vurtun · September 13, 2023 11:42 · Feb 15, 2019 · Feb 15, 2019 · Feb 13, 2019 · Feb 12, 2019
diff --git a/allocator.md b/allocator.md
@@ -89,5 +89,5 @@ im.persistent_alloactor = pers_allocator;
 im.alloc = my_alloc;
 im.free = my_free;
 // ...
-struct module_export *ex = load_module(&im);
+struct module_export ex = load_module(&im);
 ```
diff --git a/allocator.md b/allocator.md
@@ -14,7 +14,7 @@ struct module_import im;
 im.temporary_allocator = temp_allocator;
 im.persistent_alloactor = pers_allocator;
 // ...
-struct module_export *ex = load_module(&im);
+struct module_export ex = load_module(&im);
 ```
 
 Now the problem is that we want the user of the engine to also be able to define allocators. One way is to include callbacks in

diff --git a/allocator.md b/allocator.md
@@ -21,16 +21,14 @@ Now the problem is that we want the user of the engine to also be able to define
 each allocator or have a vtable. My idea to have one function inside the library mapping from allocator type to alloc or free:
 
 ```c
-enum tm_allocator_type
-{
+enum tm_allocator_type {
     TM_ALLOCATOR_TYPE_ENGINE = 0x100000
     TM_ALLACTOR_TYPE_ARENA,
     TM_ALLACTOR_TYPE_BLOCK,
     //....
 };
 
-struct tm_allocator_handle
-{
+struct tm_allocator_handle {
     int type;
 }
 

diff --git a/allocator.md b/allocator.md
@@ -11,8 +11,8 @@ or a handle/interface:
 
 ```c
 struct module_import im;
-im.temporary_allocator = &temp_allocator;
-im.persistent_alloactor = &pers_allocator;
+im.temporary_allocator = temp_allocator;
+im.persistent_alloactor = pers_allocator;
 // ...
 struct module_export *ex = load_module(&im);
 ```
@@ -51,8 +51,8 @@ This allocator handle and alloc functions can be passed to any module.
 
 ```c
 struct module_import im;
-im.temporary_allocator = &temp_allocator;
-im.persistent_alloactor = &pers_allocator;
+im.temporary_allocator = temp_allocator;
+im.persistent_alloactor = pers_allocator;
 im.alloc = tm_alloc;
 im.free = tm_free;
 // ...
@@ -86,8 +86,8 @@ any module that needs an allocator while being able to use either the engine or
 
 ```c
 struct module_import im;
-im.temporary_allocator = &temp_allocator;
-im.persistent_alloactor = &pers_allocator;
+im.temporary_allocator = temp_allocator;
+im.persistent_alloactor = pers_allocator;
 im.alloc = my_alloc;
 im.free = my_free;
 // ...

diff --git a/allocator.md b/allocator.md
@@ -17,7 +17,7 @@ im.persistent_alloactor = &pers_allocator;
 struct module_export *ex = load_module(&im);
 ```
 
