Adds literal node

Adds literal node, solving #422
I tried to implement this as a wrapper around EnumNode, but this turned out to be impossible. Literal can accept int, str, bool and Enum values, but enum keys must be strings. So for example
from dataclasses import dataclass

@dataclass
class Config:
  mode: Literal["5", 5]

there is no way to map both of these values to separate enum keys without also causing a collision somewhere else.
This PR validates a LiteralNode value by insisting on both = equality and type equality. Both are needed, otherwise python's promiscuous primitive equalities cause problems e.g. 1.0 is valid under Literal[True].
I tried to add tests wherever EnumNode had tests, but I'm unfamiliar with the codebase. Please let me know if additional tests are needed.

Okay I clearly missed a bunch of tests, working on that. Not sure what's up with mypy not thinking Literal exists.

The literal thing was because setup.cfg sets the mypy version to 3.6 by default. I had a legitimate problem where I need to import from typing_extensions before 3.8, which I now do. I also added a dependency to the pre-commit hooks to fix a bunch of mypy errors locally, although this didn't appear to show up in the last round of circleci results.

Looks like I've ironed out all the python version issues.

Hi @jordan-schneider! Thanks for taking the time to create this PR.
At the moment, I can't commit to a timeline for merging this, as the OmegaConf team's hands are full.

Thanks very much @jordan-schneider.
Unfortunately it may be some time before we are able to give this PR a serious review as the Hydra/OmegaConf team has its hands full at the moment.

Hi, I'm the one who originally opened #422. So I'm very happy you are doing this!
I'm obviously not an official member of OmegaConf, but I thought I would try to help you with a code review anyway.
Some questions:
1. What happens if I annotate a node with just `Literal` without any type arguments for `Literal`?

2. Don't we have to add something like `typing_extensions;python_version<'3.8'` to `requirements/base.txt`? Or is `typing_extensions` a dependency anyway?

I don't have time at the moment to directly check this but Literal.values/args still exists but is empty, so the LiteralNode is constructed and whatever the value is it fails to validate. This seems like the correct behavior. I'll write a test for this when I have a moment.

I think it's a dependency of one of the other dependencies but it should be added explicitly anyway, in case that changes. Again I'll handle this when I have a moment.

If I remove that type: ignore comment locally I do in fact get an error. Anyone know what's going on here?

@jordan-schneider maybe upgrade the version of mypy that you have installed locally?

If I remove that type: ignore comment locally I do in fact get an error. Anyone know what's going on here?

The CI should pass if you rebase this branch against the master branch to incorporate changes from #878.

I think it was mostly outdated local versions of tools. The pre-commit version of black and the current version used by CircleCI also disagreed, so I updated the pre-commit version as well.

Are there plans to merge this? It would be super useful!

Thanks for the nudge, @codekansas!

Are there plans to merge this?

Yes. We haven't been able to finalize this PR yet as the OmegaConf team's bandwidth is limited. It is on the roadmap.

@Jasha10 nudge again to enquire about plans/status since some time has passed

@omry @Jasha10 would appreciate some eyes on this, it's been in limbo for a year and a half and would be a nice way to produce clean structured configs

+1 this feature would be great and feels more pythonic than Enums.

+1

+1

+1, still relevant

+1

+1


[ Question / Performance ] If there were million upvoters for a comment

Hi @queso
Great work here
Just seen this and seen that you are using embed documents to save the upvoters for a comment
_id: "uRMcAdPv7cKbrN7Qo"
author<EMAIL_ADDRESS>baseScore: 3
categories: Array[0]
clickCount: 0
commentCount: 0
createdAt: Tue Jan 19 2016 13:30:16 GMT+1300 (NZDT)
downvotes: 0
inactive: false
postedAt: Tue Jan 19 2016 13:30:16 GMT+1300 (NZDT)
score: 0.003543163938850198
slug: "my-tscope"
status: 2
sticky: false
title: "My Tscope"
upvoters: Array[3]
upvotes: 3
userId: "y4vSMjwWbRa9WKi2g"
viewCount: 0

What will you do to increase performance if there were to be a million upvoters ?  would you still save their ids in an array ?

That's an interesting hypothetical question, but I think it'd be better on Stack Overflow or as a blog post, it's not really related to Telescope (more to Mongo).


[Feature Request]:  Tlit Effect to the Image

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
Tlit Effect to the Image
Use Case
Tlit Effect to the Image
Benefits
Tlit Effect to the Image
Add ScreenShots

Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[ ] I'm a SSOC'24 contributor
[X] I have starred the repository

@Damini2004 I have assigned u this issue .But please from next time provide some more details about your issue like in which project do u want to add the animation...& why ?? how will be the users get the benefits  after u add this features to that project

@apu52 Sure sir.


Consider supporting @keyword so there are no illegal words

@yield would be an identifier with value "yield".

and maybe @"foo bar baz ()" if we want arbitrary characters in identifiers for any reason

Implemented in 15f1280


fallback-sha is ignored

I get the following error when specifying fallback-sha:
Warning: Unexpected input(s) 'fallback-sha', valid inputs are ['main-branch-name', 'set-environment-variables-for-job', 'error-on-no-successful-workflow', 'last-successful-event', 'working-directory', 'workflow-id']

Indeed, fallback-sha is never passed to the list of envs in https://github.com/nrwl/nx-set-shas/blob/main/action.yml

Duplicate of #158


Out-of-bounds memory writes for messages not divisible by 8 bytes

    pub fn encrypt_vec(&self, buffer: Vec<u8>) -> Vec<u8> {
        ... (no operations that append padding bytes to `buffer`) ...
        unsafe {
            let mut src = std::mem::transmute::<Vec<u8>, Vec<u64>>(buffer);
            self.encrypt_bytes(&mut src, length, b_len);
            std::mem::transmute::<Vec<u64>, Vec<u8>>(src)
        }

This will smash the heap if the message is not a multiple of 8 bytes.

Consider using https://doc.rust-lang.org/stable/std/primitive.slice.html#method.align_to myvec.align_to::<u64>() instead - it'll give you three slices, one for the start of the buffer that's in bytes, one for the middle of the buffer in u64s, and one for the end of the buffer in bytes again. It'll be easier than all that manual math

Thank you for the reference !
I tried this method and it only returns the bytes that it could align (as you mentioned). And also it interally calls the same creating raw pointer function. I'll eventually have to manually convert those prefix and suffix to u64 which is more overhead than pre-calculating the expected length.
Can you please point out what's wrong with current implementation and steps to reproduce this mis-alignment issue ?

Right, so you need to enable Address Sanitizer to reproduce this crash. Here is the documentation:
https://doc.rust-lang.org/beta/unstable-book/compiler-flags/sanitizer.html#addresssanitizer
cargo +nightly -Zsanitizer=address test
It will trigger on your existing test cases.

Using align_to degrades performance by being major overhead as mentioned in my previous comment.
Without align_to:
Buffer Size = 1.6 GB
Encrypted   = ~1.5s
Decrypted   = ~1.7s

With align_to:
Buffer Size = 1.6 GB
Encrypted   = ~7s
Decrypted   = ~6s

Hence, I won't be using this align_to, instead https://github.com/shank03/XORCryptor-Rust/commit/d9288e8c10c308772e67b6c399bb79cf537f7b36 this is doing the job of padding before transmuting


Add an appropriate license

https://choosealicense.com/licenses/
https://choosealicense.com/licenses/apache-2.0/
https://www.apache.org/licenses/LICENSE-2.0

But still MIT for the public packages


How did this work before?

Can the creator or someone explain how this works? By this I mean what line of code does what? I don't really know the GO language but I might be able to fix this if someone explains this. Also, how do you execute/run GO code?

I will not explain line-by-line how the program works because, unless you have a very good general knowledge of programming, such an undertaking would take months or maybe even years. Instead, I will explain at a high level how this works.
In order to implement this, I first reverse-engineered the protocol that Kahoot uses. When devices connect to Kahoot, they do so through WebSockets. Most modern browsers let you easily monitor and dump the exact data which is being transferred over WebSockets, so this step wasn't too hard.
In general, the "hacks" imitate a regular client. The flood "hack" simply connects to the kahoot server many times as if it were a normal client and registers many different nicknames. It is clear that a regular person with a laptop could do the exact same thing if they could open tabs and type nicknames fast enough.
The "crash" hack worked by exploiting a bug in Kahoot's client-side JavaScript code. Essentially, I could send a malformed response packet which caused an exception on all connected clients that saw the packet. This would result in the Kahoot quiz "crashing"--the next question would not appear and the site was rendered useless until it was refreshed.
If I were Kahoot, I would have fixed the exception bug by now. However, I see no reason why the flood hack should be broken. It is much more likely that the people saying it is broken simply don't understand how to run Go code.

how do i use the flood hack when i use it this happens
i type this to run flood.go go run flood.go
then it says this Enter game pin: 98299
then this Enter nickname: test
then this Enter count: 4
then this happens Registering test1 ...
Error: tls: oversized record received with length 20527
exit status 1

@fishfishfish2104 please see the note in the README, namely:

NOTE: I have not maintained these tools for a while. I have heard reports that they are broken. If anybody wants to fix them, be my guest. But I do not intend to.

See issue #9

See issue #9


Test does not match after recording if JSON array empty

I recorded one of my call thourgh Wiremock (standalone 2.19.0), this is what I got:
{
  "id" : "1e6a0dcc-4edb-4274-a18a-9940c6250d3d",
  "name" : "array_empty",
  "request" : {
    "url" : "/array/empty",
    "method" : "PUT",
    "bodyPatterns" : [ {
      "equalToJson" : "[]",
      "ignoreArrayOrder" : true,
      "ignoreExtraElements" : true
    } ]
  },
  "response" : {
    "status" : 200,
    "headers" : {
      "X-Powered-By" : "Express",
      "Vary" : "Origin",
      "Access-Control-Allow-Credentials" : "true",
      "Date" : "Thu, 18 Oct 2018 17:39:20 GMT",
      "Connection" : "keep-alive"
    }
  },
  "uuid" : "1e6a0dcc-4edb-4274-a18a-9940c6250d3d",
  "persistent" : true,
  "insertionIndex" : 52
}

However, when run the test after based on this recording, it doen't find a match. When I asked mear-misses, I see this request:
{
    "nearMisses": [
        {
            "request": {
                "url": "/array/empty",
                "absoluteUrl": "http://localhost:3000/array/empty",
                "method": "PUT",
                "clientIp": "0:0:0:0:0:0:0:1",
                "headers": {
                    "Accept": "application/json",
                    "User-Agent": "python/3.6.4 (Windows-10-10.0.17763-SP0)",
                    "Connection": "keep-alive",
                    "Host": "localhost:3000",
                    "Accept-Encoding": "gzip, deflate",
                    "Content-Length": "2",
                    "Content-Type": "application/json; charset=UTF-8"
                },
                "cookies": {},
                "browserProxyRequest": false,
                "loggedDate":<PHONE_NUMBER>354,
                "bodyAsBase64": "W10=",
                "body": "[]",
                "scheme": "http",
                "host": "localhost",
                "port": 3000,
                "loggedDateString": "2018-10-18T20:18:51Z",
                "queryParams": {}
            },
            "requestPattern": {
                "url": "/array/empty",
                "method": "PUT"
            },
            "matchResult": {
                "distance": 0
            }
        }
   ]
}

Which I feel like this should match right?
I discovered that if I remove both "ignoreArrayOrder" and "ignoreExtraElements", then the recording matches perfectly and everything works.
I feel like based on the name of these options, and being that the array is empty, this should not impact the matching. Could it be possible that there is a bug somewhere that if the array is empty, these options fails the matching?
Note that I was able to reproduce too with an empty object '{}'
I'm not blocked, since removing these options make it work, but I feel like the recording should work out of the box.
Thanks!

Please post questions on the mailing list as per the README. Suggest you include a bit more detail about your setup and in particular the exact requests you made a) to record the stub, b) during your test.

@tomakehurst That's not a question, I humbly think you read too fast. When the JSON array is empty and the ignoreArrayOrder option is set, there is no matching, but it matches if I remove the option. Which doesn't make sense being than the array is empty....
Also, you ask the exact request: I copy/pasted it. The request to record will be exactly the same, that's an automatic system that trigger the same request part of a testsuite.

Actually, this might be a duplicate of https://github.com/tomakehurst/wiremock/issues/632.

@tomakehurst Sounds like a duplicate indeed, sorry I didn't find it since I used JSON syntax only...


Added madwizard-org/webauthn-server

I've added my PHP server library to the conformant server libs section, conformance test results have been submitted.

@madwizard-thomas Looks good. Could you provide a screenshot of passing conformance tests?

(it is actually 1.6.17 but the version inside the application still shows the older version)

Thanks @madwizard-thomas


Window scroller types

First PR with distributable types.

Codecov Report

Merging #915 into master will decrease coverage by 0.1%.
The diff coverage is 91.66%.

@@            Coverage Diff            @@
##           master    #915      +/-   ##
=========================================
- Coverage   90.01%   89.9%   -0.11%
=========================================
  Files          57      57
  Lines        1612    1615       +3
=========================================
+ Hits         1451    1452       +1
- Misses        161     163       +2

Impacted Files
Coverage Δ

source/WindowScroller/index.js
0% <0%> (ø)
:arrow_up:

source/WindowScroller/utils/dimensions.js
100% <100%> (ø)
:arrow_up:

source/WindowScroller/utils/onScroll.js
97.05% <85.71%> (-2.95%)
:arrow_down:

source/WindowScroller/WindowScroller.js
86.27% <95.45%> (-0.52%)
:arrow_down:

Continue to review full report at Codecov.

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


Light/Dark themes

[ ] Dark theme should be the default
[x] Switch should be in the top right corner
[ ] Set a light CodeMirror theme when global theme is light
[x] Brand color thar looks good on both light and dark theme

eae17974e13024bfd534352cd56178af07b7ea38

838c351dd147ca2a931c282c9ae48e9d064483f1

e67abfd804b18e00a1c65d6401f8bf972bf67553


Switch to another plot theme

Red is error colour, current ggplot theme has too much of it.


[JOSS] Coordination Numbers and Spheres

getCoordinationNumberSpheres()
There seem to be some code duplication in getCoordinationNumberSpheres(). The code after scale= is the same for whichever scale is chosen. Additionally, cnsp is initialized and computed, but not used in the final result.
https://github.com/AstraZeneca/kallisto/blob/4e03cd545c0badad8f0a7bfa7f935700196c6419/src/kallisto/methods.py#L102
I suggest to move the following code
https://github.com/AstraZeneca/kallisto/blob/4e03cd545c0badad8f0a7bfa7f935700196c6419/src/kallisto/methods.py#L115-L133
and call it with scale=2 and scale=3. With such changes, the code will better reflect the definition of CNSP_i^(3,2) given in the documentation.
getCoordinationNumbers()
There is some code duplication in getCoordinationNumbers
https://github.com/AstraZeneca/kallisto/blob/4e03cd545c0badad8f0a7bfa7f935700196c6419/src/kallisto/methods.py#L24-L37
However, writing a common function supporting all the different cntypes could possibly obfuscate the implementation so it is up to you if you want to unify them.
Documentation
In the documentation I'd mention how the parameters k0, k1, k2, k3 are obtained. Could you also link the  following bit of text (see Applications part) to the corresponding section?
Suggested TODOs

[ ] Remove unused cnsp calculation in getCoordinationNumberSpheres()
[ ] Merge duplicate code in getCoordinationNumberSpheres()
[ ] Mention how the parameters k0, k1, k2, k3 are obtained (in the documentation)
[ ] Link the text (see Applications part) to the corresponding section

Even better for getCoordinationNumberSpheres(), you could compute cnsp2 and cnsp3 within the same loop.

Hi @RMeli,
for a long time, I was also not happy with the name of the CNSP, as the definition is not really a sphere but rather a shell. So I have now updated this feature as "Proximity Shell" (Prox) and also added the possibility of user input via the size flag (default:  2->3). In the documentation, I have separated the CN and the Prox part accordingly. In addition, I have added how the parameters of the CN have been fitted and cleaned up some sections in the code.

Less code and more general, that's great! ;)


Docker bigchaindb creatation problem

Hardware: Intel i7, 16GB RAM, SSD drive
OS: Windows 10
Docker: Version 18.03.1-ce-win65 (17513)
Bigchaindb: Version latest
I wan't to create my own bigchaindb, steps which I did are in this file:
Create_bigchaindb_script.txt
docker-compose build > result here:
result.txt
I have tried to rebuild this but it didn't work.
Regards

@ttmc Yeah it helps! Thank you very much :)


[Feature] Add Ability to Not Include campaign_suppression_list_history Table

Is there an existing feature request for this?

[X] I have searched the existing issues

Describe the Feature
Right now you are not able to disable using the campaign_suppression_list_history like you are with some other tables via the variables section of the project.yml file. One of our customers (we use Powered by Fivetran) does not have this table as one of their source Iterable tables, and it would be good to have models that use that table either disabled or disregard that table if it doesn't exist.
Describe alternatives you've considered
No response
Are you interested in contributing this feature?

[ ] Yes.
[ ] Yes, but I will need assistance and will schedule time during your office hours for guidance.
[X] No.

Anything else?
No response

Hi @awpharr thanks so much for opening this feature request.
I think this is a great enhancement to our package and we will plan to integrate this update in the package. We will most likely pick this up in our upcoming sprint (starting 11/16).


Add support for true differential output (TLVDS)

Also:

extraction of information about the differential signal support in the pins;
changed the search system in longval tables

Signed-off-by: YRabbit<EMAIL_ADDRESS>

I agree. For tangnano 4k we don't even have a blinky:)

The simplest option would require an oscilloscope to confirm the polarity reversal of the signal. Do you think it's worth including one of these?
It is possible, of course, to check with a pair of LEDs turned on in the opposite direction to each other... hmmm... a bit tricky.
module top (
    input clk,
    output o_led_p,
    output o_led_n
);

reg [25:0] ctr_q;
wire [25:0] ctr_d;
wire i_led;

// Sequential code (flip-flop)
always @(posedge clk)
    ctr_q <= ctr_d;

// Combinational code (boolean logic)
assign ctr_d = ctr_q + 1'b1;
assign i_led = ctr_q[25:25];

TLVDS_OBUF led(
        .O(o_led_p),
        .OB(o_led_n),
        .I(i_led)
    );

endmodule

The tonegen demo already requires a scope to test so this is absolutely fine.

Done.
Although I desperately want 135MHz, I even read 1 page about PLLVR, didn't understand anything :)

All boards except NZ-1 and N-1 have these pins, but I do not have a pinout, so I just do not know the physical availability of the pins, although I know which pins of the chip itself can be used.

The generated examples work for me on tang nano 4K but do nothing on TEC0117. That is, one output is constantly low while the other is constantly high.  I wonder if the actual LVDS is broken or the counter logic is bugged leading to a constant output.
Tang nano 9K is in the country so can test that one soon.

I should note that all True LVDS pins on the tangnano4k board on the master branch are used for LEDs in the examples so here I take away two pins and reduce the number of available LEDs (not that it matters since they are all external).


Add merge property in pdb2gmx bb

Add merge property in pdb2gmx bb, needed to generate a single topology where multiple chains are merged into one moleculetype.

Solved in v3.5.1


Conflict between public and private ingress

When creating a private nginx ingress controller alongside a public one, which ever is created last seems to be the only one that works reliably, the other reports errors:
E0420 22:37:01.667729       8 reflector.go:138] k8s.io/client-go@v0.20.2/tools/cache/reflector.go:167: Failed to watch *v1.ConfigMap: failed to list *v1.ConfigMap: configmaps is forbidden: User "system:serviceaccount:ingress-nginx-internal:nginx-ingress-ingress-nginx" cannot list resource "configmaps" in API group "" at the cluster scope
E0420 22:37:22.098689       8 reflector.go:138] k8s.io/client-go@v0.20.2/tools/cache/reflector.go:167: Failed to watch *v1.Secret: failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:ingress-nginx-internal:nginx-ingress-ingress-nginx" cannot list resource "secrets" in API group "" at the cluster scope
E0420 22:37:33.598268       8 reflector.go:138] k8s.io/client-go@v0.20.2/tools/cache/reflector.go:167: Failed to watch *v1.Service: failed to list *v1.Service: services is forbidden: User "system:serviceaccount:ingress-nginx-internal:nginx-ingress-ingress-nginx" cannot list resource "services" in API group "" at the cluster scope
E0420 22:37:37.309110       8 reflector.go:138] k8s.io/client-go@v0.20.2/tools/cache/reflector.go:167: Failed to watch *v1beta1.Ingress: failed to list *v1beta1.Ingress: ingresses.networking.k8s.io is forbidden: User "system:serviceaccount:ingress-nginx-internal:nginx-ingress-ingress-nginx" cannot list resource "ingresses" in API group "networking.k8s.io" at the cluster scope
E0420 22:37:46.030503       8 reflector.go:138] k8s.io/client-go@v0.20.2/tools/cache/reflector.go:167: Failed to watch *v1.Endpoints: failed to list *v1.Endpoints: endpoints is forbidden: User "system:serviceaccount:ingress-nginx-internal:nginx-ingress-ingress-nginx" cannot list resource "endpoints" in API group "" at the cluster scope
Config used:
helm install nginx-ingress ingress-nginx/ingress-nginx   --namespace ingress-nginx-external
--set controller.ingressClass=nginx   --set controller.replicaCount=2
--set controller.nodeSelector."beta.kubernetes.io/os"=linux   --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux
--set controller.admissionWebhooks.patch.nodeSelector."beta.kubernetes.io/os"=linux   --set controller.publishService.enabled=true
--set controller.publishService.pathOverride=ingress-nginx-external/nginx-ingress-ingress-nginx-controller
helm install nginx-ingress ingress-nginx/ingress-nginx     --namespace ingress-nginx-internal
-f ../k8s/networking/internal-ingress.yaml     --set controller.ingressClass=nginx-int
--set controller.replicaCount=2     --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux
--set defaultBackend.nodeSelector."beta.kubernetes.io/os"=linux `
--set controller.admissionWebhooks.patch.nodeSelector."beta.kubernetes.io/os"=linux

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 1bf9c2f3-caeb-0fb1-f089-3f7ca4fad729
Version Independent ID: 929253d7-c763-6429-561f-529d39b5284d
Content: Ingress controller on internal network - Azure Kubernetes Service
Content Source: articles/aks/ingress-internal-ip.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: mlearned

@NBroomfield Thank you for sharing your query! We are currently investigating and will get back to you shortly on this.

@psmanhas Thanks, I've done a bit more digging and same across this stack overflow article which mentions the same errors I'm seeing:
https://stackoverflow.com/questions/64032639/how-to-update-nginx-ingress-controller-so-that-latest-ingress-paths-are-used
I've run the following command:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --serviceaccount=ingress-nginx-internal:nginx-ingress-ingress-nginx
Which seems to have resolved the issue however I don't think it's should be necessary, for some reason setting up two ingress controllers seems to cause an issue, it's almost as if the setting up the second controller overwrites the permissions that the first controller requires.

@NBroomfield Thank you for sharing out the information and really glad that your issue is resolved . I have shared your feedback with our internal team so they can look into issue and make changes as per the requirement.
We will now close this issue. If there are further questions regarding this, please tag me in a comment. I will reopen it and we will continue the discussion.
Thanks


ENH: Make type hinting compatible with Python 3.9

Make type hinting compatible with Python 3.9: use Union instead of the pipe operator | to support type hints in Python 3.9. The pipe operator was overloaded for writing union types starting Python 3.10: https://peps.python.org/pep-0604/
https://docs.python.org/3.9/library/typing.html
https://docs.python.org/3.10/library/typing.html
Inadvertently let go through in commits 44d0ff6 and 8c18471.

Sorry Chris, my bad, I did not pay due attention to the failures in PR #147.

Looks good! I started on this locally, but didn't finish and push. Thanks for cleaning it up!


Engine -> Framework roll blocked on new analyzer messages

Starting with the roll in https://github.com/flutter/flutter/pull/99222, analysis of samples is giving unexpected analyzer messages. That Engine roll contains only the Dart roll https://github.com/flutter/engine/pull/31702, which contains only the commit https://dart.googlesource.com/sdk.git/+/2f9d45b8bf9e5843acb94996e193e1a6fdf2da8b that modifies the text of the messages.
Here is one of the failing runs https://ci.chromium.org/ui/p/flutter/builders/try/Linux framework_tests_misc/13676/overview

I have reverted the Dart roll, and stopped the Dart -> Engine roller.
@bwilkerson

First question: how can I update the messages in the tests to unblock the roll? (I know virtually nothing about Flutter's test framework.)
Second question: can we change the tests so that it's possible for us to improve the UX without breaking the tests. For example, can we remove the messages entirely and just depend on the codes associated with the diagnostics without hurting the usefulness of the tests?

I think @gspencergoog might know more about how the samples are analyzed.

I think we need more guidance on how to solve problems like this. If there is no way to roll changes that break a framework test, then what is the recommended solution?
Must the Dart CL author create a framework change that temporarily deletes or disables the test, or can they make a change that fixes the test, and it will land simultaneously with the roll?
There is nobody assigned on this issue, so I don't know if it must urgently be fixed or not, and who is responsible for fixing it.

@whesse As far as I know, we don't have a way to roll the SDK directly into the framework, only through the engine, and the engine runs the framework tests before it will roll into the framework. To make this work, we'd have to manually roll both the engine and the SDK in the framework simultaneously, and since they're in different repos, I don't think that's possible.
I'm happy to author the PRs in this case if that is easier.  I assume we'll have to disable the test until the SDK rolls, and then re-enable it with changes after the roll. @bwilkerson would you like me to do that?

@jason-simmons has https://github.com/flutter/flutter/pull/99281 up. Like in that PR, the nature of the failure shows how to do the soft-transition. Maybe @devoncarew or @jacob314 knows whether the sample analysis is happening on Dart's Flutter analysis bot.

I'm happy to author the PRs in this case if that is easier.

That would certainly be faster, so I'm happy to let you do it.

... whether the sample analysis is happening on Dart's Flutter analysis bot.

It is not. See https://ci.chromium.org/p/dart/builders/ci.sandbox/flutter-analyze.

Looks like Jason already has a workaround PR.  I'll follow up with a PR that makes the test less fragile.  This could still happen again if an analysis option affecting the test were removed, but that's pretty unlikely, I suspect.

The rollers have recovered.


ip vrf exec fails with BPF error

Describe the bug
ip vrf exec is used to run commands inside a vrf-lite (thanks CumulusNetworks). It's really just multiple active routing tables, but without network namespaces.
Steps To Reproduce
Steps to reproduce the behavior:
Script started on 2021-11-12 20:27:09+01:00 [TERM="screen" TTY="/dev/pts/3" COLUMNS="96" LINES="51"]
➜  ~ ip vrf list
Name              Table
-----------------------
vpn               1337
➜  ~ ip vrf exec vpn ping <IP_ADDRESS>
Failed to load BPF prog: 'Operation not permitted'
➜  ~ sudo ip vrf exec vpn ping <IP_ADDRESS>
[sudo] password for lillecarl:
Failed to load BPF prog: 'Operation not permitted'
➜  ~ exit

Script done on 2021-11-12 20:27:31+01:00 [COMMAND_EXIT_CODE="255"]

  systemd = {
    network = {
      enable = true;
      netdevs."vpn" = {
        enable = true;
        vrfConfig = {
          Table = 1337;
        };
        netdevConfig = {
          Kind = "vrf";
          Name = "vpn";
        };
      };
    };
  };

Expected behavior
An error saying no route to host, unless you have routes in the VRF
Screenshots
Additional context
VRF means Virtual Routing and Forwarding. Having multiple routing tables is an essential feature to any router. It is also useful for a system running as a hypervisor, since you (like with VLANs) can isolate networks, but on layer 3 rather than layer 2.
Notify maintainers

Not entirely sure who to ping here, could be kernel, could be userspace.
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.76, NixOS, 21.05.3990.372e59d2af7 (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.16`
 - channels(root): `"nixos-21.05.3990.372e59d2af7, nixos-hardware, unstable-21.11pre327669.b67e752c29f"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:
not:
  sure: 1

Have not tested nixos-unstable.

I upgraded the kernel to 5.15.0 and it worked

@Anillc I can't go that high yet because of evdi and other kernel modules. But great to know, I'll leave this open until a stable release has this resolved.

Don't you need a higher memlock for ip vrf exec?
I have
{
  security.pam.loginLimits = [
    { domain = "*"; item = "memlock"; type = "-"; value = 8192; }
  ];
}

@Ma27 That resolved the issue straight away, just a NixOS reload. Thank you. I don't think the issue is resolved however, I'm not sure if we should have to set this configuration ourselves or "have someone do it for us"

I actually had similar issues when I moved to a 5.x Kernel a while ago, it was clarified by the kernel developers that this is expected behavior<EMAIL_ADDRESS>

I can work around the issue by using ip vrf exec. However I get the
following error (unless I run ulimit -l 2048):
Failed to load BPF prog: 'Operation not permitted'

'ip vrf exec' loads a bpf program and that requires locked memory, so
yes, you need to increase it.

@Ma27 Is it sane defaults to keep this at 0 though? With Debian and Ubuntu I haven't seen this issue.
In a never version of the iputils it seems the error message is clearer though.

According to https://man7.org/linux/man-pages/man8/ip-vrf.8.html, you need to have CAP_SYS_ADMIN, CAP_NET_ADMIN and CAP_DAC_OVERRIDE capabilities for successfull run ip vrf exec code.
The same case with systemd unit runing with ExecStart=ip vrf exec - when run by hand all works and systemd fault with ip[]: Failed to load BPF prog: 'Operation not permitted' message

What does "when run by hand mean"? Which user did you use? Did you use sudo? Did you increase the memlock before?
Also, please share the full unit including the logs, a single ExecStart isn't really helpful.

What does "when run by hand mean"? Which user did you use? Did you use sudo?

By hand I mean run 'ip vrf exec' in system shell. root user or sudo user - there is not matter.

Did you increase the memlock before?

no of course. memlock reason will provide segmentation fault. Try to set ulimits -s 0 and run ip vrf exec.

Also, please share the full unit including the logs, a single ExecStart isn't really helpful.

# systemctl cat<EMAIL_ADDRESS>#<EMAIL_ADDRESS>[Unit]
Description=OpenVPN tunnel for %I
After=network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/client
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process

[Install]
WantedBy=multi-user.target

#<EMAIL_ADDRESS>### Editing<EMAIL_ADDRESS>### Anything between here and the comment below will become the new contents of the file

### Lines below this comment will be discarded

###<EMAIL_ADDRESS># [Unit]
# Description=OpenVPN tunnel for %I
# After=network-online.target
# Wants=network-online.target
# Documentation=man:openvpn(8)
# Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
# Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
#
[Service]
# Type=notify
# PrivateTmp=true
# WorkingDirectory=/etc/openvpn/client
ExecStart=
ExecStart=/usr/sbin/ip vrf exec %i /usr/sbin/openvpn --suppress-timestamps --nobind --cd /etc/openvpn --config /etc/openvpn/client/%i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE BPF_PROG_LOAD BPF_PROG_ATTACH CGROUP_BPF CAP_SYS_ADMIN CAP_DAC_OVERRIDE
# LimitNPROC=10
# DeviceAllow=/dev/null rw
# DeviceAllow=/dev/net/tun rw
# ProtectSystem=true
# ProtectHome=true
# KillMode=process
#
# [Install]
# WantedBy=multi-user.target

I use mpls l3vpn with FRR (FRRouting). Sometimes need up shit-tunnels over openvpn (even normal interfaces does not work). I need here in the first use right vrf for outgoing connection, in the second change new tunnel to target vrf. This is made with NetworkManager dispatcher.

By hand I mean run 'ip vrf exec' in system shell. root user or sudo user - there is not matter.

If it works for these kinds of users, can you please share your limits.conf then?

no of course. memlock reason will provide segmentation fault. Try to set ulimits -s 0 and run ip vrf exec.

I don't understand what you mean. Also, why ulimit -s? And why 0?
You're decreasing the stack-size of your current shell to 0 which obviously results in a segfault, I suggested to increase the memlock to a higher value.
Regarding your systemd unit: considering that you're using /usr/sbin/ which system are you on? And is iputils installed with Nix?

If it works for these kinds of users, can you please share your limits.conf then?

My limits.conf is default for ubuntu 21.04
# cat /etc/security/limits.conf | grep -v "^#"
#

ulimit -s is 8192, -l is 630821

Also, why ulimit -s? And why 0?

sorry, my mistake -). Speaking upper about -l.

Regarding your systemd unit: considering that you're using /usr/sbin/ which system are you on? And is iputils installed with Nix because it's also from /usr/sbin.

# whereis ip
ip: /usr/bin/ip /usr/sbin/ip /usr/share/man/man8/ip.8.gz /usr/share/man/man7/ip.7.gz
# which ip
/usr/sbin/ip
# ip -V
ip utility, iproute2-5.9.0, libbpf 0.3.0

Anyway Failed to load BPF prog: 'Operation not permitted' not about memory. This is about permittions and BPF.

Anyway Failed to load BPF prog: 'Operation not permitted' not about memory. This is about permittions and BPF.

It actually is, please read the kernel thread I linked above if you'd like to know more.
However, I don't think we can really fix something for you considering that you don't seem to be using Nix/NixOS and this is the issue tracker for these projects.

People experiencing the same problem will find this because Github SEO is amazing.
https://github.com/NixOS/nixpkgs/issues/145673#issuecomment-992930602 is the answer.


Svprimlit integral

Adding the  "option" in order to allow support for both 4-state and 2-state integrals (any necessary changes in the methods are also made). The previous testcases are treated as 2-state and new test cases are added for testing the performance of 4-state.

Important problems that must be addressed:

By default all usize should be converted in 4-state SvPrimalyLiteralIntegral

Operations between 2- and 4- state  SvPrimaryLiteralIntegrals should lead to a conversion of the 2-state struct into "equivalent" an 4-state struct prior to the operation taking place.

At the moment the implementation of is_zero cannot be based on == since cmp does not support a comparison between signed and unsigned. That was not an issue with is_negative since that case always involved a comparison between two signed integral primary literals.

Currently assert_eq does not examine the contents of data_xz since the cmp trait does not support 4-state integral primary literals. That is not significant since assert_eq is complementary to the main string assertion (display assertion).

Currently adding support for 4-state (both xz and non xz) primary integrals in the following methods:

[ ] 1) LSL
[ ] 2) LSR
[ ] 3) ROL
[ ] 4) ROR
[ ] 5) CAT

Bug found in LSL: Example 01.....00
If signed LSL by 1 would produce 1....0 instead of 0 1...0 (despite that the final nu of bits is correctly specified).

Bug found in LSL: Example 01.....00 If signed, LSL by 1 would produce 1....0 instead of 0 1...0 (despite that the final nu of bits is correctly specified).

Fixed.

Bug fixed in ROR: The LSB shifted out during LSR wasn't shifted in the MSB position declared by size but instead at =usize::BITS.

If we want to cat a 4-state sv prim lit with a 2-state sv primary literal, then the 2-state will be treated as 4-state and the result will be a 4-state integral primary literal.

The following changes will be placed in a separate PR:

New lt,gt,eq implementations that allow partial comparison (4-state (X/Z/Non) with 2-state and signed with unsigned)

New addition and multiplication implementations that supports 4-state integral primary literals that contain X/Z

New neg implementation based on (1) and (2)

New inv implementation based on the LRM specification

Implement "operator overflows" in all the relative methods

Add as many traits as possible in (5) e.g addition between integral prim lit and u32/u16/u8 etc.

This PR is ready to be merged.


Create login method

Login method has been modified and now prevents the user from logging in if:
(1) They provide incorrect credentials;
(2) They fail to input anything into the username and/or password fields.
Additional considerations will be made in the form of exception handling.


Bump BouncyCastle from 1.67 to 1.77

:mag: Description
Issue References 🔗
They have stopped patching the JDK 1.5 jars that Hadoop uses (see HADOOP-18540).
The new artifacts have similar names - but the names are like bcprov-jdk18on as opposed to bcprov-jdk15on.
CVE-2023-33201 is an example of a security issue that seems only to be fixed in the JDK 1.8 artifacts (ie no JDK 1.5 jar has the fix).
https://www.bouncycastle.org/releasenotes.html#r1rv77 latest current release but the CVE was fixed in 1.74.
To be clear, Kyuubi only uses BouncyCastle for testing, the CVE does not affect Kyuubi distribution.
Describe Your Solution 🔧
Bump BouncyCastle from 1.67 to 1.77, and change the artifactId from *-jdk15on to *jdk18on.
Types of changes :bookmark:

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Test Plan 🧪
Pass GA.

Checklist 📝

[x] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

Thanks, merged to master


Correction for raw affiliation Latin American Research Centre #R##N#University of Calgary

Correction needed for raw affiliation Latin American Research Centre #R##N#University of Calgary
raw_affiliation_name: Latin American Research Centre #R##N#University of Calgary
new_rors: 03yjb2x39
previous_rors:
works_examples: W2286027814
contact: edeb9979c5de5095e754278bdfd7530a:991e0077 @ ourresearch.org

This issue was accepted and ingested by the OpenAlex team on 2024-10-09. The new affiliations should be visible within the next 7 days.


common: Remove dummy package

Description
This was just used for testing. Not needed any more.
Summary:

Related Issue:

Testing

Screenshots/GIFs (if applicable)

Checklist

[x] My code follows the project's coding standards.
[x] Prefixed the PR title and commit messages with the service or package name
[x] I have written unit tests (if applicable).
[x] I have updated the documentation (if applicable).
[x] By submitting this pull request, I confirm that my contribution is made
under the terms of the MIT license.

Additional Information

Looks good. I guess we should manually remove it from npm also?

Yes, we need to do that manually.


Lastest React 15.4.0 breaks running test

The latest React release moved the last remnants of dom related code to react-dom.
Running chai-enzyme breaks with the following error
Error: Cannot find module 'react/lib/ReactTestUtils'
    at Function.Module._resolveFilename (module.js:327:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:355:17)
    at require (internal/module.js:13:17)
    at Object.<anonymous> (./node_modules/chai-enzyme/node_modules/react-addons-test-utils/index.js:1:-44)

Changing the incriminated line to
 module.exports = require('react-dom/lib/ReactTestUtils');
makes it work but it might have other implications.
refs #https://github.com/facebook/react/issues/8314

react-addons-test-utils should be both a devDependency and a peerDependency of chai-enzyme, and like react and react-dom (which should also be peerDeps + devDeps), should match your react version.
If all three are on 15.4, you won't have a problem.

@ljharb do you recommend pinning react-addons-test-utils, react & react-dom in both devDependencies & peerDependencies to ^15.4.0-0 and releasing a new chai-enzyme version?
More context: https://github.com/algolia/react-element-to-jsx-string/issues/56

@ayrton Separate from the react-element-to-jsx-string issue, I'd say that all three of those libs should have as wide a semver range in peerDeps as possible (ideally allowing ^0.14 - ^15), and a compatible ^ range in devDeps (all three the same). I don't think it needs to be pinned; and RC versions shouldn't be that much of a concern, but if the semver range can include it, more the better.

As for react-element-to-jsx-string, this is now fixed on our side.

@ljharb confirmed in #130 that this fixes the issue above
@vvo thanks
Will release a new version soon.


How to create user_data_dir roaming folder without appauthor directory?

I would like to generate a user data dir without the appauthor directory.
My code looks like this:
from platformdirs import *

path = user_data_dir("TestApp", appauthor=None, roaming=True)
print(path)

And prints out: C:\Users\Clemens\AppData\Roaming\TestApp\TestApp
I would like it to omit the "TestApp" directory so that it prints out: C:\Users\Clemens\AppData\Roaming\TestApp
How can I achieve this?
I could simply manually remove the last subdirectory but that doesn't really seem like a good solution to me

Solution is to pass "False" to appauthor, not "None"
user_data_dir("TestApp", appauthor=False, roaming=True)


[Task]: Remove old migrations

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks
Since we have defined the upgrade path, we should remove old migrations (before that point) because,

Keeping old migrations leads to delay in startup, it doesn't affect server but the test cases because for every test class spring creates a context and the delay in startup magnifies.
By doing this we can get rid defunct code and fields which are no longer used in code but kept just because migrations depend on them.
Over time the behavior of old migrations changes as the functions used in migrations change, this may lead to migrations that no longer do what it was intended to do and then there is no point in keeping them.

@nidhi-nair for your thoughts.

Thanks for bringing this up again Sidhant! <3 Let's plan for this to go out with a 1-3 months notice for users, I think they face some trouble with making sure of their upgrade path when there is a shorter notice.


Support for comments

As follow-up for #99, this issue is about adding optional support for comment nodes.
As @maciejhirsz suggested, comments should be gathered by the lexer as internal list.
This way, f.e. all comments of a function can be pulled before the declaration.
Please note that there are three types of valid comments in JavaScript:

Line comments // foo
Block comments /* bar */
HTML comments <!-- baz --> (:angry:)

If you want to support not only comments, but white space as well, and in general support loseless syntax trees, I suggest taking a look at Swift’s libsyntax architecture:
https://github.com/apple/swift/tree/master/lib/Syntax.
This might not be what you want though: such full fidelity syntax trees are heavier than ASTs.

Oh this is clever! I like the idea of trivia being attached to nodes, I wouldn't necessarily do it on every node (although, given how fast Ratel is, it might not be that much of a burden), but doing it on things like functions should be sufficient. It would require some re-parsing of comments, but then any tool that wants to read documentation or JSDoc types from comments is likely going to have to parse those in full anyway.

BTW, I have a crate with implenets a similar flavor of syntax trees here: https://github.com/rust-analyzer/rowan
It's main focus is loselessness, and not perf, so it has a ton of indirection and allocation.


FontUtils V2

hey i was not able to fownd herocode's fontutils that have the drawHeightCenteredString methed in it.
please send it.

public void drawHeightCenteredString(String text, float x, float y, int color) {
drawString(text, x, y - getFontHeight() / 2f, color);
}


Installing dependencies natively on Ubuntu without docker

Are you using a virtual machine or are you using native Ubuntu?
I am using a Parallels Desktop on a MacOS M1 chip.

**If you are using macOS and a virtual machine, does your computer use an M1, M2, ... chip?

MacOs with M1 chip. But I will be using Parallels Desktop and work with Ubuntu 20.04

Which Ubuntu version are you using? (lsb_release -a in a terminal)

No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.6 LTS
Release:	20.04
Codename:	focal
Since I am already using a virtual machine to run Ubuntu 20.04 I don't want to install docker inside this Ubuntu Image. So is there a script file that will install all the dependencies?
I tried to use the DockerFile and install almost everything. But when I do catkin build in the workspace, I get the following error from the ct_models package. Please help resolve this.

Hi,
it's a problem related to the file system used by macOS.
The package control-toolbox contains case-sensitive files, but the default macOS file system is case-insensitive. Hence, the following, packages won't compile: ct_models, ct_doc, trajectory_planner. Affected exercises are

Section 4 Vehicle Guidance - ROS Trajectory Planning
Section 4 Vehicle Guidance - ROS Trajectory Control

A workaround would be to create a case-sensitive Volume in MacOS and mount it with Parallels. Please refer to the following guides.

https://brianboyko.medium.com/a-case-sensitive-src-folder-for-mac-programmers-176cc82a3830
https://docs.spryker.com/docs/scos/dev/tutorials-and-howtos/howtos/howto-handle-case-sensitive-file-system-on-mac-os.html

Please let us know if that worked for you.
Best regards,
Till

Thank you very much for the quick response. I tried creating a case-sensitive volume and still I have the same issue.
Also, one other doubt. I also tried copying the files to my ubuntu desktop (not mounting any volumes, just copying the files) and then building the files like we would do in a native ubuntu system. That also doesn't work. Is it because I am running on a virtual machine?

Please delete the folder acdc_ws and pull the repositories again on the case-sensitive volume. If you have just moved the code, then the files that were missing previously will still be missing. Hence, you need to pull the code again.
Make sure that this file can be found in your local directory:
https://github.com/ethz-adrl/control-toolbox/blob/v3.0.2/ct_core/include/ct/core/Common
Let me know if that helps.
Bests,
Till

@TillBeemelmanns  Thank you very much. Apparently, the Common file that you mentioned was missing. So I pulled the files again as you mentioned and now the ct_models package is able to build.
However, not the tensorflow_cpp file is not able to be built. I made sure to install TensorFlow. Can you help resolve this issue?

Finally, I was able to resolve the issue. I've made a few changes to make it all work. To preface the changes, here are the details of my system.
PC: Apple M1 running Parallels Desktop which runs Ubuntu 20.04 and ROS Noetic.
Solving the issue with tensorflow_cpp
I had to follow the install instructions for libtensorflow_cc from here. I installed the CPU version since I did not have a dedicated Nvidia GPU.
Following this, I was able to successfully build the tensorflow_cpp package.
The next issue
I got the following error because the packages lidar_detection and pointcloud_ogm packages were compelling with C++ 14.

So, I added add_compile_options(-std=c++17) to the CMakeLists.txt file of both packages. After this the lidar_detection package was able to build but the pointcloud_ogm package was not. It threw the following error.

So I had to edit the FunctorsPlugin.hpp from the source installation manually and add the missing ; in the locations mentioned in the error. After this, everything was able to build completely as expected.

Glad that you could resolve the issue! Please note, that we are currently working on the repository and we will publish a refreshed setup / docker images on the beginning of the ACDC course in approx. two weeks.

Thank you. I look forward to the updated setup instructions.


Not working with Jackson 2.12.x

In our application we updated from jackson 2.11.3 to 2.12.1 recently. Once we did this, ./gradlew resolve stopped working, showing this exception:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':api:resolve'.
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:200)
        at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:263)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:198)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:179)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109)
        at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:76)
        at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:76)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
        at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:41)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:372)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:359)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:352)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:338)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: org.gradle.api.GradleException
        at io.swagger.v3.plugins.gradle.tasks.ResolveTask.resolve(ResolveTask.java:426)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:51)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:29)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$3.run(ExecuteActionsTaskExecuter.java:555)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:56)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$run$1(DefaultBuildOperationExecutor.java:71)
        at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.runWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:45)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:71)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:540)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:523)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$300(ExecuteActionsTaskExecuter.java:108)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.executeWithPreviousOutputFiles(ExecuteActionsTaskExecuter.java:271)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:260)
        at org.gradle.internal.execution.steps.ExecuteStep.lambda$execute$1(ExecuteStep.java:34)
        at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:34)
        at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:26)
        at org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:67)
        at org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:36)
        at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:49)
        at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:34)
        at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:43)
        at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:73)
        at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:54)
        at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:44)
        at org.gradle.internal.execution.steps.SnapshotOutputsStep.execute(SnapshotOutputsStep.java:54)
        at org.gradle.internal.execution.steps.SnapshotOutputsStep.execute(SnapshotOutputsStep.java:38)
        at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:42)
        at org.gradle.internal.execution.steps.CacheStep.executeWithoutCache(CacheStep.java:159)
        at org.gradle.internal.execution.steps.CacheStep.execute(CacheStep.java:72)
        at org.gradle.internal.execution.steps.CacheStep.execute(CacheStep.java:43)
        at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:44)
        at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:33)
        at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:38)
        at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:24)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:92)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$0(SkipUpToDateStep.java:85)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:55)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:39)
        at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:76)
        at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:37)
        at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:36)
        at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:26)
        at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:94)
        at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:49)
        at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:79)
        at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:53)
        at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:74)
        at org.gradle.internal.execution.steps.SkipEmptyWorkStep.lambda$execute$2(SkipEmptyWorkStep.java:78)
        at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:78)
        at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:34)
        at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:39)
        at org.gradle.internal.execution.steps.LoadExecutionStateStep.execute(LoadExecutionStateStep.java:40)
        at org.gradle.internal.execution.steps.LoadExecutionStateStep.execute(LoadExecutionStateStep.java:28)
        at org.gradle.internal.execution.impl.DefaultWorkExecutor.execute(DefaultWorkExecutor.java:33)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:187)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:179)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109)
        at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:76)
        at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:76)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
        at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:41)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:372)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:359)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:352)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:338)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at io.swagger.v3.plugins.gradle.tasks.ResolveTask.resolve(ResolveTask.java:413)
        ... 98 more
Caused by: java.lang.NoSuchMethodError: 'com.fasterxml.jackson.core.util.JacksonFeatureSet com.fasterxml.jackson.core.JsonParser.getReadCapabilities()'
        at com.fasterxml.jackson.databind.DeserializationContext.<init>(DeserializationContext.java:211)
        at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.<init>(DefaultDeserializationContext.java:50)
        at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext$Impl.<init>(DefaultDeserializationContext.java:391)
        at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext$Impl.createInstance(DefaultDeserializationContext.java:413)
        at com.fasterxml.jackson.databind.ObjectMapper.createDeserializationContext(ObjectMapper.java:4654)
        at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4583)
        at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3546)
        at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3514)
        at io.swagger.v3.oas.integration.ContextUtils.deepCopy(ContextUtils.java:18)
        at io.swagger.v3.oas.integration.GenericOpenApiContext.init(GenericOpenApiContext.java:417)
        at io.swagger.v3.oas.integration.GenericOpenApiContext.init(GenericOpenApiContext.java:41)
        at io.swagger.v3.jaxrs2.integration.JaxrsOpenApiContextBuilder.buildContext(JaxrsOpenApiContextBuilder.java:44)
        at io.swagger.v3.jaxrs2.integration.SwaggerLoader.resolve(SwaggerLoader.java:234)
        ... 102 more

Reverting to 2.11.3 fixes the issue.

the reported issue seems to be related to some version mismatch with Jackson deps, looking at Caused by: java.lang.NoSuchMethodError: 'com.fasterxml.jackson.core.util.JacksonFeatureSet com.fasterxml.jackson.core.JsonParser.getReadCapabilities()' Please make sure you have the same Jackson version across all Jackson artifacts. If this solved the issue please close ticket

the reported issue seems to be related to some version mismatch with Jackson deps, looking at Caused by: java.lang.NoSuchMethodError: 'com.fasterxml.jackson.core.util.JacksonFeatureSet com.fasterxml.jackson.core.JsonParser.getReadCapabilities()' Please make sure you have the same Jackson version across all Jackson artifacts. If this solved the issue please close ticket

That was the first thing I did :) The application as well as all tests, etc. work fine, all jackson artifacts have a single version (2.12.1).

That was the first thing I did :) The application as well as all tests, etc. work fine, all jackson artifacts have a single version (2.12.1).

Right, can you possibly share a test case reproducing the issue?

Right, can you possibly share a test case reproducing the issue?

You could have a look at https://github.com/bdeployteam/bdeploy - git clone it, cd api && ../gradlew resolve should reproduce the issue, even though it is 2.12.0 instead of 2.12.1 on the branch currently... I don't have a smaller example right now. I'll dig into it some more...

You could have a look at https://github.com/bdeployteam/bdeploy - git clone it, cd api && ../gradlew resolve should reproduce the issue, even though it is 2.12.0 instead of 2.12.1 on the branch currently... I don't have a smaller example right now. I'll dig into it some more...

If I add this to the api/build.gradle file, which has the swagger plugin applied, it works with 2.12.1:
dependencies {
    ... <existing content>
    swaggerDeps(
        'com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.12.1',
        'com.fasterxml.jackson.datatype:jackson-datatype-jdk8:2.12.1',
        'com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.12.1',
        'org.apache.commons:commons-lang3:3.7',
        'io.swagger.core.v3:swagger-jaxrs2:2.1.6',
        'javax.ws.rs:javax.ws.rs-api:2.1',
    )
}

So it seems that the final classpath is made up of the "normal" application classpath and the swaggerDeps group, which contains (indenendent of what I configure for our application) jackson 2.11.x as transitive dependency. The final classpath ends up with a mix of both, even though both groups (application and swagger) seem to be consistent in either using all 2.11.x or all 2.12.x...

If I add this to the api/build.gradle file, which has the swagger plugin applied, it works with 2.12.1:
dependencies {
    ... <existing content>
    swaggerDeps(
        'com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.12.1',
        'com.fasterxml.jackson.datatype:jackson-datatype-jdk8:2.12.1',
        'com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.12.1',
        'org.apache.commons:commons-lang3:3.7',
        'io.swagger.core.v3:swagger-jaxrs2:2.1.6',
        'javax.ws.rs:javax.ws.rs-api:2.1',
    )
}

So it seems that the final classpath is made up of the "normal" application classpath and the swaggerDeps group, which contains (indenendent of what I configure for our application) jackson 2.11.x as transitive dependency. The final classpath ends up with a mix of both, even though both groups (application and swagger) seem to be consistent in either using all 2.11.x or all 2.12.x...

I am possibly getting a bit lost with your example (a dedicated one would help if possible), specifically not sure I get  however I have to hard-code the rest of the dependencies as well as I don't know how to just add to the swaggerDeps instead.
In any case the resolve task defines the classpath parameter and asically uses as classpath whatever you pass there, therefore if jackson version 2.12 is defined in classpath, that version will be used

I am possibly getting a bit lost with your example (a dedicated one would help if possible), specifically not sure I get  however I have to hard-code the rest of the dependencies as well as I don't know how to just add to the swaggerDeps instead.
In any case the resolve task defines the classpath parameter and asically uses as classpath whatever you pass there, therefore if jackson version 2.12 is defined in classpath, that version will be used

That is a little different from my observation, as can be seen in the two text files I attached. It seems that the plugin uses the classpath as well as some parts of its own classpath, which results in a mix of versions. Even though the classpath of my application only uses 2.12.x versions, the swagger plugin sneaks in a 2.11.x version somehow. Once i force the swaggerDeps to include 2.12.x as well everything works as expected.
I will try to put together an example somehow.

That is a little different from my observation, as can be seen in the two text files I attached. It seems that the plugin uses the classpath as well as some parts of its own classpath, which results in a mix of versions. Even though the classpath of my application only uses 2.12.x versions, the swagger plugin sneaks in a 2.11.x version somehow. Once i force the swaggerDeps to include 2.12.x as well everything works as expected.
I will try to put together an example somehow.

Yes you're right, still if you have defined all jackson artifacts with 2.12 version in sourceSets.main.runtimeClasspath (outside swaggerDeps), in theory the 2.12 ones would be used.
If this is not true however, the possible "right way" is removing the swaggerDeps section, and adding buildClasspath parameter to the resolve task, like:
resolve {
    outputFileName = 'BDeployAPI'
    outputFormat = 'YAML'
    classpath = sourceSets.main.runtimeClasspath
    buildClasspath = classpath
    outputDir = file("${buildDir}/openapi")
    readAllResources = false
    resourceClasses = [
        'io.bdeploy.api.remote.v1.PublicRootResource',
    ]
}

Please give it a try

Yes you're right, still if you have defined all jackson artifacts with 2.12 version in sourceSets.main.runtimeClasspath (outside swaggerDeps), in theory the 2.12 ones would be used.
If this is not true however, the possible "right way" is removing the swaggerDeps section, and adding buildClasspath parameter to the resolve task, like:
resolve {
    outputFileName = 'BDeployAPI'
    outputFormat = 'YAML'
    classpath = sourceSets.main.runtimeClasspath
    buildClasspath = classpath
    outputDir = file("${buildDir}/openapi")
    readAllResources = false
    resourceClasses = [
        'io.bdeploy.api.remote.v1.PublicRootResource',
    ]
}

Please give it a try

I will try that right now. In the meantime, here is a small example that reproduces the problem for your investigation :)
test.zip

I will try that right now. In the meantime, here is a small example that reproduces the problem for your investigation :)
test.zip

resolve {
    outputFileName = 'BDeployAPI'
    outputFormat = 'YAML'
    classpath = sourceSets.main.runtimeClasspath
    buildClasspath = classpath
    outputDir = file("${buildDir}/openapi")
    readAllResources = false
    resourceClasses = [
        'io.bdeploy.api.remote.v1.PublicRootResource',
    ]
}

If i try this (adding buildClasspath = classpath) I start getting errors because the SwaggerLoader class itself cannot be found - I assume because swagger is not part of my classpath at all - I only have the annotations on the classpath...

resolve {
    outputFileName = 'BDeployAPI'
    outputFormat = 'YAML'
    classpath = sourceSets.main.runtimeClasspath
    buildClasspath = classpath
    outputDir = file("${buildDir}/openapi")
    readAllResources = false
    resourceClasses = [
        'io.bdeploy.api.remote.v1.PublicRootResource',
    ]
}

If i try this (adding buildClasspath = classpath) I start getting errors because the SwaggerLoader class itself cannot be found - I assume because swagger is not part of my classpath at all - I only have the annotations on the classpath...

yes, buildClasspath is defined by the plugin for this reason (it adds swagger-jaxrs2 and a few more deps), which are added to the set defined in classpath; passing to classpath parameter one including the needed libs (e.g. extending sourceSet) would make them available to the task (or passing to buildClasspath just the ones missing

yes, buildClasspath is defined by the plugin for this reason (it adds swagger-jaxrs2 and a few more deps), which are added to the set defined in classpath; passing to classpath parameter one including the needed libs (e.g. extending sourceSet) would make them available to the task (or passing to buildClasspath just the ones missing

This is working again with 2.12.3


regressiontpcds 1T plan shape check

Proposed changes
add regression case to check tpcds 1t plan shape
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run buildall

run buildall

run clickbench


[doc] improve documentation WOODPECKER_SESSION_EXPIRES

just a small contribution, since I did wonder what it meant.

@pat-s thanks for your review.
If you don't mind, I would appreciate a 'hacktoberfest-accepted' label ;)


[Forward port main] fixing dls/fls logic around numeric aggregations

Forward port https://github.com/opensearch-project/anomaly-detection/commit/44de1c47392efa1517f13bc329bd82fb0ebbe8e0 from #787
Signed-off-by: Kaituo Li<EMAIL_ADDRESS>By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #801 (4f985d4) into main (9cebc5b) will decrease coverage by 0.32%.
The diff coverage is 69.17%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@             Coverage Diff              @@
##               main     #801      +/-   ##
============================================
- Coverage     79.61%   79.29%   -0.32%
+ Complexity     4301     4288      -13
============================================
  Files           302      306       +4
  Lines         17972    18092     +120
  Branches       1894     1889       -5
============================================
+ Hits          14308    14346      +38
- Misses         2763     2833      +70
- Partials        901      913      +12

Flag
Coverage Δ

plugin
79.29% <69.17%> (-0.32%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...est/handler/IndexAnomalyDetectorActionHandler.java
100.00% <ø> (ø)

.../ad/rest/handler/ModelValidationActionHandler.java
0.00% <0.00%> (ø)

.../handler/ValidateAnomalyDetectorActionHandler.java
100.00% <ø> (ø)

...c/main/java/org/opensearch/ad/util/ParseUtils.java
77.85% <ø> (ø)

...rc/main/java/org/opensearch/ad/util/Throttler.java
80.00% <0.00%> (-20.00%)
:arrow_down:

...rg/opensearch/ad/AnomalyDetectorProfileRunner.java
67.95% <53.84%> (-0.41%)
:arrow_down:

...a/org/opensearch/ad/util/SafeSecurityInjector.java
57.57% <57.57%> (ø)

...va/org/opensearch/ad/AnomalyDetectorJobRunner.java
80.50% <61.90%> (+0.19%)
:arrow_up:

...org/opensearch/ad/util/ADSafeSecurityInjector.java
72.41% <72.41%> (ø)

...main/java/org/opensearch/ad/util/SecurityUtil.java
87.50% <87.50%> (ø)

... and 24 more


Python hierarchy and mixing

In this PR we present the draft version of our work, implementing

the python hierarchy;
the python mixing;
generalized structure for states and hypers;
hierarchy and mixing 'switchers';
new structure of directories and corresponding CMake files.

*The documentation and styling of the code are not yet done.
We would like to mention that we did try using the 'make opaque' technique to pass by reference between c++ and python, but that surprisingly didn't improve the performance.
To build the library:
$ mkdir build
$ ./make_.sh

To run an example using the python implementations:
$ python3 docs/examples/test_run.py
We would like to hear your comments, questions and advice to improve the code before the final PR (we will need to open one in bayesmix too, since there are minor modifications also there).

Thanks a lot for the work!
The PR at the moment is too big, you should split it up in smaller chunks so that I can review them separately. Let's start with the part about the Python hierarchy, since I'm already familiar with that.
On a side note, I think that the most critical part will be the overall build system. I noticed some weir stuff:

stan math is included in a submodule, but that's already in the bayesmix submodule... please keep only the bayesmix one
there are copy-pasted cmakelists files around, it makes life harder for me to figure out what's going on.

In the end, we must be able to build this as one or two python packages (cf #14)
Please let me know when the PR is ready for a first round of review

Hi. We followed your request and opened a new PR with only the python hierarchy. We also removed the lib/math from submodules (we had added it at some point because of tbb problems but fortunately it is not needed anymore). About the CMake stuff, we followed the "if it's working, don't touch it" rule :). We would like to hear a more in depth comment about that to understand what should be changed.
How would you like us to proceed with the python mixing PR? Should we open a new one without the hierarchy, or we should wait untill this one is merged?
Also, we're starting to work on the report and to not create a clutter in the last days, we would like to send each chapter when it's ready for the review, if you don't mind :)


Dap-py 0.1.0

This 1.0 release makes Dap-py usable for searching for and downloading files from dap platforms. Here's the highlights of the changes:

Downloading via three different methods:

By providing the list of files returned from a search.
By downloading directly from a search query.
Or by downloading directly from a search query, but placing an order first.

Data can now be searched for and downloaded from SPP, albeit in a bit of a hacky way.
User is now prompted before files are downloaded.
Added some unit tests.
Now looks for environment variables DAP_CERT_DIR and DAP_DOWNLOAD_DIR for the location of certificates and where to download files respectively.
Changed the directory structure so it can be uploaded as a pip installable package. I've uploaded it to test-pypi to show this: https://test.pypi.org/project/dap-py/
Updated the READMEs to reflect the changes and add more details (like the purpose of ext1/2/3 etc. in queries).

@mkieburtzpnnl you might also want to have Sherman look through this PR before it gets merged

Thanks for the reviews! Hope to get these done early next week.

Alright that was a little more involved than I expected.


Detect inline keys config

Currently, the plugin only considers sops files if a .sops.yaml is found in one of the parent directories.
However, sops also works with standalone files inlining their keys config, like:
sops_gcp_kms__list_0__map_created_at=2022-02-16T19:19:15Z
sops_gcp_kms__list_0__map_enc=...
sops_gcp_kms__list_0__map_resource_id=projects/xyz/locations/global/keyRings/abcd

This PR allows for the 2 scenarios detection:

as before, a simple sops file + a sops config yaml in any of the parent dirs
[new]: a standalone sops file with any of the supported (taken from here: https://github.com/getsops/sops/blob/d8e8809bf92a47e0b2f742b9a43c3ab713acfd6a/stores/stores.go#L64)

Note that I didn't find where the README of the plugin page is to update it, so I guess this is part of the plugin release process with JetBrains.
Ideally, if this gets merged, this blob should be updated to add the 2 scenarios:

Hi there, thanks for your feedback!
You are correct I didn't try the edit functionality, only the decryption.
I'll have a look at the options you propose:

Read-only (decrypt)
Edit with some kind of store for the inline keys config

I found a way to do the replace using the inline metadata.
Admittedly a little hacky but it works nicely:

I'm leveraging the fact that when you call sops file... it runs in edit mode, and you can pass the editor you want via the EDITOR env var:
I'm writing the new unencrypted content to a temp file
writing a adhoc temp script that replaces the content of the temp file that SOPS passes to the editor with the new content

The reason this is nice is that I don't need to handle all the possible keys schemes that sops manages, we let sops use the normal edit flow. We simply replace the editor with a script that replaces the content.
This way, sops takes care of the decryption/encryption using either the yaml config or the inline metadata.
Note that it only works for mac/linux so far as I'm writing a temp bash script, but easily extendable for windows.
Curious to see what you think 😄

Interesting to hear about the history of the plugin 😄
The only os-dependent bit here is to have an EDITOR script that simply copies a file.
That should probably be doable?
I'm not versed into windows stuff for a long time now, but the current solution should work for mac/linux.
In any case, let me know if I can help

Fantastic!
I can't test the windows part, but it looks like you got it nicely covered.
I tested with your change, and my only nit is that the original file doesn't always refresh after re-encrypting.
I changed the file.refresh to be synchronous and then it works for me.
Let me know if that's ok.

I for myself thought about fixing the problem of #11 with the EDITOR variable, but I didn't got time to do so and thus I am very happy that you had time to rewrite it. I only have some thoughts without looking deeply into your PR.

set -o pipefail is not available in posix shells, though /usr/bin/env sh might link to bash it is not guaranteed, but since you do not use any pipes, your fine with only set -eu.
It may be good to not copy the content of the decrypted file to prevent data from leaking. I do not know how sops deletes the temporary decrypted content, but I hope they delete it in a save way. This plugin at least does not. I do not mean to be rude or anything. This plugin made it easier to work with sops files and I am glad for it to exists. So back to the topic of why it is not as safe as it could be. Files being deleted the way you do it are only unlinked but the content of the file will stay on the hard drive until another file allocates exactly this block(s). So opening the file multiple times (sequentially), will create multiple temporary files which will be unlinked, but not erased. Since now there are multiple decrypted copies of the file on the hard drive, the probability of overwriting them by creating new files will decline and thus giving an attacker the possibility to (more or less) easily read the files. Yes this might sound unrealistic, but it is possible and if the effort is justified for the attacker it might be the way to go.
To cut a long story short, it might be good to use the file created by sops without copying to not have to deal with deleting sensible files correctly. The ways I could think of to solve this are mainly possible on Linux, maybe on macOS too, but I am uncertain if they are possible on Windows at all.

Keep the sops process open and create an "editor" which will pass the path of the decrypted file to JetBrains via an unix-socket (or for windows an tcp-socket) created by the IDE and when finished editing, a simple ok-message  (or just closing the connection) will be sent back to the "editor". The problem with this solution is, that the created socket could be used by a malicious process to send a fake path. But I think it is unrealistic to be attacked this way, since the process could more easily search for the file in some temp directories instead. Furthermore depending on the implementation any second access to the socket may immediately receive a EOF or some other form of rejection, thus stoping the "editor" and therefore also sops. The only potential successful attack would be a newly created sops encrypted "empty" file which then will be populated via the IDE thus leaving the user unaware that the file they see is not managed by sops since it is also empty.
Keep the sops process open and create an editor which uses the stdin/stdout as sockets similar to the first solution. The problem with this solution, the sockets are also used by sops and may be polluted with warnings or similar of sops. But the benefit would be, that there are no sockets to attack (unless using something like reptyr but then again there is no benefit over instead searching for the file).
Decrypt the file and only use the content with in-memory IDE virtual files (if such exist - I do not have experience with the IDE plugin API). The problem with this solution is, how do you get the new content into the decrypted file provided by sops. Maybe by a solution similar to the ones above or by instead of passing the path to the IDE, passing the content to the stdin and the "editor" passes it to the file (something like cat /dev/stdin >"$1"). The benefits of this solution would be to not have a long running process and keeping the communication to the "editor" simple (and noise free). The downside is a possible race condition between sending the content and the "editor" being ready. But this could also be solved by passing a random string to the generated editor script like simple-sops-is-ready-hash and waiting for this string to appear on stdout/stderr as a whole line. The probability that such a line will be printed by sops as a warning is near zero I guess.

Printing out the decrypted content to the logs, even though it is only with the trace level, does not seem to be a good idea since the logs, at least if I am correct, will be saved to a file and therefore giving an attacker easy access to the content. Yes trace will most of the times not be enabled, but it is also not that unlikely. If it is crucial for debugging, that the content can be identified, a sha256 sum (or similar) could fulfil the same goal. Otherwise leaving it out might be the best solution.

I hope my thoughts are not to overwhelming and I do not want to say, that anyone here does a bad job, I am just sharing my two cents. It is up to you if any of those points are getting into this PR, end up in a separate issue or being thrown into the garbage.
Thank all of you for your work and have a nice day,
Jakob

It looks nice, I guess the only caveat would be the size limit on env vars on windows/linux.
A quick google search seems to indicate:

windows -> max 32,760 characters
linux -> 128KB

I've just tried it too (also on macOS), works like a charm and solves the problem from #11. Thank you both very much!

Just wanted to give a quick update.
I've been using the 2.0.0 beta for a while on a daily basis and it works like a charm for my needs.
Thanks again for this... quite a journey from my original PR 😛


Add support for cert authentication

Make sure to document

This is already added on the 2.1 branch but missing root/ca cert options


Capitalization Issue in Example

Hi Ovi,
Your example code has an error in the capitalization of the namespace:
// Convert the Javascript object to JSON format
$json = \Ovidigital\JsObjectToJson\JsConverter::convertToJson($jsObjectString);

Should actually be:
// Convert the Javascript object to JSON format
$json = \OviDigital\JsObjectToJson\JsConverter::convertToJson($jsObjectString);

This drove me crazy for about half an hour!

@bkonia sorry about that and thank you for reporting this. Very much appreciated!


Add Google Colab support

This is a pull request to the Colab branch, not the master branch.
This PR adds support for Google Colab - a free Jupyter Notebook runner in the Google cloud - to the Taproot workshop notebooks. This provides users with a completely ready-to-code environment for the workshop in less than 30 seconds and thus greatly reduces the friction of the setup process. Code written by a user is automatically saved to the users Google account.
This functionality is split up into two commits.

commit: Adds a shell script that sets up the Google Colab environment by e.g. cloning the Optech Bitcoin Core fork and the Taproot workshop repositories, downloading a statically-linked, Colab-compatible and taproot-enabled bitcoind binary (only use this binary on Colab!) and writing some config files.
commit: Adds two cells to the top of each existing notebook. The first with a markdown description for the second code cell. The code cell downloads the shell script from the first commit and executes it to set up the environment.

Reviewing this by trying out the notebooks as-is is not possible. The notebooks try to load the shell script added in the first commit. Reviewing modifying the shell script URL to point to my feature-branch (https://raw.githubusercontent.com/0xB10C/taproot-workshop/2019-11-add-colab-setup/setup-colab-env.sh). A sophisticated reviewer could try to complete other notebooks than the 0.1-test-notebook.ipynb, which has been tested in multiple PoCs before. For example 2.0-taproot-introduction.ipynb.
Example notebooks on my feature branch:

0.1-test-notebook.ipynb on Colab
0.2-elliptic-curve-math.ipynb on Colab
2.0-taproot-introduction.ipynb on Colab
... (copy link and change filename for other notebook)

closes #145

now I myself don't have an excuse to not do the workshop anymore..

@jnewbery noted that we don't need to clone the Optech fork of Bitcoin Core anymore. Removed that from the setup script in a force push.

ACK https://github.com/bitcoinops/taproot-workshop/pull/157/commits/8e293fdef3fa996b7531b528f7d83d2536ea9c7b
I haven't been able to test, but have reviewed the code. Happy to merge this to the Colab branch without testing.

Just tried it briefly and it worked well


Continuous Focus on the Application

Hi Team,
We have an application involving multiple steps and entire regression suite takes around 2 hours to complete execution.
Problem is we have to have application open and don't use the computer for other activities and sit idle. Is there a way we can execute without losing our control over mouse.
FYI.. If I use the mouse to work on different application during test execution we see failures as element not found.

RamaNarasimhaChanda it is not possible with WinAppDriver

No it's not possible the reason being headless mode is not supported.

setup a vm and inside the vm run your test, there is no other way to free machine.


add license and code of conduct

updated readme to reflect these changes

Can you add the license key to package.json?

Oops, I didn't update the license line at the bottom of the readme to follow the new format, thanks morning brain. Any way we can amend the existing commit?

Oops, I didn't update the license line at the bottom of the readme to follow the new format, thanks morning brain. Any way we can amend the existing commit?

No problem! I'll tackle it quickly


Expose treeItem internals

Is your feature request related to a problem? Please describe.
I've been creating a solution to #263 for my own usage and I managed to get something that works pretty well using a few custom renderers, however I have had to reach into the lib directory and import TreeItem.
import { TreeItem } from 'react-complex-tree/lib/cjs/treeItem/TreeItem'

This isn't a huge issue, however I have had to also update all my other imports to use 'react-complex-tree/lib/cjs' since NextJS/Webpack switches between the CJS and ESM versions depending on client/server builds so React context gets lost.
Describe the solution you'd like
Expose TreeItem or useTreeItemRenderContext to the main package. If they are still "unstable", maybe expose them under a __UNSTABLE constant?
// src/index.ts
import { useTreeItemRenderContext } from './treeItem/useTreeItemRenderContext';
import { TreeItem } from './treeItem/TreeItem';

export * from './controlledEnvironment/ControlledTreeEnvironment';
export * from './tree/Tree';
export * from './uncontrolledEnvironment/UncontrolledTreeEnvironment';
export * from './uncontrolledEnvironment/StaticTreeDataProvider';
export * from './types';
export * from './renderers';

export const __UNSTABLE = {
  useTreeItemRenderContext,
  TreeItem,
};

Describe alternatives you've considered

Import directly from 'react-complex-tree/lib/cjs'

Additional context

#263

Hey, thanks for the suggestion. The TreeItem component isn't actually that unstable, but I'd still consider it an implementation detail that doesn't make sense to expose directly. But I did expose it as part of a "INTERNALS" export that I added now in v2.3.3, similar to what you suggested. Note that I renamed TreeItem to TreeItemElement to avoid confusion with the type of the same name TreeItem, which refers to the data field.
For the hook you mentioned, I can actually see realistic use cases for that and it makes more sense to use in normal applications, so I exposed the hook also in v2.3.3 as normal export.