sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Screen Space Reflections do not show in screen texture
Labels: topic:rendering,topic:3d

### Tested versions

Reproducible in 4.3.beta2.stable
Reproducible in v4.3.beta.radiant_fork.custom_build [7e4cd8252]


### System information

Godot v4.3.beta.radiant_fork (7e4cd8252) - Arch Linux #1 SMP PREEMPT_DYNAMIC Fri, 31 May 2024 15:14:45 +0000 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 (nvidia; 550.78) - Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (8 Threads)

### Issue description

Screen space reflections fail to show up on objects in the Transparent pipeline where ALPHA = 1; and blending is done via reading from the screen texture instead.

### Steps to reproduce

Example:
```glsl
shader_type spatial;
render_mode unshaded;
uniform sampler2D screen_texture : hint_screen_texture, repeat_disable, filter_linear_mipmap;
void fragment() {
	ALPHA = 1.0;
	ALBEDO = textureLod(screen_texture, SCREEN_UV, 0.0).rgb;
}
```
This shader is enough to completely disable any screen space reflections on the objects that are covered.

### Minimal reproduction project (MRP)

N/A
Repository: next.js
Issue: TypeScript Templates: Confusion around ReadOnly
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: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.13.1
  npm: 10.5.2
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.0.0-canary.48 // Latest available version is detected (15.0.0-canary.48).
  eslint-config-next: 15.0.0-canary.48
  react: 19.0.0-rc.0
  react-dom: 19.0.0-rc.0
  typescript: 5.5.2
Next.js Config:
  output: N/A
```


### Which example does this report relate to?

packages/create-next-app/templates/app-tw/ts/app/layout.tsx and packages/create-next-app/templates/app/ts/app/layout.tsx

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

_No response_

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

_No response_

### Describe the Bug

TypeScript template's read-only props added in #58845 doesn't type check correctly.


As mentioned [here](https://github.com/vercel/next.js/commit/f60c609bdb8ad17b2f15c3dbba89a987be1078d5#commitcomment-142979798), when you destructure props, new variables are created.
[TypeScript does not consider the 'children' variable as readonly](https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgIilQ3wChSkAPSWOAEyUxQFcAbLZgOw2Ak8QgQYAGRQBPCMxgAKAN6k4cNAAtgrOkU4AaUgF8AXIlR0+rMQB55ilWo1JOh5OhgA6JxgByEBnoB8ASjh5BSVVdU04AF44czpgADdfcwB6OMSAbjhk5LgAFVUAZzhgIpRWVggAdyQ6eiQCsGAYJCMUE04zckUiGGYofmkQxXNlGBBWOFYUTgBzSPx7fF8hxRiAI28xX1kbcPtdFI26LZWU0fHlxX89IA).

Therefore, using ReadOnly with destructuring props can cause confusion.

### Expected Behavior

TypeScript templates should not enforce read-only props.

### To Reproduce

1. Run the `npx create-next-app@latest`
2. Check the `src/app/layout.tsx`
Repository: godot
Issue: extend will ignore paths from take_over_path if the path didn't already exist
Labels: bug,discussion,topic:gdscript

### Tested versions

- Reproducible on 4.2.1 and 4.3-beta2

### System information

Godot v4.3.beta2 - Windows 10.0.22631 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3090 (NVIDIA; 31.0.15.3699) - Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12 Threads)

### Issue description

This might be a duplicate of #83542 but it's not quite the same so I figured it's best to create a new issue.

If I use `take_over_path` on a script and give it a path to a file that doesn't exist on the system, then loading a new script which `extends` that path, will not work and will throw the error `Parser Error: Could not resolve super class path res://....` 



### Steps to reproduce

