Ran 5.03 km in 31:31 (06:16 /km).
Ran 3.83 km in 23:07 (06:01 /km).
Ran 3.80 km in 21:47 (05:43 /km).
Ran 3.83 km in 23:42 (06:11 /km).
Ran 3.86 km in 22:48 (05:54 /km).
Ran 5.23 km in 31:21 (05:59 /km).
Ran 5.44 km in 30:37 (05:37 /km).
First run with new Garmin Forerunner 265.
Ran 5.46 km in 33:53 (06:12 /km).
Ran 5.36 km in 35:17 (06:34 /km).
in #race
Ran 1.23 km in 08:18 (06:45 /km).
Ran 5.41 km in 35:24 (06:33 /km).
Ran 14.03 km in 01:17:18 (05:30 /km).
Ran 5.27 km in 32:36 (06:11 /km).
Ran 7.02 km in 43:01 (06:07 /km).
Today I spent some time implementing a piece tree. It's not really a tree yet. It's more like a linked list. But I think the interface will be the same.
I've been curious about the piece tree for a while after having read a lot about it. And what better way to learn more and solidify that understanding than by implementing it? After getting a simple implementation working, I wanted to use it in the rest of rlworkbench and that work felt very hard. I was disappointed.
But I think I achieved something important that I didn't realize at first. I've never used a piece tree before. I've just read about it. Now I actually have an implementation in C. And I know how it works. I have advanced one step. Previously, my brain was focused on how a piece tree works and the benefits that it can give. Now that I actually have one, my brain can start thinking about how to use it in the context of rlworkbench.
I also got bogged down in details of C. And tried to reach perfection. That never ends well. Perhaps it's time to go back and use the application and work on improving what actually hurts the most. Right now, that might be that the copy & paste buffer has a memory limit. So if you try to copy or paste text that is too large, the application will crash. I have to figure out how to extend my arena implementation to allow arbitrarily much memory and how to represent strings spanning over multiple memory chunks. The piece tree might be one solution. But perhaps there are simpler solution for this particular problem. But now I have one more tool in my toolbox.
in #rlworkbench
Ran 9.84 km in 01:00:57 (06:11 /km).
in #linux
Ran 7.33 km in 53:47 (07:20 /km).
Ran 17.26 km in 01:39:01 (05:44 /km).
Ran 5.11 km in 32:10 (06:17 /km).
Ran 10.15 km in 01:01:00 (06:00 /km).
One thing that I find easier in C compared to Python is that loops are not as expensive. And sometimes, things are easier to implement when you can think of them individually.
For example, to render characters with different styles, we can do this in C:
for (index = 0; index < SIZE; index++) { render_character(characters[index], styles[index]); }
This is cheap in C. But in Python, it is expensive. So to make this fast in Python, we might want to do something like this:
for (substring, style) in split_parts(text): render_text(substring, style)
Assuming we can write split_parts without looping over all characters, this will perform better in Python because of fewer loop iterations.
in #c
Modes are only problematic if the current mode is not the user's locus of attention?
A quasimode is more likely the user's locus of attention because the act of pressing and holding a button creates a richer experience that the user is in this mode?
What is Rickard working on and thinking about right now?
Every month I write a newsletter about just that. You will get updates about my current projects and thoughts about programming, and also get a chance to hit reply and interact with me. Subscribe to it below.