[Ktechlab-devel] Flowcode in ktl-0.3.7

[P Zoltan]

  Let's start this mail with a famous quote:

"There are two ways to write code: write code so simple there are  
obviously no bugs in it, or write code so complex that there are no  
obvious bugs in it."

  It seems that if I revert the commit that has removed the usage  
QGuardedPtr class in some cases, this bug doesn't appear. Could someone  
test in a revision earlier than 447 ?

  I don't fully agree on removing QGuardedPtr _now_, because we get too  
much odd behaviour to deal with. (IMHO) Ideally we should focus on a small  
part of the codebase, fix that -- like the equation solver, for instance  
--, fix every problem with it, then move to another part / aspect /  
functionality, and so on, while trying to keep the other parts working.  
Any opinions on this idea?

  Another topic related to this: valgrind gives a lot of errors for me;  
some are from the messed up destructor in ICNDocument, while the others  
 from joining connectors (that's really bad). Without QGuardedPtr, ktechlab  
crashes under valgrind at startup, without displaying its main window.


On Mon, 28 Sep 2009 21:01:59 +0200, P Zoltan <zoltan.padrah at gmail.com>  
wrote:

> On Tue, 22 Sep 2009 15:46:42 +0200, santiago gonzalez  
> <santigoro at gmail.com> wrote:
>
>> http://arcachofo.users.sourceforge.net/ktl4
>
>   I think I found the root of this, but it's not obvious how to fix it.
>
> electronicconnector.cpp, at the destructor:
>
> "Something else is deleting wires, FIXME, figure out what the deal is."
>
>   And the deletion of the wires is commented out... this caused the  
> strange behaviour. The problem is that after editing the circuit,  
> sometimes ktechlab crashes at that point, probably because double  
> pointer free... In conclusion, more debugging is needed.
>
>   I want to comment on the problems of SVN here: because I don't make  
> diffs between different commits, I didn't know about this change, so I  
> had to search through the source code. With something like Git, the  
> pathes are sent, so everybody can easily see, what was changed -- and  
> probably comment it.
>