Re: seg-fault with deeply nested assignment

[Dr . Jürgen Sauermann]

  
  
Hi,
  
  actually it assigns a new value (6 7 in the example) to a part
  of x.
  Even though ⊃⊃x is
  a temporarym
  the assignment changes the original x.
  
  I suppose IBM APL2 does the same.
  
  BR, Jürgen
   

On 4/7/20 1:28 AM, Blake McBride wrote:


  
  
Without assigning it to a variable, I don't see
  what sense the statement even makes.
  
  
   (⊃⊃x)
  
  
  
  produces an intermediate value.  I can't think of what
sense making an assignment to an intermediate value even
does.
  
  
  I think APL should just throw a syntax error as in:
  
  
        (+/10 10⍴⍳100)[2]←4
SYNTAX ERROR
      (+/10 10⍴⍳100)[2]←4
      ^                ^
  
  
  
  (Surely a syntax error is more appropriate than a
segfault!)
  
  
  What does IBM APL do?
  
  
  --blake
  
  



  On Sat, Apr 4, 2020 at 5:03
PM Rowan Cannaday  wrote:
  
  

  

  hello y'all, hope everyone is staying safe.

      x ← 1 (2 3 (4 5))         
      (⊃⊃x)[2;3;] ← 6 7


===
SEGMENTATION FAULT


-- Stack trace at main.cc:88

0x7F032D7BABBB __libc_start_main
0x557F8B045425  main
0x557F8B1BE755  
Workspace::immediate_execution(bool)
0x557F8B099A4B    Command::process_line()
0x557F8B09A45A    
Command::do_APL_expression(UCS_string&)
0x557F8B099AE8      Command::finish_context()
0x557F8B0A3698       Executable::execute_body()
const
0x557F8B159D4C        StateIndicator::run()
0x557F8B0DB23D         Prefix::reduce_statements()
0x557F8B0DA17D          Prefix::reduce_MISC_F_B_()
0x557F8B0F1F4F          
Bif_F12_PICK::eval_B(Value_P)
0x557F8B0EBB33          
 Bif_F12_PICK::disclose(Value_P, bool)
0x557F8B0EB86A            
Bif_F12_PICK::compute_item_shape(Value_P, bool)
0x7F032DCD1520              
0x557F8B04C4AB               



  
  By the way, it works if you use an intermediary
  variable:
  
    y←⊃⊃x
        y[2;3;]
  4 5
        y[2;3;] ← 5 6
        y
  1 0
  0 0
  0 0
  
  2 0
  3 0
  5 6
  

Cheers,
  
   - Rowan

  

  


  

Re: seg-fault with deeply nested assignment

[Blake McBride]

Thanks.  I saw that after I sent the email.  When I used APL, there was no
APL2.  So, I've never used APL2 professionally.

I also see that the latest repo version has a fix for the original report.

Thanks!

Blake


On Tue, Apr 7, 2020 at 4:37 AM Dr. Jürgen Sauermann <
mail@jürgen-sauermann.de> wrote:

> Hi,
>
> actually it assigns a new value (*6 7* in the example) to a part of *x*.
> Even though *⊃⊃x *is a temporarym
> the assignment changes the original *x*.
>
> I suppose IBM APL2 does the same.
>
> BR, Jürgen
>
>
> On 4/7/20 1:28 AM, Blake McBride wrote:
>
> Without assigning it to a variable, I don't see what sense the
> statement even makes.
>
>  (⊃⊃x)
>
> produces an intermediate value.  I can't think of what sense making an
> assignment to an intermediate value even does.
>
> I think APL should just throw a syntax error as in:
>
>   (+/10 10⍴⍳100)[2]←4
> SYNTAX ERROR
>   (+/10 10⍴⍳100)[2]←4
>   ^^
>
> (Surely a syntax error is more appropriate than a segfault!)
>
> What does IBM APL do?
>
> --blake
>
>
> On Sat, Apr 4, 2020 at 5:03 PM Rowan Cannaday  wrote:
>
>> hello y'all, hope everyone is staying safe.
>>
>>   x ← 1 (2 3 (4 5))
>>   (⊃⊃x)[2;3;] ← 6 7
>>
>>
>> ===
>> SEGMENTATION FAULT
>>
>> 
>> -- Stack trace at main.cc:88
>> 
>> 0x7F032D7BABBB __libc_start_main
>> 0x557F8B045425  main
>> 0x557F8B1BE755   Workspace::immediate_execution(bool)
>> 0x557F8B099A4BCommand::process_line()
>> 0x557F8B09A45A Command::do_APL_expression(UCS_string&)
>> 0x557F8B099AE8  Command::finish_context()
>> 0x557F8B0A3698   Executable::execute_body() const
>> 0x557F8B159D4CStateIndicator::run()
>> 0x557F8B0DB23D Prefix::reduce_statements()
>> 0x557F8B0DA17D  Prefix::reduce_MISC_F_B_()
>> 0x557F8B0F1F4F   Bif_F12_PICK::eval_B(Value_P)
>> 0x557F8B0EBB33Bif_F12_PICK::disclose(Value_P, bool)
>> 0x557F8B0EB86A Bif_F12_PICK::compute_item_shape(Value_P, bool)
>> 0x7F032DCD1520
>> 0x557F8B04C4AB
>> 
>> 
>>
>> By the way, it works if you use an intermediary variable:
>>
>>   y←⊃⊃x
>>   y[2;3;]
>> 4 5
>>   y[2;3;] ← 5 6
>>   y
>> 1 0
>> 0 0
>> 0 0
>>
>> 2 0
>> 3 0
>> 5 6
>>
>> Cheers,
>>  - Rowan
>>
>
>

