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.

Updating F# posts to 1.9.9.9 - part 1 : Before the October 2009 CTP

I've actually been fairly lucky about code changes (apart from probably being the only person on the planet affected by the change in the camel-casing of the NonPublicRepresentation enumeration flag -- which really means ImplementationArtefact) -- the only ones needed were in the very first posts, working with the September 2008 CTP (1.9.6.2), Map.mem, Set.mem, Set.to_list becoming Map.containsKey, Set.contains and Set.toList respectively. Everything else is bug-fix or implementation detail -- or updating the version number in the paths to F# components.

• September 2008 CTP (1.9.6.2) could not sub-class PSSnapin : resolved in May 2009 (1.9.6.16)
• Silverlight 2.0 integration is probably obsolete as we're coming up on Silverlight 4.0, but you might get away with changing the 1.9.6.2 version in the file path to 1.9.9.9 now.
• At some point after 1.9.6.16, the full paths to the .pdb symbol files have been included in assemblies, avoiding the need to use the nunit-console.exe /noshadow option when doing coverage analysis of unit tests.
• The representation of algebraic types has changed in subtle details since 1.9.6.16
• There have been changes in the release build code generation, but I have not tracked these in detail, being more interested in the debug build from a tooling point of view.

F# under the covers XI½ -- F# 1.9.9.9 changes everything

Well, I just tried building my code coverage static analyzer under the February CTP; and the first thing I get is that the attribute decorations for F# algebraic types have changed. In particular the SourceConstructFlags.NonpublicRepresentation enumeration value is no longer present as part of the SourceConstructFlags type.

So as part of the drive to update existing F# samples to the new release, I shall be revisiting my "under the covers" series as I update my code inspection to match the new release.

And when that's done, there'll be a 1.1 release of the toolset.

Later: A quick bit of Reflector on the subject, and we find that the name is now SourceConstructFlags.NonPublicRepresentation.

Later the same day: well, that's all the entries pre-Ocober 2009 CTP updated. Also note that the output window issue is still present in 1.9.9.9 VS integration.

Links for 10-Feb

Functional C# : Extracting higher order functions with generics.

Related : F# Changing one's C# coding style

Marking the .net 4 RC1 release on SmallestDotNet.

PoSH 2.0 -- the localized help files.

JQuery 1.4.x highlights

IronJS -- Ecmascript on the DLR

Web : Free small icons, SVG support overview, script free video embeds, and Windows 3.1 in DHTML!

No Disk -- \Device\harddisk3\dr3

Googlebait title for a problem I was having with NCover 1.5.8 on my main desktop machine at home over the weekend; whenever trying to run nUnit or FxCop inside NCover, they were raising one or many (respectively) dialog boxes with thie message.

Except if I was invoking this from an MSBuild step inside Visual Studio (either a post-build event or an AfterBuild target.

The internet was not very helpful, but the hints led me to Control Panel > Administrative Tools > Computer Management > Disk Management. There I could see that Disk 3 was one of the slots on the media reader -- the one with the slightly dodgy memory card from my old camera currently in it.

Pull the card, problem sorted.

I still don't know what filing system operation was looking at the drive to cause the error -- and more, why running inside Visual Studio fixed it.

F# October '09 & February '10 CTP and VS 2008 - output window glitch

I first noticed this when adding a simple post-build step through the project properties for running unit tests as part of the build inside Visual Studio -- the May '09 CTP echoed the data going to stdout just like with any other language; in October everything went black; and it remains that way at the February '10 CTP.

Subsequently I find that this also applies to other MSbuild targets. For example, take a completely new F# library project, and edit the .fsproj file to have the following AfterBuild target:

<Target Name="AfterBuild">
    <Error Text="Hello world" />
  </Target>

Reloading and rebuilding gives

------ Build started: Project: Library4, Configuration: Debug Any CPU ------
        C:\Program Files\FSharp-1.9.7.8\\bin\fsc.exe -o:obj\Debug\Library4.dll -g --debug:full --noframework --define:DEBUG --define:TRACE --optimize- --tailcalls- -r:"C:\Program Files\FSharp-1.9.7.8\\bin\FSharp.Core.dll" -r:C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll -r:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" -r:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll --target:library --warn:3 --warnaserror:76 --vserrors --utf8output --fullpaths --flaterrors Module1.fs
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

Using msbuild at a console, the output is shown

Project "C:\Users\Steve\Documents\Visual Studio 2008\Projects\Library4\Library4.fsproj" on node 0 (default targets).
  Processing 0 EDMX files.
  Finished processing 0 EDMX files.
CopyFilesToOutputDirectory:
  Copying file from "obj\Debug\Library4.dll" to "bin\Debug\Library4.dll".
  Library4 -> C:\Users\Steve\Documents\Visual Studio 2008\Projects\Library4\bin\Debug\Library4.dll
  Copying file from "obj\Debug\Library4.pdb" to "bin\Debug\Library4.pdb".
C:\Users\Steve\Documents\Visual Studio 2008\Projects\Library4\Library4.fsproj(51,5): error : Hello world
Done Building Project "C:\Users\Steve\Documents\Visual Studio 2008\Projects\Library4\Library4.fsproj" (default targets)
 -- FAILED.


Build FAILED.

On the up side -- messages emitted by the Error or Warning tasks (but not the Message task) do appear in the Error List tab; so you can get some feedback inside Visual Studio as to why your build failed, even if not all the realtime tracing you might be used to with other languages.

I suspect this may be as simple as a linker flag change to the VS plugin (all the plausibly relevant F# assemblies I've looked at in 1.9.7.8 are marked as GUI sub-system, and IIRC, VS plug-ins need to be Console -- i.e. to have a useful stdout).

“Hello Glade#” from IronPython

I was a little pessimistic yesterday about this operation -- but with a little sidestepping to use a different method on the Glade XML object, and a little bit of Python metaprogramming, we can actually get something much more general than the F# solution.

Same app as before

The trick here is in writing our own __getattr__ method that calls the name-to-widget look-up method of the Glade model, if we haven't already made a note of the object of that name. Written like this, the Handler class could be used in any IronPython/Glade# application.

Now I wonder whether there is a better way to do it in F# that can use generic typing, and not lose the elegance under the weight of type coercion operators.