[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" sh
From: |
Lachlan Andrew |
Subject: |
[Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" should only warn in user code |
Date: |
Sat, 05 Sep 2015 23:42:26 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 |
Follow-up Comment #2, bug #45878 (project octave):
Thanks for the reply, Carnë.
I am happy to accept that my expectations of the warning were wrong. In that
case, what is the purpose of the warning? If it has no purpose, then we could
simplify the code by removing it from the code base :)
The issue of packages being treated as user code is a good point that I hadn't
thought of. However, it would be a simple matter of to provide a list of
paths from which incompatibility warnings should be ignored when they are
raised.
I really don't think that it would be that hard to implement what I am
proposing, and I'd happily attempt it if I thought it would get merged
upstream.
On a related note, I have often wondered why Octave .m files deliberately use
a syntax incompatible with Matlab. I can see a reason for using true
enhancements, like the ++ and += operators, but what benefit is derived from
replacing ~ by ! and % by # and ' by "?
If all packages were written with Matlab-compatible syntax, except where using
true enhancements, then they could be used (perhaps with some minimal porting)
by people who buy the base Matlab product but want to use free software for
the toolboxes.
I know that Octave didn't start off as just a Matlab clone, but I think most
people regard it as such now. Is the reason for the different syntax just to
argue that Octave isn't a Matlab clone?
As an example, I needed some features of kmeans that weren't yet implemented
in Octave, and so I rewrote Octave's kmeans to provide almost all of Matlab's
functionality. Now I want a minor extension that isn't in Matlab. As a
result, I have to maintain two versions of the code -- one using #, ", ! and
one using %, ', !. That is just a waste of effort that I could use for fixing
other Octave bugs. (I'm happy to write rows=@(x)(size(x,1)) at the start of
the code; that doesn't require maintaining two sets of code.)
Thanks for the link to stack overflow. What that gives is one down-vote from
you, and three up-votes from others who share my view :)
To everyone: Are there other core Octave people who consider
incompatibility-for-the-sake-of-incompatibility a benefit?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?45878>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" should only warn in user code, Lachlan Andrew, 2015/09/05
- [Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" should only warn in user code, Carnë Draug, 2015/09/05
- [Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" should only warn in user code,
Lachlan Andrew <=
- [Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" should only warn in user code, anonymous, 2015/09/06
- [Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" should only warn in user code, Mike Miller, 2015/09/06
- [Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" should only warn in user code, Michael Godfrey, 2015/09/07
- [Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" should only warn in user code, Lachlan Andrew, 2015/09/08
- [Octave-bug-tracker] [bug #45878] warning "Octave:language-extension" should only warn in user code, Mike Miller, 2015/09/12