Sliders won't move in short distances when competing with other drags

Recording:
Steps to Reproduce

Get any Slider
Touch on the thumb
Move slightly to left or right (usually within the ripple area), it won't move.

I tried using the sample code from Gallery app and it is fully reproducible. It seems, however, that the official Gallery app (which was last updated months ago) doesn't have this issue.
Edit: this is what cause the issue. kTouchSlop should be 0 for this scenario.
https://github.com/flutter/flutter/blob/cd84ceaf5e3e8eee6a1e803938e176bdeb2efef0/packages/flutter/lib/src/gestures/monodrag.dart#L526
Logs

➜ flutter doctor -v
[✓] Flutter (Channel dev, v1.10.1, on Mac OS X 10.14.6 18G95, locale en-BR)
    • Flutter version 1.10.1 at /usr/local/Cellar/flutter/dev
    • Framework revision ce45c2d3e6 (5 days ago), 2019-09-06 20:11:41 -0400
    • Engine revision b9ce2500d9
    • Dart version 2.5.0 (build 2.5.0-dev.4.0 be66176534)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /Users/bernardoferrari/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: /Users/bernardoferrari/Library/Application
      Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/191.5791312/Android
      Studio 3.5 Preview.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 10.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.3, Build version 10G8
    • CocoaPods version 1.7.3

[✓] Android Studio (version 3.5)
    • Android Studio at /Users/bernardoferrari/Library/Application
      Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/191.5791312/Android
      Studio 3.5 Preview.app/Contents
    • Flutter plugin version 39.0.3
    • Dart plugin version 191.8423
    • Java version OpenJDK Runtime Environment (build
      1.8.0_202-release-1483-b49-5587405)

[✓] Android Studio
    • Android Studio at /Users/bernardoferrari/Library/Application
      Support/JetBrains/Toolbox/apps/AndroidStudio/ch-1/192.5863777/Android
      Studio 3.6 Preview.app/Contents
    • Flutter plugin version 39.0.4
    • Dart plugin version 192.6527
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)

[✓] IntelliJ IDEA Ultimate Edition (version 2019.2.2)
    • IntelliJ at /Users/bernardoferrari/Applications/JetBrains Toolbox/IntelliJ
      IDEA Ultimate.app
    • Flutter plugin version 38.2.4
    • Dart plugin version 192.6459

[✓] VS Code (version 1.38.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.4.1

[✓] Connected device (1 available)
    • SM G9600 • 23a1f4ee1a057ece • android-arm64 • Android 9 (API 28)

• No issues found!

If this used to work, we should first determine why it regressed, and then write a test for it.
Changing the slop shouldn't be necessary. The slop only matters when there's competing gesture detectors.

The slop only matters when there's competing gesture detectors.
I think this is precisely the issue.

In flutter_gallery, the range sliders are inside a Column. There is no scrolling factor, yet this triggers the issue. In my apps most of them are also in a Column.
Additionally, I'm also curious regarding the slop, even in ListView. I've never seen this in other platforms. Shouldn't it be optional?

We need to bisect to find when it regressed. The best way to do that is to create a unit test that exactly reproduces the issue you're concerned with, verify that it worked in the past, and then use git bisect to automatically determine what commit broke it.

Additionally, I'm also curious regarding the slop, even in ListView. I've never seen this in other platforms. Shouldn't it be optional?

When it's working correctly, the touch slop is the distance you have to go for us to distinguish a horizontal drag from a vertical drag when both are possible (and similar things between other kinds of gestures). Android has something similar from what i can tell by dragging sliders inside list views (e.g. the Audio Balance slider in the Accessibility settings on Q).
It should have no impact in the case being discussed here, where there's no other gesture competing.

I tested here in Accessibility and you are right - a bit inconsistent, since in other places it doesn't follow this, but you are right.
On native Android, they added support for the touch slop in the Material Components library this week!! https://github.com/material-components/material-components-android/commit/a7da96fac0f18684898131221c3fa628b38e7f3e
This is possibly the reason why you hardly ever see this in Android. And it is going to break a few apps in the coming months, or years, when this is eventually released. Therefore, we might see both usages for a long time.
According to @clocksmith  in the PR, it isn't a regression because the sample changed but the way it works has always been this way. I guess it makes it a feature request, then? But there is an additional issue:
On iOS (Settings -> Display & Brightness), the slider doesn't have the touch slop but doesn't jump when you slide your finger, only when you tap.
However, CupertinoSlider relies in HorizontalDragGestureRecognizer https://github.com/flutter/flutter/blob/fcaf9c4070bc726585a221279b3c94e37f49698d/packages/flutter/lib/src/cupertino/slider.dart#L338 which causes the same issue listed here with touchSlop. And, you can't tap on it to scroll.
So I guess we could make HorizontalDragGestureRecognizer accept a touchSlop (either boolean for default value or int which would make it more scalable) parameter and CupertinoSlider make use of it? And maybe make it optional on Material, not the default like iOS, but optional?

Correct this is not a regression. It started surfacing on the old flutter gallery once the demo was put into tabs, and there was competing gesture detection.

I was able to reproduce this on latest stable channel. Tested with the Gallery project!

flutter doctor -v
[✓] Flutter (Channel stable, 1.20.3, on Mac OS X 10.15.6 19G2021, locale en)
    • Flutter version 1.20.3 at /Users/pedromassango/dev/SDKs/flutter_stable
    • Framework revision 216dee60c0 (9 days ago), 2020-09-01 12:24:47 -0700
    • Engine revision d1bc06f032
    • Dart version 2.9.2

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK at /Users/pedromassango/Library/Android/sdk
    • Platform android-30, build-tools 30.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.7)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.7, Build version 11E801a
    • CocoaPods version 1.9.3

[!] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] IntelliJ IDEA Community Edition (version 2020.2.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 48.1.4
    • Dart plugin version 202.7206

[✓] VS Code (version 1.48.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.13.2

[✓] Connected device (1 available)
    • sdk gphone x86 arm (mobile) • emulator-5556 • android-x86 • Android 11 (API 30) (emulator)

! Doctor found issues in 1 category.
Process finished with exit code 0

Hi this still appear in latest flutter (2021.1.1). Will it be solved? Thanks!

Hi this still appear in latest flutter (2021.1.1). Will it be solved? Thanks!

Any updates on this?

@bernaferrari suggested setting the touchSlop to 0 and making it configurable. I think that could work. @HansMuller does that seem like a good solution?

Turns out the jump has gone with https://github.com/flutter/flutter/pull/82152

How?

onStart is now called only once per drag, so there's no jump after the slop. The slop is still there though

Oh, so the issue is still valid..

Yes

Hello @bernaferrari, I tried running the gallery app on the latest master channel, and it seems to drag the handle fine I believe this issue is fixed.
https://user-images.githubusercontent.com/31410839/211722431-a266eced-ae8a-4c50-ba02-79d53ad36d4d.mov

flutter doctor -v
[!] Flutter (Channel master, 3.7.0-15.0.pre.16, on macOS 13.1 22C65 darwin-arm64, locale en-IN)
    • Flutter version 3.7.0-15.0.pre.16 on channel master at /Users/mahesh/Development/flutter_master
    ! Warning: `flutter` on your path resolves to /Users/mahesh/Development/flutter/bin/flutter, which is not
      inside your current Flutter SDK checkout at /Users/mahesh/Development/flutter_master. Consider adding
      /Users/mahesh/Development/flutter_master/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/mahesh/Development/flutter/bin/dart, which is not inside
      your current Flutter SDK checkout at /Users/mahesh/Development/flutter_master. Consider adding
      /Users/mahesh/Development/flutter_master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 7ddf42eae5 (4 days ago), 2023-01-06 17:44:44 -0500
    • Engine revision 33d7f8a1b3
    • Dart version 3.0.0 (build 3.0.0-85.0.dev)
    • DevTools version 2.20.0
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git"
      directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0-rc4)
    • Android SDK at /Users/mahesh/Library/Android/sdk
    • Platform android-33, build-tools 33.0.0-rc4
    • ANDROID_HOME = /Users/mahesh/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14A400
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2021.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)

[✓] IntelliJ IDEA Community Edition (version 2021.2.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 61.2.4
    • Dart plugin version 212.5080.8

[✓] VS Code (version 1.74.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.56.0

[✓] Connected device (3 available)
    • Redmi K20 Pro (mobile) • <IP_ADDRESS>:5555 • android-arm64  • Android 11 (API 30)
    • macOS (desktop)        • macos           • darwin-arm64   • macOS 13.1 22C65 darwin-arm64
    • Chrome (web)           • chrome          • web-javascript • Google Chrome 108.0.5359.124

[✓] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

Closing as fixed, Incase you still encounter the issue, then please feel free to write in the comments and we will reopen it.
Thank you.

They probably just removed the horizontal listview. The issue is still there, just the sample that changed.

Thanks for the update  @bernaferrari, I tried the below code sample which wraps Slider in a Horizontal ListView-> GestureDetector, But the slider seems to slide just fine. Let me know if the code sample doesn't represent the actual issue.

code sample
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);
  final String title;
  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  double _value = 0.0;
  @override
  Widget build(BuildContext context) {
    Widget _slider() => Slider(
          value: _value,
          onChanged: (double newValue) {
            setState(() {
              _value = newValue;
            });
          },
        );

    return Scaffold(
      appBar: AppBar(
        // toolbarHeight: 48,
        title: Text(widget.title),
      ),
      body: Center(
        child: Stack(
          children: [
            Row(
              children: [
                Expanded(
                  child: ListView(
                    scrollDirection: Axis.horizontal,
                    children: <Widget>[
                      GestureDetector(
                        child: _slider(),
                      ),
                    ],
                  ),
                ),
                Expanded(child: _slider())
              ],
            ),
            Align(
                alignment: Alignment.topCenter,
                child: Text(_value.toStringAsPrecision(2)))
          ],
        ),
      ),
    );
  }
}

