3.1.6 progress report

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.

Re: SBCL support [Was: Re: Towards release 3.1.6]

On 10/11/15 Oct 11 -12:14 PM, Faré wrote: > On Sun, Oct 11, 2015 at 12:57 PM, Robert Goldman <rpgold...@sift.net> wrote: >> On 10/10/15 Oct 10 -10:26 AM, Faré wrote: >>> On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov <avodono...@yandex.ru> >>> wrote: &

SBCL support [Was: Re: Towards release 3.1.6]

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"

Re: Spurious ALLEGRO failure

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 >

Re: uiop:run-program broken on SBCL/Windows.

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

One last test failure: ECL on Linux

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

Re: One last test failure: ECL on Linux

old, 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 ECL byteco

Re: One last test failure: ECL on Linux

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, Danie

Re: Spurious ALLEGRO failure

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

test status, impending release, and UIOP/SBCL/Windows bug

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

Spurious ALLEGRO failure

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

Re: uiop:run-program broken on SBCL/Windows.

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,"

Re: uiop:run-program broken on SBCL/Windows.

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

3.1.6 release candidate test results -- and one patch

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

Re: maintaining non-Lisp systems with ASDF

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:

Re: 3.1.6

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

Release 3.1.6

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

Re: maintaining non-Lisp systems with ASDF

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

Re: maintaining non-Lisp systems with ASDF

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

Re: ASDF 3.1.5 test suite issues on ACL (8.2 and 10.0 GM)

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,

Re: ASDF 3.1.5 test suite issues on ACL (8.2 and 10.0 GM)

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

Testing Allegro 10 GM on Windows

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.

Re: ASDF 3.1.5 test suite issues on ACL (8.2 and 10.0 GM)

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.

Re: ASDF 3.1.5 test suite issues on ACL (8.2 and 10.0 GM)

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

Re: Bundle operations

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

Bundle operations

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

Pushed some docstrings

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

Re: Bundle operations

On 9/8/15 Sep 8 -12:36 PM, Faré wrote: > On Tue, Sep 8, 2015 at 11:53 AM, Robert Goldman <rpgold...@sift.net> 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 >

lisp-invocation with lispworks very unpleasant

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

Re: Tests failing on Allegro 10 preview, Mac OS X

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 rpgold...@sift.net wrote: The test-configuration.script and test-logical-pathname.script are failing

Bug in Allegro 10 preview -- Was Re: Tests failing on Allegro 10 preview, Mac OS X

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:

Re: Bug in Allegro 10 preview -- Was Re: Tests failing on Allegro 10 preview, Mac OS X

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 allegro-10-bug.

Tests failing on Allegro 10 preview, Mac OS X

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

Question from the old school: source config DSL

I have always used ASDF:*CENTRAL-REGISTRY*, with some local code that grovels over source trees. I'd love to stop maintaining the tree groveler, and move to the DSL, but I have never understood how you debug the DSL when ASDF fails to find your system. With *CENTRAL-REGISTRY* you pretty much

Re: Question from the old school: source config DSL

On 8/24/15 Aug 24 -2:14 PM, Faré wrote: On Mon, Aug 24, 2015 at 2:48 PM, Robert Goldman rpgold...@sift.net wrote: I have always used ASDF:*CENTRAL-REGISTRY*, with some local code that grovels over source trees. I'd love to stop maintaining the tree groveler, and move to the DSL, but I have

ASDF 3.1.5 is now released!

numbering API * Bug fixes: handle various configuration corner cases better (thanks to Sergey Katrevich and Rupert Warwick). * Feature: Robert Goldman fixed and documented WEAKLY-DEPENDS-ON. -- Francois-Rene Rideau f...@tunes.org Fri, 13 Jan 2012 14:40:12 -0500 cl-asdf (2:2.019-1) unstable

Re: Draft release email

