These are chat archives for AvaloniaUI/Avalonia

9th
Aug 2017
Wiesław Šoltés
@wieslawsoltes
Aug 09 2017 04:41
Yes
It's part of refactoring of unit tests to be compatible with netcore
We probably can rename it
It's just used with new csproj format
Steven Kirk
@grokys
Aug 09 2017 06:25
i think it can just be removed tbh - looks like the properties it sets are the default values in the new project system
the only thing it seems to provide is GenerateAssemblyInfo
but we can just remove the assembly attributes from the tests instead
Nikita Tsukanov
@kekekeks
Aug 09 2017 07:56
BTW, any idea why this is failing on appveyor?
https://ci.appveyor.com/project/AvaloniaUI/Avalonia/build/0.1.3619
it just ignores Avalonia.Skia.RenderTests during nuget restore
like it's not even there
Steven Kirk
@grokys
Aug 09 2017 08:12
i dunno, because things are horribly broken in msbuild? i've just found a case where changing an unrelated .csproj affects another .csproj
this commit here breaks the skia and d2d render tests, even though it only touches the cairo render tests: AvaloniaUI/Avalonia@4350bbd
or more precicely, the d2d and skia render tests are finding a dependency they don't have before this commit
Nikita Tsukanov
@kekekeks
Aug 09 2017 11:34
May be the problem is that those projects are in the same directory
Matthijs ter Woord
@mterwoord
Aug 09 2017 11:43
that's the issue, yes
there's a project.assets.json file in the obj which contains the resolved dependencies
Wiesław Šoltés
@wieslawsoltes
Aug 09 2017 13:43
@grokys I have found that some things do not work in Avalonia Desktop as same as .NET Core :(
Try toggling items in Debug using Desktop build and NetCore build
@grokys AvaloniaUI/Avalonia#1096
Steven Kirk
@grokys
Aug 09 2017 14:14
thanks for the bug reports @wieslawsoltes - i promise i will look into them once i've got our tests running properly in ncrunch
@mterwoord ohh, so the fact the project.assets.jsonis in the same dir means that the projects share dependencies?!
wow
Matthijs ter Woord
@mterwoord
Aug 09 2017 14:16
i think so, yes
danwalmsley
@danwalmsley
Aug 09 2017 14:29
msft must have the windows vista or windows me team working on visual studio now
its terrible CPU usage is so high, I cant use pc for anything else whilst its open
Steven Kirk
@grokys
Aug 09 2017 14:33
yeah, i keep trying to fix problems and instead end up fighting with VS
switching branches takes about 10 minutes sometimes
it's like using SVN again
i find it best to close VS down, switch branch and then restart it
but even then intellisese is like 10x slower than on 2015
Steven Kirk
@grokys
Aug 09 2017 14:39
last night i wanted to fix the binding stackoverflow but ended up not being able to
Matthijs ter Woord
@mterwoord
Aug 09 2017 14:39
the git integration has always been slow in vs..
Steven Kirk
@grokys
Aug 09 2017 14:45
well it's the same even if you switch from the command line
the actual switching branch is fast, it's VS that's slow to react to it
Matthijs ter Woord
@mterwoord
Aug 09 2017 14:46
vs is slow updating caches etc, i usually close vs (or the solution) first before switching
(resharper magnifies the ffect)
Steven Kirk
@grokys
Aug 09 2017 14:47
yeah, and then nuget has to go and rewrite all the packages, hanging VS, even when they haven't changed
Matthijs ter Woord
@mterwoord
Aug 09 2017 14:51
and then both VS and resharper say "hey, look, dependencies changed" :)
Steven Kirk
@grokys
Aug 09 2017 14:59
yeah i don't use resharper partly for that reason
the other reason is "MY EYES!"
Matthijs ter Woord
@mterwoord
Aug 09 2017 15:00
?
what's my eyes?
what i mean is: their designer seems to be an 80s teenager
Steven Kirk
@grokys
Aug 09 2017 16:48
getting SOOOO angry with VS2017's freezing
can we go back to 2015 please?
Jeremy Koritzinsky
@jkoritzinsky
Aug 09 2017 16:49
Try the preview version. It works remarkably well.
Steven Kirk
@grokys
Aug 09 2017 16:51
that's what i'm using
it's (kinda) fine as long as you don't try to edit a .csproj file or switch branches
it loads the solution a lot faster than 2017.2 at least
thing is, i have the perfwatson extension installed and while VS is frozen, it reports no problems
so the freezing isn't even getting reported
Steven Kirk
@grokys
Aug 09 2017 17:19
@kekekeks i don't know if it helps but i merged your skia-merge branch into my fixes/ncrunch-references branch where i was trying to get everything to compile/run under ncrunch and CI is passing: https://ci.appveyor.com/project/AvaloniaUI/Avalonia/branch/master
i did have to disable running skia render tests on core for the moment though
so not sure how much help that is
Jeremy Koritzinsky
@jkoritzinsky
Aug 09 2017 17:22
One idea for the perf tests: Set the IntermediateOutputDirectory or whatever that property is called to a different value for each render test. Then they won't stomp on each other when they're getting restored
*render tests
Steven Kirk
@grokys
Aug 09 2017 17:23
yeah i think we probably need to do that
why did you move the output of those tests to the artifacts directory @jkoritzinsky ?
your PR just said "because CI", but was wondering what the problem actually was
Jeremy Koritzinsky
@jkoritzinsky
Aug 09 2017 17:34
OpenCover wasn'
wasn't matching up the multiple copies of the same assembly
which was causing codecov to error out
If we drop code coverage we can move all of the tests back to their own directories. Since it seems like we aren't even trying to keep code coverage up (we've dropped from between 50-60 down to 44 since we got codecov) we can just change it back and I'll disable codecov
If you want to drop code coverage tag me in the PR/an issue and I'll turn off codecov.
Steven Kirk
@grokys
Aug 09 2017 17:52
i dunno about codecov, it seems like it should be useful, but nobody takes any notice of it
also a lot of the recent work has been platform stuff which is hard to unit test
i actually think our coverage of non-platform libs has actually gone up (we have over 3000 unit/render tests now - when we added it i think there were little over 2000)
what are your thoughts on it @jkoritzinsky ?
Jeremy Koritzinsky
@jkoritzinsky
Aug 09 2017 18:54
I'm fine with turning it off if it simplifies our build process and reduces/eliminates the weird bugs we have in our builds.
Especially since OpenCover doesn't support .NET Core so we're going to have issues ever getting code coverage info on anything we build that only compiles off-Windows.
And even if it does, we aren't really focusing on code coverage now anyway. We can always add it back in the future.
Steven Kirk
@grokys
Aug 09 2017 20:23
ok, yeah lets disable it then
Jeremy Koritzinsky
@jkoritzinsky
Aug 09 2017 20:39
@grokys CodeCov is deleted. I'll update the README to not have the codecov badge.
Morning folks!
Happy to see netstandard v2.0 get closer to shipping yet sad at the same time. I'm not the only one though right? AppDomains in your mobile app or netcore? What :package:
Waiting until the dotnet foundation sets up the CLA robot before merging too much more into ReactiveUI btw @jkoritzinsky but then again; I guess your already covered by it?
Jeremy Koritzinsky
@jkoritzinsky
Aug 09 2017 21:14
@ghuntley Yeah I'm already covered by the CLA haha. I'll have to re-sign it once I leave MSFT but that takes like a minute.
Also the AppDomain stuff isn't actual AppDomains (i.e. the runtime impl). It's basically minimal API surface area.
Geoffrey Huntley
@ghuntley
Aug 09 2017 21:27
Ah good to know, thanks for the correction re: appdomains.