grammar fixes

blog post - Sectr Prototype.md

@@ -1,15 +1,15 @@
 # Sectr Prototype
 
-After my last contract in January, I wanted a break from C/C++ projects, so I to attempt another go at developing a pragmatic “projectional” editor for code using Odin. The goal is to offer support for multiple “workspaces” where users can compose “views” of code definitions in a flexible manner irrespective of the their composition in the filesystem.
+After my last contract in January, I wanted a break from C/C++ projects, so I decided to attempt another go at developing a pragmatic “projectional” editor for code using Odin. The goal is to offer support for multiple “workspaces” where users can compose “views” of code definitions in a flexible manner, irrespective of their composition in the filesystem.
 
 (My last attempt at figuring things out utilizing Godot 4.2):  
 <img src="static/images/news/2024-06-sectr_prototype_godot_ver_last_state.png" alt="img: previous godot prototype" width="650">
 
 ## Why Odin
 
-Tired of the C++ toolchain, I chose Odin over Zig. Jai seemed to be up my alley but I don’t have the patience to wait for it. Odin’s looked like there would be less conflicts with the language so it won out.
+Tired of the C++ toolchain, I chose Odin over Zig. Jai seemed to be up my alley, but I didn't have the patience to wait for it. Odin’s design looked to impose less friction than Zig so it won out.
 
-That ended up being a great decision. Odin feels better than just being a “C alternative”. Llanguage features, like the “using” keyword and “deferred_” attributes, have been particularly enjoyable to use. Both the provided packages and those sourced from third-parties have been easy to learn and integrate.
+That ended up being a great decision. Odin feels better than just being a “C alternative”. Language features, like the “using” keyword and “deferred_” attributes, have been particularly enjoyable to use. Both the provided packages and those sourced from third parties have been easy to learn and integrate.
 
 Exploring the compiler implementation has also been an unexpected bonus. Most toolchains’ source feel too daunting to learn how “a toolchain works”. Odin is the exact opposite. Each file is clear and understandable at a scrolling glance, which is an amazing achievement.
 
@@ -19,13 +19,13 @@ The codebase setup was smooth. The first sign of things to come was how simple a
 
 Raylib was chosen to handle input, rendering (Text and 2D), and windowing, which did the job initially.
 
-Hot-reload was up next, Karl Zylinski’s highly praised article was loosely referenced, along with code previously written following the Handmade Hero series. Unfortunately that very series exposed me to Casey’s janky replay feature (abusing memory snapshots), and I wanted to port the feature over to this project. The first issue was the core library not exposing the starting address arg for VirtualAlloc in core:mem/virtual. However, a derivative of the virtual arena with the argument exposed was easy to implement. Another issue was allocator procedures not getting auto-remapped across reloads, leading me to roll my own dynamic array and hash table. Later, I realized I could have transmuted the containers to their “Raw” struct counterparts (Raw_Map and Raw_Dynamic_Array in base:runtime/core.odin), which is a simple refactor for the near future.
+Hot-reload was up next. Karl Zylinski’s highly praised article was loosely referenced, along with code previously I had written following the Handmade Hero series. Unfortunately, that very series exposed me to Casey’s janky replay feature (abusing memory snapshots), and I wanted to port the feature over to this project. The first issue was the core library not exposing the starting address arg for VirtualAlloc in core:mem/virtual. However, a derivative of the virtual arena with the argument exposed was easy to implement. Another issue was allocator procedures not getting auto-remapped across reloads, leading me to roll my own dynamic array and hash table. Later, I realized the builtin containers could have been transmuted to their “Raw” struct counterparts (Raw_Map and Raw_Dynamic_Array in base:runtime/core.odin). A simple refactor for the near future.
 
-The profiler was added last, and I went with Spall since it was directly setup in the Vendor library. I’ve never pulled together this many libraries in such a short period of time, even while messing around.
+The profiler was added last, and I went with Spall since it was directly available in the Vendor library. I’ve never pulled together this many libraries in such a short period of time, even while messing around.
 
 ## Why an IMGUI from scratch?
 
-The aim was to have an uncompromised ability to compose a UI tailored to this editor. Inspired by Rayn Fleury’s UI Series on substack, I set out to implement a “core” UI that could support all that was required. I dived through his implementation from the RAD Debugger, and some others (VUI, Nuklear, and MicroUI). This provided (probably misguided) confidence to tackle the endeavor. So far it’s at least been a great learning experience.
+The aim was to have an uncompromised ability to compose a UI tailored to this editor. Inspired by Ryan Fleury’s UI Series on substack, I set out to implement a “core” UI that could support all that was required. I dived through his implementation from the RAD Debugger, and some others (VUI, Nuklear, and MicroUI). This provided (probably misguided) confidence to tackle the endeavor. So far it’s at least been a great learning experience.
 
 The result was a core UI that’s surprisingly simple for its ability, along with full “flex-box” auto-layout using less than 1000 LOC. It reached a point where composing any “widgets” using just the composition of the core “box” entities felt achievable. Including all the UI code demonstrated (excluding rendering) amounts to approximately 2250 LOC.
 
@@ -36,6 +36,6 @@ The result was a core UI that’s surprisingly simple for its ability, along wit
 The limits of Raylib’s text rendering capabilities were encountered when shoving a good amount of “Lorem Ipsum” onto the screen:  
 <img src="static/images/news/2024-06-sectr_prototype_raylib_text_profiling.png" alt="img: previous godot prototype" width="650">
 
-Just having ~250 lines of text boxes queued for rendering would increase the frame time by several milliseconds. Technically, this could be ignored for several months while focusing on other features. However, I wanted to just get the platform and rendering layers down pact. Among the available options, Sokol’s app and gfx libraries seemed to be a great fit. There was an avaialble 2D graphics library called sokol gp avilable as well. All that was left was to determine the best reference for text rendering, and the Discord community recommended fontstash as it had a setup defined for sokol_gfx in the sokol repo itself. Since then I’ve been navigating my way learning all these new libraries.
+Just having ~250 lines of text boxes queued for rendering would increase the frame time by several milliseconds. Technically, this could be ignored for several months while focusing on other features. However, I wanted to just get the platform and rendering layers down pat. Among the options, Sokol’s app and gfx libraries seemed to be a great fit.There was an available 2D graphics library called Sokol GP as well. All that was left was to determine the best reference for text rendering, and the Discord community recommended fontstash as it had a setup defined for Sokol_gfx in the Sokol repo itself. Since then, I’ve been navigating my way through learning all these new libraries.
 
 <video class="ratio ratio-16x9 mb-1 rounded"  controls src="static/images/news/2024-06-sectr_prototype_Sokol_Hot_Reload_closing_vod.mp4" width="650"></video>