Compiling to Binary in sbcl

Another newb question, this time in sbcl. Here's my "hello.lisp":

(defun main()
        (print "hello, world!"))

And here's what I run in sbcl:

(load "hello.lisp")
(sb-ext:save-lisp-and-die "my_binary" :executable t :toplevel 'main)

And here's my result at the shell:

$ ./my_binary 

"hello, world!" 
debugger invoked on a TYPE-ERROR in thread #<THREAD "i, have it run and be left alone by sbcl.nitial thread" {1002685FB1}>:
  The value "hello, world!" is not of type (SIGNED-BYTE 32).

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

(SB-UNIX:UNIX-EXIT "hello, world!")

What's going on? All I want to do is compile a program into a binary and have it run uninterpreted. Why it it complaining about type?

The second question is how to make sbcl exit when the program complete, or better yet cut sbcl out of the process and run it on workstations with no lisp environment installed.

SigmaX

SigmaX wrote:All I want to do is compile a program into a binary and have it run uninterpreted.

I know that this meaning of the word "binary" is fairly common, but "compiling to binary" runs into semantic issues due to differences between the general model of most Common Lisps and C, so I would suggest not using it as a phrase. Most significant is that for example in SBCL by default every function is always compiled to native code. You can see the assembly listing of any function by using the standard disassemble function. Saving a core makes no difference about "binariness" or being interpreted or not, it just dumps the memory image to disk with some bookkeeping making it possible to load it back.

SigmaX wrote:What's going on?

What is going on is that UNIXoid systems require each terminating process to return an exit code. If you create a core with a new top level function, this function must return a suitable exit code. Which SBCL claims to be (SIGNED-BYTE 32), though I am not quite sure if negative numbers are actually meaningful. Not that it matters, since the operating system sees only a pattern of bits, as long as there are thirty two of them.

SigmaX wrote:The second question is how to make sbcl exit when the program complete, or better yet cut sbcl out of the process and run it on workstations with no lisp environment installed.

SBCL will quit when the top level function returns (a proper exit code), or when implementation specific function SB-EXT:QUIT is called, optionally with a UNIX-STATUS key parameter specifing the exit code, with 0 being the default. This is explained in the manual.

You can't cut SBCL out of SBCL process. Commercial implementations come with a tree-shaker which allow doing that to some extent, but that has never been a priority for open-source implementations. It is quite hard to bolt-it on anyway, since by now the entirety of compiler is necessary for CLOS to work, and CLOS is tightly integrated into everything, which means that even a fairly trivial program will pull in the entire environment anyway.

Do note that cores saved by SBCL with executable option contain a complete CL environment and require no installation of anything else. Which is why they are quite big.

Thanks for the informative reply.

Ramarren wrote: What is going on is that UNIXoid systems require each terminating process to return an exit code.

Gotcha. Right after I posted I wondered if that's what was going on -- but I ran off to lunch before having a chance to fix it. Solved now.

Do note that cores saved by SBCL with executable option contain a complete CL environment and require no installation of anything else. Which is why they are quite big.

Okay, good -- that's all I really care about, since I want to run this sim on multiple computers, and it's a pain to bug our IT guy to install packages too often. As is SBCL is already giving me a huge performance boost over clisp .

Thanks again,
Siggy