On 2/15/16 Feb 15 -3:06 PM, Stelian Ionescu wrote:
> On Mon, 2016-02-15 at 14:48 -0600, Robert Goldman wrote:
>> Trying again:
>>
>> Can someone please state what it is that Quicklisp needs?
>>
>> IIUC Quicklisp does *something* with .asd files that does not in
Trying again:
Can someone please state what it is that Quicklisp needs?
IIUC Quicklisp does *something* with .asd files that does not involve
the defsystem-depends-on being resolved.
Is this reading? Or loading?
If it's loading, then the DEFSYSTEM-DEPENDS-ON entries are resolved by
REGISTER-SY
On 2/15/16 Feb 15 -2:19 PM, Stelian Ionescu wrote:
> On Mon, 2016-02-15 at 11:13 -0600, Robert Goldman wrote:
>> On 2/15/16 Feb 15 -10:26 AM, Stelian Ionescu wrote:
>>>> On 2/12/16 Feb 12 -3:15 PM, Stelian Ionescu wrote:
>>>>> On Fri, 2016-02-12 at 16:07 -
On 2/15/16 Feb 15 -2:00 PM, Faré wrote:
> On Mon, Feb 15, 2016 at 2:18 PM, Robert Goldman wrote:
>> I was having some trouble with warnings causing build failures in ASDF,
>> despite (correctly?) setting variables.
>>
>> Please see the test-warnings branch on cl.
I was having some trouble with warnings causing build failures in ASDF,
despite (correctly?) setting variables.
Please see the test-warnings branch on cl.net. This contains a small
number of additional tests.
I'll continue to look these over to see why they are failing. I'll move
to release aft
On 2/15/16 Feb 15 -10:26 AM, Stelian Ionescu wrote:
>> On 2/12/16 Feb 12 -3:15 PM, Stelian Ionescu wrote:
>>> On Fri, 2016-02-12 at 16:07 -0500, Faré wrote:
I'm OK with declaring DEFSYSTEM-DEPENDS-ON a failure, and load-system
(or load-systems) the official way to go. But
1- Thi
On 2/12/16 Feb 12 -3:15 PM, Stelian Ionescu wrote:
> On Fri, 2016-02-12 at 16:07 -0500, Faré wrote:
>> I'm OK with declaring DEFSYSTEM-DEPENDS-ON a failure, and load-system
>> (or load-systems) the official way to go. But
>>
>> 1- This of course requires heads up, updating all users before
>> retir
A quick follow-up: Perhaps this should be a lesson that trying to find
a "pure" construct for a fundamentally side-effecting operation is a Bad
Idea.
Fundamentally, extending ASDF is a global change that affects the whole
running image. Pretending it is something else doesn't help anyone.
Now,
On 2/11/16 Feb 11 -8:17 PM, Faré wrote:
> Pinging again for an ASDF 3.1.7 — there are fixes in there that some
> recent CFFI extensions depend on.
>
> I may have a Windows VM and time to use it next week, for testing.
>
> In the meantime, all tests (including upgrade) pass for me on Linux
> amd64
On 2/11/16 Feb 11 -8:12 PM, Faré wrote:
> On Wed, Nov 18, 2015 at 8:59 AM, Robert Goldman wrote:
>> Commonly, one wants to extend ASDF with new operation and component classes.
>>
>> But the support in ASDF for referencing such classes all involves
>> automagically i
On 1/30/16 Jan 30 -6:22 PM, Faré wrote:
> On Sat, Jan 30, 2016 at 6:59 PM, Robert Goldman wrote:
>> The make function description in the documentation is not described
>> well. It seems to imply that there is a default operation for each
>> system that the system develope
The make function description in the documentation is not described
well. It seems to imply that there is a default operation for each
system that the system developer can specify somehow, without saying
how. I see that there's a FIXME suggesting that we need to document the
BUILD-OPERATION optio
On 1/30/16 Jan 30 -12:23 PM, Robert P. Goldman wrote:
> I'll check the current version on Mac, Linux and Windows, as feasible.
This won't be until Monday, I'm afraid -- I need the console in the
office to deal with the Windows VM, and the host machine is running
experiments over the weekend, anyw
On 1/28/16 Jan 28 -10:46 AM, Faré wrote:
> There have been many small fixes since ASDF 3.1.6 in last October, and
> I suppose it's time for a new minor release.
>
> Robert, do you want to handle the release? Are you done with it? What
> do you think?
>
> —♯ƒ • François-René ÐVB Rideau •Reflection
On 1/18/16 Jan 18 -9:28 AM, Attila Lendvai wrote:
>> * asdf:*central-registry*
>>
>> (#P"/home/LE/sbcl/" #P"/home/mordecai/quicklisp/quicklisp/")
>
> i'd just put my code under ~/quicklisp/local-projects/ and forget
> about ASDF configuration until it's again needed for something. you
> can also
On 1/18/16 Jan 18 -5:30 AM, Thomas Lynch wrote:
> New at this, sure could use a pointer. I'm not able to get the code to
> build consistently. It works only after a failure. So I have to do it
> twice to get it to go. Sure would like to know what is wrong here.
I can't swear to it without doi
[... this message also bounced yesterday...]
On 1/14/16 Jan 14 -1:20 PM, Robert Goldman wrote:
> What is the intended behavior when this is bound to :IGNORE?
>
> I believe that if warnings occur, they should be quashed and
> COMPILE-FILE should still return T, although otherwise
[This message bounced yesterday for some reason]
What is the intended behavior when this is bound to :IGNORE?
I believe that if warnings occur, they should be quashed and
COMPILE-FILE should still return T, although otherwise it would not.
I'm finding a case where :IGNORE is not enough to make t
I'm trying to load some code that's generated by CFFI, and has some
warnings in it that I know to be benign.
I'm concerned that the code to handle warnings is not working as
expected, and the tests may not work properly.
I'm attaching a modified copy of test-deferred-warnings.script. I set
the w
As you know, warnings in an ASDF build cause it to fail, because they
cause COMPILE-FILE to return NIL. That's fine, I suppose.
But at least on SBCL, the failure is not recoverable for me.
I get an error with the following retries:
restarts (invokable by number or by possibly-abbreviated name):
I am now very unhappy with my role as maintainer.
Over my repeated expressions of concern, the minimakefile -- which aims
to replace normal shell tools with CL-based scripting facilities -- has
been merged with core ASDF.
Since then, almost all of my ASDF-related time has gone into wrestling
with
I went to cl-launch and did "make" and after that asdf-tools loads, but
with the following warning:
; Fast loading
;
/Users/rpg/.cache/common-lisp/acl-9.0-macosx-x64/Users/rpg/lisp/asdf/tools/release.fasl
Warning: While compiling these undefined functions were referenced:
INFERIOR-SHELL::
au •Reflection&Cybernethics• http://fare.tunes.org
> If the human mind were simple enough to understand,
> we'd be too simple to understand it.
> — Pat Bahn
>
>
> On Sun, Jan 10, 2016 at 11:34 AM, Robert Goldman wrote:
>> I tried to load the asdf tools interac
I tried to load the asdf tools interactively, under SLIME, and they fail
to launch, although everything seems to run from make.
I get this error:
Component "cl-launch/dispatch" not found, required by
#
and, indeed:
~/lisp/asdf/ext/cl-launch $ find . -name '*.asd'
~/lisp/asdf/ext/cl-launch $
I
On 1/9/16 Jan 9 -3:13 AM, Raymond Toy wrote:
>>>>>> "Robert" == Robert Goldman writes:
>
> Robert> On 1/7/16 Jan 7 -10:44 PM, Raymond Toy wrote:
> >>>>>>> "Robert" == Robert Goldman
> >>>>>&g
On 1/8/16 Jan 8 -11:59 AM, 73budden . wrote:
> Quote from the manual:
> "But for code that you are actively developing, debugging, or
> otherwise modifying, you should use load-system, so ASDF will pick on
> your modifications and transitively re-build the modified files and
> everything that depen
On 1/7/16 Jan 7 -10:44 PM, Raymond Toy wrote:
>>>>>> "Robert" == Robert Goldman writes:
>
> Robert> On 1/4/16 Jan 4 -11:48 AM, Raymond Toy wrote:
> Robert> OK, I just pushed 3.1.6.8 with the fix for you.
>
> Hmm. I just did a git pull -
On 1/7/16 Jan 7 -10:34 AM, Faré wrote:
> Good luck convincing 7 active implementations to agree on how to parse that.
> If you know the path is relative and you want portability,
> try uiop:parse-unix-namestring.
> But even then, things get ugly when you reach wildcard characters.
I guess I'm not
On 1/4/16 Jan 4 -11:48 AM, Raymond Toy wrote:
>>>>>> "Robert" == Robert Goldman writes:
>
> Robert> Thanks for the response. I have a test. I'm just making sure it
> works
> Robert> on all the implementations, and then I will push
, I'd prefer to see implementations bundle an official ASDF
release, instead of some random git state
Cheers,
r
On 12/31/15 Dec 31 -3:54 PM, Raymond Toy wrote:
>>>>>> "Robert" == Robert Goldman writes:
>
> Robert> On 12/20/15 Dec 20 -12:
On 1/2/16 Jan 2 -11:31 AM, Kambiz Darabi wrote:
> On 2016-01-02 09:05 CET, Faré wrote:
>
One thing I *like* about submodules, is that they are optional. So if
I already have regular checkouts of libraries (and I do), I can use
them instead of those of make ext.
>>>
>>> IMO it would
On 1/1/16 Jan 1 -6:18 AM, Kambiz Darabi wrote:
> On 2016-01-01 09:59 CET, Kambiz Darabi wrote:
>
>> Happy New Year,
>>
>> On 2015-12-31 16:12 CET, Robert Goldman wrote:
>>
>>> On 12/31/15 Dec 31 -5:46 AM, Kambiz Darabi wrote:
>>>> On 2015-12-
On 12/31/15 Dec 31 -1:41 PM, Robert Goldman wrote:
> I was trying to run the tests on Windows, and this triggers make asdf.pdf.
>
> My windows box does not have texi2pdf.
>
> It seems inappropriate that in order to test ASDF you have to build the
> manual.
>
> Note
I was trying to run the tests on Windows, and this triggers make asdf.pdf.
My windows box does not have texi2pdf.
It seems inappropriate that in order to test ASDF you have to build the
manual.
Note that this seems to have changed from before minimakefile -- I used
to be able to run the tests on
On 12/31/15 Dec 31 -5:46 AM, Kambiz Darabi wrote:
> On 2015-12-29 01:58 CET, Robert Goldman wrote:
>
>> I just read the subtree tutorial, and I'm not convinced that this is any
>> simpler (except that it avoids the problem of you mistakenly not ending
>> up with you
On 12/28/15 Dec 28 -11:57 AM, Attila Lendvai wrote:
>> This is the reason why I prefer 'git subtree' to 'git submodule': with
>
> oh, git... why didn't i expect to have more than one way to implement
> the same thing? as opposed to e.g. having a flag that switches between
> the two modes of the sa
On 12/20/15 Dec 20 -12:14 PM, Raymond Toy wrote:
>>>>>> "Robert" == Robert Goldman writes:
>
> Robert> On 12/19/15 Dec 19 -2:32 PM, Raymond Toy wrote:
> >>
> >> Not sure how this ever worked with cmucl, but user-homedir-pathnam
On 12/19/15 Dec 19 -2:32 PM, Raymond Toy wrote:
>
> Not sure how this ever worked with cmucl, but user-homedir-pathname on
> cmucl returns #p"home:", where "home:" is a search-list. In some
> cases, it looks like asdf is trying to create the cache directory and
> end up with a path like
>
> P"hom
I'm having two issues with the new testing scripts:
1. The testing code is bleeding quicklisp into context:
make test
./make.sh l='' L='' u='' U='' v='' s='' t='' test
> Error: System "cl-scripting" not found
> While executing: (:INTERNAL QUICKLISP-CLIENT::RECURSE
QUICKLISP-CLIENT::COMPUTE-LOAD
What about adding a better FILE-LENGTH function to UIOP?
I was looking at Peter Seibel's discussion of FILE-LENGTH in PCL. PiTA,
and certainly unsuitable for use if one wants to write scripts in CL.
What about making UIOP:FILE-LENGTH be generic and take either strings
(filenames), pathnames, or
OK, let me see if I can summarize before doing anything irrevocable to
the git repo.
We will continue to have master, and will now also have a long-lived
"stable-3.1" branch.
On master, we can start by bumping the ASDF version number to 3.2.0.1,
and we will continue to versioning until we get to
t involve a nasty merge or rebase?
I can do some research, but I was hoping someone knew the answer
>
> -Original Message-
> From: asdf-devel [mailto:asdf-devel-boun...@common-lisp.net] On Behalf Of
> Robert Goldman
> Sent: 18 November, 2015 21:17
> To: asdf-devel@c
On 11/18/15 Nov 18 -8:35 PM, Faré wrote:
> Yeah, there's an awkward merge or rebase happening when "stable" jumps
> from 3.1 to 3.2, whereas no such jump happens if old branches have
> numbered names and are forked off a master that keeps going forward.
>
Surely git must have a solution to this p
né ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> Evolution competitively selects stable cooperative patterns.
>
>
> On Wed, Nov 18, 2015 at 2:37 AM, Kambiz Darabi wrote:
>> On 2015-11-17 18:11 CET, Robert Goldman wrote:
>>
>>> [...]
>>&g
On 11/18/15 Nov 18 -10:47 AM, Raymond Toy wrote:
>> "Fare" == Far writes:
>
> >> Once in a long while I've wanted to get a list of all of the source
> >> files, or the fasl files, a dependency graph (tree?). Mostly just to
> >> see what the system thinks it has and what I think
Commonly, one wants to extend ASDF with new operation and component classes.
But the support in ASDF for referencing such classes all involves
automagically interpreting keyword symbols (and some unqualified
symbols?) in the ASDF package.
If I understand this correctly, this leaves the ASDF exten
On 11/17/15 Nov 17 -4:00 PM, Stelian Ionescu wrote:
> On Tue, 2015-11-17 at 11:11 -0600, Robert Goldman wrote:
>> We have had a number of ASDF 3 releases that have mostly been aimed at
>> bug-fixing (although some new features have crept in).
>>
>> I'd like to dec
On 11/17/15 Nov 17 -3:10 PM, Faré wrote:
> On Tue, Nov 17, 2015 at 3:37 PM, Robert Goldman wrote:
>> This seems like it might be a good FAQ, and we had some correspondence
>> about a related query earlier.
>>
>> (sort (mapcar #'asdf:component-name
>>
This seems like it might be a good FAQ, and we had some correspondence
about a related query earlier.
(sort (mapcar #'asdf:component-name
(mapcar #'cdr
(remove-if-not #'(lambda (x) (and (typep
(cdr x) 'asdf/system:system) (typep (car x) 'asdf:l
We have had a number of ASDF 3 releases that have mostly been aimed at
bug-fixing (although some new features have crept in).
I'd like to declare ASDF 3 feature complete and done, but I don't want
to close the door to future bug fix releases as needed, nor do I want to
shove incomplete new feature
On 11/11/15 Nov 11 -3:03 PM, Andreas Davour wrote:
> On Mon, 9 Nov 2015, Robert Goldman wrote:
>
>> BTW, I have whacked the content of that cliki page. We don't have the
>> resources to maintain the cliki pages, the cl.net homepage, and the
>> manual.
>
> I
BTW, I have whacked the content of that cliki page. We don't have the
resources to maintain the cliki pages, the cl.net homepage, and the manual.
On 10/16/15 Oct 16 -2:03 PM, Faré wrote:
> I propose we document that the license field should if possible
> contain an identifier from
> http://spdx.org/licenses/
> http://esr.ibiblio.org/?p=6867
Do you expect this field to be a string, or should it be encoded in some
special way (e.g., a key
We would like to announce the release of ASDF 3.1.6, the latest bug fix
release for ASDF. As usual many thanks are due to Faré for many bug
fixes, clean ups, explanations, etc. Thanks are also owed to Dave
Cooper, for testing on the Windows platform, enabling the maintainers to
test on Windows, a
Hope to have this out this evening. Here's the announcement. Comments
and corrections welcome (for a few hours!).
We would like to announce the release of ASDF 3.1.6, the latest bug fix release
for ASDF. As usual many thanks are due to Faré for many bug fixes, clean ups,
explanations, etc. T
On 10/16/15 Oct 16 -2:03 PM, Faré wrote:
> I propose we document that the license field should if possible
> contain an identifier from
> http://spdx.org/licenses/
> http://esr.ibiblio.org/?p=6867
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> You think yo
I have just completed the upgrade tests on the following lisps:
ccl sbcl cmucl allegro_64 allegromodern_64 lispworks clisp ecl
ecl_bytecodes mkcl
and they all passed.
So I believe that ASDF 3.1.6 is ready for release.
I hope to get this done tomorrow, but worst case it would slip to Monday.
riginal Message-
> From: asdf-devel [mailto:asdf-devel-boun...@common-lisp.net] On Behalf Of
> Robert Goldman
> Sent: 15 October, 2015 16:30
> To: ASDF-devel
> Subject: 3.1.6 progress report
>
> Tests pass for me on all the implementations I have on Mac OS X (Yosemi
Tests pass for me on all the implementations I have on Mac OS X
(Yosemite), linux, and Windows.
Now running the upgrade tests on linux on CCL, SBCL, CMUCL, Allegro,
lispworks, ECL, ECL bytecodes, and MKCL.
If those pass, I will bless the current head as 3.1.6.
The upgrade tests are very time con
I have all new Allegro 10 versions. I'll be installing these on Linux,
Windows, and Mac, then re-running all the tests.
If the tests pass, I'll try to push out 3.1.6 tomorrow sometime.
Cheers,
r
On 10/15/15 Oct 15 -12:40 AM, Faré wrote:
> On Wed, Oct 14, 2015 at 6:55 PM, Robert Goldman wrote:
>>>>> Apparently, the first release that include PRINT-BACKTRACE is 1.1.5
>>>>> from February 2013.
>>>>>
>
>>> Considering that the
On 10/11/15 Oct 11 -12:14 PM, Faré wrote:
> On Sun, Oct 11, 2015 at 12:57 PM, Robert Goldman wrote:
>> On 10/10/15 Oct 10 -10:26 AM, Faré wrote:
>>> On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov
>>> wrote:
>>>> If you are interested, th
On 10/10/15 Oct 10 -10:26 AM, Faré wrote:
> On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov
> wrote:
>> If you are interested, this version of ASDF fails on SBCL 1.0.58:
>>
>> ; caught ERROR:
>> ; READ error during COMPILE-FILE:
>> ;
>> ; Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG
On 9/30/15 Sep 30 -4:35 PM, Faré wrote:
>> P.S. I don't have time to do a whole lot of debugging of the SBCL +
>> run-program issue right now, although I have been able to replicate it.
>>
> Can you replicate while you
> (trace "UIOP/RUN-PROGRAM" sb-ext:run-program sb-ext:process-input
> sb-ext:pro
I'm not sure what the upshot of this is.
Currently, the tests test images and other bundles by starting up a
subsidiary lisp, and then checking its console output.
Writing a dribble file wrapper around that will be pretty painful.
For now I propose to continue to use build.exe and buildi.exe for
On 9/30/15 Sep 30 -9:51 AM, Daniel Kochmański wrote:
> From version 16.0.0 ECL isn't affected by this bug.
Thank you: I have modified the test to record an expected failure on
earlier versions of ECL.
Best,
r
>
> Robert Goldman writes:
>
>> On 9/30/15 Sep 30 -9:37 AM,
ld, I guess.
Is there a version number where this is fixed? If there is, I might
tweak the tests to mark this failure as expected on older versions of ECL.
Best,
r
>
> Regards,
> Daniel
>
> Robert Goldman writes:
>
>> test-xach-update-bug.script fails on both ECL and
test-xach-update-bug.script fails on both ECL and ECL bytecodes for me
on Linux. This is ECL 13.5.1.
I *believe* that this is to be expected, and there's an ECL fix for this.
Please LMK if that's not true and if I should hold up releasing 3.1.6
for that reason.
Otherwise I plan to release today
LAST CALL FOR A BUG REPORT!!!
I do not know enough to replicate this bug report, so cannot debug it.
I need a bug report on launchpad per the following *THIS MORNING* if
there's going to be a fix before releasing 3.1.6:
I repeat my earlier email:
Will someone please post a launchpad ticket for
Tests all pass on my Windows VM (thanks to Dave Cooper!).
Tests all pass on Mac.
Running tests on Linux.
After that propose to release 3.1.6.
I'd like to get the UIOP fix for SBCL on Windows in place before the
release, but still have no bug report, so am not sure how to replicate
or fix.
Last c
OK, somehow, although all of the ALLEGRO variants specify that we should
be using buildi.exe or build.exe, when we actually get to test-program,
it's using alisp.exe, which seems to cause breakage.
I am looking at the output of ALL-ALLEGRO-VARIANTS.
So what is crushing the allegro executable and
I'm getting what look like spurious failures on tests of "allegro" in
test-program.script.
I *believe* that what's going wrong here is that lisp-invocation is
getting confused about how to find the right ACL runtime.
If you look at run-tests.sh, you will see that "ALLEGRO" is initially
bound usin
When I run test all on Windows, the SBCL tests fail in a spurious way.
I get an error that lisp couldn't rename f:\asdf\build\dir1\foo0.asd to
f:\asdf\build\dir1\foo1.asd.bak
AFAICT this is because CREATE-ASD-FILES in test-configuration.script
uses :if-exists :rename-and-delete when it's creating
Will someone please post a launchpad ticket for this? Specifically a
launchpad ticket that indicates how to replicate the bug and what the
expected and observed behaviors are?
I'll try to test tomorrow, but I don't know what "broken" means in this
context. Of course if it means "crashes," that's
Postscript: Divergence between SBCL results on Mac and on Linux
revealed that I have antique SBCL on Linux. Retested there, and the
BACKTRACE function replacement didn't cause a failure, so I think we are
good with PRINT-BACKTRACE.
Cheers,
r
On Linux, I checked:
ccl sbcl cmucl allegro allegromodern allegro8 allegromodern8 lispworks
clisp ecl ecl_bytecodes mkcl
All passed, except ECL and ECL with bytecodes, both of which failed
test-xach-update-bug.script
But I have only ECL 13.5.1, so this may be wrong.
Also note that I checked onl
On 9/23/15 Sep 23 -6:50 PM, Faré wrote:
> SANO Masatoshi reports that uiop:run-program broke on SBCL/Windows at
> some point between 3.1.3 and 3.1.5.
>
> Can someone with SBCL and Windows help me debug that?
> A trace of functions in uiop/run-program and the functions in sb-ext
> that appear in th
On 9/23/15 Sep 23 -3:55 PM, Robert Dodier wrote:
> Hey everybody,
>
> I've made some more progress with a Maxima extension for ASDF
> (attached). At this point it works pretty much as expected, for the
> simple examples I've tried. I think you should be able to use in
> Maxima like this: load("max
On 9/22/15 Sep 22 -2:18 PM, Faré wrote:
>>> : Faré
>>> I think the code is ready for 3.1.6.
>>>
>>> I see one regression: logical pathnames on CLISP, that don't play well
>>> with the newly used temporary file strategy. I propose we punt on that
>>> test and file a bug against CLISP. Maybe some day
On 9/22/15 Sep 22 -1:37 PM, Faré wrote:
> I think the code is ready for 3.1.6.
>
> I see one regression: logical pathnames on CLISP, that don't play well
> with the newly used temporary file strategy. I propose we punt on that
> test and file a bug against CLISP. Maybe some day CLISP will have new
Kevin,
Does head currently work for you with the new Allegro (and with 9.0) on
all three platforms?
If so, I'm inclined to suggest we bless this as 3.1.6, since I know of
no regressions on other implementations.
Out of a sense of tidiness, I'd be happier if you had an x.y.z release
version in yo
On 9/21/15 Sep 21 -6:15 PM, Robert Dodier wrote:
> Thanks a lot to everybody for the advice. I think I've made some
> progress. I've attached a patch showing the initial changes I've
> made, and with this much I can load a trivial system into Maxima.
>
> I'm working with asdf.lisp 2.26 which is pa
On 9/17/15 Sep 17 -12:57 PM, Robert Dodier wrote:
> Hi, I am exploring the possibility of using ASDF to define systems of
> non-Lisp code, specifically for Maxima (http://maxima.sourceforge.net).
> Maxima is written in Lisp but has its own language. I'd like to
> be able to load programs written in
I have just run the tests of HEAD on Windows with the GM.
HEAD passes all the tests.
Or almost
I get failures on "allegro" and on "sbcl".
I'm pretty sure that these are both bogus, because sbcl wasn't even an
element of ASDF_TEST_LISPS! And I did a "make clean" before running the
tests.
S
On 9/15/15 Sep 15 -4:31 PM, Faré wrote:
>> However, whereas using LISP=ccl as the driver correctly invokes buildi.exe,
>> using LISP=allegro as the driver leads to alisp.exe being called,
>> which is not what I wanted.
>> I haven't investigated why.
>>
> That was because defining LISP=allegro resul
On 9/14/15 Sep 14 -5:36 PM, Kevin Layer wrote:
> Faré wrote:
>
>> @thor[git:master]$ ALLEGRO=/c/acl100/alisp make l=allegro test-lisp
>>> ALLEGRO=/c/acl100/alisp
>> I believe this should be ALLEGRO=c:\acl100\alisp ? (with proper shell
>> escaping).
>> If using cygwin, $(cygpat
I have a lot to catch up on this conversation: I was out all day today
because of the holiday.
I'll catch up with the list tomorrow or Wednesday. Sorry about the delay.
On 9/11/15 Sep 11 -8:57 PM, Faré wrote:
[...snip...]
> Since there's a cache pathname bug on Windows in 3.1.5, I recommend
> shipping with 3.1.5.7 (or 3.1.6, if we manage to ship faster than you
> do).
I would be happy to coordinate with you to release a 3.1.6 that is 3.1.5
with fixes for Allegro
On 9/8/15 Sep 8 -2:03 PM, Faré wrote:
>>> : Faré
>>> On implementations other than ECL (and maybe also MKCL and CLASP),
>>> DLL-OP and LIB-OP will capture the outputs of extensions like CFFI,
>>> and not of the main Lisp implementation.
>>>
>>> Problem is, the extensions need to cooperate, and CFFI
On 9/8/15 Sep 8 -12:36 PM, Faré wrote:
> On Tue, Sep 8, 2015 at 11:53 AM, Robert Goldman wrote:
>> Are these reasonable across different Lisp implementations?
>>
>> E.g., what would it mean to try to invoke a DLL-OP on ACL, Lispworks, or
>> CCL?
>>
>> It
Are these reasonable across different Lisp implementations?
E.g., what would it mean to try to invoke a DLL-OP on ACL, Lispworks, or
CCL?
It seems like we are advertising a lot of functionality that we do not,
in fact, support. I'd like to prune this down in some way, eliminating
operations on i
I pushed documentation strings for some of the bundle operations.
Open for comments about their accuracy, helpfulness, etc.
At some point I would also like to reopen the issue of how to sync up
docstrings and manual. The SBCL manual seems to have a solution to this
problem. I'd be willing to use
On my Mac, when I run the tests on Lispworks, it insists on opening a
new terminal window for every LW job, each of which has something like
this in it:
rpg@rpgoldman: ~ $ /var/tmp/lwtemp_rpgoldman_72030319WbgIm.command ; exit;
These windows *must be closed by hand*, which makes testing lispworks
On 8/31/15 Aug 31 -9:35 AM, Faré wrote:
> On Mon, Aug 31, 2015 at 10:31 AM, Robert Goldman wrote:
>> I just ticketed four new ASDF test failures on Mac with the ECL 16.0.0
>> version that I got from Daniel Kochmanski
>>
>> Looks to me like there may be some unhapp
I just ticketed four new ASDF test failures on Mac with the ECL 16.0.0
version that I got from Daniel Kochmanski
Looks to me like there may be some unhappiness with Apple's compiler,
and there may be some issues with temporary file handling.
https://bugs.launchpad.net/asdf/+bug/1490585
https:
On 8/30/15 Aug 30 -12:54 PM, Faré wrote:
> Dear Robert,
>
> I know you wanted to proceed to making new developments in an ASDF 3.2,
> but I believe the bad default cache computation on Windows makes it a good
> idea
> to release an ASDF 3.1.6 sometime soon. Bonus will be some concurrency fix
> an
On 8/29/15 Aug 29 -2:03 PM, Kevin Layer wrote:
>>> it certainly looks like something is going wrong handling optional
>>> arguments.
>
> Robert,
>
> If you can get a test case, that would wonderful. I appreciate the
> help narrowing down this problem.
>
> Kevin
>
I pushed a topic branch "alle
On 8/29/15 Aug 29 -3:53 AM, Faré wrote:
> I've tried the Allegro 10.0 release candidate, and the script-support
> bizarrely fails to override the configuration when it passes an
> argument initialize-source-registry, that gets lost on its way to
> FLATTEN-SOURCE-REGISTRY, being replaced by NIL:
>
gt; —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> The best place for a striker, that yellow noxious mosquito, is in the
> concentration camp. — Leon Trotsky, Pravda, February 12, 1920.
>
>
> On Fri, Aug 28, 2015 at 9:13 AM, Robert Goldman wro
The test-configuration.script and test-logical-pathname.script are
failing on the latest Allegro 10 preview on Mac OS X on all the Allegro
modern variants, and on the ANSI SMP variants. All tests pass on alisp
non-SMP and alisp8 non-SMP.
Test configuration:
Running test-configuration.script with
501 - 600 of 1354 matches
Mail list logo
