helloadhavan/github_issues huggingface dataset:
Repository: ggml-org/llama.cpp
Pull request: vulkan: tune MMVQ for Intel Windows

Tune MMVQ use for Intel Windows according to https://github.com/ggml-org/llama.cpp/issues/17628#issuecomment-3897132360

@savvadesogle Please try it and see if performance is good.

Changed files:
filename: ggml/src/ggml-vulkan/ggml-vulkan.cpp
patch: @@ -7574,6 +7574,18 @@ static bool ggml_vk_should_use_mmvq(const vk_device& device, uint32_t m, uint32_
             return false;
         }
 
+        if (device->driver_id == vk::DriverId::eIntelProprietaryWindows) {
+            // Intel Windows proprietary driver tuning
+            switch (src0_type) {
+            case GGML_TYPE_MXFP4:
+            case GGML_TYPE_Q4_K:
+            case GGML_TYPE_Q5_K:
+                return false;
+            default:
+                return true;
+            }
+        }
+
         switch (src0_type) {
         // From tests on A770 Linux, may need more tuning
         case GGML_TYPE_Q4_0:
Repository: vercel/next.js
Pull request: Turbopack: use correct flags in tests

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the PR.
- Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to understand the PR)
- When linking to a Slack thread, you might want to share details of the conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->


Changed files:
filename: turbopack/crates/turbopack-tests/tests/execution.rs
patch: @@ -521,7 +521,7 @@ async fn run_test_operation(prepared_test: ResolvedVc<PreparedTest>) -> Result<V
     )
     .unused_references(
         options
-            .remove_unused_exports
+            .remove_unused_imports
             .then(|| binding_usage.unwrap()),
     );
     if options.production_chunking {

filename: turbopack/crates/turbopack-tests/tests/snapshot.rs
patch: @@ -480,7 +480,7 @@ async fn run_test_operation(resource: RcStr) -> Result<Vc<FileSystemPath>> {
             )
             .unused_references(
                 options
-                    .remove_unused_exports
+                    .remove_unused_imports
                     .then(|| binding_usage.unwrap()),
             )
             .debug_ids(options.enable_debug_ids)
@@ -521,7 +521,7 @@ async fn run_test_operation(resource: RcStr) -> Result<Vc<FileSystemPath>> {
             )
             .unused_references(
                 options
-                    .remove_unused_exports
+                    .remove_unused_imports
                     .then(|| binding_usage.unwrap()),
             )
             .debug_ids(options.enable_debug_ids)
Repository: facebook/react
Pull request: [react-native] Pull up enableFastAddPropertiesInDiffing check

## Summary

We don't need the isArray check for this experiment, as `fastAddProperties` already does the same. Also renaming slowAddProperties to make it clearer we can fully remove this codepath once fastAddProperties is fully rolled out.

## How did you test this change?

```
yarn test packages/react-native-renderer -r=xplat --variant=true
```


Changed files:
filename: packages/react-native-renderer/src/ReactNativeAttributePayloadFabric.js
patch: @@ -219,13 +219,13 @@ function addNestedProperty(
     return updatePayload;
   }
 
+  if (enableFastAddPropertiesInDiffing) {
+    return fastAddProperties(updatePayload, nextProp, validAttributes);
+  }
+
   if (!isArray(nextProp)) {
     // Add each property of the leaf.
-    if (enableFastAddPropertiesInDiffing) {
-      return fastAddProperties(updatePayload, nextProp, validAttributes);
-    } else {
-      return addProperties(updatePayload, nextProp, validAttributes);
-    }
+    return slowAddProperties(updatePayload, nextProp, validAttributes);
   }
 
   for (let i = 0; i < nextProp.length; i++) {
@@ -516,7 +516,7 @@ function fastAddProperties(
 /**
  * addProperties adds all the valid props to the payload after being processed.
  */
-function addProperties(
+function slowAddProperties(
   updatePayload: null | Object,
   props: Object,
   validAttributes: AttributeConfiguration,
Repository: vuejs/vue
Pull request: feat(warning): allow symbol as vdom key

fix #7157

**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

**Other information:**

Flow still doesn't support `typeof symbol`, a suppression comment is added. 
Also, all usage of `isPrimitive` is checked, additional `String` cast is added for compatibility.

Changed files:
filename: src/core/vdom/patch.js
patch: @@ -270,7 +270,7 @@ export function createPatchFunction (backend) {
         createElm(children[i], insertedVnodeQueue, vnode.elm, null, true)
       }
     } else if (isPrimitive(vnode.text)) {
-      nodeOps.appendChild(vnode.elm, nodeOps.createTextNode(vnode.text))
+      nodeOps.appendChild(vnode.elm, nodeOps.createTextNode(String(vnode.text)))
     }
   }
 

filename: src/shared/util.js
patch: @@ -27,6 +27,8 @@ export function isPrimitive (value: any): boolean %checks {
   return (
     typeof value === 'string' ||
     typeof value === 'number' ||
+    // $flow-disable-line
+    typeof value === 'symbol' ||
     typeof value === 'boolean'
   )
 }

filename: test/unit/modules/vdom/create-element.spec.js
patch: @@ -215,6 +215,15 @@ describe('create-element', () => {
     expect('Avoid using non-primitive value as key').not.toHaveBeenWarned()
   })
 
+  it('doesn\'t warn symbol key', () => {
+    new Vue({
+      render (h) {
+        return h('div', { key: Symbol('symbol') })
+      }
+    }).$mount()
+    expect('Avoid using non-primitive value as key').not.toHaveBeenWarned()
+  })
+
   it('nested child elements should be updated correctly', done => {
     const vm = new Vue({
       data: { n: 1 },
Repository: huggingface/transformers
Pull request: [Quantization] Removing misleading int8 quantization in Finegrained FP8

# What does this PR do?

instead of falling to int8 quantization, which we don't do for now since we validate that the environment has a `8.9` compute capability at least, we just ask the user to use an other quantization method

Changed files:
filename: src/transformers/integrations/finegrained_fp8.py
patch: @@ -34,14 +34,10 @@
     _FP8_DTYPE = torch.float8_e4m3fn
     _FP8_MIN = torch.finfo(_FP8_DTYPE).min
     _FP8_MAX = torch.finfo(_FP8_DTYPE).max
-    _FP8_IS_INT = False
 except AttributeError:
-    _FP8_DTYPE = torch.int8
-    _FP8_MIN, _FP8_MAX = -127, 127
-    _FP8_IS_INT = True
-    logger.warning_once(
-        "torch.float8_e4m3fn not available; falling back to int8 emulation for Fp8Quantize operations."
-    )
+    _FP8_DTYPE = None
+    _FP8_MIN, _FP8_MAX = -448, 448
+    logger.warning_once("torch.float8_e4m3fn not available")
 
 
 # Copied from https://huggingface.co/deepseek-ai/DeepSeek-V3/blob/main/inference/kernel.py
@@ -701,10 +697,7 @@ def convert(self, input_dict: torch.Tensor, **kwargs) -> dict[str, torch.Tensor]
         scales_broadcast = scales.unsqueeze(-1).unsqueeze(-3)  # -> (..., rows_tiles, 1, cols_tiles, 1)
         scaled = reshaped * scales_broadcast
 
-        if _FP8_IS_INT:
-            quantized = torch.clamp(scaled.round(), min=_FP8_MIN, max=_FP8_MAX).to(_FP8_DTYPE)
-        else:
-            quantized = torch.clamp(scaled, min=_FP8_MIN, max=_FP8_MAX).to(_FP8_DTYPE)
+        quantized = torch.clamp(scaled, min=_FP8_MIN, max=_FP8_MAX).to(_FP8_DTYPE)
 
         quantized = quantized.reshape(original_shape)
 

filename: src/transformers/quantizers/quantizer_finegrained_fp8.py
patch: @@ -48,7 +48,8 @@ def validate_environment(self, *args, **kwargs):
             if (major < 8) or (major == 8 and minor < 9):
                 logger.warning_once(
                     "FP8 quantized models is only supported on GPUs with compute capability >= 8.9 (e.g 4090/H100)"
-                    f", actual = `{major}.{minor}`. We will default to dequantizing the model to bf16 "
+                    f", actual = `{major}.{minor}`. We will default to dequantizing the model to bf16. Feel free "
+                    f"to use a different quantization method like bitsandbytes or torchao"
                 )
                 self.quantization_config.dequantize = True
                 return
Repository: facebook/react
Pull request: [Fizz] Reset Instructions on ResumableState

When we end up creating an incomplete state in the shell we end up not flushing anything. As a hack, in this case we need to reset the ResumableState because some of the ResumableState is still relevant (e.g. any preloads that went into headers) but some of the ResumableState needs to be reset since they assume that what we produced actually flushed.

We didn't reset the instructions state but we haven't actually flushed any of the instructions so it needs to reset.

Changed files:
filename: packages/react-dom-bindings/src/server/ReactFizzConfigDOM.js
patch: @@ -695,6 +695,7 @@ export function resetResumableState(
   resumableState.scriptResources = {};
   resumableState.moduleUnknownResources = {};
   resumableState.moduleScriptResources = {};
+  resumableState.instructions = NothingSent; // Nothing was flushed so no instructions could've flushed.
 }
 
 export function completeResumableState(resumableState: ResumableState): void {
Repository: vercel/next.js
Pull request: Turbopack: fix task category on reading cells

### What?

fix the task category

Changed files:
filename: turbopack/crates/turbo-tasks-backend/src/backend/mod.rs
patch: @@ -835,10 +835,10 @@ impl<B: BackingStorage> TurboTasksBackendInner<B> {
             // Having a task_pair here is not optimal, but otherwise this would lead to a race
             // condition. See below.
             // TODO(sokra): solve that in a more performant way.
-            let (task, reader) = ctx.task_pair(task_id, reader_id, TaskDataCategory::Data);
+            let (task, reader) = ctx.task_pair(task_id, reader_id, TaskDataCategory::All);
             (task, Some(reader))
         } else {
-            (ctx.task(task_id, TaskDataCategory::Data), None)
+            (ctx.task(task_id, TaskDataCategory::All), None)
         };
 
         let content = if final_read_hint {
Repository: huggingface/transformers
Pull request: Fp8 dq

# What does this PR do?

This PR extend the dq when users don't have compute capability >= 8.9 for fp8. 

Changed files:
filename: src/transformers/quantizers/quantizer_finegrained_fp8.py
patch: @@ -33,7 +33,7 @@ def validate_environment(self, *args, **kwargs):
             return
 
         if not torch.cuda.is_available() and not is_torch_xpu_available():
-            if self.pre_quantized and not self.quantization_config.dequantize:
+            if self.pre_quantized:
                 logger.warning_once(
                     "Using FP8 quantized models requires a GPU or XPU, we will default to dequantizing the model to bf16 since no GPU or XPU is available"
                 )
@@ -46,10 +46,12 @@ def validate_environment(self, *args, **kwargs):
             compute_capability = torch.cuda.get_device_capability()
             major, minor = compute_capability
             if (major < 8) or (major == 8 and minor < 9):
-                raise ValueError(
+                logger.warning_once(
                     "FP8 quantized models is only supported on GPUs with compute capability >= 8.9 (e.g 4090/H100)"
-                    f", actual = `{major}.{minor}`"
+                    f", actual = `{major}.{minor}`. We will default to dequantizing the model to bf16 "
                 )
+                self.quantization_config.dequantize = True
+                return
 
         device_map = kwargs.get("device_map")
         if device_map is None:
Repository: vuejs/vue
Pull request: tweak: return is better when inject has no value

<!--
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
- [ ] Feature
- [ ] Code style update
- [ ] Refactor
- [ ] Build-related changes
- [x] Other, please describe: Avoid unnecessary judgment conditions

**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:**


Changed files:
filename: src/core/util/options.js
patch: @@ -334,6 +334,7 @@ function validatePropObject (
  */
 function normalizeInject (options: Object, vm: ?Component) {
   const inject = options.inject
+  if (!inject) return
   const normalized = options.inject = {}
   if (Array.isArray(inject)) {
     for (let i = 0; i < inject.length; i++) {
@@ -346,7 +347,7 @@ function normalizeInject (options: Object, vm: ?Component) {
         ? extend({ from: key }, val)
         : { from: val }
     }
-  } else if (process.env.NODE_ENV !== 'production' && inject) {
+  } else if (process.env.NODE_ENV !== 'production') {
     warn(
       `Invalid value for option "inject": expected an Array or an Object, ` +
       `but got ${toRawType(inject)}.`,
Repository: ollama/ollama
Pull request: merge llama/ggml into ml/backend/ggml

Branched from #7954 and #7875

Changed files:
filename: ml/backend/ggml/ggml/src/ggml.go
patch: @@ -5,6 +5,7 @@ package ggml
 // #cgo CPPFLAGS: -I${SRCDIR}/../include -I${SRCDIR}/ggml-cpu
 // #include <stdlib.h>
 // #include "ggml-backend.h"
+// extern void sink(int level, char *text, void *user_data);
 import "C"
 import (
 	"log/slog"
@@ -18,6 +19,13 @@ import (
 	_ "github.com/ollama/ollama/ml/backend/ggml/ggml/src/ggml-cpu"
 )
 
+func init() {
+	C.ggml_log_set((C.ggml_log_callback)(C.sink), nil)
+}
+
+//export sink
+func sink(level C.int, text *C.char, _ unsafe.Pointer) {}
+
 var OnceLoad = sync.OnceFunc(func() {
 	var lib struct{ name, pattern, defaultValue string }
 	switch runtime.GOOS {
Repository: vercel/next.js
Pull request: agent.md: Explain where the Next.js core code lives

## What?

Explain in agent.md where the Next.js core code lives.

Changed files:
filename: AGENTS.md
patch: @@ -1,5 +1,44 @@
 # Next.js Development Guide
 
+## Codebase structure
+
+### Monorepo Overview
+
+This is a pnpm monorepo containing the Next.js framework and related packages.
+
+```
+next.js/
+├── packages/           # Published npm packages
+├── turbopack/          # Turbopack bundler (Rust) - git subtree
+├── crates/             # Rust crates for Next.js SWC bindings
+├── test/               # All test suites
+├── examples/           # Example Next.js applications
+├── docs/               # Documentation
+└── scripts/            # Build and maintenance scripts
+```
+
+### Core Package: `packages/next`
+
+The main Next.js framework lives in `packages/next/`. This is what gets published as the `next` npm package.
+
+**Source code** is in `packages/next/src/`.
+
+**Key entry points:**
+
+- Dev server: `src/cli/next-dev.ts` → `src/server/dev/next-dev-server.ts`
+- Production server: `src/cli/next-start.ts` → `src/server/next-server.ts`
+- Build: `src/cli/next-build.ts` → `src/build/index.ts`
+
+**Compiled output** goes to `packages/next/dist/` (mirrors src/ structure).
+
+### Other Important Packages
+
+- `packages/create-next-app/` - The `create-next-app` CLI tool
+- `packages/next-swc/` - Native Rust bindings (SWC transforms)
+- `packages/eslint-plugin-next/` - ESLint rules for Next.js
+- `packages/font/` - `next/font` implementation
+- `packages/third-parties/` - Third-party script integrations
+
 ## Git Workflow
 
 **Use Graphite for all git operations** instead of raw git commands:
@@ -221,19 +260,18 @@ pnpm test-dev-turbo test/path/to/test.ts
 pnpm test-start-turbo test/path/to/test.ts
 ```
 
-## Key Directories
+## Key Directories (Quick Reference)
+
+See [Codebase structure](#codebase-structure) above for detailed explanations.
 
 - `packages/next/src/` - Main Next.js source code
-  - `server/` - Server runtime (dev server, router, rendering)
-  - `client/` - Client-side code
-  - `build/` - Build tooling (webpack, turbopack configs)
-  - `cli/` - CLI entry points
-- `packages/next/dist/` - Compiled output
-- `turbopack/` - Turbopack bundler (Rust)
-- `test/` - Test suites
-  - `development/` - Dev server tests
-  - `production/` - Production build tests
-  - `e2e/` - End-to-end tests
+- `packages/next/src/server/` - Server runtime (most changes happen here)
+- `packages/next/src/client/` - Client-side runtime
+- `packages/next/src/build/` - Build tooling
+- `test/e2e/` - End-to-end tests
+- `test/development/` - Dev server tests
+- `test/production/` - Production build tests
+- `test/unit/` - Unit tests (fast, no browser)
 
 ## Development Tips
Repository: ollama/ollama
Pull request: better client error for /api/create

This change shows a mode descriptive error in the client w/ the `POST /api/create` endpoint if the client has been refreshed but the server hasn't been updated.

Changed files:
filename: cmd/cmd.go
patch: @@ -162,6 +162,9 @@ func CreateHandler(cmd *cobra.Command, args []string) error {
 	}
 
 	if err := client.Create(cmd.Context(), req, fn); err != nil {
+		if strings.Contains(err.Error(), "path or Modelfile are required") {
+			return fmt.Errorf("the ollama server must be updated to use `ollama create` with this client")
+		}
 		return err
 	}
 

filename: server/create.go
patch: @@ -33,6 +33,7 @@ var (
 	errOnlyOneAdapterSupported = errors.New("only one adapter is currently supported")
 	errOnlyGGUFSupported       = errors.New("supplied file was not in GGUF format")
 	errUnknownType             = errors.New("unknown type")
+	errNeitherFromOrFiles      = errors.New("neither 'from' or 'files' was specified")
 )
 
 func (s *Server) CreateHandler(c *gin.Context) {
@@ -95,7 +96,7 @@ func (s *Server) CreateHandler(c *gin.Context) {
 				return
 			}
 		} else {
-			ch <- gin.H{"error": "neither 'from' or 'files' was specified", "status": http.StatusBadRequest}
+			ch <- gin.H{"error": errNeitherFromOrFiles.Error(), "status": http.StatusBadRequest}
 			return
 		}
Repository: vuejs/vue
Pull request: fix(compiler): fix double escaping of ssrNode attribute values (fix #7223)

This fixes a double escaping of attribute values in the SSR optimizing
compiler, because literal attribute values get escaped early during the
call to `addAttr` inside `processAttrs` before it is known, if this
attribute will be serialized to an _ssrNode string template.

Later on the _ssrNode string template gets escaped again to preserve
whitespace and this causes double escaping of the whitespace inside the
attribute value.

This approach fixes the problem by undoing the escaping by parsing the
attribute value JSON in `genAttrSegment`, which is the easiest fix to
the problem, but probably not the best.

This fixes #7223 at least for the cases where I encountered the problem.

See #7223 for an in-depth description of the problem and a test-case.

<!--
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:**

I would love to add a breaking test, that shows that the fix is working, but I'm not sure were to add it with the large test suite, so some advise on that would be appreciated.

Changed files:
filename: src/server/optimizing-compiler/modules.js
patch: @@ -77,7 +77,7 @@ function genAttrSegment (name: string, value: string): StringSegment {
         ? ` ${name}="${name}"`
         : value === '""'
           ? ` ${name}`
-          : ` ${name}=${value}`
+          : ` ${name}="${JSON.parse(value)}"`
     }
   } else {
     return {