April 2015 - asdf-devel - mailman3.common-lisp.net

[asdf-devel] how to add one more directory to an initialized registry?
by Attila Lendvai 08 Apr '15

08 Apr '15

so, let's say i have an already initialized source registry, and from my .sbclrc i want to add one more directory to it. currently this is what i kludged together, but it stinks: (asdf:initialize-source-registry (append '(:source-registry) (butlast asdf:*source-registry-parameter*) `((:directory ,(merge-pathnames "whatever" (user-homedir-pathname)))) '(:inherit-configuration))) or am i completely backwards with the cart, and i should just forget .sbclrc and use ~/.config/common-lisp/source-registry.conf.d/ for this? the reason i prefer calling initialize-source-registry because then we can commit the right form into our env repo and the team members can have the exact same environment with less effort (just loading one repo-tracked file from .sbclrc). -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “During times of universal deceit, telling the truth becomes a revolutionary act.” — George Orwell (1903–1950)

3 7

[asdf-devel] How should ASDF return cached system definition information
by Robert P. Goldman 08 Apr '15

08 Apr '15

The latest version of ASDF contains three functions: SYSTEM-DEFSYSTEM-DEPENDS-ON SYSTEM-DEPENDS-ON and SYSTEM-WEAKLY-DEPENDS-ON that return information about defined systems. The intention is to support introspection about sets of systems (I believe Quicklisp does this today). Currently, ASDF does *not* put the return values into canonical form. So, equivalent forms like :depends-on (foo) and :depends-on ("foo") will yield different return values. Similarly, :version specifications will not be resolved. This seems wrong to me. I feel that the return values should be canonicalized. So all system names should be resolved down to lower-cased strings. Does that sound like the right approach? It would support performing inference on the systems relatively straightforwardly. I can't imagine why people would want the exact, literal slot initforms, but I could be wrong. R

2 6

[asdf-devel] Will you please test the latest ASDF with CMUCL
by Robert Goldman 08 Apr '15

08 Apr '15

On Mac OS X for me, it fails upgrade from 2.32 to the latest (3.0.2.2) using method require. Faré's testing instructions are: /usr/local/bin/cmucl -noinit then copy/paste: (load"test/script-support.lisp") (asdf-test::da) (test-upgrade 'load-asdf-lisp'load-asdf-lisp-clean "REQUIRE") I get an error as follows: Error in function KERNEL:CLASS-TYPEP: Class is currently invalid: #<KERNEL::STANDARD-CLASS ASDF/SYSTEM:SYSTEM {48589A35}> Please let me know any findings. I'd like to get this fixed (or disconfirmed) before we release 3.0.3. Best, r

2 2

Re: [asdf-devel] ASDF 3.0.2.1 released
by Faré 08 Apr '15

08 Apr '15

Dear Robert, here are some code review comments on ASDF 3.0.2.1. * Putting :asdf/find-system after :asdf in the recycle looks like it's defeating the purpose; you might as well remove it. * Maybe refactor duplicate-names so it doesn't inherit from system-definition-error ? Or have a function of the same name be called that is defined later to throw the error? * Since we don't work on antique cmucl, maybe we could check whether the :report print-object hack is still needed? * I kind of wanted to prevent the multiplication of .asd files and the eating away of the namespace by using test-asdf/foo systems for new systems; but it's your baby, so your call. Also, an error might not be compatible with putting it in test-asdf.asd. On the other hand, that's a case where define-test-system and/or eval can be used so you don't need a .asd file at all. * the nodes in the grammar could be renamed to be less confusing and not require a comment. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The politicians have a most touching faith in technology — that it can make up for any dumb thing the politicians decide to do. — John McCarthy

3 3

[asdf-devel] proposal to split ASDF in half
by Daniel Herring 08 Apr '15

08 Apr '15

Hi all, This has bugged me for years, and recent traffic brings it back to the forefront. I apologize that this email is more a teaser than a complete solution, but that's what time allows for right now. In my opinion, a lot of the complexity in ASDF is caused by its conflation of two separate goals: a "build system" and a "loader". There are a wide variety of build tools available for C/C++ and many other languages: make, imake, cmake, (s)cons, (b)jam, ninja, redo, etc. While the added overhead of installing a build system before compiling a project has drawbacks, many of these tools have compatibility with make, and most users don't compile most code. The compatibility of files produced by these diverse tools allows a lot of experiments to be run, and successful features often get absorbed into tools like GNU make. This compatibility is allowed because the loader (dynamic linker in C speak, class loader in Java) has a simple, well-defined protocol for telling it where to find things, independent of the build system. Look at the linux manpages for ld.so and ldconfig... If CL is to grow from a dev-centric ecosystem to have a large base of "normal users", I think we need to start finding ways to enable better long-term stability. Pre-tested, "binary" releases are exactly what an end user wants. Applications need to "just work" and not break whenever a dependency changes its API. What does this mean for ASDF? Since many CL developers want features like load-time recompilation, the simple static decoupling in C between link and load is not possible. A richer interface is required. While deprecated, the CL PROVIDE and REQUIRE API is very close to ideal for a loader. Obvious extensions include protocols for adding versioning checks/negotiation, search paths, re-build hooks, something better than *MODULES*, and implementation independent behavior. This API should be as small as possible, truly abstracting the different activities, and allowing multiple implementations to coexist. Then tools like ASDF could produce "installs" that fit into this framework. The core loader would still be integrated into each CL distro, but the build tool, with its dependency tracking, source file searching, and other features could be distributed separately, and multiple tools could coexist in a single image. Wherever possible, the simplest loader solution should be chosen, leaving sysadmins and/or build tools to handle any "difficult" configuration (such as hidden directories). For example, the loader could require that all libraries be installed using some UUID or hash-based scheme in a common location, and hooks inside these installs are used to activate fancy builder-specific features. I apologize, what I just wrote looks way too complicated. For example, it is possible that versioning, searching, rebuilding, and loading could be a builder-specific behavior inside a single try-load function. However it works out, I do believe that a simple decoupled API that breaks ASDF into a simple, stable loader core and a more featureful, faster changing piece, would be good for everyone in the long term. Loaders have a simpler required feature set than build systems. Loaders just need to allow for a few types of search scoping (per system, per user, and per program). Build systems require configuration, searching, incremental rebuilds, installation, unit testing, etc. Later, Daniel

4 4

[asdf-devel] Advanced Configuration
by FAU 08 Apr '15

08 Apr '15

Hello. I'd like to find out if I can do this with ASDF. Lets say I have a lisp file like this: ;;; foo.lisp (defpackage :foo (:use :cl) (:export :foo)) (in-package :foo) (defun foo () #+foo1.0 :foo1.0 #+foo1.1 :foo1.1 ) ;;; foo.lisp ends here The system definition file: ;;; foo.asd (asdf:defsystem :foo :components ((:file "foo"))) ;;; foo.asd ends here As you can see the behaviour of the fn foo depends on version request features (which, lets say, represents the API version and not the software package version) which must be pushed on *features* before the system is compiled (or loaded). I'd like to have ASDF reject any operation on system foo if there's not an appropriate API version request feature present for it and notify the user in some way. I'd like to keep multiple fasls for different API versions in the cache. (One way to achieve this, which comes to my mind, would be to mangle the name of the fasl output file name to incorporate the version in same way or to change the output directory path.) Thanks -Frank

2 5

[asdf-devel] New issue with tests
by Robert P. Goldman 08 Apr '15

08 Apr '15

Now when I run the tests with make test-all-no-upgrade I get to the end of the test process and I am left with: -#--------------------------------------- Using abcl Ran 48 tests: 48 passing and 0 failing all tests apparently successful -#--------------------------------------- ./test/run-tests.sh -c abcl at this point, make hangs until I interrupt it with ^C. Is it possible that I have messed up the way I conditionalized the test-bundle.script file? What I did was add this: #+(or abcl ecl) (leave-test "Bundle test doesn't work on Mac on this lisp." 0) in my working copy. Could that be causing this hang? thanks, r

5 5

[asdf-devel] Regression on Allegro Common Lisp
by Robert P. Goldman 08 Apr '15

08 Apr '15

I pulled an update this afternoon, and now on ACL 9.0 on Mac OS X I get a failure on asdf-pathname-test.script I get an error as follows: Above backtrace due to this condition: attempt to take the length of a non-sequence: :UNSPECIFIC I get an enormous backtrace, but this is I think the direct call that gets an error: (LET ((STREAM (OPEN . #16=((ASDF/COMPONENT:COMPONENT-PATHNAME ASDF-PATHNAME-TEST::FILE) :DIRECTION :OUTPUT :IF-EXISTS :RENAME-AND-DELETE :IF-DOES-NOT-EXIST :ERROR))) (#12=#:WITH-OPEN-FILE-ABORT-398 . #61=(T))) (UNWIND-PROTECT (MULTIPLE-VALUE-PROG1 (PROGN . #17=((PRINT ASDF-PATHNAME-TEST::START-TIME STREAM) T)) (SETQ #12# . #58=(NIL))) (WHEN (STREAMP STREAM) (CLOSE STREAM :ABORT #12#)))) More as I find out more. Best, r

3 4

[asdf-devel] Merged Fare's RUN-PROGRAM topic branch
by Robert P. Goldman 08 Apr '15

08 Apr '15

I have merged Fare's RUN-PROGRAM topic branch and pushed it as 3.0.2.11. Passes all the tests for Fare and me on Linux and for me on Mac (modulo known bugs in bundle-op). My intention is to release this as 3.0.3 in the next few days, but I would like to make it available for people to play with first. I'm of course happy for you all to run the test suite on your own machines and implementations (contact me if you need help setting this up), but even more, I'd be obliged if you were to test this on your own systems (again, ask for advice if you need help setting up to do this). I'd particularly urge you to try this on systems where you have made your own extensions (new component or operation classes), or where you reach out into the environment to do something else (e.g., run "make" or the C compiler for FFI). Those would be the most likely to expose bugs in the new facilities. Best, r

2 1

[asdf-devel] Trying to get ASDF tests (especially uiop:run-program) on Windows (Allegro CL, CCL) cleaned up before 3.0.3 release
by Dave Cooper 08 Apr '15

08 Apr '15

Starting a new thread, but in due course we should keep Fare's most recent words from previous thread in mind for expanding the test suite for uiop:run-program: Fare wrote: Ideally there would a test that includes all printable ASCII > characters and ensures that quoting works alright, with either a list > or string argument (beware quoting when generating the string). Anyway, here is what I'm seeing currently (with an unpatched 3.0.2.7): Allegro 9.0: ========= Running the test script from cygwin brings up an Allegro CL Console which immediately displays the following error: ==== An unhandled error occurred during initialization: An error occurred (Attempt to take the value of the unbound variable `|"TEST/SCRIPT-SUPPORT.LISP"|'.) during the reading or evaluation of -e "(or #.(load \\\"test/script-support.lisp\\\") #.(asdf-test::compile-asdf-script))" <The Lisp process exited with status -1 (0xffffffff)> ==== So the -e argument is not making it properly into the Allegro, and it looks like something has to be updated in the test script just to get Allegro/Windows to start running the tests. Would anyone from Franz Support care to have a look at this? I did confirm that normal programs can be run with Allegro's excl:run-shell-command without the need for "cmd /c" prepended. CCL 1.9 ======= asdf test results for (unpatched) 3.0.2.7 are here: https://www.dropbox.com/sh/jc2cqwpkp06dupm/tx0U1Fun65/cl/tests/asdf/output/… Note that the first failure, for the bundle-test, is a known bug in ccl:fasl-concatenate in CCL 1.9 for Windows, and has been fixed in the trunk for CCL 1.10. The second failure just looks like the extra space after the "ok 1" as we were seeing before. Perhaps this is also a CCL issue? Can anyone from Clozure comment on this? Also, I think I confirmed that CCL's ccl:run-program on Windows really does need the "cmd /c " prepended to be able to run a normal program. Currently the uiop:run-program is doing (cons "cmd" (strcat "/c " command)) for commands given as a single string, but it does not prepend anything for commands given as a list. There was previous opinion that the list form of the command should not automatically get the ("cmd" "c/") prepended. But from what I can tell, the user will always have to do (uiop:run-program (append '("cmd" "/c") command) if user wants to give command as a list. If that's the case, then for consistent interface of uiop:run-program across different Lisps, shouldn't uiop:run-program go ahead and do that appending by default? SBCL ===== Sorry, I'm not running SBCL on Windows at the moment. Anyone? Get with me if you can use some guidance getting the ASDF test scripts running. LispWorks ======== I don't have LWW at this juncture. Anyone? ABCL, ECL, CLISP, GCL (who am I forgetting?) ====================================== Anyone running these on Windows and willing to run some ASDF testing scripts (probably through cygwin)? Get with me if you want some guidance and/or moral support. Regards, Dave

2 3