00:30 Zoffix joined 01:49 ilbot3 joined 03:11 coverable6 joined 05:11 mst_ joined 05:19 eviltwin_b joined 05:28 brrt joined 06:38 brrt joined 07:01 domidumont joined 07:08 domidumont joined
brrt fingers crossed 07:25
(i've just compiled my great spesh annotation handling refactor and am running nqp build)
07:45 brrt joined
brrt rakudo build is fine so far 07:57
07:58 AlexDaniel joined
brrt rakudo make test is fine 07:58
lizmat whee! :-) 08:00
jnthn morning o/ 08:34
nwc10 correct! 08:36
Geth MoarVM/even-moar-jit: 31c4c54eca | (Bart Wiegmans)++ | 6 files
Handle spesh annotations in the expr JIT

Previously we tried to let the legaacy JIT handle these, but that doesn't work very well, as we might handle the same annotations twice, and we didn't handle the after-instruction annotations at all. Also, it lead to the 'breakup' of the expression tree.
With this patch the expr jit handles virtually all annotations, with the exception of DEOPT_INLINE and DEOPT_ONE, because these are attached to guards anyway, and we don't handle those yet.		 08:47
brrt the cute bit
i overwrite a DYNAMIC_LABEL control handle (which should be called POSITION_MARKER, but whatever) with a THROWISH_PRE, which has virtually the same effect 08:48
this saves me from having to nest two guards 08:49
jnthn :) 08:54
Geth MoarVM/spesh-worker: 69cc08a25f | (Jonathan Worthington)++ | src/spesh/arg_guard.c
Insert rw container check nodes.
 09:24
MoarVM/spesh-worker: af8a998968 | (Jonathan Worthington)++ | src/spesh/dump.c
Update dump output of deref nodes.
09:26 zakharyas joined 09:34 zakharyas joined
brrt ugh, clang doesn't understand ; as a comment marker in assembly 09:45
Geth MoarVM/spesh-worker: ef6f631db8 | (Jonathan Worthington)++ | src/spesh/arg_guard.c
Add decont type tests into arg guard tree.

With this, all the cases the current specializer spits out are - at least in theory - built into the tree.		 10:02
jnthn Example dump output: gist.github.com/jnthn/0e9542c94bbb...f3cd53e35b 10:03
Notice how unlike today it lifts the callsite match and reading out of the args buffer 10:04
nwc10 "next week in MoarVM" 10:05
jnthn So we only need to do those comparisons once, not once for each candidate
nwc10 because "this week in $foo" is so last week.
and no, I did not "notice" because I'm totally unfamiliar with how it used to look :-/
10:11 ggoebel joined
jnthn Other thing is that we have a current active "test register", which if we JIT these guards could just be a CPU register 10:11
And since there's only one of them, no allocation fun 10:12
timotimo in the previous implementation we had an array of all candidates and each candidate has its own array of tests. if two candidates share tests, they'll be re-run until a full match is found
nine (architectural improvements)++ 10:13
jnthn Next step is to implement the thingy that will interpret this
Well, also going to do a test run to make sure I don't hit any panics by surprise
Then I'll run it *and* the current guard checking implementation 10:14
And see that they always come out with the same result
nwc10 and only then will you stop for lunch? :-) 10:15
jnthn oh dear, an exploding test file 10:16
Which runs OK on its own out of the harness. Aww. 10:17
nwc10 pipe it to cat?
jnthn No difference, alas 10:18
But seems the spectest run will show up some more cases 10:19
It's an explosion in GC
Darn, every one I try is fine outside of the harness 10:21
timotimo do you at least get it if you run a single file with prove or some other tap parser? 10:22
jnthn Grr, can't even get the one in make test to fail again 10:25
timotimo time for a stresstest?
gc torture i mean
jnthn Hm, get a valgrind whine that seems unrelated 10:26
Geth MoarVM/spesh-worker: 50005f3142 | (Jonathan Worthington)++ | src/spesh/log.c
Use correct union branch to log static values.
 10:27
jnthn does a spectest again 10:28
I'm sure that one can't be it
hah, no
t/spec/S17-procasync/no-runaway-file-limit.t seems a reliable-ish exploder 10:29
Ah yes, invalid reads 10:30
timotimo i got a segv on every start because i forgot to recompile rakudo's extops to use the new headers %)
jnthn oh, duh... 10:31
Nothing to do with guard stuff at all, I think
timotimo aha double free or corruption 10:37
ugh, in precomp tests 10:38
those aren't small to be good debugging targets
Geth MoarVM/spesh-worker: 2502b0cdcb | (Jonathan Worthington)++ | src/spesh/log.c
Correct missing check in parameter logging.

Parameter logging may log two entries. Must freshly get the logging buffer each time, in case it became full and was sent.		 10:39
timotimo spectest looks kinda happy 10:51
not completely
jnthn Yeah, I still think somethings kinda up but it's not easy to repro
timotimo huh, the more i scroll the less happy it looks %) 10:52
i started out on a screen that had only "ok" on it and more "ok" scrolling past
jnthn Some of my failures are down to not having a latest Rakudo 10:54
timotimo oh wow, i'm further behind than i thought, too
nine jnthn: re 2502b0cdcb the if (IS_CONCRETE(param)) block now runs even if tc->spesh_log is NULL. That's different than before. 10:55
jnthn nine: True, but it's also harmless 10:56
Very occasionally, it'll cause a bit of throwaway work. 10:58
11:02 brrt joined
Geth MoarVM/spesh-worker: 6aac97bf40 | (Jonathan Worthington)++ | 2 files
Initial implementation of arg guard interpreter.
 11:06
MoarVM/spesh-worker: 80a4d43309 | (Jonathan Worthington)++ | src/core/frame.c
Run new arg guards; compare the output.

This shows up discrepancies in what is found today and what the new mechanism discovers. There are some, which will next need to be investigated.
jnthn And that gives me my things to explore after lunch. bbl :) 11:07
11:08 zakharyas joined
timotimo also looks 11:22
oh i didn't know MVM_oops gives a stacktrace, too 11:25
hm, the spesh dumper for arg guards isn't call-from-gdb-friendly 11:29
i have been poking at one of the nativecall test files; routine-sig-sanity.t 11:45
the new guards tool finds no matching candidate, whereas the old one does. it's the first candidate and it's guarded with conc + dc_type scalar 11:46
Geth MoarVM/even-moar-jit: 7c58fc80fa | (Bart Wiegmans)++ | docs/jit/todo.org
Describe stack walker for getting current position

The code snippet actually works.		 11:47
timotimo i need to rr this so i can step back into the ag matcher 11:48
can't make install because the ag rejects one of the install scripts ... 11:50
okay installed it by bypassing the oops 11:51
something's very wrong with my installation here 11:52
arghle barghle, now the test file doesn't fail any more 12:00
okay i found something 12:06
jnthn back 12:09
Geth MoarVM/spesh-worker: c42ecb6074 | (Jonathan Worthington)++ | src/core/frame.c
Include frame name/cuuid in mismatch error.
 12:12
12:12 brrt joined
timotimo jnthn: we have an anonymous union in the arg guard node; i thought we had to have all unions be nymous? 12:15
jnthn Um...what for?
Some compiler?
jnthn checked the MSVC docs and they seemed allowed there
Ah, if you disable OSR then the NQP build completes 12:16
So the missing candidate is apparently OSR-y
timotimo okay so i'm invoking Stringy and it's going through the tree matching cs, container type, rwness, and then it doesn't find a match on the type inside the container 12:19
it's only checking for IO::Path, though
jnthn I'm looking at the NQP case(s) first, fwiw :)
timotimo let's look at the spesh candidate that gets the match outside the agn runner
jnthn Since they don't have any of the DEREF things in them :) 12:20
timotimo that's probably wise %)
jnthn I've no idea why OSR would make a difference
timotimo the num_spesh on the frame and the number of result calls in the agn tree match up at least 12:21
jnthn In the case in NQP, we're actually missing Wrong result from new arg guard for EXPR (100): got 2, wanted 0 12:23
Which is a bit nuts 12:24
Because the last guard tree it dumps out only contains result 0 and result 1 o.O 12:25
12:32 brrt joined
timotimo hm, okay, so 12:35
we have a discrepancy between rwness handling in one vs the other
this is how i think it goes: 12:36
the old one is happy when an rw container is passed for a non-rw check 12:37
the new one will not consider anything that doesn't want an rw container if the container ends up rw
we don't use rw containers inside nqp (except maybe in the test suite for lexicalrefs?) so it wouldn't asplode there 12:38
jnthn Meanwhile, it seems that the NQP issue is that we are adding two things that have the same guards 12:40
Geth MoarVM/spesh-worker: 4120f7f35b | (Jonathan Worthington)++ | src/spesh/arg_guard.c
Detect and panic over duplicate guard addition.
jnthn That check makes it panic earlier
ho, it's OSR that is adding the dupe 12:41
But that OSR'd guard would never be reachable
or, OSR'd version I mean
timotimo that'd be why it's sensitive to osr, then. does it have a different code path to changing the tree?
jnthn no, but it may have a different one for "do we already have this" 12:42
ah 12:44
/* Beaten! */
result = osr ? NULL : &static_frame->body.spesh_candidates[i];
It then interprets that NULL to mean "we should install a new candidate" 12:45
But we perhaps should not :)
timotimo aha :) 12:48
Geth MoarVM/spesh-worker: 2a99ecdf62 | (Jonathan Worthington)++ | src/spesh/candidate.c
Don't install "hidden" OSRs in new arg guards.

