Last two weeks of working on LIR assembler provided one of the most challenging pieces of work done yet. Multiple fragment support in LIRasm was implemented almost completely, and landed in the tracemonkey repo. I got to look up current source code, understand the way it is performing, modify it to support mutliple fragments, battle with segfaults and memory leaks, and do a whole lot of implementation and re-implementation before finally getting an acceptable version. And it would be correct to say the hardest things bear the sweetest fruits in the end. I am really happy that I finished this part of the project.
Undoubtedly, I got great support from my project mentor, jorendorff, humph, and graydon. Without their support, guidance and everlasting patience, I would never have been able to come so far. Although the assembler is far from finished, it has been a great journey so far, with its ups and downs, and we have managed to pull through so far. I really respect this community and the people I have been working with, and I just can't see its engagement with me ending.
In the process, I fear I have disappointed people and committed some stupid mistakes. In particular, I think last post in my blog sent the wrong message to many people, and I would like to clarify whatever I believe was uncalled for on my part. I think I sounded disappointed and possibly hateful(I am not finding the right word here) in the overall tone of the post. It represented in general my feeling at that time, since I had worked hard on the project and most of my work was not going to be used in the new world. I think it was just a manifestation of the feelings associated with the unfortunate event of code duplication. Everyone loves their work.
Anyway, I am very much grateful to Mozilla Education for providing me with this opportunity to work on such a real project. I think its a great gesture, and will definitely publicise it in my college so that more juniors can benefit from it.
Tuesday, June 30, 2009
Monday, June 15, 2009
[LIR Compiler/Assembler?] Current Status
We hid a roadblock last week when it came to our notice that another version of LIR Assembler(https://bugzilla.mozilla.org/show_bug.cgi?id=484142) was being developed by Graydon Hoare(graydon), using only handcoded c/c++. The whole of last week went into deciding what should be done with the two working versions, seemingly both equally developed upto a certain extent.
The major problem was in merging the two forks - we were using a parser generator based approach, and graydon was using handcoded c++. It is far from trivial to merge the two, and hence, one version had to go. We spent one day going over the pros and cons of either approach. The summary of our discussion follows -
Graydon was advocating the fact that parser generators lead to 'mucky' .y files, a tool dependency, and are difficult to land.
Our case was that the .y files lead to much cleaner, neater classified code, separating the logic from the implementation to a certain extent. It involved significantly lesser number of code lines, and would also be extensible/modifiable(easily) in the future if additional syntax requirements appear.
As things turned out, we were deadlocked, and the decision to choose one particular fork lay upon me.
I went with graydon's version.
graydon's version was actually going to be landed in the tracemonkey repo, and this was one of the reasons I chose his version. The remainder of the week was spent in making lirasm(as our new lir assembler is now called) appropriate for the source tree, and then landing it in the repository.
During this time, I read up on Mercurial Queues(MQ), and learnt about the Bugzilla way of doing things (using patches, filing bugs) compared to the BitBucket approach we used earlier.
Things will get on track from today probably, and we have a bug to work on(https://bugzilla.mozilla.org/show_bug.cgi?id=497991).
The main setback of the whole duplication situation was time. When it occurred, things were going very - I mean very smoothly, and it really seemed most of the work for LIR Compiler would be finished in two weeks time. I will get more idea today on how much time this is going to take now.
The major problem was in merging the two forks - we were using a parser generator based approach, and graydon was using handcoded c++. It is far from trivial to merge the two, and hence, one version had to go. We spent one day going over the pros and cons of either approach. The summary of our discussion follows -
Graydon was advocating the fact that parser generators lead to 'mucky' .y files, a tool dependency, and are difficult to land.
Our case was that the .y files lead to much cleaner, neater classified code, separating the logic from the implementation to a certain extent. It involved significantly lesser number of code lines, and would also be extensible/modifiable(easily) in the future if additional syntax requirements appear.
As things turned out, we were deadlocked, and the decision to choose one particular fork lay upon me.
I went with graydon's version.
graydon's version was actually going to be landed in the tracemonkey repo, and this was one of the reasons I chose his version. The remainder of the week was spent in making lirasm(as our new lir assembler is now called) appropriate for the source tree, and then landing it in the repository.
During this time, I read up on Mercurial Queues(MQ), and learnt about the Bugzilla way of doing things (using patches, filing bugs) compared to the BitBucket approach we used earlier.
Things will get on track from today probably, and we have a bug to work on(https://bugzilla.mozilla.org/show_bug.cgi?id=497991).
The main setback of the whole duplication situation was time. When it occurred, things were going very - I mean very smoothly, and it really seemed most of the work for LIR Compiler would be finished in two weeks time. I will get more idea today on how much time this is going to take now.
Subscribe to:
Posts (Atom)