github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt good moarning 08:19
nwc10 good *, brrt
jnthn o/ 10:26
nwc10 \o
The P in pea stands for "Partial"?
jnthn Yes 10:38
lizmat
.oO( I thought it stood for Pea, in the great GNU tradition :-)
 10:48
jnthn nwc10: I'll submit a talk about it for GPW, which I guess you'll be at? :) 10:57
nwc10 I plan to be 10:59
nine jnthn: the nqp::neverrepossess you added in github.com/rakudo/rakudo/blob/mast...ar.nqp#L65 is not enough. The cache gets serialized anyway and the MVM_CF_NEVER_REPOSSESS on the object doesn't survive serialization/deserialization. 11:06
nine jnthn: this causes references to CompUnit::Repository::Staging to end up in the installed Inline::Perl5::Parent when they shouldn't. That's why we end up with missing dependencies when loading Inline::Perl5 from an RPM package 11:06
References to CompUnit::Repository::Staging's SC to be precise 11:07
jnthn nine: Well, it's enough in the sense that it avoids the repossessions it was aimed to eliminate, but yes, I can see that it'd not be enough for avoiding the cache being serialized in the first place. 11:16
Which is indeed desirable.
Though I kind of wonder how that's happening anyway
Also, if a lexical is the wrong way to hold that cache 11:17
Especially given it's not threadsafe in the light of multiple concurrent evaluations
jnthn wonders if we should hang it off $*W or something 11:18
Or make it a dynamic in TOP or comp_unit, perhaps
That probably means nothing closes over it, so we don't have the issue 11:19
nine I'm gonna give that a try and see how it affects performance. Putting it into an attribute on STD costs ~ 10s in settings compilation 11:23
jnthn Attributes in a curosr are per cursor 11:27
So that won't help at all
MasterDuke brrt: is there any reason (eq|le|lt|ge|gt)_n templates shouldn't just be the same as the *_i variants? 13:10
MasterDuke or do they and coerce_(in|ni) need that floating point support you've been working on? 13:14
lizmat And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/01/14/...it-spring/ 15:08
brrt lizmat++ 15:11
MasterDuke brrt: btw, did you catch my question earlier? 15:19
brrt probably not 15:29
nine MasterDuke: I'm quite sure at least coerce_(in|ni) will need float support 15:31
Really the same for (eq|le|lt|ge|gt)_n 15:32
MasterDuke nine: i added (eq|le|lt|ge|gt)_n as copies of *_i and nothing crashed (unlike my attempts at coerce_(in|ni)), but i haven't run a spectest yet 15:40
brrt MasterDuke: what was your question? 15:50
MasterDuke is there any reason (eq|le|lt|ge|gt)_n templates shouldn't just be the same as the *_i variants? 15:51
or do they and coerce_(in|ni) need that floating point support you've been working on?
brrt ehm.....
that is a good question....
nine MasterDuke: have you tested the semantics? 16:00
brrt so I don't know if you did so wittingly, but I've been looking at generic/polymorphic opcodes in the expr JIT
the tl;dr - if you do that *today*, it totally will not work 16:01
MasterDuke brrt: fwiw, only two spectest fails, t/spec/S32-io/io-path-extension.t and t/spec/S05-metasyntax/regex.t 16:10
brrt MasterDuke: so semantically, a (lt num num) is very different from (lt int int) 16:24
in the current implementation, you'd only compile the latter, not the former
in the jit-expr-float branch, you'd compile the first, but it doesn't work because the tiler doesn't think a 'num' is a value that warrants a register
(and that's true because I'm still figuring out how to get a correct, simple implementation of the idea of 'register class' 16:25
arguably, the register class is the full set of registers that may be allocated for a value 16:28
hmm, that gives me an idea
brrt okay, so, if the rule of genericity is this: 16:31
- an operand that is generic on its input can be generic on its output
- if an operator has two generic operands, they must be equal
- no operator can be monomorphic on input and polymorphic on output 16:32
then. the whole group of comparison and arithmetic operators can legally be generic
MasterDuke that sounds nice
brrt it is pretty nice :-) 16:42
nine jnthn: hanging the cache off $*W fixes my issue and does well WRT performance :) 17:06
jnthn nine: Cool :) 19:58
jnthn D'oh, water pipe just down the road burst... 20:01
brrt oops
lizmat jnthn: do you agree that something like "my %h is Set[Int]" should just work ? 20:02
nwc10 jnthn: impending tea crisis? 20:04
jnthn nwc10: Yeah but I can drink beer instead :) 20:07
lizmat: Um...maybe but there's a syntactic curiosity there.
lizmat ah? 20:08
jnthn We parse a circumfix after the name
lizmat right
jnthn I can't quite remember how we pass those off to the trait_mod
lizmat well, I'm looking at that code now
well, trying to make sense of it :-)
jnthn But I think if Set is a type then you'll get it as an extra argument and then call call .^parameterize(|@stuff) 20:09
And then it can work
nwc10 jnthn: beer fridge for the win!
lizmat jnthn: *that* part is already working
it's the syntax "is Set[Int]" that is crashing
jnthn lizmat: Right, so then it is in theory just wiring the [Int] into the call to .^parameterize
lizmat m: my %s is Set[Int]
camelia ===SORRY!=== Error while compiling <tmp>
Can't use unknown trait 'is ' in a variable declaration.
at <tmp>:1
------> my %s is Set[Int]⏏<EOL>
expecting any of:
TypeObject
default
dynamic
…
lizmat huh? 20:10
jnthn Right, I bet you need an extra multi candidate receiving a third rgument
lizmat ah... hmmm...
jnthn multi trait_mod:<is>(Variable:D $v, Mu:U $type, @params) { } or so
lizmat ack... will check
brrt anyone here has plans to go to FOSDEM this year? 21:05
lizmat woolfy and /me will be there at the Perl booth 21:07
brrt cool :-)
brrt brrt-to-the-future.blogspot.com/20...s-and.html 21:34
for whom it may concern, or interest 21:35
lizmat .tell jnthn I created the candidate to handle "my %s is Set[Int]", but I have **no** clue as to how to get the parameterized set into position 22:45
yoleaux lizmat: I'll pass your message to jnthn.
lizmat gives up for now 22:50

Powered by Cro and the Raku® Programming Language.

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

Thank you!