piojo Is there a way to access the variable/type name (or text) currently being parsed? I know about st->debug_name, but I think the code is running too early and debug_name is null 08:25
yoleaux 30 Dec 2017 12:04Z <jnthn> piojo: Such types should be interned even across compilation units. This process is largely implemented in src/6model/parametric.c. The interning should also be happening at deserialization time; see github.com/MoarVM/MoarVM/blob/mast...on.c#L3003 for a place to start digging further
piojo thanks jnthn!
maybe I should ask a different question--does GDB work well for understanding what MoarVM is doing as a small perl6 modules are loaded?
samcv good * 10:50
nwc10 good *, samcv
jnthn morning o/ 10:52
samcv morning 10:55
piojo Good morning (or evening), folks 10:59
jnthn, thanks for the tip about duplicate interning. I'm having trouble with "printf" debugging since the debug_names aren't set yet in the parametric.c functions 11:00
Do people mostly use GDB on this project? 11:01
jnthn Yes, though often it's useful to have some debug output in higher level code too
(If debugging stuff that's mostly implemented at that level and sometimes pokes down into VM-level things, that is) 11:02
It may be worth another pass over the places we call newtype but aren't setting a debug name 11:03
Geth MoarVM: 8414888beb | (Jonathan Worthington)++ | src/spesh/osr.c
Fix OSR of thread entry frame

Fixes issue #774.		 11:06
piojo Do you have any guess whether the problem is that Array[Int] type lookup is failing, or a duplicate type isn't being merged like it should be? 11:13
The code comments implied duplicate types are temporarily allowed, if I understood correctly 11:14
jnthn I'd guess the latter
piojo thanks 11:16
jnthn (Though I'm certainly guessing :))
travis-ci MoarVM build errored. Jonathan Worthington 'Fix OSR of thread entry frame 11:23
travis-ci.org/MoarVM/MoarVM/builds/324085867 github.com/MoarVM/MoarVM/compare/4...14888beb16
piojo jnthn, have you published anything that describes moarvm's type system? 11:35
oh, I see the 2nd day of your "nqp internals" talk covers some of this. I'll read the slides now 11:36
jnthn Yeah, that'll still be pretty accurate 11:37
Nothing's changed much in that area 11:38
piojo Good to know. (I just noticed it's 4 years old) 11:39
though this bug is even older, so it's all good.
Geth MoarVM/master: 4 commits pushed by (Bart Wiegmans)++, (Jonathan Worthington)++ 11:41
lizmat wonders if this would be a good time to do a bump ?
jnthn Maybe, though note the bug fix I did is impossible to trigger from Perl 6 11:42
lizmat well, I'm still seeing random flappers when running spectests every now and then 11:46
jnthn They'll be something else, then. 11:47
lizmat flappers I cannot explain from known race conditions
jnthn Oh, should bump MoarVM though
(In NQP)
As the newly added test depends on it :)
Will do that
lizmat cool
travis-ci MoarVM build errored. Jonathan Worthington 'Merge pull request #766 from MoarVM/memory-leak-fixes 12:19
travis-ci.org/MoarVM/MoarVM/builds/324094486 github.com/MoarVM/MoarVM/compare/8...a79ee83db8
lizmat fwiw, builds and spectests Rakudo fine, so I'm bumping Rakudo 12:29
dogbert17 o/ does anyone know how to enable the gc debug log? 18:04
timotimo you have to set a #define in the gc_debug.h or what it's called file 18:09
dogbert17: ^
but that's mostly for orchestration, like, what phase is which thread going through now
dogbert17 timotimo: I have used that define many times but I have never seen anything being written out wrt to collections 19:20
GCDEBUG_LOG(tc, MVM_GC_DEBUG_COLLECT, "Thread %d run %d : processing %d items from in tray \n", worklist->items); 19:21
dogbert17 timotimo: found it in orchestrate.h 19:56
now it writes a lot of interesting stuff on the screen and then it SEGV's so either I'm using it wron or it's slightly broken 19:57
it SEGV's here github.com/MoarVM/MoarVM/blob/mast...ect.c#L315 20:00
REPR(item) is null 20:03
leont_ Hacking on moarvm 22:16
It tells me to use nqp to test it
What kind of workflow is usual here?
MasterDuke leont_: fyi, if you rebuild moarvm, you usually don't have to rebuild nqp or rakudo 22:33
unless you're adding a new op or something like that
so i just make my moarvm changes, `make install`, and then run whatever nqp and/or rakudo code i'm testing 22:34
since i have moarvm, nqp, and rakudo all Configure.pl'ed with the same --prefix
leont_ I'm working out of a separate moarvm checkout now, I guess I shouldn't do that 22:35
But yeah, I am planning to add at least one op, possibly more
MasterDuke i have my "system" rakudo, and then a seperate checked out moar/nqp/rakudo for hacking on
fwiw, i build them individually, not with --gen-* 22:36
but then yeah, you'll have to rebuild nqp, and maybe do a `make m-bootstrap-files` (i don't know exactly when that is required) 22:37
leont_ Haven't touched this branch since August, forgotten a lot of stuff :-/ 22:40
MasterDuke timotimo, jnthn: i'm seeing some calls to MVM_fixed_size_free with bytes == 0 and to_free == NULL with my string fsa branch 22:58
however, the backtraces in valgrind and gdb aren't very helpful
is this something rr would be good for? and if so, any pointers on how to do it? 22: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!