Congratulations, you're the first ever user of FEATURE dependencies! Please contact the asdf-devel mailing-list. [Condition of type SIMPLE-ERROR]
Cheers,
-- Nikodemus
On 15 October 2010 10:04, Nikodemus Siivola nikodemus@random-state.net wrote:
Congratulations, you're the first ever user of FEATURE dependencies! Please contact the asdf-devel mailing-list. [Condition of type SIMPLE-ERROR]
Well, if you want to use this feature, you win the right to: 1- remove the cerror from asdf.lisp 2- test that it actually does what you expect 3- document it (or have someone else document it) 4- commit it (or have me commit it) as asdf 2.137 (or whatever is the number)
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] To make an apple pie from scratch, you must first create the universe. — Carl Sagan
On 15 October 2010 17:27, Faré fahree@gmail.com wrote:
Well, if you want to use this feature, you win the right to: 1- remove the cerror from asdf.lisp 2- test that it actually does what you expect 3- document it (or have someone else document it) 4- commit it (or have me commit it) as asdf 2.137 (or whatever is the number)
Ok, I'll put this on my TODO: I think :DEPENDS-ON ((:FEATURES ...)) would be a nice way to indicate that something is eg. only meant for SBCL on Linux, or whatever.
Cheers,
-- Nikodemus
On 10/15/10 Oct 15 -9:45 AM, Nikodemus Siivola wrote:
On 15 October 2010 17:27, Faré fahree@gmail.com wrote:
Well, if you want to use this feature, you win the right to: 1- remove the cerror from asdf.lisp 2- test that it actually does what you expect 3- document it (or have someone else document it) 4- commit it (or have me commit it) as asdf 2.137 (or whatever is the number)
Ok, I'll put this on my TODO: I think :DEPENDS-ON ((:FEATURES ...)) would be a nice way to indicate that something is eg. only meant for SBCL on Linux, or whatever.
I'm going a little by memory, but IIRC the officially approved way of doing this in ASDF is very cumbersome.
You indicate a features-based dependency and then you have to set up an error-handler (well, effectively an error handler), using :if-component-dep-fails to say "and if this dependency fails, ignore it."
This is difficult to write and yields system dependencies that, IMO, are unnecessarily difficult to understand.
Personally, I always use the officially deprecated and non-declarative #+ approach which yields system definitions that are readable by any CL programmer.
I note, btw, that if-component-dep-fails is not documented in the defsystem grammar, nor is it used in an example, further enhancing the obscurity of this construct ;-)
Best, r
On 15 October 2010 19:49, Robert Goldman rpgoldman@sift.info wrote:
Ok, I'll put this on my TODO: I think :DEPENDS-ON ((:FEATURES ...)) would be a nice way to indicate that something is eg. only meant for SBCL on Linux, or whatever.
I'm going a little by memory, but IIRC the officially approved way of doing this in ASDF is very cumbersome.
You indicate a features-based dependency and then you have to set up an error-handler (well, effectively an error handler), using :if-component-dep-fails to say "and if this dependency fails, ignore it."
I've done this, and it works fine -- from eg. SB-CGA:
(:module "ports" :if-component-dep-fails :try-next :components ((:file "sbcl" :in-order-to ((compile-op (feature :sbcl)))) (:file "ccl" :in-order-to ((compile-op (feature :ccl))))))
The :DEPENDS-ON for the whole system in this case is intended for system introspection for things like Quicklisp -- or that's my idea at least.
Cheers,
-- Nikodemus
On 10/15/10 Oct 15 -11:57 AM, Nikodemus Siivola wrote:
On 15 October 2010 19:49, Robert Goldman rpgoldman@sift.info wrote:
Ok, I'll put this on my TODO: I think :DEPENDS-ON ((:FEATURES ...)) would be a nice way to indicate that something is eg. only meant for SBCL on Linux, or whatever.
I'm going a little by memory, but IIRC the officially approved way of doing this in ASDF is very cumbersome.
You indicate a features-based dependency and then you have to set up an error-handler (well, effectively an error handler), using :if-component-dep-fails to say "and if this dependency fails, ignore it."
I've done this, and it works fine -- from eg. SB-CGA:
(:module "ports" :if-component-dep-fails :try-next :components ((:file "sbcl" :in-order-to ((compile-op (feature :sbcl)))) (:file "ccl" :in-order-to ((compile-op (feature :ccl))))))
The :DEPENDS-ON for the whole system in this case is intended for system introspection for things like Quicklisp -- or that's my idea at least.
Cheers,
-- Nikodemus
Right. But, honestly, I find
(:module "ports" :components ( #+sbcl (:file "sbcl") #+ccl (:file "ccl")) ...)
a lot easier to read...
best r
On 15 October 2010 20:03, Robert Goldman rpgoldman@sift.info wrote:
Right. But, honestly, I find
(:module "ports" :components ( #+sbcl (:file "sbcl") #+ccl (:file "ccl")) ...)
a lot easier to read...
Sure -- but it makes system-introspection limited to the implementation you are currently using.
...of course, if ASDF had comething like
(:module "ports" :components (:file "sbcl" :when (feature :sbcl)) (:file "ccl" :when (feature :ccl)))
then we'd be pretty close to best of both worlds
Cheers,
-- Nikodemus
Nikodemus wrote:
...of course, if ASDF had comething like
(:module "ports" :components (:file "sbcl" :when (feature :sbcl)) (:file "ccl" :when (feature :ccl)))
then we'd be pretty close to best of both worlds
One could even flip that to a more lispy (:module "ports" :components (:when (feature :sbcl) (:file "sbcl") ...) (:when (feature :ccl) (:file "ccl")))
Which could even extend to (:when (feature :sbcl) (:module "sbcl-stuff" ...))
- Daniel
On 10/15/10 Oct 15 -12:15 PM, Nikodemus Siivola wrote:
On 15 October 2010 20:03, Robert Goldman rpgoldman@sift.info wrote:
Right. But, honestly, I find
(:module "ports" :components ( #+sbcl (:file "sbcl") #+ccl (:file "ccl")) ...)
a lot easier to read...
Sure -- but it makes system-introspection limited to the implementation you are currently using.
I get it, but the value of such introspection seems, at the moment, primarily conjectural, but the bewilderment of :if-component-dep-fails is certain. Actually, I also see that the manual says that :if-component-dep-fails may be broken (see the object model section).
...of course, if ASDF had comething like
(:module "ports" :components (:file "sbcl" :when (feature :sbcl)) (:file "ccl" :when (feature :ccl)))
then we'd be pretty close to best of both worlds
Agreed. This is clearly The Right Thing. Pretty much anyone looking at this will know what it is intended to mean whereas, IMO, the :if-component-dep-fails looks like an error-handler....
I think this is related to the fact that the feature "dependency" here is really not, intuitively, acting like a dependency (which is expected always to succeed).
best, r
Robert Goldman rpgoldman@sift.info writes:
On 10/15/10 Oct 15 -12:15 PM, Nikodemus Siivola wrote:
On 15 October 2010 20:03, Robert Goldman rpgoldman@sift.info wrote:
Right. But, honestly, I find
(:module "ports" :components ( #+sbcl (:file "sbcl") #+ccl (:file "ccl")) ...)
a lot easier to read...
Sure -- but it makes system-introspection limited to the implementation you are currently using.
I get it, but the value of such introspection seems, at the moment, primarily conjectural, but the bewilderment of :if-component-dep-fails is certain.
Not really.
For example, documentation generators use ASD files to as documentation root. It would be better if they could gather and document the various implementation specific parts without playing game with the lisp reader.
So a nice syntax/semantics like that proposed by Daniel would be beneficial, and could perhaps slighly promote the development of an ecology of static analysis tools.
Actually, I also see that the manual says that :if-component-dep-fails may be broken (see the object model section).
...of course, if ASDF had comething like
(:module "ports" :components (:file "sbcl" :when (feature :sbcl)) (:file "ccl" :when (feature :ccl)))
then we'd be pretty close to best of both worlds
Agreed. This is clearly The Right Thing. Pretty much anyone looking at this will know what it is intended to mean whereas, IMO, the :if-component-dep-fails looks like an error-handler....
I think this is related to the fact that the feature "dependency" here is really not, intuitively, acting like a dependency (which is expected always to succeed).
Call it CCI for "Conditionnal Component Inclusion". I like better Daniel's syntax too.
On 10/15/10 Oct 15 -2:00 PM, Pascal J. Bourguignon wrote:
Robert Goldman rpgoldman@sift.info writes:
On 10/15/10 Oct 15 -12:15 PM, Nikodemus Siivola wrote:
On 15 October 2010 20:03, Robert Goldman rpgoldman@sift.info wrote:
Right. But, honestly, I find
(:module "ports" :components ( #+sbcl (:file "sbcl") #+ccl (:file "ccl")) ...)
a lot easier to read...
Sure -- but it makes system-introspection limited to the implementation you are currently using.
I get it, but the value of such introspection seems, at the moment, primarily conjectural, but the bewilderment of :if-component-dep-fails is certain.
Not really.
For example, documentation generators use ASD files to as documentation root. It would be better if they could gather and document the various implementation specific parts without playing game with the lisp reader.
Agreed. But the number of systems that have such documentation generators are EXTREMELY limited.
We have a bunch of systems that just use variations of Edi's hack that simply use the package system, and ignore the ASDF-ness entirely.
Once upon a time I tried to use one of the ASDF-based doc generators (I believe it was Gary's TINAA) and found that the generator had to replicate so much of ASDF in it (and a fair amount of the Lisp reader, too!) that it was too brittle to be practical.
The problem is that ASDF is, even when introspective, all about FILES. But Lisp documentation systems typically are centered around SYMBOLS, and there's no easy way to go from ASDF system definitions to SYMBOLS. It's a heck of a lot easier to go from *PACKAGES* to SYMBOLS....
So a nice syntax/semantics like that proposed by Daniel would be beneficial, and could perhaps slighly promote the development of an ecology of static analysis tools.
Despite the above, I agree with you about this --- IF it's possible to have readable system definitions AND introspection, then that's obviously The Right Thing.
But given the status quo, where you can have readable system definitions OR (exclusively) introspection, I'll take readability.
Best, r
Robert Goldman rpgoldman@sift.info writes:
On 10/15/10 Oct 15 -2:00 PM, Pascal J. Bourguignon wrote:
Robert Goldman rpgoldman@sift.info writes:
On 10/15/10 Oct 15 -12:15 PM, Nikodemus Siivola wrote:
On 15 October 2010 20:03, Robert Goldman rpgoldman@sift.info wrote:
Right. But, honestly, I find
(:module "ports" :components ( #+sbcl (:file "sbcl") #+ccl (:file "ccl")) ...)
a lot easier to read...
Sure -- but it makes system-introspection limited to the implementation you are currently using.
I get it, but the value of such introspection seems, at the moment, primarily conjectural, but the bewilderment of :if-component-dep-fails is certain.
Not really.
For example, documentation generators use ASD files to as documentation root. It would be better if they could gather and document the various implementation specific parts without playing game with the lisp reader.
Agreed. But the number of systems that have such documentation generators are EXTREMELY limited.
We have a bunch of systems that just use variations of Edi's hack that simply use the package system, and ignore the ASDF-ness entirely.
Once upon a time I tried to use one of the ASDF-based doc generators (I believe it was Gary's TINAA) and found that the generator had to replicate so much of ASDF in it (and a fair amount of the Lisp reader, too!) that it was too brittle to be practical.
The problem is that ASDF is, even when introspective, all about FILES. But Lisp documentation systems typically are centered around SYMBOLS, and there's no easy way to go from ASDF system definitions to SYMBOLS. It's a heck of a lot easier to go from *PACKAGES* to SYMBOLS....
So a nice syntax/semantics like that proposed by Daniel would be beneficial, and could perhaps slighly promote the development of an ecology of static analysis tools.
Despite the above, I agree with you about this --- IF it's possible to have readable system definitions AND introspection, then that's obviously The Right Thing.
But given the status quo, where you can have readable system definitions OR (exclusively) introspection, I'll take readability.
Yes, come to think about it, if the documentation system wants to read the sources written for another implementation, it will have to implement its own reader anyways. (A cross-documentation system let's say).
Robert Goldman wrote:
On 10/15/10 Oct 15 -2:00 PM, Pascal J. Bourguignon wrote:
Robert Goldman rpgoldman@sift.info
I get it, but the value of such introspection seems, at the moment, primarily conjectural, but the bewilderment of :if-component-dep-fails is certain.
Not really.
For example, documentation generators use ASD files to as documentation root. It would be better if they could gather and document the various implementation specific parts without playing game with the lisp reader.
Agreed. But the number of systems that have such documentation generators are EXTREMELY limited.
There are a few documentation generators that grovel any asdf system by name. Example: declt http://www.lrde.epita.fr/~didier/software/lisp/misc.php
Regardless, tools like LibCL and Quicklisp could use this information for other reasons. For example, to load systems in the proper order, to download systems before compiling, to generate documentation including all possible dependencies, etc.
The uses are very real. I would like an interface that could cull things during the normal ops, but would "satisfy everything" during introspection ops. Maybe something like asdf:*all-conditions-pass*?
This would be much nicer than tricks like temporarily binding *features*.
There is also an obscure error potentially waiting for users of #+ and #-. As asdf reads system definitions, the reader won't expand features that will be set as systems load. If asdf then caches the definitions it has found...
Example: Start with two systems, X and Y, and a fresh lisp image. X depends on Y X.asd contains "#+Y-feature X-stuff" Y pushes :Y-feature to *features* while loading
(asdf:oos 'asdf:load-op :X)
Question: Was "X-stuff" read and executed? Does the result change if we load Y then X in two separate operations?
Special care would still be needed for the (:when x y) API, but it wouldn't require reinvoking the reader.
Later, Daniel
-
dherring＠tentpost.com -
Faré -
Nikodemus Siivola -
pjb＠informatimago.com -
Robert Goldman