asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Upgrade failures for asdf-3.1.7 and later
by James M. Lawrence 08 May '17

08 May '17

Starting with a bare lisp image (e.g --no-userinit --no-sysinit for SBCL), the following signals a "component not found" error: (load "asdf-2.26.lisp") ;;; or whatever system you want (push #p"~/quicklisp/dists/quicklisp/software/alexandria-20170227-git/" asdf:*central-registry*) (load "asdf-3.2.1.lisp") (asdf:load-system "alexandria") The first bad commit is https://github.com/fare/asdf/commit/3a9457a I hope this wasn't intentional? Ideally an old asdf version would never get loaded, but practically speaking it sometimes does (e.g. on LispWorks PE and CLISP). And if that happens, thereafter one is unable to load a system that requires asdf-3. The above case is a whittled-down version of a quickloading problem. Best, lmj

5 24

ASDF backward compatibility track record
by Faré 03 May '17

03 May '17

[Starting a new thread with different topic, as suggested by Robert.] On Wed, May 3, 2017 at 3:30 PM, Daniel Kochmański <daniel(a)turtleware.eu> wrote: > Is there any chance for specification of the "core ASDF protocol" - > subset guaranteed to not change every few years, so one may write today > systems which will be loadadable in the future? > As far as I can tell, the (API for the) core of ASDF has been remarkably stable. ASDF still supports many systems written for ASDF 1 in the early 2000s. While the manual is by no means great, especially as regards documenting the API, it does introduce the main concepts; and then every function and every class has a docstring, except for a few internals you're supposed never to use, that only have a comment. I made a pass over the entire source code last year specifically to ensure no function was left behind. (If you find a place I failed to document, please report a bug.) If there is any part of ASDF that you are struggling to understand, please discuss what it is, and I can try to document it better. As to writing systems that will be loadable in the future, I recently wrote a best practices document to help authors: https://gitlab.common-lisp.net/asdf/asdf/blob/master/doc/best_practices.md It can certainly be improved, but probably will be updated on a need basis, so please ask questions. That said, a lot of ugly workarounds were necessary in the bad old days of ASDF 1 (and to a lesser degree ASDF 2). Many of these workarounds have been deprecated, and many of them have ceased to work. Instead, they were replaced by simple portable alternatives that do not require poking at internals or relying on exponentially bad algorithms. A few features were removed (if-component-dep-fails, replaced by if-feature) or are still being removed (run-shell-command, being replaced by run-program). Now, there have been cases where someone did something that relied on undocumented behavior, and never contacted ASDF maintainers to either get it documented or replaced by a stable API. And then sometimes, that code breaks when I refactor and fix ASDF internals. In those cases, tough nuggies, such code *deserves* to lose. Yet, if it's in Quicklisp, I will find out the breakage, contact the authors, and submit a patch or a suggestion on what could be done instead. I've notably fixed code (such as asdf-system-connections) and .asd files for countless systems. The proximate issue that prompted this discussion is that I dropped the heroic support that ASDF had to properly upgrade from 2.x on some implementations that were less broken than others (including SBCL). That support was becoming increasingly costly to maintain and test for dwindling benefit, when all implementations have distributed ASDF 3 for years now, and ASDF 2.x has long been unsupported (except that Xach still distributes it in Quicklisp, which is a shame). These heroics included redefined gf sets, symbols to unintern, u-o-f-r-c methods, classes for which to break transient inheritance cycles during upgrade, special variables to filter, etc. (Some of it explained in Robert's and my 2010 paper.) It is hard enough to maintain that back to ASDF 3, but back to ASDF 2 after a while proved too much trouble. Most implementations already resorted to renaming away the entire ASDF package from ASDF 1 or 2, so as to let ASDF 3 create fresh packages. I recently made that "punting" the rule on all implementations, even SBCL. This was a great relief for me. If it breaks someone who somehow tries to upgrade from ASDF 2.26, I say they deserve to lose. As to what I guess may have triggered your question, one part of ASDF that has changed a lot is the bundle support (2012-2017), née asdf-ecl (2005). It was a pain to transform this cool implementation-specific hack into a portable infrastructure that truly supports all implementations, doesn't have quadratic or cubic performance degradation, and generally well with the ASDF build model rather than cheats and defeats it. Paradoxically, what started as an ECL-only extension has had plenty of issues on ECL up until the recent 3.2.1 which I hope solves them all (notably thanks to your input). The final interface while broadly similar to that of asdf-ecl, also has notable differences. Mostly, asdf-ecl did cut a lot of corners and made a few questionable choices. I believe most of these choices were probably well justified at the time of ASDF 1, when fighting to fix ASDF could have been deemed a pointless endeavor. But when making asdf/bundle out of asdf-ecl, I made some deep changes to fix the ASDF build model, at which point these asdf-ecl choices did not make sense anymore. From your point of view as ECL maintainer, you might see the result as breaking compatibility with the old asdf-ecl. From my point of view as ASDF developer, what I did was restoring compatibility with a newly fixed ASDF 3 (2013). Best regards, —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Il n'y a absolument rien à dire de ce qui échappe complètement aux mots. The utterly unspeakable is utterly irrelevant. — Faré

