Can i stream video from an android phone to another android phone using this library?

I am trying to establish multimedia streaming among multiple android devices. Where all of them play a synchronized video. An good example of my idea is Samsung video group play. Thanx in advance.

Yes you can do that.
One way is to write a RTSP client which connects to the other phone acting as RTSP server using videoview widget and enter the server URL. Although this is the simplest approach,  it is not real time as videoview widget has inderent buffering by default (since it's originally meant for streaming kind of applications). I have seen this buffering causing lags upto 3-10 seconds on the client side depending on the resolution.
The other option is to implement your own RTSP client which connects to the RTSP server, sets up the session, receives the encoded NAL units from the server, depacketizes them and sends them to video decoder for decode and render(on the surface provided). With this you could bring down the latency drastically.
Thanks
Kiran
On 15-Feb-2016 6:55 pm, Rishi16<EMAIL_ADDRESS>wrote:
—Reply to this email directly or view it on GitHub.

Could you give any links to tutorial helping me understand the making of this rtspclient? Cause whatever you said is too technical considering i am a noob to android .

@Rishi16  yes you can do it by using vlc


Issue with players setting trades in the shop

I have Numismatic Overhaul on my Forge 1.18.2 server. Currently players are having issues in setting up trades in the shops they have crafted. I have also attempted to set a trade, however the input box for the trade item doesn't currently accept any items.
I am unsure of the reason, or if it is something we are doing wrong.

This is the repository for Numismatic Overhaul on Fabric.


Mark initWithFrame and initWithCoder as unavailable in SMXTabBar.

Fix the remaining Xcode warning.

Thanks for this PR, what version of React Native were you testing against?
On Tue, Nov 10, 2015 at 2:21 AM, admmasters<EMAIL_ADDRESS>wrote:

Fix the remaining Xcode warning.
You can view, comment on, or merge this pull request online at:
https://github.com/corymsmith/react-native-icons/pull/133
-- Commit Summary --

Mark initWithFrame and initWithCoder as unavailable in SMXTabBar.
-- File Changes --
M iOS/ReactNativeIcons/IconTabBarItem/SMXTabBar.h (2)
M iOS/ReactNativeIcons/IconTabBarItem/SMXTabBar.m (44)
-- Patch Links --
https://github.com/corymsmith/react-native-icons/pull/133.patch
https://github.com/corymsmith/react-native-icons/pull/133.diff

Reply to this email directly or view it on GitHub:
https://github.com/corymsmith/react-native-icons/pull/133

Just published 0.6.2 to NPM and it includes this PR

This broke the build on 0.14.2 (switching between commented and uncomment code of this PR in SMXTabBar.m fixes it)


Make the code that colors functions and member variables smarter

As the title says.
The issue right now
The code for coloring the text for functions and member variables is fairly simplistic at the moment, the function coloring colors every piece of text before a pair of parenthesis and the member variable coloring colors every piece of text after a period.
What can be done about it?
How about making the system smarter by using information gleaned from parsing the code in the editor.

Only color member variables that are known to exist. Otherwise leave the text white.
Only color functions that are known to exist (and only if the inheritance is correct). Otherwise leave the text white.
For both, you could even have the editor throw an error if it's a safe bet that said white text would stop the game (I know we may not be able to catch everything, that's why I said a 'safe' bet).

In a sense, use the color feature to help developers write working code more of the time so there's less time quashing errors.
Comments?

Sounds like a good idea, hovewer it will never work well because of weak typing (how you will color functions and members of nodes for which you have only references, what if in some regions of your code you are operating mostly on that kind of environment?) I know there are plans to add high performance static version of Gdscript to Godot <- with this version of language such things would be a breeze.

The thing is no matter how we do it, a slightly more complicated script will easily throw the system off. Consider for example the following tree and code:

Node2D: SceneRoot (with script)

Button: Button [pressed connected to button_pressed]
Button2: Button2 (hidden, with another script, omitted for brevity) [pressed connected to button2_pressed]
Node2D: SomeNode

extends Node2D

func do_stuff():
  get_node("SomeNode").set_margin(MARGIN_LEFT, 5)

func button_pressed():
  get_node("SomeNode").replace_by(Control.new(), true)
  get_node("Button2").show()

func button2_pressed():
  do_stuff()

At this point, should set_margin be shown in white or red text? Or maybe in pink?
We might say, red, because it is "impossible" to click the button when clicked. But.. what if another script shows the button, or even calls do_stuff directly?
Ok, then it must be white, since it is a bug... but we still don't know if it is for sure.
So, pink then? Or maybe white, since we couldn't track it down that far?
Also, what about scripts that are shared between incompatible scenes? In some of them there might be a "XX" node, but in others it might be missing.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


Add confirmation dialog for deletion of a BLAST job

Description
Blast job deletion confirmation message. As per the jira ticket, on clicking the thrash icon, we show a confirmation to delete or not to delete.
And the extra logic (mentioned in the jira), if it is the last job on either the unviewed job view or the job list we redirect to new job form and also when deleting a job on a result view (one submission), we redirect to new job form.
Note:
I am checking which view we are currently on by using useLocation which is looking at the URL. currently the view is passed as props to BlastAppBar.tsx, maybe for another ticket/PR we can have the view in redux state so that its easily retrieved.
Related JIRA Issue(s)
https://www.ebi.ac.uk/panda/jira/browse/ENSWBSITES-1686
Deployment URL(s)
http://blast-deletion.review.ensembl.org
Views affected
blast (try submitting a few jobs and have some in unviewed and job lists)

Something happened to our right-hand white space... I thought we had it sorted. Doesn't seem to be something introduced in this PR; but can be fixed here. Or separately.

Small screen broken
https://user-images.githubusercontent.com/6834224/188904808-b8446149-6746-4b2e-9894-904dde0851cb.mov

Something happened to our right-hand white space... I thought we had it sorted. Doesn't seem to be something introduced in this PR; but can be fixed here. Or separately.

Happy to fix this as part of this PR, i think its just one padding-right that needs adjusting.

Small screen broken

it looks fine to me.  What other solution do we have for smaller screen when you click on the trash icon, should it wrap the message? we can check with Andrea?

waiting for PR: https://github.com/Ensembl/ensembl-client/pull/828 to be merged and then need to update this branch (rebase dev) and add the shared component

Is there any use in greying out the Results button that is currently selected?

Thanks @azangru for making the changes needed. I am also happy with the changes. Lets see if others want to review it and then we can merge. thanks


new lesson: Multithreading

⭐ Request Type
Add a lesson on Multithreading Concepts
💻 Location
https://github.com/Utkarsh1504/DSA-Java/tree/main/lessons
❌ Additional Info
No response

Hi @Utkarsh1504
If this issue is not solved yet can you please assign it to me?


instanceof doesn't work as expected for some inheritance patterns

Currently some of the available inheritance patterns don't maintain the expected instanceof results.
For example, this works:
A = legion.Class.extend({});
B = A.Class.extend({});
b = new B();
b instanceof legion.Class; //true
b instanceof A //true
b instanceof B //true
But these don't:
A = legion.Class.extend({});
B = legion.Class.extend(A);
b = new B();
b instanceof legion.Class; //true
b instanceof A //false
b instanceof B //true
A = legion.Class.extend({});
B = legion.Class.extend({});
AB = legion.Class.extend([A, B]);
ab = new AB();
ab instanceof legion.Class; //true
ab instanceof A; //false
ab instanceof B; //false
ab instanceof AB; //true
The issue is that when passed an existing Class, there is no way to merge that Class's prototype chain with the current class's chain.
If we don't care about maintaining instanceof, we could ignore this, or create our own Class.instanceof() method to use.
Or we could also change the paradigm so that it would make more sense to the user, for example using Java's single inheritance + implements.
For example:
// extend(['array', 'of', 'implementations'], {})
Player = legion.Class.extend([legion.Input, legion.Net], {name: "doc"});
var p = new Player();
p instanceof legion.Class; //true
p instanceof Player; //true
p instanceof legion.Input; //false, as intended
p instanceof legion.Net; //false, as intended
Or another model, having an implements function so:
Player = legion.Class.extend({name: "doc"}).implements([legion.Input, legion.Net]);
or it could also be written as:
Player = legion.Class.implements([legion.Input, legion.Net]).extend({name: "doc"});
This would also allow you to more logically do something like:
Character = legion.Class.extend({name: "doc"});
PlayerCharacter = Character.implements([legion.Input]);
NPC = Character.implements([AI]);
What are your thoughts on it?

I would go with the last bit, to make it seem more logical to the user. The easier the API is to understand to the user, the better.

Alright, I'll implement it that way.


Add videos to intro & concepts docs

Thanks @agardnerIT for your work on these videos! :)
This PR
Adds these videos to the docs:

"What is OpenFeature?" video to intro.mdx
"What is the Evaluation API?" video to 01-evaluation-api.mdx
"What is a Provider?" video to 02-provider.mdx
"What is Evaluation Context?" video to 03-evaluation-context.mdx
"What are Hooks?" video to 04-hooks.mdx

