Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 14 04:41

    AArnott on v16.10

    Insert into 16.10 branch (compare)

  • May 14 04:41

    AArnott on main

    Insert into 16.10 branch Merge branch 'v16.10' (compare)

  • May 12 14:21

    AArnott on v16.10

    Fix OptProf for slow moving bra… Merge pull request #848 from AA… Merge remote-tracking branch 'u… (compare)

  • May 12 14:21

    AArnott on main

    Fix OptProf for slow moving bra… Merge pull request #848 from AA… Merge remote-tracking branch 'u… and 1 more (compare)

  • May 12 14:20

    AArnott on v16.9

    Fix OptProf for slow moving bra… Merge pull request #848 from AA… (compare)

  • May 12 14:20
    AArnott closed #848
  • May 12 14:02
    AArnott milestoned #848
  • May 12 14:02
    AArnott assigned #848
  • May 12 14:02
    AArnott opened #848
  • May 11 19:21

    AArnott on main

    Update insertion branch (compare)

  • May 11 18:06

    lifengl on lifengl

    (compare)

  • May 11 18:06

    lifengl on main

    Use strong references for JTF d… Merge pull request #847 from mi… (compare)

  • May 11 18:06
    lifengl closed #847
  • May 11 18:05
    lifengl commented #847
  • May 10 17:55
    nbarbettini commented #584
  • May 10 15:51
    springy76 commented #584
  • May 08 19:58
    AArnott commented #584
  • May 07 20:24
    lifengl edited #847
  • May 07 20:22
    lifengl opened #847
  • May 07 07:44
    Bosch-Eli-Black closed #827
Andrew Arnott
@AArnott
All good points. The point for the wiki is you don't have to worry about stale docs in some release branch.
But then, docs that are consistent with the version of the software is also a good thing.
Andrew Arnott
@AArnott
@sharwell FWIW, the blog post you refer to is linked at the bottom of our threading rules doc
Regarding code coverage, I suppose integrating code coverage results into PRs requires more work than just the appveyor.yml change. I'll need to research that.
Sam Harwell
@sharwell
@AArnott enabling code coverage in PRs is similar to enabling AppVeyor in PRs
you enable the functionality in your codecov.io account, and then you trigger it by having your AppVeyor build send it data.
Andrew Arnott
@AArnott
I just tried running opencover on my local box. It spat out a bunch of errors because it can't find source to xunit itself. But I don't see any code in your change to filter that out. How did you resolve that?
nm. I found it.
Andrew Arnott
@AArnott
Any idea how I can exclude the test sources from my report? These are the parameters I have so far.
Sam Harwell
@sharwell
Why exclude test sources?
excludebyattribute might cover StaFact. Are your tests in a namespace that makes it obvious?
Andrew Arnott
@AArnott
because I want the overall coverage % to reflect product coverage -- not test coverage.
Sam Harwell
@sharwell
I think for one exclusion I actually set it in codecov.io instead of in the build
so the data is sent to codecov.io but then dropped on their end
Andrew Arnott
@AArnott
I'm having a hard time finding good docs.
For example, what exactly is the pattern matching supported in the -excludeByFile switch
and what is the codecov yml file format?
or rather, which settings are supported
Sam Harwell
@sharwell
There's yml format?
Andrew Arnott
@AArnott
yes
also there seems to be a stability problem. Besides making each build 4 minutes instead of 2 (which I can live with), the latest build is 11+ minutes and growing. I suspect it's actually hung.
Sam Harwell
@sharwell
there's a possibility that opencover somehow gets strong references to objects you think should be collectible
I've seen code coverage tooling change results for GC-related tests
I normally run GC tests separately from coverage
Andrew Arnott
@AArnott
Thanks. That's pretty limited. I was hoping it could take the ExcludeByAttribute switch to the yml as well.
Any idea where the doc is for what this means: -filter:"+[Microsoft.VisualStudio.Threading*]*"?
Andrew Arnott
@AArnott
Sam Harwell
@sharwell
It appears there is a race condition in AsyncAutoResetEvent.Set, where it's possible for a task to be cancelled between when Set calls trySetResultToDefault and when the result is actually set.
Sam Harwell
@sharwell
Ah, I see, you protect in from cancellation in that case by essentially unlinking the cancellation token. Interesting.
Andrew Arnott
@AArnott
it's been a long time since I was in the zone for that code. So I'm glad you are satisfied or it would take me a while of study to figure it out again. :)
Sam Harwell
@sharwell
@AArnott :bug: Microsoft/vs-threading#75
Andrew Arnott
@AArnott
Nice catch.
Sam Harwell
@sharwell
@AArnott I think AsyncQueueTests.NoLockHeldForCancellationContinuation would benefit from an assertion at the end that the queue contains one item.
Andrew Arnott
@AArnott
Thanks. Please feel free to file issues for these suggestions (either an individual issues or one with a checklist of your suggestions) so I don't lose track of them in this stream of messages.
Sam Harwell
@sharwell
NP wasn't sure if you wanted small issues like that but they are easy to file
Andrew Arnott
@AArnott
Well, I normally wouldn't. But you tend to have a good level of insight. And ya, if you expect lots of small ideas, a single issue with a markdown checkbox list would probably be preferable.
Sam Harwell
@sharwell
Normally I would just submit pull requests but I'm mostly reviewing the code in the context of different project so issues it is for now :smile:
Sam Harwell
@sharwell
@AArnott Do you have more information about when .NET inlines continuations that don't have ExecuteSynchronously set explicitly?
Andrew Arnott
@AArnott
@sharwell don't submit PRs at this point. Our CONTRIB doc mentions this. We can't accept external PRs at the moment. However if interest is significant enough (from folks like yourself) we will prioritize getting that changed.
Sam Harwell
@sharwell
I did see that but thanks for the heads-up
Andrew Arnott
@AArnott
I'm not sure. I just know that that flag is a suggestion, but TPL may or may not inline the continuation in spite of its presence or absence.
Sam Harwell
@sharwell
PRs also serve to better demonstrate some of the items I've mentioned even if they can't be accepted directly
Andrew Arnott
@AArnott
It certainly can help encourage inlining. I'm not against the flag. I'm just pointing out that it may not actually win us anything if inlining already tends to happen.
re: PRs: True. But then we might get into this uncomfortable world of "I'm rejecting your PR, but I'm going to copy your code into my own commits". So I suppose if you want to show code, use a gist and keep it gist-y. Don't tempt me to reuse your code. :)
Sam Harwell
@sharwell
I'm like :expressionless: each place I read Till which is only 1 character shorter than Until
Andrew Arnott
@AArnott
Are you referring to test names?
Oh, perhaps JoinTillEmpty?
Sam Harwell
@sharwell
That's the one!
Andrew Arnott
@AArnott
That's feedback I would have been happy to respond to before the API was released. Too bad we didn't originally develop this in an OSS way, eh?