00:07 harrow joined 01:11 colomon joined 01:34 [Coke]_ joined 01:35 TimToady_ joined 01:45 tokuhiro_ joined 01:48 mtj_ joined 01:54 TimToady joined 02:58 colomon joined 04:39 vendethiel joined 05:42 zakharyas joined 06:16 FROGGS joined 06:21 Ven joined 07:42 zakharyas joined 08:41 TimToady joined 09:07 Ven joined 09:10 cognominal joined
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
timotimo: Bit like the slowpath pattern in various bits of List/Array
09:29 Ven joined 09:32 camelia joined 09:39 zakharyas joined 09:48 Ven joined 09:56 nebuchadnezzar joined 10:00 nebuchad` joined
jnthn Somewhere, it seems we've got a 16-bit storage of SC indexes when it should be 32 bit 10:38
The last class before Slang in CORE.setting has SC index 64340. Slang has 137.
10:39 FROGGS joined 10:51 brrt joined
brrt good moarning 10:51
can we rid us of the constifications again? it rains compiler warnings even on gcc 10:52
jnthn Think I found it
FROGGS jnthn++ 10:53
jnthn urgh
(the urgh was to brrt)
FROGGS ahh
brrt found what?
FROGGS :D
brrt what did i do :-)
FROGGS much confusion
brrt oh, moan about consts
jnthn brrt: Nothing; the CORE.setting hit a magical number of objects and it seems there was a copy-pasto
brrt aha.... 10:54
FROGGS is eager to see it 10:56
timotimo huh, i could have thought of that, it seems like such an obvious spot to look at in retrospect :| 11:04
dalek arVM: 1434283 | jnthn++ | src/mast/compiler.c:
Correct casts; should be to 32, not 16, bits.

Fixes an overflow in MAST assembly of Rakudo's CORE.setting, which caused some really odd bugs.		 11:07
FROGGS timotimo: that's always the case, isnt it? 11:13
timotimo often
lizmat time to bump NQP and rakudo ? 11:14
jnthn lizmat: Be patient :P 11:16
lizmat
.oO( you doctor, me patient :-)
jnthn (Was waiting on a spectest run, and saw a lot of fallout, but it's heredoc change related) 11:17
lizmat wonder if this also fixes the panda issues? 11:19
jnthn lizmat: Which panda issue? 11:22
lizmat the one with return and named params ? 11:23
jnthn No
lizmat :-(
jnthn We've got that pretty well hunted down
lizmat
.oO( will be more patient :-)
jnthn brrt++ got an even smaller test case recently
lizmat Q: is Metamodel::Primitives supposed to be public ? 11:24
jnthn Yes
It's the public interface to various MOP guts
To prevent people from having to drop to the NQP level
(e.g. so they don't have to use nqp:: ops)
timotimo ah, this is the kebab-case question
lizmat ok, it should be tested then :-)
timotimo oh, it isn't 11:25
jnthn There's no kebab-case question 'cus MOP stuff is _'d :)
timotimo okeh :)
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 11:44 zakharyas joined 12:02 Peter_R joined
brrt funny, the lookup of $*IN_RETURN is always the same 12:04
or, the place in which it is found 12:10
and then, suddenly, it isn't. weird huh
timotimo OK, so just dump the whole core before and after it changes and binary diff 12:11
should be easy!
what do you mean everything changes!!
brrt :-) 12:20
i'll have to run it under a gdb, which is a bit more than i can do now
but it certainly seems a bit more tractable that way 12:21
13:15 ggoebel joined 13:32 brrt joined 13:43 Ven joined
nwc10 The NQP test for nqp::sha1 fails on Big Endian 14:20
It looks like this isn't a regression
Tests for it were added as part of the JS porting
brrt aha
well, big endian is for wusses anyway, doesn't even have a decent JIT yet 14:21
:-P
nwc10 as best I can tell, the implementation is in 3rdparty/sha1/sha1.c
timotimo so is there some define flag we don't set that it expects?
nwc10 OK 14:22
64 bit Power
will try 32 bit Power
I see this
#define rol(value, bits) (((value) << (bits)) | ((value) >> (32 - (bits))))
And I fear that that isn't portable
specifically, IIRC, bitshift shift by more than the size of the value is undefined behaviour 14:23
[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
#ifdef WORDS_BIGENDIAN
danger sign!
[Coke] crap, ww. And I was so careful with my previous sends today.
timotimo danger, nicholas robinson 14:27
14:32 FROGGS joined 14:47 Ven joined 15:13 diakopter joined 16:04 Ven joined 16:20 tokuhiro_ joined 16:48 brrt joined 17:21 tokuhiro_ joined 18:18 vendethiel joined 18:56 ggoebel joined 19:23 tokuhiro_ joined 19:43 tokuhiro_ joined
hoelzro this subsignature memory leak is driving me nuts 20:35
masak how so? 20:38
could you be more specific? :P
hoelzro masak: well, I found a memory leak when you call a routine that uses a subsignature 20:40
I discovered that callsite objects were being allocated, but never freed
so I added a flag to MVMCallCaptureBody to indicate whether or not it owns its callsite object
which fixed the leak
*but*
that same "fix" causes rakudo to segfault when building CORE.setting 20:41
...unless spesh is disabled
I've chronicled the whole thing here rt.perl.org/Ticket/Display.html?id=126183
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:42
masak I can see why! 20:50
hope you find it!
hoelzro thanks =) 20:51
masak wow, an RT ticket with a plot in it! 20:53
timotimo i expect we take a reference to a callsite "directly" when specializing things 21:00
21:04 cognominal joined
hoelzro timotimo: that's what I would expect, but my spesh fu is very weak 21:16
timotimo let's see ... 21:20
hum. 21:24
so we don't have a golf yet? 21:25
hoelzro I haven't tried golfing down CORE.setting o_O
timotimo hehe
well, you could perhaps have tried to build a script that tickles the same bug
hoelzro hmm 21:27
yeah, I don't see why not
=)
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")
hoelzro the closest I've gotten to figuring it out is that it's routine_def's usage of onlystar that breaks things 21:29
21:44 tokuhiro_ joined 22:04 lizmat_ joined 23:46 tokuhiro_ joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!