This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: enough! (was Re: Intel+Cygnus+Optimized Compilers)


At 05:06 AM 2/28/99 -0800, you wrote:
[More deleted insults ... this seems to be becoming the official
 egcs-list pastime! I would like to see the people here who have been
 to all appearances gradually devolving into subhuman monkey-apes for 
 the past two days sharpen up and resume comporting themselves like
 mature adults, which all of us are supposed to be. What has
 triggered this  degradation of the standard of decency here is
 beyond me, since my own articles are invariably free of personal
 attacks and other such nonsense...]

>Charging for support has been one of the tenets of free software for 
>*_YEARS_*.

I am not disputing that. The original article made reference to "having to
purchase GNUPro", not "having to use GNUPro, which is free but for which
there is a support service that charges a nominal fee for maintaining
Cygnus", and thus it implied that GNUPro was itself a non-free product.
This provoked a reaction of incredulity from me that is understandable,
since I and probably everyone here is accustomed to the equation "GNU
software = open source free software, possibly with an associated fee-based
support service".

>If it wasn't for Cygnus, Redhat, etc.  I don't dare venture to guess where
>free software would be at this date!

Me, either.

>Since you started posting to the list, all I have seen
>from you are rude requests of volunteers...

No request I have made would be considered "rude" by average social
standards. And I have made nothing that could be termed a "demand". Anyone
who interprets one of my messages otherwise, interprets it wrong.

>...demands to fix things which are broken on your side...

Fallacy: there are 3 "sides", my side, your side, and the infrastructure in
between ranging from routers to my ISP's MTA.
Also, I "demanded" nothing. I *reported* what initially appeared to be a
problem with the list server system, since I, being a rational person,
could think of no rational reason why your list server would be designed to
mung messages in a particular way and to expect my ISP to demung them,
instead of merely transmitting them verbatim. Once someone informed me of
this obscure facet of email transmission, it became apparent that the
problem was with my ISP's SMTP server, and NOT with my setup (or with yours).

>...demands to fix things which are documented as incomplete...

Au contraire again. I *demanded* nothing. I *reported* omissions and bugs.
Some of the omissions proved to be things that weren't finished yet, but
they were NOT documented as such in the documentation the average *user* of
egcs would read. People expect to be able to

#include <valarray>

or

int (*foo) (void) throw ();

in their C++ sources and have them compile on a given C++ compiler, after
all. When such things don't work, expect users to be surprised unless the
readme.1st documents that they are known bugs/not yet implemented features.
Please note that the average user of a piece of software will read a small
readme file but will not read a long monolithic document mostly about
cross-compiling setup and installing on certain specific systems... they
will want all the important known bugs and unfinished stuff and
general-interest information in a small readme file that also refers them
to more detailed, separate documents about particularly hairy things (such
as cross-compiling) and to installation information files for various
machines. A documentation tree like this could go a long way to making egcs
friendlier and reducing the volume of spurious and duplicate bug reports on
the list:

egcs
  |___doc
  |    |___'readme'   general interest, points to more detailed docs.
  |    |___installation
  |    |       |_________'Linux'
  |    |       |_________'Sunos'
  |    |       |...etc.
  |    |
  |    |___cross-compiling
  |    |       |...etc.
  |    |___for-developers
  |            |...etc.
  |___src
  |...etc.

>(if you read the faqs you would know that libstdc++ v3 is a
>*_rewrite_*, not bug fixes to v2)

I guess I couldn't find it in amongst all the cross-compiling trivia.
Anyways, it does strike me as odd you'd take a big step backwards like
that. I checked the info on v3, and even the iostreams are incomplete. v2
has working iostreams and other stuff that is *gone* in v3! What gives with
that? It seems silly to start over from scratch instead of just fixing bugs
and adding the stuff that needs adding, such as valarray and numeric_limits.

>...and ignorance of what will be the standard...

I know the C++ standard probably better than you do. I have a book here
that is a fairly detailed reference to ISO Standard C++ and to the ISO
Standard C++ Library.

>(ummm..btw, has it been voted on yet?? Last I heard, public comment
>period had closed....)

Touche. It's a done deed as of months ago.

>I understand that when the following line is included as the
>sole line in a C++ source file, there is something wrong, and the error
>message
>"syntax error" is perfectly fine for me to track down the problem...
>
>extern foo<class T> bar;

With an obviously-broken one line source, a monkey can figure out the
problem and fix it no matter how incorrect the error message. In a project
encompassing over 4000 LOC and growing, figuring out that a "syntax error"
is actually an undeclared identifier which was declared but was just not
scoped correctly is incredibly hard. If the error message had said
"math_traits undeclared" I would have known instantly that a) the bug was
in my code and b) I had forgotten to import it from a namespace where I
declared it. Instead, I was scratching my head for over 4 hours about why a
well-formed, syntactically correct line of code was producing a "syntax
error" and then I submitted a tentative "possible bug" report (note the
word "possible"). Eventually discovering there were actually 2 separate
bugs: one in my code, the namespace scope resolution missing, and the other
in the egcs parser causing the wrong error message to be output.

I can see 2 possible causes for this problem actually.
1. Bug: parser generates wrong error message.
2. Laziness: Someone decided that parse errors were a handy catch-all
   category to use to avoid writing the code to actually determine
   what is actually wrong with some code and produce the right error
   message.

Note that I am not accusing anyone of laziness; I include this disclaimer
because it is becoming sadly apparent that for whatever reason, people here
automatically mentally substitute "demand" for "request" in everything they
read, and mentally replace a list of *possible* explanations with an
assertion of the explanation most insulting to them personally. Why almost
everyone here mentally "post-processes" egcs list mail in this fashion is
beyond me...

In any case, I expect in good faith that case 1 is true. I just state that
from my point of view case 2 exists as a possibility. (If it is true, I
take this opportunity to remind people that parse error means parse error,
and is not to be used as a catch-all category for any error that requires
work to properly identify after the existence of an error is detected, lest
a lot of your users find themselves scratching their heads for 4 hours and
then submitting tentative bug reports that are off the mark in identifying
the precise bug while beiong correct in that there is a bug.)

>...I am a little tipsy (ok, drunk :) )...

Ah. I wonder if a similar explanation can be found for some other cases of
recent misunderstandings here arising from the "post processing" mentioned
above.

Also, I wonder if it should be in some FAQ somewhere to "never killfile
someone when you're drunk".

>...and the bombardment of messages is really beginning to tick me
>off...

Most of the messages on the list not associated with me in some way are
on-topic and meaningful. (Most are also not of interest to me personally,
and so I delete them unread by Subject:, a procedure very useful when going
through medium-to-high-volume mailing lists.) Of the rest:
* My thread-starting messages are on topic, or else they don't quite
  belong anywhere I've subscribed but are more on target here than
  anywhere else. Note that a request I made for information about
  locating other mailing lists to better target these produced no
  useable information.
* My messages following up other messages not related to me are on
  topic, relate to the content of the message I'm following up, and
  are as helpful as I can make them with the information I have at my
  disposal. Note that due to budgetary constraints as well as my
  desire to produce an at-least-somewhat useable response as quickly
  as possible precludes the extensive researching of assorted topics
  tangentially relevant to the discussion that some seem to expect.
  Note also that there is some information I not only simply do not
  have, I also simply do not even know that I don't have it or that
  it could be relevant to a discussion. It is a fact of life that
  on any topic, any human being will lack some information on that
  topic and will also lack the knowledge that that information
  exists or that it pertains to some particular circumstance. A
  matter of not knowing the question, rather than not knowing the
  answer.
* Some messages following up to mine have been uncivil in an
  unprovoked manner, or otherwise off-charter. These are responsible
  for some of the annoyance going around lately, but some people seem 
  inclined to blame the poster of original, inoffensive message
  instead of the poster of the uncouth and offensive followup.
* My responses to flames have been to ignore the flaming portions and
  deal coolly and civilly with what remaining content, if any, was
  of a reasonable and rational nature and to which there could
  therefore be a reasonable and rational response.

In all, I would say I am comporting myself a) better than the average
person would under the circumstances and b) better than some of the other
list subscribers (note: no names).
As for what "the circumstances" are, I have no idea. Messages that are
inoffensive seem to occasionally provoke a virulent reaction from a certain
segment of the population here, if and only if their author is
me...substantially similar messages from other authors receiving no such
treatment. Now that, according to the contents of my inbox, most of that
quick-tempered segment have killfiled me, hopefully most of the
nonproductive noise on the list will subside. As to the cause of the
problem? It seems that some people are given to mistaking requests for
demands, blithely assuming everyone has read every word of a long document
most of which won't specifically interest them and then being unreasonably
offended when it turns out someone didn't read one or two words from it
they probably didn't spot in amongst the uninteresting (to them) parts
whilst skimming, and assuming that if someone posts a list of possible
explanations for something one of which might be taken as a personal attack
against them, that the poster "meant" that that particular explanation must
be the correct one.

I say what I mean; when I say request it's a request; when I say several
things are possibilities I mean they are possibilities (from my point of
view, with the information at my disposal) with no one of them a certainty;
when I ask for information on something I mean that I want information on
something and not assorted diatribes, flames, information of an entirely
irrelevant nature, or silences.

Despite which, I will wager ten to one odds someone reads this message and
instantly flames me on the list, accusing me of accusing him of laziness
and of deliberately munging the error messages his chunk of the parser code
produces.

As for the HTML header flap where I did in fact assert that someone had set
the HTTP server to "touch" HTML files all the time thus blowing the caches
of everyone viewing the web page, to the best of my knowledge at the time
that was true, although it turns out I was mistaken. I made the entirely
reasonable assumption that an HTTP server always sends timestamp
information with a document, since it seemed to me a bug that caused the
glaring omission of same would be improbable in the extreme. That
assumption was faulty because such a bug exists (in Apache, of all the
httpds, to boot!), but it was an entirely reasonable one, and if I
triple-checked every assumption invovled in my day to day life and
thoroughly researched every topic of any kind that came up, I would run out
of time to actually do anything useful! (This is true for all human beings,
weird combinations of time travel/suspension and immortality notwithstanding.)
I might note that I have encountered many sites that are rigged to "touch"
an HTML file just before sending it, to present a false impression of
activity and up-to-date-ness, or else in a clueless and misguided and
equally questionable attempt to make every move a viewer makes cause all
the revenue-generating ad banners to reload and count up more "hits".
(I didn't notice any revenue-generating ad banners on the Cygnus site, of
course; these are just a facet of my little case history file on "Web sites
that fudge their last modified times and cause surfers with slower modems
headaches.")


>(and it takes alot to get me going....I'm a software engineer! :) )

I see no evidence to back up this assertion.


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  |http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]