🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
[Coke] wiping the azure win machine I had setup for now (price quintupled this month and AFAIK no one was using it) 00:32
01:15 MasterDuke joined 08:35 sena_kun joined 08:36 finanalyst left 10:58 finanalyst joined 11:31 japhb left 11:47 japhb joined
Geth rakudo/main: f8b56432de | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: deparse alphanumeric prefixes with space

Otherwise most likely won't parse again
12:04
12:04 finanalyst left
Geth rakudo/main: 9d959fae45 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.rakumod
RakuAST: only handle true system methods specially
12:43
13:01 sena_kun left 13:15 sena_kun joined 13:44 vrurg joined 13:47 vrurg_ joined, vrurg__ left 13:50 vrurg left 14:09 vrurg joined 14:10 vrurg__ joined 14:13 vrurg left, vrurg_ left, vrurg joined 14:17 vrurg__ left 14:38 vrurg_ joined 14:42 vrurg left 14:48 vrurg_ left 14:49 vrurg_ joined 15:10 vrurg joined 15:12 MasterDuke left 15:13 vrurg_ left 15:33 vrurg_ joined 15:36 vrurg left 16:57 vrurg joined, vrurg_ left
lizmat m: say Q|use v6.d|.AST # I understand why, but it is a pain for deparsing :-) 19:00
camelia RakuAST::StatementList.new()
19:02 vrurg left, vrurg joined
gfldex So that's basically a comment, without the actual comment? 19:07
lizmat yup 19:12
actually, treating it like a comment might be TRTDT hmmm
19:12 vrurg left 19:25 finanalyst joined
patrickb I'm currently looking at the IO::Socket role. I think this line github.com/rakudo/rakudo/blob/main...akumod#L74 is fishy. 19:25
lizmat fishy in what way? 19:26
patrickb Do I misunderstand, or does reading loads of data into the decoder and then only using parts of it mean, that subsequent calls to recv(:bin) will not see the data still in the decoder?
lizmat how: only using parts? 19:27
patrickb get is reading a single line, right? 19:28
so if that nqp::readfh call reads more bytes than what the next line is, those extra bytes will not be returned from the #!decoder.consume-line-chars and stay in the decoder, right? 19:30
lizmat that's my understanding 19:33
patrickb looking at how the decoder works, it has a mechanism in place to pull out data undecoded. If recv were to use that instead of pulling from the handle directly, things would be fine. 19:34
lizmat OT: looks like the IRC logs server is using significant less actual memory after runing for a day or so 19:35
*running
patrickb oh, nice!
lizmat well.. It's using 16G of RAM now, but really only 5G because it compressed 11G of RAM 19:36
with the expr jit the amount of compressed RAM was a lot less
patrickb We cound either change IO::Socket::recv to pull all data through the decoder *if* there is a decoder set. This would only give the perf penalty of using the decoder for :bin access when it was at least used once. 19:38
Or make get() (and the other functions doing similar), process data bytewise to ensure there is never unprocessed data in the decoder. That seems decidedly worse. 19:39
lizmat I think this design is to allow to first read in text, and then read in :bin and vice-versa 19:44
e.g. when parsing a HTTP header and then receiving a body in binary ? 19:45
patrickb I'll have a PR in a moment. 19:49
testing the change now 20:13
20:35 vrurg joined 20:47 vrurg left
patrickb Bah. I've added a few tests. One fails pointing at a misbehavior in moar land. Ugh. Why do I keep falling into these rabbit holes? 20:49
ugexe Yeah I’m pretty sure the intention was to optimize http stuff for the reason Lizmat mentioned
6guts.wordpress.com/2017/06/08/sor...ronous-io/ 20:51
Might have some insight as well 20:52
20:52 vrurg joined
patrickb The current implementation fails as soon as one tries to read binary from a socket that before was read decoded from. 21:10
Geth rakudo: patrickbkr++ created pull request #5604:
Partially fix mixed bin/no bin reads in IO::Socket
21:30
roast: patrickbkr++ created pull request #857:
Test mixed bin/no bin access in IO::Socket
21:33
patrickb There we go. There is a doc PR as well trying to document the difficulty of mixing bin / non-bin reads 21:45
Oh well, I didn't get as far as I hoped with my IO::Socket::SSL lookalike as I liked tonight. 21:46
Anyways, off to bed for me.
'night every one. o/
ugexe: If you want you can join the bikeshedding fun over on the io socket ssl PR discussion. 21:47
22:46 sena_kun left
ugexe I’ll try. I’m pretty busy over the next month but am still checking up on stuff when I can 22:53
23:42 finanalyst left