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.
Hello again. Here's another monthly update to show what I've been working on.
The Heliodex/sprig repository includes a set of tools and the Sprig Shooter game for the Hack Club Sprig game console. While the engine was designed to work with tile-based games, Sprig Shooter is a bitmap-based arcade-style game. Shoot enemies and avoid crashing into them to gain score, and the game gets harder as you progress.
The limited capabilities of the Sprig was a fun challenge to work around, and making bitmap graphics and music alongside custom engine behaviour and collision detection was a great learning experience. I've applied to get my hands on the real hardware, and I can't wait to see how the game runs on it.
| // F# version, bit of a hack because it relies on luau anyway so just use the luau version, it's faster | |
| // also I'm never writing a mathematics evaluator | |
| open System | |
| open System.Diagnostics | |
| open System.Collections.Generic | |
| // digits one to ten must be in order | |
| // numbers one to ten, with 3 operators placed between them | |
| let sum = 100 |