Rendering errors with root causes in the widget layer should have a reference to the widget

Users may never directly interact with the rendering layer, make 'usage errors' entirely in the widgets layer, but end up confronted with a crash and a stacktrace entirely in RenderObjects as the tree is traversed while chain calling RenderObject.layout, RenderObject.paint or Element.mount which users may be entirely unfamiliar with.
If the user's lucky, there are asserts in the Widgets' constructors and the stacktrace is useful. But if the users are unlucky and the issue snuck past Widget constructors, even the Widget's build() stacktrace could be obscure with RenderSliverList layout etc and untraceable.
We should leverage --track-widget-creation and somehow let the crash reference users' code rather than classes deep in the framework that users never interacted with.
cc @InMatrix @jacob314
Related https://github.com/flutter/flutter/issues/29075, https://github.com/flutter/flutter/issues/19226, https://github.com/flutter/flutter/issues/7703

Thanks for the report. This is case I expect the structured error refactor to address. In the Devtools app and IntelliJ we can provide direct links to the closest spot in the inspector for the error and navigate users to the closest spot in user code to where the error occurred.

This example can be used to reproduce this issue: https://github.com/InMatrix/flutter_error_studies/blob/master/lib/renderflex_overflow_error.dart
The error doesn't currently show related widgets in the user's code.

I went through #27327 but didn't notice the stacktrace specific part of it. Was this render object stack trace -> non-inline widget construction in user code mapping mechanism already part of your planned structured error work or did you mean that that work give a foundation to add functionalities like these?

Why is this customer: critical? I understand that it'd be hugely desireable, but it doesn't seem like something that would ever block a release?

With regards to https://github.com/flutter/flutter/issues/27327, the stack traces are one of the object types that IDEs will be able to see as structured data instead of as a blob of text. The IDEs as well as the DevTools web app also know what directories should be considered part of the local project so can use that information to highlight relevant content.
Please do keep this issue open as well as 27327. I agree this is an important use case not directly called out by that issue.

To answer my question above, this is marked critical because it is a major pain point with some of our developers who would, if this was fixed, grow their usage of Flutter.

@goderbauer threw some ideas around.
Here's some more repros:
import 'package:flutter/widgets.dart';

void main() => runApp(
  CustomScrollView(slivers: <Widget>[
      SliverToBoxAdapter(child: Container()),
  ]),
);

flutter: ══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
flutter: The following assertion was thrown building
flutter: RawGestureDetector-[LabeledGlobalKey<RawGestureDetectorState>#e9962](state:
flutter: RawGestureDetectorState#30b13(gestures: <none>, behavior: opaque)):
flutter: 'package:flutter/src/painting/basic_types.dart': Failed assertion: line 222 pos 10: 'textDirection
flutter: != null': is not true.
flutter:
flutter: Either the assertion indicates an error in the framework itself, or we should provide substantially
flutter: more information in this error message to help you determine and fix the underlying cause.
flutter: In either case, please report this assertion by filing a bug on GitHub:
flutter:   https://github.com/flutter/flutter/issues/new?template=BUG.md
flutter:
flutter: When the exception was thrown, this was the stack:
flutter: #2      textDirectionToAxisDirection
package:flutter/…/painting/basic_types.dart:222
flutter: #3      Viewport.getDefaultCrossAxisDirection
package:flutter/…/widgets/viewport.dart:128
flutter: #4      Viewport.createRenderObject
package:flutter/…/widgets/viewport.dart:139
flutter: #5      RenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4497
flutter: #6      MultiChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4977
flutter: #7      _ViewportElement.mount
package:flutter/…/widgets/viewport.dart:186
flutter: #8      Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #9      Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #10     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #11     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #12     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #13     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #14     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #15     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #16     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #17     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #18     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #19     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #20     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #21     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #22     ComponentElement.performRebuild
package:flutter/…/widgets/framework.dart:3746
flutter: #23     Element.rebuild
package:flutter/…/widgets/framework.dart:3558
flutter: #24     ComponentElement._firstBuild
package:flutter/…/widgets/framework.dart:3715
flutter: #25     StatefulElement._firstBuild
package:flutter/…/widgets/framework.dart:3863
flutter: #26     ComponentElement.mount
package:flutter/…/widgets/framework.dart:3710
flutter: #27     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #28     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #29     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #30     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #31     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #32     ComponentElement.performRebuild
package:flutter/…/widgets/framework.dart:3746
flutter: #33     Element.rebuild
package:flutter/…/widgets/framework.dart:3558
flutter: #34     ComponentElement._firstBuild
package:flutter/…/widgets/framework.dart:3715
flutter: #35     ComponentElement.mount
package:flutter/…/widgets/framework.dart:3710
flutter: #36     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #37     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #38     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #39     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #40     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #41     ComponentElement.performRebuild
package:flutter/…/widgets/framework.dart:3746
flutter: #42     Element.rebuild
package:flutter/…/widgets/framework.dart:3558
flutter: #43     ComponentElement._firstBuild
package:flutter/…/widgets/framework.dart:3715
flutter: #44     StatefulElement._firstBuild
package:flutter/…/widgets/framework.dart:3863
flutter: #45     ComponentElement.mount
package:flutter/…/widgets/framework.dart:3710
flutter: #46     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #47     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #48     ComponentElement.performRebuild
package:flutter/…/widgets/framework.dart:3746
flutter: #49     Element.rebuild
package:flutter/…/widgets/framework.dart:3558
flutter: #50     ComponentElement._firstBuild
package:flutter/…/widgets/framework.dart:3715
flutter: #51     ComponentElement.mount
package:flutter/…/widgets/framework.dart:3710
flutter: #52     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #53     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #54     RenderObjectToWidgetElement._rebuild
package:flutter/…/widgets/binding.dart:933
flutter: #55     RenderObjectToWidgetElement.mount
package:flutter/…/widgets/binding.dart:904
flutter: #56     RenderObjectToWidgetAdapter.attachToRenderTree.<anonymous closure>
package:flutter/…/widgets/binding.dart:850
flutter: #57     BuildOwner.buildScope
package:flutter/…/widgets/framework.dart:2251
flutter: #58     RenderObjectToWidgetAdapter.attachToRenderTree
package:flutter/…/widgets/binding.dart:849
flutter: #59     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding&WidgetsBinding.attachRootWidget
package:flutter/…/widgets/binding.dart:736
flutter: #60     runApp
package:flutter/…/widgets/binding.dart:780
flutter: #61     main
package:t122_widget_render_error_stack/main.dart:19

Neither the error message nor the stack points to anything in 'my' code.
Another example:
void main() => runApp(
  MaterialApp(
    home: Row(children: [
      Material(child: TextField()),
    ]),
  ),
);

flutter: ══╡ EXCEPTION CAUGHT BY RENDERING LIBRARY ╞═════════════════════════════════════════════════════════
flutter: The following assertion was thrown during performLayout():
flutter: BoxConstraints forces an infinite width.
flutter: These invalid constraints were provided to RenderRepaintBoundary's layout() function by the
flutter: following function, which probably computed the invalid constraints in question:
flutter:   _RenderDecoration._layoutLineBox (package:flutter/src/material/input_decorator.dart:827:9)
flutter: The offending constraints were:
flutter:   BoxConstraints(w=Infinity, 0.0<=h<=643.0)
flutter:
flutter: When the exception was thrown, this was the stack:
flutter: #0      BoxConstraints.debugAssertIsValid.<anonymous closure>.throwError
package:flutter/…/rendering/box.dart:504
flutter: #1      BoxConstraints.debugAssertIsValid.<anonymous closure>
package:flutter/…/rendering/box.dart:545
flutter: #2      BoxConstraints.debugAssertIsValid
package:flutter/…/rendering/box.dart:551
flutter: #3      RenderObject.layout
package:flutter/…/rendering/object.dart:1559
flutter: #4      _RenderDecoration._layoutLineBox
package:flutter/…/material/input_decorator.dart:827
flutter: #5      _RenderDecoration._layout
package:flutter/…/material/input_decorator.dart:899
flutter: #6      _RenderDecoration.performLayout
package:flutter/…/material/input_decorator.dart:1071
flutter: #7      RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #8      _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #9      RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #10     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #11     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #12     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #13     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #14     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #15     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #16     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #17     _RenderCustomClip.performLayout
package:flutter/…/rendering/proxy_box.dart:1206
flutter: #18     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #19     RenderFlex.performLayout
package:flutter/…/rendering/flex.dart:738
flutter: #20     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #21     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #22     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #23     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #24     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #25     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #26     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #27     RenderStack.performLayout
package:flutter/…/rendering/stack.dart:510
flutter: #28     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #29     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #30     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #31     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #32     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #33     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #34     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #35     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #36     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #37     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #38     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #39     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #40     RenderOffstage.performLayout
package:flutter/…/rendering/proxy_box.dart:3002
flutter: #41     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #42     RenderStack.performLayout
package:flutter/…/rendering/stack.dart:510
flutter: #43     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #44     __RenderTheatre&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #45     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #46     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #47     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #48     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #49     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #50     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #51     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #52     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #53     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #54     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #55     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #56     RenderView.performLayout
package:flutter/…/rendering/view.dart:151
flutter: #57     RenderObject._layoutWithoutResize
package:flutter/…/rendering/object.dart:1519
flutter: #58     PipelineOwner.flushLayout
package:flutter/…/rendering/object.dart:766
flutter: #59     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding.drawFrame
package:flutter/…/rendering/binding.dart:336
flutter: #60     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding&WidgetsBinding.drawFrame
package:flutter/…/widgets/binding.dart:701
flutter: #61     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding._handlePersistentFrameCallback
package:flutter/…/rendering/binding.dart:275
flutter: #62     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding._invokeFrameCallback
package:flutter/…/scheduler/binding.dart:1008
flutter: #63     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding.handleDrawFrame
package:flutter/…/scheduler/binding.dart:948
flutter: #64     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding.scheduleWarmUpFrame.<anonymous closure>
package:flutter/…/scheduler/binding.dart:769
flutter: #73     _Timer._runTimers (dart:isolate/runtime/lib/timer_impl.dart:382:19)
flutter: #74     _Timer._handleMessage (dart:isolate/runtime/lib/timer_impl.dart:416:5)
flutter: #75     _RawReceivePortImpl._handleMessage (dart:isolate/runtime/lib/isolate_patch.dart:171:12)
flutter: (elided 8 frames from package dart:async)

Non trivial to figure out what in the widgets world is the error referring to.

@goderbauer threw some ideas around.
Here's some more repros:
import 'package:flutter/widgets.dart';

void main() => runApp(
  CustomScrollView(slivers: <Widget>[
      SliverToBoxAdapter(child: Container()),
  ]),
);

flutter: ══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
flutter: The following assertion was thrown building
flutter: RawGestureDetector-[LabeledGlobalKey<RawGestureDetectorState>#e9962](state:
flutter: RawGestureDetectorState#30b13(gestures: <none>, behavior: opaque)):
flutter: 'package:flutter/src/painting/basic_types.dart': Failed assertion: line 222 pos 10: 'textDirection
flutter: != null': is not true.
flutter:
flutter: Either the assertion indicates an error in the framework itself, or we should provide substantially
flutter: more information in this error message to help you determine and fix the underlying cause.
flutter: In either case, please report this assertion by filing a bug on GitHub:
flutter:   https://github.com/flutter/flutter/issues/new?template=BUG.md
flutter:
flutter: When the exception was thrown, this was the stack:
flutter: #2      textDirectionToAxisDirection
package:flutter/…/painting/basic_types.dart:222
flutter: #3      Viewport.getDefaultCrossAxisDirection
package:flutter/…/widgets/viewport.dart:128
flutter: #4      Viewport.createRenderObject
package:flutter/…/widgets/viewport.dart:139
flutter: #5      RenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4497
flutter: #6      MultiChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4977
flutter: #7      _ViewportElement.mount
package:flutter/…/widgets/viewport.dart:186
flutter: #8      Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #9      Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #10     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #11     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #12     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #13     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #14     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #15     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #16     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #17     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #18     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #19     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #20     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #21     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #22     ComponentElement.performRebuild
package:flutter/…/widgets/framework.dart:3746
flutter: #23     Element.rebuild
package:flutter/…/widgets/framework.dart:3558
flutter: #24     ComponentElement._firstBuild
package:flutter/…/widgets/framework.dart:3715
flutter: #25     StatefulElement._firstBuild
package:flutter/…/widgets/framework.dart:3863
flutter: #26     ComponentElement.mount
package:flutter/…/widgets/framework.dart:3710
flutter: #27     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #28     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #29     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #30     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #31     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #32     ComponentElement.performRebuild
package:flutter/…/widgets/framework.dart:3746
flutter: #33     Element.rebuild
package:flutter/…/widgets/framework.dart:3558
flutter: #34     ComponentElement._firstBuild
package:flutter/…/widgets/framework.dart:3715
flutter: #35     ComponentElement.mount
package:flutter/…/widgets/framework.dart:3710
flutter: #36     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #37     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #38     SingleChildRenderObjectElement.mount
package:flutter/…/widgets/framework.dart:4875
flutter: #39     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #40     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #41     ComponentElement.performRebuild
package:flutter/…/widgets/framework.dart:3746
flutter: #42     Element.rebuild
package:flutter/…/widgets/framework.dart:3558
flutter: #43     ComponentElement._firstBuild
package:flutter/…/widgets/framework.dart:3715
flutter: #44     StatefulElement._firstBuild
package:flutter/…/widgets/framework.dart:3863
flutter: #45     ComponentElement.mount
package:flutter/…/widgets/framework.dart:3710
flutter: #46     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #47     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #48     ComponentElement.performRebuild
package:flutter/…/widgets/framework.dart:3746
flutter: #49     Element.rebuild
package:flutter/…/widgets/framework.dart:3558
flutter: #50     ComponentElement._firstBuild
package:flutter/…/widgets/framework.dart:3715
flutter: #51     ComponentElement.mount
package:flutter/…/widgets/framework.dart:3710
flutter: #52     Element.inflateWidget
package:flutter/…/widgets/framework.dart:2954
flutter: #53     Element.updateChild
package:flutter/…/widgets/framework.dart:2757
flutter: #54     RenderObjectToWidgetElement._rebuild
package:flutter/…/widgets/binding.dart:933
flutter: #55     RenderObjectToWidgetElement.mount
package:flutter/…/widgets/binding.dart:904
flutter: #56     RenderObjectToWidgetAdapter.attachToRenderTree.<anonymous closure>
package:flutter/…/widgets/binding.dart:850
flutter: #57     BuildOwner.buildScope
package:flutter/…/widgets/framework.dart:2251
flutter: #58     RenderObjectToWidgetAdapter.attachToRenderTree
package:flutter/…/widgets/binding.dart:849
flutter: #59     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding&WidgetsBinding.attachRootWidget
package:flutter/…/widgets/binding.dart:736
flutter: #60     runApp
package:flutter/…/widgets/binding.dart:780
flutter: #61     main
package:t122_widget_render_error_stack/main.dart:19

Neither the error message nor the stack points to anything in 'my' code.
Another example:
void main() => runApp(
  MaterialApp(
    home: Row(children: [
      Material(child: TextField()),
    ]),
  ),
);

flutter: ══╡ EXCEPTION CAUGHT BY RENDERING LIBRARY ╞═════════════════════════════════════════════════════════
flutter: The following assertion was thrown during performLayout():
flutter: BoxConstraints forces an infinite width.
flutter: These invalid constraints were provided to RenderRepaintBoundary's layout() function by the
flutter: following function, which probably computed the invalid constraints in question:
flutter:   _RenderDecoration._layoutLineBox (package:flutter/src/material/input_decorator.dart:827:9)
flutter: The offending constraints were:
flutter:   BoxConstraints(w=Infinity, 0.0<=h<=643.0)
flutter:
flutter: When the exception was thrown, this was the stack:
flutter: #0      BoxConstraints.debugAssertIsValid.<anonymous closure>.throwError
package:flutter/…/rendering/box.dart:504
flutter: #1      BoxConstraints.debugAssertIsValid.<anonymous closure>
package:flutter/…/rendering/box.dart:545
flutter: #2      BoxConstraints.debugAssertIsValid
package:flutter/…/rendering/box.dart:551
flutter: #3      RenderObject.layout
package:flutter/…/rendering/object.dart:1559
flutter: #4      _RenderDecoration._layoutLineBox
package:flutter/…/material/input_decorator.dart:827
flutter: #5      _RenderDecoration._layout
package:flutter/…/material/input_decorator.dart:899
flutter: #6      _RenderDecoration.performLayout
package:flutter/…/material/input_decorator.dart:1071
flutter: #7      RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #8      _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #9      RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #10     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #11     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #12     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #13     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #14     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #15     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #16     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #17     _RenderCustomClip.performLayout
package:flutter/…/rendering/proxy_box.dart:1206
flutter: #18     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #19     RenderFlex.performLayout
package:flutter/…/rendering/flex.dart:738
flutter: #20     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #21     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #22     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #23     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #24     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #25     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #26     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #27     RenderStack.performLayout
package:flutter/…/rendering/stack.dart:510
flutter: #28     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #29     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #30     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #31     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #32     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #33     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #34     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #35     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #36     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #37     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #38     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #39     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #40     RenderOffstage.performLayout
package:flutter/…/rendering/proxy_box.dart:3002
flutter: #41     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #42     RenderStack.performLayout
package:flutter/…/rendering/stack.dart:510
flutter: #43     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #44     __RenderTheatre&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #45     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #46     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #47     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #48     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #49     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #50     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #51     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #52     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #53     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #54     _RenderProxyBox&RenderBox&RenderObjectWithChildMixin&RenderProxyBoxMixin.performLayout
package:flutter/…/rendering/proxy_box.dart:105
flutter: #55     RenderObject.layout
package:flutter/…/rendering/object.dart:1644
flutter: #56     RenderView.performLayout
package:flutter/…/rendering/view.dart:151
flutter: #57     RenderObject._layoutWithoutResize
package:flutter/…/rendering/object.dart:1519
flutter: #58     PipelineOwner.flushLayout
package:flutter/…/rendering/object.dart:766
flutter: #59     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding.drawFrame
package:flutter/…/rendering/binding.dart:336
flutter: #60     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding&WidgetsBinding.drawFrame
package:flutter/…/widgets/binding.dart:701
flutter: #61     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding&PaintingBinding&SemanticsBinding&RendererBinding._handlePersistentFrameCallback
package:flutter/…/rendering/binding.dart:275
flutter: #62     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding._invokeFrameCallback
package:flutter/…/scheduler/binding.dart:1008
flutter: #63     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding.handleDrawFrame
package:flutter/…/scheduler/binding.dart:948
flutter: #64     _WidgetsFlutterBinding&BindingBase&GestureBinding&ServicesBinding&SchedulerBinding.scheduleWarmUpFrame.<anonymous closure>
package:flutter/…/scheduler/binding.dart:769
flutter: #73     _Timer._runTimers (dart:isolate/runtime/lib/timer_impl.dart:382:19)
flutter: #74     _Timer._handleMessage (dart:isolate/runtime/lib/timer_impl.dart:416:5)
flutter: #75     _RawReceivePortImpl._handleMessage (dart:isolate/runtime/lib/isolate_patch.dart:171:12)
flutter: (elided 8 frames from package dart:async)

Non trivial to figure out what in the widgets world is the error referring to.

For those two examples it would be helpful if you could include the Widget in the users's code (if any) that should be indicated as the source of the problem. That way I can verify whether linking to the nearest user created ancestor widget of the problem RenderObject is useful or misleading.

@jacob314 I'm not sure if I understood what you're asking.
For instance, in example 1:
import 'package:flutter/widgets.dart';

void main() => runApp(
  CustomScrollView(slivers: <Widget>[
      SliverToBoxAdapter(child: Container()),
  ]),
);

Is the code in the user's project. In that case, the CustomScrollView widget should be highlighted since its composed widget ViewPort failed to create its RenderObject.
In this example, it's not that useful since there are only 3 widget constructions ever in the user code, but if the user's code space is 100kLOC, the error stack doesn't even point to the related file let alone the line.

@xster you understood it correctly. In each of the examples, which of the widgets in the user's code would you want to have highlighted. Like you said, my intent is to ignore the fact that all 3 widgets are only 1 line apart as in a real app the widgets might be far apart.

Ok, I think I understood the question.
I think the thing to highlight is the nearest ancestor Element whose Widget was created in user code. In example 1, it's the CustomScrollView. In example 2, I can't even tell 🤣. I think it's the TextField.

RenderObjects do have a debugCreator property, which  if it's set up will point to the widget tree that created the render object.  That seems like at least part of what you're asking for.

Exactly. That is how we determine the best Widget to associate with a RenderObject in inspector when jumping between trees. My hope is that displaying the first entry in the debugCreator list where the constructor call that occurred in the user's project provides the right context. We will need to verify that highlighting that source file location does not confuse users by taking them too far from the source of the problem. Essentially we want to display the parent chain like a stack with the first user created widget in bold and selected by default.

I strongly suspect we have places where we're not setting the debugCreator though - but that should be fixable.

Making sure we set debugCreator everywhere possible will really matter for this. Otherwise we could end up too far up the Widget tree with confusing results.
It would be good if we can add asserts to catch cases where it is not specified.
Do you have any examples of where it is not set? For example, naively it looks like RenderObjectElement does a good job of always setting it.

Ahh I assumed it wasn't getting set because of @xster stack traces - but he just cut off the bottom portion where it had this:
I/flutter ( 5269):   TextSelectionGestureDetector ← IgnorePointer ← Semantics ← TextField ← DefaultTextStyle ←
I/flutter ( 5269):   AnimatedDefaultTextStyle ← _InkFeatures-[GlobalKey#8279c ink renderer] ← ⋯
I/flutter ( 5269):   parentData: <none> (can use size)```

I definitely see some places in the Layer tree where we're not setting it though, that would help.

waiting for https://github.com/flutter/flutter/issues/27327

https://github.com/flutter/flutter/pull/30983 has two approvals and is waiting from approval from two more team members so hopefully it will be able to land soon.

@jacob314 what's the relationship of #30983 to this issue? I assume it's just a set of structured error reporting API to use for showing these types of errors?

#30983 has now landed.
I've added comments to
https://github.com/chunhtai/flutter/commit/3b0edafbc8cf3a15640a24283554a8553df52211
describing how that CL should be implemented to align with the refactor.
TLDR: basically every line of the CL would conflict with the refactor if the patch was implemented in a way aligned with how flutter layers the foundation, render, and widget layers.

Ah, I didn't know there was a prototype. Awesome! 🎉

PR is merged, This should catch most of rendering error cases, however, not all. The framework is in place, it should be relatively easy to fix if we have missed any.


msbuild could not find the latest .net core sdk

so I installed VS2017 which comes with a .net core sdk 2.1.105, and then I installed .net core sdk 2.2.202 and via VS I created a .net core web app on .net core app version 2.2.
Then the problem is building the project in VS and with msbuild on command line both give me error:
C:\Program Files\dotnet\sdk\2.1.505\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 2.2.  Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2
but if the .net CLI tool shows the 2.2.202 version is already installed, and build it using the CLI command "dotnet build <project>" works perfectly.
What did I miss to get msbuild and VS work?

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

ID: 1927440c-08b4-d442-d315-24b677603034
Version Independent ID: e334f0d3-627a-a3f6-cdfb-b3abfcccd1e7
Content: How to: Reference an MSBuild Project SDK - Visual Studio
Content Source: docs/msbuild/how-to-use-project-sdk.md
Product: visual-studio-windows
Technology: msbuild
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

I'm running into this as well. Installed .NET Core 2.2 SDK (dotnet --info output:
dotnet-info.txt ). Created a new .NET Core console project in VS 2017 15.9.9. It targets .NET Core project by default:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
  </PropertyGroup>

</Project>

When I try to build it, either in VS or using msbuild from the command line, I get the error above. dotnet build succeeds, however. In project properties VS does not show .NET Core 2.2 as an installed framework:
Log of msbuild /v:diag: build-diag.txt

@bryanchen-d  Thanks for your feedback; we appreciate it. To make sure that this is logged in the right place, please use the Report a Problem tool to report the issue. When you do this, your report becomes part of the work items that are listed in the in the Visual Studio Developer Community, which allows you to engage directly with the engineering team while they address and fix the problem.

I think I have figured out the problem, the dotnet core v2.2.202 has a breaking change that it requires msbuild v16. However msbuild with VS2017 is of version v15.*. so the workaround to this issue would be either

install lower version of dotnet core, e.g. v2.2.105
install VS2019

@bryanchen-d Thanks for following up with that! That seems to make sense.


[Feature Request] Update (open sensor) when status change

Hi, first of all, thank you for your great work! :)
I'd like to know if it's possible, once the alarm fail to arm because of one/some open sensor, if, when the status of the sensor change also  status of alarmo can change.

I'm asking that because of this case on a panel that i use to arm/disarm alarmo. https://github.com/joBr99/nspanel-lovelace-ui/issues/242.
Thank you.

The open_sensors property provides the reason why arming failed (or alarm was triggered).
The property will not update if the sensor status changes afterwards, since this has nothing to do with the reason of the failure.
For getting the current sensor state (rather than its state while triggering or arming) you can check the HA entity directly, there is no need to use an Alarmo property for this.


Upadte all require message

Isn't it more common to use the upper snake case invariant message than use a natural one. I'm all for the natural ones, but I thought the original format was becoming standard.

Pull Request Test Coverage Report for Build 2612

94 of 94 (100.0%)  changed or added relevant lines in 17 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 2593:
0.0%

Covered Lines:
580

Relevant Lines:
580

💛  - Coveralls


python310Packages.broadlink: 0.18.0 -> 0.18.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.broadlink is: "Python API for controlling Broadlink IR controllers"
meta.homepage for python310Packages.broadlink is: "https://github.com/mjg59/python-broadlink"
meta.changelog for python310Packages.broadlink is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 0.18.1 with grep in /nix/store/98zmjcdprwhn546gqb7qn18i27mfi2w2-python3.10-broadlink-0.18.1

found 0.18.1 in filename of file in /nix/store/98zmjcdprwhn546gqb7qn18i27mfi2w2-python3.10-broadlink-0.18.1

Rebuild report (if merged into master) (click to expand)

7 total rebuild path(s)

4 package rebuild(s)

4 x86_64-linux rebuild(s)
3 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
broadlink-cli
home-assistant-component-tests.broadlink
python310Packages.broadlink
python39Packages.broadlink

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/98zmjcdprwhn546gqb7qn18i27mfi2w2-python3.10-broadlink-0.18.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.broadlink https://github.com/r-ryantm/nixpkgs/archive/512404e0e40de9543dabea45499f4a3b0b065da0.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/98zmjcdprwhn546gqb7qn18i27mfi2w2-python3.10-broadlink-0.18.1
ls -la /nix/store/98zmjcdprwhn546gqb7qn18i27mfi2w2-python3.10-broadlink-0.18.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

broadlink-cli
home-assistant-component-tests.broadlink
python310Packages.broadlink
python39Packages.broadlink

Maintainer pings

Result of nixpkgs-review pr 164951 run on x86_64-linux 1

4 packages built:

broadlink-cli
home-assistant-component-tests.broadlink
python310Packages.broadlink
python39Packages.broadlink


Test is not building on iOS

On branch task/patrol-extension
I get errors about concurrency in swift files:
/Users/julia/patrol/packages/patrol/ios/Classes/AutomatorServer/Automator.swift:399:50: error: concurrency is only available in iOS 13.0.0 or newer             func getUITreeRoots(installedApps: [String]) async throws -> [NativeView] {

fixed in #1891


[Bug] A lot of characters in password field returns 413

If you put a alot of characters in the password for editing it return 413 :( 🥺🥺🥺🥺🥺🥺

Thanks. This is due to the request not validating the password input length.


fix/perf: [NPM] apply IPSets periodically and proper IPSet batching

The DP will now apply IPSets in the background, either periodically or after reaching the max batch count.
We already batch operations. Now we will batch our batches. Pod/Namespace controllers will be unaware of apply errors, yet they already do not handle these errors.
Lock DP to solve some race conditions leading to temporarily incorrect state.
Also, a controller doesn't need to apply changes if it makes none.

Superseded by #1875


Checking for IE11 Support

Hi,
I am a maintainer of a project which must have support for IE11 browser.
I'm wondering what is your browser support list since this project has been flagged as not ES5 safe.
Checking ES5 support for node_modules on my project with are-you-es5 shows:
> npx are-you-es5 check . -rv

...
✅ react-... is ES5
❌ react-querybuilder is not ES5
✅ react-... is ES5
...

If you try are-you-es5 on your project folder you would get the result:
> npx are-you-es5 check . -r -v

npx: installed 10 in 5.236s
✅ lodash is ES5
❌ nanoid is not ES5
✅ prop-types is ES5

Babel-loader exclude regex:
/[\\/]node_modules[\\/](?!(nanoid)[\\/])/
Non-ES5 dependencies detected.

So, to provide support you would have to transpile the offending nanoid package as mentioned on their README file in
https://github.com/ai/nanoid#ie

@vitorhsb I've opened PR #144 to resolve this issue.  Can you take a look and see if I've covered everything before I merge it?

Looks good.
Thanks for your super quick response.

@vitorhsb v3.5.0 should be fully compatible with IE11.  Please let me know if it's not.

@vitorhsb v3.5.0 should be fully compatible with IE11. Please let me know if it's not.

Yeah, it works. Thanks.

For anyone coming to this page via a search engine, we now have an IE11-compatible demo page.


There are some cases where OT (or Matter) loses track of matter services

We've observed cases where matter mDNS services disappear unexpectedly
To Reproduce Information to reproduce the behavior, including:

Git commit id e6df00dd66e (https://github.com/SiliconLabs/matter/releases/tag/v2.2.0-1.2)
IEEE 802.15.4 hardware platform MG24
Build steps
Network topology typically larger numbers of devices
Usually with 3 fabrics on each device (e.g. Apple Home which has 2 + Home Assistant)

We've been unable to capture this reproducibility high enough to observe it on a device with debug logs. We've indirectly observed logs from HPM sysdiagnose with the Home Network Diagnostics profile, which includes SRP calls.
Based on observation, we see some or all matter services disappearing ~2 hours after boot. Matter flow starts with advertising all operational nodes and a matterc record for a period of 3 minutes.
Independently we have our own record type (ltpdu) that needs to be advertised always. Because of current deficiencies in Matter SDK (https://github.com/project-chip/connectedhomeip/issues/32507), we have a timer that will check every 2s to see if our service is still there - we iterate over known OT services
const otSrpClientService *service_list = otSrpClientGetServices(chip::DeviceLayer::ThreadStackMgrImpl().OTInstance());

If we detect that our service is missing, we will add it immediately:
CHIP_ERROR error = chip::Dnssd::ChipDnssdPublishService(&SRPltpdu::service, nullptr, nullptr);

Our working theory is that race conditions can result in some or all of matter services not getting re-added when matterc is removed. Observationally, these services are not actively removed by the device, they simply expire later at the srp server (e.g. not refreshed).
Its unclear to us if this indicates a deficiency in OT code, a deficiency how we are using it, or otherwise a deficiency in Matter SDK.
We are already refactoring our approach to have our own service added to OT in the same function call that Matter uses to add its own to potentially address our hypothesis. But it would be good to get some understanding from the OT community whether this points to other hiding OT issues with srp behaviour.

If a service is not present in the list of services you get from OT otSrpClientGetServices, then no sw entity (matter or in general any next layer code) has not called the API to add the service.
Once a service is successfully added using otSrpClientAddService() it will be in the list until it is explicitly removed/cleared by API call from next layer.

ok, so issue points to chip stack likely, and this:
CHIP_ERROR DnssdServer::AdvertiseOperational()
{
    VerifyOrDie(mFabricTable != nullptr);

    for (const FabricInfo & fabricInfo : *mFabricTable)
    {
...
// Should we keep trying to advertise the other operational
        // identities on failure?
        ReturnErrorOnFailure(mdnsAdvertiser.Advertise(advertiseParameters));

I suspect there is still an issue in OT side either as a bug, or due to inappropriate use by matter.
Matter seems to remove all services and readd the ones it cares about. As this issue presents on the BR side logs from Apple, only the matterc service is actually removed by thread client, the remainder timeout due to lease. This suggests that perhaps if multiple services are removed all at once, OT only actively removes the last one from the SRP server.
We've otherwise avoided this behaviour by combining our own registration with matter's which seems to avoid the original failure to Advertise a service in the for loop.
filters:
any:727E27068C33DD2A.local → F75 node, which is affected
any:E62BF306B0F70C4F.local → AEA node, which is unaffected

to navigate between srp calls, search for srp_eval

both seem to restart ~17:28:43. AEA seems to register first (perhaps results in a few retries in F75?). Matterc records removed ~17:31.

For AEA, when matterc is removed, ltpdu is also removed in what seems to be same call. ltpdu is re-added. so 2 total srp evals.

In F75, ltpdu is removed first, then matterc. then ltpdu is readded. so 3 calls.

in AEA, services are refreshed at 19:26, which is just before 2 hours on the original 17:28 registration

in F75, next refresh happens at 19:29, after when the matter records have expired. only ltpdu is refreshed

I have sysdiagnose logs for any parties interested in the above analysis (file too large to upload)

OT only actively removes the last one from the SRP server?

A call to otSrpClientRemoveHostAndServices() will trigger SRP client to send an SRP update message to server asking "host" to be fully removed which should also remove any previously registered services associated with this host (on server).

Code snippet from CHIP:
for (typename SrpClient::Service & service : mSrpClient.mServices)
    {
        if (service.IsUsed() && service.mIsInvalid)
        {
            ChipLogProgress(DeviceLayer, "removing srp service: %s.%s", service.mService.mInstanceName, service.mService.mName);
            error = MapOpenThreadError(otSrpClientRemoveService(mOTInst, &service.mService));
            SuccessOrExit(error);
        }
    }

Anyway, the issue has been logged to CHIP, so this could probably be closed in the absence of stronger evidence/steps to reproduce.

Closing stale issue.


UpdateInputPreconditions has performance impact

Describe the bug
I noticed during development that UpdateInputPreconditions is requiring quite some CPU cycles because the UI is lagging while in Debug mode. This is not noticable during the release build but you can see that the CPU usage is significantly higher than without the call to this method.
Steps To Reproduce
Steps to reproduce the behavior:

Have at least 30 input configs with preconditions each
Have at least 30 output configs that are used in the preconditions.
Run MobiFlight
Take a look at the CPU usage in the Task Manager

Expected behavior
MobiFlight should not need more than 2%. Typically .7-1.5% on my computer.
Actual behavior
MobiFlight requires 4-5% CPU which is unsually high.
Details

MobiFlight Version: 9.5

Additional context
The strategy to check whether the preconditions for the input actions is not optimized. We have to introduce an additional data structure to make this check linear (N) and not NxN

The update of the outputs datagridview suffers from the error text icon updates. I will post this as a comment here to not forget it.

linked with #986

closed by #987


Add pythainlp.word_vector.WordVector

What does this changes
I add pythainlp.word_vector.WordVector. It's class for word vector. Its support thai2fit, ltw2v and more (in future).
Fixes #582
Your checklist for this pull request
🚨Please review the guidelines for contributing to this repository.

[ ] Passed code styles and structures
[ ] Passed code linting checks and unit test

Hello @wannaphong! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file pythainlp/word_vector/core.py:

Line 325:1: W293 blank line contains whitespace
Line 432:80: E501 line too long (80 > 79 characters)
Line 502:80: E501 line too long (82 > 79 characters)
Line 505:80: E501 line too long (80 > 79 characters)
Line 512:80: E501 line too long (82 > 79 characters)
Line 520:80: E501 line too long (80 > 79 characters)
Line 527:80: E501 line too long (80 > 79 characters)

Coverage increased (+0.01%) to 95.998% when pulling e2d5f50032013a9936b90b5bb4b6cfc16c713973 on add-ltw2v-word_vector into b24435956151569b035b85302992dcd2d303a7eb on dev.


Other RDBMS support

Describe the solution you'd like
I want to use this server for any postgres server
Additional context
https://github.com/sqls-server/sqls
This shows us folowing:
MySQL(Go-MySQL-Driver)
PostgreSQL(pgx)
SQLite3(go-sqlite3)
MSSQL(go-mssqldb)
H2(pgx)
Vertica(vertica-sql-go)
This means that sqls server doesn't suppor postgres server which doesn't use these engine?
My backend is on nodejs and 'pg' is as postgres client  library.
OR
sqls's support is not related to client/engines like 'pg' or 'pgx'
if we set a file like bellow?
# Set to true to use lowercase keywords instead of uppercase.
lowercaseKeywords: false
connections:
  - alias: dsn_mysql
    driver: mysql
    dataSourceName: root:root@tcp(<IP_ADDRESS>:13306)/world
  - alias: individual_mysql
    driver: mysql
    proto: tcp
    user: root
    passwd: root
    host: <IP_ADDRESS>
    port: 13306
    dbName: world
    params:
      autocommit: "true"
      tls: skip-verify
  - alias: mysql_via_ssh
    driver: mysql
    proto: tcp
    user: admin
    passwd: Q+ACgv12ABx/
    host: <IP_ADDRESS>
    port: 3306
    dbName: world
    sshConfig:
      host: <IP_ADDRESS>
      port: 22
      user: sshuser
      passPhrase: ssspass
      privateKey: /home/sqls-server/.ssh/id_rsa
  - alias: dsn_vertica
    driver: vertica
    dataSourceName: vertica://user:pass@host:5433/dbname

pgx is the client library that this sqls uses to talk to the postgres database, I imagine you should be able to configure it to talk to your server just fine.

@Lenbok
Hi. Thanks.
Do you mean that sqls REQUIRE pgx and live database connection to provide us to use autocompletion?
I would be happy if sqls provided auto-completion with just a reference to the schema file.
Because some user will not use golang.

Yes, a live connection is required.
sqls is written in golang, so your other statement doesn't make sense.


Generate a dungeon at the position of DungeonGenerateActor

DungeonGenerateActor cannot move far away from [0,0,0], it always spawn in [0,0,0]

Originally posted by @MichaelLiew1990 in https://github.com/shun126/UE5-DungeonGeneratorDemo/discussions/25

The dungeon is generated with the DungeonGenerateActor position as the origin (northwest position).
DungeonGenerateActorの位置を原点（北西の位置）にダンジョンを生成。

version 1.6.2 has been released.


Governance. Delegate to all tracks. Wrong track array

Description
When user try to delegate in all tracks it fall down with error:
convictionVoting.BadClass
example block:
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc-test-network-1.novasamatech.org#/explorer/query/0x58dd271ae8920ad4f1bb6174d206befbe1bdafe4d8bbad6e608b8b2457b18a87
Steps to Reproduce

Go to Governance page
Select Delegate case
Select all tracks
Delegate

Expected Behavior
Successfully delegate, NovaWallet extrinsic example for delegate to all tracks:
extrinsic
block
Actual Behavior
Error:
extrinsic
block
Environment
https://github.com/novasamatech/nova-spektr/commit/b684d4d72c57f1886b1f49125131fafe6db13165

Nova Wallet reference

Problem with model, it takes track list from Polkadot, there is no 2 track id on test network

Status verification: ✅


Adding an explicit error message in the case where the call to workspace memory allocator fails

Adding an explicit error message in the case where the call to workspace memory allocator fails
(in the routine MIOpenSupport::DoPrepareForConvolution).
Prior to this commit, the failure was getting ignored leading to misleading behaviour down the line.

In one case (alexnet, batch_size=1024, see MIOpen issue 1947), the subsequent call to "Find" (with allocated workspace memory size == 0) would fail, leading to a misleading error message indicating that "Find" failed to find an algorithm for the given convolution)
In another case (vgg16, see MIOpen issue 2052), the subsequent call to "Find" (with allocated workspace memory size == 0) returns a slower algorithm (than the algorithm that would have been returned if the call to allocate workspace memory had succeeded and consequently the workspace memory size argument to "Find" would have been set to the correct value)

In the first scenario above, adding the explicit error message is the right thing to do.
In the second scenario above, a warning (instead of a error) is something to consider.
In this case, we have (by accident, not ny design) the ability to "fall-back" to a "slower" algorithm (if one exists) when the workspace memory allocation fails.

If we use a warning instead of error, we will continue to have this "fall-back" capability.
On the flip-side a warning is easy to miss/ignore, and is not necssarily something folks check for when trying to debug performance issues.

@whchung @sunway513 should we change error to a warning?

Thank @deven-amd , my recommendation would be to keep it as "error", but adding something similar to the following hints as part of the failure message:
Setting TF_CUDNN_WORKSPACE_LIMIT_IN_MB to a larger number (e.g. 8000) might help

@whchung
I think there might be some bug lurking in XLA.
The same set of tests seem to be failing in the following runs

http://ml-ci.amd.com:21096/job/tensorflow-upstream-unit-tests-rocm-xla/656/
http://ml-ci.amd.com:21096/job/tensorflow-upstream-unit-tests-rocm-xla/668/
http://ml-ci.amd.com:21096/job/tensorflow-upstream-unit-tests-rocm-xla/669/

Run 656 happened in PR #613 (retest rocm-xla passed)
Run 669 is for this PR, and there are no code changes in this PR that should cause XLA failures
Run 668 is for the other PR I filed today (#628). That one also has some build failures which seem legit (those are in addition to the test failures)

@sunway513
I have updated the error message to the following:
2019-09-06 12:35:49.374795: E tensorflow/stream_executor/rocm/rocm_dnn.cc:2666] Failed to allocate scratch memory - Requested memory size<PHONE_NUMBER>) exceeds the max memory limit<PHONE_NUMBER>).
	You can set the env var TF_CUDNN_WORKSPACE_LIMIT_IN_MB to a larger number (e.g. 8192) to increase the max memory limit.
	Increasing the max memory limit might help resolve this error

I have verified that it is correctly triggered on the alexnet+batch_size=1024 scenario.
I want to verify that it triggers on the vgg16 case as well. How do I need to run that testcase (command line options, MIOpen version, etc) to make it hit the error scenario?

@deven-amd , thanks, that looks good.
Can you follow my instructions here to run VGG:
https://github.com/AMDComputeLibraries/MLOpen/issues/2052#issuecomment-528444191

I can reproduce the error on vgg16 as well
2019-09-06 16:49:26.599461: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library librocblas.so
2019-09-06 16:49:26.608125: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libMIOpen.so
2019-09-06 16:50:21.755352: E tensorflow/stream_executor/rocm/rocm_dnn.cc:2666] Failed to allocate scratch memory - Requested memory size<PHONE_NUMBER>) exceeds the max memory limit<PHONE_NUMBER>).
	You can set the env var TF_CUDNN_WORKSPACE_LIMIT_IN_MB to a larger number (e.g. 8192) to increase the max memory limit.
	Increasing the max memory limit might help resolve this error
Done warm up
Step	Img/sec	total_loss
1	images/sec: 96.3 +/- 0.0 (jitter = 0.0)	7.265
10	images/sec: 95.9 +/- 0.1 (jitter = 0.5)	7.277
----------------------------------------------------------------
total images/sec: 95.91
----------------------------------------------------------------

Interesting to note that the benchmark proceeds to run inspite of the error (guess because it is not a FATAL error)

only one failure in rocm-xla...
it is the intermittent failure that we keep seeing in (  //tensorflow/compiler/xla/tests:tuple_test_gpu )
See my comments

here https://github.com/ROCmSoftwarePlatform/tensorflow-upstream/pull/608#issuecomment-523059560
and here https://github.com/ROCmSoftwarePlatform/tensorflow-upstream/pull/608#issuecomment-523065170

same applies to this failure too

jenkins : retest rocm-xla please


AnnotationKey: Prevent issue of Feature/LF names colliding

Practically not a big issue if you just name all your LFs e.g. LF_xxx, but should not even be a possible bug...

Closed in v0.5.0


Specifying project status on the command line

Expected Behavior
In many projects we do not specify a version and let our CI infra to provide it with -Pversion=...
We'd like to also be able to specify -Dstatus=... to override the default status.
Current Behavior
Now we are trying to apply the same pattern with project status, and it doesn't seem to work:
Consider the build:
logger.lifecycle("before: $status")
if (status=='release') status = 'snapshot'
logger.lifecycle("after: $status")

The expectation is that if we run with -Pstatus=release the project will have status release, in all other cases - snapshot. In practice, the status is always snapshot
This works, but is way overwrought:
logger.lifecycle("before: $status")
project.status = (ext.properties.status ?: gradle.startParameter.projectProperties.get('status'))=='release' ? 'release' : 'snapshot'
logger.lifecycle("after: $status")

Context
Some of our builds have conditional behavior, which makes sense to model as build status, except that we are triggering it with nonstandard property (i.e. myCompanyBuildStatus). Using status in the same way we use version would make it cleaner and more intuitive.

Something is a bit off in your description:

In practice, the status is always snapshot

Which makes sense given your code:
if (status=='release') status = 'snapshot'

Could you create a small reproducer to show this problem? Thanks

I suspect the code was supposed to be if (status != 'release) ..., however that doesn't explain why the command line specified status value is ignored.
project.status is documented as having a default value of releasebut my project is reportingintegrationby default. Going on a bit of a hunt I found that thebaseplugin sets status tointegrationwhen applied, and therefore is overwriting anything set from the command line. https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/java/org/gradle/api/plugins/BasePlugin.java#L87 If I try an empty project that does not apply thebaseplugin then settingstatus` from the command line works as expected.

Going on a bit of a hunt I found that the base plugin sets status to integration when applied, and therefore is overwriting anything set from the command line.

That was a bug that we've just fixed. You'll be able to set the project status anywhere in your build script in Gradle 7.2.

This should work with the latest Gradle 7.2 snapshot.

@bmuskalla apologies, too much coding in notepad I reversed a condition somewhere. The 7.2 fix should work for me.


When terminate a inference, the dimensions doesn't match.

https://github.com/Kyubyong/transformer/blob/2234b4268355ccc073d8f0535fdd395289001151/model.py#L168
I know this line is used to end a inference, but y_hat.shape=[N, ?], and tf.reduce_sum(y_hat, 1) get a shape=[N],  how to compare with self.token2idx["<pad>"](a int value)?

Please tell me if i'm wrong.

@Kyubyong
I just ran two experiments, experiment 1 comments this line and the other one doesn't, and i find two results are equal completely. So, i think this code is not be used. Please check it.


replace "ghcr.io/distroless" with "cgr.dev/chainguard"

AFAIK, the registry address is changed from ghcr.io/distroless to cgr.dev/chainguard, but in this repository, images still use the old registry address.
https://github.com/chainguard-dev/actions/blob/515343e1d5871f6f11c88ed1618077b369af733e/setup-registry/README.md#L26
https://github.com/chainguard-dev/actions/blob/1b42233678dcfa02759e466dfe5c271abbc6b932/apko-build/action.yaml#L65
/cc @cpanato @imjasonh

ghcr.io/chainguard-dev/apko:v0.4.0 is still right, that's the image apko builds of itself: https://github.com/chainguard-dev/apko/pkgs/container/apko
Though maybe we should point folks to the wolfi-based one just to have one fewer image lying around.
I'll send a PR for setup-registry.
Thanks for bringing this to our attention! 👍


Make solid-auth-client work on Safari

Ive used it in the past on mobile successfully.  I will verify again when I get a chance.

Quick bit of extra info - I can reproduce this on desktop safari on macos.

Yes, confirmed! It works from the home page, but not from the 401.

So… it is a longstanding Safari bug with 302 redirects: https://bugs.webkit.org/show_bug.cgi?id=158420
https://rubentest.solid.community/ still uses /common/popup.html as popup URL, whereas the 401 page uses /.well-known/solid/login. The latter 302 redirects to the former, and the browser is supposed to send the hash (containing the OIDC login info) along with that. But it doesn't.
So I will need to remove the redirect from the server, and also fix #54.

This is fixed, right?

Yes, #872.


Feedback on introduction to Azure for Developers

Information has been concise and easy to follow, with regards to opening page.
Kindly
BrightFameLabs

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

ID: d58c633a-e315-cc57-0783-ea5e7f4868d5
Version Independent ID: d58c633a-e315-cc57-0783-ea5e7f4868d5
Content: Azure for developers overview
Content Source: articles/intro/azure-developer-overview.md
Service: azure-devops
Sub-service: azure-devops-reference
GitHub Login: @mcleanbyron
Microsoft Alias: mcleans

Thank you for the positive feedback, @BrightFam!


Add brew release command

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?
[ ] Have you successfully run brew man locally and committed any changes?

This PR adds a new brew release developer command to automate the release process. The command, by default, will simply bump the patch version number. If --major or --minor is passed, the command will bump the major and minor version numbers respectively (and reset other numbers to 0 as needed).
This PR is still extremely rough (hence being marked as a draft). I'm going to immediately cancel CI because I know there are issues that I haven't yet fixed locally. However, I have a few general questions, so I figured I'd open this to track my progress.
I also plan on updating the Release docs in this PR in the future.
Additionally, there's some overlap between this command and brew release-notes that I plan on extracting to a new module.

Questions

Should there be any interactivity in this command? At the moment, the whole thing runs in about 5 seconds so there isn't really any time for a frantic control-c if someone realizes they messed up. I wonder if we should make this require an additional confirmation before pushing the tags and creating the release. I know we generally like to avoid interactivity, but I don't think this command should even be used in a script so I'm not super worried about that. I'm open to other options here as well.
What is the best way to determine the "current tag." At the moment, I'm simply running a git fetch origin (although I'm now realizing I probably want git fetch --tags origin) before the command starts and then simply taking the highest version number from git tag --list --sort=-version:refname *.*.*. Is there a way to determine the latest upstream tag rather than relying on local tags? I guess an alternative would be to query GitHub for the latest release and then use that as the base. An extension question would be: is it okay to assume that those who will run this command will be in a reasonable repository state?
How should non-tip-of-the-master-branch releases be handled? I know that there's debate about this in #9331 so I don't need to duplicate that here. For the moment, I think I'm going to assume the following: the brew release command will be designed for creating releases only at the tip of the master branch. If a non-tip-of-the-master-branch release is desired, this command should not be used. Is that acceptable? If so, I'll probably either call brew update within the command or simply fail if the brew repo isn't up to date (or, to be more precise, I'll check that git rev-parse HEAD matched git rev-parse origin/HEAD).
I think we should sign tags when possible. Should we run git tag --sign by default? If not, should we add a --sign flag to brew release to control this? I have tag.gpgSign enabled in my ~/.gitconfig so my tags would be signed either way, but I'm sure tha not all maintainers do.
More specifically, how do I handle the scopes for the GitHub API call? I'm a little confused with what needs to be specified here. GitHub.open_api takes an optional scopes argument. In GitHub.create_pull_request, the GitHub.CREATE_ISSUE_FORK_OR_PR_SCOPES constant which is set to public_repo is passed. What (if any) scope needs to be used for creating a release? Obviously, some write access to the repo is needed. Just not totally sure what to do here and hoping someone can guide me through it :)

Quick Summary
Based on my answers to the questions above, here is what I'm picturing (at the moment) will happen when this command is run:

git fetch --tags origin is run in the background.
If git rev-parse HEAD doesn't match git rev-parse origin/HEAD, fail
Find the most recent tag using git tag --list --sort=-version:refname *.*.*
Generate the new tag based on args.major? and args.minor?
If creating a major/minor release, check to make sure the latest release was less than a month ago. If so, fail unless --force is passed (which should change the failure into a warning that's still displayed)
Create the new tag locally using git tag and maybe --sign
Generate the release notes
Asking for a final confirmation before pushing the tag and creating the release
Run git push origin <tag> to push the tag
Create a new release using the GitHub API
Print the url to the release
Open the url in a browser unless --no-browse is passed.

CC @MikeMcQuaid

Review period will end on 2021-01-21 at 06:59:28 UTC.

Review period will end on 2021-01-21 at 06:59:28 UTC.

Should there be any interactivity in this command?

No.

I wonder if we should make this require an additional confirmation before pushing the tags and creating the release.

I would say it's not worth pushing the tags (which cannot be undone) but instead telling the maintainer what command to run to do so.

2. What is the best way to determine the "current tag." At the moment, I'm simply running a git fetch origin (although I'm now realizing I probably want git fetch --tags origin) before the command starts and then simply taking the highest version number from git tag --list --sort=-version:refname *.*.*.

Sounds good.

2. Is there a way to determine the latest upstream tag rather than relying on local tags? I guess an alternative would be to query GitHub for the latest release and then use that as the base.

Yes, query GitHub.

2. An extension question would be: is it okay to assume that those who will run this command will be in a reasonable repository state?

Yes.

3. For the moment, I think I'm going to assume the following: the brew release command will be designed for creating releases only at the tip of the master branch.

Sounds good (forever, in my opinion).

3. If a non-tip-of-the-master-branch release is desired, this command should not be used. Is that acceptable?

Yes.

4. I think we should sign tags when possible. Should we run git tag --sign by default?

Yes.

5. GitHub.open_api takes an optional scopes argument. In GitHub.create_pull_request, the GitHub.CREATE_ISSUE_FORK_OR_PR_SCOPES constant which is set to public_repo is passed. What (if any) scope needs to be used for creating a release?

public_repo should be sufficient. The GitHub API docs should be able to confirm.

Should there be any interactivity in this command?

No.

I wonder if we should make this require an additional confirmation before pushing the tags and creating the release.

I would say it's not worth pushing the tags (which cannot be undone) but instead telling the maintainer what command to run to do so.

2. What is the best way to determine the "current tag." At the moment, I'm simply running a git fetch origin (although I'm now realizing I probably want git fetch --tags origin) before the command starts and then simply taking the highest version number from git tag --list --sort=-version:refname *.*.*.

