Coder Legion - Recent posts tagged divooka

DevLog 20261002: Desktop Automation Toolbox and Mouse Emulation

Fri, 02 Oct 2026 15:16:32 +0000

DevLog 20261002: Desktop Automation Toolbox and Mouse Emulation

I remember when I used to use Macro Recorder to automate simple repetitive tasks — I especially liked its macro recording feature. It requires no programming and can easily get tedious jobs involving clicking and waiting done.

Since then, I've long moved past automating with basic mouse/keyboard emulation and have sunk deep into an API-driven approach — I just love how clean everything is when you can really program it. Well, that's a major reason why I started Divooka in the first place — lots of ecosystems and lots of tools we use are broken beyond repair and inherently NOT designed to be automated cleanly. MCP partly addressed that problem, but it's really just a modern remedy for mediocre design.

Either way, when I set out to implement procedural context for Divooka, desktop automation is nonetheless one of the first things that comes to mind. As we get more mature in OOP programming, generics, and recently achieved a true data structure algorithm implementation in Divooka, that is drawing closer.

In this short video, I show a desktop example for the automation toolbox that will come with the upcoming Divooka Explore. It's small, but it shows quite a few interesting things:

It creates a countdown GUI using the Immediate GUI framework.
It interacts with an opened window — in this case, the Paint program — through keyboard shortcuts and mouse input.
It can parse a stroke-based font at runtime and draw text with it.

If you ask me, that's a lot of cool features in such a small example! Really excited, and there's still more work to do, so see you soon!

Two-Year Reflection on Methodox and the Development of Divooka

Sun, 20 Sep 2026 22:00:11 +0000

Still going strong, and hopefully we will be ready soon.

The Divooka Story

It's surprising to count—it has already been so many years since the first prototype in 2022, the later attempted updates in 2023/2024, the first "beta" in September 2024 that we later downplayed to something closer to an "alpha", the internal builds throughout 2025, the much greater feature expansion towards 2026, and now, over the past few months, what I hope will be the "final" major round of architectural refactoring around the runtime, file format, package management, and features needed for professional use. I just wish I didn't age at the same rate as my software concept.

I spent a lot of time earlier this year, particularly around June, polishing DSLs—Domain-Specific Libraries—because without a useful set of higher-level capabilities, Divooka is JUST a language. A language can be technically interesting while still leaving the user to build everything themselves; the point of Divooka is eventually to provide useful computational building blocks at a much higher level. The areas I've chosen to focus on are naturally the areas I know reasonably well—not necessarily the areas where I would claim to be the world's greatest expert, but areas where I think we can make genuinely useful tools for everyday work: data processing, procedural terrain generation, graphics and media work, automation, and office productivity.

The procedural context in particular took a lot of effort to conceptualize. I wanted to address several problems I have experienced with node-based systems such as Unreal Engine's Blueprint: large procedural graphs can become difficult to restructure, reuse and reason about, while certain programming patterns are awkward to express visually in the first place. Divooka's procedural context is my attempt to retain the visibility of graph-based programming without pretending that traditional programming concepts such as loops, branches, functions and structured control flow somehow stopped being useful. The move towards a compiled runtime was another major jump, and really only came together around April and May 2026. Our Mandelbrot benchmark makes the motivation rather obvious: compilation changed the performance characteristics dramatically compared with execution through the older editor/runtime paths. Fully embracing compilation has been a major undertaking, but I increasingly see it as essential if Divooka is going to combine very high-level programming with acceptable performance. More details and the limitations of the benchmark are published in the GitHub repository linked below.

The file format, runtime and standardization work has been another recurring problem. This is also why we have deliberately slowed down on declaring a final version of DiDS or other Divooka Open Standards. The formats have changed A LOT as the architecture has matured, and publishing something as "final" before we are prepared to support it for years would create more problems than it solves. I don't see much value in pretending the specification is frozen merely for the satisfaction of calling it 1.0. Stability matters, interoperability matters, and eventually backward compatibility matters—but those things are much easier to promise after the underlying system has actually settled.

So where are we going? General-purpose at the core, high utility and high performance, while keeping a super-high-level interface closer to the experience of scripting languages than traditional application development. Nodes where nodes make things clearer, code where code makes things clearer, and enough interoperability underneath that users are not trapped inside an isolated visual-programming island. For people already familiar with programming language design, scripting systems and visual development environments, that probably explains most of the idea. At this point, I am content with that.

Internal and Financial

The financial side became more challenging as we moved through 2026. We are now entering our third year and completing our second, and naturally the resources that felt relatively abundant when I started the company in 2024 are more constrained today. Legal work, IP, infrastructure, hiring and contracting all cost real money, and founder time has a cost even when it doesn't appear as a salary on an income statement. I also did not exactly enter this adventure after ten years of living like a monk and accumulating an infinite personal runway. At some point every bootstrapped founder has to ask the uncomfortable but necessary question: how long can this continue before the business itself has to carry more of the weight?

That doesn't mean I suddenly regret doing it. I am still relatively young—a little over 30—but two years is long enough that the startup can no longer be treated as a temporary experiment detached from the rest of life. I have to think about long-term financial stability, savings, retirement and everything else that continues existing regardless of whether somebody decides to build a visual programming system. There is no magical funding event I can responsibly assume will arrive and solve those questions for me, so one way or another the company has to become increasingly sustainable on its own. In that sense, commercialization is becoming more important, not because the R&D suddenly matters less, but because the only durable way to continue doing the R&D is to build a business capable of supporting it.

I doubt I would particularly enjoy going back to conventional corporate life, although occasionally I do miss parts of it: working in those skyscrapers, looking down at people and cars twenty floors below as little moving dots, the view of Lake Ontario, interesting corporate events, colleagues with very different expertise, and simply being part of something much larger. But it is fundamentally different from being one's own boss. In a large organization I could sometimes lose sight of why a particular piece of work existed in the first place; here, almost every decision is connected directly to something we eventually put in front of users. Maybe one day a smaller studio environment would suit me too, but there is something uniquely rewarding about being able to make a decision, build the thing, and then see something made by us actually published.

That is something to think about. We need to act soon—not out of panic, but because after two years, sustainability deserves to be treated as part of the engineering problem rather than something outside of it.

Noise, Splashes and Small Gadgets

The development process also spun off a surprising number of smaller products. Some were experiments, some became quite handy, and some have already gone through several iterations of their own. I don't really see these as completely separate from Divooka: in many cases they came from technologies, libraries, ideas or workflows developed while working on the larger system, and they give us smaller places to test whether those pieces are actually useful outside the environment in which they were invented.

Released / scheduled: Fantasy Planet Painter, A Detective Story and Divooka Explore.

Smaller apps: Methodox Threads, Methodox Voxel Sandbox, and Transcriber—which has been surprisingly popular as a free tool.

It sometimes feels like we spent a lot of time on each of these, and then when I actually count the list it somehow doesn't look like that much. Such is software development.

Public-Facing

On the product-readiness side, we've updated the official Methodox website, added dedicated websites for the main products, greatly expanded the Methodox Wiki, and gone through migrations away from systems such as Wiki.js and WordPress in the process. The public surface of a software company is itself a substantial product: documentation, downloads, storefronts, licensing information, release notes, product pages and examples all have to remain reasonably synchronized with software that is changing underneath them. That work is less glamorous than implementing a compiler or graph runtime, but without it there isn't really a product that an outside person can confidently understand or use.

The CI, packaging and deployment side has improved as well. Those processes had remained painfully manual for much longer than I would have liked, and ironing out the development pipeline has been one of those improvements that is difficult to advertise but immediately makes everything else easier. Releasing software should eventually become boring. If every build and publication feels like a special event requiring a checklist of mysterious manual steps, something in the engineering process is still unfinished.

Lessons

Looking back to my reflection from July 8 last year, the burden from training, external obligations and general management has been reduced considerably. A surprising amount of time last year disappeared into accounting and tax work, which was not exactly why I founded a software company, but I suppose—and I must believe—that doing something three times makes the fourth much less intimidating. More importantly, I think I now have a better understanding of what actually makes a "product", especially the amount of work between something technically functioning and something polished enough to release, document, announce and support. A feature being implemented is not the same thing as a product being finished. That distinction sounds obvious until you repeatedly experience how much work lives between those two points.

One thing I still don't do enough is "engage with the community". I understand why people keep emphasizing it, and I don't think building completely in isolation is healthy, but my view has become more nuanced over the past year: community engagement becomes substantially more useful when there is something coherent for that community to engage with. Feedback on a moving architectural target can easily turn into noise for both sides. Divooka Explore's Early Access period should give us a better mechanism for that interaction, because users can increasingly react to a functioning system rather than an abstract promise.

Things such as cloud services through Methodox One, AI integration through projects such as Chat Gateway, and various other interesting ideas people suggested all pulled my attention in different directions. In retrospect, the core runtime was simply not ready enough for that level of expansion, even towards the middle of 2026. It was really only over the past month or so that I began feeling that the foundation was taking good shape and, more importantly, starting to feel robust and trustworthy. The runtime took an unexpectedly long time to develop even though I am no stranger to making scripting systems: EasyShell worked well for what it was designed to do, and I have been using Pure in one form or another since my time at OTPP. But Divooka is a fundamentally larger undertaking. Creating a new syntax, graph model, execution system, editor, IDE, packages, interoperability layer and application model from the ground up is very different from building a convenient language layer on top of an existing interface. We absolutely use existing foundations—Roslyn, .NET, C#, Python and their enormous ecosystems—but there are still a remarkable number of edges that become our responsibility the moment we try to make them feel like one coherent system.

Launching the product has always been a priority, but during roughly the first year and a half I have to admit that I spent too much attention on what I thought I was supposed to be doing as an "entrepreneur": conferences, investor calls, chasing VC conversations, networking because people said networking was important, and generally talking about building the company while I was still trying to build the thing the company exists to make. Some friends still tell me I haven't talked to enough people, and they may well have a point. But I've also learned that there is a limit to how much external motion is useful before it becomes noise. Right now I care much more about making Divooka real, solid and usable. There will always be more people to talk to afterwards.

The AI Gain

I am finally starting to officially "use AI" in a much more meaningful way—more precisely, coding agents. I have used ChatGPT on a near-daily basis for quite a long time, while also being fairly critical of media coverage portraying every new model as immediately revolutionary. For a long time I simply didn't find the reality matched the hype. That has changed considerably through the middle of 2026, and especially since late July. Coding agents have become useful enough that I can no longer dismiss them as an unreliable novelty: for certain kinds of implementation, research, repetitive work and review, they are genuinely efficient.

That does not mean I suddenly believe an AI is going to independently build Divooka for us. In practice it feels much more like a reduction in the cost of certain kinds of labour. It can generate, inspect, compare, research and iterate very quickly, but somebody still has to decide what ought to exist, whether the proposed architecture makes sense, whether the output actually works, and whether any of it belongs in the product. If anything, human capacity has become a more obvious bottleneck: judgment, prioritization and verification do not disappear merely because implementation becomes cheaper. The useful question is no longer "is AI useful?" but "which work should we delegate to it, which work should we keep doing ourselves, and how do we verify the difference?" That is a much more practical question, and one I expect will continue changing rapidly.

Conclusion

The one thing I would most like to see now is Divooka properly released. But my philosophy throughout this project has been that some steps simply cannot be skipped. That is part of the reason I quit my job and went deep into R&D in the first place: if the only objective had been to ship something quickly, there were much easier products I could have chosen to build.

I still look forward to the day when I can produce a fully illustrated, properly written Introduction to Visual Programming with Divooka. In my head I can already see it as an entire textbook covering a way of thinking about programs that is still poorly represented in conventional computer science education—not "visual programming" as a collection of toy blocks, and not simply a diagrammatic wrapper around scripting, but a serious treatment of graphs as a practical programming medium alongside text. If we can eventually build a system rich enough that such a book genuinely deserves to exist, I think that will be an achievement in its own right.

And I think that is worth taking the time to get right.

References

Methodox Official Website: https://methodox.io
Divooka Official Website: https://divooka.com
Methodox Wiki: https://wiki.methodox.io
Methodox Apps: https://methodox.app
Steam Divooka Explore page: https://store.steampowered.com/app/4422920/Divooka_Explore/
Steam Fantasy Planet Painter page: https://store.steampowered.com/app/3336490/Fantasy_Planet_Painter/
Itch.io Store Front: https://methodox.itch.io
Mandelbrot Benchmark: https://github.com/MethodoxTech/DivookaBenchmark_Mandelbrot

Methodox Voxel Sandbox | Launch Trailer | Methodox Voxel Scene Viewer

Wed, 26 Aug 2026 18:55:20 +0000

Methodox Voxel Sandbox is a Windows-only voxel world generator, editor and renderer. You can randomly generate a voxel environment, build inside it, then photograph it with a digital camera.

Core Features

Seed-Based World Generation: Automatically rolls and generates expansive voxel environments from a given seed.
First-Person Editor: Walk through the world from a first-person perspective to interact, break blocks, and build new structures.
Progressive Path Tracer (Photo Mode): Renders scenes progressively with light bouncing, glass refraction, metal reflections, glowing objects, clouds, and soft shadows.
Advanced Camera and Image Controls: Fine-tune renders with settings for lenses, lights, quality, exposure, and tone mapping.
255-Slot Material Palette: Build with terrain, vegetation, ores, glass, metal, lights, and full color ramps.

Methodox Voxel Scene Viewer: Included download tool that opens external voxel scenes (such as .vox, Goxel, OpenVDB, and MCEdit schematics) at any scale to render them with the path-tracing engine.

DevLog 20260731: FPP v1.4.0 and Divooka Explore Demo Updates

Sat, 01 Aug 2026 18:44:44 +0000

Overview

The past few months have seen several Divooka Explore Demo releases, with our efforts focused on rolling out procedural terrain generation features. These include random noise-based terrain generation, procedural and simulation-based terrain processing, natural effects such as erosion and hydrology analysis, procedural coloration and texturing, and, more recently, improved 3D previews of generated terrains directly within the Divooka visual programming environment.

One small lesson from this cumulative effort is that there always seems to be more academic material, papers, tutorials, online examples, and even source code snippets to discover and use to improve existing systems. That is a shiny silver lining, since we are still fairly new to this domain and desperately need broad exposure to existing techniques.

Another useful lesson is that, although many papers approach these subjects from a real-time rendering perspective - such as the old GPU Gems articles - the same techniques are often equally applicable in a pure-CPU regime.

Procedural Terrain Generation in Divooka

As mentioned, we have made quite a large number of functions available in this area, and the subject definitely warrants much more detailed treatment. Documentation and comprehensive video guides are dearly needed.

To recap, we have moved from very basic noise-based terrain generation to custom heterogeneous multifractal terrains, functional erosion - although there is still plenty of room for improvement - various masking techniques, practical procedural coloring using either masks or SQL queries, and preliminary texturing support.

The terrain generation is only the first step, and there is still plenty of room for improvement despite we have achieved useful basic implementation for now.

Once we became comfortable with generating functional procedural terrains, we could move on to coloring, texturing, and eventually shading.

At this point, I realized a fundamental limitation of heightmaps and image textures. They may be able to represent distant views of terrains spanning 8–64 km when viewed from above, but for ground-level rendering, procedural shading techniques are a must.

The 3D rendering work is still new, and there is a long way to go. We started with basic baked shadows, moved on to experimental texture mixing, and eventually reached full PBR rendering.

PBR rendering is the holy grail. Once we figure out how to dynamically populate terrains with trees, grass, and rocks - and generate ripples across reflective water - we will be able to share all of it through Divooka as reproducible workflows!

Below is an intermediate result so far. It uses simple slope-based texturing, which we plan to replace with mask-layer-based materials in the next attempt.

We have learned so much and cannot wait to share more about the specific techniques once we have more spare time!

The Fantasy Planet Painter v1.4.0 Update

While the eventual goal is to support whole-planet procedural generation and content management, we began with basic Earth-like world map generation. At the moment, our work is mostly focused on improving the existing editing experience. The previous update significantly improved the multithreaded generation performance of the tetrahedral subdivision method.

The 2D cell-based height-value canvas is an interesting medium. It allows us to sketch the desired elevation levels quickly at a high level while the program procedurally populates the remaining details.

There has also been some experimental exploration into using this medium for direct 2D terrain editing, as seen in our previous video, World to Beyond (BAR map export from FPP). Although BAR export is still in its early stages, the potential of this kind of authoring technique is indeed interesting.

Following the advances in procedural terrain generation within Divooka, we have gathered quite a collection of useful tools and made them available at a high level in the latest FPP update.

The results are very interesting, and I am glad that we are moving beyond practical utility toward generating worlds that - at least in my eyes - are also visually appealing.

Conclusion

That is a brief recap for today. I have been busy diving headfirst into all the nitty-gritty work, which has left less time for DevLog updates and for sharing the techniques and progress behind them.

Still, let us look forward to the day when new results are ready to shine, when we are comfortable placing an early-access version of Divooka into the hands of users, and when we can talk in much greater detail about the road that led us there!

Designing a Binary Data API for Divooka with PPM and PLY Examples

Tue, 12 May 2026 20:29:24 +0000

Revision: 001
Last Update: 2026-05-12

One thing I feel is not discussed enough in typical programming conversations is working with binary data. It often seems as though there is a ready-to-use library for whatever data type we need. But that illusion breaks whenever we want to do something new, interface with a less common format, work with legacy data, or build high-performance applications around custom data formats.

Designing a custom data format that fits the application at hand is an important skill. In this post, however, we will focus less on the philosophy and more on the operational details.

Binary formats are everywhere: images, meshes, save files, network packets, custom asset bundles, compressed streams, hardware protocols, game data, and many old file formats that are still useful decades later. Yet in application code, binary parsing often becomes messy very quickly. You start with a byte[], then an offset integer, then a few helper methods, then nested offset calculations. Before long, the parser has two responsibilities at once: understanding the file format and manually managing where the cursor is.

File Container Formats WikiCommons

Design Motivation

At a higher abstraction level, the goal of Divooka is to move cursor-management logic into something closer to Kaitai Struct or DFDL, the Data Format Description Language. This makes it easier to work with standardized, well-documented formats such as RIFF.

Instead of writing code like this:

int offset = 0;

string magic = Encoding.ASCII.GetString(bytes, offset, 4);
offset += 4;

int version = BinaryPrimitives.ReadInt32LittleEndian(bytes.AsSpan(offset, 4));
offset += 4;

int count = BinaryPrimitives.ReadInt32LittleEndian(bytes.AsSpan(offset, 4));
offset += 4;

we want this:

var remaining = ImmutableByteArrayReader.FromFile("Data.bin")
    .ReadString(4, out string magic)
    .ReadInt(out int version)
    .ReadInt(out int count);

This is similar in spirit to a stream-based API:

using var reader = new BinaryReader(stream, Encoding.ASCII, leaveOpen: true);

string magic = Encoding.ASCII.GetString(reader.ReadBytes(4));

int version = reader.ReadInt32();
int count = reader.ReadInt32();

The involved types here are ImmutableByteArrayReader, MutableByteArrayWriter, and ImmutableByteArrayWriter, all exposed through a fluent API. The parser reads like the binary format itself.

The writer mirrors that idea:

var data = new MutableByteArrayWriter()
    .WriteStringFixedSize("DATA")
    .WriteInt(version)
    .WriteInt(count);

The idea is simple: binary data should be represented as a sequence of explicit read and write operations, not as scattered offset arithmetic.

Reading Binary Data

Binary Buffer Reader: `ImmutableByteArrayReader`

ImmutableByteArrayReader is a reader-oriented abstraction over binary data.

It is immutable. Reading from it does not mutate the current object. Instead, read operations return the remaining unread portion of the buffer.

The main API shape is:

public ImmutableByteArrayReader ReadInt(out int value);
public int ReadInt();
public int ReadIntWithOffset(int byteIndex);

These three forms cover three common use cases.

The out form is for fluent parsing:

var remaining = data
    .ReadString(4, out string magic)
    .ReadInt(out int width)
    .ReadInt(out int height);

The direct-return form is for reading a value from the start of a buffer when the remaining data is not needed:

int width = data.ReadInt();

The offset form is for random access without consuming anything:

int width = data.ReadIntWithOffset(4);

This gives the type this clear behavior: Sequential reads consume by returning a new remaining buffer. Offset reads do not consume. Because the reader is immutable, slicing can be cheap: reading a subrange can return another reader over the same underlying data instead of copying bytes.

That means this kind of operation is cheap:

var remaining = data.ReadBytes(32, out ImmutableByteArrayReader header);

Both remaining and header can be views over the same internal byte array. Since neither object can mutate the backing storage, this remains safe.

Reading blocks

Binary formats often have fixed-size blocks. For example, a file might contain a 32-byte header, followed by 32 bytes of padding, followed by records.

The API shape for bytes is:

public ImmutableByteArrayReader ReadBytes(int count, out ImmutableByteArrayReader value);
public ImmutableByteArrayReader ReadBytes(int count);
public ImmutableByteArrayReader ReadBytesWithOffset(int byteIndex, int count);
public ImmutableByteArrayReader ReadBytes(int count, out ImmutableByteArrayReader value, Action<ImmutableByteArrayReader> continuation);

The continuation form is useful when a sub-block should be parsed separately:

int versionNumber = 0;

var remaining = ImmutableByteArrayReader.FromFile("MyData.bin")
    .ReadString(4, out string magic)
    .ReadBytes(32, out ImmutableByteArrayReader _, header => header.ReadUInt(out versionNumber))
    .ReadBytes(32, out _)
    .ReadInt(out int count);

The main stream advances by 32 bytes, while the continuation reads from the isolated header block.

This is especially useful for formats where blocks have fixed sizes, but only some fields inside the block are currently relevant.

Strings

Strings usually appear in binary formats in two common forms.

The first is fixed-size:

public ImmutableByteArrayReader ReadString(int size, out string value);
public string ReadString(int size);
public string ReadStringWithOffset(int byteIndex, int size);

For example, a file magic value:

data.ReadString(4, out string magic);

The second is zero-terminated:

public ImmutableByteArrayReader ReadString(out string value);
public string ReadString();
public string ReadStringWithOffset(int byteIndex);

This reads until the first 0x00 byte.

data.ReadString(out string name);

Fixed-size strings are common in headers. Zero-terminated strings are common in older binary formats, mesh files, embedded metadata, and C-style structures.

Writing Binary Data

Binary Buffer Writer: `MutableByteArrayWriter`

MutableByteArrayWriter is the mutable writer.

It is a fluent append-only byte builder:

var current = new MutableByteArrayWriter()
    .WriteStringFixedSize("CBA1")
    .WriteInt(1)
    .WriteDouble(3.14159);

It is mutable in-place. Each call appends bytes to the same underlying buffer and returns this.

This makes it the practical default for producing binary files.

The API deliberately uses explicit method names:

WriteInt(...)
WriteUInt(...)
WriteDouble(...)
WriteStringFixedSize(...)
WriteStringZeroTerminated(...)
WriteBytes(...)

This avoids the ambiguity of a single overloaded Write(...) method. In binary code, explicitness is usually worth the extra characters.

Immutable writer: `ImmutableByteArrayWriter`

ImmutableByteArrayWriter mirrors the writer API, but every write returns a new object.

var baseFile = new ImmutableByteArrayWriter()
    .WriteStringFixedSize("TEST")
    .WriteInt(1);

var pathA = baseFile.WriteStringZeroTerminated("Variant A");
var pathB = baseFile.WriteStringZeroTerminated("Variant B");

This is useful when experimenting with different downstream write paths.

For example, you may have a common header, then several possible payload layouts:

var common = new ImmutableByteArrayWriter()
    .WriteStringFixedSize("MESH")
    .WriteInt(version);

var triangleMesh = common
    .WriteStringZeroTerminated("triangles")
    .WriteInt(triangleCount);

var pointCloud = common
    .WriteStringZeroTerminated("points")
    .WriteInt(pointCount);

The mutable writer is faster and more memory efficient. The immutable writer is better for branching, testing, and functional construction patterns.

Writing fixed-size blocks

Writers also support fixed-size subblocks:

public MutableByteArrayWriter WriteBytes(int count);
public MutableByteArrayWriter WriteBytes(int count, Action<MutableByteArrayWriter> subblock);
public MutableByteArrayWriter WriteBytes(MutableByteArrayWriter source);

For the mutable version:

int versionNumber = 1;
int count = 15;

MutableByteArrayWriter current = new MutableByteArrayWriter()
    .WriteStringFixedSize("CBA1")
    .WriteBytes(32, con => con.WriteUInt((uint)versionNumber))
    .WriteBytes(32)
    .WriteInt(count);

for (int i = 0; i < count; i++)
    current = current.WriteBytes(128);

current.Save("Copy1.bin");
current.Save("Copy2.bin");
current.Dispose();

The block continuation writes into a temporary sub-buffer. If it writes fewer than 32 bytes, the result is automatically padded with zeroes. If it writes more than 32 bytes, the writer should throw.

This makes fixed-size binary structures much easier to express.

The immutable version uses a functional continuation instead:

ImmutableByteArrayWriter current = new ImmutableByteArrayWriter()
    .WriteStringFixedSize("CBA1")
    .WriteBytes(32, con => con.WriteUInt((uint)versionNumber))
    .WriteBytes(32)
    .WriteInt(count);

Internally, that continuation should be shaped as:

Func<ImmutableByteArrayWriter, ImmutableByteArrayWriter>

because immutable writes return new objects.

Examples

Example: reading a PPM image

PPM is a simple image format from the Netpbm family. It is useful as a teaching format because the structure is small and direct. The examples below intentionally implement a minimal binary P6 reader and writer, rather than a complete Netpbm parser.

A binary PPM file starts with an ASCII header:

P6
width height
maxValue

followed by a single whitespace byte and then the binary RGB pixel data.

For example:

P6
256 256
255
<binary RGB bytes>

The header is text, but the pixel payload is binary. This makes PPM a good example of mixed text and binary parsing. In the common 8-bit case where maxValue is 255, the payload is width * height * 3 bytes. PPM also allows comments in the header and larger sample values, but this example deliberately supports only simple comment-free P6 files with maxValue == 255.

A simple PPM image type might look like this:

public sealed class PpmImage
{
    public int Width { get; }
    public int Height { get; }
    public byte[] Pixels { get; }

    public PpmImage(int width, int height, byte[] pixels)
    {
        Width = width;
        Height = height;
        Pixels = pixels;
    }
}

This simplified parser supports only the common 8-bit RGB form. General P6 files can use larger sample values and may contain comments in the header, so a production parser would need to handle those cases before reading the raster payload. Using ImmutableByteArrayReader, a basic parser could be written as:

public static PpmImage ReadPpm(string path)
{
    ImmutableByteArrayReader data = ImmutableByteArrayReader.FromFile(path);

    data = ReadAsciiToken(data, out string magic);

    if (magic != "P6")
        throw new InvalidDataException("Only binary P6 PPM files are supported.");

    data = ReadAsciiToken(data, out string widthText);
    data = ReadAsciiToken(data, out string heightText);
    data = ReadAsciiToken(data, out string maxValueText);

    int width = int.Parse(widthText);
    int height = int.Parse(heightText);
    int maxValue = int.Parse(maxValueText);
    data = ConsumeSingleAsciiWhitespace(data); // Skip delimiter whitespace

    if (maxValue != 255)
        throw new InvalidDataException("Only 8-bit PPM files with max value 255 are supported.");

    int pixelByteCount = width * height * 3;

    data.ReadBytes(pixelByteCount, out ImmutableByteArrayReader pixelData);

    return new PpmImage(width, height, pixelData.ToArray());
}
private static ImmutableByteArrayReader ConsumeSingleAsciiWhitespace(ImmutableByteArrayReader data)
{
    if (data.Length == 0 || !IsAsciiWhitespace(data[0]))
        throw new InvalidDataException("Expected whitespace before PPM raster data.");

    return data.Skip(1);
}

The helper token reader can be implemented as a small routine over the immutable buffer:

private static ImmutableByteArrayReader ReadAsciiToken(ImmutableByteArrayReader data, out string token)
{
    data = SkipAsciiWhitespace(data);

    int count = 0;

    while (count < data.Length && !IsAsciiWhitespace(data[count]))
        count++;

    token = Encoding.ASCII.GetString(data.AsSpan(0, count));
    return data.Skip(count);
}

private static ImmutableByteArrayReader SkipAsciiWhitespace(ImmutableByteArrayReader data)
{
    int count = 0;

    while (count < data.Length && IsAsciiWhitespace(data[count]))
        count++;

    return data.Skip(count);
}

private static bool IsAsciiWhitespace(byte value)
{
    return value == (byte)' ' || value == (byte)'\t' || value == (byte)'\r' || value == (byte)'\n';
}

This parser is intentionally minimal: it demonstrates the cursor-management pattern without implementing every detail of the Netpbm format. It does not support comments, alternate sample sizes, or multiple concatenated images in one file.

The parser is not fighting offsets. Each helper receives a buffer and returns the remaining buffer. That is the central pattern.

Example: writing a PPM image

Writing a binary PPM file is straightforward with MutableByteArrayWriter.

public static void WritePpm(string path, int width, int height, ReadOnlySpan<byte> rgbPixels)
{
    int expectedLength = width * height * 3;

    if (rgbPixels.Length != expectedLength)
        throw new ArgumentException($"Expected {expectedLength} RGB byte(s).", nameof(rgbPixels));

    new MutableByteArrayWriter()
        .WriteStringFixedSize("P6\n")
        .WriteStringFixedSize(width.ToString())
        .WriteByte((byte)' ')
        .WriteStringFixedSize(height.ToString())
        .WriteByte((byte)'\n')
        .WriteStringFixedSize("255\n")
        .WriteBytes(rgbPixels)
        .Save(path)
        .Dispose();
}

This writes:

P6
width height
255

then appends raw RGB bytes.

The string methods are still explicit. We are not pretending the whole file is text. We are building a binary byte sequence with some ASCII sections.

You can open a .ppm image with GIMP.

Contrast this with a traditional stream-based version:

public static void WritePpm(string path, int width, int height, ReadOnlySpan<byte> rgbPixels)
{
    int expectedLength = width * height * 3;

    if (rgbPixels.Length != expectedLength)
        throw new ArgumentException($"Expected {expectedLength} RGB byte(s).", nameof(rgbPixels));

    using FileStream stream = File.Create(path);
    using BinaryWriter writer = new BinaryWriter(stream, Encoding.ASCII, leaveOpen: false);

    writer.Write(Encoding.ASCII.GetBytes("P6\n"));
    writer.Write(Encoding.ASCII.GetBytes(width.ToString()));
    writer.Write((byte)' ');
    writer.Write(Encoding.ASCII.GetBytes(height.ToString()));
    writer.Write((byte)'\n');
    writer.Write(Encoding.ASCII.GetBytes("255\n"));
    writer.Write(rgbPixels);
}

The code is command-oriented, whereas the fluent writer makes the data structure visually continuous.

Example: reading a PLY file

(Due to length limit of the platform, this section is not shown; Refer to https://dev.to/methodox/working-with-binary-data-in-divooka-55im for full article)
(Maximum length is 20000 characters, including new lines and whitespaces.)

Future Improvements

The API can be improved in several directions.

A schema layer could sit on top of these primitives. Instead of manually writing every field, a format could define named fields, block sizes, validations, and version-specific layouts.

The reader could gain richer parsing helpers, such as ReadAsciiToken, ReadAsciiLine, ReadUntil, TryRead, and Peek variants. These would make mixed text/binary formats like PPM and PLY even cleaner.

The writer could support reservation and backpatching. Many binary formats write a length or offset before the final value is known. A controlled API for placeholders would make this safe:

var lengthPosition = current.ReserveInt();

...

current.PatchInt(lengthPosition, payloadLength);

For very large files, both reader and writer could have stream-backed variants. ImmutableByteArrayReader is ideal for in-memory data, but some workflows need lazy reading, memory-mapped files, or chunked output.

The immutable writer could also use a rope-like internal representation instead of copying the whole byte array on every append. That would preserve functional semantics while making branching construction much more efficient.

The core idea, though, should stay the same: binary data should be worked with as a fluent sequence of explicit operations. The API should make the structure of the format visible, while hiding the repetitive mechanics of offset movement, byte ordering, padding, and raw byte appending.

DevLog 20260426: Divooka Mandelbrot Benchmark – Putting Our Scripting Language to the Test

Mon, 27 Apr 2026 03:33:55 +0000

Today we released the first public version of DivookaBenchmark_Mandelbrot — a standardized benchmark suite built specifically to measure the real-world performance of Divooka against a wide range of languages and runtimes.

The benchmark computes the Mandelbrot set at 2000 × 2000 resolution with a maximum of 1000 iterations per pixel, then verifies correctness using a 32-bit checksum (target: 689833081). We run each implementation five times and record average time, min/max, peak memory, and distribution size.

Why This Benchmark Matters

One of our core beliefs is that a modern scripting language needs a "decent (high) performance". This benchmark was designed to prove that point in a reproducible way.

It exercises heavy integer and floating-point math, tight loops, branches, and memory writes — exactly the kind of workload where interpretation overhead shows up quickly. This particular benchmark doesn't test function calls directly.

The goal is not to produce the an optimized Mandelbrot renderer, but to compare a simple, fixed algorithm across different languages and runtimes, then use the result to understand where Divooka currently stands.

We included implementations (or equivalent ports) for:

C++
C# (.NET 10, including AoT/trimmed)
JavaScript (multiple browsers + Node.js)
Go, Java, Julia, Python 3.13, Ruby, Prolog, GNU Octave
And of course, multiple execution modes of Divooka 0.75.2 (compiled, Aviator, Neo Editor, Stewer)

We even tested AI-generated versions from ChatGPT, Gemini, Grok, and Kimi to see how reliable and performant LLM-produced result is in practice.

Key Results (on Windows 11, i7-13700KF)

Fastest overall: JavaScript in Edge/Chrome/Brave (~1,296 ms, very low memory)
Fastest native: C++ (~1,308 ms)
Strong managed contender: C# AoT (~1,355 ms)
Divooka compiled: 3,639 ms — comfortably beating pure interpreters like Python (~47 s) and Ruby (~49 s) ⚡
Divooka Aviator: 6,711 ms
Divooka Neo Editor: significantly higher overhead (estimated multi-hour range for full runs)

The gap between Divooka's compiled mode and the top-tier JITs (especially V8) is still noticeable, but the improvement over classic interpreted scripting languages is clear. This reinforces why we’ve been investing heavily in our compilation pipeline and runtime optimizations.

AI-generated implementations varied wildly — some produced correct checksums but took 26 seconds to several minutes, while others failed entirely or fell back to calling Python under the hood. Deterministic engineering still wins.

What We Learned

JIT is not optional for competitive scripting performance.
Tooling and editor overhead can dominate if not carefully managed (something we're actively addressing).
Even simple, well-defined tasks like Mandelbrot reveal meaningful differences in language/runtime design.

The full repository is now public:
https://github.com/MethodoxTech/DivookaBenchmark_Mandelbrot

It includes all source implementations, PowerShell automation scripts, result tables, and artifacts. Feel free to clone, run it yourself, or contribute additional language ports.

This benchmark will become part of our regular performance regression suite as Divooka evolves. Future runs should show steady gains as we refine the compiler and reduce runtime overhead.

Current Results

Results from best runs of respective platform:

Rank	Language / Runtime	Size	Best Time
1	JavaScript Web, Edge / Chrome / Brave	3 KB	1295.80–1302.80 ms
2	C++	15 KB	1308.00 ms
3	C# AoT	911 KB	1355.35 ms
4	C# .NET 10	16.5 MB	1357.47 ms
5	JavaScript Node.js	2 KB + 98.2 MB	1406.20 ms
6	Go	2 KB + 224 MB	1425.01 ms
7	Julia	2 KB + 1 GB	1511.20 ms
8	JavaScript Web, Firefox	3 KB	1513.00 ms
9	Java OpenJDK 17.0.11	301 MB + small files	1587.79 ms
10	Divooka 0.75.2, Compiled	71.914 MB	3639.24 ms
11	Divooka 0.75.2, Aviator Run	8 KB + 2.16 GB + 776 MB	6710.84 ms
12	Python 3.13.5	2 KB + 139 MB	47127.70 ms
13	Ruby 3.2.2	1 KB + 907 MB	49489.82 ms
14	Prolog SWI, optimized	2 KB + 42.8 MB	314687.84 ms
15	GNU Octave 7.3.0	2 KB + 2.07 GB	2464913.29 ms
16	Divooka 0.75.2, Neo Editor estimate	8 KB + 2.67 GB	~95.8 hr

Limitations

This benchmark only tests a narrow case.

It does not test UI programming, data manipulation, graph execution, external libraries, async workloads, recursion-heavy workloads, or large real-world applications.

It also does not fully normalize warm-up behavior. Browser JavaScript likely benefits from highly optimized JIT behavior, and other runtimes may have different startup / warm-up costs.

GNU Octave is probably optimized for matrix-oriented workloads, not naive scalar loops.

Python is rarely used this way in performance-sensitive numerical code; normally people use NumPy, Numba, Cython, PyPy, or native extensions.

2026 Divooka™ Explore Steam Release Trailer

Fri, 24 Apr 2026 02:34:45 +0000

Divooka is a high-performance visual programming platform designed for creators, developers, and world builders. Build applications, generate worlds, process data, and experiment with computation using a powerful node-based system combined with flexible code-driven workflows.

DevLog 20260319: Towards OOP - Document-Level Default Module and Module-Level Members and Behaviors

Thu, 19 Mar 2026 20:31:07 +0000

Revisiting Flappy Bird – The Pain Point

Remember our Flappy Bird example from mid-2025?

The long chain of variable initializations was needed for two main reasons:

No way to declare variables before using them
More critically - no way to define custom data structures that could group related values together and be instantiated with a single node.

In retrospective it seems obvious: we just need proper structured data containers. But building the scaffolding to support this properly in a visual, node-based system is a bit more involved.

Searching for a Solution

I spent a long time trying to bring OOP concepts into Divooka. A huge amount of effort went into DiOS (Divooka Open Standards), with the hope that a complete standard would naturally solve these kinds of problems. But standardization work is slow and deep - just like making Divooka itself feature-complete.

Then, while working on something completely unrelated and taking a short break from this topic, it suddenly clicked.

The key insight: start simple and approach it from a functional/declarative angle first, before jumping into inheritance, encapsulation, polymorphism, and all those good stuff.

I'm really excited - we finally have meaningful progress.

The Divooka Way

To claim our goal as "everything is a node" is a bit too strong, but I strongly prefer keeping almost everything on the graph.

This aligns with how we already handle structured primitives - direct value setting of compound inputs. That way, there's still hope that users can drop down to raw node programming when they need full control (and thus keep everything programmable).

Traditional property panels (like Unreal Blueprints' object definition GUIs) are out - they break the pure graph paradigm.

Instead, the solution is declarative, similar to how TerraGen works: the mere presence and connection of certain nodes defines meaning.

This feels awesome for several reasons:

We can make full use of the 2D graph layout - place things exactly where we want them visually
It stays completely coherent with Divooka's graphical paradigm
No need for separate "class editor" UIs

What's Been Implemented So Far

Current working pieces:

Graphs can now act as modules
Support for module-level data members and behavior members
A main module tied to the document, with existing graphs serving as associated behaviors

Module-scoped instance node – in Events context

Module-scoped instance node – in Dataflow context

Top-level module behavior graphs

This immediately unlocks:

Clean access to (top-level) module instances
Shared event and dataflow instance data
A unified programming and document model for subgraphs (still a work-in-progress)
In procedural contexts (Glaze! especially): we now have proper data containers - no more awkward giant variable lists or forced tuples! (Compare to the old Flappy Bird screenshot)
Much simpler and more natural state storage/access in Glaze! and procedural graphs

This is a big deal - for a system that's gearing up for real production use, it feels like crossing a major milestone in usefulness and core abstractions.

Current Limitations & Remaining Work

Still plenty to fix/polish:

A bunch of bugs and edge cases
Proper serialization support
Smooth context switching between graphs
Subgraph consolidation / better nesting UX

Looking Ahead

This is a solid foundation, but there's still a long road:

Full modularization support
Modules inside modules (nesting)
Module inheritance / composition patterns / polymorphism
Base DOM exposed as the "main module" for metaprogramming API
Detailed documentation: how it all fits together, recommended usage patterns, expected behaviors, pitfalls
Module-level scoped instances (deeper/finer control)

Overall - I am very happy with the direction. It feels like Divooka is finally getting the abstraction power it deserves while staying true to its visual, graph-first philosophy.

I am hyped for what we will achieve.

References

DevLog 20260225: Divooka Visual Programming - Direct Value Setting of Compound Inputs

Wed, 25 Feb 2026 17:55:52 +0000

Finally, it arrived! Well, not exactly here yet, but getting closer.

Overview

Divooka intends to make visual programming simple and accessible - the accessible part is achieved both through wide availability and the general-purpose nature of the programming system, but the simple part is what we spend lots of effort thinking hard trying to improve.

In the past, dealing with complex configuration takes the form of either "explosion" of arguments or dedicated Make XXX construction functions:

The problem arises due to direct exposure of all input arguments in visual programming. Both approach makes the canvas look busy, with the former a common approach in existing systems - using a struct sounds good on paper but still requires a complex looking construction node. This is a common problem in visual programming systems, below shows how it's done in Blender and ComfyUI.

You do get used to it after a while, but a busy looking canvas remains a busy-looking canvas. In Blender, you can sort of "collapse" a node:

As Blender is constantly improving, we can also now collapse property groups as shown in the earlier screenshot.

As a syntax purist and (unfortunately) very conscious about my working space, my eyes can't tolerate messiness. I kind of like how Houdini approaches this.

Essentially they offload all the complexity to the properties panel - this has the huge benefit of making everything look very clean. But the downside is Houdini rely heavily on scripting expressions (like Excel).

TerraGen and World Machine mixes the approach:

In both cases, connections represent flow of terrain data only and additional configurations are offloaded to property panels. In TerraGen especially, this allows those properties to be animated. The downside, once again, is whatever is offloaded to property panels are no longer programmable using nodes.

Our Approach

Our proposed solution for Divooka looks like this: fundamentally all properties remain as node inputs, but compound values (especially value types) should just allow "editing in place" through a property panel. If more complex programming is needed, one can easily fall back to Make XXX nodes again.

Future Work

There is still remaining work on type check, hierarchical compound types, arrays, and serialization, and also node rendering.

Conclusion

As usual with all the exciting language features of Divooka we intend to introduce, there are lots of details to take care of here.

DevLog 20260224 Divooka - Node-Level Automatic Dispatch (Runtime Execution Behavior)

Tue, 24 Feb 2026 22:22:17 +0000

Overview

Anything useful done with a program eventually involves file I/O and some form of repetition.

In Divooka, the dataflow context already makes it very easy to "just get a single thing done." That part feels good. But handling loops? That's where things start to get awkward.

One challenge lies on the GUI side — especially around lambdas and subgraphs. We do have foundational support (as shown here and here), but let's be honest: it's not smooth yet.

So the question becomes: how do we make repetition feel natural without introducing heavy conceptual overhead?

The Plan

There are several well-established ways to achieve looping behavior in a functional or visual programming context:

Subgraph context - Used in tools like Blender, vvvv, and Houdini. A specialized node group or frame defines loop entry and exit boundaries.
Lambda callbacks - Evaluation is handled via callback-style execution.
Expressive recursion - As seen in text-based functional languages, requiring explicit termination conditions to avoid stack overflow.

All of these approaches are powerful and necessary in certain contexts. But they also introduce additional constructs into the language model. For advanced workflows, that's fine. For simple operations, it can feel unnecessarily complex.

I wanted something lighter.

Array Coercion

Divooka already supports Array Coercion — a scalar value can be passed into an input expecting a collection.

This avoids the need to manually "wrap" a scalar into an array just to satisfy a function signature - I still remember the pain of handling arrays in Unreal Blueprint.

Scalar-to-array coercion keeps graphs clean and avoids clustering.

To take this to the next level, I've been giving it much thought on how the reverse might work: if we can coerce scalars into arrays — what if we also let nodes automatically dispatch when arrays are passed in?

Automatic Dispatch (Node-Level)

The core design question was:

Should an array input implicitly turn the entire downstream chain into a loop?
Or should the dispatch behavior stay localized to the node itself?

Eventually it seemed localizing things to the node made far more sense.

For example:

string String.Replace(string, string, string)

If any input is provided as an array instead of a scalar, the node automatically promotes itself to:

string[] String.Replace(string[], string[], string[])

The node executes element-wise.

Now, I can rename a folder of files with roughly three nodes:

Enumerate files
Regex replace
Rename file

No explicit loop node. No subgraph. No lambdas.

In this example, Duplicate as Array returns a strongly typed string[], enabled by generics support.

One important rule: All array inputs must align in size with the source array. The dispatch is index-based and deterministic.

Full Example

What used to require explicit iteration logic now becomes implicit behavior at the node boundary. The graph remains readable. The mental model stays simple.

Conclusion

This is still early work. Integration with the rest of Divooka's features is ongoing, and edge cases are being worked through.

So far so good.

Weekly Update 2026-01-11

Mon, 12 Jan 2026 01:29:36 +0000

This week was mostly about tightening up the foundations of our tools rather than pushing new features. A lot of our older experiments were starting to show their age, so we spent time cleaning things up and getting the core systems into better shape.

What Happened This Week

Refactoring Neo + Parcel NExT review

We continued working through refactors on Neo and reviewing the Parcel NExT implementation. Some of the earlier experimental frontend work had spread across multiple assemblies, so small API changes ripple everywhere. Slow, but necessary.

WPF + Nodify wrestling

A surprising amount of time went into understanding how WPF resource dictionaries, theming, and Nodify's API actually want to behave together. After digging through the quirks, we finally have a clearer picture of how to keep styling and view models consistent. Didn't get as far into custom styling as we hoped, but at least the fundamentals are sorted out.

Serialization groundwork

Started wiring up the basics for text-based JSON serialization of Divooka graphs/documents. Also began work on package reference records and figuring out how packages get identified and loaded at runtime. All early steps, but important ones.

Graph editor + GUI cleanup

Made some initial passes at reorganizing the graph editor. Small changes now, but they'll help us build better tools on top later.

Fantasy Planet Painter update

Spent a little time polishing and updating the Steam submission for Fantasy Planet Painter.

Methodox Threads

We also pushed out an early public release of Methodox Threads, our lightweight branching text environment for managing non-linear AI conversations. The new v0.7 build adds integrated Gen-AI generation directly inside each document pane, configurable providers, and a simple JSON-backed structure for exporting or versioning thought trees. It's essentially a cleaner way to explore tangents, run parallel prompts, and keep complex LLM work organized. Download is available on itch.io.

Closing Thoughts

Not a "big features" week, but a surprisingly productive one in terms of future stability. Refactors aren't glamorous, but they make everything that comes next a lot smoother.

DevLog 20250507 Bringing Smart Suggestions and Smarter Search to Divooka’s Visual Coding

Sun, 07 Sep 2025 23:39:02 +0000

Learning from Unreal Engine Blueprints

I’ve always admired Unreal Engine’s Blueprints - particularly its subtle yet powerful connection suggestion feature. When you drag a wire out from a pin, the system intuitively suggests compatible nodes based on the pin’s data type.

This kind of context-awareness accelerates creation and keeps workflow fluid by making things just work - no guesswork needed.

The Challenge: Missing Type Labels in C# Instance Methods

Divooka, built atop C#, posed a snag: instance methods don’t include the object’s type in their signature. So if a method like Rotate() belongs to a Transform object, the type isn’t explicitly declared in the method signature - making automatic suggestion tricky.

To match Unreal’s intuitiveness, I needed a way to tell Divooka - not just "Rotate()", but Rotate() on Transform.

Explicit Type Filter in Search Syntax

The first step is to allow users to filter the toolbox explicitly in their search query.

For example: [Pixel Image] Save would filter for methods in the Pixel Image toolbox (category). The symmetry of this syntax remains intuitive even in localized languages like Chinese - because only the type would be translated, not the syntax design itself.

Building the Pipeline: Filtering and Highlighting

Next, I leveled up the search experience by crafting a multi-stage pipeline:

Category names (like [AI Service], [Pixel Image]) now at the front, so users can scope their search by purpose.
Then we optionally parse <TypeName> syntax, which is used to filter input parameters.
Finally, full-text search for other keywords.

So a query might look like:

[Pixel Image] <String> Save

In which case we will search only for functions containing the word "Save" and expects a String parameter. Visually, I emphasized that first category tag with syntax highlighting to help the eye quickly scan.

The Result: It Just Works (Mostly)

Here’s how it currently looks:

Type [Pixel Image] Save.
The search autocomplete suggests all instance methods named Save...() defined in Pixel Image toolbox (mostly operating on the PixelImage object type) (e.g., PixelImage.Save, PixelImage.Load, etc.).
Everything lights up in palette instantly - users can find what they need fast.

What’s Missing: Auto-Connecting Suggestions

This solves the searching half of the problem beautifully - but it doesn’t yet auto-connect. In Unreal, dragging from a Vector pin might instantly suggest Normalize() - and connect it for you if you click that suggestion.

Right now, Divooka still requires a manual drag-and-click - our intention was only searching and filtering, not full drag-and-drop automation.

Next Steps: Toward Full Contextual Suggestions

I’m plotting the future:

Pin-aware suggestion: When dragging a wire from a pin, immediately filter down to matching methods—and optionally even pre-wire the node when hitting “Enter” or double-clicking.
Type inference: Avoid requiring <Type> if the context is obvious - since the system already knows the pin’s type.
Better localization: Make sure category tags and type filters localize cleanly, without mangling grammar in languages like Chinese, Japanese, etc.
Enhanced UX hints: Perhaps grey-out non-matching nodes live, or provide quick tooltips (e.g. “only shows methods on Transform”, like Unreal Blueprint's node search interface).

Summary

Previously, instance-based methods don’t expose their object type; this hampers auto-suggestion. We solved this by introducing explicit <Type> filters and category tags in our search syntax. The result is now the users can quickly locate relevant methods with filtered search - instant clarity. Up next, we want to add full context-aware, auto-connecting suggestion - move from “search” to “smart connection.”

Conclusion

Unreal Blueprints’ delightful node suggestions inspired us to refine Divooka’s search. By introducing syntax like [Category] <Type> Keywords..., Divooka now lets you filter instance-based methods explicitly - greatly improving discoverability. Coming up: auto-connection and smarter, context-aware wiring.

Let me know if you are interesting in learning more specific implementation details - like the regex matching, indexing logic, or localization strategy!

Happy visual coding!

[Article] Divooka, Where We Are

Sat, 16 Aug 2025 19:42:13 +0000

Many years from now, when power users, researchers, and historians look at this article, they will see how it all started and glimpse the vision behind our work.

Overview

Ah, vision - a fascinating subject, and a quality not appreciated by all. Like the ability to dream, to imagine, and to dwell in the realm of mathematics and technicality. For imaginative minds, it's dangerous to wander too far; without standing on solid ground, one can hardly make real progress. Often, it pays to be hands-on.

Divooka is (or is becoming) a complete, general-purpose, high-level, multi-paradigm, flexibly typed, modern visual programming language/system, complete with package management, standard libraries, application frameworks, graph editors, IDE, CLI executor, code generator & compiler, derived frontend apps, examples, documentation, and accompanying tutorials and training materials. We've achieved the majority of this already, so it's not an exaggeration to list them now. What's more, there are still ideas I haven't put into words.

It's hard to do one thing well, and to achieve all of this with limited resources, we need a good strategy. Of course, the strategy itself is a secret I won't share - it's fairly simple, really, but requires determination and execution power. After a year since incorporation last July, it's useful to review and recap what we've done and where we are.

In this article, I'll focus on the period from January to August 2025, but to give a complete picture, I find it instructive to look back and highlight outcomes from last year and key lessons learned.

Early 2024

2024 was about the modernized inception of what Divooka is today.

Neo was reviewed a third time, and we managed to trim down most legacy code. It was time to think more broadly about the concept of "general-purpose visual programming," rather than just a demonstration for data analytics. A new repository was created for modern development. Gospel was conceived.

Talks with investors and prospective entrepreneurs mostly confirmed that this subject is hard, and we learned there are countless low-code platforms in China. That is good.

A disagreement with a co-creator helped me settle the fact that we would definitely go desktop-first and worry about the web later.

The conception of Quadrinity and the flexible office software framework inspired me to quit my job and move forward.

July–Sep 2024

During initial incorporation, development was highly focused, and Divooka, though very simplistic, was a well-defined, easy-to-perceive single tool with only a handful of nodes. With Haopu's help on plotting, it quickly looked like a handy little utility for data analytics - a subject matter we should continue to explore and focus on in the future.

At the same time, to prepare for public preview and an angel investor meeting, I spent a month making prototypes for many potential application areas, including experimental libraries and web use. Due to lack of sophisticated integration and completeness, I doubt these prototypes made as strong an impression as I hoped.

On the marketing side, the concept of a case competition was pitched during this time, but it never materialized later in 2024 due to slow progress on software completion and the dashboard library.

Sep–Dec 2024

With the promise of investor funding, I decided to expand operations and start hiring contractors to work on various aspects of the overall Divooka platform, including GUI design, website improvements, and preparation for first practical use. In a previous article, I mentioned that end users were unlikely to use Divooka directly during initial adoption. To elaborate:

Lack of comprehensive DSL libraries at this stage.
Overall complexity and learning curve as a general-purpose programming language.

While we could have focused on DSL, the second point made it unlikely to gain traction (given how unknown we were) and not commercially feasible any time soon. Thus, we needed more specific, tool-like, highly focused, direct end-user GUI applications.

For that reason, we published Fantasy Planet Painter. We also planned to publish Arcadia, but timeline issues prevented it.

It was during this period that we conceived what was previously known as "ZFA," while "fighting" for the trademark of "Zora" in Canada. Due to delays with investment funding, personnel management, and other corporate matters, we didn't make significant progress on the modern Morpheus framework or ZFA at that time.

In conclusion, during these busy four months, there was not much I would call technical progress. Most efforts were miscellaneous but time-consuming. I also learned it was better to take more matters into my own hands.

Jan–Aug 2025

January to August has been much more fruitful and productive, despite major distractions in January, May, and July. With help from Aaron, Allan, and ChatGPT - and without the communication burden of contractors and external collaborators - progress has been slow but steady. More importantly, I've had time to investigate highly technical matters and build foundational work.

The Web Summit in May and internal training from April to July helped us greatly polish the Neo graph editor, stabilize Neo's internal serialization format, and establish Divooka for general-purpose use.

Ecosystem-wise, I've done plenty of investigation and prototype work on Python integration, build automation, code refactoring, and preliminary work on online services.

There has been extensive work on Neo and Neo-first features, including general GUI improvements, bug fixes, plugin framework enhancements, subgraph work, generics, lambda support, multilingual framework setup, procedural context, and other experimental work. Related to this is the improved Neo serialization format, which is becoming more robust and stable. We haven't yet worked on package management. Although we are trying to make it DiDS-conformant, it's still far from achieving a single final format.

DSL-wise, there has been initial work on Ol'ista, Glaze!, Slide Present, and Novella. Many utilities were also created for ChatGPT and GenAI services, including interfaces for Nvidia NIM, ComfyUI, and Hugging Face inference services. Different users have different demands, and it's hard to focus on any specific library without a pilot project. While we do have internal pilot projects, they are large in scope and still require groundwork, so Divooka hasn't yet played a significant role. I do want to seek external collaboration on this - but at the moment resources are constrained.

On the plotting front, as of early August, Aaron has made significant progress on the mid-level plotting API, making Divooka's plotting library almost "self-sustainable," able to meet a wide range of demands.

Although data analytics is arguably not our only focus, use case investigations have improved in-memory DB handling, refactoring, and preliminary libraries for PostgreSQL ingestion. One architectural challenge is expression interpretation: we decided long ago that, at least for data analytics, it's not efficient to rely entirely on node interfaces - some coding is desirable. The main focus is SQL snippets through our in-memory DB library, though at times LINQ expressions and in-place C# scripting have been useful. However, concerns with the latter are robustness, error tolerance, predictability, increased distribution size, and future program export compatibility.

The data analytics API also faces the challenge of whether to focus on OOP or tabular data as intermediate formats. Sometimes one is more convenient than the other, which increases development costs to maintain both. Eventually, we will likely keep both but prefer exposing the tabular format in Divooka.

A more complete picture of "data analytics" in Divooka would extend into data science and machine learning. There's plenty of research to do here, including choosing a foundational library, gradually building our own infrastructure, and developing graph-friendly, visual-programming-first APIs. This will have to wait until next year.

Summary

The most visible outcome is that Neo is receiving significant updates. On the programming language front, Divooka's function libraries are growing as the language becomes more capable, flexible, and production-ready. Once we start working on package management, it will be more prepared for practical day-to-day use. However, package management requires a fully functional online service first.

Meanwhile, we are actively exploring more "direct-user-facing" applications, which I'll discuss in future posts.

We could use a lot of help on DSL work, and that's the plan as the foundations solidify and architectural decisions become clearer.

References

Wiki Entries on related subjects:

DevLogs on Divooka/Neo progress:

The Introductory to Visual Programming with Divooka Textbook:

Access it online here!

Additional references:

Glossary

DSL: Domain-specific Library
DiDS: Divooka Document Specification
DiOS: Divooka Open Standards
Gospel: The new, revived, modern incarnation of Parcel, gateway into Divooka; Now a new graph editor frontend for Divooka
Neo: The Windows graph editor for Divooka
Morpheus: The cross-platform GUI framework and graph editor architecture for Divooka
Quadrinity: A way to perceive office suite software as a single framework consisting of multiple views, like Blender's workspaces
ZFA: Zora Frontier Architecture

DevLog 20250816: Divooka Language Specification (Preliminary Look)

Sat, 16 Aug 2025 19:41:04 +0000

Overview

Divooka is a cutting-edge visual programming platform developed by Methodox Technologies, Inc. It enables users to build and deploy complex applications through a drag-and-drop, node-based interface that integrates seamlessly with C# and Python libraries.

Key Features

General-Purpose & Flexible: Suitable for a wide range of use cases - from business tools to innovative software products - supporting both automation and application development.
Node-Based Visual Interface: Workflows are constructed visually by connecting nodes that represent data operations, logic, APIs, and more.
Multiple Editions:
- Divooka Explore: A beginner-friendly, Windows-only edition designed for learning, data analytics, dashboards, programming, and everyday utilities.
- Divooka Compute: A professional package built on the same engine, aimed at power users. Currently available as a Windows preview build, with Linux and macOS support planned for the full release.
Cross-Platform Vision: While early versions support Windows, full Linux and macOS support is planned.
Strong Architectural Foundations: Based on Data-Driven Design principles, Divooka emphasizes modular, external control of behavior through data files - streamlining workflows without modifying code.
Developer-Centric Philosophy: Divooka is not a new programming language per se. Instead, it focuses on decoupling functionality from specific environments to maximize flexibility and usability.
Active Development & Community: Ongoing updates, documentation (wiki), tutorials, a Discord community, and blog posts ensure an active ecosystem.

Divooka is built around node graphs as executable documents. Instead of writing sequential code, developers construct graphs of nodes, where each node represents a unit of computation or data. This graph-based approach supports both dataflow-oriented and procedural-oriented paradigms. A Divooka script file (a "Divooka Document") acts as a container for node graphs.

At its simplest:

A Divooka document contains multiple graphs.
Each graph contains multiple nodes.
Nodes have a type, an optional ID, and attributes.
Node attributes can connect to other nodes’ attributes.

In a Dataflow Context, node connections are acyclic; in a Procedural Context, connections may be cyclic and more flexible.

Interpretation

To illustrate the simplicity of the language, we can write a minimal interpreter in Python.

This interpreter handles an acyclic graph of nodes with Type, ID, attributes (all strings), and connections between attributes. Connections are represented directly as attribute values: if an attribute value starts with @, it refers to another node’s attribute (e.g., @Node1.Value).

For example:

DefineNumber outputs a number in its Value attribute.
AddNumbers takes two numbers as inputs and produces a Result.
Print consumes the Result and prints it.

The interpreter maps node types to operators, executes them, and produces results.

# minimal_graph_interpreter.py
# A tiny, in-memory, non-cyclic node graph + interpreter.
# Nodes have: Type, ID, attrs (all strings). Connections are '@NodeID.Attr'.

from typing import Dict, Any, List, Callable, Optional, Tuple

Node = Dict[str, Any]  # {"ID": str, "Type": str, "attrs": {str:str}, "state": {str:Any}}

def is_ref(value: Any) -> bool:
    return isinstance(value, str) and value.startswith("@") and "." in value[1:]

def parse_ref(ref: str) -> Tuple[str, str]:
    # "@NodeID.Attr" -> ("NodeID", "Attr")
    target = ref[1:]
    node_id, attr = target.split(".", 1)
    return node_id, attr

def to_number(s: Any) -> Optional[float]:
    if isinstance(s, (int, float)):
        return float(s)
    if not isinstance(s, str):
        return None
    try:
        return float(int(s))
    except ValueError:
        try:
            return float(s)
        except ValueError:
            return None

class Interpreter:
    def __init__(self, nodes: List[Node]):
        # normalize nodes and build index
        self.nodes: List[Node] = []
        self.by_id: Dict[str, Node] = {}
        for n in nodes:
            node = {"ID": n["ID"], "Type": n["Type"], "attrs": dict(n.get("attrs", {})), "state": {}}
            self.nodes.append(node)
            self.by_id[node["ID"]] = node

        # map Type -> evaluator
        self.ops: Dict[str, Callable[[Node], bool]] = {
            "DefineNumber": self.op_define_number,
            "AddNumbers": self.op_add_numbers,
            "Print": self.op_print,
        }

    # ---- helpers ----
    def get_attr_value(self, node_id: str, attr: str) -> Any:
        """Return the most 'evaluated' value for an attribute (state overrides attrs)."""
        node = self.by_id.get(node_id)
        if not node:
            return None
        if attr in node["state"]:
            return node["state"][attr]
        return node["attrs"].get(attr)

    def resolve(self, raw: Any) -> Any:
        """Dereference '@Node.Attr' chains once (graph is acyclic so one hop is enough)."""
        if is_ref(raw):
            nid, a = parse_ref(raw)
            return self.get_attr_value(nid, a)
        return raw

    def all_resolved(self, values: List[Any]) -> bool:
        return all(not is_ref(v) and v is not None for v in values)

    # ---- operators ----
    def op_define_number(self, node: Node) -> bool:
        # Input: attrs["Value"] (string number). Output: state["Value"] (numeric)
        if "Value" in node["state"]:
            return False  # already done
        raw = node["attrs"].get("Value")
        val = self.resolve(raw)
        num = to_number(val)
        if num is None:
            return False  # can't parse yet
        node["state"]["Value"] = num
        return True

    def op_add_numbers(self, node: Node) -> bool:
        # Inputs: attrs["Value1"], attrs["Value2"] (can be @ refs). Output: state["Result"]
        if "Result" in node["state"]:
            return False
        v1 = to_number(self.resolve(node["attrs"].get("Value1")))
        v2 = to_number(self.resolve(node["attrs"].get("Value2")))
        if v1 is None or v2 is None:
            return False
        node["state"]["Result"] = v1 + v2
        return True

    def op_print(self, node: Node) -> bool:
        # Input: attrs["Result"] (@ ref). Side effect: print once. Also store state["Printed"]=True
        if node["state"].get("Printed"):
            return False
        r = self.resolve(node["attrs"].get("Result"))
        # Allow printing numbers or strings once the reference resolves
        if r is None or is_ref(r):
            return False
        print(r)
        node["state"]["Printed"] = True
        return True

    # ---- execution ----
    def step(self) -> bool:
        """Try to make progress by evaluating any node whose inputs are ready."""
        progressed = False
        for node in self.nodes:
            op = self.ops.get(node["Type"])
            if not op:
                # Unknown node type: ignore
                continue
            progressed = op(node) or progressed
        return progressed

    def run(self, max_iters: int = 100):
        """Iteratively evaluate until no changes (DAG assumed, so this stabilizes quickly)."""
        for _ in range(max_iters):
            if not self.step():
                return
        raise RuntimeError("Exceeded max iterations (graph might be cyclic or ill-formed).")


if __name__ == "__main__":
    # --- Example in-memory graph ---
    graph = [
        {"ID": "Node1", "Type": "DefineNumber", "attrs": {"Value": "3"}},
        {"ID": "Node2", "Type": "DefineNumber", "attrs": {"Value": "5"}},
        {
            "ID": "Adder",
            "Type": "AddNumbers",
            "attrs": {"Value1": "@Node1.Value", "Value2": "@Node2.Value"},
        },
        {"ID": "Printer", "Type": "Print", "attrs": {"Result": "@Adder.Result"}},
    ]

    interp = Interpreter(graph)
    interp.run()   # Should print: 8.0

Running the example graph prints:

8.0

Summary

The Divooka language demonstrates how a minimalist graph-based specification can serve as a foundation for both computation and orchestration.

Key takeaways:

Node-Centric Abstraction: Everything is reduced to nodes with types, IDs, and attributes - uniform, extensible, and easy to interpret.
Simple Reference Mechanism: The @NodeID.Attr convention provides a straightforward but powerful way to connect attributes.
Separation of Concerns: Distinguishing between dataflow (acyclic, deterministic) and procedural (control flow, cyclic) contexts allows Divooka to cover both declarative and imperative styles.
Composable Operators: Even with just three operators (DefineNumber, AddNumbers, Print), meaningful behaviors emerge.
Compact Interpreter Footprint: The entire interpreter is under 200 lines of Python, demonstrating the specification’s simplicity and rapid prototyping potential.

One might ask why not use traditional graph connections. The answer is simplicity: defining connections as local attribute references reduces structure while keeping graphs clean. In dataflow, inputs typically come from a single source, while in procedural contexts, outputs are unique but inputs may be shared, so we can just reverse the syntax - making this lightweight approach intuitive and efficient.

Reference

Wiki (WIP): Divooka Language Specification

State of Divooka | 2025 Vancouver Web Summit | Video Demo | Time-lapse

Thu, 07 Aug 2025 17:26:32 +0000

Divooka is a powerful general-purpose visual programming system that brings a new level of flexibility to general-purpose software development. Its intuitive node-based interface allows you to design, automate, and deploy complex applications with ease, connecting C# and Python libraries seamlessly. Whether you're building robust business solutions or innovative software products, Divooka offers a cross-platform environment that accelerates development and enhances collaboration. Discover a new way to code—visually, intuitively, and efficiently.

In this video demo, we walk through some of the features available as of early 2025.

Topics:

00:00 Library Survey
00:01 Audio Operations
00:08 Make Presentation
00:32 Build Interactive Media
00:51 Integrate Generative AI
01:04 Number Operations
01:11 String Operations
01:28 ComfyUI API
01:38 Image Processing
01:55 Generate QR Code

02:05 Use Case
02:06 Data Analytics
02:25 Generate Entire Book with LLM

Website: Methodox
Store: Methodox Itch.io
Release announcement: Itch.io
Official wiki: wiki

Also see article: Divooka, Where We Are

DevLog 20250805: Divooka Node Graph File Formats

Wed, 06 Aug 2025 00:57:32 +0000

Preamble

When I first envisioned Divooka, I aimed for open source, open file formats, and strong version control friendliness (especially with Git). JSON is verbose and ugly, YAML is perfect but too complex, and formats like CSV/RTS/OBJ are simple and elegant but lack the flexibility needed for complex structures. A custom line-based format seemed like a good middle ground and necessary starting point.

This led to the intention of creating a simple, human-friendly, and easy-to-parse file format - something like TOML. This approach has proven effective in the past; I've parsed similar formats before, and it works well for INI, config, and even Godot scene files.

Canonical TOML Example

# This is a TOML document

title = "TOML Example"

[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00

[database]
enabled = true
ports = [ 8000, 8001, 8002 ]
data = [ ["delta", "phi"], [3.14] ]
temp_targets = { cpu = 79.5, case = 72.0 }

[servers]

[servers.alpha]
ip = "10.0.0.1"
role = "frontend"

[servers.beta]
ip = "10.0.0.2"
role = "backend"

The only issue I have with TOML is largely aesthetic: it's just not beautiful enough. Objects are too scattered, and it can feel a bit verbose - especially when incorporating type information, as seen in a Godot scene file:

[gd_scene load_steps=2 format=3 uid="uid://dbmf10vsl4g6q"]

[ext_resource type="Script" uid="uid://dcyr50rclg8m1" path="res://scenes/login.gd" id="1_l7r8x"]

[node name="Login" type="Control"]
layout_mode = 3
anchors_preset = 15
anchor_right = 1.0
anchor_bottom = 1.0
grow_horizontal = 2
grow_vertical = 2
script = ExtResource("1_l7r8x")

[node name="VBoxContainer" type="VBoxContainer" parent="."]
layout_mode = 1
anchors_preset = 8
anchor_left = 0.5
anchor_top = 0.5
anchor_right = 0.5
anchor_bottom = 0.5
offset_left = -80.0
offset_top = -80.5
offset_right = 80.0
offset_bottom = 80.5
grow_horizontal = 2
grow_vertical = 2

[node name="Label" type="Label" parent="VBoxContainer"]
layout_mode = 2
theme_override_font_sizes/font_size = 46
text = "Login"
horizontal_alignment = 1

The Two Approaches

Divooka Open Standard (Plain Text/Binary Hybrid)

We’ll eventually discuss the broader Divooka Open Standard, but for now, let’s focus specifically on file formats. My original vision was for something like Blender’s .blend format - except in plain text: a sequence of self-contained data blocks that allow easy extension and are powerful enough to store arbitrary payloads.

I imagined blocks for: document properties, nodes, graphs (including connections), payloads, revisions, etc. Some attributes - such as node positions and sizes - are considered auxiliary and handled through "decorators" rather than being part of the core schema. Perhaps I went too far here: the flexibility results in many small structures holding trivial bits of data. On the bright side, once implemented, this approach yields a format that is both human-readable and programmatically digestible. Interpreters uninterested in positional data, for instance, can simply ignore those decorators.

One of the early design decisions was to keep all attributes as strings. The idea was to rely on parsing for interpretation and avoid enforcing types directly. Much like the web, this promotes forward compatibility and long-term document stability. I still stand by this: nothing is easier to parse than plain text.

That said, I made a mistake in implementing everything strictly in this format: the string-based format only makes sense during (de)serialization. Once in memory, the data should be converted into strongly typed structures before any meaningful work is done. Otherwise, everything becomes cluttered with unnecessary boilerplate.

PV1 Neo Document Format (Binary)

PV1 Neo takes a more opinionated, object-oriented approach. Documents contain graphs, which in turn contain nodes and connections. Each of these is represented as a strongly typed object. By default, nodes include layout properties like position and size.

This results in a neat OOP hierarchy where everything is properly defined and serialized. The upside is ease of development - you simply call Serialize() at the top level and the rest follows. However, the downside is that parsing becomes nearly impossible without full knowledge of the exact object types. Any misalignment in type expectations results in binary stream reading errors.

Derivations

Since Divooka graphs can already be represented in text via the Open Standard, I’ve proposed two derived, minimalist formats: MiniParcel and MicroParcel. These are lightweight, CLI-friendly formats designed for shell use. The rationale is that since nodes can represent abstract functions or endpoints, users should be able to manipulate them without relying on a GUI.

Default:
    FileList = GetFiles "{tempFolderPath}"
    FileRenameList = Enhance @FileList !#Rename
    Apply @FileRenameList !MoveFile
Rename:
    FileName = GetOnlyName (GetArgument :0)
    Return (Replace @FileName ":File_Sequence_00(.)" ":File-Sequence-00$1")

Conclusion

As we finalize prototyping and start committing to core design decisions, file format is one area requiring careful long-term thinking. There’s an inherent trade-off between programmability and readability/portability - especially since Divooka documents may eventually hold a vast variety of data.

In the foreseeable future, both formats may coexist. In fact, it might make sense to support both for the long term. As Divooka matures and gains better standardization, I’m hopeful we’ll arrive at a robust format that truly supports the long-term vision.

References

Rationale for Godot’s custom INI format: GitHub discussion
Divooka Document Specification: future link

DevLog 2025801: Procedural Context Type

Sat, 02 Aug 2025 01:47:41 +0000

Overview

In our pursuit to challenge existing visual paradigms and establish the next-generation general-purpose visual programming system, we've studied, borrowed from, and questioned many design elements of existing systems.

An area of innovation in Divooka is its hybrid use of dataflow and procedural contexts - each suited for particular use cases.

Another innovation, still in its infancy and improving through trial and error, is what we call the procedural context base type.

Introduction

The need for this concept emerged as we integrated procedural contexts and re-examined the pain points of working with advanced visual programming systems like Unreal Blueprint. Changing the base type of Blueprints often leads to disastrous outcomes.

We aim to provide a smoother experience. In Divooka, the procedural "base type" is a toggle - you can quickly switch a graph to a different base type. Everything that isn't type-dependent continues to work, and any function that is type-dependent simply indicates so.

Components

The procedural base type introduces four important concepts:

Procedural base type (current anchor): The current graph's base, representing the instance that functions in the graph are called on.
Procedural runner for any given base type: When a run is triggered, Divooka allows a custom runner to determine what actually happens. In a typical program, this runner might seek the "entry" function (e.g., Start) and execute from there. In higher-level frameworks, it might look for recognizable event bindings.
Procedural base type instance override: By default, the specified base type is instantiated at runtime to provide a concrete instance. However, the runtime can also supply a compatible instance for the graph's behavior to operate on. This allows flexibility and decouples implementation (runtime instance) from behavior specification (graph design).
Divooka graph-baked procedural instance type: It may be desirable to directly convert or interpret a graph as a concrete type. The main benefit is being able to pass the graph as a type for further processing. This feature is not yet implemented.

Based on the above, three key objects are involved in evaluating a procedural context graph:

Executer: Provides the logic and mechanisms to fetch and evaluate specific execution paths in the procedural graph.
Runner: Determines what to run and in what order, on an event level. It may also provide additional runtime data required by the instance.
Instance: Represents the runtime state of the graph.

Summary

In summary, a Divooka graph is a data structure that specifies behavior, while the runtime interprets and is responsible for actual execution. This makes Divooka a data-driven and highly extensible programming system suitable for various scenarios.

By combining the scripting nature of Divooka graphs with the compiled/JIT-accelerated nature of the runtime, Divooka offers both flexibility and dynamic richness - while minimizing friction in program development.

DevLog 20250729: Procedural Terrain Generation

Tue, 29 Jul 2025 17:21:12 +0000

Intro

Procedural generation, often called algorithmic art, is the process of turning code into visual content. Unlike generative AI, which can often feel "either works or doesn't", procedural generation offers predictable results and detailed control over every element of the outcome. Unlike simulation, its process is less about modeling physical phenomena and more about manipulating data through arithmetic and logic.

In practical production, procedural generation rarely stands alone. It’s usually combined with hand-crafted elements to achieve a balance between efficiency and artistic vision - a good example is the diverse planets in No Man’s Sky, which mix algorithmic rules with human-made textures and assets. Unreal Engine’s City Demo is, in my opinion, one of the most condensed showcases of how far this paradigm can be pushed. Yet, as I will discuss in a future article, procedural generation also faces diminishing returns: the more we aim for total automation, the less room we leave for meaningful artistic decisions. For world-building (not just game design), it often makes more sense to focus on curated, high-quality content rather than endlessly expanding algorithmic variety.

How does it has to do with Divooka?

When we talk about general-purpose, low-level procedural generation, three tools come to mind: Houdini, Blender Geometry Nodes, and Rhino Grasshopper. All three embrace a dataflow mindset, where complex results emerge from chaining and manipulating small, modular operations.

At its core, procedural geometry is about transforming data points - vertices, edges, and faces - through parametric relationships. The same happens when working with a dataflow diagram: each node transforms data in a specific way, and the network of nodes collectively defines the outcome. This data-centric, rule-based mindset has a strong connection to what I envision for Divooka. It’s not just about "automating" art; it’s about building a flexible, modular pipeline where small algorithmic rules can shape a larger creative vision.

Procedural Terrain Generation

Among all categories of procedural content, terrain generation stands out as being easily feasible while also present just enough technical and artistic challenge. Procedural terrains, trees, and clouds - when done well - can be indispensable in environmental design. These elements create a sense of scale, variety, and believability that would be prohibitively expensive to craft by hand, especially at scale.

Procedural humans are another major frontier, as projects like MetaHuman have shown. However, most current solutions in this area remain asset-based (pre-designed components combined procedurally) rather than fully algorithm-driven, due to the complexity of human anatomy and subtle facial variations.

What makes procedural terrain generation truly interesting is its multi-scale nature. The same algorithms that define the curvature of a hill, the placement of a forest, or the erosion patterns of a mountain range can be scaled up as procedural rules to shape entire planets, as seen in projects like Outerra or the planet tech behind Star Citizen.

For terrains specifically, there are multiple approaches:

Parametric modeling: Platforms like TerraGen and Vue provides drop-in procedural terrains that works at large scale, at the sacrifice of simulating natural erosion, weathering, and geology.
Heightmap-based workflows: Tools like World Machine remain the gold standard here, providing artists with granular control over erosion layers, noise functions, and texturing.
Hybrid artistic sculpting: Recent software such as World Creator blends procedural systems with direct, real-time sculpting, letting artists guide the procedural logic for more intentional results.
Biomes and planet-scale world maps: Beyond local terrain detail, truly massive environments need a global "climate" layer to drive ecosystem placement and continental shapes. Typically you start by generating low-frequency noise on a sphere (using an icosphere or cubemap projection) to define elevation, temperature, and moisture fields. These three channels feed a biome classifier (for example, using Whittaker’s biome chart) to assign regions like tundra, desert, rainforest, or grassland. Then, by layering higher-frequency noise and erosion simulations, you carve coastlines and mountain ranges that respect those climate zones. On top of that, you can stream in progressively finer mesh tiles or voxel chunks as the viewer approaches, blending seamlessly from a planet-wide view down to individual hills and caves. This multi-scale, data-driven pipeline lets you create a consistent, believable world map—where a river born in snowy peaks will reliably flow toward warmer, wetter biomes, and deserts will hug the rain shadows of mountain ridges.
Voxel and simulation-driven worlds: Games like Minecraft and Dwarf Fortress have shown that procedural generation can build entire, fully interactive worlds at massive scale, with layers of terrain below the surface.

Conclusion

Procedural generation is more than a tool - it’s a mindset, and a skill requiring practising. It allows creators to define rules and systems rather than individual assets, creating worlds that feel alive, infinite, and varied. However, its real power comes when balanced with handcrafted content, ensuring that algorithmic variety never comes at the cost of artistic intent.

For Divooka, the challenge (and opportunity) lies in embracing procedural workflows without losing sight of the content’s purpose. A beautiful world isn’t necessarily one that is infinitely generated - it’s one where the procedural tools empower the creator to focus on meaning, storytelling, and design.

DevLog 20250728: Multi-graph Navigation GUI

Tue, 29 Jul 2025 17:19:46 +0000

Overview

From the beginning, we've expected Divooka documents to support multiple graphs for efficient daily use. I consider this essential for scripting purposes, as dealing with file system entry references should be the last thing on our minds when trying to get something done quickly.

However, implementing this isn't straightforward. Several interesting and foundational features are required first: serialization, file format support, editor refactoring - and graph referencing, which we may discuss in a future entry.

In traditional programming languages, especially object-oriented ones, similar functionality is often achieved by allowing multiple classes per file. In C#, for example, it's even possible to define partial classes across separate files, which can become confusing if not managed carefully.

Objective

When working with multiple graphs in a single document, the experience should feel similar to working with separate documents that each contain a single graph. At the most basic level, the editor should allow quick and seamless switching between graphs. More advanced features will come later. For example, storing multiple graphs within a single document should eventually enable referencing those graphs or documents from other documents.

Implementation Progress

Today's goal was to support navigation and switching between different graphs in Neo.

Preliminary work on refactoring the graph editor into a reusable component was already completed earlier. This refactor is also crucial for enabling the subgraph editing window.

To maintain context when switching graphs, the current viewport remains unchanged. We've also implemented a mini-map to help users quickly identify their location within the graph.

Minimap Behavior

The math behind the minimap is a bit tricky, so it's worth documenting:

When switching between graphs, the editor should either preserve the current viewport (location and zoom) or reset the view to the center of the new graph.
A "world boundary" must be calculated that encompasses all nodes in the graph.
A "viewport boundary" should also be calculated to represent the currently visible area of the canvas.
The minimap scale (typically less than 1 to represent downscaling) should be the minimum of:
- minimap size / world size, or
- minimap size / viewport size, if the viewport is larger than the world (e.g., when zoomed out).

Other Matters

The Neo graph editor is taking noticeably longer to load lately. We may need to investigate and address performance issues soon.

DevLog 20250726: C# is the way, Python gets things done, JavaScript is convenient

Sat, 26 Jul 2025 19:57:25 +0000

Throughout my day-to-day life, both personal and professional, there is a need for lots of "small" utilities, like converting a TSV to a Markdown table, generating a random choice, converting PNG to ICO, or quickly counting the number of lines in a C# project.

In the past, I've addressed all of those with a mix of Pure and C# - most are available in source. However, lately I've been hitting efficiency bottlenecks even with Pure or Divooka.

Today I was once again trying to convert a TSV to Markdown. However, since I haven't done it for a while, even though I know the script must exist somewhere on my disk, I do not want to waste time looking for it using Everything. Instead, what I really want is to be able to instantaneously spawn it and just run it. We could set up shortcuts, and maybe even make use of Launcher (Big White Dot) - but it would be really nice if there were a single entry point to search for such tools, and it's always available, no matter where I am, or which device I am using - like a random choice generator.

Apparently, for such simple small tasks, like random choice generation, Markdown conversion, Markdown table conversion, and PNG/ICO conversion, there are already tons of similar websites for quick, easy online use. However, most of them are filled with ads or have unclear privacy terms. It's thus more desirable to have a host of my personally built, personally customized, clean utilities, completely under my control.

Nowadays, with video coding and advanced code generators, I can create a single-page website in a few minutes, push it to GitHub, and a few minutes later the utility is accessible online - no ads, no hosting, no additional cost. That code is in HTML + CSS + JavaScript, though.

A similar thing happened a few weeks back for a personal project in which I had invested heavily in C++ before. During a revisit, I realized I could easily achieve the same results, plus more, with Python and some third-party libraries. I won't consider that setup "production grade," but it's stable, safe, and can likely run for years to come.

We always say "use the right tool for the task" - but we can be conservative by asking questions like: what if I need to link this in other apps, what if I need to reuse it, what if the code grows and I need more advanced debugging support? But eventually, the right approach is just to start over in a new language or setup when the time comes. I know C# is the way, but Python can get things done, and JavaScript is just convenient for immediately making things accessible.

What does this mean for Divooka? Well, convenience has many facets, and I think we should focus on accessibility first.

DevLog 20250724: C# Scripting, Pure 2, Updated + Some Recap

Fri, 25 Jul 2025 01:39:40 +0000

Intro

Pure has been our in-house C# scripting solution for a few years now.
After experimenting with the well-known CS-Script and some other solutions I can no longer recall, I began experimenting with Roslyn in .NET around 2022/2023, and it's been working well ever since.

Usage

Below is a basic Pure script and its execution:

using static System.Console;

var sum = File.ReadLines("Data.csv")
    .Skip(1)
    .Select(l => l.Split(','))
    .Sum(parts => double.Parse(parts[1]));
WriteLine(sum);

Recap

Version 0.0.3

The first version of Pure was just a simple wrapper around Roslyn. Later, we expanded it to support syntax like Import(MathNet.Numerics). It wasn't until we added native libraries like CSV, ODBC, and CentralSnippets that things started to get interesting.

Motivation

Below is an old table I compiled when first drafting the design document for Pure (1), with some updates to mention newer solutions:

What's Special

Pure 2 is a lightweight C# scripting platform with modern C# 12 syntax and easy NuGet import support. Pure is based on Roslyn. In addition to the base .NET runtime, Pure offers additional libraries for handling common tasks, along with a handy scripting interface (REPL and Notebook) and a place where people can share their snippets.

Pure 2 is conceptually similar to Pure but architecturally very different - it directly builds upon Parcel NExT's Ama runtime (the same runtime used by Divooka). Pure is designed for very short snippets and getting everyday tasks done faster.

Pure 2 uses C# 12 and is similar to top-level statements in C#, with the following features:

You can define types and functions anywhere in the middle of the script.
Pure has its own package import behavior (default namespace usage and package lookup rules).
Default global scope math functions, and default using for System.IO and System.Linq.
Top-level function and variable definitions, alongside classes and other common C# constructs.
Simplifies common tasks even further.
Macros to support text-based parsing, file inclusion, and module imports.

Features

Single-word standard package names. One-command NuGet package import and on-the-fly package invocation (through Import).
Full compatibility with Divooka packages and Divooka graphs.
Pure uses PUREPATH to search for scripts when using Include and when executing script files directly from the command line as the first argument.
Pure is very lightweight and will always be a thin layer on top of Roslyn/.NET runtime.
CLI REPL; GUI Notebook.

Basic Syntax

Certain macros/syntax are provided to implement language-level scripting constructs:

Summary

Be aware that adopting a scripting system - any scripting system - comes with significant risks. It's wise to plan carefully and pick the best tools for the task at hand.

References

Download page for Pure 2 on Methodox Itch.io
Official Page for Pure 2 on Methodox Wiki

DevLog 20250711: Flappy Bird in Divooka! (Sneak Peak)

Fri, 11 Jul 2025 19:38:55 +0000

Sneak Peek

I'm very excited to share some updates, along with this early demo video of making and playing Flappy Bird in Divooka! Please take a look at our YouTube for the HD video!

There's a lot of technology packed into and behind this little demo.
Sure, there are hacks here and there - like all video games - and there's still tons to be done to make it production-ready and robust. But I think this is a good, solid proof-of-concept! We are at least at parity with what Unreal Engine Blueprint can achieve for interactive 2D games!

Overview

Divooka by Methodox is our flagship visual programming language and programming platform.

In the YouTube video, I shared a quick demo of the program setup, graph layout, and runtime behavior of Flappy Bird made in Divooka.

This setup is entirely done in the Divooka procedural context as a proof of concept for competitive runtime performance, suitability for practical program development, general applicability of the Divooka language, and the availability of Glaze! - our real-time graphical application API.

A detailed tutorial, along with all resource files, will be shared under the Methodox Wiki when the time comes.

Dev Process

The latest update on the procedural context visual debugger has been really helpful!

For the purpose of this particular demo, I started in Divooka, then realized lots of missing pieces. So I drafted the API for Glaze! first, then did a benchmark in C# - so actually, there is a pure C# implementation before the Divooka implementation.

The urgent need for generics becomes evident when we don't have structs and other OOP constructs in Divooka - we need a way to contain tuples of values in collections.

Commentary

Unreal Engine can already do it - and we're just catching up. On the other hand, Unreal Engine actually packs a similar size - but with way more features! Reducing distribution size is something that will require tremendous effort from us.

References

Learn more about procedural context: Methodox Wiki
YouTube: Divooka Visual Programming
Tutorial on making Flappy Bird in Divooka(WIP): Methodox Wiki

DevLog 20250711: Limitations of Scratch

Fri, 11 Jul 2025 12:55:09 +0000

Revision: 1
Last update: 2025-07-11
Tags: Reference

Scratch is top 20 most used programming language in TIOBE index. Understanding limitations of other programming systems is key to improving our own programming language (Divooka).

Scratch targets a different audience than we do, however, it's very well-designed, highly accessible and well adopted. Due to its visual paradigm similarity, we use it as a point of comparison for Divooka in terms of fidelity.

Scratch is designed for learning and small‐scale animations or games. It does this job really well.

Advantages

Here are some of the major advantages of using Scratch as a first programming environment:

Intuitive, Low-Barrier Visual Interface
Scratch's drag-and-drop block system eliminates syntax errors and lets learners focus on concepts rather than typing rules. Its colorful, tactile blocks and immediate feedback make it fun and engaging from the very first project.
Fosters Creativity and Engagement
With Scratch, users can build interactive stories, animations, games, music and art - mixing sprites, sound and backgrounds to realize their ideas. This "Imagine-Program-Share" cycle encourages open-ended exploration and artistic expression.
Promotes Computational Thinking & Problem-Solving
By snapping together blocks for loops, conditionals, variables and events, students naturally learn decomposition, algorithmic thinking and debugging strategies. Scratch even introduces parallelism - each sprite runs its own scripts - so beginners see concurrency concepts early on.
Vibrant, Collaborative Online Community
The Scratch website hosts millions of "Scratchers" who share, remix and comment on projects. Community-run studios and design challenges foster collaboration, peer feedback and iterative learning - building social-emotional as well as coding skills.
Highly Accessible & Inclusive
Scratch is completely free and runs in any modern web browser (or as an offline desktop app). It's translated into over 50 languages and its block-based format lowers barriers for learners with dyslexia, limited typing skills or other challenges.
Educationally Aligned & Cross-Disciplinary
Used in thousands of schools worldwide (from elementary through college), Scratch supports math, science, history and language arts lessons through interactive simulations and tutorials. Educators leverage it to visualize abstract concepts and design project-based assessments.
Strong Foundation for Future Coding
Concepts mastered in Scratch - sequencing, events, data structures - translate directly to text-based languages like Python and Java. Many curricula use Scratch as a stepping-stone to more advanced computer science topics and career pathways.
Builds Confidence & Persistence
The instant, visual nature of Scratch's feedback loop - see your sprite move as soon as you snap a block - encourages learners to experiment, iterate and persist through challenges, laying the groundwork for resilient problem-solving habits.

Limitations

It runs into trouble once you're trying to build "real" software. Below we enumerate some major pain points, and some ideas for how to overcome each.

1. Monolithic, Flat Project Structure

What happens in Scratch:
All your code lives in sprites and the Stage, with no real namespace or folder hierarchies. It's like having every chapter of your novel printed on Post-its stuck to one wall.
Why it's a problem at scale:
- Hard to organize hundreds of scripts
- Difficult to see "what calls what"
- Prone to name collisions when you start copying-and-pasting blocks
How to address it:
- Custom block libraries: Treat each custom block as a mini-module, and group them carefully by sprite (e.g. "Physics," "UI," "Data").
- Transpile to text code: Export your project to JavaScript or Python (via tools like TurboWarp or external transpilers) so you can organize into real files and folders.
- Adopt a hybrid editor: Use tools like MakeCode or Blockly that let you switch between blocks and text, and support hierarchical file structures.

2. No Real Version Control

What happens in Scratch:
You "Save" or "Remix," and history is opaque. There's no Git diff you can read or "branch" your experiments.
Why it's a problem at scale:
- Team collaboration stalls
- Risk of overwriting each other's work
- Hard to roll back a specific change (e.g. "Why did the scoring logic break on June 10?")
How to address it:
- Structured exports: Regularly export your project as SB3 and check those binary files into a Git repo with clear commit messages.
- Text-based backups: Leverage a transpiler to convert Scratch blocks into JavaScript or Python, then use Git on the resulting code.
- Use a visual-code platform with Git support: Divooka or alternatives (e.g. Node-RED, Blockly) that let you commit changes as text under the hood.

3. Limited Language Features

What happens in Scratch:
You get basic loops, conditionals and variables, but no classes, no modules, no first-class functions, no generics.
Why it's a problem at scale:
- You can't encapsulate complex behavior neatly
- Difficult to share sophisticated libraries (e.g. a math library or HTTP client)
How to address it:
- Extension mechanism: Build or use native extensions (ScratchX or TurboWarp extensions) to expose advanced APIs (file I/O, networking, data structures).
- Hybrid blocks + text: Offer a "power user" mode where blocks desugar into real functions and classes in a host language.
- Migrate critical components: For performance- or feature-critical parts (e.g. physics engine), write them in C# or Python and call them via an FFI-style bridge.

4. Performance & Resource Constraints

What happens in Scratch:
All scripts run in a single-threaded VM with modest optimization; large loops or many clones can slow everything to a crawl.
Why it's a problem at scale:
- Complex simulations or data processing become unbearably slow
- No easy way to leverage multiple CPU cores or GPU
How to address it:
- Chunk and yield: Break big tasks into small chunks and let the scheduler breathe (e.g. use wait 0 secs strategically).
- Native compute modules: Offload heavy work into native extensions written in C/C++/Rust.
- Parallelizable architecture: Move to a platform (like Divooka) that supports true multithreading or asynchronous tasks.

5. Debugging & Testing

What happens in Scratch:
You're limited to watching sprites move, sprinkling in say blocks or using the "block watcher." There's no unit-test framework or breakpoint debugger.
Why it's a problem at scale:
- Bugs hide in tangled event chains
- Hard to write repeatable regression tests
How to address it:
- Logging extension: Create blocks that log to an external console or file.
- Test harness in code: Transpile critical logic into plain code and write unit tests (e.g. using pytest or NUnit).
- Visual breakpoint system: Enhance your tool (or use TurboWarp) to allow pausing and inspecting variables at runtime.

6. Collaboration & Team Workflow

What happens in Scratch:
Mostly a single-user hobby environment with "Remix" as the only share option.
Why it's a problem at scale:
- No real task assignment or issue tracking
- Unstructured remixing leads to forks with no merge path
How to address it:
- Integrated project management: Embed issue-tracking metadata in your SBC file or alongside exports.
- Merge tooling: Use text-based diffs (after transpilation) and Git-based PR workflows.
- Role-based access: Adopt an environment where you can assign "developer," "reviewer," "tester" roles, with locking on code units.

Bottom Line

Scratch is an incredible gateway for learning programming fundamentals and building quick prototypes. But when you're talking hundreds of sprites, gigabytes of assets, dozens of collaborators, or millions of lines of logic… you need:

Modularity & namespaces (think packages)
Text-based exports for version control
Advanced language features & extensions
Performance optimizations via native code
Real debugging & testing frameworks
Team collaboration workflows

Many of these gaps can be addressed by extended platforms like Snap!, Blockly/MakeCode and TurboWarp.

DevLog 20250710: ComfyUI API

Thu, 10 Jul 2025 15:05:51 +0000

ComfyUI's architecture can seem opaque at first glance, particularly for those approaching it from another platform or without a deep dive into its internals. This has led to some overly complex integration attempts. In reality, however, ComfyUI offers a clean, extensible interface. Every running instance acts as a full-featured API server - in fact, the ComfyUI frontend is essentially just a visual client layered on top of this API.

Overview On Architecture

ComfyUI is fundamentally a node-based interface and inference engine for generative AI, designed with a clear separation between frontend and backend. Under the hood, every ComfyUI process spins up a Python HTTP server that exposes both REST and WebSocket endpoints, meaning the familiar graphical canvas you interact with is simply one of many clients talking to this API-first backend.

Because the UI itself is just a "front end" for these same endpoints, you can swap it out entirely or layer additional tooling on top without touching the core. For example, the backend defines routes like /ws (a WebSocket endpoint for real-time status and currently executing-node updates) and /prompt (a REST endpoint to enqueue a workflow), which are the exact primitives any programmatic client or custom UI uses to interact with ComfyUI.

Beyond the core node types, ComfyUI's architecture is highly extensible via "API Nodes," special nodes that connect to closed-source or third-party AI services through external HTTP APIs. These API Nodes behave just like any other node in a workflow - once installed, they’re automatically discoverable through the same server endpoints, underscoring the system’s API-first design and seamless plugin support.

The API

There are two primary usage patterns for interacting with ComfyUI at the API level:

Editor-like Interface

In this mode, you explicitly build and manipulate workflow graphs before executing them. ComfyUI’s GitHub repository includes a script_examples folder with Python scripts that demonstrate how to:

Discover all available node types and their parameters.
Assemble a workflow graph as a JSON object (mapping node IDs to class_type, inputs, and optional metadata).
Save or load these JSON graphs to and from disk.
Submit the graph to the server via HTTP (e.g. to /prompt) for execution.

Because everything - node definitions, graph structures, and execution commands - is pure JSON over HTTP, you can implement a full-featured visual editor or headless pipeline in any language or framework that supports HTTP and JSON ([GitHub][5]).

Runtime-like Interface

This simpler mode treats ComfyUI as a pure inference engine. Typically, you maintain a library of pre-built workflow JSON templates, and at runtime:

Step 1. POST your chosen graph JSON to http://<host>:<port>/prompt:

POST /prompt
Content-Type: application/json

{
 "prompt": { …complete workflow JSON… },
 "client_id": "optional-client-id"
}

On success, you receive a prompt_id to track the job.

Step 2. Track progress by opening a WebSocket connection to ws://<host>:<port>/ws. This provides messages about which node is currently executing, along with overall status updates - ideal for real-time visibility into long-running workflows.

Step 3. Retrieve results (e.g. output image filenames and metadata) via:

GET /history/<prompt_id>

This returns a JSON payload listing saved images, their directories, and any workflow metadata needed to fetch or display the outputs.

This runtime-style pattern is ideal for integrating ComfyUI into production applications, batch-processing pipelines, or serverless functions, as it requires only minimal client logic.

Primary endpoints in use:

http://127.0.0.1:8188/prompt - send prompt into execution queue
http://127.0.0.1:8188/history
http://127.0.0.1:8188/history/{prompt_id} – returns results when complete
http://127.0.0.1:8188/view - retrieve images
http://127.0.0.1:8188/queue

For deeper insight, studying the server source code is highly instructive:

Summary

To summarize, working with ComfyUI programmatically is straightforward - simply use the /prompt endpoint to submit workflows, as illustrated below.

Step 1. Get the node catalogue (optional but useful): GET /object_info returns the entire node class library, including inputs, outputs, default values, and documentation - perfect for editor autocompletion or scripting.

Step 2. Build or load a workflow JSON:

Create it using the GUI or
Assemble it programmatically (see script_examples/build_json.py).

Step 3. Submit the workflow:

curl -X POST http://127.0.0.1:8188/prompt \
-H 'Content-Type: application/json' \
-d '{"prompt": YOUR_WORKFLOW_JSON,
 "client_id": "my-tool"}'

On success, the server returns: {"prompt_id": "<uuid>"}.

Step 4. Track execution progress (real-time):
Open a WebSocket to ws://127.0.0.1:8188/ws?clientId=my-tool and listen for messages:

{ "type": "executing", "data": {"node": 42} }

Useful for logging, progress bars, or live UIs.

Step 5. Fetch results:
Once execution is complete, request GET /history/<prompt_id> to retrieve a list of output files and metadata. To download or stream an image, use /view?filename=....

This flow - build JSON → POST → (optional WebSocket) → GET history - is versatile enough to power both editor-based prototyping and production-scale batch jobs.

Quick Reference

Verb	Endpoint	Purpose
`POST`	`/prompt`	Queue a workflow
`GET`	`/history/<id>`	Fetch results and metadata
`GET`	`/object_info`	Explore available nodes
`GET`	`/queue`	View queued or running jobs
`WS`	`/ws`	Live status updates

References

Hosting a ComfyUI Workflow via API by 9elements
Official ComfyUI API Example
Discussion on ComfyUI Prompt API Endpoints: Github Issue 2110
and Github Issue 6607
A video walkthrough on ComfyUI API by Methodox: Divooka Visual Programming
Use ComfyUI in Divooka: Methodox Wiki

Appendix - Requests

Because it's very useful and rarely available in such shocking detail, here I am providing full requests for quick reference.

Request and responses:

# POST http://146.190.245.196:8188/prompt
{
  "prompt": {
    "3": {
      "inputs": {
        "seed": 1044669037100678,
        "steps": 20,
        "cfg": 8,
        "sampler_name": "euler",
        "scheduler": "normal",
        "denoise": 1,
        "model": ["4", 0],
        "positive": ["6", 0],
        "negative": ["7", 0],
        "latent_image": ["5", 0]
      },
      "class_type": "KSampler",
      "_meta": {
        "title": "KSampler"
      }
    },
    "4": {
      "inputs": {
        "ckpt_name": "v1-5-pruned-emaonly-fp16.safetensors"
      },
      "class_type": "CheckpointLoaderSimple",
      "_meta": {
        "title": "Load Checkpoint"
      }
    },
    "5": {
      "inputs": {
        "width": 512,
        "height": 512,
        "batch_size": 1
      },
      "class_type": "EmptyLatentImage",
      "_meta": {
        "title": "Empty Latent Image"
      }
    },
    "6": {
      "inputs": {
        "text": "beautiful scenery nature glass bottle landscape, , purple galaxy bottle,",
        "clip": ["4", 1]
      },
      "class_type": "CLIPTextEncode",
      "_meta": {
        "title": "CLIP Text Encode (Prompt)"
      }
    },
    "7": {
      "inputs": {
        "text": "text, watermark",
        "clip": ["4", 1]
      },
      "class_type": "CLIPTextEncode",
      "_meta": {
        "title": "CLIP Text Encode (Prompt)"
      }
    },
    "8": {
      "inputs": {
        "samples": ["3", 0],
        "vae": ["4", 2]
      },
      "class_type": "VAEDecode",
      "_meta": {
        "title": "VAE Decode"
      }
    },
    "9": {
      "inputs": {
        "filename_prefix": "ComfyUI",
        "images": ["8", 0]
      },
      "class_type": "SaveImage",
      "_meta": {
        "title": "Save Image"
      }
    }
  }
}
# Response
{
  "prompt_id": "26bc628d-7ab2-43e6-8a67-d6a793e7fbcc",
  "number": 1,
  "node_errors": {}
}

# GET http://146.190.245.196:8188/history/26bc628d-7ab2-43e6-8a67-d6a793e7fbcc
{
  "26bc628d-7ab2-43e6-8a67-d6a793e7fbcc": {
    "prompt": [
      1,
      "26bc628d-7ab2-43e6-8a67-d6a793e7fbcc",
      {
        "3": {
          "inputs": {
            "seed": 1044669037100678,
            "steps": 20,
            "cfg": 8.0,
            "sampler_name": "euler",
            "scheduler": "normal",
            "denoise": 1.0,
            "model": [
              "4",
              0
            ],
            "positive": [
              "6",
              0
            ],
            "negative": [
              "7",
              0
            ],
            "latent_image": [
              "5",
              0
            ]
          },
          "class_type": "KSampler",
          "_meta": {
            "title": "KSampler"
          }
        },
        "4": {
          "inputs": {
            "ckpt_name": "v1-5-pruned-emaonly-fp16.safetensors"
          },
          "class_type": "CheckpointLoaderSimple",
          "_meta": {
            "title": "Load Checkpoint"
          }
        },
        "5": {
          "inputs": {
            "width": 512,
            "height": 512,
            "batch_size": 1
          },
          "class_type": "EmptyLatentImage",
          "_meta": {
            "title": "Empty Latent Image"
          }
        },
        "6": {
          "inputs": {
            "text": "beautiful scenery nature glass bottle landscape, , purple galaxy bottle,",
            "clip": [
              "4",
              1
            ]
          },
          "class_type": "CLIPTextEncode",
          "_meta": {
            "title": "CLIP Text Encode (Prompt)"
          }
        },
        "7": {
          "inputs": {
            "text": "text, watermark",
            "clip": [
              "4",
              1
            ]
          },
          "class_type": "CLIPTextEncode",
          "_meta": {
            "title": "CLIP Text Encode (Prompt)"
          }
        },
        "8": {
          "inputs": {
            "samples": [
              "3",
              0
            ],
            "vae": [
              "4",
              2
            ]
          },
          "class_type": "VAEDecode",
          "_meta": {
            "title": "VAE Decode"
          }
        },
        "9": {
          "inputs": {
            "filename_prefix": "ComfyUI",
            "images": [
              "8",
              0
            ]
          },
          "class_type": "SaveImage",
          "_meta": {
            "title": "Save Image"
          }
        }
      },
      {},
      [
        "9"
      ]
    ],
    "outputs": {
      "9": {
        "images": [
          {
            "filename": "ComfyUI_00002_.png",
            "subfolder": "",
            "type": "output"
          }
        ]
      }
    },
    "status": {
      "status_str": "success",
      "completed": true,
      "messages": [
        [
          "execution_start",
          {
            "prompt_id": "26bc628d-7ab2-43e6-8a67-d6a793e7fbcc",
            "timestamp": 1745105352150
          }
        ],
        [
          "execution_cached",
          {
            "nodes": [
              "4",
              "5",
              "6",
              "7"
            ],
            "prompt_id": "26bc628d-7ab2-43e6-8a67-d6a793e7fbcc",
            "timestamp": 1745105352151
          }
        ],
        [
          "execution_success",
          {
            "prompt_id": "26bc628d-7ab2-43e6-8a67-d6a793e7fbcc",
            "timestamp": 1745105352778
          }
        ]
      ]
    },
    "meta": {
      "9": {
        "node_id": "9",
        "display_node": "9",
        "parent_node": null,
        "real_node_id": "9"
      }
    }
  }
}

# GET http://146.190.245.196:8188/view?filename=ComfyUI_00002_.png&subfolder=&type=output

# POST http://127.0.0.1:8188/upload/image
Multipart with `image` payload.
{
"name": "Test.jpg",
"subfolder": "",
"type": "input"
}

The Divooka Way - Part 1: Philosophically, How Exactly is Divooka Different and Useful

Wed, 09 Jul 2025 20:28:58 +0000

Full title: The Divooka Way — Part 1: Philosophically, How Exactly is Divooka Different and Useful Compared to Plain Good Code API
Tags: Visual Programming, Developer Tools, API Design, Software Architecture, Programming Paradigms, NVI, No-Code / Low-Code, Programming Philosophy, Tool Economy
Target Audience: Software Architects, Engine and Tool Developers, Programming Educators and Curriculum Designers, Low-Code/No-Code Platform Researchers, Senior Developers interested in alternative programming models, Developers interested in visual alternatives to traditional code*

Abstract

Traditional programming uses text to represent program logic. Existing visual design platforms offer varying levels of programmability but generally focus on building specific kinds of applications. From a production-use perspective, Divooka represents a significant step forward in how users build and interact with software - by combining tool-building, data handling, and program logic under a single, coherent interface. This unified approach aims to deliver a substantial productivity boost.

Overview

If we already have a really good library - just as we have high-quality commercial software - does it still matter what language or environment we use?

In theory, it shouldn't. In practice, it absolutely does.

Pretty much everything imaginable already exists for C++, often under GNU licenses. But that doesn't mean a Python, C#, or Java developer can easily access or use those resources. Even when libraries are available for a target language, usage may not be straightforward. Licensing, API design, and documentation all come into play.

Still, let's imagine we have a well-written, freely accessible, multi-language-bound, well-documented, and easy-to-use library. Does it then matter how we use it?

That leads us to the core question:

If we already have a really good API, why not just use it in C#, Python, C++, Lua, or Pure?

The Proof of Concept

To explore this, we can approach the question from three distinct perspectives:

The end user
The program designer
Everyday tool development and sharing

From the end user's perspective, assuming the final deliverable is a polished CLI or GUI tool, it typically doesn't matter what language was used - as long as the interface is well-designed. Case closed.

From the program designer's perspective, building anything sophisticated involves significant "dry" work - debugging, iteration, architectural decisions. Productivity depends largely on the quality of the debugger and IDE, and again, it's not strictly tied to the programming language.

But from the perspective of everyday tool use, the question becomes more subtle. What do we mean by "everyday tools"? Broadly speaking, we mean:

Tools built quickly to solve practical problems within days
Tools that are easy to share and use by others
Tools that are easy to iterate, improve, refactor, and eventually package as full software
Tools that are maintainable - so that months later, we can return and still understand what we were doing, without extensive documentation effort

To solve (1), you need extensive libraries.
To solve (2), you need solid dependency and packaging mechanisms.
To solve (3), you need simple syntax and easy refactoring.
To solve (4), you need expressive, self-documenting code - or better yet, self-explanatory program design.

It's in this third category - everyday tools - that Divooka stands out. The features baked into Divooka's graph editor enable rapid development without sacrificing performance or scalability. The editor itself proves how smoothly things can run with minimal setup: just open a graph document, and it works.

The NVI

In Divooka, the primary mode of interaction is the Node Visual Interface (NVI) - distinct from both CLI and GUI paradigms.

Each node represents a functional unit, and the connections represent program or data flow. Unlike CLI, NVI offers "autocomplete" visually - everything is made explicit through connection and layout. Unlike a GUI, an NVI is composed entirely of nodes and avoids complex syntax structures.

At the base is a node canvas, and programs are built using what we call node-driven design - a pattern that breaks software into node blocks, each representing a compositional or procedural component.

The main disadvantage of NVI compared to text-based programming is space inefficiency: nodes occupy screen real estate, reducing information density. But this is offset by improved readability: the visual layout shows the exact dependencies between functional units - something much harder to grasp in linear text code.

NVI becomes more powerful when it supports:

Subgraphs – Logical groups of nodes encapsulated into single blocks. This is more compact than plain functions or classes and more intuitive than managing multiple files.
Extensible node visuals – Nodes can be customized for specific data. For example, a Table node can offer compact entry for 2D data, reducing friction.

The Scripting Interface

At its core, the NVI exposes functionality in two ways:

Nodes represent standalone functional units in a Divooka document.
A framework parses the interconnected nodes and derives behavior from the graph structure.

The key is interface availability - file operations, media I/O, math routines, etc.

The first use case is covered well by scripting languages like Python, Lua, or Jupyter.
The second - interpreting a structured node graph into dynamic program behavior - is where traditional languages fall short, often requiring large, specialized frameworks (e.g., Streamlit for Python).

With Divooka, the same graphical program often needs no changes at all. A simple toggle in the host environment can completely redefine how the program behaves.

Frameworks like Glaze, Novella, Ol'ista, Slide Present, and App Builder (all part of Divooka Explore except App Builder) rely heavily on metadata - information not defined on the graph, but embedded in the document and interpreted by the host system.

This separation - code in the graph, behavior defined by metadata - creates a powerful, data-driven model that enables reuse, variation, and flexibility.

On the Matter of Libraries

Not all useful features are readily available via libraries. And even when they are, compatibility issues, licenses, platform differences, and interoperability challenges often make reuse hard or impossible.

At Methodox, we actively author and maintain a curated library set - toolboxes optimized for Divooka. This represents a major investment, ensuring that as Divooka grows, users have an expanding, well-integrated set of native components tailored for node-driven environments.

Summary

From a scripting standpoint, Divooka may appear unremarkable: libraries are still authored in native code, and Divooka simply provides an interface layer.

But methodologically, Divooka offers a profound shift in how we build and interact with programs. It's as different as using a natural-language model to co-write your software.

Divooka is a high-level, GUI-native, NVI-first programming system. Our belief is that this new format can significantly enhance productivity, readability, and maintainability by making programs smaller, clearer, less error-prone, and more intuitive.

One-Year Anniversary Reflection on The Development of Divooka

Tue, 08 Jul 2025 20:22:47 +0000

Overview

Methodox Technologies, Inc. - officially registered in Ontario at the end of July last year - has now been around for nearly a full year. Time has passed neither too quickly nor too slowly, moving along steadily as it always has. The biggest difference between running a company and doing personal side projects, in my view, can be captured with a comparison between passion and professionalism: when you do something out of passion, you choose based on interest; when you do something professionally, you commit regardless of mood or preference, working methodically toward clear goals and standards - day or night, rain or shine.

To put it more concretely, the difference lies in quality control. As someone with an engineering background, I'm not particularly gifted at self-promotion. What I can do - and do most naturally - is focusing on making a good product. Some friends have asked where the motivation comes from. Truthfully, I'm not entirely sure either. But like clockwork, I still wake up at 6:30 a.m. every day, ready to work.

The Story

When I first started working on Divooka, I didn't envision it as a fully-fledged programming language. I wanted it to be general-purpose, yes - but not necessarily from the standpoint of a programming language. The goal was more about decoupling the functionality from its environment, enabling it to run directly from the command line, and making the library design flexible enough to work beyond our immediate domain.

Initially, the biggest problem I wanted to tackle was how to replace Excel. There are many ways to go about that - because Excel's greatest strength is also its weakness: it's too powerful and flexible, which means it often lacks structure. And that chaos is what we wanted to bring order to. The first step was to build something on top of the spreadsheet concept - adding structure and rules, using something like object-oriented thinking to enable users to visually edit and link spreadsheet data.

Had we stayed on that path, the Divooka interface today would probably look more like floating spreadsheet windows - similar to Apple's Numbers - instead of the visual node-based editor you see now.

The Divooka Way

Back in 2019, I had already started exploring the idea of using general-purpose programming for GUI building. My approach then was more framework-oriented: tools that could generate UI wrappers based on flowcharts. These weren't new languages, but auxiliary features to make diagrams more reusable.

In early 2024, we also explored two major directions: graphic annotation and online collaboration, inspired by modern design tools like Figma and Google's cloud-based productivity suite.

The ability to build complete applications wasn't something I initially envisioned - it seemed too ambitious for what started as a personal side project. But going full-time removed that ceiling. It gave us room to think bigger.

One of the most natural and promising directions for Divooka is visual app development. Unlike traditional text-based languages, Divooka was built as a graphical, extensible environment from the start. Its own development environment is a Divooka app - one that is, in principle, programmable with Divooka itself. That vision is still in blueprint form, and full realization will take time.

Business Collaboration

From a business perspective, the experience of leading a team from late 2024 into early 2025 has been mixed. On the plus side, offloading certain tasks helped reduce some pressure. On the downside, with our current financial constraints, it's been hard to find help we can fully rely on - which, perhaps, is just reality.

Teamwork through outsourcing introduced its own challenges. Choosing the right people is tough. Even highly capable partners don't always deliver the expected results. Interestingly, ChatGPT and other large language models played a strange but useful role in this phase - mainly by helping with research and code scaffolding.

There's a pattern I've noticed: even when working with contractors, I end up defining the architecture and interfaces, and much of my time still goes into coordination. Once you're past the prototyping phase, iterations are limited, and results vary. In a similar way, large language models tend to produce "one-shot" outputs - either useful or not. But if I've already built the structure, the autocomplete results I get from an LLM often rival what a junior outsourced developer might provide.

In that sense, I'd much rather work closely with people over time - collaborating, communicating, and refining a shared workflow. That's where real teamwork becomes meaningful.

The Past

Early on, development followed a pretty rigid schedule - when it was just me, with no meetings or other obligations, daily goals were clear and straightforward. But by mid-year, things were shifting constantly. On the one hand, that brought flexibility, and led to a number of unexpected developments, especially in product direction. On the other hand, such reactive planning made it harder to estimate timelines. A case in point: our "first full version," originally scheduled for release this February, will likely be delayed until next year.

But as mentioned earlier, even the definition of what qualifies as a "first full version" has evolved dramatically.

In many ways, my approach to this company mirrors how I ran projects in university. First, I'm still the main driver and implementer. Second, I remain cautious when it comes to collaboration. Over the years, I've come to understand the Economy of Scale in a deeply personal way - not in terms of wealth or headcount, but in how accumulated skills and better tools dramatically boost my individual productivity. In this age of AI, that effect is more visible than ever. Contrary to popular belief, knowledge - not just capital - is the primary engine of productivity.

That said, if you do have capital and a great team, collaborative scale can still achieve amazing things.

Entrepreneurship

One of the more surprising (though perhaps not shocking) aspects of this journey has been the mix of encouragement and skepticism I've received. Support has mostly come from peers in the professional world, while more traditional voices - old friends from university, family members - have tended to be more doubtful. Though, of course, there have been exceptions in both camps.

This kind of reaction isn't often talked about on social media, but I think it's worth reflecting on.

First, people naturally fear what they don't understand. Second, those closest to us - friends, family - end up becoming supporters in one way or another, whether they intend to or not. Third, when it comes to values and personal incentives, people respond differently to attempts to break convention - especially where money is involved.

At a few conferences, I've had the chance to talk with other founders. Their motivations, strategies, and philosophies run the full spectrum. Some of the most frustrating folks are those who throw around the term "AI" without substance. (We too fell into that trap at one point, admittedly.) But these experiences - moments of confusion, attempts to find clarity - have opened up my view of the world far more than reading philosophy books or binge-watching TV shows ever did.

The Future

Looking ahead, I see three key challenges:

Finishing development and releasing the first full version of the software.
Creating a complete educational system around it, ensuring product coherence and knowledge accessibility.
Marketing and forming partnerships, while keeping the company sustainable.

2026 will be a demanding year. We'll need to maintain development speed while trimming back unnecessary administrative tasks. We want to move with precision, but not become overly cautious. The path forward requires boldness, care, grounded execution, and avoiding the lure of shortcuts. That's something I need to keep reminding myself.

DevLog 20250708: Procedural Context Visual Debugger in Divooka

Tue, 08 Jul 2025 12:19:17 +0000

Overview

How difficult is it to achieve Unreal Engine-style procedural context debugging?

Turns out, it might be easier than expected.

In this dev log, we won't implement all the fancy animations or full-featured GUI yet, but we will derive a practical, functional debugger GUI. This interface allows users to step through a procedural program and observe its execution flow in real time.

The Debugging Problem

Procedural contexts are hard - not necessarily to implement (they're actually simpler than dataflow contexts in interpretative runtimes, where you just step over nodes), but hard for users.

The main issue is statefulness: once there's state, there's the potential for mistakes, side effects, and confusion.

From an implementation standpoint, the hard part is debugging. Without visibility into execution, it's difficult to guess what's happening. That's why programming languages without IDEs often fall back on Print statements to inspect runtime states. This approach quickly breaks down with larger programs or those involving intricate state transitions.

Even Python - often used without an IDE - includes a built-in debugger in IDLE (see tutorial). It's essential when working with complex logic.

Approach

Let's start by clarifying the setup: the current implementation of the Divooka graph editor (Neo) is done in WPF, using an interpretative runtime.

For drawing the GUI, we can use standard XAML data bindings and a few button states:

<StackPanel>
<!--Start-->
<Button Style="{StaticResource IconButtonStyle}" Click="ProceduralContextRunGraphWithoutDebugging_Clicked" ToolTip="Run and wait for the process to finish." Visibility="{Binding EvaluatingGraph, Converter={converters:BooleanToVisibilityConverter Negate=True}}"/>

<!--Continue-->
<Button Style="{StaticResource DebugButtonStyle}" Content="Continue" Click="ProceduralContextContinueWithoutStepping_Clicked" ToolTip="Skip debugging and continue the process to completion." Visibility="{Binding IsProceduralStepping, Converter={converters:BooleanToVisibilityConverter}}"/>

<!--Step-->
<StackPanel Visibility="{Binding EvaluatingGraph, Converter={converters:BooleanToVisibilityConverter Negate=True}}">
<Button Style="{StaticResource DebugButtonStyle}" Content="Step" Click="ProceduralContextStartDebuggingGraph_Clicked" ToolTip="Step into the process and observe each execution step." Visibility="{Binding IsProceduralStepping, Converter={converters:BooleanToVisibilityConverter Negate=True}}"/>
</StackPanel>

<!--Next Step-->
<Button Style="{StaticResource DebugButtonStyle}" Content="Next" Click="ProceduralContextContinueThroughGraph_Clicked" ToolTip="Execute (step over) the next step in the process."  Visibility="{Binding IsProceduralStepping, Converter={converters:BooleanToVisibilityConverter}}" IsEnabled="{Binding IsProceduralPaused}"/>

<Button Style="{StaticResource DebugButtonStyle}" Content="Finish" Click="ProceduralContextFinishDebuggingGraph_Clicked" ToolTip="Stop debugging the current process." Visibility="{Binding IsProceduralStepping, Converter={converters:BooleanToVisibilityConverter}}"/>

<Button Style="{StaticResource DebugButtonStyle}" Content="Pause" Click="ProceduralContextPauseExecution_Clicked" ToolTip="Pause execution of the current process." Visibility="{Binding EvaluatingGraph, Converter={converters:BooleanToVisibilityConverter}}" IsEnabled="{Binding IsProceduralPaused, Converter={StaticResource InvertBooleanConverter}}"/>
</StackPanel>

Stepping Through Execution

Initially, I thought we needed a dedicated execution runtime for stepping, due to the complexity of node interpretation. However, it turns out we can simply inject "breakpoints" during interpretation. The simplest way to achieve this in C# with multithreading is by using a ManualResetEventSlim:

// ── MainWindow.xaml.cs (WPF) ──
public partial class MainWindow : Window
{
// starts signaled (i.e. not paused)
    private readonly ManualResetEventSlim _pauseEvent = new ManualResetEventSlim(true);
    private readonly Executer _executer;

    public MainWindow()
    {
        InitializeComponent();
        _executer = new Executer(_pauseEvent);
    }

    private async void StartButton_Click(object sender, RoutedEventArgs e)
    {
// Run on thread-pool, but because we 'await', continuation
        // (Finish…) runs back on the UI thread.
        await Task.Run(() => _executer.ExecuteGraph());
        FinishProceduralContextDebuggingSession();
    }

    private void PauseButton_Click(object sender, RoutedEventArgs e)
    {
// next time the worker hits Wait(), it will block
        _pauseEvent.Reset();
    }

    private void ResumeButton_Click(object sender, RoutedEventArgs e)
    {
// unblocks the worker
        _pauseEvent.Set();
    }
}

// ── Executer.cs ──
public class Executer
{
    private readonly ManualResetEventSlim _pauseEvent;
    private readonly Random _random = new Random();

    public Executer(ManualResetEventSlim pauseEvent)
    {
        _pauseEvent = pauseEvent;
    }

    public void ExecuteGraph()
    {
        while (/* your long-running condition */)
        {
            DoWorkStep();  

// simulate a random pause point
            if (_random.NextDouble() < 0.05)
            {
                Debug.WriteLine("…pausing now");
// put event into non-signaled (i.e. paused)
                _pauseEvent.Reset();
                _pauseEvent.Wait();  // block until resumed
                Debug.WriteLine("…resumed!");
            }
        }
    }

    private void DoWorkStep()
    {
        Thread.Sleep(200);
    }
}

How It Works:

_pauseEvent starts in the signaled state, so .Wait() returns immediately.
Calling _pauseEvent.Reset() switches it to non-signaled, so .Wait() blocks the worker thread.
When the UI calls _pauseEvent.Set(), the blocked thread resumes execution.

Real-Time Visual Updates

A small challenge is real-time canvas updates - specifically, drawing a highlight box around the active node:

We can use an adorner for this:

/// <summary>
/// Show a red highlight around the specified FrameworkElement for a set duration.
/// </summary>
public static async void ShowSimpleHighlight(FrameworkElement target, double margin = 5, int duration = 3)
{
    if (target == null)
        return;

// Get the adorner layer for that target
    AdornerLayer adornerLayer = AdornerLayer.GetAdornerLayer(target);
    if (adornerLayer == null)
        return;

// Create and add adorner to the layer
    HighlightAdorner highlightAdorner = new(target, margin);
    adornerLayer.Add(highlightAdorner);

// Remove it after a few seconds
    await Task.Delay(TimeSpan.FromSeconds(duration));
    adornerLayer.Remove(highlightAdorner);
}

public class HighlightAdorner : Adorner
{
    private readonly Pen _pen;
    private readonly double _margin;

    public HighlightAdorner(UIElement adornedElement, double margin = 5)
        : base(adornedElement)
    {
        _pen = new Pen(Brushes.Red, 2);
        _pen.Freeze();
        _margin = margin;
        IsHitTestVisible = false;
    }

    protected override void OnRender(DrawingContext drawingContext)
    {
        Rect adornedElementRect = new(AdornedElement.RenderSize);
        adornedElementRect.Inflate(_margin, _margin);
        drawingContext.DrawRectangle(null, _pen, adornedElementRect);
    }
}

What's Next?

All that's left is a proper debug window!

Summary

A good framework truly goes a long way. I had confidence in bringing procedural debugging to Divooka from the moment procedural context was introduced, because it naturally fits into an interpretative execution model. All that's required is a bit of focused engineering.

The more challenging part is the GUI - but WPF offers solid isolation via MVVM, data binding, and adorners.

We're not dealing with setting actual breakpoints yet, but the current setup is flexible enough to support that when the time comes. Ultimately, a debug window will act as our lens into the runtime: inspecting node states, variable values, and control flow.

References

Procedural vs Dataflow context in Divooka on the Methodox Wiki.
Blueprint debugging in Unreal
Procedural debugging documentation on Methodox Wiki.

DevLog 20250706: Speech to Text Transcription using OpenAI Whisper

Mon, 07 Jul 2025 02:08:17 +0000

Overview

Mobile phones have had audio input for a long time, but none of the default options are particularly satisfactory. And despite the rise of capable online AI-based transcription services, for very simple scenarios like "turn this recording into some text," there's still no easy tool.

OpenAI released Whisper in 2022, a powerful model capable of transcribing many languages - but even now, there's no straightforward way to use it without invoking the API directly.

The API

Under the hood, Whisper is a deep neural network trained end-to-end to map raw audio to text. Conceptually, you:

Provide an audio input - the model analyzes the waveform to extract linguistic and acoustic features.
Leverage learned representations - its multi-layer architecture handles background noise, varied accents, and low-quality recordings.
Produce a transcription - Whisper outputs a sequence of text that you can display, store, or post-process.

This high-level interaction keeps things simple: feed in speech, get back text - no need to manage model internals or low-level signal processing.

The Utility

Today I'm sharing our free Transcriber tool, which I've been using for almost half a year. It does a solid job at what it's meant to do:
https://methodox.itch.io/transcriber

We likely won't have time to develop it further, but sharing it online makes it more accessible for others looking for a similar solution.

Challenges

Currently, there's a limit on audio length due to OpenAI API restrictions. It would also be ideal to add real-time transcription - something like Google Voice IME.

References

Utility download: Transcriber

DevLog 20250706: Analyzing (C#) Project Dependencies

Sun, 06 Jul 2025 19:26:37 +0000

When a code project grows complex it's going to be difficult to understand which depends on which - developers familiar with the C# ecosystem can look at NuGet Package Manager and use .csproj to try to study things but when the hierarchy gets complex it can feel inconvenient.

For instance, say I have a top-level entry program that I know ultimately depends on Mathnet.Numerics - now I need to figure out which subproject references it.

The General Approach

To view which project depend on which package in C#, below are some approaches using existing tools.

1. Using the .NET CLI

This approach only shows the NuGet packages the projects depend on.

a) List packages per project

Run, for each project:

dotnet list path/to/MyProject.csproj package

We'll get an "Installed" section showing direct references.

b) Include transitive dependencies

dotnet list path/to/MyProject.csproj package --include-transitive

This will also show packages pulled in by other packages.

c) Script it for the entire solution

On bash (Linux/macOS/git-bash):

for proj in $(find . -name '*.csproj'); do
  echo "== $proj =="  
  dotnet list "$proj" package --include-transitive | grep MathNet.Numerics -B2 -A2
done

On PowerShell (Windows):

Get-ChildItem -Recurse -Filter *.csproj |
  ForEach-Object {
    Write-Host "== $($_.FullName) =="
    dotnet list $_.FullName package --include-transitive |
      Select-String "MathNet.Numerics" -Context 2,2
  }

2. Grep / Select-String on `.csproj` files

Since NuGet package references live in <PackageReference> items, we can search directly:

bash:

grep -R "PackageReference.*MathNet\.Numerics" -n .

PowerShell:

Get-ChildItem -Path . -Filter *.csproj -Recurse | Select-String -Pattern 'MathNet\.Numerics' -List
  
# Or
Get-ChildItem -Recurse -Filter *.csproj | Select-String -SimpleMatch 'MathNet.Numerics' -List

That will show us exactly which project files reference it.

Alternatively, just do a full text search in VS Code with file type filter.

3. Visual Studio / Rider UI

Right-click on the Solution → Manage NuGet Packages for Solution…
Go to the Installed tab, find MathNet.Numerics in the left panel.
On the right, we'll see checkboxes or project-scoped lists showing which projects have it installed.

Once again, this method doesn't show the complete picture or the hierarchy of dependencies.

4. MSBuild Dependency Graph (advanced)

If we need to audit transitive and project-to-project dependencies in one go, we can generate a restore graph:

dotnet msbuild /t:GenerateRestoreGraphFile /p:RestoreGraphOutputPath=graph.dg

This produce a fairly comprehensive output that contains absolute paths and a bit too much irrelevant information.

Then inspect graph.dg (JSON) for entries where "PackageId":"MathNet.Numerics" and note the "ProjectPath" fields.

Custom Tool

Above methods work but if you don't like the output format, CLI syntax, or just want something more straightforward - then it's time for a custom tool.

The C# Dependency Analyzer is a tool that can quickly help identify dependencies of a source code project. This is useful in identifying unwanted nuget dependencies from any given entry assembly. It is equivalent to manually searching through .csproj to find which projects depend on which and debug NuGet dependencies.

It can do those three things:

Print an exhaustive dependency tree with a root node at each source project level down to all dependent projects and most importantly the root NuGets
Given a single target project/nuget, prints a filtered tree of all projects that depend on that assembly
Given a single target project/nuget and a source assembly, it prints the tree paths that lead from the source assembly to the target - showing clearly the path from the source assembly to the ultimate dependency.

Below is an example output with command: path --path <solution path> --source Transcriber --target SkiaSharp

References

Methodox Dependency analyzer: visit Github

Data-Driven Design: Leveraging Lessons from Game Development in Everyday Software

Tue, 24 Jun 2025 22:18:04 +0000

Overview

Modern software often needs to adapt quickly - whether that means processing new data sets, adjusting to user preferences, or deploying new features safely without downtime. To achieve such flexibility, software engineers increasingly adopt a methodology known as Data-Driven Design (DDD).

Originally popularized by game development, Data-Driven Design emerged prominently in the 1990s as large studios confronted a challenging problem: the need to iterate rapidly on complex and interactive content. Game developers realized it was costly and slow to rebuild and redeploy an entire game every time designers wanted to tweak gameplay mechanics, adjust character behaviors, or revise in-game dialogues.

Jason Gregory's influential book Game Engine Architecture highlighted how AAA games effectively tackled this challenge by externalizing game logic into structured data files. Instead of embedding behaviors directly in C++ code, developers loaded data such as AI rules, game levels, item descriptions, and story dialogues from easily editable files like YAML, JSON, or custom formats. This dramatically accelerated iteration, empowering non-programmers - artists, designers, and writers - to directly experiment and refine experiences without requiring code recompilation or redeployment.

Although originally rooted in game development, Data-Driven Design has proven invaluable across software domains, ranging from web development, data analytics, and DevOps automation to no-code and low-code platforms. The fundamental principle remains the same: separate generic engines from domain-specific data.

The Core Idea Behind Data-Driven Design

Before we dive deeper, let's provide a clear working definition that illustrates why Data-Driven Design is relevant to developers and system administrators today:

Data-Driven Design means that the software's behavior is governed by external data rather than hard-coded logic. The code provides generic mechanisms for processing that data, but the specifics of “what to do” or “how to behave” live in data files (such as YAML, JSON, or databases) that can be changed independently from the source code itself.

To clarify further, here's a quick comparison:

Pattern	What drives behavior?	Practical Example
Hard-coded	Embedded conditional statements in code	`if user.is_premium: enable_feature()`
Config-driven	Simple flags or settings in config files	`max_connections = 10` in `config.ini`
Data-driven	Entire behaviors defined in structured data (YAML, JSON, SQLite)	YAML defining a workflow or SQLite storing business rules

Below are some common misconceptions and anti-patterns to help clarity things:

"It's just a config file." – If removing the file breaks the program, it's not mere config; it's content that defines runtime behaviour.
"DDD = No code." – Wrong: the goal is to keep the engine generic and thin, but domain logic still has to live somewhere (often in a domain-specific language interpreted by the engine).
Premature complexity – Don't invent a custom DSL when a handful of YAML documents plus a small interpreter class will do.
Debugging blind – Always log "which data row caused this action?" so you can trace bugs quickly.

High-Level Architecture Overview

A typical Data-Driven Design architecture clearly separates:

Authoring Layer
- Human-readable formats like YAML or JSON.
- Editable directly by users or via automated processes.
Validation & Build Layer
- Schema definitions or migrations that ensure data consistency.
Runtime Loader & Hot Reload
- Reads and validates data at runtime.
- Supports hot-reload for rapid iterations.
Generic Runtime System
- Executes logic based purely on loaded data.

This creates a robust pipeline where data edits alone trigger different application behaviors.

Data Files (YAML/SQLite)
    │ load & validate
    ▼
Generic Runtime Engine
    │ executes behaviors based on data
    ▼
Dynamic Behavior in Application

Choosing Your Data Container

Here's a quick guide to choosing your data format based on needs:

Format	Advantages	Typical Use Case
YAML/JSON/TOML	Human-readable, simple to version control	Small-to-medium complexity workflows, configs
SQLite	Relational queries, consistency, single file	Complex rule sets, relational data, analytics
Binary Formats	Performance-critical loading	Embedded systems, high-performance scenarios

Typically, you start with YAML or JSON, then upgrade to SQLite as complexity grows.

Practical Example: Data-Driven Workflows with Divooka

Divooka is the visual programming language that naturally embodies Data-Driven Design principles through its composable dataflow nodes. Let's illustrate this clearly with a straightforward example:

Scenario:

A data analyst wants to build an automated workflow to:

Load a CSV file containing customer orders.
Filter orders exceeding a certain threshold.
Send a summary via a web API.

In Divooka, the process is streamlined as follows:

1. Load Data with Path and File Nodes

Path node specifies file location (e.g., /data/orders.csv).
Load from CSV file read node directly loads CSV data into a structured DataGrid.

[Path Node] "/data/orders.csv"
    │
    └─► [Load from CSV Node]
           │
           └─► DataGrid

Equivalent Python-like pseudocode:

orders_df = pd.read_csv("/data/orders.csv")

2. Filtering Data

Filter node takes the DataGrid and filters based on condition (e.g., order_total > 100).

DataGrid
    │
    └─► [Filter Node] condition: order_total > 100
           │
           └─► Filtered DataGrid

Equivalent pseudocode:

high_value_orders = orders_df[orders_df["order_total"] > 100]

3. Sending Data via HTTP API

String node specifies the webhook URI.
HTTP Send Request node sends the filtered data automatically serialized as JSON.

[String Node] "https://hooks.example.com/orders"
    │
    └─► [Send Request Node] method: POST, body: Filtered DataGrid

Equivalent pseudocode:

import requests
payload = high_value_orders.to_dict(orient='records')
requests.post("https://hooks.example.com/orders", json=payload)

Why Divooka Is Naturally Data-Driven:

High-level abstraction nodes (Path, String, File I/O, Web Request) handle data transparently.
Nodes clearly define dependencies and flow, automatically adjusting behavior when input data changes.
Entire workflows can be modified without touching underlying engine code or restarting the runtime environment.

Best Practices and Pitfalls

When embracing Data-Driven Design, keep the following in mind:

Practice	Recommendation
Schema Validation	Always enforce schemas (e.g., JSON Schema or SQLite migrations) to prevent errors
Hot Reloading	Clearly separate parsing from data activation steps
Security Considerations	Never trust external data implicitly; always validate or sanitize it before use
Performance Optimization	Cache loaded data where appropriate to avoid redundant parsing

Try It Yourself: Starter Projects

To practice Data-Driven Design, consider these beginner-friendly projects:

Feature Flag Dashboard: YAML-based flags control feature visibility.
Email Routing Automation: SQLite stores routing rules to sort incoming emails.
Procedural Content Generator: YAML files configure parameters for generated data outputs.

Each project reinforces that your engine stays generic and data explicitly drives all behaviors.

Conclusion

Data-Driven Design originated as a powerful solution to rapid iteration in the game development world, enabling large teams to build and adjust complex software efficiently. Today, its principles transcend industries, benefiting system administrators, data analysts, web developers, and more.

In tools like Divooka, Data-Driven Design emerges naturally - dataflow-based nodes inherently separate behavior from implementation, ensuring flexibility and robustness. By clearly distinguishing between generic program logic and externally-driven data, you create maintainable, adaptable, and resilient software.

References

Wikipedia on Data-driven programming - not to be confused with Data-oriented design.
Jason Gregory's book on Game Engine Architecture (table of contents).
Richard Fabian's book on Data-Oriented Design (online version).

SQLite - High-Level Introduction

Tue, 24 Jun 2025 15:27:25 +0000

SQLite

SQLite is a self-contained, serverless, zero-configuration relational database engine. Unlike traditional database servers, SQLite is distributed as a simple library that you embed directly into your applications. This guide will introduce you to SQLite's core concepts, explain why it's such a popular choice for developers, highlight how it differs from other database systems, and show how you can leverage it inside Divooka's visual programming environment.

Why SQLite?

For many new programmers, setting up a client–server database (e.g., MySQL, PostgreSQL) can feel like learning two things at once: programming and system administration. SQLite removes that overhead:

Zero-configuration
No daemon to install or manage - your application just opens a file.
Lightweight and portable
Entire database lives in a single cross-platform file (often just a few hundred kilobytes of library code).
Broad language support
Bindings exist for Python, JavaScript, C#, Java, Go, Rust, and more - so you can start querying data in the language you already know.

Because of its simplicity, SQLite is the most widely deployed database engine in the world, powering everything from mobile apps and desktop software to IoT devices and web browsers.

Core Architecture

File-Based Storage

Single file: Definitions, tables, indexes, and data all live in one .db (or .sqlite3) file.
Cross-platform: You can copy the database file between Windows, macOS, Linux, and mobile devices without conversion.

The file-based nature of SQLite makes it super easy to backup and migrate databases.

Serverless and Embedded

Library, not a server: Applications link against libsqlite3 and call C-APIs (or higher-level wrappers) directly - there's no separate "database process."
Reduced latency: Reads and writes happen in-process, avoiding inter-process communication overhead found in client–server setups.

Dynamic Typing ("Manifest Typing")

Types on values, not columns: Columns have "type affinities" (e.g., INTEGER, TEXT), but SQLite won't reject a string inserted into an INTEGER column - it will try to convert it.
Optional strict mode: As of recent versions, you can declare CREATE TABLE ... STRICT to enforce traditional SQL type checking if you need it.

Concurrency Model

Reader–writer locks: Multiple readers can operate simultaneously, but writes acquire an exclusive lock on the file.
Write-Ahead Logging (WAL): Enables concurrent reads and writes by appending changes to a separate log, improving throughput for mixed workloads.

Key Differences from Other Databases

Aspect	SQLite	Client–Server Databases
Deployment	Embed a library; open a local file	Install/maintain a separate server
Configuration	Zero-config; managed by file system	Requires user accounts, ports, etc.
Process architecture	In-process library calls	Inter-process with network protocol
Typing	Dynamic, manifest typing	Static, enforced column types
Concurrency	Serialized writes (with WAL option)	True concurrent writes via server
Backup	Copy the file or use online backup APIs	Use dump utilities or replication

Practical Use Cases

Desktop and Mobile Apps
Store user settings, preferences, and offline data without bundling a full database server.
Embedded and IoT Devices
Firmware and edge-computing modules often rely on SQLite for local data persistence, thanks to its tiny footprint.
Prototyping and Testing
Quickly spin up a relational store for experiments and unit tests - no setup scripts needed.
High-Availability Reads
Applications that require many concurrent read operations (e.g., analytics dashboards) benefit from SQLite's low-latency access.
File-Based Data Interchange
Sharing a .db file between teams or tools (e.g., GIS software, data science notebooks) is as simple as sharing a CSV.

SQLite in Divooka

In Divooka's visual programming language, SQLite plays two roles:

In-Memory Data Engine: Run queries against data you're manipulating on the canvas - think temporary tables without disk I/O.
Persistent Storage: Divooka Explore ships with SQLite pre-installed, so you can save and load your data without any extra configuration - just specifying a filepath for the database and you are good to go.
Simple Web Interface: The O'ista web framework offers a capability for you to host SQLite online with authentication, so the database can be accessed by others.

This integration means you can drag a "SQL Query" node onto your workflow, point it at either an in-memory dataset or a saved .db file, and immediately start filtering, aggregating, and joining tables - all within Divooka's visual interface.

Getting Started

Open/Create a database

-- In the sqlite3 shell:
.open my_project.db

Create tables

CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  joined DATE
);

Insert sample data

INSERT INTO users (name, joined)
VALUES ('Alice', '2025-06-01'),
       ('Bob',   '2025-06-15');

Run a query

SELECT id, name
FROM users
WHERE joined >= '2025-06-10';

In Divooka Explore, these same SQL snippets can be entered into a SQL query block node, letting you mix SQL with visual data flows.

Conclusion

SQLite offers a frictionless path for beginners to learn SQL and build data-driven applications, while still providing advanced features like ACID transactions, full-text search, and JSON support for more experienced developers. Its unique combination of simplicity, portability, and performance makes it an ideal companion for both standalone projects and integrations inside environments like Divooka. Whether you're just exploring databases for the first time or architecting an embedded system, SQLite is a tool that scales with your needs - no server required.

References

Computing in the Financial Sector: An Ideal Scenario

Fri, 20 Jun 2025 22:43:14 +0000

Technical debt is like refusing to fix a leaking roof because it's raining - only to forget about it when the sun comes out.

In this article, I'd like to share some thoughts on computing in professional environments, especially from an engineering perspective. These are based on over 18 years of experience in software and insights gathered from three years of observing workflows and speaking with veterans across industries - financial services, banking, retail, and engineering alike.

The financial industry is used here as an example - not because it is uniquely flawed, but because it is highly relatable and emblematic of issues in many complex corporate environments. The emphasis here is on computing infrastructure, though the discussion touches on organizational and human factors, which are often inseparable in real-world implementations.

As an engineer, I strive for system coherence and comprehensibility. Complexity is natural and even necessary. Complication, however, is a human failure - and preventable. This piece is not about client-facing technologies, but about the internal systems, processes, and philosophies that make a corporation function, scale, and evolve.

Summary

This article is long, so here's the TL;DR:

Avoid most commercial cloud services unless absolutely necessary.
Minimize hierarchies.
Use Azure DevOps (ADO) for task management (there is no equivalent that offers the same integration).
Provide scriptable, reusable interfaces for historical analysis and reporting (e.g., Grafana, TradeView).
Use SQL (raw or wrapped) throughout your stack for ETL.
Avoid PowerBI for anything mission-critical.
Never use Excel in production.
Invest in tailored tools for core business functions (e.g., custom accounting platforms over QuickBooks).
Consider interactive simulations or serious games for training.
Design your enterprise as API-first, not "AI-first" (AI-first is often just a buzzword).
Prefer locally deployed AI models, ideally under your control.
Underpinning all of this is a core belief: existing practices are broken, and a new paradigm is needed.

While Divooka (our own platform) embodies this philosophy, this is not an advertisement. Any platform that addresses the same core issues is welcome - though in years of searching, I've yet to find one that does.

Motivation

For both individuals and teams, the drive for faster workflows and better tools is ultimately about insight. In complex business environments, speed enables iteration, and iteration enables clarity. This is just as true for corporations as it is for individuals. But iteration only works if tools are adaptable.

Hence, the efficiency of problem-solving is directly tied to the efficiency of developing custom internal tools.

For large institutions - national pension funds, tier-one banks, or multi-national insurance firms - this goes beyond tooling. You need:

Layered access control
High-frequency analysis
Security
Training pathways for new hires (e.g., interns)

More importantly, data accessibility - real-time, API-based, version-controlled - is what drives real analytical agility. Security is not just a technical problem - it is a cultural and process problem.

Top-down visibility is also essential. Leadership should be able to trace any issue through systems with a single click. If they can't, the system has failed - not because of complexity, but because of poor design.

And while executives don't need to understand every implementation detail, they must understand the principles - and more critically, invest in education both for themselves and for entry-level employees. A longer-term view builds resilience, retains talent, and enables innovation.

Making the Best of Existing Tools

Cloud computing has made off-the-shelf infrastructure appealing - but this convenience comes at a cost. Over time, the lack of control becomes a liability, especially at scale. High-performing organizations must eventually invest in internal capabilities.

It is always cheaper in the long run to take matters into your own hands - if you can attract and retain technical talent.

Additionally, code review must be mandatory for anything related to automation - whether for internal dashboards, accounting tools, or production pipelines. Not just for QA, but for education and sustainability.

In software development cycles, a healthy time division might look like this:

1.5x Analysis/Modeling
1x Development
0.5x Code Review
0.5x QA

Financial organizations should also standardize on microservices to simplify endpoint access and reduce cross-system coupling.

For any company that uses the word "agile" unironically: Azure DevOps (ADO) remains the gold standard for work item tracking, integrated version control, testing, and pipeline automation.

A critical warning: Beware the proliferation of internal dashboards. While it may seem counterintuitive, the tendency to build highly visual dashboards is a distraction from what matters - reliable APIs, scalable infrastructure, and actual automation.

"API-first" saves 80% of the effort in the long term compared to building UI-first.

The Peer Developer Model

Financial analysts are de facto computing professionals. Any work at scale is computational. And yet, most organizations underinvest in bridging the gap between analysis and implementation.

There are two solutions:

Invest in training analysts to code (bite-sized, structured, mandatory).
Assign companion developers - dedicated engineers working side-by-side with analysts.

This is similar to how civil engineers complement architects. The developer's role: implement, optimize, and review code, leaving analysts free to model and interpret.

A junior-to-mid-level OOP developer (familiar with C-family languages) costs \~\$100K and can support 2–3 analysts effectively. This model reduces headcount while increasing productivity.

The Integrated Big Picture

Eliminating redundant tech stacks is the single most powerful way to reduce technical debt. In most organizations, essential functions are scattered across dozens of tools, each requiring specialized training.

The solution is to build reusable internal libraries, APIs, and tooling ecosystems around key functions (data ingestion, transformation, reporting, access control). And yes, this requires investment - but for a firm managing billions, it's well worth it.

Open-source solutions often provide better APIs and lower long-term cost. But the goal isn't cost reduction per se - it's control, efficiency, and resilience. Cost savings will follow.

The All-Rounded Technical Analyst Model

Divooka is our vision for what this looks like in practice: a unified computing platform combining:

Enterprise-grade C#
SQL-dominant ETL pipelines
Python's rich data science ecosystem
A modular, plugin-based architecture
Low-code/no-code visual programming
Fully local, one-click deployment

The result: self-contained, auditable, maintainable pipelines that cover 90%+ of analytical needs, with fewer components and shallower learning curves.

This abstraction allows analysts to become full-stack operators - no longer needing to juggle five tools for one task.

The winning stack: C# + Divooka + Python + PostgreSQL + ADO + GitHub + microservices.

These toolsets raise natural questions about hiring and training:

What kind of analysts should we hire?
How fast can we get them productive?

From an engineering standpoint, we want people with structured programming experience - even in entry-level roles. No one flies a plane without a license; why run production data systems without proper coding fundamentals?

Traditional programming bootcamps won't suffice. But a modern analyst can get up to speed in 3 months - if trained with the right curriculum: Excel + SQL + Divooka (Yes, Excel is still needed for practical reasons). That's all you need for 80% of the analytical workload.

Conclusion

This article outlines an ideal - but attainable - vision for computing in complex industries.

These problems can be solved with or without technology. But solving them well requires the right mindset, structure, and investment. Every organization has unique needs, and solutions should be iterative, adaptive, and people-centered.

If any part of this resonates with your experience, I'd be happy to continue the conversation.

Changelog

20250509 Rev 001: Initial draft.
20250520 Rev 002: Refine ideas.
20250609 Rev 003: Adjust wording and refine ideas, staging for publication.
20250620 Rev 004: Polishing.

[Review] 20250620: The Plan to Supersede Excel

Fri, 20 Jun 2025 13:50:46 +0000

Soon enough, Divooka is almost here. Let's go back to the problem that got us started: practical data analytics at scale.

We're not trying to completely replace Excel. Excel serves its purposes extremely well, and we envision a world where tools are more specialized depending on the needs. On the other hand, many of the problems Divooka aims to solve - particularly in data analytics - stem from overuse or misuse of Excel in situations it was never designed for. That's why Excel naturally becomes a benchmark for evaluating how well Divooka addresses these challenges - and in turn, how effectively Divooka can substitute for Excel in those contexts.

In general, the future we're building toward is one where people only use Excel occasionally - for working with legacy systems or exchanging files with external clients. For all other practical, internal, and repeatable analytical tasks, organizations and individuals shouldn't have to open Excel at all. That's the vision for Divooka in the data analytics space.

P.S. If you're wondering why we compare ourselves to Excel when talking about "data analytics" rather than Python - it's because we're focusing on where actual work gets done by everyday professionals in finance, retail, consulting, etc. - outside of data scientists and machine learning engineers, who typically work within well-defined infrastructures or theoretical environments.

Overview

Excel offers the following main functionalities and use cases:

Using worksheets/workbooks as informal databases – enabling data entry, filtering, etc.
Applying formulas for analytics – calculating sums, performing aggregates, lookups.
Plotting and reporting – generating charts and formatted reports.
Automating results and, to some extent, content – via templates for repeated use.

A Note on Learning

Some claim Excel is easier to learn than Python or Divooka. In our experience, that perception usually comes from people who've been using Excel for 10+ years. That certainly wasn't my experience when I first tried to learn it - by then, I was already an experienced programmer.

Excel has a lot of quirks. Fortunately, it also has a wealth of online resources - forums, tutorials, and StackOverflow answers - that help users troubleshoot specific needs quickly. But that doesn't necessarily make it easier to learn.

Meanwhile, its automation and extension system (VBA, VSTO) and DOM model are far from elegant. They can be powerful - but they're also idiosyncratic, outdated, and hard to scale or maintain.

Identifying Veteran Use

For veteran users - those who've worked in finance, consulting, banking, or retail for over a decade - it's crucial to identify what matters most to them so we don't waste time trying to rebuild everything from scratch.

For these professionals, usually in management roles, key priorities tend to be:

Simple data entry
Basic formulas (especially VLOOKUP and IF logic) and pivot tables
Minimal plotting
Extensive styling, including conditional formatting

Veterans rarely write VBA or build complex automated spreadsheets themselves - that's what interns and junior staff are usually tasked with.

The Solution Plan

Divooka already outperforms Excel in areas like analytics and automation (points 3 and 4), but matching Excel's GUI experience for basic data entry and formulas remains a challenge.

The Challenges

The problem can be broken down into two fronts:

We must provide a familiar interface and usage pattern - even though Divooka is not Excel - to reduce resistance from long-time Excel users.
Divooka is a visual programming language with its own design principles. While we want to be similar to Excel where needed, we must stay true to what makes Divooka powerful and unique.

The Approaches

To address the GUI/database usage pattern, we're exploring a few possible approaches:

Create a custom visual node that replicates the structure of a standard Excel worksheet - though it might look more like a clean, modern take similar to Apple Numbers.
Encourage users to adopt API-driven or externalized databases and foster a mindset of separating data, computation, and presentation. While we offer SQL and database API integration out of the box, we also recognize that many users resist this - even if they're already managing convoluted Excel formulas.
On that note, there are two directions we're exploring:
- Provide a visual interface (like MySQL Workbench) for common database operations.
- Offer a high-level, node-based API that avoids manual SQL writing, while gently encouraging users to become more familiar with what's happening under the hood.

A Combined Use Case

The most common (and most problematic) Excel use case is when people combine:

Data entry,
Basic automated calculations,
Fancy styling,
Plots and form updates for reporting purposes.

This is where Excel shines - and also where it often gets abused. It enables incredibly compact and self-contained workflows: enter numbers, add formulas, apply some styling - and voilà, you have a polished report.

But this convenience comes at a cost: poor scalability, maintainability issues, and a lack of clear separation of concerns. A single cell can simultaneously serve as a data source, a computed result, and a styled report element. This makes downstream changes, automation, and collaboration extremely hard.

The traditional software engineering solution is seen in the web: HTML (structure), CSS (style), and JavaScript (logic). By clearly separating concerns, we maintain flexibility and clarity. So what if creating an HTML/CSS/JS-based dashboard was as easy as building an Excel sheet? That's one possible angle - and something Divooka could eventually support through node APIs or higher-level content editors.

But that's not the most elegant path forward.

The Real Solution

The better question to ask is: what is the actual end goal?

People want to build interactive dashboards or reports that auto-update, look professional, and live within a single workspace where they can easily edit data, adjust formulas, and customize visuals - all while staying clean and maintainable.

Wait a second - doesn't that sound like App Mode in Neo?

(Screenshot coming soon when the time is right.)

Conclusion

Divooka was never about "replacing Excel" outright. That was never the goal - and still isn't. What we set out to solve was broader and deeper: making practical, scalable data analytics accessible to professionals who are otherwise stuck with brittle, overextended workflows. Excel simply happens to be the dominant tool in that space, so it naturally became both our benchmark and our foil.

In a sense, replacing Python is an easier problem - just design a better language, with better libraries and ecosystem. Julia is doing that, so are many others. When we started tackling "The Excel Problem," it felt vague and enormous. We only had instincts: "There must be a better way," and "Visual programming, like Divooka, seems right." Back then, we didn't yet see the full shape of the solution.

But as Divooka matures, as our libraries evolve, and as our design principles solidify, the picture becomes clearer.

It's becoming evident that:

Data entry can be streamlined through a combination of high-level APIs and dedicated GUIs.
Dedicated graphical editors are not just useful - they're the future. We'll share more on this next year.
Divooka's graph-based mindset is not only powerful but practical. Neo will serve as the reference implementation and the litmus test for what a modern visual programming platform can achieve.

Of course, there are still many UX and ergonomics problems to solve - and we must proceed with care.

But we're getting close.

Resources

App Mode

Topic 20250618: Procedural Context is More Learning (and Syntax) to Users

Wed, 18 Jun 2025 17:44:27 +0000

Overview

When people first open Divooka, they see a network of interconnected nodes where connections represent data flow.

Even someone who has never seen visual programming or Divooka before can read the titles of the nodes and input parameters and have a pretty good guess at what the program does.

Thus, a key to using Divooka (in the dataflow context) efficiently is understanding the execution runtime - what nodes are active, what the dependency tree is, and how caching works.

As someone who has been using Unreal Engine Blueprint since 2014, the concept of "execution flow" appears natural to me - but when showing this to new users, it became evident that it takes time to tune in and learn to read the diagrams.

We'll take a look at what procedural context is, then briefly analyze why that's the case.

The Procedural Constructs

The procedural context in Divooka provides many constructs that may be familiar to those from traditional programming languages.

An example is shown below:

Common Constructs

Conditional logic is done using the Branch node.

Loops are implemented using the Repeat node.

Iteration is done using the For Each node.

Functions are handled using the Execute Event and Custom Event nodes.

A switch-case structure is implemented using the Switch node.

(Pending image)

Unique Constructs

In addition, Divooka also offers constructs that are unique to it:

Sequence nodes are used to define multiple sequential steps.

Events are entry points defined by the framework (procedural context base type).

Implementation Note

Certain constructs are currently missing:

Break: to exit a loop prematurely.

Caveats of States

What's more, in procedural context there is the possibility of manipulating state - for example, incrementing a number to be used next time.

Thus, to use the procedural context effectively, users need to learn a good amount of "syntax": control flow, state handling, and more.

The Two Contexts

Given that all of the top 10 most popular programming languages support imperative/procedural programming as the default mode, one might expect this to be the most straightforward paradigm. In reality, that's not the case.

Use the dataflow context for data-centric operations, such as data transformations.

Use the procedural context for logic-centric operations, such as branching and conditional executions.

Unlike procedural context, when using dataflow context, users need to learn only a single syntax: connections represent data flows, and everything (almost) always executes - depending on node activation status. To follow the flow of a program is simply to follow the connections - there's no concern about branches or alternate execution paths.

Conclusion

The procedural context is more complex for several reasons:

Connections now represent both data and execution flow
Some nodes can interrupt, diverge from, or selectively execute downstream connections - requiring users to understand exact behaviors to make accurate predictions
There are many types of flow control nodes, each requiring learning
State is involved

Part of the reason Divooka started with the dataflow context was exactly to reduce this complexity. However, as programs become more complicated and procedural logic becomes involved, it's not possible to avoid procedural context - in fact, having it is often more convenient than not.

Users must make informed decisions about what to put into procedural context and what to offload to dataflow context.

References

DevLog 20250613: Ol'ista Web Framework

Fri, 13 Jun 2025 20:42:59 +0000

Overview

For web app development, we need a framework for Divooka. To approach this problem, we study existing frameworks in existing languages.

API Style Survey

If we look at any existing web server API, like ASP.Net Core below:

using Microsoft.Extensions.FileProviders;

var builder = WebApplication.CreateBuilder(args);
var app     = builder.Build();

// Serve default files like index.html
app.UseDefaultFiles();
// Serve static files from wwwroot/
app.UseStaticFiles();

app.Run();

or Flask:

from flask import Flask

app = Flask(
    __name__,
    static_folder='static',      # default
    static_url_path=''           # serve at root instead of '/static'
)

@app.route('/')
def index():
    # Sends static/index.html
    return app.send_static_file('index.html')

if __name__ == '__main__':
    app.run(debug=True)

or NodeJS:

// server.js
import { createServer } from 'http';
import { createReadStream, statSync } from 'fs';
import { extname, join } from 'path';

const PUBLIC_DIR = join(process.cwd(), 'public');

createServer((req, res) => {
  // Map URL → file path
  const urlPath = req.url === '/' ? '/index.html' : req.url;
  const filePath = join(PUBLIC_DIR, urlPath);

  try {
    const stats = statSync(filePath);
    if (stats.isFile()) {
      const stream = createReadStream(filePath);
      // Minimal mime-type handling:
      const ext = extname(filePath).slice(1);
      res.setHeader('Content-Type', {
        html: 'text/html',
        js:   'application/javascript',
        css:  'text/css',
        png:  'image/png',
        jpg:  'image/jpeg',
      }[ext] || 'application/octet-stream');
      stream.pipe(res);
      return;
    }
  } catch {
    // fall through to 404
  }

  res.statusCode = 404;
  res.end('Not found');
}).listen(3000, () => console.log('Listening on http://localhost:3000'));

With Express.js:

// app.js
import express from 'express';
const app = express();

// Serve index.html automatically at '/'
app.use(express.static('public'));

// (Optional) Serve another folder at /assets
app.use('/assets', express.static('PublicAssets'));

app.listen(3000, () => {
  console.log('Static server running on http://localhost:3000');
});

There are some common features:

We define what the server does
We provide some "endpoints"
And we let the server run wild

There is an obvious data-driven pattern. Now, if you have followed Divooka's development, or have seen a few use cases of the Dataflow context (e.g. with plotting), it would immediately appear to you: wow, we should be able to do this trivially in Divooka!

Indeed it is!

Ol'ista - The Divooka Way

Ol'ista (codename Oista) is Divooka Explore's builtin web framework.

A web server is configured using capabilities, those include: static file hosting, FTP server, web API, etc.

Serve Static Files

Create FTP Server

Serve Web API

Standard Components

For most common things that almost all web frameworks provide, Ol'ista provides it through the Static File Capability and Web API Capability. Configuration is done through succession of compositional APIs:

You can serve many capabilities at once:

Dynamic Behaviors

Dynamic behaviors or what's typically understood as web APIs are served through Web API Capability, and Divooka enables it through function references:

Server Side

Full Setup (Server and Client)

Result on Client

Dynamic Webpages

Most web frameworks offers some kind of template language for easier generated HTML contents.

ASP .NET Core (Razor)

Views/Shared/_Layout.cshtml

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>@ViewData["Title"] – MyApp</title>
</head>
<body>
    <header>
        @await Html.PartialAsync("_Nav")
    </header>

    <main role="main">
        @RenderBody()
    </main>

    <footer>
        @RenderSection("Scripts", required: false)
    </footer>
</body>
</html>

Views/Home/Index.cshtml

@{
    ViewData["Title"] = "Home";
    var items = new[] { "Apple", "Banana", "Cherry" };
}
<h1>Hello, @User.Identity.Name!</h1>

<ul>
@foreach (var item in items)
{
    <li>@item</li>
}
</ul>

@section Scripts {
    <script>console.log("Page loaded");</script>
}

Python Flask (Jinja2)

templates/base.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>{% block title %}MyApp{% endblock %}</title>
</head>
<body>
    <header>
      {% include "nav.html" %}
    </header>

    <main>
      {% block content %}{% endblock %}
    </main>

    <footer>
      {% block scripts %}{% endblock %}
    </footer>
</body>
</html>

templates/index.html

{% extends "base.html" %}

{% block title %}Home – MyApp{% endblock %}

{% block content %}
  <h1>Hello, {{ current_user.name }}!</h1>
  <ul>
    {% for fruit in ["Apple","Banana","Cherry"] %}
      <li>{{ fruit }}</li>
    {% endfor %}
  </ul>
{% endblock %}

{% block scripts %}
  <script>console.log("Page loaded");</script>
{% endblock %}

Ruby on Rails (ERB)

app/views/layouts/application.html.erb

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title><%= content_for?(:title) ? yield(:title) : "MyApp" %></title>
</head>
<body>
  <header>
    <%= render "nav" %>
  </header>

  <main>
    <%= yield %>
  </main>

  <footer>
    <%= yield :scripts if content_for?(:scripts) %>
  </footer>
</body>
</html>

app/views/home/index.html.erb

<% content_for :title, "Home – MyApp" %>

<h1>Hello, <%= current_user.name %>!</h1>

<ul>
  <% ["Apple","Banana","Cherry"].each do |fruit| %>
    <li><%= fruit %></li>
  <% end %>
</ul>

<% content_for :scripts do %>
  <script>console.log("Page loaded");</script>
<% end %>

Among those, ASP.Net Core and Ruby on Rails appear cleaner.

Comparison

Feature	ASP .NET Core (Razor)	Python Flask (Jinja2)	Ruby on Rails (ERB)
File extension	`.cshtml`	`.html` (or `.jinja2`)	`.html.erb`
Expression delimiter	`@Model.Property` or `@(...)`	`{{ variable }}`	`<%= @variable %>`
Statement delimiter	`@{ ... }`, `@if(...) { ... }`	`{% ... %}`	`<% ... %>`
Partial/templates include	`@await Html.PartialAsync("_Nav")`	`{% include "nav.html" %}`	`<%= render "nav" %>`

For Divooka, as a start, I plan to implement something I call Markit - a simple string replacement. This awaits further work and will be updated on Ol'ista's wiki.

References

The Ol'ista framework for Divooka
Full setup walkthrough for the example.

DevLog 20250611: Audio API Design for Divooka Glaze!

Wed, 11 Jun 2025 18:14:04 +0000

Glaze! is an interactive media framework in Divooka that features a Processing-like interface.

Overview

Today, I'm laying the groundwork for audio APIs for our Glaze! framework.

Divooka Glaze! draws inspiration from SFML and Processing, so we need to understand how those two handle audio first.

How SFML Handles It (SFML.Net)

To play audio in SFML.Net, we use the SFML.Audio module, which provides two main classes:

Sound + SoundBuffer for short, fully-loaded sounds (like sound effects).
Music for long, streamed audio (like background music).

Playing Short Sounds

Short audio files (WAV, OGG, FLAC, etc.) can be fully loaded into memory:

// Load the entire file into a buffer (only do this once per sound).
SoundBuffer buffer = new SoundBuffer("hit.wav");

// Create a Sound instance and assign the buffer.
Sound hitSound = new Sound(buffer);

// Optional settings
hitSound.Volume = 75f;    // 0–100
hitSound.Pitch  = 1.2f;   // playback speed
hitSound.Loop   = false;  // play once

// Play it
hitSound.Play();

// Make sure the program doesn't exit immediately,
// otherwise the sound will be cut off:
while (hitSound.Status == SoundStatus.Playing)
    System.Threading.Thread.Sleep(10);

Key points:

Reuse the same SoundBuffer if you need to play the same sound multiple times.
Keep the Sound (and its SoundBuffer) in scope until playback finishes.

Streaming Music

For large files (e.g., full-length tracks), use the Music class, which streams from disk:

It doesn't load the entire file into RAM.
Suitable for long tracks, though with slightly higher CPU usage due to streaming.

// Create a Music instance; it will stream the file on the fly.
Music backgroundMusic = new Music("background.ogg");

// Optional settings
backgroundMusic.Volume = 50f;
backgroundMusic.Loop   = true;

// Start playback
backgroundMusic.Play();

// In a game loop we'd typically:
// while (window.IsOpen()) { /* update, draw, etc. */ }

Common Pitfalls

Missing Native DLLs: If you get DllNotFoundException, ensure all CSFML native libraries are present.
Scope & Lifetime: If Sound or Music goes out of scope (is garbage collected), playback stops.
Program Exit: If the application ends before the audio finishes, you won't hear the full sound - keep the main thread running or integrate playback into the render loop.

How Processing Handles It

Processing offers sound support through the built-in Sound library and the legacy Minim library.

Below are the two most common approaches.

The Built-in Sound Library

Installing/Importing

In the Processing IDE, go to Sketch → Import Library… → Add Library…
Search for “Sound”, then click Install (if not already installed).

Placing Audio Files

Create a folder named data in the sketch's directory.
Copy audio files (e.g., music.mp3 or beat.wav) into that data folder.

In the sketch, import and declare:

import processing.sound.*;
SoundFile song;

void setup() {
  size(400, 200);
  // Load a file named "music.mp3" from /data
  song = new SoundFile(this, "music.mp3");
  song.play();        // start playing once
}

void draw() {
  background(0);
  // (Optionally visualize or control playback here)
}

Looping, Volume, Rate

void setup() {
  size(400, 200);
  song = new SoundFile(this, "music.mp3");
  
  song.loop();               // loop indefinitely
  song.amp(0.5);             // set volume (0.0–1.0)
  song.rate(1.2);            // change playback speed (1.0 = normal)
}

Minim

Minim handles things similarly, albeit through AudioPlayer:

import ddf.minim.*;
Minim minim;
AudioPlayer player;

void setup() {
  size(400, 200);
  
  minim = new Minim(this);
  // loadFile(filename, bufferSize)
  player = minim.loadFile("music.mp3", 2048); // Place MP3/WAV files inside the sketch's `data` folder.
  player.play();
  
  // Looping & Controlling
  player.loop();        // loop playback
  player.setGain(-10);  // lower volume: gain in dB
  player.setTempo(1.5); // speed multiplier
}

void draw() {
  background(50);
  // ...
}

Where to Store Files: Always place audio files in the sketch's data/ folder so Processing can find them.
File Formats:
- Sound library: supports WAV, AIFF, MP3 (depending on platform).
- Minim: supports MP3, OGG, WAV.
Latency / Real-Time: For low-latency playback or live audio input/processing, Minim (or advanced libraries like Beads or TarsosDSP) may be preferable.
Visualizations: Both libraries support real-time audio analysis (waveforms, FFT), which is great for interactive visuals.

Observations

Those two statements are crucial:

// Load a soundfile from the /data folder of the sketch and play it back
file = new SoundFile(this, "sample.mp3");
file.play();

We can observe a few things regarding API design:

It's procedural and imperative - we create resources first, then set properties, then play/stop via the resource reference. Importantly, it's necessary to keep a reference for later control.
Resources might require explicit (or scope-based) release.

On the other hand, I'm more interested in a "functional" style API, like this:

The Approach

We could implicitly load and manage resources, releasing them at the end of the application lifetime (on window close), if no explicit reference is needed. However, distinguishing between SoundBuffer and Sound (both are IDisposable) can be tricky when deciding which to persist. At the very least, this is what we should expose via PlaySound() and PlayMusic().

private void ReleaseResources()
{
    // Sounds
    foreach (Sound item in _soundInstances)
        item.Dispose();
    foreach ((string key, SoundBuffer item) in _soundBuffers)
        item.Dispose();
    foreach (Music item in _music)
        item.Dispose();
}

In fact in the current design we cannot share the underlying instance - since Glaze! is implementation-agnostic - unless we introduce strongly typed types for SoundBuffer, Sound, and Music, so all implementations can recognize them. Otherwise, we can't return any instance objects.

// IInteractiveServiceProvider, which is ignorant of SFML.Net's existence
#region Audio Engine
void PlaySound(string filePath);
void PlayMusic(string filePath, bool loop = true);
#endregion

A slightly inelegant shortcut is to expose them as untyped "object handles":

/// <summary>
/// One-shot sound.
/// </summary>
object PlaySound(string filePath);
/// <summary>
/// Loopable BGM etc.
/// </summary>
object PlayMusic(string filePath, bool loop = true);
/// <param name="volume">0–100f</param>
void SetVolume(object soundOrMusic, float volume);
/// <param name="pitch">0–1f</param>
void SetPitch(object soundOrMusic, float pitch);
void SetLoop(object music, bool loop);

While it might seem "unsafe" on the paper, it works well in Divooka's graphical interface:

(This is partly thanks to Divooka's support for return value naming via XML doc comments, e.g., <returns name="Music">A music instance.</returns> for PlayMusic().)

Conclusion

So far so good! There's a lot we can enhance in the audio engine - more parameters, DSP support, etc. For example, Processing has very neat functions for low-pass/high-pass filters.

But for now, we can play sounds - and that's a solid start!

References

Processing Sound library documentation: here
Divooka Glaze! framework documentation on Methodox Wiki

TechTalk 20250611: Factory Pattern - Separating Creation from Use

Wed, 11 Jun 2025 13:28:15 +0000

At its core, the Factory Pattern centralizes object creation into dedicated methods or classes, instead of scattering new calls or complex constructors throughout your codebase. This separation yields several benefits:

Clarity of Intent
A method named CreateFromCsv() or ConfigureNumberDisplay() immediately tells the reader what kind of object will emerge, whereas a bare constructor new TextDisplayConfiguration(…) may require you to look up parameter lists and defaults.
Flexible Return Types
Static factory methods can return any subtype or cached instance they choose. A constructor must always return a fresh instance of its own class.
Simplified Overloads
Instead of dozens of overloaded constructors to cover different initialization scenarios, you provide a handful of well-named static methods (e.g. WithTitle(), WithSubtitle()), each encapsulating its own logic and defaults.
Validation and Caching
Factories can centralize validation (throw early on bad arguments), perform expensive setup only once (returning a shared singleton), or even pool and reuse objects.

Static Factory Methods vs Constructors

Aspect	Constructors	Static Factory Methods
Naming & Discoverability	No name beyond class name	Method names describe purpose
Return Flexibility	Fixed to class it belongs to	Can return subtypes or cached refs
Overload Explosion	Many overloads → unreadable	Distinct methods → self-documented
Default Configuration Logic	Scattered in callers	Encapsulated in one place
Conditional Instantiation	Hard to vary at runtime	Easy to branch inside factory

Divooka's Use Case: Organizing Tools by Category

In Divooka, every static method in a class becomes a toolbox entry - with the class name serving as the toolbox category. By grouping related factory methods inside dedicated static class containers (e.g. PlotConfigurations), Divooka can automatically:

Discover all available tools at startup
Organize them under logical headings (one class = one category)
Expose named methods like ConfigureTextDisplayWithTitleAndSubtitle directly to end-users

Were these methods instead constructors on each configuration type, Divooka would lack a natural grouping: you'd have to scan every class for all its constructors, losing that simple "category = class" mapping based on usage.

Case Study: ASP .NET Core's Builder-Based Factory Approach

ASP .NET Core also relies heavily on factories - but often via the builder pattern:

Host.CreateDefaultBuilder(args)
    .ConfigureServices((ctx, services) =>
    {
        services.AddDbContext<MyDbContext>(opts => 
            opts.UseSqlServer(connectionString));
        services.AddSingleton<IMyService, MyService>();
    })
    .Build();

Here the "factory" is implicit in the IHostBuilder:

Fluent configuration methods (ConfigureServices, UseUrls, etc.) collect options
The final Build() call manufactures the fully wired IHost
You get immutability until build time, plus a clear sequence of configuration steps

Comparing Static vs. Builder Factories

Feature	Static Factory Methods	Builder Pattern (ASP NET Core)
Discovery	Simple reflection on static classes	Extension-method based; discoverable by IDE but less obvious at runtime
Grouping	One class = one category	Spread across many fluent calls
Extensibility	Add new methods in classes	Add new extension methods on interfaces
Configurability	Encapsulated per-method logic	Centralized in a mutable builder state
Readability	Direct: `MyFactory.Create(…)`	Fluent chaining: `builder.Configure…`

In many small‐to‐medium scenarios, static factory methods win on simplicity: you immediately see each creation scenario, and end-users can invoke exactly what they need. In very large frameworks (like ASP .NET Core), the builder shines by aggregating dozens of configuration concerns into a single, coherent pipeline before creating the final product.

Conclusion

The Factory Pattern - whether via simple static methods or a full builder API - decouples what you need from how it's built. Choosing static factory methods:

Keeps creation logic in one readable place
Leverages method naming to self-document different initialization paths
Allows frameworks like Divooka to auto-discover and categorize tools
Avoids constructor overload chaos

Meanwhile, builder-style factories excel when you have large configuration graphs to assemble in a defined sequence. By understanding both approaches, you can pick the pattern that best balances clarity, flexibility, and discoverability in your own projects.

DevLog 20250610: Plotting in Divooka

Tue, 10 Jun 2025 21:02:05 +0000

Overview

Plotting is one of those things people take for granted - only when you need it does its absence become painfully obvious. It's often viewed as "solved" - until it's time to implement your own.

The Design Principles

The goal of the plotting API in Divooka is to provide a very high-level, easy-to-use (ideally single-node) setup for common plot types: you just supply the source data, pick the plot type, behold and voila - you get the resulting chart. In the case of the Plotting toolbox, the results are static images.

This scheme allows some fairly complex plot types, as seen here:

However, things can become tricky when we want to support advanced style configurations, for which the convention is to expose data on a node as direct inputs and style configurations as a separate Configurations input, as discussed in this blog article.

The real challenge is to support creating advanced custom plot types without sacrificing clarity - in which case we have to use OOP under the dataflow (functional programming) constraint:

For convenience and other practical reasons, we also want to support text-based methods like Mermaid - in our case, it's called Dhole.

Designing API for Custom Plot Types on Top of ScottPlot

We have chosen ScottPlot as our underlying drawing backend, and we know it supports a host of features - now we need to design a Divooka API or wrapper of some sort so that it exposes the same feature set without exposing underlying ScottPlot types to avoid explicit dependencies.

ScottPlot 5.0 has a nice compositional API built in:

ScottPlot.Plot myPlot = new();

myPlot.Add.Signal(Generate.Sin(51));
myPlot.Add.Signal(Generate.Cos(51));

myPlot.Layout.Frameless();
myPlot.DataBackground.Color = Colors.WhiteSmoke;

And you can procedurally add elements with object instances:

ScottPlot.Plot myPlot = new();

ScottPlot.Plottables.LinePlot line = new()
{
    Start = new Coordinates(1, 2),
    End = new Coordinates(3, 4),
};

myPlot.Add.Plottable(line);

One way to create a wrapper library is to create wrappers for all types and Add methods in Divooka:

// ScottPlot.PlottableAdder
namespace ScottPlot
{
    public class PlottableAdder
    {
        public PlottableAdder(ScottPlot.Plot plot);
        public ScottPlot.Plot Plot { get; }
        public ScottPlot.IPalette Palette { get; set; }
        public ScottPlot.Color GetNextColor(System.Boolean incrementCounter);
        public ScottPlot.Plottables.Annotation Annotation(System.String text, ScottPlot.Alignment alignment);
        public ScottPlot.Plottables.Ellipse AnnularEllipticalSector(ScottPlot.Coordinates center, System.Double outerRadiusX, System.Double outerRadiusY, System.Double innerRadiusX, System.Double innerRadiusY, ScottPlot.Angle startAngle, ScottPlot.Angle sweepAngle, Nullable<ScottPlot.Angle> rotation);
        // ... more methods ...
        public ScottPlot.Plottables.VerticalSpan VerticalSpan(System.Double y1, System.Double y2, Nullable<ScottPlot.Color> color);
    }
}

Which, as you can see above, is a lot.

ScottPlot Plottable Types:
    ScottPlot.IPlottable.cs
    ScottPlot.Plottables.Annotation.cs
    ScottPlot.Plottables.Arrow.cs
    ScottPlot.Plottables.AxisLine.cs
    ScottPlot.Plottables.AxisSpan.cs
    ScottPlot.Plottables.BarPlot.cs
    ScottPlot.Plottables.Benchmark.cs
    ScottPlot.Plottables.BoxPlot.cs
    ScottPlot.Plottables.Bracket.cs
    ScottPlot.Plottables.Callout.cs
    ScottPlot.Plottables.CandlestickPlot.cs
    ...
    ScottPlot.Plottables.VerticalLine.cs
    ScottPlot.Plottables.VerticalSpan.cs
    ScottPlot.Plottables.ZoomRectangle.cs

Creating a wrapper for each of those is not too difficult - it's mechanical and can probably be sped up with ChatGPT, but the biggest concern is maintainability and the process can be error-prone during initial setup. A shortcut is to expose the ScottPlot namespace and types directly, since the API already sort of supports compositional use, but we don't want to create such explicit dependencies.

A workaround (or middle ground) is that in Divooka we can create a bunch of factory methods and indirectly expose the Plottables as return values.

internal class CustomPlot
{
    public record OtherConfigurations(string Title, string XAxisLabel, string YAxisLabel);
    public static PixelImage GeneratePlot(int width, int height, IPlottable[] plottables, OtherConfigurations styles)
    {
        ScottPlot.Plot plot = new();
        foreach (var item in plottables)
            plot.Add.Plottable(item);
        
        if (!string.IsNullOrEmpty(styles.Title))
            plot.Title(styles.Title);
        if (!string.IsNullOrEmpty(styles.XAxisLabel))
            plot.Axes.Bottom.Label.Text = styles.XAxisLabel;
        if (!string.IsNullOrEmpty(styles.YAxisLabel))
            plot.Axes.Left.Label.Text = styles.YAxisLabel;

        return plot.ConvertScottPlotToPixelImage(width, height);
    }
}

However, this is not enough shielding - to vamp it up a level, we just need to define our own Plottable.

public class Plottable
{
    internal IPlottable Underlying;
    public void SetProperty(string attribute, object value)
    {
        // Set actual property of the underlying object...
    }
};

public static PixelImage GeneratePlot(int width, int height, Plottable[] plottables, OtherConfigurations styles)
{
    ScottPlot.Plot plot = new();
    foreach (var item in plottables)
        plot.Add.Plottable(item.Underlying);
    // ...
}

In addition to factory methods, we can provide a bunch of text-based WithXXX methods to provide a functional re-configuration of data and plottable-specific properties:

public static Plottable WithData(Plottable original, double[] vector)
{
    // ...
}
public static Plottable WithLegendText(Plottable original, string text)
{
    // ...
}

The end result is that we wrote minimal code, avoided having to create a custom wrapper for every plottable, while still largely making use of existing ScottPlot components and exposing a fully functional API in Divooka for custom plotting.

Example - Advanced Plot Customization

In this case, we show how to customize a plot with OOP components:

Summary of Available Plots in Divooka

See table on Wiki page.

References

REST API - A Refresher

Mon, 02 Jun 2025 05:36:19 +0000

Overview

REST API is the HTTP interface following REST principles to manipulate resources. This quick refresher looks at some common concepts and its application in Divooka.

1. Why you should care

REST (REpresentational State Transfer) is the de-facto style for web services: roughly 8 out of 10 public APIs you’ll meet follow it, so mastering the basics lets you speak to almost any modern backend.(Integrate.io)

2. REST in 60 seconds

A REST API exposes resources (nouns such as /users/42) over plain HTTP. Clients use standard verbs to act on those resources:

Verb	Typical intent	Idempotent?
GET	Read	✔︎
POST	Create / adj. action	✖︎
PUT	Replace	✔︎
PATCH	Partial update	✖︎
DELETE	Remove	✔︎

RESTful servers must also follow six architectural constraints (uniform interface, client-server, stateless, cacheable, layered, code on demand optional).(restfulapi.net, Integrate.io)

3. Common response codes

200 OK / 201 Created – success
400 Bad Request – client error (malformed JSON, missing fields)
401/403 Unauthorized / Forbidden – auth problems
404 Not Found – wrong URI or missing record
500+ Server errors – bug, outage, etc.(Postman Blog)

4. Tiny “Hello World” example

GET https://api.example.com/items/123
Accept: application/json

Typical JSON reply:

{
  "id": 123,
  "name": "Widget",
  "price": 9.99
}

5. Trying REST in Divooka

Divooka lets you build the call as a node graph instead of filling long forms:

Send (HTTP) Request node – set GET and URL {{baseUrl}}/items/{{itemId}}.
Headers – drop a Custom Header node for key:value pairs like Accept: application/json.
(Optional) Auth node – choose Basic, Bearer, or OAuth 2.0.
Preview JSON node to parse JSON payloads – pretty-prints and type-checks the body.

Everything is visual and reusable: connect the same response into further logic (save to DB, update UI, trigger another request) without writing glue code.

You can view more practical examples on the Web API Testing page.

Environment variables

Define baseUrl, apiKey, or authToken once in Environments and reference them anywhere with Get Environment Variable nodes. Switch environments (dev/staging/prod) using Switch node.

Save and group related requests into graphs as documents, so it can be easily reused and shared.

6. Best-practice checklist

For designing your own REST APIs:

Keep URIs noun-based (/orders/17, not /getOrder).
Use correct verbs (no GET /deleteUser).
Surface pagination & filtering (?page=2&limit=50).
Version in the path or header (/v1/), never break existing clients.
Secure with HTTPS, auth, and sensible rate limits.
Document with OpenAPI; Divooka can import the spec and scaffold nodes automatically.(idratherbewriting.com)

7. Further reading

Usage documentation in Divooka.
Roy Fielding’s REST dissertation (the original source)
RFC 9110 – HTTP Semantics
Postman “REST API examples” blog for real-world patterns(Postman Blog)
Divooka Wiki → App Development > API Testing (deep-dive on every node and feature)

With these essentials you can explore any REST endpoint confidently - and wire it into your Divooka flows to suit your application needs.

Hello World in Divooka - Basic Generative AI Program

Sun, 01 Jun 2025 23:21:14 +0000

Hello World

Divooka™ is a node‑based visual programming environment that lets you build workflows by connecting functional blocks (called nodes).

In this example, we are going to see a simple but fully functional program in Divooka™. We are going to ask ChatGPT (from OpenAI) to generate a text prompt for an image generator, generate an image, and then preview it.

Prerequisites

A working installation of Divooka™. All functions mentioned in this example is available in standard Divooka™ Explore distribution.
An OpenAI API key configured in Divooka™’s AI Services toolbox. You can use Configure OpenAI node or simply save an environment variable OPENAI_KEY.
Basic familiarity with Divooka™’s interface (e.g., dragging nodes, wiring connections).

Building the Graph

To build the above program, use the following nodes:

Chat GPT Complete under OpenAI Helper (You can find it in the AI Services toolbox)
Generate Image under OpenAI Helper category (You can find it in the AI Services toolbox)
Preview from the Basic toolbox

Running the Program

To execute the program, click on the little "Run" button at the upper right corner of the Preview node.

What Happened?

We've asked Chat GPT to "help me generate a prompt with about 300 words for an image generator (in this case Dall E 3) - describe an interesting sci-fi landscape", and used its output as input to the image generator.

This simple example illustrates several basic concepts of using Divooka™:

Functions are available from toolboxes; they are further organized using categories. Certain functions may have variations that differ slightly in behavior.
You can connect inputs and outputs between nodes by holding and dragging the left mouse button. That forms the logic flow of the program.
To run a program, click the Run button on the final node from which you wish to obtain results.

Configure Nodes

If you want to pick a different model, or specifying API Key explicitly, you can use the Configure OpenAI node.

Remarks

Congratulations! You've built your first fully functional and useful Divooka™ program! Embark on an amazing journey and enjoy an unprecedented programming experience with Divooka™. As you learn more about what's available, you will be able to build more and more powerful Divooka™ programs with more sophisticated node setups.

A General Service Configuration Scheme in Graphical Context

Sun, 25 May 2025 06:16:54 +0000

Overview

In this article, we take a look at one emerging pattern that provides a straightforward and compact way to configure services. Generally speaking, when a function expects many inputs, the most straightforward way is to directly expose those on the node. However, this quickly makes the node gigantic in size.

(Node with many parameters)

(Example in ComfyUI)

When a node has too many parameters, it becomes bulky.

(Example in Blender)

This quickly becomes infeasible when even more complex parameters are required for the functioning of nodes—for instance, if it's an online service with many potential configuration settings. A typical approach is thus to utilize a GUI element, which we shall call a "node properties panel." Below is a sophisticated example from Houdini. PowerBI and Zapier do similar things.

(Houdini node configuration panel)

This method falls short for two reasons:

It's not explicit, and configuration parameters are not visible on the graph. Which makes it not possible to see dataflow nor to programmatically drive those values.
It requires a dedicated GUI and can only be configured within that GUI.

The Design Approach

Usually, some kind of scripting or expression language is used to address the first problem. For instance, in Houdini, users often write VEX snippets or Python expressions inside parameter fields to control behavior dynamically. In Zapier, configuration can include custom JavaScript code or formulas in input fields to manipulate data between steps. These workarounds bring back some level of flexibility, but at the cost of breaking the visual flow and requiring users to write code inside otherwise "no-code" or "low-code" environments.

One design goal of Divooka is to be frontend-agnostic. The currently released frontend is officially known as "Neo", which is a WPF-based technology. However, Divooka graphs are designed to be generic enough to be visualized on different frontends—ideally in a way that's very easy to implement. That’s why we prefer to expose everything explicitly, so no specialized logic is required on the frontend (e.g., to be aware of the nodes they are dealing with).

Configuration in Divooka

Visually, we have a ConfigureX node and some nodes that take a configuration parameter as input. This dominant pattern is used in many places, including plotting configuration, OpenAI service configuration, and some other APIs like the image composition API.

(Example of plot configuration)

(Example of OpenAI service configuration)

(Example of image composition API)

We could provide a few different overrides for creating a configuration—so depending on how many details are needed, one can use a more lightweight or more heavy-duty configure node.

(PostgreSQL with two different configurations)

That concludes our introduction to the current setup, but the versatility of Divooka doesn't end here. Indeed, we could also introduce some kind of GUI panels for advanced configurations, and in fact, that’s desirable for certain things - at the price of losing the capability to programmatically drive the parameter values. This will be an expected standard feature in the full release of Divooka.

References

This article reference the following software:

Houdini – A professional 3D animation and visual effects software used in film, TV, and games, known for its node-based procedural workflow.
Blender – A free and open-source 3D creation suite that supports modeling, animation, simulation, rendering, and more.
ComfyUI – A graphical node-based interface for building image generation workflows using AI models like Stable Diffusion.
PowerBI – A business analytics tool by Microsoft that lets users visualize data and share insights across an organization.
PostgreSQL – A powerful, open-source relational database system with a strong emphasis on extensibility and standards compliance.
Divooka – A general purpose programming language for building procedural programs and data flows through node graphs.
Zapier – An online automation platform that connects different apps and services to automate workflows without coding.

DevLog 20250510 Dealing with Lambda

Fri, 16 May 2025 19:49:54 +0000

(The technical term is "Closure")

The essence of lambda calculus is with captures - be it simple values or object references. At the site of anonymous function declaration, it's being captured and (the reference) is saved inside the lambda until being invoked.

// C# – Capturing a local variable in a LINQ query
int factor = 3;
int[] numbers = { 1, 2, 3, 4, 5 };
var scaled = numbers
    .Select(n => n * factor)   // ‘factor’ is captured from the enclosing scope
    .ToArray();
Console.WriteLine(string.Join(", ", scaled));  // 3, 6, 9, 12, 15

In C++ this is more explicit, and the capturing process is more obvious:

// C++20 – Capturing a local variable in a ranges pipeline
#include <iostream>
#include <vector>
#include <ranges>

int main() {
    int factor = 3;
    std::vector<int> numbers = { 1, 2, 3, 4, 5 };

    // Capture ‘factor’ by value in the lambda
    auto scaled = numbers 
        | std::views::transform([factor](int n) { return n * factor; });

    for (int x : scaled)
        std::cout << x << " ";   // 3 6 9 12 15
}

What happens when an object reference is disposed, as in the case of IDisposable? It will simply throw an error.

using System;
using System.IO;

class Program
{
    static void Main()
    {
        // Create and use a MemoryStream
        var ms = new MemoryStream();
        ms.WriteByte(0x42);                // OK: writes a byte

        // Dispose the stream
        ms.Dispose();                      // Unmanaged buffer released

        try
        {
            // Any further operation is invalid
            ms.WriteByte(0x24);            // <-- throws ObjectDisposedException
        }
        catch (ObjectDisposedException ex)
        {
            Console.WriteLine($"Cannot use disposed object: {ex.GetType().Name}");
        }
    }
}

An important distinction is events or plain callbacks that requires no return value, which can be implemented quite plainly.

To achieve the same in a dataflow context, some kind of GUI (or "graph-native") support is needed, and to the caller, it's clear (in the language of C#) it's taking a delegate as argument, as in the case of LINQ Select.

public static System.Collections.Generic.IEnumerable<TResult> Select<TSource,TResult>(this System.Collections.Generic.IEnumerable<TSource> source, Func<TSource,int,TResult> selector);

To implement capturing, the most natural way is to ensure it happens "in-place" - directly on the graph. With this approach, we don’t need specialized nodes for every kind of function; we can instead rely on existing language constructs to handle the rest.

The last bit is actually inspired by Haskell, where functions are first-class and can be composed:

-- A simple two‑argument function
add :: Int -> Int -> Int
add x y = x + y

-- Partially apply 'add' to “capture” the first argument
addFive :: Int -> Int
addFive = add 5

main :: IO ()
main = do
  print (addFive 10)          -- 15
  print (map (add 3) [1,2,3]) -- [4,5,6]

See a demo of usage here, reposted below:

Reflections on My Second LangChain Session: Hype, Substance, and Agentic Potential

Fri, 16 May 2025 16:43:56 +0000

Today marked my second time attending a LangChain talk. My first was at a previous company, and this time, I joined an ACM-invited session. Unfortunately, my impression hasn’t changed much. Like the last time, the presentation leaned more toward a marketing pitch than a meaningful deep-dive into technology.

Forty minutes into the session, we were still swimming in vague promises and general problem statements. "LangGraph can solve this," they said - without ever really explaining how.

What LangChain Brings to the Table

To be fair, LangChain does offer a decent toolbox. Its ecosystem includes:

Paid utilities (like PDF ingestion)
Core components such as text splitters, output parsers, document loaders, and vector stores
Compositional elements like prompts, example selectors, tools, and model abstractions

Among these, the PDF ingestion tool stood out. It's genuinely useful - just not particularly accessible, since it sits behind a paywall. That pattern of paywalled features brings up the classic vendor lock-in concern. When a tech stack becomes too reliant on a single platform, especially one with closed components, you're playing a risky game. And to be blunt, the overall design doesn’t feel groundbreaking.

Learning by Observing

For me, the purpose of attending wasn't just about learning the tool - it was about observing how they package and present AI service integration. As Divooka continues to evolve and offer deeper native AI capabilities, I find myself increasingly valuing compositional and node-native approaches, like what ComfyUI offers. Its visual chaining model feels more transparent and modular - something that can be critical when building robust, production-grade AI workflows.

That said, there was one key idea from the LangChain session that resonated: agents do matter. Agentic applications, when structured with purpose and supported by strong pipelines, can lead to some powerful real-world use cases.

The "Real-Time Use" Challenge

The first problem they introduced had to do with real-time responsiveness. Ironically, they later conceded it wasn’t really a "problem" but more a matter of user-perceived latency. Still, here's how they broke it down:

Challenge	Proposed Solution
Multiple LLM calls needed	Parallelize steps where possible
Non-LLM steps (e.g., RAG, database queries, tool calls)	Parallelize or batch when feasible
Keeping users engaged during waiting periods	Stream intermediate outputs (optional)

The advice wasn’t necessarily wrong - but it felt narrow. These solutions are tailored for real-time UIs and don’t necessarily tap into the deeper promise of agentic systems. Agents shouldn’t just be about speed - they should be about capability, reasoning, adaptability.

LangGraph: Intriguing Promises, Lingering Questions

LangGraph, as an extension of LangChain, introduces some genuinely interesting features:

Persistent, long-running workflows with streaming and human-in-the-loop support
Integration with LangSmith for observability
A main graph architecture augmented by subgraphs for each agent - supporting multi-agent interaction patterns
Native support for both token- and event-level streaming
(Interestingly, someone compared it to Amazon Bedrock Flows, which seems like a fair analogy)

Despite the potential, several critical questions remain unanswered:

What does the full system architecture look like?
Is LangGraph something you must self-host, or does it assume reliance on LangChain’s hosted infrastructure?
How is state managed internally, and how configurable is the runtime model?
What’s the actual developer experience like when setting up human-in-the-loop interaction?

They did recommend a textbook - Learning LangChain: Building AI and LLM Applications with LangChain and LangGraph by Mayo and Nuno - which might offer some clarity. But relying on a textbook to fill in architectural gaps from a talk feels like a missed opportunity.

Final Thoughts

These sessions are always worth attending - not necessarily for the content, but for the context. It’s important to see how the broader ecosystem evolves, what narratives companies are pushing, and where we can differentiate.

At Methodox, we’re focusing on flexibility, transparency, and seamless integration across AI services. That’s why our approach to Divooka aligns more closely with frameworks like ComfyUI - ones that embrace openness and modularity.

The future of AI applications will depend not just on speed or flashy demos, but on clarity of architecture, trust in execution, and real-world adaptability. That’s where I believe we can lead.

Coder Legion - Recent posts tagged divooka

DevLog 20261002: Desktop Automation Toolbox and Mouse Emulation

DevLog 20261002: Desktop Automation Toolbox and Mouse Emulation

Two-Year Reflection on Methodox and the Development of Divooka

The Divooka Story

Internal and Financial

Noise, Splashes and Small Gadgets

Public-Facing

Lessons

The AI Gain

Conclusion

References

Methodox Voxel Sandbox | Launch Trailer | Methodox Voxel Scene Viewer

Core Features

DevLog 20260731: FPP v1.4.0 and Divooka Explore Demo Updates

Overview

Procedural Terrain Generation in Divooka

The Fantasy Planet Painter v1.4.0 Update

Conclusion

Designing a Binary Data API for Divooka with PPM and PLY Examples

Design Motivation

Reading Binary Data

Binary Buffer Reader: ImmutableByteArrayReader

Reading blocks

Strings

Writing Binary Data

Binary Buffer Writer: MutableByteArrayWriter

Immutable writer: ImmutableByteArrayWriter

Writing fixed-size blocks

Examples

Example: reading a PPM image

Example: writing a PPM image

Example: reading a PLY file

Future Improvements

DevLog 20260426: Divooka Mandelbrot Benchmark – Putting Our Scripting Language to the Test

Why This Benchmark Matters

Key Results (on Windows 11, i7-13700KF)

What We Learned

Current Results

Limitations

2026 Divooka™ Explore Steam Release Trailer

DevLog 20260319: Towards OOP - Document-Level Default Module and Module-Level Members and Behaviors

Revisiting Flappy Bird – The Pain Point

Searching for a Solution

The Divooka Way

What's Been Implemented So Far

Current Limitations & Remaining Work

Looking Ahead

References

DevLog 20260225: Divooka Visual Programming - Direct Value Setting of Compound Inputs

Overview

Our Approach

Future Work

Conclusion

DevLog 20260224 Divooka - Node-Level Automatic Dispatch (Runtime Execution Behavior)

Overview

The Plan

Array Coercion

Automatic Dispatch (Node-Level)

Full Example

Conclusion

Weekly Update 2026-01-11

What Happened This Week

Closing Thoughts

DevLog 20250507 Bringing Smart Suggestions and Smarter Search to Divooka’s Visual Coding

Learning from Unreal Engine Blueprints

The Challenge: Missing Type Labels in C# Instance Methods

Explicit Type Filter in Search Syntax

Building the Pipeline: Filtering and Highlighting

The Result: It Just Works (Mostly)

What’s Missing: Auto-Connecting Suggestions

Next Steps: Toward Full Contextual Suggestions

Summary

Conclusion

[Article] Divooka, Where We Are

Overview

Early 2024

July–Sep 2024

Sep–Dec 2024

Jan–Aug 2025

Binary Buffer Reader: `ImmutableByteArrayReader`

Binary Buffer Writer: `MutableByteArrayWriter`

Immutable writer: `ImmutableByteArrayWriter`