00:25:10 <selsta> .merges
00:25:10 -xmr-pr- 7793 7873 7874 7912
00:31:00 <selsta> .merge+ 7959 7960 7978 7976 7958 7954
00:31:00 <xmr-pr> Added
05:45:33 <mj-xmr[m]> <hyc> "re:#7953 "There is no difference..." <- I believe he has a bias on storing the data externally, not on his SD card.
07:19:35 <mj-xmr[m]> A new report is out: memory usage for compilation. It matters for parallel compilation, because you might run into a situation, when too many heavy files are being compiled on your rig with limited RAM. This will lead to a large deal of swapping.
07:19:35 <mj-xmr[m]> Currently the average of 4 largest files is 2.56 GB per core.
07:19:36 <mj-xmr[m]> http://cryptog.hopto.org/monero/health/
07:19:44 <mj-xmr[m]> http://cryptog.hopto.org/monero/health/img/mem.png
07:19:52 <mj-xmr[m]> http://cryptog.hopto.org/monero/health/data/6b824c9ed/6b824c9ed-mem-usage-prod.txt
07:20:55 <mj-xmr[m]> The remedy would be splitting the large files into smaller chunks, which share similar dependencies.
08:23:38 <mj-xmr[m]> Another idea would be to perform the build in 2 steps - one for the basic libraries with `nproc`, and one for the high level targets with just -j2
08:25:42 <mj-xmr[m]> If you don't like moving code around that much.
08:45:29 <merope> Can confirm, I've had my laptop freeze during compilation by running out of memory after I went with -j `nproc`
08:46:22 <hyc> for most typical PCs you'd need to break it down to at most 1GB per core
08:46:55 <hyc> I tried this early on (back in 2016 or so) with little success
08:47:24 <hyc> too much crap was implemented in header files, boost, etc
08:48:03 <hyc> so even a minimal source file always had >1GB compilation overhead
10:15:26 <mj-xmr[m]> <hyc> "too much crap was implemented in..." <- Tell me about it...
10:42:03 <mj-xmr[m]> #6932 tries to tackle a part of the problem.
10:42:17 <mj-xmr[m]> (a manageable part that is)
13:39:12 <hyc> while it's been mostly just an inconvenience, it's a critical problem if you need to build debug binaries on windows
13:39:45 <hyc> all of the cruft of templates etc results in unique symbols for each instance, and it overflows the symbol table of a windows .obj file
13:39:52 <hyc> which maxes out at 32767 elements
13:40:17 <hyc> it was basically impossible to get a debug build for windows until I did some surgery on things back in 2016
13:40:44 <hyc> what you're working with now is better than it was then ;)
13:47:01 <moneromooo> Does it not with -mbigobj or similar name ? I think it was that limit.
14:44:14 <mj-xmr[m]> <hyc> "what you're working with now..." <- I can feel your pain.
15:36:58 <hyc> bigobj only raised the limit from 32767 to 65535. still wasn't enough
15:37:27 <hyc> (or something like that, I don't remember the exact details now)
18:08:23 <mj-xmr[m]> selsta: Are you planning to fix the CI for OSX, since you own a Mac, or should I try instead?
18:09:28 <selsta> I can't reproduce the issue locally unfortunately
18:11:22 <selsta> will try again today to see if I can find the difference between environments
18:53:03 <ullbeking> i've started working with my POWER9 workstation again.  is anybody else here working with P9?
19:35:26 <fluffypony> ullbeking: I've been playing with RISC-V; would be interested to see what Monero's efficiency is like on P9
19:38:58 <ullbeking> fluffypony: I have to regain access to my P9 workstation, should be soon.  I am interested in 
19:39:13 <ullbeking> seeing how to implement RandomX on P9
19:39:35 <ullbeking> I heard there was some issue that prevents JIT on P9 on Linux?
19:40:50 <fluffypony> hyc was playing with P9 a few years ago
19:40:52 <fluffypony> in 2018 iirc
19:41:42 <fluffypony> oh and tpearson actually managed to get a miner working I think
19:41:56 <fluffypony> https://github.com/nioroso-x3/xmr-stak
19:42:03 <fluffypony> https://github.com/nioroso-x3/xmr-stak/blob/master/xmrstak/backend/cpu/crypto/cryptonight_altivec.h
19:48:29 <mj-xmr[m]> <selsta> "I can't reproduce the issue..." <- I'll try to manipulate `depends` to get that openssl 3
19:49:23 <selsta> don't think it's depends related
19:51:21 <ullbeking> thank you fluffypony 
19:53:13 <ullbeking> i wanted to develop bitcoin in 2015 and i got a job at a very corporate financial organization doing enterprise software engineering hoping to pivot to bitcoing devlopment internally, but that never happened.  then other life things happened, i've just finished a six month contract, and now i'm jumping in the deep end of cryptocurrency development
19:53:22 <mj-xmr[m]> selsta: I mean I will use depends to simulate what goes on on CI, by forcing the download of openssl3
19:53:28 <ullbeking> i'm particularly interested in...
19:53:32 <mj-xmr[m]> *locally
19:53:51 <ullbeking> monero, bitcoin, and namecoin
19:54:34 <selsta> mj-xmr[m]: right but the issue is related to homebrew and how cmake finds openssl, you likely won't trigger that with cross compiling
19:55:39 <mj-xmr[m]> willl see. cmake is also used there.
19:56:29 <selsta> https://github.com/monero-project/monero/blob/master/CMakeLists.txt#L573
19:56:33 <selsta> I'm talking about this line
20:02:24 <mj-xmr[m]> Thanks. That's some clue.
20:07:27 <selsta> mj-xmr[m]: ok solved it, will PR a fix
20:14:01 <fluffypony> ullbeking: there's a surprising amount of overlap in ideology among Bitcoin, Monero, and Namecoin, so not surprised to hear those are your areas of interest :)
20:14:44 <ullbeking> fluffypony: really?!  that's so coincidental!
20:14:49 <ullbeking> why do you think this is?
20:15:25 <fluffypony> probably a better convo for #monero, let's move it there :)
20:15:33 <ullbeking> cool!
20:36:45 <selsta> https://github.com/monero-project/monero/issues/7982
20:37:00 <selsta> core tests are failing for this person, what kind of issue could this be? hardware issue, compiler, ... ?
20:37:22 <selsta> correction, not core tests but other tests
21:04:02 <ndorf> no idea but i can try to repro it on my manjaro pinebook over the weekend, if it's not resolved before then
22:10:30 <dMartian[m]> does the getmonero.org home page collect any metrics? such as page views?
22:11:11 <selsta> no client side tracking
22:11:45 <selsta> server side, don't know, use the Tor page if you worry about that
22:23:36 <fluffypony> dMartian[m]: nothing server side, we've tuned most logging down to a bare minimum if anything
23:19:37 <dartian[m]> thanks fluffypony 
23:19:37 <dartian[m]> I presume it's a given that tracker shortlinks to gemonero.org are antithetical in this community, so I wanted to see if there was any data recorded to compare against our marketing efforts