feat(trivy): add mirror config in helm chart

Description
This patch adds the trivy mirror configuration to the starboard operator
helm chart. This particular implementation is made to match the
definitions from the documentation and therefore uses two layers for the
object and singular terminology.
The patch is required because currently there is no way than post
deployment patching of the configmap in order to utilise this feature,
which works against the intention of helm. It was also very confusing to
find the documentation providing this option, but the helm chart not
doing so, therefore this patch should help to cleanup potential
confusion.
References:
https://aquasecurity.github.io/starboard/v0.15.4/vulnerability-scanning/trivy/#settings
Checklist

[x] I've read the guidelines for contributing to this repository.
[x] I've added usage information (if the PR introduces new options)

 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.

Thank you @SISheogorath working on this patch!


Units in map when using 3857 projection

Hi, as far as I understand when using the default Extent class the units in the plotted map are the values in the 0-1 range from the conversion from latitude, longitude to x,y  in a unit square.
However, when I use extent.to_project_3857() the units are in the order of 10^3 - 10^4 (as in the example notebook).
What units are those? I thought they were meters but after comparing it with the measurement tool in Google maps, there is an error of about 66%.

It should be conforming to the standard EPSG:3857  It has been some years now since I thought hard about projections, but if I understand e.g. the "well known text" format for 3857, then the units should be meters.
If you can confirm that extent.to_project_3857() is not agreeing with how another tool projects to EPSG:3857 then I will investigate further.

Thanks for your quick reply. I'll detail my case:
I'm working around this location 52.0705818, -9.5490888 (GoogleMaps, OpenStreetMap). As can be seen, there are two buildings and from google maps measurement tool, one has ~100 m side length and the other ~ 60m.

Here below are the plots using both the default extent and the .to_project_3857() option. From the first one, the units are reasonable as they are part of a unit square covering almost the whole earth. But in the second plot, the building with a 60m side, is about 100 units on that scale (from 820 to 920)  and the supposed 100m side is more than 150 units (1062850 to 1063000).

Then, I made a custom projection using a defined UTM zone (29U north in my case) and got the plot below. In this one, the units are closer to the measured values. 60 (-10 to 50) for the left side building and  ~100 (462360 to 462460) for the bottom building.

So, I think this is that EPSG:3857 doesn't do what you expect.  Here's some usage of pyproj which I ran in an IPython session:
  In [1]: import pyproj

  In [2]: p3857 = pyproj.CRS("EPSG:3857")

  In [3]: p4326 = pyproj.CRS("EPSG:4326")

  In [4]: tr = pyproj.Transformer.from_crs(p4326, p3857).transform

  In [5]: tr(52.0701843, -9.5490918)
  Out[5]: (-1063000.0367142241, 6812825.637814251)

  In [6]: tr(52.0704447, -9.5477270)
  Out[6]: (-1062848.1078731895, 6812872.795583437)

  In [7]: point1 = tr(52.0701843, -9.5490918)

  In [8]: point2 = tr(52.0704447, -9.5477270)

  In [9]: ( (point1[0]-point2[0])**2 + (point1[1]-point2[1])**2 ) ** 0.5
  Out[9]:<PHONE_NUMBER>4014333

Here EPSG:4326 is just raw longitude / latitude.  The coordinates I grabbed from OpenStreetMap as the top right and left corners of the building.  End result: the distance between these points is 159 units.

Thanks for the code. I did the same with the coordinates you provided using the projection I used and got 97.93 units (meters)

Also, I found this remark on the EPSG:3857 entry:

Remarks: Uses spherical development of ellipsoidal coordinates. Relative to WGS 84 / World Mercator (CRS code 3395) errors of 0.7 percent in scale and differences in northing of up to 43km in the map (equivalent to 21km on the ground) may arise.

So, if I understood well, the error was expected (~62% in the example coordinates) when using EPSG:3857, but if a more precise scale is needed the approach I used is fine. Am I right on this?
Thanks again for your support.

Your problem is with the 3857 projection.  I think this post explains it very well: GIS Stackexchange.
Closing, as tilemapbase is working as intended.


Naming of Domain Objects

Some points regarding to our domain model which I have noticed.

The naming of ErmengencyType is not expressive enough. My suggestion would be EmergencyPriority.
The same goes with EmergencyAction. My suggestion would be EmergencyStatus. Furthermore I would rename the states into simple past form like ACCEPTED instead of ACCEPT.

I'll take care of this issue


Update mapped to willow mappings

What
Updated the Mapped to Willow mapping file with additional mappings.
Why
Enhanced the mapping, achieving over a 96% coverage of the Mapped ontology.
Tested
Ensured the validity of the DTMI format and confirmed the absence of duplicate InputDtmi entries.

@imercerwillow Thanks for you input on these. I will make changes accordingly

@jbkoh This PR can't be merged until we update our ontology with Brick v1.3


Add relative path for plugin check

Tried it out by playing in ~/.config/yarn/global/node_modules/solidarity/dist/index.js.
Seems to work out.
I first tried to put ~/.config/yarn/global/node_modules, but this did not work (I guess ~ might not be the current user when node runs?)
Tentatively closes #221

Also, tests need to be updated.

@GantMan : I keep getting SecurityError: localStorage is not available for opaque origins when trying to run the tests locally... Any idea on how to fix that?

Not sure on your error, but everything looks good.
For some reason Danger is failing on travis.   I might remove it for now.  Good work bud!  gonna merge.


Replacing rate limiting config params

Updating rate limit config param via PUT gives a message {"name":"already exists with value 'rate-limiting'"}
Steps To Reproduce

Created a rate limit with a consumer id with
Trying to update the limit such that I want to replace the config param from day & sec to only hour
curl -X PUT http://localhost:8001/plugins --data "name=rate-limiting"     --data "consumer_id=37d42cd5-9fd6-4f32-8380-aae94ecb0a29"      --data "config.hour=5"
get the message - {"name":"already exists with value 'rate-limiting'"}

Additional Details & Logs
Rate limit data -
{
"created_at":<PHONE_NUMBER>099,
"config": {
"redis_database": 0,
"policy": "cluster",
"redis_timeout": 2000,
"hide_client_headers": false,
"second": 5,
"day": 10000,
"redis_port": 6379,
"fault_tolerant": true
},
"id": "4ac03d66-2439-4692-82d7-41c09b445813",
"name": "rate-limiting",
"enabled": true,
"consumer_id": "37d42cd5-9fd6-4f32-8380-aae94ecb0a29"
}

Kong version 0.12.3
Operating System - Ubuntu 16

As per the documentation for the relevant Kong version:
https://getkong.org/docs/0.12.x/admin-api/#update-or-add-plugin

"The behavior of PUT endpoints is the following: if the request payload does not contain an entity's primary key (id and name for Plugins), the entity will be created with the given payload. If the request payload does contain an entity's primary key, the payload will "replace" the entity specified by the given primary key. If the primary key is not that of an existing entity, 404 NOT FOUND will be returned"

You need to provide the id argument (that's the id of the plugin, not the consumer), otherwise it assumes you are trying to create a new plugin instance, and then it fails because it already exists.

hello,
Thanks for this info. I am trying to replace all the config params of one particular rate-limiting plugin(in my case, one on a consumer). I understand that PUT is way to do it as supposed to PATCH. The problem with PUT is, PUT with plugin id, as mentioned by you is NOT supported by kong. This is the output I get -
curl -X PUT http://localhost:8001/plugins/0e8b0681-ce86-421f-965b-3d5094661232 \

--data "config.hour=5"
{"message":"Method not allowed"}

Please advice.
Thanks.

Try this:
curl -X PUT http://localhost:8001/plugins/ --data "id=0e8b0681-ce86-421f-965b-3d5094661232" --data "config.hour=5"

curl -X PUT http://localhost:8001/plugins/ --data "id=0e8b0681-ce86-421f-965b-3d5094661232" --data "config.hour=5"
{"name":"name is required"}


remove checkpoint_callback=False to be able to set up checkpointing

Please describe A feature you would like to be added.
It would be nice to be able to set up checkpointing during training which is not possible in the current deepforest version 1.2.0.
I.e. the following code is not possible with the current deepforest which sets checkpoint_callback=False internally.

callback = ModelCheckpoint(dirpath='temp/dir',
                                 monitor='box_recall',
                                 mode="max",
                                 save_top_k=3,
                                 filename="box_recall-{epoch:02d}-{box_recall:.2f}")
model.create_trainer(logger=TensorBoardLogger(save_dir='logdir/'),
                                  callbacks=[callback])
model.trainer.fit(model)

Describe the solution you'd like
remove hard coded checkpoint_callback=False
Describe alternatives you've considered
Additional context
$ conda list | grep torch
pytorch                   1.10.1          py3.9_cuda10.2_cudnn7_0    pytorch
pytorch-lightning         1.5.8              pyhd8ed1ab_0    conda-forge
pytorch-mutex             1.0                        cuda    pytorch
torchaudio                0.10.1               py39_cu102    pytorch
torchmetrics              0.6.2              pyhd8ed1ab_0    conda-forge
torchvision               0.11.2               py39_cu102    pytorch

Thanks for the issue, I agree that this functionality needs to be improved. I think checkpoint callback was deprecated.
https://pytorch-lightning.readthedocs.io/en/stable/common/trainer.html#checkpoint-callback

On second look, it looks like this use case is built in, passing the checkpoint should override
```
enable_checkpointing = False
```
within the trainer. I think the real issue is that we've got
checkpoint_callback = False

when we want
enable_checkpointing = False

I'll make a quick PR.

Looks like this a recent API change
Exception: TypeError: __init__() got an unexpected keyword argument 'enable_checkpointing'

I had pytorch-lightning 1.4.1 locally. We made need to pin a version. Hard when these API keep changing.

pip install pytorch-lightning --upgrade
Successfully installed pytorch-lightning-1.5.9 setuptools-59.5.0

works.


Java 8 required for HTTP/2?

I'll stop short of asserting it won't work for anybody, but I was unable to get Netty's HTTP/2 implementation to work with Java 7. In particular, the problem seems to be that the ciphers specified in Http2SecurityUtil aren't available in Java 7, which leads to exceptions that look like this:
Nov 28, 2015 4:47:12 PM io.netty.handler.ssl.ApplicationProtocolNegotiationHandler handshakeFailure
WARNING: [id: 0x549ce599, /<IP_ADDRESS>:63577 => /<IP_ADDRESS>:8443] TLS handshake failed:
javax.net.ssl.SSLHandshakeException: No appropriate protocol
	at sun.security.ssl.Handshaker.activate(Handshaker.java:449)
	at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:708)
	at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:806)
	at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:758)
	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
	at io.netty.handler.ssl.JdkSslEngine.unwrap(JdkSslEngine.java:82)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1138)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1028)
	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:968)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244)
	at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
	at io.netty.channel.DefaultChannelHandlerInvoker.invokeChannelRead(DefaultChannelHandlerInvoker.java:163)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:155)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:950)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:510)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:467)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:381)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)
	at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
	at java.lang.Thread.run(Thread.java:745)

This happened when running the HTTP/2 "hello world" example with Oracle's JDK 1.7.0_60 under OS X 10.11 (15A284). When I switched to Java 8 (and the matching version of alpn-boot), everything worked as expected.
I don't think this is a bad thing, per se, but the README says:

You require the following to build Netty:

Latest stable Oracle JDK 7
...

Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.

Looks like some extra caveats may be needed in the system requirements.

@jchambers - HTTP/2 requires ciphers that are not included in Java 7. This is not a "netty" thing, so much a a Java thing. If you use native ssl in your service, then you can use netty's HTTP/2 codec with Java 7.

Right. Totally understood. I'm not saying it's a defect, but I am saying it might make things easier for newcomers if it were documented somewhere (since it's a non-obvious exception to the "core" system requirements). Your point about using native SSL and Java 7 seems worthy of mention, too!

I agree with you.  I think the documentation could do with some updates and general improvements.  It would be good to see codec specific documentation, such as an (HTTP/1.x || WebSocket || HTTP/2 || STOMP) section outlining the requirements, examples, and optional goodies (compression for example).
The documentation section is all available on GitHub, so I'm sure Norman and Trustin would appreciate any PRs you'd be willing to provide.

Yeah, we should probably expand the docs in the readme. Perhaps we should even break out details of using TLS (as we did for grpc: https://github.com/grpc/grpc-java/blob/master/SECURITY.md).
@normanmaurer @Scottmitch WDYT?

Perhaps we should even break out details of using TLS into a separate doc

That sounds like a good idea to me. Since I'm writing a thing that uses HTTP/2, it'd be great to have somewhere to point end users that explains both the broader requirements (HTTP/2 requires ALPN and some ciphers that aren't in Java 7) and the specifics of addressing those requirements with Netty (including native SSL).
Relatedly, I'll update the summary of this issue to be less about Java 8 and more about system requirements for HTTP/2.

Sounds good

Am 30.11.2015 um 15:41 schrieb Nathan Mittler<EMAIL_ADDRESS>Yeah, we should probably expand the docs in the readme. Perhaps we should even break out details of using TLS (as we did for grpc: https://github.com/grpc/grpc-java/blob/master/SECURITY.md).
@normanmaurer @Scottmitch WDYT?
—
Reply to this email directly or view it on GitHub.

+1 for better docs.
@nmittler - The link you provided looks like a great start! I wonder if we could "borrow" the non-gRPC specific stuff. Either promote it to Netty somewhere and link from it from gRPC, or just duplicate it for now. WDYT?

@Scottmitch I'm fine with duplicating for now ... we can refactor the grpc docs later.

+1

Am 04.12.2015 um 14:55 schrieb Nathan Mittler<EMAIL_ADDRESS>@Scottmitch I'm fine with duplicating for now ... we can refactor the grpc docs later.
—
Reply to this email directly or view it on GitHub.

I'll submit a PR.

Thx!

Am 04.12.2015 um 18:56 schrieb Scott Mitchell<EMAIL_ADDRESS>I'll submit a PR.
—
Reply to this email directly or view it on GitHub.

@jchambers - Check out https://github.com/netty/netty/wiki/Requirements-for-4.x

Thank you! Sorry I wasn't able to devote attention to this in a timely manner, but I look forward to contributing to the wiki soon.


Dist files TypeError: i is undefined

When i copy latest dist files there is TypeError: i is undefined in console
https://codepen.io/danijelGombac/pen/OoJjXa

You're missing the dependencies for our JS—jQuery and Popper.js.


HIVE-27969: Add verbose logging for schema initialisation and metastore service in docker container

What changes were proposed in this pull request?

Add option to enable verbose logging for schematool and metastore service inside docker container
Why are the changes needed?

Improved logging
Does this PR introduce any user-facing change?

Add option to enable verbose logging
Is the change a dependency upgrade?

No
How was this patch tested?

Local docker build and run for the mentioned services

@dengzhhu653 @aturoczy @kokila-19 Thanks for the review.
@dengzhhu653 can you please merge this.


Support structured error messages

Currently Flutter error messages are at the core large blobs of text with limited structure which has been often slows users down fixing errors as it is hard to distinguish the signal from the noise and so users get lost in long non interactive stack traces and distinguishing what parts of the error is the core problem that occurred, background information, or hints on how to fix the problem.
We would like to add structure to error messages making the errors practical to format beautifully on the client. The goal is to have enough structure that users can quickly scan the message to see hints for how to solve the problem, the core error message, links to interactive ui to fix the ui, and interactive links to open objects related to the error in the Inspector. Similarly, errors will start with the minimum useful information to show expanded with ui affordances to expand out to see additional information such as extra stack frames and additional parent widgets.
Basic examples of what we could do with added structure:
Note in this example, the widget names are clickable navigating the user to the matching location in the widget tree. Lists of ancestors and stack frames stack out truncated and only expand when a user clicks. Portions of the error that are hints are shown with a different background color and additional padding. The core error message is in red so it is harder to miss.

Example for an error on the rendering layer. In this case the RenderObject is similarly clickable to navigate over to the inspector to view.

Example of a ui mock of a more advanced error message that really lets the user understand a layout issue without switching contexts. Note the links to interactive UI elements to apply fixes, graphical visualization of the overflow failure that occurred, and header titles calling out core elements of the error. All of these ui features are speculative and may or may not prove out with user studies but they are features are are promising enough that we would like to iterate on them without churning through refactoring code in package:flutter for every UI iteration.

Prototype CL showing what it would take to add structure to all flutter errors at the cost of
more structured  syntax writing error messages than writing unstructured blob of text.
https://github.com/flutter/flutter/pull/27202
If nothing else this CL provides a good overview of what blocks of content exist in the existing error messages.
Some observations: there are common tasks like embedding a structured object for a RenderObject that are called 20 times across the code base. Currently the same boilerplate code to emit strings describing a widget and its immediate children is repeated for each of these cases. If you look at FlutterErrorBuilder, WidgetErrorBuilder, and RenderErrorBuilder you will see the full list of all commonly occurring patterns of structured data that is included in errors (StackTrace, RenderObject, Widget, ancestor chain of widget) and error parts (e.g. hint, error, constraint).
The core concern about this prototype CL is that the builder syntax used is not productive enough for users to use and will reduce the number or quality of errors. A counter point is that it took about 2 days to refactor all errors in package:flutter to use the format. For someone who wants to write an error message particularly in the simpler case an alternate approach is to add named arguments provided on the default FlutterError constructor but unfortunately once you exceed the capabilities of that constructor you will have to start using builder syntax. Builder syntax is needed to handle multiple messages of the same type such as multiple hints. Looking at the facts on the ground there are multiple flutter errors with multiple separate hints.
Benefits are it is hard for users to do the wrong thing and there are builder classes that clarify what helper methods should be used depending on the context the error is being thrown in (base, Render, or Widget).
The structure of the error messages is the same DiagnosticsNode format used by the WidgetInspector making it reasonable to include errors directly in the widget tree as properties of a widget indicating where the problem occurred.
Risks:
The builder syntax may be unwieldy and demotivate framework authors and users from writing good structured errors.
Alternate design:
Markdown lite for Flutter errors.
Add magic characters in the error templates that indicate error parts (e.g. hint, error, contract).
Risks:
Markdown like templates may be fragile and error prone as users will get extremely limited compile time checking that they are using the scheme in contrast to the other design where you will get an immediate compile time error if you attempt to pass the wrong type of object to a builder method.
Similarly, opening and closing blocks in this case will be done with some level of tags embedded as magic unicode characters so mismatched tags will cause the usual problems. This can be mitigated with careful test coverage although the current code base shows that there is limited coverage of errors.
Breaking change:
This change will modify the toString for all objects implementing Diagnosticable. As Diagnosticable objects have great toString functions, there tend to be a lot of tests that use them to easily write golden tests. Currently modifying the toString for Diagnosticable breaks 19 tests in package:flutter and would break third party tests as well. Modifying the equalsIgnoreHashCodes matcher to ignore the temporary object ids embedded in the toString as well would help somewhat but still leads to 16 tests failing. This is because not all tests using the equalsIgnoringHashCodes matcher as it wouldn't make sense for them to as the golden output did not contain hash codes and because adding the magic unicode character impacts line breaking for multiple diagnostics output so even though equalsIgnoreHashCodes is used. Fixing the line breaking helper used reduces the number of test failures in package:flutter to 13.  The failures would be easy enough to fix by switching to a matcher that ignores the magic characters but users would need to know such a matcher exists and use it. Otherwise the tests will become mysteriously flaking as the object ids in the matchers would change unpredictably.
This breaks anyone who linebreaks debug output and doesn't know about the magic characters. Lines will be broken incorrectly resulting in shorter lines than otherwise. The common debugWrap helper can be updated to reflect the magic characters to mitigate this risk. With debugWrap modified to ignore magic characters the # of failing tests in package:flutter is reduced to
People with golden tests should expect to have to rebaseline them periodically so perhaps this isn't that big a deal.
Alternatives to minimize the breaking:
Make the magic unicode characters be off by default in tests. This will mean that debuggers depending on them will be broken for tests and tests testing debug output are testing the wrong thing but would minimize the breakage.
Example failing test:
    expect(description, <String>[
      'backgroundColor: Color(0xff123456)',
      'elevation: 8.0',
      'titleTextStyle: TextStyle(inherit: true, color: Color(0xffffffff))',
      'contentTextStyle: TextStyle(inherit: true, color: Color(0xff000000))',
    ]);

now the toString for each TextStyle contains at least one marker character.
Fixing debugWrap to account for the magic characters still leaves  13 failures.
Unsolved challenges:
Object lifecycles using this scheme are fragile as Dart string templating is quite limited so we have no efficient way of distinguishing a toString call part of a template that will be used for an error from a time someone is just calling toString arbitrarily on an object. This suggests the only feasible approach to avoid memory leaks is to have only a ring buffer of object references.
This can work alright as long as care is taken to quickly deserialize the object references out of the format when capturing them for display at a later point either in a logging view or in an interactive view on the device or in the inspector such as a FlutterError widget.

It is my dear hope that the current number of asserts and exceptions with strings pales in comparison to the future number of asserts and exceptions with strings. What matters isn't the current messages, but the future ones.
It's currently too hard to create error messages (we know this, because otherwise we'd have many more). That's why I'm so eager to make sure that whatever solution we have here is super simple. Ideally, even simple than what we have now, though I can't for the life of me imagine how we could do that.
The problem isn't verbosity, it's what you need to know in order to write a useful error message. Today you need to know:

About assert or throw.
How to write a string.
What the cause of the error might be.
How to resolve it.
How to teach someone how to resolve it.

This, it turns out, is already a really high bar. I am very skeptical of adding to that list.
(I'm also a bit dubious of trying to fit error messages into a mold. Gradle does this, and the result is pretty much uniformly terrible -- every error message has way too much text and often ends up being so confusing that it would have been simple if it just said "Error" and left it at that.)

Maybe we should take a step back, though. We're arguing over solutions here, but I feel that I don't yet fully understand the problem space.
What is our goal? The original comment says:

The goal is to have enough structure that users can quickly scan the message to see hints for how to solve the problem, the core error message, links to interactive ui to fix the ui, and interactive links to open objects related to the error in the Inspector. Similarly, errors will start with the minimum useful information to show expanded with ui affordances to expand out to see additional information such as extra stack frames and additional parent widgets.

What our studies have shown is that at the core of it, merely adding blank lines between paragraphs is the best improvement we have tested. (It scored better than adding colour in some cases, and about the same in others. cc @InMatrix) Do we really need that much structure to allow users to scan the message? Aren't paragraph breaks all we actually need? (We have those already.) (These aren't rhetorical questions. It would be good to see concrete comparisons of error messages as they are today, as they would be with some trivial post-processing to create clear paragraph separation, and as they would be with elaborate styling as proposed earlier.)
We already have enough structure to detect the stack traces (we already detect them to avoid line-wrapping them), so we could collapse those if we wanted to.
This leaves the interactive links part. I agree that it would be nice to be able to jump from an error message to the tree view to see the context. It would also be good to be able to do that from random print statements when doing print debugging, which is common. A solution that works both for print and for exceptions (which also end up going through print), and maybe for other things like error messages in FlutterError, seems like it would be more valuable than one that requires special code in exception throwing logic. Can we find a more general solution to this?
Is there anything else we want to do?

We definitely shouldn't flip a coin. We should work together to find something we're all actually happy with.

I'm working on an option 3 that I hope we can all actually be happy with which I'll send out more details on later today. I've verifying it hangs together now but the concept is to use named arguments to cover >=90% hopefully >= 95 of the error messages with a complex error message with a solution that doesn't leave API cliffs and provides some promising ways to move forward for improving the 5000 asserts that even have a short text error message and shouldn't have one.

When it comes to reading code I find the Builder pattern pretty nice. It makes it immediately clear to me as the reader what part of the error the author considered as e.g. the solution to a problem. The Builder pattern is familiar to most readers, so they know what to expect. When reading the code with the markdown tags, those tags felt like distracting noise. Forgetting the discussion here, it was not immediately clear to me what their purpose is (I feel like in an IDE I'd have to click through to read the documentation on why somebody included ${FlutterError.hint} in an exception string), which results in an annoying context switch. The Builder pattern did not require me to switch context away from the actual exception in the code.
Again, the above is about reading code with the two patterns in use. Now when it comes to writing exceptions both patterns scare me a little. This may be my english-as-a-second-language talking - but I have no idea what the difference of a "claim" or a "ground" in an exception is supposed to be (to just name two). With both APIs I feel like I need to consult a dictionary to work out the semantics difference to provide good error messages (or look at lots of other examples to extract the differences from them). I can totally see how instead of doing that developers (not excluding me) get lazy and fall back to providing less then optimal error messages. I am not sure how to overcome this problem.
Having said that, the ultimate goal to make exceptions more accessible and actionable is of course a great cause!

Option 3 looks really nice to me.

Lets start with 4 categories of levels for the initial version as we can always add more later as needed.  error, hint, fix, and summary/description. I don't have an opinion about the names and defer to whatever is most familiar to the team.

I agree. I'd recommend the following names. I also described rationale for identifying each category.
Category "summary:"

It's a short description of the error. It's also the default category when the error author just wants to build a string and ignores the rest of categories. That said, we can probably provide a lint to encourage the author to move details to the "description" category when the length of the summary exceeds a threshold. I prefer the name "summary" since "error" feels redundant in the context of writing an error message.
Why is this category useful? It supports two kinds of user journeys:

The user has fixed a similar error before, and all she needs is to recognize the error. "What? That error again?! I know how to fix it."
The user doesn't have the patience to really study the error. He copies the summary line and search it on Google.

Category "description:"

This is the second category. Any further detail about the error can go here. This is the place where we'd encourage the author to include grounds, claim, and warranty as useful elements for making a clear explanation. This won't be enforced by code though. If the author doesn't want to further break down his error, even hints can go here. It just loses the opportunity to be highlighted separately in the IDE.
This category is important when the best way to resolve the error is to fully understand it.

Categories "hint" and "fix:"

Hint is a suggested path to resolving the error. It's usually context dependent and requires the user to understand her code and the error to reach a resolution. The error author is moderately confident that the hint is going to be useful.
In contrast, a "fix" is a set of specific instructions which the error author has high confidence of for resolving the error. The bar for marking an advice as a "fix" is that it should have the potential to be transformed into an automated "click and fix" script.

Looking at https://github.com/flutter/flutter/compare/master...jacob314:structured_error_ac I agree that this is definitely an improvement. I think I would push for even further simplification, but I need to study the patch in more detail to give a more informed opinion.

Note that master...jacob314:structured_error_ac only shows a fraction of the errors refactored with the simpler helper methods.
I expect at least 90% of the errors listed can be refactored to use the simpler syntax while keeping the number of named parameters from getting out of control.
A possible refinement I'd like your opinion on is separating the part of describeError that indicates how the context should be displayed from the part describing what error occurred because all errors regardless of the context they occurred on have the same needs for describing the error but the code to describe the context is completely custom to the context the error occurred.
A prototype for doing this is adding a simple ErrorMessage class that is used by all defineError methods. The goal is it separates out the part of the errorDescription that is independent of the context the error occurred from the part that is describing the context the error occurred.  This would reduce the duplicated logic between the various describeError messages with the downside of making the calls to describeError a little more verbose. The benefit is it is a clear separation of which part of the call to describeError is the part describing the error that occurred and which part is explaining the context the error occurred in.
A possible refinement is to in the future rewrite cases a raw ErrorMessage is thrown to inject the call to describeError on the context that appears most appropriate based on types in scope. This is analogous to the case described previously of rewriting asserts with zero arguments to inject an call to describeError passing in the expression being asserted.
Example:

Example usage:
Old:
   context.describeError(
      'No MediaQuery widget found.',
      description: '${context.widget.runtimeType} widgets require a MediaQuery widget ancestor.',
      contextName: 'The specific widget that could not find a MediaQuery ancestor was',
      describeOwnershipChain: true,
      hint:
        'Typically, the MediaQuery widget is introduced by the MaterialApp or '
        'WidgetsApp widget at the top of your application widget tree.',
    ),

New:
   context.describeError(
      ErrorMessage(
        'No MediaQuery widget found.',
        description: '${context.widget.runtimeType} widgets require a MediaQuery widget ancestor.',
        hint:
          'Typically, the MediaQuery widget is introduced by the MaterialApp or '
          'WidgetsApp widget at the top of your application widget tree.',
      ),
      contextName: 'The specific widget that could not find a MediaQuery ancestor was',
      describeOwnershipChain: true,
    ),

class ErrorDescription {
  final String summary;
  final String description;
  final Object descriptionObject;
  final List<String> hints;
  // Provide one or more convenient constructors for defining ErrorDescription objects.
}

class BuildContext {
  FlutterError describeError(
    ErrorDescription errorDescription, {
    // These 4 parameters are the configuration of how this BuildContext should be
    // converted into a useful description given this metadata about what parts of
    // the BuildContext are critical to the user.
    @required String contextName,
    String renderObjectName,
    bool describeOwnershipChain = false,
    Type expectedAncestorType,
  });

For example, by errorContext I mean the part of the error that is derived from a specific BuildContext and some flags indicating what parts of the BuildContext are relevant while errorMessage is the
The errorContext is the part of the

It's hard for me to evaluate this because I'm lacking context. Let me try to understand your branch and get back to you.

Ok, I've studied this PR in detail now.
I think we should scale back what we are doing here. For example, I think we should avoid having "fix" until we have an actual good fix (none of the cases I found in the PR are what I would consider any more than hints). I think we should combine "hint" and "description", and as noted above, we should drop contract and violation.
I think it's unfortunate that this PR doesn't make it possible to click on values that are embedded inside strings, e.g. the enum value in violation: 'Instead, this element is in the $_debugLifecycleState state.' or the variables in:
            ..addViolation('Curves must map 0.0 to near zero and 1.0 to near one but '
            '${activeCurve.runtimeType} mapped $t to $transformedValue, which '
            'is near $roundedTransformedValue.')

It works around this for some values by having dedicated methods that assign a single label to a single value, as in:
            ..addDebugProperty('Active curve', activeCurve)

I think that we shouldn't do a workaround here. We should find a solution to expose values that are interpolated in general, and then that solution would apply to all the work we're doing here with errors. (It would also fix a large class of other problems, like inspecting things that are passed to print, or inspecting things that are interpolated into strings, etc. I can imagine various ways to do this using VM support in debug builds.) I think it'd be fine to address that problem in a separate PR; it would help keep the scope of this PR down.
I think we could do a lot to make the API simpler over all. For example, removing the "describeError" methods would actually simplify matters. They are intended as convenience methods, but they have a very large API (11 arguments in one case), and they mostly just call straight through to underlying APIs that aren't much worse. Similarly, we could remove features like addHints (just call addHint several times).
If we remove the convenience methods, remove all the types of strings except "hint", and remove the features that merely add objects in various forms (e.g. addProperty, addIterable, etc). Then we're actually left with an API that's much simpler. FlutterErrorBuilder for example ends up having only two methods, addHint and addError. At that point, we hardly even need a builder. We could just put it all on FlutterError. For example, we could have it take an array of objects:
  FlutterError(<FlutterErrorParts>[
    ErrorMessage('Invalid curve endpoint at $t.'),
    ErrorHint('Curves must map 0.0 to near zero and 1.0 to near one but '
              '${activeCurve.runtimeType} mapped $t to $transformedValue, which '
              'is near $roundedTransformedValue.'
    ),
  ]);

We could make this integrate more tightly with the diagnostics logic, which presumably would help with the transferring of data to the IDE, by making FlutterErrorParts actually be DiagnosticsNodes:
  FlutterError(<DiagnosticsNode>[
    ErrorMessage('Invalid curve endpoint at $t.'),
    ErrorHint('Curves must map 0.0 to near zero and 1.0 to near one but '
              '${activeCurve.runtimeType} mapped $t to $transformedValue, which '
              'is near $roundedTransformedValue.'
    ),
  ]);

This even gives us a free way to include inspectable objects into the error description before we do the real fix as mentioned above:
  FlutterError(<DiagnosticsNode>[
    ErrorMessage('Invalid curve endpoint at $t.'),
    ErrorHint('Curves must map 0.0 to near zero and 1.0 to near one but '
              '${activeCurve.runtimeType} mapped $t to $transformedValue, which '
              'is near $roundedTransformedValue.'
    ),
    DiagnosticsProperty<Curve>('Active curve', activeCurve),
  ]);

"Free" in the sense that there's no additional API surface needed to support this, so it doesn't leave us with vestigial API surface when we eventually fix the problem for real at the VM level.

Merging hint and fix is reasonable.
Having just summary, description, and hint to start works. We can revisit fix once we have some true fixes in the future.
If Dart string interpolation was a more powerful feature with features to capture a templated string as something other than just a String I would fully support extracting object references like this but the feature is crippled and so we would have to make breaking changes to toString to make things work and then only for a fraction of objects. For example, Curve isn't currently Diagnosticable although it is on my list to change that. A reasonable middle ground would be to use a kernel transformer to extract object references from string interpolation expressions used for very specific APIs. However, any case where this is useful, the real answer is generally that we should also be calling out the properties with nice tool usable names because most of the visualizations of objects like Curve don't really work that well unless they can be on their own line.
Your example illustrates exactly why in this case breaking out the activeCurve value as a separate property with a good name "Active Curve" vs "activeCurve" is useful. I know how to write a great visualizer for Curve objects that displays what the curve is but making a visualization that will look good in the middle of a line of text is much harder. You could of course only make the value show up on hover of text but sadly few users will take advantage of that compared to actually showing the value by default.
For example (ignore the fact that "Active Curve" is not aligned well:

Curves must map 0.0 to near zero and 1.0 to near one but Curves.easeIn mapped X to Y, which is near Z.
Active Curve:

is great but

Curves must map 0.0 to near zero and 1.0 to near one but  mapped to X to Y, which is near Z.

Is a poor user experience.
For inspectable objects, the interactive displays of them tend to
Dart's string interpolation is not robust enough to be a good fit for automatically embedding

How about:

Curves must map 0.0 to near zero and 1.0 to near one but Curves.easeIn (shown below) mapped 0.0 to 0.6, which is near 1.0.
Curves.easeIn:

Each of the links except "shown below" is a link to the debugger to show the variable that was substituted in. "shown below" scrolls to the visualization.

(In any case, the last part of my last comment supports including the curve as well, with no new APIs.)

FlutterErrorBuilder for example ends up having only two methods, addHint and addError.

Dropping "description" will really limit the IDE's ability to direct the user's attention to the most important piece of information in those error messages with substantially more detail than the invalid curve error mentioned above. In addition, we also need to consider the situation where the user knows how to solve the error as soon as they recognize it. We don't want to make the user read more than necessary in this case.
That said, losing the distinction between an error summary and more detail about the error can potentially be remedied by enforcing a writing convention. For example, if we require error authors to include a headline in the beginning of each error and add a blank line below it, then this is less a problem. The IDE can even infer the headline from this convention and style it differently. But it puts burden on code reviewers to remember this guideline and ask people to do it.
Another related factor is that we currently plan to use some part of the error summary as an error's ID for analytics purpose, assuming that error summary is more stable than other details. We might need to revisit that plan if we can't keep the distinction.

@InMatrix In my proposal we keep the summary and the hint. I can't tell from your comment if you are saying we need those two categories, or if we need three categories. Can you elaborate?

I think we need three categories. In addition, I suggest revising their names to hopefully make the distinctions clearer. These three categories could be called summary, detail (previously called description), and resolution (previously hint). Among these three categories, a summary is always required for an error message, while the other two are optional.
Let's consider the possible effects of dropping the detail category in the following example:

I divided the above message into five parts. Here is how I'd categorize them:

Summary: Part 2
Detail: Part 1, 3 and 5
Resolution: Part 2

If we drop the category detail, what category would we assign Part 1, 3 and 5 to?
One possibility is to merge them with summary, but then we'll have a giant summary, which defeats its purpose. What's worse is that the actual summary (Part 2) will be buried in the middle of the message with little visual cues to make it stand out.
Alternatively, we could merge Part 1, 3 and 5 with resolution. But the content is hardly suggesting how to get out of this error state. The user is likely to stop reading before they reach the actual resolution (Part 4).

How about:
Curves must map 0.0 to near zero and 1.0 to near one but Curves.easeIn (shown below) mapped 0.0 to 0.6, which is near 1.0.
Curves.easeIn:

Each of the links except "shown below" is a link to the debugger to show the variable that was substituted in. "shown below" scrolls to the visualization.

That seems like a reasonable option for objects with a a good image representation and a short toString although I'm not sure it as clear as calling out explicitly what the Active curve looks like. However, there is benefit to supporting both and we can add a kernel transformer that will in the future make this case work, although not as well as actually describing what the properties are. I will file a separate bug describing the kernel transformer and associated lint that will let us do that in a robust way as long as we restrict it to just string interpolation templates.
We'd need to be careful that we only display the output like that for cases where the debugger view of the object is significantly different from the toString. For example:
'${context.widget.runtimeType} widgets require a Table widget ancestor.'

TableRowInkWell widgets require a Table widget ancestor.
TableRowInkWell: <TableRowInkWell Type object debugger ref>

would provide a bad user experience.

@InMatrix Those three suggested categories sound good to me and seem easy to distinguish.
However, in your example I'd be curious how to apply them. Would we want to mark part 2 both as summary and resolution?

@goderbauer Part 2 is the summary of the error. In some cases, the summary implies a resolution, and in those cases it might be Okay that the author doesn't include a resolution explicitly. In the missing material error example, Part 2 might be implying a resolution to more experienced developers who already know different kinds of Material widgets and the meaning of "ancestors" in Flutter. However, less experienced developers might well need the more explicit guidance in Part 4.

Lets address the details of what cases can and cannot be well expressed with ad-hoc string interpolation vs name-value pairs in a separate issue. I think we are generally on the same page that ad-hoc string interpolation is a great thing to support with a kernel transformer. I was just trying to set practical expectations of how fragile some of the edge cases for it will be and when we will need to encourage users to use the more typical property-value display more common for debugging tools enumerating names and values. I will file a separate bug detailing how the kernel transformer + lint approach would be integrated and lets discuss the various cases there in more detail. I agree that color, icons and a few other cases are clear wins for inline display.
Doubling back to the proposal of
  FlutterError(<DiagnosticsNode>[
    ErrorMessage('Invalid curve endpoint at $t.'),
    ErrorHint('Curves must map 0.0 to near zero and 1.0 to near one but '
              '${activeCurve.runtimeType} mapped $t to $transformedValue, which '
              'is near $roundedTransformedValue.'
    ),
    DiagnosticsProperty<Curve>('Active curve', activeCurve),
  ]);

that would be a breaking change as FlutterError currently takes a String as a parameter. Are you ok with that breaking change or would it need to be a separate named constructor? Making the api just take a list of DiagnosticsNode objects is fine with me and I'm happy to just run with implementing it that way.
The new list comprehension features landing do make writing APIs with that structure more convenient.
One question for you, how would you like to see that we avoid having users add a Widget to the error description when an Element is available? Adding the element is typically preferable as there is a 1-1 mapping of an element to a location in the inspector tree. On the other hand, it is less reliable to go from a Widget to a location in the Element tree as the widget may exist multiple times in the tree. The describeError api is intended to guide users down that path. Otherwise a developer that is used to only thinking in terms of the string output would assume a Widget is an equally fine object to include in the output.

Parts 3 and 4 are an explanation of what the error is, relevant background, etc.
I understand how to distinguish those four concepts. What I don't understand is how to distinguish parts 3 and 4.

Part 3 is explaining what's going on in the program, while Part 4 is talking about the programmer and their potential actions. In addition, two features make Part 4 distinctly different from Part 3. First, it's led by a goal statement: "To introduce a Material Widget..." Second, it talks from the second-person point of view, which is marked by the use of second-person pronoun: "you can either directly include one..."

Looking at the data, the FlutterError class constructor is barely used outside of Package flutter so I actually think we could go with the breaking change of making the one FlutterError constructor take a list of DiagnosticsNode objects without causing much pain at all.
I think having FlutterError take a list of DiagnosticsNode objects leaves us with a core API that we will never have to change and can meet all our use cases going forward as DiagnosticsNode objects can support arbitrary structure.
I will push on https://github.com/flutter/flutter/issues/27673
to support nice inline display of objects without having to resort to the more cumbersome DiagnosticsProperty syntax unless a truly custom display of a property is really desired.
I'll start working on a branch summarizing just the changes we have consensus on to make sure we are on the same page.

I've filed https://github.com/flutter/flutter/issues/27695 to track the related issue of barely used FlutterErrorDetails subclasses that could be eliminated or at least deprecated as part of simplifying to a standard way to expose metadata.

Here's a branch summarizing the changes we have consensus on and changes i'd like to get consensus on next so I can start the real refactor avoiding doing throwaway work.
https://github.com/flutter/flutter/pull/27791/files

Are you ok with that breaking change or would it need to be a separate named constructor?

It's probably ok... Hard to tell how often people use it. Please make sure to go through the breaking change process: https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
(In particular, part of that process is asking the community for feedback on whether they think this will break them.)

how would you like to see that we avoid having users add a Widget to the error description when an Element is available?

We should just put that in the style guide and make sure reviewers are aware of it. Maybe we can add a lint or something.

Part 3 is explaining what's going on in the program, while Part 4 is talking about the programmer and their potential actions.

The following two statements seem identical to me, but one sounds like it is "explaining what's going on in the program" while the other seems to be "talking about the programmer and their potential actions":
The foo constructor requires a bar.
When calling the foo constructor, provide a bar.
These statements are in my mind identical in meaning. It seems very strange to me that depending on the mood of the person writing the error message, we might sometimes have something be described as a "detail" and sometimes as a "resolution".

I understand it's a separate concern that error authors might not see the distinction. It's Okay that some authors don't initially take advantage of the "hint" category. We or other contributors could easily call out the "hint" part later, as long as there is a way to do so via the API.

As the person who's probably written most of the error messages we're talking about, not to mention the person who's reviewed the PRs for most of the rest, I care very much that I should understand how to write error messages. I don't understand the distinction described here. As in, I wouldn't be able either write or review code that was required to distinguish between "description" and "hint".

The foo constructor requires a bar.
When calling the foo constructor, provide a bar.

These two statements are not really identical to me. While the second version tells me what I need to do to get out of the error state, it doesn't tell me the definitive cause of the error. If I were to complete the second version with a cause, I could come up with more than one plausible results:

When calling the foo constructor, provide a bar, because the foo constructor requires a bar.
When calling the foo constructor, provide a bar, because bar was referenced inside foo.build.

That said, I do agree that for simple error messages (e.g., the example you gave), a resolution could be implied by the error description, and there is no need to call out a "hint". It's optional, but it's useful when the error message is long and detailed guidance is given to the user to resolve the error. Here is an example from @jacob314's earlier prototype:
    throw FlutterError.from(FlutterErrorBuilder()
      ..addError('Scaffold.of() called with a context that does not contain a Scaffold.')
      ..addDescription(
        'No Scaffold ancestor could be found starting from the context that was passed to Scaffold.of(). '
      'This usually happens when the context provided is from the same StatefulWidget as that '
      'whose build function actually creates the Scaffold widget being sought.')
      ..addHint(
        'There are several ways to avoid this problem. The simplest is to use a Builder to get a '
        'context that is "under" the Scaffold. For an example of this, please see the '
        'documentation for Scaffold.of()',
        url: 'https://docs.flutter.io/flutter/material/Scaffold/of.html'
      )
      ..addHint('A more efficient solution is to split your build function into several widgets. This '
      'introduces a new context from which you can obtain the Scaffold. In this solution, '
      'you would have an outer widget that creates the Scaffold populated by instances of '
      'your new inner widgets, and then in these inner widgets you would use Scaffold.of().\n'
      'A less elegant but more expedient solution is assign a GlobalKey to the Scaffold, '
      'then use the key.currentState property to obtain the ScaffoldState rather than '
      'using the Scaffold.of() function.')
      ..addSeparator()
      ..addProperty('The context used was', context)

Isn't the distinction between detail and hint clearer in this example?

I agree that in this case there are hints and that they are distinct from the error description.
How about this for a definition:
error message: A short (one line) description of the problem that was detected. Error messages from the same source location should have little variance, so that they can be recognized as related. For example, they shouldn't include hash codes.
description: An explanation of the problem and its cause, any information that may help track down the problem, background information, etc.
hint (optional): Specific, non-obvious advice that may be applicable.
Information that is always true (e.g. "this argument is required" or "you must include this argument") goes in the description. Information that may not be useful in all situations ("Consider using the Foo widget...") goes in a "hint" section.

That definition sounds good to me!

SGTM. That definition provides a nice crisp separation between what is a hint and what is a description. I'll go ahead and apply it to the existing error messages.

Landed the implementation of structured errors in package:flutter.


SIEM alerts

Hi,
Can you be so kind and tell me if elastalert works with SIEM module?
many thanks
tomislav

Hi tomislav!
If you mean compatibility between the Elastic SIEM module and elastalert; yes it works.
The SIEM module saves its alerts to the index .siem-signals-default-*. You can query .siem-signals-default-* with elastalert. The following elastalert rule to sens the SIEM alerts to TheHive:
name: elastic-siem-signals
type: any
index: .siem-signals-default-*
alert: hivealerter
filter:
  - query_string:
      query: "signal.status:open"
realert:
  minutes: 0
[...OMITTED...]


Setup Nuget v3 and fixed key issue based on #516

I'm so not doing it properly (due to the fact the code hasn't been updated for a while), there's a huge upgrade in dependencies, how nuget works (not using httpclient but rather the nuget.protocol etc) and a fix for keynotfoundexception (Based on #516, I shamely did a copy paste).

If this pull request is merged, then a lot of the pull requests are redundant. I've also refactored the code a tad with separation of interfaces and services. My tests for the NugetV3Service will need some work?

Also Github licenses isn't working at the moment


We should not be bind-mounting any files under /dev, /sys and /proc from the host inside the container.

These files belong to the host OS. Essentially need to revert this commit : 08909b221

Wrong repo.


DBT-780: Upgrade dbt-core version and dbt-impala adapater version to 1.7

Describe your changes
Upgrade dbt-core version and dbt-hive adapater version to 1.7
dbt-core has removed hologram dependency as part of this PR: https://github.com/dbt-labs/dbt-core/pull/8437/files
Hence removing it from dbt-impala too.
Internal Jira ticket number or external issue link
https://jira.cloudera.com/browse/DBT-780
Testing procedure/screenshots(if appropriate):
Checklist before requesting a review

[ ] I have performed a self-review of my code
[ ] I have formatted my added/modified code to follow pep-8 standards
[ ] I have checked suggestions from python linter to make sure code is of good quality.

please update the test plan and doc requirement too eg https://github.com/cloudera/dbt-hive/pull/150


chore: Use --skr-watcher-image-registry flag to configure registry

Description
Changes proposed in this pull request:

Uses new flag for configuring the dev registry

Related issue(s)

partially resolves: https://github.com/kyma-project/lifecycle-manager/issues/1859

PR targeting the feature branch to circumvent the e2e test issue wrt. pull_request_target. Once approved, will be rebased to main and merged.


EKS IAM Roles Service Accounts - Karpenter Missing policy actions

Description
Please provide a clear and concise description of the issue you are encountering, and a reproduction of your configuration (see the examples/* directory for references that you can copy+paste and tailor to match your configs if you are unable to copy your exact configuration). The reproduction MUST be executable by running terraform init && terraform apply without any further changes.
If your request is for a new feature, please use the Feature request template.

[X] ✋ I have searched the open/closed issues and my issue is not listed.

⚠ Note
Before you submit an issue, please perform the following first:

Remove the local .terraform directory (! ONLY if state is stored remotely, which hopefully you are following that best practice!): rm -rf .terraform/
Re-initialize the project root to pull down modules: terraform init
Re-attempt your terraform plan or apply and check if the issue still persists

Versions

Module version [Required]: 5.22.0
Terraform version: 1.5.1

Provider version(s): 5.x

Reproduction Code [Required]
terraform apply

Steps to reproduce the behavior:

No

Yes

Deploying the EKS IAM Service Accounts module with Karpenter attachment
Expected behavior
Module does everything correctly but the Karpenter policy is missing 3 actions.

Actual behavior
Karpenter fails to perform operation.

Deploying the EKS Iam roles for service accounts -> attach Karpenter policy
everything gets created in AWS as it should.
however the policy is missing 3 actions.
Terminal Output Screenshot(s)

These are the missing policies
 "ssm:GetParameter",    "ec2:RunInstances",    "ec2:DeleteLaunchTemplate",
according to Karpenter documentation that can be found here
https://karpenter.sh/v0.28/getting-started/migrating-from-cas/#create-iam-roles
Additional context

those permissions are available

https://github.com/terraform-aws-modules/terraform-aws-iam/blob/c1e20a227ca5c8f2953c5827533a2dc46696d3bb/modules/iam-role-for-service-accounts-eks/policies.tf#L662
https://github.com/terraform-aws-modules/terraform-aws-iam/blob/c1e20a227ca5c8f2953c5827533a2dc46696d3bb/modules/iam-role-for-service-accounts-eks/policies.tf#L649
https://github.com/terraform-aws-modules/terraform-aws-iam/blob/c1e20a227ca5c8f2953c5827533a2dc46696d3bb/modules/iam-role-for-service-accounts-eks/policies.tf#L623

sorry for the issue - we will continue to check why those 3 are not applied


void may cause different boolish behaviour for default_checked_level = :always / :never

Proposal:

Statically check that VOID must not be used for anything.
Additionally look for a way to keep runtime behavior between different default_checked_level's.

In certain scenarios, a return value of VOID may cause different behavior for different default_checked_level's.
This is because even if you don't call any methods* on VOID, it's at least a truthy value.
* Which is already statically checked. E.g. VOID.to_s is already a static error.

To ensure the truthyness of VOID has no effect, the sorbet-static should ensure that a VOID value is always discarded immediately.
This especially requires not to use VOID in these situations:

if void_method ... (or any other control flow expressions)

void_method && other_method

var = void_method
return void_method # both, explicit and implicit return

Additionally it would be nice to have a setting to disable VOID for :always and :tests.
The static checker doesn't get everything if the whole software isn't # typed: strict.
And it may be more the more important requirement not to change behavior between default_checked_level's (at least outside of exception control flow).
If anyone has an alternative to keep the behavior while returning VOID, please tell.
But as far as I know there's no way to create a falsy VOID. And forbidding BasicObject methods like :equal?(or even Kernel methods like to_s) also feels fishy.

The following seems to be a subpart of this issue.
#1367 Detect if void is ever stored in a variable

Example:
→ View on sorbet.run
# typed: true

T::Configuration.default_checked_level = :always
#T::Configuration.default_checked_level = :never

class A
  extend T::Sig

  sig {void}
  def foo
    false  # or nil
  end
end

puts('hu') if A.new.foo
# :always => 'hu' (VOID is truthy)
# :never => '' (foo returned false or nil)

There are many things that won't work when the runtime is disabled. Another example is dead code analysis. We've designed nearly every feature of Sorbet as both a static and runtime feature, it's a non-goal for us to make every feature work with the runtime disabled.

There are many things that won't work when the runtime is disabled. [...]

Maybe you got me wrong.
For me this ticket isn't about the difference between sorbet-runtime and sorbet-static.
This is about not changing the behavior of the plain ruby code between the default_checked_level's.
Assume all development happens in default_checked_level = :always. But for production the default_checked_level is switched to :never.
(I have several reason to do this in the software I'm working on ;-) )
And it would be a bad thing if values which where true/VOID in development become false in production.
Even if you run tests, QA etc. again in production mode, you'd loose a lot of implicit testing while the code was in development.


Endless Loop of Tasklets

I have the following code:
do {
    // Process all tasklets that were indicated to us from OpenThread
    otProcessNextTasklet(pFilter->otCtx);
} while (otAreTaskletsPending(pFilter->otCtx));

I have occasionally found that this gets stuck in an endless loop of processing tasklets. I haven't been able to grab it in the debugger yet, and I want to add a count and assert in DEBUG mode to assert if I hit some number of continuous executions of this loop.

First, is this code correct? Should I be using this differently?
What would be a good threshold to use to treat as a bug if I get more than that many tasklets to execute in a row?

This code could be problematic if OpenThread is using the task queue to "busy-wait" until some condition variable changes.  The Mac class had an example of this, but was recently removed in #706.  In general, you should make sure to process any interrupts from platform drivers - doing so will ensure that you don't get stuck when OpenThread is waiting for a state change/event in the platform drivers.
Of course, if OpenThread is not waiting on a state change from the driver, then you may be running into an actual bug that involves endless task processing.

My most recent hit included #706, so I am leaning towards a bug somewhere. I have a thread completely dedicated to running and processing OpenThread events (see otLwfEventWorkerThread). It processes all the events for running OpenThread. How am I supposed to prioritize between them?

The issue seems to be related to energy scans:
1: kd> ?? pFilter->otCtx->mIp6
class Thread::Ip6::Ip6
   +0x000 mRoutes          : Thread::Ip6::Routes
   +0x010 mIcmp            : Thread::Ip6::Icmp
   +0x040 mUdp             : Thread::Ip6::Udp
   +0x058 mMpl             : Thread::Ip6::Mpl
   +0x110 mMessagePool     : Thread::MessagePool
   +0x40130 mTaskletScheduler : Thread::TaskletScheduler
   +0x40140 mTimerScheduler  : Thread::TimerScheduler
   +0x40148 mForwardingEnabled :
   +0x40150 mSendQueue       : Thread::MessageQueue
   +0x40160 mSendQueueTask   : Thread::Tasklet
   +0x40180 mReceiveIp6DatagramCallback : 0xfffff805`53ae3df0     void  otLwf!otLwfReceiveIp6DatagramCallback+
   +0x40188 mReceiveIp6DatagramCallbackContext : 0xffffc18c`a559a950 Void
   +0x40190 mIsReceiveIp6FilterEnabled :
   +0x40198 mNetifListHead   : 0xffffb08a`0b3cc028 Thread::Ip6::Netif
   +0x401a0 mNextInterfaceId : 2 ''

1: kd> dx -r1 (*((otLwf!Thread::TaskletScheduler *)0xffffb08a0b3cbfb0))
(*((otLwf!Thread::TaskletScheduler *)0xffffb08a0b3cbfb0))                 [Type: Thread::TaskletScheduler]
    [+0x000] mHead            : 0xffffb08a0b3ccbe0 [Type: Thread::Tasklet *]
    [+0x008] mTail            : 0xffffb08a0b3ccbe0 [Type: Thread::Tasklet *]

1: kd> dx -r1 (*((otLwf!Thread::Tasklet *)0xffffb08a0b3ccbe0))
(*((otLwf!Thread::Tasklet *)0xffffb08a0b3ccbe0))                 [Type: Thread::Tasklet]
    [+0x000] mScheduler       : 0xffffb08a0b3cbfb0 [Type: Thread::TaskletScheduler &]
    [+0x008] mHandler         : 0xfffff80553afa510 [Type: void (__cdecl*)(void *)]
    [+0x010] mContext         : 0xffffb08a0b3ccad8 [Type: void *]
    [+0x018] mNext            : 0x0 [Type: Thread::Tasklet *]

1: kd> u fffff80553afa510
otLwf!Thread::Mac::Mac::HandleEnergyScanSampleRssi [c:\users\nibanks\source\repos\openthread-win\src\core\mac\mac.cpp @ 230]:
fffff805`53afa510 48894c2408      mov     qword ptr [rsp+8],rcx
fffff805`53afa515 4883ec28        sub     rsp,28h
fffff805`53afa519 488b4c2430      mov     rcx,qword ptr [rsp+30h]
fffff805`53afa51e e84dffffff      call    otLwf!Thread::Mac::Mac::HandleEnergyScanSampleRssi (fffff805`53afa470)

Yes, Mac::HandleEnergyScanSampleRssi is another example of "busy-looping" in a tasklet waiting for an event from the platform drivers.  This implementation is designed to sample the radio's RSSI as quickly as possible and stop when Mac::HandleMacTimer() is called.  Of course, the timer handler is only called when the platform alarm fires.  The current OpenThread examples always processes the platform drivers before each call to otProcessNextTasklet().

Ok. I put some code to only process up to 10 tasklets in a row before breaking out and trying doing some other things (timers, send/recv, ...). But can you explain a bit more why OpenThread needs to sit in a busy loop, polling? Is this something we might be able to offload to the radio with some kind of get and async completion callback?

@nibanks, this is a common pattern to have a task post itself back while waiting for some end condition. Note that this is not a pure busy loop, as other tasks may be posted and executed in between. This  pattern is used in energy-scan implementation where we want to continuously (and as quickly as possible) sample RSSI for certain interval. It is also used (sort of indirectly) in NcpUart class for sending data over uart.
As @jwhui  suggested, your do-while loop should include the processing of drivers (timers, send/recv, etc.) in the same loop where the tasks are being handled. Or they should happen fully from a different thread/context.

I totally understand for OpenThread running on the device to using a polling mechanism. But when it is running on a host, such as Windows, not only is it detrimental to the rest of the OS to be spinning, but since the actually otPlatRadioGetRssi call will take a while to get to the device and back, it's not going to give the best results.
At least when running on Windows, we would need to offload this entire process to the radio layer. If we don't want to offload this when running on the device, we could use otPlatRadioGetCaps to control the OpenThread logic to decide whether to offload the logic or do it locally.

I put some code to only process up to 10 tasklets in a row before breaking out and trying doing some other things (timers, send/recv, ...). But can you explain a bit more why OpenThread needs to sit in a busy loop, polling?

To the extent that something is using tasklets to implement polling for a condition (which, with your loop, results in a busy-wait), I believe that is a bug that should be fixed. However, I don't think that is the bug we are seeing here.
I think the real problem is in how we dispatch tasklets. Ideally, at each pass through the main loop we would dispatch all tasklets that have been added up to that point. Any new tasklets added as a part of dispatching those tasklets would be handled at the next iteration through the main loop. This prevents the other parts of the main loop from being starved of cycles. Unfortunately, I don't think the current API allows you to implement that sort of behavior.
Perhaps we need to adjust the API to allow that?

Maybe something like otProcessTasklets(). It would only dispatch tasklets queued up at the time it is called. Any new tasklets queued up while the tasklets are being dispatched would be handled at the next main loop iteration.

The idea of having otPlatRadioGetCaps to check if the radio provides an energy scan function sounds good to me. But we will still need to support this for radio platforms that don't provide this feature.

@darconeous, I like the idea of changing the API (or just adding an additional one?) to process all currently queued tasklets. When I originally put together my code, I assumed that was what the API was going to do anyways. It took me a while to debug why everything wasn't working...
@abtink, yeah, supporting both sounds good.

How about otProcessQueuedTasklets()?  Do we want to keep the existing otProcessNextTasklet()?

I'd vote to not keep otProcessNextTasklet since having some clients execute tasklets differently will likely just make things harder to debug if a problem arises in this area. Also, I like the name otProcessQueuedTasklets.


Even if you set robolectric.pixelCopyRenderMode, there are patterns where the setting is ignored.

Overview

The conditions for this to occur are as follows

LocalInspectionMode is true
SkiaGraphicsLayer.toImageBitmap is used
The following library versions

composeMultiplatform: https://github.com/JetBrains/compose-multiplatform/releases/tag/v1.7.0-alpha02
compose-bom: 2024.09.00
composeMaterial3: https://developer.android.com/jetpack/androidx/releases/compose-material3?hl=ja#1.3.0

Link

https://github.com/DroidKaigi/conference-app-2024/pull/984

I made a mistake, so I'm closing it. 🙇


enable CFG(ControlFlowGuard)

Since LLVM 16: Support for https://github.com/mstorsjo/llvm-mingw/issues/301 (-mguard=cf compile and link flags)
May need to migrate x86_64 build to llvm-mingw

Thanks for the heads up that cfguard is getting ready for use.
After enabling the necessary options, it worked with llvm-mingw out of the box. curl -V works under wine. I didn't test it more, and don't know how to probe if cfguard is indeed active.
Then I bumped LLVM to 16 on Debian, and it also successfully created the binaries (meaning no build-time errors).
These correctly show GUARD_CF, have their .00cfg segment, but they came with this linker warning:
ld.lld: warning: Control Flow Guard is enabled but '_load_config_used' is missing

This is because the mingw-w64 package is built without the --enable-cfguard option, thus missing this feature alongside the load_config_used bits. (The root cause is that this option needs clang and mingw-64 is usually built with GCC, which still lacks cfguard support.)
I'm hesitating making llvm-mingw the default for x64 (and x86), because most users expect curl-for-win libs to work with the llvm + mingw-w64 coming with the popular package managers. I also want the keep curl-for-win itself run correctly with toolchains offered via package managers.
Test build here:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/47718371

Enabled it for ARM64 in live builds:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/47719051
Binaries:
https://curl.se/windows/dl-8.2.1_4/

The PS script didn't work for me (The Export-ModuleMember cmdlet can only be called from inside a module.), but peeking into the source, it seems to be relying on the CFGUARD flag in the PE header. curl-for-win logs this already, and it's correctly set.
The docs say that this isn't enough and some other bits need to be set in the "load config" structure.
This is what's missing in builds with the warning mentioned above.
I don't have a suitable Windows system to make tests with Windows Defender though.

Here are the x64 and x86 binaries with cfguard and the mentioned warning (meaning it's most probably inactive, but it'd be interesting to confirm it on a real system):
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/47720448/artifacts
And these all built with llvm-mingw + cfguard:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/47720885/artifacts
Debian-testing, macOS+Homebrew and MSYS2 are all well-updated distros, but they rely on GCC + binutils, which is slow to pick-up with Windows features (ARM, UCRT, cfguard).

@arm64-v9a Thanks for your tests.
Could you try running the x64 curl.exe from this build?:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/47720448/artifacts
This is an attempt to enable cfguard for the static libs, while keeping it disabled in curl.exe so that it runs correctly.

@arm64-v9a Thanks for your tests.
Could you try running the x64 curl.exe from this build?:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/47722127/artifacts
This is an attempt to enable cfguard for the static libs, while keeping it disabled in curl.exe so that it runs correctly.

Thank you! Based on this it seems that cfguard is an all-or-nothing setting, even a cfguard-compiled object triggers the OS, in an executable with unset CFGUARD flag. It means there is no way to ship cfguard-enabled objects and let the linker decide to enable it or not.
[ Also CMake doesn't offer a way to pass an option to the C compiler only, without passing it to the linker, too. This is a problem because the compiler and linker flags have the same name (-mguard=cf). This may be worked around with some tricks I've yet to figure out. ]
Therefore, enabling cfguard forces all curl-for-win static lib consumers to have to enable it for all the their other objects and their executables, while also switching to llvm-mingw. This may work with ARM64 a little better because it required llvm-mingw already. For x64/x86 it reduces choices at the moment. Hard to say if this inflexibility can be improved by the tooling or something inherent to the design of cfguard.
I had expected that including a single cfguard-compiled object won't break a final executable, unless cfguard was explicitly enabled at link-time.

One thing I find odd that this feature seems entirely the function of objects having cfguard enabled, yet it also requires a link-time option to set the GUARD_CF flag in the executables. Either I'm missing something or this flag "should be" unnecessary.
To summarize where we are now:

curl-for-win has cfguard enabled for ARM64 in official binaries v8.2.1_4.
Marked as EXPERIMENTAL.
logic was added to enable cfguard automatically when building with llvm-mingw.
This can be enabled by setting env CW_LLVM_MINGW_ONLY to 1
in custom or local builds.

Hi, I just noticed this issue by chance and thought I should comment. Unfortunately some context has been lost because it seems most replies by the OP has been deleted, so I don't have the full picture.

Thank you! Based on this it seems that cfguard is an all-or-nothing setting, even a cfguard-compiled object triggers the OS, in an executable with unset CFGUARD flag. It means there is no way to ship cfguard-enabled objects and let the linker decide to enable it or not.
Therefore, enabling cfguard forces all curl-for-win static lib consumers to have to enable it for all the their other objects and their executables, while also switching to llvm-mingw. This may work with ARM64 a little better because it required llvm-mingw already. For x64/x86 it reduces choices at the moment. Hard to say if this inflexibility can be improved by the tooling or something inherent to the design of cfguard. [UPDATE: I'd guess the latter.]
I had expected that including a single cfguard-compiled object won't break a final executable, unless cfguard was explicitly enabled at link-time.

As far as I remember this is not true. You should be able to compile objects with -mguard=cf but not enable it while linking, and still produce fully working executables (without control flow guard active). It has to be designed this way because the CRT itself also has to be compiled with CFG to include the guard checks, but still allows it to be linked with user code without CFG enabled.
You can check with the test case in llvm-mingw:
> clang -mguard=cf cfguard-test.c -c -o cfguard-test.o

> clang cfguard-test.o -o cfguard-test.exe

> llvm-readobj --coff-load-config cfguard-test.exe
[...]
  GuardFlags [ (0x0)
  ]
[,,,[

> cfguard-test check_enabled
Control Flow Guard is _not_ enabled!

> cfguard-test normal_icall
Performing normal indirect call.
Normal function called.

> cfguard-test invalid_icall
Performing invalid indirect call. If CFG is enabled this should crash with exit code 0xc0000409 (-1073740791)...
Pwned!!!

[ Also CMake doesn't offer a way to pass an option to the C compiler only, without passing it to the linker, too. This is a problem because the compiler and linker flags have the same name (-mguard=cf). This may be worked around with some tricks I've yet to figure out. ]

I have not tried it myself, but the docs for add_compile_options and target_compile_options explicitly states they are not used when linking. Do they not work for you?

It's possible I got it wrong, but after a considerable amount of time spent on testing, I positively could not make it work that way, meaning: by enabling CFG at compile-time, not enabling it at link-time, yet getting a runnable binary.
(I don't have a Windows machine capable of testing this, so this involved feedback from others, which feedback is apparently now missing from this thread's history.)
I'd be happy to be proven wrong as it'd allow switching to llvm-mingw and enabling this without forcing everyone downstream doing the same.

Here's a llvm-mingw build with CFLAGS-only:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/48394235/artifacts
Here's another one with CFLAGS+LDFLAGS:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/48396839/artifacts
Please report which one is running or failing to run on old and new Windows versions,
and if CFG is or isn't enabled with them.

Tested on my x64 Windows 10 system, both win32 and win64 builds run fine here (can perform an https request). The CFLAGS-only ones don't have CFG enabled, while the CFLAGS+LDFLAGS ones do have CFG enabled (checked in Process Explorer), which matches my expectations.
I don't have an aarch64 Windows system, nor do I have any older Intel Windows systems/VMs, but I can try to ask someone else to help.

Tested on my x64 Windows 10 system, both win32 and win64 builds run fine here (can perform an https request). The CFLAGS-only ones don't have CFG enabled, while the CFLAGS+LDFLAGS ones do have CFG enabled (checked in Process Explorer), which matches my expectations.
I don't have an aarch64 Windows system, nor do I have any older Intel Windows systems/VMs, but I can try to ask someone else to help.

Both of the aarch64 builds do run just fine; I don't have Process Explorer available right now to check that CFG is enabled though.

@alvinhochun: Thanks for your tests! This is different from previous tests, but it's possible there was an error along the way before.
Both x64 binaries also run fine on a Win7 system.
This indicates that we could publish CFG-enabled static libs and those could still be used with non-llvm-mingw toolchains, though this might need actually testing this to confirm.

Using this script I built an example program with clang, gcc and llvm-mingw and the resulting 4 .exe also built and run fine on Win7:
#!/bin/sh

opt='-static -s -DCURL_STATICLIB connect-to.c -I../include -L.
  -lbrotlicommon -lbrotlidec -lcrypto -lssl -lnghttp2 -lnghttp3 -lngtcp2 -lngtcp2_crypto_quictls
  -lssh2 -lz -lzstd -lcurl -lws2_32 -lbcrypt -lcrypt32 -lwldap32'

/usr/local/opt/llvm/bin/clang -fuse-ld=lld \
  -target x86_64-w64-mingw32 --sysroot /usr/local/opt/mingw-w64/toolchain-x86_64 \
  -D_UCRT -lucrt ${opt} -o curltest-clang

x86_64-w64-mingw32-gcc -dumpspecs | sed 's/-lmsvcrt/-lucrt/g' > _gcc-specs-ucrt
x86_64-w64-mingw32-gcc -specs=_gcc-specs-ucrt \
  -D_UCRT -lucrt -Wl,--start-group ${opt} -Wl,--end-group -o curltest-gcc
rm -f _gcc-specs-ucrt

~/llvm-mingw/bin/x86_64-w64-mingw32-clang \
  ${opt} -o curltest-llvm-mingw

~/llvm-mingw/bin/x86_64-w64-mingw32-clang \
  ${opt} -o curltest-llvm-mingw-cfg -mguard=cf

~/llvm-mingw/bin/llvm-readobj --coff-load-config *.exe

One thing to note, objects compiled with CFG (if they make indirect calls) do need to reference the symbol __guard_check_icall_fptr (__guard_dispatch_icall_fptr on x86_64) which is only provided in mingw-w64 CRT since v11 (unconditionally included even if itself is not built with CFG). If the user is using an older mingw-w64 toolchain, they will get an undefined symbol error when trying to link to the static library. Did you encounter this when testing or have you always tested with the latest mingw-w64 CRT? (It is possible to supply these symbols externally but doing this is messy and inconvenient.)

Good point. I did these tests with mingw-w64 v11. In general I'm okay requiring a fresh mingw-w64, but in this case v11 is missing from the latest stable Debian/Ubuntu for example, which might be a problem for some:
https://packages.debian.org/bookworm/mingw-w64-common (since testing/trixie)
https://packages.ubuntu.com/lunar/mingw-w64
https://packages.fedoraproject.org/pkgs/mingw-w64-tools/mingw-w64-tools/ (since 39)
https://pkgs.alpinelinux.org/packages?name=mingw-w64-crt&branch=v3.18 (ok)
Probably more users would use MSYS2, which always has the latest mingw-w64.
Or llvm-mingw, with full CFG support.
Though I have no insight how (and how many) people use curl's static libs.

Another possibly interesting bit is ASM compatibility with CFG. It is reported that ASM does not work with CFG, to which OpenSSL maintainers suggest to disable ASM for CFG builds.
This should already affect curl-for-win ARM64 Windows builds, having both CFG and ASM enabled. It'd be nice to see any feedback on that binary. I haven't had a chance to ever run those myself, nor do they run in any CI.
Ref: https://github.com/openssl/openssl/issues/22554
This might also affect LibreSSL x64 builds in the future.

If the issue is limited to uplink (or 'applink'), curl-for-win is not affected because it builds OpenSSL with no-shared which disables applink, too. Also, no other forks copied this crazy (IMO) feature, and indeed, on Windows it is enabled by default only on x86.
An interesting tidbit about applink: It was a feature that was causing continuous headache for many years downstream. While discussing this in 2016 with the OpenSSL team, it turned out that it was not working before 1.1.0 due to a local bug in the assembly code. This received a fix shortly after.
This was a good opportunity IMO to switch to a different solution or to drop it completely, but the feature is still there and continue causing headaches.

The only way this will resolve is when upstream packages enable CFG support in places necessary (mingw-w64 support, with this option enabled). On part of curl-for-win this will require an update to start using it at the right moment, or possibly implement detecting such moment, though this doesn't seem trivial or worthy the effort.
Probably worth revisiting when Debian Trixie is release.
Will convert this to a TODO and close.

I don't think depending on Debian here is sensible. To support CFG, mingw-w64 has to be built with Clang+LLD while Debian and most of the other Linux distributions use GCC+Binutils.

What are our other options?

The fundamental issue is that CFG-enabled libs cannot be used with non-CFG-enabled toolchains.
We offer an option to force using llvm-mingw for all CPU targets (by default it's used for ARM64 only). If enabled, CFG is also enabled.
To offer CFG out of the box for Intel, there are these options:

enable llvm-mingw by default. This would limit our distributed static libs to llvm-mingw and best case to those distros offering a compatible mingw toolchain.

enable it for the Debian mingw toolchain. We do these cross-build from Debian, that's why it's a Debian thing. Obviously it needs CFG support there. The result would work with Debians, hopefully llvm-mingw, and other distros with a compatible mingw toolchain.

It would be useful to know which if any distro mingw toolchains offer CFG compatibility.
If there are other options, or there is a logic mistake in the above, let me know.

Sorry, forgot to respond.
I'm afraid there is no way to provide a single library that fits both cases and two distinct libraries would have to be provided.

enable it for the Debian mingw toolchain. We do these cross-build from Debian, that's why it's a Debian thing. Obviously it needs CFG support there

I doubt this is doable since GCC lacks this feature, and building Debian's mingw-w64 package with Clang would make it incompatible with other GCC-based toolchains because of the other missing features in GCC like native TLS.

Multiple binaries would make things proportionally more complex and resource intensive, to offer a hard-to-explain choice on the download page.
It seems like a case where the solution is in the hands of toolchain authors, by either making this option more flexible or making sure it gets supported and deployed everywhere.
Till then, the solution is to do a custom build with CW_LLVM_MINGW_ONLY=1. Everyone is free to run a fork or CI job that builds with this option and distributes the results. This might be the best option at this point.

You can link  CFG-enabled object files with non-CFG objects and it will still work fine, as long as the mingw-w64 crt is new enough (mingw-w64 v11) to include the dummy __guard_check_icall_fptr and __guard_dispatch_icall_fptr symbols and the final linked binary does not have CFG enabled (or is linked with a linker that does not support CFG).

@alvinhochun That's where I'm heading to, but waiting for the last major distro (Debian stable) to catch up with its mingw-w64. It's at 10, whch doesn't have support. Or am I missing something?


GH-15192: [C++] Bring back case_when tests for union types

Rationale for this change

Bring back the problematic test case of random case_when on union(bool, string) type. This case used to fail. However #36018 already addressed the issue.
More information about how it used to fail, please refer to https://github.com/apache/arrow/issues/15192#issuecomment-1862252174.
What changes are included in this PR?

Bring back the test code.
Are these changes tested?

Yes, the change is the test.
Are there any user-facing changes?

No.

Closes: #15192

@github-actions crossbow submit -g cpp


Hiero: Default to crash-less Java renderer, return to it if Freetype would cause crash

This expands on my last Hiero PR, and actually removes most of it since it turns out not to be needed if we just start on the Java renderer. Only Freetype will crash if the 'x' character is missing from a font; Java and Native don't care. There are some cases where you might want only upper-Unicode chars and a font might only provide those chars, so swapping to Arial maybe isn't the best solution. Defaulting to Java as the renderer also enables the Effects panel right away, which is a major feature of Hiero. I suspect this may fix #6359 , but that whole font/OS installation is very different from my own, so I may not be testing it correctly against that issue.

Also, before testing, if you've run Hiero before and had problems, maybe try deleting the Hiero preferences, because the app could still load with Freetype selected if that's what was last saved. Deleting the preferences should make it use Java at first startup, and that shouldn't have issues even with fonts without 'x'.

Thanks for the fix! Hiero doesn't crash anymore now


Seems not working

I don't have try to edit, but for me it's not working, I map the driver with my custom mapper with manual load and i try but zero features works for me..

btw I can finish the integration of ImGui for you if you want

Press "Attach" button with cs2 process running. You should get WinPAI's MessageBox that cheat had attachet to target process. After that you can use features
Also I'm not sure what's in release branch rn. Need to merge main after I finish Thread Management
Speaking of ImGui: you can fork this repo if you want and open a pull request to main branch.
Feel free to DM me if you have any other questions
https://discord.com/invite/wFUmHRUmjR

There were some CS2 updates so I guess release branch contains outdated offsets. I queued new build


Add new developers to urbancode velocity plugin

Description

UrbanCode Velocity Plugin
Submitter checklist for adding or changing permissions
@crjenkins89 - I am a maintainer/contributor and both additions should be added
@aberkIBM - needs to confirm

Always

[X] Add link to plugin/component Git repository in description above

For a newly hosted plugin only
~- [ ] Add link to resolved HOSTING issue in description above~
For a new permissions file only
~- [ ] Make sure the file is created in permissions/ directory~
~- [ ] artifactId (pom.xml) is used for name (permissions YAML file).~
~- [ ] groupId / artifactId (pom.xml) are correctly represented in path (permissions YAML file)~
~- [ ] Check that the file is named plugin-${artifactId}.yml for plugins~
When adding new uploaders (this includes newly created permissions files)

[X] Make sure to @mention an existing maintainer to confirm the permissions request, if applicable
[X] Use the Jenkins community (LDAP) account name in the YAML file, not the GitHub account name
[X] Make sure to @mention the users being added so their GitHub account names are known if they require GitHub merge access (see below).
[X] All newly added users have logged in to Artifactory at least once

Reviewer checklist (not for requesters!)

[ ] Check this if newly added person also needs to be given merge permission to the GitHub repo (please @ the people/person with their GitHub username in this issue as well). If needed, it can be done using an IRC Bot command
[ ] Check that the $pluginId Developers team has Admin permissions while granting the access.
[ ] In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
[ ] If security contacts are changed (this includes add/remove), ping the security officer (currently @daniel-beck) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it

Make sure to @mention an existing maintainer to confirm the permissions request, if applicable

FWIW someone is a "maintainer" (as we use the terminology) if and only if they are already in the file.
See also my response in https://issues.jenkins-ci.org/browse/INFRA-2725

I approve!

Also I have left the organization and request that crjenkins89 becomes the primary owner of this plugin


Update index.html

thanks for opening merge pull request!
Please add little description, before changing.


Unable to drag nodes in a force layout graph when zooming is added

I took the code from the Miserables force-directed graph example and added zooming.
With version 3.1.10 of d3, I can zoom with the mouse wheel, and also drag individual nodes within the graph to reposition them.
But with version 3.2.7, while zooming still works, dragging individual nodes results in dragging the entire graph instead:
https://gist.github.com/brzpegasus/97a2427ff0ba57a979d2#file-force-layout-with-zoom-L19
Was this an intended change? I'm relatively new to d3 so it's possible I'm just missing something critical in the code for this to work with the latest version.

@brzpegasus Thanks, working

@mael-morel :+1:

Thanks that working for me.


[Joss review] Installing groupyr installs unnecessary dependencies

Describe the bug
Hi, as part of the JOSS review I'll open a few issues. If you'd prefer, I can compress them all into one issue instead.
Steps/Code to Reproduce
Installing the latest groupyr version on pypi also installs ipywidgets (and the large list of its dependencies). As far as I can tell, that's not required for the library (searching for ipywidgets in the source code doesn't yield any results.
Expected Results
Only dependencies required for groupyr functionality to be installed.
Versions
0.2.0

Nice catch @janfreyberg. Resolved in #40. Thanks!


Add landscape snapshot tests

This PR adds snapshot tests in landscape mode for regular and large font types.
Snapshot PR: https://github.com/salemove/ios-widgets-snapshots/pull/49
MOB-2683

!squash

!squash


Update from Rust's obsoleted closure syntax

Maintaince PR, no features.

Huh, are they removing the &mut/& specifiers? Thought they were necessary atleast in some cases since inferring it would be to much work. (And only they &mut specifier? Does it not work without any specifier?)

Seems they are but for some reason |&:| still compiles but not |&mut:| I will pull this in locally and remove the specifier completely before merging

Yes, it fails with &mut using the latest nightly.

Closed by 8889f120537ceaf233d0def185aca0e63817370d

Did an amend on your commit since it seemed unnecessary to have two basically identical commits. Hopefully it should still work for you if you had work based on this (if nothing else the rebase should be simple)


purchase updates shows wrong info

Version of flutter_inapp_purchase
3.0.1
Platforms you faced the error (IOS or Android or both?)
iOS
Expected behavior
When listening to purchaseUpdated I should get updates based on user's real actions with Apple IAP dialog.
Actual behavior
purchaseUpdated get called multiple times and always returns transactionStateIOS = TransactionState.purchased even when IAP dialog don't show up (which is also a bug).
Tested environment (Emulator? Real Device?)
Real Device - iPhone 11 Pro - iOS 14.3
Steps to reproduce the behavior
Implement basic usage of IAP

@CripyIce  I've faced similar problems because I was registering listeners more than once.
Please check your code flow and check that you're registering listeners only once.
Hope this helps

@CripyIce  I've faced similar problems because I was registering listeners more than once.
Please check your code flow and check that you're registering listeners only once.
Hope this helps

Same issue. Getting false purchase-updated event while there wasn't even system IAP dialog. Also iPhone=11 and IOS=14

Same issue. Getting false purchase-updated event while there wasn't even system IAP dialog. Also iPhone=11 and IOS=14

@CripyIce I've faced similar problems because I was registering listeners more than once.
Please check your code flow and check that you're registering listeners only once.
Hope this helps

FYI i checked and i don't have set-listener duplications in my code. So maybe guess is wrong.

@CripyIce I've faced similar problems because I was registering listeners more than once.
Please check your code flow and check that you're registering listeners only once.
Hope this helps

FYI i checked and i don't have set-listener duplications in my code. So maybe guess is wrong.

I am getting same issue. I have used example code and I have purchased Subscription. even after Subscription cancel or Expired It's showing only TransationState.purchase