1 0

ASDF 3.2.1 released
by Faré 04 Apr '17

04 Apr '17

It is with great pleasure that we announce the release of ASDF 3.2.1. This new release brings increased stability to the 3.2 series with many fixes to small issues since ASDF 3.2.0 from last January. Note that we already have significant changes in the pipeline and are still intending to release a 3.3.0 "in a couple of months". We urge implementations that are currently bundling previous versions of ASDF to adopt 3.2.1 at their earliest convenience. Release 3.2.1 contains significant bug fixes on multiple platforms and implementations, and does not introduce any incompatibilities on public APIs. It builds on 3.2.0, that did contain cleanups and refactorings that broke some previously undocumented (and sometimes explicitly deprecated) internals. Those systems in Quicklisp that used or abused these internals have been fixed (notably including slime, asdf-system-connections, cffi, iolib, prove, cl-protobufs). Details on bugfixes can be found at https://launchpad.net/asdf and in the discussions in merged branches of https://gitlab.common-lisp.net/asdf/asdf Notable credits go to Robert P. Goldman for continued testing, François-René Rideau for general coding and fixing a few more bugs than he put in, to Dave Cooper for lending access to a Windows test server, and to Anton Vodonosov for repeatedly testing with cl-test-grid. Here is the changelog entry for 3.2.1, compared to 3.1.0: cl-asdf (2:3.2.1-1) unstable; urgency=low New release: * source-registry: resolve conflicts in a way compatible with Quicklisp. * Upgrade: make the upgrade logic more robust, especially on CCL. * Require-system: better normalize module vs system names on CMUCL MKCL SBCL. * Logical pathnames: fix bad-system-name warning behavior when using LPNs. * XDG: skip empty entries, for compatibility with Ubuntu * Bundles: numerous fixes for bundles especially so for ECL and MKCL. Don't try to combine .a's as it's not portable; only ever combine but .o's. Getting rid of the *load-system-operation*, now it's always load-op. * launch-program: more fixes, notably for ECL, clasp. * Deprecation: fix issues with the deprecation schedule of some functions. * Test and Release: fixes to the release process and to a few tests. * Documentation: a document describing best practices when using ASDF. -- Francois-Rene Rideau <fare(a)tunes.org> Sun, 03 Avril 2017 14:49:29 +0100

2 2

ASDF Best Practices
by Faré 03 Apr '17

03 Apr '17

I've started an ASDF Best Practices document as a response to all the ugly stuff I saw while debugging backward incompatibilities introduced by ASDF 3.3. It is currently in my plan branch: https://gitlab.common-lisp.net/asdf/asdf/blob/plan/doc/best_practices.md Early feedback welcome. —♯ƒ • 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>

3 3

Re: ASDF release candidates
by Faré 30 Mar '17

30 Mar '17

Oh, you mean you had this bug before 3.3 already? That's a useful data point! My mental model is indeed that if something depends explicitly on UIOP (or ASDF?), then something about the "always load ASDF first" mechanism may cause some bad behavior. But I haven't figured out what. -#f On Mar 30, 2017 03:19, "Attila Lendvai" <attila(a)lendvai.name> wrote: > > I still haven't inspected the spurious rebuilds of uiop that happened > > in some contexts. > > FWIW, i also see those rebuilds every now and then if i have explicit > dependency on :uiop or :asdf (which i've gotten rid of, so i don't see > this anymore). > > -- > • attila lendvai > • PGP: 963F 5D5F 45C7 DFCD 0A39 > -- > “Strong minds discuss ideas, average minds discuss events, weak minds > discuss people.” > — Socrates (c. 470–399 BC, tried and executed) >

2 4

ASDF release candidates
by Faré 30 Mar '17

30 Mar '17

