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 <m...@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, enz...@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 <m...@xn--jrgen-sauermann-zvb.de> wrote: > > Hi enztec, > > see below... > > Jürgen > > On 1/27/23 10:55 PM, enz...@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 ... > > --- > > > > >