[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libapl stdout
From: |
enztec |
Subject: |
Re: libapl stdout |
Date: |
Fri, 27 Jan 2023 14:55:01 -0700 |
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
(and also not tied to the programming language) so that provision for a normal
call-back mechanism would have been in place. 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.
i have no response to either and would appreciate if you could give me an
'apl/libapl' view ...
---
On Fri, 27 Jan 2023 16:18:52 +0100
Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:
> Hi enztec,
>
> not sure if this helps, but if I remember correctly (I may not) then the
> main GNU APL output
> goes to *stderr* (fd 2) and not to *stdout* (fd 1). The reason is
> somewhat historic because *stdout* is
> buffered by default while *stderr* is not (which caused some issues with
> *stdout* when used
> interactively that did not occur with *stderr*).
>
> Best Regads,
> Jürgen
>
>
> On 1/15/23 12:19 AM, enztec@gmx.com wrote:
> > Hi
> >
> > I'm still trying to resolve the failure of fpc using libapl to get it's
> > stdout
> >
> > trying to get libapl stdout to be gotten in my libapl/fpc program i read the
> > https://gist.github.com/houmei/cfd9e570b8de4d8fd55ada228d5ff004#file-readme-2-configure
> >
> > thinking fpc might be using a different stdout then the libapl does from
> > this line
> > 'but because the executable that is linked with libapl.so) has its own I/O
> > channels.'
> >
> > and re-compiled libapl with --with-android
> > and then compiling my program i get get :
> >
> > /usr/local/lib/apl/libapl.so: undefined reference to `CIN'
> > /usr/local/lib/apl/libapl.so: undefined reference to `UERR'
> > /usr/local/lib/apl/libapl.so: undefined reference to `COUT'
> > /usr/local/lib/apl/libapl.so: undefined reference to `CERR'
> >
> > is this suppose to happen ?
> >
> > i get same error when compiling my libaplo.c program
> >
> > how to set these in the c program?
> >
> >
>
- Re: libapl stdout, (continued)
- Re: libapl stdout, Elias Mårtenson, 2023/01/14
- 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 <=