On 7/18/15 Jul 18 -5:39 PM, Faré wrote: Looks mostly good. Dave Cooper can also be credited for register-immutable-systems. Thanks for the suggestion. I have added to the announcement a paragraph about immutable systems: FIXME: Attach the changelog We would like to announce the

Draft release email

If you have any feedback about this before I send it out, please respond to the list or directly to me. Thanks! FIXME: Attach the changelog We would like to announce the release of ASDF 3.1.5, much later than expected, but also much more solid. As usual many thanks are due to Faré for

Re: restarts vs debugger command

On 7/10/15 Jul 10 -5:46 AM, 73budden . wrote: I see you mean situation where we have systems (defsystem Bad2) (defsystem bAd2) (defsystem :|baD2|) In this case we can navigate to :|baD2| by name :bad2, and unable to navigate to first two systems. Where should I err? According to

Re: Almost there

On 7/15/15 Jul 15 -2:23 PM, Attila Lendvai wrote: Well, if we change the API to add a boolean slot to SYSTEM, we could this may be naive, but what i meant is a very simple change: introduce an exported SYSTEM-MUTABLE-P, together with a SETF version, that messes around with the current

Re: Almost there

On 7/10/15 Jul 10 -8:34 AM, Faré wrote: We did add better immutable-system support thanks to Dave Cooper, is this meant to be the final public API (an exported global variable that holds a hashtable)? The final API is (register-immutable-system foo) and, I suppose,

Re: Almost there

On 7/14/15 Jul 14 -3:58 PM, Dave Cooper wrote: if it's still feasible i suggest to replace REGISTER-IMMUTABLE-SYSTEM with (SETF SYSTEM-MUTABLE-P) and stop exporting *IMMUTABLE-SYSTEMS*. I think it's too late to make changes for 3.1.5. Indeed, it's probably a

Re: Almost there

On 7/14/15 Jul 14 -6:04 PM, Attila Lendvai wrote: I'm inclined to remove the export of *IMMUTABLE-SYSTEMS*. It hasn't been used in a released version of ASDF AFAIK, so it seems benign to remove it. isn't that also the case for REGISTER-IMMUTABLE-SYSTEM? if that export sticks in the

Re: Almost there

On 7/14/15 Jul 14 -6:04 PM, Attila Lendvai wrote: I'm inclined to remove the export of *IMMUTABLE-SYSTEMS*. It hasn't been used in a released version of ASDF AFAIK, so it seems benign to remove it. isn't that also the case for REGISTER-IMMUTABLE-SYSTEM? if that export sticks in the

Re: Almost there

On 7/12/15 Jul 12 -1:17 PM, Faré wrote: On Sun, Jul 12, 2015 at 1:24 PM, Robert Goldman rpgold...@sift.net wrote: This sounds like a good point. Should we do this in the cover letter, the changelog, manual, or some combination? My guess is that relatively few people actually upgrade

Re: Almost there

On 7/10/15 Jul 10 -3:24 AM, Mark Evenson wrote: On Jul 10, 2015, at 05:05, Faré fah...@gmail.com wrote: […] Nothing should have changed in the semantics of ASDF itself since the last run of cl-test-grid, so I don't expect any discrepancy. We did add better immutable-system support thanks

Re: Testing running subsidiary lisps with multiple Allegros

:27 AM, Robert Goldman rpgold...@sift.net mailto:rpgold...@sift.net wrote: How is this to be managed? In the test suite, there are environment variables that signal which of the many Allegro flavors one is testing. But somehow this information needs to get pushed through

Testing running subsidiary lisps with multiple Allegros

How is this to be managed? In the test suite, there are environment variables that signal which of the many Allegro flavors one is testing. But somehow this information needs to get pushed through the tests into the subsidiary lisp-invocations. How is this managed? Thanks, r

Tests ran overnight

...not on Windows, I'm afraid: my automation isn't up to that yet. But all tests passed on Mac OS X. On linux, though, I got the following: Unexpected test failures on these implementations: build/results/allegro8-test.text build/results/allegromodern8-test.text

Re: :require dependency

On 6/25/15 Jun 25 -4:20 PM, Didier Verna wrote: Hello, can somebody explain to me what is the :require dependency specification, and how it compares to just a simple-component-name ? Thanks. According to the manual REQUIRE-SYSTEM is ... a version of @code{load-system} that skips

Re: Problem with ACL on windows proposed fix

On 6/27/15 Jun 27 -11:40 PM, Faré wrote: On Fri, Jun 26, 2015 at 4:49 PM, Robert Goldman rpgold...@sift.net wrote: Sorry -- I've been traveling, so sat on this bug report for a while. Here's a test failure from Windows ACL. Looks like ACL is somehow not running the windows CWD program helper

Re: Problem with ACL on windows proposed fix

On 6/28/15 Jun 28 -6:10 AM, Faré wrote: On Sun, Jun 28, 2015 at 12:58 AM, Robert P. Goldman rpgold...@sift.net wrote: Ok. Maybe we'll have to issue a 3.1.5 and then follow it almost immediately with a 3.1.6 that will have better Windows support. THEN we can finally move forward again. It

Problem with ACL on windows proposed fix

Sorry -- I've been traveling, so sat on this bug report for a while. Here's a test failure from Windows ACL. Looks like ACL is somehow not running the windows CWD program helper (which should invoke CMD.EXE), but instead is just taking the command and treating it as its own output. the

Re: Test failures on Windows

