github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 3 August 2013.
diakopter hrm codepoint 48694944 00:30
dalek arVM: aaa8e98 | diakopter++ | src/ (3 files):
- safer backtracing

  - new --crash command line option to segfault instead of exit, to more easily catch in debugger...		 01:20
01:30 FROGGS_ joined
JimmyZ ..\\moarvm.exe --crash nqp.moarvm -e "say(420)" 02:03
Illegal option --y(420)
diakopter: ^^
diakopter heh 02:04
weird.. 02:06
dalek arVM: 66d010a | diakopter++ | src/main.c:
remove debug
diakopter I don't get that
JimmyZ ..\\moarvm.exe --crash nqp.moarvm temp.moarvm
Failed to tell position of filehandle:
diakopter wat 02:07
JimmyZ I'm sure it's about args
it's about temp.moarvm
hmm, ..\\moarvm.exe --dump nqp.moarvm segfault 02:11
diakopter JimmyZ: something must be very different about your setup 02:14
from mine
JimmyZ I'm trying rebuild 02:15
02:16 FROGGS joined
JimmyZ yes, it's segfault 02:21
MVMuint32 ann_offset = GET_UI32(frame->body.annotations, j*10); here
diakopter I don't see why 02:48
how
benabik "Illegal option --y(1)" 02:49
Also, no args: "MVMArray: Can't shift from an empty array", with lists of <unknown>s in the backtrace.
JimmyZ yes
I saw them 02:50
benabik `../moarvm --crash nqp.moarvm temp.moarvm` does nothing, interestingly enough. 02:51
No segfaults though. :-D
JimmyZ ..\\moarvm.exe --dump nqp.moarvm
will be segfault 02:52
benabik nope. 108k lines of output
JimmyZ MVMuint32 ann_offset = GET_UI32(frame->body.annotations, j*10); segfault here 02:53
02:58 sorear joined
JimmyZ compile time is apain.... 03:07
diakopter JimmyZ: which OS/compiler are you using again 03:13
I'll try to reproduce
JimmyZ msvc 2012
express
x64
diakopter oh 2012.. 03:14
i'll try that; jnthn & I use 2010
JimmyZ hmm, how 'sa' ea '--' ? 03:18
that's why "Illegal option --y(1)" 03:19
s/ea/eq/
diakopter: nqp::say(nqp::substr('say(42)', 0, 2) eq '--'); 03:26
diakopter what about it
JimmyZ diakopter: run as nqp nqp-moar-cc.nqp test.nqp
you will got 1 03:27
diakopter wat.
JimmyZ diakopter: nqp::say('sa', eq '--'); will be 0
benabik nqp::say("'" ~ nqp::substr('say(1)', 0, 2) ~ "'"); outputs nothing 04:17
diakopter ergh 04:18
benabik Huh. nqp::say is broken for me?
diakopter try reverting the last couple commits? 04:19
benabik Tests seem to complete though. Don't those rely on output? 04:21
diakopter :D 04:22
benabik Hm. Probably just that it's exiting before running the code for some reason.
diakopter did you try reverting the last copule commits?
benabik Yes. 04:23
diakopter hrm 04:29
benabik eh. I should sleep. 04:31
JimmyZ nqp::say(nqp::substr('say(42)', 0, 2)); 04:47
nqp::say('sa' eq '--');
nqp::say(nqp::substr('say(42)', 0, 2) eq '--');
outputs : sa, 0, 1
nqp::say("'" ~ nqp::substr('say(1)', 0, 2) ~ "'"); outputs: 'sa' 04:51
06:05 FROGGS joined 06:25 not_gerd joined
not_gerd o/ 06:25
JimmyZ \\o, not_gerd
not_gerd lots of fail in the test suite :(
JimmyZ ;)
not_gerd any reason for using fake_crash() instead of plain old abort()?
JimmyZ fake_crash? 06:26
I don't know about it
not_gerd it's what get's called by --crash 06:28
it does printf("%s", (char *)(1));
ie causes the libc to segfault
if the goal is just to cause a core dump, it's cleaner to just call abort() 06:29
JimmyZ oh, I see it 06:30
yesh, libuv use abort heavily in mutex 06:31
diakopter not_gerd: oh. 06:39
dalek arVM/abort: f9a931a | (Gerhard R)++ | src/core/exceptions.h:
Fix prototype of MVM_crash_on_error()
arVM/abort: 7388198 | (Gerhard R)++ | src/ (2 files):
Use abort() instead of custom fake_crash()
not_gerd diakopter: feel free to merge ^^ 06:40
diakopter how to merge?
JimmyZ $ git merge abort 06:41
not_gerd (assuming there's no deeper reason behind using a custom fake_crash(), of course)
diakopter why didn't you commit to master
no, I'm a newbie
please commit to master 06:43
dalek arVM: f9a931a | (Gerhard R)++ | src/core/exceptions.h:
Fix prototype of MVM_crash_on_error()
arVM: 7388198 | (Gerhard R)++ | src/ (2 files):
Use abort() instead of custom fake_crash()
arnsholt diakopter: Just "git merge $branchname" merges $branchname into your current branch 06:44
JimmyZ arnsholt: diakopter is modest
diakopter no
I'm not
I'm seriously a newbie 06:45
but I did mis-ask when I asked how to merge
I meant how to merge a pull request that didn't exist yet
I didn't realize it was a branch
arnsholt Oh, right!
Merging a non-existent PR would be hard, yeah =D
diakopter anyone know which commit made all the fail in the test suites? 06:46
06:50 crab2313 joined
FROGGS diakopter: no, but I can bisect it 06:51
dalek arVM: 03ef595 | (Gerhard R)++ | src/main.c:
s/segfault/abort/ and some whitespace fixes
JimmyZ not_gerd: how about to change #ifdef CLOCK_REALTIME to #ifndef __APPLE__ 06:59
or #ifdef __APPLE__ 07:00
not_gerd JimmyZ: it's better to test for features than architectures
there might be other POSIX systems without clock_gettime() 07:01
JimmyZ oh yes
not_gerd diakopter: the changes to nqp-cc/src/QASTCompilerMAST.nqp broke the tests
git checkout 211ab0b19f25b8c81685a97540f4b1491eb17504 -- nqp-cc/src/QASTCompilerMAST.nqp
^^ works 07:02
diakopter which changes
not_gerd see git diff 211ab0b19f25b8c81685a97540f4b1491eb17504 -- nqp-cc/src/QASTCompilerMAST.nqp 07:03
FROGGS github.com/MoarVM/MoarVM/commit/21...491eb17504
diakopter ?
not_gerd rather github.com/MoarVM/MoarVM/commit/99...7602c14c48
diakopter that's not a change to an .nqp file
not_gerd 211ab is the working commit
FROGGS ahh 07:04
diakopter okay, so calling clargs is what breaks it
diakopter tries random crap to fix it 07:08
07:16 crab2313 joined
diakopter well the first thing to do is fix the stupid annotations 07:17
not_gerd diakopter: github.com/MoarVM/MoarVM/commit/10...ccb286d47e 07:18
needs to be reverted
MVM_hll_current(tc)->slurpy_array_type apparently isn't wired up yet
(or broken)
JimmyZ MVM_hll_current(tc)->slurpy_array_type is right 07:19
diakopter ?
JimmyZ: what do you mean it's right
not_gerd JimmyZ: reverting that commit fixes my test failures
JimmyZ what failures? 07:20
diakopter all of them? 07:21
not_gerd JimmyZ: all qast tests of nqp-cc
wait...
they fail again :(
not_gerd makes clean and tests again 07:22
JimmyZ diakopter: I mean it's still tc->instance->boot_types->BOOTArray :-) 07:23
diakopter what is "it" there? 07:24
07:24 cognominal joined
not_gerd it's not ->slurpy_array_type - the tests just worked because I still had the version of QASTCompilerMAST.nqp that does not call clargs checked out :( 07:28
diakopter oh 07:29
okay, so is the problem my change to what clargs does in a later commit?
or does checking out that "broken" commit entirely still work
not_gerd xkcd.com/303/ 07:31
jnthn moarning
not_gerd o/
diakopter jnthn: hi. apparnetly I'm stpiders ther stpidnsf
<- furious at self for forgetting about abort 07:32
FROGGS hey, this is a channel where we bless $self :o) 07:33
07:33 cognominal joined
diakopter <- livid at self for lots of other things from the past few hours I won't mention 07:34
<- in a blind rage at self
TimToady diakopter: you just don't want to look as stupid as the rest of us usually are :)
diakopter :/ 07:35
TimToady s'okay, we all have our off moments
diakopter not_gerd: if only my code were compiling :P
then I'd be fencing
or at least playing ping pong
jnthn Maybe do some ping pong then come back to the code? :) 07:36
diakopter well I don't even know enough to blame you or not :P so I don't know whether to ask you to look at it.. and I don't know how to figure out the next step for figuring out the next step
jnthn coffee?? 07:37
diakopter yeah but
supposedly I have to be at work in 8 hours 07:38
jnthn: well I guess I shoudl ask you to look at it 07:40
diakopter rickrolls self
(again)
3 minutes 34 seconds of awesomeness
well the current crash is in apr file close 07:41
sigh.
TimToady well, pace yourself; you know what they say: Time is the universe's way of keeping everything from happening all at once. 07:46
08:14 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
diakopter the cross compiler doesn't know about it 08:15
JimmyZ nqp -e "nqp::clargs()" does not work either
not_gerd guessed it was like that
diakopter yes, it's a moarvm op, not an nqp op 08:16
jnthn aye, there's not an nqp::op for it 08:18
diakopter jnthn: does nmake test pass for you? 08:20
(before you git pull)
jnthn Before I pulled nmake nqptest did at least work for me...
diakopter yeah but that's not the thing :) 08:21
that's broken
jnthn (and I just built latest)
(and nqptest seems to work)
diakopter right, but that's not the thing that's broken
jnthn hm, some failures in make test...wtf
diakopter qast has a different expectation about something or other 08:22
or I broke something
jnthn oh...
diakopter 'ts why I was curious how yours did after your last commit
jnthn wait, I ran make test and make nqptest at the same time and they raced for the temp.moarvm 08:23
diakopter heh
well
jnthn yes, that's better...but the qast ones appear to fail
not_gerd jnthn: 9910a6a breaks it for me by emitting a call to :moarop('clargs')
jnthn OK 08:24
not_gerd we already tracked it down that far ;)
jnthn But...are we passing any args?
diakopter yeah but I made changes to the clargs stuff after that commit
so I still don't know whether it was working find at that commit
dalek arVM: 13dbc8c | diakopter++ | src/core/bytecodedump.c:
slightly more robust
 08:25
diakopter anyway that'll help slightly
args, tabs
jnthn ooh... 08:26
We always pass foobar foobaz over for all tests it seems
As command line args 08:27
diakopter oh yeah :)
not_gerd 9910a6a9ed8463a96aace9e0fd76597602c14c48 is already broken here 08:31
jnthn Guess that'll teach me to run make test as well as make nqptest :) 08:32
Looks like it doesn't break what the tests are testing so much as our ability to invoke them, however... 08:33
Can look later; should $dayjob 08:34
08:51 keta joined 08:52 keta left 08:58 Tene joined
diakopter jnthn: could the annotations be getting the wrong values b/c of boxing? 10:06
jnthn Sounds unlikely
diakopter well the numbers are wrong, as shown by --dump 10:07
dalek arVM: e0ac69a | (Gerhard R)++ | / (2 files):
Do not rely on APR for byte order detection
 10:09
not_gerd another tiny bit of APR gone
diakopter not_gerd++ 10:12
jnthn diakopter: You still plotting the libatomic_ops update? 10:13
diakopter eh 10:17
jnthn diakopter: As in, planning to do... 10:18
So we can finish switching over to it from the APR atomics...
diakopter well we could switch now I thought 10:19
just increasing some storage size
jnthn No, we're missing the CAS variant that returns what it saw. 10:20
diakopter well like I said you can always just read it again :P it's not like there's any more risk of losing a race.. just means you can try less often 10:21
(but yes, let's get the new lao asapractical)
JimmyZ hmm, what about apr_getopt_long 11:29
not_gerd btw, should we really remove the GPL portions of libatomic_ops? 11:35
JimmyZ I'd like to add struct { char *shotopt, char *longopt, int default, char *help }
not_gerd it's enough to just not link against (or even build) libatomic_ops_gpl
if we actually want to remove source files under the GPL, the test files should have been removed as well 11:36
JimmyZ I'd like to remove GPL part...
I think we doesn't need test actully for 3rd
not_gerd *libatomic_ops_gpl.a
JimmyZ as libuv
We only need test when we're patching it 11:38
I mean we don't need to maintain 3rd test 11:42
not_gerd: how about add struct { char *shotopt, char *longopt, int default, char *help } to replace apr_getopt_long? 11:50
*shortopt
not_gerd using which code to actually parse the arguments? 11:53
JimmyZ strcmp 11:54
not_gerd ;)
JimmyZ MVM_opt opts[] = { {"-d", "--dump",0, "Dump moarvm code"}, .... } 11:55
so just need strcmp 11:56
or ,add int has_args in struct, for if an opt has arg or not 11:57
struct { char *shotopt, char *longopt, int has_args, int default, char *help }
jnthn: ^^ 12:08
struct { char *shotopt, char *longopt, int has_args, char *default_arg, int is_default, char *help } :-) 12:10
*short
12:20 benabik joined
JimmyZ *strncmp 12:31
not_gerd bye, #moarvm 12:58
12:58 not_gerd left 13:02 yoleaux joined 14:43 FROGGS joined 14:55 jnap joined 15:55 crab2313 joined
JimmyZ Good night 15:56
diakopter o/
16:22 cognominal joined 17:17 timotimo joined 18:14 not_gerd joined
not_gerd o/ 18:14
so, we can no longer use APR for getopt 18:15
should we import another 3rdparty lib or roll our own version?
the latter could turn out to be a pita to get right if we want to support more complex arguments 18:16
right now, all we need to check is flags, which is trivial... 18:17
dalek arVM: 9acf7bc | (Gerhard R)++ | src/moarvm. (2 files):
Fix prototypes of MVM_vm_run_file() and MVM_vm_dump_file()
 18:48