It seems the logic now is touch only. Shouldn't happen with mouse. I think this is mostly fine.


disable Rails/HasManyOrHasOneDependent

they say fortune favors the bold so... here's a PR!
See issue (linked below) for my rationale.
closes #50

I agree, there are valid cases where you don't want to do this. I might keep it in if Rails offered a better option than nil for specifying "don't do anything" (like :ignore), but even then I'm :-1: on any rule that'd make some people just add more ceremony for the sake of making a linter happy


ET-STM32 Stamp: An STM32F103RET6 target for NuttX

Dear list, greetings!
Summary
This PR brings NuttX to the ET-STM32 Stamp module [1] from Futurlec. I
also utilized this opportunity to get familiar with the NuttX
internals and parts of the ARM codebase. Many thanks for NuttX!
I went through the list of already supported STM32F103 platforms. I
picked Maple as a starting point. I made an et-stm32-stamp directory
and added an initial NSH configuration. I touched boards/Kconfig for
menuconfig.
The Stamp is a very compact PCB with just pinouts. It doesn't have any
on-board peripherals; Not even a GPIO_LED OR a button I can detect
with an interrupt.
The nsh configuration is very minimal for now. It doesn't initialize/utilize
any other MCU peripheral of the on-board STM32F103RET6. I will slowly
start adding newer configurations by reading stm32f103-mimimum/.
Impact
This PR doesn't conflict with any other board/sub-system. It is
independent.
Testing

I have tested et-stm32-stamp/nsh using WSL with my Stamp
module. I have documented the details in the board README file. Can
you please let me know if the code is OK and if there's anything
else I can do in this regard?

This PR should pass the CI tests.

Many thanks.
References:
[1]: https://www.futurlec.com/ET-STM32_Stamp.shtml

Many thanks for the suggestions David!


[Update] Add JavaFX

https://github.com/mhrimaz/AwesomeJavaFX
Just a JavaFX awesome list
By submitting this pull request I confirm I've read and complied with the below requirements.
Failure to properly do so will just result in the pull request being closed and everyone's time wasted. Please read it twice. Most people miss many things.

I have read and understood the contribution guidelines and the instructions for creating a list.
This pull request has a descriptive title. For example, Add Name of List, not Update readme.md or Add awesome list.
The entry in the Awesome list should include a short description about the list project/theme (not the list itself), and should be added at the bottom of the appropriate category.
The list I added

has been around for at least 30 days,
is the result of hard work and is the best I could possibly produce,
is a non-generated Markdown file in a GitHub repo,
is not a duplicate,
includes a succinct description of the project/theme at the top (example),
includes a project logo/illustration (whenever possible) at the top right of the readme (example). (The logo should link to the project website or any relevant website. The logo should be high-DPI, so set it to maximum half the width of the original image.),
only has awesome items with descriptions (Awesome lists are curations of the best, not of everything),
contains the awesome badge on the right side of the list heading,
has a Table of Contents section named Contents as the first section,
has an appropriate license (Meaning something like CC0, NOT a code licence like MIT, BSD, Apache, etc) (If you use a license badge, it should be SVG, not PNG),
has contribution guidelines,
doesn't include a Travis badge,
has been checked for inconsistent formatting, spelling, and grammar:

Each link description starts with an uppercase character and ends with a period.
Drop all the A / An prefixes in the descriptions.
Consistent naming. For example, Node.js, not NodeJS or node.js.

By submitting this pull request I confirm I've read and complied with the below requirements.

⬆

To clarify @sindresorhus, this is what I noticed is missing:

includes a project logo/illustration (whenever possible) at the top right of the readme (example). (The
logo should link to the project website or any relevant website. The logo should be high-DPI, so set it to maximum half the width of the original image.),
has a Table of Contents section named Contents as the first section,
has an appropriate license (Meaning something like CC0, NOT a code licence like MIT, BSD, Apache, etc)
has contribution guidelines,
has been checked for inconsistent formatting, spelling, and grammar:

Thanks for clarify.
I pull a contribution guideline and change the two first point.

Seems every point said by @legodude17 are fine now.

I marked off the ones I saw that you finished.

As @legodude17 said, there are still many points not fulfilled - please have a check again.


create: add --ruby option

Make possible executing brew create --ruby to create basic template for building Ruby gems.

[ ] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] 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 tests with your changes locally?

Any ideas why brew tests failed?

Looks like a flaky cask test. Could you create an issue and/or delete it?

Flaky test deleted.

Thanks again @dawidd6!


rails 4 compass init trouble

bundle exec compass init --trace
NoMethodError on line ["223"] of /Users/ivan/.rvm/gems/ruby-2.0.0-p247/gems/compass-rails-1.1.2/lib/compass-rails.rb: undefined method config' for nil:NilClass   /Users/ivan/.rvm/gems/ruby-2.0.0-p247/gems/compass-rails-1.1.2/lib/compass-rails.rb:129:in configuration'
/Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/configuration/helpers.rb:44:in configuration_for'   /Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/configuration/helpers.rb:22:in add_configuration'
/Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/configuration/helpers.rb:107:in add_project_configuration'   /Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/commands/project_base.rb:31:in add_project_configuration'
/Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/commands/installer_command.rb:9:in configure!'   /Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/commands/project_base.rb:15:in initialize'
/Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/commands/stamp_pattern.rb:69:in initialize'   /Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/exec/sub_command_ui.rb:42:in new'
/Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/exec/sub_command_ui.rb:42:in perform!'   /Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/lib/compass/exec/sub_command_ui.rb:15:in run!'
/Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/bin/compass:30:in block in <top (required)>'   /Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/bin/compass:44:in call'
/Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/gems/compass-0.12.2/bin/compass:44:in <top (required)>'   /Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/bin/compass:23:in load'
/Users/ivan/.rvm/gems/ruby-2.0.0-p247@global/bin/compass:23:in `'

Same error here, with rails 4.2.6, ruby 2.3.0 and latest compass-rails. Can we reopen?


308 remove guava multimap

What
Replaced Guava Multimap usages.
How

Reworked the batching of revsDiff to first break down by doc ID then by groups of rev IDs up to the placeholder limit. Previously in cases where a rev ID clashed between documents the SQL statement could return revisions from the database that did not match the list of revisions passed in. Since the revision list is filtered by the revsDiff the impact was simply calling remove for entries that didn't exist so it did not cause any issues, but it seems more clear to avoid the ambiguity.
Added ValueListMap to provide Map<String, List<String>> implementation
with functionality to add values to a key.
Refactored methods using Multimap to use Map<String, List<String>>.
Replaced Multimap creation with ValueListMap.

Testing
Existing tests continue to pass. No new tests as the usage of the map should be covered by the revs diff testing.
Issues
Part of #308

one small comment, once thats done +1


Library is not compatible with Serilog.Sinks.Http 8.0.0

Error appears when library Serilog.Sinks.Http with version 8.0.0 directly referenced in project
Unhandled exception. System.TypeLoadException: Could not load type 'Serilog.Sinks.Http.BatchFormatters.BatchFormatter' from assembly 'Serilog.Sinks.Http, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=24c2f752a8e58a10'.
   at System.Reflection.RuntimeAssembly.GetExportedTypes(QCallAssembly assembly, ObjectHandleOnStack retTypes)
   at System.Reflection.RuntimeAssembly.GetExportedTypes()
   at Serilog.Settings.Configuration.ConfigurationReader.<>c.<FindConfigurationExtensionMethods>b__32_0(Assembly a)
   at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.MoveNext()
   at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.MoveNext()
   at System.Linq.Enumerable.WhereEnumerableIterator`1.ToList()
   at Serilog.Settings.Configuration.ConfigurationReader.FindEventEnricherConfigurationMethods(IReadOnlyCollection`1 configurationAssemblies)
   at Serilog.Settings.Configuration.ConfigurationReader.ApplyEnrichment(LoggerConfiguration loggerConfiguration)
   at Serilog.Settings.Configuration.ConfigurationReader.Configure(LoggerConfiguration loggerConfiguration)
   at Serilog.Configuration.LoggerSettingsConfiguration.Settings(ILoggerSettings settings)

Note: BatchFormatter was removed in latest version of library

Updates are now released with v7.0.0


Update Landscape Entry for Monte Cimone

Changes requested
Hello,
could you change the project category :
from Services
to Implemantations/HPC Systems
thank you

@bprestonlf +1.


Nextworkflow chain

create-job-script:

Adds ability for applications to chain methods together, enabling many-step processing. This is done by defining "nextworkflow" in every method of the application meant to have a successor. Still hardcoded to start with "mainflow" method.

Now treating the first method (mainflow) the same as the other ones. Sending in a dictionary and expecting a list of questions in return. Application base no longer needs the self._questions list.

Example application using this is available in ID 84  "chain2", chaining through 3 methods with differing paths.
    mainflow <--- START
    /      \
Sim         Mesh
    \       /
      wrapup

Branch can be deleted after merge.

Closing this. Incorporated changes to with PR 20: https://github.com/omnivector-solutions/jobbergate-cli/pull/20


Application Sharing does not work with OIDC SSO

Description:
Application sharing feature is not implemented to work with the OIDC SSO.
Affected Product Version:
APIM-2.1.0

@rmsamitha Can we close this issue now, Have we completed the improvement mentioned in this issue?

Yes. We can.


feat(control_data_collecting_tool): add control_data_collecting_tool

Description
This package provides tools for automatically collecting data using pure pursuit control within a specified rectangular area.

Related links

Tests performed
Tested on autoware simulator. how to test
Notes for reviewers
Draft version is discussed at https://github.com/proxima-technology/autoware_tools/pull/1 (in Japanese).
Interface changes

Effects on system behavior

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[x] The PR follows the pull request guidelines.
[x] The PR has been properly tested.
[x] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@th1991-01
could you please pass spell check
https://github.com/autowarefoundation/autoware_tools/actions/runs/9557648448/job/26405720334?pr=33

@masayukiaino
please rebase on main branch to pass build

@masayukiaino
this PR include changes of other files. so please rebase after https://github.com/autowarefoundation/autoware_tools/pull/68 is merged

@masayukiaino

this PR include changes of other files. so please rebase after https://github.com/autowarefoundation/autoware_tools/pull/68 is merged

tthis PR have been mered, so please rebase


Set override option for CDN Origin Hostname and Host Header

Makes it easier to add a proxy host between the CDN and the Container App

Requires https://github.com/DFE-Digital/trams-data-api/pull/328 to be merged first


ctf-cbp2-pistola-msuzip_1be0340e

Add content:

[UT2004 MAP] CTF-CBP2-Pistola

Submission log: https://unrealarchive.org/submit/#1be0340e

Duplicate


[help wanted]some problems occured while running the example wrt socket?

when i run "python3 main.py --env-name "PongNoFrameskip-v4""
the errors  come:
Exception in user code:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 137, in _new_conn
(self.host, self.port), self.timeout, **extra_kw)
File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 91, in create_connection
raise err
File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 81, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 560, in urlopen
body=body, headers=headers)
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 354, in _make_request
conn.request(method, url, **httplib_request_kw)
File "/usr/lib/python3.5/http/client.py", line 1106, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python3.5/http/client.py", line 1151, in _send_request
self.endheaders(body)
File "/usr/lib/python3.5/http/client.py", line 1102, in endheaders
self._send_output(message_body)
File "/usr/lib/python3.5/http/client.py", line 934, in _send_output
self.send(msg)
File "/usr/lib/python3.5/http/client.py", line 877, in send
self.connect()
File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 162, in connect
conn = self._new_conn()
File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 146, in _new_conn
self, "Failed to establish a new connection: %s" % e)
requests.packages.urllib3.exceptions.NewConnectionError: <requests.packages.urllib3.connection.HTTPConnection object at 0x7f36bef06668>: Failed to establish a new connection: [Errno 111] Connec.
the last few lines are: File "/baselines/baselines/common/vec_env/subproc_vec_env.py", line 58, in init
observation_space, action_space = self.remotes[0].recv()
File "/usr/lib/python3.5/multiprocessing/connection.py", line 250, in recv
buf = self._recv_bytes()
File "/usr/lib/python3.5/multiprocessing/connection.py", line 407, in _recv_bytes
buf = self._recv(4)
File "/usr/lib/python3.5/multiprocessing/connection.py", line 379, in _recv
chunk = read(handle, remaining)
ConnectionResetError: [Errno 104] Connection reset by peer
Didn't find the answer on Stack Overflow, please help me out.

Run visdom
python -m visdom.server

Or update the repo, I've just disabled visdom by default

Or update the repo, I've just disabled visdom by default

it seems like the some errors happen when connect to visdom server .
i've run visdom.server,but the errors still be there


File does not contain any LC_VERSION_MIN_* load command.

I'm not really familiar with jtool or tbd file generation but I found this project through a Stackoverflow answer where you help someone get .tbd files linked for PrivateFramework linking. I followed your instructions to extract from the dyld cache with jtool -e AvatarKit dyld_shared_cache_arm64 but when I run ./tbdump dyld_shared_cache_arm64.AvatarKit >AvatarKit.tbd I get this error: [!] Data format error while parsing dyld_shared_cache_arm64.AvatarKit: File does not contain any LC_VERSION_MIN_* load command. Any ideas?

Could you upload/share the library in question?

@Siguza Same issue with IOKit from iOS 12.1.1
IOKIt.zip

I'm getting this error too

I found this thread talked about this problem, that LC_VERSION_MIN_* are no longer emitted when building machos for newer Darwin systems, they are superseded by LC_BUILD_VERSION.

Sigh. Thing is, tbdump is broken on so many ends... I seriously thing efforts would be better spent trying to add dyld_shared_cache support on top of tpoechtrager/apple-libtapi.


Return "Getting Started" resources first when no parameters specified

When the user first arrives at the Resources page on the front end, they are presented with whatever resources the database happens to serve up. Since we don't yet have featured categories on the front end, it would be nice to go ahead and serve up some resources that are relevant for beginners who maybe have no idea where to start on their learning journey. There are a bunch of great blog posts and similar "Getting Started" materials in the Getting Started category. From there, they can search for what they want, or filter by categories/languages.
Acceptance criteria: When a request is made without any filter parameters to the GET /resources endpoint, the API should return "Getting Started" resources, followed by all the other resources available (paginated).
This should be able to be accomplished by adding an ORDER BY clause in this particular case. I have an idea adapted from this stackoverflow post:
ORDER BY
   CASE category
      WHEN 'getting started' THEN 1
      ELSE 2
   END, id

I have no idea how to do this with Flask-SQLAlchemy, but we'll figure it out. Importantly, we shouldn't add this ORDER BY clause unless there are no other parameters at all. So we'll want some unit tests around this. I don't think it needs to be added to the documentation so we can skip making changes to the openapi.yaml file.

I found a good example for this in SQLAlchemy. https://stackoverflow.com/a/17494735
I think this can be implemented within an if statement somewhere around here.

Oh nice!  I'll try and implement that tomorrow during lunch. Thank you.
Get Outlook for Androidhttps://aka.ms/ghei36

From: Richard Brown<EMAIL_ADDRESS>Sent: Tuesday, June 30, 2020 9:55:15 PM
To: OperationCode/resources_api<EMAIL_ADDRESS>Cc: jtmst<EMAIL_ADDRESS>Assign<EMAIL_ADDRESS>Subject: Re: [OperationCode/resources_api] Return "Getting Started" resources first when no parameters specified (#338)
I found a good example for this in SQLAlchemy. https://stackoverflow.com/a/17494735
I think this can be implemented within an if statement somewhere around here.https://github.com/OperationCode/resources_api/blob/37ab0b449ff180432237c6884370f9e14d56f91e/app/api/routes/resource_retrieval.py#L46
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/OperationCode/resources_api/issues/338#issuecomment-652140400, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOWFFCTSOIDWFLUA23WEP7DRZKJQHANCNFSM4OJMX4OQ.


[DOC] Missing exported and globals from documentation

I was just looking through the documentation and had to google both a /* global ... */ example and how to suppress functions used by other code. I then found an answer on SO and #659.
It would be nice if directives was mention in the options page. I realize it was my bad not finding them on the main documentation page but I came to jshint from a link on cloud9 and I'm guessing others will have the same entry.

The globals option is now documented on jshint.com's "options" page. It includes a reference to the corresponding directive ("To configure globals within an individual file, see Inline Configuration.") The exports directive continues to be documented with the other directives, but because it has no associated configuration option, it does not belong on the "options" page.
Thanks for the report!


Don't take the parent kind of trailing attributes in attr completion

bors r+
fixes https://github.com/rust-analyzer/rust-analyzer/issues/9076

bors retry


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 14:06:29 on 2023.06.02
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 0, errors out: 0
Original problem ID: 23141
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=23141

Problem has been resolved in 15m 0s at 14:21:29 on 2023.06.02
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 23141


Update api.md

The chunked option for the line protocol is split in two parameters. The doc conflates the two in one single parameter (which might have been the case in the past) but sniffing the traffic on chunked queries showed that the current behavior should be the one proposed here.

Thanks, @hrbonz !

No problem, I found that out when doing testing for this PR https://github.com/influxdata/influxdb-python/pull/753, would appreciate a nudge to get this moving ;)


Refactor logging statements to address CA2254

Currently we have a lot of CA2254 warnings in the codebase due to how we generate log messages.
Here's an example:
_logger.LogInformation($"Using merged config file based on environment:{configToBeUsed}.");

The issue is that we're not using log templates which enable better structured logging.
Ideally, the code should be:
_logger.LogInformation("Using merged config file based on environment:{configToBeUsed}.", configToBeUsed);

NLog has a good overview on structured logging.
This issue is to track the codebase-wide refactor.

Branching from https://github.com/Azure/data-api-builder/pull/1402#discussion_r1202762244

Whenever this is picked up, I would suggest and highly appreciate breaking up this refactor into multiple PRs to make reviewing quick and straightforward.

Yep, we should create a feature branch and do PRs into that branch so it can be reviewed piece by piece.

As a follow up to #1541, which has tests that validates the logger logs the expected messages:
We can have more explicit validation of the logged messages:

This requires us to turn our message templates into constants with variables used for structured logging present within curly braces: `string messageTemplateError = "{runtimeConfigFile} does not exist."
Then, validate that the expected log message template is logged  (this value is available to us without having to run String.Contains() or String.Split()
Optionally validate that the expected variable value is used. in this example, the runtimeConfigFile value is as expected.

You can do this with the following (copied from my comment on dotnet/runtime/issues/ 67577 #issuecomment-1625920776):

I think unit testing should be done using the interface (IReadOnlyList<KeyValuePair<string, object>>). I now think the most valid reason for these methods is for re-implementing your own log methods, not unit testing.

Your suggestion pointed me in the right direction (at least from my perspective in order to achieve the validation behavior I was seeking). I was attempting to validate the originally formatted error message, which contains variable(s) surrounded by curly brackets {variable} when using structured logging. The originally formatted error is present in FormattedLogValues collection.
I used examples other suggested for how to use Moq to verify the logging invocation, combined with a helper function to parse out and validate the key value pair contents:
            loggerMock.Verify(
                x => x.Log(
                LogLevel.Error,
                It.IsAny<EventId>(),
                It.Is<It.IsAnyType>((o, t) => ValidateLoggedState(o, t)),
                It.IsAny<Exception?>(),
                (Func<It.IsAnyType, Exception?, string>)It.IsAny<object>()
                ),
                Times.Once
            );

and
    public bool ValidateLoggedState(object o, Type t)
    {
        // Cast FormattedLogValues (internal class) to a list of key/value pairs.
        IReadOnlyList<KeyValuePair<string, object>> loggedValues = (IReadOnlyList<KeyValuePair<string, object>>)o;

        // Validate that a log with the expected message template is present.
        bool expectedErrorMsgTemplateExists = loggedValues.Any(kvp => kvp.Key == "{OriginalFormat}" && kvp.Value.ToString() == ErrorMessages.ERRMESSAGEFILEEXISTS);

        //Validate that the expected variable was used for filling the template.
        //For demonstration purposes since there may not be a point to doing this.
        bool formattedErrorMsgExists = loggedValues.Any(kvp => kvp.Key == "runtimeConfigFile");

        // Validation result.
        return expectedErrorMsgTemplateExists && formattedErrorMsgExists;
    }


Missing Format and NameQualifier attribute in AUTHN_REQUEST template

Hi!
I noticed it is not provided the possibility to add NameQualifier and Format attributes to the element Issuer in the AUTHN_REQUEST template. It would be great if we could set them in the settings file, like others.
Thank you!

+1

The saml:Issuer element is an optional parameter of an AUTHN_REQUEST.
NameQualifier, SPNameQualifier, Format and SPProvidedID  are also optional attributes of the Issuer element.
Support that will turn the settings more complex and this is something that we want to avoid.
If your projet requires it, I recommend to extend the toolkit with a custom AuthNRequest class that support that.

Hi!
I have the same requirement of @zephir89. It's true that saml:Issuer element is an optional parameter but can be "requested" by custom IDP.
And if I choose to use this library with my django application can be helpful (and a great feature) to set this optional parameter on my SP settings.
Thank you.
Salvo.


Validation if set

"if_set" was the best name I found for this rule.
It acts like the "sometimes" and cancels the field validation if no data is sent with the rule key.
"if set" because is possible set data out of an input request...

That's an interesting way to implement it. Looking at the tests I was at first thinking it was wrong since required was still there and it wasn't enforcing required when if_set was present. I can see it being useful to manage create/update rules in the same place, though, where if the field was present in the submitted form at all (which it might not be in the case of an update), then you ignore it, but if it is (like with a create) then it applies all of the other rules.
I'm a little concerned that it does ignore required, though I'm not sure I need to be.
Does my example meet the way you intended it to work?

Yes.
This rule will cancel all others. Including the required.
With it, the field required only will be run if the field is "set" (have an associated key in the array of data).
Of course, if this rules is present with a HTML Form request, and the user remove the inputs with the browser inspector he could "to trick" the validation.
If the field is required to all requests then this rule must not be used.
But continues to be useful when necessary, I think...

The required was an example rule in the tests to run with an empty string. Showing that it is not the same that isset() because it do not looks the value but if the data key is set/present.

The name could be field_sent, data_set... I do not know how it is more easy to understand in English...
The required can be the "master" rule and be more "important" than it. But, because this will check first the key and not the value, my first thoughts was that must have priority. Contrary to what happens with the sometimes there.

No the functionality is fine, and I can see it being helpful. It's just that initially I was thinking of it more like sometimes.
I think maybe if_exists is a better term, though, since set could imply a value exists for it.

If exists. What exists? if_field_exists, maybe...
Well, I'm going to have dinner. I'll answer later if necessary. Good night. 😄

If exists. What exists?

The same could be said about is_set. Is what set? :)

Hahah, yes


How to return to native code from flutter library

Duplicate of https://github.com/flutter/flutter/issues/25235


Trusted header authentication backend

Just wanted to open this up to discussion, what is the consensus on adding trusted headers as an authentication strategy? This would open up some options and allow for example nginx to do client certificate checks and set headers with user details or allow more complex user checks to be offloaded to the proxy layer.

Do you have something in mind 😃 ? For now we have worked on a REST API that authenticates through headers: you have to set the PORTUS-AUTH header like this: username:authentication-token. But you are talking about certificates and such, so what do you have in mind ?

So the primary use case for me is client certificate authentication to Portus itself, the user still uses a password to docker login using application tokens or whatever.
I've seen things in Apache that fake basic auth by doing the client authentication first and then creating a header, but in this case it would need to look up a valid token/password for the user from Portus.
I'm proposing an Devise::Strategies::Authenticatable class that just takes a username from a header and allows the person in, granted this puts a dependency on the admin deploying this to be aware that if this setting is turned on the proxy layer must ensure that the header cannot be set by and end user.


NO-JIRA: Fix recover-etcd cmd marking a missing flag required

What this PR does / why we need it:
The recover-etcd command was setting up a flag that doesn't exist as required. This PR cleans up that and fixes the require flags handling logic.
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/assign @jparrill @csrwng

/lgtm

/approve


Transcript is now an Entity

As suggested by the TAs in our feedback, transcript should really be an entity to make our application more scalable. In this PR, I have used the approach we discussed after class with the TAs. Basically, Transcript is a sub document of the whole Schema.
Changes are made in both the client and server reflect the changes.

As mentioned in the group chat, the tests are failing. Let's keep this not merged until we fix the tests, to make sure nothing is broken.

Great work Dhairya. The transcript indeed appears to be an entity now, and as we have confirmed earlier with the TAs, it being a Mongoose Schema is an acceptable Clean Architecture practice in this project.

I have added some changes to the tests to reflect the updates to the transcripts, and have included mock functions in my tests to eliminate/reduce coupling between modules.

Besides this, I think this is a good addition and will definitely help our project's scalability by explicitly specifying the Transcript's attributes as an Entity.


Fix Person and Program endpoint

Fix program path when calling it from tw alias endpoint
Fix person path when calling it from tw alias endpoint

@rpeterman-gp when you have time. Can you please review this PR? Thanks


Drop Tracks and Courses in favor of Collections

Tracks and Courses do pretty much the same things. Having an entity like a Collection is a good way to still represent this idea but leaving it more open to usage. Collections can have sections so that if someone decides to have a collection sectioned into different areas they can still do this (a.k.a Tracks).

#10 Resolves this.


Adding bowerify gem to fix the issue with relative assets paths in bower components

hey guys, there is a little gem called bowerify that fixes the relative assets path when you use bower components in rails assets pipeline.

What's the status of this pull request?

I've tried to go on working on it but met an issue https://github.com/ninefold/bowerify/issues/2.
Actually, I prefer to implement our own (or extract some logic out of bowerify if it is possible)  to close this issue. But now I have lack of time to achieve it.
So, if anyone can help with that — welcome!


feat: Community Event functionality

Summary of Changes
-Related to #137

seems fine from the limited testing I can do


Implement CODEOWNERS

https://github.blog/2017-07-06-introducing-code-owners/
We have made great strides in Node-Fetch these few months but I feel that things have been moving very fast in this repo even with having every PR reviewed by 3 people before merging.
So I am introducing CODEOWNERS.
So basically, we have a set of people that have to approve for Code Changes. Others can also approve like the maintainers, but i suggest we have 2 - 3 people approve the code. As for the 2 -3 people, I think it should be those in the @node-fetch/core for Code Changes.
For other PR's that don't have code change, we can have both @node-fetch/core and @node-fetch/reviewers take a look at it.
You might be thinking about why this might be needed.
In the past week, we merged 27 PR's
Take a look in the spike of code deletions and additions
We had two releases and one was a fix.
So, we definitely need to slow things down ( mainly merging ) and take a look at reviewing code.
Reviewing code is as important as writing it.

If we come to the conclusion of implementing this feature, I can get started on working on a PR.

Totally true

While I'm complete :+1: for CODEOWNERS I have a couple of comments regarding the rest of the issue motivation:

There is nothing wrong in a contribution surge for a project with a small team and without full-time authors - as it all freetime contributions (somebody does that because have time between projects, somebody due to immediately need to fix a bug, and somebody because he is jobless and would like to contribute to the community in the meanwhile (me 🙋🏻♂))).

The problem with bugfix release was found by a team member in less than 2 hours and mitigated not only with the regression test (#838), but also with minimum review policy change.

I think no developers team should set "slow down" as an objective - if test suites are comprehensive, code review policy in place and contributions coming - that's great and should be appreciated, and not be seen like something suspicious.

Introducing a more strict policy on merging PRs is a great idea. However, a couple of notes:

the releases you mentioned were made before introducing the minimum review requirements;
some of the PRs included in the amount were not related to code, but to things like Github Actions, documentation, issue/PR templates;
the huge spike happened in March when we merge the 3.x branch into master and  published the first beta versions, which contained many issues;

And just like @tinovyatkin said - with better tests, the new review policy, and now the CODEOWNERS file, we will be able to work on the 3.x version relatively quickly without much risks involved.

@tinovyatkin I agree with you but... one comment.
1.) I am not attacking you in any way, I also made tons of PRs and Issues during the time. I was reflecting and saying that we all should be a little more careful when merging. I am a student dev and for all I know, we are all in here together working on node-fetch. It is a tough time for everyone around the world and we are here working on node-fetch, which is great and we all appreciate you for helping to fix tons of issues.

@xxczaki I agree with you on the comments above. The surge was not all code but other maintenance stuff in the repo.

We already require at least 3 PR reviewers. In my opinion, we already have enough safeguards.

Are you sure? I think we should enable it, because what if those 3 reviews were from ppl that are not a node-fetch member. Anyone can review and approve code in Github, and it would count as a review. CODEOWNERS makes sure at least 1 or 2 people from the @node-fetch/core have taken a look at it.

If anything, PR's might be not merged for an extra day or two.

@xxczaki @bitinn What's your opinion?

@Richienb I feel like the current system works just fine. We might want to implement CODEOWNERS when some accidents start to happen, which is unlikely with 3 required reviews.

Anyone can review and approve code in Github, and it would count as a review.

Only review from a members with write access are counting toward required reviews.
And PR merging are notoriously slow now.

@tinovyatkin We can try and reduce the number of required reviews to 2 if you want. If it works well, we can leave it like so.

@tinovyatkin At the moment, I don't think any prs are being held back by a lack of reviewers. However, when we get to that point, I'll be happy to reduce the requirement.

It’s not about what I want, but I think that for a project with existing 100% coverage 3 reviews is overkill and requires a lot of dedication from team members and a lot of patience from a contributor.
I mean, there is some PRs that are too boring to review, etc.
What @NotMoni is missing here is that CODEOWNERS primary function is not to require review from somebody (this is actually an option in setting), but to automatically request review from a person mentioned there for a changed file. For example, I would love to be the codeowner for Headers and TypeScript files, because I’d basically rewritten them from the scratch recently.
That said, I that the ideal settings will be codeowners + 2 required review.
That said, I

but to automatically request review from a person mentioned there for a changed file.

👍

And anyway maintainers should not loss the common sense before merging - even when requirements by reviews are met - if there is an ongoing discussion in a PR or some request for change not attended - it’s no go for merge.

Alright, then.
I think everyone wants to use CODEOWNERS as a way to request a review from a person.
So put an 👍 if you agree and if we hit 5 👍 then we can implement it.

If the main issue is we are merging too fast, I think an alternative solution would be to add a label that indicate a PR needs more consensus / feedbacks, such that core members shouldn't merge too hastily.
In cases like:

breaking changes;
adding major features;
build pipeline, package.json, export updates;

These PR have potential to cause issues for many users, so we should ensure reviews are being done properly and not just merge based on approval count.
It's not always possible to find the code owner as we are probably all doing this part-time.
Preferably reviewers should write some comments after reviewing, so that people in charge of merging is not left to wonder how in-depth the review was.

@NotMoni just a note: not a meticulously implemented CODEOWNERS will do more pain than benefits:

It's better to not put a file into CODEOWNERS if we are not absolutely sure that there is an original author or person with deep knowledge in the area who is in the team.
It's better to not put as a codeowner a maintainer who may not have enough time for reviews
CODEOWNERS works best when project structure is as modulized as possible, for example, XO and tsd should be separated from package.json as, most probably, they should have different code owners. When test modularization will be finished then particular test should probably also have different code owners.

I mean, it's not a copy a template work, if you up for it prepare to do good research first, so, we will not repeat the experience with PR templates.

@tinovyatkin 😔Alright

Is it just me or somebody else are feeling that 3 reviews basically stops the project movement? We’ve merged only minor documentation fixes since the requirement was introduced.

@tinovyatkin @node-fetch/core
I changed the number of required PR reviews from 3 to 2, hopefully this will help.


A question about Interface Document

hi,when I read hyper intereface document at https://hyper.readthedocs.org/en/latest/api.html, a problem confused me.
HTTPConnection's parameter port——"The port to connect to. If not provided and one also isn’t provided in the host parameter, defaults to 443".
I think  something wrong is there, it should default to 80 not 443 in practice.
Looking forward your answer and wish you have a nice day!

Good spot, the documentation is wrong: it does default to 80. Do you feel like changing the documentation there?

I'd like to ,but I don't know how to do that =.=


list_render: Extend test to verify that list sorting is case insensitive.

The alphabetic sorting of lists in the User/Organization settings was changed in fa0a5ec to be case insensitive.
This commit makes changes to the list_render.js test to verify that the sorting of these lists is indeed case insensitive.
This is in relation to the commit here.

@timabbott This is the change to the list_render test that you asked me to add.

Looks great, merged, thanks @vinitS101!


Warn when server not started on running host

If an attempt is made to start a server on a host port that is already running, echo a useful warning:
"A server is already running on host " . g:OmniSharp_host

OmniSharp#StartServerIfNotRunning() is called from ftplugin.
Users will see a warning every time they open a .cs file with this change.

Oh right, I only start the server manually - I can add an argument to prevent this when called from ftplugin ... or is this functionality really only useful to me, and not worth merging?
My use case is that I have several solutions, and a vim instance for each. So solution1 starts OmniSharp on port 2000, solution2 starts OmniSharp on port 2001 etc. I often try to reuse a port by accident, and this is currently not handled well - OmniSharp loads all dependencies before realising the port is in use and crashes.

Perhaps this is too personal by my own workflow - I will add the check to my vimrc instead. After all, OmniSharp#StartServerIfNotRunning is an undocumented function anyway.


Accessibility requires tween.js

Scenery's FocusLayer requires TWEEN for animating the focus cursor.  Simulations that do not include Tween-r12.js as a dependency will crash with an error if the user presses tab twice (first tab press does not animate).  We should discuss whether we should make every simulation depend on Tween-r12.js or take another approach.  I'll schedule it for discussion at Tuesday's developer meeting.

Moved to https://github.com/phetsims/scenery/issues/364, closing.


Permissions

Latest Spigot version 1.13.2
Problem plugin is SimplePortals.
Issue: Add simpleportals.* perm, and all users can use all portals.
Use just the simpleportals.portal.jungle perm and user can't use that portal.
Any help much appreciated.
Muddup

Use the verbose command from LP, to find out what permissions are required.
Also please don't use issues here to ask for support with plugins other than LP.


VSC crashing and hanged

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

VS Code Version: Version: 1.89.0
Commit: b58957e67ee1e712cebf466b995adf4c5307b2bd
Date: 2024-05-01T02:09:22.859Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Windows_NT x64 10.0.22631
OS Version: W11

Steps to Reproduce:

Just start VSC and crashed and if trying open some dir

If not crash then when run python project loosing debugs icons

re: oom: sounds like your machine may be low on RAM?
The second issue- the Python extension may not be activated or installed but it's likely related to the first issue?

This can be done easy if code is long or mane files or many problems in code, when VSC is overloaded with some addons.
https://github.com/microsoft/vscode/issues/210085


pythonPackages.blis: add missing dependency numpy

Motivation for this change
blis' numpy dependency seems to have been falsely satisfied by its inclusion in checkInputs, whereas this seems to actually be an install dependency. This can be demonstrated by attempting to build this package with doCheck = false and watching it fail.
Also removed cython from checkInputs as it's already in nativeBuildInputs.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Thanks!
Result of nixpkgs-review pr 96664 1

9 packages built:
- python27Packages.blis
- python37Packages.blis
- python37Packages.spacy
- python37Packages.textacy
- python37Packages.thinc
- python38Packages.blis
- python38Packages.spacy
- python38Packages.textacy
- python38Packages.thinc

blis indeed failed when importing an actual function (e..g. from blis.py import einsum).


Theme konnectd

Bring konnectd frontend, create ownCloud theme and generate assets.

Open tasks:

[ ] Changelog item
[ ] Replace placeholder logo with the ownCloud one when generating
[ ] Bring ownCloud favicon when generating

There are some parts of the frontend which are probably not required but were causing a lot of errors when removed. I'd like to go in a separate PR through them when there'd more time and do some followup cleanup.

@micbar Have you got some idea why this line is not respected by codacy https://github.com/owncloud/ocis/pull/698/files#diff-3404650b2859b064f8b0527d200936d6b306cf8e11437f0051b38af5aeaab1c2R4 and the error in webpack config is still showing up?

@LukasHirt this file is no longer used.
Use the top level one and adapt the paths

same for the .gitignore

@LukasHirt please rebase to current master. A grpc-ecosystem package that we are using in some Makefiles has been renamed => already adjusted on master.

please rebase to current master. A grpc-ecosystem package that we are using in some Makefiles has been renamed => already adjusted on master.

Done 😉

Use the top level one and adapt the paths

Still getting the error even though I moved it in there 😞

file konnectd/ui/src/images/owncloud-logo.svg is part of this PR and should be removed or some placeholder image, right?

Right, thanks!

There are some files from the original kopano theme (augmenting teamwork, etc) which could be removed

I removed leftover images for now but regarding other files is this comment:
There are some parts of the frontend which are probably not required but were causing a lot of errors when removed. I'd like to go in a separate PR through them when there'd more time and do some followup cleanup.

The font size of the input fields is too small. It should be 1rem, but is 0.8...rem. With the current size it looks weird coming from the login form with tiny font size to ownCloud Web with quite big font size.

Per request from the marketing team, I have adjusted this according to the ownCloud website form inputs where it is the same font size.

The font size of the input fields is too small. It should be 1rem, but is 0.8...rem. With the current size it looks weird coming from the login form with tiny font size to ownCloud Web with quite big font size.

Per request from the marketing team, I have adjusted this according to the ownCloud website form inputs where it is the same font size.

Hm... I don't agree. 😅 Styling the login page should be consistent with phoenix, not the website. 👀  We're going back and forth between phoenix and the login page, the website is never part of this process.

Addressed your comments @refs and increased font size and changed the height of inputs to reflect the other ones in ocis-web @kulmann Thank you both for reviews! I've rebased the PR also so hopefully the random API tests failures will be gone.

love it!


Opening full details on a curation fails and reloads the page.

When you access .../curations/ you should see a view with all the changed definitions listed. If there you click on the magnifying glass for one of the components listed the full details page should open. That currently fails and just the curations page just reloads.
I've not had time to investigate

Hi @jeffmcaffer , is this something related to #267 ?
We need a real URL to check this out, could you please provide one so we can test it and solve it?
Thank you!

I was not able to repro in dev. For exapmle, I tried https://dev.clearlydefined.io/curations/185 and it worked fine.
There is definitely some quirks in this space but this issue may not capture. I'm going to close and reopen if necessary.


Implement search by attribute

Hi @nbareil,
I just added search by attribute.
Cheers

And download of attached files

Closing, resolved in #5


Bug when registering custom trainer

When users register a custom trainer with a file name of, e.g., MyTrainer.py in federatedscope/contrib/trainer/, a ValueError from call_link_level_trainer() in gfl/trainer/linktrainer.py, line 210, is raised.
This is because in core/auxiliaries/trainer_builder.py, line 97, the code iterates through the list of custom registered trainers, and call_link_level_trainer() in gfl/trainer/linktrainer.py is called, which raises ValueError because trainer_type of the custom trainer does not match. Therefore, trainer_builder is not able to find the custom trainer that users registered.
To reproduce this, one can simlpy register a custom model that calls line 97 in trainer_builder.py.
To fix this, the call function can be modified to return None if trainer_type does not match, then the iteration in trainer_builder.py, line 97 will work properly.
I made a  PR that fixes the problem. The same problem exists in nodetrainer.py, so I modified both files. This bug exists in the master branch as well as the cikm22competition branch, which may forbid the participants to register their trainer, so it should be fixed there too. #274

Thanks a lot for your comments and pr:) Please @rayrayraykk give the review and have a discussion if necessary


