User:Vbala

Welcome to Vijey's Page

My Name's Vijey; I am currently in the seventh semester of BSD and enrolled in DPS909.

Lab Notes

• The diff file that was generated after the changes were made to tabBrowser.xml.
• The changes were made to open a new tab in between tabs rather than having it opening at the end like it usually does.

Index: tabbrowser.xml
===================================================================
RCS file: /cvsroot/mozilla/browser/base/content/tabbrowser.xml,v
retrieving revision 1.243
diff -u -8 -p -r1.243 tabbrowser.xml
--- tabbrowser.xml	18 Sep 2007 00:59:41 -0000	1.243
+++ tabbrowser.xml	15 Oct 2007 22:15:13 -0000
@@ -1088,17 +1088,17 @@
             if (!bgLoad) {
               function selectNewForegroundTab(browser, tab) {
                 browser.selectedTab = tab;
               }
               setTimeout(selectNewForegroundTab, 0, getBrowser(), tab);
             }
             if (!bgLoad)
               this.selectedTab = tab;
-            
+            var position = currentTabIndex + 1;
             return tab;
          ]]>
         </body>
       </method>
 
       <method name="loadTabs">
         <parameter name="aURIs"/>
         <parameter name="aLoadInBackground"/>
@@ -1173,17 +1173,18 @@
             t.maxWidth = this.mTabContainer.mTabMaxWidth;
             t.minWidth = this.mTabContainer.mTabMinWidth;
             t.width = 0;
             t.setAttribute("flex", "100");
             t.setAttribute("validate", "never");
             t.setAttribute("onerror", "this.parentNode.parentNode.parentNode.parentNode.addToMissedIconCache(this.getAttribute('image')); this.removeAttribute('image');");
             t.className = "tabbrowser-tab";
 
-            this.mTabContainer.appendChild(t);
+            var currentTabIndex = this.mTabContainer.selectedIndex;
+			this.mTabContainer.insertBefore(t, this.mTabContainer.childNodes.item(currentTabIndex + 1));
 
             if (document.defaultView
                         .getComputedStyle(this.mTabContainer, "")
                         .direction == "rtl") {
               /* In RTL UI, the tab is visually added to the left side of the
                * tabstrip. This means the tabstip has to be scrolled back in
                * order to make sure the same set of tabs is visible before and
                * after the new tab is added */
@@ -1952,17 +1953,17 @@
           this.mTabListeners.splice(aIndex, 0, this.mTabListeners.splice(aTab._tPos, 1)[0]);
 
           var oldPosition = aTab._tPos;
 
           aIndex = aIndex < aTab._tPos ? aIndex: aIndex+1;
           this.mCurrentTab._selected = false;
           // use .item() instead of [] because dragging to the end of the strip goes out of
           // bounds: .item() returns null (so it acts like appendChild), but [] throws
-          this.mTabContainer.insertBefore(aTab, this.mTabContainer.childNodes.item(aIndex));
+          this.mTabContainer.	Before(aTab, this.mTabContainer.childNodes.item(aIndex));
           // invalidate cache, because mTabContainer is about to change
           this._browsers = null;
 
           var i;
           for (i = 0; i < this.mTabContainer.childNodes.length; i++) {
             this.mTabContainer.childNodes[i]._tPos = i;
             this.mTabContainer.childNodes[i]._selected = false;
           }

FSOSS REPORT FOR DPS909

Introduction
The two talks I decided to write about which I attended in the FS0SS 2007 gathering were Benjamin Smedberg’s Open source code review and Mike Beltzner’s talk on Designing for and with a community.

Benjamin Smedberg's Open source code review
Focusing on the first talk that I attended; Benjamin Smedberg’s key main reasons behind code reading were as follows:

• Identifying Bugs
• Identifying and implementing features
• Creating documentation or revising documentation that is available for the code
• Understanding how the code works
• And the last and according to Mr.Smedberg the most hardest part of it all; keeping track of the patches or understanding what patches have been done on the software by other people in the community
  

All of the above points in my opinion are very valid points; which will play key roles in a person’s life as a programmer in some way or another. Identifying bugs is one of the main reasons for reading code; and this is why Benjamin agreed that every school in the country teaching computer programming related courses should teach students how to read code and get them involved in some sort of code reading before they leave school and are released into the business field. In his second point of implementing or identifying features Benjamin pointed out the need for properly placing a feature or finding a necessary spot to implement a piece of code in order for it to enhance the user experience requires code reading and code understanding; putting a feature or a piece of code anywhere is not going to produce the most desirable results, in many cases or almost all cases this would just mean inefficient processing time or the system crashing as a whole.

Creating documentation for today’s world of complex and never ending lines of code is key for other programmers who later wish to add to or enhance the already existing code base. This can only be accomplished through code reading and understanding of the correct points at which the documentation should be placed. This documentation could also be later revised as the code is changed or enhanced.

Not so surprising to me was the last point where Mr. Smedberg pointed one of the hardest parts of code reading was to understand what other people’s patches did to the software the original programmer created. To Mr. Smedberg this was one of the hardest or if not the hardest and most frustrating part of code reading, decrypting other people’s code and coding styles.

Mr. Smedberg also pointed out the importance of LXR/MXR as shown to us and stressed on many times by professor David Humphries in our DPS909 class. Mr. Smedberg also talked about tools such as Eclipse, and grep which are useful in finding code parts which are necessary for code reading and understanding. Benjamin regarded himself as the “Guru” of code review, and coding in it self. Mr. Smedberg’s views of the open source world was beginning to sound more and more like the cathedral and the bazaar literature I read back at the beginning of the course. Although he did not quite come out and mention this himself; I got the impression, maybe it was my misunderstanding, especially during his talk about reading other peoples code and patches to bring a consistency to the code base felt like he was drawing parallels to bringing order to chaos and finally producing a product that can help people all through out the world.

Mr. Smedberg also gave some good tips on finding a bug’s source. But before he got into those three points he mentioned one key thing that stood out to me, he (Benjamin) said “You do not always have to understand all the bugs or know how to fix it all”. This drew parallels to something Albert Einstein once said and it seemed to stick in my mind always “Why should I remember something that I can just look up?” That being said the three tips he gave for identifying bugs location are

• Look for common bad patters
• Look for uncommented code bits
• Look for code which was changed recently or something that has being undergoing consistent change
  

Contact Info

vbalasun@learn.seneac.on.ca
or
vijeybala@gmail.com

My Blog

my blog