[asdf-devel] Re: software failures (with asdf 3?)
On Sun, Jul 7, 2013 at 8:12 AM, Zach Beane x...@xach.com wrote:
I upgraded my dist construction system to asdf 3.0 and get these
failures:
- exscribe: Don't know how to normalize (:FEATURE :EXSCRIBE-TYPESET
:CL-TYPESETTING). More info at
http://report.quicklisp.org/exscribe/2013-07-07/failtail.txt
Exscribe is working well for me.
The :FEATURE feature is an ASDF feature that was simultaneously broken
and undocumented in late ASDF1, has been fixed but cerror'ed during
the ASDF 2 days, and fixed and tested to work before ASDF3 (test in
place since 2.31.2).
Your backtrace suggests that the error happens in a package called
DEPCHECK, that doesn't know about this feature. I suppose you wrote
that package and need to teach it about :FEATURE. That's where I
realize that the :FEATURE feature is quite misdocumented in the
asdf.texinfo in the grammar production dependency-def (as opposed to
the very different, documented but deprecated feature in
requirement). Oh well. Not my problem anymore.
Robert, you might want to look into this:
* in dependency-def, it should be (:feature @var{feature-expression}
@var{dependency-def})
* the required-op production is redundant, since it's better covered
by the second branch of requirement.
* have a quick look at find-component.lisp to make sure the grammar is
properly documented; maybe document the new extensible protocol for
naming components.
- cl-launch: Could not load ASDF 2.27. More info at
http://report.quicklisp.org/cl-launch/2013-07-07/failtail.txt
Looks like you're using cl-launch 3.21.3 or earlier. Please upgrade to
the latest 3.22, available since last May (actually same as 3.21.7
from February).
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
There is never a better measure of what a person is than what he does when
he's absolutely free to choose. — William M. Bulger
Re: [asdf-devel] Re: software failures (with asdf 3?)
Faré wrote:
Robert, you might want to look into this:
* in dependency-def, it should be (:feature @var{feature-expression}
@var{dependency-def})
* the required-op production is redundant, since it's better covered
by the second branch of requirement.
* have a quick look at find-component.lisp to make sure the grammar is
properly documented; maybe document the new extensible protocol for
naming components.
I see the first two issues with the manual. I will apply a fix.
The last I will have a look at. I may have to come back to you with
some follow-up questions.
Zach, is there any way we could somehow provide a better API for your
DEPCHECK to use, so that you wouldn't have to worry about it getting out
of sync with ASDF? Suggestions welcome.
Best,
r
Re: [asdf-devel] Re: software failures (with asdf 3?)
Robert Goldman wrote:
Robert, you might want to look into this:
* in dependency-def, it should be (:feature @var{feature-expression}
@var{dependency-def})
OK, I thought I understood this, but I don't.
There's a second argument to :feature when used in a dependency-def, but
not when it's used in a dependency?
So we would see something like:
:depends-on (:cl-ppcre (:feature :clx clx-dependent-library))
and the semantics is
If (member :clx *features*) then clx-dependent-library is a dependency.
Correct?
Is there some reason why this isn't :if-feature or :when-feature? Using
:feature as a conditional seems odd
thanks,
r
Re: [asdf-devel] Re: software failures (with asdf 3?)
On Tue, Jul 9, 2013 at 2:41 PM, Robert Goldman rpgold...@sift.info wrote:
Robert Goldman wrote:
Robert, you might want to look into this:
* in dependency-def, it should be (:feature @var{feature-expression}
@var{dependency-def})
OK, I thought I understood this, but I don't.
There's a second argument to :feature when used in a dependency-def, but
not when it's used in a dependency?
In a :in-order-to spec, asdf:feature (not keyword:feature) can be used
instead of an operation specifier, to specify that the plan should
fail if the feature isn't present, which is then captured by
if-component-fails. This is a deprecated feature, with a braindead
design, and only remains as a compatibility mode for old versions of
SBCL's sb-bsd-sockets and sb-rotate-byte. I recommend you altogether
purge this mis-feature in a year or two.
So we would see something like:
:depends-on (:cl-ppcre (:feature :clx clx-dependent-library))
and the semantics is
If (member :clx *features*) then clx-dependent-library is a dependency.
Correct?
Yes.
Is there some reason why this isn't :if-feature or :when-feature? Using
:feature as a conditional seems odd
That's how it was named in e7e468 when it was introduced, though with
a buggy implementation. Renaming it :when-feature may make sense. Note
that I called the component-if-feature slot keyword :if-feature, which
you may want to either distinguish
yourself from or copy. You could even add an optional else-clause to
an :if-feature.
Considering how it never worked until ASDF3, I might be the only one
to ever have used it, in exscribe, and I'll happily stop using it
while you either transition or purge the feature altogether. It's only
really useful at for a system's :depends-on.
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
The worst thing about totalitarian regimes is not that they make people poor,
miserable and unfree — it's that they corrupt people's souls, and turning
everyone into a double-thinking, double-speaking liar for the sake of survival.
[asdf-devel] unsubscribe
Two things: The links to asdf-devel and asdf-announce on http://common-lisp.net/project/asdf/#mailing-lists are dead. Also, how do I unsubscribe? Brett
Re: [asdf-devel] Ordering of system :depends-on elements
09.07.2013, 06:17, Anton Vodonosov avodono...@yandex.ru: 08.07.2013, 01:34, Zach Beane x...@xach.com: A few projects in quicklisp work something like this: ;;; foo.asd (defsystem foo ...) (defsystem foo-extra ...) ;;; bar.asd (defsystem bar :depends-on (:foo-extra :foo)) With asdf 2, (asdf:load-system bar) seems to work fine, I guess because asdf 2 does the equivalent of find-system on the elements from right-to-left. With asdf 3, it doesn't seem to work fine, I guess because asdf 3 does the equivalent of find-system on the elements from left-to-right. Are those guesses correct? What's the best way to have a system definition that works equally well in asdf2 and asdf3 in this kind of situation? If we surround the non-findable system with the main system like this: (defsystem bar :depends-on (:foo :foo-extra :foo)) will it work? :) It's a dirty workaround (worksurround), but the level of dirtiness is the same as the original: have a system not findable by asdf:find-system due to difference between the system name and it's .asd file name; solve it by relying on the order ASDF loads dependencies, having a findable system name first. But the best solution is separation of these ASDF systems into different .asd files. Right now everyone seems to prefer dealing with systems written that way - separate .asd files per ASDF system.
Re: [asdf-devel] unsubscribe
Brett van de Sande b...@asu.edu writes: Two things: The links to asdf-devel and asdf-announce on http://common-lisp.net/project/asdf/#mailing-lists are dead. That's a feature. Also, how do I unsubscribe? By sending a message to asdf-devel+unsubscr...@common-lisp.net -- With best regards, Stas.
Re: [asdf-devel] unsubscribe
The links to asdf-devel and asdf-announce on http://common-lisp.net/project/asdf/#mailing-lists are dead. I have just set up a redirect, so it does work (kinda sorta) now. If you get a chance, can you test it? Sorry about that. -- drewc Also, how do I unsubscribe? Brett
