Re: psu-lush 1.2

Ralf Juengling <[email protected]> Tue, 11 Dec 2007 10:09:44 -0800 (PST)
Newsgroups gmane.lisp.lush.devel
Message-ID <[email protected]>
On Tue, 11 Dec 2007, Raymond Martin wrote:

>> I'm still thinking about the right way to fix this. The
>> problem would not occur if 'make install' instructions would
>> copy the time information along with the files. This is
>> desirable, I think, because it would enable making use of
>> a pre-compiled standard library. That way you don't only
>> save compilation time but also space in varlushdir (usually
>> in you home directory).
>
> Okay, I see what you are saying. There are various ways around this.
> Timestamp is one. How about checksum (MD5, CRC)? It seems to me
> that you can still use time information, the logic is just missing.
>
> Also, it is already possible to load arbitrary standard libraries in Lush,
> so why not build up your extras/changes in the fashion of the packages/interfaces
> so that much of the on-the-fly compilation can be avoided at compile time?
> That is, load all the extras for psu-lush only as needed and not all in one shot.
> Of course, this depends on what is to be considered fundamental functionality
> that needs fast loading at startup.

I'm not sure we are on the same page. After a system install
there is all kinds of code under /usr/share/lush/lsh, and
/usr/share/lush/packages, and many of these files contain build
instructions. So the first time you libload, say "libidx/idx-sort",
C code gets generated and compiled and the resulting object code
gets loaded. But this C code and object gets written into a
subdirectory of varlushdir (typically "~/.lush").

The second time you libload "libidx/idx-sort" the compilation is
bypassed because there already is an object file (under varlushdir)
and it is up-to-date. I was saying that Makefile could contain
instructions to generate all the object files for code under
/usr/share/lush/lsh and install those along with the source
filesry so that lush would not never to compile anything when
loading code from there.

One could do the same for code in /usr/share/lush/packages, of
course, but I'm not sure it is a good idea. If you update a library,
libgsl say, then the object code in /usr/share/lush/packages/gsl
becomes obsolete and you would have to partially reinstall lush.

Ralf

-------------------------------------------------------------------------
SF.Net email is sponsored by: 
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php