profile
viewpoint
Andrew Cann canndrew Perth, Australia

canndrew/error_def 17

Rust syntax extension for generating error-handling boilerplate code.

canndrew/crust 3

Reliable p2p network connections in Rust with NAT traversal. One of the most needed libraries for any server-less / decentralised projects

canndrew/crust-futures 3

Port of crust to futures/tokio

canndrew/emoji-quickpick 3

Emoji picking app for Linux

canndrew/c_linked_list 2

Rust library for handling C linked lists

canndrew/atomic-arc 1

Atomically reference-counted atomic pointers for Rust

canndrew/abstractsocket 0

abstract unix sockets support for net.createConnection

canndrew/agda 0

Agda is a dependently typed programming language / interactive theorem prover.

canndrew/beaker-plugin-safe-authenticator 0

SAFE Authenticator plugin for SAFE Browser

canndrew/bincode 0

A binary encoder / decoder implementation in Rust.

push eventcanndrew/DotNetLightning

Andres G. Aragoneses

commit sha 734c09d1298a66eb2ba43dc905dd016bc1c868a5

Fix closing tx output-reordering bug (Based on PR[1] from Andrew Cann.) The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) `TransactionBuilder` shuffling them anyway when calling `BuildTransaction`. `makeClosingTx` now uses an explicit order and we disable shuffling inputs and outputs for all transactionBuilders (this feature was introduced in NBitcoin 5.0.54 [2] so an upgrade to this version is included). (As an extra improvement, this commit also renames 'n' to 'network', and creates a constant for 0xffffffff.) Fixes https://github.com/joemphilips/DotNetLightning/issues/131 [1] https://github.com/joemphilips/DotNetLightning/pull/132 [2] https://github.com/MetacoSA/NBitcoin/commit/db0d8247d372c2aa5b23017c038618ddbf765241

view details

joe.miyamoto

commit sha 1e5cc39972a29f890e79c14d505d8b75c7a24003

Update `closing_signed` correctly in negotiation. Cherry-picked from https://github.com/joemphilips/DotNetLightning/pull/121

view details

Andres G. Aragoneses

commit sha 02564ea98dd792aa47ccb57173cbc8d69d156998

Fix CI By updating FSharp.Core version, and cherry-picking these commits from upstream: https://github.com/joemphilips/DotNetLightning/commit/eb6bc282c5b08ea201bc7de2d959c9937f0e03a2 https://github.com/joemphilips/DotNetLightning/commit/b8945895fa5fee68cc3549e2b194e4cb68ab77c1 https://github.com/joemphilips/DotNetLightning/commit/762652a1f26b90328c90f71e8b46aeada6e5f1d6 CI was failing with: /Users/runner/work/DotNetLightning.Kiss/DotNetLightning.Kiss/tests/DotNetLightning.Client.Tests/DotNetLightning.Client.Tests.fsproj : warning NU1605: DotNetLightning.Client.Tests -> FSharp.Core (>= 4.7.0) [/Users/runner/work/DotNetLightning.Kiss/DotNetLightning.Kiss/DotNetLightning.sln] /Users/runner/work/DotNetLightning.Kiss/DotNetLightning.Kiss/src/DotNetLightning.Server/DotNetLightning.Server.fsproj : warning NU1605: Detected package downgrade: FSharp.Core from 4.7.2 to 4.7.1. Reference the package directly from the project to select a different version. [/Users/runner/work/DotNetLightning.Kiss/DotNetLightning.Kiss/DotNetLightning.sln] /Users/runner/work/DotNetLightning.Kiss/DotNetLightning.Kiss/src/DotNetLightning.Server/DotNetLightning.Server.fsproj : warning NU1605: DotNetLightning.Server -> DotNetLightning.Infrastructure -> FSharp.Core (>= 4.7.2) [/Users/runner/work/DotNetLightning.Kiss/DotNetLightning.Kiss/DotNetLightning.sln] /Users/runner/work/DotNetLightning.Kiss/DotNetLightning.Kiss/src/DotNetLightning.Server/DotNetLightning.Server.fsproj : warning NU1605: DotNetLightning.Server -> FSharp.Core (>= 4.7.1) [/Users/runner/work/DotNetLightning.Kiss/DotNetLightning.Kiss/DotNetLightning.sln] /Users/runner/work/DotNetLightning.Kiss/DotNetLightning.Kiss/tests/DotNetLightning.Integration.Tests/DotNetLightning.Integration.Tests.csproj : error NU1605: Detected package downgrade: FSharp.Core from 4.7.2 to 4.7.1. Reference the package directly from the project to select a di https://github.com/nblockchain/DotNetLightning.Kiss/runs/1285679289

view details

Andrew Cann

commit sha 98b7c45c0617721d4d2e9c1f9b3493d381fb0b25

Factor RemoteParam's keys into a ChannelPubKeys We already have a type (ChannelPubKeys) for holding the public keys for a channel end. The LocalParams type uses this to store the keys of the local end of a channel, but RemoteParams instead inlines all the keys for the remote end directly in the RemoteParams type. For consistency and simplicity, move these keys into a ChannelPubKeys stored in the RemoteParams.

view details

Andrew Cann

commit sha 4b42d13638559be4ac737aafba041313f7f93f28

Move and rename some key types Rename: CommitmentPubKey -> PerCommitmentPoint RevocationKey -> PerCommitmentSecret RevocationSet -> PerCommitmentSecretStore These types were incorrectly named. A commitment has a whole bunch of keys, not just a single key, so renaming CommitmentPubKey to PerCommitmentPoint makes it clear that this type refers to the concept of "per commitment point" used in the lightning spec. Likewise, RevocationKey is actually what the spec calls a "per commitment secret". It is not the revocation key which is used to spend the revocation branch of a commitment tx. A separate type for that will be introduced in a subsequent commit. Accordingly, RevocationSet is now more correctly named PerCommitmentSecretStore. Additionally, these types now use getter methods (instead of properties) to get the underlying NBitcoin key. This prevents keys from being incorrectly serialized by NewtonSoft json serializers. The key types are also moved into a new Crypto.Keys module. Other new keys types added in subsequent commits will be added here along side them.

view details

Andrew Cann

commit sha 520d7486ab836a92447733e427c93bd973261107

Use PerCommitmentPoint in BOLT #3 test Rather than using a PubKey to represent a per-commitment-point, use the type that's specifically for this.

view details

Andrew Cann

commit sha 7f7aa3bbb7ef6e4763299b1ca6d74ab87f67f3d3

Capitalise "basepoint" consistently (with lowercase 'p') So that I don't keep using the wrong capitalisation of "basepoint" vs "basePoint"

view details

Andrew Cann

commit sha faafad2cb9156f93d2d304af80a02f9234927ce0

Rename CryptoUtils.Op type to Operation The name "Op" conflicts with the Op type from NBitcoin. This would cause problems if both CryptoUtils and NBitcoin were imported into the same module.

view details

Andrew Cann

commit sha 8913a00e7c763b3a4d9060ade4223d88262f0b65

Move Channel{Pub,}Keys into Crypto.Keys module This will be the place that all the new keys types will live. Channel{Pub,}Keys will depend on these types, requiring it to be moved to after the declaration of these types.

view details

Andrew Cann

commit sha c45e690880e12e0a463232b50393abc9dfad9677

Add ReadKey method and avoid magic number in LightningStream Add a new ReadKey method, similar to ReadPubKey, which other key-reading methods can be built off of. Use ReadKey/ReadPubKey to read the existing other keys types that are based off of Key/PubKey. Use the BytesLength static properties of Key/PubKey rather than hard-coding magic numbers into the LightningStream code.

view details

Andrew Cann

commit sha fda646f8d34b46a19ccaf79fe70904867886c424

Add delayed payment key types Add four new types for representing delayed payment keys. DelayedPaymentPubKey and DelayedPaymentPrivKey are the public/private delayed payment keys used in commitment transactions. DelayedPaymentBasepoint and DelayedPaymentBasepointSecret are the basepoint and basepoint secret used to derive the delayed payment keys for individual commitment transactions based on the per commitment point.

view details

Andrew Cann

commit sha 9437e28e4140183106a7bda997573b885ee28c0a

Move {Obscured,}CommitmentNumber into Crypto.Keys These types are used in conjunction with payment keys so they have to be defined along-side them since F# doesn't allow mutual dependencies back-and-forth between modules.

view details

Andrew Cann

commit sha ec922ca7bc8a697d5163fbd232e16a7fed724d3c

Add payment key types Add PaymentPrivKey and PaymentPubKey types which correspond to the payment keys used in commitment transactions. Also add PaymentBasepoint and PaymentBasepointSecret types which are the basepoint and basepoint secret used to derive the payment keys for each commitment transaction.

view details

Andrew Cann

commit sha e7a062566d4f2ea60a02f6e12b8c18addf995abd

Add htlc key types Add types for htlc keys and basepoints.

view details

Andrew Cann

commit sha 70eb333e402f4e964aa8bcc3e97a81c469698c34

Add revocation key types

view details

Andrew Cann

commit sha 29cb52b7875b3139f6c7af921f6534daa9727c1c

Add funding key types

view details

Andrew Cann

commit sha 6527efe647cdf9179efe7194ff229e8c693d371e

Make getFundingScriptCoin take funding pubkeys The funding redeem scripts is based on the channel's funding pubkeys. So for extra type-safety getFundingScriptCoin should take FundingPubKeys rather than raw PubKeys. Also, de-duplicate the getFundingRedeemScript and multiSigOfM_2 functions into a single Scripts.funding function which takes funding pubkey specificially.

view details

Andrew Cann

commit sha 71def77d3c3da9da32e97e2d2fd6bdfe89ff7179

Turn key derivation functions into methods Each key type now has a separate method for deriving it. This is to prevent keys from being misused as the wrong kind of key. In the lightning network every commitment tx has a per commitment point which determines how the commitment's keys are derived from the basepoints. Since the PerCommitmentPoint can be seen as a kind of "master key" for a commitment, the functions methods have been turned into methods on that type. This makes the code simpler and easier to understand.

view details

Andrew Cann

commit sha 6f570b187377151da64a07a7e40138069db2ebf9

Remove unused newSecp256k1 The NBitcoinArithmethicExtensions module stores a single ISecp256k1 which is accessible to its methods which is the only place the value is used directly. So we no longer need to plumb an ISecp256k1 through the code everywhere.

view details

Andrew Cann

commit sha 5d4f07131fea560503424f9a9839e7da0ef7b29e

Add CommitmentPubKeys type This type stores all the pubkeys for a commitment tx for one side of a channel. Wrapping these keys into a type allows us to derive all the keys with a single method call.

view details

push time in 4 days

pull request commentjoemphilips/DotNetLightning

Update `closing_signed` correctly in negotiation.

Hi @joemphilips. Can this be merged? It looks good to me and we need it to make closing work in geewallet.

joemphilips

comment created time in 6 days

PR closed joemphilips/DotNetLightning

Fix closing tx output-reordering bug

The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) TransactionBuilder shuffling them anyway when calling BuildTransaction.

makeClosingTx now makes the closing tx using Transaction directly rather than TransactionBuilder. This allows us to set the order of the outputs explicitly.

+19 -11

2 comments

1 changed file

canndrew

pr closed time in 7 days

pull request commentjoemphilips/DotNetLightning

Fix closing tx output-reordering bug

Closing in favor of https://github.com/joemphilips/DotNetLightning/pull/133

canndrew

comment created time in 7 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 1c6d9e951207dfbfa21e05eec094f97ebccb0e9d

Fix closing tx output-reordering bug The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) `TransactionBuilder` shuffling them anyway when calling `BuildTransaction`. `makeClosingTx` now makes the closing tx using `Transaction` directly rather than `TransactionBuilder`. This allows us to set the order of the outputs explicitly. Fixes https://github.com/joemphilips/DotNetLightning/issues/131

view details

push time in 7 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha f3d9a8d126350816c1f45000fbc0be20f97331ea

Fix closing tx output-reordering bug The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) `TransactionBuilder` shuffling them anyway when calling `BuildTransaction`. `makeClosingTx` now makes the closing tx using `Transaction` directly rather than `TransactionBuilder`. This allows us to set the order of the outputs explicitly. Fixes https://github.com/joemphilips/DotNetLightning/issues/131

view details

push time in 7 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 20ced1f6737d47d31aa1382ac29c6834d98517b9

Fix closing tx output-reordering bug The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) `TransactionBuilder` shuffling them anyway when calling `BuildTransaction`. `makeClosingTx` now makes the closing tx using `Transaction` directly rather than `TransactionBuilder`. This allows us to set the order of the outputs explicitly. Fixes https://github.com/joemphilips/DotNetLightning/issues/131

view details

push time in 7 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 871ecf753c9e79624467173c4829836a08171650

Fix closing tx output-reordering bug The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) `TransactionBuilder` shuffling them anyway when calling `BuildTransaction`. `makeClosingTx` now makes the closing tx using `Transaction` directly rather than `TransactionBuilder`. This allows us to set the order of the outputs explicitly. Fixes https://github.com/joemphilips/DotNetLightning/issues/131

view details

push time in 7 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha e81754d2346169c2a19a39d603758eb49a3b7f43

Fix closing tx output-reordering bug The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) `TransactionBuilder` shuffling them anyway when calling `BuildTransaction`. `makeClosingTx` now makes the closing tx using `Transaction` directly rather than `TransactionBuilder`. This allows us to set the order of the outputs explicitly. Fixes #131

view details

push time in 7 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 92c209b7be1927ba24005a32e945a8f144894516

Fix closing tx output-reordering bug The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) `TransactionBuilder` shuffling them anyway when calling `BuildTransaction`. `makeClosingTx` now makes the closing tx using `Transaction` directly rather than `TransactionBuilder`. This allows us to set the order of the outputs explicitly. Fixes #131

view details

push time in 7 days

PR opened nblockchain/DotNetLightning.Kiss

Closing tx fixes

The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) TransactionBuilder shuffling them anyway when calling BuildTransaction.

makeClosingTx now makes the closing tx using Transaction directly rather than TransactionBuilder. This allows us to set the order of the outputs explicitly.

This PR also includes an earlier fix from joe.

+25 -11

0 comment

2 changed files

pr created time in 7 days

PR opened joemphilips/DotNetLightning

Fix closing tx output-reordering bug

The lightning spec decrees that the closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) TransactionBuilder shuffling them anyway when calling BuildTransaction.

makeClosingTx now makes the closing tx using Transaction directly rather than TransactionBuilder. This allows us to set the order of the outputs explicitly.

+22 -11

0 comment

1 changed file

pr created time in 7 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha fc96b2137181da1305c796cac796c94a0b51cc6b

Fix closing tx output-reordering bug The lightning spec decrees that he closing tx's outputs need to be in lexicographical order. Instead, they were ending up in the wrong order thanks to (a) not being added in the correct order and (b) `TransactionBuilder` shuffling them anyway when calling `BuildTransaction`. `makeClosingTx` now makes the closing tx using `Transaction` directly rather than `TransactionBuilder`. This allows us to set the order of the outputs explicitly.

view details

push time in 7 days

issue commentjoemphilips/DotNetLightning

Channel closing fails with "failed to finalize psbt"

I swear last week I was seeing a problem with fee rates being different on each end, but the error I'm getting now is that tx outputs are in different order on each end. There's no way to disable shuffling on a TransactionBuilder without upgrading to an NBitcoin that has the changes that @knocte linked above, and even then the lightning spec requires that the outputs are in lexicographic order but TransactionBuilder doesn't have a way to set this or to add the TxOuts manually (after comparing them to determine their order). So I'm going to avoid using TransactionBuilder in the fix. I already had to do this in other places in geewallet, and it doesn't seem like TransactionBuilder is actually buying us anything here.

canndrew

comment created time in 8 days

issue commentjoemphilips/DotNetLightning

Channel closing fails with "failed to finalize psbt"

So if I were you I would try printing the PSBT returned from makeClosingTx on both sides and see the difference.

That's what I did. The fee rates specified in the two PSBTs are different.

canndrew

comment created time in 8 days

issue commentjoemphilips/DotNetLightning

Channel closing fails with "failed to finalize psbt"

The problem is something to do with fee negotiation. When it breaks, the fee rates are different on the two sides of the channel...

canndrew

comment created time in 11 days

issue commentjoemphilips/DotNetLightning

Channel closing fails with "failed to finalize psbt"

The funder initiates the closing. When it fails it always fails on the fundee's side.

canndrew

comment created time in 11 days

issue commentjoemphilips/DotNetLightning

Channel closing fails with "failed to finalize psbt"

Any idea what's causing this? It's coming from PSBT.TryFinalize in NBitcoin. As far as I can see, the only relevant place where NBitcoin throws a NullFail is when checking the transaction signatures when checking an OP_CHECKMULTISIG, so perhaps the transaction is malformed relative to the signatures? As I say, this only happens about 50% of the time though, (and works the rest of the time) so maybe that's a clue.

canndrew

comment created time in 11 days

issue openedjoemphilips/DotNetLightning

Channel closing fails with "failed to finalize psbt"

In geewallet we have a test that opens then closes a channel between two peers using DotNetLightning. About 50% of the time the peer which accepts the channel close (not the initiator) will crash with an exception thrown from DotNetLightning:

TransactionRelatedErrors
        [FailedToFinalizeScript
           "failed to finalize psbt Errors: seq [Input 0: The finalized input script does not properly validate "NullFail"] 
 PSBTInput: {
  "index": 0,
  "partial_signatures": {
    "02db5e2701d93ca1b07c851dda2125d4b6cc36fe378db3719f384ba7dd2dfa2d8c": "304402206b74ee87e5955097515c9c300b01a9b4f7762ac102915291add469cb3dcf256c022073457a0a6f931a0ff29e9fbf29972d3a2d9b2147946b09839cf5a3ecd018dfb701",
    "0389ecd0689e9db416e2a04eda4cc817aae00bb906765f29616617ec10120039cd": "304402205e3c21be6cd331a590662d8161c521e0e82440f0981959cc7f5a43b72e2c2c5d022040de0b8d750178fbc81b339368a287142b7e0789971f0df0b1e659c71f74a22101"
  },
  "witness_script": "2 02db5e2701d93ca1b07c851dda2125d4b6cc36fe378db3719f384ba7dd2dfa2d8c 0389ecd0689e9db416e2a04eda4cc817aae00bb906765f29616617ec10120039cd 2 OP_CHECKMULTISIG",
  "witness_utxo": {
    "value": "0.10000000",
    "scriptPubKey": "0 97548049d3dea0202df8566d01fcd747b1157b9c4bd5b49aa07e1f49a4883ba5"
  },
  "bip32_derivs": []
} 
 base64 PSBT: cHNidP8BAHMCAAAAAfvA05Q3DdmVyZAlCpXMh97XuFJkSt2PY1zRQsiqWK9bAAAAAAD/////AqAlJgAAAAAAF6kUaE6LBCrgQ3qWZuXvaVhWIIN5cT6HrE9yAAAAAAAXqRT1S8cHNnV67ocL/6lFxS02Vp64CIcAAAAAAAEBK4CWmAAAAAAAIgAgl1SASdPeoCAt+FZtAfzXR7EVe5xL1bSaoH4fSaSIO6UBBUdSIQLbXicB2TyhsHyFHdohJdS2zDb+N42zcZ84S6fdLfotjCEDiezQaJ6dtBbioE7aTMgXquALuQZ2XylhZhfsEBIAOc1SriICAtteJwHZPKGwfIUd2iEl1LbMNv43jbNxnzhLp90t+i2MRzBEAiBrdO6H5ZVQl1FcnDALAam093YqwQKRUpGt1GnLPc8lbAIgc0V6Cm+TGg/ynp+/KZctOi2bIUeUawmDnPWj7NAY37cBIgIDiezQaJ6dtBbioE7aTMgXquALuQZ2XylhZhfsEBIAOc1HMEQCIF48Ib5s0zGlkGYtgWHFIeDoJEDwmBlZzH9aQ7cuLCxdAiBA3guNdQF4+8gbM5NooocUK34HiZcfDfCx5lnHH3SiIQEAAAA="]

Any idea what's causing this? It's coming from PSBT.TryFinalize in NBitcoin. As far as I can see, the only relevant place where NBitcoin throws a NullFail is when checking the transaction signatures when checking an OP_CHECKMULTISIG, so perhaps the transaction is malformed relative to the signatures? As I say, this only happens about 50% of the time though, (and works the rest of the time) so maybe that's a clue.

created time in 11 days

create barnchcanndrew/DotNetLightning

branch : nblockchain-key-types-refactor

created branch time in 20 days

issue openedbtcpayserver/BTCPayServer.Lightning

LND swagger client fails to parse response for CloseChannelAsync

I'm calling LndSwaggerClient.CloseChannelAsync. The response I'm getting from lnd is:

{"result":{"close_pending":{"txid":"WlbkadALmDboZFa94uXU/g2IhANqirhx2QlLeMlytFw=","output_index":0}}}
{"result":{"chan_close":{"closing_txid":"WlbkadALmDboZFa94uXU/g2IhANqirhx2QlLeMlytFw=","success":false}}}

The swagger client fails to parse this response and throws an exception:

   System.AggregateException : One or more errors occurred. (Could not deserialize the response body.)
  ----> BTCPayServer.Lightning.LND.SwaggerException : Could not deserialize the response body.
  ----> Newtonsoft.Json.JsonReaderException : Additional text encountered after finished reading JSON content: {. Path '', line 2, position 0.

Clearly it's not happy that lnd returned multiple results. A look at the code shows that the entire response body is passed to a single call to JsonConvert.DeserializeObject, which fails because the response contains multiple objects.

A look at the lnd swagger API spec says that this is expected behaviour (annotated):

"operationId": "CloseChannel",
"responses": {
  "200": {
    "description": "A successful response.(streaming responses)",       // <- "streaming responses"
    "schema": {
      "type": "object",
      "properties": {
        "result": {
          "$ref": "#/definitions/lnrpcCloseStatusUpdate"
        },
        "error": {
          "$ref": "#/definitions/runtimeStreamError"
        }
      },
      "title": "Stream result of lnrpcCloseStatusUpdate"                // <- "Stream result"
    }
  },
  "default": {
    "description": "An unexpected error response",
    "schema": {
      "$ref": "#/definitions/runtimeError"
    }
  }
},

I'm not sure how to fix this since the LndSwaggerClient code is automatically generated from the API spec. Closing a channel takes time and happens in stages, so CloseChannelAsync needs to return some kind of stream or event source that the user can use to monitor the progress of the operation. It seems like it's already supposed to do that since LnrpcCloseStatusUpdate inherits from System.ComponentModel.INotifyPropertyChanged, so maybe CloseChannelAsync is correct to return a single LnrpcCloseStatusUpdate and that value should then be getting updated when new responses come in. But it's not clear to me whether or how that's implemented, and either way it's not working correctly.

created time in 20 days

CommitCommentEvent

issue openedjoemphilips/DotNetLightning

DotNetLightning conflates RevocationKey and PerCommitmentSecret

When trying to use DotNetLightning to implement revocation in geewallet I struggled to make sense of the revocation APIs until I realized they don't actually make sense. The main problem is that revocation keys and per commitment secrets are two different things, yet the RevocationKey type is actually a type that holds a per commitment secret. This is my doing, since I added the RevocationKey/RevocationSet types. Additionally, some key-related fields and variables have names that don't match the names in the lightning spec. This made it difficult for me to be confident that I'm using keys correctly, especially after I became aware that at least one thing I had to use was completely misnamed as another thing.

To fix this I'm working on a PR that (a) renames Revocation{Key,Set} as well as some fields to match the names used in the spec and (b) adds Key/PubKey-wrapper types for some more keys (like I did for RevocationKey) so that it's a type-error to use them incorrectly (eg. by using the wrong key to derive some other key). This should make both DNL's and its consumers' code more readable as well as more bug-proof.

The WIP branch is here: https://github.com/canndrew/DotNetLightning/tree/key-types-refactor

created time in 21 days

create barnchcanndrew/DotNetLightning

branch : key-types-refactor

created branch time in 21 days

pull request commentidris-lang/Idris2

add more Name reflections

I'm trying to build this branch but I'm having problems. If I build it using my existing idris2 install (which is built from current master - db9f7bbf0d42af9299920a3cf84a831f9cbe2cdd) then I get:

make[1]: Entering directory '/home/shum/src/idris/Idris2/support/c'
cc -Wall  -fPIC -O2   -c -o idris_file.o idris_file.c
cc -Wall  -fPIC -O2   -c -o idris_net.o idris_net.c
cc -Wall  -fPIC -O2   -c -o getline.o getline.c
cc -Wall  -fPIC -O2   -c -o idris_term.o idris_term.c
cc -Wall  -fPIC -O2   -c -o idris_directory.o idris_directory.c
cc -Wall  -fPIC -O2   -c -o idris_support.o idris_support.c
cc -Wall  -fPIC -O2   -c -o idris_buffer.o idris_buffer.c
ar rc libidris2_support.a idris_file.o idris_net.o getline.o idris_term.o idris_directory.o idris_support.o idris_buffer.o
ranlib libidris2_support.a
cc -shared -o libidris2_support.so idris_file.o idris_net.o getline.o idris_term.o idris_directory.o idris_support.o idris_buffer.o 
make[1]: Leaving directory '/home/shum/src/idris/Idris2/support/c'
echo 'module IdrisPaths' > src/IdrisPaths.idr
echo 'export idrisVersion : ((Nat,Nat,Nat), String); idrisVersion = ((0,2,1), "aef89bfb2")' >> src/IdrisPaths.idr
echo 'export yprefix : String; yprefix="/home/shum/.idris2"' >> src/IdrisPaths.idr
idris2 --build idris2.ipkg
1/158: Building Core.FC (src/Core/FC.idr)
2/158: Building Core.Name.Namespace (src/Core/Name/Namespace.idr)
3/158: Building Core.Name (src/Core/Name.idr)
4/158: Building Data.Bool.Extra (src/Data/Bool/Extra.idr)
5/158: Building Data.NameMap (src/Data/NameMap.idr)
6/158: Building Algebra.Semiring (src/Algebra/Semiring.idr)
7/158: Building Algebra.Preorder (src/Algebra/Preorder.idr)
8/158: Building Algebra.ZeroOneOmega (src/Algebra/ZeroOneOmega.idr)
9/158: Building Algebra (src/Algebra.idr)
10/158: Building Core.TT (src/Core/TT.idr)
src/Core/TT.idr:465:37--465:66:While processing right hand side of cast at src/Core/TT.idr:465:3--467:3:
{as:2988} is not accessible in this context at:
465	  cast {ys = y :: ys} eq (S p) = S (cast (succInjective _ _ eq) p)
	                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Core/TT.idr:506:40--506:51:While processing right hand side of reverse at src/Core/TT.idr:506:3--508:3:
Undefined name hlReverse at:
506	  reverse (MkSizeOf n p) = MkSizeOf n (hlReverse p)
	                                       ^^^^^^^^^^^

Makefile:58: recipe for target 'build/exec/idris2' failed
make: *** [build/exec/idris2] Error 1

If I try to build it using make bootstrap SCHEME=chezscheme9.5 I get:

make[1]: Entering directory '/home/shum/src/idris/Idris2/support/c'
cc -Wall  -fPIC -O2   -c -o idris_file.o idris_file.c
cc -Wall  -fPIC -O2   -c -o idris_net.o idris_net.c
cc -Wall  -fPIC -O2   -c -o getline.o getline.c
cc -Wall  -fPIC -O2   -c -o idris_term.o idris_term.c
cc -Wall  -fPIC -O2   -c -o idris_directory.o idris_directory.c
cc -Wall  -fPIC -O2   -c -o idris_support.o idris_support.c
cc -Wall  -fPIC -O2   -c -o idris_buffer.o idris_buffer.c
ar rc libidris2_support.a idris_file.o idris_net.o getline.o idris_term.o idris_directory.o idris_support.o idris_buffer.o
ranlib libidris2_support.a
cc -shared -o libidris2_support.so idris_file.o idris_net.o getline.o idris_term.o idris_directory.o idris_support.o idris_buffer.o 
make[1]: Leaving directory '/home/shum/src/idris/Idris2/support/c'
cp support/c/libidris2_support.so bootstrap/idris2_app
sed s/libidris2_support.so/libidris2_support.so/g bootstrap/idris2_app/idris2.ss > bootstrap/idris2_app/idris2-boot.ss
sed -i 's|__PREFIX__|/home/shum/src/idris/Idris2/bootstrap|g' bootstrap/idris2_app/idris2-boot.ss
sh ./bootstrap.sh
bootstrapping SCHEME=chezscheme9.5 IDRIS2_VERSION=0.2.1
Building idris2-boot from idris2-boot.ss
compiling idris2_app/idris2-boot.ss with output to idris2_app/idris2-boot.so
/home/shum/src/idris/Idris2/bootstrap
make[1]: Entering directory '/home/shum/src/idris/Idris2'
make -C libs/prelude IDRIS2=../../build/exec/idris2 IDRIS2_PATH="/home/shum/src/idris/Idris2/libs/prelude/build/ttc:/home/shum/src/idris/Idris2/libs/base/build/ttc:/home/shum/src/idris/Idris2/libs/contrib/build/ttc:/home/shum/src/idris/Idris2/libs/network/build/ttc"
make[2]: Entering directory '/home/shum/src/idris/Idris2/libs/prelude'
../../build/exec/idris2 --build prelude.ipkg
Exception in foreign-procedure: no entry for "idris2_setupTerm"
Makefile:2: recipe for target 'all' failed
make[2]: *** [all] Error 255
make[2]: Leaving directory '/home/shum/src/idris/Idris2/libs/prelude'
Makefile:69: recipe for target 'prelude' failed
make[1]: *** [prelude] Error 2
make[1]: Leaving directory '/home/shum/src/idris/Idris2'
Makefile:146: recipe for target 'bootstrap-build' failed
make: *** [bootstrap-build] Error 2
MarcelineVQ

comment created time in a month

create barnchcanndrew/fsharp-debian

branch : 4.1.14-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.1.13-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.1.12-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.1.11-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.1.10-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.1.9-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.1.0.0-debianized-broken

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.22-debianized-broken

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.21-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.20-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.19-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.18-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.17-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.16-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.15-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.14-debianized

created branch time in 2 months

push eventcanndrew/fsharp-debian

buybackoff

commit sha db5c20860bfc5c8cac1674bf1983234cd2d2fbca

Foreach optimization

view details

buybackoff

commit sha b4a6cc1d320fe2ffd3ac08ad7f931e7f4d5893c1

Revert Seq changes

view details

Omar Tawfik

commit sha 1b8b26a6aa384a41da0e198c1e9c7a121d276434

Test fixes

view details

Omar Tawfik

commit sha 1915f82eb629e85acf7de42e8313ecd3a2554c7b

Update .net version to 4.6

view details

Omar Tawfik

commit sha d360287ae44cf9029f2bf50783add3827c02b3f7

Added new language service/project/package based on Roslyn

view details

Omar Tawfik

commit sha 41c999fe2a2d416d3ac2c47bb6a1152aa19660bb

Merge branch 'master' of https://github.com/Microsoft/visualfsharp into newlanguageservice

view details

Omar Tawfik

commit sha 21571caa45edd5494455565022ca285a4cdd99c4

Resolve conflicts due to projects refactoring

view details

Omar Tawfik

commit sha 497c854cc294495276774b3ad1560b2967020eac

Added switch between old/new language services

view details

Omar Tawfik

commit sha dbd4a83656d3d82b6ae09c14da5cdf26222f4dc7

Added Roslyn myget packages to build

view details

Omar Tawfik

commit sha 90462270f16ac5af8ce7b7293d9040667094614f

Revert "Update .net version to 4.6" This reverts commit 1915f82eb629e85acf7de42e8313ecd3a2554c7b.

view details

Omar Tawfik

commit sha 41eb8a858076f250820826fb5ee51a394dd728bd

Updated just the vsintegration projects to .net 4.6

view details

Omar Tawfik

commit sha 44ecd52e6535dd169a301b2b5cf777ae9c01c3f5

Replaced old language service with roslyn based service

view details

Omar Tawfik

commit sha b2db3ebf4d5712c5464fd809a549f411d3636538

Merge branch 'master' of https://github.com/Microsoft/visualfsharp into newlanguageservice

view details

Omar Tawfik

commit sha 5ef9c7353256d722a835b550c3e23e96b51ff321

Merge branch 'master' of https://github.com/otawfik-ms/visualfsharp into newlanguageservice

view details

Omar Tawfik

commit sha 0172d9cdc4d632d30ed6f14f10a738b3279be3b8

Fix test breaks

view details

Omar Tawfik

commit sha 357ba39b8261f4fc23438d9c2470d1457b7bf847

Merge branch 'master' of https://github.com/Microsoft/visualfsharp into newlanguageservice

view details

Omar Tawfik

commit sha 08be5d62a4e639b236d9bd685ee3ebf76e9639a6

Update Roslyn packages to 1.2.0-beta1-20160218-02

view details

Omar Tawfik

commit sha b3724dbfa9e2f7f4c7980dc08f124b7fc4b6759b

Disabling editor factories until fully implemented

view details

Omar Tawfik

commit sha c6cebf849e1ee01c7b98ac7a800fe5d7a93f6382

Addressing code review comments

view details

Omar Tawfik

commit sha 3a36f79dc150ffa61a037a67f877b593d4a5265c

Merge pull request #974 from otawfik-ms/newlanguageservice Replaced old language service with Roslyn-based one

view details

push time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.10-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.9-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.8-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.5-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.4-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.3-debianized

created branch time in 2 months

pull request commentjoemphilips/DotNetLightning

remove useless Client and its tests

@knocte: :+1: We don't use the Client stuff at all.

joemphilips

comment created time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.2-debianized

created branch time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha bd69d0023d79af1e003c005885fb0e414aa18f61

Fix path to fssrgen.exe in install file

view details

Andrew Cann

commit sha 72fb1113d620a84aca406a828777313a9df8277e

Remove typeproviders package This was removed from the upstream source for some reason. I'm not sure if it now exists in some external repo somewhere or if it's now built into the FSharp.Core.

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha f8a2999a3c563fc7403b8f08a644c7792144a5ae

Make executables in bootstrap executable

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 3a4af35cbe665645bfe8aec90143da584544b87e

Fix check for xbuild in Microsoft.FSharp.Targets

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 469e215652f368c9d3004b71ae1f5261cf49bd30

Add System.Reflection.Metadata.1.4.1-beta-24227-04 to bootstrap

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 74dab837bf97b97ea9d3ad0a6ade322917c2f39f

Add System.Collections.Immutable.1.2.0 to bootstrap

view details

Andrew Cann

commit sha e831017056bbe9d90c8dbdf3de242aaff83816b2

Change path to System.Collections.Immutable to point into bootstrap dir

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 1367a2592a0d2cf42c2efe8baed84e4d2e50a98c

Add entire contents of FSharp.Compiler.Tools.4.0.0.4 to bootstrap

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 1b00bdf87fded1205c6e1026e4b4c8ab638f5f8d

Fix path to SRGen to point to bootstrap

view details

Andrew Cann

commit sha 36faa6e462f2e849582bd201dd042010040cc4ae

Add fssrgen.exe to bootstrap

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha b3013f821c96d61ff64e017a90c61f160a55e8ca

Add with-bootstrap flag to configure

view details

Andrew Cann

commit sha 8c6d65574221ad651ff3ae96f745e1ff4243c31b

Add contents of FSharp.Compiler.Tools.4.0.0.1 to bootstrap

view details

Andrew Cann

commit sha f9e41584e9a2ff4463cb0aea35b488b34e953775

Point LkgPath at the bootstrap directory

view details

Andrew Cann

commit sha 4d1287efc92fdf903de2c5d732ffe1dd095ba37d

Fix path to SRGen to point to bootstrap

view details

push time in 2 months

create barnchcanndrew/fsharp-debian

branch : tag-by-tag

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.1-debianized

created branch time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.0.1.0-debianized

created branch time in 2 months

push eventcanndrew/fsharp-debian

shum

commit sha e27e17f7e5cf698ef43c6930f11ef930b22b6fa2

make xbuild verbose

view details

shum

commit sha a79d1f2ea632dd10280a89d1c98a42c3f24eedd4

Add debugging to FSharpSource.targets

view details

shum

commit sha 6339270f8ba4a8e5002a09e564c78349b9e6726b

Fix typo in FSharpSource.targets

view details

shum

commit sha f02404ad66f704ff7c7739033497099257f363ad

Try to fix path for FSharpTargetsPath

view details

shum

commit sha e457c824b33c94fa56c63c93666f9f91abb19bee

Apply debian/patches to make experimentation easier

view details

shum

commit sha 6b14156a63cf787f5fcba399b4bfd750ab2856af

Ignore missing fsi.exe

view details

shum

commit sha 9532a7830cc4fb3e2d53f416741302f5e261cde2

uncomment import of FSharpTargetsPath

view details

shum

commit sha 70246808269e23f8f07024821202262fae657f3e

Try to fix path to fslex.exe and fsyacc.exe

view details

shum

commit sha f9d911b11a63b01b961881c4ede1510d83b86e0f

Change FSharpTargetsPath everywhere its set under bootstrap

view details

shum

commit sha 45b2b404164c20826270e0458ee55c0ba23af373

try to add debugging to FSharp.Core

view details

shum

commit sha e30922d341964122f56dd7e7cc55378697fe7f52

Set FSharpTargetsPath in FSharp.Core.fsproj

view details

shum

commit sha e58d8c3cfc0ff36e405555263c7dab1ee85ac2f4

set FSharpTargetsPath in FSharpSource.Settings.targets too

view details

shum

commit sha 0cadc6a8edab2dd253f5946d7e46422d56d32e61

Hard code path to avoid $FSharpTargetsPath

view details

shum

commit sha 34f7c73125dbb620cdc84e2411dd64d176e7e344

And also don't check the other locations

view details

shum

commit sha baee5e87ead6f116d59854f29654f5af7efdfd0e

Ignore missing fsc.exe

view details

shum

commit sha f02a4cb529385ae58d48d2438fa706287ca777ba

Don't try to copy stuff from packages

view details

shum

commit sha 7eb80380e117c95d433212182279ebcf33e45b09

Unconditionally use xbuild in Microsoft.FSharp.Targets

view details

push time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.5.0-debianized

created branch time in 2 months

push eventcanndrew/fsharp-debian

Andres G. Aragoneses

commit sha 374b42dd75bda6a8d9f39e0933dece270a85c016

autogen.sh: remove aclocal calls, not needed anymore Since we stop using autoconf macros (such as PKG_CHECK_MODULES; see [1]) in [2], aclocal is not likely to be needed anymore. [1] http://tirania.org/blog/archive/2012/Oct-20.html [2] https://github.com/fsharp/fsharp/commit/cded42fb1929f9ca1edcb5ecc38c052287caba0e

view details

Heather Mason

commit sha b4087aea1411ca728b817a7b96bde815d1b51b84

build script

view details

Matthias Dittrich

commit sha 60f094603c15657174aac8f12ac1a6f065710134

use ClrRoot of current RuntimeEnvironment instead of hardcoded 4.0 on mono

view details

funnelweb

commit sha d603ceee1d755170dd932d4f9d9cfbb2afd012ea

Merge pull request #121 from matthid/useRuntimeClrRoot use ClrRoot of current RuntimeEnvironment instead of hardcoded 4.0 on mono

view details

funnelweb

commit sha c5d650d50d39da5084422cd6a5ddb28509abb1b8

Merge pull request #120 from Heather/heather nothing but build script

view details

Anton Tayanovskyy

commit sha 56fc62be2746fd5dca5fe418af9b490475e0f8a2

Attempt to fix #119. Fixes the example on cold start "fsi --exec $file" on Mono

view details

Dave Thomas

commit sha 5990786db149ab67a928e19cd5a4ddf9adbc69cd

Updated readme, added in configuration for MonoTouch target.

view details

funnelweb

commit sha 8efa1c57cb99b87c61ac3db8f41bb407b564a0cd

Merge pull request #126 from intellifactory/master Fix fsharp/fsharp:#119

view details

funnelweb

commit sha 95e24d8ac52cd905efb37a0b8dfc16f224733a56

Merge pull request #128 from 7sharp9/patch-1 Updated readme, added in configuration for MonoTouch target.

view details

7sharp9

commit sha 5f3a23c145919dee2d59550c027dc989f3c9e051

Added MonoTouch assemblies to the dependencies folder

view details

7sharp9

commit sha cba8d2579f1945194787b9c6227df1e3cb24466d

Added a new target to the build - monotouch This new target build FSharp.Core against the monotouch mscorlib, System and system.Core

view details

funnelweb

commit sha f3c8ea8bf4831ce6dc30581558fa4a45a078cd55

Merge pull request #129 from 7sharp9/master Added a new 'monotouch' target to the build process

view details

7sharp9

commit sha 3edb6b313099e62a102ddbeb96d6b3d2d27a47bf

Fix for #131 - SimpleSourceCodeServices.fs will not generate dynamic assemblies for non silverlight builds

view details

Don Syme

commit sha f661d8c6e048994d5acaa7061b83b8bfee6c0779

Merge pull request #132 from 7sharp9/master Fix for #131 - SimpleSourceCodeServices.fs will not generate dynamic assemblies for non silverlight builds

view details

Christopher James Halse Rogers

commit sha 03579255a66942efb89d8b43746e6b5496ddb908

Imported Upstream version 3.0.27

view details

Christopher James Halse Rogers

commit sha 81d2e30464f37e167774d2d48cbbf00b243b7bb5

Merge tag 'upstream/3.0.27' Upstream version 3.0.27

view details

Christopher James Halse Rogers

commit sha 577f7b762b59f5b760162904d8dfb2b1accdaee2

Add README.source, documenting the +dfsg

view details

Christopher James Halse Rogers

commit sha 5c4564a63067ef18922c14fb7b42b2fca6a62ecb

Add Vcs-Git headers

view details

Christopher James Halse Rogers

commit sha 63aaab9b37188e937cd86f1ddd784172b9c226d6

Add libfsharp-core-cil-dev package This contains the symlinks into /usr/lib/mono/4.0, where FSharp.Compiler looks when not given an explicit reference to FSharp.Core.dll. Closes: 705924, Closes: 705906

view details

Christopher James Halse Rogers

commit sha 5227e102e1b5fe97224e01b19379aa12f062b69a

Don't build 2.0- and 3.5-profile F# libraries

view details

push time in 2 months

PR opened nblockchain/fsharp-debian

WIP - F# 4.5 debianized

This is not yet passing on CI because I haven't yet figured out how to run the test suite in github CI. The tests are copied from the mono-project repo since the original debian repo doesn't have any. My package also currently creates almost-empty packages though I know (more or less) how to fix that.

This version of the package was created by taking the 4.5.0 tag of https://github.com/fsharp/fsharp and following the debian packaging instructions: https://www.debian.org/doc/manuals/debmake-doc/index.en.html to crate the debian/ directory in the source directory.

The resulting package data is a lot slimmer than what the mono-project version has. Here's the list of differences and what I'd like to know before being confident in my package.

Their debian/ has a README.source file. Is this file necessary/expected?

Their debian/compat specifies version 8, vs my 9. I doubt this is an issue.

Their debian/control specifies the maintainer as "Debian CLI Applications Team pkg-cli-apps-team@lists.alioth.debian.org". Mine currently has "Christopher James Halse Rogers raof@ubuntu.com" since this is what is in the current debian package. They also list a bunch of extra build dependencies, none of which seem to be necessary to actually build the package but may be necessary for testing or something. They also split fsharp to less packages than the original debian package, omitting fsharp-console (subsumed into the fsharp package), libfsharp-build4.5-cil, libfsharp-compiler4.5-cil, libfsharp-compiler-interactive-settings4.5-cil, libfsharp-compiler-server-shared4.5-cil, and libfsharp-data-typeproviders4.5-cil. Are these extra packages necessary?

They have man pages (fsharpc.1, fsharpi.1 and fsharp.manpages which points to these two files) I'll need to figure out if these were generated somehow or if they were manually created. They also have fsharp-docs.{docs,install} files, despite fsharp-docs not being listed as a package in control.

Their .install files list the files included in each package. I haven't created these files yet (hence my packages being empty) but it's not clear how they determined what exactly should go in these files and whether I should just copy them verbatim. They also have .installcliframework files. I don't know what these are about.

They have a bunch of extra patches. Two of them (fsharp-GetFileNameWithoutExtension-type-inference.patch and fsharp-IsPathRooted-type-inference.patch) are equivalent to my 000-fix-broken-type-inference-in-build-script.patch patch, but the others I don't understand the need for. These are fix-bootstrap-src-targets-path.patch, fsharp-custom-prefix.patch, fsharp-msbuild-16-0.patch, fsharp-noinstall.patch, and fsharp-portable-pdb.patch.

Their rules file (the main build script for the package) does a bunch of stuff that mine (autogenerated by debmake) doesn't.

Their local-options includes "single-debian-patch". I dunno what this does.

Their watch file includes this:

opts="dversionmangle=s/\+dfsg//,filenamemangle=s_.*/(\d[\d\.]*)\.tar\.gz_fsharp-$1.tar.gz_" \ https://github.com/fsharp/fsharp/tags .*/(\d[\d\.]*)\.tar\.gz


If I want to understand all these changes I'll first need to populate my .install files so that my packages actually contain something, then get tests passing, then see what (if anything) fails, then try and understand what all these different config tweaks is doing.

+1049190 -208400

0 comment

5115 changed files

pr created time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 401b97f93b7fb9e6c3bc7a6a680ff8b94ff4445f

Test without using autopkgtest

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 9ea46dcd5a8bfe1730bcf37310b5c237c16ae301

Add test to github workflow

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 02eee00ff4e0c946ce9f678dfaa28570915d265e

Generate tarball in github workflow

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha a8680b8955586d84e2a4728938fa959c72828d8f

Generate tarball in github workflow

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 9e86a0edc8801b69de9984e8228e59aef8a2e9cd

Add more dependencies workflow file

view details

push time in 2 months

push eventcanndrew/fsharp-debian

Andrew Cann

commit sha 52ec7fc0a7c4e796a30a7d6d6486f2354dee2427

Add github CI workflow

view details

push time in 2 months

create barnchcanndrew/fsharp-debian

branch : 4.5-debianized

created branch time in 2 months

push eventcanndrew/fsharp-debian

push time in 2 months

create barnchcanndrew/fsharp-debian

branch : debian/4.5-0xamarin12

created branch time in 2 months

fork canndrew/fsharp-debian

manual mirror of https://salsa.debian.org/dotnet-team/fsharp

fork in 2 months

Pull request review commentjoemphilips/DotNetLightning

Core: simplify types wrt serialization

 type FeatureBit private (bitArray) =     interface IComparable with         member this.CompareTo(o) =             match o with-            | :? FeatureBit as fb -> this.CompareTo(fb)+            | :? FeatureBits as fb -> this.CompareTo fb             | _ -> -1

I get that the function should normally return -1 / 0 / 1 to indicate less / equal / greater, I'm just wondering if a FeatureBits should be considered less than any random obj you pass to this function or if it's an error to compare them at all.

knocte

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentjoemphilips/DotNetLightning

Core: simplify types wrt serialization

 type FeatureBit private (bitArray) =     interface IComparable with         member this.CompareTo(o) =             match o with-            | :? FeatureBit as fb -> this.CompareTo(fb)+            | :? FeatureBits as fb -> this.CompareTo fb             | _ -> -1

Is it normal to return -1 when two things can't be compared due to being incompatible types? Or should this be an exception?

knocte

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentjoemphilips/DotNetLightning

Fix chain hashes being serialized in reverse

 module SerializationTest =                     let mutable expected = hex.DecodeData("d977cb9b53d93a6ff64bb5f1e158b4094b66e798fb12911168a3ccdf80a83096340a6a95da0ae8d9f776528eecdbb747eb6b545495a4319ed5378e35b21e073a1735b6a427e80d5fe7cd90a2f4ee08dc9c27cda7c35a4172e5d85b12c49d4232537e98f9b1f3c5e6989a8b9644e90e8918127680dbd0d4043510840fc0f1e11a216c280b5395a2546e7e4b2663e04f811622f15a4f91e83aa2e92ba2a573c139142c54ae63072a1ec1ee7dc0c04bde5c847806172aa05c92c22ae8e308d1d2692b12cc195ce0a2d1bda6a88befa19fa07f51caa75ce83837f28965600b8aacab0855ffb0e741ec5f7c41421e9829a9d48611c8c831f71be5ea73e66594977ffd")
                     expected <- Array.append expected (hex.DecodeData("0000"))
                     if nonbitcoinChainHash then
-                        expected <- Array.append expected (hex.DecodeData("43497fd7f826957108f4a30fd9cec3aeba79972084e90ead01ea330900000000"))
+                        expected <- Array.append expected (hex.DecodeData("000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943"))

For instance, line 148 (the other branch of this if expression) uses that order.

canndrew

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentjoemphilips/DotNetLightning

Fix chain hashes being serialized in reverse

 module SerializationTest =                     let mutable expected = hex.DecodeData("d977cb9b53d93a6ff64bb5f1e158b4094b66e798fb12911168a3ccdf80a83096340a6a95da0ae8d9f776528eecdbb747eb6b545495a4319ed5378e35b21e073a1735b6a427e80d5fe7cd90a2f4ee08dc9c27cda7c35a4172e5d85b12c49d4232537e98f9b1f3c5e6989a8b9644e90e8918127680dbd0d4043510840fc0f1e11a216c280b5395a2546e7e4b2663e04f811622f15a4f91e83aa2e92ba2a573c139142c54ae63072a1ec1ee7dc0c04bde5c847806172aa05c92c22ae8e308d1d2692b12cc195ce0a2d1bda6a88befa19fa07f51caa75ce83837f28965600b8aacab0855ffb0e741ec5f7c41421e9829a9d48611c8c831f71be5ea73e66594977ffd")
                     expected <- Array.append expected (hex.DecodeData("0000"))
                     if nonbitcoinChainHash then
-                        expected <- Array.append expected (hex.DecodeData("43497fd7f826957108f4a30fd9cec3aeba79972084e90ead01ea330900000000"))
+                        expected <- Array.append expected (hex.DecodeData("000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943"))

Is there a reason not to write it in that order though? This is the order that's expected on the wire, and the order that uint256.Parse accepts.

canndrew

comment created time in 2 months

PullRequestReviewEvent

pull request commentjoemphilips/DotNetLightning

Fix chain hashes being serialized in reverse

I've pushed a commit to reverse the byte order of chain hashes in TLVs. @joemphilips: you mentioned QueryChannelRangeMsg as something needing to be fixed. Can you elaborate on that?

canndrew

comment created time in 2 months

push eventcanndrew/DotNetLightning

Andres G. Aragoneses

commit sha 84f5058835d02e34803920b2c93e6b944917113e

Normalize testing sdk dep to 16.7.0 to fix possible build glitch @canndrew was getting this build issue momentarily (and this patch fixes it): /home/shum/src/work/DotNetLightning/tests/DotNetLightning.Infrastructure.Tests/DotNetLightning.Infrastructure.Tests.fsproj : error NU1103: Unable to find a stable package Microsoft.TestPlatform.TestHost with version (>= 16.7.1) [/home/shum/src/work/DotNetLightning/DotNetLightning.sln] /home/shum/src/work/DotNetLightning/tests/DotNetLightning.Infrastructure.Tests/DotNetLightning.Infrastructure.Tests.fsproj : error NU1103: - Found 96 version(s) in nuget.org [ Nearest version: 16.8.0-preview-20200806-02 ] [/home/shum/src/work/DotNetLightning/DotNetLightning.sln]

view details

Joe Miyamoto

commit sha 0784169e718e8141e3cc171af21e9cd5c1acbf1d

Merge pull request #124 from knocte/fixPossibleBuildGlitch Normalize testing sdk dep to 16.7.0 to fix possible build glitch

view details

joe.miyamoto

commit sha 97c62d412fb493b47bcd13a22163231aef36e5cd

bump NBitcoin

view details

Andrew Cann

commit sha dde6a42b3737a1063c4a811a00a85523f44cd736

Fix chain hashes being serialized in reverse This is a fix for changes introduced in https://github.com/joemphilips/DotNetLightning/pull/118 which caused chain hashes to get serialized in reverse order. This allows DNL to open channels with lnd again.

view details

Andrew Cann

commit sha d328472ddeba90573079f495177ce7345aabe586

Fix TLV chain hash serialization In accordance with the previous commit, this also changes the serialization byte order of chain hashes in TLVs.

view details

push time in 2 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha cfb96aafaca669d323561b1e5ac9d44b7a28c2eb

Fix TLV chain hash serialization In accordance with the previous commit, this also changes the serialization byte order of chain hashes in TLVs.

view details

push time in 2 months

create barnchcanndrew/DotNetLightning

branch : nblockchain-master-with-record-types

created branch time in 2 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha a0ea6e16c1a49d0f1cb92a06452e85d4eeb7ec46

Fix chain hashes being serialized in reverse This is a fix for changes introduced in https://github.com/joemphilips/DotNetLightning/pull/118 which caused chain hashes to get serialized in reverse order.

view details

Andrew Cann

commit sha 1820f86034ff902c8ad891b4304b1afa5317ce39

Redefine single-variant discriminated union types A lot of types in DotNetLightning are defined as discriminated unions with a single constructor with the same name as the type. eg: type NodeId = | NodeId PubKey This commit redefines these types as: type NodeId(id: PubKey) = ... The main motivation for this is that having types and constructors with the same name breaks the json serialization library on older mono versions. It can also lead to confusing error messages. Besides that, it's also somewhat pointless to define a type as a discriminated union but then only give it one variant.

view details

Andrew Cann

commit sha afd7f3a91c3572441655e58f7131fa5de22697b7

Add JsonMarshalling module This commit adds the JsonMarshalling module which defines json serialization converters for a bunch of types exported by DotNetLightning. This allows the consumer of DotNetLightning to serialize the channel state to a wallet file.

view details

push time in 2 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 4a15a286b8e5e2fc53fb2ec92ddab44cf4c5edf6

Fix chain hashes being serialized in reverse This is a fix for changes introduced in https://github.com/joemphilips/DotNetLightning/pull/118 which caused chain hashes to get serialized in reverse order. This allows DNL to open channels with lnd again.

view details

push time in 2 months

pull request commentjoemphilips/DotNetLightning

Fix chain hashes being serialized in reverse

The commit message only has title.

Oops. Fixed.

canndrew

comment created time in 2 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 8d03891901a5c15859d4895c8456b4d0ecd48c25

Fix chain hashes being serialized in reverse This is a fix for changes introduced in #118 which caused chain hashes to get serialized in reverse order. This allows DNL to open channels with lnd again.

view details

push time in 2 months

PR opened joemphilips/DotNetLightning

Fix chain hashes being serialized in reverse

This is a fix for changes introduced in https://github.com/joemphilips/DotNetLightning/pull/118 which caused chain hashes to get serialized in reverse order.

This allows DNL to open channels with lnd again.

+22 -22

0 comment

2 changed files

pr created time in 2 months

Pull request review commentnblockchain/DotNetLightning

Implement json marshalling

 module Primitives =         static member (*) (a: FeeRatePerKw, b: uint32) =             (a.Value * b) |> FeeRatePerKw     /// Block Hash-    type BlockId = | BlockId of uint256 with-        member x.Value = let (BlockId v) = x in v+    [<Struct>]

The error in this case is: This type uses an invalid mix of the attributes 'NoEquality', 'ReferenceEquality', 'StructuralEquality', 'NoComparison' and 'StructuralComparison'

canndrew

comment created time in 2 months

Pull request review commentnblockchain/DotNetLightning

Implement json marshalling

 module Primitives =         static member (*) (a: FeeRatePerKw, b: uint32) =             (a.Value * b) |> FeeRatePerKw     /// Block Hash-    type BlockId = | BlockId of uint256 with-        member x.Value = let (BlockId v) = x in v+    [<Struct>]

Specifically, (since I just tried to build without Struct to see what the errors are), I get the error: Only record, union, exception and struct types may be augmented with the 'ReferenceEquality', 'StructuralEquality' and 'StructuralComparison' attributes.

This is the error I get if I, for instance, replace the [<Struct;StructuralComparison;StructuralEquality>] on TxId with just [<StructuralComparison;StructuralEquality>].

canndrew

comment created time in 2 months

Pull request review commentnblockchain/DotNetLightning

Implement json marshalling

 module Primitives =         static member (*) (a: FeeRatePerKw, b: uint32) =             (a.Value * b) |> FeeRatePerKw     /// Block Hash-    type BlockId = | BlockId of uint256 with-        member x.Value = let (BlockId v) = x in v+    [<Struct>]

To me "thin wrapper" means, at least in this case, that the outer layer of the value is allocated on the stack (so there aren't two pointer-indirections) and that the type forwards equality to the wrapped type.

I agree that [<StructuralComparison;...>] arguably expresses the intent for directly, however I had to add [<Struct;...>] to some of those types to get it to compile in the first place. I only added it to 3 more types when fixing the tests.

canndrew

comment created time in 2 months

Pull request review commentnblockchain/DotNetLightning

Implement json marshalling

 module Primitives =         static member (*) (a: FeeRatePerKw, b: uint32) =             (a.Value * b) |> FeeRatePerKw     /// Block Hash-    type BlockId = | BlockId of uint256 with-        member x.Value = let (BlockId v) = x in v+    [<Struct>]

Is there an advantage to that? My understanding is that [<Struct>] makes the type a thin wrapper around uint256, which seems to be what we want.

canndrew

comment created time in 2 months

more