02:44:34 <luigi1111w> hyc sech1 can you try leaving and rejoining
06:15:44 <sech1> luigi1111w done
06:17:54 <luigi1111w> got it now
06:57:25 <sech1> I've got p2pool running on testnet (2 nodes, 2 wallets so far). It runs with 1 second block time because I want to catch synchronization bugs faster. Instructions will be later today, but for now you can watch for 0in/2out blocks on https://testnet.xmrchain.net/
09:01:57 <sech1> test instructions are published: https://github.com/SChernykh/p2pool
09:02:08 <sech1> hyc selsta moneromooo or whoever else was interested ^^^
09:04:50 <selsta> sech1: not important now but cmake has some warnings https://paste.debian.net/hidden/6de62345/
09:05:33 <sech1> I'm not strong with cmake
09:06:17 <sech1> I think you'll get this warning if libzmq or libuv is not found
09:10:03 <selsta> syntax looks correct so no idea
09:10:25 <moneromoooo> Odd, I see libuv and more in external already, and we need to install it ?
09:10:25 <selsta> I have both libs
09:10:32 <sech1> "debug" is followed by specifier "debug" means that whatever was between them is an empty string
09:10:42 <selsta> right
09:11:11 <sech1> libuv and stuff in external are just collecting dust there for now
09:11:24 <sech1> I used them to build a fully static binary in Alpine
09:11:38 <sech1> not collecting dust, I still use headers from these folders
09:12:10 <moneromoooo> So... we have to install the exact same version as those headers ?
09:12:18 <sech1> No need for exact same version
09:12:39 <sech1> just headers need to be compatible
09:13:29 <sech1> I need to switch to git submodules and build everything locally, one more thing in a todo list
09:13:56 <selsta> https://paste.debian.net/hidden/80ece6d0/ fails here currently
09:14:22 <sech1> Interesting. What's your gcc version?
09:14:36 <selsta> clang 12.0.5
09:15:07 <sech1> right, clang is not supported yet
09:15:48 <sech1> add INT_ENTRY(unsigned long) in log.h on line 168
09:18:58 <sech1> that also explains your cmake warnings
09:19:10 <sech1> I just don't have stuff for clang there
09:21:53 <sech1> selsta what OS version is this?
09:22:51 <selsta> macOS 11.5.2
09:23:13 <selsta> currently stuck here https://paste.debian.net/hidden/7bd9b27e/
09:24:18 <sech1> clang is retarded
09:24:34 <sech1> sizeof(value.s) should be available to the compiler there
09:26:22 <sech1> I'll try to remove that part entirely, it's not so important
09:27:12 <sech1> I don't have a Mac so it's 100% untested there, but wait until I update log.h
09:28:02 <moneromoooo> https://paste.debian.net/hidden/637d6381/ is needed to build here (Fedora).
09:28:37 <moneromoooo> Oh, I left a debug trace...
10:12:38 <moneromoooo> Is it expected to spew lots of "not enough data to verify block at height" messages ?
10:12:49 <moneromoooo> I have accepted shares from xmrig.
10:13:45 <moneromoooo> I also disabled FULL_MEM and LARGE_PAGES, in case I goofed that one up.
10:15:03 <sech1> "not enough data" is ok
10:15:09 <sech1> it means it haven't synced required blocks yet
10:15:26 <sech1> it will verify this block later when it has enough data, obviously :)
10:15:41 <moneromoooo> Well, still hasn't stopped spewing.
10:15:59 <sech1> It needs to sync 4000+ blocks first
10:16:20 <sech1> currently down to height ~20230
10:16:49 <moneromoooo> OK, it's counting down indeed, at 21k now.
10:17:09 <sech1> it syncs all blocks and then starts verifying from bottom to top
10:17:43 <sech1> xmrig submitting shares means you're already mining from height 0, but it will reorg once you're synced
10:19:38 <moneromoooo> Nice, it's stopped spewing now.
10:20:06 <sech1> I see "3 wallets" messages in the og
10:20:09 <moneromoooo> A new job a second on the xmrig side, whee.
10:20:10 <sech1> *log
10:20:17 <sech1> 2 of those are mine, I suppose 3rd is yours
10:20:36 <sech1> yes, it's running at 1 block/second
10:20:53 <moneromoooo> I see 3 too. That'd be consensus on the share chain side, right ?
10:21:00 <sech1> yes
10:21:20 <sech1> you can type "status" command in the p2pool console if you have it open
10:21:33 <sech1> it'll probably be quickly buried under other log output
10:21:47 <sech1> but you can open p2pool.log and check it out there
10:22:03 <sech1> also "loglevel 2" to stop spam
10:22:23 <sech1> but I recommend to run at maximum loglevel 5 to catch everything in case we get a chain split or bug or something
10:23:22 <sech1> damn, status command doesn't print how many wallets are in the window. I forgot to add it
10:23:38 <moneromoooo> Nice, first coinbase.
10:24:05 <sech1> 0.001710546230 testnet XMR
10:24:21 <sech1> it will grow to match your hashrate after PPLNS window passes
10:24:28 <sech1> ~36 minutes
10:25:29 <moneromoooo> Since those wallet addresses are public, it'd need to have a large mention of such in the README at some point. ie, don't use for exchanges etc. 
10:26:01 <sech1> you can't use exchange deposit addresses for mining
10:26:10 <sech1> because these are subaddresses
10:26:23 <sech1> but yeah, I need to add it to README for the release
10:27:23 <sech1> I thought of how to avoid making miner addresses public but couldn't come up with good solution. Miners could publish stealth addresses to pay to, but they depend on output index, so it's doesn't work for p2ppool
10:29:03 <moneromoooo> So one can estimate every address' hash rate too.
10:29:45 <moneromoooo> Anyway, nifty. Thanks for doing this :)
10:29:50 <sech1> yes, and this estimate would be possible even with stealth addresses
10:30:11 <sech1> because txkey only changes after pool finds Monero block
10:30:59 <sech1> Public miner addresses are a bit of downside here. Miners will have to create entire new wallets and use them only for mining.
10:31:55 <sech1> by the way, each pool share is a Monero block template and you can see BLOCK_BROADCAST (pruned) in the log. Pruned means coinbase transaction is skipped
10:32:16 <sech1> because it can grow up to 80 KB and can be restored from sidechain data because it's part of consensus
10:33:21 <hyc> I installed libuv1-dev and it still says UV_LIBRARY is missing
10:33:53 <moneromoooo> https://paste.debian.net/hidden/637d6381/ helped me with that.
10:34:19 <sech1> moneromoooo your port 37890 is not open btw
10:34:24 <sech1> my node can't connect to you
10:34:33 <moneromoooo> I know. It's a VPN provider.
10:34:49 <hyc> cool thx
10:36:01 <sech1> I must warn that I'm a noob with cmake mumbo-jumbo
10:36:10 <sech1> feel free to make a PR to fix things
10:37:02 <moneromoooo> I think mine's a bodge. It should have worked, since monero has that kind of setup too.
10:39:05 <hyc> I also needed libbbsd here on ubuntu21
10:40:36 <sech1> moneromoooo what's your hashrate btw?
10:41:52 <moneromoooo> Looks like about 40 H/s.
10:42:16 <moneromoooo> Seems high. Depends what other VMs are doing, it'll likely go down to ~25.
10:42:47 <moneromoooo> (I set xmrig to light mode)
10:43:38 <sech1> cool
10:43:54 <sech1> and you got a payout almost immediately, this what p2pool is about
10:44:35 <sech1> I run 2 nodes: first at 475 h/s and second at 963 h/s
10:45:03 <sech1> so p2pool difficulty checks out, currently at 1460
10:48:39 <sech1> "I also disabled FULL_MEM and LARGE_PAGES" do you mean you're running p2pool in light mode too?
10:48:56 <moneromoooo> Yes.
10:49:06 <sech1> cool, it's good for testing
10:49:15 <moneromoooo> Can't afford the 2 GB per. Too many VMs.
10:49:15 <sech1> light mode takes more time to verify blocks, more latency
11:03:19 <moneromoooo> Presumably, if someone were to run a p2pool instance with number of blocks set to, say, 100k, the typical payout amount would be 25x smaller, right ?
11:04:23 <sech1> you probably can't fit 100k outputs in a 300 KB block
11:04:43 <sech1> 2160 outputs are already 80 KB
11:05:05 <sech1> you can ramp it up to ~7000 but then there will be almost no space left for other transactions
11:05:30 <sech1> also, you need 100k wallets if PPLNS window is 100k
11:06:09 <sech1> p2pool combines payouts for shares with the same wallet address
11:12:29 <moneromoooo> Good :)
11:13:30 <moneromoooo> I did not realize that the share chain size itself was "merged" by wallet address. That's interesting.
11:13:57 <moneromoooo> I wonder if that opens a DoS vector.
11:14:37 <moneromoooo> Alice has a lot of the p2pool hash. If she gets unlucky in the last 20 minutes, she might decide to switch mining to many addresses, to flush the unlucky part quicker.
11:15:54 <sech1> I don't get it. Alice still needs to mine blocks with the same difficulty no matter what wallet addresses she uses
11:16:18 <moneromoooo> Yes.
11:16:44 <moneromoooo> But if her shares are spready among N addresses, then the share chain "flushes" quicker.
11:16:51 <sech1> no it doesn't
11:16:55 <sech1> it flushes by block height
11:17:27 <sech1> PPLNS window is calculated using block heights
11:17:34 <moneromoooo> Oh, I re-read and misundersood. Makes more sense now.
11:17:48 <moneromoooo> Is the merging consensus ?
11:17:55 <moneromoooo> ie, you check for uniqueness ?
11:18:22 <sech1> Coinbase transaction is consensus to the last byte
11:19:09 <sech1> coinbase tx is not even sent over the network, nodes restore it locally and then check keccak hash, PoW and so on. And check coinbase tx again just in case
11:19:59 <sech1> merging is part of consensus, it's done deterministically - wallets are sorted and then duplicates are merged
11:20:16 <moneromoooo> That seems eerily similar to my "game tick" txes in my game. I regenerate them, and was thinking of omitting them from the actual network packet.
11:20:40 <sech1> omitting them is kind of necessity with p2pool. Coinbase tx can get quite large
11:21:21 <moneromoooo> Looks like my coinbases have stopped increasing in amount now.
11:21:33 <moneromoooo> I guess we've reached 2160 blocks since I started.
11:21:48 <sech1> they should be equal (approximately) to your hashrate divided by network diff
11:22:00 <sech1> *by network hashrate
11:22:06 <sech1> multiplied by block reward
11:22:34 <sech1> *divided by p2pool diff
11:23:01 <moneromoooo> Handwavy close enough.
11:23:10 <moneromoooo> Oh, p2pool diff...
11:23:15 <sech1> there are always luck variations if the number of your shares in PPLNS window is low
11:23:56 <sech1> yes, for my dev PC it's 963/1404*2.083862640504 = ~1.4293 XMR
11:24:03 <moneromoooo> Spot on using p2pool hsah rate.
11:24:09 <sech1> and it got last payout of 1.369020903033 XMR
12:26:23 <sech1> first p2pool block with transactions in it: https://testnet.xmrchain.net/block/1794242
12:26:39 <sech1> good that merkle tree calculation works properly
12:27:49 <sech1> Also confirmed that it's possible to move mined funds
12:29:21 <sech1> sweep_all transaction: https://testnet.xmrchain.net/tx/136025f6431d44979d3d9440cd818185153a8250d19a0081642111755c4e311d
12:29:31 <sech1> that's what p2pool miners would do eventually
12:39:42 <sech1> looking good so far, 1 second block time works: https://paste.debian.net/hidden/1fe179ea/
13:16:06 <hyc> ufff. syncing fresh testnet node
13:16:22 <hyc> estimated 1.2 days left
13:17:46 <sech1> mine synced in 5-6 hours
13:18:06 <selsta> testnet has no checkpoints
13:18:29 <hyc> anyone got a block export of it I could download?
13:19:15 <sech1> can I do an export on live blockchain? I don't want to stop my node right now
13:19:28 <hyc> yes, no problems with that
13:19:41 <sech1> ok, what's the command?
13:19:53 <hyc> monero-blockchain-export --testnet
13:19:56 <hyc> should be all you need
13:20:01 <sech1> oh, I forgot. I don't have a web server there
13:20:14 <sech1> so I don't know how you would download it...
13:20:20 <hyc> phooey
13:21:43 <sech1> installed nginx, let's see what I can do
13:22:26 <hyc> cool. was syncing from my rockpro64, now \I'm on my ryzen laptop should go faster anyway
13:24:07 <hyc> 4.6 hours estimated
13:36:21 <sech1> hyc http://148.251.81.38/blockchain.raw
14:12:55 <hyc> thanks, got it
14:52:09 <hyc> ok I'm all connected
14:52:15 <hyc> p2pool dies a lot\
14:52:26 <hyc> "Killed"
14:52:36 <sech1> how much ram do you have?
14:52:40 <hyc> prob out of RAM on this box since my regular node is here
14:52:45 <hyc> 4GB
14:52:49 <sech1> try light mode
14:52:54 <sech1> --light-mode in command line
14:52:58 <hyc> ok
14:54:22 <hyc> so, 25 hashes accepted so far
14:54:39 <sech1> you're probably still syncing
14:54:50 <sech1> I don't see 4 wallets in PPLNS window yet
14:55:17 <hyc> oh, p2pool needs to sync still?
14:55:20 <sech1> you'll see difficulty jump in xmrig, from 999 to ~1400 when your p2pool node reorgs
14:55:26 <hyc> ok
14:55:32 <hyc> still 999 for now
14:55:40 <sech1> right now you're mining on your own chain from height 0 and p2pool is syncing in the meantime
14:55:55 <sech1> give it 5-10 minutes
14:56:07 <hyc> ok
14:56:59 <hyc> p2pool logging is massive
14:57:09 <sech1> yes, as intended
14:57:18 <sech1> it'll get better after it's synced
14:57:28 <hyc> cool
14:57:51 <sech1> if you want you can try to set up logrotate to deal with logs
14:58:35 <hyc> this isn't using easylogger huh, won't rotate by itself?
14:59:09 <sech1> what block heights do you see in the log right now? It'll stop syncing when you get down to ~36900
14:59:14 <sech1> no it won't rotate by itself
14:59:30 <sech1> but it'll detect if you rename p2pool.log
14:59:46 <hyc> ok
15:00:12 <hyc> 37124
15:00:17 <hyc> getting there
15:00:47 <sech1> oh I see you synced
15:00:57 <sech1> got a bunch of blocks from you that you've been mining
15:00:57 <hyc> ah there we are
15:01:06 <sech1> from height 0, so my node discarded them
15:01:20 <hyc> I stopped the miner in the meantime. just restarted now
15:01:27 <sech1> I see 4 wallets in PPLNS window now
15:01:31 <sech1> looks like you're in!
15:01:39 <hyc> cool!
15:01:53 <hyc> so the monerod and p2pool are running on my rockpro64
15:01:57 <hyc> the miner is on my M1 mac
15:02:43 <sech1> rockpro64 is ARM, right? Nice to test it there too
15:02:49 <hyc> yes
15:03:13 <hyc> rockchip RK3399, pair of Cortex A73 plus some A53
15:03:41 <sech1> looks like my dev PC connected to you, I have 2 outgoing connections now
15:04:26 <hyc> cortex A72, oops
15:05:05 <hyc> yeah, nice that my fibre ISP gives me an actual routable IPv4 address
15:05:52 <sech1> you butchered p2pool luck :D Still no block since you joind
15:06:04 <hyc> doh
15:06:34 <hyc> I've been suspicious of the M1 for a while. been solo mining for months and got nothing
15:06:58 <hyc> but if it were generating invalid hashes we'd see errmsgs right?
15:07:06 <sech1> yes
15:07:20 <sech1> I don't see any verification errors, so my node accepts your shares
15:07:31 <hyc> cool
15:08:12 <sech1> finally
15:08:19 <sech1> https://testnet.xmrchain.net/tx/a8f52f8c7f168a6fafa3c727f13fbd8f7522aca69c1a4e8eb0c5bcd192b2573d
15:08:22 <hyc> the fact that this machine miscompiles my simple database benchmarking tool inspires no confidence
15:08:29 <sech1> already 0.031080440002 XMR? What hashrate are you mining at?
15:08:46 <hyc> 283H/s
15:08:55 <sech1> oh
15:09:10 <sech1> you probably mined a lot of shares because we waited so long for a block
15:09:22 <hyc> wallet shows .06xxx
15:09:34 <sech1> ah, so 0.03... was mooo's
15:10:38 <sech1> you should be getting ~0.35 XMR per block with current hashrates after your shares fill PPLNS window
15:10:42 <sech1> in 30-40 minutes
15:11:50 <moneromoooo> I've been stopping/restarting mining a couple times when I needed oomph on a dev vm.
15:12:39 <hyc> gonna spin up a thread on the rockpro64
15:12:49 <sech1> stopping/restarting should work fine
15:12:50 <hyc> in a while. recompiling xmrig now
15:13:13 <sech1> hyc do you have enough RAM there to spin up xmrig too?
15:13:26 <hyc> will find out ;)
15:13:39 <sech1> if your node dies, you'll have to sync again
15:13:48 <sech1> p2pool doesn't save blockchain
15:13:55 <hyc> ? oh
15:14:02 <sech1> by design
15:14:10 <sech1> it's ephemeral, old blocks are pruned
15:14:28 <hyc> ok
15:14:41 <sech1> of course I can add saving, but saved data gets obsolete pretty quickly
15:14:55 <hyc> prob not worth it then
15:15:09 <sech1> saved blockchain is useless after ~6 hours with normal 10-second block time
15:16:47 <hyc> unless you save in a circular buffer
15:16:51 <hyc> that might be nice
15:17:52 <sech1> it's probably needed anyway for the cases when you just need to restart p2pool node
15:17:58 <sech1> and don't want to sync again
15:18:41 <moneromoooo> "Monero p2pool. Spent a week syncing the chain ? Sync you're done ? Sync again."
15:18:50 <hyc> lol
15:19:12 <sech1> 4320 blocks can by up to 200-300 MB of data, depending on how many miners are on the pool
15:19:14 <sech1> *can be
15:19:29 <sech1> because initial sync doesn't use pruned blocks
15:19:59 <sech1> another thing on my todo list :D
15:23:04 <moneromoooo> BTW, earlier, p2pool crashed on startup with unable to bind. I must have run it once before and it was in wait.
15:23:26 <moneromoooo> I did not have a stack trace in gdb sadly.
15:23:41 <selsta> ./p2pool --version ends in a crash
15:24:19 <sech1> lol
15:25:02 <sech1> it doesn't even have this command line parameter, but it shouldn't crash
15:25:32 <mechanic41turk[m> Hi! Excited about monero p2pool
15:26:15 <selsta> sech1: wait
15:26:18 <selsta> it's not a crash I think, just SIGABRT
15:26:29 <selsta> didn't look properly
15:26:53 <hyc> looks like I only have 235M free RAM, won't bother starting xmrig there
15:35:27 <hyc> going to move monerod and p2pool to the mac
15:45:04 <sech1> also don't forget to look at p2pool memory usage. It shouldn't be leaking memory. My node has been stable at 3469620/37780/10096 (VIRT/RES/SHR)
15:56:25 <hyc> p2pool doesn't want to run on mac
15:56:34 <hyc> I get an abort. haven't got a backtrace yet
15:57:03 <hyc> starting under debugger gets an immediate abort, pthread_kill inside uv_rwlock_tryrdlock
15:57:32 <moneromoooo> 2.6 GB resident. Looks like I did not take out the full mem after all.
16:00:03 <selsta> hyc: does ./p2pool --help work?
16:00:05 <selsta> without abort
16:02:40 <moneromoooo> Oh look, it's got a --light-mode. Should have looked before grepping and chaning...
16:03:02 <moneromoooo> I just ran ./p2pool --help here, I got the help, but it doesn't exit.
16:03:24 <sech1> Ctrl+C
16:03:40 <hyc> yes --help worked
16:03:54 <hyc> without debugger, it starts and runs for a while before it aborts
16:03:56 <sech1> there is a thread reading from stdin waiting for console command and it stops p2pool from exiting properly unless you press Ctrl+C
16:04:17 <selsta> no need for ctrl+c on mac with --help
16:04:18 <hyc> there don't appear to be any legal console commands
16:04:28 <moneromoooo> Stack in PM.
16:04:33 <selsta> hyc: same here
16:04:41 <moneromoooo> Possibly ir crashes before the hang on mac :D
16:05:46 <sech1> hyc p2pool has a few console commands, check console_commands.cpp
16:05:54 <selsta> I don't have xmrig and monerod testnet setup here so can't fully test it
18:10:29 <hyc> think I'll write a PR to add a help and exit cmd
18:10:33 <hyc> though I guess EOF is fine
18:13:06 <sech1> sure
18:14:30 <hyc> BLOCK FOUND ooo
18:14:33 <sech1> I'm working on the block cache (circular buffer as you suggested)
18:14:51 <sech1> BLOCK FOUND is printed every time p2pool finds a block, not just your node
18:15:00 <hyc> ah
18:15:07 <sech1> because it will be rare thing on the mainnet
18:15:52 <sech1> you'll see "submit_block: BLOCK_ACCEPTED at height ..." log message in addition to that if your node finds a block
18:16:13 <hyc> it all scrolls by too uick to notice
18:16:38 <sech1> you can grep the log
18:17:07 <sech1> and the release will have more shy log level by default :)
18:37:26 <aypro> will monerod overwrite my mainnet blockchain if i run a testnet ?
18:45:02 <moneromoooo> No.
20:11:37 <pollofritto> What's up everyone. Is this channel exclusive to the p2pool project?
20:11:50 <Inge> nope. all things monero-proof-of-work
20:13:48 <pollofritto> Gotcha. Looks like I'm a little early to the pool party then.. hehe
20:14:06 <Inge> well, p2pool is the topic du hour
20:14:09 <Inge> du jour*
20:31:27 <Inge> someone is fighting ETH for high fees? https://xmrchain.net/block/a48494d5cc4239d2b28d48b6699ebf74a75b34910f210eca79f33c0023203e09
20:33:29 <nioc> 0_o
20:36:10 <gingeropolous> 2.9 xmr for the fee? what wallet implementation even allows that? 
20:36:25 <hyc> I can never get a clean exit, stratumserver hangs in destructor on uv_thread_join
20:36:25 <gingeropolous> sorry, 2.04 . 
20:36:37 <hyc> its lopp is still in uv_run even though uv_stop was called
20:37:08 <hyc> p2pool, zmqreader, and p2pserver loops all stop/close cleanly
21:00:00 <sech1> hyc I have the same problem in Linux, but it shuts down fine in Windows. It looks like it just doesn't close TCP sockets
21:01:10 <hyc> sounds like a libuv bug then
21:02:07 <sech1> yes, I remember that it got stuck even without xmrig connected. It couldn't close listen sockets
21:03:29 <sech1> I've been experimenting with saving/loading pool blocks on startup and found out that initial sync is very fragile and depends on the order in which blocks are received
21:04:17 <sech1> not sure how to make it robust, a bit of refactoring will be required
21:13:08 <hyc> I was thinking it mainly got stuck when there are no miners connected, since that's my current tester
21:34:55 <Guest35> i just saw the pull request for the p2pool project you could avoid all the const char*, char[] etc when using std::string_view, the pull request literaly deploys its own string_view as a struct called strconst
21:36:26 <Guest35> all the static constexpr char[] = ... globals could be changed to be static constexpr auto bla = "someString"_sv
21:36:55 <Guest35> ofc the auto can be avoided if the author of the projects does not like auto
21:38:21 <hyc> auto makes some things unnecessarily obscure, particularly when reading source code while debugging
21:39:24 <Guest35> yeah thats why i said the auto ofc is optional :D   i code a lot of scala normaly which is why i dont care not seeing the type :D
21:39:50 <hyc> it's a perfect example of C++ making irrelevant things easier up front and even harder later on
21:41:35 <Guest35> i use auto all the time and i have never got into problems using it, i guess its personal perference 
21:42:10 <Guest35> i hate typing types, the compile knows exactly which type an expression has, why should i need to be forced to write it all the time?
21:42:20 <hyc> debugging is usually an order of magnitude harder than writing code in the first place. so features like that are optimizing the wrong thing
21:42:50 <Guest35> auto does not make debugging much harder? 
21:43:02 <Guest35> it either typchecks or it doesnt
21:43:12 <hyc> that's not the point
21:43:26 <Guest35> i dont know what obscure useage of auto you are refering to which makes debugging harder
21:43:39 <hyc> when you're trying to find a bug and you want to know sizeof(foo) or what fields are present etc
21:43:50 <hyc> it's better when it's all explicitly spelled out in the source code
21:44:03 <hyc> instead of you needing to invoke helpers to decipher it for you
21:44:43 <hyc> typechecking isn't the issue, and again, it's trivial to do that up front
21:45:10 <pollofritto1> we call them efficiency elves
21:45:28 <hyc> but when you're deep in the weeds, all of that abstraction just hides details you might need to know
21:45:47 <Guest35> i guess thats your opinion and i only see that argument made for c++, almost all modern languages support typeinference and nobody has the debugging problems
21:46:03 <sech1> hyc I'll merge it tomorrow but I can already tell it won't compile on Windows because of "kill" call
21:46:21 <hyc> sech1: yes, that's why I said it needs feedback...
21:46:34 <Guest35> but as i said i usually do scala or haskel so i am used to not writing types :D
21:46:50 <hyc> almost all modern languages besides C and C++ are interpreted so they're really not worth discussing here
21:47:20 <Guest35> rust, scala, haskell ... non of that is interpreted
21:48:22 <hyc> scala is a jvm language
21:48:50 <Guest35> yes?
21:48:59 <hyc> never mind. this isn't the place for language debate\
21:49:11 <Guest35> you are right :D
21:52:32 <hyc> sech1: couldn't figure out why calling uv_stop(uv_default_loop()) from do_exit doesn't work, but it works from the signal handler
22:00:39 <hyc> hm. it does work, but takes ~20 seconds to happen
22:02:54 <moneromoooo> They really should have made auto mean "do what I mean". Like, int process_data() { auto; }
22:03:01 <moneromoooo> Now that'd be somehting worth having.
22:03:10 <hyc> ;)
22:04:26 <hyc> hm, took 2 minutes that time. talk about flaky. why do people like libuv, again? looks like crap, to me.
22:06:54 <hyc> basically it seems that uv_run sits in an epoll_wait() for a bunch of descriptors, which are usually network sockets
22:07:11 <hyc> but if there's no network activity, it never wakes up for local things like uv_stop()
22:07:37 <hyc> one would think they'd be smart enough to add a pipe in there for local event signaling
22:15:12 <sech1> ok, so the workaround would be to just connect and immediately disconnect
22:15:17 <sech1> that would wake up epoll_wait
22:15:31 <sech1> and do it in shutdown_tcp()
22:16:35 <sech1> libuv is hard to handle, but it wraps the most efficient network layers in each OS
22:29:21 <aypro> do i have to have the ports open in my firewall for p2pool to work ?
22:32:25 <sech1> it's not required, but it will work better with open ports
22:33:25 <aypro> i'm sending shares and getting tx in the wallet, all good
22:43:23 <sech1> nice
23:04:09 <hyc> aha, figured out how to make sure the event loop wakes up immediately