On 7/17/12 7:49 PM, Robert Goldman wrote: […]

OK, I checked. This /is/ a bug with MacPorts, and they are working on it.

I have a MacPOrts commit bit, so Lisp implementers should feel free to bug me with advice and/or patches… I'll take a stab at ecl-12.7.1 for MacPorts in the near future to see if that improves things.

On Tue, Jul 17, 2012 at 5:01 PM, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@gmail.com> wrote:

If you do not mind, I would like to produce a release of ECL with the old version of ASDF and ASDF-ECL. I need time to do what you mention, which should be done anyway at some point, but for that I would like to have some stable version of ECL out before the summer ends :-)

Oh, I don't mind that much: the whole design of ASDF 2 is that it will work even if implementors don't update it. However, I don't quite see what you're afraid of with respect to upgrading ASDF to the latest (currently 2.23) from what you have (currently 2.017.5). There have been several fixes specifically made for ECL, and we still have asdf-ecl (and will keep it until you're satisfied that asdf-bundle successfully replaces it). Not to speak about the many features and enhancements that ASDF has received in the last year. I run our regression test suite with ECL all the time and before every release and it's passing with flying colors. The test suite does not however include any test relative to asdf-ecl at this point, but I'm welcoming formal or informal test cases. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A Libertarian Constitutional Amendment: Congress shall make no law.

There have been fixes in ECL regarding asdf-ecl.

Oh, I now see that not all of them have made to the official ASDF: http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=history;f=contri... You know, if you would just tell me when you make such fixes, I'd merge them upstream faster. Also, it would be nice if those changes that are absolutely necessary for basic functionality go to asdf.lisp itself rather than asdf-ecl.lisp -- so that it is possible for e.g. quicklisp to only load asdf.lisp, then use it to load asdf-bundle, then be alright. For instance, is this line supposed to be in asdf or in asdf-ecl ? #+win32 (setf ext:*load-hooks* (append ext:*load-hooks* '(("asd" . si::load-source)))) and to avoid multiple entries, shouldn't I make it this instead? #+win32 (unless (assoc "asd" ext:*load-hooks* :test 'equal) (appendf ext:*load-hooks* '(("asd" . si::load-source)))) Also, this commit looks just wrong: http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=commitdiff;h=8ea... Instead you should (defclass compiled-file (component) ((type :initform "fas"))) or :initform nil if you want to force the user to specify the type, or (defmethod source-file-type ((component compiled-file) (s module)) (declare (ignorable s)) (pathname-type (compile-file-pathname pathname))) if you want to dynamically consult the results of compile-file-pathname. Currently, the second clause of your "or" is just wrong. I'm committing :initform nil in asdf because it's what looks most compatible with what you have currently: anything that worked with your current asdf-ecl should work that way, though it may not be a nice API.

I need to sit down and see how to push these back into asdf-bundle.

I pushed all these changes to asdf and asdf-bundle already. I helps that I can apply patch to one file, then apply the rejects to the next file.

Most important is the fact that I do not want the equivalent of asdf-ecl to be removed from what ECL users get when loading ASDF. This means I have to figure out how to bundle both asdf-bundle and asdf together.

This makes total sense. Could you have (require :asdf) do the equivalent of (load "asdf.lisp") (asdf:load-system :asdf-bundle) ? Then that would make less code to maintain for more results. Then again, if asdf-bundle is considered mature enough, it could be merged back into asdf itself if there is strong demand from ECL users.

But finally I would like to use this email to push one idea through, which that asdf-ecl is not optional for ECL. I have explained this several times, but one more will not hurt.

Would the "load asdf then have asdf load asdf-bundle" solution automatically when (require :asdf) is called satisfy you?

ECL uses shared libraries to load compiled files. In what here is considered normal operation, thousand compiled files may be loaded via, say, quicklisp. That is a waste of time and resources and hurts ECL's performance. ASDF-ECL provides a load operation, ASDF:LOAD-FASL-OP which does this and it should be the default operation for ECL, not the one that ASDF provides.

I can imagine asdf hooks by which you could make that the default for asdf:load-system as opposed to load-op.

My problem right now is that ASDF is moving on the opposite direction to what it should be. Since asdf-ecl is no longer part of ASDF, it gives the impression of less support. I also have seen recommendations in IRC to not use asdf-ecl and just use normal asdf operation, and as I said, this is wrong for ECL.

Currently, asdf-ecl *is* still part of ASDF and supported (except that since I have no test cases, I do not guarantee anything but "it compiles and we make a best effort to fix bugs"). Indeed I'd like in the future to move it out of ASDF into asdf-bundle, but I hope we can do that together in a way that minimizes disruption for ECL users.

Finally, I would like libraries such as quicklisp to use asdf:load-fasl-op with ECL, but if this is not sanctioned by ASDF, I doubt this will push through.

I'd like it to be sanctioned by ASDF. Once again, what about a hook so load-system can do something else than 'load-op ? asdf-bundle could then do that for you. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The kingly office is entitled to no respect. It was originally procured by the highwayman's methods; it remains a perpetuated crime, can never be anything but the symbol of a crime. It is no more entitled to respect than is the flag of a pirate. — Mark Twain