Replace exec_program calls (not working out of the box in CMake 3.28)

🦟 Bug fix
Summary
exec_program calls start to fail unless a given policy is set in CMake starting with Cmake 3.28 (the version in Noble). Replace the existing calls.
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

I made similar changes in #402. I should have backported it.

Oh I missed it.

I think the way RESULT_VARIABLE is handled was a little tricky. Have you tried running make uninstall?

I haven't. I was forwarding the changed made in Debian to ign-cmake2 by other user and only did a visual inspection but did not run any code. I'll take care of backporting #402


does paket verify nuget packages signatures?

I could not find documentation about this.
https://docs.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-verify
does paket verify signed nuget packages validity?

This being a cross-platform wrapper, then no.
That feature is barely supported in nuget cli: "Verification of signed packages is not yet supported in .NET Core, under Mono, or on non-Windows platforms."
It would be interesting to have, if, and only if, it will be implemented in .NET 5 - but since it is not in .NET Core yet, I doubt it will make the cut for the NuGet team.
(NB: I'm not a maintainer, but I crawled the source code through for the use of the term "verify" to confirm it)

As of NuGet 5.8 (.NET SDK version 5.0), package signature verification is supported cross-platform:
https://docs.microsoft.com/en-us/nuget/release-notes/nuget-5.8#summary-whats-new-in-58
I just wanted to give a head up since perhaps now it's more feasible to support package signature verification in Paket. For example, the NuGet signature verification is implemented in the NuGet.Packaging package when targeting net5.0.
This is dotnet nuget verify on my Ubuntu 20.04 WSL.
joel@jver-n-3:~$ dotnet nuget verify paket.6.0.0-beta8.nupkg -v normal

Verifying Paket.6.0.0-beta8
/home/joel/paket.6.0.0-beta8.nupkg
Signature Hash Algorithm: SHA256
Timestamp: 12/12/2020 22:38:19
Verifying repository primary signature's timestamp with timestamping service certificate:
  Subject Name: CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US
  SHA1 hash: A9A4121063D71D48E8529A4681DE803E3E7954B0
  SHA256 hash: C474CE76007D02394E0DA5E4DE7C14C680F9E282013CFEF653EF5DB71FDF61F8
  Issued by: CN=Symantec SHA256 TimeStamping CA, OU=Symantec Trust Network, O=Symantec Corporation, C=US
  Valid from: 12/22/2017 16:00:00 to 03/22/2029 16:59:59
Signature type: Repository
nuget-v3-service-index-url: https://api.nuget.org/v3/index.json
nuget-package-owners: agross, fsprojects, matthid, mavnn, sforkmann
Verifying the repository primary signature with certificate:
  Subject Name: CN=NuGet.org Repository by Microsoft, O=NuGet.org Repository by Microsoft, L=Redmond, S=Washington, C=US
  SHA1 hash: 8FB6D7FCF7AD49EB774446EFE778B33365BB7BFB
  SHA256 hash: 0E5F38F57DC1BCC806D8494F4F90FBCEDD988B46760709CBEEC6F4219AA6157D
  Issued by: CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US
  Valid from: 04/09/2018 17:00:00 to 04/14/2021 05:00:00

Successfully verified package 'Paket.6.0.0-beta8'.


Character form design

Objective:  To translate character word document from policy into a set of wireframes/UI designs

@Rebecca-mcknight1991 have we done this?


fix issue #18

Handle the case where the "Server Hello Done" message is in a seperate record from the "Certificate Request" message.  This format is seen when connecting to irc.libera.chat port 6697.

Thanks!


[Feature][Bots][1694836]

Removed note and added screenshot. Please review.

Docs Build status updates of commit 31e2b0b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/bots/how-to/conversations/Media/mobile-bot-menu-sample.png
:white_check_mark:Succeeded
View

msteams-platform/bots/how-to/create-a-bot-commands-menu.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 5b5b93d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/bots/how-to/conversations/Media/mobile-bot-menu-sample.png
:white_check_mark:Succeeded
View

msteams-platform/bots/how-to/create-a-bot-commands-menu.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 00f035c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/bots/how-to/conversations/Media/mobile-bot-menu-sample.png
:white_check_mark:Succeeded
View

msteams-platform/bots/how-to/create-a-bot-commands-menu.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Custom pre-commit task fails after update (0.18.0->0.19.0)

🐛 Describe the bug
After updating to version 0.19.0 my custom pre-commit task fails. Plugin generated tasks ktftmFormat etc. work normally.
⚠ Current behavior
This is my custom task:
tasks.register<KtfmtFormatTask>("ktfmtPrecommitFormat") {
                group = "formatting"
                description = "Runs ktfmt on kotlin files in the project"
                source = fileTree(rootDir).apply { include("**/*.kt", "**/*.kts") }
            }

After updating to version 0.19.0 I get the following error:
Execution failed for task ':ktfmtPrecommitFormat'.
> Could not resolve all files for configuration ':ktfmt'.
   > Could not resolve com.google.guava:guava:32.0.0-jre.
     Required by:
         project : > com.facebook:ktfmt:0.51
      > The consumer was configured to find attribute 'org.gradle.usage' with value 'java-runtime'. However we cannot choose between the following variants of com.google.guava:guava:32.1.3-jre:
          - androidRuntimeElements
          - jreRuntimeElements
        All of them match the consumer attributes:
          - Variant 'androidRuntimeElements' capabilities com.google.collections:google-collections:32.1.3-jre and com.google.guava:guava:32.1.3-jre declares attribute 'org.gradle.usage' with value 'java-runtime':
              - Unmatched attributes:
                  - Provides org.gradle.category 'library' but the consumer didn't ask for it
                  - Provides org.gradle.dependency.bundling 'external' but the consumer didn't ask for it
                  - Provides org.gradle.jvm.environment 'android' but the consumer didn't ask for it
                  - Provides org.gradle.jvm.version '8' but the consumer didn't ask for it
                  - Provides org.gradle.libraryelements 'jar' but the consumer didn't ask for it
                  - Provides org.gradle.status 'release' but the consumer didn't ask for it
          - Variant 'jreRuntimeElements' capabilities com.google.collections:google-collections:32.1.3-jre and com.google.guava:guava:32.1.3-jre declares attribute 'org.gradle.usage' with value 'java-runtime':
              - Unmatched attributes:
                  - Provides org.gradle.category 'library' but the consumer didn't ask for it
                  - Provides org.gradle.dependency.bundling 'external' but the consumer didn't ask for it
                  - Provides org.gradle.jvm.environment 'standard-jvm' but the consumer didn't ask for it
                  - Provides org.gradle.jvm.version '8' but the consumer didn't ask for it
                  - Provides org.gradle.libraryelements 'jar' but the consumer didn't ask for it
                  - Provides org.gradle.status 'release' but the consumer didn't ask for it

On the previous version (0.18.0) everything works as expected.

Are you using Java 8? Can you try different versions of Java (like 11 and 17)?

Hey, thanks for your fast response.
I'm using Java 17, I tried with 11 and 20 but that didn't help.
The project builds fine and other tasks execute with no problem, only the one I created manually fails.
Switching back to 0.18.0 works normally with Java 17

I will close this issue because I replaced the use of a custom task with the ktfmtFormat task. I already run ktfmt on all project files, so the custom task is unnecessary for me.


Backport: Private Registry Auth Causes Worker Nodes to Go Down #16282

Backport https://github.com/rancher/rancher/issues/16282

Fixed in https://github.com/rancher/rancher/pull/16321

Reproduced the issue in v2.1.1.
Tested with v2.1.2-rc2 on a single node setup. Created a cluster with all the images in private registry. After the cluster came up successfully, the kubelet, kube-proxy, and nginx containers did not restart periodically.


feat: added FromFilledEntities util

Converter from FilledEntity[] to FilledEntityMap

:tada: This PR is included in version 0.169.0 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Make use of the insecureSkipTlsVerify in the prometheus basicAuthRoundTripper

In the current implementation, Keptn is using the basicAuthRoundTripper for creating a http client which is able to skip the TLS verification.
We should make use of the already existing parameter and instead of using the DefaultRoundTripper, we should create a custom one with the usage of the  insecureSkipTlsVerify parameter in its config. This way, we should be able to use the value of the parameter in the used roudTripper and enable the user to skip/not skip the TLS verification.

Hey @mowies can I work on this issue?

Hey @mowies I would love to work on this

Hello @Bharadwajshivam28! Thank, you, assigned!

Hello @Bharadwajshivam28! Thank, you, assigned!

Thanks

Hey @Bharadwajshivam28 thank you for the PR, unfortunately we found out that there is no need to use the TLSRoundTripper for the prometheus provider to actually enable skipping the tls verification. It should be enough just to adapt the configuration of the currently used basicRoundTripper. I adapted the description of the ticket for more guidance.
Sorry for the requirement changes!

Hey @Bharadwajshivam28 thank you for the PR, unfortunately we found out that there is no need to use the TLSRoundTripper for the prometheus provider to actually enable skipping the tls verification. It should be enough just to adapt the configuration of the currently used basicRoundTripper. I adapted the description of the ticket for more guidance.
Sorry for the requirement changes!

okay I have seen the description and will make changes in the codebase accordingly


Added a link to the source code in the home page

This is so that I could hopefully get more exposure for my work :)

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


library: lr1110: Add library for LR1110 support

Add lr1110 library and two example applications using the library. This library provides user space support for the LR1110 LoRa chip on Wio-WM1110 development board within Tock.

Also, do we need copies of all of the .h files?

I don't think we need any changes in the libtock folder. They should be upstreamed (e.g. https://github.com/tock/libtock-c/blob/master/libtock-sync/net/lora_phy.c) already.


Tag taxonomy proof-of-concept - Part 1

In our Q1 2024 budget, we have allocated $750 to creating a small, proof-of-concept version of a community-led tag taxonomy for the Archives, to assist with AI search capabilities.
(Note that this task falls across 3 labels - Archive, Development, and Community Engagement.)
We may need to break this task down and assign different elements to different people.

I've drafted an idea for how we might approach it, and costs https://docs.google.com/document/d/14q0GxN0c-QraeSt1Z-bINScd5LJQr275HTjN6C9lyHY/edit?usp=sharing
It goes over the initial budget estimate of $750 - but only $290 of it is in Q1.
Do we agree the costs and the process?

Discussed and agreed in meeting on 7th Feb 2024.
The work (and budget) will need to be spread across Q1 and Q2, so I have amended due date to end of June 2024

In today's meeting (21st Feb 2024) 6 people expressed interest in being part of the team for this piece of work; so we will not need to recruit, and the $30 allocated for doing so is not needed. The 6 people are:

Ese Williams
SucrenSpice
Duke Peter
Ekemini Samuel
Nwobi Onyeka
Vasu Madaan

The original proposal was based on 3 participants, not 6 - but given the current rise in the AGIX price, we might be able to manage 6 after all.
We agreed that we will train 6 people (and have amended the Q1 budget accordingly from $290 to $320);
and Vani will look at the overall budget to see how much work we can offer to 6 people. If possible, we will expand the project to have 6 people each tagging 1 month of Archive entries; but failing that, 6 people will tag half a month each.

Aim to start training at end of Q1 2024 - towards end of March 2024
Scope of tagging depends on committed people.

Vani to DM everyone interested and set a date

Training session took place on 29th April
We agreed to set a "soft deadline" to complete the work by 15th May - we'll see how people are getting on in the Archives WG meeting on that day, and decide if we need to extend by a week (22nd) or even 2 weeks (29th).
Aiming to be finished with the actual tagging by 29th May
the n we move on to collating and seeing if we can derive a controlled vocab.
Payments needed at this point:
$20 to 6 training participants (including those who could not make the session, and viewed the video in their own time)

Vasu (Osmium)
Ekemini
Onyeka (lord_kizzy.)
Ese
Duke
Sucre

This Issue is now a bit muddled, and includes several different payment elements. Our current process as a WG is that each Issue should only cover 1 payment to 1 person (or failing that, only 1 payement element that is split equally between several people) - but this issue has got several different things in it.
So to remedy this, I've created

an Issue to pay those who attended the training on 29th April https://github.com/SingularityNET-Archive/SingularityNET-Archive/issues/144
Two separate Issues to cover the payment for planning and delivering the training - one for the part that needs to be costed in Q1, https://github.com/SingularityNET-Archive/SingularityNET-Archive/issues/145 and the other for the part that needs to be costed in Q2 https://github.com/SingularityNET-Archive/SingularityNET-Archive/issues/146.

(In order to fit with our budget, it needs to be split that way)
And this Issue has been retitled, and will now cover only the payments to the team ($80 per person, x 6 people) for completing the tagging work. It is costed in our Q1 budget, although due to unforeseen delays the work will not be completed until May.

https://docs.google.com/spreadsheets/d/1rhNfJe_i4_5thymrOjKCyltisDSv7kmSWB0joPoSB8U/edit?usp=sharing

Allocate budget in Q3 2024 ?
Discussion of estimates of time taken

Vani to list who is to be paid and create a new issue for Jenn and Onize's payment as new people
and close the issue and send for payment by next week (18th)

To be paid in this issue:
Sucre:  4 hours tagging work - $80
Ekemini:  4 hours tagging work - $80
Lord_Kizzy: 4 hours tagging work - $80
Ese:   4 hours tagging work - $80
New taggers Onize and Jenn's pay will need to come out of Q3 budget; as will the additional $20 to the people above, to cover making it up to 5 hours instead of 4. See https://github.com/SingularityNET-Archive/SingularityNET-Archive/issues/170for this

Rewards distributed here - https://treasuryguild.com/Singularity Net/Snet Archive Workgroup/53fe5f5c768e3545017c28f824175f40fa0b770a4ffb5f427ce493a6822d8f8a


Merge ES2K changes

Hi Derek, Marketing team confirmed that it's E2100 now no 'S'

Hi Derek, Marketing team confirmed that it's E2100 now no 'S'

I'm inclined to leave things as they are for the initial merge and clean them up in a subsequent pass. We need to talk about the scope of the change, agree on what we should and should not change, and advise the development team and our users of what we are doing.
ES2K is baked into the code and its interfaces. I don't think we're going to want to change --target es2k to --target e2k, nor do I think we're going to want to rename all the es2k_ files and Es2k classes and the ES2K_TARGET conditional. ES2K is the software identifier for this class of targets, and E2100 (or E2000, or E-my-name-is-earl-shibe-and-I-can-paint-that-card-for-$29.95, or whatever) is what we use in when we refer to the specific product.


Domain not updating bug fix

I will leave you guys test this.

@ssunkara1 Scatter doesn't seem to have the problem, probably because it does not check this.mark_data.length === 0 in update_domains. Could it be a simpler fix to just remove this condition in the other mark models?
import bqplot.pyplot as plt

plt.figure()
l1 = plt.scatter([0, 1], [0, 1])
l2 = plt.scatter([0, 10], [10, 10])
plt.show()

l2.y = []

Could it be a simpler fix to just remove this condition in the other mark models?

Good point.

Thanks @rmenegaux I removed the check for length.


Check All Bug

The check boxes are having an error when check all is used.
"A component is changing the controlled checked state of SwitchBase to be uncontrolled.
Elements should not switch from uncontrolled to controlled (or vice versa)."

Fixed this bug.
{t:90}

Solving merge conflicts.
{t:20}


createCookieSessionStorage is no longer exported server-runtime in v1.3.3

What version of Remix are you using?
v1.3.3
Steps to Reproduce
Upgrade from v1.3.2 where server-runtime exported createCookieSessionStorage and now it is no longer there.
Expected Behavior
It should still be exported.
Actual Behavior
x

Same for createCloudflareKVSessionStorage, since upgrading from 1.3.2 to 1.3.3 it throws with:
No matching export in<EMAIL_ADDRESS>for import "createCloudflareKVSessionStorage"

I have this issue as well

We expect users to import from one of our concrete server runtime packages (i.e. @remix-run/node or @remix-run/cloudflare) rather than import directly from @remix-run/server-runtime.
We don't currently consider @remix-run/server-runtime to be an intended public API for users, so we refactored it. Specifically we replaced the functions that depend on internal crypto sign/unsign globals (like createCookieSessionStorage and createCloudflareKVSessionStorage) with factory functions that explicitly take crypto implementations and give you back the function (for example, see this code in @remix-run/node).

If you have a specific use-case that somehow requires importing directly from @remix-run/server-runtime rather than one of our concrete server runtime packages, feel free to reopen.

@pcattori for everyone who cannot use the remix package directly (due to it modifying node_modules), the advice we got was to import from the packages behind that have the actually implementation. In this case it was @remix-run/server-runtime.
if I update the import from @remix-run/server-runtime to @remix-run/node I get the following error:
export const sessionStorage = createCookieSessionStorage({
                               ^
TypeError: (0 , import_server_runtime.createCookieSessionStorage) is not a function

@garth Previously we recommended importing from remix via "magic" imports that relied on modifying node_modules/, but we're moving away from that in favor of importing directly from server runtime packages (see #2359). We're actively working on updating our docs, examples, etc... to use this new recommended approach.
Could you provide more info about the error you're seeing e.g. what your usage looks like and what file the error points to?

I created a new Remix app using Remix App Server and then added this to app/root.tsx:
import { createCookieSessionStorage } from "@remix-run/node";

export const loader = () => {
  const sessionStorage =
    createCookieSessionStorage({
      // a Cookie from `createCookie` or the same CookieOptions to create one
      cookie: {
        name: "__session",
        secrets: ["r3m1xr0ck5"],
        sameSite: "lax",
      },
    });
  console.log(sessionStorage)
  return null
}

Using v1.3.3 and this works locally for me. I'm able to hit localhost:3000 with my browser and see the session storage functions getting logged.

With this refactoring, how can I make the createCookieSessionStorage function in Cloudflare Pages environment like the previous Remix version?
import { createCookieSessionStorage } from "remix"; This is used to work in Pages Function environment (which is Workers env).
Trying import { createCookieSessionStorage } from "@remix-run/node"; but it did not work.

I had many imports from @remix-run/server-runtime, so went through the project and replaced them all with @remix-run/node and remove the server-runtime from my package.json and that seems to have fixed it.
Glad to hear that you will update the docs. Clearer instructions will help clarify a lot of details that we are currently getting from snippets from twitter or elsewhere.

@pcattori
Since Cloudflare Pages environment uses Web Crypto (Web Crypto APIs) instead of Node crypto, how can we use Remix createCookieSessionStorage function in Cloudflare Pages environment?
The cookie-signature lib on which @remix-run/node depends uses Node crypto which Pages environment does not support.
Any Web Crypto implementation for sign and unsign functions that Remix createCookieFactory function take?
Thank you.

@supachaidev yes you should use @remix-run/cloudflare as your server runtime package. Sounds like you might be seeing the same thing as #2504

A few months after the last comment in this issue, when I updated to v1.7.2, it turns out createCookieSessionStorage is no longer exported from @remix-run/node.

However, it seems that i can import it from @remix-run/server-runtime. Did this change again?

@tonymartin-dev createCookieSessionStorage is still exported by @remix-run/node
https://github.com/remix-run/remix/blob/2262dd9554cdfa91443e327ba7da30767095466d/packages/remix-node/index.ts#L24-L29


Implement equals in Matchers

If you have an API which uses Matcher, it is difficult to mock methods because matchers are only equal by JVM identity.
ie instead of...
        when(context.findAllByUrl(Browser.class, equalTo("foo"))).thenReturn(found);
        assertSame(found, By.url("foo").findAll(Browser.class, context));

I have to do...
        Matcher equalToFoo = equalTo("foo");
        when(context.findAllByUrl(Browser.class, equalToFoo)).thenReturn(found);
        assertSame(found, By.url(equalToFoo).findAll(Browser.class, context));

With mockito this can be mitigated with using refEq() in the when stubbing, but IMHO it's easy enough for IDE's to generate good equals methods that it's not unreasonable to expect them to be implemented.
Cheers

What do you mean by equal?
Should a matcher implemented as (value == 1 || value == 2) be equal to anyOf(equalTo(1), equalTo(2))?
Even if you resolved this question to everyone's satisfaction, you'd have to submit a PR to implement equals and hashCode for all the matchers in Hamcrest-Java and all the extension libraries that implement Matcher!  I think this bird has flown.

Thanks for the reply! I realize that would require updating a lot of matchers, but I don't see why it has to be all or nothing (particularly re: extension libraries).
I would keep it simple. assertTrue(equalTo(1), equalTo(1)). Each Matcher implementation can only be equal to another of the same implementation. If two have logically the same match but are different classes, they are unequal. The IntelliJ auto-generated equals/hashcode template I think would satisfy this requirement quite reasonable. Perhaps you could use a tool like that to implement them in one batch?
Writing a fake context with map implementation seems more complicated to me than stubbing one method.

Another way of looking at this is that it's such an usual case (testing the use of Matchers, rather than using Matchers to test other code), that you should consider writing your own for the purpose of your test. Perhaps write one that does what you want and then delegates to a standard matcher for the behaviour?
On the other hand, it looks as if you're testing a DSL construction. Quite often, we just do more integration tests at that level, relying on lower-level tests for the detail.

"Each Matcher implementation can only be equal to another of the same implementation"
That leaks implementation details beyond the interface.  It must be possible to change the implementation class without breaking client code, otherwise we'd not be able to change the classes instantiated by syntactic sugar factory methods (which we sometimes do to improve mismatch messages or performance).

That leaks implementation details beyond the interface

Good point. Perhaps rather than thinking about it in terms of implementations, think about it in terms of the API then. Is it a reasonable rule to say that if you use two different APIs (like is and equalTo) there is no guarantee that they will be equal or not even if they are logically equivalent? This would give you freedom to change the implementations. If you are comparing two matcher instances from the same API, then of course they will be (unless there is some conditional logic or something surprising) the same implementation. IMHO this is what i would like to see. You could reason about equivalence as, "using the same language" (API + parameters) as opposed to "same instance."

Another way of looking at this is that it's such an usual case (testing the use of Matchers, rather than using Matchers to test other code), that you should consider writing your own for the purpose of your test.

Not a bad idea. Although, I'm employing hamcrest as use in a src/main library (to be used in tests, but I digress). Hamcrest is quite nice as a general purpose matcher library :). In this application it would be useful if matchers followed equivalence rules like suggested above. In my case this would mean to "locators" that match using equivalent matchers would be equal, which makes sense, and is useful beyond my unit tests. Otherwise, these locators will only be equal if the same instance of the matcher is used, which is less useful.
Thanks for the replies!

Sorry, but I think this case is too obscure, plus it raises the bar for people implementing their own matchers--don't forget it needs hashCode() too.


cooking plugin: add wine ferment timer

Added toggle to Cooking plugin to show timer until wine ferments
Begin countdown whenever a wine is made, reset when another is made, etc.

See: https://imgur.com/a/sh594B8

Maybe consider making this two commits - one to do the renaming of session -> cookingSession and one for the rest of the wine stuff. The rename is cluttering the diff a bit.

Thanks for you feedback @Adam-, I think I mostly addressed your comments here. Let me know.

This closes #1261


make property name not required

Coverage increased (+0.006%) to 1.085% when pulling a053f1232dddecfad800916e27748b396b08d574 on u9520107:enhance/compose-text into af440d01ca6602eb611fb5bc44115fea2c6c29ab on ringcentral:master.


Validation failures in CH-EMED

In IgValidationTests, some examples of CH-EMED fail to validate. The terminology server is enabled.
Other IGs are passing. If we remove CH-EMED, we cannot test CH-EMED-EPR.

Solved with 62bd00adbc9bc6c1c2d2981449c202e4a119689f.


Unexpected token e in JSON at position 1

when I run fsp run , the following errors was reported ,

and this id my fspconfig.js

can you help me tell me  how to modify this file  fspconfig.js?

localpath不支持用@哈，用相对路径

这个文件需要严格准守json格式


Update repositories.txt

Add of my librairy for a french project.
I make it for simplify the time to correct bugs.

@ArduinoBot

@ArduinoBot

@ArduinoBot

@ArduinoBot


[feat]: Autocomplete component. An Autocomplete is not a combobox nor a command component.

Feature description
Shadcn is lacking the Autocomplete component. This is an input text/search that shows a popover when focused or when typing otherwise no popover is shown (unlike command component). Also the trigger for the popover/dropdown is the input component only being focussed or receiving text input, and not some additional component (unlike the combobox component)
Example of a custom shadcn autocomplete component: https://www.armand-salle.fr/post/autocomplete-select-shadcn-ui
Example of an standalone autocomplete npm package: https://react-autosuggest.js.org/
Example from mantine ui: https://mantine.dev/core/autocomplete
Affected component/components
No response
Additional Context
Additional details here...
Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues and PRs

I believe this is a duplicate of https://github.com/shadcn-ui/ui/issues/173.

I believe this is a duplicate of #173.

Actually it is not, but it's related.

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

Hey, @samuelkarani is right. #173 is mislabeled. There are now a few closed issues as well as comments within #173 explaining that combobox !== autocomplete, but these seem to be buried by commenters who are confusing the two.
Autocomplete should be like a freeform input textbox that allows you to enter any text you want, and it also allows you to select from a list. #173 and others are, as far as I can tell, mostly about modifying the combobox format so that the popover is triggered by a textbox. The user is still fundamentally forced to pick an option.
As has been pointed out elsewhere, this is the desired behavior: https://mantine.dev/core/autocomplete/
@shadcn can we reopen this issue? I think the desire for this component is greater than might appear at first blush, people keep asking for it but it's spread out across different issues and comments.


upcoming v3 changes

views will no longer be auto-keyed by the passed-in model. it's too surprising and i've had to explain it too many times. explicitly keying by the model when needed isnt all that difficult.
domvm.lazyList() creator & domvm.LAZY_LIST flag for creating deferred homogenous children that can reuse old vnodes without additional allocation.
render() will be able to return vm.node (the old vnode) to prevent/optimize redraw when no changes.
xlink:href support in svg
vm.diff() & vm.hook() will be removed in favor of what is already possible:

direct assignment vm.hooks = {}
new: vm.config({hooks:..., diff...})
object return {hooks: ..., diff:..., render: ...}
externally passing in through opts: {hooks: ..., diff: ...}

dist builds may be split into a separate branch, since merging and rebasing are currently a nightmare and always result in conflicts.

v3 should be ready within the next couple weeks.

Should I implement vm.diff(...) behavior inside render() to be compatible with the upcoming release?

in v3 you can just replace vm.diff(...) with vm.diff = . right now this wont work though. the object-return style will continue to work the same as before: return {diff:..., hooks:..., render:...}

That's awesome! Thanks

to be really future-proof, i recommend using the object-return pattern (or implement the diff yourself in render once vm.node return is implemented). i doubt that direct assignment will be promoted or even documented (for hooks, too). once this stuff is refactored and refined, i'll have a better grasp on the ergonomics. in general, direct assignment makes for a crappy, non-discoverable api.
none of the stuff mentioned here is set in stone, yet.

in general, direct assignment makes for a crappy, non-discoverable api.

Yes, I agree. I do not like a direct assignment API. It also prevents validation, read-only values, and in general being unable to transparently introduce many changes without breaking backward-compatibility. That is, it's too brittle.

maybe the replacement would be to provide a single setter, to prevent the vm from continuing to grow public hair:
vm.config({
  hooks: {},
  diff: function() {},
});

What are the goals of V3?

"views will no longer be auto-keyed by the passed-in model" is the main goal. this has surprised many people and it's clear that this is an unneeded point of friction. in general, api refinement is always a goal when BC is involved (which mandates a major semver bump).
the overview at the top is the answer to your question. the reason it's v3 and not v v2.2 is because of semver/BC.

Good to know; I am a fan of API refinement, and I dislike when there are multiple ways of doing the same thing... unless there are defensible use-cases that warrant it. I would support removing any duplication of functionality from the API. If there are 3 ways to set hooks, let's just pick one.

it's difficult to provide a single way that satisfies multiple styles.

i like having a concise definition of most views where they simply return a bare render.
to take that view and simply add an optimization to it, all that must be added is vm.config() rather than switching to an object-return style.
some people will prefer the fully-explicit object-return style.
others prefer es6 class views
externally, vm.config allows you to add hooks to pre-initialized vms.
in declarative views, the only way to pass down these things outside of model is via opts. hooking up those automatically prevents the subview from having to know to internally invoke vm.config() or re-return them.

while i agree that having "one way" to do things would be ideal, there really are multiple scenarios where it cannot always work. in theory, vm.config(opts) that's automatically executed during init on any passed-in opts would work for all cases. this eliminates the need for having an object-return signature at all, so 2 ways instead of 3. but the object-return sig also provides an option for further uniformity in view defs and a clear indication of what's being returned.

All good points. Sounds like it fits into "unless there are defensible use-cases that warrant it".

And that's one of the great strengths, and weaknesses, of JavaScript, there's no one "best" way to do things is almost ubiquitously true of everything.

if anyone is interested in testing, all the public-facing changes changes listed above besides xlink:href support are now live in the 3.x-dev branch, which i've switched be default.
render(vm, model, key, opts, oldVals, newVals) now carries the 2 additional arguments that provide the previous and current return values from any present diff(), you can already assume they are somehow different because render() was not prevented. this gives you the ability to do shallow patching of vm.node and return it to prevent a full re-render. prior to this, diff had a 2-stage signature: {vals:.., then:...} to facilitate this. you can see the changeover here: https://github.com/leeoniya/domvm/commit/40ab7c06dd6944573d4cdfe2798ff03f262cab6b?diff=split
i think the new design is more powerful, logical and easier to explain. it also simplifies the internals a lot.
docs still need to catch up (hooks, diff), but i've removed the autokeyed-by-model section from them (DOM Recycling).

i actually have some serious concerns about removing the model auto-keying. it may not be such a good fit for domvm's api after all. i'd like some feedback to see if this change causes more problems than it solves.
the core issue is that we have a closure that accepts some model during init. in v2, that model was more-or less guaranteed to be persistent within this view due to auto-keying, unless you explicitly opted out of this and then you simply ignore the model in the closure and use the always-current vm.model or the model passed to render(vm, model).
in v3, this guarantee would be weakened significantly. now you have other problems like unintentional DOM recycling, view state transfer and a stale closured model. it seems there are more caveats to the new situation than the old. we'd have to recommend to ignore the closured model when the view is unkeyed and only ever use vm.model outside of render().
we can change the API to remove model from being passed into either the closure or render() and simply rely on using vm.model. this would be similar to React's always-current this.state. i'm not particularly thrilled with this prospect, since libs primarily differentiate by their APIs, each with their own trade-offs. this would also cause significant BC.

FWIW, I grew tired of constantly checking and updating my view vs render arguments. I now avoid the closured model all together in favor of vm.model and leaving out the render arguments entirely. Even having to explain to a newcomer why the signature is the same and beware of the gotcha of a stale reference seems like a burden of unnecessary cognitive load.
Does render(vm, model, key, opts, oldVals, newVals) really need to be 6 arguments? Why not remove the first 4? Aren't model key and opts all available from the vm passed to the view?

here are a few considerations handled by the current design.
a passed model argument minifies to a single character. while vm.model can only be mangled down to 7. this difference is significant when multiplied out in a large app. same applies to the other args. also, a model arg can be renamed to state by the end user, whereas vm.model cannot. the vm has a lot of implementation details that i would rather not publically promote/commit to. vm.model is currently an implementation detail. a function signature commitment allows for more flexibility to iterate domvm's internals in the future.
when you realize that render is recreated for each view, for stateless but model-bound views it may make sense to share render across instances while still having access to the vm and args (this extracting it from the closure). this is something OO and class-based inheritance offer for free and it does matter [1]. the tldr is that render is currently fully extractable/sharable across view instances. such an optimization, though, is best handled by using ES6 class views.
given how trivial it is to ignore and omit everything besides the vm arg in both the closure and render, i dont see a very compelling case for reducing the arg count. i agree that it's not optimal to have the newVals and oldVals at the end of the chain, but they are the 0.1% case when you insist on doing your own diffing (that cannot be handled by diff) or super-optimization.
as for the stale model, it's a side-effect of being able to operate in isolation on a non-global, mutable state. in react, the parent must always pass down data (or it must be pulled from some global via mobx/redux). in the former case, refactoring a component involves updating all ancestors to pass the data down a different path (eww). in the latter, magical globals or some shared echo-chamber event bus.
if we decide that an extractable render is a far-fetched case, then its sig can be modified to render(model, oldVals, newVals), but i think ignorable arg reduction is an orthogonal topic.
sorry for the brain dump.
[1] https://www.reddit.com/r/javascript/comments/6enbvb/classes_vs_closures_performance/

the ideal solution here would be for model to be a proxy object (that's always current), but the perf would almost certainly drop and support for IE would be impossible.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy

another thing you can do to keep the closured model fresh is adding a one-liner to render() that minifies to 3 chars and has basically 0 overhead: closuredModel = model.
or a slightly more expensive willUpdate vm hook that does the same thing but stays out of render().

Would it make sense for the model to be an object created by DOMVM with the current arg value beinga property of that object?
Then the argument is always the same state object and the model data is always current. Then the "state" would be a natural place to store stuff internal to the view that needs to be retained across all calls.
--
Lawrence Dol
http://tech.dolhub.com/
http://think.dolhub.com/
(Sent from my phone)

Would it make sense for the model to be an object created by DOMVM with the current arg value beinga property of that object?

the vm is already this object

how would you guys feel about adding another view type. it would be easy to do and caveat-free.
var v2 = domvm.defineView2;

v2(View2, state);

function View2(vm) {
  return function(vm, oldDiff, newDiff) {
    return el("div");
  };
}

this view would not be auto-keyed and would not inject the initial model or anything besides the vm into the closure. you would operate only on vm.* props directly. a matching domvm.createView2 would also be needed.
the hardest part would be meaningfully naming each version.
if you understand the caveats of the original views and are not bothered by the extra args, then the original views can cover all cases as they do today.

Now that I am at work, I have the time & energy to more fully consider this thread.
Caveat: I am looking at this from the app developer's perspective, looking for a tight delineation of what "belongs" to DOMVM and what "belongs" to me. I don't like having to screw with properties of vm; in my opinion, the only thing that vm should provide is a public API of functions to interact with DOMVM -- it should not be the place where I store stuff for my app.

when you realize that render is recreated for each view, for stateless but model-bound views it may make sense to share render across instances while still having access to the vm and args (thus extracting it from the closure).

I can think of important use-cases for having a non-closured, shared render function with the model/state injected in. Retaining that is very important.

given how trivial it is to ignore and omit everything besides the vm arg in both the closure and render, i dont see a very compelling case for reducing the arg count.

This is the kind of situation where I prefer to have an "opt in", with such values provided in a map/object. However, I agree that the ability to simply omit trailing arguments makes the case for reducing arguments weaker. With that said, I have found of the years that adding arguments is very much not future-proof and usually indicates that the function is too broad, or that the API has been too ad hoc over time.

model can be made into a getter that returns vm.model: model().moo

Ugh.

another thing you can do to keep the closured model fresh is adding a one-liner to render()

I've resorted to that trick somewhere, in a Mithril app, I think. I wasn't thrilled with it, but it got the job done. I'd rather the problem didn't exist.

Would it make sense for the model to be an object created by DOMVM with the current arg value being a property of that object?
...
the vm is already this object

It is from the point-of-view of DOMVM, but less so from the point-of-view of the app. The minute I have to store something in vm or get something that belongs in my app domain out of it, I feel the API is already broken. I would like to see something akin to:
function View(vm,state) {
    // state === same as render's state always
    // state.model === app model; name determined by DOMVM :-(
    return function render(vm,state) {
        // state.model always fresh whether access via closure or argument
    }
}

With render then still extractable:
function View(vm,state) {
    // state === same as render's state always
    // state.model === app model; name determined by DOMVM :-(
    return render;
}

function render(vm,state) {
    // state.model always fresh whether access via closure or argument
}

how would you guys feel about adding another view type. ... view2.

Maaaaybeee. But the simpler option should be view and the more complex view2. However, my gut tells me this is not the answer. One thing I particularly don't like is DOMVM's dual use of the word "model". It seems it's ambiguously used as the application model and the view's model. But vm is the view model, and the currently named vm.model is really the application's view state within the view-model. Some of that state may be the app's model, but what it is, and what it's named should be in the app domain (notwithstanding practical realities). Perhaps it's the method of injecting current state that's broken? Maybe it should be done thus:
function View(vm,state) {
    return {
        modelName: "data", // optional
        render: function render(vm,state) {
            // state[modelName] set to xxx by DOMVM from `view(View,xxx,...)`
            // vm.oldDiff and vm.newDiff could be there for the "0.1%".
            // as are `vm.key` and `vm.opts`?
        }
    };
}

With the above said, it seems like a big part of the confusion is that the model data is accessible via two arguments because the render function is enclosed in the view init function. This could be mitigated by encouraging a form that always has the render function as a separate function at the same level as the View function. It could also be mitigate with an init function returned as one member of an object, of which the render function is another member. I would support changing View functions to only return an object, { init: ..., render: ..., hooks: ... model: ... } and just remove the ambiguity.
Lastly, I mentally distinguish between things that DOMVM defines and supplies in vm -- a public API, key, opts --- from things my app defines and supplies -- render, initialization code, hooks, and model.
Maybe "model" should be a vm function which returns the current model supplied in the argument, instead of an argument passed in; then it can't be closed-over. In this case, I'd still want to have a state object available to render to store it's specific local state of the view that isn't part of the data-model driving the view, whether that was supplied as an argument or via vm.state.

In re-reading my comment, another important point occurs to me. I said:

But vm is the view model, and the currently named vm.model is really the application's view state within the view-model.

But that's not the entire picture. There's:

DOMVM's view-state, which should be entirely hands-off to the app.
The View's view-state, which should be entirely hands-off to DOMVM.
Injected view-state (the model), which should be entirely hands-off to DOMVM.

I feel like DOMVM conflates 1 & 2, while leaving the app developer to (instinctively) conflate 2 & 3 to avoid polluting 1 with stuff for 2.

thanks for the through feedback. i don't have too much time to respond to each point but i've read through everything and want to refine the api.

the view closure and the vm are the carriers of private and externally accessible state/api, respectively. i dont see a benefit of initializing and tracking a third state wrapper for the sake of artificially splitting user concerns and domvm concerns since there is no clear boundary between them. the vm is the only way to expose internal view state or api to external consumers (which the user would have to touch anyhow).
model is not a great name and i agree it's confusing since it's not the view model. i would like to rename it either vm.data (to match the terminology for user-defined vnode.data) or vm.state.
let's move the model-staleness concerns to result only from explicit aliasing in userspace rather than the lib's closure injection (see bottom of this comment)
expand the View declaration api to more flexible patterns so extractable render is possible by default.

// plain-object view
const View = {
    init: function(vm) {},
    hooks: {},
    diff: function(vm) {},
    render: function(vm) {},
};

// object-returning closure
function View(vm) {
    return {
        init: function(vm) {},        // redundant w/closure invocation?
        hooks: {},
        diff: function(vm) {},
        render: function(vm) {},
    };
}

// render-returning closure (shorthand for object-returning closure)
function View(vm) {
    return function(vm) {

    };
}

// functional view with state
// todo: need a way to discern this from
function View(vm, arg1, arg2) {
    return el("div");
}

class MyView extends View {
    init() {}                        // redundant w/constructor?
    diff() {}
    render() {}
}

by only ever injecting vm, we should have a much cleaner api. for my own purposes, i can replicate the current closured-model behavior in userspace and worry about the model becoming stale myself, while still gaining most of the benefits of min, less the aliasing.
function View(vm) {
    var model = vm.data;

    return function(vm) {
        return el("div", data.text);
    };
}

i think this is a good balance and i can sleep at night with removing the auto-keying.

i tried dropping all closure and render args in https://github.com/leeoniya/domvm/commit/eaef453041ce92a9691496bc7fc32d24c484dcd5 and the resulting ergonomics were not great IMO.
needing access to vm.data is so fundamental everywhere that adding an extra level of indirection is a real pain in the ass. you need to alias it everywhere to make sure you minify well and the code stays terse and readable. one thing that i always disliked about React examples is this.props.fullName when you could simply say person.fullName had the props been passed in as an arg and named logically by the end user. otherwise you have crazy deeper shit like this.props.person.fullName (shudder). react's props must live on this because classes & prototypes have no real private state, you only get this in a constructor/closure.
not passing data to the closure may be okay-ish to avoid it going stale, but not passing the always-current vm.data into render is a recipe for boilerplate aliasing or huge java-esque, incompressible verbosity. so the question becomes, what value does forcefully not passing it do vs just ignoring the extra args?
for me, keeping the closured model/data updated (if needed) from inside render() is the shortest (3 chars minified) and 0-overhead solution. if this method feels dirty to you, then you can always use vm.data as @tropperstyle has.
function View(vm, data) {
    function click() {
        data.count++;
    }

    return function(vm, newData) {
        data = newData;
        return el("a", {href: "#", onclick: click}, data.count);
    }
}

i'm on board for renaming model to data
removing the auto-keying would require adding notices for unkeyed views to

add keys if there are matching sibling views but of different data
reset any internal view state during a willUpdate hook (if needed)
update the closured data either from willUpdate or render() (if needed)

adding an extra level of indirection is a real pain in the ass

Can the overarching problem not be resolved by not including the data in the View factory arguments, since it is a conflict with a stale value?
function View(vm) { // no data arg for "initial" value of data
    function click() {
        let data=vm.data; // only if you actually need data during event
        data.count++;
        }

    return function(vm, data) { // here's where you most often need data
        return el("a", {href: "#", onclick: click}, data.count);
    }
}

Personally, I would far more prefer to employ explict reducer helper functions than have counter-intuitive "magic" and "strangeness". For me, caveats indicate possible flawed design. That is, the "data may be stale" indicates a possible error.
function View(vm) { // no data arg for "initial" value of data
    return function(vm, data) { // here's where you most often need data
        return el("a", {href: "#", onclick: vmHandler(vm,data,incCounter) }, data.count);
    }
}

function incCounter(vm,data) {
    data.count++;
}

function vmHandler(vm,data,hdl) {
    return hdl.bind(null,vm,dta);
}

This tends to result is looser coupling and more reusable with more explicit values and less assumptions. The code is easier to understand in context.

// here's where you most often need data

right. that and event handlers. typically the data is not needed directly within the closure itself. maybe it makes sense to pass the current data as an arg to event handlers (as well as render) to prevent having to alias it there. everywhere else is much less common.

This tends to result is looser coupling and more reusable with more explicit values and less assumptions. The code is easier to understand in context.

btw, in your example, you're re-creating the onclick handler every redraw, which means domvm will re-bind el.onclick each time. onclick: [incCounter, data] is what you likely want, where incCounter(data, e, vnode, vm)

maybe it makes sense to pass the current data as an arg to event handlers (as well as render)

I think that's likely the right solution, including hooks. I suppose the remaining question is one of BC; argument order.
Consistent within lib (with data passed as null or undefined, not simply omitted):
render(vm,data)
hook(vm,data,node) and (vm,data,oldNode,newNode)
eventHandler(vm,data,event,vnode,{other-args})

Backward Compatible
render(vm,data)
hook(node,data) and (node,newNode,data)
eventHandler(event,vnode,vm,data,{other-args})

I have 15 event handlers affected.  I don't usually pass anything to event handlers so I forget about this version; might be better if I habituate using onclick: [fnc] even if it's a little more verbose.

argument order in domvm is prioritized to be practical and logical for its context rather than uniform but often impractical.
an event handler's primary concern is the event's properties and the source of the event (e.target). a vnode hook cares about which vnode(s) is the context of its invocation. a vm hook cares about what vm instance we're talking about, etc.
that being said, in many cases, (vm, data, ...) make sense, but not all:
// view
view(vm) -> render | config
diff(vm, data, oldDiff) -> newDiff
render(vm, data, oldDiff) -> vnode

// vm hooks
willUpdate(vm, data, newData)
willRedraw(vm, data)

// vnode hooks (trailing vm, data)
willInsert(vnode, vm, data)
willRecycle(vold, vnew, vm, data)

event handlers is where is gets somewhat tricky.
the original idea was to stay as compatible with the original argument order of plain event handlers, so to keep e first and add the auxiliary domvm args afterwards. the [fn, ...args] signature was meant to accommodate functions that did not necessarily care about the e or domvm's args and were siply meant to operate on user-provided args, internal user-defined view state and externally-injected user-defined data - thus removing as much of domvm-isms from the handler args as possible, so handler(..args, e, ...domvmArgs). in other words, functions that don't need to know about being event handlers. making the [fn, ...args] call signature match that of fn removes this clean use case:
function setColor(h, s, l) {    // trailing args can be ignored (, e, vnode, vm, data)
  color = "hsl(...)";
  vm.redraw();
}

el(".swatch", {style: "background: ...", onclick: [setColor, 0.5, 0.23, 0.85]}, "Red")

becomes
function setColor(e, vnode, vm, data, h, s, l) {    // leading args are necessary and superfluous
  color = "hsl(...)";
  vm.redraw();
}

el(".swatch", {style: "background: ...", onclick: [setColor, 0.5, 0.23, 0.85]}, "Red")

of course you can always do the following, too, but vnode.data is not logically scoped for the onclick event:
function setColor(e, vnode) {
  color = vnode.data;
  vm.redraw();
}

el(".swatch", {style: "background: ...", onclick: setColor, _data: {h: 0.5, s: 0.23, l: 0.85}}, "Red")

either way, i would like to keep e first, since they are event handlers after all. vnode is the source of the event and may be holding vnode.data in cases of event delegation or other intermittent reasons.

// vnode hooks (trailing vm, data)

Personally, I'd still very much prefer (vm, data, ..args) for these because they are so DOMVM centric.

event handlers is where is gets somewhat tricky.

 I'm convinced by you arguments concerning event handlers, and had not previously considered the efficacy and re-use potential with respect to trailing arguments.
With that in mind, I think that (...args, event, vm, data) becomes highly defensible. Following your reasoning, then, I'd change my preference to, in order:

(...args, event, vm, data, vnode)
(event, vm, data, vnode, ...args)
(vm, data, vnode, event, ...args)
(event, ...args, vm, data, vnode)

My thinking now being that (1) is pragmatically highly useful and doubles for (2) in the common-case; (2) is most aligned with a "normal" event handler, and remaining args are consistent with other DOMVM-isms; (3) is probably the least intuitive to me -- seems a little random at first -- but more importantly once you've lost the defense for (1) there is no longer a strong defense for putting the args somewhere in the middle; (4) is most consistent with DOMVM-isms, but your arguments for (1) convince me of it's superiority.
So I think there's a good case for (1) and (2), slightly less for (3) and very little to commend (4). I think (1) wins, because if you don't supply augmenting arguments, then you have plain-event-handler compatibility.

vnode hooks rarely need to touch the vm and invoking redraw from them will lead to bad things. they also rarely need access to the vm.data since their primary use-case is to do dom patching and css-transition setup on vnode.el. i would find it very awkward if "vnode hooks" did not have the vnode itself as their first argument.
for event handlers, i'm finding it hard to justify moving the vnode apart from event since vnode.el === event.target and event.target._node === vnode. i think there will just need to be one set of functions with trailing vm, data and another with leading vm, data. the current ...args, event, vnode, vm, data would satisfy the latter, in addition to the current use cases.

one rough edge remaining that i can think of is with the global onevent that needs a single signature and cannot have trailing (vm, data), but it's still digestible:
onevent(e, vnode, vm, data, [args])

there will just need to be one set of functions with trailing vm, data and another with leading vm, data

In that case, an argument could be made for all hooks to have trailing vm, data. By changing willUpdate(vm, data, newData) to willUpdate(newData, vm, data). The question only being are vm hooks more strongly thought of as "hooks" or "vm functions".
I would, in fact, argue that diff(vm, data, oldDiff) become diff(oldDiff, vm, data) were it not for oldDiff on render. Does render really need oldDiff? If diff were changed then all of these functions would have "trailing" vm data; that is, vm,data would be the last two args for all functions, even those where they are the only two args, making eventHandler(...args, event, vnode, vm, data) perfectly consistent.
Consistency Matters
As may be obvious by now, I value consistency highly. Inconsistent APIs lead to coding blunders. Having a simple rule, "the vm and data arguments are appended to every relevant function" makes getting it right easier. Fewer "exceptions" (that is, greater consistency) reduces cognitive load. That's one reason why all "C" copy/move functions ended up being of the form (tgt,src) or (src,tgt,tgtlen) or (src,srclen,tgt,tgtlen); the odd few that deviated from that were a diabolical source of mistakes, particularly in the days before prototype function declarations when function arguments weren't type-checked (much like the case in JavaScript today).

In that case, an argument could be made for all hooks to have trailing vm, data.

a strict commitment to keeping specific arguments ever-trailing prevents argument addition without annoying API breakage. however, this "consistency" is not practically useful because you won't know what's "trailing" until you look up the argument count in the docs. the only thing that's future-proof and consistent is guaranteed leading arguments; everything else is just RTFM.

Does render really need oldDiff

the original intent was to allow for more granular checks & micro-redraw rather than the simple all-true or any-false operation of diff & full-redraw or 0-redraw. an example of when this may be needed is toggling visibility of a complex subview without forcing a re-generation & diff of all its children. imperatively this can be accomplished via:
diff(vm, data) {
    return {
        isActive: data.isActive,
        message: data.message,
    };
}

render(vm, data, oldDiff) {
    if (oldDiff.isActive && !data.isActive)
        return vm.node.patch({style: {display: "none"}});

    return el("section", {style: {display: null}}, data.message);
}

maybe there's a better way to do it, i dunno. certainly if you have a closure you can DIY diff & patch and just avoid the built-in diff altogether.

Consistency Matters

sure, within the same similar group of of functions, and only sometimes. your (tgt, src) example falls over for fread(tgt,..., src) & fwrite(src, ..., tgt) where arg[0] is always a buffer but serves different semantic purposes in each case. it's difficult to compare the strict uniformity of typed/imperative/strict-argument languages with type-coercing/fluent/error-stomping/squishy-argument languages.

Then, I believe I defer to your comment, though, it seems, with vnode hooks not receiving vm or data.
// view (leading vm,data)
view(vm) -> render | config
diff(vm, data, oldDiff) -> newDiff
render(vm, data, oldDiff) -> vnode

// vm hooks (leading vm,data)
willUpdate(vm, data, newData)
willRedraw(vm, data)

// vnode hooks (no vm, data)
willInsert(vnode)
willRecycle(vold, vnew)

// events (trailing vm,data)
handler(...args, event, vnode, vm, data)

after some soul-searching, skipping stones on the lake and quiet meditation of internet cat pictures. the following is a distillation of it all:
an important consideration for domvm's design is how @leeoniya builds apps. because of this, there's a limit to how much of my own convenience i'm willing to give up to accommodate ease-of-onboarding for new users. with that in mind, there's no good reason that data should be forcefully removed from the closure signature (i use it very often in my own apps). however, it's probably a good idea to remove it from the beginner docs/examples. to vastly reduce the need for it, i'm adding data to the args of event handlers and vm hooks. auto-keying is also gone. the resulting api still allows for a closure pattern, but almost entirely eliminates the need for it. i've also moved the vnode arg to the tail of event handlers; it's definitely less useful than vm and data and makes most cases much tidier.
summary:

removal of auto-keying
rename model -> data everywhere
domvm.lazyList
return vm.node from render (for DIY diff)
ES6 ViewClass will use init() instead of constructor && super()
API:view(vm, data, key, opts)
render(vm, data, oldDiff, newDiff)
diff(vm, data)
emitEvent(vm, ...args)
domEvent(...args, e, vm, data, vnode)
onevent(e, vm, data, vnode, args)
vmHook(vm, data)
vnodeHook(vold, vnew)

docs:
in examples, avoid using closured data
post-3.0:

stateful views that directly return templates (functional)
plain-object views, init(), vm.state

thanks everyone for your input. hopefully the changes don't anger any party disproportionately :D

of course, after fixing the demos yet again to work with the updates, it became obvious [1][2][3] why the arg order for events was e, vnode:

since my event handlers typically live in the view closure, they already have easy access to vm.redraw() and vm.data (or the closured data). much like e is unique to an event handler, vnode carries otherwise-inaccessible, granular data that you may have decided to store alongside the specific dom element without having to resort to storeing, diffing & patching stuff on the dom via data-* attrs.
n.el.value is shorter than e.target.value

while it's possible to define the handlers outside the view closure, it's not a pattern i use since it breaks up the view too much and i tend to keep all UI-related stuff inside the closure to isolate my view layer from other code. i'll likely revert back to ...args, e, vnode, vm, data (with the addition of data)
[1] https://github.com/leeoniya/domvm/commit/eb84d6d85434755314761e1eae34b2931c38ed41#diff-8ae1317ae8f9ec75af99307e424b7d74
[2] https://github.com/leeoniya/domvm/commit/eb84d6d85434755314761e1eae34b2931c38ed41#diff-31446e64c030b4bf403890b6804b0364
[3] https://github.com/leeoniya/domvm/commit/eb84d6d85434755314761e1eae34b2931c38ed41#diff-14c86bef983a71d5c9291e8531f5810f

FWIW I'm happy with the route this discussion took. More important than any semantics, is a strong conviction from the main contributor to shape the vision of the project and to stay true to that focus. I think mithril lost some of that, which is why die hard fans are now looking for alternatives.
It also looks like render was trimmed down to 4 args, which I think is much more palatable than 6.
Tangents:
Is the goal to not hit any domvm warning messages before shipping code?
Any thoughts on replacing babel for typescript?

I think mithril lost some of that, which is why die hard fans are now looking for alternatives.

Mithril's API never felt great to me. things like always-global redraw (without granular redraw) and its use of a Controller in pre-1.0 was the deal-breaker that had me look elsewhere. I found domchanger and it felt much better but ultimately pretty slow and still too restrictive. and so i decided to write a vdom lib that took some api bits i liked from both libs and here we are.

It also looks like render was trimmed down to 4 args, which I think is much more palatable than 6.

yep, i've never used key or opts in render and if i ever need them they're both available on the vm or in the closure's args since they're immutable. newDiff is technically the same as vm._diff, but i dont want to promote that ugly pattern.

Is the goal to not hit any domvm warning messages before shipping code?

ideally, yes. but not necessarily. for instance, you may want to define handlers ad-hoc via {onclick: e => alert("clicked " + e.target.id) }. that will throw an INLINE_HANDLER warning because the handler is recreated and rebound on each redraw. it's not ideal but if the view is not perf-sensitive, then stylistically it a bit cleaner than defining the handler outside of render for reuse.
you'll definitely want to avoid UNMOUNTED_REDRAW and MISMATCHED_HANDLER because they can cause undefined behavior in the lib. SVG_WRONG_FACTORY is a notice of incorrect api use. FOREIGN_ELEMENT, REUSED_ATTRS, UNKEYED_INPUT may cause unexpected behavior in the app.

Any thoughts on replacing babel for typescript?

domvm builds use Bublé rather than Babel.
as for typescript, i'm warming up to the syntax, albeit slowly. same for Prettier. i havent done too much testing for bundle size and resulting perf of TSC, so i'm not ready to migrate domvm to it yet. however, i'm open to someone contributing a domvm.d.ts public api definition file.

FWIW I'm happy with the route this discussion took. More important than any semantics, is a strong conviction from the main contributor to shape the vision of the project

I completely agree, particularly with "shape the vision". I like having input, making my case... and I'm happy for Leon to say, "Yeah... nah!". It's very hard to reason about things out of context as Leon's final comment showed, with respect to arg order, "it became obvious why the arg order  for events was e, vnode".

Mithril's API never felt great to me.

Components, "controller", global redraw + redraw suppression are what disenchanted, though the concept is great. But finally, the disengagement of Leo and the sense of "lost-ness" of the community coupled with an apparent desire to complicate the shit out of building it (even if simplicity of use was preserved).
But, what actually made me most nervous with Mithril is the sheer velocity of commits; it felt like this very simple, solid core on which to build an app was becoming the next Behemoth. I very much want to see DOMVM's core stabilize and remain largely untouched, which specific things develop around it's periphery.

i've never used key or opts in render

Neither have I.

as for typescript

I'm very much opposed to it; something like DOMVM should remain Vanilla JS. In no small part because "I very much want to see DOMVM's core stabilize and remain largely untouched", therefore, DOMVM should not need a meta-language on top of JS. Related is that I want to be able to debug POJS if ever there appears to be a problem in DOMVM.

"I very much want to see DOMVM's core stabilize and remain largely untouched",

i assume you're talking about the core api. the only time when the core will remain untouched is when domvm is no longer actively maintained. i do hope that v3 will be the last api iteration for some time.
domvm v1 had aspirations for being 100% build-free. however, that didnt seem to provide the ease-of-contribution benefit it was meant to encourage. people don't even help write docs, lol.
in the end build-free isnt realistic in a complex, well-organized app. you'll always have at least some assembly of modules and domvm left this up to the browser and acript includes, which moved the burden to the frontend/production, which was shitty.
domvm's codebase is not es5 either, and will likely use more es2015 features, not just modules. so the build steps are already there. they're easy but not absent. the build process produces both minified bundles and non-minified es5 bundles with sourcemaps that anyone can debug & tweak without building anything. what language the actual source is written in is only of relevance to those who work on the code, not users of the lib (who will always get es5 bundles). therefore, the aversion to typescript by users is rather misplaced given the current state of affairs.
that being said, i dont see much value that typescript would bring me, the only core dev. the project is small and digestible and i usually code in an editor that doesnt have TS support anyhow. maybe once vscode starts also working well for php, i'll consider switching. i do see a lot of value in a domvm.d.ts typings file so the API can be nicely consumed by users of domvm who prefer write their code in typescript and get the IDE benefits that come with that.

write their code in typescript and get the IDE benefits that come with that

Precisely. No editing environment has lured me away from my trusty vi setup until now.
@lawrence-dol One of the goals of TypeScript is to emit idiomatic, recognizable JavaScript code[1]. No source code mappings necessary. Everything is essentially opt-in, so you can use it merely as a standard ES2015 compiler, which is how I got started.
I found immediate benefits from the implicit types, and eventually moved to VS Code to see the errors and warnings instantly on keystroke, instead of waiting for run time or even build time. Then came the light of inline type definitions, documentation, and source-code, and it is a whole new world. I no longer need to visit some terribly formatted website for documentation, because I can discover a library's API as I consume it, with each keystroke. If I am refactoring something, I can see right away if I forgot to rename a reference.
@leeoniya One of my immediate draws to domvm was its readability. Though it lacked a large community, I felt comfortable reading the source code and confident I could reason about it if necessary. Taking this a step further, if this project was in TypeScript, I would never need to leave my editor. While upgrading versions, mismatched API arguments would be highlighted instantly. I'm totally biased, but embracing types can be a solid form of documentation, and we know everyone loves documentation =)
[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

While upgrading versions, mismatched API arguments would be highlighted instantly.

wouldn't a domvm.d.ts API typings file serve this purpose? creating one wouldn't require adopting TS in the core but still providing all the benefits to consumers of domvm's APIs

for v3, i'm going to drop ES6 class views in favor of plain object views. the didInit(vm) hook is being removed in favor of {init:...} return to align with this.
the main problem with ES6 class views is that the calling convention for all the defined methods needs to drop any vm arg in favor of this to be what users expect. this means testing in the core at each call site and that's not something i want to do. instead, plain object views will provide the same benefit that es6 class views do - method sharing without re-creating them from inside a closure. any kind of inheritance can just be composed in userspace via Object.assign() or whatever - as javascript promotes. i'll still set this === vm everywhere, but i dont think there's much point in using it since it'll be in the args.
there were never real tests for es6 class views, and i'm sure if i were to write them, i would have discovered this issue sooner.

plain object views are pretty sweet. and were basically 0 effort.
https://rawgit.com/leeoniya/domvm/3.x-dev/demos/object-views.html

what are people's thoughts on removing the autoPx functionality (appending px to numeric css object props) from the bundles and leaving it as an optional include? there are a couple reasons i'm considering pulling them out of the builds.

autoPx adds perf overhead because every css property must be tested against an isNumeric check as well as a dictionary of unitless props
the dictionary takes up ~299 gz bytes and by being baked into the lib it's hard to tweak by end users without recompiling domvm.
if i must have inline css, i don't find myself using css objects often, usually opting for short css strings.
when i do use css objects it's typically for performance gains of patching individual props, in which case it's faster to just append the "px" in userspace rather than testing every property and erasing some of the speed benefit.

this means that to get back the functionality, you'd simply include src/view/addons/autoPx.js which would contain:
domvm._autoPx = (function(unitless) {
    return function(name, val) {
        return !isNaN(val) && !unitless[name] ? (val + "px") : val;
    }
})({
    animationIterationCount: true,
    boxFlex: true,
    boxFlexGroup: true,
    boxOrdinalGroup: true,
    columnCount: true,
    flex: true,
    flexGrow: true,
    flexPositive: true,
    flexShrink: true,
    flexNegative: true,
    flexOrder: true,
    gridRow: true,
    gridColumn: true,
    order: true,
    lineClamp: true,

    borderImageOutset: true,
    borderImageSlice: true,
    borderImageWidth: true,
    fontWeight: true,
    lineHeight: true,
    opacity: true,
    orphans: true,
    tabSize: true,
    widows: true,
    zIndex: true,
    zoom: true,

    fillOpacity: true,
    floodOpacity: true,
    stopOpacity: true,
    strokeDasharray: true,
    strokeDashoffset: true,
    strokeMiterlimit: true,
    strokeOpacity: true,
    strokeWidth: true
});

and the default would be
domvm._autoPx = function(name, val) {
    return val;
}

what are people's thoughts on splitting the autoPx functionality

If I've made any use of auto-px, it's accidental. I prefer to be explicit with this and most things. Carve it out, I say.

ditto.

BTW, widows, orphans, opacity are not unit-carrying properties, and lineHeight is most useful as unitless, where 1.5 means 1.5 x the font height. I would be surprised if I specified 3 lines for widows and it because 3 pixels; ditto for lineHeight; 1.5px is an odd thing to specify, but 1.5 is perfectly natural.
This tends to violate the principle of least surprise.

the current unitless list (as seen above) contains props that will not have px auto-added. all the cases you mentioned are properly handled.

the current unitless list...

There I go again, not "listening" well; my mind expected a whitelist of values that can have px appended. Sorry.

i ended up with a compromise. i really don't want script includes and also don't want the smaller builds expanding. i moved autoPx up to the micro build and added domvm.defineElementSpread & domvm.defineSvgElementSpread to it.

xlink:href support has landed. i also brought back the DATA_REPLACED devmode notice since v3 will continue to pass vm.data into the closure.
while i may still do some internal cleanup, the v3 features & API are now fully baked. if anyone feels adventurous, please take it for a spin and report any issues or perf regressions.
i'm gonna spend some time re-testing the demos, running the full benchmarks and updating the docs. baring any serious regressions, v3 should be tagged sometime next week.

initial round of benchmarks shows a possible minor regression (~5%) in dom creation for massive trees (30k elements, 10k subviews). everything else falls within the noise variance. mem useage shows ~15% reduction. i think we're good for perf.

almost forgot about domvm.streamCfg(). i'm gonna convert it to a domvm.config() option:
// old
domvm.streamCfg({
    is: null,
    val: null,
    sub: null,
    unsub: null,
});

// new
domvm.config({
    stream: {
        is: null,
        val: null,
        sub: null,
        unsub: null,
    }
});

btw, i removed the flyd adapter from domvm core and moved it into userspace in the demos: https://github.com/leeoniya/domvm/blob/3.x-dev/demos/streams.html

SSR benchmarks [1] are in. this is for 204 views & 2007 DOM nodes
vidom             // 1630 ops/s
inferno           // 1430 ops/s
domvm             // 1246 ops/s
preact            //  604 ops/s
react.with-hack   //  228 ops/s
vue               //  100 ops/s
react             //   30 ops/s

lol React
[1] https://github.com/dfilatov/vidom/tree/master/benchmarks

k guys, i have a barebones playground working. please try it.
https://leeoniya.github.io/domvm/

Looks good man, it'd be nice to be able to resize the panes.

lots of stuff would be nice :) the whole thing is 216 LOC [1]; contributions always welcome!
[1] https://github.com/leeoniya/domvm/blob/gh-pages/playground/index.html

@leeoniya

i assume you're talking about the core api. the only time when the core will remain untouched is when domvm is no longer actively maintained.

I guess what I meant was the conceptual core, which includes the API. I hope that the core of DOMVM becomes highly stable, and the out-of-the-box functionality is delivered as optional parts of an ecosystem, rather than DOMVM continually growing, in both complexity and size.
You've shown every proclivity, to date, in keeping the core small and laying in additional functionality. I think that's good.

By the way, I am using V3 for a new project. So far, so good. I quite like the ergonomics of the view returning an object, with the init and render functions outside the enclosure.

I quite like the ergonomics of the view returning an object, with the init and render functions outside the enclosure.

sounds like you might as well just use plain object views:
const View = {
  init:   (vm)       => {...},
  render: (vm, data) => tpl,
};

of course, after fixing the demos yet again to work with the updates, it became obvious [1][2][3] why the arg order for events was [what it was] ... i'll likely revert back to ...args, e, vnode, vm, data (with the addition of data)

I completely agree having just ported Mithril withAttr to use a little event handler. In the context having the specified arguments first was perfectly natural.

🎉 v3.0.0 🎉
changelog: https://github.com/leeoniya/domvm/releases/tag/3.0.0

heads up! event handler registration for vm.emit() has changed:
vm.on(evName, callback) -> vm.config({events: {evName: callback}})
sorry i had to do this API break post-3.0, but it was an oversight and this change makes things more uniform with other similar changes introduced in 3.0.
will be tagging 3.0.1 in a bit.


Support for Java 11

Also took the opportunity to clean up pom files.
Changes required were minimal.

Work complete


Organize workshop on functional testing

Organise a workshop for the whole team on functional testing. Take a concrete example with high priority functionality and create example test suite in the workshop.
Definition of done

[ ] Plan the workshop
[ ] Book the workshop.
[ ] Facilitate the workshop
[ ] Document the test suite created in the workshop.

Done.


Scroll To Top

This change is

src/components/translatable/Translatable.js, line 53 at r1 (raw file):

          config,
        };
        _translatable = <DataTable onRef={(element) => dataTableElement = element} {...translatableProps} />;

This only appears to apply to changing of .tsv files since the element is limited to datatableElement. Can you abstract this out to the  inside of the return so that it works for markdown files as well?

Lol, I left a comment before I realized this was a wip.


Usage of DarIA Images

At the moment, several of the newer routines are performed without the use of DarIA images. I suppose that this is because the features that the DarIA images provide in some sense is useless for those routines. However, if we want to keep the Image-class I suggest that we make all routines run on DarIA images instead of image-matrices. That way we can limit the direct user interface to external libraries, perhaps completely, as well as automatically transform between BRG and RBG where it is natural.

There is indeed very few features that daria.Image provides which is of greater importance for any postprocessing. Mainly the coordinate system is of greater use so far. Other than that the class actually only provides very litte functionality required for the analysis itself. It is more output routines.
Note however, that the for instance daria.Image is very useful to have for daria.Patches. Here the knowledge of the coordinates of the corners and centers of the patches are directly obtained from objects as the coordinate system.
At this stage, I would not be to concerned with this issue. In my opinion, the development of daria is still in a fast-growing phase. We can still make an extra effort when we know what we want and what for. I can imagine that patches will become more relevant in the near future. And then also daria.Image


Improve tests

Increase coverage
Remove imagemagik from CI and non stable python versions

Oups, I deleted flower_lego.png.
This is because the default_path test cleans up after itself like all tests should.
The fix is to have the flower_lego.png image in a different location than flower.jpg

All fixed

conflicts


introduce feature flag enable artifacts

This is part of TEP-0147 Phase 1 implementation Plan  #7693
We need a flag to guard artifacts use, only this feature flag enable can produce/consume artifacts from $(steps.artifacts.path)
Adding actual validation is not in the scope, the issue only asks to create a feature flag like #7277 for future use to reduce the size of prs.

/assign ericzzzzzzz


Update zio, zio-test, zio-test-sbt to 2.0.14

About this PR
📦 Updates

dev.zio:zio
dev.zio:zio-test
dev.zio:zio-test-sbt

from 2.0.0-RC1 to 2.0.14
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "dev.zio" }
}]