Display data as it is made available

Changes the overview chart and the timegraph chart to display data as it is being loaded.
Changes are more notable in the overview. For the timegraph chart, even though the "analysis running" message was replaced by the direct display of data being loaded, its duration is normally short.
To see its effect, one should set the overview to open the "CPU Usage" analysis (set on preferences), because the "CPU Usage" displays a chart before having the user to select any series.
The effect is evident when a new large trace that makes several calls to the fetchTree endpoint is opened. After it is loaded, the result of the calls is cached and all charts open quickly.
Other charts like the "Disk I/O View" do not show the data as it is being loaded because they need the user to make a selection first. Therefore, on those charts, the "analysis running" message was kept on display while loading.
Fixes #816
https://user-images.githubusercontent.com/88502808/199540228-7a116efe-9a03-4d4e-8e15-e8dbfbbaa4fa.mp4
Signed-off-by: Rodrigo Pinto<EMAIL_ADDRESS>

For me locally, the CPU Usage view doesn't show a gradually loading trace with this applied. The behaviour looks like the one before this change. (Same for the Overview.)
And for the latter, the usual rotating arrow pair beside the message about running no longer shows (with this patch). That arrow pair still shows though for the CPU view.
Minor: there is a typo in the commit message; "as it (is) being".

The CPU Usage doesn't load gradually, unless it is set to be loaded on the Overview chart. After the trace is loaded and displayed on the Overview, the data is cached, so opening the CPU Usage shows the data right away, without the delay it takes to load it.
With a very big trace like the "teams" one, one could open the CPU Usage chart right after opening the trace, before the data is completely loaded. Still the CPU Usage chart won't load gradually, this time because of what I believe to be a limitation with ChartJS, that will render one chart at a time.
So, the fact that the CPU Usage chart doesn't open gradually is not a bug.
But the Overview chart, if first configured to display CPU Usage, should load gradually like in the video posted above.
Good catch! Rotating arrows added back in.
Typo fixed. Thanks.

