[asdf-devel] ASDF features under discussion
Now that this discussion is opened, I would like to add a small question and a petition. First the question. What is the level of integration of ASDF with different implementations? Does ASDF support all lisp implementations equally? Does SBCL (and perhaps other) ship the latest versions of ASDF? I am asking this because ECL has some pretty special needs. Namely, ASDF currently relies on compile-file / load for everything and for us it is more efficient to compile many files into a single binary that is loaded at a later point. Currently ECL solves this using a slightly outdated version of ASDF, providing its own operations and imposing around methods on different operations. http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=blob;f=contrib/a... For instance, we have a LOAD-FASL-OP that joins three steps: 1) a LOAD-OP that thanks to the around methods produces both FASLs and object files, 2) linking the object files into a big FASL, 3) loading the big FASL. If the big FASL has been produced, then only step 3) is performed. But in addition to this ECL provides operations for creating standalone executable files, shared libraries and statically linked libraries http://ecls.sourceforge.net/new-manual/ch16.html I am aware that ASDF is a rapidly evolving architecture and I am afraid that things would break. It is for this reason that I would like to ask for help in one of these ways: 1) providing a stable way for us to implement these extensions or 2) including those operations in ASDF. Juanjo On Wed, Aug 19, 2009 at 3:11 PM, Gary King<gwking@metabang.com> wrote:
For the record, we've had recent (but not definitive) discussions of:
* whether or not optional parts of a system should be `nil` or unbound
* version numbering
* integrating ASDF and testing
* ASDF and the windows symlink patch.
If there are things I missed in the above list, please let me know.
-- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
Juan Jose Garcia-Ripoll wrote:
Now that this discussion is opened, I would like to add a small question and a petition.
First the question. What is the level of integration of ASDF with different implementations? Does ASDF support all lisp implementations equally? Does SBCL (and perhaps other) ship the latest versions of ASDF?
This is a good question. Do we have a notion of an ASDF release from git that is flagged as worth packaging into an implementation? I'm thinking that, for example, it's a good idea for us to be able to push releases like 1.359 and 1.360 that people can try out and load on their own. But I'd argue that we should additionally take some action (I'm not sure what this would be or how to manage it) to "bless" a release as being stable enough for implementation maintainers to adopt. At the very least, we might want to buff the tests, and have some page where people could report testing ASDF on different implementation X OS X architecture tuples. Also, would it be worth tweaking the version numbering scheme to provide information about the nature of the changes (as, e.g., ASDF itself suggests). For example, if we were at 1.0.359, my doc string patch, because it wouldn't change the API or behavior, would just push us to 1.0.360. The proposed test-op modification so that test-op is made to depend by default on load-op would change behavior but not the API. So this should push us from 1.0.359 to 1.1.0. [Previously, test-op had no default dependencies, and everyone wanting to implement it had to add a :depends-on (:test-op (:load-op "foo")) to his/her foo system.] Finally, if we were to change the API incompatibly, that should bump us from 1.0.359 to 2.0.0. [While this seems crispy and clear, I suspect that in practice "change the API incompatibly" is not sufficiently operational that one could take a look at a change and decide unambiguously if it was an incompatible API modification.] The ASDF development community has a higher duty to its users than developers of a less pervasive library, so it's probably worth thinking about this a little to get it right. Best, Robert
2009/8/19 Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com>:
First the question. What is the level of integration of ASDF with different implementations? Does ASDF support all lisp implementations equally? Does SBCL (and perhaps other) ship the latest versions of ASDF?
(Sorry for the late answer.) SBCL ships with a periodically updated upstream ASDF. That is, it might not be the latest bleeding-edge one for each release, but the intention is that the one SBCL comes with contains no modifications. Historically this has not always been true, I think, but it has been the intention. If cleaning ASDF of the SBCL-contrib-releated stuff is done, then possibly this will change -- but even in that case we would prefer to keep the changes minimal. Cheers, -- Nikodemus
On Mon, 21 Sep 2009, Nikodemus Siivola wrote:
2009/8/19 Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com>:
First the question. What is the level of integration of ASDF with different implementations? Does ASDF support all lisp implementations equally? Does SBCL (and perhaps other) ship the latest versions of ASDF?
(Sorry for the late answer.) SBCL ships with a periodically updated upstream ASDF.
That is, it might not be the latest bleeding-edge one for each release, but the intention is that the one SBCL comes with contains no modifications. Historically this has not always been true, I think, but it has been the intention.
IMO, ASDF should be augmented with (stable) hooks into REQUIRE for all capable lisps. It should similarly try to handle all reasonable variations required by implementations.
If cleaning ASDF of the SBCL-contrib-related stuff is done, then possibly this will change -- but even in that case we would prefer to keep the changes minimal.
Nikodemus, does this SBCL-contrib stuff refer to my email on sbcl-help? If so, I was wanting to fix ASDF to always hook into REQUIRE regardless of the SBCL_BUILDING_CONTRIB environment variable. As it stands now, a (load "asdf.lisp") usually won't hook in; only a REQUIRE of the precompiled ASDF works. Later, Daniel
Daniel Herring wrote:
On Mon, 21 Sep 2009, Nikodemus Siivola wrote:
2009/8/19 Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com>:
First the question. What is the level of integration of ASDF with different implementations? Does ASDF support all lisp implementations equally? Does SBCL (and perhaps other) ship the latest versions of ASDF? (Sorry for the late answer.) SBCL ships with a periodically updated upstream ASDF.
That is, it might not be the latest bleeding-edge one for each release, but the intention is that the one SBCL comes with contains no modifications. Historically this has not always been true, I think, but it has been the intention.
IMO, ASDF should be augmented with (stable) hooks into REQUIRE for all capable lisps. It should similarly try to handle all reasonable variations required by implementations.
What do you mean by the above exactly? That (require 'asdf) should work everywhere? Or do you mean that (require 'foo) should try to asdf-load foo everywhere? The latter seems more controversial, since implementations may have already decided they want to do something else with require and provide. best, r
On Wed, 23 Sep 2009, Robert Goldman wrote:
Daniel Herring wrote:
On Mon, 21 Sep 2009, Nikodemus Siivola wrote:
2009/8/19 Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com>:
First the question. What is the level of integration of ASDF with different implementations? Does ASDF support all lisp implementations equally? Does SBCL (and perhaps other) ship the latest versions of ASDF? (Sorry for the late answer.) SBCL ships with a periodically updated upstream ASDF.
That is, it might not be the latest bleeding-edge one for each release, but the intention is that the one SBCL comes with contains no modifications. Historically this has not always been true, I think, but it has been the intention.
IMO, ASDF should be augmented with (stable) hooks into REQUIRE for all capable lisps. It should similarly try to handle all reasonable variations required by implementations.
What do you mean by the above exactly? That (require 'asdf) should work everywhere? Or do you mean that (require 'foo) should try to asdf-load foo everywhere? The latter seems more controversial, since implementations may have already decided they want to do something else with require and provide.
My view is that, if an implementation provides a supported hook to augment REQUIRE, then ASDF should take advantage of that hook. Otherwise, ASDF's users are left passing these around on the black market. People who really don't want that behavior could (push :disable-asdf-require-hook *features*) before loading ASDF... - Daniel
On 2009-09-23, at 08:12 , Daniel Herring wrote:
[...]
My view is that, if an implementation provides a supported hook to augment REQUIRE, then ASDF should take advantage of that hook. Otherwise, ASDF's users are left passing these around on the black market.
People who really don't want that behavior could (push :disable-asdf-require-hook *features*) before loading ASDF...
could this please at least be duplicated to a variable which has the equivalent effect on the function's actions.
- Daniel
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 2009-09-23, at 08:59 , james anderson wrote:
On 2009-09-23, at 08:12 , Daniel Herring wrote:
[...]
My view is that, if an implementation provides a supported hook to augment REQUIRE, then ASDF should take advantage of that hook. Otherwise, ASDF's users are left passing these around on the black market.
People who really don't want that behavior could (push :disable-asdf-require-hook *features*) before loading ASDF...
could this please at least be duplicated to a variable which has the equivalent effect on the function's actions.
r.goldman observed, that my concern may not be self-evident. one would expect the reader conditionalization to be limited to the vendor-specific hooks, while the operator's generic behavior is left to execution-time controls.
the execution-time control is necessary if the user is to effect the function's behavior in those cases where the vendor has supplied a compiled version of the asdf package.
- Daniel
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
participants (5)
-
Daniel Herring -
james anderson -
Juan Jose Garcia-Ripoll -
Nikodemus Siivola -
Robert Goldman