Re: Migrating to 3.8 GUI version

[Colin Beckingham]

On Tue, 2013-12-31 at 18:17 -0500, John W. Eaton wrote:
> On 12/29/2013 11:20 AM, Colin Beckingham wrote:
> > Many thanks for the 3.8 version. I have it working, both CLI and GUI, on
> > openSUSE 13.1. This version seems to have resolved my longstanding issue
> > with sporadically poor plot window control. I'm looking forward to
> > delving deeper into the capabilities of the GUI.
> >
> > One of the issues that arises when migrating from a CLI version to GUI
> > is the handling of pauses. It is convenient to stop a script to see what
> > is happening from time to time. In CLI mode the pause is good (provided
> > it works consistently) but in GUI mode it might be better to have a
> > breakpoint. Pauses are particularly confusing in GUI since if you are
> > working from the editor the script can stop without warning and since
> > the message to continue is sent to the CLI window you can miss it
> > completely.
> >
> > I tried replacing the pause()s with keyboard()s but this made things
> > worse since a keyboard() command seems to be different from a
> > breakpoint.
> >
> > How to replace pause()s with breakpoints in an efficient manner (ie
> > find/replace)?
> 
> If you are using pause as a debugging tool, I recommend that you try 
> setting breakpoints interactively in the GUI editor instead.  Then you 
> can do nice things like step through the code and watch the pointer move 
> forward to the next line or next breakpoint.  The workspace viewer also 
> follows the current function, so you can easily see what variables are 
> defined.
> 
> It might also help to detach the editor window from the GUI so you can 
> view the command window and editor simultaneously.  It's also possible 
> to have the command and editor windows both docked in the main window 
> but not overlapping.
> 
> jwe

Thanks for the reply. This is what I have been doing and it works quite
well.
The specific context here is that of the Coursera Andrew Ng Machine
Learning course where I am a community TA. Students are given
programming exercises to complete; a main .m file controls execution of
functions and subroutines that the students complete step-by-step. The
pauses give the students a chance to review the progress of their
programming. A lot of the time this works well, but unfortunately there
is a problem on some OS with pause - the first hit on return fills a
buffer and invalidates subsequent pauses, with the result that the
script runs through unimpeded which is counterproductive. This is not a
problem with Octave, but with the way the OS handles the instruction to
stop.

I've a feeling (hope) that the new GUI might help smooth this problem
out. I have yet to see feedback on the behaviour of breakpoints on Mac
and Windows versions, but we live in hope.

Clearly the course instructors cannot issue a version of the .m file
with the breakpoints embedded, but a good process at the student end
might be to first change all pauses to a different executable command 
such as dummy=1, then step through each "dummy=1" string adding
breakpoints as preferred.

Breakpoints actually solve another issue, that of being committed 
to a .m file and being unable to stop it prematurely without using ctrl-c 
which leads to its own issues.