For the next three working days including today, I will have to attend interviewing skills triaining program. Yesterday I attended a video presentation on various factors involved in interviewing.
Will write in detail after the training. However, the quality of the material used in yesterday's video presentation was really good. If an interviewer follows the tips/tricks/strategies/etc mentioned in the material, I would say, he will never ever pick a wrong person for his/her company.
Ok, feeling sleepy, will fill-in more at the end of each day's session. :)
Friday, August 05, 2005
Block diagrams to Wireframes
Yesterday, I, finally managed to complete an outline-sketch of the functional working of the mail-remote plugin glue code. After a couple of hours sleep and a good lunch, got NotZed on the evolution channel asking for his views about the outline-sketch.
He was ok with the approach that was taken in the outline-sketch, however, wanted to refine and trim some of the functions/assumptions. He explained me the facts about the data that are passed from the mail-remote plugin (server interface). Also, he suggested few things like defining structures for the interface types exposed in the IDL file and emitting individual signals for each type of "change_type" instead of a single signal with multi-parameters.
As a matter of fact, the values that are passed to the callbacks, registered in the glue-code to handle signals from the plugin, assumes a particular order and the same should be maintained.
So, with those suggestions, the mere outline-sketch has transformed into a more-or-less neat sketch that clearly defines the shape of the glue-code. (Now the sketch spans to multiple-files.)
He was ok with the approach that was taken in the outline-sketch, however, wanted to refine and trim some of the functions/assumptions. He explained me the facts about the data that are passed from the mail-remote plugin (server interface). Also, he suggested few things like defining structures for the interface types exposed in the IDL file and emitting individual signals for each type of "change_type" instead of a single signal with multi-parameters.
As a matter of fact, the values that are passed to the callbacks, registered in the glue-code to handle signals from the plugin, assumes a particular order and the same should be maintained.
So, with those suggestions, the mere outline-sketch has transformed into a more-or-less neat sketch that clearly defines the shape of the glue-code. (Now the sketch spans to multiple-files.)
Epitome of absent-mindedness
Absent-mindedness is one of the common states of human-brain during which it is completely preoccupied by something like a single-big-monolithic process running on a "non-multitasking" system.
Why am I talking about absent-mindedness?
Ah!! its about the result of a recent "preoccupied" state of my brian. As you might know that I am working on writing wrappers and lately started working on writing a bonobo-client/wrapper for the mail-remote plugin. It is this *thing* that occupied my whole brain because of which I forgot to sleep yesterday. Ugh?
After fixing-up that gapi stuff, I disconnected the dialup and was taking a deeeeeep-stretch, there was this sound "trrrrrrrrrrrrrrrrrrrringggggggggg", well, my alarm-timepiece shouted loud (7:15 AM), making me realize that I actually forgot to sleep. :)
(BTW, it was around 7:15 AM)
Why am I talking about absent-mindedness?
Ah!! its about the result of a recent "preoccupied" state of my brian. As you might know that I am working on writing wrappers and lately started working on writing a bonobo-client/wrapper for the mail-remote plugin. It is this *thing* that occupied my whole brain because of which I forgot to sleep yesterday. Ugh?
After fixing-up that gapi stuff, I disconnected the dialup and was taking a deeeeeep-stretch, there was this sound "trrrrrrrrrrrrrrrrrrrringggggggggg", well, my alarm-timepiece shouted loud (7:15 AM), making me realize that I actually forgot to sleep. :)
(BTW, it was around 7:15 AM)
Thursday, August 04, 2005
I am one among the top three
A google on "Varadhan" showed my blog link in the first three search results. :)
Soon will reach the pretigious No.1 position.
Soon will reach the pretigious No.1 position.
Mail-remote plugin glue code and GAPI
After adding that LastModfied support to the ECal# bindings, I continued my journey of providing wrappers for the mail-remote plugin. With the enough homework that I did during the day time, started with writing the base prototype that exposes four signals, two for session, one for store and one for folder.
Defined functions to lookup and initialize all the necessary callbacks. We connect to signals provided by the listeners process them and emit our own signals that will be handled in the managed-code.
make && make install went through. Now, the final step, generating C# code for the mail-remote-glue object. *BANG*, gapi spit out something like
store_changed struct _EMailRemoteGlueClass {GObjectClass parent_class;void (*session_shutdown) (EMailRemoteGlue* emrg, gpointer data);void (*folder_changed) (EMailRemoteGlue* emrg, GSList* added, GSList* removed, GSList* changed);}; at /usr/bin/gapi2xml.pl line 881, line 92.
Tried few combinations of typedefs, positioning of "*" in a declaration etc. Nothing helped. Finally, opened the /usr/bin/gapi2xml.pl file to see what is happening in line 881. It clearly mentioned that it is failing while decoding/creating "Signal" definition.
With that clue, I read through the code once again and found out a typical "copy & paste" error, that resulted in the "registration" of same signal twice, which GAPI promptly pointed out.
I fixed that and GAPI and my glue-code lived happily thenafter.
Defined functions to lookup and initialize all the necessary callbacks. We connect to signals provided by the listeners process them and emit our own signals that will be handled in the managed-code.
make && make install went through. Now, the final step, generating C# code for the mail-remote-glue object. *BANG*, gapi spit out something like
store_changed struct _EMailRemoteGlueClass {GObjectClass parent_class;void (*session_shutdown) (EMailRemoteGlue* emrg, gpointer data);void (*folder_changed) (EMailRemoteGlue* emrg, GSList* added, GSList* removed, GSList* changed);}; at /usr/bin/gapi2xml.pl line 881,
Tried few combinations of typedefs, positioning of "*" in a declaration etc. Nothing helped. Finally, opened the /usr/bin/gapi2xml.pl file to see what is happening in line 881. It clearly mentioned that it is failing while decoding/creating "Signal" definition.
With that clue, I read through the code once again and found out a typical "copy & paste" error, that resulted in the "registration" of same signal twice, which GAPI promptly pointed out.
I fixed that and GAPI and my glue-code lived happily thenafter.
Was it a race condition?
ECal# provides two types of APIs to get a list of calendar events present in a calendar.
First type is based on "Query/Response" and the other is "Compare-with-last-fetched-items-and-return-the-final-list" sort of method.
In Beagle, the new Evolution Calendar backend that Joe Shaw is working on calls "GetChanges", second-type method, to get a list of what-so-ever-has-happened since last call. Once things are setup properly, GetItems() is called. GetItems() works on "Query/Response" basis and once the query is setup and the Start() method is called, the results satisfying the query are returned immediately, causing Beagle to re-index them immediately.
Where the heck is the race-condition here?
Well, the first-time "results" of the query are the same calendar-events that are already indexed. So, it might appear like a race-condition, but, in reality, it is not. Perhaps, can be called "an unwanted" condition, though, cannot be avoided.
To handle this safely, the new CalComponent class exposes a property called LastModified, with which the first-set-of-results can be compared and avoided from a "re-indexing".
First type is based on "Query/Response" and the other is "Compare-with-last-fetched-items-and-return-the-final-list" sort of method.
In Beagle, the new Evolution Calendar backend that Joe Shaw is working on calls "GetChanges", second-type method, to get a list of what-so-ever-has-happened since last call. Once things are setup properly, GetItems() is called. GetItems() works on "Query/Response" basis and once the query is setup and the Start() method is called, the results satisfying the query are returned immediately, causing Beagle to re-index them immediately.
Where the heck is the race-condition here?
Well, the first-time "results" of the query are the same calendar-events that are already indexed. So, it might appear like a race-condition, but, in reality, it is not. Perhaps, can be called "an unwanted" condition, though, cannot be avoided.
To handle this safely, the new CalComponent class exposes a property called LastModified, with which the first-set-of-results can be compared and avoided from a "re-indexing".
Wednesday, August 03, 2005
Bonobo - The Crypted Magic word
I am happy that atlast the time has come to complete one of my long pending (personal) tasks, learning to use bonobo. Thanks to Michael Zucchi (NotZed) for his mail-remote plugin which exposes bonobo interfaces to talk with it.
As part of writing C# wrappers for things in evolution & co, I started writing a client-code in "C" for the mail-remote plugin interface. Thanks to Michael Meeks for his tutorial on bonobo. The sample How-to also came handy to quickly understand and start coding the client. Thanks to Google to find this one, which really helped me to quickly prototype my client.
Ok, here is how my client works. Client has two parts, 1) Implementation of listeners and 2) glue-code.
Listeners: These implements various listener classes and their methods. Also, emits g_signals that the glue-code can connect to and process it.
Glue-code: This is the actual client-code that talks to the server-side (the plugin) interface and exposes signals to the C# layer. Hope GAPI will pick-it-up and create a "nice" code by itself. ;)
Ok, its time to actually do some coding. More later.
As part of writing C# wrappers for things in evolution & co, I started writing a client-code in "C" for the mail-remote plugin interface. Thanks to Michael Meeks for his tutorial on bonobo. The sample How-to also came handy to quickly understand and start coding the client. Thanks to Google to find this one, which really helped me to quickly prototype my client.
Ok, here is how my client works. Client has two parts, 1) Implementation of listeners and 2) glue-code.
Listeners: These implements various listener classes and their methods. Also, emits g_signals that the glue-code can connect to and process it.
Glue-code: This is the actual client-code that talks to the server-side (the plugin) interface and exposes signals to the C# layer. Hope GAPI will pick-it-up and create a "nice" code by itself. ;)
Ok, its time to actually do some coding. More later.
Why a patch review is required?
Today, I witnessed the reason for doing a patch review. Two days back, I landed a load of changes to the Evolution-sharp cvs along with a stupid change to one of the functions in the calendar glue-code that would cause, actually, caused a pretty straight "crash".
Though, my unit-testing passed with out any error, the crash was very obvious when Joe pinged me on the channel.
This blog would keep reminding me to do a self-patch-review before commits.
Also, a message to myself, "DO NOT COMMIT ANYTHING PAST MIDNIGHT."
Though, my unit-testing passed with out any error, the crash was very obvious when Joe pinged me on the channel.
This blog would keep reminding me to do a self-patch-review before commits.
Also, a message to myself, "DO NOT COMMIT ANYTHING PAST MIDNIGHT."
Tuesday, August 02, 2005
ECal# handles recurrences
Did I say "recurrence"? Ugh, Yes, just did. The show continued to take the pace as the Showstopper was cleared.
I can say ECal# provides recurrence information as well, though, in a similar fashion that of e-d-s. A very minimal ToString() override is in CVS today that returns a "human-readable" string representation of recurrence meetings.
The recurrence part of the RFC 2445 is bit tricky, though, does provides all possible information about a recurrence meeting. This is one of the features in ECal# that took little longer time for me to understand and wrap it up.
More stringifying needs to be done.
I can say ECal# provides recurrence information as well, though, in a similar fashion that of e-d-s. A very minimal ToString() override is in CVS today that returns a "human-readable" string representation of recurrence meetings.
The recurrence part of the RFC 2445 is bit tricky, though, does provides all possible information about a recurrence meeting. This is one of the features in ECal# that took little longer time for me to understand and wrap it up.
More stringifying needs to be done.
The Showstopper
On Friday, 29th July, started my hunt for memory leaks in the recent ECal bindings in Evolution#.
Found a potential memory leak when creating an array of CalComponent objects from icalcomponent and ECalComponent objects. The call to the glue-API that does the intermediate conversion to ECalGlueComponent objects expects the caller to free the returned list of ECalGlueComponent objects but was never freed, instead, the individual fields of this objects were getting freed through the GLib.Marshaller.PtrToStringGFree() method. In order to fix this, I wrote a glue-API that takes the list of ECalGlueComponent objects are unref's them.
Every thing went fine till the new "memory-leak fix" API was called. When the API tried to unref the objects, *BANG*, a sexy segfault occurred.
Spent the whole afternoon trying to nail the culprit in the holy cross, but, didn't. Packed the laptop and caught the 2:30 PM bus to my native.
Saturday, 30th July, 10:00 PM:
Booted to my linux partition. (laptop has got a default windows partition, to be removed). Started hunting for the criminal that actually frees the memory of one of the fields of ECalGlueComponent object. Spent an hour adding all possible g_warning aka fprintf to pring debug messages.
*Voila*, to the epitome of surprise, found the hide-out of the culprit who was doing this - Mono marshaller.
Suppose, if a native call returns a "char*", mono converts it to "string" type by default. However, as an added-offer, it also "de-allocates" the source/original memory.
I am not pretty sure on the behaviour, though.
Expect the unexpected?
Found a potential memory leak when creating an array of CalComponent objects from icalcomponent and ECalComponent objects. The call to the glue-API that does the intermediate conversion to ECalGlueComponent objects expects the caller to free the returned list of ECalGlueComponent objects but was never freed, instead, the individual fields of this objects were getting freed through the GLib.Marshaller.PtrToStringGFree() method. In order to fix this, I wrote a glue-API that takes the list of ECalGlueComponent objects are unref's them.
Every thing went fine till the new "memory-leak fix" API was called. When the API tried to unref the objects, *BANG*, a sexy segfault occurred.
Spent the whole afternoon trying to nail the culprit in the holy cross, but, didn't. Packed the laptop and caught the 2:30 PM bus to my native.
Saturday, 30th July, 10:00 PM:
Booted to my linux partition. (laptop has got a default windows partition, to be removed). Started hunting for the criminal that actually frees the memory of one of the fields of ECalGlueComponent object. Spent an hour adding all possible g_warning aka fprintf to pring debug messages.
*Voila*, to the epitome of surprise, found the hide-out of the culprit who was doing this - Mono marshaller.
Suppose, if a native call returns a "char*", mono converts it to "string" type by default. However, as an added-offer, it also "de-allocates" the source/original memory.
I am not pretty sure on the behaviour, though.
Expect the unexpected?
Subscribe to:
Posts (Atom)