asdf-devel February 2010

asdf-devel@common-lisp.net

17 participants
39 discussions

[asdf-devel] last note about the module dependencies for now...
by Robert Goldman 10 Feb '10

10 Feb '10

I believe by adding a little bit more hair (a test that a component IS a module and IS NOT a system) to the TRAVERSE structure, I can salvage INTRA-system dependencies involving modules without trying to fix INTER-system dependencies, which seems like too big a bite to chew off. What would people think about that? I'm afraid, pace James A, that this won't make the code a lot simpler or more elegant, but it will make the behavior more predictable, which is a Good Thing. This exhibits a Common Lisp hassle pattern I have written myself into far too often --- you make a class (in this case system) inherit from another class (in this case module), and later on find that you should have built a triangular relationship between module, system and a common superclass. Introducing that common superclass is often quite painful.... In this case, I think backward compatibility rules out this kind of refactoring (impossible to tell whose system subclasses you might break), so the best we can do is put on some inelegant band-aids like (when (and (typep x 'module) (not (typep x 'system)) ....) cheers, r

1 0

[asdf-devel] New module-depends branch contents pushed
by Robert Goldman 10 Feb '10

10 Feb '10

Not a fast-forward push. But should be well worth it! Best, r

2 2

[asdf-devel] Refined the module dependency fix
by Robert Goldman 10 Feb '10

10 Feb '10

I have a series of patches I am about to push to the module-depends branch. Because I have had to rebase this onto master as new master changes have come in, this will not be a fast-forward update when you pull it into your local repo. So this is a head's up. I will push the update sometime after lunchtime my time (US Central time). Question: is anyone trying this out? Anyone have a good criterion for when I should close this branch out and merge it into master? Best, Robert

1 0

[asdf-devel] Looking for some help crafting a test case
by Robert Goldman 10 Feb '10

10 Feb '10

I believe my first ASDF patch had a minor buglet that could cause over-compilation. Here's the deal: when new TRAVERSE detects that the components of a module need to have an operation performed on them, it binds a dynamic variable and calls itself on the components of the module. The dynamic variable forces the components to be done even when they satisfy operation-done-p. This has an effect equivalent to propagating the module's dependencies onto the children. However, this also means that the dynamic variable is in place when we call TRAVERSE recursively on the dependencies recorded on the children, then those dependencies are forced to happen as well. In /theory/ this could cause over-compilation, over-loading, etc. However, I cannot come up with a test case where this will /actually/ occur. Why is that? It's because components of modules cannot "reach out" of the containing module to depend on anything in their surroundings. E.g. if I have a module FOO, then components of FOO can record dependencies only onto other components of FOO. This is a consequence of how name resolution works in ASDF. So I have what I think is a fix for performing unnecessary operations in ASDF, but I cannot figure out a way to craft a test case where unnecessary operations could actually occur. I feel like I should put the patch in anyway, in case we change the rules on name-lookup in ASDF, but this feels wrong. Any suggestions? Have I missed something? Is there any way, for example, a component of FOO could depend on an outside system? I don't believe that this is possible, but I could be wrong. thanks, r

2 1

[asdf-devel] clisp getuid
by Pascal Bourguignon 08 Feb '10

08 Feb '10

In asdf.lisp downloaded from the web page this afternoon, line 500. With clisp, the package LINUX is available only in special circumstances. (it has to run on Linux, AND the glibc bindings module must have been compiled AND clisp must have been launched with it, usually with -Kfull). So when using the LINUX package on clisp, we must test for it explicitely: #+(and clisp #.(cl:if (cl:find-package "LINUX") '(:and) '(:or))) (defun get-uid () (linux:getuid)) A better alternative is to use POSIX:UID, which is available on a wider range of systems (IIRC, MS-Windows is POSIX too): #+clisp (defun get-uid () (POSIX:UID)) (and similarly for the PID if needed, (POSIX:PROCESS-ID)) -- __Pascal Bourguignon__

2 1

[asdf-devel] A shot at fixing the module dependency bug
by Robert Goldman 08 Feb '10

08 Feb '10

OK, I have committed a first shot at fixing this. However, there is no easy way to have a module update its components upon dependency change but not have a system update its components upon dependency change, because a system is a subclass of module. So my path may not be desirable, or at any rate the community may want to think about it a bit before adopting it. Furthermore, I did the patch as a minimal perturbation to TRAVERSE, which has a structure which I, at least, find somewhat difficult to follow. The structure is one large function with a FORCED variable which holds the plan (sequence of OP . COMPONENT pairs). This large function contains three sub-functions in LABELS that destructively modify the FORCED variable. I think a good case could be made for breaking those sub-functions out (for easier tracing, if nothing else), and having them return values that are appended onto the list, instead of side-effecting. But this is an aesthetic matter, and would also create many problems for understanding the modifications I made, so I did NOT do this. Since these changes seem to me controversial, I did not push my changes into the main repository, but instead added a "module-depends" branch to the common-lisp.net git repository. I hope that this will make the changes easier to assess. Cheers, r

