From: Nicolas N. <Nic...@iw...> - 2004-04-14 17:22:57
|
Hello, Here is the final report. My program FEMLISP now runs on both CMUCL and SBCL with identical code [1]. The test suite is about 10% faster on CMUCL (576s user time compared with 640s user time), probably because method dispatch is faster there and Femlisp uses CLOS heavily. I am using ASDF now instead of DEFSYSTEM. Nevertheless some questions/problems: 1. (require 'asdf) (require 'asdf-install) did not work for me (but I don't need asdf-install right now). (require 'asdf) NIL * (require 'asdf-install) debugger invoked on a SIMPLE-ERROR in thread 11446: Don't know how to load ASDF-INSTALL You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). 1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. ("hairy arg processor for top level local call REQUIRE" ASDF-INSTALL NIL) 0] 2. For SBCL it was enough to say: (asdf::defsystem "femlisp" :pathname "femlisp:src;" :depends-on () :components ...) while for CMUCL I had to do: (asdf::defsystem "femlisp" :pathname (translate-logical-pathname "femlisp:src;") :depends-on () :components ...) 3. The standard says something about the control of verbosity of COMPILE-FILE but not about verbosity control for COMPILE. I guess this can be done with *compile-verbose* and *compile-print* nevertheless? Thank you for all help, Nicolas. [1] This version is not yet available on the Femlisp server. I will first have to adapt the installation scripts. |
From: David S. <da...@da...> - 2004-04-14 18:48:22
|
Nicolas Neuss <Nic...@iw...> writes: > Nevertheless some questions/problems: > > 1. (require 'asdf) > (require 'asdf-install) > did not work for me (but I don't need asdf-install right now). > > (require 'asdf) > NIL > * (require 'asdf-install) Not much of an answer here, but SBCL compiled from CVS does this for me on a linux box: $ sbcl This is SBCL 0.8.9.35, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (require 'asdf) ("ASDF") * (require 'asdf-install) ; loading system definition from ; #P"/home/david/usr/lib/sbcl/systems/sb-bsd-sockets.asd" into ; #<PACKAGE "ASDF2757"> ; registering #<SYSTEM SB-BSD-SOCKETS {9A18AF1}> as SB-BSD-SOCKETS ; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {906DF39}> as SB-BSD-SOCKETS-TESTS ; loading system definition from ; #P"/home/david/usr/lib/sbcl/systems/sb-posix.asd" into #<PACKAGE "ASDF2857"> ; registering #<SYSTEM SB-POSIX {98CCA99}> as SB-POSIX ; registering #<SYSTEM SB-POSIX-TESTS {99FEB81}> as SB-POSIX-TESTS ("SB-EXECUTABLE" "SB-GROVEL" "SB-POSIX" "SB-BSD-SOCKETS" "ASDF-INSTALL") * I gather the NIL response to require was a failure. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: Nicolas N. <Nic...@iw...> - 2004-04-14 20:22:28
|
David Steuber <da...@da...> writes: > I gather the NIL response to require was a failure. Sorry, this was only because I had required it already in my .sbclrc file. The same happens when I do not do this (CVS SBCL 0.8.9.36): * (require 'asdf) ("ASDF") * (require 'asdf-install) debugger invoked on a SIMPLE-ERROR in thread 11727: Don't know how to load ASDF-INSTALL You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). 1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. ("hairy arg processor for top level local call REQUIRE" ASDF-INSTALL NIL) 0] 4. Another question to SBCL. Is there an analogue to the -dynamic-space-size option of CMUCL (and the dropping in the debugger when this space is exhausted)? In numerical simulations, it is easy to use a lot of memory, and a graceful exit would be nice. Thanks, Nicolas. |
From: Brian M. <bma...@cs...> - 2004-04-14 22:14:13
|
On Apr 14, 2004, at 3:21 PM, Nicolas Neuss wrote: > David Steuber <da...@da...> writes: > >> I gather the NIL response to require was a failure. > > Sorry, this was only because I had required it already in my .sbclrc > file. > The same happens when I do not do this (CVS SBCL 0.8.9.36): > > * (require 'asdf) > ("ASDF") > * (require 'asdf-install) > debugger invoked on a SIMPLE-ERROR in thread 11727: > Don't know how to load ASDF-INSTALL How did you build SBCL? Did you install it on one machine, make a binary distribution, and install it on another? There is a problem with asdf-install and the installation process - basically speaking if you attempt to install twice out of the same tarball, the second time will fail to install asdf-install. My recommendation is to immediately make a binary distribution of SBCL and install from that, or alternatively hack up contrib/asdf-install/Makefile to remove the bits about the standalone asdf-install binary. -- Brian Mastenbrook bma...@cs... http://cs.indiana.edu/~bmastenb/ |
From: Christophe R. <cs...@ca...> - 2004-04-14 22:04:45
|
Nicolas Neuss <Nic...@iw...> writes: > David Steuber <da...@da...> writes: > >> I gather the NIL response to require was a failure. > > Sorry, this was only because I had required it already in my .sbclrc file. > The same happens when I do not do this (CVS SBCL 0.8.9.36): > > * (require 'asdf) > ("ASDF") > * (require 'asdf-install) > debugger invoked on a SIMPLE-ERROR in thread 11727: > Don't know how to load ASDF-INSTALL This seems to be a symptom either of a misbuild or a misinstall. When you finished the build, it will have printed out something along the lines of "... build finished successfully (including X out of Y contributed modules)." It would be good to know what X and Y were, and if either X or Y is less than 13, why. > 4. Another question to SBCL. Is there an analogue to the > -dynamic-space-size option of CMUCL (and the dropping in the debugger > when this space is exhausted)? In numerical simulations, it is > easy to use a lot of memory, and a graceful exit would be nice. Not at present, to either question (tunable heap size and heap-exhaustion detection). Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Nicolas N. <Nic...@iw...> - 2004-04-15 11:00:45
|
Christophe Rhodes <cs...@ca...> writes: > This seems to be a symptom either of a misbuild or a misinstall. When > you finished the build, it will have printed out something along the > lines of "... build finished successfully (including X out of Y > contributed modules)." It would be good to know what X and Y were, > and if either X or Y is less than 13, why. I don't remember this unfortunately. I'll run it again now. I have used CMUCL for building SBCL. However, I did not run the installation script but linked the asdf and asdf-install directories to sbcl/output (from where I use sbcl.core). (BTW: How long does a build with CLISP take?) > > 4. Another question to SBCL. Is there an analogue to the > > -dynamic-space-size option of CMUCL (and the dropping in the debugger > > when this space is exhausted)? In numerical simulations, it is > > easy to use a lot of memory, and a graceful exit would be nice. > > Not at present, to either question (tunable heap size and > heap-exhaustion detection). I do not yet understand where the difficulty lies. Isn't it rather easy and natural to keep track of the size of this space and to drop into the debugger when a certain threshold is passed? Thanks for the answer (also to Brian), Nicolas. |
From: Daniel B. <da...@te...> - 2004-04-15 11:19:42
|
Nicolas Neuss <Nic...@iw...> writes: >> Not at present, to either question (tunable heap size and >> heap-exhaustion detection). > > I do not yet understand where the difficulty lies. Isn't it rather easy > and natural to keep track of the size of this space and to drop into the > debugger when a certain threshold is passed? It is? Cool! Please send patch as unified diff; they're easier to read than context diffs. -dan -- "please make sure that the person is your friend before you confirm" |
From: Nicolas N. <Nic...@iw...> - 2004-04-15 12:09:46
|
Daniel Barlow <da...@te...> writes: > Nicolas Neuss <Nic...@iw...> writes: > > > I do not yet understand where the difficulty lies. Isn't it rather easy > > and natural to keep track of the size of this space and to drop into the > > debugger when a certain threshold is passed? > > It is? Cool! Please send patch as unified diff; they're easier to > read than context diffs. My naive imagination of memory management would be that space is allocated from the OS in larger chunks, and that it should be easy and efficient to keep track of the total size. If more memory is asked for I would first try GC and then throw an error. But I translate your message to mean that the problem is more intricate and that its difficulty cannot be explained in a few words. Nicolas. |
From: Christophe R. <cs...@ca...> - 2004-04-15 12:15:10
|
Nicolas Neuss <Nic...@iw...> writes: > Christophe Rhodes <cs...@ca...> writes: > >> This seems to be a symptom either of a misbuild or a misinstall. When >> you finished the build, it will have printed out something along the >> lines of "... build finished successfully (including X out of Y >> contributed modules)." It would be good to know what X and Y were, >> and if either X or Y is less than 13, why. > > I don't remember this unfortunately. I'll run it again now. I have used > CMUCL for building SBCL. However, I did not run the installation script > but linked the asdf and asdf-install directories to sbcl/output (from where > I use sbcl.core). Oh, right, so you're running it from the build tree? In that case, what might work is SBCL_HOME=`pwd`/contrib ./src/runtime/sbcl --core output/sbcl.core from the build tree's top-level directory. > (BTW: How long does a build with CLISP take?) Much longer than with cmucl. >> > 4. Another question to SBCL. Is there an analogue to the >> > -dynamic-space-size option of CMUCL (and the dropping in the debugger >> > when this space is exhausted)? In numerical simulations, it is >> > easy to use a lot of memory, and a graceful exit would be nice. >> >> Not at present, to either question (tunable heap size and >> heap-exhaustion detection). > > I do not yet understand where the difficulty lies. Isn't it rather easy > and natural to keep track of the size of this space and to drop into the > debugger when a certain threshold is passed? I'm sure (speaking from a position of relative ignorance, mind you) that you're right, that it's fairly easy, but there are probably some difficult decisions nonetheless: firstly, entering into the debugger can require allocation of memory; secondly, the debugger allows running of arbitrary user code, which can allocate memory. That said, I'd welcome any patch implementing even mildly useful behaviour for this condition. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Nicolas N. <Nic...@iw...> - 2004-04-15 13:02:57
|
Christophe Rhodes <cs...@ca...> writes: > In that case, what might work is > SBCL_HOME=`pwd`/contrib ./src/runtime/sbcl --core output/sbcl.core > from the build tree's top-level directory. Works fine, thank you. Maybe this option should be mentioned in the INSTALL file? > > I do not yet understand where the difficulty lies. Isn't it rather > > easy and natural to keep track of the size of this space and to drop > > into the debugger when a certain threshold is passed? > > I'm sure (speaking from a position of relative ignorance, mind you) that > you're right, that it's fairly easy, but there are probably some > difficult decisions nonetheless: firstly, entering into the debugger can > require allocation of memory; secondly, the debugger allows running of > arbitrary user code, which can allocate memory. That said, I'd welcome > any patch implementing even mildly useful behaviour for this condition. Of course, my ignorance is much larger than yours. I have looked briefly at the C runtime and could not even find out with certainty where the really decisive malloc is done. So I'm sorry, I can't provide this patch... :-) Yours, Nicolas. |