[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving functions from octave-forge to octave

From: Philip Nienhuis
Subject: Re: Moving functions from octave-forge to octave
Date: Sun, 6 Jul 2014 14:24:26 -0700 (PDT)

Sorry one request: please do not top-post. Answer below the mail please,
makes it easier to follow the dicussion.

Ronald wrote
> Op 3 jul. 2014 18:07 schreef "Philip Nienhuis [via Octave]" <

> address@hidden

>>> Ronald wrote
>>> I read a quote from a 2007 thread of John W. Eaton saying:
>>> "any function currently in an Octave Forge package that is in
>>> the list of core Matlab functions is a candidate for moving to
>>> Octave"
>>> So I was wondering if the actxserver function from the windows package
>>> shouldn't be moved to the Octave.
>>> And what about others like for example xlsread and xlswrite from the io
> package?
>>> What would be the criteria for moving an Octave Forge function to
>>> Octave?
>> I suppose one of the criteria is that core Octave functions should not be
> bound to a specific platform.
>> Now, actxserver (a sort of "system library") runs only on Windows, so
> there you go.
>> As to xlsread and xlswrite: the way they are coded now is quite involved,
> precisely because they should be able to work on about any platform
> (currently xlsread/-write can also process gnumeric and ODS). In this way
> the Octave versions are much more flexible than their Matlab counterparts;
> e.g. AFAIK on Mac OSX or Linux Matlab's xlswrite doesn't work very well,
> if
> it works at all. In that sense, ML is way behind Octave.
>> The way Octave's spreadsheet functions are offered now, included in an
> add-on package, is probably the best solution in the foreseeable future.
>> What is it you think you will gain with moving them into core Octave?
>> Philip
> I think it would improve Matlab compatibility and user experience. Matlab
> provides these functions out of the box, and therefore I think it would be
> a good thing if octave would too.
> It is not obvious for people not familiar with Octave to install e.g. the
> io or windows packages when their Matlab scripts fail in Octave. Sure, you
> could argue that they should rtfm or read up on Octave. I think they
> should
> too, but rather because they want to do new interesting things with Octave
> rather than make their existing scripts work.

AFAIK, when someone doesn't have the io package installed and wants to use
xlsread (or any other ML function not in core Octave but in a package) ,
he/she gets a message that it isn't available and what to do about it. Seems
sufficiently obvious to me.

Similar arguments apply to several other functions or even functionality
that Matlab has but core Octave not. There are quite a few of them.

> <snip>
> What do you mean with "involved"? That it depends on things you would not
> want as dependancies? Or that it is complex and may be hard to maintain?
> Or
> that it may behave different (even though it works better than Matlab) on
> different platforms?

All three.
Plus, some Octave users/contributors here have expressed not-too-positive
opinions on spreadsheets & spreadsheet programs. IOW, there are people who
think quite differently than you.

It is possible to just transplant the OCT interface (still quite a
complicated job); no external dependencies required then but it would work
only for some file types, and still a bit different from the way Matlab's
version works, and it would work quite a bit less flexible than it is now.
Regaining the flexibility currently in the io package could then be done by
installing an amended io package, so that its contents would shadow the core
functions. But fixing that in the io package would only be possible with
lots and lots of work; something I'm not quite waiting for.

Anyway I think you've made your point clear; thanks, everyone's opinion is
welcome and in some way useful.

If you are really serious I'll give you a hint of what to do (yes it's the
usual answer you get when individual OSS developers perceive suggested
priorities differently, sorry for that) and then I'll shut up - I'd rather
spend time fixing bugs in the io package (of which I'm maintainer).
Octave is free (as in speech) software; if you want changes, no one keeps
you from making them yourself. If you want those changes to be available for
everyone, present your changes as patches/changesets and the developers may
(or may not) decide in your favor. If you can't patch it yourself, find ways
to convince people to do what you want (maybe hiring developers, or funding
the Octave project might help).


View this message in context:
Sent from the Octave - General mailing list archive at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]