Welcome to MUGS ⚄♠♞🏹 (Multi-User Gaming Services)! | github.com/Raku-MUGS | v0.1.4 has been released! (github.com/Raku-MUGS/MUGS/blob/mai...v0.1.4.md) | This channel is logged for historical purposes; logs at irclogs.raku.org/mugs/index.html Set by japhb on 3 March 2024. |
|||
japhb | Ah, from chat on #raku-dev, it sounds like the latest Rakudo broke Red. They're on it, but the bigger question is why our release tests didn't catch it. | 01:34 | |
11:25
greenfork left,
patrickb left,
patrickb joined,
greenfork joined,
greenfork left
11:26
patrickb left
11:28
patrickb joined,
greenfork joined
|
|||
greenfork | Thanks! I'll try that | 11:31 | |
The 2024.02 release was broken too, it had a Red test failing which prevented Red from installing without --force-test github.com/FCO/Red/issues/573 | |||
Can I make zef install --force . faster? It takes a whole minute on my machine | 15:40 | ||
I must say it is hard to read the source code of Raku with so much code in different places | 16:14 | ||
I finally managed to stub an IF style game. I think I will try to move it to a separate directory and use paths for dependencies to avoid long install times of zef | 16:15 | ||
[Coke] | avoiding zef isn't going to help with any maintenance - and once you've installed deps, you don't have to do it again. | 16:34 | |
greenfork | I literally have to reinstall the deps every time I change the game because MUGS-UI-CLI uses global import of all games. Sepcifically, I have to reinstall MUGS-Games since I develop inside this repository | 16:39 | |
japhb | Ah, an interesting problem. And you're saying it takes a minute to install MUGS-Games? That seems ... slow. What kind of machine are you running it on? | 16:52 | |
greenfork: Note that "adventure" is basically a simple IF. (It was designed as a proof of concept, so it has very few capabilities, but it's there if that helps you.) | 16:53 | ||
greenfork | I use "advanture" a lot, yes | 16:55 | |
My machine is pretty fast, 16 cores AMD Ryzen 7 4800U laptop | 16:56 | ||
Produced about 4-5 years ago I think | |||
japhb | OK, Ryzen, so you should still be getting the (modest) bump from the JIT | ||
Spinning rust or SSD? | |||
Also, how much RAM? | 16:57 | ||
greenfork | SSD, 16 GB RAM | ||
japhb | Linux? | 16:58 | |
greenfork | Yes | ||
japhb | Hmmm. Nothing obvious with any of that, unless you happen to be stressing that RAM enough to swap (swap still sucks on SSD, it just doesn't suck *as much*) | ||
greenfork | Current memory usage 34%, I don't think zef takes 10 GB RAM | 16:59 | |
japhb | Can you actually time that install? I'm curious just how bad it really is. (That it's over a minute is already annoying, but *how much* over?) | ||
greenfork | 58 seconds for MUGS-Games | 17:00 | |
japhb | I get 23 seconds on my box with a cold cache. | 17:01 | |
Harumph. | |||
greenfork | I use Rakudo Star distribution, maybe it loads something | ||
Apart from that I think the version could be different, I sued 2024.02 currently | 17:02 | ||
s/sued/use/ | |||
japhb | (Yes, please don't sue us, kthx) | ||
greenfork | :^) | ||
japhb | I'm on 2024.03. Shouldn't make *that* big a difference. | 17:03 | |
What is `zef --version` on your system? | |||
greenfork | How did you install Red with 2024.03? | ||
zef --version is 0.21.4 | 17:04 | ||
japhb | I installed Red with --/test. It's had test complaints over the years that haven't affected my use case. Yours was the first time I'd heard of a complaint like that. | 17:05 | |
(Meaning, it actually *broke*) | |||
Yep, that's current zef. So it's not that. | 17:06 | ||
greenfork | I see, you just ignore the tests. I actually wasn't impacted by Red misbehaving in any way. I only failed to install MUGS because Red was a dependency and Red's tests failed | 17:07 | |
japhb | I build everything from scratch (MoarVM on up), so it's possible Rakudo Star is doing something that a pure Rakudo install with manual module installs does not. | ||
greenfork | I will try pure Rakudo without Star starting with 2024.03. I don't think I need any benefits of the Star distribution, although it is a recommended way of setup in various guides | 17:09 | |
japhb | greenfork: I don't like to, but there have been enough times that my dependencies have failed tests and still worked fine that I now --/test on the ones that had the most trouble over the years. I avoid it on modules that are *usually* OK, so that I catch a really egregious problem, but yeah, I can miss it when one of the 7 problem modules in my list has trouble., | ||
My module install list refers to them as 'Phase 8: Persnickety modules' | 17:10 | ||
greenfork | You have a module install list, interesting | 17:11 | |
japhb | greenfork: Yeah, because Star requires less foreknowledge and provides some modules that people expect. | ||
greenfork: Oh yeah, I install them serially from (least dependencies/most often working) to (most dependencies/most flaky), since I often run dev versions of Rakudo and need to see exactly how bad a Rakudo regression turned out to be. | 17:12 | ||
One of the side effects of having been here ... a while, shall we say. | |||
greenfork | Don't they do this with every release? I thought that Red is an important enough library to be included in a testing phase of the new release | 17:13 | |
japhb | On a related note, it looks like a proposed fix for Red is in, and SmokeMachine is looking at it to see if it worked. | ||
greenfork: And there's the next problem. Apparently the release CI (known as 'Blin') missed some regressions this time around. And we're trying to figure out why. | 17:14 | ||
There's some frustration, as you might imagine. | 17:15 | ||
greenfork | I also thought about deploying Raku applications to the server and it seems like Docker is a must because I don't think I can update dependencies of only one particular application | ||
japhb | Of the "Argh, why wasn't this caught?!" variety. | ||
greenfork | Kind of unrelated | ||
japhb | Those who deploy Raku applications to publicly accessible servers almost always use Docker or a VM solution of some sort. | 17:16 | |
greenfork | I think Blin also didn't catch the regression with Rakudo on the previous version 2024.02, maybe it broke in January or earlier. Red also failed tests for that version | ||
I have an OpenBSD server and it doesn't support Docker :^( I will have to learn vms then | 17:17 | ||
japhb | Podman maybe? Similar containers to Docker. | ||
greenfork | Podman is also missing. Their stance is that containers are ultimately not secure, so avoid them | 17:20 | |
japhb | I mean ... they're not wrong, though containers are useful for more than security. Like, say, dependency management. *cough* | 17:22 | |
greenfork | I want to live in a world where dependencies are managed by a package manager, like Ruby's bundler | 17:26 | |
japhb | Having dealt extensively with npm security in my previous job ... eh, don't necessarily trust bundlers. | 17:33 | |
(Though I haven't used Ruby's, to be fair.) | |||
But I wasn't just talking about bundling the language's own modules ... I meant the whole userspace stack. | 17:34 | ||
greenfork | Makes sense yeah | 17:58 | |
Bundlers are quite handy when developing several projects. With Raku currently I'm mostly lucky that I don't have errors because of dependencies mismatch | 17:59 | ||
At least development is better. Deployment is probably better as you said with all the userland | 18:00 | ||
japhb | Interestingly, Raku's design makes it *less* of a problem in theory, because Raku understands versioned APIs and such natively, and can in fact load different versions or forks of a module into the same memory space without complaint. | 19:02 | |
BUT: A lot of modules don't specify their dependencies in such a way as to take full advantage of that feature. | |||
So the practical reality doesn't quite meet the design bar, though there are people occasionally going through and fixing that stuff up. | 19:03 | ||
greenfork | Manual version management encourages less dependencies, a good side effect benefit. Good to know that I can be safe with dependencies in my project at least in theory | 19:06 | |
I'm trying to develop a game in a sibling directory to all the MUGS repositories with this file git.sr.ht/~greenfork/RRP/tree/mast...n/mugs-cli | 19:50 | ||
I have a problem that all my game files (need ...) are not reloaded when I change them. Is there anything I can do to fix this? | 19:51 | ||
japhb | Normally when I'm developing a game, I don't run a separate server, I just run the client by itself with no server (which will cause it to internally spun a stub server and use that). | 20:58 | |
Then I restart the client when I need to refresh things. | |||
I don't have it set to live-load plugins (including game plugins); these are all loaded at start time. | 20:59 | ||
(In MUGS-UI-TUI you can see the loading bar, but I haven't done that in MUGS-UI-CLI yet.) |