Dear Anton, could you try what is currently in the "test" branch of ASDF as a release candidate for 3.2.1 ? And if you have time, could you try what is in the "plan" branch as a release candidate for 3.3.0 ? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Puritanism: The haunting fear that someone, somewhere, may be happy. ― H.L. Mencken

3 18

"strict-mode" ASDF
by Robert Goldman 17 Mar '17

17 Mar '17

What is the proper way to make ASDF fail on ANY warning (including STYLE-WARNINGs)? I thought I knew how to do this, but I'm having trouble making it work, possible because of the DEFERRED-WARNINGS. Thx, r

2 4

Custom options for dependent systems
by Alexey Veretennikov 14 Mar '17

14 Mar '17

Hi all, I have a following problem. I'm defining a system which depends on cl-charms. cl-charms in its turn contains some cff-groveller file. But this file could not be compiled unless I provide cc-flags to the include directory. So the question is how to define dependency on cl-charms in my system providing some argument which will be used while compliling/loading cl-charms, like the variable containing cc-flags? Br, /Alexey

2 1

Test results for "test" branch on Linux
by Robert Goldman 28 Feb '17

28 Feb '17

On Linux I get test failures for run-program as follows: allegro8_64 failed test-program.script allegro8_64_s failed test-program.script allegro_64 failed test-program.script allegro_64_s failed test-program.script allegromodern8_64 failed test-program.script allegromodern8_64_s failed test-program.script allegromodern_64 failed test-program.script allegromodern_64_s failed test-program.script ccl failed test-program.script clisp failed test-program.script cmucl failed test-program.script ecl failed test-program.script lispworks failed test-program.script mkcl failed test-program.script sbcl failed test-program.script These all seem to be due to test code passing :CONSOLE T to INVOKE-LISP Cheers, R

2 1

ASDF 3.2.0 is released
by Faré 11 Jan '17

11 Jan '17

It is with great pleasure that we announce the release of ASDF 3.2.0, a new milestone in the development of ASDF. This change in minor version number advertises how much ASDF has evolved since we released 3.1 in 2014, and at the same time how stable the API has been since we release 3.0 in 2013. Note that we already have significant changes in the pipeline and are intending to release a 3.3.0 in a couple of months. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.2.0 at their earliest convenience. Release 3.2.0 contains significant bug fixes on multiple platforms and implementations, and does not introduce any incompatibilities on public APIs. It does however introducing cleanups and refactorings that break some undocumented (and sometimes explicitly deprecated) internals. Those systems in Quicklisp that abused these internals have been fixed (notably including slime, asdf-system-connections, cffi, iolib, prove, cl-protobufs). Details on bugfixes can be found at https://launchpad.net/asdf and in the discussions in merged branches of https://gitlab.common-lisp.net/asdf/asdf Notable credits go to Robert Goldman for his relentless testing and push for quality, to Elias Pipping for his contribution of the new launch-program infrastructure and upping the standards for code, to François-René Rideau for general coding and fixing a few more bugs than he put in, to Dave Cooper for lending access to a Windows test server, and to Anton Vodonosov for repeatedly testing with cl-test-grid. Here is the changelog entry for 3.2.0, compared to 3.1.7: New milestone: * launch-program: new UIOP API for asynchronous subprocesses, now available on: abcl allegro clozure cmucl ecl (and lispworks os-unix) mkcl sbcl scl. Big thanks to Elias Pipping for this significant contribution! * parameter-error, not-implemented-error: new UIOP functions to better signal abuse of parameters in function calls, or lack of function implementation. * with-deprecation macro in UIOP signals style-warnings, then warnings, then errors when deprecated functions are used. This macro is now used for all deprecated functions in ASDF. * require-system, component-loaded-p fixed to not reload .asd files, and to work in presence of preloaded-systems, that are now eagerly loaded. * registered-system added as an abstraction for internals and extensions. * make-operation is now the only supported way to create an operation; calling make-instance directly will raise an error. Update your software! * Removal of several obsolete backward-compatible internals: if-component-dep-fails, operation-forced. Update SLIME! * Robustness and portability fixes all around uiop, notably dealing with directory access, bundles on ECL and MKCL or with cffi-toolchain, dealing with a fatal-condition, surviving use of "logical" pathnames, etc. * Tests improved and extensively run on Linux, macOS and, notably, Windows, with recent versions of all the maintained CL implementations. * Internals of ASDF systematically cleaned up and documented. * Build, test, release infrastructure improved, both classic and asdf-tools. * Documentation updated. -- Francois-Rene Rideau <fare(a)tunes.org> Sun, 08 Jan 2017 20:45:29 -0500

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel