Pulsar

Lazuli, beyond Ruby: Python, JavaScript, and Elixir

It’s been a while since I’ve been working on Lazuli – the editor plug-in for Pulsar (and probably VSCode in the near future) where I try to bring the Clojure REPL experience – that is, running code inside your editor and printing the result inside your editor, without having to copy-paste between two different tabs – to other languages.

If you didn’t read the previous post, the TL;DR; is: Lazuli is basically “Chlorine, but for more languages than Clojure”. Ruby was the first target, for two reasons – first, because I decided to go back to the Ruby/Rails stack; and second, because it’s probably one of the easiest languages to implement that on.

Since then, I’ve added support for Python, and I’ve been experimenting with JavaScript and Elixir. Each of them ended up being its own can of worms, and I think it’s worth writing down what I found – because some of the “obvious” solutions turn out not to work at all.
(more…)

By Maurício Szabo, ago

Linux, Wayland, and NVidia.

For some time, I’ve been trying to run my Linux under Wayland. It’s… always complicated. VERY complicated.

I have what people call the “unholy trinity” – Wayland, NVidia GPU (in a laptop to make things worse), and I use an Electron app (Pulsar). Pulsar is my main editor, so it’s basically “the reason I use a computer most of the time” really.

So it was a good surprise when I found out that things work… except…

Gimp.

And Darktable.

These flickered like crazy. And because they are image editors, this flickering is insane – it makes editing things essentially impossible (imagine you’re adjusting brightness and the screen is flickering between darker and lighter, and then stops… in the wrong frame, meaning you have no idea if it’s correct or not). So I tried to track the problem, and I finally have a solution (hopefully). This post will give the results, but the TL;DR; is – update your Linux (Ubuntu 24.04 is the MINIMUM version that you need), update your KDE to at least 6.2 (or use some recent desktop env with good wayland support), don’t use the Open Kernel NVidia driver, and update your Xwayland to at least version 24.0.
(more…)

By Maurício Szabo, ago

Quick Post – Multiple Shadow-CLJS builds at the same runtime

One of the greatest limitations of ClojureScript is how you can’t have two ClojureScript codebases, running on “development mode”, in the same runtime. In the browser, or in Node.JS, this is not a big problem, but it is one in some other situations – like browser extensions (you might be developing two extensions at the same time), node libraries (again, same case) and… well, editor plug-ins for Pulsar, or VSCode.

That… might not be a problem anymore.

If you use Shadow-CLJS (and you should) then you can just change your target to :npm-module (or :esm if you’re in the browser). That will create a lot of files but the important one is cljs_env.js. What this file does, is bootstrap the Google Closure Compiler and make some assignments for Shadow and for ClojureScript namespaces.

In the beginning of the file, you’ll see this line:

var CLJS_GLOBAL = global;
var $CLJS = CLJS_GLOBAL;

Just change it to:

global.some_unique_identifier = {}
var CLJS_GLOBAL = global.some_unique_identifier;
var $CLJS = CLJS_GLOBAL;

And that’s done.
(more…)

By Maurício Szabo, ago

Last open-source improvements

For the last two months, I have been busy searching for a new job, unfortunately. But also, because of this, I was able to evolve on lots of projects that I have been working in a while. So in this quick post I want to explain a little bit what I did, what is happening, and hopefully somebody might be interested in some very interesting improvements.

First thins, I already wrote about Chlorine in my last post. This week I was able to remove all the dead code that I had in the previous version, and I’m closer than ever to publish a new version of that I will call “Version 2.0”. Unfortunately, this version will be lacking some features that the previous version had, and I’m not really sure if I’m going to add this back or not.

But the thing is, because the new Chlorine is more configurable and the config file is easier to write, I hope people can add these features in user-space, so I can decide later if I’ll re-include them or not (it’s always easier to add stuff than remove what people already depend on).
(more…)

By Maurício Szabo, ago

A new Chlorine is almost done!

For the last few months, I’ve been working on a new version of Chlorine (now that Pulsar is on a good track). Here I want to share what to expect of this new version.

For a quick TL;DR; it’ll have better ClojureScript (shadow-cljs) support, fix some bugs related to evaluating code and the REPL being “locked” without returning the results or evaluating new commands, and have better configurable parameters. Things will probably break a little bit – it’s not a non-breaking-change, unfortunately – but hopefully it’s good enough that people will want to migrate to the new version.
(more…)

By Maurício Szabo, ago

Pulsar have a green CI, finally!

After so many months, finally we have a green CI – we can consider pull requests and changes that break the CI as “unstable”. This is a huge milestone, and I want to both thank everybody that tracked these failures to check if they were legit, to the people that fixed the legit failures and that fixed the flaky tests. This has been an amazing experience, and it helps build trust on the project!

If you look at the commits from the Atom project and check which ones have passing tests, you’ll see a horrible situation: they mostly don’t pass. There’s even a recent commit called “disable tests” that passes, and then the next commits also fail – so Atom was already failing tests when these were disabled (how is that possible, I won’t dare to think).

So it’s a huge milestone to have a CI that confidently (or at least we hope!) say if we broke something new! But on this post, I want to show not only how cool is that, but also the process and how to avoid flaky tests on the near future – both for Pulsar and for other projects
(more…)

By Maurício Szabo, ago

The empire built over beach sand

Completely inspired on this post: https://archiloque.net/blog/a-machine-for-gods-jam/, and my experiences with Pulsar.

The Node.JS Ecosystem, together with so many others, is broken. Maybe beyond repair.

Let’s review the foundations of good software: good code, automated tests, a server that checks if the software works (usually called CI Server), a server that publishes the software continuously as soon as everything is working (usually called a CD Server), and reproducibility – meaning, if something fails, it needs to always fail if we send the same parameters, and always fail in the same place in the same way; if it passes, it must always pass on the same condition.

Now, onto Pulsar
(more…)

By Maurício Szabo, ago

HackerNews, Pulsar, and my answer

First things first: I refuse to create an account on HackerNews. It’s honestly one of the most toxic programming communities that I know of. One thing that always come to my mind when somebody links me an article on HackerNews is the phrase:

The person who says it can’t be done should stop bothering the one doing it

Seems that this first phrase was written, without attribution on the “Puck” magazine under a slight different wording and meaning, but I honestly prefer this newer version. Anyway, back to HackerNews, somebody posted about Pulsar on it. And, as always, the comments are mostly negative. This basically triggered me a lot more than I would like, so instead of creating an account and giving them more visibility, I prefer to address these issues on my blog – so I don’t risk being triggered even more when some stupid keyboard warrior writes nonsense on why our work is useless (I told you I got triggered by the comments!).

So, to answer many of the stupid remarks on the site:
(more…)

By Maurício Szabo, ago

Dyson Sphere Around a Pulsar

Well this year has been rough for Chlorine.

Basically, I wanted to keep Chlorine plugin working, but Atom was degrading over time. So, I decided to… make a new editor from the ashes of Atom! Or, basically, reuse the plugins that already had the visual elements, for example, and creates a new thing.

That obviously didn’t go right. The reason is quite simple – in the beginning, the idea was to reuse the fragments and plugins of the Atom, even if I had to depend on internal state because, sure, Atom was stale but at least it was receiving updates and security bumps over time, even when their Electron version was really far from the latest stable.

But then Atom died and I had to make a choice. Either I would keep developing Saturn and give up Atom completely (that was one of my ideas), or I could try to keep a version of Atom that did not have the backend functionality; another option was to change editors, for example, to a NeoVim version that had a webview, and focus on developing Clematis. None of these were ideal, especially because the only NeoVim editor that have a programmable webview is NyaoVim, and that is also dead.
(more…)

By Maurício Szabo, ago