labels: library-update, early-semver-pre-release, semver-spec-pre-release, commit-count:1

Superseded by #225.


[web]: Text within an HtmlElementView by default is red

The default body text color mentioned in #58828 as an indicator if an app forgets to pick a style may have implications with content in web platform views, e.g. google_maps_flutter_web, even if a style is set on the Flutter side.

It's possible that the resolution would be to require embedded web platform views to do some degree of CSS reset, which might be worth calling out in documentation. There may be some related history in #67740 and #50452.
Potential documentation sites:

https://api.flutter.dev/flutter/widgets/HtmlElementView-class.html
Somewhere in https://docs.flutter.dev/development/platform-integration/web/

Steps to Reproduce
https://dartpad.dev/5661e339114f8e41950451dce63ebad7

Repros on both stable and master on DartPad.
Repros on master on both Chrome and Edge in debug and release locally. Also tested and repro'd on Chrome with HTML renderer in debug.
Repros with or without textTheme: Typography.blackMountainView.

Expected results: Text styling similar to user-agent default or the nearest Flutter Theme.
Actual results: Red text from the body text styling debug indicator.

Code sample
import 'dart:ui';
import 'dart:html';
import 'package:flutter/material.dart';

void main() {
  platformViewRegistry.registerViewFactory(
      'example', (_) => DivElement()..innerText = 'Hello, HTML!');

  runApp(MaterialApp(
      title: 'Example',
      theme: ThemeData(colorSchemeSeed: const Color(0xff000000)),
      home: Scaffold(
          appBar: AppBar(
            title: const Text('Example'),
          ),
          body: Column(children: const [
            Text('Hello, Flutter!'),
            SizedBox(
                width: 512,
                height: 512,
                child: HtmlElementView(viewType: 'example'))
          ]))));
}

Not sure how related this is, but default text color is red on mobile web, see text "TextSpan" on
https://easythai.net
is default red on mobile browser, but black on Window desktop browsers, I created repo for this (and issue #115046)
https://github.com/arnirichard/fluttertest
Please let me know if this is a separate issue and I will create a bug

@AsturaPhoenix,  thanks for filing the issue. This issue is reproducible on the latest stable and master channels.
Both canvaskit and html renderers are affected.

Demo

Sample code (completed)
import 'dart:ui' as ui;
import 'dart:html';
import 'package:flutter/material.dart';

void main() {
  ui.platformViewRegistry.registerViewFactory(
      'example', (_) => DivElement()..innerText = 'Hello, HTML!');

  runApp(MaterialApp(
      title: 'Example',
      theme: ThemeData(colorSchemeSeed: const Color(0xff000000)),
      home: Scaffold(
          appBar: AppBar(
            title: const Text('Example'),
          ),
          body: Column(children: const [
            Text('Hello, Flutter!'),
            SizedBox(width: 512, height: 512, child: HtmlElementView(viewType: 'example'))
          ]))));
}

flutter doctor -v (stable and master)
[✓] Flutter (Channel stable, 3.3.8, on macOS 13.0 22A380 darwin-x64, locale en-VN)
    • Flutter version 3.3.8 on channel stable at /Users/huynq/Documents/GitHub/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 52b3dc25f6 (23 hours ago), 2022-11-09 12:09:26 +0800
    • Engine revision 857bd6b74c
    • Dart version 2.18.4
    • DevTools version 2.15.0

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-33, build-tools 31.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14A400
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2021.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)

[✓] IntelliJ IDEA Community Edition (version 2022.2.2)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 70.0.5
    • Dart plugin version 222.4167.21

[✓] IntelliJ IDEA Community Edition (version 2022.1.1)
    • IntelliJ at /Users/huynq/Library/Application Support/JetBrains/Toolbox/apps/IDEA-C/ch-0/221.5591.52/IntelliJ IDEA CE.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.73.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.52.0

[✓] Connected device (3 available)
    • iPhone 14 Pro Max (mobile) • 332079AF-E895-4685-910E-7B1E18B0C6B8 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-16-0 (simulator)
    • macOS (desktop)            • macos                                • darwin-x64     • macOS 13.0 22A380 darwin-x64
    • Chrome (web)               • chrome                               • web-javascript • Google Chrome 107.0.5304.110

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

[!] Flutter (Channel master, 3.6.0-3.0.pre.1, on macOS 13.0 22A380 darwin-x64, locale en-VN)
    • Flutter version 3.6.0-3.0.pre.1 on channel master at /Users/huynq/Documents/GitHub/flutter_master
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision cb224d10e3 (26 minutes ago), 2022-11-13 21:57:38 -0500
    • Engine revision b7567b92c7
    • Dart version 2.19.0 (build 2.19.0-394.0.dev)
    • DevTools version 2.19.0
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-33, build-tools 31.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14A400
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2021.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)