The CPU Usage doesn't load gradually, unless it is set to be loaded on the Overview chart. After the trace is loaded and displayed on the Overview, the data is cached, so opening the CPU Usage shows the data right away, without the delay it takes to load it.

I was mislead by my reading of the commit message part that says "and the timegraph chart". Maybe mention Overview in its title, and clarify it too in that sentence (that says "and the timegraph chart")?

With a very big trace like the "teams" one, one could open the CPU Usage chart right after opening the trace, before the data is completely loaded. Still the CPU Usage chart won't load gradually, this time because of what I believe to be a limitation with ChartJS, that will render one chart at a time.

IIUC, Overview only loads gradually, no other view, so is this issue about Overview, or another view? If applicable, maybe clarify this in the commit message, too.

So, the fact that the CPU Usage chart doesn't open gradually is not a bug.

Issue #816 however doesn't limit its scope to Overview only, AFAIK.

But the Overview chart, if first configured to display CPU Usage, should load gradually like in the video posted above.
2. Good catch! Rotating arrows added back in.

Ack, this all works for me. Thanks.

Typo fixed. Thanks.

I still see that typo up there.

Thanks. Commit message has a line exceeding the 72-chars max length limit, the one that had that typo fixed in it. -Minor.

Optional comment to potentially apply, above. And at this stage, I think @MatthewKhouzam wanted to co-review, before merge.

