-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Events #476
Refactor Events #476
Conversation
cb89c55
to
a987826
Compare
Strange? By no means. "Scope Creep" is a persistent problem, and I agree with your comment. Unfortunately, I committed it before your reminder was read. Consider my wrist slapped. We'll let @dimxy decide if he wants me to put it in another branch. |
This reverts commit de6166b.
No problem, we could put aside NPOINTS and KOMODO_STATES refactoring (but I believe we need to do this one time and add comments as it is not easy to get the idea of those objects but we have to deal with them in code pretty often. Also it seems NPOINTS is never freed) |
#476 (comment) |
Agreed. The link between CURRENCY and komodo_state is pretty weak. I'm thinking the collection of komodo_state should be dynamic. My first reaction is a map keyed on the symbol, but I need to see all the use cases. I believe this and NPOINTS should become github issues. |
Yes a map looks like a great option and improves readability. |
This line: Line 35 in 56590a4
Could be removed as well, as we don't have anything Marmara related anymore. As well as:
Also don't needed now. p.s. To clarify what i doing now - as you probably know we have also Komodo-Qt (KomodoOcean) codebase which is almost similar to original komodod, but with GUI (Qt) part and various improvements. As codebases bit different this PR changes couldn't be easily cherry-picked or merged, so, i transfer changes manually "step-by-step", verifying and checking everything once again. From one side this is additional work and "time waste", but from other side - this is an additional level of checking and testing which wouldn't be superflous in our case, so, don't be surprised if i'll mention this PR in Komodo-Qt changes. |
|
tasks marked as todo are done, except events processing (need move to new implementation) and komodo_mutex transition to std::mutex komodo_notary.h - done komodo_globals.h - done komodo_utils.h - done komodo_structs.h - done (with mixed old and new komodo_state struct) komodo_events.h - done (old events processing -> must move to new) komodo_pax.h - done komodo_bitcoind.h - done komodo_kv.h - done komodo_curve25519.h - done komodo_jumblr.h - done komodo_gateway.h - done komodo_ccdata.h - done komodo_interest.h - done komodo.h - done _stripwhite, clonestr, safecopy - still in komodo_utils.h _stripwhite, clonestr, safecopy - also they are part of komodo_cJSON.c as static functions bits256_str in hex.h as a part of KomodoPlatform/komodo#476
@jmjatlanta Seems found a serious bug, that lead to daemon crash during connecting a block + writing an event to
Let's look on
What we doing in case of
Why earlier (before refactoring) we didn't face with such error? Answer is in old
It was I fixed this error in Komodo-Qt (KomodoOcean) codebase the following way: In this case we can't change |
Yes, this is serious. Thank you for the forensic analysis. I am attempting to determine why I put a 65 there, and it may be because of thinking about the true size of In any case, you are correct in saying that for compatibility reasons, that field must remain 16 bytes, and we are limited to reading 15 of them. I will adjust, test, and look around for similar issues with Update: I now see what I did. I focused on the length of the local |
%.o: %.c | ||
$(CC) -c -o $@ $< | ||
|
||
$(LIBCJSON): cJSON.o komodo_cJSON.o komodo_cutils.o | ||
$(AR) cr $(LIBCJSON) $^ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, about the way how libcjson.a
builds, may be the following approach is more clearly:
https://github.com/DeckerSU/KomodoOcean/blob/5f99d88568e0a49ce654135d59cb8e191f5667cd/src/Makefile.am#L77-L82
# libcjson build
LIBCJSON=libcjson.a
libcjson_a_SOURCES = cJSON.c \
komodo_cJSON.c \
komodo_cutils.cpp
libcjson_a_CPPFLAGS=-fPIC
EXTRA_LIBRARIES += $(LIBCJSON)
it's just like "open discussion" how it would better.
p.s. other tests of this PR still continues on my side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also need to add clean of libcjson.a
on make clean
, like this:
DeckerSU/KomodoOcean@53ddb01
@jmjatlanta Windows build of your repo
I already made a fix for that: Please, push the similar commit into |
include adds various int types support in needed order, without this fix we will have bunch of: In file included from komodo_jumblr.h:28, from komodo_jumblr.cpp:15: uthash.h:895:5: error: ‘uint32_t’ does not name a type; did you mean ‘wint_t’? uint32_t count; ^~~~~~~~ wint_t ... /usr/share/mingw-w64/include/wincrypt.h:240:11: error: ‘ULONG_PTR’ does not name a type; did you mean ‘MAXLONG_PTR’? typedef ULONG_PTR HCRYPTPROV; ^~~~~~~~~ MAXLONG_PTR /usr/share/mingw-w64/include/wincrypt.h:554:5: error: ‘DWORD’ does not name a type; did you mean ‘HIWORD’? DWORD dwVersion; ^~~~~ HIWORD ... etc.
@jmjatlanta Other error with build
Update: Fixed it. Here is the commit with changes: DeckerSU/KomodoOcean@9d59e52 |
Thank you. I currently do not have a working Windows build environment (WIP). I will update this with the status of my testing when (if?) it is done (seems gmp doesn't compile on WSL/Ubuntu 20.04 right now). |
I used |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
secure code reviewed
I would like to use this PR to open a dialog into integrating heavier use of C++ features into the codebase. Comments are encouraged. But please send any comments about what I should or should not be working on directly to me instead of commenting here.
Status as of 2021-08-10: I believe the code sufficiently demonstrates concepts that could be used in further refactoring. I believe the code to be bug-free.
, but not complete, as both old and new ideologies coexist for discussion and testing purposes.More test cases are needed for edge cases that I have as yet not learned about.Points for discussion:
if
statements for error checking, consider using try/catch. This can reduce the code you need to write, as well as provide a performance boost in some instances if done correctly.komdo_
, consider using namespace komodo. This reduces name collisions within the codebase (we know what an "event" is in komdo, and don't have to worry about puting "komodo_" in front of it, or a UI event having a name collision with it). This also often makes using your code as a library less cumbersome.komodo_events.h
file breaks point 9 above. I'd love to get rid of it, as well as big chunks ofkomodo.h
for the same reason. But that would make testing and comparing the existing implementation with the refactor too much to take on in this round. So they will remain until they are no longer needed.#include
files necessary for the.h
. This makes chasing down dependencies less of a problem at the expense of a little compile time. Use#pragma once
to help with this.The above points are simply opinions. I am not here to start wars. If the team decides that any (or all) of these are a bad idea, I'll happily work without using them. Explaining why they are a bad idea helps everyone, but is not required.
My apologies in advance to the reviewers. There is a lot of code movement with (relatively speaking) minor changes. Moving implementations from .h to .cpp touched many seemingly unrelated areas. Doing that in a separate PR would have made both reviews easier, but merging more complicated.
Reading suggestions and References: