leont In particular because when would combine really well with destructuring 00:23
01:04 frost-lab joined 01:10 HarmtH_ left, HarmtH joined
gfldex leont: if `when` would just be a macro that created multi subs, dispatch could be used to do the matching. Like so gist.github.com/96fad87c7bcb1c03c5...37612aae91 01:34
leont Can anyone give me a pointer to where when is implemented, maybe I can fix my own problem 02:32
02:37 kvw_5 joined 02:39 kvw_5_ left
leont Ah, Perl6/Actions.nqp is the place to be 02:40
03:15 epony left
leont What is the difference between a pblock and a xblock? 03:23
03:55 sxmx left 04:15 sxmx joined
MasterDuke i think an xblock is a block after an expression, but i'm not terribly confident in that guess 07:54
07:58 HarmtH left 08:28 HarmtH joined, epony joined 08:29 HarmtH left 08:30 HarmtH joined 08:47 sena_kun joined
[Tux] Rakudo v2021.03-9-g5d058ea88 (v6.d) on MoarVM 2021.03-11-g13f926228
csv-ip5xs0.793 - 0.799
csv-ip5xs-208.091 - 8.217
csv-parser27.336 - 28.664
csv-test-xs-200.368 - 0.372
test7.685 - 8.581
test-t2.033 - 2.141
test-t --race0.874 - 0.891
test-t-2033.447 - 35.214
test-t-20 --race9.526 - 9.634
 09:05
nine It's kinda surprising that with all the awesomeness we have, there's just no way to read from a file handle asynchronously. Even though at a VM level IO is already handled in a separate thread. 09:11
nwc10 is that then not exposed by NQP? Or NQP does expose it, but there's no proper abstraction built on top? 09:26
lizmat wouldn't a .Supply method on IO::Handle do that ? 09:42
which we already have ?
nine IO::Handle.Supply does blocking reads. Thus: 09:58
m: react { whenever $*IN.lines { say "input: $_" }; whenever Promise.in(2) { done } }
camelia input: »Wann treffen wir drei wieder zusamm?«
input: »Um die siebente Stund‘, am Brückendamm.«
input: »Am Mittelpfeiler.«
input: »Ich lösche die Flamm.«
input: »Ich mit«
input:
input: »Ich komme v…
nine Well if you don't give it input, it will never finish 09:59
lizmat ok, so the problem is really that: that IO::Handle.Supply is doing blocking reads, right ?
nine Yes. And AFAICT there is no way to do any other reads.
lizmat not even in libuv ?
breakfast& 10:00
nwc10 nine: breakfast? :-) 10:32
nine on it :D 10:47
11:09 frost-lab left
dogbert17 lizmat++, wordcase optimization wizardry 12:05
lizmat dogbert17++ for the nudge 12:06
lizmat really misses Geth :-) 12:13
github.com/rakudo/rakudo/commit/9c...224401b40b Make Str.uniparse about 10% faster 12:14
dogbert17 m: my $a = words("abc def ghi") for ^500_000; say now - INIT now 12:23
camelia 1.765245
dogbert17 m: my $a = "abc def ghi".words for ^500_000; say now - INIT now
camelia 0.04631
dogbert17 lizmat: is the above also some constant folding trickery?
lizmat no, that looks like unnecessary overhead in the words() case 12:24
you will probably see the same with lines 12:25
dogbert17 aha
lizmat capture taking and such
lemme see if I can make that better with more candidates 12:26
dogbert17 ++lizmat
ugexe libuv just used a thread pool
dogbert17 m: say 1.765245 / 0.04631 12:27
camelia 38.118009
lizmat looks like words("abc def ghi") actually invokes Cool.words ??? 12:28
dogbert17 that doesn't sound very c... :) 12:29
lizmat yeah 12:30
looks like I can make words() and lines() (the sub versions) about 15x as fast 12:35
for the given example: bigger strings will benefit less from it :-)
12:38 Kaiepi joined 13:21 Kaiepi left 13:24 b2gills left 13:27 Kaiepi joined 13:55 b2gills joined
lizmat github.com/rakudo/rakudo/commit/b9...ee5679e357 Make lines()/words() (sub version) upto 20x as fast 13:56
14:15 Kaiepi left
dogbert17 lizmat++, you're on a roll 14:34
17:19 smarton joined 17:21 domidumont joined 18:39 domidumont left
[Tux] Rakudo v2021.03-12-gb4367a8f9 (v6.d) on MoarVM 2021.03-11-g13f926228
csv-ip5xs0.815 - 0.828
csv-ip5xs-208.230 - 8.682
csv-parser27.582 - 27.954
csv-test-xs-200.375 - 0.379
test6.912 - 7.921
test-t1.978 - 2.045
test-t --race0.890 - 0.940
test-t-2034.412 - 34.950
test-t-20 --race9.587 - 10.011
 18:43
still high, but I might have hit a busy moment earlier today
lizmat github.com/rakudo/rakudo/commit/23...d5ed099d17 Make open("file") (sub version) upto 20% faster 18:54
nwc10 Where does this end? Carefully doing the same thing to every sub, each 20% and Rakduo globally 20% faster. Somehow I doubt this :-( 18:56
lizmat++ # finding lots of small things to make much better
please don't stop
lizmat well, all of this is really to get around this not working 18:57
m: multi a() { dd }; multi a(*%_) { dd }; a
camelia Ambiguous call to 'a(...)'; these signatures all match:
()
(*%_)
in block <unit> at <tmp> line 1
lizmat this prevents one from creating multis for non-named argument cases
in general 18:58
if you have one known named arg, you can create a candidate with that named argument as mandatory
but if you have multiple named arguments, it quickly becomes untenable to keep track of all of the possible combinations 18:59
nwc10 OK - I think I get this - if those two were not faulted as "Ambiguous" then the dispatcher could make the choice, and that would be faster than having to write lots of ternary code
lizmat just to be able to have a candidate with no named args
nwc10 ternary code manually in a signle sub
lizmat right
and ths gets worse with methods, as they always have an implicit *%_ 19:00
nwc10 and your example "should" work because the two aren't ambigous - the multi candidate that takes zero arguments clearly binds more tightly
lizmat I have worked on making that optional, and got it working, only to find out that it was useless without being able to dfispatch on it 19:01
nwc10 binds more tightly for a call with zero arguments
lizmat you'd say that, but jnthn would disgagree
*disagree
as dispatch only happens on positionals
nwc10 OK.
lizmat and when they'r ambiguous, dispatch on first named arge match 19:02
hmmm... 19:03
m: multi a() { dd }; multi a(:$foo) { dd }; a
camelia sub a(:$foo)
19:05 b2gills left
lizmat fwiw, I don't understand why that would dispatch to the :$foo candidate 19:06
and I feel that jnthn has explained it to me several times already, and somehow it doesn't stick :-(
hmmm more inconsistencies: 19:19
m: class A { method words() { dd } }; words A
camelia method words(A: *%_)
lizmat m: class A { method flip() { dd } }; flip A
camelia 5===SORRY!5=== Error while compiling <tmp>
Calling flip(A) will never work with any of these multi signatures:
(Cool $s --> Str:D)
at <tmp>:1
------> 3class A { method flip() { dd } }; 7⏏5flip A
20:09 epony left 20:29 sena_kun left 21:03 smarton left 21:10 smarton joined, smarton left, smarton joined 21:16 smarton left 21:35 epony joined 22:38 brown121407 joined
MasterDuke m: dd Duration.new(Inf).tai.does(Rational) 22:59
camelia Bool::True
MasterDuke locally, after i've converted `$.tai` in Duration and Instant to be an Int, ^^^ dies with `Attempt to divide by zero when coercing Rational to Int`
in `method tai(Duration:D: --> Rat:D) { $!tai / 1000000000 }`, which i added 23:01
i can't think of a way to get the previous behavior 23:05
japhb MasterDuke: type the $!tai as Real (instead of Int or Rational or Num)? 23:10
MasterDuke hm...let's see... 23:12
japhb++ that seems to work. now on to the other test failures... 23:22
tomorrow though, time to sleep now 23:24
japhb Good sleep, MasterDuke

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!