On Mar 29, 2010, at 10:39 AM, Faré wrote:
[…]
So I would ask the ASDF developers to consider extending the
output translation DSL to allow something like
(initialize-output-translations
'(:output-translations :ignore-inherited-configuration
(#p"jar:file:/*
On 29 March 2010 04:33, Mark Evenson wrote:
>> Couldn't you extend the ABCL pathname matching algorithm to allow for
>> wildcards and all in the device component?
>
> Wildcards do work in DEVICE but you can't currently use unused results of
> the wildcard matches on the DEVICE components to "carry
On 3/29/10 8:25 AM, Faré wrote:
> Dear Mark,
>
>> Fare's suggestion that I use an output translation based on the jar
>> pathname doesn't quite work, because in our current implementation,
>> the pathname of the jar is stored in DEVICE, separate from the rest
>> of the jar pathname. I extended PATH
Dear Mark,
> Fare's suggestion that I use an output translation based on the jar
> pathname doesn't quite work, because in our current implementation,
> the pathname of the jar is stored in DEVICE, separate from the rest
> of the jar pathname. I extended PATHNAME-MATCH-P to match jars
> correctly,
Hi Alan,
On Wed, Mar 24, 2010 at 3:36 PM, Alan Ruttenberg
wrote:
> Is ASDF2 what gets loaded when you require 'asdf in trunk, or some
> other action required to use it?
> -Alan
I think we will need to update our ASDF now that the new ASDF2 is
available. What you get when you use REQUIRE is a ver
[Removing Erik and Alan from the CC who should see it on the armedbear list if
they're interested/
On Mar 25, 2010, at 2:00 PM, Robert Goldman wrote:
> On 3/25/10 Mar 25 -1:49 AM, Mark Evenson wrote:
>> On 3/25/10 7:34 AM, Faré wrote:
>> […]
>>
>
>>
It would be perhaps cleaner to hav
On 3/25/10 Mar 25 -1:49 AM, Mark Evenson wrote:
> On 3/25/10 7:34 AM, Faré wrote:
> […]
>
>
>>> It would be perhaps cleaner to have the binary locations machinery of ASDF2
>>> react to not being able to write to the Pathname derived from the location
>>> of the ".asd" file in an extensible m
On 3/25/10 7:34 AM, Faré wrote:
[…]
>> [1]:
>> http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/asdf-abcl.lisp
>>
> Do you want me to merge that into upstream ASDF with #+abcl conditions?
Not yet: it doesn't make sense until I figure out what works with ASDF2
(that
Dear Mark,
> Yes, ABCL ADSF1 can load from jar files and no, nothing has been removed
> from ASDF2 as it's more of a case of what has been added, namely that it now
> OPENs the .asd file instead of LOADing it, and ASDF-BINARY-LOCATIONS are
> baked-in.
>
OK.
> That a Pathname for jar locations in
On 3/24/10 7:08 PM, Faré wrote:
[…]
Can ASDF1 do this loading from jar files? I certainly didn't remove
anything from it. If you have a local patch to ASDF1 to do it, I'll be
please to include it in either ASDF2 or a contrib to it.
Yes, ABCL ADSF1 can load from jar files and no, nothing has be
On 24 March 2010 12:59, Mark Evenson wrote:
> Right: we still include ASDF 1.3 with ABCL.
>
> I'm looking at upgrading ABCL trunk to the new (aka ASDF2) version, but
> right now ASDF2 cannot load systems from jar files so I haven't put it on
> trunk just yet.
>
> One can load ASDF2 from ASDF quit
On 3/24/10 4:54 PM, Erik Huelsmann wrote:
> Hi Alan,
>
> On Wed, Mar 24, 2010 at 3:36 PM, Alan Ruttenberg
> wrote:
>> Is ASDF2 what gets loaded when you require 'asdf in trunk, or some
>> other action required to use it?
>> -Alan
>
> I think we will need to update our ASDF now that the new ASDF2
Is ASDF2 what gets loaded when you require 'asdf in trunk, or some
other action required to use it?
-Alan
On Wed, Mar 24, 2010 at 7:21 AM, Mark Evenson wrote:
> On 3/24/10 2:52 PM, Faré wrote:
>>
>> Sorry, I haven't tried recompiling the latest ABCL from source and
>> don't know if any pathname i
On 3/24/10 2:52 PM, Faré wrote:
> Sorry, I haven't tried recompiling the latest ABCL from source and
> don't know if any pathname issue remains.
>
> Have you tried downloading the latest ASDF and running its test suite?
> Do you pass all tests? I ought to include more tests about the
> output-trans
Sorry, I haven't tried recompiling the latest ABCL from source and
don't know if any pathname issue remains.
Have you tried downloading the latest ASDF and running its test suite?
Do you pass all tests? I ought to include more tests about the
output-translations configuration and the source-regist
On 3/23/10 4:53 PM, Faré wrote:
[…]
> I hope ABCL has fixed its merge-pathnames woes.
[…]
As I reported last week, ASDF2 works with ABCL from trunk and the
upcoming abcl-0.19 release, for which I have fixed a couple issues with
our pathname support.
Are there current failures with ABCL's MERG
Alan,
ASDF-Binary-Locations has been obsoleted and replaced by the more
easily configurable ASDF-Output-Translations, which is now built into
ASDF itself.
ASDF 1.660 also includes some compatibility mode with ABL, if for some
reason you love the old ABL way.
I hope ABCL has fixed its merge-pathn
How do you feel about integrating asdf-binary-locations into ABCL as
well. I would make one change to what's there now, which is to add
:java-1.4, :java-1.5, :java-1.6 to the list of architectures it has.
-Alan
On Tue, Mar 16, 2010 at 11:59 AM, Mark Evenson wrote:
> Attached are patches in 'abcl
18 matches
Mail list logo
