asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

new compiler error re: SET-DISPATCH-MACRO-CHARACTER
by Konstanski, Carlos 13 Oct '17

13 Oct '17

This is a bug report. I'm using puri as an example, but it's not a puri bug. With the latest version of asdf (3.3.0) puri no longer compiles. The following compiler error is thrown: SET-DISPATCH-MACRO-CHARACTER would modify the standard readtable. [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR] In: 0: (SET-DISPATCH-MACRO-CHARACTER #\# #\u #<FUNCTION PURI::SHARP-U> #<READTABLE {100002D6C3}>) The code: (defun sharp-u (stream chr arg) (declare (ignore chr arg)) (let ((arg (read stream nil nil t))) (if *read-suppress* nil (if* (stringp arg) then (parse-uri arg) else (internal-reader-error stream "#u takes a string or list argument: ~s" arg))))) (set-dispatch-macro-character #\# #\u #'puri::sharp-u) What puri is doing re: SET-DISPATCH-MACRO-CHARACTER is totally by the book. Why is this suddenly an error? Is there a workaround? Backing up to the next most recent release of asdf makes the problem go away: dev-lisp/asdf-3.2.1-r1:0/3.2.1-r1 dev-lisp/uiop-3.2.1:0 I tried to find the asdf changelog to see if this is a documented change. But the link is broken. https://common-lisp.net/project/asdf/Changelog uiop seems to be closely tied to asdf. Not sure which package is actually at fault. -- Carlos Konstanski

4 12

Re: [E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER
by Robert Goldman 12 Oct '17

12 Oct '17

On 12 Oct 2017, at 12:53, Konstanski, Carlos wrote: > All signs point at puri being the culprit. I am absolutely not > disagreeing > with that. I provided the offending code in the bug report myself. The > question is: what to do about it? The project is dead. The home page > is > gone. Here is what I will do: I'll see if I can get drakma to steer > clear > of it. They will undoubtedly be interested in not having their fine > code > dragged down by a dead library. > > The only other option is to fix puri. I don't even know how to begin > doing > that with a dead project. Where did Kevin Rosenberg disappear off to? > > 2017-10-12 11:45 GMT-06:00 Robert Goldman <rpgoldman(a)sift.info>: > >> >> >> Forwarded message: >> >>> From: 73budden . <budden73(a)gmail.com> >>> To: Robert Goldman <rpgoldman(a)sift.info> >>> Cc: Faré <fahree(a)gmail.com>, ASDF-devel >>> <asdf-devel(a)common-lisp.net> >>> Subject: Re: [E] new compiler error re: SET-DISPATCH-MACRO-CHARACTER >>> Date: Thu, 12 Oct 2017 20:09:44 +0300 >>> >>> Warning about modifying standard readtable is issued by SBCL (at >>> least >>> in my SBCL 1.3.18), please grep for the message in SBCL sources, and >>> it seem to be introduced in 1.0.24. I took a look at puri's >>> definition >>> (maybe old, in my local copy of quicklisp) and it looks like it >>> actually tries to modify standard readtable. But here it does not >>> happen when it is being loaded via my patched asdf 3.1.6 and my own >>> IDE with forked SLIME with many systems pre-loaded. I don't know why >>> and have no time to investigate further. Obviously, my insights >>> would >>> be of limited use because my environment is very different from that >>> of OP. >>> >>>> So we might be able to help you debug this >>> It'd be very nice to have instructions on how to trace what happens >>> while system is being built:that is, which files are compiled, which >>> are loaded and what is a readtable in the beginning of each load >>> operation. >>> >>> Running builds in old and new asdf versions and comparing logs it >>> would be relatively easy to figure out what is wrong. >>> >>> I guess that in OP's setup something had changed readtable before, >>> but >>> this does not happen anymore. And obviously many people would face >>> similar problems. >>> >>> This tracing tool should help a lot. >>> >>> I believe this tool should be supplied by asdf team. Even I begin to >>> be more positive towards efforts of ASDF team to clean up all the >>> mess >>> that was in ASDF initially, but obviously society is not quite happy >>> with breaking changes, so some small tool with a good manual would >>> make life easier. >>> >>> Printing readtable before loading, I think, requires just a line or >>> two. Dumping log of operations might be one (trace) call, so that's >>> trivial for the person who knows how ASDF is organized. Writing a >>> small two-paragraph addition to manual would relief a lot of pain >>> and >>> stress for all. >>> >>> WBR, Budden >>> >>> 2017-10-12 18:46 GMT+03:00, Robert Goldman <rpgoldman(a)sift.info>: >>>> I'm with Faré on this one. I don't see evidence that this change >>>> is >>>> because ASDF is doing something bad. I believe it's consistent >>>> with the >>>> hypothesis that there was some imperfectly-controlled aspect of >>>> building >>>> that is done differently now (e.g., files loaded in a different >>>> order >>>> where both orders are compatible with the constraints in the system >>>> definitions). >>>> >>>> This doesn't even look like an ASDF error to me -- it looks like an >>>> error that occurred while loading a system that ASDF has >>>> re-packaged. >>>> >>>> So we might be able to help you debug this, but without more >>>> evidence, >>>> there's no reason to believe that ASDF has done anything to you: it >>>> looks like the change in ASDF just reveals a pre-existing bug. >>>> >>>> >>>> >> > > > > -- > Carlos Konstanski > MTS IV Cslt > Verizon Cloud Platform > carlos.konstanski(a)verizonwireless.com > Cell: 15126218301 > Slack: vzw-vsi.slack.com username: @ckonstanski That may be, but it was unfair to get angry at the ASDF maintainers about this. This is just a pre-existing error that was *manifested* because of a change in ASDF. It's not our fault that this error appeared, it's not our fault that the puri library is no longer maintained, and we can't be expected to avoid releasing improved versions of ASDF because there exists buggy, unmaintained code in Quicklisp. An apology from you would be appropriate at this point.

3 2

WARNING: System definition file ...
by Stas Boukarev 12 Oct '17

12 Oct '17

3.3.0 issues a barrage of new warnings about something it has decided is uncouth now. I really have no wish to stare at these warnings coming from third party libraries, especially since they're never going to be fixed. Is the old behavior posing problems? Is the old behavior going away soon? This is why I don't update ASDF, I don't want to change anything in my code because of a new version.

2 5

Uploaded 3.3.0 Debian package
by Kambiz Darabi 10 Oct '17

10 Oct '17

Hello, just FYI. I uploaded the Debian package, now awaiting mentors' feedback. Cheers Kambiz ----- Forwarded Message ----- From: "Kambiz Darabi" <darabi(a)m-creations.net> To: "Submit Bugs" <submit(a)bugs.debian.org> Sent: Tuesday, 10 October, 2017 7:14:39 PM Subject: RFS: cl-asdf/3.3.0 - Another System Definition Facility Package: sponsorship-requests Severity: normal Dear mentors, I have packaged the new upstream release 3.3.0 of the Common Lisp ASDF software: Package name : cl-asdf Version : 2:3.3.0-1 Upstream Author : Robert P. Goldman <rpgoldman(a)sift.info> URL : https://common-lisp.net/project/asdf/ License : Expat Section : lisp The cl-asdf source package builds this binary package: cl-asdf - Another System Definition Facility The package appears to be lintian clean apart from a orig-tarball-missing-upstream-signature warning which I cannot fix due to building the package from git with gbp. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cl-asdf Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cl-asdf/cl-asdf_3.3.0-1.dsc Changes since the last upload: cl-asdf (2:3.3.0-1) unstable; urgency=medium Package changes: * Update Standards-Version to 4.1.1 New upstream milestone: * Build-plan: Extensively revised the build plan process so that :DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems change (which didn't work before). See our ELS demonstration about it: "Delivering Common Lisp Applications with ASDF 3.3" < https://github.com/fare/asdf2017 > * Internals: to support the above, many ASDF internals have changed. ASDF now has the notion of multiple build phases to a common build session (which generalizes the previous build cache). ASDF considers loading a .asd file as an operation DEFINE-OP, and tracks as dependencies files mentioned during in :LOAD-FILE-FORM statements, etc. Some code has moved to new files or among old files, and between packages. Actions are now uniformly represented as a CONS of an OPERATION and a COMPONENT, where in some cases previously only the class of the operation was preserved. Forcing is constrained to be uniform across all phases of a top level ASDF operation invocation. Fixed the protocol for resetting systems being (re)defined, allowing subclasses to define default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current maintainer of ECL, for which it was originally designed, decided that it could never be made to work properly, after all. * ASDF&UIOP: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP circularity, asdf.asd with no longer causes uiop.asd to be loaded. A standalone UIOP won't be loaded at all unless it's strictly more recent than ASDF. * Tests: tests for new capabilities and bugs. Test backtraces can be disabled. * Documentation: a number of improvements and clarifications. * Feature: a new feature :asdf3.3 * ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0, in a way that works on top of supported APIs (we still recommend you migrate to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME. * Deprecation: starting to emit STYLE-WARNINGs for deprecated functions. Will gradually escalate to true WARNINGs and then ERRORs. Thank you Kambiz Darabi -- m-creations gmbh Acker 2 55116 Mainz Germany

2 1

ASDF 3.3.0 is released!
by Robert Goldman 08 Oct '17

08 Oct '17

Today we release ASDF 3.3. The most substantial change is to the build planning process, which has been reformed by François-René Rideau so that DEFSYSTEM-DEPENDS-ON now behaves correctly. There are a number of other improvements, and we are indebted to Daniel Kochmanski, Rommel Martinez, and Chun Tian for contributions. Thanks again to Anton Vodonosov and Dave Cooper for support in testing, and new thanks to Martti Halminen, Jens K. Loewe, and Jason Miller. I would like to dedicate this ASDF release to the late Elias Pipping. On a technical level, Elias made great improvements in some of the most challenging ASDF internals, notably the RUN-PROGRAM component of UIOP, a place where implementations are not constrained by the language specification, diverge radically from each other, and are poorly documented. On a personal level, Elias was very supportive to me as ASDF maintainer, and while I was going through an illness. He did all these things despite being gravely ill with the cancer that eventually killed him. He will be greatly missed, Z'chrono L'vracha. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.3.0 at their earliest convenience. The improvements offered in this release will substantially improved the reliability and predictability of ASDF use. 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 Here is the changelog entry for 3.3: cl-asdf (2:3.3.0-1) unstable; urgency=low New milestone: * Build-plan: Extensively revised the build plan process so that :DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems change (which didn't work before). See our ELS demonstration about it: "Delivering Common Lisp Applications with ASDF 3.3" < https://github.com/fare/asdf2017 > * Internals: to support the above, many ASDF internals have changed. ASDF now has the notion of multiple build phases to a common build session (which generalizes the previous build cache). ASDF considers loading a .asd file as an operation DEFINE-OP, and tracks as dependencies files mentioned during in :LOAD-FILE-FORM statements, etc. Some code has moved to new files or among old files, and between packages. Actions are now uniformly represented as a CONS of an OPERATION and a COMPONENT, where in some cases previously only the class of the operation was preserved. Forcing is constrained to be uniform across all phases of a top level ASDF operation invocation. Fixed the protocol for resetting systems being (re)defined, allowing subclasses to define default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current maintainer of ECL, for which it was originally designed, decided that it could never be made to work properly, after all. * ASDF&UIOP: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP circularity, asdf.asd with no longer causes uiop.asd to be loaded. A standalone UIOP won't be loaded at all unless it's strictly more recent than ASDF. * Tests: tests for new capabilities and bugs. Test backtraces can be disabled. * Documentation: a number of improvements and clarifications. * Feature: a new feature :asdf3.3 * ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0, in a way that works on top of supported APIs (we still recommend you migrate to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME. * Deprecation: starting to emit STYLE-WARNINGs for deprecated functions. Will gradually escalate to true WARNINGs and then ERRORs. -- Robert P. Goldman <rpgoldman(a)sift.net> Sun, 20 August 2017 21:00:00 -0500 Best, R

2 1

Re: Testing Quicklisp with ASDF
by Faré 20 Sep '17

20 Sep '17

On Thu, May 25, 2017 at 6:45 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: > Finally results: > > No new failures on ASDF 3.1.7 and 3.2.1. > Yaaaay! > ASDF 3.3.0 has failures: > https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-65.html > Thanks. Interesting. A whole lot of failures seem to be related to using now-deprecated functions, that since 3.2.0 where causing ASDF to issue a STYLE-WARNING, but with 3.3.0 are causing it to issue a full WARNING. I'll send patches. Sent new patches: * metatilities - was already fixed, but quicklisp had the old darcs repo https://github.com/quicklisp/quicklisp-projects/issues/1323 * mgl-pax (affects micmac) https://github.com/melisgl/mgl-pax/pull/3 * weblocks https://github.com/skypher/weblocks/pull/53 * wuwei https://github.com/mtravers/wuwei/pull/16 * yaclml https://github.com/sharplispers/yaclml/pull/1 Still unmerged from my work last time(!), looks unmaintained, sent a ping: * bknr-web https://github.com/hanshuebner/bknr-web/pull/4 * check-it https://github.com/DalekBaldwin/check-it/pull/20 * cl-blapack https://github.com/blindglobe/cl-blapack/pull/8 * cxml-rng (patch sent to the author; I could create a github mirror if needed) * jwacs https://github.com/chumsley/jwacs/pull/2 * macrodynamics https://github.com/DalekBaldwin/macrodynamics/pull/1 * madeira-port (affects sb-cga, mathkit, linedit, glkit) https://github.com/nikodemus/madeira-port/pull/6 * org-sampler (affects nst) (patch sent to the author, who doesn't use git) * s-dot (patch sent to the author, who doesn't use git) Works for me: * cl-rrt * eco * inner-conditional * toms717 I refuse to touch this: * lisp-executable Considering these results, I think that the candidate ASDF 3.3.0 would usefully be committed next month. What do you think? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you don't like yourself, you *can't* like other people. — Robert Heinlein, "Time Enough For Love"

3 10

Lispworks improvements pushed
by Robert Goldman 09 Sep '17

09 Sep '17

The improvements that Chun Tian identified have been pushed into master on common-lisp.net I also pushed a test modification that disables testing ecl-make-image on MacOS. At the very least, it doesn't work on Macs with MacPorts (gets confused about which compiler to use with which libraries). This seems like not a problem for ASDF. I'd welcome any testing that people could do, and plan to release the new version by the end of next week. Best, r

3 6

Re: [LispM] ASDF 3.2.1 Anyone?
by Faré 01 Sep '17

01 Sep '17

Thanks. Then this entire method is better commented out on Genera by prepending #-genera before its source code. I just pushed a change to ASDF master on gitlab.common-lisp.net. Please try again. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http ://fare.tunes.org [A] Computer [programming] language is inherently a pun — [it] needs to be interpreted by both men & machines. — Henry Baker On Fri, Sep 1, 2017 at 5:23 AM, Steven Nunez <steven.nunez(a)illation.com.hk> wrote: > I see. By modifying the asdf code to read: > > > > ;;; Override previous methods (from 3.1.7 and earlier) and add proper > error checking. > > (defmethod initialize-instance :after ((o operation) &rest initargs &key > &allow-other-keys) > > (unless (null initargs) > > (parameter-error "~S does not accept initargs~%Operation > class:~S~%Initargs: ~S" 'operation (class-of 'operation) initargs)))) > > > > I get the following as output: > > > >

1 0

lispworks patch
by Chun Tian (binghe) 31 Aug '17

31 Aug '17

Hi, In latest ASDF, the function #’sys:pid-exit-status is used for LispWorks 6 and early versions, but I found this symbol doesn’t have a bounded function at all: CL-USER 1 > (describe 'sys:pid-exit-status) SYSTEM:PID-EXIT-STATUS is a SYMBOL NAME "PID-EXIT-STATUS" VALUE #<unbound value> FUNCTION #<unbound function> PLIST NIL PACKAGE #<The SYSTEM package, 6625/8192 internal, 1277/2048 external> In LispWorks 7.0, it’s even not an external symbol. On the other side, the function #’sys:pipe-exit-status exists since at least LispWorks 5.1.2, I think it should be used for all LispWorks versions, not just 7. The function #’sys:pipe-pid used in another ASDF function, exists since LispWorks 6.1, but ASDF only use it for LispWorks after 7.0. I don’t know if this could cause any potential problem in LispWorks 6.1, but I guess there’s no problem calling it also in 6.1. Basically I don’t know the purpose of these function calls, no actually tests were done. Use the patch with cautions … just calling non-exist functions are definitely wrong. Regards, Chun Tian

3 8

Turning off ecl make-image test on mac
by Robert Goldman 31 Aug '17

31 Aug '17

This has been failing for me for years. AFAICT ECL gets confused about which compiler to use and blows up. This gets error code 1: (RUN-PROGRAM "gcc" ("-o" "/Users/rpg/lisp/asdf/build/fasls/ecl-16.1.2-000af199-macosx-x64/asdf/test/ecl-make-image/hello-tmpLK0WIKQS.fas" "-L/usr/local/stow/ecl/lib/" "/private/var/folders/xq/ll1d80qs7hnbw3253yc1_x6m0000gn/T/eclinitfQslaT.o" "/Users/rpg/lisp/asdf/build/fasls/ecl-16.1.2-000af199-macosx-x64/asdf/test/ecl-make-image/hello.o" "-bundle" "-L/opt/local/lib" "-lecl" "-lgmp" "-lffi" "-lpthread" "-lm")) I suspect that what's going wrong is that gcc is /usr/bin/gcc -- Apple's clang -- and /opt/local/lib is the library for MacPorts gcc. But I can't swear to it. Anyway, this is not an ASDF bug, so I'm going to turn this test off on Mac, pending getting an "expected failure" feature in the test library. Cheers, r

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