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.)