Re: SRFI 170 (POSIX API) for Kawa

[Duncan Mak <duncanmak@gmail.com>]

Hello all,

The other weekend, I took on Per's suggestion and began typing up parts of
the SRFI 170 API using Kawa Scheme.

It's still WIP, but you can see what I have here:
https://github.com/duncanmak/srfi-170/blob/kawa/srfi/kawa/lib/srfi/170/170.scm

From the module listing, you can see which Java classes I'm using:

(define-library (srfi 170)
  (import (kawa base)
          (srfi 9)
          (class java.lang ProcessHandle UnsupportedOperationException)
          (class java.util EnumSet Iterator)
          (class java.nio.file DirectoryStream DirectoryStream$Filter Files
Path Paths)
          (class java.nio.file.attribute
                 BasicFileAttributeView
                 FileAttribute
                 PosixFileAttributeView
                 PosixFilePermission
                 PosixFilePermissions)
          (class java.nio.channels FileChannel))

I haven't gotten around to hooking up with the test code, so there might be
some mistakes there.

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.

If there's interest in seeing this work completed, I can look at finishing
up the patch and try to write something back to tally which of the APIs can
be implemented with just Java, and which would require jnr-posix.

If there's even more interest, I could also look into doing a jnr-posix
implementation as well.


Duncan.

On Sat, Feb 22, 2020 at 11:40 AM Per Bothner <per@bothner.com> wrote:

> On Sat, Feb 22, 2020 at 4:46 AM Lassi Kortela <lassi@lassi.io> wrote:
>
> > Is anyone working on implementing SRFI 170 for Kawa yet? Since Kawa is
> > Java-based instead of C-based, and uses pathname objects as well as a
> > per-thread parameter object to store the current directory, it would
> > make for a good test case.
>
> It might be interesting to see how much could be implemented in portable
> Java,
> without digging into native (C/C++) code.  Kawa currently does not contain
> native code, which means we can make a single cross-platform "binary
> release".
>
> That doesn't mean I'll rule out having optional features that depend
> on native code, but I would prefer to stick to no native code in the
> default build.
>
> There are no doubt large parts of SRFI-170 that could be implemented
> without native code, but I haven't done the effort to see what the issues
> are.
> If someone wants to look into to what extent SRFI-170 can be mapped into
> Java APIs that would be interesting, but I'm not planning to do that
> study myself.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>


-- 
Duncan.