Hi Jürgen,
> Regarding fpc it depends on how they have built their C/C++ interface (if > they did). > The last time I used Pascal was the time when the only other programming > language on my platform was BASIC. So I am not really up-to-date with Pascal. > If you want to try it, then I can help with technical information that you > may need. this is the fpc/c/c++ interface guide that i have used for accessing c libs from fpc using c++ in fpc is a lot more complicated - i have 'working examples' from the following guide (hello++.pas) but that is it for c++. ftp://ftp.freepascal.org/pub/fpc/docs-pdf/CinFreePascal.pdf This is an example of the c interface (how i can use 'c/libc' from fpc) this can be your first fpc program!! // sysconf.pas program sysconf; // see man 3 syscon uses ctypes; const _SC_NPROCESSORS_ONLN = 84; // _SC_NPROCESSORS_ONLN The number of processors currently online (available). function sysconf(i: cint): clong; cdecl; external 'c'; // libc unistd.h begin writeln(sysconf(_SC_NPROCESSORS_ONLN), ' cpus : _SC_NPROCESSORS_ONLN'); writeln; end. to compile fpc -XX sysconf.pas # -XX use smart linking to get smallest executable use -gl for generating debug info for gdb and use lineinfo unit --- > The shell approach is fine as long as your programs process a small to medium > amount of data. When the volume of data becomes huge then you have a lot of > overhead (formatting on the shell side and tokenization and optimization on > the > APL side) which can only be avoided by calling directly into the APL > interpreter. so far i've had no problem using cli apl from fpc (there are actually 2 ways depending on if i want to 'trap' and use any apl standard output (aprocess.execute) or not (sysutils.executeprocess) program fpcapl; uses sysutils; var l : ansistring; begin l := '-c "/usr/local/bin/apl --cfg"'; //l := '-c "/apl/workspaces/script.apl"'; // script.apl file has #! /usr/local/bin/apl --script -- then apl code sysutils.executeprocess('/bin/bash', l); // apl standard output just displayed end.
