extending uiop/run-program

[Faré]

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