Valhalla's Things: Conference Talk Timeout Ring, Part One
Tags: madeof:atoms, madeof:bits
A few ago I may have accidentally bought a ring of 12 RGB LEDs; I soldered
temporary leads on it, connected it to a CircuitPython supported board
and played around for a while.
They we had a couple of friends come over to remote FOSDEM together, and
I had talked with one of them about WS2812 / NeoPixels, so I brought
them to the living room, in case there was a chance to show them in
sort-of-use.
Then I was dealing with playing the various streams as we moved from one
room to the next, which lead to me being called video team , which lead
to me wearing a video team shirt (from an old DebConf, not FOSDEM, but
still video team), which lead to somebody asking me whether I also had
the sheet with the countdown to the end of the talk, and the answer was
sort-of-yes (I should have the ones we used to use for our Linux Day),
but not handy.
But I had a thing with twelve things in a clock-like circle.
A bit of fiddling on the CircuitPython REPL resulted, if I remember
correctly, in something like:
import board
import neopixel
import time
num_pixels = 12
pixels = neopixel.NeoPixel(board.GP0, num_pixels)
pixels.brightness = 0.1
def end(min):
pixels.fill((0, 0, 0))
for i in range(12):
pixels[i] = (127 + 10 * i, 8 * (12 - i), 0)
pixels[i-1] = (0, 0, 0)
time.sleep(min * 5) # min * 60 / 12end, especially since I
wasn t sure whether I wanted to run it at the beginning of the talk with
the full duration or just in the last 5 - 10 minutes depending of the
length of the slot, but I ve had at least one person agree that the
general idea has potential, so I m taking these notes to be able to work
on it in the future.
One thing that needs to be fixed is the fact that with the ring just
attached with temporary wires and left on the table it isn t clear which
LED is number 0, so it will need a bit of a case or something, but
that s something that can be dealt with before the next fosdem.
And I should probably add some input interface, so that it is
self-contained and not tethered to a computer and run from the REPL.
(And then I may also have a vague idea for putting that ring into some
wearable thing: good thing that I actually bought two :D )
Dear Debian community,
this is bits from DPL for January.
Sovereign Tech Agency
I was recently pointed to Technologies and Projects supported by the
Most of my Debian contributions this month were
For many years I wished I had a setup that would allow me to work (that is, code) productively outside in the bright sun. It s winter right now, but when its summer again it s always a bit. this weekend I got closer to that goal.
TL;DR: Using 
Passively lit coding
DeepSeek R1, the new entrant to the Large Language Model wars has created quite a splash over the last few weeks. Its entrance into a space dominated by the Big Corps, while pursuing asymmetric and novel strategies has been a refreshing eye-opener.GPT AI improvement was starting to show signs of slowing down, and has been observed to be reaching a point of diminishing returns as it runs out of data and compute required to train, fine-tune increasingly large models. This has turned the focus towards building "reasoning" models that are post-trained through reinforcement learning, techniques such as inference-time and test-time scaling and search algorithms to make the models appear to think and reason better. OpenAI&aposs o1-series models were the first to achieve this successfully with its inference-time scaling and Chain-of-Thought reasoning.
Internationalization support in Picolibc
There are two major internationalization APIs in the C library:
locales and iconv. Iconv is an isolated component which only performs
charset conversion in ways that don't interact with anything else in
the library. Locales affect pretty much every API that deals with
strings and covers charset conversion along with a huge range of
localized information from character classification to formatting of
time, money, people's names, addresses and even standard paper sizes.
Picolibc inherits it's implementation of both of these from
newlib. Given that embedded applications rarely need advanced
functionality from either these APIs, I hadn't spent much time
exploring this space.
Newlib locale code
When run on Cygwin, Newlib's locale support is quite complete as it
leverages the underlying Windows locale support. Without Windows
support, everything aside from charset conversion and character
classification data is stubbed out at the bottom of the stack. Because
the implementation can support full locale functionality, the
implementation is designed for that, with large data structures and
lots of code.
Charset conversion and character classification data for locales is
all built-in; none of that can be loaded at runtime. There is support
for all of the ISO-8859 charsets, three JIS variants, a bunch of
Windows code pages and a few other single-byte encodings.
One oddity in this code is that when using a JIS locale, wide
characters are stored in EUC-JP rather than Unicode. Every other
locale uses Unicode. This means APIs like wctype are implemented by
mapping the JIS-encoded character to Unicode and then using the
underlying Unicode character classification tables. One consequence of
this is that there isn't any Unicode to JIS mapping provided as it
isn't necessary.
When testing the charset conversion and Unicode character
classification data, I found numerous minor errors and a couple of
pretty significant ones. The JIS conversion code had the most serious
issue I found; most of the conversions are in a 2d array which is
manually indexed with the wrong value for the length of each row. This
led to nearly every translated value being incorrect.
The charset conversion tables and Unicode classification data are now
generated using python charset support and the standard Unicode data
files. In addition, tests have been added which compare Picolibc to
the system C library for every supported charset.
Newlib iconv code
The iconv charset support is completely separate from the locale
charset support with a much wider range of supported targets. It also
supports loading charset data from files at runtime, which reduces the
size of application images.
Because the iconv and locale implementations are completely separate,
the charset support isn't the same. Iconv supports a lot more
charsets, but it doesn't support all of those available to
locales. For example, Iconv has Big5 support which locale
lacks. Conversely, locale has Shift-JIS support which iconv does not.
There's also a difference in how charset names are mapped in the two
APIs. The locale code has a small fixed set of aliases, which doesn't
include things like US-ASCII or ANSI X3.4. In contrast, the iconv
code has an extensive database of charset aliases which are compiled
into the library.
Picolibc has a few tests for the iconv API which verify charset names
and perform some translations. Without an external reference, it's
hard to know if the results are correct.
POSIX vs C internationalization
In addition to including the iconv API, POSIX extends locale support
in a couple of ways:
With all the recent buzz about 
Becoming a 
I keep saying I'm "done" with my 
I watch a lot of films. Since completing the