Re: [asdf-devel] Still having problems on upgrade tests

2013-03-03 Thread Faré 
> Probably what we most care about is upgrading from the current bundled
> version to the head and released versions in git.
>
Yes, and that's the first thing we test indeed when we run the upgrade test.

>> Is the test just to make sure that an upgrade works properly for people
>> who might have saved images and want to update their asdf in that same
>> image?
>
> I will leave these to Faré to answer...
>
For people who might have saved an image.
For people who are using an old C-L-C that *did* save an image
(don't laugh: my work laptop, running a 2010 ubuntu, has c-l-c 6.18
saving an image of clisp or sbcl with ASDF 1.374 from December 2009).
For people using require on an old Lisp that provides an old ASDF
(e.g. CLISP today still ships with ASDF 2.011 from November 2010).
For finding bugs in the ASDF upgrade process itself.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
It is not recognized in the full amplitude of the word that all freedom is
essentially self-liberation — that I can have only so much freedom as I
procure for myself by my ownness. — Max Stirner

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] Still having problems on upgrade tests

2013-03-03 Thread Faré 
> The following seems to be the crux of the issue:
>
> ; Upgraded ASDF from version 1.85 to version 2.31.8
> ; Registering #
> ;;; Writing fasl file /Users/rpg/lisp/asdf/build/asdf.fasl
>
> this should be in an implementation-specific subdirectory, but isn't.
>
Well, 1.85 doesn't have asdf-output-translations.

Considering that about no one should be using asdf 1
(except that my work laptop still runs an antique ubuntu with
common-lisp-controller 6.18 and asdf 1.374),
we could eschew the upgrade tests from asdf 1.x.
What if you edit run-tests.sh function upgrade_tags
to NOT try to upgrade from the 1.x versions?
And/or edit valid_upgrade_test_p
to avoid upgrade tests on allegro and 1.x?

> Is there any chance this could be because I am not running bash?  Or
> somehow something is briefly turning off the output-redirection?
>
Well, it's vaguely possible that something happens on your system
that interferes with proper output translations and/or cleanup.

Note that the first ASDF_UPGRADE_TEST_METHODS is
'load-asdf-lisp'load-asdf-lisp-clean
precisely to clean the fasl from previous lisps or lisp versions used.
If you overrode that variable, it could explain why some things are wrong.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
When you are young you are afraid people will steal your ideas;
when you are old you are afraid they won't. — David D. Friedman

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] Still having problems on upgrade tests

2013-03-03 Thread Robert Goldman 
On 3/3/13 Mar 3 -8:08 PM, Faré wrote:
> I don't understand what could be going on. Of course, and especially
> so when we're testing upgrades, there's plenty of pathname magic and
> configuration switching going on. But I can't imagine what's at stake
> to make it work for me and not for you. Are you using the latest
> checkout from the master branch, as opposed to the release branch?
> 
> Did you try to make mrproper and/or git clean -xfd to remove any
> parasite files from your checkout?

Yes, and I did a git diff to check.

The following seems to be the crux of the issue:

; Upgraded ASDF from version 1.85 to version 2.31.8
; Registering #
;;; Writing fasl file /Users/rpg/lisp/asdf/build/asdf.fasl

this should be in an implementation-specific subdirectory, but isn't.

Is there any chance this could be because I am not running bash?  Or
somehow something is briefly turning off the output-redirection?

I'll try to pry into this tomorrow.

best,
r

> 
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> Lubarsky's Law of Cybernetic Entomology:
> There's always one more bug.
> 
> 
> On Sun, Mar 3, 2013 at 8:46 PM, Robert Goldman  wrote:
>> On 3/3/13 Mar 3 -5:38 PM, Faré wrote:
>>> On Sun, Mar 3, 2013 at 5:41 PM, Robert Goldman  wrote:
 The upgrade test for ACL from 1.85 fails reliably with this error:

 Warning: COMPILE-FILE warned while performing # on
 #.
 Warning: COMPILE-FILE failed while performing # on
 #.
 TEST ABORTED:
 #P"/Users/rpg/lisp/asdf/build/fasls/acl-8.2m-macosx-x64/asdf/build/asdf.fasl"
 does not exist, cannot load
>>> [...]
 Script failed
 upgrade FAILED for allegromodern from 1.85 using method
 'load-asdf-lisp'load-asdf-system

 Interestingly, when I paste the replication string into bash:

 ASDF_UPGRADE_TEST_TAGS="1.85"
 ASDF_UPGRADE_TEST_METHODS="'load-asdf-lisp'load-asdf-system"
 ./test/run-tests.sh -u allegromodern

 this works fine.

 So this only fails for me when running in the context of make

>>> Works for me, at least with Allegro 9.0:
>>>
>>> make u l=allegro ASDF_UPGRADE_TEST_TAGS=1.85
>>> make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85
>>
>> I'm stumped.  It fails for me on Allegro 9.0 just as with 8.2
>>
>> Note that this happens for me in the context of 'make test-all'
>>
>>
>> make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85
>>
>> also fails...
>>
>> Somehow the build is not working:
>>
>> rpg% ls
>> /Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl
>> ls: cannot access
>> /Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl:
>> No such file or directory
>>
>> For some reason, I have no asdf.fasl there, but I *do* have an asdf.lisp...
>>
>> I see this, which indicates that the fasl is being written in the wrong
>> location:
>>
>> ; Registering #
>> ;;; Writing fasl file /Users/rpg/lisp/asdf/build/asdf.fasl
>> ;;; Fasl write complete
>> Warning: COMPILE-FILE warned while performing # on
>> #.
>> Warning: COMPILE-FILE failed while performing # on
>> #.
>>
>> And that's the file, alright:
>>
>> pg% head build/asdf.fasl
>> ?z??#<> /Users/rpg/lisp/asdf/build/asdf.lisp by rpg on
>> rpgoldman-3.local at 2013-03-03T19:40:46+06\
>> using 9.0 [64-bit Mac OS X (Intel)] (Feb 26, 2013 9:53)\
>> fasl version = 63\
>> runtime version = 33\
>> for non-smp lisps; #+8-bit-specific code; #+16-bit-specific code\
>> Optimization settings at wfasl time:\
>> ((safety 3) (space 1) (speed 2) (compilation-speed 1) (debug 2))\
>>
>> So is there something going awry in the build process?
>>
>> Best,
>> r
>>
>>
>>>
>>> I can't try allegro 8.2, because my license has expired, and Franz
>>> only offers one until January 31st 2013, and I don't feel like
>>> cheating on the system date:
>>> http://www.franz.com/products/express/
>>>
>>> Is it a case of confusion whereby we changed the way the
>>> implementation identifier is computed, and asdf creates the fasl in
>>> one directory but somehow looks for it in another?
>>>
>>> What is the command that makes it fail, already?
>>>
>>> —♯ƒ • 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
>>>
>>


___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] Still having problems on upgrade tests

2013-03-03 Thread Robert Goldman 
On 3/3/13 Mar 3 -8:56 PM, Dave Cooper wrote:
> 
> 
> Hi Robert,
> 
> If you can outline for me the steps to do it, I can try this on ACL 8.2
> and 9.0 on Windows and Linux, if you like...

I am just doing the following:

setting ASDF_TEST_LISPS to a list of the lisps I have installed (this
would be at least "allegro allegromodern" for you, and perhaps some others.

Then I can do

make test-all

and the scripts will run both static and upgrade tests for all the lisps
in ASDF_TEST_LISPS.

I also have 8.2 and 9.0.  Unfortunately, the make scripts right now
aren't that friendly to testing both -- what I do is test each one
separately by pushing its install directory onto the shell PATH.

> 
> By the way, out of curiosity, why is it necessary to upgrade asdf for
> Allegro? Do you have an image with asdf built in? Franz ships
> code/asdf.fasl then updates with code/asdf.xyz - right now (for 9.0 at
> least) they are on asdf.002 which just came down last week and is 2.31.1
> I believe. So normally the Allegro will just load the latest asdf fasl
> on demand.

One nuisance I have noticed is that they have updated the fasls in 8.2
without updating src/asdf.lisp, which means that the asdf you have
loaded has drifted from the one for which you have source

Probably what we most care about is upgrading from the current bundled
version to the head and released versions in git.

> 
> Is the test just to make sure that an upgrade works properly for people
> who might have saved images and want to update their asdf in that same
> image? 


I will leave these to Faré to answer...

cheers,
r

> 
> Regards,
> 
>  Dave
> 
> 
> 
> 
> On Sun, Mar 3, 2013 at 8:46 PM, Robert Goldman  > wrote:
> 
> On 3/3/13 Mar 3 -5:38 PM, Faré wrote:
> > On Sun, Mar 3, 2013 at 5:41 PM, Robert Goldman
> mailto:rpgold...@sift.info>> wrote:
> >> The upgrade test for ACL from 1.85 fails reliably with this error:
> >>
> >> Warning: COMPILE-FILE warned while performing # on
> >> #.
> >> Warning: COMPILE-FILE failed while performing # on
> >> #.
> >> TEST ABORTED:
> >>
> 
> #P"/Users/rpg/lisp/asdf/build/fasls/acl-8.2m-macosx-x64/asdf/build/asdf.fasl"
> >> does not exist, cannot load
> > [...]
> >> Script failed
> >> upgrade FAILED for allegromodern from 1.85 using method
> >> 'load-asdf-lisp'load-asdf-system
> >>
> >> Interestingly, when I paste the replication string into bash:
> >>
> >> ASDF_UPGRADE_TEST_TAGS="1.85"
> >> ASDF_UPGRADE_TEST_METHODS="'load-asdf-lisp'load-asdf-system"
> >> ./test/run-tests.sh -u allegromodern
> >>
> >> this works fine.
> >>
> >> So this only fails for me when running in the context of make
> >>
> > Works for me, at least with Allegro 9.0:
> >
> > make u l=allegro ASDF_UPGRADE_TEST_TAGS=1.85
> > make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85
> 
> I'm stumped.  It fails for me on Allegro 9.0 just as with 8.2
> 
> Note that this happens for me in the context of 'make test-all'
> 
> 
> make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85
> 
> also fails...
> 
> Somehow the build is not working:
> 
> rpg% ls
> /Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl
> ls: cannot access
> /Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl:
> No such file or directory
> 
> For some reason, I have no asdf.fasl there, but I *do* have an
> asdf.lisp...
> 
> I see this, which indicates that the fasl is being written in the wrong
> location:
> 
> ; Registering #
> ;;; Writing fasl file /Users/rpg/lisp/asdf/build/asdf.fasl
> ;;; Fasl write complete
> Warning: COMPILE-FILE warned while performing # on
> #.
> Warning: COMPILE-FILE failed while performing # on
> #.
> 
> And that's the file, alright:
> 
> pg% head build/asdf.fasl
> ?z??#<> /Users/rpg/lisp/asdf/build/asdf.lisp by rpg on
> rpgoldman-3.local at 2013-03-03T19:40:46+06\
> using 9.0 [64-bit Mac OS X (Intel)] (Feb 26, 2013 9:53)\
> fasl version = 63\
> runtime version = 33\
> for non-smp lisps; #+8-bit-specific code; #+16-bit-specific code\
> Optimization settings at wfasl time:\
> ((safety 3) (space 1) (speed 2) (compilation-speed 1) (debug 2))\
> 
> So is there something going awry in the build process?
> 
> Best,
> r
> 
> 
> >
> > I can't try allegro 8.2, because my license has expired, and Franz
> > only offers one until January 31st 2013, and I don't feel like
> > cheating on the system date:
> > http://www.franz.com/products/express/
> >
> > Is it a case of confusion whereby we changed the way the
> > implementation identifier is computed, and asdf creates the fasl in
> > one directory but somehow looks for it in another?
> >
> > What is the command that makes it fail, already?
> >
> > —

Re: [asdf-devel] testing ASDF with cl-test-grid

2013-03-03 Thread Anton Vodonosov 
04.03.2013, 06:42, "Faré" :
> On Sun, Mar 3, 2013 at 9:39 PM, Anton Vodonosov  wrote:
>>  Yes, buildapp is the only new regression we haven't seen before.
>
> Oh, we have seen it before. 

Yes, I have found it in previous results.

>>  Meantime, the table is updated with CCL results:
>>  http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html
>>
>>  Nothing new on CCL, we saw all these failures previously.
>
> OK. I'll run some tests from work tomorrow, and release an ASDF 2.32.

Tomorrow there will also be results from CLISP, ECL and CMUCL.
ABCL will take longer.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] testing ASDF with cl-test-grid

2013-03-03 Thread Faré 
On Sun, Mar 3, 2013 at 9:39 PM, Anton Vodonosov  wrote:
> 04.03.2013, 05:49, "Faré" :
>> OK, so the results are massively positive, and the failures all known
>> and most of them already fixed upstream. I'll ping keithj again — he
>> fixed cl-sam already, but still hasn't fixed deoxybytes-systems. Apart
>> from that, the only system that looks like it loses and doesn't have a
>> fix yet is buildapp, but I'm confident Xach will fix it sooner than
>> later.
>
> Positive changes are mostly due to utf-8.
> Yes, buildapp is the only new regression we haven't seen before.
>
Oh, we have seen it before. It's just that Xach is still in "wait and
see" mode regarding ASDF, and not moving on that one, yet.

> Meantime, the table is updated with CCL results:
> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html
>
> Nothing new on CCL, we saw all these failures previously.
>
OK. I'll run some tests from work tomorrow, and release an ASDF 2.32.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
First they ignore you. Then they laugh at you.
Then they fight you. Then you win.
— Gandhi

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] testing ASDF with cl-test-grid

2013-03-03 Thread Anton Vodonosov 
04.03.2013, 05:49, "Faré" :
> OK, so the results are massively positive, and the failures all known
> and most of them already fixed upstream. I'll ping keithj again — he
> fixed cl-sam already, but still hasn't fixed deoxybytes-systems. Apart
> from that, the only system that looks like it loses and doesn't have a
> fix yet is buildapp, but I'm confident Xach will fix it sooner than
> later.

Positive changes are mostly due to utf-8.
Yes, buildapp is the only new regression we haven't seen before.

Meantime, the table is updated with CCL results:
http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html

Nothing new on CCL, we saw all these failures previously.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] Still having problems on upgrade tests

2013-03-03 Thread Faré 
I don't understand what could be going on. Of course, and especially
so when we're testing upgrades, there's plenty of pathname magic and
configuration switching going on. But I can't imagine what's at stake
to make it work for me and not for you. Are you using the latest
checkout from the master branch, as opposed to the release branch?

Did you try to make mrproper and/or git clean -xfd to remove any
parasite files from your checkout?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Lubarsky's Law of Cybernetic Entomology:
There's always one more bug.


