30 Billion to fight AIDS... and the catch is?

Wednesday, 30 May 2007 18:43 by salim

President Bush asked Congress to provide $30 Billion additional funding to fight AIDS. This is wonderful news. I have always wondered the reluctance for USA to provide funding for international efforts in health care and poverty alleviation. This is a right small step in the direction. So, I decided to read more about it, to see what the programs that will benefit from it are. Being a skeptic, I was expecting to find something fishy, may be a specification of drugs, or some wording about intellectual property. To my surprise, I did not find any rumor mills working in that direction. Then there it was…

The plan is to provide support for fighting AIDS by providing healthcare and medicines as well as a prevention plan. Guess what… The best way to prevent AIDS is abstinence. This is a principle that has been successfully tested in the US high schools. I am sure this will be the end of AIDS. We all know that it is a disease that God brought upon us for our own immoral actions. I strongly propose a strong advocacy against homosexuality as well. This will be a second dawn for Africa, centuries after the first dawn dawned on them as the missionaries.

An abstinence related story from Texas I think talks about this Prom dance where daughters go as dates of their fathers. They dress up and spend the night dancing and drinking non-alcoholic drinks. This is supposed to promote abstinence in female offspring apparently by somehow satisfying their natural sexual urges. I am not insinuating anything!!!!

Categories:  
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Delphi Win32 to Delphi.Net: Part I - Geting it Built

Monday, 28 May 2007 00:50 by salim

Converting from Delphi Win32 to Delphi.Net

There may be several reasons for deciding to move your codebase from win32 to .Net. Delphi users have a very unique opportunity to achieve this transition with much less effort than any other languages. However, beneath the apparent ease of conversion, there are several gotchas we need to be aware of. Some of them are simple compilation issues while others could cause very hard to debug runtime errors and performance issues.

While a simple recompiling of the code will be a good start for a conversion project, I strongly suggest you consider a refactoring as well. Package (assembly) management under .Net is much cleaner than under win32. .Net also provides better ways of modularization like a better reflective language, better managed interfaces, assembly loading strategies etc. In our particular case, we decided to maintain dual builds during most of the conversion process, which is crucial for us to have a production quality version of codebase at all times. If you are not planning for dual builds, you will need a full development cycle that guarantees feature parity between the win32 and .net versions before new features can be put in.

Any changes that go beyond type declarations and well known transformations must be covered by Unit tests provided you can execute them in both win32 and .Net. Chances are that, you will be making a lot of changes during the conversion process. Being able to prove your significant changes saves a lot of hard debugging time later.

Any codebase under continuous development will gather deep inter-linkages between modules that are hard to isolate and resolve. Rebuilding codebase under .Net gives you an opportunity to isolate these and similar issues. Instead of reusing the existing package projects (assuming you have a multi-package structure), start by creating a logical package structure and pull units into these packages starting from a known root level unit. A root level unit will have dependencies only to VCL and other core never-built libraries.

Since .Net allows multi-part package names, make use of them. Instead of calling your db access library as dbaccess.dpk, name it <mycompany>.<myapp>.DBAccess.dpk. You can match the package names to the default namespace of the package itself. You can change the default namespace for a package in the options dialog. I haven’t made a decision on the propriety of multiple packages defining same namespace. This could lead to confusion if you have large number of packages. However, you can use it to break dependency between two application areas which are logically in the same namespace.

Don’t expect wonders and miracles from the conversion. Your ugly forms will still look ugly, your bad performance could get worse, and you will be faced with a whole new set of idiosyncrasies. I believe that the advantages from .Net far outweigh these risks. But that is for another note.

Following is a compilation of issues, tips and tricks I collected during our .Net conversion process. They are not in any particular order. I will certainly be adding more to this list.

How to prepare for Delphi Win32 to Delphi.Net conversion

1. Get a good refactoring tool. The D 2005 has some refactoring capabilities, but you will need more than what it can do. Especially for moving, copying and pasting methods, modifiers and property accessors. We using Model Maker Code Explorer. The only issue I have found so far is that it adds fully qualified unit names (eg. Borland.Vcl.Classes even when you have the unit classes in your uses list) to the uses clause when you use a known class from the classes unit. I end up removing these as they break both .net and win32 build

