asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

Almost there
by Faré 16 Jul '15

16 Jul '15

Dear lispers, we're ready to bless ASDF 3.1.4.25 as release 3.1.5, and now is a good time to test it before it's too late. Anton, do you have time and/or resource for a run of cl-test-grid? Nothing should have changed in the semantics of ASDF itself since the last run of cl-test-grid, so I don't expect any discrepancy. We did add better immutable-system support thanks to Dave Cooper, but that isn't cover by cl-test-grid, only by our regression tests and his usage. What we did change was to make UIOP more robust and portable. Robert Goldman and I, with the help of Dave Cooper, ran extensively tests. We have notably debugged a lot of pathname and run-program issues on Windows. These issues recently cropped up since we have added a lot of tests since last release, and since neither of us is a Windows user, they had previously only been run on Unix. We also made an important compatibility fix for SBCL, added CLASP support, enhanced support for new LispWorks 7, fixed chdir for ABCL and XCL. As far as I'm concerned, this means that portable scripting in Common Lisp is more a reality than ever. If you are careful, you can write portable CL code that runs as is on Unix (including Linux and MacOS) and Windows. As usual, the more portable you want to be, the more careful you have to be; but at least UIOP covers all the bases with a reasonable portable interface (please don't use anymore any of cl-fad, trivial-shell, run-shell-command, trivial-backtrace; use uiop). I recommend CCL for a portable scripting implementation, because SBCL on Windows isn't quite as good (and is not able to call out to CMD.EXE) and CLISP has too many quirks (and is looking for a new maintainer to release it anew after 5 years). For examples of scripting in CL, see https://github.com/fare/fare-scripts —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a country where the sole employer is the State, opposition means death by slow starvation. The old principle: who does not work does not eat, has been replaced by a new one: who does not obey shall not eat. — Leon Trotsky

8 27

Finding all the systems that subclass
by Javier Olaechea 09 Jul '15

09 Jul '15

Hi, I'm trying to find all the systems that use a particular subclass of system. The goal is that through that mechanism they signal/register themselves as modules of another system. In order to list all such modules I though map-systems would do the trick: (remove-if #'null (let (results) (asdf:map-systems (lambda (system) (when (stumpwm-module-p system) (setf results (cons system results))))) results)) However it appears map-systems only works on when the system *definition* has been loaded (is that the proper term?). Is there a way to load all the system definitions in asdf's path? (That is according to *source-registry* and *central-registry*) Cheers, Javier -- "I object to doing things that computers can do." — Olin Shivers

2 1

Editing component being compiled when compilation failed.
by 73budden . 08 Jul '15

08 Jul '15

Hi! I still don't know what is the official way to edit component being compiled. I asked at comp.lang.lisp but had no reply. But I have developed my own solution. For this I had to redefine several asdf functions. I bind special variables so that current component is known at the time of compilation. Also I define asdf::e and asdf::ep symbol macros that access special variables. When compilation fails, I have an EDIT-COMPONENT restart, which is not needed - it is just a help string. Then user should eval asdf::e in the debugger to edit component source. User should eval asdf::ep in the debugger to edit component's system source. Code is here, it shoud work in asdf-3.1.4 under lispworks 6 or under SBCL+SLIME. https://bitbucket.org/budden/budden-tools/src/866bcf15ad5c793868a0a31e60247… I'd like to receive any feedback.

3 6

Note to myself
by Robert Goldman 08 Jul '15

08 Jul '15

I have a note to myself to remove SOURCE-FILE-TYPE from the manual, and I see that it's there just for backwards compatibility. Am I correct in saying that this should be replaced by COMPONENT-TYPE? That's what the comment says, but then I see this: (defmethod source-file-type ((component file-component) (system parent-component)) (file-type component))) which suggests FILE-TYPE, not COMPONENT-TYPE is The Right Thing. Also, what the heck is the return type of this? I see the following: (defmethod source-file-type ((component parent-component) (system parent-component)) :directory) which suggests that it's something like (or string (eql :directory)). Ugh. Shouldn't asking for the file-type of a PARENT-COMPONENT simply be an error? Sorry to bother you about this: just trying to kill something that's languished on my todo list for more than a year. cheers, r

2 2

