[Ktechlab-devel] Thinking like a Real Programmer (tm).

[P Zoltan]

On Tue, 05 Jan 2010 16:31:50 +0100, Alan Grimes <agrimes at speakeasy.net>  
wrote:

>
> It finally dawned on my pathetically dim mind why I'm having such a hard
> time preventing people from making drastic changes to the electronics
> simulation prior to the KDE4 port. =\
>
> That reason is that while everyone sees the same needs I do, they do not
> understand how I wish to approach them. This is because I have not taken
> the time to explain myself.
>


> C++ is a very difficult language. It takes no less than seven years to
> master. Furthermore, the API's for linking in runtime modules are
> obscure if not undocumented. If ktechlab is to take off, we need to
> provide the user the tools to add his own components without venturing
> within ten miles of a C++ compiler.

  I guess plugins are not intended for the users. They can be handy for  
_developers_, in order to structure code, or to avoid recompiling and  
relinking the main executable even for minor changes. ( g++ is slow... ).  
In my view the plugins are just about how do we deploy the application: 1  
big executables, or more smaller ones.

>
> To allow the user to add components, we should not be thinking in terms
> of plugins, because plugins are lame. We should be thinking in terms of
> declarative programs which the ktechlab engine will interpret and/or
> compile itself. -- A new, easier, form of SPICE.

  Expandability: it was discussed, and there was no final conclusion. We  
should have subcircuits. And user created extensions should be platform /  
architecture indepentent.

  Bth SPICE: importing from spice should be really cool. Should this be  
added on the feature request list?


>
> The user will have several options for creating componenets:
>
> -- He can create components as subcircuits in the GUI from circuit
> elements and/or anything else and add them to the component library.
>
> -- he can create components by using a part editor to create a library
> configuration for one of the built-in models such as for transistors or
> triodes. -- the system will hold this as a database item.
>
> -- or he can write a program which describes the matrix and other
> equations he needs to create a new model.
>

  Looks good.

>
> To make this work, we need to continue my efforts to streamline and
> minimize the code throughout the system. We then need to refactor the
> components and simulations such that each part of the simulation
> represents, as best as possible, an atomic concept. For example the
> Current Source should actually be composed of two elements, a pin that
> sources current and a pin that sinks current. By doing this the
> flexability and power of the engine will improve radically.
>


  I guess you're trying to make a bottom-up approach, while I'm planning  
top-bottom. :)

  We need to divide responsabilities between classes. One class should do  
one thing, and do that well. Currently that is not the case. By defining  
those interfaces, the simulator and the document part should be separated,  
and each cleaned up / rewritten.
  Further, the document and the view part also can be separated. I guess on  
KDE4 port already that's the situation.


> Another long-term headache of mine is the modeling of logic Outs, I've
> put a great deal of time into refactoring those classes. Effectively a
> rewrite at this point. I had this problem that I wanted to create a
> matrix which represented a fixed voltage say 4.8 volts or 0.2 volts, and
> a source impedance. Well, I spent days and days, weeks even, going about
> it the wrong way. I should have simply linked in a voltage source and an
> impedance and called it a day!! =P
>
> Another example. One very accurate way of modeling a diode is as a diode
> with a second, very weak, diode pointing the other way. So you get one
> set of parameters I_S, and N for the forward diode, and another for the
> reverse diode: I_SR, N_R.  The previous code computed both of these in
> one go. The current code has one diode junction which might be used
> twice to compute the reverse part of the diode.
>

  Someone linked a document from QUCS, describing the models used by them  
in simulation. That might be useful.

> In summary, plugins are the wrong way to approach the problem of letting
> the user program ktechlab. We want the user to program ktechlab strictly
> through the GUI, both graphically and through the part editor, with the
> ability, eventually, of parsing a new part description language file
> with an internal compiler.
>

  My conclusion is that here was a misunderstanding about plugins. They  
should not be something that an ordinary user create.


Quoting from the beginning of your email:

>
> It finally dawned on my pathetically dim mind why I'm having such a hard
> time preventing people from making drastic changes to the electronics
> simulation prior to the KDE4 port. =\

  Except the plugin system, what other changes you don't like? The rework  
of the way the simulator interacts with the circuit?