feat: add some rust notes
This commit is contained in:
parent
53e6a02031
commit
3d68ef1e97
@ -1,7 +1,7 @@
|
||||
---
|
||||
description: Adds Linked Mentions to pages
|
||||
tags: template
|
||||
hooks.bottom.where: 'true'
|
||||
hooks.bottom.where: 'false'
|
||||
---
|
||||
```template
|
||||
# We need to escape handlebars directives here, since we're embedding
|
||||
|
1
PLUGS.md
1
PLUGS.md
@ -3,4 +3,5 @@ This file lists all plugs that SilverBullet will load. Run the {[Plugs: Update]}
|
||||
```yaml
|
||||
- github:silverbulletmd/silverbullet-git/git.plug.js
|
||||
- github:silverbulletmd/silverbullet-mermaid/mermaid.plug.js
|
||||
- github:joekrill/silverbullet-treeview/treeview.plug.js
|
||||
```
|
76
Projects/bachelor/Notes.md
Normal file
76
Projects/bachelor/Notes.md
Normal file
@ -0,0 +1,76 @@
|
||||
|
||||
```toc
|
||||
```
|
||||
|
||||
# Notes
|
||||
|
||||
We need three major components to work together. I would love it if the node-store and the runtime are super loosely coupled so that they could be replaced by at will. So for example i could use the “server-runtime” that executes the node-graph on the server, or the “local” runtime that executes the node-graph locally.
|
||||
|
||||
**NODE_INTERFACE**
|
||||
This is where the user interacts with the node graph. The frontend loads a node-system. Then fetches all the relevant nodes from the node-store.
|
||||
|
||||
**NODE_REGISTRY**
|
||||
The node-store stores all the nodes. For each node it stores a definition and the wasm blob that executes that node.
|
||||
|
||||
**[[Projects/bachelor/RUNTIME_EXECUTOR|RUNTIME_EXECUTOR]]**
|
||||
The runtime gets a node-graph and returns the result after executing the node-graph. It fetches the relevant nodes from the node-store.
|
||||
|
||||
|
||||
# How to store nodes in the registry?
|
||||
|
||||
The nodes need:
|
||||
|
||||
## ID: string/string/string
|
||||
I could imagine something like jimfx/nature/branch
|
||||
|
||||
## INPUTS:
|
||||
We need a way to define how the UI should render the input ui. Could be something like:
|
||||
|
||||
```json
|
||||
{
|
||||
"inputs": [
|
||||
“a”: {
|
||||
“type”: “select”,
|
||||
“options”: [
|
||||
“curly”,
|
||||
“straight”
|
||||
]
|
||||
},
|
||||
"b": {
|
||||
"type":"float",
|
||||
"value": 0.5,
|
||||
"max": 10.0,
|
||||
"min": 0
|
||||
},
|
||||
"res":{
|
||||
"type": "integer",
|
||||
"value": 5,
|
||||
"setting":"leaves/resolution"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## OUTPUTS
|
||||
The nodes output, could look something like this:
|
||||
|
||||
```json
|
||||
{
|
||||
"outputs": ["stem","float"]
|
||||
}
|
||||
```
|
||||
|
||||
# How to store serialized nodes
|
||||
|
||||
```json
|
||||
{
|
||||
"id":"jimfx/nature/branch",
|
||||
"inputs": [0,8.4],
|
||||
"position": [0.6, 10]
|
||||
"meta": {
|
||||
"title":"Branch Node"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
26
Projects/bachelor/RUNTIME_EXECUTOR.md
Normal file
26
Projects/bachelor/RUNTIME_EXECUTOR.md
Normal file
@ -0,0 +1,26 @@
|
||||
# RUNTIME_EXECUTOR
|
||||
|
||||
This component receives a serialized node_graph and returns the output. I generally love the idea that a node is a pure function which just receives its own inputs and then calculates them. BUT! there is always a but, there are some things that the nodes needs that are not its own inputs. These are in my experience:
|
||||
|
||||
**run_seed**
|
||||
Some nodes generate random values, and to generate random values we generally need a seed value.
|
||||
|
||||
**settings**
|
||||
There are some values that are kind-of global inputs. That means they are inputs to the node, but each node receives the same input. For example for the plant nodes, they are the resolution of each leave.
|
||||
|
||||
After some thinking, my idea is to model these inputs as *hidden* inputs to the node. So they are not gonna be visible in the **NODE_INTERFACE**.
|
||||
|
||||
But they are gonna be passed to the nodes as normal inputs. This could be super useful to allow easy memoization of the nodes, because if none of the inputs changed, we can return the previously computed output.
|
||||
|
||||
|
||||
|
||||
## Linking/Importing of Nodes
|
||||
|
||||
**WebAssembly Components**
|
||||
\- only works in wasmtime / jco at the moment
|
||||
|
||||
For this the runtime_executor needs to be wasm aswell.
|
||||
|
||||
**No linking**
|
||||
\+ Very easy to implement, works everywhere
|
||||
\- Probably not as fast as components
|
33
Projects/bachelor/glossary.md
Normal file
33
Projects/bachelor/glossary.md
Normal file
@ -0,0 +1,33 @@
|
||||
# Glossar
|
||||
|
||||
## WIT
|
||||
WebAssembly Interface Types
|
||||
|
||||
## WASM
|
||||
***W***eb***As***se***m***bly
|
||||
|
||||
WebAssembly is a assembly language for a stack based virtual machine.
|
||||
|
||||
## WASI
|
||||
So wie ich es verstanden habe ist es so eine art standard library für webassembly, so das es eine art gibt dateien zu lesen/schreiben, base64 zu encoden/decoden.
|
||||
|
||||
## WASI is a modular system interface for WebAssembly
|
||||
[Announcement](https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/)
|
||||
|
||||
# Own Glossary
|
||||
|
||||
## NODES
|
||||
*> NODE_INPUTS*
|
||||
*> NODE_OUTPUTS*
|
||||
|
||||
## SERIALIZED_NODES
|
||||
|
||||
## NODE_GRAPH
|
||||
|
||||
## SERIALIZED_NODE_GRAPH
|
||||
|
||||
## RUNTIME_EXECUTOR
|
||||
|
||||
## NODE_GRAPH_INTERFACE
|
||||
|
||||
## NODE_REGISTRY
|
@ -1,5 +1,9 @@
|
||||
# Bachelorarbeit
|
||||
|
||||
- [[Projects/bachelor/links|Links]]
|
||||
- [[Projects/bachelor/glossary|Glossar]]
|
||||
- [[Projects/bachelor/Notes|Notes]]
|
||||
|
||||
_TODOS:_
|
||||
- [x] Ideen finden
|
||||
- [x] Betreuer finden
|
||||
@ -7,6 +11,7 @@ _TODOS:_
|
||||
- [x] [[Projects/bachlor/Expose|Expose]] fertig schreiben
|
||||
- [x] Termin mit Ivonne absagen
|
||||
- [x] Idee festlegen
|
||||
- [ ] 15 ECTS?
|
||||
|
||||
_Rahmenbedingungen:_
|
||||
- Maximal 80 Seiten
|
||||
@ -16,12 +21,13 @@ _Rahmenbedingungen:_
|
||||
- Ship early, ship often
|
||||
|
||||
_Termine_:
|
||||
[[Projects/bachelor/termine/23_12_14|14.12.2023 ]]
|
||||
[[Projects/bachelor/termine/21.02.2024|21.02.2024]]
|
||||
[[Projects/bachelor/termine/06.02.2024|06.02.2024]]
|
||||
[[Projects/bachelor/termine/23_12_14|14.12.2023]]
|
||||
|
||||
|
||||
|
||||
- [[Projects/bachelor/links|Links]]
|
||||
- [[Projects/bachelor/ideas|Ideas Collection]]
|
||||
|
||||
## Bachelor Topics
|
||||
```query
|
||||
bachelor render [[template/topic]]
|
||||
|
@ -1,5 +1,21 @@
|
||||
# Links
|
||||
|
||||
|
||||
## [WebAssembly: An Updated Roadmap for Developers](https://bytecodealliance.org/articles/webassembly-the-updated-roadmap-for-developers)
|
||||
*Jul 24, 2023*
|
||||
What
|
||||
|
||||
## [Keynote: What is a Component (and Why)? - Luke Wagner](https://www.youtube.com/watch?v=tAACYA1Mwv4)
|
||||
Luke Wagner is the main guy behind wasm components
|
||||
|
||||
## [Bringing the Web up to Speed with WebAssembly](https://people.mpi-sws.org/~rossberg/papers/Haas,%20Rossberg,%20Schuff,%20Titzer,%20Gohman,%20Wagner,%20Zakai,%20Bastien,%20Holman%20-%20Bringing%20the%20Web%20up%20to%20Speed%20with%20WebAssembly.pdf)
|
||||
|
||||
## Runtime agnostic implementation of webassembly components
|
||||
https://docs.rs/wasm_component_layer/latest/wasm_component_layer
|
||||
|
||||
## Talk: Procedural Modeling with Micro Webassemblies by Sean Isom @ Wasm I/O 2023
|
||||
https://youtu.be/PAMuiYCP6mM?feature=shared
|
||||
|
||||
## Gute Google-Suche um Arbeiten zu dem Thema zu finden:
|
||||
https://www.google.com/search?q=Visuelle+Programmierung+Stefan+Schiffer+filetype%3Apdf
|
||||
|
||||
|
10
Projects/bachelor/termine/06.02.2024.md
Normal file
10
Projects/bachelor/termine/06.02.2024.md
Normal file
@ -0,0 +1,10 @@
|
||||
# 06.02.2024
|
||||
|
||||
https://th-koeln.zoom.us/my/stefanbente
|
||||
PW: 420
|
||||
|
||||
Zotero/Zitavi benutzen
|
||||
|
||||
- Direkt anfangen zu schreiben
|
||||
- Nicht die Grundlagen
|
||||
- Direkt die Eigenleistung festhalten
|
1
Projects/bachelor/termine/21.02.2024.md
Normal file
1
Projects/bachelor/termine/21.02.2024.md
Normal file
@ -0,0 +1 @@
|
||||
# 21.02.2024
|
30
Resources/dev/rust.md
Normal file
30
Resources/dev/rust.md
Normal file
@ -0,0 +1,30 @@
|
||||
# Rust Notes
|
||||
|
||||
|
||||
## Options
|
||||
|
||||
So options are things that maybe contain values.
|
||||
|
||||
```rust
|
||||
let option_a: Option<u8> = Some(8);
|
||||
let option_b: Option<u8> = None;
|
||||
```
|
||||
|
||||
To get at the value of a Options you have a few options;
|
||||
|
||||
```rust
|
||||
let res:u8 = option_a.unwrap(); // using option.unwrap -> panics if value is none
|
||||
|
||||
if let Some(unwrapped1) = option_a {
|
||||
println!("Unwrapped1 {}", unwrapped1);
|
||||
}else {
|
||||
println!("None Unwrapped1");
|
||||
}
|
||||
|
||||
match option_a {
|
||||
None => println!("None Unwrapped"),
|
||||
Some(unwrapped1) => {
|
||||
println!("Unwrapped1 {}", unwrapped1)
|
||||
},
|
||||
}
|
||||
```
|
@ -49,6 +49,7 @@
|
||||
- [[Resources/dev/snippets/bash|bash]]
|
||||
- [[Resources/dev/snippets/lua|lua]]
|
||||
- [[Resources/dev/neovim|neovim]]
|
||||
[[Resources/dev/rust|Rust]]
|
||||
- [[Resources/dev/webgl|webgl]]
|
||||
- [[Resources/dev/latex|latex]]
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user