sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: deno
Issue: Mongodb Deno SRV connection not working.
Labels: bug,node compat

Version: Deno 2.0.* / canary

I am using windows and decided to switch from feathersjs to simple deno or hono+deno with mongoose/mongodb

Tried all possible options, changing deno versions or mongoose or mongdb. 
It works on my IP (sometimes) but rest it doesnt work from any other IP. 
Evfen my Atlas cloud Network is set to 0.0.0.0, 
Connect well with Hono+Bun or Bun, or Nodejs or featherjs.

After spending 3 days and tried all possible solutions, I gave up and switched to bun for now. My project is getting delayed. I had high hopes from deno. 

**URI** :  mongodb+srv://<user>:<password>@cluster.rhaiu.mongodb.net/testdb

Latest error is around : 

`MongoDB connection failed: MongooseServerSelectionError: Server selection timed out after 5000 ms at _handleConnectionErrors (c:\home\git\...........) at NativeConnection.openUri (c:\home\git\...\node_modules\mongoose\lib\connection.js:860:11) at eventLoopTick (ext:core/01_core.js:214:9) at async connectDB (file:///C:/home/git/..../src/config/db.ts:76:5) at async startApp (file:///C:/home/git/..../main.ts:20:7) { message: "Server selection timed out after 5000 ms", reason: TopologyDescription { type: "ReplicaSetNoPrimary",`
Repository: rust
Issue: compiletest: Automatically specify `-Zunstable-options` when the `edition` header is set to an unstable edition
Labels: A-testsuite,C-enhancement,T-compiler,T-bootstrap,A-compiletest,E-needs-investigation

During each new edition, it is a bit of a hassle to add/remove `-Zunstable-options` headers for the next edition. I think it would be helpful to automatically specify `-Zunstable-options` when an `edition` header specifies an unstable edition. This means there would roughly be one place to make the switch (compiletest itself).
Repository: godot
Issue: Tileset's physics layer polygon editor doesn't update tile preview when selecting another tile in expanded mode
Labels: bug,topic:editor,topic:2d

### Tested versions

- v4.3.stable.arch_linux, should be https://github.com/godotengine/godot/commit/77dcf97d82cbfe4e4615475fa52ca03da645dbd8

### System information

Godot v4.3.stable unknown - Arch Linux #1 SMP PREEMPT_DYNAMIC Fri, 22 Nov 2024 16:04:27 +0000 - X11 - Vulkan (Mobile) - integrated Intel(R) UHD Graphics 620 (WHL GT2) - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz (8 Threads)

### Issue description

Issue:
The expanded collision polygon editor for a selected tile of a TileMapLayer does not update the content when selecting another Tile.

Expectation:
selecting another tile should either close the expanded view or update the tile in the still expanded polygon editor, I guess.

This might be related to https://github.com/godotengine/godot/issues/97669, but this exact issue does not happen for me.

### Steps to reproduce

