Information about Petit Larceny on Unix systems
23 November 2004 / lth


HOW TO BUILD AND USE.

See HOWTO-BUILD and HOWTO-PETIT for information about this, there are few
surprises.

Bonuses:
 - BUILD-TWOBIT works as described in HOWTO-PETIT.

 - COMPILE-FILES and dynamic loading work as described in HOWTO-PETIT (though
   see point below about making the runtime system into a shared object)

 - On some systems you need to set LD_LIBRARY_PATH in order for
   Larceny to find the shared object.  On Linux my LD_LIBRARY_PATH
   contains "." for this purpose.

 - On some systems (Solaris seems to require it; Linux and MacOS X do
   not) you must compile the Larceny run-time system as a shared
   library in order for dynamic linking of .FASL files to work.  To
   make the build environment do this, evaluate
      (REQUIRE-SHARED-RUNTIME!)
   and then
      (BUILD-RUNTIME)
   to build Rts/libpetit.so.  When you install a version of Petit Larceny
   built with a shared run-time system, you must be sure to copy the .so
   file along with the executable and the heap image, and your shell
   script needs to add the correct directory to LD_LIBRARY_PATH on some
   systems.

 - Heap dumping works as for native Larceny: DUMP-HEAP and
   DUMP-INTERACTIVE-HEAP are both defined.

 - Twobit can be installed as a standalone application, as described
   in HOWTO-PETIT.


TODO.

* Fix COMPILE-FILES: 
  - does not pick up syntax from the compilation environment,
    eg, (require 'common-syntax) imports TIME but compiling a 
    function using TIME does not use this definition.
    COMPILE-FILE gets this right.  Alas, fix in place seems to
    confuse the macro expander -- the problem is that the
    newly loaded expander uses a different set of keywords
    (denotations) than the environment we pass in to it.  This
    is a result of using the old macro expander in the
    interaction environment (so it has old denotations) but 
    the new macro expander in the compiler (so it can only deal
    with new denotations).  The 'fix' used in the SPARC heap is
    to replace the old evaluator completely, but that does not
    work in the petit heap unless we load the interpreter again.

    Replacing the macro expander (through a parameter) is not
    enough because the macro expander works on the old syntax
    environment.

  - testcase: compile md5bench.sch and Asm/Standard-C/md5.sch into
    one file

* Implement (or test...) the foreign function interface

* Fix compilation environment further: can only compile a file once
  before restarting, because shared objects can only be loaded once
  (not unloaded and reloaded)

* Problem when moving fasl files and their shared objects: loading
  the fasl will usually cause trouble because the path in the fasl
  pointing at the .so is wrong now.  Propose fixing this by perhaps
  loading extra code to do some rewriting, ie, don't mess with the
  stuff in the std heap


BUGS, UNDIAGNOSED.

While rebuilding petit.heap using a compiled and dumped Twobit, I got
repeated problems in the heap dumping phase: the system gave me an
error that (car string=?) was being computed.  This appeared to be
related to the procedure REMOVE-DUPLICATES, since, when this function
was redefined with interpreted code, the problem disappeared.
However, the compiled code for REMOVE-DUPLICATES looked fine, and the
problem did not reappear when I restarted Twobit and tried creating
the heap once more.


--- Local Variables: ---
--- mode: text ---
--- indent-tabs-mode: nil ---
--- End: ---

