sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Deleting a resources in FileSystem doesn't remove references to it
Labels: bug,topic:editor

### Godot version

v4.1.beta.custom_build [01453ab7f]

### System information

macOS 13.3.0 - Vulkan (Forward+) - integrated Apple M1 Pro - Apple M1 Pro (8 Threads)

### Issue description

When deleting a resource from the FilesSystem dock. The resource won't be removed from scenes but won't immediately be saved internally. As a workaround if the scene is opened you can save it immediatelly before closing but it won't warn you when closing that there are unsaved action. 
This will lead to multiple type of errors varying from `cannot open resource` or `cannot find script` to `cannot open scene`or even in the worst cases to outright crashes like in here (#78238)


### Steps to reproduce

Here is what happen for script 
1. Create a scene with one nodes
2. attach a script to the root 
4. Save the scene
5. Delete the script 
6. click on the script it will show as `[unsaved]` trying to save the script (not the scene) won't work
7. close the scene and it won't tell you you have something to save
8. reopen the scene now it will state he couldn't find the script.

For ressources it will be a bit different : 
1. Create a scene with one nodes
2. attach a script to the root exporting a resource
3. create a resource and save it on disk
4. Save the scene
5. delete the resource
7. click on the script it will show that there is no resource path meaning it hasn't been saved inside the scene 
8. close the scene and it won't tell you you have something to save
9. try to reopen the scene and it will fail because of missing resources
### Minimal reproduction project

with the MRP you can start reproduction steps at the sixth step.
[Test.zip](https://github.com/godotengine/godot/files/11749747/Test.zip)


Edit : separated the crash from the rest of the bug as even we handle correctly how we delete a resource in FileSystem. The crash seems to come from `Array[Node]` specifics
Repository: electron
Issue: [Bug]: showSaveDialog without filters, changing name on windows drops extension
Labels: platform/windows,bug :beetle:,component/dialog,status/confirmed,has-repro-gist,25-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

25.1.0

### What operating system are you using?

Windows

### Operating System Version

Windows 10, version 19041.1415

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

```js
const { filePath } = await dialog.showSaveDialog({ defaultPath: "change-me.txt" })
// presented as "change-me" -- change to "updated-name"
console.log(filePath) // >> "updated-name.txt"
```

### Actual Behavior

```js
const { filePath } = await dialog.showSaveDialog({ defaultPath: "change-me.txt" })
// presented as "change-me" -- change to "updated-name"
console.log(filePath) // >> "updated-name" (no extension)
```

### Testcase Gist URL

https://gist.github.com/jamiebuilds/4731be0aa643774a71e4543a572f753f

### Additional Information

- It's not always possible to create a filter for every possible file extension you could be saving
- It's difficult to deal with paths like `.tar.gz` in user land
Repository: go
Issue: all: announce end of support for old Linux versions
Labels: Documentation,Builders,NeedsFix,release-blocker,recurring

New Linux versions get released over time, and old ones cannot be supported indefinitely. This is the tracking recurring issue for announcing end of support for very old versions that we decide to drop support for. (The corresponding tracking issues for macOS and Windows, the other two OSes that have [first class ports](https://go.dev/wiki/PortingPolicy#first-class-ports), are #23011 and #52188.)

The most recent change was applied in Go 1.18, where proposal #45964 increased the minimum Linux kernel version requirement from 2.6.23 to 2.6.32. See https://go.dev/doc/go1.18#linux.

CC @golang/release.
Repository: pytorch
Issue: Installing Torch on AMD Platform Leads to Huge Docker Image
Labels: module: rocm,triaged

### 🐛 Describe the bug

I am not sure this is the best place to raise this issue and I am not sure "bug" is the best characterization, but I found some unexpected behavior when installing pytorch in docker images built for different platforms. In particular, when I install torch in an image built for the `linux/arm64` platform I get an image that is 628MB, but when I install torch in an image built for the `linux/amd64` platform I get an image that is 6.87GB. Ideally the image would be a similar size for both platforms because the large images are slow to build/push/pull.

Here is my `Dockerfile`:
```
FROM python:3.11.2-slim-bullseye
ENV DEBIAN_FRONTEND=noninteractive
RUN pip3 install torch==2.0.0
```

Here are the docker build commands I ran:
```
docker build --platform linux/amd64 -t amd_build -f Dockerfile .
docker build --platform linux/arm64 -t arm_build -f Dockerfile .
```

And here you can see the resulting image sizes:
```
REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
amd_build    latest    6a5b409f32bf   27 minutes ago   6.87GB
arm_build    latest    1fc9604a61f3   35 minutes ago   628MB
```

### Versions

Note: Some of this information may not be relevant because the issue I am raising happens in docker.

Collecting environment information...
PyTorch version: 2.0.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.4 (arm64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: Could not collect
Libc version: N/A

Python version: 3.11.3 (main, Apr  7 2023, 20:13:31) [Clang 14.0.0 (clang-1400.0.29.202)] (64-bit runtime)
Python platform: macOS-13.4-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
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
Is XNNPACK available: True

CPU:
Apple M1 Pro

Versions of relevant libraries:
[pip3] numpy==1.24.2
[pip3] torch==2.0.0
[conda] Could not collect

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo
Repository: go
Issue: os/exec: TestContextCancel failures on plan9/amd64
Labels: OS-Plan9,NeedsInvestigation

```
#!watchflakes
post <- goos == "plan9" && pkg == "os/exec" && test == "TestContextCancel"
```

The builder for plan9/amd64 fails e.g. with ([log](https://build.golang.org/log/a5c1a8af5e8663c1898258ab27ea449fd9237c9b)):

```
--- FAIL: TestContextCancel (60.31s)
panic: canceling context did not stop program [recovered]
	panic: canceling context did not stop program

goroutine 40 [running]:
panic({0x4ea3c0?, 0x5df740?})
	/tmp/workdir-gnot/go/src/runtime/panic.go:1017 +0x3a6 fp=0x480bfb88 sp=0x480bfad8 pc=0x237006
testing.tRunner.func1.2({0x4ea3c0, 0x5df740})
	/tmp/workdir-gnot/go/src/testing/testing.go:1545 +0x26f fp=0x480bfc38 sp=0x480bfb88 pc=0x2e234f
testing.tRunner.func1()
	/tmp/workdir-gnot/go/src/testing/testing.go:1548 +0x39d fp=0x480bfda0 sp=0x480bfc38 pc=0x2e1dbd
runtime.deferCallSave(0x480bfe58, 0x48149f90?)
	/tmp/workdir-gnot/go/src/runtime/panic.go:798 +0x84 fp=0x480bfdb0 sp=0x480bfda0 pc=0x236be4
runtime.runOpenDeferFrame(0x4801ef50)
	/tmp/workdir-gnot/go/src/runtime/panic.go:771 +0x1b8 fp=0x480bfdf0 sp=0x480bfdb0 pc=0x236a18
panic({0x4ea3c0?, 0x5df740?})
	/tmp/workdir-gnot/go/src/runtime/panic.go:914 +0x213 fp=0x480bfea0 sp=0x480bfdf0 pc=0x236e73
os/exec_test.TestContextCancel(0x4816ab60)
	/tmp/workdir-gnot/go/src/os/exec/exec_test.go:1006 +0x40f fp=0x480bff70 sp=0x480bfea0 pc=0x4c2b2f
```

It can be reproduced with

```
go test -v '-test.count=10' -test.run TestContextCancel
```

(At least the first test passes though)

It seems that the process isn't fully ready when `cancel()` gets called. ([exec_test.go](https://github.com/golang/go/blob/0a48e5cbfabd679eecdec1efa731692cd6babf83/src/os/exec/exec_test.go#L986-L991)) One option could be to also read from stdout - although `time.Sleep(time.Millisecond)` seems to solve it as well.
Repository: go
Issue: cmd/go: `go list` has confusing/inconsistent semantics for Match and DepOnly
Labels: NeedsInvestigation,GoCommand

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.20.5 linux/amd64
</pre>

(Also reproduced at HEAD.)

### Does this issue reproduce with the latest release?

Yes.

### What did you do?

```
$ cd $GOROOT/src
$ go list -deps -test -f '{{.ImportPath}} {{.DepOnly}} {{.Match}}' ./... | grep 'context\.test'
context [context.test] false [./...]
runtime/trace [context.test] true [./...]
testing [context.test] true [./...]
os/exec [context.test] true [./...]
internal/fuzz [context.test] true [./...]
os/signal [context.test] true [./...]
runtime/pprof [context.test] true [./...]
testing/internal/testdeps [context.test] true [./...]
net [context.test] true [./...]
context_test [context.test] false []
context.test false []
```

### What did you expect to see?

The documentation for DepOnly and Match is:

```
        Match          []string // command-line patterns matching this package
        DepOnly        bool     // package is only a dependency, not explicitly listed
```

It's not clear whether packages built on behalf of tests "match" the pattern, but the output seems clearly inconsistent in some ways:

1. Given that `context.test` has DepOnly == false, that implies cmd/go does think of `context.test` as "explicitly listed" by `./...`. It also clearly thinks of, say, `net` as "explicitly listed" by `./...`. So it seems odd that `net [context.test]` (and several others) have DepOnly == true, indicating that they're not "explicitly listed".
2. Based on the documentation, I would expect that, if DepOnly == true, then it's "not explicitly listed", so Match should be empty because it didn't match any patterns. And if DepOnly == false, then it is "explicitly listed", and Match should list at least one pattern. For example, `context.test` is "explicitly listed", yet cmd/go can't tell me what pattern it matched.

### What did you see instead?

DepOnly is true for some of these and false for others in ways I can't rationalize.

For some packages, DepOnly == true, but a Match pattern is also listed.

For some packages, DepOnly == false, but a Match pattern is listed.
Repository: pytorch
Issue: ARM based GPU support for Distributed Data Parallelism Module
Labels: oncall: distributed

### 🚀 The feature, motivation and pitch

I'm working on building a self driving model for electric race cars and would love to be able to use the full power of my ARM based GPUs for training. I know that this is being worked on but I can't find anything related to allowing Distributed training using multiple ARM based GPUs.  I see this being huge for a lot of developers as ARM based chips are only becoming more and more popular as they are cost effective and efficient. I also recognize that there is already support for ARM based GPUs but not in a distributed fashion. If I am incorrect please let me know and provide me with an example if you can. 

### Alternatives

An alternative would be to provide more documentation on the PyTorch DistributedDataParallel module regarding ARM based chips. Making it abundantly clear that this module is developed solely for use with NVIDIA GPUs. This would prevent futile efforts to making it work. 

### Additional context

_No response_
```[tasklist]
### Tasks
```


cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Repository: next.js
Issue: router.refresh isn't working when intercepting routes
Labels: linear: next,Parallel & Intercepting Routes

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: linux
      Arch: x64
      Version: #22 SMP Tue Jan 10 18:39:00 UTC 2023
    Binaries:
      Node: 18.14.2
      npm: 9.5.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.4.4
      eslint-config-next: 13.4.4
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.0.4
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true)

### Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/sleepy-violet-84j988?file=%2Fapp%2F%40modal%2F%28.%29login%2Fpage.tsx%3A8%2C32

### To Reproduce

Click the "Refresh" button, it should refresh and show a new random number, but it doesn't

### Describe the Bug

Is not refreshing when using intercepting routes feature

### Expected Behavior

To refresh and get a new random number

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

<sub>[NEXT-1845](https://linear.app/vercel/issue/NEXT-1845/routerrefresh-isnt-working-when-intercepting-routes)</sub>
Repository: pytorch
Issue: DISABLED test_backward_ddp_outside (__main__.TensorPipeDdpUnderDistAutogradTest)
Labels: oncall: distributed,module: flaky-tests,skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_backward_ddp_outside&suite=TensorPipeDdpUnderDistAutogradTest) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/14264987221).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 3 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_backward_ddp_outside`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `distributed/rpc/test_tensorpipe_agent.py`

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Repository: react-native
Issue: Animated tracking using the native driver does not work as expected
Labels: Issue: Author Provided Repro,API: Animated,Needs: Triage :mag:

### Description

Tracking a dynamic animated value (such as scroll position) using the native driver doesn't work correctly. Instead of animating the pinned value simultaneously, the animation only starts once the dynamic value stops changing.

### React Native Version

0.71.11

### Output of `npx react-native info`

```
System:
    OS: macOS 13.2.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 81.73 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.18.1 - ~/.nvm/versions/node/v16.18.1/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v16.18.1/bin/npm
    Watchman: 2022.11.07.00 - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
    Android SDK: Not Found
  IDEs:
    Android Studio: Not Found
    Xcode: 14.3.1/14E300c - /usr/bin/xcodebuild
  Languages:
    Java: Not Found
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0 
    react-native: 0.71.11 => 0.71.11 
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

```

### Steps to reproduce

I have created an example app that illustrates the problem.

1. Clone the repository from https://github.com/kolking/animated-tracking, install and run the app in the simulator.
2. When the native driver is disabled, scroll the bottom part horizontally to see how red dots follow the scroll position with a stagger effect.
3. Now, in the `App.tsx` change the `NATIVE_DRIVER` constant to `true`, reload the app and try scrolling the bottom part again.

### Snack, code example, screenshot, or link to a repository

Also please take note that when the native driver is enabled, it ignores the initial `contentOffset`. As a result, the red dots are initially displayed on the left and will only move to the center after a manually triggered scroll event.

`useNativeDriver: false` | `useNativeDriver: true`
---|---
<video src="https://github.com/kolking/animated-tracking/assets/4656448/46de74f5-4a8d-47aa-a256-5f787b710418"> | <video src="https://github.com/kolking/animated-tracking/assets/4656448/cca8d9f8-12db-43af-b335-35598930662a">
Repository: create-react-app
Issue: The development proxy doesn't work with "type": "module"
Labels: needs triage,issue: bug report

### Describe the bug

When I start my project with `npm start` the application starts fine but I can't connect to the server due to the connection refused error.

The problem is that when `setupProxy.js` is present and there is `"type": "module"` in package.json, the web server fails to start without giving any error message.

I discovered this error by placing a breaking on [webpackDevServer.config.js:120](https://github.com/facebook/create-react-app/blob/0a827f69ab0d2ee3871ba9b71350031d8a81b7ae/packages/react-scripts/config/webpackDevServer.config.js#L120).

```
Error [ERR_REQUIRE_ESM]: require() of ES Module P:\<project>\src\setupProxy.js from P:\<project>\node_modules\react-scripts\config\webpackDevServer.config.js not supported.
```

I fixed it by switching back to commonjs, but it wasn't easy to detect this problem.

It would be nice to have more logs on what goes on under the hood so new users don't fall into the same trap

### Did you try recovering your dependencies?

Yes, I deleted node_modules and reinstalled everything from scratch.

### Which terms did you search for in User Guide?

`ERR_CONNECTION_REFUSED` and `setupProxy.js`

### Environment

```
P:\gpt\demo-app\my-app>npx create-react-app --info

Environment Info:

  current version of create-react-app: 5.0.1
  running from C:\Users\Alessandro\scoop\persist\nodejs\cache\_npx\c67e74de0542c87c\node_modules\create-react-app

  System:
    OS: Windows 10 10.0.19045
    CPU: (12) x64 Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
  Binaries:
    Node: 19.0.0 - ~\scoop\apps\nodejs\current\node.EXE
    Yarn: 1.22.19 - ~\scoop\apps\nodejs\current\bin\yarn.CMD
    npm: 9.4.2 - ~\scoop\apps\nodejs\current\bin\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Spartan (44.19041.1266.0), Chromium (114.0.1823.43)
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    react-scripts: 5.0.1 => 5.0.1
  npmGlobalPackages:
    create-react-app: Not Found
```

### Steps to reproduce

1. Create a new blank project with `npx create-react-app my-app`
2. Create a file `src/setupProxy.js` with this content (there is no need for a service on port 5000):

    ```js
    const { createProxyMiddleware } = require("http-proxy-middleware");
    
    module.exports = function (app) {
      // API proxy
      app.use(
        createProxyMiddleware("/api", {
          target: "http://127.0.0.1:5000",
          changeOrigin: true,
        })
      );
    };
    ```

4. Add `"type": "module"` in `package.json`
5. Start the application with `npm start`

### Expected behavior

The default page with "Learn React" should be visible.

### Actual behavior

The web server cannot be started without giving any relevant log message.

Chrome gives the error `ERR_CONNECTION_REFUSED`
Repository: go
Issue: syscall: strace hangs trying to trace call to Exec
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17.3 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/bkatkam/.cache/go-build"
GOENV="/home/bkatkam/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/bkatkam/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/bkatkam/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/ce/lang/go/1.17.3/build_0"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/ce/lang/go/1.17.3/build_0/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build467517364=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
<details><summary><code>my code</code> Output</summary><br><pre>
package main
import (
    "os"
    "syscall"
)
func main() {
    args := []string{"ls", "-ld"}
    env := os.Environ()
    syscall.Exec("/usr/bin/ls", args, env)
}
</pre></details>
When I run 'strace -f ./exec-ls' on this built executable,
with '-f' to follow sub-processes, strace is getting stuck.

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->

### What did you expect to see?
Expecting strace to run.


### What did you see instead?
strace getting stuck when -f option is used.
Repository: godot
Issue: Switching between gridmaps and other nodes causes selection to be incorrect when returning
Labels: bug,topic:editor,topic:3d

### Godot version

3.5.2.rc2

### System information

Windows 10

### Issue description

When switching between gridmap nodes, if the most recently chosen gridmap has fewer meshes in its MeshLibrary, returning to a previous gridmap node will result in the previously selected mesh being incorrect.

If switching between gridmaps, it will choose the highest possible mesh id in the previously selected gridmap node. If the gridmap meshlibrary ids are the same, it will retain the same chosen id.

If switching between gridmap nodes and, say, a spatial node, it seems to increase the selected meshlibrary id by 36 places. The shown chosen mesh id will be correct, but the actual mesh shown in the editor for placement is 36 places higher.

This fixed the error: https://github.com/godotengine/godot/pull/64188 but it seems to still be broken, ideally gridmaps would each store their own previously chosen mesh id and recall it when the gridmap node is selected.

### Steps to reproduce

Create two gridmaps and a spatial node.
Add many meshlibrary ids to one of the gridmaps and fewer to the other.
Observe the previously chosen mesh being incorrect unless the two gridmap mesh counts are identical.

### Minimal reproduction project

I'd need to make a special project for this as I'm working off my own huge game, but I can do if required.