[Top][All Lists]

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

Re: libapl stdout

From: enztec
Subject: Re: libapl stdout
Date: Sat, 28 Jan 2023 13:06:33 -0700

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

reply via email to

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