|
Being on the road with the DobbsMobile means that Al gets a Linux editor and compiler—almost.
July 01, 2001
URL:http://www.drdobbs.com/i-almost-get-a-linux-editor-and-compiler/184404693
Al is DDJ's senior contributing editor. He can be contacted at [email protected].
I wrote last month about an editor problem with Linux and the KDE 2.x GUI operating environment. None of the GUI text editors has a font that people can read, and you can't change their fonts. Turns out the problem exists only with more current versions of KDE and its applications. I'm writing this column on a Linux P120 laptop that has RedHat 6.2 and KDE 1.1.2, which is old stuff and which I installed because it's the only distribution I have that fits on this old laptop. KDE's recent incarnations have gone the way of that other, commercial, one-world-order GUI product. KDE is chasing the heavy metal. You need a fast processor, lots of memory, and lots of hard disk to install and use the latest version.
But why, you ask, would I waste my time puttering around with antique hardware and software? Well, just now I am enduring a Spartan existence in the DobbsMobile RV far away from the comforts of home and office. We're parked in a field on a farm in rural Pennsylvania. We don't have Internet access or e-mail. Cell phone service is sporadic at best. Regular phone service at the house involves a hand crank and a lady whose nickname is Central. RVs like the DobbsMobile require hookups for 50 amps, water, septic, and cable. Forget it. We're plugged into a fuse-protected low amp circuit usually dedicated to an electric fence. Water comes slowly down a long garden hose from the barn, so we can't take a shower when the pigs are getting a drink. We dump wastewater into a groundhog hole. Sitting in a valley, there's no TV, just polka music and grain futures on the radio. Those "Survivor" wimps got nothin' on us. This is hard living, midst the flora and fauna, next to the land, at one with nature. You can't even drive fast around here; you might crest a hill and run right over a horse-drawn carriage with a bearded old driver in a black hat.
To add to this self-imposed misery, my new laptop is in the shop getting repaired. I had to dig out this low-speed, low-capacity laptop from the junk heap to bring along to the boondocks. I should explain that since I am writing this column from memory without the benefit of lab notes or the Internet for reference, I might not remember the names of things, people, and URLs, so I'll sidestep identifying them where necessary. If you really need to know, drop me a line. By the time you read this, I'll have returned to the 21st century (or, as some of my critics will suggest, some time before that).
It wasn't supposed to come to this. I did not intend to be away from home this long. We arrived in the mountains of central eastern Pennsylvania for Easter and saw the buds and blossoms of spring straining to get out and birds eyeing one another nervously all over the place. No way am I going to miss this by heading back to Florida where it was spring for two days in January and has been summer ever since.
Besides, there's the food. Scrapple, kielbasa, sauerkraut, all out of this world. I went into a local joint the other day, stepped up to the counter, and ordered a Polish sausage and a quart of beer. "You're a voter from Florida, aren't you," said the guy. "Yes," I said, "how did you know?" He answered, "Because this is a hardware store."
(Rim shot on the snare drum!)
But don't feel too sorry for me. I installed Linux on the old P120 on my way out the door and tossed it in the RV for the trip. When I first fired it up to do some writing, I got a real surprise. Although this relic is a real slug under Windows 98 (which is why I replaced it), it runs Linux just fine. So, professional Windows programmers, don't give that two-year old computer to your nephew just because Redmond's biennial hunger for more cycles and bytes has made it obsolete. Keep it, install Linux on it, and have some fun at home.
I discovered another bonus when I started writing this month's column. Since my laptop's hard disk is too small for the latest distributions, I found that it actually has decent GUI text editors, too. What's that, you ask? Why does an older Linux distribution have superior text editors than the newer ones? I wonder, too.
One of the better Linux GUI editors is kwrite, the so-called Advanced Editor program that later KDEs sport but with the font-selection feature missing. Another is kedit, also with font selection in the old versions but without it in the new. Both programs have their own mutually exclusive strengths and weaknesses. An ideal editor would eliminate all weaknesses and combine all strengths. These two programs will serve as the model on which I shall base my own editor when I get around to porting it to Linux. I cannot imagine why more recent distributions of these programs disabled font selection. Or, given that they did, why they used an unreadable font as the default. Maybe it's another of those hidden options I haven't found yet. I'd RTFM, but there ain't no FM.
(Editor's note: Al reports that when he got back to civilization, he found the option, which had been moved.)
Last year's kwrite is almost cool. Besides font selection, it has syntax color highlighting for several programming languages, a good undo feature, limited optional word wrapping, and is smart enough to know that text files for UNIX, MS-DOS, and the Mac use different end-of-line conventions. Kedit isn't quite as cool, having no undo feature, but it does integrate with a spell checker if you install a package named ISpell. The first thing I plan to do when I get home is replace kwrite and kedit on my Mandrake Linux 7.2 KDE 2.0 systems with the older versions from Redhat 6.2. Assuming they install, that is. You might recall my discussion a couple of months ago about the Linux dependency carousel. This kwrite program will be my primary editor for a while. It could be the answer to my editor prayers and could mean I don't have to write my own editor, if only it wrapped words more intelligently, had macros, and would launch a compiler.
Unfortunately, this laptop does not have a compiler to launch. Because of the small hard disk, I had to choose between a GUI or compiler support. I think I made the wrong choice. Everything's pretty but I can't do anything.
Since I have a Linux laptop that won't really do anything for a programmer except edit text, I might as well use my time constructively. To that end I am learning bash, the command shell that seems to be the de facto standard on Linux and other UNIX derivative operating systems.
Bash is one of the GNU project programs and, consequently, free to be used and redistributed under the GPL. It is one of several shells available, others being the Bourne shell (sh), the C shell (csh), so named because its script programming language resembles C, and the Korn shell (ksh), a commercial product. The C shell is installed with Linux but there are no man or info pages to explain it in this distribution. I'd rather learn the C shell because I already know C, whereas bash's script language uses its own syntax, and I hate learning new programming languages. But virtually all the configure and install scripts that come with open-source programs are written for bash, and if you want to understand those scripts, you have to know bash. By convention, such scripts begin with a command that starts bash just in case you happen to be using a different shell.
Bash stands for "Bourne Again Shell" because the original sh was written by a programmer named Bourne and was called the "Bourne shell." After you regain control of yourself from laughing your insides out at the pun, I'll continue.
I brought along a copy of Learning the bash Shell, Second Edition, by Cameron Newham and Bill Rosenblatt (O'Reilly & Associates, 1998). I really like this book. My creaky old laptop is perfect for this exercise because all I need is a command-line interface and the typical UNIX command set. To learn bash, you just start at the beginning of the book, read it in the order of its presentation, which is well organized in a tutorial sequence, and try out all the commands and scripts the book gives as examples. Some of them assume filenames that you might not have, but the book is careful to tell you when it makes such assumptions. Some examples use commands that are UNIX command programs rather than intrinsic shell commands, such as awk and find, and the book assumes that you either understand the tool or don't need to in order to understand the lesson being taught.
If you go all the way through the book doing the examples as you go, you will know bash pretty well when you are finished. After that, the info pages that Linux installs should suffice as an online reference.
When I made the switch to Linux, I announced that I was leaning toward KDE as a development and target platform. Recently I started pulling back from that decision because the KDE application framework class libraries do not use namespaces, the Standard C++ Library and its STL container classes, or any other modern Standard C++ features. A member of the KDE application framework development team told me that those omissions are intentional. KDE has to support many diverse platforms where compilers are not in place that include the latest standard features. I can understand that, but the argument does not convince me to step backwards and use old language technology, not when my job is to report on new language technology. Then he told me that they specifically avoided STL because STL performs abysmally with GCC. This got me to thinking and remembering.
Last year I expressed an opinion that programmers might want to avoid the Standard C++ Library and stick with the legacy C++ library because of increased binary sizes and longer compile times. I used the mingw32 Win32 port of the gcc 2.95.2 compiler and an experimental version of the GNU project's Standard C++ Library that had been ported to mingw32 and compared the two libraries with the same compiler. Then I made the mistake of tossing in comparisons of Borland and Microsoft compilers on the same platform against the same two-library benchmark to see if they exhibited similar degraded performance with the new library when compared with the old. (They did, but not as dramatically.)
Mistake, indeed, because the results, which made VC++ and BCC 5.5 compilers look better than GCC, generated a flurry of flames from Linux programmers who thought I was maligning their beloved platform by comparing it to the vastly inferior Windows, an interesting reaction since: 1. I was comparing libraries not compilers; 2. I ran all the tests on Win32 and spake nothing about Linux; and 3. GCC ain't exclusively a Linux compiler suite in the first place, so why did those particular programmers get their briefs in a bunch, anyway?
They all — every one — proceeded to invalidate my conclusions by running their own benchmarks and reporting to me that under Linux, the new library caused no performance degradation whatsoever. None of them knew how to invoke the new library, even if they had it installed, however, so all they did was compare the old library with the old library. When I pointed that out to each of my outraged correspondents, I was met with dead silence rather than heartfelt apologies. Sometimes I think Red Hat and Mandrake ought to include a tube of Clearasil in the box.
At the time I ran those tests, I thought that perhaps the experimental library was at fault, that it was not optimally coded, a forgivable sin for an experimental, beta library. But KDE's experience with STL made me think again. Maybe it's the compiler. The Standard C++ Library is built mostly of template classes and functions. So is STL (which is redundant to say since STL is now part of the Standard C++ Library). Perhaps my results with standard stream classes and KDE's results with STL were best laid at the feet of the same culprit. Perhaps the GCC compiler does a lousy job compiling templates.
To dig a little deeper into this question, I decided to see if GCC's compiler and library technology has improved since my original experiments. The first thing I found was that GCC is released in a new Version, 2.95.3. The second thing I found was that the experimental library is up to Version 3 and is now the default library being released with snapshots of newer beta versions of the compiler. GCC Version 3.0 is scheduled to be released in the first half of 2001, which is now, but the release hasn't happened yet. Not to worry, says I, I'll just install the newest compiler and newest library and run my tests.
Stay with me now; this gets complicated. The web site for the Standard C++ Library includes instructions for installing the library with GCC 2.95.2, which was the released version of the compiler for a long time. There are no instructions for installing the Version 3 library with GCC 2.95.3, the latest released GCC version, and not surprisingly, the installation did not work. (The term "released" gets confusing here. There are released versions of the compiler and released beta snapshots of the compiler and library. No version of the library has been officially released except as a beta snapshot.)
I sent e-mail to the web site's author asking how I should go about doing the installation. His response was, essentially, you don't. The library developers are concentrating on the newer compiler, to be Version 3.0, and ignoring anything previous that has been released. If I want to use the very latest stuff, I'll have to download a recent snapshot of the beta compiler and install the beta library with that. I don't like to use that many unreleased tools, but it looked like there was no choice. The compiler project's 3.0 web pages include some good intentions about fixing the compiler so it works well with the new library in recognition, I suspect, of the current slow, bloated template GCC implementation.
Getting on board with the newest compiler stuff will let me rerun my benchmarks to see if GCC is going to be a viable compiler for templates. If it is, then I am a leg up on the application projects I have planned and can count on using contemporary C++ idioms. There is no doubt about it; I need the latest snapshots.
A snapshot is the daily copy of an open-source product's source code as it has been accepted for testing by whoever controls the project. You can download a snapshot, build it on your platform, and test away. The source snapshots for the compiler and library are each many megabytes of compressed data. Without a high-speed connection, you wouldn't want to download one or two of them every day. Fortunately, you don't have to. You can subscribe to their CVS service and, after downloading the whole enchilada the first time, get only what you need to update the source-code base for each subsequent snapshot. That's what I decided to do and that's where I was when this trip came up. Consequently, I haven't yet run my benchmarks and haven't determined whether Linux is to be the Standard C++ development platform of my dreams.
Using the newest compiler isn't always the smartest thing you can do. When Red Hat released Version 7.0 of its Linux distribution last year, it did a dumb thing — they put an unreleased snapshot of the GCC compiler on the system as the default C/C++ compiler. I think it was 2.96, which was an internal snapshot not blessed by the GCC project and not capable of compiling the Linux kernel. No one could believe Red Hat did that. An outcry went up from developers who figured they'd been snookered. Linus Torvalds went public with a statement to the effect that in his opinion, Red Hat Linux 7.0 was unusable as a development platform. A lot of dedicated Red Hat users switched to Mandrake in protest. Red Hat did a lot of spin doctoring trying to justify their action, but I don't think it helped their credibility. How many ways can you say, "There's a really good reason we did a really stupid thing," and get anybody to listen.
What wasn't mentioned when the cries of "foul" went up is that RedHat 7.0 includes a perfectly good compiler. They call it "kgcc," it's a renamed version of GCC 2.95.2, and Red Hat installs it if you specify you want to do kernel development. That's not any comfort to programmers who download snapshots of applications, tools, and utilities and expect all the configure and install scripts to work.
That's the old news. Now for the new news. As I write this column I have in my mitts a release candidate copy of RedHat Linux 7.1. I am dying to know which compiler is included so I can tell you, but this old laptop won't even consider upgrading enough of a system for me to find out. It'll have to wait until I get home, which happens after my deadline for this column has passed. I'd call them and ask, but Sarah down at the telephone exchange can connect you with Juanita at the diner, but she's never heard of Red Hat.
(Editor's note: Al reports that 7.1 ships with the unauthorized 2.96 compiler.)
Of course, none of my installed Linux distributions has the new 2.4 kernel, which Linus Torvalds released earlier this year. That's another reason I want to install RedHat 7.1, which should be released by the time you read this. It probably won't include the new GCC compilers and standard library. Eventually some official distribution will include all that along with the latest KDE. Of course, by then lots of new beta releases will be floating around out there and nothing will ever settle down.
Is this a bad thing? I don't think so. As long as I keep spinning my wheels building a development system and getting it completely up to date, as long as the open-source community keeps releasing new snapshots, and as long as I have to wait for that next release of that next tool I can't live without, I don't have to do any real work.
DDJ
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.