arVM: 550002b | (Gerhard R)++ | src/main.c:
No longer use APR for command line arg parsing
not_gerd [x] done
FROGGS awesome! 18:51
not_gerd++
FROGGS pulls
not_gerd hope it still works ;) 18:52
FROGGS still? the segfault from yesterday ways fixed?
diakopter depends which one you mean 18:53
not_gerd should have clarified: I hope the frontend executable still works
FROGGS the one we bisected
not_gerd FROGGS: that's not yet fixed
FROGGS k 18:54
not_gerd diakopter: should I base our libatomic_ops import on HEAD? 19:08
there was a ChangeLog update today, last real commit Aug17
jnthn I'll look into fixing the other one this evening. 19:10
19:40 jnap1 joined
diakopter not_gerd: yeah I think head is fine 20:14
not_gerd I think I ripped out everything we don't want 20:16
should I create a private libatomic_ops fork or should that go to MoarVM/
diakopter just shove it in for now :)
jnthn hasn't finished deciding about the external repo integration
jnthn Oh, I thought he had :P 20:18
diakopter it wasn't communicated to me
jnthn He's only so decisive :P
But srsly, having been being pondering it, I think the best bet is that we keep such things as forks/repos under the MoarVM account on GitHub.
I'm hopeful that we'll be able to use the system versions of various dependencies in the future. 20:19
When they're avaialable, that is.
It matters to various packagers.
diakopter they can't care as much if we modify it extensively 20:20
not_gerd anyway - github.com/gerdr/libatomic_ops/commits/moarvm
diakopter ok 20:23
doesn't look too different from what I did
jnthn diakopter: True :) 20:24
not_gerd I guess configure.ac shouldn't really call LT_INIT(), but my autotools-fu is not that strong 20:26
the build workd fine as-is
*works
20:32 donaldh joined
jnthn diakopter: Don't suppose you got anywhere with the weird substr bug? 20:32
diakopter jnthn: i was braindead; should've been asleep; no 20:33
jnthn ok 20:35
dalek arVM: 55c9392 | jnthn++ | nqp-cc/ (2 files):
Fix clargs test; also make testing more flexible.
 20:43
FROGGS here, irclog.perlgeek.de/perl6/2013-08-21#i_7479412 20:44
ww
jnthn ahahahaha... github.com/jnthn/nqp-jvm-prep/comm...b292282b37 21:00
diakopter heh ok
21:01 jnap joined
FROGGS jnthn: and this patch is missing here? 21:04
jnthn yeah
applying now
dalek arVM: 6cdcccb | jnthn++ | nqp-cc/t/qast/qast_ (11 files):
Unbest make test (threads.t aside).
 21:09
jnthn Much cleaner again now. 21:11
nqptest also looking good
diakopter jnthn++ hard work
jnthn So, nobody broke too much today :)
not_gerd jnthn++
diakopter jnthn: do you have time to investigate the wrong annotation values? 21:14
jnthn diakopter: Time, perhaps. Energy...hmm :) 21:23
jnthn somehow got quite tired from $dayjob tasks today...
oh, I guess I slept badly too...
FROGGS well, $beer @couch can be awesome too 21:24
jnthn The annotations that --dump spit out look quite hosed 21:39
annotation: 4A6E3A9C34CAB208344593CF090B214BCD2634AE:0
diakopter right; they did before I added the guard too 21:40
I've never seen them look right 21:41
so it's burgeon territory
jnthn Well, the code to write them looks OK 21:43
oh, I think I know what this might be... 21:45
struct MVMBytecodeAnnotation { MVMuint32 bytecode_offset; MVMuint16 filename_string_heap_index; MVMuint32 line_number; 21:46
};
That probably doesn't work out too well; it will probably shove 16 bytes padding after the 16-bit field so the 32-bit one is aligned.
Also, endianness... 21:47
(working on a fix) 21:50
not_gerd on a related note, is the bytecode guaranteed to be aligned correctly? 21:51
otherwise, the GET_I* macros may segfault on architectures that don't support unaligned access 21:52
not every architecture is as forgiving as x86 21:53
jnthn not_gerd: No, it's not, and on such architectures we'll need to manipulate the bytecode, just as we already have to on big-endian. 21:54
not_gerd I guess we'll wait to cross that bridge until it becomes an issue ;) 21:55
jnthn aye 21:56
not_gerd as long as there's a plan on how to deal with it, everything's good
jnthn "First, make a product that people *want* on their platform" :)
not_gerd jnthn: I also did some thinking on how to get a JIT compiler into Rakudo/MoarVM 22:07
see gist.github.com/gerdr/68fbfbab5baf55dfd98a for some bikeshedding
jnthn diakopter: I'm not sure that the op and instr in the backtraces add much value... 22:13
Are you terribly attached to them?
dalek arVM: 71576da | jnthn++ | src/ (6 files):
Fix bytecode annotation lookup.

