Trivial Bindings Updates by TheBlueMatt · Pull Request #1934 · lightningdevkit/rust-lightning

TheBlueMatt · 2022-12-24T17:35:05Z

A few trivial things for bindings, but which make sense upstream.

codecov-commenter · 2022-12-24T17:55:30Z

Codecov Report

Base: 90.78% // Head: 90.76% // Decreases project coverage by -0.02%⚠️

Coverage data is based on head (f00bc4d) compared to base (f0c181e).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files

@@ Coverage Diff @@## main #1934 +/- ##
==========================================
- Coverage 90.78% 90.76% -0.03% 
==========================================
Files 96 96 Lines 50080 50080 Branches 50080 50080 ==========================================
- Hits 45464 45453 -11 - Misses 4616 4627 +11

Impacted Files	Coverage Δ
lightning/src/onion_message/packet.rs	`76.03% <ø> (ø)`
lightning/src/routing/router.rs	`90.90% <50.00%> (ø)`
lightning-invoice/src/payment.rs	`89.48% <100.00%> (ø)`
lightning/src/chain/onchaintx.rs	`94.54% <0.00%> (-0.84%)`	⬇️
lightning/src/chain/channelmonitor.rs	`90.98% <0.00%> (-0.10%)`	⬇️
lightning/src/ln/functional_tests.rs	`96.95% <0.00%> (-0.09%)`	⬇️
lightning/src/ln/channelmanager.rs	`86.65% <0.00%> (-0.03%)`	⬇️
lightning/src/util/events.rs	`29.58% <0.00%> (+0.22%)`	⬆️

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

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

`ScorerAccountingForInFlightHtlcs` generally stores a `Score` reference generated by calling `LockableScore::lock`, which actually returns an arbitrary `Score`. Given `Score` is implemented directly on lock types, it makes sense to simply hold a fully owned `Score` in `ScorerAccountingForInFlightHtlcs` rather than a mutable reference to one.

Specifically, `OnionMessageContents` is a non-cloneable enum, which isn't stored opaque so we cannot call `&self` methods on it. Because its methods aren't critical to the API for now, we simply no-export them rather than trying to work out an alternative approach.

