github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 8 October 2013.
diakopter hm 00:00
I don't remember, but I'd think so
jnthn: does it not? 00:01
jnthn Well, if it does, MVM_HASH_EXTRACT_KEY should not need to check IS_WIDE 00:02
And if it does, then it'll do wrong things
But it would be consistently wrong so it can't be our heisenbug...
diakopter oh yeah; if it's checking IS_WIDE I think the 8-bit ones are okay too
oh hm 00:03
consequence of nfg... have to compute the hash based on the expanded string
jnthn Grr, under the debugger it works... 00:08
diakopter yeah :)
oh wait, maybe I did get that far...
argh, my memory
jnthn Though, this is weird...
Use of undeclared variable '$desired' at line 3169, near "));\\r\\n "
panicNMAKE : fatal error U1077: 'C:\\consulting\\MoarVM\\install\\bin\\moar.EXE' : return code '0x623e3c51'
See how it says "panic", but then doesn't spit out a backtrace, and the return code is weird
diakopter panic doesn't backtrace I thought 00:09
I"m pretty sure it's segmentationfail
jnthn no, I don't think it's a VM panic 00:10
It's that the method it's in is called panic
$/.CURSOR.panic(...)
But if the exception is uncaught you'd expect the error
diakopter ohh
so the backtrace printer is faulting
jnthn yeah
presumably due to some other corruption
But it don't do it under the debugger. Otherwise it'd have been a great clue. 00:11
diakopter but the debugger does special things with stderr
well, maybe that wouldn't matter
jnthn no, doesn't
diakopter it at least rewrites some code
jnthn It not only doesn't segv
It doesn't even think the variable is undeclared
So never tries to backtrace 00:12
diakopter try printing elems of the hash if it thinks it's undeclared
(not debugger)
I bet it's hosed 00:13
well the other way is to use windows' error interception
have it segfault but make windows bring up the dialog to debug in VS
I looked for how to enable that in win8 the other day to no avail 00:14
getting win8.1 soon..
jnthn msdn.microsoft.com/en-us/library/wi...s.85).aspx 00:17
diakopter THAT
how u find so quickly
I cede googling skills crown to you 00:18
jnthn I have a bad feeling that the adjustments I do to spit out the stuff when it hits the undecl variable will move enough stuff around that it'll hide the bug again... 00:36
diakopter hm 00:42
heh.
jnthn bugger, it did as well... :/ 00:45
diakopter did you try the automatic debugging? 00:46
jnthn It doesn't seem to actually segfault
Even doing attach to process doesn't show one.
diakopter hunh.
jnthn yeah, it's odd
diakopter hmmm maybe "panic" is one of those terrible error messages I threw in there 00:47
diakopter ducks
yeah, b/c it doesn't show "at 'panic'" or whatever
which revision are you at 00:50
I'll try to reproduce
jnthn Grab latest MoarVM and latest moarboot 00:52
Then apply:
gist.github.com/jnthn/6928022
Think I give up for tonight :)
diakopter oh :) 00:53
sleep swimmingly!
jnthn Thanks... 00:57
Will have plenty of tuits tomorrow :)
'night o/
TimToady o/
JimmyZ .tell jnthn I got a different error: Routine declaration requires a signature at line 1047, near "(MAST::Ins" 01:59
yoleaux JimmyZ: I'll pass your message to jnthn.
02:44 nwc10 joined, moritz joined, BinGOs joined
diakopter TimToady: I find it interesting that nqp-parrot and nqp-jvm can't run the man-or-boy benchmark/test... ;) 03:05
(but nqp-moar can)
can't is perhaps overstated; won't is more precise 03:06
uhm. 03:09
I meant to say don't
JimmyZ .tell jnthn I got a backstrace : gist.github.com/zhuomingliang/6929185 03:30
yoleaux JimmyZ: I'll pass your message to jnthn.
03:34 moritz joined, BinGOs joined, wsri joined 03:39 diakopter joined
diakopter stares at the screen awaiting ideas 04:32
06:40 ssutch joined 07:06 FROGGS joined 07:12 odc joined 07:52 foo_bar_baz joined
dalek arVM: 2db742c | jimmy++ | src/core/ (2 files):
Remove needless MVMROOT
10:00
jnthn JimmyZ: You committed debugging code, and I'd not remove that clone one 10:03
JimmyZ: I can completley imagine copy_to allocating...
The other one in exceptions.c is unrequired, though.
FROGGS jnthn: here is what I have for the flattening issue of list_*: gist.github.com/FROGGS/1240be3b37b8678bd6fd 10:20
for me it seems like as if typed arrays don't get properly composed 10:21
jnthn FROGGS: ok, gimme a bit, I'm just working on a GC bug fix...
FROGGS that is, repr_data->slot_type is never MVM_ARRAY_I64 for example
jnthn: sure, no hurry :o)
lunchtime soon anyway 10:22
jnthn I may have nailed at least one case of the undecl heisenbug 10:24
FROGGS \\o/ 10:26
may++
jnthn It was a case that looks like it could cause return value corruption
FROGGS ahh, the return value of $*W-is_symbol you mentioned? 10:27
s/'-'/./
jnthn Could easily have been, yes 10:28
Well, it seems to vanish the incident I ran into 10:29
*incidence 10:30
FROGGS yeah, but maybe it just hides under the carpet
like before
jnthn Maybe *but* (a) this was a genuine bug either way, and (b) the fix doesn't change timing of GC 10:31
and (c) it's highly likely the fix doesn't even malloc
uh, even cause a malloc where there'd not have been one
Meaning it doesn't change memory usage patterns while fixing the bug
FROGGS and (d) fixes are always good :o)
jnthn That too 10:36
dalek arVM: 6c409d9 | jnthn++ | src/6model/reprs/Lexotic.c:
Missing MVMROOT in Lexotic.

Argument processing can cause boxing. If this caused a GC run (which it did during debugging the "Undeclared variable..." heisenbug) then we'd end up looking inside the wrong Lexotic, which most likely led to corruption of the return value.
jnthn aww...git revert doesn't take a -p 10:39
dalek arVM: a1101cd | jnthn++ | src/core/ (2 files):
Partial revert of "Remove needless MVMROOT"

This partly reverts commit 2db742cf50d3736320263847c15b2b683f23f45b. It added debugging code. Also, it's reasonable for copy_to to allocate and having just spent 4 hours finding a missing MVMROOT, I would very much rather have too many than too few.
10:41
jnthn (Workaround to no git revert -p: git revert --no-commit, then git reset -p, the git commit 10:42
)
That MVMROOT comment in the commit general policy, BTW. It's cheap to have an MVMROOT that we don't need. It's very costly to hunt missing ones. 10:43
*is general policy
FROGGS: OK, your patch now :) 11:08
FROGGS: Since t/qast is one of our last failures :) 11:09
11:10 cognominal joined 11:12 camelia joined
jnthn FROGGS: I think you're confusing yourself. gist.github.com/FROGGS/1240be3b37b...r-diff-L15 should be get_elem_storage_spec, no? :) 11:17
11:21 camelia joined
JimmyZ jnthn: ping 11:24
jnthn FROGGS: Think I've got your patch in working order :) 11:29
JimmyZ: pong
FROGGS jnthn: awesome! 11:31
jnthn FROGGS: It was pretty close
JimmyZ jnthn: re the clone MVMROOT: I follow the create OP one, move 'GET_REG(cur_op, 0).o = cloned;' before allocate
FROGGS jnthn: btw, this is/was just a debugging line, but yes, it is off 11:32
JimmyZ jnthn: So I think it's safe :-)
jnthn FROGGS: Yes, I figured it was debugging. But when the debugging line contains a bug ;-)
FROGGS *g*
jnthn JimmyZ: oh, so you did... 11:33
jnthn missed that re-order
JimmyZ ;)
jnthn JimmyZ: Might I gently suggest writing something like "Re-order to avoid needing MVMROOT" in the commit message, rather than just "remove" :)
11:34 cognominal joined
jnthn But yeah, it's safe with the re-order 11:34
JimmyZ jnthn: I was consider copy the create OP comment to the clone OP
jnthn JimmyZ: That may also be wise
FROGGS: yay, t/qast now passes 11:35
JimmyZ I can do it again? :P
FROGGS yay!!!
push push push
jnthn JimmyZ: Sure :)
dalek arVM: 83b416c | jnthn++ | src/6model/reprs/MVMArray.c:
Implement get_elem_storage_spec in VMArray.

  FROGGS++
11:36
arVM: 6277e7f | jnthn++ | src/core/args.c:
Handle natively typed lists in arg flatten.

Based on a patch from FROGGS++.
jnthn JimmyZ: I had some coffee now so it's more likely to pass review ;-)
OK, so 82-decode.t... 11:37
JimmyZ jnthn: great
FROGGS ahh, I see the difference 11:39
dalek arVM: ed9523e | jimmy++ | src/core/interp.c:
Avoids a MVMROOT, also and a comment to explain why.
11:43
JimmyZ safe safe safe ...
FROGGS JimmyZ: "... before calling initialize"
?
JimmyZ oh copy_to 11:44
jnthn s/initialize/copy_to/
11:47 camelia joined
dalek arVM: b1d75d1 | jimmy++ | src/core/interp.c:
revise the comment
11:48
FROGGS jnthn: all but encode here fine too :o) 11:49
jnthn yeah, I just started working on it, but starting to feel hungry... 11:50
Why are MVM_stat_platform_blocks and friends defined in src/string/ops.h? 11:52
What does stat have to do with strings?
FROGGS stat? I'd say nothing 11:54
well, "stat" would have
I think I will look at the --target=ast issue then 11:56
jnthn +1
FROGGS: Also, maybe see why --stagestats produced corrupted output 11:58
FROGGS ahh, the double-printing? 11:59
yeah
jnthn Anyway, it's awesome we're down to one test file :) 12:02
FROGGS yes, it is :o)
I am really eager to see how long rakudo's stage parse takes 12:03
jnthn We're a bit from that yet, I think :)
FROGGS nah
my b-day is in five days you see :P
that is not that far
JimmyZ you would not mind if I added some MVM prefixes to string ops.h? 12:05
or MVM_STRING_ prefixe ...
dalek arVM: e6ff821 | jnthn++ | / (6 files):
Stub encode/decode ops.

Currently, just throw NYI exceptions.
jnthn JimmyZ: Leave those for now; it'll clutter the code a lot and it's not entirely clear that we should be exposing those... 12:06
Those used only in strings/ops.c could just be #define'd in there.
The MVM_stat things can get moved though 12:07
JimmyZ ok :-)
jnthn Were they not meant to be in src/io/ops.h ?
JimmyZ you mean MVM_stat_plaform part? yes 12:08
jnthn yeah
dalek arVM: 9c2f101 | jimmy++ | src/ (2 files):
move MVM_stat_plaform_* macro from strings/ops.h to src/io/fileops.h
12:13
jnthn lunch & 12:14
12:28 woolfy joined 12:59 Woodi joined
FROGGS btw, --target=ast explodes when concatenating "associative" with NULL 13:34
aha, nqp-jvm prints it as - QAST::VarWithFallback(associative null) 13:43
and nqp-parrot as - QAST::VarWithFallback(associative )
so, it is a bug in nqp's code 13:44
jnthn back 13:47
diakopter FROGGS: ok.. 13:50
FROGGS: well, it just means need to add a null check .. in a billion places?
:)
FROGGS nah, just one I think 13:51
diakopter well, for now
13:51 grondilu joined
FROGGS for now? 13:51
jnthn Eventually we need to arrange to not SEGV if we hit a NULL :) 13:52
diakopter I figure there are probably other places we assume printing null doesn't blow up at that level
jnthn: what are the possible argument values to encode() and decode() 13:53
FROGGS jnthn: I could imagine that we create a new string "nil" when we hit a NULL in concat, and in all other string ops 13:57
diakopter FROGGS: he means to make a pmcnull-type repr 13:58
that asplodes on evarthing
then change everywhere that writes NULLs in the C code to write that pointer instead
it's definitely easier in the short run than making the signal interceptors/handlers 14:00
though those are needed eventually too
14:03 jnap joined
dalek arVM: 3dd7916 | jnthn++ | src/ (3 files):
Integrate utf-16 encoding; small encoding cleanup.
14:05
14:06 colomon joined
jnthn encode(string, encoding_name, array_to_write_into) 14:06
decode(array, encoding_name)
FROGGS Stage mast : 1.582 14:09
Stage mbc : 0.007
moar: 3rdparty/libuv/src/unix/loop.c:150: uv__loop_delete: Assertion `!((((*(&(loop)->active_reqs))[0]) == (&(loop)->active_reqs)) == 0)' failed.
hmmm
Stage start: 0.000013Stage start : 0.000 14:13
Stage parse: 9.33755Stage parse : 9.338
Stage ast: 0.000072Stage ast : 0.000
really really strange
timotimo cool buffers running into each other 14:14
FROGGS strange strange, even
timotimo: looks at the stage parse
timotimo wow
FROGGS 9.337... vs. 9.338
timotimo one of them is rounded
the other one is full
that's amazing
FROGGS the 9.338 is correct though 14:15
timotimo oh 14:16
so it prints out all the parts first
and then the result of formatting all the parts
FROGGS nqp-m: say(nqp::sprintf("Stage %-11s: %7.3f", ["parse", "9.337533"])) 14:17
camelia nqp-moarvm: OUTPUT«Bytecode validation error at offset 22, instruction 4:␤register operand index 50 out of range 0..9␤»
FROGGS errrm, what?
needs a rebuild?
locally this works fine
so I think it only borkens when printing to stderr 14:18
install/bin/moar nqp.moarvm -e 'my $err := nqp::getstderr(); nqp::printfh($err, nqp::sprintf("Stage %-11s: %7.3f", ["parse", "9.337533"]))' 14:19
Stage parse : 9.338moar: 3rdparty/libuv/src/unix/loop.c:150: uv__loop_delete: Assertion `!((((*(&(loop)->active_reqs))[0]) == (&(loop)->active_reqs)) == 0)' failed.
14:30 ggoebel6 joined
tadzik so, t/nqp/82-decode.t is the last nqpboot failure? 14:39
JimmyZ kinda 14:40
jnthn I guess nobody ever tried touse this utf-16 encoder... :P 14:42
dalek arVM: f3e16a0 | jnthn++ | src/strings/utf16.c:
Fix obvious problem in UTF-16 encoder.

Who knows what more may lurk... :-)
14:45
arVM: 249069d | jnthn++ | src/ (3 files):
First pass at encode/decode ops.

Right enough to pass 82-decode.t, at least.
tadzik \\o/
arnsholt Does the Unicode consortium have some kind of torture chamber for implementations? 14:46
That'd make sense
jnthn Probably :)
arnsholt Kind of like TeX has TRIP 14:47
jnthn oh, I have an NQP commit locally that I didn't push too
There we go 14:48
JimmyZ jnthn++
jnthn Only issue left that isn't Moar specific is taht on Windows, \\r screws up 05-comments.t 14:49
if you get rid of those all is fine
It happens on other backends too...may just fix it while I'm fixing stuff, though, so it's clean even in that environment'
FROGGS jnthn++ 14:52
diakopter jnthn: nope, never teted the utf16 :D :D :D :D 14:58
... I'm surprised it took only that to make work... 14:59
jnthn diakopter: Well, that only tests it can encode/decode 'a' :P 15:05
diakopter heh.
TimToady you need at least A to be able to do ASCII 15:06
diakopter evalbot rebuild nqp-moarvm
evalbot rebuild nqp-moar
evalbot rebuild nqp-m 15:07
nqp-m: 1;
camelia nqp-moarvm: OUTPUT«Bytecode validation error at offset 22, instruction 4:␤register operand index 50 out of range 0..9␤»
jnthn
.oO( I was gonna learn about Unicode, but I sent for asciing vacation instead... )
*went
All tests successful. 15:13
Files=85, Tests=1918, 25 wallclock secs ( 0.39 usr + 0.11 sys = 0.50 CPU)
Result: PASS
\\o/
masak .oO( I get branded as sexists just for one little EBCDIC joke... )
sexist*
jnthn That's with an optimized build
diakopter is that fast? 15:15
jnthn It's ok :)
PerlJam masak: Just make sure you're not within ear-shot of Adria Richards ;>
benabik Correct >> fast
diakopter not_gerd: if you're around, ping me on gtalk... :D
benabik: fast is part of correct! I promise! 15:16
jnthn checks the build actually works with optimized MoarVM too
diakopter doesn't hold my breath
masak PerlJam: don't worry, I don't have a tendency to dongle in her vicinity... 15:17
jnthn I'm going to merge moarboot into master, then make sure that we didn't break the NQP on Parrot or NQP on JVM builds. And provided not, then I'll merge it
FROGGS \\o/ 15:18
jnthn diakopter: Works for me :) 15:19
I want to set up a runner thing for it too
diakopter dares you to try 32-bit
jnthn hah
diakopter runner thing?
jnthn Don't actually have a 32-bit build handy
diakopter sure you do
jnthn diakopter: Yeah, so you can just say "nqp" instead
grondilu has 32-bit linux in case it's useful 15:20
jnthn diakopter: Like on JVM
diakopter: Instead of the full path to Moar, then nqp.moarvm :)
diakopter I thought the jvm one was a shell script
jnthn Sure
Or .bat on Windows 15:21
Will do the same here.
diakopter oh; I thought we had that actually
jnthn We can look at fake-executable stuff in the future if we really want.
No, make test does prove --exec "/path/to/moar nqp.moarvm"
or so
tadzik Files=85, Tests=1918, 24 wallclock secs 15:22
hah
prove -j4 ftw :P
FROGGS jnthn: and the segfault after stagestats is due to printing to stderr, not closing it, and tehn calling uv_loop_delete
jnthn does -j4
tadzik even 20, if I reorder stuff
FROGGS I tried to close that pipe but there is still something left to clean up in libuv
jnthn Files=85, Tests=1918, 14 wallclock secs 15:23
hah
tadzik t/qregex/01-qregex.t is the slowest one, so it makes sense to put it first
jnthn ooh, lemme try that
tadzik t/qregex, then t/nqp
jnthn hm, on Windows it makes no difference 15:24
tadzik it was 20% faster here :)
(the whole run)
jnthn wow
timotimo i'm still convinced that print failure is due to it accidentally printing all pieces of the format string in order "unformatted" and then the whole thing formatted :P 15:25
tadzik (24 vs 20 secs)
jnthn diakopter: I'm gonna go for the merge, then sort out runner, etc. There's no need for the rest to happen in a branch. 15:26
oh, I may squash the stage 0 updates though... 15:27
diakopter squash away 15:28
FROGGS timotimo: now I think the nqp-cc really is to blame, because the weird output has no padding for %s, and when you look at nqp-cc's sprintf %s rule, it is outdated and can't handle it 15:29
timotimo mhk
FROGGS so, only we make bootstrap-files using the stage2 created by moar, it will vanish at all
now it is just visible when using the stage0, but not after that 15:30
diakopter why in the world does it....
asplain plz
FROGGS well, I can even update sprintf in nqp-cc, create a new stage0, and it will be good 15:31
the segfault when calling uv_loop_delete has nothing to do with that though, and therefor will remain 15:32
gtg, see you in a bit
jnthn No, just fix it in nqp repo 15:33
benabik Is Moar's nqp going to try to install itself as nqp? That could get awkward quickly, with three different versions of nqp vying to be the one true nqp.
diakopter see the #perl6 backlog... oh wait, don't. 15:34
yeah we'll have them build nqp-$vm executables/launchers
and put those in path
then alias/shortcut one of them 15:35
and have the user choose which one if there's multiple
using the system distro package manager if possible (alternatives/provides)
lee_ it might be cool if there was something like nqp --switch-vm moar, to change the default
kind of like how perlbrew or rbenv work
arnsholt That doesn't belong in NQP itself I think 15:36
diakopter lee_: there's a tool for that on the major distros
benabik I don't think they're quite 100% interchangeable... Or will nqp-moar be able to compile my parrot languages?
lee_ i guess if you trust distros to get it right, then yeah :P
diakopter benabik: not if it has Q:PIR
:P
benabik diakopter: Well, yes.
diakopter benabik: ... what parrot languages 15:37
timotimo moar already gets perl5 compatibility, why not add parrot compatibility on top!
so we can run winxed programs on moar ...
diakopter meh
(what does it offer above nqp)
benabik diakopter: I did develop on Parrot for a couple years, I have a small collection of stuff.
arnsholt If your language is implemented using NQP-rx it should be possible to re-implement it on NQP without *too* much pain I think 15:39
tadzik oh, that sounds like rakudobrew a bit :) 15:41
multiple backends installed, and a perl6 script that picks the one you want 15:42
16:14 not_gerd joined
not_gerd o/ 16:14
diakopter o/ 16:15
16:21 colomon joined
nwc10 what branches of nqp and parrot should I be building with to get moarvm to pass t/nqp/82-decode.t ? 16:22
jnthn No Parrot needed 16:23
nwc10: Hang on a bit though, I'm landing some merges etc. soon.
nwc10 OK
I shall go back to herding the 4 year old yuppie, who seems to be annexing all the sofas for house construction, and blaming her scooter for what its doing 16:24
16:45 ssutch joined
jnthn Oh, while I was taking a walk in Stockholm, I figured out how to do a nice, isolated fix for the long-standing GC gen2 root list algorithmic problem. 16:47
Just implemented it now and testing .
...and hoping for now SEGV :P
Hm, it shaved another 4s off make test 16:48
Now non-parallelized is down to 21s 16:49
diakopter sigh.
I wonder if I addressed it in the gcorch branch.. :(
jnthn And down to 10s parallelized
diakopter: I'm really happy with how self-contained my solution is
diakopter if you thought I was arguing to consider using mine instead then I'm insulted 16:50
I thought I've tried to communicate this so many times before
that when I say those sorts of things I'm simply lamenting that I didn't yet have time to finish it 16:51
jnthn diakopter: Huh, no, was just expressing my happiness that something I had first expected would be a pain to solve seems to have had a realtively easy to implement solution.
diakopter well when you push it I'll be able to see if I even worked on it 16:52
jnthn diakopter: I don't recall this being on the list youd gist'd of things you had done in gcorch fwiw
diakopter I suspect I didn't, yeah
TimToady gave up trying to figure out whether he was insulted a long time ago, and just assumes it's so, and that it doesn't matter :) 16:53
diakopter bleh 16:54
dalek arVM: ffc82e5 | jnthn++ | src/gc/ (2 files):
Greatly improve gen2 root handling.

Before, an object was only removed from the gen2 root list when it was itself GC'd in a full collection. This meant that a long-lived object that made it into the gen2 root list stayed there even if it no longer pointed to any nursery objects or frames.
Now, as we pass through the gen2 roots list, we take note of objects that no longer need to be there, and slide those that do down to the start of the list. This keeps it around a constant-ish size, rather than O(heap size). d0e69a5 | jnthn++ | src/core/coerce.c: Missing MVMROOT in nqp::radix.
16:56
jnthn nwc10: So, now no Parrot needed. In MoarVM, perl Configure.pl --prefix=install or so 17:02
nwc10: Then in latest NQP, perl ConfigureMoar.pl --prefix=/path/to/MoarVM/install
That is, just make the prefixes match :)
diakopter jnthn: yeah but nwc10 doesn't have 2GB ram
on the Pi, that is 17:03
jnthn Yeah, I suspect what I just committed will only help so much 17:04
17:05 FROGGS joined
nwc10 the Pi ended up being extremely upset 17:27
kernel paniced overnight
and oopsed into the kernel debugger on reboot
it's back now
diakopter how much memory does it have
nwc10 256Mb RAM, but the GPU has to have at least 32Mb, IIRC
it's an old model B
and apparently I need to make "brm brm brm" noises right now 17:30
diakopter o_O 17:32
nwc10 jnthn: All tests successful. (not on the Pi) 18:10
jnthn :) (:() 18:14
benabik Does moarboot being merged into nqp mean nqp-cc will die soon? 18:16
TimToady one can hope :) 18:19
jnthn benabik: yeah 18:20
benabik: But as soon as it goes away we have to start respecting bytecode back-compat 18:21
I think there's a few things to sort out (like extops bytecode changes) before we do that
But I suspect its remaining life is O(weeks) 18:22
benabik Guess I need to set up another nqp clone then. :-D
compatibility? Oh noes!
masak jnthn: '(:()' looks like a monkey with a banana on its head. 18:35
jnthn It...it does? :P 18:36
diakopter looks more like a person with two bananas on their head 18:42
benabik Hm... '2' is not a valid number at line 685, near ",\\n 2,\\n " panic 18:49
Compiling stage2/MASTOps.moarvm 18:51
diakopter well, why'd you make 2 an invalid number? :P
jnthn heh 18:53
benabik Seems odd because that's in the middle of a huge list of numbers. Going to guess that's actually a memory issue or something. 18:54
diakopter gamma rays, probably 18:55
benabik Well, it's happened twice now, with different numbers in Ops.nqp 18:56
jnthn benabik: If we're really lucky, ^ might get it. 18:58
benabik jnthn++ 18:59
diakopter t\\qregex/01-qregex.t takes fully half of the cpu time
jnthn diakopter: ? 19:00
"fully half"?
Sounds like it's a good profiling target, either way... ;)
diakopter fully there means "definitely, I'm not eaggerating" 19:01
exaggerating
jnthn diakopter: half the CPU time during make test?
diakopter yeah
jnthn Well, it does do 750 evals...
It's by far the most hard-working of the tests. 19:02
diakopter goes to profile it
jnthn I'll profile it if you don't beat...oh, cool :)
Added a runner, btw
diakopter you're a runner
jnthn Nah, I'm too lazy for that :P 19:03
FROGGS jnthn: I tried to come around the segfault when printing to stderr/stdout... 20:06
jnthn: this seems to be a possible fix: github.com/joyent/node/commit/4915...628c9ecf23
jnthn: but sadly it segfaults then when trying to leaning up the stream handle
20:21 foo_bar_baz joined
not_gerd good night o/ 21:08
diakopter o/
21:09 not_gerd left 23:05 BenGoldberg joined
BenGoldberg p6: say <JAPH> 23:05
camelia rakudo 50cecf, niecza v24-98-g473bd20: OUTPUT«JAPH␤»
BenGoldberg nqp-m: say(NQPMatch) 23:06
camelia nqp-moarvm: OUTPUT«Bytecode validation error at offset 22, instruction 4:␤register operand index 50 out of range 0..9␤»
BenGoldberg A "Bytecode validation error" is much better than a segfault (which is what that code did a day or so ago), but it's still obviously not quite right... 23:08
diakopter :) 23:11
[Coke] where are the guts for MVM_OP_tc ? oplist is signature, ops.c is a struct of that signature, it seems... 23:13
(tc is particularly hard to search for, as it's also the abbr for threadcontext) 23:14
diakopter [Coke]: look for OP(tc) in interp.c
src/core/interp.c
[Coke] danke. 23:19
diakopter yw 23:20
23:25 cognominal joined