Thursday, May 31, 2007

Micro Merging

At first I thought to keep my code under both Mercurial, for MQ, and Monotone(MTN), because Pidgin is kept under MTN. But after a bit of work, I've found that it's really annoying. So, as much as I like MQ and think it's a fantastic idea, maintaining code under two DVCS's is too much work for what I want to get out of it. I won't be able to use patch queues until I either get Pidgin to convert to a DVCS that uses patch queues, or when MTN gets them incorporated.

So I am having to find alternate means of doing some of the things I could do with patch queues. So yesterday when I was working on incorporating the ability for Finch to reassign keys, I found that it required additional functionality before this could work. So I had a problem. I couldn't just make those changes then, because they would be incorporated into the same patch of adding reassignment capability, because that would create a messy/non-discrete patch. I also couldn't revert my code back to the previous revision, because that would lose all the changes I had already made. So I was caught. After a bit of thinking it became clear that the solution was simple, due to the power provided by the decentralized nature of MTN. The answer was a micro branch.

I won't bother going into too much detail because MTN micro branching is described well on the wiki. So I had my original revision (OR) that existed before I started any of my work, and I had a new revision that I was working on, we'll call it the reassign revision (RR). But I found that I had to write some code to temporarily ignore keystrokes at the window manager level and had to write code to do that before my RR could work. So I had to write an ignore keys revision (IR). So as it stood my DAG looked like this.

 ... OR --> RR

But for my RR to work properly I had to put in a revision between OR and RR. That's not possible due to the nature of VCS's. So I decided to apply the changes to start IR with OR as its parent. Thus my graph would look like this now.

... OR

Now IR doesn't happen after RR, which was the primary goal of this exercise. So all I have to do is make sure both IR and RR work well on their own and I can merge the branches when I'm done creating a new revision of both the changes called ignore keys and reassign revision (IRR), creating a DAG that looks like this.

/ \
... OR IRR
\ /

This same idea can be used quite nicely for bug fixes. The process is called daggy fixing. I find this method to be very nice and provides for a cleaner and more readable graph.

Friday, May 25, 2007

Patch Queues

The idea of Version Control Systems is awesome. A Decentralized Version Control System is an even greater idea for a distributed working environment such as the, and most, project I'm working on now.

Also a great idea is the idea of diff patches. To be able to take an original file and compare it to a modified version and get a representation of the changes is great for programming. Taking this idea a step further you get patch queues.

The idea of a patch queue is rather simple. Before you start working, you initialize a queue that will store a series of patches to be applied to a file or group of files. You then create a patch. Then you proceed as normal and work. At any point you can update the patch to reflect the changes that have been made since the start of the patch. So far so good right? Now comes the awesome part. After having updated a patch to reflect the changes, you can then start a new patch and push it on top of the first patch. This patch will reflect a series of other changes. After having updated this patch you can now do one of the following. You can either push a new patch on the queue or you can pop the new patch off the queue to modify the first patch. When you are satisfied with the changes you've made to the first patch you can then push the second patch back on top and continue working on it! Genius, pure genius!

A good friend of mine, you know who you are buddy, brought this concept to my attention minutes after I was accepted into GSoC saying, "You are going to need this.". I hadn't bothered to make it much available because one of the Pidgin developers told me that the project was too simple and we didn't need that kind of functionality. Well, after a bit of work I found that I didn't agree. It wasn't two days after I had started working on my first set of changes that I was looking for the ability to push multiple patches onto a queue as I worked. It's not that my work was very complicated, in fact the bit of work I was doing was only like 10 lines of new code. It was that midway in my work I wanted to go make a small change to a function somewhere else and I didn't want to confuse my current changeset. By being able to push a new patch, make those changes, and then come back to the first patch, it would have made it simple.

Now if this idea of patches queues doesn't blow you out of the water, how about I tell you that Mercurial has built into their system the ability to tie in both patch queues and a DVCS? Think of it, for as long as VCS's go back, once you commit a change, they are there forever, you can't take them back. Some allow you to disapprove changes, but this can get rather dicey. With the idea of patch queues into a DVCS, patches are treated as changesets. The only difference is that you can move up and down the graph with the use of a patch queue and modify a changeset after it was "committed". Mercurial has called them Mercurial Queues (MQ). I know rather little about project development, but I can see the beauty of this system. I encourage others to use it and lavish in its power.

Tuesday, May 22, 2007

Finally Some Code

Well after a lot of code reading and discussions in IRC I think I've gotten to a decent understanding of how Finch works and can start to code now. So before I get going on stuff I wanted to do something that wasn't too intensive but could get my feet wet. So I decided to scratch an itch and work around how Alt- doesn't send a meta for some terminals.

A little explanation is due here. When you type Alt-c two outcomes can result. If alt sends a meta character it sends an escape sequence. If it doesn't it sends something rather difference, but reversible. As an ESC sequence it sends {'\033', 'c', 0}. Then when it doesn't send an ESC sequence it sends {-'c', 0}. These are series of characters, so '\033' is the octal 33 ASCII character, decimal 27, ESC and 0 is the null character denoting the end of string in C. So the code to check and convert is as follows.

if(*k < 0){
    *(k + 1) = 128 - *k;
    *k = 27;
    *(k + 2) = 0;

The variable k is the sequence of characters sent from the terminal and rd is the number of characters received. I put this code very near to the beginning of key_pressed processing so that the rest of the code can still work based on the values being sent as escape sequences.

Then came time to commit this code to the repository. I've worked with decentralized version control systems(DVCS) before. Well, I've only used Mercurial, but it rocks. One quick note about it and I'll return to it later in another post. But I really like how Mercurial builds the concept of patch queues into it's client. An idea not born in Mercurial, but very powerful. More on that later. The basic idea of a DVCS is that instead of working with a central repository and committing to it all the time. You pull the entire codebase and revision DAG to your local machine and this becomes your working copy. From there you can work, commit locally and do all that a regular VCS does. But when you decide to, you can push your changes upstream and they are merged in with the central repository. Or, if you don't have commit privileges, you can notify a developer who does and they can verify your work and pull your changes upstream. The beauty about this is that a revision DAG can have many heads now and they can be merged in whenever you want.

So I had done my work locally and has committed them and was now ready to push my changes upstream. I have commit privileges to my very own branch, isn't that just nice! So I ran my push command and in a few short moments, they were up.

Then some fun came along shortly there after. A developer let me know of a few things I had done that weren't, the best lets say. For starters I had left some debugging code behind that I might have used later. I figured it wasn't a big deal because this was my own branch and I'd clean it up later when it would be merged back into the main branch, but I can see his point. If I make this into a habit of leaving stuff behind, when it comes time to merge back into central, I won't be able to remember all the stuff I have behind. So keep it clean to save work later.

Secondly, Pidgin develops under the C89 standard. I had put in a few comments that were C99. I was completely clueless as to what that was supposed to mean. So I did a bit of research and talked to a few guys in IRC and learned that C had a standard developed in 1989, called the C89 standard. Then in 1999, they created the C99 standard. To be fully compatible with new and old compilers we are implementing the C89 standard. So // comments aren't allowed. There are a few other things too. For instance you have to declare all your variables at the top of the method or namespace. You can't declare them wherever like in Java. I think this is a good practice in general and have always done that, so this isn't a big issue for me. In any case, I've ordered the famous K&R book that teaches C89.

So when all that was fixed I had committed my first bit of code. It was a nice feeling. Now I'm working on some more and hope to have it committed today.

Tuesday, May 15, 2007

...more tools...

Tools, tools and more tools...I've been hacking around Finch code all morning trying to understand key bindings. It's slow going, but I'm getting there. Though I haven't learned much to talk about in regards to Finch and its library libgnt, I have learned a lot of useful things that I will continue to use and encourage others to use.

GLib is a powerful library that I wish I had learned a long time ago. For documentation on the functions it has available check this site out. For years I've been writing code and using functions like the ones available here, but I always wrote my own. What a relief to find a library that has all this in it.

My favorite so far is the logging features it has. By calling g_log(), g_print(), or a few others that have different logging levels, it can log all sorts of stuff for you. The cool part is that you can define a method to handle the printing. If you call g_log with different logging levels it will alter where it prints, either to stdout or stderr.

It has many string utility functions. Many are in string.h, but a bunch aren't and I've had to write a few of them in the past. It's nice to have them all here.

It's very easy to use. All you have to do is include glib.h and when you compile you pass it pkg-config. So, "gcc `pkg-config --cflags --libs glib2.0` test.c test" and it works.

So this has been very useful, for future use and because Pidgin is filled with glib use.

Another useful thing I've learned is the use of ctags. Now I've used ctags a few times before. But with the help of my mentor and a few docs I stepped it up a bit. For those of who aren't too familiar with ctags here's a short run through getting things setup.

  1. Run "ctags -R" at the top of your source tree
  2. Open my favorite text editor, Vim, at the root of your source

That's it for getting setup. Now you have the capability to bounce from function call to function with a simple keystroke. Put your cursor over a function call and type CTRL-]. It will take you to the definition of the function. You can do this with variable and custom data types also. Vim stores the jumps you've made in a stack. To pop the last jump off the stack and return to where you were looking type CTRL-t. And voila, you've come back. This has made browsing code , and following it more importantly, a breeze.

The last thing I'd like to mention today is syntax highlighting. I've heard some complain about editors that apply syntax highlighting and say that it makes it more confusing for them to read and understand the code. Well, more power to them for not using this feature. I like it, I find it useful for reading code and I shall continue to love using it. But what I found today was a site that has a list of custom color schemes for a few languages. I'll focus on the link to the C schemes. I looked at a bunch of them, I found that I like the asmanian2 theme. Though, I don't like how it bolds a lot of things. So I'm still working on getting the bold out. :help colorscheme and :help hightlight-args has been a good help in modifying the theme.

Friday, May 11, 2007

Getting Ready

Well now that I've moved in. I've started to get going with my project. I've outlined a few things I want to get done before I can really start programming.

  • Scheduled Milestones
  • Understand Pidgin
  • Details of Implementation
  • Discuss details with Other Developers
  • Detailed Goals
  • Final Approval of Plans
  • Go
Scheduled Milestones

I went ahead and scoped out my deliverables and decided how long I think it should take me to accomplish each of them. Then I scheduled them into my summer. By clicking on the link to my Google calendar you can see what I've got there so far. It's very simple for now, but as I continue working I will add more details to it as I go.

Understand Pidgin

This is going to be a tough undertaking. Pidgin is a reasonably large application. I found a link to a diagram that outlines how Pidgin works. One of my current problems is knowing when to build something as a plugin and when not to. When I spoke with the other developers in IRC, they weren't able to give me a defined line that defined the difference between a plugin and non-plugin feature. I guess I'll have to learn that as I go, or it will become a feature by feature decision, which seems to be the most likely answer at this point.

On the other hand, I was able to get a better picture of how things work as I we spoke yesterday. The idea seems somewhat simple when you think about it for a while. The core manages all the internals that don't require external libraries. The core is made up of pure C functions. It connects to a group of prplInfo structs that give it the ability to communicate over multiple protocols. It is connected to a user interface(UI). Pidgin is a UI that uses GTK+ and Finch uses libgnt. Both the core and the UI can be added to by the use of plugins.

So now I think I have a decent understanding of the general system. I need to get working on understanding the inner workings of its components.

Details of Implementation

Once I have a good understanding of Pidgin, I will begin working on planning out the details of how I will implement my goals for Finch.

Discuss Details with Other Developers

Then after I've planned out the details of how I plan to achieve my goals, I'll discuss it with my mentor and the other developers. From here I hope to iron out things that wouldn't work, or find better ways of reaching my milestones.

Detailed Goals

Once all that is planned and ready to go. I'll break down my implementation into discrete goals. I'll take those goals and put them into my calendar. This will allow me to focus on small goals at a time. Furthermore, it will give me the ability to gauge how I'm doing, if I'm on schedule or running behind.

Final Approval of Plans

Just before I actually start working on things, I'll get a final approval of my plans and how I've laid out my timeline.


With all things ready, I shall set out to change the least the world as it related to Finch.

Wednesday, May 9, 2007

Moved In

office, desk, computerWell I've made the move from Tennessee to New Hampshire where I'll be for the rest of the summer. I had to rearrange a storage room, but in the end it's become quite the little office I've created for myself. On the left here you can see what it looks like just outside the entrance. The house itself is very old, built back in 1836. The room itself is located on the other side of the garage.

office, desk, computer, programmerNext is my workstation. It's still not fully setup, I want to get some of the junk out of the way and put something more useful there. I'm thinking of either putting some useful books I'll be needing or maybe stocking up those shelves with some good junk food. Right now, I've only got some Cheez-It's and some Ramen. I've had my Logitech 5.1 sound system for a few years now and it's dying. My left channel is hurting, the front only comes in sometimes and the back is also somewhat shaky.

Here's a little walk-through of the place.

Tuesday, May 1, 2007

All Set

I have one final left, but it's not much to worry about at this point. So I've been working on getting all my paperwork setup for CPT and taxes. All that is done now, projects are in, I've got my stuff packed. I leave for NH in a few days. So today I relax cause it's my birthday so I'll be hanging with friends tonight.

So this is how I plan to set things up this summer. I am going to be staying in NH with a friend. But, since I'll only be there for the summer and he doesn't have Internet, I will be working at my ex-girlfriends place. Without going into too much details, she is also the mother of my daughter, so I'll be taking this opportunity to spend as much time with her, my daughter Hannah, as I can this summer. She's 5 months old, my daughter, on Friday.

So they have an extra room on the other side of their garage where I can set up my desk and run a network cable to and use their DSL. It should be cool, my own little office to work on Finch. I'll also set it up to be able to remote into my box from the outside. Since they aren't serving anything from their network, I'll be able to use standard ports again. That'll be awesome. I've been in a dorm this year where they limit outgoing ports to 90-99. So SSH has been 95 and HTTP has been 96, really annoying when trying to relay the link to my gallery. They always forget the ":96". So anyhow, I'll have my own little office, should be fun.

I am also thinking of using this summer and the free schedule it allows me to have to do polyphasic sleep cycles. More on this when I get going on that. But it should prove to be an interesting experiment.