asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

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

Extending ASDF System Depends-On Syntax
by Nicolas Hafner 26 Nov '16

26 Nov '16

Hello, good ASDF folk. I have a situation where I'd like to extend the allowed syntax of dependencies in the ASDF system definition forms. More specifically, my library provides a decoupling abstraction of "interfaces" and "implementations", where an interface is a set of stub definitions that can be fleshed out into properly working definitions by an implementing system. A system that depends on the definitions of an interface however should not (and cannot) know in advance which specific implementation might be used, so it instead has to depend on a 'virtual system' represented by the interface. The resolution of which specific system should implement the interface is then pushed out as far as possible and only performed when the interface is required as a dependency. Currently, the library allows you to write system definitions like so in order to facilitate this: (asdf:defsystem foo ... :depends-on ((:interface :bar) ...)) This extension to the depends-on syntax is done by redefining ASDF/PARSE-DEFSYSTEM:PARSE-DEPENDENCY-DEF to catch my specific case in advance and fall back to the original function definition otherwise. Additionally, ASDF:RESOLVE-DEPENDENCY-COMBINATION is extended by a method to handle the :INTERFACE combinator. This works fine so far, but naturally redefining a function is far less than ideal and reeks of an ugly hack. I wrote that code more than a year ago and back then I could not see any other way to extend the syntax in a way that seems intented by ASDF. Maybe the situation has changed, or maybe there's better ways to go about it altogether. Hopefully you'll be able to point me in a right direction, or if there currently isn't one, maybe there's a way to make what I want to do intentionally possible. Thank you for your time and work on ASDF! Sincerely, Nicolas Hafner

2 1

UIOP API
by Robert Goldman 21 Nov '16

21 Nov '16

In a recent ticket, Faré writes: "Some things are defined in uiop/pathname and used in uiop/filesystem, so exporting them is the right thing. There is currently no notion of "shared within uiop but not exported outside uiop". I suppose you could make do using package::qualifiers and/or import statements. Meh." Looking at the UIOP code, I see that there is no equivalent of ASDF/INTERFACE. Should we add this? I have the feeling that might be "Should we add this, before it's too late?" Comments welcome, r

2 1

asdf on windows
by fare windeau 20 Nov '16

20 Nov '16

So, I was hearing the pain of Elias and Robert trying to run tests on Windows, so I dual-booted in Windows, and here is my progress report: * I had to fix the .bat files to fix a typo (if exists should have been if exist) and put quotes around variable expansions to protect against the path containing a space (a frequent occurrence, between Program Files and usernames with spaces). * I had to remove the .exe from asdf-tools' :build-pathname, which was redundant with the .exe added by bundle.lisp, so as not to have asdf-tools.exe.exe * I passed all tests when running using ccl 1.11 for asdf-tools and either ccl or sbcl as the target. But I had to 1- export CCL=/path/to/wx86cl64.exe (and/or just export CCL=wx86cl64.exe and put it in the PATH) (using a ccl.bat script would fail some tests), and 2- use a cygwin window, because ccl fails to (quit) when in a cmd.exe window and has to be killed by the task manager (I once had it fail to quit in cygwin, but could Ctrl-C it dead) (I'll report the bug on the clozure.com site when I get my normal credentials back). * When using sbcl as asdf-tools, some run-program issue prevents invocation of programs, probably due to quoting issues and spaces in executable pathnames. I'll see if I can kluge my way around SBCL run-program bugs using cmd /s /c. Or muster the courage of fixing SBCL (unlikely considering that when I send patches to SBCL they remain unmerged for years). -#f

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel