sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Godot appears to freeze after minimizing popup window
Labels: bug,topic:porting

### Tested versions

Reproducible in 4.2.stable

### System information

MacOS Big Sur v11.6 Mac mini (M1, 2020)

### Issue description

After minimizing a popup window and opening it again, Godot does not allow interaction, appearing to be frozen.

### Steps to reproduce

Create a new project
Project Settings > Input Map
Add an action
Hit the plus button to open Event Configuration menu
![Screen Shot 2024-05-08 at 9 37 44 AM](https://github.com/godotengine/godot/assets/16740469/a41d5d49-8662-45a9-ae19-55d8c8762f7c)
This collapses all of Godot instead of just that window, which is weird
Now the dock looks like this. You can see the collapsed Event Configuration window. But I can also bring Godot back up onto the screen by clicking on the app icon.
![Screen Shot 2024-05-08 at 9 39 49 AM](https://github.com/godotengine/godot/assets/16740469/4c8bef9b-2d2c-4ce2-a50a-54994a70e363)
If you click on the Event Configuration window, Godot opens back up and everything works fine. But if you click on the Godot app icon, Godot opens back up, but you cannot interact with anything. It looks like all the windows are present on the screen, so it looks like you should be able to interact, but if you look in the dock, you can see that the Event Configuration window is still minimized. Before I fully understood what was going on, I thought Godot was crashing/freezing. But now I understand it is some weirdness in the window management of Godot.
![Screen Shot 2024-05-08 at 9 49 30 AM](https://github.com/godotengine/godot/assets/16740469/2b547ddd-d49b-493c-8ca2-5c65e2a37b84)



I also just tested and discovered the same issue occurs if you try to minimize the Project Settings window and open Godot from the app icon. So it is not a problem specifically with the Event Configuration window or Input Mapping. It is a problem with Godot's window management on Mac.

I also just tested the same process on Windows 10 running 4.2.stable and minimizing a popup window doesn't have the exact same behavior as it does on Mac - it doesn't close all of Godot, but it creates a similar problem where if I forget that I minimized a window then Godot seems frozen because I can't interact with anything and I can only get the popup window back by collapsing all of Godot and reopening it by clicking on the app icon.

Please let me know if you have any questions.

### Minimal reproduction project (MRP)

A brand new godot project is sufficient for reproducing this error.
Repository: tauri
Issue: [bug] socket.io not work in production mode
Labels: type: bug,status: needs triage

### Describe the bug

When I'm in development mode the socket.io client works fine, but when I build it it doesn't work
Repository: transformers
Issue: Add TableTransformerImageProcessor
Labels: Good First Issue,Feature request,Vision

### Feature request

The [Table Transformer](https://huggingface.co/docs/transformers/main/en/model_doc/table-transformer) is a model with basically the same architecture as [DETR](https://huggingface.co/docs/transformers/main/en/model_doc/detr).

Now, when people do this:
```
from transformers import AutoImageProcessor

processor = AutoImageProcessor.from_pretrained("microsoft/table-transformer-detection")
print(type(processor))
```
this will print `DetrImageProcessor`.

However, Table Transformer has some specific image processing settings which aren't exactly the same as in DETR:
```
from torchvision import transforms

class MaxResize(object):
    def __init__(self, max_size=800):
        self.max_size = max_size

    def __call__(self, image):
        width, height = image.size
        current_max_size = max(width, height)
        scale = self.max_size / current_max_size
        resized_image = image.resize((int(round(scale*width)), int(round(scale*height))))
        
        return resized_image

# this is required for the table detection models
detection_transform = transforms.Compose([
    MaxResize(800),
    transforms.ToTensor(),
    transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225])
])

# this is required for the table structure recognition models
structure_transform = transforms.Compose([
    MaxResize(1000),
    transforms.ToTensor(),
    transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225])
])
```
Hence we could create a separate `TableTransformerImageProcessor` which replicates this.

### Motivation

Would be great to 100% replicate original preprocessing settings

### Your contribution

I could work on this but would be great if someone else can take this up
Repository: pytorch
Issue: RFC: Integrate Arm Compute Library (ACL) into PyTorch as a submodule and add build support in setup.py
Labels: module: build,triaged,enhancement,needs design,module: arm

## Issue description

For aarch64 linux platform, Arm Compute Library ([ACL](https://github.com/ARM-software/ComputeLibrary)) is the recommended GEMM backend for PyTorch via MKLDNN. Currently ACL is an out of the tree module and is cloned and included into the builds as a separate build stage. This approach is posing challenges with
1. keeping the ACL version in sync with oneDNN version
2. Updating ACL version in multiple scripts: CI scripts and CD scripts independently and manually

So, the suggestion is to make ACL as a submodule in PyTorch and add build support in `setup.py`

## System Info
Platform: aarch64 linux
OS: ubuntu



cc @malfet @seemethere
Repository: rust
Issue: out of memory
Labels: I-crash,P-medium,regression-from-stable-to-stable,I-compilemem,C-bug

<!--
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.
-->

Unfortunately there is no kind of error or warning given by rustc, it just OOMs right away :/

I tried this code:

```rust
trait Default {
    type Id;

    fn intu(&self) -> &Self::Id;
}

impl<T: Default<Id = U>, U: Copy> Default for U {
    default type Id = T;
    fn intu(&self) -> &Self::Id {
        self
    }
}

fn specialization<T>(t: T) -> U {
    *t.intu()
}

use std::num::NonZero;

fn main() {
    let assert_eq = NonZero::<u8, Option<NonZero<u8>>>(0);
    assert_eq!(specialization, None);
}

```

I expected to see this happen: *explanation*

Instead, this happened: *explanation*

### 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.
-->

`rustc --version --verbose`:
```
rustc 1.80.0-nightly (faefc618c 2024-05-07)
binary: rustc
commit-hash: faefc618cf48bd794cbc808448df1bf3f59f36af
commit-date: 2024-05-07
host: x86_64-unknown-linux-gnu
release: 1.80.0-nightly
LLVM version: 18.1.4
```
Repository: next.js
Issue: Inconsistent behavior for usePathname between local and deployed (on Vercel)
Labels: bug

### Link to the code that reproduces this issue

https://github.com/mastoj/usepathname-sample

### To Reproduce

1. Go to https://usepathname-sample.vercel.app (deployed app on Vercel)
2. Note the href value of the green link.
3. Clone repo
4. npm run dev
5. Go to https://localhost:3000
6. Note the href value of the green link.

### Current vs. Expected behavior

The href differ between the local version and deployed version, and I expected them to not differ. 

The version I expected was the one running locally, but the biggest issue in my opinion is the inconsistencies between local and production on vercel in this case.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:49 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6020
  Available memory (MB): 65536
  Available CPU cores: 12
Binaries:
  Node: 18.17.0
  npm: 9.6.7
  Yarn: 1.22.21
  pnpm: 8.6.10
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Which stage(s) are affected? (Select all that apply)

Vercel (Deployed)

### Additional context

_No response_
Repository: pytorch
Issue: Method for loading a distributed checkpoint into a single state_dict is being deprecrated without alternative, request to make it possible to keep that feature
Labels: oncall: distributed,triaged,oncall: distributed checkpointing

### 🚀 The feature, motivation and pitch

torch.distributed.checkpoint.state_dict_loader.load_state_dict() is being [deprecated](https://github.com/pytorch/pytorch/blob/main/torch/distributed/checkpoint/state_dict_loader.py#L28), but the alternative (`load()` in the same file) doesn't offer a way to load a distributed checkpointing in unsharded form while still in distributed mode (there is no `no_dist` arg). I think an obvious usecase is to do this at the end of training.



### Alternatives

_No response_

### Additional context

_No response_

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang @d4l3k
Repository: deno
Issue: support npm:dd-trace
Labels: node compat

ref https://github.com/denoland/deno/issues/7010

TODO:
- [x] https://github.com/denoland/deno/issues/24060
- [x] https://github.com/denoland/deno/issues/24059
- [ ] https://github.com/denoland/deno/issues/24231

Minimal example to run dd-trace: https://github.com/satyarohith/deno_dd_trace
Repository: go
Issue: go/types, x/tools: help tool authors support the new go/types.Alias node
Labels: NeedsFix,early-in-cycle

Following up on https://github.com/golang/go/issues/46477#issuecomment-2101270785, this umbrella issue tracks additional actions we can take to help tool authors support the new go/types.Alias node. We've learned a lot from our work on #64581, and   should share this knowledge:

- [ ] Propose an x/exp/aliases transitional package based on [x/tools/internal/aliases](https://pkg.go.dev/golang.org/x/tools/internal/aliases@master). We did something similar for generics in #50447.
- [ ] Write a guide for updating alias support. Again, we did [something similar for generics](https://github.com/golang/exp/tree/master/typeparams/example).
- [ ] In the Go 1.23 release notes, ensure that the change to the gotypesalias GODEBUG flag is documented with instructions for tool authors to set gotypesalias=0.
- [ ] Reach out to authors of popular open source tools that may be affected.

(anyone is welcome to suggest more actions we can take)

CC @adonovan @timothy-king
Repository: next.js
Issue: default.tsx parallel routes are using the loading.tsx from the parent route instead of the one from the parallel route
Labels: bug,Parallel & Intercepting Routes

### Link to the code that reproduces this issue

https://github.com/nuclei272/parallel-route-loading-ui-bug

### To Reproduce

1. Go to `https://codesandbox.io/p/github/nuclei272/parallel-route-loading-ui-bug/main`.
2. Click on the button to navigate to "/comments" route.
3. Click on the button to do a hard refresh.

### Current vs. Expected behavior

When you click to hard refresh, you'll see that the header and sidebar parallel routes (`@header` and `@sidebar`) will incorrectly displays "Loading Children...", which is the loading.tsx on the parent route `/`. The children page displays the loading.tsx correctly and the route `/comments` is also displaying it correctly.

The expected behaviour would be to loading the corresponding loading.tsx on `@header` and `@sidebar` parallel routes as seen when we first load the page on the root route `/`.

### Provide environment information

```bash
Operating System:
  Platform: win64
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 15694
  Available CPU cores: 4
Binaries:
  node: 21.2.0
  yarn: 1.22.21
Relevant Packages:
  next: 14.3.0-canary.49 // Latest available version is detected (14.3.0-canary.49).
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Parallel & Intercepting Routes

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed), Other (Deployed)

### Additional context

_No response_
Repository: stable-diffusion-webui
Issue: [Bug]: In Img2img Scale Factor of 1 working different than higher factors producing slow results
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [ ] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

A scale factor of 1 causes the second phase of the process to be much higher than the steps specified in the img2img, with 9 steps for a 1024x1024 image this is increased to 81 in the second step, 512x512 set for the tile size of ESRGAN, the img2img resolution is set to 1024x1024. After this phase finishes, a third phase emerges with thousands of steps required, requiring multiple minutes for this phase.


### Steps to reproduce the problem

1. Create an image that's 512x512..
2. Highres upscale it to 1024x1024 with ESRGAN 4x+ Anime6B.
3. Send to img2image tab.
4. Select SD Upscale in scripts.
5. Set model to ESRGAN 4x+ Anime6B.
6. Set scale factor to 1.
7. Adjust settings to match VRAM, optimally set image height and width to 1024x1024.
8. Run the generation.

### What should have happened?

The image should be produced with the same amount of steps as any other scale factor.

### What browsers do you use to access the UI ?

Mozilla Firefox

### Sysinfo

[sysinfo-2024-05-08-20-43.json](https://github.com/AUTOMATIC1111/stable-diffusion-webui/files/15254581/sysinfo-2024-05-08-20-43.json)


### Console logs

```Shell
SD upscaling will process a total of 4 images tiled as 2x2 per upscale in a total of 4 batches.
tiled upscale: 100%|█████████████████████████████████████████████████████████████████████| 9/9 [00:31<00:00,  3.55s/it]
tiled upscale: 100%|███████████████████████████████████████████████████████████████████| 81/81 [04:40<00:00,  3.46s/it]
tiled upscale:   1%|▎                                                               | 6/1089 [00:20<1:02:19,  3.45s/it]
```


### Additional information
Changing scale factor to 1.001 provides a temporary fix for this problem.
_No response_
Repository: node
Issue: Since v20.13.0 fetch() ing small files without reading their body delays process termination for 8 seconds
Labels: fetch,v20.x

### Version

v20.13.0

### Platform

Linux 33f5daf61896 6.4.16-linuxkit #1 SMP PREEMPT Thu Nov 16 10:49:20 UTC 2023 aarch64 GNU/Linux

### Subsystem

_No response_

### What steps will reproduce the bug?

```
docker run --rm -ti node:20.13.0 /bin/bash

 cat > test.js
async function main() {
  const x = await fetch ('http://cms6-sites.webhare.com/test-arnold/empty.docx');
  console.log(x);
}
main()

^D

node test.js
```

The node process will not terminate after downloading the document


### How often does it reproduce? Is there a required condition?

100%

### What is the expected behavior? Why is that the expected behavior?

Process should terminate

### What do you see instead?

Process does not terminate

### Additional information

- downgrading to 20.12.2 fixes the issue
- the reported uname above is on a Mac M3 with Linux inside docker, but I can reproduce it on native x86_64 linux hosts too
- it does not fail when the document is served under a different mimetype (eg try with http://cms6-sites.webhare.com/test-arnold/empty.docx)
- it also hangs when the URL is changed to https
- I can also reproduce it with other docx files

Edit: fixed version number where it still works, there is no 20.12.3, oops.
Repository: flutter
Issue: [camera_android_camerax] Implement `setDescriptionWhileRecording`
Labels: c: new feature,platform-android,p: camera,package,P3,team-android,triaged-android

The method `setDescriptionWhileRecording` was added in https://github.com/flutter/packages/commit/62dd1ed88200c858e638f7776879cc70aab13926 to allow switching cameras while recording video and is currently only implemented in `camera_android`. This method needs to be implemented in the `camera_android_camerax` camera plugin implementation.

Blocked by https://b.corp.google.com/issues/330136198
Repository: TypeScript
Issue: Rename symbol weirdness with typescript type properties
Labels: Bug,Help Wanted

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.89.0
- OS Version: Windows 10

Steps to Reproduce:

Case A (working)
```ts
// caseA.ts
type a = {
  A: 0;
};

type b = a["A"];
```
1. Click on `A` (in `a["A"]`), press F2 and rename to `f`
2. `A` is renamed in both places

Case B (broken)

```ts
// a.ts
export type a = {
  A: 0;
};
```
```ts
// caseB.ts
import { a } from "./a.ts";

type b = a["A"];
```
1. Click on `A` (in `a["A"]`), press F2 and rename to `f`
2. `A` is renamed in `a.ts`, but not in `caseB.ts`

Case C (working)
```ts
// caseC.ts
import { a } from "./a.ts";

type b = a["A"];

type A = "whatever";
```
1. Click on `A` (in `a["A"]`), press F2 and rename to `f`
2. `A` is renamed in both places
Repository: pytorch
Issue: [BE][DTensor] get rid of @with_comms decorator for tests, and use run_test to init pg
Labels: oncall: distributed,triaged,better-engineering

as titled, we should get rid of the with_comms decorator https://github.com/pytorch/pytorch/blob/main/torch/testing/_internal/distributed/_tensor/common_dtensor.py#L355

Instead, init and destroy the pg by overriding `_run` classmethod. Example https://github.com/pytorch/pytorch/blob/main/torch/testing/_internal/common_fsdp.py#L1060

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang @d4l3k
Repository: go
Issue: proposal: structs: add NoUnkeyedLiterals, DoNotImplement, DoNotCompare, DoNotCopy
Labels: Proposal

### Proposal Details

#66408 has been accepted and will add a new struct package in the standard library.

There are  few other marker types we should consider to add to this structs package: namely
```go
package structs

type NoUnkeyedLiterals struct{}
type DoNotImplement interface{
    DoNotImplementInternal(DoNotImplement) 
}
type DoNotCompare [0]func()
type DoNotCopy [0]sync.Mutex
```

These are actually pretty common since the Go protobuf code uses this kind of pseudo directives: https://github.com/protocolbuffers/protobuf-go/blob/master/internal/pragma/pragma.go 
The Go protobuf generator includes these in all types generated so they should make up a significant part of the Go corpus.

Furthermore as shown in #67196 currently the lack of these marker types lessens the readability of Go code. There are likely many Go projects that could use these marker types.So I think they will pass the bar of being common enough to be included in the standard library. Adding them to the standard library also allows to improve go vet detection in the case of DoNotCopy.

So please consider adding them.
Repository: create-react-app
Issue: CRA fails with npm error in yarn project using "workspace:" dependencies
Labels: needs triage,issue: bug report

### Describe the bug

In a `yarn` project, when CRA gets to the "Installing template dependencies using npm..." part, it uses, well, npm.

`npm` seems unable to understand dependencies of the form 
```json
    "module": "workspace:*"
```
in `package.json`.

```
yarn dlx create-react-app appname  #same problem using npx
``` 
fails when run in a project with such `workspace:*` dependencies.

In a multi-workspace project,  CRA seems to process all the peer-level workspaces (via `npm` despite the fact that it is running in a `yarn` project). `npm` encounters dependencies of that `workspace:*` form, and errors out with 

```
npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "workspace:": workspace:*
```

### Environment

```
$ npx create-react-app --info

  System:
    OS: macOS 14.4.1
    CPU: (10) arm64 Apple M1 Max
  Binaries:
    Node: 20.12.2 - ~/.nvm/versions/node/v20.12.2/bin/node
    Yarn: 4.2.2 - ~/.nvm/versions/node/v20.12.2/bin/yarn
    npm: 10.5.0 - ~/.nvm/versions/node/v20.12.2/bin/npm
  Browsers:
    Chrome: 124.0.6367.119
    Edge: Not Found
    Safari: 17.4.1
  npmPackages:
    react:  18.3.1 
    react-dom:  18.3.1 
    react-scripts:  5.0.1 
  npmGlobalPackages:
    create-react-app: Not Found
```


### Steps to reproduce
File hierarchy:

```
package.json
workspace1
    package.json
workspace2
    package.json
```

top-level `package.json`:
```
{
  "name": "cra-yarn",
  "packageManager": "yarn@4.2.2",
  "workspaces": [
    "workspace1",
    "workspace2",
    "cra"
  ]
}
```

`workspace1/package.json`:
```
{
  "name": "workspace1",
  "packageManager": "yarn@4.2.2",
  "dependencies": {
    "workspace2": "workspace:*"
  }
}
```

`workspace2/package.json`:
```
{
  "name": "workspace2",
  "packageManager": "yarn@4.2.2"
}
```

Run `yarn` in the top level directory, then execute:
```sh
npx create-react-app cra
```

### Expected behavior

Create an app in the `cra` subdirectory with no errors.

### Actual behavior

```sh
$ npx create-react-app cra   # similarly for yarn dlx create-react-app cra

Creating a new React app in /path/to/tmp/cra-yarn/cra.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...

npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "workspace:": workspace:*
```

When you run using `yarn dlx`, you'll see:
```
Installing template dependencies using npm...
npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "workspace:": workspace:*
```

Note that the `package.json` files declare that they use `yarn`. So it would make sense for the "nstalling template dependencies" action also to use `yarn`?

### Reproducible demo

I'm attaching an archive with the above files.
[cra-yarn.tar.gz](https://github.com/facebook/create-react-app/files/15255872/cra-yarn.tar.gz)