New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for pty #37
Comments
I'm not entirely sure what you're asking. It seems sbcl's
since each one will accept the |
Thank you. Are you interested in adding a portable |
That's a surprisingly difficult question, to be honest. Maybe a year ago, external-program's That said, when I looked e.g. into the issue of controlling the environment that a process is spawned in, I found it impossible to come up with a portable solution (which is why that is something uiop's The reason I'm saying this for is: If (edit: and only if) you have reasonable hope of coming up with a solution that will work on typical common lisp implementations (abcl, allegro cl, ccl, clisp, cmucl, ecl, lispworks, mkcl, sbcl... except maybe clisp, that's rather dusty) then I encourage you by all means to put a reasonable amount of time into it and submit a PR (again, preferably to asdf, not here) -- the community would be thankful I'm sure. Unfortunately I cannot be of much help because my health is a disaster, as a result of which I also have not be doing much with common lisp for a while. I'd do my best to provide feedback and code review, though (and I wouldn't be surprised if @rpgoldman and @fare would, too). |
Right now, uiop:run-program passes the arguments passed to it, with overrides, to the underlying run-program, so you can add your own, if they make sense (maybe it would be better instead to take an extra argument for extra arguments to pass to the underlying run-program, but that's not how it currently is). If the pty feature requires a subtle modification of arguments actually passed by uiop:launch-program, then that's harder, at requires modification of UIOP. But we accept patches: https://gitlab.common-lisp.net/asdf/asdf/merge_requests |
Thank you both. Elias, Sorry to hear your health condition. Wish you feel
better. As you and François-René said, I'll send a PR to uiop. But if
there's comparable amount of difference in implementations, I may need to
send patches directly to all these implementations.
On Jul 11, 2017 11:38 AM, "François-René Rideau" <notifications@github.com> wrote:
Right now, uiop:run-program passes the arguments passed to it, with
overrides, to the underlying run-program, so you can add your own, if they
make sense (maybe it would be better instead to take an extra argument for
extra arguments to pass to the underlying run-program, but that's not how
it currently is).
If the pty feature requires a subtle modification of arguments actually
passed by uiop:launch-program, then that's harder, at requires modification
of UIOP. But we accept patches: https://gitlab.common-lisp.
net/asdf/asdf/merge_requests
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#37 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMpSiCvj8LIeHIXMF5UCt40_29bKWx69ks5sM5cRgaJpZM4OR587>
.
|
|
Finally got some time to continue working on this. For CCL, this option is simply ignored (and it's also mentioned in ccl doc currently this option is not implemented): |
@epipping is, sadly, deceased this year. If you submit a patch to UIOP to support the feature on implementations that have it and throws an error if a use is attempted on other implementations, it will be gladly accepted. Ideally, I would like UIOP to be good enough that external-program could be simply a deprecated wrapper around it. |
I agree with @fare here. 1. I am sadly writing more elisp than CL these days, as my career has moved in a different direction; and 2. I support @fare’s efforts to reduce duplication and shore up single solutions to various problems in the CL world. I’m happy to accept patches to external-program, but I would rather see it replaced by UIOP. I wonder if there’s a term to use prior to “deprecated” that means something like “currently still useful, but it’d be better to add new features to UIOP rather than fix external-program.” Maybe “deprioritized”? I could add something to the README to point people toward UIOP. Also, I’m saddened to hear that @epipping has passed. |
I'm so sorry to hear @epipping has passed. Looks reasonable for me to submit a patch to uiop. Thanks. |
SBCL has a
:pty
keyword for run-program, which make it possible to talk to other REPL like program possible, for example, python, psql, sqlite, etc. Although it's not in CCL and ECL, but maybe possible implement in a similar way by calling c functionsfork
,execvp
like SBCL does.I think it's a useful feature. It's of course possible to use these interpreter's low level c library, but need a lot of effort, like library RCL, LTK). Talk to interpreter to directly is a less efficient but quick way. Is this task possible (run a external python, talk to it interactively in CL) in current external-program in current external-program? Thank you
The text was updated successfully, but these errors were encountered: