From e7b84a65084e17d5da64fe1fa716d7a186ed701c Mon Sep 17 00:00:00 2001 From: s-ol Date: Mon, 4 Oct 2021 16:13:31 +0200 Subject: Split root out of mmm repo --- root/research/$order | 4 - root/research/alivecoding/$order | 1 - .../research/alivecoding/demo/URL -> youtube$video | 1 - root/research/alivecoding/description: text$plain | 1 - .../alivecoding/text$markdown+sidenotes.md | 145 ------ root/research/mmmfs/$order | 15 - root/research/mmmfs/_web_view: type | 1 - .../mmmfs/abstract/text$markdown+sidenotes.md | 14 - root/research/mmmfs/ba_log/$order | 15 - .../mmmfs/ba_log/2019-10-07/text$markdown.md | 40 -- .../mmmfs/ba_log/2019-10-08/text$markdown.md | 58 --- .../mmmfs/ba_log/2019-10-09/text$markdown.md | 9 - .../mmmfs/ba_log/2019-10-10/text$markdown.md | 46 -- .../mmmfs/ba_log/2019-10-11/text$markdown.md | 30 -- .../mmmfs/ba_log/2019-10-14/text$markdown.md | 101 ---- .../mmmfs/ba_log/2019-10-15/text$markdown.md | 70 --- .../mmmfs/ba_log/2019-10-24/text$markdown.md | 32 -- .../mmmfs/ba_log/2019-10-26/text$markdown.md | 62 --- root/research/mmmfs/ba_log/2019-10-27/$order | 1 - .../mmmfs/ba_log/2019-10-27/text$markdown.md | 77 --- .../mmmfs/ba_log/2019-10-27/video/video$webm.webm | Bin 5209109 -> 0 bytes root/research/mmmfs/ba_log/2019-10-29/$order | 1 - .../mmmfs/ba_log/2019-10-29/text$markdown.md | 38 -- .../mmmfs/ba_log/2019-10-29/video/video$mp4.mp4 | Bin 3944233 -> 0 bytes root/research/mmmfs/ba_log/2019-11-01/$order | 1 - .../mmmfs/ba_log/2019-11-01/demo/video$webm.webm | Bin 9968238 -> 0 bytes .../mmmfs/ba_log/2019-11-01/text$markdown.md | 18 - root/research/mmmfs/ba_log/2019-11-25/$order | 1 - .../mmmfs/ba_log/2019-11-25/demo/video$webm.webm | Bin 1380724 -> 0 bytes .../mmmfs/ba_log/2019-11-25/text$markdown.md | 89 ---- .../ba_log/2019-12-20/text$markdown+sidenotes.md | 39 -- root/research/mmmfs/ba_log/intro: text$markdown.md | 4 - .../print: text$moonscript -> fn -> mmm$dom.moon | 19 - root/research/mmmfs/ba_log/start/text$markdown.md | 25 - .../ba_log/text$moonscript -> fn -> mmm$dom.moon | 15 - .../mmmfs/conclusion/text$markdown+sidenotes.md | 11 - root/research/mmmfs/defense/$order | 13 - root/research/mmmfs/defense/01/text$html+frag.html | 8 - .../mmmfs/defense/02/text$markdown+wide.md | 13 - .../mmmfs/defense/03a/text$markdown+wide.md | 12 - .../mmmfs/defense/03b/text$markdown+wide.md | 10 - .../mmmfs/defense/03c/text$markdown+wide.md | 10 - .../mmmfs/defense/04a/text$markdown+wide.md | 11 - .../mmmfs/defense/04b/text$markdown+wide.md | 12 - .../mmmfs/defense/04c/text$markdown+wide.md | 11 - .../mmmfs/defense/05a/text$markdown+wide.md | 10 - .../mmmfs/defense/05b/text$markdown+wide.md | 10 - .../mmmfs/defense/06/text$markdown+wide.md | 6 - .../mmmfs/defense/07/text$markdown+wide.md | 4 - root/research/mmmfs/defense/08/$order | 1 - root/research/mmmfs/defense/08/image/image$png.png | Bin 285163 -> 0 bytes .../mmmfs/defense/08/text$markdown+wide.md | 10 - .../defense/text$moonscript -> fn -> mmm$dom.moon | 77 --- root/research/mmmfs/description: text$plain | 1 - .../mmmfs/evaluation/text$markdown+sidenotes.md | 173 ------- root/research/mmmfs/examples/$order | 5 - root/research/mmmfs/examples/gallery/$order | 2 - .../examples/gallery/actual_image/image$png.png | Bin 678429 -> 0 bytes .../gallery/actual_image/preview: image$png.png | Bin 31880 -> 0 bytes .../gallery/link_to_image/URL -> image$png | 1 - .../link_to_image/preview: URL -> image$png | 1 - ...ow: text$moonscript -> fn -> mmm$component.moon | 19 - .../gallery/text$moonscript -> fn -> mmm$dom.moon | 12 - .../mmmfs/examples/gallery/title: text$plain | 1 - .../research/mmmfs/examples/image/URL -> image$png | 1 - .../mmmfs/examples/image/title: text$plain | 1 - .../implementation: text$markdown+sidenotes.md | 88 ---- .../examples/intro: text$markdown+sidenotes.md | 10 - .../mmmfs/examples/language_support/$order | 3 - .../javascript/text$javascript -> mmm$dom.js | 15 - .../language_support/javascript/title: text$plain | 1 - .../language_support/lua/text$lua -> mmm$dom.lua | 9 - .../language_support/lua/title: text$plain | 1 - .../moonscript/text$moonscript -> mmm$dom.moon | 10 - .../language_support/moonscript/title: text$plain | 1 - .../language_support/preview: text$markdown | 6 - .../text$moonscript -> fn -> mmm$dom.moon | 16 - .../examples/language_support/title: text$plain | 1 - .../mmmfs/examples/markdown/text$markdown.md | 20 - .../mmmfs/examples/markdown/title: text$plain | 1 - root/research/mmmfs/examples/pinwall/$order | 4 - .../mmmfs/examples/pinwall/image/image$png.png | Bin 128929 -> 0 bytes .../examples/pinwall/image/pinwall_info: text$json | 1 - .../pinwall/text$moonscript -> fn -> mmm$dom.moon | 121 ----- .../examples/pinwall/text/pinwall_info: text$json | 1 - .../mmmfs/examples/pinwall/text/text$plain.txt | 4 - .../mmmfs/examples/pinwall/title: text$plain | 1 - .../mmmfs/examples/pinwall/video/URL -> video$mp4 | 1 - .../examples/pinwall/video/pinwall_info: text$json | 1 - .../pinwall/youtube_video/URL -> youtube$video | 1 - .../pinwall/youtube_video/pinwall_info: text$json | 1 - .../examples/text$moonscript -> fn -> mmm$dom.moon | 44 -- .../mmmfs/framework/text$markdown+sidenotes.md | 96 ---- root/research/mmmfs/historical-approaches/$order | 1 - .../historical-approaches/star-graph/image$png.png | Bin 87351 -> 0 bytes .../star-graph/note: text$markdown.md | 4 - .../text$markdown+sidenotes.md | 73 --- root/research/mmmfs/introduction/text$markdown.md | 18 - root/research/mmmfs/mmmfs/$order | 3 - .../mmmfs/mmmfs/text$markdown+sidenotes.md | 197 -------- .../mmmfs/mmmfs/tree_mainstream/text$mermaid-graph | 11 - .../mmmfs/mmmfs/tree_mmmfs/text$mermaid-graph | 21 - .../mmmfs/type_coercion_graph/text$mermaid-graph | 22 - root/research/mmmfs/motivation/$order | 2 - .../mmmfs/motivation/app-types/text$markdown.md | 3 - .../mmmfs/motivation/creative/text$markdown.md | 2 - .../mmmfs/motivation/text$markdown+sidenotes.md | 138 ------ .../print: text$moonscript -> fn -> mmm$dom.moon | 26 - root/research/mmmfs/references/$order | 22 - root/research/mmmfs/references/acm-dl/text$bibtex | 5 - root/research/mmmfs/references/adobe/text$bibtex | 8 - .../references/alternatives-to-trees/text$bibtex | 7 - .../mmmfs/references/appliances/text$bibtex | 7 - .../mmmfs/references/aspect-ratios/text$bibtex | 7 - .../research/mmmfs/references/dijkstra/text$bibtex | 17 - .../mmmfs/references/hypercard/text$bibtex | 6 - ...down: text$moonscript -> fn -> text$markdown.md | 1 - .../mmmfs/references/inkandswitch/text$bibtex | 7 - .../mmmfs/references/linux-exec/text$bibtex | 8 - root/research/mmmfs/references/lock-in/text$bibtex | 7 - .../mmmfs/references/market-share/text$bibtex | 7 - root/research/mmmfs/references/memex/text$bibtex | 8 - .../mmmfs/references/mime-types/text$bibtex | 14 - .../mmmfs/references/osx-files/text$bibtex | 7 - .../mmmfs/references/poc-or-gtfo/text$bibtex | 8 - .../research/mmmfs/references/renaming/text$bibtex | 7 - root/research/mmmfs/references/subtext/cite$doi | 1 - root/research/mmmfs/references/subtext/text$bibtex | 18 - .../mmmfs/references/super-powers/text$bibtex | 7 - .../text$moonscript -> fn -> mmm$dom.moon | 13 - .../mmmfs/references/transclusion/text$bibtex | 10 - root/research/mmmfs/references/unix/text$bibtex | 7 - .../mmmfs/references/wikipedia/text$bibtex | 7 - root/research/mmmfs/references/xerox-star/cite$doi | 1 - .../mmmfs/references/xerox-star/text$bibtex | 18 - .../statement-of-originality/text$html+frag.html | 13 - .../mmmfs/table-of-contents/text$html+frag.html | 91 ---- .../mmmfs/text$moonscript -> fn -> mmm$dom.moon | 26 - root/research/mmmfs/title/text$html+frag.html | 21 - root/research/realities/description: text$plain | 1 - .../text$moonscript -> mmm$component.moon | 545 --------------------- .../research/text$moonscript -> fn -> mmm$dom.moon | 10 - root/research/title: text$plain | 1 - root/research/watch-cad/description: text$plain | 1 - root/research/watch-cad/link: URL | 1 - 145 files changed, 3343 deletions(-) delete mode 100644 root/research/$order delete mode 100644 root/research/alivecoding/$order delete mode 100644 root/research/alivecoding/demo/URL -> youtube$video delete mode 100644 root/research/alivecoding/description: text$plain delete mode 100644 root/research/alivecoding/text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/$order delete mode 100644 root/research/mmmfs/_web_view: type delete mode 100644 root/research/mmmfs/abstract/text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/ba_log/$order delete mode 100644 root/research/mmmfs/ba_log/2019-10-07/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-08/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-09/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-10/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-11/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-14/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-15/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-24/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-26/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-27/$order delete mode 100644 root/research/mmmfs/ba_log/2019-10-27/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-27/video/video$webm.webm delete mode 100644 root/research/mmmfs/ba_log/2019-10-29/$order delete mode 100644 root/research/mmmfs/ba_log/2019-10-29/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-10-29/video/video$mp4.mp4 delete mode 100644 root/research/mmmfs/ba_log/2019-11-01/$order delete mode 100644 root/research/mmmfs/ba_log/2019-11-01/demo/video$webm.webm delete mode 100644 root/research/mmmfs/ba_log/2019-11-01/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-11-25/$order delete mode 100644 root/research/mmmfs/ba_log/2019-11-25/demo/video$webm.webm delete mode 100644 root/research/mmmfs/ba_log/2019-11-25/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/2019-12-20/text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/ba_log/intro: text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/ba_log/start/text$markdown.md delete mode 100644 root/research/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/conclusion/text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/defense/$order delete mode 100644 root/research/mmmfs/defense/01/text$html+frag.html delete mode 100644 root/research/mmmfs/defense/02/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/03a/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/03b/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/03c/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/04a/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/04b/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/04c/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/05a/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/05b/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/06/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/07/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/08/$order delete mode 100644 root/research/mmmfs/defense/08/image/image$png.png delete mode 100644 root/research/mmmfs/defense/08/text$markdown+wide.md delete mode 100644 root/research/mmmfs/defense/text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/description: text$plain delete mode 100644 root/research/mmmfs/evaluation/text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/examples/$order delete mode 100644 root/research/mmmfs/examples/gallery/$order delete mode 100644 root/research/mmmfs/examples/gallery/actual_image/image$png.png delete mode 100644 root/research/mmmfs/examples/gallery/actual_image/preview: image$png.png delete mode 100644 root/research/mmmfs/examples/gallery/link_to_image/URL -> image$png delete mode 100644 root/research/mmmfs/examples/gallery/link_to_image/preview: URL -> image$png delete mode 100644 root/research/mmmfs/examples/gallery/slideshow: text$moonscript -> fn -> mmm$component.moon delete mode 100644 root/research/mmmfs/examples/gallery/text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/examples/gallery/title: text$plain delete mode 100644 root/research/mmmfs/examples/image/URL -> image$png delete mode 100644 root/research/mmmfs/examples/image/title: text$plain delete mode 100644 root/research/mmmfs/examples/implementation: text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/examples/intro: text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/examples/language_support/$order delete mode 100644 root/research/mmmfs/examples/language_support/javascript/text$javascript -> mmm$dom.js delete mode 100644 root/research/mmmfs/examples/language_support/javascript/title: text$plain delete mode 100644 root/research/mmmfs/examples/language_support/lua/text$lua -> mmm$dom.lua delete mode 100644 root/research/mmmfs/examples/language_support/lua/title: text$plain delete mode 100644 root/research/mmmfs/examples/language_support/moonscript/text$moonscript -> mmm$dom.moon delete mode 100644 root/research/mmmfs/examples/language_support/moonscript/title: text$plain delete mode 100644 root/research/mmmfs/examples/language_support/preview: text$markdown delete mode 100644 root/research/mmmfs/examples/language_support/text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/examples/language_support/title: text$plain delete mode 100644 root/research/mmmfs/examples/markdown/text$markdown.md delete mode 100644 root/research/mmmfs/examples/markdown/title: text$plain delete mode 100644 root/research/mmmfs/examples/pinwall/$order delete mode 100644 root/research/mmmfs/examples/pinwall/image/image$png.png delete mode 100644 root/research/mmmfs/examples/pinwall/image/pinwall_info: text$json delete mode 100644 root/research/mmmfs/examples/pinwall/text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/examples/pinwall/text/pinwall_info: text$json delete mode 100644 root/research/mmmfs/examples/pinwall/text/text$plain.txt delete mode 100644 root/research/mmmfs/examples/pinwall/title: text$plain delete mode 100644 root/research/mmmfs/examples/pinwall/video/URL -> video$mp4 delete mode 100644 root/research/mmmfs/examples/pinwall/video/pinwall_info: text$json delete mode 100644 root/research/mmmfs/examples/pinwall/youtube_video/URL -> youtube$video delete mode 100644 root/research/mmmfs/examples/pinwall/youtube_video/pinwall_info: text$json delete mode 100644 root/research/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/framework/text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/historical-approaches/$order delete mode 100644 root/research/mmmfs/historical-approaches/star-graph/image$png.png delete mode 100644 root/research/mmmfs/historical-approaches/star-graph/note: text$markdown.md delete mode 100644 root/research/mmmfs/historical-approaches/text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/introduction/text$markdown.md delete mode 100644 root/research/mmmfs/mmmfs/$order delete mode 100644 root/research/mmmfs/mmmfs/text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/mmmfs/tree_mainstream/text$mermaid-graph delete mode 100644 root/research/mmmfs/mmmfs/tree_mmmfs/text$mermaid-graph delete mode 100644 root/research/mmmfs/mmmfs/type_coercion_graph/text$mermaid-graph delete mode 100644 root/research/mmmfs/motivation/$order delete mode 100644 root/research/mmmfs/motivation/app-types/text$markdown.md delete mode 100644 root/research/mmmfs/motivation/creative/text$markdown.md delete mode 100644 root/research/mmmfs/motivation/text$markdown+sidenotes.md delete mode 100644 root/research/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/references/$order delete mode 100644 root/research/mmmfs/references/acm-dl/text$bibtex delete mode 100644 root/research/mmmfs/references/adobe/text$bibtex delete mode 100644 root/research/mmmfs/references/alternatives-to-trees/text$bibtex delete mode 100644 root/research/mmmfs/references/appliances/text$bibtex delete mode 100644 root/research/mmmfs/references/aspect-ratios/text$bibtex delete mode 100644 root/research/mmmfs/references/dijkstra/text$bibtex delete mode 100644 root/research/mmmfs/references/hypercard/text$bibtex delete mode 100644 root/research/mmmfs/references/inkandswitch/markdown: text$moonscript -> fn -> text$markdown.md delete mode 100644 root/research/mmmfs/references/inkandswitch/text$bibtex delete mode 100644 root/research/mmmfs/references/linux-exec/text$bibtex delete mode 100644 root/research/mmmfs/references/lock-in/text$bibtex delete mode 100644 root/research/mmmfs/references/market-share/text$bibtex delete mode 100644 root/research/mmmfs/references/memex/text$bibtex delete mode 100644 root/research/mmmfs/references/mime-types/text$bibtex delete mode 100644 root/research/mmmfs/references/osx-files/text$bibtex delete mode 100644 root/research/mmmfs/references/poc-or-gtfo/text$bibtex delete mode 100644 root/research/mmmfs/references/renaming/text$bibtex delete mode 100644 root/research/mmmfs/references/subtext/cite$doi delete mode 100644 root/research/mmmfs/references/subtext/text$bibtex delete mode 100644 root/research/mmmfs/references/super-powers/text$bibtex delete mode 100644 root/research/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/references/transclusion/text$bibtex delete mode 100644 root/research/mmmfs/references/unix/text$bibtex delete mode 100644 root/research/mmmfs/references/wikipedia/text$bibtex delete mode 100644 root/research/mmmfs/references/xerox-star/cite$doi delete mode 100644 root/research/mmmfs/references/xerox-star/text$bibtex delete mode 100644 root/research/mmmfs/statement-of-originality/text$html+frag.html delete mode 100644 root/research/mmmfs/table-of-contents/text$html+frag.html delete mode 100644 root/research/mmmfs/text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/mmmfs/title/text$html+frag.html delete mode 100644 root/research/realities/description: text$plain delete mode 100644 root/research/realities/text$moonscript -> mmm$component.moon delete mode 100644 root/research/text$moonscript -> fn -> mmm$dom.moon delete mode 100644 root/research/title: text$plain delete mode 100644 root/research/watch-cad/description: text$plain delete mode 100644 root/research/watch-cad/link: URL (limited to 'root/research') diff --git a/root/research/$order b/root/research/$order deleted file mode 100644 index e05ba2c..0000000 --- a/root/research/$order +++ /dev/null @@ -1,4 +0,0 @@ -realities -mmmfs -watch-cad -alivecoding diff --git a/root/research/alivecoding/$order b/root/research/alivecoding/$order deleted file mode 100644 index 1549b67..0000000 --- a/root/research/alivecoding/$order +++ /dev/null @@ -1 +0,0 @@ -demo diff --git a/root/research/alivecoding/demo/URL -> youtube$video b/root/research/alivecoding/demo/URL -> youtube$video deleted file mode 100644 index 61512a6..0000000 --- a/root/research/alivecoding/demo/URL -> youtube$video +++ /dev/null @@ -1 +0,0 @@ -https://www.youtube.com/watch?v=z0XZYnY3Evc diff --git a/root/research/alivecoding/description: text$plain b/root/research/alivecoding/description: text$plain deleted file mode 100644 index 1b1a6fc..0000000 --- a/root/research/alivecoding/description: text$plain +++ /dev/null @@ -1 +0,0 @@ -livecoding with persistent expressions diff --git a/root/research/alivecoding/text$markdown+sidenotes.md b/root/research/alivecoding/text$markdown+sidenotes.md deleted file mode 100644 index ce40193..0000000 --- a/root/research/alivecoding/text$markdown+sidenotes.md +++ /dev/null @@ -1,145 +0,0 @@ -# alivecoding: -Persistent expressions are an approach to livecoding that unifies direct -manipulation of a dataflow engine with a textual representation and -lisp-based programming language. - - - -## shortcomings of repl-based programming -In repl-based environments, a scratch file is opened in a text editor. In it, -commands are staged and can be added, removed and edited without consequence. -The livecoding system generally has no knowledge about this scratch buffer at -all. The user is free to select and send individual commands (or groups of -commands) at any time and execute them by transmitting them to the server via -an editor plugin. - -Commands are incremental changes (deltas) that get sent to the server, which -keeps an entirely separate and invisible model of the project. Generally no -feedback about the state of this model is made available to the user. - -Code is only executed when the user evaluates a block, although code run in -this fashion may cause other code to execute outside of the user-evaluated -execution flow via side effects, for example by registering a handler for -events such as incoming messages or scheduling execution based on system time. -These mechanisms however are implementation details within the code the user -executed originally, and no uniform mechanism for noticing, visualizing or -undoing these side-effects exists. - -This design has the following consequences: - -- The view of the scratch buffer is not correlated with the code and state the - server is currently executing. This results in overhead for keeping the - mental synchronized with what the system is actually performing for the user, - but also makes it much harder for the audience to follow along. -- Sessions cannot be reopened reliably, because the state of the server depends - on the full sequence of commands that were sent to the server in order, which - is not represented in the scratch buffer. -- If parts of the execution model on the server have not been explicitly - labelled (i.e. assigned to a variable) in the textual representation, often - many potentially important actions for modifying the current behaviour are - unavailable: for example long-running sounds may not be cancellable, effects' - parameters may not be adjustable without recreating the signal chain, etc. - -## persistent expressions -The *persistent expression* paradigm, on the other hand, reconciles the user- -facing, text-based representation of the system and the server-internal model -and execution flow. - -### execution flow -Code execution happens in two different phases alternatingly: at *eval-time*, -whenever the buffer is (re)evaluated; and at *run-time*, continuously between -evaluations. - -At *eval-time*, execution is analogous to common functional and lisp-style -languages. Expressions are evaluated depth-first starting from the root. -For each expression, the head of the expression is first evaluated, and -depending on the type of that subexpression different actions are taken. In the -general case, the head of an expression is an *Op* (operator) type, an instance -of which will continue to run at *run-time*. In this case, all other arguments -are then evaluated and passed to the *Op* instance, which is either created or -reused (see below). -On the other hand, some expressions (for example `def`, `use`, ...) do not -execute at *run-time*, but cause *eval-time* side-effects like declaring a -symbol in the active scope. Because *eval-time* execution only happens once and -in a deterministic order, and no *eval-time* state persists across evaluations, -despite these side-effects, the *eval-time* execution is equivalent to -functionally pure execution with an implicit scope parameter. - -Unlike normal lisps, when evaluating expressions, not only a value is -generated. In parallel to the tree of return values, a tree of *run-time* -dependencies is built, that tracks all instantiated *Op*s and their inputs. - -At *run-time*, *Op* instances update based on this dependency tree. Starting -from a periodic root event polled by the interpreter, dependent *Op*s are -executed (following the outside-in, depth-first order that the dependencies have -been created in at *eval-time*). *Op*s whose inputs are unchanged and 'pure' -subtrees that do not have any dependency on the root event are not executed. -In this way, the *run-time* behaviour of the system is that of a event-driven -dataflow language with clearly defined execution flow. - -### expression tagging -In order to maintain the congruency between the representations across edits -and reevaluations, the identity of individual expressions is tracked using -tags. Tags are noted using unique numbers in square brackets before the head of -expressions (e.g. `([1]head arg1 arg2...)`) and are optional when parsed. - -At *eval-time* (see below), every expression that is not tagged will be -assigned a new unique tag number. 'Cloned' expressions, such as the expressions -from a function definition body, are assigned composite tags that can be noted -as a list of tags joined by periods (e.g. `[2.1]`): - -``` -([1]defn add-two-and-multiply (a b) - ([2]mul b ([3]add a 2))) - -([4]add-two-and-multiply 1 2) -([5]add-two-and-multiply 3 4) -``` - -will be expanded (at *eval-time*) to approximately -The actual implementation does not actually create sub expressions as shown -here, but the results behave equivalently.: - -``` -(do - (def a 1 - b 2) - ([4.2]mul a ([4.3]add b 2))) -(do - (def a 3 - b 4) - ([5.2]mul a ([5.3]add b 2))) -``` - -The expression tags are used to associate the *run-time* representations (*Op* -instances) of expressions with their textual representations, and track their -identity as the user changes the code. When the code is evaluated, *Op*s are -instantiated whenever the expression was previously untagged, or when the head -of the expression no longer resolves to the same value. Otherwise, the previous -*Op* instance continues to exist and parameter changes are forward to it. *Op*s -that are no longer referenced in the code are destroyed. - -### benefits -This approach combines the benefits of dataflow programming for livecoding with -those of a textual representation and the user-controlled evaluation moment. - -From visual dataflow programming, the following benefits over common textual, -REPL-based livecoding systems are inherited: - -- direct manipulation of individual parameters of a system without disturbing - the system at large -- execution and dataflow are aligned and evident in the editable representation -- state is isolated and compartmentalized in local elements -- opportunity to visualize dataflow and local state - visualizing state of individual *Op*s in editor-dependent and editor-agnostic - ways that integrate with the textual representation is an ongoing research - direction of this project. - -On the other hand, the following advantages from such textual systems are -preserved, that are generally absent in visual dataflow environments: - -- high information density -- fast editing experience -- accessibility and editability from a wide range of tools (any text editor) -- ability to harness powerful meta-programming facilities (from Lisp) -- complex changes can be made without intermittently disrupting the system diff --git a/root/research/mmmfs/$order b/root/research/mmmfs/$order deleted file mode 100644 index 45f4eb8..0000000 --- a/root/research/mmmfs/$order +++ /dev/null @@ -1,15 +0,0 @@ -title -abstract -table-of-contents -introduction -motivation -historical-approaches -framework -mmmfs -examples -evaluation -conclusion -references -ba_log -statement-of-originality -defense diff --git a/root/research/mmmfs/_web_view: type b/root/research/mmmfs/_web_view: type deleted file mode 100644 index bde5644..0000000 --- a/root/research/mmmfs/_web_view: type +++ /dev/null @@ -1 +0,0 @@ -text/html+interactive diff --git a/root/research/mmmfs/abstract/text$markdown+sidenotes.md b/root/research/mmmfs/abstract/text$markdown+sidenotes.md deleted file mode 100644 index c7d6c9c..0000000 --- a/root/research/mmmfs/abstract/text$markdown+sidenotes.md +++ /dev/null @@ -1,14 +0,0 @@ -abstract -======== - -Current end-user operating systems are based on a set of design principles and computing paradigms that make them -simple to use in some circumstances but are very inflexible for user customization and adaptation. In this thesis, these -limitations and design principles will be discussed and contrasted by an analysis of historic systems that solved these -issues by following different design goals. Based on this analysis, as well as further literature, an evaluation -framework for end-user computing systems is established. -The design and implementation of a new end-user computing system, which focuses on a file system with rich file types -and a type coercion system as its central paradigm, is discussed. Following this, the capabilities of the system are -demonstrated using multiple example use-cases. An evaluation of these examples as well as the system itself according -to the framework established earlier shows that the proposed system is indeed very flexible and useful for a wide -variety of uses involving multimedia content from various sources, although the system has many flaws that would hinder -widespread adoption. diff --git a/root/research/mmmfs/ba_log/$order b/root/research/mmmfs/ba_log/$order deleted file mode 100644 index a77277a..0000000 --- a/root/research/mmmfs/ba_log/$order +++ /dev/null @@ -1,15 +0,0 @@ -start -2019-10-07 -2019-10-08 -2019-10-09 -2019-10-10 -2019-10-11 -2019-10-14 -2019-10-15 -2019-10-24 -2019-10-26 -2019-10-27 -2019-10-29 -2019-11-01 -2019-11-25 -2019-12-20 diff --git a/root/research/mmmfs/ba_log/2019-10-07/text$markdown.md b/root/research/mmmfs/ba_log/2019-10-07/text$markdown.md deleted file mode 100644 index 46c6892..0000000 --- a/root/research/mmmfs/ba_log/2019-10-07/text$markdown.md +++ /dev/null @@ -1,40 +0,0 @@ -Today I started working on the HTTP server that finds, converts and serves content stored in the (SQL) backend just-in-time (later the server could also cache content). - -The server can handle these types of requests: - -## Fileder Index Requests -A request like `GET /path/to/fileder/` (note the trailing slash) is used to query the contents of a fileder. -It solicits a JSON-encoded response that contains the full paths to all children of this fileder, as well as all facets currently stored, e.g: - - { - "children": [ - "/projects/vcv_mods", - "/projects/HowDoIOS", - "/projects/iii-telefoni", - "/projects/btrktrl", - "/projects/demoloops", - "/projects/VJmidiKit", - "/projects/gayngine", - "/projects/themer", - "/projects/chimpanzee_bukkaque" - ], - "facets": [ - ["", "text/moonscript -> fn -> mmm/dom"], - ["name", "alpha"], - ["title", "text/plain"] - ] - } - -## Facet Requests -A request like `GET /path/to/fileder/facet_name` is used to query a facet. -To differentiate a request for the 'unnamed' facet from an index request, unnamed facets are represented as a `:` character instead. -The type to ask for can be specified in a `MMM-Accept` header separately, it defaults to `text/html`. - -The server either sends back the (possibly converted) facet with a `200 OK` status, -or a `406 Not Acceptable` error if no conversion was possible. - -I also restructured the code a bit and moved some of the HTML-rendering code into the main mmmfs code. -Then I renamed the `text/html` type to `text/html+frag`, since it refers to only a fragment of HTML code, not a whole document, -and added a new *convert* from `text/html+frag` to `text/html` that wraps the fragment in the HTML template and style. - -the full code change is in commits [81e143f](https://git.s-ol.nu/mmm/commit/81e143fa8181a6adb58d7fba632bd31a13164410/) and [ad26c7c](https://git.s-ol.nu/mmm/commit/ad26c7c4e374f66a978f9946bbb083377f2224a6/) diff --git a/root/research/mmmfs/ba_log/2019-10-08/text$markdown.md b/root/research/mmmfs/ba_log/2019-10-08/text$markdown.md deleted file mode 100644 index c10b75f..0000000 --- a/root/research/mmmfs/ba_log/2019-10-08/text$markdown.md +++ /dev/null @@ -1,58 +0,0 @@ -Today I mostly fixed the output/rendering of the 'live' server I implemented yesterday. - -I changed the URL scheme, it no longer uses headers, which made it hard to link to resources through `` and `" - rplc\render! - -if MODE == 'CLIENT' - export ^ - export o - eval = js.global\eval - GRID_W = 50 - GRID_H = 40 - - SVG = - doc: eval "(function() { return SVG(document.createElement('svg')); })", - G: eval "(function() { return new SVG.G(); })", - setmetatable SVG, __call: => @doc! - - o = do - mkobj = eval "(function () { return {}; })" - (tbl) -> - with obj = mkobj! - for k,v in pairs(tbl) - obj[k] = v - - class Diagram - new: (f) => - @svg = SVG! - @arrows = SVG.G! - @width, @height = 0, 0 - @y = 0 - - f @ - - txtattr = o { - fill: 'white', - 'font-size': '14px', - 'text-anchor': 'middle', - } - block: (color, label, h=1) => - @svg\add with SVG.G! - with \rect GRID_W, h * GRID_H - \attr o fill: color - if label - with \plain label - \move GRID_W/2, 0 - \attr txtattr - - \move @width * GRID_W, (@y + h) * -GRID_H - @y += h - if @y > @height - @height = @y - - arrattr = o { - fill: 'white', - 'font-size': '18px', - 'text-anchor': 'middle', - } - arrow: (char, x, y) => - with @arrows\plain char - \attr arrattr - \move (x + 1) * GRID_W, (y - 0.5) * -GRID_H - 11 - - -- inout: (x=@width, y=@y) => @arrow '⇋', x, y -- U+21CB - -- inn: (x=@width, y=@y) => @arrow '↼', x, y+0.25 -- U+21BC - -- out: (x=@width, y=@y) => @arrow '⇁', x, y-0.25 -- U+21C1 - inout: (x=@width, y=@y) => @arrow '⇆', x, y -- U+21C6 - inn: (x=@width, y=@y) => @arrow '←', x, y+0.25 -- U+2190 - out: (x=@width, y=@y) => @arrow '→', x, y-0.25 -- U+2192 - - mind: (label='mind', ...) => @block '#fac710', label, ... - phys: (label='phys', ...) => @block '#8fd13f', label, ... - digi: (label='digi', ...) => @block '#9510ac', label, ... - - next: => - @y = 0 - @width += 1 - - finish: => - return if @node - @svg\add @arrows - - @width += 1 - w, h = @width * GRID_W, @height * GRID_H - - l = GRID_W / 6.5 - @svg\add with @svg\line 0, -GRID_H, w, -GRID_H - \stroke o width: 2, color: '#ffffff', dasharray: "#{l}, #{l}" - - @svg\size w, h - @svg\viewbox 0, -h, w, h - @node = @svg.node - -addlabel = (label, diagram) -> - with div style: { display: 'inline-block', margin: '20px', 'text-align': 'center' } - \append diagram - \append div label - -figures = do - style = - display: 'flex' - 'align-items': 'flex-end' - 'justify-content': 'space-evenly' - (...) -> div { :style, ... } - -sources = do - short = => "#{@id} #{@year}" - long = => @names, " (#{@year}): ", (i @title), ", #{@published}" - { - { - id: 'Milgram', - title: 'Augmented Reality: A class of displays on the reality-virtuality continuum', - published: 'in SPIE Vol. 2351', - names: 'P. Milgram, H. Takemura, A. Utsumi, F. Kishino', - year: 1994 - :long, :short, - }, - { - id: 'Marsh', - title: 'Nested Immersion: Describing and Classifying Augmented Virtual Reality', - published: 'IEEE Virtual Reality Conference 2015', - names: 'W. Marsh, F. Mérienne', - year: 2015 - :long, :short, - }, - { - id: 'Billinghurst', - title: 'The MagicBook: a transitional AR interface', - published: 'in Computer & Graphics 25', - names: 'M. Billinghurst, H. Kato, I. Poupyrev', - year: 2001, - :long, :short, - }, - { - id: 'Matrix', - title: 'The Matrix', - year: 1999, - names: 'L. Wachowski, A. Wachowski', - long: => @names, " (#{@year}): ", (i @title), " (movie)" - short: => tostring @year - }, - { - id: 'Naam', - title: 'Nexus', - published: 'Angry Robot (novel)', - names: 'R. Naam', - year: 2012, - :long, :short, - } - } - -ref = do - fmt = (id) -> - - local src - for _src in *sources - if _src.id == id - src = _src - break - - if src - a { src\short!, href: "##{src.id}" } - else - span id - - ref = (...) -> - refs = { ... } - with span "(", fmt refs[1] - for i=2, #refs - \append ", " - \append fmt refs[i] - \append ")" - -references = -> - with ol! - for src in *sources - \append li { id: src.id, src\long! } - -sect = (label) -> - with section style: 'page-break-inside': 'avoid' - \append h2 label - -append with article style: { margin: 'auto', 'max-width': '750px' } - \append div 'Sol Bekic', style: 'text-align': 'right' - - \append h1 { - style: { 'text-align': 'center', 'font-size': '2em' }, - "Reality Stacks", - div "a Taxonomy for Multi-Reality Experiences", style: 'font-size': '0.6em' - } - - \append with sect "Abstract" - \append p "With the development of mixed-reality experiences and the corresponding interface devices - multiple frameworks for classification of these experiences have been proposed. However these past - attempts have mostly been developed alongside and with the intent of capturing specific projects ", - (ref 'Marsh', 'Billinghurst'), " or are nevertheless very focused on existing methods and technologies ", - (ref 'Milgram'), ". The existing taxonomies also all assume physical reality as a fixpoint and constant and are - thereby not suited to describe many fictional mixed-reality environments and altered states of consciousness. - In this paper we describe a new model for describing such experiences and examplify it's use with currently - existing as well as idealized technologies from popular culture." - - \append with sect "Terminology" - \append p "We propose the following terms and definitions that will be used extensively for the remainder of the paper:" - for definition in *{ - { "layer of reality": "a closed system consisting of a world model and a set of rules or dynamics operating on and - constraining said model." }, - { "world model": "describes a world state containing objects, agents and/or concepts on an arbitrary abstraction level." }, - '------', - { "reality stack": "structure consisting of all layers of reality encoding an agent's interaction with his environment - in their world model at a given moment, as well as all layers supporting these respectively." }, - '------', - { "physical reality": "layer of reality defined by physical matter and the physical laws acting upon it. - While the emergent phenomena of micro- and macro physics as well as layers of social existence etc. may be seen - as separate layers, for the purpose of this paper we will group these together under the term of physical reality." }, - { "mental reality": "layer of reality perceived and processed by the brain of a human agent." }, - { "digital reality": "layer of reality created and simulated by a digital system, e.g. a virtual reality game." }, - { "phys, mind, digi": "abbreviations for physical, mental and digital reality respectively." }, - } - if 'string' == type definition - \append hr! - continue - \append with div style: { 'margin-left': '2rem' } - term = next definition - \append span term, style: { - display: 'inline-block', - 'margin-left': '-2rem', - 'font-weight': 'bold', - 'min-width': '140px' - } - \append span definition[term] - - \append with sect "Introduction" - \append p "We identify two different types of relationships between layers in multi-reality environments. - The first is layer nesting. Layer nesting describes how some layers are contained in other layers; i.e. they exist - within and can be represented fully by the parent layer's world model and the child layer's rules emerge natively from - the parent layer's dynamics. Layer nesting is visualized on the vertical axis in the following diagrams. - For each layer of reality on the bottom of the diagram the nested parent layers can be found by tracing a line upwards - to the top of the diagram. Following a materialistic point of view, physical reality therefore must completely encompass - the top of each diagram." - - \append p "The second type of relationship describes the information flow between a subject and the layers of reality - the subject is immersed in. In a multi-reality experience the subject has access to multiple layers of reality and - their corresponding world models simultaneously.", br!, - "Depending on the specific experience, different types of and directions for information exchange - can exist between these layers and the subject's internal representation of the experience. - For the sake of this paper we distinguish only between ", (i "input"), " and ", (i "output"), " data flow (from the - perspective of the subject); categorized loosely as information the subject receives from the environment - (", (i "input"), ", e.g. visual stimuli) and actions the subject can take to influence the state of the world model - (", (i "output"), ", e.g. motor actions) respectively." - - \append p "In the following diagrams, information flow is visualized horizontally, in the region below the dashed line - at the bottom of the diagram. The subject's internal mental model and layer of reality are placed on the bottom left - side of the diagram. - The layers of reality that the subject experiences directly and that mirror it's internal representations are placed - on the far right. There may be multiple layers of reality sharing this space, visualized as a vertical stack of - layers. Since the subject must necessarily have a complete internal model of the multi-reality experience around - him to feel immersed, the subject's mental layer of reality must span the full height of all the layers visible - on the right side of the diagram.", br!, - "Information flow itself is now visualized concretely using arrows that cross layer boundaries in the lower part of - the diagram as described above. Arrows pointing leftwards denote ", (i "input"), " flow, whilst arrows pointing - rightwards denote ", (i "output"), "-directed information flow. In some cases information doesn't flow directly - between the layers the subject is directly aware of and the subject's internal representation and instead - traverses ", (i "intermediate layers"), " first." - - \append p "Before we take a look at some reality stacks corresponding to current VR and AR technology, - we can take a look at waking life as a baseline stack. To illustrate the format of the diagram we will compare it - to the stack corresponding to a dreaming state:" - - \append with figures! - \append addlabel "Waking Life", Diagram => - @mind! - @inout! - @phys! - - @next! - @phys '', 2 - @finish! - - \append addlabel "Dreaming", Diagram => - @mind! - @phys! - @finish! - - \append p "In both cases, the top of the diagram is fully occupied by the physical layer of reality, colored in green. - This is due to the fact that, according to the materialistic theory of mind, human consciousness owes its existance - to the physical and chemical dynamics of neurons in our brains. Therefore our mental reality must be considered - fully embedded in the physical reality, and consequently it may only appear underneath it in the diagram." - - \append p "During waking life, we concern ourselves mostly with the physical reality surrounding us. - For this reason the physical reality is placed in the lower right corner of the diagram as the layer holding the - external world model relevant to the subject. Information flows in both directions between the physical world model - and the subject's mental model, as denoted by the two white arrows: Information about the state of the world model - enter the subjects mind via the senses (top arrow, pointing leftwards), and choices the subject makes inside of and - based on his mental model can feed back into the physical layer through movements (lower arrow, pointing rightwards)." - - \append p "In the dreaming state on the other hand, the subject is unaware of the physical layer of reality, though - the mind remains embedded inside it. When dreaming, subjects' mental models don't depend on external models, hence - the mental layer of reality must be the only layer along the bottom of the diagram." - - \append with sect "Current Technologies" - \append p "Since recent technological advancements have enabled the development of VR and AR consumer devices, - AR and VR have been established as the potential next frontier of digital entertainment.", br!, - "As the names imply, the notion of reality is at the core of both technologies. - In the following section we will take a look at the respective stacks of both experience types:" - - \append with figures! - \append addlabel "VR", Diagram => - @mind! - @phys! - @inout nil, 1 - - @next! - @phys '', 2 - @inout nil, 1 - - @next! - @digi! - @phys '' - @finish! - - - \append addlabel "AR", Diagram => - @mind! - @inout nil, 1.25 - @inn nil, 0.5 - @phys! - - @next! - @phys '', 2 - @inn nil, .5 - - @next! - @digi nil, .5 - @phys '', 1.5 - @finish! - - \append p "In both cases we find the physical layer of reality as an ", (i "intermediate layer"), " between the mental - and digital layers. Actions taken by the subject have to be acted out physically (corresponding to the - information traversing the barrier between mental and physical reality) before they can be again digitized using - the various tracking and input technologies (which in turn carry the information across the boundary of the physical - and digital spaces)." - - \append p "The difference between AR and VR lies in the fact that in AR the subject experiences a mixture of the - digital and physical world models. This can be seen in the diagram, where we find that right of the diagram origin - and the mental model, the diagram splits and terminates in both layers: while information reaches the subject both - from the digital reality through the physical one, as well as directly from the physical reality, the subject only - directly manipulates state in the physical reality." - - \append p "The data conversions necessary at layer boundaries incur at the least losses in quality and accuracy of - information for purely technical reasons. However ", (i "intermediate layers"), " come at a cost larger than just - an additional step of conversion: - For information to flow through a layer, it must be encodable within that layer’s world model. - This means that the 'weakest link' in a given reality stack determines the upper bound of information possible to - encode within said stack and thereby limits the overall expressivity of the stack.", br!, - "As a practical example we can consider creating an hypothetical VR application that allows users to traverse a - large virtual space by flying. While the human mind is perfectly capable of imagining to fly and control the motion - appropriately, it is extremely hard to devise and implement a satisfying setup and control scheme because the - physical body of the user needs to be taken into account and it, unlike the corresponding representations in the - mental and digital world models, cannot float around freely." - - \append with sect "Future Developments" - \append p "In the previous section we found that the presence of the physical layer in the information path of - VR and AR stacks limits the experience as a whole. It follows that the removal of that indirection should be - an obvious goal for future developments:" - - \append figures addlabel "holy grail of VR: 'The Matrix'", Diagram => - @mind! - @inout! - @phys! - - @next! - @digi! - @phys '' - @finish! - - \append p "In the action movie 'The Matrix' ", (ref 'Matrix'), ", users of the titular VR environment interface with it - by plugging cables into implanted sockets that connect the simulation directly to their central nervous system.", br!, - "While these cables and implanted devices are physical devices, they don't constitute the presence of the - physical layer of reality in the information path because while they do transmit information, the information - remains in either the encoding of the mental model (neural firing patterns) or the encoding of the digital model - (e.g. a numeric encoding of a player character's movement in digital space) and the conversion is made directly - between those two - the data never assumes the native encoding of the physical layer (e.g. as a physical motion)." - - \append p "While we are currently far from being able to read arbitrary high-level information from the brain - or to synthesize sensual input in human perception by bypassing the sensory organs, brain-computer interfaces (BCI) - are a very active area of research with high hopes for comparable achievements in the near future." - - \append p "Applying this same step of removing the physical layer of reality from AR, we end up with something similar - to the nano-particle drug in ", (i "Nexus"), " ", (ref 'Naam'), ". However this does not grant the user a similar - amount of control over his experience as the holy grail of VR does, since the user and the physical part of the - environment remain bound by the physical layer of reality's laws.", br!, - "Instead the holy grail of AR is reached with the creation of a god machine that can manipulate the state of the - physical world according to the user's wishes. In this way the digital and physical realities become unified and - fully 'augmented'." - - \append with figures! - \append addlabel "'Nexus'", Diagram => - @mind! - @inout nil, 0.75 - @inout nil, 1.25 - @phys! - - @next! - @digi nil, .5 - @phys '', 1.5 - @finish! - - \append addlabel "holy grail of AR: 'Deus Machina'", Diagram => - col = '#92807c' - - @mind! - @inout! - @block col, '' - - @next! - @block col, '', 2 - @svg\plain('phys + digi')\attr(o fill: 'white', 'font-size': '14px')\move 6, -2 * GRID_H - @finish! - - \append p "Despite the similarities of VR and AR, the two can be considered polar opposites, as becomes evident when - we compare their respective utopian implementations: they share the goal of allowing us to experience realities - different from the one we naturally inhabit, but while VR seeks to accomplish this by creating a new, nested reality - inside ours, thus giving us full control over it. - AR, on the other hand, is instead an attempt to retrofit our specific needs directly into the very reality we exist - in.", br!, - "This is in direct contrast with the popular notion of the 'reality-virtuality continuum' ", (ref 'Milgram'), ": - the reality-virtuality continuum places common reality and VR (virtuality) as the two extreme poles, while AR - is represented as an intermediate state between the two. Here however we propose to view instead AR and VR as the - respective poles and find instead reality at the centerpoint, where the two opposing influences 'cancel out'." - - \append with sect "Conclusion and Further Work" - \append p "In this paper we have proposed a taxonomy and visualization style for multi-reality experiences, as well - as demonstrated it's flexibility by applying them as examples. Through the application of the proposed theory, - we have also gained a new and contrasting view on preceding work such as the reality-virtuality-continuum. - We have also found that the taxonomy can be used outside the research field of media studies and its use may extend - as far as philosophy of consciousness (see Appendix below)." - - \append p "Further research could enhance the proposed theory with better and more concrete definitions. - In the future, the proposed taxonomy might be used to create a more extensive and complete classification - of reality stacks and to analyse the relationships between them." - - \append with sect 'References' - \append references! - - \append with sect "Appendix: Relation to Theories of Mind" - \append p "This paper starts from a deeply materialistic point of view that borders on microphysicalism. - However it should be noted that the diagram style introduced above lends itself also to display other - philosophical theories of mind. As an example, the following graphics show a typical VR stack as interpreted by - Materialism, Cartesian Dualism and Solipsism respectively:" - - \append with figures! - \append addlabel "VR in Materialism", Diagram => - @mind! - @inout nil, 1 - @phys! - - @next! - @phys '', 2 - @inout nil, 1 - - @next! - @digi! - @phys '' - - @finish! - - \append addlabel "VR in Solipsism", Diagram => - @mind nil, 2 - @inout nil, 1 - - @next! - @digi! - @mind '' - @finish! - - \append addlabel "VR in Cartesian Dualism", Diagram => - @mind nil, 2 - @inout nil, 1 - @next! - - @phys nil, 2 - @inout nil, 1 - @next! - - @digi! - @phys '' - @finish! - - \append p "However these philosophical theories of minds also constitute reality stacks by themselves and as such can - be compared directly:" - - \append with figures! - \append addlabel "Materialism", Diagram => - @mind! - @inout! - @phys! - - @next! - @phys '', 2 - @finish! - - \append addlabel "Solipsism", Diagram => - @mind! - @finish! - - \append addlabel "Cartesian Dualism", Diagram => - @mind! - @inout! - @next! - - @phys! - @finish! - -_content diff --git a/root/research/text$moonscript -> fn -> mmm$dom.moon b/root/research/text$moonscript -> fn -> mmm$dom.moon deleted file mode 100644 index aec02d9..0000000 --- a/root/research/text$moonscript -> fn -> mmm$dom.moon +++ /dev/null @@ -1,10 +0,0 @@ -import div, h3, ul, li from require 'mmm.dom' -import link_to from (require 'mmm.mmmfs.util') require 'mmm.dom' - -=> - div { - h3 link_to @ - ul for child in *@children - desc = child\gett 'description: mmm/dom' - li (link_to child), ': ', desc - } diff --git a/root/research/title: text$plain b/root/research/title: text$plain deleted file mode 100644 index c985e65..0000000 --- a/root/research/title: text$plain +++ /dev/null @@ -1 +0,0 @@ -research diff --git a/root/research/watch-cad/description: text$plain b/root/research/watch-cad/description: text$plain deleted file mode 100644 index 75d7887..0000000 --- a/root/research/watch-cad/description: text$plain +++ /dev/null @@ -1 +0,0 @@ -immediate-mode scripting for direct-manipulation of graphics diff --git a/root/research/watch-cad/link: URL b/root/research/watch-cad/link: URL deleted file mode 100644 index fdee7eb..0000000 --- a/root/research/watch-cad/link: URL +++ /dev/null @@ -1 +0,0 @@ -https://git.s-ol.nu/watch-cad/ -- cgit v1.2.3