Re: [Bug-apl] using c libs in apl?

[Elias Mårtenson]

The main problem with quad-TS is that it doesn't provide a way to count seconds. This is because the date portion is not constant, it's sometimes 30 and sometimes 31.

The other problem is that it's local time, which means that time measurements across DST changes are not predictable. 

What's needed is something that gives you Unix time (seconds since 1970-01-01). Preferably with better resolution than seconds. Milliseconds at a minimum. For example, Java provides this value multiplied by 1000 to give millisecond resolution. 

Regards, 

Elias 

On 8 Feb 2017 23:50, "Juergen Sauermann" <address@hidden> wrote:

Hi Christian,

The problem with floats for absolute times is that the standard ieee floats have a 48-bit mantissa.
The seconds since epoch currently eats up about 32 bits of them, leaving only 16 bits for the sub-second part.
That means that the precision of an absolute time expressed in floats cannot be more that about
1/65000 seconds = 15 micro-seconds.

The same holds for the  popen()  method which opens a file, and probably re-schedules the calling process,
resulting an unpredictable delay between the timing source (no matter how precise it is) and the APL code
receiving it.

All this makes it difficult, if not impossible, to improve much on *⎕TS *with its 1 ms resolution.

On the other hand we have ¯*1 ⎕FIO*, which returns the CPU's cycle counter (which has a precision of
about 300 picoseconds on a typical 3.2 GigaHz CPU). You simply cannot beat that precisions with any
of the timing sources that are provided by the kernel.

I cannot think of a reasonable use of an absolute time with a micro second resolutions. I would argue
that times are either short-term (for benchmarking and the like) but then they are relative with a high precision,
or long-term (but then ⎕TS is good enough).

I also believe that your earlier request (2016-Jun-16 ?) was about measuring the timing of APL functions and
was not mentioning localtime() or  gettimeofday(). And I did not refuse it but rather assumed that the answer
that I gave at that time would solve your problem. BTW *⎕TS* is almost localtime() with slightly different
offsets and milliseconds resolution instead of micro-seconds.

/// Jürgen


On 02/08/2017 05:19 AM, Christian Robert wrote:

I love that.

Of course it will possibly/eventually crash your APL session if you do the smallest error in your parameters definition.

"libffi" as mentioned by Elias is also a great possibility, already available by default on Fedora, CentOS-7, debian, ...

I just had to install libffi-devel to be able to run some successful tests in C.

all this is very promising.

My last struggle with this kind of thing is that I wanted a Quad-FIO['datetime'] (refused a year ago or so, but needed now)
able to return

  a) a float meaning the current time in milli or microsecond since epoch if called with arg=0.
  b) a Quad-TS array if called with 1 arg when arg>0 and assuming it's an epoch at milli/micro/seconds accuracy.
  c) a float when arg is an array of length 7, eg: in the Quad-TS style.

I ended up to write the function in C and call it via a wrapper function written in APL using FIO['popen'], FIO['read'] and FIO['pclose']

very painful, slow (it invoke calling an external program on each invocation), but it work pretty well.

what I really wanted at that time was an interface to "localtime()" and "gettimeofday()", the former using a r/w reference to a struct tm.

not easy to program the (libffi and/or the x15.c) wrappers to APL, I agree.

Xtian.


On 2017-02-07 12:30, 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 <address@hidden> 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, address@hidden 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