From: <wil...@ai...> - 2008-04-05 20:39:29
|
As far as I can see we neither have new bug reports coming in very fast, nor outstanding bugs likely to be fixed cleanly and promptly, so this looks like a reasonable candidate for bundling up and shipping. If you disagree, speak up; the opportunity to influence a 1.x release may not come your way for many moons hereafter. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Sidney M. <si...@si...> - 2008-04-05 23:15:58
|
William Harold Newman wrote, On 6/4/08 8:46 AM: > As far as I can see we neither have new bug reports coming in very > fast, nor outstanding bugs likely to be fixed cleanly and promptly, so > this looks like a reasonable candidate for bundling up and shipping. On an Intel Mac OS X 10.5.2 (Leopard) after doing a clean build and runing the tests I get: Invalid exit status: timer.impure.lisp test failed, expected 104 return code, got 1 In timer.impure.lisp I see the comment: ;;;; OS X doesn't like these being at all, and gives us a SIGSEGV ;;;; instead of using the Mach expection system! Our or OS X's fault? ;;;; :/ If this is going to be released without a fix, should it be made an expected failure? Sidney Markowitz http://www.sidney.com |
From: Gabriel D. R. <gd...@in...> - 2008-04-06 01:12:39
|
On Sat, Apr 5, 2008 at 3:46 PM, William Harold Newman <wil...@ai...> wrote: > As far as I can see we neither have new bug reports coming in very > fast, nor outstanding bugs likely to be fixed cleanly and promptly, so > this looks like a reasonable candidate for bundling up and shipping. > > If you disagree, speak up; the opportunity to influence a 1.x release > may not come your way for many moons hereafter. this is not a disagreement; rather a suggestion that the released version for Windows does not print any `extremely cautionary' words. -- Gaby |
From: Christophe R. <cs...@ca...> - 2008-04-06 09:26:16
|
"Gabriel Dos Reis" <gd...@in...> writes: > this is not a disagreement; rather a suggestion that the released > version for Windows > does not print any `extremely cautionary' words. Until SBCL starts up independently of what other programs are running on Windows, I think it is sensible that the cautionary words remain. (If the cautionary words bother you, please help to fix this and similar issues.) Best, Christophe |
From: Gabriel D. R. <gd...@in...> - 2008-04-06 14:41:45
|
On Sun, Apr 6, 2008 at 4:25 AM, Christophe Rhodes <cs...@ca...> wrote: > "Gabriel Dos Reis" <gd...@in...> writes: > > > this is not a disagreement; rather a suggestion that the released > > version for Windows > > does not print any `extremely cautionary' words. > > Until SBCL starts up independently of what other programs are running > on Windows, Would mind an elaboration of this point? |
From: Christophe R. <cs...@ca...> - 2008-04-06 17:40:17
|
"Gabriel Dos Reis" <gd...@in...> writes: > On Sun, Apr 6, 2008 at 4:25 AM, Christophe Rhodes <cs...@ca...> wrote: >> "Gabriel Dos Reis" <gd...@in...> writes: >> >> > this is not a disagreement; rather a suggestion that the released >> > version for Windows >> > does not print any `extremely cautionary' words. >> >> Until SBCL starts up independently of what other programs are running >> on Windows, > > Would mind an elaboration of this point? Well, I'm no Windows expert, but as I understand it, once a shared library (DLL) is mapped into any process's address space, that shared library will be mapped at the same address for all processes that use that DLL. In particular, this can cause the mapping location for other DLLs to change, depending on what order the programs are started in. Certain programs (XEmacs has historically seemed to be quite a culprit) seem to use DLLs in such a way as to cause some of SBCL's own DLLs to be mapped at addresses in the middle of the address space range used for SBCL's Lisp heap. This causes SBCL to fail to start up. (Could someone who actually knows the details please correct any mistakes here? Also, I understand that one or more of David Lichteblau's git forks may solve this problem; those would be a good starting point.) Best, Christophe |
From: Gabriel D. R. <gd...@in...> - 2008-04-06 18:44:33
|
On Sun, Apr 6, 2008 at 12:40 PM, Christophe Rhodes <cs...@ca...> wrote: > "Gabriel Dos Reis" <gd...@in...> writes: > > > On Sun, Apr 6, 2008 at 4:25 AM, Christophe Rhodes <cs...@ca...> wrote: > >> "Gabriel Dos Reis" <gd...@in...> writes: > >> > >> > this is not a disagreement; rather a suggestion that the released > >> > version for Windows > >> > does not print any `extremely cautionary' words. > >> > >> Until SBCL starts up independently of what other programs are running > >> on Windows, > > > > Would mind an elaboration of this point? > > Well, I'm no Windows expert, but as I understand it, once a shared > library (DLL) is mapped into any process's address space, that shared > library will be mapped at the same address for all processes that use > that DLL. In particular, this can cause the mapping location for > other DLLs to change, depending on what order the programs are started > in. Thanks for taking the time to explain the issue. I'm no Windows expert either. I just happen to be a consumer of SBCL on Windows -- for OpenAxiom http://www.open-axiom.org/ SBCL seems to fare much better than other Lisp systems I've used to build it so far. For sure, in the past, I've not hesitated submitting patches to projects I care about when I believe I understand the issues and I can do something about them For others I care about but for which I cannot construct patches, I can only formulate wishes. I suspect you have a wish list for GCC too :-) > > Certain programs (XEmacs has historically seemed to be quite a > culprit) seem to use DLLs in such a way as to cause some of SBCL's own > DLLs to be mapped at addresses in the middle of the address space > range used for SBCL's Lisp heap. This causes SBCL to fail to start > up. If this is a Windows system issue, do you think there is anything most windows users can do something about (like sending patches to SBCL)? Is there a list of DLLs that SBCL uses and that users should be aware of? > > (Could someone who actually knows the details please correct any > mistakes here? Also, I understand that one or more of David > Lichteblau's git forks may solve this problem; those would be a good > starting point.) > > Best, > > Christophe > |
From: <wil...@ai...> - 2008-04-06 22:28:05
|
On Sun, Apr 06, 2008 at 01:44:27PM -0500, Gabriel Dos Reis wrote: > On Sun, Apr 6, 2008 at 12:40 PM, Christophe Rhodes <cs...@ca...> wrote: > > "Gabriel Dos Reis" <gd...@in...> writes: > > > > > On Sun, Apr 6, 2008 at 4:25 AM, Christophe Rhodes <cs...@ca...> wrote: > > >> "Gabriel Dos Reis" <gd...@in...> writes: > > >> > > >> > this is not a disagreement; rather a suggestion that the released > > >> > version for Windows > > >> > does not print any `extremely cautionary' words. > > >> > > >> Until SBCL starts up independently of what other programs are running > > >> on Windows, > > > > > > Would mind an elaboration of this point? > > > > Well, I'm no Windows expert, but as I understand it, once a shared > > library (DLL) is mapped into any process's address space, that shared > > library will be mapped at the same address for all processes that use > > that DLL. In particular, this can cause the mapping location for > > other DLLs to change, depending on what order the programs are started > > in. [...] > For others I care about but for which I cannot construct patches, I > can only formulate > wishes. I suspect you have a wish list for GCC too :-) I think "SBCL randomly fails to run depending on what other apps are running" is a sufficiently severe symptom of the chronic one-big-fixed-address-space problem that a strong warning is justified. However, if SBCL on Windows can sometimes be useful despite this, perhaps it would be better for the warning to be more specific and clinical, something along the lines of "We hope that you may find this new MSWindows port of an old designed-for-Unix system interesting or even useful --- but please beware that besides the usual bugs which might be found in any version of SBCL, there are some particularly serious and persistent bugs related to the change of OS, as documented in thefinemanual/limitations-of-mswin-port.html." -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Gabriel D. R. <gd...@in...> - 2008-04-07 06:09:02
|
On Sun, Apr 6, 2008 at 5:35 PM, William Harold Newman <wil...@ai...> wrote: > I think "SBCL randomly fails to run depending on what other apps are > running" is a sufficiently severe symptom of the chronic > one-big-fixed-address-space problem that a strong warning is > justified. However, if SBCL on Windows can sometimes be useful despite > this, perhaps it would be better for the warning to be more specific > and clinical, something along the lines of "We hope that you may find > this new MSWindows port of an old designed-for-Unix system interesting > or even useful --- but please beware that besides the usual bugs which > might be found in any version of SBCL, there are some particularly > serious and persistent bugs related to the change of OS, as documented > in thefinemanual/limitations-of-mswin-port.html." That is an excellent suggestion! -- Gaby |
From: Richard M K. <kr...@pr...> - 2008-04-07 00:52:57
|
William Harold Newman writes: > As far as I can see we neither have new bug reports coming in very > fast, nor outstanding bugs likely to be fixed cleanly and promptly, so > this looks like a reasonable candidate for bundling up and shipping. > > If you disagree, speak up; the opportunity to influence a 1.x release > may not come your way for many moons hereafter. There's a minor issue in the copy of ASDF in CVS, which is that stuff in the user's home directory can break building SBCL. Would it be objectionable to insert the following small patch or similar at least into the 1.1 release, if not the post-1.1 branch? It shouldn't affect anything except during make-target-contrib.sh. (An alternative suggestion from Dan Barlow on the cclan mailing list was to revert the copy of asdf.lisp to whatever version predated the preference loading stuff. I don't have time right now to figure out whether that's a better option; could somebody take a look this at least for the 1.1 release?) -- Richard --- contrib/asdf/asdf.lisp 15 Feb 2008 14:42:31 -0000 1.27 +++ contrib/asdf/asdf.lisp 7 Apr 2008 00:46:28 -0000 @@ -1278,6 +1278,13 @@ (when (sb-ext:posix-getenv "SBCL_BUILDING_CONTRIB") (pushnew :sbcl-hooks-require *features*))) +#+sbcl +(eval-when (:load-toplevel) + (when (sb-ext:posix-getenv "SBCL_BUILDING_CONTRIB") + (remove-method + #'load-preferences + (find-method #'load-preferences () '(system basic-load-op))))) + #+(and sbcl sbcl-hooks-require) (progn (defun module-provide-asdf (name) |
From: <wil...@ai...> - 2008-04-08 18:49:07
|
On Sun, Apr 06, 2008 at 08:52:27PM -0400, Richard M Kreuter wrote: > William Harold Newman writes: > > As far as I can see we neither have new bug reports coming in very > > fast, nor outstanding bugs likely to be fixed cleanly and promptly, so > > this looks like a reasonable candidate for bundling up and shipping. > > > > If you disagree, speak up; the opportunity to influence a 1.x release > > may not come your way for many moons hereafter. > > There's a minor issue in the copy of ASDF in CVS, which is that stuff in > the user's home directory can break building SBCL. Would it be > objectionable to insert the following small patch or similar at least > into the 1.1 release, if not the post-1.1 branch? (I'm sorry about this tardy reply, obviously faster feedback would've made particular sense in this situation.) It's fine with me as a matter of general policy. It looks like a problem worth fixing, and a problem which should be possible to fix conservatively, and both your proposal and Dan's proposal look like a conservative fixes. But in practice I don't feel I know ASDF well enough to review it usefully myself: I could easily end up mistaken either in high-minded architectural principle or at the level of grotty in-practice unportability gotchas, like whether some subcommunity is depending on patch-related trickery to make something else work. So if you are reasonably confident, or someone else is reasonably confident, that either your patch or DB's reversion will work well, then go for it. If you do, I'll plan to hold the release for a few more days after that while we see whether smoke comes out. OTOH, if we're still stuck on it by Thursday or Friday, I'm inclined to say to heck with it, name what we have sbcl-1.1, and encourage the stable-branch-or-whatever community to start up their core-fix pipeline ASAP.:-| > It shouldn't affect > anything except during make-target-contrib.sh. > (An alternative > suggestion from Dan Barlow on the cclan mailing list was to revert the > copy of asdf.lisp to whatever version predated the preference loading > stuff. I don't have time right now to figure out whether that's a > better option; could somebody take a look this at least for the 1.1 > release?) > --- contrib/asdf/asdf.lisp 15 Feb 2008 14:42:31 -0000 1.27 > +++ contrib/asdf/asdf.lisp 7 Apr 2008 00:46:28 -0000 > @@ -1278,6 +1278,13 @@ > (when (sb-ext:posix-getenv "SBCL_BUILDING_CONTRIB") > (pushnew :sbcl-hooks-require *features*))) > > +#+sbcl > +(eval-when (:load-toplevel) > + (when (sb-ext:posix-getenv "SBCL_BUILDING_CONTRIB") > + (remove-method > + #'load-preferences > + (find-method #'load-preferences () '(system basic-load-op))))) > + > #+(and sbcl sbcl-hooks-require) > (progn > (defun module-provide-asdf (name) -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |