On Mon, Mar 02, 2015 at 03:53:01AM +0100, Felix Salfelder wrote: > (still no clue about s_fo.)
Hi Al i have been thinking about this a bit. it's larger than i hoped it would be. i'd like to collect some thougts on my current path before pushing another variant. good ideas are welcome. output plugin implementation details - simulation output is organized as table with dimensions #probes x #outdata\ calls. a probe related plugin may do anything with it. - class PROBE_CMD, base for PROBE related commands (such as "print", "alarm",...) implements do_it as it does not together with head, outdata etc. functionality. - CMD::_type a string identifier for CMD, the identifier is set during command invocation, similar to dev_type - probe related command stores a PROBELIST for each sim type (using a DISPATCHER<PROBELIST>). - OUTPUT_PROBES maintains a list with pointers to all probe related commands. - PROBELIST. now storing PROBE* (previously PROBE). PROBEs are polymorphic. a simulation command may carry its own tailored probe variant. - SIM::head, SIM::outdata calls OUTPUT_PROBES::head, OUTPUT_PROBES::outdata, forwarding to all probe related commands, together with CMD::_type. - the simulation command has access to corresponding PROBES (using an OUTPUT_PROBES::iterator). this seems required for s_fo. - _sim->_mode remains intact (for now?). special treatment for particular commands. (e.g. s_fo currently prints mag, db and phase, as well as relative stuff) - a PROBE instance has a type. either real or complex. the output plugin decides what to do. use case, example <printcmd> <ident> <probelist> e.g. "store tran v(nodes)". picks probe prototype from command_dispatcher["tran"]. then stashes v(nodes) in the PROBELIST dispatcher of the store command plugin at "tran". <simcmd> <args> e.g. ".tran 0 1 1". runs tran, calls SIM::head, SIM::outdata as usual, passing data and CMD::_type (="tran") to the probe related commands. the "store" plugin then processes the probelist registered at "tran". problems: many. for example: - PROBE polymorphism feels a bit ugly. yet i don't know how to avoid it. - a probe related command cannot see probes stashed by another probe related command (good or bad?) - print ac v(nodes) (stashes base/default/generic probes) afterwards: load s_ac.so ac 1 10 * 2 runs ac using the wrong probes. thanks felix _______________________________________________ Gnucap-devel mailing list Gnucap-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gnucap-devel
