Hi,
configure CORE_COUNT_WANTED=2 --with-libapl --without-sqlite3 --without-postgresql --without-gtk3 --without-android --without-erlang --without-python
works for me. It will create a compiler error which I have fixed in
SVN 1181.
I also updated README-10-python with the proper ./configure
option.
You dont need the --without options because that's the
default. Something looks
fishy with the --with-erlang=no
option because despite of it ./configure says "yes"
instead. This could be a problem with the top-level configure.ac.
Please try to
./configure without mentioning erlang (or any other module that is
not used by
default).
the make distclean errors are harmless; they occur because make
distclean tries
to remove files which were supposedly created during the build (but
are missing
if the build fails for some reason).
If I remember correctly then libapl_test can fail if not properly
linked.
Check it with ldd.
If there are more problems, then please keep me posted.
Best Regards,
Jürgen Sauermann
8/1/9
Hi
after getting the latest svn revision 1180 on 8/1/19
i get the exact same configure problems as with the gnuapl-1.8 tar ball as listed below - i can't believe i'm the only one?
configure CORE_COUNT_WANTED=2 --with-libapl --without-sqlite3 --without-postgresql --without-gtk3 --without-android --without-erlang --without-python
also make distclean gives a tremendous number of errors that probably shouldn't be there (never seen before in other projects) so i have to use fresh source for each configure
also from the README-10-python configure --with-libpython_apl
gives : configure: WARNING: unrecognized options: --with-libpython_apl
---
7/30/19
Hi,
I (as the one user you reference) have no real need for it as i said - i use the fpc tprocess coding for it - i use apl --script as a matrix engine (inner and outer product with unquote dynamic code design)
just exploring using libapl.so you didn't respond to if there is any libapl.so use code for c (surely the most popular computer language) all i found was the
libapl_test.c but i get a Floating point exception when run so i am now updating my apl to get a current libapl.so and now have configure/make problems with apl-1.8
the configure options don't work as wanted
---
the apl-1.8 configure has
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--
configure CORE_COUNT_WANTED=2 --with-libapl --without-sqlite3 --without-postgresql --without-gtk3 --without-android --without-erlang --with-python
from configure output
checking if we are compiling for Android... yes
checking if we want to build an erlang interface (implies libapl.so)... yes
make
make[2]: Entering directory `/transfer/usr.src/apl/1.8/apl-1.8/erlang'
erlc apl.erl
make[2]: erlc: Command not found
make[2]: *** [apl.beam] Error 127
--
configure CORE_COUNT_WANTED=2 --with-libapl --with-sqlite3=no --with-postgresql=no --with-gtk3=no --with-android=no --with-erlang=no --with-python
from configure output
checking if we are compiling for Android... yes
checking if we want to build an erlang interface (implies libapl.so)... yes
make
make[2]: Entering directory `/transfer/usr.src/apl/1.8/apl-1.8/erlang'
erlc apl.erl
make[2]: erlc: Command not found
make[2]: *** [apl.beam] Error 127
---
configure CORE_COUNT_WANTED=2 --with-libapl --with-sqlite3=no --with-postgresql=no --with-gtk3=no --with-android=no --with-python
make
Gtk_server.cc: In function 'void cmd_1_load_GUI(const char*)':
Gtk_server.cc:238:48: error: 'gtk_builder_new_from_file' was not declared in this scope
builder = gtk_builder_new_from_file(filename);
---
---
On Tue, 30 Jul 2019 13:14:21 +0200
Dr. Jürgen Sauermann <address@hidden> wrote:
Hi,
I am not criticising freepascal in any way. My point is simply that the number of users for
which a combination of Pascal and APL makes sense is rather small (maybe one ?) and
that such an interface should therefore rather be constructed by those users rather than
by myself.
Juergen
On 7/29/19 10:33 PM, address@hidden wrote:
freepascal is as modern a language as it gets my friend - why you have a problem with it is beyond me - but to be honest not very professional of you now, is it, considering i run into more anti-apl then anti-freepascal programmers and i just wallop them all senseless
anyway - i have been running apl as a script in freepascal for years and it is the greatest combination of coding there is - no real need to use libapl.so/libapl.h anyway - right now it would be run as c code anyway as a cdecl extern. (but if you do have any c code that runs libapl.so/libapl.h with unquote or inner product or outer product - i would love it - can't find any on the internet - or any real usefull code to be honest)
with the unquote function and ease of inner and outer product etc matrix functions - coupled with fpc being compiled and having complete control over processes
https://www.freepascal.org/docs-html/current/fcl/process/tprocess.htm
and threading and [trtl]tcriticalseciton and fpflock mutexes (there are a number of ways to perform parallal and threading programming and mutex on files and code sections)
https://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial
https://www.freepascal.org/docs-html/rtl/system/trtlcriticalsection.html
https://www.freepascal.org/docs-html/current/fcl/syncobjs/tcriticalsection.html
and libcurl units, openssl units - and hundreds if not thousands more (okay maybe not thousands) ,,,,,,
sorry - i gotta take a rest now ... can't get to excited ,,, doctors orders ,,,
On Wed, 17 Jul 2019 12:30:05 +0200
Dr. Jürgen Sauermann <address@hidden> wrote:
Most of us are reaching the ends of our life cycles, so we
should not lol too loudly. Iverson was born 9 years before Wirth,
so he has all rights to leave first. By the same token, at the time when
Pascal was invented, Iverson had 9 years more working experience.
If I remember correctly (Pascal was a hot topic at that time) then Wirth
never meant Pascal to be a programming language but rather a somewhat
simplified syntax to teach compiler construction. I was only later when some
people misunderstood it as a being programming language. Given the languages
affordable at that time (BASIC and machine code without an assembler),
the mistake is excusable, but we should learn from our mistakes and not
perpetuate them.
BR,
Jürgen
On 7/15/19 8:07 PM, address@hidden wrote:
really since apl is older then pascal (excluding algol( i think you got it backwards with number of deceased
nicklaus wirth is still around what about iverson? lol
On Thu, 27 Jun 2019 18:37:41 +0200
Dr. Jürgen Sauermann <address@hidden> wrote:
sure. But I would bet that today the number of python users is at least
two magnitudes greater
than the number of Pascal users (not counting those who have ceased to
exist since Pascal
was invented).
On 6/27/19 5:37 PM, address@hidden wrote:
a grand geocentric (aplcentric) point of view indeed - i'm pretty sure the number of pascal users is orders of magnitude greater then the number of apl programmers
On Tue, 18 Jun 2019 22:10:20 +0200
Dr. Jürgen Sauermann <address@hidden> wrote:
Hi,
I believe that extending some language X with an interface to APL makes only
sense if:
1. language X is popular or at least is gaining popularity, and
2. (GNU-) APL can provide an advantage in an area where language X is weak.
According to http://statisticstimes.com/tech/top-computer-languages.php
and others, C/C++ and python are the most frequently used languages
today, with Erlang and Pascal having a far lower popularity (although
probably increasing for Erlang but decreasing for Pascal).
Erlang and Python are both weak for large vectors and even weaker for
arrays with higher ranks. Reason is the linked list structure that they use
for vectors.
Now to Pascal: it is not popular and is not weak in a particular area (being
weak in total does not count here). A further difficulty is the need to declare
the data types of variables beforehand, which does not fit well to the dynamic
typing of APL. Python and Erlang are both dynamically type and therefore
this problem does not exist for them.
For that reason you are on your own when it comes to extending Pascal with
GNU APL. I will be glad to help you with technical advice how to do that and
how GNU APL works internally, but I would prefer not be involved in building
such an interface.
Best regards,
Jürgen
On 6/17/19 5:05 PM, address@hidden wrote:
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.
|