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
