asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

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

make-build
by Faré 21 Jul '17

21 Jul '17

Dear Daniel, if you're willing to fork ASDF over make-build, would putting a make-build compatibility function back in ASDF make you adopt the upstream version again? I have an implementation for it at the end of https://gitlab.common-lisp.net/asdf/asdf/merge_requests/34 but I'd need you to provide some more test case (a simple one exists somewhere in some old version in git). There were many fixes in ASDF 3.2 and 3.3, including ECL-specific fixes, compared to the 3.1.7 from which you forked, and forking is just more work for both you and us. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Social peace will come when the socialists will love the poor more than they hate the rich. — Not Golda Meir

2 1

source-registry configuration
by Greg Bennett 20 Jul '17

20 Jul '17

Running under Linux Mint 18.1 64 bit, and either ccl or sbcl Apologies, I'm afraid I have made a mess of configuring the path to some .asd files. I believe that items 3,4,6,7,8 of Section 8.1 Configurations do not exist. I believe I have used item 5 as in Section 4.1 Configuring ASDF to find your systems. In ./config/common-lisp/source-registry.conf.d I once created the file gb-lisp.conf containing the single line (:tree "/home/gwbennett/asdf-tests") <- no trailing / instead of (:tree "/home/gwbennett/asdf-tests/") <- trailing / I have since replaced that file with source.conf holding just the line (:tree "/home/gwbennett/asdf-tests/") In the asdf-tests directory there is a file gb-a.asd and associated lisp files When I try (asdf:load-system "gb-a") I get (under ccl64 Version 1.11-r16812M) > Error: Is a directory : #P"/home/gwbennett/asdf-tests" > While executing: CCL::MAKE-FILE-STREAM, in process listener(1). Under sbcl 1.3.18 I get an analogous message, always pointing to the same pathname. If I remove the .conf file completely, restart either lisp, retry the load-system, the error persists. Some how I seem to have managed to get the incorrect specification squirreled away in asdf's memory in a way which survives not just restarting either lisp, but restarting linux too. What in the world have I managed to do ? More usefully, how do I undo it ? Thanks for advice and assistance. Cheers Greg Bennett

3 2

read-depend branch is ready for another review...
by Robert Goldman 17 Jul '17

17 Jul '17

Tests now passing on all implementations, and there's been substantial clean-up. Likely the first two commits on this branch should be merged with the plan branch directly, since they don't have anything to do with read dependencies per se. Then we could move on to reviewing (and then squash-merging) read-depends. Cheers, r

2 9

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel