helloadhavan/github_issues huggingface dataset:
Repository: vuejs/vue
Pull request: fix(compiler): normalize nested arrays in v-for(fix #8468)

Normalize nested arrays when using functional components with v-for.

<!--
Please make sure to read the Pull Request Guidelines:
https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#pull-request-guidelines
-->

<!-- PULL REQUEST TEMPLATE -->
<!-- (Update "[ ]" to "[x]" to check a box) -->

**What kind of change does this PR introduce?** (check at least one)

- [x] Bugfix
- [ ] 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
- [x] 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:
- [ ] 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:**


Changed files:
filename: src/compiler/codegen/index.js
patch: @@ -406,7 +406,10 @@ export function genChildren (
       el.tag !== 'template' &&
       el.tag !== 'slot'
     ) {
-      return (altGenElement || genElement)(el, state)
+      // because el may be a functional component and return an Array instead of a single root.
+      // In this case, just a simple normalization is needed
+      const normalizationType = state.maybeComponent(el) ? `,1` : ``
+      return `${(altGenElement || genElement)(el, state)}${normalizationType}`
     }
     const normalizationType = checkSkip
       ? getNormalizationType(children, state.maybeComponent)

filename: test/unit/features/options/functional.spec.js
patch: @@ -316,4 +316,25 @@ describe('Options functional', () => {
     triggerEvent(parent.$el.querySelector('.clickable'), 'click')
     waitForUpdate(assertMarkup).then(done)
   })
+
+  // #8468
+  it('should normalize nested arrays when use functional components with v-for', () => {
+    const Foo = {
+      functional: true,
+      props: {
+        name: {}
+      },
+      render (h, context) {
+        return [h('span', 'hi'), h('span', context.props.name)]
+      }
+    }
+    const vm = new Vue({
+      template: `<div><foo v-for="name in names" :name="name" /></div>`,
+      data: {
+        names: ['foo', 'bar']
+      },
+      components: { Foo }
+    }).$mount()
+    expect(vm.$el.innerHTML).toBe('<span>hi</span><span>foo</span><span>hi</span><span>bar</span>')
+  })
 })
Repository: nodejs/node
Pull request: doc: add missing `passed`  and `error` properties on `TestContext`

`passed` and `error` properties were left undocumented on `TextContext` class

Fixes: https://github.com/nodejs/node/issues/59321
Refs: https://github.com/nodejs/node/pull/51485 <-- passed and error implem
Refs: https://github.com/nodejs/node/pull/59322 <-- Initial PR

PR was already made by someone else but closed prematurely even if valid, see second ref.
I removed this part, which seems wrong because I tested it and even `Error` instances end up wrapped:
> The failure reason for the test/case; if anything other than an instance of `Error` was thrown, that will be wrapped

Changed files:
filename: doc/api/test.md
patch: @@ -3686,6 +3686,40 @@ added:
 
 The name of the test.
 
+### `context.passed`
+
+<!-- YAML
+added:
+  - v21.7.0
+  - v20.12.0
+-->
+
+* Type: {boolean} `false` before the test is executed, e.g. in a `beforeEach` hook.
+
+Indicated whether the test succeeded.
+
+### `context.error`
+
+<!-- YAML
+added:
+  - v21.7.0
+  - v20.12.0
+-->
+
+* Type: {Error|null}
+
+The failure reason for the test/case; wrapped and available via `context.error.cause`.
+
+### `context.attempt`
+
+<!-- YAML
+added: v25.0.0
+-->
+
+* Type: {number}
+
+Number of times the test has been attempted.
+
 ### `context.plan(count[,options])`
 
 <!-- YAML
Repository: vercel/next.js
Pull request: doc: add details of mcp client integration

add link to the mcp client configuration details section before the code block of example

Changed files:
filename: docs/01-app/02-guides/upgrading/version-16.mdx
patch: @@ -14,9 +14,11 @@ If you're using an AI coding assistant that supports the [Model Context Protocol
 
 #### Setup
 
-Add the following configuration to your MCP client, example:
+Add the following configuration to your MCP client, for each coding agent you can read [this section](https://github.com/vercel/next-devtools-mcp#mcp-client-configuration) for configuration details.
 
-```json
+**example:**
+
+```json filename=".mcp.json"
 {
   "mcpServers": {
     "next-devtools": {
@@ -27,7 +29,7 @@ Add the following configuration to your MCP client, example:
 }
 ```
 
-For more information, visit the [`next-devtools-mcp`](https://www.npmjs.com/package/next-devtools-mcp) package on npm to configure with your MCP client.
+For more information, visit the [`next-devtools-mcp`](https://github.com/vercel/next-devtools-mcp) documentation to configure with your MCP client.
 
 > **Note:** Using `next-devtools-mcp@latest` ensures that your MCP client will always use the latest version of the Next.js DevTools MCP server.
Repository: huggingface/transformers
Pull request: Fix failing `BitModelIntegrationTest`

# What does this PR do?

Fixes this failing [BitModelIntegrationTest](https://github.com/huggingface/transformers/actions/runs/20706072009/job/59437072391#step:14:844).

<img width="1351" height="151" alt="image" src="https://github.com/user-attachments/assets/c5bf6193-620f-4200-9e3a-86f550aa418d" />




## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?
@vasqu

Changed files:
filename: tests/models/bit/test_modeling_bit.py
patch: @@ -277,7 +277,7 @@ def test_inference_image_classification_head(self):
 
         expected_slice = torch.tensor([[-0.6526, -0.5263, -1.4398]]).to(torch_device)
 
-        torch.testing.assert_close(outputs.logits[0, :3], expected_slice, rtol=1e-4, atol=1e-4)
+        torch.testing.assert_close(outputs.logits[:, :3], expected_slice, rtol=1e-3, atol=1e-3)
 
 
 @require_torch
Repository: vuejs/vue
Pull request: update toMs function. fix #4894

Old versions of [Chromium](https://www.chromium.org/) (below 61.0.3163.100) [formats floating pointer numbers in a locale-dependent way, using a comma instead of a dot](https://bugs.chromium.org/p/chromium/issues/detail?id=720222).
This PR makes toMs function parse it correctly, preventing unexpected behaviors.

<!--
Please make sure to read the Pull Request Guidelines:
https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#pull-request-guidelines
-->

<!-- PULL REQUEST TEMPLATE -->
<!-- (Update "[ ]" to "[x]" to check a box) -->

**What kind of change does this PR introduce?** (check at least one)

- [x] Bugfix
- [ ] 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
- [x] 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
- [ ] 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:**


Changed files:
filename: src/platforms/web/runtime/transition-util.js
patch: @@ -181,6 +181,10 @@ function getTimeout (delays: Array<string>, durations: Array<string>): number {
   }))
 }
 
+// Old versions of Chromium (below 61.0.3163.100) formats floating pointer numbers
+// in a locale-dependent way, using a comma instead of a dot.
+// If comma is not replaced with a dot, the input will be rounded down (i.e. acting
+// as a floor function) causing unexpected behaviors
 function toMs (s: string): number {
-  return Number(s.slice(0, -1)) * 1000
+  return Number(s.slice(0, -1).replace(',', '.')) * 1000
 }
Repository: vercel/next.js
Pull request: Turbopack: unflake unit test

### What?

Too few tasks leave no space for tokio to act.

Changed files:
filename: turbopack/crates/turbo-tasks/src/priority_runner.rs
patch: @@ -565,7 +565,7 @@ mod tests {
                 let execute_context = execute_context.clone();
                 println!("Created task {}", task);
                 Box::pin(async move {
-                    let cpu_bound = task < 10;
+                    let cpu_bound = task < 50;
                     if cpu_bound {
                         println!("Executing cpu-bound task {}...", task);
                         // CPU bound task
@@ -591,13 +591,13 @@ mod tests {
             Arc::new(PriorityRunner::new(executor));
         let results = Arc::new(Mutex::new(Vec::new()));
 
-        for i in 0..20 {
+        for i in 0..100 {
             let results = results.clone();
             println!("Scheduling task {}...", i);
             runner.schedule(&results, i, i);
         }
 
-        while results.lock().len() < 20 {
+        while results.lock().len() < 100 {
             tokio::time::sleep(Duration::from_millis(10)).await;
         }
         let results = results.lock();
@@ -610,22 +610,22 @@ mod tests {
         // And the two highest priority cpu-bound tasks are executed too.
         // Since we only have 2 workers, the waiting tasks ain't polled until the cpu-bound tasks
         // are done.
-        assert!(results[2..4].contains(&9));
-        assert!(results[2..4].contains(&8));
+        assert!(results[2..4].contains(&49));
+        assert!(results[2..4].contains(&48));
         let waiting_task_pos = results
             .iter()
-            .position(|&x| x >= 10)
+            .position(|&x| x >= 50)
             .expect("Waiting task should be executed");
         // Waiting tasks should be interleaved with cpu-bound tasks
-        assert!(waiting_task_pos < 8);
+        assert!(waiting_task_pos < 45);
 
         let cpu_bound_results = results
             .iter()
             .copied()
-            .filter(|&x| x < 10)
+            .filter(|&x| x < 50)
             .collect::<Vec<_>>();
         // The last tasks are the tasks with the lowest priority
-        assert!(cpu_bound_results[8..10].contains(&2));
-        assert!(cpu_bound_results[8..10].contains(&3));
+        assert!(cpu_bound_results[48..50].contains(&2));
+        assert!(cpu_bound_results[48..50].contains(&3));
     }
 }
Repository: ollama/ollama
Pull request: Move cgroup fix out of AMD section.

This also works for Nvidia (https://github.com/ollama/ollama/issues/8594) so move it out of the AMD section.

Changed files:
filename: docs/troubleshooting.md
patch: @@ -73,6 +73,10 @@ curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.5.7 sh
 
 If your system is configured with the "noexec" flag where Ollama stores its temporary executable files, you can specify an alternate location by setting OLLAMA_TMPDIR to a location writable by the user ollama runs as. For example OLLAMA_TMPDIR=/usr/share/ollama/
 
+## Linux docker
+
+If Ollama initially works on the GPU in a docker container, but then switches to running on CPU after some period of time with errors in the server log reporting GPU discovery failures, this can be resolved by disabling systemd cgroup management in Docker.  Edit `/etc/docker/daemon.json` on the host and add `"exec-opts": ["native.cgroupdriver=cgroupfs"]` to the docker configuration.
+
 ## NVIDIA GPU Discovery
 
 When Ollama starts up, it takes inventory of the GPUs present in the system to determine compatibility and how much VRAM is available.  Sometimes this discovery can fail to find your GPUs.  In general, running the latest driver will yield the best results.
@@ -100,8 +104,6 @@ On linux, AMD GPU access typically requires `video` and/or `render` group member
 
 When running in a container, in some Linux distributions and container runtimes, the ollama process may be unable to access the GPU.  Use `ls -lnd /dev/kfd /dev/dri /dev/dri/*` on the host system to determine the **numeric** group IDs on your system, and pass additional `--group-add ...` arguments to the container so it can access the required devices.   For example, in the following output `crw-rw---- 1 0  44 226,   0 Sep 16 16:55 /dev/dri/card0` the group ID column is `44` 
 
-If Ollama initially works on the GPU in a docker container, but then switches to running on CPU after some period of time with errors in the server log reporting GPU discovery failures, this can be resolved by disabling systemd cgroup management in Docker.  Edit `/etc/docker/daemon.json` on the host and add `"exec-opts": ["native.cgroupdriver=cgroupfs"]` to the docker configuration.
-
 If you are experiencing problems getting Ollama to correctly discover or use your GPU for inference, the following may help isolate the failure.
 - `AMD_LOG_LEVEL=3` Enable info log levels in the AMD HIP/ROCm libraries.  This can help show more detailed error codes that can help troubleshoot problems
 - `OLLAMA_DEBUG=1` During GPU discovery additional information will be reported
Repository: vercel/next.js
Pull request: Turbopack: Consistency for compute_async_module_info

### What?

Use strongly consistent reads for compute_async_module_info to avoid double execution.

Changed files:
filename: turbopack/crates/turbopack-core/src/module_graph/async_module_info.rs
patch: @@ -1,6 +1,6 @@
-use anyhow::Result;
+use anyhow::{Context, Result};
 use rustc_hash::FxHashSet;
-use turbo_tasks::{ResolvedVc, TryFlatJoinIterExt, Vc};
+use turbo_tasks::{OperationVc, ResolvedVc, TryFlatJoinIterExt, Vc};
 
 use crate::{
     module::{Module, Modules},
@@ -40,20 +40,26 @@ pub async fn compute_async_module_info(
     graphs: ResolvedVc<ModuleGraph>,
 ) -> Result<Vc<AsyncModulesInfo>> {
     // Layout segment optimization, we can individually compute the async modules for each graph.
-    let mut result: Vc<AsyncModulesInfo> = Vc::cell(Default::default());
+    let mut result = None;
     for graph in graphs.iter_graphs().await? {
-        result = compute_async_module_info_single(graph.connect(), result);
+        result = Some(compute_async_module_info_single(*graph, result));
     }
-    Ok(result)
+    Ok(result
+        .context("There must be at least one single graph in the module graph")?
+        .connect())
 }
 
-#[turbo_tasks::function]
+#[turbo_tasks::function(operation)]
 async fn compute_async_module_info_single(
-    graph: ResolvedVc<ModuleGraphLayer>,
-    parent_async_modules: Vc<AsyncModulesInfo>,
+    graph: OperationVc<ModuleGraphLayer>,
+    parent_async_modules: Option<OperationVc<AsyncModulesInfo>>,
 ) -> Result<Vc<AsyncModulesInfo>> {
-    let parent_async_modules = parent_async_modules.await?;
-    let graph = graph.await?;
+    let parent_async_modules = if let Some(parent_async_modules) = parent_async_modules {
+        Some(parent_async_modules.read_strongly_consistent().await?)
+    } else {
+        None
+    };
+    let graph = graph.read_strongly_consistent().await?;
     let self_async_modules = graph
         .enumerate_nodes()
         .map(async |(_, node)| {
@@ -64,7 +70,10 @@ async fn compute_async_module_info_single(
                 super::SingleModuleGraphNode::VisitedModule { idx: _, module } => {
                     // If a module is async in the parent then we need to mark reverse dependencies
                     // async in this graph as well.
-                    parent_async_modules.contains(module).then_some(*module)
+                    parent_async_modules
+                        .as_ref()
+                        .is_some_and(|set| set.contains(module))
+                        .then_some(*module)
                 }
             })
         })
@@ -101,7 +110,7 @@ async fn compute_async_module_info_single(
     )?;
 
     // Accumulate the parent modules at the end. Not all parent async modules were in this graph
-    async_modules.extend(parent_async_modules);
+    async_modules.extend(parent_async_modules.into_iter().flatten());
 
     Ok(Vc::cell(async_modules))
 }
Repository: nodejs/node
Pull request: tools: update nixpkgs-unstable to 3edc4a30ed3903fdf6f90c837f961fa6b49

This is an automated update of nixpkgs-unstable to 3edc4a30ed3903fdf6f90c837f961fa6b49.

Changed files:
filename: tools/nix/pkgs.nix
patch: @@ -1,10 +1,10 @@
 arg:
 let
   repo = "https://github.com/NixOS/nixpkgs";
-  rev = "7d853e518814cca2a657b72eeba67ae20ebf7059";
+  rev = "3edc4a30ed3903fdf6f90c837f961fa6b49582d1";
   nixpkgs = import (builtins.fetchTarball {
     url = "${repo}/archive/${rev}.tar.gz";
-    sha256 = "0hsqizh6kqp27gywdl33rpjclz8lls8s757qwa5qkbjb9an0dxlp";
+    sha256 = "0ajsdd3m4qz8mpimfcrawx81cqj8s5ypnkrxpwy7icj9j8gcpksa";
   }) arg;
 in
 nixpkgs
Repository: vuejs/vue
Pull request: fix: support for the use of modifiers such as click.right.once

<!--
Please make sure to read the Pull Request Guidelines:
https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#pull-request-guidelines
-->

<!-- PULL REQUEST TEMPLATE -->
<!-- (Update "[ ]" to "[x]" to check a box) -->

**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:**

- [ ] 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:**
Here is an example: https://codesandbox.io/s/m5j9wk0l4p
Using both the `right` modifier and the `once` modifier in a click event will invalidate the `contextmenu` event. 

Changed files:
filename: src/compiler/helpers.js
patch: @@ -65,6 +65,18 @@ export function addHandler (
     )
   }
 
+  // normalize click.right and click.middle since they don't actually fire
+  // this is technically browser-specific, but at least for now browsers are
+  // the only target envs that have right/middle clicks.
+  if (name === 'click') {
+    if (modifiers.right) {
+      name = 'contextmenu'
+      delete modifiers.right
+    } else if (modifiers.middle) {
+      name = 'mouseup'
+    }
+  }
+
   // check capture modifier
   if (modifiers.capture) {
     delete modifiers.capture
@@ -80,18 +92,6 @@ export function addHandler (
     name = '&' + name // mark the event as passive
   }
 
-  // normalize click.right and click.middle since they don't actually fire
-  // this is technically browser-specific, but at least for now browsers are
-  // the only target envs that have right/middle clicks.
-  if (name === 'click') {
-    if (modifiers.right) {
-      name = 'contextmenu'
-      delete modifiers.right
-    } else if (modifiers.middle) {
-      name = 'mouseup'
-    }
-  }
-
   let events
   if (modifiers.native) {
     delete modifiers.native
Repository: ollama/ollama
Pull request: config: allow setting context length through env var

From offline discussions:

- Current API parameters improperly mix system and request level configurations
- For now, let users set a context length through `OLLAMA_CONTEXT_LENGTH`
- Users can still set `num_ctx` through the CLI or SDK on a request level but is expected to be moved away from in the future

closes: #6504, #8794, #5356, #5357

Changed files:
filename: api/types.go
patch: @@ -10,6 +10,8 @@ import (
 	"strconv"
 	"strings"
 	"time"
+
+	"github.com/ollama/ollama/envconfig"
 )
 
 // StatusError is an error with an HTTP status code and message.
@@ -609,7 +611,7 @@ func DefaultOptions() Options {
 
 		Runner: Runner{
 			// options set when the model is loaded
-			NumCtx:    2048,
+			NumCtx:    int(envconfig.ContextLength()),
 			NumBatch:  512,
 			NumGPU:    -1, // -1 here indicates that NumGPU should be set dynamically
 			NumThread: 0,  // let the runtime decide

filename: envconfig/config.go
patch: @@ -167,6 +167,8 @@ var (
 	MultiUserCache = Bool("OLLAMA_MULTIUSER_CACHE")
 	// Enable the new Ollama engine
 	NewEngine = Bool("OLLAMA_NEW_ENGINE")
+	// ContextLength sets the default context length
+	ContextLength = Uint("OLLAMA_CONTEXT_LENGTH", 2048)
 )
 
 func String(s string) func() string {
@@ -252,6 +254,7 @@ func AsMap() map[string]EnvVar {
 		"OLLAMA_ORIGINS":           {"OLLAMA_ORIGINS", AllowedOrigins(), "A comma separated list of allowed origins"},
 		"OLLAMA_SCHED_SPREAD":      {"OLLAMA_SCHED_SPREAD", SchedSpread(), "Always schedule model across all GPUs"},
 		"OLLAMA_MULTIUSER_CACHE":   {"OLLAMA_MULTIUSER_CACHE", MultiUserCache(), "Optimize prompt caching for multi-user scenarios"},
+		"OLLAMA_CONTEXT_LENGTH":    {"OLLAMA_CONTEXT_LENGTH", ContextLength(), "Context length to use unless otherwise specified (default: 2048)"},
 		"OLLAMA_NEW_ENGINE":        {"OLLAMA_NEW_ENGINE", NewEngine(), "Enable the new Ollama engine"},
 
 		// Informational

filename: envconfig/config_test.go
patch: @@ -272,3 +272,19 @@ func TestVar(t *testing.T) {
 		})
 	}
 }
+
+func TestContextLength(t *testing.T) {
+	cases := map[string]uint{
+		"":     2048,
+		"4096": 4096,
+	}
+
+	for k, v := range cases {
+		t.Run(k, func(t *testing.T) {
+			t.Setenv("OLLAMA_CONTEXT_LENGTH", k)
+			if i := ContextLength(); i != v {
+				t.Errorf("%s: expected %d, got %d", k, v, i)
+			}
+		})
+	}
+}

filename: llm/memory_test.go
patch: @@ -17,6 +17,7 @@ import (
 func TestEstimateGPULayers(t *testing.T) {
 	t.Setenv("OLLAMA_DEBUG", "1")
 	t.Setenv("OLLAMA_KV_CACHE_TYPE", "") // Ensure default f16
+	t.Setenv("OLLAMA_CONTEXT_LENGTH", "2048")
 
 	modelName := "dummy"
 	f, err := os.CreateTemp(t.TempDir(), modelName)