nice
i'm guessing this problem was not in my compiler's compilation .. but in
something they changed/added to the compiler since my version (4.4.3) ?
On Wed, 1 Feb 2017 22:30:49 +0100
Juergen Sauermann <juergen.sauerm...@t-online.de> wrote:
> 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, enz...@gmx.com 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 <juergen.sauerm...@t-online.de> 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, enz...@gmx.com 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 <juergen.sauerm...@t-online.de> 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, enz...@gmx.com wrote:
>
> core dump - i bz2'ed it and attached it
>
>
> On Tue, 31 Jan 2017 23:39:01 +0100
> Juergen Sauermann <juergen.sauerm...@t-online.de> wrote:
>
> Hi,
>
> sorry, should read:
>
> Q(ID::get_name(id)) // ← new line
>
> /// Jürgen
>
>
> On 01/31/2017 11:28 PM, enz...@gmx.com wrote:
> Q(name(ID::get_name(id))) // ← new line
> Q(name.size()) // ← another new line
>
>
>
>
>
>
>