On Sun, Mar 3, 2013 at 8:46 PM, Robert Goldman  wrote:
> On 3/3/13 Mar 3 -5:38 PM, Faré wrote:
>> On Sun, Mar 3, 2013 at 5:41 PM, Robert Goldman  wrote:
>>> The upgrade test for ACL from 1.85 fails reliably with this error:
>>>
>>> Warning: COMPILE-FILE warned while performing # on
>>> #.
>>> Warning: COMPILE-FILE failed while performing # on
>>> #.
>>> TEST ABORTED:
>>> #P"/Users/rpg/lisp/asdf/build/fasls/acl-8.2m-macosx-x64/asdf/build/asdf.fasl"
>>> does not exist, cannot load
>> [...]
>>> Script failed
>>> upgrade FAILED for allegromodern from 1.85 using method
>>> 'load-asdf-lisp'load-asdf-system
>>>
>>> Interestingly, when I paste the replication string into bash:
>>>
>>> ASDF_UPGRADE_TEST_TAGS="1.85"
>>> ASDF_UPGRADE_TEST_METHODS="'load-asdf-lisp'load-asdf-system"
>>> ./test/run-tests.sh -u allegromodern
>>>
>>> this works fine.
>>>
>>> So this only fails for me when running in the context of make
>>>
>> Works for me, at least with Allegro 9.0:
>>
>> make u l=allegro ASDF_UPGRADE_TEST_TAGS=1.85
>> make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85
>
> I'm stumped.  It fails for me on Allegro 9.0 just as with 8.2
>
> Note that this happens for me in the context of 'make test-all'
>
>
> make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85
>
> also fails...
>
> Somehow the build is not working:
>
> rpg% ls
> /Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl
> ls: cannot access
> /Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl:
> No such file or directory
>
> For some reason, I have no asdf.fasl there, but I *do* have an asdf.lisp...
>
> I see this, which indicates that the fasl is being written in the wrong
> location:
>
> ; Registering #
> ;;; Writing fasl file /Users/rpg/lisp/asdf/build/asdf.fasl
> ;;; Fasl write complete
> Warning: COMPILE-FILE warned while performing # on
> #.
> Warning: COMPILE-FILE failed while performing # on
> #.
>
> And that's the file, alright:
>
> pg% head build/asdf.fasl
> ?z??#<> /Users/rpg/lisp/asdf/build/asdf.lisp by rpg on
> rpgoldman-3.local at 2013-03-03T19:40:46+06\
> using 9.0 [64-bit Mac OS X (Intel)] (Feb 26, 2013 9:53)\
> fasl version = 63\
> runtime version = 33\
> for non-smp lisps; #+8-bit-specific code; #+16-bit-specific code\
> Optimization settings at wfasl time:\
> ((safety 3) (space 1) (speed 2) (compilation-speed 1) (debug 2))\
>
> So is there something going awry in the build process?
>
> Best,
> r
>
>
>>
>> I can't try allegro 8.2, because my license has expired, and Franz
>> only offers one until January 31st 2013, and I don't feel like
>> cheating on the system date:
>> http://www.franz.com/products/express/
>>
>> Is it a case of confusion whereby we changed the way the
>> implementation identifier is computed, and asdf creates the fasl in
>> one directory but somehow looks for it in another?
>>
>> What is the command that makes it fail, already?
>>
>> —♯ƒ • 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
>>
>

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] testing ASDF with cl-test-grid

2013-03-03 Thread Faré 
OK, so the results are massively positive, and the failures all known
and most of them already fixed upstream. I'll ping keithj again — he
fixed cl-sam already, but still hasn't fixed deoxybytes-systems. Apart
from that, the only system that looks like it loses and doesn't have a
fix yet is buildapp, but I'm confident Xach will fix it sooner than
later.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Suicidal terrorists may have short shelf lives.  — John McCarthy


On Sun, Mar 3, 2013 at 8:10 PM, Anton Vodonosov  wrote:
> As there were some fixes, running tests again.
>
> ASDF version 2.31.8
> Quicklisp version is shifted to 2013-02-17.
>
> SBCL results arrived already:
> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html
>
> Other will follow.
>
> ___
> asdf-devel mailing list
> asdf-devel@common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] Still having problems on upgrade tests

2013-03-03 Thread Robert Goldman 
On 3/3/13 Mar 3 -5:38 PM, Faré wrote:
> On Sun, Mar 3, 2013 at 5:41 PM, Robert Goldman  wrote:
>> The upgrade test for ACL from 1.85 fails reliably with this error:
>>
>> Warning: COMPILE-FILE warned while performing # on
>> #.
>> Warning: COMPILE-FILE failed while performing # on
>> #.
>> TEST ABORTED:
>> #P"/Users/rpg/lisp/asdf/build/fasls/acl-8.2m-macosx-x64/asdf/build/asdf.fasl"
>> does not exist, cannot load
> [...]
>> Script failed
>> upgrade FAILED for allegromodern from 1.85 using method
>> 'load-asdf-lisp'load-asdf-system
>>
>> Interestingly, when I paste the replication string into bash:
>>
>> ASDF_UPGRADE_TEST_TAGS="1.85"
>> ASDF_UPGRADE_TEST_METHODS="'load-asdf-lisp'load-asdf-system"
>> ./test/run-tests.sh -u allegromodern
>>
>> this works fine.
>>
>> So this only fails for me when running in the context of make
>>
> Works for me, at least with Allegro 9.0:
> 
> make u l=allegro ASDF_UPGRADE_TEST_TAGS=1.85
> make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85

I'm stumped.  It fails for me on Allegro 9.0 just as with 8.2

Note that this happens for me in the context of 'make test-all'


make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85

also fails...

Somehow the build is not working:

rpg% ls
/Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl
ls: cannot access
/Users/rpg/lisp/asdf/build/fasls/acl-9.0m-macosx-x64/asdf/build/asdf.fasl:
No such file or directory

