FIX: Emulatos > mGBA

This is a benchmark review for experiment review_of_100_reviews_20240409.
Run ID: review_of_100_reviews_20240409/benchmark_2024-04-10T10-33-49_v1-16-0-100-g20a786d41-dirty.
This pull request was cloned from https://github.com/jmcerrejon/PiKISS/pull/214. (Note: the URL is not a link to avoid triggering a notification on the original pull request.)

Experiment configuration
review_config:
  # User configuration for the review
  # - benchmark - use the user config from the benchmark reviews
  # - <value> - use the value directly
  user_config:
    enable_ai_review: true
    enable_rule_comments: false

    enable_complexity_comments: benchmark
    enable_docstring_comments: benchmark
    enable_security_comments: benchmark
    enable_tests_comments: benchmark
    enable_comment_suggestions: benchmark

    enable_approvals: true

  ai_review_config:
    # The model responses to use for the experiment
    # - benchmark - use the model responses from the benchmark reviews
    # - llm - call the language model to generate responses
    model_responses:
      comments_model: benchmark
      comment_validation_model: benchmark
      comment_suggestion_model: benchmark
      complexity_model: benchmark
      docstrings_model: benchmark
      security_model: benchmark
      tests_model: benchmark

# The pull request dataset to run the experiment on
pull_request_dataset:
- https://github.com/mraniki/iamlistening/pull/294
- https://github.com/gdsfactory/gplugins/pull/373
- https://github.com/Anush008/fastembed-rs/pull/48
- https://github.com/mraniki/tt/pull/1435
- https://github.com/kloudlite/operator/pull/172
- https://github.com/mraniki/iamlistening/pull/293
- https://github.com/mraniki/iamlistening/pull/292
- https://github.com/mraniki/cefi/pull/434
- https://github.com/kloudlite/operator/pull/171
- https://github.com/usama-maxenius/image-editor/pull/62
- https://github.com/mraniki/tt/pull/1434
- https://github.com/mraniki/dxsp/pull/614
- https://github.com/albumentations-team/albumentations/pull/1637
- https://github.com/erxes/erxes/pull/5119
- https://github.com/mraniki/cefi/pull/433
- https://github.com/Quarticai/QuarticSDK/pull/358
- https://github.com/mraniki/cefi/pull/432
- https://github.com/tpaviot/pythonocc-core/pull/1311
- https://github.com/lightning-bot/Lightning/pull/144
- https://github.com/ignition-api/8.1/pull/265
- https://github.com/fairdataihub/fairdataihub.org/pull/616
- https://github.com/suttacentral/suttacentral/pull/3122
- https://github.com/jquagga/ttt/pull/30
- https://github.com/jquagga/ttt/pull/29
- https://github.com/Harrytimbog/Peer-Pal/pull/22
- https://github.com/bengosney/cerberus/pull/790
- https://github.com/Harrytimbog/Peer-Pal/pull/21
- https://github.com/mraniki/cefi/pull/431
- https://github.com/bengosney/cerberus/pull/789
- https://github.com/bengosney/cerberus/pull/788
- https://github.com/jmcerrejon/PiKISS/pull/214
- https://github.com/mraniki/dxsp/pull/613
- https://github.com/mraniki/cefi/pull/430
- https://github.com/mraniki/cefi/pull/429
- https://github.com/gdsfactory/gdsfactory/pull/2658
- https://github.com/Bilbottom/sql-learning-materials/pull/7
- https://github.com/mraniki/cefi/pull/428
- https://github.com/KonScanner/synthr-farming/pull/1
- https://github.com/rtk-rnjn/algorithms/pull/78
- https://github.com/malayilneil/lab04/pull/1
- https://github.com/nbhirud/system_update/pull/6
- https://github.com/mraniki/cefi/pull/427
- https://github.com/Kilo59/ruff-sync/pull/16
- https://github.com/jquagga/ttt/pull/27
- https://github.com/alexiusstrauss/CryptoTrendAnalyzer/pull/10
- https://github.com/jquagga/ttt/pull/25
- https://github.com/mraniki/tt/pull/1425
- https://github.com/albumentations-team/albumentations_stats/pull/1
- https://github.com/jquagga/ttt/pull/24
- https://github.com/jsugg/retry-on/pull/1
# - https://github.com/strawberry-graphql/strawberry/pull/3442
# - https://github.com/jquagga/ttt/pull/23
# - https://github.com/jquagga/ttt/pull/22
# - https://github.com/jquagga/ttt/pull/21
# - https://github.com/jquagga/ttt/pull/20
# - https://github.com/Kilo59/ruff-sync/pull/14
# - https://github.com/jquagga/ttt/pull/19
# - https://github.com/jquagga/ttt/pull/18
# - https://github.com/jquagga/ttt/pull/17
# - https://github.com/brendancsmith/diffbot-kg/pull/3
# - https://github.com/2lambda123/StenaIT-stenajs-webui/pull/1
# - https://github.com/jkool702/openwrt/pull/24
# - https://github.com/KevinNitroG/VNULIB-Downloader/pull/28
# - https://github.com/CPUT-DEVS/devpost-hackathon/pull/15
# - https://github.com/code-Harsh247/FRSS-project/pull/34
# - https://github.com/code-Harsh247/FRSS-project/pull/33
# - https://github.com/kurianbenoy/samam-ml-verification/pull/1
# - https://github.com/alexiusstrauss/CryptoTrendAnalyzer/pull/8
# - https://github.com/mraniki/dxsp/pull/612
# - https://github.com/alexiusstrauss/CryptoTrendAnalyzer/pull/7
# - https://github.com/alexiusstrauss/CryptoTrendAnalyzer/pull/6
# - https://github.com/neurodatascience/cohort_creator/pull/207
# - https://github.com/albumentations-team/albumentations-demo/pull/12
# - https://github.com/mraniki/cefi/pull/426
# - https://github.com/alexiusstrauss/CryptoTrendAnalyzer/pull/5
# - https://github.com/jkool702/openwrt/pull/23
# - https://github.com/jkool702/openwrt/pull/22
# - https://github.com/ynvtlmr/intergenerational-family-code/pull/108
# - https://github.com/PythonFreeCourse/lms/pull/390
# - https://github.com/jquagga/ttt/pull/16
# - https://github.com/PythonFreeCourse/lms/pull/389
# - https://github.com/PythonFreeCourse/lms/pull/389
# - https://github.com/PythonFreeCourse/lms/pull/389
# - https://github.com/jquagga/ttt/pull/13
# - https://github.com/Speccy-Rom/Leetcode_aka_speccy-rom/pull/293
# - https://github.com/Bilbottom/sql-learning-materials/pull/5
# - https://github.com/mraniki/cefi/pull/425
# - https://github.com/approvals/Approvals.NodeJS/pull/173
# - https://github.com/gdsfactory/gdsfactory/pull/2657
# - https://github.com/mraniki/tt/pull/1420
# - https://github.com/vibikerski/trackingtasks/pull/2
# - https://github.com/yaitoo/sqle/pull/30
# - https://github.com/jquagga/ttt/pull/12
# - https://github.com/Mesteriis/test-repo/pull/4
# - https://github.com/Mesteriis/test-repo/pull/3
# - https://github.com/Mesteriis/test-repo/pull/2
# - https://github.com/Mesteriis/test-repo/pull/1
# - https://github.com/letsdoitnowus/planium-backend/pull/34
# - https://github.com/code-Harsh247/FRSS-project/pull/32
# - https://github.com/letsdoitnowus/planium-backend/pull/33

# Questions to ask to label the review comments
review_comment_labels:
- label: correct
  question: Is this comment correct?
- label: helpful
  question: Is this comment helpful?
- label: comment-type
  question: Is the comment type correct?
- label: comment-area
  question: Is the comment area correct?

# Benchmark reviews generated by running
#   python -m scripts.experiment benchmark <experiment_name>
benchmark_reviews:
- dataset_pull_request: https://github.com/mraniki/iamlistening/pull/294
  review_pull_request: https://github.com/sourcery-ai-experiments/gplugins/pull/6
- dataset_pull_request: https://github.com/gdsfactory/gplugins/pull/373
  review_pull_request: https://github.com/sourcery-ai-experiments/fastembed-rs/pull/6
- dataset_pull_request: https://github.com/Anush008/fastembed-rs/pull/48
  review_pull_request: https://github.com/sourcery-ai-experiments/tt/pull/8
- dataset_pull_request: https://github.com/mraniki/tt/pull/1435
  review_pull_request: https://github.com/sourcery-ai-experiments/operator/pull/6
- dataset_pull_request: https://github.com/kloudlite/operator/pull/172
  review_pull_request: https://github.com/sourcery-ai-experiments/iamlistening/pull/17
- dataset_pull_request: https://github.com/mraniki/iamlistening/pull/293
  review_pull_request: https://github.com/sourcery-ai-experiments/iamlistening/pull/18
- dataset_pull_request: https://github.com/mraniki/iamlistening/pull/292
  review_pull_request: https://github.com/sourcery-ai-experiments/operator/pull/7
- dataset_pull_request: https://github.com/mraniki/cefi/pull/434
  review_pull_request: https://github.com/sourcery-ai-experiments/image-editor/pull/3
- dataset_pull_request: https://github.com/kloudlite/operator/pull/171
  review_pull_request: https://github.com/sourcery-ai-experiments/tt/pull/9
- dataset_pull_request: https://github.com/usama-maxenius/image-editor/pull/62
  review_pull_request: https://github.com/sourcery-ai-experiments/erxes/pull/29
- dataset_pull_request: https://github.com/mraniki/tt/pull/1434
  review_pull_request: https://github.com/sourcery-ai-experiments/cefi/pull/9
- dataset_pull_request: https://github.com/mraniki/dxsp/pull/614
  review_pull_request: https://github.com/sourcery-ai-experiments/QuarticSDK/pull/3
- dataset_pull_request: https://github.com/albumentations-team/albumentations/pull/1637
  review_pull_request: https://github.com/sourcery-ai-experiments/cefi/pull/10
- dataset_pull_request: https://github.com/erxes/erxes/pull/5119
  review_pull_request: https://github.com/sourcery-ai-experiments/pythonocc-core/pull/4
- dataset_pull_request: https://github.com/mraniki/cefi/pull/433
  review_pull_request: https://github.com/sourcery-ai-experiments/8.1/pull/4
- dataset_pull_request: https://github.com/Quarticai/QuarticSDK/pull/358
  review_pull_request: https://github.com/sourcery-ai-experiments/fairdataihub.org/pull/9
- dataset_pull_request: https://github.com/mraniki/cefi/pull/432
  review_pull_request: https://github.com/sourcery-ai-experiments/suttacentral/pull/3
- dataset_pull_request: https://github.com/tpaviot/pythonocc-core/pull/1311
  review_pull_request: https://github.com/sourcery-ai-experiments/ttt/pull/8
- dataset_pull_request: https://github.com/lightning-bot/Lightning/pull/144
  review_pull_request: https://github.com/sourcery-ai-experiments/cerberus/pull/2
- dataset_pull_request: https://github.com/ignition-api/8.1/pull/265
  review_pull_request: https://github.com/sourcery-ai-experiments/cefi/pull/11
- dataset_pull_request: https://github.com/fairdataihub/fairdataihub.org/pull/616
  review_pull_request: https://github.com/sourcery-ai-experiments/cerberus/pull/3
- dataset_pull_request: https://github.com/suttacentral/suttacentral/pull/3122
  review_pull_request: https://github.com/sourcery-ai-experiments/PiKISS/pull/2
- dataset_pull_request: https://github.com/jquagga/ttt/pull/30
  review_pull_request: https://github.com/sourcery-ai-experiments/dxsp/pull/6
- dataset_pull_request: https://github.com/jquagga/ttt/pull/29
  review_pull_request: https://github.com/sourcery-ai-experiments/cefi/pull/12
- dataset_pull_request: https://github.com/Harrytimbog/Peer-Pal/pull/22
  review_pull_request: https://github.com/sourcery-ai-experiments/Peer-Pal/pull/8

The same fix could be applied to the PR title (another easy win here).


Clean up docstrings

Some docstrings are out of date or insufficiently informative. We should clean these up.

Duplicate of #382


'StyleGANv2Generator is not in the component registry'

Hello, thanks for your excellent work!
When I tried to load the styleganv2 model using code form https://github.com/open-mmlab/mmediting/blob/23213c839ff2d1907a80d6ea29f13c32a24bb8ef/mmedit/models/builder.py#L34.
I got a KeyError: 'StyleGANv2Generator is not in the component registry'!
(I have installed  mmcv=1.3.14  and mmcv-full=1.3.14).
Can you tell me how to solve this problem please?

Hello, could you provide us with more details about your code?

If you want to load the model from your own code, remember to import the python submodule where the styleganv2 is located. It will register itself during import


Repo owner is "Null"

If possible, how do I fix that & why is that happening?

oh wait it will fix itself on the second commit after the addition of action


feature flag - add platform

What would you like to be added:
Why is this needed:

Acceptance Criteria: Users can "opt-in" on Beta feature(s)
Switch Network: Playground
Android:

[ ] Beta feature for 0.15.0: Loans
[ ] User to "opt-in" on Beta features via Settings > About
[ ] Beta feature visible only if Beta feature is available to "opt-in"

• If there's no Beta feature, then user won't see this link
• If there is Beta feature, user can click to opt-in

iOS:

[ ] Beta feature for 0.15.0: Loans
[ ] User to "opt-in" on Beta features via Settings > About
[ ] Beta feature visible only if Beta feature is available to "opt-in"

• If there's no Beta feature, then user won't see this link
• If there is Beta feature, user can click to opt-in

Refer to test case here: https://github.com/DeFiCh/wallet/issues/725#issuecomment-970005136


image: use golang-fedora as builder

Previously, the docker build used the golang image, which is based
on debian, and copied the dynamically linked binary into a fedora
layer. This change switches the build to use a custom golang-fedora
image as builder.
Fixes #1093
Fixes #1113
Please check if this works for other platforms than amd64.

@bpradipt @wainersm @stevenhorsman

Thanks @katexochen . I tried on amd64 without any issues.
@liudalibj @jtumber-ibm @Amulyam24 can you please try this PR on s390x and ppc64le and confirm it works fine.

@liudalibj @jtumber-ibm @Amulyam24 can you please try this PR on s390x and ppc64le and confirm it works fine.

Hi @katexochen @bpradipt. I successfully verified this on ppc64le. Thanks!

I got this working with s390x
My steps were:

Check out the source branch for the PR: git checkout -b docker-image-lib katexochen/fix/docker-image-lib
Enable buildx for multi-arch: docker buildx create --use
Login to quay.io: docker login quay.io -u stevenhorsman
Run the cloud-api-adaptor release build:  make ARCHES="linux/amd64,linux/s390x" registry="quay.io/stevenhorsman" RELEASE_BUILD=true image
I then used quay.io/stevenhorsman/cloud-api-adaptor:fae29b1484d190f64df5aa02cbf5481fef411c2e in my install kustomize and ran the e2e tests that seems to work fine

Run the cloud-api-adaptor release build:  make ARCHES="linux/amd64,linux/s390x" registry="quay.io/stevenhorsman" RELEASE_BUILD=true image

I guess we need to check with RELEASE_BUILD=false, as the binary is otherwise not dynamically linked against libvirt again. Sorry for not mentioning that in the PR description.

We tend to use quay.io/confidential-containers and have the secrets for this set-up in the repo already, so I'd probably vote for that unless we want to migrate everything over to ghcr?

I'm a fan of moving everything to GitHub, it will make the future administration easier and the whole project more transparent. But I'm not sure if others think the same and I understand that permissions are a struggle.
We can push it to quay for now and if we want to move to ghcr we can do it in another PR. What should be the name of the image?

I'm a fan of moving everything to GitHub, it will make the future administration easier and the whole project more transparent. But I'm not sure if others think the same and I understand that permissions are a struggle.

We can migrate to ghcr in a subsequent PR. Having all artefacts in one place will most likely improve the release and maintenance process.

We can push it to quay for now and if we want to move to ghcr we can do it in another PR. What should be the name of the image?

Feel free to suggest something :-) or we can leave it as golang-fedora

I'm a fan of moving everything to GitHub, it will make the future administration easier and the whole project more transparent. But I'm not sure if others think the same and I understand that permissions are a struggle.

I'm definitely sympathetic to this, but want to have a unifed approach/strategy rather than fragmentation

We can push it to quay for now and if we want to move to ghcr we can do it in another PR. What should be the name of the image?

quay.io/confidential-containers/operator:golang-fedora:36 seems fine to me

quay.io/confidential-containers/operator:golang-fedora:36 seems fine to me

You meant quay.io/confidential-containers/cloud-api-adaptor:golang-fedora:36, right?

I made the registry login and credentials configurable, this way contributors can run the job on their forks if they want. The defaults are the valid input for running the job in this repo and pushing to quay.

Thanks for the fix @katexochen ! Let me test it on my local x86_64 machine before merge, please.

I'm a fan of moving everything to GitHub, it will make the future administration easier and the whole project more transparent. But I'm not sure if others think the same and I understand that permissions are a struggle.

I'm definitely sympathetic to this, but want to have a unifed approach/strategy rather than fragmentation

1+. I suggest to move to Github registry (when and if) all images together.

We can push it to quay for now and if we want to move to ghcr we can do it in another PR. What should be the name of the image?

quay.io/confidential-containers/operator:golang-fedora:36 seems fine to me

I've added the requested changes. Adding a push trigger required some bash, as it is not possible to set inputs. In addition, Fedora an Go version are now parsed from the dockerfile if not otherwise defined, and the Go version is included in the tag.

Nice one, this is looking good to me once the fixups are done :)

I built and push the builder and cloud-api-adaptor images as:
$ docker buildx build --platform=linux/amd64 -f hack/Dockerfile.golang -t quay.io/wainersm/cloud-api-adaptor/golang-fedora:36-1.20-amd64 .
$ docker push quay.io/wainersm/cloud-api-adaptor/golang-fedora:36-1.20-amd64
$ sed -i s#quay.io/confidential-containers/cloud-api-adaptor/golang-fedora:1.20.5-36#quay.io/wainersm/cloud-api-adaptor/golang-fedora:36-1.20-amd64# Dockerfile
$ make ARCHES="linux/amd64" registry="quay.io/wainersm/cloud-api-adaptor" RELEASE_BUILD=false image

Changed the overlay file:
$ cd install/overlays/libvirt/
$ ../../.././kustomize edit set image cloud-api-adaptor=quay.io/wainersm/cloud-api-adaptor:dev-cca53f961f11ecace745b6132aef51910abbb68e-dirty
$ cd -

Running as expected:
$ kubectl logs pod/cloud-api-adaptor-daemonset-v55gj -n confidential-containers-system
+ exec cloud-api-adaptor libvirt -uri 'qemu+ssh://wmoschet@<IP_ADDRESS>/system?no_verify=1' -data-dir /opt/data-dir -pods-dir /run/peerpod/pods -network-name default -pool-name default -socket /run/peerpod/hypervisor.sock
cloud-api-adaptor version v0.6.0-dev
  commit: cca53f961f11ecace745b6132aef51910abbb68e-dirty
  go: go1.20.5
cloud-api-adaptor: starting Cloud API Adaptor daemon for "libvirt"
2023/06/27 22:25:03 [adaptor/cloud/libvirt] libvirt config: &libvirt.Config{URI:"qemu+ssh://wmoschet@<IP_ADDRESS>/system?no_verify=1", PoolName:"default", NetworkName:"default", DataDir:"/opt/data-dir"}
2023/06/27 22:25:05 [adaptor] server config: &adaptor.ServerConfig{TLSConfig:(*tlsutil.TLSConfig)(0xc000544000), SocketPath:"/run/peerpod/hypervisor.sock", CriSocketPath:"", PauseImage:"", PodsDir:"/run/peerpod/pods", ForwarderPort:"15150", ProxyTimeout:300000000000}
2023/06/27 22:25:05 [util/k8sops] initialized PeerPodService
2023/06/27 22:25:05 [adaptor] server started

@katexochen just curious: will GH autosquash the commits marked with "fixup!"?

@katexochen just curious: will GH autosquash the commits marked with "fixup!"?

No, it won't. But I really would love them to implement it, I really love fixups. :smile:

quay.io/confidential-containers/operator:golang-fedora:36 seems fine to me

You meant quay.io/confidential-containers/cloud-api-adaptor:golang-fedora:36, right?

I suggest to use golang-fedora:<fedora version>-<golang as Major.Minor version> (e.g. golang-fedora:36-1.19) this way we can update golang version without bump the distro version and don't break older builds. Besides having the golang version on the name makes it more clear...well....the golang version used :)

Good suggestion ..  Suggesting a minor modification if it's acceptable
golang-fedora:<golangversion>-<fedoraversion> (the tag sequence aligns with the name sequence and easier to decipher )

Had the same thought @bpradipt , and already implemented it like this.

@snir911 last words before I click the "Rebase and merge" button? :)


EDU-553 Prepare new storage browser

Closes https://educandu.atlassian.net/browse/EDU-553
Sorry for the huge pull request. I started to modernize the server API and tried to keep it as tame as possible. There are more issues that should be fixed, but I created individual JIRA tickets for them.

Nice to finally see the tests page functionality with a bit of navigation and actual real files heart_eyes
One tiny thing I noticed, maybe it's easy to fix? The "Type" for folders is now "Unbekannt", but only on the tests page, it's fine in the legacy storge-browser:

Thanks for noticing. In the legacy browser it comes from the mime type helper which we do not use here anymore, I realized. But it was easy to fix.


Implement NotImplementedException for Organization Management

Purpose

Implement NotImplementedException.
Add error constant to be used when server error occurs while retrieving parent app id.

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/9656807926

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/9656807926
Status: success

Closing this PR since the changes done here are tracked with,

https://github.com/wso2/identity-organization-management-core/pull/141
https://github.com/wso2/identity-organization-management-core/pull/142


When using the hand tool, sometimes the secondary tool bar will go behind the document

Win7 64b ( tried using pdfjs 1.0.473 and 1.0.712 )
To reproduce I simply use the hand tool and scroll pages with it for a bit, and then click on the button to open the secondary menu.  Sometimes when I do this it gets stuck behind the document.  When this happens a page refresh is required to fix it.  This doesn't happen every time so reproducing it is somewhat awkward.  IE11 reproduces with a higher frequency, although I was also able to reproduce in FF32 as well:

Is this still an issue?

I can still reproduce using the STR from https://github.com/mozilla/pdf.js/issues/5452#issuecomment-60913444 in Chromium 80.0.3987.132. The menu goes behind the canvas, but doesn't completely disappear though.


Add a StackdriverConfiguration class and builder to create StackdriverStatsExporter

Fix https://github.com/census-instrumentation/opencensus-java/issues/872. Use a builder pattern to replace the old factory methods, since we now have many parameters when creating StackdriverStatsExporter.
The stats exporter README file needs to be updated after v0.11.0 release. Tracked in https://github.com/census-instrumentation/opencensus-java/issues/895.

Coverage increased (+0.006%) to 81.395% when pulling d5d90ccfca092772486197636e61178296f3fa55 on songy23:stackdriver-exporter-options into e2664fb9a41ea54394d4b111052ef2c3ab0d7b0c on census-instrumentation:master.

Codecov Report

Merging #896 into master will increase coverage by 0.01%.
The diff coverage is 76.47%.

@@             Coverage Diff              @@
##             master     #896      +/-   ##
============================================
+ Coverage      79.3%   79.31%   +0.01%
- Complexity      916      921       +5
============================================
  Files           157      158       +1
  Lines          4116     4128      +12
  Branches        387      388       +1
============================================
+ Hits           3264     3274      +10
- Misses          768      770       +2
  Partials         84       84

Impacted Files
Coverage Δ
Complexity Δ

...er/stats/stackdriver/StackdriverConfiguration.java
100% <100%> (ø)
2 <2> (?)

...er/stats/stackdriver/StackdriverStatsExporter.java
66.66% <71.42%> (+1.66%)
11 <5> (+3)
:arrow_up:

Continue to review full report at Codecov.

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

Coverage increased (+0.006%) to 81.395% when pulling 8131e68ae25e179e305bc0f53a8a680b0334c1da on songy23:stackdriver-exporter-options into e2664fb9a41ea54394d4b111052ef2c3ab0d7b0c on census-instrumentation:master.

Coverage increased (+0.006%) to 81.395% when pulling 3079791e2e769ab75c9670b5acff93ef224a54bf on songy23:stackdriver-exporter-options into e2664fb9a41ea54394d4b111052ef2c3ab0d7b0c on census-instrumentation:master.

Thanks!


[Bug]: Shopify: BC Doc No. attribute sent to Shopify even in cases of errors

Describe the issue
When a Shopify Order is imported and an error occurs after the CreateHeaderFromShopifyOrder finishes, then the order is order is reimported shortly thereafter, which currently clears the error message, making any consistent follow-up impossible. I don't know if the fact that the error message is cleared only happens in these cases or if there's a second issue where this also happens on new orders imported.
The cause is that in function CreateHeaderFromShopifyOrder there's an API call to shopify to add the BC Doc No. attribute.
This update triggers a webhook notification to BC, which reimports the same order.
Expected behavior
Update of attributes in Shopify shouldn't happen until the full document has been created and any errors have been accounted for.
I would move the following lines to a separate function
https://github.com/microsoft/ALAppExtensions/blob/18455700ada751a86886a8cefdb071bd4a76ce71/Apps/W1/Shopify/app/src/Order handling/Codeunits/ShpfyProcessOrder.Codeunit.al#L139C1-L143C7
This function should be called just before the Auto Release check.
Steps to reproduce
Prepare a case where a sales line will return an error on creation.

Create order in Shopify
Import orders to BC
Order is now marked with error message
Open order in Shopify admin
Confirm that order now has a BC Doc No.
Wait approx. 5 minutes
Shopify Order has now been updated in BC.

Additional context
No response
I will provide a fix for a bug

[X] I will provide a fix for a bug

Consulted @onbuyuka. Issue approved.


Merge pull request #1 from oktadeveloper/master

Keeping fork up to date with base
Problem Statement
Solution

Opened by accident


build with python3 binary uses wrong path to find Python.h (fix inside)

I spent few days fighting issue with building tensorflow where it was unable to find Python.h, and seen number of similar issues.
Python.h was installed as a part of python3-devel, but build system wasnt unable to find it.
Finally i figured out that in tensorflow/third_party/py/python_configure.bzl function _get_python_bin was looking for binary by name python, even once i did configure i told it to use /usr/bin/python3
so i did a workaround by changing python_bin_path=repository_ctx.which("python") to look for python3 instead.
but i guess configure should do that for me.
i had unsupported fedora28 but its not the only distro having both python and python3 binaries

@akorzh I tried building with python3 on Ubuntu 16.04 and the build finished correctly. I have to link /usr/bin/python3 to /usr/bin/python but other than that the build works fine. Could you list the detailed steps and environment (as was suggested in the pull request template) so that the issue could be reproduced?

problem is that python is a python 2.7 binary i dont want to use. python3 is a python 3.6 binary i want to use so when doing configure i answer /usr/bin/python3 is the one i want to use, but aforementioned .bzl function is still using python binary no matter what which leads to build fail

steps are easy : start with default fedora 27 or 28 installation where python is python2 binary and python3 is a python 3.6 binary. This issue is non-relevant to Ubuntu i guess then

Since Fedora is unsupported I will leave this as community support.

As this issue has invited community support, please remove the assignee. Otherwise, remove the community support label. Thank you.

As this issue has invited community support, please remove the assignee. Otherwise, remove the community support label. Thank you.

As this issue has invited community support, please remove the assignee. Otherwise, remove the community support label. Thank you.

Hi @akorzh ! Python 3.7 is minimum version now. Please check out instructions on build from source document from 2.8/2.9 version  and let us know . Thank you!


As a restaurant owner, I want to view which bookings clash and which are available

so that I can ensure restaurant will not be overbooked

addBooking command now checks the capacity before accepting bookings.


Failing OCR with black border and lower resolution

Originally I stumbled on this trying to use OCRmyPDF, but it seems this is a tesseract problem.
Environment
tesseract 4.1.1
Linux 5.4.123-1-MANJARO x86_64 GNU/Linux
Current Behaviour:
I am trying to OCR some scanned books. Using the original TIFF for OCR works (no extra tesseract options used).
As mentioned above, I do not want to OCR the original TIFF, but a PDF based on the scan TIFFs. On a lower resolution, the OCR fails:
Image > OCR
Removing the black border on the low res version with a white one, the OCR succeeds again:
Image > OCR
Expected Behaviour:
OCR on the low res version with black border should succeed.

Tesseract is OCR engine so you have to preprocess images by yourself. This requirement is know for a long time and there is no plan to change it.


[GHSA-9gp7-jvm2-r4mx] Moderate severity vulnerability that affects org.apache.struts:struts2-core

Updates

References
Source code location

Comments
Add source code link and patch links related to CVE-2017-7672.

Hi @sunSUNQ, this contribution is not accepted because none of the commits appear to be consistent with https://cwiki.apache.org/confluence/display/WW/S2-047 or https://issues.apache.org/jira/browse/WW-4834. Thank you for your interest in GHSA-9gp7-jvm2-r4mx!

Hi ! In the S2-047 https://cwiki.apache.org/confluence/display/WW/S2-047, UrlValidator can be improved to fix this vulnerability. In https://github.com/apache/struts/commit/9d47af6ffa355977b5acc713e6d1f25fac260a28 they fix this. So I think this commit is the fix commit.

Hi @sunSUNQ, similar to https://github.com/github/advisory-database/pull/3171, pardon me for not providing a clearer explanation when I initially rejected the commit.
https://cwiki.apache.org/confluence/display/WW/S2-047 says that Struts 2.5 - Struts <IP_ADDRESS> is vulnerable to CVE-2017-7672, and Struts 2.5.12 contains the patch.
https://github.com/apache/struts/commit/9d47af6ffa355977b5acc713e6d1f25fac260a28 is tagged STRUTS_2_5_13, so it cannot be the patch.
Additionally, according to https://mvnrepository.com/artifact/org.apache.struts/struts2-core, 2.5.12 was released on 06 July 2017, so any patch must have been committed on or before 06 July 2017.
https://github.com/apache/struts/commit/9d47af6ffa355977b5acc713e6d1f25fac260a28 was committed on 01 August 2017 and 2.5.13 was released on 23 August 2017. This is another factor that leads me to conclude
https://github.com/apache/struts/commit/9d47af6ffa355977b5acc713e6d1f25fac260a28 is part of 2.5.13, not 2.5.12, and therefore cannot be the patch.


Error with architecture i386

The doc suggest to use:
domain.machine_arch = "i386"

But leads to:
Error while creating domain: Error saving the server: Call to virDomainDefineXML failed: unsupported configuration: Unknown architecture i386

If I use i686 no errors, but the kernel-32 does not boot with a
backtrace and the kernel-64 does not boot and does not print anything.
Note that there is no qemu-system-i686 on my host. Only
qemu-system-x86_64 and qemu-system-i386 are present.
I used "ubuntu/trusty32" and "ubuntu/trusty64" virtualbox boxes
migrated with vagrant-migrate.
My goal is to get a 32 bit domain up and running. A workaround is
manually edit the conf and add:
<cpu mode='custom' match='exact'>
   <model fallback='allow'>kvm32</model>
</cpu>

Im not sure if this is also possible by using the cpu_mode. Setting it
(with nested true) gives:
Error while creating domain: Error saving the server: Call to virDomainDefineXML failed: unsupported configuration: Invalid mode attribute 'kvm32'

Hey,
The same issue happens if I want to set the arch to arm
domain.machine_arch = "arm"

produces
Error while creating domain: Error saving the server: Call to virDomainDefineXML failed: unsupported configuration: Unknown architecture arm

My use case is:
I have a working arm VM that is called 'by hand' with plain qemu and shell wrappers, and I would like to package it and run as a vagrant box

@Demonsthere  Code was added in 0.0.33 so make sure you are on that version.
That being said. "arm" is not a valid machine_arch. Try like this:
         domain.machine_type = 'virt'
         domain.machine_arch = 'armv7l'
         domain.cpu_mode = 'custom'
         domain.cpu_model = 'cortex-a15'
         domain.cpu_fallback = 'allow'

Tweak as needed.
@dancn  for 32bits, try:
    vb.machine_arch = 'i686'
    vb.cpu_mode = 'custom'
    vb.cpu_model = 'qemu32'
    vb.cpu_fallback = 'allow'
    vb.emulator_path = '/usr/bin/qemu-system-i386'


docs(colors): update gray 10 color on docs

Closes #1379    P.S. - the branch number does not match the PR because issue had to be transferred over.
Updated website docs to reflect Gray 10 $text-02 color update from Gray 80 - #393939 to Gray 70 - #525252 as coded here: https://github.com/carbon-design-system/carbon/pull/5867/files#diff-b3c4e528475647f2fd1278cac41fe964R59)
Updated website White Theme docs $text-02 color update from Gray 80 - #393939 to Gray 70 - #525252
Changelog
New

Gray 10 $text-02 color update to Gray 70 - #525252
White theme $text-02 color update to Gray 70 - #525252

Changed

Gray 10 $text-02
White theme $text-02

Removed

[ ] Gray 10 $text-02 color update from Gray 80 - #393939

[ ] White theme $text-02 color update from Gray 80 - #393939

Can we update the white theme as well? Should be the same values

Done!  :)
Do the other themes have different tokens? For Gray 90 & Gray 100?


remove 'thomasmckay' from OWNERS file

@robpblake @ciaranRoche please remove me from the OWNERS file, thanks!

@thomasmckay No problem, I'll do that now 😢


Save/rename chargers filter dialog buggy

The dialog is not high enough, so the cancel and ok buttons are not very well accessible

Thanks a lot!


[Bug Report] The Chrome form automatic fill does't work when using elementui's form component

Element UI version
2.4.5
OS/Browsers version
MacOS 10.13.6
Vue version
2.5.17
Reproduction Link
https://jsfiddle.net/mmx38qxw/4685/
Steps to reproduce
Open JSFiddle to input username and password, then tap enter.
What is Expected?
After I do the above operator in Chrome,  I open Chrome again username and password should be auto filled, but with elementui form input component, Chrome doesn't.
Something doesn't like Antd, when I try to implement the similar function using Antd form, the Chrome will auto fill the input fields and input will get yellow background color. I think this may be a elementui form data binding bug，which prevent Chrome default behavior
What is actually happening?
The Chrome auto fill doesn't work.

@LIPSong Chrome will only save the autocomplete information on submit. Clicking the submit button doesn't trigger the form submit event. https://stackoverflow.com/questions/19345879/input-autocomplete-on-does-not-work-with-chrome-is-it-a-bug

@ziyoung Senior！ "Please provide ID to your input variable" ,this helps! Thank you！What a beautiful trick！


Please release v1.1.5

Following the discussion in https://github.com/golang/go/issues/32527#issuecomment-500859320, it appears that https://github.com/kr/pty/commit/b6e1bdd4a4f88614e0c6e5e8089c7abed98aae17 is required in order to work with pty using Go tip.
Please can I therefore ask you to tag v1.1.5?
For now, I can use master.
But when go1.13beta1 is released, however, an official semver version will be more convenient for people whose setup will be broken.

Done


CD-28568 Fix issue where we are pushing job information onto "resque:…

…XXX:accepted" instead of just "resque:accepted"

[ ] @gnusosa please review

@johnny-lai let's add unit-tests around the monkey patch, thx

@johnny-lai looks good to me :+1:

test added

Here is the output of the test:
johnny_lai$ bundle exec rake
/usr/local/rvm/rubies/ruby-1.9.3-p551/bin/ruby -I"lib:test:lib" -I"/usr/local/rvm/gems/ruby-1.9.3-p551/gems/rake-10.4.2/lib" "/usr/local/rvm/gems/ruby-1.9.3-p551/gems/rake-10.4.2/lib/rake/rake_test_loader.rb" "test/airbrake_test.rb" "test/hoptoad_test.rb" "test/job_hooks_test.rb" "test/job_plugins_test.rb" "test/plugin_test.rb" "test/resque_failure_redis_test.rb" "test/resque_test.rb" "test/worker_test.rb"
/usr/local/bin/redis-server
Starting redis for testing at localhost:9736...
Run options: --seed 61772
Running tests:
EE..............................WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
...........WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
..WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
..........................WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.....WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
..WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
..WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
....WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.....WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
....WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
PID STAT
24113 S+
..WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.EWARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
...WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.WARNING: This way of doing signal handling is now deprecated. Please see http://hone.heroku.com/resque/2012/08/21/resque-signals.html for more info.
.....
Finished tests in 8.579268s, 14.9197 tests/s, 33.4527 assertions/s.

Error:
#Class:0x007fb63594b310#test_should_be_notified_of_an_error:
NoMethodError: undefined method expects' for Airbrake:Module /Users/johnny_lai/Coupa-Local/resque/test/airbrake_test.rb:19:in block (2 levels) in <top (required)>'

Error:
#Class:0x007fb63596cb00#test_should_be_notified_of_an_error:
NoMethodError: undefined method expects' for HoptoadNotifier:Module /Users/johnny_lai/Coupa-Local/resque/test/hoptoad_test.rb:18:in block (2 levels) in <top (required)>'

Error:
#Class:0x007fb6332abfe8#test_remove_failed_queue:
NoMethodError: undefined method []' for nil:NilClass /Users/johnny_lai/Coupa-Local/resque/test/worker_test.rb:466:in block (2 levels) in <top (required)>'

128 tests, 287 assertions, 0 failures, 3 errors, 0 skips
Killing test redis server...
rake aborted!
Command failed with status (3): [ruby -I"lib:test:lib" -I"/usr/local/rvm/gems/ruby-1.9.3-p551/gems/rake-10.4.2/lib" "/usr/local/rvm/gems/ruby-1.9.3-p551/gems/rake-10.4.2/lib/rake/rake_test_loader.rb" "test/airbrake_test.rb" "test/hoptoad_test.rb" "test/job_hooks_test.rb" "test/job_plugins_test.rb" "test/plugin_test.rb" "test/resque_failure_redis_test.rb" "test/resque_test.rb" "test/worker_test.rb" ]
/usr/local/rvm/gems/ruby-1.9.3-p551/bin/ruby_executable_hooks:15:in eval' /usr/local/rvm/gems/ruby-1.9.3-p551/bin/ruby_executable_hooks:15:in '
Tasks: TOP => default => test
(See full trace by running task with --trace)
Note that in order to get the pre-existing tests to run at all, I had to:

Remove test/resque-web_test.rb
Remove the "glueoutputbuf" option from test/redis-test.conf

:+1:


find_module is very slow

Describe the bug
I'm trying to write an Igniter task to generate some code. Adding new modules went pretty smooth, but as soon as I start to use find_module I'm finding that it basically hangs (CPU > 200%). The module I want to modify is only a few lines, though it is in a rather large project (120,000+ lines across 1,200 files). I tried a different module too, just in case it was somehow related to a test module, but that one also "hangs". By hangs, it takes 2-3 minutes to come back on an M1 Pro Mac -- but it does eventually return a result.
To Reproduce

A minimal set of resource definitions and calls that can reproduce the bug.
I suspect a minimal project won't reproduce the issue, if it is related to the size of the project being used in.

Expected behavior

A clear and concise description of what you expected to happen.

I expected it to take a second or two at most, given the module I specified is only 13 lines long.
** Runtime

Elixir version  1.17.3
Erlang version  27.1.2
OS macOS 15.1
Igniter version ~> 0.3.76
any related extension versions

Additional context

Add any other context about the problem here.

Wow, I knew it was in need of optimization, but would not have expected that kind of time. There is an immediate and easy optimization that we can do, but it's not guaranteed to always work, meaning it could have to fallback to this case in rare circumstances. I will look into this.

Actually, my solution only works when looking for modules that actually exist. So the whole thing needs to be optimized. I think we'll have to keep a cache of module definitions by file whenever we parse or modify a file, and annotate when the cache is "complete".

Is it looking through every Elixir file (1198 Elixir files in lib/ + 734 Elixir files in test/) to find the module?
What if I could specify the file/path that I want to modify?
Since I'm working on a project (not a library), there are very specific modules I want to change. For example, I used create_module to create a new ExMachina Factory file, and I want to use find_and_update_module to add a use NewFactoryModule line to the main test/support/factory.ex module.

Oh, you can use Igniter.update_elixir_file if you know the elixir file you want to modify.

Much faster. Thanks!
I'll use that for now, but leave this issue open, since find_module still can be very slow.

I've made an improvement in main that should make the "happy path" effectively instant. However, as you said, if the place where we guess that the module is turns out to be wrong, then we will have to search across potentially all modules. The real problem is the parsing of all elixir files to find the module. This is a solvable problem. When an Igniter is created, it can first capture all currently existing modules and their file paths. Then, whenever a file in the igniter is modified, it can modify its cache based on any modules that were removed or added. This should mean that we never have to parse all files to find a module, only parse one new file (if we haven't yet) or we will already have the file in question.

It's pretty fast now with 0.4.0 -- happy to close this if you like?


ui / testnet merge

Testnet merge had already been completed with a different PR.

Testnet merge had already been completed with a different PR.


Support to continuous joints and transmission

Hi,
I'm not sure if pinocchio supports the following features from the urdf:

continuous joint type.I tried some robots with 'continuous' joint types in their urdf and it seems that pinocchio can not recognize those joints properly.
transmission, or in other words, armature. The motor will create a resistance force = armature * acceleration. As a result, we have to figure out a way to add this number to the diagonal entries of the inertia matrix when we compute forward or inverse dynamics. I'm not sure if pinocchio can handle this feature or if there are already some similar functions that deal with this.

I'm glad to provide more information. Thanks!

As far as I can tell continuous joints are handled all right? For instance the Mini Cheetah description all joints are continuous:
    <joint name="RR_upper_leg_2_hip_motor_joint" type="continuous">
    <axis xyz="1 0 0"/>
    <parent link="RR_hip_motor"/>
    <child link="RR_upper_leg"/>
    <origin rpy="0 0 0" xyz="-0.053565 0 0"/>
    <limit effort="100" velocity="100"/>
    <joint_properties damping=".0" friction=".0"/>
  </joint>

And they are properly loaded as unbounded revolute joints by Pinocchio:
In [1]: from robot_descriptions.loaders.pinocchio import load_robot_description

In [2]: mini_cheetah = load_robot_description("mini_cheetah_description")

In [3]: mini_cheetah.model.joints.tolist()
Out[3]:
[JointModelRX
   index:<PHONE_NUMBER>3709551615
   index q: -1
   index v: -1
   nq: 1
   nv: 1,
 JointModelRUBX
   index: 1
   index q: 0
   index v: 0
   nq: 2
   nv: 1,
 JointModelRevoluteUnboundedUnaligned
   index: 2
   index q: 2
   index v: 1
   nq: 2
   nv: 1,
 JointModelRevoluteUnboundedUnaligned
   index: 3
   index q: 4
   index v: 2
   nq: 2
   nv: 1,
 JointModelRUBX
   index: 4
   index q: 6
   index v: 3
   nq: 2
   nv: 1,
 JointModelRevoluteUnboundedUnaligned
   index: 5
   index q: 8
   index v: 4
   nq: 2
   nv: 1,
...

Re. armature, have you checked existing issues? I just did a quick search on "armature" in existing issues, I see e.g. this point on why you don't need to add diagonal entries to the inertia matrix in computing $M(q)^{-1}$. There is also this issue and this one where new contributions are welcome.

The armature and other transmission data will be fully handled in Pinocchio 3x. In the meantime, I would recommend taking them into account manually.


Kismatic Inspector should use the internal IP

Currently the inspector checks if ports are accessible on the public interface, this is not needed as all cluster communication is done via the internal interface (TODO verify this statement is correct)
➜  out git:(master) ./kismatic install validate

Validating==========================================================================
Reading installation plan file "kismatic-cluster.yaml"                          [OK]
Validating installation plan file                                               [OK]
1/3....  Configure Cluster Prerequisites                                        [OK]
2/3....  Update Hosts File                                                      [OK]
3/3....  Run Cluster Pre-Flight Checks
- Running task: run pre-flight checks using Kismatic Inspector
  node1                                                                         [ERROR]
---- STDERR ----
Error: error running inspector against remote node: error posting request to server: Post http://<IP_ADDRESS>:8888/execute: dial tcp <IP_ADDRESS>:8888: getsockopt: operation timed out
---------------
- Running task: run pre-flight checks using Kismatic Inspector
  node2                                                                         [ERROR]
---- STDERR ----
Error: error running inspector against remote node: error posting request to server: Post http://<IP_ADDRESS>:8888/execute: dial tcp <IP_ADDRESS>:8888: getsockopt: operation timed out
---------------
➜  out git:(master) ./kismatic install validate

Validating==========================================================================
Reading installation plan file "kismatic-cluster.yaml"                          [OK]
Validating installation plan file                                               [ERROR]
- Worker nodes: Node #1: Invalid IP provided
validation error prevents installation from proceeding
➜  out git:(master) ./kismatic install validate

Validating==========================================================================
Reading installation plan file "kismatic-cluster.yaml"                          [OK]
Validating installation plan file                                               [OK]
1/3....  Configure Cluster Prerequisites                                        [OK]
2/3....  Update Hosts File                                                      [OK]
3/3....  Run Cluster Pre-Flight Checks
- Running task: run pre-flight checks using Kismatic Inspector
  node1                                                                         [ERROR]
---- STDERR ----
Error: error running inspector against remote node: error posting request to server: Post http://<IP_ADDRESS>:8888/execute: dial tcp <IP_ADDRESS>:8888: getsockopt: operation timed out
---------------
- Running task: run pre-flight checks using Kismatic Inspector
  node2                                                                         [ERROR]
---- STDERR ----
Error: error running inspector against remote node: error posting request to server: Post http://<IP_ADDRESS>:8888/execute: dial tcp <IP_ADDRESS>:8888: i/o timeout
---------------
➜  out git:(master) ./kismatic install validate
# After opening port 8888 on the public interface
Validating==========================================================================
Reading installation plan file "kismatic-cluster.yaml"                          [OK]
Validating installation plan file                                               [OK]
1/3....  Configure Cluster Prerequisites                                        [OK]
2/3....  Update Hosts File                                                      [OK]
3/3....  Run Cluster Pre-Flight Checks
=> The following checks failed on "node1":
   - Port Accessible: 2379: Port 2379 on host "<IP_ADDRESS>" is unreachable. Error was: dial tcp <IP_ADDRESS>:2379: i/o timeout
   - Port Accessible: 6666: Port 6666 on host "<IP_ADDRESS>" is unreachable. Error was: dial tcp <IP_ADDRESS>:6666: i/o timeout
   - Port Accessible: 2380: Port 2380 on host "<IP_ADDRESS>" is unreachable. Error was: dial tcp <IP_ADDRESS>:2380: i/o timeout
   - Port Accessible: 6660: Port 6660 on host "<IP_ADDRESS>" is unreachable. Error was: dial tcp <IP_ADDRESS>:6660: i/o timeout
   - Port Accessible: 6443: Port 6443 on host "<IP_ADDRESS>" is unreachable. Error was: dial tcp <IP_ADDRESS>:6443: i/o timeout
   - Port Accessible: 8443: Port 8443 on host "<IP_ADDRESS>" is unreachable. Error was: dial tcp <IP_ADDRESS>:8443: i/o timeout

error running preflight: error running playbook: error running ansible: exit status 2
➜  out git:(master) ./kismatic install validate
# After opening all ports on the public interface
Validating==========================================================================
Reading installation plan file "kismatic-cluster.yaml"                          [OK]
Validating installation plan file                                               [OK]
1/3....  Configure Cluster Prerequisites                                        [OK]
2/3....  Update Hosts File                                                      [OK]
3/3....  Run Cluster Pre-Flight Checks                                          [OK]

Currently, the inspector runs from the install node. This is the reason why we don't use the internal IP.

I can see this working well with #159 where we perform the connectivity tests and these port checks from within the cluster.

I have been looking into #159 this morning. Going to do it through ansible to see what it looks like.


More DMC Analysis Code

This adds to the existing analysis suite by

Adding a monty_capabilities_analysisfolder/package to hold common path settings and utilities.
Adding a couple of scripts for 1-LM analysis (including multimodal-transfer) and multi-LM analysis.
Updates to README.md about the directory structure and python path settings.

Thanks! Love how your code is so well documented and beautiful. 🥹

Thank you!!


[doc] Fix clear spelling mistakes and change docstrings and comments to 'YOLO 1.1' instead of the non-existing 'YOLO ZIP 1.0'

Fixes clear typos and mistakes in the docs.
Also:
In several comments or docstrings, the data format 'YOLO ZIP 1.0' is mentioned as an example. However, using this identifier will result in an error like "Unknown format specified for the request", since the format is not supported anymore, or maybe it is just referenced by a different name now.
This PR changes those comments in favor of 'YOLO 1.1' as an example format.
License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.

The latest commits fix spelling errors and typos in the docs.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 73.92%. Comparing base (9581b07) to head (fe16be0).
Report is 36 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #8754      +/-   ##
===========================================
- Coverage    74.06%   73.92%   -0.14%
===========================================
  Files          409      409
  Lines        43784    43957     +173
  Branches      3984     3986       +2
===========================================
+ Hits         32428    32497      +69
- Misses       11356    11460     +104

Components
Coverage Δ

cvat-ui
78.35% <ø> (-0.03%)
:arrow_down:

cvat-server
70.13% <ø> (-0.21%)
:arrow_down:

Thank you for contributing into the project!


Cables/Pipes/Tubes Breaking

Something odd has been happening with cables, transporter pipes, tubes..etc and the auto-eject for machines.
I noticed some machines not being powered, and then after investigation, I noticed power wasn't flowing through the cables. The only way to fix it was to break the entire line (from one end to the other) and completely place the cables back down.
Then a similar thing was happening with transport pipes...I have a tier 2 ore processing setup, for example, and the daisy-chain of machines from Purification Chamber to Smelter was not running smoothly. Items were not being auto-ejected (like I have set) and not traveling through the pipes until I broke them all and replaced them, and even right now I have some buggy issues with these transport pipes that I cannot figure out how to fix them. As of right now, I have items being caught in the Crusher machine and not being auto-ejcted to the pipe behind it, except for a single dust after each crush, but not every time...if that makes sense?
Current Mekanism version is 8.1.5

++ same issue.  Seems to be tied to chunk loading. I dropped down a chunk loader and set it to cover my entire base and the problem has gone away. Might give that a shot as a workaround.

I'll drop a chunk loader down I guess. I was going to try updating from 8.1.5 to 8.1.7 to see if that helped. What version are you running?

8.1.5 as well. I need to get my server owner to update to see if that fixes it. I saw some notes about pipe fixes in the commit log but I'm not sure how to tell if they were put into 8.1.6 or 8.1.7...

Ah okay. Well, I'm testing 8.1.7 later and I'll let you know if it happens again.

On Aug 7, 2015, at 16:56, Utildayael<EMAIL_ADDRESS>wrote:
8.1.5 as well. I need to get my server owner to update to see if that fixes it. I saw some notes about pipe fixes in the commit log but I'm not sure how to tell if they were put into 8.1.6 or 8.1.7...
—
Reply to this email directly or view it on GitHub.

I find that dying causes all power cables to fail, having to break them and replace them to get them working.

Update to 8.1.7.

Re-open this. I am on 8.1.7 and the issue is still occurring...except breaking and replacing the pipes doesn't fix it. I can't get it to pull out or push into any machines. There's no reason for it to be stuck, but it it. Sometimes it will send one item down every 5 seconds or so...not the constant normal flow...and this causes bottle-necks in my processing chain.

It seems some machines auto-eject into the transport pipes normally, like the enrichment chamber, but others such as the Purification Chamber and Crusher, do not.

Really? I have a few autocrafting builds that will use crushers so I'll test later. (Although i mainly use elite factories)

Okay let me know how it goes


dep ensure: Incorrect version range syntax interpretation for 0.x versions

Given a sub 1.y version, e.g. 0.8.z, ^ (caret) currently expands to:
dep ensure<EMAIL_ADDRESS>=> "version": ">=0.8.0, <1.0.0"`

But should expand to:
dep ensure<EMAIL_ADDRESS>=> "version": ">=0.8.0, <0.9.0"`

I ran across this independently today, while hammering out some kinks in our semver lib. There's a PR open that will fix this: Masterminds/semver#53

Thanks for filing the report! Sorry it took me a while to respond.
I actually ran across this independently today, while hammering out some kinks in our semver lib. There's a PR open that, once its merged and we merge in from upstream, will fix this: Masterminds/semver#53

Nice! Thanks for the constant hard work.

This is fixed now, with the latest semver update.


Exit-PSSession error on Windows 10 to Linux remote session

Steps to reproduce
Windows 10 desktop and Linux redhat both installed with Powershell 7.0
Linux server installed with psl-omi-provider and omi from below urls
https://github.com/PowerShell/psl-omi-provider
https://github.com/Microsoft/omi
On desktop, enter-pssession from windows desktop to remote to linux works by following the similar instruction as shown in the psl-omi-provider link.
$so = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
Enter-PSSession -ComputerName  -Credential  -UseSSL -SessionOption $so -Authentication Basic
However, exit-pssession returns error and number of omiagent process on linux server kept increasing after multiple remote attempts (possibly due to incomplete exit-pssession)
Expected behavior
Exit-PSSession should close the ps session successfully (and its omiagent process), but it throws error.
Actual behavior
Exit-PSSession returns the following error.
Closing the remote server shell instance failed with the following error message : <SOAP-ENV:Fault xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope">SOAP-ENV:CodeSOAP-ENV:ValueSOAP-ENV:Receiver</SOAP-ENV:Value>SOAP-ENV:SubcodeSOAP-ENV:Valuewsman:InternalError</SOAP-ENV:Value></SOAP-ENV:Subcode></SOAP-ENV:Code>SOAP-ENV:Reason<SOAP-ENV:Text xml:lang="en-US"/></SOAP-ENV:Reason></SOAP-ENV:Fault> For more information, see the about_Remote_Troubleshooting Help topic.
On linux server, the number of omiagent process kept increasing with after multiple remote attempts and exit-pssession failures (possibly due to incomplete exit-pssession).
Environment data
Desktop
Name                           Value

PSVersion                      7.0.0
PSEdition                      Core
GitCommitId                    7.0.0
OS                             Microsoft Windows 10.0.17134
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0
Linux server
Name                           Value

PSVersion                      7.0.0
PSEdition                      Core
GitCommitId                    7.0.0
OS                             Linux 3.10.0-1127.el7.x86_64 #1 SMP Tue Feb 18 16:39:12 EST 2020
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0
Installed omi and omi-psrp-server packages
Name        : omi
Arch        : x86_64
Version     : 1.6.4
Release     : 1
Size        : 4.4 M
Repo        : installed
Summary     : Open Management Infrastructure
License     : MIT
Description : omi server
Name        : omi-psrp-server
Arch        : x86_64
Version     : 1.4.1
Release     : 28
Size        : 872 k
Repo        : installed
Summary     : PowerShell Remoting Protocol
License     : MIT
Description : PowerShell Remoting Protocol provider

OMI is deprecated. https://github.com/PowerShell/PowerShell/issues/8233
You should use SSH for remoting from Unix-s..

This issue was PowerShell remote session from Windows 10 to Linux (not Linux to Windows). But thanks for the clarification on OMI deprecation, wasn't aware of that announcement.

Really WinRM can works on Linux.
Your issue is that you use UseSSL with New-PSSessionOption but New-PSSessionOption is based on WinRM and is not compatible with SSH.

@PaulHigin Is the issue the same as https://github.com/PowerShell/PowerShell/issues/12654#issuecomment-628727230 ?


How to specify Caddy version when building it from source with plugins

I followed the instructions from the README today to build Caddy from source with plugins, but when I ran go build, Go pulled the source code from the latest release tag (v0.11.5) instead of the most recent pre-release tag (v1.0.0-beta1).
Is it possible to specify either a pre-release tag or a specific commit when building Caddy from source with plugins?
@mholt Your input would be appreciated.

Yes, see the README for instructions on how to build from source at a specific release, see also the Go module documentation and the discussion in https://github.com/mholt/caddy/issues/2560.

@mholt Hmm, it's not clear to me how to go about it from the README. What would I have to change in this Go file to specify which prerelease tag or commit to use before initializing it as a Go module and building it with go build?
package main

import (
	"github.com/mholt/caddy/caddy/caddymain"

       _ "github.com/pyed/ipfilter"
       _ "github.com/hacdias/caddy-webdav"
       _ "github.com/epicagency/caddy-expires"
       _ "github.com/caddyserver/dnsproviders/gandiv5"
)

func main() {
	caddymain.EnableTelemetry = false
	caddymain.Run()
}

@mholt Thanks, I figured it out now.

@whalehub What was your solution?

@mholt When I ran build.go, Go automatically populated the go.mod file with the required dependencies. Among them was github.com/mholt/caddy with the version tag v0.11.5. After consulting Go's documentation, I found out that you can specify a commit for a required dependency by replacing the versioned tag with a prerelease tag or the commit's hash (e.g. 917d9bc9daf9740c83b2ee686f21f4c54cdf21ad). Go will automatically convert the latter into a so-called pseudo-version (e.g. v1.0.0-beta1.0.20190420181127-917d9bc9daf9) when you run go build again.
I was able to build Caddy from the latest commit with plugins this way without a problem.
root@debian:~/.caddy/build# ./caddy -version
Caddy v1.0.0-beta1.0.20190420181127-917d9bc9daf9 (h1:Qy+MKd5e5M3p2x21Bm/wxzpTR7T4tE/xq/n9AV3nM88=)

@mholt When I ran build.go, Go automatically populated the go.mod file with the required dependencies. Among them was github.com/mholt/caddy with the version tag v0.11.5. After consulting Go's documentation, I found out that you can specify a prerelease tag or a commit for a required dependency by replacing the versioned tag with the respective prerelease tag or the commit's hash (e.g. 917d9bc9daf9740c83b2ee686f21f4c54cdf21ad). Go will automatically convert the latter into a so-called pseudo-version (e.g. v1.0.0-beta1.0.20190420181127-917d9bc9daf9) when you run go build again.
I was able to build Caddy from the latest commit with plugins this way without a problem.
root@debian:~/.caddy/build# ./caddy -version
Caddy v1.0.0-beta1.0.20190420181127-917d9bc9daf9 (h1:Qy+MKd5e5M3p2x21Bm/wxzpTR7T4tE/xq/n9AV3nM88=)

Thanks. But, we just removed build.go... it is no longer needed.

@mholt That was a typo. I meant to say "When I ran go build [...]".

Are the instructions in our readme wrong then? We specifically mention a beta version because Go modules ignores prereleases otherwise.

@mholt As far as I can tell, the instructions for building Caddy without plugins are correct. It's the instructions for building it with plugins that require an overhaul. If you want, I can type something up to fix them.

What needs to be changed? They worked for me last night.

What needs to be changed? They worked for me last night.

Run go get<EMAIL_ADDRESS>before go build. This will not be necessary after the release of the v1.0.0 version tag

Furthermore, I propose another change.

go mod init mycaddy (the name doesn't really matter).

This is not really true, the module name equals the name of the binary i.e if it is called mycaddy the binary will be called mycaddy

🤔 Huh, I thought the name of the binary was based on the folder name.

But yes, a lot of pain will go away after a stable release. It's a chicken-and-egg problem. At this point I'll be tagging 1.0 just hoping it works. 😬

🤔 Huh, I thought the name of the binary was based on the folder name.

Not for me... Can anyone confirm this?


Codefix installer

Turns out this is not necessary on most .NET runtimes - I think it's only older ones that still use packages.config that require it.


Break long lines of std.format.internal.write.

Made package(std.format) global. See #7805 for the rationale.

Looks good. The docs tester seems to have a spurious failure. Maybe push the changes again to restart it.


Add HTTP/1.1 trailer test cases(master)

Purpose

Duplicate of https://github.com/ballerina-platform/ballerina-lang/pull/20820/files
Fixes #3751

Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[ ] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #20992 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #20992   +/-   ##
=======================================
  Coverage   14.59%   14.59%
=======================================
  Files          51       51
  Lines        1398     1398
  Branches      214      214
=======================================
  Hits          204      204
  Misses       1178     1178
  Partials       16       16

Continue to review full report at Codecov.

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


Firmware update with battery powered node

Battery powered node need some process for  firmware update.
Here is how firmware update works on battery powered node ( not 100% sure but seems how it works)
smartSleep() send heartbeat before going to sleep. Controller check firmware version when receive heartbeat signal from node then if there is new firmware, reset node.
Node should use smartSleep() instead Sleep().
ps. Sorry for poor English. English is my second language...
Thanks.

@ydkimnz User might need to send reboot command when the node wake-up. This issue will be addressed on https://github.com/mycontroller-org/mycontroller/issues/208

https://github.com/mycontroller-org/mycontroller/issues/208 addressed


lib: net_buf: Generates lots of warnings during Bluetooth initialization

Describe the bug
Several warnings are generated on the console during Bluetooth initialization with the message as follow:
<wrn> net_buf: Timeout discarded. No blocking in syswq.
I discovered this using the platform nrf52840dk/nrf52840 with peripheral_hr, even if the problem is not specific to this application.
Apparently this has been introduced by https://github.com/zephyrproject-rtos/zephyr/commit/88ee2bee393666ce661b47dae3b65bebdfda32d4
To Reproduce

west build -b nrf52840dk/nrf52840 samples/bluetooth/peripheral_hr
west flash

Expected behavior
Normally, I would expect no warning for a regular Bluetooth initialization.
Impact
Annoyance and feeling that something is not right.
Logs and console output
*** Booting Zephyr OS build v3.7.0-4797-g98e0e65069cf ***
[00:00:00.250,518] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.250,640] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.250,762] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.250,915] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.251,068] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.251,190] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.251,312] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.251,464] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.251,586] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.251,708] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.251,861] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.251,983] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.252,105] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.252,136] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.252,136] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 3.7 Build 99
[00:00:00.252,197] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.252,349] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.252,471] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.252,624] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.252,746] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.252,929] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.253,112] <inf> bt_hci_core: Identity: F4:EC:64:8F:85:C8 (random)
[00:00:00.253,143] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x0000, manufacturer 0x05f1
[00:00:00.253,173] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0xffff
Bluetooth initialized
Starting Legacy Advertising (connectable and scannable)
[00:00:00.253,295] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.253,448] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.253,601] <wrn> net_buf: Timeout discarded. No blocking in syswq
[00:00:00.253,845] <wrn> net_buf: Timeout discarded. No blocking in syswq
Advertising successfully started
Checking LED device...done.
Configuring GPIO pin...done.
Start blinking LED...

Environment:

OS: Windows
Toolchain: Zephyr SDK
Commit SHA: 98e0e65069cf62297c4d03e0ad5b543374f5b735
Version used: 3.7.99

CC: @JordanYates

More accurately this was introduced by #71697, and any such usage should have been cleaned up as part of that PR.

@JordanYates, I think the change of the message level from debug to warning, triggered all these messages on the console.

@JordanYates, I think the change of the message level from debug to warning, triggered all these messages on the console.

Yes, but it's the usage of blocking APIs on the system workqueue that is the problem, not the log level of the warning.

If the intention is to just let the application developer know that there is a problem in the usage of context, then can't we do Linux style printk_once? or WARN_ONCE , so, LOG_WRN_ONCE, this is a nice tradeoff b/w intimation of problem but not overwhelming console with logs? Of course, there is a caveat that this would only point out a single problematic caller, so, maybe we can log once per-thread?


Env problem

why you require openexr 3.2.1 in env.yml, and 1.3.9 in req.txt.
And you need matplotlib easydict opencv-python tensorboardx , to help using alphapose from a neet env.
Also I had a problem of
Traceback (most recent call last):
File "/home/admin188/AI/DiffusionLight/inpaint.py", line 358, in
main()
File "/home/admin188/AI/DiffusionLight/inpaint.py", line 340, in main
output_image = pipe.inpaint_iterative(**kwargs)
File "/home/admin188/AI/DiffusionLight/relighting/inpainter.py", line 328, in inpaint_iterative
ball_images = generate_balls(
File "/home/admin188/AI/DiffusionLight/relighting/inpainter.py", line 281, in generate_balls
output_image = self.pipeline(
File "/home/admin188/anaconda3/envs/fooocus/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
return func(*args, **kwargs)
File "/home/admin188/AI/DiffusionLight/relighting/pipeline_xl.py", line 307, in call
add_time_ids, add_neg_time_ids = self._get_add_time_ids(
File "/home/admin188/anaconda3/envs/fooocus/lib/python3.10/site-packages/diffusers/pipelines/controlnet/pipeline_controlnet_inpaint_sd_xl.py", line 959, in _get_add_time_ids
self.unet.config.addition_time_embed_dim * len(add_time_ids) + text_encoder_projection_dim
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'
I have no idea why and I reinstalled from start and fixed it.

I just realized that requirements.txt is set OpenEXR to 1.3.9, so I will update it to 3.2.1.
About the error, Are you able to run the example in the example folder?
python inpaint.py --dataset example --output_dir output

yes the error comes from running this and env problem is fine. I solved this by reinstalled env. I just want to make sure there's not any problem with plus an int and a NoneType.


Change edition to 2021.

Since the MSRV is 1.170 and there are no errors when doing so, you might as well change the edition to 2021 to get the most recent version that is supported.

Also, cargo fix --edition changes nothing.


RTCPeerConnection.getLocalStreams/getRemoteStreams are deprecated. Use RTCPeerConnection.getSenders/getReceivers instead.

I get the following error when running this library:
RTCPeerConnection.getLocalStreams/getRemoteStreams are deprecated. Use RTCPeerConnection.getSenders/getReceivers instead.
(Line 4015 in the non-minified file)
It doesn't seem to be a problem for now, as everything seems to work fine, but thought I might make someone aware of this. I'm not confident enough to change it myself, though I think it would be a simple case of changing the used methods, but I'm not sure so perhaps someone more familiar with WebRTC and/or RTCMultiConnection should take a look at it.

Currently only Firefox supports this feature. (getSenders)
We already have the implementation which is disabled currently.

https://github.com/muaz-khan/RTCMultiConnection/blob/master/dev/RTCPeerConnection.js#L115-L125

That's great! Already way ahead of me. So since it's a known thing, I'll close this issue.


Update docs for getResourceByPath

https://next-drupal.org/docs/reference#getresourcebypath
#87

Done. I've updated the docs. https://next-drupal.org/docs/reference#getresourcebypath


App Registrations invisible to users

There is some checkbox that says whether users can see an Enterprise App. This should not be ticked for scepman-api. Maybe for scepman-certmaster?

scepman-certmaster should get a Homepage URL and logo

Only adding the log is still open. Adding a Logo is difficult via az. It seems it can be uploaded only via the portal and then resides in some appreg-specific cloud storage.

The -hideApp parameter for RegisterAzureAdApp seems to be ignored. Review this.


The service has stopped working due to Figma website changes.

Notes from the maintainer:
Figma currently only requests local fonts on Windows and macOS. They also chose a different port for the service. (18412 -> 44950)
Please upgrade to version 0.3.2 for the port changes. However, we still need to override the browser's user-agent. There is nothing I can do about it.
The issue report on the Figma's official forum: https://forum.figma.com/t/requests-to-font-helper-on-linux-stopped-working/61389

Original bug report
Both the figma.agent.socket and figma.agent.service are enabled but fonts are not appearing on figma in any browser.
Command :
systemctl --user status --now figma-agent.socket

output :
● figma-agent.socket - Figma Agent for Linux
     Loaded: loaded (/home/shobhit/.local/share/systemd/user/figma-agent.socket; enabled; vendor pr>
     Active: active (running) since Fri 2024-01-12 22:10:01 IST; 9min ago
   Triggers: ● figma-agent.service
     Listen: [::]:18412 (Stream)
     CGroup<EMAIL_ADDRESS>
Jan 12 22:10:01 mint-Hp systemd[1448]: Listening on Figma Agent for Linux.

Command :
systemctl --user status --now figma-agent.service

output :
● figma-agent.service - Figma Agent for Linux
     Loaded: loaded (/home/shobhit/.local/share/systemd/user/figma-agent.service; enabled; vendor p>
     Active: active (running) since Fri 2024-01-12 22:10:42 IST; 9min ago
TriggeredBy: ● figma-agent.socket
   Main PID: 7487 (figma-agent)
      Tasks: 3 (limit: 4269)
     Memory: 7.0M
        CPU: 215ms
     CGroup<EMAIL_ADDRESS>             └─7487 /home/shobhit/.local/share/figma-agent/figma-agent

Jan 12 22:10:42 mint-Hp systemd[1448]: Starting Figma Agent for Linux...
Jan 12 22:10:42 mint-Hp systemd[1448]: Started Figma Agent for Linux.
Jan 12 22:10:42 mint-Hp figma-agent[7487]: [2024-01-12T16:40:42Z INFO  actix_server::builder] Start>
Jan 12 22:10:42 mint-Hp figma-agent[7487]: [2024-01-12T16:40:42Z INFO  actix_server::server] Actix >
Jan 12 22:13:58 mint-Hp figma-agent[7487]: [2024-01-12T16:43:58Z INFO  actix_web::middleware::logge>

Command :
systemctl --user is-enabled figma-agent.socket figma-agent.service

Output :
enabled
enabled

I discovered that Figma only queries the font agent if it is running on an officially supported operating system, i.e. Windows and macOS. Since there's no official client for Linux, it skips the HTTP request.  I also had to change the port in figma-agent.socket to 44950. After that my local fonts appeared.

Thanks! @m4theushw It worked for me as well.
I changed the browser agent to windows and set port ( ListenStream ) to 44950
nano .config/systemd/user/sockets.target.wants/figma-agent.socket

And it worked after restarting the socket and service.

Let me keep this issue open for tracking proposes.

Same issue for me as well. Changing port and user agent string worked. Oddly, changing it to Chrome-Macos as the user agent didn't work, Chrome-Windows as the user agent did though.

same problem with user agent browser. change to windows agent its work, the local fonts was appeared.

Figma Agent stopped working after Chrome update
I'm on Fedora and today (May 11th) I updated my Chrome to 124.0.6367.201, after that my local fonts stopped working.
It was tested on both the Flatpak and the RPM package. I know the problem is on Chrome's side since it works on Firefox. Reporting here in case someone also finds themselves with the problem.
Here is the user-agent:

The port:

My .fonts folder:

And the Figma missing fonts warning:


Update math to correct show user deposits with scaled balance token

update sdk to latest to fix deposit amount for lenders, fix formatting of withdrawl after duplicate from merge

@bbroeking please see comment for lend page


add: block arrival timestamps from monitoring at KIT

This adds the data from the three nodes of the Bitcoin Monitoring at KIT to timestamps.csv. The data ranges from block 369715 to 819921.
I did some basic cleaning to remove timestamps of blocks that were received late because the monitoring node was not running when the block was created.
I had to compress timestamps.csv to stay below GitHub's file size limit.

Thanks! I'll have a closer look next week.

I did some basic cleaning to remove timestamps of blocks that were received late because the monitoring node was not running when the block was created.

Awesome, I do have a quality assurance CI job that does something similar.

I had to compress timestamps.csv to stay below GitHub's file size limit.

Hm, yeah I didn't think about this before. Maybe moving to a different format might help. For example, we don't need the header hash for each node. I'll see what I can come up with.

I did some basic cleaning to remove timestamps of blocks that were received late because the monitoring node was not running when the block was created.

Awesome, I do have a quality assurance CI job that does something similar.

fwiw: this is the output on the uncompressed CSV file.
$ python3 qa/block-timestamps/check-block-timestamps.py
Checking that timestamps don't deviate too much from block header timestamps
Imported 820249 timestamps from qa/block-timestamps/block-timestamps.csv
Checking timestamps.csv...
ERROR: Timestamp for block 726371<PHONE_NUMBER>00000000083122d3fe07cc349dd200d497891411a711cdb49375f7) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 38880.974s
ERROR: Timestamp for block 726370<PHONE_NUMBER>0000000002684c0298ef3c6e4708e7d11b5f14a59b8137999ba279) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 40210.373s
ERROR: Timestamp for block 691670<PHONE_NUMBER>000000000e6a6a0c859ab00b92c75d7e2a6643a530e5fc03cd5abc) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 7259.312s
ERROR: Timestamp for block 691669<PHONE_NUMBER>0000000000b88a682e96dd1c6b93be32c111f28b333783f46c8b19) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 7418.312s
ERROR: Timestamp for block 691668<PHONE_NUMBER>000000000b6e1d7f0921a48618853d2d5979d8fa0c24d4831124c5) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 7442.256s
ERROR: Timestamp for block 691667<PHONE_NUMBER>0000000000fa50b1f2988a23d369a2ef560fcc2794c6892e1c4f4a) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 7844.186s
ERROR: Timestamp for block 689623<PHONE_NUMBER>000000000761c150e65e8f17644a2185f36a355f1b472dbc1d53e9) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 23523.359s
ERROR: Timestamp for block 689606<PHONE_NUMBER>0000000012b2093e931ac9e62ab3a665625647cda72309f244f9e6) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 34612.24s
ERROR: Timestamp for block 689597<PHONE_NUMBER>00000000031d8f578807033b57cc3b8b73a7f7c1e91972ba1c826c) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 40667.626s
ERROR: Timestamp for block 689595<PHONE_NUMBER>000000000e2224eba06fc8d376a057414d60fdffbbd95d3ba38672) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 43161.31s
ERROR: Timestamp for block 689584<PHONE_NUMBER>0000000006fd852fcf6a6377b9b979ac428476710115aa1b066daf) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 47329.47s
ERROR: Timestamp for block 689540<PHONE_NUMBER>0000000007ba54986a72067dac4730789d91b3b38b889c3bd8fdcb) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 74067.925s
ERROR: Timestamp for block 689533<PHONE_NUMBER>00000000108b7bd745c83190e7209e88d06ad7c09f3fe573bb4197) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 80616.507s
ERROR: Timestamp for block 682344<PHONE_NUMBER>0000000003e4c8f1c7bb96900057f352188680e7039dc9d059080f) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 24558.592s
ERROR: Timestamp for block 682343<PHONE_NUMBER>000000000be4f9dcf52c3abf45eb6236fed804f0e714de4bde95ec) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 25040.566s
ERROR: Timestamp for block 670641<PHONE_NUMBER>000000000cafae4b2f1a33ff770ec361366d1a52390eeaaeeeb23a) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 46151.997s
ERROR: Timestamp for block 670640<PHONE_NUMBER>0000000008966c80471cde133074acb5818dbc0432689a32c5474c) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 46861.759s
ERROR: Timestamp for block 583136<PHONE_NUMBER>0000000022b6c573a33a27fbb547e0668adff4d813896d98aeec5f) from source KIT Monitor B (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 116004.014s
ERROR: Timestamp for block 566938<PHONE_NUMBER>0000000003e854aee7346a0d09d6ede68b3be8eb5ca0ff302cb72d) from source KIT Monitor 1 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 39400.755s
ERROR: Timestamp for block 560469<PHONE_NUMBER>0000000020a4ce87336fc0736a9965ff66cf9f3df5f561ebef9bdb) from source KIT Monitor 2 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 7964.42s
ERROR: Timestamp for block 560468<PHONE_NUMBER>000000002a2ac2229355ad270d913191282c0a697321933ad51685) from source KIT Monitor 2 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 7387.369s
ERROR: Timestamp for block 560467<PHONE_NUMBER>0000000006b98777f7352c60465dfc3b387ff896291b247b9b6242) from source KIT Monitor 2 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 7586.395s
ERROR: Timestamp for block 560466<PHONE_NUMBER>00000000196d6d1d3f6fe9a9115a63d9b6714d9cef1a976bdb6b35) from source KIT Monitor 2 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 9673.449s
ERROR: Timestamp for block 549741<PHONE_NUMBER>0000000005da90b3f881e54016c0e4e35af45fdfdc0a542513aeb1) from source KIT Monitor 2 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 28983.899s
ERROR: Timestamp for block 549714<PHONE_NUMBER>0000000017bf87a77361c891edb479b15e21962b7f0ee2074342a9) from source KIT Monitor 2 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 49048.837s
ERROR: Timestamp for block 495682<PHONE_NUMBER>000000001a5120a39b48f8b0b2f8566fc8e6e00084072bd76144a2) from source KIT Monitor 2 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 16177.871s
ERROR: Timestamp for block 416413<PHONE_NUMBER>00000004bcd22ace7ef21346865d2b27ba504ddf4ddd43a73102aa) from source KIT Monitor 1 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 9609.54s
ERROR: Timestamp for block 416411<PHONE_NUMBER>00000001caece62c012d54f5860f0c9d404c905f0b3903fa35558d) from source KIT Monitor 1 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 10382.854s
ERROR: Timestamp for block 377774<PHONE_NUMBER>00000004b314d46d33dce1fa1759b117330728704446ef65eabd72) from source KIT Monitor 1 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 45760.332s
ERROR: Timestamp for block 377773<PHONE_NUMBER>00000000d89d5ac3d2cd194de60fe13f8769f720ef6bcaf5f79dbe) from source KIT Monitor 1 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 45985.703s
ERROR: Timestamp for block 377772<PHONE_NUMBER>0000000ddc3b0303d8fc64c79e27b19ecd91054240b6932e31f94a) from source KIT Monitor 1 (dsn.kastel.kit.edu/bitcoin/) deviates more that 7200.0s into the future: 46450.491s

Statistics about offsets from block timestamps:
source                    count      min       max         mean        stdev       quantiles[s]
darosior node0            42639      -493s     2562s       20.76s      37.26s      [11.0, 20.0, 29.0]
0xB10C monitoring1        149105     -3440s    3665s       21.40s      30.11s      [10.645, 19.876, 29.128500000000003]
KIT Monitor B             239718     -3440s    116004s     24.30s      420.43s     [9.834, 19.266, 29.13225]
KIT Monitor 2             434909     -4418s    49049s      20.94s      111.95s     [9.662, 19.508, 30.299]
KIT Monitor 1             431282     -4418s    46450s      21.55s      156.33s     [9.647, 19.483, 30.265]
0xb10c memo               51491      -1708s    1442s       27.06s      45.43s      [11.0, 20.0, 30.0]
0xb10c memo-old           72693      -2130s    682s        20.90s      30.47s      [9.0, 19.0, 30.0]

Check not successful.
The listed timestamps might have been recorded during IBD or the system clock was wrong?

fwiw: this is the output on the uncompressed CSV file.

Great, that's a helpful script!
I've used stricter rules for cleaning the data and have updated the commit.

I split the big timestamps.csv file into one file per source (along with adding a script to combine them to one big timestamps.csv file again) as a result of #17 in #18. I've adopted your commit to the new format and pushed to https://github.com/bitcoin-data/block-arrival-times/tree/2023-12-kit-matthias-g. Let me know if the attribution in data/README.md is OK. Feel free to push this commit here or, alternatively, I'd be happy to open a new PR with it too.

Splitting the file per data source sounds like a good approach.
Your updates to the commit in https://github.com/bitcoin-data/block-arrival-times/tree/2023-12-kit-matthias-g look good. Thanks! I've copied the updated commit here.

Thank you!


Create GH Pages site

Create a GitHub Pages site for Formation for better SEO results, documentation handling, etc.
We'll need a mobile-first responsive design that allows easy viewing of everything on various devices. We will move the examples folder to this site, and thus will need to modify the Gruntfile in order to copy the dist files into the appropriate Jekyll dir.
See https://medium.com/eightshapes-llc/space-in-design-systems-188bcbae0d62 for guidelines on space management.

Pages needed:

[ ] Statement of usefulness etc; Dependencies, Installation, Usage, License
[ ] One page for each supported element type and its available rules
[ ] Advanced Usage (detecting events, custom rules
[ ] API
[ ] Contributing

Helpful links:

https://help.github.com/categories/github-pages-basics/
https://help.github.com/articles/user-organization-and-project-pages/

Site is now live at http://ozzyogkush.github.io/formation and npm package updated to 1.1.1 with new docs links.


Fixed conan build

DRAFT: [check build]

build on ubuntu-20.04 for more compatible binaries
reverted conan compiler.version to 9
added revisions for conan recipes
some dumps added to CMakeLists to help troubleshooting protoc versin errors

All PRs in Boschglobal for this repo are likely merged to the root repo, closing them!


In editor, doubleclicking a word, but the word is not selected sometimes

VSCode Version: 1.46.1
OS Version: Windows 10 2004

Steps to Reproduce:

System DPI is set to 200%
Editor font is Sarasa Gothic
Create a new Lua script

Does this issue occur when all extensions are disabled?: Yes

I cannot reproduce. I have 175% DPI, also using windows 10, but latest version of VS Code.


Extensible texture formats

It may be desirable for framework to support new texture formats. This may be done in different ways: 1) framework provide extension hooks, 2) framework delegates texture loading/decoding to application, 3 application can fix textures post-mortem.
I think 1) and 2) may be highly desirable for a powerful system. 1) means framework developers/contributors can extend the framework for new texture formats 2) means without 1) app developers are not stuck.
The most wanted formats from my side is .TGA which is widely used by .OBJ models. Embedded FBX textures are also desirable but requires more infrastructure support (something like an IOSystem delegate for assimp).

I've worked out a solution for loading custom textures for anyone who's interested (TGA format is supported).
The working demo app can be found here: https://github.com/danke-sra/GearVRf/commit/a794a607b0daa82d583f2bdfb9ab51945a4bbc00
Some changes are made to the jassimp loader and won't affect textures not loaded by jassimp. If needed, they can be pulled up.


Make ClassNameMapper injectable in SchemaFactory

This pull request makes the ClassNameMapper instance injectable via setter in the SchemaFactory. If not injected, everything behaves as before this PR.

Hey @flow-control ,
Looks good to me! Quite impressed with your PR ;)
Would you mind adding just a call to the setClassNameMapper method in the SchemaFactoryTest to fix code coverage?
Also, just out of curiosity, in what scenario did you need to inject a new ClassNameMapper?

Hey @moufmouf,
we @OXID-eSales are building a GraphQL API on top of our e-commerce system, which will not be part of the core distribution but installable as a plugin. This means, that projects composer.json will not have the namespaces and paths to the GraphQL types, queries, mutations, ...
I will fix the code coverage and btw.: thanks for this very awesome library :+1:
/Flo

Thanks a lot! :+1:


It's Time

I think you should archive this repo. VS now has equivalent, better functionality, and you are not active on the project.

Hi, this repo is a fork of the original one. The fork was needed for supporting also VS on ARM and doing some fixes to the original extension. At the moment there is no plan to evolve it with new features. But, whoever want to add something, is welcome. Who want to use it as it is, is welcome. I contribute on it on my spare time. Anyway, I will leave it open for security fixes.


"Podeni" is listed in the drop-down menu

Description:
"Podeni" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Podeni" in the search bar.

Expected results
The location is listed in the drop-down menu as "Podeni, Argeș (Buzoești)".


Dropped packets on low end mac book air

While running noble on:
macOS Sierra version 10.12.1
Macbook Air (13-inch, Early 2015)
Processor: 1.6 GHz Intel Core i5
Memory: 8 GB 1600 MHz DDR3
Bluetooth info:
Bluetooth Low Energy Supported: Yes
Handoff Supported: Yes
Instant Hot Spot Supported: Yes
Manufacturer: Broadcom
Transport: USB
Chipset: 20702B0
Firmware Version: v127 c9208
The problem is on this computer only, about every two packets n number of packets are dropped. We are sending packets at 100Hz. Every other computer we have tried this software on works fine and packets are occasionally dropped (1-2 a minute).
I tried following the instructions in this online guide but to no avail, nothing seems to help. http://www.idownloadblog.com/2016/02/01/experiencing-bluetooth-problems-on-your-mac-try-this/
Is my mac just too low end? Is this a problem others have seen?
Thanks

Hi @aj-ptw,
I suggest you use the Packet Logger app from the Xcode Hardware IO Tools packages to take a closer look at what's going on. If you think there's something wrong with noble please save a trace and upload here.
Please note BLE notifications are best effort.
I'm close this for now.

Hi @sandeepmistry could I ask you to look back at this issue? Several macs, including both of mine are experiencing the same problem of packets being dropped.
Checkout the attached screen shot of the dropped packet. Can this be patched?