-Know the problem is that we want the user of the engine to also be able to define allocators. One way is to include callbacks in
+Now the problem is that we want the user of the engine to also be able to define allocators. One way is to include callbacks in
 each allocator or have a vtable. My idea to have one function inside the library mapping from allocator type to alloc or free:
 
 ```c

diff --git a/allocator.md b/allocator.md
@@ -3,7 +3,7 @@ from [Our Machinery](https://ourmachinery.com/). I have to begin that my underst
 limit and it is currently rather late in the day, so please bear with me. As far as I understood how modules work is similar to how Quake 2 did their modules. A module
 has both a struct for [export](https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L131) and one
 for [import](https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L189) containing a number of
-function pointer. [At load time the module gets a filled out import struct and fills out its own export struct with its own functions](https://github.com/id-Software/Quake-2/blob/master/ref_gl/gl_rmain.c#L1624).
+function pointer. [At load time the module gets a filled out import struct and fills out its own export struct with its own functions](https://github.com/id-Software/Quake-2/blob/master/ref_gl/gl_rmain.c#L1624) and returns it.
 
 As for the allocators. I would have guessed that all engine specific allocators are defined internally in the engine inside the foundation library.
 On load time each module would request a number of alloactors (for example for different use cases). This could include just a functions pointer and void pointer

diff --git a/allocator.md b/allocator.md
@@ -1,6 +1,6 @@
 This is a short post related to [Opaque object representations](https://ourmachinery.com/files/guidebook.md.html#omg-api:apidesign/omg-api-19:opaqueobjectrepresentations)
 from [Our Machinery](https://ourmachinery.com/). I have to begin that my understanding of how Our Machineries tech is somewhat
-limit so please bear with me. While I try to explain my thought process. As far as I understood how modules work is similar to how Quake 2 did their modules. A module
+limit and it is currently rather late in the day, so please bear with me. As far as I understood how modules work is similar to how Quake 2 did their modules. A module
 has both a struct for [export](https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L131) and one
 for [import](https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L189) containing a number of
 function pointer. [At load time the module gets a filled out import struct and fills out its own export struct with its own functions](https://github.com/id-Software/Quake-2/blob/master/ref_gl/gl_rmain.c#L1624).

diff --git a/allocator.md b/allocator.md
@@ -1,5 +1,5 @@
 This is a short post related to [Opaque object representations](https://ourmachinery.com/files/guidebook.md.html#omg-api:apidesign/omg-api-19:opaqueobjectrepresentations)
-from [Our Machinery](https://ourmachinery.com/). I have to begin that my understanding of how Our Machineries tech works is somewhat
+from [Our Machinery](https://ourmachinery.com/). I have to begin that my understanding of how Our Machineries tech is somewhat
 limit so please bear with me. While I try to explain my thought process. As far as I understood how modules work is similar to how Quake 2 did their modules. A module
 has both a struct for [export](https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L131) and one
 for [import](https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L189) containing a number of

diff --git a/allocator.md b/allocator.md
@@ -84,4 +84,12 @@ void my_alloc(struct tm_allocator_handle* handle, size_t size)
 Now just like with our engine allocator `tm_alloc` and `tm_free` functions we can also pass our own `my_alloc` and `my_free` to
 any module that needs an allocator while being able to use either the engine or my own allocators
 
-
+```c
+struct module_import im;
+im.temporary_allocator = &temp_allocator;
+im.persistent_alloactor = &pers_allocator;
+im.alloc = my_alloc;
+im.free = my_free;
+// ...
+struct module_export *ex = load_module(&im);
+```
diff --git a/allocator.md b/allocator.md
@@ -10,10 +10,11 @@ On load time each module would request a number of alloactors (for example for d
 or a handle/interface:
 
 ```c
-module_import im;
+struct module_import im;
 im.temporary_allocator = &temp_allocator;
 im.persistent_alloactor = &pers_allocator;
 // ...
+struct module_export *ex = load_module(&im);
 ```
 
 Know the problem is that we want the user of the engine to also be able to define allocators. One way is to include callbacks in
@@ -49,12 +50,13 @@ void* tm_alloc(tm_allocator_handle* handle, size_t size)
 This allocator handle and alloc functions can be passed to any module. 
 
 ```c
-module_import im;
+struct module_import im;
 im.temporary_allocator = &temp_allocator;
 im.persistent_alloactor = &pers_allocator;
 im.alloc = tm_alloc;
 im.free = tm_free;
 // ...
+struct module_export *ex = load_module(&im);
 ```
 
 However so far it is limited to only those alloactor types that are defined inside the engine. However it is also possible for anyone else to define their
@@ -82,3 +84,4 @@ void my_alloc(struct tm_allocator_handle* handle, size_t size)
 Now just like with our engine allocator `tm_alloc` and `tm_free` functions we can also pass our own `my_alloc` and `my_free` to
 any module that needs an allocator while being able to use either the engine or my own allocators
 
+
diff --git a/allocator.md b/allocator.md
@@ -1,9 +1,9 @@
-This is a short post related to (Opaque object representations)[https://ourmachinery.com/files/guidebook.md.html#omg-api:apidesign/omg-api-19:opaqueobjectrepresentations]
+This is a short post related to [Opaque object representations](https://ourmachinery.com/files/guidebook.md.html#omg-api:apidesign/omg-api-19:opaqueobjectrepresentations)
 from [Our Machinery](https://ourmachinery.com/). I have to begin that my understanding of how Our Machineries tech works is somewhat
 limit so please bear with me. While I try to explain my thought process. As far as I understood how modules work is similar to how Quake 2 did their modules. A module
-has both a struct for (export)[https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L131] andhttps://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L131 one
-for (import)[https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L189] containing a number of
-function pointer. (At load time the module gets a filled out import struct and fills out its own export struct with its own functions)[https://github.com/id-Software/Quake-2/blob/master/ref_gl/gl_rmain.c#L1624].
+has both a struct for [export](https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L131) and one
+for [import](https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L189) containing a number of
+function pointer. [At load time the module gets a filled out import struct and fills out its own export struct with its own functions](https://github.com/id-Software/Quake-2/blob/master/ref_gl/gl_rmain.c#L1624).
 
 As for the allocators. I would have guessed that all engine specific allocators are defined internally in the engine inside the foundation library.
 On load time each module would request a number of alloactors (for example for different use cases). This could include just a functions pointer and void pointer

diff --git a/allocator.md b/allocator.md
@@ -0,0 +1,84 @@
+This is a short post related to (Opaque object representations)[https://ourmachinery.com/files/guidebook.md.html#omg-api:apidesign/omg-api-19:opaqueobjectrepresentations]
+from [Our Machinery](https://ourmachinery.com/). I have to begin that my understanding of how Our Machineries tech works is somewhat
+limit so please bear with me. While I try to explain my thought process. As far as I understood how modules work is similar to how Quake 2 did their modules. A module
+has both a struct for (export)[https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L131] andhttps://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L131 one
+for (import)[https://github.com/id-Software/Quake-2/blob/372afde46e7defc9dd2d719a1732b8ace1fa096e/client/ref.h#L189] containing a number of
+function pointer. (At load time the module gets a filled out import struct and fills out its own export struct with its own functions)[https://github.com/id-Software/Quake-2/blob/master/ref_gl/gl_rmain.c#L1624].
+
+As for the allocators. I would have guessed that all engine specific allocators are defined internally in the engine inside the foundation library.
+On load time each module would request a number of alloactors (for example for different use cases). This could include just a functions pointer and void pointer
+or a handle/interface:
+
+```c
+module_import im;
+im.temporary_allocator = &temp_allocator;
+im.persistent_alloactor = &pers_allocator;
+// ...
+```
+
+Know the problem is that we want the user of the engine to also be able to define allocators. One way is to include callbacks in
+each allocator or have a vtable. My idea to have one function inside the library mapping from allocator type to alloc or free:
+
+```c
+enum tm_allocator_type
+{
+    TM_ALLOCATOR_TYPE_ENGINE = 0x100000
+    TM_ALLACTOR_TYPE_ARENA,
+    TM_ALLACTOR_TYPE_BLOCK,
+    //....
+};
+
+struct tm_allocator_handle
+{
+    int type;
+}
+
+void* tm_alloc(tm_allocator_handle* handle, size_t size)
+{
+    switch(handle->type) {
+    case TM_ALLACTOR_TYPE_ARENA: {
+      struct tm_arena_allocator =  (struct tm_arena_allocator)handle;
+      return tm_arena_alloc(size);
+    }
+    break;
+    //....
+    }
+}
+```
+
+This allocator handle and alloc functions can be passed to any module. 
+
+```c
+module_import im;
+im.temporary_allocator = &temp_allocator;
+im.persistent_alloactor = &pers_allocator;
+im.alloc = tm_alloc;
+im.free = tm_free;
+// ...
+```
+
+However so far it is limited to only those alloactor types that are defined inside the engine. However it is also possible for anyone else to define their
+own versions (all internal allocator type begin on an offet while user alloactor begin at 0):
+
+```c
+enum my_allocator_type {
+    MY_ALLOCATOR_STACK,
+    MY_ALLCATOR_SYSTEM.
+    MY_ALLCATOR_TRACE
+};
+
+void my_alloc(struct tm_allocator_handle* handle, size_t size)
+{
+    switch(handle->type) {
+    default: return tm_alloc(handle, size);
+    case MY_ALLOCATOR_STACK: {
+        struct my_stack_allocator =  (struct my_stack_allocator)handle;
+        return my_stack_alloc(size);
+    } break;
+    //....
+    }
+}
+```
+Now just like with our engine allocator `tm_alloc` and `tm_free` functions we can also pass our own `my_alloc` and `my_free` to
+any module that needs an allocator while being able to use either the engine or my own allocators
+