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

Re: [asdf-devel] Cannot use latest git ECL (asdf/quicklisp are involved)
by Robert Goldman 08 Apr '15

08 Apr '15

Didier Verna wrote: > Robert Goldman <rpgoldman(a)sift.info> wrote: > >> Can you get a backtrace from the failed call to delete the directory? > > OK. So I restarted ecl -norc and then did a (load ".clrc") with the > contents mentioned in my previous message. This is what I get. FWIW, > the directory in which UIOP is trying to delete the non-existent > asdf.fas file contains 2 files: asdf.o and asdf-ASDF-TMP.fas. Thanks, Didier. Would you please file a launchpad ticket? I am afraid I cannot be very helpful in the near future -- my neighborhood lost power last Friday in a storm, so I am having a bit of trouble staying on top of things. The name of Faré's function (delete-file-if-exists) suggests that Faré expects the deletion to fail gracefully, instead of raising an error. He attempts to catch a FILE-ERROR there. I note that ECL seems to be raising a SIMPLE-ERROR instead of a FILE-ERROR. The hyperspec states of DELETE-FILE: If the deletion operation is not successful, an error of type file-error is signaled. So if ECL is raising a SIMPLE-ERROR instead, that would be a bug in ECL, and not in ASDF. One thing that seems odd is that it seems ECL is claiming that it's asked to delete a directory, not a file. Can you trap the argument to DELETE-FILE-IF-EXISTS? Best, r > > > didier(pts/1)% ecl -norc 14:48 06/24/13 > ECL (Embeddable Common-Lisp) 12.7.1 (git:52ca46e054d72cb0b0802e376890fcfbdfc96e5a) > Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya > Copyright (C) 1993 Giuseppe Attardi > Copyright (C) 2000 Juan J. Garcia-Ripoll > ECL is free software, and you are welcome to redistribute it > under certain conditions; see file 'Copyright' for details. > Type :h for Help. > Top level in: #<process TOP-LEVEL>. >> (load ".clrc") > > ;;; Loading #P"/home/didier/.clrc" > ;;; Loading "/usr/local/share/common-lisp/source/asdf/build/asdf.lisp" > > Condition of type: SIMPLE-ERROR > Cannot delete the directory #P"/home/didier/.cache/common-lisp/ecl-12.7.1-52ca46e0-linux-x86/usr/local/share/common-lisp/source/asdf/build/asdf.fas". > C library explanation: No such file or directory. > Available restarts: > > 1. (RETRY) Retry compiling #<cl-source-file "asdf" "build" "asdf">. > 2. (ACCEPT) Continue, treating compiling #<cl-source-file "asdf" "build" "asdf"> as having been successful. > 3. (RESTART-TOPLEVEL) Go back to Top-Level REPL. > > Broken at UIOP/FILESYSTEM:DELETE-FILE-IF-EXISTS. In: #<process TOP-LEVEL>. > File: #P"/usr/local/share/common-lisp/source/asdf/build/asdf.lisp" (Position #139589) >>> :b > > Backtrace: > > UIOP/FILESYSTEM:DELETE-FILE-IF-EXISTS > > uiop/lisp-build:compile-file* > > lambda > > uiop/utility:call-with-muffled-conditions > > uiop/lisp-build:call-with-muffled-compiler-conditions > > lambda > > uiop/utility:call-function > > uiop/lisp-build:call-around-hook > > lambda > > asdf/lisp-action:perform-lisp-compilation > > lambda > > lambda > > lambda > > lambda > > lambda > > lambda > > call-next-method > > lambda > > asdf/cache:call-with-asdf-cache > > asdf/find-system::call-with-system-definitions > > lambda > > lambda > > call-next-method > > lambda > > asdf/cache:call-with-asdf-cache > > asdf/find-system::call-with-system-definitions > > lambda > > asdf/operate:load-system > > uiop/package:symbol-call > > asdf/upgrade:upgrade-asdf > > lambda > > asdf/operate:oos > > si:bytecodes [Evaluation of: (let ((*compile-print* nil) (*compile-verbose* nil) (*load-verbose* nil) (*load-print* nil)) (asdf/operate:oos 'asdf/lisp-action:load-op "quicklisp" :verbose nil))] > > si:bytecodes [Evaluation of: (let ((quicklisp-init "/usr/local/share/common-lisp/source/quicklisp/setup.lisp")) (when (probe-file quicklisp-init) (load quicklisp-init)))] > > si:bytecodes [Evaluation of: (load ".clrc")] > > si:bytecodes [Evaluation of: (si:top-level t)] > >

1 0

[asdf-devel] Structure of ASDF directory
by Robert Goldman 08 Apr '15

08 Apr '15

I was wondering if it would be possible to bump the uiop.asd file up to be a sibling of asdf.asd. It seems odd to me that asdf.asd is at the top level, and has build/asdf.lisp under it, but that uiop.asd is in uiop/. Odd + it means I need now to do (push "home:lisp;asdf;" asdf:*central-registry*) and (push "home:lisp;asdf;uiop;" asdf:*central-registry*) to upgrade.... Any reason why uiop.asd couldn't be at the top level? thanks, r

