Add More IAM Role Attachment Debugging

What happened?
When I created an IAM role with an assume role policy in crossplane, it resulted in crossplane thinking there is a mismatch between the Assume Role Policy defined in the manifest file and the Assume Role Policy that is created in AWS. However, there is no real change in the assume role policy (I verified this with AWS). So every time I apply an update, it sends an IAM API call to  AWS to perform an update.
It would be beneficial if when I turned on Debug logs that additional information was given on what the change actually was. This would help diagnose what is occurring.
Currently the debug log only shows this: Successfully requested update of external resource. If the specific change such as the IAM role name, or assumeRolePolicyDocument was detailed then it would be helpful.
How can we reproduce it?
This is the IAM Role that I have defined. (Note: I replaced the AWS Account Id and oidc provider id values with fake values)
apiVersion: identity.aws.crossplane.io/v1beta1
kind: IAMRole
metadata:
  annotations:
    crossplane.io/external-name: cc-cluster-autoscaler-qa01
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"identity.aws.crossplane.io/v1beta1","kind":"IAMRole","metadata":{"annotations":{},"labels":{"app.cloudcheckr.com/appname":"cc-cluster-autoscaler-qa01"},"name":"cc-cluster-autoscaler-qa01"},"spec":{"forProvider":{"assumeRolePolicyDocument":"{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n      {\n          \"Effect\": \"Allow\",\n          \"Principal\": {\n              \"Federated\": \"arn:aws:iam::111111111111:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/000000000000000000\"\n          },\n          \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n          \"Condition\": {\n              \"ForAnyValue:StringEquals\": {\n                \"oidc.eks.us-east-1.amazonaws.com/id/000000000000000000:sub\": \"system:serviceaccount:kube-system:cluster-autoscaler\"\n              }\n          }\n      }\n  ]\n}\n","tags":[{"key":"envName","value":"qa01"},{"key":"owner","value":"crossplane"}]},"providerConfigRef":{"name":"aws-provider"}}}
  creationTimestamp: "2021-06-26T00:01:13Z"
  finalizers:
  - finalizer.managedresource.crossplane.io
  generation: 2
  labels:
    app.cloudcheckr.com/appname: cc-cluster-autoscaler-qa01
  name: cc-cluster-autoscaler-qa01
  resourceVersion: "133949811"
  selfLink: /apis/identity.aws.crossplane.io/v1beta1/iamroles/cc-cluster-autoscaler-qa01
  uid: e36e9922-1b68-43ce-a4ee-e3f4a0491e53
spec:
  deletionPolicy: Delete
  forProvider:
    assumeRolePolicyDocument: |
      {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Federated": "arn:aws:iam::111111111111:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/000000000000000000"
                },
                "Action": "sts:AssumeRoleWithWebIdentity",
                "Condition": {
                    "ForAnyValue:StringEquals": {
                      "oidc.eks.us-east-1.amazonaws.com/id/000000000000000000:sub": "system:serviceaccount:kube-system:cluster-autoscaler"
                    }
                }
            }
        ]
      }
    maxSessionDuration: 3600
    path: /
    tags:
    - key: envName
      value: qa01
    - key: owner
      value: crossplane
  providerConfigRef:
    name: aws-provider
status:
  atProvider:
    arn: arn:aws:iam::111111111111:role/cc-cluster-autoscaler-qa01
    roleID: AROARIYQWUPA5MY3ATMFF
  conditions:
  - lastTransitionTime: "2021-06-26T00:01:13Z"
    reason: Available
    status: "True"
    type: Ready
  - lastTransitionTime: "2021-06-26T00:01:13Z"
    reason: ReconcileSuccess
    status: "True"
    type: Synced

Honestly this bug is a little strange because other IAM roles are defined with the same configuration values, except with different names, and there are no issues.
What environment did it happen in?
Crossplane version: v1.2.3
provider-aws-controller: v0.19.0
Kubernetes version: v1.19.8-eks-96780e
Kubernetes distribution: EKS

I agree, I think it would be cool if most IsUpToDate functions returned some kind of info about what is not considered up to date (at least the field names, but maybe even a full cmp.Diff). I've had similar issues multiple times and had to debug by modifying the code.


sync: add support for moved fixed bugzilla bugs to verified

This PR adds initial support for moving bugzilla bugs that were fixed in an accepted release to the VERIFIED state if the bug's QA contact approved the PR that fixed the bug.
For now, this will print what would be changed in the logs. If everything works as expected, I will make another PR to allow the release-controller to actually make the changes.
/cc @stevekuznetsov

/hold
We need to make sure the podspec is updated for release-controller in production before merging this

/hold cancel

/lgtm
/approve


Changeing the toolbar color

Is it possible to change the color of the toolbar? Maybe the icons in the toolbar?
I found a place in the theme with the comment customize your theme, but when i build the project it is set back to the defaults of the image picker.

override the colors resource file,add this in colors.xml
<color name="ef_colorPrimary" >YOURCOLOR</color>     <color name="ef_colorPrimaryDark" >YOURCOLOR</color>

@kozmabalazs @wooi
You can override the color resources like @wooi mention
or in 1.5.0 you can use theme support like this
ImagePicker imagePicker = ImagePicker.create(this)
  .theme(R.style.ImagePickerTheme)
  .start(RC_CODE)

With theme that extend ef_BaseTheme
For more example please kindly see the sample app. Thank you 😄

Thank you for help :)


Reorder initialization of IVVI

Since set_pol_dacrack makes a call to set_parameter_bounds, and set_parameter_bounds references dacs, dacs (parameters) need to be added to the instrument before calling set_pol_dacrack
Fixes #issuenumber.
Changes proposed in this pull request:

slightly reorder inicialization of IVVI

@astafan8

@kNalj please fix the Codacy complaint


Dependabot bumps combined

Description
Merged all small dependabot updates into one PR

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: MrDach:x: dependabot[bot]You have signed the CLA already but the status is still pending? Let us recheck it.


Development

added additional chapters about developing the plugins
added integration tests (they do not work properly yet)
refactored both plugins


kaboom.debug.hoverInfo doesn't seem to respect camera position

Can be seen in https://kaboomjs.com/examples#level
Expected behavior:
I should see info on an object after hovering over it regardless of how the camera is positioned.
Observed behavior:

See cursor position in the above images. Hover calculations appear to be happening irrespective of the current camera transform. As such, you have to position your mouse in unintuitive positions to hover objects.
(By the way - Thank you for the excellent library!)

Hi! This is actually just fixed in https://github.com/replit/kaboom/commit/e1144d0345f529f7e9c2cc1f26e54bbb7830731b haha! If you refresh the page it should work properly. It's on master now and will be there in the next release

oh lmao
Thank you!


CTE autocompletion does not work

Description
In this latest release, it is said that "Smart completion for CTE queries (WITH/SELECT) was fixed". However, even a simple CTE autocompletion does not work. Can provide examples if needed. Is this the expected behavior? Here is a screenshot.

DBeaver Version
Community Edition Version <IP_ADDRESS>308201919
Operating System
MacOS Ventura 13.5
Database and driver
Snowflake Server: 7.29.1
Snowflake Driver: 3.13.6
Steps to reproduce

Make a simple query with easy column aliases.
Then wrap it around as a CTE
Try selecting columns off of this CTE
You'll see that the autocompletion still does not work. Autocompletion for queries not CTE works.

Additional context
No response

It must be a mistake in release notes. We have fixed SELECT with WITH clause in FROM part #20096, but haven't worked on columns autocompletion for selects with CTE and subqueries. Thank you for the interest.

Ok thank you. Do you have an estimate as to when you'll introduce autocompletion for CTEs?

Ok, thanks for the information.


Multiline string logging with variablesReference

Using OutputEvent with a variablesReference, multiline logs aren't supported anymore.

Especially a problem when I need to print a stack from an exception or console.trace()

Maybe not straightforward to fix since variables are always 1-line everywhere else?

I think those \n are going into the console height calculation though -

I think we fixed this last minute prior to 1.8 release. Anywasy works for me now
We might fix how we hande new line and output events so we should still keep this in mind as a good test case

In my original example I was using variableReference, but if you try that now, it won't be because I changed it to not use variableReference when logging only text. I still see this if I include an object like in my second comment:

I think those \n are going into the console height calculation though -

Works for me.
My steps:

insiders, mac, node2 debug session stopped
in repl: console.log('a\nb', {a : 1})

Please try with latest or give me your exact steps

It does work now, maybe it was fixed by the fix for #17404. Thanks


Add support for Safari

This PR adds safari extension code.
I haven't upload the extension to the Safari Extension Gallery yet, because I think it is better for the original author to do this.
The jquery.js is hard coded into the inject.js because in Safari inject scripts can not access objects created by other .js files.

Closing as stale.


Update mandatory language of the form

The mandatory language of the form must be the current language (french OR english, not both). Only the mandatory fields in the current form language must be filled (validation when form is submitted).

See #706  The mandatory status was kept for both French and English


Enable use of custom provisioned engine images

We have many requests from users to support a few interrelated features:

Support for custom CA certs needed to connect to private registry: https://github.com/dagger/dagger/pull/3943 https://github.com/dagger/dagger/issues/2142#issuecomment-1320900593
Setting up a custom runner not in docker https://github.com/dagger/dagger/issues/3939
Use of an engine image pulled from a mirror https://discord.com/channels/707636530424053791/1031785076029128784/1044829278367404132
Connecting to the engine over different protocols like tcp https://github.com/dagger/dagger/issues/3939
Support for running privileged execs https://github.com/dagger/dagger/issues/3874

Crucially, this is probably something we can't enable by default, it has to be something that users can opt into enabling in their engine if they are comfortable w/ the security tradeoffs.

No issue for it yet AFAIK, but @marcosnils mentioned a possible need to configure buildkitd GC policies in playground to help prevent the disk from filling.
Running rootlessly https://github.com/dagger/dagger/issues/1287

These all require specific individual solutions, but the commonality between them is that they require use of an engine image different than the default ghcr.io/dagger/engine one we publish and execute in our default provisioning codepath. The difference may be in that they require more files in that engine (e.g. the CA certs), that they need some sort of non-default configuration or that they need to execute it differently than our default provisioning codepath does.
This issue is just meant to tackle the high-level approach to this problem. After we agree on this we can tackle the particulars of each feature individually in separate issues.

Preferred Solution - Experimental Docs in our Git Repo
To start, I think we should just document the process of customizing the engine. The docs also shouldn't live on our website quite yet as they will be referencing experimental unstable features that we will likely end up adjusting (if not entirely rethinking).

The docs can instead just live in markdown in our git repo for now and will be headed with warnings that this is all experimental+unstable. Our website could have a FAQ about custom engine images that points to this internal doc, but shouldn't emphasize the use case more than that yet.
I think this is the right place to start because this is a really tricky use case to get right. "Running engine in a custom way" opens up a pandora's box of possibilities. Ideally, we should not only try to support as many of these as possible in the long run, we should also ensure that they each work smoothly. That implies significant engineering effort not only to get them working but also tested.
If we dive right into something like docker machine or buildx builders where we introduce automation around managing and customizing these workers, we'll be making a bigger commitment to supporting that interface stably and also putting in a bigger engineering effort towards something that we may end up changing, reverting, etc.

Overall, starting with docs allows us to unblock users who need these features and then gather data from them on what works well and what needs a better OX. Once we have that data, we can start putting together more long term solutions (or, there's always a chance our process will actually be good enough and we can just move it from experimental -> officially supported and doc it on our website).
One big risk worth calling out here is that this means we will be documenting how to setup buildkit specific config files like /etc/buildkit/buildkitd.toml, so we will be directly exposing APIs we don't control directly.

See the documentation of that file here: https://github.com/moby/buildkit/blob/master/docs/buildkitd.toml.md
Given that we are marking this all as experimental anyways, I think this is fine to start out with.
However, we can consider instead having our own wrapper around this (maybe dagger.toml or just a command-line flags that wrap the entrypoint of the image)

This is more engineering effort + complexity up front in exchange for being in full control of our interface immediately up front.

What to doc
Where is our base image?
We are working on setting up a vanity URL for our registry. Once that's ready we'll just point users to it.
How do I customize the base image?
This will depend heavily on how users normally build images. E.g. if you use dockerfiles, then you can use that to pull our image, customize it and push it to a registry. If you use toolxyz, use that. Etc.
We thus can't document this thoroughly. For now, just giving one simple example (e.g. Dockerfile) should suffice.
Of course, users can also user Dagger to customize the engine image, which in theory is ideal. This would be especially awesome in a future w/ extensions where we could have an engine image extension that outputs a Container for our current image based on input customizations like CA certs, etc.
The downside is that this creates chicken-egg bootstrapping problems. We're willing to deal with that in our CI, but the way of solving that generally across any sort of environment users may need to execute in is not clear. At the very minimum, we need more user data to know whether and how we could solve this. And the best way to get user data is to let them first customize using whatever build tool they normally use and get feedback from there.
How do you know when the base image is updated? When should you upgrade to use it?
For now, to know about new engine image releases just subscribe to our Github releases.

If anyone knows of better approaches here I'm all ears, I admittedly don't have a ton of experience around this sort of problem specifically

To know which engine base image a given SDK is compatible with, I think we should for now just highlight that in the release notes for the SDK. E.g. This SDK uses registry.dagger.io/engine:v0.5.6.
How do you configure CA certs for a registry in the image?
It will require putting them somewhere in the image and then setting up /etc/buildkit/buildkitd.toml as (sort-of) documented here: https://github.com/moby/buildkit/blob/master/docs/buildkitd.toml.md
How do you configure "engine-wide" settings like turning on privileged execs, gc policies, etc.?
This again will just require setting up /etc/buildkit/buildkitd.toml as (sort-of) documented here: https://github.com/moby/buildkit/blob/master/docs/buildkitd.toml.md
Once you've built an engine image, how do you run it?
This will also depend very heavily on how the user runs container images generally. Specifics vary from one container engine to another.
We can just document the docker run flags we use, explain them and tell users to use an equivalent setup on the engine of their choice.
How do you tell an SDK and/or CLI to connect to the custom engine once its running?
We will tell them how to use _EXPERIMENTAL_DAGGER_RUNNER (as described here: https://github.com/dagger/dagger/issues/3830)
Alternative Possibilities
A lot of this will be possible in the longer-run; we aren't ruling them out by not doing them now.
Custom config file and/or entrypoint flags (rather than passing through to buildkitd)
Rather than directly having users setup /etc/buildkit/buildkitd.toml, we can immediately jump into using our own config file that only exposes the knobs we want to expose.
Alternatively, instead of a config file we could make our entrypoint be a wrapper script that exposes those knobs via command line flags.
If we wanted to truly and fully control this in a way where users can't skirt around it we'd need to wrap the full buildkitd binary, which is entirely possible too.
CLI-based management of workers
This would be something like docker machine or the buildx builder interface where runners can be provisioned and managed via a CLI interface.
As much as I'd like to avoid this, it feels inevitable in the very long run that we'd want this eventually. If we don't, someone else will create a utility for doing this. However, as stated above, it's very tricky to get this right so we shouldn't rush into it until we have more initial feedback and data from users.
Use Dagger to build custom Dagger engines
As mentioned above, this is great in every way except for the bootstrapping headaches it will probably cause in many scenarios. We shouldn't rule out having an extension that builds custom engines in the long run, but we shouldn't rush into making it the one and only way immediately.

cc @shykes @aluzzardi @vito

I am very wary of enabling this as a support user-facing feature (even for power users). I think all the requirements you listed can, and should, be implemented without requiring a custom image:

Support for custom CA certs needed to connect to private registry: https://github.com/dagger/dagger/pull/3943 https://github.com/dagger/dagger/issues/2142#issuecomment-1320900593

This should be exposed in the Dagger API. Having it manageable only by a static config file is bad UX, and we should not inherit it from buildkit.

Setting up a custom runner not in docker https://github.com/dagger/dagger/issues/3939

Can't this be done with the regular Dagger Engine image, just with a different provisioning method?

Use of an engine image pulled from a mirror https://discord.com/channels/707636530424053791/1031785076029128784/1044829278367404132

Same as above: same image, just different provisioning method.

Connecting to the engine over different protocols like tcp https://github.com/dagger/dagger/issues/3939

We should design and implement this as a regular Dagger Engine feature. Exposing underlying buildkit configuration IMO is opening a pandora box that we will never be able to close.

Support for running privileged execs https://github.com/dagger/dagger/issues/3874
Crucially, this is probably something we can't enable by default, it has to be something that users can opt into enabling in their engine if they are comfortable w/ the security tradeoffs.

I disagree actually. It should always be enabled, and gated by adding a concept of "privileged operation" and "privileged client" to the GraphQL API. Then add an authorization hook to the engine, to let operators decide which clients, if any, have access to the feature. But the feature should always be enabled, without having to tweak static configuration files or ask sysadmins to do it. Otherwise, the Dagger ecosystem will splinter in two parts: the engines with privileged exec enabled, and those with privileged exec disabled. Some pipelines will only run on one of those two subsets of the ecosystem. This is a fundamental breach of our promise of "run any pipeline anywhere" and must be avoided at all cost.

No issue for it yet AFAIK, but @marcosnils mentioned a possible need to configure buildkitd GC policies in playground to help prevent the disk from filling.

I don't know the specifics, but same idea as above.
Of course implementing all the above will take time, and I realize some of it is difficult design & engineering. In the meantime, power users are stuck without all the configuration knobs they want and would like an escape hatch. I think the escape hatch should be to fork the dagger repo and build your own image from source. This should not be documented as a user-facing feature. As painful as it is to have some power users give up because the feature they need is not yet ready, and doing it all from source without user docs is too hard; that pain is nothing compared to having power users cross all these one-way doors.
The risk if we are not careful is that the stopgap becomes the preferred solution, and either we never get around to shipping the "real" solution, or by the time we do it doesn't matter, because all users rely on the stopgap and are not willing or able to switch.

@shykes your concerns make sense, I was approaching this from the perspective that we're getting a ton of requests around all this and wanted to find the quickest possible solution to giving users a barebones escape hatch so we can get more data and then use that to figure out the right end design.
You're right though that technically they are free to just fork right now. I think that increases the risk that they just give up or stay forked for a long time, which has to be balanced against the other risk of them using our temporary solution and pressuring us to support it for a long time.
But if we can find consensus on the right long-term approach and get it implemented in a short time frame, I guess that's the best of both worlds.

This should be exposed in the Dagger API. Having it manageable only by a static config file is bad UX, and we should not inherit it from buildkit.

Good point, it will require upstream changes in buildkit but I thought about it and realized there might be a relatively straightforward path to implementing it actually. Asked about it here: https://github.com/moby/buildkit/issues/3366

Can't this be done with the regular Dagger Engine image, just with a different provisioning method?

Same as above: same image, just different provisioning method.

Due to my original approach, I was grouping everything together into this issue that would end up having the solution of "just document it and have the user set _EXPERIMENTAL_DAGGER_RUNNER". So that includes both when you need a truly custom image and when you just need to pull the image or run it in a different way. In my original thinking they are all tied together.
The title of the issue wasn't clear though, that's my bad, I changed it now to reflect that. Depending on how we decide to approach the problems here, it will most likely make sense to split this up into separate issues. I'll do that at that time.

We should design and implement this as a regular Dagger Engine feature. Exposing underlying buildkit configuration IMO is opening a pandora box that we will never be able to close.

Yeah I'm all on board with not directly exposing the buildkitd configuration if we consider the risk too big and are willing to trade some more upfront effort.
The question then is where this knob for configuring where the remote engine listens should exist. If we are going right to what we want the long-term solution to be rather than a temporary escape hatch, then my only immediate idea is to include the provisioning management as part of the CLI since it's something that has to be configured when the engine starts.
Let me know if there's other ideas on approaches here. Designing a CLI interface around all that will be a separate issue if we want to pursue it.

I disagree actually. It should always be enabled, and gated by adding a concept of "privileged operation" and "privileged client" to the GraphQL API. Then add an authorization hook to the engine, to let operators decide which clients, if any, have access to the feature. But the feature should always be enabled, without having to tweak static configuration files or ask sysadmins to do it. Otherwise, the Dagger ecosystem will splinter in two parts: the engines with privileged exec enabled, and those with privileged exec disabled. Some pipelines will only run on one of those two subsets of the ecosystem. This is a fundamental breach of our promise of "run any pipeline anywhere" and must be avoided at all cost.

Same as before, I'm all onboard with not exposing this knob via buildkitd config directly and also on board with figuring out the ideal long term approach and doing that right away instead if we are willing to trade time+effort.
The thing that immediately comes to mind is something like k8s w/ RBAC based on mutual tls certs or similar. If we're going that route, it also is probably something that should be configurable at runtime. Maybe the engine should expose an "admin" graphql API for configuring knobs like who's allowed to run a privileged exec, what the GC config is, etc. This would obviously only be served to authorized clients.
That's no small task, but let me know if you agree something in that direction is where we'd want to go in the long run. Then we can start figuring out the path to it (in a separate issue).

@shykes your concerns make sense, I was approaching this from the perspective that we're getting a ton of requests around all this and wanted to find the quickest possible solution to giving users a barebones escape hatch so we can get more data and then use that to figure out the right end design.
You're right though that technically they are free to just fork right now. I think that increases the risk that they just give up or stay forked for a long time, which has to be balanced against the other risk of them using our temporary solution and pressuring us to support it for a long time.

Agreed on all points.

But if we can find consensus on the right long-term approach and get it implemented in a short time frame, I guess that's the best of both worlds.

Yes please 😁 I believe it's doable.

This should be exposed in the Dagger API. Having it manageable only by a static config file is bad UX, and we should not inherit it from buildkit.

Good point, it will require upstream changes in buildkit but I thought about it and realized there might be a relatively straightforward path to implementing it actually. Asked about it here: moby/buildkit#3366

An upstream change will be cleaner. But while we wait for that, we could just use duct tape? For example parametrize it in our OCI image somehow? As a volume to be mounted, or some other mechanism? The key being that we release the engine as an OCI image and not an individual binary, which gives us an unfair advantage over upstream buildkit for implementing solutions.

Can't this be done with the regular Dagger Engine image, just with a different provisioning method?

Same as above: same image, just different provisioning method.

Due to my original approach, I was grouping everything together into this issue that would end up having the solution of "just document it and have the user set _EXPERIMENTAL_DAGGER_RUNNER". So that includes both when you need a truly custom image and when you just need to pull the image or run it in a different way. In my original thinking they are all tied together.
The title of the issue wasn't clear though, that's my bad, I changed it now to reflect that. Depending on how we decide to approach the problems here, it will most likely make sense to split this up into separate issues. I'll do that at that time.

Yeah, I see why you grouped them, but it makes sense to split them, as the timing and design constraints are different IMO:

Run the unmodified dagger engine image yourself, customize how it's provisioned: no big design risk, high pressure to ship it soon
Create a custom dagger engine image to bypass missing configuration options: big design risk, we should take the time to add the configuration options instead, those too impatient should fork

The question then is where this knob for configuring where the remote engine listens should exist. If we are going right to what we want the long-term solution to be rather than a temporary escape hatch, then my only immediate idea is to include the provisioning management as part of the CLI since it's something that has to be configured when the engine starts.

I think we should rely primarily on the OCI image being the only official delivery mechanism for the engine. Provisioning by our CLI is potentially useful, but will never be the soure of truth as some (most?) operators will prefer using their existing provisioning tools. If and when we ship provisioning from the Dagger CLI, it can be built on top of the same OCI image and associated configuration knobs.

Let me know if there's other ideas on approaches here. Designing a CLI interface around all that will be a separate issue if we want to pursue it.

I disagree actually. It should always be enabled, and gated by adding a concept of "privileged operation" and "privileged client" to the GraphQL API. Then add an authorization hook to the engine, to let operators decide which clients, if any, have access to the feature. But the feature should always be enabled, without having to tweak static configuration files or ask sysadmins to do it. Otherwise, the Dagger ecosystem will splinter in two parts: the engines with privileged exec enabled, and those with privileged exec disabled. Some pipelines will only run on one of those two subsets of the ecosystem. This is a fundamental breach of our promise of "run any pipeline anywhere" and must be avoided at all cost.

Same as before, I'm all onboard with not exposing this knob via buildkitd config directly and also on board with figuring out the ideal long term approach and doing that right away instead if we are willing to trade time+effort.

👍 yes I completely agree it's a tradeoff, but I believe it's worth it.

The thing that immediately comes to mind is something like k8s w/ RBAC based on mutual tls certs or similar. If we're going that route, it also is probably something that should be configurable at runtime. Maybe the engine should expose an "admin" graphql API for configuring knobs like who's allowed to run a privileged exec, what the GC config is, etc. This would obviously only be served to authorized clients.
That's no small task, but let me know if you agree something in that direction is where we'd want to go in the long run. Then we can start figuring out the path to it (in a separate issue).

For the part with mutual tls certs, I would need more details to form a useful opinion. But generally, yes I think the correct approach here is to individually define the design we want for each feature on the list; then individually decide on implementation stopgaps if any; then ship it. It's more design work up front, but it's worth it.
I'm happy to help any way I can.

Splitting this issue out into separate ones for individual items. In addition to the list in the description, made a few new ones for specific points brought up here:

https://github.com/dagger/dagger/issues/4217
https://github.com/dagger/dagger/issues/4220
https://github.com/dagger/dagger/issues/4215

cc @shykes can continue discussions there


My PsychEngine is bugged

Describe your problem here.
Okay, so after 2 days, I finally figured out how to compile my game, and it runs perfectly. I was able to save my character and it shows up perfectly in character editor, but when I go to test it in freeplay or sum. It won't show

Are you modding a build from source or with Lua?
Source
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
Nothing really, other than adding my .png, and .xml files for the custom character

If you have a folder within the mod folder for a mod and the character data is in there, then you have to either open a song within that mod in freeplay, or press 7 on the main menu, and set the mod directory to your mod and open the chart editor. For custom characters to show up, you MUST be within the same mod directory as the character when using the tools. I call it the mod environment where you have your workspace separated from other mods if you have any. Also, not sure if it matters for visibility, but having a pack.json set up might also help in this situation.

If you have a folder within the mod folder for a mod and the character data is in there, then you have to either open a song within that mod in freeplay, or press 7 on the main menu, and set the mod directory to your mod and open the chart editor. For custom characters to show up, you MUST be within the same mod directory as the character when using the tools. I call it the mod environment where you have your workspace separated from other mods if you have any. Also, not sure if it matters for visibility, but having a pack.json set up might also help in this situation.

Thank you so much, I just needed to press 7 like you said and open chart editor, I was able to see my character then.


implement logprobs=1

This doesn't work - trtllm always returns logprob=0.0; not sure what's up

it looks like it works for tp=4 but not for tp=1; merging for now


Windows Drive Letter prepended when using gvim in cygwin / bash

I use cygwin & bash as my only shell on my Windows PC.
gvim [path/filename] works perfectly to launch gvim from the bash shell.
echo $HOME from the bash shell returns /cygdrive/c/home
cat $HOME/.bashrc works fine
But gvim $HOME/.bashrc prepends "C:" and tries to open: "C:\cygdrive\c\home\.bashrc"
... so I guess gvim is trying to do something clever by automatically prepending the current drive letter to the path when it runs in a Windows environment?
Does anyone know if there is any setting or way to prevent that?

I use cygwin & bash as my only shell on my Windows PC.
gvim [path/filename] works perfectly to launch gvim from the bash shell.
echo $HOME from the bash shell returns /cygdrive/c/home
cat $HOME/.bashrc works fine
But gvim $HOME/.bashrc prepends "C:" and tries to open: "C:\cygdrive\c\home\.bashrc"
... so I guess gvim is trying to do something clever by prepending the current drive letter to the path?
Is there any setting or way to prevent that?

What is 'shellslash' set to?  You could try changing it.
The problem is that normally on windows a patch starting with a slash
(or backslash) is not an absolute path, it is relative to the current
drive.  Cygwin causes terrible confusion by using /cygdrive/c instead of
c:/.  Trying to use Unix paths on an MS-Windows system will always cause
trouble.
It can't really be fixed in Vim, since we cannot predict what the path
is used for.  Given to a Cygwin tool it would work, given to any other
Windows command it will fail.
--
hundred-and-one symptoms of being an internet addict:
96. On Super Bowl Sunday, you followed the score by going to the
Yahoo main page instead of turning on the TV.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I assume you are using the Windows native version of Vim (not the Cygwin version).
Then, you need to convert the Cygwin-style path to the Windows-style path by using the cygpath command.
E.g. gvim "$(cygpath -w $HOME/.bashrc)"

I think we can close this one as a user configuration issue.


May 26 fixes to May 24 paleoearthquake timings files

PALEO_RI_GEOLOGIC_MAY24(
"Geologic timing, no TVZ, Maruia moved, May 24 corrections",
"NZNSHM_paleotimings_GEOLOGIC_24May.txt"),
PALEO_RI_GEODETIC_MAY24(
"Geodetic timing, no TVZ, Maruia moved, May 24 corrections",
"NZNSHM_paleotimings_GEODETIC_24May.txt"),
PALEO_RI_GEODETICGEOLOGICPRIOR_MAY24(
"Geodetic with Geologic Prior timing, no TVZ, Maruia moved, May 24 corrections",
"NZNSHM_paleotimings_GEODETICGEOLOGICPRIOR_24May.txt"),
NZNSHM_paleotimings_GEOLOGIC_24May.txt
NZNSHM_paleotimings_GEODETIC_24May.txt
NZNSHM_paleotimings_GEODETICGEOLOGICPRIOR_24May.txt

done


[?] How to compute an overlap of two labels and combine both label masks into a single label?

FiftyOne has an amazing functionality to find duplicate labels with compute_max_ious() and find_duplicates().
However finding true duplicates only using a thresholding from the IoU metric is not enough.
Let's take the following example:

In cases like this, I would either want to delete the mask with the smaller area (blue), or take a union of two masks.
Both operation would be conditioned by how much the smaller mask overlaps with the bigger one.
So concretely I'd like to know how to:

Calculate the % of the area the smaller mask overlaps with the bigger mask
Take a union of both masks, merging two masks into a single label.
Not related to above, but is there a way to disable bbox preview? I work only with instance segmentation, and bbox occlude the image too much. Can I simply delete the bbox data, leaving only the mask or should I convert the whole dataset from detections to polylines?

ps. another good example, where a simple IoU thresholding would fail. In this example, the IoU is only 0.035, however the blue mask is a clear duplicate

First of all, glad you're finding compute_max_ious() and find_duplicates() useful!
In general, FiftyOne's primary goal is to provide a standardized data representation, not necessarily to have built-in every type of data transformation you might want to apply.
Merging instance masks, for example, has some free parameters. What should the resolution of the output mask be? Should the output instance's bounding box tightly enclose the union of the masks, or should it be the convex hull of the bounding boxes of the input shapes (the two might differ).
FiftyOne does provide some foundational transformations, like methods to convert Label types that you can use to build a transformation to your taste:

Detection.to_polyline()
Detection.to_segmentation()
Segmentation.to_detections()

Here's one possible way to use these methods to merge instance masks:
def merge_instances(detections, frame_size):
    """Returns a single :class:`fiftyone.core.labels.Detection` whose bounding
    box tightly encloses the given list of instance segmentations' masks and
    whose mask is the union of their masks.

    The resolution of the output mask is proportional to the given frame size.

    Args:
        detections: a list of :class:`fiftyone.core.labels.Detections`
        frame_size: the ``(width, height)`` of the image containing the objects

    Returns:
        a :class:`fiftyone.core.labels.Detection`
    """
    width, height = frame_size
    label = detections[0].label

    s = fo.Segmentation(mask=np.zeros((height, width), dtype=bool))
    for d in detections:
        s = d.to_segmentation(mask=s.mask, target=True)

    d = s.to_detections(mask_targets={True: label}, mask_types="stuff")
    return d.detections[0]

Example usage:
import fiftyone as fo
import numpy as np

image_path = "/path/to//image.jpg"

mask = np.zeros((64, 64), dtype=bool)
mask[16:48, 16:48] = True

d1 = fo.Detection(label="object", bounding_box=[0.00, 0.00, 0.75, 0.75], mask=mask)
d2 = fo.Detection(label="object", bounding_box=[0.25, 0.25, 0.75, 0.75], mask=mask)

m = fo.ImageMetadata.build_for(image_path)
d_merged = merge_instances([d1, d2], (m.width, m.height))

sample = fo.Sample(
    filepath=image_path,
    objects=fo.Detections(detections=[d1, d2]),
    merged=fo.Detections(detections=[d_merged]),
)

dataset = fo.Dataset()
dataset.add_sample(sample)

session = fo.launch_app(dataset)

Like I mentioned initially, FiftyOne generally focuses on data representation only, which means that we're not trying to provide a builtin way to compute every possible metric, but we do try to make it as easy as possible to compute your metric from our representation.
In this case, that's why the Detection.to_shapely() and Polyline.to_shapely() methods exist.
Here's a little function that would compute your metric of interest:
import fiftyone as fo

def contains(object1, object2, alpha=0.99, frame_size=None, tolerance=2):
    """Determines whether at least ``alpha%`` of ``object2`` is contained
    within ``object1```.

    Args:
        object1: a :class:`fiftyone.core.labels.Detection` or
            :class:`fiftyone.core.labels.Polyline`
        object2: a :class:`fiftyone.core.labels.Detection` or
            :class:`fiftyone.core.labels.Polyline`
        alpha (0.99): the minimum fraction of ``object2`` that must be
            contained within ``object1``
        frame_size (None): an optional ``(width, height)`` of the frame
            containing the objects. If not specified, all calculations are
            performed directly on normalized coordinates, which implicitly
            assumes the frame is square
        tolerance (2): a tolerance, in pixels, when generating an approximate
            polyline for an instance mask. Typical values are 1-3 pixels

    Returns:
        True or False
    """
    shape1 = _to_shapely(object1, frame_size, tolerance)
    shape2 = _to_shapely(object2, frame_size, tolerance)
    return shape1.intersection(shape2).area / shape2.area >= alpha

def _to_shapely(obj, frame_size, tolerance):
    if isinstance(obj, fo.Detection):
        if obj.mask is not None:
            obj = obj.to_polyline(tolerance=tolerance)

    return obj.to_shapely(frame_size=frame_size)

Example usage:
import numpy as np

mask = np.zeros((64, 64), dtype=bool)
mask[16:48, 16:48] = True

d1 = fo.Detection(label="object", bounding_box=[0.00, 0.00, 0.75, 0.75], mask=mask)
d2 = fo.Detection(label="object", bounding_box=[0.25, 0.25, 0.75, 0.75], mask=mask)

frame_size = (1280, 960)

print(contains(d1, d2, frame_size=frame_size))  # False
print(contains(d1, d1, frame_size=frame_size))  # True

I added compute_max_ious() and find_duplicates() because, in my judgement, they were "common enough" to warrant direction inclusion in the library.
Perhaps we can add an extension or variation of the above methods that allows for passing in a generic function like contains() that you want to apply pairwise to your data.
Feel free to make a PR to introduce such a method if you're so inclined 🤗

no activity, closing


[ go_router ] Nested ShellRoute does not show when pushing new route

Steps to Reproduce

Execute flutter run on the code sample
Tap the buttons to navigate between pages /a and /a/b

Expected results:
There are three different ShellRoutes. The first is red, the second green and the third blue. The first and second should be visible on page /a and /a/b. The third should only be visible on page /a/b.
Actual results:
Both pages /a and /a/b show the same ShellRoute-Containers (red and green). The blue ShellRoute is not visible on page /a/b. I do not understand why that is the case and consider it to be a bug. When I use .go() instead of .push() when switching between the pages, the expected result is showing correctly. But this is not the behavior I want in my app.

Code sample

import 'package:flutter/material.dart';
import 'package:go_router/go_router.dart';

void main() {
  runApp(const MyApp());
}

final GoRouter goRouter = GoRouter(
  routes: [
    ShellRoute(
      builder: (context, state, child) => Scaffold(
        body: Container(
          color: Colors.red,
          child: Padding(
            padding: const EdgeInsets.all(32.0),
            child: child,
          ),
        ),
      ),
      routes: [
        GoRoute(
          path: "/",
          redirect: (context, state) => "/a",
        ),
        ShellRoute(
          builder: (context, state, child) => Container(
            color: Colors.green,
            child: Padding(
              padding: const EdgeInsets.all(32.0),
              child: child,
            ),
          ),
          routes: [
            GoRoute(
              path: "/a",
              builder: (context, state) => const A(),
              routes: [
                ShellRoute(
                  builder: (context, state, child) => Container(
                    color: Colors.blue,
                    child: Padding(
                      padding: const EdgeInsets.all(32.0),
                      child: child,
                    ),
                  ),
                  routes: [
                    GoRoute(
                      path: "b",
                      builder: (context, state) => const B(),
                    ),
                  ],
                ),
              ],
            ),
          ],
        ),
      ],
    ),
  ],
);

class A extends StatelessWidget {
  const A({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Container(
      color: Colors.black45,
      child: Center(
        child: ElevatedButton(
          child: const Text("This is /a. go to /a/b"),
          onPressed: () => GoRouter.of(context).push("/a/b"),
        ),
      ),
    );
  }
}

class B extends StatelessWidget {
  const B({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Container(
      color: Colors.black45,
      child: Center(
        child: ElevatedButton(
          child: const Text("This is /a/b. go to /a"),
          onPressed: () => GoRouter.of(context).push("/a"),
        ),
      ),
    );
  }
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp.router(
      routeInformationProvider: goRouter.routeInformationProvider,
      routerDelegate: goRouter.routerDelegate,
      routeInformationParser: goRouter.routeInformationParser,
    );
  }
}

pubspec.yml
name: go_router_test
description: A new Flutter project.

# The following line prevents the package from being accidentally published to
# pub.dev using `flutter pub publish`. This is preferred for private packages.
publish_to: 'none' # Remove this line if you wish to publish to pub.dev

# The following defines the version and build number for your application.
# A version number is three numbers separated by dots, like 1.2.43
# followed by an optional build number separated by a +.
# Both the version and the builder number may be overridden in flutter
# build by specifying --build-name and --build-number, respectively.
# In Android, build-name is used as versionName while build-number used as versionCode.
# Read more about Android versioning at https://developer.android.com/studio/publish/versioning
# In iOS, build-name is used as CFBundleShortVersionString while build-number is used as CFBundleVersion.
# Read more about iOS versioning at
# https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
# In Windows, build-name is used as the major, minor, and patch parts
# of the product and file versions while build-number is used as the build suffix.
version: 1.0.0+1

environment:
  sdk: '>=2.18.2 <3.0.0'

# Dependencies specify other packages that your package needs in order to work.
# To automatically upgrade your package dependencies to the latest versions
# consider running `flutter pub upgrade --major-versions`. Alternatively,
# dependencies can be manually updated by changing the version numbers below to
# the latest version available on pub.dev. To see which dependencies have newer
# versions available, run `flutter pub outdated`.
dependencies:
  flutter:
    sdk: flutter

  # The following adds the Cupertino Icons font to your application.
  # Use with the CupertinoIcons class for iOS style icons.
  cupertino_icons: ^1.0.2
  go_router: ^5.0.5

dev_dependencies:
  flutter_test:
    sdk: flutter

  # The "flutter_lints" package below contains a set of recommended lints to
  # encourage good coding practices. The lint set provided by the package is
  # activated in the `analysis_options.yaml` file located at the root of your
  # package. See that file for information about deactivating specific lint
  # rules and activating additional ones.
  flutter_lints: ^2.0.0

# For information on the generic Dart part of this file, see the
# following page: https://dart.dev/tools/pub/pubspec

# The following section is specific to Flutter packages.
flutter:

  # The following line ensures that the Material Icons font is
  # included with your application, so that you can use the icons in
  # the material Icons class.
  uses-material-design: true

  # To add assets to your application, add an assets section, like this:
  # assets:
  #   - images/a_dot_burr.jpeg
  #   - images/a_dot_ham.jpeg

  # An image asset can refer to one or more resolution-specific "variants", see
  # https://flutter.dev/assets-and-images/#resolution-aware

  # For details regarding adding assets from package dependencies, see
  # https://flutter.dev/assets-and-images/#from-packages

  # To add custom fonts to your application, add a fonts section here,
  # in this "flutter" section. Each entry in this list should have a
  # "family" key with the font family name, and a "fonts" key with a
  # list giving the asset and other descriptors for the font. For
  # example:
  # fonts:
  #   - family: Schyler
  #     fonts:
  #       - asset: fonts/Schyler-Regular.ttf
  #       - asset: fonts/Schyler-Italic.ttf
  #         style: italic
  #   - family: Trajan Pro
  #     fonts:
  #       - asset: fonts/TrajanPro.ttf
  #       - asset: fonts/TrajanPro_Bold.ttf
  #         weight: 700
  #
  # For details regarding fonts from package dependencies,
  # see https://flutter.dev/custom-fonts/#from-packages

Logs

no relevant errors

No issues found!

[√] Flutter (Channel stable, 3.3.3, on Microsoft Windows [Version 10.0.19044.2006], locale de-DE)
    • Flutter version 3.3.3 on channel stable at C:\src\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 18a827f393 (8 days ago), 2022-09-28 10:03:14 -0700
    • Engine revision 5c984c26eb
    • Dart version 2.18.2
    • DevTools version 2.15.0

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Users\TimBa\AppData\Local\Android\sdk
    • Platform android-33, build-tools 30.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Build Tools 2019 16.11.8)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
    • Visual Studio Build Tools 2019 version 16.11.32002.261
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 4.2)
    • Android Studio at C:\Program Files\Android\Android Studio
    • 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.8+10-b944.6842174)

[√] IntelliJ IDEA Community Edition (version 2020.3)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2020.3.1
    • 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.71.2)
    • VS Code at C:\Users\TimBa\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension can be installed from:
       https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[√] Connected device (4 available)
    • sdk gphone x86 arm (mobile) • emulator-5554 • android-x86    • Android 11 (API 30) (emulator)
    • Windows (desktop)           • windows       • windows-x64    • Microsoft Windows [Version 10.0.19044.2006]
    • Chrome (web)                • chrome        • web-javascript • Google Chrome 105.0.5195.127
    • Edge (web)                  • edge          • web-javascript • Microsoft Edge 106.0.1370.34

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

• No issues found!

Page /a
Page /a/b

Buggy when using .push()

Working correctly when using .go()

Thanks for the report and code sample. Using it, I see same behavior as reported.

 stable, master flutter doctor -v

[✓] Flutter (Channel stable, 3.3.4, on macOS 12.2.1 21D62 darwin-x64, locale
    en-GB)
    • Flutter version 3.3.4 on channel stable at
      /Users/dhs/documents/fluttersdk/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision eb6d86ee27 (2 days ago), 2022-10-04 22:31:45 -0700
    • Engine revision c08d7d5efc
    • Dart version 2.18.2
    • DevTools version 2.15.0

[!] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    ! Flutter recommends a minimum Xcode version of 13.
      Download the latest version or update via the Mac App Store.
    • CocoaPods version 1.11.2

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

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

[✓] Connected device (5 available)
    • SM G975F (mobile)       • RZ8M802WY0X • android-arm64   • Android 11 (API 30)
    • Darshan's iphone (mobile)  • 21150b119064aecc249dfcfe05e259197461ce23 •
      ios            • iOS 14.4.1 18D61
    • iPhone 12 Pro Max (mobile) • A5473606-0213-4FD8-BA16-553433949729     •
      ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-3 (simulator)
    • macOS (desktop)            • macos                                    •
      darwin-x64     • Mac OS X 10.15.4 19E2269 darwin-x64
    • Chrome (web)               • chrome                                   •
      web-javascript • Google Chrome 98.0.4758.80

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

! Doctor found issues in 1 category.

[✓] Flutter (Channel master, 3.5.0-3.0.pre.5, on macOS 12.2.1 21D62 darwin-x64,
    locale en-GB)
    • Flutter version 3.5.0-3.0.pre.5 on channel master at
      /Users/dhs/documents/fluttersdk/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 9ca314afd0 (2 hours ago), 2022-10-06 23:06:11 -0400
    • Engine revision a4174f29a7
    • Dart version 2.19.0 (build 2.19.0-286.0.dev)
    • DevTools version 2.18.0

[!] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    ! Flutter recommends a minimum Xcode version of 13.
      Download the latest version or update via the Mac App Store.
    • CocoaPods version 1.11.2

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

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

[✓] Connected device (5 available)
    • SM G975F (mobile)       • RZ8M802WY0X • android-arm64   • Android 11 (API 30)
    • Darshan's iphone (mobile)  • 21150b119064aecc249dfcfe05e259197461ce23 •
      ios            • iOS 14.4.1 18D61
    • iPhone 12 Pro Max (mobile) • A5473606-0213-4FD8-BA16-553433949729     •
      ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-3 (simulator)
    • macOS (desktop)            • macos                                    •
      darwin-x64     • Mac OS X 10.15.4 19E2269 darwin-x64
    • Chrome (web)               • chrome                                   •
      web-javascript • Google Chrome 98.0.4758.80

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

! Doctor found issues in 1 category.

I think this is a duplicate of https://github.com/flutter/flutter/issues/111842

I am not sure how router should work in case we push /a from /a/b in sample, but looks like this  https://github.com/flutter/flutter/issues/111842#issuecomment-1320913533 fixes not showing blue screen


Add a button to force-update the state

This integration works in principle very well, however my system is connected through a mobile connection and I only have 200 MB/month, which is very common in Italy for IoT subscriptions.
If I set a polling interval of 120 sec or so, to get a decently responsive interface, the the data consumption is way too high. If I set a polling interval compatible with my subscription plan, then the update is way too slow.
My proposal is to introduce a button to force-update the status, so that one can set a long polling interval and then force-update in HA when required through scripts and automations.

I have a question though as you are using a long scan interval: are you impacted by #117 ?

No, I am not.
Thank you for accepting my suggestion!

Hello @Mark-64!
The force-update feature you suggested has been fully implemented, and your feedback is very welcome to see if it works as you expect! Currently, you can either add a button to force the update or use this service in your automations.
Update Your Version
As I still need to test and verify if everything works as expected, I've released this feature as a beta version, so you need to install the beta version. You have two options:

Download and use the version available on this release page: https://github.com/palazzem/ha-econnect-alarm/releases/tag/v2.4.0b1
If you use HACS, just enable the beta channel and you should see the v2.4.0b1 version available (be sure to install b1 and not b0).

Add the Update Button
Once the new version is installed, you can add a button in the Lovelace dashboard as follows:

Add a card of type "button".
In "Entity", select your Alarm Panel.
In "Tap Action", select "Call Service".
In "Service", select "e-Connect/Metronet Alarm: Update Alarm State".
Click "Save".

And then you are done! By clicking that button, you'll force the update regardless of the delay you set. The screenshot below is a configuration example; update it based on your needs:

How Can You Help Further?
Your feedback is important, as I may have missed something you need. Just write here with your feedback, and as soon as everything works as you expect, I'll release a new official version. Let me know when you have time to play with it!

Hello @Mark-64 ! I'm wondering if you had a chance to try 2.4.0b1 version, just to double check if the new feature fits your needs!
I'm planning to release a stable one tomorrow so that I can move forward with the development. Thanks again for your time and feedback!

@Mark-64 As I didn't hear back, I'm moving forward with the version release! Of course, if something doesn't work as you expect, feel free to reopen the ticket and I'll prepare a bugfix release!
I'll update this post as soon as the release is out!

@Mark-64 v2.4.0 has been release! You can find it here: https://github.com/palazzem/ha-econnect-alarm/releases/tag/v2.4.0
If you use HACS, simply update to the latest non-beta version! Keep us posted!


Wiki missing some key points

Hi,
Firstly, I would like to thank you for your hard work that has built this API. I found this API may be very useful in the future, since there's no official API.
But I see your wiki still has many shortcomings, such as the "Integrate with another system" which is still empty. I hope your wiki can be better in the future, because it would be very helpful  ;-)
Please excuse my English,
Thanks in advance  :-)

Hello, I will try to fill the wiki more in the future :-) Thank you for using the system.