1. Select a `TileMapLayer`
2. Open `TileSet` tab
3. Open `Select` tab
4. Select Tile in TileSet overview
5. Open polygon editor for collision polygon: `Physics` -> `Physics Layer 0` -> Polygon
6. Expand the editor: ![Image](https://github.com/user-attachments/assets/881b40aa-6701-471a-b881-ee9a868bfd65)
7. Select another tile in the overview
8. Preview in expanded Polygon editor does not update and show the newly selected Tile (left tree selected, right tree still shown):
![Image](https://github.com/user-attachments/assets/dcffa832-8763-4dfd-9d5a-355eaa0e2174)
9. Closing the expanded editor updates the preview (left tree selected, left tree shown):
![Image](https://github.com/user-attachments/assets/8e3a4b4e-ae9b-4fe4-b10e-cb459727a53d)


### Minimal reproduction project (MRP)

No MRP
Repository: ui
Issue: [bug]: CLI not abiding by -p / --path
Labels: bug

### Describe the bug

`npx shadcn@latest add button --path=/foo/bar/test-path` is using what's in my `components.json` aliases and not the `test-path`.

Seems like something may have broke as the reply to this doesn't work: https://github.com/shadcn-ui/ui/issues/1803

### Affected component/components

All

### How to reproduce

Add a component with the `-p` or `--path` flags.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
MacOS 15.1.1
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: node
Issue: monitorEventLoopDelay metrics are completely off especially the count
Labels: perf_hooks

### Version

v23.3.0

### Platform

```text
Darwin Rochs-MBP-3710.localdomain 23.4.0 Darwin Kernel Version 23.4.0: Wed Feb 21 21:44:43 PST 2024; root:xnu-10063.101.15~2/RELEASE_ARM64_T6000 arm64
```


### Subsystem

perf_hooks

### What steps will reproduce the bug?

```js
const { monitorEventLoopDelay } = require('perf_hooks')
const h = monitorEventLoopDelay({ resolution: 1 })

h.enable()

setInterval(() => {
  // Just to trigger an event loop iteration 10x per second.
}, 100)

setTimeout(() => {
  console.log(h)
}, 1000)
```

### How often does it reproduce? Is there a required condition?

Every time.

### What is the expected behavior? Why is that the expected behavior?

The expected behaviour would be to get accurate metrics about event loop delay without impacting the event loop itself. In the above example, I would expect to see ~10 iterations.

### What do you see instead?

Using `monitorEventLoopDelay` alters the behaviour of the event loop, causing it to run more than necessary and preventing it from idling. This means that after 1 second with a resolution of `1`, you get ~1000 iterations in 1 second for an app that is mostly idle because of the added timer.

Another similar issue is that even the metrics themselves are wildly inaccurate as described in https://github.com/nodejs/node/issues/34661

### Additional information

It seems to me that this is a fundamental issue with the approach that was used to capture these metrics, and the function would need to be rewritten in order to provide accurate information.

One way to do this that we've been using successfully for years at this point is to collect timing information with 2 hooks on libuv around the non-IO part of the loop to isolate user code. While it's not 100% accurate, it's definitely way more accurate than the current approach and doesn't skew regardless of very low (0-10) or very high (thousands to millions) iterations. Here is a code snippet of the alternative approach: https://github.com/DataDog/dd-native-metrics-js/blob/4b326d5a1669e7a69c5c84a4d3e036163e60b9d5/src/metrics/EventLoop.hpp#L72-L96

I'm willing to open a PR to fix the issue by reworking the internals to monitor libuv directly instead of relying on a timer, but I first wanted to open this issue to see what others think, and if there may be better approaches or subtle potential issue with the proposed new approach. If it sounds good to everyone then I'll just go ahead with a PR. We've been waiting for a long time to get this out of the box, and thought that we could finally remove our native addon but this ended up not being the case, so I'm pretty motivated to help any way I can to fix this.
Repository: tauri
Issue: [bug] Hot reload on android (angular) not working: [vite] failed to connect to websocket
Labels: type: bug,status: needs triage

### Describe the bug

I want to build an app on android using tauri with angular. Hot reload is not working and i get below error message when starting using `npm run tauri android dev`:

When making changes, they are detected and I see the logs: 
```
Initial chunk files | Names | Raw size
main.js             | main  |  8.05 kB | 

Application bundle generation complete. [0.772 seconds]

Page reload sent to client(s).
```
But changes are not reflected in the android emulator. 

Also, when I use `npm run tauri dev` hot reloading works. 



### Reproduction

- Create a project using create tauri app and select angular framework
  `npm create tauri-app@latest`
  select angular

- Initialize app
  `cd tauri-app`
  `npm install`
  `npm run tauri android init`

- Start app in android emulator
   `npm run tauri android dev`

- Change a file and notice that it is not reloaded

### Expected behavior

hot reload on android

### Full `tauri info` output

```text
[✔] Environment
    - OS: Windows 10.0.22631 x86_64 (X64)
    ✔ WebView2: 131.0.2903.70
    ✔ MSVC: Visual Studio Build Tools 2022
    ✔ rustc: 1.82.0 (f6e511eec 2024-10-15)
    ✔ cargo: 1.82.0 (8f40fc59f 2024-08-21)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 22.11.0
    - npm: 10.9.0

[-] Packages
    - tauri :crab:: 2.1.1
    - tauri-build :crab:: 2.0.3
    - wry :crab:: 0.47.2
    - tao :crab:: 0.30.8
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-shell :crab:: 2.0.2
    - @tauri-apps/plugin-shell : 2.0.1
    - tauri-plugin-notification :crab:: git+https://github.com/tauri-apps/plugins-workspace?branch=v2#33e924574afde37003219fdd4d9085abaadf59b8 (2.0.1)
    - @tauri-apps/plugin-notification : 2.0.0
    - tauri-plugin-os :crab:: 2.0.1
    - @tauri-apps/plugin-os : 2.0.0
```


### Stack trace

```text
E Tauri/Console: File: http://tauri.localhost/@vite/client - Line 488 - Msg: [vite] failed to connect to websocket.
E Tauri/Console: your current setup:
E Tauri/Console:   (browser) tauri.localhost/ <--[HTTP]--> localhost:1420/ (server)
E Tauri/Console:   (browser) tauri.localhost:/ <--[WebSocket (failing)]--> localhost:1420/ (server)
E Tauri/Console: Check out your Vite / network configuration and https://vitejs.dev/config/server-options.html#server-hmr .
```


### Additional context

Not sure if this is relevan, but I had to modify package.json that it even starts: 
`"start": "ng serve --host 0.0.0.0",` instead of `"start": "ng serve",`. Besides that, its a normal project created from `npm create tauri-app@latest` (or the powershell version, not sure anymore).
Repository: ui
Issue: [bug]: CLI doesn't interpret tsconfig baseUrl set to ${configDir}
Labels: bug

### Describe the bug

Since TS 5.5, the use of `${configDir}` in tsconfig is valid (more [info](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html#the-configdir-template-variable-for-configuration-files)). It allows for highly re-usable configs which is very convenient.

My tsconfig looks like this:

```json
{
  "extends": "@codecompose/typescript-config/nextjs.json",
  "include": [
    "${configDir}",
    "${configDir}/**/*.json",
    "${configDir}/next-env.d.ts",
    "${configDir}/.next/types/**/*.ts"
  ]
}
```
The `include` list is really only there because otherwise Next.js currently trips over things, but for my backend services I only use the `extends`.

If I run the CLI this is what I get:

```sh
❯  npx shadcn@latest add tooltip
✔ Checking registry.
✔ Installing dependencies.
✔ Created 1 file:
  - @codecompose/typescript-config/${configDir}/src/components/ui/tooltip.tsx
 ```

It looks like the CLI *needs* to have baseUrl in the tsconfig. This works:


```json
{
  "extends": "@codecompose/typescript-config/nextjs.json",
  "compilerOptions": {
    "baseUrl": "." // Required for ShadCN CLI
  },
  "include": [
    "${configDir}",
    "${configDir}/**/*.json",
    "${configDir}/next-env.d.ts",
    "${configDir}/.next/types/**/*.ts"
  ]
}
```

In the extended config, `baseUrl` is set to `${configDir}`. See https://github.com/0x80/typescript-config/blob/main/base.json

I think this should be allowed to work, but I'm not surprised that not all tooling handles it yet.



### Affected component/components

CLI

### How to reproduce

1. Use a similar configuration as described above
2. Run a similar CLI command as described above

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
NA
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: ui
Issue: [bug]: <Link href="#abc"/> inside a dropdown or a drawer will scroll partially to target and scroll back.  
Labels: bug

### Describe the bug

<Link href="#abc"/> inside a dropdown or a drawer will scroll partially to target and scroll to top of page.  

I have a <Link/> anchored to a section-#id .

When this Link component is inside of a <Drawer/> or <Dropdown/>, it will scroll to the target id partially and then scroll back to the top of the page. 

### Affected component/components

Drodown, Drawer

### How to reproduce

Place Link inside dropdown or drawer with the href set to an ID on the same page. 
Click on Link
Watch as it scrolls to and back.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Consistent issue in Safari and Chrome
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: rust
Issue: Tracking issue for release notes of #132706: Stabilize async closures (RFC 3668)
Labels: T-lang,relnotes,A-async-await,F-async_closure,relnotes-tracking-issue


This issue tracks the release notes text for #132706.

### Steps

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

### Release notes text

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

````markdown
# Language
- [Stabilize async closures (RFC 3668)](https://github.com/rust-lang/rust/pull/132706)
````

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

### Release blog section

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

````markdown
````

cc @compiler-errors -- origin issue/PR authors and assignees for starting to draft text
Repository: godot
Issue: Godot becomes non-responsive sometimes when using color picker.
Labels: bug,needs testing,topic:gui

### Tested versions

Godot 4.3.

### System information

Godot v4.3.stable (77dcf97d8) - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Laptop GPU (NVIDIA; 32.0.15.6614) - 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 Threads)

### Issue description

Randomly when I use the color picker and setting the uniforms for a shader. Once the color picker window comes up, Godot becomes 'non-responsive'. There is no errors logged using --verbose, and not .log file generated. It doesn't always happen when I use the color picker, but sometimes. This is only on a larger project. 

### Steps to reproduce

I am not sure. It seems random to me. I wanna find out how to reproduce it. Any tips? 

### Minimal reproduction project (MRP)

I don't have one but can provide one as soon as I can figure out how to reproduce the bug.
Repository: godot
Issue: DisplayServer.get_display_safe_area() wrongly accounts for taskbar on Windows, even on fullscreen mode
Labels: bug,platform:windows,topic:porting

### Tested versions

- Reproducible in: 4.3.stable, 4.4.dev5

### System information

Windows 10.0.19045 - Multi-window, 1 monitor - Vulkan (Forward+) - dedicated GeForce GTX 765M - Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz (8 threads)

### Issue description

On a Windows 10 laptop with a 1920x1080 pixel screen with NO notches/cutouts, both DisplayServer.get_display_safe_area() and DisplayServer.screen_get_usable_rect() report a usable height of only 1040 pixels.

This seems to suggest that the Windows taskbar is being accounted for (it is exactly 40 pixels), which is neither useful nor a true account of the screen's safe area, especially for a fullscreen application. Running the application in windowed mode, fullscreen mode or exclusive fullscreen mode makes no difference to the reported value.

![Image](https://github.com/user-attachments/assets/af5dcb0c-63c9-4de6-ad5d-f7bf06a60813)

### Steps to reproduce

Import the MRP and run the example scene.
Verify that toggling between exclusive fullscreen mode and windowed mode (with the "T" key) does not change the reported safe_area / usable_rect values.

### Minimal reproduction project (MRP)

[wrong_safe_area.zip](https://github.com/user-attachments/files/17952301/wrong_safe_area.zip)
Repository: pytorch
Issue: [`FlexAttention`] Request for the Support of Dropout
Labels: triaged,oncall: pt2,module: pt2-dispatcher,module: flex attention

### 🚀 The feature, motivation and pitch

Dropout is a fairly common concept in anything related to deep learning. This includes the attention mechanism which I shouldn't have to explain why this feature might be important.

It should be handled natively imo, especially since it's fairly simple (I think).

### Alternatives

I thought about including it in the score mod for example but this would alter common behaviour and deviate from other implementations, i.e. the issue is that dropout is applied after the softmax (and the score mod is applied before softmax).

Just a quick thought, we probably could create a dummy value tensor or use the lse to recreate the softmax outputs. But that's a lot of overhead.

### Additional context

_No response_

cc @zou3519 @bdhirsh @penguinwu @yf225 @Chillee @drisspg @yanboliang @BoyuanFeng @chauhang @ydwu4
Repository: neovim
Issue: Lua stdlib deprecation strategy; "frozen" phase
Labels: enhancement,project-management

# (This is a stub; I will leave a comment when this is fully-formed and ready for comment)

# Problem

We have a "can't win" situation:

1. Users and plugin authors get exhausted by deprecation frequency.
2. Core devs get exhausted by the API "maturation" cycle (including "bikeshedding" and other discussions to avoid hard-to-reverse mistakes), 
3. And *conversely*, core devs also get exhausted by
    1. the deprecation phases, and/or
    2. maintenance of old but disfavored APIs.


# Expected behavior

We can actually have it both ways, roughly outlined here: https://sink.io/jmk/neovimconf-2024/#future-deprecation-strategy

## Define "experiment" phase

We have "experimental" stuff but it's not clear what that means.

## Introduce a new deprecation phase: "frozen"

Frozen interfaces continue to be backwards-compatible at an "ABI" level (i.e. programmatic consumers won't break), but their docs and implementation are shuffled to a remote location, safely protecting innocent villagers from their ionizing radiation. 

1. move its implementation to `_deprecated.lua`
2. its programmatic interface ("ABI" compatibility) continues to work
3. delete its docs; it also should not auto-complete by `:lua vim.xx.<tab>`
4. mention it in `:help deprecated`
5. it is "frozen" and unsupported, though programmatic consumers can continue to use it without worrying about hard-breakage
    - bug reports involving a frozen API get rejected.
    - we will keep the old tests in `test/.../deprecated_spec.lua` and that's it. no other support.

This allows us to minimize the API (not ABI) much more aggressively, without breaking anyone.

It still leaves the door open for "full removal" as a later step, but completely avoids debates about whether it is "worth it" to make these kinds of interface-simplifications. And that is exactly the case for `start_client`. We can clear away all of its redundant docs and explanations, without breaking downstream.

## Open questions

- Do we accept PRs for fixing bugs for these, even if they are very small?

- What should be done with vim.deprecate? Should warnings still be printed to command line? Should functions be listed in deprecated checkhealth?

## Closed questions

- tbd

## Outcomes

1. Doing a "breaking change" pr and shepherding it through, advocating for it, etc is exhausting. It's much easier to do that as 1 batch where a bunch of already-frozen APIs get full-removed in 1 PR.

## Todo

1. document `:help stdlib-contract` , `:help stdlib-frozen`
    - Q: what if a bug is reported on a frozen API? (A: rejected)
Repository: rust
Issue: Document the runtime environment assumptions of `std`
Labels: A-runtime,A-docs,C-tracking-issue,T-libs

`std` makes a number of assumptions about the runtime environment that go beyond what is guaranteed by the ABI. They should be documented somewhere. I'm filing this issue to both collect these assumptions and have a discussion about what the best place is to put them.

Assumptions `std` makes:
* On pretty much any platform: `std` is not used when the C platform functions are not available. E.g. using `clone` on Linux and then calling into `std` is definitely not sound. (This one is very obvious)
* `std` is not called from an asynchronous signal handler or after `fork`. `std` makes no attempt at being async-signal-safe ([except](https://doc.rust-lang.org/nightly/std/os/unix/process/trait.CommandExt.html#notes-and-safety) for `panic!` after `always_abort` has been called).
* On UNIX: threads must not be exited or cancelled (e.g. using `pthread_exit` or `pthread_cancel`).
This is because cancellation does not result in proper unwinding meaning destructors aren't called, but the thread's stack is reused – this is incompatible with `pin!` and probably a bunch of library code.
* On UNIX: the stdio file descriptors (`STDIN_FILENO`, `STDOUT_FILENO`, `STDERR_FILENO`) are assumed to be usable as standard input/output/error.
* On UNIX: `sigaltstack` is not used by code that does not also install it's own handlers for `SIGSEGV` and `SIGBUS` (only applicable when `sigaltstack` is used in threads not spawned by `std`).
`std` uses TLS variables to store the address of the stack guard page. While TLS accesses are not documented to be async-signal-safe, they mostly are – except for the first access to a variable. `std` makes sure to always access the relevant variables before setting up a `sigaltstack`, thereby ensuring that the TLS accesses are safe when the signal handler is successfully called. User code has no access to these variables and therefore cannot initialize them, so it must ensure that `std`'s signal handler is not called when they could be uninitialized.
* On older macOS systems: the first access to any TLS variable with a destructor is not done from within `_tlv_atexit`.
There was a platform bug that resulted in crashes when `_tlv_atexit` is recursively called. It has since been fixed, but our minimum supported version is not high enough to include the fix.
* ...
Repository: godot
Issue: Generated trimesh collision shapes have debug fill enabled resulting in z-fighting
Labels: bug,topic:physics,topic:import,topic:3d

### Tested versions

v4.4.dev.custom_build [0eadbdb5d]

### System information

Godot v4.4.dev (0eadbdb5d) - macOS 15.1.0 - Multi-window, 1 monitor - Metal (Forward+) - integrated Apple M1 Max (Apple7) - Apple M1 Max (10 threads)

### Issue description

Collision shapes now have fill and I think it's nice that it's enabled by default, however I believe it's better to disable it when generating trimesh collision shapes from existing meshes because they match the source geometry resulting in z-fighting

![Image](https://github.com/user-attachments/assets/9455ab9b-7c71-4384-a505-848aa10eda0d)


### Steps to reproduce

You can either import a mesh with a `-col` hint or simply create a new MeshInstance3D and click Mesh -> Create Collision Shape on it:

<img width="500" src="https://github.com/user-attachments/assets/75ec33e9-1863-43f6-a8de-305be9aecaab" />


### Minimal reproduction project (MRP)

N/A