LXR/MXR is a cross-reference display of Mozilla source code. A user can perform a search using a keyword and it will return results of all occurrences of that keyword in the Mozilla source code. The results can also be broken down into more specific identities i.e. function name, variable name, etc.
In the lab, I tested MXR and tried to find how the "Go Back" feature in Firefox was coded. I typed in go "Go Back" into the search text field, performed a search and was shown a resulting list of all occurrences where "Go Back" was typed, be it actual code or comments. As it searched the entire Mozilla source code, I wanted a more application specific query so I typed in "browser" in the "in files matching" field. This helped narrow the search significantly.
The first file that caught my eye was the browser.js file as Mozilla was mainly written in JavaScript. I went into that file and only saw a few lines of code in the "BrowserBack" function. It appeared as if the JavaScript file served as a linking mediator. After further searching, I was able to narrow the GoBack() function down to the "nsIWebNavigation.idl" file and "nsDocShell.cpp." As the "nsIWebNavigation.idl" was an interface file, I only saw a declaration of void goback() but there was no actual code. In "nsDocShell.cpp." there was some code and further call to webnav->GoBack(). I was unable to find any more code form there, the files that resulted in further searching came up as more *.idl, *.js and *.h files which were linker files.
From my experience, MXR seems like a helpful tool, as the Mozilla source code contains over 6 million lines of code as well as thousands of files, manually searching, it would take a very long time to navigate and narrow down to what you need to find. MXR really helps cut this time down as it provides links in the source code to help you further progress your search. The search still takes a while though, it took me about 40 minutes to traverse through the results but once you get more familiar with how the searching works, you'll be able to include more specific options and that should cut your searching time down even more.
Monday, October 1, 2007
Creating a Debug Mozilla Build
My initial attempts of creating a debug Mozilla build was a pretty rough ride that ended in a terrible crash. At first, I had to download and install the Visual Studios 2005 which took me about 2 days. After I got my computer set up to the point where I can start following the steps for "Building Mozilla for the first time." I realized I was way over my head.
I have never built anything this big from source before so my inexperience proved to be a liability. As hard as I tried to follow the instructions, in the end I was still unsuccessful with compiling the source. My two attempts ended with memory accessing errors. I looked at my task manager and it was bombarded with make.exe that took up around 1.7MB but there were several hundred of them which in the end ate up all of the memory I had on my laptop (~2GB).
Fortunately, we did a build in our lab class and although I built the debug Mozilla build on Linux (much faster than Windows) I was able to transfer the knowledge so that my third attempt at building Mozilla at home was finally successful.
The two problems that I identified was that I had some mistypes in my "check out" statement so I never actually downloading the Mozilla source. The second problem was that my .mozconfig did not specify any project. All it had was:
# Add options
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
# Optimization
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --disable-static --enable-shared
The combination of those two problems, I think, caused the program to continuously looping, creating make.exe until my machine ran out of RAM which took about six hours for each attempt.
I have never built anything this big from source before so my inexperience proved to be a liability. As hard as I tried to follow the instructions, in the end I was still unsuccessful with compiling the source. My two attempts ended with memory accessing errors. I looked at my task manager and it was bombarded with make.exe that took up around 1.7MB but there were several hundred of them which in the end ate up all of the memory I had on my laptop (~2GB).
Fortunately, we did a build in our lab class and although I built the debug Mozilla build on Linux (much faster than Windows) I was able to transfer the knowledge so that my third attempt at building Mozilla at home was finally successful.
The two problems that I identified was that I had some mistypes in my "check out" statement so I never actually downloading the Mozilla source. The second problem was that my .mozconfig did not specify any project. All it had was:
# Add options
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
# Optimization
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --disable-static --enable-shared
The combination of those two problems, I think, caused the program to continuously looping, creating make.exe until my machine ran out of RAM which took about six hours for each attempt.
Monday, September 17, 2007
Revolution OS
Revolution OS is a documentary made in 2001 that details Linux and the open source movement. It interviews many key players that are involved in contributing the success of Linux and open source as well as provide statical blurbs detailing its growing popularity.
I found this documentary very interesting and enjoyable. As a person that's rather new to Linux and open source, there was a lot of great points that helped clarify what exactly is open source and free(dom) software. I really enjoyed listening to the interviews with all those renown people that started Linux and the free software/open source movement. The interviews gave me great insight into their ideology and reasonings for what they did and how much ambition and courage that they had to follow their dreams.
The documentary mixed in a lot of humor and quirkiness that had me chuckling throughout the movie. An example of this was when Richard Stallman was giving a speech after receiving the "IDG/Linus Torvalds Community Award." The documentary depicts Richard Stallman as a very passionate person when it comes to free software. So to alleviate the seriousness of his mission statement, the cameras seem to have been fixated on Linus Torvalds' two daughters running around on the stage. I feel that this reflects how the GNU/Linux community is friendly, understanding and accepting as I doubt anyone else anywhere could get away with having their kids running around during a key acceptance speech.
Though this documentary was made in 2001, historical by computer standards as a "Linux" year is six months, with Linux and open source picking up more steam and becoming more popular with each passing year the philosophies in the film are still very relevant and really helps provide all the newbies, myself included, a better understanding and possibly the necessary nudge to break out of the shackles of proprietary software and embrace these Linux and open source communities.
I found this documentary very interesting and enjoyable. As a person that's rather new to Linux and open source, there was a lot of great points that helped clarify what exactly is open source and free(dom) software. I really enjoyed listening to the interviews with all those renown people that started Linux and the free software/open source movement. The interviews gave me great insight into their ideology and reasonings for what they did and how much ambition and courage that they had to follow their dreams.
The documentary mixed in a lot of humor and quirkiness that had me chuckling throughout the movie. An example of this was when Richard Stallman was giving a speech after receiving the "IDG/Linus Torvalds Community Award." The documentary depicts Richard Stallman as a very passionate person when it comes to free software. So to alleviate the seriousness of his mission statement, the cameras seem to have been fixated on Linus Torvalds' two daughters running around on the stage. I feel that this reflects how the GNU/Linux community is friendly, understanding and accepting as I doubt anyone else anywhere could get away with having their kids running around during a key acceptance speech.
Though this documentary was made in 2001, historical by computer standards as a "Linux" year is six months, with Linux and open source picking up more steam and becoming more popular with each passing year the philosophies in the film are still very relevant and really helps provide all the newbies, myself included, a better understanding and possibly the necessary nudge to break out of the shackles of proprietary software and embrace these Linux and open source communities.
The Cathedral and the Bazaar
The Cathedral and the Bazaar is an article written by Eric S. Raymond describing the analogy of closed source, Cathedral, and open source, bazaar, development. Eric uses his own personal experience of developing and maintaining an open source project called "fetchmail" to further illustrate his analogies.
I feel that this is an excellent article for those that are new to the open source concept and wish to join its community. It lists a lot of fundamental points to help reduce any cultural-shocks when experience new environments, especially those that have been used to the closed source model. Two points that I feel help identify the difference between closed source and open source and which also shows open source as a successful paradigm are:
"6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging."
"7. Release early. Release often. And listen to your customers."
The reason I chose these two points was because they revolve around the fact that the best success is to be non discriminating against any type of input. This approach will not alienate anyone that tries to contribute and as a result, you are rewarded with more innovative ideas that will help further improve your product. Also, I feel that frequent releasing will lead to better testing and a more stable product because when releasing in small increments, it is always easier to pinpoint where bugs arise as you only need to look at the newly added segments as compared to entire sections of code.
After reading the article, I better understand how the open source community interact with each other as well as why having an open source project would be so much more successful. Because the developers that contribute to open source projects are volunteering, I feel that they are more passionate about their offerings, otherwise they would not be contributing at all. They are also more relaxed and will most likely take more chances in radical ideas as this is a hobby and they would not lose much if it does not pan out. These factors help innovate project further past any closed source rivals.
I feel that this is an excellent article for those that are new to the open source concept and wish to join its community. It lists a lot of fundamental points to help reduce any cultural-shocks when experience new environments, especially those that have been used to the closed source model. Two points that I feel help identify the difference between closed source and open source and which also shows open source as a successful paradigm are:
"6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging."
"7. Release early. Release often. And listen to your customers."
The reason I chose these two points was because they revolve around the fact that the best success is to be non discriminating against any type of input. This approach will not alienate anyone that tries to contribute and as a result, you are rewarded with more innovative ideas that will help further improve your product. Also, I feel that frequent releasing will lead to better testing and a more stable product because when releasing in small increments, it is always easier to pinpoint where bugs arise as you only need to look at the newly added segments as compared to entire sections of code.
After reading the article, I better understand how the open source community interact with each other as well as why having an open source project would be so much more successful. Because the developers that contribute to open source projects are volunteering, I feel that they are more passionate about their offerings, otherwise they would not be contributing at all. They are also more relaxed and will most likely take more chances in radical ideas as this is a hobby and they would not lose much if it does not pan out. These factors help innovate project further past any closed source rivals.
Monday, September 10, 2007
Subscribe to:
Posts (Atom)