How to decode the depth map from the predicted depth map?

Hi,
I have a question regarding depth map decoding.
The number of predicted depth map's channels is 112, how can I transform it to continuous depth?

Please refer to https://github.com/Megvii-BaseDetection/BEVDepth/issues/58


refactor: bump CLI version to 13.3.0-rc.0

We won't actually be releasing an RC, but this is necessary for the release tool to understand that it will do a minor release from this branch.

Skipping CI here to start on the real 13.3.0 release, I'll run the full CI on that PR and we can handle any problems there.


Add awareness of the new simulator platform SDK

This PR fixes #52, which has the details of the problem.  It also updates the README instructions about XCode integration and fixes an old compiler warning.

Hi @TimNN, I believe this PR is ready for review.  cargo-lipo is still incredibly useful and this updates it to work well with Xcode 13 and the new rust-supported iPhone simulator ABI.

Hi @brotskydotcom, thanks for the PR! Just as a heads-up, I probably won't have the time to properly look at the PR until next weekend or the weekend after. Thanks for your patience!

No worries, @TimNN!  I want to do some more testing on Intel anyway, so I will probably make some changes before you have a chance to review.

Thanks, @TimNN, and no worries!  I'm updating the PR based on x64-based testing so one or two weeks from now is just fine, thanks!

Thank you for your patience! This looks good, with two nits:

