Dear Abby,
Matz is going to release 1.8 within the next few days and, quite frankly, I don't think it's ready.
Maybe some Ruby programmers will read this and be mad at me for saying so, but I gotta call it like I see it. Tonight I was able to cause the latest preview to segfault with a relatively simple operation. Who knows how many lurk? I was also *SHOCKED* at how many warnings there were when it was compiled with -Wall (and no, that's not a "Larry" joke). I wasn't expecting a release until Christmas or so, but Matz wants to get a release out in time for Panther it seems.
I know you're always supposed to compile with -Wall, but I often didn't for a long time (except for my own pure C progs) because I was either installing software via pkgadd (which are precompiled) or I assumed that developers of major projects always built with -Wall (if not -Wall -W) so I never really worried about it too much.
My naivete' in that regard is gone. I have entered "CC='gcc -Wall'" permanately in my .bashrc file and I always check the Makefile to make sure that it was picked up. I've also been relentless lately not only in going back over my own C extensions and eliminating as many warnings as I can (some you can't get rid of), but also in letting other people know about warnings in *their* code (in a polite manner, I hope).
Anyway, I'll just keep submitting bug reports in the meantime.
Yours truly,
Frustrated
I agree with you. As much as I would want it released now, I would rather it be released when it is ready and not to make a OSX release.
I do wish speed would be a focus as well.
Re:Oh my!
djberg96 on 2003-07-31T20:25:14
I suspect a few others feel the same way. Note the delay announcement from Matz."I do wish speed would be a focus as well."
I agree. I've already brought it up on the ML in the past, with benchmarks so there's not much else I can do. There are a couple places where 1.8 is faster (especially on Windows) but overall it's slower.
We need to get some hardcore C hackers to come in and go over the code (especially io.c) with a fine-toothed comb.
Its only been two years since we turned -Wall on in Perl. It took a lot of work (something like 50 patches between 5.6 and 5.8) to clean it up, a few months before we knocked out most of them. There was some bitching because a lot of the warnings weren't "real" (ie. they didn't reveal a problem) and a bit of hell to walk through WRT unused variables and all the #ifdefs, but in the end it was worth it for a clean build and finding a bunch of little nigling bugs.
Its interesting to look at what building Perl used to look like. All the warning squashing that went on through May and June 2001 (I'm still shocked that I was capable of that much C programming). Also to read the discussion of whether or not we were ready to turn on -Wall by default.
I think what I learned out of that was that building a C program is so noisy, most people never notice compiler warnings. That and retrofitting -Wall onto a large, hairy C program is daunting but possible.
