help-octave
[Top][All Lists]
Advanced

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

Re: keyboard does not provide local context


From: Jaroslav Hajek
Subject: Re: keyboard does not provide local context
Date: Tue, 24 Nov 2009 08:11:59 +0100



On Fri, Nov 20, 2009 at 5:01 PM, John W. Eaton <address@hidden> wrote:
On 20-Nov-2009, Eric Chassande-Mottin wrote:

| using foo.m below,
| if I say foo(1) from prompt I get access to local vars
|
| octave3.2:1> foo(1)
| keyboard: stopped in /home/ecm/foo.m
| a =  1
| debug> whos
| Variables in the current scope:
|
|   Attr Name        Size                     Bytes  Class
|   ==== ====        ====                     =====  =====
|        a           1x1                          8  double
|        argn        1x1                          1  char
|    f   x           1x1                          8  double
|
| Total is 3 elements using 17 bytes
|
| but when calling foo() from a script I don't
|
| octave3.2:1> test
| keyboard: stopped in /home/ecm/foo.m
| b =  2
| a =  1
| debug> whos
| Variables in the current scope:
|
|   Attr Name        Size                     Bytes  Class
|   ==== ====        ====                     =====  =====
|        ans         1x30                        30  char
|        b           1x1                          8  double
|
| Total is 31 elements using 38 bytes
|
| why is that? is there a way to access local vars when calling from a script?
|
| I am using
|
| GNU Octave, version 3.2.3

It's best to report bugs to the address@hidden list.

This problem has been reported several times now and it is fixed in
the current development version of Octave.

I think the relevant patches are

 http://hg.savannah.gnu.org/hgweb/octave/rev/fb22dd5d6242
 http://hg.savannah.gnu.org/hgweb/octave/rev/25c2e92ee03c
 http://hg.savannah.gnu.org/hgweb/octave/rev/bbe033dcfe13

Jaroslav, I think it is safe to apply the first two to the 3.2.x
branch.  I'm not so sure about the third one though as it removes some
variables from a class and changes at least one function signature,
which might cause some binary compatibility problems.

These don't apply due to unwind_protect changes. I think the second one reverts the first one, so maybe it would suffice to adapt the second one for 3.2.x. Does it make sense without also taking the third one?


--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

reply via email to

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