Support remote components and turn component manager on

This adds the ability to specify remote components in the Cargo.toml and the esp-idf component manager is now turned on by default, and it will manage all such remote components (specified on the Rust side, or in esp-idf components).
I've changed the template cmake project structure to turn the component manager on. It now uses the normal project setup with project.cmake. It should, in theory, work the exact same, though I haven't tested all of it.
Remote components make use of the component manager, and its component_idf.yml file. All specified remote_components actually map to equivalent entries in that file.
They can be specified with the remote_component field in an extra component, e.g.:
[[package.metadata.esp-idf-sys.extra_components]]
remote_component = { name = "espressif/mdns", version = "1.2" }

Note though that remote_component does not accept a list. If you want to have multiple remote components, use multiple extra component entries.
Other than that, the syntax that @daggerrz suggested in https://github.com/esp-rs/esp-idf-sys/pull/220 and https://github.com/esp-rs/embuild/pull/78 is still supported, though component_refs is now remote_component.
See the docs for all supported fields (the same as the dependencies section in the idf_component.yml).
As I said, some more testing is still needed, it would be appreciated.
Feedback is also appreciated.
Fixes #193

I finally got back and was able to test this. I see the components are downloaded properly, and are part of the build path, but the cfg set is the file system "projection" / direcotry name of the component FQN. E.g for espressif/mdns, the cfg is esp_idf_comp_espressif__mdns_enabled
This does not line up with bindings.h in esp-idf-sys:
https://github.com/esp-rs/esp-idf-sys/blob/7704c645456662821551a5972ae3d3c64e551216/src/include/esp-idf/bindings.h#L183
and in lib.rs in esp-idf-svc:
https://github.com/esp-rs/esp-idf-svc/blob/cf0b85c7d92c7382cd87d5abb6b3a1bede70de6f/src/lib.rs#L59
I'm not sure if it's better to use the "bare" component name in the cfg to make it compatible with the current bindings or to update the bindings.
For reference, from the build logs:
[esp-idf-sys 0.33.1] cargo:rustc-cfg=esp_idf_comp_espressif__mdns_enabled

Thanks for testing it.
Yeah, I noticed this aswell. As far as I see it, we could:

If we want to support the existing component names, add an exception to espressif/* components, so that we also define the same component without the espressif__ prefix.
This would only be worth it if we expect further components to become remote components, and/or there are many cfgs for these components already in the code.

As you said, change the #[cfg]s in the code.

I really don't know how much of an effect these name changes have. And whether there will be more and many. Maybe @ivmarkov knows more?

Specifically ESP_IDF_COMP_MDNS_ENABLED we can't change as we are supporting ESP IDF V4.4 where this component is built in.
How about just adding || esp_idf_comp_espressif__mdns_enabled (in uppercase of course) and then Instruments g esp-idf-svc to check both cfgs? I'm not sure we'll see a flood of components leaving the ESP IDF monorepo, so maybe let's not boil the ocean as of yet, just because of mdns?

How about just adding || esp_idf_comp_espressif__mdns_enabled (in uppercase of course) and then Instrumenting esp-idf-svc to check both cfgs? I'm not sure we'll see a flood of components leaving the ESP IDF monorepo, so maybe let's not boil the ocean as of yet, just because of mdns?

I think this would be very clear in terms of the esp-idf-svc code and the solution that has the least potential to cause future confusion due to component name conflict (although it's probably extremely unlikely in the first case). As more components are moved out of IDF, the esp_idf_comp_espressif__ prefix in the cfgs will make it easy for maintainers immediately identify that a component has in fact been moved out.
It would also make it easy spot new components that are only "remote" and exist for 5.x that don't exist / have to be maintained in 4.4 at all, but still are added to esp-idf-svc (as opposed to a litany of binding crates).
// IDF Provided component.
#ifdef ESP_IDF_COMP_{component}_ENABLED
...

// Component migrated from IDF to remote in 5.x+, but IDF provided in 4.4
#if defined(ESP_IDF_COMP_{component}_ENABLED) || defined(ESP_IDF_COMP_espressif_{component}_ENABLED)
...

// Remote-only component, only available in 5.x+
#ifdef ESP_IDF_COMP_{namespace}_{component}_ENABLED
...

Can confirm that the current brand works as expected if the cfgs also are updated in esp-idf-svc. E.g: https://github.com/esp-rs/esp-idf-svc/commit/c69726e14227fd604e6cbf49a255df6e90f3df0b

@N3xed, just wanted to make sure you saw the comment over in https://github.com/esp-rs/esp-idf-sys/issues/231#issuecomment-1676189581. It's possible (perhaps likely) I was doing something wrong, but adding this to Config.toml:
[[package.metadata.esp-idf-sys.extra_components]]
espressif_tinyusb = { name = "espressif/tinyusb", version = "0.15.0_2" }
espressif_esp_tinyusb = { name = "espressif/esp_tinyusb", version = "1.3.1" }

Resulted in invalid cfg keys being set (the . in the version number is invalid):
[issue231 0.1.0] cargo:rustc-cfg=esp_idf_comp_espressif_tinyusb_0.15.0_2_enabled
[issue231 0.1.0] cargo:rustc-cfg=esp_idf_comp_espressif_esp_tinyusb_1.3.1_enabled
error: invalid `--cfg` argument: `esp_idf_comp_espressif_tinyusb_0.15.0_2_enabled` (expected `key` or `key="value"`)

This should be set without the version number, but I suspect that's something happening with ESP-IDF.

@N3xed, just wanted to make sure you saw the comment over in #231 (comment). It's possible (perhaps likely) I was doing something wrong, but adding this to Config.toml:
[[package.metadata.esp-idf-sys.extra_components]]
espressif_tinyusb = { name = "espressif/tinyusb", version = "0.15.0_2" }
espressif_esp_tinyusb = { name = "espressif/esp_tinyusb", version = "1.3.1" }

Resulted in invalid cfg keys being set (the . in the version number is invalid):
[issue231 0.1.0] cargo:rustc-cfg=esp_idf_comp_espressif_tinyusb_0.15.0_2_enabled
[issue231 0.1.0] cargo:rustc-cfg=esp_idf_comp_espressif_esp_tinyusb_1.3.1_enabled
error: invalid `--cfg` argument: `esp_idf_comp_espressif_tinyusb_0.15.0_2_enabled` (expected `key` or `key="value"`)

This should be set without the version number, but I suspect that's something happening with ESP-IDF.

Yup, I saw it. Haven't had time to get to it yet, though. I'll investigate this and try to finish the PR next weekend.

@dacut I just commented in #231 and it seems to me this is a unrelated issue.
So, this PR seems ready to be merged. I'll do it in the coming days if there are no further issues.

@N3xed Sounds good to me. I was probably "holding it wrong" as you point out. 😄


build multi pg version images

build and publish images for pg 14, 15, 16...

duplicate of https://github.com/tembo-io/pgmq/issues/137


Check pre-installed containers running on the same Docker engine to avoid port conflicts

Please, check that there are no containers pre-installed on the same Docker engine and use the same port.
Pre-requisite: enable network creation/configuration to avoid random dev-containers failures.
Some Docker engine providers pre-install some Containers in the Docker engine which use the pre-defined ports. The example is MongoDB: RedHat gives it with CentOS and Docker maybe for the demo purposes or for fun. The port on the Doker host can be busy because it is default port. Attempt to run dev-container will fail randomly. Unpleasant, but docker ps is unavoidable before deployment.
I think that it is not fair to require the usage of only blank engines.
Sorry, docker always comes with the docker networking and every container has to respect the rules.
To completely isolate docker dev-container None driver must be used but what about testing?
To partially isolate dev container a vs-code-dev attachable network has to be created instead of default bridge . and dev-containers have to be connected to it on-the-fly.

The good news here is that none of the containers in this repository map ports directly to the OS anymore. The Node + Mongo definition instead uses forwardPorts in devcontainer.json which will pick a different port if the specified port is already in use.

@Chuxel Unfortunately, nothing can help user developer if developer doesn't know what he/she does. The very common scenario is developer wants to test several images providing HTTP services and every image exposes container port 80 as most such images. The the common way to do i them on the same engine mapping port exposed 80 to ports 7070, 8080, 9090, etc. The port exposed in the docker file only designates the kind of provided interface, HTTP, HTTPS, JDBC.
In the default scenario when container is attached to the bridge network this port can be mapped to the same port on the bridge it ends in conflict even before port node port binding because Docker engine will try to create chains in underlaying iptables configuration during container instance creation.
This is one of the reasons to follow the safe rule: one container -> one role -> one interface one exposed port -> one mapped port per network. This scenario is supported by Swarm out-pf-the-box because the same ports are mapped by the same manner for all instances of service without conflicts by the Docker engine.
If Swarm mode is activated containers are attached by default to ingress network.
All this information is supplied by docker ps docker then docker container inspect and docker network inspect  that return json formatted output if --format option is used but it is not a single line solution, see:
docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' $INSTANCE_ID
Podman supports mapping of port intrervals but shortcut -p 80:80 doesn't work in this scenario. --expose option has to be used

Please post the specific error you are running into. Forward ports is intended to be used so that you don't have to worry about any of this by forwarding the port rather than publishing it. It automatically uses the appropriate local port.


[CDS-73230] Documentation for CDS-72492 - Enhancement Create ServiceN…

…ow with ServiceNow Template to consider the metadata of the attributes in Template (epic 30% done 2023-09-28)
Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the CODEOWNERS.
What Type of PR is This?

[ ] Issue
[x] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

CDS-73230

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[x] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app


Use double hyphens in flags

all-in-one is fine because it does not use any flags.
production will fail because latest is not being published currently.

It seems that standard go flags accept long flags with -- and - so there is actually no breaking change

It seems that standard go flags accept long flags with -- and - so there is actually no breaking change

This means, it should work with the latest images? If so, I'm OK with this change as long as @kevinearls or @jkandasa confirm that it works with the latest available images (ie: that this template isn't broken in master).

This means, it should work with the latest images?

Yes it should work, see CI passed. (It might be good to print image sha in tests.)

see https://github.com/jaegertracing/jaeger-kubernetes/pull/27

Yes it should work, see CI passed.

I wasn't sure the tests were active for this repository. LGTM then!

I have restarted the build (now it prints images versions). If that pass It could be merged.


Non-latin characters in Projects

Hi all,
thank you for great app.
I have updated the server to v0.24.0 an android app to 0.1.5-beta.
I have issue with non-latain characters in Project. The project name is not correctly shown.
Can someone help me please?
Thank you
Robert

Do you have the same problem in the web frontend?

Can you reproduce this on https://try.vikunja.io?
If so, please share the non-latin characters that cause issues so I can reproduce this.

Hi,
I have tried to add the German chars on the web https://try.vikunja.io and with android app with same server address.
The chars are correctly shown on the web, not in app. Chars not correctly shown: ü ö ä á ě š and more
Thank you

Same problem with Scandinavian letters like Æ, Ø and Å.

App 0.1.6-beta still has this issue with server version v0.24.0-1-e16b1356ba

Most text look like UTF-8 was displayed in ASCII

Text in reminder
Task title
Project title

Frontend displays the same values correctly

I believe this answer might be relevant here: https://stackoverflow.com/a/75646925/733440
https://github.com/go-vikunja/app/blob/4771de1a339f0bd26dfb1dbb50cde4332b8c10bf/lib/api/client.dart#L222-L226

Can you download the newest version here and try, please? It should fix that. @belidzs you were right, that was the issue, thanks!
https://github.com/go-vikunja/app/actions/runs/10240054475

Nice, issue seems to be gone now

Can you download the newest version here and try, please? It should fix that. @belidzs you were right, that was the issue, thanks!
https://github.com/go-vikunja/app/actions/runs/10240054475

It's working for me too. Thanks


What dataset did you use?

Thank you @JohnleeHIT ,
Where can I download the dataset to run the code?
Thank you @JohnleeHIT .

Hi, Thanks for your attention! Actually, we used an inhouse ICH dataset, which we will make it available to the public for a challenge in the future. Thanks.


Release Community meeting recording (November)

To double check

Recording is ordered (should be last one)
Recording has description

Meeting’s agenda:
This meeting’s agenda:
- 1.18 released
  - SLSA level 3
  - Deprecation of v1alpha2
  - CRD short names
- What’s coming next
- General:
  - Kubecon NA Kubewarden booth

Recording link
https://zoom.us/rec/share/Odgos8iuKzSHNMmkFPvPInqILFu6dUWqoPaR4l4LcLl-ljINmkLsjqKFeJjkIvJ-.hBiW9KrEHwFokJ05

On it now.

This is done.


Support UTF-8 charset in ShapefileReader

This PR contains the bugfix to solve the unreadable character in shapefile reader. See Issue https://github.com/DataSystemsLab/GeoSpark/issues/190
If you are working with Arabic, Chinese or Korean character sets in ESRI shapefile, you need to force GeoSpark shapefile reader to use UTF-8 charset.
Add the following line before GeoSpark ShapefileReader:
System.setProperty("geospark.global.charset","utf8")

Does it need to be set in each executor?

now you should write like this:
System.setProperty("sedona.global.charset","utf8")


EA tag moves [too early] during ramp down phase ... so EA builds no longer validate the next JDK release?

3 days ago the EA tag moved from version 23 to 24, noting that JDK 23 is not actually released until Sept 17th - approx 2 months away.
This means that from now until Sept 17 any project building using the EA tag is not actually validating the next JDK to be released which is JDK 23 and still 2 months away (as builds using EA are instead now building against 24-EA).
Q: Is this 2 month gap / window in terms of EA build validating the next released version an issue?
Q: Was the EA tag moved too early to 24-EA meaning that project builds against EA are not actually validating against JDK 23 for the next 2 months until the next release?
Q: Should there be another version tag that is like EA but would not actually change until the actual release date?

The symbolic EA and GA tag names (read: values for the release input of this action) work as intended: they point to the latest-and-greatest JDK offered by the website selected by the workflow. In case of jdk.java.net this means the versions right next to the colon of the frontpage of https://jdk.java.net/

Ready for use: JDK 22, JavaFX 22, JMC 9
Early access: JDK 24, JDK 23, JavaFX 23, Jextract, Loom, & Valhalla

22 for GA
24 for EA

If you want to ensure a specific JDK is used, please specify the feature relase number explitely. Here, this action doesn't make a difference between the status of the JDK. For example, 24 stays 24 - no matter if it is in early-access, rampdown, or general-availability state.
This workflow show-cases how to configure this action "across various well-known JDK version": https://github.com/junit-team/junit5/blob/abf5ac3f2e17911bd932f020d2726b01d3c68a6b/.github/workflows/cross-version.yml#L2
[...]
jobs:
  openjdk:
      matrix:
        jdk: [ 22, 23, 24 ]
    runs-on: ubuntu-latest
    steps:
[...]
      - name: 'Set up JDK ${{ matrix.jdk }}'
        uses: oracle-actions/setup-java@v1
        with:
          website: jdk.java.net
          release: ${{ matrix.jdk }}
          version: latest
[...]

Q: Should there be another version tag that is like EA but would not actually change until the actual release date?

Suppose there was such a RD tag. What would be its value for when there is no JDK in rampdown phase?
    Last week: EA=23  RD= ?  GA=22
        Today: EA=24  RD=23  GA=22
On 2024-09-17: EA=24  RD= ?  GA=23

What if there was a sort of EA-main tag that tracks the mainline and a regular EA that tracks the mainline until RD and RC.
It would behave like
Last week: EA-main=23  EA=23  GA=22
Today: EA-main=24  EA=23  GA=22
On 2024-09-17: EA-main=24  EA=24  GA=23

If you want to ensure a specific JDK is used, please specify the feature release number explicitly.

We have an action on all our repositories that periodically test with GA/EA versions. It's quite the hassle to change all those repos every time something goes into RD/RC and additionally when that non-LTS version becomes EOL.
We want to be able to automatically test with the current mainline and any JDK that is in RD/RC. In this way, we would be empowered to provide useful feedback during those phases without needing to constantly keep changing every single one of our repositories.

If you want to ensure a specific JDK is used, please specify the feature relase number explitely.

Just to add that we just have too many builds/libraries to manually adjust the version for a ramp down phase. That is, all our libraries have their own EA build and so I'm talking probably 25+ builds (avaje libraries and ebean orm libraries). The EA and GA tags in this respect are great, moving these versions ourselves across all our builds isn't actually practical.
So yes I think we are really hoping for another tag that is most of the time the same as EA (so there is probably a lot of overlap there) but then follows the version that is about to be released.
FWIW I personally don't mind if there is "overlap" like EA and EA-main point to the same thing 75% of the time. I'm just aware that all our builds are now in that "gap" and are not actually testing 23 and won't actively be testing 23 until it becomes GA. Having this ~2 month "gap" does not sound right.

To imagine the ideal scenario, our GitHub workflow EA/GA builds would somehow detect when they are in a ramp down period and now they build against both EA (which is now 24-EA) and the release candidate (which is now 23).  So in this period they perform that extra build.

Support for R (with: website:'jdk.java.net' release:'R') ...

... 22 was added on 2023-06-11 and it is still valid.
... 23 was added on 2023-12-08 and it will be valid for almost a year.
... 24 was added on 2024-06-08 and it will be valid for over a year.

Those time frames usually span over a year and are large enough to be considered quasi-stable; especially in a project that uses a shorter, namely 6 month, release cadence. Thus, you get what you specify. I hesitate to introduce another symbolic name to this action for a slightly different meaning for "EA" with respect to RD and RC phases; as the backing website dictates the underlying anyway.

To imagine the ideal scenario, our GitHub workflow EA/GA builds would somehow [...]

An interesting idea! So, what about setting up custom values for your GitHub workflow matrix like shown above?
For maintaining a few workflow definitions and for use-cases that target specific releases, it's okay to specify hard-coded values:
jobs:
  my-jdk-ea-tests:
      matrix:
        jdk: [ 22, 23, 24 ]

Now replace with [ 22, 23, 24 ] with something like {{ NUMBERS }} and let NUMBERS be either [ 23 ] or [ 23, 24 ] or anything else you want, for example include the latest-and-greatest loom early-access builds via [ 23, 24, loom ].

Having said that and looking at the composed keys defined in jdk.java.net-uri.properties ...
#
# Early-Access Releases (Alias)
#
...
23,latest,windows,x64=https://download.java.net/java/early_access/jdk23/26/GPL/openjdk-23-ea+26_windows-x64_bin.zip
...
24,latest,windows,x64=https://download.java.net/java/early_access/jdk24/1/GPL/openjdk-24-ea+1_windows-x64_bin.zip
...
ea,latest,windows,x64=https://download.java.net/java/early_access/jdk24/1/GPL/openjdk-24-ea+1_windows-x64_bin.zip

... I do see chance to introduce for ea,stable,... combination that would keep pointing to the early-access build in all phases until it goes GA. Any ideas for a better name than "stable"? 🤔

@rbygrave and @SentryMan can you please give version: stable a try?


Sema: Don't require properties to have initializers in classes in module interfaces

Avoid requiring properties to have initializers in @requires_stored_property_inits classes when type checking module interfaces. Most initializers are not printed in interfaces so enforcing this requirement in that context doesn't make sense.
Resolves rdar://91505142

@swift-ci please test

@swift-ci please test

@swift-ci please smoke test


cmsis_dap.prefer_v1 is only effective in config file

Setting cmsis_dap.prefer_v1 in pyocd.yaml works fine.
for example, like this.
cmsis_dap.prefer_v1: true

Specifying it in the command line has no effect.
-O cmsis_dap.prefer_v1=true
This is because at this point what it gets is a default session object which do not carry information from _args.options .
In the document it is stated "primarily intended for testing" . so its behaviour need not be fixed, but then the documentation needs fix.

Thanks for pointing this out. 😄


Warnings when installing

Me and my peers are seeing the following warnings when running:
npm install pretty-swag -g

One of its dependencies need to be updated. I'll patch it this evening.
Thanks for reporting.

Thank you for updating and maintaining this tool!

No problem. Turned out those warning are from highlight.js which can be tracked here: https://github.com/highlightjs/highlight.js/issues/1369

v0.2.2 should not have these complains anymore


Allow NOC Addenda Type entries for WEB

What were you trying to do?
Attempting to load an ACH file, containing NOC entries for SEC Code WEB
What did you expect to see?
I expected to see a valid ach.File with the correct contents.
What did you see?
 *ach.BatchError: BatchNumber 1 TypeCode 98 found in addenda and expecting 98 for batch type WEB

How can we reproduce the problem?
// TestBatchWEBAddendum98 validates Addenda98 returns an error
func TestBatchWEBAddendum98(t *testing.T) {
	mockBatch := NewBatchWEB(mockBatchWEBHeader())
	mockBatch.AddEntry(mockWEBEntryDetail())
	mockBatch.GetEntries()[0].AddAddenda(mockAddenda98())
	if err := mockBatch.Create(); err != nil {
		t.Errorf("%T: %s", err, err)
	}
}

Will be fixed with issue # 323


Run the examples against the GCS fake.

The examples should run against the fake to avoid
bitrot.

@houglum PTAL.


NavigationView Overlay mode shifts contents as border appears

Describe the bug

When you toggle the NavigationView pane and it appears overlaid.  The pane gains rounded corners and a border outline.  This shifts the NavigationViewItems
Steps to reproduce the bug

Steps to reproduce the behavior:

MUXTestApp > NavigationView > Navigation IsPaneOpen Test
Toggle the navigation pane open and closed with the Hamburger Button
Observe the Settings item at the bottom as well as the Home and Apps icons

Expected behavior

NavigationViewItems should maintain their horizontal and vertical positions as the pane slides open and closed.
Screenshots

Toggled Closed - (Settings icon is crisp)

Toggled Open - (Settings icon is blurry)

Top NavigationViewItems seem to be shifted down by 1px - Bottom items up by 1px

Version Info

NuGet package version:

Current Main branch built Fri 18 Jun 2021

Windows app type:

UWP
Win32

 Yes

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

October 2020 Update (19042)

May 2020 Update (19041)

November 2019 Update (18363)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

21H1
Yes

Device form factor
Saw the problem?

Desktop
 Yes

Xbox

Surface Hub

IoT

Additional context

I believe the problem is that the border around the pane does not exist in the closed state, and adding it on toggle, is repositioning the items.  Perhaps if the border were present in both modes, but set to transparent when closed, and coloured/filled on opening.  So the position of the items takes into account the border thickness.

@karenbtlai FYI

@mdtauk Thanks for the investigation! You are completely correct in the additional context part. I can send a fix for that along with my other PR :)


Warning daikin-cloud has an invalid jsonConfig

since i installed the new adapter, i see the following warnings in my logfiles:
admin.0 | 2024-07-05 17:03:08.874 |
warn |
daikin-cloud has an invalid jsonConfig: [{"instancePath":"/items/_authenticate","schemaPath":"#/definitions/sendToProps/additionalProperties","keyword":"additionalProperties","params":{"additionalProperty":"window"},"message":"must NOT have additional properties"},{"instancePath":"","schemaPath":"#/if","keyword":"if","params":{"failingKeyword":"else"},"message":"must match "else" schema"}]

Yes thats an issue in the json schema of jsonconfig

duplicate https://github.com/ioBroker/ioBroker.admin/issues/2538


Create TypeScript type(s) that represent code blocks

Main Goal
We need TypeScript types (similar to structs and classes in C++) that represent the following UML model:

Code Block Types Documentation
This document outlines the TypeScript types used for representing code blocks in the "Code Conductor" application.
Enum: CodeBlockType
CodeBlockType is an enumeration that defines the different kinds of code blocks available in the application. It includes options like WHILE, IF, and STATEMENT, representing the various control and operational structures in the visual algorithm builder.
type: BaseBlock
BaseBlock serves as the foundational class for all types of code blocks. It includes properties for identification, type specification, labeling, and holding nested blocks. Each BaseBlock can have an array of children, allowing for the creation of nested structures within the algorithm.
type: ControlBlock
ControlBlock extends from BaseBlock and is specialized for control structures like If and While blocks. It includes an additional property to specify the conditional expression that governs the control flow in these blocks.
type: StatementBlock
StatementBlock, another extension of BaseBlock, is tailored for statement operations. It carries a property that holds the specific action or code the block is meant to execute. This class is pivotal for representing simple actions or operations within the algorithm.

Here's an example of a TypeScript type that represents a Point with x and y coordinates as an example:
type Point = {
    x: number;
    y: number;
    name: string;
}

let myPoint: Point = {
    x: 2,
    y: 5,
    name: 'My Favorite Point'
}

You might need to look into how to do inheritance in TypeScript.
Files to modify
You're only allowed to modify:

src/components/block/types.ts

The Enum BlockType is already created so you don't need to worry about that.

Issue closed with PR #20


Toggle does nothing upon first click if in Problem panel

Hello,
First off, thank you! I was really hoping exactly this extension existed, and it does. Very nice.
Now to the issue.. When I'm in the Problem panel (or tab? not sure what the right word is) and I click the icon, nothing happens upon the first click.
It only goes to the Terminal panel upon clicking a second time.
Not a big deal, but I'd have expected it to go the terminal panel upon the first click?
Thanks in advance!

Oh, I just read your Readme and I see that it's a known issue. No worries! Still a great extensions. Thanks again. Closing as this is a known issue.

Sorry if this is a dumb question, but I just realized that the Ctrl+`  shortcut to toggle the Terminal does not exhibit the same issue. That is, when the "Problem" panel is open, typing Ctrl+`  jumps straight to the Terminal.
Would it be possible to get the icon to behave exactly like the Ctrl + `  shortcut?

Hello,
Thanks for your kind comments.
 Actually, ctrl +` (View: Toggle Terminal command: workbench.action.terminal.toggleTerminal) was my first choice as well. :smile:
Initially, I tried to simply execute that command in the extension. But that command does not seem to toggle the terminal once the focus is on the terminal. (found an old issue discussing about the command behavior).
I also tried to look for the API/how the command is implemented, and unfortunately I couldn't find that either.
So, I have posted my question today on the VS Code discussion section for workarounds. Need to wait and see if there are better solutions to this issue.
Thanks

Thanks @krish-r for looking into it!!

So, I have posted my https://github.com/microsoft/vscode-discussions/discussions/478 today on the VS Code discussion section for workarounds. Need to wait and see if there are better solutions to this issue.

Hello,
I received response from VS Code developers, looks like there isn't a workaround as of now.
(I will watch out for updates on https://github.com/microsoft/vscode/issues/117980.)
Thanks


Fixes/enhancements to regions plugin.

I'm modifying this for my own use and thought it could use a few additions and enhancements. More to come.
1] Fix for cursor fighting when dragging.
Previously, default cursor sometimes fought with dragging cursor, resulting in flickering cursors. The main issue here is that there is a cursor assigned to each region and there's no overall action state. This is actually a fairly complex problem. More work will be required to handle extreme edge cases. (although, it is already better than current code in that respect)
2] New events. region-resized-start and region-resized-end:
These will trigger when the region start or end is resized.
3a] New options. resizeStart and resizeEnd:
These determine whether the resize start and resize end control is created. (Sometimes, you might not want both)
3b] More new options: cssResizeStyle, cssResizeStartClass, cssResizeEndClass.
Optional parameters to change the default style of the resize controls. cssResizeStyle will overwrite the default style added to each resize control. cssResizeStartClass and cssResizeEndClass will add classes to the start/end controls.
4] Still more new options: showTitle.
Optional parameter showTitle. Default is true. If false, title will not be shown.

This is a real hassle. Is there a way to just have it auto-format?

Those are all good changes and useful options. Could you maybe add all of the changes to the next branch? We would like to make it the new master it in June.
Also, the code style is off in some places: inline objects need spacing inside, the void in unnecessary. I thought we had linting for this 🤔

Is there a tool I can use to convert the code using those options? Using
this code style is a huge hassle.
On May 29, 2017 4:52 AM, "katspaugh"<EMAIL_ADDRESS>wrote:

Those are all good changes and useful options. Could you maybe add all of
the changes to the next branch? We would like to make it the new master
it in June.
Also, the code style is off in some places: inline objects need spacing
inside, the void in unnecessary. I thought we had linting for this 🤔
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/katspaugh/wavesurfer.js/pull/1103#issuecomment-304609376,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADFJWAgUmPOZZCSikZtrJbi5xXV_CvRMks5r-odpgaJpZM4NnZX2
.

Well, it's not even particular to this code style. Just in general. Idk. I
know there's prettydiff but that doesn't do all the things in the styling
requirements that you need...
On May 29, 2017 5:50 AM, "Michael Romanovsky"<EMAIL_ADDRESS>wrote:

Is there a tool I can use to convert the code using those options? Using
this code style is a huge hassle.
On May 29, 2017 4:52 AM, "katspaugh"<EMAIL_ADDRESS>wrote:

Those are all good changes and useful options. Could you maybe add all of
the changes to the next branch? We would like to make it the new master
it in June.
Also, the code style is off in some places: inline objects need spacing
inside, the void in unnecessary. I thought we had linting for this 🤔
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/katspaugh/wavesurfer.js/pull/1103#issuecomment-304609376,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADFJWAgUmPOZZCSikZtrJbi5xXV_CvRMks5r-odpgaJpZM4NnZX2
.

eslint --fix should be able to auto-fix the code style.

It does not work without a void, or I am guessing an extra pair of parentheses.
I made a few more changes:

Instead of duplicating the fireEvent calls, I created a fireEventPropagate function. But then there are issues: what about remove+region-removed, and update+region-updated? It's not really consistent as the click event firings (dubious usefulness..) don't have that kind of structure -- it's the same for both the wavesurfer and region object.

Optimized onDrag and onResize code.

The update function will now only call the updateRender function if something actually changed.

P.S.: Once I am done working on this... pretty close now... I'll make the changes in the other branch.
The only question now is the events. They are not backward-compatible since I changed a few of them from past-tense to present in order to standardize everything.

I think we can change the names in the next branch, since the plugin init code has changed anyway.

Great. Thanks. I think the edits are pretty much done now. I just added a mechanism to prevent the seek cursor from moving if the mouse is released. I also split up drag into dragstart and drag (after the cursor has moved) for future-proofing...

Thanks! I'll need to check and test it, will get back to you.

Sorry -- one more change.

Actually, a few errors with the latest change, but I am falling asleep... tomorrow.

@katspaugh: Another idea on the events:
A slider function I made has the parameter that states whether the update is final (i.e.: user does mouseup, etc.) as the last parameter.

Duration of a clip? Timestamp?
???
@katspaugh : ok. So I dunno what is up with all these extra files. But anyway, I have a new file right here:
https://github.com/agamemnus/wavesurfer.js/blob/master/plugin/wavesurfer.regions.js
(There are quite a lot of changes. It's much improved... one thing I did recently was replace the multiple document mouseup/mousedown event listeners in favor of a single unified listener.)

I have once more updated my code at:
https://github.com/agamemnus/wavesurfer.js/blob/master/plugin/wavesurfer.regions.js
Bueller!

Closing as too many things have changed.
Moving this to https://github.com/katspaugh/wavesurfer.js/pull/1211.


Feature/misc changes

Misc changes from the meeting.

Removed (commented out) DOI related functions, revert https://github.com/dockstore/dockstore-ui2/commit/14ec76240cba3bb4da5cf2951cd5221db8f5b082 when it's needed once more.

Removed classic Dockstore.

Codecov Report

Merging #218 into develop will decrease coverage by 0.02%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop     #218      +/-   ##
===========================================
- Coverage    61.29%   61.26%   -0.03%
===========================================
  Files          106      106
  Lines         3175     3173       -2
  Branches       411      411
===========================================
- Hits          1946     1944       -2
  Misses        1016     1016
  Partials       213      213

Impacted Files
Coverage Δ

src/app/footer/footer.component.ts
62.5% <100%> (-4.17%)
:arrow_down:

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 e3e4289...235d44e. Read the comment docs.


Point Cloud or Pixmap Lens Model

The first pixmap implementation is made.  See also #86 for a different, specific approach.


Change array<int...> to list<...> in PHP doc

Ref: comment https://github.com/sabre-io/event/pull/113#discussion_r1393915303

What we can do, is done in PR #116


PDF Rendering not properly (JavaFX + pdf.js)

Hi,
i am using Java (with IDE Intellij) + JavaFx. + last build of pdf.js.

When i try to render the pdf, the layout-rendering is wrong. As you can see.
It is like if pdf.js make a "re-format" of my file.

Does your pdf file work in the online demo of pdf.js?
According to this FAQ entry, whatever JavaScript engine is used by JavaFX may not be supported by this project.


Refactor into a Serverless plugin and provide example handlers as individual Serverless functions

It seems to make a lot of sense to turn serverless-chrome into a Serverless plugin.
The plugin would hook into the Serverless after:createDeploymentArtifacts life cycle event and wrap around the handler function. The wrapper would then make sure that headless Chrome is running before calling the wrapped handler function.
https://serverless.com/framework/docs/providers/aws/guide/plugins/

[ ] refactor chrome bundle and chrome spawning into a Serverless plugin
[x] update for nodejs v6.10 (and remove Buffer.from hack/polyfill)
[ ] remove serverless-webpack plugin dependency
[ ] create Serverless functions for each example handler
[ ] change postinstall script to create serverless.yml instead of config.js from one of the example serverless.yml files

Can you reconsider using serverless, as that adds an opinionated framework? Perhaps just node-lambda or apex?

It would be nice to keep this without any framework dependency, particularly Serverless which is rather opinionated. Moreover, there's no current support in Serverless for versioning and aliases, which are integral to many AWS Lambda projects.

Thanks for the feedback, @bluepeter! I agree with your request. I don't know whether I'd encourage no framework because deploying to Lambda manually isn't particularly scalable/automate-able. However, I do intend to add support for at least a few more popular lambda-deployment tools. At least a couple from this list: Apex, Claudia.js, Gordon, Shep, DEEP, node-lambda, and/or Chalice.
The best way to make it possible to support multiple frameworks without too much code duplication, is to pull out the lambda-specific code for spawing a chrome process into it's own npm package that also bundles the headless chrome binary. This would open up the possibility for someone to easily roll their own custom solution using their own custom way of deploying to Lambda (which would satisfy your request.)
Furthermore, I also aim to make this project provider-less (e.g. support Azure and/or GCP) which is where having a framework like Serverless helps. As a consequence of these goals, this repository will end up being a mono-repo. I haven't documented this up anywhere, but here's my short-term roadmap for the project (over the next 2-4 weeks, notwithstanding changes as a result of feedback):

A Serverless-framework plugin which deals with bundling and spawning Chrome (via aforementioned lambda-headless-chrome npm package)
Add a few examples of how to do various things like capture a screenshot and save to S3, or how to manipulate DOM and/or do scraping or some testing
Add support for another framework (I think Apex—again, via the lambda-headless-chrome npm package)

Actually, thinking about this some more.. the npm lambda-bundle would almost make the support for  frameworks like Serverless or Apex a bit redundant outside perhaps of some optimisations for each framework.. Perhaps that's what you were suggesting, @bluepeter...
E.g. given the npm package, one's lambda code could be agnostic to the framework..
require('lambda-headless-chrome')(chromeFlagsOrConfigOptionsOrWhatever)
// or
const chrome = require('lambda-headless-chrome')

const someKindOfEventEmitter = chrome(chromeFlagsOrConfigOptions)
someKindOfEventEmitter.on('epic crash or something', () => { ... })

module.exports.handler = (event, context, done) {
    // do chrome-y stuff
    done()
}

I think this is definitely the right approach. Eager to see your progress on this!

Not sure what your progress has been on this, but I cobbled together a candidate npm module based on your implementation:
https://github.com/chriszarate/aws-lambda-headless-chrome
It bundles chrome-remote-interface and returns a promise that provides a CDP client:
const lambdaChrome = require('lambda-chrome');
lambdaChrome({/* overriding options */).then(client => {
  const { Emulation, Page, Runtime } = client;
  /* do stuff */
});

