github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 5 October 2013.
diakopter oh, heh, b/c clang instrumented every memory access with its guards 00:09
01:58 colomon joined 01:59 cognominal joined 02:13 FROGGS joined
[Coke] lemme know if you want a list of opcodes that don't exist in moarvm but do in some other nqp backend. 02:16
sorry, in nqp-moarvm, I mean. 02:17
02:31 wsri joined
JimmyZ .tell jnthn what's the plan to re-order the ops? :-) 02:44
yoleaux JimmyZ: I'll pass your message to jnthn.
TimToady we'll have to get an RMA to return the originals to the factory first :P 02:47
03:00 FROGGS joined 03:08 FROGGS joined 03:13 lizmat joined 03:14 woolfy joined 03:34 lizmat joined 03:37 woolfy joined 04:44 sisar joined 06:20 FROGGS joined 06:57 foo_bar_baz joined 08:01 FROGGS joined
FROGGS o/ 08:07
/home/froggs/dev/nqp/install/bin/moar --libpath=src/stage1 src/stage1/nqp.moarvm --bootstrap --setting=NULL --no-regex-lib --target=mbc \\ 09:10
--output=src/stage2/nqpmo.moarvm src/stage2/gen/nqpmo.nqp
Missing or wrong version of dependency 'nqp-src\\NQPCORE.setting'
FROGGS scratches his head
ahh, stage0's NQPCOREMoar.setting.moarvm knows about nqp-src\\NQPCORE.setting 09:19
jnthn I think it's stage1 knows about stage0's setting, actually 09:30
yoleaux 02:44Z <JimmyZ> jnthn: what's the plan to re-order the ops? :-)
03:44Z <japhb__> jnthn: Thoughts on irclog.perlgeek.de/perl6/2013-10-06#i_7677518 through irclog.perlgeek.de/perl6/2013-10-06#i_7677853 very much appreciated.
03:46Z <japhb__> jnthn: In particular, I *think* much of the problem in this space can be summarized by irclog.perlgeek.de/perl6/2013-10-06#i_7677850 .
FROGGS ahh, okay 09:39
jnthn: do you have local changes in your Makefile-Mmoar.in? I'd do some whitespacce cleanup if you don't 09:42
jnthn FROGGS: no, go for it 09:44
As for the bootstrap issue, I think it's 'cus we're missing the usecompileehllconfig/usecompilerhllconfig thing, as seen in the JVM version of ModuleLoader.nqp 09:49
FROGGS hmmm, at least it seems that these ops are not overcompliated 09:51
jnthn Well, I think the majority of the work wants to live in hll.c/hll.h 09:53
It'll need some care with memory management too
Which we kinda get "for free" on the JVM
FROGGS eww :/
jnthn But yeah, it's not too hard.
Just needs a little care to make sure both sets of HLL configs get GC marked 09:54
FROGGS ahh, here comes the --bootstrap option into account
09:56 grondilu joined
jnthn yeah 09:59
diakopter g'morn
jnthn Anyways, I can't look at it for a bit...gotta take care of some other things today
So feel free to work on it. :) If not, I can maybe look this evening. 10:00
FROGGS morning diakopter
jnthn o/ diakopter
FROGGS for the jvm compileecfg and compilercfg are stashed to the global context... do we hang that off the tc for moarvm? 10:01
jnthn no, JVM global context = MoarVM instance
Which is where HLLConfig lives today
Reachable from tc->instance 10:02
FROGGS ahh, tc->instance->hll_configs
yes, I see
jnthn Yeah. Well, the change means that that is just the current effective set of configurations
And it can point to either the compiler or compilee set of configurations 10:03
I guess that means that we GC mark the compiler/compilee hashes, and not hll_configs itself...
yeah, looks like 10:04
And be sure to take the mutex while doing the changes :)
10:56 not_gerd joined
not_gerd o/ 10:56
dalek arVM/ext: fc05347 | (Gerhard R)++ | src/ (5 files):
Implement extension op registry
arVM/ext: 6e892e5 | (Gerhard R)++ | / (3 files):
Generate dummy labels for extension op cgoto dispatch
arVM/ext: 3673dc8 | (Gerhard R)++ | build/Makefile.in:
Add missing header dependency
arVM/ext: 1d035d1 | (Gerhard R)++ | src/ (3 files):
Dispatch extension ops
jnthn o/ not_gerd++ 10:58
diakopter WOW 11:02
diakopter holds 3 fingers up on each side of my wide-open mouth, mouthing WOW
jnthn This weekend, moar and moar stuff just keeps on coming :) 11:03
not_gerd note that extops cannot be used yet because missing them with the compilation unit is NYI 11:06
s/missing/registering/ 11:07
diakopter not_gerd: what's your last name btw :)
not_gerd Gärtner
(oh noes, now I've started mixing online persona I previously kept seperate) 11:08
;)
jnthn You shoulda told us it was "not Gärtner" ;) 11:09
diakopter :D
not_gerd the NSA might be able to find out everything I do online if so desired, but I don't really see a reason to make it easy for private companies 11:12
eg you cannot (easily) link my facebook and github accounts
any comments on gist.github.com/gerdr/914b2b8f39b33d9ad14a 11:17
I'll start on that later today
jnthn nqp::loadlib('p6', 'path/to/p6.dll'); 11:19
Is the p6 a kind of "handle" here?
So the
nqp::loadext('p6', 'MVM_ext_perl6_init');
uses p6 to locate the library handle? 11:20
not_gerd correct
jnthn tries to remember why we need the prepextops/installextop thing 11:21
(that is, why the MVM_ext_register_op doesn't cut it) 11:22
not_gerd we need a mapping from cu-specific opnumber in the bytecodestrem to the op name 11:23
as we validate frames lazily (afaik), doing that via ops called from the load frame should work out 11:24
jnthn No, that's done differently, according to extops.markdown 11:25
Under "Representing Extension Op Calls on Disk and in Memory"
not_gerd jnthn: this would inline the extop table into the bytecode stream 11:35
avoids me having to change the bytecode format
jnthn Yes, it also means it's no longer declarative 11:37
So you can't implement --dump any more.
Or at least, can't have it dump anything about the extops
It really wants to be a table. 11:38
11:38 colomon joined
jnthn We should be able to parse the bytecode file statically without having to execute anything. 11:38
ah, and yeah, --dump really would be hosed in so far as if it doesn't know the op signature it doesn't know how to find the next instruction.... 11:42
not_gerd all good points
diakopter we discussed the design extremely thoroughly :D
not_gerd I just wanted to quickly get to something that I can actually run and test ;) 11:45
so, no cutting corners and I'll see if I can mock some tests on the C level
diakopter jnthn: so, how quickly does --optimize MoarVM build nqp? 11:59
[compared to parrot/jvm]
(looking for sound bites here)
FROGGS: do you have numbers? 12:06
[are they disappointing? o_O] 12:07
jnthn I didn't compare yet 12:08
diakopter: Given we only have stage1 done so far, it's not even that easy to compare 12:09
FROGGS well, I could compare it against parrot's make stage1 12:15
but I am testing something atm so... I'll paste numbers later 12:16
it seems like it doesnt complain now about usecompileeconfig, but my feeling is that if a patch seems too easy, I might have not understand the problem 12:17
s/seems/seems to be/
BinGOs I have been trying out MoarVM on Hurd 12:20
jnthn diakopter: If you want a soundbite, just compare bytecode file size :P 12:21
BinGOs src/io/dirops.c:298:15: error: ‘PATH_MAX’ undeclared (first use in this function)
jnthn BinGOs: How does it work?
heh, doesn't build 12:22
BinGOs www.gnu.org/software/hurd/community...xpath.html
12:22 lizmat joined
diakopter "simply sloppy coding" *sigh* 12:24
BinGOs >:)
diakopter :P
BinGOs I had to change build::setup slightly to get to this point too. 12:25
jnthn
.oO( POSIXier than thou :P )
 12:26
12:28 lizmat joined
BinGOs If I fudge it #ifdef __GNU__ #define PATH_MAX 256 12:35
it gets further
dyncall_macros.h:125:3: error: #error Unsupported OS. #error Unsupported OS.
oh well. 12:36
a bit of fun while I was installing perl-5.18.1 12:37
dalek arVM/ext: 8af0b7a | (Gerhard R)++ | docs/bytecode.markdown:
Suggested changes to the bytecode format to support extension ops
 12:39
not_gerd jnthn: ^^ 12:40
FROGGS /home/froggs/dev/nqp/install/bin/moar --libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap --setting=NULL --no-regex-lib --target=mbc \\ 12:51
--output=src/stage1/nqpmo.moarvm src/stage1/gen/nqpmo.nqp
Use of undeclared variable '$info' at line 911, near ")\\n }\\n\\n "
panic
jnthn: you had that too one?
once*
my $info := nqp::hash(); 12:53
$info<attribute> := @repr_info;
nqp::composetype($obj, $inf) <--- line 911
err, $info is there
tadzik inf vs info?
FROGGS no, was just a pasto here
tadzik mhm
FROGGS seems my stage0 breaks it 13:03
jnthn not_gerd: wfm 13:04
FROGGS: No, not seen that before
afk for a bit
FROGGS jnthn: it segfaults obviously because I guess the approach is totally off... gist.github.com/FROGGS/2ab383d2b3803d8bcf8f 13:24
not_gerd also afk 13:29
13:53 sisar joined
FROGGS gah 14:50
:o)
wow, I slept less then an hour, but it feels like three 14:51
jnthn Now you can debug all the things! \\o/ 14:52
FROGGS hehe
but not mine \\o/
\\o\\ let's rock the code! /o/
but first coffee 14:53
tadzik Let's rock the coffee! 14:54
jnthn oh noes, don't spill any!
FROGGS the coffee is safe 15:07
jnthn
.oO( and idempotent )
 15:08
