asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

uiop:run-program on abcl 1.4 + windows flaky 3.1.7.43 flaky vs 3.1.7
by Mirko Vukovic 05 Jan '17

05 Jan '17

I ran the following on abcl 1.4 on windows 10 with Java 1.8.0_112 with --noinint. I test uiop:run-program like this: (uiop/run-program:run-program '("where.exe" "java.exe") :output :string) It works fine with asdf-3.1.7. If I load 3-1.7.43, it works only on the second try of a session. Session transcript with 3.1.7: CL-USER(5): (load "asdf-3.1.7.lisp") T CL-USER(6): (uiop/run-program:run-program '("where.exe" "java.exe") :output :string) "C:\\ProgramData\\Oracle\\Java\\javapath\\java.exe " NIL 0 If I load 3-1.7.43, it works only on the second try of a session. Here is a synopsis of doing run-program twice: CL-USER(2): (uiop/run-program:run-program '("where.exe" "java.exe") :output :string) Error loading jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 166 (offset 8688) #<THREAD "interpreter" {34D8B89D}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(3): Pressing `0' results in a huge java stack: java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) ... at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Unknown Source) Caused by: org.armedbear.lisp.Go Error loading jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 166 (offset 8688) #<THREAD "interpreter" {34D8B89D}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.run_program_49 from org.armedbear.lisp.Pathname@3027289e Restarts: 0: TOP-LEVEL Return to top level. Pressing `0' brings be back to the top level from which I try again run program, this time with success. [1] SYS(4): 0 CL-USER(5): (uiop/run-program:run-program '("where.exe" "java.exe") :output :string) "C:\\ProgramData\\Oracle\\Java\\javapath\\java.exe " NIL 0 CL-USER(6):

2 2

Re: ASDF 3.1.7.43 is 3.2 release candidate
by Anton Vodonosov 05 Jan '17

05 Jan '17

Results are coming, these lisps are ready: ccl-1.10-r16196-f96-linux-x86 cmu-snapshot-2016-12__21b_unicode_-linux-x86 sbcl-1.3.12-linux-x86 The following report is the part of the diff including only results where new version fails: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-54.html As we can see, other systems than asdf-systems-connections fails with the " OPERATION instances must only be created through MAKE-OPERATION." too. This error constitures the majority of failures. To make it easier seeing other errors, the next report filters out the " OPERATION instances must only be created through MAKE-OPERATION." and leaves only other errors: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-55.html Notable are the cl-python failure, the "Unknown CFFI type (:STRUCT TUNION1)" error, the "Component CLSQL-UFFI-SYSTEM::UFFI does not match version 2.0, required by #<SYSTEM "clsql-uffi">" Best regards, - Anton 26.12.2016, 11:57, "Anton Vodonosov" <avodonosov(a)yandex.ru>: > Tests are running (wht updated slime, cffi, asdf-systems-connections) > > 26.12.2016, 08:22, "Faré" <fahree(a)gmail.com>: >> I see no unexplained failure in Anton's previous test run, but it's >> possible that the explained failures are hiding further failures down >> the line. >> >> Anton: can you re-run with an updated asdf-systems-connections AND an >> updated SLIME? >> >> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org >> Have the courage to take your own thoughts seriously, for they will shape you. >> — Albert Einstein >> >> On Mon, Dec 26, 2016 at 12:00 AM, Faré <fahree(a)gmail.com> wrote: >>> I see a lot of failures on ECL that seem related to using swank, >>> except the swank package is not defined. That also might be caused by >>> a bad and/or old SLIME, that was badly abusing some asdf internals in >>> an incoherent way. Can you try with the latest SLIME? >>> >>> Note that I am quite angry at the SLIME maintainers because I have >>> tried many times to offer them fixes to swank.asd but they never >>> merged any of my proposed pull requests. >>> >>> Otherwise, it looks mostly good. >>> >>> NB: When there is an error from a gcc subprocess, you don't seem to be >>> capturing the output, which goes directly to fd 1 / fd 2 of the >>> process, as inherited by the subprocess. Maybe you can fix that in >>> cl-test-grid? >>> >>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org >>> The idea is not to confront bad ideas but to come up with good ideas. >>> Otherwise, your enemies define the game and you are the loyal opposition. >>> — Terence McKenna >>> >>> On Sun, Dec 25, 2016 at 7:22 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >>>> It is the same system. >>>> >>>> When previous result was CRASH and new one is FAIL, it might be the same error. But when the previous was OK and new is FAIL, it's more suspicious. >>>> >>>> For example: >>>> (LOAD exscribe OK) >>>> vs >>>> (LOAD exscribe FAIL) QUICKLISP-CLIENT:SYSTEM-NOT-FOUND : System "fare-scripts/rescript" not found >>>> >>>> 26.12.2016, 02:36, "Faré" <fahree(a)gmail.com>: >>>>> On Sun, Dec 25, 2016 at 4:08 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >>>>>> https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-52.html >>>>> >>>>> It's not looking too bad, but there are a lot of new failures with the >>>>> latest sbcl, where some dll is not found. Can that be explained by >>>>> your running on a different setup where some libraries are missing, or >>>>> is that something I should investigate? >>>>> >>>>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org >>>>> Language is froth on the surface of thought. — John McCarthyte

2 9

Re: Question about resolving "symlink/.."
by Faré 01 Jan '17

01 Jan '17

On Thu, Dec 29, 2016 at 5:21 PM, Jason Miller <jason(a)milr.com> wrote: > Quoting Faré (2016-09-08 05:25:36) >> CL distinguishes :up and :back in directory components of pathnames. >> How ".." is parsed by uiop:parse-native-namestring is >> implementation-dependent, relying on the implementation's underlying >> native-namestring support (if any, falling back to >> cl:parse-namestring). >> >> If you insist on reading it as :up, you could use >> (uiop:parse-unix-namestring string :dot-dot :up) > > Out of curiousity, why isn't this the default behavior of > parse-unix-namestring? It seems to me that the :up is semantically the > correct mapping for ".." on unix. > Because parse-unix-namestring was born out of the needs of ASDF, and those needs were better met by :back than :up. Also, for security reasons, :back is usually better behaved than :up. :up is a gross hack that will get you p0wned. > Also note that for #+(and (or unix cygwin) (not (or clozure cmucl sbcl > scl))) uiop appears to use parse-unix-namestring rather than > cl:parse-namestring, so e.g. ecl on linux uiop will parse ".." as :back > rather than :up > Yeah well. If you *really* want well-defined portable semantics for parsing pathnames, you'll have to use iolib. I think of UIOP more as a jumpstart than as a 100% solution. It's there to get ASDF going and serve your easy scripting needs until you really need reliability at which point it helped you load IOLIB. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reasons for existence are usually provided for things that don't exist; they would be wasted on things which do. — Saul Gorn

1 0

ASDF 3.1.7.43 is 3.2 release candidate
by Robert Goldman 26 Dec '16

26 Dec '16

Per Daniel's request, I have tested and merged the link-objects-only merge request, and the result is ASDF 3.1.7.43 At this point, I'm done with anything except patches that we discover in pre-release testing, writing the changelog, etc. Will everyone who can please try out the latest ASDF with their own systems? And Anton, if you could test it with the cl-test-grid, that would be great. I'd like to push this out by the end of next week. I'm considering bumping the version on this to 3.2.0 so that anyone who wants to test new features with conditionalization on ASDF version can try it out. Any objections? Best, r

5 19

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel