octave-maintainers
[Top][All Lists]
Advanced

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

Re: Race condition seems to be fixed


From: John W. Eaton
Subject: Re: Race condition seems to be fixed
Date: Mon, 21 May 2012 08:54:32 -0400

On 21-May-2012, Jacob Dawid wrote:

|     There are other places where the symbol table could change.  For
|     example, the loop in eval_string in oct-parse.yy, which is similar to
|     the one in main_loop in toplev.cc and the one in get_debug_input in
|     input.cc.  Command history can also change in get_debug_input, though
|     I don't think it should be changing in eval_string.
| 
| 
| Why not invoke the callback there, too?

It would probably be OK to do that.  My point was that there may be
more places than the one that you chose where it is needed.

| For interactive use, ie. I sit at the
| octave console and type command for command invoking the callback there was
| sufficient. It's a question of taste on how you would like to update the 
symbol
| table: More updates means decreasing octave performance. I would opt in for
| performance. From a practical point of view, I might be interested in the
| current workspace when doing the following things:
| 
| 1.) Working interactively at the octave console.
| 2.) Debugging a script, walking step by step and watching the workspace 
change.
| 
| There is not need to update the symbol table model (which needs to be 
processed
| from the symbol table) too often.

I agree that it may not be necessary to update the list of symbols
that is displayed in the IDE every time it changes, provided that it
is updated "often enough".  I'm just not sure what "often enough" is.

jwe


reply via email to

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