From: <em...@te...> - 2006-03-13 12:16:46
|
A somewhat shalow google search doesnt give back anything obvious, but at the same time it is hard to believe that something like this has not been noticed previously. The following transcript is from a FreeBSD machine. Windows exhibits the same behaviour. $ set | grep SBCL SBCL_HOME=/usr/local/lib/sbcl $ whereis sbcl sbcl: /usr/local/bin/sbcl /usr/local/man/man1/sbcl.1.gz /usr/ports/lang/sbcl $ sbcl --userinit /dev/null This is SBCL 0.9.5, an implementation of ANSI Common Lisp. [...] * (quit) $ /opt/bin/sbcl --core /opt/lib/sbcl/sbcl.core --userinit /dev/null This is SBCL 0.9.4.44, an implementation of ANSI Common Lisp. [...] * (quit) $ /opt/bin/sbcl --userinit /dev/null --core /opt/lib/sbcl/sbcl.core This is SBCL 0.9.4.44, an implementation of ANSI Common Lisp. [...] fatal error encountered in SBCL pid 75930: can't load .core for different runtime, sorry The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. Best regards, -- Eduardo Muñoz | (prog () 10 (print "Hello world!") http://www.boundp.net/ | 20 (go 10)) |
From: Juho S. <js...@ik...> - 2006-03-13 12:31:33
|
<em...@te...> wrote: > A somewhat shalow google search doesnt give back anything > obvious, but at the same time it is hard to believe that > something like this has not been noticed previously. Please have a look at the "Command Line Options" chapter in the SBCL manual. --core is a runtime option, and must thus come before all toplevel options (like --userinit). -- Juho Snellman |
From: <em...@te...> - 2006-03-13 15:18:43
|
* Juho Snellman <js...@ik...> | <em...@te...> wrote: | > A somewhat shalow google search doesnt give back anything | > obvious, but at the same time it is hard to believe that | > something like this has not been noticed previously. | | Please have a look at the "Command Line Options" chapter in the SBCL | manual. --core is a runtime option, and must thus come before all | toplevel options (like --userinit). Ah, thanks for pointing me in the right direction. The separation betwen runtime and toplevel options does not seem intuitive at first but is suppose there is a rationale behind it (so the runtime doesnt have to parse --eval options for example). Regards, -- Eduardo Muñoz | (prog () 10 (print "Hello world!") http://www.boundp.net/ | 20 (go 10)) |
From: Nikodemus S. <nik...@ra...> - 2006-03-13 12:41:51
|
Yes. http://www.sbcl.org/manual/Command-Line-Options.html#Command-Line-Options --core is a runtime option. --userinit is a toplevel option. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." . |
From: Christophe R. <cs...@ca...> - 2006-03-13 12:47:09
|
Eduardo Mu=F1oz <em...@te...> writes: > A somewhat shalow google search doesnt give back anything > obvious, but at the same time it is hard to believe that > something like this has not been noticed previously. > The following transcript is from a FreeBSD machine. Windows > exhibits the same behaviour. This is documented in the manual page: the order of arguments is significant. See the section "COMMAND LINE SYNTAX". Cheers, Christophe |