asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

[asdf-devel] Loading an .asd file directly using its pathname
by Luís Oliveira 08 Apr '15

08 Apr '15

Hello, Given a pathname to an .asd file, I sometimes load it using this hack: (defun load-asd (path &rest options) (let ((asdf:*system-definition-search-functions* (cons (lambda (system) (when (string= (asdf::coerce-name system) (pathname-name path)) path)) asdf:*system-definition-search-functions*))) (apply #'asdf:load-system (pathname-name path) options))) Other times I use: (let ((asdf:*central-registry* (cons <directory-where-my-asd-lives> asdf:*central-registry*))) (asdf:load-system :some-system)) Also, I see that the slime-asdf contrib uses this definition: (defun load-asd (pathname &key name &allow-other-keys) (asdf::load-sysdef (or name (string-downcase (pathname-name pathname))) pathname)) I wonder if ASDF could export LOAD-SYSDEF or perhaps have ASDF:LOAD-SYSTEM accept a pathname in addition to what it currently accepts. Cheers, -- Luís Oliveira http://kerno.org/~luis/

5 9

[asdf-devel] cl-launch 4.0.0
by Faré 08 Apr '15

08 Apr '15

Dear lispers, I've just released cl-launch 4.0.0: so you can invoke CL programs from the command-line. My classic demo for cl-launch is as follows: for l in allegro ccl clisp sbcl ecl lispworks abcl cmucl xcl gcl ; do cl-launch -l $l -i '(format t "'$l' ~S ~%" `#5(1 ,@`(2 3)))' 2>&1 | grep "^$l " ; done As compared to the cl-launch 3 series, cl-launch 4.0.0: * cl-launch now accepts Unix scripting language invocation: cl-launch [options...] script [arguments...] * Therefore cl-launch can be used as a script interpreter: #!/usr/bin/cl No more need for -X ... -- options anymore (still kept for compatibility). * cl-launch has a more unrestricted model for building software, more like buildapp, executing build commands in sequence, rather than having a fixed skeleton of one file then one system. cl --lisp sbcl --require sb-posix --system foo --file file.lisp --eval '(some form)' --output myscript.sh cl --lisp sbcl --require sb-posix --system foo --file file.lisp --eval '(some form)' --output mybinary --dump '!' * cl-launch accepts --eval --load --load-system --entry like buildapp, in addition to its own --restart --init --print --write, etc. * cl-launch accepts an argument starting with an open parenthesis in any position as if it were following a --print. * cl-launch can now use quicklisp * cl-launch was tweaked to work better on ABCL, GCL, ECL cl-launch 4 is thus mostly compatible with cl-launch 3 and earlier, but: * it requires asdf 3.0.1 or later to be provided by your implementation, configured to be found by an earlier asdf provided by your implementation, or in ~/cl/asdf/ or /usr/share/common-lisp/source/cl-asdf/ * cl-launch used to have a more constrained model for building software with only one --file and one --system; if you were relying on that and/or on putting the --file after the --system, you will suffer from the incompatibility. PS: there is already a 4.0.0.1 for LispWorks, which requires a patch just pushed to ASDF 3.1.0.78. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wealth, like happiness, is never attained when sought after directly. It comes as a by-product of providing a useful service. — Henry Ford

1 0

[asdf-devel] Problems with asdf:load-system :force
by Stelian Ionescu 08 Apr '15

08 Apr '15

While working on the test suite of swap-bytes on SBCL(you'll need >=1.1.6 I think), I noticed two unexpected results in using :force : 1) (asdf:load-system :swap-bytes/test :force t) does not recurse into :defsystem-depends-on deps. Is this intentional ? 2) (asdf:load-system :swap-bytes/test :force '(:swap-bytes/test)) needlessly compiles files from :swap-bytes on which it depends. I've attached a log that traces PERFORM and COMPUTE-ACTION-STAMP and shows that two files from :swap-bytes get recompiled even though they haven't changed. I'm wondering if the problem lay with the ASDF extension in Madeira-port, but that's so simple I can't find any obvious fault. Ideas ? If you want to test for yourselves clone https://github.com/sionescu/madeira-port.git and https://github.com/sionescu/swap-bytes.git -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

2 12

Re: [asdf-devel] testing uiop:enable-deferred-warnings-check with cl-test-grid
by Anton Vodonosov 08 Apr '15

08 Apr '15

I have ACL Express on Windows. It limits heap size which fails some systems compilation, but anyway, may show some useful results. Or we can ask Dave's help. But let me first understand what is this "no applicable method ASDF/COMPONENT:COMPONENT-CHILDREN" error and why it wasn't detected previously. > On Wed, Feb 12, 2014 at 8:20 AM, Robert P. Goldman <rpgoldman(a)sift.info> wrote: >> Do you have the ability to run these checks with ACL? That was problematic in this case, IIRC. >> Thanks! >> >> Sent from my iPad >> >>> On Feb 12, 2014, at 7:07, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: >>> >>> 12.02.2014, 16:55, "Anton Vodonosov" <avodonosov(a)yandex.ru>: >>>> >>>> I now have results for SBCL and CCL with (uiop:enable-deferred-warnings-check): >>>> http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-31.html >>> >>> In this report I found some failures which seem to be unrelated on warnings: >>> >>> There is no applicable method for the generic function >>> #<COMMON-LISP:STANDARD-GENERIC-FUNCTION ASDF/COMPONENT:COMPONENT-CHILDREN (1)> >>> when called with arguments (#<CFFI-GROVEL:GROVEL-FILE "static-vectors" "ffi-types">) >>> >>> The examples are >>> >>> scriptl >>> http://cl-test-grid.appspot.com/blob?key=1bc1pz0jwt >>> http://cl-test-grid.appspot.com/blob?key=1lj39kniag >>> >>> trivial-features-tests >>> http://cl-test-grid.appspot.com/blob?key=1w15tfux4w >>> http://cl-test-grid.appspot.com/blob?key=1s3h4rlltj >>> > > -- > 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 5

[asdf-devel] resetting asdf configuration
by Faré 08 Apr '15

08 Apr '15

Dear Robert, I see that your latest edit of the ASDF manual failed to include @node surgery (why can't @node's be automatically updated by emacs or some other tool???) I also see that regarding resetting the configuration, things weren't updated. The situation is that there is now a function uiop:clear-configuration, into which the ASDF source-registry and output-translations layers hook. This function is itself hooked into the image-dump-hook, so that, if you use uiop:dump-image, you don't need clear the configuration anymore. That was one of the reasons I pulled in these hooks, actually (originally implemented at ITA in quux). If you insist on calling sb-ext:save-lisp-and-die and similar, of course you lose and you need to call the cleanup hooks yourself. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The only way for a reporter to look at a politician is down. — H.L. Mencken

2 3

[asdf-devel] Using ASDF to drive cross-compilation
by Faré 08 Apr '15

08 Apr '15

I've updated the ASDF TODO file with extensive instructions on how ASDF could be extended to handle builds like XCVB: cross-compilation, reproducible, deterministic, parallel, distributed, etc. If some of you are interested, the ideas are out there, and it's just a SMOP. As for me, I'm out of the CL game, as far as coding goes at least. I may have a few documents to write, speeches to give or videos to make yet. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It's better to know nothing that to know what ain't so. — Josh Billings

1 0

[asdf-devel] Would like to disable bundle-op on known not-working implementation X platform combinations
by Robert P. Goldman 08 Apr '15

08 Apr '15

Per the principle of failing obviously, I propose to raise an error upon attempts to use bundle-op with ECL or ABCL on Mac OSX. The bundle-op tests have been failing for me on those platforms for as long as I can remember. For ECL, at least, I believe this to be an implementation bug, having to do with the Mac's 32-/64-bit hybrid architecture. With the current disarray in ECL maintenance, I don't see any signs of this being fixed. For ABCL the cause of this issue is more mysterious, but it is still persistent. Unless someone squawks, where "squawks" includes "explains why this test failure is specific to me or provides a proposed patch," I will make that change. Cheers, r

2 3

[asdf-devel] Allegro Modern test failures
by Robert P. Goldman 08 Apr '15

08 Apr '15

Looks like this may be due to problems configuring the fasl file locations for the tests. I see this in the transcript: ; Fast loading ; /home/rpg/lisp/asdf/build/fasls/acl/asdf/test/unintern-foo.fasl cfwbi-ufo asdf-test::c => #<excl:fasl-casemode-mismatch @ #x205e0e42> TEST ABORTED: #P"/home/rpg/lisp/asdf/build/fasls/acl/asdf/test/unintern-foo.fasl" was compiled in case-insensitive-upper mode. Continuing to load this file may result in symbol-name mismatches. Surely the build/fasls/ subdirectories should distinguish between ACL alisp and mlisp. Perhaps somehow the normal implementation location logic doesn't work in the tests?

1 0

[asdf-devel] Temporary FASL reconfiguration?
by Zach Beane 08 Apr '15

08 Apr '15

I'd like to change the output translations for a little while and then revert them to the previous configuration. Is that possible via the output translation configuration API? Zach

3 2

[asdf-devel] Much improved uiop:run-program
by Faré 08 Apr '15

08 Apr '15

stassats noticed that 1- run-program would fail in ECL while under SLIME, because ECL's system simultaneously insists in redirecting the I/O to current Lisp streams, and fails if they are not fd streams. 2- the current run-program is so tight a knot as to be horrible and unmaintainable. At the same time, I was procrastinating big time, and feeling I didn't want all that UIOP effort to go to waste. Therefore, 3- I fixed run-program, which involved teaching it about input as well as output, at which point error-output was a breeze. 4- Along the way, I fixed an embarrassing bug in with-temporary-file when using external-format, fixed bugs in slurp-input, identified a CCL bug #1114. 5- run-program is now much cleaner, maybe even maintainable by others, with a somewhat more portable interface to the underlying functionality, and a much improved API for the end-user. 6- Unhappily, 400 lines of code were added (but they include improved documentation). I only tested on Linux x64, using free software implementations and Allegro (Express Edition). Other people will need to test on LispWorks and on Windows, neither of which I can test. It's all committed on the git repository in the run-program topic branch: http://common-lisp.net/gitweb?p=projects/asdf/asdf.git;a=shortlog;h=refs/he… See the commit message for more details on what changed. It should be mostly compatible for all users (= only inferior-shell and asdf tests, AFAICT). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You have the capacity to learn from mistakes. You'll learn a lot today.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel