Time Nick Message 00:00 MTDiscord types? write it in rust :juanchi_face: 00:00 MTDiscord i was gonna jokingly suggest haskell lol 00:02 MTDiscord mark, i remembered that luau is also a thing. it's a bit like teal. i've never touched it since i don't write roblox stuff but it seems promising from a glance 00:09 MTDiscord I forgot about Luau, I'll add it to my list, it's probably a good candidate given the Roblox support 00:09 MTDiscord luau essentially faced / faces the same problems as us except they've been there longer and they have money so yeah, they tend to have at least half-decent solutions and luau's type system seems to be one of them 00:11 MTDiscord yep yep, a quick search shows Luau doesn't support number ranges though, but we may have to lower our bar 😄 if there is a good parser that supports plugins maybe we can add custom syntax and parse that out for more expressive types. Just a thought. https://stackoverflow.com/questions/79616288/how-to-define-acceptable-parameters-in-a-export-type-as-a-range-of-numbers-in-lu 00:19 MTDiscord generics in luau seem meh. it might even be worse than emmylua and luacats 00:47 MTDiscord Idk, we got pretty far along with the whole markdown parser solution with a schema for validation of what we write. We were mostly uncertain about formatting, which seems to be what we are all after - a good plaintext format that covers all our needs. 00:48 MTDiscord @ExeVirus could you clarify who "we" is? Any links to this solution or am I missing something? I'm not quite following :/ 00:49 MTDiscord oh, did you read the riseup pad? https://pad.riseup.net/p/Luanti-Docs 00:49 MTDiscord i wrote more of my thoughts there too 00:50 MTDiscord along with other people 00:51 MTDiscord there's a ton of info in there, I should just capture and upload here as well for safekeeping - but yeah we were looking at different formats for what it might look like to define something as simple as a function 00:52 MTDiscord my issue with the markdown thing is that verifying the types we write is correct is going to be hard. i expect people to make typos or write types that do not resolve or make sense; mistakes basically 00:52 MTDiscord (well, not just markdown, any custom type system) 00:52 MTDiscord not worried, that's what a schema is for - it can point us to the exact line and mistake 00:53 MTDiscord sick! I must've missed that one, thanks. Verifying types is hard but automated systems are good at that 🙂 I am leaning more and more towards Markdown, but I still feel a need to do basic research on all reasonable alternatives before moving forward 00:53 MTDiscord Also if you do take a read @mark, make sure to check out the chat - there's a lot in there too 00:55 MTDiscord i think after you do yaml and make a decision on it you can pretty much immediately decide on json and toml too. yaml is a more expressive format compared to json and toml 00:59 MTDiscord I'll make a note to check the chat, and yes I think if YAML is out then TOML and JSON and XML are out as well. Honestly those last three are mostly listed for completeness, I highly doubt they're good ideas the more I think about them 01:44 MTDiscord If we are going for pure machine readability and not humans readability, then all of those toml, yaml, Json, table formats are the same in my mind, heck might as well write up everything in Lua at that point and skip the data format. I'm open to ascidoc or even latex if it's better looking from an editor, reader standpoint, because I'm certain we can make anything parsable and have a schema 01:47 MTDiscord the goal is to make something that many people will be able to maintain, the worry with JSON for example is that there is no native support for multiline strings, so adding a long description to a field will be really annoying to manage. So I am leaning away from markup languages (including JSON). The downside of making something easy to write is that it's not always easy to automatically parse, nor is it always clear what the 01:47 MTDiscord "correct" domain structure is when the core structure is just "markdown". But I think we can do it 🙂 03:23 MTDiscord I am very confident we can make anything parseable, just as long as we come up with a good, consistent format. After reading the rise up, did you like anything you saw? 03:25 MTDiscord haven't read the rise up, decided to spend the day coding a different new project. will definitely come back to this next year though! 😉 04:53 MTDiscord merging https://github.com/luanti-org/docs.luanti.org/pull/306 in 5 if ci passes 05:00 MTDiscord i was slightly woried about people going to the specific platform pages rather than the landing pages, so i included a snippet at the end to drive them back to the landing page for next steps on applicable platforms 05:08 MTDiscord also, random questions * i assume you can run luanti server on macos, and its mostly similar to linux, but do we give a crap? * bsd platform? any chance @turnipharald_7196 (sorry, your the bsd person) you have some server experience on the bsd's? (context, platform specific version of https://docs.luanti.org/for-server-hosts/setup/linux/) * can you run a server from flatpack? do we care? * for immutable/attomic/nix distros, hosting a 05:08 MTDiscord server, who cares? docker / containers will be good enough to expand into covering that, or something specific later..... perhaps 05:12 MTDiscord re #1, its kinda 🤷, but we also have a guide for windows which imo you should only use for server hosting if your truly a masochist (at least on desktop anyways) re #3, im inclined the least to care about. 05:14 MTDiscord . another random thing, under Choosing Hardware, thinking of adding some lose advice on picking actual specs, since get asked that just enough to be annoying, and can refer them there. also a note about making sure if using luajit that gc64 is on, otherwise > 2gb ram is worthless, and the mineclon*s usually need that 17:47 MTDiscord i'm not sure "markdown schema" is the correct term so much as DSL that contains markdown strings, including the need to specify the syntax for a type system 20:10 MTDiscord schema = form, the idea is a specific form of Markdown that can be parsed programmatically and consistently. I worry DSL implies a lot of overhead syntax that I'm not suggesting. But yeah I think we have the same idea of a very lightweight but consistently parseable Markdown document