From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119149 invoked by alias); 2 Apr 2017 21:08:10 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 118045 invoked by uid 89); 2 Apr 2017 21:08:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=002, sk:www.the, sk:wwwthe, Jamison X-HELO: mail.theptrgroup.com Received: from mail.theptrgroup.com (HELO mail.theptrgroup.com) (71.178.251.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 02 Apr 2017 21:08:07 +0000 Received: from [10.11.21.10] (unknown [10.11.21.10]) by mail.theptrgroup.com (Postfix) with ESMTPS id 5BC5C40131; Sun, 2 Apr 2017 17:08:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Question, GSoC Idea `Easier Access to Native Libraries using JNA/JNR" From: Jamison Hope In-Reply-To: <30c20dfb-bf03-fdb4-fbcb-3e963d780cdf@bothner.com> Date: Sun, 02 Apr 2017 21:08:00 -0000 Cc: Vasantha Ganesh , kawa@sourceware.org Content-Transfer-Encoding: 7bit Message-Id: References: <30c20dfb-bf03-fdb4-fbcb-3e963d780cdf@bothner.com> To: Per Bothner X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00018.txt.bz2 On Apr 2, 2017, at 11:12 AM, Per Bothner 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