invalid type js.controller 4.0.4

seit dem Update auf 4.0.4 folgende Fehler (Auszug des Log)
`

2022-02-06 14:20:09.719 - warn: fuelpricemonitor.0 (24074) Object online is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:09.719 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.003 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.id is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.004 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.005 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.name is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.005 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.006 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.location.address is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.006 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.007 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.location.postalCode is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.007 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.008 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.location.city is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.008 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.009 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.location.latitude is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.009 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.010 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.location.longitude is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.010 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.011 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.contact.telephone is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.011 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.012 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.0.day is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.013 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.013 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.0.label is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.013 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.014 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.0.order is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.014 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.015 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.0.from is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.015 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.016 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.0.to is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.016 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.017 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.1.day is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.017 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.018 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.1.label is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.018 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.019 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.1.order is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.019 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.019 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.1.from is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.020 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.020 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.1.to is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.020 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.021 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.2.day is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.021 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.022 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.2.label is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.022 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.023 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.2.order is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.023 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.024 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.2.from is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.024 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.024 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.2.to is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.025 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.
2022-02-06 14:20:10.025 - warn: fuelpricemonitor.0 (24074) Object 0_Home_Diesel.0.openingHours.3.day is invalid: obj.common.states has an invalid type! Expected "object", received "string"
2022-02-06 14:20:10.026 - warn: fuelpricemonitor.0 (24074) This object will not be created in future versions. Please report this to the developer.

`

Bei mir auch

fixed in release 0.2.10-alpha.0
https://github.com/HGlab01/ioBroker.fuelpricemonitor/releases/tag/v0.2.10-alpha.0

fixed in release 0.2.10-alpha.0 https://github.com/HGlab01/ioBroker.fuelpricemonitor/releases/tag/v0.2.10-alpha.0

Danke, läuft, Keine Warnungen mehr.


scrollview warnming on ios

You specifiedonScrollon a  but notscrollEventThrottle. You will only receive one event. Using16you get all the events but be aware that it may cause frame drops, use a bigger number if you don't need as much precision.

still not fixed after 3 year?


[GUI] Limit amount to 8 decimal digits

fixes #798

I'm wondering if this should rather be done at the form level, similarly to how we trim whitespaces:
https://github.com/wizardsardine/liana/blob/903328ffef8317b1f152633ac671ecd92071d8eb/gui/ui/src/component/form.rs#L53
E.g. we could add new_amount_btc() that trims any excess decimals before passing the value to the on_change function.

I'm wondering if this should rather be done at the form level, similarly to how we trim whitespaces:
https://github.com/wizardsardine/liana/blob/903328ffef8317b1f152633ac671ecd92071d8eb/gui/ui/src/component/form.rs#L53
E.g. we could add new_amount_btc() that trims any excess decimals before passing the value to the on_change function.

i'll look into this, also i think we can filter out char other then "0123456789." and maybe automaticaly replace , by . ?

deprecated in favor of #992, following @jp1ac4 advice


Readme update

 added the provided data without altering the markdown structure of readme.md

Thanks, will look forward to contribute 🙌

Sure 😀!


Build with all Ruby 2.1.x versions

I'd rather test only one version per minor release branch, unless there is some specific reason. Can you explain the purpose of the change?

@weppos Yes, but since you specified 2.1.0, the minor updated with bugs and security fixes will not be tested. Projects on 2.1.0 should have passed to fixed 2.1.5.
Either we should only test with updated 2.0, 2.1 and 2.2 versions or either all of their minors.

I switched to test against 2.0, 2.1 and 2.2. Travis should automatically install the most recent bugfix release.


doc: fixed typo in TAOS-CI install document

It's trivial. This commit is to fix an incorrect link in TAOS-CI install document.
Signed-off-by: Geunsik Lim<EMAIL_ADDRESS>
[Template] PR Description
In general, github system automatically copies your commit message for your convenience.
Please remove unused part of the template after writing your own PR description with this template.
$ git commit -s filename1 filename2 ... [enter]

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical;
various tools like `log`, `shortlog` and `rebase` can get confused
if you run the two together.

Further paragraphs come after blank lines.

**Changes proposed in this PR:**
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
  by a single space, with blank lines in between, but conventions vary here.

Resolves: #123
See also: #456, #789

**Self evaluation:**
1. Build test: [ ]Passed [ ]Failed [*]Skipped
2. Run test: [ ]Passed [ ]Failed [* ]Skipped

**How to evaluate:**
1. Describe how to evaluate in order to be reproduced by reviewer(s).

Add signed-off message automatically by running **$git commit -s ...** command.

$ git push origin <your_branch_name>

:memo: Version: 1.20180820. Thank you for submitting PR #195. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://invain.mooo.com/.


Put any manifests we rely on for testing in a controlled location in our repo

