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

Comments

cdwatkins cdwatkins
  • E2E: Brian Beckman and Erik Meijer - Co/Contravariance in Physics and Programming, 2 of 3

    shouldnt this be like part 2 of 3?  after all they dont seem quite done at the end here.

  • Wes Dyer: Controlling Concurrency in Rx

    Well done, this is very nice.  Makes me really want to start using Rx more.

  • Channel 9 Live at PDC09: Ray Ozzie

    Ha ha, anyway, even at max its very muffled.  The first few seconds play fine, but then the rest of it is very low quality.

  • Channel 9 Live at PDC09: Ray Ozzie

    Ultra low sound ftl Sad.

  • C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 1 of 13

    You really shouldnt be enumerating the list twice (if you dont have to, like you dont in this case).  I converted my IEnumerable<IGrouping<bool,T>> to a nicer Dictionary<bool,IEnumerable<T>> with a usefull helper method.

     

     

    public static IEnumerable<T> QuickSort<T>(this IEnumerable<T> input) where T : IComparable<T>
    
    { 
                var first = input.FirstOrDefault();
                var result = (from current in input.Skip(1) 
                        group current by first.CompareTo(current) > 0 into grouping
    
                        select grouping).GroupIntoBool(); 
                        return !input.Any() ? Enumerable.Empty<T>() : 
                                result[false].QuickSort().Concat(input.Take(1)).Concat(result[true].QuickSort());
    
    } 
     
    public static Dictionary<bool,IEnumerable<T>> GroupIntoBool<T>(this IEnumerable<IGrouping<bool,T>> input)
    
    { 
                         return (from bools in new List<bool>() { true, false } 
                                     join grouping in input on bools equals grouping.Key into joinedgroup
    
                                     select new 
                                     {
                                           val = bools, 
                                           rest = joinedgroup.FirstOrDefault() ?? Enumerable.Empty<T>()
    
                                     }).ToDictionary(a => a.val, a => a.rest); 
    }
     

     

     

  • E2E: Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 2 of 2

    My guess unfortunately is they aren’t going to retrofit anything, at least initially.  We would be lucky to get the IObservable interface in the BCL (and not just as an extension), although this might happen in .NET 4.0.  If they actually went converted events to be IObservable’s they would break everyones code that depended on those events.  Even if they rewrote the compiler somehow so the event keyword now MEANS IObservable, a lot of code would break (think of the IL changes on a different language).  Ah well, the good thing is that at least all events can easily be converted into IObservable’s.

  • E2E: Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 2 of 2

    Well I think there would be some restrictions (on types that can be used and method calls), that could be passed to the server.  But look at what ..net ria services, what it does is it takes the IQueryable expression tree and serializes it directly and sends it off to the server.  IQueryable is just expression trees that havnt been compiled into a function that returns an IEnumerable yet.  I am sure they could have a simlar thing in IObservable that would have interfaces like  IRequestable Select<source,result>(this IRequestable , Expression<Func<source,result>> ).  I dont know quite what they would call it though.  IQueryable unforchantly derives from IEnumerable, but otherwise it would be identical in its signatures.  IQueryable assumes that something is going to serialize it to pass it to something else for proccessing.  In the case of observables you would be assuming something is going to serialize it to do the proccessing (filtering or other proccessing) remotely.  Maybe something like you can pass it up to the server and have it tell you when some specific row of a database table changes, or off to active directory to let you know when some user gets locked out.  All the server does is provide you with access to everything you have access to as one giant IObservable, and then the client can select (and filter) the type of events it wishes to listen to, and only those are sent down.

     

    Also intresting to think about this in terms of a UI framework.  Where the framework itself has one giant IObserable which sends a new value every time the mouses moves or keyboard is pressed, and it hands off to all its children .Where(...) verions of the giant IObserable that filter for just its selected area of the screen or currently selected child (which then wraps its children in another .Where).  In the end you dont need to even test do any hitbox testing or anything, everything just flows down stream.  I spose most UI frameworks like WPF already do this with thier visual tree's just invoking methods on a child of a known type (like UIElement), but when you look at the 100's of On... overrideable method calls, you got to wonder if filtering only what you need might be a better option.  Where they dont have to keep extending the base class to add additional method calls, and instead add new derived event types that return more specific infromation if you want that extra info.  Or say your a team like Microsoft Surface that has some specific type of "new" interaction events you want to pass to your children based on specific proprietary hardware.  In the current WPF, this is very hard/impossible (I think they derived thier own UIElement type and force all thier children had to derive from that to get the new events).

  • Kim Hamilton and Wes Dyer: Inside .NET Rx and IObservable/IObserver in the BCL (VS 2010)

    "sometimes we want to block while waiting on data/computations and sometimes we dont"

     

    well IEnumerable is basicly the creator of the object expressing you should (or must if you dont split off a diffrent thread), block while you wait for the result.  IObservable says you "may" block or not block as you wish.  The nice thing about IEnumerable is it expresses that the author doesnt expect it to take too long to get the next value, although even this kind of assumption can be broken slightly.  Look at Linq to Entities or Linq to SQL, both of these take a long time to get all thier values the first time.  Why should the program have to block while it waits for these to finish?  I think IEnumerable will still probably exist for some "in-memory" very quick things, that blocking doesnt really matter on, but I wish there was a better way for authors to express that they dont expect it to take long to get the values then use a totaly diffrent type.

     

    Basicly IEnumerable is sync with a method call to get the result, and IObserable is async with a callback to get the result.

  • Kim Hamilton and Wes Dyer: Inside .NET Rx and IObservable/IObserver in the BCL (VS 2010)

    I was thinking about the new IObservable interface.  At first I thought great, brilliant, amazing, revolutionary.  But then I thought about how you could take an IEnumerable and make it an IObservable, and the reverse.  For instance you can just block the MoveNext until the next event comes in, or you can just call getnext and then IObservable.OnNext(Current) to switch it the other way.  So in the end what makes IObservable any better or different?  Well the IEnumerable has a slight assumption that when you do a GetNext/Current it will be fairly fast(as it is synchronous), the IObservable makes no such assumption.  If you want to continue computation while you wait for the GetNext to finish you better do that on a different thread, so there is thread overhead.  In the end I would say that IObservable is STRICTLY better than IEnumerable.  Anything IEnumerable can do IObservable can do.  For instance: foreach(type a in IEnumerable){ write(a)} is the same as bool end=true;IObservable.Subscribe(a=>write(a),a=>throw a,()=>end=false;);while(end){};  I bet you could even have the same syntactic suger of the foreach work for IObservable.  The only difference is going the other way where the MoveNext blocks would need to be done on a separate thread so IEnumerable is never better (and sometimes worse) then IObserable.

     

    In the end why don’t you just convert ALL IEnumerable’s over to the IObservable pattern (as well as all events)? (I know that you have backwords compatibility issues with this, but other then that)

  • Kim Hamilton and Wes Dyer: Inside .NET Rx and IObservable/IObserver in the BCL (VS 2010)

    Well the Obserable.Return function doesnt just return any old IObserable.  The one it returns calls OnNext the moment after someone subscribes (as it doesnt need to wait, it already knows what it should return).