A more complete example is in the repo (example.js). It doesn't implement an event emitter as you were discussing above, but I'm not exactly clear on the use case for that, especially if the CDP client is being provided.
Thoughts? I'd love to help push this forward but I don't want to create the module myself without your input—not least because I'm not set up to compile Chrome yet and am just warehousing your binaries. :)

Hi @chriszarate,
Thanks for reaching out. Nice work on aws-lambda-headless-chrome!
I like your clean, simple implementation! I noticed that you decompress the tarball during the Lambda invocation. Be aware that this may add tens to hundres of milliseconds to the time consumed by the handler during it's cold-start invocaton. Perhaps consider bundling the decompressed version in the lambda function's package.zip.
As an aside: I saw a comment in your readme about the 50MB file-size limits imposed by Lambda on the package size. I was lead to believe the same thing by the limits described in the AWS Lambda Limits documentation, but it seems like it may be a "soft" limit. I've successfully deployed packages that are 95MB!
This project's progress on a standalone npm package is under the v1.0 branch
You can try it out with npm or yarn:
yarn add @serverless-chrome/lambda

Then use it in a Lambda function's handler:
const launchChrome = require('@serverless-chrome/lambda')
const CDP = require('chrome-remote-interface')

module.exports.handler = function handler (event, context, callback) {
  launchChrome({
    flags: ['--window-size=1280x1696', '--hide-scrollbars']
  })
  .then((chrome) => {
    // Chrome is now running on localhost:9222

    CDP.Version()
      .then((versionInfo) => {
        callback(null, {
          versionInfo,
        })
      })
      .catch((error) => {
        callback(error)
      })
  })
  .catch((error) => {
    // Chrome didn't launch correctly

    callback(error)
  })
}

