From: Juho S. <js...@ik...> - 2011-02-15 02:39:22
|
Now that sourceforge is finally back, it's time for a long overdue release. I'll do it this weekend, so until then testing good, breaking more stuff bad. -- Juho Snellman |
From: Roman M. <rom...@gm...> - 2011-02-15 07:34:11
|
Please include this simple patch into the release: https://bugs.launchpad.net/sbcl/+bug/520607 <https://bugs.launchpad.net/sbcl/+bug/520607>Thank you, Roman 2011/2/15 Juho Snellman <js...@ik...> > Now that sourceforge is finally back, it's time for a long overdue release. > I'll do it this weekend, so until then testing good, breaking more stuff > bad. > > -- > Juho Snellman > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > |
From: Harald Hanche-O. <ha...@ma...> - 2011-02-15 10:36:42
|
[Juho Snellman <js...@ik...> (2011-02-15 02:39:16 UTC)] > Now that sourceforge is finally back, it's time for a long overdue release. > I'll do it this weekend, so until then testing good, breaking more stuff > bad. I think the following patch is in order: diff --git a/tests/threads.pure.lisp b/tests/threads.pure.lisp index 539d5de..752d230 100644 --- a/tests/threads.pure.lisp +++ b/tests/threads.pure.lisp @@ -159,6 +159,7 @@ ;;;; Printing waitqueues +#+sb-thread (with-test (:name :waitqueue-circle-print) (let* ((*print-circle* nil) (lock (sb-thread:make-mutex)) Without it, the following badness happens. // Running /local/src/lisp/sbcl/sbcl-git/tests/threads.pure.lisp [...] ::: Running :WAITQUEUE-CIRCLE-PRINT ::: UNEXPECTED-FAILURE :WAITQUEUE-CIRCLE-PRINT due to #<SIMPLE-ERROR "Not supported in unithread builds." {10036C76F1}>: "Not supported in unithread builds." debugger invoked on a SIMPLE-ERROR: Not supported in unithread builds. - Harald |
From: Martin C. <cra...@co...> - 2011-02-15 16:01:31
|
I'm having a type inference regression that might be my toy's or SBCL's fault. Investigating now. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ |
From: Nikodemus S. <nik...@ra...> - 2011-02-15 12:30:14
|
On 15 February 2011 12:36, Harald Hanche-Olsen <ha...@ma...> wrote: > Without it, the following badness happens. Thanks -- and my bad! Merged as 1.0.45.34. Re. Roman's patch: not sufficiently trivial to commit during freeze. Next week, sorry. Cheers, -- Nikodemus > > // Running /local/src/lisp/sbcl/sbcl-git/tests/threads.pure.lisp > [...] > ::: Running :WAITQUEUE-CIRCLE-PRINT > ::: UNEXPECTED-FAILURE :WAITQUEUE-CIRCLE-PRINT > due to #<SIMPLE-ERROR "Not supported in unithread builds." {10036C76F1}>: > "Not supported in unithread builds." > > debugger invoked on a SIMPLE-ERROR: Not supported in unithread builds. > > - Harald > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Nikodemus S. <nik...@ra...> - 2011-02-15 14:09:08
|
I've gotten some question re. freeze policy, so I figured I'd make my take on it public here to avoid misunderstandings. Every committer shoulders his own responsibility. If anyone with a commit bit does things a bit differently, that is their prerogative. I'll take it up with them if I feel the need, and expect them to do likewise. My current personal my filter for freeze-commits is: - Does it fix a regression during this release series and comes with a test-case? It needs to go in. - Is it an obviously-correct single hunk that fixes a bug and comes with a test-case? It can probably go in, but doesn't have to. - Is it a documentation patch? It can probably go in, but doesn't have to. - Is it something very close to one of the above? Maybe it can, maybe it can't. - Otherwise no, it can't go in during freeze. Cheers, -- Nikodemus |
From: Jim W. <jw...@dr...> - 2011-02-16 14:54:26
|
Juho Snellman <js...@ik...> writes: > Now that sourceforge is finally back, it's time for a long overdue release. I'll do it this weekend, so until then testing good, breaking more stuff bad. Cool! Solaris support for x86_64 will be broken in this release due to page size issues (1.0.45 works fine, and is on the download page) -- I'm working on this, but won't have a fix in for 1.0.46. Solaris x86 works fine, and I'll upload a build as soon as the release is tagged. Thanks, -- Jim Wise jw...@dr... |
From: Martin C. <cra...@co...> - 2011-02-16 18:12:58
|
Juho Snellman wrote on Tue, Feb 15, 2011 at 03:39:16AM +0100: > Now that sourceforge is finally back, it's time for a long overdue release. > I'll do it this weekend, so until then testing good, breaking more stuff > bad. Can't find anything wrong with 1.0.45.34. Type error was probably ours. The function is broken before and after anyway so I'm not gonna start a project on it :-) Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ |
From: Jim W. <jw...@dr...> - 2011-02-16 20:38:52
|
Jim Wise <jw...@dr...> writes: > Juho Snellman <js...@ik...> writes: > >> Now that sourceforge is finally back, it's time for a long overdue release. I'll do it this weekend, so until then testing good, breaking more stuff bad. > > Cool! Solaris support for x86_64 will be broken in this release due to > page size issues (1.0.45 works fine, and is on the download page) -- I'm > working on this, but won't have a fix in for 1.0.46. Solaris x86 works > fine, and I'll upload a build as soon as the release is tagged. Actually, I have a fix for the Solaris x86_64 thing which I'll put on launchpad tomorrow morning (still testing the best way to integrate this). So, if I can fix the sb-posix readdir thing in time for this weekend, 1.0.46 can include builds for both Solaris x86 and Solaris x86_64. Thanks, -- Jim Wise jw...@dr... |
From: Jim W. <jw...@dr...> - 2011-02-16 21:54:55
|
Jim Wise <jw...@dr...> writes: > Jim Wise <jw...@dr...> writes: > >> Juho Snellman <js...@ik...> writes: >> >>> Now that sourceforge is finally back, it's time for a long overdue release. I'll do it this weekend, so until then testing good, breaking more stuff bad. >> >> Cool! Solaris support for x86_64 will be broken in this release due to >> page size issues (1.0.45 works fine, and is on the download page) -- I'm >> working on this, but won't have a fix in for 1.0.46. Solaris x86 works >> fine, and I'll upload a build as soon as the release is tagged. > > Actually, I have a fix for the Solaris x86_64 thing which I'll put on > launchpad tomorrow morning (still testing the best way to integrate > this). > > So, if I can fix the sb-posix readdir thing in time for this weekend, > 1.0.46 can include builds for both Solaris x86 and Solaris x86_64. So, this boils down to revision 1.5 of src/compiler/x86_64/backend-parms.lisp, which changed the compiled-in value of *backend-page-bytes* from 4k to 32k, which Solaris x86-64 can't support in the default configuration. Changing this back to 4k makes Solaris work, but would have a performance impact on other platforms. This is easy enough to control with #!+sunos, but I want to make sure that I understand how this will affect cross-compilation -- I don't want to tie a build cross-compiled from Solaris for another x86-64 port to a 4k pagesize, and I don't want builds cross-compiled for Solaris from another port to create non-working binaries. How are #! read-time conditionals are set when cross-compiling? Thanks, -- Jim Wise jw...@dr... |
From: James Y K. <fo...@fu...> - 2011-02-16 22:09:19
|
On Feb 16, 2011, at 4:54 PM, Jim Wise wrote: > Jim Wise <jw...@dr...> writes: > >> Jim Wise <jw...@dr...> writes: >> >>> Juho Snellman <js...@ik...> writes: >>> >>>> Now that sourceforge is finally back, it's time for a long overdue release. I'll do it this weekend, so until then testing good, breaking more stuff bad. >>> >>> Cool! Solaris support for x86_64 will be broken in this release due to >>> page size issues (1.0.45 works fine, and is on the download page) -- I'm >>> working on this, but won't have a fix in for 1.0.46. Solaris x86 works >>> fine, and I'll upload a build as soon as the release is tagged. >> >> Actually, I have a fix for the Solaris x86_64 thing which I'll put on >> launchpad tomorrow morning (still testing the best way to integrate >> this). >> >> So, if I can fix the sb-posix readdir thing in time for this weekend, >> 1.0.46 can include builds for both Solaris x86 and Solaris x86_64. > > So, this boils down to revision 1.5 of src/compiler/x86_64/backend-parms.lisp, > which changed the compiled-in value of *backend-page-bytes* from 4k to > 32k, which Solaris x86-64 can't support in the default configuration. I think if you change os_vm_page_size to be BACKEND_PAGE_BYTES instead of the sysconf call it is right now, it'd work again. There seems to be a misunderstanding in the SBCL source code as to what kinds of "pages" are being talked about, OS VM pages, or GC pages. The constraint in SBCL is that GC pages should be some multiple of OS VM page size, not that they are equal. But not all the os-specific code seems to know that... Probably os_vm_page_size should just disappear. James |
From: Jim W. <jw...@dr...> - 2011-02-17 03:02:42
|
James Y Knight <fo...@fu...> writes: > On Feb 16, 2011, at 4:54 PM, Jim Wise wrote: > I think if you change os_vm_page_size to be BACKEND_PAGE_BYTES instead > of the sysconf call it is right now, it'd work again. There seems to > be a misunderstanding in the SBCL source code as to what kinds of > "pages" are being talked about, OS VM pages, or GC pages. The > constraint in SBCL is that GC pages should be some multiple of OS VM > page size, not that they are equal. But not all the os-specific code > seems to know that... > > Probably os_vm_page_size should just disappear. Aha, many thanks! Indeed, that did the trick -- restoring the 32k page size, and using BACKEND_PAGE_BYTES instead of the runtime OS-level page size in src/runtime/sunos-os.c gives a binary which works and completes tests (except for the sb-posix issue noted previously, which is separate). I'd started in this direction before, but suffered a similar confusion between BACKEND_PAGE_BYTES and OS_VM_DEFAULT_PAGESIZE (which has some special case handling in sunos-os.c which I also needed to change). This is working now. I'll get a patch on launchpad in the morning, and get back to looking at the readdir thing. Thanks again! -- Jim Wise jw...@dr... |
From: Jim W. <jw...@dr...> - 2011-02-17 16:16:44
|
Jim Wise <jw...@dr...> writes: > This is working now. I'll get a patch on launchpad in the morning, and > get back to looking at the readdir thing. This is up, as #720800. I'll be looking at the readdir thing later today. Thanks, -- Jim Wise jw...@dr... |
From: Jim W. <jw...@dr...> - 2011-02-18 17:00:01
|
Jim Wise <jw...@dr...> writes: > Jim Wise <jw...@dr...> writes: > >> This is working now. I'll get a patch on launchpad in the morning, and >> get back to looking at the readdir thing. > > This is up, as #720800. I'll be looking at the readdir thing later > today. With this committed, I'm up and running on Solaris x86-64. On x86-64, I am not seeing the sb-posix c string decoding issue I reported earlier on x86 (affecting the READDIR tests in sb-posix). I've also posted a patch with a separate bug fix for tests/run-compiler.sh to avoid three false-positives in tests which compile external c code, as #720807. At this point, Solaris x86-64 is ready for a 1.0.46 release. I'm seeking a fix for the dirent thing, but this obviously shouldn't hold the release -- Solaris x86 has a 1.0.45 build up for download, and should have 1.0.47 if it misses 1.0.46. Thanks, -- Jim Wise jw...@dr... |