From c6b53010acad1fc071d6afb52ff45179c00396a7 Mon Sep 17 00:00:00 2001 From: Ehnamuram Enoch Date: Fri, 28 Nov 2025 17:06:04 +0100 Subject: [PATCH] Fix various typos, spelling mistakes, and grammatical errors in design.md and source code comments. --- doc/design.md | 2 +- include/mp/proxy-io.h | 2 +- include/mp/proxy-types.h | 12 ++++++------ src/mp/gen.cpp | 2 +- src/mp/proxy.cpp | 6 +++--- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/doc/design.md b/doc/design.md index fbc8d3d3..113cafc4 100644 --- a/doc/design.md +++ b/doc/design.md @@ -199,7 +199,7 @@ If this is the first asynchronous request made from the current client thread, ` 3. Create a local `Thread::Server` object for the current thread (stored in `callback_threads` map) 4. Set the local thread capability in `Context.callbackThread` -Subsequent requests will resuse the existing thread capabilites held in `callback_threads` and `request_threads`. +Subsequent requests will reuse the existing thread capabilities held in `callback_threads` and `request_threads`. **Server side** (`PassField`): 1. Looks up the local `Thread::Server` object specified by `context.thread` diff --git a/include/mp/proxy-io.h b/include/mp/proxy-io.h index f7367468..82c88ed5 100644 --- a/include/mp/proxy-io.h +++ b/include/mp/proxy-io.h @@ -318,7 +318,7 @@ class EventLoop }; //! Single element task queue used to handle recursive capnp calls. (If server -//! makes an callback into the client in the middle of a request, while client +//! If the server makes a callback into the client in the middle of a request, while client //! thread is blocked waiting for server response, this is what allows the //! client to run the request in the same thread, the same way code would run in //! single process, with the callback sharing same thread stack as the original diff --git a/include/mp/proxy-types.h b/include/mp/proxy-types.h index 22468b15..7301aa59 100644 --- a/include/mp/proxy-types.h +++ b/include/mp/proxy-types.h @@ -87,7 +87,7 @@ struct StructField // actually construct the read destination object. For example, if a std::string // is being read, the ReadField call will call the custom emplace_fn with char* // and size_t arguments, and the emplace function can decide whether to call the -// constructor via the operator or make_shared or emplace or just return a +// constructor via the operator, make_shared, emplace or just return a // temporary string that is moved from. template struct ReadDestEmplace @@ -205,11 +205,11 @@ void BuildField(TypeList, Context& context, Output&& output, Valu } } -// Adapter to let BuildField overloads methods work set & init list elements as -// if they were fields of a struct. If BuildField is changed to use some kind of -// accessor class instead of calling method pointers, then then maybe this could -// go away or be simplified, because would no longer be a need to return -// ListOutput method pointers emulating capnp struct method pointers.. +// Adapter that allows BuildField overloads to work with, set, and initialize list +// elements as if they were fields of a struct. If BuildField is changed to use some +// kind of accessor class instead of calling method pointers, then maybe this could +// go away or be simplified, because there would no longer be a need to return +// ListOutput method pointers emulating capnp struct method pointers. template struct ListOutput; diff --git a/src/mp/gen.cpp b/src/mp/gen.cpp index 18400710..cedb4dc4 100644 --- a/src/mp/gen.cpp +++ b/src/mp/gen.cpp @@ -136,7 +136,7 @@ static bool BoxedType(const ::capnp::Type& type) // include_prefix can be used to control relative include paths used in // generated files. For example if src_file is "/a/b/c/d/file.canp" and // include_prefix is "/a/b/c" include lines like -// "#include " "#include "i +// "#include ", "#include " // will be generated. static void Generate(kj::StringPtr src_prefix, kj::StringPtr include_prefix, diff --git a/src/mp/proxy.cpp b/src/mp/proxy.cpp index 57545d37..840f6410 100644 --- a/src/mp/proxy.cpp +++ b/src/mp/proxy.cpp @@ -102,12 +102,12 @@ Connection::~Connection() // The ProxyClient cleanup handlers are synchronous because they are fast // and don't do anything besides release capnp resources and reset state so // future calls to client methods immediately throw exceptions instead of - // trying to communicating across the socket. The synchronous callbacks set + // trying to communicate across the socket. The synchronous callbacks set // ProxyClient capability pointers to null, so new method calls on client // objects fail without triggering i/o or relying on event loop which may go // out of scope or trigger obscure capnp i/o errors. // - // The ProxySever cleanup handlers call user defined destructors on server + // The ProxyServer cleanup handlers call user defined destructors on server // object, which can run arbitrary blocking bitcoin code so they have to run // asynchronously in a different thread. The asynchronous cleanup functions // intentionally aren't started until after the synchronous cleanup @@ -136,7 +136,7 @@ Connection::~Connection() // // Either way disconnect code runs in the event loop thread and called both // on clean and unclean shutdowns. In unclean shutdown case when the - // connection is broken, sync and async cleanup lists will filled with + // connection is broken, sync and async cleanup lists will be filled with // callbacks. In the clean shutdown case both lists will be empty. Lock lock{m_loop->m_mutex}; while (!m_sync_cleanup_fns.empty()) {