[✓] IntelliJ IDEA Community Edition (version 2022.2.2)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 70.0.5
    • Dart plugin version 222.4167.21

[✓] IntelliJ IDEA Community Edition (version 2022.1.1)
    • IntelliJ at /Users/huynq/Library/Application Support/JetBrains/Toolbox/apps/IDEA-C/ch-0/221.5591.52/IntelliJ IDEA CE.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.73.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.52.0

[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-x64     • macOS 13.0 22A380 darwin-x64
    • Chrome (web)    • chrome • web-javascript • Google Chrome 107.0.5304.110

[✓] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

@arnirichard Your issue is different than this one and is being tracked at #115046. Please follow up on it for further updates.

@AsturaPhoenix as a workaround, for google maps, we add a classname of infowindow-snippet here that might help you override the default from a standard stylesheet on your page.

Thanks; for now I'm just wrapping the entire platform view in a CSS reset since I had to fork it anyway to do overlays on web.
e.g. https://github.com/AsturaPhoenix/flutter-plugins/commit/bf627ad5f086c4152717f2eaf39642a48b506dfc
That snippet is interesting though; thank you; I had noticed that web lets us put HTML into an info window while Android does not, and I was curious about things.

@AsturaPhoenix very interesting. Another thing you could do to reset that is maybe to apply the reset to the element that we use to define the slot:

something like:
<style>
  flt-platform-view {
    all: initial;
  }
</style>

Maybe that fixes your platform view without you having to explicitly re-wrap them with another DIV?

something like this somewhere in your index.html:
<style>
  flt-platform-view {
    all: initial;
  }
</style>

@ditman I really liked how your idea would patch the problem for all web platform views rather than just Maps, but it turns out it has a hidden side effect that it's taken me a while to notice. Somehow, applying the reset on the flt-platform-view (rather than the map div) may also prevent stacked elements wrapped in PointerInterceptor from displaying 👆 cursors.

Not sure if that'll have any bearing on a long-term fix, but it could be a test case to keep in mind.

@AsturaPhoenix apologies, forgot all about the cursor style that we set in the body element, you may be able to extend the fix I proposed above with the following CSS:
flt-platform-view {
  all: initial;
  cursor: inherit;
}

You can fiddle with it here, without having to rebuild your webapp, this is a pure CSS issue: https://jsfiddle.net/ditman/rk264981

@ditman No worries; this is all still pretty early prototyping so a bit of churn is fine. I think I will stick with limiting the reset to the maps div for now though just in case there are any other styles that need to make it through to the platform view for other purposes, since these are hard to notice.

In my latest change to the engine, I've moved the red styling away from the body tag, and into the ShadowDOM of the Flutter app, this issue should not happen anymore. Styling of the .infowindow-snippet needs to happen in a CSS stylesheet, and cannot be controlled via flutter though.


tooling: should not need to include from source/

Issue Template
Title: One line description
Description:

In  the comments in #2921 @mattklein123 noted that it was surprising we were including from "source/".  There are two files that do that

./source/common/ratelimit/ratelimit_impl.h:#include "source/common/ratelimit/ratelimit.pb.h"
./test/integration/ratelimit_integration_test.cc:#include "source/common/ratelimit/ratelimit.pb.h"

The latter can just have the reference removed, but ratelimit_impl.h picks up a generated protobuf header from source/ the proto header is definitely needed, and the build system does not pick it up without the source/ prefix. Lots of other protobuf headers are picked up in Envoy without the source/ prefix so we just need to figure out what's different about this one.

once this is resolved, source/ can be removed from tools/common.py as a legal header prefix.

It appears that ratelimit.proto exists in source/common/ratelimit instead of the api/ directory.  I checked the source/ directory and it is the only protobuf file left which is why you'd notice the discrepancy with other profobuf files.
➜ find ./source -name '*.proto'
./source/common/ratelimit/ratelimit.proto

It looks quite similar to api/envoy/service/ratelimit/v2/rls.proto

@taion809 see https://github.com/envoyproxy/envoy/issues/1034

/assign mk46


Improve argument handling

Description
Changes proposed in this pull request:

Improve argument handling
Fix lint

Related issue(s)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

/lgtm

/lgtm

/cat

/meow

/lgtm