i'm not blaming you as even the original author of the FLU code gave up
on the DND code as too buggy in the end and just removed it from the
last couple of releases (that I found) I just consider FLU to be an
integral part of VirtualT as VirtualT won't compile without it and it's
included in the VirtualT source tree directly so in my mind it's "ken's
code" :)
As we now have two possible "fixes" for building with a "modern" gcc
(although which is the "preferred" one i'm not really sure) i'm just
going to add that to my "building VirtualT" notes and move on to see if
the segfault is something I am causing, a bug in gcc, lack of RAM on the
systems i'm using for VirtualT or something fixable.
bst rgrds
Russell
On 9/26/2019 12:54 PM, Ken Pettit wrote:
Hey Russell,
I've seen this before in the past and remember I had spend a fair
amount of time trying to debug it. But being "ken's code" that I
didn't write, I was basically just poking at it the dark and didn't
figure anything out.
Ken
On 9/26/19 9:45 AM, Russell Davis wrote:
As FLU has been pretty much left to bitrot for about the last 15
years or so (afaik) I consider it "ken's code" these days. That might
be wrong in everyone else's view but it's how I feel.
I have noticed something in all the builds i've done recently both on
ARM & x86 that I need to see happens in earlier builds (when I can
find where I put them) as I can't remember whether it occurred in
them or it's something new.
I get always segfault when closing the disassembler window and a few
BadDrawable (invalid Pixmap or Window parameter) 0x400058 when
messing around with the tools menu on occasion
bst rgrds
Russell
On 9/25/2019 7:24 PM, John R. Hogerhuis wrote:
On Wed, Sep 25, 2019 at 4:20 PM Russell Davis
<[email protected] <mailto:[email protected]>> wrote:
I just wanted a fix to let VirtualT build (reasonably) cleanly
and that
seemed to work. i'll leave proper fixes to Ken if he decides
that they
need doing sometime.
I got that.
This is actually upstream FLTK. Not Ken's code.
I can't imagine Ken assigning false to a pointer :-)
-- John.
