From 9faab27ad7f91eff32642aea62faaa60beb9d6ca Mon Sep 17 00:00:00 2001
From: Nav <nav@navnav.me>
Date: Sun, 20 Aug 2023 15:50:05 +0100
Subject: [PATCH] Updated invalid code references that were still using the old
 `Bloom` namespace.

---
 src/DebugServer/Gdb/README.md  | 10 +++++-----
 src/TargetController/README.md | 10 +++++-----
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/DebugServer/Gdb/README.md b/src/DebugServer/Gdb/README.md
index f977cadc..c5b6c610 100644
--- a/src/DebugServer/Gdb/README.md
+++ b/src/DebugServer/Gdb/README.md
@@ -27,14 +27,14 @@ appropriate address in program memory. The GDB server will action this command,
 success or failure.
 
 Commands and responses are delivered in packets. The
-[`Bloom::DebugServer::Gdb::CommandPackets::CommandPacket`](./CommandPackets/CommandPacket.hpp) and
-[`Bloom::DebugServer::Gdb::ResponsePackets::ResponsePacket`](./ResponsePackets/ResponsePacket.hpp) classes are base
+[`DebugServer::Gdb::CommandPackets::CommandPacket`](./CommandPackets/CommandPacket.hpp) and
+[`DebugServer::Gdb::ResponsePackets::ResponsePacket`](./ResponsePackets/ResponsePacket.hpp) classes are base
 classes for these packets. For most GDB commands supported by this server implementation, there is a specific command
 packet class that can be found in [/src/DebugServer/Gdb/CommandPackets](./CommandPackets). When the server receives a
 command packet from the GDB client, the appropriate (`CommandPacket` derived) object is constructed, which encapsulates
 all of the relevant information for the particular command.
 
-Consider the [`Bloom::DebugServer::Gdb::CommandPackets::SetBreakpoint`](./CommandPackets/SetBreakpoint.hpp) command
+Consider the [`DebugServer::Gdb::CommandPackets::SetBreakpoint`](./CommandPackets/SetBreakpoint.hpp) command
 packet class:
 
 ```c++
@@ -119,8 +119,8 @@ functionality to be implemented in derived classes.
 
 #### GDB target descriptor
 
-The [`Bloom::DebugServer::Gdb::TargetDescriptor`](./TargetDescriptor.hpp) abstract class provides access to any
+The [`DebugServer::Gdb::TargetDescriptor`](./TargetDescriptor.hpp) abstract class provides access to any
 information that is specific to the target architecture and GDB. For example, the register mapping described above, for
-AVR targets, is implemented in [`Bloom::DebugServer::Gdb::AvrGdb::TargetDescriptor`](./AvrGdb/TargetDescriptor.hpp).
+AVR targets, is implemented in [`DebugServer::Gdb::AvrGdb::TargetDescriptor`](./AvrGdb/TargetDescriptor.hpp).
 That class is derived from the abstract `TargetDescriptor` class. It implements the AVR specific concepts that the
 server is expected to be aware of.
diff --git a/src/TargetController/README.md b/src/TargetController/README.md
index cc8bf87c..89337c7b 100644
--- a/src/TargetController/README.md
+++ b/src/TargetController/README.md
@@ -13,20 +13,20 @@ the TargetController, and wait for a response. The TargetController will action
 response.
 
 All TargetController commands can be found in [src/TargetController/Commands](./Commands), and are derived from the
-[`Bloom::TargetController::Commands::Command`](./Commands/Command.hpp) base class. Responses can be found in
+[`TargetController::Commands::Command`](./Commands/Command.hpp) base class. Responses can be found in
 [src/TargetController/Responses](./Responses), and are derived from the
-[`Bloom::TargetController::Responses::Response`](./Responses/Response.hpp) base class.
+[`TargetController::Responses::Response`](./Responses/Response.hpp) base class.
 
 **NOTE:** Components within Bloom do not typically concern themselves with the TargetController command-response
 mechanism. Instead, they use the `TargetControllerService` class, which encapsulates the command-response mechanism and
 provides a simplified means for interaction with the connected hardware. For more, see
 [The TargetControllerService class](#the-TargetControllerService-class) section below.
 
-Commands can be sent to the TargetController via the [`Bloom::TargetController::CommandManager`](./CommandManager.hpp)
+Commands can be sent to the TargetController via the [`TargetController::CommandManager`](./CommandManager.hpp)
 class.
 
 For example, to read memory from the connected target, we would send the
-[`Bloom::TargetController::Commands::ReadTargetMemory`](./Commands/ReadTargetMemory.hpp) command:
+[`TargetController::Commands::ReadTargetMemory`](./Commands/ReadTargetMemory.hpp) command:
 
 ```c++
 auto tcCommandManager = TargetController::CommandManager();
@@ -86,7 +86,7 @@ The `TargetControllerService` class does not require any dependencies at constru
 different threads and used freely to gain access to the connected hardware, from any component within Bloom.
 
 All components within Bloom should use the `TargetControllerService` class to interact with the connected hardware. They
-**should not** directly issue commands via the `Bloom::TargetController::CommandManager`, unless there is a very good
+**should not** directly issue commands via the `TargetController::CommandManager`, unless there is a very good
 reason to do so.
 
 ##### Atomic sessions with the TargetControllerService