asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

Question about resolving "symlink/.."
by Jared C. Davis 08 Sep '16

08 Sep '16

Hi, I have set up the following directory hierarchy: lstest-dir | +---+------------------+ | | subdir1 subdir3 ---symlink---+ | | +-+---------+ | | | | xxxdir subdir2 <----------------------+ | | xxx.txt yyydir | yyy.txt On my linux system, shell commands like "ls" seem to resolve paths such as "lstest-dir/subdir3/.." to "lstest-dir/subdir1". For instance: $ ls lstest-dir/subdir3/../xxxdir xxx.txt In other words, when a path goes through "<symlink>/..", it seems to be resolved by first following the symlink, then finding the parent directory of the symlink's target. However, it appears that uiop:ensure-directory-pathname resolves ".." in a different way. For instance, on CCL on Linux, when I run: (uiop:ensure-directory-pathname (uiop:parse-native-namestring "lstest-dir/subdir3/..")) I get #P"lstest-dir/" instead of #P"lstest-dir/subdir1". Is there a way to configure ensure-directory-pathname to use a more shell-like behavior, or some other alternative that I might run to preprocess the path to resolve these obscure cases like the shell does? Thanks, Jared -- Jared C. Davis <jared.c.davis(a)gmail.com> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/

2 1

[haiku][patch]
by Daniel Kochmański 08 Sep '16

08 Sep '16

Hey, I've recently worked a bit to get ECL working on Haiku platform. To make ASDF work there, I had to patch the os-detection part of UIOP to recognize the platform. Patch is very minimal: -- CUT HERE -- >From ea6c95dc35fe3a71912fd6f43c4b704e70d35ac3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20Kochma=C5=84ski?= <daniel(a)turtleware.eu> Date: Tue, 6 Sep 2016 21:33:10 +0200 Subject: [PATCH] detect-os: add haiku os --- uiop/os.lisp | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/uiop/os.lisp b/uiop/os.lisp index 31e1583..85bd56a 100644 --- a/uiop/os.lisp +++ b/uiop/os.lisp @@ -55,13 +55,18 @@ keywords explicitly." "Is the underlying operating system an (emulated?) MacOS 9 or earlier?" (featurep :mcl)) + (defun os-haiku-p () + "Is the underlying operating system Haiku?" + (featurep :haiku)) + (defun detect-os () "Detects the current operating system. Only needs be run at compile-time, except on ABCL where it might change between FASL compilation and runtime." (loop* :with o :for (feature . detect) :in '((:os-unix . os-unix-p) (:os-macosx . os-macosx-p) (:os-windows . os-windows-p) - (:genera . os-genera-p) (:os-oldmac . os-oldmac-p)) + (:genera . os-genera-p) (:os-oldmac . os-oldmac-p) + (:haiku . os-haiku-p)) :when (and (or (not o) (eq feature :os-macosx)) (funcall detect)) :do (setf o feature) (pushnew feature *features*) :else :do (setf *features* (remove feature *features*)) -- 2.9.3 -- CUT HERE -- I did run ASDF tests - 6 failures (attached). ASDF performs well with Quicklisp and loads basic systems. Best regards, Daniel -- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

2 1

RFC: uniform exit codes
by Elias Pipping 08 Sep '16

08 Sep '16

Dear list, I’d like to talk about exit codes for a bit. The uiop/run-program::%wait-process-result function e.g. currently waits for a process to terminate and then returns something. An exit-code. What would you expect that to be? What would you like it to be? (I’ve already had a long discussion about this with Robert but Faré asked me to take it to the mailing list, too). An exit code should be a number and lie between 0 and 255, with only 0 signalling success, as far as I understand. A ‘return -1’ in C ends up as a 255 once I check for it in lisp or shell. Beyond that there are customs but not standards (there is sysexits.h but it’s not used all that much) Please consider the three shell scripts that each contain just one line: (1) exit 15 (2) kill $$ (3) sh -c ‘kill $$’ If you saved them in separate scripts and ran them from within a shell, the exit code would be 15/143/143. The take-away messages from that for me are that - the shell uses 128+n if the process dies in response to signal n - there are cases where the exit code is greater than 128 even though the process itself did not die in response to a signal, thereby interfering with this logic - the shell cannot distinguish (2) and (3) From within lisp, often but not always (2) and (3) can be distinguished. Sometimes, a process-wait function will return something like 15/(0 15)/(143 0) for the above examples(*); sometimes a process-status function will report (:exited 15)/(:signaled 15)/(:exited 143). But some implementations will behave like the shell and always return 15/143/143, e.g. ABCL, LispWorks <7, and Allegro CL with :wait t. So the thing that we can reliably do is produce the sequence 15/143/143. Please note that even this baseline is already a proposal for a change: With today’s UIOP master branch, you could also get things such as 15/15/143, 15/0/143, or 15/:sigterm/143, if I’m not mistaken. What we could not reliably do is e.g. return things like 15/-15/143 or (15 :exited)/(15 :signaled)/(143 :exited). What I’ve implemented so far is a compromise. Some platforms might return 15/(143 15)/143 and others just 15/143/143. The (143 15) could easily be turned into (143 :signaled) instead, that’s a matter of taste, the take-away message remains, though, that you couldn’t be sure that what you think is case (2) isn’t really case (3). So that leaves also the option of “let’s just not bother with distinguishing the two”. Looking forward to your feedback, Elias (*) I’m using (x y) as a short-hand for (values x y) here, rather than (list x y)

2 2

set variables before executing the "test-op"
by Alexey Veretennikov 07 Sep '16

07 Sep '16

Hi all, I am using cl-project to generate project skeleton for the library including separate asd file for unit tests. The test framework I use is the default for cl-project: prove. Using this framework I would like to set some special variables to control test execution _before_ running the asdf:test-system i.e. (setf prove.color:*enable-colors* nil) (setf prove:*default-reporter* :tap) But the problem is when I set them directly in .asd file, the CL reader complains what the prove.color and prove packages do not exist (which is true, since the prove dependency is not yet loaded). I could set them in every test file, but I would like to set them globally. How could I set them after the dependency to unit test library (prove) is loaded and therefore package exists? This is what I have in .asd file for tests: :defsystem-depends-on (:prove-asdf) :perform (test-op :after (op c) (funcall (intern #.(string :run-test-system) :prove-asdf) c) (asdf:clear-system c))) Br /Alexey

4 6

New committer: Elias Pipping
by Faré 04 Sep '16

04 Sep '16

With Robert's assent, I gave committer rights to Elias Pipping on the ASDF repository on https://gitlab.common-lisp.net/asdf/asdf — Welcome, Elias! Elias, I suggest you keep working in branches and have your code reviewed. Actually, I should probably start doing the same, now that you're here to review my code! (Not that I intend —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org For every complex problem, there is a solution that is simple, neat, and wrong. — H. L. Mencken

2 1

Re: Version 3.1.7.7 has been pushed
by Robert Goldman 02 Sep '16

02 Sep '16

On 8/21/16 Aug 21 -7:49 PM, Elias Pipping wrote: > Dear Robert, dear list, > > I’m happy to see the first changes to run-program in ASDF-3.1.7.7. I’m now working more pragmatically towards making others mergeable. As usual, the list can be viewed at > > https://gitlab.common-lisp.net/asdf/asdf/merge_requests/3 > > As of right now, it looks like this: > > 8e4f7fd Add and use process-info class > ec74b27 Add %if-on-lispworks?+ > ba8c24e Bug fix: Exit code with LispWorks 7 > a35fbe2 Bug fix: Store exit code with Allegro CL > 104da21 Change :if-*-exists default to :supersede > 4ef7409 Add and use not-implemented-error > 6359a4b Add file-stream*-p > c2d5de3 Add and use parameter-error. Reorganise errors. > 7ae0bcf Fix warnings on ABCL, etc. > fb3dd9a Add and use close-streams > 4971606 Add %process-info-*put getters > c7570da Tests: Cover %run-program and %wait-process-result > 1f43e5d Do not pass unnecessary keywords to SBCL Should we have another iteration on this, putting it into a topic branch and letting me test it on Windows, Mac, and Linux? TBH, I have never used merge requests on gitlab or github (except as submitting them), so I don't know the workflow from the recipient side. My use of git is mostly limited to command-line. best, r

4 17

Pushed ASDF 3.1.7.8: fixes for CLISP, etc.
by Faré 02 Sep '16

02 Sep '16

Sam Steingold (sds) probed me on some old bugs, which led me to waste a day debugging issues on and with CLISP. First I reproduced CLISP bug 677, figured out what CLISP was doing wrong (incorrect merging of logical pathnames in compile-file), and implemented a workaround (physicalize everything I can, trust compile-file's return value over my :output-file argument): https://sourceforge.net/p/clisp/bugs/677/ Then, I found a cleaner fix to the issue with DIRECTORY wanting "*" rather than "*.*" as the match-all pattern on CLISP and GCL. I also dug out the information in the old README.md that Robert stripped. I moved anything that may have been redundant with doc/index.html, move there what was complementary, and put back in README.md (after some editing) things that were not covered by either the home page or the manual: the documentation on how to navigate our source code, build and test ASDF, etc. Robert, please tell me if that's OK, since you were the one who deleted that information arguing of unmaintainable redundancy with web page and manual. I also slightly tweaked said web page and manual. Also, I see you disabled make doc in the Makefile. I presume it should be restored. Finally, I renamed make.bat to make-asdf.bat so that on Windows there is no risk of typing "make" and run make.bat in the current directory while believing one had run make.exe from the %PATH%. This may or may not help Robert make his tests pass on Windows. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org ...so this guy walks into a bar. "The usual, Mr. Descartes?" the barman asked. "I think not," Rene replied, and promptly disappeared.

5 11

*LOAD-TRUENAME* and ASDF
by Robert Goldman 31 Aug '16

31 Aug '16

I just realized that ASDF somewhat breaks *LOAD-TRUENAME*. I had some code in a DSL that has an :INCLUDE construct, and that DSL is being interpreted at load-time. The :INCLUDE directive tries to find other lisp files relative to the current file (the source file that contained the DSL :INCLUDE expression). Now, if we were not using ASDF, I would be able to find those files by merging a name with *load-truename* (and this is how things used to work). But ASDF's relocation of the fasls breaks this. Now, of course, I could change (:INCLUDE construct "construct-source.lisp") to (:INCLUDE construct #.(asdf:system-relative-pathname "foo" "construct-source.lisp")) but: 1. This is blatantly ugly, effortful, and error-prone for the programmer. 2. It is poor software engineering, because it requires the contained thing (the DSL expression) to "know" that it is being included in a very specific ASDF system. Now if we rename the ASDF system, or shuffle files, our DSL code is broken, and that's just wrong, because it makes the abstraction upside down. I somehow assumed it would be possible to go from the FASL to the source, but I don't actually see any obvious way to do this. suggestions? thanks! r

6 21

Re: Version 3.1.7.7 has been pushed
by Elias Pipping 27 Aug '16

27 Aug '16

> On 27 Aug 2016, at 19:45, Faré <fahree(a)gmail.com> wrote: > > All these are reasons why it's illusory to try to document a compatibility matrix in the source code itself. This matrix is extremely hard to accurately ascertain and maintain as the code evolves, and cannot possibly be future-proof. > > Please, don't pollute the source code with vain attempts at including a compatibility matrix in it. At best, have the code link to an informative URL, that at least stands a chance at being maintained. Dear Faré, I’ve already agreed with you in another mail on that topic, please see e.g. https://mailman.common-lisp.net/pipermail/asdf-devel/2016-August/005412.html I’d be interested in your thoughts on the proposal that I’ve made based on that. Elias

1 0

Question about UIOP: Any reason GET-TEMPORARY-FILE couldn't be exported?
by Robert Goldman 23 Aug '16

23 Aug '16

ACL offers a functionality like this with its make-temp-file-name and make temp file. I'd love to have a portable version that would, for example, make temporary files that could be used as arguments in RUN-PROGRAM. Is there any reason this could not be exported? thanks, r

3 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel