Compile error in include/Support/GraphWriter.h

Issue: GraphWriter includes <ostream>, which my gcc2 apparently thinks is <ostream.h>.
Fix: Make a new <Support/ostream> that handles this discrepancy, ala <Support/hash_set>.

patch (1.01 KB)

Also sprach Casey Carter:
} Issue: GraphWriter includes <ostream>, which my gcc2 apparently thinks
} is <ostream.h>.
} Fix: Make a new <Support/ostream> that handles this discrepancy, ala
} <Support/hash_set>.
}
Um...was it entirely necessary to issue *8* email messages to the group
with mostly single-line fixes instead of just one email with all of the
fixes and an explanation for each?

Bill? Wendling wrote:

Also sprach Casey Carter:
} Issue: GraphWriter includes <ostream>, which my gcc2 apparently thinks } is <ostream.h>.
} Fix: Make a new <Support/ostream> that handles this discrepancy, ala } <Support/hash_set>.
} Um...was it entirely necessary to issue *8* email messages to the group
with mostly single-line fixes instead of just one email with all of the
fixes and an explanation for each?

Actually, yes it was. Proper netiquette when submitting to a technical list is to have a single topic per message. This makes it easy to track issues individually, without the messiness that occurs from bundling several issues together in a single missive. One large email with a big lump of diffs is much less clear, and takes substantially more effort to parse: Are the patches independent? Which fix corresponds to which problem?

Being new to this group, I am simply acting as my experience dictates and discussing these issues in the way I feel is best. If my infamiliarity with the group causes me to occasionally act against what is common practice here, I will appreciate it when you inform me that I have done so and what the proper approach should be.

Also sprach Casey Carter:
} Bill? Wendling wrote:
}
} >Um...was it entirely necessary to issue *8* email messages to the group
} >with mostly single-line fixes instead of just one email with all of the
} >fixes and an explanation for each?
} >
} >
} >
} Actually, yes it was. Proper netiquette when submitting to a technical
} list is to have a single topic per message. This makes it easy to track
} issues individually, without the messiness that occurs from bundling
} several issues together in a single missive. One large email with a big
} lump of diffs is much less clear, and takes substantially more effort to
} parse: Are the patches independent? Which fix corresponds to which
} problem?
}
Since it's also proper netiquette not to spam too much, this will be the
end of this thread for me.

What you say is all true. However, the changes you made were very small
(though necessary) and not really subject to the difficulties in parsing
through them that you mentioned. Most consisted of single-line fixes (as
I mentioned above), and a lot of them obvious fixes.

} Being new to this group, I am simply acting as my experience dictates
} and discussing these issues in the way I feel is best. If my
} infamiliarity with the group causes me to occasionally act against what
} is common practice here, I will appreciate it when you inform me that I
} have done so and what the proper approach should be.
}
I vote for simple/obvious fixes to be combined in one email. I may exist
as a sole entity in feeling this way, but so be it. If others would like
such fixes to be concatenated, feel free to pipe in. If, on the other
hand, people feel that such fixes should be separated, then the consensus
should win out.

Keep in mind, I'm only suggesting this for simple/obvious fixes. Not for
more complex ones which require more detailed descriptions and are more
properly separated into multiple emails, IMHO.

Democracy is fun :slight_smile:

I'll jump in just to repeat to all listeners what I suggested to Casey:
please send patches to Nick Hildenbrandt (hldnbrnd@uiuc.edu) and not to
llvmdev. I think Casey's right that individual patches are easier to
deal with, but Nick can apply patches and use his discretion about
notifying everyone if a fix seems worth broadcasting.

Of course, patches are very welcome. Casey's fixes have been invaluable
with the Linux port so, for the record, thanks!

--Vikram