02:13:32 <selsta> luigi1111w: please also merge https://github.com/monero-project/supercop/pull/4
05:05:06 <vtnerd> selsta: ... the macOS/darwin depends build on travis is finally compiling with the amd64 asm :)
07:57:09 <azunda> @rehrar https://www.youtube.com/watch?v=ILB3GmBAP7k  - still not working, when rewinding video switches to different. It's not because yt encoding.
07:57:37 <azunda> please fix it ;)
10:37:51 <moneromooo> .merge+ 6354
10:37:51 <xmr-pr> Added
12:47:48 <selsta> moneromooo: could you add all existing approved PRs to the merge bot that we want to include in the next HF?
12:48:08 <selsta> if we can do one round of merges it should be easier to have an overview of what is left to review
13:40:45 <Snipa> .merges
13:40:45 -xmr-pr- 6354 6500 6542 6546 6593
13:45:01 <Snipa> For 6500 - Is this still ready to be merged?  The last discussion seems to have trailed off without any finality.  6542, 6546, 6593 need some friendly eyeballs. :)
13:47:47 <moneromooo> I'd say yes. Someone can add some sed later to convert version variants.
17:33:27 <selsta> vtnerd: thanks for fixing, looks like we can include it in next release :)
17:34:33 <moneromooo> There's still the AS/ASM mismatch.
17:35:17 <moneromooo> Oh there's a comment sauing that'll be dropped. Good.
20:17:15 <vtnerd> it wasn't a mismatch, the gnu assembler is called "as"
20:19:12 <hyc> it's actually called gas. as was the original AT&T assembler for Unix
20:19:38 <moneromooo> Hmm. Sounds odd, but OK.
20:20:31 <moneromooo> I'm talking about the varaible, just to make it clear.
20:20:47 <iDunk> I was wondering about that too.
20:21:05 <moneromooo> It's cmake though, so it might made to annoy people.
20:21:28 <caralho> cmake is best make
20:21:43 <moneromooo> ^ someone who only knows cmake and libtool
20:21:45 <iDunk> With the latest changes, gcc (set by CMAKE_ASM_COMPILER) seems to be the asm compilere of choice.
20:24:58 <caralho> clang is only for the most 1337 hackers
20:34:16 <hyc> since clang was developed largely with Apple's assistance, I inherently dislike it
20:36:26 <hyc> gawd, every time I see one of our stack traces I want to puke
20:41:10 <moneromooo> Why ? They don't resolve addresses to symbols ?
20:41:23 <moneromooo> Or just because they exist ? :)
20:41:38 <hyc> those function signatures are atrocious
20:41:42 <hyc> and largely noise
20:41:44 <moneromooo> Oh you mean gdb, not the ones we log... right.
20:42:02 <hyc> such a stark difference between a C trace and a C++ trace
20:42:13 <hyc> the C trace shows the actual values of parameters
20:42:18 <hyc> it's actually useful
20:42:36 <hyc> the C++ trace shows you class inheritance, but no parameter values
20:42:48 <hyc> and our class heirarchy is just gross
20:42:51 <moneromooo> I think this can do too if you build with enough -g and little enough -O.
20:43:46 <hyc> e.g. the gdb.txt that was just attached to issue #6744
20:44:08 <hyc> thread 14 backtrace - pure noise
20:44:30 <hyc> thread 14 frame 14 - this is insane
20:45:27 <moneromooo> Ah, but you can use less -SR, the spam gets clipped and you see the good stuff :)
20:46:29 <hyc> hmm, that's a bit more readable, but the fact is that C++ is still pushing all this garbage around in the actual code
20:49:22 <hyc> how many pointers does it have to dereference to find one method being invoked
20:50:54 <caralho> less is more
20:53:36 <Inge-> Why is ther even a class hierarchy?
20:59:03 <hyc> That's an excellent question
22:44:49 <moneromooo> .merge+ 6329
22:44:50 <xmr-pr> Added
23:15:15 <moneromooo> .merge+ 6493
23:15:15 <xmr-pr> Added
23:20:53 <moneromooo> .merge+ 6600
23:20:53 <xmr-pr> Added
23:22:42 <moneromooo> .merge+ 6601
23:22:43 <xmr-pr> Added
23:37:06 <moneromooo> .merge+ 6618 6632 6634 6661 6662 6677 6679 6689 6691 6693 6698 6703 6712 6715 6716 6718 6720 6722 6727 6736
23:37:07 <xmr-pr> Added