With the preceeding UTF-8 fix, I'd like to detect UTF-8 support. But
AFAICT Python doesn't have a standard way of doing version exposure.
So I added __version__, but now we need to make sure it matches. I
used the hackiest possible method.
[ Christian Decker fixed version to be sane, so previous comment no longer
applies! --RR ]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. We need to read in as a byte string, then decode into utf8 once we
have a marker. Otherwise we seem to mangle it horribly, and we
might have a bad utf8 string anyway.
2. We need to suppress the JSON \u escapes on output.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We should be able to pass UTF-8 strings to and from plugins without
python turning them into JSON-\u escapes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The v1.0.9 release of libsodium added
crypto_aead_chacha20poly1305_ietf_NPUBBYTES which we use; before that it was
...IETF_NPUBBYTES.
Since that release was in April 2016, it seems fair to simply check for
ancient versions and use the internal one if found. The alternative would be
to use the older names (which are still in the header), but given we've never
tested with such old versions, this seems safer.
Reported-by: Zoltán Gálli <@gallizoltan>
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Allow a function as well as (or instead of!) an sql statement. That
will let us do things like set per-channel values to the global
defaults, for example.
Since we remove the NULL termination, the final entry is ARRAY_SIZE()-1
not ARRAY_SIZE()-2.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
More efficient to measure the ARRAY_SIZE(), which is a runtime
constant. We move it into the unit test.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Below this code appears:
if (current != orig)
db_exec(__func__, db,
"INSERT INTO db_upgrades VALUES (%i, '%s');",
orig, version());
But since the loop pre-increments current, this is always true. I wondered
why there were so many duplicates in my db_upgrades table!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
*best is checked for null before the comparison against the uninitialized
variable ever happens, so this isn't a real issue.
Initialize it to zero so that we don't fail to compile on certain gcc versions.
plugins/pay.c: In function ‘add_shadow_route’:
plugins/pay.c:644:18: error: ‘sample’ may be used uninitialized in this function
if (!best || v > sample) {
~~^~~~~~~~
Signed-off-by: William Casarin <jb55@jb55.com>
We were tarring up the build dir, not the destination dir! We did this
for 0.6.3 and nobody noticed :(
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a separate commit, as it describes the results (as sha256sum)
of doing a test on the previous commit. Obviously these values will
have to updated after a rebase!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@cdecker reports that this gives warnings on exit; and we can't suppress
them by setting ASAN_OPTIONS within the binary itself, unfortunately.
So for 0.7, disable it by default. I'll work through the errors for 0.7.1.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
== is bash-only; for other shells this gives an error (meaning that you won't
get the sanity check):
./configure
Compiling ccan/tools/configurator/configurator...done
./configure: 148: [: gcc: unexpected operator
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And fix trivial typo in MAKING-RELEASES.md, and date retreival in
build-release.sh and repro-build.sh (real git tags start with v!)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I tried building zipfile on a fresh clone inside KVM, and got
1. Different times inside the zipfile, since zip seems to save *local* times.
2. A different zipfile order, since zip seems to use filesystem order.
Fix both of these. I don't know if LANG=C is necessary for git
ls-files, but it can't hurt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than using LightningJSONDecoder's implicit "field name and
value ends in msat, try converting to Millisatoshi", we do it to
parameters using type annotations.
If you had a parameter which was an array or dict itself, we don't
delve into that, but that's probably OK.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I originally converted input JSON naively into Millisatoshi, and the
result was a strange failure in Millisatoshi.__eq__.
It seems this is because inspect._empty.__eq__(Millisatoshi) raises
NotImplemented, and so it tries Millisatoshi.__eq__(inspect._empty)
which doesn't like it.
'is' is the correct test here, AFAICT, and doesn't suffer from these
problems.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Some JSON functions want a *class*, not just a hook, so provide one.
To make it clear that we want an encoding *class* and a decoding *object*,
rename the UnixDomainSocketRpc encode parameter to encode_cls.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we can't marshall an object into JSON, the exception causes a deadlock
and we don't get any results.
Instead of deadlocking, our failure now is:
lightning.lightning.RpcError: RPC call failed: method: echo, payload: {'msat': 17msat}, error: Error while processing echo: TypeError("Object of type 'Millisatoshi' is not JSON serializable",)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't, but we should, like we do for normal RPC. However, I chose
to use function annotations, rather than names-ending-in-'msat'
because it's more Pythony.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I tried annotating the plugin-millisatoshis.py plugin, and it failed like so:
plugin-millisatoshis.py Killing plugin: "getmanifest" result is not an object: {"jsonrpc": "2.0", "id": 1, "error": "Error while processing getmanifest: ValueError(\'Function has keyword-only parameters or annotations, use getfullargspec() API which can support them\',)"}'
So, let's do that!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For the moment it's only Ubuntu 18.04.1.
Complete documentation is in the final commit; you can test this using
the prior commit and comparing with my intermediate files and results
at:
https://ozlabs.org/~rusty/clightning-repro
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
New name is less confusing, and most people should be transitioning to
listpays rather than this anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is to future-proof against multi-part-payments: the low-level commands
will start returning multiple results once we have that, so prepare
transition plan now.
Closes: #2372
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the same deprecation, but one level up. For the moment, we
still support invoices with a `h` field (where description will be
necessary) but that will be removed once this option is removed.
Note that I just changed pylightning without backwards compatibility,
since the field was unlikely to be used, but we could do something
more complex here?
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This field was used by `pay` to hold the bolt11 description if the bolt11
string used `h` to hash the description (which nobody ever did). If the
`h` field wasn't present, it could contain anything, as it wasn't checked.
It's really useful to have a label for payments (eg. '1 Cuban'), but adding
yet-another option would be painful, so we simply rename 'description'
to 'label' except inside the db.
This means we need to do some tricky parameter parsing to handle array
and keyword JSON arguments, but only until we remove the old name.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Michael Schmoock
dlogemann
Rusty Russell
Conor Scott
Christian Decker
neil saitug
William Casarin
thestick613
nicolas.dorier
wailo