< bitcoin-git>
[bitcoin] S3RK opened pull request #21063: wallet, rpc: update listdescriptors response format (master...listdescriptors_format) https://github.com/bitcoin/bitcoin/pull/21063
< wumpus>
luke-jr: knots linux gitian build is running out of disk space here, i guess due to the added powerpc platforms
<@wumpus>
fanquake_: can you talk again now?
<@wumpus>
restored, that didn't make a difference
< fanquake_>
ping
<@wumpus>
hey !
< sipa>
hi
< fanquake>
success
<@wumpus>
PSA: if you find yourself unable to talk here or change your nick, make sure you're identified with nickserv
< bitcoin-git>
[bitcoin] fanquake opened pull request #21064: refactor: use std::shared_mutex & remove Boost Thread (master...use_std_shared_mutex) https://github.com/bitcoin/bitcoin/pull/21064
< wumpus>
so boost::preprocessor, boost::thread soon to be gone, boost::filesystem also on the horizon
< wumpus>
boost::date_time is only used in one function ParseISO8601DateTime but this ran into some issues last time as there's no good c++11 replacement #17245
< fanquake>
yes. there are two funcs in there that are trivial to replace, and probably should just be done. ParseISO8601DateTime is more difficult.
< wumpus>
boost::signals2 is used in quite a lot of places
< wumpus>
(most notably gui and other interfaces)
< wumpus>
boost::algorithm stuff is trivial to replace when we want to
< sipa>
and boost::multiindex is used by mempool and txrequest, and i don't think a replacement outside boost even exists for that
< wumpus>
that leaves boost::multi_index and boost::process, I think we'll be stuck with those for now
< sipa>
multi_index is header only, which is less of a pain i guess
< wumpus>
right
< wumpus>
multi_index is the only one that offers unique functionality
< wumpus>
we could look into factoring it out into a separate library some day
< wumpus>
but yes header-only is good in this case
< wumpus>
we might reach the point where we don't need to *compile* boost anymore
< fanquake>
also, the boost::system we compile in depends is already a dummy library
< fanquake>
It has one symbol, that is dummy_symbol() iirc
< wumpus>
hah why
< sipa>
literally, "dummy_symbol" ?
< fanquake>
it's basically been deprecated, think possibly even removed in a later Boost version
< fanquake>
sipa yea
< fanquake>
0000000000000000 T boost::system::dummy_exported_function()
< sipa>
loi
< wumpus>
so it's just there so that software doesn't need to change their -l.... linker flags
< aj>
sipa: let's replace boost::multi_index with sqlite!
< wumpus>
aj: i had the same cursed thought once but managed to keep it to myself :)
< wumpus>
i'm sure it would be possible but also a very large change to how things are done and it's unclear what the performance impact would be, also it makes sqlite a required dependency which i'm not sure is great
< wumpus>
and leveldb, the database we already have a strong dependency on, doesn't offer indexing functionality
< aj>
wumpus: might create encoding issues and stuff too, since each field needs to be sql'ed not just an entry in a struct
< wumpus>
from the Finnish translation: "Avaa %1 -debug-loki tämänhetkisestä data-hakemistosta. Tämä voi viedä muutaman sekunnin suurille lokitiedostoille." .... i don't think -debug-loki is quite right :)
< wumpus>
or maybe it is, it's not a translation of an option but of "Open the %1 debug log file from the current data directory. This can take a few seconds for large log files."
< setpill>
loki is Finnish for log
< wumpus>
setpill: right, i somehow didn't expect that, but makes sense then!
< Kiminuo>
2. One can probably use "#include <random>" to avoid using "#include random.h". That sounds doable but it sounds like too much maintenance burden for such primitive function.
< Kiminuo>
3. Or more simply, use rand() from <cstdlib> with some seed.
< Kiminuo>
4. Maybe some simple transformation based on current time (like hashing?) would suffice here.
< Kiminuo>
wumpus, ^ do you possibly have an opinion on this?
< real_or_random>
wumpus: oh the PR is simply not rebased on the newest master and so it does not have the .cirrus.yml...
< wumpus>
Kiminuo: util/getuniquepath.cpp :-)
< wumpus>
Kiminuo: imo, the best way to solve circular dependencies is to just factor it out to a new module
< wumpus>
Kiminuo: I definitely prefer sticking with our own random generator and not libc's
< wumpus>
real_or_random: whoops
< Kiminuo>
wumpus, yeah, util/getuniquepath.cpp can be done. But is it preferable?
< Kiminuo>
I mean from some grand scheme of things.
< real_or_random>
wumpus: I wonder if it's possible to configure Cirrus to run on the merge result instead of the PR branch. There's a "Config resolution strategy" setting but it's not documented
< bitcoin-git>
[bitcoin] fanquake opened pull request #21065: build: make macOS HOST in download-osx generic (master...correct_host_download_osx) https://github.com/bitcoin/bitcoin/pull/21065
< wumpus>
Kiminuo: to me it is
< Kiminuo>
wumpus, ok. Interestingly, I though you would not like this solution the most.. so I skipped it in my list. :-D
< wumpus>
I mean, small compilation units allow for the most specific dependency management (and speed up build time too)
< wumpus>
also the unique path code is only used in the tests
< wumpus>
thinking of it, you could even put it inside the test-specific utils under src/tests
< Kiminuo>
Yeah. When somebody needs it outside of tests, it can be refactored.
< luke-jr>
reminder: 38 minutes until ##Taproot-activation meeting
< bitcoin-git>
[bitcoin] practicalswift opened pull request #21068: Add GitHub Codespaces integration to allow for easy onboarding of future generations of contributors (master...github-codespaces) https://github.com/bitcoin/bitcoin/pull/21068
< miketwenty1>
Between Noon and 5 pm EST on March 30th (Tuesday).. There will be a remote speaking opportunity for a bitcoin core developer at a "Open Source 101" event. The idea would be someone who can explain about how the project is maintained, how people can contribute, why it's important, etc. Less about the bitcoin tech and more about the project and contribution to the project. I imagine history would also be a very interesting piece
< miketwenty1>
of this. If you're interested please email me mtidwell021@gmail.com and I'll give you more details.
< miketwenty1>
I imagine maybe achow101, sipa, jnewbery, or someone else, would know a good person for this?, or may be interested yourselves.
< luke-jr>
wumpus: I don't know of a single open source software package that bundles fonts…
< wumpus>
luke-jr: no idea, but I don't really see a problem with it, as there's fonts available with a free enough license
< wumpus>
this is similar to static linking imo -- be as independent as possible from what happens to be installed on the system
< luke-jr>
wumpus: except most of our static linking isn't detrimental to user experience
< luke-jr>
and fonts are fairly stable in compariosn
< wumpus>
assuming that fonts are installed corrently when they are not (or somehow not locatable) can also be detrimental to the user experience
< wumpus>
not sure about that, we've had quite some of these reported issues throughout the history of the project, especially with monospace fonts
< wumpus>
always had very ugly hacks to work around it, i think shipping a font is realtively clean
< wumpus>
for building from source i'm sure we could add an option to not embed them
< wumpus>
this is only about the distributed binaries
< sipa>
wumpus: you know we do have -chain=X, right? ;)
< wumpus>
sipa: we do?!?
< wumpus>
no, I was not aware that ever got merged
< wumpus>
seems absolutely superior to "radio button" options like -regtest -testnet
< wumpus>
though it's a bit weird to have both
< aj>
wumpus: geez, read the code sometime!
< wumpus>
aj: hehe
< aj>
wumpus: (i was going to quote the bit where it checks you only specify one of -chain, -signet etc, but now i can't find it, so apparently i should read the code sometime too)
< jonatack>
i could see why software clients might use -chain= but cli examples seem to always be -regtest, -testnet, -signet iirc
< jonatack>
seems handier for manual cli use
< jonatack>
(my interpretation of why having both can make sense)
< aj>
sipa: no, everyone should know all the code by heart, without having to grep, clearly
< wumpus>
yes it's clearly something way too many people are used to by now
< aj>
less typing when invoking "bitcoin-cli -testnet .." etc is a win
< sipa>
yeah, and -testnet -regtest also exist far longer thaj -chain
< wumpus>
aj: for the client it's absolutely a good thing
< wumpus>
I agree, it's better seen as '-testnet is a shorthand for -chain=test`
< wumpus>
though that's not how the argument parsing code works at the moment
< jonatack>
yes
< wumpus>
I don't think it even protects aginst multiple -chain=X like it does against -testnet -regtest ?
< sipa>
indeed
< aj>
should have the same protection as other options that aren't meant to be vectors?
< wumpus>
"src/bitcoin-cli -chain=test -chain=main getblockchaininfo" doesn't raise any error here, it's interpreted as just -chain=main
< wumpus>
which is fine, it's the same behavior as for other duplicated options, i just meant that the explicit protection that the shorthand network arguments have is different
< wumpus>
it's slightly inconsistent but also not big deal
< wumpus>
okayy, restarting the knots gitian linux build for the third time, hopefully i made the disk image large enough this time...
< wumpus>
to be honest i'm not actually sure why gitian bothers with a disk image at all for lxc, it's a container, it could just use a directory of the host, but anyhow
< sipa>
i suspect for historic reasons
< wumpus>
make the base image a .tar.gz and unzip it, voila, new target
< sipa>
lxc was added later, i think
< wumpus>
right i wouldn't be surprised if that's the entire explanation