asdf-devel September 2011

asdf-devel@common-lisp.net

5 participants
11 discussions

[asdf-devel] source file encoding
by Anton Vodonosov 15 Apr '12

15 Apr '12

Hello. How to specify source files encoding in ASD2? I.e. what value to pass to the :external-format argument of the compile-file? In the old ASDF I did it by (let ((asdf:*compile-file-external-format* #+:clisp charset:cp1251 #+:sbcl :cp1251)) (asdf:operate 'asdf:load-op :mysystem)) But today the variable asdf:*compile-file-external-format* does not exist. Also, it of course would be better to specify the encoding in the .asd file (the system author knows the files encoding, and should care about this, but not the system user). Could you advise me how to do it? Best regards, - Anton

13 61

[asdf-devel] Suggested patches for ASDF
by Juan Jose Garcia-Ripoll 20 Sep '11

20 Sep '11

Apart from some documentation and copyright notices, two major changes: - ECL will support two compilers. ASDF needs to be aware of that. - The plug-in for REQUIRE allows ECL users to supply another default operator. LOAD-FASL-OP is recommended because it builds each library into a single shared library, saving resources. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

4 25

[asdf-devel] Troubles with ASDF:RUN-SHELL-COMMAND
by Robert Goldman 18 Sep '11

18 Sep '11

As a side-effect of trying to export ASDF:*VERBOSE-OUTPUT*, to catch the output from RUN-SHELL-COMMAND, I created a test to verify that it was behaving properly. Boy, was that a mistake! I found that, in fact, ASDF:RUN-SHELL-COMMAND was not working on (at least) ACL, when faced with a command that had embedded double-quotes. See launchpad bug: https://bugs.launchpad.net/bugs/853566 I have fixed this and pushed the fix and the tests to the branch named 'run-shell-command' on cl.net. I would be VERY grateful if others would run the test on other lisps and other platforms. I would be especially grateful if people would run the tests on windows, since I don't really have a good understanding of how RUN-SHELL-COMMAND should work on that platform. I think it's bad that RUN-SHELL-COMMAND doesn't work properly, but I don't want to push these mods as a new version of ASDF until they run everywhere. Best, Robert

1 0

[asdf-devel] Export asdf::*verbose-out*?
by Robert Goldman 15 Sep '11

15 Sep '11

The user needs to bind asdf::*verbose-out* to something in order to see what happens when executing a command through asdf:run-shell-command. Given that the user is to do this, shouldn't this symbol be exported from the ASDF package? best, r

1 0

Re: [asdf-devel] Pathname failures on ASDF 2.017.4 on SCL 1.3.9
by Faré 14 Sep '11

14 Sep '11

Dear ASDF developers, there were test failures recently in SCL, and Douglas Crosher found that they were related to the semantics of merge-pathnames*. I'm not sure anymore what merge-pathnames does, how its current behavior differs from SCL's ext:resolve-pathname, and more importantly, what it should be doing, so I'm thinking aloud and maybe one of you will catch something. >>>: Douglas Crosher >>: Fare >: Douglas Crosher >>> The SCL requires slightly different code in merge-pathnames* >>> which seems to have been causing the issue. >>> >>> The issue occurs because pathnames in the test do not have a host etc >>> so are resolved relative to a logical-pathname host: >>> >>> (merge-pathnames* "/home/mod1/file.lisp" #p"ASDFTEST:SRC;") >>> => #p"ASDFTEST:HOME;MOD1;FILE.LISP.NEWEST" >>> >>> Adding the host etc gives the following and corrects the issue: >>> >>> (merge-pathnames* "file://localhost/home/mod1/file.lisp" >>> #p"ASDFTEST:SRC;") >>> => #p"file://localhost/home/mod1/file.lisp" >>> >>> I can't see any reason why a pathname with an absolute directory >>> should be handled specially in merge-pathnames* and the following >>> example seems right for the SCL: >>> >>> (merge-pathnames* "/home/mod1/file.lisp" #p"http://host/") >>> => #p"http://host/home/mod1/file.lisp" >>> >> The reason why merge-pathnames* does this is because >> we want to treat the merging of relative pathnames specially: >> based on defsystem specifications, we have pathnames that are relative >> to wherever the .asd file is; however, at the time the user specifies >> those relative pathnames, and as he does some merging operations on them, >> he has no idea what kind of implementation will be present and what >> host (logical or physical), device, etc., will be used for the pathname. >> Therefore, I needed this abstraction (and accompanying syntax) for >> "pathnames wherein a relative pathname does not specify host or device, >> but an absolute pathname does". >> >> I suppose there's a slight mismatch with scl's ext:resolve-pathname. >> Instead of your first patch, >> maybe merge-pathnames* shouldn't just call that latter function, >> but do some more wrapping around it? > > The SCL's ext:resolve-pathname seems to handle the relative paths just fine, > and works with URLs. > > The problem occurred when the system definition specified a path with an > absolute directory and no host or device. > The SCL's ext:resolve-pathname will resolve such a path relative to the base > host etc which I think is useful. > > Consider a standard CL example of a system definition with a base pathname > which is a logical pathname. In this case it would be reasonable to have a > component pathname with an absolute directory and no host be resolved > relative to the base logical pathname - which is what the SCL's > ext:resolve-pathname will do. The current behaviour of merge-pathname* is > to simply ignore the default host and device for a pathname with an absolute > directory which does not seem useful. Perhaps you could consider modifying > merge-pathname* to merge the host and device for pathname with an absolute > directory rather than ignoring the defaults in this case. > > This issue is hard to describe, but I may be able to come up with a new test > for it. > OK. I think I get it. The issue is that at least *some* CL implementations (for instance clisp) use a NIL pathname-host for normal Unix absolute pathnames. In that case, the host being NIL doesn't mean "host unspecified", but "normal absolute pathname", and it is wrong to replace it with a say logical host from the defaults. Maybe the "right thing" then is to identify, in each implementation, what is the canonical way of representing the possible "absolute pathname referring to some default toplevel filesystem" as opposed to possibly "absolute pathname depending on unspecified host", and keep a NIL in the first case (where that applies) but not the other case. Then, the asdf-pathname-test would have to be updated to do the right thing with those two cases (whichever applies). It seems that your ext:resolve-pathnames might already be doing this "right thing" — except maybe when a relative pathname is specified with a host? NB: to maximize the chances of pathnames being created with the correct host and device, maybe load-sysdef should bind *default-pathname-defaults* to (pathname-directory-pathname pathname) around load? Oh noes, more portability issues with CL pathnames! At that point, I'll just weep. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

1 0

[asdf-devel] ECL tests on the Mac
by Robert Goldman 14 Sep '11

14 Sep '11

I just installed ECL from MacPorts, and when I run the test suite I get a failure. Using ecl -norc Ran 35 tests: 34 passing and 1 failing failing test(s): test-configuration.script Should I expect this? best, r

3 10

Re: [asdf-devel] Unexpected behavior when loading different versions of a system
by Daniel Herring 06 Sep '11

06 Sep '11

On Tue, 6 Sep 2011, Robert P. Goldman wrote: > P.S. I'd be interested in feedback about the use I made of git here. I > *could* have squashed the series of commits that ended up with the patch > you see here, but in the end, I decided that it might be helpful for > people to see in the history the blind alley that I pursued, because it > seemed like a simpler fix to begin with. db16d0..8f5e2d I frequently like my history to show stuff like this. Some people prefer a clean, "always works" history. One approach is to treat the development work as a branch and merge it back into master with the summary message you would use in the squash. I think this caters to both styles. - Daniel

1 0

[asdf-devel] Does anyone still moderate asdf-devel?
by Robert Goldman 06 Sep '11

06 Sep '11

I have multiple email addresses and am increasingly getting bounces as a result. I'd like to fix this, but don't have the foggiest idea how to do so. If a moderator sees this email, please contact me off-list. best, r

1 0

[asdf-devel] Pushed proposed fix for Xach's bug
by Robert Goldman 05 Sep '11

05 Sep '11

Passes all of the unit tests (including the new one based on Xach's test case). Please, all of you, have a peek at the diffs (possibly I should have squashed the changeset to make this easier, sorry), and the commit message, and test it as soon as possible. I have not bumped the version number, as this is still a work in progress subject to review. best, r

2 4

Re: [asdf-devel] Unexpected behavior when loading different versions of a system
by Daniel Herring 03 Sep '11

03 Sep '11

On Fri, 2 Sep 2011, Robert P. Goldman wrote: > I can see that I didn't explain this as well as I might. It is too late for me to try again now, but I will have a whack sometime over the long weekend. The short answer is that Xach's test case actually revealed that the reuse of old component objects could leave ASDF in a very bad state (modified components with some old attributes, components that were obsolete retained, etc.). Don't do the write-up just for me. It looks like you have good reasons for this change, and that other solutions would be unnecessarily complex. Thanks, Daniel

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel September 2011