Re: Getting working version?

[James Frye]

On Sat, 28 Dec 2002, John W. Eaton wrote:

> I doubt that this is really due to a bug in Octave (the current
> sources compile cleanly for me with gcc 3.2 on a current Debian
> system).

I suppose this depends on one's definition of bug.  As someone trying to 
compile source code, and finding that it won't compile with the same gcc 
compiler version that I've been happily using for the last year or so... 
well, that looks like a bug to me :-)

> What compiler are you trying to use?  For the CVS version, I think I
> already told you that you will probably need gcc 3.2.  If your
> compiler doesn't understand ::isalnum, then I'd guess it is not
> good enough to compile the current Octave sources.  But gcc 3.2 should
> work and it is freely available, so you should probably upgrade if you
> want to build Octave.

gcc 2.95.  And why should the compiler understand ::isalnum?  I don't :-)
>From context it would appear to be calling the standard C library function 
isalnum, but why gunk it up in extra syntax when the plain ordinary 
function should be available, probably with less overhead?

> Are you referring to Octave sources, or something else?  I don't think
> Octave relies on too many arcane langauge features, and I think my
> development of Octave has been quite conservative with respect to new
> langauge features.  

Octave sources.  Look, I've been doing serious programming for a couple of
decades now, and this is the only instance I can recall where I had to
upgrade a compiler to get something to compile.  (Not that it's perfect
even now: with gcc 3.2.1, I get messages about "Dwarf errors".  The make
builds and installs the executable, which runs at least some simple tests,
but now barfs on calling eval in the .m files I want to use.)

> Even now, you can't expect that any serious C++ project
> will compile with any and all C++ compilers.  Someday, maybe, but for
> now the compilers still seem to be catching up to the standard, so
> these kinds of problems are likely to be with us for a while longer.

Pardon my flaming here, but isn't that a somewhat backwards attitude?  
Writing code for some mythical handed-down-from-on-high standard, and then
complaining that existing compilers just aren't good enough to compile it?  
C++, or any computer language, is a tool, not a frigging religion.  You
don't get brownie points for the purity of your code.  All us agnostic
user types out here care about is whether it runs or not :-)

> As it is, I think you've already received quite a lot of support for
> free (I implemented "end" and local functions just recently, in part
> because of your requests).  

Though I asked for only a small fraction of it.  Remember that my requests
were not for you or anyone else to change octave code, just for
suggestions on how to work around the differences between it and Matlab.

> Would you care to give something back to 
> the probject (code, or perhaps funding to help pay for the cost of
> providing the new features you requested or to make binary packages 
> available), or would you just like to complain about what you're
> getting for free?

Well, it hasn't been exactly free on my end.  Say 20 hours of work over
the last week, plus extra trips into the lab so I could e.g. download some
24 MBytes of gcc 3.2.1.  At the very least, I've contributed some
practical compatability testing with real-world Matlab scripts :-)

James



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------