Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

SBCL compilation

Name: Anonymous 2011-12-04 0:26

design process:
HEY LET'S JUST SHOVE EVERYTHING INTO A SINGLE EXECUTABLE!

LOL LOOK AT ALL OF THOSE 40 MB FACTORIAL PROGRAMS

Name: Anonymous 2011-12-04 1:02

Its actually an int"derp"reter packaged inside the program, just like python .exe

Name: Anonymous 2011-12-04 2:07

SBCL is a Lisp-Machine emulator. A QEMU, together with Windows, will take much more than 40 MB.

Name: Anonymous 2011-12-04 2:17

To be fair, any program that uses an eval function will need to have an interpreter bundled with in its executable, or dynamically link with a library that contains the interpreter. But if the program happens to never call eval, then that could be optimized out of the picture. But then that is assuming the developers could actually write a compiler that would translate the high level program to machine code.

Name: Anonymous 2011-12-04 2:33

Are there a way to load FASL from inside a zip archive, without unpacking into separate file? I want to simulate a Smalltalk-like system with JIT, so I store closures as fasl into a zip image. How do I load them back?

Name: Anonymous 2011-12-04 4:52

Name: Anonymous 2011-12-04 5:42

>>6
Your code looks like it is a part of SBCL implementation. Doubt it's very protable even across SBCL versions.

Name: Anonymous 2011-12-04 6:03

>>7
That code isn't mine.

Name: Anonymous 2011-12-04 6:52

>>1
Tree-shake it. Not like most other lisps are much smaller, it's always 8-40MB, depending on what you use and options used.
Major reductions in size should be obtainable if you don't include the compiler and interpreter.
>>2
No, SBCL compiles to native code, but an interpreter and a compiler is included in the code as SBCL doesn't tree-shake (you have to do this, if you want smaller files).

Don't change these.
Name: Email:
Entire Thread Thread List