> Enumerating case is only possible if the component act like a Finit > State Automaton. That may not be the case for every component. > Embedding language in javascript fashion is (I think) a bad use of > XML.Remember this: "You know you made a poor use of XML when you need > some additionnal parsing".
bah! That doesn't apply because in our use case, what we are trying to encode, as data are programs, which necessarily need to be interpreted, no shame in that. It is absolutely necessary that the user be able to design components. So compiled C++ is out of the question. > Embedding a "tag language"... not writable by hand. Not easily readable. > But no additionnal parsing need to be done. > another issue I see with XML is that it would be quite heavy. XML files > may be quite big, parsing everything will take some time. can't be much worse than the current size of the ktechlab binary! =P There are several issues that I'm concerned about. A. Loading circuit save files which contain references to library components which may not be available when loaded. B. Being able to easily create derived components. IE, specifying that "this component is just like that component but here are some specific specifications". That way we'd have a model for a darlington pair transistor, then when the user finds a datasheet, he can quickly write a specific part specification based on the generic library model. Multiple inheritance is also important, On-Semi, for example, makes a power transistor teamed with a thermal diode. So therefore, we'd have to inherit both the transistor model and the thermal diode model and then assign them to a heatsink domain which may then be combined with a larger heatsink domain in the circuit, to get an accurate model of the part. To make this really work we need to develop a new parts editor that uses the same terminology and parameters found in datasheets. It should also have a mode that would let the user implement simple test circuits and verify that the graphs produced are similar to those the manufacturer provided. Of special interest, are the transfer curves for transistors (and tubes for that matter). -- It should be possible to reproduce these in the simulator. By doing that we'll be able to verify the accuracy of our models and the user will be able to understand in what ways the simulation might not match the actual part. First you'd need a proper oscilloscope... =P Then you'd need to set up continuously variable probes for X and Y, and then a stepping function where you would input a series of voltages or currents. The engine would then apply a ramp function to X and then graph Y for each value in the list. > I'm not against the use of XML, but I think that only simple components > should be written in XML. Others may be written in C/C++, compiled as > .so and loaded at launch time (or later...). Linux absolutly, positively, categorically, does not (and will not ever), in any way, support that type of dynamically linked libraries. I have no idea what gave you the impression that it did. It is conceivably possible that there are kernel calls which may make it possible BUT THEY ARE NOT DOCUMENTED, ANYWHERE!!!!, There may even be linkers which support that, but once again they are not documented anywhere, and there might be user libraries that let you do it but they are either so obscure I've never heard of them or so arcane that I'd never attempt to use them. I have spent so much time and effort in utter frustration that I've had it. I want to design my own OS that loading plugins is it's primary and essential function, however, in attempting to develop such an OS, I've not only received no support (which is expected), I've also been actively thwarted by people who have later confessed that they didn't like me so they actively worked to frustrate my efforts by banning me from chat rooms and mailing lists. I'm sorry, this is a red-hot sore hot-button issue for me. -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
