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:
Yes, I know—yet another attempt at bringing a ternary-like experience to Go. But hey, Go doesn’t have one, and I wasn’t around when the last million were written.
Because Go doesn't have a ternary operator, and according to the official FAQ, it likely never will. The reasoning? To prevent developers from writing "impenetrably complex expressions." But let's be real—poor coding practices exist in all forms. Instead of outright banning a useful construct, wouldn’t compiler warnings for overly complicated ternary expressions have been a more reasonable approach?
Since that's not happening, here’s go-ternary—because sometimes, a one-liner is just nicer than an if-else.
| 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.
| local Players = game:GetService("Players") | |
| local TextService = game:GetService("TextService") | |
| local HttpService = game:GetService("HttpService") | |
| local DataStoreService = game:GetService("DataStoreService") | |
| local ReplicatedStorage = game:GetService("ReplicatedStorage") | |
| local FormRemote = Instance.new("RemoteFunction") | |
| FormRemote.Name = "FormRemote" | |
| FormRemote.Parent = ReplicatedStorage |