It was failing for very large traces.
I added a throttle to the updateXY() function that avoids too close apart repeated calls to the fetchXY end point. Now calls are done in 3 seconds intervals.

I suggest to update the method waitAnalysisCompletion in abstract-tree-output-component.tsx as follows:
    protected async waitAnalysisCompletion(): Promise<void> {
        let outputStatus = this.state.outputStatus;
        let factor = 1.0;
        const maxFactor = 10;
        while (this.state && outputStatus === ResponseStatus.RUNNING) {
            outputStatus = await this.fetchTree();
            const timeout = 500 * factor;
            await new Promise(resolve => setTimeout(resolve, timeout));
            factor = factor > maxFactor ? factor: factor + 1;
            // alternative: factor = factor > maxFactor ? factor = 1.0 : factor + 1;
        }
    }

With this we increase the time between queries and avoid requesting data too often. We can play with the maxFactor value and/or use the alternative code in comment.
Then you can request XY data after each fetchTree()

This is indeed good to remove the error for over calling the backend, but the update of the chart nearly stops after a few seconds.
I find the recursiveFetch() a little better at showing consistent progress, and it removes the need to empirically find a value for maxFactor.
I suggest keeping both the new waitAnalysisCompletion and the recursiveFetch methods.

I suggest to update the method waitAnalysisCompletion in abstract-tree-output-component.tsx as follows:
    protected async waitAnalysisCompletion(): Promise<void> {
        let outputStatus = this.state.outputStatus;
        let factor = 1.0;
        const maxFactor = 10;
        while (this.state && outputStatus === ResponseStatus.RUNNING) {
            outputStatus = await this.fetchTree();
            const timeout = 500 * factor;
            await new Promise(resolve => setTimeout(resolve, timeout));
            factor = factor > maxFactor ? factor: factor + 1;
            // alternative: factor = factor > maxFactor ? factor = 1.0 : factor + 1;
        }
    }

With this we increase the time between queries and avoid requesting data too often. We can play with the maxFactor value and/or use the alternative code in comment.
Then you can request XY data after each fetchTree()

This is indeed good to remove the error for over calling the backend, but the update of the chart nearly stops after a few seconds.
I find the recursiveFetch() a little better at showing consistent progress, and it removes the need to empirically find a value for maxFactor.
I suggest keeping both the new waitAnalysisCompletion and the recursiveFetch methods.

The point of the change in waitAnalysisCompletion was to be able to fetch the xy data after it fetch data returns and have better control when and how often the backend is queried during analysis execution. I'm not really for having another another independent while-loop with recursiveFetch.

When I run the latest version the spinner never goes away, even if analysis is finished. Please fix it.
Secondly, please rebase to latest in master before re-submitting it.
I'll continue reviewing it after these updates.
Thanks

Spinner bug fixed, and PR rebased.


Build(deps-dev): Bump eslint-import-resolver-typescript from 3.4.0 to 3.4.1 (#3872)

Pull request opened by the merge tool on behalf of #3872

Merged in 7fd8a1b86879976e6edb94edb437f7d1879bf405


Allow empty attributes by default for Browser#submit and Driver#submit

Not sure if default value for attributes in #submit wasn't added intentionally, but adding it seems to improve the API

Pretty sure this was intentional since they're not really part of the public API and submitting a form without its parameters doesn't really make sense.

Got it! That makes sense. My use case was page.driver.submit :delete, '/sign-out', {} which got me wondering...


No Lens distortion

I've successfully added this plugin onto my project. The VR seems to only be partially working though, specifically there is a left and right screen, but no lens distortion. This is the case from running the project in the editor and as after packaging. Do you have any advice? I'm running UE 4.10.

I'm experiencing the same problem. I'm using UE 4.10.4 and testing on Nexus 5.
This is happening when I have "Use mobile HDR" un-checked.
If it's enabled then game crashes right after startup.

Hi risoms,
MobileHDR must be checked for lens distortion to occur as stated in the README.

Hi Trojanonator,
what does the log/callstack say ?

Mobile HDR is enabled for me as well. I'm experiencing no crashing though.
On Thu, Feb 25, 2016 at 5:43 AM, nkindt<EMAIL_ADDRESS>wrote:

Hi Trojanonator,
what does the log/callstack say ?
—
Reply to this email directly or view it on GitHub
https://github.com/NivalVR/UE4Cardboard/issues/4#issuecomment-188747546.

Also is the lens distortion supposed to work, as shown on the github page,
in the editor?
On Thu, Feb 25, 2016 at 8:37 AM, Semeon Risom<EMAIL_ADDRESS>wrote:

Mobile HDR is enabled for me as well. I'm experiencing no crashing though.
On Thu, Feb 25, 2016 at 5:43 AM, nkindt<EMAIL_ADDRESS>wrote:

Hi Trojanonator,
what does the log/callstack say ?
—
Reply to this email directly or view it on GitHub
https://github.com/NivalVR/UE4Cardboard/issues/4#issuecomment-188747546
.

Lens distortion doesn't work in the editor. The plugin system doesn't recognize lens distortion for some reasons within the editor but that is a problem on the Epic side and not something we could fix. The screenshot is taken from a Nexus5 via a profiling tool so make sure you to check this on an Android device.

Does the lens distortion work on a packaged game running in windows?

Semeon

On Feb 25, 2016, at 09:31, nkindt<EMAIL_ADDRESS>wrote:
Lens distortion doesn't work in the editor. The plugin system doesn't recognize lens distortion for some reasons within the editor but that is a problem on the Epic side and not something we could fix. The screenshot is taken from a Nexus5 via a profiling tool so make sure you to check this on an Android device.
—
Reply to this email directly or view it on GitHub.

no it doesnt work in windows

I see. Do you have any advice on how to utilize the same lens distortion shown on android devices, to display on a windows pc?
The reason I ask is because I'm hoping to develop on iOS and I want to run my project via server on the pc. I'm hoping to have as much processing work done on the pc.
In any rate thank you for your time!

Semeon

On Feb 26, 2016, at 03:43, Trojanonator<EMAIL_ADDRESS>wrote:
no it doesnt work in windows
—
Reply to this email directly or view it on GitHub.

The thing is that we use the SimpleHMD plugin developed by Epic but add additional things in there. Therefore this is a problem how Epic handles the device recognition internally and apparently they simply didn't add that feature to be available in the editor or Windows/Mac builds. Only reasonable solution would be to wait until this will be addressed by Epic (maybe 4.11.x code has this fixed already).

Ah. Thank you both for the help!


buttonView on ios does not work?

On ios is showing default blue button view , but on android this prop is working correctly. How can i change button view on ios ?

anyone?)))

buttonView was only implemented for android to date.
see #91.
if you want to customize iOS for now just use the mock button
Or maybe submit a PR if you want to help out

this is a duplicate, so will close


[ROCm] Enable ROCm support for "BroadcastTo" op

This PR enables ROCm support for "BroadcastTo" op.

Not too familiar with ROCm, but if this PR does not impact CPU/CUDA build (I think it doe not impact) then it looks good to me.


double-dash handling does not support wrapper scripts.

There is no wayto terminate processing of a click.Argument with -- (double-dash).  In the previous issue I raised #2596 which was closed without resolution, I was instructed to use click.Argument to handle my use case.  This might have worked except for the fact that click strips -- from the arguments such that its impossible to determine where the "extra" arguments begin.  There are a large number of reports [1] on this issue, enough such that I think it would be worthwhile to add better support to terminate argument processing when a -- is encountered.  In the interim, I have to resort to this clever suggestion but I still think its best if click handled this without resorting to hacks.
import click
import sys

@click.command(context_settings=dict(
    # these options have no impact on this behavior
    ignore_unknown_options=True,
    allow_interspersed_args=True,
))
@click.argument('paths', nargs=-1, type=click.Path())
@click.pass_context
def cli(ctx, paths):
    print('Paths:', paths)

if __name__ == "__main__":
    cli()

$ python clickdemo.py file1.txt file2.txt -- extra1 extra2
Paths: ('file1.txt', 'file2.txt', 'extra1', 'extra2')

The expected result would be either with the double dash or excluding it and all the following arguments.  The current behavior is very unhelpful because should I want to slice off the extra args manually, I can't because there is no way to find the position of the -- double-dash.
Paths: ('file1.txt', 'file2.txt', '--', 'extra1', 'extra2')

OR
Paths: ('file1.txt', 'file2.txt')

Environment:

Python version: 3.11.9
Click version: 8.1.7

[1.] Other Issues referencing this functionality

https://github.com/pallets/click/issues/619
https://github.com/pallets/click/issues/1340
https://github.com/pallets/click/discussions/2596
https://github.com/pallets/click/issues/2637

-- is not intended as a separator to identify different arguments. Its only purpose is to turn off option parsing and treat tokens starting with - as arguments no matter what. If you want your own -- token to identify different sets of arguments, you'd type -- -- value value, and the second -- would be treated as an argument token in the resulting list.

According to posix guidelines, use of -- to disable option parsing is exactly what click does.  However, I would like to know whether click should better support creation of wrapper scripts.  What I am trying to do is have click process some arguments then optionally allow the user to provide additional arguments to pass to a wrapped utility (in this case pytest).
Example
my_pytest_wrapper dir1 dir2 dir2 -- --other --args --to --pass --to --pytest

There appears to be no way to support this behavior in click without pre-processing arguments and manually interacting with sys.args.  I am unsure how many others would find such a feature useful but I at least wanted to be clear about what I'm trying to achieve and see if there is a better way to accomplish this using the existing functionality of the library.

There is no way to unambiguously have two separate nargs=-1 arguments, no. Again, the -- is not an argument separator, you're getting thrown off by that since it does visually look like one. What you're asking for is "I want to parse "a b c d e" as [a, b] [c, d, e], where both lists can be arbitrary length, which is not possible. You need to rethink your argument design, for example by using a token to indicate where your dir list ends and argument list begins.


defaultProps rule to be deprecated on function components

defaultProps on function components is getting deprecated by React (see: https://github.com/facebook/react/pull/16210)
For this rule to follow suit, it should only be triggered when missing from class components.
The official recommendation in future versions of React is to use ES6 default values for function components.

That won't change by default; there can be an option to ignore function components, however.

Are you saying there's no way we could use object deconstruction assignment when requiring defaultProps?

Is there a way to check the deconstructed values for default props?

@KevinGhadyani-minted I'm not sure what you're asking.

The change isn't to remove defaultProps from function components, but to use the official ES6 standard for defaulting props using object deconstruction and default assignment.
Where we once had:
const TestComponent.defaultProps = {
  size: 'medium',
  type: 'primary',
}

We now have:
const TestComponent = ({
  size = 'medium',
  type = 'primary',
}) => (
  // ...
)

So the goal isn't to remove defaultProps, but change how they're defined on function components.
I would expect the defaultProps rules to function the same regardless of if I use defaultProps or object deconstruction and default assignment.

That's something that should be configurable via an option, as I said above.

I think I'm confused then. In your comment, you said there can be an option to ignore it for function components.
To me, this means there's development that would occur to disable it for function components, but this development has not occurred. It doesn't say there'd be an alternative for getting it to identify ES2015 default assignment instead.

Yes, it means someone would have to do the development work to add an option.
It makes sense to me to modify require-default-props so that the default is "defaultProps" for everything, but that there's an option for function components to instead require "default arguments", or, to ignore function components.

@ljharb, I'm considering working on the addition you suggested above, is there a good place to start beyond looking at the current rule implementation?

@aaronmccall That, and its tests, are pretty much it :-)

