octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #38236] invoking script in demo block to defin


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #38236] invoking script in demo block to define variables causes errors
Date: Thu, 14 Sep 2017 00:24:32 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #31, bug #38236 (project octave):

I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/21915520ac7b

I believe the random behavior was caused by the use of "mutable" data members
in the symbol_table::symbol_reference class.  Once that was removed, I saw
predictable behavior, but it was still not correct.

The symbol_reference class was introduced to handle symbol lookups in scripts
when the evaluation scope changes.  Like functions, scripts may be parsed once
and executed many times in different contexts.  But since they are supposed to
be evaluated in the scope of the caller, a mechanism is needed to access the
symbols from the scope outside of the script.  Originally, there was no scope
created and stored for scripts.  Now I've added one, but it is not the scope
that is used for evaluation.  It is only used to hold symbols for parsing.

To solve the evaluation problem, I made it possible for a symbol_record_rep
object to point to a secondary symbol_record_rep that contains the actual data
for the symbol.

Now when a script is evaluated, the symbols that are stored in the parse tree
are bound to the evaluation scope just before the code for the script is
evaluated.  Then these links are removed when the script exits.

The same approach is also used for nested functions now, though binding to the
parent scope happens at parse time, not evaluation time, and the links are
never removed since the parent scope of a nested function doesn't change.

Now to get a value from a symbol_record_rep requires checking to see if the
"next rep" is valid and using it if it is.  This cost is small, and in my
tests appears to be faster than the old symbol_reference class.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?38236>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]