|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:14
Ven`` joined
00:15
lizmat left,
p6bannerbot sets mode: +v Ven``
00:20
lizmat joined,
p6bannerbot sets mode: +v lizmat
01:05
Ven`` left
04:49
MasterDuke left
06:38
domidumont joined,
p6bannerbot sets mode: +v domidumont
07:05
domidumont left
07:32
domidumont joined,
p6bannerbot sets mode: +v domidumont
07:45
brrt joined
07:46
p6bannerbot sets mode: +v brrt
|
|||
| 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 | |
|
11:06
domidumont left
|
|||
| 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 | ||
|
11:22
robertle_ joined
11:23
p6bannerbot sets mode: +v robertle_
|
|||
| 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 | |||
|
11:31
domidumont joined
11:32
p6bannerbot sets mode: +v domidumont
12:35
Ven`` joined
12:36
p6bannerbot sets mode: +v Ven``
12:42
domidumont left
12:53
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke
12:54
MasterDuke left,
MasterDuke joined,
herbert.freenode.net sets mode: +v MasterDuke,
p6bannerbot sets mode: +v MasterDuke
12:57
domidumont joined,
p6bannerbot sets mode: +v domidumont
|
|||
| 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 | |
|
13:13
brrt left
|
|||
| MasterDuke | or do they and coerce_(in|ni) need that floating point support you've been working on? | 13:14 | |
|
13:15
zakharyas joined
13:16
p6bannerbot sets mode: +v zakharyas
14:01
Ven`` left
14:09
brrt joined
14:10
p6bannerbot sets mode: +v brrt
14:18
Ven`` joined
14:19
p6bannerbot sets mode: +v Ven``
15:00
domidumont left
|
|||
| lizmat | And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/01/14/...it-spring/ | 15:08 | |
|
15:09
domidumont joined
15:10
p6bannerbot sets mode: +v domidumont
|
|||
| 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 | ||
|
15:35
Ven`` left
|
|||
| 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 | ||
|
16:05
brrt left
|
|||
| MasterDuke | brrt: fwiw, only two spectest fails, t/spec/S32-io/io-path-extension.t and t/spec/S05-metasyntax/regex.t | 16:10 | |
|
16:22
brrt joined
16:23
p6bannerbot sets mode: +v brrt
|
|||
| 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 | |||
|
16:30
domidumont left
|
|||
| 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 | |
|
17:02
brrt left
|
|||
| nine | jnthn: hanging the cache off $*W fixes my issue and does well WRT performance :) | 17:06 | |
|
17:07
domidumont joined,
zakharyas left
17:08
p6bannerbot sets mode: +v domidumont
17:16
patrickb joined
17:17
p6bannerbot sets mode: +v patrickb
18:01
robertle_ left,
AlexDaniel left
18:45
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
18:46
ChanServ sets mode: +o AlexDaniel,
AlexDaniel sets mode: -m ,
ChanServ sets mode: -o AlexDaniel
19:22
brrt joined,
p6bannerbot sets mode: +v brrt
19:46
domidumont left
|
|||
| jnthn | nine: Cool :) | 19:58 | |
|
20:01
patrickb left
|
|||
| 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 | ||
|
20:30
brrt left
20:59
brrt joined
21:00
p6bannerbot sets mode: +v brrt
21:04
d4l3k_ joined
|
|||
| brrt | anyone here has plans to go to FOSDEM this year? | 21:05 | |
|
21:05
p6bannerbot sets mode: +v d4l3k_
|
|||
| lizmat | woolfy and /me will be there at the Perl booth | 21:07 | |
| brrt | cool :-) | ||
|
21:11
wictory[m] left,
d4l3k_ is now known as dalek
21:13
wictory[m] joined,
p6bannerbot sets mode: +v wictory[m]
|
|||
| brrt | brrt-to-the-future.blogspot.com/20...s-and.html | 21:34 | |
| for whom it may concern, or interest | 21:35 | ||
|
21:42
brrt left
|
|||
| 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 | ||
|
23:27
Geth joined
23:28
p6bannerbot sets mode: +v Geth
|
|||