Can you please add short explanation to the readme why the "delete Rust static libraries" step is necessary? (I assume it's because of the "can't include two arm64 targets in one archive" issue).

Can you please run rustfmt? (See also the failed CI checks, which are running now).

Also, I'm picking up your https://github.com/TimNN/cargo-lipo/pull/53/commits/0999f20250bb9ee09175d3a9ce1bd024081c0f2c in a separate PR to fix CI, the macos tests seem to need some maintenance.

Hi @TimNN, thanks for the review!  I've pushed a commit to fix both those issues.  By the way, you might be interested:

your claim that cargo-lipo in its current form shouldn't be needed for iOS integration is quite correct.  The trick of deleting the built library can be used (together with copying the correct pre-built library) to integrate cargo directly with Xcode.  I've provided a pointer in the updated README to a project that shows how to do this.
I had a real "face palm" moment when I saw your comment about running the rust formatter.  That's actually my default setting for all my projects, but while I was preparing this PR I was also working on iOS support for the rust-system-framework project, and the developers there don't like what the rust formatter does, so I had to turn it off.  Thanks for the reminder to turn it back on!

Thanks! I'll see about releasing a new version later today.


Improve the CIDR disjointedness check of shoot and seed network

How to categorize this issue?

/area networking
/kind bug
What happened:
Currently it is possible the create a shoot cluster with the IP ranges of shoot pods same as IP ranges of seed nodes, but this is not a correct configuration and the shoot will fail. The checks here are not complete: https://github.com/gardener/gardener/blob/4dde96a5994f181a998e59831aacdcaab8246b48/pkg/utils/validation/cidr/disjoint.go#L26-L71
What you expected to happen:
Gardener should have a check for that and should inform the user that such a configuration is not a possible.

/assign


UNFILED: added checks for series size results

can you commit against the jira ticket number in future?


ROX-25852: Sensor sends runtime configuration to collector

Description

Sends the collector config to collector when sensor receives a cluster config from central or a new collector comes online. The collector config is not yet a part of the cluster config, though the collector config will be added to the cluster config in the future. For testing purposes a fake collector config is sent to collector when sensor receives a cluster config from sensor.
The collector config is sent using the same gRPC channel as is used to send the CIDR blocks to collector, and collector uses to send networking information to sensor.
Note that all added logging is temporary and will be removed before merging.
User-facing documentation

[ ] CHANGELOG is updated OR update is not needed
[ ] documentation PR is created and is linked above OR is not needed

Testing and quality

[ ] the change is production ready: the change is GA or otherwise the functionality is gated by a feature flag
[ ] CI results are inspected

Automated testing

[ ] added unit tests
[ ] added e2e tests
[ ] added regression tests
[ ] added compatibility tests
[ ] modified existing tests

How I validated my change

Set ROX_COLLECTOR_RUNTIME_CONFIG to true. Deployed ACS to a gke cluster using deploy/deploy-local.sh. Used the logmein command to obtain the authorization token and set ROX_API_TOKEN. Built the version of collector at the jv-test-receiving-collector-config branch in the collector repository and pushed the image to quay.io/jvirtane/collector:3.19.x-103-ga308acf39c-dirty-. That version of collector has minimal changes to connect to sensor using the new Communicate function. Collector was made to use that image using ks edit ds collector. Obtained the cluster config using the cluster service and then sent back the same cluster config using the PUT endpoint in the cluster config service. Checked the sensor logs and found the following
common/collectorruntimeconfig: 2024/09/27 01:04:19.295905 handler.go:79: Info: In ProcessMessage for collector runtime config
common/collectorruntimeconfig: 2024/09/27 01:04:19.295974 handler.go:68: Info: Created fake collector config
common/collectorruntimeconfig: 2024/09/27 01:04:19.296017 handler.go:85: Info: Got collector config network_connection_config:{enable_external_ips:true}
common/collectorruntimeconfig: 2024/09/27 01:04:19.296053 handler.go:120: Info: In pushConfigToValueStream
common/compliance: 2024/09/27 01:04:38.141318 service_impl.go:221: Error: receiving from compliance "gke-jv-09-26-default-pool-e4b56824-x212": rpc error: code = Canceled desc = context canceled
common/signal: 2024/09/27 01:04:38.585976 signal_service.go:138: Error: error dequeueing signalStreamMsg event: rpc error: code = Canceled desc = context canceled
common/compliance: 2024/09/27 01:04:46.559032 service_impl.go:185: Info: Received connection from "gke-jv-09-26-default-pool-e4b56824-x212"
common/compliance: 2024/09/27 01:04:46.576736 service_impl.go:221: Error: receiving from compliance "gke-jv-09-26-default-pool-e4b56824-6x8d": rpc error: code = Canceled desc = context canceled
common/signal: 2024/09/27 01:04:47.483564 signal_service.go:138: Error: error dequeueing signalStreamMsg event: rpc error: code = Canceled desc = context canceled
common/networkflow/service: 2024/09/27 01:04:48.226702 service_impl.go:108: Info: In recevieMessage hostname= gke-jv-09-26-default-pool-e4b56824-x212
common/networkflow/service: 2024/09/27 01:04:48.228885 service_impl.go:149: Info: CollectorRuntimeConfig.Enabled()= true
common/networkflow/service: 2024/09/27 01:04:48.228928 service_impl.go:151: Info: CollectorRuntimeConfig is enabled
common/networkflow/service: 2024/09/27 01:04:48.229021 service_impl.go:291: Info: Sending collector config collector_config:{network_connection_config:{enable_external_ips:true}}

This shows that sensor received a cluster config and reached the point in the code at which the collector config is sent to collector. The version of collector used does not actually log the received collector configs, so it is not clear if it was correctly sent, but it seems very likely that it was.

The overall approach looks solid, and we’re heading in the right direction.
However, there are still a few open points I’d like to address:

I would appreciate a deeper understanding of your reasoning, along with the advantages and potential concerns for certain implementations. This will help me provide more informed feedback based on the project's needs. I’ve left comments on specific areas where I’m seeking clarification.
The changes in sensor/common/collectorruntimeconfig/handler.go are on the right track, but they seem to fall outside the scope of this PR. I recommend moving them to a separate one.

I will need to think about point number one more before giving a full answer. Mostly I copied the pattern of the implementation for sending CIDR blocks without a full understanding of why that implementation was chosen for CIDR blocks, what the advantages and disadvantages of it are, if those advantages and disadvantages apply to collector config, and what alternatives I might use. I was hoping to get help on these points from the reviewers.
For point number 2, I don't understand what the scope of this PR is if the handler is not within the scope of this PR. The collector config does not get sent to collector without the new handler, which is the goal of the PR. Do you mean that I should use the existing externalsrcs handler instead of creating a new one and then in a different PR separate out the handler for the collector config.


Error while running bcinsider.azurecr.io/bconprem:13.0.24573.0

Hey Guys,
I get following error while trying to run BC RC3 docker image:
docker run -e accept_eula=Y bcinsider.azurecr.io/bconprem:13.0.24573.0 -m 3G
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: container 35a1fa300bc955e2d7a6daf21702c7ae5862028985b54d29d79c0faee05109a1 encountered an error during CreateProcess: failure in a Windows system call: The system cannot find the file specified. (0x2) extra info: {"CommandLine":"-m 3G","WorkingDirectory":"C:\\","Environment":{"COMPLUS_NGenProtectedProcess_FeatureEnabled":"0","DatabaseInstance":"SQLEXPRESS","DatabaseName":"CRONUS","DatabaseServer":"localhost","NAVDVDURL":"https://nav2016wswe0.blob.core.windows.net/dvd/e561bfde-19bd-4242-b44e-77699ccd2879","VSIXURL":"https://nav2016wswe0.blob.core.windows.net/dvd/al-2.0.43900.vsix","accept_eula":"Y"},"CreateStdInPipe":true,"CreateStdOutPipe":true,"CreateStdErrPipe":true,"ConsoleSize":[0,0]}.
Any advice?
Best Regards,
Gintautas

Just tried this using the navcontainerhelper
New-NavContainer -accept_eula -containerName test -imageName bcinsider.azurecr.io/bconprem Works fine here - it looks like something with your setup.
Have you been able to run other Business Central containers?

I got the same error while running another image (bconprem:latest)
If i use navcontainerhelper script everything works fine. Any hint what could be wrong with my setup?

Just noticed the problem.
All parameters needs to be before the imagename. Try:
docker run -e accept_eula=Y -m 3G bcinsider.azurecr.io/bconprem:13.0.24573.0

Thanks,
It' solved the problem.


Proof presentation with check for revocation, always invalid when requesting multiple credentials

When doing more tests with revocable credentials (but not revoked), we have noticed that if we request more than one credential with a revocation check, the result is always invalid.
For the following requests we expected a valid proof, but they were invalid:

2 revocable credential, both not revoked, check for revocation on proof level
2 revocable credential, both not revoked, check for revocation on credential level

It appears that if more than one credential needs to be checked for revocation, the proof is invalid. We reported a similar issue when one of the credentials was non-revocable, https://github.com/hyperledger/aries-cloudagent-python/issues/1651 .

Thanks for the report -- this a big deal if true.  Do you have a test case that you can share?  If not, we will build one up, but it would good to know if you had it in place already.
I'm hoping we can use Aries Agent Test Harness and BDD tests to cover the range of tests needed.

FYI -- @WadeBarnes reports that they have run tests with multiple revocable credentials with ACA-Py and have been successful at getting the presentations to verify when the credentials are not revoked.

Details here in the ticket, specifically the Steps to reproduce - success scenario.

thanks, I will check this. So far we have done manual tests with the Lissi agent to create the credentials and presentation requests, and as holder simply an ACA-Py instance that automatically accepts and responds to requests. This is what one of the requests looks like:
{
  "version": "1.0",
  "name": "2revocCheckRevocForAll",
  "nonce": "988294151342830409375281",
  "requested_attributes": {
    "attrGrp_0": {
      "names": [
        "name"
      ],
      "restrictions": [
        {
          "cred_def_id": "DR5iYD6jK6YXYfXZrq2rCs:3:CL:14187:revocable1"
        }
      ]
    },
    "attrGrp_1": {
      "names": [
        "name"
      ],
      "restrictions": [
        {
          "cred_def_id": "DR5iYD6jK6YXYfXZrq2rCs:3:CL:14187:revocable2"
        }
      ]
    }
  },
  "requested_predicates": {},
  "non_revoked": {
    "to":<PHONE_NUMBER>
  }
}

I also just tested it by requesting two credentials + non-revocation checks. Unfortunately, AcaPy is returning that the presentation is invalid. When requesting each credential + non-revocation check individually, the AcaPy reports two valid presentations.
The presentation result returned by the AcaPy is the following
{
  "verified_msgs": [
    "VERIFY_ERROR: :Invalid object handle"
  ],
  "presentation_request": {
    "nonce": "593780741447409929721944",
    "name": "asdf",
    "version": "1.0",
    "requested_attributes": {
      "attrGrp_0": {
        "restrictions": [
          {
            "cred_def_id": "QQCQpj9mNEKuJfm14Ysrsz: 3:CL: 14714:Test2"
          }
        ],
        "names": [
          "test"
        ],
        "non_revoked": {
          "to":<PHONE_NUMBER>
        }
      },
      "attrGrp_1": {
        "restrictions": [
          {
            "cred_def_id": "QQCQpj9mNEKuJfm14Ysrsz: 3:CL: 14714:Test"
          }
        ],
        "names": [
          "test"
        ],
        "non_revoked": {
          "to":<PHONE_NUMBER>
        }
      }
    },
    "requested_predicates": {}
  },
  "initiator": "self",
  "role": "verifier",
  "state": "verified",
  "presentation_exchange_id": "a75d061e-2a10-4526-bc0d-c5dbd9a222fd",
  "thread_id": "f17835c6-56d6-4b91-8497-7149e3ff7459",
  "presentation_request_dict": {
    "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation",
    "@id": "f17835c6-56d6-4b91-8497-7149e3ff7459",
    "request_presentations~attach": [
      {
        "@id": "libindy-request-presentation-0",
        "mime-type": "application/json",
        "data": {
          "base64": "eyJ2ZXJzaW9uIjogIjEuMCIsICJuYW1lIjogImFzZGYiLCAibm9uY2UiOiAiNTkzNzgwNzQxNDQ3NDA5OTI5NzIxOTQ0IiwgInJlcXVlc3RlZF9hdHRyaWJ1dGVzIjogeyJhdHRyR3JwXzAiOiB7Im5hbWVzIjogWyJ0ZXN0Il0sICJub25fcmV2b2tlZCI6IHsidG8iOiAxNjcwMjQyNjkzfSwgInJlc3RyaWN0aW9ucyI6IFt7ImNyZWRfZGVmX2lkIjogIlFRQ1FwajltTkVLdUpmbTE0WXNyc3o6MzpDTDoxNDcxNDpUZXN0MiJ9XX0sICJhdHRyR3JwXzEiOiB7Im5hbWVzIjogWyJ0ZXN0Il0sICJub25fcmV2b2tlZCI6IHsidG8iOiAxNjcwMjQyNjkzfSwgInJlc3RyaWN0aW9ucyI6IFt7ImNyZWRfZGVmX2lkIjogIlFRQ1FwajltTkVLdUpmbTE0WXNyc3o6MzpDTDoxNDcxNDpUZXN0In1dfX0sICJyZXF1ZXN0ZWRfcHJlZGljYXRlcyI6IHt9fQ=="
        }
      }
    ],
    "comment": "Proof Request"
  },
  "updated_at": "2022-12-05T12: 18: 28.167510Z",
  "auto_verify": True,
  "presentation": {
    "proof": {
      "proofs": [
        {
          "primary_proof": {
            "eq_proof": {
              "revealed_attrs": {
                "test": "559724291912345840706199426233202135177187251912100367391451049609752637212"
              },
              "a_prime": "86333307172936036283120981665829472100424924662477788424246964911793007302717050567218436046563661134892684054726915909379352745550101914199262155995970020260349148349023332468111892904674553098572193147331489589131917346085700090588216342531780728268879297660520253649159850610723777346515608092970730394691403223229706031990305242060451451086196801288130975284645976829678737771046602810486344012885733155154068486576388534024328160785714602300722646333025278378295721020240707970855407474527768889925657952445792889945209495718445482381338444426565897393022311018846598599233735025386314669146668958709822944387795",
              "e": "85418688223361281436002253784946511355911830953398916213471545044872288250994453451208190979228573922558951253562528029444352591540216007",
              "v": "616650795867102570458124532222355740656321218280951224637778300217469526670469450800002452892026016846512589281538434042958983455924412390016379966129526838775109371777875593279464430468108751153742187952623991598795875616527722822405811941569329915498422687687485710977232975651522281508133340775797629044183606265633184918426882650558096341894004224914867052751735503681586523253277605709045437882959282042638525532681874025448916549832976313034291740770947124065540098218646835323384095799485287858771169194636821747190983739548765973021863243652823623243531913503573153174047908249121641293202770971125710707087323796651001162061200955241846226171369694020555035235607810574464174084133688473775571641481141863552537965718503360348671176092562091577418026925415310593457918967935970963523438485896307606499377684604294773965322209219560378109033677367656565755310238110752445918192628067456508432092686009345895975948",
              "m": {
                "master_secret": "12888439206942528952853342075873875576553005629259640922930241809402909801600728153891140164832328503432536483920760825893732467680808181414928799773627415704565347063482002084558"
              },
              "m2": "9057568051224137630187359171062153647848001292938667201955322339527423050708024056384213834547450466012396192172629731172184760935904282150247161399235473"
            },
            "ge_proofs": []
          },
          "non_revoc_proof": {
            "x_list": {
              "rho": "18520601CE4488D6FCEA9D8E30518BB086A9E781A9E70A82771E5224F7EDC62D",
              "r": "0F552C031B8BC64EBC8ED6C964625DD9E044A8EFA2C1DCCBC9F60A83FB2FED32",
              "r_prime": "0BDD0DBDD82F1817DBC4BA1199782F3B7894E2A2A4CCE2F41E7E0BA803AD0EB4",
              "r_prime_prime": "014DD66423569F8B52A334CF13E75B5FB7B9E79EAD7F52E9F332AD5308690B46",
              "r_prime_prime_prime": "1CC33C996D03F41B581F1946E63AF4422419DA93D5540845DDD3961C0711A9F1",
              "o": "0B06FC9285FCA44CF4CDFD890909EE6CABE2B1961C751EC5538BCDCB7EA76197",
              "o_prime": "189843BE4B2A51ECDA3FC702765302B32CA1A9168076DB46DDAB5E7731E5683A",
              "m": "0EFA1BE4102FA78248EF682853946535C50CCFDB3A89622F2F0B68E73E010768",
              "m_prime": "1A2788FF59E82E934607584AC8A9E097461A7B2205BEA2929937E54125FE0CF5",
              "t": "200E9411FAC58131190CBC7677FE1FF018B6ADCBB96728DC7B5F8ACDA11C8CCC",
              "t_prime": "207DF10646222E7BFDBB5BA169C1D92AF9158796F96466EBF013024359B8C790",
              "m2": "0210C8F42B6BE6B57FCE0D9806677C5331EDA9157490582F21B2D7A3294E7D04",
              "s": "1F28B733FC31C43186F9FF27A64C1B426B1323F908AE04E36A1819D589C14948",
              "c": "0AC3C46D76F19C5D99A2296589E08C8C9CA49347E300EF1151E7EF43517511E0"
            },
            "c_list": {
              "e": "6 44A64EEF5BCCB8BF322622F43451DD7AF5F33FCC488DE840386F98FA50C595E0 4 1CB0FB90EC83A057176B167AA7B3E7052E4FB26172828B1467F2A04744E5597E 4 26A7872C911D09821B3DC347F82C81880C5FF0C2DDF2C4EAC7DBC2878641E2D9",
              "d": "6 62A6C43394C63615398C3F5887DC3C94FA4584295B0AC35B4846FA145F39025D 4 1CE8EF651142831853AC354E438912532B28A8BF44AE11777F631ECF6BC48332 4 3A2254C221BCFE3B1F32AD1488F13012182531F183C4345DE20B976C697217F6",
              "a": "6 38391CC974AC2CAEBB09D2347E6026ACED6D0C80E1160677682395A5EE06277B 4 3C40923087D631E27F0096EDD450EFACEA38489D92FF09647863C9779485FC66 4 2816E42EFAA1B25E93C78970A7F15F58EAE821D84D5DEF33C1FBA12977A6752E",
              "g": "6 485B95B6E8A681B6A33A13A8EE87FCE98408BF1F4924F1C9A381DD4F3F9DBD25 4 290EB5C673382CC7D327CE766025EEF1FFE4A4041BB1D1CBC979357BE38D3DFA 4 3A8B20402BDFD05B3114292A2DD0D5BC709AA81871E1CFE1FB36AF9EF708ACA9",
              "w": "21 123E5D0979F6D44363761B2C2AAA6DC6AC32D4A82C0EF13161F88B1EDCBE99BF0 21 119DDD03EB79E0CC84F56613FD6078B4E6B54AA68AFF1E94FC7CA71377C5406B3 6 635C9DA5AA293B3DF63EAE73507D3DFF96BAAC3A06B8C8090D6552E72D965265 4 1CA5CF784CAF9047AB34C472FD8EC48BA384C823B0DA5F1086109644E4B695D2 6 5F7FC8A54F9B042C6DB09810ED46D8351AB76DEB045DFA2D69ACE2094B2F6766 4 31441D712A605FB3304DF9DB64CFD06DE73CD4FC95CD41DAB7A693031E0143B2",
              "s": "21 131EC54DFC5F8118C505353B338ABDD257597A568327561B3230B38151FEC0BDD 21 132A7C9C1529555E775762463FDF3FE6DA366040773841791209ACE8F941C9BCB 6 6E2FDC5ECFF0D6C18F136C5FC745EA10761C078D1186221A7855D2BCA882FD8B 4 12C14A6E132A943BD82611532826410E933A1E625694806DD906A65021D6AA17 6 6319D6F853FA5E4CA53D71A1F2E13C2FD6E2C334298E7EF325FFDFAF4628A6F8 4 17FC8B425E84C2D39D5C1A691856220F0083CBBB69C17874293DF551EE513092",
              "u": "21 13702782CF097CB039D0B5B14E5962A7477BFE76F1E3E62B60E6BA912A83C9D56 21 10E13301C824DB77146147435DF9D47B9383C3687A3F1CDE23736AD5740EC4BE7 6 6E6350AF7DA8F7C7D38B93298A281E4C7DAF4C16197D35F235CA1A6A8308BA44 4 303ED6BB04BA1C15738D256D6E40CECDA1EAB54B253EF9801769BC5083D40948 6 4FD034C1528B28922910CB436FAD4425EEC61452569192A557017B353766A46D 4 1F7D14E6CCA648EB2AF4B27E8AC5D153580B0686899103EB14CEC79DB9FE811F"
            }
          }
        },
        {
          "primary_proof": {
            "eq_proof": {
              "revealed_attrs": {
                "test": "66462239542460791898155259503102767165757637622612705294848629465626581613557"
              },
              "a_prime": "40502641672239933864720562802557962598518486848332774937371847172150014243339249706944721669037896146241528282882940368396821489255823263928553202183095686447207198709268865141679768701610733136129150136866189258843804397851597452199926257556015895462930508543905614412776545094665377550558901517126619205079389574536357695454448530024414391110485516341797981842466001845272498518199480074619680297497972558257131694313681541247476039697226807316547807385506144404456256271831934659011976585848580220062543746600692032893271373066854095017146495677798243709587469121885732397828459369671364597579685575672570507329485",
              "e": "66010484976270436759241842915273968818203751565508241757942178210657214377170151328113744875399685563202404676847483666791401238545043682",
              "v": "994214138237738411011028664068398155669673201209736802689574317251599798246796364162348836927639186947374478338763733114032874604872519222701013625794385748047996975001665187126159649972223743736543154593552240750332822836205326776877226296467070109539022569155969281404184512804183327651761483140646161562697867998122016839483114310202137740805641827050820735742175964484105535655838932940110104491894105725171794535413868917819804566545551354436830185140971037201473652201685385742168850441114715510102470406539545619304350287078436679774535212940598108230884292569384474595893146106912737958306409662224779535757111977980595398503472713315384024376358400111055283406861086452633789999446757996604503103137375292570118593100993263645395593096151257595919445697623312730115781161304531730205509654867303536419244855367860977953928460125083474401549263741979007983114416168993878274145526017435306636084157072067801777421",
              "m": {
                "master_secret": "12888439206942528952853342075873875576553005629259640922930241809402909801600728153891140164832328503432536483920760825893732467680808181414928799773627415704565347063482002084558"
              },
              "m2": "9057568051224137630187359171062153647848001292938667201955322339527423050708031955584488978477044386922455809361333814366738560835965498563619077305708109"
            },
            "ge_proofs": []
          },
          "non_revoc_proof": {
            "x_list": {
              "rho": "0B62158BFFB6ADE278E0802E727FBEEA4D2E0427E35EB13CC9BC63914365A59D",
              "r": "0FF85211B6D60F5C5B20847A44C8C2E5325730E4BE57149F9A4A36304A7E6E5E",
              "r_prime": "0AFB3B3AF37EAC06E468CA706D8C4D89F5F9640CDE56AAF2C2626D04809FC555",
              "r_prime_prime": "0E6DF3F8CAB4CB2447E8FBABF3C731FB20D38DD6EE24011934AA81767FDFCDDF",
              "r_prime_prime_prime": "12B85C12578F7E4CA8044191F848CDD270B57AB13E4DBA9C8113AAA03941B7E6",
              "o": "0C9018FDD9E5DA249F388F6EAE0EBE4361F2DD06AD3E6E9DE795A7D5EC168530",
              "o_prime": "1EA6D1AE8D64C9D800B8A05A89405D6A3F0B04A5828EC9C10FB7AC77910D6786",
              "m": "036E411392F187DE6B4553DF4DEFB12DA6727592F803CC777C9F7BE717F4A239",
              "m_prime": "0390BE01A07CBB8E5D8DE577773291B1AD25BA7497A0067F81497A43D277828B",
              "t": "027359CA0D58DA1781A731F1BAB122D1524450C1C13EE42BFF1544068B6908AC",
              "t_prime": "03280867263CBA9E8BD88A9817B15E2EAEE757B4C34A4D5507670F502684F033",
              "m2": "138792EAA16007837F43B2906C9D7E09AADE12ABF0450108D7521F3A0D88D7C0",
              "s": "0115F8BD95E2C62A0435E78F2E25F292F3AE61E359BDF9E3DCB77D141D83D8DE",
              "c": "0CDA71358E136624FB09480A1C771B2E2B3D3CFDF5C31F3008A31EB8F8F2E1D2"
            },
            "c_list": {
              "e": "6 5C229B67255BB7D08FA407BC0B2694BEB354D1E9123984FAAE1578ADA3646AE4 4 261BFEC2E84617C9EDFD9FFA7C914B7978C4E03826703530F1CF3FEDD31245F3 4 1573A096D83FD72F5FC2388FEDA14FD27BCDF4E21C487CDB584EE80ACA0388C5",
              "d": "6 4D9FB8112598567BFA6019630AA37B332162C4531326050C695361A04200C171 4 132D2AFCC265FAFEEAB43B6D0BFE893A9026C81C9A6485930A49F8C1811988AB 4 25BA7B4FABF9DE1DC54E63286AC56B6E0BD1C6348E14085D2113368334A8AB75",
              "a": "6 3EEC93736CFB382AFACC625F094DB10BF16DDE2C9F2E8B17E96C8F60A7503F34 4 2E5103A957CF5DABC01DEED3CF87A2030A47B8D6C555E86FF75BC317DF16C5CC 4 3273E917323E4CF9BC1075BC16F15E6247834A1CECE0F77278CEC8856BF64C0E",
              "g": "6 35929FFDCBDECB85661C56873EAE71540B0F76FD827607A8078AB2BA726E606C 4 3980F1CB1478DD90961DDB999D2355136DB46878EF5D16AE54E62B800BA6B5DB 4 2C14F0E74C09941AED2D8CFAFB0C649235E22EBFA89770425E91A1375C378814",
              "w": "21 126C86B1362F117AA3638C8C1C93F8D1411A8737BA6507BF1687E378BD2EB7C7F 21<PHONE_NUMBER>905DE32B7846EAABC317E7CB691A9EDC1297827C42C2A41669BA712 6 862E3A9A7394B632CC91C4002DE0AAAF556C56051E6D3EEA2BAD5BA517FDD2E1 4 3C5119F97727F3F99A450CC11671482C2668EE8180431A34B2C5A39EFB0DD873 6 744EB40179F2D87D5D8919EFF05D13E43C8F7BFC5B2B0EA808312CCFCB3A5181 4 1AC5F6AFB17DA57016AEAF5E4CBE48AF388F8C59332C2782C0DC3DB9FC7A7786",
              "s": "21 137FC9D854715B0A0D48381A607A3A0AF769144984D9F351EAB35749D4FF1E9D8 21 12D57DEE66F17611C5525EA79235CF8CC953F47CC3A25F9D07D4BC794B2D09635 6 8C607C67F58F1786C5E60EDAE4B37D1F850DA4999AD97462BAD68CBEF1B6A848 4 0E0C252F4C9B61E7B98A5DB5F8E6AB36B6C9137DAFA204C644791E750AF8EB0E 6 69B438CDCBA5394F1BCE7895F7BF895825CE85473C587772922CE787B43670DB 4 1B5D402CDECD595494EC1B5FCD22961E10173F88F4644E882DA12C79EE5AC601",
              "u": "21 12C44A6232409A4D893EA391757AA451365BBDB9CEDB849A9D70FB52CA0C3ADD7 21 143B4A7297D63A0FDAA405E3AD196E9089310BF43BEB38587B56E0291C3291EBE 6 5EB667E643BA4405C60F475FA249A03808D01D0274D503620B470D510D0ECAEA 4 253B5954542B28E53E461E6CBDA2DD54E2EDC6ABE4C9346DEB676625248A1A6E 6 7DBB7BC0965FFF097A30EACAE74385D3A06506331A292EED8ECE7DAF76A7B1EB 4 1FF6B1539529A8499070B557DDE9D43E11FA0C0148F5D5C5203D9376875CE98A"
            }
          }
        }
      ],
      "aggregated_proof": {
        "c_hash": "83629348022353869695363921069214727609538528834067511575919625166823787368943",
        "c_list": [
          [
            4, 11, 246, 84, 252, 129, 173, 13, 57, 43, 103, 60, 201, 177, 179, 101, 152, 52, 77, 70, 50, 158, 140, 211, 107, 224, 187, 206, 128, 124, 115, 138, 204, 7, 49, 86, 115, 150, 145, 238, 9, 207, 206, 127, 6, 128, 227, 97, 28, 196, 232, 107, 163, 32, 40, 141, 148, 122, 19, 125, 184, 100, 215, 216, 18, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
          ],
          [
            4, 20, 74, 20, 91, 194, 239, 67, 216, 160, 120, 222, 76, 215, 51, 215, 192, 221, 237, 12, 107, 0, 180, 7, 146, 213, 244, 31, 252, 205, 251, 241, 19, 14, 83, 92, 190, 92, 212, 211, 24, 22, 49, 191, 231, 164, 235, 64, 65, 163, 180, 192, 76, 202, 163, 127, 95, 210, 205, 215, 218, 154, 249, 10, 24, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
          ],
          [
            4, 15, 41, 1, 33, 75, 10, 100, 189, 78, 70, 130, 176, 45, 241, 164, 204, 237, 153, 8, 243, 107, 189, 42, 131, 163, 49, 22, 247, 194, 57, 56, 182, 29, 10, 115, 202, 218, 17, 133, 14, 239, 12, 250, 214, 254, 92, 53, 70, 113, 147, 133, 196, 58, 210, 173, 73, 196, 199, 204, 144, 77, 22, 198, 170, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
          ],
          [
            4, 6, 61, 186, 215, 75, 71, 184, 219, 171, 84, 136, 85, 12, 70, 151, 144, 49, 238, 147, 109, 4, 211, 4, 233, 59, 104, 95, 245, 217, 76, 149, 197, 28, 223, 54, 201, 68, 65, 134, 124, 42, 36, 135, 96, 79, 219, 222, 190, 184, 206, 235, 208, 179, 110, 200, 174, 65, 27, 227, 111, 187, 211, 76, 189, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
          ],
          [
            9, 208, 58, 237, 173, 237, 204, 157, 195, 253, 254, 178, 127, 139, 237, 100, 164, 173, 118, 136, 55, 238, 140, 50, 155, 87, 214, 109, 116, 33, 150, 20, 13, 28, 2, 14, 23, 9, 51, 79, 8, 31, 94, 245, 206, 156, 243, 226, 46, 127, 2, 124, 173, 161, 170, 243, 68, 197, 131, 222, 52, 167, 172, 150, 32, 197, 208, 251, 113, 141, 25, 61, 135, 216, 82, 79, 233, 206, 253, 237, 62, 241, 53, 231, 133, 249, 28, 247, 213, 43, 116, 43, 24, 160, 238, 142, 5, 203, 120, 146, 106, 219, 219, 202, 247, 105, 101, 65, 237, 115, 129, 191, 133, 135, 81, 133, 184, 209, 239, 212, 9, 197, 101, 138, 193, 132, 65, 115
          ],
          [
            26, 238, 5, 36, 195, 220, 24, 222, 234, 154, 206, 247, 231, 48, 62, 83, 162, 64, 231, 200, 42, 70, 205, 173, 192, 52, 150, 2, 158, 158, 19, 224, 34, 152, 180, 168, 94, 254, 113, 58, 50, 254, 165, 195, 82, 138, 33, 14, 88, 154, 177, 169, 16, 132, 200, 148, 54, 253, 167, 46, 34, 68, 55, 138, 10, 148, 232, 108, 173, 18, 147, 56, 161, 118, 16, 223, 92, 61, 109, 237, 170, 9, 247, 26, 109, 212, 183, 146, 10, 132, 101, 178, 175, 218, 154, 13, 22, 85, 118, 6, 42, 47, 239, 208, 178, 211, 157, 136, 13, 50, 15, 38, 38, 149, 113, 154, 140, 177, 4, 220, 171, 224, 1, 142, 22, 51, 207, 111
          ],
          [
            6, 68, 229, 66, 30, 190, 5, 126, 202, 211, 27, 120, 34, 197, 77, 255, 115, 195, 157, 30, 154, 155, 22, 110, 218, 197, 174, 170, 78, 11, 241, 242, 29, 140, 179, 161, 176, 188, 207, 62, 113, 54, 208, 96, 119, 44, 201, 69, 104, 235, 20, 190, 248, 115, 179, 118, 21, 130, 229, 107, 201, 50, 111, 244, 13, 201, 13, 58, 71, 82, 222, 245, 77, 46, 250, 76, 106, 70, 141, 159, 187, 39, 178, 74, 228, 193, 16, 69, 170, 10, 113, 247, 32022-12-05T12: 18: 28.189574482Z 1, 65, 53, 88, 4, 16, 96, 111, 80, 121, 242, 237, 6, 130, 210, 156, 153, 139, 38, 218, 167, 172, 214, 102, 77, 255, 21, 211, 206, 168, 30, 89, 139, 225, 206, 23
          ],
          [
            2, 171, 228, 59, 32, 54, 118, 136, 71, 18, 68, 242, 9, 229, 128, 53, 118, 224, 43, 152, 103, 112, 97, 53, 164, 128, 138, 37, 93, 201, 104, 160, 112, 103, 163, 140, 111, 31, 0, 245, 33, 252, 167, 22, 183, 129, 7, 153, 68, 227, 5, 77, 121, 24, 142, 102, 223, 132, 113, 88, 234, 218, 234, 208, 54, 158, 16, 251, 83, 164, 214, 250, 168, 228, 123, 231, 227, 21, 141, 52, 67, 195, 113, 139, 215, 224, 211, 100, 65, 31, 134, 245, 11, 130, 32, 4, 43, 128, 95, 181, 119, 213, 185, 180, 56, 40, 65, 137, 118, 215, 229, 133, 113, 115, 122, 108, 23, 151, 108, 137, 93, 137, 189, 45, 200, 8, 185, 67, 17, 216, 2, 145, 147, 249, 195, 24, 60, 126, 209, 207, 195, 96, 109, 85, 142, 15, 196, 85, 114, 118, 164, 210, 20, 71, 2, 226, 110, 211, 161, 177, 254, 38, 246, 237, 161, 84, 7, 117, 71, 53, 97, 234, 87, 52, 36, 179, 126, 175, 22, 119, 162, 181, 250, 136, 201, 8, 232, 216, 223, 165, 210, 88, 15, 239, 69, 1, 55, 5, 141, 122, 169, 145, 78, 93, 56, 238, 84, 181, 98, 28, 56, 211, 77, 205, 222, 224, 78, 67, 52, 177, 169, 214, 72, 107, 2, 149, 60, 212, 108, 179, 157, 91, 221, 124, 125, 75, 44, 188, 24, 92, 77, 115, 46, 219, 124, 40, 49, 123, 17, 146, 248, 245, 115, 180, 119, 34, 211
          ],
          [
            4, 25, 127, 149, 213, 240, 176, 220, 74, 129, 175, 202, 50, 135, 70, 159, 98, 204, 186, 180, 11, 94, 131, 2, 56, 80, 191, 63, 36, 27, 180, 201, 112, 0, 155, 81, 245, 167, 215, 186, 134, 228, 64, 33, 33, 180, 159, 186, 100, 248, 71, 38, 43, 188, 40, 189, 166, 254, 42, 150, 156, 19, 186, 163, 152, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
          ],
          [
            4, 17, 131, 0, 72, 75, 58, 118, 39, 236, 234, 192, 139, 6, 142, 10, 100, 151, 223, 169, 219, 194, 212, 0, 53, 38, 151, 222, 231, 25, 255, 147, 248, 25, 137, 153, 80, 18, 243, 50, 127, 150, 181, 234, 159, 119, 217, 100, 196, 2, 49, 225, 222, 252, 18, 6, 180, 56, 52, 27, 29, 251, 55, 145, 79, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
          ],
          [
            4, 26, 10, 241, 127, 14, 132, 27, 196, 71, 121, 123, 146, 6, 217, 41, 160, 141, 33, 26, 248, 80, 28, 38, 139, 158, 172, 22, 74, 118, 174, 136, 34, 16, 25, 141, 22, 134, 114, 246, 54, 34, 10, 31, 91, 129, 238, 13, 134, 124, 93, 217, 161, 160, 101, 28, 121, 95, 13, 106, 78, 233, 246, 36, 91, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
          ],
          [
            4, 2, 210, 207, 122, 207, 73, 222, 192, 82, 168, 74, 85, 186, 211, 4, 111, 133, 186, 47, 89, 30, 120, 112, 183, 37, 166, 13, 59, 48, 47, 56, 69, 29, 21, 241, 242, 71, 135, 160, 7, 24, 151, 52, 92, 181, 168, 16, 64, 139, 47, 98, 2, 115, 147, 182, 97, 185, 244, 162, 115, 191, 226, 93, 171, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
          ],
          [
            23, 227, 79, 201, 65, 38, 200, 168, 42, 101, 127, 133, 143, 95, 25, 118, 10, 169, 134, 93, 153, 230, 67, 132, 131, 146, 251, 242, 252, 217, 116, 130, 34, 236, 77, 18, 26, 63, 186, 109, 253, 71, 2, 97, 140, 153, 237, 54, 99, 51, 66, 249, 60, 34, 54, 39, 97, 86, 242, 241, 244, 195, 48, 114, 12, 158, 181, 13, 207, 93, 193, 126, 199, 54, 186, 22, 160, 27, 240, 252, 128, 139, 6, 219, 211, 33, 60, 198, 60, 76, 39, 211, 110, 161, 175, 153, 17, 250, 183, 216, 200, 244, 181, 191, 82, 92, 149, 228, 50, 192, 224, 49, 110, 230, 137, 123, 240, 254, 66, 96, 67, 56, 180, 155, 170, 99, 31, 52
          ],
          [
            2, 0, 188, 161, 231, 40, 212, 52, 63, 0, 218, 239, 34, 98, 117, 250, 157, 63, 4, 177, 121, 9, 56, 213, 224, 60, 103, 39, 5, 82, 209, 106, 1, 39, 46, 252, 4, 3, 231, 190, 101, 71, 54, 185, 215, 60, 144, 48, 83, 77, 205, 25, 19, 31, 225, 206, 238, 211, 194, 129, 54, 68, 242, 49, 5, 11, 80, 70, 78, 186, 110, 82, 201, 203, 226, 140, 79, 172, 141, 79, 43, 182, 175, 14, 99, 208, 170, 252, 112, 0, 151, 14, 142, 109, 193, 179, 35, 18, 127, 59, 216, 204, 56, 230, 187, 202, 37, 60, 119, 165, 122, 186, 201, 219, 118, 165, 239, 215, 90, 176, 83, 250, 193, 126, 40, 22, 200, 221
          ],
          [
            21, 195, 6, 96, 152, 231, 97, 225, 10, 170, 44, 225, 163, 15, 126, 173, 163, 36, 51, 106, 39, 19, 209, 92, 133, 127, 168, 238, 6, 189, 63, 87, 14, 43, 129, 50, 36, 63, 97, 63, 11, 248, 131, 242, 63, 13, 140, 155, 90, 207, 49, 45, 107, 206, 17, 222, 231, 214, 158, 82, 178, 78, 75, 120, 33, 204, 159, 113, 215, 244, 86, 187, 205, 155, 148, 105, 93, 86, 181, 182, 161, 5, 13, 35, 176, 225, 172, 97, 56, 117, 86, 128, 235, 190, 132, 25, 0, 98, 0, 156, 224, 73, 152, 12, 182, 72, 108, 13, 71, 212, 41, 142, 50, 88, 225, 251, 75, 124, 195, 130, 183, 202, 165, 90, 91, 52, 198, 46
          ],
          [
            1, 64, 215, 188, 199, 17, 19, 225, 62, 99, 154, 191, 154, 127, 206, 66, 24, 209, 92, 16, 89, 197, 233, 31, 81, 65, 79, 182, 39, 162, 193, 219, 64, 199, 12, 173, 65, 243, 182, 142, 5, 6, 84, 97, 57, 249, 237, 49, 249, 209, 7, 129, 175, 154, 60, 157, 121, 205, 8, 102, 12, 140, 27, 187, 218, 60, 87, 243, 57, 237, 143, 39, 5, 156, 152, 115, 75, 21, 236, 7, 102, 29, 210, 244, 196, 231, 164, 32, 5, 211, 202, 102, 6, 193, 84, 234, 104, 17, 184, 159, 206, 120, 214, 106, 4, 92, 158, 199, 112, 201, 157, 192, 197, 104, 162, 195, 54, 7, 171, 28, 177, 86, 148, 79, 184, 105, 121, 243, 146, 29, 214, 169, 137, 186, 55, 14, 121, 222, 99, 69, 125, 249, 39, 137, 205, 64, 146, 102, 4, 123, 57, 116, 168, 129, 183, 231, 143, 95, 52, 142, 154, 223, 190, 30, 203, 115, 213, 99, 24, 63, 129, 232, 135, 214, 191, 66, 129, 254, 113, 142, 137, 233, 102, 121, 239, 70, 164, 89, 57, 32, 91, 131, 92, 179, 125, 137, 182, 166, 55, 90, 104, 235, 150, 20, 98, 253, 103, 110, 199, 118, 200, 107, 109, 242, 160, 208, 118, 87, 6, 135, 249, 70, 205, 202, 64, 24, 97, 227, 125, 218, 66, 18, 232, 118, 190, 215, 177, 101, 212, 234, 169, 130, 14, 62, 226, 229, 163, 213, 218, 10, 51, 51, 62, 159, 122, 127, 205
          ]
        ]
      }
    },
    "requested_proof": {
      "revealed_attrs": {},
      "revealed_attr_groups": {
        "attrGrp_0": {
          "sub_proof_index": 0,
          "values": {
            "test": {
              "raw": "jlkj",
              "encoded": "559724291912345840706199426233202135177187251912100367391451049609752637212"
            }
          }
        },
        "attrGrp_1": {
          "sub_proof_index": 1,
          "values": {
            "test": {
              "raw": "njn",
              "encoded": "66462239542460791898155259503102767165757637622612705294848629465626581613557"
            }
          }
        }
      },
      "self_attested_attrs": {},
      "unrevealed_attrs": {},
      "predicates": {}
    },
    "identifiers": [
      {
        "schema_id": "QQCQpj9mNEKuJfm14Ysrsz: 2:test: 1.0",
        "cred_def_id": "QQCQpj9mNEKuJfm14Ysrsz: 3:CL: 14714:Test2",
        "rev_reg_id": "QQCQpj9mNEKuJfm14Ysrsz: 4:QQCQpj9mNEKuJfm14Ysrsz: 3:CL: 14714:Test2:CL_ACCUM: 2fc867db-e288-4734-ad4f-212f52d248fb",
        "timestamp":<PHONE_NUMBER>
      },
      {
        "schema_id": "QQCQpj9mNEKuJfm14Ysrsz: 2:test: 1.0",
        "cred_def_id": "QQCQpj9mNEKuJfm14Ysrsz: 3:CL: 14714:Test",
        "rev_reg_id": "QQCQpj9mNEKuJfm14Ysrsz: 4:QQCQpj9mNEKuJfm14Ysrsz: 3:CL: 14714:Test:CL_ACCUM: 1c1330b1-c249-482c-b99b-0b938ab1794d",
        "timestamp":<PHONE_NUMBER>
      }
    ]
  },
  "verified": "false",
  "created_at": "2022-12-05T12: 18: 13.416155Z",
  "connection_id": "570ef3a4-44fb-4164-a2c2-16d26eebfded",
  "trace": False,
  "auto_present": False
}

@ianco -- I think this has to bump in priority vs. the mediator testing this week.
I think the best approach to resolve this is probably what I proposed in Aries Agent Test Harness Issue 605, so we can debug what is happening and see if the problem has always been there or was added in a specific version. And we can test other Frameworks for the same issue.  @nodlesh -- heads up on this and the priority of that test.

Timestamp parameters are things I don't understand fully. So, I'm not sure but the fact that the timestamp in the proof request was<PHONE_NUMBER> and the timestamps in the proof.identifiers are<PHONE_NUMBER> and<PHONE_NUMBER> makes me suspicious. (I'm referring to this comment)
I suppose the timestamps of the proof should be larger values than the requested timestamp for non-revocation.
ACA-py is using delta_timestamp when it creates revocation_states here: https://github.com/hyperledger/aries-cloudagent-python/blob/22f8d4f79d55da2d5d0f307646f299dc991d15a4/aries_cloudagent/protocols/present_proof/indy/pres_exch_handler.py#L188
I think the timestamp used here should be larger than the requested timestamp for non-revocation and we could use the current time which is obviously larger than the requested timestamp.
AFJ is using the timestamp in the proof request message for this.

Sorry. I was wrong.
verifier.rs checks the timestamps in proof.identifiers, not those in proof.requested_proof.revealed_attr_groups.
proof.identifiers contains timestamps which are<PHONE_NUMBER> and<PHONE_NUMBER>.
My previous comment about creating revocation state was also incorrect, so please ignore that too. 😞

I've added some integration tests to cover the multi-credential-proof scenarios, here is a summary, let me know if you think there are other scenarios we need to include in the tests:
See https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/features/0454-present-proof.feature#L100
@T003-RFC0454.1 - multiple credentials in proof (1 revocable, 1 not), no revocation check
@T003-RFC0454.1f - multiple credentials in proof (1 revocable, 1 not), revocation check is at the request level, verification fails (this is the scenario which is not handled properly, I think by anoncreds)
@T003-RFC0454.2 - multiple credentials in proof (1 revocable, 1 not), revocable cred is revoked, revocation check at the attribute level, verification fails
@T003-RFC0454.3 - same as *.2 but with no revocation check, verification passes
These tests are all aca-py to aca-py, it sounds like you're testing with the Lissi wallet (?)  ...  It would be great if you could replicate using aca-py (or let me know the specific scenario and I can try to tweak the integration tests) as this is easier for us to verify/automate.

We tested as well using aca-py to make sure it was not an issue of the wallet.
Apart from the scenario of @T003-RFC0454.1f , other tests that were failing were the ones mentioned in the original post:

multiple credentials in proof, both revocable but not revoked, revocation check either at attribute or request level, verification fails

I've add this scenario like this:
   @T003-RFC0454.4 @GHA
   Scenario Outline: Present Proof for multiple credentials where both are revocable, neither credential is revoked
      Given we have "4" agents
         | name  | role     | capabilities         |
         | Acme1 | issuer1  | <Acme1_capabilities> |
         | Acme2 | issuer2  | <Acme2_capabilities> |
         | Faber | verifier | <Acme1_capabilities> |
         | Bob   | prover   | <Bob_cap>   |
      And "<issuer1>" and "Bob" have an existing connection
      And "Bob" has an issued <Schema_name_1> credential <Credential_data_1> from "<issuer1>"
      And "<issuer2>" and "Bob" have an existing connection
      And "Bob" has an issued <Schema_name_2> credential <Credential_data_2> from "<issuer2>"
      And "Faber" and "Bob" have an existing connection
      When "Faber" sends a request for proof presentation <Proof_request> to "Bob"
      Then "Faber" has the proof verified

      Examples:
         | issuer1 | Acme1_capabilities        | issuer2 | Acme2_capabilities | Bob_cap | Schema_name_1     | Credential_data_1 | Schema_name_2 | Credential_data_2 | Proof_request                    |
         | Acme1   | --revocation --public-did | Acme2   | --revocation --public-did       |         | driverslicense_v2 | Data_DL_MaxValues | health_id     | Data_DL_MaxValues | DL_age_over_19_v2_with_health_id |

And I ran the test like this:
LEDGER_URL=http://test.bcovrin.vonx.io PUBLIC_TAILS_URL=https://tails.vonx.io ./run_bdd -t @T003-RFC0454.4

The test failed with the following error logs:
#27 Process the proof provided by X

#28 Check if proof is valid
Faber.agent | 2023-01-09 10:08:36,611 aries_cloudagent.indy.credx.verifier ERROR Validation of presentation on nonce=47974977077717778770600 failed with error
Faber.agent | Traceback (most recent call last):
Faber.agent |   File "/home/indy/aries_cloudagent/indy/credx/verifier.py", line 74, in verify_presentation
Faber.agent |     rev_reg_entries,
Faber.agent |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/futures.py", line 327, in __iter__
Faber.agent |     yield self  # This tells Task to wait for completion.
Faber.agent |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 250, in _wakeup
Faber.agent |     future.result()
Faber.agent |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/futures.py", line 243, in result
Faber.agent |     raise self._exception
Faber.agent |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/concurrent/futures/thread.py", line 56, in run
INFO:aiohttp.access:<IP_ADDRESS> [09/Jan/2023:10:08:36 +0000] "POST /webhooks/topic/present_proof_v2_0/ HTTP/1.1" 200 149 "-" "Python/3.6 aiohttp/3.8.3"
Faber.agent |     result = self.fn(*self.args, **self.kwargs)
Faber.agent | Presentation: state = done, pres_ex_id = f6d73799-31b4-4e10-9f35-00f1382a7fcf
Faber.agent | Proof = false
Faber.agent |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/indy_credx/types.py", line 473, in verify
Faber.agent |     reg_entries or None,
Faber.agent |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/indy_credx/bindings.py", line 711, in verify_presentation
Faber.agent |     byref(verify),
Faber.agent |   File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/indy_credx/bindings.py", line 370, in do_call
Faber.agent |     raise get_current_error(True)
Faber.agent | indy_credx.error.CredxError: Invalid object handle

Is there a way to print out debug messages from indy-sdk? I tried adding RUST_LOG=debug with no difference.

I also ran the test @T003-RFC0454.4 with wallet type "indy" and the test passed. So, it must be an issue related to indy-credx.

Hi, has there been any evolution regarding this issue?
I'm doing some tests with two non-revoked revocable credentials and I have the problem of which I attach below the stack trace.
I used two Aca-py
and tested versions
0.7.4
0.7.5
0.8.0
and they all have the same problem.
Thanks for any kind of support you can give me.
2023-06-23 10:19:11,202 aries_cloudagent.indy.credx.verifier ERROR Validation of presentation on nonce=82000675796637021791301 failed with error
Traceback (most recent call last):
File "/home/indy/aries_cloudagent/indy/credx/verifier.py", line 86, in verify_presentation
rev_reg_entries,
File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/futures.py", line 327, in iter
yield self  # This tells Task to wait for completion.
File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/tasks.py", line 250, in _wakeup
future.result()
File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/asyncio/futures.py", line 243, in result
raise self._exception
File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/concurrent/futures/thread.py", line 56, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/indy_credx/types.py", line 472, in verify
reg_entries or None,
File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/indy_credx/bindings.py", line 715, in verify_presentation
byref(verify),
File "/home/indy/.pyenv/versions/3.6.13/lib/python3.6/site-packages/indy_credx/bindings.py", line 374, in do_call
raise get_current_error(True)
indy_credx.error.CredxError: Invalid object handle
2023-06-23 10:19:11,204 aries_askar.native.aries_askar.ffi.store INFO 	src/ffi/store.rs:528 | Started session SessionHandle(220) on store StoreHandle(1) (txn: false)
2023-06-23 10:19:11,206 aries_askar.native.aries_askar.backend.db_utils INFO 	src/backend/db_utils.rs:103 | Acquire pool connection
2023-06-23 10:19:11,206 aries_askar.native.aries_askar.backend.db_utils INFO 	src/backend/db_utils.rs:280 | Start transaction
2023-06-23 10:19:11,207 aries_askar.native.sqlx.query DEBUG 	None:0 | BEGIN; rows affected: 0, rows returned: 0, elapsed: 947.787µs
2023-06-23 10:19:11,209 aries_askar.native.sqlx.query DEBUG 	None:0 | UPDATE items SET value=$5, …; rows affected: 0, rows returned: 1, elapsed: 1.757ms

The issue was found to be in Indy CredX, part of the indy-shared-rs repo (https://github.com/hyperledger/indy-shared-rs). The issue is fixed in Release 0.3.3.
Updating the ACA-Py requirements should address this.


CornerRadiusEffect

Description of Change
Adding CornerRadius support everywhere by Clipping.

.NET MAUI will support this: https://github.com/dotnet/maui/pull/650
Clip issue on UWP: https://github.com/xamarin/Xamarin.Forms/issues/14275
Works on iOS and Android.

Bugs Fixed

Fixes #1315
Fixes https://github.com/xamarin/Xamarin.Forms/issues/12857

API Changes
public class CornerRadiusEffect : Effect
{
    CornerRadius CornerRadius;
}

Behavioral Changes
None
PR Checklist

[ ] Has a linked Issue, and the Issue has been approved
[ ] Has tests (if omitted, state reason in description)
[x] Has samples
[x] Rebased on top of main at time of PR
[x] Changes adhere to coding standard

[ ] Updated documentation

Very cool, thank you @YZahringer
I think @jsuarezruiz is a good candidate to have a look at this one? :)

@pictos thanks for the review. I followed the same idea as ShadowEffect. But yes, currently there is no platform specific implementation, we could use an AttachedBehavior for that.
There is an issue with UWP and I hope a workaround can be found. This one may require access to the native control and in that case using the Effect makes more sense?

@YZahringer yes, if we need to access the platform api, for sure an Effect will be the way to go.
FYI, I could make it work with behavior and I belive that I can make it work just with an attached property, that way can have lighter api for this feature.
Let me know what you think and if you can make it work on uwp using shared code.

I'd prefer to leave it as effect.
Because it's just visual effect:)) I doesn't bring any behavior.
But let's collect more opinions

I'd prefer to leave it as effect.
Because it's just visual effect:)) I doesn't bring any behavior.
But let's collect more opinions

I believe that we can keep the Effect name but implement it in a such way that we don't need the XF.Effect API

@YZahringer and others, please let me know what do you think about it
https://gist.github.com/pictos/f410a6983e75b2f3a993ce092c970a36
I tested on my end, using your sample and works as expected.

@YZahringer and others, please let me know what do you think about it
https://gist.github.com/pictos/f410a6983e75b2f3a993ce092c970a36
I tested on my end, using your sample and works as expected.

Looks good to me)

@pictos thanks, I have adapted the code with your proposal 👍
For UWP I have no solution unfortunately. I think the problem is here with the GeometryGroup. Maybe we can try to fix it in another PR.

@YZahringer thanks for moving this forward, I'll do a last review during this week and hopefully merge it (:

Any news about this? We have to wait #1410?

Hey @YZahringer no news yet. I'll try to return back to this one next week. I was focused on the 1.2 release

It looks like this feature was already approved before the deadline for more features.
@pictos Could you give it one more review?


[charrypick](predicate pushdown) Common expression not acting on any slot should not be pushed down

pick https://github.com/apache/doris/pull/25901

run buildall


Correction IMDb login fails #1321

Motivation for changes:
Correction IMDb login fails

Detailed changes:
use _session.headers.update to not overwrite header.
add _session.headers.update({reference : http://...}) For better browser simulation
and also post the URL from the action attribute of the form.
Addressed issues:

Fixes #1321

Config usage if relevant (new plugin or updated schema):
tasks:
  import_from_imdb:
    imdb_lookup: yes
    imdb_list:
      login: ********
      password: ********
      list: watchlist
    accept_all: yes
    list_add:
      - movie_list: from_imdb

Log and/or tests output (preferably both):
2016-08-12 15:31 DEBUG    task          import_from_imdb executing import_from_imdb
2016-08-12 15:31 DEBUG    imdb_list     import_from_imdb fetching items from IMDB
2016-08-12 15:31 DEBUG    imdb_list     import_from_imdb user credentials not found in cache or outdated, fetching from IMDB
2016-08-12 15:31 DEBUG    utils.requests import_from_imdb Fetching https://www.imdb.com/ap/signin?openid.return_to=https%3A%2F%2Fwww.imdb.com%2Fap-signin-handler&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.assoc_handle=imdb_mobile_us&openid.mode=checkid_setup&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
2016-08-12 15:31 DEBUG    imdb_list     import_from_imdb email=***********, password=**********
2016-08-12 15:31 VERBOSE  utils.requests import_from_imdb Waiting 3.40 seconds until next request to imdb.com
2016-08-12 15:31 DEBUG    utils.requests import_from_imdb Fetching https://www.imdb.com/ap/signin/151-8146494-9510128?ie=UTF8&pf_rd_r=0JEHNJ78AQWGZCRQWDP7&pf_rd_m=A2A1PIL045UJ9G&pf_rd_t=6301&pf_rd_i=imdb_mobile_us&pf_rd_p=2187562082&pf_rd_s=mobile-signin-slot
2016-08-12 15:31 VERBOSE  utils.requests import_from_imdb Waiting 4.51 seconds until next request to imdb.com
2016-08-12 15:31 DEBUG    utils.requests import_from_imdb Fetching http://www.imdb.com/profile
2016-08-12 15:31 DEBUG    imdb_list     import_from_imdb could not find list ID in cache, fetching from IMDB
2016-08-12 15:31 VERBOSE  utils.requests import_from_imdb Waiting 4.67 seconds until next request to imdb.com
2016-08-12 15:31 DEBUG    utils.requests import_from_imdb Fetching http://www.imdb.com/list/_ajax/watchlist_has
2016-08-12 15:31 VERBOSE  utils.requests import_from_imdb Waiting 4.75 seconds until next request to imdb.com
2016-08-12 15:31 DEBUG    utils.requests import_from_imdb Fetching http://www.imdb.com/list/export?list_id=ls063643555&author_id=ur68256787
2016-08-12 15:31 DEBUG    imdb_list     import_from_imdb parsing line from csv: 1, tt1386697, Sun Aug  7 00:58:27 2016, Sun Aug  7 00:58:27 2016, , Suicide Squad, Feature Film, David Ayer, , 7.0, 123, 2016, action, adventure, comedy, sci_fi, 110719, 2016-08-01, http://www.imdb.com/title/tt1386697/
2016-08-12 15:31 DEBUG    imdb_list     import_from_imdb parsing line from csv: 2, tt4196776, Sun Aug  7 00:58:31 2016, Sun Aug  7 00:58:31 2016, , Jason Bourne, Feature Film, Paul Greengrass, , 7.1, 123, 2016, action, thriller, 38574, 2016-07-11, http://www.imdb.com/title/tt4196776/
2016-08-12 15:31 DEBUG    imdb_list     import_from_imdb parsing line from csv: 3, tt2660888, Sun Aug  7 00:58:32 2016, Sun Aug  7 00:58:32 2016, , Star Trek: Sans limites, Feature Film, Justin Lin, , 7.5, 122, 2016, action, adventure, sci_fi, thriller, 52763, 2016-07-20, http://www.imdb.com/title/tt2660888/
2016-08-12 15:31 DEBUG    backlog       import_from_imdb 0 entries purged from backlog
2016-08-12 15:31 VERBOSE  details       import_from_imdb Produced 3 entries.

Oh man, awesome work!

thanks :) now it works

Any chance you fixing the test so we can merge this? Looks likes a matter of recreating cassette

Ok, I'm a beginner with Python and more with travis. From what I understood from the documentation and error, I just have to change the url signin in the cassette. what I did and now all tests are clean.

Ideally you delete and recreate the cassette but this works too

Thanks for this!

i have just updated from a relatively old version... and i get the error above. i know very little about programing, even just creating the config script is a challenge. I was using the old imdb lookup using the id and that had been fine but in the new version iys not valid anymore. can anyone shed any light on this. also let me know what info you need from me and how to run debug etc if you need it. flexget runs from cron on my headless server so obviously i only mess with it when it needs updating or breaks in someway.

The wiki is a great place to start. https://flexget.com/Plugins/List/imdb_list
Please let old issues lie and use our forums instead if you need help. imdb_list is broken.

Just use the imdb_watchlist plugin instead

sorry guys, thank you for your help, i was obviously looking in the wrong place. I couldn't be sure if it was broken or i was been stupid, so at least that question is clearedup :)


FYI: troubles in 56.8 go-echarger firmware

Checklist

[X] I have installed the latest release (or BETA) version of the integration and home assistant.
[ ] I have prepared DEBUG log output (for technical issues) | In most of the cases of a technical error/issue I would have the need to ask for DEBUG log output of the integration. There is a short tutorial/guide 'How to provide DEBUG log' here
[ ] I understand the SHIT-IN - SHIT-OUT principle (in case of implausible data) | It will happen, that the data that is displayed by this integration does not make much sense (to you) - aka the data is not plausible. Of course it could be the case, that something in this integration has been messed up - but so far - in all reported issues the root cause of implausible data was/is, that the go-eCharger device itself already provided this data [you can check this by directly requesting the attribute from the wallbox]
[X] I confirm it's really an issue | In the case that you want to understand the functionality of a certain feature/sensor Please be so kind and make use if the discussion feature of this repo (and do not create an issue) - TIA

Add a description
I'm running this integration with the latest home assistant and an go-eCharger V4, firmware 56.2.
But with go-e firmware 56.8 the integration stops working & didn't start loading (in my case).
It seems there are some api changes in the go-echarger firmware.
For more information:
https://github.com/goecharger/go-eCharger-API-v2/issues/231
https://github.com/evcc-io/evcc/discussions/14752
https://github.com/evcc-io/evcc/discussions/9279#discussioncomment-9980568
Add your DEBUG log output
No response

From what I read in the different links you shared there are no changes in the API - how I read it, it's new Firmware (of the Wallbox) that needs a "fix"...
So for now don't use 56.8 since for me looks like that multiple things (like evcc) does not work correctly...

The linked issue on our side describes a bug where the homeassistant mqtt autodiscovery topics are always written when having the newest firmware..
This should not affect any other function of the charger, if so I would need more details..

@erxbout

The linked issue on our side describes a bug where the homeassistant mqtt autodiscovery topics are always written when having the newest firmware..

thanks for this clarification - since I am not so deep into the mqtt stuff I did not followed this in detail - now I understand, that the issue of the mqtt based integration is not related to the report of @try2codesecure with this local polling based one - check...

This should not affect any other function of the charger, if so I would need more details...

I am wondering more about the post from steve0564 @ evcc [https://github.com/evcc-io/evcc/discussions/14752] - if this could be related? In any case as soon as I am able to test this locally I will come back to your go-eCharger github repro - right now the car is fully charged and it will take same days before re-charging will be required. But since 'this' integration here is just accessing the documented API's I am currently a bit clueless.

@try2codesecure you might have some more details for us what you mean with the integration stops working & didn't start loading... is this related to the pv-surplus automation? Or is it, that in the HA GUI you start the charging - then the question via which controls? (sensor.id's)

Sure.
Im running the integraton with the Huawei sensors (SUN/LUNA2000).
service: goecharger_api2.set_pv_data data:   pgrid: "{{states('sensor.power_meter_wirkleistung')|float*-1}}"
Trace:
`Ausgeführt: 14. Juli 2024 um 10:45:20
Ergebnis:
params:
domain: goecharger_api2
service: set_pv_data
service_data:
pgrid: -3247
target: {}
running_script: false
`
It works good with the 56.1 & 56.2 go-e firmware. But after the upgrade to 56.8 it doesn't start the loading in the ECO mode anymore. There are no other changes between.
Currently my car is loading, I'll try to recreate the error again until next weekend with FW 56.8.

To clarify, i also think that the problem is not related to your integration.
I just want to link the problem that other integration users avoid those "pitfalls".

ok - so we are talking then about the pv-surplus charging feature (without additional go-eController) - just providing the pgrid via HA automation...
Not sure if you have noticed, that in the past week I have updated (in the docs) the info [acp added]:
Do not forget this important settings
Once you have enabled the automation, you also need to:

Select the 'logic mode': 'Awattar [Eco]' [API-Key 'lmo']
[Logik/Modus: ECO-Modus]

enable the 'Use PV surplus' [API-Key 'fup']
[Mit PV-Überschuss laden]

enable the 'Allow Charge Pause (car compatibility)' [API-Key 'acp']
[Ladepausen zulassen (Fahrzeug Kompatibilität)]

in the setting of your go-eCharger - this can be done via the integration!

I can confirm to have also issues after upgrading to firmware 56.8 and PV surplus charging.
In my setup, the charger caps the current on each phase to max 5A.  When there was enough power from PV, I did do the phase switch to 3 phases, but still only 5A on each phase. Downgrade to 56.1 did work again, but unfortunately the sun was then soon gone.
You can nicely see how PV did not go into car:

How L1 was limited to 5A (I did downgrade FW  around 14:30 )

Go-e did see the surplus (so API transmits correct values), but charger did nothing:

Settings were correct:

There have been no errors reported.
It does not seem to be linked to the APi2 but more likely to some firmware changes that mess with the PV surplus charging algorithm. Wloud be great to have access to the FW changelog. The app does not show one for 56.2 and 56.8.
The weirdest thing is that the API can only limit current to minimum of 6A number.goe_259493_ama  (and mine was set to 16A), so not sure how a cap of 5A is even possible.

@karliwalti
On the one hand it might be nice for other users of this integration to get the confirmation, that something after the firmware update stopped working, on the other hand side we can't expect, that anybody from go-e will follow here this issue. So the information you have provided should (IMHO) provided directly to go-e (creating there an issue) - typically they reply quite fast.
What I am wondering about is, that if there is an issue with PV surplus charging with the new firmware, then I would expect that all users (even go-eController owners) should have the same problems (like you just described).

Should all of this also work with to go-e chargers connected? Just wondering if I should open a bugreport if the ha-automation works only for one of the two chargers with the same settings.

@mr-gosh your question is IMHO a bit "off topic" here... When you have two go-eChargers and have configured both in HA, and when you then use this integration to send your GRID-export data to both instances I would assume, that then both chargers will try to consume this available energy...
IMHO (but I could be totally wrong) you have to distribute the available power "manually" to Charger1 and Charger2 (e.g. by simply divide the sensor data by 2)... Obviously only if both chargers have cars connected. I would kindly ask you to start a new discussion for your "dual" use case. - TIA

@marq24 The issue with firmware 56.8 seems to exist no longer. From my perspective, the issue could be closed


Avoid a hir access inside get_static

This is the cg_gcc counterpart to https://github.com/rust-lang/rust/pull/81664. Best reviewed with whitespace changes ignored.

It seems like my rebase of my GCC fork broke some tests.

Please ping me in january if I forget to fix the bug.

You should now be able to rebase and have the CI pass.
If it segfaults (issue #245), just re-run the CI for now.

Thanks a lot!


Avoid going off-screen

Please can you add an option to avoid the modal going off-screen with anchored modals?
e.g.

Can you explain the issue a little bit more? @adil192

In the smaller screenshot, the red square modal is pushed off screen since the anchor is close to the edge. Whereas in a real app you'd expect the whole square to be visible regardless of screen size


feat: improve concurrent workers for raven controllers

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind bug
/kind documentation
/kind enhancement
/kind good-first-issue
/kind feature
/kind question
/kind design
/sig ai
/sig iot
/sig network
/sig storage

/kind feature
What this PR does / why we need it:
improve concurrent workers parameter for raven controllers
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Does this PR introduce a user-facing change?

other Note

LGTM

LGTM


feat: handle ipfs multiaddrs

Closes #38

woot! Nice
@xicombd, you won't hit this issue anymore :)


Use of wrong created by relation?

ttp://www.geneontology.org/formats/oboInOwl#created_by
https://www.ebi.ac.uk/ols/ontologies/dpo/properties?iri=ttp%3A%2F%2Fwww.geneontology.org%2Fformats%2FoboInOwl%23created_by

@matentzn what is the 'correct' created_by property?
I think we use http://www.geneontology.org/formats/oboInOwl#created_by across all the FlyBase ontologies

@matentzn what is the 'correct' created_by property?
I think we use http://www.geneontology.org/formats/oboInOwl#created_by across all the FlyBase ontologies

yes but look at the first letter in the example I gave! Missing h!

yes but look at the first letter in the example I gave! Missing h!

I see. Looks like the incorrect one is only on CARO:0020003 'cellular anatomical structure' - imported into dpo. Nothing else in FBcv or dpo.

I see. Looks like the incorrect one is only on CARO:0020003 'cellular anatomical structure' - imported into dpo. Nothing else in FBcv or dpo.

Ahh ok! Well, close it then! Not your problem. Another reason do push https://github.com/obophenotype/caro/issues/22
you can close this here then..

Ahh ok! Well, close it then! Not your problem. Another reason do push https://github.com/obophenotype/caro/issues/22
you can close this here then..


[WIP] Fuzz testing

Using eslump to find and fix various bugs (see #87)

This was a very useful exercise — found lots of small bugs that would have otherwise lain dormant. Thanks @lydell, and @vjeux for the recommendation!


Create a new pull request by comparing changes across two

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

96 of 96 (100.0%)  changed or added relevant lines in 3 files are covered.
2 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.4%) to 95.633%

Files with Coverage Reduction
New Missed Lines
%

js/src/dom/event-handler.js
1
92.27%

js/src/dropdown.js
1
92.65%

Totals

Change from base Build<PHONE_NUMBER>:
0.4%

Covered Lines:
1978

Relevant Lines:
2026

💛  - Coveralls


White-space:no-wrap is causing buttons to fall out of view on mobile

white-space: no-wrap on checkboxes div is causing buttons to fall off the page on mobile. Can be fixed by changing to normal, then making checkbox div class 'large-6' and language div class 'large-1' to give checkbox div more space. There is also a BR that needs removing.

hi @despo @georgiaobrien
I think this issue fixed by #73 , and i think it should be closed by now


data_flow_ops.py, line 91, in _as_name_list raise ValueError when run with Python3.5 but everything run well with Python2.7

When I run train.py with model faster_rcnn_resnet101 by Python2.7 interpreter on my customized data set, it work well, however when I run the same code in the same context and the same data set with Python3.5 interpreter, it report below error:

I am running with below setting:
GeForce GTX 1070
Ubuntu 16.04.2
tensorflow 1.4.1
and below is my config:
model {
faster_rcnn {
num_classes: 1
image_resizer {
fixed_shape_resizer {
height: 400
width: 400
}
}
feature_extractor {
type: 'faster_rcnn_resnet101'
first_stage_features_stride: 16
}
first_stage_anchor_generator {
grid_anchor_generator {
scales: [0.25, 0.5, 1.0, 2.0]
aspect_ratios: [0.5, 1.0, 2.0]
height_stride: 16
width_stride: 16
}
}
first_stage_box_predictor_conv_hyperparams {
op: CONV
regularizer {
l2_regularizer {
weight: 0.00004
}
}
initializer {
truncated_normal_initializer {
stddev: 0.01
}
}
}
first_stage_nms_score_threshold: 0.0
first_stage_nms_iou_threshold: 0.7
first_stage_max_proposals: 300
first_stage_localization_loss_weight: 2.0
first_stage_objectness_loss_weight: 1.0
initial_crop_size: 14
maxpool_kernel_size: 2
maxpool_stride: 2
second_stage_box_predictor {
mask_rcnn_box_predictor {
use_dropout: false
dropout_keep_probability: 1.0
fc_hyperparams {
op: FC
regularizer {
l2_regularizer {
weight: 0.0002
}
}
initializer {
variance_scaling_initializer {
factor: 1.0
uniform: true
mode: FAN_AVG
}
}
}
}
}
second_stage_post_processing {
batch_non_max_suppression {
score_threshold: 0.0
iou_threshold: 0.6
max_detections_per_class: 100
max_total_detections: 300
}
score_converter: SOFTMAX
}
second_stage_localization_loss_weight: 2.0
second_stage_classification_loss_weight: 1.0
}
}
train_config: {
batch_size: 1
optimizer {
momentum_optimizer: {
learning_rate: {
manual_step_learning_rate {
initial_learning_rate: 0.0001
schedule {
step: 0
learning_rate: .0001
}
schedule {
step: 5000
learning_rate: .00001
}
schedule {
step: 7000
learning_rate: .000001
}
}
}
momentum_optimizer_value: 0.9
}
use_moving_average: false
}
gradient_clipping_by_norm: 10.0
batch_queue_capacity: 2
prefetch_queue_capacity: 2
fine_tune_checkpoint: "models/model.ckpt"
from_detection_checkpoint: true
num_steps: 2000
}
train_input_reader: {
tf_record_input_reader {
input_path: "data/train.record"
}
label_map_path: "data/label_map.pbtxt"
}
eval_config: {
num_examples: 272
num_visualizations: 272
}
eval_input_reader: {
tf_record_input_reader {
input_path: "data/test.record"
}
label_map_path: "data/label_map.pbtxt"
shuffle: true
}
@datitran Can you help over this?

did you solve this?


Firewall rules whitelist with Skype for Business channel

Hi,
I have an hybrid infrastrucure with the .NET SDK v3 bot deployed on premises.
Using Skype for Business as channel, the bot call this url https://webpooldb40r04.infra.lync.com/platformservice/xxx/botframework/v3/conversations/yyyy/activities/0 which is blocked by default by my firewall.
Is it right to whitelist those address *.infra.lync.com in the firewall outbound rules, even if there is no mention of it in the documentation?
Thanks

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 253d4e99-7fc5-cc8d-5b07-29bf2d78687a
Version Independent ID: cdc0528d-cf1a-e015-1d8a-31ed062648f8
Content: Bot Service Frequently Asked Questions - Bot Service
Content Source: articles/bot-service-resources-bot-framework-faq.md
Service: bot-service
GitHub Login: @DeniseMak
Microsoft Alias: v-demak

For something like this, you very well may have to whitelist the calls for Skype for Business - but that will depend on your individual situation. While I cannot test it, it sounds like that would be the right firewall rules.
Questions like this should be posted to the support team at Stack Overflow using the botframework tag.


various

Three single line changes to the systemd service path and the nix common args, as the diff is small I didn't bother with separate PRs.

Thanks.


MissingParameter error.

When I tried this on my coldfusion server, I keep getting this error. Anyone else having this error?
{"__type":"com.amazon.paapi5#ValidationException","Errors":[{"Code":"MissingParameter","Message":"PartnerTag should be provided."},{"Code":"MissingParameter","Message":"PartnerType should be provided."}]}
on the index.cfm page this is how I called it.

<cfset test= myObj.init().usDefaults().SearchItems( "harry", "ItemInfo.Title" )>

I hard coded the secret key , partnertag, and access key on the .cfc page.

What server are you using?
What is myObj? Normally I think you would create the object like this:
<cfset myObj = new cfamazonproductad.amazonproductad5(
	accessKeyId= "..."
,	secretAccessKey= "..."
,	partnerTag= "..."
).usDefaults()>

Or what I do is make my own personalized object that extends amazonproductad5 and it embeds the accessKeyId / secretAccessKey / partnerTag in the init method like this:
component extends= "cfamazonproductad.amazonProductAd5" {
	function init() {
		super.init(
			accessKeyId= "..."
		,	secretAccessKey= "..."
		,	partnerTag= "..."
		).usDefaults();
		return this;
	}
}

Then just do:
test = new myAmazon5().searchItems( "harry", "ItemInfo.Title" );

I have coldfusion 18 development. myObj is declared like this in my index.cfm file.

It complains about a couple things.

 In the parameter,  it complains about it not being a Boolean. I replaced it with a number 0 and the error went away
 boolean debug= ( request.debug ?: false )

 , . There is an extra comma at the end of the parameter? I removed that common and then the error went away.

Complex object types cannot be converted to simple values.
451 : 		if( len( arguments.LanguagesOfPreference ) && isSimpleValue( arguments.LanguagesOfPreference ) ) {
452 : 		 	arguments.LanguagesOfPreference= listToArray( arguments.LanguagesOfPreference, this.defaultDelim );
453 : 		}
I removed the [] on line 252 in this.defaultLanguage= arguments.language ; and then the error went away.
Once all those errors go away, it gives me to parameter missing error as stated.

@nguyenthuan1 Thanks for the heads up.
I had only tested this with Lucee before, but I was able to quickly spin up Adobe ColdFusion 2018/2016/11 in commandbox and fix these issues. Get the latest source and try again?

@jordanclark , the last update works on my coldfusion.


Expense - "Unapprove" option exists on Manually reimbursed reports, on Collect policy with Instant Submit, Submit & Close

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.5-4
Reproducible in staging?: Y
Reproducible in production?: N
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team
Action Performed:
Precondition:

Add approval settings in Workflow is disabled (submit and close mode).

Submit an expense.
Go to transaction thread.
Go offline.
Pay elsewhere the report.
Click on the report header.
Note that there is no "Unapprove" option.
Go online.

Expected Result:
There should be no "Unapprove" option after returning online because there is no approver.
On Old Dot, there is no "Unapprove" option for paid expense when the mode is Submit and close.
Actual Result:
"Unapprove" option reappears after returning online when there is no approver.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/115492554/bed80797-075b-4b3e-87b0-72aab9fdf892

View all open jobs on GitHub
Issue OwnerCurrent Issue Owner: @Beamanator

@JmillsExpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.

We think this issue might be related to the #collect project.

Looks like this came from https://github.com/Expensify/App/pull/44229 where we added the Unapprove feature
cc @rushatgabhane @Beamanator

Don't think this needs to be a deploy blocker since this is an edge case scenario

Added to wave-control in the meantime.

A few notes when reproducing:

I don't believe we need the "Go offline then online" steps, I can reproduce in dev while doing everything online

brought to slack: https://expensify.slack.com/archives/C036QM0SLJK/p1720697773830479

Following up from the slack conversation, we want to effectively hide Unapprove from all paid reports. Separately, paid reports should have the 'Cancel payment' option but that wasn't showing. We're fixing that elsewhere.

PR up ^ - @rushatgabhane can you please review since you worked on the original App PR that this helps fix? :D

yes ofcourse

EOW Update:

We caught a bug for showing Unapproved here - Alex is figuring out how to fix now that we’ve got consensus on the expected behavior.
Show warning modal if Report has been exported to connected accounting integration is still held on the accounting connections issue, but the Auth PR is merged so hopefully we’ll be able to take this off hold next week!

@garrettmknight it loooks like that update was supposed to go on the main tracking issue? :D

PR is in staging 👍

Payment summary above is correct. @rushatgabhane please fill out checklist and submit an expense in NewDot.

The PR that introduced the bug has been identified. Link to the PR: This was my misunderstanding.

The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: N.A.

A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N.A.

Determine if we should create a regression test for this bug. Yes

If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again
   1.  Create a few manual requests
   3. Submit the report (this may happen automatically if the workspace is on instant submit)
   4. Have the admin approve the report
   5. As admin, Click on the report header - verify you see the "Unapprove" button
   6. Mark the report as "paid elsewhere"
   7. Click back on the report header - verify you DO NOT see the "Unapprove" button

Contributor+: @rushatgabhane due $250 via NewDot
TestRail GH

https://github.com/Expensify/Expensify/issues/415660

$250 approved for @rushatgabhane


adding parallels support

"en passant" dead code was trimmed and the Vagrantfile was made a bit
more idiomatic

Awesome contribution! Thank you António.


gh-2357 federatedstore federated operation merge into v2 alpha

Fire and Brimstone
Related Issue

Resolve #2357

Codecov Report

:exclamation: No coverage uploaded for pull request base (v2-alpha@0d398cd). Click here to learn what that means.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             v2-alpha    #2769   +/-   ##
===========================================
  Coverage            ?   64.26%
  Complexity          ?     2461
===========================================
  Files               ?      710
  Lines               ?    21808
  Branches            ?     2515
===========================================
  Hits                ?    14016
  Misses              ?     6654
  Partials            ?     1138

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

Mostly comment about avoiding use of deprecated Guava methods.
Not all instances of this in FederatedOperationhandlerTest are covered by the comments as were too many for adding comments.
In general, removing redundant uses of Guava should be its own issue. But for new code we can avoid introducing it.

Oh! didn't notice there was deprecated

Mostly comment about avoiding use of deprecated Guava methods.
Not all instances of this in FederatedOperationhandlerTest are covered by the comments as were too many for adding comments.
In general, removing redundant uses of Guava should be its own issue. But for new code we can avoid introducing it.

Oh! didn't notice they was deprecated

Oh so they haven't marked it as deprecated yet. ok.


Allow reading different lengths of int

I've tested my stuff with dosbox and I needed smaller read lengths.

This is a very good idea, I would request, that you add a flag for signedness to it (defaults to False). This can be forwarded to the int.from_bytes function (https://docs.python.org/3/library/stdtypes.html#int.from_bytes).
Also (if we're at it) we could make the byteorder configurable and also forward this to the int.from_bytes function. (Default could then be sys.byteorder)

So, I didn't want to mess with your forked version, but have a look at my int_size branch. Would something like this work for you? (I have no games, that require multi-level variables or smaller int sizes, so testing is limited for me)

Sadly that branch just starts the game and pyautosplit just closes itself. I've changed sptr in my config to memory.

Can I somehow see which absolute address ptrace tries to access? Maybe the starting point is different from what Cheat Engine uses.

This is unfortunate. Can you send me the config, that you are using? (Btw. maybe this is easier on an IM-Platform. Do you have matrix?)

Add @raumende:matrix.org and delete this message afterwards :)


Start local machines on startup (fixes #2857)

Signed-off-by: Caio Fernando Bertoldi Paes de Andrade<EMAIL_ADDRESS>Carries and closes #3047
Signed-off-by: Victoria Bialas<EMAIL_ADDRESS>

@nathanleclaire @moxiegirl @thaJeztah updated per comments from Nathan, and me. Please review.

minor nit, but LGTM otherwise. Thanks!

LGTM

LGTM
Thanks a lot @caiofbpa

Cool, incorporated Seb's "fails" comment (didn't mess w/line wrap for now)
Need a merge from someone other than me, for protocol.
@moxiegirl @nathanleclaire

Fortunately I am a protocol droid


RigidBody2D rotation resetted when applay_force

Tested versions
v4.3.dev6.mono.official [89850d553]
System information
Godot v4.3.dev6.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 5GB (NVIDIA; <IP_ADDRESS>23) - AMD Ryzen 9 3900X 12-Core Processor (24 Threads)
Issue description

when not call apply_force, the rotation will keep PI*0.5 at the last,
but when call apply_force, the rotation will reset to 0.0 at the last.
Steps to reproduce
run the MRP
Minimal reproduction project (MRP)
rottest.zip

Access to direct RigidBody2D state must be done in _integrate_forces, or else your changes can be discarded. Moving code with apply_force and rotation to that function fixes issue.


Cortx Object Storage Integration with Milvus.io

Describe your changes in brief
Cortx Object Storage Integration with Milvus.io 2022
Changes

[ ] Why is this change required? What problem does it solve?
[ ] If proposing a new change then please raise an issue first

How Has This Been Tested? (Optional)

[ ] Please describe in detail how you tested your changes.
[ ] Include details of your testing environment, and the tests you ran to
[ ] How your change affects other areas of the code, etc.

Screenshots (if appropriate)
Checklist

[*] tested locally
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

View rendered doc/integrations/cortx-milvusio/README.md

@mukul-seagate11 please merge this hackathon entry.

@vilaksh01, can you update your local branch?


How to use and upload the customized my own pre-trained model for feature extraction? (customized)

How to use and upload the customized pre-trained model for feature extraction?
Hello, I trained my own dataset for pre-training with Mockingjay and TERA model as described in https://github.com/s3prl/s3prl/tree/master/s3prl/pretrain
And now, the model training is finished, and I got the ckpt files at ./result/pretrain/mockingjay/states-200000.ckpt
Actually, what I want to do is upload my pre-trained model with ckpt files and extract the feature representation from the pre-trained model.  Such as below:
import s3prl.hub as hub

model_0 = getattr(hub, 'fbank')()  # use classic FBANK
model_1 = getattr(hub, 'modified_cpc')()  # build the CPC model with pre-trained weights
model_2 = getattr(hub, 'tera')()  # build the TERA model with pre-trained weights
model_3 = getattr(hub, 'wav2vec2')()  # build the Wav2Vec 2.0 model with pre-trained weights

device = 'cuda'  # or cpu
model_3 = model_3.to(device)
wavs = [torch.randn(160000, dtype=torch.float).to(device) for _ in range(16)]
with torch.no_grad():
    reps = model_3(wavs)["hidden_states"]

It means that not using for downstream tasks in s3rpl.
To this end, I refer the https://github.com/s3prl/s3prl/blob/master/s3prl/upstream/example/README.md and typed the command as:
python3 run_downstream.py -m train -n moc_korean \
    -u customized_upstream \
    -k /NasData/s3prl/s3prl/result/pretrain/mockingjay_korean/states-200000.ckpt \
    -g /NasData/s3prl/s3prl/result/pretrain/mockingjay_korean/config_model.yaml \
    -d example

After this procedure, I think the downstream tasks are doing with train/dev/test as below:

After this procedure, I think the downstream tasks are doing with train/dev/test as below:
As a result, if I want to upload my pre-trained model to the hub for use as the feature extraction, what should I do?
Or is there any way to use the pre-trained model directly for feature extraction?
Can you help with this for me?

my_ckpt = '/NasData/s3prl/s3prl/result/pretrain/mockingjay_korean/states-200000.ckpt'
my_config = '/NasData/s3prl/s3prl/result/pretrain/mockingjay_korean/config_model.yaml'

import s3prl.hub as hub

model = getattr(hub, 'mockingjay_local')(my_ckpt, my_config)

I assume your my_config is a file similar to this one here: config_model.yaml
If so, then you should not pass in the my_config, because it is already stored in states-200000.ckpt.
You can change to code to the following and it will work:
import s3prl.hub as hub
my_ckpt = '/NasData/s3prl/s3prl/result/pretrain/mockingjay_korean/states-200000.ckpt'
model = getattr(hub, 'mockingjay_local')(my_ckpt)

Note that the model_config argument should be a .yaml like this: options.yaml
Sorry for not making it clear.
Hope this helps.
Best,
Andy

This issue should be fixed by #313.
If not, feel free to re-open it, thanks!


Improvements/bug-fixes after 2.0

This adds one feature and several bug fixes:
Feature:

Default task after resuming a break is the one from before the break (Issue #38 )

Bug fixes:

Summary panics when on break (Issue #42 )
We can now no longer start a break when on a break (Issue #44 )
Summary times didn't include last/current block (Issue #43 )

It seems I accidentally already committed most of this to main. I'm leaving things as is and merging.


Scrolling inside Fancyzones Setting is jumpy

Microsoft PowerToys version
0.83.0
Installation method
PowerToys auto-update
Running as admin
No
Area(s) with issue?
Settings
Steps to reproduce

Scrolling inside Fancyzones Settings is jumpy.
It occurs whether setting is enabled or disabled.
Other setting pages have no issue.
Also, scrolling via touchpad does not cause above problem.

✔ Expected Behavior
Scrolling should be stopped at the bottom even when user keep scrolling mouse wheel.
❌ Actual Behavior
Scrolling inside Fancyzones Settings is jumpy as seen in video.
https://github.com/user-attachments/assets/e56804c2-b9c3-4d07-81ca-723577326e10
Other Software
No response

/dup #25353


reuse do_sync_command from eredis_client

Both eredis_client and eredis_sub_client use do_sync_command
the logic in both cases should be the same so there is no need
to duplicate this code.
Moreover eredis_sub_client:do_sync_command has a bug. The socket is not
set in {active, false} state before receiving data which in some cases
raise error einval.

This PR is does the same as #63 but in a different way.

Actually I have no idea why the one job on Erlang/OTP 17 failed... I'm using this patch on production without any problem (but not with 17)

I wonder if the build failure on Travis was just random. I'll merge this anyway and fix it if the build still fails.
Thanks for the patch! I'm also closing #63


Implement Value Extraction from Scopes

Summary
In order to implement lazy visualisations, a key feature of Enso Studio, we need the ability to execute arbitrary Enso code on values in the current frame. This execution mustn't be able to change the values in the scope, so we need to have some method for extracting those values from those scopes.
Value
This is the first of the two major building blocks to being able to provide lazy visualisations for Enso Studio.
Specification

Determine how best to extract values from the introspected scope in the interpreter without allowing any alteration to these values.
This value extraction should not impose significant performance or memory penalties, even in the case where the values contain huge amounts of data.
Implement this extraction functionality into the existing interpreter and provide an API.

Acceptance Criteria & Test Cases

The interpreter provides an API that allows for extracting values from the introspected interpreter scope.
This functionality is robust and rigorously tested.

Landed in #419.


Verifier.verifyInnerStep test

i just wanted to show how im testing it so we could be sure im not running it wrong
i changed the Verifier.verifyInnerStep output so it returns number instead of a bool since i wanted to see who's throwing.besides that, didnt touch any other solidity file.
most of the changes are to the js file.
if you think we need the changes i made to the js file, i can write a clean one.
anyways, like i said i just wanted to show you how im running the test.

like is said, if you think its a test that we need on scrypt, i can just cleanup the mess and add another PR.

Yes, please clean up this PR and then we can merge it. You do not need to create a new PR, just pushing to the branch will update the PR. Also you can rebase and squash the commits at some point (and then force-push).

cleaned-up, rebased and force-pushed.


Invesitgate failing ESSsans builds

See https://github.com/scipp/ess-project?tab=readme-ov-file#ess

It probably fails because it uses the latest release from sciline with the new stricter type constraints checking.
This has been fixed on the main branch of ESSsans, so releasing should fix the problem.

Ok, let us close this then, since it should be fixed by the next release.