Re: 4.4 release plans

[PhilipNienhuis]

John W. Eaton wrote
> On 12/21/2017 02:44 PM, PhilipNienhuis wrote:
>> John W. Eaton wrote
> 
>>>     * Make the variable editor feature of the GUI work properly,
>>> including for structures and cell arrays.  This may require some changes
>>> in the way we communicate between the GUI and the interpreter.
>> 
>> Character arrays (strings as well as 2D arrays) are shown as one
>> character
>> in a cell. For strings that is quite clumsy (IMO).
> 
> Yeah, it's not supposed to work that way.
> 
>> What about "general" objects? (Java, classdef, COM, ...). Currently the
>> variable editor crashes on Java objects. I thought of making openvar()
>> (or
>> its siblings) to only accept those classes / types that the variable
>> editor
>> knows how to show, but I lack the C++ skills to make that happen.
> 
> I think we should just skip those for now.  What does Matlab's variable 
> editor do with them?

last I looked Java and COM objects were just indicated as "Java object" or
"COM object". As for classdef and others I might have overlooked I'd have to
find out.


>> Would you still like spreadsheet I/O (xlsread, xlswrite) in core Octave?
>> I've been working on that and Markus Muetzel wants to help. xmlread and
>> xmlwrite would probably come with it.
>> It would require some discussion on this ML, I think, as there are some
>> complicated choices involved.
> 
> Maybe.  It would be nice to have.  What is needed to move it to core now?

After finishing cleaning up duplicate code (mostly done):

<some background>
Spreadsheet I/O works with a choice of dependencies, "interfaces". Many of
them Java-based, one native Octave. There are many spreadsheet file formats
out there esp. for Excel. Most "interfaces" only support just one file
format, some support a few. Each interface has its pros and cons. This is
the main reason I supplied a number of interfaces in the io package, to give
users some choice. E.g., .ods can be read with 4 or 5 of the interfaces.
An overview is in the NEWS for the io package, see the stanza for release
2.2.2.

* Decide if all interfaces would go over, or otherwise which ones would and
which ones would stay behind in a weeded out io package. (I expect in
practice only the native interface ("OCT") would go over but that is just
me.)
* In case of the latter, create a mechanism to be able to connect the io
package to what is in core. This may require shadowing of core functions.
Some private .m functions might need to be made "public" and have their
function names decorated with __
* Again in case of the latter, devise a strategy for keeping the io package
working with older releases for a while. This is more of a package
maintainers issue, but thinking ahead might help limiting the combined
maintenance "burden" for core and io package.

Would you like me to open a ticket in the task tracker for this?


>> A personal favorite of me is ability to read & write classdef objects
>> from/to .mat files.
> 
> I think making classdef work better may be more of a 4.6 goal for me.

Yeah, I think a 4.4 release shouldn't be postponed for too long.

Philip



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html