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

Alan Grimes agrimes at speakeasy.net
Thu Jan 7 19:53:58 UTC 2010


P Zoltan wrote:

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

I hope you aren't actually cleaning the tree before each incremental
build... I might do a clean-build once every three or four days and then
after that, for minor changes, only a small portion of the tree is
actually recompiled and the compile speed is actually quite reasonable
for the size of the binary...

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

Yeah, I've been using that. It does have it's limitations though. I
think the most powerful approach is to factor everything down to it's
most atomic units and then re-compose them in a verifiable whole.

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

Okay, how do plugins work? How do I write a plugin? I know how to write
a linkable library, but not a plugin... How do you think plugins should
work in ktechlab? etc...

-- 
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.





More information about the Ktechlab-devel mailing list