00:01:15 <UkoeHB> is the function h2d() endian-aware or has monero always been broken on big-endian machines?
01:27:23 <hyc> I wouldn't be surprised if it's always been broken
01:27:40 <hyc> there aren't any big-endian systems in common use any more
02:24:16 <vtnerd> UkoeHB: the device api is a bit of a kludge from what I recall, it wasn't done properly but its kind of too late now
02:48:16 <UkoeHB> vtnerd: I see
03:06:13 <tusko> byte-order is always little-endian, whether or not words are big- or little-endian.
03:21:28 <UkoeHB> tusko: it matters when converting uints to and from bytes
17:50:15 <moneromoooo> sech1: there is an abort in monerod with the recent rx patch in a corner case which you might not care about:
17:51:19 <moneromoooo> if you mine fast (ie, fixed difficulty 1 in tests), every block added calls rx_set_main_seedhash_thread, which starts a thread and does not join.
17:51:38 <moneromoooo> The first one ends up initializing the rx stuff, which takes a long time.
17:52:02 <moneromoooo> In the meantime, all other calls to rx_set_main_seedhash_thread stop at the dataset write lock, and bunch up. Block addition does not wait, since no join.
17:52:11 <moneromoooo> It bombs when the process limit is reached.
17:53:14 <moneromoooo> It breaks my TF functional tests, which mines a lot, that's why I had to debug it. So it won't happen in the wild. Just when mining fast.
17:54:36 <sech1> "if (is_main(seedhash)) return;" should prevent this
17:54:55 <sech1> because rx_set_main_seedhash_thread sets main_seedhash asap
17:55:10 <moneromoooo> OK, I'll debug some more, possibly I broke something then.
17:55:15 <sech1> unless it's a different seedhash every time
17:56:14 <moneromoooo> With a different seed hash every time (like with merge mining and alternating merge/not-merged blocks), it'd be dog slow anyway, right ?
17:56:54 <sech1> yes
17:57:08 <moneromoooo> OK, so best I just drop this patch anyway. Thanks.
17:57:14 <sech1> it can happen when you set one seedhash, then quickly switch to another while the first one is initializing
17:57:19 <sech1> then it'll keep spawning threads
17:57:24 <sech1> and you need just 2 hashes
17:57:49 <moneromoooo> What's the speedup you got from this patch btw ?
17:58:34 <sech1> it enables fast mode for block verification
17:58:44 <sech1> 10-11 ms down to 1-2 ms to verify PoW
17:58:51 <moneromoooo> ty
19:00:11 -xmr-pr- tobtoht opened pull request #8714: depends: bump hidapi/libusb
19:00:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8714
19:00:11 -xmr-pr- tobtoht opened pull request #8713: depends: bump hidapi/libusb
19:00:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8713
20:52:33 <jeffro256[m]> moneromoooo Did you ever end up taking a look at https://github.com/moneromooo-monero/bitmonero/pull/7?
20:59:59 <moneromoooo> Not in detail but it's the next logical step, yes. Please go ahead.
21:26:32 <jeffro256[m]> Sorry, please go ahead do what?
21:28:19 <moneromoooo> PR this patch I mean (or finish it if not finished).
21:30:06 <jeffro256[m]> Ohh, I was thinking you could merge it against yours since you came up with the original idea for the spendable cache 
21:31:02 <jeffro256[m]> But I can also create a new PR against the monero repo if that's easier 
21:50:51 <moneromoooo> It certainly seems saner. If people start to PR other people's patches, it's going to be confusing fast ^_^
21:51:39 <moneromoooo> Though I did that a few times before. Usually when the author wasn't around anymore. But also when sarang and I were working on the same thing in parallel as the patches were intertwined.
21:54:33 <moneromoooo> Also loses signatures from the other author as soon as you rebase.