Hi Chris,
thanks, fixed in SVN 1055.
/// Jürgen
On 07/02/2018 09:21 PM, Chris Moller
wrote:
I got that non-working version of
apl-1.7.tar.gz from ftp.gnu.org/pub/gnu/apl,
dated 17 March 2017, so I
I got that non-working version of apl-1.7.tar.gz from
ftp.gnu.org/pub/gnu/apl, dated 17 March 2017, so I guess it's a bit
out-of-date.
I just now got a chance to pull down the savannah svn version, which
./configures fine, but there a few compile errors with g++ (GCC) 8.1.1
20180502 (Red Hat
Hi Chris,
the svn E155007 happens if you unpack a GNU APL tar file
(as opposed to
checking out GNU APL from SVN, which is the proposed method). See
https://savannah.gnu.org/svn/?group=apl.
The other error was fixed already in SVN version 1052
I tried building apl-1.7.tar.gz, but running ./configure gave me:
svn: E155007: '/home/moller/Downloads/apl-1.7/src/Archive.cc' is not
a working copy
and then build gives me:
g++ -DHAVE_CONFIG_H -I. -I.. -Werror -Wall -I sql -rdynamic -g -O2
-MT apl-Avec.o -MD -MP -MF .deps/apl-Ave
Hi Chris,
even after a close look at the GNU APL code I can't see anything
wrong with how realpath() is being called.
To me it looks more like a bug in glibc 2.3, although the valgrind
message suggests that this bug causes no harm
(a memory are
Doing some other stuff involving libapl.so, I was running valgrind
against my own code when this popped up:
==14122== Source and destination overlap in mempcpy(0x778a9e1, 0x778a9e1, 4)
==14122== at 0x4C34FF0: mempcpy (vg_replace_strmem.c:1524)
==14122== by 0x7E06634: realpath@@GLIBC_2.3 (
Hi Juergen,
I know the file was successfully opened, because I print the argument that
is going to be passed to do the read, 2 0 16, and it has successfully
fetched the file size.
The value error is strange, because it branches to the dyadic case only
after using NC to check existence of the left
Hi Mike,
thanks for reporting this. I believe I have fixed the segfault, SVN
655.
It should have occured only if you open a non-existing file and
then try to read from it.
I believe in your function RDFILE you should check NILL in [3] to
∇RDFILE[⎕]∇
∇
[0] Z←RDFILE X;NILL
[1] NILL←210 SVOPAIR 'C5' 'D5'
[2] C5←'IR,',PATH,X,',D'
[3] NILL←C5
[4] C5←⎕←2 0,D5
[5] NILL←C5
[6] Z←D5
[7] C5←⍳0
[8] NILL←⎕SVR 2 2⍴'C5D5'
∇
[In APL2]
RDFILE 'test'
2 0 16
This is a test.
[In GNU APL]
RDFILE 'test'
2
Hi Jay,
thanks, fixed in SVN 262.
/// Jürgen
On 05/12/2014 06:26 PM, Juergen Sauermann wrote:
Hi,
looks like a bug, I will look into it.
/// Jürgen
On 05/12/2014 05:28 PM, Jay Foad wrote:
⍬≡⊃⊂⍬
0
That looks like a bug in GNU APL. It's true in IBM APL2 and Dyalog APL.
Jay.
Hi,
looks like a bug, I will look into it.
/// Jürgen
On 05/12/2014 07:35 PM, David B. Lamkins wrote:
I'm forwarding this post to the list under a new topic so it doesn't get
buried in the other discussion:
I'm forwarding this post to the list under a new topic so it doesn't get
buried in the other discussion:
--- Begin Message ---
> ⍬≡⊃⊂⍬
> 0
That looks like a bug in GNU APL. It's true in IBM APL2 and Dyalog APL.
Jay.
--- End Message ---
Hi Elias,
thanks, fixed in SVN 197.
/// Jürgen
On 04/10/2014 06:23 AM, Elias Mårtenson wrote:
In get_CDR_type(), the variable has_bool is set, but never used.
Should there be a type value for it? Otherwise, should the variable be
removed altogether?
Regards,
Elias
In get_CDR_type(), the variable has_bool is set, but never used. Should
there be a type value for it? Otherwise, should the variable be removed
altogether?
Regards,
Elias
Hi Elias,
it was intended as written, I have added the extra () for clarification
in SVN 180.
/// Jürgen
On 03/28/2014 09:33 AM, Elias Mårtenson wrote:
The file Parser.cc, line 476, looks like this:
const int funtag = tos[src].get_tag() & ~TC_MASK | TC_FUN12;
Because & binds stronger
The file Parser.cc, line 476, looks like this:
const int funtag = tos[src].get_tag() & ~TC_MASK | TC_FUN12;
Because & binds stronger than |, the compiler parses this as:
const int funtag = (tos[src].get_tag() & ~TC_MASK) | TC_FUN12;
I believe this is incorrect, and the intention is this inste
16 matches
Mail list logo