FROGGS hmmm, en de: idempotent -> idempotent 15:09
not very helpful
masak FROGGS: "idempotent" roughly means "doing it N > 1 times has the same effect as doing it 1 time".
FROGGS: or, in symbols, an operation $e$ such that $e ** N == e$ 15:10
FROGGS hehe, well, as long as I have coffee :o)
jnthn Sorry, was just working on some REST slides :P
masak :) 15:13
FROGGS: there's also "nilpotent" which means, roughly "doing it enough times takes you back where you started". increasing the hour on an analog clock is a good example. 15:14
FROGGS interesting... 15:16
jnthn None of which should be confused with impotent, which menas you don't do it any times... 15:17
FROGGS masak: that is like leaning the room when you have kids
cleaning*
masak FROGGS: :P
FROGGS arrggghhh, that c drives me razy! 15:18
masak I don't think so, kids are not referentially transparent...
FROGGS no, not transparent... covered in chocolate and other stuff atm
masak :) 15:19
15:22 not_gerd joined
not_gerd o/ 15:22
masak: I wouldn't call periodic things nilpotent 15:23
once we reached 'nil', we normally stay there
masak not_gerd: I got the definition from Wikipedia.
not_gerd "In mathematics, an element x of a ring R is called nilpotent if there exists some positive integer n such that x**n = 0" 15:24
masak not_gerd: besides, it does make sense. this happens in cyclic groups of non-prime order, for example. you get a * b == 0 with some a, b nonzero.
not_gerd then x**(n+1)=0 as well 15:25
masak yeah.
that's how 0 tends to work... :) 15:26
not_gerd but that's not how clocks work
masak oh, so the clock was a bad example. I agree.
not_gerd (not even when falling into a black hole)
FROGGS /o\\ 15:27
masak :)
jnthn FROGGS: Got any further than the gist you posted earlier? 15:45
ah, that ain't quite right...
FROGGS jnthn: nope, because it would just go further in the wrong direction :o) 15:51
if I got any further at all... 15:52
jnthn
.oO( still better than One Direction... )
 15:59
OK, I'll take over :) 16:00
FROGGS \\o/
not_gerd so, let's write some moar extension code ;) 16:09
jnthn FROGGS: oh, I think I found a really easy way to write it now I try it myself... 16:12
FROGGS cool! 16:17
16:25 ssutch joined
dalek arVM: 7ed109a | jnthn++ | / (11 files):
Support compiler/compilee HLL config distinction.

Needed for bootstrap scenarios.		 16:39
arVM: 896cb0f | jnthn++ | nqp-cc/nqp-src/ModuleLoader.pm:
Use compilee HLL config when bootstrapping.
FROGGS ahh 16:44
jnthn Well, it moves the error...
FROGGS jnthn: do I need a new stage0 now? 16:46
jnthn FROGGS: I'm looking into the next failure before I update it as I think it'll need yet another change... 16:47
FROGGS ahh, mkay 16:49
dalek arVM/ext: b98a75f | (Gerhard R)++ | src/ (7 files):
Resolve extension ops on validation
 16:50
not_gerd that's it for now
I might look into the bytecode stuff later today
dalek arVM: 99ffb28 | jnthn++ | nqp-cc/nqp-src/NQPHLL.nqp:
Also need compilee mode for role bodies, BEGIN...
 17:04
FROGGS hmmm, it just segfaults with my stage0 17:10
/home/froggs/dev/nqp/install/bin/moar --libpath=src/stage1 src/stage1/nqp.moarvm --bootstrap --setting=NULL --no-regex-lib --target=mbc \\ 17:11
--output=src/stage2/nqpmo.moarvm src/stage2/gen/nqpmo.nqp
make: *** [src/stage2/nqpmo.moarvm] Segmentation fault (core dumped)
(stage2 that is)
jnthn dinner & 17:13
darn 17:50
segv...
0x0038000400000000...that's a rather dubious pointer. 17:51
FROGGS I only see that: Program received signal SIGSEGV, Segmentation fault. 17:52
0x000000000042d770 in MVM_interp_run ()
jnthn I'm getting in different place but with local changes
dalek arVM: 9d91e67 | jnthn++ | src/6model/reprs/P6opaque.c:
Fix memory leak related to mixins.
 18:17
18:28 diakopter joined
jnthn wow, conditional breakpoints really slow things down... 18:41
FROGGS :/ 18:42
jnthn Got some kind of GC bug 18:45
diakopter d'oh
might try it with the gcorch branch merged, but with ratio set to 100000
jnthn It's taking quite some hunting... 18:46
FROGGS I guess GC bugs are always like that
jnthn It appears that somehow, a pointer into the inside of another object gets put into the worklist 18:53
diakopter er, what's wrong with that? 18:54
jnthn Ah, I mean post-dereferene 18:55
That is, a pointer to an address that is into the middle of another object
not_gerd hm... 19:04
see github.com/MoarVM/MoarVM/blob/mast...ode.c#L174 19:05
am I missing something or is there a 4 byte hole that shouldn't be there?
ie the 40 should be a 36 19:06
jnthn not_gerd: Yeah; I'm guessing there's a matching hole in the writing then... 19:18
Seems the corruption happens some way back...hmm 19:19
(in the gc thing I'm tracking)
diakopter feels bad that the gcorch branch isn't merged 19:20
jnthn Well, it's possible I'm hitting the bug that was tripping you up in the gcorch branch too...
diakopter I suppose, but it feels really unlikely knowing the bugs I know I fixed in the gcorch branch :) 19:21
not_gerd also, the SC data segment header (supposedly located between the strings and bytecode headers) appears to be gone
jnthn We probably want that one :) 19:23
not_gerd so, I'll add the header entry for extops, leave the space for the SC data segment reserved (but add a comment that the hole is supposed to be there) and remove the 4 byte hole I mentioned earlier 19:25
jnthn +1 19:26
FROGGS gnight 19:52
20:01 japhb_ joined
jnthn GC bug looks like a case of an out of date pointer at the end of the day... 20:05
20:22 foo_bar_baz joined
dalek arVM: 13c75ec | jnthn++ | src/gc/collect.c:
Tighten already-tospace test; add a sanity check.

While this won't catch *all* cases of out of date pointers, it will cause a panic if we see a pointer that should be in fromspace, but is actually into tospace (which was a fromspace in the past) and is ahead of the bit of tospace we've copied into so far.		 20:28
arVM/ext: 802e4a2 | (Gerhard R)++ | src/core/bytecode.c:
Add extension ops entry to bytecode header and fix offsets.

