asdf-devel April 2015

asdf-devel@common-lisp.net

54 participants
184 discussions

[asdf-devel] New release candidate?
by Faré 08 Apr '15

08 Apr '15

3.1.0.70 it is. Passes all tests for me, on Linux x64 on ccl clisp sbcl cmucl allegro allegromodern lispworks ecl_bytecodes ecl abcl xcl gcl Before some patches I just committed for xcl and gcl (!) 3.1.0.68 worked on Mac for Robert Goldman. (Any volunteer to test on Genera? Corman? MCL? Windows?) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Capital is past work. Undermining the rights of past and future workers in favor of present workers is sure to backfire on them tomorrow when their today's work is past and their tomorrow's work has been robbed already.

3 10

[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] Merged Fare's RUN-PROGRAM topic branch
by Robert P. Goldman 08 Apr '15

08 Apr '15

I have merged Fare's RUN-PROGRAM topic branch and pushed it as 3.0.2.11. Passes all the tests for Fare and me on Linux and for me on Mac (modulo known bugs in bundle-op). My intention is to release this as 3.0.3 in the next few days, but I would like to make it available for people to play with first. I'm of course happy for you all to run the test suite on your own machines and implementations (contact me if you need help setting this up), but even more, I'd be obliged if you were to test this on your own systems (again, ask for advice if you need help setting up to do this). I'd particularly urge you to try this on systems where you have made your own extensions (new component or operation classes), or where you reach out into the environment to do something else (e.g., run "make" or the C compiler for FFI). Those would be the most likely to expose bugs in the new facilities. Best, r

2 1

[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] rename-file-overwriting-target on clisp
by Sam Steingold 08 Apr '15

08 Apr '15

Hi, I wonder why this function has a special case for clisp: (defun rename-file-overwriting-target (source target) #+clisp ;; But for a bug in CLISP 2.48, we should use :if-exists :overwrite and be atomic (posix:copy-file source target :method :rename) #-clisp (rename-file source target #+clozure :if-exists #+clozure :rename-and-delete)) it would seem that a more portable solution would be (defun rename-file-overwriting-target (source target) #-clozure (when (probe-file target) (delete-file target)) (rename-file source target #+clozure :if-exists #+clozure :rename-and-delete)) this code causes build problems in clisp because when asdf is distributed with clisp, it is built before the posix module is available. also, nobody uses 2.48 anymore, so I think you can safely assume 2.49. thanks. -- Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>

2 2

[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] Reader conditionals in :depends-on considered harmful?
by Dave Cooper 08 Apr '15

08 Apr '15

Hi, Is stuff like the following advised/recommended? ;;;;; (asdf:defsystem #:robot :description "The Gendl™ Simplified Android Robot example " ... :depends-on (#-gendl :gendl) ... ) ;;;;;; The scenario is that we ship a pre-built Gendl image which has no asdf or Quicklisp in it (but does, of course, have :gendl included in *features). Downstream user is then free to load Quicklisp and start pulling in libraries. But if they pull a library (or application, like :robot), which normally should depend-on :gendl, then we don't want it trying to reload the whole gendl system, since it's already built in. I know this was discussed here briefly around the launch of 3.0.3 but I'm still not completely clear on how it should work. If we don't include ASDF and Quicklisp at all in our pre-built image, then I don't see any way for us to tamper with e.g. asdf's registry search functions. I guess the only way to do that would be to provide a custom function for installing Quicklisp and ASDF -- but we have no guarantee that the user will actually follow our function and not simply try to install Quicklisp according to the instructions at quicklisp.org. -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype)

3 2

[asdf-devel] Volunteer for LispWorks testing?
by Robert Goldman 08 Apr '15

08 Apr '15

Does anyone have a paid license to LispWorks that they would be willing to use to test our periodic ASDF updates? Alternatively, does anyone have a contact at LispWorks who might be willing to let me have an ASDF-only test version? What I would need is a copy of LW that would start up from the command-line, so that I could run our test scripts. I would be willing to sign a contract promising not to use it for other purposes. Such a copy would have to run on MacOS X and/or linux (I don't have access to Windows, nor am I interested in mastering it again). Thanks! Robert

2 1

[asdf-devel] Will you please test the latest ASDF with CMUCL
by Robert Goldman 08 Apr '15

08 Apr '15

On Mac OS X for me, it fails upgrade from 2.32 to the latest (3.0.2.2) using method require. Faré's testing instructions are: /usr/local/bin/cmucl -noinit then copy/paste: (load"test/script-support.lisp") (asdf-test::da) (test-upgrade 'load-asdf-lisp'load-asdf-lisp-clean "REQUIRE") I get an error as follows: Error in function KERNEL:CLASS-TYPEP: Class is currently invalid: #<KERNEL::STANDARD-CLASS ASDF/SYSTEM:SYSTEM {48589A35}> Please let me know any findings. I'd like to get this fixed (or disconfirmed) before we release 3.0.3. Best, r

2 2

← Newer
1
...
5
6
7
8
9
10
11
...
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