Relicense under dual MIT/Apache-2.0

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.
You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.
TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.
Why?
The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.
Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.
How?
To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:
## License

Licensed under either of

 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):
// Copyright 2016 urlencoded developers
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.
Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.
And don't forget to update the license metadata in your Cargo.toml to:
license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!
Contributor checkoff
To agree to relicensing, comment with :
I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

[ ] @reem
[ ] @theptrk
[ ] @zzmp
[ ] @cmr
[ ] @fsommar
[ ] @michaelsproul
[ ] @ehiggs
[ ] @AerialX
[ ] @brycefisher
[ ] @EduardoBautista
[ ] @jgelens
[ ] @untitaker
[ ] @trotter

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.
Patrick

On Jan 10, 2016, at 7:28 PM, Michael Sproul<EMAIL_ADDRESS>wrote:
I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.
—
Reply to this email directly or view it on GitHub.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.


Should Matrix really be heap-allocated here?

https://github.com/IliaFeldgun/cpp-noob/blob/01dbd16aabe106846e3bc9a19f9def34ac29343f/main.cpp#L14
Food for thought.
https://stackoverflow.com/a/79936

I think the size is always dynamic (I want it to stretch fullscreen eventually), but I'll try to see if I can get it to compile without heap.

Less heap more stack.


handle TRAPI v1.2 "operations" in query

TRAPI v1.2 queries/requests will include a "workflow" field like this:
{
    "message": ...,  // query_graph is in here
    "workflow": [
        {"id": "lookup"}
    ]
}

BTE's behavior: we plan to only support doing the "lookup" operation of a workflow (Translator documentation here)

Case 1
BTE either:
A. Gets a TRAPI query/request like the example above. There's 1 object in the workflow's array, and the id is "lookup"...
B. Gets a TRAPI query/request with no workflow field
Desired behavior:

BTE can do its normal behavior using the message.query_graph...
BTE's response should include the same workflow info that was in the query. So it should look like this:

{
    "message": ...,  // query graph, knowledge_graph, results are in here
    "workflow": [
        {"id": "lookup"}
    ]
}

Case 2
BTE encounters situations different from the two above. Maybe the object in the workflow array isn't {"id:lookup"}; or maybe there are multiple objects in the workflow array other than {"id:lookup"}.
Desired behavior:

Don't go forward with parsing the message.query_graph.
Return something like the JSON in the code block below:

no workflow field. since BTE didn't do anything
status field should be "400" (I'm still clarifying which error code to use)
description field can be anything. We could put something like "HTTP error code 400: BTE doesn't perform one or more of the operations specified in the query's workflow field"

{
    "message": {
         "query_graph": ...,                                   // the query graph that was in the submitted query
         "knowledge_graph": { "nodes": {}, "edges": {} },      // empty objects since we didn't do anything
         "results": []                                        // empty array since we didn't do anything
    },
    "status": "400",
    "description": "HTTP error code 400: BTE doesn't perform one or more of the operations specified in the query's workflow field"
}

I think to make it backward compatible with our other example queries, what do people think about this behavior:

If workflow is specified and "id": "lookup" is included, --OR-- no workflow is specified: follow case 1 described in @colleenXu's comment above
If workflow is specified but "id": "lookup" is NOT included: follow case 2 above

@andrewsu @ericz1803 I'm updating the comment with Andrew's feedback and what I know from Translator so far.
I think the Translator guidance says that if a tool is given a query with MULTIPLE operations (including lookup), and the tool can only do lookup, it shouldn't do anything - it should return an error.
So that's the caveat I would add to what Andrew has said above...

Great, I updated my previous comment to better align with the case that Colleen mentioned above for multiple operations. @ericz1803, please confirm your PRs follow the rules above (or adjust accordingly), then post a comment here.
Completion deadline of 2021-09-01, but would be great to get this done far before then.

Yup, it will return an error if the length of the workflow array is anything other than 1.

confirmed the following correct behavior using a local instance:

a TRAPI query without the workflow field works normally, returns a Response with the workflow field ({id: lookup})
a TRAPI query with the workflow field ({id: lookup}) works normally, returns a Response with the workflow field ({id: lookup})
a TRAPI query with the workflow field with multiple elements (like two {id: lookup}) or 1 element that isn't {id:hi}...doesn't work normally + does returns empty knowledge_graph / results, status code 400, and description: "WorkflowError: BTE doesn't handle the operations specified in the workflow field."


push to cloud-director-app-collection

push to cloud-director-app-collection

@QuentinBisson same issue here again, helm chart needs some work to make abs happy


Improve handling of resource arrays for D3D12

When getting read only resources from the pipe state, stitch back up according to the bindpoint mappings.
When displaying resources in UI, don't traverse unbounded arrays and just display the size as [unbounded]
Fix resource swizzle on load/sample/gather instructions, which happens on fetch result, not on the source operand. This was causing certain ways to index into resource arrays to use the wrong register.
Added more tests for unbounded arrays and different ways to index into arrays.

Looks like I'm unable to link this to an issue. Could you please link it to #1771?

The Refs #xxx needs to be in the commit message to get automatically picked up by github. Mentioning it in the PR description or a comment as you've done achieves the same result though.


ClientDetailsUserDetailsService cannot anymore support empty secret

Summary
up to verion 2.4.0, the method ClientDetailsUserDetailsService.setPasswordEncoder was called while initializing DaoAuthenticationProvider (see https://github.com/spring-projects/spring-security-oauth/blob/6234826671d75632d84c524da1dd8818cee1b4c2/spring-security-oauth2/src/main/java/org/springframework/security/oauth2/config/annotation/web/configurers/AuthorizationServerSecurityConfigurer.java#L139)
Actual Behavior
since 2.5.0 this is not the case anymore. Change was made with https://github.com/spring-projects/spring-security-oauth/commit/b478e803197d84a8054217365e1fa60e4606acba
Version
2.5.0

@barclay-reg Can you please provide more detail as it's not clear to me if you're having a specific issue. Can you put together a test or a minimal sample that reproduces the issue.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


Dont enable bevy_remote by default

Objective

I dont think we want bevy_remote enable by default until our editor is out.

Solution

Disable it

I have updated the example config, hope everything is good now


#117 - Completed.

@rultor merge

@rultor merge

@driver733 OK, I'll try to merge now. You can check the progress of the merge here

Coverage increased (+1.1%) to 79.265% when pulling a21e1a19dd74a3321f1326df8e22df495d9938e2 on #117 into aade9f2e5440b20e7162e37fc1aab2251630c9ea on master.

@rultor merge

@driver733 Done! FYI, the full log is here (took me 5min)


Update fieldset styling

… legend tag for better visibility.
As requested in issue #7428

[x] Changes have been thoroughly tested to not break existing functionality.
[x] New functionality has been documented or existing documentation has been updated to reflect changes.
[x] Visual changes are explained in the PR description using a screenshot/recording of before and after.

Before:

After:

Since the fieldset can be used on a variety of backgrounds (e.g. wrapped in a section or not), we can't just apply a background color to the label.
Could you refactor this use a border instead of ring, remove the backgrounds and shadow, @falko100?
Only downside is that the border will be inside the element instead of outside like the ring, but there is no other way to return the default fieldset behavior where the border doesn't cut through the label.

New version:

Thanks guys!


Suggestions for improvements

I know you guys are trying to finish up v1.2, but here's some suggestions for features/updated for 1.3 (or whatever version will be next):

Single Blog features are currently missing. There's no way to set/get the custom fields & get posts by category when in Single Blog mode. Perhaps the way to address that is to make the "admin" (or first) profile the default profile if no other profile is chosen?

Create a setting for "AdminRoute" that is equivalent to "BlogRoute" so that we can customize the blog admin path.

Add a (tinymce) field to "Profile" settings so that authors can write up a description for themselves. Then, clicking on the name of the author on a post (for example) could take you to their public profile page which talks about the author. From there, you could view their posts, etc.

Featured posts support

I've slowly been making progress on creating my own theme for Blogifier. There are still some public APIs that I needed to create to make this happen. Some of them are meant to address the points I raised above. I have a github repo for my theme.  If you're interested in which APIs I needed to add (in case you want to add something similar to Blogifier), you can find them at https://github.com/murst/Blogifier-Angular-Material

Awesome, I"m keeping an eye on all the suggestions here, even if not answered directly they all carefully considered.

Can I also add a method on either the public or private API that can be called for Sitemap generation by the parent app. All the current methods use paging.

@Nikkinoodl,
You can actually do that already. I have a sitemap in my WebApp project. You can see how I'm getting those posts and adapt it to your website:
Source: SitemapController
Example XML Sitemap

Thanks Murst.  I've done something similar already with my own website app, but it's less elegant than your solution.  Thanks!

Also if you see any problem with the UI on any device let me know. We are going to release 1.2 next week.
CC: @murst, @Nikkinoodl

Hey Francis - I've got 1.2.2 up and running. It looks great and is very stable. In terms of UI the only changes I made to the Admin app were to include some extra features in the TinyMCE toobar and context menus:
Toolbar: undo, redo, indent and outdent  - these make the editor easier to use
Context menu: image - this gives the ability to easily add 'alt' text and resize any images.
Thanks!
Simon


feat(CMSIS): Update CMSIS-DSP Library to v1.16.2

Description
Closes #1162 and #1099

Update CMSIS-DSP library to v1.16.2

Biggest change is the update to how code size optimizations are handled (See code size).  We should update the ARM-DSP examples in a follow-up PR.

Add the CMSIS_DSP_VERSION build config variable (default 1.16.2) to support future version updates better.

Update CMSIS-DSP documentation in UG, point to latest v1.16.2 documentation

Checklist Before Requesting Review

[ ] PR Title follows correct guidelines.
[ ] Description of changes and all other relevant information.
[ ] (Optional) Link any related GitHub issues using a keyword
[ ] (Optional) Provide info on any relevant functional testing/validation.  For API changes or significant features, this is not optional.

Pull in the latest code from main to add the fix for the "Basic Examples Test". The CI has an older ME18 revision attached which does not have the latest cache fix. Eric added this workaround for now until the latest ME18EVKITs are in stock: https://github.com/analogdevicesinc/msdk/pull/1176


Use stable rdmd instead of assuming libphobos.a is built

Previously, posix.mak assumed libphobos.a inside ../phobos was built and usable with dmd -L-L. As there is no rule in the makefile to enforce this dependency, a clean build of dlang.org would always fail.
This change causes the stable rdmd (which is downloaded and unpacked to /tmp) to be used instead.

alrighty then

Wait

well?

https://github.com/D-Programming-Language/dlang.org/pull/1020


Consider adding markup for UI

I know flutter is supposed to be efficient because we write all kind of code with dart and have to learn only one language and it prevents us from switching between different type of code, but the reality is markup like html, xml and xaml have been used for many years now in order to construct User Interface and developers are already very comfortable with it.
On one hand in every development stack we are promoting separation of concerns with MVVM and MVC etc because it keeps code testable and maintainable, but here in flutter we are doing the opposite.
Why markup is better and only using dart can create problems?

widgets get too much nested and we have to create methods and classes in order to keep them organized and readable.

markup is always easy to read in terms of creating UI.

markup requires far lesser code than backend code, for example if I want to put padding to a widget in  markup I will only add a property named padding but in dart I need to add an extra widget just to add padding.

markup promotes separation of concerns with MVVM.

markup can visually be so readable that you can recognize the number of widgets nested just with one glance at the code.

we switch between files anyway because when we try to keep dart code clean we create reusable widgets and put them in seperate files, then put models in separate file and we try to put every small working part of the app in separate file, sometimes a small widget can grow up to 2, 3 files along with its functionality, but the problem is it is all in dart code, so it can be confusing which is a widget and which is logic files, with markup we can avoid this confusion.

referring to the issue ( https://github.com/flutter/flutter/issues/9624 ) I would like to disagree because markup still allows you be fully dynamic and there are many straightforward ways to be fully dynamic with the markup, using third party solutions to convert markup into widgets is not a stable solution of this problem I think, unless some third party library is adopted by core flutter team.

I am sure there are many other pros and cons to each way as well please do share you thoughts here as well.

Lastly we can still keep the option to create widgets with dart ( backend code ) like many frameworks allow that today, but it would be great if we can bring the option to create the UI and also style the UI with a single markup language with something like xml.

This was discussed a lot already.
See also #11609, #15922.


Update Cloudflare IP ranges list

Cloudflare is making infrastructure changes to simplify customer configuration, and reduce the number of IPv4 addresses that could potentially interact with your origin on Cloudflare’s behalf.
If your security model relies on allowing a list of trusted Cloudflare IPs from cloudflare.com/ips (or via API) on your origin, please make the following changes to your allow list by May 7, 2021. This change is safe to make today.
Remove:
<IP_ADDRESS>/12
Add:
<IP_ADDRESS>/13
<IP_ADDRESS>/14
This change delists the <IP_ADDRESS>/14 prefix, which is no longer in use by Cloudflare infrastructure. These addresses will be repurposed for use with our Gateway and WARP (secure web gateway and VPN) products, and may carry traffic from untrusted sources in the future.

Thank you @kyori19, much appreciated the explanation and pull request.


Add CODEOWNERS again

Apparently I screwed up merging in Graphite.

Current dependencies on/for this PR:

main

PR #2

PR #5   👈

This stack of pull requests is managed by Graphite.


How to make it works with http ?

is there any answer here? thanks

You can't make it work with http. You need https because getUserMedia requires https.


Dequeue projects before running LfMerge

This should ensure that LF doesn't get "stuck" thinking the project is pending. Now, what can happen is that LF's pending message disappears a second or so before the project starts the S/R process, but that's not a bad experience from the user's point of view.

This change is

Review status: 0 of 5 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

src/LfMergeQueueManager/QueueManager.cs, line 56 at r1 (raw file):

							modelVersion, true);

						// TODO: If LfMerge fails, should we re-queue the project, or not?

no, we should not requeue

Comments from Reviewable

I don't see much difference compared to #30 (except that we return an error code that we don't use), but that doesn't matter.

Reviewed 5 of 5 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

Comments from Reviewable

Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable

There's no real benefit to this one over #30, except that having the error code gives us some future flexibility (for example, if we ever decide that we do want to requeue projects under certain conditions). If I had realized ahead of time that this PR would essentially end up the same as #30, I would have just merged #30 instead.


Close #1481 verify if set onlye scale

Verification if set only Scale to MysqlAdapter

Any chance we can have a small test case?

ping @HDias

ping

Closing due to no activity.


Update binary.java

Please sort the array using bubble sort

the code is just for the binary search, it is automatically assumed the array has been sorted already.


Cave spider bug

*Description of issue:
I can't make the cave spiders worth some money and xp, when I kill them I gain nothing. Every other mob is fine.
I tried to put CAVESPIDER, CAVE_SPIDER, Cave_spider, Cavespider, cavespider, CaveSpider and Cave_Spider, nothing works.
There's no error on the console, neither when I reload the plugin nor when I kill a cave spider.
CONFIG SECTION:
    Kill:
      CAVE_SPIDER:
        income: 12
        points: 20
        experience: 30

Server Type (Spigot/Paperspigot/etc):
Spigot
Server Version (using /ver):
1.12.2

You should enable pay-near-spawner option in generalConfig file.

I didn't try with spawner spiders, I spawned them manually with mob eggs

You still need to enable it because this option applies to simple spawner and manual spawner (spawner egg).

Ok I'll try it, thanks


Nullsafety

Hi @bsneider . This is what I have after making some fields late instead of nullable. I figured it was easier to share this way than try to describe all of the changes.

@rorystephenson  just gotta resolve the merge conflicts, and I'll merge it. Nice work!


what about streaming data?

Cool project.
Have you tried any of these with streaming data?
I opened an issue on the dygraphs github repository
where for a range slider I had the problem of updating the range slider handles.
https://github.com/danvk/dygraphs/issues/578
http://jsfiddle.net/7w99t15x/

Thanks.
Doing live loading while zooming is possible, but the user interactions can get complex. For example, what do you expect to happen while the user is dragging the range selector and new data is still loading?  There are multiple possibilities.
I have started a live loading example in my dynamic data loading and zooming samples here that I might eventually publish. However, the live loading is mostly independent of the techniques I am showing here.  I'm going to close the issue here and add comment to your related issue on the official dygraphs repository that might help you.

In case still following this, I finally published an example showing the technique with continuous live data:

https://kaliatech.github.io/dygraphs-dynamiczooming-example/example6.html


Add dotnet core support in ASC

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

This change is

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it microsoft/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/metacpp/azure-cli-extensions.git@master#subdirectory=src/$EXT&egg=$EXT"

@metacpp seems this is pure vendored SDK change. you'll add more commits later right?

@metacpp Hi Su, please add @ShichaoQiu as reviewer as well. He is currently the dev owner for the extension.

seems no test for this steeltoe. Can you pls add some test?


Add curly braces at the if...else with multiple statements, and add ; at…

… the end of the line.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Reason: Since your PR was create, the master branch content has updated making some of your changes unnecessary.  Please re-sync your fork so you are looking at the latest version of master and then create a new PR if you find any changes warranted.
Thank you and happy coding.


CatalogUI-2.16.1 hotfix

External release notes for CatalogUI hotfix release 2.16.1

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.suyeb siddiqui seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Bug: derive_param_confirmed_bor() does not account for ref_start_window in CR -> PR sequence

What happened?
For a sequence of overall responses of CR -> PR, the minimum duration for SD (reflected by ref_start_window) is not accounted for and also if the initial CR does not fulfill the minimum duration for SD, a CBOR of SD is returned in such cases.
For confirmed BOR RECIST v1.1 states:

Hence, for cases in which the initial CR does not meet the minimum duration for SD, PD should be returned as CBOR for CR -> PR sequences.
Please compare reproducible example below: in case 1 the initial CR meets the minimum duration for SD, while in case 2 the minimum duration for SD is not met by the initial CR. Hence, according to RECIST v1.1 case 2 should be PD as CBOR. However, in both cases SD is returned as CBOR by derive_param_confirmed_bor().
Session Information
R version 4.2.2 (2022-10-31 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19045)
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.utf8  LC_CTYPE=English_United States.utf8
[3] LC_MONETARY=English_United States.utf8 LC_NUMERIC=C
[5] LC_TIME=English_United States.utf8
attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base
other attached packages:
[1] stringr_1.5.1         lubridate_1.9.1       pharmaverseadam_0.2.0
[4] pharmaversesdtm_0.2.0 dplyr_1.1.4           admiralonco_1.0.0
[7] admiral_1.0.0
loaded via a namespace (and not attached):
[1] rstudioapi_0.14  magrittr_2.0.3   hms_1.1.2        tidyselect_1.2.0 timechange_0.2.0
[6] R6_2.5.1         rlang_1.1.1      fansi_1.0.4      tools_4.2.2      utf8_1.2.2
[11] cli_3.6.0        withr_2.5.2      ellipsis_0.3.2   tibble_3.2.1     lifecycle_1.0.4
[16] tzdb_0.3.0       readr_2.1.3      purrr_1.0.1      tidyr_1.3.0      vctrs_0.6.4
[21] glue_1.6.2       haven_2.5.1      admiraldev_1.0.0 stringi_1.7.12   compiler_4.2.2
[26] pillar_1.9.0     forcats_1.0.0    generics_0.1.3   pkgconfig_2.0.3
Reproducible Example
adsl <- tibble::tribble(
  ~USUBJID, ~TRTSDTC,
  "1",      "2023-01-01",
  "2",      "2023-01-01"
) %>%
  mutate(
    TRTSDT = lubridate::ymd(TRTSDTC),
    STUDYID = "REPREX"
  )

adrs <- tibble::tribble(
  ~USUBJID, ~ADTC,        ~AVALC,
  "1",      "2023-02-26", "CR",
  "1",      "2023-04-23", "PR",
  "2",      "2023-01-29", "CR",
  "2",      "2023-03-16", "PR"
) %>%
  mutate(PARAMCD = "OVR") %>%
  mutate(
    ADT = lubridate::ymd(ADTC),
    STUDYID = "REPREX"
  ) %>%
  derive_vars_merged(
    dataset_add = adsl,
    by_vars = exprs(STUDYID, USUBJID),
    new_vars = exprs(TRTSDT)
  )

pd_date <- admiral::date_source(
  dataset_name = "adrs",
  date = ADT,
  filter = PARAMCD == "PD"
)

cbor <- adrs %>%
  derive_param_confirmed_bor(
  dataset_adsl = adsl,
  filter_source = PARAMCD == "OVR",
  source_pd = pd_date,
  source_datasets = list(adrs = adrs),
  reference_date = TRTSDT,
  ref_start_window = 42,
  ref_confirm = 28,
  set_values_to = exprs(
    PARAMCD = "CBOR",
    PARAM = "Best Confirmed Overall Response by Investigator",
    PARCAT1 = "Tumor Response",
    PARCAT2 = "Investigator",
    PARCAT3 = "RECIST 1.1",
    AVAL = aval_resp(AVALC),
    ANL01FL = "Y"
  )
)

Hi @MChiabudini , thanks for raising this issue.
We have discussed this case when we implemented derive_param_confirmed_bor() and decided that we consider it as a data issue. Therefore a warning is issued if this scenario occurs:
Warning message:
Dataset contains CR records followed by PR.
Run `get_crpr_dataset()` to access the CR records records followed by PR

Ideally the SDTM data should be corrected either by changing the PR to PD or the CR to PR. If this is not possible, I would fix the issue in the source records (overall response records in ADRS). Then the derived parameters are consistent. Otherwise, subject 2 would have PD for the CBOR parameter but no PD for the progressive disease parameter.
If you do not want to modify the source records, you could use admiral::derive_extreme_event() to handle the CR->PR case in the CBOR derivation. See Derive Response Parameters requiring Confirmation for a starting point.

Hi @bundfussr!
Thanks for the quick reply and the thorough explanation. I agree that the CR -> PR case generally should not occur and usually will be a data issue and thus needs to be fixed in the raw or SDTM data.
I will have a look at your suggestion to use admiral::derive_extreme_event().

How about CR -> SD cases? According to RECIST they should be assigned CBOR = "PD" if the initial CR does not meet the criteria for minimum duration of SD (compare Table 3 from the RECIST guidelines above).
With admiralonco::derive_param_confirmed_bor() the returned CBOR is always SD though, even if the CR does not fulfill the minimum duration for SD (as defined in ref_start_window).
I understand the argument that assigning PD for such cases would lead to inconsistencies for the 'progressive disease parameter' as mentioned. But shouldn't CR -> SD cases then be treated similarly to CR -> PR cases as data issues, and a similar warning (like for the CR -> PR cases) should be issued by admiralonco::derive_param_confirmed_bor() to flag such cases?
Currently, no such warning is issued by admiralonco::derive_param_confirmed_bor().
Reprex:
adsl <- tibble::tribble(
  ~USUBJID, ~TRTSDTC,
  "1",      "2023-01-01",
  "2",      "2023-01-01"
) %>%
  mutate(
    TRTSDT = lubridate::ymd(TRTSDTC),
    STUDYID = "REPREX"
  )

adrs <- tibble::tribble(
  ~USUBJID, ~ADTC,        ~AVALC,
  "1",      "2023-02-26", "CR",
  "1",      "2023-04-23", "SD",
  "2",      "2023-01-29", "CR",
  "2",      "2023-03-16", "SD"
) %>%
  mutate(PARAMCD = "OVR") %>%
  mutate(
    ADT = lubridate::ymd(ADTC),
    STUDYID = "REPREX"
  ) %>%
  derive_vars_merged(
    dataset_add = adsl,
    by_vars = exprs(STUDYID, USUBJID),
    new_vars = exprs(TRTSDT)
  )

pd_date <- admiral::date_source(
  dataset_name = "adrs",
  date = ADT,
  filter = PARAMCD == "PD"
)

cbor <- adrs %>%
  derive_param_confirmed_bor(
    dataset_adsl = adsl,
    filter_source = PARAMCD == "OVR",
    source_pd = pd_date,
    source_datasets = list(adrs = adrs),
    reference_date = TRTSDT,
    ref_start_window = 42,
    ref_confirm = 28,
    set_values_to = exprs(
      PARAMCD = "CBOR",
      PARAM = "Best Confirmed Overall Response by Investigator",
      PARCAT1 = "Tumor Response",
      PARCAT2 = "Investigator",
      PARCAT3 = "RECIST 1.1",
      AVAL = aval_resp(AVALC),
      ANL01FL = "Y"
    )
  )

We discussed the issue in yesterday's admiralonco developer meeting. We agree that CR->SD is a data issue like CR->PR.
Unfortunately, our assumptions (as mentioned above) are not stated in the documentation. Therefore we will add them in the next release (https://github.com/pharmaverse/admiralonco/issues/276).
We decided not to implement more checks like signal_crpr() in admiralonco for the following reasons:

If the checks are performed within the derivation, they are performed several times and and the same issue is raised several times. Furthermore, the issue is detected too late. We think it is better to perform such checks when the SDTM data is created and before the ADaMs are derived.
The existing check is too specific. It checks one particular issue (CR->PR) for one particular response criterion (RECIST 1.1). Continuing with this approach would result in a lot of functions (signal_crsd(), signal_icripr(), signal_icrisd(), ...).

Therefore we consider such checks as out of scope for admiralonco. Maybe such checks could be added to the sdtmchecks package.

Closing this issue now as the action will be done as part of #276


MudToggleGroup: Throw exception if bound value doesn't match selection mode

Description
Depending on the selection mode you need to bind either Value or SelectedValues. This tripped me up myself so I thought it good to check thie selection mode on component initialization and throw an exception if the wrong parameter is bound. Also added an info box relating this information to the docs for clarity.
How Has This Been Tested?
unit
Types of changes

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

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[x] I've added relevant tests.

@Mr-Technician another thing I noticed was that I tried to bind the non-existent parameter Values instead of SelectedValues for MultiSelection. For SingleSelection you need to bind Value. Do you think Values would be a better name than SelectedValues ?
There is no question that Value is a better name than SelectedValue because this component is also a form component which are all expected to have the Value parameter.

If they change dynamically (which is probably a 0.01% use case) they can just dynamically change the bound value as well. I thought the percentage of people who accidentally bind the wrong parameter might be much higher. But yeah, if you guys think we shouldn't throw then I can only merge the docs update.
The question about renaming SelectedValues still stands though.

@mckaragoz actually you got it wrong. the exception was only thrown if the wrong param was bound, not if both are bound or none are bound. Alternatively we can also just log which I committed now. I can revert the change to logging if there is an argument that the exception is better.

@henon understand the logic. If it is a compiler warning i will be ok. But for runtime exception i'm not sure. Maybe someone create a builder application or may try some experimental things.

Maybe someone create a builder application or may try some experimental things.

Yeah, I can't argue against that ;)

I agree about values offer. Simple is better. The most used parameter should has simple name. If we also need a parameter about all values we can use ValueCollection etc.

I think Values is better for consistency.


Disable windows CI tests for kogito-serverless-operator

It must be disabled because right now it leads to:
packages/kogito-serverless-operator build:dev: ./hack/goimports.sh
packages/kogito-serverless-operator build:dev: Windows Subsystem for Linux has no installed distributions.
packages/kogito-serverless-operator build:dev: Distributions can be installed by visiting the Microsoft Store:
packages/kogito-serverless-operator build:dev: https://aka.ms/wslstore

https://github.com/apache/incubator-kie-tools/pull/2293


Fix child count & Click Behavior

Hi again! 😄
So after the fix, I found an error that was occurring due to the slide count.
The recent change filtered nullish children.
To better reflect this change, we need to change componentDidUpdate to have a matching "count":
const previousCount = React.Children.toArray(prevProps.children).length;
const slideCount = React.Children.toArray(this.props.children).length;

if (previousCount !== slideCount) {
    this.setState({ slideCount });
}

I also had a problem with the "click" behavior.
Until now, I think there was never a case for a slide to be a link or to do something on click.
Lets use this amazing website as an example 😁:

Imagine that every slide/photo was a link to a page. What would happen if you clicked one of the slides that is not fully visible?
Right now, the Carousel starts animating to fully display the item and, at the same time, a click event will occur and the browser will forward to the url of that item.
This behavior seems strange because the user didn't see the item yet but is already being redirected to the correspondent page.
My suggestion would be to prevent the click event if an animation to fully reveal the item is happening/will happen.
One way to achieve this:
{ React.Children.toArray(children).map((child, i) => (
    React.cloneElement(child, {
        ...child.props,
        key: i,
        className: classnames('rc-slide', {
            '-current': current === i,
            [modifierCurrentClassName]: current === i,
        }, child.props.className),
        onClick: (ev) => this.handleSlideClick(ev, i, child),         // => Add an onClick handler to each child.
        onMouseUp: (ev) => this.handleSlideMouseUp(ev, i),
        onDragStart: (ev) => ev.preventDefault(),
        onDrag: (ev) => ev.preventDefault(),
    })
)) }

handleSlideClick = (ev, slideIndex, slide) => {
    if (this.animating) {
        ev.preventDefault();

        return;
    }

    if (slide.props.onClick) {
        slide.props.onClick(ev, slideIndex);
    }
};

What do you think?
@jgradim @satazor

PS: I think I deserve a contributor prize to let me help you and be able to commit to a branch 👀😂

@paulobmarcos both sounds reasonable to me. I've added you as a contributor to this repository, so it's a bit easier for you to help maintaining this library.


Fix IPv6 migration

IPv6 address needs to be formatted as [ip]:port.
Make createTcpListener support IPv6 local address.
Signed-off-by: Or Shoval<EMAIL_ADDRESS>None

Imo this is the only thing that needs to be fixed for migration
The other issue of making the migration robust to cases of bindv6only,
by using ::1 and :: unless ipv6 is disabled (and then use ipv4 <IP_ADDRESS> and <IP_ADDRESS>)
should be handled in a separated PR which i work on right now
this links explains why ipv4 address work also for ipv6
https://stackoverflow.com/questions/6343747/ipv6-socket-creation
since ipv4 is a subset of ipv6
in any case i work on the other PR, at this very moment and this one is a cherry-pick of the base commit of that one, and which of the PR that will be chosen is the Team decision
Thanks

It seems that this PR changes the proxy listener but it does not talk about the client side or the target VM.
I am not familiar how this proxy works, but you need to explain and convince us why this makes sense to just listen to whatever was asked (I guess it is the IPv6 address).
I expect all this to be explained in the commit message so as a reviewer I'll understand why this is enough.
In addition, I see no unit tests here. Have there been unit tests covering this part? If so, an IPv6 flow is in order.

@EdDev
It is another notation of the loopback,
just loopback are accepted without TLS
see please
https://github.com/kubevirt/kubevirt/pull/3392/files#diff-e88e0fbecb2c3ab1c8c08d12a1c8b4f6L328
about
https://github.com/kubevirt/kubevirt/pull/3392#discussion_r422619425
I tested what Alona said, and indeed it isnt mandatory, it is needed when ::1 is used
(and i will double check again in that scope)
The reason was notation
All of the comments here of Alona / Edy / Or Mergi are about that function
so please decide if i should remove this function and address all of those comments in the PR that will relate to it ?

It seems that this PR changes the proxy listener but it does not talk about the client side or the target VM.
I am not familiar how this proxy works, but you need to explain and convince us why this makes sense to just listen to whatever was asked (I guess it is the IPv6 address).
I expect all this to be explained in the commit message so as a reviewer I'll understand why this is enough.
In addition, I see no unit tests here. Have there been unit tests covering this part? If so, an IPv6 flow is in order.

@EdDev
It is another notation of the loopback,
just loopback are accepted without TLS
see please
https://github.com/kubevirt/kubevirt/pull/3392/files#diff-e88e0fbecb2c3ab1c8c08d12a1c8b4f6L328

I do not understand to which of the points you answered here.

about
#3392 (comment)
I tested what Alona said, and indeed it isnt mandatory, it is needed when ::1 is used
(and i will double check again in that scope)
The reason was notation
All of the comments here of Alona / Edy / Or Mergi are about that function
so please decide if i should remove this function and address all of those comments in the PR that will relate to it ?

As we do not understand "why" this whole thing works, we cannot recommend anything.
If you just fix the [] addition, you will still need to explain why that is the only thing needed. Why the loopback part does not need changing and why the other places where <IP_ADDRESS> is mentioned is not requiring changes as well.

It seems that this PR changes the proxy listener but it does not talk about the client side or the target VM.
I am not familiar how this proxy works, but you need to explain and convince us why this makes sense to just listen to whatever was asked (I guess it is the IPv6 address).
I expect all this to be explained in the commit message so as a reviewer I'll understand why this is enough.
In addition, I see no unit tests here. Have there been unit tests covering this part? If so, an IPv6 flow is in order.

@EdDev
It is another notation of the loopback,
just loopback are accepted without TLS
see please
https://github.com/kubevirt/kubevirt/pull/3392/files#diff-e88e0fbecb2c3ab1c8c08d12a1c8b4f6L328

I do not understand to which of the points you answered here.

It answers about
" I am not familiar how this proxy works, but you need to explain and convince us why this makes sense to just listen to whatever was asked (I guess it is the IPv6 address)."
only loobpack is the one that is acceptable without TLS,
and the link show the if conditions and the error in case its not TLS
and not loopback.

about
#3392 (comment)
I tested what Alona said, and indeed it isnt mandatory, it is needed when ::1 is used
(and i will double check again in that scope)
The reason was notation
All of the comments here of Alona / Edy / Or Mergi are about that function
so please decide if i should remove this function and address all of those comments in the PR that will relate to it ?

As we do not understand "why" this whole thing works, we cannot recommend anything.
If you just fix the [] addition, you will still need to explain why that is the only thing needed. Why the loopback part does not need changing and why the other places where <IP_ADDRESS> is mentioned is not requiring changes as well.

for this see please for that
https://github.com/kubevirt/kubevirt/pull/3392#discussion_r422623830

@oshoval I'm very confused. But if I understand you correctly, you want this PR to deal only with the missing []. If so, please update the PR message and the code accordingly.
As the whole discussion regarding <IP_ADDRESS> and <IP_ADDRESS> addresses the migration proxy is listening to is in this PR and we don't fully understand how ipv6 migration works with keeping those addresses in ipv4 format (especially I don't understand how the proxy that is listening to <IP_ADDRESS> catches ipv6 requests) I think it is a shame to move it to a different PR. But if you still decide to do it please update the PR code, message and title accordantly.

@oshoval I'm very confused. But if I understand you correctly, you want this PR to deal only with the missing []. If so, please update the PR message and the code accordingly.
As the whole discussion regarding <IP_ADDRESS> and <IP_ADDRESS> addresses the migration proxy is listening to is in this PR and we don't fully understand how ipv6 migration works with keeping those addresses in ipv4 format (especially I don't understand how the proxy that is listening to <IP_ADDRESS> catches ipv6 requests) I think it is a shame to move it to a different PR. But if you still decide to do it please update the PR code, message and title accordantly.

I dont want to move it, in a "shame" mode, i truly believe its 2 different discussions,
thats all, i will shortly write more info, and according your decision will do what needed.

@oshoval I'm very confused. But if I understand you correctly, you want this PR to deal only with the missing []. If so, please update the PR message and the code accordingly.
As the whole discussion regarding <IP_ADDRESS> and <IP_ADDRESS> addresses the migration proxy is listening to is in this PR and we don't fully understand how ipv6 migration works with keeping those addresses in ipv4 format (especially I don't understand how the proxy that is listening to <IP_ADDRESS> catches ipv6 requests) I think it is a shame to move it to a different PR. But if you still decide to do it please update the PR code, message and title accordantly.

I don't want to move it, in a "shame" mode, i truly believe and know its 2 different independent discussions,
thats all, i will shortly write more info, and according your decision will do what needed.
I even divided it in order to reduce noise and that the parts would be as clear as possible,
else some questions might wont be raised.

This is what i know so far on why we / i might need to rethink about the changes
in the following PRs, hope it sheds some light.
There are multiple communication channels in the migration process.
Some are unix socket, which arent affect in case the pods are IPv4 or IPv6
there are used for internally communicate in the node, and to connect to the libvirtd,
which actually perform the migration once all the data is set.
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-handler/migration-proxy/migration-proxy.go#L133
This is the function that use <IP_ADDRESS>, and this is its comment.
// Target proxy listens on a tcp socket and pipes to a libvirtd unix socket
See please the next section about manager.go for more info.
This is about the <IP_ADDRESS>
It isnt affected by the pod IP from what i understood.
Lets leave a moment isLoopbackAddress
https://github.com/kubevirt/kubevirt/pull/3392/files#diff-e88e0fbecb2c3ab1c8c08d12a1c8b4f6R326
Assuming its needed only for the robustness feature, which i am trying to say is not part of this PR,
just because its a new feature and not a fix of this PR scope.
The occurences at
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-launcher/virtwrap/manager.go#L400
are for overcoming issue of libvirt and unix sockets, but still they are for local communication,
Not virt-handler to virt-handler communication which is the one that is sensitive to the IPv6 or IPv4 of the pods.
// Start local migration proxy.

