From: <lut...@fr...> - 2012-04-30 21:04:30
|
Hi, I see the test for bug #936304 in "gc.impure.lisp" fail on x86. Did I miss a discussion about this or am I the first one to notice? Tested on 64-bit Linux with the following x86 SBCLs: sbcl-1.0.56-7-g6b1b11a sbcl-1.0.56-55-gf0da2f6 I have not tested earlier versions. sbcl-1.0.56-7-g6b1b11a is the commit "gencgc: reclaim space more aggressively", which claims that it fixed this bug and introduced the test for it. Greetings, Lutz |
From: Martin C. <cra...@co...> - 2012-04-30 22:46:19
|
sb-unix:unix-exit is used all over the place, among other things in asdf and friends and we don't have a *feature* to easily switch to the new world order. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ |
From: Nikodemus S. <nik...@ra...> - 2012-05-01 10:21:11
|
On 1 May 2012 01:46, Martin Cracauer <cra...@co...> wrote: > sb-unix:unix-exit is used all over the place, among other things in > asdf and friends and we don't have a *feature* to easily switch to the > new world order. I'll add it back, with a deprecation style-warning. But dammit, we really need to figure out how to direct people away from using SB-UNIX. Cheers, -- nikodemus |
From: Martin C. <cra...@co...> - 2012-05-01 15:43:10
|
Nikodemus Siivola wrote on Tue, May 01, 2012 at 01:21:05PM +0300: > On 1 May 2012 01:46, Martin Cracauer <cra...@co...> wrote: > > > sb-unix:unix-exit is used all over the place, among other things in > > asdf and friends and we don't have a *feature* to easily switch to the > > new world order. > > I'll add it back, with a deprecation style-warning. But dammit, we > really need to figure out how to direct people away from using > SB-UNIX. The problem here is that the Common Lisp standard omitted exiting a program as a concept that doesn't apply to all platforms. That pretty much puts us into a position to support it for all our platforms with some nonstandard call (all of which do exit programs, as would all current mobile platforms). The name really doesn't matter either way as long as it is stable. Maybe we should have named it (ljksdfg:kljaf) to avoid misunderstandings. Either way, randomly renaming it without a #+ symbol to switch isn't helping the users :-) Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ |
From: Pascal J. B. <pj...@in...> - 2012-05-01 11:03:30
|
Nikodemus Siivola <nik...@ra...> writes: > On 1 May 2012 01:46, Martin Cracauer <cra...@co...> wrote: > >> sb-unix:unix-exit is used all over the place, among other things in >> asdf and friends and we don't have a *feature* to easily switch to the >> new world order. > > I'll add it back, with a deprecation style-warning. But dammit, we > really need to figure out how to direct people away from using > SB-UNIX. That's easy: don't release sbcl on unix, release it only on MS-Windows. You may also choose new platforms like OpenVMS. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Nikodemus S. <nik...@ra...> - 2012-05-01 14:14:15
|
On 1 May 2012 00:01, Lutz Euler <lut...@fr...> wrote: > I see the test for bug #936304 in "gc.impure.lisp" fail on x86. > Did I miss a discussion about this or am I the first one to notice? It passes for me on current HEAD, on x86. :/ Cheers, -- Nikodemus |
From: Peter S. <pe...@pj...> - 2012-05-01 15:56:54
|
This test passes on my machine too, now. (I filed a bug for it because it was failing on x86 a few weeks ago). On Tue, 2012-05-01 at 17:14 +0300, Nikodemus Siivola wrote: > On 1 May 2012 00:01, Lutz Euler <lut...@fr...> wrote: > > > I see the test for bug #936304 in "gc.impure.lisp" fail on x86. > > Did I miss a discussion about this or am I the first one to notice? > > It passes for me on current HEAD, on x86. :/ > > Cheers, > > -- Nikodemus > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: <lut...@fr...> - 2012-05-01 17:54:04
|
Hi, Nikodemus wrote > On 1 May 2012 00:01, Lutz Euler <lut...@fr...> wrote: > > > I see the test for bug #936304 in "gc.impure.lisp" fail on x86. > > Did I miss a discussion about this or am I the first one to notice? > > It passes for me on current HEAD, on x86. :/ I tried again with SBCL 1.0.56.59-436b2ab. It's non-deterministic here: I got 6 failures out of 9 tries. All failures seem to show the same numbers of available bits in the "Heap exhausted" message. Here is one example of the output: ::: Running :BUG-936304 Heap exhausted during allocation: 71589888 bytes available, 107374192 requested. Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB LUB !move Alloc Waste Trig WP GCs Mem-age 0: 0 0 0 0 1 0 0 0 0 0 4096 5368709 0 0 0.0000 1: 0 0 0 0 2 0 104860 0 104862 429498112 16640 434866821 0 4 0.0000 2: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0.0000 3: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0.0000 4: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0.0000 5: 0 0 0 0 273 32 0 98 21 1632528 18160 7001237 251 1 0.0000 6: 0 0 0 0 5696 1213 0 0 0 28299264 0 2000000 5667 0 0.0000 Total bytes allocated = 459429904 Dynamic-space-size bytes = 536870912 GC control variables: *GC-INHIBIT* = false *GC-PENDING* = true *STOP-FOR-GC-PENDING* = false ::: UNEXPECTED-FAILURE :BUG-936304 due to #<SIMPLE-ERROR "The assertion ~S failed." {AC25061}>: "The assertion (EQ :OK (HANDLER-CASE (PROGN (LOOP REPEAT 50 DO (STRESS-GC)) :OK) (STORAGE-CONDITION NIL :OOM))) failed." Greetings, Lutz |
From: Nikodemus S. <nik...@ra...> - 2012-05-01 22:31:14
|
On 1 May 2012 20:51, Lutz Euler <lut...@fr...> wrote: > I tried again with SBCL 1.0.56.59-436b2ab. It's non-deterministic here: > I got 6 failures out of 9 tries. All failures seem to show the same > numbers of available bits in the "Heap exhausted" message. Here is one Oh crud. There's a bit of nondeterminism from the threaded test earlier in the file, but... I'll poke at it some more tomorrow. Cheers, -- nikodemus |
From: Zach B. <xa...@xa...> - 2012-05-01 19:41:34
|
Nikodemus Siivola <nik...@ra...> writes: > On 1 May 2012 01:46, Martin Cracauer <cra...@co...> wrote: > >> sb-unix:unix-exit is used all over the place, among other things in >> asdf and friends and we don't have a *feature* to easily switch to the >> new world order. > > I'll add it back, with a deprecation style-warning. But dammit, we > really need to figure out how to direct people away from using > SB-UNIX. SB-EXT:EXIT has broken Ltk, which uses SB-EXT but defines a local function named EXIT in ltk.lisp. That now triggers an SB-EXT package lock error. Zach |
From: Nikodemus S. <nik...@ra...> - 2012-05-02 07:57:48
|
On 1 May 2012 22:13, Zach Beane <xa...@xa...> wrote: > SB-EXT:EXIT has broken Ltk, which uses SB-EXT but defines a local > function named EXIT in ltk.lisp. That now triggers an SB-EXT package > lock error. Oh crud. While users /can/ make backwards compatible changes to their code, using stuff like (eval-when ... (let ((name (find-symbol "EXIT" :sb-ext))) (when (and name (fboundp name)) (pushnew :sb-ext-exit *features*)))) that's an incredible waste of effort when it's spread across several hundred projects. I /could/ just make QUIT do what EXIT does, but that would just make the breakage subtler: in older SBCL's calling it from threads other than MAIN would not do what's expected, unless :RECKLESSLY-P is provided. So, maybe it's time for a magic #+ directive that allows folks to conditionalize their code without going through that all over the place? #+(and sb-version (version>= 1.0.56.55)) ; Allegro-style #+(and sb-fboundp (fboundp sb-ext exit)) ; Nice and general. #+(and sb-supports (supports exit)) ; Using a API name, referring to *SUPPORTS* or similar. Or maybe just stop worrying about elegance of *FEATURES* and push :SB-EXIT there, and make it a policy to mark non-trivial feature changes with *FEATURES* changes? It *is* what they're for, after all. Cheers, -- Nikodemus |
From: Zach B. <xa...@xa...> - 2012-05-02 17:16:56
|
Zach Beane <xa...@xa...> writes: > Nikodemus Siivola <nik...@ra...> writes: > >> On 1 May 2012 01:46, Martin Cracauer <cra...@co...> wrote: >> >>> sb-unix:unix-exit is used all over the place, among other things in >>> asdf and friends and we don't have a *feature* to easily switch to the >>> new world order. >> >> I'll add it back, with a deprecation style-warning. But dammit, we >> really need to figure out how to direct people away from using >> SB-UNIX. > > SB-EXT:EXIT has broken Ltk, which uses SB-EXT but defines a local > function named EXIT in ltk.lisp. That now triggers an SB-EXT package > lock error. GBBopen also breaks for similar reasons. Zach |
From: Faré <fa...@gm...> - 2012-05-02 01:40:37
|
No, asdf doesn't use sb-unix:unix-exit. On the other hand, poiu does (in the same package asdf), but that could be fixed if that's the wrong thing. xcvb-driver currently uses sb-ext:quit - is that the recommended interface to use? Nikodemus, is SB-UNIX *always* the wrong thing, even when running on Unix? The xcvb forker uses it (it's also somewhat broken because of signal masking issues that Alastair knows about. Sigh.) PS: Martin, I see that at ITA, in addition to POIU, some old version of XCVB-driver and some compatibility code in QPX also uses sb-unix:unix-exit. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Q. Why does "philosophy of consciousness/nature of reality" seem to interest you so much? A. Take away consciousness and reality and there's not much left. — Greg Egan, interview in Eidolon 15 On Tue, May 1, 2012 at 3:13 PM, Zach Beane <xa...@xa...> wrote: > Nikodemus Siivola <nik...@ra...> writes: > >> On 1 May 2012 01:46, Martin Cracauer <cra...@co...> wrote: >> >>> sb-unix:unix-exit is used all over the place, among other things in >>> asdf and friends and we don't have a *feature* to easily switch to the >>> new world order. >> >> I'll add it back, with a deprecation style-warning. But dammit, we >> really need to figure out how to direct people away from using >> SB-UNIX. > |
From: Nikodemus S. <nik...@ra...> - 2012-05-02 07:39:51
|
On 2 May 2012 04:40, Faré <fa...@gm...> wrote: > No, asdf doesn't use sb-unix:unix-exit. > On the other hand, poiu does (in the same package asdf), but that > could be fixed if that's the wrong thing. > xcvb-driver currently uses sb-ext:quit - is that the recommended > interface to use? Yes. Though you need to use :RECKLESSLY-P to have it behave sanely in a thread-independent manner. If you're calling from the main thread leaving :RECKLESSLY-P out is OK. (This interface messiness if the whole reason for SB-EXT:EXIT, because QUIT was too broken to fix without breaking backwards compatibility subtly.) > Nikodemus, is SB-UNIX *always* the wrong thing, even when running on > Unix? The xcvb forker uses it (it's also somewhat broken because of > signal masking issues that Alastair knows about. Sigh.) CL-USER> (documentation (find-package :sb-unix) t) "private: a wrapper layer for SBCL itself to use when talking with an underlying Unix-y operating system. This was a public package in CMU CL, but that was different. CMU CL's UNIX package tried to provide a comprehensive, stable Unix interface suitable for the end user. This package only tries to implement what happens to be needed by the current implementation of SBCL, and makes no guarantees of interface stability." SB-POSIX is the stable inferface. Some things -- like GET-TIME-OF-DAY -- also have nice lispy interfaces in SB-EXT. If SB-POSIX doesn't have something you need, and there are no alterate interfaces, call the foreign function directly or add a bug report / feature request to Launchpad. "wanted: supported interface equivalent to SB-UNIX:UNIX-FOO". Cheers, -- Nikodemus |
From: Pascal J. B. <pj...@in...> - 2012-05-02 08:19:57
|
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Pascal J. B. <pj...@in...> - 2012-05-02 08:23:00
|
Nikodemus Siivola <nik...@ra...> writes: > CL-USER> (documentation (find-package :sb-unix) t) > "private: a wrapper layer for SBCL itself to use when talking > with an underlying Unix-y operating system. > This was a public package in CMU CL, but that was different. > CMU CL's UNIX package tried to provide a comprehensive, > stable Unix interface suitable for the end user. > This package only tries to implement what happens to be > needed by the current implementation of SBCL, and makes > no guarantees of interface stability." > > SB-POSIX is the stable inferface. Some things -- like GET-TIME-OF-DAY > -- also have nice lispy interfaces in SB-EXT. > > If SB-POSIX doesn't have something you need, and there are no alterate > interfaces, call the foreign function directly or add a bug report / > feature request to Launchpad. "wanted: supported interface equivalent > to SB-UNIX:UNIX-FOO". I see. I would propose to rename SB-UNIX to SB-PRIVATE-UX, and add a nickname SB-UNIX for temporary compatibility. Later remove all export from SB-PRIVATE-UX. This should make it more obvious that SB-PRIVATE-UX is not for public consumption. Too many implementations don't keep the docstrings so a lot of users don't have the reflex to try to get them. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Rudi S. <ru...@co...> - 2012-05-02 09:24:16
|
On May 2, 2012, at 9:39 , Nikodemus Siivola wrote: > CL-USER> (documentation (find-package :sb-unix) t) > "private: a wrapper layer for SBCL itself to use when talking > with an underlying Unix-y operating system. > This was a public package in CMU CL, but that was different. > CMU CL's UNIX package tried to provide a comprehensive, > stable Unix interface suitable for the end user. > This package only tries to implement what happens to be > needed by the current implementation of SBCL, and makes > no guarantees of interface stability." > > SB-POSIX is the stable inferface. Some things -- like GET-TIME-OF-DAY > -- also have nice lispy interfaces in SB-EXT. > > If SB-POSIX doesn't have something you need, and there are no alterate > interfaces, call the foreign function directly or add a bug report / > feature request to Launchpad. "wanted: supported interface equivalent > to SB-UNIX:UNIX-FOO". Reading these paragraphs in sequence, I can't help thinking this should all be part of the docstring. Perhaps it would even make sense to put references to sb-posix in the docstrings of the individual sb-unix functions? I can see people not checking the package docstring, but when (apropos "exit") leads me to sb-unix:unix-exit, the next thing I do is check its docstring. Rudi |
From: Nikodemus S. <nik...@ra...> - 2012-05-02 10:49:57
|
On 2 May 2012 12:07, Rudi Schlatte <ru...@co...> wrote: > Reading these paragraphs in sequence, I can't help thinking this should all be part of the docstring. > Perhaps it would even make sense to put references to sb-posix in the docstrings of the individual > sb-unix functions? I can see people not checking the package docstring, but when (apropos "exit") leads > me to sb-unix:unix-exit, the next thing I do is check its docstring. That might be a good solution. In similar vein, I'm adding a "Deprecated Interfaces" chapter to the manual, which lists the interfaces, their current status, the expected next step and schedule, a bit of rationale, and suggested remedy for code that needs to work in both legacy and modern SBCLs. Along the lines of: @item SB-EXT:QUIT and SB-UNIX:UNIX-EXIT Both were deprecated as of 1.0.56.55 in May 2012. Unfortunately the design of @code{sb-ext:quit} proved too broken to fix in a backwards-compatible manner, so it had to be deprecated and replaced with @code{sb-ext:exit} instead. The entire package SB-UNIX is an internal implementation package and should not be used by users. @strong{Remedies} For backwards-compatible solutions to code using @code{sb-unix:unix-exit} use eg. @code{(alien-funcall (extern-alien "exit" (function void int)) <exit-code>)}. Code depending on @code{sb-ext:quit} is likely to be subtly broken, as its behaviour depends the argument @code{recklessly-p}, the thread it is called in, and the current session. If support for legacy SBCLs is not needed in the long term, replace using either @code{sb-ext:exit} or @code{sb-thread:abort-thread} depending on the use-case. For legacy support, conditionalize as follows: @lisp #+#.(cl:if (cl:find-symbol "EXIT" :sb-ext) '(and) '(or)) (sb-ext:exit ...) ; or SB-THREAD:ABORT-THREAD if apppropriate #-#.(cl:if (cl:find-symbol "EXIT" :sb-ext) '(and) '(or)) (sb-ext:quit ...) @end lisp PS. ...related to this whole mess is the mess that SB-SYS is. It has things that are factually supported and advertised like WITH-DEADLINE. It has things that I would be happy to support like *SHORT-SITE-NAME*. It has things that could be supported with some documentation and API cleanup like *SHARED-OBJECTS*. It has things that definitely don't belong there like FROB-DO-BODY and MACRO. The package as a whole is at the same time claimed to be private. *sigh* One step at a time... Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2012-05-02 18:09:29
|
On 2 May 2012 13:49, Nikodemus Siivola <nik...@ra...> wrote: > In similar vein, I'm adding a "Deprecated Interfaces" chapter to the > manual, which lists the interfaces, their current status, the expected > next step and schedule, a bit of rationale, and suggested remedy for > code that needs to work in both legacy and modern SBCLs. Committed, many thanks to Rudi and Zach for their input on IRC. Cheers, -- nikodemus |