linking

monero-wallet-rpc.exe

why GNU ld is very slow for this???

use linux :D

it's a MinGW issue?? :(

i was a Linux cat in past

now im a Windows cat

why does monero-cpp need to build these things???

monero-wallet-rpc.exe and more?

it does a full build

but i don't need them

compiling and linking take so long time :(

i really don't know what is GNU ld doing rn...

then only build the pieces you need

the issue

isn't monero-cpp a library to develop something with Monero features?

why is it building these?

you are doing a full build so it's also building everything

probably i will use monerod.exe right

butt

i could already have that

make sure to read through the full readme, you need the libwallet.a

is there pre-builds of that??

[ 96%] Linking CXX executable ../../bin/monero-gen-trusted-multisig.exe

make[3]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug'

[ 96%] Built target blockchain_prune

[ 97%] Linking CXX executable ../../bin/monero-wallet-rpc.exe

make[3]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug'

[ 97%] Built target gen_multisig

make[3]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug'

[ 97%] Built target wallet_rpc_server

make[2]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug'

make[1]: *** [Makefile:146: all] Error 2

make[1]: Leaving directory '/c/proje/CoinPG/monero-cpp/external/monero-project/build/debug'

make: *** [Makefile:84: debug-static-win64] Error 2

please use a paste website

sorry i thought it is short

it is short because you didn't post the error :D post the full log and use e.g. paste.debian.net

yesss doing that rn

did you sure that you checkout master branch?

which commit exactly?

i didn't

i tried master branch

there was an error

you have to apply monero-project/monero 026dbc8

i just casted a variable and fixed

monero was building but monero-cpp not

then i thought

i should checkout monero-cpp/v0.7.0

let's continue in #monero

it is v0.7.0 rn

okii

Height: 1382556/2632662 (52.5%) on mainnet, not mining, net hash 159.15 MH/s, v5, 12(out)+0(in) connections, uptime 0d 14h 51m 43s

can somebody just mail me the full node? lol

lousiF: do you have an SSD? and do you run the lastest release version?

yes and yes

my node was from an older backup, and I don't think I pruned it right. Decided to just re-download it with --prune-blockchain

running slow

which OS?

buntu jammy now

ok, sounds a bit slow for an internal ssd

it's the ISP

or something with peers. regardless it's gonna take days lol

2022-05-28 00:41:47.402 I [***.222.***.***:18180 OUT] Sync data returned a new top block candidate: 1382556 -> 2632999 [Your node is 1250443 blocks (4.8 years) behind]

2022-05-28 00:41:47.402 I SYNCHRONIZATION started

Received 22961838504 bytes (21.38 GB) in 4601667 packets in 15.2 hours, average 409.85 kB/s = 81.97% of the limit of 500.00 kB/s

Sent 68626586 bytes (65.45 MB) in 55980 packets in 15.2 hours, average 1.22 kB/s = 0.24% of the limit of 500.00 kB/s

have to cap it at 500kB/s or else no internet.

lousiF: Why?

I'm on a DSL connection on the edge of the North American continent.

and if I can't just hog all the bandwidth, it's about half-ish

-if

just an idea/request. I'm impatient, and just mailing it would be faster than downloading the entire thing. I think lots of other people could use the same assistance.

<lousiF> "just an idea/request. I'm..." <- Its not a peer problem if its using 80% of your 500kb/s limit.

Can always check sync_info to see if you have a queue of blocks waiting to sync. If so, the bottleneck is the computer.

Or you can add the flag --sync_pruned_blocks to download prepruned blocks (I imagine should speed up the sync, though I havent used it myself)

#monero:monero.social is a better place for this

I have the output here. don't want to flood

Dm

it's the ISP. it's slow as shit. lol. it is like tin cans and string out here

what is the C++ standard of monero source???

MeowingCat: c++14

okii

im getting these errors

g++ -std=c++14 -I.\monero\monero-project\src\ -I.\monero\monero-project\contrib\epee\include\ -I.\monero\monero-project\external\easylogging++\ -I.\monero\monero-project\external -I C:/msys64/mingw64/include -o main main.cpp .\monero\libwallet_merged.a

my GCC command

Hello, I was wondering is there a reason that the Daemon/Wallet JSON-RPC API is not managed via OpenAPI / Swaggerhub? Would bring huge advantages like versioning, or am I overseeing something? Would gladly help to set up something like this

Same reason it doesn't use any lib it doesn't currently happen to use I guess.

The more invasive changes you want to do to rewrite something, the beter arguments you have to have for why it'll improve monero.

So, first tell us how invasive this'd be, roughly. And second, what the improvements will be (this includes new drawbacks).

If it turns out to be another "rewrite so I like it better that way", it'll be "thanks, but no thanks".

Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at libera.ems.host/_matrix/media/r0/do…31daeb0801fc60d69c98f3fb58f3f0c97bb)

* Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at libera.ems.host/_matrix/media/r0/do…fef30c7f040dc1d6b38dc9e353f9a8f3c56)

* Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at libera.ems.host/_matrix/media/r0/do…dfcb5138503ff7d48b04f712b7d7903845b)

* Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at libera.ems.host/_matrix/media/r0/do…2a6fc3138f320bbfcef8e5cb77c6ee8ea70)

* Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at libera.ems.host/_matrix/media/r0/do…8a58d30426920b3428f9ccfcad896e6cc3c)

* Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at libera.ems.host/_matrix/media/r0/do…6ad41bf89ebe5e3448a8317745bfb35cb33)

Example can be seen here how something might look like: petstore.swagger.io

s/something/this/

s/something/this/, s/petstore/editor/

Note that past major versions of Monero are not compatible with the current network - so when a major version is rolled out, any breaking changes in the rpc api would be "mandatory" too, and the old version would be lost anyway

(Unless the majority of the network rejected the update, for whatever reason)

That is true, but it would still be nice to have this information anyway, you never know when you might use it

* Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at libera.ems.host/_matrix/media/r0/do…b421b517e01bf6a214cb9925713b45ea8b4)

Would anyone be willing to look at monero-project/supercop #9 ? It's a super quick warning fix

Can you please avoid spamming the same over and over ? That's what matrix does when you edit a line.

Also, your comments ends up cut off, and links to a site to see it.

Me ?

No, jonas1423[m]

More documentation is always good.

jonas1423[m]: what is a swaggerhub instance ? It smells like needing some third party.

I mean, we all need third parties. Like GCC. But this looks like a third party which, if it goes, takes our stuff with it. Correct me if I'm wrong, it just reads like it (I never heard of "swaggerhub" before).

The RPC documentation has always lagged and often been incomplete. Fixing this would be nice, but does swaggerhub make it easier to update somehow ? If so, how ?

And I don't mean some automated process that sees I added "uint32_t x; KV_SERIALIZE(X);" and writes "x: 32 bit integer" in the doc, that's useless.

About code generation, do you mean auto generating bindings, like what's in utils/python-rpc/framework, without having to do it manually ? That'd be useful.

Does versioning mean "bumping a version number" or "keeping historical RPC versions" ? If that former, we already have that. If the latter, surely it cannot be automatic since the behaviour of the code that handles the RPC changes. What does it do to help here ?

> About code generation, do you mean auto generating bindings, like what's in utils/python-rpc/framework, without having to do it manually ? That'd be useful.

Yeah, I've never seen it before, but it looks like if you describe the JSON RPC interface it will automatically generate a client API for a bunch of different languages

<moneromooo> "Can you please avoid spamming..." <- Sorry not used to matrix/element,... (full message at libera.ems.host/_matrix/media/r0/do…ac6e4ecc5c5b020c3999c4fa30b1fa11690)

I think something like this would be very good. Maybe there is something like swagger that works well with cpp. the documentation of the wallet rpc is badly out of sync with the code. For example the signing with subaddresses is not mentioned in the docs, but it is actually possible: old.reddit.com/r/Monero/comments/uv…problems_in_web3/i9ryrql/?context=3

spirobel[m]: Yes, thats exactly why something like a swagger-editor would be nice, the documentation on there would be the the single source of truth / the contract, if you change something there, you generate code that automatically (almost completely) adhere to that contract

jonas1423[m]: so the question to figure out: can we make swagger work with cpp? is there a plugin. And if that is not the case: is there an alternative that is similar to swagger that works with cpp.

s/./?/

spirobel[m]: You can try it out on this site editor.swagger.io under Generate Client / Server -> cpprest and look at the generate models. I cannot tell you if that generated code is usable because I am not a cpp developer, but at least it is supported.

