aerkiaga's blog

Progress report on my projects

This week I've given a good cleanup to my digital life. First, I purchased a backup drive; I transferred much unnecessary data from my devices and freed up space, then did backup copies of all of them and scheduled further, periodic backups.

I also downloaded and deleted all my data from the cloud, including photos and emails, and stored two copies of said data in different drives. I deleted any social media accounts I was no longer using and removed all comments from the ones I was using.

Finally, I installed a password manager; locked it with a very strong master password and changed many of my online passwords to randomly generated ones stored locally. Then I backed up the database to two other drives and two different devices.


Of course, I've kept interviewing local doctors to get an idea of what each hospital is like from their perspective.

Regarding Nacre, I've done small incremental changes to data type-related code generation. Now all kinds of structs can be constructed and their fields accessed. Only recursive types are left.

I have created a Github roadmap for the first release. It will probably take a lot to finalize, but most of the work is already done.

Here are the mutation testing-measured scores for the different components:

  • nacre_ast: 59 %
  • nacre_cache: 100 %
  • nacre_compiler: 76 %
  • nacre_kernel: 85 %*
  • nacre_parser: 48 %

*nacre_kernel additionally has a fuzz testing suite.

This week, I've interviewed a few local medical practitioners to help me choose a medical specialty, and, more important, a place to work and train on it. Long transcripts from the interviews, recent news and information on the different hospitals – all are helpful in the decision.

I also re-learnt the ways of Taskwarrior, a command-line task management software. I tried it long ago, but now that I've already transferred most of my workflow to the keyboard by virtue of tools like tmux and Vim, I'm starting to really feel the increased productivity.

How, s Nacre? Well, this week was more calm, with just some work on struct code generation. The goal is to get different data structures working and tested, then proceed to the next task in the roadmap, namely adapting the command-line interface.

For the first half of the week, I got Nacre a little bit further forward; now it's possible to compile some relatively simple programs. The tests working so far showcase some Bool operations and an Option::map, which requires enums with fields, closure passing, plenty of foreign function interface gimmicks and generic specialization. The test code for this one looks like this:

fn test(f: Bool -> Bool, x: Option Bool) {
    x.map f
};

And, speaking of specialization, I attended some conferences in Madrid during the second half of the week, regarding the choice of a medical specialty. I've been transcribing my notes for the last few hours, and I've arranged an interview with professionals in my target field later this week. So far everything seems clearer than ever for me: I want to become a psychiatrist.

So much has happened since my last blog post. My Google Summer of Code project was successful. I got a medical degree and ranked among the top 1% in public healthcare medical examinations. Did some research on ultrasound imaging and made a few prototypes (one manufacturer has offered to support my next prototype).

I've become more proficient in Rust and learnt Verilog and Chisel, which I use to program FPGAs for my ultrasound devices.

As for my programming projects, these years I've slowly expanded nodeverse, my voxel-based videogame. But my largest projects by far have been formal verification-related; I learnt Coq, and latter attempted to create my own language for formal verification: Rooster. After working on it for some time, I had collected a lot of knowledge on the design of these kinds of languages, and programming languages in general. Last year, after a lengthy design phase, I finally felt comfortable enough to go on to create Nacre.

I will probably talk more about this Nacre language in future posts, but for now I would just like to make an overview of its completion status and goals. Right now the compiler is almost fully functional, with a complete type checking kernel, the parser only missing some features, and code generation disabled by default for now but steadily progressing. Right now I'm implementing a specialization pass at the IR level.

The end goal is to get a language that one can use to write specific critical parts of a larger project in a formally verified fashion, letting the build system handle compiler invocation and linking.

Well, I did it. I got accepted by Open Chemistry and Google to officially work on Avogadro 2's biomolecular support. See this Discourse post to learn more and add your own ideas. I'll be (and have started!) working on the following:

  • Adding the ability to create molecular surfaces (Van der Waals, solvent accessible and excluded), colored by at least one scheme (e.g. electron density, hydrophobicity, partial charge...).
  • Adding support for rendering non-covalent interactions, like close contacts, hydrogen bonds, etc.
  • Making Avogadro 2 able to handle coordination complexes gracefully.
  • Fixing issues affecting bioinformatics workflows and improving performance in that area.

Additionally, I've cleaned the dust off Nodeverse and finished the latest piece of infrastructure: a set of scripts to convert OpenSCAD files into .obj!

I've just added automatic UV map generation and better handling of non-rectangular faces. Note that the scripts are only designed to work with axis-aligned faces (which are the only ones I'm using in Nodeverse, by design), but now at least they can have any shape within that constraint.

The idea is to use these new tools to ease development of models for the nv_ships mod, part of Nodeverse.

I did quite a lot of learning last week around molecular dynamics and quantum mechanics. In fact, I managed to get GROMACS, CP2K and OpenBabel working together to give accurate predictions on the density and heat of vaporization of various substances.

I sent a small PR to Avogadro 2, advanced in the design of both the Big Project and the tomograph, printed a piece of the latter... But I've got an exam today, in a few hours, and I've barely touched the subject :)

The more I study about Medicine, the more I see what's missing from it. And the less I think I know about the field... So massive...

For example, why don't medical records leverage Open Source Software? Why aren't EKG and other devices generally available on the cheap? Why do all imaging tests have pitfalls preventing their massive use? Why is AI not assisting imaging techniques yet? Why isn't there pharmacological secondary prevention for cancer? Why are tisular force equilibria so under-researched if they are so important? Why is the surgical field physically open to air? Why are GMO bacteria taking so long to be part of microbiome-targeting therapies?

I should probably stop wishing and keep studying. Somebody will eventually research the above after all, but no one can do my exam for me!

All the electronic components are here! I used aerkiaga/fluidics to 3D-print three boards out of ABS. Unfortunately, my printer can't add copper vias, so it's basically a matter of putting components in place, then soldering them on the other side, connecting them with tiny wires. Gross, but it works. So far I've made:

  • A small 9V barrel jack connector breakout board.
  • A 9V to 28V boost converter, to power the sensor.
  • An ESP32 board. Honestly I'm still soldering it, and there's a catch...

... one of the components is in a tiny QFN form factor chip that I still don't feel confident enough to put my soldering iron on. I soldered something that small before, but ended up overheating it (plus I bent or ripped a few pins and then dipped the whole thing in a non-electronics-safe cleaning bath... yeah...).


I've sent a couple more PRs to Avogadro 2:

  • #878: rewrites and finishes the subgraph detection code.
  • #887: fixes a few unimportant Valgrind errors so this kind of testing can be automated in the future.

I'm also learning to make biomolecular simulations using GROMACS. No new use-cases of that knowledge for now, but I hope to do something about this in the near future ;)

This week, I made some to the Avogadro 2 codebase. A few PRs were merged:

  • #860, which accelerates cartoon rendering.
  • #862 is the first step towards some big summer time changes!
  • #868 adds a new plugin, you might see it under 'View' –> 'Focus Selection' and 'View' –> 'Unfocus'.

I've already made a few orders for many electronic pieces (lots of $$). Plus I'm designing the code even further. It's a little weird writing the actual code while drafting these designs, but I hope the extra thought put into it will pay off.

I started last week getting angry at CadQuery's install procedure, which seems to be all of unreliable, bloated and proprietary. Disenchanted with OpenSCAD's lack of speed, I set off to write CaSCAD, which is little more than an OpenSCAD clone laid on top of Open Cascade Technology (OCCT).

Problem is, it's also laid on top of GTK4 (because why not), and I've not managed to get OCCT and GTK4 working together. Probably because my distro doesn't offer GTK4 natively; or maybe because some assumptions are made about what uses OpenGL and what uses GLES. In any way, that little burst of energy ended there, after having a full OpenSCAD parser, a partial compiler and bytecode interpreter, a stub of an OCCT backend and a nice-looking but empty GUI (with syntax highlighting). But not before scanning the OCCT codebase for any possible OpenGL bug...


I spent this week drafting a new device. Something that I intend to present to my professors to hopefully get my degree project managed around it. Something that can see inside the body, using...

Lasers. I bought three of them, each emitting in a different wavelength and with a different power (don't worry, no class 4). I intend to collimate them myself, using epoxy lenses, and then guide them with acrylic beam splitters.

An engineering student friend asked me if I could somehow get Cura to control the über-expensive titanium printer he was using, to break free from the half-baked commercial solution they only had available. Fast-forward a day and there's a Cura profile and post-processing script in his inbox, so now he'll design the mechanisms for my upcoming medical laser-bearing machine :)


I've also made great progress with my Big Project. First, the bad news: I haven't managed to inject metal into 3D prints... But the good news is, I don't need to. With the updated fluidics tools, I can just use a frying pan as a low-temp reflow oven and solder everything with Rose's metal!

I've also researched the electronics part of it, and am about to order large amounts of electronics components: ESP32 modules, stepper drivers, MOSFETs, frequency synthesis circuitry...

Finally, I've written some more of the code for this project. In case you're new to this blog, I'm coding everything in Rust, to make sure it's safe for biomedical applications. But here's something new...

The code is made of a client, a server/daemon, a real-time multitasking exokernel and a Hardware Abstraction Layer (HAL) underneath it. Right now, I'm making a “virtual” HAL that just runs the kernel on the host machine, using pipes to communicate with the daemon. This should help debug issues in the future, set up CI workflows, etc.

This week, I reimagined my fluidics tools. Rather than a complete solution, they were redone to work with other programs, so now you can simply draw a circuit in KiCAD and make it into an OpenSCAD script.

Of course, that leads us to OpenSCAD. No matter how much I love this tool, I feel it needs improvements. In particular, it needs speed, lots of it! And the CGAL backend just can't be enough for this, or for solid modeling in general.

I heard of CadQuery, a pretty neat piece of software, if it weren't for its fragile installation procedure, which requires an immense number of compile-time dependencies.

I tried to persuade the code into compiling, which kinda worked... Through a lengthy script that patched many files to push the installation forward, I got much progress, but ultimately quit.


And here's what I did: reimplement OpenSCAD with an OCCT backend. Nah, just kidding. Well, kinda. I've written a full lexer and parser, a half-baked compiler and a minimal bytecode interpreter, all in plain old C, linked everything against OCCT and... got a Standard_DomainError a few minutes ago. That's what's kept me busy these days.

Oh, yes, I do intend to replicate the entire thing. I'll just need to work on it for more than a week, no matter how productive it's been ;)

Edit: error fixed. Now we're making some serious cylinders!