sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react
Issue: Bug: StrictMode is not preventing side effects
Labels: Type: Discussion

React version: any with StrictMode

## Steps To Reproduce

1. Create a few components with improper or absent memoization
2. Create `useEffect` with unstable dependency
3. Observe how `StrictMode` is not able to help here

- Incorrect code
```tsx
const {propA, propB, ...rest} = propsC;

useEffect(() => {
  // some effect not expected executed on every render
}, [rest]);
// ^^ rest is "unstable"
```
```tsx
<Component
  onSomething={() => {}}
  // we dont know what  Component will do with unstable callback. May be something, may be not
/>
```

- Correct code
 ```tsx
const {propA, propB, rest} = useMemo(() => {
   const {propA, propB, ...rest} = propsC;
   return {propA, propB, rest};
}, [propC]);

useEffect(() => {
  // some effect not expected executed on every render
}, [rest]);
// ^^ rest is "stable"
```
```tsx
<Component
  onSomething={useCallback(() => {},[])}
/>
```

## The current behavior

>If a function is pure, running it twice does not change its behavior because a pure function produces the same result every time. However, if a function is impure (for example, it mutates the data it receives), running it twice tends to be noticeable (that’s what makes it impure!) This helps you spot and fix the bug early.

https://react.dev/reference/react/StrictMode

I personally never found this behaviour any helpful. It never helped me find a bug, especially a bug related to useEffect.

## The expected behavior

I would assume that `StrictMode` should not try to execute `useEffect` twice - it should render Component twice and ensure no `useEffect` or `useMemo` is invalidated.
Ideally, it should cause full application re-render to detect memoization issues spanning across multiple components, like using `children` in effect dependencies or passing unstable prop to a component with `useEffect` as such case cannot be detected by isolated re-render.

----

React Forget is going to change the game rules and automatically fix the problems from above, but how one can prove it without having a corresponding testing functionality one can trust?
Unfortunately, this is something very hard to implement in the user space, simultaneously something causing incidents (performance as well as reliability) on a weekly basic
Repository: neovim
Issue: Upstream :Lsp commands from nvim-lspconfig
Labels: enhancement,lsp

This is a tracking issue to either upstream the `:LspStart`, `:LspStop`, `:LspRestart`, and `:LspInfo` commands from nvim-lspconfig or determine formally if those features are not wanted.

`:checkhealth lsp` does a lot of what `:LspInfo` does, but is not a complete replacement. In https://github.com/neovim/neovim/pull/18476#issuecomment-1120390374, @mfussenegger mentioned:

>:lsp / :LspInfo: LspInfo currently does more than just printing all clients, it also prints all not started yet. It can do that because lsp-config currently includes the "managing clients" functionality. I think the first step we have to do to bring anything like that into core is to move the manager component.

Nvim core would need the concept of "registering" or "managing" a client without it being started. For example, a `vim.lsp.register` API that makes Nvim aware of a client configuration without actually starting it. This same functionality would be needed for `:LspStart` as well, if we want to include that.

I do not think we should include `:LspInfo` directly, but its functionality should be integrated into `:checkhealth lsp`.