2 1

[asdf-devel] Launchpad bug 502946
by Robert Goldman 07 Feb '10

07 Feb '10

Wrt https://bugs.launchpad.net/asdf/+bug/502946, module is not recompiled if _intra_-system dependency changes, I have spent quite some time groveling over the source code to TRAVERSE, and I believe that this is going to be quite difficult to fix. There are a number of assumptions baked into TRAVERSE, and some complicated uses of a variable scoped over the body of TRAVERSE, together with a number of local functions and a soupcon of unstated assumptions. I'm pretty sure that modules are substantially broken and, in the short term, I would discourage ASDF system designers from using them at all. I have been banging my head on this for at least a working day's worth of hours, and I need someone with whom to discuss the code, either by voice, IM or IRC. Email is not going to be high enough bandwidth. If anyone is interested in this enough to share the pain with me, please drop me a line and we can coordinate. Thanks, r

1 0

[asdf-devel] asdf 1.600
by Faré 04 Feb '10

04 Feb '10

I just released ASDF 1.600 in the official repository. Since my last "official release" 1.502, there is * AOT replacing ABL. AOT allows you to define a set of pathname translations in a configuration file. * Some cleanup of the ECL integration. * *asdf-revision* has been replaced by *asdf-version* * minor updates to tests, documentation I think I did all the major changes I wanted for upgradability and configuration. Now for a round of testing, bug fixes and documentation before I try to push the result as "ASDF 2". You are welcome to try the new functionality and send feedback, remarks, questions. Which glaring bugs would you like to see fix before an official release? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A student who changes the course of history is probably taking an exam.

3 12

[asdf-devel] [PATCH 1/2] Quash style-warnings in the compile-script for tests.
by rpgoldman＠sift.info 04 Feb '10

04 Feb '10

From: Robert P. Goldman <rpgoldman(a)real-time.com> Previously, style warnings in compiling asdf.lisp would cause the test script to fail. Modified to quash style warnings (but not other warnings) during build. --- test/compile-asdf.lisp | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-) diff --git a/test/compile-asdf.lisp b/test/compile-asdf.lisp index 60bca6d..168c189 100644 --- a/test/compile-asdf.lisp +++ b/test/compile-asdf.lisp @@ -4,15 +4,19 @@ (cond ((probe-file "asdf.lisp") (multiple-value-bind (result warnings-p errors-p) - (compile-file "asdf.lisp") + ;; style warnings shouldn't abort the compilation [2010/02/03:rpg] + (handler-bind ((style-warning + #'(lambda (w) + (princ w *error-output*) + (muffle-warning w)))) + (compile-file "asdf.lisp")) (declare (ignore result)) - (cond (warnings-p + (cond (warnings-p (leave-lisp "Testuite failed: ASDF compiled with warnings" 1)) - (errors-p + (errors-p (leave-lisp "Testuite failed: ASDF compiled with ERRORS" 2)) (t (leave-lisp "ASDF compiled cleanly" 0))))) (t (leave-lisp "Testsuite failed: unable to find ASDF source" 3))) - - \ No newline at end of file + -- 1.6.5.3

3 4

[asdf-devel] Bootstrapping asdf
by Robert Goldman 04 Feb '10

04 Feb '10

"The best is the enemy of the good." --- Voltaire There seems to be a strong sentiment from at least part of this mailing list that ASDF loading should be reorganized so that some minimal core functionality is loaded, and more can be loaded on demand. I'd like to go on record as opposing this. I see the arguments for tidiness involved, but I think there are some powerful arguments against doing this: 1. It raises the bar for ASDF novices. Every line we add to a lisp init file is a huge cost, from my point of view. I'd prefer we kept it to (require :asdf). 2. It makes testing more complicated. In order to be confident that code works properly, we will now have to test it in a number of configurations that will grow exponentially with the number of modules to be loaded. If we have a relatively big core, we can get away with one run of the test suite per lisp implementation X platform. 3. Related to 2, it makes development of ASDF system definitions more tricky. Now, in order to write an asdf system definition, you will have to track which modules you have loaded, and which modules the eventual users of your system definition are likely to have loaded. You may have to modify your ASDF system definition so that it forces load of modules. This is deeply undesirable, IMO, since doing this is outside the declarative DEFSYSTEM core of ASDF. 4. It is effort that we do not have in superabundance. There are outstanding ASDF bugs --- simple bugs like tests failing --- that are not getting fixed. An exercise in refactoring and tidiness will take more of the lifeblood away from core development. 5. It will create a revision control system merge hassle. Restructuring means moving stuff back and forth among files. This will neatly foil diff and emerge. I had enough of that back when we moved to git. I still haven't recovered the work I did on implementing clean-op, and backporting from markdown to texinfo was a drag. This last is not critical, if the transition is made in one swift, well-scheduled cut-over. Best, R

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel February 2010