From: Juho S. <js...@ik...> - 2011-08-14 21:22:04
|
Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please let sbcl-devel know of any regressions, and try not to add any new ones in the meanwhile :-) -- Juho Snellman |
From: Faré <fa...@gm...> - 2011-08-15 02:46:35
|
On Sun, Aug 14, 2011 at 17:21, Juho Snellman <js...@ik...> wrote: > Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please let > sbcl-devel know of any regressions, and try not to add any new ones in the > meanwhile :-) > Ahem. ASDF 2.017 (previously known as 2.016.3) has been stable for two nearly months and happily adopted by several other Lisp implementations. Is there any reason to stick to 2.015.3? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org |
From: Nikodemus S. <nik...@ra...> - 2011-08-15 13:56:11
|
On 15 August 2011 05:45, Faré <fa...@gm...> wrote: > Ahem. ASDF 2.017 (previously known as 2.016.3) has been stable for two > nearly months and happily adopted by several other Lisp > implementations. Is there any reason to stick to 2.015.3? I'll update ASDF first thing after the freeze. Cheers, -- nikodemus |
From: Christoph E. <chr...@de...> - 2011-08-15 11:28:04
|
Juho Snellman <js...@ik...> writes: > Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please > let sbcl-devel know of any regressions, and try not to add any new > ones in the meanwhile :-) No regressions on mipsel (still failing on sb-posix by some SIGBUS maybe I'll find time to look closer) Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer |
From: Nikodemus S. <nik...@ra...> - 2011-08-15 13:10:28
|
On 15 August 2011 00:21, Juho Snellman <js...@ik...> wrote: > Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please let > sbcl-devel know of any regressions, and try not to add any new ones in the > meanwhile :-) I have a fix for https://bugs.launchpad.net/sbcl/+bug/807475 that I will commit despite the freeze: the regression it fixes can cause correct code to break semi-randomly. AKA *ouch*. Cheers, -- nikodemus |
From: Jim W. <jw...@dr...> - 2011-08-15 17:25:39
|
Juho Snellman <js...@ik...> writes: > Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please > let sbcl-devel know of any regressions, and try not to add any new > ones in the meanwhile :-) Solaris/x86_64 and Solaris x86 look good for the release in the default build. I'll test Darwin, and experimental threading support later. Thanks, -- Jim Wise jw...@dr... |
From: Elliott S. <ell...@gm...> - 2011-09-04 22:16:56
|
Windows binary is finally up; loads and runs lispbuilder-sdl fine. As usual, please commit the following to sbcl-page (or give me access so I can do it myself): diff --git a/platform-support-platforms.lisp b/platform-support-platforms.lisp old mode 100644 new mode 100755 index a38abc7..a568a38 --- a/platform-support-platforms.lisp +++ b/platform-support-platforms.lisp @@ -48,5 +48,5 @@ (define-port :x86-64 :openbsd :available "1.0.50" :os-version 49) (define-port :powerpc :openbsd :available "1.0.50" :os-version 49) -(define-port :x86 :windows :in-progress "1.0.50" :file-type "msi") +(define-port :x86 :windows :in-progress "1.0.51" :file-type "msi") (define-port :x86-64 :windows :in-progress) On Sun, Aug 28, 2011 at 1:59 PM, Gabriel Dos Reis < gd...@in...> wrote: > On Sun, Aug 28, 2011 at 3:18 PM, Aleksej Saushev <as...@in...> wrote: > > In fact, I wish tests weren't run unless explicitly asked. > > Seconded. (That used to be the case.) > > > ------------------------------------------------------------------------------ > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay |
From: Josh E. <jo...@el...> - 2011-09-05 01:16:37
|
Page updated, thanks. On Sun, Sep 04, 2011 at 03:16:49PM -0700, Elliott Slaughter wrote: > Windows binary is finally up; loads and runs lispbuilder-sdl fine. > > As usual, please commit the following to sbcl-page (or give me access so I > can do it myself): > > diff --git a/platform-support-platforms.lisp > b/platform-support-platforms.lisp > old mode 100644 > new mode 100755 > index a38abc7..a568a38 > --- a/platform-support-platforms.lisp > +++ b/platform-support-platforms.lisp > @@ -48,5 +48,5 @@ > (define-port :x86-64 :openbsd :available "1.0.50" :os-version 49) > (define-port :powerpc :openbsd :available "1.0.50" :os-version 49) > > -(define-port :x86 :windows :in-progress "1.0.50" :file-type "msi") > +(define-port :x86 :windows :in-progress "1.0.51" :file-type "msi") > (define-port :x86-64 :windows :in-progress) > > > On Sun, Aug 28, 2011 at 1:59 PM, Gabriel Dos Reis < > gd...@in...> wrote: > > > On Sun, Aug 28, 2011 at 3:18 PM, Aleksej Saushev <as...@in...> wrote: > > > In fact, I wish tests weren't run unless explicitly asked. > > > > Seconded. (That used to be the case.) > > > > > > ------------------------------------------------------------------------------ > > EMC VNX: the world's simplest storage, starting under $10K > > The only unified storage solution that offers unified management > > Up to 160% more powerful than alternatives and 25% more efficient. > > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > > _______________________________________________ > > Sbcl-devel mailing list > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > > > > > -- > Elliott Slaughter > > "Don't worry about what anybody else is going to do. The best way to predict > the future is to invent it." - Alan Kay > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Martin C. <cra...@co...> - 2011-08-15 21:56:32
|
Juho Snellman wrote on Sun, Aug 14, 2011 at 11:21:57PM +0200: > Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please let > sbcl-devel know of any regressions, and try not to add any new ones in the > meanwhile :-) Thingy looks fine to me. (as usual, no CLOS tested etc) Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ |
From: Paul K. <pv...@pv...> - 2011-08-15 22:02:53
|
On 2011-08-14, at 5:21 PM, Juho Snellman wrote: > Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please let sbcl-devel know of any regressions, and try not to add any new ones in the meanwhile :-) A build + test on PPC would be appreciated, if someone has the hardware/time. Paul Khuong |
From: Ari J. <iam...@gm...> - 2011-08-16 01:56:20
|
On Mon, Aug 15, 2011 at 5:02 PM, Paul Khuong <pv...@pv...> wrote: > On 2011-08-14, at 5:21 PM, Juho Snellman wrote: > > > Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please let > sbcl-devel know of any regressions, and try not to add any new ones in the > meanwhile :-) > > A build + test on PPC would be appreciated, if someone has the > hardware/time. Newcomer to the list here, but I lurk a bit and poke around to try to understand things when I have free time. Below are the test results for 1.0.49, 1.0.50, and a recent checkout on PPC Mac OS X 10.6. I can provide a build if someone wants it. 1.0.49: Finished running tests. Status: Expected failure: float.pure.lisp / (SCALE-FLOAT-OVERFLOW BUG-372) Expected failure: float.pure.lisp / (ADDITION-OVERFLOW BUG-372) Failure: compiler.impure.lisp / REGRESSION-1.0.29.54 Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346) Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353) Failure: debug.impure.lisp / BUG-310175 Expected failure: dynamic-extent.impure.lisp / (NO-CONSING DX-RAW-INSTANCES) Failure: dynamic-extent.impure.lisp / (NO-CONSING HASH-TABLES) Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-BOGUS-COMPILER-NOTE Expected failure: dynamic-extent.impure.lisp / DX-COMPILER-NOTES Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-EATING-STACK Expected failure: dynamic-extent.impure.lisp / RECHECK-NESTED-DX-BUG Expected failure: dynamic-extent.impure.lisp / BUG-586105 Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT 1.0.50: Expected failure: float.pure.lisp / (ADDITION-OVERFLOW BUG-372) Failure: float.pure.lisp / RANGE-REDUCTION Unhandled error float.pure.lisp Skipped (broken): threads.pure.lisp / SYMBOL-VALUE-IN-THREAD.3 Failure: compiler.impure.lisp / REGRESSION-1.0.29.54 Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346) Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353) Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL) Skipped (broken): debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL) Failure: debug.impure.lisp / BUG-310175 Expected failure: dynamic-extent.impure.lisp / (NO-CONSING DX-RAW-INSTANCES) Failure: dynamic-extent.impure.lisp / (NO-CONSING HASH-TABLES) Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-BOGUS-COMPILER-NOTE Expected failure: dynamic-extent.impure.lisp / DX-COMPILER-NOTES Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-EATING-STACK Expected failure: dynamic-extent.impure.lisp / RECHECK-NESTED-DX-BUG Expected failure: dynamic-extent.impure.lisp / BUG-586105 Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Skipped (broken): timer.impure.lisp / (TIMER PARALLEL-UNSCHEDULE) (41 tests skipped for this combination of platform and features) master as of Mon Aug 15 18:06:01 EDT 2011: Expected failure: float.pure.lisp / (SCALE-FLOAT-OVERFLOW BUG-372) Expected failure: float.pure.lisp / (ADDITION-OVERFLOW BUG-372) Failure: float.pure.lisp / RANGE-REDUCTION Unhandled error float.pure.lisp Skipped (broken): threads.pure.lisp / SYMBOL-VALUE-IN-THREAD.3 Failure: compiler.impure.lisp / REGRESSION-1.0.29.54 Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346) Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353) Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL) Skipped (broken): debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL) Failure: debug.impure.lisp / BUG-310175 Expected failure: dynamic-extent.impure.lisp / (NO-CONSING DX-RAW-INSTANCES) Failure: dynamic-extent.impure.lisp / (NO-CONSING HASH-TABLES) Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-BOGUS-COMPILER-NOTE Expected failure: dynamic-extent.impure.lisp / DX-COMPILER-NOTES Expected failure: dynamic-extent.impure.lisp / HANDLER-CASE-EATING-STACK Expected failure: dynamic-extent.impure.lisp / RECHECK-NESTED-DX-BUG Expected failure: dynamic-extent.impure.lisp / BUG-586105 Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Skipped (broken): timer.impure.lisp / (TIMER PARALLEL-UNSCHEDULE) (43 tests skipped for this combination of platform and features) test failed, expected 104 return code, got 1 |
From: Jim W. <jw...@dr...> - 2011-08-16 15:53:26
Attachments:
room.test.out
|
Jim Wise <jw...@dr...> writes: > Juho Snellman <js...@ik...> writes: > >> Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please >> let sbcl-devel know of any regressions, and try not to add any new >> ones in the meanwhile :-) > > Solaris/x86_64 and Solaris x86 look good for the release in the default > build. I'll test Darwin, and experimental threading support later. > > Thanks, In further testing, I am seeing a new broken test on SunOS/x86: Finished running tests. Status: Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL) Skipped (broken): debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL) Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Invalid exit status: room.test.sh (40 tests skipped for this combination of platform and features) test failed, expected 104 return code, got 1 I've enclosed the output of a manual run of room.test.sh. This problem does not occur on SunOS/x86_64. |
From: Christophe R. <cs...@ca...> - 2011-08-16 16:30:01
|
Jim Wise <jw...@dr...> writes: > I've enclosed the output of a manual run of room.test.sh. The heap grows excitingly. If I had to guess, this was the reason that sb-di::valid-lisp-pointer-p was not declared inline; if it's inline, then (my guess) 32-bit addresses stay in conservatively-scavenged locations for longer. > This problem does not occur on SunOS/x86_64. This is consistent with my guess :-) Cheers, Christophe |
From: Stas B. <sta...@gm...> - 2011-08-16 17:53:44
|
Christophe Rhodes <cs...@ca...> writes: > Jim Wise <jw...@dr...> writes: > >> I've enclosed the output of a manual run of room.test.sh. > > The heap grows excitingly. If I had to guess, this was the reason that > sb-di::valid-lisp-pointer-p was not declared inline; if it's inline, > then (my guess) 32-bit addresses stay in conservatively-scavenged > locations for longer. > >> This problem does not occur on SunOS/x86_64. > > This is consistent with my guess :-) Oh, I didn't test on x86. But isn't valid-lisp-pointer-p run only under without-gcing, so how can there be any difference? Or does that happen when the GC kicks in after without-gcing? -- With best regards, Stas. |
From: Nikodemus S. <nik...@ra...> - 2011-08-16 18:25:20
|
On 16 August 2011 20:53, Stas Boukarev <sta...@gm...> wrote: > Oh, I didn't test on x86. > But isn't valid-lisp-pointer-p run only under > without-gcing, so how can there be any difference? Or does that happen > when the GC kicks in after without-gcing? I have a different diagnosis. The last call to ROOM before BOOM reports: Dynamic space usage is: 27,778,312 bytes. Read-only space usage is: 2,760 bytes. Static space usage is: 1,712 bytes. Control stack usage is: 1,656 bytes. Binding stack usage is: 392 bytes. Garbage collection is currently enabled. Breakdown for dynamic space: 571,100,920 bytes for 71,335,109 bignum objects. 46,141,560 bytes for 2,752,075 other objects. 617,242,480 bytes for 74,087,184 dynamic objects (space total.) Note the difference between Dynamic space usage is: 27,778,312 bytes. and 617,242,480 bytes for 74,087,184 dynamic objects (space total.) . The first number is the (correct) size of dynamic space before MAP-ALLOCATED-OBJECTS is run. The second number is the total summed across all allocated objects as seen by MAP-ALLOCATED-OBJECTS. So my reading is that MAP-ALLOCATED-OBJECTS is suddenly consing like mad. Disassembling it on x86 before and after allowing inlining of VALID-LISP-POINTER-P is likely to show what's going on. This is corroborated by the first number staying relatively stable -- indicating that the garbage from MAP-ALLOCATED-OBJECTS keeps being collected without trouble. Cheers, -- Nikodemus |
From: Stas B. <sta...@gm...> - 2011-08-16 20:02:07
|
Nikodemus Siivola <nik...@ra...> writes: > On 16 August 2011 20:53, Stas Boukarev <sta...@gm...> wrote: > >> Oh, I didn't test on x86. >> But isn't valid-lisp-pointer-p run only under >> without-gcing, so how can there be any difference? Or does that happen >> when the GC kicks in after without-gcing? > > I have a different diagnosis. > > The last call to ROOM before BOOM reports: > > Dynamic space usage is: 27,778,312 bytes. > Read-only space usage is: 2,760 bytes. > Static space usage is: 1,712 bytes. > Control stack usage is: 1,656 bytes. > Binding stack usage is: 392 bytes. > Garbage collection is currently enabled. > > Breakdown for dynamic space: > 571,100,920 bytes for 71,335,109 bignum objects. > 46,141,560 bytes for 2,752,075 other objects. > 617,242,480 bytes for 74,087,184 dynamic objects (space total.) > > Note the difference between > > Dynamic space usage is: 27,778,312 bytes. > > and > > 617,242,480 bytes for 74,087,184 dynamic objects (space total.) > > . The first number is the (correct) size of dynamic space before > MAP-ALLOCATED-OBJECTS is run. > > The second number is the total summed across all allocated objects as > seen by MAP-ALLOCATED-OBJECTS. > > So my reading is that MAP-ALLOCATED-OBJECTS is suddenly consing like > mad. Disassembling it on x86 before and after allowing inlining of > VALID-LISP-POINTER-P is likely to show what's going on. > > This is corroborated by the first number staying relatively stable -- > indicating that the garbage from MAP-ALLOCATED-OBJECTS keeps being > collected without trouble. VALID-LISP-POINTER-P is only called by MAKE-LISP-OBJ, which in turn is only called when `careful' parameter for MAP-ALLOCATED-OBJECTS is T, and ROOM calls it with careful being NIL. So, I don't see how making v-l-p-p inline can possibly affect ROOM. And I can't reproduce this on x86-linux. -- With best regards, Stas. |
From: Jim W. <jw...@dr...> - 2011-08-23 18:35:13
|
Juho Snellman <js...@ik...> writes: > Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please > let sbcl-devel know of any regressions, and try not to add any new > ones in the meanwhile :-) I've uploaded 1.0.51 builds for Darwin x86 and x86-64, and for Solaris x86-64. I've held off on uploading a build for Solaris x86, as the heap exhaustion issue persists -- I've added a readme advising users to use 1.0.50 until this is resolved. I've also uploaded an experimental threading build for darwin x86. Thanks, -- Jim Wise jw...@dr... |
From: Josh E. <jo...@el...> - 2011-08-24 14:26:01
|
On Tue, Aug 16, 2011 at 11:53:05AM -0400, Jim Wise wrote: > Jim Wise <jw...@dr...> writes: > > > Juho Snellman <js...@ik...> writes: > > > >> Barring any surprises, I'll release SBCL 1.0.51 next weekend. Please > >> let sbcl-devel know of any regressions, and try not to add any new > >> ones in the meanwhile :-) > > > > Solaris/x86_64 and Solaris x86 look good for the release in the default > > build. I'll test Darwin, and experimental threading support later. > > > > Thanks, > > In further testing, I am seeing a new broken test on SunOS/x86: > > Finished running tests. > Status: > Skipped (broken): debug.impure.lisp / (TRACE ENCAPSULATE NIL) > Skipped (broken): debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE > NIL) > Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET > Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT > Invalid exit status: room.test.sh > (40 tests skipped for this combination of platform and features) > test failed, expected 104 return code, got 1 > > I've enclosed the output of a manual run of room.test.sh. > > This problem does not occur on SunOS/x86_64. I just recently fixed the mail system on my OpenBSD/x86 machine and realized that the same problem has existed there since ~Aug 1. An automated bisection shows the problematic commit as: commit e7b2c507c364da9395ad1f9591210dac44f24afd Author: Nikodemus Siivola <nik...@sb...> Date: Mon Aug 1 16:46:26 2011 +0300 more robust backtraces for syscalls on x86 * new optimization policy: ALIEN-FUNCALL-SAVES-FP-AND-PC Set to 3 for self-build on x86 to get reliable more backtraces there, and 0 for other platforms. (1 matches the old SPEED <= DEBUG behaviour.) * When using a saved FP, and an interrupt context has a bogus FP, assume it is an interrupted syscall frame. If I update to the current HEAD and unconditionally set sb!c:alien-funcall-saves-fp-and-pc to 0 in make-host-2.lisp then the room test is able to finish normally, with normal-looking output: Dynamic space usage is: 38,983,360 bytes. Read-only space usage is: 2,760 bytes. Static space usage is: 1,712 bytes. Control stack usage is: 1,656 bytes. Binding stack usage is: 392 bytes. Garbage collection is currently enabled. Breakdown for dynamic space: 9,188,968 bytes for 12,169 code objects. 9,164,056 bytes for 1,145,507 sap objects. 5,068,968 bytes for 633,621 cons objects. 3,878,848 bytes for 89,773 instance objects. 3,451,920 bytes for 58,112 simple-vector objects. 2,981,984 bytes for 320,312 bignum objects. 5,625,240 bytes for 132,569 other objects. 39,359,984 bytes for 2,392,063 dynamic objects (space total.) test room test ok |
From: Nikodemus S. <nik...@ra...> - 2011-08-24 15:26:56
|
On 24 August 2011 17:25, Josh Elsasser <jo...@el...> wrote: > I just recently fixed the mail system on my OpenBSD/x86 machine and > realized that the same problem has existed there since ~Aug 1. An > automated bisection shows the problematic commit as: > more robust backtraces for syscalls on x86 > If I update to the current HEAD and unconditionally set > sb!c:alien-funcall-saves-fp-and-pc to 0 in make-host-2.lisp then the > room test is able to finish normally, with normal-looking output: I'm guessing it's the call to find_page_index that is the problem. Does adding (declare (optimize (sb!c:alien-funcall-saves-fp-and-pc 0))) to MAP-ALLOCATED-OBJECTS have the same effect for you? Cheers, -- nikodemus |
From: Josh E. <jo...@el...> - 2011-08-24 17:19:53
|
On Wed, Aug 24, 2011 at 06:26:49PM +0300, Nikodemus Siivola wrote: > On 24 August 2011 17:25, Josh Elsasser <jo...@el...> wrote: > > > I just recently fixed the mail system on my OpenBSD/x86 machine and > > realized that the same problem has existed there since ~Aug 1. An > > automated bisection shows the problematic commit as: > > > ?? ??more robust backtraces for syscalls on x86 > > > If I update to the current HEAD and unconditionally set > > sb!c:alien-funcall-saves-fp-and-pc to 0 in make-host-2.lisp then the > > room test is able to finish normally, with normal-looking output: > > I'm guessing it's the call to find_page_index that is the problem. > > Does adding (declare (optimize (sb!c:alien-funcall-saves-fp-and-pc > 0))) to MAP-ALLOCATED-OBJECTS have the same effect for you? Seems to, yes: diff --git a/src/code/room.lisp b/src/code/room.lisp index 3877c29..6e4ef7e 100644 --- a/src/code/room.lisp +++ b/src/code/room.lisp @@ -236,6 +236,7 @@ #!-sb-fluid (declaim (maybe-inline map-allocated-objects)) (defun map-allocated-objects (fun space &optional careful) (declare (type function fun) (type spaces space)) + (declare (optimize (sb!c:alien-funcall-saves-fp-and-pc 0))) (flet ((make-obj (tagged-address) (if careful (make-lisp-obj tagged-address nil) Dynamic space usage is: 39,650,016 bytes. Read-only space usage is: 2,760 bytes. Static space usage is: 1,712 bytes. Control stack usage is: 1,656 bytes. Binding stack usage is: 392 bytes. Garbage collection is currently enabled. Breakdown for dynamic space: 9,528,024 bytes for 1,191,003 sap objects. 9,272,120 bytes for 12,169 code objects. 5,110,032 bytes for 638,754 cons objects. 3,935,512 bytes for 91,866 instance objects. 3,460,304 bytes for 58,473 simple-vector objects. 3,075,192 bytes for 331,963 bignum objects. 5,657,936 bytes for 133,259 other objects. 40,039,120 bytes for 2,457,487 dynamic objects (space total.) test room test ok |
From: Elliott S. <ell...@gm...> - 2011-08-28 03:47:56
|
SBCL 1.0.51 compiles fine on Windows, but when I tried to build an installer, I ran into the following error: This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" unhandled SIMPLE-ERROR: No abbreviation for type: file 0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {23E2DD65}> :START 0 :COUNT 128) 1: (BACKTRACE 128 #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {223B2BB9}>) 2: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SIMPLE-ERROR "No abbreviation for type: ~A" {23E2C929}> #<unavailable argument>) 3: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #<SIMPLE-ERROR "No abbreviation for type: ~A" {23E2C929}>) 4: (INVOKE-DEBUGGER #<SIMPLE-ERROR "No abbreviation for type: ~A" {23E2C929}>) 5: (ERROR "No abbreviation for type: ~A" "file") 6: (FILE-NAMES #P"c:/Users/Elliott/Desktop/sbcl-1.0.51/contrib/sb-posix/test-output/some.file") 7: (COLLECT-1-COMPONENT #P"c:/Users/Elliott/Desktop/sbcl-1.0.51/contrib/sb-posix/test-output/") 8: (COLLECT-COMPONENTS #P"c:/Users/Elliott/Desktop/sbcl-1.0.51/contrib/sb-posix/test-output/") 9: (COLLECT-COMPONENTS #P"c:/Users/Elliott/Desktop/sbcl-1.0.51/contrib/sb-posix/") 10: (COLLECT-CONTRIB-COMPONENTS) 11: (WRITE-WXS "sbcl.wxs") 12: (SB-INT:SIMPLE-EVAL-IN-LEXENV (WRITE-WXS "sbcl.wxs") #<NULL-LEXENV>) 13: (SB-IMPL::SIMPLE-EVAL-PROGN-BODY ((WRITE-RTF (READ-TEXT "../COPYING") "License.rtf") (WRITE-WXS "sbcl.wxs") (WITH-OPEN-FILE (F "version.txt" :DIRECTION :OUTPUT :IF-EXISTS :SUPERSEDE) (WRITE-LINE (LISP-IMPLEMENTATION-VERSION) F)) (QUIT)) #<NULL-LEXENV>) 14: (SB-INT:SIMPLE-EVAL-IN-LEXENV (PROGN (WRITE-RTF (READ-TEXT "../COPYING") "License.rtf") (WRITE-WXS "sbcl.wxs") (WITH-OPEN-FILE (F "version.txt" :DIRECTION :OUTPUT :IF-EXISTS :SUPERSEDE) (WRITE-LINE (LISP-IMPLEMENTATION-VERSION) F)) (QUIT)) #<NULL-LEXENV>) 15: (EVAL (PROGN (WRITE-RTF (READ-TEXT "../COPYING") "License.rtf") (WRITE-WXS "sbcl.wxs") (WITH-OPEN-FILE (F "version.txt" :DIRECTION :OUTPUT :IF-EXISTS :SUPERSEDE) (WRITE-LINE (LISP-IMPLEMENTATION-VERSION) F)) (QUIT))) 16: (SB-IMPL::PROCESS-EVAL/LOAD-OPTIONS ((:LOAD . "../tools-for-build/rtf.lisp") (:LOAD . "../tools-for-build/wxs.lisp") (:EVAL . "(progn (write-rtf (read-text \"../COPYING\") \"License.rtf\") (write-wxs \"sbcl.wxs\") (with-open-file (f \"version.txt\" :direction :output :if-exists :supersede) (write-line (lisp-implementation-version) f)) (quit))"))) 17: (SB-IMPL::TOPLEVEL-INIT) 18: ((FLET #:WITHOUT-INTERRUPTS-BODY-[RESTART-LISP]30)) 19: ((LABELS SB-IMPL::RESTART-LISP)) 20: ("foreign function: #x413C14") 21: ("foreign function: #x40B2D5") unhandled condition in --disable-debugger mode, quitting On Wed, Aug 24, 2011 at 10:19 AM, Josh Elsasser <jo...@el...> wrote: > On Wed, Aug 24, 2011 at 06:26:49PM +0300, Nikodemus Siivola wrote: > > On 24 August 2011 17:25, Josh Elsasser <jo...@el...> wrote: > > > > > I just recently fixed the mail system on my OpenBSD/x86 machine and > > > realized that the same problem has existed there since ~Aug 1. An > > > automated bisection shows the problematic commit as: > > > > > ?? ??more robust backtraces for syscalls on x86 > > > > > If I update to the current HEAD and unconditionally set > > > sb!c:alien-funcall-saves-fp-and-pc to 0 in make-host-2.lisp then the > > > room test is able to finish normally, with normal-looking output: > > > > I'm guessing it's the call to find_page_index that is the problem. > > > > Does adding (declare (optimize (sb!c:alien-funcall-saves-fp-and-pc > > 0))) to MAP-ALLOCATED-OBJECTS have the same effect for you? > > Seems to, yes: > > > diff --git a/src/code/room.lisp b/src/code/room.lisp > index 3877c29..6e4ef7e 100644 > --- a/src/code/room.lisp > +++ b/src/code/room.lisp > @@ -236,6 +236,7 @@ > #!-sb-fluid (declaim (maybe-inline map-allocated-objects)) > (defun map-allocated-objects (fun space &optional careful) > (declare (type function fun) (type spaces space)) > + (declare (optimize (sb!c:alien-funcall-saves-fp-and-pc 0))) > (flet ((make-obj (tagged-address) > (if careful > (make-lisp-obj tagged-address nil) > > > Dynamic space usage is: 39,650,016 bytes. > Read-only space usage is: 2,760 bytes. > Static space usage is: 1,712 bytes. > Control stack usage is: 1,656 bytes. > Binding stack usage is: 392 bytes. > Garbage collection is currently enabled. > > Breakdown for dynamic space: > 9,528,024 bytes for 1,191,003 sap objects. > 9,272,120 bytes for 12,169 code objects. > 5,110,032 bytes for 638,754 cons objects. > 3,935,512 bytes for 91,866 instance objects. > 3,460,304 bytes for 58,473 simple-vector objects. > 3,075,192 bytes for 331,963 bignum objects. > 5,657,936 bytes for 133,259 other objects. > 40,039,120 bytes for 2,457,487 dynamic objects (space total.) > test room test ok > > > ------------------------------------------------------------------------------ > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay |
From: David L. <da...@li...> - 2011-08-28 07:37:06
|
Hi, Quoting Elliott Slaughter (ell...@gm...): > SBCL 1.0.51 compiles fine on Windows, but when I tried to build an > installer, I ran into the following error: when you built installers in the past, was sb-posix included? I think this failure (to package sb-posix) isn't new, but it's the first time sb-posix test failures do not prevent its inclusion in the installer. The workaround for this release will be to to remove the test-output directory manually before building the installer. Sorry about that. I'll push changes soon to fix this (for the next release). d. |
From: Aleksej S. <as...@in...> - 2011-08-28 20:19:11
|
David Lichteblau <da...@li...> writes: > Quoting Elliott Slaughter (ell...@gm...): >> SBCL 1.0.51 compiles fine on Windows, but when I tried to build an >> installer, I ran into the following error: > > when you built installers in the past, was sb-posix included? > > I think this failure (to package sb-posix) isn't new, but it's the first > time sb-posix test failures do not prevent its inclusion in the > installer. > > The workaround for this release will be to to remove the test-output > directory manually before building the installer. Sorry about that. We have to remove test output since it doesn't have reproducable file names. In fact, I wish tests weren't run unless explicitly asked. -- HE CE3OH... |
From: Gabriel D. R. <gd...@in...> - 2011-08-28 20:59:24
|
On Sun, Aug 28, 2011 at 3:18 PM, Aleksej Saushev <as...@in...> wrote: > In fact, I wish tests weren't run unless explicitly asked. Seconded. (That used to be the case.) |