|
From: | Juergen Sauermann |
Subject: | [Bug-apl] Quad-FIO[57] Take 3 |
Date: | Tue, 24 Jul 2018 23:25:00 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
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 |
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] | Current Thread | [Next in Thread] |