Trigger Events Based on Messages in Queue

Is there any way currently, or a plan to add a way, to mimic SQS events to pass a message directly to a script similar to how SQS events work in AWS?

I'm not quite sure what you are referring to. AWS Lambda perhaps?

Yea if I were deploying to AWS and was using SQS and a Lambda I could set an event that would trigger the Lambda based on messages in the queue. Of course I can create a script that just checks the queue periodically, but is there a way to instead do this on the ElasticMQ side to better mimic message events locally?

From: Michał Ossowski @.>
Sent: Saturday, December 16, 2023 4:37:23 AM
To: softwaremill/elasticmq @.>
Cc: Rick Getz @.>; Author @.>
Subject: Re: [softwaremill/elasticmq] Trigger Events Based on Messages in Queue (Issue #941)
I'm not quite sure what you are referring to. AWS Lambda perhaps?
—
Reply to this email directly, view it on GitHubhttps://github.com/softwaremill/elasticmq/issues/941#issuecomment-1858774347, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABYSC2IQK5WFWWKAQQ4BC53YJVTVHAVCNFSM6AAAAABAWSZYI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJYG43TIMZUG4.
You are receiving this because you authored the thread.Message ID: @.***>

Then the answer would be no. This project is simple in-memory queue with SQS API interface.
If you need to test integration of two or more AWS components you can take a look at https://github.com/localstack/localstack project

Fair enough. Thanks!


[Draft] Enhance GUI and Integration of Features

Major GUI Change with addition of Tabs
Addition of CsvUtils

Codecov Report

Merging #91 (232f649) into master (6b8bbf3) will decrease coverage by 2.82%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master      #91      +/-   ##
============================================
- Coverage     62.77%   59.95%   -2.83%
  Complexity      477      477
============================================
  Files            84       87       +3
  Lines          1698     1778      +80
  Branches        179      186       +7
============================================
  Hits           1066     1066
- Misses          573      653      +80
  Partials         59       59

Impacted Files
Coverage Δ

.../main/java/seedu/address/commons/util/CsvUtil.java
0.00% <0.00%> (ø)

...in/java/seedu/address/commons/util/StringUtil.java
77.27% <0.00%> (-7.73%)
:arrow_down:

...rc/main/java/seedu/address/logic/LogicManager.java
53.57% <0.00%> (-6.43%)
:arrow_down:

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)

...rc/main/java/seedu/address/model/ModelManager.java
88.67% <0.00%> (-1.71%)
:arrow_down:

...s/model/person/RandomPersonGeneratorPredicate.java
0.00% <0.00%> (ø)

.../java/seedu/address/model/util/SampleDataUtil.java
20.00% <ø> (ø)

.../java/seedu/address/storage/JsonAdaptedPerson.java
93.33% <ø> (ø)

src/main/java/seedu/address/ui/MainWindow.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/ui/PersonDetails.java
0.00% <0.00%> (ø)

... and 1 more

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 6b8bbf3...232f649. Read the comment docs.


NEI recipe lookup for Ethylene fails

Ethylene is a by-product of Biofuel in the PRC. You cannot determine the source of Ethylene from NEI (left clicking on it in the NEI just shows the R Condenstrator recipe, not the PRC one).

Fixed!


[SVCS-123] Allows read-the-docs to read Python 3

Purpose
Upgrade invoke to 0.13.0 and write a work around so mfr can use python 3 with read-the-docs.
Changes
Additional config files for read the docs, removes references to non-existent LaTex files.
Side Effects
None that I know of.
Ticket
https://openscience.atlassian.net/browse/SVCS-123

Merged as part of b7e9f1dfb370e5e044e16bbfb467cae6cf2f4f8a.  Thanks!


Missing import statements in nbeats.py

Hi, I was exploring the repository and noticed that the loss metrics import statement in nbeats.py was missing some of the import statements causing errors in line 361 to 367.
Current the statement reads as from src.utils.numpy.metrics import mae, pinball_loss but I'm assuming the statement should include mape, smape, rmse, and mse loss (from src.utils.numpy.metrics import mae, pinball_loss, mape, smape, rmse, mse).
Not a big problem tbh, just thought I would bring it up.
Great work by the way!

Hi,Could you please share the dataset? My email is: zhenjiangwu613@gmail.com,thx!


Add --enabled services/platform key to ros be list command

Add --enabled services/platform key to ros be list command

This fixes https://github.com/rails-on-services/ros-cli/issues/20


Sometimes codeceptjs will crash running with nmp/yarn scripts

Details

CodeceptJS version: v0.18.1
NodeJS Version:v7.0.0
Operating System:ubuntu 14.04
Protractor || WebDriverIO || Nightmare version (if related): WebDriverIO
Configuration file:NA
Package.json:

"scripts": {
    "setup": "yarn global add codeceptjs && yarn global add webdriverio && yarn global add selenium-standalone@latest",
    "selenium": "selenium-standalone install && selenium-standalone start",
    "xml": "codeceptjs run --reporter mocha-junit-reporter",
    "html": "codeceptjs run --reporter mochawesome",
    "lint": "eslint tests",
    "lint-fix": "eslint --fix tests"
  }

I run tests with below command:

yarn run html

But sometimes,it will crash during the testing,pls refer the detail log:

+ yarn run html
yarn run v0.18.1
$ codeceptjs run --reporter mochawesome
more test cases......
Done in 710.33s.

After codeceptjs crashs,it will not produce test report.And can not catch the shell scripts error.
This will mark the CI result as passed,but it is failed actually.

@junguchina Could you add --verbose flag in npm/yarn scripts and provide detailed logs? Also examples of executable tests will be useful

Close due inactivity


twister: fix the testcase-schema.yaml

Change the "yes/no" value to "true/false".
Otherwise pykwalify 1.8.0 will report below errors:

Value: 'no' for required keyword must be a boolean:
Path: '/mapping/common'>
Value: 'yes' for required keyword must be a boolean:
Path: '/mapping/sample/mapping/name'>

Signed-off-by: Shao Ming<EMAIL_ADDRESS>

Below previous PR is closed due to a mistake in string replacement. Please use this one.
https://github.com/smrtos/zephyr/commit/eccb5bc9276c803c0d6b1d42d078663c89c2e431#r60535821

Incomplete fix.


Plans to map CALIBER phenotypes to ontology terms?

Hi CALIBER team,
This is less an issue and more of a feature request - I was just wondering if there were any plans to extend the metadata about each CALIBER phenotyping algorithms with ontology terms? I was thinking Monarch Disease Ontology (MONDO) and/or Experimental Factor Ontology (EFO) terms may be helpful for those looking to find phenotyping algorithms by ontology mapping rather than manual trait/text matching.

Hi Sam,
if we are to map then MONDO is the most likely ontology for me as it covers disease space well. EFO is interoperable with MONDO but is a less good fit. I'd like to hear from SAIL colleagues on if they have a mapping process in place, we can build one from my group if useful as well,
best
Helen

Agreed, MONDO seems like a good choice of linkage!

We do have a rudimentary map to EFO so we could cross-map with the GWAS
catalogue so we could refine it to point to MONDO!
Is there a good EFO to MONDO map or is this not worth exploring and a fresh
map is required?
Spirors
On Wed, Jul 21, 2021 at 8:34 PM Sam Lambert @.***>
wrote:

Agreed, MONDO seems like a good choice of linkage!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/spiros/hdr-caliber-phenotype-library/issues/32#issuecomment-884366193,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAFZZDEO4FHLZH3R2PVHGDTY4ALZANCNFSM5AX6PEUA
.


remove caching effects from dockerfile

Description

Add --no-cache and -U flags on pip
Related Issues

Checklist

[ ] Is this code covered by new or existing unit tests or integration tests?
[ ] Did you run make test successfully?
[ ] Do new classes, functions, methods and parameters all have docstrings?
[ ] Were existing docstrings updated, if necessary?
[ ] Was external documentation updated, if necessary?

Additional Notes or Comments

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

Comparison is base (cbe6b32) 78.22% compared to head (a092a04) 80.26%.
Report is 99 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1140      +/-   ##
==========================================
+ Coverage   78.22%   80.26%   +2.03%
==========================================
  Files         101       97       -4
  Lines        6351     6596     +245
==========================================
+ Hits         4968     5294     +326
+ Misses       1383     1302      -81

Files
Coverage Δ

superduperdb/__init__.py
100.00% <100.00%> (ø)

superduperdb/__main__.py
71.42% <100.00%> (ø)

superduperdb/base/config.py
100.00% <100.00%> (ø)

superduperdb/base/jsonable.py
80.55% <ø> (ø)

superduperdb/cli/serve.py
31.81% <ø> (ø)

superduperdb/container/component.py
82.92% <100.00%> (+2.92%)
:arrow_up:

superduperdb/container/dataset.py
87.17% <100.00%> (ø)

superduperdb/container/encoder.py
90.00% <100.00%> (+0.16%)
:arrow_up:

superduperdb/container/listener.py
83.05% <100.00%> (ø)

superduperdb/container/serializable.py
98.14% <100.00%> (+3.02%)
:arrow_up:

... and 30 more

... and 8 files with indirect coverage changes

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


[WFLY-18084] Galleon layers for micrometer and opentelemetry are not documented

https://issues.redhat.com/browse/WFLY-18084
Add entries for micrometer, opentelemetry, and microprofile-telemetry

Thanks @jasondlee


Schedule grace period should be configurable

https://github.com/projectkudu/kudu/blob/201e2298280b4d2b2f329fa53980f6e096b0ac45/Kudu.Core/Jobs/Schedule.cs#L49

Hi
Kudu will continue to run in Azure App Service. However, this repo will no longer be maintained.
If the problem persists and is related to running on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service


⚠ Bofrost.at has degraded performance

In 0f12e48, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1269 ms

Resolved: Bofrost.at performance has improved in b84c0f5 after 7 minutes.


element only works when its a direct child to

In my "MainController":

// Setup Leaflet Directive Layers
    angular.extend($scope, {
      center: { lat: -0.006, lng: 0.015, zoom: 14 },
      defaults: {
        scrollWheelZoom: false
      },
      layers: {
        overlays: {
          L1: { name: 'Architecture', url: mB+'/{mapid}/{z}/{x}/{y}.png?access_token={apikey}',
            type: 'xyz', visible: 'true', layerOptions: { apikey: key, mapid: m1 }
          },
          L2: { name: 'Structure', url: mB+'/{mapid}/{z}/{x}/{y}.png?access_token={apikey}',
            type: 'xyz', visible: 'true', layerOptions: { apikey: key, mapid: m2 }
          }
        }
      }
    });

