update issues
This commit is contained in:
parent
04a346d851
commit
2a68cfbf63
44 changed files with 1201 additions and 318 deletions
|
@ -78,7 +78,7 @@
|
|||
+ parallelization with an event loop
|
||||
|
||||
% id = "01HA0GPJ8B48K60BWQ2XZZ0PB5"
|
||||
+ the thing with a pass-based architecture is that with enough locking, it *may* be easy to parallelize.
|
||||
+ the thing with a pass-based architecture is that with enough locking, it _may_ be easy to parallelize.
|
||||
|
||||
% id = "01HA0GPJ8B5QB6DF8YVTYC2HJY"
|
||||
+ I can imagine parallelization existing on many levels here.
|
||||
|
@ -131,7 +131,7 @@
|
|||
- because we're using a set, the computation is never duplicated; remember that if an answer has already been memoized, it does not spawn a task and instead returns the answer immediately
|
||||
|
||||
% id = "01HA0GPJ8B0V2VJMAV1YCQ19Q8"
|
||||
- though this may be hard to do with Rust because, as far as I know, there is no way to suspend a function conditionally? **(needs research.)**
|
||||
- though this may be hard to do with Rust because, as far as I know, there is no way to suspend a function conditionally? *(needs research.)*
|
||||
|
||||
% id = "01HA0GPJ8BBREEJCJRWPJJNR3N"
|
||||
- once there are no more tasks in the queue, we're done compiling
|
||||
|
|
|
@ -14,7 +14,7 @@ legacy of today's systems
|
|||
the project
|
||||
|
||||
% id = "01HFP3E77CVPJMQ69305QHRXDH"
|
||||
+ the design goal is to build a **secure operating system you can trust**
|
||||
+ the design goal is to build a *secure operating system you can trust*
|
||||
|
||||
% id = "01HFP3E77CFCF260WBQWTBNPP7"
|
||||
- gone will be the days where you download an executable from the Internet and have no idea
|
||||
|
@ -25,7 +25,7 @@ legacy of today's systems
|
|||
you have to inspect, the better
|
||||
|
||||
% id = "01HFP3E77CGBD4ZQ2JN4Z761VE"
|
||||
+ **NOTE:** at this point shelter is nothing more than an incomplete design. OS development is
|
||||
+ *NOTE:* at this point shelter is nothing more than an incomplete design. OS development is
|
||||
something I wanna get into but haven't enough time to research everything as of now, therefore
|
||||
I'm jotting down my ideas here
|
||||
|
||||
|
|
|
@ -77,14 +77,14 @@
|
|||
- from my analyses when building [Yarnbox][branch:programming/projects/yarnbox], most chunks of bytecode don't exceed 4096 bytes
|
||||
|
||||
% id = "01HA4KNTTKW393XV8CPZSW2J7H"
|
||||
+ the engine loads your bytecode *mostly* verbatim, so we could include a recognizable signature at the end of every script
|
||||
+ the engine loads your bytecode _mostly_ verbatim, so we could include a recognizable signature at the end of every script
|
||||
|
||||
% id = "01HA4NZ9DADP5E842D1630NH19"
|
||||
- I imagine we could use a short string of bytes that's unlikely to collide with anything yet fast to search for. probably 16 bytes (128 bits) would be enough but we can experiment
|
||||
with less
|
||||
|
||||
% id = "01HA4NZ9DA4HADG7SFDTPKKJ11"
|
||||
- I say it loads your code *mostly* verbatim because it actually parses the bytecode to translate archive object indices to
|
||||
- I say it loads your code _mostly_ verbatim because it actually parses the bytecode to translate archive object indices to
|
||||
|
||||
% id = "01HA4NZ9DAW2KEDX62E810PA03"
|
||||
- since we can't reallocate memory, we'll have to always preallocate all 65536 bytes - but 64 KiB isn't that much in the first place,
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue