Taylor

	Count
Releases	2
Commits	19
Contributors	1
Pull requests merged	3
Issues closed	3

At a Glance

• Taylor v0.4.2 and v0.4.3 Released I put out two small releases to fix some bugs
• mruby 4.0.0 Upgrade A hard fought battle to upgrade mruby
• Raylib 6.0 Upgrade A much simpler upgrade
• Taylor Squasher Progress Finally just sat down and built a prototype

Taylor v0.4.2 and v0.4.3 Released

Taylor v0.4.2 and Taylor v0.4.3 have been released. These contain a handful of small fixes.

Changelogs

• Taylor v0.4.2
  • Lock the MRuby version used in the export docker image
  • Refactor talyor-config.json handling
  • Update the Dockerfile.dev for Debian 13
  • Fix OSX exports
• Taylor v0.4.3
  • Properly use Taylor::Config through the entire export process

mruby 4.0.0 Upgrade

This was a hard fought battle but I managed to conquer mruby and bring it up to 4.0.0. There are three main reasons for this.

1. mruby 4.0.0 Loads mGems in a Different Order

The ordering of mgems has changed in the build config. Now custom mgems are loaded before internal core mgems. This broke the following two mgems for very different reasons.

2. mruby-require

mruby-require is an extremely powerful mgem that lets you use require and properly structure your project into many neatly organised files. It actually also allows you to compile other mgems into .so or .dll files so you can programmatically require them after mruby is built. That’s the functionality that broke.

I ended up having to fork the mgem and remove that functionality. This has the bonus of making the code for the mgem much more maintainable as that was causing the build to be complicated.

3. Neospec

neospec is my gem/mgem. It’s a testing framework that helps me keep Taylor working correctly as I develop it.

I forgot that I rely on the core mgem mruby-env and that meant it was built in the wrong order. This meant when Taylor loaded up the code tries to use ENV before it’s available. Thankfully a pretty easy fix once I figured out what was going on.

Raylib 6.0 Upgrade

This has gone a lot easier than the mruby upgrade. This brings extremely minimal changes to your experience using Taylor. What’s interesting is that this opens up a lot more possibilities on the backend for porting to different systems.

Taylor Squasher Progress

I sat down one night and decided to do something a little silly to get myself unstuck on this project. I kept worrying about “how to do it perfectly” and overthinking every step. So I sat down with my laptop, put a chill video on in the background, and just gave myself permission to write bad code to achieve the simplest possible result.

This is something I can get a little hung up on when developing something open source. I get in my head that every commit has to be a perfect example of great code instead of reality. There’s every chance I’ll re-write the git history before opening it up but history has often shown I’m too lazy for that, so you’ll probably be able to dig and see what I did.

I am happy to report that I did get a basic prototype working with the Jumpy Alien example project!

The interesting thing to note is that it includes every .rb file that’s in your load_path according to the taylor-config.json file. So you’ll see in the playground that it also includes the files from under test/ even though they aren’t used.

Obviously this is just a prototype and weird things like this are to be expected for now. I’m not entirely sure how I want to handle things like that. I’m not convinced I’d be able to implement a tree shaking algorithm or anything fancy like that. But maybe just a simple export-ignore option?