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

[asdf-devel] Please test for ASDF 3.0.2
by Faré 08 Apr '15

08 Apr '15

Dear Lisp hackers, next release of ASDF will be 3.0.2, and be done shortly by Robert Goldman. Please test. Changes since 3.0.1: * Tweaks to RUN-PROGRAM so it works better on ACL, and to RUN-SHELL-COMMAND so it's more backward-compatible. * Tweaks for XCVB: better CFASL support on SBCL and easier default-encoding. * Tweaks of TRAVERSE: have it always return a list of actions, deprecate it. Have OPERATE use MAKE-PLAN instead, that always returns a plan object. * Fixes to debian package. We're into tweaking, which is a good sign: it means the ASDF code base is stable indeed. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org An extreme optimist is a man who believes that humanity will probably survive even if it doesn't take his advice. — John McCarthy

3 5

[asdf-devel] Patch to run-tests.sh for additional Allegro variants
by Dave Cooper 08 Apr '15

08 Apr '15

ASDF probably doesn't go deep enough into the implementation for some of these variants to make a difference, but might as well include them anyway. Here's a patch for that. Allegro now has (potentially) 16 variants for each OS platform: ANSI/modern 8-bit-character/16-bit-character 32-bit/64-bit SMP/non-SMP (expt 2 4) --> 16. -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

3 2

[asdf-devel] Alternate default lisp system location
by Robert P. Goldman 08 Apr '15

08 Apr '15

How would you all feel about an alternate default location for lisp systems, in addition to ~/.local/share/common-lisp/source/ I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but it just seems odd to me to hide the lisp systems from the user, which we are doing by putting them in a location that requires ls -a. After all, these are systems, not configuration files. What about ~/asdf-systems which doesn't make the poor user play peekaboo? I came across this while editing the manual. I don't use this directory myself; maybe everyone loves it. Or maybe no one uses the standard default, and I shouldn't care. Cheers, r

14 79

[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] 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] 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] NAMED-READTABLES
by Robert P. Goldman 08 Apr '15

08 Apr '15

Faré wrote: >> > *This is partly my fault, but the current disarray of cl.net, the >> > library's position as part of an abortive EDITOR-HINTS master system, >> > and the previous maintainer's putting it into a revision control system >> > (darcs) that I don't use and don't understand are additional >> > contributing factors. >> > > If you're the new maintainer, I suggest converting the darcs > repository to git and maybe putting the library on github. I don't know enough to translate a darcs repo to git. I could probably manage this, but tcr buried the NAMED-READTABLES repo somehow inside an EDITOR-HINTS repo, and linked the two in some way I don't understand. This problem is compounded by the fact that when I tried to figure out how to fix it, the email on cl.net was broken so that admin requests went into the bit-bucket. There are pending patches I need to push into NAMED-READTABLES, but I would need some assistance to fix this. I note that NAMED-READTABLES are necessary to support your proposed changes, but *are not sufficient*, since support for named readtables would have to be added to the development environments. I would like to forestall facile answers to the above claim, too. I don't just mean "SLIME would have to handle IN-READTABLE." SLIME would have to be fixed, yes, but also ELI, Allegro Composer, Hemlock (or whatever the CCL IDE is), LispWorks whatchamacallit, etc., etc. ASDF should not demand a programming style that doesn't have full support for in-editor dynamic code writing and maintenance. Yes, this means that there can be bad libraries out there, but there are lots of crappy libraries even aside from misusing readtables or pretty-print dispatch, and ASDF cannot fix them all.

3 2

[asdf-devel] Please test before releasing ASDF 3.0.0 - Also, resigning again
by Faré 08 Apr '15

08 Apr '15

Dear Lisp hackers, I'd like to release ASDF 3.0 next week (maybe even later this week). Can you test ASDF before I do? I'll have to produce some document explaining the innovations since ASDF 2.26, 2.000 and/or 1.369, but for now here are just the changes since 2.33. As you can see, it's very minor stuff, and ASDF has been mostly stable these last two months, which is a good sign and the reason why I'm making an official 3.0 release. I'm also inserting a new digit in the version, so releases will have three digits: 3.0.0, 3.0.1, etc. will be minor continuations of 3.0. 3.1.0 will be the next "major" milestone in a series that preserves compatibility, and 4.0 (if ever) will be the next major release that doesn't. But I probably won't be there to see it, because I'm moving away from my Common Lisp job in Cambridge MA to some new as yet undetermined opportunities in NYC that are unlikely to see me do Common Lisp for a living, and I plan to try out different Lisps for a hobby (Racket, Maru, etc.). * Portability: have *uninteresting-conditions* be empty by default. Move stuff to *usual-uninteresting-conditions*, unused by default. Will make the SBCL team happy. Also, fix tests on ABCL. * UIOP: improvements to slurp-input-stream and thus run-program, notably accepting T as alias for *standard-output*, for better backward-compatibility of the deprecated run-shell-command. New macro with-output-file. * POIU support enhanced various tweaks. * Build cleanups. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Of all the things I've lost in life, I miss my mind the most... — Ozzy Ozbourne

5 12

[asdf-devel] Unable to upgrade asdf using clisp 2.49 on Mac OS X
by Robert P. Goldman 08 Apr '15

08 Apr '15

On Mac OS X, when I try to upgrade my ASDF using the logical pathnames "home:lisp;asdf;" and "home:lisp;asdf;uiop;" I get this error: *** - While searching for system "asdf": "home:lisp;asdf;uiop;" evaluated to "home:lisp;asdf;uiop;" which is not an absolute directory. Note that I am using ASDF:*CENTRAL-REGISTRY*, not the configuration DSL. But: Break 1 [2]> (translate-logical-pathname "home:lisp;asdf;uiop;") #P"/Users/rpg/lisp/asdf/uiop/" Is this expected behavior from clisp + ASDF? This same configuration works on ACL and SBCL, which suggests its a clisp issue.

2 6

[asdf-devel] ASDF testing for LWW
by Dave Cooper 08 Apr '15

08 Apr '15

Hi, I've been helping with ASDF regression testing on Windows, where we use a cygwin shell to run the ASDF test scripts. We don't have LispWorks licensed for Windows currently, so I looked at using the Personal Edition. But this is apparently not possible because the ASDF tests assume a "console image," which is supposed to be created with save-image --- functionality which is not available in the Personal Edition. So my questions are: 1. Is there something I'm missing which would indeed allow me to produce a console image (or something which behaves like one) from LWW Personal? 2. If not, would anyone with a licensed LWW be willing to run the ASDF regression tests? I will be happy to step you through the process. For what it's worth, so far I have the following implementations covered for Windows: Allegro CL 9.0 CCL 1.10-dev CCL 1.9 SBCL 1.1.12 Anyone who would like to test any other implementations on Windows should feel welcome to reach out to me for guidance on how to set them up as well. -- My Best, Dave Cooper, Genworks Support

3 5