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

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

[Vasantha Ganesh]

Hello all,
  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).

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.

It might be a little late to write proposal for other ideas.

Thank you.
Vasantha Ganesh K.

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

[Per Bothner]

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?

> It might be a little late to write proposal for other ideas.

Probably  You could take a look at the "function types using MethodHandles"
idea that I mentioned in an email March 13, and detailed here:
https://www.gnu.org/software/kawa/Ideas-and-tasks.html#Optimized-function-types-and-values-using-MethodHandles

This is definitely useful, and at least I myself understand both the problem
and a general direction for solving it.  You could use the text from my link.
The problem is it requires a fair bit of understanding of Kawa.  For a GSoC
proposal you should should that you understand the problem and have a general
plan for how to solve it.  That may be difficult in less than 2 days.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

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

[Jamison Hope]

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