01:43 tokuhiro_ joined 02:05 lizmat joined 02:17 tokuhiro_ joined 02:47 ilbot3 joined 05:19 vendethiel joined
JimmyZ Unhandled exception: Bytecode stream corrupt (missing magic string) # ^^ 06:33
no, it is 'set encoding requires an object with REPR MVMOSHandle' 06:34
flussence: looks like a rakudo bug 06:38
06:39 domidumont joined 06:44 domidumont joined 07:04 domidumont joined 07:19 domidumont joined, vendethiel joined 08:28 leont joined 08:39 zakharyas joined
stmuk wonders why we have new deprecations in a beta peroid 11:02
jnthn nwc10: Thanks for the ASAN :) 11:24
dalek arVM: 1e4912d | jnthn++ | src/strings/normalize.c:
Remvoe bogus tweaking of end of normalized chars.

We're in the middle of normalizing at this point, and update this afterwards. And we can now be sure we're never re-normalizing chars since the recent patch fixing that.
11:48
13:53 JimmyZ joined 14:44 leedo joined, ashleydev joined 14:54 _longines joined
nwc10 jnthn: ASAN is tolerating you again. 15:24
(although if you're not careful it will bring you another dead mouse to try to encourage you to learn to be a better hunter) 15:25
dalek arVM: f601e24 | jnthn++ | src/ (4 files):
Be sure to chomp separators at eof.
15:28
jnthn Phew :)
Latest one should be benign. :) 15:29
.oO( famous last words )
Bah, managed to get a runaway moar process that allocated 20 gigs before I could stop it 15:59
Oddly enough, 'cus of a bug in handling the BOM 16:00
[Coke] the BOOM?
dalek arVM: 9fd3005 | jnthn++ | src/strings/utf8.c:
After eating BOM, mark we indeed used the bytes.

Otherwise, we won't correct mark eof.
16:01
jnthn Somebody set up us the BOM...
nwc10 how *fast* is it at allocating 20 Gigs? Is our performance dangerously good, or safely pathetic?
jnthn I had to reboot.
The first time
'cus I wasn't watching
Second time I was, to see which test did it
And it hit 11GB in a second or two 16:02
nwc10 is that a live test that I'm currently running that will go boom?
jnthn Then hit the swap
Uh...yes
nwc10 OK. I'll kill that
jnthn Oh wait
No
You're safe
It's a Moar bug, but an unpushed Rakudo patch that exposed it 16:03
nwc10 have already killed. will rebuild with f601e242ef
16:52 hoelzro_ joined, JimmyZ_ joined 16:53 lue joined 16:54 arnsholt_ joined 16:57 stmuk_ joined 17:07 arnsholt_ joined 17:52 domidumont joined 18:24 leont joined 18:33 FROGGS joined 18:34 zakharyas joined 18:46 arnsholt joined
timotimo nwc10: i imagine that 11GB would have been allocated from a somewhat tight loop in C-land, so ... performance wise that doesn't say much about moar, i expect 20:20
21:18 flussence joined
timotimo jnthn: do you have a little roadmap what the NFA generator needs to learn to make "\r\n" work properly? 21:36
i expect since it works on a Str, it'll want to know about the special grapheme that \r\n turns into? 21:37
and that that is supposed to match \r, \n and \r\n?
i haven't looked into the API we expose to take apart graphemes yet 21:40
21:48 cygx joined
cygx is there any way to dump the serialized objects from a bytecode file? 21:48
context: a simple `sub foo is native {*}` compiles to about 1m of bytecode 21:50
timotimo cygx: i had a script that does that! 23:55
er ... well, it grabbed all serialized object from a given SC, i think i gave the SC id in the code via a string? 23:56
anyway, let me dig it up for you
oof, so many unversioned junk files in all my repositories 23:57
oh, huh 23:58
apparently there's a patch to moarvm that'd print out the scid and index and such into a logfile and then this script i had prints out what those things are 23:59