Re: The new Octave 3.2.4 MinGW32 and gnuplot issues

[Søren Hauberg]

tor, 22 04 2010 kl. 16:46 -0400, skrev John W. Eaton:
> On 22-Apr-2010, S ren Hauberg wrote:
> 
> | I think it is part of Octave-Forge because many Octave users have to
> | collaborate with Matlab users. So, when you send code to Matlab users it
> | is nice to have some tools to help ensure that the code runs in
> | Matlab.
> 
> So, write your code so that it can run in either system.

I would pity the Octave developer that couldn't use '#' for comments,
'endfor' for ending loops and so forth. On the rare occasions where I
have to use Matlab I always and up yelling not-so-nice words to the
computer because it doesn't support the most basic syntax.

> Is it not intended to allow Octave Forge functions to be converted so
> they can be used in Matlab?  If so, I think that is the wrong thing to
> be encouraging.

Yeah, this package does to some extend encourage people to use Octave
code in Matlab. I am not really happy about this. Similarly, the Windows
binary we provide at Octave-Forge encourages people to use Windows. I am
not really happy about this (a real scientist should never accept any
kind of proprietary software, right?).

That being said, I accept both because

     1. Well, sometimes you just have to be pragmatic. Some people
        collaborate with Matlab users. Others are forced to use Windows
        by their employer. Etc.
     2. The work is maintained by somebody else. As long as I am not the
        one doing the work, I don't want to tell others what is right
        and what is wrong. 

(I guess I am both pragmatic and lazy; not really strong personal
characteristics :-( )

> | Personally, I do not have this issue (I just tell people to use Octave
> | if they want to use my code), but not everybody is in this situation.
> 
> At the very least, the package should be fixed so that the .m files
> that shadow functions from Octave are never installed with Octave,
> since they are apparently intended to replace some Octave functions
> that are commonly used and that are not present in Matlab.  They are
> of no use with Octave itself, since Octave already provides those
> functions.

Ohh, I very much agrees with this. In SVN the package has been changed
such that it is not loaded automatically. This at least prevents the
package from screwing up Octave by default. I truly hope somebody will
fix the issue such that the compatibility functions aren't added to the
path when the package is loaded. If this does not happen, then I will
most likely remove the package from Octave-Forge. I can live with
hosting software that helps Matlab users, but I cannot accept software
that breaks Octave.

Søren