more review

code/grime/linked_list.odin

@@ -5,20 +5,20 @@ An intersive singly & double linked list implementation
 */
 package grime
 
-LL_Node :: struct ( $ Type : typeid ) {
-	next  : ^Type,
+SLL_Node :: struct ($Type: typeid) {
+	next: ^Type,
 }
 
 // ll_push :: proc( list_ptr : ^(^ ($ Type)), node : ^Type ) {
-ll_push :: #force_inline proc "contextless" ( list_ptr : ^(^ ($ Type)), node : ^Type ) {
-	list : ^Type = (list_ptr^)
-	node.next   = list
-	(list_ptr^) = node
+sll_push :: #force_inline proc "contextless" ( list_ptr : ^(^ ($ Type)), node : ^Type, node_next: ^(^Type) ) {
+	list:         = (list_ptr ^)
+	(node_next ^) = list
+	(list_ptr  ^) = node
 }
 
-ll_pop :: #force_inline proc "contextless" ( list_ptr : ^(^ ($ Type)) ) -> ( node : ^Type ) {
-	list : ^Type = (list_ptr^)
-	(list_ptr^) = list.next
+sll_pop :: #force_inline proc "contextless" ( list_ptr: ^(^ ($ Type)), list_next: ^(^Type) ) -> ( node : ^Type ) {
+	list : ^Type = (list_ptr  ^)
+	(list_ptr ^) = (list_next ^)
 	return list
 }
 

code/grime/pool_allocator.odin

@@ -353,7 +353,7 @@ pool_validate_ownership :: proc( using self : Pool, block : [] byte ) -> b32
 		{
 			misalignment := (block_address - start) % uintptr(block_size)
 			if misalignment != 0 {
-				// TODO(Ed): We cannot use thsi to validate that the data is within the pool bucket as we can provide the user different alignments
+				// TODO(Ed): We cannot use this to validate that the data is within the pool bucket as we can provide the user different alignments
 				// ensure(false, "pool_validate_ownership: This data is within this pool's buckets, however its not aligned to the start of a block")
 				// log(str_fmt("Block address: %p Misalignment: %p closest: %p",
 				// 	transmute(rawptr)block_address,

code/sectr/app/state.odin

@@ -63,11 +63,16 @@ frame_allocator :: proc() -> Allocator {
 	return result
 }
 
+// TODO(Ed): Rethink usage of transient arena
+// We can have it so that all usage of transients are chained 64 mb arenas. The users can clear the scratch and make a free-list on the parent varena.
+// Anything over 64 mb or the chaining threshold should really have dedicated memory.
 transient_allocator :: proc() -> Allocator {
 	result := varena_allocator( Memory_App.transient )
 	return result
 }
 
+// TODO(Ed): This needs to be reviewed as we technically can keep the whole file in buffer, 
+// but are we better off with a storage virtual mapping on-demand requested from the host by the client?
 files_buffer_allocator :: proc() -> Allocator {
 	result := varena_allocator( Memory_App.files_buffer )
 	return result
@@ -84,6 +89,9 @@ frame_slab_allocator :: proc() -> Allocator {
 	return result
 }
 
+// TODO(Ed): Rethink usage of transient arena, slab may still be useful but we need to think of the heursitic when this will be actively used
+// String generation should use a chained arena, they should never exceed 64 mb or the max threshold (correct?)
+// Dynamic arrays that last for a while maybe but are temp for complex workloads? Dynamic hashtables using arrays/arenas?
 transient_slab_allocator :: proc() -> Allocator {
 	result := slab_allocator( get_state().transient_slab )
 	return result

code/sectr/grime/pkg_mappings.odin

@@ -267,10 +267,10 @@ import "codebase:grime"
 	djb8_hash :: grime.djb8_hash
 
 	// linked lists
-	LL_Node :: grime.LL_Node
+	SLL_Node :: grime.SLL_Node
 
-	ll_push :: grime.ll_push
-	ll_pop  :: grime.ll_pop
+	sll_push :: grime.sll_push
+	sll_pop  :: grime.sll_pop
 
 	DLL_Node     :: grime.DLL_Node
 	DLL_NodeFull :: grime.DLL_NodeFull

code/sectr/ui/core/base.odin

@@ -120,7 +120,8 @@ UI_BoxCache_TableSize     :: 32  * Kilobyte
 
 // TODO(Ed): Rename to UI_Context
 UI_State :: struct {
-	// TODO(Ed) : Use these?
+	// TODO(Ed) : Use these? Right now the way our hashtable does things is it implicitly uses a pool allocator.
+	// We could instead use an arena (CR) allocator, if it chains it won't matter because the boxes are only accessed purely as a DAG.
 	// build_arenas : [2]Arena,
 	// build_arena  : ^ Arena,
 
@@ -141,11 +142,13 @@ UI_State :: struct {
 	// render_list          : Array(UI_RenderBoxInfo),
 	render_list_box      : Array(UI_RenderBoxInfo),
 	render_list_text     : Array(UI_RenderTextInfo),
-
+	// TODO(Ed): We can have multiple list sets, one towards working-set, and the one enqueued for rendering (a buffered list matching the framebuffer)
+	// We can back these by arenas? Do we want them persistently on the slab?
+ 
 	null_box : ^UI_Box, // This was used with the Linked list interface...
 	root     : ^UI_Box,
 
-	// TODO(Ed) : Look into using a build arena like Ryan does for these possibly (and thus have a linked-list stack)
+	// TODO(Ed) : Look into using a build arena like Ryan does for these possibly (and thus have a linked-list stack) (Chained Arenas)
 	layout_combo_stack : StackFixed( UI_LayoutCombo, UI_Style_Stack_Size ),
 	style_combo_stack  : StackFixed( UI_StyleCombo,  UI_Style_Stack_Size ),
 	parent_stack       : StackFixed( ^UI_Box, UI_Parent_Stack_Size ),

code/sectr/ui/layout_widget.odin

@@ -1,10 +1,8 @@
 package sectr
 
-import "base:runtime"
-import lalg "core:math/linalg"
-
 /*
 Widget Layout Ops
 
-TODO(Ed): Review this file, these are can now be done with ui_box_compute_layout
+For complex layout operations that are not supported by the core's auto-layout system.
 */
+