asdf-devel November 2016

asdf-devel@common-lisp.net

11 participants
15 discussions

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

ECL on Windows
by Robert Goldman 19 Nov '16

19 Nov '16

I apologize, but I think I am going to have to proclaim ECL on Windows as officially unsupported by ASDF. There are underlying bugs in ECL on Windows that preclude ASDF functioning correctly. To the best of my knowledge, there isn't anyone able to maintain ECL on Windows, and given that, attempting to keep ASDF working on that platform just piles up failing tests. With apologies, as of now I am removing "ecl_bytecodes" from my Windows test suite (I was already unable to test vanilla ECL because of not having a C compiler on Windows). If there are patches available and a means of verifying them, I would like to see Windows ECL support come back, but at the moment the community seems entirely unable to support this platform. Note that ECL is still supported on Mac OS X and Linux.

1 0

Work-around built-in ~/common-lisp/ in search path?
by Robert Goldman 18 Nov '16

18 Nov '16

Here's my issue: 1. I have a bunch of lisp libraries that I use on everyday things installed in ~/common-lisp/. One of the systems in there is an older, modified version of fiveam that my company uses in many projects. 2. I have a project where we use libraries from quicklisp to make it easier to handle dependencies. For this project, I run a function that resets the ASDF source-registry, and uses a special copy of quicklisp (a copy that writes its systems in a different location). 3. I cannot build my system because the version of fiveam in ~/common-lisp/ shadows the version of fiveam from quicklisp, which I need. 4. I don't see any OBVIOUS way to tell ASDF to ignore my ~/common-lisp/ directory. I can do the following: (setf asdf:*default-source-registries* (remove 'asdf/source-registry::default-user-source-registry asdf:*default-source-registries*)) but that seems really hard-core. Would it be reasonable to make the defaults a little easier to override? Maybe something that's equivalent to --no-userinit and --no-sysinit when starting lisp -- something that will remove the user-specific entries or system-specific entries, respectively? I don't believe I can simply wipe the defaults, because then I might miss some SBCL libraries that come with the system default settings. Cheers, r

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel November 2016