Sounds good.

2. Is there a way to determine the latest upstream tag rather than relying on local tags? I guess an alternative would be to query GitHub for the latest release and then use that as the base.

Yes, query GitHub.

2. An extension question would be: is it okay to assume that those who will run this command will be in a reasonable repository state?

Yes.

3. For the moment, I think I'm going to assume the following: the brew release command will be designed for creating releases only at the tip of the master branch.

Sounds good (forever, in my opinion).

3. If a non-tip-of-the-master-branch release is desired, this command should not be used. Is that acceptable?

Yes.

4. I think we should sign tags when possible. Should we run git tag --sign by default?

Yes.

5. GitHub.open_api takes an optional scopes argument. In GitHub.create_pull_request, the GitHub.CREATE_ISSUE_FORK_OR_PR_SCOPES constant which is set to public_repo is passed. What (if any) scope needs to be used for creating a release?

public_repo should be sufficient. The GitHub API docs should be able to confirm.

Thanks, that's good feedback. I'm in agreement about not pushing the tags. Makes sense to not even risk it.
Can you create a draft release that isn't attached to a tag? I'll have to play around with it. It's certainly ideal if that's the case.

GitHub.open_api takes an optional scopes argument. In GitHub.create_pull_request, the GitHub.CREATE_ISSUE_FORK_OR_PR_SCOPES constant which is set to public_repo is passed. What (if any) scope needs to be used for creating a release?

public_repo should be sufficient. The GitHub API docs should be able to confirm.

This is saying that the token being used must have access to all public_repos that the user it's associated with has access to, right?

Thanks, that's good feedback. I'm in agreement about not pushing the tags. Makes sense to not even risk it.
Can you create a draft release that isn't attached to a tag? I'll have to play around with it. It's certainly ideal if that's the case.

GitHub.open_api takes an optional scopes argument. In GitHub.create_pull_request, the GitHub.CREATE_ISSUE_FORK_OR_PR_SCOPES constant which is set to public_repo is passed. What (if any) scope needs to be used for creating a release?

public_repo should be sufficient. The GitHub API docs should be able to confirm.

This is saying that the token being used must have access to all public_repos that the user it's associated with has access to, right?

Can you create a draft release that isn't attached to a tag?

Yup! The tag isn't created until it's published. That's often the flow I do for creating a release.

This is saying that the token being used must have access to all public_repos that the user it's associated with has access to, right?

Yes, think so.

Can you create a draft release that isn't attached to a tag?

Yup! The tag isn't created until it's published. That's often the flow I do for creating a release.

This is saying that the token being used must have access to all public_repos that the user it's associated with has access to, right?

Yes, think so.

Review period ended.

Review period ended.

Okay, here's where this command currently stands.
Running brew release will create a draft PR with the correct release notes. It doesn't actually create the tag locally and push but relies on the tag being created when the new release is published. By default, the tag is created at the tip of the master branch. I believe this can be customized if we want, instead, to create the tag at the HEAD commit of the user running the release command. Since in almost all cases the release it at the tip (I know there's a debate about this), I don't think this is necessary.
The --major and --minor flags can be passed to create a new major or minor release, respectively. If neither is passed, a patch release will be made. The command will fail if a major/minor release is requested and the latest major/minor release was published less than one month ago (determined by querying the GitHub API).
In order to generate the appropriate release notes, this command needs to have the latest commits on origin/master fetched locally. I've added the auto-update functionality to the brew release command. To work around the case where HOMEBREW_NO_AUTO_UPDATE is set (which may be true for maintainers), I added an extra step that runs git fetch origin only if HOMEBREW_NO_AUTO_UPDATE is set. This will ensure that the latest master branch commits are available locally. Do we need to explicitly call git fetch origin master or is git fetch origin enough? Or another command?
Alternatively, another option is to query the GitHub API for the latest commit on the master branch. If it detects that the local origin/HEAD does not point to the same commit that the GitHub API reports, it will prompt the user to run brew update. Not sure which is preferred.
I've also refactored some of the shared logic between the brew release command and the brew release-notes command. I think the two commands are distinct enough that they should both be kept. However, the brew release-notes command is no longer used in our release process so could theoretically be removed.
Lastly, I've updated the release documentation.

Okay, here's where this command currently stands.
Running brew release will create a draft PR with the correct release notes. It doesn't actually create the tag locally and push but relies on the tag being created when the new release is published. By default, the tag is created at the tip of the master branch. I believe this can be customized if we want, instead, to create the tag at the HEAD commit of the user running the release command. Since in almost all cases the release it at the tip (I know there's a debate about this), I don't think this is necessary.
The --major and --minor flags can be passed to create a new major or minor release, respectively. If neither is passed, a patch release will be made. The command will fail if a major/minor release is requested and the latest major/minor release was published less than one month ago (determined by querying the GitHub API).
In order to generate the appropriate release notes, this command needs to have the latest commits on origin/master fetched locally. I've added the auto-update functionality to the brew release command. To work around the case where HOMEBREW_NO_AUTO_UPDATE is set (which may be true for maintainers), I added an extra step that runs git fetch origin only if HOMEBREW_NO_AUTO_UPDATE is set. This will ensure that the latest master branch commits are available locally. Do we need to explicitly call git fetch origin master or is git fetch origin enough? Or another command?
Alternatively, another option is to query the GitHub API for the latest commit on the master branch. If it detects that the local origin/HEAD does not point to the same commit that the GitHub API reports, it will prompt the user to run brew update. Not sure which is preferred.
I've also refactored some of the shared logic between the brew release command and the brew release-notes command. I think the two commands are distinct enough that they should both be kept. However, the brew release-notes command is no longer used in our release process so could theoretically be removed.
Lastly, I've updated the release documentation.

Running brew release will create a draft PR with the correct release notes. It doesn't actually create the tag locally and push but relies on the tag being created when the new release is published. By default, the tag is created at the tip of the master branch. I believe this can be customized if we want, instead, to create the tag at the HEAD commit of the user running the release command. Since in almost all cases the release it at the tip (I know there's a debate about this), I don't think this is necessary.

👍🏻

In order to generate the appropriate release notes, this command needs to have the latest commits on origin/master fetched locally. I've added the auto-update functionality to the brew release command. To work around the case where HOMEBREW_NO_AUTO_UPDATE is set (which may be true for maintainers), I added an extra step that runs git fetch origin only if HOMEBREW_NO_AUTO_UPDATE is set. This will ensure that the latest master branch commits are available locally. Do we need to explicitly call git fetch origin master or is git fetch origin enough? Or another command?
Alternatively, another option is to query the GitHub API for the latest commit on the master branch. If it detects that the local origin/HEAD does not point to the same commit that the GitHub API reports, it will prompt the user to run brew update. Not sure which is preferred.

I am fine with any of these options. I'd probably suggest "whichever one requires the least code to handle this edge case".

I've also refactored some of the shared logic between the brew release command and the brew release-notes command. I think the two commands are distinct enough that they should both be kept. However, the brew release-notes command is no longer used in our release process so could theoretically be removed.

