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


BitFlipper BitFlipper
  • Too much gloom here lately, even for my taste ;-)

    , PerfectPhase wrote


    Yep, they said while you should use the aync methods as a default, they are putting back no-async methods to make porting easier.  Same with Ex methods, they're adding non-Ex versions back for back compat.

    I watched the video and it is good news that they are putting non-async methods back.

    However I don't buy the part that it was done to help with backwards compatibility. That is just BS. You can convert any async/await into a sync function by simply adding ".Result" to the end. Much more likely is that someone woke up and noticed the significant overhead it adds.

  • Windows 10 (metro?) is butt-ugly

    , Jim Young wrote


    ^^ This

    Wow, do you people really think the amount of complaining and backlash is par for the course? WAKE UP!

  • Windows 10 (metro?) is butt-ugly

    , kettch wrote

    Who wants to start a pool on what the next gripe thread will be? We've covered updates and icons. I'll go for the default desktop background next.

    I'm not going to start a thread myself, but I'd imagine it would be about something else that is now broken/fubarred/uglified/dumbed down in Windows. Some people work all day in Windows, so this is important for those people.

    It's interesting how some people just want to stick their fingers in their ears and ignore negative feedback. Negative feedback is still feedback, and if the negative feedback keeps growing and it keeps being ignored then this can't possibly end well for anyone. Believe it or not, I think most of the people complaining want Windows to succeed.

    But OK fine, let's all sing along now... "lalalalala...."

  • Too much gloom here lately, even for my taste ;-)

    Async/await is definitely a nice construct, but it really shouldn't be forced into everything. It solves UI/web/database problems for people that don't know how to code, but causes other problems if forced into places it should not be in.

    Briefly, the problem I have is that it was forced into the storage APIs for WinRT, meaning there is no non-async/await way to read a file. You have StorageFile.ReadAsync, but not StorageFile.Read. As my performance tests clearly show, this has a huge impact on IO performance.

  • Too much gloom here lately, even for my taste ;-)

    , wkempf wrote


    I'm suspicious of claims that async/await slows your application down....

    You no longer need to be suspicious: Here, starting around page 4, I posted benchmark code that shows how async/await kills performance. You are more than welcome to run the code yourself and then either explain how those benchmarks are flawed, or accept that async/await has a significant effect on performance.

    "Async all the way down" is only best practice if all your application does is some UI updating, not if you actually want to do something that requires real performance.

  • Windows 10 (metro?) is butt-ugly


    I guess complaining about something you used to love that is now degrading into a cringeworthy pile of bile qualifies as trolling these days.

  • Windows 10 (metro?) is butt-ugly

    I think in 20 years from now we will point and laugh at this failed experiment. Kinda like we do with MS BoB. One of two things would have happened by then:

    1. MS became irrelevant and another company is ruling the desktop.
    2. Someone with enough power at MS got a clue and replaced whatever there is now with some real leaders.
  • Google Surface

    The YouTube link seems to be broken.

  • Why can you do this with Java but not with C#?

    You might be able to do this with a VS plugin. The plugin would do something like this:

    1. Detect when the user wants to compile new changes (maybe via a special "Compile" button that the plugin provides).
    2. Put a temporary breakpoint at the 1st line that was modified (it keeps track of changes in documents).
    3. Once stopped in the debugger, remove the temp breakpoint and issue a Run, which will use E&C to compile and then run the program again.

    The biggest problem, which may not be surmountable, would be to allow edits to be made while the application is running. VS prevents edits from being made while running, but maybe there is a way for the plugin to make the current document editable, not sure.

    Of course the other problem is that E&C doesn't support 64 bit code, not sure when/if that will be fixed.

  • Why can you do this with Java but not with C#?

    It's pretty cool but how many times would this really useful in a real world case?

    Edit & Continue is the closest thing we have but that doesn't (yet) work for 64-bit code. Not quite as slick, but putting a breakpoint and then changing the code while stopped in the debugger is not that far behind what the demo shows.

    Plus, I would say the cases where this kind of stuff is useful is where it takes a long time to get the app into a particular state so that it even executes the code you are working on. At that point, not having to stop the code when changing it doesn't add a whole lot. Plus this would only work if the code is executed repeatedly.

    The way I usually use E&C is to break at the start of the method, make the changes, then run to the breakpoint after the code that got changed (or just single-step through it). If it still doesn't do what I want, I just move the execution point back to the start of the method, make some more changes and repeat the process. I've used this technique to flesh out a full method starting with an empty method. So what the demo shows won't help much for those use cases unless the code is running in a loop.

    Still cool though.

    EDIT: In fact I think there is an advantage in breaking into the debugger first in that you can see the values of the relevant variables.

    Not to go too far off topic but I think it is somewhat relevant... A while back I was working on a VS plugin that gave you a "Live Watch" window. So just like the current Watch window, you can add variables to it while in the debugger. But when you run the program again, the Live Watch window would give you the current value of the variables you added. It is useful to keep an eye on various variables as your program runs, to see what happens over time or how some interactions cause variables to change. It actually ended up working quite well, but like so many other pet projects, when I got to the 90% completion point, I kinda lost interest.