Re: [Bug-apl] AP100 problem

[Juergen Sauermann]

Hi Frederick,

First of all, I believe the aclocal problem could be fixed with running autoreconf before ./configure in
the same directory.

Regarding the SVN version, i am currently fairly confused. I am working with two SVN repositories: a local
one into which I commit even small changes (so that I revert changes easily) and a remote one at GNU/savannah
into which I commit only versions that have been tested and are are (supposedly) working. The savannah repo is
currently at SVN 885 while my local one is at SVN 12560.

My local repository shows the latest change of AP100.cc as:

address@hidden:~/projects/juergen/apl-1.6/src/APs$ svn diff -r12013 AP100.cc
Index: AP100.cc
===================================================================
--- AP100.cc    (revision 12013)
+++ AP100.cc    (working copy)
@@ -100,7 +100,8 @@
               return;
             }
 
-         cmd = string((const char *)&cdr[20], cdr.size() - 20).c_str();
+         cmd = string((const char *)cdr.get_items() + 20,
+                      cdr.size() - 20).c_str();
 
          if (verbose)   get_CERR() << pref << " got command " << cmd << endl;
 
@@ -170,7 +171,7 @@
 {
    if (var.data == 0)   return E_VALUE_ERROR;
 
-   data = "" char *)&var.data[0], var.data->size());
+   data = "" char *)(var.data->get_items()), var.data->size());
    error_loc = "no_error";   return E_NO_ERROR;
 }
 //-----------------------------------------------------------------------------
address@hidden:~/projects/juergen/apl-1.6/src/APs$

That change was entered into the local repository on Thu, 08 Dec 2016, The reason for the change was an earlier
 change in CDR.hh which crewated a compile-error in AP100.cc.

In theory, the change made in AP100.cc should have been included in the next commit into the savannah
repository. But the savannah repo does not show anything after 2014:

address@hidden:~/projects/juergen/savannah-repo-apl/trunk/src/APs$ svnversion
885
address@hidden:~/projects/juergen/savannah-repo-apl/trunk/src/APs$ svn log AP100.cc
------------------------------------------------------------------------
r370 | j_sauermann | 2014-07-14 12:32:54 +0200 (Mon, 14 Jul 2014) | 1 line

fixed ∇ on non-empty line, more functions moved to APserver
------------------------------------------------------------------------
r91 | j_sauermann | 2014-01-13 17:23:10 +0100 (Mon, 13 Jan 2014) | 1 line

finalized 10⎕CR and fixed recent bugs
...

However, the latest version in savannah contains the last change in AP100.cc. That suggests that the SVN log
is wrong, but the savannah SVN is up-to-date. To double-check that, please check that line 103 of AP100.cc
reads:

         cmd = string((const char *)cdr.get_items() + 20,
                      cdr.size() - 20).c_str();

and not:

         cmd = string((const char *)&cdr[20], cdr.size() - 20).c_str();

BTW line 103 is just before the wrong command is being printed.

Another possible problem is that some .cc files may not have picked up changes in .hh files.
The "normal" ./configure configures for a "fast" build which does not build dependency files. That build
performs fewer compilations (and is therefore faster). But the price is that updates of header files (via SVN)
may not be recognized (make itself compares only .cc files). So if your APs/AP100 binary is older than,
say, 2 month, then this problem has most likely occurred.

Unfortunately the changes that has made the change in AP100.cc necessary were mostly happening in
header files.

If you do make develop then the ./configure is done differently an dependencies will be detected properly.
After doing  make develop once, updates from SVN are usually safe (until the next ./configure which may
override the proper settings).

In any case 'make clean; sudo make install' is always a good idea to rule out problems caused by
missing dependencies.

At this point, I believe it is clear that the commands sent from APL to the AP100 processor are being corrupted,
but the reason why is not yet clear. The date where the changes occurred was somewhere around Dec 8, 2016.

Best Regards,
Jürgen Sauermann

On 02/15/2017 02:26 AM, Frederick Pitts wrote:

Hello Juergen,

I haven't been configuring apl with DYNAMIC_LOG=yes, so I attempted 'make develop'. That got me a 'aclocal-1.14 not found' error. Fedora 25 comes with aclocal-1.15. So I punted and downloaded gnu-apl again, followed by configure/make/make install with DYNAMIC_LOG=yes in the environment.

Attached 'foobar.apl.out.1' was generated with ./foobar.apl >& foobar.apl.out.1.

Attached 'foobar.apl.out.2' was generated by starting the apl interpreter, keying in the apl statements from 'foobar.apl' and saving the transcript to 'foobar.apl.out.2'

In both cases, the third send to ap100 fail, but with different unprintable characters in the 'got command' diagnostic capture.

Can you provide me with the SVN version number or number range where the wholesale file changes occurred?

I will test versions just before and after the change. If there is no difference before and after the big change, I will go into binary search mode starting from the last known working version up until now.

Regards,

Fred

On Tue, 2017-02-14 at 21:20 +0100, Juergen Sauermann wrote:

Hi Frederick,

I did as proposed and it seems to work on my machine:

eaddress@hidden:~$ Sound/foobar.apl

1

ls Sound/*
Sound/foobar.apl
Sound/playsnd
0
ls Sound/p*
Sound/playsnd
0
ls Sound/pl*
Sound/playsnd
0
ls Sound/pla*
Sound/playsnd
0

The following in interesting. Your script complains about:

sh: -c: line 0: unexpected EOF while looking for matching ``'
sh: -c: line 1: syntax error: unexpected end of file
1

But there is no backquote ( ` ) anywhere in your script or in the AP100 code. And the script (which ?) seems to
have only 2 lines.

To nail this down a little, please try the following:

- enable dynamic logging (via ./configure). You may have that already, if not do a

make develop
sudo make install

in the top-level GNU APL directory. Then enable logging facility 35 in APL:

      ]LOG 35

This will tell us how the externam programs are called by AP100. Fr example:

      ]LOG 35
    Log facility 'Shared Variable operations          ' is now ON

      100 ⎕SVO 'OS' ⋄ 0 ⍴ ⎕DL 1
Using TCP socket towards APserver...
connected to APserver, socket is 7

apl100 got MAKE_OFFER
1

      OS ← ⎕ ← 'ls Sound/pla*'
ls Sound/pla*
apl100 got ASSIGN_VALUE
AP100(6465)  got command ls Sound/pla*
ls: cannot access Sound/pla*: No such file or directory
AP100(6465)  finished command with exit code 512

In the above example the file did not exist, but we can see in the third last like which command
was given to AP100.

Please try ]log 35 both in your script and by entering the lines in the script interactively (to see if the
problem is caused by scripting or something else). I haven't changed the AP stuff in the last years, but there
were some changes recently that affected many files at the same time. It would be good if you could figure
when (in terms of SVN versions or calendar dates) things started to fail.

Thanks,
Jürgen Sauermann

On 02/14/2017 02:29 AM, Frederick Pitts wrote:

Gentle people,

	I am having trouble using the AP100 processor.  Code that
worked reliably two to three years ago, no longer works.

	The problem can be replicated (I hope) as follows:

	1) Create a folder named 'Sound'.
	2) Touch a file in 'Sound' named 'playsnd'
	3) Copy the attached 'foobar.apl' into the folder containing
'Sound' and run ./foobar.apl after making sure it has execute
permission.

	The content of foobar.apl is:

#!/usr/local/bin/apl --script

100 ⎕SVO 'OS' ⋄ 0 ⍴ ⎕DL 1
OS ← ⎕ ← 'ls Sound/*'
OS
OS ← ⎕ ← 'ls Sound/p*'
OS
OS ← ⎕ ← 'ls Sound/pl*'
OS
OS ← ⎕ ← 'ls Sound/pla*'
OS

)OFF

	The output for the above, contained in attached
'foobar.apl.out', is:


1

ls Sound/*
Sound/playsnd
0
ls Sound/p*
Sound/playsnd
0
ls Sound/pl*
Sound/playsnd
0
ls Sound/pla*
sh: -c: line 0: unexpected EOF while looking for matching ``'
sh: -c: line 1: syntax error: unexpected end of file
1

	Why is the last invocation of the AP100 processor failing?  The
error messages reported by 'sh' indicate shell in-line substitution and
end-of-file processing problems.  BTW, I'm running on Fedora 25 where
'sh' is actually a symbolic link to 'bash'.  And the actual application
involves using the AP100 processor to invoke sound apps from an APL
game.

Regards,

Fred