On Saturday 08 November 2008 12:06:03 Celelibi wrote: > 2008/11/8, P Zoltan <[EMAIL PROTECTED]>: > > On Fri, 07 Nov 2008 02:09:13 +0100, Julian Bäume <[EMAIL PROTECTED]> > > 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. Yes, I don't think this is the way to go..
> 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...). I fully agree with your last point here. I'm not yet familiar with the possibilities of the kdelibs here, but I know, there is a strong plugin- interface to do such things. You are even not bound to a specific language. Kross is the name of the scripting interface, I'm not sure, if this helps here. The longer I think about it, the more I think, we need a plugin interface here, to put the computation-stuff for the components into external libraries that are loaded on demand. These libraries could also contain the representation of the components, of course. We then could make them available via KHotNewStuff so everybody can download them from within the program. These are also ideas mentioned in the wiki, but not as clear as they are to me, now. > But after all, I'm not a developer, I'm just someone who follow that > project. Anyway, thanks for your participation in the discussion. There's no need to be a developer to take part in development ;) bye then julian
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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
