libera/#commonlisp - IRC Chatlog

0:26:59 NotThatRPG paulapatience: ping?

0:35:39 paulapatience NotThatRPG: Hi

0:36:25 NotThatRPG I realized I never got back to you when you asked about reporting the ASDF issue. Would you mind posting to https://gitlab.common-lisp.net/asdf/asdf/-/issues

0:38:02 NotThatRPG Because I have, of course, completely forgotten what you said

0:53:46 paulapatience NotThatRPG: Sure

0:53:53 NotThatRPG Thanks!

1:09:54 paulapatience NotThatRPG: Doe

1:09:56 paulapatience Done

1:10:41 NotThatRPG Great! Appreciate it. I'll have a look when I can. rn I'm being held back by some issues w/ testing infrastructure, but the cl.net folks are helping.

1:11:44 paulapatience There's no real rush, it's a trivial fix if I'm right.

1:12:42 paulapatience I think it has gone undetected for so long because pathnames are passed directly to :input/:output in uiop:run-program

1:13:11 paulapatience I've been writing a wrapper around uiop:run-program, that's why I happened to see the bug

1:30:06 paulapatience s/are passed/are usually passed/

1:56:32 Bubblegumdrop nice work ...

2:53:40 paulapatience I will say that the implementation of uiop:run-program and uiop:launch-program is some of the most convoluted code I've ever read. I'm still not sure what half of it does.

2:54:11 paulapatience Part of the issue all the feature checks for different implementations

2:54:23 paulapatience Part of the issue is

2:55:47 paulapatience In my CLOS-based wrapper equivalent of uiop:run-program, I will wrap each implementation in a separate package. It should be clearer then.

3:44:36 Lord_of_Life_ ** NICK Lord_of_Life

5:45:34 jackdaniel another one is that uiop refuses to rely on the implementation behavior and instead of that it always transits data through its own streams

5:45:39 jackdaniel and that's like supper inefficient sometimes

5:46:45 jackdaniel say you write (uiop:run-program ... :output *my-stream*), then it calls (impl:run-program ... :output *uiop-vomiting-stream*), and marshalls all data from the vomiting stream to *my-stream*, so data is passed twice

5:47:14 jackdaniel I want to believe that there is a sensible reason to do that

5:47:28 aeth so you can define a method on the uiop stream?

5:51:59 Th30n` ** NICK Th30n

5:51:59 jackdaniel sensible reason is not necessarily the same thing as a technical desire of the creator ,)

5:52:45 jackdaniel the question is not "what can you do with it?", but rather "why?"

6:00:14 jackdaniel for my purposes this run-program does a job: https://turtleware.eu/static/paste/foo.lisp ; with a quirk that not all implementations support :wait nil, so a more sophisticated version could try to spawn a thread to manage such run-program instead; perhaps being able to communicate from a separate thread to a stream is the reason behind uiop's gymnastics?