Out like a lion...

For the last week it has been mild, and often dry -- so that the daffodils and forsythia have all suddenly burst into bloom; and the weeds are going mad in the garden. But the forecast is for colder, wet and much windier weather running up to Easter.

I took the day off today to use up some carry-over leave, and to take the new wheelchair-accessible car for a spin to take Karen out to lunch; but not a long run -- so went to the Golden Ball at Boxworth, one of the usual pub-lunch haunts from work. I'm sure the process of doing all the belts, buckles, brakes, gears, etc. will get smoother with practise. And I got a bit of unexpected manoeuvring practise when heading to Knapwell, finding the road blocked with a police car and an ambulance, so having to make a 3-point turn in a very narrow lane. Still, that was all gone on the way back, and we could enjoy the vast display of daffs along the verges through the village.

Although a frequent from-work place, I'd expected that Monday would avoid the risk of running into colleagues. So imagine my surprise when the first faces I spotted as I walked through the door were they! Still, we didn't have to rush off quickly to get back for meetings at 2pm.

Restoring CompressedFolder opening for zip files

Having gotten to the point of being annoyed by the way that WinZip overwrote the association, I finally crawled around the web to find a way to restore the CompressedFolder functionality as a more convenient method for reading, even if I want finer control for writing.

Most places talking about this are mildly dodgy, want to have you drop massive slabs of stuff into your registry or say "re-install your OS". Fortunately it's easier than that.

Run regedit, and go to HKEY_CLASSES_ROOT\.zip and change the (Default) value to CompressedFolder. That restores Explore as the default option, which was what I was after.

How-To : IronPython and callback delegates with 'out' or 'ref' parameters

Following up on the earlier post, having found time to engage the brain a little...

Let's do the int flavoured version, everything non-default:

and then in IronPython ask the variable about itself

Now we get

>"\Program Files\IronPython 2.6\ipy.exe" callback.py
<type 'StrongBox[int]'>
['Equals', 'GetHashCode', 'GetType', 'MemberwiseClone', 'ReferenceEquals', 'ToSt
ring', 'Value', '__class__', '__delattr__', '__doc__', '__format__', '__getattri
bute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__re
pr__', '__setattr__', '__str__', '__subclasshook__']
Array[object]((<System.IntPtr object at 0x000000000000002B [42]>, 17))

That Value member looks interesting, so...

which gives us

>"\Program Files\IronPython 2.6\ipy.exe" callback.py
Array[object]((<System.IntPtr object at 0x000000000000002B [42]>, 23))

which is what we were looking for.

Rebuilding the C# assembly with out rather than ref and re-instating the print lines shows that the argument is still passed as a StrongBox, so there is no change on the IronPython side.

Armed with this piece of knowledge about the type, I tried Googling again, and didn't find any obvious mentions of callbacks -- just the converse matter of calling .Net methods that take out or ref parameters. But that at least is enough to reassure me that this is not just some completely undocumented hack that would be subject to change in later versions.

Note also that if I had written

print x.GetType().ToString()

(which is what I did the first time around) rather than

print type(x)

I would have gotten the result System.Int32, which gives no clue that adding

print dir(x)

is at all something worth doing.

Links for March

Programmatically detecting screen-readers.

SSL Man-in-the-Middle certificates.

.net 4:

• Changes to events.
• Workflow migration tool.

Reactive Framework:

• Drag and Drop using Rx and WPF in F#.
• Introduction in Javascript.
• JQuery integration.

Continuation passing in C#.

A fluent wrapper for System.IO.File/Path/Directory types.

TypeMock test lint.

Spring

Cycled to work again on Friday -- and then a high-speed blitz into town for a short notice appointment early afternoon. So, the tooth with a cracked filling that had been playing me up for the last few weeks is now patched until the proper fix in May.

And next week is looking plausible for more cycling.

Mowed the lawn, what there is that isn't moss, and did some spring pruning, enough to fill up the green bin, before settling. And potted up some chilli seedlings and put them into a heated propagator in the greenhouse.

Milestones

Only 35,932 this year or 5228 miles. Now some of that will be due to not having gone to the gym over the winter because of other commitments and some due to being snowed in a lot more or otherwise working from home. And probably rather more cycling

Spring

Suddenly a spell of mild dry weather -- Saturday, cycling into town for the first time in some weeks, and to the garden centre to pick up some supplies; and having my other gear cable snap while on off-road bridleway. So a bit of pushing as being stuck in top was not suited to the terrain.

Fumigated the greenhouse overnight, and then did bicycle repair -- much easier the second time around -- and put everything back on Sunday. That was warm enough to work up a bit of a sweat -- but in the greenhouse is cheating.

And today, cycled to work for the first time since mid-October; then had that first real day of T-shirt weather -- although a lot of people were still muffled up. Mild enough this evening that the central heating suddenly went from just keeping the chill off to being rather too much!

IronPython, WPF, and button-free windows

So, how do we achieve something like this with WPF, using IronPython?

Assume Vista or later (if you want to support XP, do something different if System.Environment.OSVersion.Version.Major < 6)

Start with some XAML

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window2" Height="300" Width="400" MinWidth="400" MinHeight="100"  WindowStyle="None" AllowsTransparency="True">
    <Grid>
        <Grid Name="banner">
            <Image Name="icon" Stretch="Fill" HorizontalAlignment="Left" VerticalAlignment="Top" Width="20" Height="20" Margin="4,4,0,0" />
            <Label Height="28" Name="title" VerticalAlignment="Top" Background="WhiteSmoke" Margin="28,0,0,0">Label</Label>
        </Grid>
        <StackPanel Margin="0,28,0,0" Name="body" VerticalAlignment="Top" Height="230">
            <TextBlock Height="100" Name="message" VerticalAlignment="Top" />
            <Image Name="image" Stretch="None" Height="130" Width="400" />
        </StackPanel>
        <StackPanel Name="buttons" Height="55" VerticalAlignment="Bottom" Orientation="Horizontal">
            <!-- Button Height="23" Name="button1" Width="75" Margin="2">Button</Button -->
        </StackPanel>
    </Grid>
</Window>

We can then use ctypes to get at the glass APIs, and set up some re-usable types

which we can then hook into our window (assume we have loaded the XAML into a variable window)

Of course you now need to ensure you have some button or other control that will let you dismiss the window, now you no longer have the kiss of death available at top right.

The ref parameter in the WndProc hook is the reason behind the previous post...

IronPython and callback delegates with 'out' or 'ref' parameters -- the obvious way doesn't work

The actual how-to is given here.

The only on-line documentation I could find that mentioned this has a

TODO - Delegates with out/ref parameters

about halfway down.

So, experiment time. Build callback.dll containing (or the same with 'out'):

and call it from IronPython 2.6:

which yields

Array[object]((<System.IntPtr object at 0x000000000000002B [42]>, False))

In sum -- it fails silently; the direct return value is fine, but mutating the actually by-value parameter does nothing.

Replacing the bool with int, and using non-default values shows that the value of a ref parameter is passed in correctly, it just can't be passed out with direct assignment.

Hints of Spring

Last Sunday, after a snowy start, mild sunny weather in the afternoon got me out in the garden clearing out more dead foliage, and spotting this season's weeds starting to emerge. Also cleared the tomato and chilli plants from the greenhouse -- the last few tomatoes hadn't ripened, but there was almost a pound of chillies in various colours from green, through purple to orange and red.

More snow Monday and Tuesday, but milder today, if wet.

A net.acquaintance visited, so I'd taken the day off work to play tour-guide, and the weather meant that he got a tour of Cambridge in the rain, lunch at the Crown and Punchbowl in Horningsea, and an impromptu jaunt out to Ely, when sun suddenly burst through the clouds. There it was mild and bright enough not to need the rain-sodden jackets from the morning.

So, despite the damp start, the promise of spring weather put the finishing touches on an enjoyable day of pontification and geekery.

Meaningless Patterns

In recent weeks, I have looked at the odometer in my car after parking at home in the evening and spotted 35200, 35300, 35500 and, today, 35600.

It almost feels like cheating...

I've been noodling about in the last few days, with a view to eventually porting some 'C' code from last century to .net by incremental replacement; something I tried and gave up as too horrible some years (back when we only had Managed C++ on .net).

In the interim, of course, F# has arrived on the scene, so what I'm trying is to replace from the substrate up with that language; and unlike last time, I'm not trying a Big Bang approach to the translation.

Having renamed all the .c files as .cpp, getting a first building assembly was simple, and then making it refer to an initially empty F# library, no problem; and then setting up an (again, initially empty) unit test assembly depending on both (where vice-tests to match up new and old implementations, and their eventual unit test replacements can accumulate), just as normal.

And then the magic starts to happen. Code that looked like

can become

where

and accessed by replacing the CB_ prefix with cb_severity::; or

plus its other associated functions and header file become just

which is invoked in the old code as the simple drop-in replacement My::FSharp::Module::RandomByte().

And because it's C++/CLI I'm using, where I have 'C' structs, they can become .net structs accessed in the old code with stack semantics.

So far, the most painful bit -- which I've been skirting for the moment -- looks to be the transition from old multi-byte character set 'C' text to Unicode; which is a hit I'd have to take in moving to modern native C++ anyway.

Credit for some of the ease of transition is the Manning Press C++/CLI in Action book, especially for its treatment of mixed mode programming.

Links for 23-Feb

Martin Fowler on Version Control Tools.

PowerShell:

• Standard members property.
• MSBuild Task factory.

F#:

• Survival guide e-book.
• A simpler mailbox processor and agents.
• Structural typing constraints.

JavaScript Reactive Framework and Observables.

50 CSS+JavaScript techniques.

Ruby + Haskell.

Rake + Ant.

F# under the covers XII -- Reflector 6.0 decompilation to C#

A new Reflector release (6.0.0.918), and time to see whether it can approximate in C# some compiled F# code that the 5.1.6.0 version balked at.

The generated IEquatable.Compare method that couldn't be handled before now succeeds -- the section that had problems now resolves to

and it's not surprising that comparing not-greater-than-null might be an unexpected piece of IL.

However, when there is a problem with decompilation, the new version no longer provides the detail of which instruction it didn't like. So I don't know why this

raises an error report when trying to decompile to C# (or MC++ or VB); or why this

throws a NullPointerException while trying to report an error when asked to decompile it as C# (I was able to get an error report sent when asking for VB instead).

Dropping back to 5.1.6.0, both show the usual "invalid branching condition", and point to

(the former condition) and

respectively, on the path where we are short-circuiting, as in

where the last line here is the one that the decompilation faults on.

Updating F# posts to 1.9.9.9 - part 2 : October 2009 CTP

Post 1.9.7.8 there have been few changes to code generation, and most of them subtle -- or are places where I no longer remember what I was on about.

Headline issues are:

• Module member value initialization is now done in a way that no longer triggers FxCop warnings.
• You can now attribute getters and setters independently.
• The compiler generated classes that wrap funs are now members of the containing class, not classes at the same top level -- MyClass.Member@### rather than MyClass+Member@###.

Possibly a few more issues will come out as I reconstitute my analysis tool, which is currently undergoing a retooling of its build system to automate some of the manual checks for whether the operational tests succeeded or not.