 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It burns! IT BURNS!! >_<
I especially like the claims of "every time we added debug code, the bug
went away". Surely it is impossible to work under such conditions...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> http://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php
>
> I especially like the last one.
I prefer the penultimate one - the idea of the comedy developer face in the
corner of the screen getting all grr! when the frame rate drops - made me
chuckle.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bill Pragnell wrote:
> I prefer the penultimate one - the idea of the comedy developer face in the
> corner of the screen getting all grr! when the frame rate drops - made me
> chuckle.
Not so much a coding trick as an interesting application of
psychology... but bizare, all the same. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Surely it is impossible to work under such conditions...
Not impossible, but it should make you realise that developing software for
profit is quite different than doing it as a hobby.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Surely it is impossible to work under such conditions...
>
> Not impossible, but it should make you realise that developing software
> for profit is quite different than doing it as a hobby.
It certainly makes me realise that I prefer safe languages over
efficient ones any day of the week. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Bill Pragnell wrote:
>
> > I prefer the penultimate one - the idea of the comedy developer face in the
> > corner of the screen getting all grr! when the frame rate drops - made me
> > chuckle.
>
> Not so much a coding trick as an interesting application of
> psychology... but bizare, all the same. ;-)
Well, it had to be coded, didn't it? :)
He should have made the angrier faces steadily greener! I guess that would have
taken the edge off the psychology.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> It burns! IT BURNS!! >_<
>
> I especially like the claims of "every time we added debug code, the bug
> went away". Surely it is impossible to work under such conditions...
Heisenbugs are always lots of fun. ;)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible schrieb:
> It burns! IT BURNS!! >_<
>
> I especially like the claims of "every time we added debug code, the bug
> went away". Surely it is impossible to work under such conditions...
Well, I tell you that's pure reality. Last project I was working on,
"let's just ship the device with debug output X enabled by default" was
quite a common suggestion during troubleshooting. We managed to keep it
a joke though - the customer would not have been amused.
And some issues we did indeed fix using the "if you're falling through a
hole, don't do it" kind of approach, because the errors occurred so
infrequently that we just had no chance of ever finding the root cause.
Yeah, it's kind of fun developing software for devices where
occasionally the only way to get any helpful debug information out of
the thing is by switching an LED on or off, and errors might just as
well be hardware-related.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible schrieb:
> It certainly makes me realise that I prefer safe languages over
> efficient ones any day of the week. :-P
You can get such issues with "safe" languages, too: All you need is some
race conditions that kick in when performance is particularly good, but
don't if performance is bogged down a deal by debug output.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> I especially like the claims of "every time we added debug code, the bug
> went away". Surely it is impossible to work under such conditions...
That was a relatively common problem in C and C++ years ago, but nowadays
especially C++ compilers have got much better at debugging such things. For
example Visual C++, when compiling in debug mode, will add bounds checks to
all STL code and IIRC raw array accesses (although there are limits to the
latter, as it's quite difficult to check bounds when pointer arithmetic is
being performed). gcc has a precompiler constant which, when defined, turns
on similar checks to all STL code. Then you can use valgrind to catch the
rest.
The only situation nowadays where you might end up having such heisenbugs
in C++ which are not caught by the compiler even in debug mode is if you
use dirty raw pointer arithmetic hacks, which is something you seldom really
have to do in clean good-quality code, not even if you aim for maximum
efficiency.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
