asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

monolithic-lib-op
by Faré 07 Oct '15

07 Oct '15

Difficulties making monolithic-lib-op portable suggest that it (and maybe also lib-op) should output an object file as if by ld -r rather than a static library. Indeed, there is no *portable* way to combine several .a files into a single one on a BSD system (including MacOS X). Or should that be the case only on said systems? In any case, that's ugly, and to make a distinction, we'd have to extend os.lisp to also distinguish bsd-style unix from gnu-style unix. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is said that pragmatism trumps ideology in a crisis. What actually happens in a crisis, certainly in this one, is that the ruling party gets to rechristen its ideology as pragmatism. — Christopher Caldwell

4 7

Bundle operations
by Robert Goldman 01 Oct '15

01 Oct '15

Are these reasonable across different Lisp implementations? E.g., what would it mean to try to invoke a DLL-OP on ACL, Lispworks, or CCL? It seems like we are advertising a lot of functionality that we do not, in fact, support. I'd like to prune this down in some way, eliminating operations on implementations that don't support them. thanks, r

4 12

Spurious ALLEGRO failure
by Robert Goldman 30 Sep '15

30 Sep '15

I'm getting what look like spurious failures on tests of "allegro" in test-program.script. I *believe* that what's going wrong here is that lisp-invocation is getting confused about how to find the right ACL runtime. If you look at run-tests.sh, you will see that "ALLEGRO" is initially bound using the funky logic at the top of the file, but then is REBOUND on windows to use buildi instead of alisp on that platform.... I *suspect* this is breaking things, because I suspect that the logic for reasoning about the ALLEGRO installation directories is getting run more than once, causing INVOKE-LISP to fail. But INVOKE-LISP doesn't provide any useful information about how it's invoking lisp. I'll investigate somewhat further, but if an explanation jumps out at you, please LMK. I believe that this conjecture is supported by the fact that it is only the "allegro" tests that fail -- not allegro64, none of the modern variants, etc. Cheers, r

3 13

One last test failure: ECL on Linux
by Robert Goldman 30 Sep '15

30 Sep '15

test-xach-update-bug.script fails on both ECL and ECL bytecodes for me on Linux. This is ECL 13.5.1. I *believe* that this is to be expected, and there's an ECL fix for this. Please LMK if that's not true and if I should hold up releasing 3.1.6 for that reason. Otherwise I plan to release today (assuming I can get the necessary time from work).

2 4

uiop:run-program broken on SBCL/Windows.
by Faré 30 Sep '15

30 Sep '15

SANO Masatoshi reports that uiop:run-program broke on SBCL/Windows at some point between 3.1.3 and 3.1.5. Can someone with SBCL and Windows help me debug that? A trace of functions in uiop/run-program and the functions in sb-ext that appear in that file, using ASDF on 3.1.3 and on 3.1.5, on some failed invocation, would help. A fix before 3.1.6 would be wonderful. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The [classical] liberal, of course, does not deny that there are some superior people — he is not an egalitarian — but he denies that anyone has authority to decide who these superior people are. — F. A. Hayek, "Why I Am Not a Conservative"

3 6

test status, impending release, and UIOP/SBCL/Windows bug
by Robert Goldman 30 Sep '15

30 Sep '15

Tests all pass on my Windows VM (thanks to Dave Cooper!). Tests all pass on Mac. Running tests on Linux. After that propose to release 3.1.6. I'd like to get the UIOP fix for SBCL on Windows in place before the release, but still have no bug report, so am not sure how to replicate or fix. Last call for bug report...

1 0

Spurious failure in SBCL on windows
by Robert Goldman 29 Sep '15

29 Sep '15

When I run test all on Windows, the SBCL tests fail in a spurious way. I get an error that lisp couldn't rename f:\asdf\build\dir1\foo0.asd to f:\asdf\build\dir1\foo1.asd.bak AFAICT this is because CREATE-ASD-FILES in test-configuration.script uses :if-exists :rename-and-delete when it's creating the .asd files. Is this actually necessary? Could we replace this with :supersede, or will something go awry? For now I'm experimenting with that replacement, so please just LMK if this is A Bad Thing. thanks, r

2 1

Understanding UIOP/RUN-PROGRAM
by Mark Evenson 29 Sep '15

29 Sep '15

In a potentially memory constrained environment, I need to portably (across sbcl and ccl at least) process a potentially large (multiple GiB) stream of bytes output from a Linux command. For the curious, "process" here means encrypt with a block cipher and push to the network; whereas the UNIX command is the output of "btrfs send". I wanted to confirm with ASDF developers that as far as I can tell from wrangling with UIOP:RUN-PROGRAM, it isn't going to do what I want because there is no "asynchronous" mode. UIOP:RUN-PROGRAM cannot be "run in the background" like SBCL's SB-EXT:RUN-PROGRAM with :wait nil that allows the output of the sub-process to be gathered and processed in blocks. So, it would always be the case that UIOP/RUN-PROGRAM::SLURP-INPUT-STREAM has "gone through" all the (potentially huge) output of the sub-process before UIOP:RUN-PROGRAM can return. Note that I'm not complaining about UIOP:RUN-PROGAM: it certainly bridges a lot of implementation specific details of the use case for "Execute this command; let me process its output". I'm just trying to affirm my understanding of UIOP and (regrettable) need to move off to do my own CCL/SBCL implementation for my needs. If my understanding is correct, the UIOP maintainers may wish to emphasize the synchronous nature of UIOP:RUN-PROGRAM in its docstring. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 4

program-op compression
by Florian Margaine 28 Sep '15

28 Sep '15

Hi list, I want to use asdf's program-op to dump an image, using this command: sbcl --eval '(asdf:operate :build-op :my-system)' This works perfectly. An image is correctly dumped, and works fine. However, the image is 70MB. Is it possible to use sb-ext:save-lisp-and-die's :compression option? In the source, I've seen :extra-build-args, but it seems to be a make-build option only. I'm not very familiar with asdf's source though, so I'm surely missing something. Cheers, -- Florian Margaine

2 1

(asdf:operate :build-op :system) creates image in ~/.cache/[...]
by Florian Margaine 28 Sep '15

28 Sep '15

Hi list, I'm trying to use the relatively recent feature to dump an image using asdf's build-op feature, so that I only need this line in my terminal: sbcl --eval "(push \"$PWD/\" asdf:*central-registry*)" --eval '(asdf:operate :build-op :my-system)' Where my-system has the following .asd: (asdf:defsystem #:my-system :description "foo" :serial t :depends-on (:sb-posix) :components ((:file "package") (:file "my-system")) :build-operation "asdf:program-op" :build-pathname "my-system" :entry-point "my-system:main") The binary is built just fine. The issue is that it's created in ~/.cache/common-lisp/sbcl-1.2.15.debian-linux-x64/$PWD/, while I'd just like it to be created in $PWD/. Is this a configuration issue? Where is this setting configured? Regards, -- Florian Margaine

2 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel