Today I am joining you from the relative discomfort of my living room (since my better half has commandeered the home office due to Way Too Many Calls) to tackle the day 6 challenge, which I’m excited about: maybe despite, maybe because of, the low-grade fever I’m under.

Part 1

Our input is a jumble of letters, and we’re supposed to find the position of the first substring that’s “four different characters”.

ooc makes it easy to compile your application on all major platforms (Windows, OSX, Linux) - the compiler itself runs there, and the SDK supports all these platforms with basic functionality: data structures, file handling, time handling, networking, etc.

But between getting your application running on your dev environment with all the libraries installed, and getting it into a neat package for your users to run without having to install any dependencies by hand, there’s a bag of tricks. Fortunately, I have found the time to figure most of them out. I’ll try to explain these in detail here as clearly as possible, here in this article.

Good morning! It is still 2020, and the world is literally on fire, so I guess we could all use a distraction.

This article continues the tradition of me getting shamelessly nerd-sniped - once by Pascal about small strings, then again by a twitch viewer about Rust enum sizes.

This time, Ana was handing out free nerdsnipes, so I got in line, and mine was:

In our last article, we managed to load and execute a PIE (position-independent executable) compiled from the following code:

; in `samples/hello-pie.asm` global _start section .text _start: mov rdi, 1 ; stdout fd lea rsi, [rel msg] mov rdx, 9 ; 8 chars + newline mov rax, 1 ; write syscall syscall xor rdi, rdi ; return code 0 mov rax, 60 ; exit syscall syscall section .data msg: db "hi there", 10

Disclaimer:

At the time of this writing, I benefit from the fly.io “Employee Free Tier”. I don’t pay for side projects hosted there “within reasonable limits”. The project discussed here qualifies for that.

Why you might want a remote dev environment

Fearmongering aside — and Cthulhu knows there’s been a bunch, since this unfortunate tweet — there’s a bunch of reasons to want a remote dev environment.

Now that our development environment is all set up, let’s make something useful!

Creating the catscii crate

From a VS Code window connected to our VM (as we just set up), let’s make a new Rust project:

amos@miles:~$ cargo new catscii Created binary (application) `catscii` package

And open it in a new VSCode window:

amos@miles:~$ code catscii

Even though we’re running this “code” command in the VM guest, VSCode set up enough plumbing that it communicates back to the host, telling it to open another VSCode window, connected to the same SSH remote, in the right folder.

One could say I have a bit of an obsession with build times.

I believe having a “tight feedback loop” is extremely valuable: when I work on a large codebase, I want to be able to make small incremental changes and check very often that things are going as expected.

Especially if I’m working on a project that needs to move quickly: say, the product for an early-stage startup, or a side-project for which I only ever get to do 1-hour work bursts at most.

In the previous article, We’ve built a nagaqueen-based tool that can parse one ooc file, detect class declarations and print its doc strings. Today, we’re making a bit of infrastructure for our app to support more sizable projects.

Source path and lib folders

Parsing a single file was a nice milestone, but it’s not nearly enough. We want to generate documentation for a whole project at a time: and since we’ll want to cross-link the various bits of documentation we generate, we’ll also need to parse the various dependencies (such as the ooc sdk, and any used library) so that we can resolve argument types and link them properly.