FsEye 2.0.1 Released

FsEye 2.0.1 has been released. It includes a couple high-priority bug fixes. Download is available here. Release notes are available here.

Note that VS 2013 / F# 3.1 Preview has a regression that requires unblocking the all the dlls included in the FsEye download in order to load correctly in FSI. I reported this bug to the F# development team back in June and they said they would look into getting it fixed before the final release.

In other unfortunate news, Google Code has announced that they will soon stop hosting projects downloads. Of course, we'll figure out some other way to host our downloads and link to them from a Wiki page or something.

I'm Only Resting 1.1.0 Released

I'm Only Resting (IOR) has been released! This is pretty significant in that it now uses Scintilla for rich text editing and syntax highlighting (and etc.). See the release notes for more.

Note that this release includes an unfortunate though fairly minor regression introduced by Scintilla's aggressive TextChanged event setting newly open files as dirty. See Issue 33.

One of the neat things about IOR, is how many open source libraries it incorporates. Looking at the license NOTICE, I count six so far!

Extending Scintilla with modifiable ContextMenu

Recently I've been working on using ScintillaNET in I'm Only Resting, namely as the text editor for the Response Body content. An early issue I ran into was that the Scintilla control does not allow access to or modification of the built-in context menu. However I was able to easily extend the Scintilla control with a hand-built ContextMenu that is exactly the same as the one built-in except it can be accessed and modified like any normal .NET control.

The code is as follows:

Groovy generator proof of concept

Many languages such as C#, F#, Python, etc. have syntax supporting the generation of sequences whose elements are computed on-demand (vs. e.g. arrays or lists, which hold all their elements in-memory). Such a feature is conspicuously missing from Groovy.

Let’s take F#, for example. The following is a simple F# sequence expression:

seq {
    yield 1
    yield 2
    yield! [3;4]
    yield 5
}

This expression creates an IEnumerable<int> which yields the elements 1 through 5 on-demand. If we wrap this expression in a Quotation and decompile it with Unquote, we can see its de-sugared form:

seq (Seq.delay (fun () -> Seq.append (Seq.singleton 1) (Seq.delay (fun () -> Seq.append (Seq.singleton 2) (Seq.delay (fun () -> Seq.append [3; 4] (Seq.delay (fun () -> Seq.singleton 5))))))))

Basically, what we get is a series a continuations, similar in concept to what monadic syntax gives in general in Haskell (and indeed, in F# too with the more general concept of computation expressions).

Understanding this, we realize that between standard Java Iterables, Groovy Closures (with a bit of dynamic delegation), and Groovy AST Transformations, we can have a similar generator syntax in Groovy.

First, we’ll implement a type Generator<E> implementing Iterable<E> which generates elements on-demand from a closure composed of nested continuations (no syntactic sugar yet, we’ll get there with AST Transformations later on):


With a static import for Generator.gen, we can create a Generator equivalent to our F# example like so:


First, notice that all of our calls to undefined yield and yieldAll methods are resolved via delegation to Generator yield and yieldAll methods (which return YieldResults, used internally by our Iterable impementation for keeping track of the next continuation). Starting from the root Closure supplied to gen, each call to Iterator.next() returns the first argument supplied to the yield or yieldAll method, saving the second continuation argument for the next next() call, continuing this way until a continuation which returns null ends iteration (with some look-ahead complexities accounted for to accommodate the hasNext() pattern, as well as some complexity flattening out elements supplied to yieldAll).

To demonstrate the on-demand nature of our generator, consider the following tests:


This is all well and good, but no one wants to write all those continuations by hand. We need some syntactic sugar here. This is where AST Transformations come in to play. We will write an AST Transformation which allows us to write our generator expressions like so:


We implement two AST Transformations: YieldTransformation, which de-sugars our generator closure, and GenTransformation, which extends YieldTransformation, constructing a Generator from the de-sugared generator closure:


Note that what we have here is indeed just a proof of concept: the YieldTransformation doesn’t yet handle if / then / else expressions for example (though those cases should be pretty straight forward having implemented the more difficult BlockStatement transformation).

It would be great to see a Generator feature like this brought natively to Groovy in the future (and without the need for AST Transformation, which requires the use of annotations on declaration expressions). The full power of on-demand generators like this become apparent when used in conjunction with on-demand Iterable transformation libraries such as Tim Yates' groovy-stream or my own Functional Java (yet to be ported for friendly use from Groovy).

Move svn history from one repository to a GoogleCode repository

I keep a private Assembla svn repository for little projects that I have going but don’t want to release to the public. However, on two occasions, those little projects have turned into big projects (Unquote and FsEye) which I wanted to move to open source GoogleCode repositories.  Both times I’ve used the following instructions to help me move the svn repositories to with full history intact: http://therightstuff.de/CommentView,guid,b984a8e7-e94d-4eed-a705-5dc479f959e8.aspx.

FsEye 2.0.0 beta 1 release!

I've just released FsEye 2.0.0 beta 1! This release features a plugin system I've been working on and should prove an exciting step forward for FsEye.

You can find the download at https://code.google.com/p/fseye/downloads/listand reference the documentation athttps://code.google.com/p/fseye/wiki/FsEye2Beta.

I'm eager to get feedback and see some great plugins developed!

(cross-post from my Google+ announcement)

Unquote 2.2.2 released!

Unquote 2.2.2 has been released! From the the release notes:

Make all custom exception types serializable so that they may pass AppDomain boundaries. Other minor fixes and enhancements.

Very happy I made the effort to document the release process recently, and it definitely helped speed things up and keep my confidence!

Visual Studio Extensions and Add-ins you can’t live without

The following is my list of Visual Studio (2010) Extensions and Add-ins “you can’t live without” (I will update this from time-to-time):

Engineering

• NuGet Package Manager
• AnkhSVN
• TestDriven.Net

Development

• Indent Guidelines (indispensible in F# coding)
• Go To Definition
• VSColorOutput

Unquote 2.2.0 release

Unquote 2.2.0 has been released. This release includes several enhancements around operator decompilation.

Visual Studio Build Output on first build in a newly opened instance

In both VS 2010 SP2 and VS 11 Beta, the first time you build a solution in a newly opened instance of Visual Studio, it will focus on the Output window, but fail to switch the output channel to Output like it usually does (i.e. “Show output from” drop  down list).

This has always bugged me, and has effected me often since usually the last action I would have performed since the last time I used Visual Studio would be the run all my automated tests, so the Output window channel is persisted to Test in newly opened instances.

The solution is simply to toggle the “Show output from” option manually while the build is executing. Sounds too obvious to be worth mention, but the fact is, I never even noticed that drop down list because I am so used to it setting itself automatically in most cases.

Remapping Lenova Keys

At work, I have a new Lenova T420 laptop which has a different keyboard layout than my wonderful Dell XPS 15z and it’s been driving me nuts. Specifically two issues

1. The Ctrl and Fn keys are flipped
2. The Fn+<arrow key> map to media buttons instead of Page Up, Page Down, Home, and End.

Apparently Lenova’s are infamous for #1, so much so that they added a special BIOS setting to go ahead and flip them (apparently Fn is a very special key which isn’t recognized by the OS and needs to be done at this low level)! So just go ahead and restart your computer, and press F12 at the opportunity, and hunt it down in the BIOS settings.

#2 was easily done using using KeyTweak. Note that while you can’t technically remap or create new Fn+<other key> combinations, you can remapped the media keys, which is effectively the same here.

Now I am happy, and I think I fixed the issue early enough that my wires aren’t too crossed.  

Odd br tags being inserted before and after VSPaste code when submitting blog post from Windows Live Writer 2011 to Blogger

The title says it all. I’m not sure if this is a problem with Windows Live Writer 2011 or Blogger, but I think it is Blogger’s issue because when I view source in WLW, it doesn’t show the breaks, they only appear after submission to Blogger. Indeed, I’ve been struggling against Google’s recent changes to Blogger, such as difficulties using my custom blog template I create for Project Euler for F#un to this, newer blog (I mean, sheesh, I only created the thing two years ago, would hope it wouldn’t obsolete ever, let alone so soon!).

Anyway, the solution was to edit the blog post through Blogger’s online editing tools, and remove the br tags from the source edit view there.

Quick way to convert a space delimited list to a literal F# data structure

Today, while working on this Unquote issue, I needed to create a literal set of reserved words from a space delimited list found in the F# 2.0 specification. Thanks to the F# interactive and it’s printer, I didn’t need to manually create the literal set by laboriously inserting quotations around each word.

First, I copied and pasted the list of words from the specification into a .fs file and easily made it into a literal multi-line string. Taking care to add an extra space at the end of each line so that the last and first words of two consecutive lines didn’t run together when ultimately split.

let reservedWords = "\
    atomic break checked component const constraint constructor \
    continue eager fixed fori functor include \
    measure method mixin object parallel params process protected pure \
    recursive sealed tailcall trait virtual volatile"

I submitted that to FSI.

val reservedWords : string =
  "atomic break checked component const constraint constructor c"+[156 chars]

Then, in FSI, I set the fsi.PrintLength to 1000 so that I could see the complete list in the output and split by ‘ ‘ and converted to a set.

>  fsi.PrintLength <- 1000;;
val it : unit = ()

> reservedWords.Split(' ') |> set;;
val it : Set<string> =
  set
    ["atomic"; "break"; "checked"; "component"; "const"; "constraint";
     "constructor"; "continue"; "eager"; "fixed"; "fori"; "functor"; "include";
     "measure"; "method"; "mixin"; "object"; "parallel"; "params"; "process";
     "protected"; "pure"; "recursive"; "sealed"; "tailcall"; "trait";
     "virtual"; "volatile"]

You can see that the resulting FSI output is directly usable F# code completing my task.

Experimenting with precompiled regexes in Unquote

Today I spent some time experimenting with precompiled regexes in Unquote: https://unquote.googlecode.com/svn/branches/precompiled-regex. However, I was not able to show any measurable performance improvements from this work. Perhaps this was to be expected, considering Unquote only uses 5 compiled regexes currently and the upfront cost of compiling those on the fly must be small compared to the actual regex matching performed across all of Unquote’s nearly 500 unit tests (though Unquote uses a relatively small number of regexes, they are used frequently). So, for now, we’ll stick with normal compiled-on-the-fly regexes, unless we gain a large number of regexes in the future. But, it is worth noting the compiling on-the-fly does increase the performance of Unquote by 2x.

FsEye 1.0.1 released

FsEye 1.0.1 has been released. This is a maintenance release that only included a couple bug fixes (but critical if you wish to inspect any objects with setter only properties).

Unquote 2.1.1 released

After an 8-month break, a new version of Unquote has been released. This is mostly a maintenance release, but notable features and bug fixes include the addition of the raisesWith operator, and improved printing of function and None values. See the release notes for a full listing.

Note that the Unquote logo will not be visible on the NuGet gallery this release, due to a change in the way NuGet allows managing packages.

For myself and possible future developers, I’ve also updated the Unquote solution to use NuGet package reference wherever possible and enabled “NuGet package restore” on the solution so that packages don’t need to be committed to the source repository. However, solution level packages such as Statlight tools for running Silverlight tests don’t seem to be restoring. I’ll have to look into that later. For libraries such as NUnit Silverlight builds which don’t have NuGet packages, I’ve committed those to the source repository under a lib folder.

Convert Outlook formatted email addresses to Gmail format

Recently, I wanted to send an email from my personal Gmail account to a group of folks at my office. At the office, we use Outlook. So within Outlook, I entered all the email address in the “To” box and pressed “Check Names” to assert their validity and convert them into Outlook’s canonical format. I then copied and pasted those email address into the body of an email and sent it to my Gmail account for future use.

But alas, when it came time to send the email from my Gmail account to the Outlook formatted email addresses I had collected earlier, I got a send error due to Gmail’s inability to parse Outlook’s format. I had about 15 email addresses in the list, and decided it would be more fun to parse out the email addresses using a regex than to manually extract them.

Of course, I chose F# for the job, since, besides generally being my favorite go-to language, it is perfect for these quick interactive scripting scenarios. The following is the code snippet I came up with, which worked nicely as advertised.

open System.Text.RegularExpressions
let raw = @"John, Smith-Anderson <JohnS@Company.com>, Reg, Ex <RegE@Company.com>, Hello, World <HelloW@Company.com>"
let regx = new Regex(@"<([^<>]*)>")
let matches = regx.Matches(raw)

matches 
|> Seq.cast<Match>
|> Seq.map (fun m -> m.Groups.[1].Value)
|> String.concat "; "
//val it : string = "JohnS@Company.com; RegE@Company.com; HelloW@Company.com"

The Purpose

During my adventures in coding, I often solve problems worth remembering but not worth dedicating an entire blog or open source project to. Thus is the purpose of this blog.