Why did you shut it down? Was the stream of incorrect tweets too much for it to handle?

These kinds of error-correcting / "grammar nazi" bots are very popular on Reddit. They also seem to get banned from many subreddits, perhaps because many people find the corrections condescending or that they break the flow of conversation. On Twitter it would be different, though, as unlike what happens on Reddit, Twitter threads don't really get to see all the replies listed... so it'd be pretty easy to ignore such bots.

Yeah, I think this highlights another thing: people only have so much free time to dedicate to each community and project, and thus will choose to spend the most time on the stuff they find most rewarding. I would love to have time to participate more actively in CodeWalrus, Cemetech, open source projects I have contributed to like Haiku OS and Sming, participate in more discussions on Reddit and Hacker News, perhaps visit my old friends at the FreeVPS forum once in a while, post more on the Lisbon subway thread at SkyscraperCity, engage more with my Twitter circle, post more on my blog, work at least a couple hours a week on Clouttery, finish the home automation projects I have had going on for years and, on top of all this, keep pursuing my master's degree, keep working on UnderLX, keep maintaining my servers and other websites so they don't go down and aren't breached, play computer games and, last but not least, spend more time with my family and friends.

Even if my days had 240 hours I'm not sure I would have enough time to do all of this. Note that I only listed the things that I find enjoyable and would love to do more often (and I probably forgot some) - I completely skipped over the chores, which also take quite a lot of time, and stuff like eating, sleeping and staying healthy. Of course, people will prioritize activities in their life, and once they have some time free for doing whatever they want, they will naturally choose the activities they instinctively find most appealing/rewarding at that moment, and choose to spend time with the communities they find more interesting or that are more closely related to those activities.

What does this mean for CodeWalrus? I means that, somehow (I have no idea how), if we want to see more activity here, we must become a more appealing/rewarding community for a larger set of people, from existing members to people who find us by chance or are invited here. Personally, I think maintaining an healthy chat/Discord component is very positive, because that way the community appeals to two different kinds of interaction: both real-time, short-lived, mobile-friendly interaction in the form of chat messages, and slow-paced, long-form interaction in the form of forum posts. Many of the subreddits I subscribe to have a Discord server, and I am in some of them (although I rarely if ever look at them, because, again, my days don't have 240 hours). These servers don't seem to have reduced the amount of posts in the respective subreddits (at most, they reduced the amount of low quality posts and offtopic), and thus I believe it's entirely possible to keep an active CodeWalrus forum and an active CodeWalrus chat (which already has a very good thing going for it, which is the fact that it is bridged across multiple services, making it easier for anyone to use their preferred platform).

I think graphing calcs are much less of an appealing platform for development and for teaching programming than they were a decade ago.

- Recent models are more restrictive than ever in order to comply with new exam regulations, and in some countries said regulations have done away with graphing calculators entirely;

- A decade ago, when we weren't in "everyone has a smartphone"-era, calculators were the only affordable and relatively common handheld platform where development could be made on the device itself. Nowadays, everyone who buys a graphing calculator most likely also has a smartphone. Naturally, people wonder "how can I make smartphone apps and games?" before they even wonder "how can I build calculator games?". I think you all agree that a smartphone offers way more possibilities while still having the handheld form factor (just think of all the I/O of a smartphone that is missing on most calculators: sensors, radios, speakers...), with the plus of being so much more commonplace (which is very appealing for beginners who are heavily motivated by the fact that billions of people will be able to play their game/use their app). As for programming on-the-go, you can write scripts and run them on a smartphone, or even compile code, and you get to use a (small) QWERTY keyboard and not an awkward calculator keyboard;

- People looking to play with embedded systems programming, for example because they find the idea of developing software for machines with few resources appealing, there's all the IoT stuff (from RasPis to Arduinos to ESPs) which is way more beginner-friendly than any calculator platform (and has the benefit of appealing to people who like to tinker building physical, hardware stuff), and there are also all the retro game consoles and handhelds, like the Gameboy;

- "But you can't bring a smartphone to exams!" I got into Prizm development largely because of the appeal of "cheating" on tests. I never really "cheated" much but I must say it was quite appealing to be able to run my own code, my own software, in a context where you are supposedly deprived of much computing aid. However, going back to my first point... new exam regulations mandate the introduction of exam modes and similar stuff which makes it notably more difficult to run your own stuff during exams - to the point where doing so would definitely, beyond any doubt, be considered cheating and one would face serious consequences if caught. If I was buying a graphing calculator today, with the new regulations in place, I would most likely never have much interest in building software for it;

- Most tech depreciates and becomes a commodity over time. Again, smartphones: you can find models at any price point from $50 (or less!) to $1000+. However, graphing calculators have, for the reasons we all know about, kept their prices (or even slightly increased them!) unless you buy used. The fact that calcs are perceived as being an expensive thing makes people fear "breaking" them, and sometimes with good reasons (yes, I, too, have bricked my Prizm once...). And they are not just any "expensive item", they are something you need for school and thus can't afford to go without. This obviously disincentivizes exploration of the calculator platforms.

Now, if you don't mind, some thoughts on forums as a discussion medium. Some months ago, I posted this lengthy post at Cemetech. Much of what I said there was specific to the Cemetech topic in question and Cemetech itself, but there are some thoughts there that apply to any forum:

QuoteI feel that since a few years ago, with the rise of discussion platforms more similar to Reddit, Hacker News, StackExchange, etc., as well as with more and more discussion taking place behind walled gardens like Facebook, there are fewer people interested in participating in a "traditional" forum like Cemetech. (I frequent other "traditional" forums and even used to be a moderator at one, and this is something that affects all kinds of forums.) Some communities also started centering more and more around real-time chat services like Slack and Discord. For example, often you'll see that a project on GitHub uses their issue tracker, and besides that, discussion takes place on Slack. Another example: for UnderLX, I'm using a Discord "server" as the only place for discussion, posting changelogs, etc.
I don't participate in them, but I also know there are large communities around programming languages, frameworks, etc. on Slack.

Personally I spend a lot of time on Reddit and Hacker News. However, these types of websites are not good for long-form, ongoing project discussion (for example: on Hacker News, you can do a "Show HN" about your project, and receive feedback, but there's really no way to keep a discussion going on for weeks/months as the project evolves). I think this is one thing Cemetech excels at: a place for people to post development logs of their projects and discuss them in an ongoing fashion that can be easily be read from any point (unlike IRC, Slack or Discord, which as Alex mentioned are hard to catch up to after a few weeks or even days). But for it to be worth posting about a project at Cemetech, there has to be an audience. In this sense, you may become stuck in a catch-22: nobody posts projects because there are not enough people participating; nobody participates, because there are not enough interesting projects.

Finally, I think the graphing calculator communities have always suffered from a serious fragmentation problem, which has become especially acute in the past few years as (due to the reasons I mentioned above) the amount of people participating and the amount of discussion decrease. As much as I hate saying this, because I really like how each community has its own style and quirks, there are too many communities for a topic that is more niche than ever. If I were the king in the world of graphing calculators, I would be forcing a merger, like any sane CEO would. Since that is not possible, perhaps not even desirable, then I "prescribe" Codewalrus exactly what I "prescribed" Cemetech: that you (we) work towards making this a community around discussing and supporting each others' projects and other topics that interest us, and maybe leave graphing calculators in our past, and try to avoid "drama" at all costs. "Drama" confuses newcomers and makes them feel like they don't belong. I have observed this over and over again in multiple forums, including some where I was staff for quite a long time.

That the Windows client sometimes stops opening is a known problem I never got around to fixing. It's because the local database (not written by me, I'm using an apparently buggy library) gets corrupted. To fix it, delete the file C:\Users\<username>\AppData\Local\Apps\2.0\Data\<something.xxx>\<something.xxx>\clou..<something>\Data\batterylog.dbs and try opening Clouttery again (this only makes it forget local battery history, settings and etc. are kept).

The "business model" of Clouttery is something that was never set in stone, hence why it is still free (and probably will always have a free plan) and that's why I prepared its billing system to deal with both one-time payments and discounts, as well as recurring payments (subscriptions) and discounts.

I don't consider Clouttery to be a failure, I was just a bit tired of working on it when I began working on my other project over a year ago (and I never planned for that one to take more than a month to complete... but, as I explained, it got a bit out of control after unexpected popularity and traction). At any moment, I can resume working on Clouttery more intensively as opposed to just looking into it for emergency bug fixes (fortunately, that has been rare). And if I decide to make it open source, that doesn't necessarily mean I have given up on developing it, or given up on any "business model".

Clouttery, in its current state and the way it is presented now, is only appealing to a handful of people with very specific needs - for example, people like me, who own quite a few models of phones for software testing, and don't want to ruin the batteries of these phones. However, one of the things Clouttery was set out to do, but is currently very far from achieving, was to cater to enterprises by providing ways to manage fleets of devices - not just consumer electronics, but more specialized stuff such as those PDAs with barcode scanners you see on supermarkets and warehouses. In these contexts, Clouttery could work alone, or as part of a more complete device deployment and management system, and the idea would be to work with the clients to develop semi-customized solutions (that is, take the common Clouttery core and adapt it to each client's needs).
I, and some of the people I've talked to, agree that's where the real money is, as (like you pointed out) it will always be quite hard to get the masses interested in paying for Clouttery.

