sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Can't bake lightmaps on a MultiMeshInstance at all
Labels: bug,topic:rendering,topic:3d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.3.0
<!-- Specify commit hash if using non-official build. -->


**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Tested on both GLES2 and GLES3, Windows 10, Intel integrated graphics

**Issue description:**
<!-- What happened, and what was expected. -->
I can't bake a lightmap into a MultiMeshInstance. Nor can I use a MultiMeshInstance in a lightmap.
Given that I can bake a GridMap, I was under the impression I could bake a MultiMeshInstance as well.

**Steps to reproduce:**
1. Create a scene with a light source, BakedLightmap, and MultiMesh
2. Ensure the MutliMesh is using an ArrayMesh with the UV2 unwrapped for BakedLightMaps by adding it to a regular mesh and clicking "Unwrap UV2 for Lightmap/AO"
3. Set the used_in_baked_light and generate_lightmap options to true
4. Bake the lightmap
5. Multimesh is excluded entirely

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
This issue is actually already covered in [#45313](https://github.com/godotengine/godot/issues/45313), although the poster doesn't seem to aware at all (likely because the SSAO in the sample project made it look like the MultiMeshInstance casted a shadow)

Here's a simpler project: [bakedlighmap_test.zip](https://github.com/godotengine/godot/files/6519455/bakedlighmap_test.zip)

![image](https://user-images.githubusercontent.com/28760461/119068110-82d0bd00-b9b1-11eb-9a4f-0f57bc9379c7.png)

This is an image of the scene after I bake the indirect light and then turn the directional light off.
The lefthand side is a bunch of individual meshes (indirect light off the spheres is saved, as desired)
The middle is a multimesh (nothing is saved)
The left is a single sphere (for reference)
Repository: create-react-app
Issue: This page can't be opened => https://create-react-app.dev/
Labels: stale,needs triage

This page can't be opened
Repository: ant-design
Issue: About the pagination of table components
Labels: 🗣 Discussion,Inactive

- [ ] 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
[https://stackblitz.com/edit/react-9wqw2i?file=index.js](https://stackblitz.com/edit/react-9wqw2i?file=index.js)

### Steps to reproduce
when you click  the pageSizeChanger , the ‘current’  (current page) is reset to 1

### What is expected?
Scenario: Currently, there are 10000 rows of data, 10 rows per page. When the user turns to the middle, exp the 351 page, he finds that the number of per page is relatively small and just wants to enlarge the number of per page  .But now he had to turn from the first page to find the data he had just looked at。

Like this algorithmconst :
 const current = Math.ceil(((beforePage * beforePageSize)>total?total:(beforePage * beforePageSize))/NewPageSize);

We can get a reasonable result; 

### What is actually happening?
when you click  the pageSizeChanger , the ‘current’  (current page) is reset to 1

| Environment | Info |
|---|---|
| antd | 4.9.1 |
| React | 16.14.0 |
| System | window10 |
| Browser | chrome |

---
Like this algorithmconst :
 const current = Math.ceil(((beforePage * beforePageSize)>total?total:(beforePage * beforePageSize))/NewPageSize);

We can get a reasonable result;


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: node
Issue: Revisiting: fix for loading module twice with different case on case insensitive FSes
Labels: module

@isaacs said in #5702 that it's impossible to tell if two filenames with different case point to the same file or not.

However, on mac OS at least with a case-insensitive filesystem, `fs.stat` will give the same `ino` for the same filename with different case.  So it's completely possible, unless `ino` is somehow unreliable on some OSes.

I just ran into this issue due to a typo and it was mega confusing and annoying.  Maybe `ino` was unavailable in the 0.x days, but it seems like there's no reason not to fix this now.

Seems to me that `ino` should be the real cache key, and `require.cache` should actually be retrofitted to proxy to an underlying `ino`-keyed cache.  (I assume this would avoid duplicate loading multiple hardlinks to the same file as well).  `delete require.cache[key]` would only actually delete the module if `key` is the last remaining path for the underlying `ino`.

However, I do read that inodes on windows are...complicated...so someone feel free to shoot holes in this proposal.
Repository: flutter
Issue: [camera] Provide an option to choose video encoder for iOS
Labels: platform-ios,p: camera,package,c: proposal,P3,team-ios,triaged-ios

Please rollback iOS to H264, or give to a choice

Commit:
https://github.com/flutter/plugins/commit/9cd84bdba7fcb18750f9916e3cad70963950709b

![image](https://user-images.githubusercontent.com/32374709/119087189-2d7fc480-ba20-11eb-9159-6312c7ceee79.png)

Its critical for me: i cant view video recorded in latest version by iOS inside html5 video player and must use previous version - 0.8.0.
Repository: pytorch
Issue: Support for `uint16`, `uint32`, and `uint64`
Labels: feature,triaged,ezyang's list,module: python array api,oncall: pt2

The [array API specification](https://data-apis.org/array-api/latest/API_specification/data_types.html) stipulates the data types that we need to support to be compliant. Currently we are missing support for `uint16`, `uint32`, and `uint64`.

cc @mruberry @rgommers @asmeurer @leofang @AnirudhDagar @asi1024 @emcastillo @kmaehashi @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @gchanan @soumith @ngimel
Repository: pytorch
Issue: CSR construction: safe_get_attr_string suppresses real errors
Labels: module: sparse,triaged,open source

The current implementation:
https://github.com/pytorch/pytorch/blob/d88d321ee3a65894baf6dc0a580b44180ec52f3c/torch/csrc/utils/tensor_new.cpp#L615-L624
suppresses real errors when acquiring `dtype` of input to CSR construction. The corresponding code should read:
```
if (!rc) {
    if (!PyErr_ExceptionMatches(PyExc_AttributeError)) {
        throw python_error();
    }
    // Warning: a wrong attribute error may be suppressed here
    PyErr_Clear();
}
```

The issue was originally raised in https://github.com/pytorch/pytorch/pull/57274#discussion_r636691793

cc @aocsa @nikitaved @pearu @mruberry
Repository: pytorch
Issue: type promotion with 0d-tensors diverges from array API specification
Labels: triaged,module: type promotion,module: python array api

The [array API specification stipulates](https://data-apis.org/array-api/latest/API_specification/type_promotion.html) clear type promotion rules, that are independent of the array size and values:

![Type promotion stipulated by the array API specifictation](https://data-apis.org/array-api/latest/_images/dtype_promotion_lattice.png)

PyTorch mostly adheres to this with one exception: Within a dtype category (integral, floating, complex) 0d-tensors do not participate in type promotion:

```python
import torch

dtype_categories = (
    (torch.int8, torch.uint8, torch.int32, torch.int64),
    (torch.float16, torch.bfloat16, torch.float32, torch.float64),
    (torch.complex32, torch.complex64, torch.complex128),
)

for dtypes in dtype_categories:
    for idx in range(len(dtypes) - 1):
        dtype_nd = dtypes[idx]
        for dtype_0d in dtypes[idx + 1:]:
            a = torch.empty((1,), dtype=dtype_nd)
            b = torch.empty((), dtype=dtype_0d)
            print(f"{a.dtype} + {b.dtype} = {torch.result_type(a, b)}")
```

```
torch.int8 + torch.uint8 = torch.int8
torch.int8 + torch.int32 = torch.int8
torch.int8 + torch.int64 = torch.int8
torch.uint8 + torch.int32 = torch.uint8
torch.uint8 + torch.int64 = torch.uint8
torch.int32 + torch.int64 = torch.int32
torch.float16 + torch.bfloat16 = torch.float16
torch.float16 + torch.float32 = torch.float16
torch.float16 + torch.float64 = torch.float16
torch.bfloat16 + torch.float32 = torch.bfloat16
torch.bfloat16 + torch.float64 = torch.bfloat16
torch.float32 + torch.float64 = torch.float32
torch.complex32 + torch.complex64 = torch.complex32
torch.complex32 + torch.complex128 = torch.complex32
torch.complex64 + torch.complex128 = torch.complex64
```

This is not documented well(see #58489), but seems to be intentional.


cc @nairbv @mruberry
Repository: vscode
Issue: Workspace trust - update issue reporter
Labels: feature-request,issue-reporter,workspace-trust

- [x] Include workspace trust state when filing an issue through the Issue reporter
- [ ] Update the GitHub bug template so that the user tries to reproduce the issue in a trusted workspace

//cc @sbatten
Repository: vscode
Issue: Getting started button have to be touched twice to work
Labels: bug,ios-ipados

1. iOS, open the getting started page
2. `Customize your Setup`, `Learn the Fundamentals` and `Boost your Productivity` buttons have to be touched twice in order to react 🐛 

So the first touch puts focus on them. And only the second time you touch them they work.
Seems like you are not handling the touch events correctly.
If I use an external mouse everything works fine
Repository: pytorch
Issue: `torch.size()` diverges from array API specification
Labels: triaged,module: deprecation,module: python array api

The [array API specification stipulates](https://data-apis.org/array-api/latest/API_specification/array_object.html#size) that the `size` attribute of an array should return an integer with the number of elements of the array.

In PyTorch the `size` attribute is a method that returns the [`shape`](https://data-apis.org/array-api/latest/API_specification/array_object.html#shape) when called. The number of elements is accessible through the `numel()` method:

```python
import torch

t = torch.empty((2, 3, 4))
size = 2 * 3 * 4

assert t.size() == t.shape
assert t.numel() == size

cc @mruberry @rgommers @pmeier @asmeurer @leofang
Repository: pytorch
Issue: Python Array API New Operators Tracker
Labels: triaged,module: python array api,tracker

The [array API specification stipulates](https://data-apis.org/array-api/latest/API_specification/array_object.html#size) the following operators that are currently not supported by PyTorch:

- [x] `__dlpack__`
- [x] `__dlpack_device__`
- [x] `__rand__` (#58120)
- [x] `__rlshift__` (#58121, #59544)
- [x] ~`__imatmul__`~ - not doing `__imatmul__` because `matmul` doesn't always preserve shape, and still has a resize bug (see gh-64387)
- [x] `__rmatmul__` (#57719, #58216)
- [x] `__rmod__` (#58035, #58476)
- [x] `__ror__` (#58120)
- [x] `__rrshift__` (#58121, #59544)
- [x] `__rxor__` (#58120)
- [x] `from_dlpack` (~implemented, but not exposed yet in the `torch` namespace~ in main namespace in `1.10.0`)
- [ ] `broadcast_arrays`
- [x] `bitwise_left_shift` (#59544)
- [ ] `bitwise_invert`
- [x] `bitwise_right_shift` (#59544)
- [x] `vecdot` (#70542)
- [x] `concat` (we should be sure torch.cat is compliant and alias concat to it) (#61767) 
- [ ] `expand_dims` (#57116)
- [x] `__ipow__` (#76900)
- [ ] `to_device`
- [ ] `astype`
- [ ] `unique_(all|counts|inverse|values)` #70920
- [x] `linalg.diagonal` https://github.com/pytorch/pytorch/pull/70599
- [ ] `linalg.matrix_transpose`, `matrix_transpose`
- [ ] `linalg.outer` https://github.com/pytorch/pytorch/issues/63293
- [ ] `linalg.tensordot` https://github.com/pytorch/pytorch/pull/63478
- [ ] `linalg.trace` https://github.com/pytorch/pytorch/pull/62714
- [x] `linalg.vecdot` https://github.com/pytorch/pytorch/pull/70542

cc @mruberry @rgommers @pmeier
Repository: pytorch
Issue: Python Array API Compatibility Tracker
Labels: high priority,triaged,module: python array api,tracker

Progress tracker for all compatibility issues with [Python Array API specification](https://data-apis.org/array-api/latest/API_specification/index.html):

- [ ] `__array_namespace__` (add at/towards the end, it's the attribute that declares compliance)
- [ ] #58734
- [ ] #58736
- [x] #58739
- [x] #58740
- [ ] #58741
- [ ] #58742
- [x] #55090
- [ ] #58745
- [ ] `torch.nonzero` diverges from the specification (it returns a tensor, not a tuple, by default) - see gh-64502
- [ ] #59786
- [ ] #59787
- [x] ~#59867~
- [ ] #59868
- [x] #70591
- [ ] #70906
- [x] #70909
- [ ] #70910
- [ ] #70914
- [ ] #70915
- [ ] #70916
- [x] #70918
- [ ] #70919
- [ ] #70920
- [ ] #70921
- [x] #70922
- [x] #9190
- [ ] #70924
- [ ] #70925

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @anjali411
Repository: pytorch
Issue: Using pytorch 1.1 model on pytorch 1.8 environment
Labels: oncall: jit


Hello,

I am currently trying to use a pytorch model done with pytorch 1.0. I am doing a C++ code to load the model using torch script like this: module = torch::jit::load(net_fn);

First I tried to use pytorch 1.1 and I successfully used the model.

Now I am trying with pytorch 1.8, I did the following sequence:

I open load my model with pytorch 1.2 and I saved it again, then with pytorch 1.3, then pytorch 1.5 until getting the model on pytorch 1.8.

Then I tried to use the model I obtained on pytorch 1.8 but I got this error:

terminate called after throwing an instance of ‘std::runtime_error’
what(): The following operation failed in the TorchScript interpreter.
Traceback of TorchScript, serialized code (most recent call last):
File “code/torch.py”, line 65, in forward
_14 = torch.to(_11, dtype=4, layout=0, device=torch.device(“cuda:0”), pin_memory=False, non_blocking=False, copy=False, memory_format=None)
_15 = torch.to(_13, dtype=4, layout=0, device=torch.device(“cuda:0”), pin_memory=False, non_blocking=False, copy=False, memory_format=None)
_16 = torch.unsqueeze(torch.index(det, [_14, _15]), 1)
**~~~~~~~~~~~ <— HERE**
pts = torch.cat([_6, _9, _16], 1)
_17 = torch.slice(pts, 0, 0, 9223372036854775807, 1)

Traceback of TorchScript, original code (most recent call last):
File “code/gcn2_640x480_conv11.py”, line 42, in forward
_12 = torch.to(_9, dtype=4, layout=0, device=torch.device(“cuda:0”), pin_memory=False, non_blocking=False, copy=False)
_13 = torch.to(_11, dtype=4, layout=0, device=torch.device(“cuda:0”), pin_memory=False, non_blocking=False, copy=False)
_14 = torch.unsqueeze(torch.index(det, [_12, _13]), 1)
**~~~~~~~~~~~ <— HERE**
pts = torch.cat([_4, _7, _14], 1)
_15 = torch.slice(pts, 0, 0, 9223372036854775807, 1)
RuntimeError: Tried to cast a List to a List<Tensor?>. Types mismatch.

./run.sh: line 24: 9346 Aborted (core dumped) ./Examples/Monocular/mono_webcam

Could you please give me some highlights to solve this problem?

Regards.

cc @gmagogsfm
Repository: pytorch
Issue: `torch.(min|max)(..., dim=...)` diverges from array API specification
Labels: triaged,module: deprecation,module: reductions,module: python array api

The [array API specification stipulates](https://data-apis.org/array-api/latest/API_specification/statistical_functions.html?highlight=max#max-x-axis-none-keepdims-false) that `torch.(max|min)` must always return a tensor. [If called with `dim=...`](https://github.com/pytorch/pytorch/issues/58745#issuecomment-846921844)  `torch.return_types.(max|min)` is returned instead.

cc @mruberry @rgommers @pmeier @asmeurer @leofang @heitorschueroff @asi1024
Repository: rust
Issue: Documenting that Into implies TryFrom in a more visible manner.
Labels: C-enhancement

EDIT: The implementation seems to come from `Into` and not `From` as described below. See: https://github.com/rust-lang/rust/issues/85542#issuecomment-845877069.

I was working on a project and moved a `TryFrom` implementation to a `From` implementation.

The code that called the `TryFrom` implementation for the type wasn't changed but the project compiled and worked effortlessly.

Indeed, a [minimal reproduction](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b7d9227d16e2ba95e7eb6871c2e0f623) of this seems to work, compiling correctly:

```
use std::convert::TryFrom;

struct Foo{}

impl From<u32> for Foo {
    fn from(_: u32) -> Self {
        Foo{}
    }
}

fn main() {
    Foo::try_from(100u32).unwrap();
}
```

It makes sense to me that a `TryFrom` implementation `T -> Result<U, !>` could be automatically implemented from a `From` implementation `T -> U`, but I could not find this documented anywhere.

The documentation for [std::convert](https://doc.rust-lang.org/std/convert/trait.From.html), [std::convert::From](https://doc.rust-lang.org/std/convert/trait.From.html) and [std::convert::TryFrom](https://doc.rust-lang.org/std/convert/trait.TryFrom.html) seem to only mention that `From` implies `Into` and `TryFrom` implies `TryInto`.

I'm not sure if this behavior is intended, if it has limitations, such as applying only to some types, or if some documentation for it actually exists and I've missed it.

If the above is not the case, I would consider it sensible to add a mention of this to the above documentation, as I feel one would not expect this to be case otherwise.

I would be glad to do this myself if indeed needed.
Repository: terminal
Issue: Using `--window` in a `wt` action should do what you'd expect
Labels: Help Wanted,Product-Terminal,Issue-Task,Needs-Tag-Fix,Area-CmdPal,Area-Remoting

(from 1:1)

right now, `TerminalPage::_HandleExecuteCommandline`/`TerminalPage::ConvertExecuteCommandlineToActions` just tries to get the actions from the commandline, and tries to execute them. It would be _really neat_ if we could determine that `--window _quake` was passed in that commandline, and toss the actions to the window you'd expect. 

If there's no provided `--window`, then just execute the commandline in the current window. Otherwise, send the commandline to the monarch, and let them deal with it.

That would mean the command palette could get this functionality for commandline mode as well.
Repository: material-ui
Issue: Error displaying the current focus of the MenuItem that is selected in a Select (Firefox 88.0.1)
Labels: bug 🐛,component: select

Seen in my own Project and it happened on: [Material Ui Next Selects Page](https://next.material-ui.com/components/selects/)

Reproduce:
1. Click on the Select. (The Menu should drop down)
2. Start moving your choice with Arrow-Up and Arrow-Down (no Preview of the selection is shown)
3. press Space or Enter to select the active MenuItem (the Item that should be indicated, but it isn't right now)

(The Native Select seems to work and show the selection like expected, but all the other ones doesn't)

While playing around like this i don't got an stable behaviour to tell you more...
Repository: PowerToys
Issue: 建议新增全屏翻译功能/Add full-screen translation
Labels: Idea-New PowerToy

举个例子，例如华为手机的双指按压就能全屏翻译。我觉得实现这一点难度不大，OCR识别文字加翻译SDK即可实现，希望能新增此功能

The following translations are from Bing Translate:

For example, Huawei's two-finger press can translate full screen. I think it is not very difficult to achieve this, OCR recognition text then translation SDK can be achieved, I hope to add this feature
Repository: vscode
Issue: Align iconPath-API
Labels: api,debt

We have various definitions for `iconPath` properties and they all have different type signatures (no support ThemeIcon, no support for light/dark). We should always use the same OR-type sausage, ideally: `Uri | { light: Uri; dark: Uri } | ThemeIcon`. 

---

* [SourceControlResourceThemableDecorations#iconPath](https://github.com/microsoft/vscode/blob/eccf1354a9d22ca73619c4a1786f541dcbc27e58/src/vs/vscode.d.ts#L12317-L12317) @joao, @eamodio https://github.com/microsoft/vscode/issues/128258
* [CommentAuthorInformation#iconPath](https://github.com/microsoft/vscode/blob/eccf1354a9d22ca73619c4a1786f541dcbc27e58/src/vs/vscode.d.ts#L13340-L13340) @rebornix 
* [CommentReaction#iconPath](https://github.com/microsoft/vscode/blob/eccf1354a9d22ca73619c4a1786f541dcbc27e58/src/vs/vscode.d.ts#L13355-L13355) @rebornix 
* [WebViewPanel#iconPath](https://github.com/microsoft/vscode/blob/eccf1354a9d22ca73619c4a1786f541dcbc27e58/src/vs/vscode.d.ts#L7567-L7567)  #90616
Repository: go
Issue: net/http/pprof: assess and document security implications of the goroutines endpoint
Labels: Documentation,Security,NeedsFix,compiler/runtime

The net/http/pprof endpoints include stack traces with integer arguments, which can leak sensitive information depending on the settings. We should mention that in the docs.
Repository: pytorch
Issue: precision/consistency issue in `linspace`
Labels: triaged,module: numpy,module: numerical-reproducibility,module: tensor creation

## 🐛 Bug

`linspace(-77, 81, 31)[15]` should logically be exactly 2. numpy.linspace produces precisely 2 while torch.linspace produces 2 + epsilon. This occurs for both float32 and float64 dtypes.

## To Reproduce

```
import torch
import numpy

torch.set_printoptions(precision=30)
numpy.set_printoptions(precision=30)

print(numpy.linspace(-77, 81, 31)[15])
print(torch.linspace(-77, 81, 31, dtype=torch.float32)[15])
print(torch.linspace(-77, 81, 31, dtype=torch.float64)[15])
```

## Environment

Collecting environment information...
PyTorch version: 1.9.0a0+gitb7c0633
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 11.3.1 (x86_64)
GCC version: Could not collect
Clang version: 12.0.0 (clang-1200.0.32.29)
CMake version: version 3.19.6

Python version: 3.8 (64-bit runtime)
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.20.1
[pip3] numpydoc==1.1.0
[pip3] torch==1.9.0a0+git96d8c52
[conda] blas                      1.0                         mkl
[conda] mkl                       2021.2.0           hecd8cb5_269
[conda] mkl-include               2021.2.0           hecd8cb5_269
[conda] mkl-service               2.3.0            py38h9ed2024_1
[conda] mkl_fft                   1.3.0            py38h4a7008c_2
[conda] mkl_random                1.2.1            py38hb2f4e1b_2
[conda] numpy                     1.20.1           py38hd6e1bb9_0
[conda] numpy-base                1.20.1           py38h585ceec_0
[conda] numpydoc                  1.1.0              pyhd3eb1b0_1
[conda] torch                     1.9.0a0+git96d8c52           dev_0    <develop>


cc @mruberry @rgommers @heitorschueroff @gchanan
Repository: TypeScript
Issue: Allow reporting errors for unresolved @ link jsdoc tags
Labels: Suggestion,In Discussion

# Suggestion

## 🔍 Search Terms

- jsdoc
- `@link`

## ⭐ Suggestion

Add an option to report unresolved `@link` symbols in JSDoc comments. 

This can help catch some simple mistakes and also alert the user to cases where our IntelliSense doesn't understand the jsdocs symbol

## 📃 Motivating Example

```js
/**
 * {@link food} <- Should been an error here
 */
const foo = 12
```

## 💻 Use Cases
We'd use this in vscode for both our main codebase and for our `vscode.d.ts` file. 

I imagine this would also be quite useful for maintaining definitely typed 

## Related issues 
- #15852
Repository: TypeScript
Issue: Support IntelliSense while writing JSDoc @ link tags
Labels: Suggestion,Experience Enhancement

# Suggestion

## 🔍 Search Terms

- jsdoc
- `@link`
- suggest / suggestion
- complete / completions
- IntelliSense

## ⭐ Suggestion

Enable IntelliSense inside JSDoc  `@link` tags.

As precedent, we already support IntelliSense for `@param` parameters 

## 📃 Motivating Example

```js
/**
 * {@link } <- Trigger suggest here
 */
const foo = 12
```

## 💻 Use Cases

This would help significantly while writing `@link` tags