Dirty Coding Tricks

I especially like the last story :)
That last one reminded me of spending a month of evenings doing a 2000 piece, brand new jigsaw puzzle only to find one piece missing. I packed it up in disgust.

Later a flatmate asked "Why did you pack it away?" and I explained. She replied, "Oh I've got that because I wanted to put in the last piece".
 
Isn't that when you had to leave your old identity behind you with forensics digging through the flat?
 
Isn't that when you had to leave your old identity behind you with forensics digging through the flat?

That might have happened if it weren't for the fact I'd packed it up in "connected groups" in the event I found the missing piece behind the sofa or in the vacuum cleaner.

Alex V: :rolleyes:
 
That might have happened if it weren't for the fact I'd packed it up in "connected groups" in the event I found the missing piece behind the sofa or in the vacuum cleaner.
Smart thinking! I bet you reuse a lot of code when you get chance too. :D
 
Smart thinking! I bet you reuse a lot of code when you get chance too. :D
Yes, I'll always find it best to leave my old source code in big pieces rather than reordering all the individual ASCII characters into their own files. :D
 
I do like the third comment about Wing Commander. That's the kind of lateral problem solving I like.

Heh, yes, though of course it's also a dirty patch. :p But if it's not your code, then there's little you can do, and this is definitely the most elegant solution.

Loved the last story also, very clever.
 
The WingCommander one is my favourite too.
It reminds of something I did in my school years - a project on data-structures was due next morning and while I had the basic functionality working, the final step that was supposed to benchmark relative performances of implemented data-structures crashed.

After few hours I gave up on a proper fix, I ran a shorter test that didn't crash, extrapolated result of the long test from it and replaced the code with something like:
Code:
Sleep(10000);
printf("Result... %d", resultfrombefore + random()*someepsilon);

(random was for the case I was asked to run it more then once)

Simon F said:
Yes, I'll always find it best to leave my old source code in big pieces rather than reordering all the individual ASCII characters into their own files
Back in my hobbyist days, I used to name all my work-in progress test-code along the lines of
"popo" (or some variation of thereof, being easy to type and all).
This worked fine until one day I wanted to look at some stuff I wrote months ago and my source code folder looked like this:

popo.pas
opop.pas
popo1.pas
popo3.pas
popopop.pas
poponew.pas
popoold.pas
popop.pas
...
 
I was shipping a PS1 game, which had a streaming audio issue 2 days before we were supposed to go final. The code base was something we inheritted, and no-one really understood what the IOP module was supposed to be doing, 3 of us stayed up all night and rewrote it from scratch.
It worked fine on emulation, but the audio skipped when we burned our first CD. So we were left with under 24 hours to the deadline, and senior engineers that had been working for 27+ hours and a none fnctional disk.
However in rewriting the IOP module, we had gained some insight as to why the original was failing, the issue was it hitting the end of the last file on the disk while streaming, so we padded out the last file by 1K, burned the disk with the original IOP module, and went home to sleep.
 
The WingCommander one is my favourite too.
It reminds of something I did in my school years - a project on data-structures was due next morning and while I had the basic functionality working, the final step that was supposed to benchmark relative performances of implemented data-structures crashed.

After few hours I gave up on a proper fix, I ran a shorter test that didn't crash, extrapolated result of the long test from it and replaced the code with something like:
Code:
Sleep(10000);
printf("Result... %d", resultfrombefore + random()*someepsilon);

(random was for the case I was asked to run it more then once)
...


I'm pretty sure I handed in at least one assignment that had stubs with hard coded results, fully expecting to get docked marks, but the professor or TA never saw them.


Back in my hobbyist days, I used to name all my work-in progress test-code along the lines of
"popo" (or some variation of thereof, being easy to type and all).
This worked fine until one day I wanted to look at some stuff I wrote months ago and my source code folder looked like this:

popo.pas
opop.pas
popo1.pas
popo3.pas
popopop.pas
poponew.pas
popoold.pas
popop.pas
...

Looks clear enough to me.
 
I'm pretty sure I handed in at least one assignment that had stubs with hard coded results, fully expecting to get docked marks, but the professor or TA never saw them.
That accounted for a lot of my stress when I was writing, demoing, and publishing GlovePIE scripts. If I made a mistake on the description of my code, my videos showed things working differently than it should with the published code, or I forgot to include a line for stopping the script with the Wiimote, I'd be under the scrutiny of potentially thousands of readers and viewers, and feel rotten if even one noticed something not entirely on the level. Reading this makes me think about all the stupid choices I made under the pressure of a deadline.
 
Scientific code is less amenable to hacks in the sense that a hack usually just makes your results wrong, even if it stops the crash. However, I do recall one example. Basically, in the course of a larger PDE, I had to solve a Poisson equation, Laplace P = f. The problem is it has Neumann boundary conditions, which makes it ill-posed. My adviser said to just set one of the boundary points on the bottom to zero, and that takes care of it. Well, it didn't--it just resulted in a big spike in the pressure (P) right there. I'd fool around with it, and eventually sort of made it work with a "Don't do that" hack that kept pushing the pressure down at that point.

After a week or so of messing around, I finally figured out the problem--when my adviser represents a domain as a matrix, he numbers his rows from bottom to top, like the Cartesian plane. I number from top to bottom, like regular matrix numbering. So when I do my Poisson solves, I iterate from top to bottom, and he iterates from bottom to top...so the zero-fix at the bottom row never propagates properly. I changed my zero-point to the top boundary, and voila, that fixed everything.
 
ERP said:
the issue was it hitting the end of the last file on the disk while streaming
I saw a similar issue with PS2 once, also while burning submission discs - IIRC we solved it by adding a dummy file to the end of disc image. I think this also stayed with all the PS2 titles using that tech, even after I left the place.

Scott_Arm said:
I'm pretty sure I handed in at least one assignment that had stubs with hard coded results, fully expecting to get docked marks, but the professor or TA never saw them.
Yea, I actually got full marks on that assignment too. One thing that also stuck with me from that time was that people that wrote things in windows got higher marks then those that presented command-line implementations -_-

Looks clear enough to me.
I should point out most of those source files were completely unrelated to one another, not iterations of one thing.
 
This worked fine until one day I wanted to look at some stuff I wrote months ago and my source code folder looked like this:
Omg. Seriously, I lolled IRL at this, madly.

My cheek-muscles hurt now.

Add to the fact I was drinking tea, bringing a significant danger of Splutter-factor interfering with my fluid-ingestion...
 
Back
Top