Sunday, February 27, 2005

Going online

After a long wait, I have gotten what I have always missed. An internet connection at home.

I now have more access to one and all.

I am more accessible now.

Sunday, February 13, 2005

Lessons in keeping GMCS and BMCS in sync !

Thanks to this nice article on Building Mono on Windows, I had my build environment set up within a Cygwin environment on my Windows XP box and I was able to get my first set of "gmcs merge patches" in to bmcs.

(Paco, Thanks dude ! You are doing an excellent job in making my "Mono hacking" more productive and less hassle free. It gives me ready access to the benchmark implementation - Microsoft's vbc - while fixing up bmcs.

From this first ever merge, I could see the following challenges that lie ahead in keeping the gmcs and bmcs trees in sync:

  1. The merging of trees should happen as frequently as possible. Checkpointing every two weeks is a must till such time as bmcs begins bloating. Any longer intervals of merges between the two trees would become unmanageable.
  2. The feature additions to bmcs should itself be made in batches as opposed to increments so that one could keeping the lexical distance between the two trees to the minimum.
  3. The VB.NET specific changes should be properly documented either through visible comments or conditional compiler constants so that one doesn't end up losing those changes while performing a merge.

The above challenges need to be delicately managed, as otherwise bmcs might end up being a significantly different beast compared to gmcs. This would seriously hamper bmcs from borrowing liberally from gmcs.

Friday, February 04, 2005

Why BMCS and Why not MBAS ?

Earlier I had blogged about my intention to focus my spare time on contributing to bmcs. Therein I had declared my intention to make bmcs as "The future defacto Open Source VB.NET compiler".

An interested VB.NET user has raised the following questions - "This will delay a lot the VB.NET compiler development. All mbas compiler work will be discarded?"

The concerns of this VB.NET user is very valid but is totally unfounded. This is because folks from Novell - Manjula, Satya Sudha with additional help from Sudarshan and Ritvik Mayank - are continuing their work on mbas and making it better day by day. So mbas is not only thriving, it is all the more likely to see the light of the day much sooner than bmcs.

Some people might be tempted to think of bmcs as being positioned in direct competition with mbas. Let me clarify that it's actually the other way round. bmcs will coexist with mbas and try to leverage as much work done on mbas as possible. The birth of bmcs needs to be viewed as one creating a better, more futuristic and robust choice of for the Open Source VB.NET developers.

Let me explain why bmcs is "better", "robust", "scalable" and "futuristic".

bmcs is grown from a more mature C# compiler code base that has already seen the light of the day. If one carefully happens to look at the history of mbas, one would realize that it was also cultured out from the mcs code base - but one that's more than 2 years old. So the code emission modules in bmcs is that much more thoroughly tested and feature rich as compared to the one available in mbas.

bmcs is "futuristic". This is because bmcs is grown out of gmcs - Mono's next generation compiler supporting Generics and Partial Classes in C#. Hence bmcs can start supporting these features almost out of the box in no time.

To appreciate why bmcs is more "scalable", one need to carefully consider how mbas is going to mature. As someone, who had spent significant time working on mbas, I see development on mbas proceeding on the following two levels - neither of which is non trivial.

  1. Purging of C# language semantics with VB.NET language semantics
  2. Making the code generation and emission modules more robust and scalable

The task (1) above is something that needs to be done from scratch for both mbas and bmcs.

The only sensible alternative to task (2) would be to borrow liberally from the existing mcs or gmcs code base. That's easier said than done. This is because the class orgnization in mbas is very old and the class structure of mcs has evolved in to a totaly different beast since the fork. The differentiation has been rendered more pronounced by the aggressiveness with which mcs had grown in the intervening two years.

So bringing in new features like generics and partial classes means a significant refactoring and the attendant testing on mbas code base. Any sensible developer could see the enormity of this task.

It's in relation to task (2) that bmcs is going significantly outwit and outlive mbas . It can not only leverage the work that is being done on mbas but can also leverage the work done on the generics C# compiler. A periodic merging of patches is all that's required to make the later task possible.

Personally I am very upbeat about bmcs. The mood is as well shared by Rafael Texeira - the brain behind the Mono's VB.NET compiler