|
🦋 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
|
|||