4 ms·

I tried experimenting with Common LISP but never understood how one was supposed to deploy a finished binary to the end user. It seemed like you were supposed t

I tried experimenting with Common LISP but never understood how one was supposed to deploy a finished binary to the end user. It seemed like you were supposed to load up an environment? It made me leery of continuing.

aidenn0 5y ago
For most common-lisp implementations you can just save the current state as an executable, along with specifying an entry-point. Obviously doing this from your dev environment is a bad idea, so most people write a script that loads the system and dumps the image. Or you can use one that someone else has already written. Not all lisps work this way (most notably ECL does not), and you can use ASDF's program-op to create an executable directly from a package definition, which should work on any implemntation supported by ASDF.
- tehjoker 5y ago
  Thanks, the saving the dev environment part was the part that scared me. It certainly helps to have someone tell you you're not crazy. Maybe I'll give it another try sometime!
  - aidenn0 5y ago
    One of the things I've learned with powerful tools is that, by their nature, they empower you to do bad things almost as much as they empower you to do good things. It's even alluded to in the ruby bare-words example in this famous talk[1] 1: https://www.youtube.com/watch?v=3se2-thqf-A https://www.youtube.com/watch?v=3se2-thqf-A
  - foobarbaz33 5y ago
    You can just run make when you are ready to make a clean build and executable. Same as any other language.
  - _ph_ 5y ago
    Nothing to worry about. Yes, the minimal executable you get with SBCL is a bit fat, but for any real-world application which do some actual work, the size is a non-issue. Especially, as the executables are starting up very fast, as no dynamic linking is necessary, most of the code are static references. For any sizable Lisp project you would have an ASDF-file to load the system, with that you can create an easy build-script or even a make-file, which loads your program via ASDF and then builds the executable, it is described well here: https://stackoverflow.com/questions/14171849/compiling-common-lisp-to-an-executable https://stackoverflow.com/questions/14171849/compiling-commo... For consistancy, I would recommend to build the executable from the freshly loaded source, not a lisp image which has been used to develop in.
gibsonf1 5y ago
We have a makefile and: sudo make it creates an executable. Its slightly tricky in that the whole make process can only happen on a single thread, so you have to turn off all parallel threads during make - so we have a key on many functions :make that turns off parallel for using make. Ultimatel the make file uses (asdf:make :package-name) to compile to an exe. The other tricky part is to get a web server in the exe to work, and thats handled like this: (handler-case (bt:join-thread (find-if (lambda (th) #+os-unix (search "clack-handler-woo" (bt:thread-name th)) #+os-windows (search "hunchentoot" (bt:thread-name th)) ) (bt:all-threads))) ;; Catch a user's C-c (#+sbcl sb-sys:interactive-interrupt #+ccl ccl:interrupt-signal-condition #+clisp system::simple-interrupt-condition #+ecl ext:interactive-interrupt #+allegro excl:interrupt-signal () (progn (format *error-output* "Aborting.~&") (stop) (uiop:quit))) (error (c) (progn (format t "Woops, an unknown error occured:~&~a~& - restarting service..." c) #+os-unix (trivial-shell:shell-command "service trinity restart")) ))
vindarel 5y ago
See this recipe: https://lispcookbook.github.io/cl-cookbook/scripting.html https://lispcookbook.github.io/cl-cookbook/scripting.html The core of it is to call "sb-ext:save-lisp-and-die" after you loaded the system, and the portable way across implementations is to use asdf:make, with 2 lines on your system declaration (.asd).

aidenn0 5y ago

For most common-lisp implementations you can just save the current state as an executable, along with specifying an entry-point. Obviously doing this from your dev environment is a bad idea, so most people write a script that loads the system and dumps the image. Or you can use one that someone else has already written. Not all lisps work this way (most notably ECL does not), and you can use ASDF's program-op to create an executable directly from a package definition, which should work on any implemntation supported by ASDF.

tehjoker 5y ago
Thanks, the saving the dev environment part was the part that scared me. It certainly helps to have someone tell you you're not crazy. Maybe I'll give it another try sometime!
- aidenn0 5y ago
  One of the things I've learned with powerful tools is that, by their nature, they empower you to do bad things almost as much as they empower you to do good things. It's even alluded to in the ruby bare-words example in this famous talk[1] 1: https://www.youtube.com/watch?v=3se2-thqf-A https://www.youtube.com/watch?v=3se2-thqf-A
- foobarbaz33 5y ago
  You can just run make when you are ready to make a clean build and executable. Same as any other language.
- _ph_ 5y ago
  Nothing to worry about. Yes, the minimal executable you get with SBCL is a bit fat, but for any real-world application which do some actual work, the size is a non-issue. Especially, as the executables are starting up very fast, as no dynamic linking is necessary, most of the code are static references. For any sizable Lisp project you would have an ASDF-file to load the system, with that you can create an easy build-script or even a make-file, which loads your program via ASDF and then builds the executable, it is described well here: https://stackoverflow.com/questions/14171849/compiling-common-lisp-to-an-executable https://stackoverflow.com/questions/14171849/compiling-commo... For consistancy, I would recommend to build the executable from the freshly loaded source, not a lisp image which has been used to develop in.

gibsonf1 5y ago

We have a makefile and: sudo make it creates an executable. Its slightly tricky in that the whole make process can only happen on a single thread, so you have to turn off all parallel threads during make - so we have a key on many functions :make that turns off parallel for using make. Ultimatel the make file uses (asdf:make :package-name) to compile to an exe. The other tricky part is to get a web server in the exe to work, and thats handled like this: (handler-case (bt:join-thread (find-if (lambda (th) #+os-unix (search "clack-handler-woo" (bt:thread-name th)) #+os-windows (search "hunchentoot" (bt:thread-name th)) ) (bt:all-threads))) ;; Catch a user's C-c (#+sbcl sb-sys:interactive-interrupt #+ccl ccl:interrupt-signal-condition #+clisp system::simple-interrupt-condition #+ecl ext:interactive-interrupt #+allegro excl:interrupt-signal () (progn (format *error-output* "Aborting.~&") (stop) (uiop:quit))) (error (c) (progn (format t "Woops, an unknown error occured:~&~a~& - restarting service..." c) #+os-unix (trivial-shell:shell-command "service trinity restart")) ))

vindarel 5y ago

See this recipe: https://lispcookbook.github.io/cl-cookbook/scripting.html https://lispcookbook.github.io/cl-cookbook/scripting.html The core of it is to call "sb-ext:save-lisp-and-die" after you loaded the system, and the portable way across implementations is to use asdf:make, with 2 lines on your system declaration (.asd).