asdf-devel January 2017

asdf-devel@common-lisp.net

3 participants
4 discussions

ASDF 3.2.0 is released
by Faré 10 Jan '17

10 Jan '17

It is with great pleasure that we announce the release of ASDF 3.2.0, a new milestone in the development of ASDF. This change in minor version number advertises how much ASDF has evolved since we released 3.1 in 2014, and at the same time how stable the API has been since we release 3.0 in 2013. Note that we already have significant changes in the pipeline and are intending to release a 3.3.0 in a couple of months. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.2.0 at their earliest convenience. Release 3.2.0 contains significant bug fixes on multiple platforms and implementations, and does not introduce any incompatibilities on public APIs. It does however introducing cleanups and refactorings that break some undocumented (and sometimes explicitly deprecated) internals. Those systems in Quicklisp that abused these internals have been fixed (notably including slime, asdf-system-connections, cffi, iolib, prove, cl-protobufs). Details on bugfixes can be found at https://launchpad.net/asdf and in the discussions in merged branches of https://gitlab.common-lisp.net/asdf/asdf Notable credits go to Robert Goldman for his relentless testing and push for quality, to Elias Pipping for his contribution of the new launch-program infrastructure and upping the standards for code, to François-René Rideau for general coding and fixing a few more bugs than he put in, to Dave Cooper for lending access to a Windows test server, and to Anton Vodonosov for repeatedly testing with cl-test-grid. Here is the changelog entry for 3.2.0, compared to 3.1.7: New milestone: * launch-program: new UIOP API for asynchronous subprocesses, now available on: abcl allegro clozure cmucl ecl (and lispworks os-unix) mkcl sbcl scl. Big thanks to Elias Pipping for this significant contribution! * parameter-error, not-implemented-error: new UIOP functions to better signal abuse of parameters in function calls, or lack of function implementation. * with-deprecation macro in UIOP signals style-warnings, then warnings, then errors when deprecated functions are used. This macro is now used for all deprecated functions in ASDF. * require-system, component-loaded-p fixed to not reload .asd files, and to work in presence of preloaded-systems, that are now eagerly loaded. * registered-system added as an abstraction for internals and extensions. * make-operation is now the only supported way to create an operation; calling make-instance directly will raise an error. Update your software! * Removal of several obsolete backward-compatible internals: if-component-dep-fails, operation-forced. Update SLIME! * Robustness and portability fixes all around uiop, notably dealing with directory access, bundles on ECL and MKCL or with cffi-toolchain, dealing with a fatal-condition, surviving use of "logical" pathnames, etc. * Tests improved and extensively run on Linux, macOS and, notably, Windows, with recent versions of all the maintained CL implementations. * Internals of ASDF systematically cleaned up and documented. * Build, test, release infrastructure improved, both classic and asdf-tools. * Documentation updated. -- Francois-Rene Rideau <fare(a)tunes.org> Sun, 08 Jan 2017 20:45:29 -0500

1 0

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é 31 Dec '16

31 Dec '16

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel January 2017