It’s amazing what a few million tokens can do. I had to give my agent access to a webcam so it could debug the screen driver and after about 30 minutes of flickering screens and garbled updates it got something that is pretty much usable
It boots but, is currently too slow to be useful. The keyboard works as does the touch interface.
Newton OS 2.x running natively without emulation on a Remarkable Paper Pro!
It still needs a lot of work, but it is coming along
I have been playing around with Claude and last week set it the task of fully reverse engineering the Apple Newton 2100 ROM with the eventual goal of re-targeting it to run on any other host operating system. The results have been nothing short of miraculous. I have it running happily on my desktop machine and so far, every piece of Newton software I have thrown at it just works.
Along the way it discovered some interesting things. There are several easter eggs in the handwriting recognition, and from my searching around only one of them is widely known.
| write it three times | and you get |
|---|---|
larryy | The Doctor is on. |
Larry | larryy@apple.com |
Mondello | Fine food 408/257-2383 |
Brandyn | brandyn@brainstorm.com |
Rosetta! | Hey, that’s me! |
stafford | bill |
Les | lesv@angeltech.com |
lyon | Richard |
Currently it runs on both Windows and Linux and eventually I’d like to get it running on my Remarkable Paper Pro
This evening, I noticed that an application running in a cluster of machines I look after was behaving oddly. It was using huge amounts of RAM and then crashing. What made this even more unusual was the fact that the code was written in Elixir and had been in production use for several years without any issue.
I looked in the server logs but could not see anything out of the ordinary, so I connected to the remote Elixir console and poked around a bit. In the end I came up with a nice little code fragment to find processes that are using lots of memory and produce a stack trace to help with tracking down the issue.
Process.list() |> Enum.map(fn p -> {p, :erlang.process_info(p, :memory)} end) |> Enum.filter(fn {pid, {memory, v}} -> v > 10000000 end) |> Enum.map(fn {pid, {_, m}} -> {pid, m, pid |> Process.info(), pid |> Process.info(:current_stacktrace)} end)
With the output from the above line in hand fixing the issue was fairly simple 🙂
My poor little Nabaztag rabbit is feeling the heavy weight of years. Modern WiFi means it is having trouble connecting to newer access points so I need another solution. With that in mind I decided to have a go at replacing the guts with something a little more modern and the ESP32 sounded perfect. I’ve gotten the firmware to compile and run on the the ESP32 but it needs more RAM for it to be fully functional. The ESP32 WROOM modules don’t have enough but the WROVER modules should be pleanty big enough. Hopefully once my WROVER module arrives I should be able to continue the development.
I just got myself a nice new Makita 18v drill. It’s really nice 🙂
On thing about my battery operated tools I’ve noticed is that I tend to have one battery in the device and another charging. Since I don’t used them very often they batteries tend to degrade after a while, so I was thinking I could use the battery in something that I would run often to keep the battery in a nicer condition. It occurred to me that I have a pair of old Roomba’s in the shed that are just sitting there because the batteries are dead. What if I could use a cordless drill battery instead? I got a Makita battery adapter on Ebay and sacrificed one of the dead Roomba batteries to allow me to connect the two up. Now the interesting thing is the Roomba batteries are 14.4v and the Makita battery is 18v so I was expecting a bang and some smoke, but the Roomba seems to like the new batteries! I’ve since done some reading and apparently there is a version of the Roomba called the Create that can be run on 12 AA batteries. That would be the equivilent of 18v so it looks like the Roomba is built to take these kinds of voltages. I’ve yet to let the Roomba run through a full cycle as it is kind of noisy, but maybe later…
I’ve been running Macintosh machines for quite some time as my primary development environment. Recently I’ve been having to spend a lot of my time running Windows for my work and I’m finding it a lot less painful than I thought I would. Windows 10 has vastly improved over Windows 8 (although the bar was set very low on that on).
The Windows Subsystem for Linux makes doing a lot of things that were tricky under Windows in the past much easier. There are a few applications like Omnigraffle that I miss and I’ve yet to find an email client that feels right, but the thing I’m missing the most is my own QueryThing application that I’ll release for MacOS one of these days. There are many database query tools available for Windows but none of them works quite the way I want to work.
Now all I have to do is rewrite QueryThing to be a cross platform tool and I’ll be happy wherever I have to code 😉
Today I spent quite a bit of time trying to get ASDF to find my local packages on my Windows development machine. It turns out that since ASDF 3.1.5 the place to put the config files has moved. Now the config file needs to be placed in $HOME/AppData/Local/config/common-lisp/source-registry.conf.d/
There’s a couple of hours of my life I’m never getting back 😉
Yesterday I spent a couple of hours playing with Common Lisp and OpenGL. It’s been a while since I’ve had a chance to play like this and I had a good time. I really need to do it more often 😉
I’ve been watching the CEPL videos on youtube for a while and wanted to give it a go and since I’ve gotten this lovely new HP 840 to work with it seemed like now was a good time to make it do something other than run Oracle database VMs.
The results of my efforts are here.