Good to know. Perhaps it's worth deprecating? Could add a commented-out odeprecated and I can remove on the next release?

Running brew release will create a draft PR with the correct release notes. It doesn't actually create the tag locally and push but relies on the tag being created when the new release is published. By default, the tag is created at the tip of the master branch. I believe this can be customized if we want, instead, to create the tag at the HEAD commit of the user running the release command. Since in almost all cases the release it at the tip (I know there's a debate about this), I don't think this is necessary.

👍🏻

In order to generate the appropriate release notes, this command needs to have the latest commits on origin/master fetched locally. I've added the auto-update functionality to the brew release command. To work around the case where HOMEBREW_NO_AUTO_UPDATE is set (which may be true for maintainers), I added an extra step that runs git fetch origin only if HOMEBREW_NO_AUTO_UPDATE is set. This will ensure that the latest master branch commits are available locally. Do we need to explicitly call git fetch origin master or is git fetch origin enough? Or another command?
Alternatively, another option is to query the GitHub API for the latest commit on the master branch. If it detects that the local origin/HEAD does not point to the same commit that the GitHub API reports, it will prompt the user to run brew update. Not sure which is preferred.

I am fine with any of these options. I'd probably suggest "whichever one requires the least code to handle this edge case".

I've also refactored some of the shared logic between the brew release command and the brew release-notes command. I think the two commands are distinct enough that they should both be kept. However, the brew release-notes command is no longer used in our release process so could theoretically be removed.

