* Standardize names of LedgerConsensusImp members
* Rework visitStoredProposals
* Clean up mapComplete
* Move status helpers out of LedgerConsensusImp
* Move applyTransaction out of LedgerConsensusUmp
* Clean up applyTransactions
* Change state_ to Invalid if inner node types mismatch
* flushDirty before unsharing to ensure modified nodes get written
* Remove unnecessary code
* Fix updateHash for V2 inner nodes
* In descend, call isInconsistentNode only if node is found
* getMissingNodes could request duplicates in some cases
* An invalid node with the right hash is useful, it proves the map invalid
cmake support in rippled. Currently supports:
* unity/nounity debug/release
* running protobuf
* sanitizer builds
* optional release build with assert turned on
* `target` variable to easily set compiler/debug/unity
(i.e. -Dtarget=gcc.debug.nounity)
* gcc/clang/visual studio/xcode
* linux/mac/win
* gcc 4 ABI, when needed
* ninja builds
* check openssl for acceptably recent release
* static builds
TBD:
* jemalloc support
* count
Notes:
* Use the -G"Visual Studio 14 2015 Win64" generator on Windows. Without
this a 32-bit project will be created. There is no way to set the
generator or force a 64-bit build in CMakeLists.txt (setting
CMAKE_GENERATOR_PLATFORM won't work). The best solution may be to
wrap cmake with a script.
* It is not possible to generate a visual studio project on linux or
mac. The visual studio generator is only available on windows.
* The visual studio project can be _either_ unity or
non-unity (selected at generation time). It does not appear possible
to disable compilation based on configuration.
* Language is _much_ worse than python, poor documentation and "quirky"
language support (for example, generator expressions can only be used
in limited contexts and seem to work differently based on
context (set_property can set multiple values, add_compile_options
can not/or is buggy)
* Could not call out to `sed` because cmake messed with the regular
expression before calling the external command. I did not see a way
around this.
* Makefile generators want to be single target. It wants a separate
directory for each target type. I saw some mentions on the web for
ways around this bug haven't look into it. The visual studio project
does support debug/release configurations in the same project (but
not unity/non-unity).
basic_headers no longer combines fields with the same name by appending
a comma and concatenating the two values together. This was breaking
certain header fields which expect each value to be distinct, such as
the "Set-Cookie" header.
Now the container behaves more like a multi set with respect to insertion
of multiple values with the same field name. Additional member functions
are provided to provide extra functionality.
in addition to passing ${CMAKE_THREAD_LIBS_INIT} to the linker, this
interface library will also add -pthread to the compile options when
supported
Signed-off-by: Casey Bodley <cbodley@redhat.com>
Log thread name and exception type on unhandled exceptions and use a
terminate handler to get a stack trace that includes the function that
thows the exception.
This solves a problem where clang and gcc locate the deleted
version of teardown and async_teardown instead of the overloaded
version. It requires overloads to add `teardown_tag` into the signature
so that the rules for argument dependent lookup can find the
right function. Improve documentation of teardown requirements
The documentation is updated to clearly explain the need for including
<beast/websocket/ssl.hpp> to use SSL streams with WebSocket.
The default implementations of teardown and async_teardown now use
static_assert to alert the user of improper usage, with comments
providing guidance for resolving the error.
The example HTTP server is updated to provide the correct MIME-type.
It no longer uses the now-deprecated http::stream class, since that
implementation does not provide flow control. A new example async_write
function is provided in the asynchronous server for managing the
lifetime of a message sent asynchronously.
The logging is thread-safe, and a bug causing connections to
malfunction is fixed.
This fixes a problem where a call to read() is ambiguous because
the argument list contains objects from both boost::asio and
beast::http.
Users invoking read may need to do so fully qualified, by writing:
beast::http::read(...);
Constructing a Stream from a Sink would elide specifying the
Severity level of the Stream. That constructor is removed so
if a Stream is constructed from a Sink the Severity must be
specified.
Previously, writes using debugLog() tagged every entry with
"TRC:". Now users of debugLog() must specify the severity
level they want their information logged at.
