From 6108bedab4f6597ccf632280f46f3b599177ae4f Mon Sep 17 00:00:00 2001 From: Michel van Kessel Date: Wed, 23 Feb 2022 19:12:25 +0100 Subject: [PATCH] Rename to Blackcoin --- .github/ISSUE_TEMPLATE/bug_report.md | 2 +- doc/developer-notes.md | 28 ++++++++++++++-------------- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index bc36f19810..0844b3e816 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -9,7 +9,7 @@ assignees: '' diff --git a/doc/developer-notes.md b/doc/developer-notes.md index 583c50a763..db01fad4d4 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -24,7 +24,7 @@ Developer Notes - [Threads](#threads) - [Ignoring IDE/editor files](#ignoring-ideeditor-files) - [Development guidelines](#development-guidelines) - - [General Bitcoin Core](#general-bitcoin-core) + - [General Blackcoin More](#general-bitcoin-core) - [Wallet](#wallet) - [General C++](#general-c) - [C++ data structures](#c-data-structures) @@ -140,7 +140,7 @@ Refer to [/test/functional/README.md#style-guidelines](/test/functional/README.m Coding Style (Doxygen-compatible comments) ------------------------------------------ -Bitcoin Core uses [Doxygen](https://www.doxygen.nl/) to generate its official documentation. +Blackcoin More uses [Doxygen](https://www.doxygen.nl/) to generate its official documentation. Use Doxygen-compatible comment blocks for functions, methods, and fields. @@ -276,7 +276,7 @@ see [test/functional/](/test/functional) for tests that run in `-regtest` mode. ### DEBUG_LOCKORDER -Bitcoin Core is a multi-threaded application, and deadlocks or other +Blackcoin More is a multi-threaded application, and deadlocks or other multi-threading bugs can be very difficult to track down. The `--enable-debug` configure option adds `-DDEBUG_LOCKORDER` to the compiler flags. This inserts run-time checks to keep track of which locks are held and adds warnings to the @@ -387,7 +387,7 @@ See the functional test documentation for how to invoke perf within tests. ### Sanitizers -Bitcoin Core can be compiled with various "sanitizers" enabled, which add +Blackcoin More can be compiled with various "sanitizers" enabled, which add instrumentation for issues regarding things like memory safety, thread race conditions, or undefined behavior. This is controlled with the `--with-sanitizers` configure flag, which should be a comma separated list of @@ -509,7 +509,7 @@ Ignoring IDE/editor files In closed-source environments in which everyone uses the same IDE, it is common to add temporary files it produces to the project-wide `.gitignore` file. -However, in open source software such as Bitcoin Core, where everyone uses +However, in open source software such as Blackcoin More, where everyone uses their own editors/IDE/tools, it is less common. Only you know what files your editor produces and this may change from version to version. The canonical way to do this is thus to create your local gitignore. Add this to `~/.gitconfig`: @@ -539,9 +539,9 @@ Development guidelines ============================ A few non-style-related recommendations for developers, as well as points to -pay attention to for reviewers of Bitcoin Core code. +pay attention to for reviewers of Blackcoin More code. -General Bitcoin Core +General Blackcoin More ---------------------- - New features should be exposed on RPC first, then can be made available in the GUI. @@ -737,7 +737,7 @@ Strings and formatting - For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers. - - *Rationale*: Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion. + - *Rationale*: Blackcoin More uses tinyformat, which is type safe. Leave them out to avoid confusion. - Use `.c_str()` sparingly. Its only valid use is to pass C++ strings to C functions that take NULL-terminated strings. @@ -959,12 +959,12 @@ Subtrees Several parts of the repository are subtrees of software maintained elsewhere. -Some of these are maintained by active developers of Bitcoin Core, in which case changes should probably go +Some of these are maintained by active developers of Blackcoin More, in which case changes should probably go directly upstream without being PRed directly against the project. They will be merged back in the next subtree merge. Others are external projects without a tight relationship with our project. Changes to these should also -be sent upstream, but bugfixes may also be prudent to PR against Bitcoin Core so that they can be integrated +be sent upstream, but bugfixes may also be prudent to PR against Blackcoin More so that they can be integrated quickly. Cosmetic changes should be purely taken upstream. There is a tool in `test/lint/git-subtree-check.sh` ([instructions](../test/lint#git-subtree-checksh)) to check a subtree directory for consistency with @@ -1001,7 +1001,7 @@ you must be aware of. In most configurations, we use the default LevelDB value for `max_open_files`, which is 1000 at the time of this writing. If LevelDB actually uses this many -file descriptors, it will cause problems with Bitcoin's `select()` loop, because +file descriptors, it will cause problems with Blackcoin's `select()` loop, because it may cause new sockets to be created where the fd value is >= 1024. For this reason, on 64-bit Unix systems, we rely on an internal LevelDB optimization that uses `mmap()` + `close()` to open table files without actually retaining @@ -1027,14 +1027,14 @@ details. ### Consensus Compatibility It is possible for LevelDB changes to inadvertently change consensus -compatibility between nodes. This happened in Bitcoin 0.8 (when LevelDB was +compatibility between nodes. This happened in Blackcoin 0.8 (when LevelDB was first introduced). When upgrading LevelDB, you should review the upstream changes to check for issues affecting consensus compatibility. For example, if LevelDB had a bug that accidentally prevented a key from being returned in an edge case, and that bug was fixed upstream, the bug "fix" would be an incompatible consensus change. In this situation, the correct behavior -would be to revert the upstream fix before applying the updates to Bitcoin's +would be to revert the upstream fix before applying the updates to Blackcoin's copy of LevelDB. In general, you should be wary of any upstream changes affecting what data is returned from LevelDB queries. @@ -1183,7 +1183,7 @@ A few guidelines for introducing and reviewing new RPC interfaces: RPCs whose behavior does *not* depend on the current chainstate may omit this call. - - *Rationale*: In previous versions of Bitcoin Core, the wallet was always + - *Rationale*: In previous versions of Blackcoin More, the wallet was always in-sync with the chainstate (by virtue of them all being updated in the same cs_main lock). In order to maintain the behavior that wallet RPCs return results as of at least the highest best-known block an RPC