Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-09-28

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:07 harrow joined #moarvm
01:11 colomon joined #moarvm
01:34 [Coke]_ joined #moarvm
01:35 TimToady_ joined #moarvm
01:45 tokuhiro_ joined #moarvm
01:48 mtj_ joined #moarvm
01:54 TimToady joined #moarvm
02:58 colomon joined #moarvm
04:39 vendethiel joined #moarvm
05:42 zakharyas joined #moarvm
06:16 FROGGS joined #moarvm
06:21 Ven joined #moarvm
07:42 zakharyas joined #moarvm
08:41 TimToady joined #moarvm
09:07 Ven joined #moarvm
09:10 cognominal joined #moarvm
09:11 jnthn timotimo: Could move the initialization off to another method, then it's just self!setup() unless $!is-setup; or however it works
09:11 jnthn timotimo: Bit like the slowpath pattern in various bits of List/Array
09:29 Ven joined #moarvm
09:32 camelia joined #moarvm
09:39 zakharyas joined #moarvm
09:48 Ven joined #moarvm
09:56 nebuchadnezzar joined #moarvm
10:00 nebuchad` joined #moarvm
10:38 jnthn Somewhere, it seems we've got a 16-bit storage of SC indexes when it should be 32 bit
10:38 jnthn The last class before Slang in CORE.setting has SC index 64340. Slang has 137.
10:39 FROGGS joined #moarvm
10:51 brrt joined #moarvm
10:51 brrt good moarning
10:52 brrt can we rid us of the constifications again? it rains compiler warnings even on gcc
10:52 jnthn Think I found it
10:53 FROGGS jnthn++
10:53 jnthn urgh
10:53 jnthn (the urgh was to brrt)
10:53 FROGGS ahh
10:53 brrt found what?
10:53 FROGGS :D
10:53 brrt what did i do :-)
10:53 FROGGS much confusion
10:53 brrt oh, moan about consts
10:53 jnthn brrt: Nothing; the CORE.setting hit a magical number of objects and it seems there was a copy-pasto
10:54 brrt aha....
10:56 * FROGGS is eager to see it
11:04 timotimo huh, i could have thought of that, it seems like such an obvious spot to look at in retrospect :|
11:07 dalek MoarVM: 1434283 | jnthn++ | src/mast/compiler.c:
11:07 dalek MoarVM: Correct casts; should be to 32, not 16, bits.
11:07 dalek MoarVM:
11:07 dalek MoarVM: Fixes an overflow in MAST assembly of Rakudo's CORE.setting, which
11:07 dalek MoarVM: caused some really odd bugs.
11:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/14342833ce
11:13 FROGGS timotimo: that's always the case, isnt it?
11:13 timotimo often
11:14 lizmat time to bump NQP and rakudo ?
11:16 jnthn lizmat: Be patient :P
11:16 lizmat .oO( you doctor, me patient  :-)
11:17 jnthn (Was waiting on a spectest run, and saw a lot of fallout, but it's heredoc change related)
11:19 lizmat wonder if this also fixes the panda issues?
11:22 jnthn lizmat: Which panda issue?
11:23 lizmat the one with return and named params ?
11:23 jnthn No
11:23 lizmat :-(
11:23 jnthn We've got that pretty well hunted down
11:23 lizmat .oO( will be more patient :-)
11:23 jnthn brrt++ got an even smaller test case recently
11:24 lizmat Q: is Metamodel::Primitives supposed to be public ?
11:24 jnthn Yes
11:24 jnthn It's the public interface to various MOP guts
11:24 jnthn To prevent people from having to drop to the NQP level
11:24 jnthn (e.g. so they don't have to use nqp:: ops)
11:24 timotimo ah, this is the kebab-case question
11:24 lizmat ok, it should be tested then  :-)
11:25 timotimo oh, it isn't
11:25 jnthn There's no kebab-case question 'cus MOP stuff is _'d :)
11:25 timotimo okeh :)
11:25 jnthn And if I claim traits are MOP-y I guess I can avoid a chunk of other pondered renaming too :P
11:35 brrt joined #moarvm
11:44 zakharyas joined #moarvm
12:02 Peter_R joined #moarvm
12:04 brrt funny, the lookup of $*IN_RETURN is always the same
12:10 brrt or, the place in which it is found
12:10 brrt and then, suddenly, it isn't. weird huh
12:11 timotimo OK, so just dump the whole core before and after it changes and binary diff
12:11 timotimo should be easy!
12:11 timotimo what do you mean everything changes!!
12:20 brrt :-)
12:20 brrt i'll have to run it under a gdb, which is a bit more than i can do now
12:21 brrt but it certainly seems a bit more tractable that way
13:15 ggoebel joined #moarvm
13:32 brrt joined #moarvm
13:43 Ven joined #moarvm
14:20 nwc10 The NQP test for nqp::sha1 fails on Big Endian
14:20 nwc10 It looks like this isn't a regression
14:20 nwc10 Tests for it were added as part of the JS porting
14:20 brrt aha
14:21 brrt well, big endian is for wusses anyway, doesn't even have a decent JIT yet
14:21 brrt :-P
14:21 nwc10 as best I can tell, the implementation is in 3rdparty/sha1/sha1.c
14:21 timotimo so is there some define flag we don't set that it expects?
14:22 nwc10 OK
14:22 nwc10 64 bit Power
14:22 nwc10 will try 32 bit Power
14:22 nwc10 I see this
14:22 nwc10 #define rol(value, bits) (((value) << (bits)) | ((value) >> (32 - (bits))))
14:22 nwc10 And I fear that that isn't portable
14:23 nwc10 specifically, IIRC, bitshift shift by more than the size of the value is undefined behaviour
14:24 [Coke] hoelzro: I get that RT #126202 isn't doing what you want, but it's following the "spec", yes? So is the request that the spec change?
14:24 nwc10 oh, I didn't look far enough
14:24 nwc10 #ifdef WORDS_BIGENDIAN
14:24 nwc10 danger sign!
14:24 [Coke] crap, ww. And I was so careful with my previous sends today.
14:27 timotimo danger, nicholas robinson
14:32 FROGGS joined #moarvm
14:47 Ven joined #moarvm
15:13 diakopter joined #moarvm
16:04 Ven joined #moarvm
16:20 tokuhiro_ joined #moarvm
16:48 brrt joined #moarvm
17:21 tokuhiro_ joined #moarvm
18:18 vendethiel joined #moarvm
18:56 ggoebel joined #moarvm
19:23 tokuhiro_ joined #moarvm
19:43 tokuhiro_ joined #moarvm
20:35 hoelzro this subsignature memory leak is driving me nuts
20:38 masak how so?
20:38 masak could you be more specific? :P
20:40 hoelzro masak: well, I found a memory leak when you call a routine that uses a subsignature
20:40 hoelzro I discovered that callsite objects were being allocated, but never freed
20:40 hoelzro so I added a flag to MVMCallCaptureBody to indicate whether or not it owns its callsite object
20:40 hoelzro which fixed the leak
20:40 hoelzro *but*
20:41 hoelzro that same "fix" causes rakudo to segfault when building CORE.setting
20:41 hoelzro ...unless spesh is disabled
20:41 hoelzro I've chronicled the whole thing here https://rt.perl.org/Ticket/Display.html?id=126183
20:42 hoelzro I'm leaving for a 2 week vacation on Thursday, so I was really hoping I would be able to fix it before I left
20:50 masak I can see why!
20:50 masak hope you find it!
20:51 hoelzro thanks =)
20:53 masak wow, an RT ticket with a plot in it!
21:00 timotimo i expect we take a reference to a callsite "directly" when specializing things
21:04 cognominal joined #moarvm
21:16 hoelzro timotimo: that's what I would expect, but my spesh fu is very weak
21:20 timotimo let's see ...
21:24 timotimo hum.
21:25 timotimo so we don't have a golf yet?
21:25 hoelzro I haven't tried golfing down CORE.setting o_O
21:25 timotimo hehe
21:25 timotimo well, you could perhaps have tried to build a script that tickles the same bug
21:27 hoelzro hmm
21:27 hoelzro yeah, I don't see why not
21:27 hoelzro =)
21:27 timotimo if you know the name of the right method you could also MVM_SPESH_LOG and look for what code it builds after speshing (look for "Finished specialization of")
21:29 hoelzro the closest I've gotten to figuring it out is that it's routine_def's usage of onlystar that breaks things
21:44 tokuhiro_ joined #moarvm
22:04 lizmat_ joined #moarvm
23:46 tokuhiro_ joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary