My MacBook Pro display started malfunctioning yesterday, exhibiting flickering vertical cyan stripes in all bright-white areas, and flickering red in pitch-black areas. This doesn’t go away on reboot, and happens on the laptop screen itself and not on external monitors. So probably a hardware failure.

I’ll get it repaired, of course, but in the meantime I have a workaround: I tweaked the color profile so that the brightest RGB values map to only 96.5% of the display’s full physical brightness, and the darkest to 3% instead of 0%. Works like a charm for me. If your machine is out of warranty, you might prefer this to an expensive repair job (assuming your display problem also affects only brightest-white and darkest-black areas).

Cons: this makes the display a little bit less bright and contrasty, and might cause color hue shifts perceptible to someone more chromatically delicate than me.

Here’s the tweaked color profile (no warranty implied, may eat your computer alive, I am not liable, etc.). To try it out:

1. download this file and put it in /Library/ColorSync/Profiles/Displays
2. open System Preferences → Displays → Color
3. select the “GulliHack” display profile

If the above steps do not seem easy to you, get someone technically minded to help.

How I made this (for the technically minded):

1. Download remapcolorprofile.py. This reads a hex dump of a brightness curve as expressed in ICC files, snips off the top end of the curve, and linearly interpolates the remainder to the original number of values, maintaining its overall shape.
2. In /Library/ColorSync/Profiles/Displays, find the default color profile for your laptop screen (on my machine the filename is Color LCD-00000610-0000-A005-0000-000004280140.icc on my machine) and copy it to another file.
3. Open that file in a hex editor, such as 0xED.
4. Find the token vcgt (0x76636774) in this file. It appears in two places; go to the second (for me it was at offset 0x0A88).
5. 18 bytes on from that, find a 512-byte long sequence of two-byte words, starting with 0x0000 and ending with 0xFFFF. Select that (make sure you got exactly 512 bytes; bottom right of the window should show “Selection: 200”) and copy.
6. Run this in a terminal: pbpaste | python remapcolorprofile.py 0.03 0.965 | pbcopy (your particular problem may call for a different proportion; I tried a few and 3% and 96.5% were just right for my problem).
7. Go back to your hex editor and paste (making sure the “Write Mode” is “Overwrite”, not “Insert”). Make sure the length didn’t change.
8. Do the same for the next two 512-byte sequences (there’s one sequence for each primary color).
9. Save, and try out the color profile.

„Process applications faster and store more data with 256MB internal ROM …“

project.ioni.st.m3u

(Yes, this will stay up-to-date.)

Under (the free-of-charge and open-source) Subversion, that would have been “Sure, here you go.”

Under (the $3,000 proprietary) Team Foundation Server, it is “be thankful I’m letting you work at all. And when you get online, go download a separate utility and ask it politely to sort out which files you have changed.”

And here I was trying to break the rant habit. Dagnabbit!

1. never reinvent the wheel.
2. always break the rules.

So I guess this was only a matter of time. Presenting: TheWheel™.

Ayende.

2.07 posts a day on average over the last three years, mostly high-value software stuff. At the same time, he spews out useful, robust software. That’s all on top of his day job. And apparently he reads a lot.

Personally I suspect Ayende is a five-person software company masquerading as a single person. Even then he is not doing too badly.

The obvious question: how does he do this?

The useful question: why aren’t you doing it?

(Ouch.)

In·shaʾ·Allah·tion (ĭn’shä-lä’shən)

n.

A software installation/upgrade performed as a leap of faith in the irrational hope that it might make things less terrible.

[From Arabic in šaʾ Allāh (إن شاء الله), “God willing”]

"sgen.exe" exited with code 1.

The same project was building just fine on developer machines.

Googling the failure message turned up some pages suggesting a sledgehammer fix: disable “Generate Serialization Assembly” in the project file. But disabling something that may be valuable seems a little drastic just to appease a finicky build machine.

A better approach starts (as it always does) with getting more information about the failure. In TeamCity’s “All messages” view:

- This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

If you would like more help, please type "sgen /?".
"sgen.exe" exited with code 1.

This yields the eminently googleable HRESULT 0x800736B1, which led to a couple of pages pinpointing the problem:

• the project references a DLL that depends on the C++ runtime library
• sgen.exe needs to load referenced DLLs
• loading a C++ DLL causes it to load the C++ runtime
• The C++ runtime exists on my machine because it has Visual Studio installed; the build machine doesn’t.

Solution: install vcredist_x86. The build is now fine.

I’m quite excited about TeamCity; go check out their early access program!

Suddenly my MSBuild fails because somebody deleted Reference.cs and there’s only a Reference.map in the Web References\LT folder.

So I try changing the reference’s URL Behavior from Dynamic to Static (just to make any change, to see if Visual Studio regenerates Reference.cs). That yields the error dialog pictured here.

Pop quiz, hotshot: what is the difference between OK and Cancel in this dialog?

None, apparently. I click OK and the property does change to Static. When I repeat the experiment, this time clicking Cancel, the property also changes to Static. Don’t know what else might be happening behind this error dialog …

… and that’s exactly the point. Where, pray tell, should I go to troubleshoot this error?

Well, silly, I’m a tech guy. I should figure it out for myself, rather than expect my tools to make it easy to find. Which brings me to my next question …

… how much did we pay for this IDE again?

public double AndCastYeHimIntoAnInt(object o)
{
    return (int) (o ?? 0);
}

It works as you would expect; returns 0.0 (implicitly cast from the integer 0).

But we like our casts explicit, so now try this:

public double AndCastYeHimIntoADouble(object o)
{
    return (double) (o ?? 0);
}

Woe is me; this fails with an InvalidCastException saying “Specified cast is not valid.”

But heavens, surely the integer zero can be cast to a double? For verily, (double)0 works just fine, and a debugger verifies that that (o ?? 0) indeed evaluates to the integer 0.

But put a watch on (double) (o ?? 0) and quoth the debugger: “Cannot unbox 'o ?? 0' as a 'double'”.

And lo, lift up now thine eyes and place a watch on (o ?? 0).GetType() and it shall prove to be the struct type System.Int32, a boxed integer, and that cannot be cast to a double.

It is a boxed integer unto the LORD, because the compile-time type of the expression must be object, the only type to which both object and int have an implicit conversion.

But why does a boxed integer not convert to Judaism double in the obvious way, by unboxing to int and then implicitly converting to double? Probably because supporting that would require extra work at runtime for every unboxing conversion.

With few exceptions, value-type boxing can be ignored. This is one of those exceptions.

What’s by design, exactly? Here are the actual and expected results from my bug report:

Actual Results

A dialog box saying “Specified cast is not valid” with an OK button, displayed three times, and then information lost about control instances within the form.

Expected Results

A clear, specific indication of the invalid typecast problem encountered while saving the form. And minimal information loss when the form is saved anyway.

So it is “by design” that instead of a clear, specific indication of the problem, we get a dialog box with only the exception message, and not even a mention that this message is coming from our own code? Just a quick and cheap MessageBox.Show(ex.Message) and their work is done?

Here is Microsoft’s exact response:

I’m afraid this is largely a byproduct of the way in which the windows forms designer works. It is setting the properties on a live object. If this object throws an exception, the designer has the choice of either letting the object throw (which would crash Visual Studio) or catching the exception. When it catches the exception, it displays the Message from the exception. The message you’re describing is the typical one for invalid cast. Hooking up a debugger will find what line the exception happens on, which would make it easy to see what the exact issue is (not just type information, but values, state, etc.)

UIFX Team

This misses the point completely.

I know full well that the designer works on live objects, and that bugs in controls therefore must cause problems. My complaint is about how those problems are handled, not that they come up. What’s “by design” is that they come up, sure. How they are handled is not “by design” (we should hope!) — it is a real usability issue that remains to be resolved. But Microsoft just shrugs it off, “you can attach a debugger to help find it.”

My point is that the exception they catch contains valuable information about the problem (the stack trace), and they do not give it to us.

Should we be grateful that at least we get a line number on compiler errors, without having to attach a debugger?

This product desperately needs competition.

Eerie. This designer thing seems to know when I’m under schedule pressure and pull out all its tricks.

Now I get “Error HRESULT E_FAIL has been returned from a call to a COM component.”

Never seen this before, don’t know what it means, don’t know what caused it, and don’t know how to find out.

Yes, my changes were lost.
No, I couldn’t repeat it by making (what I believe to be) the same changes again.
Yes, I’m happy about being able to make the changes after all.
No, I’m not happy about having no idea when this will happen again, or whether it might happen at runtime.

public double DoubleValue
{
    get { return (double)NestedControl.EditValue; }
    set { Control.EditValue = value; }
}

where NestedControl.EditValue is of type object. Yeah, that’s careless handling of a possible typecast. But c’est la vie, sometimes that’s what you have, and you don’t know it, and that control is used in somebody else’s form that you’ve never seen before, and you are editing that form with the Windows Forms designer.

The designer will work merrily until you close it and say “yes, save for me please.” At this point it will present you with a dialog box saying simply “Specified cast is not valid” and inviting you to misrepresent your feelings by clicking “OK.”

When you do, it will give you the same dialog box again. You will click “OK” again, even less truthfully. And you will get that dialog box once again.

After the third time, tender mercies: the designer lets you off the hook and closes, saving your form. Phew, you think, maybe that wasn’t so bad. That’s until you discover that the designer has thrown out all the information associated with the problematic control instance, its name, text, tooltip text, sizing information, everything.

When you set out to find the cause of the problem, what do you have to go on? “Specified cast is not valid.” And which control instances got messed up. There may be dozens of them, with dozens of properties each. Happy hunting.

The lesson: when I write a tool for developers, and do it under a schedule crunch, and write a catch-all handler to display unanticipated errors … I pledge to include whatever specific contextual information I can. At least the exception stack trace. Surely that’s the least I could do.

And here I was determined to start taking a more positive tack in my tech blog. Dear me.

My impressions are as follows:

The triviality

They wrote a nine-page specification complete with “Microsoft Corporation Technical Documentation License Agreement (Standard)” and stamp of approval from Microsoft Law And Corporate Affairs and table of contents and overview and context and definitions and appeal-to-stereotype Elvis arguments …

… for a drop-shadow and rounded corners and no other changes?

And thought it would be a good idea to post it publicly?

The specious claims

“[the splash screen] is no less critical than any other part of the Visual Studio User Experience.”

They lost me right there on the front page. Let me rephrase this statement while retaining the precise meaning:

“There is no part of the Visual Studio User Experience that is more critical than the splash screen.”

Gee, I could have sworn there were a couple.

We don’t even interact with this thing. It’s not a User Experience, it’s a Viewer Experience. And that’s if we even bother to View it, instead of fetching a cup of coffee while Visual Studio loads, or starting it with /nosplash.

How could it possibly be as critical as any other part of the User Experience?

This is the kind of text that comes out when you are thinking “what would sound impressive here?” instead of “what’s the plain and useful truth here?”

“The Splash Screen typifies some of the worst aspects of the Visual Studio User Experience.”

No no no. The worst aspects of said User Experience are, unsurprisingly, things we Use. Such as:

• tiny fixed-size dialog boxes around huge tabular data.
• A source control client that blocks the entire IDE while waiting for the server, and hangs on Cancel.
• A source control system that takes 38 blocking seconds to rename a file.
• A GUI designer that chokes on buggy nested controls with cryptic error messages.

It’s OK to exaggerate the importance of your work in order to motivate yourself. But don’t go overboard.

The singularly clueless marketing stereotype banter

When Elvis first heard about Visual Studio Orcas being released, he wasn’t convinced that it was worth upgrading to, especially since he felt as though he had just purchased a copy of Visual Studio 2005.

So, like any frugal developer, Elvis went and downloaded a trial copy of Orcas to test drive.

Elvis could see that Visual Studio Orcas was new and different from the moment he started the application. The changes in the Splash Screen suggested to him immediately that this release was, indeed, different.

Well, wasn’t that a nice story.

Really, this Mort-and-Elvis stuff has to go. It pains me to see dinky little stories of these contrived stereotypes masquerading as product marketing wisdom.

The inattention

Chapter 6, “Feature Decisions / Q&A” is not just blank; it consists entirely of the placeholder text from the document template: “Include a quick description [...] describe decisions and rationale here [...] We will do so and so”

This is the document equivalent of:

/// <summary>
/// Insert summary description here
/// </summary>
public class Class1
{
    /// <summary>
    /// Construct a new Class1 instance.
    /// </summary>
    public Class1()
    {
        // Add initialization code here
    }
}

Do we post this kind of code for public review? For private review? Do we even check it in?

The implied background

One can’t help wondering whether this spec gives a glimpse of some contorted in-house dynamic, where people have to participate in a ritual Product Marketing dance by writing a Mort or Elvis “scenario” for every feature spec, and inflating the importance of their work with baseless hyperbole.

It sounds like the FeatureSpec.dot document template contained the placeholder text “Insert scenario involving Mort and Elvis here,” as a hoop for each feature spec writer to jump through.

It may not really be that way, but we’re talking impressions here.

Summary

Why did nobody’s nonsense detector go wild and prevent this embarrassment from publication? The splash screen improvements themselves are nice and understated, and should have been put in place without a word.

is called Tupper’s self-referential formula. If you graph it over particular values of x and y, it makes a picture of itself, and that is quite neat. Follow the link for details.

And this is a property of the unit impulse:

But that’s not really the point. The point is the mathematical notation; you can integrate mathematical notation in your WordPress blog very easily, using Steve Mayer’s LatexRender plugin.

And the point here is that you can install that plugin even more easily and correct a nasty bug in the offset beta functionality, using my LatexRender installation script (or the BSD version).

Go to the wp-content/plugins subdirectory of your WordPress installation, and then either:

wget http://fugato.net/wp-content/install-latexrender.bash
bash install-latexrender.bash

or, if your webserver is running BSD (or anything with the same kooky version of sed as my hosting provider’s BSD installation):

wget http://fugato.net/wp-content/install-latexrender.bsd.bash
bash install-latexrender.bsd.bash

and with any luck, the script will set everything up right. Then you’ll just need to activate the plugin LatexRender in your WordPress admin panel, and try it out by putting something like [tex]e^{i\pi}=-1[/tex] in a blog entry. That should render the classic .

This is tested working fine in WordPress versions 2.0 through 2.5.1 (the current stable version, which this blog is running).

The script assumes that your blog is located at the root of your website. If it isn’t, then you must provide the base path as an argument to the script. E.g. if your blog is at http://o.com/all/ye/faithful/, then you must run the script like this:

bash install-latexrender.bash /all/ye/faithful

and it should work right.

Some formulas may be slightly misaligned with the text baseline. You can work around this by manually surrounding them with stuff like <span style="vertical-align: -0.5px;"> ... </span> on a case-by-case basis (assuming you edit your blog entries in straight HTML, not the rich text editor).