[Ktechlab-devel] The biggest technical issue

Peter Jørgensen fifafrazer at gmail.com
Wed Jun 4 15:19:36 UTC 2008


Hi
Im not into the code myself, but if the whole ktechlab engine has to be
rewritten, wouldn't it be a good idea to do it in python instead, and only
use c++ extensions for the very speed-demanding parts. Then the application
could easily be made cross-platform, which would make it available for a lot
more users, and there is no free alternative to ktechlab for windows or mac.
Just a thought.. It may be stupid to write everything all over again, but I
can't tell, as all I know is that the engine of ktechlab should be
rewritten, as Alan Grimes has told us.

2008/5/26 Jonathan-David SCHRODER <myselfhimself at free.fr>:

> hi
> devices could be compiled in shared libraries along with the executable,
> and still be written in C/C++.
> or ktechlab could include some interpreted language runtime which is able
> to compile scripts to binary and execute them.
> in Blender's game engine, python scripts are parsed & converted to
> bytecode, and then the bytecode is evaluated at each requested iteration.
> The thing is that it's node compiled code that's run but bytecode. The speed
> is ok though.
> I think that ruby can compile files into executable but I'm not sure. So
> with this assumption, if ruby is include inside ktechlab, every time new
> components are downloaded and added to the ktechlab device libraries, ruby
> could compile these new devices scripts and those could be dynamically
> linked as shared libraries.
>
> One month ago, I noticed a piece of software on the internet which does the
> same thing as ktechlab (and with hdl support), it's a shareware... maybe...
> I find the web page again, I could contact the software developper and ask
> him how things work for his software application (I'll test first if the
> software can use external components).
>
> proteus's isis also has an interactive circuit simulator... maybe we could
> write to them and ask them how things work as to how components are
> stored/loaded/compiled.
>
> Jonathan
>
>
> On Mon, May 26, 2008 at 2:17 PM, Mauricio Giovagnini <
> maugiovagnini at yahoo.com.ar> wrote:
>
>> Julian Bäume escribió:
>> > On Monday 26 May 2008 13:35:30 Mauricio Giovagnini wrote:
>> >> I can't add anything as I'm not used to the internal
>> >> simulation characteristics of Ktechlab but is there anything
>> >> like Spice involved?
>> > No, you derive a special component from the component base class and
>> implement
>> > the internals based on the values (current and voltage) that are
>> connected at
>> > the pins you define for your component. This computation will change the
>> pins
>> > values based on the behaviour of your special component. This is exactly
>> the
>> > point Alan mentions here, since this doesn't scale. You will end up with
>> > hundrets of special classes each for a special calculation for one
>> special
>> > component.
>> >
>> > bye then
>> > julian
>>
>> Hi julian. Now I can figure out the magnitude of the
>> problem.  So, the project doesn't need "coders", it needs
>> system engineers and mathematicians, with experience in
>> simulation tools.  At least on the technical point of view.
>>
>>
>>
>>
>> --
>> ------------------------------
>> Mauricio Giovagnini (Maunix)
>> www.maunix.com.ar
>> Cordoba, Arg.
>> LinkedIn Profile: http://www.linkedin.com/in/mgiovagnini
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Ktechlab-devel mailing list
>> Ktechlab-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>>
>>
>
>
> --
> http://www.jaxtr.com/myselfhimself
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ktechlab-devel mailing list
> Ktechlab-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20080604/2d61a053/attachment.html>


More information about the Ktechlab-devel mailing list