helloadhavan/github_issues huggingface dataset:
Repository: vuejs/vue
Pull request: feat: ignored elements wildcard

<!--
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) -->

Did not make an issue for this, but would be nice to have this implemented.
To avoid warnings when integrating web components within Vue (e.g. polymer, ionic 4 / stenciljs), we currently need to add them to [ignoredElements](https://vuejs.org/v2/api/#ignoredElements).
I think it would be a nice addition if we would be able to use a wildcard there, for example:

`Vue.config.ignoredElements = ['ion*']`

instead of 

`Vue.config.ignoredElements = ['ion-app', 'ion-header', 'ion-page', 'ion-toolbar', etc....]`


All tests pass: 
```
86 specs, 0 failures
Finished in 0.698 seconds

```
If there are better ways to implement this functionality (e.g. regex), let me know.

**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
- [ ] 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:**


Changed files:
filename: src/core/vdom/patch.js
patch: @@ -120,7 +120,14 @@ export function createPatchFunction (backend) {
         if (
           !inPre &&
           !vnode.ns &&
-          !(config.ignoredElements.length && config.ignoredElements.indexOf(tag) > -1) &&
+          !(
+            config.ignoredElements.length &&
+            config.ignoredElements.some(ignore => {
+              return ignore instanceof RegExp
+                ? ignore.test(tag)
+                : ignore === tag
+            })
+          ) &&
           config.isUnknownElement(tag)
         ) {
           warn(
Repository: facebook/react
Pull request: [RN] Map Fabric priorities to reconciler priorities correctly

## Summary

This fixes how we map priorities between Fabric and the React reconciler. At the moment, we're only considering default and discrete priorities, when there's a larger range of priorities available.

In Fabric, we'll test supporting additional priorities soon. For that test to do something useful, we need the new priorities to be mapped to reconciler priorities correctly, which is what this change is done.

> [!IMPORTANT]
> At the moment, this is a no-op because Fabric is only reporting default and discrete event priorities.

## How did you test this change?

Will test e2e on React Native on top of https://github.com/facebook/react-native/pull/50627

The changes are gated in React Native, so we'll use that feature flag to test this.


Changed files:
filename: packages/react-native-renderer/src/ReactFiberConfigFabric.js
patch: @@ -18,6 +18,8 @@ import {
   NoEventPriority,
   DefaultEventPriority,
   DiscreteEventPriority,
+  ContinuousEventPriority,
+  IdleEventPriority,
   type EventPriority,
 } from 'react-reconciler/src/ReactEventPriorities';
 import type {Fiber} from 'react-reconciler/src/ReactInternalTypes';
@@ -46,6 +48,8 @@ const {
   registerEventHandler,
   unstable_DefaultEventPriority: FabricDefaultPriority,
   unstable_DiscreteEventPriority: FabricDiscretePriority,
+  unstable_ContinuousEventPriority: FabricContinuousPriority,
+  unstable_IdleEventPriority: FabricIdlePriority,
   unstable_getCurrentEventPriority: fabricGetCurrentEventPriority,
 } = nativeFabricUIManager;
 
@@ -397,6 +401,10 @@ export function resolveUpdatePriority(): EventPriority {
     switch (currentEventPriority) {
       case FabricDiscretePriority:
         return DiscreteEventPriority;
+      case FabricContinuousPriority:
+        return ContinuousEventPriority;
+      case FabricIdlePriority:
+        return IdleEventPriority;
       case FabricDefaultPriority:
       default:
         return DefaultEventPriority;

filename: scripts/flow/react-native-host-hooks.js
patch: @@ -277,6 +277,8 @@ declare const nativeFabricUIManager: {
   ) => void,
   unstable_DefaultEventPriority: number,
   unstable_DiscreteEventPriority: number,
+  unstable_ContinuousEventPriority: number,
+  unstable_IdleEventPriority: number,
   unstable_getCurrentEventPriority: () => number,
   ...
 };
Repository: ollama/ollama
Pull request: ci: skip go build for tests

`go build` largely repeats what's already happening in `go test`, and by reducing to `go test` my hope is we can speed it up even more

Changed files:
filename: .github/workflows/test.yaml
patch: @@ -243,7 +243,7 @@ jobs:
           $env:PATH="$gopath;$gccpath;$env:PATH"
           echo $env:PATH
           if (!(gcc --version | select-string -quiet clang)) { throw "wrong gcc compiler detected - must be clang" }
-          make -j 4      
+          make -j 4
       - name: 'Build Unix Go Runners'
         if: ${{ ! startsWith(matrix.os, 'windows-') }}
         run: make -j 4
@@ -310,8 +310,7 @@ jobs:
             arm64) echo ARCH=arm64 ;;
           esac >>$GITHUB_ENV
         shell: bash
-      - run: go build
-      - run: go test -v ./...
+      - run: go test ./...
 
   patches:
     needs: [changes]
@@ -323,4 +322,4 @@ jobs:
           submodules: recursive
       - name: Verify patches carry all the changes
         run: |
-          make apply-patches sync && git diff --compact-summary --exit-code llama
\ No newline at end of file
+          make apply-patches sync && git diff --compact-summary --exit-code llama
Repository: vuejs/vue
Pull request: feat($core): call data method with this (#6739)

#6739

<!--
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:**

- [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/instance/state.js
patch: @@ -161,7 +161,7 @@ function initData (vm: Component) {
 
 function getData (data: Function, vm: Component): any {
   try {
-    return data.call(vm)
+    return data.call(vm, vm)
   } catch (e) {
     handleError(e, vm, `data()`)
     return {}

filename: test/unit/features/options/data.spec.js
patch: @@ -106,4 +106,21 @@ describe('Options data', () => {
     })
     expect(vm.a).toBe(1)
   })
+
+  it('should called with this', () => {
+    const vm = new Vue({
+      template: '<div><child></child></div>',
+      provide: { foo: 1 },
+      components: {
+        child: {
+          template: '<span>{{bar}}</span>',
+          inject: ['foo'],
+          data ({ foo }) {
+            return { bar: 'foo:' + foo }
+          }
+        }
+      }
+    }).$mount()
+    expect(vm.$el.innerHTML).toBe('<span>foo:1</span>')
+  })
 })
Repository: ollama/ollama
Pull request: Add generate endpoint for structured outputs

Follow up to #7900 

Changed files:
filename: api/types.go
patch: @@ -67,7 +67,7 @@ type GenerateRequest struct {
 	Raw bool `json:"raw,omitempty"`
 
 	// Format specifies the format to return a response in.
-	Format string `json:"format"`
+	Format json.RawMessage `json:"format,omitempty"`
 
 	// KeepAlive controls how long the model will stay loaded in memory following
 	// this request.

filename: cmd/cmd.go
patch: @@ -1126,7 +1126,7 @@ func generate(cmd *cobra.Command, opts runOptions) error {
 		Prompt:    opts.Prompt,
 		Context:   generateContext,
 		Images:    opts.Images,
-		Format:    opts.Format,
+		Format:    json.RawMessage(opts.Format),
 		System:    opts.System,
 		Options:   opts.Options,
 		KeepAlive: opts.KeepAlive,

filename: server/routes.go
patch: @@ -148,10 +148,7 @@ func (s *Server) GenerateHandler(c *gin.Context) {
 		return
 	}
 
-	if req.Format != "" && req.Format != "json" {
-		c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "format must be empty or \"json\""})
-		return
-	} else if req.Raw && (req.Template != "" || req.System != "" || len(req.Context) > 0) {
+	if req.Raw && (req.Template != "" || req.System != "" || len(req.Context) > 0) {
 		c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "raw mode does not support template, system, or context"})
 		return
 	}
@@ -278,7 +275,7 @@ func (s *Server) GenerateHandler(c *gin.Context) {
 		if err := r.Completion(c.Request.Context(), llm.CompletionRequest{
 			Prompt:  prompt,
 			Images:  images,
-			Format:  json.RawMessage(req.Format),
+			Format:  req.Format,
 			Options: opts,
 		}, func(cr llm.CompletionResponse) {
 			res := api.GenerateResponse{
Repository: electron/electron
Pull request: fix: only call popup closecallback for top-level menu

#### Description of Change

Closes https://github.com/electron/electron/issues/49005.

Fixes an issue where the close callback param for `menu.popup` would fire when any arbitrary submenu of the given menu closed, and not the menu itself.

Fix this by ensuring that `menuDidClose` checks for the menu being the correc top-level menu.

#### Checklist
<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

- [x] PR description included and stakeholders cc'd
- [x] `npm test` passes
- [x] [PR release notes](https://github.com/electron/clerk/blob/main/README.md) describe the change in a way relevant to app developers, and are [capitalized, punctuated, and past tense](https://github.com/electron/clerk/blob/main/README.md#examples).

#### Release Notes

Notes: Fixed an issue where the close callback param for `menu.popup` would fire when any arbitrary submenu of the given menu closed, and not the menu itself.


Changed files:
filename: shell/browser/ui/cocoa/electron_menu_controller.mm
patch: @@ -563,16 +563,22 @@ - (void)menuWillOpen:(NSMenu*)menu {
 }
 
 - (void)menuDidClose:(NSMenu*)menu {
-  if (isMenuOpen_) {
-    isMenuOpen_ = NO;
-    if (model_)
-      model_->MenuWillClose();
-    // Post async task so that itemSelected runs before the close callback
-    // deletes the controller from the map which deallocates it
-    if (!closeCallback.is_null()) {
-      content::GetUIThreadTaskRunner({})->PostTask(FROM_HERE,
-                                                   std::move(closeCallback));
-    }
+  // If the menu is already closed, do nothing.
+  if (!isMenuOpen_)
+    return;
+
+  // We should only respond to the top-level menu's close event.
+  if (menu != menu_)
+    return;
+
+  isMenuOpen_ = NO;
+  if (model_)
+    model_->MenuWillClose();
+  // Post async task so that itemSelected runs before the close callback
+  // deletes the controller from the map which deallocates it
+  if (!closeCallback.is_null()) {
+    content::GetUIThreadTaskRunner({})->PostTask(FROM_HERE,
+                                                 std::move(closeCallback));
   }
 }
Repository: vercel/next.js
Pull request: Turbopack: fix order of breadth first edges

### What?

It's a VecDeque and we are calling pop_front() so we don't want to reverse the roots

Changed files:
filename: turbopack/crates/turbo-tasks/src/graph/adjacency_map.rs
patch: @@ -136,12 +136,7 @@ where
     pub fn into_breadth_first_edges(self) -> IntoBreadthFirstEdges<T, E> {
         IntoBreadthFirstEdges {
             adjacency_map: self.adjacency_map,
-            queue: self
-                .roots
-                .into_iter()
-                .rev()
-                .map(|root| (None, root))
-                .collect(),
+            queue: self.roots.into_iter().map(|root| (None, root)).collect(),
             expanded: FxHashSet::default(),
         }
     }
Repository: nodejs/node
Pull request: test: skip SEA inspect test if inspector is not available


Changed files:
filename: test/sea/test-single-executable-application-inspect.js
patch: @@ -16,6 +16,7 @@ const {
 } = require('../common/sea');
 
 skipIfSingleExecutableIsNotSupported();
+common.skipIfInspectorDisabled();
 
 const configFile = tmpdir.resolve('sea-config.json');
 const seaPrepBlob = tmpdir.resolve('sea-prep.blob');
Repository: vercel/next.js
Pull request: [strict-route-types] Don't reject `number` in `config.api.bodyParser.sizeLimit` when validating route

Not flagged behind `experimental.strictRouteTypes`. This is just a bug fix.

Got revealed once we typechecked routes in pure Pages Router apps e.g.
```
.next/types/validator.ts:76:11
Type error: Type 'typeof import("~/pages/api/hello")' does not satisfy the expected type 'ApiRouteConfig'.
  The types of 'config.api.bodyParser' are incompatible between these types.
    Type 'false | { sizeLimit?: SizeLimit; }' is not assignable to type 'boolean | { sizeLimit?: string; }'.
      Type '{ sizeLimit?: SizeLimit; }' is not assignable to type 'boolean | { sizeLimit?: string; }'.
        Type '{ sizeLimit?: SizeLimit; }' is not assignable to type '{ sizeLimit?: string; }'.
          Types of property 'sizeLimit' are incompatible.
            Type 'SizeLimit' is not assignable to type 'string'.
              Type 'number' is not assignable to type 'string'.
```
-- https://github.com/vercel/next.js/actions/runs/20427462435/job/58690778302?pr=87628#step:32:562

Closes https://linear.app/vercel/issue/NXT-121

Changed files:
filename: packages/next/src/server/lib/router-utils/typegen.ts
patch: @@ -574,7 +574,7 @@ export function generateValidatorFile(
   default: (req: any, res: any) => ReturnType<NextApiHandler>
   config?: {
     api?: {
-      bodyParser?: boolean | { sizeLimit?: string }
+      bodyParser?: boolean | { sizeLimit?: number | string }
       responseLimit?: string | number | boolean
       externalResolver?: boolean
     }
@@ -809,7 +809,7 @@ export function generateValidatorFileStrict(
   default: (req: any, res: any) => ReturnType<NextApiHandler>
   config?: {
     api?: {
-      bodyParser?: boolean | { sizeLimit?: string }
+      bodyParser?: boolean | { sizeLimit?: number | string }
       responseLimit?: string | number | boolean
       externalResolver?: boolean
     }
Repository: ggml-org/llama.cpp
Pull request: gguf : fix ftell/fseek for Windows

Regression introduced in #19856.

This changes the `ftell/fseek` calls to use `_ftelli64/_fseeki64` on Windows, and `ftello/fseeko` for POSIX systems.

`long` on Windows is always 32-bit. Since that would cause an overflow on large files, `ftell/fseek` fails and `nbytes_remain()` returns `0`.

fixes #19862
fixes #19868

AI Disclosure: used for review, it suggested using `ftello/fseeko` for better guarantees, figured I'd throw it in.

Changed files:
filename: ggml/src/gguf.cpp
patch: @@ -18,6 +18,14 @@
 #define GGUF_MAX_STRING_LENGTH  (1024*1024*1024)
 #define GGUF_MAX_ARRAY_ELEMENTS (1024*1024*1024)
 
+#ifdef _WIN32
+#    define gguf_ftell _ftelli64
+#    define gguf_fseek _fseeki64
+#else
+#    define gguf_ftell ftello
+#    define gguf_fseek fseeko
+#endif
+
 template <typename T>
 struct type_to_gguf_type;
 
@@ -319,22 +327,22 @@ struct gguf_reader {
 
     // remaining bytes in the file
     uint64_t nbytes_remain() const {
-        const long cur = ftell(file);
+        const int64_t cur = gguf_ftell(file);
         if (cur < 0) {
             return 0;
         }
-        if (fseek(file, 0, SEEK_END) != 0) {
-            fseek(file, cur, SEEK_SET);
+        if (gguf_fseek(file, 0, SEEK_END) != 0) {
+            gguf_fseek(file, cur, SEEK_SET);
 
             return 0;
         }
-        const long end = ftell(file);
+        const int64_t end = gguf_ftell(file);
         if (end < 0) {
-            fseek(file, cur, SEEK_SET);
+            gguf_fseek(file, cur, SEEK_SET);
 
             return 0;
         }
-        fseek(file, cur, SEEK_SET);
+        gguf_fseek(file, cur, SEEK_SET);
         return static_cast<uint64_t>(end - cur);
     }
 };
@@ -671,14 +679,14 @@ struct gguf_context * gguf_init_from_file_impl(FILE * file, struct gguf_init_par
     GGML_ASSERT(int64_t(ctx->info.size()) == n_tensors);
 
     // we require the data section to be aligned, so take into account any padding
-    if (fseek(file, GGML_PAD(ftell(file), ctx->alignment), SEEK_SET) != 0) {
+    if (gguf_fseek(file, GGML_PAD(gguf_ftell(file), ctx->alignment), SEEK_SET) != 0) {
         GGML_LOG_ERROR("%s: failed to seek to beginning of data section\n", __func__);
         gguf_free(ctx);
         return nullptr;
     }
 
     // store the current file offset - this is where the data section starts
-    ctx->offset = ftell(file);
+    ctx->offset = gguf_ftell(file);
 
     // compute the total size of the data section, taking into account the alignment
     {
Repository: ollama/ollama
Pull request: fix unmarshaling merges

some models uses `[][]string` as `.model.merges` value rather than `[]string`

Changed files:
filename: convert/tokenizer.go
patch: @@ -10,6 +10,7 @@ import (
 	"log/slog"
 	"os"
 	"slices"
+	"strings"
 
 	"golang.org/x/exp/maps"
 )
@@ -60,7 +61,25 @@ func parseTokenizer(fsys fs.FS, specialTokenTypes []string) (*Tokenizer, error)
 			addedTokens[t.Content] = t
 		}
 
-		t.Merges = tt.Model.Merges
+		if len(tt.Model.Merges) == 0 {
+			// noop; merges is empty
+		} else if err := json.Unmarshal(tt.Model.Merges, &t.Merges); err == nil {
+			// noop; merges is []string
+		} else if merges, err := func() ([][]string, error) {
+			var merges [][]string
+			if err := json.Unmarshal(tt.Model.Merges, &merges); err != nil {
+				return nil, err
+			}
+
+			return merges, nil
+		}(); err == nil {
+			t.Merges = make([]string, len(merges))
+			for i := range merges {
+				t.Merges[i] = strings.Join(merges[i], " ")
+			}
+		} else {
+			return nil, fmt.Errorf("could not parse tokenizer merges. expected []string or [][]string: %w", err)
+		}
 
 		sha256sum := sha256.New()
 		for _, pt := range tt.PreTokenizer.PreTokenizers {
@@ -156,9 +175,9 @@ func parseTokenizer(fsys fs.FS, specialTokenTypes []string) (*Tokenizer, error)
 type tokenizer struct {
 	AddedTokens []token `json:"added_tokens"`
 	Model       struct {
-		Type   string         `json:"type"`
-		Vocab  map[string]int `json:"vocab"`
-		Merges []string       `json:"merges"`
+		Type   string          `json:"type"`
+		Vocab  map[string]int  `json:"vocab"`
+		Merges json.RawMessage `json:"merges"`
 	} `json:"model"`
 
 	PreTokenizer struct {

filename: convert/tokenizer_test.go
patch: @@ -191,6 +191,62 @@ func TestParseTokenizer(t *testing.T) {
 				Pre: "default",
 			},
 		},
+		{
+			name: "list string merges",
+			fsys: createTokenizerFS(t, t.TempDir(), map[string]io.Reader{
+				"tokenizer.json": strings.NewReader(`{
+					"model": {
+						"merges": [
+							"a b",
+							"c d",
+							"e f"
+						]
+					}
+				}`),
+			}),
+			want: &Tokenizer{
+				Vocabulary: &Vocabulary{
+					Model: "gpt2",
+				},
+				Merges: []string{
+					"a b",
+					"c d",
+					"e f",
+				},
+				Pre: "default",
+			},
+		},
+		{
+			name: "list list string merges",
+			fsys: createTokenizerFS(t, t.TempDir(), map[string]io.Reader{
+				"tokenizer.json": strings.NewReader(`{
+					"model": {
+						"merges": [
+							[
+								"a", "b"
+							],
+							[
+								"c", "d"
+							],
+							[
+								"e", "f"
+							]
+						]
+					}
+				}`),
+			}),
+			want: &Tokenizer{
+				Vocabulary: &Vocabulary{
+					Model: "gpt2",
+				},
+				Merges: []string{
+					"a b",
+					"c d",
+					"e f",
+				},
+				Pre: "default",
+			},
+		},
 	}
 
 	for _, tt := range cases {
Repository: vuejs/vue
Pull request: Extend config keyCodes property type to accept an array of numbers

<!--
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:

Modification of Vue's static `config` property type definition.

**Does this PR introduce a breaking change?** (check one)

- [ ] Yes
- [x] No

**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
- [ ] New/updated tests are included

**Other information:**

![image](https://user-images.githubusercontent.com/10469676/31264038-0a7df5e0-aa2c-11e7-9ef9-441ca9e91dd4.png)

[Per the documentation of the Vue config's `keyCodes` object](https://vuejs.org/v2/api/#keyCodes), the value of a `keyCodes` property may be either a number or an array of numbers. The current `keyCodes` type definition only accepts a single, non-array number. This PR corrects the type definition to reflect both types of acceptable values.




Changed files:
filename: types/vue.d.ts
patch: @@ -80,7 +80,7 @@ export declare class Vue {
     errorHandler(err: Error, vm: Vue, info: string): void;
     warnHandler(msg: string, vm: Vue, trace: string): void;
     ignoredElements: string[];
-    keyCodes: { [key: string]: number };
+    keyCodes: { [key: string]: number | number[] };
   }
 
   static extend(options: ComponentOptions<Vue> | FunctionalComponentOptions): typeof Vue;