So... if still requires someone to write the doc. Just in some web browser instead of another editor.

Keeping old RPC versions could be interesting from time to time, but usually isn't. Most RPC stay backward compatible.

The code generation thing seems to be the one advantage I think.

moneromooo: as I understand it swagger is written as a comment with @swagger in the source code. So the source code and the comment right next to it is the single source of truth. From that the docs website is derived ( where you can autogenerate the api consumers etc)

Oh, like doxygen (which usually results in placating boilerplate) ?

I mean, if the issue is people (well, mainly me) not documenting things, adding this won't fix it, will it.

moneromooo: I dont know if I would call this placating boilerplate. It is helpful to have a way to automatically generate api consumers.

moneromooo: I have used doxygen like one or two times but I think that are completely different things

moneromooo: I mean it is just adding a comment above every api endpoint to state what variables it expects and what they mean. I dont think that is too much to ask.

It's not documentation it's specification, you write the api, generate code (the models, the single source of truth) and write your consumption / providing of this API

spirobel[m]: it is irrelevant.

This tool relies on the doc being written already, if I read the above correctly.

The doc is not written currently. Therefore adding the tool will not help.

moneromooo: yes

If you're going to say "if we add the tool, people will suddently start writing documentation", then... maybe, but why do they not without the tool ?

jonas1423[m]: I think you can go about it multiple ways, right? you can write the server code and add the comments there and then client code and specification of the website is generated from that. Or you write the specification in yaml and then generate client and server code from that. In our case server code is already written. So just adding the comments is probably the right approach. Just a guess.

Anyway, this is my opinion so far. If others want this, it'll go in.

spirobel[m]: I have only seen it in the one direction (spec -> server/client) and not the other way around, but if it works sure

I have used open api before to generate typesafe clients for a http service - it is very useful. However, IMO there should be a seperate project which maintains the open api definition, and perhaps generates clients for various languages as part of a ci action...

do you guys think there is maybe a slow way to move into this? maybe just add one of these comments for one api endpoint and see if it works? It does not need to be done all at once. Even one comment is a step forward.

moneromooo: If we go this further down this road, we are closing the doors for new developers that want to consume the daemon/wallet api and build monero applications, that is the real reason I am proposing this here. For example if someone wants to create a new Wallet-GUI on top of the daemon-rpc

at the moment in c# i have a very basic program which reads the rpc header files from github and generates the models - but i've seen projects which parse C++ code into an AST which you can then run a script over to grab the models, that way it's always in sync with the codebase

but instead of emitting c# code (which i have it do atm) you can generate the api definition

What we could try is the following:... (full message at libera.ems.host/_matrix/media/r0/do…82b9ac6ef0332ba852944f82a45ccf9add6)

> <@jonas1423:matrix.org> What we could try is the following:... (full message at libera.ems.host/_matrix/media/r0/do…a1165a4905b0be2f1fa0761ce1fb06b1b5b)

spirobel[m]: I can try to transfer the code to the api-specification

I am not a cpp developer but I am bored and want to try :D

jonas1423[m]: but can you continously do that? because the code will change so your api-spec will be out of sync at some point. you dont need to be a cpp dev. You just need to add some comments to the code if you want to try this.

the monero source code for RPC is so well structured even primitive regex approach (like used here) can get the models out okay, something like (github.com/xoofx/CppAst.NET) would be more robust - from there just need to adapt to emit open api sepc

That's the problem, I can set it up initially, but then every time a dev adds a new piece of code to the public API, he should additionally add the open-api comments for that. OR we change the source of truth from code to spec at some point. What I want in the end is that everyone can build up new monero applications on top of the wallet/daemon rpcs easily

jonas1423[m]: I dont think the source of truth can change from code to spec. Probably best to add comments. or do the parsing thing by Henry Hollingworth

Yea, also writing the openapi-comments to public-api can be enforced by pipelines. As I said no matter the approach (source of truth code or openapi-spec) I can help set it up initially, as long as we have a feasible, correct documentation in the end. I will go off for a few hours, let me know if I can help with anything

Putting effort into making open api spec makes a lot more sense than everyone duplicating that effort to make a wrapper in each language which can easily fall out of sync etc.. vs write once and generate the really good tooling around it

jeffro256[m]: that s/64/85/ thing looks really odd. Why do you need this, if the extra isn't used ?

(it's not immediately obvious why after looking at the code)

I assume sc25519_window4 can use more in some cases, but never when called from that ?

(it doens't AFAICT, I just looked)

> <@jonas1423:matrix.org> Well, the JSON-RPC API itself does not have to change, I only speak about the documentation / specification about the api. Basically, my proposal is to replace this page on the website: getmonero.org/resources/developer-guides/daemon-rpc.html with a swaggerhub instance.... (full message at libera.ems.host/_matrix/media/r0/do…3a26a1e21abd7bb0877f831ed1fffaf6536)

> jeffro256: that s/64/85/ thing looks really odd. Why do you need this, if the extra isn't used ?

Because GCC is strict about buffer overflows and will generate a warning message if size of a passed array isn't actually the full size as the array parameter.

I do not see why this applies here. The function takes 64, it's passed 64.

You're talking about b, presumably?

Yes, the applicable definition is in crypto_sign/ed25519/amd64-64-24k/sc25519.h line 59

I think the amd64-51-30k version only takes 64, but amd64.c.inc should just use the one that is greater

Oh. I see.

I looked that C file, which has 64 (and doens't seem to use above that).

I assume there's some cpp cleverness to redirect to another function that actually uses 85 ?

So should the definition be changed?

Well, I assume something uses up to 85 now that you pointed it out.

I just don't see what, but I don't really want to go through the cpp rabbit hole :D

At first glance, the prototype just looks wrong. But it's more probable I'm wrong.

git doens't even help, it's been 85 forever :/

There's a window3 which takes 85. Looks like possibly a copy/paste error.

So I think it's a mistake in the prototype. Your chance to get a patch in supercop maybe :D

No yeah you're right, the definition only uses 64 and the author who used the function expected that it takes 64, so the odd one out is the prototype

That's true of both bodies of sc25519_window4

Assuming no cpp malarkey I saw this and that made me think it might redirect to others: #define sc25519_window4 CRYPTO_NAMESPACE(batch_sc25519_window4)

If you found all and they're all 64 (which seems likely), then just fix 85.

I think they did that so that the symbols of the functions don't conflict

Like the calling code looks the same but it's a different symbol underneath, which is pretty clever

I think that's basically how C++ namespaces work under the hood lol

(and it'd be nice if you could also PR upstream, also gets confirmation it's something more subtle/clever)

True, does SUPERCOP have a public git repo ?

I assume so, since we got it. Maybe ddg one of the commit hashes.

Hello, Monero Dev community.

I’m new here and I really want to contribute to Monero.

What a college student currently studying JS/React/Node can do to contribute to Monero?

Should I pursue C++ instead?

Hi.

If by "pursue" you mean "get a course about", then that's up to you really. I *assume* your college is not led by morons, and that "JS/React/Node" is a tool for implementing stuff, rather than learning just those by rote.

If it's the former, you'll get the ideas and principles just fine, and getting C++ on top is just another layer you can add later.

If it's the latter, then you should probably change college.

Javascript is close enough to C++ (AFAIK) that if your teachers are more about the concepts rather than syntax, stuff will carry over well enough.

"close enough" only syntax wise

In any case, you likely won't be able to contribute meaningfully in the short term anyway, whether you switch or not.

OK, the idea of Javascript I have is from like 20 years ago :D

And it was really pretty similar.

Just a shitter version that runs in a browser.

OK. maybe not 20...

The reason I mention that is that I've seen people being taught "MS word" and not getting any of the concepts, just a rote "click here if you want to make text larger" and having no clue what to even do when using another word processor (can't recall which).

If you're learning the concepts, it's all good.

one of the big differences is that c++ is a strongly typed language whereas JS is weakly typed

I understand I’m too green to have an impact. But I want to start this long journey

Then again, you could also look at Haveno, a monero related project that uses JS.

Maybe you can help a bit earlier.

moneromooo: Could you point out where to start from?

plus C++ compiles to native code and has access to underlying hardware, and Javascript is interpreted and has things like 'eval'. So language conceptions are quite differents.

For monero ? I usually tell people to use it, then find some small thing that's broken or unwieldy, and focus on fixing just that part.

That's small enough, gives you an attainable goal, and you get to learn what's where.

moneromooo: For Haveno

Ah, then join #haveno-dev and ask. I never tried to even build it.

The user interface is here: github.com/haveno-dex/haveno-ui. The matrix room for development-related discussions is at #haveno-dev:haveno.network 🙂

edo.ca ^

the user interface is in javascript, the core in Java, but we are also building a library in typescript: github/haveno-dex/haveno-ts

any help would be greatly appreciated 🙂

ErCiccione: Are you currently working in the Haveno project?

edo.ca: yes, i am part of the core team

Thank you guys for all the answers. Since Haveno uses JS, I might be more useful to that project.

I’ll join Haveno room and keep in touch with ErCiccione, but I still keep my eyes in this room too

ninja: error: '../external/monero-project/build/release/src/crypto/wallet/libwallet-crypto.a', needed by 'libmonero-cpp.dll', missing and no known rule to make it

Your makefile... or... ninjafile or whatever... seems borked. You get to fix it :)

Anyway, not a monero bug AFAICT. These files aren't monero's.

(except libwallet-crypto.a)

i didn't change them

just got from Github

Ah, if it's someone else's project, ask them. libmonero-cpp.dll isn't monero. Unless something got added when I wasn't looking ?

ummmm

it is monero-cpp

And we don't use ninja either.

i don't like Ninja, CMake and others

just love GNU Make

and using relative include paths

Well, check who wrote this. Maybe they're here, maybe not.

relativeeeeeeeeeeeeeeeeee

:(

sorry buttt

this thing made me crazy

because i don't understand people

Best is to file a bug in their repo, after searching issues to see wheter it's already reported.

people are crazy for include paths

a/b/c/meow.h butttt sometimes -I a/b/c and #include "meow.h" sometimes -I a/b and #include "c/meow.h"

i understand why someone are making frameworks and shits when i see these

That will not cause your problem above.

i really don't understand %90 of native softwares are not buildable

sometimes defining some preprocessor things in build scripts and pass to compiler and more more more

im about to crazy

Monero source is not portable :(

because of these reasons

OK, you're being very useful, thank you. We will give your feedback the attention it deserves.

looooks like this monero-cpp thing is used by monoero-java and monero-javascript bindings

Ah, that might be woodser then.

the issue

I assume you read the README or BUILDING files (or similar) ?

i need Windows, Linux, Android, iOS builds

im doing that what the README.md says

Well, good luck. Build systems tend to be a massive pita.

tried everything

That's why people make more. They love adding more pita.

:(

Godot's build system is very complicated too but it is used to be very cross-platform

it is tested on everywhere

"very complicated" <- you see ? pita

but i think nobody used monero-cpp before

except monero-java and monero-javascript

Anyway, either go to the issues page of that project, or ask the ninja people if you want to fix it yourself.

(I recommend the former)

Oh, one thing.

as i understand

A shot in the dark, but: I see ".dll". Windows has always been a fucking annoying different pita.

libwallet-crypto.a is a part of Monero's building

yesss im building it on MSYS2

One common issue is if you have a space (or other "uncommon" character) in a directory leading to that. If you do, try fixing that first.

im making a wallet app with Godot Engine

i wrote ETH and BTC parts in C#

i will use C++ for Monero part

Nice. I made one with the urho3d engine :D

oh what is that

It's another game engine.

looooking rn

its editor loooks good

UrhoSharp.....

is that .Net 6?

It's some port for... forget the name... Miguel de Icaza's .net compat thing for linux. It's unmaintained AFAIK.

interesting

Godot devs are working on .Net 6 for Godot 4

And even if it were, it should not be used. I suspect it's a now dead trojan horse for MS to fuck with linux again.

Unity is stucked in .Net Framework 4.7 shit

Godot's cross-platform abilities are great

its UI system is good too

Godot editor is a Godot game

is there a built .dll of monero-cpp?

Who knows. Maybe look on the project's github releases page.

there is a big code but can't build lol

ohhh my question

isn't libwallet-crypto.a a part of Monero?

It is.

i think it is

monero-cpp is using Monero

building it

Good choice.

and linking statically its things

butttt why not creating a libwallet-crypto.a?

maybe just build it on linux

or install wsl

buttt i need Windows build

MeowingCat: can you try building release-v0.17 branch?

Windows, Android and iOS

in the monero submodule

Dunno. Maybe you should check the project's github page.

@MeowingCat monero-cpp's makefile currently assumes a *nix environment. it's an open issue to support Windows, which means expecting *.dll instead of *.a build artifacts: monero-ecosystem/monero-cpp #10

selsta, 0.17 of external/monero-project?

tryinggg

MeowingCat: maybe there is a way to cross compile it

if you're able to, I'd first confirm the build process in linux since you're targeting that platform too, and I'd like to support Windows with the necessary modifications to CMakeLists.txt

i just took a look for cross-compiling

buttt build scripts are designed for building Windows binaries on MSYS2

how could i cross-compile it??

i tried linking statically libwallet.a thing

buttt epee lib is giving errors

i have no idea

what is libwallet.a?

and libwallet_merged.a?

g++ -std=c++14 -I.\monero\monero-project\src\ -I.\monero\monero-project\contrib\epee\include\ -I.\monero\monero-project\external\easylogging++\ -I.\monero\monero-project\external -I C:/msys64/mingw64/include -o main main.cpp .\monero\libwallet_merged.a;

i tried this

These are monero libs as well.

buttt epee library has errors

Ah, that one might be our problem :)

when i build Monero i got libwallet.a and libwallet_merged.a

those are static libraries built in monero-project which monero-cpp links to

i have them

but can't link

epee library has source in headers

these errors

it can be build with Monero's build scripts

must be a way

i have no idea

there are tons of thirdparty things, build systems and more and more :(

:(((((((((((((((

it should be built against the release-v0.17 branch if you aren't already

i hoooope

im gonna try

building this ruins my CPU

how can i clean build things?

removing build directories

monero-cpp/build and monero-project/build

is there another thing i should remove?

that should be it

looooks like

some submodule targets

are not existed in repo

or there is something else wrong

i did checkout to v0.17

you did `git submodule update --init --force` ?

yes that's the one who giving errors :(

post the error

fatal: uzak konum hatası: upload-pack: not our ref 4c700e09526a7d546394e85628c57e9490feefa0

fatal: 'external/miniupnp' altmodül yolunda getirme yapıldı; ancak 4c700e09526a7d546394e85628c57e9490feefa0 içermiyor. Bu işlemenin doğrudan getirilmesi başarısız oldu.

you ran this in the monero-project submodule, right? first thing is to get monero-project building before monero-cpp

yes

git submodule sync

ohh

okiii

doing "make release-static-win64"

my CPU is gonna cry now

error :(

woodser[m], selsta

can youuu looook???

so previously you tried master and now release-0.17?

yes

idk if it was master

i tried master of monero-cpp

idk what is monero-project's submodule revision of monero-cpp/master

it's the release-v0.17 branch

Dalınız 'origin/release-v0.17' ile güncel.

im on release-v0.17

getting monero-project to build is the first step. that's completely separate from monero-cpp. I don't know what the cause of the errors are from your log, for example: keyvalue_serialization_overloads.h:388:193: error: incomplete type

okiii trying

hey, should i be unable to fork repos on repo.getmonero.org? right now the button is disabled and when i hover over it, it says i have reached maximum amount of projects, even though i don't have any

Gimme your login there, I'll fix it.

it is built

buttt

It's the defalt when you register from github, and I've not found how to change that default.

build directory is different

there is a MINGW64_NT-10.0-22000/release-v0.17/release

how should i build monero-cpp with this?

moneromooo: yeah i used github's sso

i'm MasFlam on there too

damn DLL is not there again

i feel like i should implement Monero myself

i need HD wallet things

address generation things, building and signing TXs

and i will broadcast

masflam[m]1: fixed

we need a pure C++ library

without millions of dependencies

damn C++ things

moneromooo: thanks a lot :)

everywhere is warning

C++14, C++17, C++XX, C++XXXXXXXXXX

more and more bloated

C++ should not be existed

build systems tooo

:(

package systems tooo

C with relative include paths and GNU Make is enough

and Monero must have a C library instead of C++ because it is a basic thing

that's why very basic things have C interfaces

like OpenGL

wait, try the following

True. Could even unify it all with ioctl. Much simpler.

lol

In UNIX, everything's a file. So we could make it so much simpler by replacing everything with ioctl.

Damn. You saw the sarcasm already. I must try harder.

:P

GNU libc is abstracted

for many things

try to revert this in master branch

meaning add these lines again

this loooks merged

yes, revert it

don't i already have this?

"revert" means "undo".

ie, git revert CMMITHASH.

ohh this changed again?

(then you can reset --hard HEAD^ later)

since merged?

okiii

now i have release-v0.17 branch as built

this is only relevant for master

but its build/ directory is different

isn't there a windows DLL or a static object in this build?

that i could use

what are libwallet.a and libwallet_merged.a?

i have them

but Monero source is not designed to be portable

or there are something else

when i try to link libwallet.a statically i just get epee library errors

i don't have an idea really

if it has errors

because you also have to link against epee as far as i know

how could it be compiling in Monero repo????

im passing -std=C++14

i need non-dependent types for header

somehow

to use libwallet.a

but it has classes, structs and things from everywhere

like other parts of source or booooost

this is what the gui is doing, it just links again wallet_api and everything works

or another thing

i could just use CLI executable

butttt iOS doesn't allow that

you can try to look at the cakewallet source code, they build for iOS and Android

they use libwallet directly, not monero-cpp

im feeling like shit

hmm, and now i can't clone over ssh even though i added the key

it looks like implemented in pure JS right?

masflam[m]1: ssh cloning doesn't work

im thinking about implementing Monero in GDScript

some cloudflare limitation?

it is very abstracted

just one click and export everywhere

and lightweight

so i should just use https and auth with login+pass

yes

Cake Wallet thing loooks good

i think it is implementing everything in JS

Yes, ssh via cloudflare doesn't work, IIRC it needs running some cloudflare proxy on the server, and I don't want to touch cloudflare stuff.

i need to know Monero's math

success, again thanks

something like elliptic curve shit

is there a clean doc about this?

address generation

TX structure

and signing

zero to monero is best i know

loooking

oh too long

i don't like long docs

i believe computer science is simpler

less text is more explaination

maybe im about to go crazy

you can't explain the entire cryptography behind monero's privacy tech on one page

I'd suggest you take refuge in the C spec, but it's a huge doc...

after alllll im not a elliptic curve cat

inventing all of these sounds easier to me

i know it is not exactly

but i mean

approaching specific things from outside

is always harder than approaching from zero for me

maybe i have to drink more cola

this thing must be applying something scalar parts of things continuously

and something like that

but what exactly

and white background docs are making me crazy

I especially hate those when text is also white.

ohh

(actually true, some websites do that (well, not quite white, but light grey))

white background doesn't motivate me

why don't you have a .Net thing?

it would be very nice

You know who made that, right ?

made what?

.net

ohhh

right

butt Godot has .Net Framework 4.7 shit

and it is cross-platform except C# tasks

damn tasks are threads

they are not supported on WebAssembly

i never like .Net

i heard about .Net tasks are supported on WebAssembly in .Net 6

for Godot/Mono there are some good things

Godot has so much things like HTTP client API

.Net Framework 4.7 shits don't support WebAssembly butt you can use Godot's API

they are cross-platform

just using XmlHttpRequest thing on WASM

i have to calculate things

what is the best way

understanding damn cryptographic things and implementing them all

or making monero-cpp to work on Windows, Android and iOS somehow

or using static objects of Monero somehow

damn elliptic curve

i have to find the shortest way

but i will master that damn thing in future

figuring the build system issues out will be significantly easier obviously

im curious about that

implementing a wallet + cryptography is a huge task

because my strongest argument is approaching things from zero is always more clean and pure buttt of course it just could be built somehow in a very short time

but how

is the dev of monero-cpp here??

y^{2}\ =\ x^{3}+ax+b

elliptic shit

y^2 = x^3 + 7 secp256k1 shit

oh damnn

Monero is using ed25519

GDScript's int is 64 bit

i still need to write Monero part in C++ or maybe C# too

or writing a big integer implementation for GDScript

MeowingCat: you could just use my library

monero-core-custom and monero-core-cpp

the entire point is to make monero embeddable

oh looking

cant get away from stripping deps and factoring it how i did

it's not like it was a product of my imagination ;p

MeowingCat: ok well the version i released under mymonero got badly modified IMO

starred the repo

i'm about to publish a version i've been maintaining for 2 yrs in private

<3

can this thing be compiled on Windows?

for Windows, Android and iOS targets :(

yep

yayy

looking

:)

my version also keeps up-to-date with mainline