07:41:54 <mj-xmr[m]> icscloud[m]: You could still achieve good mining performance (for a given hardware), if you do everything in Java, EXCEPT for the mining part and just call it via JNI: 
07:41:54 <mj-xmr[m]> https://developer.android.com/training/articles/perf-jni
07:43:01 <mj-xmr[m]> Which by the way, might turn out to be much less (guess)work, than trying to reimplement RandomX in Java.
12:37:15 <icscloud[m]> > <@mj-xmr[m]:libera.chat> icscloud[m]: You could still achieve good mining performance (for a given hardware), if you do everything in Java, EXCEPT for the mining part and just call it via JNI: 
12:37:15 <icscloud[m]> > https://developer.android.com/training/articles/perf-jni
12:37:15 <icscloud[m]> nice
12:37:19 <icscloud[m]> <mj-xmr[m]> "Which by the way, might turn out..." <- yes
12:37:49 <icscloud[m]> thanks
14:27:28 <garth> <garth> Can I ask why we aren’t having our PRs merged in the main Monero GitHub repo? There are 140 unmerged PRs in the queue. I understand they need review, but there are a lot that have passed review, and they still have not been merged. Is Luigi1112 too busy to maintain the main repo (which is totally fine)? If so we need to come together as a community and find or fund someone to do this 
14:27:28 <garth> important work. I am grateful for fluffypony and all the volunteer merges he did in the past. Ric, any chance you might be interested in taking up this volunteering again? If not, considering snipa doesn’t seem to have had the time or energy to help, do you have any ideas?
14:27:41 <garth> Cross posed from #monero 
14:27:50 <fluffypony> I unfortunately don't have the time to take up a lead maintainer role again 
14:28:05 <fluffypony> I do agree we need someone to really step up to the mantle with that
14:29:22 <garth> I understand that repo merge privileges are massive to give away (partially responsible for splitting BTC) but IMHO constant merges are what gave the project a ton of energy back in 2017-2018. To have slow unconsistent merges makes the project itself lose energy 
14:31:17 <fluffypony> I'd suggest we start an issue in the meta repo, and then encourage anyone who wants to take on the role (and, importantly, has a few hours a day to commit) can post in that thread
14:31:37 <garth> Ok I can do that. In my opinion Monero is the most interesting, useful, and legitimate cryptocurrency in the world right now. This is important for the project to keep alive
14:32:44 <xxfedexx[m]> Do you think that some paid/crowdfunded developer would help to improve the situation?
14:33:30 <garth> Perhaps, sure. It all depends
14:35:29 <xxfedexx[m]> I would love to contribute, but I never used C++, sadly I'm just a JavaScript and Java developer
14:38:39 <garth> Meta issue created —> https://github.com/monero-project/meta/issues/675
14:41:51 <cornfeedhobo> "importantly, has a few hours a day to commit"  <--  this is the killer
14:44:00 <fluffypony> xxfedexx[m]: a maintainer is absolutely allowed to go and crowdfund for the time they spend
14:44:19 <fluffypony> but trust is something that is earned over time, so a newcomer wanting write privs in the repo + getting paid for it is doubly problematic
14:44:30 <fluffypony> this situation is ripe for abuse, so the decision would need to be taken carefully
14:52:40 <louipc> put the work in first. prove competency and dedication
14:55:19 <louipc> xxfedexx[m]: if you can program in general great. seems like you should have an understanding of OOP if you do Java so you're on a good track. 
14:55:50 <louipc> there are tons of free online resources to learn C and C++
14:56:15 <xxfedexx[m]> louipc: Do you mean Object Oriented Programming? It's not hard
14:56:41 <louipc> yes, but the point is that you have some of the concepts in your head already
14:56:50 <louipc> not a complete noob
14:57:00 <louipc> you will have to learn about how computers really work
14:57:09 <louipc> tho. memory handling
14:57:33 <louipc> buffer/integer overflows and whatnot
15:32:08 <cornfeedhobo> to be fair, the ramp up time for C/CPP can be pretty long, especially for a technical project
15:36:33 <wernervasquez[m]> cornfeedhobo: I was first taught CPP. I cannot, in good faith, recommend it for anything. Retrospectively, I can see how much of my time it wasted.
15:38:14 <wernervasquez[m]> I don't know about its original competition, but compared to modern languages, it feels like it was written by people who hate programmers.
15:39:26 <cornfeedhobo> haha. it was built for a different time.
15:45:48 <luigi1112> <fluffypony> I do agree we need someone to really step up to the mantle with that <= +1
15:45:56 <luigi1112> .merges
15:45:56 -xmr-pr- 7675 8154 8158 8159 8169 8186 8187 8190 8216
15:51:05 <hyc> C was a good design for its era, late 1970s, where 32KB was a "large" amount of RAM
15:51:33 <hyc> it followed much the same path as other compiled languages of the era: fortran, cobol, pascal
15:52:08 <hyc> C++ was a sick joke from day 1. Ignored innovations already well established in Modula-2, ADA, etc.
15:58:32 <wernervasquez[m]> My frustrations with CPP is why I started working on a Go repo. Its not much yet, but it will get there. 
15:59:19 <hyc> Go is still mostly a toy language
16:00:19 <hyc> http://nomad.uk.net/articles/why-gos-design-is-a-disservice-to-intelligent-programmers.html
16:00:58 <hyc> "What? So Rob Pike is basically saying that the developers at Google aren’t very good so they’ve developed a dumbed down language so they can get things done."
16:02:13 <wernervasquez[m]> Well, they certainly catered to me 😅
16:05:06 <cornfeedhobo> hyc: there is a good talk about this, but the tl;dr is that go is not meant for siloed programmers. Historically siloed and intelligent went hand-in-hand, but that is no longer the case, and that blog post is the emotional fallout of someone learning they will not be valued the way they used to be
16:06:30 <cornfeedhobo> put another way, companies needed a language that was so simple that swapping out the employees that built a codebase is trivial
16:07:55 <wernervasquez[m]> hyc: I am several orders or magnitude a lesser programmer than you. I'll own that. I am not so intelligent that I need more. Go is a sweet spot with me (but does have its own issues).
16:08:13 <hyc> so you're saying go is bad for job security
16:09:16 <wernervasquez[m]> <hyc> "http://nomad.uk.net/articles/why..." <- I think some of these issues have been addressed with more recent versions. However, for some things it is verbose and boilerplate.
16:09:41 <cornfeedhobo> hmm, yeah that's one way to interpret it. of course, any interview that I go into where someone is worried about that or makes that joke gets immediately removed from our list. It's been our experience that they throw more wrenches than anyone else.
16:10:54 <cornfeedhobo> it's not a hard and fast rule, but it's not the type of thinking that helps. because the same employee could be removed from the codebase through promotion or finding a better company or some project they'd prefer to work on
16:10:59 <wernervasquez[m]> Its error handling is verbose and boilerplate, but I address that in my code by making my types include an error type with the data, rather than returning it as an additional arguement.
16:11:08 <hyc> it's certainly a weird notion, yes. job security should be about your ability to apply your skills to any problem. not solely your intimate familiarity with a single code base
16:11:18 <cornfeedhobo> exactly
16:13:45 <wernervasquez[m]> cornfeedhobo: It isnt just simplicity to swap out people (which IMO is good for an open source project). But set up, compile, testing, benchmarking, optimizing concurrency...it is all so quick and easy.
16:13:52 <hyc> at any rate, I personally despise most modern languages that keep the programmer multiple layers of abstraction away from the actual bits and bytes
16:14:32 <hyc> strongly-typed languages etc... you can't even do cryptography properly in them
16:15:01 <hyc> because our ciphers and hashes treat e.g. 32 byte clumps as big integers
16:15:28 <hyc> you need to understand at a very low level what all your high level data types really instantiante as
16:15:55 <wernervasquez[m]> hyc: You are smart. And your intelligence is extremely valuable. But it is also uncommon. I think for a collaborative project, such a language is better. And programmers like you can tackle the issues no one else can, while everyone else is maximally productive on everything else.
16:16:20 <hyc> you have to be able to freely jump back and forth between "objects" and "sequence of bytes" otherwise you can't even write the calculations needed.
16:16:46 <cornfeedhobo> wernervasquez[m]: yeah. indeed i like those other values, but to be fair, there are a host of other languages on the scene now that do the same. The real big sticking point with golang is that it's so small you can literally learn it in ~6 hours
16:17:47 <cornfeedhobo> hyc: nimlang might be up your alley
16:18:05 <hyc> hmm, seen it mentioned a few times but never looked at it
16:20:13 <wernervasquez[m]> <hyc> "strongly-typed languages etc..." <- Filippo seems like an compentent cryptographer-programmer. He writes for Go. https://filippo.io/ (I put him in the same bracket as you - beyond smarter than I).
16:27:50 <xxfedexx[m]> <wernervasquez[m]> "Filippo seems like an compentent..." <- Another Italian coder :-)
16:28:19 <xxfedexx[m]> I'm Italian too, just like ErCiccione and FluffyPony
16:39:52 <wernervasquez[m]> Speaking of Filippo, does the monero codebase have anything like his baseMult implementation? https://github.com/FiloSottile/edwards25519/blob/v1.0.0-rc.1/scalarmult.go
16:39:53 <wernervasquez[m]> It looks like you can swap one line and have an efficient point multiplication for any point. Not just base.
16:41:26 <UkoeHB> no
16:42:20 <wernervasquez[m]> It sets up the tables on first use, so if we had that, we could make a function that accepts a point, sets up the tables, and allows quick multiplication.
16:43:21 <wernervasquez[m]> It would be useful during prototyping. And if we ever needed to scalar mult a point defined during runtime enough to justify the overhead.
16:44:02 <moneromooo> We do, at least in BP IIRC.
16:44:13 <UkoeHB> wait nvm I think it's the ge_precomp thing
16:45:56 <wernervasquez[m]> UkoeHB: Cool, I'll take a look
16:47:05 <UkoeHB> or maybe the ge_dsmp
17:58:44 <spirobel[m]> <hyc> "http://nomad.uk.net/articles/why..." <- that article is a bit vulgar and does not feature the biggest issue with go: goroutines. They are not really coroutines and not really OS threads. Scheduling seems to be preemptive and not cooperative. It is not easy to gain an intuition for how they will perform and what the limitations are. I really liked the talk by Rob Pike about concurrency when I looked into go in 2015. Everything
17:58:44 <spirobel[m]> seemed so clear and easy. In practice it is sadly not like that. But there are also good things about go. For example compile times.🙂
19:16:45 <wernervasquez[m]> spirobel: Can you give a concrete example of an issue this caused you that a simple programmer would understand?
19:45:54 <amackillop[m]> Thoughts on Rust? I've heard a lot of good things about it and I thinking to give it a try 
19:48:11 <bootlegbilly[m]> I'm a huge fan personally, it makes writing multithreaded code  performant and safe without a GC
19:48:43 <joerg1> why not using golang?
19:56:39 <bootlegbilly[m]> <joerg1> "why not using golang?" <- Golang is a great language for many projects, but it does have downsides. For one, the garbage collecter and runtime mean that it's much more difficult to use in embedded projects and projects requiring low CPU usage and very low memory usage. The GC, while being very useful and definetly has a small amt of overhead, still does have overhead that matters in very performant applications
19:57:03 <bootlegbilly[m]> Rust achieves a lot of what GoLang does without compromising on performance or memory usage
20:00:18 <joerg1> It seams that I have to learn Rust.
20:01:15 <bootlegbilly[m]> joerg1: I'd definetly recommend it! Though just to warn that the language forces you to re-think the way you program, and it can be very frustrating in the beginning. That and compile times are painful (but worth it)
20:02:04 <joerg1> XMRig is in C++. Is it a good idea to change the programming language?
20:02:08 <selsta> .merge+ 8170
20:02:08 <xmr-pr> Added
20:02:30 <bootlegbilly[m]> joerg1: You want to write a monero miner?
20:02:49 <joerg1> I am thinking about.
20:03:53 <bootlegbilly[m]> If it's a brand new project, yes, writing it in Rust would be a great idea. If it's an existing project, rewriting specific parts in Rust or writing new modules in Rust and using #[repr(C)] to make it C-ABI compatible would probably be easiest
20:04:30 <joerg1> It is a brand new project.
20:05:29 <bootlegbilly[m]> Id definetly recommend starting it in rust then
20:05:42 <bootlegbilly[m]> if you need any help or have any questions abt the project or writing it feel free to message me
20:07:17 <joerg1> Thank you. Here is another question. The idea from the Bitcoin white Paper is to use only CPU Mining. What do you think about to write a miner specific for CPU mining?
20:07:59 <UkoeHB> aka a randomx miner?
20:08:13 <joerg1> Yes
20:08:26 <selsta> you won't get any speedups, the critical parts are written in ASM
20:08:28 <UkoeHB> all monero miners are randomx miners, so...?
20:09:08 <joerg1> What are your opinions?
20:09:57 <selsta> I guess you can do it as an exercise, but otherwise I don't think there is much point to this. Also IIRC someone implemented RandomX in Rust, but I'd have to look it up.
20:12:36 <joerg1> The idea is to give all the same chance to mine monero. You don't need expensive GPU's. for exaample. your smartphone can do the job if you don't need this device.
20:13:09 <bootlegbilly[m]> Mithril miner is written in Rust
20:14:29 <UkoeHB> joerg1: monero already uses randomx, not sure what you want to change...
20:14:35 <selsta> It's not clear what your goal is. You can mine already on your smartphone and other platforms. What would changing the programming language do?
20:15:42 <joerg1> Okay that is the information, that i had not. 
20:29:38 <joerg1> I would like to learn to code for the Monero Project.
21:33:31 <Rucknium[m]> I am collecting info on what Decoy Selection Algorithms wallets are using:
21:33:31 <Rucknium[m]> https://github.com/monero-project/research-lab/issues/99
21:34:41 <Rucknium[m]> If you know what methods wallets are using to select decoys, I encourage you to leave a comment with a link to the relevant source file(s).
22:46:24 <NakedKing> I've asked this question on #monero channel but no answered. I'll try my chance here.
22:46:29 <NakedKing> A question: Is it dangerous to make together fountain/escrow wallet and users wallet (for all just 1 wallet, they become a subaddress on a wallet)
22:46:36 <NakedKing> $moneroRPC->open_wallet  takes too much time for everytime. I cant optimize it.
23:28:08 <UkoeHB> NakedKing: I don't understand your question. Make a wallet multisig will convert the entire thing (deleting old keys). You can't have both.
23:28:36 <UkoeHB> both the old normal wallet and the new multisig wallet*, unless you have two separate wallet instances.