{"id":17681212,"url":"https://github.com/z64/odin0d","last_synced_at":"2026-01-07T18:39:02.458Z","repository":{"id":195730718,"uuid":"623281938","full_name":"z64/odin0d","owner":"z64","description":null,"archived":false,"fork":false,"pushed_at":"2023-05-30T19:30:05.000Z","size":3971,"stargazers_count":3,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-02-05T21:41:22.365Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Odin","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/z64.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2023-04-04T04:01:19.000Z","updated_at":"2023-06-24T11:29:03.000Z","dependencies_parsed_at":null,"dependency_job_id":"d131cee6-85fa-433d-9221-91e0374d98dd","html_url":"https://github.com/z64/odin0d","commit_stats":null,"previous_names":["z64/odin0d"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/z64%2Fodin0d","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/z64%2Fodin0d/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/z64%2Fodin0d/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/z64%2Fodin0d/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/z64","download_url":"https://codeload.github.com/z64/odin0d/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246365651,"owners_count":20765549,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-24T09:10:31.431Z","updated_at":"2026-01-07T18:39:02.413Z","avatar_url":"https://github.com/z64.png","language":"Odin","funding_links":[],"categories":[],"sub_categories":[],"readme":"# odin0d\n\nThis repo is a project organized for the [2023 Handmade Visibility Jam](https://handmade.network/jam) ([Project Entry](https://handmade.network/p/374/odin0d/)).\n\n## Files\n\n- [0d](./0d) - Reference 0d implementation package\n- [syntax](./syntax) - Syntax parser based on MxGraph diagrams\n- [demo_basics](./demo_basics) - Example using the 0d API manually\n- [demo_drawio](./demo_drawio) - Combines `0d` and `diagram` to show off hot loaded control flow based on a draw.io diagram file.\n\n## How To\n\nFirst, install [Odin](https://odin-lang.org).\n\nThere are two programs included:\n\n- [demo_basics](./demo_basics)\n- [demo_drawio](./demo_drawio)\n\nYou can run each with `odin run demo_basics` or `odin run demo_drawio` at the top level.\n\n`demo_drawio` will read the `example.drawio` file at the top of this repo.\n\nAlternatively, there is a `Makefile` you can use.\n\n### Diagram Editing\n\nFirst, load up [draw.io](https://draw.io) or download their desktop app.\n\n\nFrom their file dialog, you can open the included `example.drawio`.\nThis is diagram that `demo_drawio` will load at startup.\n\nYou can optionally load the included `scratchpad.xml`, which includes some prefabricated pieces of diagram to help you draw quickly.\nThe scratchpad section is found on the left sidebar.\nPress the pencil icon, then \"Import\" to load the scratchpad file.\n\n**Before you save, open File, Properties, and uncheck \"Compressed\".**\n\n\u003e The interpreter included does not implement decompression.\n\u003e However, this is recommended regardless, as the decompressed diagrams play much nicer with Git, etc.\n\nYou can make your edits according to the [Syntax](#syntax) section, then save the diagram back to disk.\n\n### Syntax\n\nThe current reference syntax implemented by `demo_drawio` is as follows:\n\n![Syntax Example](https://cdn.discordapp.com/attachments/602932100508942337/1099957457612185670/image.png)\n\n\u003e Note that what follows is a *reference implementation* of a diagram syntax.\n\u003e Implementations may choose to be more or less strict, interpret the same diagram differently, lint at compile or runtime, etc.\n\nGeneral rules:\n\n- Components can be in any orientation, size, or colors.\n- Components can have any number of inputs and outputs.\n- You can \"fan out\" an output to multiple destinations.\n- You can \"fan in\" an input to a single destination.\n- Any extra information (notes, images, ...) in the diagram is ignored.\n\n#### Components\n\n![Component](https://cdn.discordapp.com/attachments/602932100508942337/1099958520406872164/image.png)\n\nRectangles on the diagram represent Components.\nComponents are recognized by marking a rectangle as a \"container\" in draw.io.\n\nThe label of the rectangle is an identifier that refers either to native component (Leaf) or another container (page).\n\nYou can have multiple components drawn with the same name.\nGlobally, components with the same name refer to the same leaf code or container.\n\nPorts are recognized as any shape that is a child of this container, that also has some connections:\n\n- Arrows connecting towards the port represent inputs.\n  Messages delivered to the input will be seen by the component using the given port name.\n- Arrows connecting away from the port represent outputs.\n  Messages with matching port names will be delivered along that connection.\n\nThis allows some flexibility in how you visually configure ports on the component rect.\n\nPorts can have *any* name:\n\n- Any given port is exclusive to that component (aka port names are not global)\n- Input and output ports are exclusive (you can have inputs and outputs with the same names)\n- Multiple ports (input or output) with the same name effectively refer to the same port.\n\n#### Containers\n\n![Container](https://cdn.discordapp.com/attachments/602932100508942337/1099962043857129522/image.png)\n\nEach page of the diagram (tab along bottom of the interface) represents a container.\nThe page name is used as the name of the container.\n\n\nInputs to a container are identified using the Rhombus (diamond) shape.\nThe name on the rhombus identifies the input or output port to the container.\n\nIn the above example:\n\n1. Messages to the `main` container are routed to the inputs of `sub1` and `sub2`.\n   The pages `sub1` and `sub2` are used as the source for the `sub1` and `sub2` components.\n2. The containers described on the `sub1` and `sub2` pages execute and produce outputs.\n   These containers may contain other containers and leaf components, recursively.\n3. Then, the outputs of those subnetworks are routed to the `stdout` of `main`.\n\n#### Connections\n\nThe interpreter looks at the diagram and, using the above rules, interprets the diagram into connections.\n\nIn terms of diagram patterns:\n\n- A rhombus, connected to a shape, whose parent is a rect container, is a Down connection.\n- A shape, whose parent is a rect container, connected to another shape whose parent is a rect container, is an Across connection.\n- A shape, whose parent is a rect container, connected to a rhombus, is an Up connection.\n- A rhombus, connected to another rhobus, is a Through connection.\n\nOr, in terms of the runtime:\n\n- Container input to component input is a Down connection.\n- Component output to component input is an Across connection.\n- Component output to container output is an Up connection.\n- Container input directly to container output is a Through connection.\n\n### Runtime\n\nThe reference runtime included in the `0d` directory is intended as such.\nThe demo is intended to communicate the core concepts with minimal LoC.\n\nSince the focus was on making a hot reloading control flow network, type checking of messages is done at runtime as well.\nIf you route a message to a leaf component with a type that it does not handle, it will currently assert for the purposes of this demo.\n\nMemory management is done by copying message data onto the heap while it is in transit.\nWhen the message is delievered, or no destination for the message is found, it is freed.\n\nJust like normal functions, leaves should be careful to not send pointers to data in the current frame.\n\nAlternative implementations may consider different memory representations for messages or organization of component queues.\n\n## Authors\n\n- Paul Tarvydas - 0d author ([Programming Simplicity Blog](https://publish.obsidian.md/programmingsimplicity/), [GitHub](https://github.com/guitarvydas))\n- Zac Nowicki - Odin Implementarion ([Kagi](https://kagi.com), [GitHub](https://github.com/z64))\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fz64%2Fodin0d","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fz64%2Fodin0d","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fz64%2Fodin0d/lists"}