The issue ending up being the sweep_all method seemed to timeout and the database could not be updated after that. I fixed a few things and all is good now. Thanks for the help

the site is live now and ready to use xmrmemes.com

monerodev880022[: that's a pretty neat concept

UkoeHB: thanks

The idea / concept was done by the Wownero community first but I thought Monero needed something similar so I set out to build this a few weeks ago.

make sure to post on reddit

selsta: Yep I did a little ago. Also posted on /r/moonero

the one thing wownero did right

monerodev880022: ive got an idea for you

allow webm or gif

RustyLumberjack[: Did you have trouble submitting a gif?

GIFs should work unless there is a bug or something

I will look into adding support for webm though, not sure if that works.

that'd be cool. could make/submit custom monero webms

Kk will look into adding it tomorrow

Think currently it is (JPEG, JPG, PNG, GIF)

Thanks for the advice

boots up kden live

monerodev880022: my submission on your site swapped my wallet addy with someone elses

btw discussion about this site would be best for #monero

RustyLumberjack[: Each meme gets a new address to keep track of the stats. It will send the XMR to the address you signed up with. I will add a note on the website about this.

selsta: kk

thanks and srry selsta

also... php - havent seen something so recent made with it 🙂

C++ question: I have a 'module'-like set of functions. Some are 'interface' (intended to be called from outside), some are 'internal' (only supposed to be called within the module). Since Monero is in C++11 (no 'module' language feature until C++20). To mimic the module 'export' behavior, I am thinking about making a monostate class whose members are all static functions. This way 'internal' functions can be private, and

'interface' can be public. Is this idea basically flawed, is there a better approach (e.g. two headers - although in that case someone can still include the 'internal' header from outside), what are people's thoughts?

<UkoeHB> "'interface' can be public. Is..." <- No problem with being able to include internal headers, I believe. If they are supposed to be tested, they have to be able to be included. You can limit their visibility by NOT distributing them along with your SDK.

Some people (me included) will also say, that private methods are an untestable evil.

It's better to extract them into a separate class.

You can also separate the private methods in the way, that a public static method returns an object, which is testable, while the sole responsibility of the corresponding private method would be calling the public one, and using the returned object to set a state of an internal member.

Lately, there has to be a clear separation about what an interface is, and what it is not.

An interface is a class, that consists of pure virtual methods and has no member variables.

Look at wallet2.h for a perfect counter example.

Here is how I'm solving the issue.

So having absolutely NO member variables, proactively forces you to create an interface, which is monostate.

Which is a very good thing.

Since then you can pass it along as a const reference, which in the end allows you for a very predictable behavior.

For some reference: Java first introduced the concept of pure abstract classes, called Interfaces, but at the same time while C++ allows it, but most people don't know how to use interfaces, only C++ has a full blown const-correctness mechanism (that most people don't use either)

It's also worth mentioning, that a pure abstract interface in C++ allows you to forward declare ALL of the dependencies. This is useful, because not all the users will be calling all the methods, thus they will not need all of the dependencies being included.

And a word from our sponsor: I'm looking for reviewers on 7679 :)

Hmm I see, thank you! Since I don't need any member variables, simply using two headers where only one is made public in cmakelists seems like a good idea.

That being said, I still don't know much about cmake lol

<UkoeHB> "That being said, I still don't..." <- I'm not sure we use this technique here, but it's the installation step of CMake, where you deliver the shared libraries and their interfaces. This is a perfect excuse to have the "private" functionality embedded in the libraries, but skip a few headers :)

mj-xmr[m]: If the headers are internal to a component, how do you go about unit testing? Is it a better pattern for unit tests to be defined within the subdirectory?

<UkoeHB> "mj-xmr: If the headers are..." <- Yes, exactly. This way, you know, that your internal code works before even "advertising" it outside. Secondly, you don't need to compile and run "Everything.h" just to get the *unit* tested.

For the same reason, I was even arguing with my "colleagues", that such an internal code in form of templates should be at least included by a corresponding .cpp file within the library, before it even reached the library's own unit tests. The reason is, if the template's declaration is wrong, the tests wouldn't compile either.

So better learn this soon enough. A higher form of purism, but a consequential approach.

They were arguing that such an empty inclusion was "dead code". One of reasons to leave that project :)

> at least included by a corresponding .cpp file within the library, before it even reached the library's own unit tests. The reason is, if the template's declaration is wrong, the tests wouldn't compile eithe

I think I see what you mean. First say the library compiles, then say the library's unit tests compile, then say the tests succeed. Then this hierarchy can be extended to users of the library, and so on.

Exactly.

Although rather than 'include template headers in random cpp file's, which does feel like dead code (haphazard), I wonder if you could have a dedicated 'interface compile test' cpp file to include them in. At least this way encapsulates the purpose and behavior.

Yes, but who will remember to check if each template is included in such a file? With one header = one cpp file you at least have the problem solved by protocol. Secondly, it's not improper to separate from the templated code the code that can be static, and just called from the template code. This is the code that hasn't got anything to do with the "T" type. The static code will go to the .cpp file in the end anyway.

Human psychology works so, that if the "dead code" .cpp file doesn't exist, they will NEVER start extracting the static parts, because they're lazy or afraid of CMake :)

Ah I see

<UkoeHB> "I think I see what you mean..." <- There is however a possible loophole with the "first local tests compile", as they may be incomplete by: allow for too high degree of freedom, or even the other way around. In the second case you might be limiting a functionality that was expected outside to be there, while still having your UT succeeding.

This somehow touches the myth of having perfect UTs. You can maybe expect this perfection from a compiler, but not from UTs.

The myth is correlated with managers bragging about having 99% code coverage... which is only a HINT, that something is correct, but not proof. They like to dumb things down to their level :)

Thank you for the insights :). Fundamentals really are important wherever you go.

7821 is ready for re-review :)

Will also write a new separate PR for 7798 for next release (one that solves divide by 0 but leaves integer truncation in the code)

Is this commit something that could be merged, or is it DOA (i.e. should I roll it back and move on)? UkoeHB/monero 7596e01

thanks for the update jberman[m]

condolences as well

thank you :)

Thank you, jberman. Condolences, again. I will examine 7821 very carefully. It may take 24-48 hours, since it's not the only thing I have going on right now.

By the way, I see you mentioned me in the comment. Feel free to directly tag me. I am github.com/Rucknium

We eventually need a statistical testing suite for Monero.

^^^^

<Rucknium[m]> "We eventually need a statistical" <- There are a lot of feature-rich Python libraries for statistical tests and stuff.

R's central repository alone (CRAN) has 17,987 packages that, in turn, contain untold numbers of functions. Over 200 of those packages deal with mixture distributions, which is the exact statistical area that mixin selection deals with.

It's not really about whether the function exist. It's applying them in a way that tests the vulnerability of Monero to statistical attack.

With a bit of work, R could probably link directly to the C++ code that Monero runs on, since R has the Rcpp bridge.

vtnerd: what's the status of eventually merging this upstream? github.com/vtnerd/monero-lws

yeah thats a good question, it would have to be reviewed somehow, at least to ensure that there were no obvious privacy leak backdoors, etc

presumably people would trust it more if it were in /monero-project instead?

UkoeHB : put the functions in an anonymous namespace OR declare static in namespace scope (not function scope)

in both cases the comp

the compiler will put those functions in internal linkage only, and the symbols are not exported

Im not a fan of virtual everything interfaces in most circumstances because it adds unnecessary overhead, and if designed properly each header file has small amount of data members

<sgp_[m]> "vtnerd: what's the status of eve" <- Would love to see this more commonly supported and usable

It's a key UX improvement for anyone running their own node and has practically no drawbacks if using with own node.

wallet2 become a do everything class, and the interface added in mj-xmr PR might make that worse (because its not broken into subcomponents)

eve?

> put the functions in an anonymous namespace OR declare static in namespace scope (not function scope)

The part that annoys me (maybe naively/ignorantly) is then you have to forward declare stuff within the cpp file if function order is not sufficient.

I rarely run into that issue, but I don't know whats being implemented for this

sometimes I might have multiple anonymous namespaces, such as `namespace foo { namespace { ... } ... namespace { ... } }`

which might be the kind of thing that annoys you about it

doing the static/anonymous trick is preferable when writing a shared_object since it keeps the symbols down

theres enough maintenance work already for monero to even worry about it yet though (although I still do it where possible)

oh sethsmissons : I see matrix or something cutoff the remainder of the sentence

Hmm

Just saying it's a huge step forward if easy to run

vtnerd: are there any front ends/wallets that can be configured to work with monero-lws currently?

* vtnerd: are there any front ends/wallets that can be configured to work with monero-lws currently? Even something roughly works

mymonero should be usable but requires a valid ssl cert, and the error reporting is currently suspect (it seems to just fallback to mymonero.com when custom domain fails)

the other option is to taking the html from openmonero

the third is using the wallet-cli in light wallet mode

Im not sure if the gui wallet provides an option for that, I should look

Im tempted to create an ncurses (with mouse support) wallet specifically for this purose, and start with a view-only mode to test the concept

I think there is a small niche there, it would be more usable than the existing cli (but less features), and would have minimal dependencies ideally (ncurses instead of qt stack like other more usable wallets)

yeah. fancy ascii programs are cool. would be neat if could somehow make it work on android in a noob-friendly way

do they make ncurses with touchscreen support? :P

I think the niche is smaller than you think.... anyone with their own node should use is

s/is/it

lol, also s/smaller/larger

lol just try again XD

larger niche

Yeah, basically anyone using a home node would benefit from this if most wallets supported it

Mobile wallets most of all

exactly, I already have a device sitting here synching the chain. it might as well take some overhead from my phone

i bet cakewallet & monerojuice would make stuff happen if this was getting baked in

I would gladly donate and drive attention if someone could dedicate time to this.

most touchscreens should appear as mouse events

the trick is handling keyboard input with touchscreens, I have some vague ideas on how to handle that

one thing I would like to try is getting it working on a remarkable2 device or similar

since the viewkey scanning is off-device, the low-end cpu/ram shouldn't matter as much

Imagine an rpc wallet running on your 24/7 node - would it be possible to simply open your mobile wallet and download the local wallet file.. hey presto your mobile wallet is pretty much synched 'instantly'?

yes

Probably with some kind of rsync app running on the mobile device.. Just a thought

Could even download small xdiff files and patch your current wallet file on the mobile device (incase the file is huge)

plowsof[m]: what would be the benefit of that vs a wallet scanning server (aka lws)?

I see... lws is achieving the same effect, so no benefit at all - other than attempting to be a simple solution for smooth brains like myself ^^

I've asked on the other channel but i seems to be less populated, so here it goes: I've built xmr-stak from source but when i run it, I don't see monero as available coin. What's wrong? I'm new to crypto.

Ask in #monero-pools, also use xmrig as it supports monero