LLCM - Low Level Colonial Marines

[antlersss]

About the pull request

Introduces a Low Level Colonial Marines (LLCM) rust package into the repo. This provides an independently compiled dynamic library that byond procs can call when things need to be done closer to hardware.

We have such a thing already, called rust-g, however this is an external project that was created by /tg/ station and it doesn't necessarily cover all of our needs for finer optimizations. Having this directly integrated with the repository will allow us to create our own low-level functions that directly suit our needs, instead of needing to run it through /tg/ and then pull it down from upstream. rust-g will be used in conjunction with LLCM, and LLCM is not a full replacement for rust-g... yet.

Additionally, this PR adds vscode tasks that should streamline development with LLCM and integrates rust's testing features into the CI suite.

TLDR: Making the server faster by not using BYOND.

Testing Photographs and Procedure

Screenshots & Videos

Put screenshots and videos here with an empty line between the screenshots and the <details> tags.

Changelog

🆑
server: Creates LLCM, a low-level dynamic library used for finer optimizations for expensive/complicated proc calls.
/:cl:

[cm13-github]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[cm13-github]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[Watermelon914]

Not a fan of this, what sort of optimizations does CM need that rustg doesn't provide exactly?

[antlersss]

The most notable use case (and the one that I'm going to solve first in a PR stack based on this) is to expedite loading files like user preferences. Our icon2base64 proc has on average about 21k calls per round, and is incredibly slow in its implementation because it saves the icon directly to a save file.

The problem with rust-g is that it's not our own. It's a /tg/ application that they were able to build on top of as use cases arose. This is essentially just an in-house fork of rust-g to be used in conjunction.

What exactly do you not like about it? I'd kind of like a more thorough explanation before being marked as DNM...

[fira]

Having a separate lib makes sense since we can't neccessarily PR everything to rust-g. But personally I would like to see some practical implementations before merge rather than just merging something empty

[Watermelon914]

Having a separate lib makes sense since we can't neccessarily PR everything to rust-g. But personally I would like to see some practical implementations before merge rather than just merging something empty

As long as it's something that isn't relevant for rust-g, I agree, but as it stands, we lack the maintainers who know how to review rust, so I would prefer any generalized enough usecase to be committed there instead.

If it's something that's truly not relevant for rustg but relevant for us (i.e. through byondapi) and it provides considerable performance benefits, then I think we can take the maintenance burden, but otherwise, it may end up as a piece of tooling that ends up broken/unmaintained due to a lack of rust-capable maintainers/contributors.