-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm the one who actually asked for this discussion; I've also asked for
CL developers/packagers at the FUDCon'09 in Berlin if anyone remembers
but no luck back then.
On 01/04/2010 05:29 PM, Jerry James wrote:
One of the first issues we'll have to face is the use of
common-lisp-controller.
First, it postpones compilation to the first time the application is
executed by a particular Common Lisp engine. For the application I
packaged, PVS [2], compilation takes a significant amount of time.
This approach may be fine for small libraries and applications, but
will it really scale up to the some of the big applications people
want to package?
Not deploying ready-to-use CL-based executables but firing up a
CL
implementation instance each time a user wants to run such a program has
a massive overhead even if valid FASL to be loaded by cl-controller
still exists and draws in the chance of breakage through side-effects,
esp. if using implementation dependent code like threading APIs -
wrapper libraries such as bordeaux-threads exist for must stuff but not
everything can be covered and upstream may decide to change things
spontaneously; effectively this will lead to users discovering the
breakage when it's to late.
Pros/cons I see if deploying pre-compiled binaries for applications instead:
- - Pro: Much faster startup time (esp. if using lots of dependencies, w/
or w/o asdf doesn't matter)
- - Pro: Breakage through CL implementation changes can be discovered by
a package's maintainer first, not the user
- - Con: Binaries turn fscking HUGE by containing a whole Lisp machine
each
Alternatively, trigger scripts (don't yell, they're evil I know that!)
might be used to recompile CL programs upon implementation updates,
pros/cons:
- - Pro: Faster startup times (same as above)
- - Pro: Breakage through API changes could be caught, leaving behind an
old working version of a program based on the last working CL
machine
- - Pro: Bloat-less, only source code gets deployed
- - Con: Trigger scripts considered prone to fail; maybe trigger
recompilation upon next program execution?
Second, common-lisp-controller is only used by SBCL right now, as
far
as I can tell. Is anybody working on hooking it up for the other CLs
in Fedora? I am the GCL maintainer, and I've tried, but GCL is
missing multiple bits of functionality used by common-lisp-controller,
so I think that one is a no-go without significant upstream support.
I think that support is unlikely to appear, given that upstream
appears to be, not dead, but not very healthy either.
True, I've been waiting
for GCL threading support for ages.
The next issue is that some applications selectively load certain
Lisp
files at runtime on a demand-driven basis. They do so because any
particular run tends to load only a fraction of the available files,
thereby reducing memory pressure. How should this be accomplished
with ASDF? We need guidelines to help packagers who are working with
libraries whose upstreams do not use ASDF.
Isn't asdf supposed to only load
most crucial bits of CL code? I'd dare
to claim asdf is not intended to post-conditionally load any additional
files belonging to the same program, i.e. I'd never use (require
'foopkg) or (asdf:oos 'load-op 'foopkg) to load a bunch of files during
runtime but instead just (load) them.
Even for bigger parts upstream put into extra (def)packages it may be a
good idea to load all of them unconditionally to save startup time.
On the other hand, do you know any projects (besides the original clocc)
that *still* don't use asdf?
Yet another issue is that nobody appears to be minding the Common
Lisp
store in Fedora. In a recent thread [7], I twice asked who is
responsible for maintaining the Common Lisp packaging guidelines, with
no response. That makes me suspect that nobody is currently
maintaining them, so any group of interested parties would have to
include people willing to do that work.
The original guidelines seem to come from
Spot; just adapted from Debian..?
Finally, there are more Common Lisp engines out there in the world
that have not been packaged for Fedora. Is there any need to do so?
I'm interested in packaging up one application whose upstream favors
Clozure. Is anybody working on a Clozure package?
Actually I've started trying
to package ccl as it is (AFAIK) the only
implementation besides sbcl supporting (all at once) threads, mutexes,
semaphores and conditions, hence some projects like cl-patron do not
support any other implementation.
- - Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAktCK5YACgkQVTRddCFHw10cmQCgkfssdVKdCnxvK6Z9MRSePyMW
vroAn3XrH/HTLKR+pW4fKJz2lV3JUjGf
=pEJq
-----END PGP SIGNATURE-----