- asdf-devel - mailman3.common-lisp.net

[asdf-devel] defsystem :version (:read-file-line ...) fails because :at key isn't recognized
by Vsevolod Dyomkin 08 Apr '15

08 Apr '15

Hi, Basically, the problem is described in the message header. Whereas :read-file-form option is used by ASDF itself, :read-file-line isn't used and wasn't tested. Attached is a patch with relevant test cases and fixes. I would also suggest refactoring the code, because the code paths for :read-file-form and :read-file-line are almost identical, but are implemented in separate functions. Best regards, Vsevolod Dyomkin +38-096-111-41-56 skype, twitter: vseloved

4 5

[asdf-devel] quick-build support for ASDF
by Faré 08 Apr '15

08 Apr '15

I implemented support for quick-build in ASDF. Please review before it gets merged into the master branch. https://bugs.launchpad.net/asdf/+bug/1230368 http://common-lisp.net/gitweb?p=projects/asdf/asdf.git;a=shortlog;h=refs/he… Note that until an ASDF recent enough to include this support is widely available, you may have to use asdf-package-system, which is basically the same thing packaged as an add-on: git://common-lisp.net/projects/asdf/asdf-package-system.git http://common-lisp.net/gitweb?p=projects/asdf/asdf-package-system.git For backward compatibility with older versions of ASDF, I recommend the following: (defsystem top-of-my-quick-build-style-hierarchy :class package-system :defsystem-depends-on #.(unless (find-class 'package-system nil) '(:asdf-package-system))) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It's better to know nothing that to know what ain't so. — Josh Billings

1 0

[asdf-devel] ASDF 3.0.0
by Faré 08 Apr '15

08 Apr '15

Dear Lisp hackers, I'm proud to announce the release of release ASDF 3.0.0. Please test it and include it in your Common Lisp implementation or distribution. 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.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 backward 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. Fix regression of program-op on ECL, by implicitly linking in UIOP or ASDF. * 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 with various tweaks. * Build cleanup so make and concatenate-source-op create the same asdf.lisp —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The sunlights differ, but there is only one darkness. — Ursula K. LeGuin, "The Dispossessed" There are 40 kinds of lunacy, but only one kind of common sense. — African proverb

2 2

[asdf-devel] Re: Help with cl-launch
by Luís Oliveira 08 Apr '15

08 Apr '15

[Cc-ing asdf-devel] On Tue, Jan 14, 2014 at 1:14 AM, Faré <fahree(a)gmail.com> wrote: > Wow. If asdf 3.0.3 loads 2.14, that's a notable bug indeed. I have a faint > how that the bug is somehow in something other than asdf itself. Can you > confirm and give steps to reproduce? Ubuntu 13.04 apt-get installed cl-asdf (2:2.24-1) Grabbed the 2014-01 CMUCL snapshot luis@fusubu:~$ cmucl -noinit CMU Common Lisp snapshot-2014-01 (20E Unicode), running on fusubu With core: /home/luis/cmucl/lib/cmucl/lib/lisp-sse2.core Dumped on: Sat, 2014-01-04 19:49:03Z on lorien2 See <http://www.cmucl.org/> for support information. Loaded subsystems: Unicode 1.29 with Unicode version 6.2.0 Python 1.1, target Intel x86/sse2 CLOS based on Gerd's PCL 2010/03/19 15:19:03 * (require :asdf) ; Loading #P"/home/luis/cmucl/lib/cmucl/lib/contrib/asdf/asdf.sse2f". ("ASDF") * (asdf:load-system 'whatever) Warning: You are using ASDF version 3.0.3 (probably from (require "asdf") or loaded by quicklisp) and have an older version of ASDF (and older than 2.27 at that) registered at #P"/usr/share/common-lisp/source/cl-asdf/asdf.asd". Having an ASDF installed and registered is the normal way of configuring ASDF to upgrade itself, and having an old version registered is a configuration error. ASDF will ignore this configured system rather than downgrade itself. In the future, you may want to either: (a) upgrade this configured ASDF to a newer version, (b) install a newer ASDF and register it in front of the former in your configuration, or (c) uninstall or unregister this and any other old version of ASDF from your configuration. Note that the older ASDF might be registered implicitly through configuration inherited from your system installation, in which case you might have to specify :ignore-inherited-configuration in your in your ~/.config/common-lisp/source-registry.conf or other source-registry configuration file, environment variable or lisp parameter. Indeed, a likely offender is an obsolete version of the cl-asdf debian or ubuntu package, that you might want to upgrade (if a recent enough version is available) or else remove altogether (since most implementations ship with a recent asdf); if you lack the system administration rights to upgrade or remove this package, then you might indeed want to either install and register a more recent version, or use :ignore-inherited-configuration to avoid registering the old one. Please consult ASDF documentation and/or experts. ; Loading #P"/usr/share/common-lisp/source/cl-asdf/asdf.asd". ; Loading #P"/usr/share/common-lisp/source/cl-asdf/asdf.lisp". Exporting these symbols from the ASDF package: (FIND-SYMBOL*) results in name conflicts with these packages: ASDF/USER [Condition of type LISP::SIMPLE-PACKAGE-ERROR] Restarts: 0: [UNINTERN-CONFLICTING-SYMBOLS] Unintern conflicting symbols. 1: [SKIP-EXPORTING-THESE-SYMBOLS] Skip exporting conflicting symbols. 2: [CONTINUE ] Return NIL from load of #P"/usr/share/common-lisp/source/cl-asdf/asdf.lisp". 3: [RETRY ] Retry compiling #<CL-SOURCE-FILE "asdf" "asdf">. 4: [ACCEPT ] Continue, treating compiling #<CL-SOURCE-FILE "asdf" "asdf"> as having been successful. 5: [ABORT ] Return to Top-Level. Debug (type H for help) (EXPORT FIND-SYMBOL* #<The ASDF package, 39/64 internal, 25/194 external>) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/package.lisp. 0] This seems to be a bug with ASDF 3.0.3 as I can reproduce the same issue with SBCL 1.1.14 if I load ASDF 3.0.3 but /not/ when I use the bundled ASDF 3.0.2. HTH, -- Luís Oliveira http://kerno.org/~luis/

2 1

[asdf-devel] Buggy release
by Stelian Ionescu 08 Apr '15

08 Apr '15

The last commit causes this: ; caught ERROR: ; READ error during COMPILE-FILE: ; ; The function ASDF::FIND-SYMBOL* is undefined. ; ; (in form starting at line: 3452, column: 53, file-position: 150201) -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

4 10

Re: [asdf-devel] has ":depends-on ((:version ...))" semantics changed?
by Anton Vodonosov 08 Apr '15

08 Apr '15

18.11.2013, 08:02, "Robert P. Goldman" <rpgoldman(a)sift.info>: > Anton Vodonosov wrote: > >> 18.11.2013, 07:50, "Robert P. Goldman" <rpgoldman(a)sift.info>: >>> Are you saying now that version 1.0.0 of Closer-MOP will satisfy the >>> requirement of 0.55, and that Anton should *not* be having this build >>> failure. >> Robert, build failures happen on older ASDF, and not happen on newer ASDF. > > Well this certainly was not an ASDF change I was consulted about or approved of. It has happened right before ASDF maintenance was transferred to you, maybe even during the transition. See the mailing thread mentioned by Xach: http://thread.gmane.org/gmane.lisp.asdf.devel/3062/focus=3066 >From this thread I understand that ASDF uses the same version-satisfies for determining compatibility between ASDF versions, and for determining if an ASDF system satisfies the :depends-on ((:version ...)).

1 2

[asdf-devel] :DBG
by Faré 08 Apr '15

08 Apr '15

In ASDF 3.1.0.14, I introduced a macro :DBG (in uiop/utility.lisp). Yes, it's in the keyword package. Why? Because it's the one and only macro I want to be accessible from everywhere without a prefix, yet without modifying existing defpackage forms to make it accessible — because it's only used temporarily for debugging. :DBG is a macro for print-debugging. The syntax is (:DBG tag forms... last-form) The semantics is that if tag is true, print the tag, then for each form, write its source and its values; return the values of the last form. If tag is false, just evaluate the last form and return its values. (Tag is typically a constant keyword or string, identifying the point where values are printed.) The expansion is rather space and time efficient, as far as the semantics permit. I find :DBG soooo useful for print-debugging. I've seen tens of variants of it, but every time with something not quite right in the syntax, semantics or implementation. I just wanted one variant that got everything right, and make it ubiquitous. Because when you need it, you need it now, and there's no time to modify things to load an additional library. And when you're done, you want minimal cleanup, too: just delete the form, except maybe keep the last subform. Previously, I was using (uiop:uiop-debug) from uiop/utility which allows you to load a magic file of your choice that defines a debug mode. The default one I provided was mine, which define :DBG as DBG in your current package (thereby avoiding symbol import issues). But that still adds a new definition everytime and an extra line or form to cleanup. I was recently convinced that using the keyword package instead makes perfect sense: on the one hand, that's using a shared namespace that it is polite to not pollute, but on the other hand, such a temporary print-debugging macro the only use case I imagine of otherwise wanting something to be immediately accessible without package prefixing yet without modifying the package definition form. It's still time to remove that macro before the next release, but I believe it's the right thing to include it, and maybe some of you will agree with me and start using it, if not from the yet unrelease ASDF 3.1.1, perhaps from a copy in your .sbclrc. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The common argument that crime is caused by poverty is a kind of slander on the poor. — H. L. Mencken

