[cl-debian] Anyone willing to package Cedilla?
Hi, Could people please have a look at RFP 288769 and see whether they'd be willing to do the work? They'd be doing me a favour. For more details, please see http://www.pps.jussieu.fr/~jch/software/cedilla/ Cedilla has been in SuSE Linux for years, so the code is expected to be fairly solid. On the other hand, you should expect to have some packaging problems, some of which might require upstream changes; in particular, the current version contains some autogenerated files which it might be better to generate at build time. Oh, and upstream is maintained using Darcs. Thanks for listening, Juliusz
Juliusz Chroboczek schreef:
Hi,
Could people please have a look at RFP 288769 and see whether they'd be willing to do the work? They'd be doing me a favour.
I've had a quick look at the source and it doesn't look too difficult. As a requirement for packaging it we would have to convert it to asdf, would you like to include this in your sources too?
Oh, and upstream is maintained using Darcs.
Good. Now to find out how to use darcs-buildpackage with an darcs-upstream... Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
Juliusz Chroboczek schreef:
As a requirement for packaging it we would have to convert it to asdf, would you like to include this in your sources too?
With pleasure, as long as it doesn't break non-ASDF builds (I'm not sure whether SuSE include ASDF).
Hi, I did a basic package (you can get the darcs archive at http://cl-debian.alioth.debian.org/repository/pvaneynd/cl-cedilla/) with a asdf file and a replacement cedilla 'executable' that calls (clc:clc-require :cedilla) and then invokes cedilla as normal. This causes a slight delay in startup. For further integration with debian I've taken a look at defoma and at the cedilla-config.lisp file and I fear I've run into the limit of my font knowledge. Defoma expects me to write a perl library that can then use Defoma::Common to extract 'hints' from the font information I receive. The problem is that I see little relation between the information in these hints and the cedilla-config.lisp entries. Groetjes, Peter Ps Defoma:Common docs: http://newton.waglo.com/cgi-bin/dwww?type=man&location=/usr/share/man/man3/Defoma%3A%3ACommon.3pm.gz -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
I did a basic package (you can get the darcs archive at http://cl-debian.alioth.debian.org/repository/pvaneynd/cl-cedilla/)
Thanks a lot. I've just had a quick look at your package. It's after 2am over here, my apologies if the following fails to make sense. I have one serious objection. Cedilla is an end-user application, not a Common Lisp library, so I believe the package should be called ``cedilla'', not ``cl-cedilla''. The end user has no interest in the programming language Cedilla is implemented in. This is actually rather important to me: putting the programming language in the name feels provincial. It's also confusing to have to apt-get cl-cedilla when what you want is an application called Cedilla. (Never mind consistency with SuSE.) A more technical issue: when I installed your package, I couldn't run cedilla: CLC told me I didn't have the right permissions (EACCESS, with no further details). I had to run Cedilla as root once in order to get it to work. (I might have mis-built it; I used dpkg-buildpackage with no options except to change the signer, then dpkg -i.) You may want to tighten the dependency to Clisp version 2.27 or later. 2.26 has nasty bug that breaks Cedilla, and older versions do not support the ``-ansi'' flag. In the description, I would suggest replacing ``unicode text'' with ``unicode plain text''. There's also an unbalanced bracket after ``glyphs''. I would also suggest mentioning a2ps in the description, so that ``apt-cache search a2ps'' yields Cedilla. I don't have a clear opinion on this subject, but you may want to think about whether to include a Cedilla-typeset version of the README file in the package.
with a asdf file and a replacement cedilla 'executable' that calls (clc:clc-require :cedilla) and then invokes cedilla as normal. This causes a slight delay in startup.
On my machine (2.6GHz P4), that's a delay of 0.4s with a warm cache. For comparison, the basic script that I use upstream causes a delay of 0.2s. The trouble with this is that this delay is long enough to be annoying, and we definitely don't want to be confirming the ``Lisp is slow'' folklore. Do you think that it might be worth to switch to using a simple script, like the one upstream? Can such a script be automatically generated from the ASD definition? More generally, shouldn't the CL-Debian project start thinking about deployment of applications? It seems completely oriented to libraries right now.
For further integration with debian I've taken a look at defoma and at the cedilla-config.lisp file and I fear I've run into the limit of my font knowledge.
Heh.
Defoma expects me to write a perl library that can then use Defoma::Common to extract 'hints' from the font information I receive. The problem is that I see little relation between the information in these hints and the cedilla-config.lisp entries.
The cedila-config file was lovingly hand-crafted by the author ;-) OTOH, now you mention Defoma, it should be possible to augment the list of fontsets in cedilla-config with stuff produced by Defoma. But that will require some more support from Cedilla itself, so don't bother right now. I'll think about it, and let you know what I come up with. Thanks again, Juliusz
On 29/08/05, Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr> wrote:
Do you think that it might be worth to switch to using a simple script, like the one upstream?
Can such a script be automatically generated from the ASD definition? I've recently written cl-launch for that purpose. http://www.cliki.net/cl-launch With everything in c-l-c managed paths, you'd do something like cl-launch --output cedilla --asd cedilla --init '(cedilla:run-cedilla)' --no-path --lisps 'clisp'
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Quis custodiet ipsos custodes? (Who shall watch the watchmen themselves?) -- Juvenal, Satires, VI, 347
On 30.08.05, Juliusz Chroboczek wrote: Hello Juliusz,
I have one serious objection. Cedilla is an end-user application, not a Common Lisp library, so I believe the package should be called ``cedilla'', not ``cl-cedilla''. The end user has no interest in the programming language Cedilla is implemented in.
I highly agree on this. We have multiple End-User CL applications in the archive (mcvs, albert, stumpwm, maxima) that do not follow the cl- prefix either. cl- really only makes sense for the name of libraries.
More generally, shouldn't the CL-Debian project start thinking about deployment of applications? It seems completely oriented to libraries right now.
This is where implementations put some restrictions. Deploying Common Lisp applications is generally difficult. a) I just yesterday worked to integrate SBCL's and CMUCL's FASLs into Debian's binfmt-support, so that they are executable using the binfmt_misc kernel module. This is nice and fast for writing own system tools or even compiling larger applications, but it is completely unsuitable to deliver in a Debian package: the binary formats of SBCL und CMUCL change frequently and every package would need to be rebuilt if such an incompatible change happens. b) One could use the cl-libraries as build-depends, compile the application and dump an image to be loaded when the application is run. This is very fast, but if one of the cl-libraries has a real bug and it is fixed, the delivered application needs to be rebuilt to carry its new version in the dumped image. mcvs uses this approach and even delivers a whole clisp in its package. Applications delivered this way get huge in size, let alone the fact that you can not always load a dumped image that depends on foreign shared library code. c) The only real portable, code sharing and space saving approach is delivering the application in source code and registering it at ASDF and the Common Lisp Controller. Unfortunately this is also the slowest way. E.g. SBCL needs very much time to load even multiple of FASLs. And the first run takes even longer, because the package has to be compiled for many implementations first. Regards, René
Hello, sorry to reply so late, the clc bug had me in its grip On Tuesday 30 August 2005 09:26, René van Bevern wrote:
More generally, shouldn't the CL-Debian project start thinking about deployment of applications? It seems completely oriented to libraries right now.
This is where implementations put some restrictions. Deploying Common Lisp applications is generally difficult.
I've put some numbers to the different options (for clisp and for cedilla that is) (time is the best of 3 itterations after one warm-up) - Using clc-require with a script (like it is done now) $ time /usr/bin/cedilla Cedilla: Wrong number of arguments -- try "cedilla -?" for help. real 0m1.530s user 0m1.296s sys 0m0.160s - Concatenated all the fasls (in the right order) into one: $ time clisp -ansi -q -q -x '(load "c.fas")' -x '(cedilla:cedilla-main)' T Cedilla: Wrong number of arguments -- try "cedilla -?" for help. real 0m1.255s user 0m1.004s sys 0m0.048s - Dumping an image after loading the fasls: $ time clisp -ansi -q -q -M c.mem Cedilla: Wrong number of arguments -- try "cedilla -?" for help. real 0m0.137s user 0m0.056s sys 0m0.028s So the only real improvement over clc-require is to dump a memory image.
b) One could use the cl-libraries as build-depends, compile the application and dump an image to be loaded when the application is run. This is very fast, but if one of the cl-libraries has a real bug and it is fixed, the delivered application needs to be rebuilt to carry its new version in the dumped image. mcvs uses this approach and even delivers a whole clisp in its package. Applications delivered this way get huge in size, let alone the fact that you can not always load a dumped image that depends on foreign shared library code.
We could enhance clc to generate dependency information when building an application and when installing libraries remove all stuff depending on them. But the problem of foreign libraries remain, and in general the creation of a dumped image is difficult at best. I propose that for the moment Common Lisp applications dump manually: they will have a 'natural' implementation anyway so writing non-portable code is no problem. I will try to enhance clc to export a function writing the dependency information and nuking the cache directory when installing a library that depends on it. If we detect patterns of usage after a while we could code that up. With the dumping of images cedilla would be competitive with the startup time of other utilities: $ time groff /dev/null real 0m0.161s user 0m0.084s sys 0m0.016s Comments? Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
Peter, I didn't have time to thank you for your packaging. I have had a look at your recent work, and I'm very happy with it. For Cedilla, the current approach, while not perfect, is good enough. However, I do think that you folks (as well as upstream Common Lisp implementors) should be thinking about application delivery in the medium term.
- Using clc-require with a script (like it is done now) real 0m1.530s user 0m1.296s sys 0m0.160s
- Concatenated all the fasls (in the right order) into one: real 0m1.255s user 0m1.004s sys 0m0.048s
On my system, with a warm cache, clc-require: 0.384r, 0.349u + 0.031s Loading all the fasls one by one: 0.254r, 0.239u + 0.012s Loading the concatenated fasl: 0.268r, 0.247u + 0.016s Groff: 0.041r, 0.033u + 0.008s What's going on here? You've got to realise that Cedilla builds large hashtables at load time (see the generated file data.lisp). On your slowish system, building the hashtables appears to dominate the startup time; on my faster system, building the hashtables takes less time, and we're seeing the cost of the statting done by ASDF. (Of course, the building happens before dumping an image, which explains why dumping an image makes Cedilla so much faster. Any suggestions for making the loading of data.fas faster are welcome.) I think that Cedilla is slightly atypical; other programs will most likely not need to build such large hashtables at runtime. Thus, while the startup overhead is not a major problem for Cedilla, it is something that should be solved in the medium term. Oh, by the way, I'm not a great fan of dumped images; they use up loads of space, and prevent the Lisp runtime from being shared between Lisp processes. Thanks again for your work, Juliusz
On 9/16/05, Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr> wrote:
Oh, by the way, I'm not a great fan of dumped images; they use up loads of space, and prevent the Lisp runtime from being shared between Lisp processes. Genera could dump incremental images. We could do the same. And/or fasls could be made into mixins of incremental image dumps. stuff to be mmap'ed properly.
Except that mmap()ing probably won't do much good unless it's at a fixed address. And then we might like to maintain a system-wide (and then user-wide) mutual-exclusivity of fasl addresses. Was it HP-UX that had a mechanism like that for its shared libraries, ensuring that none of the system libraries clashed, so it could just mmap() them with no memory- and time- hungry runtime linkage? BTW, Juliusz is the one who first told me about Common Lisp; though he was telling me more praises of Scheme, at that time. Czesc, Iolo! [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "Transported to a surreal landscape, a young girl kills the first woman she meets and then teams up with three complete strangers to kill again." - TV listing for the Wizard of Oz in the Marin Independent Journal
Oh, by the way, I'm not a great fan of dumped images; they use up loads of space, and prevent the Lisp runtime from being shared between Lisp processes.
Genera could dump incremental images. We could do the same.
Hmm... that shouldn't be too hard to implement in cmucl.
And/or fasls could be made into mixins of incremental image dumps. stuff to be mmap'ed properly.
Not really, if you want to preserve the compile/load/run-time semantics of Common Lisp. (Code might need to be executed at load time.)
Except that mmap()ing probably won't do much good unless it's at a fixed address.
That's okay. Cmucl already maps images at fixed addresses.
Was it HP-UX that had a mechanism like that for its shared libraries, ensuring that none of the system libraries clashed, so it could just mmap() them with no memory- and time- hungry runtime linkage?
All modern unices (at least Linux, Solaris and Mac OS X) can do that. It's called ``prelinking'' under Linux, I don't reacall the Solaris name.
BTW, Juliusz is the one who first told me about Common Lisp;
I plead guilty. Julek
Hello On Tuesday 30 August 2005 03:05, Juliusz Chroboczek wrote:
I have one serious objection. Cedilla is an end-user application, not a Common Lisp library, so I believe the package should be called ``cedilla'', not ``cl-cedilla''. The end user has no interest in the programming language Cedilla is implemented in.
Corrected. The new name is now cedilla, please pass the brown bag.
A more technical issue: when I installed your package, I couldn't run cedilla: CLC told me I didn't have the right permissions (EACCESS, with no further details). I had to run Cedilla as root once in order to get it to work. (I might have mis-built it; I used dpkg-buildpackage with no options except to change the signer, then dpkg -i.)
I use: darcs-buildpackage -rfakeroot -k4B729625 '-i_darcs|CVS|.cvsignore' -ICVS and with me it works for a mere user.
You may want to tighten the dependency to Clisp version 2.27 or later. 2.26 has nasty bug that breaks Cedilla, and older versions do not support the ``-ansi'' flag.
done.
In the description, I would suggest replacing ``unicode text'' with ``unicode plain text''. There's also an unbalanced bracket after ``glyphs''. I would also suggest mentioning a2ps in the description, so that ``apt-cache search a2ps'' yields Cedilla.
done.
I don't have a clear opinion on this subject, but you may want to think about whether to include a Cedilla-typeset version of the README file in the package.
This would make building cedilla depend on having cedilla installed (or first compile a throw-away version). I feel this is a lot of cost for little benefit, IMHO.
The trouble with this is that this delay is long enough to be annoying, and we definitely don't want to be confirming the ``Lisp is slow'' folklore. Do you think that it might be worth to switch to using a simple script, like the one upstream? Can such a script be automatically generated from the ASD definition?
Once (in version 1 or so) there was a way to generate a 'custom core', but this was dropped as no-one was using it anyway. I would need to think if we want to create custom cores or we just want to cat the fasls together in one fasl per library. For cmucl and sbcl this is a valid method, for the others I don't know.
More generally, shouldn't the CL-Debian project start thinking about deployment of applications? It seems completely oriented to libraries right now.
There have been precious few applications to date ;-).
OTOH, now you mention Defoma, it should be possible to augment the list of fontsets in cedilla-config with stuff produced by Defoma. But that will require some more support from Cedilla itself, so don't bother right now. I'll think about it, and let you know what I come up with.
Ok. I'll try to fix 'creating applications' soonish. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
and with me it works for a mere user.
Hmm... It looks like my system is broken, it works on my laptop. Sorry for the false alarm.
More generally, shouldn't the CL-Debian project start thinking about deployment of applications? It seems completely oriented to libraries right now.
There have been precious few applications to date ;-).
So I guess the best way to get you folks to do something about that is to write such applications... Thanks again for your work, Juliusz
On 24.08.05, Peter Van Eynde wrote: Hi Peter,
Good. Now to find out how to use darcs-buildpackage with an darcs-upstream...
It's not much different. Just darcs get the repository, add your UPSTREAM_cedilla_x.y tag (you don't need to send that back, of course) and get a Debian repository from that, add your Debian files, dbp-markdeb and be done with it. :-) Every time that Juliusz releases a new version, you just need to darcs pull in your upstream repository, add your UPSTREAM tag and darcs pull in your Debian repository. So basically just replace dbp-importorig by darcs pull and set the tag manually. ;-) Works well for all of my darcs-upstreams. Regards, René -- <Treibholz> schon möglich, dass der Firefox im Vergleich zu Galeon relativ gesehen schneller ist als unter debian.
participants (4)
-
Faré -
Juliusz Chroboczek -
Peter Van Eynde -
René van Bevern