asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

Custom options for dependent systems
by Alexey Veretennikov 14 Mar '17

14 Mar '17

Hi all, I have a following problem. I'm defining a system which depends on cl-charms. cl-charms in its turn contains some cff-groveller file. But this file could not be compiled unless I provide cc-flags to the include directory. So the question is how to define dependency on cl-charms in my system providing some argument which will be used while compliling/loading cl-charms, like the variable containing cc-flags? Br, /Alexey

2 1

Test results for "test" branch on Linux
by Robert Goldman 28 Feb '17

28 Feb '17

On Linux I get test failures for run-program as follows: allegro8_64 failed test-program.script allegro8_64_s failed test-program.script allegro_64 failed test-program.script allegro_64_s failed test-program.script allegromodern8_64 failed test-program.script allegromodern8_64_s failed test-program.script allegromodern_64 failed test-program.script allegromodern_64_s failed test-program.script ccl failed test-program.script clisp failed test-program.script cmucl failed test-program.script ecl failed test-program.script lispworks failed test-program.script mkcl failed test-program.script sbcl failed test-program.script These all seem to be due to test code passing :CONSOLE T to INVOKE-LISP Cheers, R

2 1

ASDF 3.2.0 is released
by Faré 11 Jan '17

11 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é 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel