Hi again,
please disregard my posting below, the mail from Kacper has shown
me a way to reproduce the fault.
/// Jürgen
On 02/15/2017 02:51 PM, Juergen
Sauermann wrote:
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
|