sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Expression class does not support underscores in numeric literals
Labels: bug,topic:core

### Godot version

Godot Engine v4.2.beta.custom_build.93cdacbb0

### System information

Godot v4.2.beta (93cdacbb0) - macOS 13.4.1 - Vulkan (Mobile) - dedicated AMD Radeon Pro 5300M - Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 Threads)

### Issue description

The Expression class does not support underscores in numeric literals, such as `1_000_000` or `1_000.000`. These literals can be parsed correctly, but the execution result is not as expected.

In the unit test of the Expression class, TEST_CASE(“[Expression] Underscored numeric literals”) provides three cases. However, these cases can be parsed successfully, but the results after execution do not meet the expectations.

```C++
TEST_CASE("[Expression] Underscored numeric literals") {
	Expression expression;

	CHECK_MESSAGE(
			expression.parse("1_000_000") == OK,
			"The expression should parse successfully.");
	CHECK_MESSAGE(
			expression.parse("1_000.000") == OK,
			"The expression should parse successfully.");
	CHECK_MESSAGE(
			expression.parse("0xff_99_00") == OK,
			"The expression should parse successfully.");
}
```

| Input | Expected | Actual |
|------|----------|----------|
| `1_000_000` | 1000000 | 1 ❌ |
| `1_000.000` | 1000.0 | 1 ❌ |
| `0xff_99_00` | 0xff9900 | 0xff ❌ |
| `4random_characters` | ERROR | 4 ❌ |


This issue is similar to issue #81895 , where the parse process does not return an error when it encounters an invalid expression. Instead, it only keeps the previous valid part.

