sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: [C#] `uniform vec4 : source_color` cannot be `SetShaderParam()`'d with type `Vector4`. Vice versa, non-`source_color` can't be set with `Color`.
Labels: bug,needs testing,topic:dotnet,topic:shaders

### Tested versions

- Reproducible in 4.2.2 latest stable release (tested with mono).

### System information

Godot v4.2.2.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1080 (NVIDIA; 31.0.15.5176) - Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz (8 Threads)

### Issue description

Essentially as the title says. Godot's shading language has a vec4 type to represent a tuple of 4 floats. One would expect that this could be set by all the Godot types outlined in the docs, regardless of any hint_x decorators. I need to be able to set all vec4 shader parameters with one Godot type, the documentation implies that this should be possible. I am using C#, so I am not sure if this issue is just with C# or also gdscript.

### Steps to reproduce

1. Write a simple shader with some vec4 uniforms, one hinted as a colour.

```glsl
shader_type spatial;

uniform vec4 ColorHinted : source_color = vec4(1.0);
uniform vec4 ColorNotHinted = vec4(1.0);

// if you need to verify that values are/aren't being set

void fragment()
{
    ALBEDO = ColorHinted.rgb;
    //ALBEDO = ColorNotHinted.rgb;
}

```

2. Create a shader material and assign it the shader.
3. Access the shader material in code and try to set parameters.

```csharp
var colorValue = new Color(1.0f, 0.5f, 0.2f, 0.8f);
var vec4Value = new Vector4(0.5f, 0.7f, 0.6f, 0.2f);

// Doesn't work
material.SetShaderParameter("ColorHinted", vec4Value);

// Doesn't work
material.SetShaderParameter("ColorNotHinted", colorValue);

// Works
material.SetShaderParameter("ColorHinted", colorValue);

// Works
material.SetShaderParameter("ColorNotHinted", vec4Value);

```

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: No revert arrow next to export property when parent scene node has parent script type
Labels: bug,topic:editor,needs testing

### Tested versions

Reproductible on :
- v4.3.dev5.mono.official [89f70e98d]
- v4.2.stable.mono.official [46dc27791]
- v4.1.1.stable.mono.official [bd6af8e0e]
- v4.0.stable.mono.official [92bee43ad]
- v3.5.3.stable.mono.official [6c814135b]

### System information

Godot v4.3.dev5.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 (NVIDIA; 31.0.15.5186) - 12th Gen Intel(R) Core(TM) i9-12900 (24 Threads)

### Issue description

### Summary
On a very specific case, the revert arrow is not displayed next to the exported script's properties in the inspector.

InheritedScript.gd :
```gdscript
extends BaseScript
@export var myVar = 42
```
![noArrowInspector](https://github.com/godotengine/godot/assets/32590977/8120f89a-853f-4b7b-8f03-a01b9bd8183f)

### Details
This specific case is :
- Let's have 2 simple scenes composed of 1 Node and the one inheriting from the other (respectively BaseScene.tscn and InheritedScene.tscn).
- Let's have 2 scripts, the one inheriting from the other too (respectively BaseScript.gd and InheritedScript.gd)

BaseScript.gd is :
```gdscript
class_name BaseScript
extends Node
```

InheritedScript.gd is :
```gdscript
extends BaseScript
@export var myVar = 42
```

- BaseScene.tscn node has the BaseScript.gd scripts
- InheritedScene.tscn node has the InheritedScript.gd scripts
- If you set myVar to 12 from the inspector of the InheritedScript node, I expect the revert arrow to show, but it's not.

### Additionnal Info :
- I originally discovered the problem in C#. I can provide the scripts if needed
- If the InheritedScene.tscn does not inherits BaseScene.tscn, the arrow is here
- If the BaseScene.tscn has the InheritedScript.gd (instead of BaseScript.gd) or no script at all, the arrow is here

### Steps to reproduce

- Extract the given sample project inherited-export-prop-norevert-issue
- Open the sample project with godot
- Open InheritedScene.tscn
- Select the only node AInherited from the scene dock
- You can see the MyVar value is 12 in the inspector and the revert arrow is not here while the default value is 42

### Minimal reproduction project (MRP)

[inherited-export-prop-norevert-issue.zip](https://github.com/godotengine/godot/files/15075941/inherited-export-prop-norevert-issue.zip)
Repository: excalidraw
Issue: Unify `Store` data flow for local updates
Labels: refactor,store

Local changes within the editor are still being recorded after the `App` component updates. This means that our data flow of capturing changes is `action` -> `componentDidUpdate` -> `store`, but updates through the `updateScene` API end up in the `Store` before component updates - to filter out yet uncommitted local elements and eliminate potential concurrency issues.

As stated in https://github.com/excalidraw/excalidraw/pull/7348#discussion_r1516057935, we should not capture the _increments_ post component update, but emit them from the user actions and apply them to the `Store` directly. Additionally, turning on recording in relevant actions and capturing the changes after component updates does not just seem error-prone, but might also lead to unexpected issues related to `React`'s auto-batching & concurrent mode.

Moreover, from the event sourcing perspective, coupling renders with exactly one user action is just plain wrong - we should be able to have multiple actions as part of one render, as well as one "async" action spread across multiple renders.

> In theory, to support async actions properly, we would likely need to establish transactions on the elements level (with transaction id, rollback possibility, etc.)  in case there are other actions triggered in the meantime - such instances are out of the scope of this initiative.

```[tasklist]
### Tasks
- [ ] Remove scheduling of increments capture and snapshot update post component update
- [ ] Identify and refactor actions which are dependent on multiple `setState` calls or are generally asynchronous
- [ ] Update local store data flow from `action` -> `state` -> `componentDidUpdate` -> `store` into `action` -> `store` -> `state`.
```

> Store should not be considered as a mediator of the state, as it is handling only a subset of state operations. Especially it's interested only in (observed) committed data (no ephemerals).
Repository: excalidraw
Issue: Improve handling and exchanging of ephemerals
Labels: performance ⚡️,refactor,store

As their name suggests, _ephemeral_ actions, such as dragging, resizing or drawing, do not fit into the whole `Store` story very well. Ideally, such actions should be streamed over to the other clients as quickly as possible, with as small a footprint as possible. 

However, the biggest weak point currently is that each received remote action updates the `Store` snapshot by deep cloning changed elements. For shared scenes with multiple users simultaneously performing multiple ephemeral actions, it's far from ideal.

The ultimate solution is to avoid deep cloning of elements into the snapshot and not performing "snapshots diffing" at all, which is a far future, as currently we perform the diffing on all local actions. The next best solution, apart from optimising cloning itself, is to keep diffing, but postpone the clone as much as possible. Ideally the clone should be scheduled just once (A) and performed only if it's needed (B). Meaning we could do the following.

```[tasklist]
### Tasks
- [ ] Separate ephemeral updates from committed updates and debounce these updates of snapshot and related necessary cloning per `clientId`. Flush pending updates before locally capturing a change ~ solves (A).
- [ ] Add a logical `source: "local" | "remote"` on the element level (locally computed out of `clientId` or similar), so that we calculate changes only on the "local" updates and clone only remotely modified elements ~ solves (B), also allows to deprecate `filterUncomittedElements`.
- [ ] Consider streaming increments as ephemerals to the other clients and do not perform diffing to obtain them (otherwise it would not be great for perf.). Either way, we will likely want to keep receiving all elements once in a while, to ensure consistency if things go wrong, or at least until increments are SSOT.
- [ ] Consider a different Delta format for ephemerals, containing element ids and expressing operations instead of the state - i.e. imagine dragging thousands of elements, where x and y represent the same Δ on all elements, `Op { x: +10, y: -20 }`.
- [ ] Consider integrating mouse movements into ephemeral `appState`.
```
Repository: excalidraw
Issue: Decouple `Store` from the editor
Labels: refactor,store

```[tasklist]
### Tasks
- [ ] Separate `Store` into a standalone package, which could be also potentially used server-side.
- [ ] Draw a fine line between the shared functions, utilities & types - likely will need to be separated as well.
- [ ] Test the `Store` independently, as currently it is being tested indirectly by the `History` integration tests (unit, integration & performance tests)
- [ ] Think about an API for a pluggable Store (far future).
```
Repository: excalidraw
Issue: Decouple `History` from `Store`
Labels: refactor,store,history

As of now, `History` is controlled by the `StoreAction` and thus coupled to the `Store` component.

```[tasklist]
### Tasks
- [ ]  Consider decoupling each other once we hit some, yet unknown, limits.
```
Repository: excalidraw
Issue: Expose `Store` emitter to the outside world
Labels: store

After we stabilized the `Store`, especially #7921 and #7923, we might expose the increments emitter to the outside world.

```[tasklist]
### Tasks
- [ ] Design and expose the API for listening and applying increments - i.e. `onIncrement`, `applyIncrement`, etc.
- [ ] Consider exposing changes also in a JSON patch-compatible format for inter compatibility with other tools
```
Repository: godot
Issue: SkeletonIK chain solver operates differently in GDExtension and C++ Module
Labels: needs testing,topic:animation,topic:3d

### Tested versions

Tested 4.2.2

### System information

Linux, x86_64, Kubuntu 22.04, Godot 4.2.2 custom build

### Issue description

I decided to port my C++ extension into a C++ module. I discovered a discrepancy between the two versions and thought I would mention it. When mapping bones between the two versions their orientation is reversed.

### Steps to reproduce

When SkeletonIK3D is in a C++ extension.
```
Vector3 forward_vector = (ci->initial_transform.get_origin() - ci->children[0].initial_transform.get_origin()) .normalized();
```
In a Module, and as it is in the engine's version.
```
Vector3 forward_vector = (ci->children[0].initial_transform.get_origin() - ci->initial_transform.get_origin()) .normalized();
```
The origins swap positions.


### Minimal reproduction project (MRP)

Being a C++ project it is a bit unwieldy to create a small project with this, but I thought I would highlight the discrepancy. I have versions working as a Module and Extension. I just don't think there should be a difference between the versions.
Repository: vscode
Issue: Model is disposed!
Labels: error-telemetry

```javascript
Error: Model is disposed!
at V.ib in src/vs/editor/common/model/textModel.ts:416:10
at V.getLineCount in src/vs/editor/common/model/textModel.ts:801:8
at M in src/vs/editor/browser/widget/diffEditor/diffEditorViewModel.ts:155:20
at updateUnchangedRegions in src/vs/editor/browser/widget/diffEditor/diffEditorViewModel.ts:308:5
at fn in src/vs/base/common/observableInternal/base.ts:282:3
at <anonymous> in out/vs/workbench/workbench.desktop.main.js:693:49164
```
[Go to Errors Site](https://errors.code.visualstudio.com/card?ch=e170252f762678dec6ca2cc69aba1570769a5d39&bH=576c7599-7ca3-2664-1cb5-a7ce651873cf)
Repository: vscode
Issue: Soft Assertion Failed
Labels: error-telemetry

```javascript
Error: Soft Assertion Failed
at I (out/vs/workbench/workbench.desktop.main.js:12:8934)
at new s (out/vs/workbench/workbench.desktop.main.js:694:52464)
at <anonymous> (out/vs/workbench/workbench.desktop.main.js:694:46394)
at Array.map (<anonymous>)
at R (out/vs/workbench/workbench.desktop.main.js:694:46332)
at <anonymous> (out/vs/workbench/workbench.desktop.main.js:694:49384)
at h (out/vs/workbench/workbench.desktop.main.js:85:14916)
at <anonymous> (out/vs/workbench/workbench.desktop.main.js:694:49379)
```
[Go to Errors Site](https://errors.code.visualstudio.com/card?ch=59d84c5c8cecf22b24e316c5443dc3ec49462589&bH=93fdf345-6f22-5740-c93a-b71a3c32870b)
Repository: electron
Issue: [Bug]: Dump files cannot be generated on mac
Labels: bug :beetle:,has-repro-comment,28-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

28.1.0

### What operating system are you using?

macOS

### Operating System Version

12.0.1

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Expected Behavior

### code
```js
crashReporter.start({
  companyName: "demo",
  uploadToServer: false,
  compress: true,
});
setTimeout(() => {
  process.crash()
}, 3000);
```
Dump files can be generated in the local development environment
![image](https://github.com/electron/electron/assets/42735115/54cd1062-176c-4984-99d7-f75c56b303e6)

It should also be possible to generate a dump file after the application is built.


### Actual Behavior

But after building unable to generate dump file 😭.
![image](https://github.com/electron/electron/assets/42735115/55c15a76-2a41-4651-a31e-31a81305c0d7)


### Testcase Gist URL

See https://github.com/electron/electron/issues/41942#issuecomment-2081312776

### Additional Information

After the application was packaged, I tested it on multiple Macs and found that the dump can be generated normally under the 10.13.6 system version; but not on 12.0.1 or higher versions. Why is this?
Repository: storybook
Issue: [Documentation]: Configure the testing framework for portable stories (With Jest)
Labels: documentation,needs triage

### Describe the problem

On [this](https://storybook.js.org/docs/writing-tests/storyshots-migration-guide#jest) guide to migrate the storyshots to the latest storybook version (for jest) the function `getAllStoryFiles` does not return the `componentName` that is needed but comparing with Vitest it does return it.

So my suggestion it is just to update the following function:
```typescript
function getAllStoryFiles() {
  const storyFiles = glob.sync(
    path.join(__dirname, '../**/*.{stories,story}.{js,jsx,mjs,ts,tsx}'),
  );

  return storyFiles.map((filePath) => {
    const storyFile = require(filePath);
    + const componentName = path.basename(filePath).replace(/\.(stories|story)\.[^/.]+$/, '');
    return { filePath, storyFile, componentName }; // return the componentName
  });
}
```

### Additional context

_No response_
Repository: excalidraw
Issue: Migration infrastructure for `Store` increments
Labels: store

Once the schema of the state (or deltas) changes, we should be able to migrate up and down the existing increments as we should treat them as SSOT. As part of this task, prepare migrations strategy and infrastructure for migration of existing increments.
 
```[tasklist]
### Tasks
- [ ] Prepare migrations strategy and infrastructure for migration of existing increments
- [ ] Syntactic validation of increments (compile time, runtime)
- [ ] Semantic validation of increments (runtime)
```
Repository: excalidraw
Issue: Exchange `Store` increments between clients
Labels: store

Exchange the increments as an SSOT between the clients, achieving better granularity when multiple users work on the same element/s (even asynchronously) and eventually sync the changes together, converging to the same state on all clients.

To keep the P2P nature of the collaboration together with E2EE, we will likely need to keep the application of increments & related conflict resolution client-side. However, we could consider opting for stateful coordination between clients, such as holding version vector (VV) remotely, in order to remember which clients are on which versions, optimise communication and define total order by a central authority (CA).

```[tasklist]
### Tasks
- [ ] Deprecate element-based reconciliation based on `version` & `versionNonce`
- [ ] Update the state by applying remote increments based on the API introduced in #7925
- [ ] Define conflict resolution strategy (i.e. LWW) and related order of increments (CA approach above, optionally having logical clocks & version vectors client-side)
- [ ] Define a syncing strategy and related coordination/coordination, such as - stateful CA-based coordination, acknowledging increments server-side, pushing increments to clients directly, rebasing unacknowledged increments client-side, applying increments client-side etc.
- [ ] Consider adding additional metadata to the `Store`, such as VV, to be aware of other remote `Store`s and their versions
- [ ] Consider adding additional metadata to the increments, such as `id` (to ensure they are not applied twice), `sourceId` (to distinguish between local/remote increments), `type` (to distinguish between "committed" and "ephemeral" increments), potentially HLC for client-side order
- [ ] Consider system testing multiple bootstrapped clients simultaneously, similarly to what we do in collab tests, going one level above of integration tests
```
Repository: excalidraw
Issue: Persist `Store` increments on the clients
Labels: store

```[tasklist]
### Tasks
- [ ] Introduce and expose an option to persist increments inside db (i.e. `IndexedDB`) on increment
- [ ] Load persisted increments out of the db on init
- [ ] Keep persisting / loading separated from the domain logic of the store & decoupled from the editor
- [ ] Store snapshot locally and always apply the increments on top of the latest snapshot
- [ ] Consider loading a large log of increments in chunks (due to memory limits)
- [ ] Consider improving perf. of applying changes for a large log of increments
- [ ] Consider sharing the same delta instances between different deltas (flyweight-like for memory)
- [ ] Consider compressing/squashing increments into a more compact form on persist
```
Repository: transformers
Issue: Remove `mps` workaround for `isin()`
Labels: Should Fix,WIP

### Feature request

Remove `mps` workaround for `isin()`

### Motivation

#30376 introduced a workaround for `isin()` on `mps` devices, because PyTorch does not support that op yet: https://github.com/pytorch/pytorch/issues/77764#issuecomment-2067838075.

Going forward, it'd be desirable to use the much more readable `isin()` version. This issue is meant to track PyTorch support of `isin()` on `mps` so we can remove the workaround and simplify the code.

### Your contribution

I can submit a PR when the op is eventually supported.
Repository: vscode
Issue: Copy cell down should preserve the view state of the cell
Labels: bug,papercut :drop_of_blood:,notebook-commands

Testing #210961

1. Have some cell in makrdown
2. Copy cell down
3. Now the other cell shows markdown preview 🐛 

If I am copying a cell down I would expect the view state to be the same as the origin cell.


![Image](https://github.com/microsoft/vscode/assets/1926584/80274eab-c917-4e33-9bb4-5df3e03e9286)
Repository: next.js
Issue: Inconsistent CSS resolution order
Labels: bug,linear: next

### Link to the code that reproduces this issue

https://github.com/GabenGar/repros/blob/main/nextjs/css-out-of-order/README.md

### To Reproduce

Reproduction steps are in the README.md

### Current vs. Expected behavior

Current: 
Different CSS resolution order between development and production. Before I had weird client vs. render CSS issues, but it looks like they are fixed in [14.2](https://nextjs.org/blog/next-14-2#css), although they weren't super reproducible before either.
Expected: 
Work basically like `pages` router.

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10
  Available memory (MB): 7990
  Available CPU cores: 4
Binaries:
  Node: 20.9.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.2 // Latest available version is detected (14.2.2).
  eslint-config-next: 14.2.2
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


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

Not sure

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

next dev (local), next build (local), next start (local), Vercel (Deployed)

### Additional context

_No response_
Repository: godot
Issue: Animation Tree: State machine nodes view does not refresh on Undo/Redo creating new node (until next click)
Labels: bug,topic:editor,topic:animation

### Tested versions

- Reproducible in v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - Ubuntu 22.04.4 LTS 22.04 - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 860M (nvidia; 535.161.07) - Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (8 Threads)

### Issue description

The Animation Tree panel's State Machine view does not update/refresh properly when undoing or redoing an Add node action. User must click on said area to force refresh.

[Peek 2024-04-23 Animation Tree panel doesnt refresh on state machine add node undo-redo.webm](https://github.com/godotengine/godot/assets/1067772/7c436d00-2b4c-4ef3-bdc1-f2c26454893b)


### Steps to reproduce

1. Add an Animation Tree node
2. Inspector > Tree Root > new AnimationNodeStateMachine
3. In AnimationTree panel, start adding new nodes (if you don't have dummy animations to add, just put BlendSpace1D instead)
4. Undo (ctrl+Z) state machine node creation => no visible change
5. Click: view is now refreshed, with nodes removed
6. Redo (ctrl+shift+Z) => no visible change
7. Click: view is now refreshed, with nodes re-added

### Minimal reproduction project (MRP)

N/A
Repository: pytorch
Issue: Foreach tests should xfail on all dtypes that are not supported
Labels: module: tests,triaged,better-engineering,module: mta

### 🚀 The feature, motivation and pitch

I learned recently this happens for our regular OpInfos and helps makes sure that dtype support is covered by either passing tests or xfails. It would be good to do this for our foreach ops as well.

### Alternatives

_No response_

### Additional context

_No response_

cc @mruberry @crcrpar @mcarilli
Repository: storybook
Issue: [Bug]: The modulesCount cache is writing to disk too much
Labels: bug,needs triage

### Describe the bug

The cache to .cache/storybook/dev-server directory (uses file-system-cache package) is writing to a single file for modulesCount a lot and triggers EPERM error sometimes.

This is using webpack builder, may or may not be an issue with vite builder.

Current workaround is to intercept the require for fs-extra and override with memfs + dummy implementations for other methods.

### To Reproduce

It occurs on startup sometimes and depends on the existing load on the file system.

### System

```bash
System:
  OS: Amazon Linux 2
Binaries:
  Node: 16.20.2
  Yarn: 1.22.11
  npm: 8.19.4
Browsers:
  Chrome: 121
npmPackages:
  @storybook/addon-essentials: 7.6.17
  @storybook/addon-iteractions: 7.6.17
  @storybook/addon-links: 7.6.17
  @storybook/blocks: 7.6.17
  @storybook/react: 7.6.17
  @storybook/react-webpack5: 7.6.17
  @storybook/test: 7.6.17
  eslint-plugin-storybook: 0.8.0
  storybook: 7.6.17
```


### Additional context

_No response_