The method [FlutterEngine makeThreadHost:] took too long to execute, triggering the watchdog mechanism in iOS.

Steps to reproduce
From the stack trace, it appears that the issue occurs when creating the io.flutter.1.io thread during app startup. The line +[FlutterEngine makeThreadHost:] + 1412 indicates the creation of the io thread. I am unable to reproduce this problem. I noticed this issue while exporting logs from an iOS device. It occurs with a probability of approximately 0.4%.
Expected results
no crash and watchdog
Actual results
The app freezes during launch.
Code sample
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: FRONTBOARD<PHONE_NUMBER>
<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-create watchdog transgression: application<xxx>:242 exhausted real (wall clock) time allowance of 19.80 seconds
ProcessVisibility: Foreground
ProcessState: Running
WatchdogEvent: scene-create
WatchdogVisibility: Foreground
WatchdogCPUStatistics: (
"Elapsed total CPU time (seconds): 83.130 (user 83.130, system 0.000), 70% CPU",
"Elapsed application CPU time (seconds): 0.123, 0% CPU"
) reportType:CrashLog maxTerminationResistance:Interactive>

Triggered by Thread:  0

Kernel Triage:
VM - pmap_enter retried due to resource shortage
VM - pmap_enter retried due to resource shortage
VM - pmap_enter retried due to resource shortage

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib        	       0x1cf58167c __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x1dfcec06c _pthread_cond_wait + 1232
2   libc++.1.dylib                	       0x1a0121acc std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28
3   Flutter                       	       0x107d7dab0 fml::AutoResetWaitableEvent::Wait() + 72
4   Flutter                       	       0x107e749e4 flutter::ThreadHost::CreateThread(flutter::ThreadHost::Type, std::__1::optional<fml::Thread::ThreadConfig>, flutter::ThreadHost::ThreadHostConfig const&) const + 820
5   Flutter                       	       0x107aa873c +[FlutterEngine makeThreadHost:] + 1412
6   Flutter                       	       0x107aa13ec -[FlutterEngine createShell:libraryURI:initialRoute:] + 860
7   Flutter                       	       0x107abb908 -[FlutterViewController sharedSetupWithProject:initialRoute:] + 408
8   Flutter                       	       0x107abb748 -[FlutterViewController awakeFromNib] + 88
9   UIKitCore                     	       0x193ecfaf8 -[UINib instantiateWithOwner:options:] + 1740
10  UIKitCore                     	       0x193ece140 -[UIStoryboard __reallyInstantiateViewControllerWithIdentifier:creator:storyboardSegueTemplate:sender:] + 236
11  UIKitCore                     	       0x193ecdf7c -[UIStoryboard _instantiateViewControllerWithIdentifier:creator:storyboardSegueTemplate:sender:] + 80
12  UIKitCore                     	       0x193ede06c -[UIApplication _loadMainStoryboardFileNamed:bundle:] + 140
13  UIKitCore                     	       0x194019384 -[UIApplication _loadMainInterfaceFile] + 156
14  UIKitCore                     	       0x193f900a8 -[UIApplication _runWithMainScene:transitionContext:completion:] + 688
15  UIKitCore                     	       0x193f8fd9c -[_UISceneLifecycleMultiplexer completeApplicationLaunchWithFBSScene:transitionContext:] + 132
16  UIKitCore                     	       0x193cd5e74 _UIScenePerformActionsWithLifecycleActionMask + 108
17  UIKitCore                     	       0x194017d78 __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke + 216
18  UIKitCore                     	       0x193ec8adc -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] + 220
19  UIKitCore                     	       0x193ec8904 -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 620
20  UIKitCore                     	       0x193ec84b4 -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] + 252
21  UIKitCore                     	       0x193ec8380 __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke + 148
22  UIKitCore                     	       0x1945ac56c +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:] + 736
23  UIKitCore                     	       0x194646568 _UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion + 224
24  UIKitCore                     	       0x193d74374 -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 316
25  UIKitCore                     	       0x1941e7294 __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.214 + 556
26  UIKitCore                     	       0x193e469a0 -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 216
27  UIKitCore                     	       0x193e46810 -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244
28  UIKitCore                     	       0x193e45d64 -[UIApplication workspace:didCreateScene:withTransitionContext:completion:] + 520
29  UIKitCore                     	       0x193e45af0 -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:] + 288
30  FrontBoardServices            	       0x1a77e4e90 -[FBSScene _callOutQueue_agent_didCreateWithTransitionContext:completion:] + 344
31  FrontBoardServices            	       0x1a78248f8 __92-[FBSWorkspaceScenesClient createSceneWithIdentity:parameters:transitionContext:completion:]_block_invoke.78 + 120
32  FrontBoardServices            	       0x1a77e8c24 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168
33  FrontBoardServices            	       0x1a7824530 __92-[FBSWorkspaceScenesClient createSceneWithIdentity:parameters:transitionContext:completion:]_block_invoke + 360
34  libdispatch.dylib             	       0x199084f88 _dispatch_client_callout + 20
35  libdispatch.dylib             	       0x199088a08 _dispatch_block_invoke_direct + 264
36  FrontBoardServices            	       0x1a77f2d40 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 52
37  FrontBoardServices            	       0x1a77f28dc -[FBSSerialQueue _targetQueue_performNextIfPossible] + 220
38  FrontBoardServices            	       0x1a77f5184 -[FBSSerialQueue _performNextFromRunLoopSource] + 28
39  CoreFoundation                	       0x191b38f24 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
40  CoreFoundation                	       0x191b452fc __CFRunLoopDoSource0 + 176
41  CoreFoundation                	       0x191ac91c0 __CFRunLoopDoSources0 + 244
42  CoreFoundation                	       0x191adeb7c __CFRunLoopRun + 836
43  CoreFoundation                	       0x191ae3eb0 CFRunLoopRunSpecific + 612
44  GraphicsServices              	       0x1cbcd9368 GSEventRunModal + 164
45  UIKitCore                     	       0x193fd9668 -[UIApplication _run] + 888
46  UIKitCore                     	       0x193fd92cc UIApplicationMain + 340
47  Runner                        	       0x104e85348 main + 60
48  dyld                          	       0x1b03dc960 start + 2528

Thread 1 name:   Dispatch queue: com.apple.UIKit.KeyboardManagement
Thread 1:
0   libsystem_kernel.dylib        	       0x1cf5818e0 __ulock_wait + 8
1   libdispatch.dylib             	       0x199085978 _dlock_wait + 56
2   libdispatch.dylib             	       0x19908572c _dispatch_thread_event_wait_slow + 56
3   libdispatch.dylib             	       0x199094860 __DISPATCH_WAIT_FOR_QUEUE__ + 368
4   libdispatch.dylib             	       0x19909440c _dispatch_sync_f_slow + 144
5   UIKitCore                     	       0x193fd993c __37-[_UIRemoteKeyboards startConnection]_block_invoke_3 + 156
6   CoreFoundation                	       0x191ad76b4 __invoking___ + 148
7   CoreFoundation                	       0x191a83b1c -[NSInvocation invoke] + 428
8   Foundation                    	       0x18be77878 __NSXPCCONNECTION_IS_CALLING_OUT_TO_REPLY_BLOCK__ + 16
9   Foundation                    	       0x18be48c00 -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] + 520
10  Foundation                    	       0x18c4220c4 __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_5 + 188
11  libxpc.dylib                  	       0x1dfd45d48 _xpc_connection_reply_callout + 124
12  libxpc.dylib                  	       0x1dfd38b90 _xpc_connection_call_reply_async + 88
13  libdispatch.dylib             	       0x199085008 _dispatch_client_callout3 + 20
14  libdispatch.dylib             	       0x1990a2f58 _dispatch_mach_msg_async_reply_invoke + 344
15  libdispatch.dylib             	       0x19908c518 _dispatch_lane_serial_drain + 376
16  libdispatch.dylib             	       0x19908d1c0 _dispatch_lane_invoke + 436
17  libdispatch.dylib             	       0x199097e10 _dispatch_workloop_worker_thread + 652
18  libsystem_pthread.dylib       	       0x1dfce4df8 _pthread_wqthread + 288
19  libsystem_pthread.dylib       	       0x1dfce4b98 start_wqthread + 8

Thread 2:
0   libsystem_pthread.dylib       	       0x1dfce4b90 start_wqthread + 0

Thread 3 name:   Dispatch queue: com.apple.root.background-qos
Thread 3:
0   CoreFoundation                	       0x191a66278 CFEqual + 1152
1   CoreFoundation                	       0x191ae62ec CFCachedStringEqual + 52
2   CoreFoundation                	       0x191ae62ec CFCachedStringEqual + 52
3   CoreFoundation                	       0x191b14e6c _CFXNotificationRegistrarFindName + 104
4   CoreFoundation                	       0x191b400e8 _CFXNotificationRegistrarAddName + 64
5   CoreFoundation                	       0x191af6924 CFXNotificationRegistrarAdd + 524
6   CoreFoundation                	       0x191b0db1c _CFXNotificationRegisterObserver + 248
7   libdispatch.dylib             	       0x199083460 _dispatch_call_block_and_release + 32
8   libdispatch.dylib             	       0x199084f88 _dispatch_client_callout + 20
9   libdispatch.dylib             	       0x199096b8c _dispatch_root_queue_drain + 684
10  libdispatch.dylib             	       0x199097284 _dispatch_worker_thread2 + 164
11  libsystem_pthread.dylib       	       0x1dfce4dbc _pthread_wqthread + 228
12  libsystem_pthread.dylib       	       0x1dfce4b98 start_wqthread + 8

Thread 4:
0   libsystem_pthread.dylib       	       0x1dfce4b90 start_wqthread + 0

Thread 5 name:  com.apple.uikit.eventfetch-thread
Thread 5:
0   libsystem_kernel.dylib        	       0x1cf580da8 mach_msg2_trap + 8
1   libsystem_kernel.dylib        	       0x1cf593a1c mach_msg2_internal + 80
2   libsystem_kernel.dylib        	       0x1cf593c5c mach_msg_overwrite + 388
3   libsystem_kernel.dylib        	       0x1cf5812ec mach_msg + 24
4   CoreFoundation                	       0x191addac4 __CFRunLoopServiceMachPort + 160
5   CoreFoundation                	       0x191aded08 __CFRunLoopRun + 1232
6   CoreFoundation                	       0x191ae3eb0 CFRunLoopRunSpecific + 612
7   Foundation                    	       0x18be18054 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
8   Foundation                    	       0x18be17f3c -[NSRunLoop(NSRunLoop) runUntilDate:] + 64
9   UIKitCore                     	       0x19410e6a4 -[UIEventFetcher threadMain] + 436
10  Foundation                    	       0x18be31518 __NSThread__start__ + 716
11  libsystem_pthread.dylib       	       0x1dfce56cc _pthread_start + 148
12  libsystem_pthread.dylib       	       0x1dfce4ba4 thread_start + 8

Thread 6 name:  io.flutter.1.ui
Thread 6:
0   libsystem_kernel.dylib        	       0x1cf580da8 mach_msg2_trap + 8
1   libsystem_kernel.dylib        	       0x1cf593a1c mach_msg2_internal + 80
2   libsystem_kernel.dylib        	       0x1cf593c5c mach_msg_overwrite + 388
3   libsystem_kernel.dylib        	       0x1cf5812ec mach_msg + 24
4   CoreFoundation                	       0x191addac4 __CFRunLoopServiceMachPort + 160
5   CoreFoundation                	       0x191aded08 __CFRunLoopRun + 1232
6   CoreFoundation                	       0x191ae3eb0 CFRunLoopRunSpecific + 612
7   Flutter                       	       0x107d7f2b8 fml::MessageLoopDarwin::Run() + 88
8   Flutter                       	       0x107d7ec9c void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, fml::Thread::Thread(std::__1::function<void (fml::Thread::ThreadConfig const&)> const&, fml::Thread::ThreadConfig const&)::$_0> >(void*) + 208
9   libsystem_pthread.dylib       	       0x1dfce56cc _pthread_start + 148
10  libsystem_pthread.dylib       	       0x1dfce4ba4 thread_start + 8

Thread 7 name:  io.flutter.1.raster
Thread 7:
0   libsystem_kernel.dylib        	       0x1cf580da8 mach_msg2_trap + 8
1   libsystem_kernel.dylib        	       0x1cf593a1c mach_msg2_internal + 80
2   libsystem_kernel.dylib        	       0x1cf593c5c mach_msg_overwrite + 388
3   libsystem_kernel.dylib        	       0x1cf5812ec mach_msg + 24
4   CoreFoundation                	       0x191addac4 __CFRunLoopServiceMachPort + 160
5   CoreFoundation                	       0x191aded08 __CFRunLoopRun + 1232
6   CoreFoundation                	       0x191ae3eb0 CFRunLoopRunSpecific + 612
7   Flutter                       	       0x107d7f2b8 fml::MessageLoopDarwin::Run() + 88
8   Flutter                       	       0x107d7ec9c void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, fml::Thread::Thread(std::__1::function<void (fml::Thread::ThreadConfig const&)> const&, fml::Thread::ThreadConfig const&)::$_0> >(void*) + 208
9   libsystem_pthread.dylib       	       0x1dfce56cc _pthread_start + 148
10  libsystem_pthread.dylib       	       0x1dfce4ba4 thread_start + 8

Thread 8 name:  io.flutter.1.io
Thread 8:
0   libsystem_kernel.dylib        	       0x1cf580da8 mach_msg2_trap + 8
1   libsystem_kernel.dylib        	       0x1cf593a1c mach_msg2_internal + 80
2   libsystem_kernel.dylib        	       0x1cf589f64 _kernelrpc_thread_policy_set + 184
3   libsystem_kernel.dylib        	       0x1cf58a840 thread_policy_set + 24
4   Foundation                    	       0x18be8d268 -[NSThread _setThreadPriority:] + 280
5   Flutter                       	       0x107d7ec14 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, fml::Thread::Thread(std::__1::function<void (fml::Thread::ThreadConfig const&)> const&, fml::Thread::ThreadConfig const&)::$_0> >(void*) + 72
6   libsystem_pthread.dylib       	       0x1dfce56cc _pthread_start + 148
7   libsystem_pthread.dylib       	       0x1dfce4ba4 thread_start + 8

Thread 9:
0   libsystem_pthread.dylib       	       0x1dfce4b90 start_wqthread + 0

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.3.10, on macOS 14.1.1 23B81 darwin-arm, locale zh-Hans-CN)

Hi @nullLuli, you appear to be using an older version of the flutter framework, kindly upgrade to the latest version of flutter stable (3.16.4) to see if you still experience this issue.
If you do, please provide the updated output of flutter doctor -v along with a complete minimal reproducible code sample so that we can investigate this issue.
Thank you

Thank you for your response, but I'm afraid I won't be able to upgrade the Flutter version in the short term. Our product has strict stability requirements, and upgrading would require adaptation work. It took us 2 months to stabilize the crash rate when we upgraded to version 3.3.10 last time. On the other hand, the methods in the crash stack trace are functionalities from the flutter/engine. I have examined the methods +[FlutterEngine makeThreadHost:], flutter::ThreadHost::CreateThread, and AutoResetWaitableEvent::Wait in the crash stack trace. The latest code in the flutter/engine repository on GitHub is no different from version 3.3.10, except for the change in the syntax of flutter::ThreadHost::Type, which was changed from flutter::ThreadHost::Type::UI to flutter::ThreadHost::Type::kUi. Therefore, I don't have much hope that upgrading to a new version will solve this issue.

I also wish I could provide you with a minimal reproducible code, but unfortunately, I cannot determine it myself. This issue does not occur 100% of the time and can only be discovered from the IPS logs collected from user devices. Additionally, I am curious, how do you usually troubleshoot and resolve issues that cannot be consistently reproduced?

If I must provide a minimal reproducible code, I believe specifying the startup page type as FlutterViewController in a xib file can reproduce the issue. From the stack trace -[FlutterViewController awakeFromNib], it can be observed that the Flutter page encounters a watchdog issue during initialization before other operations can take place.

Hi @nullLuli, unfortunately, without a minimal reproducible sample or some steps to reproduce on a version as old as yours, there isn't a way we can take this forward. While the code may not have changed, improvements in other areas could have resolved the bug in newer versions.
Do you have a way to track user journeys in your app that may reveal what the user goes through before the crash happens?
How many instances of this crash do you have?
What device(s) are seeing this and what are their os versions?
Lastly, can you take a look at the issues below to see if they are similar to your case?
https://github.com/flutter/flutter/issues/132666
https://github.com/flutter/flutter/issues/102031

I think this is similar to https://github.com/flutter/engine/pull/34568, modifying the priority of the IO thread might be helpful. The implementation of AutoResetWaitableEvent is causing priority inversion, where the main thread is constantly waiting for the IO thread, which has a lower priority. I will try raising the priority of the IO thread to normal, which is the current state in the flutter/engine main branch, and provide feedback on the results after some time.


Reverts https://github.com/kubevirt/kubevirt/pull/5428
Need to research this flake first
https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5551/pull-kubevirt-e2e-k8s-1.20-sig-network/1387317121746210816
Signed-off-by: Or Shoval<EMAIL_ADDRESS>None

/cc @AlonaKaplan @phoracek

/approve

/test pull-kubevirt-unit-test

/retest

/test pull-kubevirt-e2e-k8s-1.19-sig-storage

/retest
some network issue it seems (when installing go libs)

https://github.com/kubevirt/kubevirt/pull/5560 should solve it
(in case the revert will be merged first, i will include the reverted again there)

https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5557/pull-kubevirt-unit-test/1387570703514996736
Checking if its related, i believe not, because i just revert code here which was added yesterday


Textual enrichment

Current coverage is 100% (diff: 100%)

Merging #28 into master will not change coverage

@@           master   #28   diff @@
===================================
  Files           1     1
  Lines          82   124    +42
  Methods        18    27     +9
  Messages        0     0
  Branches       11    15     +4
===================================
+ Hits           82   124    +42
  Misses          0     0
  Partials        0     0

Powered by Codecov. Last update 7099325...d755572


[Test Stable][FLINK-28352] PulsarSourceITCase still buggy on Flink CI

[x] [FLINK-26721]PulsarSourceITCase.testSavepoint failed on azure pipeline
[x] [FLINK-23944]PulsarSourceITCase.testTaskManagerFailure is instable
[x] [FLINK-26177]PulsarSourceITCase.testScaleDown fails with timeout
[x] [FLINK-25815]PulsarSourceITCase.testTaskManagerFailure failed on azure due to timeout
[x] [FLINK-27833]PulsarSourceITCase.testTaskManagerFailure failed with AssertionError
[x] [FLINK-24872]PulsarSourceITCase.testMultipleSplits failed on AZP
[x] [FLINK-25884]PulsarSourceITCase.testTaskManagerFailure failed on azure
[ ] [FLINK-27917]PulsarUnorderedPartitionSplitReaderTest.consumeMessageCreatedBeforeHandleSplitsChangesAndResetToEarliestPosition failed with AssertionError
[ ] [FLINK-27388]PulsarSourceEnumeratorTest#discoverPartitionsTriggersAssignments seems flaky
[ ] [FLINK-25740]PulsarSourceOrderedE2ECase fails on azure
[ ] [FLINK-26238]PulsarSinkITCase.writeRecordsToPulsar failed on azure
[ ] [FLINK-26237]PulsarSourceOrderedE2ECase failed on azure due to timeout
[ ] [FLINK-26980]PulsarUnorderedSourceReaderTest hang on azure
[ ] [FLINK-26240]PulsarSinkITCase.tearDown failed in azure
[ ] [FLINK-24302]Direct buffer memory leak on Pulsar connector with Java 11

First PR for fixing all the PulsarSourceITCase issues: https://issues.apache.org/jira/browse/FLINK-27399

The last two test cases should be resolved on Pulsar.


Popup's on_dismiss is called before its on_open

Versions

Python: 3.5.2
OS: linux
Kivy: 1.10.0

Description
When I do two actions which should open and close a popup fast enough (click on 'save' button which opens the popup, and then click somewhere else on the screen which closes it), I see in debug mode that on_dismiss is called before on_open, and that causes all kind of problems. How can this be?
I don't use the keyboard in this use-case, so I don't think the inheritance from my KeyboardListener is unrelated to the problem, but I added it here for any case.
Code and Logs
from kivy.uix.popup import Popup
from kivy.event import EventDispatcher

class TinyPopup(Popup, KeyboardListener):
    '''
    A base class for popups in our systems
    '''

    dismiss_callback = ObjectProperty()
    '''Call this callback when the popup is closed
    '''

    cancel_callback = ObjectProperty()
    '''Call this callback when the popup is canceled
    '''

    def on_open(self):
        '''
        Called when the popup is opened
        :return: Notnig
        :rtype: None
        '''
        # Register for keyboard events
        self.register_for_keyboard_listening()

    def on_dismiss(self):
        ''''Call this when the popup is dismissed
        '''
        # Unregister for keyboard events
        self.stop_listening_to_keyboard()

        # Call the dismiss_callback if we have it
        if self.dismiss_callback is not None:
            self.dismiss_callback()

    def on_keyboard_down(self, keyboard, keycode, text, modifiers):
        '''
        Act when a key is pressed down
        :param keyboard: The keyboard object
        :param keycode: The pressed key code
        :param text: The text that was pressed
        :param modifiers: A list of keyboard modifiers
        :return: True to accept the key, or False to ignore it
        '''
        if keycode[1] == 'escape':
            # Dismiss popup upon 'Esc'
            self.dismiss()

            # Call the cancel_callback if we have it
            if self.cancel_callback is not None:
                self.cancel_callback()

        # Grag all keyboard events so that the base app doesn't get anything
        return True

class KeyboardListener(EventDispatcher):
    '''
    A Keyboard listener
    '''

    def register_for_keyboard_listening(self, *args):
        '''
        Start listening to the keyboard
        '''
        if get_top_widget() is not None:
            get_top_widget().add_keyboard_listener(self)
        else:
            Clock.schedule_once(self.register_for_keyboard_listening, 0)

    def stop_listening_to_keyboard(self):
        '''
        Stop listening to the keyboard
        '''
        get_top_widget().remove_keyboard_listener(self)

    def on_keyboard_down(self, keyboard, keycode, text, modifiers):
        '''
        Act upon keyboard strokes. Subclasses should implement this
        :param keyboard: The keyboard object
        :param keycode: The pressed key code
        :param text:
        :param modifiers: A list of keyboard modifiers
        :return: True to accept the key, rahter than passing it forward
        '''
        raise NotImplementedError

class TinyPopup(Popup, KeyboardListener):

Probably not related, but generally you want to list the mixin class before the widget class here, as documented for behaviors
I notice that there is a delay which defaults to .1 seconds for dispatching on_open, but no delay for on_dismiss.
That might explain it, if you are closing the popup within the 0.1 seconds? Apart from that I don't know - can you make this into a runnable example to demonstrate the issue?

 When I change _anim_duration to 0 (In TinyPopup) it fixes the problem.
Is it safe though? What's the purpose of this delay?


Fix/132 es6 modules

Fixes #132
Also I've added few TODOs related to using ES6 features.

This is great, thank you!

NP, I'm glad to help.

@nrc Seems that I need to fix application bootstrap step. Sorry for that. Will create a PR.

#144


Add postgresql-simple-migration

https://github.com/ameingast/postgresql-simple-migration/issues/11

directory-<IP_ADDRESS> is out of bounds for:

[ ] postgresql-simple-migration-<IP_ADDRESS> (==1.2.*). Taylor Fausak<EMAIL_ADDRESS>@tfausak. @ ameingast. Used by: library, executable
hspec-2.3.2 (Simon Hengel<EMAIL_ADDRESS>@sol) is out of bounds for:
[ ] postgresql-simple-migration-<IP_ADDRESS> (==2.2.*). Taylor Fausak<EMAIL_ADDRESS>@tfausak. @ ameingast. Used by: test-suite

Should be fixed in postgresql-simple-migration-<IP_ADDRESS>.

Thanks!


update notebooks to reflect change in opentopo

@sssangha Can you review?
@bbuzz31 Could you add the capability to do notebook review? Perhaps check with @yunjunz or mintpy repo in case of questions how to enable it.

@bbuzz31 Could you add the capability to do notebook review? Perhaps check with @yunjunz or mintpy repo in case of questions how to enable it.

It should be straightforward to link ReviewNB (https://www.reviewnb.com/) with the Github repo, one might need the admin permission to enable it.

Thanks @yunjunz I added it in now. Hopefully works for the next PR.

@bbuzz31 the rendering is not yet working, so best is to click on respond via the review-notebook tool. I did my review using the tool outside github as it was not showing here (I believe next time we will have it working).
In summary:

I think some cells did not work, so would check if this is an error or not
the verbose does not print product download summary
the download does not give progress which could be problematic
the version of ARIA-tools did we capture that now correctly in the code? @yunjunz had suggest a specific approach similar to mintpy where you pull it from some sort of version file. Suggest we adopt that.
some more description would be beneficial for the program help function.

Per Sim: I believe so, but it prioritizes the new tif formats for sureSo it looks for duplicates and discards binary format if tif exists. Help is updated to reflect this.

View entire conversation on ReviewNB

I had an older version of asf_search.py installed that errors out on duplicate products. New version just puts a warning.

View entire conversation on ReviewNB

@dbekaert You caught a lot of bugs, thanks for going through these in such detail!
I think I've addressed all the comments, and commits are here and  https://github.com/aria-tools/ARIA-tools/pull/306.
The one outstanding task is the progress bar for the download.

@bbuzz31 the rendering is not yet working, so best is to click on respond via the review-notebook tool. I did my review using the tool outside github as it was not showing here (I believe next time we will have it working).
In summary:
* I think some cells did not work, so would check if this is an error or not

* the verbose does not print product download summary

* the download does not give progress which could be problematic

* the version of ARIA-tools did we capture that now correctly in the code? @yunjunz had suggest a specific approach similar to mintpy where you pull it from some sort of version file. Suggest we adopt that.

* some more description would be beneficial for the program help function.

@bbuzz31 apologies, but this had slipped me. However, I had reshuffled the .netrc/.topoapi generation step to the top "prep" sections and made it so that a user explicitly has to enter their credentials if these files don't exist. Please refer to PR #47

@bbuzz31 following my initial message, I believe it would be easier to merge my suggested changes here. Namely, I've added the following:

Add topoapi check + cleanup .netrc checks and move all to prep stage(s) at top of notebook.
If a given file doesn't exist, and explicit warning is passed, plus a prompt for users to enter their credentials.

I'll keep the aforementioned PR in draft form for now for reference, but I intend to merge this to master

@sssangha there are numerous other small changes in this PR besides the topo check. Can you clarify whether you're going to merge this branch and #47?

@bbuzz31 my plan is to close #47 and merge this one. I had essentially moved the .netrc and .topoapi checks to the top within the Prep sections. We could merge and proceed with this branch

Oh I see now. Sounds good!


FileScan from URL

Provide a function to scan a file from a URL.
It would be nice if there was a way to provide a URL and have the associated file scanned.
Just like if you Scan an URL via VirusTotal.com and then klick on:

Go to downloaded file analysis

This feature would be very usefull for having a FileScan from an exe from some Webpage before actually downloading it.
If there is alreaedy a way to do this please let me know!

Thanks for suggesting this feature, however, I don't think it is an API feature. This project is just a simple implementation of the API with some extra help for convenience sake.
Had VT implemented a function to scan the file at an URL in their API, I would implement it to keep it updated, but this seems to be outside of the API realm.

Thank you for your time ynway :)  Just for completion I'll post a comment if I find a comfortable way to scan a file from URL.

I contacted the VT-Support, actually there is a Way to do it.. but It's only avaiable in the paid API...
Quote from "karl Hiramoto":

HI Joel,
I was mistaken, this piece of data is only available on our paid private API when you use the "allinfo=1" parameter
https://www.virustotal.com/en/documentation/private-api/#url-report
You would see in the response a "filescan_permaid"
https://www.virustotal.com/vtapi/v2/url/report?apikey=YOUR_PRIVATE_API_KEY&resource=http://upload.siamza.com/download.php?id=2296595&allinfo=1
"additional_info": {
"BitDefender domain info": "This URL domain/host was seen to host badware at some point in time",
"Response content SHA-256": "b0490431cda3df5588dad6e8d269ed9d79baa49aef4a5548b881cff96c7af519",
"resolution": "<IP_ADDRESS>",
"URL after redirects": "http://upload.siamza.com/download.php?id=2296595",
"resolution_country": "TH",
"Websense ThreatSeeker category": "malicious web sites",
"filescan_permaid": "b0490431cda3df5588dad6e8d269ed9d79baa49aef4a5548b881cff96c7af519-1444108498",
"Response code": 200,
"Response headers": {
"content-length": "382592",
"content-disposition": "attachment; filename=TalesRunner Thailand Free.rar",
"x-powered-by": "PHP/5.5.25",
"server": "Apache",
"connection": "close",
"cache-control": "private",
"date": "Tue, 06 Oct 2015 05:14:54 GMT",
"content-type": "application/octet-stream"
},
You can then use the file/report API call to fetch the file scan report


Add Whole Tale integration description

This PR adds information about the Whole Tale integration test and results to the "Under Development" section.

👏


Push constants don't seem to work

[mvk-debug] Performance to convert SPIR-V to MSL source code curr: 2.495 ms, avg: 2.495 ms, min: 2.495 ms, max: 2.495 ms, count: 1
[mvk-info] Converting SPIR-V:
; SPIR-V
; Version: 1.0
; Generator: Khronos Glslang Reference Front End; 7
; Bound: 43
; Schema: 0
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint Vertex %4 "main" %10 %15 %25 %42
               OpSource GLSL 450
               OpSourceExtension "GL_ARB_separate_shader_objects"
               OpName %4 "main"
               OpName %8 "gl_PerVertex"
               OpMemberName %8 0 "gl_Position"
               OpName %10 ""
               OpName %15 "pos"
               OpName %25 "color_varying"
               OpName %27 "TransformPC"
               OpMemberName %27 0 "mvp"
               OpName %29 "transformPC"
               OpName %39 "Transform"
               OpMemberName %39 0 "mvp"
               OpName %41 "transform"
               OpName %42 "color"
               OpMemberDecorate %8 0 BuiltIn Position
               OpDecorate %8 Block
               OpDecorate %15 Location 0
               OpDecorate %25 Location 0
               OpMemberDecorate %27 0 ColMajor
               OpMemberDecorate %27 0 Offset 0
               OpMemberDecorate %27 0 MatrixStride 16
               OpDecorate %27 Block
               OpMemberDecorate %39 0 ColMajor
               OpMemberDecorate %39 0 Offset 0
               OpMemberDecorate %39 0 MatrixStride 16
               OpDecorate %39 Block
               OpDecorate %41 DescriptorSet 0
               OpDecorate %41 Binding 0
               OpDecorate %42 Location 1
          %2 = OpTypeVoid
          %3 = OpTypeFunction %2
          %6 = OpTypeFloat 32
          %7 = OpTypeVector %6 4
          %8 = OpTypeStruct %7
          %9 = OpTypePointer Output %8
         %10 = OpVariable %9 Output
         %11 = OpTypeInt 32 1
         %12 = OpConstant %11 0
         %13 = OpTypeVector %6 2
         %14 = OpTypePointer Input %13
         %15 = OpVariable %14 Input
         %17 = OpConstant %6 0
         %18 = OpConstant %6 1
         %22 = OpTypePointer Output %7
         %24 = OpTypePointer Output %13
         %25 = OpVariable %24 Output
         %26 = OpTypeMatrix %7 4
         %27 = OpTypeStruct %26
         %28 = OpTypePointer PushConstant %27
         %29 = OpVariable %28 PushConstant
         %30 = OpTypePointer PushConstant %26
         %39 = OpTypeStruct %26
         %40 = OpTypePointer Uniform %39
         %41 = OpVariable %40 Uniform
         %42 = OpVariable %14 Input
          %4 = OpFunction %2 None %3
          %5 = OpLabel
         %16 = OpLoad %13 %15
         %19 = OpCompositeExtract %6 %16 0
         %20 = OpCompositeExtract %6 %16 1
         %21 = OpCompositeConstruct %7 %19 %20 %17 %18
         %23 = OpAccessChain %22 %10 %12
               OpStore %23 %21
         %31 = OpAccessChain %30 %29 %12
         %32 = OpLoad %26 %31
         %33 = OpLoad %13 %15
         %34 = OpCompositeExtract %6 %33 0
         %35 = OpCompositeExtract %6 %33 1
         %36 = OpCompositeConstruct %7 %34 %35 %17 %18
         %37 = OpMatrixTimesVector %7 %32 %36
         %38 = OpVectorShuffle %13 %37 %37 0 1
               OpStore %25 %38
               OpReturn
               OpFunctionEnd

End SPIR-V

Converted MSL:
#include <metal_stdlib>
#include <simd/simd.h>

using namespace metal;

struct TransformPC <----------------this used to be layout(push_constant)
{
    float4x4 mvp;
};

struct Transform
{
    float4x4 mvp;
};

struct main0_out
{
    float2 color_varying [[user(locn0)]];
    float4 gl_Position [[position]];
};

struct main0_in
{
    float2 pos [[attribute(0)]];
};

vertex main0_out main0(main0_in in [[stage_in]], constant TransformPC& transformPC [[buffer(1)]])
{
    main0_out out = {};
    out.gl_Position = float4(in.pos, 0.0, 1.0);
    out.color_varying = (transformPC.mvp * float4(in.pos, 0.0, 1.0)).xy;
    out.gl_Position.y = -(out.gl_Position.y);    // Invert Y-axis for Metal
    return out;
}

End MSL

Estimated original GLSL:
#version 450

layout(binding = 0, std140) uniform Transform
{
    mat4 mvp;
} transform;

struct TransformPC
{
    mat4 mvp;
};

uniform TransformPC transformPC; <--------------estimated back to being a normal uniform

layout(location = 0) in vec2 pos;
layout(location = 0) out vec2 color_varying;
layout(location = 1) in vec2 color;

void main()
{
    gl_Position = vec4(pos, 0.0, 1.0);
    color_varying = (transformPC.mvp * vec4(pos, 0.0, 1.0)).xy;
}

End GLSL

[mvk-debug] Performance to compile MSL source code into a MTLLibrary curr: 0.392 ms, avg: 1.339 ms, min: 0.392 ms, max: 2.287 ms, count: 2
[mvk-debug] Performance to retrieve shader library from the cache curr: 23.146 ms, avg: 23.146 ms, min: 23.146 ms, max: 23.146 ms, count: 1
[mvk-debug] Performance to retrieve a MTLFunction from a MTLLibrary curr: 0.007 ms, avg: 0.007 ms, min: 0.007 ms, max: 0.007 ms, count: 1
[mvk-debug] Performance to convert SPIR-V to MSL source code curr: 0.765 ms, avg: 1.630 ms, min: 0.765 ms, max: 2.495 ms, count: 2
[mvk-info] Converting SPIR-V:
; SPIR-V
; Version: 1.0
; Generator: Khronos Glslang Reference Front End; 7
; Bound: 24
; Schema: 0
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint Fragment %4 "main" %9 %12
               OpExecutionMode %4 OriginUpperLeft
               OpSource GLSL 450
               OpSourceExtension "GL_ARB_separate_shader_objects"
               OpName %4 "main"
               OpName %9 "fragcolor"
               OpName %12 "color_varying"
               OpDecorate %9 Location 0
               OpDecorate %12 Location 0
          %2 = OpTypeVoid
          %3 = OpTypeFunction %2
          %6 = OpTypeFloat 32
          %7 = OpTypeVector %6 4
          %8 = OpTypePointer Output %7
          %9 = OpVariable %8 Output
         %10 = OpTypeVector %6 2
         %11 = OpTypePointer Input %10
         %12 = OpVariable %11 Input
         %13 = OpTypeInt 32 0
         %14 = OpConstant %13 0
         %15 = OpTypePointer Input %6
         %18 = OpConstant %6 0.200000003
         %19 = OpConstant %13 1
         %22 = OpConstant %6 1
          %4 = OpFunction %2 None %3
          %5 = OpLabel
         %16 = OpAccessChain %15 %12 %14
         %17 = OpLoad %6 %16
         %20 = OpAccessChain %15 %12 %19
         %21 = OpLoad %6 %20
         %23 = OpCompositeConstruct %7 %17 %18 %21 %22
               OpStore %9 %23
               OpReturn
               OpFunctionEnd

End SPIR-V

Converted MSL:
#include <metal_stdlib>
#include <simd/simd.h>

using namespace metal;

struct main0_out
{
    float4 fragcolor [[color(0)]];
};

struct main0_in
{
    float2 color_varying [[user(locn0)]];
};

fragment main0_out main0(main0_in in [[stage_in]])
{
    main0_out out = {};
    out.fragcolor = float4(in.color_varying.x, 0.2, in.color_varying.y, 1.0);
    return out;
}

End MSL

Estimated original GLSL:
#version 450

layout(location = 0) out vec4 fragcolor;
layout(location = 0) in vec2 color_varying;

void main()
{
    fragcolor = vec4(color_varying.x, 0.2, color_varying.y, 1.0);
}

End GLSL

[mvk-debug] Performance to compile MSL source code into a MTLLibrary curr: 0.560 ms, avg: 1.080 ms, min: 0.392 ms, max: 2.287 ms, count: 3
[mvk-debug] Performance to retrieve shader library from the cache curr: 28.208 ms, avg: 25.677 ms, min: 23.146 ms, max: 28.208 ms, count: 2
[mvk-debug] Performance to retrieve a MTLFunction from a MTLLibrary curr: 0.002 ms, avg: 0.005 ms, min: 0.002 ms, max: 0.007 ms, count: 2
[mvk-debug] Performance to compile MTLFunctions into a pipeline curr: 1.009 ms, avg: 1.009 ms, min: 1.009 ms, max: 1.009 ms, count: 1
initialize: created graphics pipeline
initialize: created command buffers
initialize: uploaded vertex data

@741g
Can you clarify what you mean when you say "Push constants don't seem to work"?
The MSL shader conversion does not seem to be showing anything obviously incorrect. The transformPC variable is being passed as buffer index 1 in MSL and is accessed by the shader...and based on your log...the shader seems to be compiling.
What specifically is not working in your app?

A rotation matrix is applied to transformPC every frame, but I don't see the colors rotating. vkCmdPushConstants is used to send the matrix over.

Hmmm...push constants are fairly common...and this is the first I've heard of them not working.
You can try push constants out via the Sascha Willems samples. You can find a version that is compatible and tested against MoltenVK here. The Demos/README.md document in the MoltenVK repo explains how to install these samples.
If you continue to have trouble after investigating further...and are able to ZIP up a small Xcode project that demonstrates the issue...upload it to somewhere like Dropbox and post a link back here so we can evaluate it.

Ok, I'll try to corral it into a minimal example. However, what seems to be happening is that the colors are not animating at all (plus not being interpolated: see https://github.com/KhronosGroup/MoltenVK/issues/328)

(and it freezes with those colors, which makes me think push constants are not working)
Intended look (and this is what it looks like on libportability and on Linux/Windows NVIDIA Vulkan drivers):

sequence of calls:
https://android-review.googlesource.com/c/platform/external/qemu/+/803202/16/android/android-emugl/host/libs/libOpenglRender/samples/HelloVulkan.cpp

Thanks for clarifying what you are looking for...and that it works correctly on other Vulkan implementations.
Unfortunately the call sequence is clearly tied to a specific implementation class structure. And there seems to be a mix of GL and VK framework artifacts. It doesn't look like the calls can simply be copied out and pasted into another demo app.
How are you building this? Is there an Xcode project...or a set of CPP files...you can send that we can incorporate into a demo here?

Thanks for clarifying what you are looking for...and that it works correctly on other Vulkan implementations.
Unfortunately the call sequence is clearly tied to a specific implementation class structure. And there seems to be a mix of GL and VK framework artifacts. It doesn't look like the calls can simply be copied out and pasted into another demo app.
How are you building this? Is there an Xcode project...or a set of CPP files...you can send that we can incorporate into a demo here?

Since the fragment shader is shading floats in the range 0.0-1.0...the effect you are seeing is almost as if the rendering is being done to a texture with only 1 bit per color component (each color component is either completely on or off).
Very strange.
If you are able to post the the full sample project so we can explore what's going on...that would be helpful.

I don't currently have a repro I can share, but I also have an issue with push constants in MoltenVK.
Here's a sketch what appears to be happening:
vkBindPipeline(pipe1)
vkBindDescriptorSet(pipe1, a uniform buffer in set 0, binding 0)
vkPushConstants(constants1)
vkDraw(draw1)
vkPushConstants(constants2)
vkDraw(draw2)
vkBindPipeline(pipe2)
vkPushConstants(constants3)
vkDraw(draw3)

It appears that draw3 sees constants2 instead of constants3, which badly breaks rendering.

Found it. The issue is that if you don't do a vkCmdBindDescriptorSets after binding a new pipeline, push constants are broken. Doing an empty
        device.cmd_bind_descriptor_sets(
                command_buffer,
                vk::PipelineBindPoint::GRAPHICS,
                self.pipeline_layout,
                0,
                &[],
                &[],
            );

fixes things right up.
Unfortunately the validation layers complain about this, so a fix in MoltenVK would be much better.

https://github.com/KhronosGroup/MoltenVK/blob/a5cefa5c98a6c1a80bb52a55a189dcbb7b1cfdb0/MoltenVK/MoltenVK/GPUObjects/MVKPipeline.mm#L56
It seems that push constant destination is only updated after binddescriptorset, so if you are switching to a pipeline that is not using any descriptor sets, these don't get updated and vkCmdPushConstants has no effect.

@billhollings The original poster here talks about an apparent shader generation issue, which is probably not the same push constant problem I found - should I break out my reports into a separate issue? There is a real bug in MoltenVK here that should be looked at.

@hrydgard Yes, please. We can then put a separate bug label on it to keep a focus on it.
And please make the title a bit more specific while you're at it. To make it easier...just consolidate your 3 comments into a single one.

Done, #657.

@hrydgard Thanks.
Closing this issue since the original issue is not sufficiently defined yet.


Add support for optional match fields

Codecov Report

Merging #72 (10fd645) into main (b82d009) will decrease coverage by 0.24%.
The diff coverage is n/a.

:exclamation: Current head 10fd645 differs from pull request most recent head 46a071e. Consider uploading reports for the commit 46a071e to get more accurate results

@@            Coverage Diff             @@
##             main      #72      +/-   ##
==========================================
- Coverage   72.93%   72.68%   -0.25%
==========================================
  Files           8        8
  Lines        2121     2131      +10
==========================================
+ Hits         1547     1549       +2
- Misses        574      582       +8

Impacted Files
Coverage Δ

p4runtime-sh/p4runtime_sh/shell.py
71.97% <0.00%> (-0.33%)
:arrow_down:

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 b82d009...46a071e. Read the comment docs.

I was going to add at least a very simple test for the optional match. Is the unittest.p4info.pb.txt being generated? or should I manually add a new table with the optional match?

@daniele-moro you may just want to update the P4Info file by hand. I believe that originally it was generated from https://github.com/p4lang/PI/blob/main/tests/testdata/unittest.p4, but it's possible that the 2 have diverged since. I know that unittest.p4info.pb.txt was updated by hand in a recent PR.
Alternatively, if you want, you can check-in unittest.p4 and make the necessary modifications to produce the "right" P4Info.

@antoninbas Thanks for the clarification. In the end, I copied the OptionalOne table from the unittest.p4info.txt in the PI repo and used that for tests.


Update Web Browsers Section with drawbacks/benefits of Chrome, Firefox and Safari

This is PR has significant changes over the original text.
Instead of proposing Chrome as the best option in terms of security, now the security and privacy benefits and drawbacks about Chrome, Firefox and Safari are presented. This way people can make an informed decision about their browser of choice.
Each browser has a separate section with references from official sources. I toned down some of the language and tried to remain impartial. Moreover, I added a paragraph about the increased attack surface that web extensions introduce and how each browser uses them.
Generic Privacy suggestions where moved to their own subsection (Web Browsers and Privacy)
Since the changes are quite significant, take your time to review them. If something is not clarified enough or needs additional references, I would be more than to happy to add them. I took quite a time proof reading this, but if I missed anything, please do not hesitate to correct me.
I understand that web browsers are a sensitive topic. Since we are talking about their security features, personal feelings should not interfere. The fact that someone loves a specific browser does not make it more secure. I would be more than happy to discuss such topics on a separate channel, but for the current PR, suggestions should be focussed in security and privacy and backed by data.

Thanks @ansell for your helpful comments.
I have addressed all of them in the present commit 😄
Please, let me know, if you have other suggestions.

@drduh I addressed most of your comments.
I left the first one, which confused me and the last two that can be removed or clarified.

Just a few more comments to address above and this is ready to merge.

@drduh I addressed the rest of the comments 😄
Have a final look and we are ready for merge 🎉

Thank you, @Or3stis for raising the issue and submitting an excellent fix.


Simplify code

Just some house keeping. Reduce the function scope.

Warnings

:warning:
It looks like this PR contains functional changes without a corresponding test.

  Generated by :no_entry_sign: dangerJS against 28121ed61388b0680b7774d80c044f418cb13bf5


Disable CGO

In some environments like Debian 11, using prebuilt binaries can result in errors. They seem to be unintentionally linked to glibc.
$ wget https://github.com/sudorandom/protoc-gen-connect-openapi/releases/download/v0.13.0/protoc-gen-connect-openapi_0.13.0_linux_amd64.tar.gz
$ tar zxvf protoc-gen-connect-openapi_0.13.0_linux_amd64.tar.gz
$ ./protoc-gen-connect-openapi
./protoc-gen-connect-openapi: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./protoc-gen-connect-openapi)
./protoc-gen-connect-openapi: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./protoc-gen-connect-openapi)

Isn't the environment variable CGO_ENABLED=0 necessary during the build process?

Thanks for bringing this up! I was using the default goreleaser settings and it seems like it relies on glibc as it doesn't set CGO_ENABLED=0 by default. I pushed up a new tag, v0.13.1, that includes a fix for this. Thanks for raising the issue!


Registrar/Resolver Redesign

I've never really been happy with the current type registrar/resolver model in Spectre.Console. Registration/resolution concerns are scattered across objects in the library with no clear line drawn between setup code and code with dependencies on services. This has been a complaint of mine going pretty far back.
The command interceptor logic introduced recently made the mutual exclusivity of the registrar/resolver design a little less painful, but I still often find myself in catch 22 scenarios simply because Spectre.Console steals away control over my own DI container from me.
I'd like to end this once and for all by completely rethinking the way Spectre.Console approaches DI. Instead of implementing its own nested facades, adopt a more modern approach. Something along the lines of this:
var services = new ServiceCollection();

services.AddSpectreConsole(config =>
{
    config.AddSetting("demo");
});

var provider = services.BuildServiceProvider();

var app = provider.GetRequiredService<ICommandApp>();
return app.Run(args);

There's certainly different approaches here. There's a fluent builder pattern that might be more appropriate here as well, although I will say that when I tried it, it didn't give me that separation between registration & resolution like this approach does.
I'll provide a more comprehensive implementation of this below. Instead of diving into the Spectre.Console code base and going crazy with refactoring, I wanted to start with a small demo to mimick some of the top level objects in the library and show the approach without much concern for implementation detail right off the bat.
This also gives us a chance to discuss the idea and see if the maintainers are interested in an overhaul in this area. I understand backward compatibility will be a big concern here. I honestly don't see a way to keep things backward compatible and still be able to overhaul the aspects of this that desperately need it, IMO.
Let me know how you folks feel about this. I'm happy to help drive the work, I just want to make sure it's not a PR bound to be rejected.
Thanks in advance.
NOTE: In the demo, I'm using the nuget package Microsoft.Extensions.DependencyInjection, but Spectre.Console will actually only use the abstractions (i.e. Microsoft.Extensions.DependencyInjection.Abstractions). I think going forward, the main spectre.console package should only be concerned with the IServiceProvider/IServiceCollection abstractions which allow users to adapt these just as they do today with the registrar/resolver facades. In the future we can add packages like Spectre.Console.DependencyInjection, where we might provide additional facilities like the AddSpectreConsole() method.
I'm open to opinion here but I'm just assuming you'd want to separate DI-specific implementations into their own packages because you might want to support other containers like Autofac separately without impacting the main library.
using System;
using System.Collections.Generic;
using Microsoft.Extensions.DependencyInjection;

namespace ConsoleApp1;

public interface IConfigurator
{
    void AddSetting(string value);
}

public class Configurator : IConfigurator
{
    private readonly List<string> _settings = [];

    public void AddSetting(string value)
    {
        _settings.Add(value);
    }
}

public interface ICommandApp
{
    int Run(IEnumerable<string> args);
}

internal class CommandApp : ICommandApp
{
    public readonly CommandExecutor _executor;
    private readonly IConfigurator _config;

    public CommandApp(IServiceProvider provider, IConfigurator config)
    {
        // CommandExecutor should probably be injected via constructor arg...
        _executor = provider.GetRequiredService<CommandExecutor>();
        _config = config;
    }

    public int Run(IEnumerable<string> args)
    {
        return _executor.Execute(_config, args);
    }
}

internal class CommandExecutor
{
    public int Execute(IConfigurator config, IEnumerable<string> args)
    {
        // do meaningful work
        return 0;
    }
}

public static class SpectreConsoleExtensions
{
    public static void AddSpectreConsole(
        this IServiceCollection services,
        Action<IConfigurator> configure)
    {
        services.AddTransient<ICommandApp, CommandApp>();
        services.AddTransient<CommandExecutor>();
        services.AddTransient<IConfigurator>(_ =>
        {
            var config = new Configurator();
            configure(config);

            // This is where the built-in (hidden) commands get added
            config.AddSetting("default stuff");

            return config;
        });
    }
}

public static class Program
{
    public static int Main(string[] args)
    {
        var services = new ServiceCollection();

        services.AddSpectreConsole(config =>
        {
            config.AddSetting("demo");
        });

        var provider = services.BuildServiceProvider();

        var app = provider.GetRequiredService<ICommandApp>();
        return app.Run(args);
    }
}

@rcdailey I'm not against the idea per se, as long as there is no breaking change in the API. We're about to ship 1.0 of Spectre.Console and Spectre.Console.Cli, and we can't really introduce breaking changes to the API at this point.

@patriksvensson In addition to my previous reply, I have another question:
        // Register the arguments with the container.
        _registrar.RegisterInstance(typeof(CommandTreeParserResult), parsedResult);
        _registrar.RegisterInstance(typeof(IRemainingArguments), parsedResult.Remaining);

How important are these registrations in CommandExecutor.Execute()? I'm not really seeing anywhere they might be injected.

@rcdailey this will force all users to use the "Microsoft DI" and restrict everyone else who likes to use some other DI container, right?

@rcdailey this will force all users to use the "Microsoft DI" and restrict everyone else who likes to use some other DI container, right?

No, that is something I'm deliberately trying to avoid, but I'd like to share my plan below for feedback and also to make sure things really will go as I hope.

