sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Peek at desktop keyboard shortcut stuck (Mouse Without Borders)
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.85.0

### Installation method

GitHub, PowerToys auto-update

### Running as admin

None

### Area(s) with issue?

General, Mouse Without Borders

### Steps to reproduce

It happens when using mouse without borders on secondary computers. When pressing Windows key + , on the secondary pc (shortcut for peeking at Desktop), it does not register any other commands with the keyboard, as if those shortcut keys were being being pressed down continuously. The only way to get around that is to press the same shortcut on the respective computer with its physical keyboard. Then, it "unfreezes" and goes back to normal.

To sum it up:
1. Bring the mouse to the computer which is connected in "mouse without borders";
2. Press Windows Key + , once
3. Can't use keyboard until manually pressing the shortcut ON the respective computer's keyboard

### ✔️ Expected Behavior

Peek at desktop supposed to be working on secondary computers when using the tool "mouse without borders".

### ❌ Actual Behavior

Once the shortcut is activated in the secondary pc, the result is a constant "peek at desktop", as if the shortcut was still being pressed down on the keyboard.

### Other Software

_No response_
Repository: ollama
Issue: Support for I16 data type in conversion from Safetensors
Labels: feature request

I tried importing the [ISTA-DASLab/Meta-Llama-3.1-8B-Instruct-AQLM-PV-2Bit-1x16-hf](https://huggingface.co/ISTA-DASLab/Meta-Llama-3.1-8B-Instruct-AQLM-PV-2Bit-1x16-hf) model from Hugging Face. It's in Safetensors format with tensor type FP16 and I16.

I downloaded the files, created a simple `Modelfile` in the same directory:
```
FROM .
```

From model creation I got this:
```
PS D:\OllamaModels\llama3.1-8b-instruct-aqlm> ollama create llama3.1-instruct-aqlm:8b
transferring model data 100%
converting model
Error: unknown data type: I16
```

Could Ollama conversion support the I16 data type?
Repository: react
Issue: Bug: DevTools 6.0.0 element inspector not working with React Native 0.75
Labels: Status: Unconfirmed

<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: 18.3.1

React Native version: 0.75.3

## Steps To Reproduce

1. Create a new 'frameworkless' React Native app, by following [these instructions](https://reactnative.dev/docs/getting-started-without-a-framework). Alternatively, clone [this repo](https://github.com/tsdevshop/react-native-devtools-test), which is the result of scaffolding a new RN project.
2. Run `npm install` and `cd ios; bundle exec pod install` to install dependencies.
3. Run `npm start` in one terminal to start the Metro bundler, and `npm run ios` in another to build and run the app on a simulator.
4. Run `npx react-devtools@6.0.0`.
5. In the simulator, reload the app and toggle the Element Inspector.
6. Tap on an element in the app to inspect it.

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example: https://github.com/tsdevshop/react-native-devtools-test

<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->

## The current behavior

- The element is not selected in the DevTools pane

## The expected behavior

- The element should be selected.

Note that running `npx react-devtools@5.3.1` results in the correct behavior.

## Screencasts

https://github.com/user-attachments/assets/89cb0446-fbbe-4b74-b989-c07a86bc4262

https://github.com/user-attachments/assets/4517c28a-c9b2-4b58-80c4-e6b3ff17a181
Repository: vscode
Issue: VS Code Insiders crashes with `editor.experimentalEditContextEnabled` and reconversion
Labels: freeze-slow-crash-leak,editor-edit-context

Version: 1.94.0-insider
Commit: 889feaf2ef663d9d3b079c4a3627e4ce27027323
Date: 2024-10-02T04:46:15.711Z
Electron: 30.5.1
ElectronBuildId: 10262041
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: 12.4.254.20-electron.0
OS: Darwin arm64 22.6.0


Steps to Reproduce:

1. Set `"editor.experimentalEditContextEnabled": true`
2. Enable Google IME for Japanese.
3. Type `sennsei`
4. Type `Space` twice
5. Click a different line of the editor with the mouse.
6. Press the key for reconversion,  the `Kana` key or `Ctrl-Shift-R`.
7. VS Code Insiders crashes sometimes, not always. It would be difficult to reproduce.

The following is the crash dump:

[fce4fc0f-f989-4de4-a9d7-4b2ace9c8859.dmp](https://github.com/user-attachments/files/17229566/fce4fc0f-f989-4de4-a9d7-4b2ace9c8859.dmp)
Repository: godot
Issue: When changing screen resolution, having a shader that use 'hint_depth_texture' will cause all shader that use 'hint_screen_texture' to turn black
Labels: bug,topic:rendering,confirmed

### Tested versions

- Reproducible in Godot Engine v4.3.stable.steam, with Compatibility renderer

### System information

Window 10 - Godot Engine v4.3.stable.steam - Compatibility renderer

### Issue description

When the screen resolution is changed, the shader that use hint_screen_texture will turn black, this radioactively happen to all shader that used hint_screen_texture even when they're not in the scene yet
I noticed that this will always happen when I look at a water, because my water shader use 'hint_depth_texture'

### Steps to reproduce

- create a CSGBox3D with Shader material that use spatial shader, this shader will use "hint_depth_texture" here is the simple script :
```
shader_type spatial;

uniform sampler2D DEPTH_TEXTURE : hint_depth_texture;

void fragment() {

	vec4 depth_texture = texture(DEPTH_TEXTURE, SCREEN_UV);
}

```


- create a color rect with Shader material that use canvas_item shader, this shader will use 'hint_screen_texture' here is the simple script :
```
shader_type canvas_item;

uniform sampler2D SCREEN_TEXTURE: hint_screen_texture;


void fragment() {
	COLOR = texture(SCREEN_TEXTURE, UV);
}
```

- If when the scene is running, the CSGBox3D is visible, the ColorRect will become black right away
- if when the scene is running and  the CSGBox3D is not visible, ColorRect shader will work fine BUT when CSGBox3D turn visible later and then resize the window, it will become black
before resize : 
![Screenshot 2024-10-02 195549](https://github.com/user-attachments/assets/980fea85-e968-41cb-a866-c1959a4d8806)
after resize : 
![Screenshot 2024-10-02 195622](https://github.com/user-attachments/assets/03c145bc-8bb4-45b3-b0da-1ca756cca9c2)






### Minimal reproduction project (MRP)

[test_depth_problem.zip](https://github.com/user-attachments/files/17229746/test_depth_problem.zip)
Repository: PowerToys
Issue: Workspaces cannot handle updated app versions
Labels: Issue-Bug,Needs-Triage,Needs-Team-Response,Product-Workspaces

### Microsoft PowerToys version

0.85.0

### Installation method

Scoop

### Running as admin

No

### Area(s) with issue?

Workspaces

### Steps to reproduce

Create a workspace with some apps. Then, update those apps to new versions, such that the new app binaries are placed in a new folder. Consider the situation where the app stores the binaries in a folder like C:/ProgramFiles/App/version1/binary.exe, but after an update it is found in C:/ProgramFiles/App/version1.1/binary.exe. In the $PATH, this is handled by having a shortcut to the current version of the app, like how Java is handled. Try to open the workspace again after updating. It will fail to open updated apps. 

### ✔️ Expected Behavior

Powertoys should open the app. Ideally, I would allow Powertoys to identify app binaries by shortcuts or by $PATH. Maybe you could allow the user to manually enter the path to the binary? 

### ❌ Actual Behavior

It looks for the app in the specific version folder, which may or may not exist anymore. 

### Other Software

_No response_
Repository: deno
Issue: Bug?: fetch(): Uncaught TypeError: error reading a body from connection
Labels: bug,ext/fetch

Version: Deno 1.46.3

I have a problem when fetching this URL.

`http(s)://www.astroarts.co.jp/article/feed.atom`

```
> await (await fetch("http://www.astroarts.co.jp/article/feed.atom")).text()
Uncaught TypeError: error reading a body from connection
    at async readableStreamCollectIntoUint8Array (ext:deno_web/06_streams.js:1066:19)
    at async consumeBody (ext:deno_fetch/22_body.js:254:9)
    at async <anonymous>:1:22
> await (await fetch("https://www.astroarts.co.jp/article/feed.atom")).text()
Uncaught TypeError: error reading a body from connection
    at async readableStreamCollectIntoUint8Array (ext:deno_web/06_streams.js:1066:19)
    at async consumeBody (ext:deno_fetch/22_body.js:254:9)
    at async <anonymous>:1:22
```

The two below can be executed without any problems.

```ts
await (await fetch("http://www.astroarts.co.jp/")).text()
await (await fetch("https://www.astroarts.co.jp/")).text()
```

You can see that it has been loaded halfway.

```
> const stream = (await fetch("https://www.astroarts.co.jp/article/feed.atom")).body
undefined
> for await (const chunk of stream) { console.log(chunk) }
Uint8Array(64) [
   60,  63, 120, 109, 108,  32, 118, 101, 114, 115, 105,
  111, 110,  61,  34,  49,  46,  48,  34,  32, 101, 110,
   99, 111, 100, 105, 110, 103,  61,  34,  85,  84,  70,
   45,  56,  34,  63,  62,  10,  60, 102, 101, 101, 100,
   32, 120, 109, 108, 110, 115,  61,  34, 104, 116, 116,
  112,  58,  47,  47, 119, 119, 119,  46, 119
]
Uint8Array(64) [
   51,  46, 111, 114, 103,  47,  50,  48,  48,  53,  47,
   65, 116, 111, 109,  34,  62,  10,  32,  32,  60,  97,
// -------------- many lines ----------------
Uint8Array(64) [
  136,  49,  48, 230, 151, 165, 227, 129, 148, 227, 130,
  141, 227, 128, 130,  60,  47, 115, 117, 109, 109,  97,
  114, 121,  62,  10,  32,  32,  32,  32,  60, 117, 112,
  100,  97, 116, 101, 100,  62,  50,  48,  50,  52,  45,
   48,  57,  45,  48,  51,  84,  48,  57,  58,  49,  48,
   58,  50,  51,  90,  60,  47, 117, 112, 100
]
Uint8Array(25) [
   97, 116, 101, 100,  62,  10,  32,
   32,  60,  47, 101, 110, 116, 114,
  121,  62,  10,  60,  47, 102, 101,
  101, 100,  62,  10
]
Uncaught TypeError: error reading a body from connection
    at async Object.pull (ext:deno_web/06_streams.js:938:27)
```
Repository: PowerToys
Issue: Scrolling Enhancements in Crop And Lock
Labels: Needs-Triage

### Description of the new feature / enhancement

For pointing devices that have horizontal scroll features, enable horizontal scrolling in Reparent mode.

Allow scrolling in all directions in Thumbnail mode (i.e., capture the entire window in the image buffer).

### Scenario when this would be used?

Based on the animated example use of Crop And Lock to crop to a section of a web page.  Horizontal scrolling would allow use of, for example, navigation links that are otherwise cropped out, without having to close the crop, navigate, and re-crop.  

In my work as an electrical engineer, I can imagine this being extremely useful when referring to small sections of large printed circuit board designs (except Altium doesn't play nice with CAR reparenting, hence the mention of scrolling in Thumbnail mode).  

CAR's real power is being able to crop out sidebars and UI elements that would otherwise get in the way when simply resizing the window.  Horizontal scrolling would make the tool that much more powerful.  

### Supporting information

_No response_
Repository: excalidraw
Issue: Excalidraw+ : scene name input + `esc` key
Labels: Excalidraw+

Hello, this is a small issue, but that's bothering me: when editing the name of a scene in Excalidraw+, pressing the `esc` key cancels the edition, which is a bit bothersome, and not what happens when editing a text in the scene itself for example.

Having `esc` accept current edition would be better IMO.

 ![Image](https://github.com/user-attachments/assets/15ca9bf7-4ff3-4437-8f54-cf2b20106d88)
Repository: rust
Issue: rustdoc search is excruciatingly slow on very large crates
Labels: I-slow,T-rustdoc,C-bug,A-rustdoc-search

Steps to reproduce:

1. Use Firefox on a computer with Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz or comparable CPU.
2. Go to https://microsoft.github.io/windows-docs-rs. This rustdoc has a search index of 38 MB.
3. Focus on the search bar and slowly type "ID3D12GraphicsPipelineState".

Expected behavior:

rustdoc quickly shows matching results while typing and when done typing.

Actual behavior:

Web page slows down to a crawl after every delayed keystroke. This is not just due to the search index download, which takes me 1.4 s and can probably not be improved much, but also due to matching the search query against the search index once the download is finished.

Here is Firefox Profiler output: <https://share.firefox.dev/4eOgrcE>. Of interest are the yellow areas in the graph (the salmon ones are mostly idle GC). Some observations:

 - buildIndex takes about a second.
 - A lot of time seems to be spent in calculating edit distance. This is definitely a useful feature (as can be seen in the example query, "ID3D12GraphicsPipelineState", which has relevant but no exact matches).
 - Some of the edit distance calculations are done by `convertNameToId`, which is documented to be used only for the In Parameters and In Return Types tabs. If the user is not going to click on those tabs then perhaps these calls are not necessary.
Repository: deno
Issue: deno.json imports not used when deno run https://xyz/main.ts - feature or bug ?
Labels: question


### Observation

I noticed that when doing `deno run path/to/main.ts` the `imports` field in `deno.json` is used - as expected.  
However when running the same script from remote `deno run https:///abc/xyz/main.ts` this is not the case.  

So if I need distribute a "package" ie a collection of interdependent `.ts` files then I cannot use the convenience of `deno.json/imports`. 

### Question

Is it a **feature** or a **bug** ?  
If it is a feature, to you plan to allow the use of `deno.json` in remote runs ?   
Or is there a good reason not to ?


### Context
I am in a corp env and the best/only way to share such package is via a github enterprise repo.  

### Repo 

To reproduce: https://github.com/oscar6echo/sample-deno-pkg  

Screenshots:
![image](https://github.com/user-attachments/assets/eb8673f1-172d-47fc-a886-0ad7c15d79d3)

![image](https://github.com/user-attachments/assets/13286651-3f50-40cd-9694-725571ed5f11)

![image](https://github.com/user-attachments/assets/030e233c-1050-4a17-b3c7-7537f4f94b87)


---

```sh
deno --version                                                                                            
deno 2.0.0-rc.9 (release candidate, release, x86_64-unknown-linux-gnu)
v8 12.9.202.13-rusty
typescript 5.6.2
```
Repository: godot
Issue: GDShader "invalid pragma directive" error on unrecognized pragma should be dropped
Labels: enhancement,discussion,topic:shaders

### Tested versions

- Reproducible in: v4.3.stable.flathub [77dcf97d8]

### System information

Godot v4.3.stable (77dcf97d8) - Freedesktop SDK 23.08 (Flatpak runtime) - X11 - Vulkan (Forward+) - integrated Intel(R) HD Graphics 5500 (BDW GT2) - Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz (4 Threads)

### Issue description

The [GLSL ES 3.00 spec](https://registry.khronos.org/OpenGL/specs/es/3.0/GLSL_ES_Specification_3.00.pdf) says on page 15:
> `#pragma` allows implementation dependent compiler control. Tokens following `#pragma` are not subject to preprocessor macro expansion. **If an implementation does not recognize the tokens following `#pragma`, then it will ignore that pragma.**

I believe the whole point of `#pragma` is to allow forward-compatibility, by letting any unrecognized instructions be ignored. So I believe showing an error like "Invalid pragma directive" defeats the whole purpose, no? Invalid pragma lines should be ignored like how it is in the spec.

In fact, both C and GLSL preprocessors don't complain at all if you add a custom pragma.

The spec also says:
> The following pragmas are defined as part of the language.
> `#pragma STDGL`
> The `STDGL` pragma is used to reserve pragmas for use by this and future revisions of the language. No
implementation may use a pragma whose first token is `STDGL`.

So, I think it would also be beneficial to add something similar for mandatory directives that *should* raise error if unrecognized. For example, you could exceptionally raise the error if it starts with `#pragma required`:
```glsl
shader_type spatial;
#pragma required command_that_must_be_supported
#pragma optional_command
```

Note that both C and GLSL preprocessors leave the entire `#pragma` lines (after joining line continuations) in their output as well (unlike other directives such as `#define`, etc. which are stripped out). Presumably, this could be to allow the compilation after the preprocessor to be affected by pragmas as well. So the ignoring behavior should be implemented in both the preprocessor and the lexer/parser after it, to account for potential usages that may extend beyond the preprocessor.

### Steps to reproduce

```glsl
shader_type spatial;
#pragma some_custom "etc" 3.14 // unrecognized pragma should be ignored instead of raising error
```
```sh
cd /tmp
echo '#pragma some_custom "etc" 3.14' | tee a.c > a.frag
echo '=== GLSL ==='; glslang -E a.frag; echo '=== C ==='; gcc -E a.c
```

Of course, the error should still show for recognized pragma lines that are malformed:
```glsl
#pragma disable_preprocessor blah blah // should still raise the error
```

### Minimal reproduction project (MRP)

N/A
Repository: PowerToys
Issue: New+ not working on Windows 11 (French Canada version)
Labels: Issue-Bug,Priority-1,Product-New+

### Microsoft PowerToys version

0.85.0

### Installation method

PowerToys auto-update

### Running as admin

None

### Area(s) with issue?

New+

### Steps to reproduce

Right-clicking on any folder doesn't bring up the New+ menu

### ✔️ Expected Behavior

New+ menu should be there (as saw in a video about this feature).

### ❌ Actual Behavior

Contextual menus are the same if New+ feature is turned ON and OFF

### Other Software

_No response_
Repository: TypeScript
Issue: Thousands of false positives that seem to crash the TypeScript extension
Labels: Needs Investigation

<!-- ⚠️⚠️ 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 (it's a built-in extension)

<!-- 🪓 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. -->
Version: 1.93.1 (Universal)
Commit: 38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40
Date: 2024-09-11T17:20:05.685Z
Electron: 30.4.0
ElectronBuildId: 10073054
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Darwin x64 22.6.0

Steps to Reproduce:

1. This is happening in our OS repo: https://github.com/Khan/perseus
2. `git clone https://github.com/Khan/perseus.git` and `yarn install`
3. Note there are no TS errors
4. Open `grapher.cypress.ts`
5. Note there are thousands of TS errors, even outside of the opened file
6. Run `yarn tsc` and note there aren't any real TS errors

https://github.com/user-attachments/assets/5bc851d0-b451-45bf-99d9-5e65d76ea77c
Repository: godot
Issue: Cannot import a Blender material with a Normal map and Alpha transparency at the same time while importing from gltf
Labels: bug,needs testing,topic:import

### Tested versions

Tested in v4.3.stable.official [77dcf97d8]

### System information

Godot v4.3.stable - Linux Mint 21.3 (Virginia) - X11 - Vulkan (Forward+) - dedicated AMD Radeon RX 580 Series (RADV POLARIS10) - AMD Ryzen 7 2700 Eight-Core Processor (16 Threads)

### Issue description

When I try to import a model from Blender 4.2.2, using the gltf 2.0 format and the default export options, if any of the materials has a texture with an alpha channel and a normal map at the same time, the whole model appears yellow in color and has no alpha transparency. If I try to remove the normal map from the material, export it again and reimport it into Godot, the material is still yellow with no alpha transparency (it doesn't update).

In order to be able to fix the material, I need to remove the corresponding .import files generated when Godot imported the model.

### Steps to reproduce

1. Create a regular cube (or any mesh, it's just an example) in Blender 4.2.2 LTS
2. Asign a material to it
3. Add a texture to the material's base color that has an alpha channel (for instance, maple.png)
4. In the Shading tab make sure that the Alpha channel of the texture is linked to the alpha property of the principled BSDF

![image](https://github.com/user-attachments/assets/993b664c-719f-4854-837c-eb544175a026)

5. Select the cube and export is as gltf 2.0. Leave all options by default, but make sure to select 'Export only selected objects'. In my case I exported it as cube.glb.
6. Import cube.glb in Godot. Double click in the imported model. Ensure that the model displays correctly.

![image](https://github.com/user-attachments/assets/660ba451-fcce-413b-9a5c-f3b82a82f667)

7. Now add a Normal Map node, link the texture color to it, and the output normal to the Normal property of the principled BSDF. Ensure that it still looks fine in Blender.

![image](https://github.com/user-attachments/assets/3a6ea517-7204-47d9-839d-b98bee386572)

8. Export the cube again as gltf2.0 overwriting the previous one
9. Make sure the model is updated in Godot (you should see Godot reimporting it. If not, drag and drop the file into your project).
10. Double click in the imported object. This time it appears yellow

![image](https://github.com/user-attachments/assets/8eb5a122-aa42-445c-88f5-cd91041efd0e)

11. Go back to blender, delete the normal map node, and repeat the exporting process again.
12. Update the model in Godot. The cube still appears yellow.
13. Navigate to the folder where your glb model is and remove the .png.import file (in my case it's cube_mapple.png.import). Now go back to Godot. Godot should reimport the material.
14. Double click in the model again. This time it should be rendering properly.

### Minimal reproduction project (MRP)

[github_bug_report_gltf_yellow.zip](https://github.com/user-attachments/files/17232275/github_bug_report_gltf_yellow.zip)
Repository: ollama
Issue: Support for NVLM
Labels: model request

NVLM is model from Nvidia: https://nvlm-project.github.io/