13 Apr 2024
japhb sys0m0.280s 00:38
Looks like a bit under 1.8s. I forgot to account for my slow-ass keyboard when considering the ^C delay. (For ergonomics, it's fantastic. For input latency, not so much ...) 00:53
greenfork real0m4.161s 07:20
user0m4.867s
sys0m0.598s
This is for me with time (echo quit | mugs-cli adventure) 07:21
I will then ask someone who understands --profile, maybe I will be able to debug that. I thought about inter-thread communication too as a source 07:22
By the way, when I run mugs-cli without specifying a server, the server is run in a thread or in a process?
I assume that UI+Client are run together? Or it is also no the case 07:23
And thanks on the primer for the private variables, I have a much better understanding of them now, regarding the general philosophy too 07:24
japhb :+1: 17:18
Yeah, UI and Client outbound run together, though Client *inbound* (just like Server inbound) runs in its own listener thread. 17:19
When you run mugs-cli and it spawns its own server, it does so using a separate thread and avoids using TCP/IP (it uses inter-thread communication instead) *but* it still uses the same encoding/decoding for the data packets, to ensure that that doesn't get broken, and to make it easier to analyze performance of that in isolation from the network. 17:21
$ faster 4.161 1.765 17:23
57.58% less time
2.36 times faster
Ouch
That just doesn't seem reasonable to me.
Makes me wonder if Rakudo Star was compiled with optimizations turned off or for generic (two decade old) CPUs or something 17:25
greenfork I will soon try out the newer version, will see if this is connected to the Star distribution 17:26
japhb Sounds good, thank you! 17:27
greenfork One more about MUGS: when there's some error in my server code for a new game, and I run it with mugs-cli <my-game-name>, I get an error like this
Died with the exception: Request invalid: Game type 'rrp' is unknown
And several stack traces pointing to MUGS::App::LocalUI 17:28
Can I improve error reporting somehow? This one happened because I referenced a variable that was not defined in my server code
japhb Oh, syntax errors in the game code? That may be causing a failure to load the plugin.
I'm using a plugin-loader module as a dependency. I'll have to take a look at what can be done about the failure mode there. 17:29
But for myself, I usually have a t/00-use.rakutest that consists of just use'ing all the modules in my distro in dependency order, and I run that test *often*, with verbose test output. It's a canary for "oops, you broke one of the modules not actually involved in startup". 17:30
greenfork Sounds nice, I will do that too 17:31
japhb If you have an editor that can run tests on file save, that's probably a good thing to hook up to at least the use test. 17:54
greenfork Hmm this is an interesting idea 18:01
14 Apr 2024
japhb: Could you comment on the use of := operator, I see it sprinkled in some places, e.g. here github.com/Raku-MUGS/MUGS-Games/bl...kumod#L217 09:41
Is this to just avoid containerization-decontainerization overhead for a little bit of performance? 09:42
lizmat yes, that's basically the reason for using := 09:47
greenfork: in the case of %has := foo it also means that "foo" is returning a hash 09:48
using := in that case means preventing a (relatively slow) copying of the hash
greenfork Got it, thank you 09:49
15 Apr 2024
japhb Thanks for replying, lizmat! I've been mostly AFK today .... 04:22
greenfork I have a primitive game for starters, now I'd like to reap the benefits of testability, since it is not dependable on UI 17:44
I assume I want to set up a Client-Server integration testing somehow?
I already can test smaller components, but Client/UI/Server split is not necessary for unit tests 17:45
I also kind of lack the concept of where the game starts, I think testing should help with that too. How would I start? 17:46
16 Apr 2024
japhb What do you mean by "where the game starts"? 02:57
And yes, a large portion of the reason for splitting Client from UI is to allow test automation, NPC AIs that operate as a special Client, etc. 02:59
(Other reasons of course are to give the various UIs a consistent clean interface to control, provide on-the-wire consistency, provide a single point for data validity verification, etc.) 03:00
greenfork By "where the game starts" I mean that I don't have a clear idea about what code is called at what point in time 03:11
There's a document "life of a request" that helps with authentication and user management github.com/Raku-MUGS/MUGS/blob/mai...request.md 03:12
But the game is built on top of genres, and genres are built on top of a default Server implementation, so there's a lot more interaction 03:13
Most of the methods public, so in theory any of it can or should be redefined in the child class. So just a lot of things to keep in my head 03:14
I'd like to have an integration test, so I can go through all the steps of interaction 03:15
japhb Can you push your latest work? I could take a look around and see if I can help you get started. :-) 15:05
greenfork That would be great, thank you 18:25
Here is my latest work: github.com/greenfork/rrp