Menu
▾
▴
ktechlab-devel
|
From: Alan G. <ag...@sp...> - 2008-05-25 18:49:39
|
first off, I hate C++. Normally you'd think that all you have to do is to remember to delete what you allocate, noooo, you not only have to remember to delete your stuff but you also need to keep track of HOW you allocated it. There's a bug in my Qmatrix class, and possibly Qvector too where I just deleted the darn arrays, I think I was supposed to delete[] them.... Huge difference -- in C++. =( That much is trivial. The biggest issue is that everyone wants more parts yet the approach Ktechlab currently uses to implement parts is not scalable. =( If you want to see what I mean by this, use kdevelop's "class inheritance diagram" feature to look at the "picinfo" tree. That one class has roughly fifty children and it's descendants are nested as much as 7 levels deep! Right now the approach is that whenever anyone wants anything implemented, what happens is that several classes are developed and added to the package. This creates a maintainance nightmare. =\ The solution I proposed was to move to a database driven parts library, where parts are loaded at runtime from a library of XML files which can be added and tweaked by the user without having to recompile the entire program. The problem is that implementing this functionality will require a great deal of work. For one thing, the simulation model of each component would have to be compiled from code embedded in the XML file. -- Ron Paul: A man of Peace. Chemistry.com: A total rip-off. Powers are not rights. We did not invade Iraq, the government did. |
|
From: Mauricio G. <mau...@ya...> - 2008-05-26 11:33:15
|
Alan Grimes escribió: > first off, I hate C++. Normally you'd think that all you have to do is > to remember to delete what you allocate, noooo, you not only have to > remember to delete your stuff but you also need to keep track of HOW you > allocated it. There's a bug in my Qmatrix class, and possibly Qvector > too where I just deleted the darn arrays, I think I was supposed to > delete[] them.... Huge difference -- in C++. =( > > That much is trivial. I agree, Java makes a better approach for that with its garbage collector. Anyway c/c++ is theorically more close to the hardware (not framework involved) and its executables should perform better. > > The biggest issue is that everyone wants more parts yet the approach > Ktechlab currently uses to implement parts is not scalable. =( If you > want to see what I mean by this, use kdevelop's "class inheritance > diagram" feature to look at the "picinfo" tree. That one class has > roughly fifty children and it's descendants are nested as much as 7 > levels deep! > > Right now the approach is that whenever anyone wants anything > implemented, what happens is that several classes are developed and > added to the package. This creates a maintainance nightmare. =\ > > The solution I proposed was to move to a database driven parts library, > where parts are loaded at runtime from a library of XML files which can > be added and tweaked by the user without having to recompile the entire > program. > > The problem is that implementing this functionality will require a great > deal of work. For one thing, the simulation model of each component > would have to be compiled from code embedded in the XML file. > Your approach sounds pretty logical to me. Its seems to be how other EDA softwares work and the user can even edit and customize components to fit their needs. I can't add anything as I'm not used to the internal simulation characteristics of Ktechlab but is there anything like Spice involved? -- ------------------------------ Mauricio Giovagnini (Maunix) www.maunix.com.ar Cordoba, Arg. LinkedIn Profile: http://www.linkedin.com/in/mgiovagnini |
|
From: Julian B. <ju...@sv...> - 2008-05-26 12:01:39
|
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 |
|
From: Mauricio G. <mau...@ya...> - 2008-05-26 12:15:03
|
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 |
|
From: Jonathan-David S. <mys...@fr...> - 2008-05-26 12:47:57
|
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 < mau...@ya...> 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 > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > > -- http://www.jaxtr.com/myselfhimself |
|
From: <cel...@gm...> - 2008-06-04 19:03:05
|
2008/6/4, Peter Jørgensen <fif...@gm...>: > 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. > Hum, well. I think ktechlab is slow enough for now. But it would need some tests to see C++ is really faster than python. (NB : perl forever !) I think that very speed-demanding parts should be written in C, not C++ IMHO. I think C++ is a good choice (not QT but that's another problem), it could be quite cross-platform if the code have a good design. Unfortunately I'm not really into the code but I think redesigning the way new components are added would involve some big modifications in the code. Therefore I think a new version would be created in order to "rewrite" the whole code (maybe with some big copy/past carefully read three time). But as I said, I don't know how big this challenge is because I'm not into the code. I think that if this is done, I will read every line commited to understand how it works. My 2 cent. Celelibi |
|
From: Gopala K. <kri...@gm...> - 2008-06-04 19:26:30
|
> > But as I said, I don't know how big this challenge is because I'm not > into the code. > I think that if this is done, I will read every line commited to > understand how it works. Believe me, it is very hard to rewrite an already existing code. Its better to start from scratch using the old codebase as a guide. This helps us to accelerate at a better pace. As some one mentioned Qucs doesn't do interactive simulation, but the port of Qucs to qt4 is seeing umpteen changes. We started from the ground up, because porting qt3 code directly doesn't always help. Also it doesn't let us exploit the cool great features of qt4. We are trying to use svg+xml to represent components in qucs and good news is its working now. We are also using xslt and ngschema to validate the xml and svg. The graphicsview really helps to simplify lots of gui handling stuff. Here is a screen shot http://picasaweb.google.com/krishna.ggk/Projects/photo#5176846323701445890 So, i think may be ktechlab in future can derive some code from qucs-qt4 and hopefully the vice-versa as well. :-) -- Cheers, Gopala Krishna A |
|
From: Michael T. <mic...@gm...> - 2008-06-05 10:36:20
|
> > "As some one mentioned Qucs doesn't do interactive simulation, but the > port of *Qucs to qt4* is seeing *umpteen changes*. We* started* from the > *ground up,* because porting qt3 code directly doesn't always help. Also > it doesn't let us exploit the cool great features of qt4." Thanks for the update on Quc's port it seems promising. - The qucs main site is going to get updated too to reflect that soon? - Does it mean that it will do interactive simulations in the future? SVG + XML is cool combo to draw components correctly. On Wed, Jun 4, 2008 at 3:26 PM, Gopala Krishna <_hi...@gm...> wrote: > > > > But as I said, I don't know how big this challenge is because I'm not > > into the code. > > I think that if this is done, I will read every line commited to > > understand how it works. > > Believe me, it is very hard to rewrite an already existing code. Its > better to start from scratch using the old codebase as a guide. This > helps us to accelerate at a better pace. > > As some one mentioned Qucs doesn't do interactive simulation, but the > port of Qucs to qt4 is seeing umpteen changes. We started from the > ground up, because porting qt3 code directly doesn't always help. Also > it doesn't let us exploit the cool great features of qt4. > > We are trying to use svg+xml to represent components in qucs and good > news is its working now. We are also using xslt and ngschema to > validate the xml and svg. > The graphicsview really helps to simplify lots of gui handling stuff. > Here is a screen shot > http://picasaweb.google.com/krishna.ggk/Projects/photo#5176846323701445890 > > So, i think may be ktechlab in future can derive some code from > qucs-qt4 and hopefully the vice-versa as well. :-) > > -- > Cheers, > Gopala Krishna A > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
|
From: Gopala K. <kri...@gm...> - 2008-06-05 11:20:54
|
On Thu, Jun 5, 2008 at 4:06 PM, Michael T. <mic...@gm...> wrote: > The qucs main site is going to get updated too to reflect that soon? I am not sure about this because i was the main person involved in the port. And currently i am busy with summer of code (umbrello under kde) But then a fellow developer (git enthusiast) is developing the port in his spare time in git repo hosted at tuxfamily. (unofficial) It will take atleast 3-4 months to decide on it (after i finish my soc) > Does it mean that it will do interactive simulations in the future? I don't think so. The qucs-core is the backend simulator program which accepts net list as input and generates simulated output as files (with plot data) The gui uses this to display the result. Right now in qucs-qt3, it is possible to do 2 or more simulations simultaneously though. I have to discuss this with the maintainer to know more information about this idea. > SVG + XML is cool combo to draw components correctly. Yup. 1. git clone git://git.tuxfamily.org/gitroot/qucsqt4dev/qucsqt4.git 2. git clone git://git.tuxfamily.org/gitroot/qucsqt4dev/qcomponents/qucscomponents.git Have a look at link 2 to see how the components are represented currently. Nothing is final, it is still under development. I am really sorry if anyone feels i *hijacked* this thread. :) I just hope may be ktechlab can collaborate with qucs in future because even i like the interactiveness of ktechlab :) -- Cheers, Gopala Krishna A |
|
From: P. J. <fif...@gm...> - 2008-06-04 15:19:28
|
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 <mys...@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 < > mau...@ya...> 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 >> Kte...@li... >> 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 > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > > |
|
From: Lawrence S. <det...@gm...> - 2008-06-05 05:12:05
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
If it would be rewritten in python/QT4, I could do a LOT of coding. I
know python/QT4 quit well.<br>
<br>
Peter Jørgensen wrote:
<blockquote
cite="mid:bb4...@ma..."
type="cite">Hi<br>
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.<br>
<br>
<div class="gmail_quote">2008/5/26 Jonathan-David SCHRODER <<a
moz-do-not-send="true" href="mailto:mys...@fr...">mys...@fr...</a>>:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">hi<br>
devices could be compiled in shared libraries along with the
executable, and still be written in C/C++.<br>
or ktechlab could include some interpreted language runtime which is
able to compile scripts to binary and execute them.<br>
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.<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
Jonathan
<div>
<div class="Wj3C7c"><br>
<br>
<div class="gmail_quote">On Mon, May 26, 2008 at 2:17 PM, Mauricio
Giovagnini <<a moz-do-not-send="true"
href="mailto:mau...@ya..." target="_blank">mau...@ya...</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Julian
Bäume escribió:<br>
<div>
<div>> On Monday 26 May 2008 13:35:30 Mauricio Giovagnini
wrote:<br>
>> I can't add anything as I'm not used to the internal<br>
>> simulation characteristics of Ktechlab but is there anything<br>
>> like Spice involved?<br>
> No, you derive a special component from the component base class
and implement<br>
> the internals based on the values (current and voltage) that are
connected at<br>
> the pins you define for your component. This computation will
change the pins<br>
> values based on the behaviour of your special component. This is
exactly the<br>
> point Alan mentions here, since this doesn't scale. You will end
up with<br>
> hundrets of special classes each for a special calculation for one
special<br>
> component.<br>
><br>
> bye then<br>
> julian<br>
<br>
</div>
</div>
Hi julian. Now I can figure out the magnitude of the<br>
problem. So, the project doesn't need "coders", it needs<br>
system engineers and mathematicians, with experience in<br>
simulation tools. At least on the technical point of view.<br>
<div>
<div><br>
<br>
<br>
<br>
--<br>
------------------------------<br>
Mauricio Giovagnini (Maunix)<br>
<a moz-do-not-send="true" href="http://www.maunix.com.ar"
target="_blank">www.maunix.com.ar</a><br>
Cordoba, Arg.<br>
LinkedIn Profile: <a moz-do-not-send="true"
href="http://www.linkedin.com/in/mgiovagnini" target="_blank">http://www.linkedin.com/in/mgiovagnini</a><br>
<br>
-------------------------------------------------------------------------<br>
This SF.net email is sponsored by: Microsoft<br>
Defy all challenges. Microsoft(R) Visual Studio 2008.<br>
<a moz-do-not-send="true"
href="http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/"
target="_blank">http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/</a><br>
_______________________________________________<br>
Ktechlab-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Kte...@li..." target="_blank">Kte...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/ktechlab-devel"
target="_blank">https://lists.sourceforge.net/lists/listinfo/ktechlab-devel</a><br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
</div>
</div>
<font color="#888888">-- <br>
<a moz-do-not-send="true" href="http://www.jaxtr.com/myselfhimself"
target="_blank">http://www.jaxtr.com/myselfhimself</a>
</font><br>
-------------------------------------------------------------------------<br>
This SF.net email is sponsored by: Microsoft<br>
Defy all challenges. Microsoft(R) Visual Studio 2008.<br>
<a moz-do-not-send="true"
href="http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/"
target="_blank">http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/</a><br>
_______________________________________________<br>
Ktechlab-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Kte...@li...">Kte...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/ktechlab-devel"
target="_blank">https://lists.sourceforge.net/lists/listinfo/ktechlab-devel</a><br>
<br>
</blockquote>
</div>
<br>
<pre wrap="">
<hr size="4" width="90%">
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
<a class="moz-txt-link-freetext" href="http://sourceforge.net/services/buy/index.php">http://sourceforge.net/services/buy/index.php</a></pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Ktechlab-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kte...@li...">Kte...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ktechlab-devel">https://lists.sourceforge.net/lists/listinfo/ktechlab-devel</a>
</pre>
</blockquote>
</body>
</html>
|
Thanks for helping keep SourceForge clean.
X