Gmail Supports SSL!

Quick - go to your Gmail account --> Options --> Always Use HTTPS



And your future sessions with Gmail will be SSL secured.
(This came as a response to a tool that automatically breaks into Gmail accounts, and is a long time overdue IMO).

The Ultimate Embarresment

Update - Boaz claims his Avast anti virus detected a virus after following the link below. My AVG doesn't detect anything, but follow at your own peril (you should be safe with Firefox & NoScript anyway)

A Blue Screen of Death project in the 2008 Olympics :) (while Bill Gates was attending it)

Thesis Complete!

Finally, after years of research, months of writing and correcting, and weeks of bureaucracy, I finished my M.Sc thesis!

Regex Complexity

Today I got a shocker.

I tried the not-too-complicated regular expression:

href=['"](?<link>[^?'">]*\??[^'" >]*)[^>]*(?<displayed>[^>]*)</a>

I worked in the excellent RegexBuddy, and ran the above regex on a normal size HTML page (the regex aims to find all links in a page). The regex hung, and I got the following message:

The match attempt was aborted early because the regular expression is too complex. The regex engine you plan to use it with may not be able to handle it at all and crash. Look up "catastrophic backtracking" in the help file to learn how to avoid this situation.

I looked up “catastrophic backtracking”, and got that regexes such as “(x+x+)+y” are evil. Sure – but my regex does not contain nested repetition operations!

I then tried this regex on a short page, and it worked. This was another surprise, as I always thought most regex implementations are compiled, and then run in O(n) (I never took the time to learn all the regex flavors, I just assumed what I learned in the university was the general rule).

It turns out that one of the algorithms to implement regex uses backtracking, so a regex might work on a short string but fail on a larger one. It appears even simple expressions such as “(a|aa)*b” take exponential time in this implementation.

I looked around a bit, but failed to find a good description of the internal implementation of .NET’s regular expression engine.

BTW, the work-around I used here is modify the regex. It’s not exactly what I aimed for, but it’s close enough:

href=['"](?<link>[^'">]*)[^>]*>(?<displayed>[^>]*)</a>

Addicted To Resharper

Well, aren't we all? Go get your banner now.

Heh, I still remember the days when I only programmed in C++, and Tomer told me how great C# is (one of the major benefits he listed was Resharper 2.0).

I didn't believe him then, but now, I don't understand how anyone can program in C++ (except realtime/embedded programmers).

The Dark Knight

Well, everyone that's told me in the recent week how good the new Batman movie couldn't prepare me - it is really that good, and better.

I rate it 5 on movielens (must see).

My Arrogance in Finding Bugs

Last night I discovered this piece of code (simplified version):

private void Foo()
{
  bool b = false;
  new Thread((ThreadStart)delegate { b = true;}).Start();
  WaitForBool(b);
}

private void WaitForBool(bool b)
{
  while (!b)
  {
     Thread.Sleep(1000);
  }
}

I was immediately filled with disgust. How could someone write such a function (WaitForBool), which is one big bug? Of course the waiting will never be over, because bool is a value type, and no external influence can modify its value.

Later, I realized the fool is me.

I ran into this code a while back, and it did have a "ref" bool, which means it can be modified by the external thread. Resharper helpfully displayed a tip "this parameter can be declared as a value" , which I took without thinking too much about the consequences (I trust Resharper too much sometimes, it appears). So I deleted the "ref" with Resharper's help and created the bug myself without noticing.


(As a side note, of course this method of waiting for a bool should never be used - use ManualResetEvent instead).

Update
Fixed in the next Resharper build (Resharper 4.0.1, build 913), within a few hours of reporting it. Cool.