live demo
As far as I know this is the first Haskell program
compiled to Webassembly (WASM) with mainline ghc and using the browser DOM.
ghc's WASM backend is solid, but it only provides very low-level FFI bindings
when used in the browser. Ints and pointers to WASM memory.
(
See here for
details and for instructions on getting the ghc WASM toolchain I used.)
I imagine that in the future, WASM code will interface with the DOM by
using a
WASI "world"
that defines a complete API (and browsers won't include Javascript engines
anymore). But currently, WASM can't do anything in a browser without
calling back to Javascript.
For this project, I needed 63 lines of (reusable) javascript
(
here).
Plus another 18 to bootstrap running the WASM program
(
here).
(Also
browser_wasi_shim)
But let's start with the Haskell code. A simple program to pop up
an alert in the browser looks like this:
-# LANGUAGE OverloadedStrings #-
import Wasmjsbridge
foreign export ccall hello :: IO ()
hello :: IO ()
hello = do
alert <- get_js_object_method "window" "alert"
call_js_function_ByteString_Void alert "hello, world!"
A larger program that draws on the canvas and generated the image above
is
here.
The Haskell side of the FFI interface is a bunch of fairly mechanical
functions like this:
foreign import ccall unsafe "call_js_function_string_void"
_call_js_function_string_void :: Int -> CString -> Int -> IO ()
call_js_function_ByteString_Void :: JSFunction -> B.ByteString -> IO ()
call_js_function_ByteString_Void (JSFunction n) b =
BU.unsafeUseAsCStringLen b $ \(buf, len) ->
_call_js_function_string_void n buf len
Many more would need to be added, or generated, to continue down this
path to complete coverage of all data types. All in all it's 64 lines
of code so far
(
here).
Also a C shim is needed, that imports from WASI modules and provides
C functions that are used by the Haskell FFI. It looks like this:
void _call_js_function_string_void(uint32_t fn, uint8_t *buf, uint32_t len) __attribute__((
__import_module__("wasmjsbridge"),
__import_name__("call_js_function_string_void")
));
void call_js_function_string_void(uint32_t fn, uint8_t *buf, uint32_t len)
_call_js_function_string_void(fn, buf, len);
Another 64 lines of code for that
(
here).
I found this pattern in Joachim Breitner's
haskell-on-fastly and copied it rather blindly.
Finally, the Javascript that gets run for that is:
call_js_function_string_void(n, b, sz)
const fn = globalThis.wasmjsbridge_functionmap.get(n);
const buffer = globalThis.wasmjsbridge_exports.memory.buffer;
fn(decoder.decode(new Uint8Array(buffer, b, sz)));
,
Notice that this gets an identifier representing the javascript function
to run, which might be any method of any object. It looks it up in a map
and runs it. And the ByteString that got passed from Haskell has to be decoded to a
javascript string.
In the Haskell program above, the function is
document.alert. Why not
pass a ByteString with that through the FFI? Well, you could. But then
it would have to eval it. That would make running WASM in the browser be
evaling Javascript every time it calls a function. That does not seem like a
good idea if the goal is speed. GHC's
javascript backend
does use Javascript FFI snippets like that, but there they get pasted into the generated
Javascript hairball, so no eval is needed.
So my code has things like
get_js_object_method that look up things like
Javascript functions and generate identifiers. It also has this:
call_js_function_ByteString_Object :: JSFunction -> B.ByteString -> IO JSObject
Which can be used to call things like
document.getElementById
that return a javascript object:
getElementById <- get_js_object_method (JSObjectName "document") "getElementById"
canvas <- call_js_function_ByteString_Object getElementById "myCanvas"
Here's the Javascript called by
get_js_object_method. It generates a
Javascript function that will be used to call the desired method of the object,
and allocates an identifier for it, and returns that to the caller.
get_js_objectname_method(ob, osz, nb, nsz)
const buffer = globalThis.wasmjsbridge_exports.memory.buffer;
const objname = decoder.decode(new Uint8Array(buffer, ob, osz));
const funcname = decoder.decode(new Uint8Array(buffer, nb, nsz));
const func = function (...args) return globalThis[objname][funcname](...args) ;
const n = globalThis.wasmjsbridge_counter + 1;
globalThis.wasmjsbridge_counter = n;
globalThis.wasmjsbridge_functionmap.set(n, func);
return n;
,
This does mean that every time a Javascript function id is looked up,
some more memory is used on the Javascript side. For more serious uses of this,
something would need to be done about that. Lots of other stuff like
object value getting and setting is also not implemented, there's
no support yet for callbacks, and so on. Still, I'm happy where this has
gotten to after 12 hours of work on it.
I
might release the reusable parts of this as a Haskell library, although
it seems likely that ongoing development of ghc will make it obsolete. In the
meantime, clone the
git repo
to have a play with it.
This blog post was sponsored by unqueued
on Patreon.
Yesterday I tagged a new version of onak, my OpenPGP compatible keyserver. I d spent a bit of time during DebConf doing some minor cleanups, in particular an annoying systemd socket activation issue I d been seeing. That turned out to be due completely failing to compile in the systemd support, even when it was detected. There was also a signature verification issue with certain Ed225519 signatures (thanks Antoine Beaupr for making me dig into that one), along with various code cleanups.
I also worked on Stateless OpenPGP CLI support, which is something I talked about when I released 0.6.2. It isn t something that s suitable for release, but it is sufficient to allow running the OpenPGP interoperability test suite verification tests, which I m pleased to say all now pass.
For the next release I m hoping the OpenPGP crypto refresh process will have completed, which at the very least will mean adding support for v6 packet types and fingerprints. The PostgreSQL DB backend could also use some love, and I might see if performance with SQLite3 has improved any.
Anyway. Available locally or via GitHub.
Man, you re no longer with us, but I am touched by the number of people you have positively impacted. Almost every DebConf23 presentations by locals I saw after you, carried how you were instrumental in bringing them there. How you were a dear friend and brother.
It s a weird turn of events, that you left us during one thing we deeply cared and worked towards making possible since the last 3 years together. Who would have known, that Sahil, I m going back to my apartment tonight and casual bye post that would be the last conversation we ever had.
Things were terrible after I heard the news. I had a hard time convincing myself to come see you one last time during your funeral. That was the last time I was going to get to see you, and I kept on looking at you. You, there in front of me, all calm, gave me peace. I ll carry that image all my life now. Your smile will always remain with me.
Now, who ll meet and receive me on the door at almost every Debian event (just by sheer co-incidence?). Who ll help me speak out loud about all the Debian shortcomings (and then discuss solutions, when sober :)).
It was a testament of the amount of time we had already spent together online, that when we first met during MDC Palakkad, it didn t feel we were physically meeting for the first time. The conversations just flowed.
Now 
Man, I still get your spelling wrong :) Did I ever tell you that? That was the reason, I used to use AR instead online.
You ll be missed and will always be part of our conversations, because you have left a profound impact on me, our friends, Debian India and everyone around. See you! the coolest man around.
In memory:
Official logo of DebConf23
Suresh and me celebrating Onam in Kochi.
Four Points Hotel by Sheraton was the venue of DebConf23. Photo credits: Bilal
Photo of the pool. Photo credits: Andreas Tille.
View from the hotel window.
This place served as lunch and dinner place and later as hacklab during debconf. Photo credits: Bilal
Picture of the awesome swag bag given at DebConf23. Photo credits: Ravi Dwivedi
My presentation photo. Photo credits: Valessio
Selfie with Anisa and Kristi. Photo credits: Anisa.
Me helping with the Cheese and Wine Party.
This picture was taken when there were few people in my room for the party.
Sadhya Thali: A vegetarian meal served on banana leaf. Payasam and rasam were especially yummy! Photo credits: Ravi Dwivedi.
Sadhya thali being served at debconf23. Photo credits: Bilal
Group photo of our daytrip. Photo credits: Radhika Jhalani
A selfie in memory of Abraham.
Thanks to Niibe Yutaka (the person towards your right hand) from Japan (FSIJ), who gave me a wonderful Japanese gift during debconf23: A folder to keep pages with ancient Japanese manga characters printed on it. I realized I immediately needed that :)
This is the Japanese gift I received.
Bits from the DPL. Photo credits: Bilal
Kristi on GNOME community. Photo credits: Ravi Dwivedi.
Abhas' talk on home automation. Photo credits: Ravi Dwivedi.
I was roaming around with a QR code on my T-shirt for downloading Prav.
Me in mundu. Picture credits: Abhijith PA
From left: Nilesh, Saswata, me, Sahil. Photo credits: Sahil.
Ruchika (taking the selfie) and from left to right: Yash, 
Joost and me going to Delhi. Photo credits: Ravi.
Our new proposal with Kevin s super awesome management company has been submitted and we will hopefully hear back next week.
Thanks for stopping by! Till next week.
If you can spare some change, consider a donation
Thank you!
I very, very nearly didn t make it to DebConf this year, I had a bad cold/flu for a few days before I left, and after a negative covid-19 test just minutes before my flight, I decided to take the plunge and travel.
This is just everything in chronological order, more or less, it s the only way I could write it.
If you got one of these Cheese & Wine bags from DebConf, that s from the South African local group!
Some hopefully harmless soldering.
And another half-written article I had in my repo. (Am I doing #FallFinishAlong with blog articles instead of / in addition to craft projects? it feels so).
I was in need of snacks. I wanted something bready, but with a bit less carbs and more proteins. I had a bag of chickpea flour.
Ingredients were:
Some time ago our LUG bought some things from soldered.com and while browsing around the website my SO and I decided to add a junk box to the order and see what we would get.
Other than a few useful things, there were two mostly unpopulated boards for the inkplate 10 which would have been pretty hard to reuse as electronics.
On the other hand, at 23 cm 18 cm they are a size that is reasonable for a book, and the slit near a long edge made them look suitable for the cover plates of a coptic bound book.
Since the size isn t a 
And then I only had to sew the book, which was done mostly while watching the 
And a couple of days later, trim and sand the pages, which as usual I could have done better, but, well, it works.
The next time I do something like this I think I will have to add a couple more mm also to the height, to be able to trim also those edges.
And now of course the Big Question is: what should I dedicate this notebook to? Will I actually use it? This year? This decade?
You can also see it in:
This post describes how to handle files that are used as assets by jobs and pipelines defined on a common gitlab-ci
repository when we include those definitions from a different project.
TPMs contain a set of registers ("Platform Configuration Registers", or PCRs) that are used to track what a system boots. Each time a new event is measured, a cryptographic hash representing that event is passed to the TPM. The TPM appends that hash to the existing value in the PCR, hashes that, and stores the final result in the PCR. This means that while the PCR's value depends on the precise sequence and value of the hashes presented to it, the PCR value alone doesn't tell you what those individual events were. Different PCRs are used to store different event types, but there are still more events than there are PCRs so we can't avoid this problem by simply storing each event separately.
QNAP TS-453mini product photo
The logo for QNAP HappyGet 2 and Blizzard s StarCraft 2 side by side
Thermalright AXP120-X67, AMD Ryzen 5 PRO 5650GE, ASRock Rack X570D4I-2T, all assembled and running on a flat surface
Memtest86 showing test progress, taken from IPMI remote control window
Screenshot of PCIe 16x slot bifurcation options in UEFI settings, taken from IPMI remote control window
Internal image of Silverstone CS280 NAS build. Image stolen from 
Internal image of Silverstone CS280 NAS build. Image stolen from 
NAS build in Silverstone SUGO 14, mid build, panels removed
Silverstone SUGO 14 from the front, with hot swap bay installed
Storage SSD loaded into hot swap sled
TrueNAS Dashboard screenshot in browser window
The final system, powered up
Daniel Knowles Carmageddon: How Cars Make Life Worse and What to
Do About It is an entertaining, lucid, and well-written manifesto
(to borrow a term from the author) aiming to get us all thinking a bit
more about what cars do to society, and how to move on to a better
outcome for all.
The book alternates between historical context and background, lived
experience (as the author is a foreign correspondent who had the
opportunity to travel), and researched content. It is refreshingly free
of formalities (no endless footnotes or endnotes with references, though
I would have liked occassional references but hey we all went to school
long enough to do a bit of research given a pointer or two). I learned
or relearned a few things as I was for example somewhat unaware of the
air pollution (micro-particle) impact stemming from tires and brake
abrasions for which electronic vehicles do zilch, and for which the
auto-obesity of ever larger and heavier cars is making things
much worse. And some terms (even when re-used by Knowles) are clever
such bionic duckweed. But now you need to read the book to
catch up on it.
Overall, the book argues its case rather well. The author brings
sufficient evidence to make the formal guilty charge quite convincing.
It is also recent having come out just months ago, making current
figures even more relevant.
I forget the exact circumstance but I think I came across the author
in the context of our joint obsession with both Chicago and cycling (as
there may have been a link from a related social media post) and/or the
fact that I followed some of his colleagues at The Economist on
social media. Either way, the number of Chicago and MidWest references
made for some additional fun when reading the book over a the last few
days. And for me another highlight was the ode to Tokyo which I
wholeheartedly agree with: on my second trip to Japan I spent a spare
day cycling across the city as the AirBnB host kindly gave me access to
his bicycles. Great weather, polite drivers, moderate traffic, and just
wicked good infrastructure made me wonder why I did not see more
cyclists.
I have little to criticize beyond the lack of any references. The
repeated insistence on reminding us that Knowles comes from Birmingham
gets a little old by the fifth or sixth repetition. It is all a wee bit
anglo- or UK-centric. It obviously has a bit on France, Paris,
and all the recent success of Anne Hidalgo (who, when I was in graduate
school in France, was still a TV person rather than the very successful
mayor she is now) but then does not mention the immense (and well known)
success of the French train system which lead to a recent dictum to no
longer allow intra-Frace air travel if train rides of under 2 1/2 hours
are available which is rather remarkable. (Though in fairness that may
have been enacted once the book was finished.)
Lastly, the book appears to have 