Rust syntax extension for generating error-handling boilerplate code.
Reliable p2p network connections in Rust with NAT traversal. One of the most needed libraries for any server-less / decentralised projects
Port of crust to futures/tokio
Emoji picking app for Linux
Rust library for handling C linked lists
Atomically reference-counted atomic pointers for Rust
abstract unix sockets support for net.createConnection
Agda is a dependently typed programming language / interactive theorem prover.
canndrew/beaker-plugin-safe-authenticator 0
SAFE Authenticator plugin for SAFE Browser
A binary encoder / decoder implementation in Rust.
PR closed joemphilips/DotNetLightning
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.
pr closed time in 5 hours
pull request commentjoemphilips/DotNetLightning
Fix closing tx output-reordering bug
Closing in favor of https://github.com/joemphilips/DotNetLightning/pull/133
comment created time in 5 hours
push eventcanndrew/DotNetLightning
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
push time in 6 hours
push eventcanndrew/DotNetLightning
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
push time in 6 hours
push eventcanndrew/DotNetLightning
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
push time in 6 hours
push eventcanndrew/DotNetLightning
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
push time in 6 hours
push eventcanndrew/DotNetLightning
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
push time in 7 hours
push eventcanndrew/DotNetLightning
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
push time in 7 hours
PR opened nblockchain/DotNetLightning.Kiss
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.
pr created time in 7 hours
create barnchcanndrew/DotNetLightning
branch : nblockchain-master-with-closing-signed-fix
created branch time in 7 hours
PR opened joemphilips/DotNetLightning
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.
pr created time in 7 hours
push eventcanndrew/DotNetLightning
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.
push time in 7 hours
create barnchcanndrew/DotNetLightning
branch : upstream-master-closing-tx-output-ordering-fix
created branch time in 7 hours
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.
comment created time in a day
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.
comment created time in a day
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...
comment created time in 4 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.
comment created time in 4 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.
comment created time in 4 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 4 days
create barnchcanndrew/DotNetLightning
branch : nblockchain-key-types-refactor
created branch time in 13 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 13 days
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 15 days
pull request commentidris-lang/Idris2
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
comment created time in a month
create barnchcanndrew/fsharp-debian
branch : 4.1.0.0-debianized-broken
created branch time in a month
create barnchcanndrew/fsharp-debian
branch : 4.0.1.22-debianized-broken
created branch time in a month
push eventcanndrew/fsharp-debian
commit sha db5c20860bfc5c8cac1674bf1983234cd2d2fbca
Foreach optimization
commit sha b4a6cc1d320fe2ffd3ac08ad7f931e7f4d5893c1
Revert Seq changes
commit sha 1b8b26a6aa384a41da0e198c1e9c7a121d276434
Test fixes
commit sha 1915f82eb629e85acf7de42e8313ecd3a2554c7b
Update .net version to 4.6
commit sha d360287ae44cf9029f2bf50783add3827c02b3f7
Added new language service/project/package based on Roslyn
commit sha 41c999fe2a2d416d3ac2c47bb6a1152aa19660bb
Merge branch 'master' of https://github.com/Microsoft/visualfsharp into newlanguageservice
commit sha 21571caa45edd5494455565022ca285a4cdd99c4
Resolve conflicts due to projects refactoring
commit sha 497c854cc294495276774b3ad1560b2967020eac
Added switch between old/new language services
commit sha dbd4a83656d3d82b6ae09c14da5cdf26222f4dc7
Added Roslyn myget packages to build
commit sha 90462270f16ac5af8ce7b7293d9040667094614f
Revert "Update .net version to 4.6" This reverts commit 1915f82eb629e85acf7de42e8313ecd3a2554c7b.
commit sha 41eb8a858076f250820826fb5ee51a394dd728bd
Updated just the vsintegration projects to .net 4.6
commit sha 44ecd52e6535dd169a301b2b5cf777ae9c01c3f5
Replaced old language service with roslyn based service
commit sha b2db3ebf4d5712c5464fd809a549f411d3636538
Merge branch 'master' of https://github.com/Microsoft/visualfsharp into newlanguageservice
commit sha 5ef9c7353256d722a835b550c3e23e96b51ff321
Merge branch 'master' of https://github.com/otawfik-ms/visualfsharp into newlanguageservice
commit sha 0172d9cdc4d632d30ed6f14f10a738b3279be3b8
Fix test breaks
commit sha 357ba39b8261f4fc23438d9c2470d1457b7bf847
Merge branch 'master' of https://github.com/Microsoft/visualfsharp into newlanguageservice
commit sha 08be5d62a4e639b236d9bd685ee3ebf76e9639a6
Update Roslyn packages to 1.2.0-beta1-20160218-02
commit sha b3724dbfa9e2f7f4c7980dc08f124b7fc4b6759b
Disabling editor factories until fully implemented
commit sha c6cebf849e1ee01c7b98ac7a800fe5d7a93f6382
Addressing code review comments
commit sha 3a36f79dc150ffa61a037a67f877b593d4a5265c
Merge pull request #974 from otawfik-ms/newlanguageservice Replaced old language service with Roslyn-based one
push time in a month
pull request commentjoemphilips/DotNetLightning
remove useless Client and its tests
@knocte: :+1: We don't use the Client stuff at all.
comment created time in a month
push eventcanndrew/fsharp-debian
commit sha bd69d0023d79af1e003c005885fb0e414aa18f61
Fix path to fssrgen.exe in install file
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.
push time in a month
push eventcanndrew/fsharp-debian
commit sha f8a2999a3c563fc7403b8f08a644c7792144a5ae
Make executables in bootstrap executable
push time in a month
push eventcanndrew/fsharp-debian
commit sha 3a4af35cbe665645bfe8aec90143da584544b87e
Fix check for xbuild in Microsoft.FSharp.Targets
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha 469e215652f368c9d3004b71ae1f5261cf49bd30
Add System.Reflection.Metadata.1.4.1-beta-24227-04 to bootstrap
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha 74dab837bf97b97ea9d3ad0a6ade322917c2f39f
Add System.Collections.Immutable.1.2.0 to bootstrap
commit sha e831017056bbe9d90c8dbdf3de242aaff83816b2
Change path to System.Collections.Immutable to point into bootstrap dir
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha 1367a2592a0d2cf42c2efe8baed84e4d2e50a98c
Add entire contents of FSharp.Compiler.Tools.4.0.0.4 to bootstrap
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha 1b00bdf87fded1205c6e1026e4b4c8ab638f5f8d
Fix path to SRGen to point to bootstrap
commit sha 36faa6e462f2e849582bd201dd042010040cc4ae
Add fssrgen.exe to bootstrap
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha b3013f821c96d61ff64e017a90c61f160a55e8ca
Add with-bootstrap flag to configure
commit sha 8c6d65574221ad651ff3ae96f745e1ff4243c31b
Add contents of FSharp.Compiler.Tools.4.0.0.1 to bootstrap
commit sha f9e41584e9a2ff4463cb0aea35b488b34e953775
Point LkgPath at the bootstrap directory
commit sha 4d1287efc92fdf903de2c5d732ffe1dd095ba37d
Fix path to SRGen to point to bootstrap
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha e27e17f7e5cf698ef43c6930f11ef930b22b6fa2
make xbuild verbose
commit sha a79d1f2ea632dd10280a89d1c98a42c3f24eedd4
Add debugging to FSharpSource.targets
commit sha 6339270f8ba4a8e5002a09e564c78349b9e6726b
Fix typo in FSharpSource.targets
commit sha f02404ad66f704ff7c7739033497099257f363ad
Try to fix path for FSharpTargetsPath
commit sha e457c824b33c94fa56c63c93666f9f91abb19bee
Apply debian/patches to make experimentation easier
commit sha 6b14156a63cf787f5fcba399b4bfd750ab2856af
Ignore missing fsi.exe
commit sha 9532a7830cc4fb3e2d53f416741302f5e261cde2
uncomment import of FSharpTargetsPath
commit sha 70246808269e23f8f07024821202262fae657f3e
Try to fix path to fslex.exe and fsyacc.exe
commit sha f9d911b11a63b01b961881c4ede1510d83b86e0f
Change FSharpTargetsPath everywhere its set under bootstrap
commit sha 45b2b404164c20826270e0458ee55c0ba23af373
try to add debugging to FSharp.Core
commit sha e30922d341964122f56dd7e7cc55378697fe7f52
Set FSharpTargetsPath in FSharp.Core.fsproj
commit sha e58d8c3cfc0ff36e405555263c7dab1ee85ac2f4
set FSharpTargetsPath in FSharpSource.Settings.targets too
commit sha 0cadc6a8edab2dd253f5946d7e46422d56d32e61
Hard code path to avoid $FSharpTargetsPath
commit sha 34f7c73125dbb620cdc84e2411dd64d176e7e344
And also don't check the other locations
commit sha baee5e87ead6f116d59854f29654f5af7efdfd0e
Ignore missing fsc.exe
commit sha f02a4cb529385ae58d48d2438fa706287ca777ba
Don't try to copy stuff from packages
commit sha 7eb80380e117c95d433212182279ebcf33e45b09
Unconditionally use xbuild in Microsoft.FSharp.Targets
push time in 2 months
push eventcanndrew/fsharp-debian
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
commit sha b4087aea1411ca728b817a7b96bde815d1b51b84
build script
commit sha 60f094603c15657174aac8f12ac1a6f065710134
use ClrRoot of current RuntimeEnvironment instead of hardcoded 4.0 on mono
commit sha d603ceee1d755170dd932d4f9d9cfbb2afd012ea
Merge pull request #121 from matthid/useRuntimeClrRoot use ClrRoot of current RuntimeEnvironment instead of hardcoded 4.0 on mono
commit sha c5d650d50d39da5084422cd6a5ddb28509abb1b8
Merge pull request #120 from Heather/heather nothing but build script
commit sha 56fc62be2746fd5dca5fe418af9b490475e0f8a2
Attempt to fix #119. Fixes the example on cold start "fsi --exec $file" on Mono
commit sha 5990786db149ab67a928e19cd5a4ddf9adbc69cd
Updated readme, added in configuration for MonoTouch target.
commit sha 8efa1c57cb99b87c61ac3db8f41bb407b564a0cd
Merge pull request #126 from intellifactory/master Fix fsharp/fsharp:#119
commit sha 95e24d8ac52cd905efb37a0b8dfc16f224733a56
Merge pull request #128 from 7sharp9/patch-1 Updated readme, added in configuration for MonoTouch target.
commit sha 5f3a23c145919dee2d59550c027dc989f3c9e051
Added MonoTouch assemblies to the dependencies folder
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
commit sha f3c8ea8bf4831ce6dc30581558fa4a45a078cd55
Merge pull request #129 from 7sharp9/master Added a new 'monotouch' target to the build process
commit sha 3edb6b313099e62a102ddbeb96d6b3d2d27a47bf
Fix for #131 - SimpleSourceCodeServices.fs will not generate dynamic assemblies for non silverlight builds
commit sha f661d8c6e048994d5acaa7061b83b8bfee6c0779
Merge pull request #132 from 7sharp9/master Fix for #131 - SimpleSourceCodeServices.fs will not generate dynamic assemblies for non silverlight builds
Christopher James Halse Rogers
commit sha 03579255a66942efb89d8b43746e6b5496ddb908
Imported Upstream version 3.0.27
Christopher James Halse Rogers
commit sha 81d2e30464f37e167774d2d48cbbf00b243b7bb5
Merge tag 'upstream/3.0.27' Upstream version 3.0.27
Christopher James Halse Rogers
commit sha 577f7b762b59f5b760162904d8dfb2b1accdaee2
Add README.source, documenting the +dfsg
Christopher James Halse Rogers
commit sha 5c4564a63067ef18922c14fb7b42b2fca6a62ecb
Add Vcs-Git headers
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
Christopher James Halse Rogers
commit sha 5227e102e1b5fe97224e01b19379aa12f062b69a
Don't build 2.0- and 3.5-profile F# libraries
push time in 2 months
PR opened nblockchain/fsharp-debian
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 [email protected]". Mine currently has "Christopher James Halse Rogers [email protected]" 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.
pr created time in 2 months
push eventcanndrew/fsharp-debian
commit sha 401b97f93b7fb9e6c3bc7a6a680ff8b94ff4445f
Test without using autopkgtest
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha 9ea46dcd5a8bfe1730bcf37310b5c237c16ae301
Add test to github workflow
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha 02eee00ff4e0c946ce9f678dfaa28570915d265e
Generate tarball in github workflow
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha a8680b8955586d84e2a4728938fa959c72828d8f
Generate tarball in github workflow
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha 9e86a0edc8801b69de9984e8228e59aef8a2e9cd
Add more dependencies workflow file
push time in 2 months
push eventcanndrew/fsharp-debian
commit sha 52ec7fc0a7c4e796a30a7d6d6486f2354dee2427
Add github CI workflow
push time in 2 months
push eventcanndrew/fsharp-debian
push time in 2 months
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.
comment created time 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
Is it normal to return -1 when two things can't be compared due to being incompatible types? Or should this be an exception?
comment created time in 2 months
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.
comment created time in 2 months
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.
comment created time in 2 months
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?
comment created time in 2 months
push eventcanndrew/DotNetLightning
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]
commit sha 0784169e718e8141e3cc171af21e9cd5c1acbf1d
Merge pull request #124 from knocte/fixPossibleBuildGlitch Normalize testing sdk dep to 16.7.0 to fix possible build glitch
commit sha 97c62d412fb493b47bcd13a22163231aef36e5cd
bump NBitcoin
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.
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.
push time in 2 months
push eventcanndrew/DotNetLightning
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.
push time in 2 months
create barnchcanndrew/DotNetLightning
branch : nblockchain-master-with-json-marshalling-methodise-commitments
created branch time in 2 months
create barnchcanndrew/DotNetLightning
branch : nblockchain-master-with-record-types
created branch time in 2 months
push eventcanndrew/DotNetLightning
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.
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.
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.
push time in 2 months
push eventcanndrew/DotNetLightning
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.
push time in 2 months
pull request commentjoemphilips/DotNetLightning
Fix chain hashes being serialized in reverse
The commit message only has title.
Oops. Fixed.
comment created time in 2 months
push eventcanndrew/DotNetLightning
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.
push time in 2 months
PR opened joemphilips/DotNetLightning
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.
pr created time in 2 months
create barnchcanndrew/DotNetLightning
branch : upstream-master-with-chain-hash-reversal
created branch time in 2 months
Pull request review commentnblockchain/DotNetLightning
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'
comment created time in 2 months
Pull request review commentnblockchain/DotNetLightning
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>].
comment created time in 2 months
Pull request review commentnblockchain/DotNetLightning
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.
comment created time in 2 months
Pull request review commentnblockchain/DotNetLightning
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.
comment created time in 2 months
push eventcanndrew/DotNetLightning
commit sha 537f6e3bd2201fe281a4974987243eca87afba23
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.
push time in 2 months
push eventcanndrew/DotNetLightning
commit sha 6234c40d133d2cc8cf139f705ef29ec211fb25af
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.
push time in 2 months