asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

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

MR 72
by Robert Goldman 02 Aug '17

02 Aug '17

[I think I'm not using gitlab effectively, because your commits and some merge requests aren't getting pushed at me...] I didn't participate in this discussion, and reading over it, I don't really understand what this MR is trying to accomplish. Can you sum it up? Should we merge it before this release? thanks, r

2 1

CLISP CLOS style warnings
by Sam Steingold 01 Aug '17

01 Aug '17

Hi, I am writing in regards to the CLISP CLOS style warnings reported in https://sourceforge.net/p/clisp/mailman/message/35946823/ Specifically: --8<---------------cut here---------------start------------->8--- WARNING: Adding method #<STANDARD-METHOD (#<STANDARD-CLASS TEST-OP> (EQL #<SYSTEM "alexandria">))> to an already called generic function #<STANDARD-GENERIC-FUNCTION OPERATION-DONE-P> WARNING: Adding method #<STANDARD-METHOD (#<STANDARD-CLASS TEST-OP> (EQL #<SYSTEM "alexandria">))> to an already called generic function #<STANDARD-GENERIC-FUNCTION PERFORM> WARNING: Adding method #<STANDARD-METHOD (#<STANDARD-CLASS TEST-OP> (EQL #<SYSTEM "babel">))> to an already called generic function #<STANDARD-GENERIC-FUNCTION OPERATION-DONE-P> --8<---------------cut here---------------end--------------->8--- The rationale for these warnings is explained in http://clisp.org/impnotes/mop-clisp.html#mop-clisp-gf-already-called-warning However, when the normal use case for a generic function is being extended by its users (e.g., `print-object`), this warning is inappropriate. ASDF user macros, apparently, expand to method definitions, thus they are similar to `print-object`. To mark a generic function as user-extendable, one can now use a declaration: --8<---------------cut here---------------start------------->8--- (defgeneric perform (...) (declare #+clisp (dynamically-modifiable)) ...) (defgeneric operation-done-p (...) (declare #+clisp (dynamically-modifiable)) ...) --8<---------------cut here---------------end--------------->8--- The declaration is now in `hg tip` (but has not been released yet). Thank you! -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://honestreporting.com http://jij.org https://jihadwatch.org http://mideasttruth.com Me, sarcastic?! Yeah, right...

3 6

Testing for ASDF 3.3.0
by Faré 26 Jul '17

26 Jul '17

Dear Anton, can you test the candidate asdf 3.3.0 in the "plan" with cl-test-grid, and compare with 3.1.7 and/or 3.2.1 ? As always, results on a recent sbcl are the more useful ones to get first. (And as usual, there is a dozen of mismaintained systems in quicklisp that still hasn't merged known fixes after several months.) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To play a wrong note is insignificant; to play without passion is inexcusable. — misattributed to Beethoven

2 2

MKCL fails when non-erroneous condition is signaled
by Faré 25 Jul '17

25 Jul '17

Dear Jean-Claude, ASDF 3.3 (the "plan" branch) is failing miserably on MKCL, because it signals a non-serious condition (that is only handled in some contexts) as a way to detect out-of-date .asd files. All other CL implementations know to ignore such conditions when they are not handled. But instead MKCL borks with error messages such as: Unhandled condition signaled during command line arguments processing: system test-asdf is out of date. I believe it's a bug in MKCL, maybe specifically in command line processing. Can you fix it? Should I add some backward compatibility for older versions of MKCL, or is it superfluous? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Wherever you go, there you are!" Dual: "Wherever you are, thence you go." Beats "I'll start exercising as soon as I'm into shape."

4 13

Issues upgrading ASDF on CMUCL
by Faré 24 Jul '17

24 Jul '17

One essential feature of ASDF is being able to upgrade from a previously loaded ASDF. This feature broke recently on CMUCL. When trying to upgrade CMUCL's provided ASDF to the latest, some weird CLOS errors happen. >From 3.1.7 (using 21d), class MODULE isn't subtypep of its superclass COMPONENT. >From 3.2.1 (using the april 2017 snapshot), I fail to set a newly defined slot inside INITIALIZE-INSTANCE: Error in function "DEFMETHOD SLOT-MISSING (T T T T)": When attempting to set the slot's value to NIL (setf of slot-value), the slot ASDF/FORCING:FORCED is missing from the object #<ASDF/PLAN:SEQUENTIAL-PLAN {5A38C46D}>. There's probably something wrong in some method caching mechanism, that prevents invalidation in presence of redefinition, or that breaks the class graph, etc. I know that ASDF upgrade stresses the CLOS implementation a lot, but CMUCL is unique in being stumped by ASDF, and has been for years. I'm not going to spend too many cycles figuring out what's happening, or going to block an ASDF release. My understanding is that the policy with respect to CMUCL is that CMUCL is always very prompt to update its ASDF, and that live ASDF upgrades are therefore not as essential as it is on other implementations that linger for years without an update. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To distinguish the real from the unreal, one must experience both. — Saul Gorn On Sun, Apr 9, 2017 at 1:11 AM, Raymond Toy <toy.raymond(a)gmail.com> wrote: > While looking at the logs, I came across this that occurred on Jan 18, 20 > years ago: > > Author: ram <ram> > Date: Sat Jan 18 14:32:04 1997 +0000 > > Werkowskis source kit 1.03.7 > > > I guess this is the birth of cmucl in the new era. > > Seems so long ago, and yet not really that long ago either. > > -- > Ray > _______________________________________________ > cmucl-imp mailing list > cmucl-imp(a)cmucl.cons.org > https://lists.zs64.net/mailman/listinfo/cmucl-imp

1 0

weirdness with compile-op and retry restart
by Attila Lendvai 21 Jul '17

21 Jul '17

dear devs, i have a system with a file that has a compilation error. i try to load it: (asdf:load-system :hu.dwim.web-server.application.test) it leads to an error with the following restart (notice its unusual wording, and that it's about the entire system, not just that one source file): 6: RETRY Retry completing compilation for #<HU.DWIM.TEST-SYSTEM "hu.dwim.web-server.application.test">. the rest FTR: 5: ACCEPT Continue, treating completing compilation for #<HU.DWIM.TEST-SYSTEM "hu.dwim.web-server.application.test"> as having been successful. 4: RETRY Retry ASDF operation. 3: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. if i touch the file and select the restart, then cl:compile-file doesn't get called and no compilation seems to happen. there used to be a restart to recompile the single source file that has failed. i'm on ASDF 3.2.1 and the very latest SBCL (i'm testing it for the current freeze) note: these systems have some customizations from hu.dwim.asdf, but not much changed there recently. is this something obvious that i'm failing to see, or should i dig deeper? what else would help? it's not a show-stopper for me, so feel free to ignore this. i'm writing this up more as offering help than asking for help. thanks for your time, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Understand and abide by the following self-evident principle, and you will be an anarchist: If there is something that would be wrong for you to do yourself, then you shouldn't ask anyone else to do it either.” — Larken Rose (1968–)

2 3

Testing new ASDF
by Robert Goldman 21 Jul '17

21 Jul '17

Our new version of ASDF has 5 failures for me on Linux, testing against the master branch. Is that what I should be testing, or should I be testing against the dev branch? The tests which are failing are: ecl-make-image.script ecl-prebuilt-systems.script test-bundle.script test-program.script test-require.script Thanks, r

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel