00:01:17 <sarang> ping seddd
01:32:11 <derpy_bridge> <[keybase] unseddd>: pong sarang
01:33:20 <derpy_bridge> <[keybase] unseddd>: err... talking to me?
01:41:37 <sarang> Yes!
01:41:48 <sarang> I was testing your fuzz PR for CLSAG seddd, and having trouble compiling
01:41:54 <sarang> How did you go about it?
01:53:45 <derpy_bridge> <[keybase] unseddd>: pretty sure I just compiled the normal afl way. maybe you need to set the env vars: CC=afl-gcc CXX=afl-g++
01:54:19 <derpy_bridge> <[keybase] unseddd>: ^ may need to set during cmake step too
02:07:17 <derpy_bridge> <[keybase] unseddd>: so something like: export CC=afl-gcc CXX=afl-g++; cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_TEST=ON && make
02:07:50 <derpy_bridge> <[keybase] unseddd>: s/BUILD_TEST/BUILD_TESTS/
02:15:43 <derpy_bridge> <[keybase] unseddd>: side-question: is any work being done on reducing the size of translation units in monero? (compiling currently takes over 6GB of RAM at peak)
02:17:08 <moneromooo> Someone's looking at thinning boost includes, which take a lot of the TU bulk.
02:19:31 <derpy_bridge> <[keybase] unseddd>: awesome! thanks moneromooo
02:20:23 <derpy_bridge> <[keybase] unseddd>: boost is beastly, do not envy their work
02:25:29 <hyc> boost is just so fucking misguided. "zero-installation libs!"
02:25:41 <hyc> because they do literally everything in their header files
02:25:54 <hyc> boost, C++, whatever. it's all fucking stupid.
02:26:12 <hyc> header files are for interfaces, not implementations. period.
02:28:47 <derpy_bridge> <[keybase] unseddd>: header-only definitely seems to be a strong trend in the C++ world
02:30:17 <derpy_bridge> <[keybase] unseddd>: makes working with templates much simpler (but if you hate C++, imagine you hate templates too :)
02:30:27 <hyc> yes. because every developer has a supercomputer at their disposal for compiling, and edit/compile/test cycles are free
02:31:13 <hyc> and yes to your guess.
02:32:05 <derpy_bridge> <[keybase] unseddd>: lol right. trying to get better at C, but do most of my coding in rust these days. compile times there are improving nicely
02:33:56 <hyc> for several months it was impossible to do a native win32 compile of the Monero source tree, with debugging enabled
02:34:09 <hyc> needed more than 3GB of RAM for the compiler
02:34:36 <hyc> and produced more than 65536 symbol sections in the object file
02:34:53 <hyc> oh wait - the object file problem was there regardless of native or cross-compile
02:35:03 <hyc> and it was 32768 sections
02:35:21 <hyc> because every stupid header file needed its own symbol section
02:36:57 <derpy_bridge> <[keybase] unseddd>: do you think things will improve there with C++ modules?
02:37:33 <hyc> I would expect so, I mean, isolating into modules ought to relieve a lot of the burdens
02:38:02 <hyc> but I haven't really looked into it that much. who supports that already?
02:38:41 <hyc> reminds me now why modula-2 was such a popular language in my Atari ST days
02:42:26 <derpy_bridge> <[keybase] unseddd>: think it is planned for C++20, so only the latest compilers (looks like Clang11 and maybe VS Code)
02:42:57 <derpy_bridge> <[keybase] unseddd>: GCC is working on them: https://gcc.gnu.org/wiki/cxx-modules
02:43:45 <derpy_bridge> <[keybase] unseddd>: once modules have been supported a while, my guess would be header-only trend dies
02:44:03 <hyc> will take a while for it to be usable in those compilers
02:45:50 <derpy_bridge> <[keybase] unseddd>: definitely, maybe 2025 :p
02:46:14 <derpy_bridge> <[keybase] unseddd>: jk, compiler work is hard though
02:47:31 <hyc> lol
02:47:45 <hyc> I was a gcc maintainer from 1989-1997 or so
02:48:02 <hyc> something like that. m68k, MIPS, i860, sparc
02:48:08 <hyc> fun times
02:52:25 <derpy_bridge> <[keybase] unseddd>: oh awesome! look who i am talking to like i actually know shit, lol
02:52:25 <hyc> 5 years back then, heck, i860 would have been off the market before its support stabilized
02:55:04 <derpy_bridge> <[keybase] unseddd>: what do you think of RISC-V ISA?
02:55:15 <hyc> tbf, I never touched any of that frontend stuff. I worked on the machine-dependent stuff, going from the IR to asm.
02:55:35 <hyc> I think RISC-V is a disorganized shitshow
02:55:43 <hyc> too many optional instruction sets
02:57:37 <hyc> it reflects timid design-by-committee, making it impossible for programmers to rely on any particular features to exist
02:57:55 <derpy_bridge> <[keybase] unseddd>: lol. usually hear the modular design as a plus, you think it's borked?
02:58:30 <hyc> yes. just like AVX512 is a pointless feature today, because so few x86 chips support it
02:59:02 <hyc> go big or go home, all or nothing. 100% support, or better programmers will avoid it.
03:00:25 <hyc> optional instruction sets suck. same situation in ARM with their crypto instruction set
03:00:50 <hyc> Broadcom is a huge ARM licensee, makes all of the raspberry Pi CPUs, doesn't include crypto instructions
03:01:02 <hyc> makes their entire product line a waste, for us
03:01:21 <hyc> and really, a waste for everyone who wants to use a Pi on the WWW.
03:01:47 <derpy_bridge> <[keybase] unseddd>: yeah, think that was the motivation for their "core ISA", with module ISAs being for stuff like crypto accelerators
03:02:26 <derpy_bridge> <[keybase] unseddd>: could see the most used modules being incorporated into the main ISA (but that implies use)
03:03:09 <hyc> Motorola did it right in m68k. unsupported instructions could trap and still be emulated in s/w without too bad a perf penalty
03:03:59 <derpy_bridge> <[keybase] unseddd>: yeah, absolutely hate that broadcom chips are little black boxes inside so much hardware
03:04:08 <hyc> yeah
03:04:46 <hyc> anyway - if you can't rely on a particular instruction working on every CPU that runs your code, you generally end up not using it anywhere.
03:05:13 <hyc> just saves headaches, as a programmer
03:05:21 <derpy_bridge> <[keybase] unseddd>: not sure how risc-v handles unsupported instructions
03:07:04 <derpy_bridge> <[keybase] unseddd>: true, just so hyped over such a big open-hardware project. even if it flops, it is influencing a lot of other projects
03:08:38 <hyc> yeah, good point. maybe that's all it needs to do
11:55:29 <moneromooo> That really only matters if you want to write your own asm code, though, right ? Otherwise, your compiler knows what insns to emit.