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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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.
>
>
>
>
>
>
>
>
>
>
>
>
