- Fixed some variable naming with graph and it's PrettyPrinter

- Added boost-atomic and boost-thread as dependencies for concurrency support

planning/CONTENTS.md

@@ -15,41 +15,58 @@
 
 ## Introduction
 
-  These files serve as general planning documentation for engine structure, systems,  
+  These files serve as general planning documentation for engine structure, systems,
 pipelines, and implementation.
 
 
-  Implementations of core engine systems should strive to be `O(1)` in  
-implementations, both in terms of runtime and memory performance. This is obviously  
-not a realistic goal, so rather than the goal requiring the entire engine to be `O(1)`,  
-we should more specifically look at achieving `O(1)` performance on hot paths.  
-I distinctly use 'strive' and 'goal' as different concepts, where designs should  
-*strive* to accommodate function implementations for `O(1)`, however the specifics  
-of the implementation might not always be able to achieve that, so the end *goal* is  
+  Implementations of core engine systems should strive to be `O(1)` in
+implementations, both in terms of runtime and memory performance. This is obviously
+not a realistic goal, so rather than the goal requiring the entire engine to be `O(1)`,
+we should more specifically look at achieving `O(1)` performance on hot paths.
+I distinctly use 'strive' and 'goal' as different concepts, where designs should
+*strive* to accommodate function implementations for `O(1)`, however the specifics
+of the implementation might not always be able to achieve that, so the end *goal* is
 that hot paths should be `O(1)`.
 
-  Functions should be highly verbose and any bugprone or erroneous behaviour should  
+  Functions should be highly verbose and any bugprone or erroneous behaviour should
 throw assertions. **DO NOT USE EXCEPTIONS**.
 
-  System implementations should be independent of architecture or platforms. i.e.  
-the code of the graphics system should not care if OpenGL or Vulkan is used and should  
+  System implementations should be independent of architecture or platforms. i.e.
+the code of the graphics system should not care if OpenGL or Vulkan is used and should
 not use any direct calls to OpenGL or Vulkan.
 
-  The engine should not care about the types of objects loaded from a so/dll. In  
-fact, most of the code should be type independent. Any shared information among a  
-collection of objects should be held either implicitly or explicitly in the super-class.  
-It will be the responsibility of the linked code to initialize and cleanup the objects  
+  The engine should not care about the types of objects loaded from a so/dll. In
+fact, most of the code should be type independent. Any shared information among a
+collection of objects should be held either implicitly or explicitly in the super-class.
+It will be the responsibility of the linked code to initialize and cleanup the objects
 related to it. This principle should extend to the submodules of the engine.
 
-  It is also best to avoid objects having behaviour that is not defined by the system  
-they are in. There are some exceptions in extensions or mods, which should be given  
-configurability and programmability within those systems and their stages. This can   
+  It is also best to avoid objects having behaviour that is not defined by the system
+they are in. There are some exceptions in extensions or mods, which should be given
+configurability and programmability within those systems and their stages. This can 
 be achieved using events at different stages of those engines that are on-demand.
 
 
+## External Libraries
+
+ * `cpptrace`
+   * Walking the stack and retrieving information about the code is *very* platform
+     dependent, and it makes little sense spending days writing a library that will
+     be less effective.
+ * `boost-atomic` `boost-thread`
+   * Concurrency support is *extremely* platform dependent. Each OS has its own
+     implementations with its own idiosyncrasies. We are not writing an operating system,
+     we do not want to spend days writing a library that will be less performant and
+     much more bugprone. Comparing this with the containers library, the containers
+     library is worth reimplementing since it is not platform dependent and we can
+     make an implementation with consistent behavior. Boost is slightly better for our
+     purposes since its implementation is more consistent across implementations than
+     the C++ stdlib.
+
+
 ## Definitions
 
-  Many subpages of these documents will contain tables that use symbols to  
+  Many subpages of these documents will contain tables that use symbols to
 denote implementation and testing progress. The symbols are defined below.
 
 | Symbol | Meaning                 | Notes                                                     |
@@ -62,4 +79,7 @@ denote implementation and testing progress. The symbols are defined below.
 
 ## Libraries
  - [C++ Language Library](./CPP_LANGUAGE.md#c-language-library-lang)
- - [Platform Support Library](./PLATFORM_SUPPORT.md#platform--api-support)
+ - [Platform Support Library](./PLATFORM_SUPPORT.md#platform-support-library-platform)
+ - [Memory Library](./MEMORY.md#memory-library-memory)
+ - [Containers Library](./CONTAINERS.md#containers-library-containers)
+ - [Language Processing Library](./LANGUAGE_PROCESSING.md#language-processing-library-langproc)