Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Bart De Smet: Rx Update - .NET 4.5, Async, WinRT

Download

Right click “Save as…”

Bart De Smet has been very busy. As you can imagine, the latest release of Rx (v1.11011.11 (Experimental)) supports the latest (developer preview) .NET version, 4.5. In this release, Bart and company have forged a deeper synergy with the async/await Task-based asynchrony model (see Prefer Async Policy in the Release Notes for this release for more info and watch/listen to this conversation!). In addition, Rx can be used in "Windows 8" Metro style apps. Smiley

Rx v1.11011.11 (Experimental) features include:

Improved Exception Management

Prefer Async Policy

Interoperability with Task<T>

FromEventPattern Support for WinRT Events Various Changes to System.Reactive The New

System.Reactive.WindowsRuntime Assembly

This release of Rx includes support for WinRT interop and to build Metro style applications leveraging Rx for event processing

IAsyncInfo Conversions

Release Notes

Download

Tags:

Follow the Discussion

  • Dylan MeeusDylan Meeus

    Very nice!

  • felix9felix9 the cat that walked by itself

    Still no native Rx ? Devil

  • tonytony

    Bart please start a blogging about rx with js...

    tia

  • Robert BaardaRobert Baarda

    Where did you buy that shirt?

  • Charles, Rock NRoll is your thing, don't let anyone tell you otherwise!

    /Rock n' Roll!

    PS. listening to Bart is awesome!

  • JeffJeff

    This is awesome.

    I have a question, though: Since Task<T> is "the" abstraction for single-valued asynchrony, why not make IObservable's folding operators (Aggregate, First, Last, etc.) return a Task<T> instead of a single-valued IObservable<T>?

  • Maddus MattusMaddus Mattus Maddus on C9, Is often ​controversi​al, But fun ​none-the-​less -​evildictait​or

    Because you want to continue using observables,..

    If it would return Task<T> you would be stuck.

  • felix9felix9 the cat that walked by itself

    I think you should move those 'txt.Text = "<Stopped>"' statements out of the using block ...... no ?

    Update. oh, maybe even setting text.Text after Dispose() wont elimate the problem.

    I guess the scheduler or 'sync context' has a 'message queue' kinda thing, and if a 'txt.Text = Key' is already in the queue, unsubscribing or Dispose wont remove it from the queue, so it could be executed after <Stopped> and overwrite the txt.Text ? right ? Maybe the fact of you are subscribing to KeyDown events could help here since its in UI thread and message queue too, but what if you are observing something really 'async' ? Perplexed

  • @Maddus Mattus: Did you watch the video? Bart talks about how IObservable<T> and Task<T> live nicely together in the new version of Rx.

  • Adam SpeightAdam​Speight2008 The Bandito Coder

    Could the capabilities of Project Roslyn, assist in "magic" strings problems on events, by provide compile-time checking? or would it require a change to the lexer / parser.

  • Aaron StainbackAceHack AceHack

    I like "Rock n Roll"  Keep saying it! Smiley

  • Bart De Smetbdesmet Bart De Smet ​[MSFT::SQL::​Cloud​Programmabi​lity::Rx]

    @Jeff: While Task<T> would be a good fit for single-value asynchronous results coming out of the Rx APIs, there are a few things we don't want to get into.

    First of all, staying in IObservable<T> allows for further composition, which is very rich in the world of Rx. A typical example I always bring up is to apply the Timeout operator to the resulting sequence. With Task<T> you can do similar things using WhenAny or by using cancellation mechanisms, but it's less sexy.

    Secondly, by going to Task<T> there's an implicit change in scheduler affinity. Having the ability to control scheduling through the IScheduler abstraction and having a more free-threaded world is an advantage of Rx we don't want to loose due to implicit changes of primitives.

    Having said all of this, users can still go to a Task<T> object explicitly by using the ToTask operator. However, for the simple task (pun intended) of awaiting the result of such a single-valued observable sequence, support is right there in Rx to use "await" directly.

  • Bart De Smetbdesmet Bart De Smet ​[MSFT::SQL::​Cloud​Programmabi​lity::Rx]

    @felix9: The test code you saw on the screen is not flawless indeed. In general, it's possible for the sequence to produce an OnNext message before the Dispose call to the subscription occurs. The fix is quite simple though: use the Finally operator in Rx to run code after the sequence completes or gets disposed.

  • Bart De Smetbdesmet Bart De Smet ​[MSFT::SQL::​Cloud​Programmabi​lity::Rx]

    @AdamSpeight2008: Remains to be seen. Notice the trend of reducing magic strings in pretty much every recent release of the languages (e.g. LINQ instead of queries in strings, dynamic instead of invocation calls with member names in strings, call info attributes instead of hardcoding the current member's name, etc.).

    Personally, to reduce the event conversion friction I'd invest in a conversion of events to IObservable<T> like F# does, but at this point there are no such plans.

  • Allan LindqvistaL_ Kinect ftw

    cool stuff!

    i really wish anders will allow us to treat events like a normal multicast delegate properties, that way you could write extensions methods for things like rx on them Smiley

  • Guys,

    Do you plan to release a version of Rx built against the Portable Library Tools?

  • Bent Rasmussenexoteric stuck in a loop, for a while

    Some clever work going on there. I really like the new WinRT event model and how it fits hand in glove with Rx. And of course the new exception handling enhancements to Rx looks really great. A lot of goodies in the box.

    Rock 'n Roll !

  • @bdesmet: Thanks for the response, Bart.

    Seems like you had to pick between two slightly awkward choices: return a Task<T> and deal with the gaps and differences, or return an IObservable<T> that breaks the abstraction slightly.

    In a perfect world, I think Task<T> and IObservable<T> would have the exact same interfaces for the shared concepts that you mentioned. Given that they don't, though, the choice makes sense.

  • Bart De Smetbdesmet Bart De Smet ​[MSFT::SQL::​Cloud​Programmabi​lity::Rx]

    @ligAZ: We're actively working with the PLIB folks on making Rx portable. The main thing required is to have IObservable available in all supported platforms. At this point, we can't commit to a time frame, but we're on it Smiley.

  • Bart De Smetbdesmet Bart De Smet ​[MSFT::SQL::​Cloud​Programmabi​lity::Rx]

    @ninjeff: One thing that would help is to have Task implement IObservable. Given that any multi-value concept has the single-value case covered too, that'd be a good way to think about it. However, in the synchronous case, there's no such implicit conversion between a multi-value thing (e.g. an array) that happens to have a single value and its contents (an "unpack" operation). Rest assure we are (and will continue to be) thinking about co-evolution and co-existence...

  • Richard Anthony HeinRichard.Hein Stay on Target

    So this is what you couldn't talk about at Mix, isn't it Bart, otherwise you'd have been revealing WinRT.  Smiley  I was surprised to discover Wes has left the team.  He'll be missed. Sad  I wish him the best at his new venture.  I do wish you and Wes would blog again. 

    There must be something coming down the pipe related to Linq-to-Cloud, and NoSQL.  Can you tell us anything about that and how Rx relates?

     

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.