[Snyk] Upgrade @typescript-eslint/eslint-plugin from 6.8.0 to 6.9.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @typescript-eslint/eslint-plugin from 6.8.0 to 6.9.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 45 versions ahead of your current version.
The recommended version was released a month ago, on 2023-10-23.

Release notes

Package name: @typescript-eslint/eslint-plugin

6.9.0 - 2023-10-236.9.0 (2023-10-23)
Bug Fixes

eslint-plugin: [no-confusing-void-expression] handle unfixable cases (#7674) (7e52f27)
eslint-plugin: [no-unsafe-return] allow returning anything if explicitly returning any (#7708) (c6124b2)
rule-tester: fix parser fallback logic (#7754) (34c23e0)
type-utils: treat custom type roots as external (#6870) (b85f744)

Features

eslint-plugin: [max-params] don't count this: void parameter (#7696) (6398d3f), closes #7538
eslint-plugin: [naming-convention] add support for default and namespace imports (#7269) (bb15aae)
eslint-plugin: [no-restricted-imports] support import = require (#7709) (4c8edcf)
eslint-plugin: [no-unsafe-enum-comparison] add switch suggestion (#7691) (53d5263), closes #7643
eslint-plugin: [prefer-readonly] private fields support (#7686) (0e875bf)

You can read about our versioning strategy and releases on our website.

6.8.1-alpha.62 - 2023-10-22

6.8.1-alpha.61 - 2023-10-22

6.8.1-alpha.60 - 2023-10-21

6.8.1-alpha.59 - 2023-10-21

6.8.1-alpha.58 - 2023-10-21

6.8.1-alpha.57 - 2023-10-21

6.8.1-alpha.56 - 2023-10-21

6.8.1-alpha.55 - 2023-10-20

6.8.1-alpha.54 - 2023-10-20

6.8.1-alpha.53 - 2023-10-20

6.8.1-alpha.52 - 2023-10-20

6.8.1-alpha.50 - 2023-10-20

6.8.1-alpha.49 - 2023-10-20

6.8.1-alpha.46 - 2023-10-20

6.8.1-alpha.43 - 2023-10-20

6.8.1-alpha.41 - 2023-10-20

6.8.1-alpha.39 - 2023-10-20

6.8.1-alpha.34 - 2023-10-20

6.8.1-alpha.33 - 2023-10-20

6.8.1-alpha.31 - 2023-10-20

6.8.1-alpha.30 - 2023-10-20

6.8.1-alpha.29 - 2023-10-20

6.8.1-alpha.28 - 2023-10-19

6.8.1-alpha.27 - 2023-10-19

6.8.1-alpha.26 - 2023-10-19

6.8.1-alpha.25 - 2023-10-19

6.8.1-alpha.23 - 2023-10-19

6.8.1-alpha.21 - 2023-10-19

6.8.1-alpha.19 - 2023-10-19

6.8.1-alpha.18 - 2023-10-19

6.8.1-alpha.17 - 2023-10-19

6.8.1-alpha.16 - 2023-10-19

6.8.1-alpha.15 - 2023-10-19

6.8.1-alpha.14 - 2023-10-19

6.8.1-alpha.13 - 2023-10-19

6.8.1-alpha.12 - 2023-10-19

6.8.1-alpha.7 - 2023-10-18

6.8.1-alpha.6 - 2023-10-18

6.8.1-alpha.5 - 2023-10-18

6.8.1-alpha.4 - 2023-10-17

6.8.1-alpha.3 - 2023-10-17

6.8.1-alpha.2 - 2023-10-17

6.8.1-alpha.1 - 2023-10-17

6.8.1-alpha.0 - 2023-10-16

6.8.0 - 2023-10-166.8.0 (2023-10-16)
Bug Fixes

eslint-plugin: [consistent-type-imports] import assertion checks added (#7722) (afdae37)
eslint-plugin: [no-shadow] fix static class generics for class expressions (#7724) (e5ea1d0)
eslint-plugin: [no-unsafe-member-access] report on only the accessed property (#7717) (f81a2da)
eslint-plugin: [no-useless-empty-export] exempt .d.ts (#7718) (ac397f1)

Features

eslint-plugin: add new extended rule prefer-destructuring (#7117) (3c6379b)

You can read about our versioning strategy and releases on our website.

    from @typescript-eslint/eslint-plugin GitHub release notes

Commit messages

Package name: @typescript-eslint/eslint-plugin

101563b chore: publish v6.9.0
9ad3917 chore: cancel concurrent ci workflow runs (#7819)
804906d chore(website): swizzle 404 page with editor-like squiggle (#7731)
066ccf7 chore: update to nx 17 (#7815)
e8a5bb3 chore(deps): update dependency lerna to v7.4.1 (#7809)
0aca484 chore(deps): update dependency @ types/react to v18.2.29 (#7772)
c5cad0a chore(deps): update dependency glob to v10.3.10 - abandoned (#7777)
703337f chore(deps): update jest (#7814)
e0895dc chore(deps): update dependency webpack to v5.89.0 (#7804)
6364861 chore(deps): update dependency @ microsoft/api-extractor to v7.38.0 (#7803)
9e95658 chore(deps): update dependency sinon to v16 (#7797)
c4fc884 chore(deps): update dependency monaco-editor to ~0.44.0 (#7794)
5c4ad83 chore(deps): update dependency tsx to v3.13.0 (#7796)
8e1bd49 chore(deps): update dependency @ eslint/js to v8.51.0 (#7802)
9be6154 chore(deps): update docusaurus to v2.4.3 (#7799)
b9a1cde chore(deps): update dependency @ actions/github to v6 (#7779)
abf1a87 chore(deps): update dependency rimraf to v5.0.5 (#7791)
2dce1f5 chore(deps): update dependency eslint-plugin-deprecation to v2 (#7780)
697cb8c chore(deps): update actions/checkout action to v4 (#7778)
c504012 chore(deps): update dependency chai to v4.3.10 (#7776)
9a0c560 chore(deps): update dependency @ types/natural-compare to v1.4.2 (#7788)
0140b37 chore(deps): update dependency esbuild to v0.19.5 (#7790)
bb4c8ab chore(deps): update dependency markdownlint-cli to ^0.37.0 (#7793)
aeecc08 chore(deps): update dependency @ types/tmp to v0.2.5 (#7789)

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (7e0d818) 92.34% compared to head (f149848) 92.34%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #24   +/-   ##
=======================================
  Coverage   92.34%   92.34%
=======================================
  Files           6        6
  Lines         418      418
  Branches       11       11
=======================================
  Hits          386      386
  Misses         32       32

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Vertical Alignment of Icon in a TextField

Use case

I have a form and below it, I have an expandable details field (it's a shame that I can't do it with a TextFormField but that's for another time). I vertically aligned the text to the top using textAlignVertical: TextAlignVertical.top but I can't do the same for the prefixIcon.
Here's the code I used to make this field:
    Widget detailsField = SizedBox(
      height: 100,
      child: Padding(
        padding: EdgeInsets.symmetric(horizontal: 8),
        child: TextField(
          keyboardType: TextInputType.multiline,
          expands: true,
          minLines: null,
          maxLines: null,
          decoration: InputDecoration(
            border: OutlineInputBorder(),
            hintText: "Details",
            prefixIcon: Icon(Icons.subject, color: Theme.of(context).primaryIconTheme.color),
          ),
          textAlignVertical: TextAlignVertical.top,
        ),
      ),
    );

Proposal

It would be great if there was a property when you style the prefix or suffix icon that can vertically align it in an expandable text field so that the text and icon aren't misaligned.

#42936 does not mention this issue at all.

#42936 does not mention this issue at all.
Would be awesome to have for suffix icon as well

If you look, they edited the PR because they put the wrong issue ID (in this case, they accidentally used this one) @Menelphor.

I figured a nice work-around :)
Remove prefexIcon and add the Icon as a stack in a Positioned widget instead. Then in the Textfield InputDecoration, add content padding to the left.
This solution is a temporary workaround that resolves the issue with TextField's prefex and suffix's Alignment and minimum padding.
It would however be nice if they add these properties into the TextField.
Stack(
            children: [
              TextField(
                keyboardType: TextInputType.multiline,
                expands: true,
                minLines: null,
                maxLines: null,
                decoration: InputDecoration(
                  contentPadding: EdgeInsets.only(left: 40.0, top: 10.0),
                  border: OutlineInputBorder(),
                  hintText: "Details",
                ),
                textAlignVertical: TextAlignVertical.top,
              ),
              Positioned(
                top: 0,
                left: 0,
                child: Padding(
                  padding: const EdgeInsets.symmetric(
                      horizontal: 8.0, vertical: 10.0),
                  child: Icon(Icons.subject,
                      color: Theme.of(context).primaryIconTheme.color),
                ),
              ),
            ],
          ),

I am also facing this issue, I have also the requirement to set prefix icon to be top-aligned with its text. I request to the core team, please add this feature in this API.

I solved this problem by adding a Padding to the Icon.
prefixIcon: Padding(    padding: const EdgeInsets.fromLTRB(0, 0, 0, 80),    child: Icon(Icons.message),  )

using textAlignVertical: TextAlignVertical.center easily fix it.

I want vertical alignment for prefixIcon & suffixIcon like Telegram:

im also having this issue, padding worked for me.

prefixIcon: Padding(
padding: const EdgeInsets.all(8)..

8 because my container have height: 38

You can wrap your widget in a Column and give it mainAxisAlignment.center, this works for me in a one line TextField, have not tried it on multiline, let me know if this is the right solution

Any update?

Is there any solution?

any news about this issue?

Here is my solution:
// suffixIcon use Center widget by default, this is to position it topRight.
 final clearIcon = Column(
      mainAxisAlignment: MainAxisAlignment.start,
      children: [
        InkWell(
          child:  Icon(Icons.clear),
          onTap: () => _yourController.clear(),
        ),
      ],
    );

...
 TextFormField(
      maxLines: 9,
      decoration: InputDecoration(
        // Override default spaces by assigning empty constraints. Default is 48x48.
        suffixIconConstraints: BoxConstraints(),
        suffixIcon:
            _yourController.text.isNotEmpty ? clearIcon : null,
      ),
      controller: _yourController,
    )

Simple prefix or suffix have the same baseline as texts, so using them also solves this misalignment issue. But do not forget they are designed to add paddings initially, not to build icons. So Icon used in suffix can also tweak the alignment of text when you try to extend clickable area of icon by paddings. You need to play around with it in that case.

I manage to solve this by adding proper bottom padding
bottom: (double.parse(maxLines.toString()) - 1) * 18)

  prefixIcon: Padding(
                padding: EdgeInsets.only(
                    left: 25,
                    right: 18,
                    //https://github.com/flutter/flutter/issues/42651 The issue is opened in github. However, I manged to solve this problem with proper bottom padding.
                    bottom: (double.parse(maxLines.toString()) - 1) * 18),
                child: Icon(
                  prefixIcon,
                  color: AppColors.appPrimaryColorLight,
                ),
              ),

Any Update on this topic?

I just fix this issue. Just only use prefixIcon property instead of prefix property and use TextAlignVertical.center for textAlignVertical
TextField(         textAlignVertical: TextAlignVertical.center,         decoration: InputDecoration(           contentPadding: EdgeInsets.zero,           prefixIcon: Icon(             Icons.add,             size: 24,             color: Colors.grey,           ),           hintText: 'Typing...',         ),       ),


Revert "Bump dropwizard-bom from 2.1.0 to 2.1.2"

Reverts alphagov/pay-ledger#2146
An integration test fails when post-merge tests are run:
uk.gov.pay.ledger.pact.event.DisputeLostEventQueueConsumerIT
Expected: is "DISPUTE_LOST"
but: was "DISPUTE_WON"
at uk.gov.pay.ledger.pact.event.DisputeLostEventQueueConsumerIT.test(DisputeLostEventQueueConsumerIT.java:101)

I don't think #2146 genuinely caused a problem; I'm closing this PR.


model_precision='float16'

coremltools.converters.keras.convert have parameter model_precision='float16' and seems tfcoreml.tf_converter.convert doesn't have this option, is there any other way to convert tensorflow model to float16 coreml model?

after conversion you can always use the coremltools quantization utils to get float 16 weights model, this has the same effect as the argument in keras convert call
import coremltools
from coremltools.models.neural_network import quantization_utils
mlmodel_fp16 = quantization_utils.quantize_weights(mlmodel_fp32, 16)
mlmodel_fp16.save(coreml_model_path)

Looks like this doc is outdated:
nbits – Int Number of bits per quantized weight. Only 8-bit and lower quantization is supported
Also as I can see here linear quantization is used by default:
https://github.com/apple/coremltools/blob/2b0c00eaec53338d3539bc4009210985fc7c2477/coremltools/models/neural_network/quantization_utils.py#L879

Here is some clarification on this topic:
https://github.com/apple/coremltools/issues/316


Debugger crash when accessing script properties after set_script

Godot version
4.0 Beta3
System information
Windows 10
Issue description
The debugger (and the launched game) crash without further information in the case I try to access a script property after calling set_script on it.
As the debugger crashed, no stack is available for debugging.
It doesn't crash for direct values, but for references (Array, Dict...).
Steps to reproduce
A single Node with the following script:
extends Node

var array = []

func _ready():
	set_script('res://other_script_without_array_property.gd')
	print(array)

Set array to a 'direct' value (int, String...) and it will work perfectly fine.
Set it to a 'referenced' one (Array, Dict...) and after launching the scene, the crash will occur.
Minimal reproduction project
Test4.3.zip

I cannot reproduce this issue on a version based on master . All types of Variants return are null after set_script() is called. Could you elaborate by sharing a minimal reproduction project, maybe trying Godot 4.0 Beta 3 or later?

@Mickeon I just tried on Beta3, still crash. I had ommitted to say that launching the scene was needed for the crash to occur.
I updated the issue with a minimal reproduction project.

Tried the example, and the crash still doesn't occur because array becomes null and is printed as such.
But, the crash does occur when accessing inner members of null (e.g. array.get_property()), whereas normally the debugger would catch it and display the following:

I can confirm that crash, and even handle it through VisualStudio (it doesn't print to log however):

Still seems to be the case in 4.2 beta 6.


Importing ".graphql" file gives cannot resolve warning and no import recommendation

See
https://intellij-support.jetbrains.com/hc/en-us/community/posts/360006865039-Importing-graphql-file-gives-cannot-resolve-warning
I love this plugin. But we have one minor issue. We are using Webpack for loading  ".graphql" files with graphql-tag/loader
{
    test: /\.(graphql|gql)$/,
    exclude: /node_modules/,
    loader: 'graphql-tag/loader',
}

When I use named import like this:
import {productQuery} from<EMAIL_ADDRESS>
Intellij gives "Cannot resolve symbol 'productQuery' "
It works fine if I use default import instead of named import
import productQuery from<EMAIL_ADDRESS>
But this only works if I have only one query per file. Additionally: If I add the term "productQuery" to my code for example
apollo: {
  products: {
     query: productQuery
     ...
 }
}

Intellij should recommend an import statement as a quick fix.

This is still an issue, any word on it?

Hi! I'll look into that in the next release. Also, it may require some changes in the Webstorm, so this may complicate the implementation a bit.

Any updates on this? Running into this problem as a new JetBrains user.

Why is this not yet resolved?
import { Operators, Partners } from "./landing-pages.gql";

This still give Cannot resolve symbol warnings.

@ottopaulsen, it was not possible to resolve it without making changes to the JavaScript support in WebStorm. However, I can now confirm that I have made some improvements related to this issue in WebStorm for the upcoming 2023.3 release. Therefore, it is likely that I will be able to implement support for importing from GraphQL files in the coming months.


python3Packages.elgato: 2.1.1 -> 2.2.0

Motivation for this change
Update to latest upstream release 2.2.0
Change log: https://github.com/frenck/python-elgato/releases/tag/v2.2.0
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 145687 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.elgato
python39Packages.elgato


Add xr::DispatchTable for XrUtility to support libraries that lazily …

…load openxr_loader without static link to xrFunctions.
Also simplify how to call extension functions through global dispatch table.

Need to redo this PR with latest code.


Images not being rendered correctly

I'm seeing an issue with images not being correctly parsed but I'm not 100% sure if the issue is with the plugin or with tt-rss.
I am using latest version of ttrss and feediron plugin via github requests (checked today).
Via FeedIron testing tab I get the correct results, but the result in ttrss excludes the image.  The image exclusion happens maybe 70% of the time for www.economist.com.
URL tested = http://www.economist.com/news/obituary/21717785-long-time-manager-new-yorks-hotel-chelsea-was-82-obituary-stanley-bard-died-february?fsrc=rss
JSON config:
{
"type": "xpath",
"xpath": "article | //img[contains(@class,'component-image__img')]",
"cleanup": "not_aside",
"force_charset": "utf-8"
}
The result shows the image and then the text (the gap does not appear in the ttrss output but I don't know if this is relevant).  However, when I load this in ttrss the image does not appear.  Any thoughts?

I run into this issue often, the responsive image attribute srcset is to blame modifying it to null fixes the issue.
{
    "type": "xpath",
    "xpath": "article | \/\/img[contains(@Class,'component-image__img')]",
    "cleanup": "not_aside",
    "force_charset": "utf-8",
    "modify": [
        {
            "type": "replace",
            "search": [
                "srcset"
            ],
            "replace": [
                "null"
            ]
        }
    ]
}

Many thanks for this.  That has helped a lot, and I'm a bit annoyed for
not spotting it before.
Kind regards,
Darren
On 09/04/2018 08:48, dugite-code wrote:

|"type": "xpath", "xpath": "article |
//img[contains(@Class,'component-image__img')]", "cleanup":
"not_aside", "force_charset": "utf-8", "modify": [ { "type":
"replace", "search": [ "srcset" ], "replace": [ "null" ] } ]|

This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


python/adbc_driver_flightsql: crash in concurrent usage

$ go run github.com/apache/arrow/go/v12/arrow/flight/flightsql/example/cmd/sqlite_flightsql_server@latest -port 12345

Separately:
$ python -m venv venv
$ source venv/bin/activate
$ pip install pyarrow==10.0.1 adbc-driver-flightsql

Then run this script:

import concurrent.futures
from concurrent.futures import ThreadPoolExecutor
import adbc_driver_flightsql.dbapi
import pyarrow

def task(conn):
    with conn.cursor() as cur:
        cur.execute("SELECT 1")
        cur.fetch_arrow_table()

with adbc_driver_flightsql.dbapi.connect("grpc://localhost:12345") as conn:
    with ThreadPoolExecutor() as ex:
        while True:
            futures = [ex.submit(task, conn) for _ in range(23)]
            for future in concurrent.futures.as_completed(futures):
                future.result()

The Go runtime should immediately crash:
runtime: marked free object in span 0x7f7bc8480ba8, elemsize=24 freeindex=0 (bad use of unsafe.Pointer? try -d=checkptr)

Technically, the concurrent conn.cursor() call here is not allowed. But the crash seems to be unrelated to that; the crash won't occur if you comment out fetch_arrow_table or replace it with fetchone.
It also won't happen if you have PyArrow 11, so it may be a regression in PyArrow and not something we should be concerned about.

I think I've observed a crash like this without concurrent usage. @zeroshade should we perhaps just enable checkptr in our releases? It has a performance cost but I don't think users will be spamming calls spanning the FFI boundary.

Specifically, -d=checkptr checks the following:

When converting unsafe.Pointer to *T, the resulting pointer must be aligned appropriately for T.
If the result of pointer arithmetic points into a Go heap object, one of the unsafe.Pointer-typed operands must point into the same object.

https://go.dev/doc/go1.14
It sounds like the cost is fairly minimal (some arithmetic per pointer conversion) all things considered. The original PR (https://github.com/golang/go/issues/22218#issuecomment-463007572) suggests it would be lightweight, too. It sounds more like it's behind -d just because it's somewhat experimental and because existing code was known to violate the rules, not because it's expensive.

It's also not the concurrency itself that's the issue here (i.e. putting a lock around getting a new cursor doesn't change anything).

I added some instrumentation to print out pointers in various places but all seem to be in an entirely different space than what Go is reporting as the problematic pointer. So it doesn't seem to be in the FFI bindings or in Arrow-Go, at least so far.

The next step will be to try building pyarrow 10.0.1 and replicating the issue, then cherry-picking the patch from 11.0.0 that we think is the fix, and confirming that it is indeed the fix.

Non-concurrent reproducer:
import adbc_driver_flightsql.dbapi
import pyarrow

with adbc_driver_flightsql.dbapi.connect("grpc://localhost:12345") as conn:
    cursors = []
    while True:
        cur = conn.cursor()
        cursors.append(cur)
        cur.execute("SELECT 1")
        table = cur.fetch_arrow_table()
        del table

Independent connections aren't safe, either:
import concurrent.futures
from concurrent.futures import ThreadPoolExecutor
import adbc_driver_flightsql.dbapi
import pyarrow

def task():
    with adbc_driver_flightsql.dbapi.connect("grpc://localhost:12345") as conn:
        with conn.cursor() as cur:
            cur.execute("SELECT 1")
            cur.fetch_arrow_table()

with ThreadPoolExecutor() as ex:
    while True:
        futures = [ex.submit(task) for _ in range(23)]
        for future in concurrent.futures.as_completed(futures):
            future.result()

But they're OK on a single thread.

runtime: pointer 0xc000376000 to unused region of span span.base()=0xc0001e4000 span.limit=0xc0001e5fe0 span.state=1
TL;DR: an uninitialized C Data Interface struct may happen to contain a pointer that looks like a Go pointer.  If the Go garbage collector sees this, it'll get confused and will panic:

Note: the current implementation has a bug. While Go code is permitted to write nil or a C pointer (but not a Go pointer) to C memory, the current implementation may sometimes cause a runtime error if the contents of the C memory appear to be a Go pointer. Therefore, avoid passing uninitialized C memory to Go code if the Go code is going to store pointer values in it. Zero out the memory in C before passing it to Go.  (https://pkg.go.dev/cmd/cgo)

This is very annoying to debug.
Background
The ADBC Flight SQL driver (and the Snowflake) driver are unusual in that they are implemented in Go, then wrapped in a C API and exposed to Python and other languages.
Testing concurrent usage of the Flight SQL driver turned up a crash that would take down the entire process.
The error message varied, but was generally looked like one of these two:
runtime: marked free object in span 0x7f7bc8480ba8, elemsize=24 freeindex=0 (bad use of unsafe.Pointer? try -d=checkptr)
runtime: pointer 0xc000376000 to unused region of span span.base()=0xc0001e4000 span.limit=0xc0001e5fe0 span.state=1

This almost certainly means we're violating the rules of how to use CGO and/or unsafe properly.
But where and how are we doing so?
All we seem to know is the address of an invalid pointer, not where it came from…
The Easy Suspects: GODEBUG=cgocheck=2 and -d=checkptr
As suggested, we can compile with the flag -d=checkptr.
This adds a number of checks that we're following the rules of how to use unsafe.Pointer.
We can also use GODEBUG=cgocheck=2, which adds checks that we're using CGO correctly.
Unfortunately, neither turned up anything useful.
Reading the Clues
This problem only reproduced with pyarrow 10.0.1 from conda-forge.
Curiously, even a locally-built pyarrow of the same version wouldn't fail.
But otherwise, with the given script in the original issue, it crashed reliably.

We know that because of the call to runtime.gcWriteBarrier.
Go's GC is concurrent, so writes have to cooperate with the GC so that it doesn't accidentally miss something.
When writing a pointer value to the heap, instead of directly writing the new value to memory, Go first calls out to a write barrier.
Roughly speaking (as someone who's not a compiler/languages developer), this means that we first tell the garbage collector about (1) the pointer we're about to write and (2) the pointer we're about to overwrite, before actually writing the value.
From mbarrier.go:
// 1. shade(*slot) prevents a mutator from hiding an object by moving
// the sole pointer to it from the heap to its stack. If it attempts
// to unlink an object from the heap, this will shade it.
//
// 2. shade(ptr) prevents a mutator from hiding an object by moving
// the sole pointer to it from its stack into a black object in the
// heap. If it attempts to install the pointer into a black object,
// this will shade it.

Go's compiler implements this by emitting a call to a function, runtime.gcWriteBarrier, each time we want to write a pointer value to memory.
The function stores the two pointers in a write barrier buffer for the GC to follow up on later, then does the actual write.
From mwbbuf.go:
// wbBuf is a per-P buffer of pointers queued by the write barrier.
// This buffer is flushed to the GC workbufs when it fills up and on
// various GC transitions.
//
// This is closely related to a "sequential store buffer" (SSB),
// except that SSBs are usually used for maintaining remembered sets,
// while this is used for marking.
type wbBuf struct {
	// next points to the next slot in buf. It must not be a
	// pointer type because it can point past the end of buf and
	// must be updated without write barriers.
	//
	// This is a pointer rather than an index to optimize the
	// write barrier assembly.
	next uintptr

	// end points to just past the end of buf. It must not be a
	// pointer type because it points past the end of buf and must
	// be updated without write barriers.
	end uintptr

	// buf stores a series of pointers to execute write barriers
	// on. This must be a multiple of wbBufEntryPointers because
	// the write barrier only checks for overflow once per entry.
	buf [wbBufEntryPointers * wbBufEntries]uintptr
}

const (
	// wbBufEntries is the number of write barriers between
	// flushes of the write barrier buffer.
	//
	// This trades latency for throughput amortization. Higher
	// values amortize flushing overhead more, but increase the
	// latency of flushing. Higher values also increase the cache
	// footprint of the buffer.
	//
	// TODO: What is the latency cost of this? Tune this value.
	wbBufEntries = 256

	// wbBufEntryPointers is the number of pointers added to the
	// buffer by each write barrier.
	wbBufEntryPointers = 2
)

If the buffer is full, it first jumps to the GC to check all the pointers before continuing.
Going back to the stack trace above, we're in this case, as we can see because gcWriteBarrier has jumped to wbBufFlush.
And the GC is unhappy, because one of those pointers—0xc0002ff000—is invalid.
We can confirm this by searching for the two pointers we know must exist in the Go heap.
We know that the Go heap is always at a fixed address, 0xc000000000.
From runtime/malloc.go:
		// Starting at 0x00c0 means that the valid memory addresses
		// will begin 0x00c0, 0x00c1, ...
		// In little-endian, that's c0 00, c1 00, ... None of those are valid
		// UTF-8 sequences, and they are otherwise as far away from
		// ff (likely a common byte) as possible. If that fails, we try other 0xXXc0
		// addresses. An earlier attempt to use 0x11f8 caused out of memory errors

We can see this in the debugger:
(rr) info proc map
process 1446086
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
          0x68000000         0x68200000   0x200000        0x0
          0x6fffd000         0x70001000     0x4000        0x0 /usr/lib/rr/librrpage.so
          0x70001000         0x70002000     0x1000        0x0 /tmp/rr-shared-preload_thread_locals-1446204-0
          0x70003000         0x70004000     0x1000        0x0
        0xc000000000       0xc000400000   0x400000        0x0
        0xc000400000       0xc004000000  0x3c00000        0x0
      0x55c71b4c1000     0x55c71b5b1000    0xf0000        0x0 /home/lidavidm/miniforge3/envs/arrow-bad/bin/python3.11

We can use the debugger to search for the offending address in the heap, which should be the write buffer barrier:
(rr) find /g 0xc000000000,0xc004000000,0xc0002ff000
0xc00004fd18
0xc000305000
2 patterns found.

Which one is correct?
It should be the first one.
Going back to the stack trace:
runtime.wbBufFlush1(0xc00004e000)

The implementation takes the address of a large structure that contains the write barrier buffer.
And from the Go code above, the buffer is 512 entries.
The first address is relatively close to the address in the stack trace.
The contents of memory look reasonable, too:
(rr) x/4xg 0xc00004fd10
0xc00004fd10:	0x00007f8e0c000d20	0x000000c0002ff000
0xc00004fd20:	0x000000c00003e580	0x0000000000000000

That's indeed a pair of pointers, one of which is on the C heap and one of which is the offending Go pointer.
Tracking the Culprit
You may have noticed we're using rr and not gdb to debug.
rr is like gdb, but supports time-travel debugging—you can start from where your program crashed, set breakpoints and such, and run it backwards.
Here, we'll use it to figure out who wrote this bad pointer to the write barrier buffer.
(rr) watch *0xc00004fd18
Hardware watchpoint 1: *0xc00004fd18
(rr) reverse-cont
Continuing.

Thread 2 received signal SIGABRT, Aborted.
0x0000000070000002 in syscall_traced ()
(rr) reverse-cont
Continuing.

Thread 2 hit Hardware watchpoint 1: *0xc00004fd18

Old value = 3141632
New value = 0
runtime.gcWriteBarrier () at /usr/local/go/src/runtime/asm_amd64.s:1655
1655		MOVQ	R13, -8(R12)	// Record *slot

We set a watchpoint on the address containing our bad pointer.
Then we step the program backwards a couple times…to find the write barrier!
And from the handily commented source, we know that we're recording a pointer that we're about to overwrite.
We also get a nice backtrace:
(rr) bt
#0  runtime.gcWriteBarrier () at /usr/local/go/src/runtime/asm_amd64.s:1655
#1  0x00007f8e5984092d in github.com/apache/arrow/go/v13/arrow/cdata.(*schemaExporter).finish (exp=0xc000070bf0, out=0x7f8e250f9480) at /home/lidavidm/Code/upstream/adbc/arrow-go/go/arrow/cdata/cdata_exports.go:338
#2  0x00007f8e59840c98 in github.com/apache/arrow/go/v13/arrow/cdata.exportField (field=..., out=0x7f8e250f9480) at /home/lidavidm/Code/upstream/adbc/arrow-go/go/arrow/cdata/cdata_exports.go:363
#3  0x00007f8e5983683d in github.com/apache/arrow/go/v13/arrow/cdata.ExportArrowSchema (schema=0xc0002783c0, out=0x7f8e250f9480) at /home/lidavidm/Code/upstream/adbc/arrow-go/go/arrow/cdata/interface.go:203
#4  0x00007f8e598418af in github.com/apache/arrow/go/v13/arrow/cdata.cRecordReader.getSchema (rr=..., out=0x7f8e250f9480, ~r0=<optimized out>) at /home/lidavidm/Code/upstream/adbc/arrow-go/go/arrow/cdata/cdata_exports.go:458
#5  0x00007f8e59842b8d in github.com/apache/arrow/go/v13/arrow/cdata.streamGetSchema (handle=<optimized out>, out=0x7f8e250f9480, ~r0=<optimized out>) at /home/lidavidm/Code/upstream/adbc/arrow-go/go/arrow/cdata/exports.go:129

The line numbers are off since (as part of many hours of debugging that I am omitting here) the code is modified, but here's the offending segment:
	cName := C.CString(exp.name)
	cFormat := C.CString(exp.format)
	out.name = cName
	out.format = cFormat

We're just storing a C-allocated pointer into C-allocated memory, following the CGO rules…so where did the Go pointer come from?
(rr) f 1
#1  0x00007f8e5984092d in github.com/apache/arrow/go/v13/arrow/cdata.(*schemaExporter).finish (exp=0xc000070bf0, out=0x7f8e250f9480) at /home/lidavidm/Code/upstream/adbc/arrow-go/go/arrow/cdata/cdata_exports.go:338
338		out.format = cFormat
(rr) p out
$1 = (github.com/apache/arrow/go/v13/arrow/cdata._Ctype_struct_ArrowSchema *) 0x7f8e250f9480
(rr) p *out
$2 = {format = 0xc0002ff000 "", name = 0x7f8e0c001c90 "", metadata = 0x7f8e0c001b50 "\250\324\307f\216\177", flags =<PHONE_NUMBER>78005, n_children =<PHONE_NUMBER>23072, children = 0x0, dictionary = 0x0,
  release = 0x7f8e59851479 <_cgo_release_context+21>, private_data = 0x7f8e250f9630}

Hmm, it seems our C-allocated struct already had a Go pointer inside it (as we can see from the address beginning in 0xc00…).
If you've written a lot of C/C++, alarm bells might be ringing, but let's follow things through to their conclusion.
Capturing the Culprit
We can set another watchpoint and run in reverse again, to find out who wrote 0xc0002ff000 to 0x7f8e250f9480.
(rr) reverse-cont
Continuing.
[Switching to Thread 1446086.1446098]

Thread 2 hit Hardware watchpoint 2: *0x7f8e250f9480

Old value = 3141632
New value = 0
0x00007f8e591ae7e8 in runtime.copystack (gp=0xc000204820, newsize=<optimized out>) at /usr/local/go/src/runtime/stack.go:885
885		adjinfo.old = old
(rr) si

Thread 2 hit Hardware watchpoint 2: *0x7f8e250f9480

Old value = 0
New value = 3141632
runtime.copystack (gp=0xc000204820, newsize=<optimized out>) at /usr/local/go/src/runtime/stack.go:886
886		adjinfo.delta = new.hi - old.hi
(rr) x/2xg 0x7f8e250f9480
0x7f8e250f9480:	0x000000c0002ff000	0x0000000000000000
(rr) bt
#0  runtime.copystack (gp=0xc000204820, newsize=<optimized out>) at /usr/local/go/src/runtime/stack.go:886
#1  0x00007f8e591aef37 in runtime.newstack () at /usr/local/go/src/runtime/stack.go:1114
#2  0x00007f8e591c5540 in runtime.morestack () at /usr/local/go/src/runtime/asm_amd64.s:574
#3  0x00007f8e250f9758 in ?? ()
#4  0x00007f8e6101e2c0 in ?? ()
#5  0x0000000000000000 in ?? ()

Well, there's our value.
What's going on here?
It's not really important what this code does exactly, but we're in some Go runtime code that expands stacks (since goroutine stacks are dynamically allocated), and this runtime code is using the C stack.
As part of that, it appears to have stored a value that happens to look like a Go pointer into the C stack.
We can see the stack pointer is quite close to our C Data Interface struct's address above:
(rr) p/x $rsp
$6 = 0x7f8e250f93f0

Did we allocate our ArrowSchema on the stack?
Well, yes.
Our reproducer uses pyarrow, and pyarrow builds on top of libarrow, which in version 10.0.1 would import schemas like so:
  std::shared_ptr<Schema> CacheSchema() const {
    if (!schema_) {
      struct ArrowSchema c_schema;
      ARROW_CHECK_OK(StatusFromCError(stream_.get_schema(&stream_, &c_schema)));
      schema_ = ImportSchema(&c_schema).ValueOrDie();
    }
    return schema_;
  }

We stack-allocate and do not zero-initialize an ArrowSchema.
Normally, this is fine; the code producing the schema is supposed to just blindly overwrite the existing value because it shouldn't matter.
But there's this little note in the CGO documentation:

Note: the current implementation has a bug. While Go code is permitted to write nil or a C pointer (but not a Go pointer) to C memory, the current implementation may sometimes cause a runtime error if the contents of the C memory appear to be a Go pointer. Therefore, avoid passing uninitialized C memory to Go code if the Go code is going to store pointer values in it. Zero out the memory in C before passing it to Go.  (https://pkg.go.dev/cmd/cgo)

What's the "bug"?
Well, let's go back to the write buffer barrier.
It's in assembly, but well commented and pretty straightforward:
// gcWriteBarrier performs a heap pointer write and informs the GC.
//
// gcWriteBarrier does NOT follow the Go ABI. It takes two arguments:
// - DI is the destination of the write
// - AX is the value being written at DI
// It clobbers FLAGS. It does not clobber any general-purpose registers,
// but may clobber others (e.g., SSE registers).
// Defined as ABIInternal since it does not use the stack-based Go ABI.
TEXT runtime·gcWriteBarrier<ABIInternal>(SB),NOSPLIT,$112
	// Save the registers clobbered by the fast path. This is slightly
	// faster than having the caller spill these.
	MOVQ	R12, 96(SP)
	MOVQ	R13, 104(SP)
	// TODO: Consider passing g.m.p in as an argument so they can be shared
	// across a sequence of write barriers.
	MOVQ	g_m(R14), R13
	MOVQ	m_p(R13), R13
	MOVQ	(p_wbBuf+wbBuf_next)(R13), R12
	// Increment wbBuf.next position.
	LEAQ	16(R12), R12
	MOVQ	R12, (p_wbBuf+wbBuf_next)(R13)
	CMPQ	R12, (p_wbBuf+wbBuf_end)(R13)
	// Record the write.
	MOVQ	AX, -16(R12)	// Record value
	// Note: This turns bad pointer writes into bad
	// pointer reads, which could be confusing. We could avoid
	// reading from obviously bad pointers, which would
	// take care of the vast majority of these. We could
	// patch this up in the signal handler, or use XCHG to
	// combine the read and the write.
	MOVQ	(DI), R13
	MOVQ	R13, -8(R12)	// Record *slot
	// Is the buffer full? (flags set in CMPQ above)
	JEQ	flush
ret:
	MOVQ	96(SP), R12
	MOVQ	104(SP), R13
	// Do the write.
	MOVQ	AX, (DI)
	RET

As we can see, it just stores two pointers, as advertised—the pointer we're trying to write, and the pointer we're overwriting.
It doesn't differentiate between Go and C allocated memory.
So if the C allocated memory happens to have something that looks like a Go pointer, and we apply this barrier to it…the GC gets very confused, because we've just pulled an invalid pointer from thin air.
The Solution
Now that we know what happened, we just have to somehow clear the struct before it hits Go.
That's implemented here: https://github.com/apache/arrow/pull/36670, along with some incidental fixes for things that were found as part of the testing.


Generics with 'extends' for return types cause type check failure.

TypeScript Version:  2.2.0
Code
interface I { attr: string }

type M = <T extends I>() => T
const v: M = () => ({})

v().attr

Expected behavior:
Type '() => {}' is not assignable to type 'M'.   Type '{}' is not assignable to type 'I'.
Actual behavior:
The compilation is successful.

@RyanCavanaugh is there any chance to fix assignability checks for generic and do it properly? not sure which issue tracks it (there are way to many)

Fixed by #16368.


Enforce single node-mapnik at startup?

Different or duplicated versions of C++ modules can create crashy conditions out of the blue during development. We've all hit this even if we didn't know it. Most recently @camilleanne was smartly using npm link to bring in tilelive modules into tm2 but this created multiple copies of node-mapnik in the local tree.
.
Thinking out loud: what about doing some require.cache magic at startup to try to detect multiple imported mapnik and/or sqlite3 modules at startup. This would basically move the logic used in testing (https://github.com/mapbox/tilemill/blob/master/test/duplicate_module.test.js) to startup.

done in #1202


WIP: Setup for Inference Performance Blog

/test rhoai-light kserve rhoai_inference_performance_blog_setup

/test rhoai-light kserve rhoai_inference_performance_blog_setup

/test rhoai-light kserve rhoai_inference_performance_blog_setup

Test of 'rhoai test test_ci' failed after 01 hours 28 minutes 22 seconds.

Link to the test results.
Link to the reports index.

Test configuration:
# RHOAI: run kserve test test_ci
PR_POSITIONAL_ARGS=four_l40s_g6e_12xlarge
PR_POSITIONAL_ARG_0=kserve-perf-ci
PR_POSITIONAL_ARG_1=four_l40s_g6e_12xlarge

[Test ran on the internal Perflab CI]
[TOPSAIL auto-generated message]

Test of 'rhoai test test_ci' failed after 03 hours 41 minutes 44 seconds.

Link to the test results.
Link to the reports index.

Test configuration:
# RHOAI: run kserve test test_ci
PR_POSITIONAL_ARGS=four_l40s_g6e_12xlarge
PR_POSITIONAL_ARG_0=kserve-perf-ci
PR_POSITIONAL_ARG_1=four_l40s_g6e_12xlarge

[Test ran on the internal Perflab CI]
[TOPSAIL auto-generated message]

Test of 'rhoai test test_ci' failed after 00 hours 52 minutes 04 seconds.

Link to the test results.
Link to the reports index.

Test configuration:
# RHOAI: run kserve test test_ci
PR_POSITIONAL_ARGS=four_l40s_g6e_12xlarge
PR_POSITIONAL_ARG_0=kserve-perf-ci
PR_POSITIONAL_ARG_1=four_l40s_g6e_12xlarge

[Test ran on the internal Perflab CI]
[TOPSAIL auto-generated message]

Test of 'rhoai test test_ci' succeeded after 00 hours 49 minutes 53 seconds.

Link to the test results.
Link to the reports index.

Test configuration:
# RHOAI: run kserve test test_ci
PR_POSITIONAL_ARGS=four_l40s_g6e_12xlarge
PR_POSITIONAL_ARG_0=kserve-perf-ci
PR_POSITIONAL_ARG_1=four_l40s_g6e_12xlarge

[Test ran on the internal Perflab CI]
[TOPSAIL auto-generated message]

Test of 'rhoai test test_ci' succeeded after 00 hours 55 minutes 09 seconds.

Link to the test results.
Link to the reports index.

Test configuration:
# RHOAI: run kserve test test_ci
PR_POSITIONAL_ARGS=four_l40s_g6e_12xlarge
PR_POSITIONAL_ARG_0=kserve-perf-ci
PR_POSITIONAL_ARG_1=four_l40s_g6e_12xlarge

[Test ran on the internal Perflab CI]
[TOPSAIL auto-generated message]

Test of 'rhoai test test_ci' succeeded after 01 hours 11 minutes 42 seconds.

Link to the test results.
Link to the reports index.

Test configuration:
# RHOAI: run kserve test test_ci
PR_POSITIONAL_ARGS=eight_a100_nvidia-dgx_A100_SXM4_40GB_tp_8
PR_POSITIONAL_ARG_0=kserve-perf-ci
PR_POSITIONAL_ARG_1=eight_a100_nvidia-dgx_A100_SXM4_40GB_tp_8

[Test ran on the internal Perflab CI]
[TOPSAIL auto-generated message]

Test of 'rhoai test test_ci' succeeded after 02 hours 13 minutes 23 seconds.

Link to the test results.
Link to the reports index.

Test configuration:
# RHOAI: run kserve test test_ci
PR_POSITIONAL_ARGS=eight_a100_nvidia-dgx_A100_SXM4_40GB_tp_4
PR_POSITIONAL_ARG_0=kserve-perf-ci
PR_POSITIONAL_ARG_1=eight_a100_nvidia-dgx_A100_SXM4_40GB_tp_4

[Test ran on the internal Perflab CI]
[TOPSAIL auto-generated message]


Qt4 compatibility

added Qt4 Loader compatibility

Good job :)

you review faster then I am fixing my problems made by my laziness 👍


Clicks not registered with webkit2gtk on Linux

Steps to Reproduce

Create new flutter app on beta channel
Start dev server or build app and serve it
Open url in webkit2gtk-based browser (such as Gnome Web/Epiphany)
Try to click something

Target Platform: Arch Linux (Manjaro)
Target OS version/browser: anything webkit2gtk-based
Devices: browser
Logs

▶ flutter run -d web-server --verbose
[  +18 ms] executing: [/opt/flutter/] git -c log.showSignature=false log -n 1
--pretty=format:%H
[  +32 ms] Exit code 0 from: git -c log.showSignature=false log -n 1 --pretty=format:%H
[        ] 18cd7a3601bcffb36fdf2f679f763b5e827c2e8e
[        ] executing: [/opt/flutter/] git describe --match v*.*.* --first-parent --long
--tags
[  +18 ms] Exit code 0 from: git describe --match v*.*.* --first-parent --long --tags
[        ] v1.12.13+hotfix.6-0-g18cd7a360
[   +5 ms] executing: [/opt/flutter/] git rev-parse --abbrev-ref --symbolic @{u}
[   +5 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] origin/beta
[        ] executing: [/opt/flutter/] git ls-remote --get-url origin
[   +4 ms] Exit code 0 from: git ls-remote --get-url origin
[        ] https://github.com/flutter/flutter.git
[  +37 ms] executing: [/opt/flutter/] git rev-parse --abbrev-ref HEAD
[   +7 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] beta
[  +83 ms] executing: /home/noah/Android/Sdk/platform-tools/adb devices -l
[   +7 ms] Exit code 0 from: /home/noah/Android/Sdk/platform-tools/adb devices -l
[        ] List of devices attached
[  +19 ms] Artifact Instance of 'AndroidMavenArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping
update.
[        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping
update.
[        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[   +3 ms] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping
update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping
update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping
update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping
update.
[ +124 ms] Generating
/home/noah/Documents/flutter/flutter_tauri/android/app/src/main/java/io/flutter/plugins/Gen
eratedPluginRegistrant.java
[  +63 ms] Launching lib/main.dart on Web Server in debug mode...
[        ] Building application for the web...
[+7659 ms] Starting daemon...
[ +124 ms] Initializing inputs
[  +10 ms] Reading cached asset graph...
[ +154 ms] Reading cached asset graph completed, took 152ms

[ +151 ms] Checking for updates since last build...
[ +418 ms] Checking for updates since last build completed, took 418ms

[   +8 ms] Initializing inputs
[   +1 ms] Reading cached asset graph...
[        ] Reading cached asset graph completed, took 152ms
[        ] Checking for updates since last build...
[        ] Checking for updates since last build completed, took 418ms
[ +641 ms] About to build [web]...
[   +4 ms] Running build...
[+1082 ms] 1.1s elapsed, 3/4 actions completed.
[ +279 ms] Running build completed, took 1.3s

[        ] Caching finalized dependency graph...
[   +1 ms] Caching finalized dependency graph completed, took 82ms

[   +4 ms] Succeeded after 1.4s with 8 outputs (5 actions)

[   +7 ms] Building application for the web... (completed in 10.5s)
[        ] lib/main.dart is being served at http://localhost:39195/
[   +1 ms] Warning: Flutter's support for web development is not stable yet and hasn't
[        ] been thoroughly tested in production environments.
[        ] For more information see https://flutter.dev/web
[        ] 🔥  To hot restart changes while running, press "r". To hot restart (and refresh
the
           browser), press "R".
[   +1 ms] For a more detailed help message, press "h". To quit, press "q".

▶ flutter analyze
Analyzing flutter_tauri...
No issues found! (ran in 1.4s)

▶ flutter doctor -v
[✓] Flutter (Channel beta, v1.12.13+hotfix.6, on Linux, locale en_US.UTF-8)
    • Flutter version 1.12.13+hotfix.6 at /opt/flutter
    • Framework revision 18cd7a3601 (33 hours ago), 2019-12-11 06:35:39 -0800
    • Engine revision 2994f7e1e6
    • Dart version 2.7.0

[!] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /home/noah/Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: /opt/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
    ! Some Android licenses not accepted.  To resolve this, run: flutter doctor
      --android-licenses

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[✓] Android Studio (version 3.5)
    • Android Studio at /opt/android-studio
    • Flutter plugin version 42.0.1
    • Dart plugin version 191.8593
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] Connected device (2 available)
    • Chrome     • chrome     • web-javascript • Google Chrome 79.0.3945.79
    • Web Server • web-server • web-javascript • Flutter Tools

! Doctor found issues in 1 category.

The problem seems to be that we're not detecting this browser as Webkit. Would you mind sending a pull request that fixes it for this particular browser? We're not setup to work with Epiphany.

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact descriptions what happens, logs and the output of 'flutter doctor -v'  please.
All system setups can be slightly different so its always better to open new issues and reference related issues.


Stop using _SwiftConcurrencyShims, use @_extern(c) to forward declare C functions instead

Seeking input on whether this is a good idea or not. My $0.02 is that _SwiftConcurrencyShims complicates the module story of Concurrency, and given that we now have @_extern(c), it looks like we can stop using the shim to forward declare simple C functions like exit(int) in a reliable way.

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test

Don't we need to remove the part of SwiftDeclConverter::importFunctionDecl that effectively removes exit() out of Darwin?


os: fix broken links

/cc @dgonyeo

Would there be any way to get marker to run in a CI workflow for this repo?


HTML Classes and IDs

Description 📜
I will create the documentation on HTML Classes and IDs, where I will explain the concepts in detail and provide code snippets for better understanding of the topic.

Domain of Contribution 📊

[x] Frontend Dev (HTML, CSS, JS)

/assign

/assign documentation

/assign

I created this issue. Kindly assign this to me.

/assign

/assign


Flutter Cache and Hot Reloading Hanging issue in Visual Studio

Steps to Reproduce
1.Reload 5 to 6 times in visual studio and hot reloading stops working
2.After fresh debug instance sometimes old cache is shown

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, v0.3.2, on Mac OS X 10.13.4 17E202, locale en-SG)
[!] Android toolchain - develop for Android devices (Android SDK 27.0.3)
! Some Android licenses not accepted.  To resolve this, run: flutter doctor --android-licenses
[!] iOS toolchain - develop for iOS devices (Xcode 9.3.1)
✗ libimobiledevice and ideviceinstaller are not installed. To install, run:
brew install --HEAD libimobiledevice
brew install ideviceinstaller
[✓] Android Studio (version 3.1)
[!] IntelliJ IDEA Community Edition (version 2017.2.5)
✗ Flutter plugin not installed; this adds Flutter specific functionality.
✗ Dart plugin not installed; this adds Dart specific functionality.
[✓] Connected devices (2 available)

This sounds like #17434; could you try switching to the master branch temporarily (flutter channel) and see if the problem goes away?
(Btw, there's also a new beta version that you're on if you flutter upgrade, though it doesn't have the above fix in it, you need master for that).

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


Execution Hook differences for HystrixCommand/HystrixObservableCommand

Ran into this while working on implementing #600
Currently, HystrixCommandExecutionHook has the following methods (among others):

onRunStart(HystrixInvokable<T> instance)
onRunSuccess(HystrixInvokable<T> instance, T response)
onRunError(HystrixInvokable<T> instance, Exception ex)
onStart(HystrixInvokable<T> instance)
onComplete(HystrixInvokable<T> instance, T response)
onError(HystrixInvokable<T> instance, FailureType failureType, Exception ex)

This set of methods matches well to HystrixCommand, but not HystrixObservableCommand.

HystrixCommand has a run() method, HystrixObservableCommand has construct(), so the naming feels strange
onRunSuccess conflates an emission (it contains the response) and a terminal signal.  HystrixObservableCommand may emit many values before the overall command is marked as a 'success' (an onCompleted)
onComplete also suffers this conflation

\cc @benjchristensen for thoughts on design

Here are my thoughts on how to handle this mismatch:

Deprecate onRunStart, onRunSuccess, onRunError because the name is misleading.  Keep their behavior the same
Deprecate onFallbackSuccess, onComplete because they include a value.  This is only appropriate for the single-valued case
This is the new set of un-deprecated hooks (new are bolded):

onStart(HystrixInvokable<T> commandInstance)
onError(HystrixInvokable<T> commandInstance, FailureType failureType, Exception e)
onSuccess(HystrixInvokable<T> commandInstance)
onThreadStart(HystrixInvokable<T> commandInstance)
onThreadComplete(HystrixInvokable<T> commandInstance)
onExecutionStart(HystrixInvokable<T> commandInstance)
onExecutionEmit(HystrixInvokable<T> commandInstance, T value)
onExecutionError(HystrixInvokable<T> commandInstance, Exception e)
onExecutionSuccess(HystrixInvokable<T> commandInstance)
onFallbackStart(HystrixInvokable<T> commandInstance)
onFallbackEmit(HystrixInvokable<T> commandInstance, T value)
onFallbackError(HystrixInvokable<T> commandInstance, Exception e)
onFallbackSuccess(HystrixInvokable<T> commandInstance)
onCacheHit(HystrixInvokable<T> commandInstance)

I think that's good.

Completed in #683


MaxListenersExceededWarning showing everytime I call a function

Describe the bug
Everytime I call a function I get hundreds of lines saying MaxListenersExceededWarning which makes debugging impossible because console.logs are completely buried. It was supposed to be fixed by https://github.com/netlify/cli/issues/717 but it is not.

To Reproduce
Steps to reproduce the behavior:

Run netlify dev
Call any lambda function with console.log()
Console.log() is not visible as the whole terminal is filled with MaxListenersExceededWarning

Configuration
My netlify.toml
[build]
  functions = "lambda"
  publish = "dist"
  command = "npm run build && npm run build:lambda"

[[headers]]
  for = "/*"
  [headers.values]
    #  Multi-value headers are expressed with multi-line strings
	  cache-control = '''
    private,
	  max-age=3600'''

npx output
npx: installed 1 in 1.465s

  System:
    OS: Windows 10 10.0.19042
    CPU: (8) x64 Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
    Memory: 4.41 GB / 15.60 GB
  Binaries:
    Node: 12.20.0 - C:\Program Files\nodejs\node.EXE
    npm: 6.14.4 - C:\Program Files\nodejs\npm.CMD

I am using netlify-cli/2.70.0 win32-x64 node-v12.20.0
Expected behavior
There should be no warnings about memory leak

Is anyone looking into this? It makes any kind of debugging impossible especially when netlify-lambda doesn't generate sourcemaps that would allow proper debugging in VS Code.

Hi @michalhudecek sorry for the delay.
I can't reproduce it by adding console.log to a function, so this might be related netlify-lambda or something more specific.

I cannot share the repo. Yes, it is connected to netlify lambda. Is there anything else beyond the repo itself that would help you? Some kind of log?

Hi @michalhudecek, maybe share the function's code and netlify-labmda setup? An example repo (doesn't have to be your repo, just any public repo with the issue) will help figure out the underlying issue much faster.

@erezrokah What do you mean by netlify-lambda setup? I have only netlify.toml file I already posted in the description of the issue. I didn't set up anything else. I just run netlify dev and the functions are automatically build. I also posted npx output in the description.
We have around 15 netlify lambda functions of various complexity, all of them has the same issue. This is an example of a simple function that generates hundreds of memory leaks in the console. It does the same on Windows, Mac and Linux. All of our programmers have the same issue.
/* eslint-disable no-console */
import axios from "axios";
import { getIndexId } from "./constants/index";
import { getViewsPayload } from "./functions/index";

const elasticHost = process.env.ELASTIC_HOST;
const elasticUser = process.env.ELASTIC_USER;
const elasticPassword = process.env.ELASTIC_PASSWORD;

import * as Sentry from "@sentry/node";
const { initSentry } = require("./functions/sentry.js");
initSentry();

exports.handler = async (event, context) => {
  const docId = event.queryStringParameters["id"];

  const url = new URL(event.headers.referer);
  let indexId = event.queryStringParameters["index"];
  if (indexId !== "sellers") {
    indexId = getIndexId(url.hostname, indexId);
  }

  Sentry.configureScope(scope => {
    scope.setLevel("error");
    scope.setTag("endpoint", "doc");
    scope.setExtra("docId", docId);
    scope.setExtra("index", indexId);
    scope.setExtra("httpMethod", event.httpMethod);
  });

  let responseData;
  try {
    const elasticResponse = await axios.get(
      `${elasticHost}/${indexId}/_doc/${docId}`,
      {
        auth: {
          username: elasticUser,
          password: elasticPassword
        },
        headers: {
          "Content-Type": "application/json"
        }
      }
    );
    responseData = { ...elasticResponse.data };
    // Remove restricted data
    delete responseData._source.restrictedData;
  } catch (error) {
    console.log(error);
    Sentry.captureMessage(error);
    return {
      statusCode: 400,
      body: JSON.stringify(error)
    };
  }
  try {
    const payload = getViewsPayload(url, responseData._source);
    await axios.post(`${elasticHost}/${indexId}/_update/${docId}`, payload, {
      auth: {
        username: elasticUser,
        password: elasticPassword
      },
      headers: {
        "Content-Type": "application/json"
      }
    });
  } catch (error) {
    Sentry.captureMessage(error);
    return {
      statusCode: 400,
      body: JSON.stringify(error)
    };
  }
  return {
    statusCode: 200,
    headers: {
      "content-type": "application/json; charset=utf-8"
    },
    body: JSON.stringify(responseData)
  };
};

Hi @michalhudecek and sorry for the delay to respond. I tried reproducing this issue in https://github.com/erezrokah/netlify-build-reproductions/blob/cli/issue_1701/functions/index.js#L15 by using your function as a reference and adding the missing env variables per the best of my ability.
I tried sending a request to the function and wasn't able to get the same error, so I'm probably missing a lot of the configuration you have.
Providing a public repo with a reproduction will make it much easier to debug and identify the cause.
For debugging in VSCode does the suggestion here work for you?
Also you should be able to generate source maps by using a custom webpack config.

Hi @erezrokah. I am not sure what could be causing it. Unfortunately, I cannot share it publicly. I could maybe share it in a call.
None of the mentioned suggestions worked for me. I just run netlify dev, nothing else. I have no influence on how netlify-lambda is called from there.

Hi @michalhudecek, to clarify - I'm not asking you to share private code.
I'm suggesting you create a public repo reproducing the issue per our issue reporting guidelines.
The purpose of doing that is that we can reproduce the issue in our environment and also if anyone else is experiencing is they can contribute.

After running netlify dev --inspect I found out that the errors are coming from sentry/node package
I reported the issue to Sentry https://github.com/getsentry/sentry-javascript/issues/3247, closing this issue here.

Thank you for the follow up @michalhudecek!

It was actually a bug in netlify-cli after all. Got fixed by upgrading to https://github.com/netlify/cli/releases/tag/v5.2.0


chore(main): release 0.17.0

:robot: I have created a release beep boop
0.17.0 (2024-11-21)
Features

add support for Dart-Code.dart-code (4baa9d2)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.17.0
:sunflower:


Proposal: GraphQL File Upload

Summary
Implement the file upload for the Ballerina GraphQL package. The GraphQL file upload can be used to upload the files via GraphQL endpoints.
Goals

Provide a way to upload files via GraphQL endpoints.

Motivation
Although the GraphQL specification doesn’t specify the file uploading,  this might be an essential feature for some of the GraphQL use cases. Most of the prominent GraphQL implementations have introduced the file uploading feature and there are several specifications for that as well. This proposal is also referring such a specification to structure the Multipart Request. With this feature, the GraphQL endpoints are able to accept the Multipart Request coming from the client. GraphQL User will be able to access all the details of the file receiving via Multipart Request.
Description
As mentioned in the Goals section, the purpose of this proposal is to provide a way to upload files to a GraphQL endpoint using the Ballerina GraphQL package. In order to fulfill the requirement, GraphQL mutation query can be used with HTTP multipart request. GraphQL endpoints can accept the multipart request which includes file information. This multipart request should be in the form described in the Multipart Request section. With this request format, the user will be able to send files into the GraphQL endpoint.
GraphQL module provides graphql:FileUpload type described in graphql:FileUpload section, to represent the file information within the resolvers. Graphql library is able to process the Multipart request receiving to the GraphQL endpoint and extract a graphql:FileUpload type value from the request. The GraphQL multipart request handler resolves the request and populates the value of type graphql:FileUpload. If an error occurred while processing the request, it’ll be returned without further processing.  The values populated without any error, pass along with the GraphQL document to continue the execution. The developer will be able to use these graphql:FileUpload type values within the resolvers to extract the file information. Extracted file information can be used to store the file using custom logic.
The high-level architecture of the proposed design is as follows:

The graphql:FileUpload type
The graphql:FileUpload will be defined as a record type in the Ballerina GraphQL module. Following are the fields of the graphql:FileUpload type.
type FileUpload record {
    string fileName;
    string mimeType;
    string encoding;
    stream<byte[], Error?> byteStream;
}

Field
Type
Description

fileName
string
Name of the file

mimeType
string
File Mime type according to the file content

encoding
string
File stream encoding

byteStream
stream<byte[], Error?>
File content as a stream of byte[]

Multipart Request
HTTP Multipart Request for GraphQL file upload consists of the following fields.

Operations - The field includes JSON-encoded body of standard GraphQL POST requests where all the variable values related to file upload are null.“Operations“: { "query": "mutation($file: FileUpload!) { fileUpload(files: $file) { link }", "variables": {"file": null} }

Map - JSON-encoded map of paths of the file that occurred in the operation. Map key is the name of the file in multipart request and the value is an array of paths.“Map”: { “0”: ["variables.file"] },

File - The field includes the file with a unique name.

Sample curl request for single file upload:
curl localhost:9090/graphql \
  -F operations='{ "query": "mutation($file: graphql:FileUpload!) { fileUpload(file: $file) { link } }", "variables": { "file": null } }' \
  -F map='{ "0": ["variables.file"] }' \
  -F<EMAIL_ADDRESS>
Sample curl request for multiple file upload:
curl localhost:9090/graphql \
  -F operations='{ "query": "mutation($file: [graphql:FileUpload!]) { filesUpload(file: $file) { link } }", "variables": { "file": [null, null] } }' \
  -F map='{ "0": ["variables.file"], "1": ["variables.file"]}' \
  -F<EMAIL_ADDRESS>  -F<EMAIL_ADDRESS>
Using the graphql:FileUpload type in the Resolvers
The graphql:FileUpload can be used as the parameter type of resolver function to handle the file uploading process. Following is an example:

Note: To implement the logic of the file uploading process, the developer may have to import the Ballerina io library into the service.

remote function fileUpload(graphql:FileUpload file) returns string|error {
    string fileName fileName = file.fileName;
    stream<byte[], Error?> byteStream = file.byteStream;
    string path = string`./files/${fileName}.png`;
    check io:fileWriteBlocksFromStream(path, byteStream);
    return "Successfully Uploaded"
}

+1. I think this proposal covers all the aspects of the feature.

Just to confirm, in the case of multiple file uploads, we simply do the below right ?
remote function multipleFileUpload(graphql:FileUpload[] files) returns string|error {}

Just to confirm, in the case of multiple file uploads, we simply do the below right ?
remote function multipleFileUpload(graphql:FileUpload[] files) returns string|error {}

yes.


I can uplift the frontend technologies.

I can upgrade the frontend to make it more attractive and effective .

okay.All the Best!!

Thanks a lot.


Upgrade CRDs by Helm

Describe the feature
We can install Capsule and Capsule Proxy easily with Helm, however, Helm doesn't manage the upgrade of CRDs. See here.
What would the new user story look like?
In order to let Helm to manage CRDs, it's nice to use two charts approach to do so.
Like,
resource "helm_release" "capsule-proxy-crds" {
  depends_on = [
    helm_release.capsule,
  ]

  name             = "capsule-proxy"
  repository       = "https://projectcapsule.github.io/charts"
  chart            = "capsule-proxy-chart"
  version          = "0.7.0"
  namespace        = "capsule-system"
  create_namespace = false
  atomic           = true
  cleanup_on_fail  = true
  values = [
    file("${path.module}/capsule-proxy-values.yaml"),
  ]
}

resource "helm_release" "capsule-proxy" {
  depends_on = [
    helm_release.capsule,
  ]

  name             = "capsule-proxy"
  repository       = "https://projectcapsule.github.io/charts"
  chart            = "capsule-proxy"
  version          = "0.7.0"
  namespace        = "capsule-system"
  create_namespace = false
  atomic           = true
  cleanup_on_fail  = true
}

Expected behavior
A specific Helm chart for the CRDs is required.

Poking here @oliverbaehler since took care of this, but it seems to me we're already overcoming Helm limitations about CRDs lifecycle.
https://github.com/projectcapsule/capsule-proxy/blob/f4608891984bb692dace74f67789cc1435e9b1af/charts/capsule-proxy/values.yaml#L5-L10
Furthermore, a detailed way to handle these updates has been documented with the v0.7.0 release: https://github.com/projectcapsule/capsule-proxy/tree/main/charts/capsule-proxy#07x
If you haven't tried this flow I'd say it would be great if you could try it by reporting any issue you encountered.
Otherwise, let's close this feature, mostly because I would like to keep the Issue section only for confirmed bug reports.

Thanks @prometherion , happy to close it. Seems crds.install: true is what I need for both installation and upgrade. ❤


Recognize -q flag and the QUIET variable

From psql manual:

-q
--quiet
Specifies that psql should do its work quietly. By default, it prints welcome messages and various informational output. If this option is used, none of this happens. This is useful with the -c option. This is equivalent to setting the variable QUIET to on.

Fixed in 7714c9dc25e346d59c5c5f02c6adddb7d4ae35d8


TSM conversion tool improvements

I updated the tool to properly limit parallelism in the conversion tool.
I am also in the process of cleaning up some of the rough edges (log.Print then os.Exit(1) instead of log.Fatal,  etc) to prepare for regular status update outputs. The current command will just tell you that it started doing something, and sit in silence until each shard is complete.
My thoughts were to just print regular status updates to include things like:

complete shards vs. total shards
currently processing shards
total wall time spent

I am seeing a huge slowdown when I run the conversion tool on a spinning disk, even for a 1GB shard. The IO read was topping out at ~500KB/s and the process was in IO wait >95% of the time. I'm going to do some profiling to see if I can improve that at all (possibly even just caching the file in memory if we can).

Tests are failing w/
ok  	github.com/influxdb/influxdb/cmd/influx/cli	0.026s
# github.com/influxdb/influxdb/cmd/influx_tsm
cmd/influx_tsm/converter_test.go:14: undefined: scrubValues
cmd/influx_tsm/converter_test.go:23: undefined: scrubValues
cmd/influx_tsm/converter_test.go:32: undefined: scrubValues
cmd/influx_tsm/converter_test.go:41: undefined: scrubValues

D'oh... I'll get that fixed.

:+1:


Permissions

Related Issue:
https://github.com/rancher/rancher/issues/40251
Checklist
Please fill out this table to identify which fields need to be modified in your PR.
Under Status, either indicate Does Not Apply or Added to this PR.

Version to be incremented
Why should this be modified?
Status

version in rancher-project-monitoring package.yaml
You modified the contents of the rancher-project-monitoring chart to make changes
Added to this PR

helmProjectOperator.image.tag in prometheus-federator values.yaml
Either you modified the rancher-project-monitoring chart or you modified the main.go file
Does Not Apply

appVersion in prometheus-federator Chart.yaml
You modified the helmProjectOperator.image.tag in the above box
Does Not Apply

version in prometheus-federator Chart.yaml
Either you modified the appVersion in the above box or you modified the contents of the prometheus-federator chart to make changes
Does Not Apply

closing in favor of https://github.com/rancher/prometheus-federator/pull/76


[gdcm] no absolute paths

For #20469

vcpkg_fail_port_install has been deprecated, could you please remove it in portfile.cmake?

Thanks!


Catch doesn't download automatically.

Make sure to do the following before submitting your issue - thanks!

[X] Make sure you're running the latest release. You can find your version number at the bottom of the Help menu in Catch.
[X] Check the FAQ, your question might be answered there.
[X] Check for an open issue, and please comment on that issue instead of creating a duplicate.

Catch doesn't download automatically.  I'm on the last version, compiled myself. It used to work …

There's only two reasons for the Skipped status, both user-fixable:

The Save to: folder from Preferences is missing not writable (if you build yourself, you might need to re-select it and give permission)
You have no feeds in Preferences


Configuring persistence plugins at runtime

Follow up on https://github.com/apache/pekko/issues/1513.
Implementing persistence plugin configuration at runtime for this project will require changes to implementation and configuration. Because the required changes are not trivial and there potentially are multiple ways to approach them, I am going to give more context and propose what I think is the simplest solution.
Current behavior
Configuration for persistence plugins is provided roughly as follows:
pekko.persistence.r2dbc {
  journal {
    class = "org.apache.pekko.persistence.r2dbc.journal.R2dbcJournal"

    # other settings
  }
}

pekko.persistence.r2dbc {
  snapshot {
    class = "org.apache.pekko.persistence.r2dbc.snapshot.R2dbcSnapshotStore"

    # other settings
  }
}

pekko.persistence.r2dbc {
  state {
    class = "org.apache.pekko.persistence.r2dbc.state.R2dbcDurableStateStoreProvider"

    # other settings
  }
}

pekko.persistence.r2dbc {
  query {
    class = "org.apache.pekko.persistence.r2dbc.query.R2dbcReadJournalProvider"

    # other settings
  }
}

pekko.persistence.r2dbc {
  dialect = “postgres”

  connection-factory {
    host = "localhost"
    port = 5432
    database = "postgres"
    user = "postgres"
    password = "postgres"
  }

  # other settings
}

The way this config is used is that journal, query, snapshot and state plugins take this whole config from the ActorSystem, pick their specific configuration from one of the branches - pekko.persistence.r2dbc.journal, pekko.persistence.r2dbc.query, etc. - and then pick the shared configuration - like database connection settings - from parent path of pekko.persistence.r2dbc. Additionally, journal plugin is the only plugin that directly depends on another plugin - it uses the query plugin for replay of events.
Problems with current behavior
There are two problems with this implementation that makes it incompatible with how runtime plugin configuration works:

Persistence plugins do not use config that is passed to them, instead taking the config from the ActorSystem.
https://github.com/apache/pekko-persistence-r2dbc/blob/553752fc82c15695e52c8db7627a48b1ec14bd3c/core/src/main/scala/org/apache/pekko/persistence/r2dbc/journal/R2dbcJournal.scala#L97
Constructor argument config is not used in current implementation. This can be observed in implementations of all plugins.

Journal plugin does not pass dynamic configuration to the query plugin that it instantiates.
https://github.com/apache/pekko-persistence-r2dbc/blob/553752fc82c15695e52c8db7627a48b1ec14bd3c/core/src/main/scala/org/apache/pekko/persistence/r2dbc/journal/R2dbcJournal.scala#L100
PersistenceQuery has a separate readJournalFor method that accepts configuration as the second parameter and this method is not used here.

Expected behavior
Expectation is simply that persistence plugins should actually use the config that is provided to them via constructor instead of using the config from the ActorSystem.
Proposed solution

Use configuration from config constructor argument in persistence plugins.
There are few changes required to make this work. Configuration that is passed through this argument has certain constraints, for example it has to have a class attribute equals to the FQCN of the class implementing chosen plugin. Essentially it must be the plugin specific branch of the config - pekko.persistence.r2dbc.journal, pekko.persistence.r2dbc.query, etc., which means that shared configuration can no longer be defined at parent path level, because this will not get passed with config argument. So the solution would be just that - to move in the shared config into each of the plugin branches:
pekko.persistence.r2dbc {
  journal {
    class = "org.apache.pekko.persistence.r2dbc.journal.R2dbcJournal"
    shared = ${pekko.persistence.r2dbc.shared}

    # other settings
  }
}

pekko.persistence.r2dbc {
  snapshot {
    class = "org.apache.pekko.persistence.r2dbc.snapshot.R2dbcSnapshotStore"
    shared = ${pekko.persistence.r2dbc.shared}

    # other settings
  }
}

pekko.persistence.r2dbc {
  state {
    class = "org.apache.pekko.persistence.r2dbc.state.R2dbcDurableStateStoreProvider"
    shared = ${pekko.persistence.r2dbc.shared}

    # other settings
  }
}

pekko.persistence.r2dbc {
  query {
    class = "org.apache.pekko.persistence.r2dbc.query.R2dbcReadJournalProvider"
    shared = ${pekko.persistence.r2dbc.shared}

    # other settings
  }
}

pekko.persistence.r2dbc.shared {
  dialect = “postgres”

  connection-factory {
    host = "localhost"
    port = 5432
    database = "postgres"
    user = "postgres"
    password = "postgres"
  }

  # other settings
}

This change will also require split of R2dbcSettings:
https://github.com/apache/pekko-persistence-r2dbc/blob/553752fc82c15695e52c8db7627a48b1ec14bd3c/core/src/main/scala/org/apache/pekko/persistence/r2dbc/R2dbcSettings.scala#L40-L75
Because one plugin branch will not contain other plugin branches, this class will need to be split to a class per plugin, potentially with shared config expressed through an attribute of a common type:
class R2dbcJournalSettings(
  journalTable: String,
  shared: R2dbcSharedSettings
  // journal specific settings
)

class R2dbcJournalSettings(
  snapshotsTable: String,
  shared: R2dbcSharedSettings
  // other snapshot specific settings
)

// other classes for other plugins

class R2dbcSharedSettings(
  dialect: Dialect,
  schema: String
  // other shared settings
)

Journal plugin should not depend on query plugin.
This will simplify the config for journal plugin, because it will not have to dynamically initialize query plugin. The functionality that is common between journal and query plugins - fetching of events by persistence ID - can just be moved to a common trait/class that both plugins depend on.

With this solution implemented the runtime plugin configuration would be used as follows:
// provide the whole config for required plugins
val config = ConfigFactory
  .parseString("""
    runtime1 {
      journal {
        class = "org.apache.pekko.persistence.r2dbc.journal.R2dbcJournal"
        shared = ${runtime1.shared}

        # other settings
      }

      snapshot {
        class = "org.apache.pekko.persistence.r2dbc.snapshot.R2dbcSnapshotStore"
        shared = ${runtime1.shared}

        # other settings
      }

      shared = {
        dialect = "postgres"

        connection-factory {
          database = "runtime1_database"

          # other settings
        }
      }
    }
  """)
  .resolve()

// or do overrides for defaults
val config = ConfigFactory
  .parseString("""
    runtime1 {
      journal = ${pekko.persistence.r2dbc.journal}
      journal.shared = ${runtime1.shared}

      snapshot = ${pekko.persistence.r2dbc.snapshot}
      snapshot.shared = ${runtime1.shared}

      shared = ${pekko.persistence.r2dbc.shared}
      shared = {
        dialect = "postgres"

        connection-factory {
          database = "runtime1_database"
        }
      }
    }
  """)
  .withFallback(ConfigFactory.load())
  .resolve()

EventSourcedBehavion...
  .withJournalPluginId("runtime1.journal")
  .withJournalPluginConfig(config)
  .withSnapshotPluginId("runtime1.snapshot")
  .withSnapshotPluginConfig(config)

Please share your thoughts on the proposed solution. Is it good to go as is or are there any aspects that need improvement? The only problem I see right now is that both binary and source compatibility look like a major pain to preserve. @pjfanning, pinging you since you have participated in this development.

We recently released 1.1.0-M1 as a preview. It has been suggested that the changes are already big enough to justify us calling it 2.0.0 when it gets around to a full release.
https://lists.apache.org/thread/zhg8ptrh3m5jo24zmz4n3t7jtvfvhss5
This is not a heavily used module and if the changes are easy enough to uptake then I don't mind fairly large changes.

Sounds great!
Looking at the version history and the state of code it feels like 1.0.0 releases for both Akka and Pekko versions of this project were about license changes and not the source being ready semver-wise, so going for a major release gives us an opportunity to prepare the repository for easier management of compatibility guarantees going forward.

Note that the proposed changes to configuration will also affect how ConnectionFactoryProvider behaves - connection factories are identified by config path, so currently all plugins share single connection factory because for all of them the path is pekko.projection.r2dbc.connection-factory, after the proposed changes this will break in two ways:

Config paths that plugins pass for connection factory identity will become pekko.projection.r2dbc.journal.connection-factory, pekko.projection.r2dbc.query.connection-factory, etc. - that will force separate connection factories.

This can be fixed by providing a similar solution to how it is done in JDBC plugin - https://pekko.apache.org/docs/pekko-persistence-jdbc/current/configuration.html#sharing-the-database-connection-pool-between-the-journals.

Runtime config will not be applied because ConnectionFactoryProvider loads the config from the ActorSystem:
https://github.com/apache/pekko-persistence-r2dbc/blob/553752fc82c15695e52c8db7627a48b1ec14bd3c/core/src/main/scala/org/apache/pekko/persistence/r2dbc/ConnectionFactoryProvider.scala#L94

This can be fixed by creating a method in ConnectionFactoryProvider that allows providing config for the connection factory that is to be created.


Current dynlib-only approach might be insufficient, need header

Table of Contents

The initial Nim program
The same code in C
Comparing the PTX
Generate the CUBIN
A CUBIN loader & runner in C
A CUBIN loader in Nim
A standalone example
Applying this to nimcuda

NOTE: I've written the below probably more for myself than anyone
else, to understand what I actually did to figure out what the heck
went wrong.
I'm prefacing this issue by saying that I may be missing
something. But I've come to the conclusion that our current approach
of wrapping CUDA is fundamentally flawed, because we only use cdecl,
importc and dynlib. I think we must use header: "foo.h" in
addition.
Essentially, I've been toying around a lot with nimcuda the last
week. I've essentially written a tiny macro DSL to Nim "compile-time
compile" Nim code to a CUDA string. At some point I tried to just
insert a printf into the CUDA code, which is nowadays possible. A
single printf breaks the library.
Over quite a few hours I've now finally nailed it down to the omission
of the header pragma.
In short, I'm able to load a CUBIN file in C, compile via gcc and
have it load & run successfully. However, loading the identical file
from a (seemingly identical) Nim program causes a
CUDA_ERROR_INVALID_IMAGE error.

The initial Nim program
Let's start by looking at the (ultra reduced and basic) Nim program,
which succeeds / fails with nimcuda depending on whether a printf
is present.
import nimcuda/cuda12_5/[nvrtc, check, cuda]

const kernel_source = """
extern "C" __global__ void warpTest(int* output) {
    printf("hello"); // comment out the printf and it works
    int tid = ((blockIdx.x * blockDim.x) + threadIdx.x);
    if (blockDim.x == 32) {
        output[tid] = 1;
    }
}
"""

proc main =
  # Initialize CUDA
  var res = cuInit(0)
  if res != CUDA_SUCCESS:
    var error_str: cstring
    check cuGetErrorString(res, cast[cstringArray](addr error_str))
    echo "CUDA init failed: ", error_str
    quit(1)

  var device: CUdevice
  var context: CUcontext
  res = cuDeviceGet(addr device, 0)
  if res != CUDA_SUCCESS: quit(1)
  res = cuCtxCreate(addr context, 0, device)
  if res != CUDA_SUCCESS: quit(1)

  # Create program
  var prog: nvrtcProgram
  var compileResult = nvrtcCreateProgram(addr prog, kernel_source,
                                        "kernel.cu", 0, nil, nil)
  if compileResult != NVRTC_SUCCESS:
    echo "Program creation failed"
    quit(1)

  # Compile
  const opts = [cstring "--gpu-architecture=sm_61"]
  compileResult = nvrtcCompileProgram(prog, 1, cast[cstringArray](addr opts[0]))
  if compileResult != NVRTC_SUCCESS:
    var logSize: csize_t
    check nvrtcGetProgramLogSize(prog, addr logSize)
    var log = newString(logSize)
    check nvrtcGetProgramLog(prog, cstring log)
    echo "Compilation failed: ", log
    quit(1)

  # Get PTX
  var ptxSize: csize_t
  check nvrtcGetPTXSize(prog, addr ptxSize)
  var ptx = newString(ptxSize)
  check nvrtcGetPTX(prog, cstring ptx)

  writeFile("kernel_nim.ptx", ptx)

  # Load module
  var modul: CUmodule
  res = cuModuleLoadData(addr modul, cstring ptx)
  if res != CUDA_SUCCESS:
    var error_str: cstring
    check cuGetErrorString(res, cast[cstringArray](addr error_str))
    echo "Module load failed: ", error_str
    quit(1)

  # Get function
  var kernel: CUfunction
  res = cuModuleGetFunction(addr kernel, modul, "warpTest")
  if res != CUDA_SUCCESS: quit(1)

  # Allocate memory
  var dOutput: CUdeviceptr
  res = cuMemAlloc(addr dOutput, sizeof(cint) * 32)
  if res != CUDA_SUCCESS: quit(1)

  # Launch kernel
  var args = [cast[pointer](addr dOutput)]
  res = cuLaunchKernel(kernel,
                       1, 1, 1,    # grid
                       32, 1, 1,   # block
                       0, nil,       # shared mem, stream
                       addr args[0], nil) # args, extra
  if res != CUDA_SUCCESS:
    var error_str: cstring
    check cuGetErrorString(res, cast[cstringArray](addr error_str))
    echo "Kernel launch failed: ", error_str
    quit(1)

  check cuCtxSynchronize()

  # Cleanup
  check cuMemFree(dOutput)
  check cuModuleUnload(modul)
  check cuCtxDestroy(context)

main()

Depending on whether the printf line is present in the CUDA kernel
the code either succeeds or breaks.
We save the PTX to a file kernel_nim.ptx so that we can compile it to CUBIN using
nvlink.

The same code in C
Here's the exact same code from C. We write a kernel_c.ptx file in
this case. It works perfectly fine with and without the printf
statement being present.
#include <cuda.h>
#include <nvrtc.h>
#include <stdio.h>

const char* kernel_source = R"(
extern "C" __global__ void warpTest(int* output) {
    printf("hello"); // works with and without printf!
    int tid = ((blockIdx.x * blockDim.x) + threadIdx.x);
    if (blockDim.x == 32) {
        output[tid] = 1;
    }
}
)";

int main() {
    // Initialize CUDA
    CUresult res = cuInit(0);
    if (res != CUDA_SUCCESS) {
        const char* error_str;
        cuGetErrorString(res, &error_str);
        printf("CUDA init failed: %s\n", error_str);
        return 1;
    }

    CUdevice device;
    CUcontext context;
    res = cuDeviceGet(&device, 0);
    if (res != CUDA_SUCCESS) return 1;
    res = cuCtxCreate(&context, 0, device);
    if (res != CUDA_SUCCESS) return 1;

    // Create program
    nvrtcProgram prog;
    nvrtcResult compileResult = nvrtcCreateProgram(&prog, kernel_source,
                                                  "kernel.cu", 0, NULL, NULL);
    if (compileResult != NVRTC_SUCCESS) {
        printf("Program creation failed\n");
        return 1;
    }

    // Compile
    const char* opts[] = {"--gpu-architecture=sm_61"};
    compileResult = nvrtcCompileProgram(prog, 1, opts);
    if (compileResult != NVRTC_SUCCESS) {
        size_t logSize;
        nvrtcGetProgramLogSize(prog, &logSize);
        char* log = malloc(logSize);
        nvrtcGetProgramLog(prog, log);
        printf("Compilation failed: %s\n", log);
        free(log);
        return 1;
    }

    // Get PTX
    size_t ptxSize;
    nvrtcGetPTXSize(prog, &ptxSize);
    char* ptx = malloc(ptxSize);
    nvrtcGetPTX(prog, ptx);

    printf("PTX size: %zu\n", ptxSize);
    printf("PTX start: %.100s\n", ptx);

    FILE* f = fopen("kernel_c.ptx", "w");
    fwrite(ptx, 1, ptxSize, f);
    fclose(f);

    // Load module
    CUmodule module;
    res = cuModuleLoadData(&module, ptx);
    if (res != CUDA_SUCCESS) {
        const char* error_str;
        cuGetErrorString(res, &error_str);
        printf("Module load failed: %s\n", error_str);
        return 1;
    }

    // Get function
    CUfunction kernel;
    res = cuModuleGetFunction(&kernel, module, "warpTest");
    if (res != CUDA_SUCCESS) return 1;

    // Allocate memory
    CUdeviceptr d_output;
    res = cuMemAlloc(&d_output, sizeof(int) * 32);
    if (res != CUDA_SUCCESS) return 1;

    // Launch kernel
    void* args[] = {&d_output};
    res = cuLaunchKernel(kernel,
                        1, 1, 1,    // grid
                        32, 1, 1,   // block
                        0, 0,       // shared mem, stream
                        args, 0);   // args, extra
    if (res != CUDA_SUCCESS) {
        const char* error_str;
        cuGetErrorString(res, &error_str);
        printf("Kernel launch failed: %s\n", error_str);
        return 1;
    }

    res = cuCtxSynchronize();
    if (res != CUDA_SUCCESS) return 1;

    // Cleanup
    free(ptx);
    cuMemFree(d_output);
    cuModuleUnload(module);
    cuCtxDestroy(context);

    return 0;
}

We compile this file with:
gcc -I/usr/local/cuda-12.6/targets/x86_64-linux/include -L/usr/local/cuda-12.6/targets/x86_64-linux/lib -o rt_printf rt_printf.c -lcuda -lnvrtc

Comparing the PTX
While you have to believe me now, the generated PTX is identical. So
from here on we'll just continue from a CUBIN file.

Generate the CUBIN
To generate the CUBIN from the PTX file:
nvlink -m64 --arch=sm_61 kernel_nim.ptx -lcudadevrt -o kernel_nim.cubin

Obviously, given that the PTX is the same, the generated CUBIN is the
same too.

A CUBIN loader & runner in C
Let's look at a simple loader a CUBIN file and execute that kernel in
C:
#include <cuda.h>
#include <stdio.h>

int main() {
    CUdevice device;
    CUcontext context;
    CUmodule module;
    CUfunction kernel;
    CUdeviceptr output;

    // Init
    cuInit(0);
    cuDeviceGet(&device, 0);
    cuCtxCreate(&context, 0, device);

    // Load the CUBIN
    if (cuModuleLoad(&module, "kernel_nim.cubin") != CUDA_SUCCESS) {
        printf("Failed to load module\n");
        return 1;
    }

    if (cuModuleGetFunction(&kernel, module, "warpTest") != CUDA_SUCCESS) {
        printf("Failed to get function\n");
        return 1;
    }

    // Allocate GPU memory
    cuMemAlloc(&output, sizeof(int) * 32);

    // Launch kernel
    void* args[] = {&output};
    cuLaunchKernel(kernel,
                   1, 1, 1,    // Grid dimensions
                   32, 1, 1,   // Block dimensions
                   0, 0,       // Shared memory and stream
                   args, 0);   // Arguments and extra

    cuCtxSynchronize();

    // Optional: read back results
    int host_output[32];
    cuMemcpyDtoH(host_output, output, sizeof(int) * 32);

    // Print first few results
    for(int i = 0; i < 10; i++) {
        printf("%d ", host_output[i]);
    }
    printf("\n");

    // Cleanup
    cuMemFree(output);
    cuModuleUnload(module);
    cuCtxDestroy(context);

    return 0;
}

Compiling and running it
gcc -I/usr/local/cuda-12.6/targets/x86_64-linux/include -L/usr/local/cuda-12.6/targets/x86_64-linux/lib -o execute_cubin execute_cubin.c -lcuda

works perfectly fine. So the "Nim generated" kernel runs perfect,
despite not being loadable from Nim.

A CUBIN loader in Nim
Now we come to something closer to a reduced example. Here's the same
code as the C version from Nim:
import nimcuda/cuda12_5/[cuda, check]

proc main =
  var device: CUdevice
  var context: CUcontext
  var modul: CUmodule
  var kernel: CUfunction
  var output: CUdeviceptr

  # Init
  check cuInit(0)
  check cuDeviceGet(addr device, 0)
  check cuCtxCreate(addr context, 0, device)

  # Load the CUBIN
  let res = cuModuleLoadData(addr modul, cstring "kernel_nim.cubin")
  if res != CUDA_SUCCESS: #
    var error_str: cstring
    discard cuGetErrorString(res, cast[cstringArray](addr error_str))
    echo "Failed to load module: ", error_str
    quit(1)

  if cuModuleGetFunction(addr kernel, modul, "warpTest") != CUDA_SUCCESS:
    echo "Failed to get function"
    quit(1)

  # Allocate GPU memory
  check cuMemAlloc(addr output, sizeof(cint) * 32)

  # Launch kernel
  var args = [cast[pointer](addr output)]
  check cuLaunchKernel(kernel,
                       1, 1, 1,    # Grid dimensions
                       32, 1, 1,   # Block dimensions
                       0, nil,       # Shared memory and stream
                       addr args[0], nil)   # Arguments and extra

  check cuCtxSynchronize()

  # Read back results
  var host_output = newSeq[cint](32)
  check cuMemcpyDtoH(addr host_output[0], output, sizeof(cint) * 32)

  # Print first few results
  for i in 0 ..< 10:
    stdout.write host_output[i], " "
  echo ""

  # Cleanup
  check cuMemFree(output)
  check cuModuleUnload(modul)
  check cuCtxDestroy(context)

main()

This fails with the aforementioned CUDA_ERROR_INVALID_IMAGE error.

A standalone example
At this point I was rather convinced the reason has to be in some
minor detail regarding the CUDA wrapper. So I wrote a standalone CUBIN
loader + wrapper script.
In the below you'll see me either using the approach of nimcuda
currently or by passing the paths to the header files and libraries
and using the header pragma. The latter (commented out) version
works correctly.
# Necessary if we use the `header` pragma (see below)
#{.passC: "-I/usr/local/cuda-12.6/targets/x86_64-linux/include".}
#{.passL: "-L/usr/local/cuda-12.6/targets/x86_64-linux/lib -lcuda".}

type
  CUresult* {.size: sizeof(cint).} = enum # just remove all others for the time being
    CUDA_SUCCESS = 0
    CUDA_ERROR_INVALID_IMAGE = 200
    CUDA_ERROR_UNKNOWN = 999

  CUdevice* = distinct int32
    ## Compute Device handle
  CUcontext* = distinct pointer
#  CUmodule* = distinct pointer # neither this approach
  CUfunction* = distinct pointer
  CUstream* = distinct pointer
  CUdeviceptr* = distinct pointer

# Nor this one makes a difference
type
  CUmod_st {.pure, inheritable.} = object  # Opaque struct
  CUmodule* = ptr CUmod_st                 # Matches CUDA's definition exactly

# The important piece of the puzzle is the `header` pragma
{.push importc, dynlib: "libcuda.so".} #, header: "cuda.h".}
# {.push importc, dynlib: "libcuda.so", header: "cuda.h".}

proc cuInit*(flags: uint32): CUresult
proc cuDeviceGet*(device: var CUdevice, ordinal: int32): CUresult
proc cuCtxCreate*(pctx: var CUcontext, flags: uint32, dev: CUdevice): CUresult
proc cuCtxDestroy*(ctx: CUcontext): CUresult
# correspondingly this or
#proc cuModuleLoad*(module: var CUmodule, file: cstring): CUresult {.used.}
# this
proc cuModuleLoad*(module: ptr CUmodule, file: cstring): CUresult
proc cuModuleUnload*(module: CUmodule): CUresult
proc cuMemFree*(devptr: CUdeviceptr): CUresult

{.pop.} # {.push noconv, importc, dynlib: "libcuda.so".}

template check*(status: CUresult) =
  ## Check the status code of a CUDA operation
  ## Exit program with error if failure

  let code = status # ensure that the input expression is evaluated once only
  if code != CUDA_SUCCESS:
    writeStackTrace()
    stderr.write(astToStr(status) & " " & $instantiationInfo() & " exited with error: " & $code & '\n')
    quit 1

proc main =
  var device: CUdevice
  var context: CUcontext
  var modul: CUmodule
  var kernel: CUfunction
  var output: CUdeviceptr

  # Init (all these 3 pass; I leave out `check` to produce less noise in the generated C code)
  discard cuInit(0)
  discard cuDeviceGet(device, 0)
  discard cuCtxCreate(context, 0, device)

  # Load the CUBIN
  let res = cuModuleLoad(addr modul, cstring "kernel_nim.cubin")
  if res != CUDA_SUCCESS: # fails unless we push the `header` pragma
    echo "Failed to load module ", res
    quit(1)

  # Cleanup
  check cuMemFree(output)
  check cuModuleUnload(modul)
  check cuCtxDestroy(context)

main()

Applying this to nimcuda
To apply this to nimcuda we essentially just have to push / pop the
header to all the wrapped procs. I've verified that this works
locally.
The downside to this approach is that we then need to pass the path to
the header at compile time. Still, I guess that's a sane trade-off for
having actually working code?
I don't fully understand why this is such a big problem with CUDA, to be
honest. I can only assume there is some minor ABI mismatch that I don't
see. Or CUDA just does too much magic behind the scenes. :)

This is gonna give me a headache...
It appears that printf is a built-in function in cuda, declared internally in common_function.h. This header also includes fan favorites like new, delete, free, malloc, and more. It was eventually compiled in libnvrtc-builtins.so and gets auto-included to nvrtc programs via a header called __nv_nvrtc_builtin_header.h. I have confirmed that all of these cause the same issue. What this has to do with anything, i dont know.
At least its an easy fix?

This header also includes fan favorites like new, delete, free, malloc, and more. It was eventually compiled in libnvrtc-builtins.so and gets auto-included to nvrtc programs via a header called __nv_nvrtc_builtin_header.h. I have confirmed that all of these cause the same issue. What this has to do with anything, i dont know. At least its an easy fix?

Yeah, I assumed that there would likely be other functions causing the same problem. Thanks for investigating and confirming it!
The main problem I see is how we want to handle the path to the CUDA libraries at compile time. Try to find a path? Require the user to define the path themselves? Not sure what the cleanest option looks like.

Maybe we can assume that the header is in the path and use header: "<cuda.h>"?

Maybe we can assume that the header is in the path and use header: "<cuda.h>"?

At least on my machine, this doesnt work. nvidia's docs dont have the user put the includes or libs on path anyways.
imo, the best option would be a strdefine that auto detects on the most common setups


DOC: fix up scipylib download page

Most importantly, link to PyPI instead of SourceForge.

okay, merging this.

Thank you Ralf!