The evaluation context video isn't loading in the preview for some reason. Viewing it directly on YouTube works, but the audio only comes out of the left side of my headphones. None of the other videos had this issue.
https://deploy-preview-127--openfeature.netlify.app/docs/reference/concepts/evaluation-context

I see the same. It seems like this video is configured not to allow embedding.

Ok, I've updated the video setting to allow embedding (that box was unchecked in YT, apologies!). However, I am still hearing only left-side audio for that video still.
@agardnerIT can you check out the audio on the Evaluation Context video and see if there's an easy way to fix that audio issue? Happy to work with you on this.

Ok, I've updated the video setting to allow embedding (that box was unchecked in YT, apologies!). However, I am still hearing only left-side audio for that video still.
@agardnerIT can you check out the audio on the Evaluation Context video and see if there's an easy way to fix that audio issue? Happy to work with you on this.

Personally I don't think this is a blocker. We can fix the audio in that video whenever. 5 videos with 1 with mono-audio is still an improvement over none.

Video has been updated. Is this good to go now?

@beeme1mr I've updated the "What is a Provider" video today. :)


Services uuid

Official services uuid are available here : https://app.stopcovid.gouv.fr/json/version-22/config.json

Thanks. You want to do a pull request? It seems I'll have to rework a bit of code to adapt to the 1.0 that have been pushed.
The 0xfd64 uuid has not been put online on https://www.bluetooth.com/specifications/assigned-numbers/16-bit-uuids-for-members/
I don't have the application (yet), but I guess the ble.characteristicUUID is the identifier of the serviceData.

I just pushed an updated version.


Updated documentation link in README

Current documentation link points to a 404 page, updated it with a working version.

Thanks for your contribution! :)


Setup actions

Testing actions

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@f4d91a7). Click here to learn what that means.
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #12   +/-   ##
=======================================
  Coverage        ?   79.16%
=======================================
  Files           ?        5
  Lines           ?      264
  Branches        ?       16
=======================================
  Hits            ?      209
  Misses          ?       41
  Partials        ?       14

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

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


Edit: EnerGeek Retro - Logo

Channel ID (required)
EnerGeekRetro.cl
Logo
https://energeek.cl/uploads/logos/Retro-new.png

Updated in https://github.com/iptv-org/database/commit/1b7a4c8564477ad18d4ebffbb8ac0ee8d1e0bb65


[firebase_messaging] FCM dashboard doesn't show received notifications count

Notifications are working properly, but FCM dashboard doesn't show received notifications count

Hi @lesnitsky
can you please provide your flutter doctor -v
and your flutter run --verbose?
Also, to better address the issue, would be helpful
if you could post  a minimal code sample
or the steps to reproduce the problem.
Thank you

this issue is valid for the whole time app has been released, so flutter doctor -v will be useless (issue is valid on all version of flutter released in 2019)
Minimal code sample could be found in firebase_messaging readme. I'm not doing anything extravagant, just sending notifications to FCM from server
example payload:
{
  "priority": "high",
  "data": {
    "click_action": "FLUTTER_NOTIFICATION_CLICK",
    "feedId": "<feed-id>
  },
  "to": "<device token>",
  "notification": {
      "body": "Message",
      "title": "Chat title",
      "sound": "default",
      "badge": 3
  },
}

Hey 👋
As part of our roadmap (#2582) we've just shipped a complete rework of the firebase_messaging plugin that aims to solve this and many other issues. Specifically we've updated to the latest Firebase SDKs which should resolve any underlying issues. Firebase Analytics is also a requirement for these to work.
If you can, please try out the dev release (see the migration guide for upgrading and for changes) and if you have any feedback then join in the discussion here.
Given the scope of the rework I'm going to go ahead and close this issue in favor of trying out the latest plugin.
Thanks.


Chrome Enterprise enrolment error: "Oops! The system filed to determine device model or serial number."

Raspberry Pi model 4B with 4GB RAM

Your Chromium OS for Raspberry Pi release version, e.g. Chromium OS 92.0.4515.138
Usb kb, touchscreen monitor via hdmi

Error: Chrome Enterprise enrollment error: "Oops! The system failed to determine device model or serial number."

fixed, try r92-r2 release


Remove log2 from tile api.

please opine

RUSTFLAGS="--cfg=cargo_c" cargo build or check to test w/out using cargo cbuild.

@tdaede @lu-zero I spot https://github.com/xiph/rav1e/pull/1469 - presumably this should also be done pre-release.

yes.

Updated. Note that this makes context creation fallible (can return null) in the capi.
Alternatively we could make the setter fail.

Note that this makes context creation fallible

Passing a value which is not a power-of-2 could have the same behavior as passing a log2 value greater than 6 (invalid too). It did not required to make the context creation fallible.
(I don't know whether it is better or not to make it fallible, bit IMO it is independant of passing non-log2 values.)
Also, the choice to pass tiles instead of tiles-log2 is just a UI decision (more user-friendly). For simplicity, we could still use log2 values internally for the context config.
What do you think?

Coverage increased (+0.004%) to 71.296% when pulling 6b5d8ced477732eac0c2d78d68a8c78dd524be95 on tdaede:tiles_wxh into 2de7d88f36509e6a0bae0df0c06db5c0df057ba4 on xiph:master.


Update Labcontrol unit tests.

Unit tests in TestPlateConfiguration should be updated to account for new database column 'creation_timestamp'. Tests can also be updated to be more flexible.

@wasade Just to clarify, I believe we're going to rollback the creation_timestamp change, correct? If so, we can close this issue out as moot, won't-fix.

:+1:


GCC optimization levels - See why the tests are not passing for -O1, -O3

Currently in the GCC compile we are running without any optimizations when we are compiling are test.
Will note that we are adding the optimization level -O3 only in the linker and the final compilation, but the Original tests is already in assembly form that I don't know if there are other optimization that can take place when the code is already in assembly form.
See:
[COMMAND] riscv-none-embed-gcc.exe -S -ffreestanding -march=rv32i -I ../../../../../app/defines ../../../../.././verif/core_rrv/tests/hw_sw_lfsr_perf.c -o hw_sw_lfsr_perf_rv32i.c.s
[COMMAND] riscv-none-embed-gcc.exe -O3 -march=rv32i -T ../../../../../app/link.common.ld -I ../../../../../app/defines -Wl,--defsym=I_MEM_OFFSET=0 -Wl,--defsym=I_MEM_LENGTH=65536 -Wl,--defsym=D_MEM_OFFSET=65536 -Wl,--defsym=D_MEM_LENGTH=61440 -nostartfiles -D__riscv__ -Wl,-Map=hw_sw_lfsr_perf.map ../../../../../app/crt0/crt0_default.S hw_sw_lfsr_perf_rv32i.c.s -o hw_sw_lfsr_perf_rv32i.elf

We need to modify the build to compile the "-S" with optimization.
Test it with -O1, -O2 and -O3.
i think -O1 should be a good starting point
See descutions  To read about it.

@roman012285  - just FYI

@roman012285 - FYI
I ran this test before and after updating the build optimization flag:
python build.py -dut core_rrv -test alive -app -hw -sim
See the example of the elf without any optimization vs -O1 (minimal optimization)
[COMMAND] riscv-none-embed-gcc.exe -S -ffreestanding -march=rv32i -I ../../../../../app/defines ../../../../.././verif/core_rrv/tests/alive.c -o alive_rv32i.c.s

vs
[COMMAND] riscv-none-embed-gcc.exe -O3 -S -ffreestanding -march=rv32i -I ../../../../../app/defines ../../../../.././verif/core_rrv/tests/alive.c -o alive_rv32i.c.s

2 interesting points:

In the "main" -> there is no use of the z so the compiler optimized away all of the logic!
in the "sum" -> the compiler found that there is no need for a stack update and simply used the "add" and "ret"

I gave this a try and debug.. and things are confusing. the optimization makes it harder to understand.
First i tried comparing with the reference model.
But then i found out that the reference model is not able to execute the optimized program!
this is the test that i will debug & enable in the reference model. (not the rrv_core).
Once i have that up and running, i will be able to understand whats wrong with the rrv_core by comparing it to the reference model.
./build.py -dut rv32i_ref -test alive_vga -app -hw -sim
And this is the test:

Super simple - but its failing so its great to use for debug

Found the issue!
The linker has a read-only section that for unknown reason was generated outside the "dmem" region! (0xd14 is outside the DMEM!!)

We explicitly wrote that the rodata section should be part of the "global_data"

But for some unknown reason, the -O1 flag moved some of it outside.
ChatGPT suggested fixing the linker SECTIONS a little:

And now it all works!

Seems like its failing now the mini_core..
I really tried to understand what happened there..
But this time seems like the compiler just added random 4 reads to regions and location that i definitely did not want him to do..
So i added the cfg option to add the -O1, so currently its enabled in specific cfg..

I added the optimization only to the "-cfg core_rrv_boot_trap"
See how the run time was cut in half!!!

vs this:

Still need to figure out if we can enable the compile optimization also for the mini_core and big_core..
I don't like it that the compile added 3 reads that are not used.. but i don't know what we can do about it..

nice!


[python] Export AxisColumnNames

Client code needs to instantiate objects this of class, so it should be exported in top-level __init__.py

https://github.com/single-cell-data/SOMA/pull/116 (somacore) is merged.
We need a python-v0.0.0a11 tag for somacore before we can use this for the next PR on this issue which will be a tiledbsoma PR. cc @thetorpedodog .

This is published as a12. Note that while having the name exported at the top level in somacore is something we should be doing anyway, it is not needed to export the name from tiledbsoma. tiledbsoma could already say:
from somacore.query import AxisColumnNames

__all__ = (
    ...,
    "AxisColumnNames",
    ...,
)

So there is no need to have the tiledbsoma side blocked by the somacore side.


Added a fix for the parsing of the timestamp from the Amazon request.…

… Sometimes the timestamp can vary. Amazon started sending the date in epoch in their test harness about 3 days ago. This code change can do the Iso 8601 format and the epoch date.

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

I would recommend adding a second argument of CultureInfo.InvariantCulture to TryParse, to ensure consistent results no matter the locale of the server.

Thanks for your contribution @jaysonhelseth. I accepted the pull request and rewrote some parts to use Json.Net parsing so as not to change previous behavior with respect to how date/time inputs are handled.

Thanks for accepting my code. I like the feedback that you gave. I am new to working with dates that are security sensitive inside of JSON so it was easy for me to parse things out incorrectly.


Setup IBC

Crate

ibc

Version
v0.5.0
Summary
Hermes fails with TxNoConfirmation error constantly when trying to communicate with a full node that does not have indexing enabled.
The error can be tracked down using a patched version of Hermes, and looks like this:

Jun 30 13:39:20.800 TRACE waiting for commit of block(s)
Jun 30 13:39:21.001 ERROR query_txs fail: Internal error: transaction indexing is disabled (code: -32603)

Many thanks to @Fraccaman for helping us uncover this corner-case.
A separate, related problem was due to misconfiguration (see https://github.com/heliaxdev/ibc-setup/pull/1).
Acceptance criteria:

[ ] Hermes should catch the "transaction indexing is disabled" error and propagate it up the stack (instead of masking it under the hood of TxNoConfirmation)
[ ] Ideally, Hermes should be able to detect the health of a full node upon startup (similar to how we plan in #1057), so that the end-user is warned when Hermes is unable to correctly communicate with a full node

Original discussion
Summary of Bug
Probably this is not a bug, but I can't understand whats wrong. I'm trying to open a channel between a cosmos mainnet node and a "own gaia testnet" node. I am able to build the relayer and configure it correctly (It doesn't complain so I'm assuming it is correct) but as soon as I try to run hermes channel handshake id-1 id-2 transfer transfer it throw the following error:
{"status":"error","result":"chain runtime/handle error: Light client supervisor error for chain id heliax: empty witness list"}.
p.s: @andynog suggested to open an issue
Version

v0.1.1

Steps to Reproduce
I have created a repository with a series of bash scripts to reproduce this use case here.

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Something is likely going wrong with the commands that configure the light clients (ie. the light add commands).
I see that the script adds secondary peers for each node using the same network address, is that intended?
Could you remove the &>/dev/null redirect at the end of the commands in ibc.sh and report back with the output?

So this is the output (i fixed also a typo):
Building the Rust relayer...
Removing light client peers from configuration...
Adding primary peers to light client configuration...
    Finished dev [unoptimized + debuginfo] target(s) in 0.18s
     Running `target/debug/hermes -c /home/ec2-user/.hermes/config.toml light add 'localhost:26657' -c stargate -f -p -s /home/ec2-user/node-stargate/data -y`
     Success Added light client:
  chain id: stargate
  address:  tcp://localhost:26657
  peer id:  648A550A0545AF774223E556117BBDE3156A3520
  height:   5229734
  hash:     CF9104D58D3FE7A35E062C02C09E52EA062C5A8F212DF5DDA358EE9A52450F84
  primary:  true
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/hermes -c /home/ec2-user/.hermes/config.toml light add 'localhost:26357' -c heliax -f -p -s /home/ec2-user/node-heliax/data -y`
     Success Added light client:
  chain id: heliax
  address:  tcp://localhost:26357
  peer id:  97DAF05D3D5CCE2DF5AC3323784C2C01A1B7D5CA
  height:   6904
  hash:     81995B52593A2F3D1629A31A20CAF034F9AB64A6235D34457C4F36B065FFD439
  primary:  true
Adding secondary peers to light client configuration...
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/hermes -c /home/ec2-user/.hermes/config.toml light add 'localhost:26657' -c stargate -s /home/ec2-user/node-stargate/data -y --peer-id 2427F8D914A6862279B3326FA64F76E3BC06DB2E`
     Success Added light client:
  chain id: stargate
  address:  tcp://localhost:26657
  peer id:  2427F8D914A6862279B3326FA64F76E3BC06DB2E
  height:   5229737
  hash:     6D874A3D9167B8C955D9AF512C20D7B7069260B831B5F1B338FC77F430AC317E
  primary:  false
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/hermes -c /home/ec2-user/.hermes/config.toml light add 'localhost:26357' -c heliax -s /home/ec2-user/node-heliax/data -y --peer-id A885BB3D3DFF6101188B462466AE926E7A6CD51E`
     Success Added light client:
  chain id: heliax
  address:  tcp://localhost:26357
  peer id:  A885BB3D3DFF6101188B462466AE926E7A6CD51E
  height:   6905
  hash:     6AED5CE877589AE582C5DF9881F008A7CF371E1DCB0F7F03DD1B81FF5A4E71ED
  primary:  false
Importing keys...
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/hermes -c /home/ec2-user/.hermes/config.toml keys add stargate /home/ec2-user/node-stargate/key_seed.json`
{"status":"success","result":"Added key node_key (cosmos1ztu56h7kpuguf9y39lhxgayhngmysnxsgl8f9u) on stargate chain"}
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/hermes -c /home/ec2-user/.hermes/config.toml keys add heliax /home/ec2-user/node-heliax/key_seed.json`
{"status":"success","result":"Added key node_key (cosmos196hkxg7c53h6u75umdrhwum6kp8xyxzw2kvu7r) on heliax chain"}
Done!

Now, the error changed and is the following:
{"status":"error","result":"chain runtime/handle error: Light client instance error for rpc address tcp://localhost:26657: invalid light block: invalid validator set: header_validators_hash=862A9C43A9A29FC6D508352B056A738DB35B3F96F0FA02F0DA2FC1ED8035A55C validators_hash=0198C4156F82C8E0B11C23A24F43FEDE7D92D9146E64FD5D37C5ED3360F53AA9"}

Can you post your full ~/.relayer/config.toml file after running the script?

If you mean the ~/.hermes/config.toml here it is:
[global]
timeout = '10s'
strategy = 'naive'
log_level = 'error'

[[chains]]
id = 'stargate'
rpc_addr = 'tcp://localhost:26657'
grpc_addr = 'tcp://localhost:9090'
account_prefix = 'cosmos'
key_name = 'node_key'
store_prefix = 'stargate'
gas = 3000000
clock_drift = '5s'
trusting_period = '14days'

[chains.trust_threshold]
numerator = '1'
denominator = '3'

[chains.peers]
primary = '648A550A0545AF774223E556117BBDE3156A3520'

[[chains.peers.light_clients]]
peer_id = '648A550A0545AF774223E556117BBDE3156A3520'
address = 'tcp://localhost:26657'
timeout = '10s'
trusted_header_hash = 'CF9104D58D3FE7A35E062C02C09E52EA062C5A8F212DF5DDA358EE9A52450F84'
trusted_height = '5229734'

[chains.peers.light_clients.store]
type = 'disk'
path = '/home/ec2-user/node-stargate/data/648A550A0545AF774223E556117BBDE3156A3520'

[[chains.peers.light_clients]]
peer_id = '2427F8D914A6862279B3326FA64F76E3BC06DB2E'
address = 'tcp://localhost:26657'
timeout = '10s'
trusted_header_hash = '6D874A3D9167B8C955D9AF512C20D7B7069260B831B5F1B338FC77F430AC317E'
trusted_height = '5229737'

[chains.peers.light_clients.store]
type = 'disk'
path = '/home/ec2-user/node-stargate/data/2427F8D914A6862279B3326FA64F76E3BC06DB2E'

[[chains]]
id = 'heliax'
rpc_addr = 'tcp://localhost:26357'
grpc_addr = 'tcp://localhost:9091'
account_prefix = 'cosmos'
key_name = 'node_key'
store_prefix = 'heliax'
gas = 3000000
clock_drift = '5s'
trusting_period = '14days'

[chains.trust_threshold]
numerator = '1'
denominator = '3'

[chains.peers]
primary = '97DAF05D3D5CCE2DF5AC3323784C2C01A1B7D5CA'

[[chains.peers.light_clients]]
peer_id = '97DAF05D3D5CCE2DF5AC3323784C2C01A1B7D5CA'
address = 'tcp://localhost:26357'
timeout = '10s'
trusted_header_hash = '81995B52593A2F3D1629A31A20CAF034F9AB64A6235D34457C4F36B065FFD439'
trusted_height = '6904'

[chains.peers.light_clients.store]
type = 'disk'
path = '/home/ec2-user/node-heliax/data/97DAF05D3D5CCE2DF5AC3323784C2C01A1B7D5CA'

[[chains.peers.light_clients]]
peer_id = 'A885BB3D3DFF6101188B462466AE926E7A6CD51E'
address = 'tcp://localhost:26357'
timeout = '10s'
trusted_header_hash = '6AED5CE877589AE582C5DF9881F008A7CF371E1DCB0F7F03DD1B81FF5A4E71ED'
trusted_height = '6905'

[chains.peers.light_clients.store]
type = 'disk'
path = '/home/ec2-user/node-heliax/data/A885BB3D3DFF6101188B462466AE926E7A6CD51E'

If you mean the ~/.hermes/config.toml here it is:

Yes it's what I meant, sorry about that! Your config looks good to me.
The light client is throwing this error when verifying the initial trusted lightblock, and gets a mismatch between the hash of validator set stored in the header and the hash  of the validator set for that height that it computes.
I am not sure what could cause that. Maybe a mismatch in the Tendermint version that the nodes are running vs the version supported by tendermint-rs? Can you tell me what version of Tendermint the nodes are running?

No worries @romac!
Can you tell me how can I check that?
I can give you the output of gaiad version --long (hope this is enough):
name: gaia
server_name: gaiad
version: 4.0.0
commit: a279d091c6f66f8a91c87943139ebaecdd84f689
build_tags: netgo,ledger
go: go version go1.15.8 linux/amd64
build_deps:
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>=><EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>

The Tendermint version looks good. We are going to try to reproduce the issue on our side and get back to you. /cc @andynog

Hi @Fraccaman, just following up on this. For the stargate chain, is this a local chain you're running or are you testing against a testnet ?

One node is running stargate mainnet, the other a local chain.

When you say your node is running on Stargate mainnet, are you referring to cosmoshub-4 ? Can you please send what you get if you run this API query https://localhost:26657/status
Just want to ensure we're talking about the same thing :-)

Sorry for the late response, here is the response:
{   "jsonrpc": "2.0",   "id": -1,   "result": {     "node_info": {       "protocol_version": {         "p2p": "8",         "block": "11",         "app": "0"       },       "id": "3ed8666e8e7fe0ae4dac31014841c1828d240cc9",       "listen_addr": "tcp://<IP_ADDRESS>:26656",       "network": "cosmoshub-4",       "version": "",       "channels": "40202122233038606100",       "moniker": "heliax-1",       "other": {         "tx_index": "on",         "rpc_address": "tcp://<IP_ADDRESS>:26657"       }     },     "sync_info": {       "latest_block_hash": "E1B2EE22FF1B025DA902FA6B732D09BBCF7DBF8B2E406A7D65A26BED8D499CAF",       "latest_app_hash": "A99F8C091DD628CA595098368BC57EC69E42EFC1CAAC9D66FA26929756430DD1",       "latest_block_height": "5201056",       "latest_block_time": "2021-02-18T13:08:36.985091499Z",       "earliest_block_hash": "1455A0C15AC49BB506992EC85A3CD4D32367E53A087689815E01A524231C3ADF",       "earliest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",       "earliest_block_height": "5200791",       "earliest_block_time": "2019-12-11T16:11:34Z",       "catching_up": true     },     "validator_info": {       "address": "84B23508421F2B0C20F1C09308D25F0F6E8AEB41",       "pub_key": {         "type": "tendermint/PubKeyEd25519",         "value": "Abh8gRTD4ZEu5ytdlb+OSkrX7DiRt8vtiPvCLUuQjOY="       },       "voting_power": "0"     }   } }

Related to https://github.com/informalsystems/tendermint-rs/issues/831

Hi @Fraccaman, we believe this bug is fixed now. We did encounter a bug and fixed in master. We could reproduce it last week and made modifications in https://github.com/informalsystems/tendermint-rs/issues/831
Please let us know if this is fixed now so we can close the ticket. Thanks!

Ill try again asap and report back! Thanks! :)

So, I tried again (same setup). Now I get the following error:
{"status":"error","result":"chain runtime/handle error: Light client instance error for rpc address tcp://localhost:26657: invalid light block: not withing trusting period: expires_at=2021-03-04T15:47:08.9667102Z now=2021-04-07T15:16:02.429079517Z"}

So, I tried again (same setup). Now I get the following error:
{"status":"error","result":"chain runtime/handle error: Light client instance error for rpc address tcp://localhost:26657: invalid light block: not withing trusting period: expires_at=2021-03-04T15:47:08.9667102Z now=2021-04-07T15:16:02.429079517Z"}

Hi @Fraccaman, you might need to update your light client if you haven't done so. It's the same command to add so run again
hermes light add tcp://localhost:26657 -c stargate ...

I started from a new machine, so I don't think I needed to update the trusted headers.
Anyway, I tried rerunning hermes again (you can see the scripts here), and its kinda strage. Sometime I get the same about the trusting period but sometime I get
{"status":"error","result":"chain runtime/handle error: Light client instance error for rpc address tcp://localhost:26657: I/O error: fetched validator set is invalid: proposer with address 'C2356622B495725961B5B201A382DD57CD3305EC' not found in validator set"}

I started from a new machine, so I don't think I needed to update the trusted headers.
Anyway, I tried rerunning hermes again (you can see the scripts here), and its kinda strage. Sometime I get the same error about the trusting period but sometime I get
{"status":"error","result":"chain runtime/handle error: Light client instance error for rpc address tcp://localhost:26657: I/O error: fetched validator set is invalid: proposer with address 'C2356622B495725961B5B201A382DD57CD3305EC' not found in validator set"}

That's strange is this setup a clean one?

This error happens when the light client fetches the header and the validator set at height H from the chain, where the latter does not contain a validator whose address matches the proposer_address of the fetched header. It is not clear to me in which circumstances this can happen. As far as I understand, the validator that proposed a block at height H should always be present in the validator set at height H, or at least that's what the code currently enforces.

Fetching the header and validator set:
https://github.com/informalsystems/tendermint-rs/blob/e4eb6b927dd88f89d7bc9016f7e6517bae9b96b9/light-client/src/components/io.rs#L107-L111
Building the validator set:
https://github.com/informalsystems/tendermint-rs/blob/e4eb6b927dd88f89d7bc9016f7e6517bae9b96b9/light-client/src/components/io.rs#L175-L179
Ensuring there is a validator in the set with a matching address:
https://github.com/informalsystems/tendermint-rs/blob/e4eb6b927dd88f89d7bc9016f7e6517bae9b96b9/tendermint/src/validator.rs#L92-L96

What version of hermes? I think this may come from the pagination issue in tendermint rpc (where we were getting an incomplete validator set) that was fixed and picked up in hermes v0.2.0.

What version of hermes? I think this may come from the pagination issue in tendermint rpc (where we were getting an incomplete validator set) that was fixed and picked up in hermes v0.2.0.

Oh right, that's probably it! This was fixed in tendermint v0.19.0 and will therefore indeed be fixed in Hermes v0.2.0.

@andynog @Fraccaman Can you try with Hermes master and see if the issue does indeed go away?

Im still using 0.1.1 so maybe thats the problem!

So, I'm using the hermer binary from master but I have problems running the same script as before. It is now complaining about missing subcommands. For example:
cargo run --bin hermes -- -c ~/.hermes/config.toml light rm -c stargate --all -

return
error: unrecognized command `light`

Did you change anything in the command line?

Do you have any thoughts on this? The machine I'm using is running Amazon-linux as OS.
Update: I think its a problem with my openssl configuration but I'm not really sure. I have solved this adding to the ibc-relayer-cli create the openssl dependency (https://docs.rs/crate/openssl-sys/0.9.36). Probably not the best option but it compiles.

To build the tendermint-rpc crate with TLS support (one of the ibc-rs dependencies), you need to ensure you have the OpenSSL development library installed for your platform. See https://docs.rs/openssl/0.10.33/openssl/index.html#automatic

So, I'm using the hermer binary from master but I have problems running the same script as before. It is now complaining about missing subcommands. For example:

My bad, we just merged a PR which removes the need to specify peers for the light client, so we can't test whether the fix works for you via the (now removed) light add command. You can therefore remove the whole [peers] section from your configuration file.
The next best way to test if things now work correctly would be to create a on-chain client and perform a client update (which will trigger light client verification), by following the instructions at https://hermes.informal.systems/tx_client.html.

So, I'm using the hermer binary from master but I have problems running the same script as before. It is now complaining about missing subcommands. For example:

My bad, we just merged a PR which removes the need to specify peers for the light client, so we can't test whether the fix works for you via the (now removed) light add command. You can therefore remove the whole [peers] section from your configuration file as well as the invocation of the light rm and light add commands in your script. You may have to manually update your configuration file as some required options have been added in the meantime. You can take a look at the example config to see which options must now be specified.
The new ones are: websocket_addr, rpc_timeout (optional), fee_denom and fee_amount.
The next best way to test if things now work correctly would be to create a on-chain client and perform a client update (which will trigger light client verification), by following the instructions at https://hermes.informal.systems/tx_client.html.

Hi @romac! I tried updating the scripts (https://github.com/heliaxdev/ibc-setup) but the link you posted above is a 404 (probably you updated the docs). I followed the docs at https://hermes.informal.systems/tutorials/local-chains/raw/index.html.
Do you mind checking especially the config and scripts in the ibc folder? I will try to run it, but it takes a lot of time to start  gaiad on cosmoshub-4 network. Thank you!

Update. Tried running it again and now it complains as soon as I launch hermes tx raw create-client $IBC0 $IBC1 to create the first client. The error is the following:
Error: tx error: error raised while creating client: failed while querying src chain (stargate) for latest height: Light client error for RPC address http://localhost:26657/: node at http://localhost:26657/ running chain stargate not caught up.

I think i just need to wait for the node to get in sync (?)

yes, it looks like that. Has the sync finished? What version of hermes are you running?

No, it still catching up. Do you have any idea how much time/space this process should take?

What is the output of http://localhost:26657/status?

Here it is:
{
  "jsonrpc": "2.0",
  "id": -1,
  "result": {
    "node_info": {
      "protocol_version": {
        "p2p": "8",
        "block": "11",
        "app": "0"
      },
      "id": "729d39e3146fe9871b33c2d88eb0030c38995805",
      "listen_addr": "tcp://<IP_ADDRESS>:26656",
      "network": "cosmoshub-4",
      "version": "v0.34.9",
      "channels": "40202122233038606100",
      "moniker": "heliax-1",
      "other": {
        "tx_index": "on",
        "rpc_address": "tcp://<IP_ADDRESS>:26657"
      }
    },
    "sync_info": {
      "latest_block_hash": "F00C8384734FE5FE70A33581C9CCF1770E087DAE8197DEC1DB2D08AF40E826CD",
      "latest_app_hash": "20F4CAB46E5A81D03D2D39EB3073AD8A834BA7B0CBA02288E085D872BD3ADD21",
      "latest_block_height": "5978609",
      "latest_block_time": "2021-04-24T14:10:05.321924709Z",
      "earliest_block_hash": "1455A0C15AC49BB506992EC85A3CD4D32367E53A087689815E01A524231C3ADF",
      "earliest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
      "earliest_block_height": "5200791",
      "earliest_block_time": "2019-12-11T16:11:34Z",
      "catching_up": true
    },
    "validator_info": {
      "address": "49587EBF98D03A58115682BEA6B0D8CB585EA4F7",
      "pub_key": {
        "type": "tendermint/PubKeyEd25519",
        "value": "qwmnJLq4afdHSSkAM24hmuQ0j+HjiQJEiXQ8lF81Uys="
      },
      "voting_power": "0"
    }
  }
}

Hi @Fraccaman,
I have a full node synced and it's taking 337GB as of now (height 6037600) this is with pruning = nothing.
Concerning custom pruning if you do gaiad start help it gives you some pruning options, you can set in start command or in the config.
  --pruning string                                  Pruning strategy (default|nothing|everything|custom) (default "default")
      --pruning-interval uint                           Height interval at which pruned heights are removed from disk (ignored if pruning is not 'custom')
      --pruning-keep-every uint                         Offset heights to keep on disk after 'keep-every' (ignored if pruning is not 'custom')
      --pruning-keep-recent uint                        Number of recent heights to keep on disk (ignored if pruning is not 'custom')

Yes, it is still catching up

at 8-10 blocks/ sec sync speed this will take another ~20 hrs probably.

if you're running this node on AWS, one thing I noticed when syncing mine was that instance type and size and volume speed makes a big difference.

Yes, im running on a EC2 t3.xlarge machine (which may not be the best instance). I'll try with a non-burstable machine next time.
@andynog Do you know if IBC works also with a pruned node?
@ancazamfir With this machine I'm doing 2/3 blocks/ sec. Should be ready by tomorrow.

Hi @Fraccaman, could you figure out the keys and account issues?

Sorry, I have been a little busy, ill try next week!

Hi @Fraccaman, any updates on this? We believe this might not be an issue anymore since several changes have been implemented on the relayer since then. We might close this issue for now if we don't hear back in the next few days, but feel free to open it again if the problem persists.

@andynog sorry for the delay, some things have changed and I had to resync the chain which is taking a lot (1week+). Im almost finished synching, maybe a couple of days, and ill be back with some updates.

Okay made some progress. I have been able to download a snapshot from https://cosmos.quicksync.io/ which speeds up things a lot. So, as I have both node up and running, addresscosmos1x60z62swcm4j5ct4l5xpmcln3fdkvp8kylqv07 has some ATOM, and I'm now trying to create a channel between them.

First thing I do is building the relayer and importing the keys. This is doing fine, here is the output:

Building the Rust relayer...
Importing keys...
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s
     Running `target/debug/hermes -c /home/ec2-user/.hermes/config.toml keys add stargate -f /home/ec2-user/node-stargate/key_seed.json`
Success: Added key 'node_key' (cosmos1x60z62swcm4j5ct4l5xpmcln3fdkvp8kylqv07) on chain stargate
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s
     Running `target/debug/hermes -c /home/ec2-user/.hermes/config.toml keys add heliax -f /home/ec2-user/node-heliax/key_seed.json`
Success: Added key 'node_key' (cosmos1uvp3k66wl246jzcgl7etg80ly94mvtq84gr98x) on chain heliax
Done!

Second step, I try to create the clients. This is failing with this output:

Error: tx error: error raised while creating client: failed while building client state from src chain (stargate) with error: GRPC error: status: Unimplemented, message: "unknown service cosmos.staking.v1beta1.Query", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc"} }
Error: tx error: error raised while creating client: failed while building client state from src chain (heliax) with error: GRPC error: status: Unimplemented, message: "unknown service cosmos.staking.v1beta1.Query", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc"} }
Error: tx error: error raised while creating client: failed while building client state from src chain (heliax) with error: GRPC error: status: Unimplemented, message: "unknown service cosmos.staking.v1beta1.Query", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc"} }
Error: Query of client '07-tendermint-0' on chain 'heliax' failed with error: Query error occurred (failed to query for client state): error converting message type into domain type: the client state was not found
Error: config error: missing chain for id (irishub-1) in configuration file

Hermes version:
[ec2-user@ip-172-31-19-38 ibc-setup]$ $BINARY version
hermes 0.4.0

Gaiad version:
[ec2-user@ip-172-31-19-38 ibc-setup]$ gaiad version
v4.2.1

Okay, I had some bugs in the hermes config. Ill keep you posted.

More updates. I have been able to create a client between the 2 chains 🎉🎉🎉
Here the output:
[ec2-user@ip-172-31-19-38 ibc-setup]$ $BINARY query client state $IBC1 07-tendermint-252
Success: ClientState {
    chain_id: ChainId {
        id: "h3liax",
        version: 0,
    },
    trust_level: TrustThresholdFraction {
        numerator: 1,
        denominator: 3,
    },
    trusting_period: 1209600s,
    unbonding_period: 1814400s,
    max_clock_drift: 5s,
    frozen_height: Height {
        revision: 0,
        height: 0,
    },
    latest_height: Height {
        revision: 0,
        height: 3437,
    },
    upgrade_path: [
        "upgrade",
        "upgradedIBCState",
    ],
    allow_update: AllowUpdate {
        after_expiry: false,
        after_misbehaviour: false,
    },
}
[ec2-user@ip-172-31-19-38 ibc-setup]$ $BINARY query client state $IBC0 07-tendermint-2
Success: ClientState {
    chain_id: ChainId {
        id: "cosmoshub-4",
        version: 4,
    },
    trust_level: TrustThresholdFraction {
        numerator: 1,
        denominator: 3,
    },
    trusting_period: 1209600s,
    unbonding_period: 1814400s,
    max_clock_drift: 5s,
    frozen_height: Height {
        revision: 0,
        height: 0,
    },
    latest_height: Height {
        revision: 4,
        height: 6614024,
    },
    upgrade_path: [
        "upgrade",
        "upgradedIBCState",
    ],
    allow_update: AllowUpdate {
        after_expiry: false,
        after_misbehaviour: false,
    },
}

Following the tutorial, I'm trying to create a connection and this one is failing.
The first command (conn-init) works:
$BINARY tx raw conn-init $IBC0 $IBC1 07-tendermint-2 07-tendermint-252
Success: OpenInitConnection(
    OpenInit(
        Attributes {
            height: Height {
                revision: 0,
                height: 4474,
            },
            connection_id: Some(
                ConnectionId(
                    "connection-0",
                ),
            ),
            client_id: ClientId(
                "07-tendermint-2",
            ),
            counterparty_connection_id: None,
            counterparty_client_id: ClientId(
                "07-tendermint-252",
            ),
        },
    ),
)

Second command (conn-try) should be working:
$BINARY tx raw conn-try $IBC1 $IBC0 07-tendermint-252 07-tendermint-2 -s connection-0
Error: tx error: failed during a transaction submission step to chain id cosmoshub-4 with underlying error: RPC error to endpoint http://localhost:26657/: RPC error to endpoint http://localhost:26657/: Internal error: timed out waiting for tx to be included in a block (code: -32603)

I think it ran successfully, but I need to increase the rpc timeout.
Third command (conn-ack) fails:
$BINARY tx raw conn-ack $IBC0 $IBC1 07-tendermint-2 07-tendermint-252 -d connection-0 -s connection-1
Error: tx error: failed with underlying cause: tx response error: deliver_tx reports error: log=Log("failed to execute message; message index: 1: connection handshake open ack failed: failed connection state verification for client (07-tendermint-2): chained membership proof failed to verify membership of value: 0A1130372D74656E6465726D696E742D32353212230A0131120D4F524445525F4F524445524544120F4F524445525F554E4F524445524544180222260A0F30372D74656E6465726D696E742D32120C636F6E6E656374696F6E2D301A050A03696263 in subroot C42B7ED48FB47D14FC71C73C510D1687C981E1827F52DDCDC80FED215C6674BA at index 0. Please ensure the path and value are both correct.: invalid proof")

Do you have any suggestions?

I made a little progress but I'm still stuck at the same "step". I avoided the timeout error by setting in gaia timeout_broadcast_tx_commit to 300s. The "new" error (for the same command) is:
Error: tx error: failed with underlying cause: tx response error: deliver_tx reports error: log=Log("failed to execute message; message index: 1: connection handshake open try failed: failed connection state verification for client (07-tendermint-260): chained membership proof failed to verify membership of value: 0A0F30372D74656E6465726D696E742D3012230A0131120D4F524445525F4F524445524544120F4F524445525F554E4F5244455245441801221A0A1130372D74656E6465726D696E742D3236301A050A03696263 in subroot 3A9C01E534577A1D3BD6AD66742C7A1CFE16610347EB7F677FD636EFD9D0C50F at index 0. Please ensure the path and value are both correct.: invalid proof")

You can see the transactions here.

@andynog @ancazamfir any suggestion?

Hi @Fraccaman,
@ancazamfir and others in the team are looking at this. However, would you be interested in jumping on a call with one of us for quicker troubleshooting? You can reach me for instance and would be glad to fix it together.
In the meantime, some suggestions:

can you ensure you're using the latest version of Hermes (currently v0.5.0)?
the transactions on mintscan show slightly different details, e.g., this one using client id 07-tendermint-260, not 07-tendermint-252 like detailed in your comment above.

Hi @adizere,
yes, sounds good! We can catch up on slack :)

I'm using hermes v0.4.0
Yes, its because I tried several times after between the two comments

Some pointers after @romac and I debugged together with @Fraccaman

Hermes is failing with error TxNoConfirmation but the actual problem is twofold:

the simulated transaction fails, yet Hermes is not printing anything, and instead is just using the max gas; this is probably not ideal
we should handle the tx_simulate error case, since the transaction might be malformed, see here
It's not clear why we're seeing the "chained membership proof failed to verify membership" error, since both chains are plain gaia binaries, so Hermes should be able to interoperate and correctly relay proofs; the problem may be more serious.

to reproduce the error, we'll try to reuse the scripts from here

hello friends, maybe someone knows what this problem is and how to deal with it.
Reason: Hermes health check failed while verifying the application compatibility for chain osmosis-1:http://localhost:9120/; caused by: SDK module at version '0.46.0' does not meet compatibility requirements >=0.41, <0.46

Hey,
That warning should be harmless. Make sure you're using the latest Hermes version
https://github.com/informalsystems/ibc-rs/releases/tag/v1.0.0
The warning appears because we didn't update the compatibility check yet (SDK releases went through several back-and-forth and we waited to stabilize).
If you notice problems relaying on Osmosis-1, please let us know, we'd be glad to help!

Hello, I have a problem, I need to install a relayer and join an existing cosmos - osmosis channel, I made a configuration, checked it
hermes health-check
It struck me that everything is correct, then I executed the following commands in order to join the new channel.
hermes query channel end --chain osmosis-1 --port transfer --channel channel-0
hermes query channel end --chain cosmoshub-4 --port transfer --channel channel-141
Then I started I started the hermes servicer. After a while such errors
Sep 26 21:18:09 dedic-cyberG hermes[3669236]: 2022-09-26T19:18:09.358083Z  INFO ThreadId(01) spawned client worker: client::cosmoshub-4->osmosis-1:07-tendermint-1532
Sep 26 21:18:09 dedic-cyberG hermes[3669236]: 2022-09-26T19:18:09.426945Z  WARN ThreadId(91) refresh{client=07-tendermint-1532 src_chain=cosmoshub-4 dst_chain=osmosis-1}: task encountered ignorable error: failed while querying for client consensus state 07-tendermint-1532 on chain id osmosis-1 for height 4-8039226: error decoding protobuf: error converting message type into domain type: the client consensus state was not found
Sep 26 21:18:09 dedic-cyberG hermes[3669236]: 2022-09-26T19:18:09.688846Z  WARN ThreadId(79) refresh{client=07-tendermint-1431 src_chain=cosmoshub-4 dst_chain=osmosis-1}: task encountered ignorable error: failed while querying for client consensus state 07-tendermint-1431 on chain id osmosis-1 for height 4-7856203: error decoding protobuf: error converting message type into domain type: the client consensus state was not found
Sep 26 21:18:10 dedic-cyberG hermes[3669236]: 2022-09-26T19:18:10.592684Z  WARN ThreadId(91) refresh{client=07-tendermint-1532 src_chain=cosmoshub-4 dst_chain=osmosis-1}: task encountered ignorable error: failed while querying for client consensus state 07-tendermint-1532 on chain id osmosis-1 for height 4-8039226: error decoding protobuf: error converting message type into domain type: the client consensus state was not found
Sep 26 21:18:10 dedic-cyberG hermes[3669236]: 2022-09-26T19:18:10.816786Z  WARN ThreadId(79) refresh{client=07-tendermint-1431 src_chain=cosmoshub-4 dst_chain=osmosis-1}: task encountered ignorable error: failed while querying for client consensus state 07-tendermint-1431 on chain id osmosis-1 for height 4-7856203: error decoding protobuf: error converting message type into domain type: the client consensus state was not found
what could be the problem?

Can you please paste your config here so we can take a look?

Can you also check what the pruning parameters are set to in the Tendermint config? Pruning should be disabled for Hermes to successfully retrieve consensus states from the past.

[global]
log_level = 'info'
[mode]
[mode.clients]
enabled = true
refresh = true
misbehaviour = true
[mode.connections]
enabled = false
[mode.channels]
enabled = false
[mode.packets]
enabled = true
clear_interval = 100
clear_on_start = true
tx_confirmation = true
[rest]
enabled = true
host = '<IP_ADDRESS>'
port = 3000
[telemetry]
enabled = true
host = '<IP_ADDRESS>'
port = 3001
[[chains]]
id = 'osmosis-1'
rpc_addr = 'http://<IP_ADDRESS>:27667'
grpc_addr = 'http://<IP_ADDRESS>:9120/'
websocket_addr = 'ws://<IP_ADDRESS>/websocket'
rpc_timeout = '10s'
account_prefix = 'osmo'
key_name = 'osmosis'
store_prefix = 'ibc'
default_gas = 100000
max_gas = 400000
gas_price = { price = 0.001, denom = 'osmo' }
gas_multiplier = 1.1
max_msg_num = 30
max_tx_size = 2097152
clock_drift = '5s'
max_block_time = '30s'
trusting_period = '13days'
trust_threshold = { numerator = '1', denominator = '3' }
address_type = { derivation = 'cosmos' }
[[chains]]
id = 'cosmoshub-4'
rpc_addr = 'http://<IP_ADDRESS>:27657'
grpc_addr = 'http://<IP_ADDRESS>:9110'
websocket_addr = 'ws://<IP_ADDRESS>:27657/websocket'
rpc_timeout = '10s'
account_prefix = 'cosmos'
key_name = 'cosmos'
store_prefix = 'ibc'
default_gas = 100000
max_gas = 400000
gas_price = { price = 0.001, denom = 'atom' }
gas_multiplier = 1.1
max_msg_num = 30
max_tx_size = 107152
clock_drift = '5s'
max_block_time = '30s'
trusting_period = '14days'
trust_threshold = { numerator = '1', denominator = '3' }
address_type = { derivation = 'cosmos' }

root@dedic ~/.hermes # hermes version
hermes 1.0.0+ed4dd8c

I have such assignments in both nodes
default: only the last 100,000 states(approximately 1 week worth of state) are kept; pruning at 100 block intervals
nothing: all historic states will be saved, nothing will be deleted (i.e. archiving node)
everything: 10 latest states will be kept; pruning at 10 block intervals.
custom: allow pruning options to be manually specified through 'pruning-keep-recent', and 'pruning-interval'
pruning = "default"

What happens if you do?
$ hermes query client state --chain osmosis-1 --client 07-tendermint-1431

I don't know, but I want to understand how it works

it seems to me that this is information about the created client

I need to join the already created channel, if you tell me the sequence of actions, I will be very grateful to you
maybe i'm doing something wrong

I need to join the already created channel, if you tell me the sequence of actions, I will be very grateful to you
maybe i'm doing something wrong

Let's continue this discussion on Discord. I can be more responsive there.
Either join the  IBC Gang server here or DM me directly Adi Seredinschi (Informal)#9927.
My colleagues will also followup by providing a tutorial on how to join created channels.

Hi, there.
Can help me?
When I run the hermes create client on hermes for osmosis chain and my own chain(evmos forking), I get the error as follows.
"ERROR foreign client error: error raised while creating client for chain osmosis-1: failed when building client state: error in underlying transport when making gRPC call: transport error"
I want to fix it on hermes.
best regards


Remove outermost parenthesis in Javascript

Have you read the Contributing Guidelines on Pull Requests?
Yes
(Write your answer here.)
Description
This is code for removing the outermost parenthesis using Javascript.
(Write your answer here.)
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
Issue #955
(Write your answer here.)

@plazzy99 @atarax665 @siddharth25pandey @iamrajiv please review this PR.


create a Where's Waldo finder and generator?

This came to me talking about the neural net when explaining it to a friend, might be fun.

Fun, but very hard! I think the way to go on this is to split the big image into smaller chunks (say 100x100 each) and then run a convolutional net over each one of those chunks. Let it classify if waldo is present. A generator is a whole other story though...

Agreed!  Progress for the underlying library requirements are here: https://github.com/harthur-org/brain.js/issues/39

Hello @robertleeplummerjr were you able to achieve this?

The entire of brain.js v2, which we hope to have a release candidate out by the end of the month, will be the catalyst for this, and I have been working on it for essentially a couple years.  I wanted to not just do it, but make it so easy a child could do it.
I was told:

Fun, but very hard!

I want to tell my future self, @wagenaartje, and a future @samparsky: "ha, easy"
We will see, but I know the api, is working, and will give us the wings to achieve this.

I was wondering if the where's waldo generator was completed?

That would be very cool


issue uploading skill code to lambda

Anytime i hit the save button to send my code to lambda i'm receiving the below error. Any leads into what could be causing this? I've recreated my roles with admin access and update my credential file, no luck.
`/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/request.js:30
throw err;
^
Error: Missing credentials in config
at Request.callListeners (/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/sequential_executor.js:107:43)
at Request.emit (/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
at Request.emit (/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/request.js:596:14)
at Request.transition (/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/request.js:21:10)
at AcceptorStateMachine.runTo (/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/state_machine.js:14:12)
at /Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/state_machine.js:26:10
at Request. (/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/request.js:37:9)
at Request. (/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/request.js:598:12)
at Request.callListeners (/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
at Request.emit (/Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/node_modules/gulp-awslambda/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
npm ERR! Darwin 15.6.0
npm ERR! argv "/usr/local/Cellar/node/5.10.1/bin/node" "/usr/local/bin/npm" "start"
npm ERR! node v5.10.1
npm ERR! npm  v3.8.3
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: node node_modules/gulp/bin/gulp.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'node node_modules/gulp/bin/gulp.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the interactive-adventure-game-tool package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node node_modules/gulp/bin/gulp.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs interactive-adventure-game-tool
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls interactive-adventure-game-tool
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/MisterFili/Documents/InteractiveStory/interactive-adventure-game-tool/npm-debug.log`

The error clearly states "Error: Missing credentials in config" and needed to update my config file. it is a good idea to step away from work if you are tired or frustrated.

What exactly did you do? Got the same error but can't figure out how to fix it... keys in the credentials file in .aws should be alright so I'm pretty confused atm

I have a similar issue, mine says the User is not authorised to perform lambda:UpdateFunctionCode - I have checked the user and their permissions, and they should be able to access.
So off to check and review the code once again :)
I am running on Linux rather than a Mac - but the shell should be very similar.....
Mind you, I guess I have not too bad on AWS with just 4 hours use of AWS going through various tutorials.  I am using the deprecated package - so I am wondering if that could be one behind the reason if AWS have changed things in the console.

LOL - a typo!  The arn string had one digit that was wrong, a '4' instead of a '7' ..
Yes, cut&paste helps if you have access to the command, but as I am running Linux in a VM on Windows, and doing all the AWS stuff on my Windows web and running the code on the Linux VM then I guess typo's like this are inevitable ....
So it works, so far.... upload as works and the "save" has generated the files in the "model" directory on the Linux VM.
Really cool example 👍


change 'role' to 'k8s-role'

Coverage increased (+12.6%) to 61.056% when pulling 88c8a66689e72fc88a884962da32123b13c499b2 on yuye/k8s-config-id-change into 619e4045584784654061a7cc27db399c832dd03c on master.


Add support for history end_time param & make time parameter optional

As documented in the REST API HA docs, there's another parameter end_time which is not covered by the API.
Furthermore, the timestamp field was made optional as this is also supported according to the HA docs.
I'd appreciate any feedback and am looking forward to getting this into the next version of this npm module.
Thanks!

is this project dead?

Probably ¯_(ツ)_/¯

@sibbl that's a shame, it would be nice to be able to use NodeJS with HA

Please make sure the unit tests continue to pass and new test cases are provided around your new functionality.


[juniper_rocket] Expose GraphQLResponse fields

This PR exposes the fields of GraphQLResponse to make it easier to create custom responses.
Example
Here we're building a custom Rocket response so we can set some Access-Control-* headers:
fn execute_graphql_request<'a>(
    connection: DatabaseConnection,
    request: GraphQLRequest,
) -> Response<'a> {
    let context = Database::new(connection);
    let schema = Schema::new(Query, Mutation);
    // Prior to this change, this fails to compile with an error:
    // "constructor is not visible here due to private fields".
    let GraphQLResponse(status, json) = request.execute(&schema, &context);
    Response::build()
        .raw_header("Access-Control-Allow-Origin", "*")
        .raw_header("Access-Control-Allow-Methods", "OPTIONS, GET, POST")
        .raw_header("Access-Control-Allow-Headers", "Content-Type")
        .header(ContentType::new("application", "json"))
        .status(status)
        .sized_body(Cursor::new(json))
        .finalize()
}

@LegNeato Alright, I added an integration test. I based it off the existing tests for juniper_rocket, but it builds up a custom Rocket response.
I had to put the test in the tests directly so that it properly tests whether the fields of GraphQLResponse are visible.

@LegNeato No worries! I think "integration test" was a bit of a loaded term :sweat_smile:
But the test is much simpler now :+1:

Yeah, sorry, when you put a file in tests it is technically an integration test because it can only see pub stuff:
https://doc.rust-lang.org/book/second-edition/ch11-03-test-organization.html#integration-tests
Again, I should have been more explicit, thanks for the change and hanging in there!


part 3: Interpret models' predictions

Hi, thank you for your wonderful work. I'm trying the third part: Interpret Models' Predictions. I find I can't visualize some of the predictions. As follows:
IndexError                                Traceback (most recent call last)
 in
1 import shutil
----> 2 create_patiens_cam(acl[0],plane)
 in create_patiens_cam(case, plane)
19     logit = mrnet(mri)
20     size_upsample = (256, 256)
---> 21     feature_conv = feature_blobs[0]
22 #     print(features_blobs[0])
23
IndexError: list index out of range
and then I did this:
mrnet = torch.load(f'../models/{model_name}')
mrnet = mrnet.to(device)
mrnet.eval()
hook the feature extractor
features_blobs = []
def hook_feature(module, input, output):
features_blobs.append(output.data.cpu().numpy())
mrnet._modules.get('pooling_layer').register_forward_hook(hook_feature);
...
global features_blobs
mri = mri.to(device)
logit = mrnet(mri)
size_upsample = (256, 256)
feature_conv = features_blobs[0]
h_x = F.softmax(logit, dim=1).data.squeeze(0)
probs, idx = h_x.sort(0, True)
probs = probs.cpu().numpy()
idx = idx.cpu().numpy()
slice_cams = returnCAM(features_blobs[-1], weight_softmax, idx[:1])

...
import shutil
create_patiens_cam(acl[0],plane)
Could you tell me what went wrong? thank you

I think I solved the problem:
# hook the feature extractor
features_blobs = []

def hook_feature(module, input, output):
    features_blobs.append(output.data.cpu().numpy())

mrnet.pretrained_model._modules.get('features').register_forward_hook(hook_feature)


Allow environment variables for sqlalchemy uri

Is your feature request related to a problem? Please describe.
When deploying to multiple environments we'll like to be able to switch database connection.
Currently we have one script fixing database sqlalchemy uri
Describe the solution you'd like
Allow the use of environment variables as the value of sqlalchemy_uri property of Database
Describe alternatives you've considered
None yet
Additional context
We deploy using docker
Proposal
class Database(Model, AuditMixinNullable, ImportMixin):
....
allow_env_for_uri = Column(Boolean, default=False)
....
@property
def expanded_sqlalchemy_uri(self):
    if self.allow_env_for_uri:
        return os.path.expandvars(self.sqlalchemy_uri)
    return self.sqlalchemy_uri

@property
def sqlalchemy_uri_decrypted(self):
    conn = sqla.engine.url.make_url(self.expanded_sqlalchemy_uri)
    if custom_password_store:
        conn.password = custom_password_store(conn)
    else:
        conn.password = self.password
    return str(conn)

@gbrian you are free to extend the Python configuration as described in [the documentation] https://superset.apache.org/installation.html#configuration - as the configuration is a Python file, it is possible to tell Superset to look for environment variables for any configuration option. I hope this approach will work for you!

@willbarrett,  @gbrian is not referring to SQLALCHEMY_DATABASE_URI, but to the ones ones that we encrypt and store in the database.
I'm not sure how well that is documented, but with DB_CONNECTION_MUTATOR (a configuration hook) you can intercept the Database at runtime and do whatever, meaning you can put in bogus username/password in the database, and your DB_CONNECTION_MUTATOR function can read an env var and replace the proper value.
def DB_CONNECTION_MUTATOR(sqlalchemy_url, params, effective_username, security_manager, source):
    # Assuming that by convention your `sqlalchemy_url` references the env var you want to use
    sqlalchemy_url = os.environ.get(sqlalchemy_url)
    return sqlalchemy_url, params

Thanks @willbarrett , @mistercrunch.
I implemented differently as wanted to have a flag on database connection to set if ENV replacement should apply but reconsidering in favor of:  DB_CONNECTION_MUTATOR and SQL_QUERY_MUTATOR


Add capability to create issues directly from report

We need to decide which issue creation support could provide our report. This could be either test case summary to copy and paste to issue or full stack issue tracker API support.

we should implement such ability as custom report plugin


feat(storage): basic compactor scheduler policy

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
This section will be used as the commit message. Please do not leave this empty!
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)
How does this PR work? Need a brief introduction for the changed logic (optional)
Describe clearly one logical change and avoid lazy messages (optional)
Describe any limitations of the current code (optional)

Checklist

[x] I have written necessary rustdoc comments
~- [ ] I have added necessary unit tests and integration tests~
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note
Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.
Refer to a related PR or issue link (optional)

https://github.com/risingwavelabs/risingwave/issues/6730

Also, since we have 2 new metrics, can we run a test to do compaction for a period of time to verify the fundamental correctness of this framework?

Seems like a task distribution problem with the scaling scenario. Here are some evidences:
One of the compactor takes all 2,000 L3 SSTs and do the compaction by itself. After that, it keep compacting the tasks related to L0. All the other seven new compactors are idle with CPU usage around 0%. The following graph shows the CPU usage in percentage of each compactor node.

Somehow all compactors work together to compact L6. And after L6 tasks are done, all the other seven compactors are back to idle status (no task allocation) leaving only one compactor to do the compaction tasks related to L0.

With autoscaling, the compactor group now can handle a burst workload. When the number of pending bytes remains small for a specific period, the number of compactors will also decrease:


TryGetJointPose only works on Handedness.Right/Handedness.Left but not Any

Describe the bug
TryGetJointPose only gives a result on Handedness.Right/Handedness.Left but not Handedness.Any.
A clear and concise description of what the bug is.
Using Handedness.Any as parameter will always return false. In the documentation it is pointed out that it should be placed in an if statement implying that true means the joint pose has been acquired and false otherwise.
To reproduce
``
// is always false
if (HandJointUtils.TryGetJointPose(TrackedHandJoint.IndexTip, Handedness.Any, out pose))
{
//..
        }

       // will always go here
        else
        {
           // ..

        }

// trying again with right and left will never return false when hand is visible
if ( HandJointUtils.TryGetJointPose(TrackedHandJoint.IndexTip, Handedness.Right, out pose))
{
//..
}
        else if (HandJointUtils.TryGetJointPose(TrackedHandJoint.IndexTip, Handedness.Left, out pose))
        {
          //..

        }

``
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
Handedness.Any should find the first hand available (or all?), return true if anything is found, and populate out variable, same as Handedness.Left/Right do
Screenshots
If applicable, add screenshots to help explain your problem.
Your Setup (please complete the following information)

Unity Version [e.g. 2018.3.11f1]
MRTK Version [e.g. v2.0]

Target Platform (please complete the following information)

HoloLens
HoloLens 2
WMR immersive
OpenVR

Additional context
Add any other context about the problem here.

@wiwei is going to update the documentation for this behavior. It's unlikely that there will be a change in this behavior.

The intent of this function as I understand it was to provide the joint information for a specific hand (i.e. user wants the right hand, user wants the left hand).
Handling "Any" or "Both" puts it in this weird case where it's non-deterministic which hand gets returned (I guess we could always default to a specific one, but without a good understanding of the use cases it's tough to say whether or not that would actually make sense).
In order to address this, we'll update the docs to describe what they actually take so there's no future confusion about the set of supported values.
If there's a specific behavior you're looking for (i.e. I want this API to support Any/Both, and default to left or right hand, or the last one that sent input, or the 'primary' one), it would be good to open a new issue describing what that request is and what it would enable.

Alrighty, it looks like we updated this to work with Any as well, so this should be good.


People4Hops factor table does not guarantee paths between two persons

For SNB Interactive, for parameter selection the People4Hops factor table is used to get two persons with a path that is 4 hops long.
However, not all person pairs in the people4Hops have a path.
To reproduce:

Using the generate-all.sh script from ldbc_snb_interactive_impls, generate SF1.
Load SF1 into Neo4j using the implementation from the implementations repository
Using Q13 with the following input: Person1Id=24189255812497, Person2Id=4398046513909 (this is from the people4Hops factor table), no path is found. The creation date/deletion date of both persons are outside the simulated time window (28-11-2012 ~31-12-2012)

Thanks for reporting this! This is a pretty nasty bug but I have a workaround in mind.
This problem occurs because the factor generation step in the data generator is unaware of the benchmark's time window. So it has two choices:

Only return person pairs between whom there is always a 4-hop path. The are two approaches for this:
a. Only use persons and knows edges which always exist in the network. Doing this is simple but it has problems:

it will never return endpoints who have been freshly inserted to the network during the benchmark
there are likely going to be <4-hop paths between these people at some point during the network due to the addition of new persons/knows edges

b. Take the temporal attributes into account: when calculating 2-hop paths by joining two knows edges k1 and k2, calculate the intersection of their interval, i.e. [max(k1.creationDate, k2.creationDate), min(k1.deletionDate, k2.deletionDate)]. This interval may very well be empty, in which case this is not an actual 2-hop path in the graph and should be discarded. (4-hop paths can then be found by taking two 2-hop paths and intersecting them in the middle.)
This approach (1b) could work in theory but requires some work in the factorgen.

Return pairs of persons between whom there is potentially no path in the given time interval (I call this "overapproximation", returning a set of pairs some of whom will not work for our parameters) and later filter on them.
This approach has the advantages that: (1) we can do it in the paramgen, which is easier to develop & cheaper to iterate on than the factorgen; (2) we can be more granular for SNB Interactive: we can ensure that the two persons have an exactly 4-hop shortest path between them on a given day.
Its disadvantage is that our "factors" now include the person_knows_person with attributes (person1id, person2id, day of creationDate, day of deletionDate), so it's hardly a "factor table" anymore. For SF10,000, the factors are 20GB in total and the personKnowsPersonDays table uses 15GB.

I actually implemented approach 2. for BI Q15b but didn't do so for BI Q15a. It's not trivial because doing 4 joins would definitely run out of memory on large SFs. I'll take a look and report back tomorrow.

So the solution for BI is relatively simple to implement: https://github.com/ldbc/ldbc_snb_bi/pull/104/files
The extra distinct is there as a naive implementation of factorization to limit the memory use of the long acyclic path.
Some benchmark results (for the full BI paramgen run): https://github.com/ldbc/ldbc_snb_bi/pull/104#issue-1385136217