Access violation since 1570

Description
When switching to 0.3.7-preview.1570 from 0.3.7-preview.9 I now get an access violation exception in an otherwise unmodified application. This is on Windows, with a Varjo XR-3.
Platform / Environment
Windows, MSVC 17.4.4
Logs or exception details
Call stack with native debugging enabled:
 	VarjoOpenXR.dll!00007ff95c29546c()	Unknown
 	VarjoOpenXR.dll!00007ff95c2b9cef()	Unknown
 	VarjoOpenXR.dll!00007ff95c2ba519()	Unknown
 	StereoKitC.dll!xrLocateViews(XrSession_T * session, const XrViewLocateInfo * viewLocateInfo, XrViewState * viewState, unsigned int viewCapacityInput, unsigned int * viewCountOutput, XrView * views) Line 464	C++
 	StereoKitC.dll!sk::openxr_views_update_fov() Line 888	C++
 	StereoKitC.dll!sk::openxr_poll_events() Line 844	C++
 	StereoKitC.dll!sk::openxr_init() Line 511	C++
 	StereoKitC.dll!sk::platform_set_mode(sk::display_type_ mode) Line 164	C++
 	StereoKitC.dll!sk::platform_init() Line 74	C++
 	StereoKitC.dll!sk::systems_initialize() Line 138	C++
 	StereoKitC.dll!sk_init(sk::sk_settings_t settings) Line 322	C++
 	[Managed to Native Transition]
 	StereoKit.dll!StereoKit.SK.InitializeCall(StereoKit.SKSettings settings) Line 149	C#
 	StereoKit.dll!StereoKit.SK.Initialize(StereoKit.SKSettings settings) Line 92	C#
>	ModelViewer.dll!ModelViewer.Application.Main(string[] args) Line 1173	C#
 	[Native to Managed Transition]
 	hostpolicy.dll!00007ff9b5e64c5d()	Unknown
 	hostpolicy.dll!00007ff9b5e72e10()	Unknown
 	hostpolicy.dll!00007ff9b5e7288c()	Unknown
 	hostpolicy.dll!00007ff9b5e74b85()	Unknown
 	hostfxr.dll!00007ff9b5edb7e0()	Unknown
 	hostfxr.dll!00007ff9b5ede41a()	Unknown
 	hostfxr.dll!00007ff9b5ee06e6()	Unknown
 	hostfxr.dll!00007ff9b5edea84()	Unknown
 	hostfxr.dll!00007ff9b5ed85a3()	Unknown
 	ModelViewer.exe!00007ff638962d47()	Unknown
 	ModelViewer.exe!00007ff6389632c8()	Unknown
 	ModelViewer.exe!00007ff638964978()	Unknown
 	kernel32.dll!00007ff9ce457614()	Unknown
 	ntdll.dll!00007ff9cf3426f1()	Unknown

Relevant init code, nothing special:
       static void Main(string[] args)
        {
            // To get , as thousand separator
            CultureInfo.CurrentCulture = CultureInfo.CreateSpecificCulture("en-US");

            // Initialize StereoKit
            SKSettings settings = new SKSettings
            {
                appName = "ModelViewer",
                assetsFolder = "Assets",
                //displayPreference = DisplayMode.Flatscreen,        // If enabled, runs simulator
                //blendPreference = DisplayBlend.Opaque,            // If enabled, gives VR mode without pass-through
            };

Console log (seems to be something related to graphics pipeline setup):
[SK diagnostic] Initializing StereoKit v0.3.7-preview.1570 Win32 x64...
[SK diagnostic] Initializing Assets
[SK diagnostic] Initializing Platform
20230706 13:53:40.198 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Users\VR-1\Desktop\Projects\ModelViewer\bin\Release\netcoreapp3.1\VarjoRuntime.dll"...
20230706 13:53:40.198 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "\VarjoRuntime.dll"...
20230706 13:53:40.198 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll"...
20230706 13:53:40.200 --- [Varjo::RuntimeInterface::load] VarjoRuntime.dll loaded from C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll successfully.
20230706 13:53:40.200 --- [Varjo::CreateAndInitSession] clientSessionId: sdk#openxr#1000001379982533400, version: <IP_ADDRESS>
20230706 13:53:40.201 --- [PipeSession::Run] Pipe1: Open
20230706 13:53:40.201 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.201 --- [PipeSession::Run] Pipe1: Disconnected
20230706 13:53:40.202 --- [Varjo::LayerClient::LayerClient] New LayerClient, unique client session id: 'sdk#openxr#1000001379982533400', sdk version='<IP_ADDRESS>'
20230706 13:53:40.209 --- [Varjo::HighPrecisionSleep::initialize::<lambda_edb3a67b8881b8eb44fc475bf02b5bd1>::operator ()] HPSleep resolution: 499900 ns
20230706 13:53:40.209 --- [PipeSession::Run] Pipe2: Open
20230706 13:53:40.209 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.210 --- [Varjo::LayerClient::waitHandshake] Wait for handshake
20230706 13:53:40.213 --- [Varjo::LayerClient::waitHandshake] HANDSHAKE OK
20230706 13:53:40.213 *** [Varjo::LayerClient::waitHandshake] result OK
20230706 13:53:40.216 --- [Varjo::State::PropertyClient::waitForConnection] Trying to connect to PropertyServer
20230706 13:53:40.216 --- [Varjo::State::PropertyClient::waitForConnection] Connected to PropertyServer
20230706 13:53:40.216 --- [Varjo::State::PropertyClient::onClientRoleRequest] Identifying as client role 'RUNTIME'
20230706 13:53:40.218 --- [Varjo::State::PropertyClient::processOnPropertyDefinitions] Received definitions for 301 properties
20230706 13:53:40.218 --- [Varjo::State::PropertyClient::tryInitialization] Connection to Property Server established and property definitions initialized
20230706 13:53:40.219 --- [Varjo::Session::createCompositorLink] Create compositor link for sdk#openxr#1000001379982533400
20230706 13:53:40.219 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait...
20230706 13:53:40.221 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait... OK.
20230706 13:53:40.221 --- [Varjo::ProcessorUtil::useOnlyPerformanceCpuCoresForCurrentProcess] Setting Process Affinity mask 0xffff
20230706 13:53:40.222 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.222 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.223 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' connection thread woke up
20230706 13:53:40.223 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager' connection thread woke up
20230706 13:53:40.224 WAR [Varjo::State::PropertyClient::stop] Cancelling PropertyClient initialization
20230706 13:53:40.224 WAR [Varjo::State::PropertyClient::onConnectionLost] Connection lost to Property Server
20230706 13:53:40.225 --- [PipeSession::Run] Pipe2: Disconnected
20230706 13:53:40.226 --- [Varjo::RuntimeInterface::unload] No more active sessions, VarjoRuntime unloaded.
20230706 13:53:40.226 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Users\VR-1\Desktop\Projects\ModelViewer\bin\Release\netcoreapp3.1\VarjoRuntime.dll"...
20230706 13:53:40.227 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "\VarjoRuntime.dll"...
20230706 13:53:40.227 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll"...
20230706 13:53:40.230 --- [Varjo::RuntimeInterface::load] VarjoRuntime.dll loaded from C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll successfully.
20230706 13:53:40.232 --- [Varjo::CreateAndInitSession] clientSessionId: sdk#openxr#1000001380014127400, version: <IP_ADDRESS>
20230706 13:53:40.233 --- [PipeSession::Run] Pipe1: Open
20230706 13:53:40.233 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.234 --- [PipeSession::Run] Pipe1: Disconnected
20230706 13:53:40.235 --- [Varjo::LayerClient::LayerClient] New LayerClient, unique client session id: 'sdk#openxr#1000001380014127400', sdk version='<IP_ADDRESS>'
20230706 13:53:40.237 --- [Varjo::HighPrecisionSleep::initialize::<lambda_edb3a67b8881b8eb44fc475bf02b5bd1>::operator ()] HPSleep resolution: 499900 ns
20230706 13:53:40.238 --- [PipeSession::Run] Pipe2: Open
20230706 13:53:40.238 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.239 --- [Varjo::LayerClient::waitHandshake] Wait for handshake
20230706 13:53:40.240 --- [Varjo::LayerClient::waitHandshake] HANDSHAKE OK
20230706 13:53:40.241 *** [Varjo::LayerClient::waitHandshake] result OK
20230706 13:53:40.244 --- [Varjo::State::PropertyClient::waitForConnection] Trying to connect to PropertyServer
20230706 13:53:40.244 --- [Varjo::State::PropertyClient::onClientRoleRequest] Identifying as client role 'RUNTIME'
20230706 13:53:40.244 --- [Varjo::State::PropertyClient::waitForConnection] Connected to PropertyServer
20230706 13:53:40.245 --- [Varjo::State::PropertyClient::processOnPropertyDefinitions] Received definitions for 301 properties
20230706 13:53:40.247 --- [Varjo::State::PropertyClient::tryInitialization] Connection to Property Server established and property definitions initialized
20230706 13:53:40.248 --- [Varjo::Session::createCompositorLink] Create compositor link for sdk#openxr#1000001380014127400
20230706 13:53:40.248 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait...
20230706 13:53:40.249 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait... OK.
20230706 13:53:40.249 --- [Varjo::ProcessorUtil::useOnlyPerformanceCpuCoresForCurrentProcess] Setting Process Affinity mask 0xffff
20230706 13:53:40.251 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.251 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.252 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' connection thread woke up
20230706 13:53:40.252 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager' connection thread woke up
20230706 13:53:40.253 WAR [Varjo::State::PropertyClient::stop] Cancelling PropertyClient initialization
20230706 13:53:40.253 WAR [Varjo::State::PropertyClient::onConnectionLost] Connection lost to Property Server
20230706 13:53:40.254 --- [PipeSession::Run] Pipe2: Disconnected
20230706 13:53:40.255 --- [Varjo::RuntimeInterface::unload] No more active sessions, VarjoRuntime unloaded.
20230706 13:53:40.255 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Users\VR-1\Desktop\Projects\ModelViewer\bin\Release\netcoreapp3.1\VarjoRuntime.dll"...
20230706 13:53:40.256 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "\VarjoRuntime.dll"...
20230706 13:53:40.256 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll"...
20230706 13:53:40.258 --- [Varjo::RuntimeInterface::load] VarjoRuntime.dll loaded from C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll successfully.
20230706 13:53:40.258 --- [Varjo::CreateAndInitSession] clientSessionId: sdk#openxr#1000001380040098600, version: <IP_ADDRESS>
20230706 13:53:40.258 --- [PipeSession::Run] Pipe1: Open
20230706 13:53:40.259 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.260 --- [PipeSession::Run] Pipe1: Disconnected
20230706 13:53:40.260 --- [Varjo::LayerClient::LayerClient] New LayerClient, unique client session id: 'sdk#openxr#1000001380040098600', sdk version='<IP_ADDRESS>'
20230706 13:53:40.263 --- [Varjo::HighPrecisionSleep::initialize::<lambda_edb3a67b8881b8eb44fc475bf02b5bd1>::operator ()] HPSleep resolution: 499900 ns
20230706 13:53:40.263 --- [PipeSession::Run] Pipe2: Open
20230706 13:53:40.264 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.265 --- [Varjo::LayerClient::waitHandshake] Wait for handshake
20230706 13:53:40.265 --- [Varjo::LayerClient::waitHandshake] HANDSHAKE OK
20230706 13:53:40.266 *** [Varjo::LayerClient::waitHandshake] result OK
20230706 13:53:40.268 --- [Varjo::State::PropertyClient::waitForConnection] Trying to connect to PropertyServer
20230706 13:53:40.269 --- [Varjo::State::PropertyClient::waitForConnection] Connected to PropertyServer
20230706 13:53:40.269 --- [Varjo::State::PropertyClient::onClientRoleRequest] Identifying as client role 'RUNTIME'
20230706 13:53:40.271 --- [Varjo::State::PropertyClient::processOnPropertyDefinitions] Received definitions for 301 properties
20230706 13:53:40.272 --- [Varjo::State::PropertyClient::tryInitialization] Connection to Property Server established and property definitions initialized
20230706 13:53:40.272 --- [Varjo::Session::createCompositorLink] Create compositor link for sdk#openxr#1000001380040098600
20230706 13:53:40.273 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait...
20230706 13:53:40.274 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait... OK.
20230706 13:53:40.274 --- [Varjo::ProcessorUtil::useOnlyPerformanceCpuCoresForCurrentProcess] Setting Process Affinity mask 0xffff
20230706 13:53:40.275 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.275 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.275 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' connection thread woke up
20230706 13:53:40.279 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager' connection thread woke up
20230706 13:53:40.280 WAR [Varjo::State::PropertyClient::stop] Cancelling PropertyClient initialization
20230706 13:53:40.280 WAR [Varjo::State::PropertyClient::onConnectionLost] Connection lost to Property Server
20230706 13:53:40.281 --- [PipeSession::Run] Pipe2: Disconnected
20230706 13:53:40.282 --- [Varjo::RuntimeInterface::unload] No more active sessions, VarjoRuntime unloaded.
20230706 13:53:40.282 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Users\VR-1\Desktop\Projects\ModelViewer\bin\Release\netcoreapp3.1\VarjoRuntime.dll"...
20230706 13:53:40.283 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "\VarjoRuntime.dll"...
20230706 13:53:40.283 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll"...
20230706 13:53:40.285 --- [Varjo::RuntimeInterface::load] VarjoRuntime.dll loaded from C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll successfully.
20230706 13:53:40.285 --- [Varjo::CreateAndInitSession] clientSessionId: sdk#openxr#1000001380067304800, version: <IP_ADDRESS>
20230706 13:53:40.286 --- [PipeSession::Run] Pipe1: Open
20230706 13:53:40.286 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.287 --- [PipeSession::Run] Pipe1: Disconnected
20230706 13:53:40.287 --- [Varjo::LayerClient::LayerClient] New LayerClient, unique client session id: 'sdk#openxr#1000001380067304800', sdk version='<IP_ADDRESS>'
20230706 13:53:40.288 --- [Varjo::HighPrecisionSleep::initialize::<lambda_edb3a67b8881b8eb44fc475bf02b5bd1>::operator ()] HPSleep resolution: 499900 ns
20230706 13:53:40.288 --- [PipeSession::Run] Pipe2: Open
20230706 13:53:40.288 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.289 --- [Varjo::LayerClient::waitHandshake] Wait for handshake
20230706 13:53:40.290 --- [Varjo::LayerClient::waitHandshake] HANDSHAKE OK
20230706 13:53:40.291 *** [Varjo::LayerClient::waitHandshake] result OK
20230706 13:53:40.293 --- [Varjo::State::PropertyClient::waitForConnection] Trying to connect to PropertyServer
20230706 13:53:40.294 --- [Varjo::State::PropertyClient::waitForConnection] Connected to PropertyServer
20230706 13:53:40.294 --- [Varjo::State::PropertyClient::onClientRoleRequest] Identifying as client role 'RUNTIME'
20230706 13:53:40.296 --- [Varjo::State::PropertyClient::processOnPropertyDefinitions] Received definitions for 301 properties
20230706 13:53:40.297 --- [Varjo::State::PropertyClient::tryInitialization] Connection to Property Server established and property definitions initialized
20230706 13:53:40.298 --- [Varjo::Session::createCompositorLink] Create compositor link for sdk#openxr#1000001380067304800
20230706 13:53:40.298 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait...
20230706 13:53:40.301 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait... OK.
20230706 13:53:40.302 --- [Varjo::ProcessorUtil::useOnlyPerformanceCpuCoresForCurrentProcess] Setting Process Affinity mask 0xffff
20230706 13:53:40.303 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.303 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.304 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' connection thread woke up
20230706 13:53:40.305 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager' connection thread woke up
20230706 13:53:40.305 WAR [Varjo::State::PropertyClient::stop] Cancelling PropertyClient initialization
20230706 13:53:40.306 WAR [Varjo::State::PropertyClient::onConnectionLost] Connection lost to Property Server
20230706 13:53:40.307 --- [PipeSession::Run] Pipe2: Disconnected
20230706 13:53:40.309 --- [Varjo::RuntimeInterface::unload] No more active sessions, VarjoRuntime unloaded.
20230706 13:53:40.310 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Users\VR-1\Desktop\Projects\ModelViewer\bin\Release\netcoreapp3.1\VarjoRuntime.dll"...
20230706 13:53:40.310 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "\VarjoRuntime.dll"...
20230706 13:53:40.311 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll"...
20230706 13:53:40.313 --- [Varjo::RuntimeInterface::load] VarjoRuntime.dll loaded from C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll successfully.
20230706 13:53:40.313 --- [Varjo::CreateAndInitSession] clientSessionId: sdk#openxr#1000001380095093500, version: <IP_ADDRESS>
20230706 13:53:40.313 --- [PipeSession::Run] Pipe1: Open
20230706 13:53:40.314 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.314 --- [PipeSession::Run] Pipe1: Disconnected
20230706 13:53:40.315 --- [Varjo::LayerClient::LayerClient] New LayerClient, unique client session id: 'sdk#openxr#1000001380095093500', sdk version='<IP_ADDRESS>'
20230706 13:53:40.316 --- [Varjo::HighPrecisionSleep::initialize::<lambda_edb3a67b8881b8eb44fc475bf02b5bd1>::operator ()] HPSleep resolution: 499900 ns
20230706 13:53:40.316 --- [PipeSession::Run] Pipe2: Open
20230706 13:53:40.316 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.317 --- [Varjo::LayerClient::waitHandshake] Wait for handshake
20230706 13:53:40.318 --- [Varjo::LayerClient::waitHandshake] HANDSHAKE OK
20230706 13:53:40.318 *** [Varjo::LayerClient::waitHandshake] result OK
20230706 13:53:40.321 --- [Varjo::State::PropertyClient::waitForConnection] Trying to connect to PropertyServer
20230706 13:53:40.322 --- [Varjo::State::PropertyClient::onClientRoleRequest] Identifying as client role 'RUNTIME'
20230706 13:53:40.322 --- [Varjo::State::PropertyClient::waitForConnection] Connected to PropertyServer
20230706 13:53:40.325 --- [Varjo::State::PropertyClient::processOnPropertyDefinitions] Received definitions for 301 properties
20230706 13:53:40.326 --- [Varjo::State::PropertyClient::tryInitialization] Connection to Property Server established and property definitions initialized
20230706 13:53:40.327 --- [Varjo::Session::createCompositorLink] Create compositor link for sdk#openxr#1000001380095093500
20230706 13:53:40.327 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait...
20230706 13:53:40.329 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait... OK.
20230706 13:53:40.329 --- [Varjo::ProcessorUtil::useOnlyPerformanceCpuCoresForCurrentProcess] Setting Process Affinity mask 0xffff
20230706 13:53:40.331 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.331 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.332 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' connection thread woke up
20230706 13:53:40.332 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager' connection thread woke up
20230706 13:53:40.333 WAR [Varjo::State::PropertyClient::stop] Cancelling PropertyClient initialization
20230706 13:53:40.333 WAR [Varjo::State::PropertyClient::onConnectionLost] Connection lost to Property Server
20230706 13:53:40.334 --- [PipeSession::Run] Pipe2: Disconnected
20230706 13:53:40.335 --- [Varjo::RuntimeInterface::unload] No more active sessions, VarjoRuntime unloaded.
20230706 13:53:40.335 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Users\VR-1\Desktop\Projects\ModelViewer\bin\Release\netcoreapp3.1\VarjoRuntime.dll"...
20230706 13:53:40.335 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "\VarjoRuntime.dll"...
20230706 13:53:40.336 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll"...
20230706 13:53:40.338 --- [Varjo::RuntimeInterface::load] VarjoRuntime.dll loaded from C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll successfully.
20230706 13:53:40.340 --- [Varjo::CreateAndInitSession] clientSessionId: sdk#openxr#1000001380121668000, version: <IP_ADDRESS>
20230706 13:53:40.340 --- [PipeSession::Run] Pipe1: Open
20230706 13:53:40.340 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.341 --- [PipeSession::Run] Pipe1: Disconnected
20230706 13:53:40.341 --- [Varjo::LayerClient::LayerClient] New LayerClient, unique client session id: 'sdk#openxr#1000001380121668000', sdk version='<IP_ADDRESS>'
20230706 13:53:40.342 --- [Varjo::HighPrecisionSleep::initialize::<lambda_edb3a67b8881b8eb44fc475bf02b5bd1>::operator ()] HPSleep resolution: 499900 ns
20230706 13:53:40.342 --- [PipeSession::Run] Pipe2: Open
20230706 13:53:40.343 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.344 --- [Varjo::LayerClient::waitHandshake] Wait for handshake
20230706 13:53:40.346 --- [Varjo::LayerClient::waitHandshake] HANDSHAKE OK
20230706 13:53:40.346 *** [Varjo::LayerClient::waitHandshake] result OK
20230706 13:53:40.349 --- [Varjo::State::PropertyClient::waitForConnection] Trying to connect to PropertyServer
20230706 13:53:40.350 --- [Varjo::State::PropertyClient::waitForConnection] Connected to PropertyServer
20230706 13:53:40.350 --- [Varjo::State::PropertyClient::onClientRoleRequest] Identifying as client role 'RUNTIME'
20230706 13:53:40.351 --- [Varjo::State::PropertyClient::processOnPropertyDefinitions] Received definitions for 301 properties
20230706 13:53:40.351 --- [Varjo::State::PropertyClient::tryInitialization] Connection to Property Server established and property definitions initialized
20230706 13:53:40.352 --- [Varjo::Session::createCompositorLink] Create compositor link for sdk#openxr#1000001380121668000
20230706 13:53:40.352 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait...
20230706 13:53:40.354 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait... OK.
20230706 13:53:40.355 --- [Varjo::ProcessorUtil::useOnlyPerformanceCpuCoresForCurrentProcess] Setting Process Affinity mask 0xffff
20230706 13:53:40.356 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.356 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.356 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' connection thread woke up
20230706 13:53:40.358 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager' connection thread woke up
20230706 13:53:40.358 WAR [Varjo::State::PropertyClient::stop] Cancelling PropertyClient initialization
20230706 13:53:40.358 WAR [Varjo::State::PropertyClient::onConnectionLost] Connection lost to Property Server
20230706 13:53:40.359 --- [PipeSession::Run] Pipe2: Disconnected
20230706 13:53:40.360 --- [Varjo::RuntimeInterface::unload] No more active sessions, VarjoRuntime unloaded.
[SK diagnostic] available: XR_KHR_D3D12_enable
[SK diagnostic] available: XR_KHR_opengl_enable
[SK diagnostic] available: XR_VARJO_composition_layer_depth_test
[SK diagnostic] available: XR_VARJO_environment_depth_estimation
[SK diagnostic] available: XR_EXT_debug_utils
[SK diagnostic] available: XR_EXT_win32_appcontainer_compatible
[SK diagnostic] available: XR_VARJO_quad_views
[SK diagnostic] available: XR_VARJO_foveated_rendering
[SK diagnostic] available: XR_KHR_visibility_mask
[SK diagnostic] available: XR_VARJO_marker_tracking
[SK diagnostic] available: XR_HTCX_vive_tracker_interaction
[SK diagnostic] available: XR_VARJO_view_offset
[SK diagnostic] available: XR_KHR_vulkan_enable
[SK diagnostic] available: XR_KHR_vulkan_enable2
[SK diagnostic] available: XR_KHR_swapchain_usage_input_attachment_bit
[SK diagnostic] REQUESTED: XR_KHR_D3D11_enable
[SK diagnostic] REQUESTED: XR_KHR_win32_convert_performance_counter_time
[SK diagnostic] REQUESTED: XR_KHR_composition_layer_depth
[SK diagnostic] REQUESTED: XR_EXT_eye_gaze_interaction
[SK diagnostic] REQUESTED: XR_EXT_hand_tracking
20230706 13:53:40.365 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Users\VR-1\Desktop\Projects\ModelViewer\bin\Release\netcoreapp3.1\VarjoRuntime.dll"...
20230706 13:53:40.365 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "\VarjoRuntime.dll"...
20230706 13:53:40.365 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll"...
20230706 13:53:40.367 --- [Varjo::RuntimeInterface::load] VarjoRuntime.dll loaded from C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll successfully.
20230706 13:53:40.367 --- [Varjo::CreateAndInitSession] clientSessionId: sdk#openxr#1000001380149475700, version: <IP_ADDRESS>
20230706 13:53:40.368 --- [PipeSession::Run] Pipe1: Open
20230706 13:53:40.368 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.369 --- [PipeSession::Run] Pipe1: Disconnected
20230706 13:53:40.371 --- [Varjo::LayerClient::LayerClient] New LayerClient, unique client session id: 'sdk#openxr#1000001380149475700', sdk version='<IP_ADDRESS>'
20230706 13:53:40.371 --- [Varjo::HighPrecisionSleep::initialize::<lambda_edb3a67b8881b8eb44fc475bf02b5bd1>::operator ()] HPSleep resolution: 499900 ns
20230706 13:53:40.372 --- [PipeSession::Run] Pipe2: Open
20230706 13:53:40.372 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.373 --- [Varjo::LayerClient::waitHandshake] Wait for handshake
20230706 13:53:40.373 --- [Varjo::LayerClient::waitHandshake] HANDSHAKE OK
20230706 13:53:40.374 *** [Varjo::LayerClient::waitHandshake] result OK
20230706 13:53:40.377 --- [Varjo::State::PropertyClient::waitForConnection] Trying to connect to PropertyServer
20230706 13:53:40.377 --- [Varjo::State::PropertyClient::waitForConnection] Connected to PropertyServer
20230706 13:53:40.377 --- [Varjo::State::PropertyClient::onClientRoleRequest] Identifying as client role 'RUNTIME'
20230706 13:53:40.378 --- [Varjo::State::PropertyClient::processOnPropertyDefinitions] Received definitions for 301 properties
20230706 13:53:40.379 --- [Varjo::State::PropertyClient::tryInitialization] Connection to Property Server established and property definitions initialized
20230706 13:53:40.379 --- [Varjo::Session::createCompositorLink] Create compositor link for sdk#openxr#1000001380149475700
20230706 13:53:40.380 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait...
20230706 13:53:40.382 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait... OK.
20230706 13:53:40.382 --- [Varjo::ProcessorUtil::useOnlyPerformanceCpuCoresForCurrentProcess] Setting Process Affinity mask 0xffff
20230706 13:53:40.383 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.383 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.383 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' connection thread woke up
20230706 13:53:40.384 --- [Varjo::GazeClient::waitConnectionThreadWakeup] GazeClient 'VarjoSystem.FoveatedViewManager' connection thread woke up
20230706 13:53:40.384 WAR [Varjo::State::PropertyClient::stop] Cancelling PropertyClient initialization
20230706 13:53:40.387 WAR [Varjo::State::PropertyClient::onConnectionLost] Connection lost to Property Server
20230706 13:53:40.388 --- [PipeSession::Run] Pipe2: Disconnected
20230706 13:53:40.389 --- [Varjo::RuntimeInterface::unload] No more active sessions, VarjoRuntime unloaded.
20230706 13:53:40.389 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Users\VR-1\Desktop\Projects\ModelViewer\bin\Release\netcoreapp3.1\VarjoRuntime.dll"...
20230706 13:53:40.389 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "\VarjoRuntime.dll"...
20230706 13:53:40.390 --- [Varjo::RuntimeInterface::load] Trying to load VarjoRuntime from "C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll"...
20230706 13:53:40.392 --- [Varjo::RuntimeInterface::load] VarjoRuntime.dll loaded from C:\Program Files\Varjo\varjo-compositor\\VarjoRuntime.dll successfully.
20230706 13:53:40.392 --- [PipeSession::Run] Pipe1: Open
20230706 13:53:40.392 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.393 --- [PipeSession::Run] Pipe1: Disconnected
20230706 13:53:40.394 --- [PipeSession::Run] Pipe1: Open
20230706 13:53:40.394 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.394 --- [PipeSession::Run] Pipe1: Disconnected
20230706 13:53:40.394 --- [Varjo::CreateAndInitSession] clientSessionId: sdk#openxr#1000001380176498000, version: <IP_ADDRESS>
20230706 13:53:40.395 --- [PipeSession::Run] Pipe2: Open
20230706 13:53:40.395 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.396 --- [PipeSession::Run] Pipe2: Disconnected
20230706 13:53:40.396 --- [Varjo::LayerClient::LayerClient] New LayerClient, unique client session id: 'sdk#openxr#1000001380176498000', sdk version='<IP_ADDRESS>'
20230706 13:53:40.396 --- [Varjo::HighPrecisionSleep::initialize::<lambda_edb3a67b8881b8eb44fc475bf02b5bd1>::operator ()] HPSleep resolution: 499900 ns
20230706 13:53:40.397 --- [PipeSession::Run] Pipe3: Open
20230706 13:53:40.397 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.398 --- [Varjo::LayerClient::waitHandshake] Wait for handshake
20230706 13:53:40.399 --- [Varjo::LayerClient::waitHandshake] HANDSHAKE OK
20230706 13:53:40.399 *** [Varjo::LayerClient::waitHandshake] result OK
20230706 13:53:40.402 --- [Varjo::State::PropertyClient::waitForConnection] Trying to connect to PropertyServer
20230706 13:53:40.403 --- [Varjo::State::PropertyClient::waitForConnection] Connected to PropertyServer
20230706 13:53:40.403 --- [Varjo::State::PropertyClient::onClientRoleRequest] Identifying as client role 'RUNTIME'
20230706 13:53:40.404 --- [Varjo::State::PropertyClient::processOnPropertyDefinitions] Received definitions for 301 properties
20230706 13:53:40.405 --- [Varjo::State::PropertyClient::tryInitialization] Connection to Property Server established and property definitions initialized
20230706 13:53:40.406 --- [Varjo::Session::createCompositorLink] Create compositor link for sdk#openxr#1000001380176498000
20230706 13:53:40.406 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait...
20230706 13:53:40.407 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait... OK.
20230706 13:53:40.407 --- [Varjo::ProcessorUtil::useOnlyPerformanceCpuCoresForCurrentProcess] Setting Process Affinity mask 0xffff
20230706 13:53:40.408 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.408 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
[SK diagnostic] Found OpenXR runtime: Varjo OpenXR Runtime 3.10.1
20230706 13:53:40.466 --- [Varjo::GazeClient::connectionThread] GazeClient 'sdk#openxr#1000001380176498000' with output frequency 100Hz and smoothing ON successfully connected to suitable gaze IPC stream
[SK diagnostic] [sk_gpu] Using Direct3D 11: vendor 0x10DE, device 0x2204
[SK diagnostic] [sk_gpu] Device: NVIDIA GeForce RTX 3090
[SK diagnostic] Starting a stereo display
20230706 13:53:40.541 --- [Varjo::HandTrackingClient::start] Start HandTrackingClient
[SK diagnostic] System name: XR-3
[SK diagnostic] Platform supports single-pass rendering
[SK diagnostic] OpenXR articulated hands ext enabled!
[SK diagnostic] OpenXR gaze ext enabled!
20230706 13:53:40.542 --- [Varjo::HandTrackingClient::process] HandTrackingSource thread started
[SK diagnostic] Creating view: PrimaryStereo color:rgba32_linear depth:depth32 blend:Alpha Blend
20230706 13:53:40.545 --- [Varjo::HandTrackingClient::process] (skipped 0) Waiting for IPC input Varjo.HandTracking.TrackedHands connection...
20230706 13:53:40.545 --- [Varjo::CreateAndInitSession] clientSessionId: sdk#openxr#1000001380326851400, version: <IP_ADDRESS>
20230706 13:53:40.546 --- [PipeSession::Run] Pipe4: Open
20230706 13:53:40.547 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.548 --- [PipeSession::Run] Pipe4: Disconnected
20230706 13:53:40.548 --- [Varjo::LayerClient::LayerClient] New LayerClient, unique client session id: 'sdk#openxr#1000001380326851400', sdk version='<IP_ADDRESS>'
20230706 13:53:40.548 --- [PipeSession::Run] Pipe5: Open
20230706 13:53:40.549 --- [PipeClient::OnSessionStart] Connected.
20230706 13:53:40.550 --- [Varjo::LayerClient::waitHandshake] Wait for handshake
20230706 13:53:40.551 --- [Varjo::LayerClient::waitHandshake] HANDSHAKE OK
20230706 13:53:40.552 *** [Varjo::LayerClient::waitHandshake] result OK
20230706 13:53:40.554 --- [Varjo::State::PropertyClient::waitForConnection] Trying to connect to PropertyServer
20230706 13:53:40.557 --- [Varjo::State::PropertyClient::waitForConnection] Connected to PropertyServer
20230706 13:53:40.557 --- [Varjo::State::PropertyClient::onClientRoleRequest] Identifying as client role 'RUNTIME'
20230706 13:53:40.558 --- [Varjo::State::PropertyClient::processOnPropertyDefinitions] Received definitions for 301 properties
20230706 13:53:40.559 --- [Varjo::State::PropertyClient::tryInitialization] Connection to Property Server established and property definitions initialized
20230706 13:53:40.560 --- [Varjo::Session::createCompositorLink] Create compositor link for sdk#openxr#1000001380326851400
20230706 13:53:40.560 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait...
20230706 13:53:40.562 --- [Varjo::LayerClient::createIPCAndWait] createIPCAndWait... OK.
20230706 13:53:40.563 --- [Varjo::ProcessorUtil::useOnlyPerformanceCpuCoresForCurrentProcess] Setting Process Affinity mask 0xffff
20230706 13:53:40.564 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.564 --- [Varjo::GazeClient::connectionThread] GazeClient 'VarjoSystem.FoveatedViewManager.Latency' with output frequency DeviceHz and smoothing ON successfully connected to suitable gaze IPC stream
20230706 13:53:40.567 --- [Varjo::Session::createSwapChain] Varjo::Session::createSwapChain, client: sdk#openxr#1000001380176498000
20230706 13:53:40.569 --- [Varjo::LayerClient::createSwapChain] createSwapchain... OK.
20230706 13:53:40.569 --- [Varjo::Session::createSwapChain] Varjo::Session::createSwapChain, client: sdk#openxr#1000001380176498000
20230706 13:53:40.571 --- [Varjo::LayerClient::createSwapChain] createSwapchain... OK.
[SK diagnostic] Set view: PrimaryStereo to 4148x3556@1msaa
Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at StereoKit.NativeAPI.sk_init(StereoKit.SKSettings)
   at StereoKit.NativeAPI.sk_init(StereoKit.SKSettings)
   at StereoKit.SK.InitializeCall(StereoKit.SKSettings)
   at StereoKit.SK.Initialize(StereoKit.SKSettings)
   at ModelViewer.Application.Main(System.String[])

With 0.3.7-preview.9 the successful init log continue as follows:
...
20230706 13:59:19.131 --- [Varjo::Session::createSwapChain] Varjo::Session::createSwapChain, client: sdk#openxr#1000001718721317900
20230706 13:59:19.134 --- [Varjo::LayerClient::createSwapChain] createSwapchain... OK.
[SK diagnostic] Set view: PrimaryStereo to 4148x3556@1msaa
[SK diagnostic] Bounds updated: 0.00x0.00 at (0.0,0.0,0.0) (0.00,0.00,0.00,1.00)
[SK diagnostic] Initializing Audio
[SK diagnostic] ISAC audio backend not available, falling back to miniaudio! It's likely the device doesn't have Windows Sonic enabled, which can be found under Settings->Sound->Device Properties->Spatial Sound.
[SK info] Using audio backend: WASAPI
[SK diagnostic] Initializing Defaults
[SK diagnostic] Initializing World
[SK diagnostic] Initializing Sprites
[SK diagnostic] Initializing Lines
[SK diagnostic] Initializing UI
[SK diagnostic] Initializing Renderer
[SK diagnostic] Initializing Physics
[SK diagnostic] Initializing Input
[SK info] Initialization successful
...

Edit: added native call stack

Okay! Good news is that I actually can reproduce this using the Varjo simulator too. I've got a decent idea what's causing this, and I should have a fix for it relatively soon. Thanks for the details! :)

Ok, fix for this should be in tonight's build :)

With preview.1601 I indeed don't see the issue anymore, closing!


Fix tests

deleted tests/bootstrap.ts & tests/functional/hello_world.spec.ts

Alredy fixed on main: 919138a


Add ResNet18 accuracy checker config

ok, changes looks good. Do not merge this until R4 is done. It is content of the next release.


Regarding the use of impressions in MMM

I have a theoretical question about the use of exposure level metrics (such as impressions) in MMM. Since some of the models in LightweightMMM incorporate diminishing returns (channel saturation), does it make sense to use exposure level metrics as input? I was under the impression (no pun intended) that diminishing returns reflected on the relationship between spend and returns (be it impressions or sales) and NOT on the relationship between impressions and returns (such as sales)? I know it is possible to include both spend data and exposure level metrics in LightweightMMM, but would does including exposure level data work other than to calculate ROAS?

Hello @bart-vanvlerken !
In short it is okay to use impressions as your media unit. After all impressions is a proxy and highly correlated with spend, so one can establish the diminishing returns between impressions and returns as well.
Hope it helps!

Thanks Pablo!


Create an example Ng component that use D3.js

The goal of this task is to show how to use D3.js in an Ng app because Sage-Bionetworks/schema_visualization depends on it.
Look at the code I wrote for the PHI Collaboration Portal.

Actually I will do this only if Schematic team requests this.


Multiple bug in the terminal

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.74.0 (Universal)
OS Version: MacOS 13.0.1 (22A400)

First all, these problems only occur in version 1.74.0. They did not exist before I updated it.
Bug 1
Ghost String
Steps to Reproduce:

Copy two line text to terminal
Press any key

Bug 2
Garbled code
Steps to Reproduce:

Copy any Chinese text to terminal

Bug 3
Command history is strange, I can't go back to the previous records. I can only go back to the last few.
In versions prior to VSCode, the historical behavior of the terminal is consistent with that of iTerm. No matter which terminal I am in, I can quickly find the historical command by pressing the Up/Down key
Thank you for your time on VSCode, which is very important to me.

git log in terminal. has chinese text

git log in terminal. has chinese text

After installing this plugin, the problem fixed

/duplicate https://github.com/microsoft/vscode/issues/166936

Sorry Bug 2 is duplicate.
Bug 1 not in #166936, do you think Bug 1 and Bug 2 are same problem? @meganrogge
Supplement
Bug 3 is not an bug, This is a new default action. We can set "terminal.integrated.shellIntegration.enabled" to false in the settings file to go back to the previous.

Bug 1 is a duplicate of https://github.com/microsoft/vscode/issues/168458

Thanks a lot, Looking forward to the next version.

awesome, has fixed.


work with ops to gate access to linkurious and datashare by sunet/workgroup

will likely spawn a couple of more specific ops tasks ticket

related to #50, but if SSO is too much work for the dev capacity we currently have allocated, it'd still be useful to restrict who can reach the app using sunet/workgroup/webauth machinery.

@jmartin-sul Do you need me to set up a workgroup? Or do we have one?


Regression in average_gpu_usage in simple_animation_perf_ios

There have been two recent regressions since migrating to the iPhone 11 in the lab. The first one was small:
https://flutter-flutter-perf.skia.org/e/?begin=1672181480&end=1675553399&keys=X0d345e60408f7956175cccac38cc524f&requestType=0&selected=commit%3D32959%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DiPhone_11%252Cdevice_version%253Dnone%252Chost_type%253Dmac%252Csub_result%253Daverage_gpu_usage%252Ctest%253Dbackdrop_filter_perf_ios__timeline_summary%252C&xbaroffset=33206
We guessed that it was due to https://github.com/flutter/engine/pull/38989, but couldn't repro locally since the variance in gpu utilization is high.
This second one is larger:
https://flutter-flutter-perf.skia.org/e/?begin=1675463868&end=1675693416&keys=X0d345e60408f7956175cccac38cc524f&num_commits=50&request_type=1&xbaroffset=33206
There are two commits that seem like they might be related https://github.com/flutter/engine/pull/39172 and https://github.com/flutter/engine/pull/39359.
One reason GPU utilization might increase is that thanks to these changes, Flutter is now pushing frames at a higher rate. That would overall be a good thing. I'm filing this issue so that we can investigate whether that is the trade-off that we're making. Assigning @cyanglaz.

Looking at the commits in https://flutter-flutter-perf.skia.org/e/?begin=1675463868&end=1675693416&keys=X0de0ea40508c10467ea337e51588ebd4&selected=commit%3D33206%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DiPhone_11%252Cdevice_version%253Dnone%252Chost_type%253Dmac%252Csub_result%253Daverage_gpu_usage%252Ctest%253Dbackdrop_filter_perf_ios__timeline_summary%252C&xbaroffset=33206 , could it be the transparent background change too?

Yes. I think that's https://github.com/flutter/engine/pull/39359 linked above.

oops, reading while tired. need coffee

I was not able to reproduce this issue on the device I have. @cyanglaz / @jmagman will need to investigate, or we can do a preemtive revert to see if devicelab metrics return to normal

I wasn't able to reproduce the first one. I will check XCode instrument for GPU usage to see if I can find anything.
I'm Investigating the 2nd regression now.

https://github.com/flutter/engine/pull/39172 didn't have impact on the benchmark.
This is what I got when I revert https://github.com/flutter/engine/pull/39359: (iPhone 13pro)
average_gpu_usage       23.04 (0.00%)   1.73 (0.00%)    13.33x
The gpu_usage is 13.33x smaller, the opposite of the bench mark graph? Maybe setting background color to clearColor improved gpu usage on iPhone 13pro (reduced the nextDrawable time)?
The ci was running on iPhone 11, so maybe it actually behaves the opposite on a non-promotion device?
I have an appointment after lunch, I don't have an 11 but I'll try on my X when I'm back.

Tested on iPhone X:
average_gpu_usage       25.55 (0.00%)   5.23 (0.00%)    4.88x.
Not as significant as iPhone 13pro but I do see a significant reduction of gpu usage. I'm not sure how the ci showed a complete opposite result.
Where can we see the iOS version of the iPhone 11? Both of my devices are iOS 16.2+

are we getting higher GPU utilization because we're pushing through more frames? Or is it just higher with no other observable effects?
I'm really uncertain how useful this measurement is. Unless there is some more concrete regression I'm inclined to accept the changes

As @zanderso mentioned, I think high gpu usage while the app is animating is generally a good thing performance wise? Do we care about gpu life time? I don't have enough knowledge on this topic to know what other trade offs would be.

are we getting higher GPU utilization because we're pushing through more frames? Or is it just higher with no other observable effects?

Maybe we can add a new measurement on total number of frames pushed?

we should be tracking that already, I'm not sure if that particular benchmark contains it.

If we have local results that show a change is an improvement in metrics we care about heavily - in this case frame time, I would trust that over benchmark results we don't know how to interpret.

Added some other metrics including frame counts and I didn't see major differences. I don't know if we have better metrics to show janks. (A is after the PR, B is before the PR)
═════════════════════════╡ ••• Final A/B results ••• ╞══════════════════════════

