01:14 dogbert17_ joined 13:06 ilbot3 joined
brrt ohai ilbot3 13:14
13:28 zakharyas joined 13:42 domidumont joined 13:55 FROGGS joined
FROGGS o/ 13:55
lizmat FROGGS o\
brrt \o FROGGS, lizmat 13:56
jnthn o/ eveyrone :) 13:57
yoleaux2 09:11Z <lizmat> jnthn: is there a specific reason why we have the $!shape attribute on shaped arrays? Why not determine that ad-hoc from nqp::dimensions, just like with native shaped arrays ?
13:54Z <lizmat> jnthn: is there a reason to not mixin the $!descriptor for TypedArrays only, and leave it off for Arrays ?
jnthn *everyone
nwc10 good *, *
lizmat jnthn nwc10 brrt o/
brrt good wildcards indeed
jnthn lizmat: Yes, as soon as we get to jagged arrays we'll not be able to infer it from nqp::dimensions :)
lizmat ok, and the other question ?
jnthn m: my @a; say @a.name 13:58
camelia rakudo-moar c00061: OUTPUTĀ«@aā¤Ā»
jnthn That comes from the descriptor, no?
lizmat eh... ah 13:59
eh
ah, indeed
jnthn Teletubbies...say...eh ah!
lizmat I guess the default/dynamic flags are more important though :-)
jnthn I think also it carries the default too :) 14:00
lizmat yeah
jnthn So it'll get rather involved when we do/don't need it
lizmat yeah, gotcha
jnthn Which feels a bit much to just save a pointer :)
lizmat well, it would be a pointer on a data structure that is used all over the place
but yeah, got my questions answered :-) 14:01
jnthn: what is the meaning of nqp::knowhow without parameters?
looking at the difference between adding shape to an Array and a nativearray 14:02
the nqp::knowhow seems disconnected from anything related to it, and it's not documented in github.com/perl6/nqp/blob/master/d...s.markdown
trying to fix the global deopt for every shaped array
jnthn It gets the root meta-object that all overs are based upon 14:04
lizmat basically a whatever meta object 14:05
jnthn Yeah. If you look at NQP's MOP, then all its metaobjects are knowhow Blah { }
lizmat ok
so basically I think the problem is that set-shape is mixin in the shaped role on the instance, rather than the class 14:06
jnthn There's no inheritance or role composition at that level, which is why Rakudo's rather more sophisticated MOP is implemented in terms of NQP's MOP :)
lizmat jnthn: that would cause a global deopt for each shaped array, right ? 14:07
jnthn A mixin is always a global deopt, yes
lizmat right, so if I do it to a class, it gets cached, and the deopt only happens once 14:08
possibly at compile time
jnthn Well, you don't really mix in to a class 14:10
It's an immutable operation
That is, you get back a new class
So yes, no deopt, and then you're just making instances of that
lizmat ok, gotcha
14:33 domidumont joined
lizmat afk& 14:47
14:59 dalek joined 17:06 zakharyas joined 17:19 zakharyas joined 17:39 FROGGS joined 17:56 domidumont joined 19:54 vendethiel joined 22:08 zakharyas joined 22:11 lizmat joined 23:16 geekosaur joined 23:39 geekosaur joined