[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Release Plans
From: |
Daniel J Sebald |
Subject: |
Re: Release Plans |
Date: |
Fri, 05 Jul 2013 15:22:42 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 07/05/2013 02:42 PM, John W. Eaton wrote:
On 04/22/2013 03:31 PM, John W. Eaton wrote:
I would like to aim for making a new stable release by the end of
June (this year).
[snip]
The GUI is better, but we don't have QtHandles integrated and the
terminal widget does not work properly on either Windows or Unixy
systems. The biggest problem is that using Ctrl-C for interrupting
the Octave interpreter does not work and we seem to be unable to make
keyboard shortcuts work properly, or to allow users to customize them.
I intend to start a separate thread about these issues. As I see it,
the GUI is the single largest issue preventing the release from
happening.
I believe the Ctrl-C issue might tie in with the signals conundrum,
which has shown up in at least a couple other places. Right now, Octave
core will take control of a number of signals, but to do so means
overriding the GUI's use of signals which happens on at least one
platform (KDE) when opening files. The GUI hangs, then eventually
reports some bad message. Either signals are going to have to all go to
the GUI and be routed to the core, or vice versa.
There was a short list of criticals a few weeks back (to which I will
add one, breakpoints):
1) MinGW/MXE build
2) Bug #38785
3) SIGCHILD (and possibly other) signal handlers (Patch #7949 and Bug
#38305)
4) Java support
5) breakpoint retention for poorly parsed file
My feeling is that users of the debugger won't find the breakpoint
behavior acceptable. The problem is that running a script function for
which there is a badly constructed line (very easy thing to do) loses
all breakpoints internally. Yet, the GUI doesn't update the breakpoint
markers so it appears that they are still set. Fix the syntax on the
offending line and the function will execute all the way through, not
breaking where previously there were breakpoints. So one has to go
through the script file, reapplying breakpoints. However, the presence
of the breakpoint markers makes doing so somewhat dodgy. I think I've
even managed a scenario where I've saved a file with a bogus line and
have the function work fine once, then fail on the second attempt.
Dan