sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: Story stuck/slow using specific configuration
Labels: bug,needs triage

**Describe the bug**

It's difficult to articulate the problem, as it involves a mix of things to manifest itself, which is slowness of loading a story (long seconds), or a complete browser hang, where the tab must be forced to a close.


https://user-images.githubusercontent.com/845031/161568851-88604b3e-0794-4f5e-bd0b-f12b33e53008.mp4


For some reason, this **only** happens for stories which are wrapped with:

```js
const storyWrap = storyFn => (_, storyArgs) => storyFn(storyArgs)

storiesOf(...).add('Render slow', storyWrap(() => ...
```

**And** only with lots of JSX in some props property which is spread on the story's component:

```js
storiesOf('issue', module).add('Render slow', storyWrap(() => {
	const props = {
        data: [...Array(100)].fill(<></>)  // filling an array with JSX syntax manifests the problem
    }
	
	return <Foo {...props}>slow</Foo>
}))
```

I've narrowed it down to `@storybook/addon-essentials`, which is a common addon collection, and within it
to the `docs` & `controls` addons. When both are disabled, this issue does not occur:

**main.js**
```js
module.exports = {
    "stories": [
		"../stories/**/*.stories.mdx",
		"../stories/**/*.stories.@(js|jsx|ts|tsx)"
    ],
    "addons": [
		"@storybook/addon-links",
		"@storybook/addon-interactions",
		{
			name: '@storybook/addon-essentials',
			options: {
				docs: true,     // set to false to eliminate the issue
				controls: true, // set to false to eliminate the issue
				actions: true,
				backgrounds: true,
				viewport: true,
			}
		}
    ],
    "framework": "@storybook/react"
}
```