12 19

All tests passing for ASDF 3.0.2.32 on my installed platforms (was: Re: [asdf-devel] Fwd: ASDF testing for LWW)
by Dave Cooper 08 Apr '15

08 Apr '15

On Sun, Oct 20, 2013 at 9:37 PM, Faré <fahree(a)gmail.com> wrote: > > So... is there any obstacle left to release? > > All 48 ASDF test-suite tests are passing for me on ASDF 3.0.2.32 on all platforms which i'm currently testing, which consist of: Linux: allegro allegro8 allegromodern allegromodern8 ccl sbcl Mac: ccl lispworks sbcl Windows: allegro allegro8 allegromodern allegromodern8 ccl-1.10-dev sbcl I think this is also true now even when the build/ directory is not cleared before every test run (but still with separate test directories for each OS). I'll confirm this and report by tomorrow morning if this turns out not to be true. -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype)

1 1

[asdf-devel] keeping versioning information externally
by Anton Vodonosov 08 Apr '15

08 Apr '15

I want to highlight another tool to deal with versioning. 19.11.2013, 23:41, "Robert P. Goldman" <rpgoldman(a)sift.info>: > two versions of the same library on the same machine is quite feasible, > and indeed I do this myself, every day. I have different > source trees for different projects, and with each source tree > is associated a different ASDF configuration. > > This is not a futuristic "wouldn't it be nice if..." situation, either: > it's a simple requirement of my daily work environment. E.g., I have > projects that rely on different versions of FiveAM (they are hosted > differently, so it's not just a matter of demanding that everyone > upgrade -- some I run, some I don't). I did that too. I had a config file vermap.lisp which puts directories of the libary versions I need to ASDF central registry. So, when we say :depends-on (#:fiveam) we have an external configuration which specifies then exact version of fiveam to be loaded. The external configuration is a flat mapping: (:name :chunga :ver "0.4.3") (:name :cl-base64 :ver "3.3.2") (:name :cl-cont :ver "0.3.4") (:name :cl-containers :ver "0.9.10") (:name :cl-fad :ver "0.6.2") (:name :cl-html-parse :ver "1.0") I called such a mapping a "vermap" or a "libworld". I used different vermaps for different applications. And Quicklisp uses this approach. Quicklisp dist version is a collection of releases, it specifies what exact release of fiveam is used by asdf:load-op "fiveam". This approach is different from the case where each libary author specifies constrains for the library dependencies, and the library loader tries to find some versions which satisfy the constrains. With the exact mapping we have a reproducible configuration. For example, my application startup script does (require-quicklisp :version "2013-01-28"), so that when the application is deployed on server, it works with exactly same library versions as it was tested on the development machine. Developers can collaborate to assemble library version and share vermaps which are consistent and tested to work well together. They can be shared inside a company, or globally, like Quicklisp does. Best regards, - Anton

3 2

[asdf-devel] Make the CL syntax predictable
by Faré 08 Apr '15

08 Apr '15

Dear Anton, can you (1) run cl-test-grid on all implementations with 3.1.0.94, our release candidate? can you run the cl-test-grid on at least SBCL with the latest ASDF and the attached patch? In writing my article "ASDF3, or Why Lisp is Now an Acceptable Scripting Language", one of the limitations I list is the mess of uncontrollable syntax. This would fix it... but might break dirty files that side-effect the current syntax without first creating and using a new readtable. Breaking these files is actually desired, but we need to check how large is the issue before we do it (if we do). I figure that, like any other potentially disruptive change, it is best done just before a release that defines a new features, in this case, #+asdf3.1 Of course, I won't commit any such thing to master without maintainer approval. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Ontogeny recapitulates phylogeny. — Ernst Haeckel

13 89