// This also creates a tcp server for each additional direct migration connections
// that will be proxied to the destination pod
The 4 places in this function is for serving the above comment, and for connecting to the hypervisor,
which is again not connected to the virt-handler IP family.
Two more places which do need invetigation but not as part of this PR imo,
are
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-launcher/virtwrap/manager.go#L749
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-launcher/virtwrap/manager.go#L857
it updates the /etc/hosts file, which i saw that have the IPv4 / IPv6 localhost address already, need to understand how,
and if there are cases when they will both be needed, from what i started to read, they both needed,
so the change there need to be researched. However again its for hostname resolving of localhost, not for the
virt-handler that are the IP sensitive.
The last place of <IP_ADDRESS> is again not connected to virt-handlers communication (the IP sensitive one),
but to local libvirt communication via the proxy
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-launcher/virtwrap/manager.go#L866

@oshoval I'm very confused. But if I understand you correctly, you want this PR to deal only with the missing []. If so, please update the PR message and the code accordingly.
As the whole discussion regarding <IP_ADDRESS> and <IP_ADDRESS> addresses the migration proxy is listening to is in this PR and we don't fully understand how ipv6 migration works with keeping those addresses in ipv4 format (especially I don't understand how the proxy that is listening to <IP_ADDRESS> catches ipv6 requests) I think it is a shame to move it to a different PR. But if you still decide to do it please update the PR code, message and title accordantly.

I don't want to move it, in a "shame" mode, i truly believe and know its 2 different independent discussions,
thats all, i will shortly write more info, and according your decision will do what needed.
I even divided it in order to reduce noise and that the parts would be as clear as possible,
else some questions might wont be raised.

This is what i know so far on why we / i might need to rethink about the changes
in the following PRs, hope it sheds some light.
There are multiple communication channels in the migration process.
Some are unix socket, which aren't affected in case the pods are IPv4 or IPv6.
They are used for internally communicate in the node, and to connect to the libvirtd,
which actually perform the migration once all the data is set.
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-handler/migration-proxy/migration-proxy.go#L133
This is the function that use <IP_ADDRESS>, and this is its comment.
// Target proxy listens on a tcp socket and pipes to a libvirtd unix socket
See please the next section about manager.go for more info.
This is about the <IP_ADDRESS>
It isnt affected by the pod IP from what i understood.
Lets leave a moment isLoopbackAddress
https://github.com/kubevirt/kubevirt/pull/3392/files#diff-e88e0fbecb2c3ab1c8c08d12a1c8b4f6R326
Assuming its needed only for the robustness feature, which i am trying to say is not part of this PR,
just because its a new feature and not a fix of this PR scope.
The occurrences at
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-launcher/virtwrap/manager.go#L400
are for overcoming issue of libvirt and unix sockets, but still they are for local communication,
Not virt-handler to virt-handler communication which is the one that is sensitive to the IPv6 or IPv4 of the pods.
// Start local migration proxy.

