Hi asdf developers,
I recently was writing some code with UIOP:CALL-WITH-CURRENT-DIRECTORY and came across something slightly unexpected.
In particular, running CALL-WITH-CURRENT-DIRECTORY or WITH-CURRENT-DIRECTORY forms evaluates to NIL, whereas one may expect that the form evaluates to the return value of THUNK or the macro body, respectively.
In my program, I'm trying to do something like:
(uiop:with-current-directory (dir) (uiop:run-program (list "some" "program") :output :string))
Which doesn't quite do what I want it to do.
I believe this has to do with the definition, which ends in a trailing (chdir dir) form to get out of the directory which unfortunately returns NIL instead of the value from evaluating THUNK.
So my question is: would it be acceptable if a future version of UIOP changes call-with-current-directory to return the value of evaluating THUNK?
Thanks, Kevin
I haven't checked carefully, but I think you need to work around this with something like
``` lisp (let (result) (uiop:with-current-directory (dir) (setq result (uiop:run-program (list "some" "program") :output :string))) result)
```
The problem with changing this behavior is that it wouldn't be forwards-compatible: if you write code that depends on this change, you would have to condition it on the ASDF release version. So I don't *object* to making the change, but it's a niche issue and one that could cause headaches when ASDF/UIOP aren't updated. So I'm not going to code it up myself, but I would consider a merge request.
Best, R
On 19 Aug 2024, at 17:01, Kevin Zheng wrote:
Hi asdf developers,
I recently was writing some code with UIOP:CALL-WITH-CURRENT-DIRECTORY and came across something slightly unexpected.
In particular, running CALL-WITH-CURRENT-DIRECTORY or WITH-CURRENT-DIRECTORY forms evaluates to NIL, whereas one may expect that the form evaluates to the return value of THUNK or the macro body, respectively.
In my program, I'm trying to do something like:
(uiop:with-current-directory (dir) (uiop:run-program (list "some" "program") :output :string))
Which doesn't quite do what I want it to do.
I believe this has to do with the definition, which ends in a trailing (chdir dir) form to get out of the directory which unfortunately returns NIL instead of the value from evaluating THUNK.
So my question is: would it be acceptable if a future version of UIOP changes call-with-current-directory to return the value of evaluating THUNK?
Thanks, Kevin
Hi Robert,
On 8/19/24 7:27 PM, Robert Goldman wrote:
I haven't checked carefully, but I think you need to work around this with something like
|(let (result) (uiop:with-current-directory (dir) (setq result (uiop:run-program (list "some" "program") :output :string))) result) |
Yes, that's indeed how I've been working around this (with a macro).
The problem with changing this behavior is that it wouldn't be forwards-compatible: if you write code that depends on this change, you would have to condition it on the ASDF release version. So I don't /object/ to making the change, but it's a niche issue and one that could cause headaches when ASDF/UIOP aren't updated. So I'm not going to code it up myself, but I would consider a merge request.
This is what I wanted to know: whether a merge request might be considered. Thanks and I may work on submitting one.
Regards, Kevin
Can you show an example of UIOP failing? Works for me—the chdir is the protection form of an unwind-protect.
(require :asdf) (in-package :uiop) (progn (with-output-file (s "/tmp/foo" :if-exists :supersede :if-does-not-exist :create) (write `(1 bar ,(+ 2 2)) :stream s)) (with-current-directory ("/tmp/") (safe-read-file-form "foo")))
(1 COMMON-LISP::BAR 4)
(with-current-directory ("/tmp") (uiop:run-program (list "echo" "program") :output :string))
"program " NIL 0
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org “Anarchy is order, government is civil war.” — Anselme Bellegarrigue
On Tue, Aug 20, 2024 at 4:27 AM Robert Goldman rpgoldman@sift.info wrote:
I haven't checked carefully, but I think you need to work around this with something like
(let (result) (uiop:with-current-directory (dir) (setq result (uiop:run-program (list "some" "program") :output :string))) result)
The problem with changing this behavior is that it wouldn't be forwards-compatible: if you write code that depends on this change, you would have to condition it on the ASDF release version. So I don't object to making the change, but it's a niche issue and one that could cause headaches when ASDF/UIOP aren't updated. So I'm not going to code it up myself, but I would consider a merge request.
Best, R
On 19 Aug 2024, at 17:01, Kevin Zheng wrote:
Hi asdf developers,
I recently was writing some code with UIOP:CALL-WITH-CURRENT-DIRECTORY and came across something slightly unexpected.
In particular, running CALL-WITH-CURRENT-DIRECTORY or WITH-CURRENT-DIRECTORY forms evaluates to NIL, whereas one may expect that the form evaluates to the return value of THUNK or the macro body, respectively.
In my program, I'm trying to do something like:
(uiop:with-current-directory (dir) (uiop:run-program (list "some" "program") :output :string))
Which doesn't quite do what I want it to do.
I believe this has to do with the definition, which ends in a trailing (chdir dir) form to get out of the directory which unfortunately returns NIL instead of the value from evaluating THUNK.
So my question is: would it be acceptable if a future version of UIOP changes call-with-current-directory to return the value of evaluating THUNK?
Thanks, Kevin
Hi all,
On 8/23/24 1:56 PM, Faré wrote:
Can you show an example of UIOP failing? Works for me—the chdir is the protection form of an unwind-protect.
Oops, that's embarrassing for me. I ran your snippet and indeed WITH-FILE-OUTPUT seems to be returning the value from the body.
What was going on was that I had wrapped my call to (with-current-directory) with another macro that *didn't* properly return the last value. What then likely happened was that I first "fixed" uiop, saw that it didn't fix things, fixed my macro, and then later proposed the "fix" to uiop.
Glad you caught this :)
Thanks, Kevin