Hello all, here's another monthly project update. The summer holidays have started, so I'm away at the moment, but I've still had lots of time to code some cool things.
The jokes, hoaxes, and memes have all turned out to be true. There will be a Mercury 3.
Mercury 3 will be hosted on the domain xtcy.dev. We have a working DLL hook for the 2013 client & studio (same as previous Mercuries) and a Windows Server VPS for running Mercury Core, RCCService, and related services.
Welcome, again, to another monthly update. This one's right in the middle of my exam season! How convenient.
Mercury Core is back to life now, after a few months of inactivity. The codebase has been given some much needed TLC & dedusting and I'm working on improving many of its parts – at the moment the 'communication' branch contains a rewrite of the forum, status updates, and asset comments into a single system, as well as improvements for likes/dislikes.
The database schema has also been significantly improved, the auth system has been rewritten without the need for Lucia v3 (thank you lucia!), all components have been migrated to use Svelte 5 syntax and features, fixes have been applied to the economy service, and many miscellaneous formatting and styling fixes have been made, as usual.
Happy holidays! The year is Marching on, so I hope everyone is doing well; here's some updates on the projects I've been working on.
Coputer now features a number of 'program types' for programs to accept and return certain values. Current program types are as follows:
| import data1 from "./250-350.json" | |
| import data2 from "./350-400.json" | |
| import data3 from "./400-500.json" | |
| import data4 from "./500-550.json" | |
| const hits1 = data1.results[0].hits | |
| const hits2 = data2.results[0].hits | |
| const hits3 = data3.results[0].hits | |
| const hits4 = data4.results[0].hits |
Spring has sprung, the grass is ris. I wonder where the monthly project update is? Welcome back all.
Litecode is in the process of being rebranded! The name "litecode" will now only be used for the VM, standard libraries, and execution system. This means that the rest of the project, what I'm coining the "communication system", will be separate, and will communicate with the litecode execution system over a(n internal) network. Litecode will handle the execution and return of programs and their results, and should cancel them if they run for too long.
The combination of the execution system, the communication system, the protocols they rely on, and the network of these systems communicating with each other is being rebranded as follows.
Hello again! Your monthly update is here once again, with the usual side of assorted sections of rambling.
Some bug fixes and a better external API have been added, alongside four string library functions I was hesitant to implement: find, match, gmatch, and gsub. Pattern matching was, as I had suspected, a pain in the ass to get working. What next, maybe metatable support? Eh, perhaps if they actually turn out to be useful someday.
Pretty much all standard library functions apart from the really naughty ones have been implemented now, so I'll call it ready for further battle-testing as part of a larger-scale system. If any bugs crop up that I haven't caught yet, they'll probably be really insane time-sink ones.
Happy new year! Small update from the end of last year here.
Litecode is, solely for the purposes of the larger project I would like to use it in, nearing completion. I ought to change the tagline to something other than "Semi-working Luau bytecode interpreter" at this point lol
I'm taking full advantage of the fact I can break compatibility with the reference implementation in a couple of places. The interpreter now features a faster, simpler, and lighter implementation of tables, at the cost of a few tiny edge cases being different with vanilla Lua/Luau. Bugs are sometimes difficult to track down because of little debugging/error handling support at the moment, though the steadily growing test suite helps a lot with this.
Sup. Hope you're all excited for this epic completely regular post about the progress of what I'm working on.
I've been steadily stabilising litecode's interpreter and continued work on the standard library. math and table libraries are now complete, and I have some functions working on the string library.
However, I'm unsure I'll be able to match the compatibility of the reference implementation, especially given that what I'm building might not even be considered Luau anymore. Most deprecated functions have been removed, math.random/randomseed have also been taken out, and the string library, the most complex so far, I'm only planning on implementing about half of.
Relating to randomness – I'd like determinism to be a priority, as this would be extremely useful for the larger project I intend for it to be a part of. Relating to the string library – A lot of the stuff relating to iterators I
| <script> | |
| let name = 'world'; | |
| let map = [] | |
| let colours = [] | |
| const petals = 13 | |
| const hue = Math.random() * 360 | |
| const stdev = 10 |
Eh. Welcome back, fellow monthly update viewer! Here's the October one.
litecode is a bytecode interpreter for Luau, modelled after Fiu. It's semi-functional at the moment, though handles a lot of stuff I've thrown at it. Building it ended up being a huge pain learning experience (even though it was still way easier than attempting to embed Luau itself).
Implementing this has given me loads of insight into how Luau works, and interest about what I can use it for as well. It's also given me some crazy ideas like "hey, what if metatables were bad?" and "what if I made tables index starting at 0?" and "what if I made if-conditions only work with booleans?" and so on. I'll see if I can keep those out of my head or if I'll power trip and let them stay there.