These are technically dupes today. This issue will be revisited when OSR gets a larger overhauling during the move to doing it on the spesh worker thread.		 12:49
jnthn With that we get through the NQP build and tests fine 12:51
Building Rakudo now
Reached CORE.setting
And works but make test failures, probably the thing timotimo found 12:55
12:55 brrt joined
timotimo we could make the last no-branch of the yes-rw-branch point at the no-rw-branch and that should make things equivalent to the old guard system again 12:56
it'd give everything that wants rw priority if there is rw, but if there's nothing that needs the rw we'll go through the ro candidates 12:58
perhaps we'll want to note "this needs another specialization" anyway, though?
jnthn Hmm, interesting 12:59
timotimo not exactly sure how the different levels above spesh will do all of this with regards to read-writability, i.e. if there would be different staticframes anyway for some reason
jnthn Yeah, today "not rw" counts as "don't care" 13:01
timotimo right. in the new one it counts as "oh no!"
jnthn Indeed. 13:02
timotimo it will blow up the "do both agree?" but not cause actual trouble
jnthn It's a bit curious in that
my $a = [1,2,3]; sub x() { $a }; 13:03
Then
timotimo fwiw, the "point end-of-yes-branch to no-branch" thing is potentially incompatible with multiple args
jnthn sub y($v) { }; y($a) for ^100; y(x()) for ^100
Will produce one specialization today 13:04
While
sub y($v) { }; y(x()) for ^100; y($a) for ^100
Will produce two
timotimo yup
jnthn Which feels...a bit off 13:06
This brings up another spesh weakness at the moment though
Which is that it doesn't actually matter if the rw-ness is used for now
timotimo right
jnthn uh
*used or not
Which is something we'll fix
timotimo we have a system for telling "this guard was used" but only for guard instructions inside spesh itself
jnthn I wonder if there's a possible bug here
timotimo i mean in the target bytecode itself
it's really rather warm here today :| 13:08
jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { say 1 }; multi m($v) { say 2 }; sub y(\v) { m(v) }; y(x()) for ^50; y($a) for ^50 13:09
camelia 2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
1
1
1
1
1
1
1
1
1
1
1
1
1
1ā€¦
jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { print 1 }; multi m($v) { print 2 }; sub y(\v) { m(v) }; y(x()) for ^50; y($a) for ^50 13:10
camelia 2222222222222222222222222222222222222222222222222211111111111111111111111111111111111111111111111111
jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { print 1 }; multi m($v) { print 2 }; sub y(\v) { m(v) }; y(x()) for ^50; say('') y($a) for ^50
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> y(\v) { m(v) }; y(x()) for ^50; say('')ā y($a) for ^50
expecting any of:
infix
infix stopper
statement end
ā€¦
jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { print 1 }; multi m($v) { print 2 }; sub y(\v) { m(v) }; y(x()) for ^50; say(''); y($a) for ^50
camelia 22222222222222222222222222222222222222222222222222
11111111111111111111111111111111111111111111111111
jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { print 1 }; multi m($v) { print 2 }; sub y(\v) { m(v) }; y($a) for ^50; say(''); y(x()) for ^50
camelia 11111111111111111111111111111111111111111111111111
22222222222222222222222222222222222222222222222222
jnthn Hm, seems OK
Maybe in the interim we could treat the no rw case as really meaning "not rw" 13:12
So then we'd produce the same specializations either way
(whichever order you do the calls in, I mean) 13:13
timotimo ah, right 13:16
definitely could
jnthn Seems like it'll help 13:17
timotimo so we'll also use the free-at-safepoint mechanism with the jitted machine code that comes from the agn tree, right?
jnthn Yeah
timotimo i *think* that forces us to trampoline off of the code that calls into the decision tree
otherwise a return address might still point at decision tree code that has been tossed already 13:18
jnthn I think we want to get the offset thingy in place before working on the machine code gen from it though
(for rw and deref)
timotimo not sure what the offset thingy is 13:19
jnthn So we don't have to call container_spec vtable functions
But instead can just read directly from the object
timotimo oooh
devirtualizing the repr ops, yeah?
jnthn yeah
Well, they ain't repr ops per se 13:20
Well, I guess they sorta are but :)
timotimo right, it lives in a different struct
it's functionally similar. if we know the stable we know the container spec
jnthn OK, make test is happy with the changes I proposed
timotimo nice!
jnthn Let's see how spectest goes 13:21
timotimo i think the amount of re-use from the regular jit and the agn jit will be so small that i might as well start from scratch
only copying some dynasm setup and teardown stuff
hm. actually. the nodes needed for the agn graph could live alongside nodes for the regular jit, and then we could use the same MVM_jit_compile_graph function 13:23
jnthn urgh, more fail
But not terribly more
I shoulda probably pulled a more recent Rakudo though
jnthn does that 13:24
JIT entry label out of range for code!
..that was not the error I was expecting!
timotimo wtf :) 13:25
brrt don't do that then
jnthn oh, I did make install in NQP while running it. maybe... :)
timotimo oh whoops 13:26
not sure if that can cause a jit error?
jnthn It'd be odd but :)
Let's see
hah, segv this time 13:27
brrt well, i like the jit label out of range one perhaps better
13:28 AlexDaniel joined
brrt but i'm happy as long as it is replicable 13:28
jnthn Seeing if valgrind has anything to say
Darn, looks like it's going to pass under valgrind 13:29
brrt uh-oh
jnthn That always make finding stuff more annoying
brrt what about ASAN 13:31
and, what about jit sensitivity
jnthn hmm 13:32
*** Error in `/home/jnthn/dev/MoarVM/install/bin/moar': corrupted size vs. prev_size: 0x00007fffc0018e40 ***
JIT entry label out of range for code!
(label 0x7ffff40096e8, func_ptr 0x7ffff4008000, code size 3716i, offset 5864, frame_nr 3273, seq nr 555)
and...uh...a wedged gdb...wat
timotimo wedged? 13:33
wedgdb 13:34
jnthn It woudln't response to anything after process exit
hm, this itme it said Spesh: get_osr_deopt_finalize_index failed
OK, this whiffs of memory corruption
Cannot find user-level thread for LWP 21440: generic error
And it hung up gdb again :P 13:35
13:35 AlexDaniel joined
jnthn ah no, this time it recovered 13:35
heh, hung again
What on earth.
jnthn tries --asan to Configure.pl 13:36
13:36 AlexDaniel joined
jnthn wowser 13:37
==22674==ERROR: AddressSanitizer: heap-use-after-free on address 0x619000cf3200 at pc 0x7f6891c53484 bp 0x7f6886ba4dc0 sp 0x7f6886ba4db0
READ of size 8 at 0x619000cf3200 thread T5
==22674==AddressSanitizer: while reporting a bug found another one. Ignoring.
ASAN:SIGSEGV
==22674==AddressSanitizer: while reporting a bug found another one. Ignoring.
ASAN:SIGSEGV 13:38
brrt andā€¦ is that JIT sensitive, or not? 13:39
jnthn brrt: Didn't check yet, but I suspect not
(My feeling is it's not significant) 13:40
(It's just a consequence of corruption)
huh, got some stack traces out of ASAN, but it's use after free in optimize_decont of all places o.O 13:47
timotimo o_O 13:48
are threads involved at all?
man, i gotta take another shower 13:50
jnthn Yes
brrt :-o
jnthn It's as if two threads both end up trying to specialize the same candidate o.O
brrt but. that. should not happen?
timotimo using the same spesh memory region?! 13:51
jnthn Yes, since that's allocated pre-logging
And this is post-logging
brrt: No, and I can't figure out how anything I've changed would make it happen
nwc10 check this by building MoarVM master and NQP master with ASAN and running the same thing from them? 13:52
or just take a break?
timotimo aha, yeah, they share that 13:57
that makes sense
jnthn OK, going back to c42ecb6074348 but with the throw on wrong guard result disabled works fine 14:01
huh, looks like it's 2a99ecdf621 14:03
ohhh!
bah
Geth MoarVM/spesh-worker: 6f6d2c0278 | (Jonathan Worthington)++ | src/core/frame.c
Tighten up rw/non-rw specializations.

Most immediately, to match up the semantics of the new guard tree. However, the existing behavior would cause different specializations to be produced depending on call order (rw then non-rw would make 2, non-rw then rw would make 1).		 14:06
MoarVM/spesh-worker: d4d59b4ce8 | (Jonathan Worthington)++ | src/spesh/candidate.c
Unconditionally increment candidate count.
jnthn Second one was to thank :P
jnthn spectests again 14:10
Much better, though not totally happy 14:13
But in the same way as before the guards check was added
Seems that the new guard mechanism is giving the right results now, anyways 14:28
timotimo cool 14:30
14:36 AlexDaniel joined
jnthn So the next step is to switch to using the new guards entirely :) 14:37
jnthn spectests switching over in invoke of frame.c 14:39
Geth MoarVM/spesh-worker: c3bc6012fb | (Jonathan Worthington)++ | src/spesh/arg_guard.c
Don't walk NULL guard tree.
 14:42
MoarVM/spesh-worker: d4bd25d9b4 | (Jonathan Worthington)++ | src/core/frame.c
Switch to using new arg guard tree on invoke.
 14:43
jnthn Righty, that's it done on invoke. Next to sort out the use of it in optimize.c to find an existing spesh candidate for fast invoke or inlining 14:51
15:01 Geth joined, colomon_ joined 15:06 brrt joined 15:11 colomon joined
Geth MoarVM/spesh-worker: c4582644f7 | (Jonathan Worthington)++ | 3 files
First pass at using new guards in optimizer.

This is used to resolve speshed callees so we can emit faster calls or perform inlinings. Again, implement with comparison to result we got from analyzing previous guards to help identify shortcomings.		 15:19
jnthn Close, but a couple of discrepancies from spectests 15:22
oh, it's probably the rw thing again 15:25
timotimo that does sound likely 15:27
jnthn Fixed the case I was looking at, at least
timotimo i wonder if there's something tough & tricky about the "make the agn interpreter read memory offsets directly"
or if i can just go ahead and try my luck
jnthn heh, if you make install moar while gdb is open and then try to set a breakpoint you get a bus error :)
Well, we probably need to figure out how ot make the container API cooperative in telling us them 15:28
timotimo right. until now that was the job of the spesh function
jnthn Yeah, that was all of the discrepancies 15:29
So, will cut over to using the new function instead
There's still some heisenbug to hunt down 15:31
Though not on such a warm day
Nor at this time of it :)
brrt jnthn, the agn tree is a branch tree 15:39
Geth MoarVM/spesh-worker: 9b2d7b7674 | (Jonathan Worthington)++ | src/spesh/optimize.c
Switch over to using new guards in optimize.
brrt ā€¦ okay, i have an idea of how to compile this
jnthn brrt: Just a binary tree really
That is organized aiming to minimize the number of loads/checks 15:40
brrt that's pretty cute
if we find a NULL node, we break out, right?
timotimo yeah 15:41
jnthn Well, 0, but yes
0 means "no result"
timotimo right, the "pointers" are indexes into the flattened tree array
that's why they are 16bit big only
jnthn Yeah, integers are compacter than pointers
brrt i'm familiar with the trick :-)
it is an awesome trick and i'm so happy to see it reappear 15:42
'trick'
anyway.
okay
i see how that works out
i think...
doesn't have to be a tree, though, does it
timotimo if we went with the idea i had about rw tree shape, no. but i don't think it's necessary 15:44
brrt and you use this one 'facts' value to hold the current facts
timotimo no, you're looking at the wrong instance of the interpreter
this one is the abstract interpreter
brrt i am?
which one is the right one
timotimo the right one looks at an array named args
it's in MVM_frame_invoke 15:45
brrt aha, okay 15:46
timotimo it's interesting to note that we're only working with a single register that everything is checked against 15:51
Geth MoarVM/spesh-worker: 3c982ba8ae | (Jonathan Worthington)++ | src/spesh/candidate.c
Tease apart guard addtion from temp type tuple.
 15:57
16:10 domidumont joined
Geth MoarVM/spesh-worker: 576fe32d97 | (Jonathan Worthington)++ | 3 files
Use new guards to check if specialization exists.

For now, doing the original computation also to ensure we're getting a match.		 16:23
jnthn Hm, spectest is happy with that right away 16:25
16:25 domidumont joined
timotimo suspicious! ;) 16:26
jnthn ah, the d'oh is that we actually needed to know which matched 16:28
Geth MoarVM/spesh-worker: 59b8d945b5 | (Jonathan Worthington)++ | 3 files
Existing candidate check needs which matched.

Rather than just "exists or not".		 16:32
MoarVM/spesh-worker: 99a3c6014f | (Jonathan Worthington)++ | src/spesh/candidate.c
Use new guards for existing candidate lookup.
 16:41
MoarVM/spesh-worker: 4366baa192 | (Jonathan Worthington)++ | 3 files
Remove old-style guards from spesh candidate.

We no longer need to keep them around after initial specialization production.		 16:45
jnthn There we go, nearly cleaned up :)
Last step I think is for args.c to make a type tuple directly, which I guess is a good code cleanup to do 16:46
But once we switch to the worker thread that's all rather inverted
The type tuple comes before the specialization there
Actually maybe that's the more forward-thinking way: make the type tuple from the args buffer and feed it into args spesh 16:47
Then less to refactor later
Either way, enough for today :)
& 16:50
timotimo have a good one!
TimToady
.oO( what a bunch of slackers... :)
 16:57
mst TimToady: we're *IRCers*, c'mon 17:05
timotimo oh, the op_deref_rw offset needs to be different from the deref_value offset 17:08
17:21 stmuk_ joined
stmuk_ timotimo: github.com/MoarVM/MoarVM/issues/61...-313462214 17:21
timotimo huh, can you give us a diff of the moarvm makefile generated in each case? 17:29
stmuk_ yes shortly 17:35
gist.github.com/stmuk/94143d97f0bb...e0323e350e 17:43
I'll experiment with the CONFIG line 17:44
grrr why does "make clean" not remove the Makefile 17:45
timotimo we do have make realclean
which also throws out 3rdparty build results 17:46
iirc
stmuk_ ah
timotimo i don't think it's normal for make clean to remove the makefile 17:48
"make distclean" perhaps
stmuk_ oh yeah 17:53
it's the --optimize flag to moar configure 18:02
timotimo actually, the rakudo scalar seems to have two dereferences in its can_store function 18:08
i'd have to go to the descriptor pointer and behind that is the rw flag 18:09
18:40 AlexDaniel joined
timotimo huh 18:42
debug fprintf isn't agreeing with callgrind output
the fprintf i have in the "we don't have an offset so we have to do a call" branch doesn't get called, but it does count instructions and calls from that 18:44
even worse: i see Ir for the call to fetch, but none for the fprintf in front of that 18:45
5,167,657,570 Ir if the offset thing is there, 5,135,101,054 if it's missing 19:32
so that's kind of bad?
or just noisy 19:33
jnthn Sounds odd, yes 19:35
timotimo another run without is 5,135,005,870 - 5,135,107,574 another
jnthn Would have to take a look at the patch to see why
but gotta be away for a bit now
timotimo maybe i did it wrong and caused it to never match any guards and then keep re-speshing something over and over? 19:36
stmuk_ is there anyway of passing NOISY apart from editing the Makefile? 19:38
timotimo i think you can make foo NOISY=1
stmuk_ ah 19:39
timotimo yeah, it's giving wrong results 19:40
stmuk_ although I'm trying to debug --make-install 19:41
timotimo ah, of course. i calculated the offset from the beginning of the object's data, but i applied it to the beginning of the object's header 19:43
stmuk_ wonders if qemu arm would be faster than a real PI 19:46
timotimo oh, also it'd have to know about REAL_DATA 19:47
19:54 TimToady joined
timotimo now i have valgrind processes that won't die 20:02
everytime i ctrl-c i get a new block of "process terminating with default action of signal 2 (SIGINT) 20:03
same with ctrl-\, but then it's 3 (SIGQUIT) of course
okay, htop wouldn't do it, but kill will
curiously this test file quits with an exception if run under callgrind? 20:05
i can't measure stuff like this 20:06
ok 9 - making an "is rw" parameter optional dies with adequate error message and mentions the parameter name 20:07
Must specify something as a path: did you mean '.' for the current directory?
in block <unit> at t/05-messages/01-errors.t line 67
seems a bit fishy
comes from initializing a dynamic var, most likely $*EXECUTABLE 20:10
ah, heh.
that probably has valgrind somewhere in it 20:11
i think we want nqp::execname() || stuff instead of nqp::execname() // stuff 20:14
that's better 20:16
73,002,727,218 with offset optimization, 59,651,101,659 without it ... :( 20:41
though maybe if i force Rakudo_Scalar to also use MVM_p6opaque_real_data, maybe that'll catch up? :\ 20:44
what the ... a screenful of ^@ in my spesh log 21:01
null bytes, thousands of 'em 21:02
oh, perhaps because i had this set as an env var and subprocesses took it, too 21:16
and then they wrote over each other or something?
22:47 Ven joined 23:39 AlexDaniel joined
Geth MoarVM: f621f21191 | (Samantha McVey)++ | src/strings/nfg.c
Throw an exception instead of panic'ing in MVM_nfg_get_synthetic_info

In addition improve the error messages to be less confusing and more clear about what has occured when the errors occur.		 23:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!