then in index.html:

  <leaflet center="center" layers="layers" height="90%"></leaflet>

As soon as I put leaflet inside of another div, it doesn't work..

<leaflet center="center" layers="layers" height="90%"></leaflet>

Im ultimately trying to put it inside of route provider (ng-view) but I can't even get it to work in a simple div first and I have no idea what I'm doing wrong. Please help!

Plunkr or jsfiddle. would be most excellent.

Also use backticks to forformat your code like
oh hi I am code

Probably you need to give the dive some height.

This is dead, closing unless I hear some news.


Enhancement/custom widget resize

PR fixes following issue(s)
Fixes #30821
Media

A video or a GIF is preferred. when using Loom, don’t embed because it looks like it’s a GIF. instead, just link to the video

Type of change

New feature (non-breaking change which adds functionality)

Testing

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Also list any relevant details for your test configuration.
Delete anything that is not relevant

[ ] Manual
[ ] JUnit
[ ] Jest
[ ] Cypress

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

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

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/build-deploy-preview skipTests=true

/ok-to-test<EMAIL_ADDRESS>

/ok-to-test<EMAIL_ADDRESS>

/ok-to-test<EMAIL_ADDRESS>

@sbalaji1192 why is this a chore and has the label skip-changelog.
From what I understand, We are shipping a feature

@somangshu I don't think we should consider this as a feature. its a small enhancement to an existing UI. No new functionality has been added from user perspective.

/build-deploy-preview skipTests=true env=release


Upgrade yapoml to 1.39

Deleted implicit timeout

As there's already #112 here related to move of examples to a separate repository I'd suggest put this one on pause and once #112 and https://github.com/MAFIN-Squad/examples/pull/1 are merged, migrate these changes to a new solution.
Alternatively, and maybe even preferabley in this case, you could just put your changes directly in https://github.com/MAFIN-Squad/examples/pull/1.
What do you think?


[BUG] - Date Range Picker TypeError (Error on click the right corner)

NextUI Version
2.3.6
Describe the bug
When i clicked the bottom right corner of the date range picker before or after select a new range of dates. The component fallbacks an error
Unhandled Runtime Error
TypeError: Failed to execute 'createTreeWalker' on 'Document': parameter 1 is not of type 'Node'.

This occurs on the main website and when using the component in my own project
Your Example Website or App
https://nextui.org/docs/components/date-range-picker
Steps to Reproduce the Bug or Issue

Go to the Date range picker
Click in the bottom right corner of the component

Expected behavior
As a user, i don't expect to have this error on the component.
Screenshots or Videos
https://github.com/nextui-org/nextui/assets/58609880/bfcbe55a-d70f-4113-8237-0268321d6873
Operating System Version
macOS
Browser
Chrome

I have the same issue

Hi, I also received the same issue in my next.js project using "@nextui-org/react": "^2.3.6"
Unhandled Runtime Error
TypeError: Failed to execute 'createTreeWalker' on 'Document': parameter 1 is not of type 'Node'.

The way I solved it was by installing the package as individual npm install @nextui-org/date-picker, and then using that import in my project.
Before I was using global import {DateRangePicker} from "@nextui-org/react"; which gave me the error, thank you

@zillBoy Just FYI. This issue has been fixed and our latest version is v2.4.2.


Prepare backport of bug fixes for releasing 1.1.1

Command to generate the below list:
git fetch origin
git log --grep='Merge pull request' --format="%s %b" origin/release-1.1..origin/release-1.2 \
  | cut -d' ' -f4,7-  | awk '{print "- [ ]",$0}'

In order to backport PRs for releasing the patch version v1.1.1, we can do:
/cherry-pick release-1.1

Which ones should we cherrypick? I crossed the PRs that I think are not bugfixes.

[x] #3647 Fix Helm chart type conversion bug → ❌ CONFLICT
[ ] ~#3505 Add option to specify OCSP server #3497~
[ ] ~#3545 Allow ingress-shim to specify key usages + add server-auth to default~
[ ] ~#3628 Fix duplication of the CRD definitions in cert-manager.yaml~
→ doesn't need to be cherry-picked as it was introduced during a 1.2 alpha release
[ ] ~#3538 Fix comments for docs on types_certificate.go~
[ ] ~#3623 Skips invalid Ingress tls entries instead of invalidating the Ingress~
[ ] ~#3532 Make CNAME resolver recursive~
[ ] ~#3604 Passes a singe context with cancel func to all the kubectl plugin com…~
[ ] ~#3583 Add CRD categories~
[ ] ~#3457 Add inspect secret command~
[ ] ~#3514 E2e tests for external issuers~
[ ] ~#3593 The development meetings are now hosted on Google Meet~
[ ] ~#3533 Venafi Issuer now sets the CA.crt field of the Secret~
[ ] ~#3552 Minor log message clarification~
[ ] ~#3559 Remove copyright year from codegen~
[ ] ~#3556 Fix verify-codegen.sh to ignore Copyright lines~
[ ] ~#3529 Fix release tar content of manifests~
[ ] ~#3526 Remove a deprecated script and some lingering references to an old make e2e_test target~
[ ] ~#3527 Make leader-election settings customizable for cainjector~
[ ] ~#3519 Remove Helm hack for webhook API versions~
[ ] ~#3522 Remove api-migration tool~
[ ] ~#3463 Wait for order-controller to add certificate data to the Order~
[ ] ~#3465 Add duration and renew-before Ingress annotations to set those fields on the Certificate~
[ ] ~#3515 Rename the User Agent fields~
[ ] ~#3440 Update ingress-nginx addon~
[ ] ~#3500 Update copyright to cert-manager project~
[ ] ~#3499 Migrate Ingress to networking.k8s.io/v1beta1~
[ ] ~#3503 Add Kubernetes 1.20 to the kind setup script~
[ ] ~#3477 Added profiling for controller~
[ ] ~#3489 Add creation of truststore.p12 from CA~
[ ] ~#3504 Remove legacy kind + old kind kubernetes versions~
[ ] ~#3487 Remove the legacy release~
[ ] ~#3476 Move the 'back off for 1 hour' logic to a unit-tested func~
[x] #3478 Bug: the issuing controller does not wait until the request matches the certificate before setting the certificate to "Issuing = False"
[ ] ~#3433 Handle Vault issuer working as intermediate correctly~
→ is a kind/feature so shouldn't be backported
[x] #3485 Strip X-Amzn-RequestId to avoid spurious challenge updates
[ ] ~#3464 Fix and deprecate the --renew-before-expiration-duration flag~

Notes for backporting:

https://github.com/jetstack/testing/pull/428#pullrequestreview-588652838 discusses how we should set up prow to test release-1.1 branch as we backport to it and eventually release it

cc @jakexks

#3628 Fix duplication of the CRD definitions in cert-manager.yaml doesn't need to be cherry-picked as it was introduced during a 1.2 alpha release
#3433 Handle Vault issuer working as intermediate correctly is a kind/feature and shouldn't be backported
Aside from that I agree with your categorisations 👍
/assign

Do we need to backport anything? Related discussion in #cert-manager-dev

We only support the current version
However, the helm chart fix could be backported to aid people upgrading
It might be a courtesy to backport a few bug fixes if people can't upgrade their installations - but we'd need to create dedicated test jobs

After discussion in the stand-up this morning, only the helm chart fix should be backported.

Is it possible to pull #3465 to v1.0.0? I have a helm2 deployment and I need this fix. v1.2.0 requires helm3 and we only have support of helm2.

Hi!
I think it makes sense for us to backport "upgrade" patches that would help users upgrade to earlier versions of cert-manager.
From what I understand, you have an existing cert-manager v1.0 deployment that was deployed using Helm 2. Your goal is to upgrade cert-manager to v1.2.0, but v1.3.0 requires Helm 3.
Question:

Is the problem the fact that there is some difficulty in upgrading your current Helm 2 release to a Helm 3 release using helm (the CLI) v3?
Or is it that you want to keep using Helm 2 for use with cert-manager v1.2? If that is the case, we do not support Helm 2 anymore as of (some version of cert-manager that I cannot remember of 😅)

Thank you Maelvls for your response. Currently I am on v01.15.2 and system is working fine except that the ingress certificates are expiring in 90days which is causing us issues. That is the reason I wanted fix #3465. We are using helm2 and cannot upgrade to helm3 as it will be very complicated for us and require quite a bit of changes.  So

Can #3465 be back ported to v0.15.2 (preferred) and we can continue with what we have. This version is requires helm2.
Can #3465 be back ported to v1.0.0 (good option) ? Since this uses helm2, I can upgrade to this version.
Do you know what issues I might see if I deploy v1.2.0 with helm2 (not helm3). I tried this option, certificates came up fine, but saw too many kube apiserver call being throttled so not sure if it was deployed right.


Support the GitHub Checks API

This would allow us to report rich information back to GitHub PRs directly, potentially including:

success/failures in the compiler matrix (including 'non-fatal' beta compilers);
linting errors, for source code and documentation (https://github.com/ocurrent/ocaml-ci/issues/94);
impact of changes on rev-deps.

I've done some work on this - it's visible here: https://github.com/novemberkilo/ocurrent/commit/5c606a95d675c3300919883fae3ff1fb39881e53
However, I am not focused on this at the moment so am un-assigning myself. I will pick this up again as appropriate.

Status: The checks-run driven rebuild is enabled. We're not doing anything with check-suite events yet so that's something to visit next.


Allow the user to export the data

A nice feature would be allowing the user to export the data into a human readable formatted file like CSV file.

Thank you for your time spent with my app. Please make a fork and create a pull request. Thank you :)

@rpuspana I cannot make a pull request because it seems that I am not allowed to.


chore: fix documentation for id.mk

Corrects documentation for id.mk which previously implied that id was a lawful Monad, Applicative and Functor

LGTM

bors merge


farmer dashboard - frontend

initially displays the owners who are interested in the produce mentioned by farmer in his profile

make a intuitive notification banner to receive updates on buyers
make a banner to sell produce

assigned to lavi

main nhi kar rha


Update branch

What does this change?
Brengt mijn container query weer up to date met de main.

How Has This Been Tested?

[ ] User test
[ ] Accessibility test
[ ] Performance test
[ ] Responsive Design test
[ ] Device test
[x] Browser test

How to review

Check merge conflicts en of alle files er nog staan.

Prima👍


(fix) - useState can potentially add to the state queue and make the _dirty call neglect this

Fixes: https://github.com/developit/preact/issues/1583
Bytesize remains untouched

Coverage remained the same at 100.0% when pulling a056d8fe50967f01a2db6cc7e24159156ce5604d on fix/useState into 9d2fb10b43034f0b742b59be32eb05e852bcdbbf on master.


[chore] Workflow for v0.4.3 branch

Changes

Add v0.4.3 workflow
Submitter Checklist

[ ] Docs included if needed
[ ] Tests included if needed
[x] Follows the good commit messages standard

/approve

/test


Adding function allowing to limit the text length in Entry

This function allows the developer to limit the maximum number of characters allowed in the Entry (set it to 0 to disable this limit).

Thanks for your contribution. I've adjusted the code style, comments and a bug that didn't reset the text if a maximum length is set on an entry that already has a longer text stored. ;-)

Sorry if I don't respect the code style. I'm not habituate to it totaly. ;-)

Yeah, I understand that. Writing in another style than the own is always a bit pricky ;)


Install/uninstall script

…e with import-module locking local dll files

PR Summary
Keep install/uninstall in the same script
TODO: figure out import-module locking local dll files issue and preventing uninstallation
TODO: figure out versioning for upgrading
TODO: replace placeholder urls with github release urls, potentially with aka.ms links?

PR Context

I’ve made some changes to the script, and will push to the PR later tonight, please hold off any changes before that.

From: Steven Bucher @.>
Sent: Friday, November 15, 2024 3:34:34 PM
To: PowerShell/ProjectMercury @.>
Cc: Dongbo Wang @.>; Mention @.>
Subject: Re: [PowerShell/ProjectMercury] Install/uninstall script (PR #285)
@StevenBucher98 commented on this pull request.

In tools/scripts/script.ps1https://github.com/PowerShell/ProjectMercury/pull/285#discussion_r1844663206:

+# ----------------------------------------------------------------------------------

+param(

[Parameter(HelpMessage = "Specify this parameter to uninstall AIShell")]
[switch] $Uninstall
+)

+<#################################################
+#
+#               Helper functions
+#
+#################################################>
+
+function Get-PowerShellVersion {

if ([version]$PSVersionTable.PSVersion -lt [version]"7.4.6") {

   Write-Warning "[PowerShell version 7.4.6 is the minimum requirement for AIShell module, exiting...]"

Agreed we should add where they can install PS 7.4.6
—
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/ProjectMercury/pull/285#discussion_r1844663206, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAA7DWVTJEIUUYIRYVAVFOD2A2AIVAVCNFSM6AAAAABRSBHSL2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIMZZHEZDQMBVGI.
You are receiving this because you were mentioned.Message ID: @.***>

@calvinhzy @StevenBucher98 Given the issues with the script and the tight timeline, I rewrote some of the install script to get it ready for try-out and iterative updates. Make sure you sync this branch if you are making code updates.
@calvinhzy Note that I haven't get a chance to test the new implementation yet, so please go-ahead testing and fixing issues that you might find.

This file needs to be named something more descriptive, I suggest installaishell.ps1


A value of 0 is not allowed. 0 must be used  border-zero

What version of Sass Lint are you using?
Not using
Please include any relevant parts of your configuration
border-zero:
- 1
- convention: 0
What did you do? Please include the actual source code causing the issue.
@include screen(sm-phone) {
border: 0;
padding: 0;
}
What did you expect to happen?
no error
What actually happened? Please include any error messages given to you by Sass Lint.
A value of 0 is not allowed. 0 must be used  border-zero
If you're using a IDE plugin have you tried the CLI too?
i am using gulp-sass-lint Atom and VIM, same error message

Hi there this is a duplicate of #861


TestCrypt Failures.

Is anyone else seeing the crypto failures when running test_crypt.exe (Win64)?
Crypto Wrapper Cryptosystem Testing:
Crypt hash Engine Testing:

SHA256: Init... Update... Finalize... Check value... HashAll... [Pass]
SHA384: Init... Update... Finalize... Check value... HashAll... [Pass]
SHA512: Init... Update... Finalize... Check value... HashAll... [Pass]
SHA3_256: Update... [Failed]
SHA3_384: [Failed]
SHA3_512: [Failed]
SM3_256: HashAll... [Failed]

Crypto HMAC Engine Testing:

HMAC-SHA256: Update... Finalize... Check value... [Pass]
HMAC-SHA3_256: [Fail]

Crypto HKDF Engine Testing:

HKDF-SHA256: extract... Check value... expand... Check value... extract_and_expand... Check value... [Pass]
HKDF-SHA3_256: extract... [Fail]

Crypto AEAD Testing:

AES-GCM Encryption: [Pass]
AES-GCM Decryption: [Pass]
ChaCha20Poly1305 Encryption: [Pass]
ChaCha20Poly1305 Decryption: [Pass]
SM4-GCM Encryption: [Fail]

Crypto RSA Engine Testing:

Generate RSA context ... Set/Get RSA key Components ... Clear/Get RSA key Components ... Generate RSA key Components ... Check Invalid RSA key Components ... hash Original message ... PKCS#1 signature ... PKCS#1 signature Verification ... PSS signature ... PSS signature Verification ... Release RSA context ... [Pass]

Crypto RSA key Retrieving Testing:

Retrieve RSA Private key for PEM ...[Pass]

Retrieve RSA public key from X509 ... [Pass]

PKCS#1 signature ... [Pass]

PKCS#1 signature Verification ... [Pass]

X509 Certificate Verification with Trusted CA ...[Pass]

X509 Certificate Chain Verification ... [Pass]

X509 Certificate Chain get leaf certificate Verification ... [Pass]

X509 Certificate Chain get leaf certificate Verification ... [Pass]

X509 Certificate Chain get root certificate Verification ... [Pass]

X509 Certificate subject Bytes Retrieving ... [Pass]

X509 Certificate context Retrieving ...

Retrieving Common name = "intel test ECP256 intermediate cert" (size = 36) - [PASS]
Retrieving Oraganization name - [PASS]
Retrieving version = 2 - [Pass]
Retrieving serial_number = 1 - [Pass]
Retrieving issuer Bytes ...  - [Pass]
Retrieving Issuer Common name = "intel test ECP256 CA" (size = 21) - [Pass]
Retrieving Issuer Oraganization name - [Pass]
Retrieving  SubjectAltName (size = 42) - [Pass]
Retrieving Validity - [Pass]
Set date_time - [Pass]
Set date_time - [Pass]
Compare date_time - [Pass]

X509 Certificate Verification with Trusted CA ...[Pass]

X509 Certificate Chain Verification ... [Pass]

X509 Certificate Chain get leaf certificate Verification ... [Pass]

X509 Certificate Chain get leaf certificate Verification ... [Pass]

X509 Certificate Chain get root certificate Verification ... [Pass]

X509 Certificate subject Bytes Retrieving ... [Pass]

X509 Certificate context Retrieving ...

Retrieving Common name = "intel test ECP256 intermediate cert" (size = 36) - [PASS]
Retrieving Oraganization name - [PASS]
Retrieving version = 2 - [Pass]
Retrieving serial_number = 1 - [Pass]
Retrieving issuer Bytes ...  - [Pass]
Retrieving Issuer Common name = "intel test ECP256 CA" (size = 21) - [Pass]
Retrieving Issuer Oraganization name - [Pass]
Retrieving  SubjectAltName (size = 42) - [Pass]
Retrieving Validity - [Pass]
Set date_time - [Pass]
Set date_time - [Pass]
Compare date_time - [Pass]

X509 Certificate Verification with Trusted CA ...[Pass]

X509 Certificate Chain Verification ... [Pass]

X509 Certificate Chain get leaf certificate Verification ... [Pass]

X509 Certificate Chain get leaf certificate Verification ... [Pass]

X509 Certificate Chain get root certificate Verification ... [Pass]

X509 Certificate subject Bytes Retrieving ... [Pass]

X509 Certificate context Retrieving ...

Retrieving Common name = "intel test RSA intermediate cert" (size = 33) - [PASS]
Retrieving Oraganization name - [PASS]
Retrieving version = 2 - [Pass]
Retrieving serial_number = 1 - [Pass]
Retrieving issuer Bytes ...  - [Pass]
Retrieving Issuer Common name = "intel test RSA CA" (size = 18) - [Pass]
Retrieving Issuer Oraganization name - [Pass]
Retrieving  SubjectAltName (size = 42) - [Pass]
Retrieving Validity - [Pass]
Set date_time - [Pass]
Set date_time - [Pass]
Compare date_time - [Pass]

X509 Certificate Verification with Trusted CA ...[Pass]

X509 Certificate Chain Verification ... [Pass]

X509 Certificate Chain get leaf certificate Verification ... [Pass]

X509 Certificate Chain get leaf certificate Verification ... [Pass]

X509 Certificate Chain get root certificate Verification ... [Pass]

X509 Certificate subject Bytes Retrieving ... [Pass]

X509 Certificate context Retrieving ...

Retrieving Common name = "intel test RSA intermediate cert" (size = 33) - [PASS]
Retrieving Oraganization name - [PASS]
Retrieving version = 2 - [Pass]
Retrieving serial_number = 1 - [Pass]
Retrieving issuer Bytes ...  - [Pass]
Retrieving Issuer Common name = "intel test RSA CA" (size = 18) - [Pass]
Retrieving Issuer Oraganization name - [Pass]
Retrieving  SubjectAltName (size = 42) - [Pass]
Retrieving Validity - [Pass]
Set date_time - [Pass]
Set date_time - [Pass]
Compare date_time - [Pass]

Crypto DH Engine Testing:

Context1 ... Context2 ... Generate key1 ... Generate key2 ... Compute key1 ... Compute key2 ... Compare Keys ... [Pass]

Crypto EC-DH key Exchange Testing:

Context1 ... Context2 ... Generate key1 ... Generate key2 ... Compute key1 ... Compute key2 ... Compare Keys ... [Pass]
Context1 ... Context2 ... Generate key1 ... Generate key2 ... Compute key1 ... Compute key2 ... Compare Keys ... [Pass]

Crypto EC-DSA Signing Verification Testing:

Context1 ... Context2 ... Compute key1 ... Compute key2 ...
EC-DSA Signing ... EC-DSA Verification ... [Pass]
EC-DSA Signing ... EC-DSA Verification ... [Pass]

Crypto EC-DSA Signing Verification Testing with SetPubKey:

Context1 ... Context2 ... Compute key in Context1 ... Export key in Context1 ... Import key in Context2 ...
EC-DSA Signing in Context1 ... EC-DSA Verification in Context2 ... [Pass]

Crypto EC key Retrieving Testing:

Retrieve EC Private key for PEM ...[Pass]
Retrieve EC public key from X509 ... [Pass]
EC-DSA Signing ... [Pass]
EC-DSA Verification ... [Pass]

Crypto Ed-DSA Signing Verification Testing:

Context1 ... [Fail]
Crypto Ed key Retrieving Testing:
Retrieve Ed Private key for PEM ...[Fail]
Crypto Montgomery Curve key Exchange Testing:
Context1 ... [Fail]
Crypto SM2 key Exchange Testing:
Context1 ... [Fail]
Crypto sm2 key Retrieving Testing:
Retrieve sm2 Private key for PEM ...[Fail]
Crypto PRNG Engine Testing:
Random Generation...[Pass]

that is expected. No all crypt functions are supported in mbedtls or openssl.

Dec 7-2021. Close as expected.


fix(layers_in_area): 13152 selected area differs from event shape

When use change selected event in order:

Select event that was never selected before
Select previously active event

This creates a situation in which all the necessary layers are already in the cache so we don't need to trigger api request (areaLayersDetailsResourceAtom). But we have an old fix in areaLayersLegendsAndSources that listen resource atom changes, and then run imperative update of eventShape layers with new geometry (this workaround was created because eventShape always have same id, but in fact different geometry depending from event in request)
I create task for refactoring that will allow us remove this workaround (14387), and as temporary solution I trigger resource atom with skip 'true` flag - it still not send request to backend, but at the same time trigger listeners of resource atom.
Additional small changes

improvements in ts config that fixes auto imports of type definitions - blocked by reatom bug
function name misspelling fixed

Codecov Report

Merging #407 (8a1bc13) into main (9afe870) will decrease coverage by 0.01%.
The diff coverage is 2.94%.

@@            Coverage Diff             @@
##             main     #407      +/-   ##
==========================================
- Coverage   11.77%   11.76%   -0.01%
==========================================
  Files         544      544
  Lines       38841    38863      +22
  Branches     1168     1168
==========================================
  Hits         4572     4572
- Misses      33824    33846      +22
  Partials      445      445

Impacted Files
Coverage Δ

...yersDetailsResource/areaLayersDetailsParamsAtom.ts
0.00% <0.00%> (ø)

...rsDetailsResource/areaLayersDetailsResourceAtom.ts
0.00% <0.00%> (ø)

...s_in_area/atoms/areaLayersDetailsResource/types.ts
0.00% <0.00%> (ø)

...ayers_in_area/atoms/areaLayersLegendsAndSources.ts
0.00% <0.00%> (ø)

src/core/shared_state/focusedGeometry.ts
61.05% <100.00%> (ø)


Exit early and don't eat logs if the target key doesn't exist

As mentioned in https://github.com/fluent-plugins-nursery/fluent-plugin-concat/issues/42

Thanks!


Double fractional scaling for dpi-aware apps

The foot terminal emulator recently implemented fractional scaling.  With two monitors of different physical dimensions and hyprland set to scale them each at 1.0, foot now changes its font size to look identical on each screen - but other apps are too small as they can't do this trick.
If hyprland is set to scale the physically smaller monitor higher than 1.0, it appears that both foot and hyprland apply scaling and it ends up too big.
I am not sure if it's possible for hyprland or foot, or any other wayland app, to be aware of eachothers' dpi awareness capabilities, but it would be cool to be able to run in a mixed mode where the compositor is scaling apps that are not dpi-aware while apps that can do it on their own are allowed to do so.

sounds like a foot bug? It should take the scale into account

if you want to know that, this is the thing to read: https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/protocol/wayland.xml


Create unique quicky pm2 ids for apps

If a user is using PM2 for other things already in their VPS and if they want to uninstall this, there would be problems due to it is closing all pm2 instances when uninstalling. I created an id system for every exec and only stop them when uninstalling.

🔥 Great catch! Updated the code to use the repository name as the main identifier for stopping and deleting PM2 instances managed by Quicky.
Instead of relying on unique PM2 IDs, we leverage the uniqueness of the repo name to manage instances efficiently! 🚀


Does training resume from last saved checkpoint?

When training is interrupted and later resumed, I expect the process to restart from the last saved checkpoint iteration. However, even when specifying the same --checkpoint_dir flag, the training process restarts from iteration 0, disregarding previously completed iterations.
I tried:

Start training with a specified --checkpoint_dir.
Allow the training to proceed past a few iterations (e.g., 12 iterations).
Interrupt the training process.
Resume training with the same --checkpoint_dir flag.

I expected the training to resume from iteration 13, considering the last completed iteration was 12. However, the training restarts from iteration 1, ignoring the checkpoints saved in the specified directory.
Inside run_learner of main_loop.py, the checkpointing and iteration logging logic seems correct. However, I cannot find where the code loads the checkpoint to resume training from the last saved state.
# Start training
for iteration in range(1, num_iterations + 1):
    logging.info(f'Training iteration {iteration}')
    logging.info(f'Starting {learner.agent_name} ...')

    # Update shared iteration count.
    iteration_count.value = iteration

    # Set start training event.
    start_iteration_event.set()
    learner.reset()

    run_learner_loop(learner, data_queue, num_actors, learner_trackers)

    start_iteration_event.clear()
    checkpoint.set_iteration(iteration)
    saved_ckpt = checkpoint.save()

    if saved_ckpt:
        logging.info(f'New checkpoint created at "{saved_ckpt}"')

Hi, currently the training scripts does not support resume training. As you can see from the code, the --checkpoint_dir argument just specify the path to save model checkpoints, it will not looking for some existing checkpoint to continue training.
You should be able to adapt the code to add the logic to looking for latest model checkpoint if required, here's an example of manually loading checkpoint file in the eval_agent.py module.
    if FLAGS.load_checkpoint_file:
        checkpoint.restore(FLAGS.load_checkpoint_file)

However, keep in mind, the code will only save model state, not optimizer or the agent internal states (number of updates etc.), and also need to correctly handle logging to tensorboard or the csv files.


read tar file by requested block

Problem
An .tar file is entirely read during BlockReader::read_block_FileTar.
This may cause problems for very large compressed files (the s4 program will have the entire unarchived file in memory; it will use too much memory).
This is due to design of the tar crate. The crate does not provide a method to store tar::Archive<File> instance and tar::Entry<'a, R: 'a + Read> instance due to inter-instance references and explicit lifetimes.  (or is prohibitively complex; I made many attempts using various strategies involving references, lifetimes, pointers, etc.)
A tar::Entry holds a reference to data within the tar::Archive<File>. I found it impossible to store both related instances during new() or read_block_FileTar() and then later, during another call to read_block_FileTar(), utilize the same tar::Entry.
A new tar::Entry could be created per call to read_block_FileTar().  But then to read the requested BlockOffset, the entire .tar file entry would have to re-read.  This means reading an entire file entry within a .tar file would be an O(n^2) algorithm.
Solution
Read an .tar file per block request, as done for normal files.

Similar problem as Issue #12.

Current code https://github.com/jtmoon79/super-speedy-syslog-searcher/blob/0.0.32/src/readers/blockreader.rs#L2012-L2032
Uses https://github.com/alexcrichton/tar-rs/releases/tag/0.4.38

See solution idea in https://github.com/jtmoon79/super-speedy-syslog-searcher/issues/12#issuecomment-2016681186

Not relevant after #283

What is wanted is to create an tar::Entry and later make calls to Entry.read_exact.
Creating an tar::Entry requires creating tar::Archive<File>, tar::Entries<File>, tar::Entry<'a, File>. But this is greatly complicated in that tar::Entry is borrowing tar::Archive and also the tar::Entry is derived from the tar::Entries. So AFAICT, a later call to Entry.read_exact requires all three instances must remain in existence.
Here are the permutation of technical approaches I have tried:

storing a Box<...>
storing a Pin<Box<...>>; this was to avoid an error of the Archive becoming overwritten

storing the same but using unsafe blocks to read from Entry; Entry instance became corrupted

using thread_local! (lazy_static! requires Sync and Send to be implemented)
forcibly allocating on the heap with the help of the copyless crate; this was to attempt to avoid lifetime problem of Archive
storing Archive, Entries, Entry in a struct and annotating with ouroboros::self_referencing; ouroboros macros did not like the < symbol in the T

trying the same with self_cell::self_cell

trying Serialize, Deserialize from crate serde; tar::Archive does not support Sync and Send

Again, I tried many permutations of all of the prior.

The closest I got was
use std::env;
use std::io::prelude::*;
use std::fs::File;
use std::cell::RefCell;
use std::ops::DerefMut;
use std::pin::Pin;
use ::copyless;

use ::tar::Archive;
use ::tar::Entries;
use ::tar::Entry;

std::thread_local! {
    static MyArchive4: RefCell<Option<Box<Archive<File>>>> = {
        eprintln!("thread_local! MyArchive4");
        RefCell::new(None)
    };
    static MyEntry4: RefCell<Option<Box<Entry<'static, File>>>> = {
        eprintln!("thread_local! MyEntry4");
        RefCell::new(None)
    };
    static MyEntries4: RefCell<Option<Box<Entries<'static, File>>>> = {
        eprintln!("thread_local! MyEntries4");
        RefCell::new(None)
    };
}
fn main() {
    let args: Vec<String> = env::args().collect();
    let filename = &args[1];

    MyArchive4.with(|rca| {
        let file: File = File::open(filename).unwrap();
        unsafe {
            // https://stackoverflow.com/a/59368947/471376
            // forcibly allocate on the heap
            let mut bx = <Box<Archive<File>> as copyless::BoxHelper<Archive<File>>>::alloc();
            rca.borrow_mut().replace(
                copyless::BoxAllocation::init(
                    bx,
                    Archive::<File>::new(file)
                )
            );
        }
        MyEntries4.with(|rces| {
            unsafe {
                let mut bx = <Box<Entries<'_, File>> as copyless::BoxHelper<Entries<'_, File>>>::alloc();
                MyEntry4.with(|rce| {
                    let mut bx = <Box<Entry<'_, File>> as copyless::BoxHelper<Entry<'_, File>>>::alloc();
                    rce.borrow_mut().replace(
                        copyless::BoxAllocation::init(
                            bx,
                            rca.borrow_mut().as_mut().unwrap().entries().unwrap().nth(0).unwrap().unwrap()
                        )
                    );
                });
            }
        });
    });
}

but this results in error
298 |     MyArchive4.with(|rca| {
    |                      ---
    |                      |
    |                      `rca` is a reference that is only valid in the closure body
    |                      has type `&'1 RefCell<Option<Box<Archive<std::fs::File>>>>`
...
333 |                             rca.borrow_mut().as_mut().unwrap().entries().unwrap().nth(0).unwrap().unwrap()
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |                             |
    |                             `rca` escapes the closure body here
    |                             argument requires that `'1` must outlive `'static`


how to disable yocto pi 4 64bit x11 in sleep mode or cpu in sleep mode ?

hi all,
sorry to bother you.
I add IMAGE_FEATURES += "x11" to my local.conf in yocto,
so I use x11 for my pi 4 touchscreen to display the chromium webpage, but after some hours, the chromium webpage become blank(white), after touch and move finger from right to left, it comes to normal display,   it seems  that  1. CPU  was in sleep mode 2. x11 or chrmoum was in sleep mode.
the most possibility is x11 was in sleep mode
before I play maaxboard wayland, I know where I can set wayland sleep time.
but I do not know where I can disable 1. CPU sleep mode; 2 x11 sleep mode?
or some other reasons to make the chrome webpage is white blank?
any help?
Thank you very much.

Your issue is not BSP specific - at least that's how it sounds to me. I've moved to Wayland for a good while. If I remember correctly there were two features in x11: screen blanking and screen saving. And both were configurable through xset. That's what I remember now but I'm going to close this issue and let you figure it out as a distro configuration functionality.


Publish the type definition file to @types organization on npm

With TypeScript 2.0, the recommended way to install type definitions is like this:
npm install --save @types/oidc-client
npm install --save @types/oidc-client-js

See: https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html
See also: https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/
You have already added the types to the NPM package, it would be great also to have them in the @types organization repository.

what's the status on this?

The status is that it would be nice to have this complete. I'm happy to take ownership of this issue if you'd like me to do that.

yes, please do

Related commit to definitely typed: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/13116. Let me know if you have questions.

If a package bundles its own types, we do not recommend using an @types package.

@andy-ms The accepted PR to definitely typed says this:

Add oidc-client-js to not needed packages
The emphasis is on not needed. Does that make sense?

The PR to definitely typed adds to the list of not needed packages. Does that make sense?

I guess we could have called it notNeededAnyLongerPackages.json. We are also updating the pull request template to more forcefully tell people not to do this. DefinitelyTyped/DefinitelyTyped#13448

@andy-ms Let me see if I understand correctly. If a package bundles its own types:

do not publish an @types package,
do not add the package to the list of not need packages in definitely typed.

Am I understanding correctly now?

BTW @shaunluttin once this is all sorted, you will be the official PM for typings for this project :)

Exactly. You don't have to "register" your package anywhere, you can just publish it on your own and you're good to go.

@brockallen Yes. I would be happy to manage the typings for this project.

@shaunluttin , I just upgraded oidc-client to 1.3.0 but for some reason visual studio is acting like the typing are not part of the oidc package.

How did you install the typings for oidc-client?

Hi @crh225. Apologies for the slow response. It's been quite some time since I have looked at this. If I recall correctly, the types do not need installation, because they come with the oidc-client. Since time is short right now, I can point you in the direction of this demo: https://github.com/shaunluttin/aurelia-open-id-connect. Please ping me again if that does not illuminate this for you. Best, Shaun


Clarify that Azure needs trailing slack in Firezone configs too

Closes #1492

Pull Request Test Coverage Report for Build e720799be956ae7da378b883288b218b40ef3f3c-PR-1496

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

Totals

Change from base Build 08ef4518b45a92dc4caf126da7cc9bb7c70515f6:
0.0%

Covered Lines:
1690

Relevant Lines:
2526

💛  - Coveralls


Crop meshes

Include option to crop meshes to bounding box.

Throw away regions?
Jagged edges?

Current interface:
from nanomesh.data import blob_mesh3d
mesh = blob_mesh2d()
triangles = mesh.get('triangle')
triangles.crop(xmax=10)
triangles.plot()

from nanomesh.data import blob_mesh3d
mesh = blob_mesh3d()
tetras = mesh.get('tetra')
tetras.crop(xmax=10)
tetras.plot()


Added Rocket Image as asked in Issue #11

Hello! Thank you for your contribuition.
This issue was solved at #14
Check out our other issues for new challenges! thanks for your understanding!


correct an oversight in ++nest:ut (mismatch with jet)

@cgyarvin this is kosher, right? If it is, let's get it merged.

Yeah, I thought that was merged already.
On Fri, Feb 16, 2018 at 12:50 PM, Ted Blackman<EMAIL_ADDRESS>wrote:

@cgyarvin https://github.com/cgyarvin this is kosher, right? If it is,
let's get it merged.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/417#issuecomment-366354519, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALyAUKxd0AugmYzL__E578-TP_6z2aqks5tVeoJgaJpZM4OxaF1
.


Add Russian SuperGLUE

Hi,
This adds the Russian SuperGLUE dataset. For the most part I reused the code for the original SuperGLUE, although there are some relatively minor differences in the structure that I accounted for.

Added the missing label classes and their explanations (to the best of my understanding)

Thanks a lot ! Once the last comment about the label names is addressed we can merge :)


Unable to use SSO with redirect URL pointing to a Ingress https URL

ArgoWorkflow version 2.9.4
Issue:
when we try to access the argo workflow url and try to login we are getting below error:
failed to verify token: failed to verify signature: fetching keys oidc: failed to decode keys: expected Content-Type = application/json, got "application/jwk-set+json": illegal base64 data at input byte 43 {
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "e": "AQAB",
      "kid": "kdMGsVSWsregfrtgrtggHbs8vy",
      "use": "sig",
      "n": "2lndfggggdxrKs836yrbdIWOCWzQ4P0ieNr0HEyYC8zfc2HfatPJkjQtbZBua9ylq6NoP-wAql8JgItwAcPUJLztD5LQ2BET-TWgV5xrRMgrAhU6MbVRi4E8JertregregjqrLu-U2kCHKeK5ouBloinvQyTAdGzfFUc8afefserfjYOXRxsl5CxpQGUQrFQfmtgIhlr1Z-dsqyc6n9l94lzpdfgf8OOK8b1LeFxIC7nrO2oidQ",
      "x5t#S256": "duWB_-0jRqu_mxx4pH4cgffrgr4t4q1i6X5GA="
    }
  ]
}

