txiki.js 23.1.0 released, and it’s a big one!

Posted on by saghul Leave a comment

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

Posted on by saghul Leave a comment

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 more

txiki.js 22.11 released with FFI, WebSocket and more!

Posted on by saghul Leave a comment

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 more

Replacing PulseAudio with PipeWire in KDE Neon

Posted on by saghul Leave a comment

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.

PipeWire Original Repo

pycares 4 released, mistakes were fixed

Posted on by saghul Leave a comment

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 more

pycares 3.1.0 released!

Posted on by saghul Leave a comment

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!

Posted on by saghul Leave a comment

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.

Streaming a webcam to a Jitsi Meet room

Posted on by saghul 3 Comments

Every so often I see the following question:

How can I stream a webcam to a Jitsi Meet room?

Wait, isn’t this just like “joining” a room? Not quite. One may want to have some dedicated contraption streaming a webcam to a room. Think of a homemade security camera system or something alike.

This probably gets asked for other WebRTC conferencing services too. The way I see it, there are 2 ways to go about it:

  • Buid a way (on the server) to accept a stream sent with ffmpeg or gstreamer, and broadcast that.
  • Use a browser.

I know what you’re thinking: “Saúl, running an entire browser is overkill!”. Maybe. It will consume more RAM, yeah, but I argue the dominating factor here is video capture and encoding, not JavaScript execution, the DOM and other shenanigans.

Also, when all you have is a hammer, everything looks like a nail.

With the advent of headless mode in both Chrome and Firefox, this option looks more enticing than ever, so let’s roll our sleves and give it a shot.

I’m going to use Google’s puppeteer library, which runs Chrome headless to join a Jitsi Meet room. Being a headless client, we can cut down some of Jitsi Meet’s features in order to reduce the required resources:

  • No need to receive video
  • Disable simulcast (only encode video once)
  • No audio levels

I could probably add some more, but those should be enough to make a difference. The astute amongst you may think “but Saúl, disabling simulcast means every streamer will send an HD stream, I can’t cope with so many!”. Great point! Here we are going to rely on adaptivity, so no need to worry, if the client can only receive a single HD stream, the rest will be suspended, but you can switch between them just fine!

Here is the code (I also got to play with async / await for the first time, which is pretty cool):

https://gist.github.com/saghul/179feba3df9f12ddf316decd0181b03e

My original intent here was to use some inexpensive (and not very powerful) device such as the Raspberry Pi, but alas puppeteer doesn’t yet support ARM devices 🙁

Happy streaming!