Hi
I did it - i have fpc executing apl statements - it was pretty simple - i
already had done something similar for a posits library.
the only 'problem' is that apl uses ' ' single quotes q ;= 'qerqwr'; for
strings so to have a←'a' i need to do 'a←''a''' (double single quote)
or 'a←"a"' (double quote)
r me (red highlight with mismatch quote)
apl can use ' ' or " " for strings but fpc only uses ' ' and using " " for
quotes causes fpc compiler error so ... i have a vim syntax color set for "
quotes so lots of red in the code when i use " "
i'll probably have to make a real apl vim color syntax
On Mon, 5 Aug 2019 11:41:40 -0600
enz...@gmx.com wrote:
> Good afternoon (in Germany?)
>
> > Unfortunately this implies that no only ⎕PW but most likely all other
> > C++ objects are
> > not initialized either.
>
> what other c++ objects are you thinking about? i can test specific apl code
> that is affected by things that are or aren't initialized
>
> ---
>
> i have /usr/local/lib/apl in /etc/ld.so.conf
>
> doesn't seem to be a linker problem at all as the compiled program works with
> either gcc line
>
> f="capl"
> #gcc $f.c -L /usr/local/lib/apl -lapl -o $f -O2
> gcc $f.c -lncurses -lxcb -lpthread -ldl -lm -lsqlite3 -lstdc++
> /usr/local/lib/apl/libapl.a -o $f -O2
>
> ---
>
> so the problem is : not sure why quad_PW is 0 on my machine and 80 on yours
>
> so the the obvious solution is :
>
> Q(quad_PW)
> if (quad_PW == 0) { quad_PW = 80; }
> Q(quad_PW)
>
> and it fixes it in libapl.so for me
>
> i can now call the c function (main renamed to apll and compiled with
>
> gcc -c aplc.c -O2 -> aplc.so
>
> from fpc/pascal extern/cdecl)
>
> as you can see from this c code - it would be a pain to code like this for
> long vs apl script (called from fpc tprocess method)
> return apl_exec("⎕←2 3⍴⍳6 ◊ ⎕←a←'2 3⍴⍳6' ◊ ⎕←⍎a");
>
> but i'll study the lua docs for how they do it from lua directly so i can
> call the apl_exec function directly from libapl in fpc/pascal code without
> the c intermediate .so
>
> i'm not going to recompile the apl binary as i know it works
>
> ---
>
> something else from working on making new libapls.so/libapl.a now
>
> if i make the mistake of make distclean instead of just make
> after i edit the UCS_string.cc file
>
> it seems make distclean doesn't do a proper clean up
>
> so the next configure --with-libapl ; make fails with
> ar: libapl_la-Archive.o: No such file or directory
>
> a new libapl_la-Arvhive.o is not made but the old one exists and has the same
> size as when i don't get the make error - so something else is at work here
>
> if i do a make clean it does a proper clean up so a new libapl.so can
> be made
>
> but neither make distclean nor make clean deletes the
> src/.libs dir
> but the make clean deletes sometime that make distclean doesn't so a
> new libapl.so can be made
>
> if after make clean if i delete the src/.libs dir manually with rm
> -rf src/.libs/* then i get a good libapl.so
>
> but if after make distclean if i delete the src/.libs dir manually with
> rm -rf src/.libs/* then make fails with
> g++: error: .libs/libapl_la-*.o: No such file or directory (* -> it lists
> all the missing files)
>
> using --without-gtk3 has no effect here
>
> ---
>
> thanks Jürgen i much appreciate your help - your c++ code is to complex to
> even look at - it is apl and fpc for me :)
>
> let me know if you need someone to do some configure/make testing for the
> libpython_apl i couldn't get it made
>
> ---
>
> On Mon, 5 Aug 2019 12:16:31 +0200
> Dr. Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote:
>
> > Hi,
> >
> > the output below shows that ⎕PW is not properly initialized. The
> > floating point
> > exception is then raised because the length of an output is divided by
> > ⎕PW in
> > order to get the number of lines for the output.
> >
> > Unfortunately this implies that no only ⎕PW but most likely all other
> > C++ objects are
> > not initialized either.
> >
> > This is most likely a problem with how libapl is being linked (a sort of
> > moving target
> > as far as I understand). It is a bit tricky to set up a machine in such
> > a way that dynamic
> > linking works well.
> >
> > The way I do it is this:
> >
> > 1. make sure that the directory into which libapl.so is installed
> > (/usr/local/lib/apl in most cases)
> > is mentioned in /etc/ld.so.conf.d.
> >
> > 2. compile like this:
> >
> > gcc test_libapl.c -L /usr/local/lib/apl -lapl -o test_libapl
> >
> > 3. On my box it then works:
> >
> > eedjsa@server68:~/apl-1.8/src$ ./test_libapl
> > quad_PW: '80' at UCS_string.cc:340
> > 1 2 3
> > 4 5 6
> >
> > I would strongly suggest to use gcc because compilers and linkers behave
> > quite differently
> > when it comes to dynamic linking. My gcc is this:
> >
> > eedjsa@server68:~/apl-1.8/src$ gcc --version
> > gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
> >
> > Good luck!
> >
> > Jürgen
> >
> >
> >
> > On 8/4/19 7:51 PM, enz...@gmx.com wrote:
> > > Hi
> > >
> > > Hello, World!
> > > quad_PW: '0' at UCS_string.cc:341
> > > ./stc: line 26: 4895 Floating point exception./$f
> > >
> > > ---
> > >
> > > (gdb) run
> > >
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library "/lib/libthread_db.so.1".
> > > Hello, World!
> > > quad_PW: '0' at UCS_string.cc:341
> > >
> > > Program received signal SIGFPE, Arithmetic exception.
> > > 0xb7eb5a22 in UCS_string::UCS_string (this=0xbffff008, pb=..., rank=2,
> > > quad_PW=0) at UCS_string.cc:350
> > > 350 breakpoints.reserve(2*total_width/quad_PW);
> > >
> > > (gdb) bt
> > > #0 0xb7eb5a22 in UCS_string::UCS_string (this=0xbffff008, pb=...,
> > > rank=2, quad_PW=0) at UCS_string.cc:350
> > > #1 0xb7e11fea in PrintBuffer::do_PrintBuffer
> > > (this=this@entry=0xbffff168, value=..., pctx=...,
> > > out=out@entry=0xb7f81a40 <COUT>,
> > > outer_style=outer_style@entry=66560, scaling=..., pcols=...,
> > > item_matrix=item_matrix@entry=0x8073594) at PrintBuffer.cc:414
> > > #2 0xb7e13078 in PrintBuffer::PrintBuffer (this=0xbffff168, value=...,
> > > _pctx=..., out=0xb7f81a40 <COUT>) at PrintBuffer.cc:169
> > > #3 0xb7ecf633 in Value::print (this=0x8074c48, out=...) at Value.cc:1598
> > > #4 0xb7e9615d in Quad_Quad::assign (this=0xb7fc6964
> > > <Workspace::the_workspace+263172>, value=..., clone=true,
> > > loc=0xb7effa50 "Prefix.cc:1665") at SystemVariable.cc:712
> > > #5 0xb7de61a9 in Prefix::reduce_V_ASS_B_ (this=0x8071220) at
> > > Prefix.cc:1665
> > > #6 0xb7dec3b0 in Prefix::reduce_statements (this=this@entry=0x8071220)
> > > at Prefix.cc:675
> > > #7 0xb7e7908a in StateIndicator::run (this=0x8070c00) at
> > > StateIndicator.cc:337
> > > #8 0xb7db2def in Executable::execute_body (this=0x8073028) at
> > > Executable.cc:260
> > > #9 0xb7da99e3 in Command::finish_context () at Command.cc:335
> > > #10 0xb7daa1c9 in Command::do_APL_expression (line=...) at Command.cc:323
> > > #11 0xb7da94e9 in Command::process_line (line=...) at Command.cc:133
> > > #12 0xb7ee7829 in apl_exec (line=0x804899e "⎕←2 3⍴⍳6") at libapl.cc:361
> > > #13 0x080488b1 in main ()
> > > (gdb)
> > >
> > > ---
> > >
> > > On Sun, 4 Aug 2019 18:43:13 +0200
> > > Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote:
> > >
> > >> Hi,
> > >>
> > >> I see. Could you please change src/UCS_string.cc around line 337 to look
> > >> like this:
> > >>
> > >> //-----------------------------------------------------------------------------
> > >> UCS_string::UCS_string(const PrintBuffer & pb, Rank rank, int quad_PW)
> > >> {
> > >>
> > >> Q(quad_PW)
> > >>
> > >> create(LOC);
> > >> ...
> > >>
> > >> I might be that quad_PW is uninitialized for some reason.
> > >>
> > >>
> > >>
> > >> On 8/4/19 6:26 PM, enz...@gmx.com wrote:
> > >>> Hi
> > >>>
> > >>> You started this yesterday emailing me directly - none of this is going
> > >>> to the mailing list
> > >>>
> > >>> (gdb) bt
> > >>> #0 0xb7eb6953 in UCS_string::UCS_string(PrintBuffer const&, int, int)
> > >>> () from /usr/local/lib/libapl.so
> > >>> #1 0xb7e12fea in PrintBuffer::do_PrintBuffer(Value const&,
> > >>> PrintContext const&, std::ostream*, PrintStyle, std::vector<bool,
> > >>> std::allocator<bool> >&, std::vector<PrintBuffer,
> > >>> std::allocator<PrintBuffer> >&, PrintBuffer*) () from
> > >>> /usr/local/lib/libapl.so
> > >>> #2 0xb7e14078 in PrintBuffer::PrintBuffer(Value const&, PrintContext
> > >>> const&, std::ostream*) () from /usr/local/lib/libapl.so
> > >>> #3 0xb7ed0563 in Value::print(std::ostream&) const () from
> > >>> /usr/local/lib/libapl.so
> > >>> #4 0xb7e9715d in Quad_Quad::assign(Value_P, bool, char const*) () from
> > >>> /usr/local/lib/libapl.so
> > >>> #5 0xb7de71a9 in Prefix::reduce_V_ASS_B_() () from
> > >>> /usr/local/lib/libapl.so
> > >>> #6 0xb7ded3b0 in Prefix::reduce_statements() () from
> > >>> /usr/local/lib/libapl.so
> > >>> #7 0xb7e7a08a in StateIndicator::run() () from /usr/local/lib/libapl.so
> > >>> #8 0xb7db3def in Executable::execute_body() const () from
> > >>> /usr/local/lib/libapl.so
> > >>> #9 0xb7daa9e3 in Command::finish_context() () from
> > >>> /usr/local/lib/libapl.so
> > >>> #10 0xb7dab1c9 in Command::do_APL_expression(UCS_string&) () from
> > >>> /usr/local/lib/libapl.so
> > >>> #11 0xb7daa4e9 in Command::process_line(UCS_string&) () from
> > >>> /usr/local/lib/libapl.so
> > >>> #12 0xb7ee8759 in apl_exec () from /usr/local/lib/libapl.so
> > >>> #13 0x080488b1 in main ()
> > >>> (gdb)
> > >>>
> > >>>
> > >>>
> > >>> On Sun, 4 Aug 2019 18:16:25 +0200
> > >>> Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> sorry, forhgot one gdb command (after the fault):
> > >>>>
> > >>>> bt
> > >>>>
> > >>>> Regarduibng html, you can always view the messages under:
> > >>>>
> > >>>> https://lists.gnu.org/archive/html/bug-apl/
> > >>>>
> > >>>> Without HTML they look worse.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 8/4/19 5:15 PM, enz...@gmx.com wrote:
> > >>>> Hi
> > >>>>
> > >>>> you know you are sending email message as html? it gets blocked and i
> > >>>> don't get it as soon as it comes in
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> the gtk configure problem is still there --without-gtk3 has no
> > >>>> effect - i still have to comment out or delete the line in the
> > >>>> configure
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> gcc caplc.c -lapl -lstdc++ -o caplc -O2
> > >>>>
> > >>>> --
> > >>>>
> > >>>> // caplc.c from /fpc/current/apl/html/msg00009.html from
> > >>>> libapl_test.c
> > >>>>
> > >>>> #include <stdio.h>
> > >>>> #include <stdint.h>
> > >>>> //#include <dlfcn.h>
> > >>>> #include <apl/libapl.h> // "/usr/local/include/apl/libapl.h"
> > >>>>
> > >>>> //int main(int argc, const char *argv[])
> > >>>> int main(int argc, char *argv[])
> > >>>> {
> > >>>> // insert code here...
> > >>>> printf("Hello, World!\n");
> > >>>>
> > >>>> init_libapl(argv[0], 0);
> > >>>> //init_libapl("main"i, 0);
> > >>>>
> > >>>> return apl_exec("⎕←2 3⍴⍳6"); <-- Floating point exception.
> > >>>> }
> > >>>>
> > >>>> --
> > >>>>
> > >>>> /fpc/current/apl > ldd caplc
> > >>>> linux-gate.so.1 => (0xb7744000)
> > >>>> libapl.so => /usr/local/lib/libapl.so (0xb744c000)
> > >>>> libstdc++.so.6 => /usr/local/gcc/lib/libstdc++.so.6
> > >>>> (0xb7364000)
> > >>>> libc.so.6 => /lib/libc.so.6 (0xb71ff000)
> > >>>> libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0xb7149000)
> > >>>> libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0xb7122000)
> > >>>> libdl.so.2 => /lib/libdl.so.2 (0xb711c000)
> > >>>> libpthread.so.0 => /lib/libpthread.so.0 (0xb7101000)
> > >>>> libncurses.so.6 => /lib/libncurses.so.6 (0xb70b2000)
> > >>>> libnsl.so.1 => /lib/libnsl.so.1 (0xb7098000)
> > >>>> libm.so.6 => /lib/libm.so.6 (0xb706e000)
> > >>>> libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7053000)
> > >>>> /lib/ld-linux.so.2 (0xb7745000)
> > >>>> libXau.so.6 => /usr/local/lib/libXau.so.6 (0xb704f000)
> > >>>> libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0xb704a000)
> > >>>>
> > >>>> --
> > >>>> /fpc/current/apl > gdb caplc
> > >>>> GNU gdb (GDB) 8.3
> > >>>> Copyright (C) 2019 Free Software Foundation, Inc.
> > >>>> License GPLv3+: GNU GPL version 3 or later
> > >>>> <http://gnu.org/licenses/gpl.html>
> > >>>> This is free software: you are free to change and redistribute it.
> > >>>> There is NO WARRANTY, to the extent permitted by law.
> > >>>> Type "show copying" and "show warranty" for details.
> > >>>> This GDB was configured as "i686-pc-linux-gnu".
> > >>>> Type "show configuration" for configuration details.
> > >>>> For bug reporting instructions, please see:
> > >>>> <http://www.gnu.org/software/gdb/bugs/>.
> > >>>> Find the GDB manual and other documentation resources online at:
> > >>>> <http://www.gnu.org/software/gdb/documentation/>.
> > >>>>
> > >>>> For help, type "help".
> > >>>> Type "apropos word" to search for commands related to "word"...
> > >>>> Reading symbols from caplc...
> > >>>> (gdb) run
> > >>>> Starting program: /fpc/current/apl/caplc
> > >>>> warning: File "/usr/local/gcc-4.8.5/lib/libstdc++.so.6.0.19-gdb.py"
> > >>>> auto-loading has been declined by your `auto-load safe-path' set to
> > >>>> "$debugdir:$datadir/auto-load".
> > >>>> To enable execution of this file add
> > >>>> add-auto-load-safe-path
> > >>>> /usr/local/gcc-4.8.5/lib/libstdc++.so.6.0.19-gdb.py
> > >>>> line to your configuration file "/root/.gdbinit".
> > >>>> To completely disable this security protection add
> > >>>> set auto-load safe-path /
> > >>>> line to your configuration file "/root/.gdbinit".
> > >>>> For more information about this security protection see the
> > >>>> "Auto-loading safe path" section in the GDB manual. E.g., run from
> > >>>> the shell:
> > >>>> info "(gdb)Auto-loading safe path"
> > >>>> [Thread debugging using libthread_db enabled]
> > >>>> Using host libthread_db library "/lib/libthread_db.so.1".
> > >>>> Hello, World!
> > >>>>
> > >>>> Program received signal SIGFPE, Arithmetic exception.
> > >>>> 0xb7eb6953 in UCS_string::UCS_string(PrintBuffer const&, int, int) ()
> > >>>> from /usr/local/lib/libapl.so
> > >>>> (gdb)
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Sun, 4 Aug 2019 11:30:11 +0200
> > >>>> Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> regarding GTK, I found a cut-and-paste error in configure.ac.
> > >>>> Fixed in SVN 1182.
> > >>>>
> > >>>> Regarding test_libapl, if that does not work then nothing else will.
> > >>>> Can you send me the output of:
> > >>>>
> > >>>> ldd test_libapl
> > >>>>
> > >>>> in directory src? Or try:
> > >>>>
> > >>>> gdb test_libapl
> > >>>> run
> > >>>>
> > >>>> and dsend me the output?
> > >>>>
> > >>>> Best Regards,
> > >>>> Jürgen
> > >>>>
> > >>>>
> > >>>> On 8/4/19 5:48 AM, enz...@gmx.com wrote:
> > >>>>
> > >>>>
> > >>>> Hi Jürgen
> > >>>>
> > >>>> Once i got beyond the gtk3 problem using either --with-python or
> > >>>> --without-python gave make errors so they were good to stay away from
> > >>>> -> just like you said
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> to get past my GTK problem i just deleted the line in the configure
> > >>>>
> > >>>> around line 681 there is
> > >>>> HAVE_GTK3_FALSE
> > >>>> HAVE_GTK3_TRUE <- i deleted this line
> > >>>>
> > >>>> -
> > >>>>
> > >>>> so for good libapl.so
> > >>>> configure --with-libapl
> > >>>>
> > >>>> so for good apl just
> > >>>> configure
> > >>>>
> > >>>> both need the gtk configure edit though on my machine
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> do you have any c test programs for libapl.so? the old libapl_test.c i
> > >>>> found gives a floating point exception error
> > >>>>
> > >>>> i can call c code from fpc extern/cdecl so if i have a working c use
> > >>>> of libapl.so ..... it would be a good start
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> On Sat, 3 Aug 2019 20:17:32 +0200
> > >>>> Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> the ./configure defaults for GNU APL are chosen so that it builds with
> > >>>> a minimum
> > >>>> number of dependencies (= libraries).
> > >>>>
> > >>>> For some of the libraries I can use m4 macros (= configure tests) that
> > >>>> are shipped with the
> > >>>> library, and for other libraries I wrote my own ones (less than
> > >>>> perfect).
> > >>>>
> > >>>> Apparently --without options are not reliable and should, for the
> > >>>> reason above, never be
> > >>>> needed.
> > >>>>
> > >>>> The build error is for target for GTK_server and not for GNU APL. As
> > >>>> a work-around
> > >>>> for glady you could try: touch src/GTK_server and then build GNU APL.
> > >>>> It could
> > >>>> very well be that the apl binary was already built in directory src
> > >>>> before the fault.
> > >>>>
> > >>>> Not all configure options are for libapl; option --with-android builds
> > >>>> an apl binary for android,
> > >>>> but without using libapl.
> > >>>>
> > >>>> Its kind of difficult to test the --without build cases, because that
> > >>>> would require to un-install all
> > >>>> the libraries before building (and re-installing after that). What I
> > >>>> would suggest is to install all
> > >>>> the libraries even if you ./configure without using them. That is the
> > >>>> configuration that I use.
> > >>>>
> > >>>>
> > >>>> On 8/3/19 5:05 PM, enz...@gmx.com wrote:
> > >>>>
> > >>>>
> > >>>> Hi
> > >>>>
> > >>>> i got the latest 1181 svn
> > >>>>
> > >>>> You dont need the --without options because that's the default.
> > >>>>
> > >>>> the default for erlang and android are --without
> > >>>> but the --without-erlang has problems that we are aware of
> > >>>> i didn't try the --without-android (are you thinking of a libapl
> > >>>> for land line phones?)
> > >>>>
> > >>>> the default for postgresql appears to also be --without (but not sure
> > >>>> because i have a very non standard pgsql installation and the
> > >>>> configure might just think it isn't installed)
> > >>>>
> > >>>> the --without-sqlite3 works
> > >>>>
> > >>>> the only one that doesn't seem to work is the --without-gtk3 and it
> > >>>> isn't the default <-----
> > >>>>
> > >>>> configure CORE_COUNT_WANTED=2 --with-libapl --with-python
> > >>>>
> > >>>> gives the exact same make error for gtk3 as
> > >>>>
> > >>>> configure CORE_COUNT_WANTED=2 --with-libapl --with-python
> > >>>> --without-gtk3
> > >>>>
> > >>>> -
> > >>>>
> > >>>> the gtk3 make error
> > >>>>
> > >>>> 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);
> > >>>>
> > >>>> gtk_builder_new_from_file was added since gtk3-3.10
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> i need not mention that glady's in accounting said she'd go and have
> > >>>> coffee with me it i had an apl demo by lunch on thursday ,....
> > >>>>
> > >>>> Please help :)
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> On Sat, 3 Aug 2019 11:55:03 +0200
> > >>>> Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote:
> > >>>>
> > >>>> 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
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 8/1/19 3:55 PM, enz...@gmx.com wrote:
> > >>>>
> > >>>> 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.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> >