Main `Spectre.Console Package
Instead of using our own abstractions for DI concerns, such as ITypeRegistrar and ITypeResolver, consume dependencies directly in constructors. For example, in one instance, the CommandApp constructor would take a CommandExecutor (or abstraction of it) and then using the fluent builder pattern, remove construction concerns from the user (i.e. factory).

New Spectre.Console.DependencyInjection Package
This package would introduce extension methods for IServiceCollection (e.g. IServiceCollection.AddSpectreConsole()) that support transparently registering internal dependencies into the MS DI container, without users having to be aware of the ins & outs of how the registrations work and what types are needed.

The benefits I'm aiming for:

Clearer separation of concerns (DI-related code won't be sprinkled across the Spectre.Console code base)
More flexibility for users. Users have more control over what code is executed between the registration & configure steps of Spectre.Console and actual execution (e.g. RunAsync()) of the CLI application. The command interceptors are supposed to fill this gap today but they add a layer of complexity and are still not entirely flexible enough.
Users no longer have to implement their own DI container adapters. The responsibility of DI container support is shifted to specific extension packages. I don't suspect these to really ever change, so I think the maintainers taking on this responsibility is a good balance for achieving higher usability.

I think achieving these goals would be much easier if we were willing to accept breaking changes. It might be possible to avoid it, but it will result in a significant amount of problem solving and effort that I do not personally believe to be worth it. My principle is always to avoid backward breaking changes, so this isn't an opinion I take lightly. However, if you all feel strongly about backward compatibility, I will do my best to find an iterative approach that allows for it.
I would likely take a two step approach:

First PR would likely be an effort to refactor the existing implementation to shift existing registrations into the CommandApp.Configure() method, and greatly simplify the amount of setup work that is happening in the CommandExecutor class.
Second PR would lay the foundation for passing parameters directly into constructors to make them DI-friendly, and also probably introduce the fluent builder system at this time.
Third PR would probably be the MS DI-specific package. The reason I start with MS DI is because many other DI frameworks (e.g. Autofac) already have adapters for MS DI so I think starting here gets us the best bang for our buck, so to speak, in terms of DI compatibility across the board.

I hope my explanation is helpful. If my plan sounds too ambitious or just impossible let me know. Happy to adjust, after all, I need you all to be on board with this for PR approvals and I really don't want to waste effort if I can avoid it.

I noticed IPairDeconstructor is internal but CommandParameter supports a custom deconstructor via the PairDeconstructor property. However, because it's internal, no clients of the library can effectively implement their own deconstructor due to this logic (taken from CommandValueBinder):
        // Create deconstructor.
        var deconstructorType = parameter.PairDeconstructor?.Type ?? typeof(DefaultPairDeconstructor);
        if (!(resolver.Resolve(deconstructorType) is IPairDeconstructor deconstructor))
        {
            if (!(Activator.CreateInstance(deconstructorType) is IPairDeconstructor activatedDeconstructor))
            {
                throw new InvalidOperationException($"Could not create pair deconstructor.");
            }

            deconstructor = activatedDeconstructor;
        }

This leads me to believe that there are no active users for CommandParameter.PairDeconstructor since that type is required to implement IPairDeconstructor but they do not have access to it.
What is the intent here? Should the configurability of a "pair deconstructor" be removed from the public interface, or should the interface simply be made public?

I've read none of the above @rcdailey, but when my plate is more clear (that shouldn't be too long away), I'm happy to work alongside you with this, if it's still of interest.

Thanks Frank. I'll try to renew interest later, but the slow turnaround makes any motivation or progress difficult. I understand everyone is spending their free time here, so I'm not upset and certainly not pointing fingers. But it is a reality, and unfortunately I barely have enough free time as it is working on my own projects.
I absolutely do want to maintain a helpful relationship so if you ever get some downtime let me know. I mentioned connecting on Discord earlier, if that's an option anyone is comfortable with, that would likely make communication much easier.

I would propose considering making this work tied closely with any AOT work (e.g. #1322, #1155, #955). Both are going to have some overlap on  breaking changes and architecture rework, so both being in the same discussion would probably save some headaches in both directions

@rcdailey  There is a lull in maintainer activity/free time at the moment, except for myself, which is what you are seeing from the outside. Nothing untoward, just the reality of situation. I'm currently clearing down a few PR's and preparing the command line system for version 1 of Spectre.Console. But once that's out of the way, say early Dec, I can stick around and support any development you do, so you know it will be merged. That said, if it's too ambitious or breaking, then I'll become slowed down having to square it off with the other maintainers. But other things I can merge, and/or we could look at other issues if you feel like contributing there instead. Or simply acknowledging this is the situation currently, and waiting a bit. I think you're good in terms of 'maintain a helpful relationship', so don't let that cloud the decision how we proceed here.

Thanks again Frank. You've always been a pleasure to chat with on here so definitely will take advantage of your free time in December.
I think this is a challenging effort, especially if it means not breaking backward compatibility. I've mulled over a few different approaches but it involves a LOT of hacks and shims just to avoid breaking things. And the way the resolver is exposed to users in various structures and callbacks makes it even more challenging.
My inclination is to just break everything to get it the way we want, instead of tip toeing around compatibility. I understand that implies everything you mentioned, but maybe Phil's idea of bundling it with Native AOT work might make it more palatable (although I have no idea what that effort is yet, or if it's a good idea to build a bigger kitchen sink).

I also noticed an issue with the current implementation that should be addressed if a new one is made.
Currently there is two main steps, the creation of the app (new CommandApp()) where the TypeRegistrar is passed and the app  run (app.RunAsync).
From a DI perspective I expect that all dependencies registrations are made in the application building phase and not in the run phase, It is not currently the case.
I use myself SimpleInjector container which lock itself after the first dependency resolution.
So if I want to do something like :

Build container
Build app
Resolve some dependencies
Run app
I can't, because the app try to register some dependencies in the run phase and can't because the container is locked.

I want to understand the situation with Spectre.Console AOT trimming, hence my comment on 1508 here.

From a DI perspective I expect that all dependencies registrations are made in the application building phase and not in the run phase, It is not currently the case.

nb. It's the following line that resolves the registrations, obviously deep in the command execution method:
https://github.com/spectreconsole/spectre.console/blob/aa9e5c48c6b212e75ee9bd25b890359267997579/src/Spectre.Console.Cli/Internal/CommandExecutor.cs#L60
If this was moved somewhere else @kvpt, how should it work?
For example.
new CommandApp(DI container)

(opportunity to continue modifying registrations here)

CommandApp.ResolveDependencies()

(container is locked, internally registered types locked also)

CommandApp.Run()

Is this what you had in mind?

I think there is no need for a new method here, it only need to adhere on this two principes :

All the registrations need to be made in the build phase
new CommandApp(DI container)

All the resolutions need to be done in the run phase
CommandApp.Run()

Currently rule 2 seems ok, but rule 1 is not.
https://github.com/spectreconsole/spectre.console/blob/aa9e5c48c6b212e75ee9bd25b890359267997579/src/Spectre.Console.Cli/Internal/CommandExecutor.cs#L13-L28
For exemple the executor register IConfiguration, IAnsiConsole and CommandModel.
Is it not possible to build and register them in build phase instead of doing it at the execution ?

Yes, I see what you mean @kvpt.
I'm keen to look into whether a non-breaking refactor could separate out these different build/run concerns.
I'll update the thread once I've investigated further.

It's nearly December @rcdailey, my diary is emptying a little - how are you feeling about this issue?

I'm going to take a look at this tonight and see if we can remove the TypeRegistrar/TypeResolver and instead take a dependency on the Microsoft.Extensions.DependencyInjection package.

I'm going to take a look at this tonight and see if we can remove the TypeRegistrar/TypeResolver and instead take a dependency on the Microsoft.Extensions.DependencyInjection package.

@patriksvensson It would be worth keeping in mind @kvpt's comment above, when looking into this, see: https://github.com/spectreconsole/spectre.console/issues/1657#issuecomment-2486250826

I'm going to take a look at this tonight and see if we can remove the TypeRegistrar/TypeResolver and instead take a dependency on the Microsoft.Extensions.DependencyInjection package.

Awesome news. I would see if you can instead get away with a dependency on just Microsoft.Extensions.DependencyInjection.Abstractions for the main package, this would allow users to adapt to their own DI system if they want. Then you can provide an extension package for actual concrete support for specific DI frameworks like Microsoft's.

No, we still used a built-in DI container even if the user doesn't provide one, so would need to have an actual implementation as well.

I guess what I'm saying is that there's a strategy you could adopt where the Spectre.Console library itself uses constructor injection normally with no DI framework dependencies. Imagine using pure DI in this case. There would be nothing special about this, you're just using dependency inversion and factories.
Then via extension libraries, you can extend your configuration builder pattern to facilitate initialization of the library (i.e. provide its dependencies) using specific DI libraries, such as MS.DI, Autofac, etc. Users can also implement their own.
I'm not saying you should do this; it's just an approach. If you want to hard-code to support Microsoft.DI, then I completely understand. Other popular libraries like MassTransit do this, and it seems to work fine (except when you need to support older .NET frameworks).
Thanks again for acknowledging the issue and expressing support for it. If I can help at all please let me know.

I have solved a very similar issue in https://github.com/JKamsker/Spectre.Console.Extensions.Hosting-ng


Fix double locking/unlocking issue

Hi,
When opening a second modal without closing the first one Remodal keeps on adding padding to the body.
Here's a quick PR that checks the html is locked/unlocked before locking/unlocking it for the second time.
Tests are included.
P.S. I had to move $body and paddingRight  declaration outside of the if because jscs wants a single var declaration per method and I really didn't want to initialize $body and paddingRight before the conditional for the performance reasons.

Travis CI build failure is fixed in another PR — https://github.com/VodkaBears/Remodal/pull/78

Hmm… I wonder what is the reason for failing tests. They are all green on my machine:

:cry:

parseInt

Ok, so it was very naive of me to rely on headless WebKit's scrollbar to be exactly 15px.

Thanks)


Add phoenix

Looks good, but can you move it to the right place in terms of alphabetical sorting?

Thanks for the quick review @strickvl. Changed the name to the full name (we are pip install arize-phoenix).

Thanks for the contribution and fixes, @axiomofjoy!


Hydrating a machine from localStorage doesn't work without an existing key

Description

The guides show how to hydrate state from (e.g.) localStorage, however this will crash xstate if the key doesn't exist: https://github.com/davidkpiano/xstate/blob/master/docs/guides/states.md
Expected Result

The State to resolve to the machine's initial state
Actual Result

xstate crashes and throws this error:
// Code
const stateDefinition = JSON.parse(localStorage.getItem('auth-state'))
const previousState = State.create(stateDefinition)
const resolvedState = authMachine.resolveState(previousState)

// Thrown Error
State.js?2eb3:75 Uncaught TypeError: Cannot read property 'value' of null
    at new State (State.js?2eb3:75)

Reproduction
https://codesandbox.io/s/confident-waterfall-7linq?file=/src/index.js
Additional context
I think the docs should either be updated, or, ideally, the State should fall back to the machine's defaultstate (probably by passing it in?)

One way around this, is to use the initial state of the machine as a fallback:
// Code
const stateDefinition = JSON.parse(localStorage.getItem('auth-state')) || authMachine.initialState
const previousState = State.create(stateDefinition)
const resolvedState = authMachine.resolveState(previousState)

Feel free to open a PR updating the docs for this 🙏


printing html?

May I know is there a way to print it as html content? Thanks and appreciate your response.

Hello! Thank you for you question. I have just updated plugin to support HTML text.
Example:
cordova.plugins.starIOPrint.printHTMLText('Hello World!',
function(success) {
alert(success);
}
, function(error) {
alert(error);
}
);
To print simple text now you should use 👍
cordova.plugins.starIOPrint.printText
I haven't so much time to test new functionality perfectly, so please respond me when you try.

Hi,
Thanks and appreciate for your effort and making this happen. Amazing and very useful plugin. Love it.
I have tried out and it can print HTML text now. Cool. I really appreciate and like it.
Between, this plugin support cash drawer? If yes, how ? Any references? Thanks.
Once again, thanks and appreciate your effort and help.

Yes, it can support cashdrawer. Please open new issue with specific topic and I will help you as soon as  possible.


miniflare: kill workerd process with tree-kill

What this PR solves / how to test
Author has addressed the following

Tests

[x] TODO (before merge)
[ ] Included
[ ] Not necessary because:

E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)

[ ] I don't know
[ ] Required / Maybe required
[ ] Not required because:

Changeset (Changeset guidelines)

[ ] TODO (before merge)
[ ] Included
[ ] Not necessary because:

Public documentation

[ ] TODO (before merge)
[ ] Cloudflare docs PR(s):
[ ] Not necessary because:

This fix seems to work when running wrangler via npx (public registry and prerelease urls) but not when we run via pnpm workspaces (in fixtures and our test suite). Therefore I'm having trouble writing a regression test.
Since this fix works for real (npx) usage, I'm inclined to merge this without a test for the benefit of users. We can work on  regression tests and finding root causes async but land this fix early.

I tried fkill instead of tree-kill and it's almost like it kills the process too quickly and many of the miniflare tests fail

Closing in favour of https://github.com/cloudflare/workers-sdk/pull/7169


Playlist titles disappear on hover

https://user-images.githubusercontent.com/22990262/177403488-bb2eb318-41e6-4210-a26d-8d66368cac0f.mp4
Title/video pretty explain it all

I cannot recreate the issue on my end. What version of Spotify/Spicetify are you running?

Spotify for macOS (Apple Silicon)
<IP_ADDRESS>2.gcc529952
spicetify --version                                                  ✔ 
2.10.2

I'm on <IP_ADDRESS>6.gc5f8b819 on Arch. Once I get the next update I'll test again. They probably made some changes to the CSS classes again.

Still facing this issue, any fixes?

The theme has been updated to the 0.2.0 spec, adding the new flavours, but sadly this issue still persists on macOS.
I personally don't use Spotify, so we'll have to wait until someone bothers to fix it on macOS, or Spotify updates its Linux client.

I had the same issue in windows 11, I fixed it by adding the following CSS code to spicetify\Themes\catppuccin-mocha\user.css:
.main-rootlist-rootlistItemLink:link, .main-rootlist-rootlistItemLink:visited {
    z-index: 1;
}

And then i reapplied the theme spicetify config current_theme catppuccin-mocha, spicetify update.

Including this with #23, since @ghostx31 tried it on Linux, and I just did on macOS. Changes nothing on Linux, fixes the issue on macOS.
Thanks for the CSS snippet @Rekit0.


Commit to drop 5.4 introduced a bug in travis that makes build fail with an error

This commit: drop PHP 5.4 should have also changed matrix php setting to 5.5. This caused errors when building on travis:
This package requires php ~5.5|~7.0 but your PHP version (5.4.37) does not satisfy that requirement.

Resolved in #68.
Thanks for this! If you have a solution feel free to save yourself a little time by just sending the PR and not doing the issue to. I usually use the issue first then PR later approach only when I'm not sure if I'll actually get a fix in in a reasonable time. :)


FEAT-#1936: avoid empty frame checks for lazy backend

What do these changes do?
Avoid checks for empty frames when lazy backend is used. This might affect semantics for lazy engines in corner cases, but we are OK with that.

 How is that processed there?


Create a CONTRIBUTING.md file for generators

Coverage remained the same at 97.492% when pulling 0515de64e8cc92f13b3362fd20e64cbc415c6e2e on generator-contributing.md into a50d2851bf788ec11473b49e9c8b46a1eff4bd82 on major.


[Tracking] AMD GPUs and NixOS - 'Cannot find target for triple amdgcn-- Unable to find target for this triple (no targets are registered)'.

Issue description
I've been experiencing a bug with my AMD iGPU (780M), but it appears this is a bug affecting more than a few NixOS users.
For me, it affects 1Password, and dwl. I'm also having issues with Steam crashing when the web component loads. I am curious if this is related, but I am certain 1Password and dwl are affected by the amdgcn triple error.
This issue, therefore, will act as a tracking issue.
Below is a list of issues I've found with the characteristic signature error:
#343580
#340196
#339520
There has been talk of a possible Mesa bug causing this.

My guess this is a problem with a mismatch of the Mesa version between the one used by the system and for building the package rather than a bug in Mesa itself. This seems to fit the pattern so far as all of the issues you linked mention using an unstable package. I experience the same bug with launch unstable youtube-music, an Electron app, but the stable package is fine.
Currently mesa is at 24.0.7 on stable and at 24.2.2 on unstable. There was a minor update for mesa on unstable from 24.1 to 24.2 last month (see https://github.com/NixOS/nixpkgs/commits/nixos-unstable/pkgs/development/libraries/mesa/common.nix), so this might be what launched the recently increased amount of problem reports.
To confirm the mismatch is the problem it'd be interesting if someone tried running the affected package unmodified, but on an unstable NixOS.
My guess stems from the fact that when I had problems with Vivaldi (which is based on Chromium) not starting in the past that I was able to fix by overriding the mesa input:
(pkgs.unstable.vivaldi.override { mesa = pkgs.mesa; })

If this is the problem, I guess it isn't actually be a bug or something nixpkgs could fix. Although noting somewhere that using unstable chromium/electron on a stable NixOS is problematic and providing an easy override for the mesa input would be helpful.

OK, so I did try and override wlroots and pass that modified derivation to dwl. I'm still working it out, but it seems by overriding the Mesa input of wlroots, it then can't find things like libdrm or cmake.
We should likely document this behaviour with Mesa, though.

I stumbled upon this issue when searching for the error message. For what it's worth, this is also happening on Debian Sid/unstable at the moment, with Mesa 24.2.3. Downgrading to Mesa 24.2.2 fixes the issue there.

Yeah, it may well be an upstream issue then. Do you have a link to a Debian Sid bug report?
We might need to work together across distros/packagers to fix this. Perhaps there's a breaking change with Mesa.

I don't see a report yet for Debian, though I may just be looking in the wrong place since Mesa has lots of packages. I'll see if I can make one once I find the package that's causing the issue

My guess this is a problem with a mismatch of the Mesa version between the one used by the system and for building the package rather than a bug in Mesa itself. This seems to fit the pattern so far as all of the issues you linked mention using an unstable package. I experience the same bug with launch unstable youtube-music, an Electron app, but the stable package is fine.
Currently mesa is at 24.0.7 on stable and at 24.2.2 on unstable. There was a minor update for mesa on unstable from 24.1 to 24.2 last month (see https://github.com/NixOS/nixpkgs/commits/nixos-unstable/pkgs/development/libraries/mesa/common.nix), so this might be what launched the recently increased amount of problem reports.
To confirm the mismatch is the problem it'd be interesting if someone tried running the affected package unmodified, but on an unstable NixOS.
My guess stems from the fact that when I had problems with Vivaldi (which is based on Chromium) not starting in the past that I was able to fix by overriding the mesa input:
(pkgs.unstable.vivaldi.override { mesa = pkgs.mesa; })

If this is the problem, I guess it isn't actually be a bug or something nixpkgs could fix. Although noting somewhere that using unstable chromium/electron on a stable NixOS is problematic and providing an easy override for the mesa input would be helpful.

Hey @Eisfunke - just wanted to get your thoughts on my fix for dwl here. I was going to document it on my wiki once I get it working.

I don't see a report yet for Debian, though I may just be looking in the wrong place since Mesa has lots of packages. I'll see if I can make one once I find the package that's causing the issue

No rush, if you're able to get anywhere, let us know! Thanks.

I updated my Debian machine to Mesa 24.2.3 again, and rather annoyingly everything just works now.  There was no Mesa nor LLVM version change in Debian, so I can't really blame any package for causing this. I wonder if it's something cache related? There were issues before with Chromium/Electron applications having broken rendering after a Mesa update, and wiping the application's shader cache resolved those.

Yeah, that could be why. However, I can't see a dwl cache in $XDG_CACHE_HOME.

I don't know where dwl puts its cache, so I can't help with that sadly. But for Electron apps, they put their shader cache in ~/.config/<app_name>/GPUCache, because... Electron. That's just how they do things.

I could not reproduce this with dwl, but mpv and prusa-slicer also have this issue.

I got this error while trying to package an app with electron_31, while my system is on 24.05

I could not reproduce this with dwl, but mpv and prusa-slicer also have this issue.

Are you using dwl v0.7? That's the issue I'm having. My repo is currently private, whilst I try and prepare for a work laptop.

I've just made the repo public again.
@AgentElement I meant to tag you in my previous message - the repo is here.
Thanks.

+1, unable to use mpv with 780M amdgpu on nixos-stable @ fbca5e745367ae7632731639de5c21f29c8744ed.

I run into the same error trying to run the cinny-desktop package from unstable on a system on the 24.05 branch.

I think, ultimately, the issue comes down to mixing packages from unstable (with a newer version of Mesa), with stable.
One solution would be to override the unstable package's mesa input with stable's mesa package, as previously described in this thread.

Same for unstable.brave to make it searchable, syncing the mesa versions worked!

The fix suggested in https://github.com/signalapp/Signal-Desktop/issues/6855 worked for me on Framework16, which has an integrated AMD Phoenix1 GPU.
export LIBVA_DRIVER_NAME="vdpau"

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/cannot-run-chrome-nor-chromium/54373/5

I don't think this is related to libva. The issue was [originanly] due to mixing unstable Mesa and stable Mesa.
If people are experiencing the same issue, even when overriding the mesa input, please update the issue. For libva, I believe that is a separate issue.

Yeah setting export LIBVA_DRIVER_NAME="vdpau" doesn't fix it for me using MPV unstable.

As mentioned in the thread on discourse I'm experiencing the same error on the stable channel that I always used.
Is there the possibility that some stable packages where contaminated by some unstable dependencies? Actually this hypothesis it the only one that I have that would explain the issue

Hi!
I use NixOS with a mix from stable + unstable pkgs.
I have this video card from AMD:
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef)
My main 'desktop' works ok and is based on swayfx (0.4) but I'm also experimenting this problem when trying to launch sway-1.10 or hyprland from unstable.
Is there a fix for this or if we update to 24.11 when it is available will experiment  the same problem, I mean if I want to use sway-1.10 by then 'stable'?

I'm experiencing this bug now as well, the LIBVA_DRIVER_NAME didn't work for me either.
05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] (rev c5)

I'm using this workaround:
    (
      let
        wrapped = pkgs.writeShellScriptBin "prusa-slicer" ''
          export LIBGL_ALWAYS_SOFTWARE=1
          exec ${pkgs.prusa-slicer}/bin/prusa-slicer "$@"
        '';
      in
      pkgs.symlinkJoin {
        name = "prusa-slicer";
        paths = [
          wrapped
          pkgs.prusa-slicer
        ];
      }
    )

This has been fixed for me, as far as I can tell, when I updated to 24.11

Same for me :)

Also for me

I think the lesson to be learned here is that mixing unstable packages that - in this case, rely on Mesa - with stable systems, cause this particular manifestation.
As 24.11 has resolved this issue, for me included, are people alright if I go ahead and close this issue as resolved?

I think the lesson to be learned here is that mixing unstable packages that - in this case, rely on Mesa - with stable systems, cause this particular manifestation.
As 24.11 has resolved this issue, for me included, are people alright if I go ahead and close this issue as resolved?

Yes, just updated to 24.11 and it works now.
Thanks for your work in Nixos.

Will close now. I'll open an issue to see if we should document this behaviour.


404'ing Media causes build to fail

Previously I would just get a warning of 404s for media but now when the first post with inserted media which 404s I get an error and the build fails.
Received a 404 when trying to fetch

https://api.thesite.co.uk/wp-content/uploads/2013/11/lounge-diner-300x300.jpeg
from Post #4111 "Post with Image 404"

Most likely this image was uploaded to this Post and then deleted from the media library.
You'll need to fix this and re-save this Post to remove this warning at
https://api.thesite.co.uk/wp-admin/post.php?post=4111&action=edit.

 ERROR

Cannot read property 'id' of null

  TypeError: Cannot read property 'id' of null

  - process-node.js:196 fetchNodeHtmlImageMediaItemNodes
    [gatsby-theme-starter]/[gatsby-source-wordpress-experimental]/steps/source-nodes/create-nodes/process-node.js:196:23

  - next_tick.js:68 process._tickCallback
    internal/process/next_tick.js:68:7

The build completes if I set:
 html: {
   useGatsbyImage: false,
},

Plugin version 1.0.7
WP Gatsby 0.4.9
WpGraphQL 0.10.3

I get a 404 error too but I don't get any indication on the place of the image, and the html: { useGatsbyImage: false} don't solve the issue, I would be happy if at least I can tell where the image is used!
info  gatsby-source-wordpress  Unrecoverable error
 occured while fetching media item #23787

Media item link: https://********.com/
?attachment_id=23787

 ERROR

failed to process https://********.com/wp-content/uploads/2020/04/COVID-19-Event-Cancellations-1.png
HTTPError: Response code 404 (Not Found)

Hi @ashhitch , this is actually by design to prevent deploying a broken site. We were considering this a feature because an admin can delete an image from the media library without knowing where that image lives. All pages or posts that had that image in html will then be broken. The link where the image is used is added to the error so that the site can be fixed https://github.com/gatsbyjs/gatsby-source-wordpress-experimental/issues/20
@Nazeh your issue is a bit different actually. In your case you have a media item that exists in WordPress but the image file for it has been deleted on disk. I will look at improving that error message but you should be able to go to the media item with a db id of 23787 to see which media item is missing files.

Oh @Nazeh actually the error message includes the link to the media item too Media item link: https://********.com/?attachment_id=23787. I will add a note about what this means to the error

@TylerBarnes i do think it would be handy to have an option especially in dev to allow them through like before with just a warning.
Along with just being able to ignore old posts with missing media.
A use-case I have is I'm dev'ing a site with a lot of media but I don't want to copy all the media down to staging.

@ashhitch , that's a really good use-case. I'll put this on my list and have another crack at it.

@TylerBarnes Thank you! Keep up the awesome work.

@TylerBarnes  - another vote for not having a 404 halt the build, especially when doing a development build. I'm currently exploring using Gatsby for a news site and I can't actually finish a develop build because of a late 404. I want the warning, but I'd like to be able to actually have the build finish. As it is, I have to fix every 404 before I can even start seeing how this will work and since it halts on the first 404 I can't tell if I have just one to fix or 100.

@rickgregory
as a temp workaround, you could add a redirect rule for all 404'ing images on your wordpress site...
it's not ideal but will get you out of a bind:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteRule \.(gif|jpe?g|png|bmp|webp) /placeholder.png [NC,L]
</IfModule>

404's no longer fail the build in development as of<EMAIL_ADDRESS>I've also added an additional line to the error in production when the build fails to explain why this is the case.
Thanks for opening this issue and for your patience!


Manage dependencies clash with gql, request-toolbelt and urllib3

Example user issue: https://speckle.community/t/unable-to-install-speckle-qgis-on-m1-mac/5810/6
Cause:
The latest releases of the two libraries (request-toolbelt and urllib3) are incompatible, as reported here https://stackoverflow.com/a/76177575
gql library that specklepy is using is relying on requests and requests-toolbelt.
Although universal python installer ensures specific version of every module (e.g. urllib3<=1.26.16), some software (e.g. QGIS) imports request library from the original Python setup (probably imported before Speckle connector is loaded) with possibly incompatible version.
To do:
Look into the use of gql module relying on request-toolbelt, which is then relying on urllib3.

More details:

gql library fixed the issue by restricting to urllib3<2.0
request-toolbelt released 1.0.0 to support urllib 2.x

Closing this ticket as we are moving to Jira to reduce noise. You can access it there.


autoClose can't be used when using Abstract*Spec.() -> Unit

When writing test by providing closure in the spec constructor doesn't allow for using autoClose function:
class Test : DescribeSpec({
  describe("") {
      // autoClose() not available
  }
})

Is it inteded? If yes, what's the preferred workaround for this?

We need a DSL version. I'll add this to 4.0.
On Thu, 12 Sep 2019, 04:20 Łukasz Wasylkowski<EMAIL_ADDRESS>wrote:

When writing test by providing closure in the spec constructor doesn't
allow for using autoClose function:
class Test : DescribeSpec({
describe("") {
// autoClose() not available
}
})
Is it inteded? If yes, what's the preferred workaround for this?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kotlintest/kotlintest/issues/987?email_source=notifications&email_token=AAFVSGRB7F3HTLHNI6JPX4LQJICWNA5CNFSM4IWBK6ZKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HK5ZSNQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFVSGWYF3APTI3ZXWTFQIDQJICWNANCNFSM4IWBK6ZA
.

Current master (4.0) now allows this:
class AutoCloseDslTest : FunSpec({
   val closeme = AutoCloseable {
   }
   autoClose(closeme)
   test("auto close with dsl method") {
   }
})


[MPoW] On-chain crypto lib

Cause the runtime_interface can not purely forkless upgraded, so we need think another way to keep the root CA from IAS
-----------------------------2020-07-07 Update-----------------------------
We should remove runtime_interface cause the restriction of parachain of polkadot

Change p256 to secp256k1;
On-chain CA X509;

This can be remove from p0 issue, cause it can be forkless upgraded.

Move it to P0 since it cannot be forkless upgraded.
There are two major works.

Move report works into on-chain

[x] encode/to_string/hex::encode
[ ] p256 to ecdsa(secp256k1)

Move register identity into on-chain

[ ] base64?
[ ] x509. To use Phala's lib


Map base and bonus scores to F,A,I,R

It's difficult to understand the breakdown of the base and bonus scores to each of F,A,I, R. might suggest some kind of interactive chart that i) shows where the resource is passing/failing, and ii) is clickable to the specific assessment section.

Bonus scores have been removed

forget about the bonus scores then, just an interactive chart.


core: Rename parameter signature in BaseOutputParser.parse_with_prompt method

Description
I've renamed the parameter signature of OutputParsers, which use llm for fixing on completions, to follow a consistent format (text: str, prompt_value: PromptValue)
It's anticipated that the BaseOutputParser.parse_with_prompt method will have minimal side-effects, as it's only overridden by RetryOutputParser and RetryWithErrorOutputParser in output_parsers/retry.py.

AS-IS:

# libs/core/langchain_core/output_parsers/base.py

    # TODO: rename 'completion' -> 'text'.
    def parse_with_prompt(self, completion: str, prompt: PromptValue) -> Any:

TO-BE:

# libs/core/langchain_core/output_parsers/base.py

    def parse_with_prompt(self, text: str, prompt_value: PromptValue) -> Any:

# libs/langchain/langchain/output_parsers/fix.py

    def parse(self, text: str) -> T:
        completion = text
        retries = 0

        while retries <= self.max_retries:
        # ...

# libs/langchain/langchain/output_parsers/retry.py

    def parse_with_prompt(self, text: str, prompt_value: PromptValue) -> T:
        completion = text
        retries = 0

        while retries <= self.max_retries:
        # ...

Hi @KangmoonSeo thank you for the contribution. I am not sure that we'll want to roll out these changes.

The methods signatures could cause breaking changes since we're not using the / operator in our code. So users may be invoking those parameters by name.
The output parser exceptions are used by some caller code to do retrys with LLMs.

Hello! Thank you, @eyurtsev, for your feedback.
I appreciate your concern regarding the potential breaking changes due to the modification of your method signature.
Should we consider removing the TODO: comment requesting the change in the BaseOutputParser.parse_with_prompt signature?
Additionally, the adjustments made to the OutputParserException now specifically address cases where the user inputs a max_retries value less than zero. The purpose of this change is to explicitly indicate which text parsing failed.
Thank you for reviewing the code!


Allow for pinning scenarios/datasets in model-check report

Currently in the model-check UI, scenario and dataset items are always sorted according to the number of differences reported for each item (items with the most differences bubble up to the top of the list).  This is OK in the summary view, but in the detail view, this behavior can make it difficult to review changes for a particular scenario or dataset because the view always scrolls to the top when navigating between items.
One solution to this would be to introduce a "pinning" feature in the model-check report.  If you pin an item, it goes to a section at the top of the summary/detail page with a fixed ordering, so when you navigate between pages, the same items appear in a consistent location.
Nice-to-haves:

Allow the user to reorder the pinned items via drag and drop
Save the set of pinned items in LocalStorage so that they persist between builds

Re: the nice-to-haves above, I did implement drag and drop in the summary view, but decided not to include the pinned items in the summary view after all; we can consider restoring that code later.  I didn't do the LocalStorage thing for now because I will have to figure out a better way to have stable scenario identifiers between runs, so I will work on that in a later issue.
With these changes in place, in the detail view, there is now a context menu for each comparison graph box that the user can access by right-clicking on the box title or the row title:

Selecting the "Pin [Item]" option will make that item go to the top of the detail view for all pages in that category:

I didn't want to get too bogged down with implementing reordering the pinned items via drag and drop, so for now, when there are multiple pinned items, you can select "Move [Item] to Top" to have some basic reordering support:

You can also pin an entire row of scenarios at once in the "Comparisons by output" detail view:

As part of this I improved the section header style in the detail views to include a horizontal line to help visually separate the sections.


DisposeAsync: Missing base/inherited example

Under the title Implement the async dispose pattern, there's a bullet point that says:

The DisposeAsyncCore() method is virtual and is overridden in the ExampleAsyncDisposable class.

ExampleAsyncDisposable doesn't implement a base class, so ExampleAsyncDisposable::DisposeAsyncCore() isn't overriding anything 🙂
I think maybe in this example, there was supposed to be a base class and an inherited class, with both implementing DisposeAsyncCore()?

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

ID: 61a961dc-3ebf-2a96-a6eb-2e0b62ab909f
Version Independent ID: d72276e1-9059-815f-dc14-a03a7544ab87
Content: Implement a DisposeAsync method
Content Source: docs/standard/garbage-collection/implementing-disposeasync.md
Product: dotnet-fundamentals
GitHub Login: @IEvangelist
Microsoft Alias: dapine

Associated WorkItem - 90208

Thanks! 🎉


Add conda recipe

This will automatically run development tests on install, and tests are available as datashader.test() as well.

I've amended the PR.

Alright, I've pulled out the try block (no other changes).

Thanks!


feat: FLB supports multiple modes of getting upstreams

Description:

Testing done:

Affected area:

Functional Area

New Functionality
[ ]

CI System
[ ]

CLI Tool
[ ]

Certificate Management
[ ]

Control Plane
[ ]

Demo
[ ]

Documentation
[ ]

Egress
[ ]

Ingress
[ ]

Install
[ ]

Networking
[ ]

Observability
[ ]

Performance
[ ]

SMI Policy
[ ]

Security
[ ]

Sidecar Injection
[ ]

Tests
[ ]

Upgrade
[ ]

Other
[ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project?

Did you notify the maintainers and provide attribution?

Is this a breaking change?

Has documentation corresponding to this change been updated in the fsm-docs repo (if applicable)?

Codecov Report
Attention: 36 lines in your changes are missing coverage. Please review.

Comparison is base (5510084) 47.71% compared to head (6e5a22e) 47.59%.

Files
Patch %
Lines

pkg/utils/ip.go
0.00%
17 Missing :warning:

pkg/configurator/mock_client_generated.go
0.00%
8 Missing :warning:

pkg/utils/pod.go
0.00%
8 Missing :warning:

pkg/configurator/methods.go
0.00%
3 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@               Coverage Diff                @@
##           release/v1.2     #153      +/-   ##
================================================
- Coverage         47.71%   47.59%   -0.12%
================================================
  Files               194      196       +2
  Lines             14883    14919      +36
================================================
  Hits               7101     7101
- Misses             7738     7774      +36
  Partials             44       44

Flag
Coverage Δ

unittests
47.59% <0.00%> (-0.12%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.