[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] qucs parser
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] qucs parser |
Date: |
Fri, 16 Mar 2012 12:27:02 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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