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 _______________________________________________ Gnucap-devel mailing list Gnucap-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gnucap-devel