desirable than this behavior. Is there no way to redirect the output of ACL on Windows? Must it always go into its own console window (or be lost altogether if it's run without a console window)? That seems deeply undesirable Best, r On Tuesday, June 23, 2015, Robert Goldman rpgold

Windows and Lisp scripting [Re: Test failures on Windows]

On 6/23/15 Jun 23 -2:15 PM, Robert Goldman wrote: On 6/23/15 Jun 23 -1:46 PM, Dave Cooper wrote: Is there no way to redirect the output of ACL on Windows? Must it always go into its own console window (or be lost altogether if it's run without a console window)? That seems deeply

Test failures on Windows

I'm having some real oddities testing on Windows. Attached is a roster of the implementations for which I see test failures -- the Allegro variants and clisp. Two oddities: 1. I do not get verbose output showing what happens when the tests fail. Critical information is missing from the

Re: The dictatorship of versioning

I would welcome a restructuring of the version comparison protocol along the lines that Didier suggests: make sure all the components of the protocol are properly handled by generic functions, and allow system developers and maintainers to manage their own version comparison logic should they so

Re: The dictatorship of versioning

On 6/16/15 Jun 16 -10:33 AM, Didier Verna wrote: Robert Goldman rpgold...@sift.net wrote: Just to clarify: I am NOT saying Pascal is wrong to want these things or to do them himself. And I AM saying that ASDF should make it possible for him to do so. ASDF could call FORMATTED-VERSION

Re: The dictatorship of versioning

On 6/16/15 Jun 16 -10:24 AM, Didier Verna wrote: Robert Goldman rpgold...@sift.net wrote: So what happens when the programmer updates the human readable version and not the canonical version, or vice versa? Wouldn't it be better to functionally derive one of these two forms from the other

Re: The dictatorship of versioning

On 6/16/15 Jun 16 -9:31 AM, Didier Verna wrote: Robert Goldman rpgold...@sift.net wrote: Now: a request for management purposes: Didier, would you be so kind as to describe the proposal (I think cut and paste out of your earlier emails would do admirably) in a ticket on launchpad.net

Re: Fwd: why is usocket.asd without an in-package or package qualifiers?

On 6/16/15 Jun 16 -2:08 PM, Faré wrote: Robert, should we export load-asd from asdf? Yes, that sounds right. I will do so now, unless you want to —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org If Java had true garbage collection, most programs would

Re: Introspecting source registry

On 6/7/15 Jun 7 -5:09 AM, Mark Evenson wrote: With asdf-3.1.4, how do I introspect the current state of source registry configuration? I need to debug a remote user's ASDF configuration on a machine which I don't have access to, so I would like to have ASDF output the current source registry

Re: Fwd: Introspecting source registry

On 6/7/15 Jun 7 -10:44 AM, Faré wrote: 1- Look for asdf::*source-registry-parameter* which will tell you what ultimate overrides were used, if any. 2- Follow the trail of items in asdf::*default-source-registries*. So first, an environment variable CL_SOURCE_REGISTRY, then a configuration

[Asdf-devel] ASDF 3.1.4 released today

This is a maintenance and bugfix release. There should be no incompatibilities, and many small fixes. The one new feature is an optional speedup to system search. Users who have large directory trees to search, and stable sets of systems, can build a system search cache that will substantially

Re: [Asdf-devel] ASDF test failure on MKCL linux

After disabling test-try-refinding, I get two more test failures on MKCL: test-program: ; Registering #SYSTEM hello-world-example TEST ABORTED: Error while trying to load definition for system hello-world-example from pathname /home/rpg/common-lisp/asd\ f/test/hello-world-example.asd: Unknown

Re: [Asdf-devel] Minor minimakefile nit

Robert P. Goldman wrote: The minimakefile help lists: archive alias for command make-and-publish-archive but make-and-publish-archive is not listed as a command in the help, nor in the makefile. Is this description out of date? Question: can we do a long help for

Re: [Asdf-devel] minimakefile branch

Kambiz Darabi wrote: Hi Faré, do you think it is now obsolete to create a test git repo which contains the dependencies as git subtrees? There is probably a small value in having a repo with versions of the dependencies which are known to work. But I'm not sure about the trade-off of

Re: [Asdf-devel] mkcl and asdf upgrade. It works now.

On my linux box, I confirm that mkcl now passes the asdf upgrade tests on both master and syntax-case branches. ___ Asdf-devel mailing list Asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] mkcl and asdf upgrade

I have replicated this bug by doing the following: 1. update my copy of mkcl from git 2. build and install new mkcl 3. update my copy of ASDF, checking out master 4. do make in the ASDF root directory 5. do make test-upgrade l=mkcl in the ASDF root directory From this I get the following error:

Re: [Asdf-devel] converting asdf build test to Lisp

Well, let's try this again. I have looked more deeply, and it's amazing what you have achieved. I am left with my concerns about the interface that this scripting offers, but maybe by adding cl-launch (to remove the makefile layer), and providing better interaction for the user (completion +

[Asdf-devel] Test results

On Linux all the tests passed. On Mac, though, test-all-no-stop crashed: /bin/sh: command substitution: line 0: syntax error near unexpected token `newline' /bin/sh: command substitution: line 0: `for i in build/results/*-upgrade.text ; do case $(tail -1 $i) in Upgrade test succeeded for *'

Re: [asdf-devel] Make the CL syntax predictable

Attila Lendvai wrote: I do have control: If femlisp or any other library makes a boneheaded decision that breaks my software, I can stop using it. yes, resolving that is trivial -- once you have identified the problem. regarding the recent discussions i'm generally baffled why it is at

Re: [asdf-devel] Make the CL syntax predictable

Zach Beane wrote: Faré fah...@gmail.com writes: femlisp raises an interesting issue: it has (setq *READ-DEFAULT-FLOAT-FORMAT* 'double-float) in setup.lisp, which is cancelled by the with-standard-io-syntax that I introduce in my syntax-control branch. I just pushed a change in said branch to

Re: [asdf-devel] Make the CL syntax predictable

The thing that concerns me about this proposed change is that the poor programmer may look up the CLHS and see that the default value is specified to be 'single-float. If anything, I'd say that ASDF should force standards compliance, and use 'SINGLE-FLOAT. But I'd rather have ASDF just leave

Re: [asdf-devel] optimization settings

Managing scoped optimizations seems like something that should be at least partly handled by a CDR, if anyone pays any attention to those. It would be great if there was an expression, common to most CL implementations, that we could wrap around a call to COMPILE-FILE in order to impose an

Re: [asdf-devel] optimization settings

Robert Brown wrote: Does ASDF set compiler optimization settings before compiling each file when building? I'm concerned that changing the optimization setting inside one source file could cause the change to stick and be used for other files. I don't think the CL standard mandates that

Re: [asdf-devel] Make the CL syntax predictable

Quick follow-up: what about blowing this discussion into launchpad under the rubric of Manage CL syntax or something like that. I would prefer not to lose the discussion. I believe this is a place where a tool like POIU or XCVB really veers away from vanilla CL usage. Vanilla CL usage

Re: [asdf-devel] add-cldir helper script

Daniel Herring wrote: Re: [asdf-devel] Alternate default lisp system location On Wed, 12 Mar 2014, Zach Beane wrote: Is there some easy way, supported by ASDF, to make a system known to ASDF if you have its pathname? I added the following function to my ~/bashrc shortly after migrating to

Re: [asdf-devel] Fixing asdf-sytem-connections

Liam Healy wrote: Well, I think it has some use, though now in the Quicklisp era it's less important, and that is to define an optional dependency for something that's incidental to the main system. For example, one of my projects (Antik) defines units as part of a large system for doing

Re: [asdf-devel] Fixing asdf-sytem-connections

Thanks for the clarifications, Faré. I will ponder on further changes to the manual accordingly. I hadn't thought about *when* that :if-feature's value would be computed. I will make a note accordingly. Cheers, r

Re: [asdf-devel] One failure on ASDF 3.1.0.70 on Allegro/Windows

Dave Cooper wrote: Please test again with the latest ASDF and tracing uiop/run-program::%system with two colons. https://dl.dropboxusercontent.com/u/19667598/asdf-failures/3.1.0.73/clisp-test.text

Re: [asdf-devel] Re: Another grammar question

Faré wrote: On Sun, Feb 23, 2014 at 10:33 PM, Robert Goldman rpgold...@sift.net wrote: Faré wrote: On Sun, Feb 23, 2014 at 12:11 PM, Robert Goldman rpgold...@sift.net wrote: The :REQUIRE directive seems undocumented. Under what circumstances is it acceptable? If I remember the intent

Re: [asdf-devel] One failure on ASDF 3.1.0.70 on Allegro/Windows

Dave Cooper wrote: No, you ran this test today, but it uses 3.1.0.35, and the test doesn't trace the requested functions. You might have run it from a different directory than you extracted the asdf code. Please try again with the latest ASDF (3.1.0.72 or whatever).

Re: [asdf-devel] asdf loading error error

Faré wrote: On Sat, Feb 22, 2014 at 3:26 PM, Cyrus Harmon ch-l...@bobobeach.com wrote: While trying to load and asdf system that generates an error (that’s another story, presumably an abcl-contrib problem), I get the following error: Error while trying to load definition for system abcl-cdk

[asdf-devel] Re: Mistake (?) in grammar of defsystem

Thanks. This helps a lot. Follow-up question: :if-feature really doesn't make sense at the system level, does it? The grammar allows that, but it seems silly there. Am I wrong about this? I will add an example of suggested use of :IF-FEATURE to the manual. Best, r -- Robert P. Goldman

[asdf-devel] Another grammar question

The :REQUIRE directive seems undocumented. Under what circumstances is it acceptable? thanks, r -- Robert P. Goldman Staff Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice:(612) 326-3934 Email:rpgold...@sift.net

[asdf-devel] Re: Another grammar question

Faré wrote: On Sun, Feb 23, 2014 at 12:11 PM, Robert Goldman rpgold...@sift.net wrote: The :REQUIRE directive seems undocumented. Under what circumstances is it acceptable? If I remember the intent and interpret the source code correctly, it is always acceptable, but highly non-portable

Re: [asdf-devel] New release candidate?

Faré wrote: I have just compiled report for 3.1.0.67: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-35.html Looks good, no regressions. The two CCL failures are due to the previously discussed CCL:NO-APPLICABLE-METHOD-EXISTS (SETF CCL:SLOT-VALUE-USING-CLASS) BTW, I have

Re: [asdf-devel] The issue at hand

Robert Brown wrote: I have not been following every last detail of this conversation, so please forgive me if what I'm about to suggest is a terrible idea. [..snip..] All of the discussion I have snipped has been covered before, and fits under my declining to discuss further. I apologize,

Re: [asdf-devel] Releasing asdf 3.1.1 ?

Faré wrote: Dear Robert, do you think we can release this year? All tests pass for me on Linux, and I believe all tests were passing for Dave Cooper on Windows. There has been very light development this past month, with no intent for further development ahead, but notable new features and

Re: [asdf-devel] Detecting non-defsystem dependencies

Faré wrote: On Thu, Nov 7, 2013 at 9:35 AM, Zach Beane x...@xach.com wrote: Thanks. I started to implement this idea, but I'm concerned because ASDF already defines an unspecialized :before method on OPERATE. Is it safe to clobber it? If not, what should I do instead? Well, I would use a

Re: [asdf-devel] Detecting non-defsystem dependencies

Zach Beane wrote: Some system files look like this: myproject.asd (asdf:load-system some-prerequisite) (defsystem myproject ...) Can you recommend a good way to detect that system myproject depends on system some-prerequisite? Are there any hooks or other features of ASDF

Re: [asdf-devel] How to specify to ASDF to load system from current directory?

Faré wrote: —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org On Wed, Nov 6, 2013 at 3:00 PM, Robert Goldman rpgold...@sift.net wrote: Faré wrote: I disrecommend pushing '*default-pathname-defaults* into the *central-registry* — that makes system loading less

[asdf-devel] ASDF 3.0.3 released

Dear Lisp hackers, I am pleased to announce the release of ASDF 2.26. Since previous release 2.25, the changes are as follows: * Run-program much improved, with a slight backward incompatibility. See the new documentation about it. * Portability enhanced, with more robust Windows

Re: [asdf-devel] New issue with tests

Faré wrote: Do you get any output? We heavily modified run-tests.sh to be more robust with the way Windows implementations (fil to) parse command-line arguments; test-run-program has taken a beating, and the new test-stamp-propagation has never worked well on ABCL. Maybe we somehow broke

Re: [asdf-devel] 3.0.2.21

Faré wrote: Robert: can I commit this asdf-package-system branch now, before the 3.0.3 release? It's only additive features, modulo a rename of file asdf/defsystem to asdf/parse-defsystem (with a nickname for the old package name) and system asdf/header to asdf/prelude. Maintaining that topic

Re: [asdf-devel] New failures on Allegro Windows

These ok 1 errors look deeply mystifying to me, since the two strings look quite similar to me. Is it that run-program echo is somehow causing whitespace between ok and 1 to disappear? What *is* that whitespace? Just spaces, or are there tabs involved? Looking at test-run-program.script, it

Re: [asdf-devel] Re: Bug#723977: missing symlink in /usr/share/common-lisp/systems

Faré wrote: Robert: when do you instead to release 3.0.3 ? Otherwise, I could do a Debian package for 3.0.2.9. (PS: I took the liberty of also committing my load-systems* patch). I was waiting on those two more UIOP patches (see the launchpad tracker -- sorry I'm on a plane so I can't look

[asdf-devel] Version 3.0.2.9 available

Minor test tweak only. But one item off my todo list! ;-)

[asdf-devel] Pushed 3.0.2.8

Tweaked the bundle op so that writing DLLs on Mac generates files with dylib as extension instead of so. To do so, I added os-macosx-p to UIOP. Cheers, r -- Robert P. Goldman Principal Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN

<    1   2   3   4   5   6   7   8   9   10   >