Just like you, I dropped the event emitter; it doesn't really make much sense. Furthermore, if you keep an event listener bound to the spawned Chrome process, the Lambda function won't end correctly as it'll just keep running waiting for events from Chrome until the execution timeout occurs.
I decided against bundling CDP straight into package. For example, you might want to connect two instances of CDP to two different tabs—so I leave connecting to Chrome up to the user. This gives the maximum flexibility for how a developer can use the module. The implementation in the v1.0 branch uses the Lighthouse Chrome Launcher to spawn the headless_shell binary when run in the Lambda execution environment. The launcher tries to find another Chrome binary when run locally. This makes it convenient to develop locally with a local install of Chrome, or Chrome Canary. It also manages to start up Chrome much quicker than my original implementation. Shaves off between 500 to 1500ms!
So far I've only tested the @serverless-chrome/lambda module in a "vanilla" Lambda function and with the Serverless-framework. The Serverless-framework example is here. Only the version-info handler is complete thus far, but demonstrates how you can use it.
With all that said, I'm definitely open to collaboration and PRs! For example I'd love to hear your feedback on using the @serverless-chrome/lambda package, ways to improve it, or to get together a ClaudiaJS usage example function in the functions) collection.

Thanks for the response and feedback! Not sure how I missed your commit from earlier in the day.
RE: Lambda package size limits, I'll have to investigate that further. I definitely received a "too large" error response from Lambda when trying to package the decompressed binary. It's possible this error was specific to Claudia or something else in my environment. Perhaps this soft limit varies by AWS region?
The Lighthouse launcher logic and speed sounds great! Definitely makes sense to standardize on an "official" approach to launching.
I'll give your package a spin using Claudia and report back, possibly with a PR with an example for the collection.
One question: Is the plan to eventually publish to NPM unscoped, or will this remain a scoped package?

@chriszarate About the "soft limit"—I've only tried in us-west-2 region but I doubt AWS would have variable "soft limits" in different regions. Not sure..
I'm undecided about the package scope. What are your thoughts?

@adieuadieu Hmm ... I got a chance to test the size limits again, with consistent results. It definitely points to the limits being variable—if not by region then perhaps by account.
I created a 64MB file resistant to compression:
dd if=/dev/urandom of=file.txt bs=1048576 count=64

Including this file in my payload, both for us-east-1 and us-west-2, resulted in the following error response:
{
  message: 'Request must be smaller than 69905067 bytes for the CreateFunction operation',
  code: 'RequestEntityTooLargeException',
  time: 2017-06-02T21:42:17.259Z,
  requestId: '...',
  statusCode: 413,
  retryable: false,
  retryDelay: 74.10051249271442
}

I had a thought that perhaps only CreateFunction enforced the limit, but UpdateFunctionCode did not. However, creating a small function first, then adding the large file and updating, resulted in the same error.
(Curiously, the limit reported by the error message works out to 66.67 MB, which is also larger than the stated limit. Perhaps they are rolling out size increases on a fractional basis.)
As for the package scope, I think unscoped packages feel more "official," but that's purely anecdotal. Since it's discoverable via npmjs.com, I don't think it matters much.

@chriszarate nice the size limit investigation! It's interesting that you're unable to upload over 50 MB. Here's a screenshot of some of my Lambda functions, over 50MB:

What's noteworthy is that these functions are deployed via the Serverless-framework tool, which uses CloudFormation to update the Lambda stack, and involves uploading the function's code package to S3. Perhaps the size limit is more lenient when done via S3? In the screenshot, the function with the 66.3MB code-size includes both the headless chrome and ffmpeg binaries.

@adieuadieu That's it! ClaudiaJS, by default, uploads the payload directly. However, it provides an option to upload via S3. Testing again, I was able to upload a larger payload:
claudia create --use-s3-bucket my-bucket --handler index.handler

Since your npm package includes the uncompressed binary, Claudia will in effect require the use of the --use-s3-bucket to successfully upload. That's a small price to pay for the resulting increase in spin-up speed, however.
I'll put together a PR with a Claudia example.

@chriszarate nice! One thing I'm not clear on: Claudia doesn't produce a packaged zip file of the function code? I've left the headless chrome binary uncompressed in the npm package because my assumption was that it'll get compressed when the lambda function zip package is created—and there's really no compression benefit from double-zipping.

@adieuadieu Claudia does package a zip file (the test files I created were from /dev/random and therefore didn't compress much at all).
Leaving the binary uncompressed is not an issue; Claudia compresses that as expected. What I am seeing is that using Lighthouse as a dependency increases the payload size significantly. Using @serverless-chrome/lambda and about 2K of my code, bundling with Claudia produces zipped payload in the neighorhood of 85MB. This works when uploading via S3, but isn't ideal.
I notice that your use of serverless has a Webpack build step. I'm guessing that effectively does some tree-shaking to reduce to payload size. Claudia doesn't have a Webpack integration (I'm using Node 6.10–compatible ES2015 code) so I think it ends up bundling all of Lighthouse.

@chriszarate thanks for the follow up. I've been working on the serverless-framework plugin and had similar concerns about the amount of dependencies Lighthouse introduces. Although the plugin will only include the minimum node modules that are required to run, it still adds about 500KB to the bundle. I end up having to make a whitelist of stuff to include which I think is a bit brittle.
In Claudia, do you have any control over what gets included in the zip? In other words, are you able to include only the actual dependencies and not also devDependencies in the zip? When I cherry pick out only the actual dependencies, with @serverless-chrome/lambda, I end up with a zip that's  around 49MB. 47 or so of that is Chrome.
Anyway, I'm already thinking about removing the lighthouse dependency in @serverless-chrome/lambda. It brings along tons of it's own dependencies and just makes everything more complicated. However, it does make it easy to enable local development. So I'm torn.

A quick follow-up<EMAIL_ADDRESS>included this feature which should make it easier to keep devDependencies out of the function artefacts when using Serverless.

Hi, thanks for all the work you've done! I was wondering if anyone could direct me to a web-scraping example (eg just rendering the DOM and returning it) of serverless-chrome that is deployable to aws lambda? I've been tinkering around with your package for a little while but haven't had much luck


Alpha Release

Tracking issue for features required for ALPHA release
See corresponding issue uisautomation/university-media-deploy#17 for deployment requirements

[ ] Add endpoint for redirecting legacy SMS media pages (#82)
[ ] Add alpha badge (#81)

Moved to alpha milestone


📃: SQUID GAME

🔴 Title :SQUID GAME(using three.js)
🔴 Tech stack :HTML,CSS ,JS(three.js)
🔴 Objective :Simple game based of on a popular Netfilx seires called "Squid Game".
🔴 Summary :This 3D game incorporates immersive sound effects, The objective is to reach the end of the challenging course as quickly as possible , and the first player to cross the finish line will emerge victorious.
📸 Screenshots

✅ Details to Include When Taking the Issue:
Name :KETAN KUMAR
Participant Role (CONTRIBUTOR)

Happy Contributing! 🚀
Wishing you all the best on your open source journey. Enjoy! 😎

already present


Destroy method for SPA web sites

Describe the solution you'd like
Method for destroy lib requestAnimationFrame and future reinitialize lib.
Additional context
After closing modal window the canvas destroy, but when I open modal window again and run JEEFACEFILTERAPI.init the jeelizFaceFilter throw error

Hi,
JEEFACEFILTERAPI.init is quite heavy because It has to get the neural network model (NNC.json) which is quite heavy, and to instantiate a lot of stuffs.
So for optimization purpose, I strongly advice to initialize it once and for all.

When you do not use it, you call JEEFACEFILTERAPI.toggle_pause(...) to stop/restart the rendering loop
You unmount the canvas element from the DOM when the popup is closed, and you mount it to the new popup when it is open.

But with react, using the standard component cycle handlers (ComponentDidMount, componentShouldUpdate etc...) it is very doable.


WIP Masonry: Add support for pin leveling

After talking through pin leveling with @jportella93, I was inspired to take a crack at it. It's hard. 😅
This PR does a few things:

Combines the existing positionStore and a new heightAdjustmentStore into a single itemAttributeStore. We should probably fold the measurementStore into this eventually.
Attempts to identify the two items just above the 2-col module and passes along the necessary heightAdjustment based on the additionalWhitespace
Adjusts the layout position of the 2-col module to take up the additional whitespace

But there are problems. I'm not sure if this will be technically possible given the current constraint that item heights cannot change after the first render. This is leads to overlapping items. There are a couple of possible solutions I see to this:

Introduce some way for items to communicate changes in their height to Masonry. This feels gross.
Only lay out a 2-col module in a large enough batch of items that it includes the items just above the module. We would adjust the layout of the target items and update their heights in the measurementStore, and optimistically assume that the item height was adjusted correctly in userland. This feels brittle.

I don't really like either of these solutions. 😕 But I'm also not sure what would be a better approach.
Overlapping pins, I think because they're still honoring their original heights

the whitespace here was so large that an additional pin could fit in it, leading to targeting the wrong item

I'm going to close it and sav the PR for future reference.


Provide transition module for java/jakarta.activation

Environment Details

Helidon Version: 2.2.1

Problem Description
External libraries being migrated from JDK 8 to JDK 11 may have dependency on java.activation JPMS module buried somewhere deep in their dependency tree. To help these libraries move to Helidon 2.x and JDK 11, it may be useful to provide transition module, ie something having just following module-info with appropriate maven dependency defined:
module java.activation {
    requires transitive jakarta.activation;
}

We don not plan on addressing this.


unreachable code after return statement

What kind of change does this PR introduce?
Remove an assumed typo
What is the current behavior?
no impact
What is the new behavior?
no impact

Thanks!


open-xr dependency needs to be updated to avoid building error: 'wayland-client.h' not found

open-xr build fails when building in openSUSE Tumbleweed because cmake is not able to find 'wayland-client.h' on /usr/include because it is on  /usr/include/wayland.
The issue is fixed upstream on this PR:

https://github.com/KhronosGroup/OpenXR-SDK-Source/pull/346

That fix does not have a release version yet, it is on main. So I suggest updating lovr/deps/open-xr to the latest commit to get the fix.
This is the cmake build log with the error if you want to check it:

https://gist.github.com/RiQuY/d744905540c31f57efeab2e9b142299a

This fix was released in version 1.0.27 of the OpenXR SDK.  LÖVR's OpenXR submodule is currently at 1.0.30 (55224479ab13db8ebc8ab1e3d49197bce6201b0b), which is the latest commit on main.  It looks like the fix is already included, right?  Or am I missing something?

This fix was released in version 1.0.27 of the OpenXR SDK. LÖVR's OpenXR submodule is currently at 1.0.30 (55224479ab13db8ebc8ab1e3d49197bce6201b0b). It looks like the fix is already included, right? Or am I missing something?

You are right, I had read Jan 20, 2023 like 2024. Sorry about that. If this is the case, I don't know why it is still happening.

I read 2023 as 2024 too at first haha.
I uninstalled libwayland-dev and I got the same error you did, but if did cmake .. -DBUILD_WITH_WAYLAND_HEADERS=OFF then everything works.  Since LÖVR doesn't use wayland and OpenXR's wayland stuff is weird anyway, I think BUILD_WITH_WAYLAND_HEADERS could be set to OFF in LÖVR's CMakeLists.txt.

I read 2023 as 2024 too at first haha.
I uninstalled libwayland-dev and I got the same error you did, but if did cmake .. -DBUILD_WITH_WAYLAND_HEADERS=OFF then everything works. Since LÖVR doesn't use wayland and OpenXR's wayland stuff is weird anyway, I think BUILD_WITH_WAYLAND_HEADERS could be set to OFF in LÖVR's CMakeLists.txt.

I bumped OpenXR to 1.0.33 on dev and set BUILD_WITH_WAYLAND_HEADERS to OFF as well.  Let me know if you're still having problems.  Thanks for the issue!

@bjornbytes Sorry for answering so late. I tried building it again using the latest commit on dev branch but I've got a new error.
These are the commands I ran:
❯ git clone https://github.com/bjornbytes/lovr.git
❯ cd lovr
❯ git submodule update --init --recursive
❯ mkdir build
❯ cd build
❯ cmake ..
❯ cmake --build .

Related error:
[100%] Building C object plugins/lovr-http/CMakeFiles/http.dir/http.c.o
/media/Almacen/Programas/lovr/plugins/lovr-http/http.c:468:10: error fatal: curl/curl.h: No existe el fichero o el directorio
  468 | #include <curl/curl.h>
      |          ^~~~~~~~~~~~~
compilación terminada.
gmake[2]: *** [plugins/lovr-http/CMakeFiles/http.dir/build.make:76: plugins/lovr-http/CMakeFiles/http.dir/http.c.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1974: plugins/lovr-http/CMakeFiles/http.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

Full cmake build log:

https://gist.github.com/RiQuY/5563321d0a9fc5d36ad9c52ac99a205c

That's coming from lovr-http, which is an optional component (plugin).  If you don't need HTTP you can remove the lovr-http folder from the plugins colder and it won't build.  That warning is safe to ignore though, lovr-http is designed to work with older versions of curl for the time being, since some Debian distributions don't have 7.85 yet.


Adding netcore50 TFM to support RTM UAP template

cc @natemcmaster

:shipit: (after travis checks out)


after logout token is not getting expired able to hit apis and get data

Describe the bug

if I do global sign out of cognito, library not able to know that the token is expired when I do any update call to cognito via access token then it is the token expired but the library not able to catch it

Versions
version - 4.0.0
using - node js
node version - above 18
typescript version - 5.2.2
To Reproduce

login to application in two browsers
logout from one of them --> used global signout of cognito
The token is not expired, it can pass aws-verify library
but if I call cognito with that access token cognito is throwing token expired

Thanks for reporting this. We do not consider this behavior a bug though, this is expected behavior. This library verifies the JWT using the user pool's public key, but does not check with the user pool if the token was revoked. This is because this library is intended to be used in API endpoints, where you need this check to be as fast as possible.
This behavior is consistent with most JWT verification implementations. In many auth scenario's it's not desirable to also check the upstream IDP for token revocation, as that would add latency––and defeats the purpose of JWT. One of the best selling points of JWT is, that you can verify them very fast locally (using cryptographic verification), without needing to reach out to the issuing IDP (except once initially to get the IDPs public key, to verify the JWTs with).
Adding this check against the IDP, Cognito in this case, is possible, but you probably want to add some caching, say of 5 minutes, to not have to reach out to Cognito everytime you see the same JWT. However another, better, approach then is to configure the Cognito JWTs have an expiry of only 5 minutes. Same end result, but a faster and simpler implementation.
That's the general answer to this particular concern (related to the concern of JWTs being stolen): a short expiry is your best mitigation against threats.
Anyway be that as it may, we can also see that there's cases where you'd want to do the effort of verifying a JWT upstream with the IDP. However currently Cognito doesn't have an endpoint that allows you to check a JWT like that (but you could check it by testing the JWT against an actual Cognito endpoint, if it works it's valid). That however is not part of this library, nor have we yet been convinced that it should.
Hope that explanation helps!


Fix highlighting when showing the commit message

I had issues with highlighting on light background and fixed them.
Issue https://github.com/NeogitOrg/neogit/issues/807 describes a similar problem and can IMHO be closed.

Cool :) I dig the change


Adds a list of restricted usernames that won't generate links

Since these names are used for group mentions, don't create links to a user.
Maybe we should add some sort of highlight for these names?

This is published in markdownz 2.2.0


Storing OAuth token in secrets manager?

I'm opening this issue to inquire whether you would be open to merging a PR that implements an option to store the OAuth token in a Secrets Manager (e.g. AWS Secrets Manager, Github Secrets or Terraform Cloud Workspace Variables) instead of the local config. This would facilitate managing OAuth authorization and token creation from a local computer, while making the token seamlessly available to a remote server running email-oauth2-proxy. It would also facilitate persisting the token if the remote server needs to be destroyed and recreated.
As mentioned in a prior issue, I've been working on an infrastructure-as-code project which uses Terraform to automatically configure an AWS server running email-oauth2-proxy. I've just made a first version of my work public at: michaelstepner/email-oauth2-proxy-aws.
As you might anticipate, the biggest limitation of my automated server configuration is authenticating with the email provider to obtain OAuth tokens. Thanks to your prior work, after creating the lightweight server I'm able to authenticate manually via SSH using --no-gui and --local-server-auth. But I would love to configure a more elegant solution someday.
I wouldn't ask you to implement this yourself, of course, unless you were interested in doing so.
Implementation
I considered a command-line argument, but I'm currently envisioning a per-account configuration option like token_store below:
<EMAIL_ADDRESS>permission_url = https://login.microsoftonline.com/common/oauth2/v2.0/authorize
token_url = https://login.microsoftonline.com/common/oauth2/v2.0/token
oauth2_scope = https://outlook.office365.com/IMAP.AccessAsUser.All https://outlook.office365.com/SMTP.Send offline_access
redirect_uri = http://localhost
client_id = *** your client id here ***
client_secret = *** your client secret here ***
token_store = aws_secrets_manager

If that configuration option were left unspecified, it would default to local and the behaviour would follow the status quo, storing the token in the config file. This would preserve backward compatibility, and maintain simplicity for the majority of users who are using this software as a local client in their system tray.
Additional configuration required for the secrets manager could either be via environment variables (e.g. credentials for access to the secrets manager) or the configuration file.

Thanks for your thoughtful and thorough reply! I'll respond in-line:

My key concern before merging would be about overcomplicating the proxy – I'm quite keen to keep it as simple and focused as reasonably possible, so if it's a straightforward change to add this capability then I'd be open to it, but if it would end up drawing in lots more dependencies and adding lots of extra complexity then I'd be less keen.

I think the extra dependencies and complication would be minimal.

Dependencies: For example, to use AWS Secrets Manager would bring in a dependency on boto3.
Code complications: I think changes would be limited to OAuth2Helper.get_oauth2_credentials. In my quick skim, it seems this function is solely responsible for fetching and storing the OAuth2 token. Adding the option for a secrets manager would mean fetching and storing from a difference source.

How would you actually store the four required OAuth values? (access_token, access_token_expiry, refresh_token and token_salt). The set of valid email address characters doesn't match the set of permitted key name characters in the secrets managers I looked at, so you'd need some sort of mapping here (or an additional value in the configuration file).

One possible design would be to store all tokens in a valid JSON string, like:
{
   "email1@example.com":{
      "access_token":"QWERYUIOP",
      "access_token_expiry":1234567890,
      "refresh_token":"ASDFGHJKL",
      "token_salt":"ZXCVBNM"
   },
   "email2@example.com":{
      "access_token":"QWERYUIOP",
      "access_token_expiry":1234567890,
      "refresh_token":"ASDFGHJKL",
      "token_salt":"ZXCVBNM"
   }
}

The key for the secret could either be:

hardcoded
optionally configurable on an application-wide basis

via an env variable, or
via a config option within [Server setup]

I'm also interested in how you'd surface the token request to the user. I agree that being able to manage this remotely without needing to ssh into a server and authenticate is a benefit, but what would the interaction flow look like from the client's point of view? Would they have to manually generate and process the authentication request?

I was thinking that a user could install email-oauth2-proxy locally and remotely, configuring both to use the same secrets store. Then if you successfully authenticate locally, the tokens are stored in the secret store and immediately available to the remote server.
I think this idea was inspired by rclone authorize, which I've used in my work.

As it happens, I was recently thinking about how to achieve this with a plugin (not yet committed, but see the plugins branch for the basic capabilities) – essentially it could trigger an email to the account when there is an authentication request, and then intercept an email reply from the user with the updated authentication response in the body. This is a little similar to how Gmail allows security alert emails to be retrieved via IMAP even when everything else is blocked because of that security alert. Of course, this is a bit of a hack, but it makes the user side very easy, which is I think an important factor.

This is really clever, I love this idea. I think it would be complementary to a secrets manager, since the secrets manager would still facilitate persisting the tokens across multiple servers (ex: a local and remote server, or re-creating the remote server without re-authenticating). However, it might entirely obviate the need for a secrets manager, since re-authenticating a remote server would become much less of a hassle.

Between something like this and the POP branch, this sounds like exactly what I was looking for. GMail still hasn't implemented OAuth2 for GMail POP3 and I'm about to lose access to my personal O365 tenant email because Microsoft is deprecating basic auth.
I was hoping to deploy email-oauth2-proxy as an Azure Function/AWS Lambda but that would require a place to store the OAuth values, and a secrets manager is what I was thinking for that, but I hadn't thought about the implications and reading this thread I would have seriously underestimated them!
All that being said, I realized I may have jumped to a conclusion - how is email-oauth2-proxy designed to be/typically deployed? Maybe it's simpler to use a laptop or a Raspberry Pi or something and have it run locally.

The proxy was initially designed for my own personal use on a desktop/laptop because I was going to lose access to O365 through a client I would find it difficult to do without. As a result it is GUI-first, with a menu bar icon and interactive authentication screen. For this reason (and the other challenges discussed earlier in this issue thread) it could be quite painful to use a secrets manager effectively. So, yes, if you're able to use the proxy locally that may well be simpler.
Do you have a typo in your comment – "GMail still hasn't implemented OAuth2 for GMail POP3"? Gmail definitely does support OAuth for POP3, so perhaps you meant a specific client here? Regardless, the POP branch will almost certainly be merged once I've had chance to complete the implementation, so you should have full support via the proxy.

@billbliss You may wish to check out my work at michaelstepner/email-oauth2-proxy-aws. I built upon @simonrob's wonderful work on making a local client and deployed it to an EC2 instance for my use case: I wanted to provide access to O365 to my favourite cloud email provider which had not implemented OAuth2.
You were hoping to use a serverless framework like Azure Functions or AWS Lambda. That would indeed would be cheaper, but struck me as very difficult to implement for SMTP since it is not an HTTP-based API. I therefore used the cheapest AWS instance available to set up a server, and the final cost for me is around US$4 per month (no guarantees as to your costs, of course).
I've fully documented the installation steps in the README of michaelstepner/email-oauth2-proxy-aws, and it's 100% functional for me. Adding a feature to store credentials in a secrets manager would streamline the installation and quarterly config refresh, but if you're willing to tolerate a bit of manual config via SSH, I think my installation guide would get you up and running.

Sweet! I will take a look. A quarterly SSH isn’t too bad. Spaced on the “those protocols aren’t http” but obviously too. Thx!

Another option here could just be to synchronise the config file between instances of the proxy. You'd get the benefits of shared credentials but the proxy changes required would be far more minor.

Excellent! Thanks for the work on this - great to see you found an approach with minimal impact to the proxy's core features. Let me know how you get on; happy to review fully after that with a view to merging.

Reopening this issue now that I've tested my implementation of this feature and opened PR #114.
@simonrob I welcome your feedback and you should feel free to request changes from me or directly edit the proposed changeset!

Would it not be better to first have the tool store its state (the access tokens) somewhere other than the config file?
Right now, I need to  make the config file writable to the tool while it runs, which is sub-optimal. Ideally, the tool should run with systemd's ProtectSystem=full or strict, which make the /etc dir read-only but allow /var to remain writable.

Separating configuration and caching has been requested before, but I don't personally have the need for it or the spare time to implement it I'm afraid.
I'll happily review a PR (or maybe accept sponsorship to add this), but it will need careful integration with the various existing features. Probably the simplest approach is to modify the load/save methods of the AppConfig class.

@thiagomacieira if you decide to pursue this further, I think the code in PR #114 (which is close to being merged) provides a good template for what changes are required to store the tokens elsewhere.
In fact, PR #114 does meet your objective of storing the access tokens somewhere other than the config file...but with the dependency on AWS Secrets Manager, whereas it sounds like you'd like to store them in a separate local file.
The other question raised would be where to store the lastactivity state. In PR #114, that remains stored in the local config, which remains writable (and written to) by the proxy. But it sounds like you'd want that separated out too.

@thiagomacieira it turns out that generalising #114 made supporting a local cache file much more straightforward, so this is now available in that PR. The exact configuration may change between now and merging, but it would be useful if you could test that feature.

Thanks, let me take a look!

The change looks good from reading. I'll test it soon too.

Confirmed, working just fine. The config file is now owned by root and is actually world-readable; the auth cache file is read-write, but only writable by the user running emailproxy.py.
I'll make a PR with the systemd service file I'm using.


feature: More customisation for notify: duration and render style

Did you check the docs?

[X] I have read all the noice.nvim docs

Is your feature request related to a problem? Please describe.
I'd like to change how long the messages are displayed on the screen and which render style is used globally (e.g. always use the compact style).
Describe the solution you'd like
Add render_style and duration keys to the notify options.
Describe alternatives you've considered
I went through the documentation and the code, but I didn't find anything that could be used for this.
Additional context
No response

Have you tried changing the nvim-notify defaults? Such properties belong to the notify plugin, what noice does is only to invoke it (with whichever default properties you have set).

That worked! Thank you. For reference, it was as easy as adding the following lines after noice's setup:
require("notify").setup({
	render = "compact",
	timeout = 2000,
	stages = "static",
})


Fix -Wl,--no-undefined-version

The generated exports.sym contains rhash_wfile which is not defined on ELF platforms and causes an error for -Wl,--no-undefined-version. We could remove the pattern, but using a glob pattern rhash_* is simpler.

The rhash_wfile symbol shall not be included into the exports.sym file on non-Windows systems.

The rhash_wfile symbol shall not be included into the exports.sym file on non-Windows systems.

Thanks for the reply. Version script syntax does not support an exclude pattern. Perhaps you can provide a better fix...

Fixed by e4b8b9282709cfe875b8996f3f318212b3d0a52e.


adding sample repos page to the docs

This PR adds a sample repositories page to the documentation. The basic idea here is to give users some pointers to how they can construct various environments, using the binder-examples organization as a guide. I put together a script to parse the GitHub repos that does this in a slightly-hacky way, but we shouldn't have to run it too often. LMK what folks think about this.
Here's an example of how it looks:
http://predictablynoisy.com/binder/
sample repo page:
http://predictablynoisy.com/binder/sample_repos.html
thoughts?

I think this is a great idea. It helps people discover what has already been done and hopefully steers them towards using the "official" way instead of inventing their own.
Do we need the "Files" section for each repo? Mostly asking because I find it tricky to quickly scan the page and see where one example ends and next starts. Removing some of the sub-sections might help with that or adding more empty space before each new example starts?

yeah I kinda agree....hmmm, we could put a horizontal line between repos? Maybe we could skip the "files" section and just expect people would click the repo link to see the files. WDYT?

I like the idea of removing the Files section.
Prefer spacing over horizontal bars but mostly in a -0 vs +0 fashion :)

This is an improvement, merging a is and we can iterate. I missed this PR and started to document that as well.


add blockscape chain to testnet

add testchain ->nochainnogain<-

I'm going to be restarting the testnet tomorrow. Merging this in anticipation of that. Please see gaiad and rly version details here


Task runs instantly when I schedule it

schedule.every().day.at("19:40").do(conectate,"NORMAL")
It is supossed to call the job conectate with the param "NORMAL" every day at 19:40
But the job gets called in the moment it executes that line

sorry, it was my fault.
It works right. Thank you


[CELEBORN-175][BUILD] Include Flink client into the binary release tarball

What changes were proposed in this pull request?
This pr will support release packages include celeborn-flink-plugin. Now we can use ./dev/make-distribution.sh -Pflink-1.14  to package.

Why are the changes needed?
Does this PR introduce any user-facing change?
How was this patch tested?

Please hold on, I'm working on restructure the build script for releasing 0.2, please add flink moudles after that.

Please hold on, I'm working on restructure the build script for releasing 0.2, please add flink moudles after that.

Okay.

@RexXiong FYI https://github.com/apache/incubator-celeborn/pull/1129 has been merged into main branch

BTW, usually, we should build/test against the latest patch version of third-party software, why use Flink 1.14.0 instead of 1.14.6 in Celeborn?

BTW, usually, we should build/test against the latest patched version of third-party software, why use Flink 1.14.0 instead of 1.14.6 in Celeborn?

Already bumping Flink to 1.14.6, thanks.

Thanks, merged to main for 0.3


Migrate to Redux Toolkit part 1

Description

Redux has strongly encouraged to stop usage of "vanilla" Redux, and all the more this was emphasised with Redux 5 + RTK 2.0 release last December. This PR serves as a stepping stone to slowly migrate our codebase away from writing actions manually, and adopting redux toolkit.
Changes:

Install RTK v1 dependency
Reconfigure store using RTK (required first step to support type inference for subsequent steps)
Set up redux-sage middleware in RTK store (take note of a typing issue which will be supposedly fixed by #2757)
Rewrite some actions to use RTK

Although once we fully adopt RTK, we no longer have to define the action creators and action types manually, we still need to migrate our actions to use createAction for now (and also use the prepare callback) in order to maintain compatibility with our existing reducers before they are migrated

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[x] Code quality improvements

How to test

Everything should still work.
Checklist

[x] I have tested this code
[ ] I have updated the documentation

This PR will also form the stepping stone to eventually move to RTK v2.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-17 of 168 (89.88%)  changed or added relevant lines in 9 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.01%) to 37.213%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/features/academy/AcademyActions.ts
6
7
85.71%

src/features/sourceRecorder/SourceRecorderActions.ts
13
14
92.86%

src/features/groundControl/GroundControlActions.ts
4
7
57.14%

src/commons/workspace/WorkspaceActions.ts
96
108
88.89%

Totals

Change from base Build<PHONE_NUMBER>:
-0.01%

Covered Lines:
5717

Relevant Lines:
14435

💛  - Coveralls


Feature Request: Ability to use String or UUID as @Id

It would be great to be able to use a string or UUID as the key.

I've also been looking into this feature, Is there any updates on this Tickets?
Regards


Fix downloadUrl when repo is private

This is probably poor Github etiquette, because I've tested little of this code, but I wanted to let @Aluxian and anyone else who might use this repo to be aware of a bug when using this with private repos (because I've spent about 5 frustrating hours figuring this out).
First, for reference: http://stackoverflow.com/questions/25923939/how-do-i-download-binary-files-of-a-github-release/35280061#35280061
The old code was passing in asset.browser_download_url instead of asset.url to getRedirect in order to find the AWS url for the asset. This is incorrect. I've fixed that.
Unfortunately, I don't currently have time to test all the code paths. The one I've tested is the /update/darwin path. The others are similar, so it should work (famous last words).
Also, I do not know whether win32_file in the update controller needs to be changed. It's quite different than the others.
To confirm this fix yourself:

Get a private repo with a tag and a release to that tag. Add assets for squirrel-update-server to find.
Configure config.js with the details. privateRepo is true.
Visit http://localhost:3000/update/darwin?version=1.0.0 with whatever value for version you used in your release.

Before the fix, the "url" key was not present, after the fix, it is present.

I was wondering why sending a request to the API and getting its location would yield a public URL but then I realised it's because of the Accept: application/octet-stream header. Thanks for finding the proper solution to this problem and I'm sorry for your lost time.
The truth is that what I had before was just a quick hack for a client of mine who, eventually, made his repo public, so the hack was not tested thoroughly.
All the routes that return a download url should be changed so that the download url is publicly accessible. So win32_file should be changed too, I'll do it.
Thanks again! 👍


After scrolling for a while, photos no longer load

Describe the bug
After scrolling for a while in a large album, I reach pixellated thumbnails, then blurred thumbnails, then just a blur. The blur no longer responds to clicks or loads.
To Reproduce
Steps to reproduce the behavior:

Go to 'https://demo.photofield.dev/'
Enter a large album and scroll for a while
Pictures will eventually stop loading

Expected behavior
Memory to be cleared of earlier thumbnails and the new thumbnails to be loaded while scrolling, rather than stopping at some point.
Screenshots
of course, once I try and get a screenshot, I couldn't replicate. Maybe click-zooming clears memory and gets things working again?
Desktop (please complete the following information):

OS: Windows 10 v1709
Browse: Ungoogled Chromium
Version: 90

Smartphone (please complete the following information):
N/A

So this would happen if the server stops responding to any requests, so the browser can only do what it can with what it already has (preloaded lower quality images). For technical reasons clicks also depend on the server being there and ready, so I think you just ran into the server being overloaded at times :)
I would be interested if it happens for you locally though if you end up trying it out!

