asdf-devel April 2015

asdf-devel@common-lisp.net

54 participants
184 discussions

[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] :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

[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

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel April 2015