csammisrun

From the co-respondence of C. B. Sammis, this Fourth day of September, Two Thousand and Eight:

To my colleagues at the Ministry of Gummi Studies:

Those who know me well know of my truest desire in the service of Mankind: the clarification of gummi bear behavior in climes which do not favor their fragile existence. Competing research has come to light from my most dear friend and greatest enemy, A. W. Haasbeck, on the methods and “delightful” consequences of immersing g. bear in libationous spirits. Haasbeck, ever the devious scientician, seeks only to derail the singularity of purpose that our Ministry holds most dear. Future publications under My Own Name will reveal that the genera gummi does not maintain cohesion under sustained application of alcohol (much like A. W. himself!). We know all too well that the Dionysian destruction of our beloved subject is not what we wish to present to the public, who strain ever-closer to hear new developments from our branch of Science.

So that you will not be concerned that this Ministry’s charter concerning the preservation of gummi creatures is anything but alive and well, I send advance notice of my current findings vis-à-vis the hibernation of gummi bears when exposed to the brisk chill of fine sorbets. Note here my cautions in the advance of our understandings! Until the very respectable studies of our colleague R. T. Clemens regarding lactose intolerance in g. worm are completed to the full satisfaction of us all, I do not risk exposing any of the gummi species to milky sherbets or iced-creams. This is the standard of ethics that one can expect from research performed under My Own Name.

Hibernation of g. bear commons under conditions of Lemon Sorbet
Under favorable conditions less pliable than organicii or haribo, this subspecies employs a most ingenious form of defending its small form while exposed to the cold. The observed commons hibernate in a consistency not unlike that of well-crafted bricks! Their addition to the sorbet environment becomes textural, rather than flavorful. Discretion should be employed for those with dental faculties at less than their peak.

Hibernation of g. bear organicii(?) under conditions of Raspberry Sorbet
The variations between the subspecies cannot help but to fascinate even those who have dedicated their life to their study. These bears, labeled organicii based on the Qualities of the establishment in which I observed them, have a vastly different hibernation pattern than commons. The bears employ an unusual defensive mechanism upon entering sorbet-induced hibernation: some breeds became positively distasteful, acquiring through currently unknown means the flavor of licorice. Additionally, it is a most unexpected fact that there was nearly no discernible decrease in the flexibility of their gummi substrates! I expect to have a full description of this phenomenon by the next Continental Meeting of Gelatinous Discovery Institutions.

The Ministry will no doubt question at this time my tentative classification of organicii to the subjects of this study. Further investigation is indeed needed in regard to the specific subspecies of g. bear used in this dessert establishment, and rest assured I will not publish until classification is beyond question – unlike the infamous P.N. Reisting, a man whose unbridled and inflammatory claims led to the founding of this very establishment of Science, I am a researcher in whom trust can be placed.

And here’s my marque to prove it. Gentlemen, I remain:

C. B. Sammis

That’s right, I’m trying this again. This weekend I’ll be making my more or less annual trip to Ames to visit my friends and old coworkers. Historically, this has not worked out well. This time around, however, I will be taking the new Mazda. Let’s see Ames try to kill my car now!

(oh god ames please do not hurt my car)

A few years ago some friends of mine were having a discussion about whether there was an opposite to sublimation: the change of a solid directly to gas, such as dry ice -> CO₂. We were none of us chemists or physicists (me especially) so we bandied about the idea of such words as superlimation and eventually dropped the subject.

Wikipedia has settled the matter for me: the opposite of sublimation is deposition. That was sort of anticlimactic, but could yield some vaguely amusing science fiction: one could use SUPERPOWERS to depose a despot using deposition, turning the poor tyrant into a cloud of vapor, then give a deposition on the subject before a Committee.

Really   vaguely amusing.

I managed to post threads about my fish tank on two different forums but forgot about my blog.

A while ago I decided I wanted to start with saltwater reefkeeping again, so when I ordered a small fishtank for my office, I decided to salt it up. Putting it in my office, however, just wouldn’t be very practical. The tank I’m using is only three gallons, and in the dry atmosphere of a heavily air-conditioned office, it’d evaporate like crazy. That’s bad enough with a freshwater tank but it’s really bad with saltwater because salt doesn’t evaporate, so the salinity of the water would fluctuate badly. It wasn’t too bad with my 10g tank back at CSSM because I had a topoff going and there was more water mass to balance things out. Long story short(ish), the tank ended up in my living room instead.

So, with minor alterations, here’s the contents of the thread I posted on Something Awful:

I bought a 3 gal Picotope a couple weeks ago, and decided to make it a nano reef in the general style of Sandeep’s 5.5 gal with in-tank refugium. I didn’t go the full refugium route, but I really liked the idea of partitioning off the hardware with the addition of an overflow.

The bare Picotope, it’s about 11″ x 8″ x 8″.

The piece of plexi I cut for the partition. It’s 3/32″ thick, with slats for overflow and a hole for the return powerhead. It’s about to be painted with Krylon Fusion flat black and set in the tank with GE Silicone I.

The tank is masked off and ready for the equipment area to be painted with Krylon Fusion satin black. I ended up masking off the bowed part of the equipment area so I had a place to look in and make sure things were working okay.

Looking into the equipment area after the painting. The powerhead (MJ400 or 600, I forget) and the HOB Taam Rio Nano skimmer are visible here. Note the plastic screw on the skimmer – that’s not stock. I didn’t like the way it was hanging on the back, so I got some little rubber stick-on feet and fixed them to the skimmer against the glass, then used a securing screw from an old HOB skimmer to get a tight fit. No rattling = good

The tank on its stand in my living room. The lamp that comes with the Picotope is a 9 watt PC 50/50, which I may be upgrading at some point.

Water + sand + rocks from an older tank added. There are a lot of microbubbles, which will hopefully go down as the skimmer activates.

Already churning away!

For stocking, when the time comes, I’ll probably stick with ricordea and zoas.

Since that thread was posted on August 4th, several things have changed. The microbubbles did subside after I added a piece of live rock from a nearby saltwater fish store, which activated the skimmer as the tank’s cycle got started. Ammonia/nitrite/nitrate testing a couple days ago indicated that the tank is almost done cycling. It’s already pretty freakin’ alive. There’s a small brittle starfish that came in with the piece of rock, an unexpectedly large number of amphipods (which is great, it indicates a healthy tank and makes good food for things), and last night I got a margarita snail and a scarlet reef crab. I’ll be taking more pictures tonight, after I pick up the fourth season of House and ingredients for gazpacho. Busy busy.

I’ve replaced most of the stuff that I lost when my sink exploded, thanks to the sale of Dethkar. I got a chef’s knife, cutting board, mixing bowl, colander, measuring cups and spoons, and a toaster oven. The last one wasn’t a total necessity, but the bottom of my microwave had gotten corroded by the overflow and I took it as an excellent excuse to replace the ole Radiation King.

As promised, I got it washed and took many a’picture!

Click for the Flickr set

I finally did it: a week ago I signed the papers for a new 2008 Mazda3 5-door, and on Tuesday I took delivery after it had been driven in from St. Louis.

Click for the Flickr page

That photo’s not very good, I admit this. The new car looks sort of black next to Dethkar, whereas it’s actually a dark blue, but I wanted to get a picture of the two side-by-side while I could. The guy who sold me Dethkar last September is buying it back, possibly as soon as tomorrow. I’m rather amused by the whole circle-of-life thing going on here.

As for the new car, it’s pretty outstanding. I’m still getting accustomed to shifting it, it’s got a much newer transmission with a much shorter throw, and the presence of a fifth gear is making me miss third occasionally. It hasn’t quite hit me yet that I own this beast – right now it still feels like I’m driving around a rental car. I imagine I’ll get used to the idea

More pictures are definitely forthcoming, most likely this weekend as the weather clears up and becomes sunny again.

I live on the bottom floor of a three floor apartment building. Drain pipes leading from the upper two floors naturally all go past my pipes before waste water flushes away into the sewers to nourish the Morlocks and whatever else is living down there.

Unless there’s a clog, in which case it all comes to visit Chris.

Thursday night, I heard a loud gurgling coming from my kitchen. Both halves of my kitchen sink are half-full of greasy gray hot water. “Well that is not good at all,” I say, and fetch my plunger. This had no effect whatsoever, and I sat there contemplating the situation before I finally decided to call the night maintenance line. About twenty minutes later, the maintenance guy comes over and does not like what he sees (surprise). We fiddle with it for a while before he decides to pour some sulfuric acid drain declogger into the mix. This has absolutely no effect, and now I have a sinkful of greasy gray hot acid water.

Right about then, the upstairs neighbor’s dishwasher cycles. Cue a rapid rise in the amount of greasy gray hot water in my sink – aaaaand it overflows onto the counters and floor. The maintenance guy runs out to his truck and grabs a shop-vac to start suctioning the water out, I grab a metal mixing bowl and a five gallon bucket and start bailing (keep in mind the water is both hot and slightly acidic). Once we get the flood under control, he runs upstairs to ask the neighbors not to do anything else in their kitchens, then calls the night plumber – who can’t make it until midnight. Well, what can you do? He left the shop-vac with me in case of any other emergencies, and I waited up for the plumber. He came around midnight, as promised, and had the clog clear in about two minutes with the aid of his power auger. Turns out the clog was a combination of hair and mop fibers. I thanked him, he left, and I shut the cats out of the kitchen and went to bed.

Damage surveying started after work yesterday. The entire kitchen floor had a greasy film on it, as did the counters and anything sitting on the counters. I wiped down the floor, washed down the counters, and salvaged what I could, but the effects of greasy hot acid water on the [mostly plastic and metal] items sitting in my sink were not good. I ended up losing:

• Two knives, a boning knife and a chef’s knife
• A cutting board
• An herb shears (goddamn it, those were new)
• A collander
• A mixing bowl
• Basically everything that was in the sink that wasn’t glass

There are two upsides to this story. First, it makes me glad I live in an apartment, as I did not have to foot the bill for a plumber to come out in the dead of night to deal with this – the corollary being that I sure as hell did not wash hair and mop fibers down my own kitchen sink. Second, Linens ‘n’ Things is doing a huge going out of business sale, so I can probably replace much of what I lost at a low low price. Plus I wanted a new cutting board anyway. THE END.

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.

In yet another stunning display of how much better my new working environment is, I’ve gotten permission to keep a small fish tank on my desk. At first I was just going to keep a betta, but like usually happens, I’ve starting thinking bigger. I got Courtney a 12 gallon Eclipse for her birthday, and at that time I dragged out all my old equipment so I could give her supplies that I wasn’t using, such a big heater. Going through all that salt-encrusted hardware that I’d forgotten I owned got me yearning for keeping a saltwater tank again. At this point I was already planning on doing a tank at work, so I figured, why not get back into saltwater whole-hog?

Yesterday the new tank I’d ordered was delivered. It’s a 3 gallon Picotope, and it’s a pretty darn attractive tank in person, what with its curved front and all. Sadly, I won’t be able to reuse much of my old hardware, since this tank is significantly smaller than anything I’ve tried before. Thankfully that won’t be much of a problem. Reefkeeping technology has progressed in the last two years, and now they make wee tiny protein skimmers. Measurements given in a review on Reef Central indicates that would fit pretty well on the Picotope, and since they’re on sale for only $15, I ordered one on the theory that I wouldn’t be out much if it didn’t work for me. They make a wide range of wee tiny heaters too, which will be helpful since an office environment is not usually kept at the optimal 80 degrees of a reef tank.

So what am I going to do with this tank? I’m not sure quite yet, but I’ll definitely have time to think about it while I get all the hardware ordered and together. Reading threads on Reef Central has given me ideas for the tank layout, at least. The new trend is to hide all the hardware behind an overflow wall, which is a very attractive option if it’ll work with the size of the protein skimmer. If I go that route, I’ll have even more time to think about what to put in it, as this will require the cutting and painting and gluing of Plexiglass. Fun times ahead!