[Help Wanted] - Runnng nox fails with a Syntax Error: invalid syntax - error

Hello everyone,
Thanks in advance for looking into this issue. I'm a first time user of nox and I'm trying to run some tests on a project that uses nox (which is the google-cloud-python project). I installed nox using pip and ran the unit tests as instructed on google's project, but always end up with the following error, but I'm not sure what's wrong:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/bin/nox", line 7, in <module>
    from nox.__main__ import main
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nox/__main__.py", line 155
    print(dist.version, file=sys.stderr)
                            ^
SyntaxError: invalid syntax

I apologize if this is a very silly error or if there's a fundamental setup issue on my laptop. Here are the steps that I followed:

Clone google-cloud-python project
Create a virtual virtual environmene using virtualenv
Install nox using pip install nox
Run the following command to run the tests in the repo: nox -f bigtable/noxfile.py -s unit-2.7

This results in the error trace I've posted above, every time. I installed all other requirements that the project requires based on their docs/requirements.txt file, but always end up in this issue.
Development Environment details:

Python 2.7.13
MacOS Mojave

Please let me know if any more info is required from me.
Thanks,
Naveen

Nox is Python 3.5 only.

Yep. Nox can be used to test any version of Python, but Nox itself must be installed under 3.5+.


Update Riverpod sample to promote best practices

See https://github.com/rrousselGit/riverpod/issues/3226
(I'm not sure who has access to update these gists. Sorry if it was unhelpful to file an issue here and in Riverpod!)

Thanks for noticing and reporting this :)
I'm not familiar with Riverpod myself so any improvements sound great to me.
\cc @domesticmouse If you have a chance, could you update https://gist.github.com/flutterdevrelgists/ef06ab3ce0b822e6cc5db0575248e6e2 with @KyleFin's code at https://github.com/rrousselGit/riverpod/issues/3226#issue-2049260050 if it looks good to you?

I only have a day left before I'm out for Xmas holidays, so I'm handing this off to @johnpryan to update.

Thanks for filing an issue!


fix: navigation of imports in project tree

Description
Fix some imports in project tree did match correct link.

Task Item
refs #6444
refs #6354

Screenshots
form dialog

imports

Coverage decreased (-0.06%) to 52.659% when pulling bc58e7b46aae5dec9714d6e11082bbfcd2bdb41a on zhixzhan/navigation into 294514fbf2a5a3b5110889bd4f4dba04567c90d0 on main.

did this also fix the hosit view of lu intent?

did this also fix the hosit view of lu intent?

Do you mean reference lu intent not found in inline editor? not include that, I will make another PR fix it.


Buffer Factory: Configuration of the minimum account size to track.

We can now configure the minimum account size to track.
Signed-off-by: Kevin Baichoo<EMAIL_ADDRESS>
Commit Message: Buffer Factory: Configuration of the minimum account size to track.
Additional Description:
Risk Level: low
Testing: unit test
Docs Changes:  NA
Release Notes: NA -- the feature isn't entirely user-facing. The documentation and release note changes are already finished in a PR that builds off of this. See: https://github.com/KBaichoo/envoy/pull/111/files#diff-c69815663eb82a9e98598ce5dc2c55bc7a4b0b180dd7fe188ef1227bdab9160c
Related Issue #15791

/assign @antoniovicente
PTAL

/retest

/retest


[bug] windows - URLs with extended chars cause  backup  to not run - 500 Internal Server Error

Describe the bug
On the locally hosted Python version the Backup link in the navbar leads to a 500 Internal Server Error page.
Tried updating and restarting the app, same result.
Version
v0.45.1
To Reproduce
Steps to reproduce the behavior:

Go to 'Backup'
See error

Desktop (please complete the following information):

OS: Win10
Browser: Firefox
Version: 117.0.1

@kazerniel using a url as https://changedetection.io/?go=őőőőő , I'm unable to reproduce it.. I need more info here...

I'm running it in Windows via pip - installed it with the instructions on this page.
Attached the list of URLs that have "ő" in them. (I'm using the app to monitor new Steam releases from Hungarian game developers.)
ő devs.txt

thanks! ok hmm might be a windows only issue, interesting

In the meanwhile, is there any other way I can back up the app's data? (Particularly the filters applied to watched URLs.)

@kazerniel click the backup button

That's the one that doesn't work, what the whole ticket is about 😅

ah, you can copy the /datastore volume from inside the docker container to your local/host side then

btw, so far i was unable to reproduce this, its possible that the URL you have in there is not correctly "url-encoded" either, perhaps, an idea

ah, you can copy the /datastore volume from inside the docker container to your local/host side then

I run it via Python on Windows, is there an equivalent there?

btw, so far i was unable to reproduce this, its possible that the URL you have in there is not correctly "url-encoded" either, perhaps, an idea

sorry, I don't know what this means, the detection has been running fine on the "ő" URLs


Updated pisa API data

Needed content changes: https://edit.scrivito.com/d0a154d76edf2a7bd991fc658e700a1d~https://new-pisa-data.scrivito-portal-app.pages.dev/my-tynacoon-59274260f223b65f?_scrivito_workspace_id=i4c55a37bc5458f8&_scrivito_display_mode=view

Please focus your review on the editing config and the content changes in the working copy. Did I cover all places, that changes from a "localized only" value to an enum value? Please also keep in mind, that the

Content looks good to me, but I only checked the main lists and one item each and don't really know what to watch out for.

The main change is for all "enum" attributes, that most (but not all) places in the content should used xLocalized instead of x. So a regular visitor should not see something like PSA_QUO_STY_GEN_OVR or PSA_INF.


Beyla loses k8s metadata after pods restarted

Hi All,
I created https://github.com/grafana/alloy/issues/2016 as this issues has surfaced in Alloy but the issues is with Beyla.
Essentially when you start Beyla it is able to get all the metadata for the pods without issue, but if you go and restart a deployment or something, then Beyla stop decorating the traces with the pods metadata.
I've been testing this using Kind and Alloy is running as a daemonset.
No errors are reported in the logs and Alloy has enough permissions.
Just seems that as soon as some pods are rotated that Beyla forgets to add the metadata etc.
I'm hoping this is just an issue with my configuration but any help would be appreciated.
Steps to reproduce

Run a kind cluster
Run a random deployment with some annotations.
Create alloy daemonset using the below config.
Once the alloy daemonset is running, rollout restart the deployment.

System information
linux/arm64/kubernetes:v1.29.2
Software version
grafana/alloy:v1.4.3
Config
beyla.ebpf "default" {
  output {
    traces = [otelcol.processor.k8sattributes.default.input]
  }

  attributes {
    kubernetes {
      enable = "true"
      cluster_name = "test"
    }
  }

  discovery {
    services {
      kubernetes {
        namespace = ".*"
      }
    }
  }

  metrics {
    features = ["application","application_span","application_service_graph","application_process"]
  }
}

Logs
Before some pods are restarted
{"ts":"2024-10-31T22:54:22.627883417Z","level":"debug","msg":"evaluating pod identifier","component_path":"/process_traces.traces.default","component_id":"otelcol.processor.k8sattributes.default","value":[{"Source":{"From":"resource_attribute","Name":"k8s.pod.name"},"Value":"mimir-6db8548bd4-bpmsv"},{"Source":{"From":"resource_attribute","Name":"k8s.namespace.name"},"Value":"monitoring"},{"Source":{"From":"","Name":""},"Value":""},{"Source":{"From":"","Name":""},"Value":""}]}

Resource attributes:
     -> service.name: Str(loki)
     -> telemetry.sdk.language: Str(go)
     -> telemetry.sdk.name: Str(beyla)
     -> host.name: Str(loki-5868469c7b-csx8n)
     -> host.id: Str(88742f305b054aa0870f91054c288cdb)
     -> service.namespace: Str(monitoring)
     -> k8s.node.name: Str(kind-worker3)
     -> k8s.pod.uid: Str(5d1e946b-db06-44dd-8cd0-fc6c359583bb)
     -> k8s.pod.start_time: Str(2024-11-10 21:57:29 +0000 UTC)
     -> k8s.cluster.name: Str(test)
     -> k8s.replicaset.name: Str(loki-5868469c7b)
     -> k8s.deployment.name: Str(loki)
     -> k8s.namespace.name: Str(monitoring)
     -> k8s.pod.name: Str(loki-5868469c7b-csx8n)
     -> service.instance.id: Str(alloy-bps5z-88188)
     -> otel.library.name: Str(github.com/grafana/beyla)
     -> team: Str(loki)

After pods are restarted
{"ts":"2024-10-31T22:54:22.62843Z","level":"debug","msg":"evaluating pod identifier","component_path":"/process_traces.traces.default","component_id":"otelcol.processor.k8sattributes.default","value":[{"Source":{"From":"","Name":""},"Value":""},{"Source":{"From":"","Name":""},"Value":""},{"Source":{"From":"","Name":""},"Value":""},{"Source":{"From":"","Name":""},"Value":""}]}

Resource attributes:
     -> service.name: Str(loki)
     -> telemetry.sdk.language: Str(go)
     -> telemetry.sdk.name: Str(beyla)
     -> host.name: Str(alloy-dptnw)
     -> host.id: Str(1ec4a9bedd034cb495e9fbc5c2f97bfa)
     -> service.instance.id: Str(alloy-dptnw-93093)
     -> otel.library.name: Str(github.com/grafana/beyla)

This is most probably the bug we fixed in Beyla 1.8.3 (Alloy ships Beyla 1.8.1): https://github.com/grafana/beyla/releases/tag/v1.8.3
Next version of Alloy will include Beyla 1.8.7 and fix it. We'll verify once it is published.


Rollup ^3.0.0 cjs re-exports edge case with externalLiveBindings: false

This is a new version of the same problem reported back in https://github.com/nodejs/cjs-module-lexer/issues/38
Given code
export * from 'foo'

Default cjs output from Rollup (working, correctly detects re-exports from foo):
var foo = require('foo');

Object.keys(foo).forEach(function (k) {
	if (k !== 'default' && !exports.hasOwnProperty(k)) Object.defineProperty(exports, k, {
		enumerable: true,
		get: function () { return foo[k]; }
	});
});

With output.externalLiveBindings: false (not working, no re-exports detected):
var foo = require('foo');

for (var k in foo) {
	if (k !== 'default' && !exports.hasOwnProperty(k)) exports[k] = foo[k];
}

Note: this was working previously in Rollup 2.x where the code generated was:
var foo = require('foo');

Object.keys(foo).forEach(function (k) {
	if (k !== 'default' && !exports.hasOwnProperty(k)) exports[k] = foo[k];
});

Reproduction

Install deps
npm run build (which builds src/index.js with Rollup to out.js)
node lex.js (which runs cjs-module-lexer on out.js)

Thanks for reporting. Per the policy on this project, the patterns supported were fully stabilized at the point this library started shipping, so that no new detections will be added. Otherwise that risks code that works in new Node.js versions mysteriously breaking in older versions and that would be very very difficult to debug.
I've posted a PR in https://github.com/nodejs/cjs-module-lexer/pull/80 to better explain this as part of the project status.

/cc @lukastaegert
If Node.js will no longer update the detection mechanism, maybe Rollup will have to adapt to this case? I think it comes down to the use of for ... in vs Object.keys(...).forEach(...).

Unfortunately that basically is the situation today - where build tools do have to accept these semantics as part of their targets now. It's ended up the lesser of the evils, and my apologies we couldn't do better!

esbuild ended up just using a hinting pattern itself - https://github.com/nodejs/cjs-module-lexer/pull/46

I think the change was done to allow some level of improved ES3 compatibility via this option. But I see that this is only affecting a very minor group of users and since .forEach can easily be polyfilled, I will revert it to the other pattern.

Actually, looking at this longer, it was not about ES3 compatibility. I wanted to switch to the other pattern altogether because it is smaller and more performant, but it cannot be used for live bindings because var k is being reassigned. If you allow const, then it will also use a for..in loop with live-bindings: https://rollupjs.org/repl/?version=3.11.0&shareable=JTdCJTIyZXhhbXBsZSUyMiUzQSUyMiUyMiUyQyUyMm1vZHVsZXMlMjIlM0ElNUIlN0IlMjJjb2RlJTIyJTNBJTIyZXhwb3J0JTIwKiUyMGZyb20lMjAnZm9vJyUyMiUyQyUyMmlzRW50cnklMjIlM0F0cnVlJTJDJTIybmFtZSUyMiUzQSUyMm1haW4uanMlMjIlN0QlNUQlMkMlMjJvcHRpb25zJTIyJTNBJTdCJTIyb3V0cHV0JTIyJTNBJTdCJTIyZm9ybWF0JTIyJTNBJTIyY2pzJTIyJTJDJTIyZ2VuZXJhdGVkQ29kZSUyMiUzQSU3QiUyMmNvbnN0QmluZGluZ3MlMjIlM0F0cnVlJTdEJTdEJTdEJTdE
But yes, I will revert this change.

Fix at rollup/rollup#4826

Thanks @lukastaegert - I will close this one now.


Xnero: Blacklist gamesd.app

Xnero requests the blacklist of the website gamesd\.app. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

gamesd\.app has been seen in 5 true positives, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


allow collect() to create nested collections

collect(array) becomes collect(array,bool) where bool recursively creates nested collections.
collect([1,2,3,4=>['test'=>[7,8,9]]],true)

produces
Illuminate\Support\Collection {#896
     all: [
       0 => 1,
       1 => 2,
       2 => 3,
       4 => Illuminate\Support\Collection {#861
         all: [
           "test" => Illuminate\Support\Collection {#893
             all: [
               7,
               8,
               9,
             ],
           },
         ],
       },
     ],
   }

Could you add some tests?

I would definition prefer a new function like collect_nested instead of a boolean parameter


crossScalaVersions are not published

Only the package with version defined in sbt is published. Packages created using crossScalaVersions are not published

Maybe you are using sbt-release with sbt 1.*?
https://www.scala-sbt.org/1.x/docs/Cross-Build.html#Note+about+sbt-release

seems to be the same issue as #42
I'm using only sbt-bintray (not sbt-release) and this works for me. See for instance https://gitlab.com/tyrcho/approvals-scala/-/jobs/581669177


Incorrectly appending 'Dockerfile' to path

One can provide a file not called Dockerfile to docker build like this: docker build -f Dockerfile.debug .. When instantiating with a file that isn't named Dockerfile dockerfile-parse will append Dockerfile to the path and fail.
>>> test = DockerfileParser('/home/nisha/test_dockerfile')
>>> test.structure
Couldn't retrieve lines from dockerfile: NotADirectoryError(20, 'Not a directory')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/nisha/scancodeenv/lib/python3.6/site-packages/dockerfile_parse/parser.py", line 250, in structure
    for line in self.lines:
  File "/home/nisha/scancodeenv/lib/python3.6/site-packages/dockerfile_parse/parser.py", line 143, in lines
    with self._open_dockerfile('rb') as dockerfile:
  File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
    return next(self.gen)
  File "/home/nisha/scancodeenv/lib/python3.6/site-packages/dockerfile_parse/parser.py", line 131, in _open_dockerfile
    with open(self.dockerfile_path, mode) as dockerfile:
NotADirectoryError: [Errno 20] Not a directory: '/home/nisha/test_dockerfile/Dockerfile'
>>> import os
>>> os.path.exists('/home/nisha/test_dockerfile') <-- the file exists
True

:wave: I don't see any contributing guide, but I can submit a PR if you think this is a valid bug :)


InputDecorator: Switch hint to Opacity instead of AnimatedOpacity

The AnimatedOpacity transition doesn't match native components on at least Android and web. M3 doesn't include Placeholder text anymore and I can't find anything saying that it was animated. The original complaint also stated that the transition from hint to input text can be disorienting.
This PR switches the hint to Opacity, making the opacity transition instant.
Fixes https://github.com/flutter/flutter/issues/20283
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

@HansMuller I saw this was reverted due to some breaking internal tests. Is there something I can fix?


ng2-datepicker is not supported to Angular 2 RC1

Can you please tell me when ng2-datepicker will gives support to RC1?

Hi, use https://github.com/morocarlo/ng2-my-datepicker


Go BLUI

Changes proposed in this Pull Request:

This publishes the BLUI ng-component library.

To test out the BLUI components, run yarn start:storybook.
I also converted the angular-showcase-demo repo to BLUI.  To test out the BLUI components & BLUI themes, check out the branch below & run yarn && yarn start.
https://github.com/pxblue/angular-showcase-demo/tree/feature/blui

looks good, do we track the components/README.md refs of pxb later

I'll make a story for this now in JIRA; most pictures in the react & rn component libraries don't need changed but nearly all of angular's will need updated.

Just some things I'm noticing on the showcase that we may want to resolve later or perhaps an audit of this would be nice just to make sure we are using the correct colors as defaults.
These list item tags are hardcoded to have a white background... not sure why but they don't look great on light or dark theme in my humble opinion.

Decending character gets cut off of our score card...

That stop watch icon looks strange to me. Should we be using an outlined variant or something here ¯_(ツ)_/¯

None of these things are a direct issue with the component library work as far as I can tell so I'll approve this, but we may want to write a story to double check these colors and other potential issues.


Usage example of dockerClient.logs()

Im having trouble reading the logs from a running container via:
	@Test
	public void testLog() throws Exception {
		try (DockerClient dockerClient = DefaultDockerClient.builder().uri("http://localhost:4243").build()) {
			try (LogStream logStream = dockerClient.logs(
					"89622a6d0b8b",
					LogsParameter.FOLLOW,
					LogsParameter.STDERR,
					LogsParameter.STDOUT)) {

				LogStreamInputStream result = new LogStreamInputStream(logStream);
				final InputStreamReader inr = new InputStreamReader(result);
				String log = CharStreams.toString(inr);
				System.out.println("Log: " + log);
			}
		} catch (DockerException e) {
			e.printStackTrace();
		}
	}

	static class LogStreamInputStream extends InputStream {

		private final LogStream logStream;
		private ByteBuffer currentBuffer = null;

		/**
		 * @param logStream
		 */
		public LogStreamInputStream(final LogStream logStream) {
			super();
			this.logStream = logStream;
		}

		@Override
		public int read() throws IOException {
			if (this.currentBuffer == null) {
				if (this.logStream.hasNext()) {
					this.currentBuffer = this.logStream.next().content();
				}
			}

			int result;
			if (this.currentBuffer.remaining() > 0) {
				result = this.currentBuffer.get();
			} else {
				this.currentBuffer = this.logStream.next().content();
				result = this.currentBuffer.get();
			}
			return result;
		}
	}

This example just stucks an never prints out any, it even does not loop in the read().
Can someone please give an simple example howto consume docker logs.
greetings
Stefan

This can be closed now right?


mat: rewrite Cholesky.ToSym without calling SymOuterK

A substitute for the Dlauum attempt. Cholesky.ToSym is not super important but with this PR it becomes slightly faster.
name                    old time/op  new time/op  delta
CholeskyToSym/n=10-4    2.65µs ± 2%  0.78µs ± 0%  -70.75%  (p=0.029 n=4+4)
CholeskyToSym/n=100-4    329µs ± 1%   124µs ± 0%  -62.33%  (p=0.029 n=4+4)
CholeskyToSym/n=1000-4   241ms ± 2%   175ms ± 0%  -27.34%  (p=0.029 n=4+4)

Please take a look.

I will wait also for @btracey


Wrong indentation when inverting comment

Hi,
I happen to use the <Leader>ci command a lot for situations like the following python example:
# some_dict = {
#    'key1': 0,
# }
some_dict = {
    'key1': 1,
}

When I use Invert Comment on that code, I get
some_dict = {
   'key1': 0,
}
# some_dict = {
    # 'key1': 1,
# }

But I would expect the # to be all aligned at the beginning of the line (as is done when I use <Leader>cc on the code).
Thanks for your help!

@alerque I have the same issue. It seems like NERDComToggleComment does not respect the alignment setting specified in g:NERDDefaultAlign where as NERDComComment does.
Same issue as mentioned here https://github.com/scrooloose/nerdcommenter/issues/128
Is g:NERDDefaultAlign supposed to change the alignment for toggling comments? As it doesn't seem to work.

Also observed here; I use  let g:NERDDefaultAlign = 'left', which works fine when commenting a block of lines using NERDCommenterToggle, but if NERDCommenterInvert is used instead, the left indent is not respected.

Is this going to be fixed?

It will get fixed when somebody fixes it. This is an open source project and reliant on people that use it to fixi things or add features and submit their work for others to benefit from. I personally have limited time to develop this right now, but I've been staying on top of Pull Request submissions. Anybody should feel free to tackle this issue knowing their work will benefit others.


Conditionally add btrfs-tools patch

It looks like this needs rebasing on the libsdl fix.

Reworked to use LooseVersion from distutils.version
Don't know how strict the package maintainers are regarding their versioning and that is why I choose LooseVersion. I can switch to StrictVersion if desired

@floion I think it's fine for now. Thanks.

Can this be merged?

@floion the builds didn't pass. Codewise I approved the PR.


[FEATURE] Enable selection of multiple rows in Table

Summary
A user needs the option to select multiple rows in a table widget and perform an action on the rows selected.
Motivation
The reason a multi select dropdown doesn't work for the user is because the table data is fragmented and the users of the application need to look at a combination of columns in order to make a decision as to which rows should be acted upon

Would love this feature 😍

@mohammadnajmuzzaman this feature has been deployed! Check it out and let us know your feedback 😃


[BUG] compatibility problem when use NettyHttpClientPlugin

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
When using NettyHttpClientPlugin, the implementation of org.apache.shenyu.plugin.api.result.ShenyuResult#contentType is incompatible.
Expected Behavior
No compatibility problem.
Steps To Reproduce

run ShenyuAdminBootstrap;
run ShenyuTestHttpApplication;
enable NettyHttpClientPlugin and run ShenyuBootstrapApplication;
send request:

POST http://localhost:9195/http/shenyu/client/hello
Accept: application/json
Content-Type: application/json

Environment
ShenYu version(s): master

Debug logs
nop
Anything else?
nop

    default MediaType contentType(ServerWebExchange exchange, Object formatted) {
        //fixme not compatible with NettyHttpClientPlugin
        final ClientResponse clientResponse = exchange.getAttribute(Constants.CLIENT_RESPONSE_ATTR);
        if (Objects.nonNull(clientResponse) && clientResponse.headers().contentType().isPresent()) {
            return clientResponse.headers().contentType().get();
        }
        return MediaType.APPLICATION_JSON;
    }

Is anyone willing to fix it?

I Can fix it. thinks

Sorry, it has been done in org.apache.shenyu.plugin.response.strategy.NettyClientMessageWriter.


Duplicate item in query after using upsert mutation

Describe the bug
When using useQuery or useInfiniteOffsetPaginationQuery and then modifying a row with useUpsertMutation, the row is updated and moved to the bottom of the list but the first item is now a duplicate of the newly updated row. The size of the data array remains the same and so one row is missing with the duplicate in its place.
It seems to be similar to this issue https://github.com/psteinroe/supabase-cache-helpers/issues/59 but I don't use subscriptions.
To Reproduce
If possible, open a PR with a failing test. Otherwise, describe how to reproduce the behavior:
const { trigger: upsert } = useUpsertMutation(
    supabase.from("table"),
    ["id, foo_id"],
    null,
    {
      revalidate: true,
    }
  );

const query = supabase
    .from("table")
    .select("id, foo_id, name")
    .eq("foo_id", foo?.id);

const { data } = useQuery(foo ? query : null);

I've tried with revalidate set to true and false, also by ordering of creation date but I am getting the same result
Expected behavior
Item to be updated in the list with no duplicate entry.

thanks for reporting the issue. Is this about tables with two primary keys, and a query on just one of them? Or is the reproduction example random?

thanks for reporting the issue. Is this about tables with two primary keys, and a query on just one of them? Or is the reproduction example random?

Yeah correct, I just tested now with only id passed in as the primary key field for the upsert mutation and is now working as expected. So I'm not sure if it was an issue form my end but useUpsertMutation mentions An array of primary key column names for the table. so i assumed it requires all the primary keys passed in.
const { trigger: upsert } = useUpsertMutation(
    supabase.from("table"),
    ["id"],
    null,
    {
      revalidate: true,
    }
  );

thanks for reporting the issue. Is this about tables with two primary keys, and a query on just one of them? Or is the reproduction example random?

Yeah correct, I just tested now with only id passed in as the primary key field for the upsert mutation and is now working as expected. So I'm not sure if it was an issue form my end but useUpsertMutation mentions An array of primary key column names for the table. so i assumed it requires all the primary keys passed in.
const { trigger: upsert } = useUpsertMutation(
    supabase.from("table"),
    ["id"],
    null,
    {
      revalidate: true,
    }
  );

yes, if your table has two primary keys then both should be passed in the array as well as the input. so both id and foo_id are primary keys of your table? Can you pass me a minimal schema for me to reproduce?

CREATE TABLE "foo" (
  "id" integer PRIMARY KEY
);

CREATE TABLE "bar" (
  "id" integer,
  "foo_id" integer,
  "name" text,
  PRIMARY KEY ("id", "foo_id")
);

ALTER TABLE "bar" ADD FOREIGN KEY ("foo_id") REFERENCES "foo" ("id");

With the foo bar tables, this is how i was querying them
// retrieve foo object from global state
const foo = useFoo();

const { trigger: upsert } = useUpsertMutation(
    supabase.from("bar"),
    ["id, foo_id"],
    null
  );

const query = supabase
    .from("bar")
    .select("id, name")
    .eq("foo_id", foo?.id);

const { data } = useQuery(foo ? query : null);

hey @stevebyatt10, I have added a test to try and replicate your issue. https://github.com/psteinroe/supabase-cache-helpers/pull/331
Unfortunately, it works. Can you find any difference to your code?

Apologies for the late reply, this is unfortunately a mistake on my end.
 const { trigger: upsert } = useUpsertMutation(
    supabase.from("bar"),
    ["id, foo_id"], <- 1 string
    null
  );

I can confirm this does work when actually passing 2 strings.
Thanks for taking a look into this once again.

Apologies for the late reply, this is unfortunately a mistake on my end.
 const { trigger: upsert } = useUpsertMutation(
    supabase.from("bar"),
    ["id, foo_id"], <- 1 string
    null
  );

I can confirm this does work when actually passing 2 strings.
Thanks for taking a look into this once again.

ahh good catch! no worries, its always good to add more tests. :)


Pinning flask-socketio version

Currently, compatibility issues between the socket-io client and server will prevent minigui from communicating. Recommend pinning the version here to ensure compatibility.

@googlebot I signed it!


Add Headless Data Table Support

closes #2920
Additional description
This commit adds a new DataTable prop, isHeadless: boolean. Setting
this prop to true hides the header by applying
slds-table_header-hidden to table and slds-assistive-text to
thead.

CONTRIBUTOR checklist (do not remove)
Please complete for every pull request

[X] First-time contributors should sign the Contributor License Agreement.  If you haven't before, wait a few minutes and a bot will comment on this pull request with instructions.
[X] npm run lint:fix has been run and linting passes.
[X] Mocha, Jest (Storyshots), and components/component-docs.json CI tests pass (npm test).
[X] Tests have been added for new props to prevent regressions in the future. See readme.
[X] Review the appropriate Storybook stories. Open http://localhost:9001/.
[X] Review tests are passing in the browser. Open http://localhost:8001/.
[X] Review markup conforms to SLDS by looking at DOM snapshot strings.

REVIEWER checklist (do not remove)

[ ] TravisCI tests pass. This includes linting, Mocha, Jest, Storyshots, and components/component-docs.json tests.
[ ] Tests have been added for new props to prevent regressions in the future. See readme.
[ ] Review the appropriate Storybook stories. Open http://localhost:9001/.
[ ] The Accessibility panel of each Storybook story has 0 violations (aXe). Open http://localhost:9001/.
[ ] Review tests are passing in the browser. Open http://localhost:8001/.
[ ] Review markup conforms to SLDS by looking at DOM snapshot strings.

Required only if there are markup / UX changes

[ ] Add year-first date and commit SHA to last-slds-markup-review in package.json and push.
[ ] Request a review of the deployed Heroku app by the Salesforce UX Accessibility Team.
[ ] Add year-first review date, and commit SHA, last-accessibility-review, to package.json and push.
[ ] While the contributor's branch is checked out, run npm run local-update within locally cloned site repo to confirm the site will function correctly at the next release.

@garygong could you review this when you get a few minutes? Thanks!

Thanks @jacobroschen . Please update prop name to isHeadless to conform to https://github.com/salesforce/design-system-react/blob/master/docs/codebase-overview.md#boolean-props-use-is-has-and-can-prefixes-or--able-suffix

Rest of PR is good.

@interactivellama thanks for the quick review. I've changed headless to isHeadless and hidden to isHidden.

@jacobroschen We got the CI working again. Please update the DOM snapshots.

@interactivellama Everything should be ready. Thanks again for getting this in.


How to get the vocab files？

HI, the src_vocab and dst_vocab in vocab files with 38831/34432 words, is generated by how many pieces of data are generated separately for the vocab.py？
By vocab.py，The result has two columns of data, taking the first column as a vocabulary file？
Thanks～

@luckper You mean the BPE merge operation? we set it as 32000. Actually, you can directly use the file generated by vocab.py as the vocabulary file. The second column has no effects on our program.

@ZhenYangIACAS Hi，I have a question，pre-processed the data by tokenization and BPE，about tokenization and BPE，How are you dealing with it ? Which scripts or tools are used?
Thanks～～

@luckper You can find the answers in some one issue proposed by others.  I remember that some one has asked this question before and you are supposed to scan the existing issues before you propose a new issue. Anyway, we are still glad to answer this question again. For tokenization,  we utilize the script of Mose. And you can also use the nltk to do tokenization. For BPE, we utilize the open-source subword-nmt toolkit. You can find the download links easily.

@ZhenYangIACAS  First，thanks for your answer！
I have got the subword-nmt，and I am watching the subword-nmt.
But I can't understand the relationship between the tokenization and the BPE，and what are we tokenization? the word or sentence？
Thanks～～

@ZhenYangIACAS  Hi, for English-German, did you use 32000 or 30000 BPE merge operations?

30000 merge operations

@luckper You mean the BPE merge operation? we set it as 32000. Actually, you can directly use the file generated by vocab.py as the vocabulary file. The second column has no effects on our program.

Hi, zhen yang, I would like to make some clarifications.

for en-de, you learn the BPE code jointly with merge operation set to 32000
you then apply the BPE to training corpus and get the source and target vocabularies, which contains 38831/34432 subword-units respectively

Moreover, I am confused that the src_vocab_size and dst_vocab_size are both 32000 in the config_generator_train.yaml  while in the other *.yaml (e.g. config_generate_sample.yaml), the  src_vocab_size and dst_vocab_size are set to 38831/34432 respectively.
Looking forward to your reply, many thanks.


Waymo → nuScenes

The impact of REDB for Waymo adapt to nuScenes is significantly limited, why？

Thanks for your question.

Challenging Dataset: The nuScene dataset inherently poses significant challenges, resulting in the model (SECOND) achieving fully-supervised training results of only 18.92 (pedestrian) and 11.73 (cyclist) 3D mAP.
Significant domain gap: There exist large domain gaps between Waymo and nuScene, such as very different object densities and beam numbers, which introduces a level of complexity when attempting to adapt to nuScene.

The coexistence of these two factors introduces error accumulation in pseudo-labelling. In the case of ST3D++, which focuses on adapting one model for a single class, the 3D mAP results are just 8.91 (pedestrian) and 4.84 (cyclist). However, when we transition to a more realistic scenario, training all three classes simultaneously while adapting at once, the performance of ST3D++ drops significantly to 1.58 (pedestrian) and 3.74 (cyclist).
Regards,
Zhuoxiao (Ivan) Chen


firstCommit

https://ankitsite.atlassian.net/browse/ANKITKEY-1?atlOrigin=eyJpIjoiYTQ4YjhkMWQzYWUzNDNkZWExZmExNjQwZDJkNmI4YzYiLCJwIjoiaiJ9

