csammisrun

A rare situation

Archive for the ‘Development’ Category

At long last – a Lock’n'Roll update!

without comments

Lock’n'Roll, a Pidgin plugin for Windows designed to set an away status message when the PC is locked, has received its first update in three and a half years!

Daniel Laberge has forked the project and released a version 1.2 update which allows you to specify which status should be set when the workstation locks. Get it while it’s awesome (always)!

Written by Chris

February 7th, 2013 at 9:56 pm

Blast from the past

with 2 comments

Extremely nerdy post ahoy!

The new version of the .NET Framework will be coming out relatively soon, and I spied this little gem on the BCL Team Blog: ObservableCollection<T> is moving into System.dll so implementers can avoid a dependency on WPF.

That would have been nice about a year and a half ago :(

Written by Chris

October 22nd, 2009 at 4:02 pm

Posted in Development,shaim

Surprise, I didn’t forget about this project!

without comments

Way back in April I talked about a new programming project: extracting and analyzing text from the Codex Seraphinianus. It’s been several months since any updates. Progress has been really sporadic (life happens), but I can now present the next step in my silly past-time.

In my last post I mentioned that the pixel connection algorithm wasn’t perfectly suited to isolating words. One of the problems was that the scan quality produced a lot of “broken” text – cursive lines don’t quite line up and sometimes a single word is carved up into multiple regions. I’ve implemented morphological functions to “close” words and produce better connections, but I haven’t taken the time to sit down and tune the process so that it doesn’t accidentally turn fine loops into dense blocks of black. The other big problem was that the process didn’t group diacritics with the modified word, and it is the solution to this that I’d like to share.

First, let’s understand how the connected components algorithm outputs its information. It starts with an image that looks like this:

The algorithm starts at the upper-left and works down and right, numbering the regions as it encounters them (usually, more on this later):

The challenge now is to attach the diacritic, region 2, to the larger word represented by region 1. To do this, each region gets a bounding rectangle…

…and the following algorithm is applied to all N regions:

for each region X between 1 .. N:
  for each region Y between X + 1 .. N:
    if region Y is fully contained by region X:
      region X consumes region Y

In the example image, region 2 is indeed fully contained by region 1, so it becomes part of region 1. This is good for the Codex script, most diacritics appear close to the letter it modifies and usually within the boundaries of the full word. Applying this procedure to the first page of the Codex yields some pretty good results.


Click for full-size

Still not perfect, though. You can see that there are some diacritics that are clearly fully contained by the parent word, but they aren’t consumed by the word.

It turns out that there are some pathological cases in region numbering. The connected region algorithm does not always correct number regions in a top-down and left-right manner, so the enclosure algorithm listed above doesn’t catch everything. Let’s say that the example image is one of these cases:

Now region 1 doesn’t enclose region 2, and since the algorithm only counts up (for efficiency’s sake), the diacritic isn’t grouped in with the word.

It’s not a great situation, but there’s a fix. Rather than mess around with the connection algorithm and trying to figure out the numbering sequence and where it breaks down – even for a small image, the numbers start getting pretty hard to keep track of in one’s head or on paper – I added an extra step when the bounding rectangles are calculated. Working again in a top-down/left-right fashion, I simply renumber the bounding rectangles as they’re encountered. This fixes the misnumbered cases and doesn’t add complexity for the normal cases, and the result is much better:


Click for full-size

We’re still not at 100% diacritic capture – if you look closely, there are three diacritics that aren’t included with the word that they’re intended to be included with (left of the first word, right of the fourth word, right of the last word). This isn’t another pathological case or anything, those marks actually do not fall completely within the bounding rectangle of their word. Oh well. It’s time to move on to other things – frankly, if I get to the point where I’m statistically identifying language features and a couple missing diacritics make a huge difference, I can go back and tweak things then :)

Written by Chris

October 15th, 2009 at 9:44 am

Posted in Development,General

Upping the Nerdiness Ante

without comments

I was working on some database stuff today when I had the greatest (read: dorkiest) idea for an avatar / custom text combo:
 
 

Chris
A Big Nerd
Posts: too many

 
E. F. Codd
I smoke two JOINs in the morning

 

Written by Chris

July 21st, 2009 at 2:39 pm

Posted in Development,General

Lock ‘n’ Roll 1.1

with 19 comments

A stunning update to Lock ‘n’ Roll 1.0.1, this version includes the following changes:

  • New: LNR restores statuses that it replaces when the workstation locks
  • Bugfix: LNR no longer replaces Unavailable, Offline, or Invisible statuses
  • Misc: Documented the source code
  • Misc: Updated URLs to point to the specific LNR category at my site

Thanks to O. D. for submitting a patch to accomplish the new feature and the bugfix!

Download locknroll-1.1.zip, source and binary included. To install, copy “locknroll.dll” to the Pidgin plugins directory. To activate it, restart Pidgin and go to the Tools menu, select Plugins, and tick the checkbox next to “Lock ‘n’ Roll”

Written by Chris

June 14th, 2009 at 2:41 pm

Oh boy, another programming project!

with 4 comments

Since shaim is over, I’ve found myself with rather a glut of time on my hands. I’ve been reading a lot more (alternating between the Dune series and the Dresden Files series) but I still have the desire to work on programming stuff in my spare time. This time around I’ve decided to combine my love of strange books with my interests in linguistics and computational analysis.

I’m guessing that aren’t many people reading this who know what the Codex Seraphinianus is. From Wikipedia:

The Codex Seraphinianus is a book written and illustrated by the Italian artist, architect and industrial designer Luigi Serafini during thirty months, from 1976 to 1978. The book is approximately 360 pages long (depending on edition), and appears to be a visual encyclopedia of an unknown world, written in one of its languages, a thus-far undeciphered alphabetic writing.

It’s rather rare (read: expensive) and isn’t currently published in the US, but I happened to get a hold of a copy via Courtney’s connection to the library at the University of Illinois. The art is beautiful, and the language intrigues me. Linguists have worked at figuring out this language since the book was first published – for all anyone knows, it’s complete nonsense. I’m not vain or stupid enough to think that I can succeed where trained linguists have not, but I decided I’d try my hand at learning about image processing and give the deciphering a crack myself. What can it hurt?

The first step to all of this ballyhoo is to extract words from the book. Recently I came across some fairly high-quality scans of the Codex. Here’s an example of the writing:
Writing from the Codex Seraphinianus
Writing from the Codex Seraphinianus

The scans are full-color and you can see where images on the opposing page have shown through. The first thing I did was write a quick program to convert the images to black-and-white. This removes a lot of the noise, smallerizes the image files, and gives analysis algorithms an easier time of figuring out what’s where.

The same paragraph in 2-color format
The same paragraph in 2-color format

The next step is to figure out where words are on the page. I’ve implemented a connected components algorithm that identifies connected regions on an image.

The same paragraph with connected regions colored
The same paragraph with connected regions colored

That’s all my progress as of last night. The algorithm isn’t perfect yet, I’ll have to tweak its performance to find regions that should be connected but aren’t because of quality issues in the black-and-white format. You can also see that diacritic marks aren’t grouped to the word that they belong to, so the next phase of processing will involve grouping regions that fall within a bounding area.

I’m not entirely sure what comes next, at least as far as extracting the text goes. This is a learning experience for me. Further bulletins as events warrant :)

Written by Chris

April 16th, 2009 at 9:10 am

Posted in Development,General

I’m all up outta here, part 3

with 2 comments

The even-stunninger conclusion to I’m All Up Outta Here parts one and two!

I’m just going to come out and say it: I’m burned out on shaim. As of right about now, I’ve been developing some incarnation of shaim for four years. I really enjoyed the experience that it netted me, as well as the satisfaction of helping loyal users as they reported bugs and endeavored to help me make it better, but now enough is enough. The site will remain up as long as Greg sees fit to leave it up; if it ever goes down, I’ll transition the codebase to another host so that anyone who wants to use any part of it may do so.

Thanks go out to everyone who’s contributed code, resources, or general support over the years. In no particular order:

  • Greg
  • CheeToS
  • saiyr
  • Joy
  • Andrew
  • The group from Western Washington University who contributed to shaim for their senior project
  • The dozens of people who’ve contributed bug reports and kudos

PEACE OUT

Written by Chris

April 16th, 2009 at 8:35 am

Lock ‘n’ Roll 1.0.1

with 15 comments

This is a bugfix release updating Lock ‘n’ Roll 1.0 for Pidgin. The original version crashed when a message was received while the computer was locked…not very helpful at all. Version 1.0.1 should have that fixed up right nice.

Thanks to everyone who has sent feedback so far, both in the form of bug reports and feature requests. I’m hoping to get around to implementing all the great suggestions I’ve received very soon! If you’d like to leave any feedback about this new version, hit me up at .

Download locknroll-1.0.1.zip, source and binary included. To install, copy “locknroll.dll” to the Pidgin plugins directory. To activate it, restart Pidgin and go to the Tools menu, select Plugins, and tick the checkbox next to “Lock ‘n’ Roll”

Written by Chris

March 6th, 2009 at 2:13 pm

Lock ‘n’ Roll

with one comment

A computer is a box where decisions are made.

Phillippe, age 5

One of the computer decisions I make on a frequent basis is to get up and walk away from it, locking the workstation as I go. Sadly, Pidgin, the IM client I use at work, remains blissfully ignorant of my choice. Other IM clients automatically set the account status to “Away” when the workstation is locked, but Pidgin does no such thing…until now.

I’ve created a Pidgin plugin called Lock ‘n’ Roll that will set any active accounts to Away (with a user-defined message if applicable) when the workstation locks, and back to Available when it is unlocked. If an account has an existing away message set, Lock ‘n’ Roll leaves it alone. This is my first shot at Pidgin development so be sure to report any errors to so that I can fix them and make everyone’s life a little happier.

Download locknroll-1.0.zip, source and binary included. To install, copy “locknroll.dll” to the Pidgin plugins directory. To activate it, restart Pidgin and go to the Tools menu, select Plugins, and tick the checkbox next to “Lock ‘n’ Roll”

Written by Chris

January 22nd, 2009 at 9:18 am

What thread do shaim events use? – or, Why status updates don’t make the UI cry

without comments

Fourth in the series of “how or why shaim does what it does”:

  1. WPF versus IM typing notifications
  2. WPF windows, in my Winforms application?
  3. .NET 3.0 functionality in .NET 2.0: a sorting, filtering, bindable list (Part Two)

Right on the heels of the two-parter on the BindingListCollection, this little spiel will continue the trend of describing the core contact list and its data structures, and how it all works with the UI. We’ll also touch on the threading model – or complete lack thereof – of the shaim core and its plugins.

A little GUI development background, but not much

A graphical UI (any graphical UI, not just shaim’s) can only be updated by the thread that created it. If another thread tries to update some text, or move a window, or change something’s color, the UI could deadlock and that is not good. The process of executing code on the UI thread is called invoking : any thread can call the Invoke method on a UI object, give it some code to execute, and that code will be executed on the UI thread so it can safely update the UI.

shaim’s hedonistic threading free-for-all

With one notable exception – which is the subject of this post – the shaim core doesn’t make much of an attempt to control the threading of its plugins. Each plugin is free to do whatever it wants, and shaim events aren’t guaranteed to be synchronized to anything in particular (the core does synchronize access to its data structures so that operations like ContactList.UpdateContactStatus will execute in the order they were called).

Let’s take OscarLib as an example. The initial login sequence of OSCAR is a pretty rigid call-response setup, so when the network socket receives data, it processes and sends a response on the same thread. The synchronous processing ensures that there aren’t any responses out of order from the packets that initiated them. This all changes, however, once the OSCAR session is initialized and asynchronous messages like status updates start coming in. Processing something like an incoming message may take a noticeable amount of time, and if it’s being processed on the same thread that received it, the socket might end up missing a packet. To solve this problem, the socket uses the ThreadPool.QueueUserWorkItem method to dispatch an incoming packet. The packet is processed by a random thread in the thread pool, a system-allocated collection of threads that are meant to be spawned for processing information in the background (that is, not in the main process, which in this case is the thread that owns the socket).

“Processed by a random thread” – so these events are not happening on the UI thread. Huh. Problems ahoy!

The easy part: dispatching shaim events in the UI

Each shaim event defined by the core defines a delegate that can handle itself (tee hee).

public class ShaimMessageReceivedEvent : ShaimIncomingEvent
{
    public delegate void Handler(ShaimMessageReceivedEvent);
}

When a plugin registers to handle a specific event, it uses a method that matches the signature of the event’s Handler delegate. We can define a very very simple incoming message handler registered by the UI plugin that will display the message to the shaim user:

private void HandleIncomingMessage(ShaimMessageReceivedEvent evnt)
{
    Conversation conv = FindConversation(evnt.Contact); // Gets a reference to the conversation window for this contact
    conv.AppendMessage(evnt.Message);  // Appends the text of the message to the conversation window
}

Simple, but it won’t work right. When this event comes in on a thread other than the UI thread – and it most assuredly will – the UI will lock up and WPF may even throw an exception and die unexpectedly and leave a ton of debt for its family to take care of, but it had no life insurance and the whole debacle ends in bankruptcy.

Let’s avoid that by dispatching the incoming event onto the UI thread:

// A simple delegate that will be initialized in a single method's scope
private delegate void AnonymousInvoker();

private void HandleIncomingMessage(ShaimMessageReceivedEvent evnt)
{
    AnonymousInvoker invoker = delegate
    {
        Conversation conv = FindConversation(evnt.Contact); // Gets a reference to the conversation window for this contact
        conv.AppendMessage(evnt.Message);  // Appends the text of the message to the conversation window
    };
    // Invoke the operation on the UI thread
    Application.Current.Dispatcher.BeginInvoke(invoker);
}

It’s a bit more verbose, and it has to be done for every incoming event, but it’s 100% thread-safe. It also has the benefit of removing the responsibility of marshalling every event onto the UI thread from the core. This is a desirable trait because it encapsulates UI responsibility within the UI plugin. The shaim framework might not even have an active UI plugin, so there’d be no reason for the core to have to perform the extra logic.

The hard part: dispatching binding events in the core

The above works well when the developer is defining their own event handlers, but it doesn’t solve the thread dispatch problem when something happens for which there isn’t an explicit shaim event. When there’s a direct binding between a data structure and the UI, and another thread updates the data structure, the binding attempts to update on the same thread that invoked the change and the UI craps itself. This presents a huge problem for the contact list and its constituent objects and collections, all of which are directly bound by the UI and updated by random threads spewing out of the plugins.

Well hell, there goes our fever-dream of the core not knowing anything about dispatching onto the UI. Fortunately, we can at least design the solution so that the core doesn’t have to know anything specific about the UI. It has to know two things: one, that the UI requires dispatching, and two, how to dispatch an event onto the UI thread. In turn, the UI has to expose information about whether it requires dispatching, and provide a generic mechanism for doing dispatch.

An interface is defined that provides a method to check whether if dispatch is required, and a method to do the dispatch:

/// <summary>
/// Specifies an interface for an object that can dispatch method calls onto the UI thread
/// </summary>
public interface IUIDispatcher
{
    /// <summary>
    /// Dispatches a delegated method onto the UI thread
    /// </summary>
    /// <param name="methodDelegate">The delegate to invoke on the UI thread</param>
    /// <param name="parameters">A list of parameters to pass to the method</param>
    void Dispatch(Delegate methodDelegate, params object[] parameters);
    /// <summary>
    /// Checks to see if the currently executed thread has access to the UI thread
    /// </summary>
    /// <returns><c>true</c> if a method can be executed in the context of the UI thread</returns>
    bool CheckAccess();
}

…and the UI plugin interface is extended to request one of these buggers from the UI plugin:

public interface IUIPlugin
{
    ...
    /// <summary>
    /// Gets a <see cref="IUIDispatcher"/> object to delegate method calls to the UI thread
    /// </summary>
    /// <returns>A new <see cref="IUIDispatcher"/></returns>
    IUIDispatcher CreateDispatcher();
}

Each UI plugin will define their IUIDispatcher differently, but the WPF plugin does it like so:

public class UIDispatcher : IUIDispatcher
{
    private DispatcherPriority dispatchPriority;

    /// <summary>
    /// Initializes a new UIDispatcher
    /// </summary>
    /// <param name="dispatcherPriority">The priority at which to dispatch method calls</param>
    public UIDispatcher(DispatcherPriority dispatcherPriority)
    {
        this.dispatchPriority = dispatcherPriority;
    }

    #region IUIDispatcher Members

    public void Dispatch(Delegate methodDelegate, params object[] parameters)
    {
        if (Application.Current != null)
        {
            if (parameters.Length > 0)
            {
                Application.Current.Dispatcher.Invoke(dispatchPriority, methodDelegate, parameters[0]);
            }
            else
            {
                Application.Current.Dispatcher.Invoke(dispatchPriority, methodDelegate);
            }
        }
    }

    public bool CheckAccess()
    {
        return Application.Current.Dispatcher.Thread == System.Threading.Thread.CurrentThread;
    }

    #endregion
}

Using the IUIDispatcher in the BindingListCollection

Let’s take a look back at the BindingListCollection. It raises binding events in response to things like adding or removing items, as well as moving items around in response to status or name updates. Since those updates may be coming from some crazy random thread, it’ll need to use the IUIDispatcher to raise those events. The following is pseudocodeish, but it illustrates the point; consult the actual BindingListCollection code for details on the move operation and how the IUIDispatcher gets assigned.

private IUIDispatcher uiDispatcher;
...
private delegate void MoveInListHandler(T item);

void MoveInList(T item)
{
    // If there is no UI dispatcher or we're on the right thread...
    if(uiDispatcher == null || uiDispatcher.CheckAccess())
    {
        // Do the MoveInList action, finding new indexes and moving the item
    }
    else
    {
        // There is a UI dispatcher to contend with, and we're on the wrong thread
        // Invoke the current method on the UI thread, then the above code will execute correctly
        uiDispatcher.Dispatch(new MoveInListHandler(MoveInList), item);
    }
}

Presto! This method is used throughout the BindingListCollection and the ContactList to ensure directly bound data members are updated on the correct thread, and no UI plugin has to be concerned about where updates are coming from.

Ensuring events are invoked correctly is a pain in the ass, but a wholly necessary one. The IUIDispatcher is the best method I could design, but if any readers have ideas about how shaim could institute a threading model that doesn’t involve *every* plugin operation being executed on the UI thread, I’d love to hear about it in the comments.

Written by Chris

July 25th, 2008 at 10:03 am