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. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel