Re: scope and CARD_LIST:_card_list

On Wed, 27 Jan 2021 00:55:06 +0100
Felix Salfelder <[email protected]> wrote:
> On Mon, Jan 25, 2021 at 03:08:15PM -0500, al davis wrote:
> > > I also have issues with DEV_DOT. Symptoms are that commands like "get"
> > > wont work properly if scope != CARD_LIST::_card_list. This is because
> > > the owner is lost in command elaboration.[..]  
> > 
> > use scope?  
> 
> Not sure what you mean. I was thinking of something like
> 
> {
> 	CARD_LIST cl;
> 	CMD::command("get file", &cl);
> }

You could, but it needs to change underneath.  You have the idea with
the s_* files.  It needs to be extended to all.  Use the Scope argument
to do_it(), instead of direct access to CARD_LIST::card_list.

To check that it really works, add check code:


void XXXXXXXXXX::do_it(CS& Cmd, CARD_LIST* Scope)
{
  assert(Scope);
  if (Scope == &CARD_LIST::card_list) {untested();
  }else{untested();
  }


Then change all CARD_LIST::card_list to Scope->


> e.g. LANG_SPICE_BASE::parse_command does
> 
> CARD_LIST* scope = (x->owner()) ? x->owner()->subckt() : &CARD_LIST::card_list;
> [..]                   ^ is NULL
> CMD::cmdproc(cmd, scope);

Keep this use of CARD_LIST::card_list.


> I think the workaround is to use a CARD at the root instead, and avoid
> CMD::command. Similar to
> 
> {
> 	BASE_SUBCKT* root = device_dispatcher.clone("subckt");
> 	CS cs(STRING, "get file");
> 	new__instance(cs, root, root->subckt());
> }

I thought of that.  It might be an improvement.  

It's not really necessary, and really just cosmetic, so don't do that
yet.  Get the first part working, then try it.

> Not sure which consequences this will have. CARD::long_label might not
> play well if there is an additional owner at the top. 


> (and set_owner has
> an assertion against resetting it NULL, perhaps for a reason).

 void	set_owner(CARD* o) {assert(!_owner||_owner==o); _owner=o;}

That assertion is against resetting _owner, to anything, but allowing redundant calls.

!owner .........  it's not set.
_owner==o   .........   the call is a confirmation.

Once _owner is set, you can't reset it, but you can hit it again to
make sure it is set.

I don't remember any problem with changing the owner after it was set,
but it wasn't tested.