txiki.js 23.10.0 released!

Posted on by saghul Leave a comment

txiki.js is a small and powerful JavaScript runtime. It targets ECMAScript 2020 and implements many web platform features.

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 / WebSocket client.

After a few months of hiatus I’m happy to announce a new txiki.js release: 23.10.0, and it’s a good one!

This new release is packed with new features:

  • Faster startup time
  • New fs features
  • SQLite builtin module
  • Storage web APIs support
  • curl integration fixes
  • Added import.meta.path
  • Better CLI errors
  • Improved types documentation

Check the full changelog here!

This release is particularly exciting because I’ve been looking forward to integrating SQLite support for a while. I started implementing the Storage API support thinking I’d use a file for persistence, but at one point I thought I’d use a SQLite databse instead, so I went for it!

There is likely stuff to be improved specially in this new builtin, the SQLite module, but I’m happy it’s in now!

The last release was over 6 months ago, so please do check the full changelog, I almost didn’t remember all the things that were added in the months past…

Thinking ahead, it might be time to start bringing in Mbed TLS support. Maybe just hasing at first, then TLS sockets, then WebCrypto. Step by step…

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.