Re: /⍨

[Dr . Jürgen Sauermann]

Hi Peter,

thanks, good idea. I will do so.

Best Regards,
Jürgen


On 6/7/22 7:39 PM, Peter Teeson wrote:

Hi Jurgen:

If it’s not already there please add the debugging tips you give below 
as an item to the documentation.


respect….

Peter

On Jun 7, 2022, at 12:56 PM, Dr. Jürgen Sauermann 
> wrote:


Hi Hudson,

I believe that I fixed the double execution for executable scripts,
Looks like the OS handles executable scripts differently than
non-executable ones. *SVN 1560*.

The F ← {⍵ × (?⍨⍵) ,¨ ⍳⍵} bug is something that I cannot reproduce.
I wonder if it happens always or lnly sometimes. I have some suggestions
for you and others that make my life easier:

* run "*make develop*" in the top-level directory.

That enables some more internal checks that may be useful for 
troubleshooting.

Most importantly it enables dynamic logging.

* run *"make apl.lines"* in the *src* directory,

That makes GNU APL's stack traces more readable, i.e.whowing  line 
numbers rather
than hex addresses. After that only use the apl binary in the src 
directory.


* do "ulimit -c unlimited" go get a core file when apl crashes silently,

It does not hurt and after that you can "gdb ./apl core" to obtain 
more information

about where a fault has occured (gdb command *bt*)

* in apl: do

*  ]log 25**
**      ]log 26*

That gives more details about where APL errors were thrown. In 
particular with
your function F because I cannot quite see why it would give a 
*DOMAIN ERROR* at all

and therefore the location where that happens would be interesting.

Thanks,
Jürgen


On 6/6/22 7:32 PM, hud...@hudsonlacerda.com wrote:

Hi Jürgen,

- Dr. Jürgen Sauermann <mail@jürgen-sauermann.de  
> escreveu:
[...]
> Thanks. I believe this is a compiler error (which does not happen with
> mine -
> g++ (Ubuntu 9.4.0-1ubuntu1~18.04) 9.4.0).
[….]

Here it is:
   g++ (Debian 11.3.0-3) 11.3.0

⌹2 is now fixed, but there are strange behaviours in other cases.
Please see the attachments.

Best,
Hudson

Re: /⍨

[hudson]

Hi Jürgen,

- Em 7 de Jun de 2022, em 13:56, Dr. Jürgen Sauermann 
mail@jürgen-sauermann.de escreveu:

> Hi Hudson,
> 
> I believe that I fixed the double execution for executable scripts,
> Looks like the OS handles executable scripts differently than
> non-executable ones. SVN 1560 .

Thanks.

Now, executable scripts need "-f" to be run directly ( ./script.apl ).

   #!/usr/bin/env -S apl -s -f

Otherwise, apl waits for stdin input (the script is not executed),
and apl cannot be terminated by killall apl — only by ")off" or kill .


> 
> The F ← {⍵ × (?⍨⍵) ,¨ ⍳⍵} bug is something that I cannot reproduce.
> I wonder if it happens always or lnly sometimes.

It happened always, for ⍵>35 around. But the errors were different
for every argument value. See attachment.


> I have some suggestions
> for you and others that make my life easier:
> 
> * run " make develop " in the top-level directory.
>
[...]

Thank you for the explanation. It was useful.
After some testing, my conclusions are:


1) The errors seem be caused by parallel processing. I was using

   ./configure DEVELOP_WANTED=yes CORE_COUNT_WANTED=2

   (Now I run ./configure without options.)


2) With  make develop / make apl.lines / ./apl, the program worked fine
   inside src/ directory.


3) I got the same bugs after "sudo make install", running /usr/local/bin/apl.


4) No problems if "sudo make uninstall" before reconfiguring and recompiling.
   That suggests me that some residues of previous versions were remaining.


5) README-2-configure suggests running

   autoreconf --force --install
   ./configure
   make

   but I need also calling autoupdate:

   autoupdate
   autoreconf --force --install
   ./configure
   make


Best regards,
Hudson







Reading symbols from ./apl...

warning: core file may not match specified executable file.
[New LWP 191833]
[New LWP 191832]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./apl -l 25 -l 26'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49  ../sysdeps/unix/sysv/linux/raise.c: Arquivo ou diretório inexistente.
[Current thread is 1 (Thread 0x7f59a5a1c640 (LWP 191833))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x7f59a6f98546 in __GI_abort () at abort.c:79
#2  0x7f59a7332909 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x7f59a733df2a in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x7f59a733df95 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x7f59a733e1e8 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x55f713425d13 in throw_apl_error(ErrorCode, char const*)
(code=code@entry=E_DOMAIN_ERROR, loc=loc@entry=0x55f713592a03 
"Cell.cc:156") at Error.cc:213
#7  0x55f7133f8eb7 in Cell::get_pointer_value() const (this=0x55f715326460) 
at Cell.cc:156
#8  0x55f713501b72 in ScalarFunction::PF_scalar_AB(Thread_context&) 
(tctx=...) at ScalarFunction.cc:654
#9  0x55f713457ff9 in Parallel::worker_main(void*) (arg=0x55f71532ded0) at 
Parallel.cc:380
#10 0x7f59a75fbd80 in start_thread (arg=0x7f59a5a1c640) at 
pthread_create.c:481
#11 0x7f59a707076f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


---




  9120× (?⍨9120),¨⍳9120


throwing DOthrowing DOMAIN ERROR at Cell.cc:1MAIN ERROR at Cell.cc:1556
6


-- Stack trace at Error.cc:198

0x7F6D947257FD __libc_start_main
0x55F6577B7415  main
0x55F65799D835   Workspace::immediate_execution(bool)
0x55F65783C2D1Command::process_line()
0x55F65783C39F Command::finish_context()
0x55F65784BF28  Executable::execute_body() const
0x55F65793051C   StateIndicator::run()
0x55F6578943D3Prefix::reduce_statements()
0x55F65788B27C Prefix::reduce_A_F_B_()
0x55F65792F575  Bif_F12_TIMES::eval_AB(Value_P, Value_P) const
0x55F65792A8A0   ScalarFunction::eval_scalar_AB(Value const&, Value 
const&, ErrorCode (Cell::*)(Cell*, Cell const*) const) const
0x55F657928F51ScalarFunction::do_scalar_AB(ErrorCode&, Value 
const&, Value const&, ErrorCode (Cell::*)(Cell*, Cell const*) const) const
0x55F657927B72 ScalarFunction::PF_scalar_AB(Thread_context&)
0x55F65781EEB7  
0x55F65784BCA1   throw_apl_error(ErrorCode, char const*)

DOMAIN ERROR+
  9120×(?⍨9120),¨⍳9120
  ^^

==
Assertion failed: get_pointer_cell_count() == 0
in Function:  ~Value
in file:  Value.cc:450

Call stack:


-- Stack trace at Assert.cc:72

0x7F6D9472