Right now I have a hand-implemented shift register with a ton of D-flippies. There is a standard chip that does the same thing called the 74164 (or more modern: 74LS164).
I started to implement the part then I remembered that I wanted to re-design the parts library. Here are some of the things that are pissing me off about the code right now. >>> Nonlinear is broken, affecting Diode and Jfet but apparently leaving bjt untouched for some unfathomable reason, might be a computational drift issue or exponentially huge value returned by the current version of diodeJunction, or some other bug in the engine. (!!!) there is plenty of evidence for other bugs, IE seeing 27 volts in a circuit with nothing except 5 volt power supplies. (We need infrastructure to benchmark/measure when the nonlinear iterations converge and not and obtain debugging on when it doesn't.) >>> Connectors still mess up, It's not the catastrophy it used to be, the showstopper bugs have been fixed but there are MANY problems. For example, I came across a class Point today. Why the hell do we have a class point?? Well anyway, I started to refactor it to see whether it tends to either evaporate or pull in other functions to become a proper class... Well, two of its four variables were set but never read, so I cleaned lines of code from several other methods. The connector router is the most algorithmically complex thing ktechlab does. In order to make it work we _MUST_ do our best to organize that code so that it makes the best sense, has no dead variables or functions so that it is plainly obvious what everything does. >>> there are still many classes stacked on top of each other (in the same files. If all the classes in the file are tiny, then OK. If there are two or more decent sized classes in a single file THEY SHOULD BE SEPARATE!!!! There are many many advantages to keeping classes separate, for one thing it becomes easier to audit which classes a class is using. In one case I found a class including a bunch of child classes when it should have included only a parent class. By cleaning up includes we also improve compile time and the reliability of our builds. Fortunately, ktechlab is shaping up to have several discreet layers of organization. These layers should be made more distinct and the separation between them should be rigorously enforced. Ie, most code in /src should be completely ignorant of anything and everything going on in either /src/electronics or /src/flowparts. This way the code becomes more robust and maintainable. In general there should not be any super huge or super tiny classes. Some of the super tiny classes might be better treated as structs or even switch to library functionality. One of the reasons its difficult to debug the simulation engine is that I messed up the current reading code from the wires. =P (Yes it's my fault too.) But to get it working again I need a traceable path from the engine through the model classes (pin and wire, I think), to the interface classes such as electricconnector and ECNode. I want to simplify jkflipflop some more but am not using it right now and don't really have any good test circuits. Anyway. -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
