Hi,
two explanations:
1. ⎕FIO does not allow closing of file descriptors 0, 1, and 2 aka.
stdin, stdout and stderr.
Closing them is usually a mistake because it disconnects the interpreter
from its I/O. That
should explain the DOMAIN ERRORs.
2. Files opened with fopen (aka.*⎕FIO[3]*) are buf
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 '
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
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 Saue
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 libap
All of the code below is in the C++ language and std::string is a very
basic bit of C++. If you're not familiar with C++, the string class,
stringstream, stringbuf, and so on, the first thing you need to do is
get some experience in C++.
There is no direct replacement for QString, but std::st
sorry that means nothing to me as to what to replace the qstring below with
On Fri, 27 Jan 2023 19:38:51 -0500
Chris Moller wrote:
> QString is mmore or less equivalent to the C++ std::string class.
>
> On 1/27/23 18:00, enz...@gmx.com wrote:
> > what do i replace all the qstring with
> >
>
QString is mmore or less equivalent to the C++ std::string class.
On 1/27/23 18:00, enz...@gmx.com wrote:
what do i replace all the qstring with
/apl/libapl/c > grepi qstring
./aplexec.h:18:aplExec (apl_op_e apl_op, QString &cmd,
./aplexec.h:19:QString &outString, QString &errString);
./libapl
what do i replace all the qstring with
/apl/libapl/c > grepi qstring
./aplexec.h:18:aplExec (apl_op_e apl_op, QString &cmd,
./aplexec.h:19:QString &outString, QString &errString);
./libaplc.c:12:AplExec::aplExec (apl_op_e apl_op, QString &cmd,
./libaplc.c:13:QString &outString, QString &errStri
Qt isn't necessary--that's just the environment I'm working in. From my
example, get rid of the #include line.
Here's aplexec.h:
#ifndef APLEXEC_H
#define APLEXEC_H
#include
#include
#define APL_VARIABLE "([⍙∆a-z][⍙∆_a-z0-9]*)"
typedef enum {
APL_OP_EXEC,
APL_O
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 eas
Chris
i don't have qt installed nor do i have your
#include "aplexec.h"
On Fri, 27 Jan 2023 11:23:08 -0500
Chris Moller wrote:
> For what it's worth, in an ongoing project in use:
>
> #include
>
> #include
> #include
>
> #include
>
> #include "aplexec.h"
>
> LI
For what it's worth, in an ongoing project in use:
#include
#include
#include
#include
#include "aplexec.h"
LIBAPL_error
AplExec::aplExec (apl_op_e apl_op, QString &cmd,
QString &outString, QString &errString)
{
LIBAPL_error execerr = LAE_NO_ERRO
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
according to this
--with-android
This option prevents the instantiation of CIN, COUT, and CERR. This maybe
needed when GNU APL is compiled for Android, since Android applicationsare
using a different I/O model than standard C++ programs.
from
https://gist.github.com/houmei/cfd9e570b8de4d8fd
Those variables are C++ variables, so the names are probably mangled. You
can try to change the GNU APL code to declare them as extern "C".
Den sön 15 jan. 2023 07:19 skrev:
> Hi
>
> I'm still trying to resolve the failure of fpc using libapl to get it's
> stdout
>
> trying to get libapl stdout
16 matches
Mail list logo
