Re: [Gnucap-devel] output plugins, iteration

[Felix Salfelder]

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