[#464 ]

@ankit-arora12 What's this?

Closing as it appears to be some kinda of test or done by accident?


Scope clarification: this is a protocol library

Add something in the main page and README stating the difference between a protocol library like this and a framework/ORM like sqlpp11.

Done as of bf4071f37062bd180a495fc73241becb32aa2c6e.


Support labels on Provisioner set outside of labels

Tell us about your request
What do you want us to build?
Karpenter currently only supports label selectors that either karpenter manage (by assuming it can configure kubelet) or that are well-known (those kubelet set itself, such as kubernetes.io/os and kubernetes.io/arch).
But there is a host of other components that put labels on nodes: KCM, CCM, CNIs, device managers and others.
It should be possible to tell karpenter that instances launched by a given Provisioner is expected to get these labels.
This is the label analog to #628
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
One example would be a Pod that is scheduled to run only on worker nodes and that would have node-role.kubernetes.io/node as selector.
Note that many of these selectors are forbidden to be set by kubelet (e.g the above-mentioned label), so this will most likely need a new field in the API.
Are you currently working around this issue?
Not possible.

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

I'd love to see another example other than kop's node-role.kubernetes.io/node. One might be the node labels from https://github.com/NVIDIA/k8s-device-plugin. Seeing more examples will help us design the right solution.
I'll be honest that this feels like a hack to me. One option (at least in this case) would be to use a NotIn NodeAffinity rule to avoid the kops masters, rather than attracting to kops nodes.

The node role label is a wellknown label that all installers use. Kops has a role for spots though that is very popular for using with cluster autoscaler to ensure a pod are either scheduled on or off spot instances.
master (and apiserver) nodes are tainted and doesn't automatically attract any pods.
CAS has templates that support this functionality.

It's worth mentioning that karpenter cannot schedule nodeAffinity that uses NotIn. There is no way for karpenter to know what labels a node may not have.

Would this "just work" if kops didn't use the kubernetes.io domain?

What are you referring to? If you mean the node-role.kubernetes.io/role label then that is a label that all nodes have in a cluster. It is e.g used by kubectl get nodes. All installers have mechanisms for setting this label. That also goes for the older kubernetes.io/role label.

@olemarkus We're not sure this is still a requirement. Please reopen or comment if still needed.


don't require user to set ~/.cargo/bin on the PATH

Fixes #444
I decided not to update the install instructions and instead make the build system set the PATH for you.

My only concern might be that some could be installing cargo though other means and have it installed in a different location.  But I guess that's probably less likely...

@traiansf that is not an issue because the LLVM backend does not support installing rust except via rustup.


Queueing multiple songs from one result set

Frank   > @wolfman find breeders - last splash
Wolfman > 0: The Breeders - Last Splash - Cannonball
1: The Breeders - Last Splash - No Aloha
2: The Breeders - Last Splash - Divine Hammer
3: The Breeders - Last Splash - New Year
4: The Breeders - Last Splash - Invisible Man
5: The Breeders - Last Splash - Roi
6: The Breeders - Last Splash - Flipsiide
7: The Breeders - Last Splash - I Just Wanna Get Along
8: The Breeders - Last Splash - Saints
9: The Breeders - Last Splash - S.O.S.
Frank   > @wolfman play 1, 2, 8
Frank   > @wolfman play 3-4 7-9

User is able to queue multiple results at the same time using commas as a separator and dashes to represent ranges.
Frank   > @wolfman play all results

User is able to queue all the results that were returned in a single command

Seems like 1 2 3 should also work.

I like that as well.

This works, but it exposed issue #18 - Queuing multiple tracks when the player is completely stopped.


Provide a typesafe and fluent way to return only a subset of data and to use script_fields

Is your feature request related to a problem? Please describe.
I can't find a good way to return only a subset of the source in a typesafe way. I also can't find a (reasonably) typesafe way to use script_fields.
Describe the solution you'd like
I would like to be able to do this somehow. One option would be a new overload to SearchAsync:
Task<SearchResponse<TResult>> SearchAsync<TDocument, TResult>(
    Action<SearchRequestDescriptor<TDocument>> configureRequest,
    Expression<Func<TDocument, TResult>> resultFactory
);

The intent is that this could be invoked like this:
var result = await client.SearchAsync<MyEntity, MyResultEntity>(
    req => req.Index(...).Query(...),
    doc => new MyResultEntity
    {
        Prop1 = doc.Prop1,
        Prop2 = doc.Prop2ByLanguage[currentLanguage],
        Prop3 = Script<int>(@"emit(0)")
    }
);

And this should set the _source_includes and script_fields based on what the factory method wants.
Describe alternatives you've considered
One option is to remove all required from my indexed entity and then transform each element in result.Documents.
another would be to use SearchAsync<JsonObject>, but that doesn't work, either. Trying to use
var result = await client.SearchAsync<JsonObject>(
    req => req.Query(q => q.Term(o => o["prop1], theValue))

);
results in an exception with this stack trace:
# FailureReason: Unrecoverable/Unexpected BadRequest while attempting POST on http://localhost:9200/my-index/_search
 - [1] BadRequest: Node: http://localhost:9200/ Exception: ArgumentOutOfRangeException Took: 00:00:00.2872455
# Audit exception in step 1 BadRequest:
System.ArgumentOutOfRangeException: capacity ('-1') must be a non-negative value. (Parameter 'capacity')
Actual value was -1.
   at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
   at System.Text.StringBuilder..ctor(Int32 capacity, Int32 maxCapacity)
   at Elastic.Clients.Elasticsearch.FieldExpressionVisitor.Resolve(Expression expression, Boolean toLastToken) in /_/src/Elastic.Clients.Elasticsearch.Shared/Core/Infer/Field/FieldExpressionVisitor.cs:line 33
   at Elastic.Clients.Elasticsearch.FieldResolver.Resolve(Expression expression, MemberInfo member, Boolean toLastToken) in /_/src/Elastic.Clients.Elasticsearch.Shared/Core/Infer/Field/FieldResolver.cs:line 75
   at Elastic.Clients.Elasticsearch.FieldResolver.ResolveFieldName(Field field) in /_/src/Elastic.Clients.Elasticsearch.Shared/Core/Infer/Field/FieldResolver.cs:line 49
   at Elastic.Clients.Elasticsearch.FieldResolver.Resolve(Field field) in /_/src/Elastic.Clients.Elasticsearch.Shared/Core/Infer/Field/FieldResolver.cs:line 31
   at Elastic.Clients.Elasticsearch.Inferrer.Field(Field field) in /_/src/Elastic.Clients.Elasticsearch.Shared/Core/Infer/Inferrer.cs:line 52
   at Elastic.Clients.Elasticsearch.QueryDsl.TermQueryDescriptor`1.Serialize(Utf8JsonWriter writer, JsonSerializerOptions options, IElasticsearchClientSettings settings) in /_/src/Elastic.Clients.Elasticsearch/_Generated/Types/QueryDsl/TermQuery.g.cs:line 217
<--snip

However, using await client.SearchAsync<Dictionary<string, JsonNode>>(...) seems to work but is rather unergonomic.

I can help building this feature, if you want.

Hi @erik-kallen,
I have to think about this a little bit more. Currently I only see 1 main problem which would have to be solved in the code-generator:

The search APIs should have a generic argument TDocument for the query builder part, etc. and a different generic argument TPartialDocument for just the deserialization.

If that would be the case, you could easily deserialize into a partial type that only has the requested properties marked with required.
This does not solve the problem for meta-fields like the script_fields in your example, but these are only available after deserialization of the complete response (including all documents) which means we definitely have to materialize the request and perform a transformation afterwards.
For that transformation part, I'm not sure if we really need a helper, but I'm not completely against adding one.
Regarding type safety:

The SourceIncludes property is already of type Fields which allows to define fields using lambda expression trees
The ScriptFields are currently defined as IDictionary<string, Elastic.Clients.Elasticsearch.ScriptField> which does not allow usage of lambda expressions. A hand-crafted class ScriptFields similar to Fields could be created to improve usability and type-safety

What do you think?

The problem with the TPartialDocument approach is that I need to make sure that properties are named the same in both types, which is something I very much want to avoid. Another problem that would be good to have solved is that whenever a property would be added to this partial document, the SourceIncludes list needs to be manually maintained.
Given that we already have the typesafe ability to generate a Field from an Expression, I don't think it would be a super hard problem to:

Use the ExpressionVisitor to traverse an Expression<Func<TDocument, TTarget>> to find all access chains to properties of the source and collect them to a Fields object, and to collect all ScriptFields.
Use the ExpressionVisitor to transform the Expression<Func<TDocument, TTarget>> to an `Expression<Func<Hit, Hit>>
Compile the expression.
Deserialize the document into a JsonObject instead of TDocument (this might be hard, but it would be required also for the TPartialDocument solution).
Use the compiled expression to transform the documents.

The only thing I'm a little worried about is that this means that there is a real risk of the user defining the lambda inline, which would lead to a lot of compilations. To solve this, we could implement expression comparisons and reuse the compiled expressions if the expression trees are identical. Or we could have a limit of how many expressions are allowed to be compiled (which will alert the user to the problem). Or we could not compile the expressions but instead evaluate them dynamically.
Actually, I realize that my idea to have the script inline probably won't play well with this cache. Those values probably need to be referenced by some syntax like FieldValue<string>("theFieldName") instead.

The problem with the TPartialDocument approach is that I need to make sure that properties are named the same in both types

This sounds like a pretty unique problem to be honest. I fully understand the argument about the required properties, but renaming properties during retrieval is probably not a very common thing to do.

Another problem that would be good to have solved is that whenever a property would be added to this partial document, the SourceIncludes list needs to be manually maintained.

The Fields type already provides an implicit conversion operator from PropertyInfo[] which means you could initialize it with a list of properties for the TPartialDocument that is previously obtained by reflection.

Given that we already have the typesafe ability to generate a Field from an Expression, I don't think it would be a super hard problem to:

From the technical side, this is definitely doable and the approach you describe sounds reasonable.
However, in the context of this library I'm concerned about using compiled expressions. Besides the actual compilation overhead that you already mentioned, they are interpreted instead of compiled on several platforms like Mono, Xamarin, etc. Even when using AOT compilation in regular .NET framework, expression trees can no longer be compiled. This introduces a significant performance impact on these code pathes.

To solve this, we could implement expression comparisons and reuse the compiled expressions if the expression trees are identical

I've played with expression tree comparison in the past to be able to cache generic EF query results and from my experience, the comparison takes a significant amount of time itself (my code can probably be optimized on a few places) so that it was not worth using for fast queries at all.

I can definitely see the value in such helper function and don't want to demotivate you, but the problem you want to solve is really specific in my opinion. I would rather keep the library more generic and don't increase the scope too much. As I'm the only person working on this project, I always have to keep an eye on maintainability as well. This as well was one major reason for switching from hand-crafted code to the code generation approach. Besides that, there are the technical difficulties with the expression trees.
If you want to work on this anyways, I would love to see the results, but I don't expect it to be merged upstream at the moment.
What I'll definitely add to my list, is to come up with a way to deserialize search query results into a TPartialDocument. While this does not solve your specific issue, this still is something that I can see to have value for a lot of other users 🙂

The problem with the TPartialDocument approach is that I need to make sure that properties are named the same in both types

This sounds like a pretty unique problem to be honest. I fully understand the argument about the required properties, but renaming properties during retrieval is probably not a very common thing to do.

I don't understand what you mean. The problem I am referring to is that if I have a class IndexedEntity with all properties required, and another class PartialIndexedEntity with all properties optional, I need to make sure that the properties have the same name in both classes, or things will break silently.

The Fields type already provides an implicit conversion operator from PropertyInfo[] which means you could initialize it with a list of properties for the TPartialDocument that is previously obtained by reflection.

Yes, but as mentioned above, I don't think the TPartialData approach is better than what I currently have.

However, in the context of this library I'm concerned about using compiled expressions

This is a valid concern. The overload would have to be annotated with RequiresDynamicCode. Or perhaps do whatever EF does (which I don't know the details of, but the problem is very similar).

I can definitely see the value in such helper function and don't want to demotivate you, but the problem you want to solve is really specific in my opinion.

I don't think it's a very specific problem. Of course, I don't know how other people use the library, but I imagine it not being uncommon for people to do client.Search<TDocument>(...).Documents.Select(d => new SomeOtherEntity(...)). Anyone who does that could potentially benefit from this solution.

As I'm the only person working on this project, I always have to keep an eye on maintainability as well.

I understand that, thank you for your work!

If you want to work on this anyways, I would love to see the results, but I don't expect it to be merged upstream at the moment.

I wouldn't mind working on it, but I won't do it if it won't be merged. Or, if it becomes possible to deserialize to a different type than the query builder type, I might implement it as part of my own project (and I can share the code if I manage to get it working nicely).

What I'll definitely add to my list, is to come up with a way to deserialize search query results into a TPartialDocument. While this does not solve your specific issue, this still is something that I can see to have value for a lot of other users 🙂

While I don't see myself using the TPartialData approach, i think I can probably implement what I want externally if TPartialData is allowed to be JsonElement (or JsonNode).

The problem I am referring to is that if I have a class IndexedEntity with all properties required, and another class PartialIndexedEntity with all properties optional, I need to make sure that the properties have the same name in both classes, or things will break silently.

I understand that concern 🙂 Just the way you want to solve this, is very specific (in my opinon and without knowing all of your requirements).
The way I personally would solve this (again, given that we would have a version of the API that allows to specify TDocument and TPartialDocument), would just look like this:
public record Partial
{
    public required int A { get; init; }
    public required int B { get; init; }
}

public record Full : Partial
{
    public required int C { get; init; }
}

// In the next step, get `Property[]` of `Partial` by reflection and use it to initialize
// the `Fields` instance of the `SourceInclude` property in the `SearchRequest`

If this is a suitable class design, of course depends on your needs.
And keep in mind, that even with your approach, you would still be forced to update the property names on your already indexed documents, if you rename something.
A solution to this would be to use explicit JsonName attributes on the properties.

I don't know how other people use the library, but I imagine it not being uncommon for people to do client.Search<TDocument>(...).Documents.Select(d => new SomeOtherEntity(...)).

That definitely could be the case. It's just that from my experience:

people either use the inheritance based approach
people just quickly map the properties by hand if the amount of properties is small
large projects are using defacto-standard libraries to do the mapping for them (e.g. AutoMapper)

While I don't see myself using the TPartialData approach, i think I can probably implement what I want externally if TPartialData is allowed to be JsonElement (or JsonNode).

Yes, this should be possible in this case. Deserialization to JsonObject works fine in theory. For you it was crashing because of accessing the indexer (o => o["prop1]) which is probably not supported at the moment by the field name inference expression visitor.

Inheritance won't work for me because different queries return different subsets.

I don't know how other people use the library, but I imagine it not being uncommon for people to do client.Search(...).Documents.Select(d => new SomeOtherEntity(...)).

That definitely could be the case. It's just that from my experience:

people either use the inheritance based approach
people just quickly map the properties by hand if the amount of properties is small
large projects are using defacto-standard libraries to do the mapping for them (e.g. AutoMapper)

Yes, but the main thing I want to do doesn't really have anything to do with the mapping part. It's about reducing the amount of data fetched from elastic, and AutoMapper won't help with that.

Closing this for now as not planned. #7792 / #8186 is still on the roadmap.


Add test with arbitrary

The test from #4 can be made accessible with -
cargo test --all-features

This PR adds the test.
It still fails, however.

Some questions:

How fast/slow are these tests?

Do you have any examples of how other libraries make use of quickcheck + arbitrary? i.e. do they run it in CI, or do they just keep it behind a feature flag?

Would you recommend that these run in CI?

How do you see this evolving over time? What would a good arbitrary-based test suite look like? Are there more tests that you would want to see added over time?

Do you know how/why this arbitrary test fails?

Thanks!


Fix links which pointed to unavailable location

Routes /docs/concepts/#kubernetes-control-plane and /docs/concepts/#kubernetes-objects don't work as they are expected, due to unimplemented anchors perhaps. Could be better if they directly point to topics.

Due to invalid commit message. Re-edit and create a new PR.


Issue extension doesn't support windows new lines

https://github.com/vsch/flexmark-java/blob/07b83fb84047f7d9add8c729d1006c46517aecda/flexmark-ext-gfm-issues/src/main/java/com/vladsch/flexmark/ext/gfm/issues/internal/GfmIssuesInlineParserExtension.java#L13
Expression has \n but it doesn't have \r. Windows new lines are in the form \r\n.
This causes text written as #1\r\n to not get recognized and converted to links by the Issue extension, but it will recognize #1\n and convert it correctly.

GfmUsersInlineParserExtension will have the same issue as it has \n in it.
https://github.com/vsch/flexmark-java/blob/07b83fb84047f7d9add8c729d1006c46517aecda/flexmark-ext-gfm-users/src/main/java/com/vladsch/flexmark/ext/gfm/users/internal/GfmUsersInlineParserExtension.java#L13

@rnveach, thank you for catching it. I used to develop on Windows and was always annoyed when unix utilities failed to work with "\r\n". Now that I am on OS X, I can see how easy it is to miss this.

@rnveach, fixed. Repo updated. Maven update in progress.


KYLIN-4054 Logger of HCreateTableJob record error message

Can one of the admins verify this patch?

Pull Request Test Coverage Report for Build 4656

0 of 33 (0.0%)  changed or added relevant lines in 4 files are covered.
8 unchanged lines in 5 files lost coverage.
Overall coverage increased (+0.0003%) to 28.185%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core-common/src/main/java/org/apache/kylin/common/persistence/JDBCConnectionManager.java
0
2
0.0%

tool/src/main/java/org/apache/kylin/tool/CubeMetaIngester.java
0
4
0.0%

storage-hbase/src/main/java/org/apache/kylin/storage/hbase/steps/CreateHTableJob.java
0
13
0.0%

core-storage/src/main/java/org/apache/kylin/storage/gtrecord/GTCubeStorageQueryBase.java
0
14
0.0%

Files with Coverage Reduction
New Missed Lines
%

core-dictionary/src/main/java/org/apache/kylin/dict/lookup/cache/RocksDBLookupTable.java
1
81.08%

server-base/src/main/java/org/apache/kylin/rest/util/QueryRequestLimits.java
1
47.62%

core-storage/src/main/java/org/apache/kylin/storage/gtrecord/GTCubeStorageQueryBase.java
1
0.0%

core-cube/src/main/java/org/apache/kylin/cube/cuboid/TreeCuboidScheduler.java
2
68.46%

core-cube/src/main/java/org/apache/kylin/cube/inmemcubing/MemDiskStore.java
3
78.42%

Totals

Change from base Build 4655:
0.0003%

Covered Lines:
23256

Relevant Lines:
82513

💛  - Coveralls


crypto/elliptic: deprecate big.Int interface

Exposing big.Ints in crypto/elliptic was a mistake (#52075, #50974, #37294), and the package is slow and not constant time.
I've been running a large remediation project for a few releases to replace the guts of the elliptic curve implementations.
This issue tracks related efforts for Go 1.19. Some related issues:

[ ] #50975
[ ] #34648
[ ] #40171
[ ] #52221

@FiloSottile I have collected numbers to compare your nistec changes + Paul's carry improvements against your nistec changes + asm.
tls:
name                                            old time/op   new time/op   delta
HandshakeServer/RSA                               514µs ± 0%    514µs ± 0%    -0.06%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P256-RSA/TLSv13            1.09ms ± 0%   0.87ms ± 0%   -19.57%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P256-RSA/TLSv12            1.07ms ± 0%   0.82ms ± 0%   -23.21%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P256-ECDSA-P256/TLSv13      917µs ± 0%    511µs ± 0%   -44.25%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P256-ECDSA-P256/TLSv12      857µs ± 0%    460µs ± 0%   -46.33%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-X25519-ECDSA-P256/TLSv13    598µs ± 0%    459µs ± 0%   -23.25%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-X25519-ECDSA-P256/TLSv12    544µs ± 0%    406µs ± 0%   -25.34%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P521-ECDSA-P521/TLSv13     4.87ms ± 0%  11.21ms ± 0%  +129.92%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P521-ECDSA-P521/TLSv12     4.83ms ± 0%  11.16ms ± 0%  +131.19%  (p=1.000 n=1+1)
ecdsa:
name              old time/op    new time/op    delta
Sign/P256            294µs ± 0%     111µs ± 0%   -62.31%  (p=1.000 n=1+1)
Sign/P224            272µs ± 0%     427µs ± 0%   +57.28%  (p=1.000 n=1+1)
Sign/P384            730µs ± 0%    1396µs ± 0%   +91.32%  (p=1.000 n=1+1)
Sign/P521           1.75ms ± 0%    3.87ms ± 0%  +121.13%  (p=1.000 n=1+1)
Verify/P256          474µs ± 0%     255µs ± 0%   -46.10%  (p=1.000 n=1+1)
Verify/P224          443µs ± 0%     744µs ± 0%   +67.88%  (p=1.000 n=1+1)
Verify/P384         1.20ms ± 0%    2.51ms ± 0%  +108.35%  (p=1.000 n=1+1)
Verify/P521         2.93ms ± 0%    7.07ms ± 0%  +141.09%  (p=1.000 n=1+1)
GenerateKey/P256     240µs ± 0%      54µs ± 0%   -77.47%  (p=1.000 n=1+1)
GenerateKey/P224     225µs ± 0%     379µs ± 0%   +68.00%  (p=1.000 n=1+1)
GenerateKey/P384     611µs ± 0%    1279µs ± 0%  +109.33%  (p=1.000 n=1+1)
GenerateKey/P521    1.49ms ± 0%    3.61ms ± 0%  +142.22%  (p=1.000 n=1+1)
elliptic:
name                                old time/op    new time/op    delta
ScalarBaseMult/P256                    237µs ± 0%      52µs ± 0%   -78.22%  (p=1.000 n=1+1)
ScalarBaseMult/P224                    222µs ± 0%     376µs ± 0%   +69.51%  (p=1.000 n=1+1)
ScalarBaseMult/P384                    609µs ± 0%    1276µs ± 0%  +109.65%  (p=1.000 n=1+1)
ScalarBaseMult/P521                   1.49ms ± 0%    3.61ms ± 0%  +142.11%  (p=1.000 n=1+1)
ScalarMult/P256                        239µs ± 0%     213µs ± 0%   -10.95%  (p=1.000 n=1+1)
ScalarMult/P224                        223µs ± 0%     377µs ± 0%   +69.05%  (p=1.000 n=1+1)
ScalarMult/P384                        611µs ± 0%    1278µs ± 0%  +109.24%  (p=1.000 n=1+1)
ScalarMult/P521                       1.49ms ± 0%    3.61ms ± 0%  +141.75%  (p=1.000 n=1+1)
MarshalUnmarshal/P256/Uncompressed    2.17µs ± 0%    1.94µs ± 0%   -10.91%  (p=1.000 n=1+1)
MarshalUnmarshal/P256/Compressed      19.4µs ± 0%    34.4µs ± 0%   +77.02%  (p=1.000 n=1+1)
MarshalUnmarshal/P224/Uncompressed    2.15µs ± 0%    2.47µs ± 0%   +14.86%  (p=1.000 n=1+1)
MarshalUnmarshal/P224/Compressed       208µs ± 0%     328µs ± 0%   +57.94%  (p=1.000 n=1+1)
MarshalUnmarshal/P384/Uncompressed    3.05µs ± 0%    4.02µs ± 0%   +31.89%  (p=1.000 n=1+1)
MarshalUnmarshal/P384/Compressed      47.0µs ± 0%   109.4µs ± 0%  +132.87%  (p=1.000 n=1+1)
MarshalUnmarshal/P521/Uncompressed    4.30µs ± 0%    6.71µs ± 0%   +56.27%  (p=1.000 n=1+1)
MarshalUnmarshal/P521/Compressed       116µs ± 0%     296µs ± 0%  +154.79%  (p=1.000 n=1+1)

It looks like there are several cases where the assembler is better, so I don't think we can abandon the asm implementation this release, especially given that we are running out of time. If we can get the remaining Go optimizations in place so the benchmarks are closer then we can use Go instead of asm at that point maybe in the next release.

@FiloSottile I have collected numbers to compare your nistec changes + Paul's carry improvements against your nistec changes + asm.
tls:
name                                            old time/op   new time/op   delta
HandshakeServer/RSA                               514µs ± 0%    514µs ± 0%    -0.06%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P256-RSA/TLSv13            1.09ms ± 0%   0.87ms ± 0%   -19.57%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P256-RSA/TLSv12            1.07ms ± 0%   0.82ms ± 0%   -23.21%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P256-ECDSA-P256/TLSv13      917µs ± 0%    511µs ± 0%   -44.25%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P256-ECDSA-P256/TLSv12      857µs ± 0%    460µs ± 0%   -46.33%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-X25519-ECDSA-P256/TLSv13    598µs ± 0%    459µs ± 0%   -23.25%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-X25519-ECDSA-P256/TLSv12    544µs ± 0%    406µs ± 0%   -25.34%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P521-ECDSA-P521/TLSv13     4.87ms ± 0%  11.21ms ± 0%  +129.92%  (p=1.000 n=1+1)
HandshakeServer/ECDHE-P521-ECDSA-P521/TLSv12     4.83ms ± 0%  11.16ms ± 0%  +131.19%  (p=1.000 n=1+1)
ecdsa:
name              old time/op    new time/op    delta
Sign/P256            294µs ± 0%     111µs ± 0%   -62.31%  (p=1.000 n=1+1)
Sign/P224            272µs ± 0%     427µs ± 0%   +57.28%  (p=1.000 n=1+1)
Sign/P384            730µs ± 0%    1396µs ± 0%   +91.32%  (p=1.000 n=1+1)
Sign/P521           1.75ms ± 0%    3.87ms ± 0%  +121.13%  (p=1.000 n=1+1)
Verify/P256          474µs ± 0%     255µs ± 0%   -46.10%  (p=1.000 n=1+1)
Verify/P224          443µs ± 0%     744µs ± 0%   +67.88%  (p=1.000 n=1+1)
Verify/P384         1.20ms ± 0%    2.51ms ± 0%  +108.35%  (p=1.000 n=1+1)
Verify/P521         2.93ms ± 0%    7.07ms ± 0%  +141.09%  (p=1.000 n=1+1)
GenerateKey/P256     240µs ± 0%      54µs ± 0%   -77.47%  (p=1.000 n=1+1)
GenerateKey/P224     225µs ± 0%     379µs ± 0%   +68.00%  (p=1.000 n=1+1)
GenerateKey/P384     611µs ± 0%    1279µs ± 0%  +109.33%  (p=1.000 n=1+1)
GenerateKey/P521    1.49ms ± 0%    3.61ms ± 0%  +142.22%  (p=1.000 n=1+1)
elliptic:
name                                old time/op    new time/op    delta
ScalarBaseMult/P256                    237µs ± 0%      52µs ± 0%   -78.22%  (p=1.000 n=1+1)
ScalarBaseMult/P224                    222µs ± 0%     376µs ± 0%   +69.51%  (p=1.000 n=1+1)
ScalarBaseMult/P384                    609µs ± 0%    1276µs ± 0%  +109.65%  (p=1.000 n=1+1)
ScalarBaseMult/P521                   1.49ms ± 0%    3.61ms ± 0%  +142.11%  (p=1.000 n=1+1)
ScalarMult/P256                        239µs ± 0%     213µs ± 0%   -10.95%  (p=1.000 n=1+1)
ScalarMult/P224                        223µs ± 0%     377µs ± 0%   +69.05%  (p=1.000 n=1+1)
ScalarMult/P384                        611µs ± 0%    1278µs ± 0%  +109.24%  (p=1.000 n=1+1)
ScalarMult/P521                       1.49ms ± 0%    3.61ms ± 0%  +141.75%  (p=1.000 n=1+1)
MarshalUnmarshal/P256/Uncompressed    2.17µs ± 0%    1.94µs ± 0%   -10.91%  (p=1.000 n=1+1)
MarshalUnmarshal/P256/Compressed      19.4µs ± 0%    34.4µs ± 0%   +77.02%  (p=1.000 n=1+1)
MarshalUnmarshal/P224/Uncompressed    2.15µs ± 0%    2.47µs ± 0%   +14.86%  (p=1.000 n=1+1)
MarshalUnmarshal/P224/Compressed       208µs ± 0%     328µs ± 0%   +57.94%  (p=1.000 n=1+1)
MarshalUnmarshal/P384/Uncompressed    3.05µs ± 0%    4.02µs ± 0%   +31.89%  (p=1.000 n=1+1)
MarshalUnmarshal/P384/Compressed      47.0µs ± 0%   109.4µs ± 0%  +132.87%  (p=1.000 n=1+1)
MarshalUnmarshal/P521/Uncompressed    4.30µs ± 0%    6.71µs ± 0%   +56.27%  (p=1.000 n=1+1)
MarshalUnmarshal/P521/Compressed       116µs ± 0%     296µs ± 0%  +154.79%  (p=1.000 n=1+1)

It looks like there are several cases where the assembler is better, so I don't think we can abandon the asm implementation this release, especially given that we are running out of time. If we can get the remaining Go optimizations in place so the benchmarks are closer then we can use Go instead of asm at that point maybe in the next release.

Thank you @laboger for the benchmark! The most important line is the ScalarMult one, because that's the one that I can only marginally improve myself, and that one is within 10% of the assembly which is amazing! I can make ScalarBaseMult dramatically faster, and everything else is downstream of that. I filed #52424 to keep track of that. I am also happy to land the updated assembly first to relieve the time pressure. Are the compiler improvements going to land in Go 1.19?

@pmur is working on getting his changes into Go 1.19. Currently he is waiting on reviews.

CC @golang/security
What is the current status here?  This issue is currently in the 1.19 milestone.  Should it move to 1.20?  To Backlog?  Thanks.


Some UI windows are opening up incorrectly scaled to fit their text

Description

Screenshots

Additional context

also happens with viewvars windows

The new UI system can't measure an absolute minimum size for UI controls anymore so we now need to manually specify it via MinSize in the controls. I guess I missed some spots.

Similar to #3294


Build error "Manifest merger failed" - androidx incompatibility?

🐛 Bug Report
When I add the line "geolocator: ^3.0.0" to my pubspec.yaml file (and after I do "flutter packages get") I receive the following build error. This error disappears if I comment out "geolocator: ^3.0.0".
C:\Users\frogr\AndroidStudioProjects\rvtournament\android\app\src\main\AndroidManifest.xml:22:18-91 Error:
	Attribute application@appComponentFactory value=(android.support.v4.app.CoreComponentFactory) from [com.android.support:support-compat:28.0.0] AndroidManifest.xml:22:18-91
	is also present at [androidx.core:core:1.0.1] AndroidManifest.xml:22:18-86 value=(androidx.core.app.CoreComponentFactory).
	Suggestion: add 'tools:replace="android:appComponentFactory"' to <application> element at AndroidManifest.xml:19:5-69:19 to override.
         *********************************************************
WARNING: This version of firebase_analytics will break your Android build if it or its dependencies aren't compatible with AndroidX.
         See https://goo.gl/CP92wY for more information on the problem and how to fix it.
         This warning prints for all Android build failures. The real root cause of the error may be unrelated.
         *********************************************************

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:processDebugManifest'.
> Manifest merger failed : Attribute application@appComponentFactory value=(android.support.v4.app.CoreComponentFactory) from [com.android.support:support-compat:28.0.0] AndroidManifest.xml:22:18-91
  	is also present at [androidx.core:core:1.0.1] AndroidManifest.xml:22:18-86 value=(androidx.core.app.CoreComponentFactory).
  	Suggestion: add 'tools:replace="android:appComponentFactory"' to <application> element at AndroidManifest.xml:19:5-69:19 to override.

The Application tag in my manifest file looks like this:
<application
        android:name="io.flutter.app.FlutterApplication"
        android:label="RV Tournament"
        android:icon="@mipmap/rvt_icon">

As you can see from the errors, I am using the Firebase plugin which breaks applications that have dependencies that are not compatible with androidx. One of the duplicate objects referred to in the error (androidx.core.app.CoreComponentFactory) is part of androidx... so maybe this is related? Is geolocator incompatible with androidx? I see there are earlier issues relating to androidx compatibility, but they are closed.
Expected behavior
No build error.
Reproduction steps
See above.
Configuration
Flutter and packages updated to latest release versions.

This problem is solved in version 3.0.1 of the Geolocator plugin.


Fix dependency versions in README

What was the motivation to add this version column? Any compatibility issue?

To ensure reproducibility across devs, specially with software in 0.x.y such as Cartesi CLI.


Re-write / re-factor the taker heartbeat code

The code to handle heartbeats and re-connect on the taker is complex and might contain bugs.
Re-write and add more tests (also for edge cases).

Closing this as we're moving away from our old networking stack to libp2p, which will use different technique to check maker status.


Expand NVTX usage

Description
This PR improves the experience when profiling MXNet under nvprof or Nsight Systems, by expanding NVTX functionality.
It was used successfully for some time in the NVIDIA NGC container.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] Changes are complete (i.e. I finished coding on this PR)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
[x] To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[x] Added C API for NVTX ranges push/pop
[x] Added C API to start/stop profiling via nvprof/NSight Systems
[x] Added Python API corresponding to the C API
[x] Added automatic ranges to MXNet operators

@mxnet-bot run ci [centos-cpu, miscellaneous]

@ptrendx still WIP?

Yes, I will return back to it sometime next week probably (@DickJC123 is currently merging 1.7 into our codebase and cherry picking stuff after that merge will be easier).

What's the status for this change?

It is currently on hold - I got sidetracked to other things and am not sure exactly when I will have time to finish it - I still intend to do that, though.

@mxnet-bot run ci [unix-cpu]

@mxnet-bot run ci [unix-cpu, website]

@mxnet-bot run ci [unix-cpu, website]

@mxnet-bot run ci [unix-cpu]


Fixing important typo in readme

The .py appears to be important for this example to work.

Coverage remained the same at 34.194% when pulling 05f5e73aeb0afea9687ecb65b05da030db4fc7b8 on kjschiroo:kjschiroo-patch-1 into 1a932f9bb78f56114a83923ae0cc3812afbef783 on slackhq:master.

Thanks!


Add Good First issue

The developer hub should be the easy go to guide for new beginners dev to find new issues daily that is available for all. If they can be find new issues quickly that can be a good feature.
@BamaCharanChhandogi review this issue & assign it to me with proper gssoc & hacktoberfest labels.

👋 Thank you for raising an issue! We appreciate your effort in helping us improve. Our GitFinder team will review it shortly. Stay tuned!

hey @BamaCharanChhandogi what do you think of this feature

@BamaCharanChhandogi hi can you assign me this issue with proper labels of gssoc & hacktoberfest

@BamaCharanChhandogi hey bro can I be assigned this issue

@yashksaini-coder Thanks for showing interest in contributing. But your initial message needs to be a bit more clear about what is developer hub and can you elaborate a bit more on the issue itself than the solution.?

Its already in your github repo desc:-
GitFinder is a vibrant hub for developers, offering a space to showcase projects, discover coding trends, and connect with peers worldwide. Showcase your coding prowess, explore diverse projects, engage in discussions, and stay updated on the latest in the coding community.
Then why don't add the functionality to search for issues, if possible we can implement a search for different labels type. How does this idea sounds ?
@tmsagarofficial

I would say this would be a nice feature.
Thanks for the clarification.
What do you say ? @BamaCharanChhandogi

@tmsagarofficial @BamaCharanChhandogi well can I work on this feature ?

Yeah, go ahead! Sorry for the delay.


feat(backend): Don't wait for transactions to be mined

Previously we were always waiting for the blockchain transactions to be mined before resolving a request to the API.
This started causing major headaches in production, since requests would take 30+ seconds to resolve.
This PR introduces a workflow that just triggers the blockchain transactions on API calls.
It is now the user's responsibility to track the transactions and check when the transactions were mined or not mined.

Need to merge this ASAP.  Will have to skip reviews for now.

Need to merge this ASAP.  Will have to skip reviews for now.


pick support json_keys function

Proposed changes
backport: https://github.com/apache/doris/pull/36411
Issue Number: close #xxx

run buildall

run buildall


Navigation

I tried this with the MkDocs documentation, it generally looks great. The Navigation isn't showing on the left however. I think it might not be working, but perhaps I am doing something wrong?

For now I've left just TOC in the sidebar. That's what http://docs.python-requests.org/ or http://flask.pocoo.org/docs/ use. I just forgot to remove the Navigation header, I'll fix this ASAP.
More navigation options will be added then, probably as a part of configurable sidebar (something like that:)
extra:
  sidebars:
    - about
    - navigation/pocoo # navigation/fabfile, navigation/paramiko
    - searchbox
    - github/star:
        repo: iamale/mkdocs-alabaster

Just pushed the 0.7.1 version to PyPI, removing the header.

Neat. This will be the first theme to take advantage of extra: it was intended just for this purpose - theme authors allowing simple theme configuration.

@iamale Hi, Alex! How hard do you think porting the original Alabaster's navigation.html to MkDocs' version?
We have some long-ass holidays in Russia, so if it's not too hard I'd be happy to do it :-)

@moigagoo Hey, Konstantin! It's not too hard, I think — just me being lazy and some other work being more important. If you want to do it, that's great! And of course you can ask if you need any help. С новым годом!

@iamale Aaand, here you go! https://github.com/iamale/mkdocs-alabaster/pull/15

@moigagoo Thanks, you're awesome! I'll review it tonight.

Fixed via https://github.com/iamale/mkdocs-alabaster/pull/15


refactoring helm chart

Related issues
closes https://github.com/apache/apisix-ingress-controller/issues/209

New feature or improvement
merge base and ingress-apisix helm chart

Codecov Report

Merging #213 (21757b1) into master (549d67d) will increase coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #213      +/-   ##
==========================================
+ Coverage   44.52%   44.62%   +0.09%
==========================================
  Files          32       32
  Lines        2019     2019
==========================================
+ Hits          899      901       +2
+ Misses        981      979       -2
  Partials      139      139

Impacted Files
Coverage Δ

pkg/seven/state/solver.go
3.96% <0.00%> (+1.98%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 549d67d...21757b1. Read the comment docs.

Codecov Report

Merging #213 (21757b1) into master (549d67d) will increase coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #213      +/-   ##
==========================================
+ Coverage   44.52%   44.62%   +0.09%
==========================================
  Files          32       32
  Lines        2019     2019
==========================================
+ Hits          899      901       +2
+ Misses        981      979       -2
  Partials      139      139

Impacted Files
Coverage Δ

pkg/seven/state/solver.go
3.96% <0.00%> (+1.98%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 549d67d...21757b1. Read the comment docs.

@Junnplus The installation of CRDs (and the ClusterRole) should be optional, if we have multiple Ingress controller Deployments, only the first installation should apply them, you can refer to https://github.com/Kong/charts/blob/main/charts/kong/values.yaml#L346 as a reference.

@Junnplus The installation of CRDs (and the ClusterRole) should be optional, if we have multiple Ingress controller Deployments, only the first installation should apply them, you can refer to https://github.com/Kong/charts/blob/main/charts/kong/values.yaml#L346 as a reference.

@tokers installCRDs of kong is for compatibility helm2. this chart require helm 3.0+.

With the arrival of Helm 3, we removed the old crd-install hooks for a more simple methodology. There is now a special directory called crds that you can create in your chart to hold your CRDs. These CRDs are not templated, but will be installed by default when running a helm install for the chart. If the CRD already exists, it will be skipped with a warning. If you wish to skip the CRD installation step, you can pass the --skip-crds flag.

@tokers installCRDs of kong is for compatibility helm2. this chart require helm 3.0+.

With the arrival of Helm 3, we removed the old crd-install hooks for a more simple methodology. There is now a special directory called crds that you can create in your chart to hold your CRDs. These CRDs are not templated, but will be installed by default when running a helm install for the chart. If the CRD already exists, it will be skipped with a warning. If you wish to skip the CRD installation step, you can pass the --skip-crds flag.

@tokers installCRDs of kong is for compatibility helm2. this chart require helm 3.0+.
see more in chart best practices

With the arrival of Helm 3, we removed the old crd-install hooks for a more simple methodology. There is now a special directory called crds that you can create in your chart to hold your CRDs. These CRDs are not templated, but will be installed by default when running a helm install for the chart. If the CRD already exists, it will be skipped with a warning. If you wish to skip the CRD installation step, you can pass the --skip-crds flag.

if need to be compatible helm2, I can make additional pr for it.

Sorry, i'm not so familiar with Helm, just want to know how to skip installing CRDs in helm 3.0+.

@tokers installCRDs of kong is for compatibility helm2. this chart require helm 3.0+.
see more in chart best practices

With the arrival of Helm 3, we removed the old crd-install hooks for a more simple methodology. There is now a special directory called crds that you can create in your chart to hold your CRDs. These CRDs are not templated, but will be installed by default when running a helm install for the chart. If the CRD already exists, it will be skipped with a warning. If you wish to skip the CRD installation step, you can pass the --skip-crds flag.

if need to be compatible helm2, I can make additional pr for it.

Sorry, i'm not so familiar with Helm, just want to know how to skip installing CRDs in helm 3.0+.

@tokers Any other questions?

@tokers Any other questions?

@Junnplus LGTM, will need other reviewers to dome double check. Thank you again!

@Junnplus LGTM, will need other reviewers to dome double check. Thank you again!

@gxthrj Can we merge this PR? cc @tokers

@Junnplus Yes it can be, the broken e2e case is not related with the changes in this PR. It should be fixed in another PR.
@gxthrj

@Junnplus Please update your branch with the newest master, it fixed the broken e2e case, after that, your PR can be merged :)

ping @tokers


Update CloudWatch section with high-resolution metrics and alarms

High-resolution metrics and alarms were added in July. This PR updates the guide to include information about this option.

LGTM!


README update

See also my comments on the SDKs, we need to have all upstream GA for metrics first.


Add support for standalone Thread network creation command.

To achieve that, the following has been implemented:

Added new version of AddNetwork() message - kMsgType_AddNetworkV2.
Implemented mechanism, which automatically resends old version of
AddNetwork() message if the new version of that message is not
supported by the device.
Added new Create Thread Network (create-thread-network) command
to the Python Device Manager.

@jaylogue I have update the implementation following our discussion.


Class 'JsValidator' not found In custom theme

I get an error Class 'JsValidator' not found in resources/views/vendor/canvas/backend/settings/index.blade.php after adding my custom theme (which I forked from https://github.com/cnvs/paper).
There is a line {!! JsValidator::formRequest('Canvas\Http\Requests\SettingsUpdateRequest', '#settings') !!} but when I browse the default layout blade file (vendor/cnvs/paper-dark/resources/views/backend/settings/index.blade.php) this is not included.

The JSValidator class was removed from the main project. If you look at the resources/views directory of Easel, those are the updated views you'll want to use in your custom theme. Make sense?


repository: decouple fs logic from copier

Closes #58
This commit introduces the decouple of fs logic from the copiers, that become a single copier.
Before we had several copiers, one per remote file system. This was problematic because some high-level logic could not be reused and forced us to write again and again the same logic.
Now, we have two pieces that together act as the old copiers.

Filesystems: which are hdfsFs and localFs that fulfill a certain interface that Copier needs to copy from a fs to the other.
Copier: which is no longer an interface, but a struct, that knows how to apply this high level logic of copying from fs A to fs B in the exact same way by using the contract defined by the Fs interface.

In addition to that, CopyFromRemote and CopyToRemote are cancellable now.

Hadoop upgraded again to version 2.7.6.

After discussing a bit with @jfontan we think that maybe we could skip copying the .copy siva file to a tmp dir and just copy it in the same directory and then rename. Engine handles now that and avoids all non .siva files, so it'd be fine.
What do you think?

@kuba-- .copy is deleted when the copy is cancelled, so it should not leave any .copy files unless there's a huge crash that stops the program.
Ok, so I'll get rid of the defer and change the logic so it doesn't copy to a tempdir but directly to the same place :+1:


Message-editor can paste inline images

Requirements

Message-editor allows to paste images as inline content

Pasted screenshot:

Pasted image from image viewer:


Public ip segment

@bhilburn mentioned in #365 that he would be interested in a public ip segment, i hacked one together for review/discussion on behavior/icons/etc. Currently it will only poll for a new IP every 5 minutes which is configurable by the user. It saves the IP to a tmp file also configurable by the user. It will attempt to use dig to get your IP if it's installed, if not it will use either curl or wget to poll an IP checker host in the same manner that neofetch uses. Let me know what you all think.

currently there's no default icon, i think it looks best without one but then I couldn't really find one that seemed appropriate, maybe with an appropriate one it would look better.

I also test killing the internet connection and it will still attempt to get a new IP at each timeout interval but it fails silently. This was the best behavior I could work out for not having a connection to the internet, input is very welcome with regards to how to handle that =]

Nice work, @rjorgenson! Very cool to see this get put together so quickly, and I think this will be really useful for our sysadmin users out there.
I just left some questions in a small review =)

@bhilburn I updated the offline behavior to the best solution I could get without removing the timeout feature altogether. If you are kicked offline it will continue to show your last known IP until the timeout expires, after that it will display nothing by default, but this can be configured by the user and continue to check for a new IP each time the segment is generated until it gets an IP and the timeout will reset. A user can set the timeout to 0 to have a real time polling with every new prompt of their public IP as well. Then they would notice as soon as they get disconnected.
If this behavior sounds good to you then I'll write up a section in the README on it. I'm still not sure on an icon for this segment, or if it even needs one. Any input on that?

@rjorgenson - The new changes look great, and the final scheme sounds good. Let's proceed with this.
As for an icon, I just looked through all of the code points in Font Awesome and the standard UTF icons, and didn't see anything obvious. Go ahead and create the icon point in P9k, but we can leave it blank until we come up with something - I'm okay merging it without an icon.
@dritter - Any ideas?

Okay I've written up the README section. Writing isn't my strongest so if any of that could be changed to make more sense let me know =]
I've also added the ability to specify a particular method and only ever attempt to use that method. This may save a bit of time if you know a particular method will always be available.

Whew, that was a lot of issue I noticed after my last comment =/ I think I got everything though .. i hope lol

As this segment is related to the (internal) ip segment (which we should rename at some point), I have a couple quick ideas regarding the icon:

We could use the signal icon, as the internal ip segment (mis)uses the rss icon (at least in awesome-patched mode). Patched-Codepoint is \uE129.

We could use the wifi icon, but that would work in awesome-fontconfig mode only (not in patched font included).

We could use a "radio tower" (don't know the name) icon (\uE830 in patched), but we should save that for a gnuradio segment ( 😉  @bhilburn ):

We could use the rss icon as well, but set a different default color for the visual identifier.

But I am good to go with no icon as well.

Hah! Thanks for the gnuradio reference, @dritter!
I'm so-so on our icon choices so far - to me, they all imply a wireless connection, which may not be the case.
What do folks think about just using the @ sign? In lieu of that, I think we should just go with no icon.

Yes, I agree. These are not the best symbols, but there are no ethernet icons in awesome terminal fonts. ;)
I am ambivalent with the @ sign, as this must stand before the address, but the visual identifier stands before the segment only in left aligned ones. We could (of course) put that into the segments content, but then it would be hard to override.

@dritter - Great point. The @ sign isn't a great choice.
Let's roll without an icon for now, @rjorgenson.

No icon sounds good to me =] Just went over it again and pretty sure it's ready to merge. If anyone else wants to pull this PR and do some user testing in case I missed any bits that would probably be helpful =]

Thanks for another great contribution, @rjorgenson! Excited to have this merged.


bosh stop detects deployment changes

If you are using a deployment with version latest for either release or stemcell in the manifest, the diff algorithm will complain about deployment changes when calling bosh stop.
$ bosh stop
Acting as user 'admin' on deployment 'dummy' on 'my-bosh'
You are about to stop all jobs

Detecting deployment changes
----------------------------
Releases
No changes

Compilation
No changes

Update
No changes

Resource pools
No changes

Disk pools
No changes

Networks
No changes

Jobs
No changes

Properties
No changes

Stemcells
No changes

Instance groups
No changes

Cannot perform job management when other deployment changes are present. Please use '--force' to override.

Deployment manifest extract:
releases:
- name: dummy
  version: latest

stemcells:
- alias: trusty
  os: ubuntu-trusty
  version: latest

This diff algorithm should not complain if latest is used as version value, either for release or for stemcell.
This was tested with the current ruby bosh cli 1.3262.4.0

This also applies for bosh start

@cppforlife It was just an observation. I did not investigate.

It's possible that, when there's a "latest" version, bosh treats the actual version as more recent. To find out, export the actual manifest (bosh download manifest <some-release> > <temporary-file>) and compare the versions to those in your manifest file. If there's a difference, that's what bosh is complaining about. It would be better if bosh told us which value in the manifest it was unhappy about.

Hey @Kiemes @voelzmo is this still an issue you are seeing?

It was probably related to the ruby cli requiring a manifest for commands such as bosh stop, so I guess we can close this one.


Support native builds on Apple silicon

Hey Wim!
This tool is great! Just wanted to flag an issue in case it helps others who might come across it.
Installation via brew worked great, but when when attempting to run ttcli init I received the following:
zsh: bad CPU type in executable: ttcli
I'm on a new M2 Pro chip (first Mac in years), and Google leads me to believe this is a somewhat common issue. The commonly suggested fix I came across was to install Rosetta 2. This doable via the CLI: softwareupdate --install-rosetta
After running that installation the original ttcli init command worked great.
Not sure if this is anything you're able to address on your end, but hope it helps other folks who might be new to Apple's ARM chips like myself.
Really enjoying Taming Thymeleaf -- thanks for putting out such a great book!

Thanks for letting me know, I still have an Intel mac, but I'll see what I can do. Glad you have found a workaround for now.

Seems there is no GitHub-hosted runner available to build for Apple silicon at present. See https://github.com/github/roadmap/issues/528 which is currently scheduled for Q4 2023.

@wimdeblauwe GitHub runners are now available 🎉

Seems it is not yet available for free for public projects:
https://github.com/actions/runner-images/issues/8439#issuecomment-1755601587
Op wo 25 okt. 2023 om 21:40 schreef Tom Beckett @.***>

@wimdeblauwe https://github.com/wimdeblauwe GitHub runners are now
available 🎉
—
Reply to this email directly, view it on GitHub
https://github.com/wimdeblauwe/ttcli/issues/29#issuecomment-1779936820,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIQNL37SW7UWDY226QDNVLYBFTKHAVCNFSM6AAAAAAXYOSINCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZZHEZTMOBSGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Seems it is not yet available for free for public projects:

You can use the FlyCI's M1 and M2 runners. Our runners are on average 2x faster and 2x cheaper than GitHub's AND we have a free tier for OSS projects (see below).
Install Instructrions
Easily replace your M1 runners:
jobs:
 ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m1
   steps:
   - name: 👀 Checkout repo
     uses: actions/checkout@v4

Or try the M2 runners:
jobs:
  ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m2
    steps:
      - name: 👀 Checkout repo
        uses: actions/checkout@v4

Pricing

Processor
vCPU
RAM (GB)
Storage
Label
Price on FlyCI
Price on GitHub

M1
4
7
28 GB
flyci-macos-large-latest-m1
$0.06
-

M1
8
14
28 GB
flyci-macos-xlarge-latest-m1
$0.12
$0.16

M2
4
7
28 GB
flyci-macos-large-latest-m2
$0.08
-

M2
8
14
28 GB
flyci-macos-xlarge-latest-m2
$0.16
-

500 mins/month Free for Public Repos
If your repo is public, then FlyCI offers 500 mins/month of free M1 runner usage with the flyci-macos-large-latest-m1 runner.
Best Regards,
Kiril Gantchev
CEO and co-founder of FlyCI

I created a test build for Apple silicon since that is now officially supported on GitHub : https://github.com/wimdeblauwe/ttcli/actions/runs/7731468595
Could somebody that has such a device try the build to see if it works?

I created a test build for Apple silicon since that is now officially supported on GitHub : https://github.com/wimdeblauwe/ttcli/actions/runs/7731468595
Could somebody that has such a device try the build to see if it works?

Looks good (M1 running macOs Sonoma 14.2.1):
christian@MacBook Temp % ./ttcli init
? Group:  com.test
? Artifact:  test-project
? Project Name:  Test Project
? Select Spring Boot version 3.2.2
? Select live reload implementation: npm-based-with-tailwind-css
? Web dependencies alpinejs,htmx
? Tailwind dependencies forms
🍃 Generating Spring Boot project
🛠  Using node v18.14.0 with npm 9.3.1
🔨 Installing npm dependencies
👷♂ Adding npm build scripts
👷🏻♀ Updating Maven pom.xml
🔨 Installing npm dependencies
✅ Done generating project at /Users/christian/Temp/./test-project

See HELP.md in the generated project for additional information.

There is one error in the logs. But it seemingly had no negative impact. I can open and start the generated project using IntelliJ without any issues.
ttcli.log

Ok, thanks for testing @ChristianHuff-DEV !

Version 1.1.1 is now released with native Apple silicon (M1/M2/M3) builds. You can download it from the releases, or use homebrew.


[Bug] - Duplicate Pipeline schedules

Describe the bug
We have a GitLab project, and the pipeline of this project needs to run once a day in order to achieve a defined task. In order to achieve daily runs we are using Scheduled pipelines (Gitlabform Pipeline schedules).
With the following configuration, every time the pipeline runs, it creates a new schedule every 2nd time
some-project:

    # Periodic execution Schedule
    schedules:
        "Daily":
            description: "Execute Pipeline daily, to avoid configuration divergence"
             ref: main
             cron: 0 3 * * * # Daily at 3:00 AM
             active: true

Observation,

First Run: Schedule created with Description Daily
Second Run: Schedule updated with Description Execute Pipeline daily, to avoid configuration divergence
Total Schedules: 1

Third Run: Schedule created with Description Daily
Fourth Run: Schedule updated with Description Execute Pipeline daily, to avoid configuration divergence
Total Schedules: 2

Working Fix
Schedules works as expected after changing the configuration to (description attribute has been removed) :
some-project:

    # Periodic execution Schedule
    schedules:
        "Daily":
             ref: main
             cron: 0 3 * * * # Daily at 3:00 AM
             active: true

GitLabForm version
🏗 GitLabForm version: 3.5.0 = the latest stable 😊
GitLab version
GitLab Enterprise Edition 15.8.0-ee
Credits:
Working fix provided by (Removing description attribute) - Aver Mimas (@amimas)

Yes I agree @gdubicki 😊|