- asdf-devel - mailman3.common-lisp.net

[asdf-devel] Are there nightly builds for trunk sources? (was: Re: CCL Windows: output from ccl:fasl-concatenate is "not a FASL file")
by Genworks Support 08 Apr '15

08 Apr '15

So this has been fixed (almost immediately after I opened the Trac ticket http://trac.clozure.com/ccl/ticket/1109!) in the trunk in: http://trac.clozure.com/ccl/changeset/15892 Now I am wondering how often the binaries (e.g. wx86cl.exe) in http://svn.clozure.com/publicsvn/openmcl/trunk/windows/ccl get rebuilt? Is there a nightly build so that I can simply do an svn update on this, or is it time to get set up with gcc on Windows and perform the Windows build of the trunk myself, in order to test this? Regards, Dave On Wed, Sep 4, 2013 at 4:36 PM, Dave Cooper <david.cooper(a)genworks.com>wrote: > > So I'm trying to get the ASDF test suite running on Windows, and tracked > this down as one of the failures for CCL (32-bit and 64-bit). (there were 5 > failures out of 47 tests, I haven't looked at the rest yet). > > This can be replicated as follows (with files from > > https://www.dropbox.com/sh/jc2cqwpkp06dupm/7lgyRUdwZ5/cl/tests/simple > ): > > > [below, substitute ".../'" for your actual path to the test files]: > > > > (lisp-implementation-version) > "Version 1.9-r15765 (WindowsX8664)" > > > (compile-file ".../try1") > > > (compile-file ".../try2") > > > (ccl:fasl-concatenate ".../try.wx64fsl" (list ".../try1.wx64fsl" > ".../try2.wx64fsl")) > > > (load ".../try.wx64fsl") > > ERROR: Not a FASL file. > > > Does anyone recognize what might be going on? > > > -- > My Best, > > Dave Cooper, Genworks Support > david.cooper(a)genworks.com, dave.genworks.com(skype) > USA: 248-327-3253(o), 1-248-330-2979(mobile) > UK: 0191 645 1699 > -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

1 0

[asdf-devel] Checking system names...... NOT
by Robert P. Goldman 08 Apr '15

08 Apr '15

Faré and James Anderson have convinced me I'm tilting at windmills here. I am in the process of reverting the checks and testing the results to make sure that I haven't messed up in the reversion process. Look for a 3.1.0.76 as soon as I'm sure the tests all pass. Bloodied, but unbowed, R

1 0

Re: [asdf-devel] Possible problem with check-compile-results
by Faré 08 Apr '15

08 Apr '15

You'd have to post the stack trace for us to tell. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org On Sat, Aug 24, 2013 at 5:02 PM, Robert Goldman <rpgoldman(a)sift.net> wrote: > Yes, the underlying problem was a version skew. But I was wondering if this problem tickled a problem in the way that ASDF (UIOP) bundles up errors and re-signals them. > > Best, > r >

1 0

Re: [asdf-devel] Alternate default lisp system location
by Daniel Herring 08 Apr '15

08 Apr '15

On Wed, 12 Mar 2014, Faré wrote: > 1- I think we should proceed and add a default path anyway. > ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one > complain about that. > You could make it ~/local/common-lisp/ if you're into larger paths. The computer I'm currently on uses ~/lisp for a lot of non-ASDF-related systems, including numerous files that are not source code. On some other systems, I use paths like ~/cl to distinguish from ~/racket and other dialects. I agree with others who dislike this idea. ASDF will inflict significant end-user pain for little benefit if it chooses to do a land grab on an obvious directory name. In my opinion, a lot of the complexity in ASDF, and a lot the motivation for this proposal, stems from ASDF's conflation of the "loader" with the "build system". That's the topic for another post... - Daniel

1 0

Re: [asdf-devel] 3.1.0.75 pushed: more checking of system names
by Robert P. Goldman 08 Apr '15

08 Apr '15

james anderson wrote: > >> My main concern is that ASDF behave understandably for all users, and >> errors about illegal pathnames appearing deep in the call tree, away >> from the reason for their occurrence, won't meet that requirement. >> >> This seems like another case where trying to be nice, instead of being >> strict, leads us to a place where *someone* must lose. If ASDF 1 had >> either refused logical pathnames, or refused inconsistent module >> names, we wouldn't be in this pickle... > > to pose a somewhat rhetorical question, why are module names necessarily > incorporated into logical pathnames? > Treating your question as literal, rather than rhetorical: If the system search path contains directories specified as logical pathnames, then when we try too find <foo.asd> we must merge <foo.asd> into the logical pathname. If, unfortunately, instead of "foo" we have "cl+ssl" or "foo_bar" the results are undefined. Actually, that's probably too kind. I think in fact the results *are* defined, and they are erroneous. the grammar of logical pathnames specifically excludes the use of symbols such as "+" and "_". If we have "fOo" and "foo" as systems, we may have collisions, since logical pathnames and some other filesystems cannot distinguish "foo.asd" from "fOo.asd". Faré reminds us that this also arises if we have (defsystem foo :components (:module "my_funky_module" :components ...) ...) where the system name is compatible with logical pathnames, but the module name is not. :pathname initargs provide another challenge.

1 0

[asdf-devel] A few more failures (was: Re: One failure on ASDF 3.1.0.70 on Allegro/Windows)
by Dave Cooper 08 Apr '15

08 Apr '15

With a bit more Windows testing we have 1 failure on SBCL and 3 or 4 on clisp. Here's a summary (the Allegro failure below is included in the attached file): On Fri, Feb 21, 2014 at 4:31 PM, Dave Cooper <david.cooper(a)genworks.com>wrote: > > Sorry to be late to the party again with Windows testing... > > So far I'm seeing a consistent failure for every Allegro variant on > Windows for test-sysdef-asdf. > > Here is the error: > > > These two expressions fail comparison with equal: > > (asdf-test::system-lisp-files :uiop) evaluates to ("uiop\\package.lisp" > "uiop\\common-lisp.lisp" "uiop\\utility.lisp" "uiop\\os.lisp" > "uiop\\pathname.lisp" "uiop\\filesystem.lisp" "uiop\\stream.lisp" > "uiop\\image.lisp" "uiop\\run-program.lisp" "uiop\\lisp-build.lisp" > "uiop\\configuration.lisp" "uiop\\backward-driver.lisp" "uiop\\driver.lisp") > > (asdf-test::makefile-lisp-files "driver-files") evaluates to > ("uiop/package.lisp" "uiop/common-lisp.lisp" "uiop/utility.lisp" > "uiop/os.lisp" "uiop/pathname.lisp" "uiop/filesystem.lisp" > "uiop/stream.lisp" "uiop/image.lisp" "uiop/run-program.lisp" > "uiop/lisp-build.lisp" "uiop/configuration.lisp" > "uiop/backward-driver.lisp" "uiop/driver.lisp") > > Script failed > > > > -- My Best, Dave Cooper

1 0

[asdf-devel] Re: Question about MKCL support
by Faré 08 Apr '15

08 Apr '15

On Tue, Mar 25, 2014 at 9:17 AM, Robert Goldman <rpgoldman(a)sift.net> wrote: > JCB complains that requiring UIOP:RESTART-IMAGE causes MKCL somehow to > end up sucking the compiler into programs, causing severe bloat. > > Can we provide an option to PROGRAM-OP that does *not* invoke > RESTART-IMAGE, satisfying him, but keeping the default behavior that all > applications restart identically? > Yes, that's totally legitimate and desirable as a non-default extension. Now that ECL and MKCL support have been merged, it was easy enough to implement this feature portably — test included (of course, before it was tested, it was completely buggy). Please try the program-system class with :no-uiop option in 3.1.0.105. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Trying to be happy is like trying to build a machine for which the only specification is that it should run noiselessly.

1 0

[asdf-devel] :here directive fails
by Kilian Sprotte 08 Apr '15

08 Apr '15

Hi, is (asdf:initialize-source-registry '(:source-registry (:directory (:here "asd")) :ignore-inherited-configuration)) still a valid call to make? I am getting the error NIL fell through ETYPECASE expression. Wanted one of ((EQL :USER-CACHE) (EQL :HERE) (EQL :HOME) (EQL :ROOT) CONS STRING PATHNAME). Running this through git bisect tells me that the last working commit is commit 61192882b468b74a7f5fbf810e138b94db5fdd2a Merge: f4a7eac 610ca23 Author: Robert P. Goldman <rpgoldman(a)gmail.com> Date: Tue Jan 8 13:16:34 2013 -0600 Merge branch 'master' of ssh://common-lisp.net/project/asdf/public_html/asdf The next commit then has a broken build and the next two commits fail with the above error, as does the current master. I will put a summary of those commits below. Regards Kilian FAILS commit 056f33a907f9ae3ffe5e0ae6aaa5f3b6f5bc863a Author: Francois-Rene Rideau <tunes(a)google.com> Date: Wed Jan 9 07:43:10 2013 -0500 2.26.64: checkpointing progress with define-package FAILS commit 4b1cea29891e45ee50c4114dd7b7c17b78cfc7fc Author: Francois-Rene Rideau <tunes(a)google.com> Date: Wed Jan 9 00:32:11 2013 -0500 2.26.63: more pathname hell. New pathname functions to work around more logical-pathname issues. See discussion with rpgoldman on asdf-devel, and see CCL ticket:953. Also, tweak build to reflect recent refactoring of asdf. WIP of define-package work needed for clean upgrade (still broken). broken commit 7c151aab3d9bf6460b7683c4498a230bf6ea9660 Author: Francois-Rene Rideau <tunes(a)google.com> Date: Tue Jan 8 15:34:51 2013 -0500 2.26.62: split into many packages, quick-build style. TODO: Create a define-package that can make it upgrade itself.

2 1

cl-launch 4.1.1.1
by Faré 01 Apr '15

01 Apr '15

(Only tangentially related to asdf; apologies if this is noise; please suggest a better channel.) I just pushed cl-launch 4.1.1.1, which minimally implements support for a --dispatched-entry feature that's mostly compatible with Xach's buildapp. Differences are: 1- like cl-launch in general, it works on all command-line Lisp implementations supported by ASDF, not just on SBCL and CCL 2- I don't do as much error checking as Xach; in case of conflict, last one wins. 3- I accept UIOP-style function designators for the main function, not just symbol designators, see uiop:ensure-function. Background: I'm more and more replacing my shell-scripts with CL scripts, but the startup time of a script can be very high if we load from fasl every time, even when no compilation is needed. On the other hand, dumping one image per script is expensive, with the smallest CL implementation (CLISP) taking about 16MB for every script. Therefore, I implemented --dispatched-entry in a way mostly compatible with buildapp. I can then dump a single image for all my scripts, and they start super fast, evaluate super fast, and only occupy a few tens of megabytes once. --dispatched-entry is implemented as a thin layer that delegates everything to a small new library call cl-launch-dispatch, to be distributed with cl-launch. That means it will actually slow things down a tiny bit if you use it without dumping an image, but won't slow things down at all if you don't use it and don't dump an image. Enjoy! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Democracy is a religion too. It's the worship of jackals by jackasses. — H. L. Mencken

1 0

os-cond patch pushed and version bumped to 3.1.4.4
by Robert P. Goldman 30 Mar '15

30 Mar '15

This patch passes all the tests for me that were passing before. I'm still not convinced that our patch for Bug 1437480 is ready to go yet, so I have held off that one, to minimize chances we'll need to backtrack.

1 0