sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: WorldEnvironment's high-quality glow mode doesn't work as expected
Labels: bug,topic:rendering

### Godot version

3.4.rc (a05aefb74)

### System information

Fedora 34, GeForce GTX 1080 (NVIDIA 470.74)

### Issue description

The high-quality glow mode backported to `3.x` by https://github.com/godotengine/godot/pull/51491 doesn't work as expected in both GLES3 and GLES2.

### GLES3

#### Low quality

*Glow width depends on rotation, as expected.*

https://user-images.githubusercontent.com/180032/139950350-f4b84d57-6a72-46da-9a0e-450c4989d524.mp4

#### High quality

*Glow width depends on rotation, but it shouldn't in this mode.*

https://user-images.githubusercontent.com/180032/139950341-bf8fa56e-6bb9-4e66-84a9-515ad86ab675.mp4

### GLES2

#### Low quality

*Glow width depends on rotation, as expected.*

https://user-images.githubusercontent.com/180032/139950332-d392e5ca-7fe4-492f-9430-202c069b2d2e.mp4

#### High quality

*Glow width depends on rotation, but it shouldn't in this mode.*

https://user-images.githubusercontent.com/180032/139950328-5c88bc1f-66cc-4fd2-8679-28652999efc5.mp4

### Steps to reproduce

- Create a long and thin object with high emission value.
- Enable Glow in WorldEnvironment. Unzoom to make the object small in the viewport, and rotate the camera. Notice the glow width changing depending on camera rotation.
- Enable **Glow > High Quality** in WorldEnvironment. Unzoom to make the object small in the viewport, and rotate the camera. Notice the glow width still changing depending on camera rotation, even though it shouldn't when high-quality glow is used.

### Minimal reproduction project

[glow_orientation_issue.zip](https://github.com/godotengine/godot/files/3587352/glow_orientation_issue.zip) ([MRP by fracteed](https://github.com/godotengine/godot/issues/32030#issuecomment-529175410))
Repository: pytorch
Issue: Decorate tests with a "deadline"
Labels: module: ci,triaged,better-engineering

## 🚀 Feature
We should limit the runtime of every tests to a certain time, like 5min or something.

## Motivation

This would help save resources and help us pinpoint culprit tests when they time out, like the ones in https://github.com/pytorch/pytorch/issues/67448



cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: terminal
Issue: [DefApp] Conhostv1 activation fails from runbox when Default Terminal is set
Labels: Product-Conhost,Issue-Bug,Priority-2,Area-DefApp

1. Have Default Terminal set up
2. Set legacy conhost (ForceV2 registry key off / the setting in the prop sheet) for conhostv1 
3. Run `conhost cmd` from the runbox which should launch it

Expected: it launches
Actual: nothing happens

Bonus points.... `conhost cmd -ForceV1` doesn't seem to do what I want either
Repository: storybook
Issue: Create `prepareStoryExternal` for external use (ie. tests)
Labels: feature request,core

I'm not sure of the best name here, I am open to ideas!

### Context

- `@storybook/testing-react`, in 6.3, has it's own `composeStory` function which is similar to the internals of the 6.3 story store in that it takes a set of story, component and project annotations and puts them together into a "story" function that includes decorators + context.

- In 6.4, we have a `prepareStory` function that does almost the exact same thing, refactored out of the store.

### What needs to happen

The `prepareStory` function currently generates a `Story<TFramework, TArgs>` object which is the internal SB representation of a story. In particular:

 - A `Story` has an `unboundStoryFn` field, which is the story function, without a context bound yet.
 - A `Story` has an `initialArgs` field, which is the stories args before any user modification via controls
 - A `Story` also has a `applyLoaders` and a `playFunction` which I am not sure if `testing-react` currently considers?

For external purposes a user will want to call a bound version of `unboundStoryFn` -- bound with a `StoryContext`. Internally to get a `StoryContext` we call `store.getStoryContext(story)` which basically returns the `story` object with a couple of extra fields:

 - `args` -- the *current* value of the args for this story after user modification via controls. In the testing/external use-case this would always just be equal to `story.initialArgs`.
 - `globals` -- the current value of the Storybook's globals. I am not sure if `testing-react` currently passes globals, but the correct way to get the initial set is encoded in the `GlobalsStore.set()` function, this may need to be factored out.
 - `hooks` -- a hooks context, that allows SB hooks to be used. This is one-liner to create: `new HooksContext()`[1]

### Sketch of implementation

So the `prepareStoryExternal` function might look something like:

```js
function prepareStoryExternal(storyAnnotations, componentAnnotations, projectAnnotations) {
   const story = prepareStory(storyAnnotations, componentAnnotations, projectAnnotations);

  const context = {
    ...story,
    args: story.initialArgs,
    globals: getInitialGlobals(projectAnnotations), // <- this function isn't factored out yet
    hooks: new HooksContext(),
  }

  const boundStoryFn = (runtimeContext) => unboundStoryFn({ ...context, runtimeContext });
  return {
    ...boundStoryFn,
    ...story,
   };
}
```

[1] Keep in mind that for `useEffect` to work, the hooks context will monitor the addons channel for the `STORY_RENDERED` event. We would need to figure out how to either change that or mock the channel in tests. This may be out of scope for now.
Repository: puppeteer
Issue: The chromium binary is not available for arm64
Labels: feature,upstream,confirmed

### Bug description

In an ARM based Docker container (or ARM based Linux):

1. `npm install puppeteer` 

Error:
> The chromium binary is not available for arm64.

This is related to #6622 which wasn't really solved just worked around via Rosetta.

I'm trying to build an ARM based Docker Image that uses BackstopJS/puppeteer. Ref https://github.com/garris/BackstopJS/issues/1300

Are there any plans to build an arm64 version of `chromium`?


### Puppeteer version

10.0.0

### Node.js version

16.3.0

### npm version

7.15.1

### What operating system are you seeing the problem on?

Linux

### Relevant log output

_No response_
Repository: pytorch
Issue: `torch.utils.data.random_split` example broken in 1.10
Labels: needs reproduction,triaged,module: data

## 🐛 Bug

`random_split` example from [src](https://pytorch.org/docs/stable/_modules/torch/utils/data/dataset.html#random_split) doesn't seem to work correctly (doesn't actually split anything)

## To Reproduce
```
>>> import torch
>>> x, y = torch.utils.data.random_split(range(10), [3, 7], generator=torch.Generator().manual_seed(42))
>>> print(len(x))
10
>>> print(len(y))
10
```

## Expected behavior
```
>>> import torch
>>> x, y = torch.utils.data.random_split(range(10), [3, 7], generator=torch.Generator().manual_seed(42))
>>> print(len(x))
3
>>> print(len(y))
7
```

## Environment

PyTorch version: 1.10.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.10.2
Libc version: glibc-2.10

Python version: 3.7.6 (default, Jan  8 2020, 19:59:22)  [GCC 7.3.0] (64-bit runtime)
Python platform: Linux-4.15.0-156-generic-x86_64-with-debian-buster-sid
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: GeForce GTX 1080 Ti
GPU 1: GeForce GTX 1080 Ti

Nvidia driver version: 450.51.06
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.0.3
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.0.3
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.0.3
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.0.3
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.0.3
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.0.3
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.0.3
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.5
[pip3] torch==1.10.0
[pip3] torchvision==0.11.1
[conda] numpy                     1.18.4                   pypi_0    pypi

## Additional context

The same code produces the expected behavior in torch 1.9.1+cu102.


cc @VitalyFedyunin @ejguan @NivekT
Repository: pytorch
Issue: A `sieve` operation for separating values of a tensor into two tensors based on a condition.
Labels: triaged,enhancement,module: ux,module: viewing and reshaping

## 🚀 Feature
This is an operation that is almost the inverse of `where`. 
Let's call it `sieve`.
It takes as input a tensor `A` and a boolean tensor `B` of the same shape and a "fill" value `c`.
It returns two tensors `O1` and `O2` of the same shape as `A`.
`O1` is equal to `A` where `B` is True and is equal `c` where `B` is False.
`O2` is equal to `A` where `B` is False and is equal `c` where `B` is True.

For example, let's say you want to separate positive and non-positive elements of `A` into two tensors.:
``` pos, neg = torch.sieve(A, B=(X > 0), fill=0) ```

## Motivation
This can be made twice faster than current solutions.

## Pitch
This obviously can already be done in various ways in PyTorch currently.
But it can be theoretically be twice as fast when done in one operation.
That is because **ALL** current ways of achieving this have to go over `A` twice. 
Once to get `O1` and once to get `O2`. 
But we know if something does not go to `O1`, is has to go to `O2`.
Therefore, we can do this in one pass of `A`.

## Alternatives

For the example mentioned above, one current solution is to do.
```
neg = torch.minimum(X, 0)
pos = torch.maximum(X, 0)
```
Here, we are comparing each element of X with zero twice, but we don't have to.

## Context
I use this in a custom activation function. So having this operation means my activation functions will be 2x faster, and that makes my runs noticeably faster.

I'm willing to dedicate some time to this, if someone is willing to guide me, as I haven't written custom CPU or Kernel code.
Repository: flutter
Issue: [Web, engine] Decoding a semi-transparent image gives slightly incorrect results
Labels: engine,platform-web,a: images,e: web_html,P2,team-web,triaged-web

When decoding a bitmap image, the resulting pixels might be slightly off if any of the pixels are partially transparent, i.e. contain alpha between 1 ~ 254. This does not occur if all pixels have alpha of either 0 or 255.

This is observed on HTML renderer. I have not tested if it reproduces on canvaskit, but I suspect not.

Following is the testing code:
```dart
  test('Correctly encodes a transparent image', () async {
    // A 2x2 testing image with transparency.
    // Pixel order: Left to right, then top to bottom.
    // Byte order: 0xAABBGGRR (because uint8 is placed in little endian.)
    final Uint8List sourceImage = Uint8List.sublistView(Uint32List.fromList(
      <int>[ /* To be filled later */ ],
    ));
    final ImageDescriptor descriptor = ImageDescriptor.raw(
      await ImmutableBuffer.fromUint8List(sourceImage),
      width: 2,
      height: 2,
      pixelFormat: PixelFormat.rgba8888,
    );
    final Image encoded = (await (await descriptor.instantiateCodec()).getNextFrame()).image;
    final Uint8List actualPixels  = Uint8List.sublistView(
        (await encoded.toByteData(format: ImageByteFormat.rawStraightRgba))!);
    // expect(actualPixels, listEqual(actualPixels)); // Broken
  });
```

In the code above, `descriptor` contains a BMP representation of the source image, `encoded` is an `HtmlImage`, and `encoded.toByteData` decodes the data back into raw pixels. 

If any pixel is partially transparent, then all pixels might be slightly off, including the alpha channel:
```
// Byte order: 0xAABBGGRR
source: 0x030201FF, 0x0605FE04, 0x09FD0807, 0xFC0C0B0A
actual: 0x030000FF, 0x0600FF00, 0x09FF0000, 0xFC0C0B0A
```

In comparison, if all pixels have either 0 or 255 on alpha, the accurate pixels are decoded:
```
// Byte order: 0xAABBGGRR
source: 0xFF0201FF, 0xFF05FE04, 0xFFFD0807, 0x000C0B0A
actual: 0xFF0201FF, 0xFF05FE04, 0xFFFD0807, 0x00000000
```

Note that the fully transparent pixel is turned all 0, which is fine since it's transparent anyway.

The reason is unknown, but I suspect it's because `HtmlImage` decides image data using `canvas.drawImage`, which might blend semi-transparent image using a different algorithm that introduces rounding errors. Note that the deviation also depends on browser. Running on Firefox gives a different value from Chrome, neither correct.
Repository: rust
Issue: BTreeMap/Set don't have debug visualizers
Labels: A-debuginfo,C-enhancement,T-compiler,O-windows-msvc,WG-debugging

It would be nice if BTreeSet and BTreeMap had visualizers. These seem to be in `.natvis` files for other `std` collections, but the BTree structures seem to have been overlooked.

As it is now, debugging these structures is extremely unwieldy. See screenshot:
![screenshot](https://user-images.githubusercontent.com/119948/140010898-b22f52fd-13c1-4231-b19f-453c930d9b97.jpeg)

originally reported here https://internals.rust-lang.org/t/feature-request-debug-visualizer-for-btreemap-set/15543

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"GrumpyMetalGuy"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: pytorch
Issue: Remove logic for constructing symbolic shapes in Profiler
Labels: triaged,better-engineering,jit-backlog

## 🚀 Feature

Simplify Profiler by removing two pieces of logic in `profiling_record.cpp` responsible for grouping profiled tensor types by `frame_id` (i.e. an unique identifier of a particular instance of a function) and for merging groups into final symbolic shapes.

## Motivation

Profiler is an important component of ProfilingExecutor which is our default runtime to execute TorchScript'ed models.
Profiler is used in a number of scenarios. 
* For TS'ed models, the profiling information is used for fusion element-wise operations on both CPU and GPU
* Models running on a lazy device will also be utilizing PE and Profiler to collect profiling information for fusers.
* Profiler can be used to collect shapes, strides ahead of time and to also trace through the control flow in the original graphs.

**This particular item will allow us to simplify the implementation of Profiler which should make it easier to add new features and service in the future. It may also result in moderate gains, as the merging step will be combined with the profiling step.**

## Pitch

1. Remove `profiled_types_per_frame_` from `profiling_record.h`
2. In https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/runtime/profiling_record.cpp#L174-L204 use "profiled_type" attribute on `prim::profile` node to store and merge profiling information for a given `Value*` regardless of which invocation of a function (i.e. which `frame_id`) it came from
  a. An example of setting `ty_` : https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/runtime/profiling_record.cpp#L172
  b. An example of using `ty`: https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/passes/tensorexpr_fuser.cpp#L284
3. Remove this code : https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/runtime/profiling_record.cpp#L358-L416 since we should already have merged profiling information for each value in `profiled_type` attribute of each prim::profile node.
4. Remove any auxiliary functions and/or structures used by either 2. or 3. 
5. Run CI to identify tests that were testing the removed feature.
6. Remove the tests.


## Additional context

1. Learning how to build PyTorch and run tests (1-3 days)
2. Reading `profiling_record.cpp`/`profiling_record.h` (1-2 days)
3. Cleaning up `profiling_record.cpp` (1-2 days)
4. Running the tests (1 day)
5. Inspecting failures (1-3 days)

Before working on this task, it's recommended to acquire some basic understanding of PE flow. This can be done by writing a simple model (2-3 ops) or using one of our tests in `test_jit.py` or `test_jit_fuser_te.py` and running it multiple times (1st time for profiling, 2nd time for optimization) and inspecting the output of `export PYTORCH_JIT_LOG_LEVEL=>>profiling_graph_executor_impl`
Repository: rust
Issue: Warn if no-op `let _ = x` statement is used
Labels: A-lints,T-lang,T-compiler,C-feature-request

This is related to https://github.com/rust-lang/rust/issues/90465.

The problem is code as follows

```rust
    let x = ...;
    let c = move || {
        let _ = x;
    };
```

or also

```rust
fn foo() {
    let x: u32;
    let _ = x; 
}
```

The `let _ = x` statement in both cases has no effect at all:
  - In the first case with the 2021 edition it does not move the `x` into the closure. With the 2018 edition it is moved into the closure however.
  - In the second case the variable `x` is not even initialized.

As the statement generally has no effect, it would be good to warn if it used like in the above cases. The author of the code probably intended something that the code is not actually doing.
Repository: PowerToys
Issue: When turning off auto-complete history, delete history file 
Labels: Idea-Enhancement,Help Wanted,Product-PowerRename

### Description of the new feature / enhancement

My suggestion is that if there is a function that can erase the history of PowerRename, that would be wonderful. 

### Scenario when this would be used?

It was about privacy, so I do not like others to see the history of the PowerRename, I can clear the history after I open it up. 

### Supporting information

_No response_
Repository: pytorch
Issue: Building libtorch from source requires too much RAM
Labels: module: build,module: cuda,triaged

## 🐛 Bug

I tried doing the following:
```
git clone --recursive https://github.com/pytorch/pytorch.git
cd pytorch
python3 tools/build_libtorch.py
```

Within seconds, the script has consumed 32GB of RAM and my computer crashes.
That's crazy!

How can we reduce the amount of memory consumed? Usually ninja uses the right amount of threads, i.e. equal to the number of cores, in my case 8. But something tells me that there is a hard-coded number of threads equal to something stupid like 256. Otherwise, ninja would never require 32+GB of RAM for any build.

## Expected behavior

I expect this to build on my machine.

## Environment

```
Collecting environment information...
PyTorch version: 1.10.0+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.5 LTS (x86_64)
GCC version: (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.20.5

Python version: 3.6 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: NVIDIA GeForce RTX 2070 SUPER
GPU 1: NVIDIA GeForce RTX 2070 SUPER

Nvidia driver version: 465.19.01
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.2.4
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.2.4
/usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudnn.so.8.1.1
/usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.1.1
/usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.1.1
/usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.1.1
/usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.1.1
/usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.1.1
/usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] efficientnet-pytorch==0.6.3
[pip3] msgpack-numpy==0.4.7.1
[pip3] numpy==1.19.5
[pip3] pytorch-complex==0.0.7.2
[pip3] pytorch-metric-learning==0.9.85
[pip3] pytorch-ranger==0.1.1
[pip3] segmentation-models-pytorch==0.1.3
[pip3] torch==1.10.0+cu113
[pip3] torch-dct==0.1.5
[pip3] torch-lr-finder==0.2.0
[pip3] torch-optimizer==0.1.0
[pip3] torchaudio==0.10.0+cu113
[pip3] torchvision==0.11.1+cu113
[conda] Could not collect
```

## Additional context

<!-- Add any other context about the problem here. -->


cc @malfet @seemethere @ngimel
Repository: vscode
Issue: Support structured "browser" property in package.json
Labels: feature-request,extension-host

Today VS Code supports a `browser` property of type string in the `package.json` to specify an extension's entry point for web worker based extensions.

When using `esbuild` for bundling the extension, the `browser` property of the package.json can be used to substitute some node-only built-in packages for a browser-friendly alternative by listing (see https://esbuild.github.io/getting-started/#bundling-for-the-browser).

When this esbuild feature is used, VS Code runs into an issue and shows this alert:
<img width="483" alt="2021-11-02_17-12-15" src="https://user-images.githubusercontent.com/1898161/140031504-a7618840-91eb-4e4f-9690-325f17f34bdb.png">

I suggest that VS Code accepts a structured `browser` property and looks for a `main` sub-property in this case.

/cc @jrieken @alexdima @sandy081
Repository: opencv
Issue: putText antialiasing doesn't work with float images
Labels: feature,category: imgproc

In python, using:

```
cv2.putText(frame, text, org, font_face, font_scale, color, lineType=cv2.LINE_AA)
```

doesn't produce antialiased text when `frame` is of type `np.float32`.

Changing it to:
```
frame = (frame*255).astype(np.uint8)
cv2.putText(frame, text, org, font_face, font_scale, color, lineType=cv2.LINE_AA)
```

and using

`color=(255, 255, 255)` instead of `color=(1, 1, 1)`

then nicely antialiases the text...

This is with `opencv-python-headless=4.4.0.42`