Steps followed:
When deploying Argo Workflow we have updated the configmap with the SSO credentials / details like
 config: "containerRuntimeExecutor: kubelet  \nartifactRepository:\n  archiveLogs:
    true\n  s3:\n    accessKeySecret:\n      key: accesskey\n      name: argo-s3-creds\n
    \   secretKeySecret:\n      key: secretkey\n      name: argo-s3-creds\n    bucket:
    \"argo-workflow-bucket-15987261\"\n    endpoint: \"s3.us-staage.appdomain.cloud\"\n
    \   insecure: true\nsso:\n  clientId:\n    key: client.ID\n    name: argo-oidc-creds\n
    \ clientSecret:\n    key: client.Secret\n    name: argo-oidc-creds\n  issuer:
    \"https://test1.xyz.com\"\n  redirectUrl: \"https://devops-argoworkflow.xyz.com/oauth2/callback\"\n"

Also we have updated the deployment YAML file if argo-server to below details so that it is by default enabled to SSO auth-mode.
containers:
      - args:
        - server
        - --auth-mode
        - sso
        image: argoproj/argocli:v2.9.3
        imagePullPolicy: IfNotPresent
        name: argo-server

At the deployment time we are setting the Ingress with TLS certificate for this instance and use this as the redirect URL in the SSO configuration configmap as above.

It is unclear when this error is happening. Can I ask:

Are you using an ingress? Are you using BASE_HREF or and reverse proxy?
Which actual request fails? Can you provide the HTTP request logs from you browser network console?

@alexec
Thanks for the reply.
Yes we are using ingress and here is the ingress yaml file
`
apiVersion: v1
items:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
labels:
chart: argo-0.9.9
heritage: Tiller
release: argo
name: argo-server
namespace: argo
spec:
rules:

host: devops-argoworkflow.xyz.com
http:
paths:

backend:
serviceName: argo-server
servicePort: 2746
tls:

hosts:

devops-argoworkflow.xyz.com
secretName: mysecrets-tls
kind: List
metadata:
resourceVersion: ""
selfLink: ""
`

Logs from Network console:
Request:
Request URL: https://devops-argoworkflow.xyz.com/oauth2/callback?code=5f21a40da950c39343877a1aba&state=IXLcjas224Ft&nonce=&redirect_uri=https://devops-argoworkflow.xyz.com/oauth2/callback Request Method: GET Status Code: 401 Unauthorized Remote Address: <IP_ADDRESS>:443 Referrer Policy: no-referrer-when-downgrade
Response:
failed to verify token: failed to verify signature: fetching keys oidc: failed to decode keys: expected Content-Type = application/json, got "application/jwk-set+json": illegal base64 data at input byte 43 {  "keys": [     {       "kty": "RSA",       "alg": "RS256",       "e": "AQAB",       "kid": "kdMGsVSWsregfrtgrtggHbs8vy",       "use": "sig",       "n": "2lndfggggdxrKs836yrbdIWOCWzQ4P0ieNr0HEyYC8zfc2HfatPJkjQtbZBua9ylq6NoP-wAql8JgItwAcPUJLztD5LQ2BET-TWgV5xrRMgrAhU6MbVRi4E8JertregregjqrLu-U2kCHKeK5ouBloinvQyTAdGzfFUc8afefserfjYOXRxsl5CxpQGUQrFQfmtgIhlr1Z-dsqyc6n9l94lzpdfgf8OOK8b1LeFxIC7nrO2oidQ",       "x5t#S256": "duWB_-0jRqu_mxx4pH4cgffrgr4t4q1i6X5GA="     }   ] }