For some reason, I have no asdf.fasl there, but I *do* have an asdf.lisp...

I see this, which indicates that the fasl is being written in the wrong
location:

; Registering #
;;; Writing fasl file /Users/rpg/lisp/asdf/build/asdf.fasl
;;; Fasl write complete
Warning: COMPILE-FILE warned while performing # on
#.
Warning: COMPILE-FILE failed while performing # on
#.

And that's the file, alright:

pg% head build/asdf.fasl
?z??#<> /Users/rpg/lisp/asdf/build/asdf.lisp by rpg on
rpgoldman-3.local at 2013-03-03T19:40:46+06\
using 9.0 [64-bit Mac OS X (Intel)] (Feb 26, 2013 9:53)\
fasl version = 63\
runtime version = 33\
for non-smp lisps; #+8-bit-specific code; #+16-bit-specific code\
Optimization settings at wfasl time:\
((safety 3) (space 1) (speed 2) (compilation-speed 1) (debug 2))\

So is there something going awry in the build process?

Best,
r


> 
> I can't try allegro 8.2, because my license has expired, and Franz
> only offers one until January 31st 2013, and I don't feel like
> cheating on the system date:
> http://www.franz.com/products/express/
> 
> Is it a case of confusion whereby we changed the way the
> implementation identifier is computed, and asdf creates the fasl in
> one directory but somehow looks for it in another?
> 
> What is the command that makes it fail, already?
> 
> —♯ƒ • 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
> 


___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] testing ASDF with cl-test-grid

2013-03-03 Thread Anton Vodonosov 
As there were some fixes, running tests again. ASDF version 2.31.8Quicklisp version is shifted to 2013-02-17. SBCL results arrived already:http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html Other will follow.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] Still having problems on upgrade tests

2013-03-03 Thread Faré 
On Sun, Mar 3, 2013 at 5:41 PM, Robert Goldman  wrote:
> The upgrade test for ACL from 1.85 fails reliably with this error:
>
> Warning: COMPILE-FILE warned while performing # on
> #.
> Warning: COMPILE-FILE failed while performing # on
> #.
> TEST ABORTED:
> #P"/Users/rpg/lisp/asdf/build/fasls/acl-8.2m-macosx-x64/asdf/build/asdf.fasl"
> does not exist, cannot load
[...]
> Script failed
> upgrade FAILED for allegromodern from 1.85 using method
> 'load-asdf-lisp'load-asdf-system
>
> Interestingly, when I paste the replication string into bash:
>
> ASDF_UPGRADE_TEST_TAGS="1.85"
> ASDF_UPGRADE_TEST_METHODS="'load-asdf-lisp'load-asdf-system"
> ./test/run-tests.sh -u allegromodern
>
> this works fine.
>
> So this only fails for me when running in the context of make
>
Works for me, at least with Allegro 9.0:

make u l=allegro ASDF_UPGRADE_TEST_TAGS=1.85
make u l=allegromodern ASDF_UPGRADE_TEST_TAGS=1.85

I can't try allegro 8.2, because my license has expired, and Franz
only offers one until January 31st 2013, and I don't feel like
cheating on the system date:
http://www.franz.com/products/express/

Is it a case of confusion whereby we changed the way the
implementation identifier is computed, and asdf creates the fasl in
one directory but somehow looks for it in another?

What is the command that makes it fail, already?

—♯ƒ • 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

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

[asdf-devel] Still having problems on upgrade tests

2013-03-03 Thread Robert Goldman 
The upgrade test for ACL from 1.85 fails reliably with this error:

