helloadhavan/github_issues huggingface dataset:
Repository: facebook/react
Pull request: Format `ReactNativeAttributePayloadFabric.js` with Prettier

The prettier check for this file is currently failing on `main`, after #32119 was merged.

Changed files:
filename: packages/react-native-renderer/src/ReactNativeAttributePayloadFabric.js
patch: @@ -255,7 +255,9 @@ function diffProperties(
     nextProp = nextProps[propKey];
 
     if (typeof nextProp === 'function') {
-      const attributeConfigHasProcess = typeof attributeConfig === 'object' && typeof attributeConfig.process === 'function';
+      const attributeConfigHasProcess =
+        typeof attributeConfig === 'object' &&
+        typeof attributeConfig.process === 'function';
       if (!attributeConfigHasProcess) {
         // functions are converted to booleans as markers that the associated
         // events should be sent from native.
Repository: ollama/ollama
Pull request: Win: doc new rocm zip file

To stay under the 2G github artifact limit, we're splitting ROCm out like we do on linux.

Doc follow up from  #9350 

Changed files:
filename: docs/windows.md
patch: @@ -81,9 +81,11 @@ help you keep up to date.
 
 If you'd like to install or integrate Ollama as a service, a standalone
 `ollama-windows-amd64.zip` zip file is available containing only the Ollama CLI
-and GPU library dependencies for Nvidia and AMD. This allows for embedding
-Ollama in existing applications, or running it as a system service via `ollama
-serve` with tools such as [NSSM](https://nssm.cc/).
+and GPU library dependencies for Nvidia.  If you have an AMD GPU, also download
+and extract the additional ROCm package `ollama-windows-amd64-rocm.zip` into the
+same directory.  This allows for embedding Ollama in existing applications, or
+running it as a system service via `ollama serve` with tools such as
+[NSSM](https://nssm.cc/). 
 
 > [!NOTE]  
 > If you are upgrading from a prior version, you should remove the old directories first.
Repository: vercel/next.js
Pull request: [ci] Ensure Turbo Remote Cache can be written to

Follow-up to https://github.com/vercel/next.js/pull/88746

The token in `TURBO_TOKEN` has no write permissions. Unclear why Turbo logged "Remote caching enabled" if all the roles in Vercel either have read/write or no permissions.

I added a new token under the `vtest314-next-e2e-tests` scope which is more relevant to Next.js. 

Part of https://linear.app/vercel/issue/NAR-719/

## Test plan

- [x] `pnpm build` cache in build-and-test: https://github.com/vercel/next.js/actions/runs/21167346706/job/60875389162?pr=88794#step:29:660
- [x] No more "no write permissions" warnings and tests are stable in e2e deploy test: [successful write](https://github.com/vercel/next.js/actions/runs/21167622381/job/60876197825#step:31:63), [successful read](https://github.com/vercel/next.js/actions/runs/21167622381/job/60876656384#step:31:63)

Changed files:
filename: .github/workflows/build_reusable.yml
patch: @@ -95,9 +95,9 @@ env:
   # disable backtrace for test snapshots
   RUST_BACKTRACE: 0
 
-  TURBO_TEAM: 'vercel'
+  TURBO_TEAM: 'vtest314-next-e2e-tests'
   TURBO_CACHE: 'remote:rw'
-  TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
+  TURBO_TOKEN: ${{ secrets.TURBO_REMOTE_CACHE_TOKEN }}
 
   NEXT_TELEMETRY_DISABLED: 1
   # allow not skipping install-native postinstall script if we don't have a binary available already
Repository: ollama/ollama
Pull request: Update README.md

removed solar and added granite 3.2 by ibm. redhat looking for using this on there linux os so having this one make sense and removed solar as it is now irrelevant not been updated and it is too out of date for the quality. 

Changed files:
filename: README.md
patch: @@ -75,7 +75,7 @@ Here are some example models that can be downloaded:
 | Code Llama         | 7B         | 3.8GB | `ollama run codellama`           |
 | Llama 2 Uncensored | 7B         | 3.8GB | `ollama run llama2-uncensored`   |
 | LLaVA              | 7B         | 4.5GB | `ollama run llava`               |
-| Solar              | 10.7B      | 6.1GB | `ollama run solar`               |
+| Granite-3.2         | 8B         | 4.9GB | `ollama run granite3.2`          |
 
 > [!NOTE]
 > You should have at least 8 GB of RAM available to run the 7B models, 16 GB to run the 13B models, and 32 GB to run the 33B models.
Repository: nodejs/node
Pull request: doc: mention --newVersion release script

This is useful when preparing a semver-minor security release 

Changed files:
filename: doc/contributing/releases.md
patch: @@ -325,7 +325,12 @@ git node release -S --prepare --security --filterLabel v20.x
 ```
 
 to automate the remaining steps until step 6 or you can perform it manually
-following the below steps.
+following the below steps. For semver-minors, you can pass the new version
+explicitly with `--newVersion` arg:
+
+```bash
+git node release -S --prepare --security --filterLabel v20.x --newVersion 20.20.0
+```
 
 <details>
 <summary>Security release</summary>
Repository: facebook/react
Pull request: [Flight] Use Web Streams APIs for 3rd-party component in Flight fixture

Stacked on #33480.

Now that the Node bundles for Webpack also expose the Web Streams APIs, we can can use those in the Flight fixture for caching the 3rd-party component, without needing to convert the streams back and forth.

This new approach of how we're exposing those APIs also allows us to mix and match them with the Node Streams APIs (e.g. in the outer rendering in `fixtures/flight/server/region.js`). This was not possible with the previous approach of using separate bundles, because React only allows a single RSC renderer to be active at a time.

Changed files:
filename: fixtures/flight/src/App.js
patch: @@ -1,6 +1,6 @@
 import * as React from 'react';
-import {renderToPipeableStream} from 'react-server-dom-webpack/server';
-import {createFromNodeStream} from 'react-server-dom-webpack/client';
+import {renderToReadableStream} from 'react-server-dom-webpack/server';
+import {createFromReadableStream} from 'react-server-dom-webpack/client';
 import {PassThrough, Readable} from 'stream';
 
 import Container from './Container.js';
@@ -46,43 +46,33 @@ async function ThirdPartyComponent() {
   return delay('hello from a 3rd party', 30);
 }
 
-// Using Web streams for tee'ing convenience here.
-let cachedThirdPartyReadableWeb;
+let cachedThirdPartyStream;
 
 // We create the Component outside of AsyncLocalStorage so that it has no owner.
 // That way it gets the owner from the call to createFromNodeStream.
 const thirdPartyComponent = <ThirdPartyComponent />;
 
 function fetchThirdParty(noCache) {
-  if (cachedThirdPartyReadableWeb && !noCache) {
-    const [readableWeb1, readableWeb2] = cachedThirdPartyReadableWeb.tee();
-    cachedThirdPartyReadableWeb = readableWeb1;
-
-    return createFromNodeStream(Readable.fromWeb(readableWeb2), {
+  // We're using the Web Streams APIs for tee'ing convenience.
+  const stream =
+    cachedThirdPartyStream && !noCache
+      ? cachedThirdPartyStream
+      : renderToReadableStream(
+          thirdPartyComponent,
+          {},
+          {environmentName: 'third-party'}
+        );
+
+  const [stream1, stream2] = stream.tee();
+  cachedThirdPartyStream = stream1;
+
+  return createFromReadableStream(stream2, {
+    serverConsumerManifest: {
       moduleMap: {},
-      moduleLoading: {},
-    });
-  }
-
-  const stream = renderToPipeableStream(
-    thirdPartyComponent,
-    {},
-    {environmentName: 'third-party'}
-  );
-
-  const readable = new PassThrough();
-  // React currently only supports piping to one stream, so we convert, tee, and
-  // convert back again.
-  // TODO: Switch to web streams without converting when #33442 has landed.
-  const [readableWeb1, readableWeb2] = Readable.toWeb(readable).tee();
-  cachedThirdPartyReadableWeb = readableWeb1;
-  const result = createFromNodeStream(Readable.fromWeb(readableWeb2), {
-    moduleMap: {},
-    moduleLoading: {},
+      serverModuleMap: null,
+      moduleLoading: null,
+    },
   });
-  stream.pipe(readable);
-
-  return result;
 }
 
 async function ServerComponent({noCache}) {
Repository: ggml-org/llama.cpp
Pull request: nit : better mtp check and fix return

cont #20411

Changed files:
filename: convert_hf_to_gguf.py
patch: @@ -10092,9 +10092,9 @@ def modify_tensors(self, data_torch: Tensor, name: str, bid: int | None) -> Iter
             # Skip Multi-Token Prediction (MTP) tensors. These are used for
             # for speculative decoding but we don't include them in this model
             # conversion. See https://github.com/ggml-org/llama.cpp/pull/18886
-            if "mtp" in name:
+            if name.startswith("mtp."):
                 logger.info(f"gguf: Skipping MTP (Speculative) layer: {name}")
-                return []
+                return
 
             if name.endswith("mixer.gate.e_score_correction_bias"):
                 new_name = name.replace("e_score_correction_bias", "e_score_correction.bias")
Repository: vuejs/vue
Pull request: test(ssr): add basic directives test

<!--
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
- [x] 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
- [x] New/updated tests are included

**Other information:**

#9167

Changed files:
filename: test/ssr/jasmine.js
patch: @@ -4,6 +4,7 @@ module.exports = {
     '*.spec.js'
   ],
   helpers: [
-    require.resolve('@babel/register')
+    require.resolve('@babel/register'),
+    '../helpers/to-have-been-warned.js'
   ]
 }

filename: test/ssr/ssr-string.spec.js
patch: @@ -794,6 +794,23 @@ describe('SSR: renderToString', () => {
     })
   })
 
+  it('should resolve custom directive', done => {
+    renderToString(new Vue({
+      directives: {
+        test: {
+          bind(node) {
+            node.data.domProps = { textContent: 'test' }
+          }
+        }
+      },
+      template: '<div v-test></div>',
+    }), (err, result) => {
+      expect('Failed to resolve directive: test').not.toHaveBeenWarned()
+      expect(result).toContain('<div data-server-rendered="true">test</div>')
+      done()
+    })
+  })
+
   it('custom directives', done => {
     const renderer = createRenderer({
       directives: {
Repository: facebook/react
Pull request: [Flight] Add Web Streams APIs to unbundled Node entries for Webpack

This was missed in #33474. We're adding the new exports to the server entries only. The client entries don't need to be changed because they use `export *`.

Changed files:
filename: packages/react-server-dom-webpack/npm/server.node.unbundled.js
patch: @@ -7,9 +7,11 @@ if (process.env.NODE_ENV === 'production') {
   s = require('./cjs/react-server-dom-webpack-server.node.unbundled.development.js');
 }
 
+exports.renderToReadableStream = s.renderToReadableStream;
 exports.renderToPipeableStream = s.renderToPipeableStream;
-exports.decodeReplyFromBusboy = s.decodeReplyFromBusboy;
 exports.decodeReply = s.decodeReply;
+exports.decodeReplyFromBusboy = s.decodeReplyFromBusboy;
+exports.decodeReplyFromAsyncIterable = s.decodeReplyFromAsyncIterable;
 exports.decodeAction = s.decodeAction;
 exports.decodeFormState = s.decodeFormState;
 exports.registerServerReference = s.registerServerReference;

filename: packages/react-server-dom-webpack/server.node.unbundled.js
patch: @@ -9,8 +9,10 @@
 
 export {
   renderToPipeableStream,
-  decodeReplyFromBusboy,
+  renderToReadableStream,
   decodeReply,
+  decodeReplyFromBusboy,
+  decodeReplyFromAsyncIterable,
   decodeAction,
   decodeFormState,
   registerServerReference,

filename: packages/react-server-dom-webpack/static.node.unbundled.js
patch: @@ -7,4 +7,7 @@
  * @flow
  */
 
-export {unstable_prerenderToNodeStream} from './src/server/react-flight-dom-server.node.unbundled';
+export {
+  unstable_prerender,
+  unstable_prerenderToNodeStream,
+} from './src/server/react-flight-dom-server.node.unbundled';
Repository: ollama/ollama
Pull request: server/.../backoff,syncs: conditionally skip synctest tests

This guards tests using the experimental synctest breaking builds in environments where the experiment is not enabled.

It is required in CI, so we should still catch breaking any changes that break these packages. If we start using the new feature more, we can make it a required part of all tests.

Changed files:
filename: docs/development.md
patch: @@ -118,6 +118,35 @@ To run tests, use `go test`:
 go test ./...
 ```
 
+> NOTE: In rare cirumstances, you may nedd to change a package using the new
+> "synctest" package in go1.24.
+>
+> If you do not have the "synctest" package enabled, you will not see build or
+> test failures resulting from your change(s), if any, locally, but CI will
+> break.
+>
+> If you see failures in CI, you can either keep pushing changes to see if the
+> CI build passes, or you can enable the "synctest" package locally to see the
+> failures before pushing.
+>
+> To enable the "synctest" package for testing, run the following command:
+>
+> ```shell
+> GOEXPERIMENT=synctest go test ./...
+> ```
+>
+> If you wish to enable synctest for all go commands, you can set the
+> `GOEXPERIMENT` environment variable in your shell profile or by using:
+>
+> ```shell
+> go env -w GOEXPERIMENT=synctest
+> ```
+>
+> Which will enable the "synctest" package for all go commands without needing
+> to set it for all shell sessions.
+>
+> The synctest package is not required for production builds.
+
 ## Library detection
 
 Ollama looks for acceleration libraries in the following paths relative to the `ollama` executable:

filename: server/internal/internal/backoff/backoff_test.go
patch: @@ -1,3 +1,5 @@
+//go:build goexperiment.synctest
+
 package backoff
 
 import (

filename: server/internal/internal/syncs/line_test.go
patch: @@ -1,3 +1,5 @@
+//go:build goexperiment.synctest
+
 package syncs
 
 import (
Repository: ollama/ollama
Pull request: Update README.md - Add OllamaServer

OllamaServer is an Android software that allows users to start Ollama service with one click without Termux

Changed files:
filename: README.md
patch: @@ -513,6 +513,7 @@ See the [API documentation](./docs/api.md) for all endpoints.
 - [Maid](https://github.com/Mobile-Artificial-Intelligence/maid)
 - [Ollama App](https://github.com/JHubi1/ollama-app) (Modern and easy-to-use multi-platform client for Ollama)
 - [ConfiChat](https://github.com/1runeberg/confichat) (Lightweight, standalone, multi-platform, and privacy focused LLM chat interface with optional encryption)
+- [Ollama Android Chat](https://github.com/sunshine0523/OllamaServer) (No need for Termux, start the Ollama service with one click on an Android device)
 - [Reins](https://github.com/ibrahimcetin/reins) (Easily tweak parameters, customize system prompts per chat, and enhance your AI experiments with reasoning model support.)
 
 ### Extensions & Plugins
Repository: vuejs/vue
Pull request: fix(lifecycle): updated should not be called after component being de…

…stroyed, fix #8076

<!--
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/core/observer/scheduler.js
patch: @@ -98,7 +98,7 @@ function callUpdatedHooks (queue) {
   while (i--) {
     const watcher = queue[i]
     const vm = watcher.vm
-    if (vm._watcher === watcher && vm._isMounted) {
+    if (vm._watcher === watcher && vm._isMounted && !vm._isDestroyed) {
       callHook(vm, 'updated')
     }
   }

filename: test/unit/features/options/lifecycle.spec.js
patch: @@ -199,6 +199,43 @@ describe('Options lifecycle hooks', () => {
         expect(calls).toEqual(['child', 'parent'])
       }).then(done)
     })
+
+    // #8076
+    it('should not be called after destroy', done => {
+      const updated = jasmine.createSpy('updated')
+      const destroyed = jasmine.createSpy('destroyed')
+
+      Vue.component('todo', {
+        template: '<div>{{todo.done}}</div>',
+        props: ['todo'],
+        destroyed,
+        updated
+      })
+
+      const vm = new Vue({
+        template: `
+          <div>
+            <todo v-for="t in pendingTodos" :todo="t" :key="t.id"></todo>
+          </div>
+        `,
+        data () {
+          return {
+            todos: [{ id: 1, done: false }]
+          }
+        },
+        computed: {
+          pendingTodos () {
+            return this.todos.filter(t => !t.done)
+          }
+        }
+      }).$mount()
+
+      vm.todos[0].done = true
+      waitForUpdate(() => {
+        expect(destroyed).toHaveBeenCalled()
+        expect(updated).not.toHaveBeenCalled()
+      }).then(done)
+    })
   })
 
   describe('beforeDestroy', () => {
Repository: huggingface/transformers
Pull request: fix `_get_test_info` in `testing_utils.py`

# What does this PR do?

This method uses some check like

>  frame.function == test_name

however, when we use `@parameterized.expand`, 

- `frame.function` could be `test_model_logits`
- `test_name` could be `test_model_logits_0_cpu`

and we got some strange error message.

See

```
(Pdb) frame.function
'test_model_logits'
(Pdb) test_name.startswith(frame.function)
True
(Pdb) test_name
'test_model_logits_0_cpu'
```

This PR tries to relax this condition to handle this `parameterized` case.

Changed files:
filename: src/transformers/testing_utils.py
patch: @@ -3318,7 +3318,7 @@ def _get_test_info():
         # check frame's function + if it has `self` as locals; double check if self has the (function) name
         # TODO: Question: How about expanded?
         if (
-            frame.function == test_name
+            test_name.startswith(frame.function)
             and "self" in frame.frame.f_locals
             and hasattr(frame.frame.f_locals["self"], test_name)
         ):
@@ -3346,7 +3346,7 @@ def _get_test_info():
     # Between `the test method being called` and `before entering `patched``.
     for frame in reversed(stack_from_inspect):
         if (
-            frame.function == test_name
+            test_name.startswith(frame.function)
             and "self" in frame.frame.f_locals
             and hasattr(frame.frame.f_locals["self"], test_name)
         ):
Repository: ggml-org/llama.cpp
Pull request: [ggml-virtgpu] Fix some build commands of `development.md`

Hi, this PR fixes the bug of build command in the document.
- Fix incorrect cmake option in building host `ggml-virtgpu` (`GGML_REMOTINGBACKEND=ONLY` → `GGML_VIRTGPU=ON` + `GGML_VIRTGPU_BACKEND=ONLY`)
- Add missing `cd virglrenderer` step in building virglrenderer
- Fix double slash typo in `$PWD//build-virtgpu`

Changed files:
filename: docs/backend/VirtGPU/development.md
patch: @@ -55,7 +55,8 @@ LLAMA_MAC_BUILD=$PWD/build/ggml-virtgpu-backend
 cmake -S . -B $LLAMA_MAC_BUILD \
       -DGGML_NATIVE=OFF \
       -DLLAMA_CURL=ON \
-      -DGGML_REMOTINGBACKEND=ONLY \
+      -DGGML_VIRTGPU=ON \
+      -DGGML_VIRTGPU_BACKEND=ONLY \
       -DGGML_METAL=ON
 
 TARGETS="ggml-metal"
@@ -71,6 +72,7 @@ cmake --build $LLAMA_MAC_BUILD --parallel 8 --target $EXTRA_TARGETS
 ```bash
 # Build virglrenderer with APIR support
 mkdir virglrenderer
+cd virglrenderer
 git clone https://gitlab.freedesktop.org/kpouget/virglrenderer -b main-macos src
 cd src
 
@@ -95,7 +97,7 @@ mkdir llama.cpp
 git clone https://github.com/ggml-org/llama.cpp.git src
 cd src
 
-LLAMA_LINUX_BUILD=$PWD//build-virtgpu
+LLAMA_LINUX_BUILD=$PWD/build-virtgpu
 
 cmake -S . -B $LLAMA_LINUX_BUILD \
       -DGGML_VIRTGPU=ON
Repository: nodejs/node
Pull request: doc: correct typo in api contributing doc

In [doc/contributing/api-documentation.md#vocabulary--good-to-knows](https://github.com/nodejs/node/blob/main/doc/contributing/api-documentation.md#vocabulary--good-to-knows) and viewing the sentence:

> * The [Stability Index](https://nodejs.org/dist/latest/docs/api/documentation.html#stability-index) is used to community the Stability of a given Node.js module.

the word "community" doesn't fit.

Perhaps "communicate" was intended?

I'm suggesting to change it to "describe" instead, so it changes to:

> * The [Stability Index](https://nodejs.org/dist/latest/docs/api/documentation.html#stability-index) is used to describe the Stability of a given Node.js module.

Changed files:
filename: doc/contributing/api-documentation.md
patch: @@ -54,7 +54,7 @@ meant to be a guide on how to write documentation for Node.js.
   it as a reference for the structure of the documentation.
 * The
   [Stability Index](https://nodejs.org/dist/latest/docs/api/documentation.html#stability-index)
-  is used to community the Stability of a given Node.js module. The Stability
+  is used to describe the Stability of a given Node.js module. The Stability
   levels include:
   * Stability 0: Deprecated. (This module is Deprecated)
   * Stability 1: Experimental. (This module is Experimental)
Repository: ollama/ollama
Pull request: docker: use go version from go.mod

use the go.mod version so it's always up to date. this skips downloading a compatible version when `ARG GOVERSION` is out of date

Changed files:
filename: Dockerfile
patch: @@ -86,10 +86,11 @@ RUN --mount=type=cache,target=/root/.ccache \
         && cmake --install build --component CUDA --strip --parallel 8
 
 FROM base AS build
-ARG GOVERSION=1.23.4
-RUN curl -fsSL https://golang.org/dl/go${GOVERSION}.linux-$(case $(uname -m) in x86_64) echo amd64 ;; aarch64) echo arm64 ;; esac).tar.gz | tar xz -C /usr/local
-ENV PATH=/usr/local/go/bin:$PATH
 WORKDIR /go/src/github.com/ollama/ollama
+COPY go.mod go.sum .
+RUN curl -fsSL https://golang.org/dl/go$(awk '/^go/ { print $2 }' go.mod).linux-$(case $(uname -m) in x86_64) echo amd64 ;; aarch64) echo arm64 ;; esac).tar.gz | tar xz -C /usr/local
+ENV PATH=/usr/local/go/bin:$PATH
+RUN go mod download
 COPY . .
 ARG GOFLAGS="'-ldflags=-w -s'"
 ENV CGO_ENABLED=1