Identifiers validation failed for dataset CRI - Herbário Pe. Dr. Raulino Reitz

Identifier validation failed for the dataset CRI - Herbário Pe. Dr. Raulino Reitz:

Crawler attempt: 390
Publishing organization: Universidade do Extremo Sul Catarinense
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 14781
Cause: GBIF IDs hit maximum allowed - 50%, duplicates - 100%, total records count 14845, absent records count 14845
Step metrics:

Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3042314/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the CRI - Herbário Pe. Dr. Raulino Reitz : https://doi.org/10.15468/wvampl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

contacted 07-18-2023

Identifier validation still  failing for the dataset CRI - Herbário Pe. Dr. Raulino Reitz:

Crawler attempt: 394
Publishing organization: Universidade do Extremo Sul Catarinense
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 14781
Cause: GBIF IDs hit maximum allowed - 50%, duplicates - 100%, total records count 14845, absent records count 14845
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3072451/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the CRI - Herbário Pe. Dr. Raulino Reitz : https://doi.org/10.15468/wvampl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset CRI - Herbário Pe. Dr. Raulino Reitz:

Crawler attempt: 395
Publishing organization: Universidade do Extremo Sul Catarinense
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 14781
Cause: GBIF IDs hit maximum allowed - 50%, duplicates - 100%, total records count 14845, absent records count 14845
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3083289/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the CRI - Herbário Pe. Dr. Raulino Reitz : https://doi.org/10.15468/wvampl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset CRI - Herbário Pe. Dr. Raulino Reitz:

Crawler attempt: 396
Publishing organization: Universidade do Extremo Sul Catarinense
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 14781
Cause: GBIF IDs hit maximum allowed - 50%, duplicates - 100%, total records count 14845, absent records count 14845
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3083844/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the CRI - Herbário Pe. Dr. Raulino Reitz : https://doi.org/10.15468/wvampl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset CRI - Herbário Pe. Dr. Raulino Reitz:

Crawler attempt: 397
Publishing organization: Universidade do Extremo Sul Catarinense
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 14781
Cause: GBIF IDs hit maximum allowed - 50%, duplicates - 100%, total records count 14845, absent records count 14845
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3096218/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the CRI - Herbário Pe. Dr. Raulino Reitz : https://doi.org/10.15468/wvampl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset CRI - Herbário Pe. Dr. Raulino Reitz:

Crawler attempt: 398
Publishing organization: Universidade do Extremo Sul Catarinense
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 14781
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 14845 total records; 14845 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3173151/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the CRI - Herbário Pe. Dr. Raulino Reitz : https://doi.org/10.15468/wvampl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset CRI - Herbário Pe. Dr. Raulino Reitz:

Crawler attempt: 399
Publishing organization: Universidade do Extremo Sul Catarinense
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 14781
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 14845 total records; 14845 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3184849/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the CRI - Herbário Pe. Dr. Raulino Reitz : https://doi.org/10.15468/wvampl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset CRI - Herbário Pe. Dr. Raulino Reitz:

Crawler attempt: 400
Publishing organization: Universidade do Extremo Sul Catarinense
Publishing country: BRAZIL
Installation: speciesLink Network / INCT-HVFF IPT
Number of occurrences indexed for this dataset at the time of the issue: 14781
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 14845 total records; 14845 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3257832/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the CRI - Herbário Pe. Dr. Raulino Reitz : https://doi.org/10.15468/wvampl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

closing because no response from publisher


iPad support

Fix: #6
Draft: Waiting for discussion and for https://github.com/shogo4405/HaishinKit.swift/issues/997 to be fixed. Not possible, just show warning not to use Multitasking.
Commits:
Enable iPad support
Specify sourceView when creating UIActivityViewController
Fix crash on iPad when tapping share button.
Increase Media View height on iPads
Save and restore media view height from constraint instead of hardcoding

Commit in latest push
Fix livestream preview not filling screen, show Multitasking warning
Camera access is not allowed while Multitasking.
https://developer.apple.com/documentation/avkit/accessing_the_camera_while_multitasking

@akinwale This should be fine to Rebase merge, keeps the commit history clear as there's a few separate changes.

@ktprograms Please fix the merge conflict so that I can create  the test  build.

@akinwale Done :)


Add MACH_5 from Kerbal Stuff

This pull request was automatically generated by Kerbal Stuff on behalf of Mach_966784356, to add MACH_5 to CKAN.
Please direct questions about this pull request to Mach_966784356.

#rebuild


Partial resolve issue with dynamic loading of ibverbs, mxm or hcol

This fix solve cases we loading supported modules during run-time
using ldopen(). In this situation RTLD_NEXT can not help and we
need to load libraries to resolve symbols. This change helps when
supported library can be found under standart dlopen search places.
Use LD_LIBRARY_PATH to direct location when supported module (ibverbs,
mxm or hcol) was installed in nonstandard way.
This change does not cover situation when real application must use
module from specific place but libibprof finds one in another standard
location (use correct LD_LIBRARY_PATH as an workaround).
There is probably more friendly solution as rehook dlopen() inside but
it will be implemented later.
In addition this change provides --enable-check option (turned on by default) to check api calls. It avoids segmentation faults.

bot:retest

Coverity found 2 errors, check http://bgate.mellanox.com:8888/jenkins/job/gh-libibprof-pr//ws/cov_build_8/output/errors/index.html :octocat: Sent from GH.

Refer to this link for build results (access rights to CI server needed):
http://bgate.mellanox.com/jenkins/job/gh-libibprof-pr/8/
Build Log
last 50 lines
[...truncated 4153 lines...]
+ '[' -n 3 -a -f /var/lib/jenkins/jobs/gh-libibprof-pr/workspace/cov_file_8.txt ']'
++ cat /var/lib/jenkins/jobs/gh-libibprof-pr/workspace/cov_file_8.txt
+ gh pr 3 --comment '
* Coverity found 2 errors, check http://bgate.mellanox.com:8888/jenkins/job/gh-libibprof-pr//ws/cov_build_8/output/errors/index.html'
gh [info] Adding comment on pull request #3
gh [success] https://github.com/mellanox-hpc/libibprof/pull/3
TAP Reports Processing: START
Looking for TAP results report in workspace using pattern: **/*.tap
Saving reports...
Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/coverity.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/coverity.tap].
1..1
not ok 1 Coverity Detected 2 failures # http://bgate.mellanox.com:8888/jenkins/job/gh-libibprof-pr//ws/cov_build_8/output/errors/index.html

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/ibprof_sample.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/ibprof_sample.tap].
1..1
ok 1 ibprof_sample

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/ibv_devinfo.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/ibv_devinfo.tap].
1..1
ok 1 ibv_devinfo

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/ibv_err0.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/ibv_err0.tap].
1..1
ok 1 ibv_devinfo IBPROF_ERR_PERCENT=0

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/ibv_err1.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/ibv_err1.tap].
1..1
ok 1 ibv_devinfo IBPROF_ERR_PERCENT=100

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/mpi_hello.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/8/tap-master-files/mpi_hello.tap].
1..2
ok 1 mpi_hello mlx4_0
ok 2 mpi_hello mlx5_0

There are failed test cases and the job is configured to mark the build as failure. Marking build as FAILURE
TAP Reports Processing: FINISH
Build step 'Publish TAP Results' changed build result to FAILURE
Setting commit status on GitHub for https://github.com/mellanox-hpc/libibprof/commit/ecea356bf701dca8117264e1cc7174941a2c2288
[BFA] Scanning build for known causes...
[BFA] Found failure cause(s):
[BFA] TAP test failed
[BFA] Done. 0s
Setting status of 7ebbe6c400b11bc5741122f5093ce87158ed4402 to FAILURE with url http://bgate.mellanox.com:8888/jenkins/job/gh-libibprof-pr/8/ and message: Build finished.

Test FAILed.

Coverity found 2 errors, check http://bgate.mellanox.com:8888/jenkins/job/gh-libibprof-pr//ws/cov_build_9/output/errors/index.html :octocat: Sent from GH.

Refer to this link for build results (access rights to CI server needed):
http://bgate.mellanox.com/jenkins/job/gh-libibprof-pr/9/
Build Log
last 50 lines
[...truncated 4153 lines...]
+ '[' -n 3 -a -f /var/lib/jenkins/jobs/gh-libibprof-pr/workspace/cov_file_9.txt ']'
++ cat /var/lib/jenkins/jobs/gh-libibprof-pr/workspace/cov_file_9.txt
+ gh pr 3 --comment '
* Coverity found 2 errors, check http://bgate.mellanox.com:8888/jenkins/job/gh-libibprof-pr//ws/cov_build_9/output/errors/index.html'
gh [info] Adding comment on pull request #3
gh [success] https://github.com/mellanox-hpc/libibprof/pull/3
TAP Reports Processing: START
Looking for TAP results report in workspace using pattern: **/*.tap
Saving reports...
Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/coverity.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/coverity.tap].
1..1
not ok 1 Coverity Detected 2 failures # http://bgate.mellanox.com:8888/jenkins/job/gh-libibprof-pr//ws/cov_build_9/output/errors/index.html

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/ibprof_sample.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/ibprof_sample.tap].
1..1
ok 1 ibprof_sample

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/ibv_devinfo.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/ibv_devinfo.tap].
1..1
ok 1 ibv_devinfo

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/ibv_err0.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/ibv_err0.tap].
1..1
ok 1 ibv_devinfo IBPROF_ERR_PERCENT=0

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/ibv_err1.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/ibv_err1.tap].
1..1
ok 1 ibv_devinfo IBPROF_ERR_PERCENT=100

Processing '/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/mpi_hello.tap'
Parsing TAP test result [/var/lib/jenkins/jobs/gh-libibprof-pr/builds/9/tap-master-files/mpi_hello.tap].
1..2
ok 1 mpi_hello mlx4_0
ok 2 mpi_hello mlx5_0

There are failed test cases and the job is configured to mark the build as failure. Marking build as FAILURE
TAP Reports Processing: FINISH
Build step 'Publish TAP Results' changed build result to FAILURE
Setting commit status on GitHub for https://github.com/mellanox-hpc/libibprof/commit/ecea356bf701dca8117264e1cc7174941a2c2288
[BFA] Scanning build for known causes...
[BFA] Found failure cause(s):
[BFA] TAP test failed
[BFA] Done. 0s
Setting status of 7ebbe6c400b11bc5741122f5093ce87158ed4402 to FAILURE with url http://bgate.mellanox.com:8888/jenkins/job/gh-libibprof-pr/9/ and message: Build finished.

Test FAILed.

bot:retest

Refer to this link for build results (access rights to CI server needed):
http://bgate.mellanox.com/jenkins/job/gh-libibprof-pr/10/
Test PASSed.

@miked-mellanox could you approve

Refer to this link for build results (access rights to CI server needed):
http://bgate.mellanox.com/jenkins/job/gh-libibprof-pr/11/
Test PASSed.

ok, lets handle it as diff PR


Origin and Destination labels

Closes #81

@matthewsmawfield This is ready for review.

https://github.com/unhcr/dataviz-streamgraph-explorer

@matthewsmawfield This is ready for review.

@matthewsmawfield This is ready for review.


Cyclic Sort in Python

🛠 Issue (Number)
Issue no #74
👨💻 Changes proposed
Added readme.md
added code for cyclic sort
✔ Check List (Check all the applicable boxes)

[ ✔] My code follows the code style of this project.
[ ✔] This PR does not contain plagiarized content.
[ ✔] The title of my pull request is a short description of the requested changes.

📷 Screenshots

@Kumar-laxmi Sorry for the inconvenience caused....as I was figuring out how to resolve the conflicts the earlier PR got deleted


Helm chart: Broken deployment when chart name is not "cert-manager"

Describe the bug:
I'm including cert-manager in my Helm chart as a dependency (via requirements.yaml). Let's say my chart is called "my-ingress".
Helm creates a secret called "cert-manager-webhook-webhook-tls", but then the my-ingress-webhook-deadb33f is crashing because it's trying to mount "my-ingress-webhook-webhook-tls".
Expected behaviour:
It should be possible to use a different chart name. The created secret name and webhook requirement should match - either the secret should be named after my current chart, or the webhook pod should be looking for static name
Steps to reproduce the bug:
Create a Helm chart my-ingress with requirements.yaml:
dependencies:
  - name: cert-manager
    version: 0.7.0
    repository: "@jetstack"

Install the chart.
Environment details::

Cloud-provider/provisioner: GKE
cert-manager version: 0.7.0
Install method: Helm

/kind bug

That's odd - we already do use the release name when generating the YAML manifests in the Helm chart, you can see that here: https://github.com/jetstack/cert-manager/blob/5bc0bae9fa1b650ee96ee7183addf9ed999a5638/deploy/charts/cert-manager/webhook/templates/_helpers.tpl#L46-L48
https://github.com/jetstack/cert-manager/blob/5bc0bae9fa1b650ee96ee7183addf9ed999a5638/deploy/charts/cert-manager/webhook/templates/pki.yaml#L69
https://github.com/jetstack/cert-manager/blob/5bc0bae9fa1b650ee96ee7183addf9ed999a5638/deploy/charts/cert-manager/webhook/templates/deployment.yaml#L60
Would you mind providing a few commands that I can run to reproduce this issue locally/on my own cluster? It'd really help with digging in and debugging 😄
/area deploy
/triage needs-information

I'm going to close this issue now as we've not had a response for a while, but please re-open and update with more information if you've got more to add 😄


[Question] Any examples using pretty-text outside of formatic?

I should be able to hack through it, but do you have any examples or tips on using the pretty-text component outside of formatic?
My problem so far is setting up the config prop to pass to PrettyText. I tried including default-config.js to create it but get some import errors. Would you recommend trying to extract the component from formatic to use on my own?

Hey @tcosentino, sorry about the horribly slow reply! It's on our roadmap (but no timeline right now) to do a big refactor of formatic where we'll make all the fields more usable by themselves. They might always need a wrapper <Formatic> element though to provide context.
For now...
If I wanted to use a field by itself, I'd just wrap it in a component which owns the config and renders the field you want. So something like:
// Create a default config.
const config = Formatic.createConfig();

const MyField = ({value, onChange}) => {

  const fields = [
    {type: 'pretty-text', key: 'myField'}
  ];

  const onChangeForm = (formValue) => onChange(formValue.myField);

  return (
    <Formatic
        fields={fields}
        value={{key: 'myField', value}
        onChange={onChangeForm}
        config={FormaticConfig}
    />
  )
};

You could then wrap that in a higher order component if you wanted to make it easy to create fields of any type. Something like:
const createFieldComponent = (type) => {
  // use code from above to create a component with a specific type and return it
};

const MyPrettyTextField = createFieldComponent('pretty-text');
const MyPrettySelectField = createFieldComponent('pretty-select');


[BUG] Soft keyboard unable to populate InputFields

Describe the bug
Soft keyboard in InputFieldExamples scene within the MRTKDevTemplate project is unable to input text to InputField
To reproduce
Steps to reproduce the behavior:

Build the MRTKDevTemplate and deploy to Hololens 2
Load up the "InputFieldExamples"  scene
Select an input field, this should cause the native soft keyboard to appear
Try and enter some text using the soft keyboard.

Expected behavior
With an input field selected, typing on the soft keyboard should populate input field with whatever was entered using soft keyboard.
Your setup (please complete the following information)

Unity Version 2021.3.21f1
MRTK Commit e12380e4

Target platform

HoloLens 2

Closing, as I wasn't able to repro this issue on the latest main.
@EbilCat If you are still seeing this, please reopen.

I also have this issue. Let me know if I can help figure it out. I don't think I had this problem before on the -pre014 version, but in January I upgraded to the latest 1.0.0 versions and discovered this issue.
Of course, I didn't notice it until building and running on the actual HL2.
It seems like something is causing the input field to lose focus, but the keyboard still takes in the input. If that's the behavior, would it be possible to at least have the keyboard receive an event trigger if the input field it's supposed to be providing input to, loses focus?


Why do we generate a fresh identifier in quote?

I'm trying to grasp how Normalization by Evaluation works. Unfortunately, the resources are outright scanty at the moment. I've stumbled upon this example code:
https://github.com/AndrasKovacs/elaboration-zoo/blob/0e710812c38e2be8a2fce72a9350815be28e01a2/01-eval-HOAS-names/Main.hs#L96
I wonder why we need to generate a fresh x if we don't perform substitution, since this step has already been done during evaluation. Am I missing something?

 If we normalize this, and we don't do the variable freshening in quoting, we get \y y. y y as output, which is not correct (not convertible to the input term). The VLam result of f y depends on y as a free variable, so we can't pick y for the binder name for quoting this VLam. Instead, we pick a name which doesn't shadow anything from the current scope, which prevents any free variable in closure bodies to become conflated with the new binder.

Oh, that's right, I was just looking for this kind of logic in eval itself. Thanks!


Storing DateTime with Update doesn't seem to work

When updating a record in a table that has a datetime field, it works
`MyTable record = await database.FindAsync(c => c.GuidID == GuidID);
if (record != null)
{
record.ClientLastUpdated = DateTime.UtcNow;
await database.UpdateAsync(record);
}
However, if I attempt to update like this, the date is not stored correctly but stored as a 1/1/1. Other data does save properly.
database.ExecuteAsync("UPDATE MyTable SET ClientLastUpdated='" + DateTime.UtcNow + "' WHERE GuidID ='" + GuidID  + "'");
`

This is related to how the date is converted to string. Depending on the culture, DateTime won't be formatted the same way and because you don't specify anything, it will format to default which is not compatible with SQLite datetime format (except if you are lucky or japanese!). Furthermore, SQLite datetime can be stored either through string or integer! Doing this without checking that parameter is another recipe to database mess up.
That's why you have an ORM like sqlite-net, to avoid these kind of errors. If you want to use low level functions, be sure to understand all the consequences. sqlite-net uses this formatting ONLY if your database supports datetime as string!
Hope this helps


Providing an updated 256bit color patch for xterm

https://gist.github.com/saitoha/7822989 no longer applies to recent xterm versions. Would it be possible to update the patch?

@ismail That patch seems to be no longer needed now. Try
$ echo "XTerm*decTerminalID: vt340" >> $HOME/.Xresources
$ echo "XTerm*numColorRegisters: 256" >>  $HOME/.Xresources
$ xrdb $HOME/.Xresources
$ xterm

or
$ xterm -xrm "XTerm*decTerminalID: vt340" -xrm "XTerm*numColorRegisters: 256"

Indeed you are right! Would be nice to document this :-) Thanks a lot!


More AnmManager with some fixups

Did some pretty simple mapping and moved AnmVm to its own file mostly

I merged the mapping update, you might need to rebase.


docs: update compatibility warning

Update existing compatibility warning in docs to reflect the switch to apiextensions.k8s.io/v1 CRD in v0.39.0 which requires kubernetes v1.16 or newer (#3175, #3187).

Thank you so much for this, I think this is very useful!
It appears a formatter is complaining https://travis-ci.org/github/coreos/prometheus-operator/jobs/712349042, otherwise this lgtm!

Reverted accidental whitespace change. Should be good now.


Implement parsing msgpack parameter

This PR implements parsing msgpack request body with Content-Type: application/msgpack header.

LGTM. Thanks!

Thank you!

@jingweno Is this on latest version v0.4.3? pull from ruby gems can't see this there.

@a2ikm Also, it would be nice if there was also a raw array format parser by which attributes could be matched with the index of the array (in specific order) and parsed to activerecord attributes. I'm thinking the challenge would be how to give active record attributes a specific index key through which they match with the decoded msgpack array.


Questions about preprocessing

After preprocessing(clean_data()), the column contained missing value will be deleted. Why not filling them with the value of last day so it will be robust to more situations?

For daily data, missing values are mainly because the stock is unlisted, delisted, or suspended. In this case, it may not be robust to use simple forward filling.


Added crossy road game

added html css javascript file for crossy road game.
fixes #1116

I am closing this PR because all of the checks have failed. Please create a new one.


Add has_updates to C++ metadata

What
Here we add has_updates to C++ metadata - without it we crash when querying with the type-erased Vamana index. The one interesting thing to me is that in Python has_updates is an int64:
### Array Metadata ###
- Key: has_updates
- Value: 0
- Type: DataType.INT64

So we also do that in C++.
Changes
In order to get this to work I made two changes beyond the core code and unit tests:

Update the Vamana index in external/test_data/nano/vamana/vamana_test_index, as well as src/include/test/notebooks/gen_vamana_metadata.ipynb which is used to generate it.

Side note: I don't like this pattern of checking in extra arrays to the repo because all they really test for is backwards compatibility. It seems better to instead use the backwards compatibility CI job and indexes it creates, instead of these one-off indexes. This is easier to maintain and simpler, yet still provides similar testing coverage for the same set of potential issues. In a follow-up I plan to remove these indexes, but I'll hold off for now.

Add #include "detail/linalg/vector.h" to src/include/index/vamana_index.h - we failed to compile in one of the unit tests without it.

I also added some unit tests to apis/python/test/test_index.py that check the metadata when the indexes are created. This is not required, but I used it to understand the Python code better, and it seems like a nice test to add.
TODO

As mentioned above, in a future update I would like to remove as man indexes checked into external/test_data/ as I can.
Once I do that I will be able to mark has_updates as a required field in src/include/index/vamana_index.h. Right now it is optional because otherwise all the unit tests would fail. I could update the checked in indexes (I did ask Andrew to share the code he used to generate them), but I still don't love that, as it just means the next time we want to change something we need to regenerate the indexes.

Testing

Adds several new unit tests. One of these is to explicitly load metadata in src/include/test/unit_backwards_compatibility.cc. This check was then removed from src/include/test/unit_ivf_flat_metadata.cc and src/include/test/unit_vamana_metadata.cc. In it's place I added a check where we create an index and then load the metadata.
Olds unit tests pass.

Talked to @NikolaosPapailiou offline - we will want this eventually, but for now we can just make Python work with C++ indexes which do not have has_updates. Then we need to change less code which is nice. So closing for now.


Problems Generating Call Graph for Apps

I'm start using Argus-SAF to generate call graphs. In my case, both callbacks and ICC communications are supposed to be viewed as edges in call graphs. I'm reading about the tutorial and examples to learn about it. But I'm wondering if there is some simple solution or direct example of achieving this.
Actually, I found that there are some mismatches between the homepage and the latest version of Argus-SAF, e.g., there is no such field resolve_icc. To my current understanding, I can generate call-graph with InterProceduralSuperSpark for each component, and then merge them together. But as far as I can see from the result, there is no edge corresponding to ICC communications in the merged call graph(using InterProceduralDataflowGraph.merge()). Also, there are no edges for callbacks like Thread.run() or Thread.start().
To summarize, I'm wondering:

if there is direct way to generate call graphs with callbacks and ICCs considered;
if this must be done by hand, it would be nice to have some simple examples.

I'd be very grateful if someone can help.

I read the paper and started to getting the points. Hope I can solve it.


Add curl into the test container

It's used for resetting etc.
Looks like this has been a problem for a while, but the test container had not been rebuilt so everything was still working.  Looks like a push to this repo resulted in a rebuild of the test container.

Ah figured it out. Our past builds of libcalico include this message:
World updated, but the following packages are not removed due to:
  curl: git

Looks like in the past, the build process refused to uninstall curl. I believe 'git' no longer requires 'curl, which means our call to apk remove curl now succeeded.
LGMT


Changes for adding default dimensions in CWSink.

Description

Added FlintMetricSource, which will be used in upcoming PRs for publish all kinds of metrics.
Added default dimensions of domainId, jobId, applicationId while publishing metrics in CloudWatch Sink.
Removed prefixes appended to metricNames. For eg:
Previous Metric Name:
driver.00fg29jd50i99g0m.LiveListenerBus.queue.appStatus.listenerProcessingTime
Current Metric Name:
LiveListenerBus.queue.appStatus.listenerProcessingTime
Changed the separator in DimensionedName encoder to "##" to remove conflicts with names containing ": "

Sample Metrics Testing:

Issues Resolved
List any issues this PR will resolve, e.g. Closes [...].
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@vamsi-amazon Would you prefer a seperate commit for AOP or should I contribute to this PR?

@vamsi-amazon Would you prefer a seperate commit for AOP or should I contribute to this PR?

Separate PR. I would minimize the changes in this PR and would limit to just publishing opensearch response code metrics. You can refactor and add AOP. Will publish the PR by end of the day.

This fix the backport issue https://github.com/opensearch-project/opensearch-spark/pull/230


hydra.errors.MissingConfigException: Cannot find primary config 'configs/samurai/sam2.1_hiera_b+.yaml'. Check that it's in your config search path.

Missing Configuration File Causes MissingConfigException
> python scripts/demo.py --video_path video.mp4 --txt_path first_frame_bbox.txt
  Traceback (most recent call last):
    File "/kaggle/working/samurai/scripts/demo.py", line 122, in <module>
      main(args)
    File "/kaggle/working/samurai/scripts/demo.py", line 44, in main
      predictor = build_sam2_video_predictor(model_cfg, args.model_path, device="cuda:0")
    File "/opt/conda/lib/python3.10/site-packages/sam2/build_sam.py", line 71, in build_sam2_video_predictor
      cfg = compose(config_name=config_file, overrides=hydra_overrides)
    File "/opt/conda/lib/python3.10/site-packages/hydra/compose.py", line 38, in compose
      cfg = gh.hydra.compose_config(
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/hydra.py", line 594, in compose_config
      cfg = self.config_loader.load_configuration(
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/config_loader_impl.py", line 142, in load_configuration
      return self._load_configuration_impl(
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/config_loader_impl.py", line 253, in _load_configuration_impl
      defaults_list = create_defaults_list(
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 745, in create_defaults_list
      defaults, tree = _create_defaults_list(
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 715, in _create_defaults_list
      defaults_tree = _create_defaults_tree(
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 356, in _create_defaults_tree
      ret = _create_defaults_tree_impl(
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 457, in _create_defaults_tree_impl
      return _expand_virtual_root(repo, root, overrides, skip_missing)
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 280, in _expand_virtual_root
      subtree = _create_defaults_tree_impl(
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 464, in _create_defaults_tree_impl
      config_not_found_error(repo=repo, tree=root)
    File "/opt/conda/lib/python3.10/site-packages/hydra/_internal/defaults_list.py", line 799, in config_not_found_error
      raise MissingConfigException(
  hydra.errors.MissingConfigException: Cannot find primary config 'configs/samurai/sam2.1_hiera_b+.yaml'. Check that it's in your config search path.

  Config search path:
      provider=hydra, path=pkg://hydra.conf
      provider=main, path=pkg://sam2_configs
      provider=schema, path=structured://

I and @ALFONSOBUGRA think it occurred due to commit number 2f0cdf0
elif "base_plus" in model_path:
- return "configs/sam2.1/sam2.1_hiera_b+.yaml"
+ return "configs/samurai/sam2.1_hiera_b+.yaml"

Please check if you are pointing to the samurai-version of sam 2, the config files are all in https://github.com/yangchris11/samurai/tree/master/sam2/sam2/configs.

Hey, there i am facing the same issue the config cannot, try all your solution but the things didn't work; is there any other thing we can do for it.

@dhruvai09 You are excecuting the demo.py within the script folder, try executing outside in the samurai folder.
It also seems like you are using the original sam2.1 config instead of samurai config from your error message, so you might want to git pull the latest version of code.

@dhruvai09 You are excecuting the demo.py within the script folder, try executing outside in the samurai folder.
It also seems like you are using the original sam2.1 config instead of samurai config from your error message, so you might want to git pull the latest version of code

Thanks for the quick response, it's working.


Update upgrade script for fixed roles in APG17

Description
Earlier we failed upgrade if fixed roles exist.
With this commit, we updated the script for fixed roles as:

throw warning instead of exception for fixed server roles.
check if expected fixed database roles exist, throw the warning else create fixed db roles.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 74.809%

Totals

Change from base Build<PHONE_NUMBER>5:
0.0%

Covered Lines:
46469

Relevant Lines:
62117

💛  - Coveralls

Not required.


Dataset can't be downloaded

Hello
I just tried to download datasets from the page of contest you provided in readme, but I'm not able to download data from here(
Don't you have this data stored in some other place?
Thank you in advance

Same problem , also if we could get the pre-trained weights fir further finetuning.
Thanks

I have download the datasets ,but it can't be used for your project. Is there something need I to do? @hyhouyong

@Gs-Zhang
Same problem here. Have you solved the problem? It will be appreciated that you could tell me the solutions.
Looking forward to your reply.

Sorry,I also don't find the dataset as the same as what he use.But maybe you can do it yourself,and modify the code.There is a dataset on internet,and you can use it to finsh your task.Just need to separate it into serval parts.
---Original---
From<EMAIL_ADDRESS>Date: Fri, Jul 5, 2019 08:30 AM
To<EMAIL_ADDRESS>Cc: "Mention"mention<EMAIL_ADDRESS>Subject: Re: [HiKapok/tf.fashionAI] Dataset can't be downloaded (#7)
@Gs-Zhang
Same problem here. Have you solved the problem? It will be appreciated that you could tell me the solutions.
Looking forward to your reply.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@
Thank you for your help! Best wishes!

@Gs-Zhang
Thank you for your help! Best wishes!


iOS system paste always prepends a space on textboxes

Pasting passwords in osu! on iOS gets annoying because of this. I'm seeing this with the 3-tap paste feature, not sure about pasting using hardware keyboard in iPad.
Potentially related to https://github.com/ppy/osu-framework/issues/5046.

Bumping to p0 as hopefully it should be an easy fix. It's an important one to get right as if it's broken people will be attempting to login and reporting failures due to password pasting wrong (has happened in the past)

Tested this with a hardware keyboard and I cannot reproduce the issue.
(I also cannot test the popover paste item since it does not appear possibly due to the hold to rightclick menu, but the paste button on the software keyboard in iPadOS also works as intended)
Tested on iOS 17.0 (iPad), iOS 16.6 (iPhone) by copying from the Bitwarden app, osu-2023.815.0


Update plugins after updating to Jenkins 2.0

Fix issue https://github.com/gmacario/easy-jenkins/issues/104
Signed-off-by: Gianpaolo Macario<EMAIL_ADDRESS>

Tested locally.
LGTM, merging


Revert "mvsim: 0.7.1-1 in 'humble/distribution.yaml' [bloom]"

Reverts ros/rosdistro#37598
FYI @jlblancoc

Nevermind, I misunderstood buildfarm error.


Include paymentHash in LiquidityEvent.Source

This allows integrators to easily map events to payments.

Looks good. However this will require work on Phoenix side to account for the Source type change in the database.

I'm not sure this will be necessary once we have #649 where the payment_hash can be found in the liquidity purchase structure.


Special character scrambled after SMS restore

SMS Backup Version 1.5.8
Android Version 4.4.2, tested on HTC One Mini and Wiko Birdy
After restoring SMS, all special characters and German Umlaut (ä,ö,ü,..) are scrambled. It seems  to be an UTF8 coding issue because hex (C3 A4) is the code for 'ä'.
Example:
Restored Text: Hey p=C3=A4de, ...
Orig Text in Gmail: Hey päde
I also tested the restore with previous version 1.5.x from Google play store (don't know the version number...) without this issue.

closed in fd420c75fd4fc5457da8e94cace1d470e51c771c
sorry about that, just pushed a new apk to google play.


Fix to #17236 - Improve readability of expressions in client evaluation exception

Adding a new switch to ExpressionPrinter that creates simplified output for Print and verbose (i.e. what we had before this change) for PrintDebug.
Simplified output means:

displaying Enumerable/Queryable methods (e.g. Where, Select, Join) as extension methods
simplifying display of Navigation object

Also fixed minor display bugs in expression printer.
Also some changes in testing:

added unit tests for ExpressionPrinter,
DRY the "translation failed" tests,
"translation failed" tests no longer verify expression in the exception message and instead just make sure that right exception is thrown.

Resolves #17236

ping

@AndriySvyryd @smitpatel new version up


Deep-Insights.js AutoStyle integration and ::outline polygon properties

Context: https://github.com/CartoDB/cartodb/issues/7723. For some CartoCSS polygon properties, we want to use them within a ::outline scope.
Once the auto-style part of Deep-Insights decides what is the best CartoCSS, it sets it, and Builder has to understand it to reflect that into the interface components. This is half broken right now, as some of the properties are behind mapnik::geometry_type filters.
We might need changes in the way detect ::outlined properties as we rely on regular expressions, so we can reflect them in the Builder interface. See https://github.com/CartoDB/cartodb/blob/ed553a8b34fedbb0f9a7ab429615b437ad6c9fb3/lib/assets/core/javascripts/cartodb3/deep-insights-integrations.js and https://github.com/CartoDB/cartodb/blob/ed553a8b34fedbb0f9a7ab429615b437ad6c9fb3/lib/assets/core/javascripts/cartodb3/editor/style/style-definition-model.js#L39 for context.
However, we should take this as an opportunity to change the way the Deep-Insights – Builder integration works. So instead of leaving the room open to change the CartoCSS from Deep-Insights directly, making Builder responsible for understanding all the changes to reflect them on the interface, we should define a model to change the style from outside so the interface is easier to update and the CartoCSS is still easy to generate.
Also important, there is an existing PR working on big changes in deep-insights-integrations.js wich will conflict with any change done in this area.

Deployed!

👏

🎉 !


Installation error

I am receiving this error message when running the installation.
Page not found l, could not install. [Repo]: repository.icarbrandt.test Check Long url.....
(see image below)

I am receiving this error message when running the installation.
Page not found l, could not install. [Repo]: repository.icarbrandt.test Check Long url.....
(see image below)

I opened a PR with a simple fix you can zip this branch and install it using the local zip.


Update package installs for uuid for apk

Not gonna block this one now but there's a neater way of doing those build dep installs and removals. I'll chat tomorrow about it.


generator: export oneof interface types

We currently generate unexported interface types for oneof fields.
(https://github.com/golang/protobuf/blob/master/protoc-gen-go/generator/generator.go#L2027)
That makes it extremely difficult to write helper-functions that accept oneof values as parameters and use them to set fields (e.g. to generate skeleton messages with the oneof field set within a couple layers of nesting).
Beyond that, it's awkward and confusing to have unexported types in the exported documentation for the package — users need to be familiar with the details of our oneof implementation to make sense of it.
We should export the oneof interface types.

Because isMessageName_MyField visibility is package only, it makes a code operating on it unnecessary complex, e.g. when one want to return a isMessageName_MyField she must return interface{}, cast it to the right underlying type of value and just then can assign to MyField.
Also a function which normally would have a signature:
func (IsMessageName_MyField), right now must take any value: func (interface{}).
The change is trivial, but I cannot find any instruction how to run tests against it (I expect them to fail):
https://github.com/orian/protobuf/commit/f72201aca5615112c2793af0b656979e062b535f

Hitting the same issue when attempting to operate on union types generically. Exporting would help a lot with the use case of a message containing a header and body, with the body being a oneof and the header being generated based off other conditions independent of the body type.

Can we get a response to this issue? Not exporting the interface or the methods that satisfy that interface makes for some really terrible code with no conceivable benefit. It blows my mind that some of the exported helper methods return this unexpected interface, in direct contradiction to Go conventions (see: golint), but for some reason the interface was decided to not be exported.

This seems reasonable. Want to take this on @bcmills?

I don't have the bandwidth for it at the moment, but it should be a minor (i.e., fully backward-compatible) change.

I solved this issue by creating a new Go file in the same package as generated code with the following content:
type MessageNameMyField = isMessageName_MyField

Yep, that's type alias. IMO, that's one of the few valid reasons to use it.
But I really hope #588 will be merged soon.

Copying my comment from #588:

I don't think we should do this.
In the protobuf data model, there is no such thing as a single "oneof field" that aggregates the individual components of a oneof. Instead a oneof is just a set of mutually exclusive fields which behave just like non-oneof fields, except setting one implicitly clears all the others.
Exporting this type would introduce a concept into the Go generated code which has no equivalent in most (all?) other languages' protobuf implementions. I don't think that's a good idea.
In addition, the current Go implementation oneofs leaks too many details of the implementation to the user. I think we can do a lot to improve that; in particular, adding setters for oneof fields would be a big help. This PR goes in the wrong direction, by exposing even more of those implementation details.

Closing per @neild's comment: https://github.com/golang/protobuf/issues/261#issuecomment-435081813


cargo rustc being used instead of check.

Edit
When testing this and pasting information i realized my rustc was 1.14, while i have the 1.15 source. I updated it, and the program no longer completely fails, i do get errors back. Though I do still wonder why I'm not getting cargo check :)
Original Issue
Version of VSCode: 1.9.1
Version of the extension: 0.3.6
OS: Mac OS
Description:
Hello, I have an issue where cargo runs rustc to do the check, instead of using cargo check. I've been digging through a bit of the extension code, and i see that it evaluates whether cargo check is there, and will call cargo check or cargo rustc. The problem with rustc, is the -Zno-trans option seems to be deprecated, and I can't compile the build with it. Where as trying in iTerm, cargo check runs fine. Any ideas as to why it's still calling rustc?
Output when building on save:
Started cargo rustc --message-format json -- -Zno-trans
   Compiling am_test v0.1.0 (file:///Users/aaronmcleod/src/rust/am_test)
error: Could not compile `am_test`.

To learn more, run the command again with --verbose.
Completed with code 101
It took approximately 0.77 seconds

My VSCode settings:
// Place your settings in this file to overwrite the default settings
{
    "editor.renderWhitespace": "all",
    "git.confirmSync": false,
    "files.trimTrailingWhitespace": true,
    "editor.tabSize": 2,
    "rust.rustLangSrcPath": "/usr/local/src/rustc-1.15.0-src/src",
    "rust.actionOnSave": "check",
    "rust.cargoPath": "/Users/aaronmcleod/.cargo/bin/cargo"
}

Output of the "Rust logging" channel:
DEBUG: SuggestService: start(): enter
DEBUG: SuggestService: start(): racerPath=racer
DEBUG: MissingToolsInstallator: getMissingTools(): pathDirectories=["/Users/aaronmcleod/.rbenv/shims","/usr/local/Cellar/vim/7.4.027/bin","/usr/local/bin","/usr/local/bin","/usr/bin","/bin","/usr/sbin","/sbin","/Users/aaronmcleod/bin","/Users/aaronmcleod/Library/Android/sdk/platform-tools","/Users/aaronmcleod/Library/Android/sdk/tools","/Users/aaronmcleod/.cargo/bin",""]
DEBUG: MissingToolsInstallator: getMissingTools(): tools={"racer":"racer","rustfmt":"rustfmt","rustsym":"rustsym"}
DEBUG: MissingToolsInstallator: getMissingTools(): missingTools=[]

Hi @agmcleod,
Thanks for your feedback.
I have no idea why it does that.
Let me check.

@KalitaAlexey probably should have posted my edit in a comment. Updating to 1.15 rustc prevents it from exiting completely, so i at least get feedback returned. Would still prefer to use cargo check if possible though.

@KalitaAlexey absolutely. I was trying to write console.log statements in the plugin code to see what was going on, but im guessing that doesnt work with the release version :), or i simply didnt know where to check for output.

@agmcleod,
If you have a source code you can execute it via F5.
It opens a new window.
console.log would be shown in the windows where the source code is opened.

I have pushed a commit.
Please update and reproduce the issue.

Sorry for taking a bit, got busy with work.
DEBUG: Cargo Manager: CargoTaskManager: Task: execute: cargoPath = "/Users/aaronmcleod/.cargo/bin/cargo"
DEBUG: Cargo Manager: CargoTaskManager: Task: execute: this.args = ["check","--help"]
DEBUG: Cargo Manager: CargoTaskManager: Task: execute: cargoEnv = {}
DEBUG: Cargo Manager: CargoTaskManager: OutputChannelTaskManager: Task: execute: cargoPath = "/Users/aaronmcleod/.cargo/bin/cargo"
DEBUG: Cargo Manager: CargoTaskManager: OutputChannelTaskManager: Task: execute: this.args = ["rustc","--","-Zno-trans","--","-Zno-trans","--","-Zno-trans","--","-Zno-trans"]
DEBUG: Cargo Manager: CargoTaskManager: OutputChannelTaskManager: Task: execute: cargoEnv = {}

Can you execute:
"/Users/aaronmcleod/.cargo/bin/cargo check --help

and look what it will give you?

Compile a package and all of its dependencies

Usage:
    cargo rustc [options] [--] [<opts>...]

# etc

It is strange, isn't it?

Probably you have cargo-check installed.

Yeah, maybe i have the whole thing confused. So i installed cargo-check yesterday, and symlinked the binary. Should I use nightly to compile a local copy of check instead via the repo?

You don't need cargo-check. It's integrated into cargo.
2017-02-09 18:55 GMT+01:00 Aaron McLeod<EMAIL_ADDRESS>
Yeah, maybe i have the whole thing confused. So i installed cargo-check
yesterday, and symlinked the binary. Should I use nightly to compile a
local copy of check instead via the repo?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/KalitaAlexey/vscode-rust/issues/63#issuecomment-278720249,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYmbhl3Yh49B-DcldoAKJ14qp164ndMks5ra1MNgaJpZM4L8QRf
.

@agmcleod,
Cargo has built-in check.

It isn't stable yet.

Hi @CryZe, can you look at #68?

@agmcleod,
I am closing this issue because there is no problem in the extension.


⚠ Bofrost.at has degraded performance

In 5b109f7, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1503 ms

Resolved: Bofrost.at performance has improved in ede8220.


Not documented / bad UX between ImageUpdateAutomation + Submodules

I tried adding an ImageUpdateAutomation for a GitRepo that I had configured some time ago without any automations, and everything worked fine for one or two updates, but after a bit longer I started getting this error instead of successful commit and push from flux get image update:
$ flux get image update
NAME        	READY	MESSAGE                           	LAST RUN	SUSPENDED
apps-jenkins	False	worktree contains unstaged changes	        	False

It is a really basic image update automation, it just works on a single image in the HelmRelease. It committed with success twice without errors:

https://github.com/kingdonb/fleet-infra/commit/24d4809fef7ad37753eac1a90401e71d1d9f9acf
https://github.com/kingdonb/fleet-infra/commit/b4d6a5ed1a93e4ee71e9e0025240fd62c30150ff

I suspect it failed after that because of git submodules. It was surprising that it failed after two successful updates. I did not remember adding submodules in this repo, like I mentioned it was an older repo that was started some time ago and has been around for a while. If I clone it now with git clone --recurse-submodules I do not see any trace of the submodules that I did remove, that were there once for some reason but not important to my Flux deployment, so I thought I could just remove them but that did not evidently have any effect, as I still get the error worktree contains unstaged changes.
I added a separate GitRepo for this automation called flux-system-rw with a hand-configured SSH deploy key that has read-write permission, so it would not be mixed together with my bootstrap credentials that are read-only.
I am going to copy these files (just the important ones that I intended, without any submodules) to a new git repo and see if I can't get ImageUpdateAutomation working there, but for now it seems like anyone who tries using Image Automation on a repo that has or has had submodules enabled, might be subject to a bad time.
The first smallest thing I think we should do to fix all this is to document the correct way to recover, if it is possible, without nuking the repo from orbit. (I will keep it around for now in case we need it for debugging, I don't think it will be that hard to repro the error given that it worked twice before failing, it will probably always work twice, or maybe never work again; perhaps all I need to do now is clear my image resources and let Flux apply them again from the gitrepo to resolve it. Whatever it is that fixes the issue, we should have it documented until at least as long as we find a way to fix it somehow.)

[X] Bootstrapped against a new repo that does not have any submodule history in it, to verify my image update automations all function OK when there is no submodule present. ✅
[ ] Set up a GitHub Actions Auto Pull Request workflow
[ ] Actually verify ImageUpdateAutomation doesn't get stuck under heavy use (with the repo that has no-submodule history)
[ ] Reproduce the issue with submodules and see what can be done to make it fail more gracefully

I'm seeing the same error, "worktree contains unstaged changes", on a project whenever I stop using master for my pull / push branches. The git repo has no submodules. Any idea why this may be? Even if I pull from master and have push set to a brand new branch (looks like the controller should create it if doesn't exist, but tested manually creating one myself) I'm still seeing unstaged changes somehow.

Any updates on this @kingdonb ?
We are also facing the same issue, when submodules are pushed to the same repository where flux needs to update the image from ecr, it is throwing error: "worktree contains unstaged changes"

Thanks for re-raising this @ajaygoudaY to let us know you're interested in it – I haven't got around to the submodule issue, but we are making progress on Image Automation front and making that more reliable.
I will make a note to come back and try reproducing this after a few other things in front of me 👍 (commenting here also makes it more likely to come up in conversation during the weekly Bug Scrub, because of the sort ordering we use there.)


cmctl as downloaded for 1.8.0 shows canary as its version

Describe the bug:

I just downloaded cmctl from this repository and running cmctl version doesn't show the command actual version (1.8.0). I was expecting 1.8.0 but instead is shows canary.
This is the current output
Client Version: util.Version{GitVersion:"canary", GitCommit:"", GitTreeState:"", GoVersion:"go1.17.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: &versionchecker.Version{Detected:"v1.7.1", Sources:map[string]string{"crdLabelVersion":"v1.7.1"}}

If I run the same using version 1.7.2, then this is fine and the correct version is displayed
Client Version: util.Version{GitVersion:"v1.7.2", GitCommit:"2e0bfc87d0c63c473c31a17f4c8c65e89806dc16", GitTreeState:"clean", GoVersion:"go1.17.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: &versionchecker.Version{Detected:"v1.7.1", Sources:map[string]string{"crdLabelVersion":"v1.7.1"}}

Expected behaviour:

cmctl version shoud show version 1.8.0.
Steps to reproduce the bug:

download cmctl from https://github.com/cert-manager/cert-manager/releases/download/v1.8.0/cmctl-linux-amd64.tar.gz
unpack the archive via tar -zxf cmctl-linux-amd64.tar.gz
run ./cmctl version

Anything else we need to know?:
Environment details::

Kubernetes version: 1.22
Cloud-provider/provisioner: bare metal
cert-manager version: 1.8.0 (client), 1.7.1 (deployed)
Install method: e.g. helm

/kind bug

Hi! That is strange, I thought I had fixed this in https://github.com/cert-manager/cert-manager/pull/4968. 😞
I will investigate now.

It seems like we can't have multiple -ldflags in a go build command (source).
The make command
make bin/cmctl/cmctl-linux-amd64

runs go build with two consecutive -ldflags. The second one "cancels" the first:
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 GOMAXPROCS= \
  go build -o bin/cmctl/cmctl-linux-amd64 -trimpath \
  -ldflags '-w -s -X github.com/cert-manager/cert-manager/pkg/util.AppVersion=v1.8.0-6-gd212165c8da228 -X github.com/cert-manager/cert-manager/pkg/util.AppGitCommit=d212165c8da228437e71a74c2e117ae9d62c7f24' \
  -ldflags '-X "github.com/cert-manager/cert-manager/cmd/ctl/pkg/build.name=cmctl" -X "github.com/cert-manager/cert-manager/cmd/ctl/pkg/build/commands.registerCompletion=true"' cmd/ctl/main.go

The right command would look like this:
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 GOMAXPROCS= \
  go build -o bin/cmctl/cmctl-linux-amd64 -trimpath \
  -ldflags '-w -s -X github.com/cert-manager/cert-manager/pkg/util.AppVersion=v1.8.0-beta.0-4-g312baa4d7e0a25 -X github.com/cert-manager/cert-manager/pkg/util.AppGitCommit=312baa4d7e0a25222571f8cdb1c95356a28a70d3 -X "github.com/cert-manager/cert-manager/cmd/ctl/pkg/build.name=cmctl" -X "github.com/cert-manager/cert-manager/cmd/ctl/pkg/build/commands.registerCompletion=true"' cmd/ctl/main.go

I'll open a PR to fix this. (cc @SgtCoDFish)

bumping this issue so it doesn't auto-close.

bumping this issue so it doesn't auto-close.

@aureq Thank you for bumping - this issue totally flew under the radar and your bump helped me realise that! Thank you for getting involved :raised_hands:  :grin:


Switch from tools to routes in sitemap operations

I'm thinking to address #6384, but before this I'd like to get rid of the deprecated tools approach in the sitemap stuff.

Sweet! Looking forward to checking this out. tools are going away in version 9 so the sooner we can get them out of the core the better.

In commit 54c1a64 I added support to more drag operations, like for instance copying the homepage under itself.

Our users have problems understanding how to select the correct destination while dragging a page.
So, I added 5ba3b92 and f30f5a3, so that we have highlighted the destination page in light blue only if it's the choosen destination, and not a sibling.
Sample recording: before

Sample recording: after

If you can swap these out to use the new router I'll take a look at them asap

Should I resolve conflicts or close this pull request?

No worries, I merged this and fixed the conflict. Thanks, this looks great.


Use the new PyVista sphinx directives for interactive plots in the documentation?

It'd be great to make the documentation examples interactive! I'll see if I can make some time to contribute this while on winter holiday

Direct help or some pointers would be very much appreciated.  I see where the DynamicScraper is specified for sphinx_gallery in pyvista conf.py, but this package does not use this Sphinx plugin.  Is it required?  It seems to me that interactive is opt-out through specifying force_static yet there must be some opt-in mechanism I cannot find.

Its all done directly through the pyvista-plot directive nowm so no need for the new dynamic scraper (that's specific to sphinx-gallery)

If you want a specific plot to opt-out of the dynamic rendering, you can specify force_static in the directive options:
.. pyvista-plot::
   :force_static:


update YARP to 1.0.0

updated YARP configuration
updated to .NET 6
changed server-destination port to 5003
updated packages
added port 5005 for Tye proxy entry

Thank you for this PR, I'll review it and make the necessary adjustments to the blog post! Cheers.

This is great, I'll make some changes to reduce the number of steps in the tutorial.


Read man page in split mode

Hi,
I find superman really great, especially when doing c programming and needing to read man pages.
I use the plugin from inside vim with for example
:SuperMan printf
I would like to open the man page in a split. Currently it creates a new buffer, and loads in a complete windows.

I'm right there with you. I just haven't found any way to do it that doesn't involve huge hacks.
There's a section from $VIMRUNTIME/ftplugin/man.vim that is of interest here:
  " Use an existing "man" window if it exists, otherwise open a new one.
  if &filetype != "man"
    let thiswin = winnr()
    exe "norm! \<C-W>b"
    if winnr() > 1
      exe "norm! " . thiswin . "\<C-W>w"
      while 1
        if &filetype == "man"
          break
        endif
        exe "norm! \<C-W>w"
        if thiswin == winnr()
          break
        endif
      endwhile
    endif
    if &filetype != "man"
      new
      setl nonu fdc=0
    endif
  endif
  silent exec "edit $HOME/".page.".".sect."~"

It's a little hard to follow, but it basically searches through all windows within the active tab for one with filetype set to "man". If it doesn't find one or if there is only one window in this tab, it uses new to create a horizontal split. If that line were tabnew instead of new, it would open all man pages in a tab instead of a split.
In the plugin right now, I use only to force the split to go away, thus allowing the man page to take up the whole screen.
I'm going to investigate this a little bit further, but I'd love to hear suggestions on how to accomplish this better. It might involve submitting a patch to the upstream man.vim plugin.

I redid a lot of the vim man page plugin (here)[https://github.com/nhooyr/neoman] to make it better at handling different sections of manpages and only use the edit command to open the manpage. I cleaned up a lot of the code (but it may have bugs, its very alpha). I also added autocomplete for the new command I use (:Neoman).
I also made it easy to integrate it with the neovim terminal. E.g. if you have a terminal buffer open in a window in neovim and you type man printf instead of opening a new neovim instance, it tells the existing neovim to open that man page.
This is the zsh function I use and you will need https://github.com/mhinz/neovim-remote
nman() {
	if [[ "$@" == "" ]]; then
		print "What manual page do you want?"
		return
	fi
	/usr/bin/man "$@" > /dev/null 2>&1
	if [[ "$?" != "0" ]]; then
		print "No manual entry for $*"
		return
	fi
	if [ -z $NVIM_LISTEN_ADDRESS ]; then
		/usr/bin/env nvim -c "Neoman $* term"
	else
		nvr --remote-send "<c-n>" -c "Neoman $* term"
	fi
}

Its again a work in progress and I'm changing a lot.

I just gave here a massive update. Its pretty good now.

Huh, that's very interesting; i'll have to give it a look. I haven't really been able to get into NeoVim's :term command (back when I first saw it the keybindings to navigate buffers were really clunky and I didn't bother changing them).


route.query() not working as expected when using # base

When using # as the base, route.query() for these URLs is not behaving correctly:

index.html?param=xyz#/search => { param: "xyz#/search" }
index.html?param=xyz#/search?q=keyword => { param: "xyz#/search?q=keyword" }

Where ?param=xyz are query params for the server rather than the router.
It's not entirely clear how it should behave. The docs don't address it and the specs only test with '/' base. My expectation is that if using a # base, the router should only consider query params after the #. Which would look like this:

index.html?param=xyz#/search => {}
index.html?param=xyz#/search?q=keyword => { q: "keyword" }

When using '/' as the base, the issue doesn't exist because there's only one set of query params which is shared between server and router.
I didn't manage to write a spec to show this failing because the code behaves differently when running in the test suite (it doesn't use location.href).

@simonomis right. Thank you for pointing it out.
Your spec seems reasonable for me.

Closing this issue because it's related to an old router version. Please update to the latest @riotjs/route version if you can.


[FLINK-22781][table-planner-blink] Fix bug in emit behavior of GroupWindowAggregate to skip emit window result if input stream of GroupWindowAggregate contains retraction and input counter of input records for current window is zero

What is the purpose of the change
This pr aims to fix a bug in emit behavior of GroupWindowAggregate when input stream contains retraction. After updating, GroupWindowAggregate would not emit window result if input stream of GroupWindowAggregate contains retraction and input counter of input records for current window is zero.
Brief change log

Update constructors of WindowOperator and it's subclasses to including inputCountIndex which means index of input counter
Update StreamExecGroupWindowAggregate to add inputCountIndex when create new WindowOperator instance.

Verifying this change

Existed ITCase in GroupWindowITCase

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

ci fails caused by FLINK-23079

@flinkbot run travis

@cshuo Would you please have a look at the pull request, thanks a lot. cc @godfreyhe

@flinkbot run travis

@cshuo @godfreyhe Thanks for your review, I've address all your comments, please have a look.


refactor: migrating modular package from v5 to v6

Flutter Modular updated to v6, however, snippets were left behind.
Simple changes made the difference, the instances are different.
References:
From v5 to v6
Newer version documentation

This also solves #20


Support Coset domain for univariate poly?

Coset radix-2 domain can be useful in some circumstances.
Perhaps we can add an offset: F to Radix2EvaluationDomain?
(Doing so, the domain will also be consistent with the domain in r1cs-std)

I think this is a duplicate of https://github.com/arkworks-rs/algebra/issues/88


Feature request: uninstaller for applications titles

Is there a way we could get uninstallers added for titles in this script?
I see this as removing files from these locations:
/Applications
/Library/Application Support
/Library/Containers
~/Library/Application Support
~/Library/Containers
I think the main things needed to do this is are already in the script app name and bundle id.

There is nothing in Installomator that can help remove installed files.
To uninstall you need the bom-file from pkgs that shows what was installed, and then those should be deleted. If it was an app that was copied, then that can be removed but what about the data that the app installed in the folders you mention?
It would be specialized for each software title, and impossible for anyone to maintain.
So that will never be part of Installomator.
On certain software titles an uninstaller is provided and that will always be the best.


feat: add support for post-cache routes

Which problem is this pull request solving?
When an edge function file doesn't have a matching declaration with a path property, it's deployed as a post-cache edge function.

Will these run for anything that would be a 404, or for things rewritten to a functions, or somehting else?


New Plugin: Azure Maps basemap provider

Adding the Azure Maps Leaflet plugin to the list of basemap provider plugins. The plugin project can be found here: https://github.com/Azure-Samples/azure-maps-leaflet

Cool.
Note that your sample code uses outdated 1.3.1 version of Leaflet.

Right. I had been testing with multiple leaflet versions. I'll update the samples to use the latest.

Cool.
Note that your sample code uses outdated 1.3.1 version of Leaflet.

Right. I had been testing with multiple leaflet versions. I'll update the samples to use the latest.

@rbrundritt
Please resolve conflicts


[vector] Handling no features on category generator

This will fix https://github.com/CartoDB/cartodb.js/issues/1151
@alonsogarciapablo

:+1:


Introduce the base gains workflow

Codecov Report
Base: 12.81% // Head: 13.28% // Increases project coverage by +0.46% :tada:

Coverage data is based on head (c611fc4) compared to base (d575a03).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##               main      #17      +/-   ##
============================================
+ Coverage     12.81%   13.28%   +0.46%
- Complexity      158      159       +1
============================================
  Files            29       29
  Lines           554      557       +3
============================================
+ Hits             71       74       +3
  Misses          483      483

Impacted Files
Coverage Δ

app/Kata/Challenges/KataChallengeEloquent.php
100.00% <100.00%> (ø)

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


After compiling Umple, pass the results to the base langauge compiler, and compile, pointing any error messages to code embedded in Umple

Originally reported on Google Code with ID 193
Owned by redeyedmars

Umple would then appear like a normal compiler, and could be used in the same manner
See also 66

Reported by @umple on 2011-06-25 03:10:44

Blocked on: #66

#882 is an active issue dealing with this same thing, so this is being closed


Performance Optimisation for Reward calculation

I think we should have a look if we can tune the reward calculation and make it faster.
For my 1000 voters it takes a bit too long. There must be some stuff we can optimise.

Yeah Agreed - we should cache votes locally and check for new voters, periodically. As when calculation for every voter we check transactions - to get latest vote transaction - meaning 1000xREST API call.
Alternative we wait - and move this to goark-node when completed, or

I think it has no high priority right now. Maybe we wait for go node. Then we can directly access it in a fast way.

agreed


Have Envoy support a NULL-DNS resolver type

Have Envoy support a new DNS resolver type: NULL-DNS resolver, which don't do DNS resolving at all.
Description:
Currently Envoy support two DNS resolver types: cares and apple.  Can we add a NULL-DNS resolver type, which if configured,  the Envoy code won't perform any DNS resolving at all.
With the effort of "Refactoring Envoy DNS resolution as extension #17479",new DNS resolver types can be easily added.  A NULL-DNS resolver may fit in the requirement in some scenarios like DNS resolving is not necessary.

Describe the desired behavior, what scenario it enables and how it would be used.
If configure with Null-DNS resolver type, no DNS resolving is performed.

Any extra documentation required to understand the issue.

cc @htuch @jmarantz @yanavlasov

Now that this is an extension point you could potentially maintain this internally? I'm skeptical this has general OSS utility.


Trouble with onkeyup

Hi!, I'm started to playing with the library and I found a strange behaviour when I try to use the onkeyup event.
const {div, p, input, label} = H;

const Input = ({ value, onchange }) => input({
	type: 'text', value: value || '',
	onkeyup: e => onchange(e.target.value)
})

const html = (props, state, setState) => div(
  label('Enter your name:'),
  H(Input, { value: state.name, onchange: (value) => setState({ name: value }) }),
  p.label(state.name ? `Hello ${state.name}` : '')
)

R(H(html), document.body)

Working code: https://jsfiddle.net/utrfb1cq/2/
The example works well, but when I'm focused into the input and press left arrow in the keyboard (or try to select the typed word without using the mouse) the cursor always go back to the end of the text.  I suppose that have any relation with the redraw of the virtual node, but I not sure.

Hey @maxidr and thank you for your feedback!
Unfortunately, it looks that by assigning the new value property the selection range changes. This means that you should carry them along, like so:
const Input = ({ value, selectionStart, selectionEnd, onchange }) => input({
	type: 'text', value: value || '',
  selectionStart: selectionStart || 0,
  selectionEnd: selectionEnd || 0,
	onkeyup: e => onchange(e.target.value, e.target.selectionStart, e.target.selectionEnd)
})

const html = (props, state, setState) => div(
	label('Enter your name:'),
  H(Input, { value: state.name, selectionStart: state.selectionStart, selectionEnd: state.selectionEnd, onchange: (value, selectionStart, selectionEnd) => setState({ name: value, selectionStart: selectionStart, selectionEnd: selectionEnd }) }),
  p.label(state.name ? `Hello ${state.name}` : '')
)

But this is kind of counter-intuitive and that definitely needs to be part of the core. I would try my best to find a solution to fix this problem while keeping the 512 byte limitation, but any contribution or discussion is more than welcome 😄

The solution was actually simpler than I expected. It should be fixed with the #13 pr

Merged! Expect it fixed on the 0.2.2 release 👍


Use container-based testing for Travis

http://docs.travis-ci.com/user/workers/container-based-infrastructure/

This gives  3 min 4 sec among pull request builds. The second best result among last 10 builds in this  category is 4 min 13 sec, so a guaranteed 25%+ improvement.

!m @techtonik


Public Registry Module Versions Are Not Ordered From Latest To Oldest

Describe the bug
When you declare a module from the public registry and go to select a version where VS Code intellisense provides the available versions as a drop-down list; this list is not ordered from latest version to oldest (top-down).

As you can see they are not even ordered in the matching order of the tags list from MAR/MCR: https://mcr.microsoft.com/v2/bicep/avm/res/storage/storage-account/tags/list
We should add some logic to order them in the VS Code extension/language server to always populate the list in order from latest semantic version, which should be selected by default, to oldest.
Cc: @shenglol
Related to: https://github.com/Azure/Azure-Verified-Modules/issues/1181

Being noticed in community more and more now https://x.com/johnlokerse/status/1813283919367696581?s=46&t=4I1PEfJog-kNAV4zqFNBGA


WIP: Use 'OPENSSL_' as common include guard prefix

The current policy mandates that all public symbols should have an OpenSSL-specific prefix in order not to pollute the global namespace of the C compiler and preprocessor.
In order to conform to the policy, all include guard prefixes are changed from 'HEADER_' to 'OPENSSL_'.
Note: This pull request replaces #8890 with consent from @DDvO (see https://github.com/openssl/openssl/pull/8890#issuecomment-496182190).
commits
The bulk changes are in commit 5e450009bac728c8d4ed1c4253182b91ec9f45e4:
commit 5e450009bac728c8d4ed1c4253182b91ec9f45e4
Author: Dr. Matthias St. Pierre<EMAIL_ADDRESS>Date:   Sun Jun 30 14:52:46 2019 +0200

    Use 'OPENSSL_' as common include guard prefix

    The current policy mandates that all public symbols should have an
    OpenSSL-specific prefix in order not to pollute the global namespace of
    the C compiler and preprocessor.

    In order to conform to the policy, all include guard prefixes are changed
    from 'HEADER_' to 'OPENSSL_'.

The bulk changes were automated using the following bash script, which is included in 63b9ca52d19c582342996d104e15835ff38fc0b5 for reference only. It will be discarded before merging.
commit 63b9ca52d19c582342996d104e15835ff38fc0b5
Author: Dr. Matthias St. Pierre<EMAIL_ADDRESS>Date:   Sun Jun 30 14:19:16 2019 +0200

    Add `update-openssl-include-guards` script [to be discarded]

Finally, the change to util/mkerr.pl is based on a patch from @DDvO  which was triggered by a change request from @bernd-edlinger (see https://github.com/openssl/openssl/pull/8669#discussion_r280882523).
commit 755b50599854734f4c70c11fe7899d875acf6db2
Author: Dr. Matthias St. Pierre<EMAIL_ADDRESS>Date:   Sun Jun 30 15:06:18 2019 +0200

    util/mkerr.pl: use 'OPENSSL_' as include guard prefix of *err.h files

    Also add a comment at the corresponding `#endif`.

Initially I thought this should be backported to 1.1.1, but meanwhile I believe that it is too big a change for doing it. Although the include guards are not part of the API in the strict sense, application developers might depend on their names to check whether certain OpenSSL headers have already been included.
What's your opinion about that, @openssl/omc?

A CHANGES entry will certainly be necessary. I will wait a little and see in which direction the discussion goes, before adding it.

Side note: the policy talks about new features (i.e new APIs)

I'm all for this change, including a back port to 1.1.1. Our current guards are ridiculously generic...

Side note: the policy talks about new features (i.e new APIs)

I assume you are referring to the commit messag. Would you find the following text more suitable?
Use 'OPENSSL_' as common include guard prefix

The current policy mandates that new public API symbols should
have an OpenSSL-specific prefix in order not to pollute the
global namespace of the C compiler. Although not mentioned
explicitly in the policy, it is sensible to apply the same rule
to preprocessor #include guards as well.

For that reason, all include guard prefixes are changed from
'HEADER_' to 'OPENSSL_'.

I'm all for this change, including a back port to 1.1.1.

Ok, I added the [1.1.1] tag to indicate my intention for backporting. Note however, that I won't cherry-pick. Instead I'll apply the final  version of the update-openssl-include-guards script to the 1.1.1 branch (and create a separate pull request), once this pull request has been accepted.

I'm all for this change, including a back port to 1.1.1.

One final remark w.r.t. backporting:
I certainly agree that it would be desirable to have the change in 1.1.1. The only caveat I see is: What if application developers added some checks for include guards like the following in their code (possibly in some auxilliary include files) in order to add some amendments to the official openssl includes?
#ifdef HEADER_BIO_H
    /* some BIO related code */
#endif HEADER_BIO_H

We promised that applications only need to be recompiled for OpenSSL 3.0, but this pull request would break that promise for people who relied on the include guards.
OTOH one can argue that the names of the include guards are not considered part of the official API.
That's why I believe it demands at least a discussion (if not a vote) by the @openssl/omc members.

We promised that applications only need to be recompiled for OpenSSL 3.0, but this pull request would break that promise for people who relied on the include guards.

Rereading my comment, I noticed that I mixed two questions together.

Should we change the include guards in master, possible breaking builds agains 3.0?
Should we change the include guards in OpenSSL_1_1_1-stable, possible breaking builds agains 1.1.1?

Currently, my opion about those questions is

Yes we should. The benefits outweigh the inconveniences. But we certainly we need to inform people loud enough.
I don't know. We could consider using the #include guards an abuse of the API, but I'm really not sure whether we would annoy some users by introducing a breaking change in a bugfix release.

Oh, don't be too harsh with your critics: Here is one valid use case from myself: I'm currently porting my company's code from 1.0.2 to 1.1.1, so I wrote a single compatibility header openssl_compat.h , which adds all the necessary  amendmends for 1.0.2 (*) in order to compile our applications against both 1.0.2 and 1.1.1.  This compatibity header is included after all openssl includes in the modules which use them. By checking the OpenSSL include guards, only amendmends for the previously included OpenSSL headers are added.
Of course it could have been done differently, but having all changes in a single file was the most simple way to do it at the time.
(*) It mostly retrofits accessors for opaque structs. Sincewe are using C++, a lot of functions could simply be copy&pasted from 1.1.1 into the header file and just the inline declaration needed to be added.

Would a sequence like this avoid the compatibility concerns:
#ifndef OPENSSL_HEADER_FOO
# if OPENSSL_API_COMPAT < 0x30000000L
#  define HEADER_FOO
# endif
...
#endif

It's a bit ugly but in 3.0, we can deprecate symbols.  It doesn't address somebody who does #define HEADER_FOO and expects the header to not load when included.
I'd still like to see the HEADER part of the name, hence OPENSSL_HEADER_FOO.

Would a sequence like this avoid the compatibility concerns:
...

I'm not sure. I'd rather not backport this pull request than creating such a three-headed monster.

I'd still like to see the HEADER part of the name, hence OPENSSL_HEADER_FOO.

Do you have any particular reason for your wish? Because what I like most about my naming convention is precisely the fact that for all the public header files the include guard name and the include directive match nicely (e.g. <openssl/hmac.h> and  OPENSSL_HMAC_H). For the internal files, the correspondence is similar although not always consistent.
For me, the _H suffix (which is missing in your example) seems to be sufficient to indicate an include guard.  If that not obvious enough for an include guard, I'd prefer something like OPENSSL_HMAC_H_INCLUDED

The _H suffix would be sufficient I guess.  I don't think there are any examples of a macro ending _H unless it is a head guard.  At least not yet :)

I force-pushed new commits, adressing all review comments (hopefully). Manual changes were made exclusively in the update-openssl-include-guards script (commit b64721082624c1a1c736d53c3dadb72826ce5615), the bulk changes were regenerated  using the script (commit 1ee38fc6c30ee1349e7a5dad313ea99134151bee).
(The third commit was moved to the beginning temporarily, to avoid having to rebase it every time the script is changed. It will be moved back to the end when the reviewing is done.)

I created pull request #9283 as a proof-of-concept of how I intend to do the semi-automated backporting to 1.1.1.

@paulidale @bernd-edlinger now that everything looks right, I intend to add a CHANGES entry and finalize the commit messages. I'll do that later today and let you know when I need reconfirmation. Also it would be nice if this pr would receive a second approval from an OMC member (@levitte?).

@kroeckx @t8m what is your opinion as platform maintainers about the idea to backport the renaming of the include guard prefixes to 1.1.1 (see proof-of-concept in #9283)? On one hand, it is an overdue and sensible change. On the other hand, users might rely on the precise names of the include guards (see discussion following https://github.com/openssl/openssl/pull/9274#issuecomment-507044929), so doing it in a bugfix release might be too risky.

see discussion following https://github.com/openssl/openssl/pull/9274#issuecomment-507044929

in particular also https://github.com/openssl/openssl/pull/9274#issuecomment-507047651

I do not really have a strong opinion either way. I would probably leave it out of 1.1.1 unless this would complicate backports of future patches.
I do not see any reported issues to be fixed by this so that's the reason why I'd rather chose not to put it in 1.1.1.

@paulidale @bernd-edlinger I cleaned up the commits, added a CHANGES entry and removed the auxiliary script. Please take a look at the changes and at the commit messages in their final form
724bee14f0 CHANGES: Add entry about new #include guard prefixes
59267ccf59 Use 'OPENSSL_' as common #include guard prefix
c6ecebe2ed util/mkerr.pl: use 'OPENSSL_' as include guard prefix of *err.h files
and reconfirm your approval.

Needed a rebase to solve a conflict in the changes file.

I wonder why some header files have guards at all.  All the _lcl and _locl header files are typically included from .c files only, i.e. not recursively, for example...

yes, that appeared to me as well.

I'm not pushing anything today. It's impossible to do these changes properly on my little notebook display.

Pushed some additional fixes addressing @bernd-edlinger's comments (listed bottom-up)

The fixup! ... commits just contain trival search&replace changes
The squash! ... commits contain some additional information in the commit message

Note: the following two commits will not be squashed into one, in order not to break git's automatic rename detection:
commit 470c37f9d3dd2ef73aee3a6138e0303c4c9c1442
Author: Dr. Matthias St. Pierre<EMAIL_ADDRESS>Date:   Thu Jul 4 13:40:36 2019 +0200

    add <openssl/ossl_typ.h> compatibility header

commit feb2fd59642085726f9198de07f8d661f3c6163d
Author: Dr. Matthias St. Pierre<EMAIL_ADDRESS>Date:   Thu Jul 4 13:00:12 2019 +0200

    rename <openssl/ossl_typ.h> to <openssl/types.h>

Pull request  #9274 has grown too large now to be backported. Apart from that, it remained unclear whether changing the names of the #incude header guards in a stable release could be safely done without breaking things.
That's why I just closed pull request #9283.

I feel bad for poor @mspncp for "stepping in it" with this PR. :)  Maybe something like this would help, eventually script it to find mismatches:
; git ls-files | fgrep .h | xargs grep -m1 ifndef

Ok @bernd-edlinger, just give me another round to look at all include guards once more. Using git grep will be faster than searching manually through the change sets, and less work for you, too. I'll let you know when I'm through and I'm sure you still will find enough nits and errors for me to fix.
@richsalz thanks for offering you help. No need to worry, I'm not desperate yet ;-).

Thanks @mspncp and apologies for adding so many comments,
I really had no idea how this would evolve...
All my comments are only suggestions, if you see a way
to get things consistent one way or the other that is okay for me as well.

... apologies for adding so many comments

No problem, really. On the contrary: your comments encouraged me to do it properly and not stop half way. So let's pause briefly for a general thought about naming rules for include guards:
I intend to achieve exact correspondence w.r.t filenames, but not strict correspondence w.r.t relative paths, with the important exception that the relative path must match for all public header files <openssl/filename.h>. Matching relative paths strictly for all header files is just too meticulous IMHO.
So the intended naming scheme is roughly as follows:

#include <openssl/filename.h> <-> #define OPENSSL_FILENAME_H
#include "internal/filename.h" <-> #define OPENSSL_INTERNAL_FILENAME_H
#include "filename_lcl.h" <-> #define OPENSSL_FILENAME_LCL_H

Would that be ok for you? (Of course this question not only goes to @bernd-edlinger but to all other @openssl/committers, too).

One more question to all: some of the internal include files do not really require include guards, because they are only included by modules and not by other include files. Should I remove those superfluous include guards or should I leave them in for safety reasons)?

And last but not least:  having two different suffixes _locl.h and _lcl.h is inconsistent, too.
So here is a vote for the @openssl/committers:  which suffix do you prefer?

If you prefer the _lcl.h suffix, please add your 'thumb up' here

filename_lcl.h

If you prefer the _locl.h suffix, please add your 'thumb up' here instead

filename_locl.h

which one is more common today?

Hang on, I'll check it out...

msp@msp-nbw10:~/src/openssl$ find -name '*_locl.h' | wc -l
30
msp@msp-nbw10:~/src/openssl$ find -name '*_lcl.h' | wc -l
19

What would be more interesting: which suffix is older, which is newer :-)

I wouldn't mind to accept the vote from searching the source code. This would mean I'd go for _locl.h.

Hmm....
If we rename those local files, it would be good to do the rename on 1.1.1 as well,
since otherwise lots of PRs will fail to merge against 1.1.1.

Oh, git actually has an excellent file rename detection. In some cases, it will stop you and ask you to increase the renameLimit to a higher value. It even tells you how high it need to be.
I forgot what the defaults are, my limits are already relatively high:
git config merge.renameLimit
32768
git config diff.renameLimit
32768

(git tries to identify file renames along the path from one commit to the other commit via the merge-base. If the branching took place a long time ago this might take some time though.)

It might be better to discuss this on openssl-committers.

One more question to all: some of the internal include files do not really require include guards, because they are only included by modules and not by other include files. Should I remove those superfluous include guards or should I leave them in for safety reasons)?

I like the include guards - they are not difficult to add. The use of the headers can change over time.

The use of the headers can change over time.

Yes, I agree. I already had this in mind when I asked my question, but I didn't mention it because I wanted to add no bias to the question.

Superseded by #9333.


Handle HTML Blocks in new algorithm

This handles HTML Blocks Type 1 through 6. I'm leaving Type 7 aside for the moment.
Now passing 269/621 spec tests.

Indentation fixed. I'd like to defer HTML Block Type 7 for now, I'm focusing on the Container Blocks.

Thanks!