Re: GUI release

[Rik]

On 01/27/2015 04:35 PM, address@hidden wrote:

Subject:

Re: Release Ideas

From:

"John W. Eaton" <address@hidden>

Date:

01/27/2015 04:35 PM

To:

Michael Godfrey <address@hidden>, address@hidden

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

7bit

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden> <address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=utf-8; format=flowed

Message:

7

On 01/27/2015 06:40 PM, Michael Godfrey wrote:

Unless there is something blocking default, why not just make one
release (default already has all the
GUI code).

We deprecated some things in 3.8 that have already been removed from default but not gui-release.  Normally we have one release that still contains the deprecated functions but warns if they are used.  Skipping the gui-release release and going straight to default would break this promise that we normally make.  Not a huge thing, I suppose, but something we should consider if we decide to just release default.

jwe

I don't think we want to wait much longer for a GUI release.  The development branch continues to make great strides, but it is rapidly diverging from the gui-release branch.  I would prefer to see us keep the promise about maintaining deprecated code for two releases.

In terms of what to do, there is a checklist of activities for a release on the wiki at http://wiki.octave.org/Roadmap.  One of the first priorities is figuring out which bugs require fixing before the release and which would only be nice to fix.  In the past we have tried to fix all segmentation faults, all regressions, and any bugs with a severity > 4.  A quick search on Savannah shows that there are 38 bugs marked as crashes.  One thing that becomes apparent is that the GUI has a lot of trouble running and plotting under Mac OS X.  Certainly we will need to have some sort of solution for that OS.

My main concern is the slow down in performance in Octave under the GUI.  As a quick gauge I tried runtests on the corefcn directory.  See below.

--Benchmark Code--
more off
t0 = cputime(); runtests ("libinterp/corefcn"); t1 = cputime(); t1 - t0
--End Code--

hg: 101ce4eaa56c (gui-release)

GUI:
./run-octave -f
time : 145.40

CLI:
./run-octave -f --no-gui-libs
time : 80.489

Built with --disable-atomic-refcounts

GUI:
./run-octave -f
time : 126.40

CLI:
./run-octave -f --no-gui-libs
time : 71.136
 
There is about an 80% decrease in performance when running the GUI.  It seems like maybe the update frequency for items in the Variable Browser pane could be slower when Octave is fully engaged making a calculation.

--Rik