Summary
gitsync_processor_test.go relies on the file structure in numaflow repository as well as the file structure in this repo not changing. It would be nice to have a location in our repository where we can put any files we need for these unit tests, which is guaranteed not to change.
@xdevxy and I agreed that any test files for unit tests can go in the tests/manifests directory. This can include both GitSync spec files that we need to pull from Github as well as any the manifest files referenced by the RepositoryPaths.
(Note, the exception is if we have any tests that require authorization, then we won't be able to do this for that test.)

Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

@shubhamdixit863 I just updated the description - thanks


GUI: add scroll bars to meta data sheet as this window will bot be fully displayed on older notebooks

Finished with 6a3d4ab11080af05f7b77b923108c07d41945300.
Closing #48


Add swift-algorithms

Pull Request Description
Add https://github.com/apple/swift-algorithms
Acceptance Criteria

[x] be an Xcode or swift package manager project
[x] support building on either Linux or macOS
[x] target Linux, macOS, or iOS/tvOS/watchOS device
[x] be contained in a publicly accessible git repository
[x] maintain a project branch that builds against Swift 4.0 and passes any unit tests
[x] have maintainers who will commit to resolve issues in a timely manner
[x] be compatible with the latest GM/Beta versions of Xcode and swiftpm
[x] add value not already included in the suite
[x] be licensed with one of the following permissive licenses:

Apache License, version 2.0

[x] pass ./project_precommit_check script run

PASS: swift-algorithms, 5.2, 386460, Swift Package
========================================
Action Summary:
     Passed: 1
     Failed: 0
    XFailed: 0
    UPassed: 0
      Total: 1
========================================
Repository Summary:
      Total: 1
========================================
Result: PASS
========================================
--- swift-algorithms checked successfully against Swift 5.2 ---

@swift-ci test

@swift-ci test

@natecook1000 FYI - Adding you as a maintainer here.

@natecook1000 FYI - Adding you as a maintainer here.

Can you also add tag "tags": "swiftpm"?

Can you also add tag "tags": "swiftpm"?

@swift-ci test

@swift-ci test


[AHub] Fix AHub Defect @open sesame 04/06 17:11

In this PR
Fix AHub Defect

make some exception statement
change auto element -> auto &element

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #2175. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

:octocat: cibot: @DonghakPark, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nntrainer/ci/repo-workers/pr-checker/2175-202304061609410.84432697296143-3f68a91864a58cbfe6c4f09c1ddebbccc501cb54/.

:octocat: cibot: @DonghakPark, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nntrainer/ci/repo-workers/pr-checker/2175-202304061711550.73580694198608-3f68a91864a58cbfe6c4f09c1ddebbccc501cb54/.

:octocat: cibot: @DonghakPark, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nntrainer/ci/repo-workers/pr-checker/2175-202304071057040.12570905685425-25204ff3afe74f713073641d3aebf2818fdbac7f/.

:octocat: cibot: @DonghakPark, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nntrainer/ci/repo-workers/pr-checker/2175-202304072009120.82289409637451-25204ff3afe74f713073641d3aebf2818fdbac7f/.

:octocat: cibot: @DonghakPark, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nntrainer/ci/repo-workers/pr-checker/2175-202304100922100.90769600868225-25204ff3afe74f713073641d3aebf2818fdbac7f/.


Correctly ignore depandabot branches during push

Signed-off-by: Peter Zhu<EMAIL_ADDRESS>Description
Correctly ignore depandabot branches during push.
Per github document the single * will not ignore additional / if the branch name includes it.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet
In this PR the branch name is: dependabot/gradle/com.diffplug.spotless-6.9.0 thus ignore rule.
https://github.com/opensearch-project/OpenSearch/pull/4065
Thanks.
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff

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 #4077 (615c3e8) into main (6f43dbc) will decrease coverage by 0.06%.
The diff coverage is 66.66%.

@@             Coverage Diff              @@
##               main    #4077      +/-   ##
============================================
- Coverage     70.61%   70.54%   -0.07%
- Complexity    56983    56995      +12
============================================
  Files          4595     4595
  Lines        274234   274234
  Branches      40181    40181
============================================
- Hits         193638   193466     -172
- Misses        64342    64503     +161
- Partials      16254    16265      +11

Impacted Files
Coverage Δ

...pensearch/common/settings/IndexScopedSettings.java
100.00% <ø> (ø)

.../java/org/opensearch/snapshots/RestoreService.java
55.37% <0.00%> (ø)

...org/opensearch/cluster/metadata/IndexMetadata.java
83.85% <100.00%> (ø)

.../main/java/org/opensearch/index/IndexSettings.java
86.35% <100.00%> (ø)

...g/opensearch/index/analysis/CharFilterFactory.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...gations/bucket/composite/CompositeAggregation.java
15.00% <0.00%> (-85.00%)
:arrow_down:

...luster/routing/allocation/RoutingExplanations.java
41.37% <0.00%> (-58.63%)
:arrow_down:

...a/org/opensearch/client/cluster/ProxyModeInfo.java
0.00% <0.00%> (-55.00%)
:arrow_down:

.../admin/cluster/reroute/ClusterRerouteResponse.java
55.00% <0.00%> (-45.00%)
:arrow_down:

...aggregations/bucket/composite/ParsedComposite.java
44.44% <0.00%> (-40.75%)
:arrow_down:

... and 477 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Error when analyzer globs go unmatched

This is a perf hit, of course, but I claim it's not an important one.
I took the liberty of unindenting the code at the end of the main function (by early-exiting), but this has made the diff pretty nasty, sorry :(
Fixes #203.
I could understand not wanting this; on balance, though, I think these cases are more likely to be user error than intended.

Hi @Smaug123, did you see @dawedawe's last message here?

I don't really want this feature enough to work on it any more, thanks!


Feature: Sparse Access Memory

Implement sparse access memory for DNCs.
Related paper: https://arxiv.org/abs/1610.09027

Are you already diving into this, or do you need some help?

Not looking at this at the moment. Trying to make DNCs work for language modeling & seq2seq.

I've done DNCs for seq2seq before. Does anything about the base implementation need to change, or is it just a matter of structuring the inputs and outputs?

I actually wrote this repo because the other ones were not torch.nn-like. Making the APIs more like torch.nn makes it easier to replace nn.LSTM etc with DNC otherwise keeping implementations intact, potentially requiring one line of code change.
The ones I tried, I had to also write this piece of code for LMs to detach hidden states: https://gist.github.com/ixaxaar/02b65312eb1a840cc14e74d93b35178f
For seq2seq I took the openNMT repo and forked it here.
Other than that it was pretty much a few liners.

Is implemented in #16 and #18 , though code review etc are pending.


Use repository config.py files to grab items for the gallery cards

We can grab title, author, tag, and thumbnails all from the Jupyterbook conf.py files in each repository. I am going to change the code to do this because it is much more flexible and robust.
You may see some PRs on your cookbooks to add these elements to your cookbook, but feel free to customize them more.

Copying a comment form https://github.com/ProjectPythiaCookbooks/projectpythiacookbooks.github.io/pull/33 here:

Just showing what the local build looks like now. Only the radar-cookbook has merged the changes to the the _conf.py file and has the "accepted" tag added. All other Cookbooks have a PR open to have them follow the new format. But we'll need some sort of process for adding the "accepted" tag.
Notice that the tags now are split up into packages and domains again :)

@hCraker 's now follows the template as well

!


Deserialize union in CaseKeyAsFieldValue mode from JSON with more than 2 fields

Is there any particular reason for this check in deserializeUnion?
if fields.Length <> 2 then
    failDeserialization path <| sprintf "Failed to parse union from record with %i fields, should be 2 fields." fields.Length

I have a JSON with more than two fields but I care just for the key field (union case discriminator) and the value field.
{
    "ignore_this": "yes",
    "ignore_that": "also yes",
    ...,
    "discriminator": "type_1",
    "data": {
        ...
    }
}

Is data in your example depends on discriminator? You refer to some "value field" that is not in your example (I'm assuming you meant data field).

Yes, sorry, data is the value field (CaseValueField =  "data").

Hmmm, actually from the code it seems that we can safely lift this limitation for number of fields in the object.

Thank you I will let you know here in what release the change is available

Thanks!


RFP - RealPopup LAN chat

Checklist

[x] The package I am requesting does not already exist on https://chocolatey.org/packages;
[x] There is no open issue for this package;
[x] The issue title starts 'RFP - ';
[x] The download URL is public and not locked behind a paywall / login;

Package Details
Software project URL : https://www.realpopup.it
Direct download URL for the software / installer : https://www.realpopup.it/download.html
Software summary / short description: Send messages from PC to PC, create chat groups, transfer files and get a remote desktop sharing over a local network without using the Internet or dedicated servers.

Status: Review
https://chocolatey.org/packages/realpopup

Status: Published
https://chocolatey.org/packages/realpopup
Can be closed.


Added default Kryo behavior to kryo-extend multimethod.

The current implementation doesn't necessarily allow setRegistrationOptional
to behave as expected (where unknown java classes are serialized using the FieldSerializer.)
This commit implements Kryo's default behavior as a separate function, register-generic,
and adds a default dispatch method to kryo-extend that calls register-generic if no custom
serialization made it.
Patch here: https://gist.github.com/1425255

Let me know what you guys think! I also wanted to ask your opinion on setting optional registration with a keyword argument.

Actually, this makes me think of a potential problem. I was reading the Kryo page and cake across this note:

When a class is registered, it is assigned an ordinal number. This integer is used in the serialized bytes to identify what class to instantiate when the object is deserialized. By using an integer, a class can be represented very efficiently, usually with just a byte. The downside is that the ordinals must be identical when the class is deserialized. To do this, the exact same classes must be registered in the exact same order when the object is deserialized.

could it be that kryo-extend will cause issues between different compilations of the same source, or if additional multimethods are added between serialization and deserialization?

On the original patch, this makes sense and I will apply it.
On the ordering issue - there is an implicit assumption in the current Kryo setup that assumes that the reader and writer have registered the same classes in the same order.  If you are explicitly registering all your classes and encapsulating that setup in a single function called by both sides, there is no isssue.  (This is what we do at Revelytix).  If, however, reading and writing code registers them in different orders, there could certainly be a problem.
There is a solution to this in Kryo, which is to call [register](http://kryo.googlecode.com/svn/api/com/esotericsoftware/kryo/Kryo.html#register(java.lang.Class, com.esotericsoftware.kryo.Serializer, boolean)) and pass true for the last argument - that will send the class name string on the first serialization so the receiving side can register it properly (or at least that's my understanding).

Cool, got it. Just tested it out and it looks like the class name is stored the first time it appears in each object. Thanks!


KOGITO-120 - Setup Integration Tests for Service Discovery

See https://issues.jboss.org/browse/KOGITO-120
First implementation contains only Kubernetes Service Discovery tests

Waiting for XTF 0.13 release before removing the WIP...

@radtriste overall looks really great. It's clearly that you put a lot of effort on it. Many thanks!

@spolti do you have anything to add or I can merge this?

you can merge this.

@radtriste please squash your commits

squash done :)


Switch from /terminal to /terminalsocket assumes that /terminal was at the root of the URL

https://github.com/intersystems-community/webterminal/blob/c49b0ac1d2a98c6084598bcf1a65ce794a13b89e/src/client/js/server/index.js#L56-L61
This fails in a situation where a "real" web server is hosting Web Gateway connections to multiple InterSystems servers. For instance an IIS instance on a server named webhost configured with root applications dev and test, and the Web Gateway connecting /dev and /test URLs to different InterSystems servers.
The WebTerminal URL for the dev server would be http://webhost/dev/terminal/ but the code above points the websocket to ws://webhost/terminalsocket/WebTerminal.Engine.cls

Hello! Thanks for reporting this issue.
I'm not maintaining this project right now - however I would gladly accept any pull request you can make. If you could also export the XML from any prior-IRIS installation, I can then release it via official channels.
I am not very sure how environments work, but it seems to be easy to fix, as far as I understand:
 function getNewWs () {
     return new WebSocket(`${ (location.protocol === "https:" ? "wss:" : "ws:")
         }//${ location.hostname }:${ location.port ||
         (location.protocol === "https:" ? "443" : "80")
-         }/terminalsocket/${ encodeURIComponent(CACHE_CLASS_NAME) }`);
+         }${ location.pathname.includes('/terminal') ?  location.pathname.replace(/\/terminal.*/, "/terminalsocket") : "/terminalsocket" }/${ encodeURIComponent(CACHE_CLASS_NAME) }`);
 }

@ZitRos I have submitted PR #147 to resolve this.


Adjust script for patching glibc 2.27

Arch upgraded to glibc 2.27, the old qldv does not work anymore (noticible when using swift-bin).
Current implementation of version checks is here: https://github.com/bminor/glibc/blob/glibc-2.27/elf/dl-version.c and it's different from 2.26. I adjusted the script accordingly:

10129: the verbose parameter lands via esi in [rsp+0x48],
103e0: value from [rsp+0x48] lands in edx - this is the line that I replace with xor edx, edx and a few nops

old:
   103e0:	8b 54 24 48          	mov    edx,DWORD PTR [rsp+0x48]

new:
103e0:	31 d2                	xor    edx,edx
103e2:	90                   	nop
103e3:	90                   	nop

Thanks for the heads up!
That being said, this solution isn't really ideal. The core problem seems to more be that we're changing the wrong test; there's a test instruction immediately following the mov that seems to be the proper one.
I have a fix, but I have to test it under Flatpak first. Should be ready later today...

Ok, it should be fixed now, and the new package is up on AUR.


Node rebuild progress for drives and pools is incorrect

Environment info

Version: 2.1.3-b3379aa
Deployment: AZURE
Customer: Shiri's System

Actual behavior

I had Linux agent with 4 drives and two additional agents with 1 drives each.
The agents had data written on them and I've assigned them to a newly created pool.
There were enough agents left for rebuild correctly without errors.
I can see inside agent's drives screen that the progress is 0% yet on the same screen, I see that one of the drive's progress is 68%.
The same problem happens with pool progress (probably because aggregated from drives)

Expected behavior

The progress bar should be correct and show 68% / 4 instead of 0.

Steps to reproduce

Create host with 4 drives and additional 5 hosts with 1 drive each.
Upload data and store is at some agents
Assign hosts with 3 drives and additional 2 hosts to a different pool
Wait for a rebuild and look at the progress

Screenshots or Logs or other output that would be helpful

Agent assignment to pools is no longer relevant with k8s pools


csharp_dotnetcore: Add echo bot sample, fixes to main README.md

Proposed Changes

add echo bot without state
update main README.md to point to new sample
removed incorrect :runner: emoji’s from main README.md

Question about App Insights and how early we want to weave that in.
Other than that looks awesome!


[spark] It is more reasonable import class ImmutableMap from package:org.apache.paimon.shade.guava30.com.google.common.collect

Purpose

Linked issue: close #2382

It is more reasonable import class ImmutableMap from package:org.apache.paimon.shade.guava30.com.google.common.collect which is from jar: org.apache.paimon:paimon-shade-guava-30
, instead of org.apache.hadoop.shaded.com.google.common.collect.ImmutableMap
Tests

API and Format

Documentation

Can you also add checkstyle to forbid hadoop guava？

 Can you also add checkstyle to forbid hadoop guava？

done


Improve meta description

@athul Sorry for the multiple PRs, I jumped the gun on the last one and wasn't really expecting such a fast turnaround on the original PR. 🤐  After looking into it more, it makes more sense to provide a custom meta description per-page where possible, so I copied the behavior of the og:description tag.

Rather than use the same description on every page, prefer the post summary if it's available and only use .Params.description on the root page.
This mimics the behavior of the opengraph internal template for the og:description tag.

Hey, No issues. I'll merge this one too 😉

Just add a comment when you find everything is ⚡

Just add a comment when you find everything is 👌

Haha no more changes on the way, should be good to go as-is :shipit: Thanks again!


Nested routes breaks/removes injected styles (e.g. Vuetify theme-related styling)

Environment

Operating System: Darwin
Node Version:     v20.7.0
Nuxt Version:     3.7.4
CLI Version:      3.9.1
Nitro Version:    2.7.0
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      build, modules, ssr, vite
Runtime Modules:  ()
Build Modules:    -

Reproduction
https://stackblitz.com/edit/nuxt-starter-6q9lur?file=README.md
https://github.com/mathiasrando/nuxt3-vuetify-issue-nested-routes
Describe the bug
This issue only occurs when you use Nuxt 3. Using the same route structure in Vue 3 doesn't break any styling.
Steps to reproduce

Install and start the development server (see README) or open the Stackblitz provided.
Visit "Index" and refresh the page (works as expected)
Visit "Issue" and refresh the page (theme styling breaks)
Visit "Nested issue" and refresh the page (theme styling breaks)
Visit "grandchild" and refresh the page (works as expected)

When visiting "grandchild" after the theme is broken it also applies the styles correctly.
If you remove <NuxtPage></NuxtPage> from the route it no longer breaks the theme styling even if the child route is still present.
Expected Behavior
The theme styles should be loaded correctly for all routes.
Actual Behavior
The theme styles does not load correctly when you load a page/route that has children.
Help from Vuetify core member
This is a link for the code where a core member of Vuetify suspects things goes wrong: https://github.com/vuetifyjs/vuetify/blob/f314cd11553d90708d295a03edf18621105724c5/packages/vuetify/src/composables/theme.ts#L302-L307
Example of the styling being applied(route with NuxtPage) and when it's not(parent route with `NuxtPage´):

Additional context
No response
Logs
No response

For anyone also experiencing this issue a temporary fix is to inspect the page when working and take the generated theme styling, add it to a CSS file and then load it in nuxt.config.ts. If you're using the default theme search the DOM for .v-theme--light and copy the entire content of the injected style tag.
So add e.g. css: ["assets/css/vuetify-theme-fallback.css"] to nuxt.config.ts with the content.

Thanks for the attention, @danielroe.
Does this mean I should add it in another repository as well? And if so, which one?

This is fixed in Nuxt version 3.8.1.
It might be fixed in 3.8.0 as well, but I haven't tested it.


padding on inline

is able to padding on inline mode ? thanks..

Hi @HaxorGaruda, can you explain a little more about what you mean? Perhaps you have a short script to demonstrate the issue?


Empty appearance DEF names

I was trying to export the blender file below and it did not give me any problems then but when I tried opening it in Webots it gave me:
ERROR: 'C:/Users/***/Documents/Inventor/FRC Field 2019/FRC Field 2019.wbt':17:37: error: Expected node or PROTO name, found '{'.
ERROR: 'C:/Users/***/Documents/Inventor/FRC Field 2019/FRC Field 2019.wbt': Failed to load due to syntax error(s).
I am in Webots R2019b and in Windows 10
https://drive.google.com/open?id=1kuIG4Jh2BoMZ4Qza5nOWXdTzLzb_mli0

I can reproduce the problem, thîs is due to an issue when defining the appearances DEF names, which are in some cases empty:
appearance DEF  PBRAppearance {

We will fix the importer to avoid such cases, in the meantime you can simply do a search and replace in your *.wbt file (replace appearance DEF  PBRAppearance { by appearance PBRAppearance {), I just tried and it seems to work fine:

Be aware the number of triangles of your model is very high, I strongly recommend reducing the number of triangles of some key part of your model to keep a simulation speed and memory usage reasonable in Webots.

Thanks it seems that it works now!

Perfect, thank you for the feedback.
Just for information, the fix is ready here: https://github.com/omichel/blender-webots-exporter/pull/6


Update to RFEM Python Client (main HEAD)

Description
This change includes all relevant updates made to the RFEM Python Client (SHA-1: caaddce22daba40581705bc1460aadc7965bf800).
unit tests: 123 passed, 6 skipped in 198.95s (0:03:18).
To check these changes fast and reliably run unit tests, examples and compare  folder directly (RFEM_Python_Client\RFEM to RSTAB_Python_Client\RSTAB, RFEM_Python_Client\UnitTests to RSTAB_Python_Client\UnitTests and all auxiliary files together)
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update

How Has This Been Tested?

[x] Unit Tests
[ ] Attached examples

Test Configuration:

RFEM / RSTAB version: 6.02.0059.158.0353a07beab
Python version: 3.11.0

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

All comments should be fixed.


kapp and kube API Server calls limits

Hello,
I'm benchmarking some kapp deploy commands on a big manifest file with 6 containers and some wait-rules, without kapp-controller, and i'm facing 403 errors from the APIServer if i do multiple concurrent kapp deploy. Looks like these 403 make kapp stop with :
kapp: Error: waiting on reconcile job/job-template-kapp1-1-32ylei-db-hasura-create-secret-672rpn (batch/v1) namespace: fabrique-ci:
  Errored:
    Listing schema.GroupVersionResource{Group:"", Version:"v1", Resource:"pods"}, namespaced: true:
        Fetching all namespaces: an error on the server ("error trying to reach service: dial tcp <IP_ADDRESS>:443: connect: connection refused") has prevented the request from succeeding (get namespaces)

I've done various tests and set kapp-api-qps to 10 and kapp-api-burst to 10 and have no more ideas so i'd like to share this with you, maybe you'll have some 😉
Looks like most of 403 are related to cluster-wide API calls (namespaces, pods...)
Have anyone experiences this kind of behaviour ? we're using AKS with Rancher.
Some numbers for a multiple deploy (3) with the below manifests (stripped) :
In this graph you can see APIServer responses to kapp :

green : 200 or 201
blue: 404
red: >201 and !=404 (mostly 403)

Samples errors :

Sample manifests :
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: app
    application: template
  name: app
  namespace: template-kapp1
  annotations:
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.app: kontinuous/app.template-kapp1
    kapp.k14s.io/change-rule.build-app: upsert after upserting kontinuous/build-app.template-kapp1
    kapp.k14s.io/change-rule.keycloakx: upsert after upserting kontinuous/keycloakx.template-kapp1
    kapp.k14s.io/change-rule.hasura: upsert after upserting kontinuous/hasura.template-kapp1
spec:
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: hasura
    application: template
  name: hasura
  namespace: template-kapp1
  annotations:
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.hasura: kontinuous/hasura.template-kapp1
    kapp.k14s.io/change-rule.build-hasura: upsert after upserting kontinuous/build-hasura.template-kapp1
    kapp.k14s.io/change-rule.db-hasura: upsert after upserting kontinuous/db-hasura.template-kapp1
    kapp.k14s.io/change-rule.keycloakx: upsert after upserting kontinuous/keycloakx.template-kapp1
spec:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: maildev
    application: template
  name: maildev
  namespace: template-kapp1
  annotations:
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.maildev: kontinuous/maildev.template-kapp1
spec:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: metabase
    application: template
  name: metabase
  namespace: template-kapp1
  annotations:
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.metabase: kontinuous/metabase.template-kapp1
    kapp.k14s.io/change-rule.db-metabase: upsert after upserting kontinuous/db-metabase.template-kapp1
spec:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: pgweb
    application: template
  name: pgweb
  namespace: template-kapp1
  annotations:
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.pgweb: kontinuous/pgweb.template-kapp1
    kapp.k14s.io/change-rule.db-hasura: upsert after upserting kontinuous/db-hasura.template-kapp1
spec:

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: keycloakx
  annotations:
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.keycloakx: kontinuous/keycloakx.template-kapp1
    kapp.k14s.io/change-rule.db-keycloak: upsert after upserting kontinuous/db-keycloak.template-kapp1
  namespace: template-kapp1
spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-build-app-kaniko-3zekn9
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.build-app: kontinuous/build-app.template-kapp1
    kapp.k14s.io/change-group.build-app.kaniko: kontinuous/build-app.kaniko.template-kapp1
    kapp.k14s.io/change-group.build-app..kaniko: kontinuous/build-app..kaniko.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1
spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-build-hasura-kaniko-3d6853
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.build-hasura: kontinuous/build-hasura.template-kapp1
    kapp.k14s.io/change-group.build-hasura.kaniko: kontinuous/build-hasura.kaniko.template-kapp1
    kapp.k14s.io/change-group.build-hasura..kaniko: kontinuous/build-hasura..kaniko.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1
spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-db-hasura-create-db-1dtpbq
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.db-hasura: kontinuous/db-hasura.template-kapp1
    kapp.k14s.io/change-group.db-hasura.create-db: kontinuous/db-hasura.create-db.template-kapp1
    kapp.k14s.io/change-group.db-hasura..create-db: kontinuous/db-hasura..create-db.template-kapp1
    kapp.k14s.io/change-rule.db-hasura..create-secret: upsert after upserting kontinuous/db-hasura..create-secret.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1
spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-db-hasura-create-secret-672rpn
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.db-hasura: kontinuous/db-hasura.template-kapp1
    kapp.k14s.io/change-group.db-hasura.create-secret: kontinuous/db-hasura.create-secret.template-kapp1
    kapp.k14s.io/change-group.db-hasura..create-secret: kontinuous/db-hasura..create-secret.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1

spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-db-keycloak-create-db-3dxq1g
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.db-keycloak: kontinuous/db-keycloak.template-kapp1
    kapp.k14s.io/change-group.db-keycloak.create-db: kontinuous/db-keycloak.create-db.template-kapp1
    kapp.k14s.io/change-group.db-keycloak..create-db: kontinuous/db-keycloak..create-db.template-kapp1
    kapp.k14s.io/change-rule.db-keycloak..create-secret: >-
      upsert after upserting
      kontinuous/db-keycloak..create-secret.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1

spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-db-keycloak-create-secret-39r2rj
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.db-keycloak: kontinuous/db-keycloak.template-kapp1
    kapp.k14s.io/change-group.db-keycloak.create-secret: kontinuous/db-keycloak.create-secret.template-kapp1
    kapp.k14s.io/change-group.db-keycloak..create-secret: kontinuous/db-keycloak..create-secret.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1
spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-db-metabase-create-db-xgit30
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.db-metabase: kontinuous/db-metabase.template-kapp1
    kapp.k14s.io/change-group.db-metabase.create-db: kontinuous/db-metabase.create-db.template-kapp1
    kapp.k14s.io/change-group.db-metabase..create-db: kontinuous/db-metabase..create-db.template-kapp1
    kapp.k14s.io/change-rule.db-metabase..create-secret: >-
      upsert after upserting
      kontinuous/db-metabase..create-secret.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1
spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-db-metabase-create-secret-2bu7x4
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.db-metabase: kontinuous/db-metabase.template-kapp1
    kapp.k14s.io/change-group.db-metabase.create-secret: kontinuous/db-metabase.create-secret.template-kapp1
    kapp.k14s.io/change-group.db-metabase..create-secret: kontinuous/db-metabase..create-secret.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1

spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-seed-hasura-import-secret-3h5a4u
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.seed-hasura: kontinuous/seed-hasura.template-kapp1
    kapp.k14s.io/change-group.seed-hasura.import-secret: kontinuous/seed-hasura.import-secret.template-kapp1
    kapp.k14s.io/change-group.seed-hasura..import-secret: kontinuous/seed-hasura..import-secret.template-kapp1
    kapp.k14s.io/change-rule.hasura: upsert after upserting kontinuous/hasura.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1
spec:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: job-template-kapp1-seed-hasura-seed-db-59hfdf
  namespace: fabrique-ci
  annotations:
    kapp.k14s.io/nonce: ""
    kapp.k14s.io/update-strategy: fallback-on-replace
    kapp.k14s.io/change-group: kontinuous/template-kapp1
    kapp.k14s.io/change-group.seed-hasura: kontinuous/seed-hasura.template-kapp1
    kapp.k14s.io/change-group.seed-hasura.seed-db: kontinuous/seed-hasura.seed-db.template-kapp1
    kapp.k14s.io/change-group.seed-hasura..seed-db: kontinuous/seed-hasura..seed-db.template-kapp1
    kapp.k14s.io/change-rule.seed-hasura..import-secret: >-
      upsert after upserting
      kontinuous/seed-hasura..import-secret.template-kapp1
    kapp.k14s.io/change-rule.hasura: upsert after upserting kontinuous/hasura.template-kapp1
    kapp.k14s.io/disable-original: ""
    kapp.k14s.io/create-strategy: fallback-on-update
    kapp.k14s.io/change-group.jobs: kontinuous/jobs.template-kapp1
spec:

Hi @revolunet! I am guessing that the server has a bunch of pending requests and therefore it's refusing the tcp connection.
You can try to increase the --wait-check-interval duration to a high number (say 5 seconds or 20 seconds) and see if that helps. Increasing it to 5 seconds would decrease the number of api calls made during the waiting stage to ~ 1/5th.

thanks @praveenrewar ! will try and report with these options

While it reduces the load in the long run it doesnt prevent 403s.
Looks like at the start of kapp deploy, theres a lot of requests made and it doesnt account the qps/burst/wait options

I see. Would you be able to share any such error? If it's happening in the apply stage, then you could also try increasing --apply-check-interval and decreasing --apply-concurrency (default is 5). But I feel that it's happening much before that. You can also try reducing --existing-non-labeled-resources-check-concurrency to a smaller number like 5 (default is 100).

mmm thanks. i've tried many combinations without luck. looks like we have something wrong in our cluster. it fails as soon as we launch multiple parrallel kapp deploys

Would you be able to share a couple of things which might help us in improving kapp performance (we are already working on a couple of things https://github.com/vmware-tanzu/carvel-kapp/issues/599)

cluster configuration (RAM, CPU, number of nodes etc,.)
permissions available to the user/SA being used
couple of errors where you are seeing the 403 error
Number of kapp apps you are trying to deploy concurrently

Hi
Our cluster is 6x(6cpu + 32Go)
I tried with a superior account and got no 403 but still 499 or 500 from the API Server which make kapp stop.
So yes, the 403 are due to a limited serviceaccount that cannot query cluster-wide
We use Rancher and suspect it is our bottleneck here. We'll test directly on the API Server to see if it gets better.
It works well with one kapp deploy, sometimes two simultaneous but no more with the above manifests.
some logs examples
2022-10-19T09:59:58+00:00 499 /k8s/clusters/c-gjtkk/api/v1/namespaces/template-kapp1-8-2/configmaps kapp/v0.0.0 (linux/amd64) kubernetes/$Format
2022-10-19T09:59:58+00:00 499 /k8s/clusters/c-gjtkk/api/v1/namespaces/template-kapp1-8-2/configmaps kapp/v0.0.0 (linux/amd64) kubernetes/$Format
2022-10-19T09:59:58+00:00 499 /k8s/clusters/c-gjtkk/api/v1/namespaces/template-kapp1-8-2/configmaps kapp/v0.0.0 (linux/amd64) kubernetes/$Format
2022-10-19T09:59:58+00:00 409 /k8s/clusters/c-gjtkk/api/v1/namespaces/template-kapp1-8-2/serviceaccounts kapp/v0.0.0 (linux/amd64) kubernetes/$Format
2022-10-19T09:59:50+00:00 499 /k8s/clusters/c-gjtkk/api/v1/namespaces/template-kapp1-8-1/configmaps kapp/v0.0.0 (linux/amd64) kubernetes/$Format
2022-10-19T09:59:50+00:00 409 /k8s/clusters/c-gjtkk/api/v1/namespaces/template-kapp1-8-1/serviceaccounts kapp/v0.0.0 (linux/amd64) kubernetes/$Format

I tried with a superior account and got no 403 but still 499 or 500 from the API Server which make kapp stop.
So yes, the 403 are due to a limited serviceaccount that cannot query cluster-wide

I see, but usually if you get a forbidden error leads kapp to stop, I am wondering what caused these mani api calls then?

We use Rancher and suspect it is our bottleneck here. We'll test directly on the API Server to see if it gets better.

That is a possibility, because based on the cluster configuration, it should be able to handle these many requests.

Hi @revolunet ! Were you able to find the root cause of the failures? Let me know if you need any help or if you would like to share some information which could be helpful to improve kapp performance.

Hello @praveenrewar,
After many tests we've confirmed that it comes from the rancher API; For some reason it throws "connection refused" when under load and we're unable to find the root cause or more logs.
The good news is kapp works flawlessly when talking directly to the kube API server !
I think this isuee can be closed

Thank you for the update @revolunet. Closing the issue for now, but feel free to re open it if you find something we can improve on.

Maybe kapp could have a better retry mechanism on API errors so it could also work with flaky clusters.
Thanks for your support !

We do have a set of retry-able errors, but currently retrying doesn't happen in the waiting stage. We are tracking that over here. Hopefully we will find a suitable solution to it soon.


Question about long sequence lengths with Hyena

Hello!
In the Hyena paper, section 4.4 says "Hyena speedups reach 100x at sequence length 64K."
The figure referenced by that section (figure 4.3) stops at a sequence length short of 10k and the optimized implementation in this repo appears to be limited to an 8k sequence length.
There are a few other references to a 100x speedup over FlashAttention in the paper (and in blog posts). Are these measured speedups or extrapolated from smaller sequence lengths?
I've experimented with the implementation in standalone_hyena.py but it appears to be ~3x slower than FlashAttention at sequence lengths > 32k tokens.
Do you have an estimate for when the fftconv implementation in this repo will support longer sequence lengths (or a pointer to another Hyena codebase if the speedups in the paper were measured)?
Thanks for the great work!

The runtime numbers in the paper do not use the optimized fftconv kernel precisely because of the temporary 8k limitation.

I've experimented with the implementation in standalone_hyena.py but it appears to be ~3x slower than FlashAttention at sequence lengths > 32k tokens.

Can you give more details on your benchmarking workload? Hyena should already be much faster at 32k tokens, I suspect there might be other factors at play.

Figure 4.3 (left) goes up to 100k, I think you're referencing the one on the right (which is only a zoomed-in portion of the left figure)?

Yeah my bad.  I saw 10^5 and thought 10000 for some reason :facepalm:

Can you give more details on your benchmarking workload?

My benchmarking baseline was a model with:

Sequence length of 36032 tokens (36k rounded up to a multiple of 64)
Batch size of 1
FlashAttention with 16 heads and an embedding dim of 1024 (from the pypi package for this repo)
bfloat16
A100

I compared it to a model replacing FlashAttention with a HyenaOperator (d_model of 512, l_max of the sequence length above and everything else at the default values).
I ran into memory issues using the HyenaOperator with an embedding dim of 1024 so I had to drop to 512.
Even with the much smaller embedding dim, the network with the HyenaOperator was ~3x slower than the one with FlashAttention.
Do you think the memory usage issues are just an artifact of the standalone implementation?

Hyena should already be much faster at 32k tokens, I suspect there might be other factors at play.

Are you saying Hyena even without the optimized kernel should be much faster than FlashAttention at that sequence length?
The benchmark above was just a quick test to get some rough numbers so there were some other differences between the baseline and the Hyena test:

Smaller embedding dim, but AFAIK, that should work in favor of Hyena
torch.compile didn't work with the HyenaOperator (complaining about complex to float conversions). I haven't had a chance to dig into the issue in depth yet, but it seems unlikely that it's responsible for the performance gap assuming you expect Hyena to be significantly faster (i.e. 10x  to 50x faster). Maybe the overall model is just getting really slow without torch.compile, but if I remember correctly, that should be less than a 2x perf difference. I don't think not using torch.compile would "undo" a significant improvement from Hyena especially because Hyena should be improving the bottleneck of the network. Of course, this is pretty straightforward to test so I can do that.

Do you have any suggestions for things to try?
Thanks!

Thanks for all the info! I pushed a small benchmarking script here for both forward and backward passes, what numbers do you see when you run it? On my end (on a single A100) I see Hyena as 5x/6x faster at batch size 1. If you use the same script and benchmark at batch size 64, you should get the FlashAttention runtime numbers of the original paper.
Regarding memory: yes at the moment without the custom kernel both memory scaling is slightly worse for Hyena w.r.t FlashAttention, though they are both linear. Doing a bit more recomputation on the backward pass helps, we're working on these optimizations.

I was just about to run a benchmark I wrote when you posted your comment :)
I modified your script to import from standalone_hyena and I can roughly reproduce your results on an A100. FlashAttention (fwd + bwd) takes ~3.8x longer than Hyena (fwd + bwd) at a seq len of 32k and batch size of 1.
Full output:
2048
/home/ubuntu/standalone_hyena.py:17: UserWarning: ComplexHalf support is experimental and many operators don't support it yet. (Triggered internally at ../aten/src/ATen/EmptyTensor.cpp:31.)
  k_f = torch.fft.rfft(k, n=fft_size) / fft_size
4096
8192
16384
32768
65536
131072
---
{2048: 0.0002955092999854969, 4096: 0.0005243146999873716, 8192: 0.0016268614999717101, 16384: 0.0051274498999646315, 32768: 0.017562666200001333, 65536: 0.06848136959997646, 131072: 0.2707951788000173}
{2048: 0.000688433300001634, 4096: 0.001220289100001537, 8192: 0.003820151900026758, 16384: 0.011008315900016895, 32768: 0.041841238200004224, 65536: 0.16533355219999066, 131072: 0.6602845148999676}
---
{2048: 0.0008685043000241421, 4096: 0.0009082306999971479, 8192: 0.0017019433000314166, 16384: 0.002847423499997603, 32768: 0.00549896880002052, 65536: 0.01111297390002619, 131072: 0.02508695080000507}
{2048: 0.0017592959000012343, 4096: 0.0017505167999843252, 8192: 0.003214542400019127, 16384: 0.005148207100000945, 32768: 0.009867695800039655, 65536: 0.02085177230001136, 131072: 0.044432145000018866}

That said, the speed difference at 64k is still "only" 7.3x vs the 100x from the paper. Any thoughts on what could be causing that?
Thanks again!

Awesome! It's all a game of batch sizes, try running at batch sizes 16, 32 and 64 and you should see the speedup get larger.

Hmm that doesn't seem to work.
At a batch size of 16 and sequence length of 32k, FlashAttention takes 3.48 times longer than Hyena (see details below).
Thoughts:

Currently, a single HyenaOperator with a batch size of 16 and seq len of 32k uses up almost all GPU memory (> 35gb on a 40GB A100) when running the benchmark. So we can't easily test any larger combos.

At that sequence length, Hyena with a batch size of 16 is ~18.7x slower than Hyena with a batch size of one. This seems to imply that batching is worse than just serially processing each sequence.

As far as I can tell, there isn't really a good reason to use a large batch size here vs a batch size of 1 + gradient accumulation.
Any ideas on what's going on?

Details:
GPU: A100 40GB SXM4
Versions:
Torch 2.0.0
flash-attn 0.2.8
einops 0.6.0

Hyena implementation permalink
Benchmark permalink
Batch size of 1
Bechmark script with batch size of 1:
2048
/home/ubuntu/standalone_hyena.py:17: UserWarning: ComplexHalf support is experimental and many operators don't support it yet. (Triggered internally at ../aten/src/ATen/EmptyTensor.cpp:31.)
  k_f = torch.fft.rfft(k, n=fft_size) / fft_size
4096
8192
16384
32768
65536
131072
---
{2048: 0.0003016873999968084, 4096: 0.0004113602999950672, 8192: 0.0012788771000032284, 16384: 0.0046683007999945405, 32768: 0.017532283400009875, 65536: 0.06853519320000032, 131072: 0.2708130353000115}
{2048: 0.0005378262000022005, 4096: 0.0009546344999989742, 8192: 0.0030730292000043847, 16384: 0.010984528699987095, 32768: 0.041858487700005755, 65536: 0.16538351169999715, 131072: 0.6592029120000007}
---
{2048: 0.0008691948000205229, 4096: 0.0009022319999985485, 8192: 0.0014434583000138446, 16384: 0.002845392300014282, 32768: 0.005500168399998983, 65536: 0.011115612699995836, 131072: 0.02511233400000492}
{2048: 0.001425099199991564, 4096: 0.0014490745000102835, 8192: 0.0027972210999905656, 16384: 0.005150951700011319, 32768: 0.009863483899994207, 65536: 0.0208421756000007, 131072: 0.044432989299980366}

Batch size of 16
Benchmark script with batch size of 16 (limited to seq len of 32k because Hyena runs out of memory at larger seq lengths):
2048
/home/ubuntu/standalone_hyena.py:17: UserWarning: ComplexHalf support is experimental and many operators don't support it yet. (Triggered internally at ../aten/src/ATen/EmptyTensor.cpp:31.)
  k_f = torch.fft.rfft(k, n=fft_size) / fft_size
4096
8192
16384
32768
---
{2048: 0.0020986096000342514, 4096: 0.0062191390999942085, 8192: 0.02071911389998604, 16384: 0.0747385351000048, 32768: 0.2817839461999938}
{2048: 0.004406064900013007, 4096: 0.014036858499957816, 8192: 0.049613316399972976, 16384: 0.1854088593999677, 32768: 0.7167293173999951}
---
{2048: 0.004067870600010792, 4096: 0.008555072500030292, 8192: 0.017019115599987346, 16384: 0.0345663336999678, 32768: 0.069258173299977}
{2048: 0.009594092299994372, 4096: 0.019340128099975117, 8192: 0.04256208110000444, 16384: 0.09568457360001048, 32768: 0.21756787399999666}

Something else I noticed is that the paper says "Hyena speedups reach 100x at sequence length 64K" and references Figure 4.3, but if you look at the LaTeX for Figure 4.3, it's actually only an 11.4x difference.
I know the paper is still a draft so is the figure (or text) outdated? Or are we interpreting the meaning of "speedup" differently?
Thanks!

Figure 4.3 from the paper:

\addplot [line width=1pt, indianred]
table {%
1024 0.9
2048 1.16
4096 1.47
8192 1.5
16384 2.84
32768 5.41
65536 11.32
};
\addplot [line width=1pt, cornflowerblue]
table {%
1024 0.4
2048 1.25
4096 2.16
8192 6.17
16384 21.74
32768 90.71
};
\addplot [line width=1pt, lightseagreen, dashed]
table {%
1024 0.29
2048 0.3
4096 0.63
8192 2.1
16384 8.33
32768 32.85
65536 129.07
};

(FlashAttention at 64k) / (Hyena at 64k) = 129.07/11.32 = ~11.4
Section 4.4 says (emphasis mine):

We benchmark runtime of an order 2 Hyena operator compared to attention and FlashAttention layers (Dao
et al., 2022b). Hyena uses a fused CUDA kernel to perform FFTConv (Dao et al., 2022c). We set batch
size to 64 and measure runtime (in milliseconds). Results are provided in Figure 4.3. Hyena speedups reach
100× at sequence length 64K. Crossover points for Hyena and attention is at length 2048, and for Hyena and
FlashAttention is between 4096 and 8196. Despite the absolute reduction in FLOPs, speedups are achieved
only on longer sequences when the gap grows sufficiently large. This occurs because hardware utilization of
Hyena is lower than FlashAttention. We expect the gap between theoretical maximum speedup to shrink
with improved implementations of FFTConv and specialized hardware.

Interesting finds, a few things here:

I wouldn't read too much in the superlinear runtime scaling you mentioned w.r.t to batch size, it's all round-off measurement errors. You can increase the number of repeats in the benchmark, and at DIM=768 the scaling will be almost perfectly linear. At smaller model widths, the scaling is also much better for Hyena:

FlashAttention: {(1, 32768): 0.011, (4, 32768): 0.048, (8, 32768): 0.098, (16, 32768): 0.1977, (32, 32768): 0.4041, (64, 32768): 0.8306}
Hyena: {(1, 32768): 0.0012, (4, 32768): 0.0024, (8, 32768): 0.0043, (16, 32768): 0.0082, (32, 32768): 0.0160, (64, 32768): 0.0346}

If the model is smaller, the speedups are larger even at shorter sequence lengths. An example is given below (again DIM=96, batch_size=64).

FlashAttention: {(64, 32768): 0.8301, (64, 65536): 3.3059, (64, 131072): 13.2732}
Hyena: {(64, 32768): 0.0346, (64, 65536): 0.0725, (64, 131072): 0.1762}

At saturation (width large enough), take the numbers in the paper and what you see running this benchmark as ground truth, and expect a few more x of speedup and memory reduction as we figure out how to optimize various operations. We'll update the paper when we do so!
If you plan to run models at DIM=768, SEQ_LEN=64k
FlashAttention:  {(1, 65536): 0.0745, (4, 65536): 0.2999, (8, 65536): 0.6023, (16, 65536): 1.2074}
Hyena: {(1, 65536): 0.0118, (4, 65536): 0.0406, (8, 65536): 0.0807, (16, 65536): 0.1806}

Thanks! That makes sense. I think it would be super useful to have a sweep over (dim, batch_size, seq_len) comparing FlashAttention and Hyena runtimes (for both forward and backward passes), but I don't think I'll be able to get to that anytime soon. Do you think you'll have time to run that sweep? It might even be worth committing to the repo or adding to a wiki so there's a place for people to quickly see potential speedups.
Thanks again!


✅ Flask/Netflix Custom Signin

closes #ISSUE-NO
What does this PR do?
netflix passwordless custom sign in using sawo and flask
Description of the task to be completed?
How can this be manually tested?
cd to the Custom-netflix-signin and run python3 app.py
Any background context you want to provide?
Is there any relevant issue to this PR?
Screenshots (if appropriate)
Questions

Hey @starlightknown is the usecase deployed so that we can check. Or can you record the screen demonstrating the usecase. This will speed up the review process


Notification Color is not OK on iOS

<h3> content is not shown with enough contrast

It might be a problem in the app (check that typography and colors modules are included in the app)

I suspect that the Lumo color.html is somehow imported and this style module include works and sets the color for the header element. So it would be working as expected.

Closing this as no-one else has reported this issue. I assume this was an issue in the test setup, that somehow both Lumo and Material styles were imported and included on the same page.


[Backport 2.x]  Repository stats for remote store

Description
Backport of  https://github.com/opensearch-project/OpenSearch/pull/10567/files
Related Issues
Resolves #8917

Check List

[x] New functionality includes testing.

[x] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff
[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)
[ ] Public documentation issue/PR created

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.

1 Failing test in gradle.
org.opensearch.search.query.QueryPhaseTests.testQueryTimeoutChecker {p0=0 p1=org.opensearch.search.query.QueryPhase$DefaultQueryPhaseSearcher@10724a72}

* What went wrong:
Execution failed for task ':distribution:bwc:minor:buildBwcLinuxTar'.
> Building 2.11.0 didn't generate expected file /var/jenkins/workspace/gradle-check/search/distribution/bwc/minor/build/bwc/checkout-2.11/distribution/archives/linux-tar/build/distributions/opensearch-min-2.11.0-SNAPSHOT-linux-x64.tar.gz


How could we set up South Polar Projection

To report a non-security related issue, please provide:

the version of the software with which you are encountering an issue
environmental information (i.e. Operating System, compiler info, java version, python version, etc.)
a description of the issue with the steps needed to reproduce it

If you have a general question about the software, please view our Suggested Support Process.

This question is probably better asked on https://stackoverflow.com or the cartopy issue tracker.


Clean code & Add dynamic variables for user-supplied entropy and 24-word mnemonics

The current version of this simple Python program lets a user create a cryptographically secure 12-word mnemonic under BIP39. The issue posted here requires that the existing code is cleaned up (condensed, or otherwise improved for speed/performance) while adding the two options below:

User chooses at the start of the app whether to supply their own entropy or for the tool to randomly create entropy.

User selects whether to use a 12-word (as it current defaults to) or a 24-word mnemonic (note: when users choose for the tool to randomly create the entropy, the option for word length will still be shown, and in all cases, the tool will also compute the check, and only allow 128 bits (not 132) for the user to add, as the tool should calculate those last 4 bits, or for 24 word mnemonics 256 bits (not 264) as the last 8 bit checksum would be calculated as part of validating the mnemonic.

About to test some of the changes*

All tests ran successfully, the tool now can generate 24 word mnemonics and accepts user-supplied entropy in the form of a 0x-padded hex string.

@Destiner please submit this work as "submitted" on Gitcoin, and I will pay the bounty (if that is not possible for you I can skip this requirement and use the advanced function to pay it out bypassing that step, please let me know, thanks!).


Add support for Solvis SC2?

Hi there,
the ModBus integration does not create a device in Homeassistant.
It seems that you achieved this - and you are talking to the Solvis SC3 via Modbus.
Do you think it would be possible to modify your integration to

differentiate between SC2 and SC3 (or would you suggest to branch this and create another integration?)
adjust the ModBus dialogues to get the right values for the SC2?
I am reasonably new to HASS... so excuse any naive questions ;-)

Hi Patrick, Started to test it - seems to work with the SC2 as well, the registers stayed the same.
Some thoughts:

It would be great to configure the registers in the respective instance to adjust them. In my Solvis, the techies changed one or two sensors. Secondly, some add registers might be interesting. Could be achieved through branching the code
it would be great to be able to use the Writ feature of Modbus (to switch WW heating on etc). looking at your code that would however mean a complete set of new functionalities etc...

I might give the first one a try (starting with a branch - new to HASS... and certainly brand new to programming HASS...)

Hi Patrick, working now on the Solvis integration of Lars -> saw the dialog on your git repo.
Best timmo


code coverity test defect

hi
will fix coverity issue ?
scan boost 1.70.0 by Coverity ,report many issues,like bellow:

Thanks for reporting this, and sorry for the late reply (ticket was in the wrong place). The fix is easy and should go in for 1.73.

version: 1.70.0
more:

@Raffi Enficiaud

The second post is not exactly related to Boost.Test but to Beat, it would be good if you post those images on the Beast project's issue tracker. Thanks!

Fixed in master for the issues related to boost/test. For the other issues, please contact @boostorg/beast team.


Fixes #371 UI got disturbed

Fixes #371
Checklist

[x] I have read the Contribution & Best practices Guide and my PR follows them.
[x] My branch is up-to-date with the Upstream master branch.
[x] I have added necessary documentation (if appropriate)

Changes proposed in this pull request:

Fixes #371 UI got disturbed.

@vaibhavsingh97 @AnshulMalik Please review

@vaibhavsingh97 Can we merge this one, so to get http://query-server.herokuapp.com/ running as earlier

Thanks for fixing 😄


Is there a way to leverage hosted fields with this?

I'm having a lot of issues getting custom CSS to do what I want via the options prop, something like (from Braintree docs):
card: {
    overrides: {
      styles: {
        input: {
          color: 'blue',
          'font-size': '18px'
        },
        '.number': {
          'font-family': 'monospace'
          // Custom web fonts are not supported. Only use system installed fonts.
        },
        '.invalid': {
          color: 'red'
        }
      }
    }
  }

I can't easily modify the label for an input, for example.
Is there a way to leverage hosted fields with this library? Or an easier way to apply custom styles?

Can you point me where you are getting those options from?
For this component, it would definitely be part of the options prop. I can help a bit more with the source!

Here is where I found the options in Braintree's documentation.

Yeah so you would use it like so:
<DropIn
  options={{
    // other options...
    card: {
      overrides: {
        fields: {
          number: {
            placeholder: 'Card Number',
            formatInput: false // Turn off automatic formatting
          }
        }
      }
    }
  }}
/>


Expose custom transforms visitor API

The JavaScript bindings for lightningcss expose a powerful API for transforming CSS: https://lightningcss.dev/transforms.html. This functionality would be valuable, especially for projects like https://github.com/pydsigner/anchovy_css.

https://docs.rs/lightningcss/1.0.0-alpha.44/lightningcss/visitor/index.html
The basis of our implementation should be a PyVisitor struct. This will have to wrap a RustVisitor struct that implements lightningcss::visitor::Visitor; Visitor itself involves lifetime parameters, which must be abstracted away from PyO3 (https://pyo3.rs/v0.19.2/class#no-lifetime-parameters).


Remove CLI tool as it's in ovos-cli-client now.

Get rid of the cli tool remnants.

these are left in here on purpose, we expose everything mycroft-core does, we can not remove the imports
when code is meant to be removed later (after 0.1.0) it goes into the mycroft.deprecated module
This code is only here for backwards compat, we do not deprecate anything in the mycroft-core public api
If i misunderstood then feel free to reopen the PR

some time back i was curious to see what our code would look like with all the backwards compat deprecated stuff removed, see https://github.com/OpenVoiceOS/ovos-core/pull/197
the whole mycroft.deprecated module will be gone at some point


Failed to execute goal org.sonarsource.scanner.maven

Seen at https://github.com/gdcc/xoai/actions/runs/11124129153/job/30909036734?pr=272#step:7:903
Error: Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:<IP_ADDRESS>21:sonar (default-cli) on project xoai: Project not found. Please check the 'sonar.projectKey' and 'sonar.organization' properties, the 'SONAR_TOKEN' environment variable, or contact the project administrator to check the permissions of the user the token belongs to

Probably because the PR was from a fork. See https://github.com/gdcc/xoai/pull/272#issuecomment-2385710453


docs: up advice and add screenshot

docs: change readme merge to master

docs: up advice and add screenshot


fix builds by supporting sparse_output renamed parameter in OneHotEncoder in new scikit-learn version update

Description
fix builds by supporting sparse_output renamed parameter in OneHotEncoder in new scikit-learn version update
Builds are failing due to a parameter rename in scikit-learn package, which just recently released a new version:
https://github.com/microsoft/responsible-ai-toolbox/actions/runs/7619055180/job/20874745412?pr=2499
                ("imputer",
                    SimpleImputer(strategy='constant', fill_value='missing')),
>               ("encoder", OneHotEncoder(sparse=False))]), ["embarked"]),
            ("sex_pclass", OneHotEncoder(sparse=False), ["sex", "pclass"])
        ])
E       TypeError: __init__() got an unexpected keyword argument 'sparse'

For more context please see scikit-learn docs:
https://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.OneHotEncoder.html
sparse_outputbool, default=True
When True, it returns a [scipy.sparse.csr_matrix](https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.csr_matrix.html#scipy.sparse.csr_matrix), i.e. a sparse matrix in “Compressed Sparse Row” (CSR) format.

New in version 1.2: sparse was renamed to sparse_output

This PR updates notebooks and test utilities to support both variants depending on the scikit-learn version in the build.
Note that rai-test-utils will need to be released at some point with the updates.  For now, I've added a local install where required in the builds.
Checklist

[x] I have added screenshots above for all UI changes.
[x] I have added e2e tests for all UI changes.
[x] Documentation was updated if it was needed.

Codecov Report
Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (7ff3476) 83.05% compared to head (2943867) 88.14%.

Files
Patch %
Lines

...i_test_utils/models/sklearn/sklearn_model_utils.py
25.00%
3 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2507      +/-   ##
==========================================
+ Coverage   83.05%   88.14%   +5.09%
==========================================
  Files          65       39      -26
  Lines        3169      852    -2317
==========================================
- Hits         2632      751    -1881
+ Misses        537      101     -436

Flag
Coverage Δ

unittests
88.14% <25.00%> (+5.09%)
:arrow_up:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


MBL-1696: AddOns add button lost state

📲 What

After selecting addOns, if an scroll event takes place, the UI forgot the state

| Before 🐛 |
https://github.com/user-attachments/assets/7a4bf3a1-cc3f-4e19-949e-c7b8fdfc7796
| After 🦋 |
https://github.com/user-attachments/assets/8aef8e18-2302-456b-b222-5507031c2598
| --- | --- |
|  |  |
📋 QA

Go to any project with several addOns, scroll to the bottom, select addOns, scroll up and down a few times, the selected number of addOns should state the same.

Story 📖
MBL-1696

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 67.60%. Comparing base (8fcbaf0) to head (17ca649).

Files with missing lines
Patch %
Lines

.../activities/compose/projectpage/AddOnsContainer.kt
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##             master    #2120   +/-   ##
=========================================
  Coverage     67.60%   67.60%
  Complexity     2195     2195
=========================================
  Files           367      367
  Lines         22619    22619
  Branches       3255     3255
=========================================
+ Hits          15291    15292    +1
+ Misses         5575     5574    -1
  Partials       1753     1753

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Return list of sources

To allow implementation of https://github.com/TheAsel/BYBE-frontend/issues/4 we should return the list of sources

fixed: #30


shadows of tileset does not work when using 3dtiles next

I find that shadows property does not work when using 3dtiles next.
const tileset = new Cesium3DTileset({
  url: 'http://xxx/xxx/xxx/tileset.json',
  backFaceCulling: false,
  shadows: ShadowMode.DISABLED,
})

Here's a pr for this: https://github.com/CesiumGS/cesium/pull/10131

@ptrgags Can you verify if this is expected behavior or a regression?


[Docs] Meshery release docs needs some update

Current State
For now some release versions are not present in the doc site
Desired State
The doc must be updated with relevant release pages
Contributor Resources

Meshery documentation site
Meshery documentation source
Instructions for contributing to documentation
Layer5 Community Slack

@alphaX86 🎉


Nested folders won't open in v1.7

On clicking a nested folder, it closes the parent folder. Renaming also doesn't work.

@paddy1228, does the #10574 sound like the issue you're seeing? Basically, right now you need to click on the name of the nested folder to close/open it. Clicking on the area left to it will result in collapsing the parent folder. Is this what you're seeing?

#10574 should be fixed in 1.8.
If that is not the problem you were seeing please reopen.


refactoring for new husky grid style

__ Pull-Request __:

https://github.com/massiveart/husky/pull/500

tasks:

[ ] gather feedback for my changes

informations:

q
a

Fixed tickets
none

@marcelmoosbrugger looks good to me! please add upgrade and changelog line

TODOs:

Collection => Files selectbox in the header of the datagrid is not clickable
Permission datagrid in roles select all link is gray (should be black)


Readability and style fixes to user-data-cleanup

Added eslint configuration copied from Angular.
Fixed most eslint errors and warnings.
Fixed Flychecker warnings of violations of Google style.
Made demo app work with older browser, by removing const and arrow functions.
Did some minor code simplifications, and readability improvements, such as replacing
some if-else-ifs with switch-cases and reformatting line-breaking in test code.

Fixed conflicts with base branch.

Help

For the ESlint config, you can extend the published Google rules. For instance, this is the .eslintrc file I usually use for web apps:
{
  "extends": "google",
  "env": {
    "browser": true
  },
  "rules": {
    "camelcase": 0,
    "default-case": 0,
    "max-len": 0,
    "max-nested-callbacks": 0,
    "no-inline-comments": 0,
    "no-warning-comments": 0,
    "require-jsdoc": 0,
    "valid-jsdoc": 0,
    "no-implicit-coercion": [2, {
      "boolean": false,
      "number": true,
      "string": true
    }],
    "no-unused-vars": [2, {
      "vars": "all",
      "args": "after-used",
      "argsIgnorePattern": "^var_args$"
    }],
    "no-negated-condition": 0
  },
  "globals": {
    "$": true,
    "firebaseUi": true,
    "uiConfig": true,
    "jQuery": true,
    "ga": true,
    "firebase": true,
    "gapi": true
  }
}

Otherwise LGTM :)

Changed eslint to use published Google rules and tweaked code to fix style errors found.
Also fixed bug found in initialization, and cleaned up HTML template of demo app a bit.

Looks good! :)


Traverse nested list items

Pre-merge checklist

[ ] code has been tested in Node and all major browsers WIP
[x] accompanying tests are written and passing
[x] npm install passes with no errors
[x] npm run lint passes with no errors

Description of changes
This is an initial attempt to parse nested lists. I haven't done much of refactoring as I need to use it quickly and the change is not that huge.
Reason for changes or related GitHub issue
https://github.com/aem/docs-soap/issues/2
@aem

[Current coverage][cc-pull] is 94.77%

No coverage report found for master at 7e471e0.

Powered by Codecov. Last updated by [7e471e0...7272ef3][cc-compare]
[cc-base-branch]: https://codecov.io/gh/aem/docs-soap/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/aem/docs-soap/compare/7e471e04d52d7208df1bf9f3f3e1b43163587736...7272ef3043d8de68c3c1950f4b91cb006074c37c?src=pr
[cc-pull]: https://codecov.io/gh/aem/docs-soap/pull/16?src=pr

i'm ok to merge this despite the codecov checks, and after that I'm going to turn off the patch checks from codecov because they seem to be calculated poorly.

@LeZuse let me know when you're satisfied with browser testing and i'll merge and publish a new version

@aem Just finished browser testing. Safari, Chrome, Firefox. I tried testing IE, but the access to html clipboard is a pain there.

Alright, sounds good. At some point soon I'm planning on throwing together an example page that can be loaded in any browser for testing purposes, but haven't gotten around to it


[feature] Machinery to highlight unknown flags (and doc) | #BAZEL-1186

This adds basic machinery to resolve flag names as Symbol and to be able to extract documentation for them.
It also adds an annotator highlighting unknown flags.
It has halfway done flags database (pulled from bazel help build output only) that will be enhanced to include flags from all commands and tags and more typing of flags such in subsequent PRs
Examples:
Doc

Error

Oh wow, that's really impressive! Thanks!

Wow, THAT IS really impressive! Amazing functionality, thank you for contribution!


FUSETOOLS2-2120 - Provide Camel Quarkus debug profile in completion

https://github.com/camel-tooling/camel-language-server/assets/1105127/e4b31b42-6c9c-4b60-a142-1c24cf0ac01f
ideas for other iterations:

provide completion only inside a profiles block
provide completion only when it is a Camel Quarkus project
include profiles block when not available

worthy to mention in changelog?

Yes, I need to create the PR in VS Code Camel LSP. Thanks for the reminder


Interesting and probably unwanted behaviour for strain_interaction_to_cross_immunity

The utils function to convert strain interaction to cross immunity can produce some counterintuitive cross immunity matrix.
import numpy as np
from utils import strain_interaction_to_cross_immunity

interact = np.array([[0.6, 1.0], [0.3, 1.0]])

strain_interaction_to_cross_immunity(2, interact)
# Array([[0. , 0.6, 1. , 0.6],
#        [0. , 0.3, 1. , 1. ]], dtype=float32)

So in this case, if we say that the "interaction" for:

challenging strain 1 to a strain 1 infected is 0.6, and
challenging strain 1 to strain 2 infected is 1.0

A person who is infected by strain 2 only has cross immunity of 1.0 towards challenging strain 1, but if they are infected by both strain 1 & 2, their cross immunity drops to 0.6 towards challenging strain 1.

labeling wontfix for now since this is something that should be on our radar but is not actively going to be worked on


fixed OCI image import bug

Description

It's an attempt to solve the issue faced by getOci
What does this PR do?

this PR added a new logic as said to retrieve the file and return it
Types of changes

[x] Bug fix (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)
[ ] New chore (expected functionality to be implemented)

Checklist:

[ ] My change requires a change to the documentation.

[ ] I have updated the documentation accordingly.

[x] I've signed off with an email address that matches the commit author.

@7h3-3mp7y-m4n anything else here, or can I merge this for you?

@7h3-3mp7y-m4n anything else here, or can I merge this for you?

No , You can merge it :)


Load order broken with loading from save files

I believe this happens when a cube is saved, with no column saved, which often happens on a crash / kill

This may have been fixed in 4fad255f3566355fde4982a5e7dde6ea47db4e0e, will do some testing


WhatsappApiException not expose the status code

Sorry for the late reply @Bindambc,

I can modify the class WhatsappApiException by adding a method called getWhatsappApiError() that will allow obtaining the error object. Within the error object, you will be able to check the error codes sent by WhatsApp API.

Yes is perfect because the class WhatsappApiException return only the message of the exception throwed from API.

I could also return the HTTP code, but I'm not sure if it would be helpful. Note that in the case of media not found, the HTTP code is 400.

I think that is the best way to register the HTTP status code in the WhatsappApiError and expose it with public int getHttpStatusCode().
I hope that is useful 😀.
Thanks,
Giuseppe.
Originally posted by @pcomp96 in https://github.com/Bindambc/whatsapp-business-java-api/issues/107#issuecomment-1685826059

https://github.com/Bindambc/whatsapp-business-java-api/pull/168


multiples errors to use the framwork

any advice?....

My best guess is that your zombie doesn't have write permissions to the target directory defined in exec_cmd. Either run the stager from an elevated command prompt or change the target directory. Default directory is %TEMP% which should be world writeable, weird if it isn't.


Add support for Boat (USV) in SITL gazebo

Describe problem solved by this pull request
Recently there has been interest on using PX4 on USV (unmanned surface vehicle) systems. This PR adapts the usv_dynamics plugin from the vrx simulation and integrates the boat simulation into px4 SITL.
As PX4 does not officially support boats yet, I hope this PR becomes a initial step towards supporting such applications.
Describe your solution
Integrate usv_dynamics plugin from the vrx into px4/sitl_gazebo
Test Data Coverage
The video below shows the WAM-V vehicle being controlled in manual mode.

Video: link
Additional context
Implementation in https://github.com/PX4/sitl_gazebo/pull/409

Try setting up a new rover configs for it. It should just work.

Here is the log of the boat trying to do mission: log
It seems like the assumption rover was making

Velocity is always in the direction of heading
Steering input translates to lateral acceleration

Makes the boat position controller get into those oscillations. Nevertheless, improvements in the rover position controller will come in a different PR, so not a deal breaker for this PR


On docs when try select code all page is selected

When I try select part of code of docs page all page is selected, this happening with you too?
Just only one click select all text of page 😡

Windows 10
Chrome 54 (64 bits)

Workaround for Chrome:
Right click on page > Inspect > In Chrome's webtools select the body element > Under styles - body untick user-select: all;

Hi,
Thank you very much for opening this issue.
I just fixed it!

@jack828 thanks
@Qathom Thanks, fixed


Add 3D graphing via square approximation.

While this isn't perfect, it is a way to graph a 3D surface using square approximations. (Also apparently some linting got in, which I can change if necessary.)

Meant to address #143

Really what's needed here is a different type of mobject built on a 3d graphics library.  Eventually, it'll be worth taking the time to implement that, but trying to make the vectorized Mobjects behave like curved surfaces is just going to be way too slow, and likely not great looking.


specify exact prometheus image tag

I would suggest specifying an exact tag, avoid latest. Your prometheus config breaks with prometheus 2.
Changing to this in main.yml got prometheus up:
prometheus_image_tag: v1.8.2

Thanks! Maybe you could create a PR? :)

All done. May have more pull requests in time ...

Sure, looking forward! :)


Added "Enable Clipboard" feature

Added Preferences menu and fragment layout
Clipboard choice is persisted by default
Gated the auto-copy/paste on select using this setting
SharedPreferences is MODE_PRIVATE by default. This mitigates tamper here
There may still be some layout/theming/phrasing choices to be made later
Manually verified, but with UI changes I think we should manually test more extensively

Fixes freeotp/freeotp-android#63

This would be very nice! Thanks

I would suggest #66 makes this a critical issue, but the default value should be changed to false.

@joekir I have bluetooth sharing almost working (I haven't pushed the patch yet). This feature is implemented via a "share" menu. In this patch set we disable clipboard by default and move it to the share target. So basically, you click "share" on a token and you get a list of places you can share the code:

Clipboard
Nearby Bluetooth Devices
Et cetera...

This accomplishes the same thing as your patch but in a different, and I think cleaner, way. For this reason, I'm closing this PR. Look for this feature to land shortly.

Yeah I think I recall discussing this previously, sounds good to me.


Container Count pop-up blocks the container icon and count.

v0.38.0
UI v0.49.0

No longer relevant in new UI.


Incorrect display of function/class argument types in documentation.

Describe the bug
Incorrect display of function/class argument types in documentation.
Expected behavior
I would expect to just see a display of arguments with a simple type e.g. my function(arg1: NDArray)
Screenshots

Desktop (please complete the following information):

OS: MacOS 14
Safari

Additional context
Add any other context about the problem here.

Possible solution:
Create a python file with the following contents and add to sphinx project:
`# sphinx_initvar_filter.py
from sphinx.ext.autodoc import ClassDocumenter, ModuleLevelDocumenter
from sphinx.util.inspect import getdoc
from sphinx.util import logging
logger = logging.getLogger(name)
class InitVarFilterDocumenter(ClassDocumenter):
def add_directive_header(self, sig):
self.options.noindex = True
super().add_directive_header(sig)
self.options.noindex = False
def filter_members(self, members, want_all):
    filtered_members = []
    for name, obj in members:
        if not name.startswith('__') and 'InitVar' not in str(obj):
            filtered_members.append((name, obj))
        else:
            logger.info(f'Filtering out: {name} ({obj})')
    return filtered_members

def setup(app):
app.add_autodocumenter(InitVarFilterDocumenter)`
Then modify conf.py to include the custom operation:
`# conf.py
extensions = [
'sphinx.ext.autodoc',
'sphinx_autodoc_typehints',
'sphinx.ext.napoleon',
'sphinx_initvar_filter'  # Add your custom extension here
]
autodoc_typehints = "description"
autodoc_typehints_format = "short"`

Hasn't been tried and tested yet

also more in pressure submodule:

This looks relevant:
https://stackoverflow.com/questions/67473396/shorten-display-format-of-python-type-annotations-in-sphinx

Nice find.
is there a simple way to build the docs locally to test the changes?

Should be able just to do cd docs; poetry run make html. All the requirements for docs are included in the poetry requirements. It doesn't seem to work though 😢

Should be able just to do cd docs; poetry run make html. All the requirements for docs are included in the poetry requirements. It doesn't seem to work though 😢

It does work for me.

Hm, I tried adding
autodoc_typehints_format = 'short'
python_use_unqualified_type_names = True

to conf.py , running sphinx-apidoc, and a couple of other things suggested on stackoverflow&Co, but it seems to make no difference whatsoever. I am wondering whether I need to regenerate something further down?


[BEAM-7523] Fix starting Kafka container twice in KafkaCSVTableIT

I made a mistake and Kafka Container starts twice in KafkaCSVTableIT (@Rule KafkaContainer makes it start and stop automatically). It may result in leaving redundant containers on the VMs.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

@TheNeuralBit Could you review this? I think it's worth to have it done asap.

Looks like moving the imports around broke spotless, I'll push a commit to fix so we can get this merged today.

Looks like moving the imports around broke spotless, I'll push a commit to fix so we can get this merged today.

Sorry, I even had this commited locally yesterday but in the meantime I got a food poisoning and just forgot to push it.

Run SQL PostCommit

Sorry to hear about the food poisoning, hope you're feeling better now :)

I was up and running the next day, thank you :)


If run only one pods on specific node, reboot will cause something

IF create a workload with this config, and only deploy one pod.

When recreate the pod, it will persist start more and more pods until someone start success.

and the system won't clean the failed pods .

Useful
Info

Versions
Rancher v2.0.6 UI: v2.0.61

Access
`` admin

Route
containers.run

Type deployment and deamonset have the same problem.

Please select stop old pods, then start new in upgrade policy section as you are using hostPort.
K8s doesn't clean it up. You can find some script to remove the failed pod.
We will support bulk delete in worklaod detail page. So you can select all and remove the failed pod in one go from the UI

Please let us know in a comment if you can still reproduce the issue, and we'll reopen it