Thursday, January 12, 2012
Just to make sure, I did my “once-a-decade” check of an IDE. Yup, I still hate 'em.
My first exposure to an IDE was in the mid-80s with Turbo Pascal 3, and I hated it. Not the language per se but the editor. By then, I was used to IBM's PE (version 1.0—never found a bug but there were a few limitations, mostly due to it being able to run under MS-DOS 1.0) with it's true block copy, the ability to move anywhere on the screen and type (and have it insert spaces, if required) and fairly pneumonic keybindings, so I had some issues with how Borland thought an editor should work.
I found it a nightmare.
And then when Turbo Pascal 4 came out, with an entirely new interface where they tried (and in my opinion, failed) to do “windows” in a text mode and well … it took a bit over a decade for me look at another IDE.
By now it's the late 90s, and I'm working on Brainstorm. One of the first Java IDEs came out (and I have no idea what program it was or even what became of it). I thought I'd give it a try as I was curious if it would handle an existing project.
It didn't.
My code killed it. I suspect the programmers of that IDE never thought that anyone would bother with writing their own layout manager, and I recall the dialog went something like:
- IDE
- What … is your language?
- Sean
- Java.
- IDE
- What … is your quest?
- Sean
- To compile this Java code I wrote.
- IDE
- What layout manager are you using?
- Sean
- Really? I wrote my own.
- IDE
- Huh? I don't know that [falls over the Bridge of Death into the Gorge of Eternal Peril] Auuuuuuuuuuuuuuuuuuuuuuuugh!
Scratch another IDE off my list. And a bit over a decade passes.
We're doing a lot of Java programming at The Ft. Lauderdale Office of The Corporation and most of the programmers are using this IDE called Eclipse (we doing both backend stuff and Android development). I've heard of it. Nearly all Java programmers swear by it. I figure I'd give it a go, if only as an source code/object viewer. I suck down the 300+ megabyte package that Ubuntu offers overnight and give it a go.
And … yeah. I have no idea what I'm doing. Why does it want a “workspace?” How do I load an existing project into the darned thing? Why is the Android Eclipse extension failing? Oh, the “stable” version that Ubuntu coughed up is more than twenty minutes old, and therefore, an ancient and decrepid piece of XXXX. I should know better by now.
So off I go to the Eclipse site, and I'm faced with a dozen different options for Eclipse. Wait? There are three different versions for Java, one for C/C++? One for Javascript? Wait? I thought Eclipse could work with a bunch of different languages. Shouldn't these all be modules or extentions or something? You mean I have to download a separate version for each language I want? And what's with the three Java versions?
Auuuuuuuuuuuuuuugh!
And off I go the Bridge of Death into the Gorge of Eternal Peril.
Okay, so I pick one, download it, figure out I can just run the darned thing and don't have to install it. Okay, the Android extension (another umptillion bytes) installs fine, and I figure out that I can use the existing project, but only if I build it from the command line first (um … isn't that kind of defeating the purpose of an IDE?) and neither I nor J (office mate) can figure out why I'm getting these two errors about overriding an interface (which is the point of an interface—you override it). If I do the so called “quick fix” that Eclipse suggests, it fails on the same line with a different error.
Sigh.
The Android Emulator runs the code just fine … I guess … since I'm supposed to test this code. But i can launch the compiled application (compiled via command line) on the emulator, so the code works (and no errors from the command line compiler there). It's just that Eclipse doesn't like the code.
Par for course. Of course.
I can still use it to browse the code, and follow the relationships of
all the objects. And indeed, one of the warnings that Eclipsed barfed up
did indeed turn out to be a real bug (an unused variable that turned out
should have been used). So that's good. But all the other warnings are
bogus, as “fixing” them causes other errors. So I have to pretty much
ignore all that, and just use Eclipse as a glorified version of
more, only one that automagically cross references
everything.
Oh, and it gets hopelessly confused when I checkout new versions from the source repository and have to manually tell Eclipse to reload the changed files, instead of having it just figure it out on its own.
It's comical, I tell you.
If that wasn't fun enough, I figured I try out the “C/C++ version” of Eclipse, if only as a code browser (since we do have some C++ code, and the call depth does make it rather difficult to follow using a more traditional, but less flaky, text editor). So I download that version. I'm still not quite sure what the “workspace” is, since when I point the “workspace” to the top level directory of our existing C/C++ codebase, it does nothing. No, I have to select a “new project” which is an “existing project,” none of which exactly matches what we have, but I select the one that most closely, but not exactly, matches what we have only to have Eclipse immediately wet its pants and dump core, all over the place.
Now, I thought Eclipse was written in Java, a managed
language that produces not real machine code, but virtual code that
is then emulated by a runtime engine—the whole “write once,
debug run everywhere” schtick. How does that dump
core? What's wrong Eclipse? You can't deal with 2,100 source code
files?
Okay, what about something smaller? How about SPCDNS? It's C. There are only eight source files, only two of which, one code and one header file are absolutely required for the project. How about that?
Oh, I see you're still horribly confused from the previous 2,100 file codebase. Okay, I delete everything you touched, re-extract from the downloaded tarball and try again. Feel better? Should I lay out some newspaper in case you barf again? No? Okay.
Hmm. I still don't fully understand this business with “workspaces”
but whatever. Here's the top level directory for SPCDNS. Oh, you can't
find anything. Start over. Here's the source directory for SPCDNS. Ah,
you like that. But you can't build, because the Makefile is
missing.
Seriously. Eclipse. You can't deal with a Makefile one
level up? Oh for crying out loud …
Start over. New project. Entirely new project. Oh look, one of the
options is for autoconf. I've
never bothered with that, but maybe Eclipse can show me a thing or two about
… oh never mind, that's right. My Ubuntu install is now fourty minutes
old and the installed autoconf might as well be in Sumarian for
all you care, Eclipse.
Start over. New project. Makefile. GCC. New file. dns.h.
Load it up in another text editor, select all, copy. Paste into Eclipse.
Seriously, Eclipse? 600 errors? It's a XXXXXXX header file! You don't have to compile that!
Okay, let me continue with the C code. Load codec.c into a
text editor. Select all, copy, paste into a new file in Eclipse. Oh, now
it's 1,234 errors? Oh, you don't like the restrict keyword …
what? You don't understand C99? Don't worry, Mark doesn't care for C99
either, so you're in good company there, but … really?
Start over. New project. Pure C. Makefile. GCC. Check the options,
ah, find where I can specify C99 on the command line. Select, copy, paste
dns.h into Eclipse. 600 errors. Okay, okay, I'll include the
XXXXXXX headers you want. Happy? Okay, on to
codec.c. Two warnings this time, about two unused
functions.
Really? Those are unused? Okay, I'll remove one of then, and the prototype and—
Eclipse?
Eclipse?
Where did you go?
You puke and dump core again?
You're written in XXXXXXX Java! You shouldn't be able to crash!
Bah!
I still hate IDEs.
The proper care of cast iron cookware
Bunny and I got into a heated discussion over the proper way to clean a cast iron skillet and in the end, I had to do some searching. So, for the record, the proper way to clean your cast iron cookware, and while we're at it, reseason (or recondition) your cast iron cookware (even if you think it's given up the ghost).
99 ways to program a hex, Part 4: C99
Today's variation: C99.
/*************************************************************************
*
* Copyright 2012 by Sean Conner. All Rights Reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* Comments, questions and criticisms can be sent to: sean@conman.org
*
*************************************************************************/
/* Style: C99 */
#include <stdio.h>
#include <ctype.h>
#include <string.h>
#include <stdlib.h>
#define LINESIZE 16
static void do_dump (FILE *,FILE *);
/****************************************************************/
int main(int argc,char *argv[])
{
if (argc == 1)
do_dump(stdin,stdout);
else
{
for (int i = 1 ; i < argc ; i++)
{
FILE *fp = fopen(argv[i],"rb");
if (fp == NULL)
{
perror(argv[i]);
continue;
}
printf("-----%s-----\n",argv[i]);
do_dump(fp,stdout);
fclose(fp);
}
}
return EXIT_SUCCESS;
}
/******************************************************************/
static void do_dump(FILE *fpin,FILE *fpout)
{
unsigned char buffer[BUFSIZ];
size_t offset;
size_t bread;
offset = 0;
while((bread = fread(buffer,1,BUFSIZ,fpin)) > 0)
{
unsigned char *pbyte = buffer;
while (bread > 0)
{
char ascii[LINESIZE + 1];
fprintf(fpout,"%08lX: ",(unsigned long)offset);
size_t j = 0;
do
{
fprintf(fpout,"%02X ",*pbyte);
if (isprint(*pbyte))
ascii [j] = *pbyte;
else
ascii [j] = '.';
pbyte ++;
offset ++;
j ++;
bread --;
} while ((j < LINESIZE) && (bread > 0));
ascii [j] = '\0';
if (j < LINESIZE)
for (size_t i = j ; i < LINESIZE ; i++) fprintf(fpout," ");
fprintf(fpout,"%s\n",ascii);
}
if (fflush(fpout) == EOF)
{
perror("output");
exit(EXIT_FAILURE);
}
}
}
/***************************************************************/
It's not much different than the C89 version. The main difference is the ability to
declare variables when needed instead of the beginning of a block of code.
I don't particularly care for that feature, but I do like the
ability to declare variables inside the for() statement, like
I've done here.
