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

Discussions

Richard Anthony Hein Richard.Hein Stay on Target
  • Visual Studio Alternatives

    @TheJoe:  The debugger will still work if you attach to process, I think.  You could also use WinDbg which is much more lightweight to install.  Make sure you use the right version of sos.dll and so on.

  • Green mass murder.

    Heh, I just assumed it was wind power, but it's a huge solar collector.  I guess they had better think of a way to attract the insects away, outside the perimeter, which will draw the birds there instead.  They might talk to that fungi guy (what's his name) about attracting and repelling insects.

  • Green mass murder.

    Wind power is a huge waste of land, resources and time.  All that money needs to go into fusion and more immediately, solar power with artificial photosynthesis.  Lately artificial leaves and photosynthesis are being cracked wide open (i.e. http://phys.org/news/2014-08-sunlight-formula-sustainable-fuel.html), so why don't we stop wasting money on wind power.  Nothing operates on wind power in nature except the environment itself, and if we really could capture all the energy from wind that we need we'd definitely effect global weather patterns, using things like giant windmills.  If using wind power was an efficient way to gather energy, there would be life forms that use wind for a power source.  Note, I mean the mechanical motion of air, not i.e. oxygen, as it is a source of energy.

  • [Roslyn] Pattern Matching for C# (draft spec)

    This is the first time I've been excited by new C# features for a while.  :)

  • wireless power

    It would be interesting to experiment with programmable magnets, ala http://techcrunch.com/2013/06/12/austin-based-cmr-demos-programmable-magnets-that-changes-polarity-and-strength-on-a-whim/ and this form of wireless power

  • wireless power

    , BitFlipper wrote

    I didn't watch the videos so maybe someone made some amazing new discovery but I wasn't going to risk wasting my time.

    Using a form of resonance generated by the magnetic field, this is much more efficient than pure induction which earlier devices have used, thus making it much more practical for many applications.  Looks good to me. 

  • async and lock

    , BitFlipper wrote

    @Richard.Hein: Richard, OK that sounds like something I should look into.

    BTW, I was facetious when I said it is either oriented towards UI or web. What I meant was that these types of frameworks/features etc never consider the type of scenarios required for audio processing. We can see how async/await doesn't even allow you to set thread priority anymore since it is supposed to be a black box that magically never blocks and can't possibly cause performance issues.

    To prove my point, even Lucian said the following (all caps are his):

    *snip*

    Performance tests like to greatly disagree with that statement when it is painfully measurable at 6000 to 16000 times slower.

    Balancing nicely composed code vs. performance is harder with async/await as you can't really flip all the bits ;), whereas Rx is a library only, and you can always make your own operator to replace something.  TBH, other than the test schedulers I haven't played around with custom schedulers, so I don't know all the possibilities.  This Bozai library uses Rx and is extensible; maybe it's worth taking a peek at.  https://bitbucket.org/horizongir/bonsai/overview

     

  • async and lock

    @BitFlipper:  Perf issues might exist depending on what you do, but Rx is not oriented towards web or UI, I don't know what makes you think that.  In any case, if something involves processing streams of data asynchronously, Rx is your best bet.  I'd work out the problem using some marble diagrams, implement it in Rx, find any perf issues, and optimize from there.  That means maybe switching some bits to work with Tasks, and some having their own special threading.  Rx and async/await do play nice together as well, so combining them is 100% ok.  Rx also allows you to implement IScheduler and pass in your custom schedulers to various operators. 

    No matter even if you decide not to do it in Rx in the end - at least you'll have a solution that you can work from to get where you want to go.  It's easier to optimize an elegant solution I think.  You wouldn't have to entirely rewrite - you can just implement the operators as you see fit, replacing Rx operators with your own special perf tested replacements.

  • async and lock

    @BitFlipper:  I am interested in this thread, but seriously just don't have time to go too deep into it right now, so I didn't get involved, but might I suggest using Rx instead?  I think you'll have more luck.  Just my 2 cents.

  • Give me your best.

    Disregard advice given in forums. ;)  It's incomplete!