From: Gopala K. <kri...@gm...> - 2007-11-04 14:32:29
|
Hi, This is going to be the major change in the qucs-qt4 where the components will be represented by xml and the corresponding schematic by svg. Now is the right time to come to a conclusion about the xml file format. I request active participation from you people in this regard. :-) According to the discussion between me and Bastein, this is the draft we agreed to(partially ;-) ) <component name="resistor" qucsversion="0.1.0"> <desc> <C>Resistor<C/> <fr>Resistance<fr/> <desc/> <help> <C>A dissipative device. Ohm law apply<C/> <help/> <schematic type="external" filename="resistor.svg"/> <ports> <port name="1" position="0,0"> <port name="1" position="4.5,0"> <ports/> <properties> <property name="R" type="double" range="positive" unit="ohm" isnetlistproperty="false"> <help> <C> Help text here <C/> <help/> <property/> <properties> <component/> This is just a rough draft. What is your opinion about this ? I have some doubts to be clarified. First of all i went through most of qucs/components/*.h and *.cpp files (Whew!! ) There are some components which implement the netlist method, verilog method and vhdl method. If we xmlize the components, how can we represent these in the xml ? Or should these components need to reimplemented as c++ code itself ? What does the parameter for get_VHDL_Code(int NumPorts) represent ? I see this usage in the function body, if(NumPorts < 0). But i really couldn't understand this. Can somebody explain me ? One more confusing place is the properties implementation. There are comments which warns us to maintain the order of properties. I understand that this is for specific reasons like for example not to write unnecessary properties to netlist. But it would be better if someone could make a comprehensive list of these special behavior so that it will be easier to convert them to xml. What is the best "name" to be used to identify components ? This will be used to cache svg's, id's of svgs, sidebar... Currently in qucs-qt3 i guess Component::Model is used to identify components right ? Finally should the digital and analog ports be differentiated or is it enough to use one kind of port to both the categories ? -- Cheers, Gopala Krishna A |
From: Bastien R. <rou...@gm...> - 2007-11-04 15:25:26
|
Le dimanche 4 novembre 2007, Gopala Krishna a =E9crit=A0: > Hi, > This is going to be the major change in the qucs-qt4 where the > components will be represented by xml and the corresponding schematic > by svg. Now is the right time to come to a conclusion about the xml > file format. I request active participation from you people in this > regard. :-) I could add that transform all the c++ code to xml will allow to easilly ad= d=20 component to the gui without recompiling the gui. That is a major gain of=20 time and ressource comparing to the actual system. Moroever it will allow t= o=20 fully decouple gui from core :-) > According to the discussion between me and Bastein, this is the draft > we agreed to(partially ;-) ) > > <component name=3D"resistor" qucsversion=3D"0.1.0"> > <desc> > <C>Resistor<C/> > <fr>Resistance<fr/> > <desc/> > <help> > <C>A dissipative device. Ohm law apply<C/> > <help/> > <schematic type=3D"external" filename=3D"resistor.svg"/> > <ports> > <port name=3D"1" position=3D"0,0"> > <port name=3D"1" position=3D"4.5,0"> > <ports/> > <properties> > <property name=3D"R" type=3D"double" range=3D"positive" unit=3D"ohm" > isnetlistproperty=3D"false"> > <help> > <C> > Help text here > <C/> > <help/> > <property/> > <properties> > <component/> > > > This is just a rough draft. What is your opinion about this ? > > I have some doubts to be clarified. > First of all i went through most of qucs/components/*.h and *.cpp > files (Whew!! ) > There are some components which implement the netlist method, verilog > method and vhdl method. If we xmlize the components, how can we > represent these in the xml ? I think we could extend the xml component model to add this, but I am short= of=20 idea > Or should these components need to reimplemented as c++ code itself ? > > What does the parameter for get_VHDL_Code(int NumPorts) represent ? I > see this usage in the function body, if(NumPorts < 0). But i really > couldn't understand this. Can somebody explain me ? > > One more confusing place is the properties implementation. There are > comments which warns us to maintain the order of properties. I > understand that this is for specific reasons like for example not to > write unnecessary properties to netlist. But it would be better if > someone could make a comprehensive list of these special behavior so > that it will be easier to convert them to xml. > > What is the best "name" to be used to identify components ? This will > be used to cache svg's, id's of svgs, sidebar... > Currently in qucs-qt3 i guess Component::Model is used to identify > components right ? > > Finally should the digital and analog ports be differentiated or is it > enough to use one kind of port to both the categories ? I will say we need to differenciate the two kind of port, because they are= =20 physically different. Regards=20 Bastien =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Oswald B. <os...@kd...> - 2007-11-04 15:58:41
|
On Sun, Nov 04, 2007 at 08:02:20PM +0530, Gopala Krishna wrote: > <schematic type="external" filename="resistor.svg"/> > <ports> > <port name="1" position="0,0"> > <port name="1" position="4.5,0"> > <ports/> > this looks wrong. the ports should be defined inside the svg. > There are some components which implement the netlist method, verilog > method and vhdl method. If we xmlize the components, how can we > represent these in the xml ? > Or should these components need to reimplemented as c++ code itself ? > i see no alternative to implenting the device models in c++. you can try to make the models pluggable, so the xml would name a library that implements the model. you could also have a second library that implements the gui to parametrize a part of the given type. btw, consider making xml files and plugins possible that implement multiple components, and group the standard components logically - if you need to load two or more files for each component, startup time sill suffer significantly. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Bastien R. <rou...@gm...> - 2007-11-04 16:11:38
|
Le dimanche 4 novembre 2007, Oswald Buddenhagen a =E9crit=A0: > On Sun, Nov 04, 2007 at 08:02:20PM +0530, Gopala Krishna wrote: > > <schematic type=3D"external" filename=3D"resistor.svg"/> > > <ports> > > <port name=3D"1" position=3D"0,0"> > > <port name=3D"1" position=3D"4.5,0"> > > <ports/> > > this looks wrong. the ports should be defined inside the svg. Why ? Give me some argument... Actually port are separed in tjhe C++ code from drawing. Moreover we do=20 notwant to parse svg file each time we need to get port position for wiring. I agree that port need to be defined in the svg file. But is a only graphic= al. BTW if you user commit a mistake copying port cordinate between svg file an= d=20 xml file it is his problem. A little bit like you do rm -rf / as root :-) > > There are some components which implement the netlist method, verilog > > method and vhdl method. If we xmlize the components, how can we > > represent these in the xml ? > > Or should these components need to reimplemented as c++ code itself ? > > i see no alternative to implenting the device models in c++. > you can try to make the models pluggable, so the xml would name a > library that implements the model. you could also have a second library > that implements the gui to parametrize a part of the given type. > btw, consider making xml files and plugins possible that implement > multiple components, and group the standard components logically - if > you need to load two or more files for each component, startup time sill > suffer significantly. It is not about performance. Early optimization is evil (Donald knuth). It = is=20 about correctness. We do not say device model are not implemented is C++ . = We=20 are saying that implementing gui component in C++ is not scalable and quite= =20 boring for core team.** Unix philosophy is one program, one goal. The goal of the gui is to offer a= =20 gui nothing more, we do not want to add C++ file each time we add a compone= nt=20 in core. To be simple we will implement one file one component in a first time. Beca= use=20 we prefer (Gopala and me) a slow thing but correct and scalable. The medium term goal is to implement a auxilarry program that will group al= l=20 the component database in a single file. But we prefer to concentrate in a= =20 simple but working thing ** BTW I think a lot of component will be implemented using equation block= =20 instead of C++. And moreover I use regulary Sparam (s2p) pure text file=20 model. Therefore it is not true that you implement model in C++ =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Gopala K. <kri...@gm...> - 2007-11-04 16:30:02
|
> this looks wrong. the ports should be defined inside the svg. There is still confusion regarding this. Lets see what others have to say about this. > > There are some components which implement the netlist method, verilog > > method and vhdl method. If we xmlize the components, how can we > > represent these in the xml ? > > Or should these components need to reimplemented as c++ code itself ? > > > i see no alternative to implenting the device models in c++. > you can try to make the models pluggable, so the xml would name a > library that implements the model. you could also have a second library > that implements the gui to parametrize a part of the given type. > btw, consider making xml files and plugins possible that implement > multiple components, and group the standard components logically - if > you need to load two or more files for each component, startup time sill > suffer significantly. Performance can be given look at a later stage i feel. Infact we will be adding caching mechanisms to handle this which should speed up things considerably. :-) The actual device models are implemented in the core part, so nothing to worry from the gui point of view. The reason i asked the question regarding this was, to find out a possibility to find out a universal xml format which can counter these minor quirks. Most of the components fit very well inside xml. I got an idea for on hooking vhdlCode() and verilogCode() to xml. My idea is to use place holder in place of port->Connection->Name so that these placeholders can be replaced by the appropriate connection name. Have a look at the the current implementation of these functions in d_flipflop, digi_source and other files for an overview and this possibility. Stefan, is there something that can be done from core part so that the Component::netlist() works universally for all ? @Oswald: Are you too shift key challenged, like Aaron ? ;-) -- Cheers, Gopala Krishna A |
From: Bastien R. <rou...@gm...> - 2007-11-04 17:43:06
|
Le dimanche 4 novembre 2007, Gopala Krishna a =E9crit=A0: > > this looks wrong. the ports should be defined inside the svg. > > There is still confusion regarding this. Lets see what others have to > say about this. > > > > There are some components which implement the netlist method, verilog > > > method and vhdl method. If we xmlize the components, how can we > > > represent these in the xml ? > > > Or should these components need to reimplemented as c++ code itself ? > > > > i see no alternative to implenting the device models in c++. > > you can try to make the models pluggable, so the xml would name a > > library that implements the model. you could also have a second library > > that implements the gui to parametrize a part of the given type. > > btw, consider making xml files and plugins possible that implement > > multiple components, and group the standard components logically - if > > you need to load two or more files for each component, startup time sill > > suffer significantly. > > Performance can be given look at a later stage i feel. Infact we will > be adding caching mechanisms to handle this which should speed up > things considerably. :-) Exactly caching and embeded a lot of little file in one xml file using an=20 external program will speed up a lot of thing > The actual device models are implemented in the core part, so nothing > to worry from the gui point of view. The reason i asked the question > regarding this was, to find out a possibility to find out a universal > xml format which can counter these minor quirks. Most of the > components fit very well inside xml. > I got an idea for on hooking vhdlCode() and verilogCode() to xml. My > idea is to use place holder in place of port->Connection->Name so that > these placeholders can be replaced by the appropriate connection name. > Have a look at the the current implementation of these functions in > d_flipflop, digi_source and other files for an overview and this > possibility. Ok I understand that you want to say. You cannot know by advance the number= of=20 port of an vhdl file. You need to read the vhdl file in order to get the=20 number of port. I think the best option is to create a custom component for= =20 each vhdl or verilog file. It is that xilinx do or spice do. They create a= =20 local component type. > Stefan, is there something that can be done from core part so that the > Component::netlist() works universally for all ? > > @Oswald: Are you too shift key challenged, like Aaron ? ;-) Regards Bastien =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Oswald B. <os...@kd...> - 2007-11-04 16:48:39
|
On Sun, Nov 04, 2007 at 05:11:32PM +0100, Bastien ROUCARIES wrote: > Le dimanche 4 novembre 2007, Oswald Buddenhagen a écrit : > > On Sun, Nov 04, 2007 at 08:02:20PM +0530, Gopala Krishna wrote: > > > <schematic type="external" filename="resistor.svg"/> > > > <ports> > > > <port name="1" position="0,0"> > > > <port name="1" position="4.5,0"> > > > <ports/> > > > > this looks wrong. the ports should be defined inside the svg. > Why ? Give me some argument... > having coordinates on the outside that point into the svg is just plain bad style. > Actually port are separed in tjhe C++ code from drawing. > internal detail. why would a component designer care? > Moreover we do notwant to parse svg file each time we need to get port > position for wiring. > you need to do it once on startup. > I agree that port need to be defined in the svg file. But is a only > graphical. > i completely agree. coordinates are graphical, though. > BTW if you user commit a mistake copying port cordinate between svg > file and xml file it is his problem. A little bit like you do rm -rf / > as root :-) > that's nonsense. you hardly can justify denormalizing data structures with the argument that the user just has to pay somewhat more attention to keep them consistent. every serious database designer would shoot you. the right thing is declaring named ports in the part definition and having appropriately named objects in the svg file. > It is not about performance. Early optimization is evil (Donald knuth). > yes. and designing something that is known to be performance-critical in a way that makes later optimization impossible is just stupid. > We do not say device model are not implemented is C++ . We are saying > that implementing gui component in C++ is not scalable and quite > boring for core team.** > i didn't challenge that position - in fact, i couldn't support it more. i guess we are hitting some type of communication barrier here. note that i have little clue about qucs internals (and none about the gui) and thus can only use generally known and accepted terminology. > The medium term goal is to implement a auxilarry program that will > group all the component database in a single file. > a cache works for the xml and svg files, but not for plugins if you chose to go with them. > ** BTW I think a lot of component will be implemented using equation > block instead of C++. And moreover I use regulary Sparam (s2p) pure > text file model. Therefore it is not true that you implement model in > C++ > oh, great - an interpreter. i'm already looking forward to my simulations taking two days instead of two hours. @gopala: yes, i *invented* being shift key challenged. :) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Bastien R. <rou...@gm...> - 2007-11-04 17:30:06
|
Le dimanche 4 novembre 2007, Oswald Buddenhagen a =E9crit=A0: Do not trim CC please Le dimanche 4 novembre 2007, Oswald Buddenhagen a =E9crit : > On Sun, Nov 04, 2007 at 05:11:32PM +0100, Bastien ROUCARIES wrote: > > Le dimanche 4 novembre 2007, Oswald Buddenhagen a =E9crit : > > > On Sun, Nov 04, 2007 at 08:02:20PM +0530, Gopala Krishna wrote: > > > > <schematic type=3D"external" filename=3D"resistor.svg"/> > > > > <ports> > > > > <port name=3D"1" position=3D"0,0"> > > > > <port name=3D"1" position=3D"4.5,0"> > > > > <ports/> > > > > > > this looks wrong. the ports should be defined inside the svg. > > > > Why ? Give me some argument... > > having coordinates on the outside that point into the svg is just plain > bad style. Sorry but taste is not a technical argument :-)=20 > > Actually port are separed in tjhe C++ code from drawing. > > internal detail. why would a component designer care? I agree. But I say it will not to be different from actual processing > > Moreover we do notwant to parse svg file each time we need to get port > > position for wiring. > > you need to do it once on startup. How can we differenciate port annotation in svg file? I suppose using=20 http://www.w3.org/TR/SVGMobile12/extend.html And the question taht could be raised is why not therefore using this=20 mechanism for property and something else. I do not think it is a good idea= =20 to use this mechanism for property help text ort something else because it = is =20 not the goal of the svg file to carry this information > > I agree that port need to be defined in the svg file. But is a only > > graphical. > > i completely agree. coordinates are graphical, though. No coordinate are not graphical. Sorry we do not agree. They are no definitive decision in the norm (IEC 617) about position of the= =20 port. Sometime port are even not linked to wire. It will be therefore quite= =20 difficult to justify why port are embeded directly in svg file > > BTW if you user commit a mistake copying port cordinate between svg > > file and xml file it is his problem. A little bit like you do rm -rf / > > as root :-) > > that's nonsense. you hardly can justify denormalizing data structures > with the argument that the user just has to pay somewhat more attention > to keep them consistent. every serious database designer would shoot > you. I do not say this I say that svg should not incoporate any information abou= t=20 port. Nothing more. And if the user put the port in a stupid position it is= =20 own bussiness that all I say. Moreover a medium term goal is to embeded the= =20 svg file (that is xml) directly in the xml component file. But we do not do= =20 this because it will be simpler to use external file in a first go. > the right thing is declaring named ports in the part definition and > having appropriately named objects in the svg file. I do not agree with you because it is really heacy weight to parse svg for= =20 retrying port. And as I say before I know some schematic (again in the norm= )=20 of component where the port is nowhere (ie not linked to any graphical=20 element). Therefore your approach do not work.=20 > > It is not about performance. Early optimization is evil (Donald knuth). > > yes. and designing something that is known to be performance-critical in > a way that makes later optimization impossible is just stupid. No please, I do not want to offence ou I want only to highlight that I pref= er=20 correctness and scalability against performance. > > We do not say device model are not implemented is C++ . We are saying > > that implementing gui component in C++ is not scalable and quite > > boring for core team.** > > i didn't challenge that position - in fact, i couldn't support it more. > i guess we are hitting some type of communication barrier here. note > that i have little clue about qucs internals (and none about the gui) > and thus can only use generally known and accepted terminology. GUI create netlist (pure text file) and this text file are processed by the= =20 core. Actually the problem is that when we add a component in core (usually= =20 in C++) we must code somtehing (in C++) in the gui that code for the=20 schematic and the translation layer schematic netlist. > > The medium term goal is to implement a auxilarry program that will > > group all the component database in a single file. > > a cache works for the xml and svg files, but not for plugins if you > chose to go with them. It is not a cache it is a program that will create at installation one whol= e=20 file from a lot of little fiel creating therefore a database. A little bit= =20 like a compiler. The princips is to use xml embeding capability. IE we can= =20 embeded a svg file directly in a component xml file, that is embeded in a=20 database of component file > > ** BTW I think a lot of component will be implemented using equation > > block instead of C++. And moreover I use regulary Sparam (s2p) pure > > text file model. Therefore it is not true that you implement model in > > C++ > > oh, great - an interpreter. i'm already looking forward to my simulations > taking two days instead of two hours. It is not about interpreted. In my field some computation need one month of= =20 bibliographic research (mathematicall, etc). One week of hand writing math,= =20 two or three day of mathematica, One week of fortran coding, And one week o= f=20 simulation on a big grid. And at the end we extract a model (datafile or=20 analytic). We do not want to recode an C++ component each time we get a new= =20 result, nothing more. And we do not care to lost 1% of speed simualting thi= s=20 component.=20 I agree that classical component are needed to be simulated in C++, but som= e=20 are not even analytical (think a infinite serie or a contour integral in th= e=20 complex plane) and are therefore better simulated using datafile :-) Thank for your answer.=20 BTW I am on #qucs channel > @gopala: yes, i *invented* being shift key challenged. :) =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Oswald B. <os...@kd...> - 2007-11-05 00:33:20
|
On Sun, Nov 04, 2007 at 06:29:53PM +0100, Bastien ROUCARIES wrote: > Le dimanche 4 novembre 2007, Oswald Buddenhagen a écrit : > > having coordinates on the outside that point into the svg is just > > plain bad style. > > Sorry but taste is not a technical argument :-) > this isn't about taste, but basic software design principles. > > > Moreover we do notwant to parse svg file each time we need to get port > > > position for wiring. > > > > you need to do it once on startup. > > How can we differenciate port annotation in svg file? > by ... uh, wait, didn't i say "named objects", like in "every object in an svg file can be given an id"? > I suppose using http://www.w3.org/TR/SVGMobile12/extend.html > slight overkill > And the question taht could be raised is why not therefore using this > mechanism for property and something else. > because it would be backwards, maybe? > > > I agree that port need to be defined in the svg file. But is a only > > > graphical. > > > > i completely agree. coordinates are graphical, though. > > No coordinate are not graphical. Sorry we do not agree. > !?!? how could a coordinate into a graphics *not* be graphical? > > the right thing is declaring named ports in the part definition and > > having appropriately named objects in the svg file. > > I do not agree with you because it is really heacy weight to parse svg for > retrying port. > i doubt that re-parsing small svg files (the symbols aren't going to be particularly big by any means) would have any significant impact. also, you can have your "compiler" put the data into some more accessible location. it might even be that you can use QSvgRenderer::boundsOnElement directly. and anyway - where has "prefer correctness and scalability against performance" suddenly gone? > And as I say before I know some schematic (again in the norm) of > component where the port is nowhere (ie not linked to any graphical > element). Therefore your approach do not work. > wow. and i thought one could do such completely unthinkable things as overlaying the bounding rect of a symbol with a transparent zero-size element and do other obvious absurdities. stupid me. ;) > Actually the problem is that when we add a component in core (usually > in C++) > => plugin > we must code somtehing (in C++) in the gui that code for the schematic > #define something > and the translation layer schematic netlist. > as this is a rather cheap procedure that needs to be done once when starting a simulation, you can easily use QtScript embedded into the xml file. > > > The medium term goal is to implement a auxilarry program that will > > > group all the component database in a single file. > > > > a cache works for the xml and svg files, but not for plugins if you > > chose to go with them. > > It is not a cache it is a program that will create at installation one > whole file from a lot of little fiel creating therefore a database. > a cache is more flexible - it needs no special handing at installation time, particularly when the user installs 3rd party components later. > A little bit like a compiler. > yeah. for aggregating plugins you'd need a linker, though. :D -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Bastien R. <rou...@gm...> - 2007-11-05 10:20:47
|
Le lundi 5 novembre 2007, Oswald Buddenhagen a =E9crit=A0: Please do not trim CC > On Sun, Nov 04, 2007 at 06:29:53PM +0100, Bastien ROUCARIES wrote: > > Le dimanche 4 novembre 2007, Oswald Buddenhagen a =E9crit : > > > having coordinates on the outside that point into the svg is just > > > plain bad style. > > > > Sorry but taste is not a technical argument :-) > > this isn't about taste, but basic software design principles. I am really sorry but taste and basic software principles are like relativi= ty=20 they are relative :-) For instance when I program a PIC I love self modifyi= ng=20 code. But when I program in C++ on linux I think it is overkill and bad=20 taste. =20 Another instance is the linus torvarld vs Tanenbaum flame, etc etc... > > > > Moreover we do notwant to parse svg file each time we need to get > > > > port position for wiring. > > > > > > you need to do it once on startup. > > > > How can we differenciate port annotation in svg file? > > by ... uh, wait, didn't i say "named objects", like in "every object in > an svg file can be given an id"? See below section about invisible port > > I suppose using http://www.w3.org/TR/SVGMobile12/extend.html > > slight overkill Ok we agree > > And the question taht could be raised is why not therefore using this > > mechanism for property and something else. > > because it would be backwards, maybe? Here also > > > > I agree that port need to be defined in the svg file. But is a only > > > > graphical. > > > > > > i completely agree. coordinates are graphical, though. > > > > No coordinate are not graphical. Sorry we do not agree. > !?!? > how could a coordinate into a graphics *not* be graphical? It is not graphics in the sense that it doesn't draw anything. For me=20 cordinate is a pair of float nothing more. > > > the right thing is declaring named ports in the part definition and > > > having appropriately named objects in the svg file. > > > > I do not agree with you because it is really heacy weight to parse svg > > for retrying port. > > i doubt that re-parsing small svg files (the symbols aren't going to be > particularly big by any means) would have any significant impact. also, > you can have your "compiler" put the data into some more accessible > location. it might even be that you can use > QSvgRenderer::boundsOnElement directly. > and anyway - where has "prefer correctness and scalability against > performance" suddenly gone? I agree with you with about "prefer correctness and scalability against performance" suddenly gone? Sometime I am stupid. It is not really a good= =20 argument. > > And as I say before I know some schematic (again in the norm) of > > component where the port is nowhere (ie not linked to any graphical > > element). Therefore your approach do not work. > > wow. and i thought one could do such completely unthinkable things as > overlaying the bounding rect of a symbol with a transparent zero-size > element and do other obvious absurdities. stupid me. ;) I do not understand what you means. I do not know if it is humor or reality= =2E=20 Yes norm is often stupid, Perhaps you are misunderstanding. Sorry for my ba= d=20 english. That I would say by not linked to any graphical element is that they are no= =20 wire or circle or graphical element to anchor the port in the schematic.=20 Yes zero-size element will work, but it is not really pretty (from my point= of=20 view, but I agree it is a matter of taste) I have also a new argument that is vhdl component. We do not know by advanc= e=20 where how many port a vhdl component will have and where the user will put= =20 the port. Therefore It will be better to add port in the component=20 description and not in the graphical stuff. Thus we could reuse the same sv= g=20 file for each vhdl component even if we do not know the number of port. > > Actually the problem is that when we add a component in core (usually > > in C++) > > =3D> plugin No core is coded in std c++ not with kde. The goal is to run the core in a = big=20 computer without any graphical unit. Sorry but no qt in the core. I push=20 really hard to include ATLAS or fwftt but no graphical, not useful stuff in= =20 core please... > > > we must code somtehing (in C++) in the gui that code for the schematic > > #define something I do not understand, sorry > > > and the translation layer schematic netlist. > > as this is a rather cheap procedure that needs to be done once when > starting a simulation, you can easily use QtScript embedded into the xml > file. > > > > The medium term goal is to implement a auxilarry program that will > > > > group all the component database in a single file. > > > > > > a cache works for the xml and svg files, but not for plugins if you > > > chose to go with them. > > > > It is not a cache it is a program that will create at installation one > > whole file from a lot of little fiel creating therefore a database. > > a cache is more flexible - it needs no special handing at installation > time, particularly when the user installs 3rd party components later. They will have a cache and a compiler in the medium term. Why not take both= of=20 them?=20 And about special handling when you add new tex file in your system you nee= d=20 to run texhash. When you add some library in spice you need to register it,= =20 etc. Moreover the compiler pass will be optionnal, you could use non compil= ed=20 component but it will be slower. Compiler will mainly be used for=20 > > A little bit like a compiler. > > yeah. for aggregating plugins you'd need a linker, though. :D Regards Bastien =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Oswald B. <os...@kd...> - 2007-11-05 12:44:14
|
On Mon, Nov 05, 2007 at 11:20:39AM +0100, Bastien ROUCARIES wrote: > Le lundi 5 novembre 2007, Oswald Buddenhagen a écrit : > Please do not trim CC > > On Sun, Nov 04, 2007 at 06:29:53PM +0100, Bastien ROUCARIES wrote: > > > Le dimanche 4 novembre 2007, Oswald Buddenhagen a écrit : > > > > having coordinates on the outside that point into the svg is just > > > > plain bad style. > > > > > > Sorry but taste is not a technical argument :-) > > > > this isn't about taste, but basic software design principles. > > I am really sorry but taste and basic software principles are like relativity > they are relative :-) > For instance when I program a PIC I love self modifying code. But when > I program in C++ on linux I think it is overkill and bad taste. > SMC it is certainly a funny exercise and on µCs it might be actually justified due to being the most efficient solution (heck, JITs are nothing else than SMC), but it is still a nightmare to understand, debug, maintain, etc. and therefore simply bad style. > Another instance is the linus torvarld vs Tanenbaum flame, etc etc... > that discussion was also about the tradeoff between the theoretically better design and what reality mandates. in our case there is no tradeoff, though. > > > > > I agree that port need to be defined in the svg file. But is a only > > > > > graphical. > > > > > > > > i completely agree. coordinates are graphical, though. > > > > > > No coordinate are not graphical. Sorry we do not agree. > > !?!? > > how could a coordinate into a graphics *not* be graphical? > > It is not graphics in the sense that it doesn't draw anything. For me > cordinate is a pair of float nothing more. > this simply doesn't make sense. the coordinates describe locations in the graphics. without the graphics, they are meaningless. if the graphics changes (even just the size), they lose meaning. how can you seriously not consider them inherently bound to the graphics? > > > And as I say before I know some schematic (again in the norm) of > > > component where the port is nowhere (ie not linked to any graphical > > > element). Therefore your approach do not work. > > > > wow. and i thought one could do such completely unthinkable things as > > overlaying the bounding rect of a symbol with a transparent zero-size > > element and do other obvious absurdities. stupid me. ;) > > I do not understand what you means. I do not know if it is humor or reality. > that was glaring sarcasm. > That I would say by not linked to any graphical element is that they are no > wire or circle or graphical element to anchor the port in the schematic. > Yes zero-size element will work, but it is not really pretty (from my > point of view, but I agree it is a matter of taste) > it is pretty, because it follows the principle of putting data where it belongs. it simply makes working with it nicer. > I have also a new argument that is vhdl component. We do not know by advance > where how many port a vhdl component will have and where the user will put > the port. Therefore It will be better to add port in the component > description and not in the graphical stuff. Thus we could reuse the same svg > file for each vhdl component even if we do not know the number of port. > you don't need to actually use every declared port "docking point". you could also have several sets of "docking points" for different utilizations. > > > Actually the problem is that when we add a component in core > > > (usually in C++) > > > > => plugin > > No core is coded in std c++ not with kde. The goal is to run the core > in a big computer without any graphical unit. Sorry but no qt in the > core. > what have plugins to do with qt? it sure is simpler with QLibrary, but there are other plain c++ libs that support dynamic loading. the plain c solution is libtool + libltdl, but that's quite a cruch and not windows-compatible. > > > we must code somtehing (in C++) in the gui that code for the schematic > > > > #define something > > I do not understand, sorry > *what* needs to be coded? "something" is a tad vague, you know. > > > > > The medium term goal is to implement a auxilarry program that > > > > > will group all the component database in a single file. > > > > > > > > a cache works for the xml and svg files, but not for plugins if > > > > you chose to go with them. > > > > > > It is not a cache it is a program that will create at installation > > > one whole file from a lot of little fiel creating therefore a > > > database. > > > > a cache is more flexible - it needs no special handing at > > installation time, particularly when the user installs 3rd party > > components later. > > They will have a cache and a compiler in the medium term. Why not take > both of them? > why have two parallel solutions for the same problem? > And about special handling when you add new tex file in your system > you need to run texhash. When you add some library in spice you need > to register it, etc. > a central store is sure more efficient than per-user caches. otoh, it doesn't help with extensions that users install into their $HOMEs. you could have a cascaded cache, with the central part being created by a setuid helper. anyway - optimizations ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Lisandro
<per...@gm...> - 2007-11-05 12:52:36
|
El Lunes 05 Noviembre 2007, Oswald Buddenhagen escribi=F3: [snip] > > No core is coded in std c++ not with kde. The goal is to run the core > > in a big computer without any graphical unit. Sorry but no qt in the > > core. > > what have plugins to do with qt? it sure is simpler with QLibrary, but > there are other plain c++ libs that support dynamic loading. > the plain c solution is libtool + libltdl, but that's quite a cruch and > not windows-compatible. Just for the record: Qt doesn't mean "GUI only". I have done a simulation=20 program for a PhD thesis with Qt-Core, all console based, no GUIs implicate= d. It turned out to be very helpful and still multiplatform. Regards, Lisandro. =2D-=20 Wiki is not WysiWyg. It's an intelligence test of sorts to be able to edit a wiki page. It's not rocket science, but it doesn't appeal to the VideoAddicts. If it doesn't appeal, they don't participate, which leaves those of us who read and write to get on with rational discourse. http://www.c2.com/cgi/wiki?WhyWikiWorks Lisandro Dami=E1n Nicanor P=E9rez Meyer http://perezmeyer.com.ar/ #bblug irc.freenode.net |
From: Bastien R. <rou...@gm...> - 2007-11-05 13:24:53
|
Le lundi 5 novembre 2007, Lisandro Dami=E1n Nicanor P=E9rez Meyer a =E9crit= =A0: > El Lunes 05 Noviembre 2007, Oswald Buddenhagen escribi=F3: > [snip] > > > > No core is coded in std c++ not with kde. The goal is to run the core > > > in a big computer without any graphical unit. Sorry but no qt in the > > > core. > > > > what have plugins to do with qt? it sure is simpler with QLibrary, but > > there are other plain c++ libs that support dynamic loading. > > the plain c solution is libtool + libltdl, but that's quite a cruch and > > not windows-compatible. > > Just for the record: Qt doesn't mean "GUI only". I have done a simulation > program for a PhD thesis with Qt-Core, all console based, no GUIs > implicated. I agree from a pratical point of view but problem is size of qt library and= =20 dependancy at least: ldd /usr/lib/libqt-mt.so libfontconfig.so.1 =3D> /usr/lib/libfontconfig.so.1 (0x00002b649a39= c000) libaudio.so.2 =3D> /usr/lib/libaudio.so.2 (0x00002b649a4d0000) libXt.so.6 =3D> /usr/lib/libXt.so.6 (0x00002b649a6e9000) libjpeg.so.62 =3D> /usr/lib/libjpeg.so.62 (0x00002b649a94a000) libpng12.so.0 =3D> /usr/lib/libpng12.so.0 (0x00002b649ab6c000) libz.so.1 =3D> /usr/lib/libz.so.1 (0x00002b649ad91000) libXi.so.6 =3D> /usr/lib/libXi.so.6 (0x00002b649afa8000) libXrender.so.1 =3D> /usr/lib/libXrender.so.1 (0x00002b649b1b1000) libXrandr.so.2 =3D> /usr/lib/libXrandr.so.2 (0x00002b649b3bb000) libXcursor.so.1 =3D> /usr/lib/libXcursor.so.1 (0x00002b649b5c2000) libXinerama.so.1 =3D> /usr/lib/libXinerama.so.1 (0x00002b649b7cc000) libXft.so.2 =3D> /usr/lib/libXft.so.2 (0x00002b649b8cf000) libfreetype.so.6 =3D> /usr/lib/libfreetype.so.6 (0x00002b649b9e2000) libXext.so.6 =3D> /usr/lib/libXext.so.6 (0x00002b649bc5f000) libX11.so.6 =3D> /usr/lib/libX11.so.6 (0x00002b649bd71000) libSM.so.6 =3D> /usr/lib/libSM.so.6 (0x00002b649bf7a000) libICE.so.6 =3D> /usr/lib/libICE.so.6 (0x00002b649c182000) libdl.so.2 =3D> /lib/libdl.so.2 (0x00002b649c39e000) libpthread.so.0 =3D> /lib/libpthread.so.0 (0x00002b649c5a2000) libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x00002b649c7bd000) libm.so.6 =3D> /lib/libm.so.6 (0x00002b649cac6000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x00002b649cd47000) libc.so.6 =3D> /lib/libc.so.6 (0x00002b649cf55000) libexpat.so.1 =3D> /usr/lib/libexpat.so.1 (0x00002b649d2ad000) libXfixes.so.3 =3D> /usr/lib/libXfixes.so.3 (0x00002b649d4d0000) libXau.so.6 =3D> /usr/lib/libXau.so.6 (0x00002b649d5d6000) libXdmcp.so.6 =3D> /usr/lib/libXdmcp.so.6 (0x00002b649d6d8000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) And losting memory for this is not really nice wheras (we could use a lot o= f=20 memory in matrix computation) ldd /usr/bin/qucsator libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x00002b0fd0a9e000) libm.so.6 =3D> /lib/libm.so.6 (0x00002b0fd0da6000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x00002b0fd1027000) libc.so.6 =3D> /lib/libc.so.6 (0x00002b0fd1235000) /lib64/ld-linux-x86-64.so.2 (0x00002b0fd0880000) Better isn't it? So no using qt in core is not really nice.=20 > It turned out to be very helpful and still multiplatform. > > Regards, Lisandro. =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Lisandro
<per...@gm...> - 2007-11-05 14:16:18
|
El Lunes 05 Noviembre 2007, escribi=F3: > Le lundi 5 novembre 2007, Lisandro Dami=E1n Nicanor P=E9rez Meyer a =E9cr= it=A0: > > El Lunes 05 Noviembre 2007, Oswald Buddenhagen escribi=F3: > > [snip] > > > > > > No core is coded in std c++ not with kde. The goal is to run the co= re > > > > in a big computer without any graphical unit. Sorry but no qt in the > > > > core. > > > > > > what have plugins to do with qt? it sure is simpler with QLibrary, but > > > there are other plain c++ libs that support dynamic loading. > > > the plain c solution is libtool + libltdl, but that's quite a cruch a= nd > > > not windows-compatible. > > > > Just for the record: Qt doesn't mean "GUI only". I have done a simulati= on > > program for a PhD thesis with Qt-Core, all console based, no GUIs > > implicated. > > I agree from a pratical point of view but problem is size of qt library a= nd > dependancy at least: > ldd /usr/lib/libqt-mt.so > libfontconfig.so.1 =3D> /usr/lib/libfontconfig.so.1 > (0x00002b649a39c000) libaudio.so.2 =3D> /usr/lib/libaudio.so.2 > (0x00002b649a4d0000) libXt.so.6 =3D> /usr/lib/libXt.so.6 (0x00002b649a6e9= 000) > libjpeg.so.62 =3D> /usr/lib/libjpeg.so.62 (0x00002b649a94a000) > libpng12.so.0 =3D> /usr/lib/libpng12.so.0 (0x00002b649ab6c000) > libz.so.1 =3D> /usr/lib/libz.so.1 (0x00002b649ad91000) > libXi.so.6 =3D> /usr/lib/libXi.so.6 (0x00002b649afa8000) > libXrender.so.1 =3D> /usr/lib/libXrender.so.1 (0x00002b649b1b1000) > libXrandr.so.2 =3D> /usr/lib/libXrandr.so.2 (0x00002b649b3bb000) > libXcursor.so.1 =3D> /usr/lib/libXcursor.so.1 (0x00002b649b5c2000) > libXinerama.so.1 =3D> /usr/lib/libXinerama.so.1 (0x00002b649b7cc0= 00) > libXft.so.2 =3D> /usr/lib/libXft.so.2 (0x00002b649b8cf000) > libfreetype.so.6 =3D> /usr/lib/libfreetype.so.6 (0x00002b649b9e20= 00) > libXext.so.6 =3D> /usr/lib/libXext.so.6 (0x00002b649bc5f000) > libX11.so.6 =3D> /usr/lib/libX11.so.6 (0x00002b649bd71000) > libSM.so.6 =3D> /usr/lib/libSM.so.6 (0x00002b649bf7a000) > libICE.so.6 =3D> /usr/lib/libICE.so.6 (0x00002b649c182000) > libdl.so.2 =3D> /lib/libdl.so.2 (0x00002b649c39e000) > libpthread.so.0 =3D> /lib/libpthread.so.0 (0x00002b649c5a2000) > libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x00002b649c7bd000) > libm.so.6 =3D> /lib/libm.so.6 (0x00002b649cac6000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x00002b649cd47000) > libc.so.6 =3D> /lib/libc.so.6 (0x00002b649cf55000) > libexpat.so.1 =3D> /usr/lib/libexpat.so.1 (0x00002b649d2ad000) > libXfixes.so.3 =3D> /usr/lib/libXfixes.so.3 (0x00002b649d4d0000) > libXau.so.6 =3D> /usr/lib/libXau.so.6 (0x00002b649d5d6000) > libXdmcp.so.6 =3D> /usr/lib/libXdmcp.so.6 (0x00002b649d6d8000) > /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) > > > And losting memory for this is not really nice wheras (we could use a lot > of memory in matrix computation) > ldd /usr/bin/qucsator > libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x00002b0fd0a9e000) > libm.so.6 =3D> /lib/libm.so.6 (0x00002b0fd0da6000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x00002b0fd1027000) > libc.so.6 =3D> /lib/libc.so.6 (0x00002b0fd1235000) > /lib64/ld-linux-x86-64.so.2 (0x00002b0fd0880000) > > Better isn't it? > > So no using qt in core is not really nice. I don't know if using just qtcore will load all that, but I see your point = :-) Please, do not mail me in private, I'm in the list. Regards, Lisandro. =2D-=20 =46AQ del peque=F1o tomi: P- =BFQue cuernos es una particion swap? R- Es un coso en el disco que tenes que crear para que cuando se apachache la memoria RAM el nucelo no te entre a matar procesos como desaforado y pierdas todas las peliculas XXX que te estas bajando por el Azureus cuando te mate la maquina virtual de java por ser el proceso que mas consume o que Windos Vista se que cuelge cuando le activas las transparecias al relojito... Textual de Mart=EDn "El Ruso" Ribelotta Lisandro Dami=E1n Nicanor P=E9rez Meyer http://perezmeyer.com.ar/ #bblug irc.freenode.net |
From: Bastien R. <rou...@gm...> - 2007-11-05 13:31:26
|
Le lundi 5 novembre 2007, Oswald Buddenhagen a =E9crit=A0: > On Mon, Nov 05, 2007 at 11:20:39AM +0100, Bastien ROUCARIES wrote: > > Le lundi 5 novembre 2007, Oswald Buddenhagen a =E9crit=A0: > > Please do not trim CC > > > > > On Sun, Nov 04, 2007 at 06:29:53PM +0100, Bastien ROUCARIES wrote: > > > > Le dimanche 4 novembre 2007, Oswald Buddenhagen a =E9crit : > > > > > having coordinates on the outside that point into the svg is just > > > > > plain bad style. > > > > > > > > Sorry but taste is not a technical argument :-) > > > > > > this isn't about taste, but basic software design principles. > > > > I am really sorry but taste and basic software principles are like > > relativity they are relative :-) > > > > For instance when I program a PIC I love self modifying code. But when > > I program in C++ on linux I think it is overkill and bad taste. > > SMC it is certainly a funny exercise and on =B5Cs it might be actually > justified due to being the most efficient solution (heck, JITs are > nothing else than SMC), but it is still a nightmare to understand, > debug, maintain, etc. and therefore simply bad style. > > > Another instance is the linus torvarld vs Tanenbaum flame, etc etc... > > that discussion was also about the tradeoff between the theoretically > better design and what reality mandates. > > in our case there is no tradeoff, though. No comment because I think we have two different philosophy, I like C becau= se=20 it allow to shoot me in my foot. > > > > > > I agree that port need to be defined in the svg file. But is a > > > > > > only graphical. > > > > > > > > > > i completely agree. coordinates are graphical, though. > > > > > > > > No coordinate are not graphical. Sorry we do not agree. > > > > > > !?!? > > > how could a coordinate into a graphics *not* be graphical? > > > > It is not graphics in the sense that it doesn't draw anything. For me > > cordinate is a pair of float nothing more. > > this simply doesn't make sense. the coordinates describe locations in > the graphics. without the graphics, they are meaningless. if the > graphics changes (even just the size), they lose meaning. how can you > seriously not consider them inherently bound to the graphics? Even if we include it in the svg file we will need to do this kind of=20 computation because port are defined relatively wheras they are used=20 globally. Port are used for wiring that need global coordinate, wheras port coordiant= e=20 are local to your composent schematic. I say only that the property that we= =20 call port are only used for wiring, no reprensenting a port in the schemati= c=20 of the component > > > > And as I say before I know some schematic (again in the norm) of > > > > component where the port is nowhere (ie not linked to any graphical > > > > element). Therefore your approach do not work. > > > > > > wow. and i thought one could do such completely unthinkable things as > > > overlaying the bounding rect of a symbol with a transparent zero-size > > > element and do other obvious absurdities. stupid me. ;) > > > > I do not understand what you means. I do not know if it is humor or > > reality. > > that was glaring sarcasm. ok=20 > > That I would say by not linked to any graphical element is that they are > > no wire or circle or graphical element to anchor the port in the > > schematic. > > > > Yes zero-size element will work, but it is not really pretty (from my > > point of view, but I agree it is a matter of taste) > > it is pretty, because it follows the principle of putting data where it > belongs. it simply makes working with it nicer. If you prefer but I say it will be overengineered > > I have also a new argument that is vhdl component. We do not know by > > advance where how many port a vhdl component will have and where the us= er > > will put the port. Therefore It will be better to add port in the > > component description and not in the graphical stuff. Thus we could reu= se > > the same svg file for each vhdl component even if we do not know the > > number of port. > > you don't need to actually use every declared port "docking point". you > could also have several sets of "docking points" for different > utilizations. Did you use something like cadense ADS or even xlinx (do not take it as an= =20 offence it is only in order to get away the language barrier and engineerin= g=20 field barrier. We know the number of port used by vhdl parsing the vhdl file that is an ad= a=20 like language used for hadware generation. Therefore the could not put=20 docking point by advance. That is the problem and I am open to discussions > > > > Actually the problem is that when we add a component in core > > > > (usually in C++) > > > > > > =3D> plugin > > > > No core is coded in std c++ not with kde. The goal is to run the core > > in a big computer without any graphical unit. Sorry but no qt in the > > core. > > what have plugins to do with qt? it sure is simpler with QLibrary, but > there are other plain c++ libs that support dynamic loading. > the plain c solution is libtool + libltdl, but that's quite a cruch and > not windows-compatible. We try to avoid dynamic loading for this reason. I am even thinking instead= of=20 use dynamical library in windows to use static library (I know ugly but at= =20 least it will work). > > > > we must code somtehing (in C++) in the gui that code for the > > > > schematic > > > > > > #define something > > > > I do not understand, sorry > > *what* needs to be coded? "something" is a tad vague, you know. Ok now the solution is to code the graphics in C using arc line and all qt= =20 stuff, we code also list of properties and a lot of code to generate in fac= t=20 the component widget. We want to offer an abstraction layer that will need = to=20 add only a xml and a svg file each time we add a component and will avoid a= =20 recompilation.=20 > > > > > > The medium term goal is to implement a auxilarry program that > > > > > > will group all the component database in a single file. > > > > > > > > > > a cache works for the xml and svg files, but not for plugins if > > > > > you chose to go with them. > > > > > > > > It is not a cache it is a program that will create at installation > > > > one whole file from a lot of little fiel creating therefore a > > > > database. > > > > > > a cache is more flexible - it needs no special handing at > > > installation time, particularly when the user installs 3rd party > > > components later. > > > > They will have a cache and a compiler in the medium term. Why not take > > both of them? > > why have two parallel solutions for the same problem? Because one is local scale (caching) wheras the second is global scale=20 (compile). > > And about special handling when you add new tex file in your system > > you need to run texhash. When you add some library in spice you need > > to register it, etc. > > a central store is sure more efficient than per-user caches. > otoh, it doesn't help with extensions that users install into their > $HOMEs. Exactly central store will be compiled at installation. But user could=20 compile their own project using the compiler locally > you could have a cascaded cache, with the central part being created by > a setuid helper. > anyway - optimizations ... No setuid needed because it will be done at installation for global symbol.= =20 And it is optimization About the whole discution do you better understand what you want to do? Do = not=20 take it as an offence but I think I use bad wording so a reformulation on=20 your side will be welcome for my understanding. Regards =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Oswald B. <os...@kd...> - 2007-11-05 13:32:06
|
On Mon, Nov 05, 2007 at 02:24:50PM +0100, Bastien ROUCARIES wrote: > Le lundi 5 novembre 2007, Lisandro Damián Nicanor Pérez Meyer a écrit: > > Just for the record: Qt doesn't mean "GUI only". I have done a > > simulation program for a PhD thesis with Qt-Core, all console based, > > no GUIs implicated. > > I agree from a pratical point of view but problem is size of qt > library and dependancy at least: > ldd /usr/lib/libqt-mt.so > yeah, very fair to use qt 3's dep list for a console application. > And losting memory for this is not really nice wheras (we could use a > lot of memory in matrix computation) > i can assure you that the memory used by qtcore doesn't come anywhere near being significant compared to serious computations' requirements. oh, and what was this part about optimization, extensibility, scalability, architecture? ;) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Bastien R. <rou...@gm...> - 2007-11-05 13:55:12
|
Le lundi 5 novembre 2007, Oswald Buddenhagen a =E9crit=A0: > On Mon, Nov 05, 2007 at 02:24:50PM +0100, Bastien ROUCARIES wrote: > > Le lundi 5 novembre 2007, Lisandro Dami=E1n Nicanor P=E9rez Meyer a =E9= crit: > > > Just for the record: Qt doesn't mean "GUI only". I have done a > > > simulation program for a PhD thesis with Qt-Core, all console based, > > > no GUIs implicated. > > > > I agree from a pratical point of view but problem is size of qt > > library and dependancy at least: > > ldd /usr/lib/libqt-mt.so > > yeah, very fair to use qt 3's dep list for a console application. Is it humour? Because I know some grid computer without qt... > > And losting memory for this is not really nice wheras (we could use a > > lot of memory in matrix computation) > > i can assure you that the memory used by qtcore doesn't come anywhere > near being significant compared to serious computations' requirements. > oh, and what was this part about optimization, extensibility, > scalability, architecture? ;) We talk about core and not gui. When I code for core I care a lot about=20 performance, And about size of lib I invite you to do some computation using /proc on li= nux=20 comparing shared size with and without qt... =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Oswald B. <os...@kd...> - 2007-11-05 13:58:33
|
On Mon, Nov 05, 2007 at 02:31:25PM +0100, Bastien ROUCARIES wrote: > Le lundi 5 novembre 2007, Oswald Buddenhagen a écrit : > > On Mon, Nov 05, 2007 at 11:20:39AM +0100, Bastien ROUCARIES wrote: > > > Le lundi 5 novembre 2007, Oswald Buddenhagen a écrit : > > > > On Sun, Nov 04, 2007 at 06:29:53PM +0100, Bastien ROUCARIES wrote: > > > > > Le dimanche 4 novembre 2007, Oswald Buddenhagen a écrit : > > > It is not graphics in the sense that it doesn't draw anything. For me > > > cordinate is a pair of float nothing more. > > > > this simply doesn't make sense. the coordinates describe locations in > > the graphics. without the graphics, they are meaningless. if the > > graphics changes (even just the size), they lose meaning. how can you > > seriously not consider them inherently bound to the graphics? > > Even if we include it in the svg file we will need to do this kind of > computation because port are defined relatively wheras they are used > globally. > and? the point about svg is that it is *vector* graphics. you have a tree structure with relative positions, and you leave it that way up to the point where you actually paint it on a raster device. only then you have absolute coordinates which you can communicate to the outside. > > you don't need to actually use every declared port "docking point". > > you could also have several sets of "docking points" for different > > utilizations. > > We know the number of port used by vhdl parsing the vhdl file that is > an ada like language used for hadware generation. > fine. > Therefore the could not put docking point by advance. > i have to wonder by which logic you arrive to this conclusion from the presented facts ... > > > > > we must code somtehing (in C++) in the gui that code for the > > > > > schematic > > > > *what* needs to be coded? "something" is a tad vague, you know. > > Ok now the solution is to code the graphics in C using arc line and > all qt stuff, we code also list of properties and a lot of code to > generate in fact the component widget. We want to offer an abstraction > layer that will need to add only a xml and a svg file each time we add > a component and will avoid a recompilation. > good. that doesn't add anything new though, so i wonder why you brought this in in the first place. ;) > > > They will have a cache and a compiler in the medium term. Why not > > > take both of them? > > > > why have two parallel solutions for the same problem? > > Because one is local scale (caching) wheras the second is global scale > (compile). > why do you create an artificial distinction here? it's the same process, just with different locality. > About the whole discution do you better understand what you want to > do? Do not take it as an offence but I think I use bad wording so a > reformulation on your side will be welcome for my understanding. > this paragraph is a complete mystery to me. i gather it is about missing understanding though, which sort of makes it a self-fulfilling prophecy. :-D -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Oswald B. <os...@kd...> - 2007-11-05 14:14:38
|
On Mon, Nov 05, 2007 at 02:55:11PM +0100, Bastien ROUCARIES wrote: > Le lundi 5 novembre 2007, Oswald Buddenhagen a écrit : > > On Mon, Nov 05, 2007 at 02:24:50PM +0100, Bastien ROUCARIES wrote: > > > Le lundi 5 novembre 2007, Lisandro Damián Nicanor Pérez Meyer a écrit: > > > > Just for the record: Qt doesn't mean "GUI only". I have done a > > > > simulation program for a PhD thesis with Qt-Core, all console based, > > > > no GUIs implicated. > > > > > > I agree from a pratical point of view but problem is size of qt > > > library and dependancy at least: > > > ldd /usr/lib/libqt-mt.so > > > > yeah, very fair to use qt 3's dep list for a console application. > Is it humour? Because I know some grid computer without qt... > $ ldd /opt/kde4/lib/libQtCore.so /lib/ld-linux.so.2 (0x75555000) linux-gate.so.1 => (0xffffe000) libz.so.1 => /usr/lib/libz.so.1 (0xa7e5f000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xa7e5b000) librt.so.1 => /lib/librt.so.1 (0xa7e51000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xa7db1000) libpthread.so.0 => /lib/libpthread.so.0 (0xa7d9a000) libdl.so.2 => /lib/libdl.so.2 (0xa7d96000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xa7cab000) libm.so.6 => /lib/libm.so.6 (0xa7c85000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xa7c79000) libc.so.6 => /lib/libc.so.6 (0xa7b31000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xa7b0b000) if you think that installing a separate qtcore is impossible (even though installing qucsator *is* possible?!), you can compile it statically. > > > And losting memory for this is not really nice wheras (we could > > > use a lot of memory in matrix computation) > > > > i can assure you that the memory used by qtcore doesn't come > > anywhere near being significant compared to serious computations' > > requirements. > > And about size of lib I invite you to do some computation using /proc > on linux comparing shared size with and without qt... > imagine, i know the requirements of qt pretty well. now compare a few megs of *shared* memory with some tens of megs of *private* memory per instance. and i really have to wonder why you seriously consider a few megs when talking about systems that have hundreds of gigs in total. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Bastien R. <rou...@gm...> - 2007-11-05 14:37:31
|
Le lundi 5 novembre 2007, Oswald Buddenhagen a =E9crit=A0: > On Mon, Nov 05, 2007 at 02:55:11PM +0100, Bastien ROUCARIES wrote: > > Le lundi 5 novembre 2007, Oswald Buddenhagen a =E9crit=A0: > > > On Mon, Nov 05, 2007 at 02:24:50PM +0100, Bastien ROUCARIES wrote: > > > > Le lundi 5 novembre 2007, Lisandro Dami=E1n Nicanor P=E9rez Meyer a= =E9crit: > > > > > Just for the record: Qt doesn't mean "GUI only". I have done a > > > > > simulation program for a PhD thesis with Qt-Core, all console > > > > > based, no GUIs implicated. > > > > > > > > I agree from a pratical point of view but problem is size of qt > > > > library and dependancy at least: > > > > ldd /usr/lib/libqt-mt.so > > > > > > yeah, very fair to use qt 3's dep list for a console application. > > > > Is it humour? Because I know some grid computer without qt... > > $ ldd /opt/kde4/lib/libQtCore.so > /lib/ld-linux.so.2 (0x75555000) > linux-gate.so.1 =3D> (0xffffe000) > libz.so.1 =3D> /usr/lib/libz.so.1 (0xa7e5f000) > libgthread-2.0.so.0 =3D> /usr/lib/libgthread-2.0.so.0 (0xa7e5b000) > librt.so.1 =3D> /lib/librt.so.1 (0xa7e51000) > libglib-2.0.so.0 =3D> /usr/lib/libglib-2.0.so.0 (0xa7db1000) > libpthread.so.0 =3D> /lib/libpthread.so.0 (0xa7d9a000) > libdl.so.2 =3D> /lib/libdl.so.2 (0xa7d96000) > libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0xa7cab000) > libm.so.6 =3D> /lib/libm.so.6 (0xa7c85000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0xa7c79000) > libc.so.6 =3D> /lib/libc.so.6 (0xa7b31000) > libpcre.so.3 =3D> /usr/lib/libpcre.so.3 (0xa7b0b000) > > if you think that installing a separate qtcore is impossible (even > though installing qucsator *is* possible?!), you can compile it > statically. Yes because they have libc++ and libc installed. Do you think it will be=20 possible to run a qt program without X??? I do not think so.. > > > > And losting memory for this is not really nice wheras (we could > > > > use a lot of memory in matrix computation) > > > > > > i can assure you that the memory used by qtcore doesn't come > > > anywhere near being significant compared to serious computations' > > > requirements. > > > > And about size of lib I invite you to do some computation using /proc > > on linux comparing shared size with and without qt... > > imagine, i know the requirements of qt pretty well. > now compare a few megs of *shared* memory with some tens of megs of > *private* memory per instance. and i really have to wonder why you > seriously consider a few megs when talking about systems that have > hundreds of gigs in total. Because I care about TLB miss, I care about to be cache hot and I care abou= t=20 efficiency. I care to not load fonts like now for qt. Etc etc...=20 =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Lisandro
<per...@gm...> - 2007-11-05 14:51:26
|
El Lunes 05 Noviembre 2007, Bastien ROUCARIES escribi=F3: [snip] > Yes because they have libc++ and libc installed. Do you think it will be > possible to run a qt program without X??? I do not think so.. It is. As I said before, using just QtCore you don't use anything graphical. And, by the way (but going a little bit OT), Qt works perfectly on=20 framebuffer. Check: http://www.qde.bblug.usla.org.ar/qde/images/ =2D-=20 I was married by a judge. I should have asked for a jury. -- Groucho Marx Lisandro Dami=E1n Nicanor P=E9rez Meyer http://perezmeyer.com.ar/ #bblug irc.freenode.net |
From: Bastien R. <rou...@gm...> - 2007-11-05 14:38:03
|
Le lundi 5 novembre 2007, Oswald Buddenhagen a =E9crit=A0: > On Mon, Nov 05, 2007 at 02:31:25PM +0100, Bastien ROUCARIES wrote: > > Le lundi 5 novembre 2007, Oswald Buddenhagen a ?crit?: > > > On Mon, Nov 05, 2007 at 11:20:39AM +0100, Bastien ROUCARIES wrote: > > > > Le lundi 5 novembre 2007, Oswald Buddenhagen a ?crit?: > > > > > On Sun, Nov 04, 2007 at 06:29:53PM +0100, Bastien ROUCARIES wrote: > > > > > > Le dimanche 4 novembre 2007, Oswald Buddenhagen a ?crit : > > > > > > > > It is not graphics in the sense that it doesn't draw anything. For = me > > > > cordinate is a pair of float nothing more. > > > > > > this simply doesn't make sense. the coordinates describe locations in > > > the graphics. without the graphics, they are meaningless. if the > > > graphics changes (even just the size), they lose meaning. how can you > > > seriously not consider them inherently bound to the graphics? > > > > Even if we include it in the svg file we will need to do this kind of > > computation because port are defined relatively wheras they are used > > globally. > > and? the point about svg is that it is *vector* graphics. you have a > tree structure with relative positions, and you leave it that way up to > the point where you actually paint it on a raster device. only then you > have absolute coordinates which you can communicate to the outside. > > > > you don't need to actually use every declared port "docking point". > > > you could also have several sets of "docking points" for different > > > utilizations. > > > > We know the number of port used by vhdl parsing the vhdl file that is > > an ada like language used for hadware generation. > > fine. > > > Therefore the could not put docking point by advance. > > i have to wonder by which logic you arrive to this conclusion from the > presented facts ... Because the programmer (us) do not know by advance the position and number = of=20 port in a vhdl block schematic. The standard say we could have (minimum)=20 65535 port. And the number of port depend of the vhdl file > > > > > > we must code somtehing (in C++) in the gui that code for the > > > > > > schematic > > > > > > *what* needs to be coded? "something" is a tad vague, you know. > > > > Ok now the solution is to code the graphics in C using arc line and > > all qt stuff, we code also list of properties and a lot of code to > > generate in fact the component widget. We want to offer an abstraction > > layer that will need to add only a xml and a svg file each time we add > > a component and will avoid a recompilation. > > good. that doesn't add anything new though, so i wonder why you brought > this in in the first place. ;) > > > > > They will have a cache and a compiler in the medium term. Why not > > > > take both of them? > > > > > > why have two parallel solutions for the same problem? > > > > Because one is local scale (caching) wheras the second is global scale > > (compile). > > why do you create an artificial distinction here? it's the same process, > just with different locality. Because one is static and global (compiler) whereas the second is local and= =20 dynamic > > About the whole discution do you better understand what you want to > > do? Do not take it as an offence but I think I use bad wording so a > > reformulation on your side will be welcome for my understanding. > > this paragraph is a complete mystery to me. i gather it is about missing > understanding though, which sort of makes it a self-fulfilling prophecy. Ok often I invert us and you sorry about that, particularly when I do two o= r=20 three thing in the same time. Brain multhread is not really without danger I want to say that we spoke two different technical languages and come from= =20 two different engineering field. And I suppose we argue about=20 misunderstanding of the concept of schematic and components. BTW in order to check if you understand me I will welcome that you reword t= he=20 whole concept.=20 Thank you > :-D =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |
From: Gopala K. <kri...@gm...> - 2007-11-05 14:47:02
|
I am still not convinced on the opinions regarding port placement in the xml but i do have an idea. On one hand hooking port info in a svg seems to be a good method since there won't be any errors. I mean to say in some use cases the designer of the svg will be a different person than the xml coder and so there can be a misjudgment of the location of port. But port also needs different information like whether its analog or not, name attribute in some cases. These things clearly won't fit in an svg. So thinking this way suggests to have the ports described in a xml.. My idea is to marry both the svg and xml ;-) How about defining only the location of port in svg, and in xml we can refer to this ? This might resolve all the conflicts. And regarding plugins, its really difficult to take care of designing plugin infrastructure at this stage as we are really short of developers. I cant manage everything since i have to take care of my studies, my algorithm learnings, university mini projects.. Its very easy to say use "this" and "that" but when its comes to actual implementation its not so easy. Infact we are working on api documentation as well so that new developers might step in more easily. I request you not to discuss about core at this stage because we are very far from having a finished qt4 gui for qucs. Lets do it first. If you are really interested, you can start a new thread for the discussion. so that the respective responsible people can take care of :-) And regarding performance, we aren't shooting blind. We do have experience too.. That too using too much of memory(cache) to boost performance is not good either. We need to provide option for user whether to cache or not. We need make clever coding like sharing the common properties (I discovered QSharedData and friends to help me in this regard) I have doubt regarding vhdl. I could see most of components except vhdlfile component using known number of ports. Am i correct ? If that is the case, we can use the place holder mechanism and named ports technique , right ? Correct me if i am wrong. P.S: I have almost two weeks of holidays. Actually this is study holidays. But i have planned to devote atleast 4 hrs a day on qucs coding alone. Anybody interested to join me can mail me. -- Cheers, Gopala Krishna A |
From: Oswald B. <os...@kd...> - 2007-11-05 14:51:38
|
On Mon, Nov 05, 2007 at 03:37:03PM +0100, Bastien ROUCARIES wrote: > Le lundi 5 novembre 2007, Oswald Buddenhagen a écrit : > > if you think that installing a separate qtcore is impossible (even > > though installing qucsator *is* possible?!), you can compile it > > statically. > > Yes because they have libc++ and libc installed. > non-sequitor. > Do you think it will be possible to run a qt program without X??? I do > not think so.. > i don't think it is, i *know* it is. and it would be even with qt3. > > and i really have to wonder why you seriously consider a few megs > > when talking about systems that have hundreds of gigs in total. > > Because I care about TLB miss, I care about to be cache hot and I care > about efficiency. > fine. care for doing the math? some actual testing? i tell you that linking qt and using it for some high-level stuff like lib loading will not hurt performance in any way. only if you chose to use qt properties for parametrizing components things might be slightly worse due to objects being bigger for being qobject derived. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Bastien R. <rou...@gm...> - 2007-11-05 15:28:08
|
Le lundi 5 novembre 2007, Oswald Buddenhagen a =E9crit=A0: > On Mon, Nov 05, 2007 at 03:37:03PM +0100, Bastien ROUCARIES wrote: > > Le lundi 5 novembre 2007, Oswald Buddenhagen a =E9crit=A0: > > > if you think that installing a separate qtcore is impossible (even > > > though installing qucsator *is* possible?!), you can compile it > > > statically. > > > > Yes because they have libc++ and libc installed. > > non-sequitor. > > > Do you think it will be possible to run a qt program without X??? I do > > not think so.. > > i don't think it is, i *know* it is. and it would be even with qt3. > > > > and i really have to wonder why you seriously consider a few megs > > > when talking about systems that have hundreds of gigs in total. > > > > Because I care about TLB miss, I care about to be cache hot and I care > > about efficiency. > > fine. care for doing the math? some actual testing? i tell you that > linking qt and using it for some high-level stuff like lib loading will > not hurt performance in any way. only if you chose to use qt properties > for parametrizing components things might be slightly worse due to > objects being bigger for being qobject derived. To kill this discussion, because flame war are boring=20 first item todo list of core is harmonic balance and not plugin. Sorry.... =2D-=20 "ROUCARIES Bastien" roucaries.bastien+qucs@gmail.= com =2D------------------------------------------------------------------------= =2D----- DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED |