[Ktechlab-devel] simulator

[Celelibi]

2008/11/8, P Zoltan <zoltan.padrah at gmail.com>:
> On Fri, 07 Nov 2008 02:09:13 +0100, Julian Bäume <julian at svg4all.de>
wrote:
>
>> On Friday 07 November 2008 01:14:35 Glen wrote:
>>> Is there any direction / ideas for what direction the simulator should
>>> go? I have my own ideas, especially now since I've probed the code a
>>> little bit, but what's really better for the project?
>> Some time ago, it was mentioned on the list, that the actual code won't
>> scale.
>> So it's really hard to add new components to the simulator. We need a
>> way to
>> define components more easy.
>
>   Actually the components are hard-coded in the program, so to change
them,
> you need to recompile ktechlab. That's a huge problem, imo.
>
>> XML would be something to mention here. I don't
>> see the problem to do something like that with the visualisation part,
>> but for
>> the simulator I don't see a good way to do it.
>
>   I think the models can be also defined in XML; I've mentioned this on
the
> list earlier:
> some 'basic' components should be defined in the program and everything
> else threated as subcircuit. So in XML we should describe two things: the

> symbol for the new component and the equivalent subcircuit as the model.
>   As I know, spice does something similar: there are some basic parts,
and
> the more complex ciruits are threated as subcircuits.
>
>   Things get tricky when we want to define some interactive components
with
> XML. For that we might need some expression-evaluation algorithms.
>

Hum, well. You know, XML is quite a good description language. It is
possible to do anything with it.
But have you ever tried to imagin what a programming language would be in
XML ?
It could looks like
<if test="x == y && x+y > c">
    <then>
       <!-- some very useful things -->
    </then>
    <else>
       <!-- yet very useful things -->
    </else>
</if>

that's quite awful to write.
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.

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.
But if you want to represent dynamic things (like some electronic
components) you may :
- try to make a static representation by usually enumerating every case
- try to embed some kind of programming language.
    - In a fashion like javascript inside html pages
    - Or as a "tag language".


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".
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.

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...).



But after all, I'm not a developer, I'm just someone who follow that
project.


>
>> There is a wiki page for features:
>> http://ktechlab.org/wiki/index.php?title=DEVEL:Feature_Request
>>
>
>   BTW Wiki: can the wiki made read-only for not registered readers? When
I
> look at the recent changes, I see 99% spam / spam deleted.
>
>> I mentioned to create the simulation logic in the XML files via ECMA
>> script,
>> since this could be interpreted by Qt. I haven't done any speed tests
>> till
>> now.. shame on me.
>>
>


Celelibi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20081108/0714ea7a/attachment.html>