asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

lisp-invocation with lispworks very unpleasant
by Robert Goldman 31 Aug '15

31 Aug '15

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 unbearable. Anyone have any idea why this happens? thanks, r

1 0

Toward an ASDF 3.1.6 ?
by Faré 31 Aug '15

31 Aug '15

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 and a better run-program on ECL. I still advocate merging in the minimakefile branch before 3.1.6. It will really make releasing and testing easier, especially on Windows. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You may easily play a joke on a man who likes to argue — agree with him. — Edgar Waston Howe

2 2

Package inferred system base pathname
by David Vázquez 30 Aug '15

30 Aug '15

Hi, In the past I have used modules with the pathname keyword in order to specify that a group of files come from a subdirectory. However, I cannot find how to do this if I use the package inferred system approach. Basically what I would like to achieve is: (asdf:defsystem :myproject :name "" :description "" :version "0.0.1" :pathname "src" ;; non-existing keyword :class :package-inferred-system :defsystem-depends-on (:asdf-package-system) :depends-on (:myproject/all)) and all.lisp will be loaded from src/all.lisp. Is that possible somehow? Thanks in advance. David.

2 1

Fwd: [spr42456] More issues with Allegro 10 (and ASDF)
by Faré 26 Aug '15

26 Aug '15

Looks like I fumbled. This wasn't caught by our automated tests, because they redirect the cache. Sigh. Maybe we need a 3.1.6 some time soon? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If prices are information, then subsidies are censorship. — Russ Nelson ---------- Forwarded message ---------- From: Faré <fahree(a)gmail.com> Date: Wed, Aug 26, 2015 at 6:38 PM Subject: Re: [spr42456] More issues with Allegro 10 (and ASDF) To: "The Franz Inc. Bug Handling System" <support(a)franz.com>, Kevin Layer <layer(a)franz.com> On Wed, Aug 26, 2015 at 5:16 PM, Kevin Layer <layer(a)franz.com> wrote: > It does seem like 3.1.5 is broken on Windows: > > ((os-windows-p) (xdg-data-home "cache")) > > and xdg-data-home calls resolve-absolute-location, which would seem to > want an absolute pathname, but "cache" doesn't qualify. > > I've rolled back to the previous ASDF version, and will await your > advice on how to proceed. > Ouch, this is an embarrassing bug, indeed. This "cache" should be "cache/" — does it work when you fix it? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Democracy is a pathetic belief in the collective wisdom of individual ignorance. — H. L. Mencken

1 0

Question from the old school: source config DSL
by Robert Goldman 24 Aug '15

24 Aug '15

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 pprint the variable, eyeball it, and it's usually pretty easy to see whether a directory is missing. But what do you do if you use the DSL? The last time I tried to use the DSL, I found myself using the inspector to grovel over internal-to-ASDF hash tables, which wasn't very pleasant. Is there a "debugger API" to the new source configuration search? E.g., can we dump the hash-table in a human readable (sorted, formatted way?)? can we trace something to see how ASDF is populating the hash table? cheers, r

2 3

Re: Question from the old school: source config DSL
by Faré 24 Aug '15

24 Aug '15

>> You can >> (alexandria:hash-table-alist asdf/source-registry::*source-registry*) >> >> or for a higher-level view, you can >> (asdf/source-registry:flatten-source-registry) >> >> then again, if you use the newfangled source-registry-cache, you can >> find ~/common-lisp -name .cl-source-registry.cache > > Sweet. Those I have wished for sometimes. Thanks! > > So what does "a higher level" mean? How do those two views interrelate? I > guess it's in the code, but the asdf code is smarter than me... > Well, if you read source-registry.lisp, function compute-source-registry (itself called by initialize-source-registry), you'll find that 1- the configuration is "flattened" into this list of entries 2- .asd files found in the directories and trees listed are accumulated into the *source-registry* table. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If a trainstation is where the trains stop, what is then a workstation... — Lars Lundgren <d95lars(a)dtek.chalmers.se>

1 0

The case for merging the minimakefile branch
by Faré 01 Aug '15

01 Aug '15

