I love how the contributor guidelines itself were yolo-merged before anonimal addressed all of moo's comments.

Why we recognize a document that was more-or-less copy-pasted from zeromq is beyond me.

Half of it doesn't even make sense in the context of this project.

<r​brunner7:monero.social> "pasted from zeromq" Just imagine how hard it would have been to find consensus for something new written from scratch ....

can i strip out the supercop components off the build system?

it's causing issues with building it, and it doesn't seem to be a necessary component (since it's just to evaluate the performance of cryptographic algorithms)

(also i'm not gonna push this to upstream, just modifying my copy of monero)

<o​frnxmr:monero.social> > <t​obtoht_> I love how the contributor guidelines itself were yolo-merged before anonimal addressed all of moo's comments.

<o​frnxmr:monero.social> because there were no guidelines and a lot of stuff was yolo merged w/o addressing reviews

<o​frnxmr:monero.social> The C4 was decided on in meetings

surprising how much stuff i have to patch out to make an automated library build of monero

at least, one that would work in meson

(and apparently supercop offers fast cryptographic operations for monero wallets, but has a misleading name that makes it look like it's just there to benchmark cryptographic algorithms)

ofrnxmr: "The C4 was decided on in meetings" <- Yeah?

"A new Contributor who makes a correct patch MUST be invited to become a Maintainer."

Give me a fucking break. Not one person read this thing.

It was clearly read and modified, but clearly not well

I noticed that as well and luigi commented (months ago) that he disagreed with that line. Obviously it hasnt been touched in years

It was implemented in place of a CoC

as you said, it was yolo merged without addressing comments (like many other prs at the time)

Cant be "not read" and have unaddressed comments simultaneously. Back then we had a core team who, by the governance structure, had veto over everything

times change(d)

"Cant be "not read" and have unaddressed comments simultaneously. " <- Moo, the only reviewer, literally says: "I've stopped in the middle". That line appears near the end.

And we have been ignoring it ever since, until you found a clause that aligned with your opinion. Might as well start over if it wasn't done properly the first time.

if you want to go ahead and yolo merge all of your own prs, w/o merge queue, or however you first proposed, go ahead and do it. I'm not your boss

If you dont like my opinion or the clause in the guide, youre free to do whatever tf you want

You're definitely not accountable to me and don't have to pay any attention to my opinion, and i'm definitely free to disagree with setting precedent that we should go back to the days when things were yolo merged

I'm not interested in yolo-merging any PRs. And I do value your opinion.

<j​effro256:monero.social> Cindy: you can't remove it easily, `wallet2` uses the supercop repo for a fast implementation of ECDH when scanning. However, if you refactored `wallet2` I'm sure that you could switch it out for a different implementation, even if that one was much, much slower

nah, i finally got supercop to compile

i removed the "-x cpp-with-assembler" build flag

and renamed consts.s to consts.S

(which made GCC parse it as assembler with C preprocessor)

meson misinterpreted the "set_source_file_proprieties" from CMake's trace JSON, and applied the parameters to all source files within the supercop targets

so that was a hack i had to do

(since meson can't apply specific flags to specific source files within a target)

hello i have faced an issue with debugging monero code in clion, i have set build type as debug but still when i try to jump inside some wallet2 functions i get moved to functions not inside of monero like stl_vector.h, do i have to setup something more to get it to work?

i mean i jump into some random functions inside of stl_vector.h

<j​effro256:monero.social> Are you using `gdb`?

edgzoah has disconnected from IRC

<r​brunner7:monero.social> Probably hit a breakpoint :)

If you use "step into" on some line of code, the debugger will step into all function calls on that line, one by one. It's probably some vector size() calls that get in the way first