<br><br>2008/11/8, P Zoltan <<a href="mailto:zoltan.padrah@gmail.com">zoltan.padrah@gmail.com</a>>:<br>> On Fri, 07 Nov 2008 02:09:13 +0100, Julian Bäume <<a href="mailto:julian@svg4all.de">julian@svg4all.de</a>> wrote:<br>
><br>>> On Friday 07 November 2008 01:14:35 Glen wrote:<br>>>> Is there any direction / ideas for what direction the simulator should<br>>>> go? I have my own ideas, especially now since I've probed the code a<br>
>>> little bit, but what's really better for the project?<br>>> Some time ago, it was mentioned on the list, that the actual code won't <br>>> scale.<br>>> So it's really hard to add new components to the simulator. We need a <br>
>> way to<br>>> define components more easy.<br>><br>> Actually the components are hard-coded in the program, so to change them, <br>> you need to recompile ktechlab. That's a huge problem, imo.<br>
><br>>> XML would be something to mention here. I don't<br>>> see the problem to do something like that with the visualisation part, <br>>> but for<br>>> the simulator I don't see a good way to do it.<br>
><br>> I think the models can be also defined in XML; I've mentioned this on the <br>> list earlier:<br>> some 'basic' components should be defined in the program and everything <br>> else threated as subcircuit. So in XML we should describe two things: the <br>
> symbol for the new component and the equivalent subcircuit as the model.<br>> As I know, spice does something similar: there are some basic parts, and <br>> the more complex ciruits are threated as subcircuits.<br>
><br>> Things get tricky when we want to define some interactive components with <br>> XML. For that we might need some expression-evaluation algorithms.<br>><br><br>Hum, well. You know, XML is quite a good description language. It is possible to do anything with it.<br>
But have you ever tried to imagin what a programming language would be in XML ?<br>It could looks like<br><if test="x == y && x+y > c"><br> <then><br> <!-- some very useful things --><br>
</then><br> <else><br> <!-- yet very useful things --><br> </else><br></if><br><br>that's quite awful to write.<br>But we could go yet farther by writing the expression in the test with tags like <and>, <equal>, <add>, <sup> and <var>. And in that way the XML document would be a ASCII representation of the abstract syntax tree.<br>
<br>XML is a good language to describe static things (or to describe a snapshot of dynamic things) with a finit (and static) number of properties.<br>But if you want to represent dynamic things (like some electronic components) you may :<br>
- try to make a static representation by usually enumerating every case<br>- try to embed some kind of programming language.<br> - In a fashion like javascript inside html pages<br> - Or as a "tag language".<br>
<br><br>Enumerating case is only possible if the component act like a Finit State Automaton. That may not be the case for every component.<br>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".<br>
Embedding a "tag language"... not writable by hand. Not easily readable. But no additionnal parsing need to be done.<br>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.<br>
<br>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...).<br><br><br><br>But after all, I'm not a developer, I'm just someone who follow that project.<br>
<br><br>><br>>> There is a wiki page for features:<br>>> <a href="http://ktechlab.org/wiki/index.php?title=DEVEL:Feature_Request">http://ktechlab.org/wiki/index.php?title=DEVEL:Feature_Request</a><br>>><br>
><br>> BTW Wiki: can the wiki made read-only for not registered readers? When I <br>> look at the recent changes, I see 99% spam / spam deleted.<br>><br>>> I mentioned to create the simulation logic in the XML files via ECMA <br>
>> script,<br>>> since this could be interpreted by Qt. I haven't done any speed tests <br>>> till<br>>> now.. shame on me.<br>>><br>><br><br><br>Celelibi<br>