Score   Average A (noise)       Average B (noise)       Speed-up
average_frame_build_time_millis 0.39 (0.00%)    0.40 (0.00%)    0.99x
worst_frame_build_time_millis   0.70 (0.00%)    2.19 (0.00%)    0.32x
90th_percentile_frame_build_time_millis 0.47 (0.00%)    0.47 (0.00%)    0.98x
99th_percentile_frame_build_time_millis 0.53 (0.00%)    0.55 (0.00%)    0.97x
average_frame_rasterizer_time_millis    8.26 (0.00%)    8.25 (0.00%)    1.00x
worst_frame_rasterizer_time_millis      10.07 (0.00%)   10.43 (0.00%)   0.97x
90th_percentile_frame_rasterizer_time_millis    8.44 (0.00%)    8.47 (0.00%)    1.00x
99th_percentile_frame_rasterizer_time_millis    8.87 (0.00%)    8.95 (0.00%)    0.99x
average_layer_cache_count       0.00 (0.00%)    0.00 (0.00%)    NaNx
90th_percentile_layer_cache_count       0.00 (0.00%)    0.00 (0.00%)    NaNx
99th_percentile_layer_cache_count       0.00 (0.00%)    0.00 (0.00%)    NaNx
worst_layer_cache_count 0.00 (0.00%)    0.00 (0.00%)    NaNx
average_layer_cache_memory      0.00 (0.00%)    0.00 (0.00%)    NaNx
90th_percentile_layer_cache_memory      0.00 (0.00%)    0.00 (0.00%)    NaNx
99th_percentile_layer_cache_memory      0.00 (0.00%)    0.00 (0.00%)    NaNx
worst_layer_cache_memory        0.00 (0.00%)    0.00 (0.00%)    NaNx
average_picture_cache_count     2.00 (0.00%)    2.00 (0.00%)    1.00x
90th_percentile_picture_cache_count     2.00 (0.00%)    2.00 (0.00%)    1.00x
99th_percentile_picture_cache_count     2.00 (0.00%)    2.00 (0.00%)    1.00x
worst_picture_cache_count       2.00 (0.00%)    2.00 (0.00%)    1.00x
average_picture_cache_memory    11.94 (0.00%)   11.94 (0.00%)   1.00x
90th_percentile_picture_cache_memory    11.94 (0.00%)   11.94 (0.00%)   1.00x
99th_percentile_picture_cache_memory    11.94 (0.00%)   11.94 (0.00%)   1.00x
worst_picture_cache_memory      11.94 (0.00%)   11.94 (0.00%)   1.00x
new_gen_gc_count        6.00 (0.00%)    6.00 (0.00%)    1.00x
old_gen_gc_count        0.00 (0.00%)    0.00 (0.00%)    NaNx
average_vsync_transitions_missed        1.00 (0.00%)    1.00 (0.00%)    1.00x
90th_percentile_vsync_transitions_missed        1.00 (0.00%)    1.00 (0.00%)    1.00x
99th_percentile_vsync_transitions_missed        1.00 (0.00%)    1.00 (0.00%)    1.00x
average_cpu_usage       37.51 (0.00%)   36.83 (0.00%)   1.02x
average_gpu_usage       22.28 (0.00%)   2.63 (0.00%)    8.49x
average_memory_usage    110.83 (0.00%)  110.68 (0.00%)  1.00x
90th_percentile_memory_usage    116.06 (0.00%)  116.02 (0.00%)  1.00x
99th_percentile_memory_usage    117.30 (0.00%)  117.03 (0.00%)  1.00x
30hz_frame_percentage   0.00 (0.00%)    0.00 (0.00%)    NaNx
60hz_frame_percentage   0.00 (0.00%)    0.00 (0.00%)    NaNx
80hz_frame_percentage   0.00 (0.00%)    0.00 (0.00%)    NaNx
90hz_frame_percentage   0.00 (0.00%)    0.00 (0.00%)    NaNx
120hz_frame_percentage  100.00 (0.00%)  100.00 (0.00%)  1.00x
illegal_refresh_rate_frame_count        0.00 (0.00%)    0.00 (0.00%)    NaNx
frame_count     1203.00 (0.00%) 1207.00 (0.00%) 1.00x
frame_rasterizer_count  1202.00 (0.00%) 1205.00 (0.00%) 1.00x
missed_frame_build_budget_count 0.00 (0.00%)    0.00 (0.00%)    NaNx
missed_frame_rasterizer_budget_count    0.00 (0.00%)    0.00 (0.00%)    NaNx
average_vsync_frame_lag 0.00 (0.00%)    0.00 (0.00%)    NaNx```

Given that there are no other regressions and the ambiguidy of this metric, I think we should accept the regression and move on. If more information comes to light we could reconsider.

Agreed. I'm going to look into the first one.

(Just wanted to record this result in issue so we don't lose it)
The local result of the first regression :
A is with the https://github.com/flutter/engine/pull/38989 change and B is without the change
(There are no significant difference, tested with iPhone X)
═════════════════════════╡ ••• Final A/B results ••• ╞══════════════════════════

Score   Average A (noise)       Average B (noise)       Speed-up
average_frame_build_time_millis 1.09 (0.00%)    1.08 (0.00%)    1.01x
worst_frame_build_time_millis   3.44 (0.00%)    2.23 (0.00%)    1.55x
90th_percentile_frame_build_time_millis 1.26 (0.00%)    1.27 (0.00%)    0.99x
99th_percentile_frame_build_time_millis 1.40 (0.00%)    1.36 (0.00%)    1.03x
average_frame_rasterizer_time_millis    16.42 (0.00%)   16.42 (0.00%)   1.00x
worst_frame_rasterizer_time_millis      19.55 (0.00%)   20.62 (0.00%)   0.95x
90th_percentile_frame_rasterizer_time_millis    16.89 (0.00%)   16.99 (0.00%)   0.99x
99th_percentile_frame_rasterizer_time_millis    18.66 (0.00%)   18.06 (0.00%)   1.03x
average_layer_cache_count       0.00 (0.00%)    0.00 (0.00%)    NaNx
90th_percentile_layer_cache_count       0.00 (0.00%)    0.00 (0.00%)    NaNx
99th_percentile_layer_cache_count       0.00 (0.00%)    0.00 (0.00%)    NaNx
worst_layer_cache_count 0.00 (0.00%)    0.00 (0.00%)    NaNx
average_layer_cache_memory      0.00 (0.00%)    0.00 (0.00%)    NaNx
90th_percentile_layer_cache_memory      0.00 (0.00%)    0.00 (0.00%)    NaNx
99th_percentile_layer_cache_memory      0.00 (0.00%)    0.00 (0.00%)    NaNx
worst_layer_cache_memory        0.00 (0.00%)    0.00 (0.00%)    NaNx
average_picture_cache_count     2.00 (0.00%)    2.00 (0.00%)    1.00x
90th_percentile_picture_cache_count     2.00 (0.00%)    2.00 (0.00%)    1.00x
99th_percentile_picture_cache_count     2.00 (0.00%)    2.00 (0.00%)    1.00x
worst_picture_cache_count       2.00 (0.00%)    2.00 (0.00%)    1.00x
average_picture_cache_memory    11.07 (0.00%)   11.07 (0.00%)   1.00x
90th_percentile_picture_cache_memory    11.07 (0.00%)   11.07 (0.00%)   1.00x
99th_percentile_picture_cache_memory    11.07 (0.00%)   11.07 (0.00%)   1.00x
worst_picture_cache_memory      11.07 (0.00%)   11.07 (0.00%)   1.00x
new_gen_gc_count        2.00 (0.00%)    2.00 (0.00%)    1.00x
old_gen_gc_count        0.00 (0.00%)    0.00 (0.00%)    NaNx
average_vsync_transitions_missed        1.00 (0.00%)    1.00 (0.00%)    1.00x
90th_percentile_vsync_transitions_missed        1.00 (0.00%)    1.00 (0.00%)    1.00x
99th_percentile_vsync_transitions_missed        1.00 (0.00%)    1.00 (0.00%)    1.00x
average_cpu_usage       49.72 (0.00%)   49.45 (0.00%)   1.01x
average_gpu_usage       14.47 (0.00%)   14.49 (0.00%)   1.00x
average_memory_usage    104.69 (0.00%)  104.67 (0.00%)  1.00x
90th_percentile_memory_usage    108.02 (0.00%)  107.92 (0.00%)  1.00x
99th_percentile_memory_usage    109.27 (0.00%)  109.16 (0.00%)  1.00x
30hz_frame_percentage   0.00 (0.00%)    0.00 (0.00%)    NaNx
60hz_frame_percentage   100.00 (0.00%)  100.00 (0.00%)  1.00x
80hz_frame_percentage   0.00 (0.00%)    0.00 (0.00%)    NaNx
90hz_frame_percentage   0.00 (0.00%)    0.00 (0.00%)    NaNx
120hz_frame_percentage  0.00 (0.00%)    0.00 (0.00%)    NaNx
illegal_refresh_rate_frame_count        0.00 (0.00%)    0.00 (0.00%)    NaNx
frame_count     602.00 (0.00%)  603.00 (0.00%)  1.00x
frame_rasterizer_count  601.00 (0.00%)  602.00 (0.00%)  1.00x
missed_frame_build_budget_count 0.00 (0.00%)    0.00 (0.00%)    NaNx
missed_frame_rasterizer_budget_count    523.00 (0.00%)  528.00 (0.00%)  0.99x
average_vsync_frame_lag 0.00 (0.00%)    0.00 (0.00%)    NaNx```

Thanks for investigating this @cyanglaz and @jonahwilliams.
Should we get rid of the gpu usage metric if we are fine with it going up and down? Or should we keep it as indicator that something happened and should still be investigated?

I would say we should stop tracking it if we don't know what to do with it.

In this case the fix for https://github.com/flutter/flutter/issues/103847 is likely pushing more frames, so it seems like a good trade-off since there's less jank.
I looked into this more, and I can see this metric regressing in the future on a more subtle change and investigation being require to understand why, since GPU usage does impact battery https://github.com/flutter/flutter/issues/31865#issuecomment-498537485.  I think we should keep it since it may help us track down future issues where battery is getting chewed up, but accept the regression in this case and close it.
Paper trail:
https://github.com/flutter/flutter/issues/31865
https://github.com/flutter/flutter/issues/58197
https://github.com/flutter/engine/pull/18516
flutter/engine#18752

Locally, I still couldn't find any regression related to the 3 commits in the first [regression on ci] (https://flutter-flutter-perf.skia.org/e/?begin=1672181480&end=1675553399&keys=X0d345e60408f7956175cccac38cc524f&requestType=0&selected=commit%3D32959%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DiPhone_11%252Cdevice_version%253Dnone%252Chost_type%253Dmac%252Csub_result%253Daverage_gpu_usage%252Ctest%253Dbackdrop_filter_perf_ios__timeline_summary%252C&xbaroffset=33206)
Can we try to revert the engine roll and confirm if it is really a regression caused by one of the 3 commits before digging into it more? @zanderso
Is this hard to revert sdk rolls? (especially there are probably already more sdk rolls after that commit?) If so, we can first try to revert my engine PR in the engine to see if it resolves the regression.

No, I don't think its reasonable to revert the entire engine roll. We can revert commits in the engine and let those roll into framework

https://flutter-flutter-perf.skia.org/e/?queries=arch%3Dintel%26branch%3Dmaster%26device_type%3DiPhone_11%26host_type%3Dmac%26sub_result%3Daverage_gpu_usage%26test%3Dbackdrop_filter_perf_ios__timeline_summary&selected=commit%3D33260%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DiPhone_11%252Cdevice_version%253Dnone%252Chost_type%253Dmac%252Csub_result%253Daverage_gpu_usage%252Ctest%253Dbackdrop_filter_perf_ios__timeline_summary%252C doesn't look like the revert fixed the ci. I don't think it was a jump that is related to the actual code.

To sum up. I think the first average_gpu regression is not related to commits and the 2nd is. However there are no other indications that the 2nd regression has negative impacts. Is there anything else that we can do before we call it and closing the issue?

The logs for the benchmarks show the same number of frames pushed both before and after (601).
before: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios backdrop_filter_perf_ios__timeline_summary/8797/overview
after: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios backdrop_filter_perf_ios__timeline_summary/8948/overview
You can click through to the timeline summaries in the log links step, and even download the timelines from the runs, but based on the summaries I don't think that will be useful.
This change takes average GPU utilization from ~3% to ~8%, and only this one benchmark was flagged. The culprit change solved a performance issue in other cases, so I think on balance we should accept this regression. Closing the issue.


Long lists not lazily loaded

Describe the bug
When using LazyVStack or ForEach, all content gets loaded immediately instead of when they become visible. I can get it to work with a List, but since that doesn't work with enableAppleScrollBehavior, the content scrolls before the list is expanded, completely breaking the scroll effect where the bottom sheet first expands before the content scrolls, so the user would have to use the little anchor to manually expand the sheet.
Minimal reproduce-able code
create a bottom sheet with 3 states and enableAppleScrollBehavior enabled.
contentView:
LazyVStack(alignment: .leading) {
    ForEach(items, id: \.id) { item in
        Text(item.name)
            .onAppear {
                print("Appeared: \(item.id")
            }
    }
}

Expected behavior
The content in LazyVStack to call onAppear only when it becomes visible
Target version

Environment: iOS iPhone 14 pro max simulator
Version: iOS 16.1 with project targeting iOS 14.0

Good point. I'm facing the same issue. Did anyone find out how to let it work as expected?

@lucaszischka Hello, any updates on this issue? Thanks!


Deleting an array disables reclamation for all arrays bound to that location manager

Original issue: https://charm.cs.illinois.edu/redmine/issues/1312

~~https://charm.cs.illinois.edu/gerrit/1114~~ https://github.com/UIUC-PPL/charm/commit/5a92b2880d91e5108d34782a77b151143c22aa54
The above change disabled sending reclaimRemote() messages to location manager instances that were going to be destroyed as a result of all associated arrays being destroyed. This change helps fix bug #1002.
In the case of bound arrays, one array being deleted permanently disables the reclaimRemote() calls in the associated location manager. I'm not sure of a present use case where this arises, but more dynamic future applications could stumble on this.
I thought AMPI might exhibit this in MPI_Comm_free, depending on how rank to index mapping works. If a given AMPI process is the same index in all arrays, and the ranks are mapped to indices by rank in MPI_COMM_WORLD, then there shouldn't be any cause to call reclaimRemote. I think that must be the case, because otherwise objects could become separated from their parent.

Original date: 2016-11-27 19:53:03

Actually, it looks like element deletion may destroy its corresponding CkLocRec and trigger this path regardless of whether there are any bound arrays. That means deleting one bound array would make all associated arrays fail in weird ways. That may require further investigation, and potentially bumps up the priority of fixing this.

Original date: 2016-11-27 20:08:19

I recently opened bug #1307 for AMPI_Comm_free (currently a no-op). I made a quick effort at implementing it, just calling ckDestroy on the local ampi chare array element for the given comm, and it failed weirdly. Haven't looked into it any more.

Original date: 2016-11-27 20:09:48

Interesting that we independently stumbled on this potential problem from opposite directions almost simultaneously.

Original date: 2016-12-20 05:12:30

Bumping priority to 'normal' since it effects AMPI and bound array deletion

Original date: 2017-02-26 17:37:39

I think this should be prioritized for merge before the release.

Original date: 2017-04-11 06:09:44

A potential fix for this is implemented in ~~https://charm.cs.illinois.edu/gerrit/#/c/2380/~~ https://github.com/UIUC-PPL/charm/commit/9278e1df90297e10e2df09a9a0a794f59878a480, however it would appear that the reclaimRemote method no long does what it is supposed to. It just attempts to delete the local CkLocRec, however a while back it was changed so that CkLocRecs get deleted at emigration, so there will never be a local rec to delete. Instead it should clean out location caches for the given idx/id.

Original date: 2017-04-11 20:35:00

A fix to the actual functionality of reclaimRemote has been posted here: ~~https://charm.cs.illinois.edu/gerrit/#/c/2385/~~ https://github.com/UIUC-PPL/charm/commit/2c90af974313f23dd244365b4f2a4d633ae4896c

Original date: 2017-04-12 18:44:22

Both patches have now been merged, so I think we're done here. Please re-open if that's not the case.


neovim

Except markdonw, it works

Without some other piece of information here, I don't think I can help.  I did release a new version of markdown2ctags with all the unicode bits in there, so you can use that or run from master again.  I believe it likely fixes the issue you are seeing.  I'm closing this issue.  If you turn up something more (error output from markdown2ctags, a file that fails from the command line, etc.), please open a new issue (or re-open this one, if it's related to neovim) and I'll take a look.  At this point, I don't feel there is anything more that I can do right now.


Clear RDCache for MLE and MAP estimation

Fixes #1418. The memoization cache is now cleared after each MLE/MAP optimize call only if ReverseDiff & Memoization are loaded -- I used a dispatched function called clearcache that does nothing if the two named packages aren't loaded, but clears the cache if they are both loaded.
Not sure what the tests here should be?

Or, perhaps we should just export emptyrdcache for users to track their own cache (not necessarily ideal). I'm wary of requiring people to create an OptimLogDensity themselves because they should be able to do whatever work they need with an instantiated model, rather than constructing miscellaneous intermediate types.

I'm wary of requiring people to create an OptimLogDensity themselves because they should be able to do whatever work they need with an instantiated model, rather than constructing miscellaneous intermediate types.

Oh, I don't think users should deal with creating an OptimLogDensity directly. I think instead of calling optimize they should call a function that gives them something they can just throw at (Galactic)Optim - either an objective function or an optimization problem that takes care of all conversions from parameter space to VarInfo, contexts etc.

How would we handle wrapping it up for people? I.e., how could we serve the optimal values in an interperetable way, so that they don't have to deal with a vector of parameters themselves?

By returning an OptimizationProblem: https://github.com/sciml/galacticoptim.jl

By providing both the optimization function/problem and a function for mapping the results back to the intuitive/interpretable formulation, similar to e.g. functor.

@cpfiffer Could you give this PR another shot? It seems like low-hanging fruit and we should be able to merge it quickly once the comments from @devmotion are addressed.

@cpfiffer Could you give this PR another shot? It seems like low-hanging fruit and we should be able to merge it quickly once the comments from @devmotion are addressed.

I'm not really convinced that this PR is the fix -- I think I agree with David that we should export a more generally optimization function and allow users to handle their own cache clearing. Maybe we should close this PR?

I'm not really convinced that this PR is the fix -- I think I agree with David that we should export a more generally optimization function and allow users to handle their own cache clearing. Maybe we should close this PR?

Closing it sounds good to me.

Closing it sounds good to me.


Disabling the linebreak-style rule in .eslintrc.js

Description
On a windows machine, there's a ton of eslint errors when you run "npm run dev" about "expecting line breaks LF instead of CRLF". I've added
*.js text eol=lf
to my gitattributes file, according to eslint documentation (https://eslint.org/docs/rules/linebreak-style) but its not still not working.
To Reproduce
Steps to reproduce the behavior:

Fork the repo
Clone it on your windows machine
Run 'npm install'
Run 'npm run dev' and you'll see the error

Desktop (please complete the following information)

OS: (windows 10)
Browser (ex. chrome, safari)

I think npm run lint -- --fix this will fix it, but will modify many files so whenever you are doing a git pull do a git stash and then whenever you are committing for a pull request add only that particular file(s) don't do a git add .
Wait for some more answers better than mine and then proceed

Hello I'm Jacqueline Binya.
I would love to work on this issue if its still open.

Hello I am Jacqueline Binya an Outreachy 2020 applicant.
I can disable the rule, may I work on this?
But after I disable the rule everyone pushing from a Windows machine would have to do what @hemanth-hk suggested otherwise they may risk introducing CLFR line breaks whilst the whole code-base uses LF.

The issue is already under review.
On Mar 8, 2020 08:59, "JackieBinya"<EMAIL_ADDRESS>wrote:

Hello I am Jacqueline Binya an Outreachy 2020 applicant.
I can disable the rule, may I work on this?
But after I disable the rule everyone pushing from a Windows machine would
have to do what @hemanth-hk https://github.com/hemanth-hk suggested
otherwise they may risk introducing CLFR line breaks whilst the whole
code-base uses LF.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/creativecommons/cccatalog-frontend/issues/649?email_source=notifications&email_token=AKZI4KIAK7KGVS4VR5MZMSLRGNF6VA5CNFSM4K37W6DKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOEPE7A#issuecomment-596177532,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKZI4KKHISHNVZHUWPOCLWLRGNF6VANCNFSM4K37W6DA
.

We've make some updates recently to the webpack and npm run dev doesn't show lint errors anymore. I think this is no longer relevant.
Feel free to reopen if you have any further suggestions


Convert Payment.received_on from datetime to date

We only care about the date when the payment was received so we don't need to keep the time.

Codecov Report

Merging #559 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #559   +/-   ##
========================================
  Coverage    96.39%   96.39%
========================================
  Files          123      123
  Lines         3609     3609
  Branches       319      319
========================================
  Hits          3479     3479
  Misses          90       90
  Partials        40       40

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3d3c089...8075256. Read the comment docs.


several comments: logic, scope of function, python idioms

I have a few comments about this function:

in general, the scope is too restrictive; why can't there be other external workflows besides nextflow? See the Varlociraptor workflow already forked. The command line switch should simply be something like --external and the script also simply check if a cubi/ subfolder exists.
the comparison operator is not in and not not ... in, see Pep8 programming recommendations
the if/else or rather elif/elif below checks a binary true/false condition, i.e. there are exactly two options. The code below checks if the condition is true, and if it is not, the code checks if the condition is false, which is a logical must.

https://github.com/core-unit-bioinformatics/devtools/blob/0393e1701100d6c307d339253cad21f3a051d0ed/update_template.py#L71-L80

Regarding 1), Yes I can make it more general and yes by manual setting --external, the script knows what to do. However it would be great if the tool would detect this automatically. "Simply check if cubi folder exists" - That ofc only works for an already established workflow/ folder structure. Imagine starting from an empty directory- there is no "cubi" folder. Therefore the script scans the workflow name to guess if its an external one. Sadly our workflow name definition does not inlcude an external tag. So its difficult to implement a solution for the script to know whether to create a cubi folder or put metadata files on the first level. If we dont find an automatic solution, I"ll make --external as a mandatory parameter
2)fixed
3) still open

Regarding 1) again: deactivated automatic external workflow detection. Needs now to be set manually with --external. I dont see a way for the script to detect an external workflow from the foldername of an empty folder.


feat: add comments, parameter names to ABI

currently the ABI only shows types.

It should show parameter names and comments if provided

Closing, docs can be handled externally and arg names are already there


Circular reference on this page

In the Connect to a Synapse Workspace, the Connect to Azure Synapse Link appears to point back to this same page.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5ccfb5cf-0a7d-220c-3f68-8ed5ea60bfa4
Version Independent ID: 080e66e3-d3bd-5915-1137-cf8c48671ecb
Content: Configure and use Azure Synapse Link for Azure Cosmos DB (preview)
Content Source: articles/cosmos-db/configure-synapse-link.md
Service: cosmos-db
GitHub Login: @srichintala
Microsoft Alias: srchi

@john-loughlin Thank you for making us aware of this issue. It appears that the correct link has now published.

The link now goes to: Connect to Azure Synapse Link (preview) for Azure Cosmos DB

We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


detectron2 vs sapiens for  MIMO

Sapiens:
Specialized in human-centric tasks: Sapiens excels at human pose estimation, body-part segmentation, and depth/normal estimation, making it ideal for complex human motion and interaction tasks in 3D-aware video synthesis, which is the core of MIMO.
High-fidelity human representation: Sapiens is built to handle high-resolution, detailed human imagery and motion, which aligns well with MIMO’s need for accurate and lifelike character videos.
Scalability: With models scaling up to 2 billion parameters, Sapiens provides the precision and generalization required for complex scenes and articulated human motions.
Detectron2:
General-purpose object detection: While powerful for object detection, segmentation, and keypoint detection, Detectron2 is not as specialized for tasks involving high-fidelity human understanding or 3D motion, which are critical for MIMO.
Broader applications but less specific: Detectron2 is more versatile for general object detection but does not offer the same human-specific capabilities and high-resolution support as Sapiens.

i add both
https://github.com/johndpope/MIMO-hack/blob/main/utils.py


stacked bar plotting error for multi-class model

I've trained a multi-class XGBoost model like the following:
import xgboost as xgb

# Get data
df_train_X = ... # 10000 x 82 dataframe
df_train_y = ... # 10000 x 1 dataframe

# Train using sklearn API
params = {
    'n_estimators': 500,
    'booster': 'gbtree',
    'objective': 'multi:softprob',
    'num_class': 31,
    ...
}
model = xgb.XGBClassifier(**params).fit(X=df_train_X, y=df_train_y)

The training data has 10,000 instances with 82 features each, and the target variable has 31 different classes.
I'd like to produce a stacked bar plot showing overall feature importance like this example. However, when i try to create the plot like
import shap

explainer = shap.TreeExplainer(model)
shap_values = explainer(df_train_X)
shap.summary_plot(shap_values, feature_names=df_train_X.columns, plot_type="bar")

I instead get a beeswarm interaction plot like

When i try to produce the plot like
shap.plots.bar(shap_values)

I get the following error:
IndexError                                Traceback (most recent call last)
<ipython-input-42-8c051e58575e> in <module>()
----> 1 shap.plots.bar(shap_values_tst)

/home/default_user/.conda/envs/user/lib/python3.7/site-packages/shap/plots/_bar.py in bar(shap_values, max_display, order, clustering, clustering_cutoff, merge_cohorts, show_data, show)
    157     for pos,inds in enumerate(orig_inds):
    158         if len(inds) == 1:
--> 159             feature_names_new.append(feature_names[inds[0]])
    160         else:
    161             full_print = " + ".join([feature_names[i] for i in inds])

IndexError: list index out of range

I am able to produce a normal looking bar plot for a single class like, e.g., the following:
class_ind = 5
shap.summary_plot(shap_values[:, :, class_ind], feature_names=df_train_X.columns, plot_type="bar")

Note: The shape of shap_values is N_instance X N_feature X N_class, whereas I was expecting N_class X N_instance X N_feature from the docs.
I'm using:

python == 3.7
shap == 0.39.0

Thanks for any help!

Update: I was able to get shap.summary_plot to work by passing in shap_values like the following:
shap.summary_plot(
    [shap_values[:, :, ind].values for ind in range(shap_values.shape[-1])],
    feature_names=df_train_X.columns,
    plot_type="bar"
)

Kind of hacky but it at least it gets the job done.

Hey @staubda,
thanks to your issue I could figure out my problem is also related to multi-class (random forest) model.
Also, I thought to share what I found out after reading other various posts in case it is useful. I get different behavior with these two objects
shap_obj = explainer(X1_train) shap_values = explainer.shap_values(X1_train)
And this is the plots I get with the two different objects

I would expect shap_obj.values to be equivalent to shap_values but it isn't (I started using shap yesterday, still digging)
Cheers,
Antonella


PingOne article

Status
Ready
Related Issues
fixes: https://github.com/demisto/etc/issues/21263

@yaakovi @RomanRapoport Sent updated article README to @teizenman.  Doc review completed.


[Feature Request] [Support] Close ticket if no response from invoker

New configuration option similar to the one where it closes if the user leaves the guild. It should be a set timer once the ticket is open for them to say something (what they need) before it closes.

This feature has been added as of now :)

This should only look for the ticket invoker to send a message, instead of just anyone. Lots of support people go, "Do you need anything" thus "disabling" the close timer.

It already does that.

I will re-test. Maybe it was a fluke on my end.


[CI] Some TPCH benchmarks started failing

Describe the bug, including details regarding any error messages, version, and platform.
When  https://github.com/apache/arrow/pull/34912 was merged, some TPCH benchmarks started failing. Here is a build with failed benchmarks: https://buildkite.com/apache-arrow/arrow-bci-benchmark-on-test-mac-arm/builds/2835
https://github.com/apache/arrow/pull/35364 fixed some of these failing TPCH benchmarks but these benchmarks are still failing:

Component(s)
Benchmarking

@icexelloss @rtpsw Could you take a look at this?

BTW, it's difficult to find error messages from the log. Is this a related error for this?
https://buildkite.com/apache-arrow/arrow-bci-benchmark-on-test-mac-arm/builds/2835#0187d7f0-b6aa-4a1a-b054-5873f056fdda/6-1380

[230501-13:39:32.996] [66823] [buildkite.benchmark.run] INFO: Started executing -> conbench tpch --iterations=3 --all=true --drop-caches=true --run-id=$RUN_ID --run-name="$RUN_NAME" --run-reason="$RUN_REASON"
--
  | Traceback (most recent call last):
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/_psosx.py", line 346, in wrapper
  | return fun(self, *args, **kwargs)
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/_common.py", line 480, in wrapper
  | raise raise_from(err, None)
  | File "<string>", line 3, in raise_from
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/_common.py", line 478, in wrapper
  | return fun(self)
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/_psosx.py", line 373, in _get_kinfo_proc
  | ret = cext.proc_kinfo_oneshot(self.pid)
  | ProcessLookupError: [Errno 3] assume no such process (originated from sysctl(kinfo_proc), len == 0)
  |
  | During handling of the above exception, another exception occurred:
  |
  | Traceback (most recent call last):
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/__init__.py", line 361, in _init
  | self.create_time()
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/__init__.py", line 719, in create_time
  | self._create_time = self._proc.create_time()
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/_psosx.py", line 346, in wrapper
  | return fun(self, *args, **kwargs)
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/_psosx.py", line 471, in create_time
  | return self._get_kinfo_proc()[kinfo_proc_map['ctime']]
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/_psosx.py", line 351, in wrapper
  | raise NoSuchProcess(self.pid, self._name)
  | psutil.NoSuchProcess: process no longer exists (pid=44552)
  |
  | During handling of the above exception, another exception occurred:
  |
  | Traceback (most recent call last):
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/runpy.py", line 194, in _run_module_as_main
  | return _run_code(code, main_globals, None,
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/runpy.py", line 87, in _run_code
  | exec(code, run_globals)
  | File "/opt/homebrew/var/buildkite-agent/builds/test-mac-arm/apache-arrow/arrow-bci-benchmark-on-test-mac-arm/buildkite/benchmark/monitor_memory.py", line 24, in <module>
  | mem_rss_bytes = psutil.Process(proc.pid).memory_info().rss
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/__init__.py", line 332, in __init__
  | self._init(pid)
  | File "/Users/voltrondata/miniconda3/envs/arrow-commit/lib/python3.8/site-packages/psutil/__init__.py", line 373, in _init
  | raise NoSuchProcess(pid, msg='process PID not found')
  | psutil.NoSuchProcess: process PID not found (pid=44552)

Can we improve log output?


Skip evaluation for rows with errors in Expr::evalSimplified

This is the first in set of PRs required to enable Try in the fuzzer.
This PR is an unabashed reproduction of @kevinwilfong's PR (https://github.com/facebookincubator/velox/pull/1455) with very slight modifications.
Currently the fuzzer fails when enabling TRY due to simple path evaluating expressions on rows that have already thrown an exception - this can throw an exception or other undefined behavior.
For e.g : try(regexp_extract(json_extract_scalar(X,"c0"),"c1")) , will still run regexp_extract for rows where json_extract_scalar has thrown.
In this PR we filter out those rows that have thrown exceptions.
Required but not sufficient for Issue: https://github.com/facebookincubator/velox/issues/3645

Hi @mbasmanova , The major reason I think we want to do this is we do not want function evaluation on rows that have garbage values , the end result as you note might be same, however its probably safer to not allow this to happen (perhaps functions have side effects, or request too much memory etc..).

its probably safer to not allow this to happen (perhaps functions have side effects, or request too much memory etc..).

Functions are not supposed to have side effects or request too much memory. In a way, it would be useful to catch these cases and fix the functions.

Abandoning this PR , since we would like to expose bugs in udfs.


Data for HTML figure/figcaption elements

Would be useful. Thanks.

Already exists: http://caniuse.com/#search=figure

@Ugoku
Thanks! Was fooled because it doesn't seem to be included in the list of elements on the homepage?

Yeah, browsers started supporting figure & figcaption together with a bunch of other semantic HTML5 elements so they're grouped together at http://caniuse.com/#feat=html5semantic


Recover interrupted eventhubs subscriptions

Description
This is an attempt to recover eventhubs topic subscription upon error.
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
~* [ ] Created/updated tests~
~* [ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]~

/ok-to-test

Components certification test
🔗 Link to Action run
Commit ref: bb2e600
❌ Some certification tests failed
These tests failed:

bindings.azure.eventhubs
bindings.rabbitmq
pubsub.aws.snssqs
pubsub.mqtt3
pubsub.pulsar

Tests failed here, including the eventhubs one.

Components certification test
🔗 Link to Action run
Commit ref: bb2e600
❌ Some certification tests failed
These tests failed:

bindings.azure.eventhubs
bindings.rabbitmq
pubsub.aws.snssqs
pubsub.mqtt3
pubsub.pulsar

Tests failed here, including the eventhubs one.

@yaron2 the eventhubs bindings test passed in this PR before - problem is that the 4  conformance and certification tests for eventhubs can't be run in parallel - they weren't designed well, so you manually need to restart them.


core: add fractional_scaling option

Allows users to enable and disable fractional scaling.
The auto option is default and enables fsv1 when on Hyprland or Niri.
Scaling of lock surfaces is currently broken on sway & river.
Closes #439

This is the fallback.
https://github.com/hyprwm/hyprlock/blob/6f5a6614378b0f0fc016f6127fd44d19d06cccfa/src/core/LockSurface.cpp#L94-L99
Compositor gives us the scaled surface via the configure event (size_)
Do we need to do anything else?

we need to make the buffer (scale)x the pixel size and send buffer_scale as (scale)

looks sharp to me I guess, thanks!

just make a wiki mr


Use reply count from post if thread not tracked in postsInThread reducer

Summary
Quick fix for CRT where unfollowed posts didn't have reply counts showing up in the center channel.
Release Note

NONE

Going to merge this as is since @koox00 and I already talked about it in a DM and it's fixing a glaring issue


Store Datasource UUIDs with hash of file in storage class

At the moment we don't store the Datasource UUIDs that a file's data is assigned to. This can cause issues when we want to delete a Datasource and re-standardise some data. If we remove the hash then we don't know about some of the data that is still stored in the other Datasources. We could just store a list of UUIDs the data has been assigned to with the dictionary of hashes.
hashes = {sha1_hash: [uuid1, uuid2, uuid3], ...}

When we want to delete a Datasource we can just remove its UUID from the list.

Closed by #1025


Adapt lib.rs doc test for endianness-dependent hash result

The exact in-memory byte representation of the u64 field of the example Data struct are dependent on architecture endianness.
This PR converts the doc test that's "broken" on big-endian architectures (e.g. s390x / System Z) to specific assertions gated by the target_endian cfg attribute.
Fixes #8

Thanks!


[BUG] Model converted from TorchScript gets stuck on qnn-net-run

Describe the bug
I have a model with only layers like Conv2d, LeakyReLU, Sigmoids and element-wise multiplications. The model converts successfully, here is an example job: https://app.aihub.qualcomm.com/jobs/jegn9nk5o/
However, running the model on device (Vivo X90 Pro+ with 8550 chipset) through qnn-net-run gets stuck.
If I run the model through the qnn-pytorch-converter it converts successfully and I can run it on device.
TorchScript can be downloaded here: https://drive.google.com/file/d/19Y2H8TyqEsJ_QbNISDBA98b_6RCYa38k/view?usp=share_link
To Reproduce

Download model from link above.
Run code to convert:

compile_job = qai_hub.submit_compile_job(
    model="checkpoints/Mock.pt",
    device=qai_hub.Device("Samsung Galaxy S23+"),
    options="--target_runtime qnn_lib_aarch64_android",
    input_specs=dict(image=x.shape),
)
compile_job.download_target_model("checkpoints/")

Create demo input with np.random.rand(256,256,1).astype(np.float32).tofile("input.raw") and a input list with echo input.raw > input.txt
Copy the model, demo input and input list to device
Run the model with qnn-net-run --backend libQnnHtp.so --model job_jegn9nk5o_optimized_so_m7n1evpm5.so --input_list input.txt

Expected behavior
The qnn-net-run command should exit after a few seconds, generating an output/Result_0 folder.
Stack trace
Stack trace with cancellation after a minute:
./qnn-net-run --backend libQnnHtp.so --model res/job_jegn9nk5o_optimized_so_m7n1evpm5.so --input_list res/input.txt
qnn-net-run pid:11906
WARNING: linker: Warning: unable to normalize "$/data/local/tmp/QNN-2.19" (ignoring)
WARNING: linker: Warning: unable to normalize "$/data/local/tmp/QNN-2.19" (ignoring)
^C

Host configuration:

QAI-Hub client version: '0.9.0'

Thank you for reporting this. I can confirm that I see the same behavior, although it does eventually finish for me after 10 minutes. I do not see this behavior when profiling via AI Hub and I do not yet know what the difference is. I thought it might be the htp graph optimization type, but even setting that to the slowest on AI Hub is super fast.
I'll keep digging.

I have forwarded this to the appropriate internal team at Qualcomm. I will let you know when I hear something.

@gustavla Thank your for following this - let me know if you get any feedback or if I can offer any help!


Allow exporting custom Resource variables from GDscript

This PR is based on the work by Will Nations (@willnationsdev) in
https://github.com/willnationsdev/godot/commits/gdres-3.2
It includes some extra changes to make it more robust to cyclic script
references and a minor bugfix. These changes were sponsored by IMVU.
In order to export a custom Resource:

Create a script that extends Resource (or any other Resource type) and give it a class_name

You are done! You can now export variables using the class name as a hint.

Inheritance works too :)

Thanks again to @willnationsdev for the awesome work!

@willnationsdev It would be nice if you could review this PR, I didn't make that many changes but I'd rather be safe :)

I don't see this implementation as user friendly.

Why is it so explicit? Why do you have to name it twice, using the class_name directive and the argument of add_custom_type?
Why is there an editor plugin at all for something that should just work outright when you extend the Resource class? Are we expecting all users to create editor plugins now to be able to export their Resource-based properties?

@willnationsdev Sorry, I did this changes a while back, so I kinda forgot how everything worked, I refreshed my mind now.
I double-checked and you are completely right, there is no need to add custom types through a plugin. I just did that because otherwise the Resource icons on the inspector menu didn't work properly, so it's just a minor issue.
Also, I am not a fan of custom types either, so I would also get rid of them if possible for 4.0
In general the only major problem I found was that the changes to the GDscript parser would load every script that was used as a class_name identifier (i.e. actually calling ResourceLoader::load() on them) creating a lot of dependency cycles that were not present before. My solution was to get rid of the changes to GDScriptParser::_parse_type() and instead grab the latest code from 3.2 (I now realized your branch was not up to date, sorry for the confusion). I left more details in your review comments.
Finally, if you want to continue this discussion and development on your own PR I'm all for it. This was my way to upstream the changes but you did the bulk of the work, I didn't mean to steal that from you :)

will this be picked for 3.2.4? it should be ... @willnationsdev seems to update his own recently as well, the proposal for this feature is one the highest liked

@JFonS I'm fine with you setting this up for upstream deployment. I have made some additional changes to my PR though, to fix a few things:

usage of get_global_class_base / get_global_class_native_base (since the _native_base one was added later and _base used to just be the native base).
add stuff for supporting drag-and-drop in EditorPropertyResource (don't think it was there before).

Feel free to consult the updated changes in my gdres_gd2 branch (NOT the gdres branch used for my pull request). I haven't actually updated the pull request directly yet because none of the GDScript parser changes can be done until more progress is made on GDScript 2.0.

@willnationsdev awesome! I will check it out.

so dos this allow for something like so?
export(MyCustomResource) var whatever

or do we need to do it like so?
export var whatever : MyCustomResource

Any update here? I'd LOVE to see this for 3.2.4! @akien-mga @Calinou @willnationsdev @vnen

@jonbonazza Well, before anything else, commits must be fixed to not have conflicts. Aside from that, it might just be a question of when it comes up in a PR meeting, though I don't see the pr meeting label on this Issue, so idk.

@JFonS have all of @willnationsdev concerns been addressed or are there any outstanding? Trying to push to see if this can be released in 3.2.4

@jonbonazza I'll try to take another look at the PR tonight to evaluate the changes.

Sorry, I've been focusing work on the CPU lightmapper which I would like to merge before 3.2.4 too.
@willnationsdev If you can allocate some time to work on this it would be great, otherwise I will do it eventually :)

@JFonS what work do you know that is left to do? If I can find some time this week, I can help try to finish it.

@jonbonazza If I remember correctly, everything was already working. All that's left to do is port the improvements that @willnationsdev did to his version of this PR (gdres_gd2 branch in his fork).

This is a must have improvement in UI/UX for Resources in Godot. Thanks all devs involved! 🥳🎉
Any chance the same support in C# soon ?

@vitorbalbio maybe in 4.0, if C# gets script class support. WIP draft PR for it already exists.

Just hit this problem, and I wonder, is class_name mandatory for this to work? None of my plugin uses class_name so far, and I was already able define custom types through add_custom_type, just the inspector is not able to recognize them.
Also I use the hint_string of _get_property_list to do this, instead of export.

@Zylann defining script classes instead of custom types is required. Custom types do not actually exist at runtime - they are merely an editor tool to auto-add a script to a node or resource upon instantiation from the Editor GUI. Without the script class info in the project.godot file, there is nothing mapping a name to a script filepath; the ScriptServer never deserializes the information and makes it available to scripting languages. The intent is actually to add script class support for all languages in 4.0 and completely deprecate and remove custom types.

@JFonS Do you have a sample test project you use to confirm that the features are working? I've developed a gdres-all-3.2 branch, built on top of my P22/script-classes-3.2 branch, that has script class support for all languages and enables you to define and export resources for all scripting languages from any scripting language. It would presumably replace this PR for 3.2, but I don't quite know if I'm missing anything from changes you made to my code. I would just want to make sure that I'm guaranteeing I don't lose any of your work in my own updated PR.

@JFonS Do you have a sample test project you use to confirm that the features are working? I've developed a gdres-all-3.2 branch, built on top of my P22/script-classes-3.2 branch, that has script class support for all languages and enables you to define and export resources for all scripting languages from any scripting language. It would presumably replace this PR for 3.2, but I don't quite know if I'm missing anything from changes you made to my code. I would just want to make sure that I'm guaranteeing I don't lose any of your work in my own updated PR.

Sorry for the delayed response, back from holidays now :)
Before the holiday break, we found some more issues in the GDscript parser. Specifically the fact that the parser was loading (and parsing IIRC) the scripts of the custom types used as export hints. This was causing trouble in exported projects the original .gd file was not present (it was a compiled .gdc file) and the parser didn't take this into account.
@RandomShaper did a clean-up of the parsing code and added a parsing mode that, instead of loading the exported script types,  keeps the class names in the parser tokens. This still allows for checking if the used type is a Resource (using ClassDB) but gets rid of all the cyclic reference and compiled scripts shenanigans.
(please correct me if I'm wrong @RandomShaper)
@willnationsdev I can dig up the patch for those changes, but at this point it would be a patch on top of a patch on top of a patch. So it might be easier just to get the general idea of the change and apply it manually on your branch.

Sorry for the delayed response, back from holidays now :)
Before the holiday break, we found some more issues in the GDscript parser. Specifically the fact that the parser was loading (and parsing IIRC) the scripts of the custom types used as export hints. This was causing trouble in exported projects the original .gd file was not present (it was a compiled .gdc file) and the parser didn't take this into account.
@RandomShaper did a clean-up of the parsing code and added a parsing mode that, instead of loading the exported script types,  keeps the class names in the parser tokens. This still allows for checking if the used type is a Resource (using ClassDB) but gets rid of all the cyclic reference and compiled scripts shenanigans.
(please correct me if I'm wrong @RandomShaper)
@willnationsdev I can dig up the patch for those changes, but at this point it would be a patch on top of a patch on top of a patch. So it might be easier just to get the general idea of the change and apply it manually on your branch.

Yes, I extended the boolean that tells whether to parse to get a constant to a three modes enum: constant, non-constant (both work as the old boolean), and a new constant-but-keep-classnames-as-identifiers. That one avoids having to lookup the classname from the script object when dealing with custom resource types.

Yes, I extended the boolean that tells whether to parse to get a constant to a three modes enum: constant, non-constant (both work as the old boolean), and a new constant-but-keep-classnames-as-identifiers. That one avoids having to lookup the classname from the script object when dealing with custom resource types.

@JFonS Yeah, I'd really like a copy of that patch, just so I can review the changes and compare it with what I have. The strategy I was previously using to handle the static type hint parsing wasn't working well, so I switched over to your technique, and so far everything has been fine in my demo project.
@RandomShaper Where is this "extended the boolean that tells whether to parse to get a constant"?
Could both of you provide an example of what sort of exported project script code caused your issue? Cause I just tried it with mine and it worked just fine.

@JFonS Yeah, I'd really like a copy of that patch, just so I can review the changes and compare it with what I have. The strategy I was previously using to handle the static type hint parsing wasn't working well, so I switched over to your technique, and so far everything has been fine in my demo project.
@RandomShaper Where is this "extended the boolean that tells whether to parse to get a constant"?
Could both of you provide an example of what sort of exported project script code caused your issue? Cause I just tried it with mine and it worked just fine.

@willnationsdev, my patch was done to some fork of Godot, which is older than 3.2. I've gotten a diff of the patch, here: https://pastebin.com/GWBLRtgK
It's quite hard to merge now because of conflicts. Maybe it's better or worse than the current approach.
Regarding the error itself, I'm making an effort to remember. I think that get_global_class_name() was trying to load the .gd file, instead of the .gdc. That could have been solved, but I decided to take a different route which avoided having to resolve class name from path in the first place.

@willnationsdev, my patch was done to some fork of Godot, which is older than 3.2. I've gotten a diff of the patch, here: https://pastebin.com/GWBLRtgK
It's quite hard to merge now because of conflicts. Maybe it's better or worse than the current approach.
Regarding the error itself, I'm making an effort to remember. I think that get_global_class_name() was trying to load the .gd file, instead of the .gdc. That could have been solved, but I decided to take a different route which avoided having to resolve class name from path in the first place.

Superseded by https://github.com/godotengine/godot/pull/44879.


Save functionality added in GUI file menu

#81 Added the save functionality in GUI filemenu

Please have a look at this.

ok.. i will look into it

@realsdx great :)

its for python3 only
in python2 its tkFileDialog... should i add support for python2 ???

@realsdx yes please, actually as of now the app is for both py2 and py3. So py2 support is required :)

Done.

@realsdx will review it ASAP

I forgot squash the commits, sorry for that

@realsdx since this is your second PR, it is a good time to learn how to squash commits. I would suggest you to squash your commits for this PR as it is very essential :)