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

[asdf-devel] Why Lisp is Now an Acceptable Scripting Language
by Faré 08 Apr '15

08 Apr '15

My cl-launch demo: cl -sp lisp-stripper -i '(print-loc-count "asdf.lisp")' Source code for lispwc: #!/usr/bin/cl -sp lisp-stripper -E main (defun main (argv) (if argv (map () 'print-loc-count argv) (print-loc-count *standard-input*))) And of course: for l in sbcl ccl clisp cmucl ecl abcl \ scl allegro lispworks gcl xcl ; do cl-launch -l $l -i \ '(format t "'$l': ~S~%" `#5(1 ,@`(2 3)))' \ 2>&1 | grep "^$l:" # LW, GCL are verbose done Backstory: After recent exposure to Python at work, I grew an intense dislike for that language, and realized that I could do everything in CL instead, and that the remaining stumbling blocks to using CL as a "scripting language" were quite small — just missing the ability to put #!/usr/bin/cl in a script, and there you go. And so, I added just this capability to cl-launch, improved it to have some of the features of buildapp, and made sure it works without a hitch on each of the 11 implementations with a command-line interface. This in turn requires updating ASDF and UIOP, and so here we are with ASDF 3.1.0.86. Then, I found that I had to take the word out, and started editing that way a paper that I'm preparing a paper for ELS 2014 (or else ILC 2014): ASDF3, or Why Lisp is Now an Acceptable Scripting Language It's incredible how having to explain the code forces you to make it actually simpler to use. Hence new option -sp in cl-launch, to load a system and change the current package, all in one go. Hence also having cl-launch build software with a sequence of --system --load --eval instead of a single setup file and toplevel system like before: people already understand a sequence of build commands. Also new in ASDF3: command line argument support was improved with a LispWorks workaround and a new argv0 function; with-input and with-output accept pathnames as designating a file to open; the bundle support was much improved and cleaned up; the upgrade mechanism was slightly improved to cope with the class refactoring; bugs were found and removed in pathname functions; a weird bug in SCL was worked around. Enjoy! TODO: I'm considering modifying the default behavior of cl-launch to launch a REPL and/or read commands from stdin, like a Unix shell does when given no script and no commands to run. I'm reserving that for another round of procrastination. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To have a right to do a thing is not at all the same as to be right in doing it. — G.K. Chesterton

2 2

[asdf-devel] Problems with different versions of ASDF
by Robert Goldman 08 Apr '15

08 Apr '15

I have been running with ASDF from ACL and sometimes overloading it with ASDF from git. This gives me package errors like the following: ; Fast loading /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf-context/set-context.fasl Error loading #P"/Users/rpg/clinit.cl": No package exists of name ASDF/LISP-ACTION. I suspect this happened because ASDF-context was compiled in an image with ASDF 3 loaded, and is being loaded in an image with ASDF 2.x (shipped by Franz with Allegro). Is there something I can do in systems that build on ASDF to avoid this from happening? Putting (:depends-on ASDF) in the relevant system (here my "asdf-context" system) does not solve the problem. It seems that we need a mechanism that says "if ASDF has changed its package structure, you must recompile." I understand the original motivation for subdividing the packages, but I think in future we need to be careful not to do this without an explicit plan to ensure it doesn't cause this kind of bug. It's an interesting unforeseen issue in the plan to be able to upgrade ASDF -- you need also to be able to downgrade! I.e., if I want to be able to test new ASDF, I may still need to work with colleagues who are using an older, implementation-provided version. For now, I can simply blow away my cache, and I expect that will solve the problem, but it's something to consider. thanks, r

2 1

patch for allegro8 (was: Re: [asdf-devel] Ready to release?)
by Dave Cooper 08 Apr '15

08 Apr '15