valentinewallace · 2023-01-03T16:57:30Z

 impl<T: CustomOnionMessageContents> OnionMessageContents<T> {
 	/// Returns the type that was used to decode the message payload.
+	///
+	/// (C-not exported) as methods on non-cloneable enums are not currently exportable


Does this need a release note somewhere?

We generally haven't release-noted this kinda thing. The nice thing about the comments is they appear in the documentation, but sadly when we do the bindings update after the release they won't show up until the next release :(. Once we get to 0.1 I want to redo our release process to do a rcX release, then update the bindings, then once that's done do the actual release.

TheBlueMatt · 2022-12-24T17:35:05Z

A few trivial things for bindings, but which make sense upstream.

codecov-commenter · 2022-12-24T17:55:30Z

Codecov Report

Base: 90.78% // Head: 90.76% // Decreases project coverage by -0.02%⚠️

Coverage data is based on head (f00bc4d) compared to base (f0c181e).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files

@@ Coverage Diff @@## main #1934 +/- ##
==========================================
- Coverage 90.78% 90.76% -0.03% 
==========================================
Files 96 96 Lines 50080 50080 Branches 50080 50080 ==========================================
- Hits 45464 45453 -11 - Misses 4616 4627 +11

Impacted Files	Coverage Δ
lightning/src/onion_message/packet.rs	`76.03% <ø> (ø)`
lightning/src/routing/router.rs	`90.90% <50.00%> (ø)`
lightning-invoice/src/payment.rs	`89.48% <100.00%> (ø)`
lightning/src/chain/onchaintx.rs	`94.54% <0.00%> (-0.84%)`	⬇️
lightning/src/chain/channelmonitor.rs	`90.98% <0.00%> (-0.10%)`	⬇️
lightning/src/ln/functional_tests.rs	`96.95% <0.00%> (-0.09%)`	⬇️
lightning/src/ln/channelmanager.rs	`86.65% <0.00%> (-0.03%)`	⬇️
lightning/src/util/events.rs	`29.58% <0.00%> (+0.22%)`	⬆️

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

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

`ScorerAccountingForInFlightHtlcs` generally stores a `Score` reference generated by calling `LockableScore::lock`, which actually returns an arbitrary `Score`. Given `Score` is implemented directly on lock types, it makes sense to simply hold a fully owned `Score` in `ScorerAccountingForInFlightHtlcs` rather than a mutable reference to one.

Specifically, `OnionMessageContents` is a non-cloneable enum, which isn't stored opaque so we cannot call `&self` methods on it. Because its methods aren't critical to the API for now, we simply no-export them rather than trying to work out an alternative approach.

valentinewallace · 2023-01-03T16:57:30Z

 impl<T: CustomOnionMessageContents> OnionMessageContents<T> {
 	/// Returns the type that was used to decode the message payload.
+	///
+	/// (C-not exported) as methods on non-cloneable enums are not currently exportable


Does this need a release note somewhere?

We generally haven't release-noted this kinda thing. The nice thing about the comments is they appear in the documentation, but sadly when we do the bindings update after the release they won't show up until the next release :(. Once we get to 0.1 I want to redo our release process to do a rcX release, then update the bindings, then once that's done do the actual release.

TheBlueMatt · 2022-12-24T17:35:05Z

A few trivial things for bindings, but which make sense upstream.

codecov-commenter · 2022-12-24T17:55:30Z

Codecov Report

Base: 90.78% // Head: 90.76% // Decreases project coverage by -0.02%⚠️

Coverage data is based on head (f00bc4d) compared to base (f0c181e).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files

@@ Coverage Diff @@## main #1934 +/- ##
==========================================
- Coverage 90.78% 90.76% -0.03% 
==========================================
Files 96 96 Lines 50080 50080 Branches 50080 50080 ==========================================
- Hits 45464 45453 -11 - Misses 4616 4627 +11

Impacted Files	Coverage Δ
lightning/src/onion_message/packet.rs	`76.03% <ø> (ø)`
lightning/src/routing/router.rs	`90.90% <50.00%> (ø)`
lightning-invoice/src/payment.rs	`89.48% <100.00%> (ø)`
lightning/src/chain/onchaintx.rs	`94.54% <0.00%> (-0.84%)`	⬇️
lightning/src/chain/channelmonitor.rs	`90.98% <0.00%> (-0.10%)`	⬇️
lightning/src/ln/functional_tests.rs	`96.95% <0.00%> (-0.09%)`	⬇️
lightning/src/ln/channelmanager.rs	`86.65% <0.00%> (-0.03%)`	⬇️
lightning/src/util/events.rs	`29.58% <0.00%> (+0.22%)`	⬆️

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

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

`ScorerAccountingForInFlightHtlcs` generally stores a `Score` reference generated by calling `LockableScore::lock`, which actually returns an arbitrary `Score`. Given `Score` is implemented directly on lock types, it makes sense to simply hold a fully owned `Score` in `ScorerAccountingForInFlightHtlcs` rather than a mutable reference to one.

Specifically, `OnionMessageContents` is a non-cloneable enum, which isn't stored opaque so we cannot call `&self` methods on it. Because its methods aren't critical to the API for now, we simply no-export them rather than trying to work out an alternative approach.

valentinewallace · 2023-01-03T16:57:30Z

 impl<T: CustomOnionMessageContents> OnionMessageContents<T> {
 	/// Returns the type that was used to decode the message payload.
+	///
+	/// (C-not exported) as methods on non-cloneable enums are not currently exportable


Does this need a release note somewhere?

We generally haven't release-noted this kinda thing. The nice thing about the comments is they appear in the documentation, but sadly when we do the bindings update after the release they won't show up until the next release :(. Once we get to 0.1 I want to redo our release process to do a rcX release, then update the bindings, then once that's done do the actual release.

TheBlueMatt · 2022-12-24T17:35:05Z

A few trivial things for bindings, but which make sense upstream.

codecov-commenter · 2022-12-24T17:55:30Z

Codecov Report

Base: 90.78% // Head: 90.76% // Decreases project coverage by -0.02%⚠️

Coverage data is based on head (f00bc4d) compared to base (f0c181e).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files

@@ Coverage Diff @@## main #1934 +/- ##
==========================================
- Coverage 90.78% 90.76% -0.03% 
==========================================
Files 96 96 Lines 50080 50080 Branches 50080 50080 ==========================================
- Hits 45464 45453 -11 - Misses 4616 4627 +11

Impacted Files	Coverage Δ
lightning/src/onion_message/packet.rs	`76.03% <ø> (ø)`
lightning/src/routing/router.rs	`90.90% <50.00%> (ø)`
lightning-invoice/src/payment.rs	`89.48% <100.00%> (ø)`
lightning/src/chain/onchaintx.rs	`94.54% <0.00%> (-0.84%)`	⬇️
lightning/src/chain/channelmonitor.rs	`90.98% <0.00%> (-0.10%)`	⬇️
lightning/src/ln/functional_tests.rs	`96.95% <0.00%> (-0.09%)`	⬇️
lightning/src/ln/channelmanager.rs	`86.65% <0.00%> (-0.03%)`	⬇️
lightning/src/util/events.rs	`29.58% <0.00%> (+0.22%)`	⬆️

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

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

`ScorerAccountingForInFlightHtlcs` generally stores a `Score` reference generated by calling `LockableScore::lock`, which actually returns an arbitrary `Score`. Given `Score` is implemented directly on lock types, it makes sense to simply hold a fully owned `Score` in `ScorerAccountingForInFlightHtlcs` rather than a mutable reference to one.

Specifically, `OnionMessageContents` is a non-cloneable enum, which isn't stored opaque so we cannot call `&self` methods on it. Because its methods aren't critical to the API for now, we simply no-export them rather than trying to work out an alternative approach.

valentinewallace · 2023-01-03T16:57:30Z

 impl<T: CustomOnionMessageContents> OnionMessageContents<T> {
 	/// Returns the type that was used to decode the message payload.
+	///
+	/// (C-not exported) as methods on non-cloneable enums are not currently exportable


Does this need a release note somewhere?

We generally haven't release-noted this kinda thing. The nice thing about the comments is they appear in the documentation, but sadly when we do the bindings update after the release they won't show up until the next release :(. Once we get to 0.1 I want to redo our release process to do a rcX release, then update the bindings, then once that's done do the actual release.

TheBlueMatt · 2022-12-24T17:35:05Z

A few trivial things for bindings, but which make sense upstream.

codecov-commenter · 2022-12-24T17:55:30Z

Codecov Report

Base: 90.78% // Head: 90.76% // Decreases project coverage by -0.02%⚠️

Coverage data is based on head (f00bc4d) compared to base (f0c181e).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files

@@ Coverage Diff @@## main #1934 +/- ##
==========================================
- Coverage 90.78% 90.76% -0.03% 
==========================================
Files 96 96 Lines 50080 50080 Branches 50080 50080 ==========================================
- Hits 45464 45453 -11 - Misses 4616 4627 +11

Impacted Files	Coverage Δ
lightning/src/onion_message/packet.rs	`76.03% <ø> (ø)`
lightning/src/routing/router.rs	`90.90% <50.00%> (ø)`
lightning-invoice/src/payment.rs	`89.48% <100.00%> (ø)`
lightning/src/chain/onchaintx.rs	`94.54% <0.00%> (-0.84%)`	⬇️
lightning/src/chain/channelmonitor.rs	`90.98% <0.00%> (-0.10%)`	⬇️
lightning/src/ln/functional_tests.rs	`96.95% <0.00%> (-0.09%)`	⬇️
lightning/src/ln/channelmanager.rs	`86.65% <0.00%> (-0.03%)`	⬇️
lightning/src/util/events.rs	`29.58% <0.00%> (+0.22%)`	⬆️

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

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

`ScorerAccountingForInFlightHtlcs` generally stores a `Score` reference generated by calling `LockableScore::lock`, which actually returns an arbitrary `Score`. Given `Score` is implemented directly on lock types, it makes sense to simply hold a fully owned `Score` in `ScorerAccountingForInFlightHtlcs` rather than a mutable reference to one.

Specifically, `OnionMessageContents` is a non-cloneable enum, which isn't stored opaque so we cannot call `&self` methods on it. Because its methods aren't critical to the API for now, we simply no-export them rather than trying to work out an alternative approach.

valentinewallace · 2023-01-03T16:57:30Z

 impl<T: CustomOnionMessageContents> OnionMessageContents<T> {
 	/// Returns the type that was used to decode the message payload.
+	///
+	/// (C-not exported) as methods on non-cloneable enums are not currently exportable


Does this need a release note somewhere?

We generally haven't release-noted this kinda thing. The nice thing about the comments is they appear in the documentation, but sadly when we do the bindings update after the release they won't show up until the next release :(. Once we get to 0.1 I want to redo our release process to do a rcX release, then update the bindings, then once that's done do the actual release.

TheBlueMatt · 2022-12-24T17:35:05Z

A few trivial things for bindings, but which make sense upstream.

codecov-commenter · 2022-12-24T17:55:30Z

Codecov Report

Base: 90.78% // Head: 90.76% // Decreases project coverage by -0.02%⚠️

Coverage data is based on head (f00bc4d) compared to base (f0c181e).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files

@@ Coverage Diff @@## main #1934 +/- ##
==========================================
- Coverage 90.78% 90.76% -0.03% 
==========================================
Files 96 96 Lines 50080 50080 Branches 50080 50080 ==========================================
- Hits 45464 45453 -11 - Misses 4616 4627 +11

Impacted Files	Coverage Δ
lightning/src/onion_message/packet.rs	`76.03% <ø> (ø)`
lightning/src/routing/router.rs	`90.90% <50.00%> (ø)`
lightning-invoice/src/payment.rs	`89.48% <100.00%> (ø)`
lightning/src/chain/onchaintx.rs	`94.54% <0.00%> (-0.84%)`	⬇️
lightning/src/chain/channelmonitor.rs	`90.98% <0.00%> (-0.10%)`	⬇️
lightning/src/ln/functional_tests.rs	`96.95% <0.00%> (-0.09%)`	⬇️
lightning/src/ln/channelmanager.rs	`86.65% <0.00%> (-0.03%)`	⬇️
lightning/src/util/events.rs	`29.58% <0.00%> (+0.22%)`	⬆️

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

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

`ScorerAccountingForInFlightHtlcs` generally stores a `Score` reference generated by calling `LockableScore::lock`, which actually returns an arbitrary `Score`. Given `Score` is implemented directly on lock types, it makes sense to simply hold a fully owned `Score` in `ScorerAccountingForInFlightHtlcs` rather than a mutable reference to one.

Specifically, `OnionMessageContents` is a non-cloneable enum, which isn't stored opaque so we cannot call `&self` methods on it. Because its methods aren't critical to the API for now, we simply no-export them rather than trying to work out an alternative approach.

valentinewallace · 2023-01-03T16:57:30Z

 impl<T: CustomOnionMessageContents> OnionMessageContents<T> {
 	/// Returns the type that was used to decode the message payload.
+	///
+	/// (C-not exported) as methods on non-cloneable enums are not currently exportable


Does this need a release note somewhere?

We generally haven't release-noted this kinda thing. The nice thing about the comments is they appear in the documentation, but sadly when we do the bindings update after the release they won't show up until the next release :(. Once we get to 0.1 I want to redo our release process to do a rcX release, then update the bindings, then once that's done do the actual release.

TheBlueMatt · 2022-12-24T17:35:05Z

A few trivial things for bindings, but which make sense upstream.

codecov-commenter · 2022-12-24T17:55:30Z

Codecov Report

Base: 90.78% // Head: 90.76% // Decreases project coverage by -0.02%⚠️

Coverage data is based on head (f00bc4d) compared to base (f0c181e).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files

@@ Coverage Diff @@## main #1934 +/- ##
==========================================
- Coverage 90.78% 90.76% -0.03% 
==========================================
Files 96 96 Lines 50080 50080 Branches 50080 50080 ==========================================
- Hits 45464 45453 -11 - Misses 4616 4627 +11

Impacted Files	Coverage Δ
lightning/src/onion_message/packet.rs	`76.03% <ø> (ø)`
lightning/src/routing/router.rs	`90.90% <50.00%> (ø)`
lightning-invoice/src/payment.rs	`89.48% <100.00%> (ø)`
lightning/src/chain/onchaintx.rs	`94.54% <0.00%> (-0.84%)`	⬇️
lightning/src/chain/channelmonitor.rs	`90.98% <0.00%> (-0.10%)`	⬇️
lightning/src/ln/functional_tests.rs	`96.95% <0.00%> (-0.09%)`	⬇️
lightning/src/ln/channelmanager.rs	`86.65% <0.00%> (-0.03%)`	⬇️
lightning/src/util/events.rs	`29.58% <0.00%> (+0.22%)`	⬆️

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

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

`ScorerAccountingForInFlightHtlcs` generally stores a `Score` reference generated by calling `LockableScore::lock`, which actually returns an arbitrary `Score`. Given `Score` is implemented directly on lock types, it makes sense to simply hold a fully owned `Score` in `ScorerAccountingForInFlightHtlcs` rather than a mutable reference to one.

Specifically, `OnionMessageContents` is a non-cloneable enum, which isn't stored opaque so we cannot call `&self` methods on it. Because its methods aren't critical to the API for now, we simply no-export them rather than trying to work out an alternative approach.

valentinewallace · 2023-01-03T16:57:30Z

 impl<T: CustomOnionMessageContents> OnionMessageContents<T> {
 	/// Returns the type that was used to decode the message payload.
+	///
+	/// (C-not exported) as methods on non-cloneable enums are not currently exportable


Does this need a release note somewhere?

We generally haven't release-noted this kinda thing. The nice thing about the comments is they appear in the documentation, but sadly when we do the bindings update after the release they won't show up until the next release :(. Once we get to 0.1 I want to redo our release process to do a rcX release, then update the bindings, then once that's done do the actual release.

TheBlueMatt · 2022-12-24T17:35:05Z

A few trivial things for bindings, but which make sense upstream.

codecov-commenter · 2022-12-24T17:55:30Z

Codecov Report

Base: 90.78% // Head: 90.76% // Decreases project coverage by -0.02%⚠️

Coverage data is based on head (f00bc4d) compared to base (f0c181e).
Patch coverage: 75.00% of modified lines in pull request are covered.

Additional details and impacted files

@@ Coverage Diff @@## main #1934 +/- ##
==========================================
- Coverage 90.78% 90.76% -0.03% 
==========================================
Files 96 96 Lines 50080 50080 Branches 50080 50080 ==========================================
- Hits 45464 45453 -11 - Misses 4616 4627 +11

Impacted Files	Coverage Δ
lightning/src/onion_message/packet.rs	`76.03% <ø> (ø)`
lightning/src/routing/router.rs	`90.90% <50.00%> (ø)`
lightning-invoice/src/payment.rs	`89.48% <100.00%> (ø)`
lightning/src/chain/onchaintx.rs	`94.54% <0.00%> (-0.84%)`	⬇️
lightning/src/chain/channelmonitor.rs	`90.98% <0.00%> (-0.10%)`	⬇️
lightning/src/ln/functional_tests.rs	`96.95% <0.00%> (-0.09%)`	⬇️
lightning/src/ln/channelmanager.rs	`86.65% <0.00%> (-0.03%)`	⬇️
lightning/src/util/events.rs	`29.58% <0.00%> (+0.22%)`	⬆️

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

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

`ScorerAccountingForInFlightHtlcs` generally stores a `Score` reference generated by calling `LockableScore::lock`, which actually returns an arbitrary `Score`. Given `Score` is implemented directly on lock types, it makes sense to simply hold a fully owned `Score` in `ScorerAccountingForInFlightHtlcs` rather than a mutable reference to one.

Specifically, `OnionMessageContents` is a non-cloneable enum, which isn't stored opaque so we cannot call `&self` methods on it. Because its methods aren't critical to the API for now, we simply no-export them rather than trying to work out an alternative approach.

valentinewallace · 2023-01-03T16:57:30Z

 impl<T: CustomOnionMessageContents> OnionMessageContents<T> {
 	/// Returns the type that was used to decode the message payload.
+	///
+	/// (C-not exported) as methods on non-cloneable enums are not currently exportable


Does this need a release note somewhere?

We generally haven't release-noted this kinda thing. The nice thing about the comments is they appear in the documentation, but sadly when we do the bindings update after the release they won't show up until the next release :(. Once we get to 0.1 I want to redo our release process to do a rcX release, then update the bindings, then once that's done do the actual release.

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 9ca0fea to 3784b44Compare December 24, 2022 23:09

TheBlueMatt added 2 commits December 25, 2022 00:58

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 3784b44 to f00bc4dCompare December 25, 2022 00:58

tnull approved these changes Jan 3, 2023
View reviewed changes

valentinewallace approved these changes Jan 3, 2023
View reviewed changes

valentinewallace reviewed Jan 3, 2023
View reviewed changes

TheBlueMatt merged commit 7d84a45 into lightningdevkit:mainJan 3, 2023

TheBlueMatt mentioned this pull request Jan 3, 2023
Parameterize ChannelManager by a Router#1812
Merged

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 9ca0fea to 3784b44Compare December 24, 2022 23:09

TheBlueMatt added 2 commits December 25, 2022 00:58

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 3784b44 to f00bc4dCompare December 25, 2022 00:58

tnull approved these changes Jan 3, 2023
View reviewed changes

valentinewallace approved these changes Jan 3, 2023
View reviewed changes

valentinewallace reviewed Jan 3, 2023
View reviewed changes

TheBlueMatt merged commit 7d84a45 into lightningdevkit:mainJan 3, 2023

TheBlueMatt mentioned this pull request Jan 3, 2023
Parameterize ChannelManager by a Router#1812
Merged

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 9ca0fea to 3784b44Compare December 24, 2022 23:09

TheBlueMatt added 2 commits December 25, 2022 00:58

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 3784b44 to f00bc4dCompare December 25, 2022 00:58

tnull approved these changes Jan 3, 2023
View reviewed changes

valentinewallace approved these changes Jan 3, 2023
View reviewed changes

valentinewallace reviewed Jan 3, 2023
View reviewed changes

TheBlueMatt merged commit 7d84a45 into lightningdevkit:mainJan 3, 2023

TheBlueMatt mentioned this pull request Jan 3, 2023
Parameterize ChannelManager by a Router#1812
Merged

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 9ca0fea to 3784b44Compare December 24, 2022 23:09

TheBlueMatt added 2 commits December 25, 2022 00:58

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 3784b44 to f00bc4dCompare December 25, 2022 00:58

tnull approved these changes Jan 3, 2023
View reviewed changes

valentinewallace approved these changes Jan 3, 2023
View reviewed changes

valentinewallace reviewed Jan 3, 2023
View reviewed changes

TheBlueMatt merged commit 7d84a45 into lightningdevkit:mainJan 3, 2023

TheBlueMatt mentioned this pull request Jan 3, 2023
Parameterize ChannelManager by a Router#1812
Merged

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 9ca0fea to 3784b44Compare December 24, 2022 23:09

TheBlueMatt added 2 commits December 25, 2022 00:58

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 3784b44 to f00bc4dCompare December 25, 2022 00:58

tnull approved these changes Jan 3, 2023
View reviewed changes

valentinewallace approved these changes Jan 3, 2023
View reviewed changes

valentinewallace reviewed Jan 3, 2023
View reviewed changes

TheBlueMatt merged commit 7d84a45 into lightningdevkit:mainJan 3, 2023

TheBlueMatt mentioned this pull request Jan 3, 2023
Parameterize ChannelManager by a Router#1812
Merged

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 9ca0fea to 3784b44Compare December 24, 2022 23:09

TheBlueMatt added 2 commits December 25, 2022 00:58

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 3784b44 to f00bc4dCompare December 25, 2022 00:58

tnull approved these changes Jan 3, 2023
View reviewed changes

valentinewallace approved these changes Jan 3, 2023
View reviewed changes

valentinewallace reviewed Jan 3, 2023
View reviewed changes

TheBlueMatt merged commit 7d84a45 into lightningdevkit:mainJan 3, 2023

TheBlueMatt mentioned this pull request Jan 3, 2023
Parameterize ChannelManager by a Router#1812
Merged

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 9ca0fea to 3784b44Compare December 24, 2022 23:09

TheBlueMatt added 2 commits December 25, 2022 00:58

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 3784b44 to f00bc4dCompare December 25, 2022 00:58

tnull approved these changes Jan 3, 2023
View reviewed changes

valentinewallace approved these changes Jan 3, 2023
View reviewed changes

valentinewallace reviewed Jan 3, 2023
View reviewed changes

TheBlueMatt merged commit 7d84a45 into lightningdevkit:mainJan 3, 2023

TheBlueMatt mentioned this pull request Jan 3, 2023
Parameterize ChannelManager by a Router#1812
Merged

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 9ca0fea to 3784b44Compare December 24, 2022 23:09

TheBlueMatt added 2 commits December 25, 2022 00:58

TheBlueMatt force-pushed the 2022-12-113-bindings-upstream branch from 3784b44 to f00bc4dCompare December 25, 2022 00:58

tnull approved these changes Jan 3, 2023
View reviewed changes

valentinewallace approved these changes Jan 3, 2023
View reviewed changes

valentinewallace reviewed Jan 3, 2023
View reviewed changes

TheBlueMatt merged commit 7d84a45 into lightningdevkit:mainJan 3, 2023

TheBlueMatt mentioned this pull request Jan 3, 2023
Parameterize ChannelManager by a Router#1812
Merged

Uh oh!

Conversation

TheBlueMatt commented Dec 24, 2022

Uh oh!

codecov-commenter commented Dec 24, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

TheBlueMatt commented Dec 24, 2022

Uh oh!

codecov-commenter commented Dec 24, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

TheBlueMatt commented Dec 24, 2022

Uh oh!

codecov-commenter commented Dec 24, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

TheBlueMatt commented Dec 24, 2022

Uh oh!

codecov-commenter commented Dec 24, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov-commenter commented Dec 24, 2022•
edited
Loading

codecov-commenter commented Dec 24, 2022•
edited
Loading

codecov-commenter commented Dec 24, 2022•
edited
Loading

codecov-commenter commented Dec 24, 2022•
edited
Loading

codecov-commenter commented Dec 24, 2022•
edited
Loading

codecov-commenter commented Dec 24, 2022•
edited
Loading