Cro: libraries and tools for building reactive services in Perl 6 | cro.services/ | Logs: irclog.perlgeek.de/cro/
Set by moderator on 31 January 2018.
02:58 ilbot3 joined
moderator Cro: libraries and tools for building reactive services in Perl 6 | cro.services/ | Logs: irclog.perlgeek.de/cro/
09:55 jc_denton_ joined
jc_denton_ Hey there. Is anyone around to give me a hand with getting messages from cro websockets. I can see the message received when I run the server using cro trace but they never appear as a say or a warn. 10:25
I've been using the example on the reference to the http-websocket but I'm not sure how to make use of the recieved messages. 10:26
jnthn jc_denton_: Can you show the code you're using? 10:32
Each message that you get will be a Cro::WebSocket::Message object
jc_denton_ pastebin.com/5zDfQ5VQ 10:34
jnthn Ah, that's just an echo server 10:36
So it's just sending back to the client everything it receives
Stick in a say $body; if you want to see what's arriving
jc_denton_ Thanks, I wasn't sure about that. I wanted to make use of the messages received. Can you point me in the direction of how to do that? 10:42
jnthn What use do you want to make of them? 10:45
I mean, you have the message in $body, so you'd just write some code to do whatever you need with it and call it, I guess 10:46
11:11 timo joined
jc_denton_ I was aiming to make use of them to create a list of open web socket connections and be able to send specific messages to individual web socket connections. 12:00
sorry for the late reply.
12:37 colomon joined
colomon jnthn: static "static", $filename; gets me “Type check failed in binding to parameter '@path'; expected Positional but got Str” 12:38
colomon ’s idiot IRC program was using 50 GB memory yesterday, so he may not stay on long today…. 12:39
using @path (like in http-router.t) works, so I’ve switched to that 12:46
jnthn colomon: Hmm, maybe we should make it a slurpy instead of an array arg there, so it'd Just Work :) 13:02
colomon +1 13:13
jnthn jc_denton_: Ah, sorry, was at lunch when you replied then missed it. For that I'd create a new Supplier per incoming connection, store that somewhere, and put `whenever $that-supplier { .emit }` into the supply for the websocket 14:01
jc_denton_: Then you can .emit into the appropriate Supplier 14:02
jc_denton_: Only thing then is that since the application is multi-threaded, you should probably use a monitor to handle your subscription list lookup thing
jc_denton_: An easier way (though that maybe scales less well) is one Supplier and then whenever $all-messages.grep(...) { .emit } - that is, you grep out the ones destined for a particular user 14:03
jc_denton_ That seems to have been what I was looking for. Thanks a lot! 15:45
Geth cro-websocket: fadeed59f0 | (Jonathan Worthington)++ | 7 files
Support body parser/serializer in WebSocket client
16:11
cro-websocket: bac66d89f1 | (Jonathan Worthington)++ | 2 files
Provide :json option for WebSocket client

As a convenience over manually setting up the body parser/serializer.
16:32
cro-websocket: 622fcd3792 | (Jonathan Worthington)++ | lib/Cro/WebSocket/Handler.pm6
More correct web socket close Promise handling

A recent commit forced processing of messages sent to the web socket handler to happen asynchronously, to avoid deadlocks when an `await` of the message body would prevent incoming frames to be processed in multi-frame messages. Unfortunately, that could cause the close Promise to be kept before all message processing was done. This change makes sure that won't happen.
17:10
cro: d8a16575f0 | (Jonathan Worthington)++ | 4 files
Doc update for body parser/serializer changes

This updates the names of the roles, which are now in Cro::Core.
17:24
cro: 596130160f | (Jonathan Worthington)++ | 2 files
Document body parser/serializer with WebSockets

Both for the client and the server side.
17:48
20:01 trnh joined, trnh left 22:39 lizmat joined