In engineering you've got to do whatever it takes to solve the problem.
If you ever have a really tricky bug, try printing out the entire source repo on origami paper and laying out the sheets in a Hilbert curve pattern on the floor. Then throw out some silicium sticks -- one for each thread you were running -- and 63% of the time, one will land on the buggy line of code.
The most strange bugs have the strangest solutions. Just an hour ago I was trying to debug a queueConstructor (it returns a malloc'd pointer to a queue data structure), right after I finished implementing the operations for a stack data structure. Malloc was inexplicably causing the program to hang (I don't know if it's a segfault, I was using Windows). printfing around the constructor and inside it didn't work. I had included all the libraries I needed to, syntax was good, no warnings, I even changed the declarations from int var to int var.
It turns out the problem was that in main() just before I called queueConstructor, I added the item 633346 as an integer element in my stack data structure. Whether this overflowed the integer, I don't know. But I don't know why it would stop malloc for a different data structure stored in a different variable from working (perhaps it was occupying some memory that my queue wanted?).
This isn't the first time bugs like this happen, and as a novice programmer I really wish tools were better, or I knew how to use the tools. GDB available via CodeBlocks wasn't helpful.
That sort of magic isn't right and if you don't find the source then you'll probably end up with more and more weird bugs down the line, to the point that nothing will work and you won't know why.
My first suggestion would be to familiarize yourself with valgrind to make sure that you aren't accessing memory that you shouldn't be. Next would be writing tests so you can isolate problems like this.
When you've got 58 different systems interacting you'll occasionally come across some weird problems that you can't replicate, but they should be few and far between.
"engineering you've got to do whatever it takes to solve the problem."
No, no and no. Engineering is about taking Science and finance and working out the best fit. Wasting resources in using inefficient divining rods is the exact opposite of Engineering.
A really tricky bug, back to first principles and science, then work back from there.
Hunch detector yes, but also human experience with how past pipe laying decisions went. The past people making those decisions weren't just making randomized decisions - they were likely thinking about property lines, and about of running through difficult to dig areas or likelihood of areas that might get dug into unintentionally. Humans interpreting humans, sometimes using talismans to focus an unconscious thought process.
It would probably be made into a better performing process if they got rid of the tokens, and someone thought about it, wrote up what they thought past layment decisions were based upon, and taught others as well as evaluated how well that worked, but maybe not worth that level of formalization/optimization either.
I like to think that dowsers are really a secret guild of hydrologists who make a show of using magic to account for the uncertainty inherent in finding things underground.
16 comments
[ 4.4 ms ] story [ 40.2 ms ] threadIf you ever have a really tricky bug, try printing out the entire source repo on origami paper and laying out the sheets in a Hilbert curve pattern on the floor. Then throw out some silicium sticks -- one for each thread you were running -- and 63% of the time, one will land on the buggy line of code.
It turns out the problem was that in main() just before I called queueConstructor, I added the item 633346 as an integer element in my stack data structure. Whether this overflowed the integer, I don't know. But I don't know why it would stop malloc for a different data structure stored in a different variable from working (perhaps it was occupying some memory that my queue wanted?).
This isn't the first time bugs like this happen, and as a novice programmer I really wish tools were better, or I knew how to use the tools. GDB available via CodeBlocks wasn't helpful.
My first suggestion would be to familiarize yourself with valgrind to make sure that you aren't accessing memory that you shouldn't be. Next would be writing tests so you can isolate problems like this.
When you've got 58 different systems interacting you'll occasionally come across some weird problems that you can't replicate, but they should be few and far between.
Not too surprising considering what we know about Buffon's needle.
A really tricky bug, back to first principles and science, then work back from there.
By the way - I work with underground services....
the brain can sense a lot more than we think.
> Every properly conducted scientific test of water dowsing has found it no better than chance
It would probably be made into a better performing process if they got rid of the tokens, and someone thought about it, wrote up what they thought past layment decisions were based upon, and taught others as well as evaluated how well that worked, but maybe not worth that level of formalization/optimization either.