• without daylight savings time
• with daylight savings time

The way I'm naïvely imagining using this:

• Scroll to the timezone you know the time in.
• Click on the nearest hour.
• It'll highlight that column all over the page.
• Scroll or find the timezone you care about.
  • If you're not in a whole-number timezone (Hello India), you'll need to do some additional mental arithmetic by comparing nearby rows.

That's it. Since it's almost entirely static, you can always be sure that you're seeing the same thing on this page as anyone else.

Unfortunately you need to know if you're in daylight savings time or not, something that is often beyond me. I'm not sure what to do about that without reintroducing dynamism that takes the current computer's time into account. Then I again end up wondering if others are seeing what I'm seeing.

There are a few abbreviations for America, Europe and Australia in both pages. You can see *ST and *DT on either page, which might help if you're not observing daylight time yet, but someone else is. There's a tension here between trying not to be overwhelming and emphasizing the Western or Northern hemisphere. My thinking is to only add codes for longitudes with lots of cities or with daylight savings time. Hopefully people in Bhutan or Nigeria or the Chatham Islands won't hold it against me.

Inspired by Bret Victor, but of course the inevitable mistakes are all mine. ]]> http://akkartik.name/post/2024-10-26-devlog 26 Oct 2024 10:20:27 PDT http://akkartik.name/post/2024-10-26-devlog back into teaching kids programming 1:1. Of course, this time using Lua, LÖVE and Carousel. After a couple of months, it occurred to me to collect all my little impromptu puzzles and exercises into a single app anyone can go through on their own schedule.

Carousel Cards (LÖVE app, really just a zip file containing source code, 169KB)

Nowhere near done yet. But it has 50 112 little "levels", each taking between a few seconds and a minute. A full game/curriculum might need 2000 levels or something.

Inspirations:

• The Hour of Code
• Microban
• Sheepolution

• Inserting/deleting text before a range moves it.
• Inserting/deleting text after a range leaves it unchanged.
• Inserting/deleting text within a range grows/shrinks it.
• Deleting text at a boundary shrinks the range, and deletes it when it becomes empty.
• Inserting text at boundaries can't disambiguate whether I want the text within or outside the boundaries. But I can grab some handles on the range to adjust.

The final complexity cost was 200 lines but it was a non-linear path getting there. I started out with the notion of pivots from my doodle app. There, pivots live inside the data structure for a single line of text. Since ranges now need two pivots that could be on different lines, I had to move them out. I started tracking pivots in a separate data structure, maintaining bidirectional mappings between pivots and their locations, and then tracking ranges as combinations of pivots. This quickly blew up the implementation to 500 lines, and I was juggling 27 manual tests of which half were failing.

The next day I started from scratch and threw out the notion of pivots entirely. Now I just maintain 2 locations directly inside each range, and linearly scan through them all for any book-keeping. The implementation dropped to 200 lines and the tests passed fairly quickly.

Earlier this year I threw out an implementation after suffering with it for 2+ years. It feels like I'm getting the hang of this programming thing that I threw out an implementation now after just 2 days. I'm setting a higher bar for elegance. At the same time, it's interesting that my instinct remains as poor as ever for the right approach in even a slightly new problem. Here I spent a lot of time trying to squeeze my ranges into lines so that deleting a line would transparently delete ranges within it. But I blindly assumed a fully normalized design with a first-class notion of a pivot must be a good idea.

As I linked to in the previous post, this app was inspired by this comment by Alex Kladov about how Emacs maps ranges of text to attributes. ]]> http://akkartik.name/post/2024-10-18-devlog 18 Oct 2024 10:19:02 PDT http://akkartik.name/post/2024-10-18-devlog Potluck and the Emacs model of text augmented with attributes for ranges. Potluck describes 3 mechanisms:

1. extracting data using (regex) patterns
2. performing computations on that data
3. showing results of computation as annotations

My notebook app does simple variants of 2 and 3, and replaces 1 with explicit in-document markup.

Now I'm playing with another approach to 1. I already have the idea of pivots from my doodle app. Putting two of those pivots together should yield a range that adjusts in intuitive ways in the presence of edits. An example may be a WYSIWYG UI for adding a hyperlink to some text:

• Inserting/deleting text before a range moves it.
• Inserting/deleting text after a range leaves it unchanged.
• Inserting/deleting text within a range grows/shrinks it.
• Deleting text at a boundary shrinks the range, and only deletes the attached attributes if the range becomes empty. This makes ranges more robust to deletion than my doodles which attached to a single pivot.
• Inserting text at boundaries can't always do what you want. I imagine it'd be nice to have handles that you can drag to adjust a range.

The fine print: to switch directions I have to fill in the right blank, clear the old blank, and then type in something outside the old blank (to indicate I'm not going to type further into the old blank).

Works better if I clear the old query first, but who can remember that?

I've decided to just recompute on every keypress and mouse click. It seemed unnecessary, but now I see that there's some benefit from the inefficiency. ]]> http://akkartik.name/post/2024-10-07-devlog 07 Oct 2024 17:33:44 PDT http://akkartik.name/post/2024-10-07-devlog Ways I've previously seen text coexist with a canvas:

• A fixed background that is disconnected from text.
• Fixed page boundaries.

I'm instead using the game engine idea of a pivot. Any time I toggle into doodle mode I have to first pick a pivot from one of the characters on screen. All my drawings are relative to that pivot, and edits to text maintain pivots alongside.

Displacements to the pivot are preserved in font-derived units, so it looks "reasonable" as you resize the font.

Deleting a character deletes all drawings pivoted on it. (But there's undo.)

This took 200 lines, so not too much though it was more than I'd initially expected.

Inspired by this thread. ]]> http://akkartik.name/post/2024-10-06-devlog 06 Oct 2024 16:17:35 PDT http://akkartik.name/post/2024-10-06-devlog the notebook fills blanks

Blanks can be filled in either with the results of computation or with what a person typed in. Now we indicate such conflicts in two ways.

• Blanks filled in from computations get a distinct look (the cyan background), separate from both hand-written (black on white) and computed, non-editable text (cyan on white)
  
• If I manually edit a blank, its background changes, and any code that was overridden doesn't execute. Here are a couple of examples:

  
  

But perhaps the color choice is too strong:

]]> http://akkartik.name/post/2024-10-04-devlog 04 Oct 2024 21:29:52 PDT http://akkartik.name/post/2024-10-04-devlog A notebook with tabs that live-update as you edit.

The sort of interaction I live for: someone wished something existed, and it gave me a great deal of pleasure to manifest it. ]]> http://akkartik.name/post/2024-10-02-devlog 02 Oct 2024 09:27:25 PDT http://akkartik.name/post/2024-10-02-devlog

Repo ]]>