> trivial utilities for interactive use from the shell command-line with an "instantaneous" feel
Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers.
Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers.
With Debian it should work out of the box, on other distributions it probably needs to register a wrapper/trampoline with the binfmt_misc infrastructure.
FWIK running instances don't share the same core in RAM though.
$ cat hello-world.lisp /tmp
(print "Hello. World!")
$ sbcl --noinform /tmp
* (compile-file "hello-world.lisp" :output-file "hello-world")
; compiling file "/tmp/hello-world.lisp" (written 23 AUG 2017 11:09:24 AM):
; compiling (PRINT "Hello. World!")
; /tmp/hello-world.fasl written
; compilation finished in 0:00:00.001
#P"/tmp/hello-world.fasl"
NIL
NIL
* %
$ chmod +x ./hello-world.fasl /tmp
$ ls -lh hello-world.fasl /tmp
-rwxr-xr-x 1 user user 330 Aug 23 11:17 hello-world.fasl*
$ time ./hello-world.fasl /tmp
"Hello. World!" ./hello-world.fasl 0.00s user 0.00s system 44% cpu 0.009 total
$ /tmp
You need to consider that Common Lisp includes a runtime, and this is a essential part of the goods of Common Lisp. Whenever you create a Common Lisp program, you also "embed" the runtime, and the runtime allows you to do wonderful stuff within the running code, like for example, compile code on the fly, replace function with new version (while the program is running), replace class instances with new versions of the class (while the program is running), all sorts of enforcements of the required data type for actual data* (while the program is running),
and,
it has the wonderful "conditions/restart" system. The combination of the latter with all the former, allows you to 'correct' or 'patch' a running program without really needing to recompile the whole program or even restart the running program. Famous story of usage of this feature is using it to patch a bug on the Common Lisp program for the autopilot of the NASA Deep Space One spaceship. The NASA engineers were able to debug and then fix the program while having the DS1 in space with the code running.
So, the FASL (fast load) file is basically similar to the memory file created whenever you put a laptop into "hibernation" mode; it allows you to quickly load the whole runtime, plus your code, *plus the instances of your objects or data, if needed, just straight into memory. This is how "fast load" is achieved.
Actual RAM usage of Lisp will vary with implementations; again, as I mentioned in another post, you pick the implementation that suits your particular needs.
Lots of other people do this without massive executables to distribute, though. CLs are inconsistent on how they can distribute base images and executables. For example, Java's compiler is a code segment you an link in if you want to carry it with you.
There is only one Common Lisp, the 1994 ANSI Standard.
There are many implementations and they give you diverse options of delivering. For example if you want good options to package an executable, I think LispWorks has lots of options for specifically this need.
> For example if you want good options to package an executable, I think LispWorks has lots of features.
It had 2 alternatives. I know, because I shipped some stuff to prod for Powerset on LW back in like 2009? We ultimately stopped using it precisely because we shipped less bytes more quickly with Java and Ruby.
> As for Java, to execute a Java class you need a JRE (java runtime environment), which is not small at all, so I am not sure if it gives you a big advantage.
I'm surprised to hear you say this, but in the interests of completeness I'll give you a handy way to compute the difference in bytes saved.
(defun bytes-saved (num-deploys stdenv-size)
(* (-1 num-deploys) stdenv-size))
This requirement is even more important in the world of diverse deployment techniques that expect modularized executables as a space and performance optimization. Docker, Nim, deployments around FreeBSD jails, and even package managers have dramatically improved performance if you can offer that kind of segmentation.
http://www.oracle.com/technetwork/java/javase/windows-disksp...
ONE installation is inevitable. It's that very few CL-offering environments give you anything better than an image.
$ cat > hello-world.lisp
(defun main () (format t "Hello, World!~%"))
$ sbcl
* (load "hello-world.lisp")
T
* (save-lisp-and-die "hello-world" :toplevel #'main :executable t)
[undoing binding stack and other enclosing state... done]
[defragmenting immobile space... 1110+19908+28500+22601 objects... done]
[saving current Lisp image into hello-world:
writing 4816 bytes from the read-only space at 0x20000000
writing 2320 bytes from the static space at 0x20100000
writing 2383872 bytes from the immobile space at 0x20300000
writing 15190112 bytes from the immobile space at 0x21b00000
writing 39911424 bytes from the dynamic space at 0x1000000000
done]
$ ./hello-world
Hello, World!
$ ls -lh hello-world
-rwxr-xr-x 1 user user 56M Aug 23 10:23 hello-worldI wrote TXR to basically be the "acceptable {awk, perl, ruby, Python, ...}" for Lisp-minded people. Well, for me, that is; but anyone else too.
I have experience deploying with Clozure on Windows. The raw memory images are large-ish, but they compress extremely well into the installer (such as NSIS). I think there is a lot of wasted space in there. Lisp images are not unlike Unix core dumps in may respects. It's similar to checkpointing a process to disk. There is a time versus speed tradeoff there; if you compress it, then you can't just map it into memory as-is.