bugGNU Octave - Bugs: bug #65607, cluttering text output when using...

 
 

bug #65607: cluttering text output when using path() with echo on

Submitter:  Hartmut <hardy>
Submitted:  Thu 18 Apr 2024 09:54:08 AM UTC
   
 
Category:  Octave Function Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 9.1.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 May 2024 07:07:07 PM UTC, comment #7: 

Another option to try (actually a kludge) is to simply shadow built-in echo with an m-file 'echo.m' containing no code at all (maybe just a comment) while you're working with cvx (e.g., put it somewhere in the path you're working in while using cvx).

I sometimes do this with Matlab code (usually of the X-Mas-tree variety with lots of superfluous bells and whistles) that I occasionally need, and it very often helps me forward sufficiently.
That said I have never tried it with 'echo', and if cvx depends on `echo's` functionality it might not work for you.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 10 May 2024 07:53:49 AM UTC, comment #6: 

(In my opinion, changing the C++ code mentioned in comment #3, using the information given in comment #5, along the reasoning of comment #2, would be most appropriate here. But since I am not experienced in doing changes to the C++ parts of Octave, I'll need to wait if someone else likes to improve Octave's C++ code in this respect.)

Hartmut <hardy>
Sun 21 Apr 2024 12:46:02 AM UTC, comment #5: 

There is no way in an m-file to read the echo state.  Within C++ the tree_evaluator class has a member variable m_echo_state and also m_echo.  One could probably write an oct-file to check the echo state.

Or stay in C++ and modify the path command as outlined in comment #3.

Rik <rik5>
Group administrator
Sat 20 Apr 2024 11:30:38 AM UTC, comment #4: 

@Rik: It's the cvx library itself that calls path() as well as echo().

I tried to find a workaround (on cvx's m-code, but the same question is also relevant if we want to change Octave's load-path.cc code), but did not come very far because of the following question:

How can one detect the "echo state" of Octave at all? I could not find any Octave-command to detect if this code runs currently on the "echo on" mode or in the "echo off" mode. Does anyone know how to detect this?

Hartmut <hardy>
Fri 19 Apr 2024 12:26:31 PM UTC, comment #3: 

Changing Item Group to Matlab Compatibility.  Matlab doesn't have PKG_ADD files as far as I know.  This is an Octave extension that we can program to behave as we wish.

Is the cvx library calling path(), or is this your own code that you could modify?  Modifications to m-files would be easiest.

The C++ code for path() is load_path::set at libinterp/corefcn/load-path.cc:308.  The code in question is


  for (auto& di : m_dir_info_list)
    {
      if (m_add_hook)
        m_add_hook (di.dir_name);
    }


This would be the point to save/restore the echo state.

Rik <rik5>
Group administrator
Fri 19 Apr 2024 06:43:22 AM UTC, comment #2: 

I personally use "echo" not very often, at all. But currently I am using an external m-code library called cvx (https://cvxr.com/cvx/). This library is designed for Matlab, but runs sufficently well in Octave. And this cvx library uses "echo" extensivly to turn on or off the console output of other included (m-code and mex code) numerical solver libraries (SDPT3, SeDuMi).

So probably this Octave behavior of "echo" is mostly a "Matlab compatiblity" issue, when people (as currently me) run code that was originally designed for Matlab, and now the code behaves  differently when used with Octave.

If this excessive text output really only happens when "echo on" is used together with "path", would then the following approach be a feasible code change in Octave, in order to improve its Matlab compatiblity?

  • at the point in the code of "path", shortly before/after the PKG_ADD scripts are called:
  • save the current state of "echo"
  • echo off
  • PKG_ADD stuff
  • restore the previously saved state of "echo"



Hartmut <hardy>
Fri 19 Apr 2024 02:05:49 AM UTC, comment #1: 

I would say that my first thought is not to use 'echo on'.  I only use it occasionally when debugging, and never for ordinary usage.  Is there another way to accomplish your goal?  Maybe 'diary' if you are trying to get a record of commands and resulting output?

The root cause is that setting the path will also evaluate any PKG_ADD scripts contained in path directories.  Try `help autoload` for a description.  Since these are script files, not functions, maybe it is correct to display them?  To see that this is the case, take a look at libinterp/dldfcn/PKG_ADD.  That is where most of the commands that you are seeing are located.

Rik <rik5>
Group administrator
Thu 18 Apr 2024 09:54:08 AM UTC, original submission:  

I have observed the following behavior with the current Octave 9.1 release. When I run this demo code (from the Octave console or from within an m-file):


echo off
echo off all
clc
path(path,''); % -> no text on console = OK
echo on
% NOW COMES THE BUG:
path(path,''); % -> a lot of text on console = bug


Then I see very much text output on the Octave console. And in my understanding this text output should NOT be there, because "echo on" is only supposed to turn the text output on for the current script and not for sub-functions. (Also Matlab does not produce this nasty long text output.)

Here is what I get as text output on my Octave installation:


+ echo on
+ % NOW COMES THE BUG:
+ path(path,''); % -> a lot of text on console = bug
+ autoload ("__fltk_check__", "__init_fltk__.oct");
+ if (__have_feature__ ("FLTK") && __have_feature__ ("OPENG
L") && have_window_system () && ! (ismac () && __event_mana
ger_enabled__ ())) register_graphics_toolkit ("fltk"); endi
f
+ autoload ("__have_gnuplot__", "__init_gnuplot__.oct");
+ if (__have_gnuplot__ ()) register_graphics_toolkit ("gnup
lot"); endif
+ autoload ("__player_audioplayer__", "audiodevinfo.oct");
+ autoload ("__player_get_channels__", "audiodevinfo.oct");

+ autoload ("__player_get_fs__", "audiodevinfo.oct");
+ autoload ("__player_get_id__", "audiodevinfo.oct");
+ autoload ("__player_get_nbits__", "audiodevinfo.oct");
+ autoload ("__player_get_sample_number__", "audiodevinfo.o
ct");
+ autoload ("__player_get_tag__", "audiodevinfo.oct");
+ autoload ("__player_get_total_samples__", "audiodevinfo.o
ct");
+ autoload ("__player_get_userdata__", "audiodevinfo.oct");

+ autoload ("__player_isplaying__", "audiodevinfo.oct");
+ autoload ("__player_pause__", "audiodevinfo.oct");
+ autoload ("__player_play__", "audiodevinfo.oct");
+ autoload ("__player_playblocking__", "audiodevinfo.oct");

+ autoload ("__player_resume__", "audiodevinfo.oct");
+ autoload ("__player_set_fs__", "audiodevinfo.oct");
+ autoload ("__player_set_tag__", "audiodevinfo.oct");
+ autoload ("__player_set_userdata__", "audiodevinfo.oct");

+ autoload ("__player_stop__", "audiodevinfo.oct");
+ autoload ("__recorder_audiorecorder__", "audiodevinfo.oct
");
+ autoload ("__recorder_get_channels__", "audiodevinfo.oct"
);
+ autoload ("__recorder_get_fs__", "audiodevinfo.oct");
+ autoload ("__recorder_get_id__", "audiodevinfo.oct");
+ autoload ("__recorder_get_nbits__", "audiodevinfo.oct");
+ autoload ("__recorder_get_sample_number__", "audiodevinfo
.oct");
+ autoload ("__recorder_get_tag__", "audiodevinfo.oct");
+ autoload ("__recorder_get_total_samples__", "audiodevinfo
.oct");
+ autoload ("__recorder_get_userdata__", "audiodevinfo.oct"
);
+ autoload ("__recorder_getaudiodata__", "audiodevinfo.oct"
);
+ autoload ("__recorder_isrecording__", "audiodevinfo.oct")
;
+ autoload ("__recorder_pause__", "audiodevinfo.oct");
+ autoload ("__recorder_record__", "audiodevinfo.oct");
+ autoload ("__recorder_recordblocking__", "audiodevinfo.oc
t");
+ autoload ("__recorder_resume__", "audiodevinfo.oct");
+ autoload ("__recorder_set_fs__", "audiodevinfo.oct");
+ autoload ("__recorder_set_tag__", "audiodevinfo.oct");
+ autoload ("__recorder_set_userdata__", "audiodevinfo.oct"
);
+ autoload ("__recorder_stop__", "audiodevinfo.oct");
+ autoload ("audioformats", "audioread.oct");
+ autoload ("audioinfo", "audioread.oct");
+ autoload ("audiowrite", "audioread.oct");
+ autoload ("bzip2", "gzip.oct");
+
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fminbnd");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fminsearch");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fminunc");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fsolve");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fzero");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("lsqnonneg");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("pqpnonneg");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("qp");
+
+
+
+
+
>>


I observed this unwanted behavior under Windows (10) as well as under Linux. I have seen it in the Octave GUI as well as in the CLI.

Many older Octave version show this very same behavior (I tested Octave 5.1.0 until the current 9.1.0). BUT my oldest Octave version, Octave 4.2.2, does NOT show this unwanted behavior.

This behavior bothers me, because it makes using the external toolbox cvxr very "noisy" on the console.

Is there an easy way so we can fix this in Octave? (Or at least a workaround?)

Hartmut <hardy>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by hardy (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-04-19 rik5 Severity3 - Normal 2 - Minor
        StatusNone Confirmed
    2024-04-19 rik5 Item GroupRegression Matlab Compatibility

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code