[Top][All Lists]

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

Re: Getting working version?

From: Paul Kienzle
Subject: Re: Getting working version?
Date: Sun, 29 Dec 2002 17:58:54 -0500
User-agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130

James Frye wrote:

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

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 :-)

Yes a bit of grumbling is in order, much like you grumble about going to the dentist. The changes are painful, but they need to be done to avoid more pain in the future. In particular, a number of things won't compile on gcc 3.2 unless you bring them in line with the C++ standard, or alternatively choose
compiler options which supress the warnings about deprecated features.

The alternative to spending effort to develop new features is to spend effort ensuring compatibility in a changing build environment, plus much ugliness with the preprocessor to hide syntax which has changed
since C++ was first proposed.

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?

There is no overhead associated with using ::isalnum. It is a compile-time thing which disambiguates namespace references. ::isalnum is very old syntax. I can't believe that your compiler can't handle it. It simply says use the global namespace for this function rather than the function defined for the class. I first used it in 1995.

As for gunking up the syntax, you can take it up with Stroustrup.

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.)

Then you've lived in a very sheltered world. Every try running some fortran 95 code through a fortran 77 compiler? How about C99 code through an old C compiler? How about matlab 5 code in matlab 4?
Or for that matter, matlab 4 code in matlab 5?

By choosing to follow standards, Octave can hope one day to be able to compile on a variety of compilers. If instead it stayed with g++ deprecated syntax and libraries then it would forever be
tied to running on older versions of g++.

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 :-)

You are missing the point: existing compilers can compile it. You just don't happen to have them

I don't remember the exact details, but IIRC the alternative to moving to gcc 3.2 was to reimplement some code that is in STL so that octave could be extended. That sounds rather like re-inventing the
wheel for the religion of supporting out of date compilers.

I grant that in this case not being able to compile on the largest installed base of linux (red hat 7.x) is a questionable decision (and I did question it myself), but if it is a choice between progress on octave and support for the previous version of red hat, I choose progress with minimal grumbling. FWIW, my main development machine is still running octave-2.1.38 because I don't have space
to build a new compiler.

John, maybe we could indicate the new compiler requirements on the download page, with a suggestion
to use 2.1.38 for older compilers?

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.

Which I gave you.

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 :-)

I started writing a compatibility guide a while ago. See Feel free to send updates, and maybe save someone like yourself 20 hours of work in the future.

It is a little out of date just now since octave is rapidly changing and I'm not actively porting
matlab code.

Paul Kienzle

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

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

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