Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Sam Harwell
    @sharwell
    @SergeyTeplyakov I changed my mind on the comment in #144. I didn't realize it would be so long until I typed it out.
    However, I do prefer "requires/ensures" to "pres/posts"
    Sam Harwell
    @sharwell
    @SergeyTeplyakov I'm working on an AppVeyor configuration -- the build is already working but now I'm working on the tests.
    I even got it to handle our versioning scheme.
    Sergey Teplyakov
    @SergeyTeplyakov
    @sharwell Merged AppVeyor configuration
    Sam Harwell
    @sharwell
    Saw that :)
    Sam Harwell
    @sharwell
    @SergeyTeplyakov @tom-englert I'm re-running the formatter with /rule-:FieldNames, which prevents it from renaming private static and instance fields.
    It makes the review easier, which means we can merge it faster
    then we can deal with field names afterwards
    I closed the existing reformat PRs. As I update them I will reopen them
    Sergey Teplyakov
    @SergeyTeplyakov
    @sharwell Ok. Sounds good. I'll review and merge them as soon as they would be available.
    Sam Harwell
    @sharwell
    @SergeyTeplyakov I looked at #151 to see which files Tom needed reformatted first. Those files are formatted in #152, #153, and #154.
    After you merge those last 3, we can rebase #151 and it will be much easier to review it (since it will no longer contain 7000+ lines of formatting changes).
    Off to lunch now ttyl
    Sam Harwell
    @sharwell
    @SergeyTeplyakov I was hoping to open the conversation re: moving to .NET foundation
    Sergey Teplyakov
    @SergeyTeplyakov
    As I mentioned in the comment. I'l find out how to do this.
    Sergey Teplyakov
    @SergeyTeplyakov
    @sharwell Could you please do not reformat rewriter?
    I'm working on some stuff in that area...
    foxtrot project with Rewriter.cs
    Sam Harwell
    @sharwell
    @SergeyTeplyakov I'm reformatting one project at a time. If there are conflicts, I will redo it. It is not a problem.
    Sergey Teplyakov
    @SergeyTeplyakov
    ok, thanks a lot!
    Sam Harwell
    @sharwell
    @SergeyTeplyakov @tom-englert I'd like your feedback regarding #158. Do we want to go down that path or not?
    It automatically breaks up the 19 current "macro tests" into 3325 "micro tests" that can be run individually (or in whatever grouping you want)
    Sergey Teplyakov
    @SergeyTeplyakov
    I'm a big fan of proper parametrized unit tests. So :clap: from me! That would be awesome to have this stuff!
    Micah Zoltu
    @MicahZoltu
    @sharwell I have used xunit v2 parallelization, it is definitely handy for getting long test runtimes down (not sure if this is a problem for you). We had some integration tests that would take ~35 minutes to run because each test would take 30-120 seconds to run but most of the time was spent waiting for external resources. We converted them to xUnit v2 and got runtime down to ~3.5 minutes with the CPU pegged the whole time.
    Sergey Teplyakov
    @SergeyTeplyakov
    @Zoltu Long tests are actually a problem in this project, but I think most of them are CPU intensive, so I'm not sure that we would be able gain any benefits from parallelization, but an ability to run only specific test case is very useful.
    Micah Zoltu
    @MicahZoltu
    @SergeyTeplyakov The gains from CPU intensive tests are definitely limited. However, I have found that often times tests will only burn CPU on one thread in which case you can often get performance gains by running a number of tests equal to your core count. I believe xUnit does this by default (one parallelized test per core).
    That all being said, I'm definitely a huge fan of being able to run one-off tests. It makes debugging and iterating on them so much easier.
    Sam Harwell
    @sharwell
    CPU tests are stuck on 1 thread for me. I have 28 cores.
    it makes me sad
    (14 cores + hyper threading)
    Sergey Teplyakov
    @SergeyTeplyakov

    That all being said, I'm definitely a huge fan of being able to run one-off tests. It makes debugging and iterating on them so much easier.

    @Zoltu Totally agree!

    Sergey Teplyakov
    @SergeyTeplyakov
    New version of Code Contracts was published on VS Gallery: https://visualstudiogallery.msdn.microsoft.com/1ec7db13-3363-46c9-851f-1ce455f66970
    Sam Harwell
    @sharwell
    :+1:
    Sergey Teplyakov
    @SergeyTeplyakov
    Thanks a lot for everyone for your help!
    jbcutting
    @jbcutting
    Is the issue with code contracts output not showing in the error list in VS2015 (#137) not going to be addressed for the VS2015 release? Without that, users aren't going to see the output for missing contracts unless they happen to go to the output window.
    That also includes output for static analysis failures.
    Sam Harwell
    @sharwell
    @jbcutting it was less important an issue than getting ccrewrite working
    We needed to get an initial release out the door ASAP so builds were unblocked
    Issue #137 and a few others are important next steps
    jbcutting
    @jbcutting
    I get that, but it does seem like releasing something that doesn't give expected warnings for something people rely on (static analysis) could cause problems for people.
    Also, I don't have repro steps yet, but the editor extension is still crashing regularly in VS2015... I've been having to disable it.
    Sam Harwell
    @sharwell
    Re crashing: Look at the Output window for the "Code Contracts Editor Extensions" pane and you'll see stack traces. I've found 2 so far; they result in an error dialog but visual studio keeps running.
    If you have a case where visual studio actually crashes, that would be more important to address immediately.
    jbcutting
    @jbcutting
    For the analysis, I can at least tell my team to pay attention to the output window. If we're not including that as a known issue, others may upgrade and miss static analysis issues because they have no knowledge that the output is broken.
    I'll check. I agree that a VS crash would be worse, but why did the editor extension update get released if it hasn't been thoroughly tested in VS2015?
    Sam Harwell
    @sharwell
    The ccrewrite work for 2015 was almost all @SergeyTeplyakov (with no time for any editor features at all). The 2013 and 2015 support for the editor extensions was almost entirely me, and I know it has a long way to go. Keep in mind that I saw the code for the first time earlier this summer and it's just something I do in my spare time (evenings/weekends).
    The installer work for 2015 and updated contracts were done by a few other members of the community, including @hubuk and @tom-englert

    why did the editor extension update get released if it hasn't been thoroughly tested in VS2015?

    Mostly because VS 2015 didn't exist at the time.