[Top][All Lists]

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

Re: libapl stdout

From: Dr . Jürgen Sauermann
Subject: Re: libapl stdout
Date: Sun, 29 Jan 2023 13:55:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

Hi enztec,

⎕FIO comes with file handles 0 (stdin), 1 (stdout), and 2 (stderr) open
so you can read/write to them with any ⎕FIO function that has a file handle
argument (read/write/fread/fwrite/etc.) Note that these handles are the OS
file descriptors (and NOT the corresponding GNU APLoutput channels
(CIN/COUT/CERR) since both COUT and CERR write to stderr
(aka. cerr in C++).

You cannot close or fclose a file handle 0, 1, or 2.

The easiest way to obtain the value of apl_exec() is to ⍕ it in
(or before) the apl_exec() callback. Before apl_exec() returns it
calls res_callback(). The default res_callback(). does nothing.

If write your own res_callback() then its second argument committed
indicates whether the resut value was committed (as in apl_exec("Z←3+4").)
or not (as in apl_exec("3+4");). If your res_callback() returns
non-zero then I believe libapl will print the value as well.

The first argument of res_callback() is an APL value V whose
essential APL properties (⍴⍴V, ⍴V, and (,V[j]) (types and values))
can be accessed with libapl functions.

Using with apl_exec()  simplifies matters since the first argument
res_callback() will then always be a character matrix rather than a
general (possibly mixed and/or nested) APL value.

Best Regards,

On 1/28/23 9:06 PM, enztec@gmx.com wrote:
Thanks Jürgen

i am currently using ⎕fio to write the apl_exec result to a file and then using fpc to read the file data back into an fpc ansistring variable

is it possible to use ⎕fio to write to stdout rather then a file?
can ⎕fio[3] do it?

On Sat, 28 Jan 2023 12:21:06 +0100
Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:

Hi enztec,

see below...


On 1/27/23 10:55 PM, enztec@gmx.com wrote:
  Hi Jürgen (i hope you are feeling better - if you need a pint of [blood, beer, ....] 
  these quotes are from an fpc programmer who is interested in the libapl/apl interface with fpc - i have no idea how to respond and would love something to respond with
  quote 1:
  Things would have been much easier if the library was a proper shared library.
Arguable. Static libraries are IMHO easier to produce and easier to use. However, the
fpc programmer could fix the GNU APL Makefiles to poduce

  (and also not tied to the programming language) Not sure how a GNU APL library could not be tied to APL.

  so that provision for a normal call-back mechanism would have been in place.
Actually libapl provides a callback mechanism for printing results. Instead
of messing with stdout/stderr, the fpc programmer should have used it. See
info libapl (after installing libapl).

  We/you are trying to fix something that should not have to be fixed in the first place. You can already make use of a sort of callback mechanism with APL but it still will not catch /all/ output from the library.
  quote 2 :
  Just for the record: combining output and error will not help you in communicating properly with the APL library. One channel is used for normal results, the other for indicating that there is an error and another channel that outputs additional information. And then you have your input channel. The latter can be fixed/circumvented with a call-back. Another callback also work for /one/ of the other used channels.
???. My impression is that the fpc programmer has an execution model in mind that
differs from the execution model anticipated by Dirk Laurie (the author of libapl). The
apl_exec() functions should not produce any output (and their results can be obtained
by either assigning them to APL variables or else by the result callbacks. The
 apl_command() functions return their output as strings. None of them writes to stdout
or stderr (except when ⎕FIO functions that do so are used in the APL code).

Again, see info libapl.
  i have no response to either and would appreciate if you could give me an 'apl/libapl' view ...


reply via email to

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