Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look-up functions for ReadOnlyNetworkGraph #1543

Merged
merged 1 commit into from Jul 14, 2022

Conversation

jkczyz
Copy link
Contributor

@jkczyz jkczyz commented Jun 14, 2022

ReadOnlyNetworkGraph uses BTreeMap to store its nodes and channels, but these data structures are not supported by C bindings. Expose look-up functions on these maps in lieu of such support.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmm, yuckkkk. That's a ton of copying, so much so I'd bet we'll see some nontrivial issues with anyone trying to use this on mobile. I'd much rather expose some method to query for individual entries rather than expose the full set.

@jkczyz
Copy link
Contributor Author

jkczyz commented Jun 15, 2022

Hmmmm, yuckkkk. That's a ton of copying, so much so I'd bet we'll see some nontrivial issues with anyone trying to use this on mobile. I'd much rather expose some method to query for individual entries rather than expose the full set.

Yeah, wasn't really happy about the cloning. But to confirm my understanding of bindings, (1) could we use references instead and (2) is HashMap unsupported?

@TheBlueMatt
Copy link
Collaborator

(1) could we use references instead

References to what? In theory references are supported, we could implement a getter that returns a reference, but most of the language bindings would just clone on the return, which is fine if we're just returning info for one channel.

(2) is HashMap unsupported?

In general none of the std things are supported, we don't have a manual mapping for maps (unlike vecs).

@jkczyz
Copy link
Contributor Author

jkczyz commented Jun 15, 2022

(1) could we use references instead

References to what? In theory references are supported, we could implement a getter that returns a reference, but most of the language bindings would just clone on the return, which is fine if we're just returning info for one channel.

Was thinking either Vec<&(NodeId, NodeInfo)> or Vec<(NodeId, &NodeInfo)>. But a look-up function may be preferable, as you noted.

@codecov-commenter
Copy link

Codecov Report

Merging #1543 (2d50c17) into main (22dc964) will increase coverage by 0.65%.
The diff coverage is n/a.

❗ Current head 2d50c17 differs from pull request most recent head 3024b07. Consider uploading reports for the commit 3024b07 to get more accurate results

@@            Coverage Diff             @@
##             main    #1543      +/-   ##
==========================================
+ Coverage   90.94%   91.60%   +0.65%     
==========================================
  Files          80       80              
  Lines       43469    47658    +4189     
  Branches    43469    47658    +4189     
==========================================
+ Hits        39533    43657    +4124     
- Misses       3936     4001      +65     
Impacted Files Coverage Δ
lightning/src/routing/gossip.rs 91.69% <ø> (ø)
lightning/src/ln/features.rs 99.28% <0.00%> (-0.19%) ⬇️
lightning/src/ln/functional_tests.rs 97.06% <0.00%> (-0.11%) ⬇️
lightning/src/ln/payment_tests.rs 99.31% <0.00%> (+0.07%) ⬆️
lightning/src/routing/router.rs 93.27% <0.00%> (+0.80%) ⬆️
lightning/src/ln/functional_test_utils.rs 96.71% <0.00%> (+1.48%) ⬆️
lightning/src/ln/channelmanager.rs 87.79% <0.00%> (+3.46%) ⬆️
lightning/src/ln/channel.rs 92.06% <0.00%> (+3.48%) ⬆️
lightning/src/util/config.rs 57.50% <0.00%> (+14.36%) ⬆️

Continue to review full report at Codecov.

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

@jkczyz jkczyz changed the title Expose NetworkGraph nodes and channels in C bindings Look-up functions for ReadOnlyNetworkGraph Jul 14, 2022
@jkczyz jkczyz marked this pull request as ready for review July 14, 2022 01:17
@TheBlueMatt TheBlueMatt added this to the 0.0.110 milestone Jul 14, 2022
@TheBlueMatt
Copy link
Collaborator

Tagging 110 due to user request, plus its trivial

TheBlueMatt
TheBlueMatt previously approved these changes Jul 14, 2022
@tnull tnull self-requested a review July 14, 2022 09:28
tnull
tnull previously approved these changes Jul 14, 2022
Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, mod two style nits.

lightning/src/routing/gossip.rs Outdated Show resolved Hide resolved
lightning/src/routing/gossip.rs Outdated Show resolved Hide resolved
ReadOnlyNetworkGraph uses BTreeMap to store its nodes and channels, but
these data structures are not supported by C bindings. Expose look-up
functions on these maps in lieu of such support.
@jkczyz jkczyz dismissed stale reviews from tnull and TheBlueMatt via 2da4953 July 14, 2022 15:27
@jkczyz jkczyz force-pushed the 2022-06-network-graph-bindings branch from 3024b07 to 2da4953 Compare July 14, 2022 15:27
@jkczyz jkczyz merged commit b760407 into lightningdevkit:main Jul 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants