What have I been up to over the last week? A few things.
RAM
I got my next 16GB batch of RAM in for my desktop. Out with the old, in with the new. It works. With the upgraded CPU and double the RAM, this 9 year old computer feels like new.
Now I have an extra 32 GB of DDR3 RAM that I will probably never use.
The four on the left didn’t work in my computer, but I suspect it might work in some other motherboard. The rest of it all works fine. It’s going to end up in a drawer somewhere, so I’d love to get it to someone who can use it. Open to any offers. Shipping, plus whatever you want to pay. I’m not looking to profit, but if I could recoup some fraction of what I spent, that’d be nice.
Bit-Box
I was really enjoying my Bit-Box for the last week or so. Until I was messing around with the USB cable for some reason and managed to tear the connector right off.
Oops!
The problem, I think, was that I used way-too-heavy, solid wire to connect everything. Everything was far too stiff so when I put a bit too much strain on the USB cable, the connector was the first thing to go. Also, soldering everything directly to the board wasn’t the greatest idea either. So the first step was to remove the old one…
Then I soldered on the pins that came with the Arduino boards. I had some ribbon cable with connectors on it, so I cut some of that to size and plugged it onto the pins.
Now it’s much more flexible and in the event that something does go wrong with this board, I can easily pull it and put in a new one.
I still have plans on making a larger one, but haven’t started anything on that front yet.
Attractors
I’ve been continuing to work on learning GTK3 desktop Linux apps, working on making an app that does live drawing based on changeable UI parameters. It’s been fun and I’ve made some good progress. I figured out enough of the architecture to feel some confidence in how to set something like this and started in on making a real app using this idea.
One app that I’ve done multiple times over the years is what I call “Strange Explorer”. It presents different formulas for strange attractors, allows you to change their parameters in real time and see and save the outcome. I’ve done it in Flash and JavaScript, and even made a native iOS version. Here’s what I’ve come up with so far:
Two things about this project that I’m really happy about so far. One is that the different formulas are created as external configuration files that get read in at run time. They look like this:
name Hopalong Attractor x_formula y-1-sqrt(abs(b*x-1-c))*sign(x-1) y_formula a-x-1 z_formula n/a scale 10 iter 50000 init_x 0 init_y 0 offset_x 0 offset_y 0 rotation 0 a -0.537 b 2.797 c 2.973 d 0
The code reads all the files in the formulas directory at startup. So to create a new attractor, I just have to create the new config file for it and start the app. It will automatically populate and function.
The other part is the formula parsing itself. Note that the formulas in the above configuration file are just lines of text that populate text fields in the UI. And those text fields are editable. And yet, it winds up as runnable code. To accomplish that, I’m using a library called tinyexpr. https://github.com/codeplea/tinyexpr You just feed it a string of text and it is evaluated. There are ways to bind variables to it so a, b, c, x and y are all plugged in to the formula at run time as well. It handles all the standard C math library stuff. But you can also define your own functions, like I had to for the sign operation in that example.
Eventually, I’ll create a way to bookmark settings and define brand new formulas right in the UI. Having a lot of fun with this project though.
Interpreters
To be honest, the attractors project has been a bit sidelined during the latter half of the week, as I’ve started down a whole new giant rat hole.
When I was creating the configuration files for that project, I needed a way to read and parse them at runtime. I thought about JSON and YML. There are C libraries that handle those. There’s also libraries that are totally designed for reading configuration files of various formats. In the end, I decided all of those were overkill for what I needed. I just needed to read lines from a file, separate the first word (name of property) from the rest of the line (property value) and add that to a model object.
So I wound up making my own parser. It does just that – reads each line, splits each line on white space. Takes the first element as the property name and joins the remaining elements as the value. If it’s a numeric property, it converts it to a number. Super simple, but it works fine. I’ll need to bolster it up a bit with some error checking, but it’s all I really need.
But it reignited my interest in building an interpreter. And reading up on tinyexpr fanned those flames a bit more.
I’ve had this idea for a while now to build my own DSL (Domain Specific Language) for creating graphics. It would sit on top of something like Cairo Graphics, parse a simplified source file and create a picture. Mainly so I could do away with a ton of setup and boilerplate and just write the commands that make the pretty shapes. It would probably wind up looking something like Processing, but even simpler.
Now before you start throwing links at me to projects that already exist like that, or ask why don’t I just use ____? … that’s not the point. The point is that I want to make something like this. Even if it’s only for myself.
A while back, when I was doing more with Go, I picked up two books:
I got a little ways into the interpreter book, but never finished. Not a criticism on the book, which seemed pretty good actually, but I got distracted.
Anyway, I decided to go back into this idea and found a few really good online resources. The one I’m working through now is Let’s Build a Simple Interpreter.
When I first started this series, I assumed it was maybe up to five parts and I saw that it was started 5 years ago, so figured I’d get through it fairly quickly. It turns out that it’s now up to 19 parts and the last installment was earlier this year.
And it is amazing.
As an author of technical books myself, I really appreciate it when someone can explain complex subjects clearly. There are so many poorly written technical books and tutorials, when you find one that is really well done, it is a joy. This is one of those.
Writing an interpreter is a complex thing. He takes it one step at a time, in bite sized chunks that you really can wrap your head around. The overall goal is to write an interpreter that will handle most of the Pascal language. I’m on lesson 9 right now. And I don’t recall being this excited over some technology in a while.
This series focuses on Python as the language that the interpreter is being developed in. But I’ve been re-writing it in C. Porting it while learning it has been a great way to force myself to really fully understand what each line of code is actually doing. Much better than just copying and pasting. In fact, I think from now on, if I want to learn something that is not totally language dependent, I’m going to seek out tutorials in a language other than the one I’ll be using.
If you’ve ever thought about learning more about this subject, this particular series is a great place to start. Along the way I’ve found some other resources that I plan on looking into when I work my way though this one. I’ll list them here.
Sites:
- Let’s Build a Simple Interpreter
- Crafting Interpreters
- Let’s Build a Compiler
- Let’s Make a Teeny, Tiny Compiler
Books:
(These were all taken from the simple interpreter series I’m working through now)