// This also creates a tcp server for each additional direct migration connections
// that will be proxied to the destination pod
The 4 places in this function is for serving the above comment, and for connecting to the hypervisor,
which is again not connected to the virt-handler IP family.
Two more places which do need invetigation but not as part of this PR imo,
are
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-launcher/virtwrap/manager.go#L749
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-launcher/virtwrap/manager.go#L857
it updates the /etc/hosts file, which i saw that have the IPv4 / IPv6 localhost address already, need to understand how,
and if there are cases when they will both be needed, from what i started to read, they both needed,
so the change there need to be researched. However again its for hostname resolving of localhost, not for the
virt-handler that are the IP sensitive.
The last place of <IP_ADDRESS> is again not connected to virt-handlers communication (the IP sensitive one),
but to local libvirt communication via the proxy
https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-launcher/virtwrap/manager.go#L866

https://github.com/kubevirt/kubevirt/blob/b488ebd49594a8c30f7bf7755f10255d7ab2425c/pkg/virt-handler/migration-proxy/migration-proxy.go#L310
See please that those that use this function are unix socket so IP doesn't matter at all here, does it ?

Thanks for the long explanation. But I still don't understand how it works. Afaik, please correct me if I'm wrong, if a server is listening on ipv4 address, you cannot connect to it using ipv6 address.
So to make sure keeping the ipv4 addresses is fine I need to see both of the sides. The client and the server.
I'm not fully familiar with the migration flow and why we are using a proxy. But the thing that bothers me the most is the proxy that is listening on <IP_ADDRESS>. I would love to see the code of the client connection to this proxy to be sure it is always using ipv4 address as well, although we are in ipv6 cluster.

Thanks for the long explanation. But I still don't understand how it works. Afaik, please correct me if I'm wrong, if a server is listening on ipv4 address, you cannot connect to it using ipv6 address.
So to make sure keeping the ipv4 addresses is fine I need to see both of the sides. The client and the server.
I'm not fully familiar with the migration flow and why we are using a proxy. But the thing that bothers me the most is the proxy that is listening on <IP_ADDRESS>. I would love to see the code of the client connection to this proxy to be sure it is always using ipv4 address as well, although we are in ipv6 cluster.

Thanks for reading,
please see this
https://unix.stackexchange.com/questions/419880/connecting-to-ip-0-0-0-0-succeeds-how-why
i think the IP here isnt an issue due to this
Also lets assume a moment it was, since its on the same host (do we agree?)
and as long as IPv4-mapped address feature isn't disabled it would work
see please last paragram
https://access.redhat.com/solutions/4291941

Thanks for the long explanation. But I still don't understand how it works. Afaik, please correct me if I'm wrong, if a server is listening on ipv4 address, you cannot connect to it using ipv6 address.
So to make sure keeping the ipv4 addresses is fine I need to see both of the sides. The client and the server.
I'm not fully familiar with the migration flow and why we are using a proxy. But the thing that bothers me the most is the proxy that is listening on <IP_ADDRESS>. I would love to see the code of the client connection to this proxy to be sure it is always using ipv4 address as well, although we are in ipv6 cluster.

Thanks for reading,
please see this
https://unix.stackexchange.com/questions/419880/connecting-to-ip-0-0-0-0-succeeds-how-why
i think the IP here isnt an issue due to this

Please explain why the ip is not an issue due to this and what are you talking about when you say this. Iiuc, we are listening on <IP_ADDRESS>. Which means (according to the link you provided) any ipv4 address will be accepted. And that's exactly what I'm worried about, do we connect to this proxy server using only ipv4 addresses? I couldn't find any reference in the link regarding connecting to <IP_ADDRESS> with ipv6 so I cannot understand what answer should I get in this link.

Also lets assume a moment it was, since its on the same host (do we agree?)
and as long as IPv4-mapped address feature isn't disabled it would work
see please last paragraph
https://access.redhat.com/solutions/4291941
This link is saying that listening over ipv6 localhost (::1) or any host (::) will except ipv4 connections as well. Well, that's exactly the code you removed from the pr (using ::1 and :: for both ipv6 and ipv4). Currently the pr contains listening only on the ipv4 addresses. Does listening on <IP_ADDRESS> will receive connection to ::1? The link doesn't answer this question so I don't understand how it helps to our discussion.

Regarding the fact that it is on the same host, again I don't understand why it is relevant. If you have a process that is listening on <IP_ADDRESS>:2222 and another process that is connecting to [::]:2222. Would it work?

Not quoting because it adds noise, referring to last topic, trying to wrap the answers,
please say what do you think, thanks
Communication channels in migration:
SRC POD ENV (migration unix socket) <-> HOST ENV (tcp client) <--*--> (tcp server) HOST ENV <-> TARGET POD ENV (libvirtd unix socket)
The reason <IP_ADDRESS> / <IP_ADDRESS> (handler to handler, marked with *) works is that golang net library,
when listening to "tcp" [4] which is our case, and ipv4 mapping enabled,
it creates IPv6 socket [1], and the address therefore act as INADDR6_ANY and so on.
Call stack if desired:
[2] https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-handler/migration-proxy/migration-proxy.go#L135
[3] https://github.com/kubevirt/kubevirt/blob/b488ebd49594a8c30f7bf7755f10255d7ab2425c/pkg/virt-handler/migration-proxy/migration-proxy.go#L426
[4] https://github.com/kubevirt/kubevirt/blob/b488ebd49594a8c30f7bf7755f10255d7ab2425c/pkg/virt-handler/migration-proxy/migration-proxy.go#L326
[5] https://golang.org/src/net/dial.go?s=9855:9903#L308
[1] https://github.com/golang/go/blob/440f7d64048cd94cba669e16fe92137ce6b84073/src/net/ipsock_posix.go#L121
Taking this under consideration, this PR can be standalone
As Edy suggested, even that golang act like this,
A seperate PR will deal with using IPv6 address (unless ipv6_disable=1) explicity in order to:

Make it explicit to use IPv6 addresses and not relay on internal go implementation.
Be robust to case of bindv6only, where the mapping is disabled, and therefore it might fail.

I will remove from this PR the part about isLoopbackAddress, because its not an intergral part.

Not quoting because it adds noise, referring to last topic, trying to wrap the answers,
please say what do you think, thanks
Communication channels in migration:
SRC POD ENV (migration unix socket) <-> HOST ENV (tcp client) <--*--> (tcp server) HOST ENV <-> TARGET POD ENV (libvirtd unix socket)
The reason <IP_ADDRESS> / <IP_ADDRESS> (handler to handler, marked with *) works is that golang net library,
when listening to "tcp" [4] which is our case, and ipv4 mapping enabled,
it creates IPv6 socket [1], and the address therefore act as INADDR6_ANY and so on.
Call stack if desired:
[2] https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-handler/migration-proxy/migration-proxy.go#L135
[3]
https://github.com/kubevirt/kubevirt/blob/b488ebd49594a8c30f7bf7755f10255d7ab2425c/pkg/virt-handler/migration-proxy/migration-proxy.go#L426
[4]
https://github.com/kubevirt/kubevirt/blob/b488ebd49594a8c30f7bf7755f10255d7ab2425c/pkg/virt-handler/migration-proxy/migration-proxy.go#L326
[5] https://golang.org/src/net/dial.go?s=9855:9903#L308
[1] https://github.com/golang/go/blob/440f7d64048cd94cba669e16fe92137ce6b84073/src/net/ipsock_posix.go#L121
Taking this under consideration, this PR can be standalone
As Edy suggested, even that golang act like this,
A seperate PR will deal with using IPv6 address (unless ipv6_disable=1) explicity in order to:
1. Make it explicit to use IPv6 addresses and not relay on internal go implementation.

2. Be robust to case of bindv6only, where the mapping is disabled, and therefore it might fail.

I will remove from this PR the part about isLoopbackAddress, because its not an intergral part.

@oshoval thanks for the detailed response. Now it makes sense and I understand how come it works with the ipv4 addresses.
Your plan sounds reasonable to me.

Thanks Alona, just see please i edited and added my view,
i will ask a maintainer for his opinion just to see the direction you prefer is fine please

Not quoting because it adds noise, referring to last topic, trying to wrap the answers,
please say what do you think, thanks
Communication channels in migration:
SRC POD ENV (migration unix socket) <-> HOST ENV (tcp client) <--*--> (tcp server) HOST ENV <-> TARGET POD ENV (libvirtd unix socket)
The reason <IP_ADDRESS> / <IP_ADDRESS> (handler to handler, marked with *) works is that golang net library,
when listening to "tcp" [4] which is our case, and ipv4 mapping enabled,
it creates IPv6 socket [1], and the address therefore act as INADDR6_ANY and so on.
Call stack if desired:
[2] https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-handler/migration-proxy/migration-proxy.go#L135
[3]
https://github.com/kubevirt/kubevirt/blob/b488ebd49594a8c30f7bf7755f10255d7ab2425c/pkg/virt-handler/migration-proxy/migration-proxy.go#L426
[4]
https://github.com/kubevirt/kubevirt/blob/b488ebd49594a8c30f7bf7755f10255d7ab2425c/pkg/virt-handler/migration-proxy/migration-proxy.go#L326
[5] https://golang.org/src/net/dial.go?s=9855:9903#L308
[1] https://github.com/golang/go/blob/440f7d64048cd94cba669e16fe92137ce6b84073/src/net/ipsock_posix.go#L121
Taking this under consideration, this PR can be standalone
As Edy suggested, even that golang act like this,
A seperate PR will deal with using IPv6 address (unless ipv6_disable=1) explicity in order to:
1. Make it explicit to use IPv6 addresses and not relay on internal go implementation.

Why not just listen (only) to ::0 instead ? (not sure this what you mean here; if so, sorry to point the obvious).

Be robust to case of bindv6only, where the mapping is disabled, and therefore it might fail.

I will remove from this PR the part about isLoopbackAddress, because its not an intergral part.

@oshoval thanks for the detailed response. Now it makes sense and I understand how come it works with the ipv4 addresses.
Your plan sounds reasonable to me.

Does sound reasonable. I'd just change from <IP_ADDRESS> to ::0, making explicit that the proxy is binding to v4 / v6 addresses.

Interesting link @SchSeba sent me https://docs.google.com/document/d/1zznvkK87y7UvOJZqs2DM4oWzx94P8Lg6YUb43whil3g/edit#heading=h.23ehcjjvl9pd (Section - Some IPv6 Porting Best Practices).

@maiqueb

Why not just listen (only) to ::0 instead ? (not sure this what you mean here; if so, sorry to point the obvious).
Its interesting, syntactic it will achieve the desired readability.
But if ipv6 will be disabled (which i dont know if there will be a feature like that, we can ask if desired),
it would either not work, or do implicit magics, Edy voted down for it.
This also address your 2nd comment.

Thanks Alona, just see please i edited and added my view,
i will ask a maintainer for his opinion just to see the direction you prefer is fine please

@oshoval I liked your response before you edited it:). I prefer you to introduce the second PR that will substitute <IP_ADDRESS> with ::1 and <IP_ADDRESS> with :: (in case ip6 is not disabled in the kernel).
Although it works with the ipv4 addresses (and now I even understand why) I think it will make things more clear if the ipv6 addresses will be used.
But we can consult with the kubevirt community about it.

Thanks Alona, just see please i edited and added my view,
i will ask a maintainer for his opinion just to see the direction you prefer is fine please

@oshoval I liked your response before you edited it:). I prefer you to introduce the second PR that will substitute <IP_ADDRESS> with ::1 and <IP_ADDRESS> with :: (in case ip6 is not disabled in the kernel).
Although it works with the ipv4 addresses (and now I even understand why) I think it will make things more clear if the ipv6 addresses will be used.
But we can consult with the kubevirt community about it.

+1 on being explicit. Relying on the implementation of a private method is worrying.

Thanks Alona, just see please i edited and added my view,
i will ask a maintainer for his opinion just to see the direction you prefer is fine please

@oshoval I liked your response before you edited it:). I prefer you to introduce the second PR that will substitute <IP_ADDRESS> with ::1 and <IP_ADDRESS> with :: (in case ip6 is not disabled in the kernel).
Although it works with the ipv4 addresses (and now I even understand why) I think it will make things more clear if the ipv6 addresses will be used.
But we can consult with the kubevirt community about it.

didn't meant otherwise, as i wrote.
one nit, the <IP_ADDRESS> i need to see if indeed we need it, because there are internal sockets which arent tcp even, i will first understand what i am doing.
and about the /etc/hosts that is updated by <IP_ADDRESS>
its a WA for libvirt that doesnt allow migration to the same host, a feature Vladik wrote.
so each part need to be understanded before doing please.

When dealing with IPv6 addresses, the standard net package is expecting an IPv6 address format that includes square brackets (e.g [::1]).
By normalizing the IPv6 address, the whole migration flow succeeds and the currently skipped functional tests are therefore ran normally.

Uncle bob said 72 chars xD

/test pull-kubevirt-e2e-kind-k8s-1.17.0-ipv6

/hold
adding a revert to check that the ipv6 lane pass without it,
so putting this hold guard

the summary of this PR with the revert of fc32, there are 4 failing tests, trying to understand if they are flaky
https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/3392/pull-kubevirt-e2e-kind-k8s-1.17.0-ipv6/1260907237409296384

/hold cancel

Can the functional tests that have been un-skipped passing now on CI? Is the current failing IPv6 lane affecting these tests?

/assign @vladikr
Hi Vladik, can you review this one please?
This one fixes the migration, by normalization the IPv6 address.
A following PR will make the code more explicit about using IPv4 or IPv6 bind address,
without letting the Golang lib to implicity choose the socket family.
Thanks

Are the functional tests that have been un-skipped passing now on CI? Is the current failing IPv6 lane affecting these tests?

The functional ones that were caused by this bug, are unskipped and passing,
All the non passing are connected to Agent problems,
https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/3392/pull-kubevirt-e2e-kind-k8s-1.17.0-ipv6/1261737473550061569

/lgtm

/lgtm

/retest

This PR needs #3429 Fix, so some of the tests will fail over and over,
this is why the bot is busy retesting

This PR needs #3429 Fix, so some of the tests will fail over and over,
this is why the bot is busy retesting

It was finally merged. You will need now to rebase.

Holding until a rebase.
/hold

@EdDev
Rebased, removing hold, thanks
/hold cancel

/retest

Thanks Edy
@vladikr
can you please re-approve ? a rebase was needed
thanks

/override pull-kubevirt-e2e-kind-k8s-1.17.0-ipv6
checking if the bot allow me

/retest


Handling fonts with the CLI

Hi,
I'm using the CLI and all the installation instructions work perfectly now (thanks). The one issue I'm running into is the roboto fonts not loading:
GET http://localhost:9000/materialize-css/fonts/roboto/Roboto-Regular.woff2
:9000/materialize-css/fonts/roboto/Roboto-Regular.woff:1
GET http://localhost:9000/materialize-css/fonts/roboto/Roboto-Regular.woff
:9000/materialize-css/fonts/roboto/Roboto-Regular.ttf:1
GET http://localhost:9000/materialize-css/fonts/roboto/Roboto-Regular.ttf

Any recommended approaches for handling this?
Thanks,
Jason

Hi @jasonhjohnson,
that's definitely a good question. Last time I checked (several au versions ago) you couldn't load fonts easily with Aurelia CLI. This may have changed and I need to check again. They couldn't be bundled and I think that's what causing this issue.
The workaround is to copy these fonts (via a buld task) into the directory where they are expected.
https://github.com/aurelia/cli/issues/248
When I take a look at the file system, the referenced path seems to be the correct one. So I guess this unresolved Aurelia CLI issue is related.

Checked again. As of now, there doesn't seem to be a "real" solution to this.
 If you do that now, au throws errors because it wants to bundle Roboto-Regular.js..

Yeah. Would there be away to bypass these errors?

Well, I can't think of any "pretty" solution.. Remove all @font-face from materialize.css (build step with regular expressions?) or create a directory materialize-css/fonts/roboto/ where a build task copies the Materialize fonts so the network requests from materialize.css succeed.

I resolved it for font awesome using custom build task, as described here. I think same fix can be done for Roboto fonts.

I tried adding the following custom build tasks:
import * as gulp from 'gulp';
import merge from 'merge-stream';
import changedInPlace from 'gulp-changed-in-place';
import project from '../aurelia.json';

export default function prepareFontAwesome() {

  let source = 'node_modules\\font-awesome';

  let taskCss = gulp.src(`${source}\\css\\font-awesome.min.css`)
    .pipe(changedInPlace({firstPass:true}))
    .pipe(gulp.dest(`${project.platform.output}\\css`));

  let taskFonts = gulp.src(`${source}\\fonts\\*`)
    .pipe(changedInPlace({firstPass:true}))
    .pipe(gulp.dest(`${project.platform.output}\\fonts`));

  return merge(taskCss, taskFonts);
}

and
import * as gulp from 'gulp';
import merge from 'merge-stream';
import changedInPlace from 'gulp-changed-in-place';
import project from '../aurelia.json';

export default function prepareMaterialize() {

  let source = 'node_modules\\materialize-css';

  let taskCss = gulp.src(`${source}\\dist\\css\\materialize.min.css`)
    .pipe(changedInPlace({firstPass:true}))
    .pipe(gulp.dest(`${project.platform.output}\\css`));

  let taskFonts = gulp.src(`${source}\\fonts\\*`)
    .pipe(changedInPlace({firstPass:true}))
    .pipe(gulp.dest(`${project.platform.output}\\fonts`));

  return merge(taskCss, taskFonts);
}

Thanks everybody

Please see this app skeleton

Finally added to the docs.


unable to depart for quests

everything seems to be working fine but whenever i depart for a quest i get these errors

i can tell this is just a me problem i am not tech savvy at all so if theres a way to fix this would you be so kind to let me know in detail please

did you start sky coridor? because sky coridor is not available in ZZ

i have not departed for a quest that had the sky corridor map i seem get these errors whenever i depart for any map like the great forest, volcano, etc

did you start sky coridor? because sky coridor is not available in ZZ

i forgot to like quote your message idk if it counts as replying sorry if im being bothersome

This is intended behavior as defined here:
https://github.com/ZeruLight/Erupe/blob/main/server/channelserver/handlers_quest.go#L56


Team Instructions

Repository Link: Project Link
Number of Partners: 2  @biruk-bereka  @kensteph

Hi ,
Your project is complete!  There is nothing else to say other than... it's time to move on :shipit:
Congratulations! 🎉

Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Add Cache based on config & params

Added ability to cache responses to the API. It caches the response based on the Config and URL Params.
Cache is disabled by default, however can be enabled per-template or in the default ElementApi Config.

You can close this, I see that there is another pull request for caching.


Opacity props ignored on foreignObject children on android.

#Bug
Unexpected behavior
A group <G/> with a opacity of 0 will still display a  <ForeignObject/> children's content when run on android device.
Environment info
System:
    OS: macOS Mojave 10.14.5
    CPU: (4) x64 Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz
    Memory: 174.88 MB / 16.00 GB
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.18.2 - /var/folders/c_/714h7f2x5l76nm3ytcmj8k1w0000gn/T/yarn--1596555629972-0.5353164014936929/node
    Yarn: 1.22.4 - /var/folders/c_/714h7f2x5l76nm3ytcmj8k1w0000gn/T/yarn--1596555629972-0.5353164014936929/yarn
    npm: 6.14.5 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.8.4 - /Users/giregm/.rvm/gems/ruby-2.4.1/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 26, 27, 28, 29, 30
      Build Tools: 27.0.3, 28.0.3, 29.0.2, 30.0.0
      System Images: android-28 | Intel x86 Atom_64, android-30 | Google Play Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 3.5 AI-191.8<IP_ADDRESS>00203
    Xcode: 11.3/11C29 - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_202 - /usr/bin/javac
    Python: 2.7.16 - /usr/local/bin/python
  npmPackages:
  @react-native-community/cli: Not Found
  react: 16.11.0 => 16.11.0
  react-native: 0.62.2 => 0.62.2

