[Ecls-list] Dumping running image

[Gabriel Dos Reis]

On Sun, 11 Mar 2007, Juan Jose Garcia-Ripoll wrote:

| 11 Mar 2007 05:25:04 -0500, Gabriel Dos Reis <gdr at cs.tamu.edu>:
| >
| > In the system I'm working with, I have the following scenario:
| >
| >    (I) one part does the following:
| >       (1) the system defines some macros
| >       (2) those macros need to be present in the environment while
| >           compiling the rest of the files.
| >       (3) with GCL, SBCL, CLISP the system builds fine as follows:
| >           (a) load the macros in a fresh lisp.
| >           (b) save the current image to disk.
| >           (c) use that image to compile the rest of the files.
| >           (d) use that image to load all objects and build the
| >               final executable.
|
|
| Simply put:
|
| (1) Build an program with the macro files. Call it ECL2

My reading of

  http://www.lisp.org/HyperSpec/Body/sec_3-2-2-2.html

did not suggest to me that the macros will be compiled away, or made
available in the compiled obejcts, therefore present in in the second
imageg (ECL2) while processing other files.
I read your message as suggesting that the macros will be available in
ECL2.  Is that specific to ECL, or is it a standard behaviour?

| (2) For each file, use ECL2 to compile it.
| (3) Build a program with the macro and the compiled files.
|
|   (II) another part does this for bootstrapping:
| >       (1) start with loading macros
| >       (2) for each file in a component II:
| >           (a) compile the lisp file to object code
| >           (b) load the just compiled object code
| >       (3) save the resulting image to disk.
|
|
| Here it would apply the same routine as before.  Build an ECL2 that contains
| the macros. For each file, compile it twice: once as a FASL, once as object
| file (with :system-p t). Load the FASL and continue compiling. Finally link
| all the object files (macro and compiled files) into a single executable.
|
| If you do things this way, the resulting standalone program will mimic the
| steps of first loading the macros and then loading each FASL. If your system
| supports this way of working then it should work with ECL.

Thanks for the tip; I'll try to see whether I can arrange the build
machinery to accomodate that.  I'll shortly release what I have so
that other people can start playing with it and give feedback.

| for timing constraints, it is important that the loading of object
| > files doe not go from linear to quadratic.
|
|
| I do not understand this very well.

Well, a scenario would be to compile:

      * for each file f:
         (i) load all previously compiled objects.
        (ii) compile f.

which would guarantee the functional beahviour, but would make the
object files loading quadratic in the number of files.

Thanks,

-- Gaby

-- 
Dr. Gabriel Dos Reis (gdr at cs.tamu.edu), Assistant Professor
	      http://www.cs.tamu.edu/people/faculty/gdr
	Texas A&M University -- Department of Computer Science
	301, Bright Building -- College Station, TX 77843-3112