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

3.2rc on MKCL (Was: ASDF 3.1.7.43 is 3.2 release candidate)
by Jean-Claude Beaudoin 19 Dec '16

19 Dec '16

On Thu, Dec 15, 2016 at 7:51 PM, Faré <fahree(a)gmail.com> wrote: > > "Our greatest release ever!" > > :-) I just tried ASDF master head on my latest MKCL with this small (attached) edit and I got this as result: -#--------------------------------------- Using ../../../bin/mkcl Ran 63 tests: 63 passing and 0 failing all tests apparently successful -#--------------------------------------- This is on Ubuntu Linux x86_64. So I guess it looks like good to go on that configuration. I will test on Win32 and Win64 soon. Cheers, JCB

3 9

Loading a system
by Greg Bennett 16 Dec '16

16 Dec '16

3 2

Pending Merge Requests
by Robert Goldman 12 Dec '16

12 Dec '16

I would very much like to get 3.2.0 released, but I am starting to feel like we have a Zeno process here. Merge requests are appearing as fast as they are merged. Currently pending for 3.2.0: !59 Link objects only !60 Fix bad-system-name for "logical" .asd pathnames !61 Remove *load-system-operation* Which, if any, of these must be in our 3.2.0 release candidate? I would like to freeze a release candidate, marking it as version 3.2.0, for people to play with for at least a week, before we push it into the world. I'd very much like to do this this week, since the holidays are coming up when people's minds will turn to other things than testing new ASDF versions. I can pretty much guarantee that if the answer to the above is "we need all three," we are talking a 2017 release, instead of finishing this year, because of limitations on my available testing cycles in the remainder of 2016. Thanks, r

3 5

Re: Fwd: Re: Is the :PERFORM stanza still valid?
by Robert Goldman 08 Dec '16

08 Dec '16

On 12/8/16 Dec 8 -2:40 PM, Faré wrote: > ./make-asdf.sh extract "2.26 2.27 3.0.1 3.1.2" > grep 'def.*make-operation' build/asdf-version*.lisp > > It was defined in asdf 2.27, i.e. the first asdf 3 pre-release. Thanks! So no one has to worry about backwards-compatibility -- any ASDF in the wild will have MAKE-OPERATION in it. Best, r > > -#f > > > On Dec 8, 2016 13:54, "Robert Goldman" <rpgoldman(a)sift.net > <mailto:rpgoldman@sift.net>> wrote: > > Fare -- > > Is there an easy way to find out when ASDF:MAKE-OPERATION was added to > the API, so that people can provide backward-compatibility? > > I suppose it might make sense to do some kind of backward search over > the released versions, and for each one, extract a list of exported > symbols from ASDF and UIOP. > > I could probably write a script to do this, but that seems like > something that I am unlikely to get around to. > > R > > > ---------- Forwarded message ---------- > From: Mark Evenson <evenson(a)panix.com <mailto:evenson@panix.com>> > To: asdf-devel(a)common-lisp.net <mailto:asdf-devel@common-lisp.net> > Cc: > Date: Thu, 8 Dec 2016 19:40:37 +0100 > Subject: Re: Is the :PERFORM stanza still valid? > > > On 2016/12/8 18:28, Robert Goldman wrote: > > Hi, Mark -- > > > > The issue is in PROVE-ASDF. Replacing line 50 of asdf.lisp > > > > (asdf:perform (make-instance 'asdf:load-source-op) c) > > > > with > > > > (asdf:perform (asdf:make-operation 'asdf:load-source-op) c) > > > > should solve the problem. > > > > LMK if that doesn't fix the problem. > > Thanks! That works. > > Created an [upstream pull request][34]. > > [34]: https://github.com/fukamachi/prove/pull/34 > <https://github.com/fukamachi/prove/pull/34> > > -- > "A screaming comes across the sky. It has happened before, but there > is nothing to compare to it now." > >

1 0

Is the :PERFORM stanza still valid?
by Mark Evenson 08 Dec '16

08 Dec '16

