Re: How many people are interested in designing the OS interface? Lassi Kortela 09 May 2019 15:32 UTC
These are all good points. > I'm not convinced that direct Scheme access to low-level integer file > descriptors and fork are useful to standardize. I've found it very useful even in high-level languages to be able to refer to file descriptors by number. It's true that it's not as portable outside Unix. You can pass HANDLE values around even in WinAPI but they are not small integers like Unix fd's (some handles are pointers cast to integers, you have to assume a handle can be a uint64). > Doing doing a 'fork' on the JVM using native code seems like a bad idea. We discussed this briefly with John and agreed with you that the most "ordinary" procedure should have the semantics of a combined fork+exec, like start-process in Emacs or CreateProcess() on Windows. Unixisms such as separate fork and exec should be designated as special and less portable procedures. It might be best to leave them for their own SRFI altogether. The current draft is based on Scsh which shows a lot of Unix bias. Having this division would also hopefully encourage people to prefer the more portable procedures, resorting to the Unix-only stuff only when it's necessary. When programming in C, people often use the fork()/exec() abstraction because it's there and it's familiar, not because they need that fine-grained control. > Better to use ProcessBuilder, > which is quite flexible: > https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/ProcessBuilder.html It looks similar to Python's subprocess.Popen() API (<https://docs.python.org/3/library/subprocess.html>). That's good. It makes sense to have a process not-yet-launched-process object on which you can set various options (where stdin reads from, where stdout and stderr write to, possibly other file descriptors, what environment variables are used, etc.) > It is better to standardize higher-level APIs. For example Kawa has a > flexible high-level process API: > https://www.gnu.org/software/kawa/Processes.html The run-process function already embodies the above philosophy nicely: (run-process in-from: "in.txt" out-to: "out.txt" "tr A-Z a-z") pipe-process is a nice touch too. Manually constructing pipelines by gluing together OS pipes and subprocesses is tricky. > I build a single portable "universal" binary release for Kawa. Adding > native code would complicate that. Do you currently manage with only Java's standard libraries, i.e. no JNA or JNI?