At Fri, 30 Nov 2007 15:44:00 +0530, Madhu wrote:
- Samium Gromoff 87lk8hvhdz.wl@betelheise.deep.net :
| The patch below rectifies the swank.asd, making the | ASDF load flow more natural.
- Samium Gromoff 87hcj4uzwz.wl@betelheise.deep.net :
| Now it actually compiles contribs, but also doesn't load them. | | The contrib enumeration, protocol version formulation, | some utility functions plus the loader epilogue part are now | shared between the ASDF and swank-loader paths.
I noticed this patch adds 4 files and a lot of complexity.
It makes the ASDF load path use the generic .fasl storage policy, so at a certain conceptual level it removes complexity.
Moreso, it makes data more explicit -- namely the contrib list and the constituent file list are now specified at separate, well-known locations, prone to creative tampering.
Making the policies that were hidden to be explicit is bound to produce that feeling of complexity.
But yes, the loading is now less self-contained.
I do not load ASDF in any of my lisp images, and I have a simple recipe for loading Slime: [Optionally make the SWANK-LOADER package and set *FASL-DIRECTORY*], and then LOAD on a single file swank-loader.lisp.
Is this workflow still supported?
Indeed, that's the "swank-loader path" I refer to.
Couldnt asdf be patched/added to support SLIME's simple swank load mechanism instead?
Well, the intent was to align the ASDF load path with the "normal" system definitions, allowing ASDF to manage the .fasls and making the behaviour more intuitive for the users.
You can see people doing various hacks to make swank load faster -- this patch makes it behave like any other system would (modulo contrib loading, but even here the difference is fairly minor), meaning that if swank is loaded into the core, loading the ASDF system[1] won't make it load again.
-- Madhu
regards, Samium Gromoff