Problem building version 1251 on Mac OS X

[Louis Chrétien via Bugs and suggestions for GNU APL]

This morning, having done the SVN update, I got version 1251.

When I try to compile on Mac OS X 10.14.6, with Xcode 11.3, I get this error:

g++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Werror  -g -O2 -MT 
apl-Bif_F12_DOMINO.o -MD -MP -MF .deps/apl-Bif_F12_DOMINO.Tpo -c -o 
apl-Bif_F12_DOMINO.o `test -f 'Bif_F12_DOMINO.cc' || echo './'`Bif_F12_DOMINO.cc
Bif_F12_DOMINO.cc:333:4: error: 'delete' applied to a pointer that was 
allocated with 'new[]'; did you mean
  'delete[]'? [-Werror,-Wmismatched-new-delete]
   delete data;
   ^
 []
Bif_F12_DOMINO.cc:242:17: note: allocated with 'new[]' here
double * data = new double[end];   if (data == 0)   WS_FULL;
^
1 error generated.
make[3]: *** [apl-Bif_F12_DOMINO.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


---
Louis Chrétien
lchret...@mac.com

Re: Problem building version 1251 on Mac OS X

[Dr . Jürgen Sauermann]

  
  
Hi Lois,
  
  thanks, fixed in SVN
  1252.

Best Regards,
Jürgen


On 4/7/20 9:02 PM, Louis Chrétien via
  Bugs and suggestions for GNU APL wrote:


  
  This morning, having done the SVN update, I got version 1251.
  
  
  When I try to compile on Mac OS X 10.14.6, with
Xcode 11.3, I get this error:
  
  
  
g++
-DHAVE_CONFIG_H -I. -I..    -Wall -I sql -Werror      -g -O2
-MT apl-Bif_F12_DOMINO.o -MD -MP -MF
.deps/apl-Bif_F12_DOMINO.Tpo -c -o apl-Bif_F12_DOMINO.o
`test -f 'Bif_F12_DOMINO.cc' || echo
'./'`Bif_F12_DOMINO.cc
Bif_F12_DOMINO.cc:333:4: error:
'delete' applied to a pointer that was allocated with
'new[]'; did you mean
 
    'delete[]'? [-Werror,-Wmismatched-new-delete]
  
delete data;
  
^
  
      []
Bif_F12_DOMINO.cc:242:17: note:
allocated with 'new[]' here
double
* data = "" double[end];   if (data == 0)   WS_FULL;
 
              ^
1
error generated.
make[3]:
*** [apl-Bif_F12_DOMINO.o] Error 1
make[2]:
*** [all-recursive] Error 1
make[1]:
*** [all-recursive] Error 1
make:
*** [all] Error 2

  

  
  
---
  Louis Chrétien
  lchret...@mac.com
  
  
  

  


  


  

Re: seg-fault with deeply nested assignment

[Rowan Cannaday]

thanks jurgen, i havent had time to pull latest and compile, but i
appreciate the fix.

- Rowan

On Tue, Apr 7, 2020, 5:58 AM Blake McBride  wrote:

> Thanks.  I saw that after I sent the email.  When I used APL, there was no
> APL2.  So, I've never used APL2 professionally.
>
> I also see that the latest repo version has a fix for the original report.
>
> Thanks!
>
> Blake
>
>
> On Tue, Apr 7, 2020 at 4:37 AM Dr. Jürgen Sauermann <
> mail@jürgen-sauermann.de> wrote:
>
>> Hi,
>>
>> actually it assigns a new value (*6 7* in the example) to a part of *x*.
>> Even though *⊃⊃x *is a temporarym
>> the assignment changes the original *x*.
>>
>> I suppose IBM APL2 does the same.
>>
>> BR, Jürgen
>>
>>
>> On 4/7/20 1:28 AM, Blake McBride wrote:
>>
>> Without assigning it to a variable, I don't see what sense the
>> statement even makes.
>>
>>  (⊃⊃x)
>>
>> produces an intermediate value.  I can't think of what sense making an
>> assignment to an intermediate value even does.
>>
>> I think APL should just throw a syntax error as in:
>>
>>   (+/10 10⍴⍳100)[2]←4
>> SYNTAX ERROR
>>   (+/10 10⍴⍳100)[2]←4
>>   ^^
>>
>> (Surely a syntax error is more appropriate than a segfault!)
>>
>> What does IBM APL do?
>>
>> --blake
>>
>>
>> On Sat, Apr 4, 2020 at 5:03 PM Rowan Cannaday 
>> wrote:
>>
>>> hello y'all, hope everyone is staying safe.
>>>
>>>   x ← 1 (2 3 (4 5))
>>>   (⊃⊃x)[2;3;] ← 6 7
>>>
>>>
>>> ===
>>> SEGMENTATION FAULT
>>>
>>> 
>>> -- Stack trace at main.cc:88
>>> 
>>> 0x7F032D7BABBB __libc_start_main
>>> 0x557F8B045425  main
>>> 0x557F8B1BE755   Workspace::immediate_execution(bool)
>>> 0x557F8B099A4BCommand::process_line()
>>> 0x557F8B09A45A Command::do_APL_expression(UCS_string&)
>>> 0x557F8B099AE8  Command::finish_context()
>>> 0x557F8B0A3698   Executable::execute_body() const
>>> 0x557F8B159D4CStateIndicator::run()
>>> 0x557F8B0DB23D Prefix::reduce_statements()
>>> 0x557F8B0DA17D  Prefix::reduce_MISC_F_B_()
>>> 0x557F8B0F1F4F   Bif_F12_PICK::eval_B(Value_P)
>>> 0x557F8B0EBB33Bif_F12_PICK::disclose(Value_P, bool)
>>> 0x557F8B0EB86A Bif_F12_PICK::compute_item_shape(Value_P,
>>> bool)
>>> 0x7F032DCD1520
>>> 0x557F8B04C4AB
>>> 
>>> 
>>>
>>> By the way, it works if you use an intermediary variable:
>>>
>>>   y←⊃⊃x
>>>   y[2;3;]
>>> 4 5
>>>   y[2;3;] ← 5 6
>>>   y
>>> 1 0
>>> 0 0
>>> 0 0
>>>
>>> 2 0
>>> 3 0
>>> 5 6
>>>
>>> Cheers,
>>>  - Rowan
>>>
>>
>>

Modulo algorithm

[Elias Mårtenson]

I was reading the APL spec and noted that it specifies that the modulo
operation is implementation-defined.

I've been looking at various sources, and it's not clear to me how complex
modulo is defined. Is there some source that documents it (and specifically
the method used in GNU APL).

Regards,
Elias

Building GNU APL (1.8, SVN: 1252) under OpenBSD/amd64 6.6-STABLE

[Alexander Shendi]

Hello GNU APL world,

I have compiled SVN 1252 under OpenBSD 6.6-STABLE (amd64).
I had the following small issue:

In file "src/Bif_F12_DOMINO.hh" I had to insert
#ifdef _N
#undef _N
#endif

after line 28. It seems the system header file "ctype.h" i
already #defines _N.
I'm not sure this is the correct remedy. Another option would be
to rename all occurences of "_N" in that file to e.g. "_NN".

After startup GNU APL displays the following message:

surfacego$ ./.local/gnuapl/svn-1252/bin/apl --noColor
*** Warning: the process memory limit (RLIMIT_AS) of 6442450944
 is more than the estimated total_memory of 3221225472.
 This could cause improper WS FULL handling.
::connect() to supposedly existing APserver failed: Invalid argument

I'm not sure what this means, let alone how to deal with it.

Many thanks in advance for your help.

Best Regards,

Alexander