Here is a patch to add the allegro 8-bit character executables to the test cases in run-tests.sh. Also here is an updated version of my little "run" script (which is to be used in the parent of the asdf/ directory) which now automatically sets the executables based on the running OS. I'm still having intermittent failures of test-encodings.script on mlisp8.exe, and test-stamp-propogation.script on alisp8.exe. These may be spurious failures because when I run them with a clean build/ directory, they seem to pass. If I can get them to fail reliably I will report it otherwise I don't want to hold up the release because of this. Best Regards Dave Let's go Tigers! On Thu, Oct 17, 2013 at 4:59 PM, Dave Cooper <david.cooper(a)genworks.com>wrote: > > On Thu, Oct 17, 2013 at 4:41 PM, Faré <fahree(a)gmail.com> wrote: > >> >> Do you have a transcript for the remaining failure with test-encodings >> on mlisp8 or such? >> >> > > I don't. I re-ran the tests a few times and could not reproduce the > failure. I'll run everything from the top with a fresh build/ directory a > bit later, with your test-utilities.script workaround, and see if any of > the failures pop up again. > -- 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 23

[asdf-devel] Pushed version 3.1.0.52 -- first version with checks for OPERATION subclasses -- please test!
by Robert P. Goldman 08 Apr '15

08 Apr '15

If you have any systems that define their own subclasses of OPERATION, *please* pull this update and test. This new version checks to see if OPERATION classes have been updated to adapt to Fare's refactoring of the OPERATION class hierarchy. In a nutshell, Fare has added MIXIN subclasses of OPERATION that control the propagation of dependencies. These new subclasses are DOWNWARD-OPERATION UPWARD-OPERATION SIDEWAY-OPERATION and SELFWARD-OPERATION To these, I have added NON-PROPAGATING-OPERATION. New subclasses of OPERATION will be checked to see if they inherit from one of the above classes, and if they do not, ASDF will signal an error. Fixes for this error should look something like this: (defclass my-operation (OPERATION) ...) should turn into something like (defclass my-operation (#-asdf3 OPERATION #+asdf3 DOWNWARD-OPERATION) ...) with DOWNWARD-OPERATION being replaced by whatever is/are the appropriate dependency (non-)propagating class(es). I hope to add a page or two to the Texinfo documentation to provide more information before the final release. Best, R

6 30

[asdf-devel] Re: Bug#723977: missing symlink in /usr/share/common-lisp/systems
by Faré 08 Apr '15

08 Apr '15

(Adding asdf-devel to the recipients — the problem is wrong (asdf::default-source-registry) when XDG_DATA_DIRS is empty.) Well, ASDF ought to have worked even in absence of XDG_DATA_DIRS, and you discovered a genuine bug in ASDF. It turns out, split-string was not designed to return correct results when passed either NIL or "", and this caused ASDF to fail to treat the default properly for XDG_DATA_DIRS. I've pushed a fix as ASDF 3.0.2.9, but that's a pretty bad bug you've discovered, which defeats the default configuration. Robert: when do you instead to release 3.0.3 ? Otherwise, I could do a Debian package for 3.0.2.9. (PS: I took the liberty of also committing my load-systems* patch). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A competent and self-confident person is incapable of jealousy in anything. Jealousy is invariably a symptom of neurotic insecurity. — Robert Heinlein, "Time Enough For Love" On Mon, Sep 23, 2013 at 1:05 AM, Diogo F. S. Ramos <diogofsr(a)gmail.com> wrote: >> 1- what does env return? > > I think the problem lies here. > > My environment does not export XDG_DATA_DIRS. If I try it inside gnome, > which exports it, everything works nicely. > > According to the XDG Base Directory Specification[1], if XDG_DATA_DIRS is > empty or not set, the defaults should be used. More specifically: > > $XDG_DATA_DIRS defines the preference-ordered set of base directories > to search for data files in addition to the $XDG_DATA_HOME base > directory. The directories in $XDG_DATA_DIRS should be seperated with > a colon ':'. > > If $XDG_DATA_DIRS is either not set or empty, a value equal to > /usr/local/share/:/usr/share/ should be used. > > Maybe something in the stack is not implementing this characteristic of > XDG. > > [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html >

3 3

[asdf-devel] Re: software failures (with asdf 3?)
by Faré 08 Apr '15

08 Apr '15

On Sun, Jul 7, 2013 at 8:12 AM, Zach Beane <xach(a)xach.com> wrote: > I upgraded my dist construction system to asdf 3.0 and get these > failures: > > - exscribe: Don't know how to normalize (:FEATURE :EXSCRIBE-TYPESET > :CL-TYPESETTING). More info at > http://report.quicklisp.org/exscribe/2013-07-07/failtail.txt > Exscribe is working well for me. The :FEATURE feature is an ASDF feature that was simultaneously broken and undocumented in late ASDF1, has been fixed but cerror'ed during the ASDF 2 days, and fixed and tested to work before ASDF3 (test in place since 2.31.2). Your backtrace suggests that the error happens in a package called DEPCHECK, that doesn't know about this feature. I suppose you wrote that package and need to teach it about :FEATURE. That's where I realize that the :FEATURE feature is quite misdocumented in the asdf.texinfo in the grammar production "dependency-def" (as opposed to the very different, documented but deprecated feature in "requirement"). Oh well. Not my problem anymore. Robert, you might want to look into this: * in dependency-def, it should be (:feature @var{feature-expression} @var{dependency-def}) * the required-op production is redundant, since it's better covered by the second branch of requirement. * have a quick look at find-component.lisp to make sure the grammar is properly documented; maybe document the new extensible protocol for naming components. > - cl-launch: Could not load ASDF 2.27. More info at > http://report.quicklisp.org/cl-launch/2013-07-07/failtail.txt > Looks like you're using cl-launch 3.21.3 or earlier. Please upgrade to the latest 3.22, available since last May (actually same as 3.21.7 from February). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There is never a better measure of what a person is than what he does when he's absolutely free to choose." — William M. Bulger

2 3

[asdf-devel] ASDF 3.0.3 released
by Robert Goldman 08 Apr '15

08 Apr '15

Dear Lisp hackers, I am pleased to announce the release of ASDF 2.26. Since previous release 2.25, the changes are as follows: * Run-program much improved, with a slight backward incompatibility. See the new documentation about it. * Portability enhanced, with more robust Windows support, plus patches for CCL, CLISP, LispWorks, XCL. * UIOP improved, with a README, more docstrings, a few new functions (println, writeln, stripln, ensure-gethash, vomit-output-stream), and bugfixes (to ensure-function, with-temporary-file, split-string). * Debian installations that don't export XDG_DATA_DIRS will benefit from the fix to split-string, as the bug was basically disabling the default source-registry entry for /usr/share/common-lisp/source// Closes: #723977 * Minor tweaks to the defsystem, mostly to print more information in some situations, less in other situations, but also to better handle systems with secondary names like foo/bar, a fix for user functions in output-translation, and to :version (:read-file-...) * Documentation somewhat updated. This is a very substantial bug fix release, notably on Windows, but has a stable API wrt the previous version. For this reason, CL implementations are strongly encouraged to replace previous bundled versions with 3.0.3. As always, thanks to Faré for what seems like a countless number of fixes. Thanks to Dave Cooper for many hours of testing on Windows, without whom the improvements on that platform would have been impossible. Work will soon begin on the 3.1.0 series, with some additional API features, so please make sure to pull a copy of 3.0.3 instead of the bleeding edge when you are bundling. Best, Robert

4 3

[asdf-devel] optimization settings
by Robert Brown 08 Apr '15

08 Apr '15

Does ASDF set compiler optimization settings before compiling each file when building? I'm concerned that changing the optimization setting inside one source file could cause the change to stick and be used for other files. I don't think the CL standard mandates that "(declaim (optimize ... ))" applies only to the current file. The issue is similar to that of readtables ... Bob

4 6

[asdf-devel] Anyone having trouble with working copies of doc/index.html?
by Robert Goldman 08 Apr '15

08 Apr '15

I am getting repeated pull failures with this error: error: unable to unlink old 'doc/index.html' (Permission denied) Anyone else seeing that? I'm just wondering because the obvious fixes (cf. StackOverflow) don't work for me. Even rebooted to make sure there wasn't anything holding the file open. No joy. Also, every failure to pull leaves me with spurious uncommitted changes in my working copy. If this is just my problem, I'll work it out, but I was wondering if the repo was somehow messed up. Cheers, r -- Robert P. Goldman Principal Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman(a)SIFT.net

2 1

[asdf-devel] Tiny patch for cmucl print-herald
by Raymond Toy 08 Apr '15

08 Apr '15

Not sure how useful this would be, but it would be nice if images that contained asdf could display the asdf version on startup on cmucl. Anyway, here is the necessary change to allow cmucl to print out the adsf version when the startup banner is printed. Ray (setf (getf ext:*herald-items* :asdf) `(,#'(lambda (stream) (write-string " ASDF " stream) (write-string asdf::*asdf-version*))))

2 9