I wish you luck with your projects too

EDIT: I forgot to mention, but just a few days ago, I renewed the clouttery.xyz domain for two years. Now, it will only expire in 2020. I think this is a solid proof that Clouttery is here to stay.

As you might have noticed if you actually use it, Clouttery keeps working as well as it ever did. Back in September, I talked about open-sourcing Clouttery as if it was something I was about to do very soon. Months have passed, and it didn't happen yet... but I'm happy to announce that today, I finally found some time and motivation to work on Clouttery again.

The work I've done moves the last remaining big obstacle out of the way, which was to rewrite the dotAccount authentication code so that it no longer relied on a mess of PHP code and instead used a proper library, in the same language as the Clouttery server and built into it. I did not want to release the source of Clouttery as long as the PHP bridge was used, because it relied on quite a lot of security through obscurity. Now that the server uses something proper, I'm closer than ever to being able to open source Clouttery - both the server and the clients. However, I'm still not entirely sure I want to do it.

The reason is simple: I had the opportunity to talk about Clouttery (or in entrepreneur lingo, "pitch Clouttery") to a few people who have relevant experience in the area of bootstrapping projects like these and turning them into real businesses. Most of these people found the idea to be great and agreed that it's realistically possible to make the subscription model work and have people pay monthly for something like this, especially if the service is extended to support most of the features I initially planned and which are yet to be implemented. In this sense, I might not want to open source the code. I'll see, over the following months, if I feel like working on this ever again or not, and decide whether to open-source it or not.

As for my other project, UnderLX... you have no idea what happened. In November we were featured in national media for the first time. Since then, we have been featured in over ten online news sites, from tech news sites to "mainstream news" sites, and we were interviewed four times - and I'm talking about full-length interviews here. Here are some of them (in Portuguese): 1, 2, 3.
The UnderLX Android application now has over 3500 active users and it doesn't seem like it will ever stop growing. I honestly never expected so much exposure and success from a silly app for public transit. Hopefully this lets you understand why Clouttery has been basically dead for almost a year, and also why I'm not ever going back to developing software for calculators - at least, not as a hobby.

Shutting down the service is very much out of the equation, as it is not really that demanding to run and I need the servers for other projects anyway (like UnderLX).

With this said, I've been lucky that the increase in price of Bitcoin has been sufficient to allow me to keep paying for servers and domains, as I have no means of income. The advertising in tny.im really doesn't pay out much if at all, it pays at most for 10% of the price of running my "online empire".

Hello everyone again. I figured it was time for an update, even though this is not exactly a "happy" update, at least as far as Clouttery is concerned. This is a long post, bring it to bed so you can fall asleep to it if you wish, but trust me, it's worth reading. I hope you can learn a thing or two about managing your side projects, from reading about my mistakes.

