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?

6:52:49 younder There is a package inferior-shell that can run programs

6:55:03 younder Never-mind it uses uiop:run-program as well

7:22:17 beach Hmm, I never noticed this before; the SBCL TRACE function prints symbols with package prefixes upon function entry but without package prefixes upon function exit.

7:23:10 beach Try (defun foo (symbol) symbol) (trace foo) (foo 'hello)

7:48:29 jackdaniel this description seems to be incomplete

7:48:55 jackdaniel when trace is entered, then the package printer uses is the package FOO is defined in, and when trace returns, the package printer uses is the package user is in

7:49:09 jackdaniel i.e

7:49:10 jackdaniel CLIM-USER> (cl-user::foo 'cl-user::hello) 0: (FOO HELLO) 0: COMMON-LISP-USER::FOO returned COMMON-LISP-USER::HELLO

7:50:09 beach Yes, I see. Thanks. Still an interesting observation.