-
hyc
my build hashes match
-
TrasherDK1
Arghhh... src/checkpoints/checkpoints.cpp:138:103: error: ‘boost::placeholders’ has not been declared
-
TrasherDK1
Last build on May 19, no problems ??
-
selsta
TrasherDK1: build release-v0.16 branch
-
selsta
-
TrasherDK
selsta: On branch release-v0.16
-
TrasherDK
Your branch is up to date with 'origin/release-v0.16'.
-
selsta
Which boost version?
-
TrasherDK
boost-1.59.0-x86_64
-
selsta
Can you update?
-
selsta
We added boost 1.73 support which looks like broke support with your version.
-
TrasherDK
boost 1.58 should be sufficient according to required dependencies.
-
selsta
Yes. The required dependencies have to be updated then.
-
TrasherDK
There was a patch to revert the braking change.
-
selsta
Which one?
-
TrasherDK
So, no more support for Slackware :(
-
hyc
why?
-
hyc
just install boost yourself
-
selsta
Maybe someone can PR a solution that works for boost 1.59 and 1.73 (without #if everywhere)
-
moneromooo
I think it's a simple thing to add: #if BOOST_VERSION < 0x17300 (or whatever) #define placeholders:: #endif
-
moneromooo
Or namespace placeholders = :: (I dunno the actual syntax, vtnerd_ must do)
-
moneromooo
(assuming _1 is not a define itself, it might)
-
selsta
TrasherDK: In the meantime you can revert f35ced6d7f00282091a9623bad573132f42a91b0
-
moneromooo
I use 1.70, which works like 1.58 in that regard.
-
moneromooo
I *think* I tried 1.72 at some point and it also did, though this was a beta version I believe.
-
TrasherDK
Reverting did the trick.
-
TrasherDK
./bin/monerod --version
-
TrasherDK
Monero 'Nitrogen Nebula' (v0.16.0.0-e4a20231b)
-
luigi1111
no re re tag? we are amazing
-
fluffypony
first time in history
-
moneromooo
-
flipchan
any monero based project in need for a developer?
-
ErCiccione[m]
flipchan: You mentioned in -lab that you are a python dev. Take a look at
github.com/monero-ecosystem
-
moneromooo
Oooh, that's the one I meant, not monero community :D
-
ErCiccione[m]
:P
-
flipchan
cool :)
-
selsta
anyone know how to do proper diff between v0.15.0.5 and v0.16.0.0? `git shortlog v0.15.0.5..v0.16.0.0` contains commits that we already had in v0.15.0.5 because we PRed them to both master and branch
-
selsta
kinda annoying when writing patch notes
-
moneromooo
git diff v0.15.0.5 v0.16.0.0
-
iDunk
selsta: git shortlog --cherry-pick --no-merges v0.15.0.5...v0.16.0.0
-
iDunk
See if that helps.
-
selsta
perfect
-
derpy_bridge
<[discord] DynaChip#0559>: What is it
-
moneromooo
This one either.
-
derpy_bridge
<[discord] DynaChip#0559>: Why do you all have cat pics lol
-
derpy_bridge
<[discord] Kayla#5718>: its robothash, irc doesnt have pics, please listen to moneromoo
-
derpy_bridge
<[discord] Kayla#5718>: #irc_monero-dev and #irc_monero-research-lab are not for spam
-
selsta
iDunk: I tried that previously and it did not work but now it does..
-
» selsta confused
-
iDunk
maybe ... vs ..
-
selsta
wow, yep that was the reason
-
selsta
I thought they are the same
-
derpy_bridge
<[discord] NightH4wk#5036>: Alr works
-
derpy_bridge
<[discord] DynaChip#0559>: Yep
-
derpy_bridge
<[discord] Kayla#5718>: @NightH4wk same to you, those channels are not for spam, which btw you can look at the right there is not bot so you dont get "xp" writing in the bridged channels
-
selsta
Kayla can you mute people if they write unrelated off topic stuff?
-
derpy_bridge
<[discord] Kayla#5718>: sure
-
derpy_bridge
<[discord] Kayla#5718>: done, sowry about that
-
selsta
np
-
selsta
moneromooo: do you think the rpc pay bug will require a point release?
-
moneromooo
I'd say no, but I'm not quite sure exactly why the wrong time.
-
vtnerd_
the syntax would be `#ifdef BOOST_VERSION <= WHATEVER \n using namespace boost::placeholders;\ n #endif`
-
vtnerd_
the namespace was added in boost 1.60
-
selsta
can you do a PR? not urgent
-
vtnerd_
should I have an old copy of boost somewhere to test against
-
vtnerd_
s/should/sure/
-
moneromooo
It's in headers though, so you'd need to do that a number of times (or else dump a using for whatever's after the include, which isn't very nice).
-
moneromooo
So I thought the namespace X = Y thing (and keep the existing patch) would be less intrusive maybe.
-
vtnerd_
theres no namespace for the old boost versions. we could define one and then alias global variables into that namespace for consistency so that it doesn't pollute the global namespace for newer boost versions
-
vtnerd_
-> namespace X = Y only works with boost 1.60+ or maybe you can do `namespace X = ::` which I dunno seems like a syntax error
-
moneromooo
So you can't do namespace placeholders = :: ?
-
moneromooo
nvm, I should learn to read.
-
moneromooo
Right, I tried, doesn't work, but works with an actual non root namespace. Oh well.
-
UkoeHB_
Im looking into how duplicate key images are handled for new blocks being added to the chain. The path seems to be `Blockchain::handle_block_to_main_chain() -> BlockchainDB::add_block() -> BlockchainDB::add_transaction() -> BlockchainLMDB::add_spent_key()`, where `add_spent_key()` tries to add key images to the db and throws an exception when it sees a duplicate. The exception gets caught by
-
UkoeHB_
`handle_block_to_main_chain()`, which then calls `tx_memory_pool::add_tx()` on all the block's transactions to clean up. Now, if for example a block has 2 transactions, and `add_block()` successfully calls `add_transaction()` for tx1, but then an exception is thrown for tx2, it would seem like the key images from tx1 would still be in the db when `handle...chain()` catches the exception. This means
-
UkoeHB_
`tx_memory_pool::add_tx(tx1)` should be cleaning up those tx1 key images. However, I can't find where it does that. The relevant function for cleaning up appears to be `BlockchainLMDB::remove_spent_key()`, but afaict that only gets called by `BlockchainDB::pop_block() <- BlockchainDB::remove_transaction()`. So I guess my question is if there is a leak where key images can get added to the db when there is no block
-
UkoeHB_
that owns them, or if I am misunderstanding `tx_memory_pool::add_tx()` and it is cleaning up properly after all, or if it is cleaned up somewhere else. Thanks :)
-
moneromooo
One thing you might (or might not) have missed is that everything that's written in a db txn is dumped in the bit bucket if that db txn is not committed.
-
UkoeHB_
My best guess what that might be is `BlockchainDB::add_block()` calls `BlockchainLMDB::add_block()`, and it also has the line `m_hardfork->add(blk, prev_height);`. That call, and that statement, won't be executed if any transaction throws a `KEY_IMAGE_EXISTS` exception. However, my concern is that `BlockchainLMDB::remove_spent_key()` calls `mdb_cursor_put()` which sounds like it's writing to the db.
-
UkoeHB_
add_spent_key*