Re: Common Lisp apps in Fedora
Kevin Kofler: > Ouch, we weren't aware of all these issues when we approved common-lisp- > controller in FESCo. :-( It was "sold" to us as something great and working > perfectly. I wasn't aware that it didn't actually work at all at this time > and I strongly doubt the rest of FESCo was either. It makes no sense to have > a packaging guideline mandate using something which doesn't work. Jerry James: > The alternative to common-lisp-controller, for libraries at least, is > to have lots of subpackages:... > I can see why Debian went with > common-lisp-controller It helps keep insanity at bay. Common-lisp-controller would probably be very helpful for libraries if it *did* work. But it appears that mandating it was premature. Jerry James: > But I think we need to have an escape clause for applications, and > also for libraries that take a significant amount of time/space to > compile. No escape clause needed for applications. The 2nd sentence of: https://fedoraproject.org/wiki/Packaging:Lisp "This document does not describe conventions and customs for application programs that are written in Common Lisp." I think it should be backed down until it's *really* fixed (awakening upstream as necessary). --- David A. Wheeler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
On Fri, Jan 8, 2010 at 1:29 PM, Kevin Kofler wrote: > Ouch, we weren't aware of all these issues when we approved common-lisp- > controller in FESCo. :-( It was "sold" to us as something great and working > perfectly. I wasn't aware that it didn't actually work at all at this time > and I strongly doubt the rest of FESCo was either. It makes no sense to have > a packaging guideline mandate using something which doesn't work. The alternative to common-lisp-controller, for libraries at least, is to have lots of subpackages: trivial-features-ccl trivial-features-clisp trivial-features-cmu trivial-features-ecl trivial-features-gcl trivial-features-sbcl And you also have to keep trivial-features-src around in case someone buys an Allegro license. I can see why Debian went with common-lisp-controller for that case. It helps keep insanity at bay. But I think we need to have an escape clause for applications, and also for libraries that take a significant amount of time/space to compile. If we're going to use it for (some) libraries, then we also need to fix it so that it works on as many CLs as possible. A number greater than zero would be good. :-) Some kind of response to the fix I suggested for SBCL in https://bugzilla.redhat.com/show_bug.cgi?id=499182 would be nice, too. I guess I should make that an actual patch instead of a suggested sed operation. :-) H, I just looked upstream to see if this has been fixed, and found that the last CVS checkin was 4 years ago. That isn't encouraging. Is upstream dead, or could it be awakened if shouted at? -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
Jerry James wrote: > One of the first issues we'll have to face is the use of > common-lisp-controller. Ouch, we weren't aware of all these issues when we approved common-lisp- controller in FESCo. :-( It was "sold" to us as something great and working perfectly. I wasn't aware that it didn't actually work at all at this time and I strongly doubt the rest of FESCo was either. It makes no sense to have a packaging guideline mandate using something which doesn't work. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
On Fri, Jan 8, 2010 at 2:15 AM, Alexander Kahl wrote: > Please see my reply to David's post; do you know whether there is a > standardized SIG founding procedure? I looked around and found this: https://fedoraproject.org/wiki/Defining_projects It sounds like we should tell the Fedora Project Board that we are forming, and appoint someone to send them regular status reports. We should also tell the Packaging Committee that we have identified some problems with the current Lisp packaging guidelines and plan to submit revisions to those guidelines. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/2010 04:27 PM, Jerry James wrote: > On Wed, Jan 6, 2010 at 2:32 AM, Alexander Kahl > wrote: >> Thanks for the offer; currently I'm busy with getting GNUnet through the >> review, ccl can be next on the list but I'm unsure whether it wouldn't >> be better if we'd focus on packaging most commonly used CL libs like >> Alexandria first. ATM Debian (and its brown derivative) seems to be the >> no. 1 distro of choice for CL devs and I'd like to change that. > > I have a handful of candidate CL library packages, including alexandria, here: > > http://jjames.fedorapeople.org/ Nice! I'd add bordeaux-threads, cl-patron, cl-ppcre and some other as soon as the issues mentioned below are resolved. > The problem is that I followed the packaging guidelines, and thus used > common-lisp-controller which, as I mentioned, doesn't work for any CL > engine currently available in Fedora. I think we have to fix that > first. > >> Are you (or is anyone else here) interested in founding a Common Lisp SIG? > > Yes, I think we need to do so. Count me in. Please see my reply to David's post; do you know whether there is a standardized SIG founding procedure? - - Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktG958ACgkQVTRddCFHw12gmQCfcLbnC7mit17eA9ktEHGd2RAz LJkAniDgJUlQCwu4GHvLkRM9QycWD92+ =Wtzs -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, On 01/06/2010 06:34 PM, David A. Wheeler wrote: > 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? > > No. That'd be rediculous; big CL applications can take a LONG time to > compile, > and compilation usually requires lots of memory (even if the final > application doesn't). this is identical to my experience. > Fedora has lots of applications written in many other compiled languages > like C and C++, and they aren't distributed *only* as source code. Instead, > people expect that when they download the binary they'll get a pre-compiled, > ready-to-go version. I think the same should be true for big Common Lisp (CL) > applications. (...) Definitely - but I'd rather see CL as a compiled language that permits the equivalent of static linking only (worst drawback) so the resulting binaries are huge since they contain every dependency including the actual lisp machine itself. This could in fact be the weakest point arguments could attack; I don't see an obvious solution here either as FASL is the closest it can get to prepare a freshly started lisp machine up to the desired state but that still requires dependency resolution, lots of memory, disk activity and cpu cycles etc. The only known alternative to me is gcl and ecl using C as intermediate language for compilation but gcl lacks even basic threading and ecl doesn't provide some POSIX related standard featured expected from compiled languages either. So the question remains whether Fedora devs and users would tolerate big CL app binaries. > Alexander Kahl: >> Are you (or is anyone else here) interested in founding a Common Lisp SIG? > > I'm interested. Is there a standardized process for founding SIGs? Or just add some wiki pages, set up a mailing list and spread some propaganda so folks will join? - - Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktG9wMACgkQVTRddCFHw13qZACgpnCOT8PH45rMIlztwqSgCUnQ nIIAoIyGSLFIIyZs09tqG23dLDOdDslg =MwAw -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
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? No. That'd be rediculous; big CL applications can take a LONG time to compile, and compilation usually requires lots of memory (even if the final application doesn't). Fedora has lots of applications written in many other compiled languages like C and C++, and they aren't distributed *only* as source code. Instead, people expect that when they download the binary they'll get a pre-compiled, ready-to-go version. I think the same should be true for big Common Lisp (CL) applications. If you want a distribution that requires you to recompile *everything* from scratch, go to Gentoo or similar. There should be pre-compiled versions of large CL applications, as maxima-sbcl is right now and the upcoming pvs-sbcl will be. Alexander Kahl: > Are you (or is anyone else here) interested in founding a Common Lisp SIG? I'm interested. --- David A. Wheeler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
On Wed, Jan 6, 2010 at 2:32 AM, Alexander Kahl wrote: > Thanks for the offer; currently I'm busy with getting GNUnet through the > review, ccl can be next on the list but I'm unsure whether it wouldn't > be better if we'd focus on packaging most commonly used CL libs like > Alexandria first. ATM Debian (and its brown derivative) seems to be the > no. 1 distro of choice for CL devs and I'd like to change that. I have a handful of candidate CL library packages, including alexandria, here: http://jjames.fedorapeople.org/ The problem is that I followed the packaging guidelines, and thus used common-lisp-controller which, as I mentioned, doesn't work for any CL engine currently available in Fedora. I think we have to fix that first. > Are you (or is anyone else here) interested in founding a Common Lisp SIG? Yes, I think we need to do so. Count me in. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/05/2010 12:10 AM, Jerry James wrote: > On Mon, Jan 4, 2010 at 10:55 AM, Alexander Kahl > wrote: >> 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. > > Is there anything I can do to help? If nothing else, I can review the > package when you have it ready. Thanks for the offer; currently I'm busy with getting GNUnet through the review, ccl can be next on the list but I'm unsure whether it wouldn't be better if we'd focus on packaging most commonly used CL libs like Alexandria first. ATM Debian (and its brown derivative) seems to be the no. 1 distro of choice for CL devs and I'd like to change that. Are you (or is anyone else here) interested in founding a Common Lisp SIG? - - Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktEWLUACgkQVTRddCFHw10RhwCePBIwfDvFvvRC+UFKqn0+RnYU Mj8AoNr6cwPIJ5r3eD/YE26OqvibJqen =7gLM -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
On Mon, Jan 4, 2010 at 10:55 AM, Alexander Kahl wrote: > 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. Is there anything I can do to help? If nothing else, I can review the package when you have it ready. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
-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
Common Lisp apps in Fedora
I was asked [1] to start a thread about the packaging of Common Lisp
applications for Fedora. The person who made that request feels that
the existing guidelines are lacking detail. Who else is interested in
packaging such applications? We should get a group together and start
hashing through the issues.
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?
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. How about
clisp, ecl, or cmucl?
Third, common-lisp-controller support in SBCL is broken [3]. This
means that common-lisp-controller currently works for ZERO Common Lisp
implementations in Fedora, yet the guidelines mandate its use.
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.
Another issue is that some RPM macros would come in handy. I have
found myself defining macros like this for nearly every ASDF-using
Common Lisp package I have put together so far:
%global clname trivial-features
%global cldir %{_datadir}/common-lisp
%global sysdir %{cldir}/systems
%global srcdir %{cldir}/source/%{clname}
Examples can be found at [4], [5], and [6].
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.
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?
References:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=548607#c30
[2] http://pvs.csl.sri.com/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=499182#c7
[4] http://jjames.fedorapeople.org/cl-trivial-features/
[5] http://jjames.fedorapeople.org/cl-trivial-gray-streams/
[6] http://jjames.fedorapeople.org/cl-alexandria/
[7]
https://www.redhat.com/archives/fedora-devel-list/2009-December/msg00801.html
--
Jerry James
http://www.jamezone.org/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
