extending uiop/run-program

Faré fahree at gmail.com
Sat Aug 13 00:59:14 UTC 2016

Dear Elias,

first, I'd like to reiterate how positively impressed I am by the
quality of your work on improving uiop:run-program. Thanks a lot!

>   https://gitlab.common-lisp.net/epipping/asdf/commits/run-program-messy-with-rebasing

> I’ve also opened a merge request at
>   https://gitlab.common-lisp.net/asdf/asdf/merge_requests/3

Remaining issues I see:
* missing docstrings for file-stream-p & file-or-synonym-stream-p (and
any other exported function you introduce).
* to avoid code duplication in
5cd51f5cd26cd29d14e5a57dfaed2b0b5602a685 I would use nest or something
to separate the lispworks 7 specific code without duplicating the
common code.
* Also, is #+lispworks7 future-proof? Is there a feature for 7-or-later?
* I was going to suggest adding a not-implemented error. I see you
did. Congrats! Could you put it in utility.lisp, though? It's a
general-purpose error to have. Same for parameter-error.

> As for CLASP: Getting it to compile is currently rather difficult and as promising and
> interesting as it sounds as a project: I would currently describe it as experimental.
> Even though I’ve now (after multiple attempts on multiple different linux distributions)
> managed to compile it, it currently has issues that keep me from even loading my
> test script.
> I’ve spoken to Nicolas Hafner aka Shinmera (on irc and github) about this and he
> allowed me to quote him as having said:
> [..] I wouldn't bother with clasp right now. If you break UIOP in any substantial way
> we'll notice it. If not, then, well, you can check back once things are running more
> smoothly again. [..] ASDF is being tested somewhat automatically. If you break
> anything seriously, we'll notice [..]
Excellent! It's pleasing to see both you and they have your shit together.

> The function has been exported since at least January of 2008: that’s how far back the history of the
> file that contains such exports goes here:
>   https://github.com/Clozure/ccl/commits/master/lib/ccl-export-syms.lisp
Wow, I was going to say I'm impressed they migrated from their
badly-done svn to git, but I see it's a mirror and the original is
still svn. Meh.

> I’ve gone with a class now (please let me know if you prefer a struct).
> That gets rid of nconc and (Robert had already suggested it earlier for
> this reason) allows one to check if an object is a process). (Actually,
> I’ve called it process-info because it’s more than just a process but
> that’s all up for debate of course).
Perfect, especially with the semi-reflective use of slot-value. Much cleaner.
Don't kid yourself into believing that it's either faster or less
(source or binary) code, though.

>> Yes, the names are acceptable. If you are going to support them as
>> stable interfaces, you can remove the % and export the symbols. Be
>> sure to have adequate docstrings, then.
> These are two outstanding issues: I have not exported anything yet
> and nothing’s documented. On my TODO list.
Thanks a lot!

> I’ve now moved the test to uiop/test. Is that also acceptable? (I didn’t mean to deviate
> from what you said, I just hadn’t read it carefully enough)
Well, then you have to modify the test framework to find those tests
where they are.
(And if you're courageous, you can also update the alternate test
framework I wrote.)

> Up until now, I only used the tests to check for myself if the code I’d written works
> as expected. I’ve now given the test suite a workover so that it’ll handle unexpected
> errors, too, and provide a summary. The issue is, though: A test suite that anyone
> further downstream (be it end users or package maintainers for a distribution) would
> want to run should have a certain character. You wouldn’t want it to sometimes skip 80%
> of the subtests and you wouldn’t want it to fail any tests (that upstream already knows
> about). Yet that’s precisely what happens right now.
The ASDF test framework has some mechanism for having known-failures.

> CLISP’s ext:run-program only supports a tiny subset of the %run-program interface.(*)
> CMU CL and MKCL both have multiple bugs (I’ve filed issues for those) that currently make
> quite a few tests fail, hang, or even lead to a crash of the interpreter. I’ve thus had to
> explicitly skip the hanging and crashing ones.
Welcome to the world of CL portability hacking :-(

> (*) There’s also the private ext::launch which does many things ext:run-program doesn’t
> but then also doesn’t sport an actual superset of features (e.g. you cannot have it
> read from a file. unless you do it manually by opening a file stream and passing that
> stream back to the process. but then you’re in charge of closing the stream, also
> with :wait nil…)
> While we’re on that topic: ABCL has a sys:run-program function which is not currently
> put to use by uiop/run-program. I mean to look into that, too.
I hadn't looked at CLISP's ext::launch (wasn't aware of it).
I believe I gave a cursory look at ABCL's sys:run-program before I
decided that (at least at the time) it didn't have enough features to
do what I want and I might as well fall back to using system.

> I’ve tried to download the free version of Scieneer Lisp by the way but that apparently
> requires approval by someone in the company and they’ve never contacted me. So
> I hope to be able to add clasp to that list at some point and also abcl, but scl probably
> won’t make it.
Last I knew, Douglas Crosher seems to have stopped hacking Scieneer
and to be angry at me and/or free software hackers in general.

>> PS: Are you interested in becoming new maintainer for UIOP?
> I’d certainly like to help and invest time. I’m not sure if you’re asking “a maintainer”
> or “the maintainer”. Because there are certainly large parts of UIOP that I know nothing
> about and issues such as the re-initialisation of argv after dumping an image of cmucl
> sound intimidating, requiring a lot more understanding of common lisp, cmucl, or uiop
> (I don’t even know which one of those three I know too little about, potentially all three)
> than I currently have. So I think my answer should be: “a maintainer”: yes, but
> (pardon if you that’s not what you asked) “the maintainer”: not at this point in time.
I was thinking about "the maintainer", but you could start being "a
maintainer", i.e. have commit rights. I still think you should get
your code reviewed in a branch, though, especially since you're doing
such a good job at it!

You probably know more about the issue with argv on CMUCL than I do at
this point: it's mostly fallen off my cache, and any knowledge I had
was reified in uiop + cl-launch.

Robert, are you OK with granting Elias the commit bit on ASDF?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Be yourself, everybody else is taken. — Oscar Wilde

More information about the asdf-devel mailing list