Attendees: Benedikt, Victor, Amos, Benoit, Mark Agenda Review action items from last meeting: Benedikt will continue working on .NET foundation application Victor - will continue review of CLR loader PR Benedikt - review codec PR please Benoit - multithreaded python code Victor - will work on breaking up Quantconnect PR Mohamed will rebase #974 on top of Victor's codec PR ? - github actions Amos - will take changes made to PR #958 and push to #1016, address comments Notes Benoit looked at releasing threads on initialization return for multithreaded python code use case is initializing Python.NET in Unity, on return GIL is held, workaround doesn't need Python.NET change (just release GIL from C#) should the solution be in user code or Python.NET? discussion around tradeoff between complexity for users and correct behaviour Could this be opt-in via e.g. attributes? So existing code continues to work without change. Currently PyGIL attribute doesn't do anything, purely documentation Current behaviour is somewhat surprising First step is to document behaviour Benedikt still working on .NET foundation application seems to be in some triage stage, not rejected but not progressing either will continue with personal membership and keep application moving CLR loader still WIP, can load any CLR into Python dynamic loading of Python.NET is messy, problems around PInvoke and content string, works in Mono and .NET framework should work in .NET core but first function call that hits Python function fails with missing DLL from the PInvoke call we want PInvoke to call into symbols in the existing namespace so can use current Python exe (without Python so/dll) very WIP could this be split into multiple work items? goal is to have a single deployment, but maybe this work can be split up there are a lot of people asking for .NET core support, splitting would help that Codec PR target a specific version or just merge into master once it passes CI? merge into new branch for next version? or make functions internal and use [InternalsVisibleTo] in master? just land in master tuple converter looks more like an example of how code should be done - maybe move out of main assembly to an example project? internal conversions should be rewritten using codec API PR #1016 Amos merged changes to the PR Some test failures need to be addressed Linux 3.7 crash not sure if errors are legitimate or test framework failure seems to be infrastructure instability? Victor saw same crash on other branch try again? Is there a release schedule? not really want to get Amos' big change into master before next release so we can update Python for Unity (sometime in 2020) needs input from Benedikt Action Items Benoit will write github issue documenting GIL best practices when running multithreaded code and possible solutions Benedikt will look into splitting up CLR loader into multiple work items to speed up .NET Core support Victor will address comments on codec PR Victor - will work on breaking up Quantconnect PR Mohamed will rebase #974 on top of Victor's codec PR ? - github actions Victor will send Benoit & Felix build that failed on Linux 3.7 Benoit will continue working on PR #1016 Amos is having connection issues and will send an update email to the mailing list The meeting notes google doc is here <https://docs.google.com/document/d/1rJVU84B_dgx58-_EopjRtOJVFAI2WfHJYV0n7uE1Oak/edit#>. Feel free to correct or add additional information. The next meeting will be held on Thursday, February 13th at 12pm EST, 9am PST, 6pm CET, 1am China. Mark Visser Tooling Dev Manager Unity Technologies - www.unity3d.com <http://www.unity3d.com/>