sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tauri
Issue: window.print in android
Labels: type: bug,status: needs triage

### Describe the bug

`window.print` function (javascript) is not working in android, you can call it but despite desktop nothing happens

### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
[⚠] Environment
    - OS: NixOS 25.5.0 x86_64 (X64)
    ✔ webkit2gtk-4.1: 2.46.4
    ✔ rsvg2: 2.58.3
    ✔ rustc: 1.82.0 (f6e511eec 2024-10-15)
    ✔ cargo: 1.82.0 (8f40fc59f 2024-08-21)
    ⚠ rustup: not installed!
      If you have rust installed some other way, we recommend uninstalling it
      then use rustup instead. Visit https://rustup.rs/
    ⚠ Rust toolchain: couldn't be detected!
      Maybe you don't have rustup installed? if so, Visit https://rustup.rs/
    - node: 20.18.0
    - pnpm: 9.14.2
    - npm: 10.8.2

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.0
    - tao 🦀: 0.30.8
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-shell 🦀: 2.0.2
    - @tauri-apps/plugin-shell : 2.0.1 (outdated, latest: 2.2.0)

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../build
    - devUrl: http://localhost:1420/
    - framework: Svelte
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: tauri
Issue: [bug] Remote API Access from localhost does not inject window.__TAURI__
Labels: type: bug,status: needs triage

### Describe the bug

I am trying to access the Tauri API in my browser via `http://localhost:1420/`. This is intended for the release, not just development. I use the following snippet to check if the API is available.

```tsx
// App.tsx
useEffect(() => {
  console.log("__TAURI__" in window ? "Tauri" : "Web");
}, []);
```

For the Tauri window, this logs `Tauri` as expected. For the browser window however, this logs `Web`.

I followed [the capabilities docs](https://v2.tauri.app/security/capabilities/#remote-api-access) to set this up.

```jsonc
// capabilities/remote-access.json
{
    "$schema": "../gen/schemas/desktop-schema.json",
    "identifier": "remote-access-capability",
    "windows": [
        "main"
    ],
    "remote": {
        "urls": [
            "http://localhost/*"
        ]
    },
    "platforms": [
        "windows"
    ],
    "permissions": [
        "core:default"
    ]
}
```

```jsonc
// tauri.conf.json
...
"app": {
  ...
  "security": {
    "csp": null,
    "capabilities": [
      "remote-access-capability"
    ]
  },
  "withGlobalTauri": true
}
```

Is this a mistake on my end? 

### Reproduction

Here is a minimal reproduction example, starting from create-tauri-app.
https://github.com/bischoff-m/tauri-remote-api-issue/commit/aa0a1eefcbd49c89c099420ae979383ca03c2484

### Expected behavior

I expected the `window.__TAURI__` object to be accessible via `http://localhost/`.

### Full `tauri info` output

```text
[✔] Environment
    - OS: Windows 10.0.22631 x86_64 (X64)
    ✔ WebView2: 131.0.2903.86
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.18.0
    - npm: 10.8.2

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-shell 🦀: 2.2.0
    - @tauri-apps/plugin-shell : 2.2.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: vscode
Issue: Allow for subtraction in Settings editor search queries
Labels: feature-request,settings-editor

I realized while looking at https://github.com/microsoft/vscode/issues/201456 that allowing `-query` to subtract results could be pretty cool.
Repository: PowerToys
Issue: Checkbox ticks in Markdown files have bad contrast
Labels: Issue-Bug,Needs-Triage,Product-Peek

### Microsoft PowerToys version

0.86.0

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

Peek

### Steps to reproduce

Create a Markdown file using the following code and use Peek to preview its content:
````markdown
- [ ] Unchecked
- [x] Checked
````

### ✔️ Expected Behavior

Mockups:
![Image](https://github.com/user-attachments/assets/01388d49-f13e-4e7e-a2d2-13760a2bd5bd)![Image](https://github.com/user-attachments/assets/6d0f9e5a-870f-4dd6-b4b6-393ed1ec7001)
or
![Image](https://github.com/user-attachments/assets/8030c4fb-dd5a-4723-92d5-6f980011f069)![Image](https://github.com/user-attachments/assets/659e9c8c-1cb1-43ef-89c7-1f5f0220f877)




### ❌ Actual Behavior

![Image](https://github.com/user-attachments/assets/ca6ea650-b3cc-44c8-82fb-ca7bc635b183)![Image](https://github.com/user-attachments/assets/aaaf4d81-622f-4058-92f8-9886f3364801)


### Other Software

_No response_
Repository: rust
Issue: Tracking issue for release notes of #132975: De-duplicate and improve definition of core::ffi::c_char
Labels: T-libs-api,relnotes,T-libs,relnotes-tracking-issue


This issue tracks the release notes text for #132975.

### Steps

- [ ] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Compatibility Notes
- [More closely match clang behavior for definition of core::ffi::c_char](https://github.com/rust-lang/rust/pull/132975)
  On many targets, this has changed the definition of c_char, resulting in potential compilation issues.
  The new definition is more likely to be accurate for the corresponding C definition on the relevant target.
  The libc crate matches this change as of its 0.2.169 release.
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @arichardson, @BurntSushi, @tgross35 -- origin issue/PR authors and assignees for starting to draft text
Repository: pytorch
Issue: Add [low, high] interval for torch.distributions.beta
Labels: module: distributions,triaged

### 🚀 The feature, motivation and pitch

I think it would be nice to extend the torch.distributions.beta with two additional parameters "low" and "high" similar to the ones in the torch.distributions.uniform to be able to scale the beta distribution on a custom interval [low, high] in order not to be limited to the interval [0, 1].

### Alternatives
It is possible to obtain a similar result using an AffineTransform 
`dist = TransformedDistribution(
        Beta(concentration1=alpha, concentration0=beta), 
        [AffineTransform(loc=min_val, scale=(max_val - min_val)])`
, but I feel like it would be more intuitive to be able to specify the interval from the constructor as it is done in the Uniform distribution. 
In addition the resulted TransformedDistribution does not implement all the methods and properties of the original Beta distribution, ( mean, std_dev, mode, etc... )

### Additional context

_No response_

cc @fritzo @neerajprad @alicanb @nikitaved
Repository: godot
Issue: GLTFDocument.append_from_scene executed on non-ui thread cost tool much time compared to on ui thread.
Labels: bug,needs testing,topic:import,performance

### Tested versions

Reproducible in Godot v4.0.4.stable

### System information

Mac & Android & iOS - Godot v4.0.4.stable

### Issue description

try to execute GLTFDocument.append_from_file on ui thread and non-ui thread respectively, the time cost on non-ui thread is much higher than on ui thread. for example, in the minimal reproduction project,  append on ui thread time cost: 3436ms,
but append on other thread time cost: 117287ms
Hope to see your replay as soon as possible! Thanks so much!

### Steps to reproduce

run the MRP Main.tscn to check result

### Minimal reproduction project (MRP)

[MinimalProject.zip](https://github.com/user-attachments/files/18088789/MinimalProject.zip)
Repository: pytorch
Issue: Document spectral norm non-support on non-diagonalizable inputs.
Labels: module: docs,module: nn,triaged,module: nn.utils.parametrize

### 📚 The doc issue

Document spectral norm support on non-diagonalizable inputs.

The spectral norm implementation(s) rely upon a power iteration which doesn't guarantee a correct result for non-diagonalizable inputs:

- https://pytorch.org/docs/stable/generated/torch.nn.utils.spectral_norm.html
- https://pytorch.org/docs/stable/generated/torch.nn.utils.parametrizations.spectral_norm.html#torch.nn.utils.parametrizations.spectral_norm

Example:
```
import torch


m = torch.nn.Linear(2, 2)
# Example input A is non-diagonalizable, with repeated dominant eigenvalue 3.
# So expected spectral norm is sigma = 3, and returned result should be A / 3.
A = torch.tensor([[3., 3.], [0., 3.]])
with torch.no_grad():
    m.weight = torch.nn.Parameter(A)
    torch.nn.utils.parametrizations.spectral_norm(m)
    expected = A / 3
    actual = m.weight.data
    if not torch.allclose(actual, expected):
        # Spectral norm algorithm returning A / sigma computes sigma = 4.8541 instead of sigma = 3.
        print(f"expected: {expected} \ngot: {actual}")
```

### Suggest a potential alternative/fix

Spectral norm non-support on non-diagonalizable inputs should be included in the docs (perhaps as a 'warning').

cc @svekars @brycebortree @sekyondaMeta @AlannaBurke @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: godot
Issue: Random Editor Crash
Labels: bug,needs testing,crash,regression,topic:gui

### Tested versions

- Reproducible in 4.3.stable, 4.4.dev1, 4.4.dev3 and 4.4.dev6
- Not Reproducible in 4.2.2.stable

### System information

Windows 10 - Godot 4.3.stable - Vulkan - NVIDIA RTX 3060 Laptop - 11th Gen Intel Core i7-11800H @ 2.3GHz (16 Threads)

### Issue description

So the editor would sometimes crash at random, and it's a little annoying. I tried opening the console version and I do not see any errors pop out when the editor becomes unresponsive.

### Steps to reproduce

From my experience, these are the things that trigger this issue:
- Changing the value in the color picker using the color wheel
- Editing text by only highlighting certain parts of text using mouse
- Popup window when right-clicking in file manager, node properties, etc.

On very rare occasions, it can also crash when:
- The animation player in the editor finishes playing.
- Typing in any textbox (create nodes, create scripts, directory search, etc.)

If you want to try and reproduce the bug, try doing any of the actions mentioned above in rapid succession.

### Minimal reproduction project (MRP)

You can reproduce this in any blank project, to be honest.

[new-game-project-dev.zip](https://github.com/user-attachments/files/18089743/new-game-project-dev.zip)
Repository: storybook
Issue: [Bug]: react-docgen-typescript not working after v8.4.6
Labels: bug,react,has workaround,builder-vite,sev:S2,docgen

### Describe the bug

After v8.4.6, using `react-docgen-typescript` as the argTypes inferrer fails to pick up arguments and JSDoc comments entirely.

### Reproduction link

https://github.com/fertolg/storybook-8_4_6-react-docgen-typescript-bug

### Reproduction steps

1. Clone the repo
2. Run `pnpm storybook`
3. Notice how the default example stories are missing type inference (size property is missing for example) and the JSDocs comments are not being rendered in the documentation either.

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.7.1
    CPU: (11) arm64 Apple M3 Pro
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.9.0 - ~/.nvm/versions/node/v20.9.0/bin/node
    npm: 10.1.0 - ~/.nvm/versions/node/v20.9.0/bin/npm
    pnpm: 9.10.0 - /opt/homebrew/bin/pnpm <----- active
  Browsers:
    Chrome: 131.0.6778.109
    Safari: 18.1.1
  npmPackages:
    @storybook/addon-essentials: 8.4.6 => 8.4.6 
    @storybook/addon-interactions: 8.4.6 => 8.4.6 
    @storybook/addon-onboarding: 8.4.6 => 8.4.6 
    @storybook/blocks: 8.4.6 => 8.4.6 
    @storybook/react: 8.4.6 => 8.4.6 
    @storybook/react-vite: 8.4.6 => 8.4.6 
    @storybook/test: 8.4.6 => 8.4.6 
    eslint-plugin-storybook: ^0.11.1 => 0.11.1 
    storybook: 8.4.6 => 8.4.6
```

### Additional context

You don't have to clone the repo I provided, you can also:

1. Initialize a brand new project in an empty directory with `pnpm dlx storybook@latest init`
2. Choose React + Vite
3. After initialization, update `.storybook/main.ts` to use `react-docgen-typescript`.
4. Run storybook and see the result.
Repository: next.js
Issue: Problem with apollographql using turbopack - Unexpected error processing request: TypeError: module.require is not a function
Labels: bug,Turbopack

### Link to the code that reproduces this issue

https://github.com/dincerpece/nextjs15-1_turbo_apollographql_error

### To Reproduce

When I start it with turbopack and open the page, an error occurs.

next dev --port 65000 --turbo

### Current vs. Expected behavior

When I run "next dev --port 65000" without turbopack, the response comes as it should. However, when I add the --turbo flag and start it, an error occurs!

Error: Response not successful: Received status code 500
    at resolveErrorDev (http://localhost:65000/_next/static/chunks/node_modules_next_dist_compiled_107ce8._.js:3662:65)
    at processFullStringRow (http://localhost:65000/_next/static/chunks/node_modules_next_dist_compiled_107ce8._.js:3824:23)
    at processFullBinaryRow (http://localhost:65000/_next/static/chunks/node_modules_next_dist_compiled_107ce8._.js:3812:9)
    at progress (http://localhost:65000/_next/static/chunks/node_modules_next_dist_compiled_107ce8._.js:3932:102)
    
    
 
![nextjs_turbopack_apollographqlerror](https://github.com/user-attachments/assets/d0d108b1-bfd6-4991-9c02-8b20ca285d65)


![nextjs_turbopack_apollographqlerror2](https://github.com/user-attachments/assets/35692968-14ba-44a6-b3d2-a47f3892b05c)

And the warning I mentioned earlier keeps popping up during build!
https://github.com/vercel/next.js/issues/72525
![nextjs_turbopack_apollographqlerror3](https://github.com/user-attachments/assets/9f76862a-a8a6-4147-8995-a4355bd62de2)





When I run next dev --port 65000 without turbopack, the response comes as it should and works without any problems.
![nextjs_apollographql1](https://github.com/user-attachments/assets/bb46a8dd-b0e9-4b5e-8468-3a7b454d742f)
![nextjs_apollographql2](https://github.com/user-attachments/assets/d756aa09-7b8a-407f-8cbe-78862451ab97)


### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 32607
  Available CPU cores: 16
Binaries:
  Node: 23.4.0
  npm: 10.9.2
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 15.1.0 // Latest available version is detected (15.1.0).
  eslint-config-next: 15.0.3
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.2
Next.js Config:
  output: N/A
```


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

Turbopack

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

next dev (local), next build (local)

### Additional context

I am running it locally. I want to use my application with turbopack and get fast response. A powerful framework like apollographql needs to be supported by turbopack. @trevor-scheer, @martinnabhan
Repository: pytorch
Issue: Deprecate `torch.squeeze()` with unspecified `dim`
Labels: triaged,module: viewing and reshaping,module: python frontend

### 🚀 The feature, motivation and pitch

Deprecate unspecified `dim` in calls to `torch.squeeze()`, and/or issue a single runtime warning.


#### Rationale

`squeeze()` without an `dim` argument is the cause of many subtle bugs. Example:

```python
x = images[:batch_size]

B, C, H, W = x.shape

# Incorrect attempt to remove "grayscale" channel dimension.
gray = x.squeeze()
```

This causes hard-to-debug issues if:

- `B == 1`  (batch size is 1)
- `H == 1`  (height is 1)
- `W == 1`  (width is 1)

The above should have been written:

```python
gray = x.squeeze(1)
```


#### Examples in the wild

Many users of this library are not "experts" at code, and frequently produce and publish programs containing this bug.

Roughly 486000 bugs here:
https://github.com/search?q=language%3APython+squeeze%28%29&type=code
I challenge the reader to find an example which is *not* a (potential) bug!

[YOLOX (10k stars)](https://github.com/Megvii-BaseDetection/YOLOX/blob/d872c71bf63e1906ef7b7bb5a9d7a529c7a59e6a/yolox/utils/boxes.py#L49):
```python
        conf_mask = (image_pred[:, 4] * class_conf.squeeze() >= conf_thre).squeeze()
```

The correct code would have been:
```python
        conf_mask = image_pred[:, 4] * class_conf.squeeze(1) >= conf_thre
```

The above bug actually inspired the creation of this proposal. See also: https://github.com/numpy/numpy/issues/27968

---

P.S. On a similar note, `torch.eye(3).squeeze(0)` should also issue a runtime warning. NumPy correctly raises a full-fledged error in this case.

### Alternatives

_No response_

### Additional context

_No response_

cc @albanD
Repository: transformers
Issue: Improve tensor parallel memory usage
Labels: Feature request

### Feature request

Thanks to #34184 we can use TP for llama with only one line change. However the current implementation loads the whole model to each GPU in each rank before applying TP, significantly increasing the memory footprint.

### Motivation

We can load the model in CPU before applying TP. I tested this with llama3.1 8B on 2 GPUs. The memory usage is reduced from 60G to less than 20G. Below is my test script
```
import os
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from torch.distributed import device_mesh
from stainedglass_core.integrations.lm_eval.models.tensor_parallel.llama import parallelize_model

model_id = "meta-llama/Meta-Llama-3.1-8B-Instruct"

rank = int(os.environ["RANK"])
device = torch.device(f"cuda:{rank}")
torch.cuda.set_device(device)
torch.distributed.init_process_group("nccl")

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    device_map='cpu',
)
num_gpus = torch.cuda.device_count()
tp_mesh = device_mesh.init_device_mesh("cuda", (num_gpus,), mesh_dim_names=("tp",))
model.tensor_parallel(tp_mesh)
model.to(device)  # needed for weights and buffers that are not included by the TP plan

tokenizer = AutoTokenizer.from_pretrained(model_id)
prompt = "Can I help"
inputs = tokenizer(prompt, return_tensors="pt").input_ids.to(device)

outputs = model(inputs)
print(tokenizer.decode(outputs.logits.squeeze()[-1].argmax()))
```

### Your contribution

We can set `device_map` to `cpu` in `PreTrainedModel.from_pretrained` if `tp_plan` is not `None`, and apply TP  at the end.

happy to have discussions and work on a pr for this.

CC @kwen2501 @ArthurZucker
Repository: vscode
Issue: Add Cell toolbar remains sticky in blank notebook
Labels: bug,notebook-celltoolbar

### Applies To

- [x] Notebooks (.ipynb files)
- [ ] Interactive Window and\/or Cell Scripts (.py files with \#%% markers)

### What happened?

1. Create a new blank notebook (with no cells at all)
2. Open that blank notebook
3. Notice that the Add Cell toolbar is available without hovering (expected would be that this is only available on hover)
4. Add a few cells
5. Notice that the Add Cell toolbar at the top of the notebook remains sticky and is still available without hovering

Video recording: https://github.com/user-attachments/assets/64fb76f6-f3c6-4aae-8b61-7b5fcce23e89


### VS Code Version

Version: 1.96.0-insider (user setup) Commit: 54d1a4d6f395e73204ce0b5999439b267aec3fef Date: 2024-10-31T10:29:28.944Z Electron: 32.2.1 ElectronBuildId: 10427718 Chromium: 128.0.6613.186 Node.js: 20.18.0 V8: 12.8.374.38-electron.0 OS: Windows_NT x64 10.0.22621

### Jupyter Extension Version

Name: Jupyter Id: ms-toolsai.jupyter Description: Jupyter notebook support, interactive programming and computing that supports Intellisense, debugging and more. Version: 2024.11.2024103101 Publisher: Microsoft VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-toolsai.jupyter

### Jupyter logs

11:31:49.448 [info] Starting Kernel (Python Path: ~\projects\housing\Scripts\python.exe, Venv, 3.10.11) for '~\projects\housing\test.ipynb' (disableUI=true)
11:31:51.133 [info] Process Execution: ~\projects\housing\Scripts\python.exe -c "import ipykernel; print(ipykernel.__version__); print("5dc3a68c-e34e-4080-9c3e-2a532b2ccb4d"); print(ipykernel.__file__)"
11:31:51.152 [info] Process Execution: ~\projects\housing\Scripts\python.exe -m ipykernel_launcher --f=c:\Users\~\AppData\Roaming\jupyter\runtime\kernel-v3d91a32716d7e0e029c4de6545e6dd8e72d90bf73.json
    > cwd: ~\projects\housing
11:31:51.204 [info] Process Execution: ~\projects\housing\Scripts\python.exe -m pip list
11:31:56.103 [info] Kernel successfully started

### Coding Language and Runtime Version

_No response_

### Language Extension Version (if applicable)

_No response_

### Anaconda Version (if applicable)

_No response_

### Running Jupyter locally or remotely?

None
Repository: vscode
Issue: Re-opening a notebook results in failure to render output with the right renderer
Labels: bug,notebook-output

### Applies To

- [x] Notebooks (.ipynb files)
- [ ] Interactive Window and\/or Cell Scripts (.py files with \#%% markers)

### What happened?

[tqdm.zip](https://github.com/user-attachments/files/17686619/tqdm.zip)
The #16188 issue could be reproduced in the above file:
![Image](https://github.com/user-attachments/assets/a1d9b497-9bfe-41e2-b14c-2e1487b07d6f)


### VS Code Version

Version: 1.95.2 (system setup) Commit: e8653663e8840adaf45af01eab5c627a5af81807 Date: 2024-11-07T11:07:22.054Z Electron: 32.2.1 ElectronBuildId: 10427718 Chromium: 128.0.6613.186 Node.js: 20.18.0 V8: 12.8.374.38-electron.0 OS: Windows_NT x64 10.0.22000

### Jupyter Extension Version

v2024.10.0

### Jupyter logs

```shell

```

### Coding Language and Runtime Version

_No response_

### Language Extension Version (if applicable)

_No response_

### Anaconda Version (if applicable)

_No response_

### Running Jupyter locally or remotely?

None