Re: /⍨

2022-06-09 Thread Dr . Jürgen Sauermann 

  
  
Hi Hudson,
  
  thanks, see below. SVN 1561.
  
  Best Regards,
  Jürgen


On 6/8/22 3:59 PM,
  hud...@hudsonlacerda.com wrote:


  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 .


Fixed. However, please note the following.

The operating system, at least GNU/Linux resp. bash handles text
files
differently depending on whether they are executable or not. This is
not detectable by the executed script or binary (= apl). The only
thing
that apl can do is to apply some heuristics as to how it was
started.

You may (and should)  avoid the above hanging by having )OFF at the
end of the script or by using the --OFF command line option (or in
the
shebang line if the script is started directly).

  


  

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.)



I have change the code so that A?B (which was probably the culprit)
will no longer be executed in parallel.


  
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

Re: /⍨

2022-06-09 Thread hudson 
Hi Jürgen,

Many thanks.

Building GNU APL with default ./configure options work fine overall.
I noticed that my config options (compiler version, core count, develop wanted, 
assert, etc.)
are overriden by "make develop" or "make parallel[1]".

However, any attempt to use more than one core causes errors (like below).

I am not sure whether I should continue to try parallel processing and report 
such exceptions,
since it is experimental in GNU APL, and I do not have expertise
to significantly help you debugging the program in a different plataform.

Cheers,
Hudson

PS. Executable scripts are working fine now.


  ]log 26
Log facility 'details of error throwing   ' is now ON 
  ]log 25
Log facility 'more verbose errors ' is now ON 
  ⎕syl[26;2]←2
  120× (?⍨120),¨⍳120

throwing DOMAIN ERROR
throwing DOMAIN ERROR at Cell.cc:156
 at Cell.cc:156


-- Stack trace at Error.cc:198

0x76A6F7FD __libc_start_main
0x55618205  main
0x557A91F5   Workspace::immediate_execution(bool)
0x5567F5DBCommand::process_line()
0x5567F678 Command::finish_context()
0x5568C8D8  Executable::execute_body() const
0x557457CC   StateIndicator::run()
0x556C8CC0Prefix::reduce_statements()
0x556C27FC Prefix::reduce_A_F_B_()
0x55744975  Bif_F12_TIMES::eval_AB(Value_P, Value_P) const
0x55741730   ScalarFunction::eval_scalar_AB(Value const&, Value 
const&, ErrorCode (Cell::*)(Cell*, Cell const*) const) const
0x557406F1ScalarFunction::do_scalar_AB(ErrorCode&, Value 
const&, Value const&, ErrorCode (Cell::*)(Cell*, Cell const*) const) const
0x5573FDB2 ScalarFunction::PF_scalar_AB(Thread_context&)
0x55662C47  
0x5568C6B1   throw_apl_error(ErrorCode, char const*)

DOMAIN ERROR+
  120×(?⍨120),¨⍳120
  ^   ^
total_lines in apl.lines: 752472
assembler lines in apl.lines: 169513
source line numbers found:169513


-- Stack trace at Error.cc:198

0x21B7DD80 
0x163799  Parallel::worker_main(void*) at Parallel.cc:381
0x1EBDB2   ScalarFunction::PF_scalar_AB(Thread_context&) at Shape.hh:211
0x10EC47
0x1386B1 throw_apl_error(ErrorCode, char const*) at Error.cc:203

DOMAIN ERROR+
  120×(?⍨120),¨⍳120
  ^   ^
terminate called after throwing an instance of 'Error'

Thread 2 "apl" received signal SIGABRT, Aborted.
[Switching to Thread 0x754f2640 (LWP 69811)]
__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.
(gdb) 
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x76a6e546 in __GI_abort () at abort.c:79
#2  0x76e08909 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x76e13f2a in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x76e13f95 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x76e141e8 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x5568c724 in throw_apl_error(ErrorCode, char const*) 
(code=code@entry=E_DOMAIN_ERROR, loc=loc@entry=0x557c10b6 "Cell.cc:156") at 
Error.cc:213
#7  0x55662c47 in Cell::get_pointer_value() const (this=0x55950460) 
at Cell.cc:156
#8  0x5573fdb2 in ScalarFunction::PF_scalar_AB(Thread_context&) 
(tctx=...) at ScalarFunction.cc:655
#9  0x556b7799 in Parallel::worker_main(void*) (arg=0x559582e0) at 
Parallel.cc:380
#10 0x770d1d80 in start_thread (arg=0x754f2640) at 
pthread_create.c:481
#11 0x76b4676f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95