Last school year was the last year of my undergrad course (and I'm starting a second cycle course in a couple weeks) and this required some more effort, so I had less time for side projects. As often happens when one works on something for an extended period of time, I too gradually lost interest in this project.

To make things more... interesting, in mid-March I launched a small website that was meant to be kind of a practical joke about the unreliability of the Lisbon subway (for those who haven't yet figured it out, I'm Portuguese). You'll be able to understand what it is about by checking out its repo on GitHub.
I started that project mostly to have something different to work on that was not Clouttery, and the original plan was for it to be something I'd build in a few weeks, publish and then forget, for it to be yet-another-small-thing in my portfolio. But to my surprise, after minimal "marketing" on the SkyscraperCity Portuguese community, that has a section dedicated to railways and subways, my website received a lot more attention than I was expecting, especially for something so simple and tongue-in-cheek.

I then understood there was a real interest in a service that would let people work-around the problems in the Lisbon subway, while at the same time denouncing the problems with the service (for example, by collecting independent statistics). Long story short, a small community assembled around this project, which ended up evolving into an Android app called UnderLX that's even published on Google Play. And there's still a lot of work to do for it to become the product I envisioned.
This obviously took most of my summer.
Yes, it's true that, unlike Clouttery (for which I had even written a complete billing system from scratch!), I'll never be able to monetize UnderLX effectively. However, it is way more satisfying to work on, at least until I get saturated of it too. With Clouttery, it often took a while to realize what it was about, and let's be honest: the final reaction of many people was just "meh". However, with UnderLX, people tend to pay a bit more attention, and those who understand the whole potential of the project usually become much more involved in it. "Unfortunately" for me, the technical side of it is more complex than Clouttery.
It also has an "advantage" to my eyes: both the client (Android app) and the server are open-source from the first day. I regret not going this route with Clouttery; now I have lots of closed-source code which I can't easily show to anyone because, well, it's in private repos. I'll go back to this point, later.

Finally, to add to the school work, the gradual loss of interest, this happy accident that was UnderLX, there's a fourth factor in all this. Because of multiple reasons including the astronomical rise of the price of Bitcoin, it made economical sense to fulfill a long-time desire of mine: to build a desktop, so I could have a powerful machine, more powerful than my six-years-old laptop. Picking parts and putting it together was very enjoyable, and now I have a proper workstation like I had been dreaming of for the past couple years. If you are interested I might even post a thread about it here. I wasn't much into PC gaming before (in part, because the hardware didn't really allow for it), but... you see... to sum things up, many hours were spent chilling to some great triple-A titles (thanks Steam summer sales!...).

That's all really nice, but I thought this topic was about Clouttery?
Work on Clouttery gradually slowed down through the last months of 2016, subject to how busy I was with school, and pretty much completely halted in March this year, as I got more and more tired of working on it, so I decided to do that "small" subway thing. It also didn't help that I was going through a complex phase with Clouttery, more specifically regarding the Windows and Linux clients.

• I couldn't get the Linux client to work right, despite trying to develop it from scratch multiple times using different languages and technologies.
  Spoiler

  story of clouttery for nix
  
  1. python + tkinter
  2. go + libui
  3. go + gotk3 (gtk3 bindings)
  4. Mono + gtksharp (for gtk3)
  5. Python + gtk3
  6. go + gotk3 (gtk3 bindings)

  [close]
  No matter what I tried, there were always major roadblocks to getting it to the point I wanted. I did not want to write it in C or C++; I hate Python but decided to try using it anyway - didn't end well; UI framework bindings for Golang are apparently all terrible, or don't have a suitable license. Mono would have been a viable choice, but the gtksharp bindings were tricky to get to work, they apparently had to be recompiled for each GTK version (meaning I couldn't simply distribute a single binary), and the bindings for GTK3 aren't/weren't exactly ready for prime-time. Ugh, I don't even know what all the problems were anymore. I do remember that I just wanted to write code, but problems with libraries and bindings and whatever were always getting in the way.
• The UI of the Windows client suffers from major lag and other problems, so I decided to switch from WinForms, which is no longer supported, to the supported and way more modern and flexible alternative: WPF. But this was taking a lot of time, certain things were much harder to get to work than I expected, it didn't help that I only had time to work on it like one hour at a time (school work, etc.), and I lost more and more interest.

For you to get an idea of how inactive this project has been, these are the dates of the latest commits to Clouttery repos:

• Server: 2017-07-10 (and this was only to fix a bug with notification filtering; previous "real" work on it had been on the 23rd of March)
• Windows client: 2017-03-26
• Android client: 2016-12-29
• Chrome client: 2016-09-08
• Linux client: 2017-03-09

Earlier, I mentioned I regret not open-sourcing Clouttery from the beginning. I decided to work on it privately, because it was supposed to become a commercial service, and I feared that if I made it possible for people to host their own Clouttery servers and recompile the clients to talk to it, then nobody would pay for the service. This is obviously a stupid way of thinking, especially when the project in question is a personal project of a student that doesn't have much time to work on it, and likely would never be able to get it to a commercially-viable state. If the service was worth it, I guess most people would happily pay for it, just to not have the hassle to figure out how to make the server and clients work for themselves; this is especially true since the target audience wasn't exactly software developers nor sysadmins, i.e. it was people who wouldn't have a clue how to do that nor would bother even if they were given clear and easy instructions.

Right now I have 30K lines of code, possibly more, that's closed-source, but for no good reason. To aggravate things, Clouttery shows more of my abilities in software development and engineering than any of my open source projects, because it contains code in more languages, for more platforms, than any other of my projects; it includes web design, API design, use of cryptography, etc. It is not the most beautiful code (for example, the UnderLX Android app has much cleaner and organized code than the Clouttery client, and even then it's not exactly stellar), but it works, and definitely shows what I'm capable of.

This whole situation is even more ridiculous, because right now there's very little to no code in Clouttery that's "novel" to the point of requiring intellectual property protection. At this point, Clouttery is extremely dumb, as I never got to work on the "intelligence" that would involve machine learning, pattern matching and the like. And in the end, if I wanted to make my super-awesome-and-courageous battery level prediction and damage identifying algorithms secret, I could always have added them as a closed source module while keeping the "infrastructure" open source.

Finally, I always told people that if I were to stop working on Clouttery, I would release its source code. I don't know what you think, but if I half-close my eyes and look from far away... yeah... like that... yep, I definitely stopped working on it.

Then why don't you open source Clouttery?

I definitely want to open source Clouttery, so I can show its code to more people, and so that others may eventually try to pick up on the project. I intend to keep running the official Clouttery server - if for no one else, for me, as my family finds Clouttery useful. I think I would be a little sad if someone took the project and simply changed its name and started running their own "official" service, available to the masses and possibly profiting from it, so I'll see what kind of licensing restrictions I can add to prevent that. Without the help of a lawyer, it's a bit hard to add clauses to existing software licenses or write new ones from scratch; even with legal help, it's easy to get to a controversial result - for example, Facebook has that famous problem with the "patents" file on their open source projects, like React.

...so why didn't you do it already?
Because ideally, I'd like to publish the source code with the complete commit history. The problem is that, in the past, secrets (API keys and the like) have been committed to the repos. If I remember correctly, the latest server code no longer has that problem - keys are read from a separate, uncommitted file and no longer stored in the source code, but going back in history the secrets are still there. Some of these secrets are hard to revoke and replace, and I'll need to go on an individual basis to see what can be done about them. Furthermore, the clients also contain secrets in their repos, but this is just one secret per client that's used to authenticate the client before the server, and since it's relatively easy to get these secrets from the binaries anyway, I might just go and make them public anyway - their only purpose is to stop people from using the official server with unofficial clients, but if the whole thing is going to be open source, that doesn't make much sense. These secrets are not involved in securing the pairings between clients and user accounts, so in terms of user account security, there's no problem with publishing them.

I also need to write a bit of documentation explaining essential things about each repo, and ideally also explaining how to run the server, what needs to be in the database, etc. Or I could not care about any of that, and just have people figure it out by themselves - at that point, I make it hard for people to contribute, but at least people can already look at the code, which is much better than the current situation.

As you can imagine, all this takes time and effort, and I've been busy with all those things I mentioned in the first section. But with classes starting very soon, I'd like to get this going ASAP, or it's not going to be done for some more months.

Did I "give up" on Clouttery too soon?
Is it a good idea to open source it, even if in the distant future I decide to turn it into a proper commercial service?
Do you agree it would have been better if it were open source from the beginning?
What license do you think would be most adequate? - don't forget the server and each client can have different licenses.
Would you be interested in submitting pull requests for this project, perhaps even taking over one of the sub-projects or the whole thing?
Share your thoughts.

An update to the image viewer has been released. The g3a works on all Prizm models.

For Eigenmath, I don't know what to do and I've given up for now.

critor says the image viewer appears to be fixed, but Eigenmath is crashing and causing system instability.

In the interest of the public, here's a copy of the email I just sent him, as it summarizes the situation very well.

----
I have bad news. I can't reproduce the problem on the previous model, neither on the emulator nor on real hardware, and I can't do it on the emulator for the new models, no matter which mode is selected.

I also have little idea of what could be causing the crashes and general instability. Only thing that comes to mind is if they changed the RAM areas in size or the way they are supposed to be initialized. But that doesn't explain how other add-ins run so well.

It could also have something to do with one user timer that the add-in installs (and carefully uninstalls when it's supposed to), to be able to abort computations. Maybe tomorrow I'll send you a build that doesn't install any timers, to see if that fixes the problem. Maybe Casio broke the timer API, or the timer system entirely, with the new OS. I don't think it's a functionality that official add-ins use.

I might give this problem some more hours of attention tomorrow, but failing the timer idea, I'm afraid this can't be fixed unless the OS change that causes the problems is identified. I don't own one of these calculators and since the emulator is significantly different, it makes everything very hard. I have also lost all familiarity with the code of my Eigenmath port, which was never exactly a miracle of software engineering to begin with. In fact, I lost familiarity with lots of quirks of the Casio syscalls. So things take a lot of time and effort as I need to restudy everything.

Is the PC and target always the same?

At least the image viewer appears to be fixed.

And unfortunately, unlike earlier versions of the fx-CG10/20 manager, I have not been made aware of any registry hacks for the newer emulators.

If you use PlayOnLinux you can always create a new virtual disk (Wine config) every time the 90-day trials expire, though. This is what I used to do...
For Windows I'm not sure if there's any sandboxing tool that will allow for something like that.

I think in the longer run it'd be best to get an open-source alternative going on so we can stop pretending we didn't read EULAs.

Yes, they will work on previous versions as well. But you don't need to test that, as the emulator does an OK job and I already checked.

@critor, I sent you test builds. If everything works fine then the only thing left to do is to tag the git commit, rebuild them so the version strings gets updated, and upload them to the various places on the internet where I originally uploaded them.

Icons will stay in the fx-CG 10/20 style for now. I hope someone works on a solution to automatically and safely swap the icon on the first run, so separate builds for different models are not needed. Given the trouble previous Prizm OS versions had when writing or otherwise manipulating g3a files from add-ins, I'm not hopeful...

OK, fortunately if I manage to fix Eigenmath I can also fix the Image Viewer very easily. It's just a matter of getting to my old development environment, if it still works. Perhaps later today I'll be able to do that.

That's sad. It means the emulator OS diverges from the OS running on real hardware even more than with the fx-CG10/20. It's probably a good time for someone to resume working on a QEMU-based emulator, or to figure out a way to run OS images on the official emulator that are closer to what runs on real hardware. Fortunately I don't intend to develop anything else for this platform other than one-off fixes like this.

Can you check if my image viewer still runs fine on real hardware for both JPEG and PNG?

I am aware of that and I've seen the issue that was opened in the Eigenmath GitHub.

I have also identified the problem, in fact I did so some months ago. The VRAM address is hardcoded. Utilities doesn't have this problem, as it reads the VRAM address using the appropriate syscall when it starts, caching that address to RAM and using it for custom VRAM manipulation functions from then on. Eigenmath uses a hardcoded address for these custom functions, which is why on some calculators the graphics are glitched.
It appears that the Graph 90+E uses a different VRAM address than the fx-CG50 (since on the emulator for the latter at least, the add-in doesn't show any problems).

I also know how to fix this in terms of code, it's a matter of reusing the solution from Utilities.
Now, you may think that the problem is basically solved as the steps that are usually 90% of the work are done (identifying the problem and drafting a solution). The problem is that I no longer have a Prizm development environment on any of my machines. And it's a bit tricky to set one up.
First, I need a custom mkg3a (because the add-in has a eActivity strip, and vanilla mkg3a doesn't have support for that) and I'm not sure I still have the source code to that custom mkg3a anywhere.
Second, I need to use my fork of libfxcg (this is not very hard).
Third, if I recall correctly there are some library shenanigans regarding the C math functions. I'm not sure but I think Eigenmath was the add-in where I had to use a library frankensteined from miniSDK or whatever that terrible libfxcg alternative was called.
Finally, ideally I'd like to use the same 4.x GCC I used before, as a long long time ago I tried GCC 5 and 6 without success. It appears that at the time these versions of GCC had some problem emitting code for the Prizm SH4 CPU architecture. It's probably fixed by now, or the problem might be in my code, or in libfxcg, after all. But I don't want to waste time figuring that out.

I'll see if I can boot the Linux install I supposedly still have on the hard disk I used to have on my laptop. That's supposedly where I had the environment I used to develop Eigenmath and Utilities.
This will take a while though, and there's a chance I'll have to fight bitrot, and that's why I haven't started yet. Furthermore, fixing Eigenmath is obviously not the only thing I had postponed to the summer and there are more urgent things in my to-do list.

@critor, how do you prefer I send you builds for testing?