iotaledger / entangled Goto Github PK

Currently, two logging facilities are being used in different branches.

• https://github.com/embear/logger that turned out not being thread-safe so locks were added on top of it
• A thread-safe logger facility that was made from scratch

This issue aims at merging the best out of the two current logger facilities

Via Boost.Beast or CURL

• Write a script that generates CROSSTOOL files for toolchains from https://toolchains.bootlin.com
• Generate a few such CROSSTOOLs and add to testsuite.

This is necessary for targeting & testing other architectures.

On the same model than the generic queues

• Command line arguments (#146)
• Configuration file

Transaction is defined as a struct in cppclient (api.h) as well as a class in common/model (cpptransaction.h).
Although they are in different namespaces, it is impossible to use both non-namespaces names together in the same source file.
See api_json.cc for an example where the fully qualified name of the Transaction class was used.

Could we add a description, tags and general readme to the repo?

Methods that can fail should return an error code and take output targets as parameters.
We need to define the relevant error codes in an enum and make sure that existing code uses/returns them.

In tanglescope/common/tangledb.hpp line 5, the include is not found on OSX.
Can it be changed to <nonstd/optional.hpp> instead?

We should be able to use --define to toggle the encoding until proper support has been merged into upstream bazel.

https://docs.bazel.build/versions/master/be/general.html#config_setting

At the moment, the trit_array encoding is hardcoded in bazel buildfile

Different deployment targets require different storage backends for a functioning IOTA node.
As such, we need to abstract the actual storage layer for higher-level (i.e. networking operations)

• Design storage abstraction layer
  This can be as simple as

extern retcode_t iota_stor_store(const trit_array_p hash /* = key */, const trit_array_p value /* = tx data */);
extern retcode_t iota_stor_load(const trit_array_p hash /* = key */, trit_array_p into);

However, we also need to have a means of storing metadata (e.g. arrival time, consensus data, ...)

extern retcode_t iota_stor_metadata_store(const trit_array_p hash, const trit_array_p metadataKey, const trit_array_p value); 
extern retcode_t iota_stor_metadata_load(const trit_array_p hash, const trit_array_p metadataKey,  trit_array_p into); 

Questions:

• Where and how is concurrency handled?
• Do we need to store more than this? IRI has 5 different 'tables' or so

• Implement storage abstraction layer

• Do we need helper methods here? Probably for transaction stuff at the least.

• Implement in-memory storage

• Just do a std::unorderd_map?

Potential users:

• TangleScope

We need a CROSSTOOL that targets emscripten.

In order to perform unit test, I consider to introduce Google Test. Which target would be the appropriate environment for unit tests to interoperate with? Mainnet with snapshot or testnet?

Currently, we default to all CPU cores. There should be a PearlDiverOptions struct or similar.

MAM merkle tree currently uses recursion in mam/v1/merkle.c for traversal.
This makes debugging hard as no TCO happens

• Fix 32bit compatibility issues
• Enable CI build & tests with i686 bootlin toolchain

This is because width/lambda should be a constant

currently, we support 1/4/5 trits per byte. trytes would be 3 trits per byte.

In cclient/system.h line 19, type uint is not defined when compiling on OSX.
I suggest changing that to a more compatible type, such as uint32_t or uint64_t.

you need to allocate the actual array first before putting it into a struct for consumption by cclient. This is not very nice...

Design / Implement macros to define atomic_handle_t types, that depends on a type, and its associated functions