sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tensorflow
Issue: tf.lite.Interpreter num_threads argument inconsistent documentation and functionality 
Labels: type:docs-bug,stat:awaiting tensorflower,comp:lite

The `tf.lite.Interpreter` [documentation](https://www.tensorflow.org/api_docs/python/tf/lite/Interpreter) claims:

num_threads:

Sets the number of threads used by the interpreter and available to CPU kernels. If not set, the interpreter will use an implementation-dependent default number of threads. Currently, only a subset of kernels, such as conv, support multi-threading. num_threads should be >= -1. Setting num_threads to 0 has the effect to disable multithreading, which is equivalent to setting num_threads to 1. **If set to the value -1, the number of threads used will be implementation-defined and platform-dependent.** 


However, the [code](https://github.com/tensorflow/tensorflow/blob/857e530ca9cef0dc12ca4aa8fa488a682d189748/tensorflow/lite/python/interpreter.py#L465) is different

```python
    if num_threads is not None:
      if not isinstance(num_threads, int):
        raise ValueError('type of num_threads should be int')
      if num_threads < 1:
        raise ValueError('num_threads should >= 1')
```

Therefore, if the num_threads variable is -1, it raises ValueError.
Repository: PowerToys
Issue: Allow filling of all available zones on desktop (not maximizing) instead of only two vertical columns.
Labels: Needs-Triage

### Description of the new feature / enhancement

This is pretty basic. For example, use the Priority default layout. Hover a windows over two zones, and it will fill two of the three zones. We should be able to fill all zones without having to maximize the window.

For instance, instead of just resizing the window to fill two of the three zones, it should be possible to fill all three zones of Priority (default FancyZone layout) when dragging, or through a shortcut, perhaps.

### Scenario when this would be used?

This would be used in all scenarios where a maximized window is not needed, but more than than two vertical columns of FancyZones are required. 

### Supporting information

_No response_
Repository: next.js
Issue: Parallel, intercepted catchall routes provided wrong params
Labels: bug,Parallel & Intercepting Routes

### Link to the code that reproduces this issue

https://github.com/Drewsapple/repro-intercept-catchall

### To Reproduce

1. Start the app (`next dev` or `next build && next start`)
2. navigate to `/reproduction`
3. click the link to `/reproduction/double/double`
4. refresh the page or otherwise load the same route so navigation is not intercepted

### Current vs. Expected behavior

When the default export from `(.)[...catchall]/page.tsx` is loaded, the params object passed is are follows:

Navigating to `/reproduction/single`
```
{"catchall":["single"]}
```

Navigating to `/reproduction/double/double`
```
{"catchall":["doubledouble"]}
```

Instead of the route segments being concatenated as strings, they should be concatenated as array elements, i.e.
```
{"catchall":["double","double"]}
```



### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Debian 6.11.6-1 (2024-11-04)
  Available memory (MB): 15748
  Available CPU cores: 8
Binaries:
  Node: 20.11.1
  npm: 10.9.0
  Yarn: N/A
  pnpm: 9.14.2
Relevant Packages:
  next: 14.2.18 // An outdated version detected (latest is 15.0.3), upgrade is highly recommended!
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.6.3
Next.js Config:
  output: N/A
```


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

Parallel & Intercepting Routes

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

next dev (local), next start (local)

### Additional context

I tried this in v14.2.14 as well, to see if it was a regression introduced by #65063 in v14.2.15, but the behavior was the same.

In v15.0.3 (with awaited params), the catchall group doesn't intercept a navigation with multiple path segments at all. This modification is tracked in the `v15.0.3` branch of the reproduction repo.
Repository: vscode
Issue: API to tell if a `Terminal` is a Task `Terminal`
Labels: feature-request,api,tasks


Type: <b>Bug</b>

Currently there is no way for extensions to detect the active terminal is a task. This is needed to determine if send text would work or not. 

VS Code version: Code - Insiders 1.96.0-insider (90868576241dd25c6c5da64adadc0a09de91a9fe, 2024-11-22T09:56:24.579Z)
OS version: Windows_NT x64 10.0.26100
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz (8 x 1498)|
|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<br>webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|31.60GB (14.23GB free)|
|Process Argv|--folder-uri file:///c%3A/GIT/LSP/pygls --log trace --log ms-python.python=info --crash-reporter-id 4fb1ebc1-cf4c-4880-a88a-47738ec3768d|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (19)</summary>

Extension|Author (truncated)|Version
---|---|---
tsl-problem-matcher|amo|0.6.2
ruff|cha|2024.56.0
esbuild-problem-matchers|con|0.0.3
vscode-eslint|dba|3.0.10
gitlens|eam|16.0.2
EditorConfig|Edi|0.16.4
prettier-vscode|esb|11.0.0
copilot|Git|1.245.1224
copilot-chat|Git|0.23.2024112103
vscode-github-actions|git|0.27.0
vscode-pull-request-github|Git|0.101.2024112104
debugpy|ms-|2024.12.0
python|ms-|2024.21.0-dev
vscode-pylance|ms-|2024.11.3
vscode-python-envs|ms-|0.0.0
remote-containers|ms-|0.388.0
remote-wsl|ms-|0.88.5
extension-test-runner|ms-|0.0.12
code-spell-checker|str|4.0.21


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vsc_aacf:30263846
pythonvspyt551:31179976
vscod805cf:30301675
vsaa593cf:30376535
py29gd2263:31024238
c4g48928:30535728
vscrpc:30624061
a9j8j154:30646983
962ge761:30841072
pythonnoceb:30776497
asynctok:30898717
dsvsc014:30777825
dsvsc015:30821418
pythonmypyd1:30859725
h48ei257:31000450
pythontbext0:30879054
cppperfnew:30980852
pythonait:30973460
0ee40948:31013168
dvdeprecation:31040973
dwnewjupytercf:31046870
newcmakeconfigv2:31071590
nativerepl1:31134653
pythonrstrctxt:31093868
nativeloc1:31118317
cf971741:31144450
notreesitter:31116712
e80f6927:31120813
iacca1:31150324
notype1:31143044
dwcopilot:31158714
h409b430:31177054
5b1c1929:31184661

```

</details>

<!-- generated by issue reporter -->
Repository: pytorch
Issue: PyTorch crashes with `mkl_lapack_dgetrf` if `from_numpy and set_num_threads` are used
Labels: module: crash,triaged,module: mkl,module: multithreading,module: linear algebra,module: intel

### 🐛 Describe the bug

Running
```python
import torch
print(torch.linalg.inv(torch.rand(100, 200, 200)))
```
Hangs/fails with
```
Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.
Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.

Intel MKL ERROR: Parameter 6 was incorrect on entry to DLASWP.
```

And following backtrace
```
Process 2200668 stopped
* thread #1, name = 'pt_main_thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fffe648f267 libtorch_cpu.so`mkl_lapack_cdag1d_probe_task + 71
libtorch_cpu.so`mkl_lapack_cdag1d_probe_task:
->  0x7fffe648f267 <+71>: movq   0x40(%rbp), %r10
    0x7fffe648f26b <+75>: movq   (%rbp), %r9
    0x7fffe648f26f <+79>: leaq   0x1(%r10), %rdx
    0x7fffe648f273 <+83>: cmpq   %r9, %rdx
(lldb) bt
* thread #1, name = 'pt_main_thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fffe648f267 libtorch_cpu.so`mkl_lapack_cdag1d_probe_task + 71
    frame #1: 0x00007fffe61a011e libtorch_cpu.so`thread_team_ctxt_thread_for_task_hint + 30
    frame #2: 0x00007fffe648fe4a libtorch_cpu.so`mkl_lapack_thread_team_ctxt_get_task + 682
    frame #3: 0x00007fffe61a047b libtorch_cpu.so`mkl_lapack_dgetrf._omp_fn.0 + 395
    frame #4: 0x00007fffe61a2bd5 libtorch_cpu.so`mkl_lapack_dgetrf + 3381
    frame #5: 0x00007fffe61463dc libtorch_cpu.so`dgetrf_ + 748
    frame #6: 0x00007fffe04cdde4 libtorch_cpu.so`void at::native::lapackLu<double>(int, int, double*, int, int*, int*) + 36
    frame #7: 0x00007fffe04ee1b9 libtorch_cpu.so`void at::internal::invoke_parallel<void at::parallel_for<void at::native::(anonymous namespace)::apply_lu_factor<double>(at::Tensor const&, at::Tensor const&, at::Tensor const&, bool)::'lambda'(long, long)>(long, long, long, double const&)::'lambda'(long, long)>(long, long, long, double const&) (._omp_fn.0) + 297
    frame #8: 0x00007ffff707f05f libgomp-a34b3233.so.1`GOMP_parallel + 63
    frame #9: 0x00007fffe04f1b20 libtorch_cpu.so`at::native::(anonymous namespace)::lu_factor_kernel(at::Tensor const&, at::Tensor const&, at::Tensor const&, bool) + 3664

```

### Versions

2.3.1, 2.5.1

cc @albanD @jianyuh @nikitaved @pearu @mruberry @walterddr @xwang233 @Lezcano @frank-wei @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
Repository: flutter
Issue: Flutter Widget Previews Architecture
Labels: design doc,:scroll:

### Document Link

https://flutter.dev/go/widget-previews-architecture

### What problem are you solving?

While one of the main selling points of Flutter is its rapid iterative development cycle that’s enabled by hot reload, it does require developers to have an active target device or simulator to work. In addition, it only allows for viewing the UI in a single configuration at a time without running an application on multiple devices, making it difficult for developers to visually verify the impact of variables like screen size, orientation, font size, and locale on their application.

Flutter Widget Previews is a development tool designed to improve the Flutter development workflow by allowing developers to quickly visualize and iterate on their widgets in various configurations without running the full application. This tool aims to significantly reduce development time and improve the overall developer experience by providing a fast and convenient way to experiment with widget variations, themes, and different device settings.
Repository: godot
Issue: OS.move_to_trash() makes window lose and gain focus
Labels: bug,topic:editor,needs testing

### Tested versions

Reproduced in 4.3 stable and 4.2 stable

### System information

Godot v4.3.stable - Windows 10 - GLES3 (Compatibility)

### Issue description

calling the OS.move_to_trash() function will cause the application window to lose and gain focus.

there are more issues with the window losing/gaining focus (see #99438), but I dont know if thats related.

### Steps to reproduce

create a node and attache a script with the following code:

```gdscript
func _ready() -> void:
	get_window().focus_entered.connect(func_print.bind("enter"))
	get_window().focus_exited.connect(func_print.bind("exit"))
	
	await get_tree().create_timer(0.5).timeout
	OS.move_to_trash("res://not_exists.txt") # this will also cause an error 124 in the debug (note: error 124 is not defined in the return values btw), because input was not a global path, but it does not matter for the demonstration (window always loses & gains focus - no matter, if operation was successful or not)


func func_print(text):
	print(text)
```

the window will lose focus and gain it again shown in the output:
```
exit
enter
```

### Minimal reproduction project (MRP)

[trash-bug.zip](https://github.com/user-attachments/files/17874761/trash-bug.zip)
Repository: react-native
Issue: SectionList's `onScrollToIndexFailed` does not catch requested sectionIndex & itemIndex
Labels: Issue: Author Provided Repro,Component: SectionList,Needs: Attention,Needs: Version Info

### Description

`onScrollToIndexFailed` returns index,heighestMeasuredIndex, and averageItemHeight, which is enough in FlatList.
but in sectionList it should return requested sectionIndex and itemIndex, and heighestMeasured section & item index in addition to flat index, because we have only scrollToLocation method available for sectionList and section and item index params are needed.

### Steps to reproduce

run the snack, press on `scroll to no where`, you will see the alert

### React Native Version

0.76.3

### Affected Platforms

Runtime - Android, Runtime - iOS, Runtime - Web, Runtime - Desktop, Build - MacOS, Build - Windows, Build - Linux

### Output of `npx react-native info`

```text
System:
  OS: Windows 11 10.0.22000
  CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
  Memory: 8.47 GB / 15.89 GB
Binaries:
  Node:
    version: 23.0.0
    path: C:\Program Files\nodejs\node.EXE
  Yarn:
    version: 1.22.0
    path: C:\Program Files (x86)\Yarn\bin\yarn.CMD
  npm:
    version: 10.9.0
    path: C:\Program Files\nodejs\npm.CMD
  Watchman:
    version: 20241027.093345.0
    path: E:\Software\Watchman\bin\watchman.EXE
SDKs:
  Android SDK: Not Found
  Windows SDK:
    AllowDevelopmentWithoutDevLicense: Enabled
    AllowAllTrustedApps: Disabled
IDEs:
  Android Studio: Not Found
  Visual Studio: Not Found
Languages:
  Java:
    version: 21.0.3
    path: /c/Program Files/Eclipse Adoptium/jdk-21.0.3.9-hotspot/bin/javac
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.76.2
    wanted: 0.76.2
  react-native-windows: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found
```


### Stacktrace or Logs

```text
scroll to index failed
```


### Reproducer

https://snack.expo.dev/@arasrezaie/sectionlist-example

### Screenshots and Videos

_No response_
Repository: go
Issue: all: reopen tree for Go 1.25 development
Labels: NeedsInvestigation,early-in-cycle,umbrella

### Current Tree Status: Release freeze for Go 1.24 (see [golang-dev announcement](https://groups.google.com/g/golang-dev/c/JkRenbsSBv4/m/dhcurHI5CwAJ))

Now that we've entered the freeze for Go 1.24, we will eventually need to reopen the tree for Go 1.25 development. This is the tracking issue for that reopening, created early so that it's available for planning. The tree reopening is estimated to begin around week 3 of January 2025 (see https://go.dev/s/release#timeline), exact timing depends on how well the Go 1.24 release preparations are going.

As usual, the tree will initially be open to changes that must land early:

- [ ] Bump `internal/goversion.Version` to 25—this should be the very first CL to be submitted as it marks the start of main branch representing Go 1.25 (rather than Go 1.24). ([Example CL](https://go.dev/cl/600176).)
  - #40705
- [ ] Initialize `doc/next` for the Go 1.25 cycle. (See "For the release team" in [doc/README](https://cs.opensource.google/go/go/+/master:doc/README.md).)
- [ ] Submit CLs that are ready and marked AutoSubmit+1, but blocked on wait-release ([query](https://go-review.googlesource.com/q/is:open+label:Auto-Submit%3D%252B1+label:Code-Review%3D%252B2+-label:Hold%3D%252B1+-label:TryBots-Pass%3DNEED+-label:Legacy-TryBots-Pass%3DNEED+-has:unresolved+hashtag:wait-release+-is:wip+-label:Do-Not-Review%3DNEED+-label:Do-Not-Submit%3DNEED)).
- [ ] Look over issues labelled as [early-in-cycle](https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3Aearly-in-cycle+milestone%3AGo1.25) for anything needs to land very early.
- [ ] Submit CL for #49580.
- _(Anything else that is missing but should be added here, edit or comment below.)_
- [ ] A brief soft-reopening window, where any fix/stabilization CLs are okay to submit.
- [ ] Finally, open the tree for all general Go 1.25 changes.

CC @golang/release.
Repository: vscode
Issue: Customizable Marketplace message for denylisted extensions and extension updates
Labels: feature-request,extensions

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

**This feature request is an add-on to the extension allowlist/denylist under development in https://github.com/microsoft/vscode/issues/84756.** cc @isidorn who requested that this be filed as a separate request.

The VS Code Marketplace is a great place for engineers to discover new extensions directly in their editor. We would love to maintain the usability of this Marketplace even with a strict allowlist policy in place so that our engineers have actionable information on what to do to allowlist an extension (or its update) within our organization.

Organizations will have different procedures for modifying the allowlist. Stripe has an online approval flow for new software dependencies that would be augmented with VS Code extensions once the  allowlist functionality is available. Users would need to navigate to this form, fill it out for the specific extension and version, and get it approved.

It would be wonderful if VS Code supported modifying the message that shows up or is displayed when an extension is denylisted. If the message could be templated with the `extension_id` and `version`, we could even render a link directly to a pre-filled out web form, which would remove a lot of the friction from allowlisting a new extension.

For example, we might render something like:

> $extension_id@$extension_version is not an approved VS Code extension at Stripe. You can begin the approval for this extension at http://go/vscode-extn/$extension_id@$extension_version

Ideally, the link would be clickable and redirect to the relevant form, with most fields pre-filled out.

**If there is no UI space for an interactable message like this**, then I would also accept a configurable URL (templated with extension ID and version) that is put somewhere for the user to visit for more info; we could link to a templated help document that then links to the form if the user decides they want to allowlist the extension. (Maybe a "More info" button or link?)
Repository: pytorch
Issue: Doc for `assign` parameter of `load_state_dict` is not rendered correctly
Labels: module: docs,module: serialization,triaged,actionable

### 📚 The doc issue

https://pytorch.org/docs/stable/generated/torch.nn.Module.html

![image](https://github.com/user-attachments/assets/e585ff09-7937-46d3-84d0-68563b5ea695)

https://github.com/pytorch/pytorch/blob/7c5c38da2349c23fdfcbae065153ccef32471b14/torch/nn/modules/module.py#L2495-L2500

```:class:`~torch.nn.Parameter`s for which the value from the module is preserved. ``` is not shown.


### Suggest a potential alternative/fix

_No response_

cc @svekars @brycebortree @sekyondaMeta @AlannaBurke @mruberry @mikaylagawarecki
Repository: godot
Issue: CI / CD Headless Mono Export(s) don't work
Labels: bug,topic:export

### Tested versions

- Reproducible in Godot 4.3 Mono

### System information

Godot v4.3.stable.mono unknown - Arch Linux #1 SMP PREEMPT_DYNAMIC Sun, 17 Nov 2024 16:06:17 +0000 - Wayland - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 (nvidia; 565.57.01) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

### Issue description

When exporting Godot Mono projects from the CLI. Using `godot-mono --headless --export-release "Linux-Profile" "build/path/game.x86_64"` from a docker container does not yield a playable build. Using a CI / CD docker container with supporting dependencies again isn't yielding a playable build with godo mono. Building projects locally through either a local CLI, or the GUI to export a build works as intended. When running one of these builds locally, it yields errors saying the executable cannot locate resources. Even though there are valid *.pck file produced with the build and the supported resources are included in the produced *.pck file.

### Steps to reproduce

Here is a link to a minimally reproducible build [https://gitlab.com/benscodeworks/godot-docker-ci](godot gitlab project). There are two different ways to recreate the issue. One is by cloning / forking my repository and running the pipeline and observing the artifacts produced. Then trying to run them on a local x86 supported Linux platform.
The other way is to clone the repository and have docker installed on your local machine.

1. run `cd into/the/repo`
2. run `docker build --tag my-docker-tag .`
3. run `docker run -it --name godot-test-container -v "$(pwd)":/app -w /app my-docker-tag /bin/bash`
4. run `mkdir -p build`
5. run `godot-mono --headless --verbose --export-release "CI-Linux" build/mvp.x86_64`
6. exit the docker container using `exit` from the command line
7. run the game file from outside the docker container and observe the errors produced. `./build/mvp.x86`

### Minimal reproduction project (MRP)

https://gitlab.com/benscodeworks/godot-docker-ci
Minimally reproducible project with Dockerfile and relevant gitlab pipelines.

https://hub.docker.com/repository/docker/benscodeworks/godot-mono-ci/general
Additionally, I have my docker build image out there for further investigation.
Repository: go
Issue: runtime/pprof: theoretical appendLocsForStack panic with SIGPROF between cgocallback and exitsyscall
Labels: NeedsInvestigation,compiler/runtime

[`runtime/pprof.appendLocsForStack`](https://cs.opensource.google/go/go/+/master:src/runtime/pprof/proto.go;l=445;drc=ca63101df47a4467bc80faa654fc19d68e583952) asserts that an inline-expanded PC always expands to the same number of logical PCs (inlined frames). This is a static property of a given PC, so it should always be true.

When handling SIGPROF, if we are on an extra M running in C, we [don't try to traceback](https://cs.opensource.google/go/go/+/master:src/runtime/signal_unix.go;l=443;drc=944df9a7516021f0405cd8adb1e6894ae9872cb5) since this is C anyway, and just add a sample with stack `{pc, runtime._ExternalCode}`.

"We are on an extra M running in C" is defined as `gp.m.isExtraInC`. In `cgocallbackg`, we [clear this field](https://cs.opensource.google/go/go/+/master:src/runtime/cgocall.go;l=341;drc=4aa1c02daee42c37ddd30ae2aa91bd3fd3b72e77;bpv=1;bpt=1) after `exitsyscall` returns. This leaves a fairly long window when we are in fact running Go code, but the SIGPROF handler will think it is in C.

A lot of this code (particularly in `exitsyscall`) is reachable from normal Go code as well. If any of this code has more than 2  inlined frames at a single PC, then a SIGPROF from a normal Go context followed by a SIGPROF in this `cgocallback` context could trigger this `appendLocsForStack` panic.

I do not know if any code reachable in this window actually has more than 2 inlined frames. Only 2 frames is insufficient, as `appendLocsForStack` wouldn't actually care that the second frame is `runtime._ExternalCode` instead of the proper frame.

One potential fix is to attempt to do inline expansion in `sigprofNonGoPC` in case it actually is a Go PC.