334 lines
11 KiB
Org Mode
334 lines
11 KiB
Org Mode
#+TITLE: Undâr Roadmap
|
|
#+AUTHOR: Zongor
|
|
#+EMAIL: archive@undar-lang.org
|
|
#+DATE: [2025-04-05]
|
|
#+LANGUAGE: en
|
|
#+OPTIONS: H:4 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
|
|
#+STARTUP: align fold nodlcheck hidestars oddeven lognotestate
|
|
#+TAGS: { TODO(t) NEXT(n) DONE(d) | HOLD(h) WAITING(w) CANCELLED(c) }
|
|
#+PROPERTY: header-args :tangle-mode (identity #o0644)
|
|
|
|
* Roadmap
|
|
|
|
** Example: Hello world (=hello.ul=)
|
|
*WIP syntax, not final implementation**
|
|
|
|
#+BEGIN_SRC ul
|
|
/**
|
|
* Constants
|
|
*/
|
|
const str nl = "\n";
|
|
|
|
plex Terminal {
|
|
nat handle;
|
|
}
|
|
|
|
/**
|
|
* Main function
|
|
*/
|
|
function main() {
|
|
pln("nuqneH 'u'?");
|
|
}
|
|
|
|
/**
|
|
* Print with a newline
|
|
*/
|
|
function pln(str message) {
|
|
Terminal term = open("/dev/term/0", 0);
|
|
write(term, message, message.length);
|
|
write(term, nl, nl.length);
|
|
}
|
|
#+END_SRC
|
|
|
|
** Example: 3D Client (=client.ul=)
|
|
|
|
**WIP syntax, not final implementation**
|
|
|
|
Common:
|
|
|
|
#+BEGIN_SRC ul
|
|
/**
|
|
* Camera.
|
|
*/
|
|
plex Camera {
|
|
int setting;
|
|
real pov;
|
|
real[3] up;
|
|
real[3] pos;
|
|
real[3] look;
|
|
|
|
init(real[3] pos, real[3] look) {
|
|
this.setting = CAMERA_PERSPECTIVE;
|
|
this.pov = 45.0;
|
|
this.up = [0.0, 1.0, 0.0];
|
|
this.pos = pos;
|
|
this.look = look;
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Player.
|
|
*/
|
|
plex Player {
|
|
Client client;
|
|
str username;
|
|
real[3] pos;
|
|
nat color;
|
|
Camera camera;
|
|
|
|
init(str username, real[3] pos, Color color) {
|
|
this.client = Client("tcp://localhost:25565");
|
|
this.username = username;
|
|
this.pos = pos;
|
|
this.color = color;
|
|
this.camera =
|
|
Camera([this.pos.x + 10.0, this.pos.y + 10.0, this.pos.z], this.pos);
|
|
}
|
|
|
|
login(str password) Player[] { // looks like a method but really it just has an implied "Player this" as the first argument
|
|
this.client.attach(this.username, password);
|
|
this.players = client.open("players");
|
|
return players.read();
|
|
}
|
|
|
|
logout() {
|
|
this.players.flush();
|
|
this.client.clunk();
|
|
}
|
|
|
|
update() {
|
|
if (key_down("right")) {
|
|
this.pos.x += 0.2;
|
|
this.client.write(Command(this.username, KEY_RIGHT))
|
|
}
|
|
|
|
if (key_down("left")) {
|
|
this.pos.x -= 0.2;
|
|
this.client.write(Command(this.username, KEY_LEFT))
|
|
}
|
|
|
|
if (key_down("down")) {
|
|
this.pos.z += 0.2;
|
|
this.client.write(Command(this.username, KEY_DOWN))
|
|
}
|
|
|
|
if (key_down("up")) {
|
|
this.pos.z -= 0.2;
|
|
this.client.write(Command(this.username, KEY_UP))
|
|
}
|
|
this.camera.sync();
|
|
}
|
|
}
|
|
|
|
const nat RED = rgb332([255, 0, 0]);
|
|
const nat WHITE = rgb332([0, 0, 0]);
|
|
const nat PURPLE = rgb332([255, 255, 0]);
|
|
#+END_SRC
|
|
|
|
Client:
|
|
#+BEGIN_SRC ul
|
|
use <str.ul>; // from stdlib
|
|
use "common.ul"; // from local
|
|
|
|
function main(int argc, str[] argv) {
|
|
nat screen_width = 800;
|
|
nat screen_height = 450;
|
|
|
|
if (argv < 2) {
|
|
pln("usage: undar client.ul <username> <password>");
|
|
exit(-1);
|
|
}
|
|
str username = argv[1];
|
|
str password = argv[2];
|
|
|
|
Player me(username, [0.0, 1.0, 2.0], PURPLE);
|
|
|
|
bool running = true;
|
|
while (running) {
|
|
window("zwl client", screen_width, screen_height) {
|
|
splitbox(parent.size 0.25) {
|
|
canvas() {
|
|
if (button("logout")) {
|
|
me.logout();
|
|
running = false;
|
|
}
|
|
}
|
|
}
|
|
splitbox(parent.size 0.75) {
|
|
canvas() {
|
|
model(Floor([0, 0, 0], 30));
|
|
me.update();
|
|
model(Cube(me.pos, [0.5, 0.5, 0.5], me.appearance));
|
|
if (Player[] players = me.server.read("players")) {
|
|
for (p in players) {
|
|
model(Cube(p.pos, [0.5, 0.5, 0.5], p.apperance));
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
exits("Client Closed Successfully");
|
|
}
|
|
#+END_SRC
|
|
|
|
Server:
|
|
#+BEGIN_SRC ul
|
|
use "common.ul";
|
|
|
|
function main(int argc, str[] argv) {
|
|
Server s("tcp://0.0.0.0:25565");
|
|
bool running = true;
|
|
Player[] players = [Player("user", [0.0, 0.0, 0.0], RED)];
|
|
while (running) {
|
|
if (Client client = s.accept("players")) {
|
|
if (Message message = client.get()) {
|
|
if (message.t == "close") {
|
|
client.close();
|
|
running = false;
|
|
} else if (message.t == "players") {
|
|
client.write(players);
|
|
} else {
|
|
print("unknown message {message}");
|
|
}
|
|
}
|
|
}
|
|
}
|
|
exits(nil);
|
|
}
|
|
#+END_SRC
|
|
|
|
** Plex
|
|
|
|
A =plex= is a structure which, works like a struct but syntactically looks like a class. the naming of "plex" comes from douglas ross's paper "a generalized technique for symbol manipulation and numerical calculation". It is used instead of "class" or "struct" is to make a break from the historical baggage of "classes". unlike classes it does not describe a object in real life and copy it, but it allows for a convenient way to mediate states and handling. i.e. compositions + encodings instead of oop/polymorphisms. for example, instead of having a struct with a bool flag in it (like for a game alive/dead), we can create a multilist where the structs move from a "alive" list to a "dead" list; or things like that. instances of a plex in memory are called "atoms".
|
|
|
|
Plexes support permacomputing by allowing the developer to use lower level interfaces with a friendly syntax.
|
|
|
|
**WIP syntax, not final implementation**
|
|
|
|
#+BEGIN_SRC ul
|
|
plex Player {
|
|
str name;
|
|
real[3] pos;
|
|
|
|
init(str name, real[3] pos) {
|
|
this.name = name;
|
|
this.pos = pos;
|
|
}
|
|
update() {}
|
|
logout() {}
|
|
}
|
|
#+END_SRC
|
|
|
|
the language is statically typed and similar to c but with some array semantic ideas from fortran like row major, fortran style replaces need for vec or mat. arrays are first class values, the compiler uses optimized opcodes for array manipulation.
|
|
|
|
**WIP syntax, not final implementation**
|
|
|
|
#+BEGIN_SRC ul
|
|
real[3] pos = [1.0, 2.0, 3.0];
|
|
real[3][3] mat = identity(3);
|
|
real[3] result = mat * pos; ! compiler generates matrix-vector multiply
|
|
#+END_SRC
|
|
|
|
- Row-major order
|
|
- Fat pointers for slices and strings
|
|
- No =vec3=/=mat4x4= structs needed
|
|
- Supports composition, slicing, element-wise ops
|
|
|
|
it has a abstraction layer for devices that work as system calls that can open, read, write, close, and use ioclt for extra system calls that are beyond ops.
|
|
|
|
** Devices
|
|
|
|
(partially implemented)
|
|
|
|
core devices include
|
|
- screen
|
|
- mouse
|
|
- keyboard
|
|
- terminal
|
|
- tunnel
|
|
|
|
Devices are accessed via a namespace "path/to/device" and are implemented outside of the VM's runtime. This allows for the interface of the system to be the same within the VM but allow for specific variations on a concept depending on the device it is running on.
|
|
|
|
*** Immediate Mode GUI
|
|
|
|
UI elements are draw directly on the canvas and syntactically are spacial to show which elements are child elements of each other. Calling a function is the equivalent of a redraw of that element
|
|
|
|
*** 3D Modeling
|
|
|
|
3D Primitives + Constructive solid geometry (Similar to OpenSCAD or .kkrieger) allow for the construction of more complex 3D models from the manipulation of primitives. It also has the ability to create textures dynamically similar to .kkrieger, textures can be imported and auto mipmapped from larger sizes down to the internal RGB332 + 8x8 - 32x32 tile system.
|
|
|
|
** Tunnels: Unified I/O (Plan 9 / 9P-Inspired)
|
|
|
|
Tunnels are an abstraction called a tunnel which acts like a device like a screen, mouse, etc. that is inspired by Plan9. Plan 9 was an operating system developed at Bell Labs that treated all resources (including network connections and UI elements) as files in a hierarchical namespace. it allows files, web requests, sockets, etc. to be viewed through a simple unified interface. it is very similar to the 9p protocol where everything is a file in a filesystem, it just might be a file located on a server halfway across the world or on another planet. the only thing that is the difference is that it takes longer to read the file on mars compared to the file on your local system. the way the device system works is that it is written by a developer in another language like c, but from Undâr's pov the interface remains the same, its just a namespaced device like all the other devices, so that it is easy to understand by a new developer. so it is comparable with tcp/udp sockets or something esoteric like a lorawan network, or some new communication method that hasn't been invented yet.
|
|
|
|
**WIP syntax, not final implementation**
|
|
|
|
#+BEGIN_SRC ul
|
|
Tunnel server = Tunnel("tcp://localhost:25565");
|
|
if (server.attach(auth)) {
|
|
Player[] players = server.read("players");
|
|
server.write("me", me.update());
|
|
server.clunk();
|
|
}
|
|
#+END_SRC
|
|
|
|
*** Tunnel Operations
|
|
|
|
| Op | Meaning |
|
|
|------------+-------------------------------------------------------------------|
|
|
| =.attach()= | Authenticate and open communication |
|
|
| =.open()= | opens a tunnel for doing operations on |
|
|
| =.create()= | creates the plex from the database graph file from file structure |
|
|
| =.remove()= | removes the plex from the database graph file from file structure |
|
|
| =.read()= | reads from a tunnel |
|
|
| =.write()= | writes to a tunnel |
|
|
| =.walk()= | moves around the filesystem or through the graph |
|
|
| =.flush()= | cancels long operation and dumps whatever is in buffer |
|
|
| =.clunk()= | Close communication |
|
|
| =.stat()= | returns the status of the file resource |
|
|
| =.version()= | returns the version code for the connected tunnel |
|
|
|
|
** Actor System
|
|
|
|
*** Core Principles
|
|
- Deterministic memory management with no garbage collection or manual free
|
|
- Zero fragmentation via contiguous arena allocation
|
|
- Isolated memory spaces for all actors (no shared memory)
|
|
- Compile-time memory bounds enforcement
|
|
|
|
*** Memory Architecture
|
|
- Actor memory is partitioned into fixed-size arenas
|
|
- Two primary arenas:
|
|
- =Main Thread Arena= (top of memory)
|
|
- =Actor Arenas= (bottom-up allocation)
|
|
- Arena layout:
|
|
#+begin_src text
|
|
|---------------------| <-- Top of memory
|
|
| MAIN THREAD | (e.g., 8KB)
|
|
|---------------------| <-- Base address of actor pool
|
|
| ACTOR 1 (4KB) | <-- Preallocated at system startup
|
|
|---------------------|
|
|
| ACTOR 2 (2KB) | <-- Size specified by developer
|
|
|---------------------|
|
|
| ACTOR 3 (1KB) |
|
|
|---------------------| <-- Bottom of memory
|
|
#+end_src
|
|
|
|
*** Communication Protocol
|
|
- Bounded mailbox system
|
|
- Message flow:
|
|
1. Main thread sends via =send_message()=
|
|
2. Message copied into actor's mailbox
|
|
3. Actor processes in =on_message()= during next cycle
|
|
4. Actor sends response via =send_response()=
|
|
|
|
*** Failure Behaviors
|
|
| Behavior | Action | Certification Impact | Example Use Case |
|
|
|----------+-------------------------+----------------------+-------------------------|
|
|
| =RESTART= | Reset arena offset to 0 | 2 artifacts | Network reconnection |
|
|
| =EXIT= | Free arena | 1 artifact | Session termination |
|
|
| =CRASH= | Halt entire VM | 1 artifact | Critical subsystem fail |
|