strange behaviour when running a script via "run"

[Carlo de Falco]

On 19 Apr 2009, at 22:03, Carlo de Falco wrote:

> Hi,
>
> I have the following line in my .octaverc to load the sundials  
> toolbox:
>
> run /opt/sundials/2.3.0/sundialsTB/startup_STB.m
>
> Since I built and installed the current mercurial tip on OSX this  
> has stopped working,
> I believe this is due to a strange behaviour when running scripts  
> with the "run" command.
>
> For example with the following very simple script:
>
> ---------------------------------------------------
> >> type startup_STB
> startup_STB is the user-defined function defined from: /Users/carlo/ 
> Desktop/test/startup_STB.m
>
> stb_path = '/opt/sundials/2.3.0';
> stb = fullfile(stb_path,'sundialsTB');
> printf(["stb=" stb "\n"]);
> printf(["stb=" stb "\n"]);
> ---------------------------------------------------
>
> I get
>
> ---------------------------------------------------
> >> version
> ans = 3.1.55
> >> run startup_STB.m
> stb=/opt/sundials/2.3.0/sundialsTB
> `stb' undefined near line 4 column 16
> error: called from `startup_STB' in file /Users/carlo/Desktop/test/ 
> startup_STB.m near line 4, column 1
> error: called from:
> error:   /Users/carlo/Desktop/OF/octave/octave-hg/scripts/ 
> miscellaneous/run.m at line 53, column 7
> ---------------------------------------------------
>
> i.e. the variable "stb" exists when referenced in the first printf  
> command but it's undefined when printf is called the second time.
> If the script is launched directly, everything seems to work fine
>
> ---------------------------------------------------
> >> startup_STB
> /opt/sundials/2.3.0/sundialsTB
> /opt/sundials/2.3.0/sundialsTB
> ---------------------------------------------------
>
> c.

I have tried to trace the origin of this bug using "hg bisect" and it  
seems to indicate that it was introduced with the following changeset:

--------------------8<--------------------

hg log -r8581 -p
changeset:   8581:6adcafc70c32
user:        John W. Eaton <jwe at octave.org>
date:        Fri Jan 23 11:28:25 2009 -0500
summary:     toplev.cc (octave_call_stack::do_goto_caller_frame):  
allow caller frame to be base frame

diff -r 188d38a553c7 -r 6adcafc70c32 src/ChangeLog
--- a/src/ChangeLog	Fri Jan 23 13:13:39 2009 +0100
+++ b/src/ChangeLog	Fri Jan 23 11:28:25 2009 -0500
@@ -1,3 +1,8 @@
+2009-01-23  John W. Eaton  <jwe at octave.org>
+
+	* toplev.cc (octave_call_stack::do_goto_caller_frame):
+	Also allow caller frame to be base frame, not just user code.
+
  2009-01-23  Jaroslav Hajek  <highegg at gmail.com>

  	* gripes.cc (gripe_indexed_cs_list, gripe_invalid_inquiry_subscript):
diff -r 188d38a553c7 -r 6adcafc70c32 src/toplev.cc
--- a/src/toplev.cc	Fri Jan 23 13:13:39 2009 +0100
+++ b/src/toplev.cc	Fri Jan 23 11:28:25 2009 -0500
@@ -437,7 +437,7 @@

        octave_function *f = elt.fcn;

-      if (f && f->is_user_code ())
+      if (frame == 0 || (f && f->is_user_code ()))
  	{
  	  if (! skipped)
  	    // We found the current user code frame, so skip it.

--------------------8<--------------------

Unfortunately I don't understand this patch so I'm not really sure  
whether it is actually responsible for the bug...
c.