-
DangrOnTheRangr
selsta: just double-checking that you had seen I had squashed the commits on 7823
-
selsta
DangrOnTheRangr: approved it
-
Space[m]
mj-xmr: I compiled monero on Master
-
mj-xmr[m]
Great. Thanks. Were there any changes needed?
-
selsta
anything remaining that isn't merged yet that should be included in the next release?
-
Space[m]
mj-xmr[m]: All dependencies remain the same, only instead of release - master
-
Space[m]
In both cases, I used the patch for boost 1.76
-
mj-xmr[m]
selsta: IDK, but maybe these 3 UB protections?
-
mj-xmr[m]
(searchable by "UB"
-
Space[m]
Space[m]: but used boost 1.77
-
mj-xmr[m]
7870 7868 7861 and 7829
-
mj-xmr[m]
Space: I'm not sure now what happened. Did everything (release & master) work without changes with boost 1.76 but not with 1.77?
-
Space[m]
-
Space[m]
> <@mj-xmr:matrix.org> Space: I'm not sure now what happened. Did everything (release & master) work without changes with boost 1.76 but not with 1.77?... (full message at
libera.ems.host/_matrix/media/r0/do…4a59f71e8ad5056efabc8418111df496556)
-
mj-xmr[m]
ok. Now it's clear for me. Thanks.
-
mj-xmr[m]
I will build boost 1.77 rn and try to reproduce.
-
mj-xmr[m]
If I can't, I will get back to you.
-
Space[m]
-
mj-xmr[m]
Thanks. This can be useful.
-
Space[m]
> <@mj-xmr:matrix.org> If I can't, I will get back to you.... (full message at
libera.ems.host/_matrix/media/r0/do…8bcce45c814b9ceb054e681223649a5d9a8)
-
Space[m]
> <@bigmenpixel:matrix.org> note: boost is compiled like this... (full message at
libera.ems.host/_matrix/media/r0/do…2bf9ff267fcfba0a7883d0d567d33c8cdbc)
-
selsta
mj-xmr[m]: someone has to review them, I'm not really familiar with it
-
mj-xmr[m]
OK, then let's pass them for now.
-
mj-xmr[m]
Space: I can reproduce the Release with Boost 1.77
-
mj-xmr[m]
I will try with 1.76 as well just to be sure. But it seems to me, that Boost is actively cutting on the size of their headers. Which is good.
-
Space[m]
<mj-xmr[m]> "Space: I can reproduce the Relea" <- without patch?
-
mj-xmr[m]
without patch
-
mj-xmr[m]
But the patch seems only slightly related to me, looking at the error message.
-
Space[m]
mj-xmr[m]: Hmm ... even archlinux uses a patch in its package
-
mj-xmr[m]
It may fix this but only indirectly.
-
mj-xmr[m]
And this is not the way we want to have it in long term.
-
mj-xmr[m]
Since such "solutions" will cease to work when boost cuts yet another header (as they should)
-
mj-xmr[m]
I'm about to create the "proper" patch for this particular situation and we'll decide how to proceed.
-
Space[m]
mj-xmr[m]: ok
-
Space[m]
Let the flatpak package monero-gui 0.17.2.2 lie down as a binary for now, without building from sources
-
selsta
mj-xmr[m]: can you post the error message with Boost 1.77?
-
mj-xmr[m]
-
mj-xmr[m]
`/run/build/monero/src/common/i18n.cpp:74:8: error: ‘transform’ is not a member of ‘std’`
-
selsta
that's boost?
-
mj-xmr[m]
No. It's fishy.
-
mj-xmr[m]
It appears that your patch fixed it indirectly.
-
mj-xmr[m]
but since boost 1.77, that included header dropped <algorithm> from its included headers.
-
selsta
ok I see
-
mj-xmr[m]
and thus it was missing down there in i18n.cpp
-
selsta
otherwise no compilation issues?
-
Space[m]
What version of boost is the github release compiled with?
-
selsta
1.64 or so
-
mj-xmr[m]
selsta: just finishing compilation
-
selsta
do you want to PR it?
-
mj-xmr[m]
selsta: all green. Shall I PR against
-
mj-xmr[m]
took it from my brain
-
selsta
both master and release
-
mj-xmr[m]
Master already has the header included.
-
mj-xmr[m]
7902
-
mj-xmr[m]
bbl
-
selsta
mj-xmr[m]: can you change the position of the include? unless it was intentional
-
mj-xmr[m]
selsta: it was intentional. Basic headers always go below own headers.
-
mj-xmr[m]
-
selsta
but we don't do it like that currently
-
selsta
hmm ok, whatever
-
mj-xmr[m]
Somebody has to start :)
-
hyc
that is nonsense
-
hyc
most local headers depend on standard headers. e.g. NULL is defined in <stdio.h>
-
hyc
whoever wrote that doesn't know wtf they're talking about
-
hyc
basic headers should always come first. local headers last.
-
hyc
complex systems are built from the ground up. always define the basics first and then build on top of them. not the other way around.
-
hyc
stackoverflow idiocy...
-
UkoeHB
Can you give a practical reason to include basic first? I think including local first makes a lot of sense for catching missing header dependencies.
-
hyc
again, it's just common sense. I can't use a local header that uses FILE* without including <stdio.h. first.
-
UkoeHB
Common sense? Lmao that is not a practical reason.
-
hyc
you have to include the lowest level deinitions before you can build higher level abstractions on top of them
-
UkoeHB
Yes, headers should include their own lowest level definitions.
-
hyc
no, that's fucking stupid.
-
UkoeHB
That just an opinion, give me a practical reason.
-
hyc
that means every high level local header file includes the entire world that it depends on
-
hyc
even with annotations to only include_once it still wastes time opening and ignoring all of the header files redundantly
-
hyc
include what you need before you need it, and only do it once.
-
hyc
I swear, it's as if every C++ practice is designed to waste developer and user time
-
UkoeHB
Isn't tracking down all the dependencies of all the headers you include, wasting time?
-
hyc
you only do it once.
-
hyc
and from then on compiles are fast.
-
hyc
edit/compile/run cycle time matters.
-
mj-xmr[m]
<UkoeHB> "Can you give a practical..." <- exactly
-
mj-xmr[m]
UkoeHB: Or waiting for compilation to finish.
-
hyc
you haven't given a valid reason to change to the opposite order.
-
hyc
in absence of a reason to change, don't change.
-
mj-xmr[m]
He did.
-
mj-xmr[m]
It catches the missing dependencies.
-
hyc
so you're going to submit PRs now to invert the order of all includes in all source files?
-
mj-xmr[m]
before you distribute your library.
-
hyc
fixing what ain't broke...
-
mj-xmr[m]
They are already inverted.
-
mj-xmr[m]
in the wrong way
-
UkoeHB
lol
-
hyc
that's just BS
-
hyc
you want to define the roof of the house before the walls, floors, or foundation
-
hyc
restating the example: you can't use types from <stdint> in your own definitions before you include <stdint.h>
-
hyc
the low level headers must always come first
-
UkoeHB
Bludgeoning us with insults and empty abstractions is rude and unhelpful. Please keep it technical.
-
hyc
\I've already given you technical examples which you ignore
-
hyc
........................
-
UkoeHB
Did I ignore them? Now you are mind-reading also, which is equally as rude and unhelpful.
-
hyc
^ cat on kbd
-
hyc
yes, you've ignored them. you certainly have not acknowledged them before continuing your argument. *That* is rude and unhelpful.
-
UkoeHB
I continued my argument?
-
UkoeHB
Where?
-
UkoeHB
Here I am thinking about what you said while you spout off.
-
UkoeHB
ffs
-
BusyBoredom[m]
I like to use the google style guide to end these disputes. Here's their entry for include order:
google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes
-
moneromoooo
...
-
moneromoooo
using a monero block hash as random seed would seem fairer
-
moneromoooo
(As long as you're going to solve disagreements with an arbitrary choice)
-
BusyBoredom[m]
Alright, just figured I'd share what worked on my projects.
-
hyc
note the Exception on that section
-
hyc
if you blindly throw headers in in arbitrary order you'll usually get a broken result
-
hyc
because conditionals that depend on other definitions are a frequent occurrence
-
hyc
the one rule that always works, with no exceptions, is always go from lowest level first to highest level last.
-
selsta
.merge+ 7902
-
xmr-pr
Added
-
Space[m]
is this fixed in master?
-
Space[m]
-
selsta
it's not a known problem
-
wfaressuissia
"is this fixed in master?" how to reproduce it ?
-
wfaressuissia
master + arbitrary build environment == undefined behavior
-
wfaressuissia
* any branch + ...
-
selsta
.merges
-
xmr-pr
7828 7902
-
selsta
luigi1111w: once you merge ^ you can tag v0.17.2.3
-
selsta
.merge+ 7888
-
xmr-pr
Added
-
utxobr[m]
<selsta> "luigi1111w: once you merge ^ you..." <- aka "folks, get ready for gitian sigs party"?
-
selsta
tomorrow most likely, yes :P
-
utxobr[m]
sweeet
-
Mochi101
Is there an IRC channel specific to the COMIT tools?
-
selsta
afaik they are matrix only but you can ask in #monero-swap maybe
-
Mochi101
ok
-
sethsimmons
<Mochi101> "Is there an IRC channel specific..." <- Matrix is #comit-monero:matrix.org, not sure if bridges.
-
Mochi101
thanks sethsimmons, doesn't bridge though...
-
Mochi101
I set up the ASB... had some input on it... was doing the CLI as well and had some difficulties
-
sethsimmons
Let's chat in #monero:monero.social
-
sethsimmons
Nvm don't see you in there.
-
sethsimmons
Feel free to DM and I'll try to answer Qs, assuming you've read my guide and the official docs.
-
sethsimmons
Off topic for this channel, though.
-
luigi1111w
K