• Time transposition (based on a patch by Matt Corks). Example: 62.5 in the “Minutes” field will now be converted to 1 hour, 2 minutes, 30 seconds.
• GStreamer for playing sounds (patch from Philipp Kern)

run-parts –test /etc/cron.daily
(replacing ‘/etc/cron.daily’ with whichever actual folder contains your script)

This will list the scripts that cron or anacron would run (the –test option tells it to show, but not actually execute, the scripts). Your script should appear in the output listing. If it doesn’t, verify that:

1. your script is executable, and
2. the name of the script has only letters, digits, underscores, and hyphens

#1 is easy to understand, but let me explain #2. By default (at least on Ubuntu), /etc/crontab and /etc/anacrontab are setup to execute the contents of the /etc/cron.* directories using a command like this:

run-parts –report /etc/cron.daily

but according to the run-parts man page:

If  neither the –lsbsysinit option nor the –regex option is given then the names must consist entirely of upper and lower case letters, digits, underscores, and hyphens.

This means that run-parts will just ignore scripts that are not named properly!

Preferences

• Display line numbers
• Highlight current line
• Display right margin (so I know when I’m putting too much on one line)
• Enable automatic indentation

Plugins

• File Browser Pane (included) – Sidebar for browsing and opening files
• Indent Lines (included) – Indent/unindent selected text
• Snippets (included) – Expand abbreviations to snippets of boilerplate text.
• Code Comment (gedit-plugins) – Comment/uncomment selected text
• Draw Spaces (gedit-plugins) – Show tab and space characters
• Smart Spaces (gedit-plugins) – When using spaces for indentation, this lets you unindent by pressing backspace once, rather than pressing it as many times as the number of spaces you use for one level of indentation.
• completion – Auto-complete words
• snapopen – Quickly open files using regex
• autotab – Detect whether the tab key should insert a tab or spaces, based on what’s being used for indentation in the rest of the file

For Ubuntu, I’ve noted the plugins that are included with the standard gedit installation and the ones that come as part of the ‘gedit-plugins’ package. You can also go to the gedit Plugins page to see what other plugins are available.

• Ubuntu 8.10 “Intrepid Ibex”
• Driver: fglrx
• Compiz Visual Effects enabled
• Primary LCD monitor: 1680×1050 resolution
• Secondary LCD monitor (positioned to the right of the primary monitor): 1024×768 resolution

The following is the contents of my xorg.conf file (most of the important stuff is in the “Device” section). Hopefully others with similar setups will find this useful:

Section “Monitor”
Identifier “Configured Monitor”
EndSection

Section “Screen”
Identifier “Default Screen”
Monitor “Configured Monitor”
Device “Configured Video Device”
DefaultDepth 24
EndSection

Section “Module”
Load “glx”
Disable “dri2″
EndSection

Section “Device”
Identifier “Configured Video Device”
Driver “fglrx”

# Fix video flickering when Compiz is enabled.
Option “TexturedVideo” “off”

# Comment out the following line if you want to mirror the primary monitor instead of extend it.
Option “DesktopSetup” “horizontal”

Option “ForceMonitors” “lvds,crt2″
EndSection

Update: I forgot to mention a couple things:

• I’m using the version of fglrx provided by envyng.
• After updating the xorg.conf file, I had to open up the “Screen Resolution” settings panel and change the “Resolution” drop-down menu from “1680 x 1050 (16:10)” to “3360 x 1050″.

# * Monad structure:#    (((func1, state1), (func2, state2), (funcN, stateN)), watched_val)## * Watcher function signature:#    watcher_func(state, prev_watched_val)#      state will be equal to None on the first call

def make_watchable(watched_val):   return ((), watched_val)

def join_watchable(watchable):   outer_watchers = watchable[0]   inner_watchers = watchable[1][0]   inner_value = watchable[1][1]   return (outer_watchers + tuple([watcher for watcher in inner_watchers if watcher not in outer_watchers]),           inner_value)

def wrap_func_for_watchable(orig_func):   def make_updated_watchers(watchers, prev_val):       return tuple([(watcher_func, watcher_func(state, prev_val)) for watcher_func, state in watchers])   return lambda watchable: (make_updated_watchers(watchable[0], watchable[1]),                             orig_func(watchable[1]))

def add_watcher(watchable, watcher_func):   return join_watchable((((watcher_func, None),), watchable))

# Sample watcher functions

def count_modifications_watcher(state, prev_val):if state == None:   return 1else:   return state + 1

def track_history_watcher(state, prev_val):if state == None:   return (prev_val,)else:   return state + (prev_val,)

# Usage

>>> increment_watchable = wrap_func_for_watchable(lambda x: x + 1)>>> double_watchable = wrap_func_for_watchable(lambda x: 2 * x)>>> watched_zero = add_watcher(add_watcher(make_watchable(0), count_modifications_watcher), track_history_watcher)>>> >>> increment_watchable(watched_zero)(((<function track_history_watcher at 0xb7dd84c4>, (0,)), (<function count_modifications_watcher at 0xb7dd848c>, 1)), 1)>>> watched_two = increment_watchable(increment_watchable(watched_zero))>>> increment_watchable(double_watchable(watched_two))(((<function track_history_watcher at 0xb7dd84c4>, (0, 1, 2, 4)), (<function count_modifications_watcher at 0xb7dd848c>, 4)), 5)

Reading up a bit also helps. I found Wikipedia to be a good reference:
http://en.wikipedia.org/wiki/Monads_in_functional_programming

Dan also recommends this:
http://www.cs.toronto.edu/~sme/presentations/cat101.pdf

Carefully reviewing the Lisp examples and reading the above two links made a second reading of his post much more understandable for me.

Reading Lisp again was also strangely refreshing, but we definitely need some kind of in-browser paren matching. Maybe there’s some JavaScript magic somewhere? But even if such as thing existed, I doubt you’d be able to get it to work in WordPress. Oh well. Thanks for another excellent post Dan!

While working on some GObject-derived classes, I started to wonder if I was incrementing and decrementing reference counts at the correct times. I was confused by the fact that the g_value_get_object() method would return an object reference (the caller is not responsible for decrementing the reference count), but g_object_get() would return an object copy (the caller is responsible for decrementing the reference count). Reference counting APIs usually rely on naming conventions to indicate whether the caller will receive a reference or a copy, so I expected some standard behavior for “get” methods. Judging by other methods I’ve used in the GObject API, it looks like “get” methods should return object references rather than copies. It worried me that one of the most-used “get” methods in GObject, g_object_get(), has behavior inconsistent with that convention. After a bit of searching, I finally stumbled upon a few nuggets of information. The first post highlights some of the naming inconsistencies I encountered. The reply to that message explains that conventions were proposed a while ago but were never formally adopted, and he also links to the proposed conventions for reference.

Although I’m sure some attempt is made at maintaining consistency in function naming and reference counting semantics in GObject and related APIs, I really hoped that there was a formal set of guidelines that API developers could follow and that API users could refer to. It really is a annoying to have to either refer to the docs or browse the source code to figure out if a particular method’s return value must be unreferenced. Using naming conventions would not only make GObject-based APIs both individually consistent and consistent among each other, but it would also let developers know the exact reference counting behavior of a method just by looking at its name. I remember reading over some of Apple’s API docs, and both Core Foundation and Cocoa have a standard set of memory management guidelines. Something similar for GObject would be very nice.

So now I’m back in C. First of all, welcome back type declarations. I like the self-documenting nature of type declarations, especially in function/method arguments. It makes it much easier to understand how a particular function is used. Sometimes when reading other people’s Python code, I would have to follow call chains in reverse (by grepping through the source files for the function names) in order to figure out what the types of the arguments ultimately were (if there is smarter way to do this, please let me know). You could probably argue that this would not be a problem with better documentation, but why rely on someone to voluntarily document something when you can have strict enforcement by the compiler? I still like Python though. It’s just a different beast compared to C and has many advantages of its own.

A big annoyance about going back to C has been header files! After working with higher-level languages like C# or Python, having to create and maintain header files is just horrible. Why do I have to change two files whenever I want to add or remove a method or change a method’s signature?? But I wanted to learn GObject, and GObject is written in C, so let’s move on.

From my experience so far, creating new GObject-derived classes is a bit tedious in C (which I guess is to be expected), but it’s not too bad once you get used to it. You encounter a lot of friction in the beginning. It’s very difficult to stay on track and get anything useful done because you’re constantly trying to figure out how to create things like signals and properties. But once you get the hang of things, all that boilerplate code becomes understandable and almost second nature. Overall, it’s been a good learning experience. It’s nice to better understand the foundation on which GNOME is built.