[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 ...
>
> ---
>
>
>
- Re: libapl stdout, (continued)
- Re: libapl stdout, Dr . Jürgen Sauermann, 2023/01/27
- Re: libapl stdout, Chris Moller, 2023/01/27
- Re: libapl stdout, enztec, 2023/01/27
- Re: libapl stdout, Chris Moller, 2023/01/27
- Re: libapl stdout, enztec, 2023/01/27
- Re: libapl stdout, Chris Moller, 2023/01/27
- Re: libapl stdout, enztec, 2023/01/27
- Re: libapl stdout, Chris Moller, 2023/01/27
Re: libapl stdout, enztec, 2023/01/27