Monday, June 20, 2011

My first BTC!

My first BitCoin:

Mining this took almost a week. A BitCoin exchanges for about 17 USD as of this writing at Mt.Gox. Hopefully, it will clamber back to ~20USD soon.

Boring specifics:
Software: Phoenix (with Phoenix Rising UI)
Hardware: ATI 5970 GPU
Mining Pool: BTC Guild

Wednesday, May 11, 2011

Ad blocked!

So, I've been working on a project and one of the tasks was to add Advertisement Banner functionality. I used custom php and javascript to create a light-weight Ad display mechanism.
The next part of the project was to add an "AD Rotator" which rotates the displayed Ad every few minutes.
I wrote this class in a separate javascript file included it in the required pages. I almost marked it as completed when I noticed that the rotation script, which was working in localhost, was not working when hosted on the testing server. I was testing in Google Chrome and the Error Console stated:
Uncaught ReferenceError:  start_adRotator is not defined only in chrome
I was pulling my hair over this for almost a day. Good 'ol google was not very helpful here. The same page from the testing server ran perfectly in IE! I mean, my code runs in IE not in Chrome?? Has the fabric of space-time begun to unravel? Is it time to deploy the Amber?...

I was willing to try anything at that point because the project's completion date was near. Time to get debugging. I noticed that my Ad Rotation script was not in the Scripts list box, but present in the "Resources" tab. Hmm... weird, but I didn't think much of it. Next, I tried the Audits tool in Chrome's built-in "Developer Tools". The audit reported that a huge chunk of javascript was not being used. A quick gander at the details revealed that these functions were from the AdBlock plugin that I had installed! *flicker flicker* *flash!*

As the sage Adam Savage once said, "Well, there's your problem!".

After adding an exception to the AdBlock extension, the code works everywhere now. You can rest easy. My lustrous and thick locks are safe, at least for now.

I guess, somehow, when you are the one hosting or displaying Advertisements, you tend not to see them as the annoying, distracting and useless pieces of bandwidth and screen-real estate wasting annoyances of the web that just begs to be blocked!

Monday, October 25, 2010

Saturday, September 11, 2010

Signs of (Road) Life

Even along the highways of the not-so-fast Indian road traffic, there can be seen quite a few imaginatively worded signs reminding drivers and riders of the speed limit and some interestingly worded cautions.

As an aside, consider why we even have these signs along the highway? I don't contend with the message of these signs but their placement. The only people who are moving slowly enough to read these signs sure don't need to read them. Not to mention that reading these signs may in fact may cause accidents (wonder why you don't see "Do Not Read Signs While Driving" signs...)
The only guys that these signs are directed at are traveling at close to warp speed anyway. So why even bother?
Perhaps the Highway Authority thinks that, on the off-chance that there is a traffic jam on the highway, these "speeders", who probably have low respect for authority and even lesser respect for anything "the man" might care to put up on a sign, might chance a glance upon them and suddenly and forever be changed?

Maybe these signs were put up so that whoever put these up can say that they tried?

Included below are the signs that I managed to capture on my way from Chennai to Bangalore (or Bengaluru). I humbly apologize for the low quality of these images beforehand. On my defense, I took these photos using a digital camera (Sony DSC HX-1) while traveling on a fast moving car, looking out through tinted windows and on an overcast day. Most of these shots were taken at dawn, dusk and at night.
Finally, after much-ado:





























For the above shots, I used the Manual mode and had to keep the ISO low and jiggle the shutter speed and aperture values so that the shots don't look grainy and, most importantly, avoid motion-blur.

And now for something somewhat different.
In the pitch black of the night, the limitations of the digital camera were becoming quite obvious. The heavy rain pouring down didn't help either. So I gave up with keeping the shutter speed high and dialed it way down low (1 to 5 secs) just for the hell of it. This resulted in quite an unexpected light-show and I was quite impressed with the results:




Wednesday, July 08, 2009

Enforcing a minimum of one check mark

Good evening, ladies and gentlemen. Here's a little code I tossed off recently in the Computer:

So, here's how I made sure that at least one check box remains checked in one of my forms. A quick search didn't turn out any vb.net samples for doing this, so here is my version so that I will have a source of copy-paste the next time I google :P

Private Sub dlgViewImageHistogram_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
  chkRed.AutoCheck = False
  chkGreen.AutoCheck = False
  chkBlue.AutoCheck = False
  chkIntensity.AutoCheck = False
  chkIntensity.Checked = True
End Sub

Private Sub checkColor_Clicked(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles _
chkRed.Click, chkGreen.Click, chkBlue.Click, chkIntensity.Click
  Dim checkCount As Integer
  For Each chkBox As Control In pnlChannels.Controls
    If Not TypeOf chkBox Is CheckBox Then Continue For
    checkCount = IIf(CType(chkBox, CheckBox).Checked, checkCount + 1, checkCount)
  Next

  If checkCount = 1 And sender.checked = True Then
    Exit Sub
  Else
    sender.checked = Not sender.checked
  End If

End Sub


Basically, you need to set the AutoCheck property of the checkboxes to 'false' to take over control of the setting of the 'Checked' property.
Also, make sure that you have at least one check box checked. I have put all the checkboxes in a Panel control. Maybe there's a better way of grouping the check boxes, but I haven't read up on it.

Monday, June 29, 2009

Bitmap cloning is not Bitmap cloning

Almost 7 years ago, I had a pet project called 'PBrush', a small paint program created in VB 6. It was where I experimented with implementing the Undo/Redo features, image processing (emboss/invert/edge-detection, etc) in addition to the standard tools found in MSPaint.
I lost the project files when my first RAID-0 array broke and I've forgotten about it since then. (Since then I don't keep my project files on a raid-0 array.)

So, here I am today trying to get back in touch with VB.net after quite some time working in the Java/JSP platform and out of nowhere, I am reminded of the old PBrush project of mine. Not surprising really, since I had the most fun working on that project, ya know, trying different things with pixels and coming up with names for them :) Good times.

So anyway, I downloaded VB.net 2008 express edition and began coding about a few days ago in my spare times. I've already got a couple of kernel-based filters for edge-detection (Sobel. Scharr) coded down using basic loops for now. I heard directx methods will be faster for this, so I might try to re-write these functions.

For now, I am using a PictureBox for the main display and pass its Image property to my functions that will do the image processing. I had it all working in a day. But, as these filters are time-consuming, I noticed that the form would go to 'Not Responding' state after about 3 seconds of processing. This turns out to be caused by the form and its child controls staying "invalided" for too long. That is, the controls want to re-paint themselves, but can't because of the current thread is busy executing the image proessing routine.
First I tried the good old Application.doEvents()
Turns out that this method is old alright but certainly not "good". Some call for its timely death, even, and I can see their point. After adding this method call, my functions were taking about ten times more time to complete. Online documentations say that this is expected behaviour(!). Called 're-entrancy', this function halts any method that's been running, processes form messages and, get this, re-enters the function that it interupted.

Well, I said "no thank you. Don't come again" and started looking into putting the functions in separate threads instead.

Now, this is my first (not counting lab projects) project with threading. But it turns out that putting a function call into a separate thread is too easy. I used the BackgroundWorker class for doing this. Now, the functions work quite faster and the UI doesn't stay "invalidated" either. Seems perfect on the surface. But the devil is in the details, yes?

Yes. To better illustrate this point, let me give you a brief overview of the code.
So, I have a Picture box that holds the bitmap that needs processing. This control is also the one that is visible to the user, so it has to stay "validated". When an image filter is chosen by clicking on a menu item, I pass the Image object of the PictureBox to the appropriate function to be processed in the thread's DoWork method. Like so:

Dim bmpSrc as Bitmap
bmpSrc = pbMainDisplay.Image
e.Result = pdc.applyFilter(bmpSrc)


I noticed that "sometimes", when the BackgroundWorker is executing an image processing routine in the background, the Picture box will show a big red 'X' on it instead of the bitmap and an exception will be thrown stating "Bitmap region is already locked." on the line where I try to do a GetPixel().

I thought that it was simply a matter of adding a clone() method call on the Image property as this would create a new Image object instead of passing the reference to the Image. When this didn't work, I searched for every usage of the bitmap on the code and added the Clone() method call to it. Finally, when all the Image properties were adorned with the Clone() method, I ran the project again.... and met with the same problem, unchanged.

I looked up this issue online and found a similarly frustrated developer's blog entry on this. I gladly gave his method a try, like this:

Dim bmpSrc as Bitmap
bmpSrc = New Bitmap(pbMainDisplay.Image)
e.Result = pdc.applyFilter(taMain).Clone()


Unfortunately, this approach didn't work for me either.
Frustrated, I tried to either set the visibility of the Picture Box to false whenever the picture is being worked on by the background thread. But this would make the picture not visible to the user, which is ultimately not very "smooth".
So, for now, I have opted to intercept the paint events of the picture box and disallowing it whenever the background thread is busy, like so:


Private Sub pbMainDisplay_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles pbMainDisplay.Invalidated
If bwMain.IsBusy() Then
Exit Sub
End If
End Sub

It might be a workaround, but it's the only thing I've tried that works.


Update: 8th July, 2009

I have since moved the code that sets the Bitmap variable from the background worker's DoWork event to the method that calls the background worker instance's RunWorkerAsync() method, et voila, no stinkin workarounds required now.
It had been a matter of inter-thread chatter, I suppose, between the main application thread and the background worker.