-----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-----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
