Open Source Hacking
Monthly Archives: November 2011
Woah, almost completely forgot to actually blog about this!
I finally finished off this plugin, long overdue in my opinion. It’s funny because this was actually the first ticket that I planned on working on for our 0.1 release but things took a left turn at Albuquerque when I found that small typo in the old Facebook plugin. Next thing you know I’m re-writing the Facebook plugin during 0.1 and 0.2!
I’m glad I finally finished this off for a few reasons. For one I felt bad neglecting it and giving it no attention for so long but because it also showed that I could write something from scratch. The Facebook plugin as it stands now may be very different than it originally was but I still didn’t write any of it from the ground up and I had a lot of guidance on it the whole way through. With the Tumblr Plugin I was left to make a lot of decisions myself about how I would process the JSON data that was being returned to me and this made me really have to think through how I wanted the user to not only view their data but to use this plugin.
The Tumblr API provides a lot of options when it comes to returning multiple posts with multiple sorting options but to me it didn’t make sense to allow a person to request multiple posts. All the plugins to this point have been about singular things with each invocation of an event. To me it didn’t make sense to be displaying multiple blog posts at once but rather to be specific and show information about one at a particular time. That and it’s a whole hell of a lot easier to code this but also use as a developer because there aren’t nearly as many confusing options you have to worry about.
I eventually want to come back to this and change how some of the request types display their data. One in particular is the chat blogpost because right now it simply displays each dialogue item all at once. I want it to almost be it's own sub event that maybe fades each item in to add a nice cool effect to it.
Anyway that's all for now. See you all around!
While hanging around in the #seneca channel on irc.mozilla.org reading through what I had missed on our advancements/discoveries with implementing MouseLock I noticed ted mentioning some silly and easy bug that humph should totally fix. Then I made the comment “Easy bugs are always nice”, or something along those lines anyway.
Boy what a mistake THAT was…..
Just kidding. While it honestly at it’s core is an easy fix there’s a lot of little things I will have to do first to ensure I can submit patches properly because I use git over mercurial. The biggest thing I will be learning is just going through the process of fixing a bug with Bugzilla. There are obviously a lot of hoops and rings of fire that I’ll need to jump through to get my patch through and accepted; Imagine if it was actually a complicated change! Sharks with Lasers maybe?
I’m happy it’s an easy fix because honestly I’m not that talented of a programer. I love open source and definitely want to be involved with this kind of process more as it’s a lot of fun but my theoretical knowledge is definitely lacking. I don’t know if that’s typical or not of someone who has only been programming for two years now or not but oh well.
Anyway, this will be covering my 0.4 release for our open source class and it should be a blast. If you ever want to view information on the ticket you can look at this link here (Bug 334573), or add yourself to the CC list if you want to stay up to date on what’s happening with it.
Till next time….
While I know I’ve done something terribly wrong, I still find it incredibly interesting having the browser freeze on me and then get this awesome stack trace printed on my terminal.
If you want to actually look at the code it’s here.
Definitely forgot that I even ran into this error because after Thursday last week I just stopped trying to figure it out!
Anyway, for whatever reason when I try running the Makefile in my built NightlyDebug it seems to fail because it doesn’t know what export or tools are? As it stands I have no idea what this means and in the meantime hoping that throwing this up will allow someone to see the problem until I am able to attack it later.
http://pastie.org/2867999 Terminal Output
Sorry for the vagueness of the post!
So after finally getting it the Nightly firefox built I of course went around looking for something easy to change that I understood but would also ALWAYS be visible/accessible.
After searching around for a bit I found the code that affects Firefox’s about:home page. What I did was change the function that would launch a Google search based on what was entered in the textfield from dynamic (so whatever the user entered) to a static value.
I currently have it set to always query “Seneca College” rather than whatever the user enters.
Let’s see. How about we try searching for Firefox…..
Hey wait a minute……
That’s all for tonight folks. My CPU is complaining about being taxed so much for the last 3 hours so it’s time to give it a break.
So I’m finally trying to get my build of firefox up and running “properly” defined by our classes standards (found here). In my previous post I was successfully able to get a build going of Firefox following the Mozilla Developer Network (MDN) for a “Simple” build. And it was exactly that, very very simple. The only problem was that I didn’t use the source code from our github repo at all so really I kind of defeated the whole purpose here.
So tonight after remember I had to try and accomplish this before class tomorrow (hey, I’m busy with other classes too you know!) I woke my macbook and opened my terminal to try and figure this out.
.mozconfig and other Environment Setup
First I realized that there was a few additional things that I needed to get done in order to properly use make to build a debug version of firefox on my laptop. First and foremost, I recommend that if you use Mac OSX that you view this link here and if you don’t just select your OS from the list here.
Obviously don’t bother with the Mercurial setup instructions as we are opting for github instead (although it actually isn’t too different) but the rest are important, specifically about the options you need in you’re created .mozconfig file. If I am reading them correctly they basically are telling the compiler to change the directory that it leaves everything in to ff-dbg (far simpler to remember than their default system), make flags (what they actually do is another story), enable debug and disable any optimization done in the make process.
From here I simply ran the provided make -f client.mk build and lines starting spewing out everywhere in my terminal. Way too fast to really read it all but a lot of it is preventative measures checking if X file is present or not, what version of GNU compilers are being used etc.
So here I am coming back a few minutes later thinking everything was good to go! Oh how wrong I was. I came back to these errors:
make: *** [mozalloc.o] Error 1
make: *** [libs] Error 2
make: *** [libs_tier_base] Error 2
make: *** [tier_base] Error 2
make: *** [default] Error 2
make: *** [realbuild] Error 2
make: *** [build] Error 2
Wait what? What does any of that even mean? *sadface*
I’ve been looking around at the various MDN articles but so far have not been able to find out how to fix my problem. Unfortunately even my fellow students couldn’t figure out what was going on as it all seemed to work for them when they followed the same or similar instructions.
Oh well. I’ll try to figure this out later I think. Maybe we will go over it in class tomorrow.
Edit: This is all of the output from my make, although the level of sense still low. Terminal Output
Today’s class in open source development was an interesting one. Basically in addition to the other open source projects we are working on during the semester we will be attempting to fix a bug (or was it add a feature?) along with our professor David Humphrey. The bug in particular is located here and is about implementing the Mouse Lock API into Firefox.
This feature will basically allow a user freedom of movement with their mouse. If their cursor hits the sides of whatever window they are using it will allow them to continue scrolling in the desired direction rather than forcing the user to pick up their mouse, move it in the opposite direction you were, set it down and then continue moving it in the original direction to scroll further. An example can be seen here with it’s current implementation in Flash. The w3c specs that we will be following for the Mouse Lock API can be found here.
We also had Mike Shaver in today, a former VP at Mozilla. He helped us get an idea of the kinds of things we should keep in mind while developing for big projects like Firefox. When it comes to code review we need to realize that the people who do the reviews (experts) are often very busy so it can make turn around time a week or more. There are different kinds of flags as well when it comes to reviews that will allow us to notify what we are looking for in regards to response on the bug. Making progress doesn’t come from simply adding more or changing existing code but can be simply finding information about existing code through different APIs.
Firefox in itself is one massive and complicated project. It involves multiple programming languages controlling different layers of the program and has dynamically generated code and tools, making it impossible for any one person to even consider understanding it all them self. This is why ambient learning is an important concept as it allows you to focus yourself on a particular subject or area of the code and become and expert on it allowing yourself to be of aid whenever someone else needs to use or understand your code. Until then, you’re going to have to ask for help! This can be done in many different ways including but not limited to: getting an example, using mailing lists, looking at blame logs for people who worked on the issue and information in a bug tracking service such as Bugzilla.
There are also some interesting sites that can help out the aspiring Mozilla developer by helping them learn about existing code.
- https://mxr.mozilla.org/ Allows you to search through the different branches of code and looks for instances of essentially anything. For example, if you wanted to know the common uses for some method called…. lets say testSomethingHere(), you could search for that specific string across multiple files in a branch of the Mozilla repo all at once.
- https://tbpl.mozilla.org/ Allows you to have a quick view of the different built in test opts.
Phew, a lot to take in all at once. For now, as emphasized, we need to take it all in small steps. It starts my simply getting the latest code from mozilla central which for use will be done through a github repo of our professor found here. I’ve cloned this and have it on my machine at home and all setup and needless to say, there is A LOT of code there. The next step is to make our own build of Firefox! I completed this using the steps I found here but I have the slight feeling I didn’t necessarily complete the task as intended. I’m sure I will find that out later after seeing some more blog posts over the week from my fellow classmates 😛
For now, that is all. Time to get some sleep for the rest of the week!
Good luck hacking everyone!