sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Engine crashes when modifying tool script
Labels: bug,topic:gdscript,confirmed,crash

### Godot version

4.0 stable

### System information

manjaro linux 

### Issue description

when modifying an tool script the engine crashes

```
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.stable.official (92bee43adba8d2401ef40e2480e53087bcb1eaf1)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x38f50) [0x7f4489f0ff50] (??:0)
[2] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0x4634528] (??:0)
[3] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0x1271370] (??:0)
[4] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0x43a4897] (??:0)
[5] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0x43c31ab] (??:0)
[6] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0x43d1966] (??:0)
[7] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0x45d8d04] (??:0)
[8] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0x2bc32fd] (??:0)
[9] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0x2bd12db] (??:0)
[10] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0xec07db] (??:0)
[11] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0xe027f3] (??:0)
[12] /usr/lib/libc.so.6(+0x23790) [0x7f4489efa790] (??:0)
[13] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f4489efa84a] (??:0)
[14] /run/media/nonunknown/3a1f3657-ce4a-4ffa-8f65-f41e1dfcaf68/4Godot.x86_64() [0xe2286e] (??:0)
-- END OF BACKTRACE --
================================================================

```

not very useful stack trace, but its the message!

### Steps to reproduce

* Download the MRP
* Open Project
* open node_3d scene
* selectr TrailRenderer node
* click on active (will run _process) in inspector
* then go to TrailRenderer's `_process` code and add a `print("test")`
* save script
* engine should crash

### Minimal reproduction project

[MRP-ToolReload.zip](https://github.com/godotengine/godot/files/10921228/MRP-ToolReload.zip)
Repository: godot
Issue: tween_interval() works strangely with set_parallel()
Labels: discussion,topic:animation

### Godot version

4.0.stable

### System information

Win10

### Issue description

```
extends ColorRect

func _ready():
	var tween = create_tween()
	tween.tween_property(self,"scale",Vector2(2,2),1)
	tween.tween_interval(2)
	tween.set_parallel()
	tween.tween_property(self,"position",position +Vector2(50,50),0.3)
	tween.tween_property(self,"modulate",Color.RED,0.3)
```
The sequence of execution of this code in my imagination is:

`ColoRect `first magnifies the `scale `to twice in 1 second, and then after a delay of 2 seconds, it simultaneously changes its `position `and `modulate `to the specified value in 0.3 seconds.

But the fact is that after taking a second to adjust its `scale`, it skipped `tweet.tween_ Interval (2) `sets the 2-second delay. Instead, it directly start modifying `position `and `modulate `.

It looks like set_parallel() will execute the previous IntervalTweener at the same time.

But the description in the document is as follows:
> "the Tweeners appended **after** this method will by default run simultaneously, as opposed to sequentially."

I don't know whether my understanding is wrong or there is a bug here.

### Steps to reproduce

You use the code in the above question to reproduce.

### Minimal reproduction project

N/A
Repository: vscode
Issue: Support debug adapter server over WebSockets (similar to DebugAdapterServer)
Labels: feature-request,debug

Currently a `DebugAdapterDescriptorFactory` can return one of:

- `DebugAdapterExecutable`
- `DebugAdapterServer`
- `DebugAdapterNamedPipeServer`
- `DebugAdapterInlineImplementation`

`DebugAdapterServer` uses raw sockets, but it would be useful to be able to use WebSockets too (debuggers using WebSockets can be connected to from code running in a browser, and can also host multiple endpoints in a single port by having different URLs).

Alternatively, an implementation that allows us to just provide streams (like how the LSP client can accept a stream reader/writer) would allow a WebSocket version to be implemented fairly easily.
Repository: vscode
Issue: [Accessibility] Support task completion/failure audio cues in Output
Labels: feature-request,accessibility,accessibility-signal

CC @meganrogge 

Many extensions, such as [microsoft/vscode-arduino](https://github.com/microsoft/vscode-arduino), use Output view and display compile results like below:

![image](https://user-images.githubusercontent.com/19754711/223737392-4a0cfa2f-1c44-4c3e-b24b-5c54b6b87cd7.png)

Could you please support task completion and failure audio cues in output view as well? Currently, it is very tedious to read through the results line by line.
Repository: rust
Issue: `async` block occupies twice the size of its captures (causing explosion in size).
Labels: T-compiler,C-bug,WG-async


I tried this code ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=412097d4fcf82a97b18515f3bd652880)) which wraps a future in a trivial `async` block:

```rust
let foo = async move { ... };
dbg!(std::mem::size_of_val(&foo));

let bar = async move { foo.await };
dbg!(std::mem::size_of_val(&bar));
```

I expected to see that `size_of(bar) == size_of(foo)` (plus some bytes for a tag). Instead, I found that `size_of(bar) > 2 * size_of(foo)`.

I discovered this while nesting a couple of futures which largely had the following form:
```rust
let future = function_returning_future(...);
async move { 
    let result = future.await;
    let output = /* ...do something with result... */;
    output
}
```
The final future occupied a few kilobytes. I was able work around this by using a `map` combinator, but it is not ideal.

This could possibly be related to #62958, but I'm not familiar enough with the compiler internals to say with certainty if `async`-block captures are implemented the same way as `async fn` arguments. 

### Meta

This happens in stable 1.67.1, beta 1.70.0, and the latest nightly.
Repository: next.js
Issue: Sourcemaps pointing to incorrect file in Chrome error stack trace
Labels: bug

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.13.2
      npm: 8.1.2
      Yarn: 3.3.0
      pnpm: 6.11.0
    Relevant packages:
      next: 13.2.4-canary.6
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
```


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

_No response_

### Link to the code that reproduces this issue

https://github.com/pellejacobs/nextjs-sourcemaps-error-example

### To Reproduce

Clone the repo and run both the build & start commands: `npm run build && npm start`. Click the "throw error" button on both a Chrome and Firefox. 

The repo is a clean `create-next-app` install with: 
- a function defined in a separate `utils.js` file, which throws a standard `Error`. 
- a component in `index.jsx` calling this function. 

### Describe the Bug

The chrome stack trace does not reference the correct file: the `onClick` step happens in `index.jsx`, not in `utils.js`. 

Chrome: 

![image](https://user-images.githubusercontent.com/7174652/223744136-1fe2b97b-834e-4c23-8d41-75f14f4c0a47.png)

I've reproduced the same error on clean installs of other Chromium based browsers like Edge and Opera. We've also noticed the same behaviour on our error reporting platform (Sentry).


### Expected Behavior

I would expect the second line of the stack trace to reference `index.jsx` instead of `utils.js`. 

It seems like Firefox parses the sourcemap properly:

Firefox: 
<img width="386" alt="image" src="https://user-images.githubusercontent.com/7174652/223744212-e9045b60-4143-447e-8905-206a30c4437b.png">

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

Chrome 110.0.5481.177 and Firefox 110.0.1

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

Not applicable.
Repository: pytorch
Issue: Reuse autograd.grad graph for rapid, repeated gradient calculation
Labels: feature,module: autograd,triaged,module: cuda graphs

### 🚀 The feature, motivation and pitch

In Scientific Machine Learning (SciML), there is often the need to run a function forward and obtain gradient wrt inputs. This is not to tune nn parameters but for solving large systems of equations. This task happens at every time step with fixed input shapes and is often the largest time consumer. The workflow can be written concisely as:

```
for i in range(nt):
  torch.set_grad_enabled(True)
  gg = G(x, p, aux)   
  #x, p are tensors.  They may have very many elements, but fixed shapes over time steps. 
  dGdx = torch.autograd.grad(gg,x,grad_outputs=v) ## the jacobian dGdx is often sparse
  torch.set_grad_enabled(False)
  #use dGdx in some calculations, without need for Automatic Differentiation
```

through some optimization with v we were already making torch.autograd.grad parallel for two dimensions, but it is still the majority of the time. I suspect it is due to repeatedly calling the autograd engine, but the graph is fixed for every time! if we can capture the graph for the two main lines "gg=G" and "autograd.grad", only change the data (x,y) and reuse the graph every time step, it can go much faster:

```
# somehow initialize the graph capturedGraph for both G and autograd.grad
for i in range(nt):
  dGdx = capturedGraph(x,p)
  # use dGdx in some calculations
```

Motivation:
This is a core task for almost all engineering domains. It's a super big deal!! For example, read here.
https://www.mathworks.com/help/optim/ug/nonlinear-equations-with-analytic-jacobian.html


### Alternatives

I've been reading torch.fx to no avail.

### Additional context

_No response_

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @mcarilli
Repository: PowerToys
Issue: Request taskbar/taskbar editor in PowerToys
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

preferred in the next version of PowerToys, an insertion of the Taskbar/taskbar-Editor, for monitors of long size, such as 3840x1080 (also 1200 and other formats), so that you can have the Taskbar and maybe Windows 10 StartMenu in the center, or on the right, if you use FancyZones, with Monitor splitter, to be able to each splitter to have a Taskbar with Startmenu. All otherwise I have to move from one side to the other more movement with the mouse, being careful that if you play, that the double taskbar does not go above the Game window...
thank you and I hope good news in the next version

### Scenario when this would be used?

as explained above, for large (Curved) monitors. Mouse movement from side to side of the monitor to reach the Windows 10 Start Button. Windows 10 does not have the ability to center the Startmenu and Taskbar icons like Windows 11

### Supporting information

_No response_
Repository: tensorflow
Issue: third_party/icu/data missing big-endian conversion data files
Labels: stat:awaiting tensorflower,type:build/install,subtype: ubuntu/linux

<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Build/Install

### Have you reproduced the bug with TF nightly?

Yes

### Source

source

### Tensorflow Version

tf 2.11

### Custom Code

Yes

### OS Platform and Distribution

Linux Ubuntu 20.04 s390x

### Mobile device

_No response_

### Python version

3.10

### Bazel version

5.3.0

### GCC/Compiler version

gcc 9

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current Behaviour?

```shell
Two of the unicode unit tests fail on s390x due to the icu_conversion_data.c.gz.* files being in little-endian format. 

Could big-endian formatted versions of the icu_conversion_data.c.gz.* files be added so that they can be selected when building on s390x?
```


### Standalone code to reproduce the issue

```shell
The unit tests:

* //tensorflow/python/kernel_tests/strings_ops:unicode_decode_op_test
* //tensorflow/python/kernel_tests/strings_ops:unicode_transcode_op_test

fail on s390x.
```


### Relevant log output

```shell
======================================================================
ERROR: testDecodeWithDifferentEncodings5 ('SHIFT-JIS', ['Hello', 'こんにちは']) (__main__.UnicodeDecodeTest)
UnicodeDecodeTest.testDecodeWithDifferentEncodings5 ('SHIFT-JIS', ['Hello', 'こんにちは'])
testDecodeWithDifferentEncodings('SHIFT-JIS', ['Hello', 'こんにちは'])
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jalbrecht/.cache/bazel/_bazel_jalbrecht/d88fb95a52e214eb99836e3d1a65a951/execroot/org_tensorflow/bazel-out/s390x-opt/bin/tensorflow/python/kernel_tests/strings_ops/unicode_decode_op_test.runfiles/org_tensorflow/tensorflow/python/client/session.py", line 1378, in _do_call
    return fn(*args)
  File "/home/jalbrecht/.cache/bazel/_bazel_jalbrecht/d88fb95a52e214eb99836e3d1a65a951/execroot/org_tensorflow/bazel-out/s390x-opt/bin/tensorflow/python/kernel_tests/strings_ops/unicode_decode_op_test.runfiles/org_tensorflow/tensorflow/python/client/session.py", line 1361, in _run_fn
    return self._call_tf_sessionrun(options, feed_dict, fetch_list,
  File "/home/jalbrecht/.cache/bazel/_bazel_jalbrecht/d88fb95a52e214eb99836e3d1a65a951/execroot/org_tensorflow/bazel-out/s390x-opt/bin/tensorflow/python/kernel_tests/strings_ops/unicode_decode_op_test.runfiles/org_tensorflow/tensorflow/python/client/session.py", line 1454, in _call_tf_sessionrun
    return tf_session.TF_SessionRun_wrapper(self._session, options, feed_dict,
tensorflow.python.framework.errors_impl.InvalidArgumentError: Could not create converter for input encoding: SHIFT-JIS
         [[{{node UnicodeDecode/UnicodeDecode}}]]
```
</details>
Repository: neovim
Issue: TUI: exepath is set to PATH twice on Windows
Labels: bug,platform:windows,tui,remote

### Problem

`exepath` is set to `PATH` twice.

Perhaps `exepath` was added in `tui` and more `exepath` was added in `server`. The design of #18375 is wrong. The TUI and server code should be separated. Ad hoc code that branches conditional on `ui_client_channel_id` should not be written.
Cc: @bfredl 

### Steps to reproduce

```vim
set PATH=C:\Windows;C:\Windows\System32
nvim --clean
:echo $PATH
C:\Windows;C:\Windows\System32;C:\Neovim\bin;C:\Neovim\bin " If neovim is located at C:\Neovim\bin.
```





### Expected behavior

`exepath` is set to `PATH` only once.

### Neovim version (nvim -v)

cce736218f465511194465410e1ba23b5530e46f or later

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

N/A

### Operating system/version

Windows

### Terminal name/version

N/A

### $TERM environment variable

N/A

### Installation

zip of release page
Repository: godot
Issue: Renaming material resource does not update reference in GLTF import file
Labels: bug,topic:editor,confirmed,topic:import,topic:3d

### Godot version

v4.1.dev.custom_build [9b9bb418c]

### System information

Windows 10, Vulkan, Geforce RTX 2060

### Issue description

An imported GLTF file with materials has the `use_external/enabled` property checked and the path set to a material asset in the project folder. This works as expected. When the material asset is renamed in the editor, references to it are updated in .tscn and other resource files. They are **not** updated in the GLTF's import file, leading to an out-of-date reference that breaks visuals the next time the file is imported.

### Steps to reproduce

Open the MRP. Rename the material asset. Open the `cube.glb.import` file in an external editor and observe how it still references the old material name. Reimport the asset, open `main.tscn` and notice how the inherited scene no longer uses the assigned material.

### Minimal reproduction project

[import-rename.zip](https://github.com/godotengine/godot/files/10923079/import-rename.zip)
Repository: deno
Issue: Remove `Send` requirement from the lsp
Labels: chore

This is all single threaded, but the lsp code complains if we switch to `RefCell` and `Rc`. I tried spawning a local task for this, but that didn't help. Probably some simple fix I don't know about.

https://github.com/denoland/deno/blob/0cce9c2bcc9667935a571d30847e66ef5d01a196/cli/npm/resolution/graph.rs#L162-L163

cc @bartlomieju
Repository: rust
Issue: Testing a cross-compiled toolchain
Labels: A-testsuite,P-low,T-bootstrap

We (Android platform) build a custom version of rustc. Basically, we take the source distro, apply a few patches, and run x.py with a custom config.toml.

I am working on 2 things, which are related:

* We want to build a Rust toolchain that runs on Windows (MinGW). For various reasons, we'd prefer to do this by cross-compiling (i.e. build a Windows rustc on a Linux machine).

* We want to test our toolchain in our CI pipeline. For example, run `x.py test tests/ui`

So, I had the following "clever" idea:

1. Cross-compile a windows toolchain on Linux.
1. Copy it to a Windows machine.
1. In Windows, `x.py --stage 0 test tests/ui` with the stage 0 / bootstrap configured to use my new toolchain.

I got a very helpful warning that I probably shouldn't be doing this, and inviting me to file this issue. When I proceeded anyway, with `COMPILETEST_FORCE_STAGE0=1`, I got a number of test failures (~200 out of ~13,000). (For comparison, when I ran `x.py test tests/ui` the "right" way, the tests all passed, so I'm pretty confident the failures weren't due to our patches and custom configuration.)

Is there a correct, supported way to do this? That is, run tests "after-the-fact" on a toolchain you just built, possibly on a different machine? If not, I am willing to add support for it, if there is interest.

I found several things that seemed related, but not quite right:

* According to the [docs](https://rustc-dev-guide.rust-lang.org/tests/intro.html#dist-check), `./x.py test distcheck` applies to a source tarball, not a compiled toolchain.
* The [remote test server](https://rustc-dev-guide.rust-lang.org/tests/running.html#running-tests-on-a-remote-machine) seems to be for testing different **targets**, not for when the toolchain itself is cross-compiled. It also seems like it would be very difficult to use in our CI pipeline. It also seems like it poses security issues in a production environment (opening a port allowing arbitrary code execution).
Repository: vscode
Issue: Quick Fix Shortcut not working after running VSCode for some time
Labels: bug,keybindings

Type: <b>Bug</b>

After running VSCode for some time (a few hours), the shortcut (command + .) for the quick fix action stops working. This issue appeared to me multiple times. Restarting VSCode doesn't fix it. Instead a complete system restart is required to solve the issue. There are no global (system-wide) hotkeys configured for the shortcut, and it does work in the beginning but ceases to do after some time. In the "Developer: Toggle Keyboard Shortcuts Troubleshooting" pannel, only the command key event is shown, not the press of the dot key.

I'm using a German keyboard.

The bug could be related to #125932 and #133513.

VS Code version: Code 1.76.0 (Universal) (92da9481c0904c6adfe372c12da3b7748d74bdcb, 2023-03-01T10:23:45.993Z)
OS version: Darwin arm64 21.6.0
Modes:
Sandboxed: No

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Apple M1 Pro (8 x 24)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>metal: disabled_off<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_renderer: enabled_on<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: disabled_off|
|Load (avg)|1, 2, 2|
|Memory (System)|16.00GB (0.27GB free)|
|Process Argv|--crash-reporter-id d93a1dc4-f8d4-436f-8490-25a822cf9a4b|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (7)</summary>

Extension|Author (truncated)|Version
---|---|---
copilot|Git|1.77.9225
latex-workshop|Jam|9.7.0
remote-ssh|ms-|0.98.0
remote-ssh-edit|ms-|0.84.0
remote-explorer|ms-|0.2.0
code-spell-checker|str|2.19.0
code-spell-checker-german|str|2.2.0

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
dsvsc012:30540252
azure-dev_surveyone:30548225
pyindex848:30662994
nodejswelcome1cf:30587006
3biah626:30602489
pyind779:30671433
89544117:30613380
pythonsymbol12:30671437
showlangstatbar:30672706
vscodeenable:30660116

```

</details>

<!-- generated by issue reporter -->
Repository: go
Issue: all: `connect: connection reset by peer` failures on NetBSD
Labels: NeedsInvestigation

```
#!watchflakes
post <- goos == "netbsd" && `connect: connection reset by peer`
```

Edit: Changed to catch all connection reset by peer on NetBSD. -@neild

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/385b016762bfce1d37987cbeb5aa3329e2e852c6)):

    --- FAIL: TestQuerySemicolon (0.00s)
        --- FAIL: TestQuerySemicolon/?a=1;x=good;x=bad/allow=true (0.00s)
            serve_test.go:6648: Get "http://127.0.0.1:64693?a=1;x=good;x=bad": dial tcp 127.0.0.1:64693: connect: connection reset by peer
    2023/03/01 22:23:01 http: TLS handshake error from 127.0.0.1:63007: EOF


— [watchflakes](https://go.dev/wiki/Watchflakes)