[12:28 PM]:
i did coding today
wrote a quick test application of 49 lines in some 10 mins
testing took another 3 mins
felt good when it worked in the first shot
[12:29 PM]:
i need cold water
Showing posts with label office. Show all posts
Showing posts with label office. Show all posts
Wednesday, August 08, 2007
Infinitesimal things...
Tuesday, April 10, 2007
Superman spins a web?!?
Could you take my picture...
Cause I won't remember...
It was after quite a long time that the 'Tools Team' decided to de-stress, unwind and chill out. After a very disappointing stint at 'Legends of Rock' things went into high gear when we hit the '13th floor'. Once there we had an Intel strategy meeting, a team strategy meeting and many other strategy meetings. Believe me not all the strategy meetings revolved around work! I only wish someone had taken minutes, ha! It sounds boring cause it looks like we were discussing work but you had to be there to see what we were up to. Plus we were having a tough time keeping our concentration because of you know, the 'surroundings' ;-). Once we stumbled out of 13th floor, Lazy Dude in fact acted contrary to his name, put in some extra effort and went back to wave g'nite to someone! One more funny incident was when Lazy Dude in his 'elevated' state remarked "Ha! What does Superman do. He just shoots something from his wrist, what is that he does na?" That's Spiderman, man!
Later at around 11 or 11:30 we were infact not even allowed to eat at one of the Coffee Day outlets. After looking at the 3 of us they politely made a lame excuse that they were only allowing to take away food. So we did take away the food and ate it on the bonnet of my car in total Bombay ishtyle...
Cause I won't remember...
It was a very strange coincidence that about a week back when lazy dude, geek guy and I were more than a little 'elevated' and this song (Take a Picture by Filter) was playing in the car. Coincidence because we were in a state where quite possibly the next day we wouldn't remember what all had happened ;-)
It was after quite a long time that the 'Tools Team' decided to de-stress, unwind and chill out. After a very disappointing stint at 'Legends of Rock' things went into high gear when we hit the '13th floor'. Once there we had an Intel strategy meeting, a team strategy meeting and many other strategy meetings. Believe me not all the strategy meetings revolved around work! I only wish someone had taken minutes, ha! It sounds boring cause it looks like we were discussing work but you had to be there to see what we were up to. Plus we were having a tough time keeping our concentration because of you know, the 'surroundings' ;-). Once we stumbled out of 13th floor, Lazy Dude in fact acted contrary to his name, put in some extra effort and went back to wave g'nite to someone! One more funny incident was when Lazy Dude in his 'elevated' state remarked "Ha! What does Superman do. He just shoots something from his wrist, what is that he does na?" That's Spiderman, man!
Later at around 11 or 11:30 we were infact not even allowed to eat at one of the Coffee Day outlets. After looking at the 3 of us they politely made a lame excuse that they were only allowing to take away food. So we did take away the food and ate it on the bonnet of my car in total Bombay ishtyle...
Saturday, April 22, 2006
Seize the bugs!
lAfter quite a long gap I got a break from enhancing my PowerPoint skills and got chance to do some hands on debugging. 3 instances which given the time I spend on PowerPoint, were heaven sent…
The first bug we were tracking down was a fairly tricky one since we didn’t have the hardware to test our code. So, two of us who were looking at this had no option but to just peer at the code. Everything seemed absolutely fine, the previous developer needed the contents of a widely used structure. But since this structure was in a different file had made an EXTERN out of it and then proceeded to use the contents. Initially we never even suspected this structure could be the problem. But after looking at all the other parts of the code and eliminating all the other scenarios we were left with nothing but to verify this variable. Nothing looked wrong at all; it was being filled upon initialization in a separate file and then being used. After lots more of staring and global searches we noticed that the structure being filled upon initialization was the local variable of the exact same name. The global had never been touched but since the names were the exact same and also that the variable was very widely used the developer had not verified that the wrong variable was being imported. So we just proceed to use the right one and things were fine.
The second one was a painfully slow debugging session that required about 3-4 hours. Here the software would start fine once, twice and but during the third time would get screwed up. This was slow because after u ran it the 3rd time there was no option but to reboot the system. And since it had the Vista OS it would login to a normal user account first from where you had to logout and then login to the admin account and then start the debugging. The intern in our group was with me on this run. We did so many reboots that we lost count but each time we painfully small amounts of progress. To what we didn’t know and to where we didn’t know either. Finally we found that for some strange reason the processor affinity being set in the application was not carrying over to the driver. This is given, we had no doubt that it carries over from the user space to the kernel space. We couldn’t figure out why the affinity was not sticking for this particular application whereas another application using the same driver was working just fine. We gave up on the reason behind because time was short and made a simple fix of re-asserting the processor affinity in the kernel one more time and things began working.
The third was a minor one where it took me 2 minutes to solve a problem that someone had spent an hour and a half looking into. It took me 2 minutes because I knew this problem existed and had faced it before :D. What happens with this tool is that it quietly installs a driver in the system32/drivers directory and never uninstalls it. So when you have a new driver your changes never show up since the driver already exists in the drivers directory and the OS picks it up every time from there (because the registry entry points to there also). So you have to remove the registry entry and additionally go delete this file only then will the new driver get loaded. Stupid thing, will need to be cleaned up by the next release :P
The first bug we were tracking down was a fairly tricky one since we didn’t have the hardware to test our code. So, two of us who were looking at this had no option but to just peer at the code. Everything seemed absolutely fine, the previous developer needed the contents of a widely used structure. But since this structure was in a different file had made an EXTERN out of it and then proceeded to use the contents. Initially we never even suspected this structure could be the problem. But after looking at all the other parts of the code and eliminating all the other scenarios we were left with nothing but to verify this variable. Nothing looked wrong at all; it was being filled upon initialization in a separate file and then being used. After lots more of staring and global searches we noticed that the structure being filled upon initialization was the local variable of the exact same name. The global had never been touched but since the names were the exact same and also that the variable was very widely used the developer had not verified that the wrong variable was being imported. So we just proceed to use the right one and things were fine.
The second one was a painfully slow debugging session that required about 3-4 hours. Here the software would start fine once, twice and but during the third time would get screwed up. This was slow because after u ran it the 3rd time there was no option but to reboot the system. And since it had the Vista OS it would login to a normal user account first from where you had to logout and then login to the admin account and then start the debugging. The intern in our group was with me on this run. We did so many reboots that we lost count but each time we painfully small amounts of progress. To what we didn’t know and to where we didn’t know either. Finally we found that for some strange reason the processor affinity being set in the application was not carrying over to the driver. This is given, we had no doubt that it carries over from the user space to the kernel space. We couldn’t figure out why the affinity was not sticking for this particular application whereas another application using the same driver was working just fine. We gave up on the reason behind because time was short and made a simple fix of re-asserting the processor affinity in the kernel one more time and things began working.
The third was a minor one where it took me 2 minutes to solve a problem that someone had spent an hour and a half looking into. It took me 2 minutes because I knew this problem existed and had faced it before :D. What happens with this tool is that it quietly installs a driver in the system32/drivers directory and never uninstalls it. So when you have a new driver your changes never show up since the driver already exists in the drivers directory and the OS picks it up every time from there (because the registry entry points to there also). So you have to remove the registry entry and additionally go delete this file only then will the new driver get loaded. Stupid thing, will need to be cleaned up by the next release :P
Subscribe to:
Posts (Atom)
