On 8 June 2011 11:54, Raymond Toy toy.raymond@gmail.com wrote:
On 6/8/11 5:21 AM, Faré wrote:
Can you upgrade your implementation to ship with the latest ASDF? Thanks! If you're still using 2.015 (or something even older), there have been many bug fixes, robustness, portability and upgradability enhancements and a few features implemented since.
Done, in cvs.
Also, the CLISP maintainers insist on having (require :asdf) not work and (require "asdf") work, whereas CMUCL does the opposite. Since the CLISP maintainers won't seem to budge, could you have CMUCL accept both?
I thought this would be a more difficult change, but in fact it's quite simple and compatible. Just needed to add (defmodule "asdf" "modules:asdf/asdf") and now cmucl will accept both :asdf and "asdf".
Will be available in the next snapshot.
Thank you so much!
It's not the first time I resent the attitude both uncommon and dogmatic of the CLISP maintainers. All other maintainers are so nice and accommodating!
If I have another wishlist for CMUCL, it would be self-enclosed application delivery into a single executable that includes the image.
SBCL, CLISP, CCL, ECL, LispWorks do it and are supported by XCVB and CL-Launch. Could CMUCL do it? That would tremendously simplify delivery of code.
For extra brownie points, if you have a good story for a "linkkit" allowing to statically compile additional C libraries into the executable being delivered, that's would be wonderful. CLISP and ECL have it, SBCL notably doesn't. If CMUCL is similar to SBCL in that regard, you might have to have some magic linker script and function annotations to ensure that magic functions are located at an address known to Lisp code despite new code being linked into the .text and .data segments. Typically, you'd either ensure the proper objects files are linked first, or you'd create a magic segment(s) different from .text and/or .data, that starts at a magic address, in which to compile the stuff that the Lisp image will expect to be at a known address.
So there.
Thanks a whole lot!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Arbitrary limits to programs are evil, particularly when they go either enforced or unenforced.