[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Quad-FIO[57] Take 3

From: Peter Teeson
Subject: Re: [Bug-apl] Quad-FIO[57] Take 3
Date: Wed, 25 Jul 2018 15:43:35 -0400

As you can see this email came through OK.

On Jul 24, 2018, at 5:25 PM, Juergen Sauermann <address@hidden> wrote:


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
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.

/// Jürgen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]