asdf-devel April 2015

asdf-devel@common-lisp.net

54 participants
184 discussions

[asdf-devel] (asdf:system-source-directory :uiop) not working after upgrade to 3.0.2.25
by Dave Cooper 08 Apr '15

08 Apr '15

Hi, There is an outstanding request from the maintainer to test the latest asdf "in production," and I'm here trying to do that. So what do I have to do in order to make (asdf:system-source-directory :uiop) still work after upgrading asdf? Is it a bug that after upgrading from 3.0.2.3 (the current ASDF shipping with fully patched Allegro) to 3.0.2.25, then (uiop:system-source-directory :uiop) returns nil? Before upgrading, it returns the uiop-3.0.2.4/ in the quicklisp/dists/quicklisp/software directory. After upgrading, it returns nil. The impact of this in production is that I am trying to make a monolithic fasl of a system which depends on :uiop, and the :uiop module is not getting included in this monofasl. This of course results in "package missing" errors when trying to load this monofasl into a vanilla image to do a build. The way I install asdf 3.0.2.25 for trying to use it in production is: 1. git pull into my local asdf directory. 2. make (to make a single asdf.lisp file in asdf/build/) 3. copy this to quicklisp/asdf.lisp 4. rm -r quicklisp/cache 5. edit quicklisp/setup.lisp to say: (defvar *required-asdf-version* "3.0.2.25") 6. copy the uiop/ directory from local asdf/ into quicklisp/local-projects/ 7. restart the Lisp 8. load quicklisp/setup.lisp and (ql:register-local-projects) Having done all this, the (asdf:system-source-directory :uiop) still returns nil, and uiop is not ending up in my monofasls which depend on it. Am I doing it wrong? My Best, Dave

2 3

[asdf-devel] unsubscribe
by Brett van de Sande 08 Apr '15

08 Apr '15

Two things: The links to asdf-devel and asdf-announce on http://common-lisp.net/project/asdf/#mailing-lists are dead. Also, how do I unsubscribe? Brett

4 4

Test failure: CCL 1.9 on Mac OSX
by Robert Goldman 08 Apr '15

08 Apr '15

Just pulled and ran all the tests, and CCL 1.9 fails test-utilities on Mac OSX: TEST ABORTED: These two expressions fail comparison with EQUAL: NIL evaluates to NIL (FISHY-ASDF-EXPORTED-SYMBOLS) evaluates to (ASDF/OPERATION:ORIGINAL-INITARGS) cheers, r

2 2

[asdf-devel] The issue at hand
by Robert P. Goldman 08 Apr '15

08 Apr '15

James Anderson has asked for a "concise statement of the issue at hand." Faré has had to change the semantics of the OPERATION class. Previously, the OPERATION class would automatically trigger dependencies downward (notably, if you did an OPERATION on a system, then you had to do that OPERATION as well on that OPERATION's children), "leftward," and onto itself ("selfward"). The implementation of this left holes, and also caused problems for extensions (e.g., for TEST-OP, one typically had to define a default PERFORM that did nothing, since testing a system necessarily tested all of the files). To fix this, Faré had to add new mixin classes, DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION, and SELFWARD-OPERATION. In order to preserve the integrity of the code, OPERATION remained as the superclass of all operation objects. But its semantics has changed. This is not a problem for anyone with a "vanilla" ASDF system. The only programmers who are vulnerable to this change are those who have defined their own subclasses of OPERATION (or those who use libraries whose programmers have defined subclasses of OPERATION). For those cases, I have pushed a change that checks to make sure that all operations that are instantiated are subclasses of either DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION, SELFWARD-OPERATION, or a new NON-PROPAGATING-OPERATION. If this run-time test fails, an error will be signaled and the programmer will have to fix the offending OPERATION subclass's definition.

8 28

[asdf-devel] Problem with CMUCL 20e and ASDF
by Pascal Costanza 08 Apr '15

08 Apr '15

Hi, I just installed CMUCL 20e on my Mac OS X 10.8.5. CMUCL 20e release notes say that it comes with ASDF 3.0.2. My .cmucl-init.lisp file looks like this: (setf (logical-pathname-translations "costanza") `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl" (lisp-implementation-type) (lisp-implementation-version))) ("**;*.*.*" "/Users/costanza/**/*.*"))) ;;; The following lines added by ql:add-to-init-file: #-quicklisp (let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp" (user-homedir-pathname)))) (when (probe-file quicklisp-init) (load quicklisp-init))) When I start CMUCL, I see this: ; Loading #P"/Users/costanza/.cmucl-init.lisp". ;; Loading #P"/Users/costanza/quicklisp/setup.lisp". ;;; Loading #P"/Users/costanza/lib/cmucl/lib/contrib/asdf/asdf.sse2f". Error in function UIOP/UTILITY:CALL-FUNCTION: Invalid pathname #P"~/lisp/develop/": Expected an absolute pathname [Condition of type SIMPLE-ERROR] Restarts: 0: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system asdf after reinitializing the source-registry. 1: [CONTINUE ] Return NIL from load of #P"home:quicklisp/setup.lisp". 2: Return NIL from load of "home:.cmucl-init". 3: [ABORT ] Skip remaining initializations. Debug (type H for help) (UIOP/UTILITY:CALL-FUNCTION ERROR "Invalid pathname ~S: ~*~?" #P"~/lisp/develop/" :WANT-ABSOLUTE ...) Source: ; File: modules:asdf/asdf.lisp ; File has been modified since compilation: ; modules:asdf/asdf.lisp ; Using form offset instead of character position. (APPLY (ENSURE-FUNCTION FUNCTION-SPEC) ARGUMENTS) 0] What do I do? Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

3 4

[asdf-devel] NAMED-READTABLES
by Robert P. Goldman 08 Apr '15

08 Apr '15

Faré wrote: >> > *This is partly my fault, but the current disarray of cl.net, the >> > library's position as part of an abortive EDITOR-HINTS master system, >> > and the previous maintainer's putting it into a revision control system >> > (darcs) that I don't use and don't understand are additional >> > contributing factors. >> > > If you're the new maintainer, I suggest converting the darcs > repository to git and maybe putting the library on github. I don't know enough to translate a darcs repo to git. I could probably manage this, but tcr buried the NAMED-READTABLES repo somehow inside an EDITOR-HINTS repo, and linked the two in some way I don't understand. This problem is compounded by the fact that when I tried to figure out how to fix it, the email on cl.net was broken so that admin requests went into the bit-bucket. There are pending patches I need to push into NAMED-READTABLES, but I would need some assistance to fix this. I note that NAMED-READTABLES are necessary to support your proposed changes, but *are not sufficient*, since support for named readtables would have to be added to the development environments. I would like to forestall facile answers to the above claim, too. I don't just mean "SLIME would have to handle IN-READTABLE." SLIME would have to be fixed, yes, but also ELI, Allegro Composer, Hemlock (or whatever the CCL IDE is), LispWorks whatchamacallit, etc., etc. ASDF should not demand a programming style that doesn't have full support for in-editor dynamic code writing and maintenance. Yes, this means that there can be bad libraries out there, but there are lots of crappy libraries even aside from misusing readtables or pretty-print dispatch, and ASDF cannot fix them all.

3 2

[asdf-devel] Please test before releasing ASDF 3.0.0 - Also, resigning again
by Faré 08 Apr '15

08 Apr '15

Dear Lisp hackers, I'd like to release ASDF 3.0 next week (maybe even later this week). Can you test ASDF before I do? I'll have to produce some document explaining the innovations since ASDF 2.26, 2.000 and/or 1.369, but for now here are just the changes since 2.33. As you can see, it's very minor stuff, and ASDF has been mostly stable these last two months, which is a good sign and the reason why I'm making an official 3.0 release. I'm also inserting a new digit in the version, so releases will have three digits: 3.0.0, 3.0.1, etc. will be minor continuations of 3.0. 3.1.0 will be the next "major" milestone in a series that preserves compatibility, and 4.0 (if ever) will be the next major release that doesn't. But I probably won't be there to see it, because I'm moving away from my Common Lisp job in Cambridge MA to some new as yet undetermined opportunities in NYC that are unlikely to see me do Common Lisp for a living, and I plan to try out different Lisps for a hobby (Racket, Maru, etc.). * Portability: have *uninteresting-conditions* be empty by default. Move stuff to *usual-uninteresting-conditions*, unused by default. Will make the SBCL team happy. Also, fix tests on ABCL. * UIOP: improvements to slurp-input-stream and thus run-program, notably accepting T as alias for *standard-output*, for better backward-compatibility of the deprecated run-shell-command. New macro with-output-file. * POIU support enhanced various tweaks. * Build cleanups. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Of all the things I've lost in life, I miss my mind the most... — Ozzy Ozbourne

5 12

[asdf-devel] Unable to upgrade asdf using clisp 2.49 on Mac OS X
by Robert P. Goldman 08 Apr '15

08 Apr '15

On Mac OS X, when I try to upgrade my ASDF using the logical pathnames "home:lisp;asdf;" and "home:lisp;asdf;uiop;" I get this error: *** - While searching for system "asdf": "home:lisp;asdf;uiop;" evaluated to "home:lisp;asdf;uiop;" which is not an absolute directory. Note that I am using ASDF:*CENTRAL-REGISTRY*, not the configuration DSL. But: Break 1 [2]> (translate-logical-pathname "home:lisp;asdf;uiop;") #P"/Users/rpg/lisp/asdf/uiop/" Is this expected behavior from clisp + ASDF? This same configuration works on ACL and SBCL, which suggests its a clisp issue.

2 6

[asdf-devel] ASDF testing for LWW
by Dave Cooper 08 Apr '15

08 Apr '15

Hi, I've been helping with ASDF regression testing on Windows, where we use a cygwin shell to run the ASDF test scripts. We don't have LispWorks licensed for Windows currently, so I looked at using the Personal Edition. But this is apparently not possible because the ASDF tests assume a "console image," which is supposed to be created with save-image --- functionality which is not available in the Personal Edition. So my questions are: 1. Is there something I'm missing which would indeed allow me to produce a console image (or something which behaves like one) from LWW Personal? 2. If not, would anyone with a licensed LWW be willing to run the ASDF regression tests? I will be happy to step you through the process. For what it's worth, so far I have the following implementations covered for Windows: Allegro CL 9.0 CCL 1.10-dev CCL 1.9 SBCL 1.1.12 Anyone who would like to test any other implementations on Windows should feel welcome to reach out to me for guidance on how to set them up as well. -- My Best, Dave Cooper, Genworks Support

3 5

[asdf-devel] :depends-on to load-system or require-system?
by John Morrison 08 Apr '15

08 Apr '15

Hi All; tl:dr - AFAICT post-version-2.26-ish versions of ASDF systems listed in :depends-on are unconditionally loaded rather than required - ditto for asdf:load-system. If this is correct (both in intent and my understanding), then how to create a GUI for quicklisp in McCLIM which can quickload any system which :depends-on McCLIM? Apologies in advance in the likely event this is Pilot Error. Am trying to write a gui<https://bitbucket.org/symbolicsimulation/com.symsim.oss.ql-gui>for quicklisp. Testing on various platforms (Raspberry Pi, linux/SBCL, linux/CCL) with various vintages of ASDF produces differing behavior. In particular, quickloading a system which depends upon McCLIM from the McCLIM-based gui screws up (I haven't tracked down the exact problem, but I could understand why unconditionally reloading McCLIM while it's running could get weird). After some digging (and rebuilding various versions of SBCL up to 1.1.9), I got as far as seeing asdf:load-system behavior diverging from 2.26 (SBCL 1.0.9) to both 2.32 (CCL 1.9) and 3.0.2 (both SBCL and CCL). AFAICT 2.26 load-system does not unconditionally load an already-loaded system (behaving like and perhaps redundant to asdf:require-system). 2.32 and 3.0.2 load-system unconditionally load systems, and require-system does not. I think I understand why the newer vintages do this. The issue for me is loading systems that :depend-on McCLIM from inside a McCLIM frame command. In my naivety, I would think that the :depends-on systems should be required rather than loaded (if you've patched them, say, you wouldn't want the patch hammered). For my own stuff, I guess I could require prerequisite systems within the asd file rather than :depending-on them, but this seems wrong (breaks introspection?) - so wrong I feel I may be going about this entirely the wrong way. Would anybody please be so kind as to throw some advice my way? -jm

4 9

← Newer
1
2
3
4
5
6
7
...
19
Older →

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