* 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.