sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Parallel server action calls
Labels: create-next-app,bug,Performance,linear: next,Parallel & Intercepting Routes

### Link to the code that reproduces this issue

https://github.com/yehonatanyosefi/parallel-routes-example

### To Reproduce

1. start the application
2. click start button
3. see console logs come out as ABAB on the server side with two post requests, and on the client side it taking 2 seconds instead of one even though using promise.all

### Current vs. Expected behavior

Current behavior of nextjs server actions are they are executed in sequential fashion, however there is no flag or option or a config to let them be executed in parallel. Causing them to block some ux. For example for ai image generation, you'd have to wait for the last call to finish before making your next one, causing you to need to wait over 15 seconds before you can even generate more images instead of the Expected behavior of being able to send them in parallel and stream in finished generations by awaiting them.

In the example I sent you can see even though I used Promise.all on 2 promises that each take a second that should be expected take only 1 second together but because of the sequential nature the current behavior is it takes 2.

### Provide environment information

```bash
when hosted on vercel it happens, locally it happens too:
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 32393
  Available CPU cores: 20
Binaries:
  Node: 20.10.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.0.0-canary.128 // Latest available version is detected (15.0.0-canary.128).
  eslint-config-next: N/A
  react: 19.0.0-rc-eb3ad065-20240822
  react-dom: 19.0.0-rc-eb3ad065-20240822
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

create-next-app, Parallel & Intercepting Routes, Performance

### Which stage(s) are affected? (Select all that apply)

next dev (local), Vercel (Deployed)

### Additional context

Edit: https://x.com/cramforce/status/1733240566954230063
Above's link to a reply by Vercel's CTO agreeing it should have control if we want it parallel
Repository: godot
Issue: PropertyInfo Usage has no effect in GDExtension
Labels: bug,topic:editor,topic:gdextension

### Tested versions

- Reproducible in 4.3

### System information

Windows 11 - Godot 4.3 - Forward+

### Issue description

While developing a plugin using GDExtension for godot I've noticed `usage` has no effect when adding a custom EditorSettings. You can enter a random int and it doesn't affect anything the main reason I need this is `PROPERTY_USAGE_RESTART_IF_CHANGED` which doesn't work.

It's necessary for GDExtension editor settings to warn user to restart editor on certain critical settings.

```CPP
PropertyInfo propertyGen(Variant::INT, "gdrtx/compute_model", PropertyHint::PROPERTY_HINT_ENUM, "Cuda,OpenCL", 
						PROPERTY_USAGE_DEFAULT | PROPERTY_USAGE_RESTART_IF_CHANGED);
editor_settings->add_property_info(propertyGen);
```

Same issue was addressed here https://github.com/godotengine/godot/pull/66079 which was fixed for ProjectSettings but not EditorSettings.

### Steps to reproduce

1. Create a simple EditorPlugin and register it.
2. Get Editor Settings Instance and Register a new PropertyInfo with `PROPERTY_USAGE_RESTART_IF_CHANGED` flag
3. Run editor.
4. Change the setting and you will be not prompted for restart.

### Minimal reproduction project (MRP)

No Project
Repository: godot
Issue: C# exported StringName property set to null is assigned a non-null empty StringName with a null native value.
Labels: bug,topic:dotnet

### Tested versions

- Reproducible in 4.2 stable and 4.3 stable

### System information

Windows 10 - Godot 4.3

### Issue description

When a node or resource has an exported StringName property and that property is set to null in the tscn or tres file, upon running the game an empty StringName object will be assigned to that property.

### Steps to reproduce

It is specifically these functions from the [C# Glue StringName.cs](https://github.com/godotengine/godot/blob/e3550cb20f5d6a61befaafb7d9cbdb57b24870e4/modules/mono/glue/GodotSharp/GodotSharp/Core/StringName.cs#L55) and [C# Glue VariantUtils.cs](https://github.com/godotengine/godot/blob/e3550cb20f5d6a61befaafb7d9cbdb57b24870e4/modules/mono/glue/GodotSharp/GodotSharp/Core/NativeInterop/VariantUtils.cs#L520) files that cause this behavior:
```csharp
// StringName.cs

private StringName(godot_string_name nativeValueToOwn)
{
    NativeValue = (godot_string_name.movable)nativeValueToOwn;
    _weakReferenceToSelf = DisposablesTracker.RegisterDisposable(this);
}

// Explicit name to make it very clear
internal static StringName CreateTakingOwnershipOfDisposableValue(godot_string_name nativeValueToOwn)
    => new StringName(nativeValueToOwn);
```
```csharp
// VariantUtils.cs

public static StringName ConvertToStringName(in godot_variant p_var)
    => StringName.CreateTakingOwnershipOfDisposableValue(ConvertToNativeStringName(p_var));
```
This behavior can be observed when Godot is setting the properties defined within a tscn or tres file that has a StringName property with a value of null. When attempting to convert a Variant whose type is null, the `godot_string_name` that `ConvertToNativeStringName` returns does not have its `IsAllocated` property checked before creating a new StringName in `CreateTakingOwnershipOfDisposableValue`. This results in an empty StringName being created with an internal NativeValue wrapping a null IntPtr.

This _feels_ like unintended behavior. When other exported reference types are set to null through the editor, they are assigned null at runtime. If this is in fact unintended, I've already written a [small fix](https://github.com/operation404/godot/commit/7e52ce776351a23f3c3d547290707bdda8404862) and can open a pull request with it. I just added a ternary check to see if the native value was allocated before creating a new managed StringName.

If this is _intended_, then I think it should be documented somewhere explicitly. I have many StringName properties set to null by default, and if they aren't specified within a tscn or tres file, they stay null at runtime. If those properties are declared as null within those files, they instead have an empty StringName assigned. Even if a property isn't modified from its default and doesn't need to be specified in the resource file, Godot will sometimes add it anyways, which results in different behavior than if it were excluded.

### Minimal reproduction project (MRP)

-
Repository: rust
Issue: [rustdoc search] allow setting crates to search in before showing results
Labels: T-rustdoc,A-rustdoc-search

specifically, this would mean moving the `#crate-search` dropdown so it is available outside of the results screen.

on desktops, it could be moved into the `<rustdoc-search>` search form, and displayed in a single line.  on mobile, it could be displayed directly underneath the search bar line.

this would significantly speed up searching through the `nightly-rustc` docs when you already know what crate you want to search, although it would require some small refactorings of rustdoc's `search.js`.
Repository: godot
Issue: Texture Progress with offset fill doesn't properly draw with nine patch stretch
Labels: bug,topic:gui

### Tested versions

Tested in v4.3.stable.official [77dcf97d8]

### System information

Windows 10, Forward+ Renderer

### Issue description

Texture progress is supposed to use a fill texture that only fills in the drawn progress inside of an Over or Under dressing texture.
When using it in this way for a texture that needs to be able to be shrunk (necessitating clicking Nine Patch Stretch) - the fill does not draw in the correct UV space, nor properly handling the appropriate texture offset.

![image](https://github.com/user-attachments/assets/ecbd37b6-ca49-401c-beff-61240152328b)

Seen here: clicking on NinePatchStretch has made this smaller texture - that's supposed to be the size of the empty space inside the Over texture - the entire size of the TextureProgress.  It is also still using the original texture offset, not adjusting relatively to the drawn space of the node.

### Steps to reproduce

In a new project - create a TextureProgress node
Use either the supplied textures or any texture that requires an offset Progress texture that is a different size than the original

<img src="https://github.com/user-attachments/assets/c67d8de2-e0f1-4053-a4f0-be336f7238ea" height="80">
<img src="https://github.com/user-attachments/assets/70dabca1-9bdb-48f1-8e7f-994b8c9c1b86" height="100">

Apply the larger texture to the Over (the right image)
Apply the smaller texture to the Progress (the left image)
set the value of the TextureProgress node to 100 to see the progress draw
Enable NinePatchStretch -> observe the smaller Progress texture become the size of the entire rect.

### Minimal reproduction project (MRP)

[textureprogressbug.zip](https://github.com/user-attachments/files/16738516/textureprogressbug.zip)
Repository: godot
Issue: Unable to use subclassed instances of MovieWriter
Labels: bug,topic:gdextension

### Tested versions

Reproducible in 4.3 stable

### System information

MacOs aarch64, Godot v4.3 stable

### Issue description

I was subclassing `MovieWriter` when I realized that calls to `MovieWriter::add_writer` were not adding the writer to the list of available writers when done at scene initialization. This is problematic because, to my understanding, you cannot create new MovieWriter instances prior to this step in a gdextension. 

### Steps to reproduce

- subclass MovieWriter in a gdextension that adverstises mp4 support (MRP attached)
- set the movie writer file to test.mp4 in the project settings
- try to attach it at scene load time, to my understanding, the earliest that this can be done.
- the error :  `setup2: Can't find movie writer for file type, aborting: test.mp4` should be emitted in the debugger.



### Minimal reproduction project (MRP)

The following rust plugin demonstrates the lifecycle issue https://github.com/mobile-bungalow/WriterExample.

see that[ adding the writer](https://github.com/mobile-bungalow/WriterExample/blob/9762d581020fb4f1981786d3891e27897002f465/src/lib.rs#L21) must occur prior to [loading the writer](https://github.com/godotengine/godot/blob/e3550cb20f5d6a61befaafb7d9cbdb57b24870e4/main/main.cpp#L2962).
Repository: flutter
Issue: [macOS] Remove FlutterViewController.mouseDown/Up workaround
Labels: engine,platform-mac,c: proposal,a: mouse,P3,team-macos,triaged-macos

In https://github.com/flutter/engine/pull/40241, I added a workaround for an AppKit bug wherein mouseDown/Up events were ignored when the *Reduced Transparency* accessibility setting was enabled, and the view was hosted in an `NSPopover`.

I filed a Radar and Apple reported the bug fixed in macOS 13.3.1.

When we drop support for macOS 12 in Flutter, we should remove the workaround in
FlutterViewController, here:
https://github.com/flutter/engine/blob/3ce6c4bf17534fddb07ea98df035d33243d9fd7a/shell/platform/darwin/macos/framework/Source/FlutterViewController.mm#L289-L316

So long as nothing else has been added to these methods at that time, the method overrides themselves should be removed, so that we fall back to the default behaviour.

See: https://github.com/flutter/flutter/issues/115015
See: http://www.openradar.me/FB12050037
See: https://developer.apple.com/documentation/appkit/nsresponder/1535349-mouseup
Repository: go
Issue: x/tools/gopls: Extend hover ability to get the type of selected expression
Labels: FeatureRequest,gopls,Tools

### gopls version

golang.org/x/tools/gopls v0.0.0-20240816163142-66adacf20fc4
golang.org/x/tools/gopls@v0.0.0-20240816163142-66adacf20fc4 h1:iSreTB1mHFYjQkoNmGjFjKRGkrhedt4wmfg
47nKSo28=
github.com/BurntSushi/toml@v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=
github.com/google/go-cmp@v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
golang.org/x/exp/typeparams@v0.0.0-20221212164502-fae10dda9338 h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH
3x7MAiqGW6Y=
golang.org/x/mod@v0.20.0 h1:utOm6MM3R3dnawAiJgn0y+xvuYRsm1RKM/4giyfDgV0=
golang.org/x/sync@v0.8.0 h1:3NFvSEYkUoMifnESzZl15y791HH1qU2xm6eCJU5ZPXQ=
golang.org/x/telemetry@v0.0.0-20240712210958-268b4a8ec2d7 h1:nU8/tAV/21mkPrCjACUeSibjhynTovgRMXc32
+Y1Aec=
golang.org/x/text@v0.17.0 h1:XtiM5bkSOt+ewxlOE/aE/AKEHibwj/6gvWMl9Rsh0Qc=
golang.org/x/tools@v0.24.1-0.20240816163142-66adacf20fc4 h1:PoPnfVMls3TamN2+Zq6FsI1uSjUOqW1mt6AXfY
w3kdw=
golang.org/x/vuln@v1.0.4 h1:SP0mPeg2PmGCu03V+61EcQiOjmpri2XijexKdzv8Z1I=
honnef.co/go/tools@v0.4.7 h1:9MDAWxMoSnB6QoSqiVr7P5mtkT9pOc1kSxchzPCnqJs=
mvdan.cc/gofumpt@v0.6.0 h1:G3QvahNDmpD+Aek/bNOLrFR2XC6ZAdo62dZu65gmwGo=
mvdan.cc/xurls/v2@v2.5.0 h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8=
go: go1.22.4



### go env

```shell
GO111MODULE='auto'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/xzb/Library/Caches/go-build'
GOENV='/Users/xzb/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/xzb/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/xzb/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.4'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/xzb/Project/go/tools/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/gv/r110hgbx1gbgzp95kf_q71x40000gn/T/go-build4205968761=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

As the title says, get the type info of seleted range. 
in Goland
https://github.com/user-attachments/assets/7eea395f-490f-420f-8c8e-d1897f679f0e

in rust-analyzer 
[documentation](https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md#hover-range)

https://github.com/user-attachments/assets/1d12247d-eccb-44a6-819e-03ce71b40ed2



### What did you see happen?

We can't hover in selection state to get type information

### What did you expect to see?

Get the type info of seleted range.
related:https://github.com/rust-lang/rust-analyzer/pull/9693

### Editor and settings

_No response_

### Logs

_No response_
Repository: tauri
Issue: [feat] It is not explicitly stated that hyphens cannot be used in the Android Package ID
Labels: type: feature request

### Describe the problem

It is not explicitly stated that hyphens cannot be used in the Android Package ID. If the plugin name is Kebab case, the suggestion will be hyphenated.

example: com.plugin.my-plugin

### Describe the solution you'd like

1. Explicitly state that hyphens are not allowed in the CLI.
2. Automatically convert suggestions. snake_case, or CamelCase.

### Alternatives considered

_No response_

### Additional context

_No response_
Repository: next.js
Issue: Cannot read properties of null (reading 'get')
Labels: bug,Parallel & Intercepting Routes

### Link to the code that reproduces this issue

https://github.com/yehonatanyosefi/parallel-routes-example

### To Reproduce

Happens randomly in production with App Router

### Current vs. Expected behavior

Happens here: `../src/client/components/router-reducer/fill-lazy-items-till-leaf-with-head.ts in fillLazyItemsTillLeafWithHead` at line `153:60`:

```
const existingParallelRoutes = newCache.parallelRoutes.get(key)
```

Error: `Cannot read properties of null (reading 'get')`

![image](https://github.com/user-attachments/assets/b3eeea05-a107-4ad0-8ebb-01d6fd2879a6)

### Provide environment information

```bash
const nextConfig = {
  output: "standalone",
  reactStrictMode: true,
  poweredByHeader: false,
  skipTrailingSlashRedirect: true,
  ...
}
```

```
"next": "^15.0.0-rc.0",
```
```


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

Parallel & Intercepting Routes

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

Other (Deployed)

### Additional context

_No response_
Repository: ollama
Issue: Add option to /api/embed to not normalize embeddings
Labels: feature request,api

The old /api/embeddings endpoint does not seem to normalize embeddings. However, the new /api/embed endpoint does:

https://github.com/ollama/ollama/blob/0f92b19bec97198b035a7801eda14e3d48149033/server/routes.go#L388

This is probably the right behavior as normalized embeddings are what most people want. However, it would be nice if there were an optional argument to /api/embed where one could specify `'normalization':false`.
Repository: node
Issue: vm: TypeError thrown instead of ReferenceError when a Proxy is the vm context
Labels: vm,v8 engine

### Version

v22.7.0

### Platform

```text
Microsoft Windows NT 10.0.22631.0 x64
```


### Subsystem

vm

### What steps will reproduce the bug?

```js
"use strict";
const vm = require("vm");

const context = vm.createContext({
  __proto__: new Proxy({}, {
    get(target, property, receiver) {
      return Reflect.get(target, property, receiver);
    }
  })
});
vm.runInContext("thisFunctionDoesNotExist()", context);
```

Output:

### How often does it reproduce? Is there a required condition?

Always.

### What is the expected behavior? Why is that the expected behavior?

If I instead do

```js
const context = vm.createContext({
  __proto__: new Proxy({}, {})
});
vm.runInContext("thisFunctionDoesNotExist()", context);
```

or simply

```js
const context = vm.createContext({});
vm.runInContext("thisFunctionDoesNotExist()", context);
```

then I get the expected output:

```
$ node test.js
evalmachine.<anonymous>:1
thisFunctionDoesNotExist()
^

ReferenceError: thisFunctionDoesNotExist is not defined
    at evalmachine.<anonymous>:1:1
    at Script.runInContext (node:vm:148:12)
    at Object.runInContext (node:vm:300:6)
```

### What do you see instead?

```$ node test.js
evalmachine.<anonymous>:1
thisFunctionDoesNotExist()
^

TypeError: thisFunctionDoesNotExist is not a function
    at evalmachine.<anonymous>:1:1
    at Script.runInContext (node:vm:148:12)
    at Object.runInContext (node:vm:300:6)
    at Object.<anonymous> (C:\Users\d\OneDrive - domenic.me\Code\GitHub\jsdom\jsdom\test.js:31:4)
    at Module._compile (node:internal/modules/cjs/loader:1546:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1691:10)
    at Module.load (node:internal/modules/cjs/loader:1317:32)
    at Module._load (node:internal/modules/cjs/loader:1127:12)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:217:24)

Node.js v22.7.0
```

### Additional information

I am not 100% sure this is a vm bug. It may be a fundamental limitation of `Proxy` and the complicated ECMAScript spec rules governing `ReferenceError` vs. `TypeError`. But I am pretty sure this is a vm limitation instead:

- Browsers manage to give a ReferenceError here
- Browsers have something very similar to proxies (the WindowProperties object) as part of their global object
- I can't see anything in [the spec for WindowProperties](https://webidl.spec.whatwg.org/#named-properties-object) that cannot be emulated by a Proxy.

This is blocking jsdom from passing the web platform test [window-runtime-error.html](https://github.com/web-platform-tests/wpt/blob/master/html/webappapis/scripting/events/event-handler-processing-algorithm-error/window-runtime-error.html) once I implement the WindowProperties object (https://github.com/jsdom/jsdom/pull/3765).
Repository: ollama
Issue: Custom model generating response not based on the prompt given
Labels: bug

### What is the issue?

 ollama run mapler/gpt2:latest
>>> Hello

"What do you mean?" I asked. "Well, what about the first two or three hundred people who came in a week after your show and didn't speak up for themselves? Or how did they 
react to that announcement of yours as well—that was just an excuse," he said, pointing at my face with his finger on mine.

"What's going through our heads now?" I asked, looking down over the audience in dismay. The only one who seemed visibly shaken up and angry right back then had been me (or 
maybe a friend) while we were making this interview—and he hadn't bothered to tell us about it yet at all since… well, that was too much for him, anyway.
 He wasn'a good guy," I said flatly, "but so why are you saying something like 'you did nothing wrong?' If they thought the right thing would happen with those numbers and 
then told me we were going to get it done by now… well... that was just what happened in Boston for them. They didn't care—the media treated us very badly."
/randy_goddard


### OS

Linux

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.3.6
Repository: godot
Issue: Identical `spatial`/`canvas_item` fragment shaders differ in output, when not using Compatibility/GLES2 renderer
Labels: discussion,topic:rendering,documentation,needs testing,topic:3d

### Tested versions

v4.3.stable.official [77dcf97d8], v4.0.stable.official [92bee43ad], v3.5.2.stable.official [170ba337a]

### System information

Godot v4.2.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 SUPER (NVIDIA; 32.0.15.5612) - AMD Ryzen 5 5600G with Radeon Graphics (12 Threads)

### Issue description

I was trying to translate `canvas_item` shaders to `spatial` and vice versa, in curiosity for how their performance would differ. Some were fine, but others just seemed to have different coloration and I was confused. Then I tested a basic linear gradient, and it seems that `spatial` isn't linear for some reason?

---
This is the case in both Forward+ and Mobile renderers, but in Compatibility it looks fine!

![Godot_v4 2 2-stable_win64_R2vvGmQI6z](https://github.com/user-attachments/assets/0f891a5f-3df5-441a-bac1-e0991c694a00)
> Forward+



![Godot_v4 2 2-stable_win64_DuekR53VzL](https://github.com/user-attachments/assets/4b0470d3-2b84-4bb9-9948-3c4d68b23bd3)
> Compatibility

Here are the identical fragment shaders for both `spatial` and `canvas_item`:
<details>
  <summary>Spatial Code</summary>

```GLSL
shader_type spatial;
render_mode blend_mix, unshaded;

void vertex() {
	POSITION = vec4(VERTEX, 1.0);
}

void fragment() {
	ALBEDO = vec3(1.0 - SCREEN_UV.x, 0.0, 0.0);
	//ALBEDO = vec3(1.0 - UV.x, 0.0, 0.0); // The same as above.
}
```
*`spatial` shader uses `vertex()` to act as fullscreen, but the bug happens regardless.
</details>

<details>
  <summary>CanvasItem Code</summary>

```GLSL
shader_type canvas_item;
render_mode blend_mix, unshaded;

void fragment() {
	COLOR.rgb = vec3(1.0 - SCREEN_UV.x, 0.0, 0.0);
	//COLOR.rgb = vec3(1.0 - UV.x, 0.0, 0.0); // The same as above.
}
```

</details>

---
Interestingly enough, in Godot 3.5 it's the same thing; GLES3 has the same issue and GLES2 doesn't, even though Godot 4 uses GLES3 for Compatibility(afaik). I have tried many combos of `render_mode`s, but it doesn't seem to fix the problem.

This seems like a bug to me, but I wouldn't be surprised if this is intended and I just don't get it.

### Steps to reproduce

Open the repro and run `main.tscn`, bug is only apparent when not using Compatibility/GLES2 renderer.

### Minimal reproduction project (MRP)


[ShaderBugRepro.zip](https://github.com/user-attachments/files/16739382/ShaderBugRepro.zip), 4.x

[ShaderBugRepro3.zip](https://github.com/user-attachments/files/16739383/ShaderBugRepro3.zip), 3.x