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> 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 > > and the relevant code is at > > 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.sauerm...@t-online.de> > <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 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 > > > > > > >
