Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-12-02

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:15 vendethiel joined #moarvm
01:06 vendethiel joined #moarvm
01:52 vendethiel joined #moarvm
02:24 jimmy_ joined #moarvm
02:28 jimmy_ timotimo: I think it's not a small project, since it maybe needs ssa form to do better static optimization, maybe I'm wrong :)
02:59 timotimo no clue
03:02 jimmy_ timotimo: btw, did you see the esc paper?
03:02 jimmy_ timotimo: I think you may be interested with it :P
03:02 timotimo i shall have a look
03:02 timotimo after bedtime :)
03:03 jimmy_ the link is in #perl6
03:03 timotimo i recall :)
03:03 jimmy_ good night :)
03:03 timotimo i think you overestimated the scope of what i was suggesting above
03:03 jimmy_ maybe ...
03:04 timotimo all i meant was to look at the code-gen in the QASTCompilerMAST to see why it emits a set after every wval, many getlex-like operations etc etc
03:04 timotimo you could moar --dump CORE.setting.moarvm | grep -B 1 'set '
03:05 jimmy_ oh, I will give it try, but with no guarantee
03:05 timotimo OK
03:05 timotimo do you know of the "result_reg" mechanism the InstructionList class uses?
03:06 jimmy_ yeah, I have tried it a bit long long ago, but I can't find where are they from :(
03:07 jimmy_ and it can't reuse the reg , IIRC
03:07 timotimo each piece of as_mast will usually allocate a result_reg or get one passed from its caller
03:07 timotimo not 100% sure
03:07 jimmy_ and we maybe needs vanilla reg allcation
03:08 timotimo also, there's more uses of InstructionList in rakudo's moar/Perl6/Ops.nqp
03:10 timotimo i'm off now for reals :)
06:27 jimmy_ joined #moarvm
07:21 FROGGS joined #moarvm
07:31 oetiker joined #moarvm
07:46 zakharyas joined #moarvm
08:11 zakharyas1 joined #moarvm
08:49 vendethiel joined #moarvm
09:12 dalek MoarVM: 650333f | TimToady++ | src/6model/reprs/NFA.c:
09:12 dalek MoarVM: trap epsilons to 0
09:12 dalek MoarVM:
09:12 dalek MoarVM: The NFA construction code could accidentally introduce a state with no
09:12 dalek MoarVM: edges, which under epsilon removal produced an epsilon that forwarded to
09:12 dalek MoarVM: state 0, which doesn't work so well.  This bug is now fixed, but until
09:12 dalek MoarVM: we rebootstrap, we rely on moar's NFA to ignore null epsilons for later
09:12 dalek MoarVM: stages optimizing earlier stages' NFAs.
09:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/650333f63a
09:21 woolfy left #moarvm
09:45 vendethiel joined #moarvm
10:21 vendethiel joined #moarvm
11:11 vendethiel joined #moarvm
13:28 nwc10 ug, I seem to be able to get NQP test hangs on Ubunut
13:28 nwc10 (this is not "my" machine, which is Centos, but my work desktop)
13:28 nwc10 hang is zombie sh process, MoarVM stting in
13:28 nwc10 epoll_wait(5,
13:28 nwc10 and I really don't have time to debug this
13:28 nwc10 but just reporting it, in case folks know why
13:44 jnthn Not seen that, but do yuou know which teste?
13:46 nwc10 t/nqp/19-file-ops.t t/nqp/78-shell.t t/nqp/86-pipes.t
13:46 jnthn EIOIO
14:14 vendethiel joined #moarvm
14:42 dalek joined #moarvm
15:12 timotimo jnthn: what MAST op (or alternatively QAST op) do i use to pre-size an array before pushing a known number of items into it?
15:12 jnthn setelems iirc
15:12 timotimo thanks
15:13 timotimo the code that emits the string heap in bootstrarray form could probably benefit from pre-sizing
15:13 timotimo the code that calls getcode on a whole bunch of things and pushes them into a list could probably benefit, too
15:16 timotimo jnthn: can you explain what $newer is supposed to do here? https://github.com/perl6/nqp/blob/master/src/vm/moar/QAST/QASTOperationsMAST.nqp#L514
15:16 timotimo oh
15:17 timotimo it's probably there to assure that the return value of the generated instruction list is the list
15:17 JimmyZ_ joined #moarvm
15:19 jnthn timotimo: yes, exactly that
15:19 jnthn Not a great name
15:19 timotimo i may touch it up
15:37 vendethiel joined #moarvm
15:57 nwc10 oooh, Racy :-(
15:57 nwc10 in static MVMint64 eof
15:57 nwc10 if (data->filename) {
15:57 nwc10 ...
15:57 nwc10 bad idea. Really always fstat the filehandle.
16:11 dalek joined #moarvm
16:22 vendethiel joined #moarvm
19:07 FROGGS joined #moarvm
19:28 lizmat joined #moarvm
19:38 dalek joined #moarvm
19:42 dalek joined #moarvm
20:02 dalek MoarVM/6pe: 62387b8 | jonathan++ | docs/6model-parametric-extensions.markdown:
20:02 dalek MoarVM/6pe: Start documenting the parametric 6model design.
20:02 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/62387b80b5
20:02 dalek MoarVM/6pe: 4b59fbc | jonathan++ | / (6 files):
20:02 dalek MoarVM/6pe: Stub parametricity-related ops.
20:02 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/4b59fbcd34
20:02 dalek MoarVM/6pe: 4ea8e4c | jonathan++ | src/6model/6model.h:
20:02 dalek MoarVM/6pe: STable extensions for parametricity.
20:02 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/4ea8e4c4f5
20:02 dalek MoarVM/6pe: 8a433dd | jonathan++ | src/gc/collect.c:
20:02 dalek MoarVM/6pe: GC marking for STable parametricity bits.
20:02 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/8a433ddf92
20:02 dalek MoarVM/6pe: 31cf163 | jonathan++ | / (5 files):
20:02 dalek MoarVM/6pe: Basic implementation of parameterization ops.
20:03 jnthn Don't get excited, was just a rebase so I have it on top of something recent :)
20:04 FROGGS *g*
20:07 [Coke] awwwwww
20:08 dalek joined #moarvm
20:08 * jnthn did just write a couple more failing tests to try and make pass, though :)
20:09 FROGGS my goal for today is to do something for Perl 6 today...
20:10 FROGGS did nothing for two weeks or so... at least it feels like it has been two week
20:10 FROGGS s
20:11 jnthn I'd say "same", but I distinctly remember a train journey last Friday involving lldb and the OSX guardmalloc.. :P
20:11 * TimToady hopes natives are still percolating in the hindbrane
20:12 nwc10 FROGGS: you helped me. That was doing something
20:12 jnthn Well, that's a bit part of what 6pe is working towards.
20:12 jnthn *big
20:12 FROGGS nwc10: yeah, but I feel the urge to git commit something:o)
20:13 jnthn I'd really like to do the native arrays on a better base than current types arrays are on (and clean up typed arrays in the process)
20:13 jnthn TimToady: Any further thoughts on the array (non-lazy, native) vs Array line of thinking?
20:13 * TimToady doesn't object at all :)
20:14 jnthn We know native arrays need to have a different representation.
20:14 TimToady still seems like a reasonable distinction to me
20:14 jnthn OK
20:14 jnthn Will something like, "if the type you specify in my type @foo is a native one, then the default is array, not Array" rule be sane enough?
20:15 jnthn uh, so grammar...
20:15 TimToady we might be able to specialize some Array to array if we know thigns
20:15 jnthn I think it was understandable :)
20:15 TimToady uh, so spelling
20:15 TimToady yes, I'd expect native arrays to be native :)
20:16 TimToady and non-native arrays to be restless
20:17 jnthn OK
20:17 jnthn I'll head in that kinda direction and see where we end up :)
20:18 jnthn Still pondering a bit what the answer to @native-array.HOW.WHAT should be...
20:18 jnthn Though "ClassHOW" was a fine enough answer for the buf stuff.
20:24 nebuchadnezzar hello
20:24 nebuchadnezzar maybe someone could update the homepage http://moarvm.org/ ?
20:26 jnthn Uh, maybe, yes... It's *two* releases behind...
20:26 jnthn D'oh.
20:36 dalek joined #moarvm
20:41 dalek MoarVM/6pe: 5b2f613 | jonathan++ | src/6model/ (2 files):
20:41 dalek MoarVM/6pe: Start interning parameterizations.
20:41 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/5b2f6132ed
21:18 FROGGS jnthn: we have a global symbol merger that runs when we deserialize, right?
21:31 TimToady .oO(we just used to call that a "linker")
21:33 FROGGS could have been called "rechter" too
21:55 FROGGS jnthn: is that what I am looking for? MoarVM/src/6model/serialization.c:2418:    work_loop(tc, reader);
22:07 timotimo isn't it repo_conf_res?
22:07 timotimo $repo_conf_res, FROGGS?
22:11 FROGGS timotimo: in MoarVM?
22:11 FROGGS ahh, in nqp
22:13 FROGGS have to sleep about that... gnight
22:30 vendethiel joined #moarvm
22:34 jnthn .tell FROGGS no, we do the symbol merging in normal code, not inside of the VM, since the rules are down to the language. See merge_globals or so in the Perl 6 module loader, or NQPs one. Also, if there are deserialization conflicts, the language's module loader can resolve them too, which is the thingy timotimo pointed you at; that's separate.
22:35 timotimo OK
22:36 timotimo jnthn: when i talked about storing the serialized blob in "not base64" in the deserialize function you said something about utf8; how did you mean that?
22:36 jnthn Basically, a module puts the things it wants to contribute to the real GLOBAL into a lexical GLOBALish in UNIT
22:36 timotimo also: can our strings properly contain null bytes without stuff b0rking?
22:37 jnthn timotimo: There's a special section in the bytecode file for storing serialized data, so it doesn't matter what bytes it contains; it's not a string, it's just a load of bytes.
22:37 jnthn Our strings can contain null bytes just fine because they always carry length around with them.
22:37 timotimo well, that's not what i mean, though
22:38 jnthn I'm pretty sure in the string heap in the bytecode file the size is written, then the data, then some padding bytes
22:40 jnthn Also: phew, YAPC::EU and YAPC::Asia don't come way too close to each other this year. :)
22:40 timotimo deserialization_code starts out with my str $serialized := nqp::serialize($sc, $sh)
22:41 timotimo where $sh is apparently the string heap that's there "in code"
22:41 timotimo as in: the sh gets assembled as a nqp::list_s that gets every string push_s'd into it
22:41 jnthn Yes.
22:42 jnthn Those are taken from the bytecode file's own string heap
22:42 jnthn But yeah, it's a level of indirectin
22:42 jnthn It's not perfect
22:42 jnthn A declarative approach would be preferable
22:43 jnthn But it does keep two things at a distance from each other, which is a nice thing.
22:43 timotimo yeah, but what about the serialized blob that's put into the string heap as base64 coded serialization data?
22:43 jnthn I don't know why that's ever happening.
22:43 jnthn It shouldn't be.
22:43 jnthn Not ever on MoarVM or JVM.
22:43 timotimo maybe that comes from having another SC where we override stuff?
22:44 jnthn But it's about the currently compiling SC, or at least it should be.
22:44 jnthn If we're getting stuff in base64 in th estring heap on Moar, there's almost certainly a bug somewhere.
22:44 jnthn I can't easily imagine where, though...
22:44 timotimo if $comp_mode {
22:44 timotimo $block.push(self.deserialization_code($cu.sc(), $cu.code_ref_blocks(),
22:44 timotimo $cu.repo_conflict_resolver()));
22:45 timotimo }
22:45 timotimo that's the deciding factor whether or not to emit the code that does the base64 thing
22:45 jnthn No, it's not that simple.
22:45 timotimo the base64 decode is right at the beginning of dissect_and_somethingsomething_data
22:45 jnthn That's just "should we emit serialization stuff"
22:46 jnthn If it manages to store the serialization blob in a better way, it hands back a null string.
22:46 timotimo oh, i didn't know about that
22:46 jnthn Which in normal compilation it always should be.
22:46 timotimo i've seen a bunch of null_s where i would have expected the base64 blob to appear
22:46 jnthn Right, that's what should always happen.
22:46 * timotimo looks closer
22:46 jnthn That is the "we stored it in the appropriate segment in the .moarvm file" indicator
22:47 jnthn So, the situations where we *don't* have that are the ones where something goes amiss.
22:47 timotimo i was expecting nqp::serialize to *always* hand back a base64 string if there's anything at all or otherwise a null_s
22:47 jnthn No, null_s means "look for it in the bytecode file segment"
22:47 timotimo i shall put some debug stuff everywhere
22:49 jnthn timotimo: Look around here for it. https://github.com/MoarVM/MoarVM/blob/master/src/6model/serialization.c#L767
22:52 jnthn Sleep time... o/
22:52 timotimo yes, found that exact spot by myself in the mean time :)
22:53 vendethiel joined #moarvm
23:06 timotimo great. now i can't reproduce the base64 blobs any more
23:28 vendethiel joined #moarvm
23:32 lizmat joined #moarvm
23:33 ggoebel111111115 joined #moarvm
23:53 vendethiel joined #moarvm
23:57 woolfy joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary