Time has come to migrate away from Docker Desktop on my Mac work laptop. Rancher Desktop is one of the usual suggestions, but since it uses a tool called colima underneath, and I really never used the Docker Desktop GUI, might as well go full-on command line. Let’s get started!
Read moretxiki.js 23.1.0 released, and it’s a big one!
txiki.js is a small and powerful JavaScript runtime. It’s built on the shoulders of giants: it uses QuickJSas its JavaScript engine, libuv as the platform layer, wasm3 as the WebAssembly engine and curl as the HTTP client.
After a few months of more work I’m happy to announce a new txiki.js release, version 23.1.0, quite possibly the biggest release I’ve made, and one that paves the way for the future. Let’s dive right in!
Standard library refactor
I’ve actually gone back and forth on this one. The standard library modules started being importable as @tjs/ modules, but I later switched to having it all bundled together in @tjs/stdlib. While easier to work with, that was a mistake. It’s slower to load and the churn due to the bundles being in the repo is just annoying.
It’s also important to look around and see what others are doing. Both Node and Bun seem to have settled in using namespace:module naming for builtins, so that’s what I went with. All standard library modules are now imported like so: tjs:module.
These modules are now documented too, so you can see the full API at a glance.
CLI refactor
The CLI also got some much needed love on this one. Generally speaking the CLI allowed one to either launch a file or eval an expression, plus some modifiers for each. After giving it some though, the idea of using subcommands sounded the most appealing, so now you can do tjs run foo.js and tjs eval ”console.log(42)”
But there is more. There is a also a builtin test runner now so tjs test is a thing too!
Last, running WASI binaries directly was too easy not to do, so you can also tjs run foo.wasm now and it works as expected.
Top level await
Just when I was about ready to cut the release I noticed zamfofex had sent a patch adding top level await support to QuickJS to the mailing list. That was too good to pass so I quickly incorporated it, and it worked beautifully!
This makes writing simple scripts (and tests!) so much more pleasant! So off I went and migrated the test suite to use TLA, the examples too, and added some initial support to the REPL while I was at it!
There is even more!
While these are the highlights, there are a lot more fixes that went into the release. Please checkout the full release notes here.
Migrating an ArchLinux install from an SSD to an NVMe drive
Today I’m going back to the roots of when I started tinkering with Linux. I have recently got a new (old) workstation and I decided to install ArchLinux on a test SSD drive I had lying around. Once I got things working I thought I’d migrate to an NVMe drive, instead of reinstalling. This post describes the process. All of it can be found on the wiki, but since there are many options available, I’m posting the route I took.
Read moretxiki.js 22.11 released with FFI, WebSocket and more!
txiki.js is a small and powerful JavaScript runtime. It’s built on the shoulders of giants: it uses QuickJS as its JavaScript engine, libuv as the platform layer, wasm3 as the WebAssembly engine and curl as the HTTP client.
Today I’m happy to release txiki.js 22.11, which contains a bunch of improvements that have happened during the last few months. Let’s look at some of those!
Read moreReplacing PulseAudio with PipeWire in KDE Neon
For some time now I’ve been running KDE Neon on my desktop Linux machine, and I’m loving it. I love getting the Latest and Greatest KDE features, on top of a boring and familiar distro like Ubuntu LTS.
I’ve been following PipeWire from a distance for a while, and it seemed to be ready for prime time so, after getting some choppy audio from by Bluetooth headphones I thought I’d give it a try.
It’s actually fairly easy, and while I was at it I decided to use a PPA which will allow us to use a more recent PipeWire version.
Without further ado:
sudo add-apt-repository ppa:pipewire-debian/pipewire-upstream
sudo apt full-upgrade
sudo apt install pipewire-pulse libspa-0.2-bluetooth
systemctl --user --now disable pulseaudio.{socket,service}
systemctl --user mask pulseaudio
systemctl --user --now enable pipewire{,-pulse}.{socket,service}
pactl info | grep '^Server Name'
That’s it really. The last command will show something like Server Name: PulseAudio (on PipeWire 0.3.49) confirming you are running PipeWire as your PulseAudio server!
So far, upon switching to PipeWire my audio is no longer choppy and the volume meter is correct (it used to display 100% while clearly not being at 100%), so count me in as a happy PipeWire user.
Introducing txiki.js a tiny JavaScript runtime
njk: powerful templating in less than 1MB
pycares 4 released, mistakes were fixed
pycares is a Python module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously.
Finally, after a long time, I managed to make a new pycares release. Introducing pycares 4.0.0. This is an important one (note the major number change!) here are the most important features from this release:
- Dropped support for Python <= 3.5, the supported Python versions are 3.6-3.9
- Added getaddrinfo()
- Added support for CAA queries
- Updated c-ares to the latest version
- Dropped custom patches from the embedded c-ares library
- Added ability to use the system provided c-ares library
- Refactor automation of the release process and wheel generation and upload to PyPI
I’m looking for help maintaining this module further, if you are interested, please comment here.
While working on this release I had some thoughts and reflections, if you are interested in those come with me in a trip down memory lane.
Read morepycares 3.1.0 released!
Finally back blogging… it’s been a while. Today I bring you a new pycares release: 3.1.0
pycares is a Python module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously.
This release was relatively small, but I’m really happy about the automation work that I managed to do before the release, which should help with making the next releases faster and better.
Thanks to the automation work this release includes binary wheels for Python 3.5-3.8 on Windows, macOS and GNU/Linux.
How is this done? Well, pycares is now using 3 different CIs:
- Travis: runs tests on GNU/Linux and it builds release wheels for all 3 platforms (this las key bit is new!)
- GitHub Actions: runs tests on macOS
- AppVeyor: runs tests on Windows
Thanks to these 3 free services, I couldn’t have done it without them! ❤️ Also huge thanks to Joe Rickerby for creating cibuildwheel it really made this a whole lot easier.
Skookum JS 18.6.0 released!
2 years have passed since the last Skookum JS release, so here we are, with a new release, and (maybe) a new plan.
But first, for those who don’t remember: what is Skookum JS (sjs)?
Skookum JS (or sjs for short) is a simple JavaScript runtime built on top of the Duktape JavaScript engine, with a simple POSIX-y API.
I guess the first question is “what’s with the version number?”. Fair point. I decided to switch to calendar versioning and give it a try, so since we are in June 2018, it’s time for a 18.6.0.
The focus of this release was to add more features and make it more CommonJS-alike, as I mentioned on my previous sjs post, but as time passed I realized I was wrong.
When I designed sjs I got heavily inspired by the runtime I knew the most: Python. This means having a small binary and “native addons” as shared libraries, in addition to a sizeable standard library. That’s all great, but it brings significant trouble because all those need to be in some path which the runtime will query, take (potentially) long time to load, and having multiple versions installed side by side is not easy. By contrast, Node takes the single binary approach: all the native modules needed for the standard library are part of the single binary, and so is the standard library itself. So I decided to do the same.
With this release, sjs is a single binary with all previous native modules embedded, as well as the standard library. I’d like to point out how I went about embedding the standard library, because that was a fun discovery: incbin. Incbin uses assembly to embed binaries into an executable, so that’s how I chose to embed all the JavaScript in the standard library onto the binary? Ugly? Maybe. Does it work? You bet!
sjs remains a toy project I like to hack on every now and then, and it’s now clear to me that my original design was flawed in many levels, so with this release I’m fixing one of those mistakes. Hopefully there will be more to come!
You can check the release notes here, check the code on GitHub, and check the documentation here.