Allow lisp programs to read a process's stdout and stderr either separately or together.#32
Allow lisp programs to read a process's stdout and stderr either separately or together.#32ethanxxxl wants to merge 10 commits intolem-project:masterfrom
Conversation
|
That's great. |
|
currently chasing a bug with process_write, for large inputs (greater than ~11.7k bytes) the program will fail to transfer all the data, and then lock up, with a "Resource temporarily unavailable" error. |
…rote function to open a pty
|
after a bit of a hiatus, I have gotten back to this finally. I often found myself working on this during long flights. Having the C compilation dependency was giving me a headache when trying to get qlot/Lem to use/find the library. After some digging, I discovered I can just import all the C posix functions and constants I was using with CFFI. I decided to rewrite my (mostly) working C code in CL to remove this C dependency and simplify the build process a little bit. I'm still working on the translation, I can currently open/close, and I am currently working on testing the process creation functions. |
I was trying to get a language server running in lem (clangd) but it was not starting. After some investigation I found that clangd was outputing error messages to stderr, which were being piped to stdout via the PTY in async-process.
I ended up having to rewrite all of async-process.c in order to add this ability in. Apparently PTYs only have in input stream and an output stream. My solution was to add a second PTY into the process just for stderr. This should work fine as long as programs don't try to set terminal settings on stderr, as these settings will not be mirrored to the PTY running stdout and stdin.
These changes still need some testing before they can be merged. I need to ensure that there are no memory leaks, either in the C code or in the CL interface. One of the changes I made was to use dynamically allocated buffers for read. This way a single call through the CFFI will read as much data as it can. We can revisit this decision if a thinner C API is desired. I am marking this PR as a draft for the time being.
also note, that I changed the load path for libasyncprocess.so to where it is saved to on my local machine for testing