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=
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
Port are used for wiring that need global coordinate, wheras port coordiant=
are local to your composent schematic. I say only that the property that we=
call port are only used for wiring, no reprensenting a port in the schemati=
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.
> > 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=
> > 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=
> > 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
Did you use something like cadense ADS or even xlinx (do not take it as an=
offence it is only in order to get away the language barrier and engineerin=
We know the number of port used by vhdl parsing the vhdl file that is an ad=
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=
use dynamical library in windows to use static library (I know ugly but at=
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=
stuff, we code also list of properties and a lot of code to generate in fac=
the component widget. We want to offer an abstraction layer that will need =
add only a xml and a svg file each time we add a component and will avoid a=
> > > > > > 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
> > 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
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.=
And it is optimization
About the whole discution do you better understand what you want to do? Do =
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.
DO NOT WRITE TO roucaries.bastien+blackhole@... OR BE BLACKLISTED