Re: qucs parser

On Fri, Mar 16, 2012 at 12:38:53AM -0400, al davis wrote:
> In a way, I like the qucs approach that everything, including
> probes, is a netlist element.  A while back, I implemented a
> "meter" device that provides some new probes like "gain".

if a probe is a netlist element, would that make printlists obsolete in
the end? (thats fine with me, i'm just curious)

> > what remains (on gnucap side) is the probes. qucs does not
> > issue .print commands, but has {i,v} probe devices, which
> > add themselves to the printlist. we had no trouble to
> > implement an ELEMENT doing, what the qucs-style probes do
> > and hacked a simple hook in the backend, which makes these
> > probes register the corresponding probes.
> 
> Here's the code for a "meter" device.  It adds a "gain" probe, 
> and inherits all of the probes than an ELEMENT has.

thanks. this meter device is similar to what our probes do. in a similar
manner i've also implemented frequency and duty-cycle probes. how do you
suggest it to add itself to the printlist (and when?). or rather: what
would be a considerable change in the backend allowing components to add
probes?

currently its not possible for the qucs parser to issue a 'print tran
v(myself)' simply because the device does not yet exist.
what would work out of the box is having qucs issue print statements,
but i dont like that idea...

thank you
felix