It made bad assumptions about C structure packing and didn't handle endianness right. Still doesn't in bytecodedump, though it at least looks a lot righter on little endian now.		 22:14
arVM: 97942bf | jnthn++ | src/core/exceptions.c:
Don't leak annotation lookup result.
TimToady not_gerd: when you say "type inference" I think that in addition to multi prediction, it will have a lot of optimization potential for propagating lazy/sink/eager/hyper/race context inward at the same time 22:15
not_gerd TimToady: does this pass a basic sanity check? 22:16
TimToady in particular, lists that don't have to have the lazy apparatus can be batched or done as a whole as P5 does
not_gerd: I'm not an expert in the low-level bits of it, but it sounds goodish
22:17 FROGGS joined
TimToady I suspect the current approach will be to just stay within hailing distance rather than targeting a JIT off the bat 22:17
but it might be good to think about whether anything in the instruction set would preclude that later
jnthn++ et al have been doing a pretty good job of keeping the instructions simple, from my (distant) viewpoint 22:18
jnthn Having pondered the JIT stuff, my feeling is that getting the REPR specialization stuff in place probably has a lot of bang for buck.
22:18 jnap joined
TimToady well, that's where the type inference rubber meets the instruction set road 22:19
assuming we're not in a flying car
jnthn It's not so much inference as "OK, we observe we get these things"
not_gerd does Rakudo support multi-dispatch on REPRs?
TimToady you mean at run time?
jnthn Not short of where .REPR eq ... 22:20
TimToady is hoping for a little more compile-time smarts too...
jnthn TimToady: Well, we're already doing a little of that, too. Though it can also go a lot further.
That is, multi inlining at compile time.
not_gerd well, multi-dispatch on REPR would be more or less a pre-requisite to make my particular idea work 22:21
TimToady I think optimizing away laziness will also be a biggie
jnthn not_gerd: I suspect that's the wrong factoring. 22:23
not_gerd jnthn: in what way?
jnthn It's as interesting for single-dispatch or just any frame really. 22:24
not_gerd jnthn: so promote single-dispatch to potentially-multi dispatch 22:25
jnthn I think what we're looking at is below the level of actually manipulating the Rakudo-level multi candidate lists.
not_gerd any callsite that does not call a sun with complete type information should be made multi-able
jnthn I don't think MoarVM should actually have that deep knowledge of how Rakudo lays its Routine out. Knowing about the multi cache, however, is fine. 22:26
not_gerd jnthn: triggering dynamic recompilation would happen Rakudo-side 22:27
jnthn That sounds like the kind of coupling I really don't want.
not_gerd digs out a video to somewhat related work by oracle labs 22:28
jnthn The reason we have all of the 6model ops as MoarVM ops is so we can push the interesting semantic info down VM-wards.
not_gerd jnthn: arguments can be made that some stuff wants to happen at a high level 22:29
jnthn Sure, but not JIT repr-specialization, IMO
not_gerd I believe that's the video I was thinking about: medianetwork.oracle.com/video/playe...5432528001
jnthn That's not the vision I had when I designed 6model a few years ago, anyways. :) 22:30
oh yay, the video to go with the slides! :)
not_gerd: I'll certainly watch that, though not tonight. :) 22:31
not_gerd jnthn: where would you image to hook in repr-specialization if not the multi-dispatcher?
I see that as a very convenient point to wire up arbitrary recompilation 22:32
after all, reprs are just another type of polymorphism
jnthn not_gerd: When a bytecode frame gets JIT-compiled, the JITted code would be type+REPR-conditional 22:33
A lot of code will be monomorphic in both dimensions. 22:34
for example, consider a submethod BUILD() { $!foo = 42 } 22:35
There's likely not many types self can be, and possibly only ever a given REPR
s/given/single/ 22:36
Then observing that if self starts with a given REPR, it's going to keep it, and given it's probably P6opaque, the $!foo lookup can almost certainly be JIT-compiled into adding an offset to the self pointer. 22:37
To a limit, a given frame may have several JITted specialized variants. 22:38
TimToady assuming no MI chicanery, of course...
jnthn Right. :)
MI throws you back onto the unoptimized path. 22:39
My idea was to initially prototype this stuff by specializing to an intermediate form we could JIT from, but then interpreting it to start with. 22:40
Which should still come out ahead.
TimToady is in favor of coming out ahead 22:41
jnthn Building it that way would naturally lead us to separate the analysis/specialization logic from the details of a particular CPU instruction set, which is likely also good design.
.oO( It may also mean I can focus on the specialization logic and get away with emitting the machine code... :P )
 22:42
Inlining I guess gets intresting once you start coalescing the guards... 22:43
um, however you spell it... :)
TimToady intRESTing? 22:44
jnthn oh, I thought I got coalescing wrong :P 22:45
not_gerd well, I still like my idea because it automatically takes care of guard clauses 22:50
assuming sufficietly smart type propagation, the type information will bubble all the way down and call-sites further down the call chain 22:51
s/and/to/
I think I'll just post an example of how I image this to work out before going to bed 22:58
say foo(x) calls bar(x) 22:59
at a particular call site, foo() gets called with x of type int 3 times in a row
if there's no multi for foo(int), we generate one
type inference will show that bar() also necessarily gets called with type int, and we force-compile bar() as well with correct type information
the bar() callsite within that particular foo() becomes static and the guard has been pushed up to the call site of foo() 23:00
needs to get some sleep o/ 23:04
23:04 not_gerd left 23:15 BenGoldberg joined
jnthn sleep also & 23:18
23:35 FROGGS joined 23:40 cognominal 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!