There is a lot of moving parts here. The "failed to verify token" error comes because the id_token cannot be verified, specifically because the content-type is "application/jwk-set+json" and must be "application/json".
https://github.com/coreos/go-oidc/blob/v2/oidc.go#L415
Can you contact your OIDC provider (are you using Auth0?) and determine why they are sending this content type please?

@alexec our OIDC provider supports the JWK-set+json following these standards - https://tools.ietf.org/html/rfc7517
Does Argo workflow also follow the same.


Does SAM supports cloudfront distribution for an S3 bucket ?

Hi,
I want to create a cloudfront distribution for an S3 bucket through SAM . My CFN template is like this
{
    "AWSTemplateFormatVersion" : "2010-09-09",
    "Resources" : {
        "myDistribution" : {
            "Type" : "AWS::CloudFront::Distribution",
            "Properties" : {
                "DistributionConfig" : {
                    "Origins" : [ {
                        "DomainName" : "test-folder.s3.amazonaws.com",
                        "Id" : "S3-test-folder",
                        "S3OriginConfig" : {
                            "OriginAccessIdentity" : "origin-access-identity/cloudfront/xxxxxxxxx"
                        }
                    }],
                    "Enabled" : "true",
                    "DefaultCacheBehavior" : {
					  "CachedMethods" : [ "GET", "HEAD" ],
					  "Compress" : "false",
					  "FieldLevelEncryptionId" : "",
					  "SmoothStreaming" : "false",
					  "ForwardedValues" : {
                            "QueryString" : "false",
                            "Cookies" : { "Forward" : "none" }
                        },
                        "AllowedMethods" : [ "GET", "HEAD" ],
                        "TargetOriginId" : "S3-test-folder",
						"DefaultTTL" : 5,
                        "ViewerProtocolPolicy" : "redirect-to-https"
                    },
				   "IPV6Enabled" : "true",
                   "PriceClass" : "PriceClass_All",
                   "ViewerCertificate" : { "CloudFrontDefaultCertificate" : "true" }
                }
            }
        }
    },
"Outputs" : {
  "StackVPC" : {
    "Description" : "Value",
    "Value" : { "Fn::GetAtt" : [ "myDistribution" , "DomainName"] }
  }
}
}

Does SAM supports cloudfront distriubtion ? I had searched in examples directory but find any examples for that.
Question

Can i mix SAM with CFN resources ? Because some resources are not supported by SAM .

Any help is appreciated
Thanks

Yes, you can mix SAM+CloudFormation. We are also discussing adding native support in #624

Thanks @brettstack . I see #624 in requirements gathering state .  Is there any example cloudfront distribution template for reference like we have a lot other in examples directory ?

No we don't have any examples since it's not a SAM resource yet. Looks like you already have the foundation of what you need in your example though


eyeWidenLeft/eyeWidenRight/noseSneerLeft/noseSneerRight blendshapes are always near 0

Have I written custom code (as opposed to using a stock example script provided in MediaPipe)
None
OS Platform and Distribution
Python 3.9 (Windows)
Mobile device if the issue happens on mobile device
No response
Browser and version if the issue happens on browser
No response
Programming Language and version
Python
MediaPipe version
No response
Bazel version
No response
Solution
Face Landmarks
Android Studio, NDK, SDK versions (if issue is related to building in Android environment)
No response
Xcode & Tulsi version (if issue is related to building for iOS)
No response
Describe the actual behavior
Similar to #4436, I was not able to make any of those blendshapes value greater than 0.05.

Describe the expected behaviour
These blendshapes should have values greater than 0.05 when I sneer my nose / raise my eyebrows.

Standalone code/steps you may have used to try to get what you need
Official Python example code can reproduce this issue.

Other info / Complete Logs
This could be a problem with the diversity of the model's training data (I am an Asian male).

Unfortunately this is still a major issue that noticeably decreases the quality of  blendshapes face landmarker returns. The landmarks are great, but a large amount of blendshapes are inaccurate or barely go above 0 :/


Make activation and signal updates one and the same

This replaces the existing invalidation algorithm with a much simpler one that always recurses upwards from bottom to top. It avoids a bunch of ordering issues that we were running into with the previous algorithm and it's shorter too.
Also kudos to @jviide for sending me various gists that made it click for me!
Fixes #124 .

Changed the implementation a bit to track dependencies in arrays instead of Map because the Map version was noticeably slower. With the switch to arrays it's on par with the code in main and in my crude tests slightly faster (about ~100ms) when stress testing.
There are some remaining tests in the adapters that are currently failing that I need to address.

Ok, doing some more checks the code in this PR is actually quite a bit faster than in main. In raw stress testing creation of computed signals and triggering one update it's about 1.4x faster

Closing as this PR will be replaced by #136 .


Unable to authenticate with keycloak oidc

Describe the bug: (a clear and concise description of what the bug is)
I cannot authenticate with keycloak
To Reproduce
Steps to reproduce the behavior:

Go to otomi login page and login with oidc

Input credentials and follow login instructions

Observe error page "We are sorry... An internal server error has occurred"

See error

Expected behavior: (a clear and concise description of what you expected to happen)
I can login
Screenshots: (if applicable, add screenshots to help explain your problem)
Cluster(s):

Cloud: azure
Cluster: dta

Versions: (seen in console's /settings)

Core Version: 0.11.53

Additional context: (add any other context about the problem here)
Error from keycloak container:
07:52:54,252 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) SQL Error: 0, SQLState: 23505
07:52:54,252 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-12) ERROR: duplicate key value violates unique constraint "uk_ru8tt6t700s9v50bu18ws5ha6"
  Detail: Key (realm_id, username)=(master,  ) already exists.

From the logs keycloak parses username as an empty string and that may be the reason of login error

This issue may be related with: https://github.com/redkubes/otomi-core/issues/210

Can you confirm this is related to #210 @rawc0der ?

Can you confirm this is related to #210 @rawc0der ?

@rawc0der ??

Yes,
This is related to #210 and I am trying to figure a different solution out in my local cluster.
The User Registration process is working first time only and does not allow re-registration of existing users. This happens when IDP entry is "replaced" and corrupts internal objects state.
A temp fix is to delete PVC for keycloak-postgress pod and sync the keycloak and keycloak-jobs releases.

I think have already solved that issue yesterday and implementation
has been done as well.
@Morriz @rawc0der can I close this issue ?

I think have already solved that issue yesterday and implementation
has been done as well.
@Morriz @rawc0der can I close this issue ?

Yes, this issue is fixed, but #210 is still under the radar.

Yes, this issue is fixed, but #210 is still under the radar.


evcc.dist.yaml: linted version

Ich habe meine evcc Entwicklungs-Configs mal über yamllint laufen lassen, um sie sauber zu strukturieren.

Die Version hier im PR wirft keine Meldungen mehr aus.
Ist evtl. auch Tip für Einsteiger, die Probleme mit dem Erstellen ihrer ersten evcc.yaml haben.
xxxx@xxxx:~/evcc/git/evcc$ yamllint ./evcc.dist.yaml
./evcc.dist.yaml
  1:1       warning  missing document start "---"  (document-start)
  1:19      warning  too few spaces before comment  (comments)
  2:15      warning  too few spaces before comment  (comments)
  15:81     error    line too long (97 > 80 characters)  (line-length)
  18:1      error    wrong indentation: expected 2 but found 0  (indentation)
  20:14     warning  too few spaces before comment  (comments)
  22:13     warning  too few spaces before comment  (comments)
  24:16     warning  too few spaces before comment  (comments)
  25:15     warning  too few spaces before comment  (comments)
  34:81     error    line too long (86 > 80 characters)  (line-length)
  37:1      error    wrong indentation: expected 2 but found 0  (indentation)
  38:16     warning  too few spaces before comment  (comments)
  39:24     warning  too few spaces before comment  (comments)
  44:81     error    line too long (88 > 80 characters)  (line-length)
  47:1      error    wrong indentation: expected 2 but found 0  (indentation)
  50:16     warning  too few spaces before comment  (comments)
  51:9      warning  too few spaces before comment  (comments)
  52:13     warning  too few spaces before comment  (comments)
  58:15     warning  too few spaces before comment  (comments)
  60:16     warning  too few spaces before comment  (comments)
  61:12     warning  too few spaces before comment  (comments)
  62:22     warning  too few spaces before comment  (comments)
  63:19     warning  too few spaces before comment  (comments)
  67:1      error    wrong indentation: expected 2 but found 0  (indentation)
  67:17     warning  too few spaces before comment  (comments)
  68:19     warning  too few spaces before comment  (comments)
  70:20     warning  too few spaces before comment  (comments)
  78:81     error    line too long (94 > 80 characters)  (line-length)
  79:81     error    line too long (85 > 80 characters)  (line-length)
  82:81     error    line too long (87 > 80 characters)  (line-length)
  83:81     error    line too long (98 > 80 characters)  (line-length)
  84:81     error    line too long (98 > 80 characters)  (line-length)
  86:81     error    line too long (85 > 80 characters)  (line-length)
  88:12     warning  too few spaces before comment  (comments)
  89:17     warning  too few spaces before comment  (comments)
  90:21     warning  too few spaces before comment  (comments)
  91:17     warning  too few spaces before comment  (comments)
  92:14     warning  too few spaces before comment  (comments)
  93:20     warning  too few spaces before comment  (comments)
  94:13     warning  too few spaces before comment  (comments)
  95:11     warning  too few spaces before comment  (comments)
  96:15     warning  too few spaces before comment  (comments)
  97:18     warning  too few spaces before comment  (comments)
  97:81     error    line too long (103 > 80 characters)  (line-length)
  98:12     warning  too few spaces before comment  (comments)
  99:16     warning  too few spaces before comment  (comments)
  100:20    warning  too few spaces before comment  (comments)
  101:21    warning  too few spaces before comment  (comments)
  101:81    error    line too long (85 > 80 characters)  (line-length)
  102:17    warning  too few spaces before comment  (comments)
  103:18    warning  too few spaces before comment  (comments)
  107:3     warning  comment not indented like content  (comments-indentation)
  114:3     warning  comment not indented like content  (comments-indentation)
  122:12    warning  too few spaces before comment  (comments)
  125:11    warning  too few spaces before comment  (comments)
  128:14    warning  too few spaces before comment  (comments)
  131:17    warning  too few spaces before comment  (comments)
  144:81    error    line too long (86 > 80 characters)  (line-length)

Hm, jetzt verstehe ich die Meldung hier in der fehlgeschlagenen Schema Validation nicht:  :-(
/home/runner/work/evcc/evcc/evcc.dist.yaml
[{"range":{"start":{"line":79,"character":8},"end":{"line":79,"character":8}},"message":"Incorrect type. Expected \"object\".","severity":2,"source":"yaml-schema: EVCC configuration schema"}]
evcc.dist.yaml

Ich würde das Ganze einfach lassen. Der yamllinter ist "opinionated".

OK


Add to dotnet tools repo

Suggestion: Add to https://github.com/natemcmaster/dotnet-tools

@lindexi Thanks for your suggestion
The PR created.
https://github.com/natemcmaster/dotnet-tools/pull/191

PR accepted


Calling declared(params) from child namespace fails to include parent namespace defined params

The test in this PR highlights the problem as described in the subject.
The docs seem to suggest that a params block defined against resource in this way should apply to every method within the resource(/namespace)
Hence the expectation that a call to declared(params) should include the param defined against the resource.
Does this make sense? Hopefully the test does!

Changes Unknown when pulling 739c131cad278c6ae4890cc098f48a68ef03a5e7 on myitcv:nested_declared_usage into ** on intridea:master**.


Pytest caplog workaround

Fixes some temporary errors in the tests

Codecov Report

Merging #155 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #155   +/-   ##
=======================================
  Coverage   93.97%   93.98%
=======================================
  Files          62       62
  Lines        5825     5831    +6
=======================================
+ Hits         5474     5480    +6
  Misses        351      351

Impacted Files
Coverage Δ

stix2validator/test/v20/misc_tests.py
100.00% <100.00%> (ø)

stix2validator/test/v21/misc_tests.py
100.00% <100.00%> (ø)

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 2cb4873...e8cc1a0. Read the comment docs.


x/mobile: stack traces are wrong on iOS

What version of Go are you using (go version)?
go version devel +4f178d157d Fri Oct 20 13:59:37 2017 +0000 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/steeve/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.9.1/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.9.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bs/51dlb_nn5k35xq9qfsxv9wc00000gr/T/go-build785508759=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?
Bind an iOS framework using gomobile bind and create a panic.
What did you expect to see?
The real stack trace.
What did you see instead?
As commented in https://github.com/golang/go/issues/20392#issuecomment-344102319:
# Crashlytics - plaintext stacktrace downloaded by Steeve Morin at Tue, 14 Nov 2017 00:11:12 GMT
# Platform: ios
# Application: testapp-swift
# Version: 1.0 (1)
# Issue #: 2
# Issue ID: 591c99d0be077a4dccdaf367
# Session ID: e591a6fc5b8641d8b4571ce7df6c11f4_4c0f40a1c8d011e7a1bd56847afe9799_0_v2
# Date: 2017-11-14T00:10:00Z
# OS Version: 11.1.1 (15B150)
# Device: iPhone X
# RAM Free: 7.2%
# Disk Free: 69.1%

#0. Crashed: com.apple.main-thread
0  testapp-swift                  0x1048d5798 runtime.raiseproc + 24
1  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
2  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
3  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
4  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
5  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
6  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
7  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
8  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
9  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
10 testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60

--

#0. Crashed: com.apple.main-thread
0  testapp-swift                  0x1048d5798 runtime.raiseproc + 24
1  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
2  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
3  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
4  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
5  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
6  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
7  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
8  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
9  testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60
10 testapp-swift                  0x1048c1fdc runtime.dieFromSignal + 60

#1. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#2. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d76fa0 _pthread_wqthread + 884
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#3. Thread
0  libsystem_pthread.dylib        0x183d76c1c start_wqthread + 122

#4. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d77134 _pthread_wqthread + 1288
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#5. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d77134 _pthread_wqthread + 1288
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#6. com.apple.uikit.eventfetch-thread
0  libsystem_kernel.dylib         0x183c44bc4 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x183c44a3c mach_msg + 72
2  CoreFoundation                 0x1840f5c74 __CFRunLoopServiceMachPort + 196
3  CoreFoundation                 0x1840f3840 __CFRunLoopRun + 1424
4  CoreFoundation                 0x184013fb8 CFRunLoopRunSpecific + 436
5  Foundation                     0x184a3d6e4 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 304
6  Foundation                     0x184a5cafc -[NSRunLoop(NSRunLoop) runUntilDate:] + 96
7  UIKit                          0x18e1472f4 -[UIEventFetcher threadMain] + 136
8  Foundation                     0x184b3e860 __NSThread__start__ + 996
9  libsystem_pthread.dylib        0x183d7831c _pthread_body + 308
10 libsystem_pthread.dylib        0x183d781e8 _pthread_body + 310
11 libsystem_pthread.dylib        0x183d76c28 thread_start + 4

#7. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d76fa0 _pthread_wqthread + 884
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#8. Thread
0  testapp-swift                  0x1048d5b44 runtime.mach_semaphore_timedwait + 20
1  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
2  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
3  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
4  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
5  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
6  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
7  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
8  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
9  testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192
10 testapp-swift                  0x1048ac5e0 runtime.semasleep1 + 192

#9. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#10. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#11. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#12. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#13. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#14. Thread
0  testapp-swift                  0x1048d5b1c runtime.mach_semaphore_wait + 12
1  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
2  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
3  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
4  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
5  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
6  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
7  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
8  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
9  testapp-swift                  0x1048ac55c runtime.semasleep1 + 60
10 testapp-swift                  0x1048ac55c runtime.semasleep1 + 60

#15. com.twitter.crashlytics.ios.MachExceptionServer
0  libsystem_kernel.dylib         0x183c44bc4 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x183c44a3c mach_msg + 72
2  testapp-swift                  0x104918aa4 CLSMachExceptionServer + 100
3  libsystem_pthread.dylib        0x183d7831c _pthread_body + 308
4  libsystem_pthread.dylib        0x183d781e8 _pthread_body + 310
5  libsystem_pthread.dylib        0x183d76c28 thread_start + 4

#16. Thread
0  libsystem_kernel.dylib         0x183c65dbc __workq_kernreturn + 8
1  libsystem_pthread.dylib        0x183d77134 _pthread_wqthread + 1288
2  libsystem_pthread.dylib        0x183d76c20 start_wqthread + 4

#17. com.apple.NSURLConnectionLoader
0  libsystem_kernel.dylib         0x183c44bc4 mach_msg_trap + 8
1  libsystem_kernel.dylib         0x183c44a3c mach_msg + 72
2  CoreFoundation                 0x1840f5c74 __CFRunLoopServiceMachPort + 196
3  CoreFoundation                 0x1840f3840 __CFRunLoopRun + 1424
4  CoreFoundation                 0x184013fb8 CFRunLoopRunSpecific + 436
5  CFNetwork                      0x18477e264 +[NSURLConnection(Loader) _resourceLoadLoop:] + 404
6  Foundation                     0x184b3e860 __NSThread__start__ + 996
7  libsystem_pthread.dylib        0x183d7831c _pthread_body + 308
8  libsystem_pthread.dylib        0x183d781e8 _pthread_body + 310
9  libsystem_pthread.dylib        0x183d76c28 thread_start + 4

cc @williamweixiao

Yes, a self-contained case is important for post mortem of the wrong stack traces.
As I know, frame-pointer is enabled on amd64 desktop platform (e.g. linux/amd64 and darwin/amd64) by default. If we can reproduce the failure on the platform we can rule out the problem with missing framepointers.

It occurred to me that there is a small chance that the crash logger is somehow confused by the DWARF information the Go compiler generates. Have you tried to crash log a binary compiled with -ldflags="-w" on a GOARCH with framepointers (amd64)?

hi, can you try the latest version of my patch (https://go-review.googlesource.com/c/go/+/61511) on darwin/arm64?

So I've spent more time and indeed, the DWARF on darwin/arm64, while there, is empty:
$  dwarfdump -a --arch=arm64 Adder.framework/Adder
----------------------------------------------------------------------
 File: Adder.framework/Adder(go.o) (arm64)
----------------------------------------------------------------------
.debug_abbrev contents:
< EMPTY >

.debug_aranges contents:
< EMPTY >

.debug_info contents:
< EMPTY >
.debug_inlined contents:
< EMPTY >
.debug_frame contents:
< EMPTY >

.debug_line contents:
< EMPTY >

.debug_macinfo contents:
< EMPTY >

.debug_pubnames contents:
< EMPTY >

.debug_pubtypes contents:
< EMPTY >

.apple_names contents:

.apple_types contents:

.apple_exttypes contents:

.apple_namespaces contents:

.apple_objc contents:

.debug_str contents:
< EMPTY >

Indeed this may be confusing the unwinder, however, as tested by @eliasnaur, removing it doesn't seem to make the situation better either with, or without frame pointers, at least on Darwin.

DWARF generation is completely disabled on darwin/arm and darwin/arm64. There's a
*ld.FlagW = true // disable DWARF generation
in cmd/link/internal/arm*/obj.go for objabi.Hdarwin. Removing that line for arm64 doesn't improve the Xcode backtrace in my informal crash test, however.

The problem of incomplete / incorrect the stack is because the stack seems to be modified between the start of the panic (runtime.gopanic), and the sigabort being raised (runtime.dieFromSignal).
On android using the lldb debugger:
Set a breakpoint in runtime.gopanic:
(lldb) b runtime.gopanic
Breakpoint 3: where = libgojni.so`runtime.gopanic + 20 at panic.go:427, address = 0x0000007bc84963a4
(lldb) c
Process 6570 resuming
(lldb) bt
* thread #1, name = 'ly.co.crashtest', stop reason = breakpoint 2.1 3.1
  * frame #0: 0x0000007bc84963a4 libgojni.so`runtime.gopanic(e=interface {} @ 0x0000004420048e78) at panic.go:427
    frame #1: 0x0000007bc84fe590 libgojni.so`github.com/znly/crashtest/crash.CrashPanic at crash.go:65
    frame #2: 0x0000007bc84ff9d8 libgojni.so`_/tmp/gomobile-work-050620269/gomobile_bind.proxycrash__CrashPanic at go_crashmain.go:41
    frame #3: 0x0000007bc84ff588 libgojni.so`_/tmp/gomobile-work-050620269/gomobile_bind._cgoexpwrap_25f17ada05be_proxycrash__CrashPanic at _cgo_gotypes.go:216
    frame #4: 0x0000007bc84bd18c libgojni.so`runtime.call32 at asm_arm64.s:411
    frame #5: 0x0000007bc8473360 libgojni.so`runtime.cgocallbackg1(ctxt=0x0000000000000000) at cgocall.go:316
    frame #6: 0x0000007bc84731a8 li
bgojni.so`runtime.cgocallbackg(ctxt=0x0000000000000000) at cgocall.go:194
    frame #7: 0x0000007bc84bef40 libgojni.so`runtime.cgocallback_gofunc at asm_arm64.s:642
    frame #8: 0x0000007bc84bf374 libgojni.so`runtime.goexit at asm_arm64.s:1037

From there the stack is correct. We can see the user code panicking in frame 1.
Continue, waiting for the debugger to catch the SIGABRT.
(lldb) c
Process 6570 resuming
(lldb) bt
* thread #1, name = 'ly.co.crashtest', stop reason = signal SIGABRT
  * frame #0: 0x0000007bc84bfca8 libgojni.so`runtime.raise at sys_linux_arm64.s:163
    frame #1: 0x0000007bc84aac1c libgojni.so`runtime.dieFromSignal(sig=6) at signal_unix.go:422
    frame #2: 0x0000007bc84aadc0 libgojni.so`runtime.crash at signal_unix.go:520
    frame #3: 0x0000007bc8497058 libgojni.so`runtime.dopanic_m(gp=0x0000004420000600, pc=0x0000007bc8496730, sp=0x0000004420048dd0) at panic.go:751
    frame #4: 0x0000007bc84bb980 libgojni.so`runtime.dopanic.func1 at panic.go:598
    frame #5: 0x0000007bc84bcdbc libgojni.so`runtime.systemstack at asm_arm64.s:229
    frame #6: 0x0000007bc849aed0 libgojni.so`runtime.startTheWorldWithSema(emitTraceEvent=false, ~r1=548874206800) at proc.go:1092

Now the stack doesn't show the user code anymore.
With a simple program that starts a goroutine and panic on linux/amd64, it looks like this and this is what one would expect:
* thread #2, name = 'crash', stop reason = signal SIGABRT
  * frame #0: crash`runtime.raise at sys_linux_amd64.s:159
    frame #1: crash`runtime.dieFromSignal(sig=6) at signal_unix.go:422
    frame #2: crash`runtime.crash at signal_unix.go:520
    frame #3: crash`runtime.dopanic_m(gp=0x000000c420132900, pc=0x0000000000426121, sp=0x000000c42012df10) at panic.go:751
    frame #4: crash`runtime.dopanic.func1 at panic.go:598
    frame #5: crash`runtime.systemstack at asm_amd64.s:409
    frame #6: crash at proc.go:1092
    frame #7: crash`runtime.crash at signal_unix.go:520
    frame #8: crash`runtime.dopanic_m(gp=0x000000c420132900, pc=0x0000000000426121, sp=0x000000c42012df10) at panic.go:751
    frame #9: crash`runtime.dopanic.func1 at panic.go:598
    frame #10: crash`runtime.systemstack at asm_amd64.s:409
    frame #11: crash at proc.go:1092
    frame #12: crash`runtime.dopanic_m(gp=0x000000c420132900, pc=0x0000000000426121, sp=0x000000c42012df10) at panic.go:751
    frame #13: crash`runtime.dopanic.func1 at panic.go:598
    frame #14: crash`runtime.systemstack at asm_amd64.s:409
    frame #15: crash at proc.go:1092
    frame #16: crash`runtime.dopanic.func1 at panic.go:598
    frame #17: crash`runtime.systemstack at asm_amd64.s:409
    frame #18: crash`runtime.systemstack at asm_amd64.s:409
    frame #19: crash at proc.go:1092
    frame #20: crash`runtime.gopanic(e=interface {} @ 0x000000c42012dfb0) at panic.go:551
    frame #21: crash`main.parentFunc1 at crash.go:18
    frame #22: crash`main.parentFunc2 at crash.go:14
    frame #23: crash`runtime.goexit at asm_amd64.s:2361
    frame #24: crash`main.parentFunc1 at crash.go:18
    frame #25: crash`main.parentFunc2 at crash.go:14
    frame #26: crash`runtime.goexit at asm_amd64.s:2361
    frame #27: crash`main.parentFunc2 at crash.go:14
    frame #28: crash`runtime.goexit at asm_amd64.s:2361
    frame #29: crash`runtime.goexit at asm_amd64.s:2361

Also the problem that shows everytime on android/arm64 can happen on linux/amd64 too:
lldb ./tmp/crash
(lldb) target create "./tmp/crash"
Current executable set to './tmp/crash' (x86_64).
(lldb) b runtime.gopanic
Breakpoint 1: where = crash`runtime.gopanic + 47 at panic.go:426, address = 0x000000000042523f
(lldb) run
Process 23097 launched: './tmp/crash' (x86_64)
Process 23097 stopped
* thread #10, stop reason = breakpoint 1.1
    frame #0: crash`runtime.gopanic(e=interface {} @ 0x000000c420045fb0) at panic.go:426
   423
   424     // The implementation of the predeclared function panic.
   425     func gopanic(e interface{}) {
-> 426         gp := getg()
   427         if gp.m.curg != gp {
   428             print("panic: ")
   429             printany(e)
(lldb) bt
* thread #10, stop reason = breakpoint 1.1
  * frame #0: crash`runtime.gopanic(e=interface {} @ 0x000000c420045fb0) at panic.go:426
    frame #1: crash`main.parentFunc1 at crash.go:18
    frame #2: crash`main.parentFunc2 at crash.go:14
    frame #3: crash`runtime.goexit at asm_amd64.s:2361
    frame #4: crash`main.parentFunc1 at crash.go:18
    frame #5: crash`main.parentFunc2 at crash.go:14
    frame #6: crash`runtime.goexit at asm_amd64.s:2361
    frame #7: crash`main.parentFunc2 at crash.go:14
    frame #8: crash`runtime.goexit at asm_amd64.s:2361
    frame #9: crash`runtime.goexit at asm_amd64.s:2361
* thread #2, name = 'crash', stop reason = signal SIGABRT
    frame #0: crash`runtime.raise at sys_linux_amd64.s:159
   156    MOVL  sig+0(FP), SI // arg 2
   157    MOVL  $SYS_tkill, AX
   158    SYSCALL
-> 159    RET
   160
   161  TEXT runtime·raiseproc(SB),NOSPLIT,$0
   162    MOVL  $SYS_getpid, AX
(lldb) bt
* thread #2, name = 'crash', stop reason = signal SIGABRT
  * frame #0: crash`runtime.raise at sys_linux_amd64.s:159
    frame #1: crash`runtime.dieFromSignal(sig=6) at signal_unix.go:422
    frame #2: crash`runtime.crash at signal_unix.go:520
    frame #3: crash`runtime.dopanic_m(gp=0x000000c420001080, pc=0x00000000004255d1, sp=0x000000c420045f10) at panic.go:751
    frame #4: crash`runtime.dopanic.func1 at panic.go:598
    frame #5: crash`runtime.systemstack at asm_amd64.s:409
    frame #6: crash at proc.go:1092
    frame #7: crash`runtime.crash at signal_unix.go:520
    frame #8: crash`runtime.dopanic_m(gp=0x000000c420001080, pc=0x00000000004255d1, sp=0x000000c420045f10) at panic.go:751

We can see that program even switched thread between the start of the panic and the raise of the signal.
I can't reproduce anymore but I recall the thread 2 where the goroutine panicked didn't had the panicking stack anymore and was blocked in runtime.futex.

Thanks, @gwik. Other than the platform difference (linux vs android), the other difference that comes to mind is the buildmode. Have you reproduced the wrong stack trace on android/arm64 (or android/arm) with a regular static binary outside the JVM? Conversely, are stack traces correct on linux/amd64 with a Go c-shared library loaded into a C main program?

@steeve @gwik with #24883 fixed, are stack traces on iOS acceptable? If so, please update this issue or start a new one with the Android specific problems.

@eliasnaur I'll do a check this afternoon (Paris time). Could you test by replacing the nil pointer with a good old panic() call ?
This might have other effects.

@eliasnaur thanks for making this happen, this is great news.

@aclements you did CL 93658 where a systemstack() is wrapping the dieFromSignal you see in the stack trace above. Is there a way to avoid that so the backtrace instead shows the correct call sequence leading to the panic()?

One might consider the value of actually printing the full stack trace to stderr in that scenario. Perhaps a new debug.SetTraceback value ?
From my user perspective, I'd be fine not having the stack trace printed at all in that scenario if it makes the LLDB backtraces good.
Ideally, a panic could make the debugger halt on the offending line. But I have no idea how to do that properly.


_load signature

What do you think about making Dataset._load() return an anndata instance rather than setting it in as an attribute the class? (it would then be set in _load_cached directly after, so no changes outside of this code) This would make it a lot more accessible to people with little experience with classes in python because it would be much closer even to a loading script.

+1 for this!

closed in #131


Fix param check of KeyGeneratorConfiguration

In KeyGeneratorConfigurationYamlSwapper.swap(final YamlKeyGeneratorConfiguration yamlConfiguration), check whether the type of keyGenerateAlgorithm is null.
In sharding.xsd, add use="required" on attribute column of element key-generator.

Pull Request Test Coverage Report for Build 10805

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 57.169%

Totals

Change from base Build 10803:
0.002%

Covered Lines:
11710

Relevant Lines:
20483

💛  - Coveralls


feat(translator): early request header modifier

What type of PR is this?

What this PR does / why we need it:
Adds support for early request header mutation in client traffic policy
Which issue(s) this PR fixes:
Fixes #3978

/retest

/retest