Lee Campbell

Cheers. As a C# dev this helped me understand the syntax (:: << etc) more than anything. Most of the rules seem quite similar to the C# rules which is nice.

Good work.

Thanks for the mention in (http://channel9.msdn.com/Shows/The-Defrag-Show/Defrag-PAE-SkyDrive-VHDs-Arsenal-of-Halo-4). I wasn't suggesting that you guys wasted my time, this was a while ago I tried to do it. The frustrating thing is that it only rejects the process at the very end of the process. Fail fast would have been appreciated 

Keep up the good work.

Lol, I love the Wallabies shirt.

All Black fan

VHD boot only seems to work on Win7 Ultimate. This seems to be a big secret, but I have wasted hours trying this when I only had Win 7 Pro.

Brilliant work Bart. I really like the perf improvement stuff you have done. It is cool to see a conceptual evolution from your MiniLinq concept to Rx v1 to the optimisations you are doing in v2 (eg Buffer/Merge/SelectMany/Either).

Call stack imrpvements are super welcome addition too. Are there any tricks that your operators do to know that they are part of a "safe" chain? ie that Select doesnt need to protect itself from Where, but potentially does from my own custom operator?

@genteldepp: http://leecampbell.blogspot.co.uk/2010/08/reactive-extensions-for-net.html has an introduction to Rx, but for V1. It is currently undergoing a total rewrite...hope to be out soon. Hope it helps.

I like the image of the 5 concepts of LINQ (Insert/Transform/Filter/Expand/Aggregate).

I would be great if you released this as a nice little poster

Are there any links to the document or image?

It would also be cool if there was a MiniLinq version that showed that we only need Insert/Expand/Aggregate (Ana/Bind/Cata) as Transform and Filter can both be performed with Bind/Expand/SelectMany

Lee

Ok instead of being part of the problem I thought I would put my 2c in.

Here is my post on Hot vs Cold Observables.

http://leecampbell.blogspot.com/2010/08/rx-part-7-hot-and-cold-observables.html

Hmmmmmm.....I believe that what has been implemented here is a step backwards from TDD.

In traditional TDD you write out your contract in human readable test names with human readable failure messages. When I go to read the unit tests for a class I can just collapse to definitions and just read the name of the tests. When the tests run and fail I can tell why. I imagine Zip2() is not a very helpful test name. Also I imagine maintaining the one large coupled Pex meta test method would be clumsy and easy to accidentally remove functionality.

I would have thought a bunch of test methods like:

[TestMethod] public void Zip_method_with_uneven_inputs_will_have_length_of_shortest_input() {....} [TestMethod] public void Zip_method_invokes_combinator_function_with_index_equilvalent_values_from_inputs() {....} [TestMethod] public
 void Zip_method_yields_combinator_function_result() {....}

still protects you from the implementation detail and is more explicit about the intention of the contract.

My $0.02

Lee