[cmucl-imp] ASDF 2.016 released

[Faré]

On 8 June 2011 11:54, Raymond Toy <toy.raymond at 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.