About a month ago, I mentioned I'd been building a scripting language named Languish. I've decided to rename it Yall. The main idea of Yall is to have a scripting language that is easy to use and learn, while having all of the features built in one would expect in a modern language. One thing I've been working on a lot is the error handling and exception system. In my opinion, this is one of the most important pieces of a language and most languages simply fail to implement a decent error handling system.
For instance, why is there ever an uncaught exception? Yall assumes that each code block, function, and method is able to throw or catch an exception. There's no need for a try-catch. If an exception propagates outside of the user code, then it is caught by a global catch, which can be configured with user code exception handlers or error types. In the user code, you can specify catch and throw as part of the return statement (or individually). There's no need for a try-catch.
Catch statements can also retry with another function, a new code block, or a loop back retry statement, which allows you to re-run that block of code or function with default or updated parameters or state. In addition to the traditional, immutable, error object, there is also a context object, which gives you a mutable object inside the exception system to define however you please.
The last thing, for error handling, I've been working on is a special kind of type for errors. These types define or structure the error handling and can be extended. I haven't worked out all of the details yet, but the idea is most of the error handling should be handled by the types assigned, and then you can supplement that, if needed, in the user code, but there should never be an unhandled error or uncaught exception, because they get handled by the interpreter if nowhere else.
I completely agree with Pate on this one.
I spent some time tonight working on the next version of Grazie!, which will be 0.7. Following my redefined roadmap, the major change is the update from Remix to React Router 7. That is mostly complete. I've also done some bug fixes and added some missing features: added delete functionality for Posts and Pages; fixed a bug where editing a Post didn't display the categories list; Pages now display status, if they are a draft, and an edit button; the Tumbleweed Snapshots feature has had a few display fixes and its feeds (RSS, Atom, & JSON) now also list the latest snapshot.
Some of the features I'd planned for 0.8 may come in 0.7 instead. This is mostly because 0.8 will, hopefully, use Rsbuild, and that looks like more of an undertaking than I initially expected. Rsbuild is working on a react-router-plugin, so that will be a lot of help, but it's not released yet. My intention is to fork that plugin to become a zulu-plugin, but Grazie! doesn't necessarily need to be running on Zulu for 0.8. I'd rather build up Zulu on the side and switch to it once it has matured some.
With that in mind, I'll probably do a few more fixes and update the main branch to 0.7, then build onto it a few incremental versions, on the way to 0.8. I would like to improve the Notes and there's also the Theme system updates and a Blocks system planned. The latter two will be transformational, as they add some very convenient features. I also want to add an RSS reader, image galleries, and auto-save.
Zulu is a server-side rendered framework for React. What makes Zulu different from other frameworks is it uses Rsbuild for its build tool/support libraries, Biome for linting and formatting, and the React Router 7 framework for routing, and it doesn't use Vite. Initially it will use Mantine for UI, for my own purposes, but I plan to provide templates, or at least a barebones version, people to choose their UI.
I personally feel this combination of tools provides a lot of functionality, so Zulu itself is actually very small, as it relies mostly on its core dependencies. It also provides a fairly straight forward migration from Remix 2 and React Router 7 framework. This is by design, as I use Remix for my personal and professional projects. The main difference between Zulu and React Router 7 framework is it doesn't use Vite and it uses a custom server built on node:http. I plan to experiment with other server options, but so far node:http has been more than adequate.
The real powerhouse behind Zulu is Rsbuild, which is blazing fast, and just very good all around. I really don't understand why more projects aren't using Rsbuild. In fact, Rsbuild was the initial step that got me to build Zulu in the first place. It's just not being used that much and it's almost silly how fast and flexible it is. A friend of mine, who generally uses SPAs, seemed quite impressed with the build speeds we are seeing in Zulu.
You can already fine Zulu in my public github repositories, if you want to take a peek. It's very much experimental and will probably be unstable until I can build up some decently sized test cases. I'm currently using it to replace React Router 7 framework (Vite) in the dev branch of Grazie!.
I think all of those names are taken, in one form or another. I'm mostly kidding anyway. But in all seriousness, I have a beginning of what could be the new base for Grazie! and potentially ATF. It works like Remix, but it doesn't use Remix, it uses React Router 7, but doesn't need Vite, it's server-side rendered, and it builds with Rsbuild. It also uses Mantine for the UI and, so far, just works. It has a few rough patches. It currently only has the production server and it's using node:http. I plan to work on the dev server next, preferably using the dev server that comes with Rsbuild.
It hasn't been easy to figure out all of the pieces. It seems not a lot of people are trying something like this. I'm not entirely against sticking with node:http for the server. I'd prefer express or maybe fastify, but it's not a deal breaker yet. I definitely want to use Rsbuild. I'd probably be happiest if someone could make a remix/react router plugin for Rsbuild, but from what I can tell all attempts at that have failed. I have been learning a lot about how Remix works internally, so maybe I could do it eventually, but I'm kinda liking the path I'm on at the moment.
The purpose of Grazie! is to have a CMS that can be used on multiple web sites, without having to start from scratch each time. It's still moving in that direction, it's not perfect for that yet, but that's where I want to get. The goal is to have Grazie that provides a reusable, stable base, and then you can extend that or override it.
Remix has been ok for the CMS piece. Unfortunately, everything I've tried with the Vite Dev server in the later versions of Remix 2 or React Router 7 has been atrocious. It's unusable as a dev server, as far as this code base goes. The production server is fine in React Router 7, but I've put too much time trying to figure out the dev server and I'm not doing it anymore. I'd rather do something else that may or may not work, either one still feels more productive.
So here's the new and amended plan:
I want to use rsbuild as my build tool.
I want to use Express server for production and rsbuild for my dev server.
I'm willing to use React Router 7 as the router, but it's losing it's luster for me.
I'll consider using Tanstack router, if it checks all of the boxes.
That's it for now. I think that's doable and then I can carry on with the more important stuff from there.
Since updating earlier, the site has had some performance issues due to Remix 2.15 and npm sucking. We had updated ESLint and npm installed the newer Remix 2 with Vite, which I do not have configured and never planned to install. I, unfortunately, had to revert that ESLint update and we are now back on the better Remix 2 version without Vite. I'm seriously reconsidering even using React Router 7 with Vite.
I've updated this site to the "latest" version of Grazie. It's now caught up with the main branch, which I'm calling 0.6. The actual latest is 0.7, which is the React Router 7 migration, but it's not ready yet. That branch isn't in the repo yet. I'll probably tag 0.6.0, as it is the last Remix 2 build, and 0.8.0, as it will be the first beta. 0.7 will be the beginning of a new dev branch in the repo.
I can't remember if I'd mentioned it before, but I've built a parser and page to track Tumbleweed snapshots. It'll be in the next site update, which should be sometime this week, I think. There will also be feeds for other sites to use. The Tumbleweed page will display what snapshot you are on, if you are using Tumbleweed, and there's a diff viewer to show package changes between the current snapshot and the past snapshots.
I haven't updated the Grazie versions in a while, so when I merge the React Router changes, I'll call it 0.7.x. Version 0.8 will have the new theme system updates, which will be a pretty big shift, and then 0.9.x will be betas and RCs.
I am not at all happy with the way the react-router dev server works, which is just vite dev. It is very slow and is basically only useful for error messages. I've put in a stop gap with nodemon and the production build/serve, which is much better, but not entirely useful as a dev server. I'm still trying to get it figured out. Unfortunately, it's the reason I hadn't migrated much sooner, even to newer Remix versions, because the dev server is just terrible.
I still have a few updates to do in the react router migration, mostly dealing with how route components changed from Remix 2, and tweaking the routing in general. It runs really well on the production server, I just want to get those few things cleaned up.
I'm not sure how much time I'll have to work on it this week, but I'd like to get this site updated with the last Remix 2 version of Grazie. I'm trying to decide if I want to launch ProfoundGrace.org with the Remix 2 version or wait and merge the React Router version into it first. It may be easiest to wait for the changes planned for 0.8.0.
Speaking of 0.8.0, my plan for it is to add a site folder outside of app, but I'm still trying to decide on the exact structure. The idea is to have the core Grazie app and then site specific stuff in the site folder, like theme, routes, and components. This makes it easier to build different sites which Grazie and makes merging upstream changes easier. I'm also thinking about dropping PostgreSQL support. Allora will have a better database alternative to SQLite, so I don't really see the point in having PG in Grazie!. It's not changing for now, but is a possibility.
I had planned to stay on Remix 2, without Vite, for a little longer, but some initial tests went well. I've rebuilt Grazie! to run on React Router 7 Framework, which is the equivalent of what would have been Remix 3. This means we get React 19 support and Vite. The latter, I'm not super impressed with. I kinda hate the Vite Dev server. It's super slow, compared to the Remix Dev server. I've tried a few things to speed it up, but I can't believe it wants to download every package file as a chunk on every refresh. That just doesn't make sense, plus it's non-responsive for a good 10 seconds after a restart. It has to be, something, not entirely correct, but I haven't figured out what, if that is the case.
The good news is the production server runs fine, so I've decided to press on. The big changes planned for February are, obviously, the RR 7/Vite migration, and then I plan to restructure the way themes and overrides work. Currently, you can override a page/layout, based on the loader value for that page, in your theme. I plan to add route and component overrides as well, but I haven't decided if those should be in the theme yet.
The goal is to build something that can be deployed and built onto for different purposes, without causing a lot of issues merging upstream changes. Th current structure is almost there, but I feel like it needs another layer between Grazie! and site specific changes. It needs a better core and customization separation, basically. That's what I hope to solve in February.
In addition to the package/framework migration, I'm also adding password resets and email support. The email support is kinda needed for the password reset. This change is driven by me moving away from bcrypt to the Node.js crypto module for password hashing. If a current user has a bcrypt hashed password, it will trigger a password reset workflow, when they try to log in.
If I get everything done, that I want to, in February, then we may be close to a beta for March. There are a few additional things I want to fix or add, but it wouldn't hurt for them to come later.
Today I merged the new RSS, Atom, and JSON feeds into Grazie!. The feeds are currently only for latest posts (up to 25 items), I plan to add feeds for categories in the future. I've decided to take a step back from the work I had done for theme component overrides. I think the block system is more important and may make component overrides unnecessary. I also worked on a page that processed Tumbleweed snapshots. That's mostly a personal thing for me, but it could be useful as an RSS feed, which I plan to add as well.
It's been sitting for a while (20250103 branch), so I went ahead and reviewed/merged the early January updates into Grazie!. It's mostly just the Notes functionality (although not complete) and some bug fixes. I've been working on theme overrides for route components/loaders. I'd like to get that finished for some other projects I'm working on using Grazie!. Either way I'll likely upgrade this site sometime this week just for the Notes functionality. I've also been working on RSS support for Posts, some RSS reader features, and a content block system, which will likely be part of the February updates.
On alltheflavors.com we have formulations that you use to "mix" flavored recipes. Most people on the site use these to create eliquid, but we have a lot of different ingredients to create other things to. I've been drinking a lot of tea lately, mostly green tea, but also some mixtures with green, oolong, and white teas. I mostly have individual size tea bags, so I would put in 2 green tea bags and 2 oolong tea bags, to make a green tea with a little kick. I also have used some flavored tea bags. It eventually occurred to me, I have all of these flavor concentrates, I wonder if I could flavor my own tea. Well, I can!
I did some research, some math, and compared usage percentages of different concentrates. The concentrate bottles most of us get drop 0.02 grams of concentrate per drop. I wanted to try to create a simple formula for use, that would work for drops or grams (or mL). Based on the research, it looked like people were using 2 to 3 drops per 8 ounces of water, while one site recommends 5 drops per 12 ounce of water. I deduced this down to 1 drop per 100mL. Since 0.02 grams is 0.02mL, this approach simplified usage percentage, which comes out to 0.02%.
I created a formulation on ATF that uses brewed green tea and a flavor modifier of 0.02x. I left sugar out of the formulation and it assumes you've already sweetened the tea to your liking. I've made my formulation public, you can see it here: Mixnjuice's Green Tea. To use it, just select it under a recipe with the Mix button in the formulations list. I've only tried it with Flavorah flavors, one of them made the best Mango Green Tea I've ever tasted, but it should work with other brands. I plan to test others, so if it doesn't work as well, then I'll make a v2 formulation to adjust the modifier, but none of the Flavorah flavors I tested used the same percentages, so it should be fairly universal.
One downside to my methodology, is you are more limited at smaller quantities. For instance, there are a lot of flavors that you wouldn't, easily, be able to use at the 100mL minimum, because it would require less than 1 drop. You would need to find a less concentrated flavoring at 100mL, something like Capella or The Flavor Apprentice comes to mind, but that means you'd need to use more flavoring as the scale goes up. Overall though I'm extremely satisfied and surprised at how well this works.
Sony announced they are ending support for Blu-ray, potentially ending physical media and consumer media ownership, Techspot reports.
Tumbleweed now has the latest (mainline) Linux Kernel, 6.13. I'm running it right now, no issues so far :)
I never use Discover, unless it's to install something KDE specific and I never use it to update. If you are using openSUSE Tumbleweed and want to get rid of Discover Notifier, run this:
sudo zypper rm --clean-deps discover6-notifier
sudo zypper al discover6-notifier
These will uninstall the notifier and lock the package so it isn't installed in the future, which it typically is by default.
Drupal has released a new CMS, creatively named Drupal CMS. The Drupal framework is one of the most used platforms for building web sites, with deployments from governments and several large corporations. The timing is exceptional, as the popular WordPress is currently going through some difficult times, both legally and financially. I haven't had a chance to try it, but it looks like it has potential.
I've been experimenting with creating a new scripting language that I'm writing with Rust. I've named it Languish, which is a synonym for Rust and a word play on Language. Surprisingly, it's actually coming along fairly well. I don't want to really get into details yet, but it has some novel capabilities and has been kind of refreshing to work on. I don't know when it'll be ready, but I plan to get it to the point I'm happy with it and then I'll begin sharing it with the world. For now it's just another side project.
Sometime around snapshot 20250102 I started having issues with Flatpaks not using system fonts or cursors. Most notably in DBeaver and Zen Browser. If you have these issues, you can solve them as below.
Download the previous RPM from the Tumbleweed repos: https://download.opensuse.org/tumbleweed/repo/oss/x86_64/xdg-desktop-portal-1.18.4-1.1.x86_64.rpm
Open the location you downloaded the RPM in a terminal and run:
sudo zypper in --oldpackage xdg-desktop-portal-1.18.4-1.1.x86_64.rpm(optional) Lock the package version to skip the bad version:
sudo zypper al xdg-desktop-portal
Note: once a newer package is released, you can remove the package lock with sudo zypper rl xdg-desktop-portal
In the evenings I've been working on the reboot of ProfoundGrace.org (PFG), which is being built on top of Grazie!. I have the Bible feature working fairly well, with some additional features it didn't have before. PFG will have it's own theme, named Rock, based loosely on it's existing color scheme. The work has driven some fixes and improvements to Grazie! as well. I found some bugs in the pager and content lists: the pager currently overwrites query params external to the pager itself; the posts listing page doesn't display correctly for privileged users when there are no posts. There have also been a few little fixes here and there.
In Grazie!, I've been working on the Notes feature, which will later merge into PFG and kinda be specialized for that use case. Notes in Grazie! are mostly a feature for me or any user that registers here; they are private notes and lists, so you can only see the ones you create. I also plan to add website Bookmarks to Grazie!, but I don't know yet if they will be public or private (or both).
ProfoundGrace.org (PFG) hasn't had any updates in a while and it uses ArangoDB, so I'm converting it into SQLite so I can use Grazie! with it. I had been planning to use Allora (the SurrealDB variant of Grazie!) for it, but it seems like overkill and I was working on some JSON to SQL scripts earlier, which gave me the idea to use it with PFG. The tooling is intended for a project on ATF, but it actually works really well with SQLite as well. I have the SQLite tool in a repo, on github, named dbtools, if you want to take a peek, otherwise I'll talk about it later on when it's more capable.
I need to get back to the ATF work, which inspired this change, but I mostly have the Bible feature ported to Grazie. I'll work on it on the side and try to get it online in a couple of weeks. This was all necessary because I'm moving to SurrealDB and want to drop my ArangoDB sites/servers. Getting PFG converted gets me another step closer and SQLite makes a lot of sense for mostly static data. The content features don't get a lot of traffic, but the Bible does, so I don't want to take it down without replacing it.