sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Visual Studio Code Open File Dialog uses the wrong Display Settings
Labels: native-file-dialog

Type: <b>Bug</b>

On a 4k Monitor, use File -> Open File to open the Open File Dialog Box. The Open File dialog text and everything is super small and does not match the display settings of Visual Studio Code (Font Size, Aspect Ratio, etc). Everything is shrunk down and difficult to read. Note, the 4k monitor is not the primary monitor. Primary is 3440x1440. Visual Studio Code is maximized on the 4k monitor.

VS Code version: Code 1.89.1 (dc96b837cf6bb4af9cd736aa3af08cf8279f7685, 2024-05-07T05:13:33.891Z)
OS version: Windows_NT x64 10.0.19045
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i9-14900K (32 x 3187)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|undefined|
|Memory (System)|191.77GB (165.82GB free)|
|Process Argv|--crash-reporter-id befc7fff-822e-4dc1-8041-8b21d88a9e5d|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (17)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-intelephense-client|bme|1.10.4
vscodemq2|DeW|0.7.0
loretta-lua|lor|0.0.7
debugpy|ms-|2024.6.0
python|ms-|2024.6.0
vscode-pylance|ms-|2024.5.1
jupyter|ms-|2024.4.0
jupyter-keymap|ms-|1.1.2
jupyter-renderers|ms-|1.0.17
vscode-jupyter-cell-tags|ms-|0.1.9
vscode-jupyter-slideshow|ms-|0.1.6
remote-wsl|ms-|0.88.2
cmake-tools|ms-|1.17.17
cpptools|ms-|1.20.5
cpptools-extension-pack|ms-|1.3.0
lua|sum|3.9.1
cmake|twx|0.0.17

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
tftest:31042121
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialogc:30910334
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pythonmypyd1:30879173
pythoncet0:30885854
h48ei257:31000450
pythontbext0:30879054
accentitlementst:30995554
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
jchc7451:30973076
chatpanelt:31048053
dsvsc021:30996838
724cj586:31013169
pythoncenvptcf:31049071
fchga941:31046352
dvdeprecation:31040881
pythonprt:31047983
dwnewjupyter:31046869
26j00206:31048877

```

</details>

<!-- generated by issue reporter -->
Repository: pytorch
Issue: [DCP] DCP does not support objects which are lazy initialized.
Labels: triaged,enhancement,module: distributed_checkpoint,oncall: distributed checkpointing

### 🚀 The feature, motivation and pitch

DCP lacks support for objects which are lazy initialized. E.g.:

```
import copy
import torch.distributed.checkpoint as dcp
dl_state = {"dl_state": {"data": {"a": "b"}}}

checkpoint_id = "tmp_ckpt"
dcp.save(state_dict=dl_state, checkpoint_id=checkpoint_id)

# simulates an object which is lazy initialized (in this case 'data' does not exist)
dl_state_loaded = copy.deepcopy(dl_state)
dl_state_loaded["dl_state"].pop("data")
dcp.load(state_dict=dl_state_loaded, checkpoint_id=checkpoint_id)

print(dl_state_loaded)
assert "data" in dl_state_loaded and "a" in dl_state_loaded["data"]   # fails
```

Since lazy initialization is a fairly common practice (e.g. optimizers, dataloaders), this ends up being pretty problematic. Additionally, although we will save the entire state, DCP loads without any warning when keys exist in the serialized checkpoint but do not exist in the local state_dict. This can essentially be considered a 'silent failure to load', and is pretty confusing to users.

Proposal:

The main motivation for not supporting objects which are lazily initialized is that DCP loads modules 'in-place'. Essentially, if an object does not exist as part of the local state_dict, there is nothing for DCP to copy into, and thus those objects are ignored. 

An alternative is to assume if objects do not exist in the local state_dict, we should still make a best effort at loading the object by creating the object and inserting it into the local state dict. Additionally, we can add a configuration to optionally raise warnings for 'extra' keys.





### Alternatives

The alternative for this proposal is to force all users of DCP to avoid lazy initialization patterns. In the above example, we could recommend the entire "data" object should be serialized, and should exist as a bytes object at load (I'm going to admit this is a little hand-wavy, but that is the general idea). The important distinction is that the object would always exist and would be properly replaced at load time.

From a UX perspective I don't believe this is a good idea because:
a) Users should expect that a load api handles this case.
b) lazy initialization is a fairly common practice, and this behavior is fairly subtle and surprising to users (which means it's bad UX)

### Additional context

I'm not suggesting we do this as a replacement to the current lazy initialization logic in optimizers. This might be a step in the right direction for avoiding lazy initialization (or it could not be), but either way optimizers present additional complexity since currently they need to be sharded _before_ calling load. 

In practice, this doesn't really apply to most other objects such as dataloaders since the expectation is that if the object does support re-sharding then:
 a) they are either DTensors and exist before calling `dcp.load`
 b) manage their own sharding logic in `load_state_dict`
Repository: pytorch
Issue: Bug: `torch.func.jacrev` fails with backend=`aot_eager`
Labels: triaged,oncall: pt2,module: aotdispatch,module: pt2-dispatcher

### 🐛 Describe the bug

This is a follow-up to issue #125078, which addresses a bug in the AOT Autograd metadata analysis.

```python
import torch
from torch.func import jacrev

def func(x):
    two = 2.0
    return two * x

@torch.compile(backend='aot_eager')
def jac_func(x):
    return jacrev(torch.sin)(x)

x = torch.ones(3, dtype=torch.float64)
out = jac_func(x)
print(out)
```

`torch.func.jacrev` fails with `torch.compile(backend="aot_eager")` due to a bug in _vjp_with_argnum. The wrapper function in `_vjp_with_argnum` uses two variables from the outer scope: `flat_primals_out` and `flat_diff_primals`, that are wrapped in `GradTrackingTensors`.

These variables are only valid when the grad context manager is active, and as soon as they go out of scope, the wrapper metadata becomes garbage:

```python
(Pdb++) flat_primals_out
[GradTrackingTensor(lvl=-2, value=
    tensor([0.8415, 0.8415, 0.8415], dtype=torch.float64)
)]
(Pdb++) flat_diff_primals
[GradTrackingTensor(lvl=-2, value=
    tensor([1., 1., 1.], dtype=torch.float64)
)]
```

Notice the `lvl=-2` in both tensors. This doesn't seem to be a problem in eager mode, but it fails in aot_autograd (see traceback below) as the tensors do not get properly unwrapped in symbolic execution, given the invalid level:

```python
...
  File "/home/guilhermeleobas/git/pytorch/torch/_dynamo/utils.py", line 273, in time_wrapper
    r = func(*args, **kwargs)
  File "/home/guilhermeleobas/git/pytorch/torch/_functorch/aot_autograd.py", line 558, in create_aot_dispatcher_function
    fw_metadata = run_functionalized_fw_and_collect_metadata(
  File "/home/guilhermeleobas/git/pytorch/torch/_functorch/_aot_autograd/collect_metadata_analysis.py", line 654, in inner
    traced_tangents = pytree.tree_map(
  File "/home/guilhermeleobas/git/pytorch/torch/utils/_pytree.py", line 943, in tree_map
    return treespec.unflatten(map(func, *flat_args))
  File "/home/guilhermeleobas/git/pytorch/torch/utils/_pytree.py", line 782, in unflatten
    leaves = list(leaves)
  File "/home/guilhermeleobas/git/pytorch/torch/_functorch/_aot_autograd/collect_metadata_analysis.py", line 626, in view_avoid_dupes_with_primals
    return t.view(t.shape)
  File "/home/guilhermeleobas/git/pytorch/torch/_subclasses/functional_tensor.py", line 166, in __torch_dispatch__
    raise RuntimeError(
torch._dynamo.exc.BackendCompilerFailed: backend='aot_eager' raised:
RuntimeError: Attempting to use FunctionalTensor on its own. Instead, please use it with a corresponding FunctionalTensorMode()
```

For reference, see the relevant code
https://github.com/pytorch/pytorch/blob/86ad101370075cfa392c953b17e1a8ab3e66881f/torch/_functorch/eager_transforms.py#L426-L438

### Versions

main

cc @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang @zou3519
Repository: next.js
Issue: [backport request] Backport fix of an already-fixed bug of next-swc
Labels: bug,SWC

### Link to the code that reproduces this issue

https://stackblitz.com/edit/nextjs-wzyqzn?file=app%2Fpage.tsx

### To Reproduce

just open the [stackblize online reproduce](https://stackblitz.com/edit/nextjs-wzyqzn?file=app%2Fpage.tsx)

### Current vs. Expected behavior

```ts
class Father {
  static instance = {};

  static register() {
    return (target) => {
      class Wrapper extends target {
        constructor(props) {
          super({
            ...props,
          });
        }
      }

      this.instance = new Wrapper();
    };
  }

  private _a = 1;

  constructor() {
    this._a = 2;
  }
}

@Father.register()
class Son {}

console.log(Father.instance._a); // 1, but why ???
```

<img width="1509" alt="image" src="https://github.com/vercel/next.js/assets/41773861/903141ec-3e34-47ee-bcf0-ae6268490979">


<img width="1503" alt="image" src="https://github.com/vercel/next.js/assets/41773861/dcf5bc49-3dd9-4d72-a468-27c758ae1009">


## expect

should compile correct

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: Ubuntu 20.04.0 LTS Wed May 22 2024 23:45:04 GMT+0800 (中国标准时间)
Binaries:
  Node: 18.20.3
  npm: 10.2.3
  Yarn: 1.22.19
  pnpm: 8.15.6
Relevant Packages:
  next: 14.1.0
  eslint-config-next: 13.5.1
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

SWC

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

The latest canary version fix this issue, but I can find a good way to fix it now. 

I want to use canary but it require react19.
I try use yarn1 resolution to lock the next swc version, but yarn1 seems can't correctly deal with resolution with optionalDependencies:

![image](https://github.com/vercel/next.js/assets/41773861/54102552-1ea6-4455-b46c-a871d5262d0a)

So, I thing the best method way to fix this is the nextjs official release a new 14.x version.

I think the compile error is a serious error and cost me one day to locate it.

more context:

1. https://x.com/YuTengjing/status/1793270230531395826
2. https://github.com/swc-project/swc/pull/8835
Repository: node
Issue: `node:test` custom reporters get `test:stdout` and `test:stderr` events before `test:dequeue`
Labels: test_runner

### Version

v22.2.0

### Platform

Linux 6a770f0f664c 6.6.26-linuxkit #1 SMP Sat Apr 27 04:13:19 UTC 2024 aarch64 GNU/Linux

### Subsystem

test_runner

### What steps will reproduce the bug?

Create a folder with these files:

`index.test.mjs`:

```js
import { it } from "node:test";

it("test", () => {
  console.log("message from the test");
});
```

`reporter.mjs`:
```js
import util from "node:util";

export default async (source) => {
  for await (const event of source) {
    if (event.type === "test:stdout") {
      console.log(event.type, util.inspect(event.data.message));
    }

    if (event.type === "test:dequeue") {
      console.log(event.type, event.data.name);
    }
  }
};
```

and run 

`node --test --test-reporter=./reporter.mjs`

which will print 

```console
test:dequeue index.test.mjs
test:stdout 'message from the test\n'
test:dequeue test
```

### How often does it reproduce? Is there a required condition?

It always does the same

### What is the expected behavior? Why is that the expected behavior?

I expected `test:dequeue test` to be printed before `test:stdout 'message from the test\n'` as the documentation states "Emitted when a test is dequeued, right before it is executed."


### What do you see instead?

The `test:stdout` event is emitted before the `test:dequeue`, which makes it impossible to understand which test was running when the message was written to stdout.

### Additional information

_No response_
Repository: ollama
Issue: raspberry pi 32bit userland - /usr/local/bin/ollama: cannot execute: required file not found
Labels: bug,linux

### What is the issue?

I'm trying to install ollama on a raspberry pi, I get that it'll be slow but I'm just playing around.

So running the curl command worked and it downloaded.

But when I run ollama run gemma or ollama pull gemma l get `-bash: /usr/local/bin/ollama: cannot execute: required file not found`

### OS

Linux

### GPU

Other

### CPU

Other

### Ollama version

_No response_
Repository: go
Issue: x/tools/gopls: report unnecessarily exported symbols
Labels: gopls,Tools,Refactoring

After a code reorganization, many symbols may continue to be exported even though they are no longer referenced from another package. Just as it is helpful to report dead code within an application, it would be useful to report symbols that could safely be unexported.

Gopls has all the information required to do this; we should expose it on request in the UI somehow.

(Or this could be a feature of cmd/deadcode. But cmd/deadcode could be a feature of gopls, too.)
Repository: go
Issue: cmd/go: get doesn't select dependencies limited to go@version
Labels: NeedsInvestigation,GoCommand,modules

### Go version

go version go1.21.8 darwin/amd64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users/aoeu/Library/Caches/go-build'
GOENV='/Users/aoeu/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/aoeu/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/aoeu/go'
GOPRIVATE=''
GOPROXY=''
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.21.8'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/aoeu/Desktop/just-a-test/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/sm/14wxd09941l27xkmt31qrz3h0000gq/T/go-build2401627713=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

we would like to stay on golang version 1.21 and still be able to update our dependencies using `go get -u ./...`

the problem is that `go get` doesn’t respect the local toolchain version and attempts to pull in module versions that are newer than the local toolchain

we found this solution https://github.com/golang/go/issues/59886#issuecomment-1591746299 but it doesn’t seem to work as seen in the example below:

```bash
% go version
go version go1.21.8 darwin/amd64

% export GOTOOLCHAIN=local

% go get k8s.io/client-go go@1.21.8
go: k8s.io/client-go@v0.30.1 requires go >= 1.22.0 (running go 1.21.8; GOTOOLCHAIN=local)
```

I also attempted with `go get k8s.io/client-go go@1.21` and `go get k8s.io/client-go go@1.20`

### What did you see happen?

not download compatible module version

### What did you expect to see?

download compatible module version
Repository: godot
Issue: Failed import on the first start of the project with csv translations, but after restart everything imports fine
Labels: bug,topic:import

### Tested versions

reproducible in 4.2.1, 4.2.2

### System information

Linux Fedora, Mac os X latest

### Issue description

I'm collaborating on an opensource project, and we have a problem in this project anytime you open it with godot for the first time (or after removing the folder .godot) fails importing the resources, but once it run once, you close the project and reopen everything is imported well

### Steps to reproduce

1. Clone https://github.com/Codename-Recon/Codename-Recon/
2. open it with godot, it complains about missing dependencies
3. Close the project 
4. reopen it, and everything is fine. 

(If you run the game, on the first open, it will corrupt some files, but once you restart the project, everything works fine)

### Minimal reproduction project (MRP)

For the moment this is the project, I will try to get a minimum reproduction project soon, but since I don't know where this issue comes from, I expect will take a good amount of time to get something small that reproduces it:
https://github.com/Codename-Recon/Codename-Recon/
Repository: go
Issue: cmd/compile: arm64 multiplication with constant optimization
Labels: Performance,help wanted,NeedsInvestigation,arch-arm64,compiler/runtime

While looking into optimizing [ed25119 verification](https://github.com/golang/go/blob/5f6a85637c5f2b7e093044651f5557e08faa8351/src/crypto/internal/edwards25519/field/fe_generic.go#L79) on ARM64, I noticed that `x * 19` is not optimized into shifted adds.

```
func multiply19(x uint64) uint64 {
    return x * 19
}
// which compiles to:
MOVD    $19, R1
MUL     R1, R0, R0
```

This can be reduced to:
```
ADD     R0<<3, R0, R1
ADD     R1<<1, R0, R0
```

The general form seems to be:

```
x * c, where
    c = 1 + 2^N + 2^(N+M), N != M;
    N > 1, M > 1 // not sure whether this restriction is necessary

Then the multiplication can be rewritten as:
    x + (x + x << M) << N

This can be checked with:
    (c-1)&1 == 0 && bits.OnesCount(c - 1) == 2

Which holds for numbers like:
    7, 11, 13, 19, 21, 25, 35, 37, 41, 49, 67, 69, 73, 81, 97, 131, 133, 137, 145, 161, 193...
```

There is also a similar reduction, that can be done:

```
x * c, where
    c = 1 + 2^N + 2^M + 2^(N+M), N < M
    N > 1  // not sure whether this restriction is necessary

Then the multiplication can be rewritten as:
    x = x + x<<N; x = x + x<<M

This can be checked with:
    (c-1)&1 == 0 && bits.OnesCount(c - 1) == 3 && highbit - lowbit = midbit

Which holds for numbers like:
    15, 23, 27, 29, 39, 43, 51, 53, 57, 71, 75, 83, 89, 99, 101, 135, 139, 147, 163, 169, 177, 195...
```

I didn't verify, but this might be useful on amd64 as well.

---

I can send a CL about this, but I'm not sure whether there are some corner cases with high `c` values that I'm not thinking of. Similarly, I wasn't able to figure out how to write the second reduction in SSA rules.
Repository: flutter
Issue: ☂️ Tracking issue for any infra or test failures with macOS 14
Labels: P2,team-ios,triaged-ios

## Test failures:

### flutter/flutter

- [x] https://github.com/flutter/flutter/issues/149264
- [x] https://github.com/flutter/flutter/issues/149268
- [ ] https://github.com/flutter/flutter/issues/150008
- [ ] https://github.com/flutter/flutter/issues/150642

### flutter/packages

- [x] https://github.com/flutter/flutter/issues/149264
- [x] https://github.com/flutter/flutter/issues/149266
- [x] https://github.com/flutter/flutter/issues/149270
- [x] https://github.com/flutter/flutter/issues/149329
- [x] https://github.com/flutter/flutter/issues/149713 (introduced by https://github.com/flutter/flutter/pull/149618)

### flutter/engine

- [x] https://github.com/flutter/flutter/issues/149416
- [x] https://github.com/flutter/flutter/issues/150011
- [ ] https://github.com/flutter/flutter/issues/150023
- [x] https://github.com/flutter/flutter/issues/150117


## Infra Issues:

- [ ] https://github.com/flutter/flutter/issues/157636
- [x] https://github.com/flutter/flutter/issues/156614
Repository: flutter
Issue: CP macOS 14 fixes for beta and stable
Labels: P2,team-ios,triaged-ios

## Prerequisites 

- [x] https://github.com/flutter/flutter/issues/148881
- [x] https://github.com/flutter/flutter/issues/148891
- [ ] Ensure all issues are fixed in https://github.com/flutter/flutter/issues/148882

## Instructions

CP any fixes made to resolve issues in https://github.com/flutter/flutter/issues/148882. This may include recipe fixes.
Repository: flutter
Issue: CP ci.yaml and configs to run on either macOS 13 or 14 for beta and stable
Labels: P2,team-release

## Prerequisites

- [x] https://github.com/flutter/flutter/issues/148881
- [x] https://github.com/flutter/flutter/issues/148891
- [ ] https://github.com/flutter/flutter/issues/148886 - may want to wait for one release to be successful with those changes before doing this

---

CP the following:
- [ ] https://github.com/flutter/flutter/issues/148871
- [ ] https://github.com/flutter/flutter/issues/148879
Repository: neovim
Issue: `'statusline'` `%{…}` expressions will sometimes lose a leading space
Labels: bug-vim,statusline

### Problem

There seems to be some obscure, undocumented logic when displaying the status line that will remove a single space character in some situations.

### Steps to reproduce

* `nvim --clean foo.txt`
* Insert some text to make sure the file is modified.
* `:set stl=%f%{&modified?'\ M':''}`
* The status line should say `foo.txt M`
* `:set stl=%{expand('%%')}%{&modified?'\ M':''}`
* The status line should now say `foo.txtM`, missing the space before the `M`.

### Expected behavior

The leading space returned by the second expression should not be removed, and certainly not depending on what the first expression is.

Looking at vim/vim#3898, the Vim folks seem to be aware of this since 2017, but it looks to me as if they hesitate changing it, for [xkcd 1172](https://xkcd.com/1172/) reasons. I'm raising this here, maybe Neovim is willing to break backwards compatibility to make things more consistent.

* In case you're thinking that the `%%` in the first expression is the problem: `:set stl=%{''}%{&modified?'\ M':''}` has the status line only contain `M`, with no leading space either.
* Using `%F` or `%t` as the first part will keep the space, while `%r` or `%M` will drop it.
* Adding a _second_ space in the second expression (`%{&modified?'\ \ M':''}`) will result in _one_ being printed.

### Neovim version (nvim -v)

NVIM v0.10.0

### Vim (not Nvim) behaves the same?

yes, VIM 9.0.1378 (including 1499)

### Operating system/version

Debian 12 bookworm

### Terminal name/version

kitty 0.26.5

### $TERM environment variable

xterm-kitty

### Installation

AppImage, but also occurs with Debian's 0.7.2