🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Log inspection is getting closer to beta. If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 25 August 2021.
Maxdamantus Hmm .. this is a bug, right? 03:17
$ cat /dev/urandom | head -c 100000 | raku -e 'say slurp("/dev/stdin", :bin).elems;'
65536
Looking at strace, it does a read with size 1048576, and it stops reading if the returned size is less than that. 03:18
If it receives a full 1048576 bytes, it will do another read (potentially blocking), so seems like it's just assuming that it's a regular file or something. 03:19
elcaro_ I made a Wordle clone with Raku just for fun... teaching my kids about spelling and programming in one go 07:15
gist.github.com/0racle/77fb3e50b6b...2188bb81d8
MasterDuke nice 09:17
Voldenet Maxdamantus: maybe a workaround, but `cat /dev/urandom | head -c 100000 | raku -e 'say "/dev/stdin".IO.open(:bin).slurp.elems;'` works fine 11:22
makes me wonder why `slurp("/dev/stdin", :bin)` behaves differently 11:23
Maxdamantus Yeah, I noticed that. A bit more awkward though since you need to capture the handle to avoid leaking the file descriptor.
(Not very nice to just open a file and not close it) 11:24
Voldenet Well yes, but `sub my-slurp(IO() $path, :$bin) { my $p = $path.open(:$bin); LEAVE $p.close; $p.slurp };` also works without that bug 11:35
moon-child augment class Handle { method slurp { ... } } 11:37
:)
Voldenet I wish LEAVE worked like defer, btw 11:39
Voldenet in fact, this would be super nice to use: say "/dev/stdin".IO.open(:bin).defer-with(*.close).slurp.elems; 11:43
moon-child you would an explicit '.done' or similar at the end 11:44
otherwise I think you could rig it so that you'd be able to write that as is
lizmat Supplier.slurp() takes a :close argument ? 11:45
actually IO.slurp takes a :bin
so maybe "/dev/stdin".IO.slurp(:bin).elems" should work ? 11:46
Voldenet > cat /dev/urandom | head -c 14120000 | raku -e 'say "/dev/stdin".IO.slurp(:bin).elems;' 11:47
i see nothing close to the number on the left
with .open(:bin) inbetween I do though
lizmat hmmm... that feels strange 11:58
Voldenet github.com/rakudo/rakudo/blob/10c3...h.pm6#L574 12:21
…can't readfh return fewer bytes than expected? 12:22
lizmat as far as I know, yes, what you specify is the max number of bytes to receive 12:24
moon-child check EAGAIN or some such iirc
might be the problem
Voldenet eh, just instead of iseq_i(…, slurp-size) do isne_i(…, 0) 12:31
Skarsnik I think I remember stdin/stdout being already available at async::io on start up, that maybe the issue? 13:00
Maxdamantus It's not specific to stdin. 13:18
$ raku -e 'say slurp(@*ARGS[0], :bin).elems;' <(head -c 100000 /dev/urandom)
65536
gfldex lolibloggedalittle: gfldex.wordpress.com/2022/01/15/ma...-hypering/ 13:42
cognominal 0+0i == 0 13:55
True
> 0+0i eq 0
False
>
Why ?
Skarsnik say 0i.Str 13:56
evalable6 0+0i
Skarsnik eq coerce into string 13:57
cognominal Yes but I would expect. === things to be coerced into eq things
Nemokosch what does that mean? 14:02
m: dd 0+0i === 0 14:05
Voldenet m: dd 0+0i === 0 14:06
camelia Bool::False
Voldenet 0+0i has different value identity than 0
Skarsnik say (0+0i).WHAT 14:07
evalable6 (Complex)
Nemokosch okay, so 0+0i and 0 are NOT "=== things" in the first place
and from this point, there is nothing really surprising
string representation is more verbose than numeric representation 14:08
Voldenet say 0+0i + 1 === 1+0i 14:09
evalable6 True
Voldenet say 0+0i === 0.Complex 14:10
evalable6 True
cognominal Nine said the same thing in #raku-dev.. Thx everyone. I got rusty even if I have trouble with rust 14:14
Voldenet counterintuitively you'll never get rusty if you code in rust frequently ;) 14:20
stanrifkin how i enter 200 in roman numerals? 20:35
ⅭⅭ
i copied that from unicode-table.com
one Ⅽ works but two of them not.
when i quite them "ⅭⅭ" it just print ⅭⅭ 20:36
and "ⅭⅭ" + 0x200 is says it can't convert to number 20:37
but Ⅽ + 0x200 works fine
japhb Looking for Slang::Roman or Math::Roman maybe? 20:38
stanrifkin haven't looked into that
thought raku can do it native
[Coke] check the unicode properties on those characters. There's a difference between numbers/numerals, if I recall. 20:49
stanrifkin eval: Ⅽ + 0x200
evalable6 WARNINGS for /tmp/J1HIEdYGmN:
Useless use of "+" in expression "Ⅽ + 0x200" in sink context (line 1)
stanrifkin hm...
[Coke] you need to output it. 20:50
stanrifkin eval: say Ⅽ + 0x200
evalable6 612
stanrifkin eval: say ⅭⅭ + 0x200
evalable6 (exit code 1) 4===SORRY!4=== Er…
stanrifkin, Full output: gist.github.com/d6925d556caf3815e6...d5e89037e1
stanrifkin Slang::Roman works. But not in the Repl. 21:07