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.

1 comment:

Anonymous said...

I think Will has that book.