As you can see this email came through OK.
> On Jul 24, 2018, at 5:25 PM, Juergen Sauermann
> <juergen.sauerm...@t-online.de> wrote:
>
> 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
>
