Re: sqlite3 on macOS

[Peter Teeson]

Hi Jürgen:

 My recollection is that Apple used to distribute a number of command line apps 
for developers and did put them in the correct dirs.
They stopped distributing svn and also sql around 2017.
I wonder if we should document the README prerequisite about this issue? 

Gandalf:trunk pteeson$ ./configure --with-sqlite3=/usr/local/opt/sqlite3
checking for gcc... gcc
……..
checking for __atomic_fetch_add_4 in -latomicity... no
checking for SQLite3 library >= 3.0.0... yes
checking for pg_config... no

repeat

Peter

> On Oct 5, 2022, at 10:43 AM, Dr. Jürgen Sauermann 
>  wrote:
> 
> Hi Peter,
> 
> thanks. A closer look into the m4/ax_lib_sqlite3.m4 macro reveals two 
> problems, which apparently only
> occurs on macOS:
> 
> 1. The m4 macro looks for include/sqlite3.h only in the directories  /usr, 
> /usr/local, and /opt,
> while macOS decides to install in  /usr/local/opt. Therefore sqlite.h is not 
> found even
> though it exists. In defence of the m4 script I should mention that, 
> according to the
> Linux File Hierarchy Standard (aka. FHS), /usr/local/opt is not a suitable 
> location for
> that file and the fault is more on the macOS side.
> 
> 2. The m4 macro is faulty when sqlite.h is not found. This is due to a quirk 
> in bash. In the
> bash shell you can compare two strings or string variables. However if any of 
> the two strings
> is empty (like it happens when sqlite.h is not found) then the comparison 
> does not return
> an equal or not equal result, but instead raises the syntax error (on line 
> 19090) that you
> see below.
> 
> Both problems should be fixed in SVN 1593 now.
> 
> BTW installation mismatches caused by non-standard installation directories 
> can
> sometimes (!) be fixed by ./configure options. In the above case something 
> along the
> lines of
> 
> ./configure --with-sqlite3=/usr/local/opt 
> 
> may have worked (whether it does or does not work depends entirely on the m4 
> macro).
> 
> Best Regards,
> Jürgen
> 
> 
> On 10/3/22 11:29 PM, Peter Teeson wrote:
>> Hi Jürgen:
>> I started with an empty dir, downloaded current version 1592, and 
>> ./configure. Same warning.
>>  
>> The m4/ax_lib_sqllite3.m4 says:
>> 
>> "dnl If no intallation prefix to the installed SQLite library is given
>> dnl the macro searches under /usr, /usr/local, and /opt."
>> 
>> Gandalf:~ pteeson$ cd /usr/local/opt/sqlite3/include
>> Gandalf:include pteeson$ ls -al sql*
>> -rw-r--r--  1 502  staff  581196 18 Jun  2020 sqlite3.h
>> -rw-r--r--  1 502  staff   35269 18 Jun  2020 sqlite3ext.h
>> 
>> checking for SQLite3 library >= 3.0.0... yes
>> cat: /include/sqlite3.h: No such file or directory
>> ./configure: line 19090: test: !=: unary operator expected <==
>> configure: WARNING: Can not find SQLITE_VERSION macro in sqlite3.h header to 
>> retrieve SQLite version!
>> 
>> I found it in the header
>> #define SQLITE_VERSION"3.32.3"
>> #define SQLITE_VERSION_NUMBER 3032003
>> #define SQLITE_SOURCE_ID  "2020-06-18 14:00:33 
>> 7ebdfa80be8e8e73324b8d66b3460222eb74c7e9dfd655b48d6ca7e1933cc8fd"
>> 
>> So I do not know how to proceed further to help isolate what’s up.
>> 
>> respect…
>> 
>> Peter
>> 
>>> On Oct 3, 2022, at 8:12 AM, Dr. Jürgen Sauermann 
>>> mailto:m...@xn--jrgen-sauermann-zvb.de>> 
>>> wrote:
>>> 
>>> Hi Peter,
>>> 
>>> thanks for reporting this. It looks like the m4/ax_lib_sqlite3.m4 macro 
>>> shipped with
>>> GNU APL has been outdated over time. I have updated it from a more recent
>>> version from here:
>>> 
>>> https://ac-archive.sourceforge.net/ac-archive/ax_lib_sqlite3.m4 
>>> <https://ac-archive.sourceforge.net/ac-archive/ax_lib_sqlite3.m4>
>>> 
>>> I hope this fixes the problem at your end, please let me know.
>>> 
>>> Best Regards,
>>> Jürgen
>>> 
>>> 
>>> On 10/2/22 11:03 PM, Peter Teeson wrote:
>>>> Hi Jürgen:
>>>> 
>>>> Doing some investigation I came across this(see my comments below):
>>>> 
>>>> ./configure
>>>> …….
>>>> checking for SQLite3 library >= 3.0.0... yes
>>>> cat: /include/sqlite3.h: No such file or directory
>>>> ./configure: line 19132: test: !=: unary operator expected
>>>> configure: WARNING: Cannot find SQLITE_VERSION macro in sqlite3.h header 
>>>> to retrieve SQLite version!
>>>> 
>>>> locate sqlite
>>>&g

Re: sqlite3 on macOS

[Peter Teeson]

Hi Jürgen:

Sadly Apple’s favourite song seems to be “I did it my way!” 
(I am on Mojave 10.14 - and unable to install later releases without patching, 
which I don’t do.)

Referring to my 31 March 2021 email — Re: Notes about git-svn source control in 
macOS:
"macOS Catalina 10.15 Command line tool support for Subversion — including svn, 
git-svn, and related commands — 
is no longer provided by Xcode. (50266910)”

Based on the above my conclusion is that: 

if you are an Apple developer using macOS version  >= Catalina 10.15 you need 
to install either svn or git yourself!
I think this also apples to sqlite3.

respect….

Peter

> On Oct 8, 2022, at 1:29 PM, Dr. Jürgen Sauermann 
>  wrote:
> 
> Hi Peter,
> 
> yes, we could document this. However, I am lacking the necessary information 
> to do so.
> As far as SVN is concerned, it should now also be possible to use git (with 
> some minor
> quirks due to the lack of SVN version numbers).
> 
> Best Regards,
> Jürgen
> 
> 
> On 10/5/22 11:32 PM, Peter Teeson wrote:
>> Hi Jürgen:
>> 
>>  My recollection is that Apple used to distribute a number of command line 
>> apps for developers and did put them in the correct dirs.
>> They stopped distributing svn and also sql around 2017.
>> I wonder if we should document the README prerequisite about this issue? 
>> 
>> Gandalf:trunk pteeson$ ./configure --with-sqlite3=/usr/local/opt/sqlite3
>> checking for gcc... gcc
>> ……..
>> checking for __atomic_fetch_add_4 in -latomicity... no
>> checking for SQLite3 library >= 3.0.0... yes
>> checking for pg_config... no
>> 
>> repeat
>> 
>> Peter
>> 
>>> On Oct 5, 2022, at 10:43 AM, Dr. Jürgen Sauermann 
>>> mailto:m...@xn--jrgen-sauermann-zvb.de>> 
>>> wrote:
>>> 
>>> Hi Peter,
>>> 
>>> thanks. A closer look into the m4/ax_lib_sqlite3.m4 macro reveals two 
>>> problems, which apparently only
>>> occurs on macOS:
>>> 
>>> 1. The m4 macro looks for include/sqlite3.h only in the directories  /usr, 
>>> /usr/local, and /opt,
>>> while macOS decides to install in  /usr/local/opt. Therefore sqlite.h is 
>>> not found even
>>> though it exists. In defence of the m4 script I should mention that, 
>>> according to the
>>> Linux File Hierarchy Standard (aka. FHS), /usr/local/opt is not a suitable 
>>> location for
>>> that file and the fault is more on the macOS side.
>>> 
>>> 2. The m4 macro is faulty when sqlite.h is not found. This is due to a 
>>> quirk in bash. In the
>>> bash shell you can compare two strings or string variables. However if any 
>>> of the two strings
>>> is empty (like it happens when sqlite.h is not found) then the comparison 
>>> does not return
>>> an equal or not equal result, but instead raises the syntax error (on line 
>>> 19090) that you
>>> see below.
>>> 
>>> Both problems should be fixed in SVN 1593 now.
>>> 
>>> BTW installation mismatches caused by non-standard installation directories 
>>> can
>>> sometimes (!) be fixed by ./configure options. In the above case something 
>>> along the
>>> lines of
>>> 
>>> ./configure --with-sqlite3=/usr/local/opt 
>>> 
>>> may have worked (whether it does or does not work depends entirely on the 
>>> m4 macro).
>>> 
>>> Best Regards,
>>> Jürgen
>>> 
>>> 
>>> On 10/3/22 11:29 PM, Peter Teeson wrote:
>>>> Hi Jürgen:
>>>> I started with an empty dir, downloaded current version 1592, and 
>>>> ./configure. Same warning.
>>>>  
>>>> The m4/ax_lib_sqllite3.m4 says:
>>>> 
>>>> "dnl If no intallation prefix to the installed SQLite library is given
>>>> dnl the macro searches under /usr, /usr/local, and /opt."
>>>> 
>>>> Gandalf:~ pteeson$ cd /usr/local/opt/sqlite3/include
>>>> Gandalf:include pteeson$ ls -al sql*
>>>> -rw-r--r--  1 502  staff  581196 18 Jun  2020 sqlite3.h
>>>> -rw-r--r--  1 502  staff   35269 18 Jun  2020 sqlite3ext.h
>>>> 
>>>> checking for SQLite3 library >= 3.0.0... yes
>>>> cat: /include/sqlite3.h: No such file or directory
>>>> ./configure: line 19090: test: !=: unary operator expected <==
>>>> configure: WARNING: Can not find SQLITE_VERSION macro in sqlite3.h header 
>>>> to retrieve SQLite version!
>>>> 
>>>> I found it in the hea

Re: sqlite3 on macOS

[Peter Teeson]

Hi Jürgen:

Thanks for the latest additions to README-1.  respect… Peter

> On Oct 10, 2022, at 8:32 AM, Dr. Jürgen Sauermann 
>  wrote:
> 
> Hi Peter,
> 
> thanks, I updated README-1-prerequisites. There seems to be no difference 
> between maxOS
> and GNU/Linux: in both you have to install svn manually. Not sure about git 
> because I cant
> remember if it was there initially or if I installed it later on.
> 
> Best Regards,
> Jürgen
> 
> 
> On 10/8/22 9:50 PM, Peter Teeson wrote:
>> Hi Jürgen:
>> 
>> Sadly Apple’s favourite song seems to be “I did it my way!” 
>> (I am on Mojave 10.14 - and unable to install later releases without 
>> patching, which I don’t do.)
>> 
>> Referring to my 31 March 2021 email — Re: Notes about git-svn source control 
>> in macOS:
>> "macOS Catalina 10.15 Command line tool support for Subversion — including 
>> svn, git-svn, and related commands — 
>> is no longer provided by Xcode. (50266910)”
>> 
>> Based on the above my conclusion is that: 
>> 
>> if you are an Apple developer using macOS version  >= Catalina 10.15 you 
>> need to install either svn or git yourself!
>> I think this also apples to sqlite3.
>> 
>> respect….
>> 
>> Peter
>> 
>>> On Oct 8, 2022, at 1:29 PM, Dr. Jürgen Sauermann 
>>> mailto:m...@xn--jrgen-sauermann-zvb.de>> 
>>> wrote:
>>> 
>>> Hi Peter,
>>> 
>>> yes, we could document this. However, I am lacking the necessary 
>>> information to do so.
>>> As far as SVN is concerned, it should now also be possible to use git (with 
>>> some minor
>>> quirks due to the lack of SVN version numbers).
>>> 
>>> Best Regards,
>>> Jürgen
>>> 
>>> 
>>> On 10/5/22 11:32 PM, Peter Teeson wrote:
>>>> Hi Jürgen:
>>>> 
>>>>  My recollection is that Apple used to distribute a number of command line 
>>>> apps for developers and did put them in the correct dirs.
>>>> They stopped distributing svn and also sql around 2017.
>>>> I wonder if we should document the README prerequisite about this issue? 
>>>> 
>>>> Gandalf:trunk pteeson$ ./configure --with-sqlite3=/usr/local/opt/sqlite3
>>>> checking for gcc... gcc
>>>> ……..
>>>> checking for __atomic_fetch_add_4 in -latomicity... no
>>>> checking for SQLite3 library >= 3.0.0... yes
>>>> checking for pg_config... no
>>>> 
>>>> repeat
>>>> 
>>>> Peter
>>>> 
>>>>> On Oct 5, 2022, at 10:43 AM, Dr. Jürgen Sauermann 
>>>>> >>>> <mailto:m...@xn--jrgen-sauermann-zvb.de>> wrote:
>>>>> 
>>>>> Hi Peter,
>>>>> 
>>>>> thanks. A closer look into the m4/ax_lib_sqlite3.m4 macro reveals two 
>>>>> problems, which apparently only
>>>>> occurs on macOS:
>>>>> 
>>>>> 1. The m4 macro looks for include/sqlite3.h only in the directories  
>>>>> /usr, /usr/local, and /opt,
>>>>> while macOS decides to install in  /usr/local/opt. Therefore sqlite.h is 
>>>>> not found even
>>>>> though it exists. In defence of the m4 script I should mention that, 
>>>>> according to the
>>>>> Linux File Hierarchy Standard (aka. FHS), /usr/local/opt is not a 
>>>>> suitable location for
>>>>> that file and the fault is more on the macOS side.
>>>>> 
>>>>> 2. The m4 macro is faulty when sqlite.h is not found. This is due to a 
>>>>> quirk in bash. In the
>>>>> bash shell you can compare two strings or string variables. However if 
>>>>> any of the two strings
>>>>> is empty (like it happens when sqlite.h is not found) then the comparison 
>>>>> does not return
>>>>> an equal or not equal result, but instead raises the syntax error (on 
>>>>> line 19090) that you
>>>>> see below.
>>>>> 
>>>>> Both problems should be fixed in SVN 1593 now.
>>>>> 
>>>>> BTW installation mismatches caused by non-standard installation 
>>>>> directories can
>>>>> sometimes (!) be fixed by ./configure options. In the above case 
>>>>> something along the
>>>>> lines of
>>>>> 
>>>>> ./configure --with-sqlite3=/usr/local/opt 
>>>>> 
>&g

Re: Latin-American APL keyboard layout?

[Peter Teeson]

There is this marvellous utility that I have used. It might be helpful. 
https://software.sil.org/ukelele/ 

If the user is on an Apple Mac then this extract from the Installation Guide 
may be helpful.

Keyboard Setup
To make the keyboard work correctly with the APL interpreter we need two things 
- a correct APL font and a mapping of the keyboard key codes. Fortunately these 
are both available. The fonts I used are from 
http://dyalog.com/apl-font-keyboard.htm. Here is a quote from that page:

This page contains resources that are believed to be of general
interest to the APL community. The fonts are freely available,
to everyone irrespective of whether you use Dyalog
(or any other APL system for that matter).
Indeed they are and we applaud Dyalog for making them available.


(1) Installing the APL Fonts. Download the APL385 font, and also APL333 if you 
want a proportional version. You can save them in your usual download place and 
manually install them. Alterately when prompted select the default Open with 
Font Book. Installing it in /Library/Fonts/ will make it available to all 
Accounts on this computer. In my case I placed it in my user account at 
~/Library/Fonts/ instead. That was easy.

(2) A keyboard layout. There is one available on the same web page but it is 
for UK Dyalog users. For GNU APL there is a recommended one provided in the 
distribution which fully matches that displayed with the ]keyb command. You can 
find it in the support-files folder in the OS-X-keyboard folder. It is the 
MacAplAlt.keylayout file.

You install it by copying it to /Library/Keyboard Layouts which makes it 
available for all users or ~/Library/Keyboard Layouts for just that user.

(3) Terminal Settings Terminal Help gives instructions for these. However you 
might not want to use the defauts.. My personal preference is to make a new 
Profile from the Preferences Profiles menu by selecting New Window and then 
choosing MacAplAlt. Set the Font attributes using the Text tab in the Profiles 
window.

(4) Using Terminal with APL Start a Terminal window and, from the Input Source 
(a.k.a. Language) menu, top right on the Menu Bar, select MacAplAlt. Also 
select Show Keyboard Viewer from the same menu. Now you can see the key 
mappings; press the alt key and voila your familiar APL symbols. Try Shift+Alt 
to get the rest. Type apl in the terminal window and enjoy.

respect….

Peter
> On Oct 12, 2022, at 9:14 AM, Dr. Jürgen Sauermann 
>  wrote:
> 
> Hi Russ,
> 
> I am no expert in foreign keyboard layouts, and in particular not in 
> Latin-American ones.
> However, I found the following program in Linux Mint (and supposedly also in 
> Ubuntu and
> other GNU/Linux distributions) useful:
> 
> *gkbd-keyboard-display -l *
> 
> where  is probably one of those in */usr/share/X11/xkb/symbols/**
> 
> Also have a look here:
> 
> *https://kbdlayout.info/KBDLA/**
> *
> As a programmer I very much dislike country-specific keyboard layouts. In the 
> 1990s,
> my Swedish employer wanted me to translate a technical document from English
> to German on a PC with a Swedish keyboard. Almost drove me crazy.
> 
> I would also propose that the APL characters should be the same on all 
> keyboards.
> 
> Best Regards,
> Jürgen
> 
> 
> On 10/12/22 6:35 AM, Russtopia wrote:
>> Hello,
>> 
>> I was asked today by someone from Chile about APL layouts for Latin-American 
>> keyboards.
>> 
>> It seems the ; : + * " / symbols are placed differently, which would make 
>> for problematic mapping wrt. the US layout. Has anyone come up with a good 
>> 'standard' layout for this region? (Interestingly there appears to be an 
>> 'each' ¨ already there, right of the 'P' key, as shift-comma).
>> 
>> Dyalog's keyboard pages do not seem to address such a layout.
>> 
>> See an example layout here: 
>> https://howtoperu.com/wp-content/uploads/2010/06/how-to-ty...@-latin-american-keyboard.png
>>  
>> 
>> 
>> -Russ
>> 
> 
> 

Re: Still some issues/warnings..

[Peter Teeson]

STAT(1)   BSD General Commands Manual  STAT(1)

NAME
 readlink, stat -- display file status

SYNOPSIS
 stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file ...]
 readlink [-n] [file ...]
……
  -f format
 Display information using the specified format.  See the FORMATS 
section for
 a description of valid formats.



> On Oct 18, 2022, at 2:39 PM, Dr. Jürgen Sauermann 
>  wrote:
> 
> Hi Peter,
> 
> I will look deeper into this. At first a glance, MacOS binaries seem to be 
> incompatible with
> proper ones (e.g. -f is a valid option for my readlink command).
> 
> he clan warning looks bogus (see end of README-11-bogus-compiler-warnings
> as to how to fix this with ./configure.
> 
> The problem with Doxygen is this: if I run doxygen then I can read all
> generated files with both firefox and with chromium - no problem.
> 
> If I then copy all files to some web server directory, then, depending
> on both the web server and on the browser:
> 
> * neither chromium nor firefox renders them properly, or
> * chromium renders them properly, but firefox does not (and complains
> about CORS issues).
> 
> I suspect this either caused by the web server configuration and/or by how
> doxygen works. If I browse the *savannah SVN repository* then chromium
> renders the files properly, but firefox does not. If I browse the
> *savannah git repository* (which uses a different wbb server setup) then
> neither firefox nor chromium renders the files properly. In both cases all
> Doxygen files are present.
> 
> Best regards,
> Jürgen
> 
> 
> On 10/18/22 8:03 PM, Peter Teeson wrote:
>> Hi Jürgen:
>> 
>> Thanks for the latest svn 1603. We still have issues. Log file attached.
>> E.G.  Note lines 307, 336 et seq, 649 et seq, 741 et seq,  ….
>> 
>> 
>> respect
>> 
>> Peter
>> 
>> P.S. In the past I was able to use Firefox to examine the Doxygen generated 
>> html files….
>> When we have dealt with the present issues I will run Doxygen and check what 
>> happens.
>> 
> 
> 

Re: Still some issues/warnings..

[Peter Teeson]

configure: creating buildtag.hh...
readlink: illegal option -- f

>  [-f format 

HYH

> On Oct 18, 2022, at 4:04 PM, Peter Teeson  wrote:
> 
> STAT(1)   BSD General Commands Manual  STAT(1)
> 
> NAME
>  readlink, stat -- display file status
> 
> SYNOPSIS
>  stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file ...]
>  readlink [-n] [file ...]
> ……
>   -f format
>  Display information using the specified format.  See the FORMATS 
> section for
>  a description of valid formats.
> 
> 
> 
>> On Oct 18, 2022, at 2:39 PM, Dr. Jürgen Sauermann 
>> mailto:m...@xn--jrgen-sauermann-zvb.de>> 
>> wrote:
>> 
>> Hi Peter,
>> 
>> I will look deeper into this. At first a glance, MacOS binaries seem to be 
>> incompatible with
>> proper ones (e.g. -f is a valid option for my readlink command).
>> 
>> he clan warning looks bogus (see end of README-11-bogus-compiler-warnings
>> as to how to fix this with ./configure.
>> 
>> The problem with Doxygen is this: if I run doxygen then I can read all
>> generated files with both firefox and with chromium - no problem.
>> 
>> If I then copy all files to some web server directory, then, depending
>> on both the web server and on the browser:
>> 
>> * neither chromium nor firefox renders them properly, or
>> * chromium renders them properly, but firefox does not (and complains
>> about CORS issues).
>> 
>> I suspect this either caused by the web server configuration and/or by how
>> doxygen works. If I browse the *savannah SVN repository* then chromium
>> renders the files properly, but firefox does not. If I browse the
>> *savannah git repository* (which uses a different wbb server setup) then
>> neither firefox nor chromium renders the files properly. In both cases all
>> Doxygen files are present.
>> 
>> Best regards,
>> Jürgen
>> 
>> 
>> On 10/18/22 8:03 PM, Peter Teeson wrote:
>>> Hi Jürgen:
>>> 
>>> Thanks for the latest svn 1603. We still have issues. Log file attached.
>>> E.G.  Note lines 307, 336 et seq, 649 et seq, 741 et seq,  ….
>>> 
>>> 
>>> respect
>>> 
>>> Peter
>>> 
>>> P.S. In the past I was able to use Firefox to examine the Doxygen generated 
>>> html files….
>>> When we have dealt with the present issues I will run Doxygen and check 
>>> what happens.
>>> 
>> 
>> 
> 

Re: Still some issues/warnings..

[Peter Teeson]

Hi Jürgen:

So sorry but we’re not done yet…… respect Peter

Gandalf:~ pteeson$ cd /Volumes/Data/GNUAPL-on-Mac-WS/GNUapl 
Gandalf:GNUapl pteeson$ svn co http://svn.savannah.gnu.org/svn/apl/trunk > 
svn-log 2>&1
Atrunk/doc
...
Atrunk/tools/sockconst.c
Checked out revision 1605.


Gandalf:~ pteeson$ which realpath
Gandalf:~ pteeson$ 
Gandalf:~ pteeson$ which readlink
/usr/bin/readlink


configure: creating buildtag.hh...
./configure: line 23140: realpath: command not found
configure: top-level apl directory is: 
configure: removing old ./makefile.h
 
Gandalf:trunk pteeson$ make
creating a fresh makefile.h...
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in workspaces
…..
Making all in DALY
make[3]: Nothing to be done for `all'.
/bin/sh /Volumes/Data/GNUAPL-on-Mac-WS/GNUapl/trunk/missing makeinfo 
libapl.texi -o libapl.info --no-split || touch libapl.info
/bin/sh /Volumes/Data/GNUAPL-on-Mac-WS/GNUapl/trunk/missing makeinfo --html 
libapl.texi -o libapl.html --no-split || touch libapl.html
Making all in erlang
…..
Making all in server
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
make[2]: Nothing to be done for `all-am'.
Gandalf:trunk pteeson$ 

> On Oct 19, 2022, at 7:42 AM, Dr. Jürgen Sauermann 
>  wrote:
> 
> Hi Peter,
> 
> thanks for reporting this.
> 
> Line 304 should be fixed now by replacing readlink -f with realpath.
> Line 336 ff. seems to be an issue with your makeinfo version (mine is 6.5
> and I am not getting these warnings),
> Line 649 ff. and 741 ff. should be fixed (in m4/ax_lib_sqlite3.m4).
> 
> SVN 1604.
> 
> Best Regards,
> Jürgen
> 
> 
> On 10/18/22 8:03 PM, Peter Teeson wrote:
>> Hi Jürgen:
>> 
>> Thanks for the latest svn 1603. We still have issues. Log file attached.
>> E.G.  Note lines 307, 336 et seq, 649 et seq, 741 et seq,  ….
>> 
>> 
>> 
>> respect
>> 
>> Peter
>> 
>> P.S. In the past I was able to use Firefox to examine the Doxygen generated 
>> html files….
>> When we have dealt with the present issues I will run Doxygen and check what 
>> happens.
>> 
> 

Re: Still some issues/warnings..

[Peter Teeson]

Hi Jürgen:

Something strange seems to be happening in ./configure but I don’t know how to 
trace it.
i.e. track down why we are having a problem. 

realpath is not in /usr/bin.

But readlink and dirname are in /usr/bin. 
So calls to those functions should work.

Can we make a small test example calling them to see?

respect

Peter

== background status information
Gandalf:~ pteeson$ which readlink
/usr/bin/readlink
Gandalf:~ pteeson$ ls -al /usr/bin/readlink
-rwxr-xr-x1 root   wheel  27520 20 Sep  2019 readlink

Gandalf:~ pteeson$ which dirname
/usr/bin/dirname
Gandalf:~ pteeson$ ls -al /usr/bin/dirname
-rwxr-xr-x  1 root  wheel  18128 20 Sep  2019 /usr/bin/dirname

== Below is the latest issue.
Gandalf:~ pteeson$ cd /usr/local/lib 
Gandalf:lib pteeson$ ls -al -print
…
 445346 drwxr-xr-x   17 00   578 16 Jun 00:49 ../
4252737 -rwxr-xr-x1 501  80  953 17 Oct 16:05 libsqlite3.la
4252736 lrwxr-xr-x1 501  80   18 17 Oct 16:05 libsqlite3.dylib -> 
libsqlite3.0.dylib
4252739 -rw-r--r--1 501  80  9061472 17 Oct 16:05 libsqlite3.a
4252735 -rwxr-xr-x1 501  80  1845464 17 Oct 16:05 libsqlite3.0.dylib
 565934 drwxrwxr-x  307 501  8010438 17 Oct 16:05 ./

Gandalf:bin pteeson$ sqlite3 
SQLite version 3.39.4 2022-09-29 15:55:41

 Latest issue

Gandalf:~ pteeson$ cd /Volumes/Data/GNUAPL-on-Mac-WS/GNUapl/trunk 
Gandalf:trunk pteeson$ ./configure
checking for gcc... gcc
….
   *** checks for optional libraries ... ***

checking for SQLite3 library >= 3.0.0... ./configure: line 19029: 
-L/usr/local/lib: No such file or directory
yes
checking for pg_config... no

> On Oct 19, 2022, at 1:27 PM, Dr. Jürgen Sauermann 
>  wrote:
> 
> Hi Peter,
> 
> I see. Next try then: SVN 1607.
> 
> I hope macOS has dirname, has it?
> 
> Best Regards,
> Jürgen
> 
> 
> On 10/19/22 6:19 PM, Peter Teeson wrote:
>> Hi Jürgen:
>> 
>> So sorry but we’re not done yet…… respect Peter
>> 
>> Gandalf:~ pteeson$ cd /Volumes/Data/GNUAPL-on-Mac-WS/GNUapl 
>> Gandalf:GNUapl pteeson$ svn co http://svn.savannah.gnu.org/svn/apl/trunk 
>> <http://svn.savannah.gnu.org/svn/apl/trunk> > svn-log 2>&1
>> Atrunk/doc
>> ...
>> Atrunk/tools/sockconst.c
>> Checked out revision 1605.
>> 
>> 
>> Gandalf:~ pteeson$ which realpath
>> Gandalf:~ pteeson$ 
>> Gandalf:~ pteeson$ which readlink
>> /usr/bin/readlink
>> 
>> 
>> configure: creating buildtag.hh...
>> ./configure: line 23140: realpath: command not found
>> configure: top-level apl directory is: 
>> configure: removing old ./makefile.h
>>  
>> Gandalf:trunk pteeson$ make
>> creating a fresh makefile.h...
>> /Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
>> Making all in workspaces
>> …..
>> Making all in DALY
>> make[3]: Nothing to be done for `all'.
>> /bin/sh /Volumes/Data/GNUAPL-on-Mac-WS/GNUapl/trunk/missing makeinfo 
>> libapl.texi -o libapl.info <http://libapl.info/> --no-split || touch 
>> libapl.info <http://libapl.info/>
>> /bin/sh /Volumes/Data/GNUAPL-on-Mac-WS/GNUapl/trunk/missing makeinfo --html 
>> libapl.texi -o libapl.html --no-split || touch libapl.html
>> Making all in erlang
>> …..
>> Making all in server
>> make[3]: Nothing to be done for `all'.
>> make[3]: Nothing to be done for `all-am'.
>> make[2]: Nothing to be done for `all-am'.
>> Gandalf:trunk pteeson$ 
>> 
>>> On Oct 19, 2022, at 7:42 AM, Dr. Jürgen Sauermann 
>>> mailto:m...@xn--jrgen-sauermann-zvb.de>> 
>>> wrote:
>>> 
>>> Hi Peter,
>>> 
>>> thanks for reporting this.
>>> 
>>> Line 304 should be fixed now by replacing readlink -f with realpath.
>>> Line 336 ff. seems to be an issue with your makeinfo version (mine is 6.5
>>> and I am not getting these warnings),
>>> Line 649 ff. and 741 ff. should be fixed (in m4/ax_lib_sqlite3.m4).
>>> 
>>> SVN 1604.
>>> 
>>> Best Regards,
>>> Jürgen
>>> 
>>> 
>>> On 10/18/22 8:03 PM, Peter Teeson wrote:
>>>> Hi Jürgen:
>>>> 
>>>> Thanks for the latest svn 1603. We still have issues. Log file attached.
>>>> E.G.  Note lines 307, 336 et seq, 649 et seq, 741 et seq,  ….
>>>> 
>>>> 
>>>> 
>>>> respect
>>>> 
>>>> Peter
>>>> 
>>>> P.S. In the past I was able to use Firefox to examine the Doxygen 
>>>> generated html files….
>>>> When we have dealt with the present issues I will run Doxygen and check 
>>>> what happens.
>>>> 
>>> 
>> 
> 

Re: DALY SUBDIRS in makefile

[Peter Teeson]

What is your operating system?


> On Oct 30, 2022, at 11:22 PM, Peri Didaskalou  wrote:
> 
> Hello, 
> 
> Today I tried configuring and making GNU APL both via github and subversion.
> 
> Either way configure kept getting stuck on not finding the DALY subdirs under 
> /doc /wslib3 and /wslib5, at least.
> I managed to get configured after editing the paths in configure, but then 
> make obviously ran into the same issue.
> 
> I'm sorry I didn't try editing the makefiles of those sans-DALY-subdirs DIRs, 
> mostly out of ignorance and inexperience with creating these.
> I also didn't feel like like joining the debug mailing list just yet, just 
> for this.  I did search for DALY and SUBDIRS in the bug-apl archives.
> I didn't find a discussion about this.
> 
> Anyhow, hances are by the time someone reads this, the issue will be fixed.
> 
> Regards,
> Peri Didaskalou
> 
> 

Re: Compilation problem

[Peter Teeson]

FWIW I also get the same error on macOS - been trying for days to hunt down 
problem but so far no answer. 

Looking at the ./configure code but am boggled by it and struggling to zone in 
on the correct area,
I work in Xcode so no idea what to use to dynamically debug/trace in Terminal

Gandalf:trunk pteeson$ ./configure --with-python
…..

configure: SUMMARY OF TESTS (please include in error reports) 

DEVELOP_WANTED:  no
ASSERT_LEVEL_WANTED: 1
DYNAMIC_LOG_WANTED:  no
PERFORMANCE_COUNTERS_WANTED: no
VALUE_CHECK_WANTED:  no
VALUE_HISTORY_WANTED:no

apl_MAINTAINER_MODE: no
apl_missing_headers: 3
apl_missing_functions:   0
apl_FFT: no (affects: ⎕FFT)
apl_PCRE:   (affects: ⎕RE)
apl_PNG: yes(affects: ⎕PNG)
apl_POSTGRES:no (may affect: ⎕SQL)
apl_SQLITE3: yes(may affect: ⎕SQL)
apl_SQL  yes(affects:⎕SQL)
apl_X11 (libxcb):no (fallback for   ⎕PLOT)
apl_GTK3:no (affects: ⎕PNG, ⎕GTK, maybe ⎕PLOT)
apl_GUI: no (affects: ⎕PNG, ⎕GTK,   ⎕PLOT)

=From the Make log===
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -Wall -I sql -I 
/Volumes/Data/GNUAPL-on-Mac-WS/GNUapl/trunk -I/usr/include -DNDEBUG 
-D_FORTIFY_SOURCE=2 -fwrapv -fPIC -fstack-protector --param=ssp-buffer-size=4 
-I/usr/include/python3.6m -I/usr/include/python3.8 -g -O2 -I 
/Volumes/Data/GNUAPL-on-Mac-WS/GNUapl/trunk -MT lib_gnu_apl_la-python_apl.lo 
-MD -MP -MF .deps/lib_gnu_apl_la-python_apl.Tpo -c python_apl.cc  -fno-common 
-DPIC -o .libs/lib_gnu_apl_la-python_apl.o
python_apl.cc:3:10: fatal error: 'Python.h' file not found
#include 
 ^~
1 error generated.
make[1]: *** [lib_gnu_apl_la-python_apl.lo] Error 1
make: *** [all-recursive] Error 1

 tracking down python3.8 -
../../Library/Frameworks/Python.framework/Versions/3.8/include/python3.8
../../Library/Frameworks/Python.framework/Headers 

> On May 24, 2023, at 4:45 PM, Emmanuel Charpentier  
> wrote:
> 
> Dear Jürgen,
> 
> TL,DR : I tried to recompile gnu-apl with the Python library, but got a 
> compilation error :
> 
> ../../src/python_apl.cc:3:10: fatal error: Python.h: Aucun fichier ou dossier 
> de ce type
> 3 | #include 
>   |  ^~
> compilation terminated.
> Some details :
> 
> In a fresh VPATH directory I did :
> 
> ../configure --with-sqlite3 --with-gtk3 --with-python
> which ended with :
> 
> configure: SUMMARY OF TESTS (please include in error reports) 
> 
> DEVELOP_WANTED:  no
> ASSERT_LEVEL_WANTED: 1
> DYNAMIC_LOG_WANTED:  no
> PERFORMANCE_COUNTERS_WANTED: no
> VALUE_CHECK_WANTED:  no
> VALUE_HISTORY_WANTED:no
> 
> apl_MAINTAINER_MODE: no
> apl_missing_headers: 0
> apl_missing_functions:   0
> apl_FFT: yes  (affects: ⎕FFT)
> apl_PCRE:yes  (affects: ⎕RE)
> apl_PNG: yes  (affects: ⎕PNG)
> apl_POSTGRES:yes  (may affect: ⎕SQL)
> apl_SQLITE3: yes  (may affect: ⎕SQL)
> apl_SQL  yes  (affects:⎕SQL)
> apl_X11 (libxcb):yes  (fallback for   ⎕PLOT)
> apl_GTK3:yes  (affects: ⎕PNG, ⎕GTK, maybe ⎕PLOT)
> apl_GUI: yes  (affects: ⎕PNG, ⎕GTK,   ⎕PLOT)
> but a compilation, launched by
> 
> time make -j8 2>&1 | tee compilation.log
> failed. The error seems to be :
> 
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../src -I.. -Wall 
> -Wno-parentheses -I sql -I /home/charpent/Dev/apl/trunk/obj/.. 
> -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz 
> -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount 
> -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo 
> -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 
> -I/usr/include/x86_64-linux-gnu -I/usr/include/gio-unix-2.0 
> -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 
> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 
> -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -pthread -I/usr/include 
> -I/usr/include/postgresql -DNDEBUG -D_FORTIFY_SOURCE=2 -fwrapv -fPIC 
> -fstack-protector --param=ssp-buffer-size=4 -I/usr/include/python3.6m 
> -I/usr/include/python3.8 -g -O2 -I /home/charpent/Dev/apl/trunk/obj -MT 
> lib_gnu_apl_la-python_apl.lo -MD -MP -MF .deps/lib_gnu_apl_la-python_apl.Tpo 
> -c ../../src/python_apl.cc  -fPIC -DPIC -o .libs/lib_gnu_apl_la-python_apl.o
> ../../src/python_apl.cc:3:10: fatal error: Python.h: Aucun fichier ou dossier 
> de ce type
> 

Re: Compilation problem

[Peter Teeson]

P.S to my previous post….

>
Apple has officially deprecated Python 2.7 in macOS Monterey 12.3. 
 The company is advising its developers to use an alternative programming 
language 
instead, such as Python 3, which, however, does not come preinstalled on 
macOS.Jan 28, 2022

>

Re: Compilation problem

[Peter Teeson]

Why not make a note in the python README for users to  make a symbolic link 
from their actual python location to a standard place such as 
/usr/include/python?
Then configure need only refer to that.


> On May 25, 2023, at 5:34 AM, Dr. Jürgen Sauermann 
>  wrote:
> 
> actually:
> 
> CXXFLAGS="-I /usr/include/python3.10" ./configure --with-python
> 
> 
> On 5/25/23 11:31, Dr. Jürgen Sauermann wrote:
>> Hi Emmanuel,
>> 
>> could you please translate the french error message to English?
>> 
>> No idea yet what this is about.
>> 
>> In the meantime it may help to copy Python.h from:
>> /usr/include/python3.11/Python.h
>> to:
>> /usr/include/Python.h
>> 
>> Or configure GNU APL like this:
>> 
>> CXXFLAGS="-I /usr/include/python3.10" ./configure
>> 
>> Best Regards,
>> Jürgen
>> 
>> 
>> On 5/24/23 22:45, Emmanuel Charpentier wrote:
>>> Dear Jürgen,
>>> 
>>> TL,DR : I tried to recompile gnu-apl with the Python library, but got a 
>>> compilation error :
>>> 
>>> ../../src/python_apl.cc:3:10: fatal error: Python.h: Aucun fichier ou 
>>> dossier de ce type
>>> 3 | #include 
>>>   |  ^~
>>> compilation terminated.
>>> Some details :
>>> 
>>> In a fresh VPATH directory I did :
>>> 
>>> ../configure --with-sqlite3 --with-gtk3 --with-python
>>> which ended with :
>>> 
>>> configure: SUMMARY OF TESTS (please include in error reports) 
>>> 
>>> DEVELOP_WANTED:  no
>>> ASSERT_LEVEL_WANTED: 1
>>> DYNAMIC_LOG_WANTED:  no
>>> PERFORMANCE_COUNTERS_WANTED: no
>>> VALUE_CHECK_WANTED:  no
>>> VALUE_HISTORY_WANTED:no
>>> 
>>> apl_MAINTAINER_MODE: no
>>> apl_missing_headers: 0
>>> apl_missing_functions:   0
>>> apl_FFT: yes(affects: ⎕FFT)
>>> apl_PCRE:yes(affects: ⎕RE)
>>> apl_PNG: yes(affects: ⎕PNG)
>>> apl_POSTGRES:yes(may affect: ⎕SQL)
>>> apl_SQLITE3: yes(may affect: ⎕SQL)
>>> apl_SQL  yes(affects:⎕SQL)
>>> apl_X11 (libxcb):yes(fallback for   
>>> ⎕PLOT)
>>> apl_GTK3:yes(affects: ⎕PNG, ⎕GTK, maybe 
>>> ⎕PLOT)
>>> apl_GUI: yes(affects: ⎕PNG, ⎕GTK,   
>>> ⎕PLOT)
>>> but a compilation, launched by
>>> 
>>> time make -j8 2>&1 | tee compilation.log
>>> failed. The error seems to be :
>>> 
>>> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../src -I.. -Wall 
>>> -Wno-parentheses -I sql -I /home/charpent/Dev/apl/trunk/obj/.. 
>>> -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
>>> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz 
>>> -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount 
>>> -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo 
>>> -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 
>>> -I/usr/include/x86_64-linux-gnu -I/usr/include/gio-unix-2.0 
>>> -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 
>>> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 
>>> -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -pthread -I/usr/include 
>>> -I/usr/include/postgresql -DNDEBUG -D_FORTIFY_SOURCE=2 -fwrapv -fPIC 
>>> -fstack-protector --param=ssp-buffer-size=4 -I/usr/include/python3.6m 
>>> -I/usr/include/python3.8 -g -O2 -I /home/charpent/Dev/apl/trunk/obj -MT 
>>> lib_gnu_apl_la-python_apl.lo -MD -MP -MF 
>>> .deps/lib_gnu_apl_la-python_apl.Tpo -c ../../src/python_apl.cc  -fPIC -DPIC 
>>> -o .libs/lib_gnu_apl_la-python_apl.o
>>> ../../src/python_apl.cc:3:10: fatal error: Python.h: Aucun fichier ou 
>>> dossier de ce type
>>> 3 | #include 
>>>   |  ^~
>>> compilation terminated.
>>> make[3]: *** [Makefile:2779 : lib_gnu_apl_la-python_apl.lo] Erreur 1
>>> make[3]: *** Attente des tâches non terminées
>>> The curious thing is that Python.h is present on my system :
>>> 
>>> charpent@zen-book-flip:~/Dev/apl/trunk/obj$ locate Python.h
>>> locate: warning: database ‘/var/cache/locate/locatedb’ is more than 8 jours 
>>> old (actual age is 30,1 jours)
>>> /usr/include/python3.11/Python.h
>>> /usr/share/doc/Macaulay2/Python/html/_to__Python.html
>>> charpent@zen-book-flip:~/Dev/apl/trunk/obj$ ls -l 
>>> /usr/include/python3.11/Python.h
>>> -rw-r--r-- 1 root root 2854 13 mars  13:18 /usr/include/python3.11/Python.h
>>> I might have to specify some library in an option to ../configure, but 
>>> can't figure out which.
>>> 
>>> My setup is Debian testing, used fairly often for development (I'm more or 
>>> less in the Sagemath development group), with as little non-Debian software 
>>> I can manage (two notorious exceptions : Zotero, which is a sine qua non of 
>>> my work) and, of course, Sagemath (built from my local git clone). And an 
>>> armfull of R packages, which are probably quite irrelevant.
>>> 
>>

2 warnings and an error

[Peter Teeson]

Hi Jürgen:Full logs attached at bottom. kind regards PeterGandalf:~ pteeson$ cd /Volumes/Data/GNUAPL-on-Mac-WS/GNUapl Gandalf:GNUapl pteeson$  svn co http://svn.savannah.gnu.org/svn/apl/trunk > svn-log 2>&1A    trunk/m4…..A    trunk/aclocal.m4Checked out revision 1699.Gandalf:GNUapl pteeson$ cd trunkGandalf:trunk pteeson$ ./configure DYNAMIC_LOG_WANTED=yes  <<<===……configure:     SUMMARY OF TESTS (please include in error reports)     DEVELOP_WANTED:              no    ASSERT_LEVEL_WANTED:         1    DYNAMIC_LOG_WANTED:          yes    PERFORMANCE_COUNTERS_WANTED: no    VALUE_CHECK_WANTED:          no    VALUE_HISTORY_WANTED:        no    apl_MAINTAINER_MODE:         no    apl_missing_headers:         3    apl_missing_functions:       0    apl_FFT:                     no	(affects: ⎕FFT)    apl_PCRE:                    	(affects: ⎕RE)    apl_PNG:                     yes	(affects: ⎕PNG)    apl_POSTGRES:                no	(may affect: ⎕SQL)    apl_SQLITE3:                 yes	(may affect: ⎕SQL)    apl_SQL                      yes	(affects:    ⎕SQL)    apl_X11 (libxcb):            no	(fallback for               ⎕PLOT)    apl_GTK3:                    no	(affects: ⎕PNG, ⎕GTK, maybe ⎕PLOT)    apl_GUI:                     no	(affects: ⎕PNG, ⎕GTK,       ⎕PLOT)…….Gandalf:trunk pteeson$ make/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive…..Command.cc:2477:8: warning: template argument uses local type 'lid_OOT' [-Wlocal-type-template-args]vector lid_OOTs;       ^~Executable.cc:338:8: warning: template argument uses local type 'conditional' [-Wlocal-type-template-args]vector conditionals;       ^~~Executable.cc:595:20: error: non-aggregate type 'const Function_PC2' cannot be initialized with an initializer      listconst Function_PC2 after_from_to = { body_from_to.low  - start,                   ^               Executable.cc:815:11: warning: result of comparison of constant 2 with _expression_ of type 'Function_PC' is always      true [-Wtautological-constant-out-of-range-compare]   if (pc < 2)   return Function_PC_0;       ~~ ^ ~

svn-log
Description: Binary data
Last login: Wed May 31 14:46:28 on ttys001
Gandalf:~ pteeson$ cd /Volumes/Data/GNUAPL-on-Mac-WS/GNUapl 
Gandalf:GNUapl pteeson$  svn co http://svn.savannah.gnu.org/svn/apl/trunk > 
svn-log 2>&1
Gandalf:GNUapl pteeson$ cd trunk
Gandalf:trunk pteeson$ ./configure DYNAMIC_LOG_WANTED=yes

*** core tests... ***

checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for wchar.h... yes
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... ././install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports the include directive... yes (GNU style)
checking whether make supports nested variables... yes
checking dependency style of gcc... gcc3
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-apple-darwin17.7.0
checking host system type... x86_64-apple-darwin17.7.0
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker 
(/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld)
 is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-apple-darwin17.7.0 file names to 
x86_64-apple-darwin17.7.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin17.7.0 file names to toolcha

Startup with command line parameters....

[Peter Teeson]

Hi Jürgenl:I was trying out how to startup APL using command line parameters. My first attempt worked:Last login: Sun Jun  4 13:43:24 on ttys000Gandalf:~ pteeson$ apl -l 37…..

Command Line Parms test 1.txt.pdf
Description: Adobe PDF document
But I had to know that LID_startup was  enum 37. (UserPreferences::parse_argv_0(..) {.. if (!strcmp(argv[a], "-l") && atoi(argv[a+1]) == LID_startup)           That seems to imply I had already built apl, launched it, and typed ]LOG to find the LID_startup enum.So I’m wondering if we could maybe add something to the READMEs? Perhaps similar to the README-7? Listing the LOG table?Maybe indicating which can be used on the command line? Just a thought…respect…Peter

Re: Startup with command line parameters....

[Peter Teeson]

Hi Jürgen:

Thanks for your reply. I feel somewhat stupid because never thought to look in 
HOWTOs.
Too brainwashed by macOS world view vs Linux world view.

respect…

Peter

> On Jun 5, 2023, at 6:51 AM, Dr. Jürgen Sauermann 
>  wrote:
> 
> Hi Peter,
> 
> thanks for the proposal. The logging facilities are already
> described in the GNU-APL-Designers-Guide.html and
> I have added a note concerning -l 37. Also:
> 
> apl --help
> 
> mentions it, although it could be missed there due to the many
> command line options.
> 
> SVN 1705.
> 
> Best Regards,
> Jürgen
> 
> 
> On 6/4/23 20:44, Peter Teeson wrote:
>> Hi Jürgenl:
>> 
>> I was trying out how to startup APL using command line parameters. My first 
>> attempt worked:
>> 
>> Last login: Sun Jun  4 13:43:24 on ttys000
>> Gandalf:~ pteeson$ apl -l 37
>> …..
>> 
>> 
>> 
>> But I had to know that LID_startup was  enum 37. 
>> (UserPreferences::parse_argv_0(..) {.. if (!strcmp(argv[a], "-l") && 
>> atoi(argv[a+1]) == LID_startup)
>>
>> That seems to imply I had already built apl, launched it, and typed ]LOG to 
>> find the LID_startup enum.
>> 
>> So I’m wondering if we could maybe add something to the READMEs? 
>> Perhaps similar to the README-7? Listing the LOG table?
>> Maybe indicating which can be used on the command line? 
>> 
>> Just a thought…
>> 
>> respect…
>> 
>> Peter
> 

Re: Building GNU APL with clang

[Peter Teeson]

Yes many times on my Apple Mac which runs macOS.

> On Oct 2, 2023, at 8:07 PM, Russtopia  wrote:
> 
> Hello, See topic.
> 
> I would rather not, but in this case I am trying to re-build GNU APL in 
> Termux on my newer Android phone, and Termux decided some time ago to remove 
> gcc entirely from its packages, in preference to clang. :(
> 
> I am not up to date at all on modern C++, but this conversation on 
> Stackoverflow suggests that auto_ptr is considered deprecated in newer C++ 
> standards: 
> https://stackoverflow.com/questions/69116001/how-do-i-re-enable-c17-removed-features-in-clang
>  
> 
> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. 
> -Wno-deprecated-declarations -g -O2 -I 
> /data/data/com.termux/files/home/gnuapl/trunk -c Listener.cc -o Listener.o 
> >/dev/null 2>&1
> network.cc:37:10: error: no member named 'auto_ptr' in namespace 'std'
> std::auto_ptr connection( (NetworkConnection *)arg );
> ~^
> network.cc:37:19: error: 'NetworkConnection' does not refer to a value
> std::auto_ptr connection( (NetworkConnection *)arg );
> ^
> 
> Adding -std=c++11 to src/emacs-mode/Makefile CXXFLAGS got me past the 
> auto_ptr issues, but then I hit issues with 'typeof()' in LineInput.cc:
> 
> g++ -DHAVE_CONFIG_H -I. -I.. -Wall -I sql -I 
> /data/data/com.termux/files/home/gnuapl/trunk -std=c++11 -g -O2 -I 
> /data/data/com.termux/files/home/gnuapl/trunk -MT apl-Missing_Libraries.o -MD 
> -MP -MF .deps/apl-Missing_Libraries.Tpo -c -o apl-Missing_Libraries.o `test 
> -f 'Missing_Libraries.cc' || echo './'`Missing_Libraries.cc
> LApack.cc:1784:37: error: unknown type name 'typeof'; did you mean 'typedef'? 
> tau = reinterpret_cast (work);
> ^~
> typedef
> LApack.cc:1784:43: error: expected a type tau = reinterpret_cast 
> (work);
> ^
> LApack.cc:1784:37: error: type name does not allow storage class to be 
> specified
> tau = reinterpret_cast (work);
> ^
> 
> Has anyone managed to build and successfully run GNU APL with clang?
> 
> -Russ
> 

Re: Hot Footer

[Peter Teeson]

Oh my!FWIW in 1955 I emigrated from the UK to Canada. 
My first job was as a clerk with Underwood Typewriter.
But during my lunch 1/2 hour I had to learn how to use an Olivetti Underwood 
Sundstrand adding machine.
In order to add up a pile of invoices….. look at the invoice for the amount 
which I would “blindly” punch into the adding machine.

See the pictures here:
>

respect

PHT

> On Oct 12, 2023, at 10:51 AM, Bill Daly  wrote:
> 
> This announcement is for all of us who crunch numbers for a living, in
> apl or out of it.
> 
> I wrote Hot Footer in 2004 and have been using almost daily since
> then. I was sick and tired of playing with the paper tapes generated
> by tape calculators and decided a virtual tape (from which I could
> copy and paste) was needed.
> 
> Now after almost twenty years, I've released it under the GNU Public
> License.
> 
> https://sourceforge.net/projects/hot-footer/
> 
> For those born after the computer revolution, a tape calculator is a
> desktop mechanical appliance that printed a log of your calculations to
> a roll of paper tape. Mine had an electric motor so that having
> entered a number all I did was hit (tapping didn't show enough
> strength) the plus key.  My Grandfather's had a twelve inch long lever
> that one pulled for each entry.
> 
> w
> 
> 

[Bug-apl] Building on OS X 10.8.5 Mountain Lion

[Peter Teeson]

Mac Pro Desktop dual quad core CPU's, Mountain Lion OS X 10.8.5

I DL'd the 2014-01-13 APL 1.2 tar.gz and did ./configure.
Blew up because of
configure:2767: checking for gcc
configure:2797: result: no
configure:2860: checking for cc
configure:2907: result: no
configure:2963: checking for cl.exe
configure:2993: result: no
configure:3017: error: in `/Users/pteeson/Desktop/APL/apl-1.2':
configure:3020: error: no acceptable C compiler found in $PATH
See `config.log' for more details.

Apple's Xcode uses llvm-gcc4. I'm not deeply familiar with the whole GNU make 
system.

Do I need to set an environment var for gcc and cc?
Where is the proper place to do this? In configure.ac? AC_PROG_CXX AC_PROG_CC
Or some other way?

Sorry to be so ignorant of naked unix but it's never been necessary for me to 
dig that deep.

Thanks and respect….

Peter Teeson (formerly a 14 year member of the IPSA zoo a.k.a. dev group)

Re: [Bug-apl] Building on OS X 10.8.5 Mountain Lion - partly resolved….

[Peter Teeson]

On 2014-03-11, at 4:30 PM, Peter Teeson  wrote:
> Mac Pro Desktop dual quad core CPU's, Mountain Lion OS X 10.8.5
> 
> I DL'd the 2014-01-13 APL 1.2 tar.gz and did ./configure.
> Blew up because of
> configure:2767: checking for gcc
> configure:2797: result: no
> configure:2860: checking for cc
> configure:2907: result: no
> configure:2963: checking for cl.exe
> configure:2993: result: no
> configure:3017: error: in `/Users/pteeson/Desktop/APL/apl-1.2':
> configure:3020: error: no acceptable C compiler found in $PATH
> See `config.log' for more details.
> 
> Apple's Xcode uses llvm-gcc4. I'm not deeply familiar with the whole GNU make 
> system.
> Do I need to set an environment var for gcc and cc?
> Where is the proper place to do this? In configure.ac? AC_PROG_CXX AC_PROG_CC
> Or some other way?
> 
> Sorry to be so ignorant of naked unix but it's never been necessary for me to 
> dig that deep.
> 
> Thanks and respect….
> 
> Peter Teeson (formerly a 14 year member of the IPSA zoo a.k.a. dev group)

I booted into Lion OS X 10.7.6 and everything built and installed without a 
hitch.
Back in Mountain Lion I searched for llvm-gcc4 and it looks like it was not 
installed by default from the Xcode package.
Further digging uncovered this note in the "What's New in Xcode" document.
"NOTE: LLVM_GCC is not included in Xcode 5"

So that's where things stand right now. It seems to me there are a number of 
options for 10.8 Mountain Lion and forward:
(0) Install GCC4 
(1) Try to build using llvm-clang
(2) Boot into 10.7 Lion to use APL

Personally I don't mind trying to do what it takes to try (1). I have the time 
( I'm in my mid 70s) and some experience.
But I'd need some guidance and help with the whole automake and friends to be 
of any use.

Seeking your advice ….

respect….

Peter

Re: [Bug-apl] Building on OS X 10.8.5 Mountain Lion - SOLVED and How to setup your keyboard.

[Peter Teeson]

Sorry to intrude but…..
Is there a better list to share these steps about using your lovely 
implementation on Mac?
I can make a better formatted form (via TeX if desired).

> The solution is much simpler. For Xcode 5:
> Launch Xcode
> Go to Xcode menu and select Preferences and Downloads
> Choose Install Command Line Tools and click on Install.
> 
> Open Terminal and follow usual steps of ./configure, make, sudo make install.
> It all works flawlessly (except for a whole bunch of warnings).
> Attached is the log FWIW
> 
> The compiler used is llvm clang.

I'm also able to use the Mac keyboard with the APL font. Here is how.

Go to 
Download the APL385 font (also the APL333 one if desired).
for OS X: Copy the font to /Library/Fonts/ (for all users) or ~/Library/Fonts 
for just yourself (which is what I did)
In the OS X Font & Keyboard section download the Dyalog APL for Unix Apple 
Macintosh Supplement (which is a pdf)
Try to download Dyalog Keyboard Layout for OS X. Your browser will not be able 
to do this. If you try you will likely see this
XML Parsing Error: reference to invalid character number
Location: http://www.dyalog.com/resources/downloads/DyalogAlt.keylayout
Line Number 96, Column 36:
---^
I contacted Dyalog and they sent me an email with it attached. Support said 

The XML error occurs as the keylayout file is an XML file, and Firefox is
trying to read it.
I've let my colleagues know of this and we'll try to improve that link.

Follow the instructions in the Dyalog APL for Unix Apple Macintosh Supplement.

In my case I setup a Terminal settings.terminal file with the APL385 as the 
font.
The keyboard layout should be placed in Library/Keyboards Layouts folder (or 
~/Keyboard Layouts) which is what I did
You need to re-boot after that step. Now you're good to go.
Open a terminal window with the right settings.
From the menu bar Language menu (in my Case Canadian English) select the Dyalog 
Alt keyboard.
One other very nice feature that comes standard with OS X is the Keyboard 
Viewer.
From the Language menu select it, place it where you wish, launch APL in the 
Terminal window and have fun.

respect…

Peter

Re: [Bug-apl] Building on OS X 10.8.5 Mountain Lion - SOLVED and How to setup your keyboard.

[Peter Teeson]

OK. I am in the process of making a LATeX doc and will also update 
README-6-porting and send it to you when done.


respect….

Peter
On 2014-03-14, at 9:52 AM, Juergen Sauermann  
wrote:

> Hi Peter,
> 
> my plan was to include your information in our README-6-porting in the next 
> release.
> 
> I am currently preparing that release, but have not reached that point yet 
> because
> I am working on keyboard input related proposals and methods.
> 
> Please feel invited to send an updated README-6-porting; I would be happy
> to include that.
> 
> /// Jürgen
> 
> 
> On 03/13/2014 10:12 PM, Peter Teeson wrote:
>> Sorry to intrude but…..
>> Is there a better list to share these steps about using your lovely 
>> implementation on Mac?
>> I can make a better formatted form (via TeX if desired).
>> 
>>> The solution is much simpler. For Xcode 5:
>>> Launch Xcode
>>> Go to Xcode menu and select Preferences and Downloads
>>> Choose Install Command Line Tools and click on Install.
>>> 
>>> Open Terminal and follow usual steps of ./configure, make, sudo make 
>>> install.
>>> It all works flawlessly (except for a whole bunch of warnings).
>>> Attached is the log FWIW
>>> 
>>> The compiler used is llvm clang.
>> 
>> I'm also able to use the Mac keyboard with the APL font. Here is how.
>> 
>> Go to <http://www.dyalog.com/resources/>
>> Download the APL385 font (also the APL333 one if desired).
>> for OS X: Copy the font to /Library/Fonts/ (for all users) or 
>> ~/Library/Fonts for just yourself (which is what I did)
>> In the OS X Font & Keyboard section download the Dyalog APL for Unix Apple 
>> Macintosh Supplement (which is a pdf)
>> Try to download Dyalog Keyboard Layout for OS X. Your browser will not be 
>> able to do this. If you try you will likely see this
>> XML Parsing Error: reference to invalid character number
>> Location: http://www.dyalog.com/resources/downloads/DyalogAlt.keylayout
>> Line Number 96, Column 36:
>> ---^
>> I contacted Dyalog and they sent me an email with it attached. Support said 
>> 
>> The XML error occurs as the keylayout file is an XML file, and Firefox is
>> trying to read it.
>> I've let my colleagues know of this and we'll try to improve that link.
>> 
>> Follow the instructions in the Dyalog APL for Unix Apple Macintosh 
>> Supplement.
>> 
>> In my case I setup a Terminal settings.terminal file with the APL385 as the 
>> font.
>> The keyboard layout should be placed in Library/Keyboards Layouts folder (or 
>> ~/Keyboard Layouts) which is what I did
>> You need to re-boot after that step. Now you're good to go.
>> Open a terminal window with the right settings.
>> From the menu bar Language menu (in my Case Canadian English) select the 
>> Dyalog Alt keyboard.
>> One other very nice feature that comes standard with OS X is the Keyboard 
>> Viewer.
>> From the Language menu select it, place it where you wish, launch APL in the 
>> Terminal window and have fun.
>> 
>> respect…
>> 
>> Peter
>> 
> 

[Bug-apl] GNU APL on Mac

[Peter Teeson]

Hi folks:

Attached is a small 12 page guide to help installing GNU APL on a Macintosh.
Please review it and help to make it better by letting me know how.

Thanks and respect….

Peter

Re: [Bug-apl] clang warning

[Peter Teeson]

Updated to revision 211.
../GNUAPL/apl-svn/src/UserPreferences.cc:378:1: Control may reach end of 
non-void function

Peter

[Bug-apl] Bug in my knowledge..

[Peter Teeson]

This is a bug in my brain but related to GNU APL.
Last time I used APL was when I worked at IPSA.
The language has been extended since then.

I have the ISO Standard and even the IBM APL2 Language Summary & Programming 
Guide.
What can I read for a summary of the differences between the APL I know/knew 
and GNU APL - ISO 13751?
(In my days at IPSA I shared an office with one of the authors of the ISO std)

TIA & respect

Peter

[Bug-apl] clang Warning - revisited

[Peter Teeson]

Hi Jürgen:

I've been thinking again about this warning and I'm inclined to agree with it.

..MyProjects/GNUAPL/apl-svn/src/UserFunction.cc:1191:10: Comparison of constant 
10 with expression of type 'Function_Line' is always true

   if (l < 10)   ucs.append(UNI_ASCII_SPACE);


These suggestions eliminate the Warning.

In File APL_Types.hh

enum Function_Line
{
   Function_Retry  = -2,   // →'' in immediate execution
   Function_Line_0 = 0,
   Function_Line_1 = 1,
   Function_Line_MAX = 10  // << === My suggestion
};

In UserFunction.cc:1191:10:
   if (l < Function_Line_MAX)   ucs.append(UNI_ASCII_SPACE); // << === My 
suggestion

[Bug-apl] 2 more clang Warnings + 3 similar ones

[Peter Teeson]

../apl-svn/src/Token.cc:545:11: 5 enumeration values not handled in switch: 
'TC_L_CURLY', 'TC_R_CURLY', 'TC_MAX_PHRASE_2'…
../apl-svn/src/Token.cc:601:11: 5 enumeration values not handled in switch: 
'TC_L_CURLY', 'TC_R_CURLY', 'TC_MAX_PHRASE_2'…

Should there be a default label in the switch?
You return a char string in both of these cases when falling through.

respect….

Peter
P.S. In fact there are 3 more Warnings of the same type.

../apl-svn/src/Avec.cc:281:11: 18 enumeration values not handled in switch: 
'UNI_iPAD_U2', 'UNI_iPAD_U3', 'UNI_iPAD_U1'...
..L/apl-svn/src/Executable.cc:455:23: 156 enumeration values not handled in 
switch: 'TOK_NEWLINE', 'TOK_NUMERIC', 'TOK_SYMBOL'…
../apl-svn/src/PrimitiveFunction.cc:2887:16: 310 enumeration values not handled 
in switch: 'UNI_ASCII_NUL', 'UNI_ASCII_SOH', 'UNI_ASCII_STX'...


respect…

Peter

[Bug-apl] clang Warning

[Peter Teeson]

/bin/sh ../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..   -I/usr/local/include -rdynamic -g -O2 -MT file_io.lo -MD -MP -MF 
.deps/file_io.Tpo -c -o file_io.lo file_io.cc

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include 
-rdynamic -g -O2 -MT file_io.lo -MD -MP -MF .deps/file_io.Tpo -c file_io.cc  
-fno-common -DPIC -o .libs/file_io.

clang: warning: argument unused during compilation: '-rdynamic'

../apl-svn/src/file_io.cc:113:41: Expression result unused

for (; fm < (sizeof(fmt) - 1); fm)
 ^~

Congratulations! 
Expression result unused
This is the only warning that shows up now in the Notifications using Xcode for 
building .

The Warning about -rdynamic occurs for every compilation but we can ignore it 
can't we?
When I do man libtool in Terminal it only shows -dynamic. Couldn't see an 
-rdynamic.

respect…

Peter

[Bug-apl] Good news..

[Peter Teeson]

As of APL 1.3 6401 --  For OS X both Mountain Lion 10.8.5 & Mavericks 10.9.2

./configure --disable-nls ; make clean ; make 
/apl-svn/src/file_io.cc:113:41: Expression result unused
Input.cc:106:42: warning: conversion from string literal to 'char *' is 
deprecated [-Wdeprecated-writable-strings]

./configure ; make clean ; make 
/apl-svn/src/file_io.cc:113:41: Expression result unused

respect….

Peter

[Bug-apl] 2 questions wrt editing my programs

[Peter Teeson]

(1) Where is docn for the built in function editor when running in terminal 
mode?
(I have the IBM manuals - should I be looking there? Also I am not familiar 
with emacs or vi)
(I'm only familiar with the IPSA one)

(2) Can I use an external text editor and interface with quad FX?

Because I now want to get on with my original intent which is to solve a 
problem using APL
rather than C/C++ since APL is much better suited for that purpose - lots of 
arrays involved.

TIA

respect….

Peter

Re: [Bug-apl] 2 questions wrt editing my programs

[Peter Teeson]

Heh Heh…. Yes I do know about emacs mode and your contribution…..

respect….

Peter
On 2014-04-21, at 6:33 PM, Peter Teeson  wrote:

> (1) Where is docn for the built in function editor when running in terminal 
> mode?
> (I have the IBM manuals - should I be looking there? Also I am not familiar 
> with emacs or vi)
> (I'm only familiar with the IPSA one)
> 
> (2) Can I use an external text editor and interface with quad FX?
> 
> Because I now want to get on with my original intent which is to solve a 
> problem using APL
> rather than C/C++ since APL is much better suited for that purpose - lots of 
> arrays involved.
> 
> TIA
> 
> respect….
> 
> Peter

Re: [Bug-apl] 2 questions wrt editing my programs

[Peter Teeson]

Thanks Jürgen & Elias for your responses. I will explore both approaches. 
In fact I have downloaded Emacs for OS X from  but 
not yet installed it.

As a long time user of BBEdit, a great text editor for Mac, I've also 
downloaded the free TextWrangler app.
It's also from Bare Bones Software and is almost the same as BBEdit except for 
some language specific extras.

If I wanted to try using it as the editor for GNU APL what is the interface I 
need to use or craft?
I guess this is another way of asking how Elias was able to make things work 
with Emacs.

respect….

Peter

Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)

[Peter Teeson]

David's is a thoughtful email which which we should consider without prejudice.
The ISO standard makes clear, in chapter 4, what it means to be compliant.

When I worked at IPSA Ken Iverson's office was just a couple away from mine.
He was very thoughtful of what should be added/extended to the language and the 
QUAD's.
At the time we were adding shared variables, fairly new at that time and long 
before APL2.

IPSA APL had a component file system, BSS, initially written by Larry Breed.
Because it was essential, it was integrated into IPSA APL and we had a set of 
Quad functions to use it.
I cannot recall now but I'm pretty sure they were not part of the APL/360 
manual.

When we were exploring new capabilities we used to model them in APL first and 
there were
special privileges, really restricted to only some zoo members, to be able to 
run them. 
Later on they might be written in Assembly, which was the implementation 
language used at that time.

Because I'm old now  I suggest that we err on 
the side of caution.
Because the present GNU APL is the best thing that has come along in years, it 
would be a pity to
burden it with the sort of feature creep that has happened to far to many 
pieces of SW. Much ado about nothing.

Perhaps the place for the experimenting with these sort of things is in a 
branch, not the trunk.
And like fine wine let them ferment and mature in order to get the full flavour 
and benefit.
(Which reminds me time to pour a glass of red cab/sauv)

If I have misunderstood the gist of the various proposals then feel free to 
correct me.

respect…

Peter

Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)

[Peter Teeson]

Blake said:
> "This means creating a quad function to load, execute, and interface with 
> shared libraries (so/dll/etc).  
>   It also means standard ways of communicating data back and forth"
clap clap clap. +1.

That's basically the idea of what we did at IPSA. 
As for the file system it was built separately but interfaced with the 
interpreter through the same idea. 
I could in fact ask one of my former colleagues with whom I'm still in touch as 
he was the maintainer.

And I think GNU APL is a great gift and Jürgen's herculean effort to bring us 
this far is beyond compare.

respect…

Peter

Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)

[Peter Teeson]

This discussion is and has been healthy and useful - at least to me.
Jürgen's point's wrt the open issue of libraries etc gives us good ground to 
stand on.
Are we not all "newbies" wrt GNU APL even those who have a history using APL? I 
certainly feel that way.

Personally there has been an underlying philosophy one tries to follow in 
computer programming.
How best to resolve the tension between immediacy and elegance; between 
commercial deadlines and beauty.

And the issue of libraries and other add ons is part of a larger one - which 
language to use for implementation.
Because the choice of language so often conditions and constrains the solution 
set of the problem.
Personally I cannot recall how many times I have wished for access to call into 
APL to use it's array processing strengths.

Each language has strengths and weakness': Assembly,C/C++/Obj-C, Lisp. SNOBOL, 
COBOL, Fortran, APL, ADA, PL1, OpenGL, etc, etc.
To me these are all merely tools that should be available to artisan 
programmers to use wherever and whenever appropriate.

So in an ideal world one would be multi-lingual and be able to make use of 
whatever "tool" one chooses at the moment.
Providing GNU APL with an elegant and beautiful mechanism for libraries is a 
highly worthy objective.

Totally agree with Jürgen's quotes below. 
But in this exploration stage perhaps we should branch this off, or use some 
mechanism to indicate it's experimental.
This so that it can be withdrawn or deprecated should it turn out not to be the 
"best" solution.

from Jürgen's email:
"That means that Elias is correct in asking for certain functions in order to 
make GNU APL
more useful. And most of you seem to agree that such functions shall not be 
part of
the core GNU APL, but in libraries. 
...
A. the extension mechanism used shall be native functions
B. A library consist of:

1. C/C++ support functions in the GNU APL interpreter (creating APL values, 
access to values, etc.)
2. C/C++ code for native functions, typically wrappers to existing libraries,
3. APL code (⎕FX of the native function, but possibly more),
4. documentation"

[Bug-apl] Test build re SVN 221

[Peter Teeson]

/bin/sh ../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..   -I/usr/local/include -rdynamic -g -O2 -MT util.lo -MD -MP -MF 
.deps/util.Tpo -c -o util.lo util.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include 
-rdynamic -g -O2 -MT util.lo -MD -MP -MF .deps/util.Tpo -c util.cc  -fno-common 
-DPIC -o .libs/util.o
clang: warning: argument unused during compilation: '-rdynamic'
Showing first 200 notices only

[Bug-apl] Line Editor bug?

[Peter Teeson]

As of svn 221 


I expected the editor to allow editing of line [1] at position 10.
Did I misunderstand?

respect….

Peter

[Bug-apl] Bug-apl] APL and text editors- some initial thoughts

[Peter Teeson]

Hi Jürgen - I'm back from a mini-break.
The ISO Standard Ch 16 p 239 et seq specifically states
"The user makes entries on a keyboard, and obtains responses by seeing them 
presented on a display- device. The combination of a keyboard and a 
display-device is intended to represent, abstractly, a terminal. This 
International Standard does not require the use of any particular terminal, 
keyboard, display or method of encoding characters. The ISO 2022.2 APL 
character encoding reproduced in Annex A is widely used.
The display-device is considered a window into an unbounded sequence of past 
entries and responses. The mapping between this unbounded sequence and the 
display-device is not specified by this International Standard. "

IOW it's implementation defined. Nevertheless APL2  has been mentioned as a 
sort of de facto standard.
IMHO the design for a GNU APL  text editing capability ought to be something 
like this:

(1) The default internal editor is an implementation of the APL2 Editor 1 as 
described in the APL2 Language Reference Manual pp 383-394 et seq.

(2) All other text editors are 
   (a) either written in APL itself and thus )LOADable from some library or
   (b) are external editors, chosen by the user, and interfaced to the 
interpreter in a standard manner.
In particular I think it highly undesirable to have code in the core release to 
support any specific external editor.

Why? Because we should have an as minimal as possible core implementation that 
meets the standard.
Non-lingual extensions should be optional to the core implementation and should 
interface through the cleanest and simplest possible mechanism. Inclusion 
should be an intentional activity of the end user.

Why? Because once code becomes part of the core implementation users become 
"addicted" to it and later on it's impossible to remove it - it must be 
supported forever and constrains future development. This is not a clever 
design and we see numerous instances of this in the wild. Having an OO paradigm 
approach is a more preferred way - not necessarily for everything but certainly 
for interfacing add-ons, plugins, whatever you want to call them. The interface 
is stable whilst the add-ons can change.

So, for example, perhaps we can have a Session Manager Class as well as as well 
as an Editor Class from which the internal Editor 1 inherits; external editors 
can also do so even if they need wrappers.

As to how the editor interfaces with the interpreter I need to get up to speed 
with the current situation.
Last time I was involved with the internals was ~40 years ago and things have 
changed - both in the language itself and in the programming paradigms; 
particularly the Object Oriented paradigm becoming very prevalent these days.

More about designing the item (2)(b) standard interface later after I dig 
deeper.

respect

Peter

Re: [Bug-apl] APL and text editors- some initial thoughts

[Peter Teeson]

Hi Elias:
Firstly I am totally agnostic as to which text editor should be used.  
I don't even understand why there should be an Emacs mode. 
But since you said it's actually generic maybe we can change it's name 
to more clearly reflect its generic nature? External Editor Mode? Just a 
fleeting thought.
[APL2 had an )Editor command]

There does need to be state switching from (immediate) execution to editing to 
etc…
The IBM APL2 Language Reference has a brief discussion about this in Ch 9.

As I said I need to get up to speed on the existing mechanism.
Right now all that I have found is the existing source "Emacs" code.

Rather than read through a multitude of postings of something that is 
already in existence is there a document that I can read if I wished to 
interface 
e.g. TextWrangler telling me how would I go about it? 
(I don't intend to do that - just try to understand what we have now as an 
interface)

respect

Peter

Re: [Bug-apl] Test build re SVN 221

[Peter Teeson]

Hi Jürgen:
> "your compiler apparently pretends to be g++"
ROTFLOL
Yes no need to push this any further…..

respect…

Peter

[Bug-apl] Proposal wrt experimental code

[Peter Teeson]

Hi Jürgen:

This is a proposal for a mechanism to allow experimental code but still 
distribute it without becoming part of the "officially supported" code base. My 
reasons for proposing this have been stated previously but to recap:

"Experimental code too often becomes the de facto released code and is almost 
impossible to withdraw once users have become "addicted" to it. Like fine wine, 
design and implementation requires a maturation period. 
As developers we need to freely experiment. But we should be able to withdraw 
or replace such code when needed without negative consequences."

This proposal relates to distribution code; probably what's not in the trunk 
doesn't need it:

(0) In configure.ac. (I don't know the AC_… mechanisms) add something to 
indicate an XPERI capability. Default set to off. Run autoconf to generate a 
new configure file.

(1) Allow the end user to do ./configure --onXPERI (again I don't know the 
language) for those users
who want to experiment.

(2) The user does make ; sudo make install.  On launch the user would do apl 
--onXPERI  where
each number refers to a specific experiment.   might be in a range from 
1 - 10 e.g. if we don't want to have to much experimental code at once.

For example if I wanted to experiment with implementing the )EDITOR command I 
might be assigned the number 8.

(3) I would have to add to Command.def, Command.hh, and Command.cc. But unless 
I had specifically
turned on experimentation and for the )EDITOR command I would receive BAD 
COMMAND. 

(Note: If the addition to Command.def could be made dependant on --onXPERI  8 
then that would be automatic. If not then the actual cmd_EDITOR code would have 
to print the BAD COMMAND message)

Clearly this is only talking about commands but something similar could also be 
done for APL primitives.
At IPSA we used ⍵ and it only ran from an )OPR terminal in the fishbowl (where 
the operators were - highly restricted of course). But we were a time sharing 
operation and could not afford to let just anyone experiment.

GNU APL is primarily, but not necessarily,  a single user product. But in 
principal this idea could also work when we want to compare different versions 
of a primitive to see how well the new "optimized" one performs.

Any way it's just a suggestion. Comments solicited.

respect…..

Peter

Re: [Bug-apl] Proposal wrt experimental code

[Peter Teeson]

Hi Jürgen:

So sorry but we are not understanding each other on this.
I apologize for my inability to state it more clearly.
This is a long reply but I'm trying to explain it with words.
Too bad we can't sit down over a mug of beer (or a cup of tea) and discuss it 
IRL.

My proposal is NOT specific to the ∇-editor command [A⎕B] .
I am NOT talking about making [A⎕B] configurable. That would be an abomination.
It is just a small "bug" which will be repaired. It has nothing to do with my 
proposal.
I'm trying to look at a much bigger picture.

The core implementation of GNU APL is the ISO 13751 plus some IBM APL2. It is a 
thing of beauty.

What I was trying to do was outline a generic way to allow the development and 
eventual release of
"add ons" in a way that keeps the core implementation "pure". 

We all know of products on the market that have "feature creep" which need to 
be maintained forever
because some users have come to rely on them. That's OK if the other users 
don't have to include them.

So my proposal is for a generic mechanism that allows experimentation (and 
eventual inclusion in the distribution) but can be excluded (or included) as a 
default - it requires a user to take action to include or exclude it.

The only method I could think of was the one I proposed. Probably there is a 
better way.

Let me take a specific example:
(0) We make the design decision that the core code should include an 
implementation 
of the IBM APL2 Editor 1 a.k.a. the Line Editor. 
This has already been done but may need some tweaking.

(1) We also want to experiment by adding the IBM APL2  )EDITOR command. This is 
an "add on" because
the standard clearly states it's implementation defined. (See my earlier 
verbatim quote from the standard).

What are the steps? 
(a) Implement it first locally on the developer's installation. Test it and fix 
bugs.
(b) Make it available as part of the code distribution for wider testing - but 
as experimental code.
(c ) When it's stable, release it as optional code - (i.e. no longer 
experimental and subject to withdrawal).
  The default might be to include it (the user does nothing) or it might be 
to exclude it (the user has to 
 explicitly include it)

Now suppose we want to allow )EDITOR II or )EDITOR VI or )EDITOR Emacs.
We need to write supporting code to interface (steps a, b, c, above). 
It should NOT be part of the core implementation - it should be an "add on".
It's up to the end user to include or exclude it.

Similarly we can imagine a better way to implement ⍳ and we want to compare the 
performance of the old one with the new one. We can use the same mechanism to 
experiment and perhaps eventually release.

But we are not irrevocably bound to the code because it's experimental. (At 
IPSA we defined ⍵ as the primitive to use for experimental implementations of 
primitive functions and operators. We had both the existing and the new version 
available in the interpreter. That way we could test both of them at the same 
time.)

We would still follow the a,b,c, steps above. Of course in this case if the new 
implementation was significantly better it would be included by default. (Of 
course in a production time-shared system you could not have both 
implementations at the same time.)

Don't know if this explains it better but anyway thanks for reading it.

respect…..

Peter

[Bug-apl] Compiler Warnings after ./configure DYNAMIC_LOG_WANTED=yes

[Peter Teeson]

Hi Jürgen:
..GNUAPL/apl-svn/src/Logging.cc:32:11: Enumeration values 'LID_NONE' and 
'LID_MAX' not handled in switch
..GNUAPL/apl-svn/src/Logging.cc:42:11: Enumeration values 'LID_NONE' and 
'LID_MAX' not handled in switch
..GNUAPL/apl-svn/src/Logging.cc:47:1: Control may reach end of non-void function
..GNUAPL/apl-svn/src/Logging.cc:52:11: Enumeration values 'LID_NONE' and 
'LID_MAX' not handled in switch

respect…

Peter

[Bug-apl] Linker error libstdc++ vs Libc++

[Peter Teeson]

Sigh…..
Tracking down something in nabla I decided to start absolutely clean and did a 
new SVN checkout.
I did the usual ./configure followed by make and got this:
…..
Undefined symbols for architecture x86_64:
  "_libintl_bindtextdomain", referenced from:
  _main in apl-main.o
  "_libintl_gettext", referenced from:
  Command::process_line(UCS_string&) in apl-Command.o
  Command::cmd_CHECK(std::ostream&) in apl-Command.o
  Command::cmd_DROP(std::ostream&, std::vector > const&) in apl-Command.o
  Command::cmd_HELP(std::ostream&) in apl-Command.o
  Command::cmd_HOST(std::ostream&, UCS_string const&) in apl-Command.o
  Command::cmd_IN(std::ostream&, std::vector >&, bool) in apl-Command.o
  Command::cmd_LIB(std::ostream&, UCS_string const&) in apl-Command.o
  ...
  "_libintl_setlocale", referenced from:
  Quad_NLT::Quad_NLT() in apl-SystemVariable.o
  Quad_NLT::assign(Value_P, char const*) in apl-SystemVariable.o
  "_libintl_textdomain", referenced from:
  _main in apl-main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The reason is this:
"There are two implementations of the standard C++ library available on OS X: 
libstdc++ and libc++. 
 They are not binary compatible.
On OS X 10.8 and earlier libstdc++ is chosen by default, on OS X 10.9 libc++ is 
chosen by default. To ensure compatibility add -stdlib=libstdc++ to the linking 
command."

I happen to be on 10.8 Mountain Lion. I know 10.9 has been out 6 months and I 
have been building on it as a test.
But there are still lots of people on 10.8.

Do you feel it's worthwhile to still support OS X less than 10.9?

respect….

Peter

Re: [Bug-apl] Linker error libstdc++ vs Libc++

[Peter Teeson]

Hi Jürgen:
OK I spent some time digging around and maybe I understand a bit more.
Based on the details below it is my understanding that 
•gettext was built using libstdc++ 
•but GNU APL was built using libc++
And so we have incompatible binaries.

On OS X 10.8 I had previously, installed gettext which includes libintl in 
/usr/local/lib so I could test NLS
I now know that gettext and libintl was built then with libstdc++.
Why? Because I again  downloaded the source from GNU and grepped for libstdc++ 
and found it.
Whereas grepping for libc++ was not found.

However here is the Xcode setting for  CLANG_CXX_LIBRARY = libc++
and this is what GNU APL was built with- i.e. Apple's default.

The interesting question is what to do about it?
(1) Change Xcode setting and thus diverge from Apple default?
(2) Build gettext with libc++ - but should that not come from the maintainer?
(I certainly don't have enough deep understanding to go fiddling with the 
gettext auto tools stuff)
(3) For GNU APL on Macintosh ./configure --without-nls 

For now I shall follow (3) but in the future it might be nice to allow NLS 
support.

Not totally confident that I have analyzed this correctly. What do you think?

respect….

Peter

P.S. Now leaving this rabbit trail and going back to nabla and Editor 1

=== supporting evidence 
Here are some more details FWIW
using  previously installed get text (in March)
Using a fresh SVN co and then ./configure,  the terminal log showed the 
following
…
checking whether NLS is requested… yes
…
checking for GNU gettext in libintl... yes <<<<=
checking whether to use NLS… yes   <<<<=
So problem because of incompatible binaries
(Back in March I didn't understand the problem and just reconfigured 
--without-nls)
Now the fresh SVN co showed up the issue again and forced me to try to 
understand it.

On OS X 10.9 I have never installed gettext and libintl.
Following the same steps as above the terminal log shows
…
checking whether NLS is requested… yes
…
checking for GNU gettext in libintl... no <<<<=
checking whether to use NLS… no<<<===
…
So no problem because no NLS

On 2014-05-04, at 7:13 AM, Juergen Sauermann  
wrote:
> Hi Peter,
> 
> looks like all linker messages point to libintl. We are checking for the
> presence of libintl_gettext in configure.ac and that check seem to pass (your 
> config.log tells more).
> And then the linker (which is the compiler under a different name) complains.
> That suggests that the compiler used by ./configure us different from the 
> compiler used in make.
> This can often be cured by eg.
> 
> CXX=mycompiler ./configure
> 
> see INSTALL for more details. An alternative could be ./configure 
> --without_readline or playing around with
> --with-libintl-prefix= if you have both library variants installed.
> 
> /// Jürgen
> 
> 
> On 05/03/2014 11:53 PM, Peter Teeson wrote:
>> Sigh…..
>> Tracking down something in nabla I decided to start absolutely clean and did 
>> a new SVN checkout.
>> I did the usual ./configure followed by make and got this:
>> …..
>> Undefined symbols for architecture x86_64:
>>   "_libintl_bindtextdomain", referenced from:
>>   _main in apl-main.o
>>   "_libintl_gettext", referenced from:
>>   Command::process_line(UCS_string&) in apl-Command.o
>>   Command::cmd_CHECK(std::ostream&) in apl-Command.o
>>   Command::cmd_DROP(std::ostream&, std::vector> std::allocator > const&) in apl-Command.o
>>   Command::cmd_HELP(std::ostream&) in apl-Command.o
>>   Command::cmd_HOST(std::ostream&, UCS_string const&) in apl-Command.o
>>   Command::cmd_IN(std::ostream&, std::vector> std::allocator >&, bool) in apl-Command.o
>>   Command::cmd_LIB(std::ostream&, UCS_string const&) in apl-Command.o
>>   ...
>>   "_libintl_setlocale", referenced from:
>>   Quad_NLT::Quad_NLT() in apl-SystemVariable.o
>>   Quad_NLT::assign(Value_P, char const*) in apl-SystemVariable.o
>>   "_libintl_textdomain", referenced from:
>>   _main in apl-main.o
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> 
>> The reason is this:
>> "There are two implementations of the standard C++ library available on OS 
>> X: libstdc++ and libc++. 
>>  They are not binary compatible.
>> On OS X 10.8 and earlier libstdc++ is chosen by default, on OS X 10.9 libc++ 
>> is chosen by default. To ensure compatibility add -stdlib=libstdc++ to the 
>> linking command."
>> 
>> I happen to be on 10.8 Mountain Lion. I know 10.9 has been out 6 months and 
>> I have been building on it as a test.
>> But there are still lots of people on 10.8.
>> 
>> Do you feel it's worthwhile to still support OS X less than 10.9?
>> 
>> respect….
>> 
>> Peter
>> 
> 

Re: [Bug-apl] Linker error libstdc++ vs Libc++

[Peter Teeson]

We probably want to do that at some time anyway but IMHO a simpler solution is 
to make
the default in configure be --without-nls. Particularly in view of Jürgen's 
comments.
So if somebody wants NLS they have to be intentional. Either way it's no big 
deal
to just add it or remove it at ./configure time. 

I have no idea of how to achieve the following but probably the best solution 
is to have 
a GNU gettext built using libc++ which seems to be more modern than libstdc++. 
It includes the STLwhich, IIRC, was a motivator for the original libstdc++. 
My recollection may be wrong though. Of course we then have the fragile binary 
problem
to overcome in the wild and it may not be worth the agony.

As to documenting it in the GNU APL on Macintosh  "A Brief Installation Guide" 
I will do that either way. Also in the forthcoming GNU APL on Macintosh 
"Developing using Xcode"

respect…

Peter
On 2014-05-07, at 7:39 AM, Elias Mårtenson  wrote:
> How about we build an binary package for OSX? Another alternative is a 
> Hombrew recipe.
> 
> Regards,
> Elias
> 
> On 7 May 2014 19:22, "Juergen Sauermann"  
> wrote:
> Hi Peter,
> 
> when I first looked at internationalization my impression was that it could 
> be a good idea,
> in particular for ⎕NLT.
> 
> After that saw a number of problems with translation and locales, and I was 
> several times
> close to removing it again (and I may actually do that at some point in time).
> 
> Currently only a few major error messages (SYNTAX ERROR, VALUE ERROR, etc) 
> can be
> translated to German. More detailed information via )MORE and debug messages 
> are not
> translated. So removing gettext() altogether would not harm too much.
> 
> My proposal would therefore be ./configure --without-nls and maybe
> mention that in your nice Macintosh manual.
> 
> Best Regards,
> Jürgen

Re: [Bug-apl] Linker error libstdc++ vs Libc++ (maybe) SOLVED

[Peter Teeson]

Previously I said "OK I spent some time digging around and maybe I understand a 
bit more."
and also "Not totally confident that I have analyzed this correctly. What do 
you think?"
Well here is a better analysis which I do feel more confident about. 

The version of gettext I had previously installed (in April of 2013) was 0.18.2 
dated 2012 -12-25
I downloaded the current release last week which is 0.18.3 dated 2013-07-07 and 
just now built and installed it.
Then I did: SVN co  GNU APL, ./configure ; make; sudo make install ; apl
and it all worked!! I tried ⎕NLT and got C. 

I'd like to test German or French but don't know how to do that as I don't know 
the IBM language codes.

Anyway seems we don't have to do anything about NLS (except mention gettext  in 
the Mac booklets along with M4)
The old saying "Timing is everything" sure seems to apply here.

respect….

Peter

On 2014-05-07, at 10:31 AM, Elias Mårtenson  wrote:
> The way configure is supposed to work is that it tests if it's possible to 
> build with a library, and it will deselect it if it doesn't work.
> 
> Also, as far as I can tell, this issue only occurs if one has built gettext 
> prior to upgrade to 10.9.
> In this particular case, it seems reasonable for configure to warn what is 
> going on.
> 
> Regards,
> Elias

Re: [Bug-apl] native function lib_file_io reload not working

[Peter Teeson]

Hi Jürgen:
Never noticed the link before but I just printed it out for thoughtful reading.

respect….

Peter
On 2014-05-08, at 10:25 AM, Juergen Sauermann  
wrote:
> Hi,
> 
> I have written a proposal earlier but haven't received any comments so far.
> 
> The document is available here: 
> http://www.gnu.org/software/apl/Library-Guidelines.html
> so that we don't need to scan the bug-apl mail archive.
> 
> According to it package⍙ is the prefix for meta information of a package 
> while package∆ is
> the prefix for package functions and global variables.
> 
> I also believe that we should have a common web page for libraries and all 
> the other GNU APL related
> contributions from the GNU APL community so that they dont get lost and 
> people dont need to scan
> the bug-apl mail archive for the latest version.
> 
> /// Jürgen
> 
> 
> On 05/08/2014 03:01 PM, Elias Mårtenson wrote:
>> Is this the standard system we should abide by? To separate the module and 
>> function name with ⍙? Are we using ∆ for public functions and ⍙ for private 
>> ones? So far I've used ∆∆ (two deltas) as separator for internal functions.
>> 
>> Regards,
>> Elias
>> 
>> 
>> On 8 May 2014 20:56, Juergen Sauermann  wrote:
>> Hi David,
>> 
>> thanks, fixed in SVN 252.
>> 
>> /// Jürgen
>> 
>> 
>> 
>> On 05/07/2014 08:53 PM, David B. Lamkins wrote:
>>'lib_file_io' ⎕fx 'pkg⍙fileio'
>> pkg⍙fileio
>>)erase pkg⍙fileio
>>'lib_file_io' ⎕fx 'pkg⍙fileio'
>> pkg⍙fileio
>>pkg⍙fileio⍬
>> VALUE ERROR
>>pkg⍙fileio⍬
>>^
>>
>> 
>> 
>> 
>> 
>> 
> 

Re: [Bug-apl] )SAVE should show WSID

[Peter Teeson]

I think you are correct Blake. 
IIRC @ IPSA we used UTC internally for things saved to HD. 
But displayed local time on the Terminal which was an IBM 2741 with an APL golf 
ball.

(FWIW We also had a really really precise external clock custom built for us 
which we used for date/time things rather than the System 360 clock.)

Peter

On 2014-05-09, at 12:13 PM, Blake McBride  wrote:
> Greetings,
> Perhaps the time they are showing is local and the "(GMT-4)" is showing its 
> relationship to GMT.
> 
> Blake
> 
> On Fri, May 9, 2014 at 11:03 AM, Juergen Sauermann 
>  wrote:
> Hi,
> 
> GNU APL is following the IBM APL2 language reference manual as much as 
> possible (so that we can
> use it as GNU APL reference and need no write our own one).
> 
> It says:
> 
> "For example:
>   )WSID
> THISWS
>   )SAVE
> 1992-03-27 21 .51.09 (GMT-4) THISWS
> 
> Note: The system response includes the workspace name when it is omitted from
> the )SAVE command."
> 
> The only difference I can see right now is that the workspace ID is not shown 
> if omitted in the )SAVE command.
> I will fix that. The rest (GMT offset etc) should remain as is (it would also 
> break my testcases to change it).
> 
> /// Jürgen
> 

[Bug-apl] TERM env var not getting set

[Peter Teeson]

Using Mac OS X 10.8 and the Apple Xcode 5.1.1 development IDE

The first few lines in main are:
int
main(int argc, const char * _argv[])
{
   {
 // make curses happy
 //
 const char * term = getenv("TERM");
 if (term == 0 || *term == 0)   setenv("TERM", "dumb", 1);
   }

bool log_startup = false;

Normally I pass the environment variable TERM=xterm-256color when launching APL.
As a test I did not pass anything for TERM. (part of an anomaly I'm trying to 
debug)

So I set a breakpoint on the first statement.
The debugger, lldb, shows that the term var had been initialized to NULL.
After the call to getenv() the PC was positioned at the log_startup line.

IOW the if statement was skipped and so the setenv() never happened.

I remain confused.

respect…..

Peter

[Bug-apl] Error after make developer

[Peter Teeson]

I did ./configure ; make develop; make

/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Value.cc:1319:9: Goto 
into protected scope
Value.cc:1319:9: error: goto into protected scope
goto complete;
^
const Cell * C = &get_ravel(0);
 ^
uint32_t error_count = 0;
 ^
respect….

Peter

Re: [Bug-apl] TERM env var not getting set

[Peter Teeson]

Hi Jürgen:
Thanks - didn't know about Q or Q1.. they are defined in Common.hh right?

(const void *)(getenv("TERM")): '0' at main.cc:269
getenv("TERM"):  '(lldb)

(const void *)(getenv("TERM")): '0x100309215' at main.cc:278
getenv("TERM"):  'dumb' at main.cc:279

So you are correct - it's working but the debugger is not my friend.

respect

Peter
On 2014-05-22, at 9:55 AM, Juergen Sauermann  
wrote:
> Hi Peter,
> 
> interesting. Try
> 
> Q((const void *)(getenv("TERM")))
> Q(getenv("TERM"))
> 
> (needs recompile) before:
> 
> bool log_startup = false;
> 
> I guess your debugger is fooling you.
> 
> /// Jürgen
> 
> 
> On 05/21/2014 09:59 PM, Peter Teeson wrote:
>> Using Mac OS X 10.8 and the Apple Xcode 5.1.1 development IDE
>> 
>> The first few lines in main are:
>> int
>> main(int argc, const char * _argv[])
>> {
>>{
>>  // make curses happy
>>  //
>>  const char * term = getenv("TERM");
>>  if (term == 0 || *term == 0)   setenv("TERM", "dumb", 1);
>>}
>> 
>> bool log_startup = false;
>> 
>> Normally I pass the environment variable TERM=xterm-256color when launching 
>> APL.
>> As a test I did not pass anything for TERM. (part of an anomaly I'm trying 
>> to debug)
>> 
>> So I set a breakpoint on the first statement.
>> The debugger, lldb, shows that the term var had been initialized to NULL.
>> After the call to getenv() the PC was positioned at the log_startup line.
>> 
>> IOW the if statement was skipped and so the setenv() never happened.
>> 
>> I remain confused.
>> 
>> respect…..
>> 
>> Peter
>> 
>> 
> 

[Bug-apl] stdin still echoed to stdout even with --noCIN

[Peter Teeson]

In Xcode I pass TERM=xterm-256color as an env var. This is the value Terminal 
uses.
Also --noCIN as an option at launch time to turn off echoing stdin.

Set breakpoint here in UserPreferences.cc:
 else if (!strcmp(opt, "--noCIN"))
{
  do_not_echo = true;
}
and we did break and it got set.
(lldb) po do_not_echo
true

But APL is still echoing stdin as well as stdout to the Xcode console pane.
How best to track this down in Input/Output?

respect….

Peter

Re: [Bug-apl] stdin still echoed to stdout even with --noCIN

[Peter Teeson]

Hi Jürgen:
Thanks for your suggestion but 
CinOut::overflow(int c)
{
   Q(uprefs.echo_current_file());

   if (!uprefs.echo_current_file())   return 0;

CInOut::overflow(int c) is never called. Please see my next post.

Peter

On 2014-05-23, at 8:43 AM, Juergen Sauermann  
wrote:
> Hi Peter,
> 
> the decision if a cin character, say c, should be echoed or not is made
> in CinOut::overflow(int c) by asking uprefs.echo_current_file().
> Note that uprefs.echo_current_file() not only depends on the command
> line option --noCIN but also on its position in relation to -f (if used) etc. 
> and
> that it may return different values for different input files.
> 
> You can use Q(uprefs.echo_current_file()) at the beginning of
> CinOut::overflow(int c) (creating a lot of debug output).
> 
> If the input is echoed even though it shouldn't then there are two possible 
> culprits:
> 
> 1. uprefs.echo_current_file() returns true, or
> 2. ECHO bit in then c_lflag of the terminal attributes is set (check with 
> stty -a)
> 
> The color of the echoed input might give you a hint: if the color changes 
> before the
> echoed input changed then we have 1, if not then we have 2,
> 
> /// Jürgen

Re: [Bug-apl] Boehm garbage collector

[Peter Teeson]

FWIW Apple moved away from GC and instead uses ARC <=> Automatic Reference 
Counting.
In my experience it has radically reduced the MRR <=> Manual Retain Release 
effort for the programmer.
If anyone is interested here is a link that may be of interest.


Peter

On 2014-05-29, at 1:14 PM, "David B. Lamkins"  wrote:

> I'll add to that:
> 
> The Boehm collector is in the family of "conservative" collectors.
> Briefly, since there's no way to give the collector a precise list of
> roots to the data structures in the heap (this is true, for example, of
> pointers on the stack and in structures), the collector instead uses the
> hueristic of testing the value of a machine word to see whether it
> contains an address in the heap; if the word passes this test, it's
> assumed to be a pointer.
> 
> A conservative GC therefore won't collect any object that's still live,
> but it *may* hold onto chunks of memory that aren't actually live. (You
> might have a scalar value, for example, that "looks like" a pointer.)
> The end result is a space leak.
> 
> In practice, this is *usually* not a problem. I have seen production
> systems, though, in which a conservative GC caused catastrophic space
> leaks under the right (wrong) conditions.
> 
> A reference-counting collector won't have these problems. 
> 
> Additionally, the work done by a reference-counting collector is evenly
> amortized over the execution of the program, whereas a mark-sweep
> collector (like Boehm) causes a pause (sometimes significant, depending
> upon circumstances of the size of the heap, state of the heap, speed of
> the machine, etc.) at unpredictable intervals for collection.
> 
> A proper GC can be an attractive alternative to reference counting in
> the case where there may be circularity in references. I don't believe
> that circularity of references is an issue in APL, unless the
> implementer has explicitly tried to do clever sharing optimizations.
> 
> On Thu, 2014-05-29 at 10:38 -0500, Blake McBride wrote:
>> Dear Elias,
>> 
>> 
>> I have experience with the Boehm collector and thought I would share
>> some opinions.
>> 
>> 
>> 1.  Since C/C++ was not designed with GC in mind, the Boehm collector
>> is forced to take into account many very system specific factors.
>> These factors vary widely from system to system, and from system
>> release to system release.  This means that, rather than portable
>> code, you are maximally system dependent.  While that may be fine as
>> long as the Boehm team continues to support their collector, all of
>> your code will fall on its face the day they don't.  In other words,
>> anything built with the Boehm collector will from then on be
>> completely dependent on them.  The source code they provide, while
>> complete, is pretty useless unless you understand all of the very
>> system specific nuances of each system they support.  In other words,
>> you can't support it yourself.
>> 
>> 
>> 2.  A GC like Boehm would never be as fast as reference counting.
>> Reference counting, when possible, only does what it needs to do at
>> the time it needs to do it.  A generic GC has to use up a specified
>> amount of memory and then check everything.  I know generational GC's
>> and concurrent GC's minimize some of this but it still takes time and
>> their assumptions are rarely completely accurate so their function is
>> reduced, i.e. _conservative_ collector.
>> 
>> 
>> The Boehm collector is a great solution when you want to add GC to a
>> system after-the-fact, or if you are unwilling to do the hard work
>> yourself.  It seems to me that Jurgen has already done the hard work
>> in a portable way.  I'd prefer not to mess with it, nor pepper the
>> system with Boehm ifdefs.
>> 
>> 
>> Just an opinion (from someone who has used the Boehm collector and has
>> written my own collectors).
>> 
>> 
>> Thanks.
>> 
>> 
>> Blake
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Thu, May 29, 2014 at 9:24 AM, Elias Mårtenson 
>> wrote:
>>I've been playing around with the Boehm (Böhm, I suppose)
>>garbage collector, and it's pretty amazing. Jürgen, do you
>>have any experience with it?
>> 
>> 
>>Updating the GNU APL code to (conditionally, with a compiler
>>option) to support using the collector for at least Value
>>objects should be fairly simple. This would provide several
>>benefits:
>>  * A performance improvement since there is no need to
>>deal with the reference counter.
>>  * Improved parallelism if one wants to expand threading
>>beyond simply paralellising simple loops (no need to
>>deal with race conditions when accessing the reference
>>count)
>>  * Provide a more solid ground when attempting to reduce
>>excessive cloning (with the GC, once can simpl

[Bug-apl] Is this output incorrect?

[Peter Teeson]

Please note the command line options. My question is:
Should the following be (a) indented by 6 spaces and (b) Nabla::edit ought to 
provide line numbering?


respect….

Peter

Re: [Bug-apl] Is this output incorrect?

[Peter Teeson]

Hi Jürgen:
Well please help me properly understand the no_readline function in Input.cc.
Because it's called instead of the readline library because of the --rawCIN.
I've made comments of my interpretation of the code but am probably wrong.
So I'd appreciate any contribution to my very rusty C++.

no_readline(const UCS_string * prompt)
{
   if (prompt)  // points at 6 spaces x'20'
  {
CIN << '\r' << *prompt << flush;// CIN is an ostream see 
Output.cc
UTF8_string prompt_utf(*prompt);
loop(p, prompt_utf.size())  // ungets those spaces from stdin
   {
 const int cc = prompt_utf[prompt_utf.size() - p - 1];
 ungetc(cc & 0xFF, stdin);
   }
  }
etc

Much appreciated and

respect…

Peter

On 2014-05-31, at 11:13 AM, Juergen Sauermann  
wrote:
> Hi Peter,
> 
> looks OK to me. (Note: as of recently apl -s does the same as your command 
> line options).
> 
> --rawCIN reads directly from the file (stdin in this case) without outputting 
> any prompts.
> The line numbers in the ∇-editor count as prompts and are therefore 
> suppressed as well.
> 
> However when you display the function with [⎕] then the line numbers are not 
> prompts
> but output of the editor.
> 
> /// Jürgen

Re: [Bug-apl] Is this output incorrect?

[Peter Teeson]

Thanks Jürgen for correcting my comment.
You've prompted me to browse through my venerable copy of Josuttis' The C++ 
Standard Library.
 
respect…

Peter

On 2014-06-01, at 8:00 AM, Juergen Sauermann  
wrote:
> Hi Peter,
> 
> almost correct. The first comment should be "// may point to an optional 
> string typically containing 6 spaces".
> prompt can be 0 and then no prompt is printed. Otherwise the function pushes 
> the prompt (backwards)
> back into stdin. Whether that works is a matter of the underlying operating 
> system. The man page
> of ungetc() says that only 1 ungetc() char is guaranteed but we push 6. 
> Another question is whether
> an ungetc() into stdin will occur on C++ cin?
> 
> The main use case for this were scripts where it does not matter too much if 
> a prompt is printed
> or not. Note also that pushing chars back into stdin has a different effect 
> than just printing the prompt
> - there are  cases where the prompt should be editable (⍞ I believe).
> 
> /// Jürgen

Re: [Bug-apl] Command::process_line breakup

[Peter Teeson]

Well this is an opportunity to bring up something that has been on my mind for 
some time.

My feeling is that a better way to deal with the I/O issue is to have an 
abstract Class ( or Classes) from which
the various I/O implementations can inherit.  e.g. Class Input, Class Output or 
Class InputOutPut.

The present implementation of a terminal / command line interface would be the 
default and be one example.
In Xcode I have run into issues trying to make a simple wrapper for GNU APL.
Not the least of these is avoiding terminal control codes which I presently do 
with apl launch options - a bit crufty.

Mentally I have a picture of the interpreter as a (potentially) embeddable item 
with a full duplex I/O channel.
It is the interpreter that is the crucial thing that does the work of solving. 
The I/O is just the Microphone and Speaker.
Then one can use (or implement) the I/O mechanism of one's choice.

Of course there must be constraints on what is acceptable input (must be 
characters and must be in quadAV?).
I submit that this approach is preferable versus adding special case code 
(which is never ending) and
 IMHO neither elegant nor desirable even if it is practical. :-}

Just my 2¢ FWIW.

much respect to everyone.

Peter
On 2014-06-05, at 10:49 AM, Elias Mårtenson  wrote:

> In the Android version that I have started working on, am I not going for a 
> plain text-based I/O model like the normal GNU APL session. This is because 
> terminal-oriented sessions are quite cumbersome to work with on a small 
> mobile device.
> 
> Instead, I intend to be a bit more clever when rendering results, being able 
> to do things like collapsing parts of the array, doing searches, panning them 
> around with the touchscreen. I haven't actually implemented any of this yet, 
> but those are my rough ideas.
> 
> Anyhow, this means that the mainloop looks significantly different compared 
> to the normal version. And what I realise is happening is that I am 
> reimplementing most of Command::process_line. I can't really re-use anything 
> in it because it's such a big single method.
> 
> My question is: Would it be possible to break it up into smaller functions 
> that I can call from the Android interaction loop? Ideally, I would like to 
> be able to pass a string into a function for evaluation (taking account all 
> the stuff like the SI stack etc) and simply return a Token that represents 
> the result of the evaluation. I'm perfectly fine with having the Error being 
> thrown in case of error.
> 
> Commands can be handled separately of course (I intend to present those in a 
> menu most likely).
> 
> Would this be doable?
> 
> Regards,
> Elias

Re: [Bug-apl] GNU APL for Android

[Peter Teeson]

Good for you Elias. That is precisely along the lines I am working -
build the interpreter as a dll wrapped in the I/O  mechanism of your choice.

respect…

Peter

On 2014-06-10, at 6:03 AM, Elias Mårtenson  wrote:

> I am on vacation right now, so what better time to work on some fun open 
> source projects?
> 
> This year I'm working on GNU APL for Android, and I've reached a milestone 
> today. The application runs, I can enter expressions and I get results back.
> 
> The way I've implemented is that I have compiled GNU APL as a dynamic library 
> and not using the I/O mechanisms for the normal implementation. Instead, I 
> link the shared library into the Java code that drives the user interface, 
> which calls into GNU APL to do the actual processing.
> 
> It's not actually usable yet, however, because I need to write a custom 
> keyboard implementation so it's incredibly difficult to actually enter any 
> APL expressions right now (you're basically forced to use copy&paste). That 
> fact is the reason I'm not distributing a APK file yet.
> 
> If anyone is interested in looking at the code, it's here: 
> https://github.com/lokedhs/android-gnu-apl
> 
> Regards,
> Elias

[Bug-apl] Revision 327 minor warning

[Peter Teeson]

GNUAPL/apl-svn/src/UTF8_string.cc:273:1: Control reaches end of non-void 
function

Re: [Bug-apl] Android features

[Peter Teeson]

I suggest once again two abstract classes for I/O with virtual methods which 
can then be inherited from and implemented by the user.
This special case patching of fixes  is not elegant - to me it is smelly 
coding. 
Sorry if I offend but that's my 2¢.

Peter

On 2014-06-15, at 4:06 PM, Elias Mårtenson  wrote:

> Do you think it would be possible to apply this patch that avoids setting up 
> the output streams when compiling for Android? The Android version installs 
> its own that redirects the output to Java streams.
> 
> Regards,
> Elias
> 

Re: [Bug-apl] Android features

[Peter Teeson]

Hi Jürgen:
Thanks for responding to my proposal.
Yes I understand and didn't take static into account.
I do like your cleaner and simple proposal.

Where would the source for all these Class XyzInput files be hosted?
Part of the distribution? Or would the end user supply them at build time?
I would hope that they must also be GNU licensed like the rest?

Also would we allow just one Android, one OS X, etc?

And how do you feel about Output? Does it make sense to do the same thing there?

respect……

Peter

On 2014-06-16, at 12:30 PM, Juergen Sauermann  
wrote:
> Hi Peter,
> 
> I see a few problems with your proposal.
> 
> Currently class Input has only static functions, so virtual methods can not 
> be used to distinguish
> between different implementations of the same function.
> 
> Suppose we would fix that by using Input instances. Instead of eg.
> 
> #ifdef HAVE_ANDROID
> 
> line = Android_Input::get_line();
> 
> #else
> 
> line = Input::get_android_line();
> 
> #endif
> 
> We would then have eg.
> 
> class Input { ... }
> class Android_Input: public Input { ... }
> class Normal_Input: public Input { ... }
> 
> #ifdef HAVE_ANDROID
> 
>   Android_Input a_input;
>   Input * input = a_input;
> 
> #else
> 
>   Normal_Input n_input;
>   Input * input = a_input;
> 
> #endif
> 
> ...
> line = input->get_line();
> 
> IMHO this is only adding complexity without really making things more elegant.
> 
> And it does not solve the real problem, which I believe is the following. I 
> assume
> that Elias' Java environment has a number of nasty (read: totally 
> incompatible) things that
> I cant support in a reasonable (read: portable) way. The two derived classes 
> would still need
> to be compiled, but one of them is not portable, which will create a lot of 
> headache for all
> non-Android users.
> 
> A much cleaner (or at least simpler) proposal, in my eyes, is this:
> 
> 1. We use two files Input.cc and AndroidInput.cc.
> 2. Both use the same Input.hh so that all other source files are no affected. 
> Not all functions
> declared in Input.hh need to be implemented, so AndroidInput.cc. can be 
> rather simple.
> 3. The src/Makefile decides which of the two files shall be compiled in a 
> given environment.
> 
> /// Jürgen
> 
> 
> On 06/16/2014 04:43 AM, Peter Teeson wrote:
>> I suggest once again two abstract classes for I/O with virtual methods which 
>> can then be inherited from and implemented by the user.
>> This special case patching of fixes  is not elegant - to me it is smelly 
>> coding. 
>> Sorry if I offend but that's my 2¢.
>> 
>> Peter
>> 
>> On 2014-06-15, at 4:06 PM, Elias Mårtenson  wrote:
>> 
>>> Do you think it would be possible to apply this patch that avoids setting 
>>> up the output streams when compiling for Android? The Android version 
>>> installs its own that redirects the output to Java streams.
>>> 
>>> Regards,
>>> Elias
>>> 
>> 
>> 
> 

Re: [Bug-apl] Android features

[Peter Teeson]

Hi Elias:
Sorry but I am totally ignorant about Android so don't know how the following 
comments apply, if at all.

As a first step in OS X I am going to experiment with setting up file handles 
for pipes, setting up NSNotifications,  and launching a sub-task.
See NSTask documentation and sample code such as Moriarty and QCComposer.
Both are Cocoa event driven wrappers of command line programs. 
The sub task gets the environment of the launcher but is a separate process.

My eventual goal would be to try to build the interpreter as a dynlib and 
possible later also a framework.

respect….

Peter
On 2014-06-16, at 12:56 PM, Elias Mårtenson  wrote:
> Note that the Android port doesn't really do input. It's all event-driven 
> from the user interface. That said, I'll need to deal with quad-assignment. 
> Trying that right now would cause it to hang since there is no way to send 
> input to stdin.
> 
> So yeah, I'd need some mechanism by which I can be informed that the running 
> APL program is requesting input (quad-assignment). I haven't looked at that 
> yet though.
> 
> Regards, 
> Elias
> 
> On 16 Jun 2014 18:30, "Juergen Sauermann"  
> wrote:
> Hi Peter,
> 
> I see a few problems with your proposal.
> 
> Currently class Input has only static functions, so virtual methods can not 
> be used to distinguish
> between different implementations of the same function.
> 
> Suppose we would fix that by using Input instances. Instead of eg.
> 
> #ifdef HAVE_ANDROID
> 
> line = Android_Input::get_line();
> 
> #else
> 
> line = Input::get_android_line();
> 
> #endif
> 
> We would then have eg.
> 
> class Input { ... }
> class Android_Input: public Input { ... }
> class Normal_Input: public Input { ... }
> 
> #ifdef HAVE_ANDROID
> 
>   Android_Input a_input;
>   Input * input = a_input;
> 
> #else
> 
>   Normal_Input n_input;
>   Input * input = a_input;
> 
> #endif
> 
> ...
> line = input->get_line();
> 
> IMHO this is only adding complexity without really making things more elegant.
> 
> And it does not solve the real problem, which I believe is the following. I 
> assume
> that Elias' Java environment has a number of nasty (read: totally 
> incompatible) things that
> I cant support in a reasonable (read: portable) way. The two derived classes 
> would still need
> to be compiled, but one of them is not portable, which will create a lot of 
> headache for all
> non-Android users.
> 
> A much cleaner (or at least simpler) proposal, in my eyes, is this:
> 
> 1. We use two files Input.cc and AndroidInput.cc.
> 2. Both use the same Input.hh so that all other source files are no affected. 
> Not all functions
> declared in Input.hh need to be implemented, so AndroidInput.cc. can be 
> rather simple.
> 3. The src/Makefile decides which of the two files shall be compiled in a 
> given environment.
> 
> /// Jürgen
> 
> 
> On 06/16/2014 04:43 AM, Peter Teeson wrote:
>> I suggest once again two abstract classes for I/O with virtual methods which 
>> can then be inherited from and implemented by the user.
>> This special case patching of fixes  is not elegant - to me it is smelly 
>> coding. 
>> Sorry if I offend but that's my 2¢.
>> 
>> Peter
>> 
>> On 2014-06-15, at 4:06 PM, Elias Mårtenson  wrote:
>> 
>>> Do you think it would be possible to apply this patch that avoids setting 
>>> up the output streams when compiling for Android? The Android version 
>>> installs its own that redirects the output to Java streams.
>>> 
>>> Regards,
>>> Elias
>>> 
>> 
>> 
> 

Re: [Bug-apl] Can't break out of the middle on a display operation

[Peter Teeson]

In Sharp APL (IPSA) we had a "panic int" which interrupted whatever was being 
computed after a predetermined time.
It was inherent to the interpreter because we ran a timesharing system.
I don't recall the exact details but it went something like this;

1) Workspace gets swapped in for execution and is given a quantum of CPU time
2) At the end of that quantum a second but quite small (relative to the normal 
) additional amount of CPU was allocated 
 to see if that would allow an interrupt at a "suitable" point in the 
function/operation that was going on.
3) If that extra time was not sufficient the workspace was arbitrarily 
interrupted and AFAICR the user got )CLEAR WS.

That's probably not exactly correct (I never read the actual assembly code for 
that part of the interpreter).
But the idea worked for us.

On a single user system there is no real need for a specific quantum; the OS 
takes care of  scheduling.
But perhaps a "panic int" concept in some form or other might be useful?
Perhaps allowing the user to decide if they want to continue? 
Perhaps with a default value? Perhaps assignable by the user?

respect…

Peter

On 2014-07-08, at 1:50 PM, Blake McBride  wrote:

> If I do:
> 
>   z←⍳100
> 
> the operation is very fast.  But if I do:
> 
>   ⍳100
> 
> it is very slow, presumably because it is formatting the whole thing for 
> display.  No problem.
> 
> The problem is that during its effort to format for display, I cannot use ^C. 
>  ^C appears to work fine in normal situations - but not during the format for 
> display time.  During format-for-display time ^C is ignored.
> 
> This caused me a problem when I accidentally mis-typed something.  The 
> mis-type caused something very large to be displayed.  In fact, it was so 
> large that my machine started paging.  I was unable to use ^C to stop it.  
> After waiting an hour, I had to kill the process and loose my work.
> 
> Thanks.
> 
> Blake
> 

Re: [Bug-apl] ISO Component File API preview

[Peter Teeson]

On 2014-07-10, at 5:22 PM, Blake McBride  wrote:
> What I've been trying to convey (and clearly have failed on every attempt so 
> far) is that an APL component file system must be file-centric. Every APL 
> component file system that I've worked with or have read about has created a 
> file to contain its APL data components.
> 
> Conceptually, yes.  Actually, what goes on under the hood is implementation 
> specific.  In our present case, each component file would equate to an SQL 
> table - not an SQL database.  This is very important.  So, if your 
> applications uses 15 component files, that would be represented as 15 SQL 
> tables in one SQL database.
In my experience with the IPSA/STSC file system a component file could store 
different data types in each component.
In my experience with various SQLs an SQL table only stores records whose 
fields are consistent for each record.
Therefore I do not agree that component file maps to an SQL table.

Peter

Re: [Bug-apl] ISO Component File API preview

[Peter Teeson]

The IPSA/STSC file system, also know as BSS (Backing Store (sub)System) ran as 
an independent process.
It so happened that it was only used via the APL interpreter. 
But were it available to the world at large other programs could have utilized 
it given the API and the code to access it.
IFRC it was layered on top of ISAM or maybe VSAM (I don't exactly remember)

Without having examined your keyed file system, and on no way making a value 
judgement, 
I infer from your comments in reply to my previous post that it is dependant on 
APL.

Am I correct?

Peter
On 2014-07-10, at 6:07 PM, Blake McBride  wrote:

> On Thu, Jul 10, 2014 at 4:49 PM, Peter Teeson  wrote:
> 
> On 2014-07-10, at 5:22 PM, Blake McBride  wrote:
>> What I've been trying to convey (and clearly have failed on every attempt so 
>> far) is that an APL component file system must be file-centric. Every APL 
>> component file system that I've worked with or have read about has created a 
>> file to contain its APL data components.
>> 
>> Conceptually, yes.  Actually, what goes on under the hood is implementation 
>> specific.  In our present case, each component file would equate to an SQL 
>> table - not an SQL database.  This is very important.  So, if your 
>> applications uses 15 component files, that would be represented as 15 SQL 
>> tables in one SQL database.
> 
> In my experience with the IPSA/STSC file system a component file could store 
> different data types in each component.
> In my experience with various SQLs an SQL table only stores records whose 
> fields are consistent for each record.
> Therefore I do not agree that component file maps to an SQL table.
> 
> Peter
> 
> 
> The way I implemented the keyed file system, which supports arbitrary nested 
> arrays of varying size and types in each record, is as follows:
> 
> Each table is defined to have two columns (for data - not including the key). 
>  One is a varchar, the other is a text.  I use GNU APL's 14 ⎕CR and ¯14 ⎕CR 
> to convert between arbitrary nested APL arrays and string vectors.  If the 
> string vector is short I use the varchar field.  If it is long, I use the 
> text field.
> 
> So, SQL only sees varying length strings.  APL sees arbitrary APL nested (or 
> not nested) arrays.
> 
> --blake
> 
> 
> 

[Bug-apl] Warning SVN 371 on OS X

[Peter Teeson]

/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/APserver.cc:609:1: 
Control reaches end of non-void function

#else
int
open_UNIX_socket(const char * listen_name)
{
   cerr << "*** this platform does not support address family AF_UNIX!";
}
#endif

Re: [Bug-apl] TextWrangler, Emacs Key Bindings and GNU APL

[Peter Teeson]

Here is some additional info from the User Manual:
The first time you run TextWrangler after installation, it will offer to
install the “edit”, “twdiff”, and “twfind” command line tools for you.

You can use the “edit” command line tool to open files into TextWrangler
via the Unix command line.

To open a file into TextWrangler from the command line, type

edit 

To launch TextWrangler without opening a file (or to activate the
application if it is already running), type edit -l 

You can also pipe STDIN to the “edit” tool, 
and it will open in a new untitled window in TextWrangler: 

for example, ls -la | edit 

If you just type edit with no parameters, the tool will accept STDIN from the 
terminal; 
type Control-D (end-of- file) to terminate and send it to TextWrangler.

On 2014-07-20, at 3:36 PM, Peter Teeson  wrote:

> Bare Bones Software makes a free text editor for Macintosh called 
> TextWrangler.
> It's a mildly stripped down version of their great BBEdit professional 
> product which I have used for umpteen years.
> The interesting thing is that it has a bunch of Emacs Key Bindings. See below 
> for details.
> 
> Following Elias' lead with emacs I'm thinking it would be nice to make it 
> available on Macintosh.
> How should I go about that?
> 
> respect….
> 
> Peter
> 
> 
> 
> 
> 

[Bug-apl] Build error SVN 403 on OS X 10.8.5

[Peter Teeson]

Did a brand new checkout, ./configure, make
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/FloatCell.cc:393:39: 
Call to 'pow' is ambiguous
FloatCell.cc:393:39: error: call to 'pow' is ambiguous
  const APL_Float z = pow(A->get_real_value(), b);
  ^~~
extern double pow(double, double);
  ^
  pow(double __x, int __i)
  ^
  pow(float __x, float __y)
  ^
  pow(long double __x, long double __y)
  ^
  pow(float __x, int __n)
  ^
  pow(long double __x, int __n)
  ^
1 error generated.
make[1]: *** [FloatCell.o] Error 1
make[1]: *** Waiting for unfinished jobs
mv -f .deps/ComplexCell.Tpo .deps/ComplexCell.Po
mv -f .deps/Function.Tpo .deps/Function.Po
mv -f .deps/Error.Tpo .deps/Error.Po
mv -f .deps/Id.Tpo .deps/Id.Po
mv -f .deps/DerivedFunction.Tpo .deps/DerivedFunction.Po
mv -f .deps/Executable.Tpo .deps/Executable.Po
mv -f .deps/Command.Tpo .deps/Command.Po
make: *** [all-recursive] Error 1

[Bug-apl] Strange T∆ output... OS X 10.8.5

[Peter Teeson]

I launched apl --noColor --silent
Version / SVN:  1.3 / 7603

When I trace this line: i←(2|j)/j←⍳×/k←⍴Y it produces this display
Please display the tiff because when I copy/paste mail shows this 
13579111315 which is not what I see on the Terminal.
but it should display this value for i
adj[5] 1 3 5 7 9 11 13 15

What could be happening?

Thanks

Peter

[Bug-apl] Determining data type...

[Peter Teeson]

I feel pretty stupid.
Looked in the APL2 IBM manual but do not understand how to determine the data 
type of a variable.
Neither the primitives nor the Quads sparked the answer in my brain. 
It must be something pretty obvious but not to me right now.

So if I have a function FOO X how do I determine if X is character, integer, 
float, or imaginary?
Assuming that it is not a nested array of course.

respect…

Peter

Re: [Bug-apl] Determining data type...

[Peter Teeson]

Thank you kind gentlemen for helping me move forward with modern APL.
Am I correct in assuming that expressions such as {⍬≡0⍴⍵} are lambdas?
And that the symbols theta and omega are place holders similar to X and Y in a 
user defined function?
(all new stuff to me BTW - but very interesting.)

respect

Peter
On 2014-07-31, at 9:51 PM, Elias Mårtenson  wrote:

> This is the table I have included in the Emacs mode documentation. I got the 
> information from the ISO spec, so I hope it's correct:
> 
>   0   (1-R⋆2)⋆0.5
>  ¯1   arcsin R   1   sin R
>  ¯2   arccos R   2   cosin R
>  ¯3   arctan R   3   tan R
>  ¯4   (R+1)×((R-1)÷R+1)⋆0.5  4   (1+R⋆2)⋆0.5
>  ¯5   arcsinh R  5   sinh R
>  ¯6   arccosh R  6   cosh R
>  ¯7   arctanh R  7   tanh R
>  ¯8   -(¯1-R×2)⋆0.5  8   (¯1-R⋆2)⋆0.5
>  ¯9   R  9   Real part of R
> ¯10   +R10   |R
> ¯11   0J1×R 11   Imaginary part of R
> ¯12   ⋆0J1×R12   Arc R
> 
> Regards,
> Elias
> 
> 
> On 1 August 2014 06:46, David B. Lamkins  wrote:
> Reshape your datum as an empty vector then match to zilde. If the match
> succeeds then your datum is a number; otherwise a character/string.
> 
> I believe that there's a circle function to extract the imaginary part
> of a number, if any. You can test for a nonzero imaginary part.
> 
> Finally, you can compare a number's floor to the number itself to
> determine whether the value is integer or real.
> 
> Not knowing your application, I have to warn you that you shouldn't use
> these tests to infer anything about APL's storage. All of the numeric
> tests are subject to quad-CT.
> 
> On Thu, 2014-07-31 at 15:54 -0400, Peter Teeson wrote:
> > I feel pretty stupid.
> > Looked in the APL2 IBM manual but do not understand how to determine the 
> > data type of a variable.
> > Neither the primitives nor the Quads sparked the answer in my brain.
> > It must be something pretty obvious but not to me right now.
> >
> > So if I have a function FOO X how do I determine if X is character, 
> > integer, float, or imaginary?
> > Assuming that it is not a nested array of course.
> >
> > respect…
> >
> > Peter
> >
> 
> 
> 
> 

Re: [Bug-apl] Determining data type...

[Peter Teeson]

Thanks Elias:

David used theta as well. Is that also an available symbol?
i.e. a greek letter not otherwise used by the APL language?

I will have to Google for a good intro to lambdas…
They look interesting...

respect…

Peter
On 2014-07-31, at 10:11 PM, Elias Mårtenson  wrote:

> Yes, you are right. Here are the available symbols:
> 
> ⍵ - Right-hand argument
> ⍺ - Left-hand argument
> ⍹ - Right-hand function (the lambda is an operator)
> ⍶ - Left-hand function (the lambda is an operator)
> χ - Index
> 
> Regards,
> Elias
> 
> 
> On 1 August 2014 10:04, Peter Teeson  wrote:
> Thank you kind gentlemen for helping me move forward with modern APL.
> Am I correct in assuming that expressions such as {⍬≡0⍴⍵} are lambdas?
> And that the symbols theta and omega are place holders similar to X and Y in 
> a user defined function?
> (all new stuff to me BTW - but very interesting.)
> 
> respect
> 
> Peter
> 
> On 2014-07-31, at 9:51 PM, Elias Mårtenson  wrote:
> 
>> This is the table I have included in the Emacs mode documentation. I got the 
>> information from the ISO spec, so I hope it's correct:
>> 
>>   0   (1-R⋆2)⋆0.5
>>  ¯1   arcsin R   1   sin R
>>  ¯2   arccos R   2   cosin R
>>  ¯3   arctan R   3   tan R
>>  ¯4   (R+1)×((R-1)÷R+1)⋆0.5  4   (1+R⋆2)⋆0.5
>>  ¯5   arcsinh R  5   sinh R
>>  ¯6   arccosh R  6   cosh R
>>  ¯7   arctanh R  7   tanh R
>>  ¯8   -(¯1-R×2)⋆0.5  8   (¯1-R⋆2)⋆0.5
>>  ¯9   R  9   Real part of R
>> ¯10   +R10   |R
>> ¯11   0J1×R 11   Imaginary part of R
>> ¯12   ⋆0J1×R12   Arc R
>> 
>> Regards,
>> Elias
>> 
>> 
>> On 1 August 2014 06:46, David B. Lamkins  wrote:
>> Reshape your datum as an empty vector then match to zilde. If the match
>> succeeds then your datum is a number; otherwise a character/string.
>> 
>> I believe that there's a circle function to extract the imaginary part
>> of a number, if any. You can test for a nonzero imaginary part.
>> 
>> Finally, you can compare a number's floor to the number itself to
>> determine whether the value is integer or real.
>> 
>> Not knowing your application, I have to warn you that you shouldn't use
>> these tests to infer anything about APL's storage. All of the numeric
>> tests are subject to quad-CT.
>> 
>> On Thu, 2014-07-31 at 15:54 -0400, Peter Teeson wrote:
>> > I feel pretty stupid.
>> > Looked in the APL2 IBM manual but do not understand how to determine the 
>> > data type of a variable.
>> > Neither the primitives nor the Quads sparked the answer in my brain.
>> > It must be something pretty obvious but not to me right now.
>> >
>> > So if I have a function FOO X how do I determine if X is character, 
>> > integer, float, or imaginary?
>> > Assuming that it is not a nested array of course.
>> >
>> > respect…
>> >
>> > Peter
>> >
>> 
>> 
>> 
>> 
> 
> 

Re: [Bug-apl] Determining data type...

[Peter Teeson]

Thank you Kacper for both your original reply and this clarification.
My eyesight is not what it used to be… we persevere however.

respect…

Peter

On 2014-07-31, at 10:53 PM, Kacper Gutowski  wrote:

> On 2014-07-31 22:49:06, Peter Teeson wrote:
>> David used theta as well. Is that also an available symbol?
>> i.e. a greek letter not otherwise used by the APL language?
> 
> You're probably refering to ⍬.  This is not a theta.  This symbol
> is called zilde and it should look like zero with superimposed
> tilde.  It's not specifically related to lambdas.
> Zilde stands for a numeric vector of zero length (just like '' is
> a character vector).  You can write (0⍴0) instead of ⍬.
> 
> 
> -k

Re: [Bug-apl] GNU APL on a Mac

[Peter Teeson]

Back in March this year I wrote up a small guide which you can find in the doc 
folder. 
It's title is APL-on-Macintosh.pdf Should you run into issues I may be able to 
help.

And of course if you find errors in the pdf or poorly written bits 
please let me know and I will correct it.

respect…

Peter

On 2014-08-01, at 1:18 PM, Blake McBride  wrote:

> Greetings,
> 
> I understand that some have gotten GNU APL working on a Mac.  I've not tried 
> this, and the doc files (such as README-3-keyboard) do not mention it.  It 
> would be great if someone who has GNU APL running on a Mac could provide 
> instructions that could be added to the various README files.
> 
> Same for Windows.
> 
> Thanks.
> 
> Blake
> 

Re: [Bug-apl] GNU APL on a Mac

[Peter Teeson]

Let me know if there are problems.
These days I always use the latest svn update rather than the tar ball release.
Of course that's after the initial svn co.

respect…

Peter
On 2014-08-01, at 2:19 PM, Blake McBride  wrote:
> Dear Peter,
> 
> Wow.  I somehow missed that.  Really great job!  
> 
> Thanks!
> 
> Blake
> 
> 
> 
> On Fri, Aug 1, 2014 at 12:45 PM, Peter Teeson  wrote:
> Back in March this year I wrote up a small guide which you can find in the 
> doc folder.
> It's title is APL-on-Macintosh.pdf Should you run into issues I may be able 
> to help.
> 
> And of course if you find errors in the pdf or poorly written bits
> please let me know and I will correct it.
> 
> respect…
> 
> Peter
> 
> On 2014-08-01, at 1:18 PM, Blake McBride  wrote:
> 
> > Greetings,
> >
> > I understand that some have gotten GNU APL working on a Mac.  I've not 
> > tried this, and the doc files (such as README-3-keyboard) do not mention 
> > it.  It would be great if someone who has GNU APL running on a Mac could 
> > provide instructions that could be added to the various README files.
> >
> > Same for Windows.
> >
> > Thanks.
> >
> > Blake
> >
> 
> 

[Bug-apl] build warning on OSX

[Peter Teeson]

I did a brand new SVN co and then did ./configure and got this warning

file://localhost/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl:
 warning: Missing file: 
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl is 
missing from working copy.


Peter

Re: [Bug-apl] build warning on OSX

[Peter Teeson]

First I deleted the previous folder (directory) and then did a brand new svn co 
of the trunk followed by the usual ./configure and make.

There is a script.apl file in /workspaces but not a SCRIPT.apl one.
Even my backup does not have one.

Other than documentation it appears in the /workspaces Makefile and Makefile.am

I'm confused….

Peter

On 2014-08-05, at 6:41 AM, Juergen Sauermann  
wrote:

> Hi Peter,
> 
> I guess you accidentally deleted the file or did the 'svn update' from the 
> src subdir?
> 
> /// Jürgen
> 
> 
> On 08/04/2014 09:51 PM, Peter Teeson wrote:
>> I did a brand new SVN co and then did ./configure and got this warning
>> 
>> file://localhost/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl:
>>  warning: Missing file: 
>> /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl is 
>> missing from working copy.
>> 
>> 
>> Peter
>> 
>> 
> 

Re: [Bug-apl] Creating a new release

[Peter Teeson]

Checked out , built and tested on both OS X 10.8.5 and 10.9.4 with no errors or 
warnings (except that I do not have Postgres on 10.9.4).

On 2014-08-05, at 3:16 PM, David Lamkins  wrote:

> Tested on one of my Fedora 20 systems, both by an update to my existing work 
> dir and a fresh SVN checkout. The build and install finished properly in both 
> cases. No surprises. :)
> 
> -- 
> "The secret to creativity is knowing how to hide your sources."
>Albert Einstein
> 
> 
> http://soundcloud.com/davidlamkins
> http://reverbnation.com/lamkins
> http://reverbnation.com/lcw
> http://lamkins-guitar.com/
> http://lamkins.net/
> http://successful-lisp.com/

Re: [Bug-apl] GNU APL 1.4 released

[Peter Teeson]

Great job Jürgen..and Elias, Blake, and David.

respect…

Peter

On 2014-08-07, at 1:57 PM, Juergen Sauermann  
wrote:

> Hello,
> 
> I am happy to announce that  GNU APL 1.4 has been released.
> 
> This release contains:
> 
> * an interface to mySQL and Postgres databases (thanks to Elias)
> 
> * two component file systems as demanded by ISO 13751 (thanks to Blake and 
> David)
> 
> * a centralized server for shared variables (APserver)
> 
> All bugs reported before 8/6/2014 were fixed.
> 
> 
> The GNU APL project lives at: http://www.gnu.org/software/apl
> and can be downloaded from: ftp://ftp.gnu.org/gnu/apl/ or any GNU mirror.
> 
> Bug reports and other suggestions are welcome at bug-apl@gnu.org.
> 
> Have fun!
> 
> Dr. Jürgen Sauermann
> Author and Maintainer of GNU APL
> 

[Bug-apl] APL fill elements

[Peter Teeson]

Is there a nice way to set the fill element for arrays?
Right now it's 0 for numeric and ' ' for character.

Because my function, that is deliberately ⎕IO agnostic, produces an m by n 
array of different length vectors as a result of using X←(⊂matrix)foo¨matrix. 
These vectors are certain indices into the original matrix This is precisely 
what I want.

However in ⊃X each vector is filled with 0 - which, when ⎕IO is also 0, is also 
a legitimate index. And I don't want that. 

I suppose I could set ⎕IO locally but it doesn't appeal to my sense of elegance 
- although it would be practical! Sigh!

So it would be nice to allow me to set the fill element to something other than 
the default values.

Comments?

respect….

Peter

Re: [Bug-apl] APL fill elements

[Peter Teeson]

Yes thanks I understand. 
My Foo function used out of bounds fill elements internally to be able to 
manipulate rectangular arrays of generated indices which are of course ⎕IO 
dependant.
The return result of Foo had removed them. I will not do so and my problem will 
disappear. 
thanks again and respect…

Peter

On 2014-08-10, at 8:28 AM, Juergen Sauermann  
wrote:

> Hi Peter,
> 
> no there isn't. Fill items and Fill functions occur all over the place in 
> APL2.
> And they are function specific so that ↑ has other fill items (' ' and 0) than
> + (0) and × (1). On the other hand fill items are not at all related ⎕IO.
> 
> You can easily achieve what you are after like this:
> 
>   A←4 5
>   B←3 2⍴42
>   Z←A↑B
>   Z
> 42 42 0 0 0
> 42 42 0 0 0
> 42 42 0 0 0
>  0  0 0 0 0
>   Z + ∼A↑(⍴B)⍴1
> 42 42 1 1 1
> 42 42 1 1 1
> 42 42 1 1 1
>  1  1 1 1 1
> 
> /// Jürgen
> 
> 
> On 08/09/2014 08:15 PM, Peter Teeson wrote:
>> Is there a nice way to set the fill element for arrays?
>> Right now it's 0 for numeric and ' ' for character.
>> 
>> Because my function, that is deliberately ⎕IO agnostic, produces an m by n 
>> array of different length vectors as a result of using 
>> X←(⊂matrix)foo¨matrix. These vectors are certain indices into the original 
>> matrix This is precisely what I want.
>> 
>> However in ⊃X each vector is filled with 0 - which, when ⎕IO is also 0, is 
>> also a legitimate index. And I don't want that. 
>> 
>> I suppose I could set ⎕IO locally but it doesn't appeal to my sense of 
>> elegance - although it would be practical! Sigh!
>> 
>> So it would be nice to allow me to set the fill element to something other 
>> than the default values.
>> 
>> Comments?
>> 
>> respect….
>> 
>> Peter
>> 
>> 
>> 
> 

[Bug-apl] A word of warning…re posted DyalogAlt.keylayout for Mac OS X

[Peter Teeson]

The currently posted layout dated 2011-04-13 at 16:09 (GMT +1:00) (edited by 
Ukelele version 2.1.5) 
has does not have the glyphs that were in a later version (which was the one 
previously posted)
dated 2011-09-29 at 14:26 (GMT +1:00) (edited by Ukelele version 2.1.7) 

The missing glyphs are in the Shift+Alt plane and are things like:
⍷⍨⍸⍥⍣⍤⍞⍬≡≢⍙⍠⍪

So I would be careful not to download the currently linked one - or at least 
not install it.

respect…

Peter

[Bug-apl] OS X DyalogAlt.keylayout mappings to add...

[Peter Teeson]

Hi Blake:
In your email of 5 Aug your mentioned the following missing mappings in the 
apl.xmodmap.
> χ ⍹ ⍶ ⍷ ⍨ ¥ ⍸ ⍣ ⌷ ⍥ ¢ £ ⍙

The DyalogAlt.keylayout for OS X dated 2011-09-29 at 14:26 (GMT +1:00) (edited 
by Ukelele version 2.1.7) 
contains the following in the Shift + Alt plane

> ⍷ ⍨  ⍸ ⍣ ⌷ ⍥  £ ⍙
Because Dyalog is a UK based company they are using a UK keyboard which is why 
£ is available as Shift 3.

Using the below tool I propose adding χ ⍹ ⍶ to the Shift + Alt plane using the 
x,w,a keys which are available.
As for  ¥ and ¢ keys in the Shift + Alt plane they are also available so I 
propose to also map to those.

Do you or anyone else know what the Unicode for χ is?  Any objections or other 
suggestions anyone?

Thanks…

Peter

From this website: 


> Ukelele is a Unicode Keyboard Layout Editor for Mac OS X versions 10.2 and 
> later.
> Version 2.0 and later are only for Mac OS X versions 10.4 and later.
> Beginning with version 10.2 (Jaguar), Mac OS X supports an XML-based format 
> for keyboard layouts (.keylayout files).
> 
> These may be installed by copying them to the Keyboard Layouts folder within 
> /Library or ~/Library; then they are enabled via the Input Sources (Input in 
> 10.5 and earlier) tab of the Language & Text (International in 10.5 and 
> earlier) module within System Preferences.
> 

[Bug-apl] OS X link to DyalogAlt.keylayout is to older version than previously

[Peter Teeson]

Greetings:
I like your new web site and that we can now download the OS X 
DyalogAlt.keylayout from the site. Well done.

However the file that you have linked to is earlier than your previous one.
The currently posted layout dated 2011-04-13 at 16:09 (GMT +1:00) (edited by 
Ukelele version 2.1.5) 
and does not have the glyphs that were in a later version (which was the one 
previously posted)
dated 2011-09-29 at 14:26 (GMT +1:00) (edited by Ukelele version 2.1.7) 

The missing glyphs are in the Shift+Alt plane and are things like:
⍷⍨⍸⍥⍣⍤⍞⍬≡≢⍙⍠⍪

These are pretty important in modern APL as I'm sure you know.
Please correct this and restore the later dated file.

Thanks & respect

Peter Teeson

Re: [Bug-apl] OS X DyalogAlt.keylayout mappings to add...

[Peter Teeson]

Thanks Blake - added that one. 
When you say keyboard definitions I interpret that to mean for use with xkbcomp.
Since it is not part of a standard OS X install and requires running X I 
decided to go with Apple's use of XML.
Furthermore that's what Dyalog has done.
Also Readme-3 in the keyboard section states that GNU APL's standard layout is 
Dyalog so that's what I'm working with.
I've already "enhanced" the DyalogAlt.keylayout and just am waiting to see if 
there are any comments on the proposed mapping.

BTW did you do an install using my little  guide?

respect…

Peter

On 2014-08-11, at 6:11 PM, Blake McBride  wrote:

> Dear Peter,
> 
>  χ is U03C7
> 
> The keyboard definitions I supplied included all of the characters used by 
> GNU APL.
> 
> Thanks.
> 
> Blake

Re: [Bug-apl] OS X DyalogAlt.keylayout mappings to add...

[Peter Teeson]

Hmmm interesting… I don't think that would be too hard to do. 
Thanks for the idea. I'll check it out tomorrow.

Peter



On 2014-08-11, at 9:37 PM, Blake McBride  wrote:

> Dear Peter,
> 
> I think the GNU APL layout differs a little from the Dyalog layout.  It would 
> be nice for your Mac setup to match the output of the GNU APL ]ketb command.  
> That is what I did with my layout files.
> 
> I used the Mac primarily for several years.  I had a problem with my 
> motherboard.  While they were fixing it, I switched to LinuxMint as my 
> primary platform and haven't gone back.  (I had many years of Unix & Linux 
> experience.  I just didn't use it as my primary development platform until 
> the last year or so.)  I like the idea of having the software portable so 
> that I can switch and share at will.  Your Mac layout is appealing for that 
> reason.  I'd like to get one of my Mac's up with GNU APL, but I haven't done 
> it yet.
> 
> Thanks for your work on the Mac files!!
> 
> Blake
> 
> 
> On Mon, Aug 11, 2014 at 7:34 PM, Peter Teeson  wrote:
> Thanks Blake - added that one. 
> When you say keyboard definitions I interpret that to mean for use with 
> xkbcomp.
> Since it is not part of a standard OS X install and requires running X I 
> decided to go with Apple's use of XML.
> Furthermore that's what Dyalog has done.
> Also Readme-3 in the keyboard section states that GNU APL's standard layout 
> is Dyalog so that's what I'm working with.
> I've already "enhanced" the DyalogAlt.keylayout and just am waiting to see if 
> there are any comments on the proposed mapping.
> 
> BTW did you do an install using my little  guide?
> 
> respect…
> 
> Peter
> 
> On 2014-08-11, at 6:11 PM, Blake McBride  wrote:
> 
>> Dear Peter,
>> 
>>  χ is U03C7
>> 
>> The keyboard definitions I supplied included all of the characters used by 
>> GNU APL.
>> 
>> Thanks.
>> 
>> Blake
> 
> 

Re: [Bug-apl] OS X DyalogAlt.keylayout mappings to add...

[Peter Teeson]

The ]keyb command shows the "canonical" key layout for GNU APL.
It is/was based on the Dyalog layout. But there are a few differences and 
omissions in the current DyalogAlt.keylayout for Mac.

Starting with the actual Dyalog layout I have added the mappings to the Unicode 
glyphs mentioned in Blake's email i.e.
> χ ⍹ ⍶ ⍷ ⍨ ¥ ⍸ ⍣ ⌷ ⍥ ¢ £ ⍙
Then I compared that layout to the ]keyb one and there are indeed some minor 
differences
These have now also been corrected. 

So I now have available a GnuAplMacAlt.keylayout that is, with one exception, 
the same as ]keyb.
The exception is this: ⍙ appears twice in ]keyb at AltShift H and AltShift 
period.

Presently I have left the AltShift period one there and not yet added the 
AltShift H.

What is the correct next step to finalize things?

Plus can we come up with a better name for the layout than  GnuAplMacAlt?

respect…

Peter

On 2014-08-11, at 10:06 PM, Peter Teeson  wrote:
> Hmmm interesting… I don't think that would be too hard to do. 
> Thanks for the idea. I'll check it out tomorrow.
> Peter
> On 2014-08-11, at 9:37 PM, Blake McBride  wrote:
>> Dear Peter,
>> I think the GNU APL layout differs a little from the Dyalog layout.  
>> It would be nice for your Mac setup to match the output of the GNU APL ]keyb 
>> command.  
>> That is what I did with my layout files.

[Bug-apl] MacAplAlt.keylayout & updated Installation Guide

[Peter Teeson]

I have a Mac keyboard layout available as well as an updated Installation Guide.
May I suggest that a new folder be created in /support-files named OS 
X-keyboard?

The Guide provides manual instructions on how to install it - a simple drag and 
drop to either /Library/Keyboard Layouts 
or preferably ~/Library/Keyboard Layouts.

I suppose it could be done automatically with make files but I have no 
expertise in this area.

The only thing I question is the duplication of the ⍙ glyph in Alt+Shift+h and 
Alt+Shit+b.
This is to follow what ]keyb displays. But I am curious why it is duplicated.
IMO the Alt+Shit+h is the proper place since Alt+h is ∆.

If you agree and want the Alt+Shift+b glyph removed I will do so on the Mac 
layout.

Then I can forward these two items to you for inclusion or update to 1.4 at the 
next minor revision.

respect….

Peter

Re: [Bug-apl] MacAplAlt.keylayout & updated Installation Guide

[Peter Teeson]

Hi Jürgen:
Thanks very much.
In the MacAplAlt.keyboard I placed a Comment making it GPL'd (same as the 
install guide). That way it's not proprietary.
IMPO I believe we should place ⍙ at Shift+Alt+h (since Alt+h is where ∆ js 
placed) and that's what I've done for MacAplAlt.

Also unless there is a strong objection, for MacAplAlt I will remove the Dyalog 
Shift+Alt+.

I will submit the keylayout and revised pdf later this week after waiting to 
allow comments in the next day or two.

respect…

Peter
On 2014-08-18, at 12:32 PM, Juergen Sauermann  
wrote:

> Hi Peter,
> 
> I will be happy to create a Mac folder and include your files there.
> 
> The reason for ⍙ sitting on two keys is that I was so used to ⍙ on Shift-∆ 
> that
> I left it there (see also the folder called "old-Keyboard" which was my 
> initial
> keyboard layout (and how I believed it makes the most sense).
> 
> Then I purchased a Dyalog keyboard and found a number of characters in 
> different places.
> 
> Since my layout was kind of proprietary, I then changed to the Dyalog 
> keyboard but left the ⍙ where it was
> (and my fingers still find it there).
> 
> /// Jürgen

[Bug-apl] 8 Warnings latest SVN

[Peter Teeson]

8 Warnings latest SVN
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Output.cc:255:19: 
Unsequenced modification and access to 'errors'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Output.cc:256:19: 
Unsequenced modification and access to 'errors'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Output.cc:257:19: 
Unsequenced modification and access to 'errors'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Output.cc:258:19: 
Unsequenced modification and access to 'errors'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Output.cc:259:19: 
Unsequenced modification and access to 'errors'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Output.cc:260:19: 
Unsequenced modification and access to 'errors'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Output.cc:261:19: 
Unsequenced modification and access to 'errors'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Output.cc:262:19: 
Unsequenced modification and access to 'errors'

[Bug-apl] What is the correct key code for diamond?

[Peter Teeson]

The subject says it all.

I have a glyph setup for my MacAplAlt but it must be the wrong key code.
Because if I use it I get Offending token…..SYNTAX ERROR.

So what is the correct one to use please?

Thanks….

Peter

Re: [Bug-apl] What is the correct key code for diamond?

[Peter Teeson]

Great thanks that fixed it.
On 2014-09-13, at 6:58 PM, David B. Lamkins  wrote:

> U+25CA (from src/Avec.def)

Re: [Bug-apl] What is the correct key code for diamond?

[Peter Teeson]

Hi Jürgen:
I had made a mistake, not recognizing that Avec was the atomic vector and 
looking up lozenge in there.
Instead I went to the OS X character viewer and did a find on Diamond. 
It showed me the White Diamond Suit U+2662 UTF-8 E2 99 A2. Of course this won't 
work.

Everything is fine now that I have corrected my MacAplAlt.keyboard to use 
U+25CA.

Thanks…

Peter
On 2014-09-14, at 5:11 AM, Juergen Sauermann  
wrote:

> Hi Peter,
> 
> there are some characters that have different unicodes in different APL 
> interpreters.
> 
> Normally GNU APL accepts all of them on input (as far as they are known).
> 
> Currently U+25CA (the default diamond) but also U+22C4 (a somewhat smaller 
> diamond)
> should be accepted. If not (because diamond is handled somewhat special in 
> some cases) then please
> let me know with as example.
> 
> It could also be that there is another diamond around. If that is the case 
> then please let me know
> its unicode and I will add it to the table of alternative characters in 
> Avec::map_alternative_char().
> 
> /// Jürgen
> 
> 
> On 09/14/2014 04:57 AM, Peter Teeson wrote:
>> Great thanks that fixed it.
>> On 2014-09-13, at 6:58 PM, David B. Lamkins  wrote:
>> 
>>> U+25CA (from src/Avec.def)
>> 
>> 
> 

[Bug-apl] Why do I hit this SYSTEM LIMIT?

[Peter Teeson]

  c←⍳9
 d←'c',('n',⊃⍕¨c),'←'),'⍳'),'0'),'  '),'◊'
SYSTEM LIMIT (prefix length)
  d←'c',('n',⊃⍕¨c),'←'),'⍳'),'0'),'  '),'◊'
  ^   ^
 but this is OK? 
d←((('c',('n',⊃⍕¨c),'←'),'⍳'),'0'),'  '

I don't see prefix length in ⎕SYL.

I don't understand. Sorry but my coffee must not be working….

Peter

[Bug-apl] errors in latest SVN

[Peter Teeson]

/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Parallel.cc:181:1: 
Unknown type name 'cpu_set_t'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Parallel.cc:197:55: Use 
of undeclared identifier 'cpu_set_t'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Parallel.cc:323:1: 
Unknown type name 'cpu_set_t'

Re: [Bug-apl] Another OSX compile error

[Peter Teeson]

/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:125:6: 
Variable length array of non-POD element type 'PrintBuffer'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:188:6: 
Variable length array of non-POD element type 'PrintBuffer'

[Bug-apl] Macintosh compile errors and warnings SVN 581

[Peter Teeson]

Hi Jürgen:
Congratulation on the 1.5 release….
So to keep you busy here are some issues on Mac OS X 10.8.5 

respect….

Peter

Shell Script Invocation Error Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh::257257::2626:0:
 Non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:278:26: 
./../Workspace.hh:278error: non-ASCII characters are not allowed outside of 
literals and identifiers:26
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:279:0: 
26error::  non-ASCII characters are not allowed outside of literals and 
identifierserror
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:257:26: 
Non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:258:26: 
Non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src:26: Non-ASCII 
characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:278:26: 
Non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:279:26:
rw_sv_def(Quad_Quad,  ⎕)non-ASCII characters are not allowed outside of 
literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:279:26: 
Non-ASCII characters are not allowed outside of literals and identifiers

Shell Script Invocation Warning Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/file_io.cc:1273:25: 
Comparison of unsigned expression < 0 is always false

Re: [Bug-apl] Macintosh compile errors and warnings SVN 582

[Peter Teeson]

Hi Jürgen:
Almost fixed… but some new errors & warnings…:-}

Peter

On 2015-03-31, at 10:10 AM, Juergen Sauermann  
wrote:
> Hi Peter,
> 
> thanks, should be fixed in SVN 582.
> 
> /// Jürgen

SVN 582
GNUAPL Group
Shell Script Invocation Error Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:128:9: 
Variable length array of non-POD element type 'PrintBuffer'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:131:14: 
Variable length array of non-POD element type 'PrintBuffer'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:149:14: 
Variable length array of non-POD element type 'PrintBuffer'

Shell Script Invocation Warning Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/QuadFunction.cc:1974:43:
 If statement has empty body
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/QuadFunction.cc:1975:43:
 If statement has empty body

Re: [Bug-apl] Macintosh compile errors and warnings SVN 583

[Peter Teeson]

GNUAPL Group
Shell Script Invocation Error Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/TempFileWrapper.cc:45:5:
 No matching function for call to 'strcpy'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/TempFileWrapper.cc:47:10:
 No matching function for call to 'mkstemp'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/TempFileWrapper.cc:52:10:
 No viable overloaded '='

On 2015-03-31, at 11:22 AM, Juergen Sauermann  
wrote:
> Hi Peter and Fausto,
> 
> thanks. I have tried to catch this in ./configure. SVN 583.
> 
> /// Jürgen