Library version: 12.1.0 (react-native-svg)
Short, Self Contained, Correct (Compilable), Example
<G opacity={0}>
   <Circle cx={0} cy={0} r={100} fill="red"></Circle>
   <ForeignObject>
      <View style={{ backgroundColor: 'red', width: 20, height: 20}}/>
    </ForeignObject>
</G>

On ios we see nothing as intended because the opacity is at 0.
On android, we see a red square, the opacity is not applied on ForeignObject.

i have the same issue, trying to fix it...

i have the same issue, trying to fix it...

I found wrapping the inside of a foreignObject inside a 0 opacity view would fix it on android (but break it on iOS)
<G opacity={0}>
   <Circle cx={0} cy={0} r={100} fill="red"></Circle>
   <ForeignObject>
      <View style={{opacity: Platform.OS === 'andoird' ? 0 : 1}}>
        <View style={{ backgroundColor: 'red', width: 20, height: 20}}/>
      </View>
   </ForeignObject>
</G>

Can't reproduce the bug with react-native-svg : 10.1.0

I also face this issue. In my case it goes worse: opacity on a View, that is nested into the ForeignObject, isn't applied at all. Any constant opacity doesn't work at all.
My workaround is to apply opacity on all levels: to parent G, to nested View, to all View children, to all of them 😭


feat: Blink funding source

supersedes https://github.com/lnbits/lnbits/pull/2270 (this PR is just a rebase and squash of that PR)
ready for review
still in draft, because type checks (mypy and pyright) still need to be fixed

@prusnak ok

Maybe our typing guru @dni can help with the typing issues? :)

@openoms i confirmed this branch is working, i used this .env.example, not the one from previous
@prusnak @motorina0 unit test is for graphql not rest api, let me know if you need it to be adjusted to fit the others

Where are we with this current PR? i'm getting a little thin on free time here in the next few..., so would be good to let me know

Where are we with this current PR? i

We still need to figure out the typing issues and fix them (mypy/pyright)

Where are we with this current PR? i'm getting a little thin on free time here in the next few..., so would be good to let me know

I'm reviewing it now.

I've tested a good list of extensions using this branch using Zeus (connecting to LND) and with another Blink connected LNbits wallet mixed:

[x] User Manager
[x] LNURLw
[x] LNURLp
[x] TipJar
[x] TPoS (receive + ATM)
[x] Events
[x] Invoices
[x] SatsPayServer
[x] Paywall
[ ] LNCalendar - Waiting for payment...

only has an issue with the LNcalendar - the incoming payment is not picked up - only getting Waiting for payment... despite successful payment from Zeus and from another lnbits wallet.
The problem with LNcalendar might be not related to the Blink integration at all, but it does work on a CLN backed LNbits v0.12.2.
Apart from the documentation change suggestion above I found this PR to be fully functional and working as expected.

@openoms regarding

the incoming payment is not picked up

This is expected, the websocket connection is not implemented, I will handle that next.

The CI is green now, thanks @motorina0!
Can you please retest @openoms with the changes from Vlad? If you say it still works, we can merge 🎉

@openoms regarding

the incoming payment is not picked up

This is expected, the websocket connection is not implemented, I will handle that next.

Done, payment notifications can be tested now.

CI not failing anymore.
Marked as ready for review (turning off the draft status).

@motorina0 ran a quick test with the updates using the websocket.
the basic wallet functions and Tpos receive and send works.
Found the LNcalendar unreliable especially when paying the invoice with a Blink funded LNbits subaccount or with another Blink wallet.
Either having no receive confirmation on the LNcalendar page or getting this:

@motorina0 ran a quick test with the updates using the websocket. the basic wallet functions and Tpos receive and send works.
Found the LNcalendar unreliable especially when paying the invoice with a Blink funded LNbits subaccount or with another Blink wallet. Either having no receive confirmation on the LNcalendar page or getting this:

This is most likely an issue with the LNCalendar extension and not with the Blink funding source.
You can try with an LNbits funding source (https://demo.lnbits.com), I would expect the same error.
Jut curious, are you using LNCalendar in any particular way, or was it a random choice for testing.

@motorina0 ran a quick test with the updates using the websocket. the basic wallet functions and Tpos receive and send works.
Found the LNcalendar unreliable especially when paying the invoice with a Blink funded LNbits subaccount or with another Blink wallet. Either having no receive confirmation on the LNcalendar page or getting this:

This is most likely an issue with the LNCalendar extension and not with the Blink funding source. You can try with an LNbits funding source (https://demo.lnbits.com), I would expect the same error.
Just curious, are you using LNCalendar in any particular way, or was it a random choice for testing.

I did test LNcalendar with a CLN backed LNbits instance where it had no problems. It is a useful extension I would plan to use myself and testing it particularly beacuse it was the only one not working. Hope to have a solution here: https://github.com/lnbits/lnbits/pull/2477#discussion_r1673683338

I am not able to reproduce the issue. Payment was successful, no errors in the console (LNbits v0.12.8, LNCalendar v0.1.2).
I have the Blink funding source configured.

Is there a special scenario on how I can reproduce this?

I am not able to reproduce the issue. Payment was successful, no errors in the console (LNbits v0.12.8, LNCalendar v0.1.2). I have the Blink funding source configured.
Is there a special scenario on how I can reproduce this?

Yes, the payments in LNcalendar are still not picked up for transactions where the invoice is paid with an LNbits wallet on the same instance (which is connected to Blink). The accounting happen - sats are spebt from the wallet and arrive in the LNcalendar wallet, bu the appoinment booking is not successful.
I had no problems now paying from Zeus (LND) and with a Blink wallet of another user.

Sounds like an issue with lncalendar and self payments, rather than blink

Possible fixed with lnbits/lncalendar#8

@dni @talvasconcelos can you please review so we can finally merge?

Blink missing from the server UI

Blink missing from the server UI

Weird - I see it in both lnbits-funding-sources.js and bundle.min.js 🤷

Blink missing from the server UI

Got it on my instance (updated to latest and restarted):

Weird, i must have some bundle issue. My mistake, will try again 👍

Its outside of the scope of this pr, but the issue was LNBITS_ALLOWED_FUNDING_SOURCES in env needing Blonkwallet, even though LNBITS_ADMIN_UI=true was set.

Thank you all who have worked on improving and reviewing this PR. As you might know there is a  1M sats bounty offered for this feature which is now completed and ready to be paid.
The original initiative and the bulk of the work was taken up by @bitkarrot who would be entitled to receive the bounty, but given the additional work done (especially by @motorina0 and all the reviewers) I’d like to make sure that we offer to share the bounty if wanted.
So please comment if you have an opinion about how it would be best to deal with the payout. Planning to finalize it by the end of the this week.

As far as I'm concerned the bounty belongs entirely to @bitkarrot

As far as I'm concerned the bounty belongs entirely to @bitkarrot

Same 👍


CMake policy CMP0048 warning

Description

Type:  Enhancement
Priority: Minor

Enhancement
Justification - why does the library need this feature?
When building as subproject of project using CMake 3.9.x I get a warning:

CMake Warning (dev) at build/mbedtls-src/CMakeLists.txt:2 (project):
Policy CMP0048 is not set: project() command manages VERSION variables.
Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
command to set the policy and suppress this warning.
The following variable(s) would be set to empty:
PROJECT_VERSION
PROJECT_VERSION_MAJOR
PROJECT_VERSION_MINOR
PROJECT_VERSION_PATCH
This warning is for project developers.  Use -Wno-dev to suppress it.

Suggested enhancement
This project does not seem to use these variables, so explicitly setting policy CMP0048 (before project()) either way would silence this warning:
if (POLICY CMP0048)
  cmake_policy(SET CMP0048 NEW)
endif (POLICY CMP0048)

Hi @yachoor thank you for raising this issue!
We will look into this, and see how we resolve this, keeping backwards compatibility

ARM Internal Ref: IOTSSL-1963


Searching for reliable tool for donations

EXAMPLE 1: Moorfields Eye Charity
added: Mon 26 Aug 21:34:13 2019
website: https://www.moorfieldseyecharity.org.uk/summerappeal2019

donation

Example 2: I CAN BE
added: Tue 17 Sep 21:26:36 BST 2019
website: https://www.icanbe.org.uk/donate

I Can Be brings seven and eight year-old girls into the world of work, broadening horizons and helping them to discover the breadth of opportunity around them.
Run through schools, the programme gives Year Three girls the opportunity to research, visit and interview a wide range of female professionals in their workplaces during their working day.
Targeting inner-city primary schools, I Can Be enables girls to explore jobs they otherwise may never be exposed to, building their curiosity and confidence along the way.
more: https://www.icanbe.org.uk/

Example 3: Arduino
Downloading arduino software is completely free, but user can also donate or pay what they thing is fine for the software. The following images are shown here: https://www.arduino.cc/en/Main/Software

Example 4: Wikipedia
https://donate.wikimedia.org/wiki/Ways_to_Give

Paypal: https://donate.wikimedia.org/wiki/Ways_to_Give#PayPal
Cryptocurrency: https://donate.wikimedia.org/wiki/Ways_to_Give#Cryptocurrency

MX: https://payments.wikimedia.org/index.php?title=Special:AstroPayGateway&appeal=JimmyQuote&ffname=astropay-mx&recurring=false&utm_source=Waystogive.default~default~default~default~control.cash&utm_medium=Waystogive&utm_campaign=C11_Waystogive&utm_key=vw_1433.vh_848.otherAmt_0.validateError_1.time_18&referrer=donate.wikimedia.org%2Fwiki%2FWays_to_Give&language=en&country=MX&payment_method=cash&payment_submethod=&gateway=&variant=&amountGiven=&frequency=onetime&amount=100&currency=MXN

UK: https://donate.wikimedia.org/w/index.php?title=Special:LandingPage&uselang=en&country=GB&utm_medium=Waystogive&utm_source=Waystogive&utm_campaign=C11_Waystogive

Example 5: Save the Children
More ways to help: https://www.savethechildren.org.uk/donate

Example 6
https://creativecommons.org
https://us.netdonor.net/page/6650/donate/1?ea.tracking.id=top-of-page-banner

Example 7

Wiki Education serves as the bridge between academia and Wikipedia. A small 501(c)(3) nonprofit, we run programs that seek to build connections between universities and Wikipedia and other Wikimedia projects in the United States and Canada. https://wikiedu.org

Donation tools is powered by: https://donately.com/?utm_source=formjs

Hello, I have come across this project as a possible donation or funding tool and to have open finances.

https://opencollective.com/

Intro
example

I was also reviewing the github option for donations or sponsors

https://github.com/sponsors

please give a look on both options.

Various types of donations at KISS Institute for Practical Robotics
https://www.kipr.org/donate


Check packchk cov

Codecov Report

Merging #1 (b62f70d) into main (f4092dd) will increase coverage by 24.32%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main       #1       +/-   ##
===========================================
+ Coverage   45.60%   69.92%   +24.32%
===========================================
  Files         116       50       -66
  Lines       20664     9566    -11098
  Branches    11281     5861     -5420
===========================================
- Hits         9423     6689     -2734
+ Misses       9455     1853     -7602
+ Partials     1786     1024      -762

Flag
Coverage Δ

buildmgr-cov
74.95% <ø> (ø)

svdconv-cov
?

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

Impacted Files
Coverage Δ

tools/svdconv/SVDModel/include/SvdCExpression.h

tools/svdconv/SVDGenerator/include/HeaderData.h

tools/svdconv/SVDModel/src/SvdDimension.cpp

tools/svdconv/SVDGenerator/src/FileIo.cpp

tools/svdconv/SVDModel/src/SvdWriteConstraint.cpp

tools/svdconv/SVDModel/include/SvdInterrupt.h

tools/svdconv/SVDModel/src/SvdUtils.cpp

tools/svdconv/SVDGenerator/src/SvdGenerator.cpp

tools/svdconv/SVDGenerator/src/SfdGenerator.cpp

tools/svdconv/SVDGenerator/src/SfdData.cpp

... and 56 more

Codecov Report

Merging #1 (7ed15c2) into main (f4092dd) will increase coverage by 23.70%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main       #1       +/-   ##
===========================================
+ Coverage   45.60%   69.30%   +23.70%
===========================================
  Files         116       50       -66
  Lines       20664     9566    -11098
  Branches    11281     5861     -5420
===========================================
- Hits         9423     6630     -2793
+ Misses       9455     1927     -7528
+ Partials     1786     1009      -777

Flag
Coverage Δ

packgen-cov
81.72% <ø> (ø)

svdconv-cov
?

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

Impacted Files
Coverage Δ

tools/packchk/src/ParseOptions.cpp
0.00% <0.00%> (-57.85%)
:arrow_down:

tools/svdconv/SVDGenerator/src/SvdGenerator.cpp

tools/svdconv/SVDGenerator/src/PartitionData.cpp

tools/svdconv/SVDModel/src/SvdModel.cpp

tools/svdconv/SVDModel/include/SvdEnum.h

tools/svdconv/SVDModel/src/SvdCluster.cpp

tools/svdconv/SVDModel/src/SvdField.cpp

...ools/svdconv/SVDGenerator/include/SfrccInterface.h

tools/svdconv/SVDGenerator/include/HeaderData.h

tools/svdconv/SVDModel/include/SvdAddressBlock.h

... and 57 more

Codecov Report

Merging #1 (7ed15c2) into main (f4092dd) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage   45.60%   45.60%
=======================================
  Files         116      116
  Lines       20664    20664
  Branches    11281    11281
=======================================
  Hits         9423     9423
  Misses       9455     9455
  Partials     1786     1786

Flag
Coverage Δ

packchk-cov
50.52% <ø> (ø)

packgen-cov
81.72% <ø> (ø)

svdconv-cov
24.63% <ø> (ø)

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


Method for adding a section ?

Is there a way to add a section to a configparser ?
I need to add a section with a few Value Key pairs.

When you set a value and the sectionname is not in the config the section will be created with the Values and then you can add more. :)


feat(bpdm-gate): Extend error states

Description

Enhance the error handling mechanism for the orchestrator and gate components by extending the list of available error codes. This will improve the visibility and detail of error information, particularly beneficial for the customer dashboard to understand why a data set could not be processed.
Currently, the orchestrator and gate components have a limited set of error codes. Extending these error codes will provide more granular information on processing failures, aiding in quicker diagnosis and resolution. This feature will update both the orchestrator and gate components to support a more comprehensive list of error codes.
The new enums add to the BusinessPartnerSharingError:

NaturalPersonError - The provided record contains natural person information.
BpnErrorNotFound - The provided record can not be matched to a legal entity or an address.
BpnErrorTooManyOptions - The provided record can not link to a clear legal entity.
MandatoryFieldValidationFailed - The provided record does not fulfill mandatory validation rules.
BlacklistCountryPresent - The provided record is part of a country that is not allowed to be processed by the GR process (example: Brazil).
UnknownSpecialCharacters - The provided record contains unalloyed special characters.

https://github.com/eclipse-tractusx/sig-release/issues/727
Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review:

[ ] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
[ ] Copyright and license header are present on all affected files

@kunyao-cofinity-x, It looks like rebase on your current branch didn't performed correctly.

Since the error code needs to be added to the orchestrator table schema(Error Type), that's the reason rebase to the mani, the branch was created before the orchestrator persistent creating

@kunyao-cofinity-x, It looks like rebase on your current branch didn't performed correctly.

Since the error code needs to be added to the orchestrator table schema(Error Type), that's the reason rebase to the main branch, the branch was created before the orchestrator persistent creating. should I recreate a branch based on the updated main?

In order to make sure that the newest state of main is compatible with the changes we typically request the feature branch to be up-to-date with the newest changes on main.
You can see that you get it right, when this pull request has one commit that it wants to apply to the main branch.
In order to achieve this from your state you will need to use rebasing and/or cherry-picking and update your local main to the newest state of this repository's main


Add files section

Coverage remained the same at 100.0% when pulling 8bd39a61c1332a0045120f14d8a639bd9aaa84ba on clean-pkg into 1f389bf939c8f8287a1f683db417b47138898ec9 on master.


Difficulties sharing DataType Archive between multiple programs in a project

We have a project consisting of multiple versions of the same basic program.  These programs share the same DataTypes (in particular, structure definitions), so we have a common DataType archive to pull from.  However, a persistent problem we see is illustrated by this example:
Consider messages passed between tasks within the program.  Different versions of the program may have different definitions of particular message numbers, so the enum that defines the message number is unique for each program within the project.
But, the message header itself is common between all versions, except that they use different enums for the message number.  But, the DataType archive has to contain a single message number enum in the archive.  Furthermore, message queues point to the message header, so they want to be unique based on which enum is in the header, etc.
So, what we want to do is to have a "generic" enum in the DataType archive and the specific values in the enum get used from the program datatype manager.  At the moment, we use ushort in the message header, but this disables the very useful enum expansion that ghidra is capable of.
And sometimes this variation is actually slightly different contents of structures, which is more problematic to work around.
So, the question is, are we overlooking a better way to deal with this problem?

Bump

Bump

You may want to convert this issue to a discussion.  You will probably get more eyeballs there than here.  If github isn't giving you the "Transfer Issue" option, I or another team member could do it.
As far as your original question goes, I can't think of any shortcuts that would help your situation.

Hmm.  If it was available to me, I gather that I would see a "Convert to Discussion" button on the
right, but I don't, so I guess this is asking to be converted when you get a chance..

With trying to live with this problem for some time now, I do have a suggestion that I think would help.
I had thought that perhaps the "new -> typedef" entry in the DataTypeManager might give me what I wanted, but it seems that using a typedef gets replaced with the contents of the type when the typedef is used.  That is, if I have an enum localMsgType and a typedef msgType => localMsgType, then if I define an element in a structure or function signature as a msgType, it gets replaced with localMsgType when the data is parsed.
What I want is perhaps an AliasDataType that contains the name of a DataType to alias to.  When the type is referenced, it looks up the alias.  Or perhaps it looks up itself or something.  The idea is that One file defines an alias for msgType to be localMsgType, which is an enum with the particular message codes for this binary.  Many functions take a msgType argument, and message structures take a msgType member in the structure, and the FunctionDefinitionDataType signatures and referencing structures all can be shared between different binaries, but when it comes time to use the DataType, it refers to the localMsgType enum in that particular binary which is not shared with other binaries.
Does that make any sense at all?  I want to share structs and signatures that refer to msgType, but have a unique msgType for each binary (since each one has a different numbering).
Similarly, I might have an alias for "struct foo" that some binaries set up to refer to "struct foo1" and others refer to "struct foo2" because at some point in the code's evolution a few fields were added to the real struct foo, but I want to share everything that only references struct foo between all of the different binaries.


Fix boolean config value race condition

This PR fixes race condition for boolean config values. When pack schema had
type: boolean
default: true

Overriding it in pack's config with value: false, would still give value: true.
I apologize for not including tests in this PR, but I could not quickly find a way how I could pass boolean value to set_datastore_value_for_config_key in st2common/tests/unit/test_config_loader.py . If someone could point me the right direction, I would be glad to add unit test for that.

Thanks, good catch, but can you please add test cases for it?

And please also update changelog :)

@geriBatai  How is this looking?
Would be great if we can get it finished soon so we can get it included in v2.3.1.
If you don't have time in the near time, let me know and I will pick it over and finish it.

Also, looking at the failing tests a bit, looks like this change will be a bit more involved and we need to be careful to not break something.
I think the best way to start with this change would be to add failing test cases (scenarios which are not correctly handled right now) and work from there to make all the tests pass.

Here we go - #3531.

I will go ahead and merge #3531 because we are in a bit of a rush to make sure that change makes it into the next release (v2.3.1).
Thanks again for catching, reporting and working on this :+1: