sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Fix `torch.stft` and `torch.istft` when using `center=False`, non-rectangular windows and `win_length==hop_length`
Labels: high priority,triaged,module: python frontend

### 🚀 The feature, motivation and pitch

Over the past years, multiple issues were opened about using the non-default parameters in `torch.stft` and `torch.istft`. Those issues have not been solved and are still crippling. This is significant as the parameters that can raise errors are commonly used and well motivated in audio signal processing.

This is a non-exhaustive compilation of issues:
- pytorch/audio/issues/427
- pytorch/audio/issues/500
- #62323
- #81428
- #91309
- #118507
- #70073

The importance of those issues is also reflected by the number of re-implementations of iSTFT in audio signal processing repositories (e.g. [this one](https://github.com/charactr-platform/vocos/blob/03c4fcbb321e4b04dd9b5091486eedabf1dc9de0/vocos/spectral_ops.py#L7-L75) by @hubertsiuzdak)

Those issues most commonly happen when setting `center=False` as the NOLA check fails at the edges, or when using windows with zeroes like Hann or the ones proposed by Mauler and Martin in [2007](https://ieeexplore.ieee.org/document/7098797) and [2009](https://doi.org/10.1155/2009/469480) as illustrated by @LXP-Never [here](https://github.com/pytorch/pytorch/issues/62323#issuecomment-1829564313).

The solutions are:
- Adding an option to disable the NOLA check
- Adding support for custom padding
- Fixing the normalization by taking the selected window into account when `normalized=True`.

In my opinion, the current padding is fundamentally wrong and should be reimplemented. As pointed out by @fakufaku [here](https://github.com/pytorch/pytorch/issues/91309#issuecomment-1371755324), the option `center=True` currently does two unrelated things, 1. fitting an integer number of frames and 2. ensuring the signal is invertible by dealing with the first and last samples when using a non-rectangular window, in which case the padding should actually be `win_length - hop_length`, and not `win_length // 2`. As I demonstrated [here](https://github.com/pytorch/pytorch/issues/70073#issuecomment-1495893892), the current padding can cause data loss even when `center=True`!

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @albanD
Repository: storybook
Issue: [Bug]: Local registry process is not killed when sandbox creation fails
Labels: bug,needs triage

### Describe the bug

If the creation of a sandbox (invoked with `yarn task --task dev --template <> --start-from=install`) fails with some error (say during the `script` execution), then the local registry process is still running in the background and a new run will fail since the port is already taken:
![image](https://github.com/user-attachments/assets/77c592d0-acf6-4151-b900-269ec9cf560c)

```
shortMessage: 'Command failed with exit code 1: yarn local-registry --publish',
  command: 'yarn local-registry --publish',
  escapedCommand: '"yarn local-registry --publish"',
  exitCode: 1,
  signal: undefined,
  signalDescription: undefined,
  stdout: '📐 reading version of storybook\n' +
    '🚛 listing storybook packages\n' +
    '🗑 cleaning up cache\n' +
    '🎬 starting verdaccio (this takes ±5 seconds, so be patient)\n' +
    '\x1B[36minfo \x1B[39m\x1B[37m\x1B[34m---\x1B[37m plugin successfully loaded: \x1B[32mverdaccio\x1B[37m-\x1B[32mauth-memory\x1B[37m\x1B[39m',
  stderr: '(node:39764) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.\n' +
    '(Use `node --trace-deprecation ...` to show where the warning was created)\n' +
    'node:events:498\r\n' +
    "      throw er; // Unhandled 'error' event\r\n" +
    '      ^\r\n' +
    '\r\n' +
    'Error: listen EADDRINUSE: address already in use :::6001\r\n' +
    '    at Server.setupListenHandle [as _listen2] (node:net:1902:16)\r\n' +
    '    at listenInCluster (node:net:1959:12)\r\n' +
    '    at Server.listen (node:net:2061:7)\r\n' +
    '    at D:\\Programming\\storybook\\scripts\\run-registry.ts:65:11\r\n' +
    '    at new Promise (<anonymous>)\r\n' +
    '    at startVerdaccio (D:\\Programming\\storybook\\scripts\\run-registry.ts:36:3)\r\n' +
    '    at run (D:\\Programming\\storybook\\scripts\\run-registry.ts:173:3)\r\n' +
    "Emitted 'error' event on Server instance at:\r\n" +
    '    at emitErrorNT (node:net:1938:8)\r\n' +
    '    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {\r\n' +
    "  code: 'EADDRINUSE',\r\n" +
    '  errno: -4091,\r\n' +
    "  syscall: 'listen',\r\n" +
    "  address: '::',\r\n" +
    '  port: 6001\r\n' +
    '}\r\n' +
    '\r\n' +
    'Node.js v22.6.0',
  failed: true,
  timedOut: false,
  isCanceled: false,
  killed: false
}
```

### Reproduction link

main repo

### Reproduction steps

_No response_

### System

```bash
latest `next` branch
```


### Additional context

_No response_
Repository: react
Issue: [React 19] Upgrading React causes infinite refetching
Labels: React 19

## Summary

The reproduction is using Relay, but I came as this seems closer to a bug in React than Relay.

https://stackblitz.com/@cometkim/collections/react-relay-suspend-loop

With this basic setup, using `useLazyLoadQuery` with `network-only` to make a new `fetch()` call on render. The code works fine in v18, but after upgrading to v19, it starts remounting an element infinitely.

- [React v18](https://stackblitz.com/edit/vitejs-vite-ingwz7?file=src%2Fmain.tsx): No issues
- [React v19](https://stackblitz.com/edit/vitejs-vite-ezhrrp?file=src%2Fmain.tsx): No differences, but the children including the suspense boundary is unexpectedly unmounted, resulting in an infinite refetch loop.
- [React v19 workaround 1](https://stackblitz.com/edit/vitejs-vite-jqbsjc?file=src%2Fmain.tsx): Removing `<StrictMode>` seems to solve the issue.
- [React v19 workaround 2](https://stackblitz.com/edit/vitejs-vite-56sxrz?file=src%2Fmain.tsx): Wrap the parent (which is just a context provider with nothing special) by one more `<Suspense>` boundary. It seems to do not make sense, but it works. 

The expected behavior is that the `<Suspense>` boundary is retained stable, and the `<NetworkOnly>` is rendered after waiting for the QueryResource fulfilled.

However, this seems to me like the `<Suspense>` could suspend itself.
Repository: langchain
Issue: ReAct agent creating own "User Input" and ending up stopping agent with iteration limit
Labels: Ɑ: agent,🤖:bug

### Checked other resources

- [X] I added a very descriptive title to this issue.
- [X] I searched the LangChain documentation with the integrated search.
- [X] I used the GitHub search to find a similar question and didn't find it.
- [X] I am sure that this is a bug in LangChain rather than my code.
- [X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

### Example Code

# Agent and Executor setup
```python 
agent = create_react_agent(llm, tools, full_prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True, handle_parsing_errors=True)
langchain.debug = True```

### Error Message and Stack Trace (if applicable)

Agent stopped due to iteration limit exceeded.

### Description

I was using langchain.agents AgentExecutor, create_react_agent. I got the output for the user input in my chain but it is creating its own user input and keep answering it with the given available tools.
<img width="1512" alt="Screenshot 2024-08-23 at 4 08 40 PM" src="https://github.com/user-attachments/assets/1b9b8537-8ab2-49de-806f-0f85f438b688">


### System Info

langchain==0.2.11
langchain-community==0.2.7
langchain-core==0.2.24
langchain-experimental==0.0.62
langchain-huggingface==0.0.3
langchain-openai==0.1.16
langchain-text-splitters==0.2.1

platform mac

dnspython==2.6.1
opencv-python==4.10.0.82
python-dateutil==2.9.0.post0
python-dotenv==1.0.1
python-multipart==0.0.9
Repository: vscode
Issue: Allow more than 9 items in the title bar
Labels: feature-request,workbench-tabs,layout

<!-- ⚠️⚠️ 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. -->

Currently, there are only 9 items allowed in the title bar. Is there any specific reason for that? 
On the first screenshot, there are only 6 but as soon as I click `Open Changes with Revision...`, and multiple diff-related buttons show up, it’s impossible to have more than 9 in total, despite a lot of free space being available.

![CleanShot 2024-08-23 at 13 27 46@2x](https://github.com/user-attachments/assets/599bac3e-c9c3-44ef-8587-b9b176939428)

![CleanShot 2024-08-23 at 13 34 52@2x](https://github.com/user-attachments/assets/83aec359-a805-4cfc-b835-2c58e978e77b)
Repository: pytorch
Issue: Proposal: When serializing to state_dict/parameters use different separators for ParameterList and ParameterDict
Labels: module: nn,module: serialization,triaged,needs research

### 🚀 The feature, motivation and pitch

JAX has the idea of pytrees--combinations of lists, dictionaries, and custom objects which can have subtrees. When working in JAX, a model is represented by a pytree and its parameters are the leaves of the pytree.

I've been writing a pytree to safetensors converter, and I found it convenient to use different separators depending on whether the pytree is a list, dictionary, or object. In particular, I'm using "#" when the subtree is the index of a list, "@" when the subtree is the value of a dictionary, and "." when the subtree is an object.

I like this approach, and I wish PyTorch also used "#" as the separator before the index of ParameterList and "@" as the separator before the value of a ParameterDict, both for interoperability and for readability.

### Alternatives

_No response_

### Additional context

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: material-ui
Issue: [joy-ui] `--joy-spacing` CSS var no longer injected
Labels: on hold,package: joy-ui,customization: theme

### Steps to reproduce

Link to live example (Any of the Joy UI Codesandbox):
https://codesandbox.io/s/pt8svk?file=/src/Demo.tsx

Steps:
1. Update to latest version of `@mui/joy`
2. `--joy-spacing` CSS var is no longer injected into styles


### Current behavior

`--joy-spacing` CSS var is not injected into styles

### Expected behavior

`--joy-spacing` CSS var is injected into styles

### Context

I used `var(--joy-spacing)` in quite a few of my custom styles rather than `theme -> theme.spacing(x)` to minimize JS and it worked nicely.

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: macOS 14.6.1
  Binaries:
    Node: 21.6.0 - /usr/local/bin/node
    npm: 10.2.4 - /usr/local/bin/npm
    pnpm: 9.6.0 - /usr/local/bin/pnpm
  Browsers:
    Chrome: 128.0.6613.84
    Edge: 128.0.2739.42
    Safari: 17.6
```
</details>
I used Chrome.


**Search keywords**: joy, spacing, theme
Repository: godot
Issue: Window resized on secondary monitor resets to default window size if moved to main display
Labels: bug,platform:macos,topic:gui

### Tested versions

Reproducible on 4.3.stable, and as far back as I can remember (at least 4.2) so it's not a recent regression I think.

### System information

macOS 14.6.1

### Issue description

If you move a window to a secondary display by setting the window.position to a position on that display and then changing the window.size this works as expected. However, if you then move this window back to the main display the window resized back to the project default window size (set small in the example to see the effect).

https://github.com/user-attachments/assets/dc80d385-5ac8-48e9-b05f-9dcc57a28e0d

If you do the resize on the main monitor you can move the window back and forth to the secondary monitor with no issue. 
Same if you manually resize the window on the secondary display before moving it to the main display.


### Steps to reproduce

All that is required is to position and resize a window like so:
```
func _ready() -> void:
	get_window().position = Vector2(200,200) #position on secondary display
	get_window().size = Vector2(1000,1000) #Something different from project default window size
	
```
And the drag the window back to the main monitor.

However, if you set the size first and then move the window, the issue does not occur. So it's as if setting the window size when it's on a secondary monitor it puts it in some invalid size state that is revealed when ending a move of the window to a different display?

### Minimal reproduction project (MRP)

As you can see in the video above only a couple of lines of code are required, apart from having two monitors to test with. I've seen this on macOS only, since it's the only multi-monitor system I have available to test on, so I'm not sure if it's macOS specific or not.

In my case both monitors are hiDPI monitors, but with the same display scale, so it shouldn't be an issue related to trying to switch between monitors with different dpi (which is often a cause for issues like this).
Repository: next.js
Issue: `useSearchParams` and `usePathname` do not retain original values when an intercepting route is open
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/ali-idrizi/next-intercepting-routes-hooks-reproduction

### To Reproduce

1. `next dev`
2. Click the link in the homepage
3. Notice all values are correct:
    ```
    Props params: {"slug":"some-exmaple-blog-page"}
    useParams: {"slug":"some-exmaple-blog-page"}
    usePathname: /blog/some-exmaple-blog-page
    useSearchParams: {"query":"test"}
    ````
4. Click the link in the page which renders a  `<dialog>` through intercepting routes
5. Under the dialog, notice correct values for props params and `useParams`, but not for `usePathname` and `useSearchParams`:
    ```
    Props params: {"slug":"some-exmaple-blog-page"}
    useParams: {"slug":"some-exmaple-blog-page"}
    usePathname: /about
    useSearchParams: {}
    ```


https://github.com/user-attachments/assets/6d5b74a5-3a3c-4fc1-9cc3-85edbeb58f8b

### Current vs. Expected behavior

Opening an intercepting route should not affect the router of the original page. Currently, only the `params` prop and the `useParams` hook correctly retain the values.

The values of `usePathname` and `useSearchParams` however are lost. If the page is running conditional logic (similar to the example), then opening an intercepting route changes the content under the dialog.

The issue is also present in the latest canary with React 19.

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Thu Oct 5 21:02:42 UTC 2023
  Available memory (MB): 38098
  Available CPU cores: 24
Binaries:
  Node: 20.10.0
  npm: 10.2.3
  Yarn: N/A
  pnpm: 8.15.1
Relevant Packages:
  next: 14.2.6 // Latest available version is detected (14.2.6).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: N/A
```


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

Navigation

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

next dev (local), next start (local)

### Additional context

_No response_
Repository: PowerToys
Issue: 关于rename功能无法使用的问题
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.83.0

### Installation method

Microsoft Store

### Running as admin

None

### Area(s) with issue?

PowerRename

### Steps to reproduce

选中文件浏览器里的文件右击出现的菜单中没有powerrename选项
![11](https://github.com/user-attachments/assets/d5d3f44b-14a3-4242-b185-cbcc46db3c38)



### ✔️ Expected Behavior

希望能正常使用rename功能

### ❌ Actual Behavior

无法使用

### Other Software

_No response_
Repository: transformers
Issue: llama3 position_ids error with left padding
Labels: Feature request

### Feature request

The LLaMA 3 implementation should generate default `position_ids` that take the `attention_mask` into account.

@ArthurZucker @younesbelkada 

### Motivation

Is there a specific reason why the default `position_ids` generation doesn’t consider the `attention_mask`? A friend mentioned that this issue has persisted for almost half a year now.

https://github.com/huggingface/transformers/blob/adb91179b9e867b7278e0130c87558974056c7b4/src/transformers/models/llama/modeling_llama.py#L962

The problem arises when using left padding, as the default position_ids start from the first index in the sequence length  rather than from the first non-zero index in the `attention_mask`.

As far as I know, this is handled correctly in the `generate` function, but I would expect consistency during training as well.
https://discuss.huggingface.co/t/llama-position-ids/75870

### Your contribution

I can submit a PR changing 

https://github.com/huggingface/transformers/blob/adb91179b9e867b7278e0130c87558974056c7b4/src/transformers/models/llama/modeling_llama.py#L963

to

```
position_ids = (attn_mask.cumsum(-1) - 1).clamp(min=0)
position_ids.masked_fill_(attn_mask.to(torch.bool) == 0, 0)
```

if noone has any objections on correctness of that. Otherwise, let's discuss.
Repository: deno
Issue: deno fmt (v1.46+): Ignore front matter in HTML files
Labels: feat,deno fmt

Thank you very much for adding formatters for HTML, YAML, CSS etc. Fantastic!

If you work with static site generators (my own is based on deno) you can use front matter data (e.g. in YAML, TOML, JSON or JS format) in HTML files. The [11ty documentation](https://www.11ty.dev/docs/data-frontmatter/) provides examples.

Also, template files are often HTML files with a bit of template code ([vento](https://vento.js.org/), nunjucks or liquid for example). These template files can also contain front matter.

It would be excellent, if deno could just ignore front matter -- generally or by using a flag or language setting.

#19458 is kind of related.

Thanks a lot!
Repository: PowerToys
Issue: sticky or delayed keys
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.83.0

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

General

### Steps to reproduce

lately the ctrl or alt keys have a lag. I notice it when I use it for shortcuts. For instance, I hit ctrl V and many times it types V, because it didn´t get the ctrl. But if I slowly repeat the shortcut, it works. 

### ✔️ Expected Behavior

that it works properly. 

### ❌ Actual Behavior

it doesn´t. 

### Other Software

_No response_
Repository: storybook
Issue: [Bug]: isTemplate prop on Meta component from @storybook/blocks is missing in TS types
Labels: bug,needs triage

### Describe the bug

<img width="814" alt="Screenshot 2024-08-23 at 16 10 44" src="https://github.com/user-attachments/assets/b7272332-70e6-4000-ad10-9911d2e90125">

```
type MetaProps = BaseAnnotations & {
    of?: ModuleExports;
    title?: string;
};
```

The prop works and should be defined based on https://storybook.js.org/docs/api/doc-blocks/doc-block-meta#istemplate

### Reproduction link

https://github.com/storybookjs/storybook/blob/next/code/lib/blocks/src/blocks/Meta.tsx#L9

### Reproduction steps

_No response_

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.6.1
    CPU: (8) arm64 Apple M1
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.7.0 - ~/.local/state/fnm_multishells/34287_1724422541447/bin/node
    npm: 10.8.2 - ~/.local/state/fnm_multishells/34287_1724422541447/bin/npm <----- active
  Browsers:
    Chrome: 128.0.6613.85
    Safari: 17.6
  npmPackages:
    @storybook/addon-docs: ^8.2.9 => 8.2.9 
    @storybook/addon-essentials: ^8.2.9 => 8.2.9 
    @storybook/addon-webpack5-compiler-babel: ^3.0.3 => 3.0.3 
    @storybook/blocks: ^8.2.9 => 8.2.9 
    @storybook/preview-api: ^8.2.9 => 8.2.9 
    @storybook/react: ^8.2.9 => 8.2.9 
    @storybook/react-webpack5: ^8.2.9 => 8.2.9 
    @storybook/test: ^8.2.9 => 8.2.9 
    storybook: ^8.2.9 => 8.2.9
```


### Additional context

_No response_
Repository: react-native
Issue: Application Scene Delegates support in RN >= 0.74
Labels: Resolution: Answered

### Description

When we added CarPlay support to our React Native app we needed to switch from [App Delegate to Application Scene Delegates](https://medium.com/@Ariobarxan/ios-application-scene-delegate-vs-app-delegate-a-talk-about-life-cycle-a2ecae9d507e).

Independently of whether the app was started on the phone (PhoneScene) or on the CarPlay-client (CarScene), the first code to run natively will always be the AppDelegates `application:didFinishLaunchingWithOptions:` method.
A React Native app usually calls the super-method in its AppDelegate, which is implemented in React Native's own `RCTAppDelegate`. The problem with this is that `RCTAppDelegate` assumes a phone usage and creates a `rootViewController` along with a window for the app to be displayed in. This leads to problems when launching the app on the CarPlay-client first, since CarPlay does not require a rootViewController or a window to display its views.

The key to solving this problem is to split the app initialization logic into PhoneScene and CarScene (which are both subclasses of `UIResponder`) and only run the code required to set up the React Native bridge in the AppDelegate. We can achieve this by not calling the super-method in `application:didFinishLaunchingWithOptions:` but instead create and call a
custom init method.

Prior to React Native 0.74 this wasn't a problem, since all methods needed for setup were publicly exposed.
Starting with React Native 0.74, the root view is created via `RCTRootViewFactory` with no way of instantiating one from the custom initialization routine in App Delegate.

How do you plan to support Application Scene Delegates in the future?
Are there any options to create a `RCTRootViewFactory` without patching the header file as described [here](https://github.com/birkir/react-native-carplay/pull/158#issuecomment-2302350901)?
Would it be problematic to expose [createRCTRootViewFactory](https://github.com/facebook/react-native/blob/516428771d4e98e1f5d6fcebc1c9a0fcdbd0b3ad/packages/react-native/Libraries/AppDelegate/RCTAppDelegate.mm#L233) in the header, making it accessible from the App Delegate?

### Steps to reproduce

Try setting up a RN 0.74 or 0.75 app via [application scene delegates](https://medium.com/@Ariobarxan/ios-application-scene-delegate-vs-app-delegate-a-talk-about-life-cycle-a2ecae9d507e)

### React Native Version

0.74

### Affected Platforms

Runtime - iOS

### Output of `npx react-native info`

```text
irrelevant
```


### Stacktrace or Logs

```text
none
```


### Reproducer

none

### Screenshots and Videos

_No response_