Article by figosdev

Summary: "I don't love the idea of trying maybe Tk instead. But Tk is at least responsible enough not to keep selling themselves to an aggressive monopoly that hates software freedom."

This story is more about GitHub than it is about fig, but I use fig more than anything else I've ever written -- it's basically my reference implementation of a language for teaching.

Because of this, I like it to set an example for all my other projects; whether they follow the example or not.

Fig goes back to version 0.4, it was always based on CPython, the standard and most conventional implementation of Python -- for fig 3.x it switched to Python 3.

"I hate when languages break a lot of things, as if nothing made previously with them matters."Each stage of fig was an experiment, though I rely on it and I've tried to keep it as stable as possible. I hate when languages break a lot of things, as if nothing made previously with them matters. In an industry, that makes enough sense. For hobbyists, that really sucks sometimes.

I use fig for both serious purposes (at the moment I've got a fig program running for 48 hours on a dedicated machine, processing over a million files) and for fun. I've enjoyed tinkering with graphics since I was a kid. Fig is what I use for that.

But for dealing with various kinds of files, Python 2 suits my purposes. After years of checking on options and tricks, I did my utmost to make fig Python-3 compatible, as an experiment. Fig really leans on the way that strings are expected to work in Python. I've gone through many tutorials, run 2to3, maybe you can make a language based on fig that uses Python 3. Have fun with that.

I have fig 3.x a serious chance -- I used it almost exclusively for half a year. After that I was working on a serious project and fig 3 started mishandling a file, I ran it with Python 2 instead and it worked better for my purposes.

"I use fig for both serious purposes (at the moment I've got a fig program running for 48 hours on a dedicated machine, processing over a million files) and for fun."That's why fig jumped right ahead to 4.x, the most recent version of which (until today) was from late 2017.

If Pygame is not installed, fig falls back on escape sequences -- it draws in the term instead. It's designed specifically to have fewer than 100 commands; I created an experimental (quite nice) "figplus" to try some new things. I'm still very happy with standard fig; the main features figplus adds are extra Pygame features and some neat handling of Python dictionaries. Both allow inline Python in fig programs, so you can define fig functions that access dictionaries as well.

Years ago I created a simple hack with inline Python to access the 16-colour palette (fig uses foreground/background 0-15/0-15, based on the CGA palette) and allow fig to do 24-bit colour without adding commands. I decided for many reasons I preferred this hack to making it a feature of fig -- but I made it a native feature in figplus:

function rgbcolor r g b
python
    figcgapal[0] = (r, g, b)
    fig
    fig

This changes colour 0, so the next time you draw it will use whatever RGB settings you like. You can change it back to 0, 0, 0 after that if you want.

I made four changes to the stable version of fig for the latest, and each change is related to GitHub:

1. Pygame is gone, even as an optional feature. This is a protest, if someone wants to fork fig to keep Pygame I'd be happy to help them do it. It's simple enough that they probably won't need it. The change is backward compatible -- commands that only did something when Pygame was installed, now do nothing even when it is. No code changes should be needed.

2. PyPy 2 is now used instead of CPython. This was likely to happen anyway, because the Python Foundation wants to force a language I don't care about. I knew a guy that worked at Nokia who felt the same way, but there are plenty of sound technical treatises on why strings are broken in Python 3. Don't agree? Then use what the Python Foundation tries to shovel at you -- most people do.

"...not only am I not interested in Python 3, it is also developed on Microsoft GitHub."However the reason is two-fold; not only am I not interested in Python 3, it is also developed on Microsoft GitHub. PyPy is not, and I hope it never will be. People who have Python 2 installed on the GNU operating system that want to continue to use it with fig only need to make a symlink; I'm not judging. If you have trouble with a symlink, copying your Python executable to something called pypy2 may help.

3. The arropen command already worked in both CPython and PyPy. However, PyPy doesn't close files read with .read() as I think it ought to, which means that after reading about 1000 or so files with arropen, PyPy complains about too many open files. It shouldn't be necessary, but fig 4.9 caters to PyPy by opening and closing files even when arropen uses .read(). As I said, the command works in both implementations. What's changed is that arropen should now work more reliably when under heavy use in PyPy.

4. I didn't just remove Pygame support, I tried to add something to make the GitHub boycott a little more fun. The hack that allows 24-bit colour in Pygame is now supported in text mode. If you don't include the hack in your program, figcgapal doesn't get modified (it can only be modified with inline Python; fig doesn't support identifiers that start with "fig") and fig does escape output the way it did before, with esc[0 or 1;(30 or 40 plus f)m.

"The screencap is also a jpeg, even though png would be better for this purpose. The reason is symbolic; png relies on zlib1g, which is on GitHub."If you use the hack, it changes the contents of figcgapal and fig uses esc[38;2;r;g;bm instead. This is designed to be compatible with existing code that uses the hack; fig now checks figcgapal against a copy that's made when the original is set. This was done in haste, and 4.8 is GitHub-free but the 24-bit feature didn't work until it was fixed (along with arropen) in 4.9, maybe 30 minutes later.

The screencap has fig 4.9 doing 24-bit output based on unmodified code, but I haven't tried it with a lot of code yet. The screencap is also a jpeg, even though png would be better for this purpose. The reason is symbolic; png relies on zlib1g, which is on GitHub.

Very few people have any idea just how much everybody is relying on GitHub right now. Although it may not be possible to get away from it (or Microsoft) completely, and removing Pygame from my favourite programming language may seem ridiculous, I don't think it's nearly as ridiculous as putting all our free software eggs in Microsoft's giant basket. We need to Delete GitHub. If it turns out that we can't do it entirely, we should at least consider our options. I'd rather sacrifice Pygame than use a canvas that Microsoft controls.

"Very few people have any idea just how much everybody is relying on GitHub right now. Although it may not be possible to get away from it (or Microsoft) completely, and removing Pygame from my favourite programming language may seem ridiculous, I don't think it's nearly as ridiculous as putting all our free software eggs in Microsoft's giant basket."To the Pygame devs: I love SDL (I love DOSBox! Which probably still uses SDL, but did when I created fig). I never preferred to use anything other than Pygame for fig graphics. I don't love the idea of trying maybe Tk instead. But Tk is at least responsible enough not to keep selling themselves to an aggressive monopoly that hates software freedom. I figure any graphics will likely pull in libffi (GitHub) though you're developing there directly. Please reconsider your reasons for this! Don't sell out your users to the GIAFAM trap.

Long Live Stallman, and happy hacking. ⬆

Licence: Creative Commons CC0 1.0 (public domain)