If the perform stanza still the way to add operable test systems in ASDF? It would be nice to update the manual if this is not the case. For an ASDF test operation for a test system defined as: (asdf:defsystem plato-test :depends-on (:plato :prove) :components ((:module "t" :components ((:test-file "plato")))) :description "Test system for plato" :defsystem-depends-on (:prove-asdf) :perform (test-op (op c) (uiop:symbol-call :prove-asdf 'run-test-system c) (asdf:clear-system c))) I am getting the error: OPERATION instances must only be created through MAKE-OPERATION. [Condition of type ASDF/FIND-SYSTEM:FORMATTED-SYSTEM-DEFINITION-ERROR] Restarts: 0: [SKIP-TEST-FILE] Skip this test file. 1: [SKIP-ALL-TEST-FILES] Give up all test files. 2: [RETRY] Retry #<ASDF/LISP-ACTION:TEST-OP > on #<ASDF/SYSTEM:SYSTEM "plato-test">. 3: [ACCEPT] Continue, treating #<ASDF/LISP-ACTION:TEST-OP > on #<ASDF/SYSTEM:SYSTEM "plato-test"> as having been successful. 4: [RETRY] Retry ASDF operation. 5: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. --more-- Backtrace: 0: (#<FUNCTION {2EA005A1}> #<ASDF/FIND-SYSTEM:FORMATTED-SYSTEM-DEFINITION-ERROR {53DCB225}> #<FUNCTION {2EA005A1}>) 1: (APPLY #<FUNCTION {2EA005A1}> (#<ASDF/FIND-SYSTEM:FORMATTED-SYSTEM-DEFINITION-ERROR {53DCB225}> #<FUNCTION {2EA005A1}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ASDF/FIND-SYSTEM:FORMATTED-SYSTEM-DEFINITION-ERROR {53DCB225}> #<FUNCTION {2EA005A1}>) 3: (INVOKE-DEBUGGER #<ASDF/FIND-SYSTEM:FORMATTED-SYSTEM-DEFINITION-ERROR {53DCB225}>) 4: (ERROR ASDF/FIND-SYSTEM:FORMATTED-SYSTEM-DEFINITION-ERROR :FORMAT-CONTROL "OPERATION instances must only be created through MAKE-OPERATION." :FORMAT-ARGUMENTS NIL) 5: (ASDF/FIND-SYSTEM:SYSDEF-ERROR "OPERATION instances must only be created through MAKE-OPERATION.") 6: (ASDF/OPERATION::CHECK-OPERATION-CONSTRUCTOR) 7: (#<FUNCTION {4EB834F7}> #<ASDF/LISP-ACTION:LOAD-SOURCE-OP {1F9CF5CF}>) 8: (APPLY #<FUNCTION {4EB834F7}> (#<ASDF/LISP-ACTION:LOAD-SOURCE-OP {1F9CF5CF}>)) 9: (#<STANDARD-GENERIC-FUNCTION {4F6E7A42}> #<ASDF/LISP-ACTION:LOAD-SOURCE-OP {1F9CF5CF}>) 10: (APPLY #<STANDARD-GENERIC-FUNCTION {4F6E7A42}> #<ASDF/LISP-ACTION:LOAD-SOURCE-OP {1F9CF5CF}> NIL) 11: (#<FUNCTION {65C1AB91}> #<STANDARD-CLASS ASDF/LISP-ACTION:LOAD-SOURCE-OP {714368CD}>) 12: (APPLY #<FUNCTION {65C1AB91}> (#<STANDARD-CLASS ASDF/LISP-ACTION:LOAD-SOURCE-OP {714368CD}>)) 13: (#<STANDARD-GENERIC-FUNCTION {209C8A44}> #<STANDARD-CLASS ASDF/LISP-ACTION:LOAD-SOURCE-OP {714368CD}>) 14: (APPLY #<STANDARD-GENERIC-FUNCTION {209C8A44}> #<STANDARD-CLASS ASDF/LISP-ACTION:LOAD-SOURCE-OP {714368CD}> NIL) 15: (#<FUNCTION {6AD13452}> ASDF/LISP-ACTION:LOAD-SOURCE-OP) 16: (APPLY #<FUNCTION {6AD13452}> (ASDF/LISP-ACTION:LOAD-SOURCE-OP)) 17: (MAKE-INSTANCE ASDF/LISP-ACTION:LOAD-SOURCE-OP) 18: (PROVE.ASDF:RUN-TEST-SYSTEM #<ASDF/SYSTEM:SYSTEM {175A9F63}>) 19: (APPLY PROVE.ASDF:RUN-TEST-SYSTEM (#<ASDF/SYSTEM:SYSTEM {175A9F63}>)) This is with ABCL trunk using ASDF:ASDF-VERSION "3.1.7.40". -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 3

Patch for ABCL development versions
by Mark Evenson 01 Dec '16

01 Dec '16

I'm unsure of the current ASDF work flow for patch submissions, but I guessed that y'all would like [merge requests][57]. Without this patch, Elias' recent work on UIOP/RUN-PROGRAM won't be utilized on any ABCL which is built from development source. ABCL uses the convention that development versions start appending strings separated via #\- characters to the primary value returned by CL:LISP-IMPLEMENTATION-VERSION (e.g. '1.5.0-dev'. Such values cause the UIOP/UTILITY:PARSE-VERSION function to return nil, meaning that this is not a suitable conditional for whether LAUNCH-PROGRAM is invoked. This patch uses the value of UIOP/OS:IMPLEMENTATION-IDENTIFIER to identify version. Unknown whether this would work on MKCL/ECL, which might simplify the code path here. [57]: https://gitlab.common-lisp.net/asdf/asdf/merge_requests/57 Please let me know what I can do to conform to y'alls current style conventions, test coverage, etc. for such a patch submission. This patch is necessary for [my backporting of Elias's work to JDK56][1] [1]: http://abcl.org/trac/ticket/422 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

Incremental defsystem dependencies
by Faré 30 Nov '16

30 Nov '16

Dear Stelian, Dear Lispers, in Gitlab MR !37 I try to address some fundamental bugs regarding the proper treatment of incrementality for defsystem dependencies. See for instance the test I just added, that still fails at this time, test-defsystem-depends-on-change.script. https://gitlab.common-lisp.net/asdf/asdf/merge_requests/37 Now, the good news is that it's a generally understood problem, analogous to proper phase separation of macro evaluation in e.g. Racket, or of proper stratification of dynamic computation graphs in reactive programming: "just" have an operation define-op for every primary-system, that can represent in the graph the definition of other computations, and its dependencies. Many current open ASDF bugs can be fixed, and ASDF will correctly handle the incremental rebuilding of systems when a defsystem-depends-on dependency is out of date. The bad news is that it becomes even harder than before to support a system that has defsystem-depends-on on another system defined in the very same file, a feature currently relied upon by iolib. Indeed, if every reference to a system by operate now triggers a dependency on define-op, then loading a file already being read while defining a system triggers the circular dependency detector. To solve that while preserving some semblance of atomicity for the perform seems hard. Stelian had a proposal to defer the evaluation of the defsystem forms, which could help if done well, but itself is not a trivial change, and might not help that much when methods are defined on (eql (find-system ...)). We'll see. Stelian, how sad would you be if you have to segregate defsystem-depends-on to refer to systems in separate files? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Malthusianism: because growth may stop within centuries, we must use extreme violence to put an end to it now and make everyone poor today.

2 3

3.2.0
by Robert P. Goldman 29 Nov '16

29 Nov '16

This is clearly my fault. I lost track of the plan. Going forward, I need to get a better handle on plans -- I've been to reactive, having discussions spread across launchpad, GitLab, IRC, and the mailing list. Here's one proposal: instead of reverting the recent merge, we could cut a release off master before the merge. That would give us a less disruptive release (at the expense of a little complexity on the release branch). Would this make everyone happy? Sent from my iPhone

4 6

no operation initargs, ecl make-build, etc.
by Faré 27 Nov '16

27 Nov '16

Dear Lispers, apart from a new and improved run-program featuring asynchronous support thanks to Elias Pipping, the ASDF master branch (currently at 3.1.7.37) also features some long announced cleanups of internals: * instead of using operation class names (symbols) as keys to various internal tables, whereby ASDF can't distinguish between multiple operations of same type, operation objects are used instead. * this required making sure that operation objects are always created using MAKE-OPERATION, which can hash-cons them when created with compatible options. * this also required eliminating the current original-initargs mechanism, which was abused by SWANK and ECL in non-sensical ways, but never used to build distinguishable operations (nothing could). * there is currently no more mechanism to build distinct operations of a same class, and so each operation class is currently a singleton. But in the future some mechanism might be added e.g. to support cross-compilation. Or not. Swank was fixed. An alternative implementation of ECL's MAKE-BUILD has been offered, but I'd like to stop making this function part of ASDF itself: ECL can provide its own add-on it they care for this function, it just was never a good fit for ASDF, that provides better APIs since 3.1.2 (May 2014). That said, Robert is the person to convince whether to keep shipping MAKE-BUILD or not. See !34 for an extended discussion: https://gitlab.common-lisp.net/asdf/asdf/merge_requests/34 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Committing genocide on behalf of an institution generates greater loyalty to it than merely getting people fired from their jobs on its behalf. — John McCarthy

1 0

Getting to 3.2 release
by Robert Goldman 27 Nov '16

27 Nov '16

My current thoughts have been to merge the obsolete function warnings and bad system name merge requests and then release 3.2. But perhaps this is a bridge too far. I'd be interested in opinions for and against bundling up the current version as 3.2, and moving on to 3.2.x and 3.3 release candidates. Also, separately, I'd be interested in more discussion of how changes to the image and program operations will affect others. I tend to lose track of these, since I don't use them myself. Thanks, r

1 0