the libapl (whether fpc/c/python3) appears to be giving it's output to something other then stdoutI/O channels depend on how things were build, see https://gist.github.com/houmei/cfd9e570b8de4d8fd55ada228d5ff004#file-readme-2-configure
i believe i am the only person working with fpc-3.2.2 and apl/libaplOfficial GNU sources for apl do not compile on my setup (debian gcc 12.2). Official GNU apl .deb does not seem to include libapl.
Does anybody have a libapl.dll binary? (pref 64 bit, but 32 bit is acceptable)Does this (https://mirror.koddos.net/gnu/apl/apl-1.8-windows.zip) satisfy your needs ?
Thank you for your header code Thaddy.Alas no, did you get it to work? Seems only the keyboard driver.Does anybody have a libapl.dll binary? (pref 64 bit, but 32 bit is acceptable)Does this (https://mirror.koddos.net/gnu/apl/apl-1.8-windows.zip) satisfy your needs ?
Can you confirm my code works, the wrappers that is?Yeah wrappers work, (just some minor stuff see also rest of my answer)
Alas no, did you get it to work? Seems only the keyboard driver.Sorry. I was not aware the zipfile only contained the keyboard driver. I simply noticed the dll's in there.
Note I am missing some unitialize call. I am sure there must be one, because the dll or shared library uses its own memory management.So far as I am able to see there simply is no uninitialization provided. library's include file header: https://svn.savannah.gnu.org/viewvc/apl/trunk/src/libapl.h?view=markup
Can you post the signature for that? Then I can also add that one too.
If you experience any problems with my code plz inform here, but I am quite confident that it works.The library itself, yeah that is no problem. I've made some minor correction to your (and toby's) code but nothing dramatic (e.g. parameter naming that reflects documentation, and I had to add the name of the library to the external modifier)
About the console output: I probably need to change the APL sourcecode to be able to capture the handles.It uses standard COUT/CERR/CIN.
But that is doable.
of interest : for full display when initializing libapl i useThen you can change 0 to 1 if that is preferred, e.g.:
init_libapl(paramstr(0), 1);
Can you give us the modifications? By the end of the week we have a package :D!No problem. What I have is attached.
I hope you did not touch the wrappers, though: that is pure pascalification and has almost no speed penalty because I inlined it.https://www.youtube.com/watch?v=otCpCn0l4Wo :P
If you want to capture all the output to terminal in Unix OS, you may use FpDup2Yes the last resort is to try redirect all terminal output.
i mistakingly said compiling --with-android made no difference (i forgot to copy the new libapl to /usr/local/lib/apl/libapl.so) before compiling
would setting COUT to stdout be this solution for the stdout problem in the fpc code using libapl?No, unfortunately that would not solve the issue. Its pretty technical, especially on/for Linux. E.g. I am trying to find a better solution but I am also not very well versed in such matters.
Btw, I also had strDispose(), but that is really not necessary because the temp PChar is allocated on the stack and so disappears after the function returns (goes out of scope). StrDispose is to free heap memory, see the documentation for strDispose, temp is stack.Sorry for that.
Please test. If it does not work I will send you a patched libapl. (very crude, but also works)It works. That is the Output is redirected as expected. Thank you for that as I was not aware that you could 'trick' IO that way.
If you use commandline style redirection, either the library function you use needs to execute a shell (like system())) , or you have to specify a shell yourself.Skimming posts can be risky, as is in this case ;)
If you want to capture all the output to terminal in Unix OS, you may use FpDup2Yes the last resort is to try redirect all terminal output.
Your example works as expected (thank you very much for that example code Fred vS).
The only drawback is the need for a file (or files in this case: err and out)
Maybe there is a trick to use a TMemorysteam vs a TFileStream for fpdup2 but I did not find the way.What you need is a THandleStream or descendant (that may behave like a memorystream).
If you use commandline style redirection, either the library function you use needs to execute a shell (like system())) , or you have to specify a shell yourself.Skimming posts can be risky, as is in this case ;)
Your input is appreciated but the used characters have nothing to do with redirection. It is how the APL language itself operates.
TS is trying to retrieve the output from the library (that is emitted to the terminal). I assume he wishes to do that so that the library can be used in a Lazarus GUI program.
It is possible the C++ code does that.The U part error is non-standard user error re-direction and needs a call back afaict. But it is no problem to use a file for that. It is used to report syntax errors etc.
It *should* work.See example named redir2b.pas
Will investigate. I will add the redirect options to the unit when written and tested.appreciated. :thumbsup:
The U part error is non-standard user error re-direction and needs a call back afaict. But it is no problem to use a file for that. It is used to report syntax errors etc.Unfortunately UERR is also used for command output :'(
CIN,COUT and CERR have no problems, nor on windows nor on linux, simple standard OS handles. libapl simply inherits the handles of the pascal process.
Much easier than I thought.
I reacted to the Toby post immediately above it. Should have quoted.Sorry i should have been more explicit.
using apl_command(')help'); is redirectedAnd I understand why (hence my reaction) :)
but apl_exec('2 < 1 1 1'); doesn't
Another tidbit that surfaced while reading through this thread: While I do work on TProcess from time to time, I am not that versed in *nix side of things anymore. But iirc some kinds of redirection there worked on glibc ( or c++ stdlib?) level rather than on handle level. It is possible the C++ code does that.Thank you for that insight. For sure there is something odd there as redirecting stderr to a file (as suggested by Fred vS) has the wanted effect alas it seems that can't be replicated by using other means (at least not to my current knowledge). I could perhaps try using pipes or reroute using another (new created) handle.
Then we need to duplicate the handles....?Sorry, I have to correct myself There. It is not the command output rather the output (apl_exec() result ) from the interpreter that seem to get emitted to UERR.
Fred VS
what about assigning what is written to the file to an ansistring instead or better adding it to a tstringlist.add(...)?
it is possble?
I prefer to link it statically for the time being. Does that work for you?Yes .. and no :D
If not we three need to synchronize our libraries so we are barking all up to the same tree.. :) O:-)No problem for testing purpose I can stick to linking.
btw UERR seems fixed here.Then you are a greater man then I am, because it does not seem to matter what I do as I am simply unable to shut off the chatter of libapl. For some reason FPC does not seem to pick up the chatter on StdErrorHandle for me (even though I explicitly tell it to: example redir2b is wrong in that regards).
thaddy and tron : looks like you weren't able to figure it out and just left it hangingnot leaving it hanging, just requires more in depth research to figure out exactly what is happening internally.
isn't this doable from fpc itself by some combo of thandlestream/fpdup/tmemorystream/tstringstream/loadfromstream/tstream.write programming methods?As you have noticed yourself: no. That is not a problem of FPC perse.
surely some hero fpc programmer here who knows this stuff can do it :)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.
anyone can help get it working properly?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 don't understand your problem with the libapl.so libraryAs a reminder: I do not have a problem with libapl.so, you did ask for help ;D
please post your problem code so i have something to understand what is a problemI don't like repeating myself: see post #42
from a c++ libapl programmer he uses the lineThat has no bearings on the current issues.
LIBAPL_error execerr = LAE_NO_ERROR;
from the apl devI am aware how the library works. You can also do so by using a simple trace.
i get following compile errorah yes, craps. Sorry for that.
are you using a new ulibapl.pas that i do not have ??Yes, but it is no big change (although I have now almost all functions declared) . Only requires one additional function for the example to work.
catch stdout and stderr in an ansistring.Close but no cigar :)
//apl_exec_cb('⍞←rs1', s); // not captured in s ??Those are using an immediate input request. For that you need to use/install a callback with install_get_line_from_user_cb.
apl_exec_cb('⍞←⍕rs1', s); // hot captured in s ??
the ⍕ character is the Monadic format ⍕B A character representation of B U+2355 ⍕Can't comment on that a.t.m. other then If you need a different storing method for the result (f.e. stringlist) then you can create your own callback wrapper function.
the callbacl method takes 96msec for a 30000 integer -> 89999 byte string test result (my largest current use exanple/need) vs 26msec when writing the result to a file with apl and then reading it back into an tstringlist
⎕pw ⍕ problemAre you referring to the plot window functionality ? (e.g. apl is non-case sensitive so that pw = PW ?)
this is not inlcuding the time that would be need to be taked to get rid of the #10 addedAlthough there is little documentation w.r.t. behaviour on certain functionality /this/ is at least a topic that is present in the docs :)
because of the 3x time increase i renamed your apl_exec call back function apl_exec(example, s) to apl_exec_cb(example. s) and 'added' back in the original apl_exec for apl use and only use the apl_exec_cb callback for actualy capture of apl_exec output wnen needed.In that regards you can do whatever you please :) It is encouraged to write your own additions/correction. Only then things can improve
also of major importance is that your apl_exec_cb code does not negatively impact using it with )copy commandYou should have a better/closer look at the other functionality that the apl library exposes.
I can catch output from a pascal file along with errors, hints, or any other information needed, both from stdout and stderr using my previous code.catch stdout and stderr in an ansistring.Close but no cigar :)
Thank you for your effort BobDog but the issue is about catching your own program's I/O. Or to be more precise: the I/O from a library that is used in your program. And it already works (for stdout) except that it seems impossible to do the same for stderr.
I can catch output from a pascal file along with errors, hints, or any other information needed, both from stdout and stderr using my previous code.The code that you showed (thank you for the example) is executing an external program and catches that program's error/output, not its own error and output. You also combined out and err which is a no-go for using this 3th party library. TS also expressed not wanting to use external files.
I really could use a cigar but I have quit smoking, doctor's orders.Smart doctor, smart patient :)
if you do do any additional programming to your ulibapl.pas could you please add it as a new reply to this forum/topic thread instead of as a modified post? thanksI have no problem posting my additions and will do so later. It is just that my code includes dynamic loading which isn't supported by the library so I have to remove that and i haven't had the time to do that yet.
it is easier to check for new replies rather than if a post has been modifiedActually I disagree on that matter. That way I would have to keep track of every post with a published zip in the thread to make sure old attachments are removed. As things progresses, so will the length of the thread so that people have to read through the whole thread to be able to locate the latest attachment. imo keeping old attachments alive works counterproductive as people tend to download old versions then ask about issues that are already solved in a later version and keeping old attachments will needlessly waste forum space.
Tron
looks like you have no problem taking my original libapl work and appropriating it as your own
pretty sad
APL Library itself published under the GNU General Public License
All Pascal related files in this archive are licensed as "Pay it forward"
Tron@toby:
looks like you have no problem taking my original libapl work and appropriating it as your own
pretty sad