I'll test more extensively locally!

Closing this as there seems to be nothing more to do :)


warn only if remote cluster is unavailable

To address part of https://github.com/istio/istio/issues/15061 :
when there is no cluster available, will print client version only and warn user about this:
warn    will use `--remote=false` to retrieve version info due to "unable to retrieve Pods: Get https://xxxx:6443/api/v1/namespaces/istio-system/pods?fieldSelector=status.phase%3DRunning&labelSelector=istio: dial tcp xxxx:6443: connect: connection refused"
2b86b6665dd6eb4f7d2d47d20e692cedee2f1825

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: irisdingbj
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

istioctl/OWNERS [irisdingbj]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: irisdingbj, liamawhite
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

istioctl/OWNERS [irisdingbj,liamawhite]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Add "map" functionality to headers

It's quite common that header values are actually numbers and not strings but it's not possible to easily convert the strings to numbers in REST Assured. One solution could be to introduce a "Function" interface that allows you to do mapping before validation. For example:
... then().header("someheader", val -> Integer.parseInt(val), lessThan(200)). ..
... then().header("someheader", Integer::parseInt, lessThan(200)). ..

Hi @johanhaleby , how can I apply header as content-type header is applied? I mean like this:

I've already try this:
     given()
                .headers("My-Key", "123456789")
        .when()
                .get("http:/myURL/user")
        .then()
                .log().body();

but is not working, would you help me please? thanks in advance :smile:


Set str builin addrspace to kernel

str builtin generates a probe read that reads a string from either userspace or kernel space onto the BPF stack. Hence, the call's addrspace attribute should be set to AddrSpace::kernel to reflect this.
Fixes #2480

Checklist

[ ] Language changes are updated in man/adoc/bpftrace.adoc and if needed in docs/reference_guide.md
[ ] User-visible and non-trivial changes updated in CHANGELOG.md
[ ] The new behaviour is covered by tests

The original code comes from #1504, which implemented addrspace for helpers.

@viktormalik I didn't have time to add a changelog, should I open another PR for it? (Or perhaps if you could add it directly to master, it would be more efficient.)

@lenticularis39 it's just removing a warning, no need to update the changelog (no functional change).

Ah, OK :)