Re: libapl stdout

[enztec]

Hi Jürgen

this is what i'm testing and i must be missing something - 

//apl_exec('h ← "w" ⎕fio[3] "https.tmp"'); // h → 3     good '1 2 3 4' written 
to file
//apl_exec('h ← "w" ⎕fio[3] "/dev/stdin"'); // h → 3   '1 2 3 4' written to 
screen
apl_exec('h ← "w" ⎕fio[3] "/dev/stdout"'); // h → 3   '1 2 3 4' written to 
screen
//apl_exec('h ← "w" ⎕fio[3] "/dev/tty"'); // h → 3  '1 2 3 4' written to screen
//apl_exec('h ← "w" ⎕fio[3] "/dev/stderr"'); // h → 3  '1 2 3 4' written to 
screen
//apl_exec('h←0'); // causes domain error
//apl_exec('h←1'); // causes domain error
//apl_exec('h←2'); // causes domain error
//apl_exec('h←3'); // causes domain error
apl_exec('"h :", h');
writeln('1');
apl_exec('rs←(⍕⍳4) ⎕fio[23] h');
writeln('2');
apl_exec('rs←⎕fio[4] h'); // closing causes display on screeb  (but not to 
stdout?)

On Sun, 29 Jan 2023 13:55:55 +0100
Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:

> 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,
> Jürgen
> 
> 
> 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...
>     
>     Jürgen
>     
>     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 ...
>       
>       ---
>       
>       
>     
>   
>