Marius Bancila’s Blog

For those that attended my last evening presentation about F# at Ronua Roadshow in Timisoara (but not only), here is the demo I’ve shown, and one that I planned to show but didn’t due to lack of time. The purpose of these demos was to shown simple Windows Forms applications written in F#.

Mandelbrot Fractal
A Mandelbrot set is a set of points in the complex plane, whose boundary forms a fractal. The fractal, known as Mandelbrot fractal, is obtain by associating a color with each point in the complex plane (or rather a subset of it). The color is chosen based on the result of computing the value of the complex quadratic polynomial Z(n+1) = Z(n)^2 + c for a number of iterations (100, 200, etc.). You can read more about it on Wikipedia.

The program that I shown exhibits traits of both functional (for computing the fractal) and object oriented (for displaying the fractal) paradigms. It is a variation of the program available here, for which I kept the functional part (computing the Mandelbrot set is not very fast, I must warn you), but redone the user interface part. You can use the mouse to drag the fractal and the wheel to zoom in and out.

You can download it from here.

Game of Life
I blogged about this two years ago, when F# was still far from a final release. In the meantime, syntax has changed, classes have changed, so if you try to run that implementation of mine you’ll run into some errors. I have updated the code to run correctly with Visual Studio 2010.

You can download it from here.

When you run your (unmanaged/C++) application in debugger, you see at the end a report of memory leaks (if any are detected). Something like this:

Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {381} normal block at 0x001FFC30, 54 bytes long.
Data: < x > 0C 00 B9 78 12 00 00 00 12 00 00 00 01 00 00 00
d:\marius\vc++\memoryleakstest\memoryleakstestdlg.cpp(163) : {380} normal block at 0x001FFBF0, 4 bytes long.
Data: <@ > 40 FC 1F 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp(306) : {374} client block at 0x001FFA38, subtype c0, 68 bytes long.
a CWinThread object at $001FFA38, 68 bytes long
Object dump complete.

Some of them can be fixed immediately, because when you double click on them Visual Studio will take you to the line where the allocation was made. Some of them are harder to spot, because Visual Studio is not able to do the same. Question is how do you find the source of those allocations? Luckily, there is this global variable called _crtBreakAlloc, that can be used to force the debugger to stop the execution when a certain block is allocated.

In order to use that, you should follow several steps:

• First, you have to find a reproducible sequence that produces the same memory allocation number. When memory blocks are allocated, they are identified with a number, called allocation number. This number is reported by Visual Studio in brackets when it lists the memory leaks (e.g. {381}).
• Second, you have to put a breakpoint somewhere in your program to force a stop at the beginning of the execution. That means you could use function main(), your CWinApp derived class constructor, function InitInstance() or other, depending on your application type and how early in the execution of the program the block that leaks is allocated. The smaller the allocation number is, the earlier in the execution the allocation occurs.
• Run your program in debugger.
• When the program stops (at the first breakpoint) open the Watch window and add the following expression: {,,msvcr90d.dll}_crtBreakAlloc in the Name column. In the Value column (which by default should have the value -1) write the allocation number. Take notice that msvcr90d.dll (which is the DLL that contains the C++ runtime library) is specific to Visual Studio 2008 (and is the debug version). If you use another version of Visual Studio, you have to use the appropriate DLL.
• Continue debugging.
• When the block identified by the allocation number set in the Watch window is allocated, the debugger will stop the execution and jump to a line from dbgheap.c.
  
  In order to see the line in your code that triggered the allocation, open the Call Stack window and find, from top down, the first function from your own code.
  
  That will lead you to the source of the memory leak.

To read more about this topic see:
How to: Set Breakpoints on a Memory Allocation Number
How to use _crtBreakAlloc to debug a memory allocation

If you’re a football fan you must have heard about the octopus called Paul that has predicted the outcome of all Germany’s matches at the World Cup 2010. She lives in the Sea Life Aquarium in the western city of Oberhausen. Before each match she was given two jars with a mussel and a national flag inside. And every time she picked the mussel from the jar with the flag of the correct winner. Yesterday she picked Spain over Germany.

Now, I want to make a prediction about her current and next predictions: she got the result of tonight’s match wrong, Germany will win. And then, she’ll have to chose between Netherlands and Germany and will pick the Netherlands. Now, the prediction is not that much about who wins (it doesn’t matter actually who wins), it’s about how Paul makes the picks.

How did I do this prediction? Well, I see patterns. And here is Paul’s prediction pattern. She is giving two jars, arranged by the teams order:
Germany – Australia
Germany – Serbia
Ghana – Germany
Germany – England
Argentina – Germany
Germany – Spain

She’s picking left, right, right, left, right, right. The next match will be between Netherlands and Germany and she will pick left, thus Netherlands.

Let’s see how good I am with predictions.

UPDATE: OK, psychic Paul was right once again. But I still predict that it will pick left, thus, Uruguay for Germany’s next match.

SECOND UPDATE: so Paul has picked Germany over Uruguay, and Spain over Netherlands. That completely ruins my prediction.