patchGNU Octave - Patches: patch #8532, Use conventional signaling to...

 
 

patch #8532: Use conventional signaling to modify Readline term size rather than callback.

Submitter:  Dan Sebald <sebald>
Submitted:  Fri 12 Sep 2014 03:23:19 AM UTC
   
 
Category:  Core : other Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 18 Sep 2014 11:20:01 PM UTC, comment #7: 

Windows isn't something I know real well.  Is this WM_SIZING message similar to a SIGWICH in Unix?

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632647%28v=vs.85%29.aspx

Dan Sebald <sebald>
Thu 18 Sep 2014 10:07:24 PM UTC, comment #6: 

OK, I guess I should have been a little more descriptive about exactly the problem is.  Or I should say "was", because the oldcol!=_columns code is gone and the width now behaves properly.

It's subtle.  What PN describes is the behavior of the GUI's terminal window, but I was referring to Octave's internal output format.  The callback (and the SIGWICH) are meant to indicate to the core that the terminal size has changed, e.g., it is no longer 80 characters wide.  The internal formatter uses the new size to determine how many columns of a matrix can be printed on one line.

It's hard to illustrate with examples when there is no window, but if one would have shrunk the terminal window to the minimum columns, exit, then relaunch, the output would look something like:


>> pi*ones(10)
ans =

 Columns 1 through 7:

   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416   3.1
416   3.1416   3.1416   3.1416

 Columns 8 through 10:

   3.1416   3.1416   3.1416


Resizing would correct the appearance as (after another print out):


>> pi*ones(10)
ans =

 Columns 1 through 3:

   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416

 Columns 4 through 6:

   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416
   3.1416   3.1416   3.1416


Well, it's been corrected now, and the internal Octave format line width is correct.

I still prefer using SIGWICH.  That's the mechanism that other terminal emulators use (e.g., Gnome Terminal).

Dan Sebald <sebald>
Thu 18 Sep 2014 04:23:09 AM UTC, comment #5: 

My patch is attached.  It seems to work for me to preserve previous lines on Windows systems when the window is made smaller, then larger again.  If this works for others (Windows only!) then I'll add log info and commit.

(file #32127)

John W. Eaton <jwe>
Group administrator
Tue 16 Sep 2014 04:22:44 PM UTC, comment #4: 

raising a SIGWINCH signal would be OK for systems that have it, but Windows does not.

But we also need to do something else on Windows systems anyway because currently narrowing a terminal window and then making it wider causes existing lines in the window to be truncated.  I think I have a possible fix for this.  I'll post it here when I have something that works and that I'm happy with.

John W. Eaton <jwe>
Group administrator
Tue 16 Sep 2014 04:15:47 PM UTC, comment #3: 

Dan, thanks for the patch. But as Philip already mention I can not see a difference with and without the patch applied on my Linux system. When exactly do you see problems with the old approach?

Torsten Lilge <ttl>
Group Member
Fri 12 Sep 2014 02:53:22 PM UTC, comment #2: 

3.9.0+ (where I applied your patch to) seems to work OK on Linux and on Windows/MinGW.
To be honest I fail to see any difference as regards resizing the GUI terminal; it just works fine.

One thing I note is that on Linux, while making the terminal narrower, the pager line at the bottom disappears; but as soon as I touch an arrow key or so it reappears.

What never worked fine on MinGW is that when widening a too narrow terminal (where long lines wrapped), the wrapped characters/words jump back to the right once they fit in.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 12 Sep 2014 09:12:15 AM UTC, comment #1: 

Is it meant for 3.9.0+ or 4.1.0+? both I guess...

While resizing the GUI terminal I never noted strange behavior in the first attempt (I get that is the issue you refer to?); that is, I do see lots of other things happening that draw my attention :-)

Anyway, I plan to update my "unstable" Windows binaries today, I'll check if this makes any difference or provokes adverse effects.
Hang on....

Philip Nienhuis <philipnienhuis>
Group Member
Fri 12 Sep 2014 03:23:19 AM UTC, original submission:  

In main-window.cc is the following line which I believe is meant to force the Octave core to update the Readline terminal size so that Octave properly formats its output:

+verbose+
octave_link::post_event (this, &main_window::resize_command_window_callback);
-verbose-

Currently if the window is resized then the terminal will properly adjust.  The reason it doesn't work on the first resize due to restoring user settings is that QTerminal code has this conditional:


  _resizing = (oldlin!=_lines) || (oldcol!=_columns);

  if ( _resizing )
    {
...
    }


which I presume cuts down on kernel traffic a little bit since it changes the scale from pixels to characters.  (I.e., sizing isn't changed with every pixel change.)

Attached is a changeset that removes the use of a callback function and instead raises a signal at a location hopefully after the GUI objects are initialized and the Octave core has reached the point where it is capable of recognizing kernel signals.  Now, whether that is true and is still open for timing problems I'm not sure because kernal signals isn't something I've worked with a lot.  But I think the signal approach is just about right and a more conventional way of doing this.

What the ramifications are for Windows systems I'm not sure.  Perhaps it isn't even a problem problem for Windows.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #32127:  diffs.txt added by jwe (4KiB - text/plain)
file #32079:  octave-terminal_size_signal-2014sep11.patch added by sebald (2KiB - 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 lachlan (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by sebald (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 logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-07 lachlan CategoryNone Core : other
    2014-09-18 jwe Attached File- Added diffs.txt, #32127
    2014-09-12 sebald Attached File- Added octave-terminal_size_signal-2014sep11.patch, #32079

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code