If we do add `:LspStart` and/or `:LspStop`, I propose they be added as `:lsp start` and `:lsp stop` and promote `:lsp` to a first class command (note, this is a different interface thn the one proposed in #18476).

cc @mfussenegger
Repository: flutter
Issue: [Impeller] Switch to lazy mipmap generation by default.
Labels: P2,e: impeller,team-engine,triaged-engine

Would also solve: 
  * https://github.com/flutter/flutter/issues/127697
 
 Context: https://github.com/flutter/flutter/issues/123469
 
 Today Impeller generates mipmaps by default when encoding images, see https://github.com/flutter/engine/blob/main/lib/ui/painting/image_decoder_impeller.cc#L339
 
 However we've discovered that almost all flutter images will by default not use any miplevels. This means once we fix https://github.com/flutter/flutter/issues/147259 , most of this work is wasted. Instead of eagerly generating mipmaps, we should switch to a system where they are generated on demand _if_ an image is rendered with a filter quality that requires it.
Repository: neovim
Issue: `:finish` can no longer be used in `exrc` files since v0.9.0
Labels: bug,vimscript,has:vim-patch,startup

### Problem

Since v0.9.0, I started getting

```
Error detected while processing .exrc:
E168: :finish used outside of a sourced file
```

...due to `finish`es in my `.exrc`.

I suspect this is related to the `vim.secure.read()` + exrc changes.

### Steps to reproduce

1. Enable `exrc`
2. Create a `.exrc` file like (This is how/why I use `finish` in `exrc`s. To reproduce the issue itself, a simple `finish` anywhere should do.)
    ```vim
    if index(['git', 'gh'], trim(split(system('ps -o comm= ' .. luaeval('vim.loop.os_getppid()')), '/')[-1])) >= 0
          \ || stridx(trim(split(system('ps -o command= ' .. luaeval('vim.loop.os_getpid()')), '/')[-1]), '+Man!') >= 0
      finish
    endif
    
    " lots of settings
    ```
3. Start Neovim (In my case, use Neovim as Git editor and `git commit`, or use Neovim as Manual pager then `man ...`)

### Expected behavior

`:finish` still works in `exrc`s.

### Neovim version (nvim -v)

v0.9.5

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

No, 9.1 (2024 Jan 02, compiled Apr 18 2024 20:05:12)

### Operating system/version

macOS 14.4.1

### Terminal name/version

Kitty 0.34.1

### $TERM environment variable

tmux-256color

### Installation

Homebrew
Repository: next.js
Issue: The behaviour of encoded special characters in path params is not consistent between page.tsx and route.ts
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/naughty-sinoussi-2cz5ks

### To Reproduce

1. Create a dynamic `page.tsx` route using a path parameter like `/[pathParam]/` and `{params}: {params: { pathParam: string }}`
2. Create a dynamic `route.ts` route using the same path parameter like `/[pathParam]/` and `{params}: {params: { pathParam: string }}`
3. Visit the page.tsx based route with special characters in the URL
4. Visit the route.ts based route with special characters in the URL

### Current vs. Expected behavior

I would expect Next.js' `params` object to behave the same whether it's used from `page.tsx`, `route.ts`, or `useParams()`.

Instead pathParam is undecoded when used from `page.tsx` and `useParams()` but is decoded when used from `route.ts`.

## `/dynamic-page/%3F%2C%3D%2C%2F%2C%26%2Cшеллы`
```
{
  "params": {
    "pathParam": "%3F%2C%3D%2C%2F%2C%26%2C%D1%88%D0%B5%D0%BB%D0%BB%D1%8B"
  }
}
```

## `/dynamic-route/%3F%2C%3D%2C%2F%2C%26%2C%D1%88%D0%B5%D0%BB%D0%BB%D1%8B?`
```
{
  "method": "GET",
  "params": {
    "pathParam": "?,=,/,&,шеллы"
  }
}
````

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 14.2.0-canary.11 // There is a newer canary version (14.3.0-canary.21) available, please upgrade! 
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


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

Not sure

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

next dev (local)

### Additional context

_No response_
Repository: ollama
Issue: Is it possible to start with fastchat and then wrap the interface with fastapi to become like ollama?
Labels: feature request

Since Ollama supports more than 30 models, but doesn't have the one I need, and in addition, having already deployed another application using fastchat, can I encapsulate the interface and disguise it as Ollama for reuse purposes?
What interfaces do I need to encapsulate and where is the interface documentation?
Repository: ollama
Issue: Please use comfyUI-like to realize Automatic Programming?
Labels: feature request

auto coding.

[https://raw.githubusercontent.com/comfyanonymous/ComfyUI/master/comfyui_screenshot.png](url)

like Andrew Ng say,  The Agentic Workflow much stronger than the original GPT3.5, 
I know that ollama can be called using API. The problem now is how to implement the agent workflow on the UI and complete the human-computer interaction of automatic coding, so I thought of the connection method ComfyUI,
Perhaps you also need a window to communicate with the large model, a window to return codes and a terminal window.

This is an initial, relatively vague idea about how to design automatic coding.

Does Agentic Workflow still need an intermediate layer like ollama for communication between UI and large model?
Repository: tauri
Issue: [bug] [macos] [v1] Window cannot join other spaces and cannot be drawn over fullscreen apps in "tauri build" mode
Labels: type: bug,status: needs triage

### Describe the bug

- In `tauri dev` mode:
    - Window can be drawn on another workspace, i.e. window.show() rerenders the window on the currently active space. **This is the expected behavior.**
- In `tauri build` mode:
    - Window is always drawn on the original workspace and cannot be moved to another space. **That's the problem.**

Window option `alwaysOnTop` is set to `true`.

### Reproduction

Reproducer repo:
https://github.com/romazu/tauri-macos-draw-window-over-fullscreen/tree/tauri_v1

### Expected behavior

An `alwaysOnTop` window can be drawn over other fullscreen apps in other workspaces on macOS in both the `tauri dev` and `tauri build` modes.

### Full `tauri info` output

```text
yarn run v1.22.21
$ tauri info

[✔] Environment
    - OS: Mac OS 14.4.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.77.2 (25ef9e3d8 2024-04-09)
    ✔ cargo: 1.77.2 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 21.7.1
    - pnpm: 8.15.1
    - yarn: 1.22.21
    - npm: 10.5.0

[-] Packages
    - tauri [RUST]: 1.6.2
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.8
    - tao [RUST]: 0.16.9
    - @tauri-apps/api [NPM]: 1.5.4
    - @tauri-apps/cli [NPM]: 1.5.11

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../src
    - devPath: ../src
✨  Done in 7.16s.
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: tauri
Issue: [bug] [macos] [v2] Window cannot join other spaces and cannot be drawn over fullscreen apps in both "tauri dev" and "tauri build" modes
Labels: type: bug,status: needs triage

### Describe the bug

- Both `tauri dev` and `tauri build` modes:
    - The window is always drawn on the original workspace and cannot be moved to another one.

Window options `alwaysOnTop` and `visibleOnAllWorkspaces` are set to true.
Capability `window:allow-set-visible-on-all-workspaces` is set.

Also see possibly related [bug](https://github.com/tauri-apps/tauri/issues/9556) in tauri v1. There the problem arises only in `tauri build` mode.

### Reproduction

Reproducer repo:
https://github.com/romazu/tauri-macos-draw-window-over-fullscreen/tree/tauri_v2

### Expected behavior

An `alwaysOnTop`, `visibleOnAllWorkspaces` window can be drawn over other fullscreen apps in other workspaces on macOS in both the `tauri dev` and `tauri build` modes.


### Full `tauri info` output

```text
yarn run v1.22.21
$ tauri info

[✔] Environment
    - OS: Mac OS 14.4.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.77.2 (25ef9e3d8 2024-04-09)
    ✔ cargo: 1.77.2 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 21.7.1
    - pnpm: 8.15.1
    - yarn: 1.22.21
    - npm: 10.5.0

[-] Packages
    - tauri [RUST]: 2.0.0-beta.16
    - tauri-build [RUST]: 2.0.0-beta.13
    - wry [RUST]: 0.39.2
    - tao [RUST]: 0.27.1
    - @tauri-apps/api [NPM]: 2.0.0-beta.9
    - @tauri-apps/cli [NPM]: 2.0.0-beta.13

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../src
✨  Done in 4.67s.
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: transformers
Issue: (Willing to PR) Make `tokenizer.padding_side` an argument instead of only being a field
Labels: Core: Tokenization,Feature request

### Feature request

Hi thanks for the library! When using tokenizer, for example, for batch-generation with GPT2 (in https://discuss.huggingface.co/t/batch-generation-with-gpt2/1517), it seems that currently I have to do something like:

```
tokenizer.padding_side = 'left'
data = tokenizer(['sentence one', 'another'])
tokenizer.padding_side = 'right'
```

Therefore, it would be great to have:

```
data = tokenizer(['sentence one', 'another'], padding_side = 'left')
```

just like what we do today for many options like `padding_strategy` etc.

### Motivation

(see above)

### Your contribution

Yes, I am willing to PR
Repository: vscode
Issue: Process Explorer and `code --status` show all remote server Memory as 0
Labels: bug,remote,confirmed

<!-- ⚠️⚠️ 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

<!-- 🪓 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.88.1 (system setup)
    Commit: e170252f762678dec6ca2cc69aba1570769a5d39
    Date: 2024-04-10T17:41:02.734Z
    Electron: 28.2.8
    ElectronBuildId: 27744544
    Chromium: 120.0.6099.291
    Node.js: 18.18.2
    V8: 12.0.267.19-electron.0
    OS: Windows_NT x64 10.0.19043

WSL:

    Distributor ID: Ubuntu
    Description:    Ubuntu 22.04.4 LTS
    Release:        22.04
    Codename:       jammy

Steps to Reproduce:

1. open a Workspace in wsl
2. Press ctrl+p, open Process Explorer
3. Check CPU and memory usage of process under wsl section

![image](https://github.com/microsoft/vscode/assets/8296331/8d38d84c-d3db-44b0-bfbd-bcd5289c6128)
Repository: electron
Issue: [Enhancement]: Missing support for Persistent Permissions with the File System Access API as of Chrome 122
Labels: enhancement :sparkles:,bug :beetle:,platform/all,30-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

30.0.0

### What operating system are you using?

Windows

### Operating System Version

Windows 11 (fully updated)

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

Chrome 122+ now has [persistent permissions](https://developer.chrome.com/blog/persistent-permissions-for-the-file-system-access-api) for the File System Access API. In versions of Electron containing Chrome 122+, I expect to be able to set persistent permissions, either via Chrome's UI or via a Web session broker in `main`. Alternatively, I expect persistent permissions will always be granted.

### Actual Behavior

Although there is a new broker for handling File System Access permissions (see #28422 and its resolution in PR #41419 by @codebytere), using this function does not grant persistent permissions. This results in an Electron app using this API being unable to access a file or directory from a file handle stored in a previous session _**unless the user supplies a gesture**_ (e.g. mouse click). The following error shows in console: `DOMException: Failed to execute 'requestPermission' on 'FileSystemHandle': User activation is required to request permissions.`.


The current behaviour of 30.x means that developers would be forced to use Node FS APIs, and hence complicate their codebase when packaging a PWA as an Electron app.

### Testcase Gist URL

https://gist.github.com/bradisbell/86ae72ea9709c471a0c4f49fea9dd0e0

### Additional Information

It should be noted that in Electron versions up to 29.x, it is possible to bypass the user gesture requirements, and essentially emulate persistent permissions, with the commandline switch `enable-experimental-web-platform-features`. That switch simply granted all requested permissions.

Please see https://github.com/electron/electron/issues/28422#issuecomment-2072737532 and response below it for further details about this part of the File System Access API not yet being implemented in Electron.
Repository: ui
Issue: [bug]: Very slow selection with a large amount of elements
Labels: bug

### Describe the bug

I use select to output a large number of items, there can be around 1 thousand and even sometimes more than that
When I press select to get a dropdown list, on my device it takes about 3-4 seconds before the list of options appears on the screen. With native select everything works instantly

### Affected component/components

Select

### How to reproduce

   Here is the code for my component
```
 <FormField
      control={control}
      name="postOffice"
      render={({ field }) => (
        <FormItem>
          <FormLabel>Post office</FormLabel>
          <Select onValueChange={field.onChange} defaultValue={field.value}>
            <FormControl>
              <SelectTrigger>
                <SelectValue placeholder="Select a verified email to display" />
              </SelectTrigger>
            </FormControl>
            <SelectContent>
              {postOfficeListToSelect &&
                postOfficeListToSelect.map((postOffice) => (
                  <SelectItem value={postOffice.value} key={postOffice.value}>
                    {postOffice.label}
                  </SelectItem>
                ))}
            </SelectContent>
          </Select>
        </FormItem>
      )}
    />
```
Here is what the **postOfficeListToSelect** array looks like

```
const postOfficeflistToSelect = [
  {
    value: "7b422fba-e1b8-11e3-8c4a-0050568002cf",
    type: "Branch",
    label: "Post office number 1",
  },
  {
    value: "5db422f-e1b8-11e3-8c4a-0050568002cf",
    type: "Branch",
    label: "Post office number 2",
  },
  ...,
  ...,
  ...,
  {
    value: "158db422f-e1b8-11e3-8c4a-0050568002cf",
    type: "Branch",
    label: "Post office number 1000",
  },
];

```


### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
MacBook Pro M1
Chrome, Ark
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: rust
Issue: We are relying on undocumented behavior of GetUserProfileDirectoryW
Labels: O-windows,C-bug,T-libs

This is about this code:

https://github.com/rust-lang/rust/blob/b58f647d5488dce73bba517907c44af2c2a618c4/library/std/src/sys/pal/windows/os.rs#L327-L340

According to the [docs](https://learn.microsoft.com/en-us/windows/win32/api/userenv/nf-userenv-getuserprofiledirectoryw), the size pointer is updated as follows:

"If the buffer specified by lpProfileDir is not large enough or lpProfileDir is NULL, the function fails and this parameter receives the necessary buffer size, including the terminating null character."

The docs say nothing about what happens to the size pointer if the buffer *is* large enough (and not NULL). std however assumes that in that case, the size pointer is updated to the actual length of the data (including the null terminator). Reality seems to agree as otherwise we'd long have seen issues (and FWIW, [wine agrees](https://github.com/wine-mirror/wine/blob/d07019e4d174fd1b5d8b74ff2a36e900c07d96d7/dlls/userenv/userenv_main.c#L451) as well). Still, we're technically relying on undocumented behavior here.

Probably the best way forward is for the Windows docs to be updated.
Repository: pytorch
Issue: CI is downloading model definitions and model weights from external sources
Labels: module: ci,triaged

### 🐛 Describe the bug

I noticed [some CI](https://github.com/pytorch/pytorch/actions/runs/8811061038/job/24184675398) jobs failing with: 

```
[linux-focal-py3.8-clang10-onnx / test (default, 2, 2, linux.2xlarge)](https://github.com/pytorch/pytorch/actions/runs/8811061038/job/24184675398#logs)
```

```
OSError: We couldn't connect to 'https://huggingface.co/' to load this file, couldn't find it in the cached files and it looks like t5-small is not the path to a directory containing a file named config.json.
```

I believe we should not be downloading things from external sources in our CI, we should cache and maintain all this data in our dedicated buckets. This is due to:

* Speed;
* Data transfer costs;
* Stability (that the data won't change in the remote)
* Confiability (that the service will be up)

so I believe we should fix that;

### Versions

main

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: deno
Issue: Add support for subresource integrity in imported module scripts
Labels: feat,cli

SRI support for ES module imports would enable using them in documents that require SRI for certain scripts for security or privacy reasons.

See [problem statement and proposal](https://github.com/guybedford/import-maps-extensions#integrity) by [Guy Bedford](https://guybedford.com/).

[HTML PR](https://github.com/whatwg/html/pull/10269)
[Chromium CL + tests](https://chromium-review.googlesource.com/c/chromium/src/+/5441822)