This is something I might want to take a look at. I think the most difficult part of implementing this is to decide on a nice way to map the libffi API to APL in a natural way.
I'm thinking of providing a quad-function that allows you to declare a C function and their arguments (and associated types). That way you don't have to mess with datatypes when it comes to actually calling the native functions. Still, you need to have constructs that allows you to allocate memory, as well as functions to access the content of said memory. I have no idea how such an API should look in APL. I might take a look at this, but right now I'm working on some other projects so I don't have time. Regards, Elias On 8 Feb 2017 23:05, "Juergen Sauermann" <juergen.sauerm...@t-online.de> wrote: > Hi, > > I had a quick look at both the C code from the www.jsoftware.com < > http://www.jsoftware.com/help/user/call_procedure.htm> and fromhttps:// > github.com/libffi/libffi <https://github.com/libffi/libffi> > My first impression is that the former is quite hack-ish. > > But I haven't worked with libffi myself, so I cant really say if it lives > up to its promises. > If it does then my vote would definitely be for *libffi*. > > Another plus for *libffi* is that it is available as debian package. > > /// Jürgen > > > On 02/08/2017 01:38 AM, Elias Mårtenson wrote: > >> This would be really neat to have, but as someone who has written a lot >> of FFI (foreign function interface) code in Common Lisp which has a very >> powerful such interface, there are a lot of nuances that needs to be >> covered in order to have a decent FFI. >> >> For example, what if you need to call a function which accepts a struct >> as its first argument which contains a pointer to another struct which in >> turn has a list of unsigned integers of size Foo (defined with a typedef in >> a .h file of course). The second argument being a pointer to a callback >> function. >> >> That just gives a small idea of the issues one would come across. >> >> Thankfully there is a C library, libffi, which can help here. It's >> designed to assist when creating an FFI for something like GNU APL. I >> recommend anyone who considers taking up this project to investigate it. >> >> libffi can be found here: https://github.com/libffi/libffi >> >> I certainly would really like it if this was implemented. >> >> Regards, >> Elias >> >> On 8 Feb 2017 03:01, "Juergen Sauermann" <juergen.sauerm...@t-online.de >> <mailto:juergen.sauerm...@t-online.de>> wrote: >> >> Hi Xiao-Yong, >> >> I believe this could be achieved by a single "master"-native >> function which then loads the >> actual DLL as specified by the arguments of the master function. >> Referring to the example in >> link you gave below: >> >> *a=: 'kernel32 GetProfileStringA s *c *c *c *c s' b=: >> 'windows';'device'; 'default'; (32$'z');32 a cd b >> +--+-------+------+-------+--------------------------------+--+ >> |31|windows|device|default|HP LaserJet 4P/4MP,HPPCL5MS,LPT |32| >> +--+-------+------+-------+--------------------------------+--+*** >> >> This would become in GNU APL: >> >> >> *a← 'kernel32 GetProfileStringA s *c *c *c *c s' b← 'windows' >> 'device' 'default' (32⍴'z') 32******'universal-dll-loader' ⎕FX >> 'cd'****** a cd b ⍝ dlopen("kernel32.dll"), dlsym("GetProfileStringA") on >> first access,****⍝ and call GetProfileStringA with argument b* >> >> The *universal-dll-loader.so* needs to be written only once and >> contains mainly the code from github below. That code somehow goes >> into the *native/template_F12.cc* code of GNU APL and thats it. If >> you need help doing this then please let me know. /// Jürgen >> >> On 02/07/2017 06:30 PM, Xiao-Yong Jin wrote: >> >>> It would be nice if one doesn't need to write wrappers and the APL >>> system can do the >>> structure conversions within the APL interpreter. In J, you can >>> dlopen a library >>> and pass J values directly without writing and compiling C, see >>> >>> http://www.jsoftware.com/help/user/call_procedure.htm >>> <http://www.jsoftware.com/help/user/call_procedure.htm> >>> >>> and the relevant code is at >>> >>> https://github.com/jsoftware/jsource/blob/master/jsrc/x15.c >>> <https://github.com/jsoftware/jsource/blob/master/jsrc/x15.c> >>> >>> It would simplify using external libraries a lot. >>> >>> On Feb 4, 2017, at 7:38 AM, Juergen Sauermann<juergen.sauermann@t- >>>> online.de> >>>> <mailto:juergen.sauerm...@t-online.de> wrote: >>>> >>>> Hi, >>>> >>>> yes there is: native functions. You can load shared libraries and >>>> ⎕FX functions in >>>> them to be called from APL code. The src/native directory contains >>>> a few templates >>>> that you can use as a starting point and to call your favourite >>>> library from them. >>>> >>>> Of course you need to provide wrappers from/to APL values to/from >>>> the data >>>> structures expected or produced by the libraries. >>>> >>>> Coming back to your other problems, if you do not like the terminal >>>> I/O of GNU APL, then >>>> you can write your own one and call libapl from it. I have extended >>>> libapl recently, giving >>>> you the full functionality of GNU APL without the specific ways how >>>> it handles terminal IO. >>>> >>>> /// Jürgen >>>> >>>> >>>> On 02/04/2017 02:52 AM,enz...@gmx.com <mailto:enz...@gmx.com> >>>> wrote: >>>> >>>>> is there method for loading a c lib and using it in apl ? cdecl? >>>>> like this in fpc? >>>>> >>>>> >>>>> ftp://ftp.freepascal.org/fpc/docs-pdf/CinFreePascal.pdf >>>>> <ftp://ftp.freepascal.org/fpc/docs-pdf/CinFreePascal.pdf> >>>>> >>>>> >>>>> >>>>> >>>>>
