Re: Release Plans

[PhilipNienhuis]

John W. Eaton wrote
> I would like to aim for making a new stable release by the end of
> June (this year).

Would it be a 3.8 or a 4.0?


> My goals are listed below.  If there are other significant items that
> should be addressed, then post them here.  But I would like to keep
> the list short so that we have the best chance of making a release in
> finite time.
> 
>   * A working GUI enabled by default
> 
>     - Most necessary features are implemented.  The focus now needs to
>       be more on fixing problems with the features that are implemented
>       and less on adding more features.

Indeed.
Especially the Windows terminal needs attention but you are working hard to
iron out the wrinkles. Thank you very much for that.

I'm using the MXE build on a daily basis for work now and in spite of some
comments about its buggyness I've read here, I find it already very usable.


> <snip>
>   * Release with Java enabled by default.  The JVM is not loaded
>     unless it is needed, so having Java enabled by default should not
>     cause trouble for users unless they actually want to try using
>     some Java functions.  The only exception is that the dialog
>     functions attempt to use Java if the Qt versions are not
>     available, but I think that will be a tiny minority of users.

What trouble do you refer to? Loading of the JVM?
By supplying a java.opts file with carefully chosen values (sufficiently low
amount of initial memory, say 16 MB) this issue can be mitigated. Java has a
sophisticated garbage collector so if methods and objects are unloaded
properly, JVM memory shouldn't be an issue.

The dialogs accept and yield native Octave types so I don't expect problems
there.
Note that these dialog functions were modeled after the Matlab/Java dialogs
and the Matlab GUI used to be built upon Java. So even if a user gets
Java-based dialogs, the upside is that at least they are ML-compatible :-)


>   * Release with the JIT compiler disabled by default.  The JIT
>     compiler does not currently compile very many things but a bug in
>     the way it compiles and executes a loop would be bad for many
>     users.  I also don't think it has had the testing it needs to be
>     considered ready for release.

A while ago I tried to have Java support compiled in via MXE but I got
untractable (for me) configure errors (I reported about them here early
March but got no response). 
Same happens for JIT. I saw that llvm is built through MXE but is isn't
included in the build, it is configured "out" in src/octave.mk.

Maybe the updated MXE build tree from 6 weeks ago has fixes for this?

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Release-Plans-tp4652127p4652146.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.