Re: Question, GSoC Idea `Easier Access to Native Libraries using JNA/JNR"

[Jamison Hope <jrh@theptrgroup.com>]

On Apr 2, 2017, at 11:12 AM, Per Bothner <per@bothner.com> wrote:

> On 04/02/2017 04:07 AM, Vasantha Ganesh wrote:
>>  I have been trying to write a proposal for ``Easier Access to Native
>> Libraries using JNA/JNR" idea for my GSoC project.
>> 
>> The access to native libraries is available through popular libraries
>> such as JNA and JNR. Access to native libraries in Kawa is just like
>> any other Java library in a very consistent way (strengths of Kawa?).
>> 
>> I tried looking into the Ruby wrappers. JRuby is trying to make their
>> FFI API compliant with other implementations. So that Code on JRuby
>> can run in the same way as other Ruby implementations.
>> 
>> Common lisp is trying to do something similar with CFFI. Common lisp
>> implementations are trying to make their code that can run on other
>> implementations in the same way. This calls for a common API (CFFI).
> 
> Looks like you've done some good research.
> 
>> But in scheme we are not trying to be compliant with any other Scheme
>> implementations. Take Guile and Kawa for example. Guile code does not
>> necessarily run on Kawa. Also, Guile has its own FFI.
>> 
>> These are just my views. I would like to know the motivation of this
>> project because I'm fuzzy about the usefulness of this project.
> 
> I'm afraid I haven't JNA or JNR myself, so I don't know firsthald how
> useful they are, or how much a Kawa binding would help.
> 
> What was an open question was whether a Kawa wrapper (i.e. some
> well-design Scheme procedures and/or macros) would make JNA or JNR
> easier to use. You've suggested that it probably wouldn't.  Or at
> least we don't have enough experience with possible "pain points"
> to identify areas where a Kawa wrapper would make using JNR
> noticeable easier or more pleasant, partly because Kawa already makes
> it very easy and pleasant to use the Java API as-is.  Right?

I haven't used JNR, but I  have used JNA (well, JNAerator).  Using
it directly from Kawa is not terrible, you just have to define a
class with one or more static #!native methods, and a static
initializer that calls com.sun.jna.Native:register() passing the
name of the native library:

(define-simple-class LibC ()
  (allocation: 'static init: (com.sun.jna.Native:register "c"))
  ((printf s::String)::int allocation: 'static #!native)
  ((clock)::long allocation: 'static #!native))

LibC:printf
=>
int LibC.printf(String)

(LibC:printf "Hello\nWorld\n")
=>
Hello
World
12

(LibC:clock)
=>
1677346


The advantage of a Kawa wrapper would be able to do something
that looked more like (perhaps) a R7RS library, or maybe to
permit #!native as the body of an ordinary named procedure:

(define (printf s::String)::int #!native)

(But we would need some way to provide the call to
Native.register() in there.)

Just my $0.02.

--
Jamison Hope
The PTR Group
www.theptrgroup.com