Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 22:23
  • Jan 31 2019 22:00
    MichalStrehovsky commented #6919
  • Jan 31 2019 21:59
    MichalStrehovsky opened #6928
  • Jan 31 2019 20:45
  • Jan 31 2019 19:57
    kouvel commented #6880
  • Jan 31 2019 19:45
    filipnavara commented #6880
  • Jan 31 2019 19:44

    jkotas on master

    Merge pull request #6815 from d… Merge pull request #6839 from d… Merge pull request #6859 from d… and 8 more (compare)

  • Jan 31 2019 19:44
    jkotas closed #6926
  • Jan 31 2019 19:43
    kouvel commented #6880
  • Jan 31 2019 19:26
    kouvel commented #6880
  • Jan 31 2019 19:19

    trylek on master

    Pointer size and ARM64 fixes in… (compare)

  • Jan 31 2019 19:19
    trylek closed #6921
  • Jan 31 2019 18:40
    jkotas synchronize #6926
  • Jan 31 2019 18:40

    jkotas on nmirror

    MethodOnStruct - Fixing Project… Merge pull request #6927 from d… (compare)

  • Jan 31 2019 18:40
    jkotas closed #6927
  • Jan 31 2019 18:32
    dotnet-bot opened #6927
  • Jan 31 2019 17:19

    jkotas on master

    Reverting "Fixing up the UTF8Fo… Add managed implementation of G… (compare)

  • Jan 31 2019 17:19
    jkotas closed #6923
  • Jan 31 2019 17:18

    jkotas on master

    Fix ProjectN build breaks (#692… (compare)

  • Jan 31 2019 17:18
    jkotas closed #6924
Robin Sue
@Suchiman
@kant2002:matrix.org winforms depends heavily on win32, no chance, or do you mean only compiling it, not running it?
1 reply
@kant2002:matrix.org alternatively you could try the mono winforms implementation
Michal Strehovský
@MichalStrehovsky
@kant2002:matrix.org I don't know if there's way to compile winforms at the nuget level, but you can always just copy them out of the nuget package and add the assemblies as an explicit Reference
Andrii Kurdiumov
@kant2002:matrix.org
[m]
Will try that. Thought, maybe more easy way to do that.
Michal Strehovský
@MichalStrehovsky
I don't have high expectations that the mono winforms would implement the accessibility interfaces that are actually problematic in WinForms
Andrii Kurdiumov
@kant2002:matrix.org
[m]
True. So far, my expectation that everything except WebBrowser would simply works (assuming proper ComWrappers given) and want to validate that
Michal Strehovský
@MichalStrehovsky
that's really cool! thank you for working on that!
Andrii Kurdiumov
@kant2002:matrix.org
[m]
I really want to have simple demos to show that technology actually working. and all heavy lifting was done by you and Jan by pushing me in proper direction.
so brains was yours, hands mine :)
Michal Strehovský
@MichalStrehovsky
heh, yeah Jan has a great gift. but this is a lot of hard work and relentlessness by you. I can't claim much credit
Andrii Kurdiumov
@kant2002:matrix.org
[m]
thanks. It is fun working with you guys, always learning something new.
Michal Strehovský
@MichalStrehovsky
ah, I see you now need the change you did in IL Linker to get ported over to NativeAOT. I can do that later this week or if you want this sooner, could you port it yourself? it's the exact same change in NativeAOT (modulo the horrible formatting)
Andrii Kurdiumov
@kant2002:matrix.org
[m]
If possible I will resurrect my PR then. because it is annoying that DAtaGridView not working.
it's big thing in WinForms world.
Michal Strehovský
@MichalStrehovsky
we have two copies in the repo: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/Dataflow/ReferenceSource/ReflectionMethodBodyScanner.cs - this is the literal exact same file that exist in the IL Linker repo, including the horrible formatting. then there's https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/Dataflow/ReflectionMethodBodyScanner.cs which is the thing we actually build. if you can send a pull request that updates both with just the diff you're changing, that would make things faster
1 reply
I update them by copying the IL Linker file over and manually porting any relevant diffs, but we don't need a full update
I just don't want it to show up as a diff next time I do the full update, which is why I ask for updating both files
Andrii Kurdiumov
@kant2002:matrix.org
[m]
Perfect! perfect! Let me do that then.
after COM work, that's nothing.
Michal Strehovský
@MichalStrehovsky
:)
Andrii Kurdiumov
@kant2002:matrix.org
[m]
BTW. Do you know any book or article which explain IReferenceTracer and philosophy behind it.
because I read about COM earlier, I was almost unscattered with change, but UWP just do not want stick to me.
John Tur
@reflectronic:matrix.org
[m]
I have tried asking around, I do not think they have any public documentation
I tried looking at the way they are used in CoreCLR but the flow is far too complicated. Maybe it’ll make more sense after taking another look, though
Andrii Kurdiumov
@kant2002:matrix.org
[m]
Thanks. Maybe only reasonable way would be file PR here and see how everything unrolls :)
definitely not very soon.
John Tur
@reflectronic:matrix.org
[m]
Aaron Robinson might know
Michal Strehovský
@MichalStrehovsky
on a very high level (I don't know more details), IReferenceTracker allows integration with the WinRT reference tracker. it's used to avoid memory leaks (we're mixing ref counting with the .NET GC). the IReferenceTrackerTarget is called into during GCs
the WinRT APIs interfaces are equally poorly documented
Andrii Kurdiumov
@kant2002:matrix.org
[m]
Looks like CoreCLR source code is my best bet. At least I already a bit familiar with that area.
Michal Strehovský
@MichalStrehovsky
@RalfKornmannEnvision oh, I just found FEATURE_EMULATED_TLS you added in the past for Android. with that I have a Hello World with a real System.Console running on Android. very few hacks needed. looks very close to being checkinable: https://github.com/dotnet/runtimelab/compare/feature/NativeAOT...MichalStrehovsky:droidhacks?expand=1
once that's done, it shouldn't be too much work to hook it up with something like https://github.com/floooh/sokol and have a canvas we can draw to and an audio buffer we can play to
RalfKornmannEnvision
@RalfKornmannEnvision
@MichalStrehovsky I had a simple console app running in the past but only with debug outputs. IIRC the stack walks on Android were terrible slow. There is one improvement in this old PR https://github.com/dotnet/runtimelab/pull/296/files. I worked on another one on top of it as I noticed a major part of the bad performances is that for every walk it runs trough all dynamic modules over and over again to find the correct one with the needed information. And at least on android there are a lot of dynamic modules and the needed one seems always somewhere at the end of the list.
Michal Strehovský
@MichalStrehovsky
yeah, I didn't try to measure perf yet and for now run out of the time I allocated myself for it (back to doing "work stuff"). might get back to it next week. Jan wanted to find someone else to review the unwinding change because these things require a bit more careful look when they go into the product. The person who was finishing up the ARM64 Linux/Windows support didn't look into it and I'm not too qualified. At some point I'll need to learn those things too.
RalfKornmannEnvision
@RalfKornmannEnvision
No problem. I just create the PR back than in the case someone might find it usefull.
Andrii Kurdiumov
@kant2002:matrix.org
[m]
@yowl: congratulations on progress!
yowl
@yowl
@kant2002:matrix.org Thanks.
yowl
@yowl
Hmm, I don't suppose anyones going to review this:
image.png
lol
Robin Sue
@Suchiman
@yowl LGTM
Joshua Wierenga
@JoshuaWierenga
I am probably missing something simple but I have been stuck trying to get Comparer.CompareTo working on a runtime derived from Test.CoreLib. The exact issue appears related to IComparable.CompareTo so I suspect I missed something while setting up casting to interfaces since (char)a.CompareTo(b) works fine but (IComparable)a.CompareTo(b) gives junk, (char)(IComparable)a does preserve everything from char so it's not like either boxing or casting totally fail. Is there anything required for interface casting to work correctly other than RhTypeCast_IsInstanceOfInterface and RhTypeCast_CheckCastInterface? https://github.com/JoshuaWierenga/EfiSharp/tree/ArrayImprovements in case it matters but I haven't committed the actual comparison code currently.
Michal Strehovský
@MichalStrehovsky
I assume the arguments to the interface call get corrupted while we compute the target of the dispatch. the problem is that when we do an interface call, we need to resolve the target. but at that time the arguments to the interface call are already in the registers. the first thing RhpInitialDynamicInterfaceDispatch does is preserves all the registers, then calls the resolution helper, then restores the registers, and jumps to the target of the resolution
some of the assembly helpers are in the runtime because of perf. but some are there because of correctness
this one is because of correctness
you'll need to look into compiling these. it shouldn't be a problem to include assembly helpers in the EFI binary. linker can link them in
(it's not a problem with casting, it's a problem with calling interface methods. I suggest you step through it in a debugger on the "real" CoreLib to get a hang of it)
Joshua Wierenga
@JoshuaWierenga
I think I am close but it's now crashing because FindInterfaceMethodImplementationTarget returns IntPtr.Zero, is there anything in DispatchResolve.cs that might be platform dependant or RhpGetDispatchCellInfo for that matter? I might have to try updating my copy of NativeAOT since I saw you changed a few things related to interfaces a few days back, I am already using the changes in EEType and DispatchResolve, not sure if anything else changed during the last runtime pull.
Michal Strehovský
@MichalStrehovsky
do you mean this one? dotnet/runtimelab#1219. the compiler and the runtime data structures have to be in sync, so yeah, this would be needed if you also picked up a new compiler. nothing comes to mind - you'll need to step through it. on a high level, each interface dispatch contains three pieces of information - the slot number of the interface, the interface type and a this. we look up the dispatch table for this and then iterate over all the entries in it until we find the row with a matching interface type and slot number. we then take the code pointer from the last "column" of the table
Michal Strehovský
@MichalStrehovsky
I started a running list of breaking change announcements here: dotnet/runtimelab#1241. there was no good way to communicate when we're breaking things. since this is all preview-quality, we're pretty liberal in breaking things