Re: [Qucs-devel] XML components and some doubts

[Bastien R. <rou...@gm...>]

Le mercredi 7 novembre 2007, Oswald Buddenhagen a =E9crit=A0:
> On Tue, Nov 06, 2007 at 11:08:39PM +0100, Bastien ROUCARIES wrote:
> > BTW i do not think qtscript is bad (cenceptually). But I think ECMA-262
> > is really a very good scientific language. [...]
> > Personnally (and it is personnal) I am really kind of python due to pys=
ci
> > module.
>
> you should really consider using kde as the platform - in this case, the
> kross scripting framework would come in handy. :-)

I know that the big force of qt is cross plateform. But I think also python=
 is=20
cross plateform (and swig will allow to create really easilly perl and pyth=
on=20
binding, why qt do not use swig is a mystery licence is not a reason becaus=
e=20
it is under BSD).=20

About qtscripting of qucs-gui it does not serve a big purpose because as th=
e=20
schematic file format is documented we could alway generate directly the=20
schematic code. What why I think qtscript is not worth the effort.

=46or filter plugin ECMA-262 is not really suitable because the only useful=
=20
stuff that will be of use is the arbitrary=20

> > > Regarding plugins, it doesn't serve any purpose of xmlizing the code.
> > > You can preserve the old code itself then!! Any other idea ?
>
> hey, i told you that i am not suggesting anything drastical. ;)
> this is only about modularization. a component would come as a set of
> files (probably in a tar-ball for 3rd-party parts) that make it up - a
> component description, a symbol, some (c++) code that implements its
> model (the core part) and some glue to make the gui be able to deal with
> the component in some way (this is where i brought scripting into the
> game).  while there is no pressing need to externalize standard
> components, it is simply architecturally cleaner to handle them the same
> way as 3rd-party components - and it tests the quality of the interface
> already.

Without any thing bad in my mind do you know the history of spice?

Allowing as you call plugin is not really good for our freedom. Spice was=20
killed for this kind of stuff. And moreover we expose to something like nvd=
ia=20
driver. People that will deny the GPL license of qucs.=20

Plugin is nice but not really good for us freedom. However I can think that=
=20
writing components in python could be a good idea. Even if it will not=20
preserve your plain freedom it will be sufficently slow to avoid direct=20
danger

> > About plugin I have talked about it with Vincent the guy we made the
> > filter plugin. It will be nice to use core or filter module as a librar=
y.
> > But qucs-core need to reentrant and it will pretty hard.
>
> this sounds odd. i guess one would rather make a library with some often
> used core functions that both the core itself and the plugins would use.

It has some advantage, particularly for real time simulation and automation=
=20
(in electrical engineering sense).

> > > We are thinking of using xslt to generate netlist. But still do you
> > > have any idea ?
> >
> > using xslt will have the advantage to get from the same xml source a
> > spice netlist a kicad netlist or a qucs netlist. And all the
> > articulation between core and gui will be based on only one file to
> > maintain :-)
>
> if xslt is powerful enough, it is certainly better suited than generic
> scripting.

XSLT is really powerfull :-) A little bit hard to understand but really nic=
e=20
and standard (w3m standard). To summerize you need to xml file, one is the=
=20
source and the second is a pattern of transformation rule for the first.=20
As XSLT is Turing complete you could get what you want from the first file =
:-)

Regards Bastien

=2D-=20

"ROUCARIES Bastien"
                                              roucaries.bastien+qucs@gmail.=
com
=2D------------------------------------------------------------------------=
=2D-----
DO NOT WRITE TO rou...@gm... OR BE BLACKLISTED