Previously if there was a chain of exceptions, we were only
sending the traceback for the final exception.
E.g.
try:
raise ExcOne("asdasd")
except ExcOne() as e:
raise ExcTwo("qweqwe") from e
^ we would lose all info about ExcOne, including potentially many lines of trace
The .pyc files would get created when a .py module is imported,
which is done during the build for some source files by pyinstaller
(when it analyses imports).
I considered setting PYTHONDONTWRITEBYTECODE=1 in build_tools_util.sh,
to apply to all builds, but am not sure how it would affect the Android build,
where we actually want .pyc files included in the apk.
related: https://github.com/spesmilo/electrum/issues/7390
```
20210706T091826.513398Z | ERROR | __main__ | daemon.run_gui errored
Traceback (most recent call last):
File "run_electrum", line 407, in handle_cmd
File "electrum\daemon.py", line 584, in run_gui
File "electrum\gui\qt\__init__.py", line 414, in main
File "electrum\gui\qt\__init__.py", line 291, in wrapper
File "electrum\gui\qt\__init__.py", line 316, in start_new_window
File "electrum\gui\qt\__init__.py", line 361, in _start_wizard_to_select_or_create_wallet
File "electrum\wallet_db.py", line 73, in __init__
File "electrum\wallet_db.py", line 106, in load_data
File "electrum\util.py", line 412, in <lambda>
File "electrum\util.py", line 408, in do_profile
File "electrum\wallet_db.py", line 175, in upgrade
File "electrum\wallet_db.py", line 540, in _convert_version_24
ValueError: too many values to unpack (expected 2)
```
Fixes: after adding a payment request, if the process was killed,
the payreq might get lost. In case of using the GUI, neither the
callee nor the caller called wallet.save_db().
Unclear where wallet.save_db() should be called...
Now each method tries to persist their changes by default,
but as an optimisation, the caller can pass write_to_disk=False
e.g. when calling multiple such methods and then call wallet.save_db() itself.
If we had partial writes, which would either rm the need for wallet.save_db()
or at least make it cheaper, this code might get simpler...
related: https://github.com/spesmilo/electrum/pull/6435
related: https://github.com/spesmilo/electrum/issues/4823
see code comment.
While the balance in the channels might shift before the sender tries to
pay the invoice, as we are not a forwarding node, that seems unlikely to matter.
It is the last Trampoline Forwarder that should be checked, not the
first one.
Consider route (of Trampolines only):
Alice-electrum -> T_ACINQ -> T_Hodlister -> Bob-electrum
Even if Bob has a transport open with ACINQ or even if Bob has a channel open with ACINQ,
Alice can safely use end-to-end trampoline for this route: ACINQ will not know who
the recipient is, so they will not try to do pay-to-open (and hold up the payment for minutes...).
related: https://github.com/ACINQ/lightning-kmp/pull/237
- better error handling: previously we stopped all attempts on any of
TRAMPOLINE_EXPIRY_TOO_SOON, UNKNOWN_NEXT_PEER, TEMPORARY_NODE_FAILURE.
Instead we should retry (but see code comments).
- previously payments failed if ALL of the following criteria applied:
- sender is paying via trampoline, but not via the ACINQ node (which is
special cased)
- receiver only has private channels and has put r_tags into invoice, along
with setting the trampoline feature bit in the invoice, however the receiver
is not connected to any trampoline forwarders directly
The sender would then assume that the private routing hints in the invoice
correspond to trampoline forwarders.
- also, previously if both the sender and the recipient used trampoline and
they shared a trampoline forwarder (that they were both connected to), the
private channels the recipient had (with nodes other than the shared TF)
would never be attempted.
This commit ports the work of EchterAgo and cculianu from Electron-Cash,
to implement a new toolchain to scan qr codes.
Previously, on Linux and Win, we have been using zbar to access the camera
and read qrcodes; and on macOS we used CalinsQRReader (an objective-C
project by cculianu).
The new toolchain added here can use QtMultimedia to access the camera,
and then feed that image into zbar. When used this way, zbar needs
fewer dependencies and is easier to compile, in particular it can be
compiled for macOS.
The new toolchain works on all three platforms, with some caveats
(see code comments in related commits) -- so we also keep the end-to-end
zbar toolchain; but at least we can drop CalinsQRReader.
The related changes in Electron-Cash are spread over 50+ commits (several PRs and direct
pushes to master), but see in particular:
https://github.com/Electron-Cash/Electron-Cash/pull/1376
some other interesting links:
b2b737001c163224cf1f3b31e0fcb1eda015908ehttps://github.com/Electron-Cash/Electron-Cash/pull/1545052aa06c23
- fix kivy wizard restore-from-seed
- qt seed dialog: disable "next share" if current share is invalid
- fix tests: file paths should not depend on $PWD (working dir)
was exiting with non-zero error code due to trying to copy directory
```
9cf9cdda331b565dd95b105d3fe987beefa113ac2c594d83783998017ad52d70 dist/electrum-4.1.4-16-g648fac709-portable.exe
020ceacb3a6fc5986d3ec271985c22c8646d2bb534536b8e2ab774924b21d58f dist/electrum-4.1.4-16-g648fac709-setup.exe
e65dbbe24fe01e8635d4def088667e65d4e9763e2ab74cbc1aec616b3f2834bc dist/electrum-4.1.4-16-g648fac709.exe
💬 INFO: Done.
cp: -r not specified; omitting directory '/home/user/wspace/electrum/contrib/build-wine/../../contrib/build-wine/fresh_clone/electrum/contrib/build-wine/dist/electrum'
```
