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.
Tuesday, September 10, 2013
Friday, March 15, 2013
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!
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!
Wednesday, March 13, 2013
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:
The code is as follows:
Monday, February 18, 2013
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:
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:
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).
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).
Monday, August 27, 2012
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.
Friday, July 20, 2012
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)
Thursday, June 14, 2012
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!
Subscribe to:
Posts (Atom)