if you are using a state ,then use the default values like below,
const BlogPostForm=({onSubmit,initialValues=()=>{initialValues.title='',initialValues.content=''}})=>{      //default values set in a function
const [title,setTitle]=useState(initialValues.title)
const [content,setContent]=useState(initialValues.content)

Can we also have a way to enforce that function components can't have defaultProps?

@chbdetta that's included in https://github.com/yannickcr/eslint-plugin-react/issues/2396#issuecomment-539688853

My thoughts:

Using defaultProps is fine when using JS as it can be used for checks
Using destructured defaults is superior when using typescript, since typescript doesn’t need those checks and by using destructured defaults, the accepted prop types don’t differ from the object the function actually gets passed.

To demonstrate: Who wants to do this dance for every component? https://stackoverflow.com/a/69449759/247482
import * as React from "react";

interface IMyComponentRequiredProps {
  title: string;
}
interface IMyComponentOptionalProps {
  color: string;
  fontSize: number;
}
interface IMyComponentProps
  extends IMyComponentRequiredProps,
    IMyComponentOptionalProps {}

const defaultProps: IMyComponentOptionalProps = {
  color: "red",
  fontSize: 40,
};

const MyComponent = ({ title, color, fontSize }: IMyComponentProps) => {
  return
{title}
;
};

MyComponent.defaultProps = defaultProps;

export default MyComponent;

The same with defaults:
import * as React from "react";

interface IMyComponentProps {
  title: string;
  color?: string;
  fontSize?: number;
}

const MyComponent = ({ title, color = "red", fontSize = 40 }: IMyComponentProps) => {
  return
{title}
;
};

export default MyComponent;

My solution is therefore:
eslintrc.yaml
rules:
  react/require-default-props:
  - error
  - forbidDefaultForRequired
overrides:
- files: ['*.ts', '*.tsx']
  rules:
    react/require-default-props: off # use default arguments in typescript

Someone who wants maximal correctness would want to do that dance.

The second variant is no less correct, it just doesn’t give some of the types names.
Regarding our comments being hidden: Is this not the right place for this discussion? Whatever is the case, I very much think that my eslintrc.yaml might be helpful to people so in hopes this comment won’t be hidden without explanation I’ll reproduce it here:
rules:
  react/require-default-props:
  - error
  - forbidDefaultForRequired
overrides:
- files: ['*.ts', '*.tsx']
  rules:
    react/require-default-props: off # use default arguments in typescript

@flying-sheep discussion about just disabling the rule, even with overrides, won’t likely help anyone; people already know they can do that.
Either way, defaultProps should absolutely be used in TS still, and the type info does not contain the same information - because 100% of it is stripped out at runtime, which is when the defaultProps information can be needed.

@flying-sheep discussion about just disabling the rule, even with overrides, won’t likely help anyone; people already know they can do that.
Either way, defaultProps should absolutely be used in TS still, and the type info does not contain the same information - because 100% of it is stripped out at runtime, which is when the defaultProps information can be needed.

Would that very depending on the compilation target? I would expect default values assigned in ES6 to still work at runtime (be that built by TS or not), right?

@amypellegrini they work, but are not introspectable, so at runtime tooling can’t read information about what’s defaulted except with .defaultProps.

Why treat components in a special way? If you use JS, your code base could benefit from runtime type checking for all kinds of functions, not just components.
Once you have fully migrated a code base to  TypeScript, all types are proven correct at compile time and runtime checking isn’t necessary.

all types are proven correct at compile time and runtime checking isn’t necessary.

This is objectively false, since every system includes runtime user data (from the network, filesystem, user interaction, etc), as well as a majority of third-party code that was never typechecked, and this false belief is actually the worst damage caused by the use of a type system.

Even if TS was a sound type system - which it is not - it would NEVER be safe to omit runtime checks or to believe that types are "proven" correct. TS, for example, thinks that this JS snippet which has thrown an exception since 2009 - Object.create(null).toString() - is perfectly type-safe, so it's incredibly easy to disprove your claim.

Well, seems like none of my systems ever put user data through edge cases like the one you pointed out, but point taken!

@flying-sheep In your solution I would miss a linting rule to make sure the destructured defaults are really in place.

No need, the type system takes over. E.g. if I have this:
// required prop “x”
interface CompAProps { x: string }
const CompA = ({ x }: CompAProps) => <>{x}</>

// optional prop “y”
interface CompBProps { y?: string }
const CompB = ({ y }: CompBProps) => <CompA x={y} />

TypeScript will complain that <CompA x={x} /> is invalid as the type of y is string | undefined and not string.
I can then choose to fix this however I want, e.g. like this:
const CompB = ({ y = 'some default' }: CompBProps) => <CompA x={y} />

If this gets depreacted, is there still a way to set the defaultProps globally for example the react-native <Text> element?

@uloco im not familiar with what you’re describing, but either way, that’s a question to ask react native, and only if concrete plans to depreciate it ever materialize.

Any way to disable the error that react throws in development about this?

#2396 (comment) is the plan of record here.

Does anyone have an idea whether this improvement is available now?
Thanks in Advance!

@pavinduLakshan at the top, it says "fixed by #3249", and if you go there, you can see my comment https://github.com/jsx-eslint/eslint-plugin-react/pull/3249#issuecomment-1130645309 which says that it's in v7.30.0.

@pavinduLakshan at the top, it says "fixed by #3249", and if you go there, you can see my comment #3249 (comment) which says that it's in v7.30.0.

Thanks. missed it.


KeyError: 'Time Series (Daily)'

This seems to be an issue with GBTC's data from the API, and possibly an issue with AV itself. Call was working just fine a few days ago and had me scratching my head until I tried some other calls.
ts.get_daily("GBTC")
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/home/oberyn/.local/share/virtualenvs/prophet-ssuQ7s-c/lib/python3.6/site-packages/alpha_vantage/alphavantage.py", line 164, in _format_wrapper
    data = call_response[data_key]
KeyError: 'Time Series (Daily)'

Other get daily calls (GOOG, LC) are working just fine, and get_weekly("GBTC") works as well.
Not sure best way to pull the actual API response from the debugger. Let me know how you want me to proceed with this.

Ok, seems that call_response: <class 'dict'>" {}
Pretty sure that nails it down to the API itself. I've added a ValueError for this case and submitted PR.
https://github.com/RomelTorres/alpha_vantage/pull/155

get_weekly is working for you for 'GBTC'? I tried both on the wrapper, and by running the whole URL itself.
https://www.alphavantage.co/query?function=TIME_SERIES_WEEKLY&symbol=GBTC&apikey=<ENTER_KEY_HERE>
Am I punching something in wrong?

It's not now. Was when I submitted this issue. But at least having the ValueError tells me where it's at.

Agreed.


unlock too early, make other routine get an "unknown series" error

s, created := a.head.getOrCreate(lset.Hash(), lset) in (a *headAppender) Add(lset labels.Labels, t int64, v float64) gives a not-nil s, but s := a.head.series.getByID(ref) in addfast says s is nil and gives an "unknown series" error

Thanks! Are you running into this often? This should be a rare scenario, but I might have totally miscalculated this.
While the fix is generally right, I think it can lead to a deadlock. Currently gc() is the only thing actually locking stripes for ID and hash and it is never executed concurrently.
However, if another goroutine starts locking both, they might try to lock the same two stripes but in different order and consequentially block each other.
So to fix this, we probably need to think of some general change to how we are handling this.

It might well be we just want to "fail silentely" if the series is no longer there since it generally means it just got GCd because it didn't have data anymore anyway.

Yes, you are right, it can really lead to a deadlock!!!
But if there are many goroutine call add, "unknown series" errors occur often!!!

Yes, you are right, it can really lead to a deadlock!!!
But if there are many goroutines call add, "unknown series" errors occur often!!!
Do you think the way of locks1 [stripeSize]stripeLock for series and locks2 [stripeSize]stripeLock for hashes is an appropriate solution? And two locks give a better performance.

I edit the code again, you can review it


Fake install option

Description
brew install --fake D registers the installation of D without actually performing anything.
Motivation
Suppose package P depends on packages D1 D2 D3 ..., and the user hopes to use their own D1 rather than that from Homebrew, they could ask Homebrew to believe that D1 was installed.
Relevance
Many packages have very common and customizable dependencies e.g. Emacs, Python. Some users might prefer using the native Python on macOS; some have already installed Emacs via Cask.
Alternatives
The user could use brew install D2 D3 ...; brew install --ignore-dependencies P, but that could be as verbose as P's dependency list.

Homebrew (deliberately) doesn't support using Homebrew-packaged dependencies from outside Homebrew, sorry.

@liyishuai In that case we will throw various warnings/errors, though, and be able to detect that if you file other issues.


Cannot disable -c for slow-tiling

I ran the show-tiling without any option but still get a negative start position. From the mummer 3 manual, it says this only happens when using with -c. Is there a way to specify the reference sequence is linear? Thanks.

I have the same problem, did you solve it?


Support this module on Windows

Thank you for the PR I just need testing and verification on my end for windows. That's the only delay

Closing because other commits were inadvertently added to branch. Will re-open PR with correct commit only.


Enrich logs with kubernetes metadata

/kind feature
Environment:

Kubernetes version (use kubectl version): 1.10
Cloud provider or hardware configuration: CDK on-prem
OS (e.g. from /etc/os-release): Ubuntu 16.04

CDK deploys Graylog as a central logging instance. The default filebeat configuration adds nothing essential to event logs.
While one can filter for a particular pod using the (IMO ugly) query type:kube\-logs AND file:\/var\/log\/containers\/mypod*, it would be much better if filebeat would add kubernetes metadata into separate fields. Filebeat seems to have this capability already, see: https://www.elastic.co/guide/en/beats/filebeat/master/add-kubernetes-metadata.html
This would enrich the events in graylog with fields such as:

Podname
Namespace
Labels

@lopf looks like add_kubernetes_metadata became available with filebeat 6.x.  The current elastic charms are set to 5.x, so i think the first step is to get that stack upgraded and make sure the 5.x data migrates well to 6.x.


Hide "packages" on the right side if not currently used

I think it is great to hide features that are not used, they can always be brought back if they are needed

While you can manually change this by clicking the "gear" icon on repos you control, I agree it should just omit empty sections.

@abbycabs done how/when? I just enabled the packages tab on https://github.com/ljharb/qs, and it's still showing up despite there being no packages published.

I manually turned it off for this repo like Eddie suggested

ahhh i misunderstood the issue then :-) i got excited thinking you were going to auto-hide those sections everywhere when they were empty

Ah, that's a great feature request for github.com/community


Fonts not working due to quotation marks in some email clients

In some email clients, the quotation marks around "Helvetica" and "Arial" in the following code seem to interfere, resulting in the ugly default font.
body, table.body, h1, h2, h3, h4, h5, h6, p, td {
  color: #222222;
  font-family: "Helvetica", "Arial", sans-serif;
  font-weight: normal;
  padding:0;
  margin: 0;
  text-align: left;
  line-height: 1.3;
}

Removing the quotation marks seems to do the trick.

Looks like this has been addressed! We're still accepting PRs for v1, however we recommend using the most recent F4E2 code.
Thanks!


hyperion not work with more than 254 leds

When I put 254 leds in config file, everything is working fine, and I see startup effect.
With 255 or more leds in config file, leds are not working, also there is no error messages from hyperiond.
config file with 254 leds.

What are you using to receive the data ?

wifi udp receiver based on esp8266

with which sketch?

Last I saw, the esp8266 doesn't do fragmented packet reassembly which limits this simple raw protocol (==0) to about 450 leds.
https://github.com/penfold42/stuff/blob/master/ESP-udp-neo.ino Works fine for <450 leds
Protocol 1 and 2 were my early attempts at chunking the updates - I can't remember which worked. My sketch above implements one of these.
Protocol 3 is probably what you want if you can find the sketch that implements tpm2net.

It was a issue on receiver side now, 32x8 led panel is running wonderful.
@tpmodding
I didn't like sketches, is pure C implementation and is running under freertos.


Integrate Event list into User model and implement persistent storage

Integrate Events into the User Model and implemented persistent storage as well

Closes #90
Closes #120

Closes #35
Closes #44


Update regex for getting port

Since the base build is broken, I merged this and fix the errors in another PR @sbansal7
THANK YOU

@sbansal7 HERE YOU ARE <3