[Ktechlab-devel] Please test before commit

[Alan Grimes]

P Zoltan wrote:
>   Rev. 505 had a severe bug: the PinNodes won't move together with te item  
> associated with them, and Qt was throwing lots of errors in the terminal.  
> Now it's fixed. The problem was that Qt takes the parameters of the slots  
> strictly, so "const double" != "double".

I was a bit panicked when I read that subject line given the number of
bad commits I've made. =0, But thankfully, the latest revision I worked
on was 503. =P I can move resistors around in 503 just fine.

Wait a minute, my version does have the version of node.h reverted by 506.

hmm... =\

Maybe if you do a clean-build it either does or doesn't work (not sure
which), based on whether the MOC file is regenerated. I'm not sure which
version of the MOC I'm running, so maybe I'll see it break on my end if
I do a clean build.

That said, my local version has many meaningless and or experimental
changes that I have not committed. It is quite possible that among these
are some that are actually important. =\

In general, "const" is annoying as hell to type  and read all over the
place again and again. BUT, it does allow the compiler to help find
errors in your code, confirm design assumptions, and even allow the
compiler to find more optimal instruction orderings.

>   It would be nice if we wouldn't introduce regressions; it something  
> doesn't "want" work, better talk about it on the list.

Sometimes it is unavoidable. Making the linear algebra engine more
correct, basically broke many circuits which were relying on the old
engine to fudge things just enough to work. However, no valid simulation
is possible unless the linear algebra system is correct.

Also, improving the models for nonlinear components seems to involve
making sure that the physical constants used are correct to the limits
of science. (see physics.h), and to make sure the equations are well
implemented. Unfortunately, I was not able to make it work. =(

>   Also based on the below list [1], some basic testing cand be done, just  
> to be sure that things mostly work. Suggestions for adding items to the  
> list are welcome (as comments usually).

ok...
>From the document >>>>>>>
( has ICN* any meaning as an abstraction? Is it needed? )
<<<<<<

YES.

Item documents are documents of items without connectors such as the
zombie rigid body dynamics (mechanics) code. =\

((((PROJECT: Go into the mechanics document code and make it active
enough that it can be tested and played with, even if it immediately
segfaults.
As part of this project, evaluate the potential for CAD, computer aided
engineering with ktechlab.))))

ICN documents are documents with connectors. So therefore, it seems to
me at least, the ICN documents are an important layer of abstraction.

>>>>>>>>>>>>>>>>
( the ItemDocumentData? class is flawed; there should be a class
hierarhy – there are are lots of dynamic_cast -s in its implementation;
also the objects should know to convert themselves to XML, to make the
structure extensible )
<<<<<<<<<<<<<<<

I don't understand how this code works so I haven't messed with it. =\




-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.