sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Add nnapi serialization for module components in Wav2Vec2Model
Labels: module: android,oncall: mobile

## 🚀 Feature
Running wav2vec2 model on accelerated mobile phone hardware, using nnapi

## Motivation

We've been able to run a quantized wav2vec2 model on a beefy mobile phone, but this takes a lot of CPU power, and is slow (because the model is large I suppose).  Being able to run on accelerated hardware via the nnapi would potentially speed up inference time. 

## Pitch

If the nnapi model serialization trick would work for a `torchaudio.Wav2Vec2Model`, then that would be really cool and big kudos for pytorch

## Alternatives

 - run slower
 - train a smaller model
 - run on GPU-backed cloud

## Additional context

I've tried monkey-patching `torch.backends._nnapi.serializer._NnapiSerializer.ADDER_MAP`, but after (guessing) the functionality of `aten::dim` as 
```python
def add_dim(self, node):
    assert node.inputsSize() == 1
    assert node.outputsSize() == 1

    _, in_oper = self.get_tensor_operand_by_jitval_fixed_size(node.inputsAt(0))
    res = len(in_oper.shape)
    output = node.outputsAt(0)
    self.add_constant_value(output, output.type(), res)
```
the next unsupported operation was `aten::conv1d`, and my guess it that that is too hard for me to do that, and potentially a whole lot of other operations, myself.
Repository: pytorch
Issue: Gloo and TensorPipe depend on different version of libuv
Labels: oncall: distributed,module: build,triaged,module: third_party,module: tensorpipe

TensorPipe includes libuv-1.41 as submodule, as can be seen [here](
https://github.com/pytorch/tensorpipe/tree/master/third_party):
While Gloo simply depends on libuv>=1.26:
https://github.com/facebookincubator/gloo/blob/9c1876a9000c9585c9406941770950404128bbe2/cmake/Dependencies.cmake#L81

Which results in a strange idiosyncratic behavior when building PyTorch , which depends on libuv for build
https://github.com/pytorch/builder/blob/a2df736ec6d3ac8e679fb02e3776a3b505aaa8f9/conda/pytorch-nightly/meta.yaml#L27

And compiles gloo using libuv public headers, but then compiles TensorPipe against newer version and links this version statically into `libtorch_cpu`, which were accidentally exposed in https://github.com/pytorch/pytorch/issues/64649 when added `libllvm` dependency change include order.

In the long run, we should either:
- Teach Gloo to use embedded libUV
- Remove libuv as submodule dependency of TensorPIpe

cc @malfet @seemethere @osalpekar @jiayisuse @lw @beauby @pritamdamania87 @mrshenli @jjlilley @gqchen @rohan-varma
Repository: pytorch
Issue: [DataPipe] Add Test Cases to Ensure Correct Behaviors When IterDataPipes Reset
Labels: triaged,module: data

## 🚀 Feature

Within the [test_datapipe](https://github.com/pytorch/pytorch/blob/master/test/test_datapipe.py) file, we should create test cases for each type of IterDataPipe to ensure that they behave correctly when they are reset under different scenarios.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

Generally, each IterDataPipe should reset when `iter(DataPipe)` is called, regardless if the IterDataPipe is partially read or fully read. This behavior can be tricky to implement for certain IterDataPipes and sometimes they should raise appropriate warnings to help users understand what is happening and which objects are affected. Therefore, we should ensure that there are test cases for each IterDataPipe to ensure correctness. 

## List

- [ ] Batcher
- [x] BucketBatcher (deprecated and will be moved to TorchData)
- [ ] Collator
- [ ] Concater
- [ ] DFIterDataPipe
- [x] Demultiplexer
- [ ] FileLister
- [ ] FileLoader
- [ ] Filter
- [x] Forker
- [ ] Grouper
- [x] HttpReader (deprecated and will be moved to TorchData)
- [ ] IterableWrapper
- [x] LineReader (deprecated and will be moved to TorchData)
- [ ] Mapper
- [ ] Multiplexer
- [ ] RoutedDecoder
- [ ] Sampler
- [ ] Shuffler
- [ ] StreamReader
- [x] TarArchiveReader (deprecated and will be moved to TorchData)
- [ ] UnBatcher
- [x] ZipArchiveReader (deprecated and will be moved to TorchData)
- [ ] Zipper

Some IterDataPipes are very simple and do not require such test. For example, `IterableWrapper` has an `iter` function that is simply `for data in it: yield data`. Therefore, this test may not be needed and feel free to mark them as such.

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->

This helper function has already been written and it can be used to generate results from a DataPipe before and after a reset.

https://github.com/pytorch/pytorch/blob/3fb33b38b9edfb294b32b61e6c6133822e48f215/test/test_datapipe.py#L114-L119

Here is an example of the helper function being used to test `TarArchiveReader`:

https://github.com/pytorch/pytorch/blob/3fb33b38b9edfb294b32b61e6c6133822e48f215/test/test_datapipe.py#L254-L270

Here is an example of various reset-related test cases that `Forker` has to ensure correctness in its behavior. This is one of the more complicated examples because a reset impacts multiple objects (child DataPipes).

https://github.com/pytorch/pytorch/blob/3fb33b38b9edfb294b32b61e6c6133822e48f215/test/test_datapipe.py#L768-L813

cc @VitalyFedyunin @ejguan
Repository: pytorch
Issue: torch.linalg.cholesky does not raise a RuntimeError when the matrix is not symmetric
Labels: module: docs,triaged,module: linear algebra

## 📚 Documentation

The documentation for [`torch.linalg.cholesky`](https://pytorch.org/docs/stable/generated/torch.linalg.cholesky.html) mentions that a `RuntimeError` is raised when the matrix "is not Hermitian (resp. symmetric) positive-definite" which seems incorrect. It looks like `torch.linalg.cholesky` behaves similarly to [`numpy.linalg.cholesky`](https://numpy.org/doc/stable/reference/generated/numpy.linalg.cholesky.html) which does not check if the matrix is symmetric and only uses the lower-triangular and diagonal elements of the matrix.

The following code does not raise a `RuntimeError` when the matrix is clearly not symmetric:

```python
import torch
torch.manual_seed(0)
A = torch.rand(4, 4) + torch.eye(4) * 10
L = torch.linalg.cholesky(A)
```


cc @brianjo @mruberry @jianyuh @nikitaved @pearu @walterddr @IvanYashchuk @xwang233 @Lezcano
Repository: scrcpy
Issue: Add option to cause mouse middle-click to paste text
Labels: feature request


First, a HUGE thank you for scrcpy; it's monumentally useful.  I'm using 1.19 on Arch Linux.

As a user of the X window system, I'm used to middle-clicking to paste text, and it would be really nice if that worked in scrcpy as well.  (For now, I use "--forward-all-clicks" so that my reflexive clicking at least doesn't cause the HOME action!  And I paste with ctrl-V.)

Would it be possible to add an option (say, "--middle-click-paste") to make middle-click paste the clip-board's text, instead of sending HOME?


Anne.
Repository: angular
Issue: Please create an interface for HttpClient's 'options' parameter
Labels: feature,area: common/http,cross-cutting: types,feature: under consideration

### Which @angular/* package(s) are relevant/releated to the feature request?

common

### Description

Practically every method in HttpClient has an `options` parameter where the type is defined every time.  Because it's not an actual type, that makes it very hard to dynamically build up the options in a calling method when using strict type checking.

### Proposed solution

Something like:

```typescript
export declare interface HttpClientOptions {
        body?: any;
        headers?: HttpHeaders | {
            [header: string]: string | string[];
        };
        context?: HttpContext;
        observe?: 'body';
        params?: HttpParams | {
            [param: string]: string | number | boolean | ReadonlyArray<string | number | boolean>;
        };
        reportProgress?: boolean;
        responseType: 'arraybuffer';
        withCredentials?: boolean;
}
```

### Alternatives considered

Not sure what else could be done.
Repository: rust
Issue: Windows builds are not deterministic with --crate-type=bin and path-prefix remapping
Labels: O-windows,T-compiler,C-bug,A-reproducibility

The existing reproducible-build tests only verify that building with `--crate-type=rlib` produces the same output when building from different locations when using `--remap-path-prefix` to strip out the location differences.

https://github.com/rust-lang/rust/pull/87320 adds another way to do this with `--remap-cwd-prefix`. It added a test that verifies the same thing with rlibs, but also added a test for `--crate-type=bin`. This test for `bin` passes on Linux but fails with a difference in the output on Windows: https://github.com/rust-lang/rust/pull/87320#issuecomment-920105533

```
2021-09-15T00:11:03.6840467Z /d/a/rust/rust/build/x86_64-pc-windows-msvc/test/run-make-fulldeps/reproducible-
build/reproducible-build/first /d/a/rust/rust/build/x86_64-pc-windows-msvc/test/run-make-fulldeps/reproducible-build/
reproducible-build/reproducible-build differ: char 140561, line 276  <<<<====
2021-09-15T00:11:03.6843153Z make[1]: Leaving directory '/d/a/rust/rust/src/test/run-make-fulldeps/reproducible-build'
2021-09-15T00:11:03.6843848Z 
2021-09-15T00:11:03.6844310Z ------------------------------------------
2021-09-15T00:11:03.6844776Z stderr:
2021-09-15T00:11:03.6845251Z ------------------------------------------
2021-09-15T00:11:03.6845850Z make[1]: *** [Makefile:78: remap_cwd_bin] Error 1
```

To verify, I added another test of `--remap-path-prefix` with `--crate-type=bin` to see if that produces non-deterministic build outputs on Windows as well, and it does: https://github.com/rust-lang/rust/pull/87320#issuecomment-920205146

```
2021-09-15T16:43:43.1281275Z /d/a/rust/rust/build/x86_64-pc-windows-msvc/test/run-make-fulldeps/reproducible-
build/reproducible-build/reproducible-build /d/a/rust/rust/build/x86_64-pc-windows-msvc/test/run-make-fulldeps/reproducible-
build/reproducible-build/foo differ: char 139921, line 272  <<<<====
2021-09-15T16:43:43.1282876Z make[1]: Leaving directory '/d/a/rust/rust/src/test/run-make-fulldeps/reproducible-build'
2021-09-15T16:43:43.1283397Z 
2021-09-15T16:43:43.1283769Z ------------------------------------------
2021-09-15T16:43:43.1284164Z stderr:
2021-09-15T16:43:43.1284554Z ------------------------------------------
2021-09-15T16:43:43.1285077Z make[1]: *** [Makefile:72: different_source_dirs_bin] Error 1
```

Thus we see that the output of `--crate-type=bin` is not deterministic on Windows, based on running rustc from different directories.

### Meta
This is with rustc at tip of tree, as the commit queue found it in merge https://github.com/rust-lang/rust/commit/e63d3d7581bdb6f629f01f8bafa6ec29e7ac97d8 .
HEAD was https://github.com/rust-lang/rust/commit/c3c0f80d608 at that time, I believe.

No root cause determined yet, and I don't have the Windows binary outputs to see what is at the differing location yet.
Repository: ant-design
Issue: Row background incorrect for rows that use rowSpan
Labels: Inactive

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/antd-col-span-hover-bug-reprodution-05hrn?file=/index.js)

### Steps to reproduce
When we are using the rowSpan props, the row hover is not changing the entire row background, just the first row or the row with rowSpan. The others rows are only changing the background when you hover over it.

### What is expected?
The entire row's set covered by the rowSpan should change the background when hovered. 

### What is actually happening?
Just for the first row, the remaining others not. 

| Environment | Info |
|---|---|
| antd | 4.16.13 |
| React | react |
| System | MacOS 11.6 |
| Browser | Firefox 92.0 (64-bit) |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: Signal 11 crash in AppleIntelICLGraphicsGLDriver on 2020 macs with Intel Iris Plus Graphics (940,640)
Labels: bug,platform:macos,topic:rendering,needs testing,crash

### Godot version

v3.3.2.stable.official

### System information

osx catalina/big sur,GLES3/~GLES2~,Intel Iris Plus Graphics 640 and 940

### Issue description

The engine crashes with signal 11 on newer macs with Intel Iris Plus Graphics.

```
Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00007fbce4052508
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [25946]

VM Regions Near 0x7fbce4052508:
    MALLOC_LARGE             7fbce4000000-7fbce4018000 [   96K] rw-/rwx SM=PRV  
--> 
    MALLOC_LARGE             7fbce4064000-7fbce407c000 [   96K] rw-/rwx SM=PRV  

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.driver.AppleIntelICLGraphicsGLDriver	0x00007fff64cdf23a processOperations(_IntelTempCompileParams*, USC::IM_Shader*, ShaderInfoRec*, _PPStreamToken*, unsigned int, unsigned int, std::__1::bitset<80ul>*, unsigned int*, unsigned int*, unsigned int*, unsigned int, unsigned int, unsigned int*) + 157824
1   com.apple.driver.AppleIntelICLGraphicsGLDriver	0x00007fff63f4e2fe PPStreamToGHAL(GLDContextRec*, GLDProgramRec*, ShaderInfoRec*) + 24616
2   com.apple.driver.AppleIntelICLGraphicsGLDriver	0x00007fff63f30767 intelUpdateCtxSysProgramCommon(GLDContextRec*, GLDProgramRec*, GLDPipelineProgramRec*, void*, ShaderInfoCacheRec*, unsigned int) + 3404
3   com.apple.driver.AppleIntelICLGraphicsGLDriver	0x00007fff63f2f1b1 gpusLoadCurrentPipelinePrograms + 3511
4   com.apple.driver.AppleIntelICLGraphicsGLDriver	0x00007fff63f2d035 updateDispatch + 1590
5   GLEngine                      	0x00007fff6bec92e6 gleDoDrawDispatchCoreGL3 + 674
6   GLEngine                      	0x00007fff6be901ea gleDrawArraysOrElements_Entries_Body + 151
7   GLEngine                      	0x00007fff6be8cd84 glDrawElements_GL3Exec + 227
```

[crash.txt](https://github.com/godotengine/godot/files/7172526/crash.txt)


### Steps to reproduce

https://github.com/godotengine/godot/issues/52722#issuecomment-922087067

### Minimal reproduction project

https://github.com/godotengine/godot/issues/52722#issuecomment-922087067

_No response_
Repository: pytorch
Issue: THPVariable_subclass_dealloc (i.e. tp_dealloc for torch.Tensor) should handle Python error state gracefully
Labels: high priority,module: internals,triaged,module: correctness (silent)

## 🐛 Bug

Identified by @albanD, from offline discussion with @ezyang: "You cannot assume that there isn't an error already set when THPVariable_dealloc is called.
If you need to call some functions that might clobber the global error state in there, we should PyErr_Fetch at the beginning of the function and PyErr_Restore at the end."

## To Reproduce

See https://github.com/pytorch/pytorch/pull/65068

## Expected behavior

We should call PyErr_Fetch at the beginning of THPVariable_subclass_dealloc and PyErr_Restore at the end. However (and this is the reason why I haven't submitted a patch for this yet) we have to be very, very careful about what happens if a Python error (call this error B) occurs in between PyErr_Fetch and PyErr_Restore. I guess we have a few options here:
- completely ignore error B
- don't PyErr_Restore if error B occured
- PyErr_Restore only if an error was previously set before entering tp_dealloc
Does python have a better solution for this?

Here's some examples of this out in the wild:
- https://github.com/posborne/dbus-python/blob/fef4bccfc535c6c2819e3f15384600d7bc198bc5/_dbus_bindings/conn.c#L387
- https://bugs.python.org/issue45210?%40ok_message=msg%20401854%20created%0Aissue%2045210%20created&%40template=item

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @bhosmer @smessmer @ljk53
Repository: PowerToys
Issue: Fancy zones - Different layouts depending on Monitor Arrangement
Labels: Idea-Enhancement,Product-FancyZones

### Description of the new feature / enhancement

Would like to see intelligence added to Fancy Zones whereby the selected FZ configuration could be dependent upon whether my laptop is connected to external monitor (or external monitors) -- or not.

For example, laptop with 14" screen really doesn't need use of fancy zones when mobile, however, when docked to the 5K2K display at my office, I'd like FZ to sense that and *enable* FZ with Custom Layout X, and recall the state of each Zone Behavior value. (e.g. hold Shift to enable snap or not). 

Think hardware profiles....

### Scenario when this would be used?

When you have a portable system, i.e. notebook, that connects to external monitor(s). Might even be multiple different monitors. e.g. one monitor configuration at office and a different one at home.

### Supporting information

_No response_
Repository: flutter
Issue: The label strings in BottomNavigationBar do not appear centred when overflow is set to visible and label string overflows
Labels: framework,f: material design,c: proposal,team-design,triaged-design

## Use case

In the BottomNavigationBar, TextStyle for both selected and unselected labels has overflow property set to ``TextOverflow.ellipsis`` by default. To fully display long strings as labels, this property needs to be set to ``TextOverflow.visible``. This makes sure when the string is too long to fit in the container, part of it moves to the next line. However, when this happens, the string is left aligned and there is no way to centre it. This is not a problem when there is no overflow as the container size is exactly same as string size, and because the container is always centred, the string appear in the centre. However when the string overflows, the container expands to maximum size and the string inside appears left aligned.

## Proposal

Text should be centred even when the label string overflows to multiple lines.
Repository: pytorch
Issue: Bug: torch.jit.load cannot load from IOBuffer
Labels: oncall: jit

Taking code straight from the documentation on [this page](http://man.hubwiz.com/docset/PyTorch.docset/Contents/Resources/Documents/jit.html):

```
import torch
import io

class MyModule(torch.nn.Module):
    def forward(self, x):
        return x + 10

m = torch.jit.script(MyModule())

# Save to io.BytesIO buffer
buffer = io.BytesIO()
torch.jit.save(m, buffer)
```

If we then run:

```torch.jit.load(buffer)```

We see:

```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/torch/jit/_serialization.py", line 163, in load
    cpp_module = torch._C.import_ir_module_from_buffer(
RuntimeError: PytorchStreamReader failed reading zip archive: not a ZIP archive
```

Also worth noting that if you save to a file, and then read into a buffer, and load from there, it does work as intended:

```
torch.jit.save(m, 'scriptmodule.pt')
with open('scriptmodule.pt', 'rb') as f: buffer = io.BytesIO(f.read())
torch.jit.load(buffer)
```

This is on Mac and Linux, Python3.9, torch 1.9.0.
Repository: excalidraw
Issue: Sorting Library Items
Labels: enhancement

Thanks for all the amazing work on excalidraw!

A hugely amazing feature would be being able to sort library items via drag and drop or some similar interface.

Workflow:
1. Open library tab
2. Click and hold a library item
3. Drag it around in the panel
4. Release and the underlying library is resorted.

Thanks for the consideration!
Repository: flutter
Issue: Investigate existing g_realloc leaks and stop suppressing them
Labels: engine,from: sanitizer,P3,team-engine,triaged-engine

Realloc calls originating from g_realloc obscure the trace of the original allocation. These traces still likely represent legitimate leaks, but they're harder to track down and fix because of this.

At the moment, they're being suppressed in `lsan_suppressions.txt`. Remove this suppression and fix the existing leaks (at the time of writing, this only amounts to 4 allocations totaling 512 bytes) so that new ones are caught in CI as they happen.
Repository: vscode
Issue: [Test UI] [Feature Request] Allow message for skipped() test function
Labels: feature-request,testing

@connor4312 
Issue Type: <b>Feature Request</b>

In Pester, tests can be skipped/inconclusive for reasons, for instance, because other tests precluded the need, or a flaw in a test made this test be inconclusive, or because a dependent test did not complete successfully.

Today I have to express these as error messages, I would prefer to be able to express it as part of the skipped() method using the same nomenclature as error, and also have a highlight for skipped messages that is a warning color or a gray color.
![image](https://user-images.githubusercontent.com/15258962/133524947-576be610-3888-4555-bbc2-5f88e9494a57.png)



VS Code version: Code - Insiders 1.61.0-insider (0c83ca1ced83259971d80890d93abbe19cbfc992, 2021-09-15T05:16:32.507Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No

<details><summary>Extensions (45)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-log-viewer|ber|0.12.2
markdown-checkbox|bie|0.3.2
vscode-opennewinstance|chr|0.0.12
esbuild-problem-matchers|con|0.0.2
vscode-eslint|dba|2.1.25
vscode-generate-getter-setter|DSK|0.5.0
gitlens|eam|11.6.0
filter-lines|ear|1.0.0
EditorConfig|Edi|0.16.4
prettier-vscode|esb|8.1.0
copilot|Git|1.4.2678
remotehub|Git|0.14.0
vscode-pull-request-github|Git|0.30.0
todo-tree|Gru|0.0.214
vscode-test-explorer|hbe|2.21.1
vscode-drawio|hed|1.6.2
change-case|hjd|1.0.2
git-graph|mhu|1.30.0
vscode-bicep|ms-|0.4.613
vscode-docker|ms-|1.16.1
csharp|ms-|1.23.15
vscode-dotnet-runtime|ms-|1.2.0
remote-containers|ms-|0.195.0
remote-ssh-nightly|ms-|2021.9.19620
remote-wsl|ms-|0.58.2
azure-account|ms-|0.9.8
powershell-preview|ms-|2021.9.1
test-adapter-converter|ms-|0.1.2
vscode-paste-image|mus|1.0.4
indent-rainbow|ode|8.0.0
docthis|oou|0.8.2
vscode-jest|Ort|4.1.2
pester-test|psp|0.0.0-source
quicktype|qui|12.0.46
vscode-commons|red|0.0.6
vscode-yaml|red|0.22.0
vscode-sort-json|ric|1.20.0
even-better-toml|tam|0.14.2
vscode-inline-values-powershell|Tyl|0.0.5
errorlens|use|3.4.0
vscode-icons|vsc|11.6.0
codetour|vsl|0.0.58
gistfs|vsl|0.3.0
gitmoji-vscode|Vtr|1.0.7
better-align|wwm|1.1.6


</details>
<!-- generated by issue reporter -->