2 1

[asdf-devel] using uiop standalone
by Anton Vodonosov 08 Apr '15

08 Apr '15

Hello. If I want to use uiop tools, for example run-program, can I use the newest uiop without upgrading ASDF, or it should be only used with corresponding ASDF version? I mean, uiop is included in Quicklisp, I can add :depends-on uiop, but will it affect the ASDF version shipped with my CL implementation? Is it safe to load new uiop with any ASDF? BTW, is the uiop-3.0.3.tgz included into the recent Quicklisp 2014-02-11 is the latest version of uiop? Best regards, - Anton

2 1

[asdf-devel] Yes proglogue and epilogue is used!
by Jean-Claude Beaudoin 08 Apr '15

08 Apr '15

Hello Faré, Yes the prologue and epilogue is (or will be, in the publicly and officially sanctioned ASDF-way once I send you my small MKCL mods for ASDF 3) used after all. Maybe not really by ECL, although it should, but by MKCL. It is an essential part of the program-op processing. You are right about the fact that prologue and epilogue are not very well designed as they stand in ECL (and how MKCL inherited them from ECL). But they really make sense if they are considered in the context of #'compiler:build-program. I would even say that they are essential in the context of #'compiler:build-program. I am currently putting the finishing touch to ASDF 3.0.3 on MKCL 1.1.7 on Windows (3 more tests to fix). I should be done somewhat shortly and after that I'll sent the ASDF list what I have got, merged with ASDF head. Sorry if I could not reply to your ecls-list messages more promptly but I was out all day participating in a double fencing tournament. I did basically a somewhat marathon-like 8 hours straight of competitive épée, so I hope you will understand if I stand a bit out of phase with my computer keyboard for a few more hours while I try to recover. Cheers, Jean-Claude Beaudoin

2 1

[asdf-devel] Further customization of output translations
by Stelian Ionescu 08 Apr '15

08 Apr '15

How would I go about including the git branch in the output directory name ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

3 2

[asdf-devel] Quick question about the bundle op
by Robert P. Goldman 08 Apr '15

08 Apr '15

I see that the BUNDLE-PATHNAME-TYPE for :dll is "so" on all unixes. Question: should this be "dylib" on Mac OS X instead? Thanks, r

2 1

[asdf-devel] current failures for CCL Windows and SBCL Windows
by Dave Cooper 08 Apr '15

08 Apr '15

Here are the output text files for these platforms, currently: SBCL: https://www.dropbox.com/s/lky1wlz0o1ku7qt/sbcl.text CCL: https://www.dropbox.com/s/ptoor8nepik85by/ccl.text What else should I be testing for Windows?

1 0

[asdf-devel] 3.0.2.7 follows hot on the heels of 3.0.2.6
by Robert P. Goldman 08 Apr '15

08 Apr '15

Faré points out that /usr/bin/env can only be used on Unix.... Patch pushed!

1 0

[asdf-devel] Are there nightly builds for trunk sources? (was: Re: CCL Windows: output from ccl:fasl-concatenate is "not a FASL file")
by Genworks Support 08 Apr '15

08 Apr '15

So this has been fixed (almost immediately after I opened the Trac ticket http://trac.clozure.com/ccl/ticket/1109!) in the trunk in: http://trac.clozure.com/ccl/changeset/15892 Now I am wondering how often the binaries (e.g. wx86cl.exe) in http://svn.clozure.com/publicsvn/openmcl/trunk/windows/ccl get rebuilt? Is there a nightly build so that I can simply do an svn update on this, or is it time to get set up with gcc on Windows and perform the Windows build of the trunk myself, in order to test this? Regards, Dave On Wed, Sep 4, 2013 at 4:36 PM, Dave Cooper <david.cooper(a)genworks.com>wrote: > > So I'm trying to get the ASDF test suite running on Windows, and tracked > this down as one of the failures for CCL (32-bit and 64-bit). (there were 5 > failures out of 47 tests, I haven't looked at the rest yet). > > This can be replicated as follows (with files from > > https://www.dropbox.com/sh/jc2cqwpkp06dupm/7lgyRUdwZ5/cl/tests/simple > ): > > > [below, substitute ".../'" for your actual path to the test files]: > > > > (lisp-implementation-version) > "Version 1.9-r15765 (WindowsX8664)" > > > (compile-file ".../try1") > > > (compile-file ".../try2") > > > (ccl:fasl-concatenate ".../try.wx64fsl" (list ".../try1.wx64fsl" > ".../try2.wx64fsl")) > > > (load ".../try.wx64fsl") > > ERROR: Not a FASL file. > > > Does anyone recognize what might be going on? > > > -- > 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 > -- 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

1 0

[asdf-devel] Checking system names...... NOT
by Robert P. Goldman 08 Apr '15

08 Apr '15

Faré and James Anderson have convinced me I'm tilting at windmills here. I am in the process of reverting the checks and testing the results to make sure that I haven't messed up in the reversion process. Look for a 3.1.0.76 as soon as I'm sure the tests all pass. Bloodied, but unbowed, R

1 0