Tuesday, July 27, 2004

Switched to a full RSS feed - Dog Food

It may seem weird, but I did not try my own Atom Feed until today. When I saw it, I noticed: it was ugly, without formatting, without the source code, and incomplete. I changed a simple setting on Blogger.com and then, bang! Instant full RSS feeds, with colors, fonts, links and all the text!
I hope this does not be a hassle, but I love reading full RSS feeds, so I thought this switch was a Good Thing.

Monday, July 26, 2004

FlexWiki installed

We are already using CVS, NAnt, NUnit and Bugzilla for quite a long time and we have a very good history with these tools. They're solid rock stable, useful, and some are even intuitive (e.g., Bugzilla). Bugzilla was a bit strange to setup, mainly because I do play a bit with Linux, but I'm by no means a Linux wizard.
People here liked Bugzilla so much that they started to create bugs in it just to document some internal knowledge and procedures (e.g., "how to setup a new build machine").
So I installed FlexWiki. It took me around 10 minutes to download and setup it.
We're still moving all the scattered documentation to the Wiki, but it seems great. FlexWiki have a few bugs, but at least until now, nothing seems so serious that makes it not be a great tool to use.

Saturday, July 24, 2004

Where did my code go?

A few weeks ago, I was teaching a bit of modern OO design to a fellow programmer (a bit of UML, design patterns, code smells, refactor, etc), who is one of the best programmers I've ever knew (he coded so many things other people named "impossible" that one has to respect that). For a series of reasons, he never really did a whole OO design, and he needed to design this big system, with around 50 classes. One of the difficulties was that he was having a bad time, trying to understand where all the code he was originally planning to do gone. All those huge methods he was planning to do had simply disappeared! Now, he basically had a few, very small methods (the biggest was around 10 or 20 lines of code), and the logic was scattered all over the place! He could clearly see that the design was right, and that the final code would probably work, but he was with that constant feeling that "we left something out of this", "the code can't be that simple", and so on.
And why I am talking about all of this? I'm reading Fowler's "Refactoring: Improving Design of Existing Code", and here is something I'd like to quote:
The object programs that live best and longest are those with short methods. Programmers new to objects often feel that no computation ever takes place, that object programs are endless sequences of delegation. When you have lived with such a program for a few years, however, you learn just how valuable all those little methods are. - Martin Fowler

Well, at least is nice to see that other people experience the same things.

Wednesday, July 21, 2004

More about the HttpWebRequest/HttpWebResponse leaks

Steve Binney contacted me through e-mail and provided some feedback about the .NET HTTP infrastructure leaks I've (actually, everyone have) been having. The two last e-mails I had from him provided some very useful observations about the bug:

Email #1

I decided to be brave and install .Net 1.1 SP1 on my laptop. Unfortunately, the leaks still seem to be there. In Reflector, I have verified the HttpWebResponse/Request still have the leaks.

Email #2
To clarify my observations:

On the released version of .Net 1.1 and .Net 1.1 sp1 beta:

My app makes one synchronous HttpWebRequest/HttpWebResponse per second on a single thread. My handle count starts at 200 and ramps up to approx. 1200 before automatic GC kicks in. Memory (private bytes) start at 7 mb and quickly ramps to 20 mb before leveling off. The memory slowly creeps up after that. On a few occasions, the memory quickly increased to 60 mb but I cannot reproduce this. Calling gc.Collect stops the handle leak but has no effect on memory.

On VS 2005 Beta 1, .Net 2.0 beta 1:
Memory and handles are constant at (< 200 handles) and (18 mb). Using reflector, I see that the HttpWebRequest/HttpWebResponse clean up the
event handles created by internally calling begin/end async methods.


I have mixed feelings about this input: while it's very good news that VS 2005 does not have the same leaks, I feel a bit frustrated that this bug is not fixed yet in the .NET 1.1 SP1.
Steve and I also posted this on microsoft.public.dotnet.framework, but by Feroze feedback I feel it'll be a long, long run until a solution. Feroze didn't even seem to have looked at or tried the 10-line code snippet I posted. Probably I'll be using .NET 2.0 before that is fixed...


No, I'm not talking about the little girl from Monsters, Inc. I'm talking about Rodrigo Barreto de Oliveira's work on a new language called Boo, defined as a "wrist friendly language" on its manifesto. Boo borrows some ideas from other languages (e.g., "duck typing" is nothing more than the old "late binding"), but introduces several new concepts (at least, new to me):

There are some things, I don't like, though:

But the coolest things about this language are:

  1. It's .NET friendly, so you can start using it now where it makes sense to produce some C#-callable libraries

  2. Hey, it's from a Brazilian buddy! It's always nice to see some yellow & green language design!

Wednesday, July 07, 2004

Another bug, another workaround...

I was using Genghis to create a standard Find and Replace dialog, when I hit another bug in the .NET framework (this is getting boring...):
The System.Windows.Forms.NativeWindow class has a problem on the ReleaseHandle method: I don't know (don't care) why, when you subclass a window using the NativeWindow class, your new WndProc will still be called, even after the ReleaseHandle. On the Genghis FindReplaceDialog class, this bug appears when you invoke the dialog twice: your WndProc will be called for a while, and then, BAM! A call to a collected delegate will happen. I googled a lot and found nothing, so I coded the following workaround. When you need to subclass a window, just derive from my class instead of deriving from System.Windows.Forms.NativeWindow class and you won't need to change a single line of code!
class NativeWindow
private IntPtr handle;
private WndProcDelegate wndProcDelegate; // Prevents the delegate being collected
private IntPtr oldWndFunc;
private delegate IntPtr WndProcDelegate(IntPtr hwnd, int Msg, IntPtr wParam, IntPtr lParam);

private const int GWL_WNDPROC = -4;

private static extern IntPtr SetWindowLong(IntPtr hWnd, int nIndex, WndProcDelegate wndProcDelegate);
private static extern IntPtr SetWindowLong(IntPtr hWnd, int nIndex, IntPtr wndFunc);

private static extern IntPtr CallWindowProc(IntPtr prevWndFunc, IntPtr hWnd, int iMsg, IntPtr wParam, IntPtr lParam);

public NativeWindow()
wndProcDelegate = new WndProcDelegate(this.WndProc);

public void AssignHandle(IntPtr hWnd)
handle = hWnd;
oldWndFunc = SetWindowLong(hWnd, GWL_WNDPROC, wndProcDelegate);

public void ReleaseHandle()
SetWindowLong(handle, GWL_WNDPROC, oldWndFunc);
handle = IntPtr.Zero;
oldWndFunc = IntPtr.Zero;

protected virtual void WndProc(ref Message msg)
DefWndProc(ref msg);

public void DefWndProc(ref Message m)
m.Result = CallWindowProc(oldWndFunc, m.HWnd, m.Msg, m.WParam, m.LParam);

private IntPtr WndProc(IntPtr hWnd, int Msg, IntPtr wParam, IntPtr lParam)
Message msg = Message.Create(hWnd, Msg, wParam, lParam);
WndProc(ref msg);
return msg.Result;

Friday, July 02, 2004

Yet another bug on the .NET framework

I hit another bug on the .NET framework. No, this time the bug is not a leak like the other two times.
I have this application that is starting to work, and it's starting to be a cool visual credit policies MDI editor. Now that the grunt work is done, I started to make the application visually appealing, and I started adding some icons to the toolbars. Everything was ok, until I added a toolbar and an ImageList to the main MDI form. Suddenly, every image on every toolbar on the application disappeared!
What amazed me more was that at design time everything was ok. After a bit try this, disable that, I disabled the following line on my Main():
/// <summary>
/// The main entry point for the application.
/// </summary>
static void Main()
// Application.EnableVisualStyles(); <-- Removing this line "solved" the problem
Application.Run(new Principal());

Now I had something to search and after a bit of Google I found this article. Although there are some failure reports on the posts below, Don is right: simply adding an Application.DoEvents worked like a charm!

Marc did it again!

Marc Clifton, the article writing machine, and MyXaml author did it again! Worried about CodeProject's increasing noise level, he and Anders Molin branched another Windows development site, RealDevs.net. Speaking with some fellow programmers, some became worried about branching a site, which could split the development community. I don't think so: CodeProject was a branch from Codeguru, and look at the size it became, and CodeGuru still exists.
What I love about the way Marc and Anders are doing their site is: high quality articles, use of modern tools (as of today, DNN, DotNetNuke), and openness. Modern tools are a must, IMO, because they'll be able to concentrate on what the users want, not on how to do it. Can you really understand why Codeproject still runs in traditional ASP? And Chris still has performance and scalability problems, even on cluster!
Openness is also very powerful: instead of hiding your problems, tell them to the world, after all we are programmers, and maybe we can help! If not help, we can maybe learn, hehehe.
Quote of the day:
We both believe that there are no reasons for keeping a secret about what platform we use and what problems we have, so we will pretty much post all of it here ;)
- Anders

Good luck, guys!

IDisposable Article Series - What's IDisposable?

IDisposable is, at the same time, one of the most simple and most important .NET interfaces. It consists of a single method, Dispose, with no parameters and returning nothing. It's declared by the .NET framework as follows:
namespace System
public interface IDisposable
void Dispose();

The goal behind IDisposable is simple: to clear any unmanaged resources allocated by a class. And what are "unmanaged resources"? First, you need to understand what are "managed resources": memory. But not any memory: only memory that the .NET framework explicitly allocated.
You probably know that the .NET framework provides you with a garbage collector (GC). While a standard technical term, I don't agree with this, I think it's not a precise term, at least in the .NET environment: there's no real "garbage collector" in .NET. What really exists is a memory recycler. Basically, you are not in control of memory deallocation and the environment takes care of this for you. Think of this as a "controlled memory leak". Your code will only ask for the GC to allocate memory and keep track of its uses, and when something triggers it (probably a combination of idle time, memory pressure and even maybe the size of your L2 cache), the GC comes in and releases all the unused memory. While this, most of the time, achieves high levels of performance and reliability, also has some very bad consequences:

If there are no predictable destructors in the .NET environment, how can API wrapper classes (e.g) Control, Bitmap, Socket or FileStream, which hold a handle to physical, costly or scarce resources, be able to automatically close handles or execute clean up code? They can't: at least, in a predictable way. So, IDisposable comes to scene, and you, the class user, are responsible for the lifetime management.

Next article part:
What are the responsibilities of the IDisposable for the class user?

This page is powered by Blogger. Isn't yours?