The following link is the documentation of Underscored numeric literals in Java.
[Underscored numeric literals](https://docs.oracle.com/javase/8/docs/technotes/guides/language/underscores-literals.html)




### Steps to reproduce

1. Run reproduction script.
2. Observe output:
```
Godot Engine v4.2.beta.custom_build.93cdacbb0 - https://godotengine.org
Vulkan API 1.2.261 - Forward Mobile - Using Vulkan Device #0: AMD - AMD Radeon Pro 5300M
 
0
1
0
1
0
255
0
4
--- Debugging process stopped ---

```



### Minimal reproduction project
```
extends Node2D


# Called when the node enters the scene tree for the first time.
func _ready():
	var expr = Expression.new()
	print(expr.parse('1_000_000'))
	print(expr.execute())
	
	print(expr.parse('1_000.000'))
	print(expr.execute())
	
	print(expr.parse('0xff_99_00'))
	print(expr.execute())
	
	print(expr.parse('4random_characters'))
	print(expr.execute())


# Called every frame. 'delta' is the elapsed time since the previous frame.
func _process(delta):
	pass
```
Repository: PowerToys
Issue: [Peek] Add support for previewing in Open and Save As Dialog
Labels: Idea-Enhancement,Product-File Explorer,Product-Peek

### Description of the new feature / enhancement

(I am not a native English speaker and I use translation software to assist in my writing. If there are any wording and grammatical errors, please point them out.)

I would like to be able to use Peek in the system's native file selection dialogs such as Open and Save As.

In the version I'm currently using (v0.75.1), pressing the activation key (i.e. Ctrl+Space) in these windows does not result in any response.

### Scenario when this would be used?

For example, when uploading files, it is very convenient to preview the files to be uploaded in advance in the file selection dialog.

### Supporting information

Many similar products implement this feature, such as QuickLook for Windows. Some even support previewing in third-party software (such as Everything).
Repository: material-ui
Issue: [OutlinedInput][material-next] Add OutlinedInput component
Labels: component: text field,design: material you

Part of https://github.com/mui/material-ui/issues/38374

### Migration Steps

- [x] Copy component files from material (v5) to material-next ([39698](https://github.com/mui/material-ui/pull/39698))
- [ ] Remove deprecated components and componentsProps props
- [ ] Drop support for ThemeProvider in favor of CssVarsProvider
- [ ] Migrate component to Typescript
- [ ] ~Refactor component to use Base UI’s hook if it exists~
- [ ] Implement Material You design specs (will be polished again when working on `TextField`)
- [x] ~Add component playground to v5 docs~ will be part of the `TextField` playground
- [ ] Refactor styles to use component CSS Variables (will be polished again when working on `TextField`)
Repository: material-ui
Issue: [TextField][material-next] Add TextField component
Labels: on hold,component: text field,design: material you

Part of https://github.com/mui/material-ui/issues/38374

### Migration Steps

- [ ] Copy component files from material (v5) to material-next
- [ ] Remove deprecated components and componentsProps props
- [ ] Drop support for ThemeProvider in favor of CssVarsProvider
- [ ] Migrate component to Typescript
- [ ] ~Refactor component to use Base UI’s hook if it exists~
- [ ] Implement Material You design specs (will be polished again when working on `TextField`)
- [x] ~Add component playground to v5 docs~ will be part of the `TextField` playground
- [ ] Refactor styles to use component CSS Variables (will be polished again when working on `TextField`)
Repository: go
Issue: x/crypto/chacha20poly1305: unconditional use of PSHUFB instruction on amd64
Labels: NeedsFix

It looks like golang.org/x/crypto/chacha20poly1305/chacha20poly1305_amd64.s uses PSHUFB instructions unconditionally, even when built for GOAMD64=v1. PSHUFB is part of SSSE3 which is only v2+. In my version of similar code for chacha8rand I didn't want the overhead of two copies of the code and a runtime switch, so I just did

```
// ROL16 rotates the uint32s in register R left by 16, using temporary T if needed.
#ifdef GOAMD64_v2
#define ROL16(R, T) PSHUFB ·rol16<>(SB), R
#else
#define ROL16(R, T) ROL(16, R, T)
#endif

// ROL8 rotates the uint32s in register R left by 8, using temporary T if needed.
#ifdef GOAMD64_v2
#define ROL8(R, T) PSHUFB ·rol8<>(SB), R
#else
#define ROL8(R, T) ROL(8, R, T)
#endif
```

That may be fine for this code too, since newer x86 chips are going to use the AVX code path anyway.
Repository: rust
Issue: `Arc::strong_count` memory ordering is a potential footgun
Labels: T-libs,C-discussion,A-atomic

In https://github.com/rust-lang/rust/pull/115546 the memory ordering of `{Arc,Weak}::{strong,weak}_count` got changed to `Relaxed`, which can cause some hard to debug race bugs.

I tried this code:

```rust
use std::cell::UnsafeCell;
use std::sync::Arc;
use std::thread;

struct SendMe<T>(T);
unsafe impl<T> Send for SendMe<T> {}

fn main() {
    let a = Arc::new(UnsafeCell::new(0i32));
    let b = SendMe(a.clone());
    thread::spawn(move || {
        let b = b;
        for _ in 0..100 {
            unsafe { *b.0.get() += 1; }
        }
    });
    while Arc::strong_count(&a) != 1 {}
    // core::sync::atomic::fence(core::sync::atomic::Ordering::Acquire);
    unsafe { *a.get() += 1; }
}
```

**I expected to see this happen:** I expected the check `strong_count == 0` to be strong enough to avoid a data race in this program. My intuition was that this check implies that no other thread can access the data concurrently.

**Instead, this happened:** With the fence commented out, the above program has undefined behavior. Miri outputs:

```text
error: Undefined Behavior: Data race detected between (1) Write on thread `<unnamed>` and (2) Read on thread `main` at alloc826+0x10. (2) just happened here
  --> src/main.rs:19:14
   |
19 |     unsafe { *a.get() += 1; }
   |              ^^^^^^^^^^^^^ Data race detected between (1) Write on thread `<unnamed>` and (2) Read on thread `main` at alloc826+0x10. (2) just happened here
   |
help: and (1) occurred earlier here
  --> src/main.rs:14:22
   |
14 |             unsafe { *b.0.get() += 1; }
   |                      ^^^^^^^^^^^^^^^
   = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
   = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
   = note: BACKTRACE (of the first span):
   = note: inside `main` at src/main.rs:19:14: 19:27
```

I think we should either put the `Acquire` ordering back or add a warning to the docs that such code requires a manual fence.

### Meta

1.74 = current beta

cc @SUPERCILEX author of https://github.com/rust-lang/rust/pull/115546

@rustbot label T-libs A-atomic
Repository: deno
Issue: Switch glob implementation to use one from dprint
Labels: perf,chore

Current implement is really slow, we should switch to `dprint`'s implementation: https://github.com/dprint/dprint/blob/main/crates/dprint/src/utils/glob/glob.rs

CC @dsherret
Repository: ollama
Issue: API Improvements
Labels: feature request,api

I'm currently writing a webui for ollama but I find the API quite limited/cumbersome. 
What is your vision/plan regarding it? Is it in a frozen state, or are you planning to improve it?

Here's some criticism:

* mixed model/generation endpoints. some namespacing would be nice.
* mixed `model`/`name` params that refer to the same thing.
* `/api/tags`: why is this named tags? 
* `GET /api/tags` to get all available local models but `POST /api/show` to get one?
* some endpoints throw errors, some return `status` as a JSON property. 
* No way to query the available public models repository
* `POST /api/create`: doesn't allow to specify the `Modelfile` as just raw text, so there's no way to create models without file system access (client-side). Also no way to specify model file using just an object. Also for this to work, `FROM` needs to handle remote resources aswell.
* `POST /api/show`: returns a string which forces the client to parse it to get the actual data. It would be nice it it also returned a JSON object.
* `POST /api/embeddings`: without batching support is mostly useless
* `template` in `Modelfile`:
    to properly support chat agents it would be nice to have a chat-specific generation endpoint, and to be able to iterate over them in the `template`. 
    otherwise the feature itself is quite limited and requires the client to mostly override and re-implement all the logic (and it also needs to know all the underlying model parameters).
    (this is how Hugginface does https://huggingface.co/HuggingFaceH4/zephyr-7b-beta/blob/main/tokenizer_config.json#L34)

    Example:

    define `Modelfile` `template` :

    ```
    {{range .Messages}}
    <|{{ .Role }}|>
    {{ .Content }}
    

    {{end}}
    ```
    instead of:

    ```
    {{- if .System }}
    

    {{ .System }}
    

    {{- end }}
    

    {{ .Prompt }}
    

    

    ```

    and then passing the messages as a JSON array to

    `POST /api/chat/generate`
    ```
    {
        ...,
        "messages": [
            {"role": "system", "content": "you are an assistant"},
            {"role": "user", "content": "hello"},
            {"role": "assistant", "content": "hi there"}
        ]
    }
    ```
    

Here's my app if you want to have  a peek: https://github.com/knoopx/llm-workbench
Repository: go
Issue: all: more thorough testing of GOAMD64=v1 instruction limits
Labels: help wanted,Builders,NeedsFix,compiler/runtime

#63871, which found a PSHUFB (v2+) not guarded by any instruction set checks in a crypto/tls dependency, shows that we are not testing GOAMD64=v1 terribly well. That is, it is possible to use newer instructions in Go packages accidentally, without breaking any tests. If we are going to provide GOAMD64=v1 it seems like we should have a test that it works as advertised. 

(To be clear, it is OK to emit these instructions when GOAMD64=v1, which is our default build mode, but only if they are guarded by an instruction set check before use. I don't see any such check in that case.)

I don't believe we have any v1 hardware to run on, and keeping access to that hardware would become progressively difficult in the future. I've heard a suggestion of using QEMU, but that's fraught with all sorts of problems. Instead I wonder if we should set up a stronger, builder version of cmd/compile/internal/amd64's TestGoAMD64v1. That test does the following:

1. Replace any non-v1 instruction with a breakpoint instruction, found by disassembling the binary.
2. Set GODEBUG environment variables to instruct code not to use post-v1 features.
3. Run itself (its own test binary).

The stronger version would set some environment variable on a v1 builder that would cause the assembler to do two things:

1. Replace all non-v1 instructions with breakpoints.
2. Replace CPUID with a call to a simulation function that sets the registers to look like only v1 features are present.

This would apply during all of all.bash, not just during cmd/compile/internal/amd64.test. And it wouldn't depend on our getting the GODEBUG variables correct. We'd need a table of instruction->feature set for the assembler. We could set up the same for v2, v3.

Might be a good fixit week activity.
Repository: deno
Issue: Use JSX regex from deno_graph for parsing pragmas in the REPL
Labels: repl,chore

https://github.com/denoland/deno/pull/20695#discussion_r1342192944
Repository: godot
Issue: Error stacktrace info opens external editors on single-click
Labels: bug,topic:editor,usability

### Godot version

4.2.dev ([6afd320](https://github.com/godotengine/godot/commit/6afd320984cf14198368cc6c53752813a02169e3))

### System information

Arch Linux

### Issue description

When clicking on an error to select it, Godot immediately focuses on the script tab:

https://github.com/godotengine/godot/assets/6501975/b6cf016b-8b9e-4438-a50d-94f4f4bb4aee

The issue is that when using external editors, this single-click behavior making it very difficult to inspect information about the error because it constantly switches to the external editor, and is especially annoying when folding/collapsing the item which sometimes also triggers it:


https://github.com/godotengine/godot/assets/6501975/b3a6b5b3-6f87-4769-b9d9-730d2b072521



### Steps to reproduce

- Use any [external editor](https://docs.godotengine.org/en/stable/tutorials/editor/external_editor.html)
- Run a project and generate some sort of error:
```gdscript
func _ready():
    push_error("Error")
```
- Try to inspect the error source on the Debugger tab
    - Single clicks constantly steal focus from Godot
    - Sometimes, folding/collapsing also does this

### Minimal reproduction project

N/A
Repository: rust
Issue: feature(gen_blocks): cannot use the ? operator in a gen block that returns ()
Labels: T-compiler,C-bug,F-gen_blocks

As per gen_blocks RFC:
> Even when ? is used within a gen block, the block must return a value of type unit or !. That is, it does not return a value of Some(..), Ok(..), or Continue(..) as other such blocks might.

But currently upon using `?` an error occurs: `cannot use the ? operator in a gen block that returns ()`

To reproduce: https://godbolt.org/z/4fGT9EM8q
Repository: godot
Issue: screen_pixel_size has x and y set to 0 in Shader Editor (VisualShader)
Labels: topic:editor,usability,topic:shaders

### Godot version

v4.2.beta4.mono.official [93cdacbb0], v4.1.2.stable.mono.official [399c9dc39]

### System information

Godot v4.2.beta4.mono - Windows 10.0.22621 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3060 Laptop GPU (NVIDIA; 31.0.15.3713) - AMD Ryzen 5 5600H with Radeon Graphics (12 Threads)

### Issue description

![image](https://github.com/godotengine/godot/assets/431426/370b506a-8145-43db-a7b2-542d4f642dc8)

A sample non-zero value would be preferred. Having this node return zero in the editor makes it harder to make shaders that respond correctly to various screen aspect ratios (for instance, when you use screen_uv to make squares).

### Steps to reproduce

1. Create a new VisualShader with the mode set to Canvas Item.
2. Create a new input node, select screen_pixel_size from its dropdown.
3. Enable preview and observe that it is completely black.

### Minimal reproduction project

Not required, steps provided are very simple + visual aid included.
Repository: PowerToys
Issue: [Peek] Code view alternative for certain file types.
Labels: Idea-Enhancement,Needs-Triage,Product-Peek

### Description of the new feature / enhancement

Have a [code] button option on the top so we can view code file contents for certain file types like HTML and SVG for instance, instead of their visual result, or even a possible side by side view.
Code should be shown similar as other code only files like JS and CSS files, with basic syntax colours.

### Scenario when this would be used?

When previewing HTML or SVG files, show button to switch to [code] view.

### Supporting information

_No response_
Repository: PowerToys
Issue: Version update should not auto-enable new modules
Labels: Issue-Bug,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.75.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

General

### Steps to reproduce

Update PowerToys to a new version that introduces new modules

### ✔️ Expected Behavior

The new module should be disabled by default in order to not alter the existing behavior.

### ❌ Actual Behavior

The new module is auto-enabled and therefore potentially changes existing behavior if the new module is triggered in certain scenarios/with certain keyboard shortcuts.

### Other Software

_No response_
Repository: pytorch
Issue: Nesting no_grad in autocast causes backwards graph to be (partially) lost outside of no_grad
Labels: high priority,module: autograd,triaged,actionable,module: amp (automated mixed precision)

              Hmm, I actually think your example is unexpected, can you file a separate bug for it.

_Originally posted by @ezyang in https://github.com/pytorch/pytorch/issues/105211#issuecomment-1787772959_


If I'm in an autocast context and I do a forward pass of a model in no_grad, then do another forward pass outside of that no_grad context but still in the autocast context, arbitrary nodes in the graph will be lost. See example:

```Python
import torch
import torch.nn as nn

l1 = nn.Sequential(
    nn.Linear(2, 2),
).cuda()

l2 = nn.Sequential(
    nn.Linear(2, 2),
    nn.LayerNorm(2),
).cuda()

x = torch.randn(2, 2).cuda()

#################################
# Just linear
################################
with torch.cuda.amp.autocast():
    with torch.no_grad():
        y1 = l1(x)

    y1_2 = l1(x)
    print(y1_2.grad_fn) # None

# Remove autocast
with torch.no_grad():
    y1 = l1(x)

y1_2 = l1(x)
print(y1_2.grad_fn) # AddmmBackward

#################################
# Linear -> LayerNorm makes output
# have grad_fn
################################
with torch.cuda.amp.autocast():
    with torch.no_grad():
        y2 = l2(x)

    y2_2 = l2(x)
    print(y2_2.grad_fn) # LayerNormBackward

with torch.no_grad():
    y2 = l2(x)

y2_2 = l2(x)
print(y2_2.grad_fn) # Still LayerNormBackward

with torch.cuda.amp.autocast():
    with torch.no_grad():
        y2 = l2(x)

    y2_2 = l2(x)
    print(y2_2.grad_fn) # LayerNormBackward

y2_2.sum().backward()
print(l2[0].weight.grad) # None
print(l2[1].weight.grad) # Not none
```

PyTorch version: 2.1.0

cc @ezyang @gchanan @zou3519 @kadeng @albanD @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @mcarilli @ptrblck @leslie-fang-intel @jgong5
Repository: godot
Issue: Breakpoints in VisualStudio C# not working with Godot Console Windows
Labels: bug,topic:editor,needs testing

### Godot version

Godot_v4.1.2-stable_mono_win64 and Godot_v4.1.2-stable_mono_win64_console

### System information

Windows 11

### Issue description

**Versions**
+ Godot 4.1.2 
+ VisualStudio 2019
+ .NET 6
+ OS: Windows 11

(Issue moved from [this original ticket](https://github.com/godotengine/godot-docs/issues/8356) to here)

With the Godot Windows build, breakpoints are working, but printf-debugging is not possible.
With the Godot Console build, breakpoint don't work, but printf-debugging is possible.

So, none of both ways allow efficient debugging. 
Is there a solution or workaround of how to enable breakpoints in the Godot Console build?



### Steps to reproduce

**Issue description part 1:**

Reproduce the problem by setting up a simple C# script and set a breakpoint in Visual Studio. Here are the configuration details:

- Setup a scene in Godot and attach a C# script
- In Godot goto `Editor -> Editor Settings -> Dotnet -> Editor` select `Visual Studio`
- In Godot click the Script-symbol to open Visual Studio
- In Visual Studio create a new debug profile with the following settings (the automatially created profile does not work):
  - Launch: `Executable`
  - Executable: `<path to Godot Windows>` (in my case `C:\Program Files\godot\Godot-v4.1.2\Godot_v4.1.2-stable_mono_win64.exe`)
  - Application arguments: `--path .`  (mind the space and dot after `--path`)
  - Working directory: `.` (dot)
  - Check `Enable native code debgging`
  - Save the settings

Now open your C# script in VisualStudio and modify the `Ready_()` method as shown below and set a breakpoint on the line with the  `GD.Print()` statement: 

```
public override void _Ready()
{
    GD.Print("Hello VisualStudio");  // set a breakpoint at this line
}
```

Press F5 to run the code.
**Result 1:** Program stops at the breakpoint. Continuing the program does *not* output `Hello VisualStudio` to the output-window of Visual Studio.


**Issue description part 2:**

Same setup as before, but in the editor profile set
  - Executable: `<path to Godot **Console**>` (in my case `C:\Program Files\godot\Godot-v4.1.2\Godot_v4.1.2-stable_mono_win64_console.exe`)

Press F5 to run the code.
**Result 2:** A console window opens, but the program does *not* stopp at the breakpoint and `Hello VisualStudio` is sent to the DOS window.


### Minimal reproduction project

Thanks and kind regards,

Peter
Repository: storybook
Issue: [Bug]: `decorators` causes TS error
Labels: bug,documentation,has workaround,typescript,csf,sev:S3

### Describe the bug

Following the code from the [docs](https://storybook.js.org/docs/react/writing-stories/decorators#wrap-stories-with-extra-markup), I get a TS error:

> TS2742: The inferred type of `meta` cannot be named without a reference to `.pnpm/@storybook+types@7.5.2/node_modules/@storybook/types`. This is likely not portable. A type annotation is necessary.


### To Reproduce

```tsx
import type { Meta } from "@storybook/react";

const meta = {
  component: Icon,
  decorators: [
    Story => (
      <div style={{ margin: '3em' }}>
        <Story />
      </div>
    ),
  ],
} satisfies Meta<typeof Icon>;

export default meta;
```


If I remove `decorators`, the error goes away.

### System

```bash
System:
    OS: macOS 13.5
    CPU: (12) arm64 Apple M2 Pro
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.8.1 - /opt/homebrew/bin/node
    npm: 10.1.0 - /opt/homebrew/bin/npm
    pnpm: 8.6.8 - /opt/homebrew/bin/pnpm <----- active
  Browsers:
    Chrome: 118.0.5993.117
    Safari: 16.6
```


### Additional context

TypeScript version is 5.2.2.

Adding `import type {} from "@storybook/types"` is a workaround but ideally it would not be required.
Repository: flutter
Issue: [Impeller] Add docstring for `FilterContents::RenderFilter`.
Labels: engine,P2,c: tech-debt,e: impeller,team-engine,triaged-engine

One of the most important parts is documenting `coverage` and `coverage_hint`.