The writer still needs to be adjusted.		 20:31
arVM/ext: 7c02802 | (Gerhard R)++ | src/mast/compiler.c:
Write new bytecode header
jnthn diakopter: 13c75ec trips on the couple of cases I'm looking at. Both times the out-of-date object is a string
dalek arVM: 039253f | jnthn++ | src/core/args.c:
Missing root of key in slurpy named handling.

If the boxing of the object allocates, then key could become out of date. Doesn't fix the issue tripping up bootstrap, sadly.		 20:45
diakopter jnthn: increase the nursery size to 100MB for bootstrap... ;) 20:52
jnthn diakopter: Hiding the problem won't help us in the end 20:53
diakopter apparently you missed the smiley ;)
jnthn diakopter: It'll just bite when we have to compile *really* big things (like, Rakudo's setting)
diakopter ^ there it was again ;)
jnthn :P
You may want to see if 13c75ec trips in gcorch btw... 20:54
diakopter k
dalek arVM: 6814d0e | jnthn++ | src/gc/collect.c:
Include pointer in the panic.
 20:56
diakopter are we taking bets on how much memory rakudo will reside in?
not_gerd NQP revision 2013.09-118-g23985aa required (currently 2013.09-117-g959d4c6).
curses, off-by-one strikes again
jnthn ain't having much luck tracking this down :( 21:09
dalek Heuristic branch merge: pushed 30 commits to MoarVM/ext by gerdr 21:18
not_gerd g'night o/ 21:22
21:23 not_gerd left
jnthn ah, progress 21:28
Something goes wrong when we're processing a positional slurpy argument and we trigger a GC.
dalek arVM: 9be2af1 | jnthn++ | src/core/args.c:
When slurping a str arg, root it.

Otherwise, the box allocation can do a GC run, and then the pointer to the string that we looked up is then out of date.		 21:34
jnthn The good news is that fixes the GC bug that showed up in t/serialization/01-basic.t in selftest. 21:35
The bad news is that it doesn't fix the bootstrap one.
lizmat hopes that fix provides inspiration for fixing the other one 21:37
grondilu each time you make a modification in moarvm or nqp's source code, do you need to go through stage0 and stage1 again? (I understand you're having issues with stage2) 21:40
jnthn Good heavens, i think it's in args.c again. 21:41
yah, got further 21:42
dalek arVM: b12fc1f | jnthn++ | src/core/args.c:
Need to root objects *before* allocating!

This one seems to fix the SEGV that was in the way of bootstrap work.		 21:43
grondilu so... champagne?? 21:44
jnthn Well, not really :) 21:46
This just means stage1 build completes without a segfault.
And the result gets somewhere beyond bootstrap layer confusion. 21:47
dalek arVM: d66dd52 | jnthn++ | src/gc/ (2 files):
Add cur_frame separately to rest of tc roots.

Keeps worklists a little smaller, but also can be good debugging wise to know which is to blame.		 21:48
timotimo how close did we get today? :) 22:33
what do i have to do to check out what's going on? 22:34
.o(roarkudo)
dalek arVM: b03a1dc | jnthn++ | src/6model/serialization.c:
A couple of minor serialization tweaks.
 22:50
jnthn timotimo: stage1 builds and starts up, but there's something wrong with invocation of action methods...well, that's the upshot, but I think the real issue must lie a little deeper... 22:52
timotimo isn't it always :) 22:53
what kind of thing do i set the --prefix to? 22:55
jnthn To the same place you gave as --prefix to MoarVM's configure
And need a make install in MoarVM
If you don't give it one, it uses .
timotimo ah, good 22:56
huh, While looking for 'QAST.moarvm': no such file or directory - i set the prefix to where my moarvm installed to and i did make install in there 22:58
(there is only QASTMoar.moarvm and friends in src/vm/moar/stage0
jnthn huh 23:00
no idea what you've done :)
timotimo i'll just wait for the bootstrap work to finish so i don't have to make my hands messy :)
jnthn Think I'v efound it... 23:40
Was a code-gen bug, of all things...
dalek arVM: 4c4fd04 | jnthn++ | nqp-cc/src/QASTOperationsMAST.nqp:
Don't mutate the AST as we're compiling it.
 23:49

Powered by Cro and the Raku® Programming Language.

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

Thank you!