From: Miles E. <mi...@ca...> - 2003-10-25 23:17:59
|
Deploying sbcl programs is a bit of a hassle at the moment. I have to bootstrap all my apps from a shell script, which seems clunky. sb-executable seems pretty clunky too. It would be great if I could just do: #!/usr/bin/sbcl (format t "Hello World!~%") And have it work. After toying around with the toplevel-init stuff it looks like all it would take to make this work is the following: 1. Define #! as a new dispatch macro that just discards up to end of line. 2. Adjust toplevel-init to check to see if there's an argument left after option processing and (load) it if so, instead of passing it on as a program argument. I guess the downside of doing this is that programs that rely on the current behavior to pass command-line arguments. Perhaps the impact of this could be minimized by specifying that the special "--" argument means that all following arguments are to be passed on as before? Another side benefit of this is that "sbcl foo.lisp" loads and runs foo.lisp, which is what anybody coming from a perl/python/ruby etc background is going to expect. Any opinions? I'd be happy to take a stab at a patch if people don't think this is too drastic. miles |
From: Marco A. <ma...@cs...> - 2003-10-26 17:59:21
|
Miles Egan wrote: > Deploying sbcl programs is a bit of a hassle at the moment. I have to > bootstrap all my apps from a shell script, which seems clunky. > sb-executable seems pretty clunky too. > > It would be great if I could just do: > > #!/usr/bin/sbcl > (format t "Hello World!~%") > > And have it work. > > After toying around with the toplevel-init stuff it looks like all it > would take to make this work is the following: > > 1. Define #! as a new dispatch macro that just discards up to end of > line. Wasn't there some code around for CMUCL (or was it CLisp) that defined #! /usr/bin/lisp-program !# to do just that? If I remeber correctly, this would allow you to have more complex argument passing to to lisp program. Cheers -- Marco |
From: Miles E. <mi...@ca...> - 2003-10-27 16:09:22
|
On Sun, 2003-10-26 at 09:57, Marco Antoniotti wrote: > Wasn't there some code around for CMUCL (or was it CLisp) that defined >=20 > #! /usr/bin/lisp-program !# >=20 > to do just that? >=20 > If I remeber correctly, this would allow you to have more complex=20 > argument passing to to lisp program. How did this work? Did it define a new global #! read macro or did it do something slightly more sophisticated? --=20 Miles Egan <mi...@ca...> |
From: Eric M. <ema...@la...> - 2003-10-27 17:55:35
|
>>>>> "ma" == Marco Antoniotti <ma...@cs...> writes: ma> Wasn't there some code around for CMUCL (or was it CLisp) that defined ma> ma> #! /usr/bin/lisp-program !# ma> ma> to do just that? ma> ma> If I remeber correctly, this would allow you to have more complex ma> argument passing to to lisp program. I wrote (or rather adapted from something written by Olin Shivers) a trampoline program that makes this possible for CMUCL. There are comments in the file that explain how it works. The actual syntax is ,---- | #!/usr/bin/cmucl-trampoline \ | -quiet -batch -noinit | #! | | (format t "Hello world~%") `---- <URL:http://www.chez.com/emarsden/downloads/cmucl-trampoline.c> -- Eric Marsden <URL:http://www.laas.fr/~emarsden/> |
From: Christophe R. <cs...@ca...> - 2003-10-26 18:54:56
|
Miles Egan <mi...@ca...> writes: > Deploying sbcl programs is a bit of a hassle at the moment. I have to > bootstrap all my apps from a shell script, which seems clunky. > sb-executable seems pretty clunky too. Can you elaborate on the problems with sb-executable? Sure, it's a hack, but you should only have to do it once, right? > It would be great if I could just do: > > #!/usr/bin/sbcl > (format t "Hello World!~%") > > And have it work. > > After toying around with the toplevel-init stuff it looks like all it > would take to make this work is the following: > > 1. Define #! as a new dispatch macro that just discards up to end of > line. > > 2. Adjust toplevel-init to check to see if there's an argument left > after option processing and (load) it if so, instead of passing it on > as a program argument. OK, well, here's the thing. ANSI specifically frees #! as a readmacro that is free for the user; the implementation is not allowed to define it by default. So we're never going to get to your state of grace as above. On the other hand, the two issues above could be solved in one go; something like #! /usr/bin/sbcl --script might work, where --script is syntactic sugar for "set up #! readmacro then load the argument as a file". > I guess the downside of doing this is that programs that rely on the > current behavior to pass command-line arguments. Perhaps the impact > of this could be minimized by specifying that the special "--" > argument means that all following arguments are to be passed on as > before? > > Another side benefit of this is that "sbcl foo.lisp" loads and runs > foo.lisp, which is what anybody coming from a perl/python/ruby etc > background is going to expect. I'm not convinced that encouraging this is that great an idea, on the dual basis that firstly, lisp's strength isn't in unattended mode, and on the other hand, "sbcl <foo.lisp" already works as in other scripting languages. > Any opinions? I'd be happy to take a stab at a patch if people don't > think this is too drastic. I hope this doesn't pour too much cold water on your enthusiasm. :-) 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: Ingvar <in...@ca...> - 2003-05-28 12:18:01
|
> Ingvar <in...@ca...> writes: > > > And now with "diff -u" patch-file. > > +(defmacro compiler-note-conditional (note-type format-string &rest format-args) > > + `(progn (unless (or ,@(loop for sym in note-type collect (list 'member sym '*ignore-compiler-note-class-list*))) > > + (compiler-note ,format-string ,@format-args)) > > + (values))) > > + > > > - (compiler-note > > + (compiler-note-conditional '(:return) This one will. > > - (give-up-ir1-transform "BOOLE code is not a constant.")) > > + (give-up-ir1-transform '(:boole :no-inline) "BOOLE code is not a constant.")) This one won't. > Here's a good argument for more type-checking: those QUOTEs, if I'm not > mistaken, are going to cause a problem. :-) The ones in calls to COMPILER-NOTE-CONDITIONAL (it's a macro, so...). > OK, I think this is a good start. However, I think I would rather see > something that uses the condition system. The comment above > COMPILER-NOTE says that it used to signal conditions; however, in the > process of modernising the code, that was removed, basically because > in SBCL a compiler note really is a note, not a STYLE-WARNING. I > think it ought to be possible to reintroduce conditions for compiler > notes, with a hierarchy that looks something like > CONDITION > COMPILER-NOTE > SIMPLE-COMPILER-NOTE (mixin: SIMPLE-CONDITION, for uncategorized) > FAILED-INLINE > ... That would probably make sense. Having a slot for "what type of note is this" and then selectively ignore issuing notes on that (or possibly re-signal and do nothing if not caught). the main reason I went with (initially) instrumenting COMPILER-NOTE calls was to modify the code as little as possible. Alas, it would probably have benefited from the experimentation I did after having found so few calls to COMPILEr-NOTE being done before introducing COMPILER-NOTE-CONDITIONAL. It did give me an idea of rioughly how I wanted things, so I guess it's OK in the long run. > Then you can get the effect of your patch by having an outer handler, > discarding the condition based on its type (and a special variable, > say *ignored-note-types*); but also user code can handle these beasts > selectively, maybe with a declaration interface to quieten the > compiler... > > Does that make any sense? I suppose the thing that using the > condition system buys us is a little more power for reflection. Yup. Introspection and reflection is good. The big workload is probably going to be adding suitable typing to the existing messages anyhow. //Ingvar |
From: Ingvar <in...@ca...> - 2003-10-26 19:34:43
|
> Miles Egan <mi...@ca...> writes: > > > Deploying sbcl programs is a bit of a hassle at the moment. I have to > > bootstrap all my apps from a shell script, which seems clunky. > > sb-executable seems pretty clunky too. > > Can you elaborate on the problems with sb-executable? Sure, it's a > hack, but you should only have to do it once, right? Plus "bootstrapping from a shell script" has a long and arguably non-dishonourable tradition in the unix world. At least Netscape of old started that way and similar for Acrobat Reader in some versions. > > It would be great if I could just do: > > > > #!/usr/bin/sbcl > > (format t "Hello World!~%") > > > > And have it work. > > > > After toying around with the toplevel-init stuff it looks like all it > > would take to make this work is the following: > > > > 1. Define #! as a new dispatch macro that just discards up to end of > > line. > > > > 2. Adjust toplevel-init to check to see if there's an argument left > > after option processing and (load) it if so, instead of passing it on > > as a program argument. > > OK, well, here's the thing. ANSI specifically frees #! as a readmacro > that is free for the user; the implementation is not allowed to define > it by default. So we're never going to get to your state of grace as > above. On the other hand, the two issues above could be solved in one > go; something like > > #! /usr/bin/sbcl --script > > might work, where --script is syntactic sugar for "set up #! > readmacro then load the argument as a file". Plus that the #! "magic" in exec is explicity tuned to allow "one optional argument and one only" (this means that "#! /usr/bin/sbcl --script" OR "#! /usr/bin/env sbcl" (the extra argument tacked on will be eth path to the file that has the #! magic in it). //Ingvar |
From: Brian M. <bma...@cs...> - 2003-10-26 21:15:22
|
>> OK, well, here's the thing. ANSI specifically frees #! as a readmacro >> that is free for the user; the implementation is not allowed to define >> it by default. So we're never going to get to your state of grace as >> above. On the other hand, the two issues above could be solved in one >> go; something like >> >> #! /usr/bin/sbcl --script >> >> might work, where --script is syntactic sugar for "set up #! >> readmacro then load the argument as a file". > > Plus that the #! "magic" in exec is explicity tuned to allow "one > optional > argument and one only" (this means that "#! /usr/bin/sbcl --script" OR > "#! /usr/bin/env sbcl" (the extra argument tacked on will be eth path > to the > file that has the #! magic in it). Whoops, forgot to hit "reply to all" on that last one. Since this readmacro will only ever be used once, why not have it uninstall itself then? That way programs which do use #! as a readmacro will still work as expected. -- Brian Mastenbrook bma...@cs... http://cs.indiana.edu/~bmastenb/ |
From: Pascal J.B. <pj...@in...> - 2003-10-27 05:22:41
|
Christophe Rhodes writes: > Miles Egan <mi...@ca...> writes: > > It would be great if I could just do: > > > > #!/usr/bin/sbcl > > (format t "Hello World!~%") > > > > And have it work. In any case, sbcl is so slow to start up, you shoud rather use clisp, even with -C: $ time sbcl --eval '(quit)' ; in: LAMBDA NIL ; (SB-KERNEL:FLOAT-WAIT) ; ; note: deleting unreachable code ; compilation unit finished ; printed 1 note real 0m12.463s user 0m10.630s sys 0m0.280s $ time clisp -C -x '(ext:quit)' ;; Loading file /home/pascal/.clisprc.lisp ... ;; Loaded file /home/pascal/.clisprc.lisp real 0m0.188s user 0m0.110s sys 0m0.030s (Note that both my .clisp.lisp and my .sbclrc load the same .common.lisp, so the initialization is about the same, but for a couple of forms). Granted, if you start it without any init file, it's faster, but if you're using lisp, I assume it's because you have scripts more complicated than what could be done with two lines of sh, so you'll probably include external packages... $ time sbcl --noinform --sysinit /dev/null --userinit /dev/null --eval '(quit)' real 0m0.043s user 0m0.020s sys 0m0.000s $ time /usr/local/bin/clisp -q -ansi -norc -x '(ext:quit)' real 0m0.419s user 0m0.010s sys 0m0.020s -- __Pascal_Bourguignon__ http://www.informatimago.com/ |
From: Brian M. <bma...@cs...> - 2003-10-27 06:22:55
|
> In any case, sbcl is so slow to start up, you shoud rather use clisp, > even with -C: Did you bother to check what list you were posting this to? > (Note that both my .clisp.lisp and my .sbclrc load the same > .common.lisp, so the initialization is about the same, but for a > couple of forms). Maybe there's a slight difference between the amount of work done by clisp -C and the amount of work done by SBCL when reading and compiling a file. > Granted, if you start it without any init file, it's faster, but if > you're using lisp, I assume it's because you have scripts more > complicated than what could be done with two lines of sh, so you'll > probably include external packages... Chances are you'll want to include said packages from the script instead of your user init file anyway. My SBCL user init sets up sb-aclrepl and linedit. I sure don't need that in shell scripts. Have you considered compiling your initialization files too? > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ How does a donation program sponsor something? -- Brian Mastenbrook bma...@cs... http://cs.indiana.edu/~bmastenb/ |
From: Kevin R. <ke...@ro...> - 2003-10-27 16:38:32
|
Brian Mastenbrook wrote: > Maybe there's a slight difference between the amount of work done by=20 > clisp -C and the amount of work done by SBCL when reading and compiling= =20 > a file. There's a marked difference in compilation speed between clisp and sbcl. My SBCL start-up time is quite rapid -- on the order of clisp's -- since my start-up file loads fasls of library files [though it will compile them if the source file has a later modification date than the corresponding fasl.] =20 (load-maybe-compile-relative-klisp '("kboot") "utils") #-asdf=20 (load-maybe-compile-relative-klisp '("kboot" "lib") "asdf") #-mk-defsystem (load-maybe-compile-relative-klisp '("kboot" "lib") "defsystem") (load-maybe-compile-relative-klisp '("kboot") "systems") #-common-lisp-controller=20 (load-maybe-compile-relative-klisp '("kboot") "non-clc") Starting up my SBCL which includes loading several such compiled support files is quick: kevin@pal:~> time sbcl --eval '(quit)'=20 This is SBCL 0.8.5, an implementation of ANSI Common Lisp. =20 [...] <http://sbcl.sourceforge.net/>. =20 real 0m0.503s user 0m0.469s > Chances are you'll want to include said packages from the script=20 > instead of your user init file anyway. My SBCL user init sets up=20 > sb-aclrepl and linedit. I sure don't need that in shell scripts. Have=20 > you considered compiling your initialization files too? For vcs-tree which is created by sb-executable and which doesn't load my standard support files, startup time is even quicker: kevin@pal:~> time vcs-tree usage: vcs-tree action [OPTIONS] Processes a source-control managed directory tree Action: update, commit, or status OPTIONS -m <str> Set commit string =20 real 0m0.047s user 0m0.037s I don't have any complaints about SBCL startup time. I suppose using a system much slower than the one I used for the above tests [Athlon 64 FX-51] would be cause me to notice SBCL's start-up time. However, I'd have other performance issues besides SBCL on such a system. --=20 Kevin Rosenberg ke...@ro... |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2003-10-27 16:38:36
|
Pascal J.Bourguignon writes: > > In any case, sbcl is so slow to start up, you shoud rather use clisp, > even with -C: *cough* just for the record: [tfb@Cannon]~$ uname -a Darwin Cannon.local. 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Power Macintosh powerpc [tfb@Cannon]~$ time sbcl --eval '(quit)' This is SBCL 0.8.4, an implementation of ANSI Common Lisp. ... real 0m0.162s user 0m0.030s sys 0m0.090s -- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----' |
From: Raffael C. <raf...@ma...> - 2003-10-27 20:44:11
|
On Oct 27, 2003, at 11:33 AM, Thomas F. Burdick wrote: > Pascal J.Bourguignon writes: >> >> In any case, sbcl is so slow to start up, you shoud rather use clisp, >> even with -C: > > *cough* just for the record: > > [tfb@Cannon]~$ uname -a > Darwin Cannon.local. 6.8 Darwin Kernel Version 6.8: Wed Sep 10 > 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Power > Macintosh powerpc > [tfb@Cannon]~$ time sbcl --eval '(quit)' > This is SBCL 0.8.4, an implementation of ANSI Common Lisp. > ... > real 0m0.162s > user 0m0.030s > sys 0m0.090s Similar times under Darwin 7.0/Panther for sbcl 0.8.5: raffaelc% uname -a Darwin Kernel Version 7.0.0: Wed Sep 24 15:48:39 PDT 2003; root:xnu/xnu-517.obj~1/RELEASE_PPC Power Macintosh powerpc raffaelc% time sbcl --eval '(quit)' This is SBCL 0.8.5, an implementation of ANSI Common Lisp. [snip] More information about SBCL is available at <http://sbcl.sourceforge.net/>. 0.010u 0.050s 0:00.07 114.2% 0+0k 0+0io 0pf+0w Less than a tenth of a second is essentially instantaneous for most purposes. BTW, openmcl shows almost identical timings on this setup: raffaelc% time openmcl --eval '(quit)' 0.010u 0.070s 0:00.07 114.2% 0+0k 0+0io 0pf+0w On a different note, I find that the latest sbcl (0.8.5) is about twice as fast as the latest openmcl (0.14-031018) at executing floating point, array, integer, and list manipulation/consing benchmarks. The openmcl compiler still runs a bit faster though. Raf Raffael Cavallaro, Ph.D. raf...@ma... |
From: Daniel B. <da...@te...> - 2003-10-27 06:03:02
|
Ingvar <in...@ca...> writes: > Plus that the #! "magic" in exec is explicity tuned to allow "one optiona= l=20 > argument and one only" (this means that "#! /usr/bin/sbcl --script" OR=20 > "#! /usr/bin/env sbcl" (the extra argument tacked on will be eth path to = the=20 > file that has the #! magic in it). For anyone wondering what Ingvar is referring to here, the perlrun(1) manual page has a pretty good guide to the grottier aspects of #! support in various unixlike systems. Is it worth my mentioning that O'Caml (last time I looked, at least, which was admittedly a few years ago) does something very similar to the sb-executable kludge? As others have remarked, i think the real improvement that would enable SBCL shell scripting to become reasonable would be an improvement in fasl loading speed. My suspicion is that this probably involves a new fasl format that looks more like an object file and less like a bytecoded forth machine, but I'd be happy to be proved wrong on that one ;-) =2Ddan =2D-=20 http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro |
From: Miles E. <mi...@ca...> - 2003-10-27 16:08:06
|
On Sun, 2003-10-26 at 22:03, Daniel Barlow wrote: > Is it worth my mentioning that O'Caml (last time I looked, at least, > which was admittedly a few years ago) does something very similar to > the sb-executable kludge? OCaml does this for bytecode executables. OCaml native-code executables are real honest-to-goodness standalone ELF binaries. That's one of the things OCaml really does well, IMHO. It would be very cool if it were possible to use SBCL to build real ELF binaries too. I poked around with a few approaches to this over the weekend. It doesn't seem like it would be too hard to tack an core file onto the end of a little c-kernel bootstrapper and just load the core from the end of that kernel. Good elf docs seem to be a little hard to find though. > As others have remarked, i think the real improvement that would > enable SBCL shell scripting to become reasonable would be an > improvement in fasl loading speed. My suspicion is that this probably > involves a new fasl format that looks more like an object file and > less like a bytecoded forth machine, but I'd be happy to be proved > wrong on that one ;-) Is this assuming that most scripts are going to want to load big libraries like cl-ppcre or the like? Otherwise it doesn't seem like fasl performance would make much difference because, presumably, lisp scripts will always be loaded as sounce. --=20 Miles Egan <mi...@ca...> |
From: Miles E. <mi...@ca...> - 2003-10-27 16:04:12
|
On Sun, 2003-10-26 at 10:50, Christophe Rhodes wrote: > Can you elaborate on the problems with sb-executable? Sure, it's a > hack, but you should only have to do it once, right? Actually, I think sb-executable is ok for what it is, but it's not very helpful for lisp scripts because I have to compile and rebuild the "executable" every time I make a change to the code it runs. > OK, well, here's the thing. ANSI specifically frees #! as a readmacro > that is free for the user; the implementation is not allowed to define > it by default. So we're never going to get to your state of grace as > above. On the other hand, the two issues above could be solved in one > go; something like >=20 > #! /usr/bin/sbcl --script >=20 > might work, where --script is syntactic sugar for "set up #! > readmacro then load the argument as a file". This would be fine. The only minor downside of this is that I usually like to do: #!/usr/bin/env interpreter Which works with multiple installations of the interpreter and switches among them by $PATH. Still, --script seems like a pretty reasonable compromise between ANSI compliance and script-friendliness. --=20 Miles Egan <mi...@ca...> |
From: Jon B. <jo...@bu...> - 2004-09-14 14:44:51
|
Christophe Rhodes wrote: > "Jon Buller" <jo...@bu...> writes: > > > My cross compile from NetBSD/x86 is from the wiki page, and > > it mentions that things changed in 0.7.13.5 to use genesis. Is > > the correct build procedure still: > > > > 1) set SBCL_ARCH and SBCL_XC_HOST on the x86 machine > > 2) make-config.sh on sparc > > 3) make-host-1.sh on x86 > > 4) set GNUMAKE on sparc > > 5) make-target-1.sh on sparc > > 6) make-host-2.sh on x86 (assuming I can get past #5) > > 7) make-target-2.sh on sparc (assuming #6 works too...) > > Are your source trees shared (e.g. over NFS) or separate? Well, I tried the seperate version of the wiki instructions, but the change note said copy genesis/* instead of sbcl.h, etc. I tried some of that, but it didn't work too well, so now I just tar up the whole thing and scp it across. (Short answer, shared, but not over NFS or anything "normal" 8^) Jon |
From: Jon B. <jo...@bu...> - 2005-07-11 15:08:16
|
Christophe Rhodes wrote: > "All tests should pass on x86/Linux, x86/FreeBSD4, and ppc/Darwin" > except of course that in an ideal world the tests would pass without > some of them being conditionalized out... One point that you may not have seen go by... I created a package for the NetBSD package system, so everytime they do a bulk build of their packages, SBCL will be built on NetBSD/i386. They just got hardware from Sun to run bulk builds on Solaris, and their package system runs on other systems as well, including Darwin. Right now, the package will only build on NetBSD/i386, using CLisp to host it, unless you comment out the CLisp host line and uncomment the SBCL one in the Makefile. 8^) (It made the package build dependencies a lot easier to deal with that way.) I've tried to get SBCL working on my NetBSD/Sparcstation 20, but without luck so far. I think I have the memory map messed up. That's all the hardware I have to develop with, but if someone wants to figure out how to get that SBCL package building on other places where SBCL runs (both machines and OSs), I'll commit the changes. It might be as simple as adding a new OS to the ONLY_FOR_PLATFORM list in the makefile. Jon |
From: Miles E. <mi...@ca...> - 2003-10-27 16:02:17
|
On Sun, 2003-10-26 at 21:21, Pascal J.Bourguignon wrote: > Christophe Rhodes writes: > > Miles Egan <mi...@ca...> writes: > > > It would be great if I could just do: > > > > > > #!/usr/bin/sbcl > > > (format t "Hello World!~%") > > > > > > And have it work. >=20 > In any case, sbcl is so slow to start up, you shoud rather use clisp, > even with -C: sbcl starts plenty fast on my system if all it has to do is load a core. What I'd like to do is build a "scripting" core with all the right stuff (cl-ppcre etc) pre-loaded and then use that to run lisp scripts. --=20 Miles Egan <mi...@ca...> |
From: Pascal J.B. <pj...@in...> - 2003-10-27 21:02:22
|
Miles Egan writes: > On Sun, 2003-10-26 at 21:21, Pascal J.Bourguignon wrote: > > Christophe Rhodes writes: > > > Miles Egan <mi...@ca...> writes: > > > > It would be great if I could just do: > > > > > > > > #!/usr/bin/sbcl > > > > (format t "Hello World!~%") > > > > > > > > And have it work. > > > > In any case, sbcl is so slow to start up, you shoud rather use clisp, > > even with -C: > > sbcl starts plenty fast on my system if all it has to do is load a > core. What I'd like to do is build a "scripting" core with all the > right stuff (cl-ppcre etc) pre-loaded and then use that to run lisp > scripts. Oh! I didn't think about that, we can indeed pre-compile a specialized core... Thanks. -- __Pascal_Bourguignon__ http://www.informatimago.com/ |
From: Miles E. <mi...@ca...> - 2003-10-27 16:11:41
|
On Sat, 2003-10-25 at 17:46, Nikodemus Siivola wrote: > On Sat, Oct 25, 2003 at 04:17:01PM -0700, Miles Egan wrote: >=20 > > #!/usr/bin/sbcl > > (format t "Hello World!~%") >=20 > I'm all for making lisp friendlier to newbies, but they should also be > thought relatively soon that lisp *is* different. I don't think any extra effort on our part is necessary to get that point across. :) > A datapoint: I think I gave up on CL for a month or two due to wierd > command-line behaviour, and returned after I discovered that clisp > handled #! from the box. I stuck with clisp for a long time for similar reasons. I finally switched to sbcl because it seemed like so much more of the really hard work of building a good lisp compiler had been done in sbcl/cmucl. > What about keeping the runtime as is, but including a run-sbcl script > along the lines: >=20 > #!/bin/sh > exec sbcl ... --eval '(sb-ext:enable-shebang-comments)' --load $@ I guess I can't find any real technical problems with it, but it does offend the perfectionist in me. ;) --=20 Miles Egan <mi...@ca...> |