helloadhavan/github_issues huggingface dataset:
Repository: electron/electron
Pull request: ci: handle PRs with no checks in rerun apply patches

#### Description of Change

<!--
Thank you for your Pull Request. Please provide a description above and review
the requirements below.

Contributors guide: https://github.com/electron/electron/blob/main/CONTRIBUTING.md
-->

There's an edge case that I wasn't aware of before, where `gh pr checks` exits with a non-zero exit code if there are "no checks reported" for a PR. This seems to be the case for some old PRs that are in merge conflict state.

This PR refactors the workflow to use `gh pr view` instead, which has all the same information we need, in slightly different named fields. Since `gh pr view` is just for viewing a PR, it won't fail on this edge case, `statusCheckRollup` will just be an empty array.

#### Checklist
<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

- [x] PR description included

#### Release Notes

Notes: none <!-- Please add a one-line description for app developers to read in the release notes, or 'none' if no notes relevant to app developers. Examples and help on special cases: https://github.com/electron/clerk/blob/main/README.md#examples -->


Changed files:
filename: .github/workflows/rerun-apply-patches.yml
patch: @@ -35,20 +35,20 @@ jobs:
             echo "Processing PR #${PR_NUMBER}"
 
             # Find the Apply Patches workflow check for this PR
-            CHECK=$(gh pr checks "$PR_NUMBER" --json link,name,state,workflow --jq '[.[] | select(.workflow == "Apply Patches" and .name == "apply-patches")] | first')
+            CHECK=$(gh pr view "$PR_NUMBER" --json statusCheckRollup --jq '[.statusCheckRollup[] | select(.workflowName == "Apply Patches" and .name == "apply-patches")] | first')
 
             if [ -z "$CHECK" ] || [ "$CHECK" = "null" ]; then
               echo "  No Apply Patches workflow found for PR #${PR_NUMBER}"
               continue
             fi
 
-            STATE=$(echo "$CHECK" | jq -r '.state')
-            if [ "$STATE" = "SKIPPED" ]; then
+            CONCLUSION=$(echo "$CHECK" | jq -r '.conclusion')
+            if [ "$CONCLUSION" = "SKIPPED" ]; then
               echo "  apply-patches job was skipped for PR #${PR_NUMBER} (no patches)"
               continue
             fi
 
-            LINK=$(echo "$CHECK" | jq -r '.link')
+            LINK=$(echo "$CHECK" | jq -r '.detailsUrl')
 
             # Extract the run ID from the link (format: .../runs/RUN_ID/job/JOB_ID)
             RUN_ID=$(echo "$LINK" | grep -oE 'runs/[0-9]+' | cut -d'/' -f2)
Repository: huggingface/transformers
Pull request: Remove stale TODO comments in UDOP tied weights

## Summary
Remove outdated TODO comments claiming patch embedding weight tying is "not working".

## Details
Testing confirms the tying mechanism works correctly:
- `patch_embed.proj.weight` and `encoder.embed_patches.proj.weight` share the same tensor
- Only source weights are saved to state_dict
- Weight tying is correctly re-established when loading

The TODO was added during #41580 refactor but the mechanism works identically to token embedding tying.

Changed files:
filename: src/transformers/models/udop/modeling_udop.py
patch: @@ -1420,8 +1420,8 @@ class UdopModel(UdopPreTrainedModel):
     _tied_weights_keys = {
         "encoder.embed_tokens.weight": "shared.weight",
         "decoder.embed_tokens.weight": "shared.weight",
-        "encoder.embed_patches.proj.weight": "patch_embed.proj.weight",  # TODO tie weights for patch embeddings not working
-        "encoder.embed_patches.proj.bias": "patch_embed.proj.bias",  # TODO tie weights for patch embeddings not working
+        "encoder.embed_patches.proj.weight": "patch_embed.proj.weight",
+        "encoder.embed_patches.proj.bias": "patch_embed.proj.bias",
     }
 
     def __init__(self, config):
Repository: ollama/ollama
Pull request: ggml: Fix memory leak on input tensors

For every forward pass through the model, we need to allocate input tensors: tokens, images, positions, outputs and masks. These get allocated in system memory.

However, when we close the context that the tensors were allocated through, the metadata gets freed but the actual backend memory does not. This results in a significant memory leak.

This makes it so that all the memory allocated through a context gets freed when it is closed.

Changed files:
filename: ml/backend/ggml/ggml.go
patch: @@ -447,13 +447,16 @@ func (b *Backend) NewContextSize(n int) ml.Context {
 		panic(fmt.Errorf("requested number of graph nodes (%v) for new context exceeds maximum (%v)", n, b.maxGraphNodes))
 	}
 
+	var allocatedBuffers []*C.struct_ggml_backend_buffer
+
 	return &Context{
 		b:             b,
 		maxGraphNodes: n,
 		ctx: C.ggml_init(C.struct_ggml_init_params{
 			mem_size: C.size_t(n)*C.ggml_tensor_overhead() + C.ggml_graph_overhead_custom(C.size_t(n), false),
 			no_alloc: true,
 		}),
+		allocatedBuffers: &allocatedBuffers,
 	}
 }
 
@@ -474,17 +477,22 @@ type Context struct {
 	// buft is the buffer type used for new tensors
 	buft *C.struct_ggml_backend_buffer_type
 
+	// allocatedBuffers are buffers for tensors that we have allocated in this context
+	// so that we can free them when we close the context
+	allocatedBuffers *[]*C.struct_ggml_backend_buffer
+
 	// maxGraphNodes is the maximum allowed number of graph nodes in this context
 	maxGraphNodes int
 }
 
 func (c *Context) Input() ml.Context {
 	if c.b.input != nil {
 		return &Context{
-			b:             c.b,
-			ctx:           c.ctx,
-			buft:          c.b.input,
-			maxGraphNodes: c.maxGraphNodes,
+			b:                c.b,
+			ctx:              c.ctx,
+			buft:             c.b.input,
+			allocatedBuffers: c.allocatedBuffers,
+			maxGraphNodes:    c.maxGraphNodes,
 		}
 	}
 
@@ -494,10 +502,11 @@ func (c *Context) Input() ml.Context {
 func (c *Context) Layer(i int) ml.Context {
 	if buft, ok := c.b.layers[i]; ok {
 		return &Context{
-			b:             c.b,
-			ctx:           c.ctx,
-			buft:          buft,
-			maxGraphNodes: c.maxGraphNodes,
+			b:                c.b,
+			ctx:              c.ctx,
+			buft:             buft,
+			allocatedBuffers: c.allocatedBuffers,
+			maxGraphNodes:    c.maxGraphNodes,
 		}
 	}
 
@@ -610,6 +619,7 @@ func (c *Context) newTensor(dtype ml.DType, shape []int) (ml.Tensor, error) {
 	if b == nil {
 		return nil, fmt.Errorf("unable to allocate %v from device %v for new tensor", format.HumanBytes2(uint64(size)), C.GoString(C.ggml_backend_buft_name(c.buft)))
 	}
+	*c.allocatedBuffers = append(*c.allocatedBuffers, b)
 
 	C.ggml_backend_tensor_alloc(b, t, C.ggml_backend_buffer_get_base(b))
 	return &Tensor{b: c.b, t: t}, nil
@@ -688,6 +698,11 @@ func (c *Context) FromIntSlice(s []int32, shape ...int) (ml.Tensor, error) {
 
 func (c *Context) Close() {
 	if c != nil {
+		for _, b := range *c.allocatedBuffers {
+			C.ggml_backend_buffer_free(b)
+		}
+		*c.allocatedBuffers = nil
+
 		C.ggml_free(c.ctx)
 	}
 }
Repository: facebook/react
Pull request: [compiler] More precise errors for invalid import/export/namespace statements


import, export, and TS namespace statements can only be used at the top-level of a module, which is enforced by parsers already. Here we add a backup validation of that. As of this PR, we now have only major statement type (class declarations) listed as a todo.

---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33748).
* #33753
* #33752
* #33751
* #33750
* __->__ #33748

Changed files:
filename: compiler/packages/babel-plugin-react-compiler/src/HIR/BuildHIR.ts
patch: @@ -1397,6 +1397,41 @@ function lowerStatement(
       });
       return;
     }
+    case 'ExportAllDeclaration':
+    case 'ExportDefaultDeclaration':
+    case 'ExportNamedDeclaration':
+    case 'ImportDeclaration':
+    case 'TSExportAssignment':
+    case 'TSImportEqualsDeclaration': {
+      builder.errors.push({
+        reason:
+          'JavaScript `import` and `export` statements may only appear at the top level of a module',
+        severity: ErrorSeverity.InvalidJS,
+        loc: stmtPath.node.loc ?? null,
+        suggestions: null,
+      });
+      lowerValueToTemporary(builder, {
+        kind: 'UnsupportedNode',
+        loc: stmtPath.node.loc ?? GeneratedSource,
+        node: stmtPath.node,
+      });
+      return;
+    }
+    case 'TSNamespaceExportDeclaration': {
+      builder.errors.push({
+        reason:
+          'TypeScript `namespace` statements may only appear at the top level of a module',
+        severity: ErrorSeverity.InvalidJS,
+        loc: stmtPath.node.loc ?? null,
+        suggestions: null,
+      });
+      lowerValueToTemporary(builder, {
+        kind: 'UnsupportedNode',
+        loc: stmtPath.node.loc ?? GeneratedSource,
+        node: stmtPath.node,
+      });
+      return;
+    }
     case 'DeclareClass':
     case 'DeclareExportAllDeclaration':
     case 'DeclareExportDeclaration':
@@ -1411,32 +1446,12 @@ function lowerStatement(
     case 'OpaqueType':
     case 'TSDeclareFunction':
     case 'TSInterfaceDeclaration':
+    case 'TSModuleDeclaration':
     case 'TSTypeAliasDeclaration':
     case 'TypeAlias': {
       // We do not preserve type annotations/syntax through transformation
       return;
     }
-    case 'ExportAllDeclaration':
-    case 'ExportDefaultDeclaration':
-    case 'ExportNamedDeclaration':
-    case 'ImportDeclaration':
-    case 'TSExportAssignment':
-    case 'TSImportEqualsDeclaration':
-    case 'TSModuleDeclaration':
-    case 'TSNamespaceExportDeclaration': {
-      builder.errors.push({
-        reason: `(BuildHIR::lowerStatement) Handle ${stmtPath.type} statements`,
-        severity: ErrorSeverity.Todo,
-        loc: stmtPath.node.loc ?? null,
-        suggestions: null,
-      });
-      lowerValueToTemporary(builder, {
-        kind: 'UnsupportedNode',
-        loc: stmtPath.node.loc ?? GeneratedSource,
-        node: stmtPath.node,
-      });
-      return;
-    }
     default: {
       return assertExhaustive(
         stmtNode,
Repository: ollama/ollama
Pull request: ggml: Log filesystem errors

Sometimes loading the GGUF file fails with:
panic: context canceled

This is probably a filesystem error but it doesn't provide any information about what happened.

Changed files:
filename: ml/backend/ggml/ggml.go
patch: @@ -332,6 +332,7 @@ func New(ctx context.Context, r *os.File, params ml.BackendParams) (ml.Backend,
 			// seeking around within an FD shared between all goroutines.
 			file, err := os.Open(r.Name())
 			if err != nil {
+				slog.Warn("file open error", "file", r.Name(), "error", err)
 				return err
 			}
 			defer file.Close()
@@ -342,6 +343,7 @@ func New(ctx context.Context, r *os.File, params ml.BackendParams) (ml.Backend,
 			for s < t.Size() {
 				n, err := io.ReadFull(sr, bts[:min(len(bts), int(t.Size()-s))])
 				if err != nil {
+					slog.Warn("file read error", "file", r.Name(), "error", err)
 					return err
 				}
Repository: nodejs/node
Pull request: doc: update Python 3.14 manual install instructions (Windows)

Refs: https://github.com/nodejs/node/issues/61427
Refs: https://github.com/nodejs/node-gyp/issues/3264

## Current documentation

The document section [BUILDING > Windows Prerequisites > Option 1: Manual install](https://github.com/nodejs/node/blob/main/BUILDING.md#option-1-manual-install) provides the following instructions to install Python, that are correct only up to Python 3.13:

> **Manual install**<br>
The current [version of Python](https://devguide.python.org/versions/) from the [Microsoft Store](https://apps.microsoft.com/store/search?publisher=Python+Software+Foundation)

Python has [deprecated the full installer](https://docs.python.org/3/using/windows.html#the-full-installer-deprecated) since version 3.14 and provides instead the [Python Install Manager](https://docs.python.org/3/using/windows.html#pymanager). The [Microsoft Store](https://apps.microsoft.com/store/search?publisher=Python+Software+Foundation) displays only the versions Python 3.12 and 3.13.

The instructions in the [node-gyp/README > On Windows](https://github.com/nodejs/node-gyp/blob/main/README.md#on-windows) repo documentation section have already been updated and now read:

> Follow the instructions in [Using Python on Windows](https://docs.python.org/3/using/windows.html) to install the current [version of Python](https://www.python.org/downloads/) on Windows.

## Updated documentation

The updated [node-gyp/README > On Windows](https://github.com/nodejs/node-gyp/blob/main/README.md#on-windows) instructions are copied to the [node/BUILDING > Windows Prerequisites > Option 1: Manual install](https://github.com/nodejs/node/blob/main/BUILDING.md#option-1-manual-install) document section in this repo. This covers installing all Python 3 versions, including Python 3.14.



Changed files:
filename: BUILDING.md
patch: @@ -735,8 +735,8 @@ Refs:
 
 ##### Option 1: Manual install
 
-* The current [version of Python][Python versions] from the
-  [Microsoft Store](https://apps.microsoft.com/store/search?publisher=Python+Software+Foundation)
+* The current [version of Python][Python downloads] by following the instructions in
+  [Using Python on Windows][].
 * The "Desktop development with C++" workload from
   [Visual Studio 2022 (17.13 or newer)](https://visualstudio.microsoft.com/downloads/)
   or the "C++ build tools" workload from the
@@ -1146,4 +1146,6 @@ by opening a pull request against the registry available at
 
 [AIX toolbox]: https://www.ibm.com/support/pages/aix-toolbox-open-source-software-overview
 [Developer Mode]: https://learn.microsoft.com/en-us/windows/advanced-settings/developer-mode
+[Python downloads]: https://www.python.org/downloads/
 [Python versions]: https://devguide.python.org/versions/
+[Using Python on Windows]: https://docs.python.org/3/using/windows.html
Repository: vercel/next.js
Pull request: [backport][ci] Make gh auth status optional when triggering a release

Backports https://github.com/vercel/next.js/pull/89098
Part of Closes https://linear.app/vercel/issue/NAR-753/

Changed files:
filename: .github/workflows/trigger_release.yml
patch: @@ -28,10 +28,6 @@ on:
         default: false
         type: boolean
 
-    secrets:
-      RELEASE_BOT_GITHUB_TOKEN:
-        required: true
-
 name: Trigger Release
 
 env:
@@ -62,6 +58,9 @@ jobs:
 
       - name: Check token
         run: gh auth status
+        # This sometimes fails for unknown reasons.
+        # Ignoring failures for now to check if a failure truly implies a failed publish.
+        continue-on-error: true
         env:
           GITHUB_TOKEN: ${{ secrets.RELEASE_BOT_GITHUB_TOKEN }}
Repository: huggingface/transformers
Pull request: handle 1D position_ids for modeling_flash_attention_utils as well

This PR fixes failed test case of 
`pytest -rA tests/models/lighton_ocr/test_modeling_lighton_ocr.py::LightOnOcrForConditionalGenerationModelTest::test_eager_matches_fa2_generate`, in this case `position_ids` is concated to 1D in [position_ids_in_meshgrid](https://github.com/huggingface/transformers/blob/main/src/transformers/models/pixtral/modeling_pixtral.py#L37) func, and hence cause the crash. 

Changed files:
filename: tests/models/lighton_ocr/test_modeling_lighton_ocr.py
patch: @@ -243,11 +243,14 @@ def _prepare_for_class(self, inputs_dict, model_class, return_labels=False):
         """
         inputs_dict = super()._prepare_for_class(inputs_dict, model_class, return_labels=return_labels)
 
-        # Ensure image_sizes matches the batch size of pixel_values or input_ids
-        if "pixel_values" in inputs_dict and "image_sizes" in inputs_dict:
+        # Ensure image_sizes is properly set when pixel_values is present
+        if "pixel_values" in inputs_dict:
             batch_size = inputs_dict["pixel_values"].shape[0]
-            # If image_sizes doesn't match batch size, adjust it
-            if len(inputs_dict["image_sizes"]) != batch_size:
+            # If image_sizes is missing or None, infer from pixel_values
+            if "image_sizes" not in inputs_dict or inputs_dict["image_sizes"] is None:
+                _, _, height, width = inputs_dict["pixel_values"].shape
+                inputs_dict["image_sizes"] = [(height, width)] * batch_size
+            elif len(inputs_dict["image_sizes"]) != batch_size:
                 # Take only the first batch_size entries
                 inputs_dict["image_sizes"] = inputs_dict["image_sizes"][:batch_size]
Repository: vuejs/vue
Pull request: feat: add warning when .native modifier is used on native HTML elements

**What kind of change does this PR introduce?** (check at least one)

- [ ] Bugfix
- [x] Feature
- [ ] Code style update
- [ ] Refactor
- [ ] Build-related changes
- [ ] Other, please describe:

**Does this PR introduce a breaking change?** (check one)

- [ ] Yes
- [x] No

If yes, please describe the impact and migration path for existing applications:

**The PR fulfills these requirements:**

- [x] It's submitted to the `dev` branch for v2.x (or to a previous version branch), _not_ the `master` branch
- [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number)
- [x] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
- [x] New/updated tests are included

If adding a **new feature**, the PR's description includes:
- [x] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

**Other information:**
Currently if we have a `.native` modifier applied to event handler on native HTML element, it will break the handler (you can find the minimal reproduction [here](https://codesandbox.io/s/m718j536yp)).

We had a discussion about it with @chrisvfritz and it was decided it would be a good solution to add a console warning for this case. This way we can warn people they are using `.native` incorrectly: it should be used only on components not on elements.

An ideal solution would be also making `.native` work on elements while throwing a warning but it might be a subject for another PR.

Changed files:
filename: src/core/vdom/create-element.js
patch: @@ -98,6 +98,12 @@ export function _createElement (
     ns = (context.$vnode && context.$vnode.ns) || config.getTagNamespace(tag)
     if (config.isReservedTag(tag)) {
       // platform built-in elements
+      if (process.env.NODE_ENV !== 'production' && isDef(data) && isDef(data.nativeOn)) {
+        warn(
+          `The .native modifier for v-on is only valid on components but it was used on <${tag}>.`,
+          context
+        )
+      }
       vnode = new VNode(
         config.parsePlatformTagName(tag), data, children,
         undefined, undefined, context

filename: test/unit/features/directives/on.spec.js
patch: @@ -460,6 +460,20 @@ describe('Directive v-on', () => {
     expect(spy).toHaveBeenCalled()
   })
 
+  it('should throw a warning if native modifier is used on native HTML element', () => {
+    vm = new Vue({
+      el,
+      template: `
+        <button @click.native="foo"></button>
+      `,
+      methods: { foo: spy },
+    })
+
+    triggerEvent(vm.$el, 'click')
+    expect(`The .native modifier for v-on is only valid on components but it was used on <button>.`).toHaveBeenWarned()
+    expect(spy.calls.count()).toBe(0)
+  })
+
   it('.once modifier should work with child components', () => {
     vm = new Vue({
       el,
Repository: ollama/ollama
Pull request: Fix nondeterministic model unload order

Fix nondeterministic model unload order in scheduler
Summary
This pull request fixes a bug where Ollama's model scheduler sometimes failed to unload models predictably, leading to inconsistent memory release and occasional request failures, especially on Linux.

Root Cause
The scheduler iterated over Go maps (which are unordered) when selecting a model to unload. When multiple models had the same session duration, the unload choice was nondeterministic, varying across runs and platforms. This caused inconsistent unload behavior and resource management issues.

Fix
The unload selection logic was updated to:

Sort runners primarily by session duration (as before).
Add a secondary sort key: model path (string).
This ensures a deterministic unload order even when durations are equal, eliminating nondeterminism caused by map iteration order.

Impact
Model unload behavior is now consistent and predictable across platforms.
Fixes occasional failures to release models or accept new requests.
Tested on Linux with NVIDIA GPU, confirmed models unload deterministically and GPU memory is released as expected.

Changed files:
filename: server/sched.go
patch: @@ -667,13 +667,19 @@ func (runner *runnerRef) waitForVRAMRecovery() chan any {
 	return finished
 }
 
-type ByDuration []*runnerRef
-
-func (a ByDuration) Len() int      { return len(a) }
-func (a ByDuration) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
-func (a ByDuration) Less(i, j int) bool {
-	// uint64 to turn negative time (never unload) to largest
-	return uint64(a[i].sessionDuration) < uint64(a[j].sessionDuration)
+type ByDurationAndName []*runnerRef
+
+func (a ByDurationAndName) Len() int      { return len(a) }
+func (a ByDurationAndName) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
+func (a ByDurationAndName) Less(i, j int) bool {
+	// Primary sort by session duration (uint64 to handle negatives)
+	d1 := uint64(a[i].sessionDuration)
+	d2 := uint64(a[j].sessionDuration)
+	if d1 != d2 {
+		return d1 < d2
+	}
+	// Secondary sort by model path lex order
+	return a[i].modelPath < a[j].modelPath
 }
 
 // TODO - future consideration to pick runners based on size
@@ -775,7 +781,7 @@ func (s *Scheduler) findRunnerToUnload() *runnerRef {
 
 	// In the future we can enhance the algorithm to be smarter about picking the optimal runner to unload
 	// e.g., if we have multiple options, will one make room for the request?
-	sort.Sort(ByDuration(runnerList))
+	sort.Sort(ByDurationAndName(runnerList))
 
 	// First try to find a runner that's already idle
 	for _, runner := range runnerList {
Repository: vuejs/vue
Pull request: Improving license clarity of simplehtmlparser.js


**What kind of change does this PR introduce?** (check at least one)

- [ ] Bugfix
- [ ] Feature
- [ ] Code style update
- [ ] Refactor
- [ ] Build-related changes
- [x] Other, please describe: License documentation

**Does this PR introduce a breaking change?** (check one)

- [ ] Yes
- [x] No

If yes, please describe the impact and migration path for existing applications:

**The PR fulfills these requirements:**

- [x ] It's submitted to the `dev` branch for v2.x (or to a previous version branch), _not_ the `master` branch
- [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number)
- [ ] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
- [ ] New/updated tests are included

If adding a **new feature**, the PR's description includes:
- [ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

**Other information:**

The licensing in src/compiler/parser/html-parser.js is described as "Mozilla Public License", which will cause flags of concern for some reviewers as it takes Vue from being an MIT licensed project to a project containing copyleft licensing. This is unnecessary as the original code appears to have an option of three licenses. I've updated the text to describe the three licenses using SPDX license expression format.

Changed files:
filename: src/compiler/parser/html-parser.js
patch: @@ -5,7 +5,7 @@
 /*!
  * HTML Parser By John Resig (ejohn.org)
  * Modified by Juriy "kangax" Zaytsev
- * Original code by Erik Arvidsson, Mozilla Public License
+ * Original code by Erik Arvidsson (MPL-1.1 OR Apache-2.0 OR GPL-2.0-or-later)
  * http://erik.eae.net/simplehtmlparser/simplehtmlparser.js
  */