2. Try to split your application/source code into smaller packages. Package management in Delphi.NET is much less problematic compared to previous versions of Delphi

3. Write as many unit tests as you can under win32. It will give you an idea of where the most painful dependencies are. This is very valuable information for your package design.

4. Scrub your code for compiler warnings, especially the ones about invalid type casts and platform independence. Most of these warnings have been promoted to errors under .Net.

5. If you are using third-party components, make sure they have a vcl.net version available. If not, make sure you have their source code and it is not too hard to compile under .Net. For example if you see a lot of pointer manipulations, windows API calls or ASM keywords in your third-party source, be very scared!!!

6. Get a fast machine, ideally a multi-core and have 1GB or even better 2GB RAM. Delphi 2005 and D 2006 are memory hogs. I routinely see close to 1GB used up by BDS during a long change/rebuild cycle.

7. Use DUnit and write tests for any unit that can be tested. If the unit cannot be tested, try similar constructs in test before making the change itself.

8. If you do not have a source control, install one. There are several open source options available. If you have MSDN subscription, try using Team Foundation Server. I have grown to appreciate the nice features TFS provides especially for an agile development environment.

9. Create a project group that contains everything you are compiling. This could be a bit of a load for Delphi, so go for that 2+GB.

10. Create a command-line script for compiling your project group from command line. Compiling from IDE is much slower than command line compiles.

11. Add your unit test projects to the command line compile and run them as part of the build.

12. Be ready for some boring work. Make sure that you have whatever keeps you alive on those endless build/fix cycles. May be you can take a cruise!!

TClass.NewInstance disappeared

Here is another one for the elusive "Conversion Guide from Delphi win32 to Delphi.Net" that Borland/Codegear has never written.

TClass had this nice virtual NewInstance method which would call the default constructor. We used this in a lot of factories. However, understandably so, Delphi.Net does not have a NewInstance method.

I imagine it would be awkward to keep this behavior under .Net. So, we will need to use other means for achieving the result. It did take some poking around to finally figure out how this is done. Well, it was not that hard once I looked in Borland.Vcl.Classes, the TReader method to construct a new instance. So, my solution was to rewrite the factory methods similar to the following.

function MyClassFactory.CreateInstance( aName : string ): TMyClass;
var params : array of System.Type;
    paramValues : array of TObject;
    aConstructorInfo : System.Reflection.ConstructorInfo;
begin
  SetLength( params, 0 );
  SetLength( paramValues, 0 );
  aConstructorInfo := getClass( aName ).ClassInfo.getConstructorInfo(params);
  Result := TMyClass( aConstructorInfo.Invoke(paramValues));
end;

In my case, the constructors did not have any parameters. If you are expecting parameters to your constructor, fill the params array accordingly. Unfortunately, this will not compile in win32. There goes the first IFDEF CLR.

Specializations of TMessage... a good thing, but!!!

To ease the marshalling requirements of sending messages, a large number of windows messages have been converted to specialized message types in Delphi.Net. However, this has introduced an interesting problem in conversion.

We have several components that override and redeclare message handlers. One of them is a CMParentFontChanged. The original declaration was

procedure CMParentFontChanged( var Message: TMessage ); message CM_PARENTFONTCHANGED;

In the implementation, it calls inherited, which has the following declaration.

procedure CMParentFontChanged(var Message: TCMParentFontChanged); message CM_PARENTFONTCHANGED;

The compiler will cast your TMessage to a TCMParentFontChangedMessage, resulting in a null reference under .Net. So, I was getting these mysterious “object reference not pointing to an instance” errors. (I still haven’t figured out how to make D2005 debug into .Net VCL source. That would have helped me figuring this out easier.) My resolution was to change the type of the inherited message handlers. If you have a lot of message handlers, this could become a headache.

Some interesting tricks that are biting back!!!!

In Delphi win32, explicit casts were not type enforced - meaning, you can cast an object reference to another type even when they are not compatible. While in most cases this would be disastrous, in one of the third party components we have, there was this interesting piece of code. It was trying to access the color of the parent to set its own color. However, since the parent is a TCustomControl, which doesn’t have a color property, it cast the parent to TCustomPanel in one case and TGroupBox in another both of which have a color property, and this worked fine.

When converted this code to .Net, it did compile. However, since the explicit cast is strictly typed (same as the as cast) the result of the cast was a nil, which of course created the "Object reference not blah blah"

Full reflective nature of .Net makes it easier to handle such situations. Instead of casting to an arbitrary class, use reflection to get PropInfo for the property you want to set or get. This technique can be used for even non-published properties under .net.

Following code snippet shows setting a text value to an arbitrary property of the control.

class procedure TMyControlhelper.SetString(aControl: TWinControl;
const propName: string; aValue: string);
var
PInfo : PPropInfo;
begin
PInfo := GetPropInfo ( aControl.ClassInfo, propName );

if ( PInfo <> nil ) then
begin
if ( PInfo.TypeKind = TTypeKind.tkString) then
SetStrProp( aControl , PInfo, aValue )
end
end;

Please note that PPropInfo is System.Reflection.MemberInfo and thus a full citizen of.Net reflection. You can use a similar method to get the values.

A small wrinkle to the above is when you need to set a delegate (event handler) the same way. In Win32, you can use a TNotifyEvent and cast it to a TMethod for setting a event handler. For e.g

SetMethodProp(aControl, propName, TMethod(aValue)); // win32

Where aValue is of type TNotifyEvent (or some other method of object type). However, this is not true under Delphi.Net. TMethod is a whole new class. It took me sometime to figure out how to resolve this issue. Finally, I found out, almost by accident that the reference of a TNotifyEvent is actually a TMethod. So, under .Net my code looks like:

SetMethodProp(aControl, propName, @aValue); // clr

Unit changes

1. Variant: As usual, there are several classes and constants that have changed units. The primary one is Variant. Variant is no longer declared in System. It is declared in variants. Well, a variant is just a TObject with a very interesting ObjectHelper. By the way, if any of you want to know how to write implicit conversion routines in Delphi, Look in the variants unit, TVariantHelper object. Really interesting stuff.

1. HRESULT. I have no clue where this constant was before. Now it is in Delphi.VCL.Windows

2. If any of you were being too smart by appending unit names to functions, here is a gotcha. If any of the system units where qualified ( for e.g System.copy instead of just copy), it is not going to work. System now refers to the System unit of Framework. Borland's system unit is called Borland.Delphi.System. So, if you really want to qualify a function from Delphi's system unit, write Borland.Delphi.System.Copy.

3. HInstance: I had to do a search the whole source directory for this. It is in WinUtils.

4. Where is the Point!!! : The Point and Rect routine has moved to Borland.Vcl.Types. Well many other things have moved there. For e.g TPoint declaration. But there is a typedef in Windows unit that refers to this TPoint

Simple issues in class declarations

Unsafe Methods: In our codebase, there were some methods I wanted to use direct pointer manipulations. These methods required adding the unsafe keyword to it.

Inherited Constructor: Most of us don’t follow the good programming practice of calling inherited Create in the constructors. For Win32 it was optional, and you could decide where to call it from within the constructor body. Under Delphi.Net, you must call the inherited Create before trying to access local fields and functions. It luckily shows as a compile time error.

Class methods as event handlers: It is possible to use class methods as event handlers/delegators. You cannot use a standard Delphi class method as a delegate under .Net. Delphi class methods are a very Delphiish

Visibility of Overriding Method: When the visibility of an overriding method in a descended class differs from Parent, Delphi win32 used to give a warning. Changing the visibility of an inherited method is no longer a warning, it is a compiler error. Only way to change visibility seems to be reintroducing.

Potentially polymorphic constructors should be virtual. That sure sounds mysterious!!! This is a compiler error I got. The offensive call was trying to create a class by using a variable of the type of that class. ( for e.g, FooClass = class of TFoo ). Changed the constructor to virtual and the compiler was happy.

Constructor is where the class is constructed: In Delphi win32, constructor was just a method that the compiler called during the creation of the object. The object is already allocated and initialized by the time you get to the constructor. However, in Delphi.Net, like any other .Net language, constructor is where the whole thing happens. Until you call the inherited constructor, the instance will not be initialized. There were several cases where the constructor was making use of instance variables and methods. In one case, the constructor was calling the inherited constructor passing to it an instance method as a delegate. This however was correctly flagged as an error (unlike Java!!!) by the compiler. The resolution of that issue was not very simple.

The change in constructor behavior has caused us more problems than simple compilation issues. It is common to use constructor as an initialize in Delphi Win32, which it was. In an ideal world, no one should be doing any initialization in a constructor, but in Delphi, the temptation was hard to resist..Net requirements could derail initialization dependencies and create hard to track bugs. If you confront a class hierarchy that has substantial amount of initialization code in constructors, you should try to refactor the initialization code out of the constructor to a virtual instance method called from the base constructor. This will give us a chance to verify the behavior before the actual conversion.

A related issue is dependency injection. A large initialization block is usually a symptom of arbitrary dependencies. If this is happening in your code, consider one of those dependency injection patterns.

Changed class internals

We are all humans and end up using some of the undocumented internals of VCL classes for convenience or tweaking performance. One such usage I found was of the internal pointer list that a TList holds. Accessing the values directly from internal list is slightly faster as it does not do bound checking. Under .Net, this internal list is a System.Collections.ArrayList. Furthermore, it does not do a bounds check before accessing the element of the internal list. You can either decide to sacrifice the performance gain in win32 code and access the items directly, or use compiler directive to direct access the items under .Net.

Variants are first class objects. All the variant magic is now simple operator overloads. Other than the requirement for adding the Variants unit where there are implicit casts of Variants to other types, I haven’t encountered anything that will break the conversion.

TGUID: This class is now just a System.Guid and does not have the internal D1, D2 etc. fields that the win32 TGuid structure has. There was one case where we were ascertaining if a Guid was empty by comparing the D1, D2 etc. to zero. This technique obviously won’t work under .Net. Following is what I ended up doing.

           NULLGUID = '00000000000000000000000000000000';
           ...
           Result := aGuid.Equals( TGUID.Create( NULLGUID ) );

TStringList.GetText and TStringList.SetText are not public anymore. I am not sure why someone want to use the methods instead of the Text. I do remember one time when the strings where only 256 bytes, GetText provided a way to get a PChar of the complete text representation of a TStringList larger than 256 bytes.

TWinControl. CMFocusChanged is gone. Instead it declares a virtual method FocusChanged( newFocusControl: TWinControl ). One of our TWincontrol descendants was handling this message, which needed to be changed to the overridden method.

Delphi Exception class under .Net is a redeclaration of System.Exception. This is a welcome change as we no longer need those weird third party contraptions or home grown stack tracing mechanisms. System.Exception class contains everything you need to know about the exception. For example, to get the stack trace just access Exception.StackTrace property. One change that might affect existing code is that Message property is now read only. You cannot append to the message property of an instance of an exception to provide additional information. However, System.Exception has an InnerException property which contains additional exceptions that were thrown before this one.

TList and ValueType Pointers

TList is a very popular container class for Delphi programmers. One common use for TList is to hold valuetype references, typically to native types. These constructs will take the address of the passed in value (integer, float, TDateTime etc.) and store it as a TList item. When the value is read, it will be dereferenced to the corresponding type.

There are two major differences in .Net. TList is now an array list that can hold any System.Object. Secondly, you cannot use the address operator on a ValueType.

If you want create a pointer to a ValueType, you will need allocate outside managed memory and marshal it back and forth. In a similar case, I considered three different approaches. First one was using marshalling. I soon found the horror in that approach. Second approach was to use Variants to hold value instead of a pointer. Third approach is to use Boxing; a technique .Net uses to make ValueTypes to behave as an object reference. Though Delphi.Net does not support auto-boxing, you can use a simple cast to box the value type, for example, you can make an integer into a boxed integer using TObject(value). Just to be sure, I wrote a small test that compares the three options. As expected, marshalling found to be the slowest approach followed by Variants. Boxing approach seems to introduce the least amount of overhead in the above scenario. Using Variants provide additional support for type checking and safe conversions. If you require this, use variants.

Categories:  
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Multi-verse and Brahman - May be there is a book here!!!

Saturday, 19 May 2007 01:41 by salim

Recently we in our alumni email group caught up in a heated discussion about god and miracles. Since I was in vacation this was a good opportunity to brush up my vedanta. So, when a discussion started about Ishaavaasyopanishad, well, specifically about the first Shloka

Ishaavaasyam Idam Sarvam Yatkincha Jagatyaam Jagat||
Tena tyaktena bhunjithaah. Maa gridah kasya svit dhanam||

Well, during the reading, I couldn’t but help think about the ramifications of M-Theory (another link) on the whole concept of Brahman, Maaya and Isha. So, I refreshed my Shankaracarya and found something rather interesting.

Shankaracarya took great attention to the logic of his arguments. Instead of saying something is so just because Vedas said so, he tried to come up with analogies and logical tools to provide an explanation, sometimes terming them as proofs. So, it is only natural to try to extend those logical steps to include new realizations of how things are.

While not all M-Theorists agree about multi-verses, they do agree that the laws of physics of this universe are not necessarily applied anywhere else in the 11 dimensional space. One of the significant achievement of M-Theory is explaining the singularity away from Big-Bang. But that would make it quite viable that such brane collisions happen more than once and could give rise to multiple universes.

So, how could one relate this possibility of differing fundamental laws being applied in different universes/branes/boundaries to Advaita?

The fundamental assumption in Advaita is that Brahman is the primordial, omnipotent, featureless, (not that, not that) presence (Nirguna). Isha is the manifestation of Brahma on Maaya. Furthermore, Isha is responsible for creating the universe, and is the causation. (Of course, the ultimate causation is Brahman). The universe is the effect of this, and at the same time, is a projection of Isha (Brahman by association) on Maaya.

When there are multiple universes with differing laws of physics, one could take two possible arguments. The first one is to say that Isha manifests universe in multiple ways with differing laws. But, a logical explanation will be to assume that in a multi-brane state (sthiti) it is quite possible to have multiple manifestations of Brahma on the branes. Ohh… my, this could even lead to the assumption that Branes are actually the causation of Maya. So, these manifestations of Brahma could be considered as different Isha, each of which is omnipotent, omniscience in the corresponding universe (or Brane if it had never collided with another one. I agree, I haven’t found a good enough explanation of what happens to the Ishas when a collision occurs. Survival of the fittest?)

It is like a hall of mirrors that has different mirrors with different surface geometry. Each one reflects you in different ways while all is you. (See, I too can come up with Shankaracaryanesque analogies.) One has to acknowledge the complexity of Hindu philosophy though. It is possible to come up with an esoteric definition with the help of as many Shlokas as you like using the Vedas and Upanishads.

I am sure one of those Frijtoff Capra likes will run with this or a similar take to provide more proof that the ancient philosophies actually did solve all the problems.

If somebody is still not clear, I do not subscribe to this idea. This is one of those thought plays you do instead of masturbating J

Categories:  
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

We are a bunch of idiots!!!

Thursday, 17 May 2007 01:06 by salim

I have been reading the comments on the article Why doesn’t Microsoft has a Cult Religion? I did blog about the article yesterday and did leave a comment in the article too. But I cannot but notice the sheer animosity people (apparently developers) express in these articles and discussion boards about their preferences in computer software companies and technologies.

It is common to have very passionate discussion about technology. But these days, especially when developers and IT discuss technology there is so much venomous exhortations against each other. Most of the time, the mudslinging is between the haters of the symbol of all evil Microsoft and the self appointed MS evangelists. I have seen some Linux fans showing their fangs at Java guys and vice versa. What I don't understand is the logic behind this.

Anybody who has some experience in the IT industry and actively participates in it clearly knows that there is no one solution and no one evil. Open source is not the next French revolution, it is just a business model (a pretty innovative one at that). Microsoft is not the embodiment of all evils; it is an amazing technology company with some very good products under their belt. Mac is great in their innovative design concepts that are so finely tuned to the youth. Java is a great language that practically redefined object-oriented languages.

As a developer, I embrace any technology that is exciting and give me a useful and flexible set of tools to do my work. Currently I am using MS products because that is what is providing me the most enjoyable work experience, be it in programming, or in making music. It doesn’t mean that I consider all other possibilities as lesser ones or unsuitable. I just am used to these and haven’t found any overwhelming reason to switch to anything else.

As I have been saying, this is a great time to be a software developer. We have so many options to choose from. Many of them wonderful to work with. Yes, they all do have their idiosyncrasies. So, I do look forward for the next big thing. And, it always comes… in such close successions.

So please, my fellow developers, please celebrate the diversity. We know that it is inevitable that everything will start to interoperate soon, may be with some seam. If something misses the boat, well, that is how it is. Don’t tell me you are not resourceful enough to move between the choices!!! if you are, then you will miss the boat too.

Categories:  
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Universe and me

Thursday, 10 May 2007 23:33 by salim

I was always infatuated by exotic physics and astronomy. However, I kind of left this interest hang out in the back of my mind for quite some time. In the last year or so I find myself spending more and more time reading about and thinking (well, a better word will be dreaming) about these subjects. I have to say, Discovery Science channel has something to do with it :-)

Anyways, the recent flurry of exoplanet findings is so amazing. In the last couple of weeks or so, there was the discovery of the earthlike planet (Planet Hunters Edge Closer to Their Holy Grail) that is at habitable zone of its star, series of in-depth findings about mars like exoplanets (Sizzling Planet Makes Some Stars Look Cool, Scientists Map Weather on Distant World, freezing cold).

Combine this with the recent solary system explorations that are providing astonishing information about our neighbourhood...

Every day brings in so much fascination. I can't wait for the day that will finally provide us with the universality of life. Ofcourse, part of the satisfaction comes from shaking the basis of most of the fundamentalist relegions that we are crazy about!!!!

Categories:  
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Nasty McAfee - Outlook 2007 issue

Monday, 7 May 2007 23:10 by salim

I finally took the move to office 2007 during the weekend and immediately hit by a very irritating issue. When I started Outlook 2007 the second time, it gave me a message box saying "naCmnLib.dll cannot be found, please reinstall office". First of all I have to say that it is a dumb message. It felt even dumber after I searched the name first which revealed that the file in question belongs to McAfee. So, Office guys, you need to change your dll resolution messages. (I know it could be just an exception that climbed up the ladders)

Outlook handles this issue very unlegently. After the above message, it exits and shows an error reporting screen. I almost always forgot about the checkbox that says restart outlook. So, everytime I dispose the error report screen, Outlook will restart, start receiving files, and crash. That is a good sunday morning!!!

Anyways, after searching several groups, all I could assertain was that, this definitely is an issue related to McAfee and there are other people who have seen this issue. No one seemed to have resolved it, or felt it would be useful for other people if they posted the resolution.

Then I found that my version of McAfee is centrally managed and cannot be updated individually. There goes that possibility.

The solution was very simple. I searched for naCmnLib.dll, found it, and added the path to my environment path. To my surprise (not) everything started working fine.

(Hey, I tricked you to read until here to find the solution. Dont think my oratory skills are good enough to capture your attention for much more. So, have a good day)

Categories:  
Actions:   E-mail | del.icio.us | Permalink | Comments (1) | Comment RSSRSS comment feed

New song - Last Day of Summer

Sunday, 6 May 2007 22:18 by salim

Well, as my music website is still rather unfinished, I decided to announce the new songs here and post them from the links on the side.

I have been trying to finish this song for the last several months. The first phase of the song went very well. Well, in most of my solo works, the first phase always finish very fast. Afterall, I usually record the whole song in one sitting. Eventhough in this song I played both Piano and Flute, it was one continuous session. I think that has given a very tight melodic structure to the song.

When I play meditative tunes, I want them to last for a long time. As always, I make something that I like to hear :)

Anyways, here is the song  Last Day of Summer.

If the contractor finishes my house soon, I will be able to upload a couple of more songs that wait mixing down.

Categories:  
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed