Hi,
I have added a new ⎕FIO[57] aka. FIO∆execve to GNU
APL.
Handle←⎕FIO[57] Filename
forks a new process running program Filename
and connects it to GNU APL. GNU APL and the new program
can then communicate using Handle, FIO∆fread,
and FIO∆fwrite. This is similar to FIO∆popen,
except that
the communication is bi-directional.
An example (template) for writing your own server is provided as
tools/TLV_server.c. The testcase
testcases/Quad_FIO.tc has been extended to show how the tools/TLV_server.c
template is intended
to be used at the GNU APL end.
A server program and a GNU APL workspace are free to agree on how
the communication between them
is being encoded. However when sending byte sequences over a
stream connection (like the one provided
by FIO∆execve) it
is a common problem to frame the data has not being framed (like
it is in UDP or SCTP)
so that the receiver has the problem of figuring knows if there is
more data coming or not. To solve that
problem, I have added 33 ⎕CR resp. 34 ⎕CR (= ¯33 ⎕CR)
that encode s pair Tag, Byte_vector at the sender
side into a sequence of bytes that can be easily decoded back into
Tag, Byte_vector
at the receiving end
without much APL coding. The byte sdsequence in the middle is a
Tag/Length/Value (TLV) structure
created by 33 ⎕CR and decoded by
34 ⎕CR .
In other words, an APL vector Tag,
Byte_vector with an integer Tag followed
by 0 or more data bytes
(in the range ¯128...255 including) is transparently
transferred from the sender (GNU APL) to the receiver
(the newly forked server program).
SVN 1058.
Enjoy,
/// Jürgen