-
m-relay
<tzadiko:matrix.org> Got this comment to change from CamelCase (FeePriority) to snakeCase (feePriority) for an enum. I don;'t see a standard naming convention. Some code uses `this_convention` too.
-
m-relay
<tzadiko:matrix.org> What's the correct approach? vtnerd
-
m-relay
-
m-relay
<jeffro256:monero.social> I might be wrong but feePriority isn't snake case, fee_priority is
-
m-relay
<syntheticbird:monero.social> i'm pretty sure snakeCase is actually snake_case
-
m-relay
<syntheticbird:monero.social> yeah exactly
-
m-relay
<jeffro256:monero.social> Jinx
-
m-relay
<syntheticbird:monero.social> and CamelCase is actually camelCase
-
m-relay
<syntheticbird:monero.social> oh wait no im wrong on this one nvm
-
m-relay
<syntheticbird:monero.social> ah ok depends there is lower camel case and upper camel case
-
m-relay
<jeffro256:monero.social> Some people call thisStyle "Pascal case"
-
m-relay
<syntheticbird:monero.social> interesting
-
m-relay
<syntheticbird:monero.social> i suppose this is a psyop/plot from the Pascal community, these guys are more fanatics than rustaceans
-
m-relay
<jeffro256:monero.social> No wait I screwed that up . Uppercase camel case = Pascal case
-
m-relay
<syntheticbird:monero.social> don't want some good kebab-case
-
m-relay
<syntheticbird:monero.social> 🥙
-
m-relay
<tzadiko:matrix.org> Oh derp
-
m-relay
<tzadiko:matrix.org> Ok, will change to that. I confused pascal and snake.
-
m-relay
<syntheticbird:monero.social> naming convention would be cool
-
m-relay
<syntheticbird:monero.social> almost forgot with Rust that C++ don't particularly enforce one.
-
m-relay
<tzadiko:matrix.org> Snake case classes and enumerations just feels dirty to me.
-
m-relay
<syntheticbird:monero.social> agree
-
m-relay
<ofrnxmr:xmr.mx> This pr was updated
-
m-relay
<ofrnxmr:xmr.mx> 9838 (for irc). Precursor to 9847 (increase auto fee to lvl 3 if over 12hrs backlog at greater than lvl 2)
-
m-relay
<syntheticbird:monero.social> ofrnxmr: when are you learning C++ to help?
-
m-relay
<syntheticbird:monero.social> apologies i thought i was in #monero
-
m-relay
<ofrnxmr:xmr.mx> Yesterday
-
m-relay
<syntheticbird:monero.social> great
-
m-relay
<syntheticbird:monero.social> first PR for monero when?
-
m-relay
<ofrnxmr:xmr.mx> Already merged
-
m-relay
<ofrnxmr:xmr.mx> 2nd* already, first coauthored 9494
-
m-relay
<ofrnxmr:xmr.mx> Another closed in favor of 9847
-
m-relay
<ofrnxmr:xmr.mx> I stay in my lane
-
m-relay
<jukeman1968:matrix.org> Hello! I am looking for a list of IPs of spy nodes. Does this list exist?. I would like to dinamically update this list using an nftables set. Will this work? Thanks!
-
m-relay
-
m-relay
<syntheticbird:monero.social> and i think the later included the first but im not sure. boog900 ?
-
m-relay
<syntheticbird:monero.social> also didn't know you could establish a dynamic set of addresses with nftables, sounds awesome.
-
m-relay
<boog900:monero.social> mostly I think there are a couple not
-
m-relay
<syntheticbird:monero.social> well then only the first
-
m-relay
<boog900:monero.social> you can still use the later, its only like 2 IPs. The later includes IPs of more malicious nodes not just the current spys.
-
m-relay
<jukeman1968:matrix.org> Excellent. No need to use a firewall, the daemon supports it directly. Even better. Good job guys 🙌
-
m-relay
<jukeman1968:matrix.org> I will give a try tomorrow. It might be more efficient than adding it to the daemon.
-
m-relay
<syntheticbird:monero.social> I'm certain it will much more INefficient
-
m-relay
<jukeman1968:matrix.org> You mean with nftables more inneficient?
-
m-relay
<syntheticbird:monero.social> adding the ban list will just prohibit these nodes from connecting to you or you trying to connect to them. if you set nftable it will do this check at every ip connections
-
m-relay
<syntheticbird:monero.social> yes
-
m-relay
<jukeman1968:matrix.org> Makes sense