Good to know. Perhaps it's worth deprecating? Could add a commented-out odeprecated and I can remove on the next release?

In order to generate the appropriate release notes, this command needs to have the latest commits on origin/master fetched locally. I've added the auto-update functionality to the brew release command. To work around the case where HOMEBREW_NO_AUTO_UPDATE is set (which may be true for maintainers), I added an extra step that runs git fetch origin only if HOMEBREW_NO_AUTO_UPDATE is set. This will ensure that the latest master branch commits are available locally. Do we need to explicitly call git fetch origin master or is git fetch origin enough? Or another command?
Alternatively, another option is to query the GitHub API for the latest commit on the master branch. If it detects that the local origin/HEAD does not point to the same commit that the GitHub API reports, it will prompt the user to run brew update. Not sure which is preferred.

I am fine with any of these options. I'd probably suggest "whichever one requires the least code to handle this edge case".

Sounds good. I went with the one-line git fetch solution.

In order to generate the appropriate release notes, this command needs to have the latest commits on origin/master fetched locally. I've added the auto-update functionality to the brew release command. To work around the case where HOMEBREW_NO_AUTO_UPDATE is set (which may be true for maintainers), I added an extra step that runs git fetch origin only if HOMEBREW_NO_AUTO_UPDATE is set. This will ensure that the latest master branch commits are available locally. Do we need to explicitly call git fetch origin master or is git fetch origin enough? Or another command?
Alternatively, another option is to query the GitHub API for the latest commit on the master branch. If it detects that the local origin/HEAD does not point to the same commit that the GitHub API reports, it will prompt the user to run brew update. Not sure which is preferred.

I am fine with any of these options. I'd probably suggest "whichever one requires the least code to handle this edge case".

Sounds good. I went with the one-line git fetch solution.

Okay, I'm going to go ahead and merge this. @MikeMcQuaid let me know how this works! (I'm assuming you'll be the one to make the next release).

Okay, I'm going to go ahead and merge this. @MikeMcQuaid let me know how this works! (I'm assuming you'll be the one to make the next release).


Linting for shell and GitHub Actions

More linting!
Adds linting for shell and GitHub Actions workflows:

https://github.com/koalaman/shellcheck
https://woodruffw.github.io/zizmor

Also fixes an oversight in the CMake linting setup.

My initial push at commit https://github.com/Cambridge-ICCS/FTorch/pull/206/commits/e128fe3a024a0c663580118091e68fba376644d4 shows the static analysis workflow failing because I'd only applied lint fixes to the static_analysis.yml. With my second push at commit https://github.com/Cambridge-ICCS/FTorch/pull/206/commits/5858a6be5d4e78db8523fe643145636cc932a8d0 it passes.

#207 has been merged into the branch here so should be merged first.

They seem active projects. I note zizmor is in beta, so perhaps we want to pin the version similar to fortitude, to avoid unexpected complaints.
We also need the docs updating to detail these, and I note that shellcheck is not pip installable. Seems installable via all sensible package managers. I wouldn't know where to start with Windows packaga managers, but don't see this as an issue as our docs state "follow the instructions in the linter docs".

Thanks @jatkinson1000. Addressed in https://github.com/Cambridge-ICCS/FTorch/pull/206/commits/2834064705796bc428b4f6145dda13ffaadbaea7.


R.isEmpty({}) returns false

R.isEmpty('') returns true,
R.isEmpty([]) returns true

but
R.isEmpty({}) returns false
=> If an object is observed as a collection of (enumerable) properties, this can be considered inconsistent. If Object.keys({}) returns [], it may make sense to consider the object as empty

If an object is observed as a collection of (enumerable) properties, this can be considered inconsistent.

That's a pretty big "if". I note that the documentation says:

Reports whether the list has zero elements.

(emphasis added)
And:
/* ...
 * @example
 *
 *      R.isEmpty([1, 2, 3]); //=> false
 *      R.isEmpty([]); //=> true
 *      R.isEmpty(''); //=> true
 *      R.isEmpty(null); //=> false
...*/

So one can work with plain objects by isEmpty(keys({})) which transforms the object to a list. That said, it does feel pretty natural to expect isEmpty({}) to be true. Curious for other opinions.

I understand and can agree with the reasoning that isEmpty operates on lists. Probably an example should clarify the use case, as you mentioned:
 R.isEmpty({}); //=> false  R.isEmpty(R.keys({})); //=> true

I understand and can agree with the reasoning that isEmpty operates on lists. Probably an example should clarify the use case, as you mentioned:

:+1:

I'm definitely not in favor of changing the function to handle the empty object type as well.  This is simply part of our List API.

We discussed the possibility of changing the behaviour of R.isEmpty({}) in #539.
Let's add the two examples @xorcus suggested.


Hosts configuration

How do you configure the hosts? Can we add an inventory file? thanks

It uses Ansible's default inventory to generate the list of nodes / hosts. It's the same as when you call ansible without the -i or --inventory-file option (default is most likely /etc/ansible/hosts).

Is there a way to specify an inventory file thought the plugin?

@dhafley not yet. I'm unsure how to implement the configuration option, as I haven't done much stuff with Rundeck and its plugins. It would need to be in a config file I guess, probably per project, so all Ansible plugins know about it.
Definitely want this, though.

Running Debian 8 and ansible 1.7.2 with rundeck 2.6.6. I've installed the plugin, but for some reason it can't populate nodes from the default hosts file (/etc/ansible/hosts). I can successfully run:
# su rundeck -s /bin/bash -c "ansible all -m ping"
<my_ip> | success >> {     "changed": false,      "ping": "pong" }
Attached is the error log of rundeck where I think the error has occured.
ansible_rundeck_error.txt

HI, check the right of /etc/ansible/hosts ans /var/log/ansible.log  with the user rundeck.

-rw-r--r-- 1 root root   85 Apr 21 11:51 hosts
The error I get as shown in the error file is Error gathering facts

@ecsumed

the plugin is trying to create a /data directory on the hosts from the inventory file

It creates a new temp dir (/tmp/rundeck/ansible-hosts9102979686939565663/ according to line 68 in your logfile) and copies a playbook and template file into it. It then runs ansible with this dir as the working directory (see this line and around).
The playbook then creates a data/ subdir, which it didn't do in your case, for whatever reason. Maybe it didn't find any hosts or there is something special with your /tmp dir.
P.S. Please open a new issue the next time, your concern is separate from this issue. ;)

I've run into a similar problem.
I can run a ping as suggested but there is:

com.dtolabs.rundeck.core.resources.ResourceModelSourceException: Error reading facts.
...
Caused by: java.nio.file.NoSuchFileException: /tmp/rundeck/ansible-hosts6030625997178406791/data

the data file is not created. I can run the playbook in the same directory as the rundeck user and it outputs the data/ directory, no problem. It seems there is a problem with the executing of this from rundeck. Any indication as to what might be different?
I run the generated playbook:

ansible-playbook gather-hosts.yml

@smcavoy-travelbird please test the newest version and see the README on how to enable debug mode. Also please create a new issue if the problem persists, as it has nothing to do with the OP.

Closing due to inactivity.

Do you have to use the rundeck user, im not pulling any hosts from my host file. But ive set everything up to use an ansible user.


[CELEBORN-1190] Apply error prone patch and suppress some problems

What changes were proposed in this pull request?

Fix MissingOverride, DefaultCharset, UnnecessaryParentheses Rule
Exclude generated sources, FutureReturnValueIgnored, TypeParameterUnusedInFormals, UnusedVariable

Why are the changes needed?
./build/make-distribution.sh --release

We get a lot of WARNINGs.
Does this PR introduce any user-facing change?
No
How was this patch tested?
GA

Emm... I think at least we can not fix all MissingOverride cases while supporting multiple Spark/Flink versions.

I think at least we can not fix all MissingOverride cases while supporting multiple Spark/Flink versions.

So I kept some methods without adding @Override, which is why GA passed.

cc @cfmcgrady, consider including this patch into 0.4.0 (or at least branch-0.4) to reduce the potential conflicts of future cherry-picking

thanks, merging to main(v0.5.0)/branch-0.4(v0.4.0).


add --output parameter

As mentioned in Issue #1480, I added a --output option, which will write to a file, instead of stdout.
I created a de-facto interface, from which the most important methods are inherited.
There are three Writer-classes:

DefaultWriter
Prints to stdout
FileWriter
append to a file, regardless if it exists or not (but user is warned that file exists if it does)
QuietWriter
does nothing at all

I could only select master as the base branch, and not e.g. upcoming/v4.10 as is suggested in contributing.md

I chose master as base branch, because I could not select upcoming/v4.10, as suggested in contributing.md