Re: Help adapting POLY H source

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 lang_spice.cc... (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
worse.

> 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
spice.

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.

cheers
felix