[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Help adapting POLY H source

From: Felix Salfelder
Subject: Re: [Gnucap-devel] Help adapting POLY H source
Date: Sat, 21 Mar 2015 22:04:05 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Al.

On Fri, Mar 20, 2015 at 12:34:35PM -0400, al davis wrote:
> > must have missed that. so several new devices require an
> > extra patch to (which is not a problem).
> It really is a problem, but it is nontrivial to address.

it doesn't seem easy to do right. but it only affects spice, could be

> The intent was (and still is) to use commons to do that kind of 
> extension.

ok, so it's a bit like ELEMENT, should be possible to figure out.

there's a basic draft for G+poly(k) in the poly_g branch. with this it's
probably easy to implement any other poly(k) device in a similar way.
but it won't help, as long as there is no way to instanciate it from

the spice syntax should be something close to
Glabel p n poly(k) <portlist> <coefficients>,
i tried to parse this -- without the obsolete_callbacks.

now i am unsure about how this can work, particularly the "poly(k)" in
between. in the non-obsolete-callback case,
LANG_SPICE_BASE::parse_instance uses count_ and parse_ports to reach the
the type, and then calls x->set_dev_type() through parse_type, which
seems to be a bit late. no port parsing afterwards.  similarly,
LANG_SPICE_BASE::parse_args does not make use of set_param_by_index,
although some spice devices have positional arguments (currently parsed
with the obsolete code).

or short: it seems that not using the (obsolete) ELEMENT style parsing
is related to reinventing the spice parser. this is not what the poly(k)
implementation was meant to address...

what next?
- fall back to obsolete_callback_parse (ugh).
- patch lang_spice to get along (if(OPT::keys_between_nodes) ... ).
- anything else.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]