- use `take_over_path` on any class and give it any path (`res://foobar.gd` for example, or even `foo://bar` to be sure the path doesn't exist already)
- using a `load` on the new path will work as expected
- but loading a derived class which extends the new path does not work (i.e: doing an `extends "res://foobar.gd"` or `extends "foo://bar"` will fail with a parse error)

### Base class
```gdscript
extends Node

func _init():
	print("Base Class")
```

### Derived class
```gdscript
extends "foo://bar"

func _init():
	super._init()
	print("Derived")
```

### Main Scene
```gdscript
extends Node

func _ready():
	var base= load("res://base.gd")
	base.take_over_path("foo://bar")

	var base2 = load("foo://bar")
	base2.new()

	var extended = load("res://extended.gd")
	extended.new()
```

On the `load("res://extended.gd")`, we get `Parser Error: Could not resolve super class path "foo://bar"` error.

Note that the issue happens when using a `res://` path too, but if the path points to an actual file which does exist, then the issue doesn't happen.

### Minimal reproduction project (MRP)

[take_over_path_bug.zip](https://github.com/user-attachments/files/16038437/take_over_path_bug.zip)
Repository: terminal
Issue: Cannot start wt through "Run"
Labels: Issue-Bug,Needs-Tag-Fix,Culprit-Centennial

### Windows Terminal version

1.20.11781.0

### Windows build number

10.0.26120.670

### Other Software

_No response_

### Steps to reproduce

win+R then type "wt" in Run

### Expected Behavior

Start the terminal

### Actual Behavior

wt crashed immediately, with the same logs just like [https://github.com/microsoft/terminal/issues/13193](https://github.com/microsoft/terminal/issues/13193).

>   AppName WindowsTerminal.exe 
>   AppVersion 1.21.2406.25002 
>   AppTimeStamp 667b71e3 
>   ModuleName ucrtbase.dll 
>   ModuleVersion 10.0.26100.751 
>   ModuleTimeStamp cdc60ec5 
>   ExceptionCode c0000409 
>   FaultingOffset 00000000000a514e 
>   ProcessId 0x918 
>   ProcessCreationTime 0x1dac9cdc051aa8e 
>   AppPath C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.21.1772.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe 
>   ModulePath C:\WINDOWS\System32\ucrtbase.dll 
>   IntegratorReportId 53217967-c8f2-46a6-9b33-7883da184a4d 
>   PackageFullName  
>   PackageRelativeAppId  

However, with any other ways to start, like start menu, right-click menu or run "wt" in another terminal, it works well.
Repository: kubernetes
Issue: Invalid kube-reserved configuration in kubelet causes frequent node status patch updates ignoring node-status-report-frequency
Labels: kind/bug,priority/backlog,area/kubelet,sig/node,triage/accepted

### What happened?

### Summary

If the CPU values set in kube-reserved/system-reserved configurations are in terms of decimal values of millicores, Kubelet should throw an error and not start, Else, it should throw a warning to aide the triaging. 

Withiout this check, the issue manifests in unexpected places, like frequent status updates, ignoring the node-status-report-frequency value.

### Detailed description

1. We have set the Kubelet's node-status-report-frequency property to 5 minutes to reduce the frequency of the status updates to kube-apiserver
2. But we noticed that this is not honoured and the updates were sent every few seconds
3. On further triaging, we found that, since we  set the kube-reserved values as a function of number of cores, for some worker node compute shapes, we are setting the kube-reserved cpu values as decimal values (in millicores).

E.g. 
"kubeReserved": {
    "cpu": "237.5m",
    "memory": "10Gi"
  }

Kubelet accepted the values provided and kubelet was running without any errors or warnings.

The kubelet module that posts the statuses to kube-apiserver  calculates the current status (to compare  with the status posted already to API server) so as to post the status even if the node-status-report-frequency value is not exhausted.

This module calculates the current capacity in terms of millicores and this results in mismatch with the status stored in kube-apiserver.  

### What did you expect to happen?

Kubelet should fail to start or throw warnings when the kube-reserved/system-reserved values are incorrect

### How can we reproduce it (as minimally and precisely as possible)?

Set the kubeReserved value to a decimal value as below and increase the node-status-report-frequency to 5 minutes

` "kubeReserved": {
    "cpu": "237.5m",
    "memory": "10Gi"
  },``

You would notice that the status is posted every few seconds 


### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
Client Version: v1.28.2
Server Version: v1.27.2
```

</details>


### Cloud provider

<details>
Oracle Container Engine for Kubernetes
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: transformers
Issue: Add `bot_token` attribute to `PreTrainedTokenizer` and `PreTrainedTokenizerFast`
Labels: Feature request

### Feature request

I'm requesting for the attribute `bot_token` (beginning-of-tools token) to be added to the `PreTrainedTokenizer` classes, similar to `eos_token`. This token would be associated with `self.bot_token` and `self.bot_token_id` and would expose the token to downstream consumers like vLLM.

### Motivation

This request builds off [this PR comment](https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.3/discussions/35) as well as the ongoing work to support function calling [in transformers](https://github.com/huggingface/transformers/pull/30621). 

A number of downstream consumers depend on what's available in the `PreTrainedTokenizer` classes, like vLLM's `Sequence` class and `LLMEngine` class [example](https://github.com/vllm-project/vllm/blob/main/vllm/engine/llm_engine.py#L462). For example, the current problem I'm facing is that vLLM doesn't correctly label the finish reason for "tool call" outputs, as, well, tool calls, since the `CompletionOutput.finish_reason` ultimately relies on the attributes available in `PreTrainedTokenizer`. 

As open-source tool calling proliferates, having these attributes exposed would greatly enhance the utility of the library. This token can be set to `None` by default and should be backwards compatible with the right implementation. 

### Your contribution

I can help contribute to the PR and write code. Might need help navigating the library + writing good test cases.
Repository: PowerToys
Issue: Environment Variables - allow changing order of paths by dragging
Labels: Idea-Enhancement,Area-User Interface,Needs-Triage,Product-Environment Variables

### Description of the new feature / enhancement

Add an option to change order of paths by dragging them by "..." button. When I first saw the UI - intuitively I thought it work but it still currently using old UX with moving up/down.

https://github.com/microsoft/PowerToys/assets/9417531/2723aa23-8c4c-4d17-a4de-049f40ce7f2d



### Scenario when this would be used?

I think anyone would prefer this to "Move Up" and "Move Down" button - they could be considered deprecated if this gets implemented.

### Supporting information

_No response_
Repository: PowerToys
Issue: Environment Variables - advanced path management (grouping / descriptions / temporary enabling or disabling)
Labels: Idea-Enhancement,Needs-Triage,Product-Environment Variables

### Description of the new feature / enhancement

Since Path environment variable is the one that's most manipulated it with, it would be really cool to have some special tools for it's management - path groups.

E.g. you would be able to group paths like `C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\ucrt\x64` and `C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\um\x64\` as `VS Linker` and add some description to it (e.g. "Paths for .lib files for Visual Studio"), so it will be easier to make sense of the paths you've added after awhile. 
Grouping, naming and option to add a description would make path stored in much more meaningful way.

Another advanced feature if you could enable/disable path groups or paths in general. 
E.g. if you disable a group or  a path, Power Toys still store it somewhere in memory but it's not included in the current Path. 
And then you can enable it back at any moment.

### Scenario when this would be used?

Described above.

### Supporting information

_No response_
Repository: next.js
Issue: Variables defined in `.env` files that do not begin with `NEXT_PUBLIC_` are not available in Middleware deployed to Vercel
Labels: bug,Middleware,Webpack,Runtime

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/flamboyant-cray-pwlc82

### To Reproduce

1. next dev
2. observe that the middleware logs value as defined in `.env`
3. Deploy to Vercel
4. observe that the middleware logs `undefined` instead of the value defined in `.env`

### Current vs. Expected behavior

##### Current
Variables defined in `.env` files that do not begin with `NEXT_PUBLIC_` are not available in Middleware deployed to Vercel.

BUT, **all** variables defined in Vercel **are** available in Middleware.  This inconsistency is very confusing.

`.env` files offer more functionality, e.g. `MY_PATH="https://${VERCEL_URL}/some/path"`, so it would be great if it _just worked_.

I have tried this workaround: https://github.com/vercel/next.js/discussions/39705#discussioncomment-4621291 but it extremely limited since some dependencies access variables using other syntax like `process.env[name]`.


##### Expected

Consistent behaviour.  If **all** environment variables defined in Vercel are made available to middleware, so too should all environment variables defined in `.env` files.



### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:42 PST 2022; root:xnu-7195.141.26~1/RELEASE_ARM64_T8101
  Available memory (MB): 8192
  Available CPU cores: 8
Binaries:
  Node: 20.10.0
  npm: 10.2.3
  Yarn: N/A
  pnpm: 8.15.4
Relevant Packages:
  next: 14.2.4 // Latest available version is detected (14.2.4).
  eslint-config-next: 14.2.4
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Developer Experience, Middleware, Runtime, Webpack

### Which stage(s) are affected? (Select all that apply)

Vercel (Deployed)

### Additional context

This issue is related to Vercel deployment, see the discussion here https://github.com/vercel/next.js/discussions/39705
Repository: godot
Issue: Closing, opening, resizing windows and popups leads to engine and screen freezes on Endeavour OS
Labels: bug,platform:linuxbsd,topic:porting

### Tested versions

- Reproducible in v4.2.2.stable.arch_linux

### System information

Godot v4.2.2.stable unknown - EndeavourOS #1 SMP PREEMPT_DYNAMIC Fri, 21 Jun 2024 19:49:19 +0000 - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU () - AMD Ryzen 5 5600H with Radeon Graphics (12 Threads)

### Issue description

_Possible duplicate, please read the details all the same._

I've noticed this issue on two actions until now:
1. When I'm opening a new window or resizing it. So running my game, opening Project Settings, etc.
2. When I'm opening any sort of popup/dropdown. Example: If I'm in the script editor, going to Edit can cause it to freeze. Or in the Edit submenu, hovering over Line can make it freeze.

Sometimes just the editor freezes, sometimes it's just a minor delay and at other times my whole screen freezes and I have to use my secondary screen to reset my display. Moving windows between multiple displays is almost guaranteed to mess things up.

I have noticed this on both my GPUs: AMD and Nvidia. I'm running on Nvidia using prime-run package.

All my packages are up to date from AUR, and I installed Godot from there as well.

I've also disabled Multi Window in the Editor Settings.

Downloading the x86_64 file directly from the website and using that doesn't seem to be triggering the lag problem, other problems still persist.

Lastly, I keep getting this warning in the editor: 
`platform/linuxbsd/x11/display_server_x11.cpp:5603 - XCreateIC couldn't create wd.xic`

### Steps to reproduce

Use the editor normally. Open some windows, popups, menus and eventually one will cause a lag or a freeze within the first minute of using Godot.

### Minimal reproduction project (MRP)

N/A
Repository: next.js
Issue: Does the devcontainer fail for everyone or just me when attempting to build nextjs from source?
Labels: bug

### Link to the code that reproduces this issue

https://github.com/garyhuntddn/next.js.git

### To Reproduce

1. Checkout the source code from the canary branch
2. Open Visual Studio Code
3. Either when prompted, or via the menu, open the project in a devcontainer
4. Attempt to run pnpm install / pnpm run build

### Current vs. Expected behavior

Would expect the docker devcontainer to have the environment setup correctly ready to build, develop and test the nextjs src

### Provide environment information

```bash
OS = OpenSUSE and OS X, multiple versions tested

Being in Docker it should be a clean environment and not depend on the host OS.

The options below refer to bugs in Next rather than in the build environment for next so aren't relevant.
```


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

Not sure

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

Other (Deployed)

### Additional context

If the devcontainer is no longer being maintained then I would suggest it should be removed as having it there in a non-working condition is just a distraction
Repository: puppeteer
Issue: [Feature]: waitForEvent
Labels: feature,P3

### Feature description

I'm not exactly a puppeteer expert, but it seems to me that it's not easily possible to await the emission of arbitrary events on arbitrary elements.

So my proposal would be to add a `waitForEvent` method to the page class, which can currently be achieved with this snippet:

```typescript
declare module "puppeteer" {
  interface Page {
    waitForEvent<
      Selector extends string,
      Event extends string,
      Count extends number,
    >(
      this: Page,
      selector: Selector,
      event: Event,
      opts?: { timeout?: number; count?: Count },
    ): Promise<
      () => Promise<
        (
          Event extends keyof ElementEventMap
            ? ElementEventMap[Event]
            : globalThis.Event
        ) extends infer E
          ? Count extends 1 | number
            ? E
            : E[]
          : never
      >
    >;
  }
}

Page.prototype.waitForEvent = async function (
  selector,
  event,
  { timeout = 100, count = 1 } = {},
) {
  const waitForEvent = Promise.withResolvers<any>();
  const resolutionFunctionName = crypto.randomUUID();
  await this.exposeFunction(resolutionFunctionName, waitForEvent.resolve);
  await this.$eval(
    selector,
    (element, { event, count, resolutionFunctionName }) => {
      const encounteredEvents = [] as any[];
      element.addEventListener(event, (e) => {
        encounteredEvents.push(e);
        if (encounteredEvents.length >= count) {
          (window as any)[resolutionFunctionName](
            count === 1 ? encounteredEvents[0] : encounteredEvents,
          );
        }
      });
    },
    { event, count, resolutionFunctionName },
  );

  return () =>
    Promise.race([
      waitForEvent.promise,
      new Promise<any>((_, reject) =>
        setTimeout(
          () =>
            reject(
              `timed out while waiting for a ${event} event (${timeout}ms)`,
            ),
          timeout,
        ),
      ),
    ]).finally(() =>
      this.evaluate(
        ({ resolutionFunctionName }) => {
          delete (window as any)[resolutionFunctionName];
        },
        { resolutionFunctionName },
      ),
    );

};
```
So it basically uses exposeFunction to capture events into a "sink" that is then moved to the puppeteer context.

I am, at this point, not sure whether or not it is possible or even wise to use this for something like `event.stopPropagation` and thus it's maybe better to just use `waitForFunction` and limit the possibilities by just awaiting a boolean. Though you'd potentially lose information that might interest you about the event...
Repository: pytorch
Issue: Crash when testing Libtorch example
Labels: needs reproduction,module: crash,module: windows,module: cpp,triaged

### 🐛 Describe the bug

Hello,

I tried in my software the example giving by Libtorch (https://pytorch.org/tutorials/advanced/cpp_autograd.html) and it crashed. I can't figure out why it is happening

`#include <torch/torch.h>

auto model = torch::nn::Linear(4, 3);

auto input = torch::randn({3, 4}).requires_grad_(true);
auto output = model(input);

// Calculate loss
auto target = torch::randn({3, 3});
auto loss = torch::nn::MSELoss()(output, target);

// Use norm of gradients as penalty
auto grad_output = torch::ones_like(output);
auto gradient = torch::autograd::grad({output}, {input}, /*grad_outputs=*/{grad_output}, /*create_graph=*/true)[0];
auto gradient_penalty = torch::pow((gradient.norm(2, /*dim=*/1) - 1), 2).mean();

// Add gradient penalty to loss
auto combined_loss = loss + gradient_penalty;
combined_loss.backward();

std::cout << input.grad() << std::endl;`

I tried to apply the correct device on the model and the tensors but it didn't change anything ; I tried to add requires_grad_(true) but it didn't change anything either.

Have you ever faced this problem? And how did you manage to solve it?

Thank you in advance,

Laurick

### Versions

C++17
Visual Studio 2019
Libtorch : 2.0.0+cu118 

cc @peterjc123 @mszhanyi @skyline75489 @nbcsm @vladimir-aubrecht @iremyux @Blackhex @cristianPanaite @jbschlosser