What makes the minimakefile branch great: * It provides a nicer test experience: the output is quieter and more readable and makes it obvious which tests scripts succeeded or failed, with a nicer summary at the end. All the verbose output is still available in a clearly indicated log file. * It has a nicer failure behavior: more detailed instructions are printed when a test fails, and these instructions, being extracted from the test command, are guaranteed to be in synch with the command, whereas the shell script in the master branch often gets slightly out of synch, and probably is out of synch right now. * It has better-working release functions (for tarballing, making debian packages, etc.) than the master branch. Actually, what's in master currently fails, and I had to use minimakefile for the latest release. A lot of the release scripts could be backported, since even in master, the release is done by bin/asdf-builder which is already a Lisp script — but that would be work. * It is much easier to write and maintain than the shell scripts it replaces; iterating over lists, filtering them, building lists of files, ensuring that the list of files used to bootstrap asdf with make is identical to the list used to bootstrap asdf with asdf, etc. Higher-order functions with good scoping discipline beat shell functions any day. run-tests.sh is an unkempt horror, and so are all the little bits of Makefile magic. * It removes any dependency on perl, sed, dirname, etc. Actually, it removes dependency on any Unix utility, potentially even make, so the tests could run on Windows (with make and a Unix shell, a new ./make.bat file to start asdf-tools might be required, though; on Unix, a ./make.sh could replace make). * You can run and debug all the ASDF tests and all the ASDF release functions in subprocesses from the SLIME REPL instead of running them from the shell. Particularly useful when debugging them with tracing, stack inspection, etc. * It has no change to asdf itself, only to the build, test and release infrastructure. Previously valid objections that have been addressed: * Sure, Lisp scripting is a new thing, but even in master, that's what the release script bin/asdf-builder is, with the same dependency on inferior-shell. What the minimakefile does is generalize this mechanism for tests and for all the things that the Makefile does. * minimakefile uses many Lisp libraries as dependencies. But they have all been added as git submodule's already, and so should actually reduce the dependency on things outside source control, as opposed to all the using utilities used in master (including sed and perl -- ouch). * Sure, our Lisp dependencies themselves are moving targets and might not have completely stable APIs, but by using git submodule, we are protected from any future breakage — we can always keep versions that are known to work for us (as they currently are), or revert to them if we try to upgrade and fail. * Sure this branch is bigger: git diff --stat master minimakefile says there are 1455 insertions, 1199 deletions, which means the asdf-specific code is 21% bigger — but it is also vastly more documented that the Lisp and shell scripts it replaces, and does more things. Actually, if * Sure, writing it from scratch and dealing with the novelty of it would be hard, but it's been done already, the kinks have been ironed out, a few libraries have been spun off of it, and it's even running on Windows. Additionally, merging to master will save me the trouble of maintaining the branch. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org One advantage of living abroad is that there is no pretense whatsoever to represent me as I'm being taxed. TAXATION WITHOUT REPRESENTATION!

1 1

ASDF 3.1.5 is now released!
by Robert Goldman 21 Jul '15

21 Jul '15

1 0

Draft release email
by Robert Goldman 19 Jul '15

19 Jul '15

If you have any feedback about this before I send it out, please respond to the list or directly to me. Thanks!

2 2

restarts vs debugger command
by 73budden . 16 Jul '15

16 Jul '15

Hi! > You 'access' a debugger stack by using handler-bind and restart-case. > Then the user uses the debugger that can use the annotations. This > modular design is a great strength of CL. Yes, I was wrong. It is easy to capture condition with handler-bind and restart-case. But what about "normal" operation? E.g. I use "of-system" to declare and assert that the file is loaded through a correct system. Only a special variable works there as there is no condition at all. > You don't understand what I said. I was thinking of a handler-bind > that does something like > (handler-bind ((some-asdf-condition (e) ... (restart-case (error e) > (edit-file () :report ... (funcall *editor* (condition-component > e)))))) ...) What edit-file does? It can call external editor, wait while user finishes the editing and then retry operation. But in SLIME and Lispworks my code does just some other thing: asynchronous message is sent to IDE so that file is opened in the IDE. The editing is done in another thread and maybe in anoter process (as with SLIME/EMACS). Debugger with all restarts is still available, so user can choose any restart. When user decides what to do, he can invoke the restart he wants. After sending a message a control is returned to handler function. What is the reasonable action of that function? IMO the only reasonable action is to resignal the condition. This is unnecessary blinking, or unnecessary output: user just starting to edit, and resignaling does not supply user with any new useful information. This is the difference between restart and "debugger command". Restart either fixes the problem or resignals condition (maybe some new one). Debugger command (e.g. "show source" or "eval in frame") does another thing: it just evaluates some code in current context and then returns to the debugger without restarting. My extension can be kept separated, but it defines some around method and thus can interfere with other extensions which could also define the same method. This is not very good. Also maybe I can use some wrapper function to asdf::oos instead of patching asdf, but it will not work in the cases where load-system is called implicitly, e.g. from ql:quickload.

3 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel