Devlog 14: …oh

So I’ve been doing my development on Ubuntu, which, as a Linux distro, is UNIX-based, and uses just \n for newlines. However, I haven’t done any testing on Windows, and Houston, we have a problem. I still don’t have all my ratings yet, but someone was kind enough to create a github issue saying that Ile doesn’t work on Windows. I hadn’t thought to support it, but Windows uses \r\n for newlines! This broke the tokenizer, and caused the language to be unusable on non-UNIX-based systems. It was a one-line fix, but I already have 10 ratings, so I can only hope they aren’t too negative for having bad Windows support.😟

P.S. I guess this means Windows is officially as outdated as a typewriter!

Devlog 13: Ship time!

I’ve been working on getting everything ready to ship, and I think it’s almost time! I’ve fixed some bugs, added more tests, published to crates.io, and created a GitHub release! Now, I’ll make sure I have good instructions in my README, and I’ll be ready to go!

Devlog 12: Scoping is hard

I’ve been working on getting Ile ready to ship, and I had a small, significant feature to implement: scoping. This is basically when a function is called and uses the scope that it was a part of when it was created instead of the scope it was called in. This was hard.

To implement this, my first thought was write yet another lookup function to find the correct module’s stack and walk the function in the stack. Unfortunately, the compiler didn’t like this. I couldn’t get it done without having 2 different mutable references to the stack at the same time, so it was off the table. What I ended up going for was when a function is called, it clones (memory-efficient, amirite?!) its entire scope and walks inside it. After the function executes, it then sets the value of its module’s scope to the current value of the scope it just walked in, so as to update it with any changes. Makes sense, right? RIGHT?!

Anyway, there isn’t really a picture to show, so here’s tests passing.

Devlog 11: I don’t even know

I’m hoping to ship tomorrow, so I’m fixing up the language to be usable. I’ve been writing some documentation, so I have a little starter guide now. I also learned that Ile can use as little as one thirtieth the ram of Node.js! That’s definitely going in the features section.

Devlog 10: asdf

I’ve been trying to add a GUI system to the standard library. Because I don’t want any dependencies, I came up with the following harebrained scheme:

• Write a Python script that formats its stdin in a Tkinter window to draw a GUI
• When the function to create a window is called, spawn Python as a sub-process and send the text to be displayed to its input via a pipe

Unfortunately, this doesn’t work. The script works when run on its own, but when run by Ile it just doesn’t launch a window. I couldn’t figure this out, so the GUI system (VeBaGu, or Very Bad GUI) is staying, albeit in an unstable beta state.

On a side note, I’ve also decided to ditch the editor idea and just focus on the language; this Stardance project is now just Ile, not Crocodile.

Devlog 9: Hello, world!

I didn’t do that much work for this devlog, but I did achieve 2 important things:

• Added comment support
• Added bindings to println!() and stdin
  This means that Ile, as demonstrated below, can now read its stdin and write to stdout!

Devlog 8: We have language!

If you couldn’t tell, that was a play on “we have liftoff!”. I didn’t add a rocket emoji, for obvious reasons.

Anyway, I have great news: Ile is almost a usable language! Today, I added loops and operators, so it can iterate and do math now! My for loop is a tad different than other languages, so here’s the gist: every for loop has a condition and a block. Every iteration, the condition runs. If it returns something, the block runs. Otherwise, the loop exits. Because I made let statements return the value they assign, you can have syntax that looks like this:

for let x = iterator.next() {}

I’m really proud of how my syntax is turning out overall. There’s still not much to screenshot; I haven’t written the logic to interface with Rust, so there’s no println yet. I do have some more test coverage, though.

There was some difficulty getting break to work, however. For some reason, the loop it was a part of would always keep going. Eventually, I figured out why: It was being removed from the stack at the end of the code block that generated it. To fix this, I added some logic to re-push it to the stack if it got popped.

Devlog 7: Running before I can run

For some reason, I felt like instead of finishing the syntax fundamentals, I would skip directly to object-oriented (ish) patterns. In this case, we have a bunch of attributes that can be accessed and modified.

Below is a snippet of some OOP concepts in practice:

Devlog 6: {insert dark joke about lifetimes}

I just spent a frustratingly long amount of time figuring out why Rust didn’t like my lifetimes. I don’t even remember what I did to make it compile. This was fun.

However, after figuring that out, I wrote the walk methods for a few NodeTypes. Here’s the stack after a simple program finishes, and the program that was run:

Devlog 5: Operators

I started work on the AST (abstract syntax tree) walking algorithm today. I didn’t get very far, but one of the things I did do was I fixed operator parsing.

Before, if you were to parse something like 15 > 5 && 5 < 10, it would have been a greater-than operator with a boolean operator as a child, and that doesn’t work. Therefore, I had to write some code to convert that broken operator into a boolean operator with mathematical children. The algorithm didn’t make much sense in my head, so I drew it out on paper and that made it pretty easy to write.

Below is the illustration I made and the code it became.

Devlog 4: I finished the parser!

I wrote the parser, which takes the tokenized code and converts it into a usable, in-memory representation. After fixing the bugs from yesterday, I wrote some logic to parse a function block and the rest of the syntax was easy. Running main.rs now prints out a representation of a parsed AST. Now all I have to do is:

• make the AST walkable, so I can actually execute the code
• write logic to facilitate interop with Rust

The first image is some example Ile code, and the second is some of the AST that is generated from it.

Devlog 3: An almost-broken parser!

I made a very basic AST parser! The AST (abstract syntax tree) is the in-memory representation of the code as a tree. This took a really long time. My machine froze and my interpreter produced incomprehensible errors about wanting a word token, but in the end cargo test passed, so I’m happy.

It also doesn’t support anything other than function calls, but this is a great first step in creating an actually walkable AST.

Devlog 2

I started work on the AST builder. I decided that the algorithm will use delimiters to decide which tokens correspond to which AST node and I’m working on a method for Node that determines how to add a child based on the Node‘s type and the child’s type.

The screenshot is some of the code for Node.

Devlog 1: Building blocks

I’ve been focusing on the scripting language, Ile, because to be honest the editor is the boring part. So far, I have project structure and some fundamentals–I’ve written the tokenizer and some stack-switching logic. For those who don’t know, the tokenizer is responsible for taking a blob of (hopefully) human-readable source code and converting it into tokens, which are used later on to build an abstract syntax tree. For now, all I’m concerned about is that cargo test passes!

Devlog 3: Dependencies and hallucinations

I’m generally an anti-AI person. I don’t like the technology and I’m not a fan of offloading my thinking to a machine that cares so little about me that it can’t even deprive itself of sleep for the sake of my project. However, it became clear that Smithay’s documentation was doing me no favors. Begrudgingly, I turned to Gemini.

It was actually really helpful at first. I’ve been working on moving from a winit window to being able to run the compositor from a TTY or display manager, and it’s been “fun” (emphasis on the air quotes). Anyway, Gemini was able to explain what I had to do and help me understand things better.

Unfortunately, it’s also dumb. It consistently told me to use nonexistent APIs and misuse real ones. It at one point told me to loop over a bunch of connectors gotten from a DrmDevice. Getting them worked, but it then immediately instructed me to compare a value to a nonexistent enum. I had to find the source code for the library itself, which was a pain because I couldn’t find the relevant code anywhere in Smithay’s docs.rs documentation or even source code! Eventually, I realized that I should be looking in a dependency of Smithay instead of Smithay itself, and I found what I was looking for.

I still haven’t achieved what I set out to do, and I wrote this half an hour before midnight. cries in sleep deprivation

Devlog 2: Hello, world!

I finished copying Smallvil’s logic. That basically means 2 things:

1. I have a semi-semi-semi-functional compositor already
2. I’m on my own. Everything else I do I’ll have to research and implement myself.

Right now, I plan to go to sleep and then start working on getting it running without a parent compositor. Currently, it runs in a window inside another WM, and while that’s good for debugging, it needs to be able to stand on its own (2?) feet. After reading through Smallvil’s source, I think the hardest part will be determining when to render and receiving input, as both of those are handled in the winit event loop right now. Luckily, I have the Niri source code to read through.

Devlog 1: This was a terrible idea

I’ve wanted to make some kind of graphical shell for awhile now, but I finally decided that this would be the time. Unfortunately for me, I didn’t realize that this would be incredibly complicated. I’ve spent most of time researching and reading, so this devlog is only for 43 minutes.

I’ve learned a bit about the Wayland protocol, but also how Smithay works. Smithay is a Rust framework for building compositors that I’ll be using for mine. It was used for Niri (my current favorite window manager), so there has to be something good here!

I haven’t written much yet, but I have a plan: I’m going to copy over all the logic from Smithay’s Smallvil example to learn how it works. I’m then going to make some changes, such as pushing to the screen itself instead of a window and maybe some shell UI.

The screenshot is of some of Smallvil’s rendering code next to my notes about it.

I also designed a simple wallpaper, which I set the project image to.

Devlog 9: The unnecessary one

Stardance doesn’t want me to ship again without logging my 48 minutes, so here’s a brief summary: I removed some old code, changed the pawns_in_center heuristic to be more drastic, and made the TUI display how much time the engine took to move.