Testing running subsidiary lisps with multiple Allegros
by Robert Goldman 07 Jul '15

07 Jul '15

How is this to be managed? In the test suite, there are environment variables that signal which of the many Allegro flavors one is testing. But somehow this information needs to get pushed through the tests into the subsidiary lisp-invocations. How is this managed? Thanks, r

4 4

Tests ran overnight
by Robert Goldman 07 Jul '15

07 Jul '15

...not on Windows, I'm afraid: my automation isn't up to that yet. But all tests passed on Mac OS X. On linux, though, I got the following: Unexpected test failures on these implementations: build/results/allegro8-test.text build/results/allegromodern8-test.text build/results/allegromodern-test.text build/results/allegro-test.text build/results/cmucl-test.text For Allegro, I see test-program failing: TEST ABORTED: In (GETENV-PATHNAME "ALLEGRO"), invalid pathname #P"alisp8/": Expected an absolute pathname Evaluation stack: Warning: while extracting symbols from /lib/i386-linux-gnu/librt.so.1: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libm.so.6: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libdl.so.2: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libc.so.6: couldn't find .symtab section Warning: while extracting symbols from /lib/ld-linux.so.2: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libnss_files.so.2: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libnss_compat.so.2: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libnsl.so.1: couldn't find .symtab section Warning: while extracting symbols from /lib/i386-linux-gnu/libnss_nis.so.2: couldn't find .symtab section Above backtrace due to this condition: In (UIOP/FILESYSTEM:GETENV-PATHNAME "ALLEGRO"), invalid pathname #P"alisp/": Expected an absolute pathname The .symtab errors imply we are trying to build a program assuming a 32-bit execution model, instead of a 64-bit one. I have had this problem on Allegro before. I see that warning on allegro8-test.text, allegromodern-test.text, allegromodern8-test.text, but not on allegro-test.text. That's my fault, because I replaced my old 32-bit license with a 64-bit one, and it looks like there's some way to find the old license. This is a potential real issue, though: we have often found problems linking with C code on Allegro when we have only 32-bit Allegro on a 64-bit platform. It's getting less and less common to rig up one's 64-bit linux box with a full 32-bit build environment as well as the 64-bit one. CMUCL has a different error: stderr: This is make-hello-world, testing its stderr. 0: RUN-PROGRAM returned NIL NIL 0 - then use this executable image 0: (RUN-PROGRAM ("/home/rpg/common-lisp/asdf/build/fasls/cmu-20f___20f_unicode_-linux-x86/asdf/test/hello-world-example--all-systems.image" "-quiet" "-noinit" "-batch" "-eval" ...) :OUTPUT :LINES :ERROR-OUTPUT ...) 0: RUN-PROGRAM returned ("hello, world") NIL 0 - now, use this executable image with arguments 0: TEST ABORTED: Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: #<Function EQ {100138F1}> is not of type SEQUENCE 0: (DEBUG:BACKTRACE 69 #<Synonym Stream to SYSTEM:*STDOUT*>) 1: (UIOP/IMAGE:RAW-PRINT-BACKTRACE :STREAM #<Synonym Stream to SYSTEM:*STDOUT*> :COUNT 69 :CONDITION #<unused-arg>) 2: ("WITH-UPGRADABILITY NIL") 3: ("WITH-UPGRADABILITY NIL") 4: (LISP::%WITH-STANDARD-IO-SYNTAX #<Closure Over Function "WITH-UPGRADABILITY NIL" {585234D1}>) 5: (UIOP/IMAGE:PRINT-CONDITION-BACKTRACE #<TYPE-ERROR {5850089D}> :STREAM #<Synonym Stream to SYSTEM:*STDOUT*> :COUNT 69) 6: (NIL #<TYPE-ERROR {5850089D}>) 7: (NIL #<TYPE-ERROR {5850089D}>) 8: (SIGNAL #<TYPE-ERROR {5850089D}>) 9: (ERROR TYPE-ERROR :FUNCTION-NAME REVERSE :DATUM #<Function EQ {100138F1}> :EXPECTED-TYPE SEQUENCE) 10: (KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER REVERSE #<System-Area-Pointer: #x3FFFB864> #<Alien (* SYSTEM:SYSTEM-AREA-POINTER) at #x3FFFB40C> (144 16)) 11: (KERNEL::INTERNAL-ERROR #<System-Area-Pointer: #x3FFFB40C> #<unused-arg>) 12: ("call_into_lisp+#x74 [#x8059750] /usr/local/bin/cmucl") 13: ("funcall2+#x2C [#x805927C] /usr/local/bin/cmucl") 14: ("interrupt_internal_error+#x7A [#x805201A] /usr/local/bin/cmucl") 15: ("sigtrap_handler+#x183 [#x8059593] /usr/local/bin/cmucl") 16: (REVERSE 1 #<Function EQ {100138F1}>)[:EXTERNAL] 17: (DEBUG::PRINT-FRAME-CALL-1 #<Compiled-Frame UIOP/RUN-PROGRAM:RUN-PROGRAM>) 18: (DEBUG::PRINT-FRAME-CALL #<Compiled-Frame UIOP/RUN-PROGRAM:RUN-PROGRAM> :PRINT-LENGTH NIL :PRINT-LEVEL NIL :VERBOSITY 1 :NUMBER NIL) 19: ("DEFUN TRACE-START-BREAKPOINT-FUN" #<Compiled-Frame UIOP/RUN-PROGRAM:RUN-PROGRAM> #<unused-arg>) 20: (DEBUG-INTERNALS::INVOKE-BREAKPOINT-HOOKS (#<Breakpoint UIOP/RUN-PROGRAM:RUN-PROGRAM:FUNCTION-START> #<Breakpoint UIOP/RUN-PROGRAM:RUN-PROGRAM:FUNCTION-START>) #<Code Object "WITH-UPGRADABILITY NIL" {581163D7}> 617) 21: (DEBUG-INTERNALS::HANDLE-BREAKPOINT-AUX (#<Breakpoint UIOP/RUN-PROGRAM:RUN-PROGRAM:FUNCTION-START> #<Breakpoint UIOP/RUN-PROGRAM:RUN-PROGRAM:FUNCTION-START>) #<Breakpoint-Data UIOP/RUN-PROGRAM:RUN-PROGRAM at 617> 617 #<Code Object "WITH-UPGRADABILITY NIL" {581163D7}> #<System-Area-Pointer: #x3FFFBF4C>) 22: ("call_into_lisp+#x74 [#x8059750] /usr/local/bin/cmucl") 23: Above backtrace due to this condition: Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: #<Function EQ {100138F1}> is not of type SEQUENCE Script failed I'm not seeing an obvious explanation for this failure. Looks like it would be some kind of place where EQ appears in the wrong position, but the backtrace is unhelpful, and I don't know how to work through all the intricacies of LISP-INVOCATION. When I try to make this run at the command line, I fail as follows: > cmucl -core /home/rpg/common-lisp/asdf/build/fasls/cmu-20f___20f_unicode_-linux-x86/asdf/test/hello-world-example--all-systems.image Invalid magic number: 0x464c457f should have been 0x434f5245. ...but that seems like a different error, since the above transcript seems to suggest that the lisp invocation worked, but then we tried to test some result and encountered an error.

2 1

:require dependency
by Didier Verna 29 Jun '15

29 Jun '15

Hello, can somebody explain to me what is the :require dependency specification, and how it compares to just a simple-component-name ? Thanks. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info

2 3

Problem with ACL on windows & proposed fix
by Robert Goldman 28 Jun '15

28 Jun '15

Sorry -- I've been traveling, so sat on this bug report for a while. Here's a test failure from Windows ACL. Looks like ACL is somehow not running the windows CWD program helper (which should invoke CMD.EXE), but instead is just taking the command and treating it as its own output. the other expression (ASDF-TEST::GETCWD-FROM-RUN-PROGRAM) yields that: #P"%cd%\\" (:HOST NIL :DEVICE NIL :DIRECTORY (:RELATIVE "%cd%") :NAME NIL :TYPE NIL :VERSION :UNSPECIFIC) This comes from: (defun getcwd-from-run-program () (uiop:parse-native-namestring (nest ;; TODO: fix run-program to use POWERSHELL.EXE rather than CMD, and remove this kluge. #+os-windows (string-trim " ") (run-program (os-cond ((os-unix-p) '("pwd" "-P")) ((os-windows-p) "echo %cd%")) :output '(:string :stripped t))) :ensure-directory t)) RUN-PROGRAM on Allegro invokes RUN-SHELL-COMMAND, about which their documentation says: "This function, originally written and named for Unix machines, is badly misnamed for Windows, because on Windows, you can only run programs. Shell commands, such as dir, are not acceptable as a value of the command argument. See below in this entry for discussion on this point." Looking below, I see: "On Windows the name of the shell is cmd.exe. Here is an example of using run-shell-command on Windows: (run-shell-command "cmd /c start \"c:\\Program Files\\\"") which suggests we should modify %NORMALIZE-COMMAND for Allegro to prepend "CMD /C " to all commands when on windows. I'll test this myself the next time I get into the office, but that might not be till Monday afternoon. Or I might get lucky and find that I can remotely access my windows VM.... Best, r

4 8

Test failures on Windows
by Robert Goldman 24 Jun '15

24 Jun '15

I'm having some real oddities testing on Windows. Attached is a roster of the implementations for which I see test failures -- the Allegro variants and clisp. Two oddities: 1. I do not get verbose output showing what happens when the tests fail. Critical information is missing from the logfiles. I suspect that the test script assumes that standard output is redirectable in some way that it is not on Windows. See allegro-test.txt which is attached. Any idea how to get the lisp output? Any chance that REDIRECT-OUTPUTS function from script-support.lisp does not work on Allegro + Windows? 2. I get fewer failures running one test at a time than running them all in make. Allegro testing reported the following: -#--------------------------------------- Using g:/windows/allegro/32/non-smp/alisp Ran 56 tests: 52 passing and 4 failing failing test(s): test-encodings.script test-program.script test-try-refinding.script test-utilities.script -#--------------------------------------- But when I run the tests individually, only test-program and test-utilities failed. The other two tests succeeded. I have rarely seen something like this before in make on Unix variants due to not cleaning up the filesystem, but never in such a wholesale way. ---- Trying not to be a Unix bigot, but failing.... Best, R

3 5

Fwd: why is usocket.asd without an in-package or package qualifiers?
by Faré 16 Jun '15

16 Jun '15

Robert, should we export load-asd from asdf? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If Java had true garbage collection, most programs would delete themselves upon execution. — Robert Sewell ---------- Forwarded message ---------- From: Mark H. David <mhd(a)yv.org> Date: Tue, Jun 16, 2015 at 3:05 PM Subject: Re: why is usocket.asd without an in-package or package qualifiers? To: Zach Beane <xach(a)xach.com> Cc: usocket development <usocket-devel(a)common-lisp.net> Well, ASDF doc (here: https://common-lisp.net/project/asdf/asdf/The-defsystem-form.html) is not that clear about this. It shows an example .asd file, which does have an in-package, albeit to package asdf-user, and says of it: The file starts with an in-package form for package asdf-user. Quick summary: just do this, because it helps make interactive development of defsystem forms behave in the same was as when these forms are loaded by ASDF. ... The in-package form will ensure that the system definition is read the same as within ASDF when you load it interactively with cl:load. However, we recommend that you load .asd files through function asdf::load-asd rather than through cl:load, in which case this form is unnecessary. Don't mean to hijack usocket for ASDF complaints, but shouldn't asdf::load-asd be exported? Thanks, Mark ----- Original message ----- From: Zach Beane <xach(a)xach.com> To: "Mark H. David" <mhd(a)yv.org> Cc: usocket development <usocket-devel(a)common-lisp.net> Subject: Re: why is usocket.asd without an in-package or package qualifiers? Date: Tue, 16 Jun 2015 14:54:36 -0400 ASDF establishes a particular environment when using asdf:find-system and asdf:load-system that is not duplicated by a plain CL:LOAD. It has always been this way. You cannot reliably use CL:LOAD to load a system file and have things work. Zach On Tue, Jun 16, 2015 at 2:50 PM, Mark H. David <mhd(a)yv.org> wrote: I notices there's no in-package or qualifiers present in usocket.asd. So you have to, it seems, do (in-package :asdf) or similar before loading this file. Is there any good reason for this? I was thinking of fixing this and doing a pull request. Anyone against? Thanks, Mark

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel