sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: transformers
Issue: Tokenizer `encode/decode` methods are inconsistent, TypeError: argument 'ids': 'list' object cannot be interpreted as an integer
Labels: Feature request

### System Info

- `transformers` version: 4.35.2
- Platform: Linux-6.5.0-14-generic-x86_64-with-glibc2.35
- Python version: 3.11.6
- Huggingface_hub version: 0.20.2
- Safetensors version: 0.4.1
- Accelerate version: not installed
- Accelerate config: not found
- PyTorch version (GPU?): 2.0.1+cu117 (True)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using GPU in script?: <fill in>
- Using distributed or parallel set-up in script?: <fill in>


### Who can help?

@ArthurZucker

### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [X] My own task or dataset (give details below)

### Reproduction

Run the following code:
```python
from transformers import AutoTokenizer

text = "test"
tokenizer = AutoTokenizer.from_pretrained("gpt2")
encoded = tokenizer.encode(text, return_tensors='pt')
result_text = tokenizer.decode(encoded, skip_special_tokens=True)
print(text)
```

Will raise exception:
```
Traceback (most recent call last):
  File "main.py", line 8, in <module>
    tokenizer.decode(encoded, skip_special_tokens=True)
  File "/home/scruel/mambaforge/envs/vae/lib/python3.11/site-packages/transformers/tokenization_utils_base.py", line 3748, in decode
    return self._decode(
           ^^^^^^^^^^^^^
  File "/home/scruel/mambaforge/envs/vae/lib/python3.11/site-packages/transformers/tokenization_utils_fast.py", line 625, in _decode
    text = self._tokenizer.decode(token_ids, skip_special_tokens=skip_special_tokens)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: argument 'ids': 'list' object cannot be interpreted as an integer
```

### Expected behavior

Should be able to print the original text `"test"`, rather than raise an exception(`TypeError`).
Repository: go
Issue: hash/crc32: wrong hash code for CRC32-Q in documented example
Labels: Documentation,NeedsInvestigation

### Go version

not relevant

### Output of `go env` in your module/workspace:

```shell
not relevant
```


### What did you do?

The example on https://pkg.go.dev/hash/crc32#example-MakeTable uses the polynomial for CRC32-Q when producing a checksum, so it looks like it should be producing the correct CRC32-Q checksum.





### What did you see happen?

The produced checksum value - 2964d064 - is not correct.

The reason is that hash/crc32 only support some specific variations of crc32 algorithms, and CRC32-Q requires other settings than those implemented in hash/crc32. There is a proposal to support other variants in #60992 .


### What did you expect to see?

The expected output when computing the CRC32-Q checksum for "Hello world" is "0xA790E213", as here: https://crccalc.com/?crc=Hello+world&method=CRC-32Q&datatype=ascii&outtype=0


The simplest fix here is to remove the example, and I think that would be an improvement. It is better to not provide a wrong example.

It would be more helpful to give some hints about the pitfalls, though.

I have attempted to fix the example on https://go.dev/play/p/_avQEOSV2uJ, but maybe this is too complicated to put in the standard documentation.
Repository: opencv
Issue: Document cv::Mat::type bits layout
Labels: category: documentation

### Describe the doc issue

cv::Mat::type is bit-filed, but bits semantic is not obvious.

### Fix suggestion

Create 2 independent PRs: for 4.x and 5.x as branches have differences.
Repository: tauri
Issue: [bug] White window on prod build on Linux
Labels: type: bug,platform: Linux,status: needs triage

### Describe the bug

When opening production build of tauri in Linux the window is completly white. on cargo tauri dev it works normally and the window responsive. environemnt is `ubuntu 22.04.3 LTS` and `WAYLAND`

### Reproduction

Build any app of tauri or the one I used [vibe](https://github.com/thewh1teagle/vibe) and start it's appImage

### Expected behavior

The window should open normally and be responsive

### Full `tauri info` output

```text
[✔] Environment
    - OS: Ubuntu 22.04 X64
    ✔ webkit2gtk-4.0: 2.42.4
    ✔ rsvg2: 2.52.5
    ✔ rustc: 1.75.0 (82e1608df 2023-12-21)
    ✔ cargo: 1.75.0 (1d8b05cdd 2023-11-20)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.7.0
    - npm: 10.1.0
    - bun: 1.0.3

[-] Packages
    - tauri [RUST]: 1.5.4
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.5
    - tauri-cli [RUST]: 1.5.9
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 1.5.9

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: React
```


### Stack trace

_No response_

### Additional context
https://discord.com/channels/616186924390023171/1198765010558664704
WAYLAND!
Repository: PowerToys
Issue: Fail Fast Exception when launching PowerToys Settings
Labels: Issue-Bug,Product-Settings,Severity-High,Needs-Triage

### Microsoft PowerToys version

0.77.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Settings

### Steps to reproduce

The issue started after updating the app from 0.66 to 0.77. The error pops up directly after starting the PowerToys settings

### ✔️ Expected Behavior

the powertoys settings menu would open

### ❌ Actual Behavior

an error pops up saying "A fail fast exception occurred. Exception handlers will not be invoked and the process will be terminated immediately". I can see that the fancy zones are working though, it is just not possible to get into the settings.

![image](https://github.com/microsoft/PowerToys/assets/68536969/766a192c-1d1a-4a7c-a773-b3cdd91ea29c)

tried to run as admin or not.

### Other Software

_No response_
Repository: opencv
Issue: Make BarcodeDetector resolution invariant
Labels: feature

### Describe the feature and motivation

The ```cv::barcode::BarcodeDetector``` relies on hardcoded parameters in ```bardetect.cpp```. 

The barcode localisation algorithm is very good, but it has some limitations in terms of high-res and small barcode inputs that make it both resolution and barcode scale **dependent**. 

I had managed to figure out four values that impact this:
- the input image is downsampled to 512px by default (a workaround is to use ```np.lib.stride_tricks.sliding_window_view``` to process the image in patches, and NMS the resulting boxes afterwards which is inefficient).
- the gradient magnitude threshold is permanently set to 64. 
- window sizes for filters have been empirically determined with respect to input size and is not possible to adjust them ```{0.01f, 0.03f, 0.06f, 0.08f}``` for other scenarios.
- the NMS Box threshold is calculated and set for a 512px wide image

There are a lot more parameters in ```bardetect.cpp``` but these are the most relevant ones which need to be tuned to improve the barcode localisation performance. 

This is what the stock detector returns for a 2048x1536 input image. 
![detector_params_fail](https://github.com/opencv/opencv/assets/69245609/2062fd83-1bc8-45cd-aa3f-e3e50045df6c)

Obviously this is very poor performance. But after manually adjusting these parameters, I am able to successfully localise each barcode in the image.

![detector_params_success](https://github.com/opencv/opencv/assets/69245609/92369a2d-617d-467e-8255-1b95a29a141d)

### Additional context

Proposal on how to set detector parameters, and reference values used for the test pattern. 

```
detector = cv2.barcode.BarcodeDetector()

div = float(np.max(frame.shape)) / 512.
detector.setDownSampleThresh( div * 512 ) # prevent downsample
detector.setDetectorScales( [ 0.01/div, 0.03/div, 0.06/div, 0.08/div ] )
detector.setGradientThresh( 256 )
```

This should keep compatibility and maintain the current behaviour of the standard barcode detector. 

**Reference image**
![testpattern](https://github.com/opencv/opencv/assets/69245609/c471921c-80b0-4791-b654-674a3bd51ee1)

LE: Updated proposal to set detector parameters per 24903
Repository: next.js
Issue: Interception of a parallel route clash
Labels: bug,linear: next

### Link to the code that reproduces this issue

https://github.com/javiermartinz/nextgram

### To Reproduce

1. Visit https://nextgram-javiermartinz.vercel.app/
2. Click on the buggy link
3. You'll see the app crashing because the route is intercepted.

### Current vs. Expected behavior

## Current
Dynamic route intercepted, although there is an static route for it

## Expected
Only dynamic route intercepted. Static route should use a regular redirect to be fully shown.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000
Binaries:
  Node: 20.8.0
  npm: 10.1.0
  Yarn: 1.22.19
  pnpm: 8.14.1
Relevant Packages:
  next: 14.1.1-canary.5 // Latest available version is detected (14.1.1-canary.5).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


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

App Router

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

next dev (local), next build (local), next start (local), Vercel (Deployed)

### Additional context

_No response_

<sub>[NEXT-2186](https://linear.app/vercel/issue/NEXT-2186/interception-of-a-parallel-route-clash)</sub>
Repository: go
Issue: go/types, cmd/compile/internal/types2: type inference limitation leads to incorrect result for directed channel type constraint
Labels: NeedsInvestigation,generics,TypeInference

### Proposal Details

Think such code:
can be found here: https://go.dev/play/p/qNBK9KjxqrW
```go
func Chan[E any, C ~<-chan E](c C) {}

func x() {
    c := make(chan int)
    Chan(c)
}
```

then `Chan(c)` produce `chan int does not satisfy ~<-chan int (chan int missing in ~<-chan int)`


In my opinion, this is a flaw in generic design that should be supported
Repository: vscode
Issue: Test runners in vscode are much slower than pycharm
Labels: bug,perf,testing,python

Running tests in pycharm are much faster than in vscode. This poses a significant disadvantage for vscode for any serious Python project that has a large test suite.
Repository: electron
Issue: [Bug]: `backgroundMaterial` effect does not work on first page load
Labels: platform/windows,bug :beetle:,status/confirmed,has-repro-gist,29-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

29.0.0-alpha.11

### What operating system are you using?

Windows

### Operating System Version

Windows 11

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

`backgroundMaterial` should works with `transparent: true` property.

### Actual Behavior

`backgroundMaterial` effect does not work on first page load in frameless window. But it starts working after resizing the window. Without `transparent: true`, `backgroundMaterial` works as intended. 

### Testcase Gist URL

https://gist.github.com/cb33c3357860dd393b4155ff63db585e

### Additional Information

_No response_
Repository: next.js
Issue: Enabling "draftMode" and redirection with search params
Labels: bug

### Link to the code that reproduces this issue

https://github.com/rootkowsky/nextjs-preview

### To Reproduce

The **local** approach:
1. Clone repository
2. Run `npm install && npm run build && npm run start`
3. Open `localhost:3000/api/preview?slug=foo` (you will be redirected to `/foo?revision_id=<...>`)
4. Notice that the `revisionId` is available on Server and Client (`app/[page]/page.tsx`)
![Screenshot 2024-01-22 at 13 46 09](https://github.com/vercel/next.js/assets/8841245/8bd3fd32-7c64-4069-9ba6-4c89e166c454)

The **vercel** approach:
1. Deploy repository on vercel
2. Open `custom-domain.vercel.app/api/preview?slug=foo` (you will be redirected to `/foo?revision_id=<...>`)
4. Notice that the `revisionId` is not available on Server and Client (`app/[page]/page.tsx`)
![Screenshot 2024-01-22 at 13 45 23](https://github.com/vercel/next.js/assets/8841245/cda2d01a-776a-4f18-b422-631a11a8865a)


### Current vs. Expected behavior

The `searchParams` are available in the Server Components locally,
but they are not available in the Server Components on the Vercel environment.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:28:12 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T8103
Binaries:
  Node: 18.17.1
  npm: 9.6.7
  Yarn: 1.22.17
  pnpm: N/A
Relevant Packages:
  next: 14.1.0
  eslint-config-next: 14.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


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

App Router

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

next start (local), Vercel (Deployed)

### Additional context

_No response_
Repository: electron
Issue: [Bug]: `backgroundMaterial` causes a black screen when maximized
Labels: platform/windows,bug :beetle:,status/confirmed,has-repro-gist,29-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

29.0.0-alpha.11

### What operating system are you using?

Windows

### Operating System Version

Windows 11

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

No black screen.

### Actual Behavior

Frameless window with the `backgroundMaterial` option enabled causes a black screen when maximized.

### Testcase Gist URL

https://gist.github.com/36b045c1ac8c8a0a00f046fa9ba68001

### Additional Information

_No response_
Repository: material-ui
Issue: [material-next][ProgressIndicator] Update the designs according to MD3
Labels: on hold,component: CircularProgress,component: LinearProgress,package: material-ui,design: material you

⚠️  This is `on hold` and part of #29345 ⚠️ 

### Summary

The Material Design team recently updated the progress indicators guidelines. This issue is to update the current designs with the recent iteration of both the `CircularProgress` and `LinearProgress` in Material You. 

`ProgressIndicator` specification: https://m3.material.io/components/progress-indicators/overview

| Current | Recent iteration |
|--------|--------|
| ![image](https://github.com/mui/material-ui/assets/37222944/70c29cfc-881c-493c-b700-c17aecaa89ce) | ![image](https://github.com/mui/material-ui/assets/37222944/d5f0f30c-46cd-4b66-80e1-b9936d832ee9) |
Repository: vscode
Issue: add label:vscode.dev to URL for "Search Feature Requests"
Labels: polish,menus

Under the Help drop-down, the URL for "Search Feature Requests" should be https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Afeature-request+label%3Avscode.dev+sort%3Areactions-%2B1-desc+

Version: 1.85.2
Commit: 8b3775030ed1a69b13e4f4c628c612102e30a681
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Safari/605.1.15
Embedder: vscode.dev
Repository: material-ui
Issue: [material-next][Slider] Update the designs according to MD3
Labels: on hold,component: slider,package: material-ui,design: material you

⚠️  This is `on hold` and part of #29345 ⚠️ 

### Summary

The Material Design team recently updated the `Slider` guidelines. This issue is to update the current designs with the recent iteration of the `Slider` in Material You. 

`Slider` specification: https://m3.material.io/components/sliders/overview

| Current | Recent iteration |
|--------|--------|
| ![image](https://github.com/mui/material-ui/assets/37222944/ab1396cc-5091-42b6-870a-a0d630dfbe20) | ![image](https://github.com/mui/material-ui/assets/37222944/3d48eed5-301e-4981-ade9-ce649290ed10) |
Repository: go
Issue: x/pkgsite: remove stdlib branches
Labels: pkgsite

pkgsite has custom code for fetching two stdlib branches, dev.boringcrypto and dev.fuzz. The first hasn't had a commit for a year and the second for over 2 years. Neither one is in the DB now. I'm going to remove the code for these.
Repository: rust
Issue: never patterns: `!` argument not detected as diverging on async fn
Labels: T-compiler,C-bug,A-async-await,AsyncAwait-Triaged,WG-async,requires-incomplete-features,F-never_patterns

With https://github.com/rust-lang/rust/pull/120104, a function with a `!` pattern in a binding is detected as diverging:
```rust
fn never_arg(!: Void) -> ! {}
fn never_let(x: Void) -> ! {
  let ! = x;
}
```

This doesn't work the arguments of an `async` fn however:
```rust
async fn never_let(x: Void) -> ! {
  let ! = x;
} // ok
async fn never_arg(!: Void) -> ! {} // ERROR mistmatched types
```
Repository: flutter
Issue: Test "PageScrollPhysics work with NestedScrollView" is failing flakily on monorepo
Labels: a: tests,framework,f: scrolling,P2,c: flake,team-framework,triaged-framework

The test

    test/widgets/scroll_physics_test.dart: PageScrollPhysics work with NestedScrollView

in test shard web_tests subshard 0 is failing flakily on monorepo builds, and has started to fail more frequently (about 20% of the time).

These failures happen on the monorepo builders but not on the flutter CI builder
https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20web_tests_0

I don't see that there is any automatic deflaking on the flutter CI, that is somehow hiding or removing these failures, but perhaps there is and I don't know how to see it.

I don't see a difference between the way it is run, except that Flutter CI is using "Google Chrome for Testing 119.0.6045.9" and monorepo builds are using "Chromium 114.0.5735.0".

Failing builds and error logs can be seen at https://ci.chromium.org/ui/p/dart/builders/ci.sandbox/flutter-linux-web-tests-0

The error is
```
00:05 +11: test/widgets/scroll_physics_test.dart: PageScrollPhysics work with NestedScrollView                                                                                                         
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following assertion was thrown running a test:
The finder "Found 0 widgets with text "Index 2": []" (used in a call to "fling()") could not find
any matching widgets.

When the exception was thrown, this was the stack:
../dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 328:3  throw_
../packages/flutter_test/src/test_text_input_key_handler.dart.js 9423:19        [_getElementPoint]
../packages/flutter_test/src/test_text_input_key_handler.dart.js 9341:38        getCenter
../packages/flutter_test/src/test_text_input_key_handler.dart.js 9101:34        fling
scroll_physics_test.dart.js 421:20                                              <fn>
```
Repository: vscode
Issue: Tree Sticky Scroll: Support mouse interaction with compressed nodes
Labels: feature-request,tree-sticky-scroll

Sticky scroll currently does not support clicking on intermediate nodes in a compressed node

#199539
Repository: material-ui
Issue: [Button] Add three-valued button
Labels: new feature,waiting for 👍,component: toggle button

### Search keywords

three-valued button checkbox

### Latest version

- [X] I have tested the latest version

### Summary

The three-valued button represents a control that implements [the three-valued logic](https://en.wikipedia.org/wiki/Three-valued_logic).

<img width="314" alt="Three-valued button states" src="https://github.com/whatwg/html/assets/31864557/9ab52bff-1994-4b6a-82cf-f4454325eebf">

The `true` state is equivalent to the `checked` state of the checkbox.
The `unknown` state is equivalent to the `unchecked` state of the checkbox.
The `false` state has no equivalent for the checkbox. This state means prohibition of the specified search criterion.
The `all` state is equivalent to the `undefined` state of the checkbox.

These states must be looped (but it is preferable to use a dropdown list/menu of states):

- `unknown` -> `true` -> `false` -> `unknown`
- `all` -> `true` -> `false` -> `unknown` -> `all` (for group button)


### Examples

There are only homemade solutions now that are similar to my proposal, for example, in Nigma search engine:
![Nigma](https://github.com/whatwg/html/assets/31864557/76ec965c-63b2-4398-9e93-edbe49be05c1)

### Motivation

This new feature should be used instead of a checkbox, for example, to apply **or prohibit** the specified search criterion from a list of criteria.
Repository: material-ui
Issue: [material-ui][Chip] Add three-valued filter chip with additional prohibiting state
Labels: new feature,waiting for 👍,component: chip

### Summary

The three-valued chip represents a control that implements [the three-valued logic](https://en.wikipedia.org/wiki/Three-valued_logic).

<img width="382" alt="Prohibition filter chips" src="https://github.com/material-components/material-components/assets/31864557/083d7e48-6510-4978-9c25-44cd928db93e">

These states must be looped:
`disabled` -> `enabled` -> `prohibited` -> `disabled`

A combination of two-valued and three-valued filter chips is allowed.

### Examples

There are only homemade solutions now that are similar to my proposal, for example, in Nigma search engine:
![Nigma](https://github.com/whatwg/html/assets/31864557/76ec965c-63b2-4398-9e93-edbe49be05c1)

### Motivation

This new feature should be used to apply **or prohibit** the specified search criterion.

**Search keywords**: three-valued filter chip
Repository: PowerToys
Issue: Command not found allows you to select install even if it has known required components missing
Labels: Issue-Bug,Product-CommandNotFound

### Microsoft PowerToys version

0.77.0

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Command not found

### Steps to reproduce

Go to the Command Not Found Settings, and the panel allows you to install the powershell 7 module even though its correct detects missing components.

<img width="772" alt="image" src="https://github.com/microsoft/PowerToys/assets/12837710/02c18001-9734-4d3e-8755-390f79cd4a39">

If you chose to install it, you get an expected error when launching powershell.

<img width="854" alt="image" src="https://github.com/microsoft/PowerToys/assets/12837710/2827f58a-ebe6-44de-994a-0e0f4d28b288">



### ✔️ Expected Behavior

I wouldn't expect the panel to allow installation while missing required components.

### ❌ Actual Behavior

_No response_

### Other Software

_No response_