00:18 johnjay left 00:23 johnjay joined 00:43 jjido left 01:15 hulk joined 01:16 kylese left 02:15 hulk left, kylese joined 04:43 leppard is now known as Inline 04:45 johnjay left 04:52 johnjay joined 05:02 Inline left 05:10 Inline joined 05:40 Inline left 05:44 Inline joined 06:01 Sgeo left
disbot4 <melezhik.> liz: irclogs.raku.org/ is down for me 06:28
<melezhik.> ^^ lizmat: 06:29
xinming my $fh = open("xxx.bin", :enc<utf16>); my $buf = $fh.read(8, :bin); 07:02
In this case, the buf should be Buf[uint16], right?
bbl, I'll ugpraded my raku and test again.
timo tbrowder: liz put in a lot of work with JSON::Fast as well 07:28
07:49 Inline left 08:05 belluzj joined
xinming Even with 2026.05 version, when open a file with :enc<utf16>, read returns Blob[uint8] too. 08:33
So a bug
08:35 lichtkind joined
timo xinming: i think read is for binary reading, not encoded reading 08:35
08:44 DarthGandalf left
xinming timo: Which method to use then? When I check the doc, there is readchars 08:46
I thought readchars is pure byte by byte reading
timo you have it backwards, readchars is to get decoded strings and read is for byte-for-byte reading 08:47
depending on your use case, you may be more likely interested in .get to read line-by-line, or .slurp to read everything? 08:48
xinming timo: I wish to get Buf[uint16] string 08:52
timo: Thanks, I just read the docs.raku.org/type/IO/Handle yea, read do byte reading, readchars do graphemes
timo OK, i'm not sure what the easiest way is to get from a file handle to a 2-byte buffer 08:53
xinming I can manually combine 2 uint8 in to a single uint16, But there're unnecessary steps I want to avoid. 08:54
something like, my $buf = $fh.read(24, :bin); $buf.rotor(2).map( ... ) 08:55
timo there's methods on Buf for reading and writing different sizes of bytes at desired endiannesses 08:56
m: my $a = Buf.new; $a.write-uint32(0x123456); say $a
camelia Too few positionals passed; expected 3 or 4 arguments but got 2
in block <unit> at <tmp> line 1
timo m: my $a = Buf.new; $a.write-uint32(0, 0x123456); say $a
camelia Buf:0x<56 34 12 00>
xinming timo: thanks for the Buf methods hint, Will paly on Buf.write-* method 09:02
timo well, you will want the .read-* methods to get 16bit parts from an 8bit buf and put them into an array of some kind 09:05
09:17 belluzj left
xinming timo: Thanks, the read-* methods from Blob is what I want. Much better than my .parse-base method 09:18
timo apart from .parse-base, there's also this: 09:19
m: say :256[0x10, 0x20, 0x30, 0x40] 09:20
camelia 270544960
timo m: say :256[0x10, 0x20, 0x30, 0x40].base(16)
camelia 10203040
timo m: say :10[1,2,3,4,5,6] 09:21
camelia 123456
timo m: say :65536[0xabcd, 0xaffe, 0x9876].base(16) 09:22
camelia ABCDAFFE9876
timo it's a little bit like parse-base but it operates on integers instead of strings. i guess it's a bit like polymod in reverse?
basically it's $accum = $accum * $base + $_ for @numbers i think 09:23
09:42 johnjay left 10:03 johnjay joined 10:14 johnjay left 10:48 johnjay joined 10:51 guifa joined, guifa_ left 11:24 leppard joined 12:23 itaipu joined
disbot4 <librasteve> .oO guess I need to add that to cragcli.info 13:24
13:25 librasteve_ joined
disbot4 <librasteve> hi. i just submitted Slangify: The Case for DSLs in LLM Workflows to Hackernews news.ycombinator.com/item?id=48460953 … your comments on this topic would be very welcome to help it gain momentum 13:37
14:49 belluzj joined
tbrowder timo: yes, as in the old song about super man: lizmat's everywhere, she's everywhere! 14:59
15:34 human-blip left 15:35 librasteve_ left 15:36 human-blip joined 15:53 johnjay left 15:54 johnjay joined 15:59 johnjay left 16:00 johnjay joined 16:11 DarthGandalf joined 16:49 human-blip left 16:50 human-blip joined 16:53 sjn left 17:01 johnjay left 17:05 belluzj left 18:18 jjido joined 18:27 johnjay joined 18:52 swaggboi left 18:56 swaggboi joined, librasteve_ joined 19:08 jjido left 19:46 leppard left 20:36 jjido joined 21:34 Geth left 21:55 RakuIRCLogger left 22:31 Geth joined 22:40 merp left 22:42 merp joined 22:43 jjido left 23:29 Sgeo joined