[Edited subject]
That begs the question: how should asdf be distributed?
Does it? I thought we were talking about asdf-driver.
Well, asdf-driver is currently developed together with asdf, which crucially depends on it. So how to distribute one with or without the other is a question; hopefully made less important by quicklisp.
Also, distributing asdf-driver separately from asdf makes for quadratic growth of potential upgrade issues to be wary of.
As asdf.lisp only?
Yes. As it always has been.
That is not the whole truth.
ASDF has been distributed in many ways; in order of chronology and progress, I can cite: * as a source file that you may load manually. * as code builtin to the image on Debian with C-L-C. * as part of some batteries-included Lisp distribution. * as a REQUIRE module provided by the Lisp implementation. * as a system and source file ready to upgrade any of the previous with a more advanced version on which you depend.
The latter solution has only worked since ASDF 2 (indeed, was the whole point of ASDF 2), and has allowed for some decoupling between what providers offer and was users may require, thus fostering nicer development.
These days, all actively-maintained implementations (except maybe SCL?) provide ASDF 2 as a REQUIRE module. Some of them are quite old (CLISP still provides 2.011), but all of them are able to locate a new ASDF in the source registry and upgrade themselves.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Economic illiteracy often leads one to take for wealth creation or cost reduction what is only a forced displacement of activity, with no primary gain, and a lot of secondary costs and negative side-effects. — Faré
OK, so I've put in the archives/ directory of asdf a few tarballs. See: http://common-lisp.net/project/asdf/archives/
The driver is in asdf-driver-2.26.118.tar.gz, which has only the general-purpose utilities. I minimally tested that loading it on top of 2.26 doesn't make 2.26 obviously not work. I'll fix backward incompatibility bugs when found. Remember: "If it's not backwards, it's not compatible". The solution is to promptly rename any function the semantics of which clashes.
The defsystem is in asdf-defsystem-2.26.118.tar.gz, which includes a bootstrapped asdf.lisp in addition to the defsystem-specific sources.
And an archive of the git repo plus a bootstrapped asdf.lisp is in asdf-2.26.118.tar.gz.
It's all build through a lisp script. Lisp scripting is so much more run than shell scripting, and it's easier than ever to do in a portable way thanks to asdf-driver and inferior-shell. See bin/asdf-builder for my "canonical" example.
I've finally debugged the CLISP upgrade, an issue with magic symbols for setf-functions.
Featurewise, there a now debugged and somewhat tested mini-language ensure-pathname. POIU was debugged, and its deferred-warning support was moved to asdf-driver, though not yet used in asdf-defsystem.
I devised a convention for putting multiple defsystems in a same file, with asdf being able to find all of them without ambiguity: foo.asd can contain system foo, foo/bar, foo/bar/baz, foo/quux, etc. This won't work on an old asdf, but going forward, you will be able to do that. asdf.asd itself already uses this trick to define asdf/defsystem.
logical pathnames get weirder. If you're crazy enough to use them in your source-registry, the files will be loaded as logical pathnames, at least on some implementations that don't translate-logical-pathname their *load-pathname*. You get what you're asking for. The central-registry keeps using probe-file, which will resolve to a truename.
I'm peddling a new operation 'build-op which should do "the default thing for this system", whatever that be. For asdf/defsystem, it's not load-op, it's concatenate-source-op.
At Stelian Ionescu's request, I implemented a :read-file-form way to point defsystem to a form that contains the version of a system or component. As an extension to what he requested, the form doesn't have to be the first in the file, but you can define a path of accessors to go grab the version number. For instance, POIU has (:read-file-form "poiu.lisp" :path (1 2 2)) which means the 3rd element of the third element of the second form (yay English having an off-by-one bug).
Less bugginess, more features. ASDF is not a "Lisp with batteries included" by far, but it is growing enough spare battery energy to let you go grab the bigger batteries.
The downside is it's bigger. The upside is that it's as many redundant libraries that you don't have to write and/or import on top of it, and it really makes Lisp scripting easier.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To have a right to do a thing is not at all the same as to be right in doing it. — G.K. Chesterton
Faré fahree@gmail.com writes:
OK, so I've put in the archives/ directory of asdf a few tarballs. See: http://common-lisp.net/project/asdf/archives/
The driver is in asdf-driver-2.26.118.tar.gz, which has only the general-purpose utilities.
Would you consider adding an URL like asdf-driver-latest.tgz that will always refer to the latest version?
Zach
OK, so I've put in the archives/ directory of asdf a few tarballs. See: http://common-lisp.net/project/asdf/archives/
Would you consider adding an URL like asdf-driver-latest.tgz that will always refer to the latest version?
Done:
(defun link-archive () (run `(ln -sf ,(tarname (driver-name)) (,*clnet-asdf-public* "archives/asdf-driver.tar.gz")) :show t :host *clnet*) (values))
While I'm at it, a present for foom, 2.26.119 will do its best to avoid resolving pathnames at all if *resolve-symlinks* is nil (please test with your setting).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Statists seek the solution to all human problems in arbitrary political power and bureaucracies above society. They choose to ignore that when they are not all too humans, politicians and bureaucrats are oh so inhuman.
Faré fahree@gmail.com writes:
OK, so I've put in the archives/ directory of asdf a few tarballs. See: http://common-lisp.net/project/asdf/archives/
Would you consider adding an URL like asdf-driver-latest.tgz that will always refer to the latest version?
Done:
(defun link-archive () (run `(ln -sf ,(tarname (driver-name)) (,*clnet-asdf-public* "archives/asdf-driver.tar.gz")) :show t :host *clnet*) (values))
While I'm at it, a present for foom, 2.26.119 will do its best to avoid resolving pathnames at all if *resolve-symlinks* is nil (please test with your setting).
Does it also fix the issue with the asdf-utils package name conflict?
Zach
On Fri, Jan 18, 2013 at 6:12 PM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes:
OK, so I've put in the archives/ directory of asdf a few tarballs. See: http://common-lisp.net/project/asdf/archives/
Would you consider adding an URL like asdf-driver-latest.tgz that will always refer to the latest version?
Done:
(defun link-archive () (run `(ln -sf ,(tarname (driver-name)) (,*clnet-asdf-public* "archives/asdf-driver.tar.gz")) :show t :host *clnet*) (values))
While I'm at it, a present for foom, 2.26.119 will do its best to avoid resolving pathnames at all if *resolve-symlinks* is nil (please test with your setting).
Does it also fix the issue with the asdf-utils package name conflict?
Which way do you want the conflict resolved? The current resolution is that asdf-utils.asd is an empty system that depends on asdf-driver.asd, and asdf-driver has the nickname asdf-utils, and exports about everything useful that asdf-utils used to; I omitted a few things that have changed name, but I can provide compatibility functions with the previous backward API if there's a demand.
If you think it's nicer to NOT have the same name, and/or to have asdf-utils a proxy package that imports and re-exports select symbols from asdf-driver, everything is possible.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Fraud is the homage that force pays to reason. — Charles Curtis
Faré fahree@gmail.com writes:
Does it also fix the issue with the asdf-utils package name conflict?
Which way do you want the conflict resolved? The current resolution is that asdf-utils.asd is an empty system that depends on asdf-driver.asd,
Now I don't get a package conflict, I get "Your ASDF version is too old." I'm using 2.26. Is taht really too old?
Zach
Now I don't get a package conflict, I get "Your ASDF version is too old." I'm using 2.26. Is taht really too old?
tldr: just update whichever libraries used to depend on xcvb-driver.
Long version:
That's message from xcvb-driver. I will make it clearer.
Yes, on the one hand, 2.26 is too old for xcvb-driver.
On the other hand, no program should be needing xcvb-driver anymore except xcvb itself (which is broken, in need of serious updating after the last year or so of asdf improvements; I just made a minimal adjustment so at least it compiles, and released that).
Now that asdf-driver does everything that xcvb-driver did and much more as far as everyone but xcvb itself is concerned, all my systems that used to depend on xcvb-driver for its runtime support instead depend on asdf-driver.
NB: The runtime support that used to be in xcvb-driver and is now in asdf-driver includes such things as: run-program, stream handling, condition muffling, environment access, command-line arguments, quitting, image dumping and restoring, etc.
From the old asdf, asdf-driver also has pathname abstractions,
encoding support, lisp compilation support, some generic configuration file support. And from two months of hacking, debugging, and automatic testing on 12 different implementations, asdf-driver has a more robust and self-sufficient version of all that, including a cleaned up API, a few general purpose utilities, and hot-upgradable package support.
In other words, I would like asdf-driver to become a universally available portability layer to bridge the differences between all CL implementations. The minimal "batteries included" that all Lisps require to interact with the underlying operating system in a portable way. I used to miss a usable, portable run-program, or access to command-line arguments. Now I have all that. It sure makes for a simpler cl-launch. Lisp scripting sure is more fun than shell scripting.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Corollaries to the Law of Bitur-Camember: The political process destroys the value of all known resources that are up for grabs. The socialist process of systematically denying legitimacy to property rights applies the political process universally and destroys the value of all available resources.
Faré fahree@gmail.com writes:
Now I don't get a package conflict, I get "Your ASDF version is too old." I'm using 2.26. Is taht really too old?
tldr: just update whichever libraries used to depend on xcvb-driver.
When will that work? Right now many things still fail with the most recent updates of everything, e.g. fare-utils, rpm, cl-launch, exscribe, etc.
Zach
When will that work? Right now many things still fail with the most recent updates of everything, e.g. fare-utils, rpm, cl-launch, exscribe, etc.
I just fixed rpm, but apart from that, the other ones have already been fixed yesterday at most.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "We will never get the money out of politics until we get the politics out of money." — Alex Tabarrok
Faré fahree@gmail.com writes:
When will that work? Right now many things still fail with the most recent updates of everything, e.g. fare-utils, rpm, cl-launch, exscribe, etc.
I just fixed rpm, but apart from that, the other ones have already been fixed yesterday at most.
Now I get ":ASDF does not match 2.26.114". Is that to be expected?
Zach
Now I get ":ASDF does not match 2.26.114". Is that to be expected?
OK, that was a message from cl-launch. I both improved the message, and scaled back the ASDF requirement to 2.015, with explicit loading of asdf-driver if old than that.
While I was at it, I had exscribe stop requiring cl-launch, by importing the two needed cl-launch functions that were too klugy to make it to asdf/driver.
Thanks again for the testing.
PS: I made sure ASDF 2.26.142 works minimally on GCL 2.6, Genera and LispWorks, in addition to all the automatically tested implementations. ASDF 2.27 is coming close. Now to try to get cleaner upgrade on ABCL, CLISP, CMUCL, and make sure cl-grid-test comes clean.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Common Lisp makes it easy for you to grow your own language; however, it makes it difficult for that language to be the same as anyone else's. — Faré
Faré fahree@gmail.com writes:
Now I get ":ASDF does not match 2.26.114". Is that to be expected?
OK, that was a message from cl-launch. I both improved the message, and scaled back the ASDF requirement to 2.015, with explicit loading of asdf-driver if old than that.
While I was at it, I had exscribe stop requiring cl-launch, by importing the two needed cl-launch functions that were too klugy to make it to asdf/driver.
fare-matcher fails because "FARE-UTILS does not designate any package".
This affects weblocks and other projects.
Zach
On Thu, Jan 24, 2013 at 9:58 AM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes: fare-matcher fails because "FARE-UTILS does not designate any package".
Oops, I had removed xcvb-utils, but still needed fare-utils (previous imported through fare-utils).
This affects weblocks and other projects.
This means that weblocks still didn't apply my patch getting rid of fare-matcher in favor of its worthy successor optima, in addition to .asd cleanups. Hopefully, the new ASDF is backward-compatible enough to work despite lack of such cleanups.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org #.(let((q`(#0=lambda(q)(labels((p(q)(if(atom q)(intern(#1=reverse(string q)))(#1#(mapcar #'p q))))(q(q)(subst q(eq q q)'(#2=defun p(&aux #2#nufed ,@''#3=etouq(xua& #3#)p tsil)((#0#(q)(setq q 't tsil q nufed(eval(list q (list'quote q)))))#3#)))))(nconc(q q)(p(q q)))))))(eval`(,q',q)))
Faré fahree@gmail.com writes:
On Thu, Jan 24, 2013 at 9:58 AM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes: fare-matcher fails because "FARE-UTILS does not designate any package".
Oops, I had removed xcvb-utils, but still needed fare-utils (previous imported through fare-utils).
By the way, this steady stream of "oops, ooops, oops, oops", is causing me a huge, huge, huge headache.
The short life of asdf-utils is causing me a huge headache.
The incompatibilities introduced in ASDF are causing me a huge headache.
This is a very annoying mess from my perspective. I haven't really gotten a grip on what the benefits are to make this (temporary?) pain worth it.
Zach
On Thu, Jan 24, 2013 at 11:41 AM, Zach Beane xach@xach.com wrote:
By the way, this steady stream of "oops, ooops, oops, oops", is causing me a huge, huge, huge headache.
My apologies. I've been focusing so much on ASDF that I forgot to update all the systems I maintain that indirectly depend on it. Now (only) I've added an automated test that all these systems can still load correctly.
The short life of asdf-utils is causing me a huge headache.
asdf-utils still exists. Now it's just a thin wrapper over asdf-driver. I broke it briefly, thinking it had no clients (none showing in quicklisp); I didn't you of all people were using it, after your complaining that asdf should export utilities at all.
The incompatibilities introduced in ASDF are causing me a huge headache.
I've been working hard to resolve them. There's no way the old ASDF could be fixed without a complete rewrite, and that was bound to introduce some minor incompatibilities, especially in cases where clients software were exploiting unsupported interfaces or outright bugs.
This is a very annoying mess from my perspective. I haven't really gotten a grip on what the benefits are to make this (temporary?) pain worth it.
I'll publish a feature update shortly.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Advertising may be described as the science of arresting the human intelligence long enough to get money from it. — Stephen Leacock.
Faré fahree@gmail.com writes:
The short life of asdf-utils is causing me a huge headache.
asdf-utils still exists. Now it's just a thin wrapper over asdf-driver. I broke it briefly, thinking it had no clients (none showing in quicklisp); I didn't you of all people were using it, after your complaining that asdf should export utilities at all.
When ASDF exported utilities, I did not use ASDF as library of utility functions.
When the independent library asdf-utils exported utilities, I used them.
The incompatibilities introduced in ASDF are causing me a huge headache.
I've been working hard to resolve them. There's no way the old ASDF could be fixed without a complete rewrite, and that was bound to introduce some minor incompatibilities, especially in cases where clients software were exploiting unsupported interfaces or outright bugs.
The only positive practical difference I've seen between ASDF 1 and ASDF 2 is the automatic FASL segregation.
Please keep an audience like me in mind when documenting feature updates.
Zach
The only positive practical difference I've seen between ASDF 1 and ASDF 2 is the automatic FASL segregation.
Which to work everywhere correctly by default requires non-trivial runtime support, configuration file support, pathname support, implementation-specific compilation support.
Oh yeah, did you notice that specifying either unix namestrings or relative pathnames in your system definitions just works, portably, on all implementations and all operating systems?
And did you notice that inter-module dependencies were propagated? (thanks to rpgoldman for the initial fix)
Did you notice that ASDF can be require'd out of the box on nine different implementations, and works on 14 plus variants, on four vastly different operating systems (though only two may really matter)?
Actually, the less you noticed about these issues, the better.
But it sometimes requires massive amount of work for users not to notice breakage that was inevitable in previous versions.
Hopefully, with ASDF 2.27 you won't notice the lack of weird failures as dependencies do not fail to be propagated anymore in the many cases that previous versions of ASDF could not conceivably cover due to deep conceptual bugs.
Also, Quicklisp is just a subset of the CL code out there; not breaking stuff in Quicklisp is good, but not breaking anything at all is good
Of course, but not always possible, when massive refactoring is due. If I break a never-exported feature that isn't used in quicklisp, and that I was never contacted about using, I feel that the failed user bears some responsibility.
Please keep an audience like me in mind when documenting feature updates.
I just send a quick summary of user-visible changes so far. I'll answer any questions about it.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reason wins in the long run, because irrational memes fight each other, whereas rational memes add up.
Faré fahree@gmail.com writes:
The short life of asdf-utils is causing me a huge headache.
asdf-utils still exists. Now it's just a thin wrapper over asdf-driver. I broke it briefly, thinking it had no clients (none showing in quicklisp);
Also, Quicklisp is just a subset of the CL code out there; not breaking stuff in Quicklisp is good, but not breaking anything at all is good too.
Zach
-
Faré -
Zach Beane