bugGNU Octave - Bugs: bug #41202, Spurious output when path() called...

 
 

bug #41202: Spurious output when path() called with 'echo on'

Submitter:  Michael C. Grant <mcgrant>
Submitted:  Fri 10 Jan 2014 11:01:05 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Michael C. Grant Open/Closed:  * Closed
Release:  * 3.8.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 13 Jan 2014 06:41:52 PM UTC, comment #21: 

I combined my patch and John's and it seems to be compatible with Matlab now.  I pushed the changeset to the gui-release branche here (http://hg.savannah.gnu.org/hgweb/octave/rev/bc139ccccef9).

Octave still doesn't support the 'echo on function_name' syntax.  A new feature request could be opened for it if desired, but the existing support seems good enough for now.

Rik <rik5>
Group administrator
Sat 11 Jan 2014 05:27:06 PM UTC, comment #20: 

Thanks John. BTW, I'm now able to build octave directly from the gui-release repo so I can test changes readily.

Michael C. Grant <mcgrant>
Sat 11 Jan 2014 05:22:53 PM UTC, comment #19: 

Rik, if you commit a change for this bug, please put it on the gui-release branch.  I'd really like to help Michael get CVX working properly with Octave for the 4.0.x release series.

John W. Eaton <jwe>
Group administrator
Sat 11 Jan 2014 05:04:12 PM UTC, comment #18: 

Would a function like the attached help?


