Resolve merge conflicts after meta DEx RPC enabler PR #61
Conversation
Should have no functional effect, as parsing transactions is guarded by the `isTransactionTypeAllowed` checks.
This commit adds all missing checks before executing "cancel-at-price", "cancel-all-for-pair" and "cancel-everything". Furthermore the behavior of "cancel-everything" was enhanced, such that it cancels all open orders, if offered and desired properties are within the same ecosystem, and otherwise it cancels all open orders for all properties of both ecosystems.
CMPOffer: - subaction was undefined CMPMetaDex: - still_left_for_sale is already in initializer list - addr.empty() should be addr.clear() (addr.empty() is faulty here) - std::string has default constructor - therefore addr.empty() was removed - other constructor should use initializer list
|
Not yet finished. One moment.. |
OmniLayer#8 touched some parts, which caused merge conflicts for this branch. Conflicts: src/mastercore_rpc.cpp src/rpcclient.cpp src/rpcserver.cpp
dexX7
force-pushed
the
oc-0.10-pr-13-resolve-mdex-merge-conflicts
branch
from
23f8791 to
07100c5
Compare
|
Alright. This seems to do it, even though you may just pull the updated omnicore-0.0.10 branch in yourself. For an easier comparison, the actual merge conflicts can be addressed by the changes of the following commit: dexX7@23f8791 - ... though cherry-picking this one alone doesn't seem to do the trick, because Sorry for the trouble! |
…nflicts Resolve merge conflicts after meta DEx RPC enabler PR
|
No trouble at all :) |
|
Just a quick one to note test plan for MetaDEx passes so likely test plan is insufficient. The UI throws up examples that are easy to spot, for example: There should be matching going on here. Dumping the MetaDEx state we can pluck out a couple of offers that clearly should have been matched/traded: Note they're the same address but this is permitted (quoting spec)
I'm itching to get into the nuts and bolts of MetaDEx but am really trying to get through the work I've been assigned first (which I think is getting there) so sorry I'm not being much help with specifics - figured it's best to note these things even if it's just for myself when I can circle back round to it :) |
|
Well, this was sort of expected.. :) I suggest you keep posting any flaws you find, and pin down the underlying issue (or issues). |
|
I'm confused. A unit price of 20'000'000? Shouldn't it be 0.2 TMSC? Sold 10x IndivisibleToken for 0.2 TMSC each (= 2.0 TMSC total).
|
|
Clearly something wrong there |
|
Note listing sells via the UI is likely still broken (I haven't looked at refreshing sendTrade() from the old stuff from Dec14 yet) |
|
Oh, you're in regtest mode nevermind hehe |
|
Just sent the same transaction from the UI on testnet, 10 indivisible tokens for 0.2 each - looks OK in pending, will see what happens when it confirms: |
|
Ahh nevermind, I thought I'd got all the divisibility display bugs out yesterday but seems a couple still remain... Working on it.. |
|
Hehe, at some point you'll probably look back and wonder: "why didn't I use regtestnet earlier?" :) Todo note to myself: tutorial for spock + some basic, manual regtest stuff. |
Hehe I have no doubt mate, I have no doubt :) Think 0f5baed should sort that price display issue mate. |
OmniLayer#8 touched some parts, which caused merge conflicts for this branch.