sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Gradients (Jacobian) in inference
Labels: module: onnx,triaged,onnx-triaged

### 🚀 The feature, motivation and pitch

Neural Nets are often applied in physical or related fields. Here, one usually not only need an output, put also its derivative. With Pytorch one can use Autograd, but I have not found a way to export a Pytorch model to onnx and then get the results from a backwards call. So if there is no way to export any Pytorch gradient calculations, is this planned for the feature? It wouldn't only be a great help for me, I am sure many others would appreciate this functionality!

(If someone found a way to achieve it, please let me know!)

### Alternatives

_No response_

### Additional context

_No response_
Repository: next.js
Issue: Example uses hard coded domain instead of localhost and misses reference to .env file in "how to use"
Labels: examples

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #36-Ubuntu SMP PREEMPT Fri Jul 14 13:27:38 UTC 2023
Binaries:
  Node: 18.18.0
  npm: 10.1.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 13.5.4
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 4.9.5
Next.js Config:
  output: N/A
```


### Which example does this report relate to?

with-zones-app

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

### Describe the Bug

The example is not using the local `blog` application (localhost:4000) but `"https://with-zones-blog.vercel.app"`.

The `home/.env` file and the variable `BLOG_URL` are mentioned in the "Deploy on Vercel" section but should be mentioned in the "How to use" section,too or even better `BLOG_URL` should be `http://localhost:4000` out of the box.

When you use the example in stackblitz no changes in `blog` will show until you change the `.env`

### Expected Behavior

When I follow the "How to use" section or open the example on stackblitz, code changes in `blog` should apply.
The `blog` part should be rendered from the example (localhost:4000) and not from `with-zones-blog.vercel.app`

Problem since 13.4.13 redirects on localhost with pages router are looping see -> https://github.com/vercel/next.js/issues/56615

### To Reproduce

Open [stackblitz example](https://stackblitz.com/github/vercel/next.js/tree/canary/examples/with-zones)
and change something in `blog/pages/post/[id].tsx` and check for your changes.
Repository: go
Issue: x/build: Migrate builders to LUCI
Labels: Builders,NeedsFix,umbrella

Hi Gophers,

The Go team is currently migrating its builders to [LUCI](https://ci.chromium.org/p/golang) and we need your help. As a trusted contributor and owner of the a builder, your input will ensure availability the builder to fellow gophers.

To get started, use these [instructions](https://go.dev/wiki/DashboardBuilders#luci-builders) to migrate your builder. Feel free to provide any feedback/tips you have so we can update them for future users. If you have questions, please tag @golang/release.
 
If you are tagged, you are listed as a owner of a builder that needs migrating.

Thanks for your ongoing support of Go!


- [ ] @steeve
- [ ] @changkun
- [ ] @paulzhol
- [ ] @dmgk
- [x] @mengzhuo
- [x] @jclulow
- [x] @mengzhuo
- [ ] @XiaodongLoong 
- [x] @abner-chenc
- [x] @draganmladjenovic
- [ ] @4a6f656c
- [x] @mengzhuo
- [ ] @Vishwanatha-HD
- [ ] @srinivas-pokala
- [x] @bsiegert
- [ ] @4a6f656c
- [x] @n2vi 
- [x] @0intro
- [x] @rorth
- [ ] @zx2c4
Repository: godot
Issue: Inconsistent ambient light from procedural sky with low starting energy multiplier values
Labels: bug,topic:rendering,topic:3d

### Godot version

v4.1.1.stable.mono.official.bd6af8e0e

### System information

- OS: Windos 10 
- Vulkan API 1.3.242 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 2070 SUPER

### Issue description

When using procedural sky for dynamic ambient light, results are inconsistent depending on what value the energy multiplier starts at. If you run the game with energy mulitplier at 1, you can lower this value all the way to 0 and back again and get expected results, the scene gets darker, then brighter. However if you run the game with the energy multiplier at a low value, say 0 or 0.01, increasing the energy multiplier to 1 results in a in scene significantly darker ambient light than expected.     

![2023-10-09 12_06_47-](https://github.com/Zylann/godot_voxel/assets/46543541/d831c958-19eb-4c14-9e4a-7588f6898815)
Game started with Energy multipler set to 1, expected results at energy multipler 1.

![2023-10-09 11_59_51-](https://github.com/Zylann/godot_voxel/assets/46543541/21d2f6cf-1ca0-417a-b73b-c3d6c21d1712)
Game started with Energy multipler set to 0.01, inconsistent results at energy multipler 1.     

### Steps to reproduce

1. Open new project.
2. Add cube mesh, camera, and world environment to scene.
3. Ensure WorldEnvironment is set to procedural sky, process mode automatic or real time.
4. In WorldEnvironment inspector set ambient light to Sky.
5. Set energy multiplier 1, run the game. Reduce Energy Multiplier down to 0 and back again, observing light in scene. Should be as expected.
6. Close game
7. Set multiplier to 0.01, run game again. While game is running, increase energy multipler to 1, observe scene lighting is not consistent with previous, or with the Godot editor.

### Minimal reproduction project

N/A
Repository: material-ui
Issue: [joy-ui][slider] Slider is draggable beyond bounds (touch)
Labels: component: slider,package: joy-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example: https://mui.com/joy-ui/react-slider/

Steps:

1. open example
2. scroll to first example
3. open dev tools with touch
4. drag ouside the bounds of `root`



### Current behavior 😯

On touch devices the dragging of the slider works far beyond the root element. 

Screenshot: the gaps either drag the upper or lower slider

![image](https://github.com/mui/material-ui/assets/1148334/b642788a-34c4-4a19-b23a-115a9d0f6ed5)

If an interactive element is in the gap, the behavior is as expected
![image](https://github.com/mui/material-ui/assets/1148334/a84ae18d-568a-4535-8c82-eaf187b0b7d9)



Screencast

https://github.com/mui/material-ui/assets/1148334/131104b7-b517-4da1-9536-b173e56b0a06



https://github.com/mui/material-ui/assets/1148334/d22467f1-6572-472f-a364-3b34f1f2a027



### Expected behavior 🤔

I expect to be able do click on an area outside the slider bounds without triggering the slider itself, so that I can perform actions like scrolling.

### Context 🔦

I have a page with several slider stacked in a box. I want to scroll the page on mobile, but it is impossible because each slider is somehow blocking me and triggering the slider instead of scrolling.

This breaks my UI/UX.

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```

  System:
    OS: Windows 10 10.0.22621
  Binaries:
    Node: 18.5.0 - C:\Program Files\nodejs\node.EXE
    @emotion/styled: 11.11.0 => 11.11.0
    @mui/base:  5.0.0-beta.17
    @mui/core-downloads-tracker:  5.14.12
    @mui/icons-material: 5.14.11 => 5.14.11
    @mui/joy: 5.0.0-beta.9 => 5.0.0-beta.9
    @mui/material: ^5.14.11 => 5.14.11
    @mui/private-theming:  5.14.12
    @mui/styled-engine:  5.14.12
    @mui/system:  5.14.12
    @mui/types:  7.2.5
    @mui/utils:  5.14.12
    @types/react: ^18.2.23 => 18.2.23
    react: 18.2.0 => 18.2.0
    react-dom: 18.2.0 => 18.2.0
    typescript: ^5.2.2 => 5.2.2

```
</details>
Repository: material-ui
Issue: [joy-ui] Locally tweaking components' variants
Labels: package: joy-ui,design: joy

### Context

We’ve had been thinking about ways to _improving global variants_, and one option that we considered was to remove nonsensical variants (#39161). However, after feedbacks and discussions, we ended up finding that the tradeoffs to the developer experience wouldn’t justify removing them.

That said, we are keen to take a different approach: **Locally tweaking only the nonsensical variants**. 

This means that there would be a deliberation about which variants make sense for a given component, and how they should look—instead of just changing colors.

### Benefits

1. Improvement on the visual design of the library.
2. A lot more freedom for design customization. We’d feel safe to tweak how the outlined variant of a component looks without hurting the other.
    1. Developers would probably have a similar experience, being easier to customize with components being less dependent stylistic-wise.
3. It’s not a foreign approach to developers ⎯ most of the UI component libraries use it.

### Tradeoffs

1. As far as DX, it would be less predictable, which props the tweaked variants will look like.
2. Potentially a bit more work to develop and maintain these components as each style would be local (that’s, as far as I understand, the current Material UI reality, so not as foreign, though).

### Components to be tweaked
Each one of these components is intended to have ad hoc tweaks to variants, and to see more details you should check the appropriate PRs.

- [ ] Circular progress #39492 
- [ ] Linear progress #39492 
- [ ] Radio
- [ ] Slider
- [ ] Switch
- [ ] Tabs

### Will be iterated in the future
- List
- Table
Repository: rust
Issue: Inlining causes miscompilation of code that mixes target features
Labels: A-LLVM,A-codegen,P-high,T-compiler,I-unsound,C-bug,A-target-feature,I-miscompile

The following code ought to be completely fine and UB-free:
```rust
use std::mem::transmute;
#[cfg(target_arch = "x86")]
use std::arch::x86::*;
#[cfg(target_arch = "x86_64")]
use std::arch::x86_64::*;

extern "C" fn no_target_feature(_dummy: f32, x: __m256) {
    let val = unsafe { transmute::<_, [u32; 8]>(x) };
    dbg!(val);
}

#[inline(always)] 
fn no_target_feature_intermediate(dummy: f32, x: __m256) {
    no_target_feature(dummy, x);
}

#[target_feature(enable = "avx")]
unsafe fn with_target_feature(x: __m256) {
  // Critical call: caller and callee have different target features.
  // However, we use the Rust ABI, so this is fine.
  no_target_feature_intermediate(0.0, x);
}

fn main() {
    assert!(is_x86_feature_detected!("avx"));
    // SAFETY: we checked that the `avx` feature is present.
    unsafe {
        with_target_feature(transmute([1; 8]));
    }
}
```
There's some unsafe going on, but the safety comment explains why that is okay. We are even taking care to follow the target-feature related ABI rules (see https://github.com/rust-lang/rust/pull/115476); all calls between functions with different target-features use the "Rust" ABI.

And yet, [this prints](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6adc5699d44d62b73e0c4bc0de09ebf9) (when built *without* optimizations)
```
[src/main.rs:9] val = [
    1,
    1,
    1,
    1,
    538976288,
    538976288,
    538976288,
    538976288,
]
```
The value got clobbered while being passed through the various functions.

Replacing `inline(always)` by `inline(never)` makes the issue disappear. But `inline` attributes must never cause miscompilation, so there's still a soundness bug here.

I don't know if this is the MIR inliner (Cc @rust-lang/wg-mir-opt) or the LLVM inliner going wrong.

Here's an LLVM issue for the problem: https://github.com/llvm/llvm-project/issues/70563
Repository: godot
Issue: Draw passes without trails enabled on particles are repeated per trail segment
Labels: discussion,topic:rendering,topic:3d,topic:particles

### Godot version

42425baa59956dc9d1e22341fe5e5d7f8fad5067 (somewhere before 4.2 beta1)

### System information

Fedora, RX 590

### Issue description

Having a two pass drawing for trails causes the non-skinned mesh to be repeated on every segment of the trail, making effects like a shooting star (billboard star + trail) really difficult to achieve.
![image](https://github.com/godotengine/godot/assets/7917475/75787050-f3d4-486a-9c96-e06a78e56a2e)

https://github.com/godotengine/godot/assets/7917475/99b90743-733c-413e-86a9-5145a37dbb0e


### Steps to reproduce

Open Mrp, observe the sphere draw pass is shown multiple times.

Observed behaviour: the sphere draw pass repeats on each segment
Expected behaviour: the sphere draw pass shows only once at the head of the trail.

### Minimal reproduction project

[TrailDrawingIssue1.zip](https://github.com/godotengine/godot/files/12848587/TrailDrawingIssue1.zip)
Repository: PowerToys
Issue: [PT Run] [Plugins] PluginAdditionalOptions: Support list settings
Labels: Idea-Enhancement,Help Wanted,Product-Settings,Needs-Triage,Run-Plugin,Run-Plugin Manager

### Description of the new feature / enhancement

Support for list settings in PowerToys Run plugins. The settings ui should provide a content dialog to edit a list of string values.

### Scenario when this would be used?

When a plugin needs a setting to edit a list of values.

### Supporting information

The description should be shown a the top of the content dialog as usage documentation. Additional the data should be stored sortable.
Repository: flutter
Issue: [ios][engine]remove iOS 17 checks used for cherry-pick purpose in text input plugin
Labels: a: text input,platform-ios,engine,P3,team-ios,triaged-ios

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

Some of the checks are only there so that cherry-pick is safer, but the logic should apply to older version as well. 

Context: https://github.com/flutter/engine/pull/46591/files#r1349180495



### Proposal

We want to remove that check in main branch
Repository: react-native
Issue: <VirtualizedList renderScrollComponent> should preserve child elements
Labels: Component: VirtualizedList,Needs: Triage :mag:,Needs: Repro,Never gets stale

### Description

It's extremely confusing that this works:

```js
<VirtualizedList
  renderScrollComponent={props =>
    <ScrollView {...props} />
  }
  // ...
/>
```

but this doesn't:

```js
<VirtualizedList
  renderScrollComponent={props =>
    <View>
      <ScrollView {...props} />
    </View>
  }
  // ...
/>
```

The reason appears to be that the third `cells` argument to `cloneElement` call [here](https://github.com/facebook/react-native/blob/570655d80fcb1f213de07af05798897e5dbe42b9/packages/virtualized-lists/Lists/VirtualizedList.js#L1132) (which in this case would be passed a `<View>`) overrides the children of that top-level element. So the `ScrollView` inside gets lost.

What I believe should happen instead is that [`scrollProps`](https://github.com/facebook/react-native/blob/570655d80fcb1f213de07af05798897e5dbe42b9/packages/virtualized-lists/Lists/VirtualizedList.js#L1079) should include `children: cells`. Then it's up to your `renderScrollComponent` function to decide what to do with it.

That would be a breaking change but it seems a lot more in line with how React components are supposed to work? It's bad that wrapping a top-level component completely breaks the logic. (I spent an hour debugging this because I couldn't believe a built-in RN component would do this :). It's possible that I badly misunderstood something, so apologies if that's the case.

### React Native Version

0.72.5

### Output of `npx react-native info`

```
info Fetching system and libraries information...
System:
  OS: macOS 13.2.1
  CPU: (10) arm64 Apple M1 Max
  Memory: 12.29 GB / 64.00 GB
  Shell:
    version: 5.8.1
    path: /bin/zsh
Binaries:
  Node:
    version: 18.17.1
    path: /usr/local/bin/node
  Yarn:
    version: 1.22.19
    path: /usr/local/bin/yarn
  npm:
    version: 9.6.7
    path: /usr/local/bin/npm
  Watchman:
    version: 2023.01.30.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.11.3
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 22.4
      - iOS 16.4
      - macOS 13.3
      - tvOS 16.4
      - watchOS 9.4
  Android SDK: Not Found
IDEs:
  Android Studio: 2022.1 AI-221.6008.13.2211.9514443
  Xcode:
    version: 14.3.1/14E300c
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: javac 18
    path: /usr/bin/javac
  Ruby:
    version: 2.7.6
    path: /Users/dan/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.72.5
    wanted: 0.72.5
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false
```

### Steps to reproduce

see earlier

### Snack, screenshot, or link to a repository

this is about API design
Repository: tensorflow
Issue: cuDNN, cuFFT, and cuBLAS Errors
Labels: stat:awaiting tensorflower,type:build/install,comp:gpu,TF2.14

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

GIT_VERSION:v2.14.0-rc1-21-g4dacf3f368e VERSION:2.14.0

### Custom code

No

### OS platform and distribution

WSL2 Linux Ubuntu 22

### Mobile device

_No response_

### Python version

3.10, but I can try different versions

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

CUDA version: 11.8, cuDNN version: 8.7

### GPU model and memory

NVIDIA Geforce GTX 1660 Ti, 8GB Memory

### Current behavior?

When I run the GPU test from the TensorFlow install instructions, I get several errors and warnings.
I don't care about the NUMA stuff, but the first 3 errors are that TensorFlow was not able to load cuDNN. I would really like to be able to use it to speed up training some RNNs and FFNNs. I do get my GPU in the list of physical devices, so I can still train, but not as fast as with cuDNN.

### Standalone code to reproduce the issue

```shell
python3 -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))"
```


### Relevant log output

```shell
2023-10-09 13:36:23.355516: E tensorflow/compiler/xla/stream_executor/cuda/cuda_dnn.cc:9342] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2023-10-09 13:36:23.355674: E tensorflow/compiler/xla/stream_executor/cuda/cuda_fft.cc:609] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2023-10-09 13:36:23.355933: E tensorflow/compiler/xla/stream_executor/cuda/cuda_blas.cc:1518] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2023-10-09 13:36:23.413225: I tensorflow/core/platform/cpu_feature_guard.cc:182] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2023-10-09 13:36:25.872586: I tensorflow/compiler/xla/stream_executor/cuda/cuda_gpu_executor.cc:880] could not open file to read NUMA node: /sys/bus/pci/devices/0000:01:00.0/numa_node
Your kernel may have been built without NUMA support.
2023-10-09 13:36:25.916952: I tensorflow/compiler/xla/stream_executor/cuda/cuda_gpu_executor.cc:880] could not open file to read NUMA node: /sys/bus/pci/devices/0000:01:00.0/numa_node
Your kernel may have been built without NUMA support.
2023-10-09 13:36:25.917025: I tensorflow/compiler/xla/stream_executor/cuda/cuda_gpu_executor.cc:880] could not open file to read NUMA node: /sys/bus/pci/devices/0000:01:00.0/numa_node
Your kernel may have been built without NUMA support.
[PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]
```
Repository: PowerToys
Issue: [FancyZones] Allow me to drag a window at the very top of a monitor
Labels: Idea-Enhancement,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

When a window is fullscreened (without FancyZones), I am able to simply move my mouse to the top of the monitor, and grab the window without thinking.

When a window is snapped with fancyzones to the top of a monitor, I am unable to do the same, instead resizing the window. The same goes for pressing the X button in the top right, and any other button in the top left.

This feature would emulate the fullscreen behavior so you can thoughtlessly move your mouse to the top of your monitor without requiring precision. 

### Scenario when this would be used?

When users have windows snapped to a zone at the top of a monitor and they want to reposition the window, or wish to close a window by moving their mouse to the top right.

### Supporting information

I am very often finding myself frustrated by needing to reposition the mouse. It is extremely convenient to simply just move my mouse to the top to reposition or to the top right to close a window.
Repository: PowerToys
Issue: Retain Installation Folder
Labels: Area-Setup/Install,Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

I have PowerToys installed in D:\Program Files\Powertoys. Every time I install an update of the application, it directs the installation to C:\Program Files\Powertoys. Obviously the application installer should detect an existing installation and make that the install folder for the current activity. 

As an additional question, I wonder what would happen if I forget to make that change and allow the update to install to the C drive? Would I have some wierd conflicts? Would I lose functionality? Would the installer uninstall the tool from my D drive? Should something unfortunate occur in this situation, this enhancement request should receive an elevated priority or be reclassified as a Bug.

### Scenario when this would be used?

During installation.

### Supporting information

_No response_
Repository: flutter
Issue: [process] Add example app
Labels: package,team-ecosystem,P3,triaged-ecosystem,p: process

Currently (as highlighted in the Scores on pub.dev) we don't provide any kind of example doc or app for `process`. We should have a simple example app for it that demonstrates its functionality.
Repository: go
Issue: proposal: go/types.ImportFunc
Labels: Proposal

I propose to add these two lines to `go/types`:
```
// An ImporterFunc is an implementation of the single-method
// types.Importer interface based on a function value.
type ImporterFunc func(path string) (*types.Package, error)

func (f ImporterFunc) Import(path string) (*types.Package, error) { return f(path) }
```

since we seem to keep typing them out everywhere else:
```
go/analysis/unitchecker/separate_test.go
293:type importerFunc func(path string) (*types.Package, error)

go/analysis/unitchecker/unitchecker.go
438:type importerFunc func(path string) (*types.Package, error)

go/analysis/passes/cgocall/cgocall.go
367:type importerFunc func(path string) (*types.Package, error)

go/packages/packages.go
1099:type importerFunc func(path string) (*types.Package, error)

gopls/internal/lsp/cache/check.go
1861:type importerFunc func(path string) (*types.Package, error)

internal/gcimporter/iexport_test.go
451:type importerFunc func(path string) (*types.Package, error)

internal/refactor/inline/everything_test.go
233:type importerFunc func(path string) (*types.Package, error)
```

@gri @findleyr