* On Wed, 14 Jul 2010, Chris Robinson wrote:
- On Wednesday, July 14, 2010 5:02:59 pm Max TenEyck Woodbury wrote:
'FIXME's that contain no variable information are completely redundant after their first report. After the first reminder, the additional reports are just noise. They add no additional information in terms of action required.
I wouldn't say that. Sometimes the simple knowledge that a FIXME is called a whole lot says enough on its own (eg, in WineD3D, you get a fixme when an sRGB reload occurs, because it's a performance drain; if this happens a lot, it can be taken as a source for performance issues). Sometimes knowing particular a fixme is triggered near to a crash or other behavioral anomaly can say a bit, too.
Although I stand for *_ONCE implementation, I agree with Chris.
And there might be some alternative: lets then implement it like a
FIXME_ONCE_PER(N)("a_debug_string");
Which could print something like a
"fixme:channel:a_debug_string [repeated N times]"
This would not oly still tell you approximate frequency of a FIXME, but it also would require developer to know reasonable occurence quanta value (N) or to tune it later. This (for me) sounds like a way to know the code's stochastic behaviour better! Which would be a plus.
If such fixmes were only printed once, it would be impossible to see this information without more in-depth testing that most users won't bother with. If the fixme is only printed once and the rest are TRACEs, it would still cause more work and a whole lot more noise (ie. all the other traces) in trying to spot it.
TRACE_ONCE probably could help in some cases too. There I see another constraint of *_ONCE functionality. "Once" could be per block (eg. for-loop), per wrapping function call, per process or even once per thread's life.
Implementing all onces might be difficult, IMHO. Though not all of them could be necessary, probably.
* On Thu, 15 Jul 2010, Dmitry Timoshkov wrote:
The patches which silense some FIXME's have been accepted as an exception. That covers the code which is unlikely to be fixed in near future, or the code nobody is working on.
Then at least replacement of these (ugly by their size, IMHO) silence-blocks with a simple FIXME_ONCE seems rational.
S.