Re: [Bug-apl] svn 863 make warning/error

[Juergen Sauermann]

Hi Alexey,

agreed, except that this is not at all about singletons.

According to Wiki:

In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.

According to Dijkstra: software engineering is about "How to program if you cannot.". I am convinced
that GNU APL would have been impossible if I had used software design patterns.

The problem below was caused by an un-initialized string table (more precisely, it was initialized to
empty strings). And GNU APL is essentially single-threaded (unless you use parallel execution which
you normally do not).

/// Jürgen

On 02/02/2017 12:39 AM, Alexey Veretennikov wrote:

Just in case, singletons are evil (and should be considered anti-pattern
in any app with more than 1 thread). Better to replace them with
external interfaces and use via dependency injection (it will help to
write more tests later).

Being there done that - moving all singleton::instance() to the main
function, still it is a short term solution, since in order to write
tests for the functions which uses your singletones you have to invent
special kind of mocks (it is possible but hard).

Juergen Sauermann <address@hidden> writes:

Hi,

I see, then it is probably gone since I reworked that area.

BTW I have started to move all static object constructors to a single
file, which gives more control over the construction order and avoids
different orders with different compilers.

/// Jürgen

On 02/01/2017 08:17 PM, address@hidden wrote:

 
it was the get_name line you added in Id.cc 

Core was generated by `/usr/local/apl-svn/bin/apl -v'.
Program terminated with signal 11, Segmentation fault.
#0  0x08093b9b in std::basic_ios<char, std::char_traits<char> >::widen (cond=0x8279234 "result", 
    fun=0x824d573 "get_name", file=0x824d32e "Id.cc", line=85)
    at /usr/local/gcc/lib/gcc/i686-enztec-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/basic_ios.h:440
440           { return __check_facet(_M_ctype).widen(__c); }



On Wed, 1 Feb 2017 19:51:41 +0100
Juergen Sauermann <address@hidden> wrote:

 Hi,

I wasn't able to decipher the core. It is difficult if the core was 
dumped from a binary that differs
from your own sources. It says:

*...**
**#9  0x082fba5c in VH_entry::history ()**
**#10 0xbfb167b8 in ?? ()**
**Backtrace stopped: previous frame inner to this frame (corrupt stack?)**
**(gdb) **
*
It would be helpful if you could load the core into gdb on your system 
and send me the
backtrace displayed by gdb.

I also fixed x⎕AV in *SVN 874* - I am getting too old for all of this.

/// Jürgen



On 02/01/2017 07:02 PM, address@hidden wrote:

 
Indeed you did
btw you left the 'debug' x⎕AV in the Id.def    ;)

here is the apl start  (i added the change in Symbol.cc to test and didn't have to do the change in Id.def)

name:                '⎕' at Symbol.cc:50
name:                '⍞' at Symbol.cc:50
name:                '⎕AI' at Symbol.cc:50
name:                '⎕ARG' at Symbol.cc:50
name:                'x⎕AV' at Symbol.cc:50
name:                '⎕CT' at Symbol.cc:50
name:                '⎕EM' at Symbol.cc:50
name:                '⎕ET' at Symbol.cc:50
name:                '⎕FC' at Symbol.cc:50
name:                '⎕IO' at Symbol.cc:50
name:                '⎕L' at Symbol.cc:50
name:                '⎕LC' at Symbol.cc:50
name:                '⎕LX' at Symbol.cc:50
name:                '⎕PP' at Symbol.cc:50
name:                '⎕PR' at Symbol.cc:50
name:                '⎕PS' at Symbol.cc:50
name:                '⎕PW' at Symbol.cc:50
name:                '⎕R' at Symbol.cc:50
name:                '⎕RL' at Symbol.cc:50
name:                '⎕SVE' at Symbol.cc:50
name:                '⎕SYL' at Symbol.cc:50
name:                '⎕TC' at Symbol.cc:50
name:                '⎕TS' at Symbol.cc:50
name:                '⎕TZ' at Symbol.cc:50
name:                '⎕UL' at Symbol.cc:50
name:                '⎕X' at Symbol.cc:50
name:                '⎕WA' at Symbol.cc:50
name:                'λ' at Symbol.cc:50
name:                '⍺' at Symbol.cc:50
name:                '⍵' at Symbol.cc:50
name:                'χ' at Symbol.cc:50
name:                '⍶' at Symbol.cc:50
name:                '⍹' at Symbol.cc:50


       )wsid
IS CLEAR WS
       )save xyz
2017-02-01  10:51:46 (GMT-7)
       )load xyz
name:                '⎕CT' at Symbol.cc:50
name:                '⎕FC' at Symbol.cc:50
name:                '⎕IO' at Symbol.cc:50
name:                '⎕L' at Symbol.cc:50
name:                '⎕LX' at Symbol.cc:50
name:                '⎕PP' at Symbol.cc:50
name:                '⎕PR' at Symbol.cc:50
name:                '⎕PS' at Symbol.cc:50
name:                '⎕PW' at Symbol.cc:50
name:                '⎕R' at Symbol.cc:50
name:                '⎕RL' at Symbol.cc:50
name:                '⎕SYL' at Symbol.cc:50
name:                '⎕TZ' at Symbol.cc:50
name:                '⎕X' at Symbol.cc:50
name:                'λ' at Symbol.cc:50
name:                '⍺' at Symbol.cc:50
name:                '⍵' at Symbol.cc:50
name:                'χ' at Symbol.cc:50
name:                '⍶' at Symbol.cc:50
name:                '⍹' at Symbol.cc:50
SAVED 2017-02-01 10:51:46 (GMT-7)
       )wsid
IS xyz

---

Post debrief

was there a source code change step after the 'core dump' that you did to figure this out ? or did you figure it out from the the core?
I'd like to save this work as a case study type thing (it was a pretty interesting set of circumstances)

---

your progrmming talents are supreme - maybe you can take a look at my apl code that causes my rasp pi running this https://en.wikipedia.org/wiki/Digi-Comp_I to get stuck between floors of my elevator ;)
^^ bad humour

thanks  Jürgen   this was a great process to go through
Ps I'll wait a few days to get back the the    ⍝ ∇   and    clear screen/cursor location situation

though here :
/usr/bin/clear | hexdump -c    or -C for hex    -c gives ascii
0000000 033   [   H 033   [   2   J
0000007

====

On Wed, 1 Feb 2017 13:07:27 +0100
Juergen Sauermann <address@hidden> wrote:

 Hi,

I believe I found the problem.

It looks like the constructor for the Workspace object (containing all system variables)
was called before the constructors for the system variables were called. That made the
names of the system variables empty strings.

The compiler has some freedom regarding the order of initialization of static objects
and your compiler has chosen different order than mine.

Hopefully fixed in SVN 872.

/// Jürgen


On 01/31/2017 11:47 PM, address@hidden wrote:

core dump - i bz2'ed it and attached it


On Tue, 31 Jan 2017 23:39:01 +0100
Juergen Sauermann <address@hidden> wrote:

Hi,

sorry, should read:

Q(ID::get_name(id))   // ← new line

/// Jürgen


On 01/31/2017 11:28 PM, address@hidden wrote:
Q(name(ID::get_name(id)))   // ← new line
Q(name.size())              // ← another new line