|
00:16
finanalyst left
|
|||
| [Coke] | nice to see someone take a stab at that repo! | 00:49 | |
|
02:48
guifa left
02:54
guifa joined
04:50
guifa left
05:08
guifa joined
|
|||
| Geth | rakudo: patrickbkr++ created pull request #5753: Get PRs working for everyone |
07:32 | |
|
09:48
sena_kun joined
|
|||
| timo | BBIAB | 09:52 | |
|
09:52
timo left
10:02
sena_kun left
10:06
timo joined
10:07
finanalyst joined
11:17
finanalyst left
|
|||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/01/06/2025-01/ | 12:53 | |
|
16:15
guifa left
16:39
guifa joined
17:25
finanalyst joined
|
|||
| ab5tract | Anyone know why dispatch_order returns candidates that are not concrete? | 17:44 | |
| lizmat | that feels... sub-optimal ? | 17:45 | |
| what are the not-concrete types that are returned ? | |||
| timo | lizmat, do you have a cycle or two to look at a change for HYPER and METAOP_HYPER I'm trying as result of looking at antonon's "good permutations" code? | 18:21 | |
| lizmat | sure | ||
| ab5tract | lizmat: they all seem to be `Mu` | 18:24 | |
| I'll poke at it a bit more | |||
| lizmat | or nqp::null ?? check with nqp::isnull ? | 18:25 | |
| Geth | rakudo/maybe_lower_hyper_startup_overhead: d84b474935 | (Timo Paulssen)++ | src/core.c/metaops.rakumod Make hyper infix metaop very slightly cheaper to invoke In sub HYPER, don't use slurpy capture, in sub METAOP_HYPER create the Hyper instance once up front and invoke infix on it every time it's called. |
18:26 | |
| timo | spec test looks clean, i only have the result that the script with good_permutations that i last posted as a gist in #raku is faster with this, and the spesh log also looks a bit nicer | 18:27 | |
| lizmat | timo: doesn't that require a "proto sub HYPER(|) {*} ? | ||
| timo | hum, i didn't need it for stuff to be clean | 18:28 | |
| lizmat | weird, I thought all multis required a proto in the setting ? | 18:29 | |
| hmmm is the case for .infix() covered ? | 18:30 | ||
| timo | not sure if it's possible. you mean like when you [>>-<<] [] ? | 18:32 | |
| m: say [>>-<<] [] | |||
| camelia | Too few positionals passed; expected 2 arguments but got 0 in block <unit> at <tmp> line 1 |
||
| timo | m: say [>>-<<] [1] | ||
| camelia | 1 | ||
| timo | m: say [>>-<<] [1,2] | ||
| camelia | -1 | ||
| timo | that "too few positionals passed" could be the "smoking gun" here? | 18:33 | |
| but that's before my patch :) | |||
| it'd be kinda cool if we could create the Hyper instance at compile or optimizer time statically for the frame it's in, since it doesn't have any internal state apart from "does it dwim left or right" and "what is the operator" | 18:34 | ||
| lizmat | yeah, plenty of opportunity like that in RakuAST in the future :-) | 18:36 | |
|
18:36
finanalyst left
|
|||
| timo | 16.35% total time (inclusive) spent in method !predictive-iterators, second place GrepAccepts's pull-onewith 9.9% inclusive; method infix from Hyper is at 5th place by exclusive time with 3.92% exclusive, 26.36% inclusive time | 18:39 | |
| so we do spend a lot of time generating the list of "is a digit at its spot?" values (values >>-<< (1..9)) | |||
|
18:41
summerisle is now known as eop,
eop is now known as eof
|
|||
| timo | hmm. is there something better than $foo == Inf and $foo === Inf? the first one converts $foo to Real via Bridge if it's an Int for example, the other calls WHICH to create the which-string, which is also not quite perfect | 18:58 | |
| lizmat | nqp::eqaddr(nqp::decont($foo),Inf) ?? | 18:59 | |
| timo | is that good enough? | 19:00 | |
| m: use nqp; say nqp::eqaddr(nqp::decont(Inf), Inf.new); say nqp::eqaddr(nqp::decont(Inf), Inf.clone); | 19:01 | ||
| camelia | 0 0 |
||
| timo | oh | ||
| lizmat | m: use nqp; my $foo = Inf; say nqp::eqaddr(nqp::decont($foo),Inf) | 19:02 | |
| camelia | 1 | ||
| timo | m: use nqp; say nqp::eqaddr(nqp::decont(Inf), nqp::decont(Inf.new)); say nqp::eqaddr(nqp::decont(Inf), nqp::decont(Inf.clone)); | ||
| camelia | 0 0 |
||
| lizmat | why the Inf.new? | ||
| timo | m: use nqp; my $foo = Inf; say nqp::eqaddr(nqp::decont($foo),Inf); $foo = Inf + 1; say nqp::eqaddr(nqp::decont($foo),Inf); $foo = Inf.new; say nqp::eqaddr(nqp::decont($foo),Inf); $foo = Inf.clone; say nqp::eqaddr(nqp::decont($foo),Inf); | ||
| camelia | 1 0 0 0 |
||
| timo | to show that you can have a value that is Inf but isn't nqp::eqaddr to Inf | ||
| lizmat | aha.... but Inf + 1 should return the original Inf in my opinion ? | 19:03 | |
| timo | unless that's inefficient :) | ||
| lizmat | why would that be inefficient ? | 19:04 | |
| the extra checking you mean? | |||
| timo | yes | 19:05 | |
| lizmat | m: dd Inf.new | ||
| camelia | 0e0 | ||
| timo | oh | ||
| hehe. | |||
| lizmat | Inf.new does not do what you think | ||
| timo | m: dd Inf.clone | ||
| camelia | Inf | ||
| timo | but this one does | ||
| m: dd Inf + 1 | |||
| camelia | Inf | ||
| timo | interesting. i would have expected that if i make a list of lists with the results of rotating (1..9).list for values 0 through -8 it would be faster than to rotate the array of permutated values and compare it to (1..9) | 19:10 | |
| but it's actually a bit slower than how all this performed before my performance improvement attempts | 19:11 | ||
|
19:11
guifa left
|
|||
| lizmat | on reified lists, .rotate just creates a special iterator that doesn't move any data around | 19:11 | |
| maybe that's the reason ? | |||
| timo | oh, let's see | 19:12 | |
| getting it into an Array "for sure" didn't help i think | 19:17 | ||
| (^9).map(-> int $_ { 1 if @p[$_] == @cmp[$_] }) is just a little faster all in all than the one with @p >>-<< (1..9) and .grep(0) | 19:19 | ||
| making a custom "has-exactly-one($list)" and "has-exactly($list, $value)" is a lot faster than `.head(2).elems == 1` | 19:28 | ||
| my $it := $list.iterator; return ($it.pull-one === $value && $it.pull-one =:= IterationEnd); | 19:29 | ||
| that's the implementation of has-exactly, the other one is the same with === $value replaced by !=:= IterationEnd | |||
|
19:43
guifa joined
|
|||
| timo | the iterator of `(^9).map(-> int $_ { 1 if @p[$_] == @cmp[$_] })` is a good bit faster than the one of `(^9).map(-> int $_ { @p[$_] - @cmp[$_] }).grep(0)`, but maybe that's to be expected? | 19:45 | |
|
19:48
sena_kun joined
|
|||
| timo | code's even uglier now, with an explicit for loop that has an int counter, but it's also even faster by a good bit | 19:50 | |
| lizmat | yes, because .grep is an extra level if indirection | ||
| *of | |||
| timo | 0.667389519 seconds time elapsed / 5.393 CPUs utilized | ||
| 2.555046670 seconds time elapsed / 1.021 CPUs utilized without hyper | 19:51 | ||
| m: use nqp; my $var = Inf; say nqp::isinf($var<>) | 20:15 | ||
| camelia | ===SORRY!=== No registered operation handler for 'isinf' |
||
| timo | there is only "isnanorinf"? | ||
|
20:15
kjp joined
|
|||
| timo | i guess if you decont_n you can safely == nqp::inf | 20:15 | |
|
20:27
kjp left,
kjp joined
20:47
guifa left
20:54
guifa joined
|
|||
| patrickb | bisectable6: gist.github.com/patrickbkr/8af931a...9442dabaf7 | 21:56 | |
| bisectable6 | patrickb, Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
| patrickb, Output on all releases: gist.github.com/e530e45ff8c76df76d...d4f41a8219 | |||
| patrickb, More than 3 changes to bisect, please try a narrower range like old=2024.12 new=HEAD | |||
| patrickb | bisectable6: gist.github.com/patrickbkr/8af931a...9442dabaf7 2022.07 2024.12 | 21:59 | |
| bisectable6 | patrickb, Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
| patrickb, Output on all releases: gist.github.com/53a2cf73c3cd434e39...0cce5ecda0 | 22:00 | ||
| patrickb, More than 3 changes to bisect, please try a narrower range like old=2024.12 new=HEAD | |||
| patrickb | bisectable6: good=2022.07 bad=2024.12 gist.github.com/patrickbkr/8af931a...9442dabaf7 | ||
| bisectable6 | patrickb, Bisecting by output (old=2022.07 new=2024.12) because on both starting points the exit code is 0 | 22:01 | |
|
22:05
bisectable6 left
|
|||
| timo | docs.raku.org/type/Any#method_pairs - this says "[...] if the invocant is a type object [...]" and then "for a value object, [...]" which i think is at least an odd way to call it, but might also be confusing if you know about Value Types? | 22:13 | |
| or i guess Value Object, as in ValueObjAt. but i don't think we actually have something we call "value object"? | 22:14 | ||
| the docs page for ValueObjAt starts with "A subclass of ObjAt that should be used to indicate that a class produces objects that are value types", i'm not sure if that's how you can use "value types" either though? | 22:15 | ||
| and while i'm at it, should that page recommend to use `self.^name` in the WHICH method example? or should instances of subclasses automatically be considered equivalent to an instance of the superclass unless the subclass implements WHICH itself? which also includes adding mixins with "but" or "does" changing the WHICH if you use "self.^name" but not if you put the name of the class in the code, | 22:17 | ||
| or use ::?CLASS or what it's called | |||
| > If two objects compare equally via ===, their .WHICH methods return the same ObjAt object. | 22:18 | ||
| this sounds kind of backwards? | 22:19 | ||
|
22:20
bisectable6 joined,
bisectable6 left,
bisectable6 joined
|
|||
| patrickb | bisectable6: good=2023.06 bad=2024.12 gist.github.com/patrickbkr/8af931a...9442dabaf7 | 22:22 | |
| bisectable6 | patrickb, Bisecting by output (old=2023.06 new=2024.12) because on both starting points the exit code is 0 | ||
|
22:27
bisectable6 left
22:30
finanalyst joined
|
|||
| Geth | ¦ rakudo: patrickbkr self-assigned Nested whenevers cause supply values to change their order github.com/rakudo/rakudo/issues/5754 | 22:32 | |
|
22:41
bisectable6 joined,
bisectable6 left,
bisectable6 joined
|
|||
| timo | got you some debug output | 23:02 | |
| the thing i did there sounds kind of very much like a thing we might want a single-line or single-flag way to enable | 23:09 | ||
|
23:24
sena_kun left
|
|||