Re: SRFI 170 (POSIX API) for Kawa

[Jamison Hope <jhope@alum.mit.edu>]

On Wed, Jul 15, 2020 at 12:16 AM Per Bothner <per@bothner.com> wrote:
>
> On 7/14/20 2:10 PM, Duncan Mak wrote:
> > it's pretty clear that we won't be able to support the entirety of the SRFI 170 API using just Java classes. If we want to achieve that, we'll probably have to use JNR-Posix.
> >
> > With JNR-Posix, Per's comments about shipping native code will become a thing.
>
> I don't mind an optional (configurable) dependency on jnr or jnr-posix, but I don't think
> it should be a required or default dependency.
>
> I don't have much feel for how popular or common JNR is - it seems to be
> a project that is in semi-maintenance mode, and not on any kind of "standards track".
> I haven't done anything with it.
>
> That doesn't seem we can't make use of it, of course.

I agree it shouldn't be a required dependency.  But it would also be
handy to be able to use the SRFI in conjunction with a stock binary
Kawa release, and not have to do a custom configuration.

Per, can the srfi loading in ImportFromLibrary.java cross jar
boundaries?  If so, one option might be for SRFI97Map to map 170 to
some other named class that isn't included in kawa.jar, and then
provide a separately-compiled kawa-srfi170.jar or whatever that did
rely on JNR-Posix or other such native code.  Then if that other jar
is in the CLASSPATH, then (import (srfi 170)) loads/uses it, and if
not, then it doesn't work, or maybe we instead fall back on a
Java-only subset.

I've never used JNR.  My impression is that it's like JNA but..
better?  Or at least newer?  I used to use JNA to access some C
libraries, and it worked fine for what I was doing at the time.  Is
JNR-Posix the only viable option?

Duncan, can you post a listing of which SRFI-170 functions are / are
not doable using just standard Java with no third-party/native code?
It'll help to weigh the pros and cons of introducing a new dependency.

> Please us and Duncan know (here) whether SRFI-170 or other Posix bindings would be
> useful to you.

It's really a shell thing and not a POSIX thing per se, but I have
some scsh scripts lying around that made heavy use of process
pipelines and &&, which seem to have been omitted from SRFI-170.  Kawa
supports pipelines via pipe-process, but is there an equivalent to
scsh's &&?  As in:

(let ((echo (if dry-run? '(echo) '())))
  (&& (,@echo cmake ,@(cmake-opts) ,@opts ,src-dir)
      ,(if verbose?
           `(,@echo make -j ,ncpu VERBOSE=1)
           `(,@echo make -j ,ncpu)))

This almost works:
(define-syntax && (syntax-rules () ((_ e ...) (and (process-exit-ok? e) ...))))

(&& &`{date} &`{true}) => #t
(&& &`{date} &`{false}) => #f

but it loses the output of each command.  I'm guessing it would need a
validate-apply thing just like pipe-process in order to inject
"out-to: 'inherit" to each one, but I haven't figured out the right
incantation.


As for what is covered by SRFI-170, for the most part they aren't
really things I would use very often, beyond what's already available
in Kawa's file system interface.  But that's not a vote against
proceeding with this effort: I've contributed several SRFI
implementations to Kawa, and I hardly ever use any of them, either.

-- 
Jamison Hope