**To Reproduce**
👉 [Please clone my (very simplified) repo](https://github.com/yairEO/sb-issue-performance-essentials-addon)

**System**
```
System:
  OS: Windows 10 10.0.19042
  CPU: (8) x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
  
Binaries:
  Node: 14.19.1 - ~\AppData\Local\Volta\tools\image\node\14.19.1\node.EXE
  Yarn: 3.2.0 - ~\AppData\Local\Volta\tools\image\yarn\1.22.18\bin\yarn.CMD
  npm: 8.1.2 - ~\AppData\Local\Volta\tools\image\npm\8.1.2\bin\npm.CMD

Browsers:
  Edge: Spartan (44.19041.1266.0), Chromium (98.0.1108.43)

npmPackages:
  @storybook/addon-actions: ^6.5.0-alpha.55 => 6.5.0-alpha.55
  @storybook/addon-docs: ^6.5.0-alpha.55 => 6.5.0-alpha.55
  @storybook/addon-essentials: ^6.5.0-alpha.55 => 6.5.0-alpha.55
  @storybook/addon-interactions: ^6.5.0-alpha.55 => 6.5.0-alpha.55
  @storybook/addon-links: ^6.5.0-alpha.55 => 6.5.0-alpha.55
  @storybook/react: ^6.5.0-alpha.55 => 6.5.0-alpha.55
  @storybook/testing-library: ^0.0.9 => 0.0.9
```

**Additional context**
Updated Storybook (and some other packages) for a large components repo (of my workplace),
and then I saw some stories caused the browser to hang completely. Took ~10 hours to narrow it down.

We have hundreds of stories wrapped with this (`storyWrap`) wrapper, so it's not that simple to make
an overall change, and also, it is very strange those mentioned addons are involved in the slowness.
Repository: kubernetes
Issue: Memleak in client-go transport.tlsCache
Labels: kind/bug,sig/api-machinery,lifecycle/frozen,triage/accepted

### What happened?

We're using a long-running process that connects to thousands of kubernetes cluster via client-go (not all simultaneously).
We noticed that the more kubernetes clusters we connect to and the longer the process runs, the more memory our process consumes over time.
An analysis with pprof confirmed that it looks like a memory leak in transport.tlsCache.

### What did you expect to happen?

Memory to be freed of clients that aren't used anymore, especially when the client object is not referenced anymore.

### How can we reproduce it (as minimally and precisely as possible)?

Connect to different k8s clusters with cert-base auth in a long-running process and watch memory usage grow.

### Anything else we need to know?

Reason for the leak:
We're using `kubernetes.NewForConfig` which eventually calls `transport.New(config)`
That transport calls `tlsCache.get`: https://github.com/kubernetes/kubernetes/blob/3b5044fefd5a9a192b379236fac11ac8c41a7017/staging/src/k8s.io/client-go/transport/transport.go#L50

`tlsCache` is a non-exported global that implements a http transport cache. The `get` also stores the given transport in the cache if it's not there, yet.
However there are no mechanisms that would remove something from the cache. Neither explicitly, nor through expiration or anything.
The cache key includes k8s cert data which means every cluster we connect to will create a new cache entry that will then stay there indefinitely.

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
```

</details>


### Cloud provider

all

### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: create-react-app
Issue: `npm init react-app` ignores `--template` directive
Labels: needs triage,issue: bug report

### The commands `npx create-react-app` and `npm init react-app` behave differently.

Using `npx create-react-app my-app --template typescript` **correctly** creates a React app with the typescript template.

```
$ npx create-react-app my-app --template typescript
Creating a new React app in /home/user/my-app.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template-typescript...
...
```

Using `npm init react-app my-app --template typescript` (as documented at https://create-react-app.dev/docs/getting-started/#npm) **does not** work correctly. The `--template` directive is silently ignored:

```
$ npm init react-app my-app --template typescript
Creating a new React app in /home/user/my-app.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...
...
```


### Environment

```
Environment Info:

  current version of create-react-app: 5.0.0
  running from /home/royston/.npm/_npx/c67e74de0542c87c/node_modules/create-react-app

  System:
    OS: Linux 5.10 Ubuntu 20.04.4 LTS (Focal Fossa)
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
  Binaries:
    Node: 16.14.2 - ~/.volta/tools/image/node/16.14.2/bin/node
    Yarn: Not Found
    npm: 8.5.0 - ~/.volta/tools/image/node/16.14.2/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    react: Not Found
    react-dom: Not Found
    react-scripts: Not Found
  npmGlobalPackages:
    create-react-app: Not Found
```
Repository: flutter
Issue: [packages] pigeon isn't formatting dart code
Labels: c: new feature,package,team-ecosystem,p: pigeon,P3,triaged-ecosystem

## Explanation

pigeon doesn't generate formatted dart code. That means that you have to run an additional formatting step. My understanding with code generation is it's best practices (and in many cases absolutely required) to format with `dartfmt` after generation such that the output is deterministic even if format commands are run over the generated code afterwards.

## Environment

Pigeon version: 
`pigeon: ^2.0.3`

Flutter version:
```
Flutter 2.10.4 • channel stable • https://github.com/flutter/flutter.git
Framework • revision c860cba910 (10 days ago) • 2022-03-25 00:23:12 -0500
Engine • revision 57d3bac3dd
Tools • Dart 2.16.2 • DevTools 2.9.2
```


## Repro

`pubspec.yaml`
```yaml
name: pigeon_formatting
description: A new Flutter project.
publish_to: "none"
version: 1.0.0+1

environment:
  sdk: ">=2.16.2 <3.0.0"

dependencies:
  flutter:
    sdk: flutter

  cupertino_icons: ^1.0.2

dev_dependencies:
  flutter_test:
    sdk: flutter

  flutter_lints: ^1.0.0
  pigeon: ^2.0.3

flutter:
  uses-material-design: true
```

`pigeons.dart`
```dart
import 'package:pigeon/pigeon.dart';

class Value {
  int? number;
}

@HostApi()
abstract class Api2Host {
  @async
  Value calculate(Value value);
}
```

### Steps

1. run `flutter pub run pigeon --input pigeons.dart --dart_out pigeons.g.dart`
2. stage all generated code
3. run `flutter format pigeons.g.dart`
4. git will show the diffs

Diffs are visible here: https://gist.github.com/lukepighetti/17f04f16083d6f42dfa740c5e273498f/revisions
Repository: storybook
Issue: webpack option is not documented
Labels: documentation

Webpack documentation does not mention the fact that you can add "webpack" and "webpackFinal" option. TBH, I am not totally sure what they exactly do. 

**To Reproduce**
Open documentation. Read. 

**System**
Please paste the results of `npx sb@next info` here.

**Additional context**
Add any other context about the problem here.
Repository: PowerToys
Issue: original windows snap/resize scroll
Labels: Idea-Enhancement,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

while having fancyzones on, I can still use default windows snap method to put a window to a side of 50% size of my screen, then able to choose another window to show side by side
however the slider from the default snap option is missing if I have fancyzones on: I cannot resize one of the windows' size while resizing the second window at the same time
feature gets back if I shut down powertoys..

### Scenario when this would be used?

despite using fancyzones to snap windows to the zones locations I still have to get a side by side windows setup with an option to resize both of them at the same time occasionally (having my email & a spreadsheet opened on a 21:9 monitor, resizing with slider according to the content I'm working with)

### Supporting information

_No response_
Repository: godot
Issue: Inspector doesn't show correct size of array of objects
Labels: bug,topic:editor

### Godot version

3.4.4.stable.mono

### System information

Windows 10

### Issue description

If you create an array with 1000000 items, the inspector shows the size 1000000 

But if you create an array with 1000000 items of a class, the inspector shows "nil"

When you print the 999999 item of this array, it's there... no fault.

### Steps to reproduce

added demo project

### Minimal reproduction project

[BugReport.zip](https://github.com/godotengine/godot/files/8412693/BugReport.zip)
Repository: pytorch
Issue: Improve wording in _store_based_barrier logging and identify ranks that have not joined
Labels: oncall: distributed,triaged,better-engineering

🚀 Feature
To better debug the stuck ranks that have not reached `_store_based_barrier()`. We can think about recording the ranks that have not called into the function and logging those.

Currently, while ranks are waiting for all workers to call into `_store_based_barrier`, they log
```
"Waiting in store based barrier to initialize process group for
rank: {}, key: {} (world_size={}, worker_count={}, timeout={})"
```

see: https://github.com/pytorch/pytorch/blob/cda3f586d0b1189c5c4175a503f99f374d1fcce2/torch/distributed/distributed_c10d.py#L220-L264

For one this might be misleading wording since `"for rank: {}"` might be interpreted that we are waiting for that rank (but the rank is actually the one logging this message). 

Second, it only provides information for the whole group count rather than the rank(s) we are waiting for. For something like a 10 node job with 8 gpus each, that is 80 workers, the log message simply lets you know the amount of workers (e.g. `(world_size=80, worker_count=75, timeout=300)`) that called into barrier, rather than pointing out the ranks that are missing. With currently logs you might be led to believe that (ranks 75-80) are missing, when it actually could have been earlier ranks 4, 23, 40 etc. that did not actually join.  You would have to look at the logs of each individual node to find out which ones did not add their key.


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: pytorch
Issue: [torch.distributed] Document bfloat16 support
Labels: oncall: distributed,module: docs

### 📚 The doc issue

torch.distributed and applications such as DDP can only support bfloat16 data type with NCCL process group when NCCL version is >= 2.10.3, as previously NCCL did not support this datatype. We should document this as such.

### Suggest a potential alternative/fix

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @brianjo @mruberry
Repository: pytorch
Issue: Storing LTC tensor shape information in jit::Value
Labels: oncall: jit

### 🚀 The feature, motivation and pitch

Currently, a `jit::Value` contained in a graph generated by the TorchScript LTC backend contains no tensor shapes; however, `lazy::Value` from each `lazy::Node` _does_ contain this information. It would be beneficial to propagate this data all the way through to JIT.

It looks like `jit::Value`s are generated [here](https://github.com/pytorch/pytorch/blob/5177f95d21063d6b868834fccb58ce71f3fef820/torch/csrc/jit/frontend/schema_matching.cpp#L632-L634) according to some predefined schema, which is only able to specify the generic type (i.e. `Tensor` in this case). 

The main problem with this is that there isn't an easy way to "plumb" the shape information from `lazy::Node` to this point, since there are several layers that separate the two (starting [here](https://github.com/pytorch/pytorch/blob/5177f95d21063d6b868834fccb58ce71f3fef820/torch/csrc/lazy/ts_backend/ts_node_lowering.cpp#L386-L407) at `LowerTSBuiltin`).

I'd like to avoid having to poke around the guts of JIT _too_ much if we can avoid it. A possible approach would be to intercept the `jit::Value` in `LowerTSBuiltin` _just_ before it returns and insert shape information there:
```cpp
TSOpVector LowerTSBuiltin(
    std::shared_ptr<torch::jit::GraphFunction> function, c10::Symbol sym,
    const std::vector<torch::jit::NamedValue>& arguments,
    const std::vector<torch::jit::NamedValue>& kwarguments) {
  auto builtin =
      std::make_shared<torch::jit::BuiltinFunction>(sym, at::nullopt);
  auto magic_method = std::make_shared<torch::jit::MagicMethod>("", builtin);
  auto ret = magic_method->call({}, *function, arguments, kwarguments, 0);
  auto sv = dynamic_cast<torch::jit::SimpleValue*>(ret.get());
  CHECK(sv);

  TSOpVector results;
  if (sv->getValue()->type()->kind() == c10::TypeKind::TupleType) {
    const auto tuple_call_result = sv->asTuple({}, *function);
    for (const auto& tuple_component : tuple_call_result) {
      auto tuple_component_sv =
          dynamic_cast<torch::jit::SimpleValue*>(tuple_component.get());
      results.push_back(tuple_component_sv->getValue());
    }
  } else {
    results.push_back(sv->getValue());
  }

  // Insert shape information
  for (jit::Value* value : results) {
    if (value->type()->kind() == c10::TypeKind::TensorType) {
        // TODO: Get real shape information in here
        value->setType(torch::jit::TensorType::create(
            c10::nullopt,
            c10::nullopt,
            c10::VaryingShape<int64_t>(std::vector<int64_t>({1, 2, 3})),
            c10::VaryingShape<int64_t>(std::vector<int64_t>({4, 5, 6})),
            c10::nullopt
        ));
    }
  }

  return results;
}
```

Note: We are actually using a modified version of the TS LTC backend, so if this isn't something that is needed in TS LTC we'll just make the changes over there.

@wconstab do you have any thoughts on this/how it should be approached? 

cc: @silvasean @antoniojkim @ke1337

### Alternatives

_No response_

### Additional context

_No response_
Repository: storybook
Issue: Support non-bubbling events with Actions Addon
Labels: feature request

**Is your feature request related to a problem? Please describe**

We have a web-component that fires and event named `cancel` following the API of the [native `dialog` element where `cancel` is not bubbling](https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/cancel_event).

If we try to use:

```js
actions: {
    handles: ['cancel']
}
```
The action is never caught because non-bubbling events will not bubble up the DOM and event listeners need to be registered directly on the target element. The Actions addon assumes all events that are observed are bubbling events and assumes the event target is `document`:

https://github.com/storybookjs/storybook/blob/d377613e4274f57f875a926afd3931427d548982/addons/actions/src/preview/withActions.ts#L51

The **documentation is misleading** as [it states that](https://storybook.js.org/docs/react/essentials/actions#action-event-handlers):

> This will bind a standard HTML event handler to the outermost HTML element rendered by your component

Where instead from the source it appears that the event listener is bound to `document`.

**Describe the solution you'd like**

I'd like to be able to listen for events that are not bubbling that are fired from my component. Some option ideas:

- One options is have a configurable root / target selector for each event that is configured with the Actions Addon. Maybe something like:

  ```js
  actions: {
    handles: [{
      name: 'cancel',
      rootSelector: 'my-element',
      eventTargetFilterSelector: null // potential name for the current selector configuration. Or it could continue to be part of name.
    }]
  }
  ```
- Another option is to change the target of the event listener to the expected event (seems like it might interfere with the current selector pattern).
- Another option might be to allow configuring the addEventListener mode to be capturing. Maybe as a per event setting:
  ```js
  actions: {
    handles: [{
      name: 'cancel',
      capture: true
    }]
  }
  ```

**Describe alternatives you've considered**

Couldn't find any workaround.

**Are you able to assist to bring the feature to reality?**

If there is a suggested API we may be able to help create a PR.

**Additional context**

N/A
Repository: pytorch
Issue: One of the backends for `lu_factor` fails on windows.
Labels: triaged,module: linear algebra

### 🐛 Describe the bug

See the skip added in https://github.com/pytorch/pytorch/pull/73878#discussion_r841416793

### Versions

master

cc @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
Repository: rust
Issue: rustdoc: Mark public items, instead of private items, with `--document-private-items`
Labels: T-rustdoc,C-enhancement,A-rustdoc-ui

Looking at the rustc API docs (doc.rust-lang.org/nightly/nightly-rustc), the result of #95024 still feels really noisy to me.

![image](https://user-images.githubusercontent.com/37223377/161451392-1aee96dc-a20d-4e13-9064-7472a9815db2.png)

I have two ideas for ways to improve it:

1. **Move the lock to the left "gutter"**, i.e. the left side of the name, but in a column to the left of all the names. This would make it look a bit less chaotic. Not sure how technically feasible this is, and it'd still have noise from the locks themselves.

2. **Instead of marking private items, mark public items.** This would only happen when `--document-private-items` is passed. Usually crates have a lot more private items than public ones – which is even more likely for the kinds of crates that people use `--document-private-items` on – in which case the markings would cause less noise.

   Also, my understanding is the original purpose of this PR was to make it easier to see which parts of the API are public. When all but a few items are marked, it's hard to find the unmarked items, whereas when just a few are marked, it's easier to find those marked items. So I think doing this would accomplish the goal even better.

   The only issue I can think of is figuring out what icon to use. IntelliJ seems to use an open lock: https://stackoverflow.com/questions/57427175/intellij-not-showing-private-or-public-icon-aka-visibility-icon-for-methods-aka

I think I'd prefer option 2. What do you think about it?

_Originally posted by @camelid in https://github.com/rust-lang/rust/issues/95024#issuecomment-1086963044_
Repository: kubernetes
Issue: Detect log-spam in tests
Labels: area/logging,sig/instrumentation,sig/testing,lifecycle/frozen,triage/accepted,wg/structured-logging

When adding log statements in Kubernetes it can sometimes be difficult to tell just how frequent a code path is. For example: https://github.com/kubernetes/kubernetes/pull/109181, or any of about 500 issues & PRs: https://github.com/kubernetes/kubernetes/issues?q=log+spam

I'd like to add infrastructure to all our test frameworks (~~unit,~~ integration & E2E) to detect log spam. Things that would be interesting to look at:
- ~~Total log volume - works best for unit tests; e2e & integration with variable run times are likely to have too much variance on total volume~~
- Logging rates (percentiles) - less dependent on test length, probably needs a way to separate out logging during cluster bring-up
- Repeated log lines - typically indicates a low-information or high-spam log

The reasons we should care about log spam:
1. It obscures informative log information
2. It can fill up disks and/or saturate log pipelines

/sig testing instrumentation
/area logging
Repository: rust
Issue: Panic in `thread::sleep()` on arm32 Debian 10
Labels: C-bug,T-libs,O-unix,A-thread

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

This issue reproduces consistently for multiple arm32 Debian 10 Buster devices (raspberry pi 2b). Running a docker container with ubuntu20.04 base image and calling `thread::sleep()` will result in the following panic:
```
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
left: `1`,
right: `4`', library/std/src/sys/unix/thread.rs:217:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
``` 

I tried this code (simplified):



```rust
const PROCESS_POLL_INTERVAL_SECS: Duration = Duration::from_secs(1);
thread::sleep(PROCESS_POLL_INTERVAL_SECS);
```

Full source code:
https://github.com/Azure/iotedge/blob/main/edge-hub/watchdog/src/child.rs#L103

I expected to see this happen: no panic, instead a proper sleep.

Instead, this happened: Attempting to sleep panicked.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

Will fill in the below information in a bit.

`rustc --version --verbose`:
```
rustc 1.58.1 (db9d1b20b 2022-01-20)
binary: rustc
commit-hash: db9d1b20bba1968c1ec1fc49616d4742c1725b4b
commit-date: 2022-01-20
host: x86_64-unknown-linux-gnu
release: 1.58.1
LLVM version: 13.0.0
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
<backtrace>
```

</p>
</details>