(file #30245)

John W. Eaton <jwe>
Group administrator
Sat 11 Jan 2014 04:49:59 PM UTC, comment #17: 

Yes, I would say that MATLAB's rule for "echo on" is this: echo the command if there is nothing but scripts in the call stack. If there is even one function, don't echo.

I've done a little reading and I now realize that my analysis of "echo on all" is wrong.

Here's the deal:
- "echo on / echo off / echo" are for SCRIPTS only.
- "echo on all / echo off all" are for FUNCTIONS only. Scripts are NOT affected by these commands. So for instance:


>> echo on all
>> x=1;
>> script1

x =

     3


- "echo <FNAME> on / echo <FNAME> off" are for the single function <FNAME> only.


>> echo off all
>> echo func1 on
>> func1(1)
script2
x = x + 1;
script2
x = x + 1;
y = x;

ans =

     3

>> echo off all
>> func1(1)

ans =

     3

>> echo func2 on
Error using echo
MATLAB file not found: func2


Michael C. Grant <mcgrant>
Sat 11 Jan 2014 04:39:37 PM UTC, comment #16: 

My patch was made before the latest testing by Michael.  It generally works, and is maybe good enough, but it is not exactly equivalent to Matlab.  They seem to base their decision to echo or not based on whether the call path has descended through a function or through a script.  My decision was based on the call depth and whether the current calling instance was a function or a script.  The only difference appears in the script calling script instance such as script1->script2 where only script1 will be echoed.


Rik <rik5>
Group administrator
Sat 11 Jan 2014 04:34:58 PM UTC, comment #15: 

Keep in mind that "run" is a function in MATLAB, so the behavior you see below is entirely consistent with the rules we have enumerated.

If "source" behaves differently from "run", then, I would say that's fine, especially since MATLAB does not have "source".

Michael C. Grant <mcgrant>
Sat 11 Jan 2014 04:33:09 PM UTC, comment #14: 

OK, here's "run"


>> echo on
>> x=1;
>> run script2
>> x

x =

     2


Michael C. Grant <mcgrant>
Sat 11 Jan 2014 04:32:10 PM UTC, comment #13: 

MATLAB does not have a "source" command. Here's the best I can do:


>> echo on
>> x=1;
>> script2
x = x + 1;
>> x

x =

     2


Michael C. Grant <mcgrant>
Sat 11 Jan 2014 04:29:02 PM UTC, comment #12: 

I don't think there is a "source" command in Matlab.  Maybe "run" is the closest thing to Octave's "source" function.

John W. Eaton <jwe>
Group administrator
Sat 11 Jan 2014 04:22:41 PM UTC, comment #11: 

I've upload a patch for the C++ code that checks the call depth and only echoes top-level script files.  It works fine with the examples in this bug report.  For completeness though, could you check the behavior of Matlab when using the source command?


echo on
x = 1
source script2.m




(file #30244)

Rik <rik5>
Group administrator
Sat 11 Jan 2014 04:20:17 PM UTC, comment #10: 

Actually, I hadn't confirmed that "scripts called by scripts called by functions" were not echoed. I just modified func1.m below to call script1 instead of script2, though, and indeed the sub-sub-script was not echoed. So it's confirmed.

Michael C. Grant <mcgrant>
Sat 11 Jan 2014 04:17:23 PM UTC, comment #9: 

OK, here's the test. I created script1.m as follows:


script2
script2
x


Here is MATLAB's output, indicating that echoing occurs within the second script:


>> script1
script2
x = x + 1;
script2
x = x + 1;
x

x =

     3


So that means that "echo on" behavior is this: commands are echoed in
- scripts
- scripts called by scripts
BUT NOT
- functions
- scripts called by functions
- scripts called by scripts called by functions



Michael C. Grant <mcgrant>
Sat 11 Jan 2014 04:12:15 PM UTC, comment #8: 

"echo on all" truly echoes everything: functions, scripts, etc.

"echo on" definitely does not echo inside functions, or anything within a function (including scripts).

What I don't know is this: if you call a script from the command line, and that script in turn calls another, does it echo that script as well? Or does it go just one level deep regardless? That I will test.

Michael C. Grant <mcgrant>
Sat 11 Jan 2014 04:06:55 PM UTC, comment #7: 

Unless someone else really wants to work on it, I'll see if I can fix this problem.

Is there a clear explanation of exactly how echo is supposed to behave for functions and scripts called by other functions or scripts?  Does the "all" option affect that behavior?

I guess we need a test that shows all the possible combinations along with the expected output from Matlab.

John W. Eaton <jwe>
Group administrator
Sat 11 Jan 2014 05:47:50 AM UTC, comment #6: 

The issue is the same one identified earlier that 'echo on' turns on echoing for scripts at all levels, not just toplevel scripts.  In this case, when a directory is added to the path one of the hooks that is done is to run the PKG_ADD script for the directory.  That is the source of all the screen output.  I tested this by setting the path to something which has no PKG_ADD scripts (/home) and there is no output.


echo on
x = path ();
path ("/home");  # no weird output
path (x);  # lots of output


Rik <rik5>
Group administrator
Sat 11 Jan 2014 04:45:02 AM UTC, comment #5: 

This sequence seems to demonstrate the bug reproducibly


echo on
x = path ();
path (x)


Rik <rik5>
Group administrator
Sat 11 Jan 2014 04:04:00 AM UTC, comment #4: 

Rik, regarding "path": I think you actually have the change the path for that internal script to be executed and echo-ed. Just typing "path" with no arguments won't do anything, I agree.

Here's the output of "echo on all" for func1. Octave:


>> echo on all
>> func1(1)
function y = func1 (x)
script2
x = x + 1;
endscript;
script2
x = x + 1;
endscript;
y = x;
endfunction;

ans =  3


MATLAB:


>> echo on all
>> func1(1)
script2
x = x + 1;
script2
x = x + 1;
y = x;

ans =

     3


So there is closer agreement with "echo on all".

Michael C. Grant <mcgrant>
Sat 11 Jan 2014 03:49:58 AM UTC, comment #3: 

I just tried your func1/script2 example and I see what you mean.  Apparently Octave always echoes scripts, regardless of what level of hierarchy they are called from.  I know the parser keeps track of hierarchy so it is probably possible to implement echo only when the level is the topmost.

For the first bug you reported, what was the sequence that led to it?  I tried


echo on
path


And all I get is the output of path() and nothing with colormaps, etc.

Rik <rik5>
Group administrator
Sat 11 Jan 2014 03:40:17 AM UTC, comment #2: 

Matlab's documentation for echo is here (http://www.mathworks.com/help/matlab/ref/echo.html).  It appears that Octave's echo corresponds to 'echo on all'.  It might be nice if you could check that in Matlab since you seem to have access to it.


Rik <rik5>
Group administrator
Fri 10 Jan 2014 11:08:49 PM UTC, comment #1: 

Actually, MATLAB's behavior does differ here: it does not echo script commands when those scripts are called by functions.

For example, consider files func1.m


function y = func1(x)
script2
script2
y = x;


and script2.m:


x = x + 1;


Obviously, if I type "func1(1)" on the command line, I get the result "3" out. In MATLAB, the output looks like this, with both ECHO ON and ECHO OFF.


>> echo off
>> func1(1)

ans =

     3

>> echo on
>> func1(1)

ans =

     3


In Octave, I get this:


>> echo off
>> func1(1)
ans =  3
>> echo on
>> func1(1)
x = x + 1;
endscript;
x = x + 1;
endscript;
ans =  3



Michael C. Grant <mcgrant>
Fri 10 Jan 2014 11:01:05 PM UTC, original submission:  

CVX does some hacky things sometimes. One of those things is to modify the PATH: when "cvx_begin" is called, I add some directories into the path; and when "cvx_end" is called, I remove them.

I do this because I don't want some of the commands I define to pollute the namespace when CVX is not being used. The names are pretty generic, like "expression", "dual", "binary", etc.

Now, what I've discovered is that when I call the "path()" command with ECHO ON, it spits out all of this output, attached below. This makes demos involving CVX pretty much impossible to follow.

I thought about whether this is actually a bug, and it seems to me that it must be. path() is a function, and not only that, it's a built-in function. So I should not be seeing any output if I use it. I am sure there are legitimate reasons for running a script from within path(), but I need to expect it to behave like a function when I do so.


colormap ("register", "autumn");
colormap ("register", "bone");
colormap ("register", "cool");
colormap ("register", "copper");
colormap ("register", "flag");
colormap ("register", "gmap40");
colormap ("register", "gray");
colormap ("register", "hot");
colormap ("register", "hsv");
colormap ("register", "jet");
colormap ("register", "lines");
colormap ("register", "ocean");
colormap ("register", "pink");
colormap ("register", "prism");
colormap ("register", "rainbow");
colormap ("register", "spring");
colormap ("register", "summer");
colormap ("register", "white");
colormap ("register", "winter");
endscript;
## Discard result to avoid polluting workspace with ans at startup.
~ = __all_opts__ ("fminbnd");
## Discard result to avoid polluting workspace with ans at startup.
~ = __all_opts__ ("fminsearch");
## Discard result to avoid polluting workspace with ans at startup.
~ = __all_opts__ ("fminunc");
## Discard result to avoid polluting workspace with ans at startup.
~ = __all_opts__ ("fsolve");
## Discard result to avoid polluting workspace with ans at startup.
~ = __all_opts__ ("fzero");
## Discard result to avoid polluting workspace with ans at startup.
~ = __all_opts__ ("lsqnonneg");
## Discard result to avoid polluting workspace with ans at startup.
~ = __all_opts__ ("pqpnonneg");
## Discard result to avoid polluting workspace with ans at startup.
~ = __all_opts__ ("qp");
endscript;
autoload ("__fltk_maxtime__", "__init_fltk__.oct");
autoload ("__fltk_redraw__", "__init_fltk__.oct");
autoload ("__have_fltk__", "__init_fltk__.oct");
autoload ("gui_mode", "__init_fltk__.oct");
autoload ("mouse_wheel_zoom", "__init_fltk__.oct");
if (__have_fltk__ () && have_window_system ())
  register_graphics_toolkit ("fltk");
endif;
register_graphics_toolkit ("fltk");
register_graphics_toolkit ("gnuplot");
autoload ("__magick_finfo__", "__magick_read__.oct");
autoload ("__magick_formats__", "__magick_read__.oct");
autoload ("__magick_ping__", "__magick_read__.oct");
autoload ("__magick_write__", "__magick_read__.oct");
autoload ("csymamd", "ccolamd.oct");
autoload ("chol2inv", "chol.oct");
autoload ("choldelete", "chol.oct");
autoload ("cholinsert", "chol.oct");
autoload ("cholinv", "chol.oct");
autoload ("cholshift", "chol.oct");
autoload ("cholupdate", "chol.oct");
autoload ("etree", "colamd.oct");
autoload ("symamd", "colamd.oct");
autoload ("sprank", "dmperm.oct");
autoload ("qrdelete", "qr.oct");
autoload ("qrinsert", "qr.oct");
autoload ("qrshift", "qr.oct");
autoload ("qrupdate", "qr.oct");
endscript;


Michael C. Grant <mcgrant>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #30245:  diffs.txt added by jwe (1KiB - text/plain)
file #30244:  patch.echo added by rik5 (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mcgrant (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-13 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2014-01-11 jwe Attached File- Added diffs.txt, #30245
    2014-01-11 rik5 Attached File- Added patch.echo, #30244
        Assigned tojwe None
    2014-01-11 jwe Assigned toNone jwe
    2014-01-11 rik5 Item GroupIncorrect Result Matlab Compatibility
    2014-01-11 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code