Warning: COMPILE-FILE warned while performing # on
#.
Warning: COMPILE-FILE failed while performing # on
#.
TEST ABORTED:
#P"/Users/rpg/lisp/asdf/build/fasls/acl-8.2m-macosx-x64/asdf/build/asdf.fasl"
does not exist, cannot load
Evaluation stack:
; Autoloading for make-broadcast-stream:
;   Fast loading /usr/local/acl/acl82.64/code/streamc.003
;;; Installing streamc patch, version 3.
; Fast loading from bundle code/efft-utf8-base.fasl.
; Fast loading from bundle code/efft-void.fasl.
; Fast loading from bundle code/efft-latin1-base.fasl.

 ->(sys::..runtime-operation #11="applyn" . #1=(:unknown-args))
   (tpl:do-command #2="zoom" . #)
   (sys::..runtime-operation #5="lisp_apply" . #1#)
   [... excl::eval-as-progn ]
   (let

. #3=(((*terminal-io* stream)
   (*standard-output* stream)
   (tpl:*zoom-print-circle* *print-circle*)
   (tpl:*zoom-print-level* *print-level*)
   (tpl:*zoom-print-length* *print-length*))
  (tpl:do-command
   #2#
   :from-read-eval-print-loop
   nil
   :count
   t
   :all
   t)))
   [... excl::eval-as-progn ]
   (block asdf/image:raw-print-backtrace (let . #3#))
   [... excl::%eval ]
   (asdf/image:raw-print-backtrace

:stream
#4=#
:count
69)
   (sys::..runtime-operation #10="comp_to_interp" :stream #4# :count 69)
   (sys::..runtime-operation #5# . #1#)
   [... excl::eval-as-progn ]
   (let*

. #7=(((#6=#:g822995
. #19=((cons
(load-time-value excl::.ignore-errors-1.)
(excl::fast excl::*handler-clusters*
   (excl::*handler-clusters* #6#))
  (declare
   (dynamic-extent #6# . #21=(excl::*handler-clusters*)))
  (progn
   . #8=((apply
  'asdf/image:raw-print-backtrace
  asdf/image::keys)
   [... excl::eval-as-progn ]
   (catch #22='excl::ignore-errors-1 (let* . #7#))
   [... excl::eval-as-progn ]
   (let

. #9=(((*print-readably* nil)
   (*print-circle* t)
   (*print-miser-width* 75)
   (*print-length* nil)
   (*print-level* nil)
   (*print-pretty* t))
  (ignore-errors . #8#)))
   [... excl::eval-as-progn ]
   (let ((*package* (find-package :cl))) . #16=((let . #9#)))
   [... excl::%eval ]
   ((:internal asdf/image:print-backtrace))
   (sys::..runtime-operation #10#)
   (sys::..runtime-operation #11# . #1#)
   (funcall

#15=#
. #32=#)
   [... excl::eval-as-progn ]
   (let

. #12=(((*package* (find-package package))
(*read-default-float-format* 'double-float)
(*print-readably* nil)
(*read-eval* nil))
   (funcall asdf/stream::thunk)))
   [... excl::eval-as-progn ]
   (let nil . #13=((let . #12#)))
   [... excl::eval-as-progn ]
   (let

. #14=(((*print-case*
 (excl:if*
  excl::*forced-readtable-case-raw*
  #87=then :downcase
  #89=else :upcase))
(*readtable* excl::std-lisp-readtable))
   (locally . #13#)))
   [... excl::eval-as-progn ]
   (progv

excl::with-standard-io-syntax-vars
excl::with-standard-io-syntax-vals
(let . #14#))
   [... excl::eval-as-progn ]
   (block

asdf/stream:call-with-safe-io-syntax
(with-standard-io-syntax . #13#))
   [... excl::%eval ]
   (asdf/stream:call-with-safe-io-syntax #15#)
   (sys::..runtime-operation #10# #15#)
   [... excl::eval-as-progn ]
   (block

asdf/image:print-backtrace
(asdf/stream:with-safe-io-syntax (:package :cl) . #16#))
   [... excl::%eval ]
   (asdf/image:print-backtrace :stream #4# :count 69)
   (sys::..runtime-operation #10# :stream #4# :count 69)
   (sys::..runtime-operation #5# . #1#)
   [... excl::%eval ]
   (excl::eval-as-progn

#17=((asdf/image:print-backtrace :stream stream :count count)
 (when
  condition
  (asdf/stream:safe-format!
   stream
   "~&Above backtrace due to this condition:~%~A~&"
   condition
   (block asdf/image:print-condition-backtrace . #17#)
   [... excl::%eval ]
   (asdf/image:print-condition-backtrace

#18=#
:count
69
:stream
#4#)
   (sys::..runtime-operation #10# #18# :count 69 :stream #4#)
   (sys::..runtime-operation #5# . #1#)
   [... excl::eval-as-progn ]
   (block

asdf-test:acall
(apply
 (apply
  'asdf-test:asym
  (if
   (consp asdf-test::name)
   asdf-test::name
   (list asdf-test::name)))
 asdf-test::args))
   [... excl::%eval ]
   (asdf-test:acall

:print-condition-backtrace
#18#
:count
69
:stream
#4#)
   (sys::..runtime-operation

#10#
:print-condition-backtrace
#18#
:count
69
:stream
#4#)
   (sys::..runtime-operation #5# . #1#)
   [... excl::eval-as-progn ]
   (let*

. #23=(((#20=#:g822994 . #19#) (excl::*han

Re: [asdf-devel] wert?

2013-03-03 Thread Robert Goldman 
On 3/2/13 Mar 2 -2:58 PM, Faré wrote:
> On Sat, Mar 2, 2013 at 3:30 PM, Robert Goldman  wrote:
>> On 3/2/13 Mar 2 -2:16 PM, Faré wrote:
>>> Hans Hübner suggests that asdf-driver is too clumsy a name, and
>>> suggested we rename it to something in the line of asdf and poiu.
>>> What do you think of wert - wispy environment run-time?
>>> The existing aliases asdf-driver, asdf/driver, asdf-utils would remain
>>> for a while.
>>
>> "wart"?  Wispy ASDF-related Run-Time
>>
>> ;-)
>>
> The meaning is good, but I don't know anyone with a QWARTY keyboard.

So should it be JKL, pronounced Jekyll?

cheers,
r


___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] An upgrade path for checking deferred-warnings

2013-03-03 Thread Faré 
On Sun, Mar 3, 2013 at 2:17 AM, Attila Lendvai  wrote:
>> it is time that I declare this simultaneous change
>> towards checking deferred
>> warnings as a failure.
>
>
> i haven't experimented much with this infrastructure, so take it with
> a piece of salt... but maybe there's a middle ground, where the new
> warnings get printed but the load/compile is not forced to fail? or
> that's the case already?
>
Well, the checking obeys *compile-file-warnings-behaviour*
and *compile-file-failure-behaviour*, so it will only cause the build to fail
when there is a full warning, on SBCL and MKCL.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
In a five year period we can get one superb programming language.
Only we can't control when the five year period will begin. — Alan Perlis

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Zach Beane 
Dave Cooper  writes:

> This is with no (in-package ...)  form at the beginning.
>
> In any case, it looks like as long as the .asd files are used as intended,
> then no package prefix is needed on the (defsystem ...), and no (in-package
> ...) is needed at the top (when using any ASDF version).
>
> I think the confusion started at a time when we were, for some reason,
> manually loading .asd files ourselves by calling (load ...),  ...

Not for me - I had problems with indentation when using plain (defsystem
...) and no problems with (asdf:defsystem ...), so I always used the
latter.

Zach

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Faré 
> I think the confusion started at a time when we were, for some reason,
> manually loading .asd files ourselves by calling (load ...),  which
> according to my understanding is not and has never been an intended use of
> .asd files -- they are strictly to be considered as data files for use with
> supported ASDF (and Quicklisp) operators which expect to find .asd files.
> Although normal CL expressions are also allowed inside .asd files, the .asd
> files are never intended to be loaded with (load ...) by the user.
>
Yes. I recently modified SLIME to do the right thing
when you C-c C-k a .asd file, i.e. (asdf:load-asd pathname)

Note that load-asd is an ASDF3-ism.
Later ASDF2 versions only have a slightly less practical load-sysdef,
and ASDF1 doesn't expose any separate abstraction for that.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Our system is defined to prevent majority politicians from overtly oppressing
minorities. However, our system is also overtly defined to let majorities
elect majority politicians and not let minorities wield electoral power.
Kinda funny... one part of our constitution tries to fix a problem which
the other half of the constitution tries to create!
— Lee Salzman , about the US political system.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Dave Cooper 
I'm not seeing any difference in SLIME's indentation between:


(defsystem #:gdl-ent
  :description "Auto-generated asdf defsys from Genworks GDL cl-lite."
  :author "Genworks and Dave Cooper unless otherwise indicated"
  :serial  t
  :version  "2013030200"
  :depends-on (:gdl-build)
  :components
  ((:file "source/package") (:file "source/assembly")
   (:file "source/controller") (:file "source/agent")))


and:

(asdf:defsystem #:gdl-ent
  :description "Auto-generated asdf defsys from Genworks GDL cl-lite."
  :author "Genworks and Dave Cooper unless otherwise indicated"
  :serial  t
  :version  "2013030200"
  :depends-on (:gdl-build)
  :components
  ((:file "source/package") (:file "source/assembly")
   (:file "source/controller") (:file "source/agent")))


This is with no (in-package ...)  form at the beginning.

In any case, it looks like as long as the .asd files are used as intended,
then no package prefix is needed on the (defsystem ...), and no (in-package
...) is needed at the top (when using any ASDF version).

I think the confusion started at a time when we were, for some reason,
manually loading .asd files ourselves by calling (load ...),  which
according to my understanding is not and has never been an intended use of
.asd files -- they are strictly to be considered as data files for use with
supported ASDF (and Quicklisp) operators which expect to find .asd files.
Although normal CL expressions are also allowed inside .asd files, the .asd
files are never intended to be loaded with (load ...) by the user.




On Sun, Mar 3, 2013 at 11:20 AM, Faré  wrote:

> Or you could fix SLIME's package guessing heuristics.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
> http://fare.tunes.org
> Laziness is mother of Intelligence. Father unknown. [Rumor has it it's
> Greed.]
>
>
> On Sun, Mar 3, 2013 at 10:46 AM, Zach Beane  wrote:
> > Faré  writes:
> >
> >> You do NOT need the prefix, unless you've explicitly changed package
> >> to one that doesn't :use :asdf.
> >
> > Or unless you want SLIME auto-indentation to work.
> >
> > Zach
>



-- 
My Best,

Dave Cooper, Genworks Support
david.coo...@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Faré 
Or you could fix SLIME's package guessing heuristics.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.]


On Sun, Mar 3, 2013 at 10:46 AM, Zach Beane  wrote:
> Faré  writes:
>
>> You do NOT need the prefix, unless you've explicitly changed package
>> to one that doesn't :use :asdf.
>
> Or unless you want SLIME auto-indentation to work.
>
> Zach

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Zach Beane 
Faré  writes:

> You do NOT need the prefix, unless you've explicitly changed package
> to one that doesn't :use :asdf.

Or unless you want SLIME auto-indentation to work.

Zach

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Faré 
> I don't want it to omit the prefix. I want:
>
>(asdf:defsystem  ...)
>
(format t "(asdf:defsystem ...)" ...)

> Does "usual hygiene rules" mean that I do or do not need any prefix on the
> defsystem in
>
>   (defsystem ... )
>
You do NOT need the prefix, unless you've explicitly changed package
to one that doesn't :use :asdf.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Individualism is thus an attitude of humility before this social process and
of tolerance to other opinions, and is the exact opposite of that intellectual
hubris which is at the root of the demand for comprehensive direction of the
social process.  — Friedrich August Hayek, The Road to Serfdom

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Dave Cooper 
On Sun, Mar 3, 2013 at 8:32 AM, Faré  wrote:

> >>: Dave Cooper
> >> I have a little utility which emits the .asd files for me, with a form
> like:
> >>
> >>   `(asdf:defsystem ,(something-to-make-my-system-name) :description
> "blah"
> >> … )
> >>
> If you print that form while *package* is bound to something that uses
> ASDF,
> (such as ASDF-USER, on 2.31), then it will omit the prefix.
>
>

I don't want it to omit the prefix. I want:

   (asdf:defsystem  ...)



> >> Or should I put some (in-package ...) statement at the top of the .asd
> >> file, and use plain defsystem with no package prefix?
> >
> >: stassats
> > You don't need to have prefixes already, when .asd is loaded ASDF
> > creates a temporary package, which uses ASDF package.
> >
> In ASDF1 and ASDF2, indeed, .asd files are read from
> a temporary package ASDF~D that uses ASDF.
> In ASDF3, we're using a permanent package ASDF-USER instead,
> and usual hygiene rules apply.
>
>

Does "usual hygiene rules" mean that I do or do not need any prefix on the
defsystem in

  (defsystem ... )

?




> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
> http://fare.tunes.org
> Any time you're asking the user to make a choice they don't care about,
> you have failed the user — Jeff Atwood
>



-- 
My Best,

Dave Cooper, Genworks Support
david.coo...@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Faré 
>> In ASDF1 and ASDF2, indeed, .asd files are read from
>> a temporary package ASDF~D that uses ASDF.
>> In ASDF3, we're using a permanent package ASDF-USER instead,
>> and usual hygiene rules apply.
> So, if you define your own operation classes, you need to create a new
> package?
>
You already needed to, to be able to name, modify or redefine them afterwards.

In practice, everyone already did, at least in Quicklisp.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The major advances in civilization are processes that all but wreck the
societies in which they occur.
— A.N. Whitehead

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Stas Boukarev 
Faré  writes:

>>>: Dave Cooper
>>> I have a little utility which emits the .asd files for me, with a form like:
>>>
>>>   `(asdf:defsystem ,(something-to-make-my-system-name) :description "blah"
>>> … )
>>>
> If you print that form while *package* is bound to something that uses ASDF,
> (such as ASDF-USER, on 2.31), then it will omit the prefix.
>
>>> Or should I put some (in-package ...) statement at the top of the .asd
>>> file, and use plain defsystem with no package prefix?
>>
>>: stassats
>> You don't need to have prefixes already, when .asd is loaded ASDF
>> creates a temporary package, which uses ASDF package.
>>
> In ASDF1 and ASDF2, indeed, .asd files are read from
> a temporary package ASDF~D that uses ASDF.
> In ASDF3, we're using a permanent package ASDF-USER instead,
> and usual hygiene rules apply.
So, if you define your own operation classes, you need to create a new
package?

-- 
With best regards, Stas.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Faré 
>>: Dave Cooper
>> I have a little utility which emits the .asd files for me, with a form like:
>>
>>   `(asdf:defsystem ,(something-to-make-my-system-name) :description "blah"
>> … )
>>
If you print that form while *package* is bound to something that uses ASDF,
(such as ASDF-USER, on 2.31), then it will omit the prefix.

>> Or should I put some (in-package ...) statement at the top of the .asd
>> file, and use plain defsystem with no package prefix?
>
>: stassats
> You don't need to have prefixes already, when .asd is loaded ASDF
> creates a temporary package, which uses ASDF package.
>
In ASDF1 and ASDF2, indeed, .asd files are read from
a temporary package ASDF~D that uses ASDF.
In ASDF3, we're using a permanent package ASDF-USER instead,
and usual hygiene rules apply.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Any time you're asking the user to make a choice they don't care about,
you have failed the user — Jeff Atwood

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [asdf-devel] printing the symbol asdf:defsystem for .asd file

2013-03-03 Thread Stas Boukarev 
Dave Cooper  writes:

> So I am using ASDF 2.31 which puts the symbol "defsystem" into
> asdf/defsystem package instead of plain asdf package (Franz already
> includes ASDF 2.31 in their patches for Allegro CL).
>
> I have a little utility which emits the .asd files for me, with a form like:
>
>   `(asdf:defsystem ,(something-to-make-my-system-name) :description "blah"
> … )
>
> and now the asdf:defsystem symbol is coming out as asdf/defsystem:defsystem
> instead,
>
> which makes the .asd file non backwards-compatible with slightly older asdf
> versions,
>
> because (symbol-package 'asdf:defsystem) --> #
>
>
> So the Question is, what is the best way to get asdf:defsystem to print as
> asdf:defsystem,
>
> when its home package is :asdf/defsystem and apparently it is now just
> re-exported from :asdf.
>
>
> Or should this symbol now be officially printed as asdf/defsystem:defsystem
> ?
>
>
> Or should I put some (in-package ...) statement at the top of the .asd
> file, and use plain defsystem with no package prefix?
>
>
> Of course I think for the time being the .asd file should be compatible
> with all ASDF versions from recent history...
You don't need to have prefixes already, when .asd is loaded ASDF
creates a temporary package, which uses ASDF package.

-- 
With best regards, Stas.

___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel