Lazy Malloc()

Maintaining a Patch Series with Mercurial Queues

2010-10-09T21:38:00.008-04:00

This topic has been written about quite a bit (there are links to some additional resources at the end of the article), but I'm going to describe how I handle patches using Mercurial Queues. Some existing articles are either out of date or describe a different workflow.

I normally use Mercurial Queues to maintain patches on top of source trees for applications that I need to modify before compiling for use for whatever reason (compiler fixes, system tweaks, non-mainstream features, etc). Although Mercurial Queues can be used to manage thousands of patches, the number of patches I work with is usually less than ten in this situation, so this work flow is optimized for a smaller number of patches. It also requires the rebase extension (bundled with "modern" versions of Mercurial) to be enabled, as well as Mercurial Queues itself.

Initial Setup
We're going to assume that the official application source is not contained in a Mercurial repository. If it is, you can just clone that and skip the steps in this section. The commands below are based on the workflow I use, just to convey the general idea of what to do.
First, grab the latest version of the application you need to modify, and extract it into a directory. In this case I'll be modifying some_application, because I have no imagination. Since this will be the repository in which you'll be making your changes, you may want to remove the version from the folder name, if present.


cd custom_builds
tar xvf some_application-version.tar.bz2
mv some_application-version some_application
cd some_application

Create a Mercurial repository here.


hg init

Custom Changes
Now you can make your changes, adding as many patches as necessary. Please see the MQ official documentation for more information on these commands,


hg qnew [patch name] # create a new patch
hg qrefresh          # refresh the current patch
hg qrecord           # refresh the current patch (at the patch hunk level)
hg qdelete           # remove the current patch
hg qpush             # push the next patch onto the stack
hg qpop              # pop the current patch off of the stack
hg qseries           # list all of the patches in the series
hg qapplied          # list all of the patches that are currently applied

After your changes are set up to your liking, you can compile and enjoy the application.
Please note that there are many more Mercurial Queues commands; to get a full listing you can type hg help mq.

Handling Updates to the Core Source Code
Say it's been a few months and there have been a few significant changes to some_application, and a new version is out. The kind of changes you would like to be able to use.

Clone your existing repository (without the patches) to create an area in which to apply the core updates.


hg clone some_application some_application-new_version

Extract the source code for the new version over the files in your cloned repository, and update it.


tar xvf some_application-new_version
cd some_application-new_version
hg addremove # tell Mercurial to add new files and remove ones that were deleted
hg commit -m 'Updated to new version.'

Now you can go back to your main repository, and pull in the updated changes from the clone. Thanks to the rebase extension, the pull command can be used to update the changes to the core code, then merge in your managed patches on top using the regular merge tools.


hg qpush -a # apply all of your patches
hg pull --rebase ../some_application-new_version
...do any manual merging necessary...

After this process is complete your patches will apply cleanly onto the updated source tree. You can delete the some_application-new_version folder if you wish, or keep it around for archival purposes.

This process makes maintaining a series of patches relatively painless in terms of merging and keeping the code up to date. Based on the experiences of others, similar processes scale well, so I assume this one does as well.

For more information and additional work flows, check out the links below:
Mercurial Definitive Guide - Managing Change with Mercurial Queues (a little outdated, but useful).
Mozilla's MQ Notes
David Herron's Introduction to MQ
Git User's Guide to Mercurial Queues
Random Notes on Mercurial Queues

Emacs - Clear Current Buffer

2010-10-01T20:23:00.004-04:00

There are a few cases where clearing the current buffer is useful. For example,when using the *scratch* buffer a lot, or running a shell inside Emacs, being able to clear the screen can help the user stay organized. Since I'm often stuck in a Windows environment without Cygwin, running a shell inside Emacs is a great boost to productivity.

I recently found a method that works great. I'm sure there other, (possibly more elegant) solutions, but this gets the job done.

There are two functions to define for this solution; the best place for them is probably your .emacs file.

The first function, beginning-of-buffer(), from rattlesnake.com simply moves the point to the beginning of the buffer, leaving the mark wherever it happens to currently be.


(defun beginning-of-buffer()
 "Move point to the beginning of the buffer."
 (interactive)
 (push-mark)
 (goto-char (point-min))

The second function, clear-buffer(), from Audacity Init-Nyquist, deletes everything in the buffer and moves the point to the beginning of the buffer.


(defun clear-buffer()
 "Kill all of the text in the current buffer."
 (interactive)
 (clipboard-kill-region 1 (point-max))
 (beginning-of-buffer)

It is of course possible to combine these two functions together if there is no reason to re-use beginning-of-buffer(). Once this is in your .emacs file, or has been run in Emacs, you can type M-x clear-buffer to clear the current buffer. It can also be mapped to a key combination like any other function.

Mercurial Relink Extension and hg-relink.py

2009-12-12T11:04:00.012-05:00

In newer versions of Mercurial (greater than 1.3.1), a great extension called relink comes bundled with the system. For larger projects, this can significantly reduce the amount of disk space consumed when you have a large number of cloned repositories.

When a repository is locally cloned, Mercurial will create hardlinks to the original repository's files in order to save space, if the operating system and file system support hardlinking. However, when a pull is done into either repository (the original or the cloned), those hardlinks are broken, regardless of whether the files are still identical. The relink extension allows Mercurial to re-create those hardlinks. For those of you stuck with 1.3.1 or a prior version, see the last section of this post for the solution used before this extension.

Since the relink extension is bundled with Mercurial, to activate it, just add the standard lines to your .hgrc.

[extensions]
.
.
.
relink =

Using the extension is very straightforward. Execute one of the following commands from somewhere within the cloned repository's directory structure.

# Re-link with the stored origin (the original repository this was cloned from.)
hg relink

# Relink with a specific ORIGIN repository.
hg relink /path/to/origin

Mercurial will print out which repositories were relinked and how many files were pruned. See the official extension page, or type hg help relink in a terminal for more information on usage and output.

For users of version 1.3.1 and prior:
There is a python script (contrib/hg-relink.py, or sometimes contrib/relink.py) in the source tree that provides this same functionality, and can be used with versions 1.3.1 and prior. I used it myself until I found out about the relink extension.

The usage is just as easy as the extension, but requires some extra setup. First, copy the hg-relink.py (or relink.py) file to a directory in your PATH. You can then call it as shown below:

python hg-relink.py /path/to/source /path/to/destination

The script will then hardlink the appropriate files from the source repository to the destination repository. There used to be a page on the Mercurial wiki describing this script in more detail, but it seems to have disappeared.

Changing the Terminal Titlebar Text for Each Application

2009-12-07T19:26:00.017-05:00

I have been using the awesome window manager, and it has been, well, awesome. I have also tried ratpoison, xmonad, and ion but awesome is my current favorite. Anyway, as you may have gathered from the title, window managers are not the topic of this post.

I have found myself using more terminal applications because it is easy to manage them with a tiling window manager, and I am a fan of minimizing mouse use when doing text-related tasks. However, when there are several terminal windows open, it would be nice to see what is currently running in each one, instead of having to cycle through all of the windows. I imagine that this is the case with all window managers, and it has just become more obvious with my current setup.

This technique is based on a tip found here, which is for displaying the hostname in the titlebar of an xterm window. I use rxvt-unicode as my terminal, but this technique should work with any xterm compatible terminal emulator running a bash terminal. The following is an example of the section in my .bashrc.

if [ "$TERM" = "rxvt-unicode" ] && [ "$0" = "-bash" ]
then
   # Escape sequence for setting xterm title
   label () { echo -ne "\e]0;$*\a"; }

   # Titles for each application
   alias s1='label urxvt - ${PWD#$HOME/}'
   alias s2='label urxvt - vim $*'
   alias s3='label urxvt - top $*'

   # Commands for each application
   cd_t () { "cd" $*; eval s1; }
   vims_t () { eval s2; "vim" $*; eval s1;}
   top_t () { eval s3; "top" $*; eval s1;} 

   # Assign the aliases
   alias cd=cd_t
   alias vim=vim_t
   alias top=top_t

   # Set title to home directory
   eval s1
fi

Let's take a look and (hopefully) shed some light on what is going on here.

The first line is checking for the name of the terminal. Replace this with whatever terminal you are using (e.g. xterm, aterm, rxvt, etc) so that the configuration will take effect.

The next section defines a function named label that will change the title of the terminal window.

label () { echo -ne "\e]0;$*\a"; }

Next, we set up some aliases to rename the window depending on the application. The $* after each application represents the list of arguments it was called with. For example, the command vim bob.txt would name the window vim bob.txt. Shocking, no? Here we define three aliases; the first sets the window title to the name of the home directory, the second to "vim", and the third to "top", all with the accompanying arguments.

alias s1='label urxvt - ${PWD#$HOME/}'
alias s2='label urxvt - vim $*'
alias s3='label urxvt - man $*'

Now we need some functions to actually change the titles. These are defined in the next section, one for each application. One downside of this technique is that your .bashrc will become long and messy if you need to do this for many applications. The applications have been named with the scheme [application name]_t. Each function does the following:

Changes the title for the current application

Runs the application

Resets the title to the current directory after the application closes

cd_t () { "cd" $*; eval s1; }
vim_t () { eval s2; "vim" $*; eval s1;}
top_t () { eval s3; "top" $*; eval s1;}

The final section assigns aliases for the commands actually used to the functions defined in the previous section. This allows the title window text to be changed transparently in the background. For example, when "vim" is typed, the "vim_t" function will be called.

alias cd=cd_t
alias vim=vim_t
alias top=top_t

The last line of the configuration section simply sets the title to the home directory after the terminal window is opened.

This setup has made identifying windows more convenient for me, and I imagine it would with any window manager, not just the tiling variety. Remember that this should work for any terminal application. Enjoy!

Creating Unrelated Branches in Mercurial

2009-03-21T17:47:00.011-04:00

Earlier I watched Scott Chacon's excellent GitCast about using "Empty Branches", or branches that are not derivations of your main development flow. In other words, they are not descendants of your first revision. Obviously his tutorial was about how this is done in Git, but it is possible in Mercurial as well.

It's important to remember that while Git ignores commits that it cannot reach via a branch head or tag, Mercurial follows all commits. Therefore some of the steps described below are not necessary if you wish to refer to a branch head anonymously. Another caveat is that when I refer to a branch, I mean a fork in the revision history graph (you can automatically track these with bookmarks, similar to Git's branches), not what Mercurial sees as a named branch.

Starting an Unrelated Empty Branch

First let's bookmark the tip revision for easier reference later:


$ hg bookmark -r tip MainBranch

Make sure your working directory is clean, with no changes. If there are changes, either revert or commit them.


$ hg status
M test.txt
$ hg revert --all

Now set the parents of the current directory to null to start the root of a new tree.


$ debugsetparents null

Update: Some readers have pointed out that there is a much cleaner (and potentially safer) way to set the parents to null.

$ hg update -C null

Go ahead and add some files and make your first commit.


$ echo "test file" >> f1.txt
$ echo "test file" >> f2.txt
$ hg addremove
adding f1.txt
adding f2.txt
$ hg ci -m "A new separate branch."

Let's bookmark this head so it's easier to review separately from the main development tree.


$ hg bookmark NewBranch

That's it! You can now switch between these unrelated branches using hg update -C. Remember that the bookmarks are simply for convenience, you can always refer to the heads anonymously if you would like. These separate branches have several uses. Scott Chacon mentions creating one for documentation, or for the website for the project. While these branches are part of the project, they are unrelated to the main code base. You could also use these branches to store an alternate version of the project that doesn't share much of the same code.

Using Unrelated Branches

Here are a few usage examples.


# Check out the main project tree
$ hg update -C MainBranch
# Check out the alternate tree
$ hg update -C NewBranch
# View only the history for the main tree
$ hg view MainBranch
# View only the history for the alternative tree
$ hg view NewBranch

Enjoy!

Mercurial vs Git: Tags

2009-03-18T22:42:00.021-04:00

The implementation of tags is one design idea that is fundamentally different between Mercurial and Git. In this post I aim to summarize how each system handles tagging revisions, and hopefully enlighten the reader.

Mercurial
Both systems have two types of tags, long-lived tags that are meant to mark significant points in project history, and local or lightweight tags for temporarily marking revisions.

Mercurial brands the two types as public tags and local tags. Public tags are stored in a text file called .hgtags that lives in the root directory of the repository and is versioned along with the rest of the files.

However, the latest committed version is always used, regardless of the changeset currently checked out. This means that any tag can be referenced at any time, even between named branches.

The idea is that changes to tags should be tracked over time, so that we can look back and see when a tag changed, and who made the change. A custom commit message can be added to the changeset adding the tag, allowing for annotated tags. Mercurial also allows GPG signing of changesets with the GPG Extension.
The disadvantage of this is that all of the tags must be shared among clones of the repository. There are some workarounds, as described below. In addition, there are a few caveats with the .hgtags file:

Each named branch in Mercurial has a separate set of tags.
Occasionally the .hgtags file introduces merge conflicts.

Example Usage


hg tag -r 78hfvea v1.08

The other type of tagging Mercurial supports involves local tags. These are stored in a plain text file called .hg/localtags. These tags are, as the name implies, local to the repository in which they were created and are not propagated during a push, pull or a clone. These types of tags are ideal for temporary markers for finding bugs, or simply tags that you do not wish to share.

Example Usage


hg tag -l -r 78hfvea "Bug51 sighted"

However, if you wish to propogate these tags to certain repositories, you can always add a hook for a push event (or just do it manually) to trigger scp or rsync to copy the .hg/localtags file.

Git
Git brands its two types of tags as normal tags and lightweight tags. Normal tags are actual objects in Git (like commits, trees, and blobs), and can be annotated and GPG signed. Unlike Mercurial, Git treats all tags completely independent of history and manages them outside of the file tree.

Example Usage


# create an unsigned annotated tag
git tag -a v1.01 78h2gv

Git's lightweight tags are similar to Mercurial's local tags. They exist as text files in .git/refs/tags and are not annotated. However, unlike Mercurial's local tags, these are separate objects and can be shared between repositories.

Example Usage


git tag PossibleBug 78h2gv

Summary
Both systems have capable tagging capabilities that work well with most workflows. Mercurial's global tags are version controlled, which can be advantageous if your project workflow involves lots of tag changes. The local tags provide an alternative for throw-away tags that are not part of project history, at the expense of not being able to directly share them between repositories.

Git's tag objects have the advantage that they can be annotated directly in the tag, which is advantageous if you often need to store longer comments about particular revisions. In addition, both normal and lightweight tags can be selectively shared between repositories (via push/pull/etc). This feature adds some flexibility, allowing someone to publish only the tags that make sense for a public repository.

For more information concerning how each system handles tags, check the manual for the respective system: Mercurial, Git.

Uses of Mercurial's "bookmarks" Extension

2009-03-02T20:35:00.009-05:00

The bookmarks extension that is now bundled with Mercurial makes it easy to keep track of multiple heads in a repository, similar to Git's "lightweight" branches.

While Mercurial has always supported lightweight branches via multiple repository heads, they are somewhat difficult to keep track of because they are unnamed. Moving tags manually (or via a script) to keep track of each head becomes unwieldy, as does tracking by the last commit message. In Git, unnamed repository heads simply become inaccessible if they are not tagged. A branch in Git is basically a pointer to the head of a fork in the tree.

Similar to Git's branches, bookmarks are markers that move forward with each commit automatically, allowing you to track different lines of work in one repository. This feature is perfect for small experimental features or bugfixes that will either later be thrown away or merged into the main line of development.

NOTE: To take advantage of having a "current" bookmark, make sure you have the latest version of the extension, available here.
You will also need to add the following section to your .hgrc or Mercurial.ini.


...
[extensions]
hgext.bookmarks =
...

[bookmarks]
track.current = True

Here are a few example uses of bookmarks to consider:

Let's say you're working on a relatively small project and only have two clones, one for main development and a "stable" clone. You decide to start work on a new feature based off of version 1.0 of your project. Fortunately, thanks to your crazy awesome software development skills, you tagged v1.0 after it's release.


...create a bookmark for your new feature
hg bookmark -r v1.0 awesome_feature
...check out the code and set as the current bookmark
hg update -C awesome_feature

Those who are familiar with Git's branches will see the similarity. The current bookmark is set in .hg/bookmarks.current. Now you start on your feature.


...some good work going on
hg commit -m "A good feature."

You will notice that the bookmark moves along with your commit. With the extension set to track the "current" bookmark, only the one currently set will move forward. This means that you can set two bookmarks to the same revision, and as long as you update appropriately only one will move forward. This is different from how the bookmarks extension operates by default, which entails all bookmarks moving forward when a commit is done on their parent.

Now you start another feature from the v1.0 revision and make some commits.


hg bookmark -r v1.0 even_cooler_feature
...set as current bookmark
hg update -C even_cooler_feature
...work
hg commit -m "some work."
...work
hg commit -m "some more work."

*** soda break ***


...work
hg commit -m "almost done."

Someone wants to help with one of your new features and clones the repository. Since they also want the bookmarks, they have to copy the .hg/bookmarks file over manually. This is important: bookmarks are not part of the repository (yet). They are not pushed/pulled or cloned. However, since they refer to the hash of the changeset ID, they can be used in any clone of the repository.

The anonymous helpful person does some work on the "awesome_feature", making a few commits and asks you to pull and review them. However, he has also made some commits to "even_cooler_feature" that are not ready yet, so you need to pull only the changes from the awesome_feature branch. This is a two step process, although it can be easily automated.


# update and set the current bookmark to awesome_feature so it is fowarded
hg update -C awesome_feature
# find the tip of the awesome_feature branch 
# (the location of the remote bookmark)
hg id -r awesome_feature http://some.remote.repo
74b4cb5hs4b2
# pull all of the ancestor changesets of that tip
hg pull -r 74b4cb5hs4b2 http://some.remote.repo

pulling from http://some.remote.repo
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 6 changes to 2 files
(run 'hg update' to get a working copy)

The awesome_feature bookmark will have moved to the tip of your now updated branch, and you can review to your heart's content. No unrelated changesets were pulled. You can also push bookmarks just as you can with any other revision identifier.

Now say you want to add an experimental feature that you may not keep.


hg bookmark -r v1.0 experiment
# locally tag the base of the branch so it can be deleted later if necessary
hg tag -l experiment_base
...some work
hg commit -m "here goes nothing."
...some more work.
hg commit -m "work."
...realization that this is a horrible idea

You can delete the bookmark and leave the head and changesets intact (which is what Git does), or remove the changesets with the strip command from Mercurial Queues.


# delete the reference to the tip
hg bookmark -d experiment
# now no one will ever know, muwahaha
hg strip experiment_base

There are many more things you can do with bookmarks, but this should get you started. This is a great extension and people who use both Git and Mercurial will enjoy having more flexibility with lightweight branches in Mercurial. I'm sure as the extension evolves we'll have more features to play with. I...err...of course mean "optimize our productivity". Have fun!

Organizing Commits with Mercurial Queues and Attic

2009-02-28T23:31:00.030-05:00

I've been using distributed version control for a few years. Although I've only collaborated with smaller groups of people, these tools have helped out immensely. However, I've only recently started using Mercurial to organize changes into logical commits. I use the Mercurial Queues and attic (or shelve) extensions. Note:

EDIT: A few people have mentioned that the workflow outline below is possible using only the attic extension. For the example outlined below, the attic extension would be adequate. However, using Mercurial Queues allows you to work on patches that depend on each other, which gives you quite a bit of flexibility, almost like a "queue" of patches ;).

If you're using Git, check out StGit and the stash command, or with Bazaar, the Loom and shelve commands for similar functionality. Similar workflows are also possible with the help of the Git Index.

My workflow has traditionally gone something like this:


...work on some parts of features...
hg commit -m "Added feature1, part of feature2..."
...some more random work...
hg commit

While my commits contain generally related items, the implementation of features is often spread out among commits. Below is an example of an alternative workflow resulting in more organized commits.

Say we're working on a multithreaded application, and have written the skeleton code for the worker thread function. Without committing, we began working on the code for the main thread.
We could always commit with the record extension or something similar, but there is a more natural way.

Store away the changes related to the main function interactively (similar to record) in a patch called main.p. It will be stored in .hg/attic.


hg shelve -i main.p

Initialize a Mercurial Queues repository:


hg qinit -c

Create a new patch to track the changes to the worker thread (use the -f flag to include local changes.) The patch will be stored as .hg/patches/workerthread.p


hg qnew -f workerthread.p

Refresh the patch, and create a new patch for the main thread.


hg qrefresh
hg qnew mainthread.p

Restore the changes we saved earlier, and delete the temporary patch from the attic directory.


hg unshelve --delete main.p

The working directory is now updated with those changes. Refresh the mainthread.p patch.


hg qrefresh

We can use the qapplied command at any time to look at the applied patches that Mercurial Queues is managing:


hg qapplied

mainthread.p
workerthread.p

We are now free to work on the patches separately, using qpush and qpop to switch to the patch we want to edit, then running qrefresh to save our changes. Mercurial will warn you when you try to switch patches without saving local changes. It's also possible to change the order that the patches are applied by editing the .hg/patches/series file. Just make sure that none of them are applied! When we feel that one of our patches is ready, we can turn it into a "real" commit using qfinish.

I highly recommend reviewing the Mercurial Queues documentation if you use Mercurial. It opens the door to workflows of which you may not have been aware. Organized commits are especially important when collaborating on projects that depend on patches. When each commit makes one logical change or a group of logically related changes, the process of tracking down the source of a bug is greatly simplified.

Audio with Flash Applications in Firefox (Linux)

2009-01-02T23:50:00.007-05:00

The title of this post may not be the best, but this issue does not apply to a particular distribution, or to all distributions. As far as I can tell, it just depends on your distribution and sound hardware. I had the issue with Slackware 12.2, but I had not encountered it in previous versions with the same hardware.

The problem is as follows: You have configured ALSA properly, adjusted using your favorite mixer, and sound works normally (tested by playing a sound file in amp/xmms/etc). However, sound from Flash based websites (using the Adobe Flash plugin) does not play in Firefox. This includes websites such as Youtube and Pandora. The most common fix I encountered was to install libflashsupport, which adds support for non-ALSA sound systems to the Adobe Flash Player. If you use Slackware, there is a Slackbuild file over at slackbuilds.org. Most other distributions should have an appropriate package.

I had some trouble finding the solution to this issue, so I hope this helps. Best of luck!

Working with Sets in Common LISP

2008-11-26T23:49:00.012-05:00

For a long time I was unaware that Common LISP has built in facilities for working with sets. I may have been looking in the wrong places (actually, I'm *sure* that was the case), but other people must have come across the same issue. I'll outline the most common LISP functions for dealing with sets below. Chapter 13 of Practical Common LISP has some more information for anyone who is interested.

The easiest way to represent a set in Common LISP is as a list. Shocking, I know. To add an item, use adjoin or pushnew. They both check to see if an item is already in the list before adding it to avoid duplicates. The difference between the two is that pushnew modifies the original list and adjoin does not. In addition, since the lists are treated as sets the order of the elements does not matter.


; Create a list of numbers
> (setq li '(1 2 3 4 5))
; Try to add another 2
> (adjoin 2 li)
(1 2 3 4 5)
; Try to add a 0
> (adjoin 0 li)
(0 1 2 3 4 5)

You can check whether an item is in a set with the member function, or it's companions member-if and member-if-not. Instead of returning just the item (what the find family of functions do), member returns a sublist containing the item and all subsequent items in the original list.


; Using our list from the previous example
> (member 2 li)
(2 3 4 5)
> (member 8 li)
nil

Common LISP also includes the basic set functions intersection, union, and set-difference.


; Create some sets
> (setq s1 '(1 2 3 4))
> (setq s2 '(3 4 5 6))
; Find the intersection
> (intersection s1 s2)
(3 4)
; Find the Union
> (union s1 s2)
(1 2 3 4 5 6)
; Find the Set Difference between s1 and s2
> (set-difference s1 s2)
(1 2)
; Find the Set Difference between s2 and s1
> (set-difference s2 s1)
(5 6)

Remember that all of these functions accept the optional :test parameter, and therefore can be used with any data type. There are more set related functions, however these are those that I found most useful and others may as well. Check out the full function documentation in the Common LISP Hyperspec or the chapter in Practical Common LISP mentioned above for more information. LISP time.

Always Initialize Your Pointers!

2008-10-30T23:08:00.006-04:00

I've recently been debugging quite a bit of C code that was written a while back. The original developers rarely initialized their pointers, maybe 30% of the time. I linked most of the memory leaks and crashes back to those pointers. Moral of the story: Always Initialize Your Pointers.

If you are not familiar with the difference between an uninitialized or bad pointer, and a null pointer, keep reading.

When a pointer is declared and not initialized, there is no telling where it points to. This is also sometimes referred to as a "bad pointer". When you try and deference it, the program will try and jump to the address of whatever random value happens to be in that spot in memory. Also, it is sometimes outside the range of memory locations allocated to your program, resulting in the classic segfault on UNIX's, or an illegal operation for the Windows folks. Keep in mind that this doesn't always happen, if the address is within your program memory, sometimes your program will just quietly self destruct internally and the error will show up later. Good times, good times.


int* somePointer; //This is an unitialized pointer.

//There is no telling what this will do.
printf("%d", somePointer)

//Uh-oh. This will definitely throw an error.
free(somePointer);

However, if you initialize a pointer when you declare it, this eliminates most of those problems, as it is now a "null" pointer. In C and C++, null pointers are easy to test for. Setting a pointer to null directly after freeing it is also considered good practice.

You may think that since you're assigning a value to the pointer three lines down in the function, it's not worth initializing when you declare it. What happens when you remove that line during refactoring or debugging and forget about it? Exactly.
Do yourself and your colleagues a favor. Initialize your pointers (either with null or a value) when they are declared, and set them to null after you free them.

A properly allocated and freed pointer:


int* somePointer = NULL; //Can also be 0
somePointer = (int*)(malloc(sizeof(int)));
.
.
some code...
.
.
free(somePointer);
somePointer = NULL;

Configuring OpenCV v1.1pre1 in Visual Studio 2005

2008-10-19T11:50:00.003-04:00

I'm currently using OpenCV for a project, and since a new version was released October 15th, I decided to update the libraries. It turns out a few tricks are needed to get the auxiliary libraries and sample applications to compile in debug mode (in Visual Studio 2005), as the source for JasPer (for reading JPG images) was not included, and there is no debug version of the library present. Below I've outlined the steps I took to make everything compile correctly. If you're using Visual Studio 2008, I imagine the steps below will still work with some minor tweaking.

1) Download OpenCV v1.1pre1.
2) Run the executable and install OpenCV. Go to the start menu item for
"OpenCV .NET Workspace 2005,2008" and open it. Building some of the
items requires libjasper, so we'll build that next.

3) Download JasPer (1.900.1)
4) Extract the files, and navigate to the ...\src\msvc directory. Open the
project and let Visual Studio convert it to the new format. Build the
debug version, it should compile with no issues.
5) Go to the debug output folder and rename libjasper.lib to libjasperd.lib
6) Copy libjasperd.lib to ...\OpenCV\otherlibs\_graphics\lib

7) Back in the main OpenCV solution, right click on the "highgui" project
and open the properties window. Under the "Linker" section, and the
"Ignore Specific Library" field, add "libcmtd.lib" to the list.
8) Build the "highgui" project.
9) The rest of the projects should now build with no problem.

NOTE: Some of the libraries are not compiled, so you may need to compile everything in the solution before any of the sample programs will work.

Good Luck!

Looping in Common Lisp

2008-10-12T15:46:00.012-04:00

I'm currently taking an Artificial Intelligence class, and had my first assignment to be done in Common Lisp. There have been many variations of Lisp over the years, and currently the two major dialects are Common Lisp and Scheme, both of which are commonly used for Artificial Intelligence related applications.
Since I was learning Common Lisp over the course of doing the project, I had a somewhat difficult time getting the syntax for loops correct. For those of you who support the "pure" functional programming paradigm (where side effects and loops are evil): I took the lazy approach of using a loop and some variables rather than figuring out how to do the recursion. Faster? Maybe. Overall better? Varies by opinion. Feel free to disagree.

Anyway, these are the most useful and "safe" ways I found to do loops without causing massive debugging headaches that cause you to want to switch to a lucrative career in ice cream sales.

loop: The simplest loop structure
The "loop" structure is as simple as you can get. It provides no built-in termination, you must provide that yourself with a conditional statement, and the "return" command. Here is a simple example:


(let ((n 5))
  (loop
   (print "Looping!")
   (- n 1)
  (if (< n 0) (return "Finished"))
)

do: General Counting Loop
The "do" loop is analogous to the "for" loop structure in many languages. You can specify several variables, rules for how they are to be updated each iteration, and a stopping condition. For me, it took a little while to get used to the syntax, but once you understand the structure, you have a great deal of flexibility at your fingertips. The general syntax is as follows:


(do (([var1] [var1 initial value] [var1 step])
     ([var2] [var2 initial value] [var2 step])
     .
     .
    )
    ([stopping-condition-test] [return value])
    ...commands....
)

A simple example that will loop 10 times, each time printing "Looping..." and
then will print "Finished":


(do ((i 0 (+1 i))
  ((= i 10) "Finished")
  (print "Looping...")
)

dotimes:
"dotimes" is a specialized form of the "do" loop, suited for situations where you know exactly how many times you need to iterate. It basically saves you from having to enter a stopping condition, by counting from 0 until the number you specify. Here is the syntax:


(dotimes ([variable] [final-value])
 ...commands...
)

An example:


(dotimes (i 10)
 (print i)
)

dolist:
"dolist" is another specialized form of "do", perfect for iterating through a list. You need to specify an iteration variable (holds the value of the current item in the list) and a list to iterate through. The basic form is as follows:


(dolist ([variable] [list])
  ...commands...
)

An example that squares each value of a list of numbers:


(dolist (item '(1 2 3 4 5))
  (print (* item item))
)

Note: In this situation you could also use the one of the "map" functions (mapcar or maplist) to apply a function to each successive item in a list (mapcar), or to successive cdr's of a list (maplist). These functions both return another list.

Now, go forth and Lisp.

A Review of Spore

2008-10-02T23:29:00.007-04:00

So...Spore. The game many of us have been anticipating for years. Many are disappointed at how it turned out, throwing out a lot of criticism; some of it deserved, some of it not. This will by no means be a full rebuttal to everything I've read, but I have addressed a few issues. I didn't even limit it to worthless pricks! It turns out that's only about 80% of the internet. I'm sure everyone can guess what groups make up the rest. Anyway, before I get started:

DISCLAIMER: Yes, the DRM included by EA is a horrible idea and probably reduced their sales to a fraction of what they could have been. However, I am not going to address that. If you want to see people complain about the DRM, read the comments of any article featured on Digg that even mentions Spore. Even some that don't. Seriously.

1) The game is watered down so much it is boring.
This is a pretty broad claim, and encompasses a lot of the other criticisms that I address below. In short, I will say that the game is watered down from it's original design and is not quite what everyone was expecting. However, this does not automatically make it a bad game, for reasons I discuss.

2) The game has very little depth, and is basically a simplified combination of five games.
If you have not played Spore yet, the game is divided into five "stages"; cell stage, creature stage, tribal stage, civilization stage, and the space stage. Your creature starts in the cell stage and "evolves" up through the space stage.

The cell stage is a lot of fun, simply because you just swim around, eat stuff, and kill other cells. It's a good, solid, two dimensional life. This is the shortest stage, after which at some point you seem to discover that there are three dimensions and grow some type of legs. Or not, it's your choice. Once on land, you are in the creature stage, during which you eat, make friends or hunt other creatures, and find random creature parts from skeletons that just happen to be lying around and sparkle at you. This stage is pretty underrated. You can have a lot of fun trying to locate all the creature parts to build awesome creatures.

I actually agree with the criticism of the tribal stage. It is very simplistic compared to what it could be. When dealing with another tribe, you can destroy them, or give them food until they like you enough to let you perform a musical selection for them. After you've conquered or befriended all the tribes, you move to the civilization stage.

I've read a lot of criticism that this stage is an extremely watered down version of the classic Civilization games. There are quite a few similarities, but I think this stage is just to segway your creatures' expansion into space, since it is almost a direct subset of the space stage. While it is pretty easy, I still enjoy it.
I've seen a few complaints that this stage should be more like an RTS (real time stragety game). Remember that Spore is not supposed to be five games. It's supposed to contain five stages of development. Making this stage an RTS would take away from the other stages.

The space stage is what Spore is all about. As you advance through the space stage, you obtain tools to accomplish quite a bit, including the manipulation of lesser species, and planet destruction. With the exception of the cell stage (which is just cool), my guess is that the other stages act as tutorials to help you hit the ground running when you obtain these tools. They are fun in themselves, but the space stage is where the real depth of the game lies. You ally, declare war, and trade with other empires, expand your empire and terraform planets.

The creature stage lets you experience modifying a species, and how various species interact. The tribal stage introduces diplomacy in the game, and the civilization stage ultimately teaches you how to manage your home planet and colonies.

3) The DRM is horrible. Why would EA do this?
Seriously, did you even read the introduction? Exactly, now keep reading.

4) It's difficult to accomplish anything in the space stage because you keep getting called back to your home planet or a colony every few minutes to solve an ecodisaster or an invasion. Also, there is only one spaceship in the whole empire!
This does happen when you reach a certain point in the space stage (although the first official patch reduces the amount of disasters and attacks in easy and normal mode), however once you obtain the funding to properly outfit your colonies with defense turrets, it is no longer a problem. They may still call you back, but they survive fine with no help. With a sufficient number of colonies, you make more money every few minutes than you could possibly need.

The one spaceship issue is kind of annoying, but keeps the game from being too close to an RTS at this level and allows more of a sense of immersion. I know quite a few people disagree, but my guess is that was the intent. Also, you can travel to the center of the galaxy.

5) There is no actual evolution!
This is true, and I do not know if this was ever planned to be included. It would have been nice to have some simple evolution like that which occurs in the old SimLife game, but nothing is perfect. Spore already includes some amazing technological achievements, most notably the procedural generation of the planet environments and the galaxy, the various creators, and the texturing system used.

Creating creatures, buildings, and vehicles is awesome, and probably one of the best characteristics of the game. By the time you get to the space stage, your creature has various accessories from all the previous stages. Also, if they are anything like all the other races, they have an annoying voice and often jump around excitedly for no apparent reason.
Regardless, it is a lot of fun to see how other people interact with your race (see the Sporepedia) and to see a less evolved version of one of your creatures in another game.

6) The Grox are the biggest jerks ever.
All part of the game, my friend. I'm sure you know people with the same attitude.

7) I disagree, and you sir, are an idiot.
That could be. At least that sentence makes sense and everything is spelled right. Oh yeah, I worded it for you.

This is just my opinion, you do not have to agree with it. I play Spore a great deal and have a lot of fun with it. Games do not always have to be about constantly using strategy and tactics to destroy an enemy. That is always awesome, but Spore is a different type of game. Maybe not what everyone expected, but still great.

Now, if you live in the US, take a break from games, do something useful, and go watch the Vice Presidential debate (CNN, Youtube, etc).

The Return

2008-09-26T18:20:00.003-04:00

So I have not posted for a while. A long while. However, it's all good.
I'm back into the swing of school, and I'm planning on writing at least one post a week here. To start out, I will post a rebuttal to a lot of criticism written recently by some worthless pricks concerning Spore , and my experiences with common LISP. Stay Tuned.

Embedding Mozilla in Java SWING Applications:JDIC and Mozswing

2008-07-21T22:19:00.004-04:00

Sorry for the delay, I have been doing some overtime at work and have been pretty lethargic outside of it. Anyway, on with the article!

If you need to embed a web browser into a Java Swing application on Windows, you have many options, of which I have found the most useful is JDICplus, or JDIC itself. Both of these approaches are very well documented with excellent sample code.

However, doing this in a Linux environment is a little more complicated. I succeeded using no commercial software. There may be much better methods, but this is what worked for me.
I was initially able to get the package up and running using Mozswing. There is currently next to no documentation, but looking at the provided sample code helps a great deal. It uses the Xulrunner application from Mozilla to embed the browser. I did experience some instability (probably due to their Java/GTK libraries) under certain conditions, but they were easy to spot. The issues seem to be present if the Java application uses a large number of JNI calls. If you experience instability, I recommend using JDIC as discussed below.

Pros:

Embeds a browser as a JPanel, fully compatible with the rest of the Swing application
Tri-Licensed (GPL, LPGL, Mozilla), so it can be used in all the same situations as Mozilla.
Uses an up-to-date version of Xulrunner

Cons:

Early in development, currently at Beta 1 release
Some instability issues with Java applications that make heavy use of JNI
Many JAR and SO libraries

Because of the stability issues I tried out JDIC. Although at the time of this writing, the front page says it has not been updated since 2006, looking at the download page shows some active development. JDIC proved to be very stable, no matter the situation, and had few JAR and SO library files to carry around. It does embed the browser as an AWT component, so in some situation that may be an issue. However, I used it in an application with a very rich Swing GUI, and had no problems with the browser window drawing/resizing as necessary. I was also only able to use JDIC with Mozilla 1.7.13, which is kind of old. OK, fine. Really old. JDIC does not work with Firefox, and for some reason on Linux, embedding Seamonkey causes the scrollbars to disappear.

Pros:

Very stable
Licensed as LGPL, not GPL
Very little JAR and SO baggage to distribute

Cons:

Only works correctly with old version of Mozilla.
Embeds as an AWT component, which could cause problems in some Swing applications.

During this process I was able to find very little information on this subject. If you are faced with this problem and are unable to use a commercial library to solve the problem, I hope this information can help you piece together a solution.

Interfacing C/C++ with Java Through JNI

2008-06-28T10:41:00.010-04:00

There are quite a few applications that for one reason or another are written partially in C++, and partially in Java. In most cases it seems the GUI is the Java portion. While several methods exist to interface C++ and Java, the one that is a core part of Java is the JNI, or Java Native Interface.

It is much easier to use the JNI than one might think, although it does produce some nasty looking C code so it is sometime difficult to debug. The process for creating methods with the JNI is simple. This example uses the tools included with the standard JDK (Java Development Kit).

Create a class and include declarations for the method you would like to implement in C/C+


public class TestJNIClass {
   //Method declaration.
  private static native void testJNI();

  //Loads the library. Use System.loadLibrary() 
  //if the library will be registered with the system.
  static {
      System.load("./TestJNIClass.o"); //For UNIX
      //System..load(./TestJNiClass.dll); //For Windows
  }

  //Test call to the method
  public static void main(String[] args) {
  TestJNIClass.testJNI();
  }
}

Compile the class: javac TestJNIClass.java

Generate the C header file with the javah tool: javah -jni TestJNIClass (There are many options you can pass to this command, check out the man page).

Implement the C or C++ functions you would like to include, then compile using your compiler of choice. Note: If you get errors about a missing jni.h file, be sure to include the JDK Home/include directory, and if you're on Windows, the JDK Home/include/win32 directory as well. Make sure you are compiling a library native to your system (for example, DLL on Wndows)


#include "TestJNIClass.h"

JNIEXPORT void JNICALL Java_TestJNIClass_testJNI
  (JNIEnv *, jclass)
  {
    printf("Output!\n");
  }

Run the java class you compiled earlier, and it will call the native method you wrote in C/C++!

If you you need your methods to return simple datatypes, simply add the return type to the declaration in the java file. This article barely scratches the surface of what you can do with JNI, be sure to check out the official Sun documentation or if you're really interested, there are several books written about JNI.

Managing Solo Software Development with Spreadsheets

2008-06-22T18:23:00.008-04:00

This is more of a quick tip than a full-fledged how-to.

For software projects involving only one person, or even just a few people, there is no reason to deploy a full-fledged item tracking system to manage the various components of the project and to who each item is assigned. The method I use involves a simple spreadsheet. Almost any spreadsheet software (Excel, GNumeric, etc) will work, as only the base features are needed.

First, decide which characteristics each item or task of the project will have. I recommend assigning each task the following:

Name
Description
Assignee (if more than one person is involved)
Estimated Time
Actual Time
Status (Defined, In progress, Finished, etc)

For projects that are not simple enough to be divided into tasks, you can divide each task into components, with each having the above characteristsics as well as the task they are assigned to. For example:

This method of managing projects works well for me. Hopefully you will be able to adapt it to your needs. Enjoy!

Alternative Uses for Version Control: Games

2008-06-15T11:42:00.003-04:00

I am an avid player of Simcity 4. However when trying out a new strategy for developing a city, I find it much easier to plan out the development in stages, and save the cities between stages. Making backup copies of a city is a pain because each city file is stored in a region folder. You need to manually copy the file to a different location and rename it. Obviously, if you plan on backup up a city more than a few times during its development, this becomes a pain.

One solution I have been using recently is to place the region folder under version control using Mercurial. In fact, almost any version control tool would work in this situation. Simply add the cities you want to track, and make commits whenever you reach a point you want to preserve. If a few saves later you notice that your decision to build a prison in the middle of a high wealth residential zone is not quite working out, instead of destroying it and trying to improve the land value again, you can simply revert to an earlier revision. Here is an example using Mercurial:

[Create a new city within the game]
hg commit "City - TheCity.sc4" -m "Initial Commit."
[Play the city for a while, make a few saves]
hg commit "City - TheCity.sc4" -m "Basic residential, adding more industrial."
[Play the city for while]
[Massive air and water pollution...overall reduction in health...uh oh]
hg revert "City - TheCity.sc4"

This is an oversimplified example, but you get the idea. While this obviously does not promote realism in the development of a city, when trying out new techniques it can save you a lot of time and frustration. This idea is also applicable to other games that do not have some type of "save as" feature to back up progress.

Managing Multiple Repositories with Mercurial

2008-05-30T10:38:00.011-04:00

Unfortunately my interest has shifted to other projects, so I will not be continuing my series on different distributed revision control systems at the moment. I may pick it up again at some point in the future. However, since I currently use Mercurial, I will be posting information on how I use it. For now I'll give an overview of different ways to use Mercurial to manage multiple projects.

From my personal experience as well as sources that I have read, it seems that there are three main ways to use Mercurial to manage multiple projects:

Single Repository - There is a root directory called something like "projects", which is the Mercurial repository. Each project has a subfolder, but all of the tracked files are in the main repository.
Multiple Repositories - Each project has its own repository. They are most likely all grouped under the same root folder, but all have different histories and are managed independently.
Multiple Repositories with the ForestExtension - Each project has it's own repository, however they are all "nested" repositories in one large Mercurial repository. The ForestExtension provides commands to manage all the repositories in a loose group.

Single Repository
This is the setup I currently use. I have a main "Projects" directory, containing folders for various categories of projects. Each of those in turn has a folder for each project in that category. The advantage is that to back up the repository I can deal with everything at one time. In addition, there are a few tricks to deal with the projects independently.

For example, to view the history only affecting files associated with a certain project, list that project's subdirectory after the "log" command:

hg log /projects/school/project1

It is also possible to clone only part of the repository (eg, a particular project), and merge it back in using the ConvertExtension. You must create a temporary file that includes the path of the files you would like to extract. For example, you would create a file testconvertmap.txt that contains the text: include "school/project1". Then run the command:

hg convert --filemap testconvertmap.txt /projects /subproject

The new folder "subproject" will contain the subset of the repository with all the files in the directory that you specified, with full history concerning those files. This is useful for testing a feature in a particular project, or providing someone with only the part of the repository they need. You can merge your changes back into the main repository, however depending on the nature of the repository and the changes you may need to employ the method outlined in Merging Unrelated Repositories.

Multiple Repositories
The advantage to this method is that each project is actually independent. No special methods are needed to clone a project to test a new feature or only extract the information for a particular project. However if you later want to combine two projects (eg, they are closely related), you will need to employ the method in the Merging Unrelated Repositories document mentioned in the previous section.

Multiple Repositories with the ForestExtension
I have not used this extensively, I have a small group of test repositories in a "forest". However, at least conceptually, this seems to be the most convenient method for handling multiple projects. Each project is in its own repository, so cloning individual projects is just as easy as with the Multiple Repositories method. However, all of these repositories are in one larger repository. The ForestExtension provides commands to operate on all of the repositories at once, such as fpull, fpush, fupdate, fstatus, etc. This makes backups and bundling of all the repositories similar to the Single Repository method. There is also a recommendation to include the functionality of this extension into the core of Mercurial with NestedRepositories. I will be working with this method more in the future and will expand on it when I know more.

Each of these methods has advantages and disadvantages, just like anything else. I would recommend trying each with a small number of projects to see which you prefer, then employ that for all of your projects. Since it is possible to convert between them, whichever you choose is not set in stone.

Reviews of Distributed Revision Control: Mercurial

2008-05-08T21:01:00.007-04:00

First up on the reviews of distributed revision control systems (DRCS) is Mercurial. This, along with Git, is one of the revision control systems that came out of the big Bitkeeper Debacle of 2005 (believe it or not, I did not come up with that name, and I’m sure it’s trademarked). Long story short, Bitkeeper was the versioning system used by the Linux Kernel developers until Larry McVoy (the CEO of Bitmover) decided to take away the free license. Of course there is much more to the story, but you can read up on that on your own if you care.

Anyway, Mercurial is written in Python with the exception of a few core routines written in C. The command line user interface is very well designed. The commands are intuitive and relatively easy to get used to, especially if you are familiar with Subversion or CVS (If you are still using CVS, you should probably upgrade. Seriously.) Mercurial's output is customizable, making it perfect for scripting. However if you prefer a GUI, there are some available. The classic repository features (such as hooks and permissions) are all there, and it scales well for large projects. Mercurial is used by projects such as NetBeans, Mozilla, and OpenSolaris.

My personal experiences with Mercurial have all been pleasant. It has worked well for small/medium projects, both with me being the only developer and with a few more people contributing to the repository. I have also used Mercurial to manage some patches on top of the Linux Kernel with a great deal of success. Having patch management built on top of the revision control system is incredibly convenient. Just try it.

Stay tuned for the next review, Git.

Reviews of Distributed Revision Control Systems

2008-05-06T22:31:00.008-04:00

I know many people involved with software development have at least heard of distributed revision control (DRC), but there are still many that have not. In this series of articles I attempt to summarize the differences between distributed revision control and traditional centralized revision control while comparing different distributed revision control systems; namely the open source applications Mercurial, Git, Bazaar, and darcs.

Alright, alright, CALM DOWN. I apologize if your favorite application is not on the list, but I am going for quality over quantity, and these are the four systems I have used extensively. There are many others as well. Subversion and Perforce will be the centralized revision control systems that I use for reference.

For a more in-depth description of distributed revision control in general, check out this introduction, or this talk by Linus Torvalds (Warning: His views are very one-sided, so do not take it personally if he bashes your favorite revision control system).

Stay tuned for the first review: Mercurial.

Software Design Patterns: Observer Pattern

2008-04-27T00:58:00.006-04:00

I learned about the Observer (also known as Subscriber) pattern near the beginning of this semester in my Software Design Methods class, and had the same thoughts that I’m sure most people have when they first learn about it; “Oh, that could be useful”. Then I went right back to pretending I was out fishing somewhere, and not in class.

Recently I’ve actually begin to use the Observer pattern in a project, and it has been very helpful. Some of you may be thinking that I am making stuff up, “fabricating” as it were, that there never was such a thing as the Observer pattern. HA! Got You!

Just kidding, it is an extremely useful pattern, most notably for interaction between the core functionality layer of an application and the UI layer (be it a GUI Graphical User Interface or CLI Command Line Interface). For those of you who do not know what the Observer pattern is, I’ll explain it briefly. Various objects “subscribe” to other objects that broadcast some type of information.

For example, let’s say that you are object A, and object B is a website that offers a weekly e-mail newsletter. You subscribe to object B, aka the website, because the newsletter sounded interesting at the time (We've all done it). After subscribing, you, along with everyone else who is subscribed, receive a weekly copy of the newsletter. After a few weeks you decide that the newsletter is an abomination and a waste of time and unsubscribe. The next week you do not receive an e-mail, but everyone who is still subscribed does. This pattern allows information to be sent to whichever objects declare that they would like to receive it, thus allowing a great amount of flexibility for future changes.

While the project I’m referring to only has a rudimentary GUI, I’m using the observer pattern to facilitate showing updated information. I am only familiar with the implementation of this pattern with Java using interfaces, but I imagine it is trivial to use an inherited class as well. Here is a more detailed example using interfaces:

A is an integer counting the number of words in the text file
B is a GUI widget in the status bar that displays the number of words in the text file
B implements the “Observer” interface, implementing a method such “getUpdate()”, allowing objects it is subscribed to send it new information.
A implements the “Observed” interface, implemented methods such as register(), and unRegister() for subscribing and unsubscribing objects. These methods both take in references to Observer objects as arguments. There should also be a method for sending the update to all the observers.
A has an internal list of references to Observer objects that are its subscribers.

To allow the status bar (B) to receive the word count updates, implement a simple Observer interface with a function that knows how to handle update information. In the current example, it may be getUpdate(int wordCount). Implement a simple Observed interface in A with functions to register/subscribe and unregister/unsubscribe Observers. For example, register(Observer newObserver), unRegister(Observer newObserver). You will also need a function to send the update to all the observers. It should basically just iterate through the list of observers, calling the getUpdate() function of each with the proper arguments. It could be called something like sendUpdates().

The main program may look something like this:

Observed A;
Observer B;
A.register(B); //Register the observer
A.sendUpdates(); //Update all the observers

I realize that this is a very generic example, but I hope it conveys the general idea. The beauty of this pattern is that if at a later time you need another widget to monitor the word count, you just need to implement the Observer interface and call the appropriate functions. There is minimal modification to code that you have already written and tested.

I encourage you to try this out, you’ll thank yourself later.

Two excellent books about design patterns in general:
Applying UML and Patterns
Design Patterns (Head First)

Ext2 Gotchas (Directory Entry Size)

2008-04-19T01:56:00.005-04:00

Recently in my Operating Systems Concepts class, one of our projects involved reading in an ext2 filesystem and listing the contents of the root directory. For anyone who is familiar with filesystem programming, yes, you can go ahead and laugh at the simplicity of this project.
Seriously, go ahead, I'll wait.

However, there is one aspect of the ext2 filesystem that was extremely difficult to track down: the size of a directory entry must be a multiple of four (4). This makes sense for efficiency reasons, however people familiar with this filesystem seems to take this for granted when writing descriptions and make no mention of it. The directory entry structure is defined as a struct in C with the following items:

Inode Number (4 bytes)
Length of this entry (2 bytes)
Length of file name (1 byte)
File Type (1 => File, 2=> Directory) (1 byte)
The file name (? Bytes)

The reason the size is variable in practice is due to the variable lengths of file names. If the length of the name is not a multiple of four, extra bytes are tacked on the end to even it out. For example, take the link present in every directory pointing to its parent. The name of this link is “..”, causing the size of the directory entry structure to be 10 (4 + 2 + 1 + 1 + 2). Two null bytes are added to the end of the name giving the structure an appropriate size of 12.

I finally figured out the answer after looking at different systems with a hex editor, and then got a hold of the book Understanding the Linux Kernel by Bovet and Cesati, which was invaluable. (It is also available online at Google books.) So if you ever find yourself writing a tool for dealing with ext2 or ext3 filesystems and cannot use the existing functions for whatever reason, keep this is mind.

On another note, here is another resource that was very helpful when doing this project. It is a great in-depth introduction to the ext2 filesystem for those who are not familiar with filesystems in general.

The Beginning (Always has to be somewhere)

2008-04-18T23:46:00.000-04:00

I'm starting this for the same reasons that many other people start blogs. Or so I imagine.
I have quite a few projects I would like to get started on and with the semester ending in a few weeks I will finally have the time to actually do them. Writing about them here will hopefully help motivate me to keep with them until completion.

I will probably write about other programming, software design, and general technology topics as well as time goes on. I'll just have to see how it goes.