Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-04-11

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

All times shown according to UTC.

Time Nick Message
00:31 sortiz joined #p6dev
01:47 ilbot3 joined #p6dev
01:47 Topic for #p6dev is now Perl 6 language and compiler development
04:15 geekosaur joined #p6dev
04:15 geekosaur joined #p6dev
04:32 lizmat joined #p6dev
05:57 geekosaur joined #p6dev
06:18 [Tux] test            20.991
06:18 [Tux] test-t          12.432
06:18 [Tux] csv-parser      25.262
07:43 [Tux] first utf8-c8 tests causes segfault
07:45 [Tux] https://gist.github.com/Tux/047f8c52a3f167d14bde3e3da7fc8547
07:49 vendethiel joined #p6dev
08:19 RabidGravy joined #p6dev
09:20 dalek roast: 30db586 | usev6++ | S32-list/permutations.t:
09:20 dalek roast: Add test for RT #127777
09:20 dalek roast: review: https://github.com/perl6/roast/commit/30db58671d
09:20 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127777
09:34 vendethiel joined #p6dev
09:48 dalek roast: a261748 | usev6++ | S02-types/array-shapes.t:
09:48 dalek roast: Add tests for RT #126800
09:48 dalek roast: review: https://github.com/perl6/roast/commit/a2617480f4
09:48 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=126800
09:52 jnthn nine: Expected MAST::Frame but didn't get one is an error from the assembler iirc. It perhaps means that you've got a bogus QAST::BVal node...or at least that'd be my first guess.
09:53 jnthn [Tux]: Please file the thing that now crashes as an RT. I already fixed the utf8-c8 one that was in RT.
09:58 nine jnthn: I posted further findings on #moarvm. Looks like I'm missing an entry in the MASTCompilerInstance's %!mast_frames despite two entries being written for the cuid in question.
09:59 nine jnthn: just for the sake of seeing what happens, I added a workaround to the list_b op skipping the entry in question which got my minimal example to actually compile and run :) So it would seem I'm rather close now.
10:00 jnthn Nice! :)
10:00 jnthn This stuff is probably the trickiest area of the Rakudo/NQP codebase...
10:01 nine Minimal example being precompilation of a BEGIN EVAL "1"; The example that actually runs the EVAL for the DependencySpecification still fails trying to serialize some Lexotic. But progress nevertheless.
10:02 nine Yep, complicated code spread out over all of rakudo, nqp and MoarVM with little support for debugging. I've already added 50 nqp::sayfh(nqp::getstderr(), ...) and probably more to come ;)
10:31 vendethiel joined #p6dev
10:38 dalek roast: 4785228 | usev6++ | S32-list/permutations.t:
10:38 dalek roast: Fix test description
10:38 dalek roast: review: https://github.com/perl6/roast/commit/4785228ca9
10:38 dalek roast: 132d97f | usev6++ | S32-list/combinations.t:
10:38 dalek roast: Add tests for RT #127778
10:38 dalek roast: review: https://github.com/perl6/roast/commit/132d97ffc9
10:38 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127778
10:57 vendethiel joined #p6dev
11:04 |Tux| m: my$b=Buf.new(61,^2048 .map({256.rand.Int}));my Str $u=$b.decode("utf8-c8");$u.=subst(/("a"|"b")/,{"c$0"},:g);
11:05 camelia rakudo-moar 40a953: OUTPUT«(timeout)*** Error in `/home/camelia/rakudo-m-inst-2/bin/moar': corrupted double-linked list: 0x0000000005c5cda0 ***␤»
11:05 |Tux| jnthn, still want me to RT that or is that enough rope for you to hang it?
11:06 |Tux| I either get corrupted messages or a core dump
11:10 jnthn |Tux|: Please RT it; it'll probably be tomorrow or Wed before I can look at it, and I'll likely forget between now and then ;)
11:35 timotimo nine: "note" is available as a sub in nqp and does the same as sayfh(getstderr...)
11:35 timotimo (i was very happy when someone pointed that out to me)
11:40 nine woah!
11:41 nine timotimo: thanks! :)
11:43 timotimo i'm glad you're glad! :)
11:44 |Tux| perl #127878
11:44 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127878
11:58 RabidGravy eugh
11:58 timotimo in re_nfg, where we try to turn a string that got concatenated or something back into NFG form, we end up writing quite a few bytes past the allocated buffer
11:58 timotimo i'm not sure if adding a realloc is the right fix, because i'm not sure why we end up writing more codepoints there
11:58 timotimo but it'd surely mitigate the crash
12:00 timotimo maybe it's about utf8-c8 generating these long strings of "here, this was a b0rked piece of utf8"
12:06 timotimo [Tux]: i pushed a commit to moarvm, can you test your utf8-c8 stuff with it?
12:07 |Tux| yes, I will
12:08 timotimo thanks :)
12:08 timotimo i'll especially be interested if encoding stuff back will restore the original bytes again; i've got a weak suspicion that that might somehow be b0rked
12:09 awwaiid ah, 'note' is handy :)
12:24 dalek nqp: 1201e20 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
12:24 dalek nqp: [js] Avoid declaring useless js variables.
12:24 dalek nqp: review: https://github.com/perl6/nqp/commit/1201e20f35
12:25 |Tux| test            20.690
12:25 |Tux| test-t          11.994
12:25 |Tux| csv-parser      25.149
12:25 |Tux| I still get a segfault though
12:26 |Tux| m: Buf.new(61,^2048 .map({256.rand.Int})).decode("utf8-c8").subst(/"a"/,"c",:g);
12:26 camelia rakudo-moar 40a953: OUTPUT«(timeout)*** Error in `/home/camelia/rakudo-m-inst-2/bin/moar': free(): corrupted unsorted chunks: 0x000000000321c2d0 ***␤*** Error in `/home/camelia/rakudo-m-inst-2/bin/moar': malloc(): memory corruption: 0x000000000405b910 ***␤»
12:27 timotimo oh, huh, let's see.
12:27 timotimo how often do you have to run it to get it to crash with the newest moarvm?
12:27 |Tux| with ^2048 only once :)
12:28 |Tux| with lower values, like ^200 it depends
12:28 timotimo http://t.h8.lv/no_crashes_here.png
12:37 timotimo well, i'm unable to reproduce the problem now :(
12:40 dalek nqp: 15ce590 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
12:40 dalek nqp: [js] More accurate error messages for stranded next/last/redo etc.
12:40 dalek nqp: review: https://github.com/perl6/nqp/commit/15ce59098b
12:45 timotimo oh, there's still an invalid read during utf8-c8 decoding
12:46 timotimo immediately after an ensure_buffer call :\
12:46 vendethiel joined #p6dev
12:49 timotimo ah, because it's an invalid *read*, not an invalid *write*
13:11 timotimo we probably barf when the incoming string ends in a partial valid utf8 sequence? perhaps?
13:12 perlpilot joined #p6dev
13:16 |Tux| 256.rand.Int hints towards randomness :)
13:16 |Tux| I could try to come up with less random reproducable test cases
13:17 timotimo it'd be enough to set a srand(123) at the beginning and figure out a number that'll cause the crash for you
13:18 timotimo i added a "for ^1024" at the end
13:18 timotimo still running
13:18 |Tux| m: srand(123);Buf.new(61,^179 .map({256.rand.Int})).decode("utf8-c8").subst(/"a"/,"c",:g);
13:18 camelia rakudo-moar 40a953: OUTPUT«(signal SEGV)*** Error in `/home/camelia/rakudo-m-inst-2/bin/moar': free(): invalid size: 0x00000000046af0a0 ***␤»
13:21 timotimo i'm betting camelia doesn't have the current moarvm version
13:21 |Tux| for ^200 {
13:21 |Tux| srand(123);
13:21 |Tux| .say;
13:21 |Tux| Buf.new(61,(^$_).map({256.rand.Int})).decode("utf8-c8").subst(/"a"/,"c",:g);
13:21 |Tux| }
13:21 timotimo doesn't crash locally
13:21 |Tux| that crashes at different points
13:22 |Tux| This is Rakudo version 2016.03-113-g37857b2 built on MoarVM version 2016.03-104-g10d3971
13:22 dalek roast: f90f4e3 | usev6++ | S02-types/whatever.t:
13:22 dalek roast: Add test for RT #127408
13:22 dalek roast: review: https://github.com/perl6/roast/commit/f90f4e371b
13:22 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127408
13:22 |Tux| that is the most recent, right?
13:22 timotimo that doesn't have my fix
13:22 |Tux| damn
13:22 timotimo This is MoarVM version 2016.03-105-g808fd05 built with JIT support
13:22 timotimo is what i have
13:23 * |Tux| rebuilds again
13:23 timotimo something's strange, i've got 105, but i have two commits that you don't have, but you have 104
13:24 |Tux| maybe I pulled a microsecond too soon
13:25 timotimo could be
13:29 |Tux| re-pull'ed, re-built. still -104
13:31 timotimo :o
13:31 |Tux| http://tux.nl/Files/20160411153124.png
13:32 timotimo well, the fix was in moarvm, not in rakudo
13:33 timotimo did you build moar from master or from MOAR_REVISION?
13:33 |Tux| moar-nom 524 > git co master
13:33 |Tux| error: pathspec 'master' did not match any file(s) known to git.
13:33 |Tux| I have the nom branch checked out
13:33 timotimo *moar* from master, not rakudo
13:34 [Coke] "moar", not "rakudo"
13:34 timotimo nom is a rakudo branch
13:34 * |Tux| feels unaware: I only have rakudo, and rakudo has moar-nom
13:34 |Tux| that is what I used all these years
13:35 timotimo ah, so you're not cd-ing into the MoarVM folder and git pulling manually?
13:35 |Tux| my build procudure digs into all rakudo folders that have a .git folder and executes a git pull on each
13:35 timotimo oh, interesting
13:36 timotimo and how do you build?
13:36 |Tux| $ make
13:36 timotimo it could very well be it pulled the newest code from moarvm, but didn't rebuild moarvm
13:36 timotimo is that a custom makefile you've got? because otherwise it won't pull in newer versions of nqp and moar at all
13:36 |Tux| http://tux.nl/Files/20160411153634.png
13:36 |Tux| you mean that one
13:36 timotimo aye
13:37 timotimo you have the right commits there. now you just have to make sure it also gets built
13:37 timotimo you ought to see some lines like "compiling src/blahblah/foobar.o"
13:37 |Tux| I'll start afresh. have a few moments (it'll take a bit)
13:37 timotimo about a hundred or so of these
13:46 |Tux| Inline::Perl5 is still a no-go on -Duselongdouble perl5
13:46 * timotimo knows nothing about Inline::Perl5 :(
13:47 |Tux| This is Rakudo version 2016.03-113-g37857b2 built on MoarVM version 2016.03-104-g10d3971
13:48 timotimo why is that still at 104? :(
13:49 timotimo do you use --gen-nqp or --gen-moar or something?
13:49 |Tux| maybe a flaw in rakudo merging MoarVM ?
13:49 timotimo if so, you can use --gen-moar=master
13:49 timotimo rakudo doesn't merge moarvm
13:49 timotimo the only thing there is is NQP_REVISION in rakudo that'll cause Configure.pl to complain when nqp is too old and MOAR_REVISION in nqp which does the same kind of thing
13:49 |Tux| rakudobrew pulls git_reference, otherwise I would not have had that
13:50 RabidGravy joined #p6dev
13:50 timotimo i didn't bump the revisions yet, because i didn't know if the fix was proper, and i didn't want to spam rakudo and nqp repository with "bump revisions" commits over and over again
13:50 |Tux| can someone then tell me how to use moar from git_reference in my rakodo-env?
13:51 timotimo i have no idea what git_reference means :|
13:51 |Tux| I am really sorry to be such a nuisance right now
13:51 timotimo don't worry about it
13:51 timotimo you can get rakudobrew to give you the latest of everything with "rakudobrew triple nom master master"
13:51 timotimo maybe that is what we need right now
13:51 perlpilot |Tux|: you mean as in "perl Configure.pl --backends=moar --gen-moar=SHA1"  ?
13:51 timotimo it's only a nuisance because i wasn't aware what your local setup looks like :)
13:52 timotimo doesn't need to be a sha1, can also be "master" in there
13:52 perlpilot right
13:52 perlpilot any commitish actually
13:53 nine timotimo: -Duselongdouble means 80 bit doubles which MoarVM doesn't support yet, so we can't even use them in NativeCall.
13:53 timotimo oh
13:53 timotimo i don't even know how to work with those in C
13:54 timotimo is there language support in C or do you work those with inline assembler?
13:58 |Tux| in i; long double d;
13:58 |Tux| int i; long double d;
14:02 geekosaur hm, aren't you conflating things there? long double is 128-bit. 80 is the Intel internal precision thing for 64-bit floats and I don't think they provide a way to get full significance there
14:03 teatime I think it's compiler-dependent
14:03 geekosaur that is, FP regs have 80 bits but memory load/store chops at 64
14:03 |Tux| This is perl 5, version 22, subversion 0 (v5.22.0) built for x86_64-linux-thread-multi-ld
14:03 |Tux| nvsize='16';
14:03 |Tux| longdblsize='16';
14:03 |Tux| longlongsize='8';
14:05 |Tux| perlpilot, that didn't help
14:05 |Tux| perl Configure.pl --backends=moar --gen-moar=master;make;./perl6 --version
14:05 |Tux| This is Rakudo version 2016.03-113-g37857b2 built on MoarVM version 2016.03-104-g10d3971
14:05 |Tux| implementing Perl 6.c.
14:06 timotimo o_O
14:09 nine geekosaur: long double is 80 bits extended precision floating point type with a typical storage size of 128 bits. https://en.wikipedia.org/wiki/Long_double
14:09 nine usually at least
14:11 bartolin |Tux|: did you try: (cd nqp/MoarVM/; make; make install)
15:52 lucasb joined #p6dev
15:52 lucasb hello
15:53 lucasb I thought ticket #127869 was interesting, and I tried to golf it...
15:53 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127869
15:54 lucasb I arrived at this:
15:54 lucasb m: for ^1000 -> $i { for 1,2,3 { if my $x = ($_ == 2 ?? Nil !! False) { die "$i $x" unless $x } } }
15:54 camelia rakudo-moar 40a953: OUTPUT«69 False␤  in block  at /tmp/9NTyNXxBA7 line 1␤  in block <unit> at /tmp/9NTyNXxBA7 line 1␤␤»
15:54 lucasb Maybe it can be made even shorter :)
15:55 timotimo uh oh, spesh bug?
15:55 lucasb exactly :)
15:55 lucasb with MVM_SPESH_DISABLE=0, it doesn't happen
15:56 lucasb if I change 'for 1,2,3' to 'for 1,2', the iteration number where the error happens also change
15:56 lucasb m: for ^1000 -> $i { for 1,2 { if my $x = ($_ == 2 ?? Nil !! False) { die "$i $x" unless $x } } }
15:56 camelia rakudo-moar 40a953: OUTPUT«104 False␤  in block  at /tmp/_V8aHqiwmu line 1␤  in block <unit> at /tmp/_V8aHqiwmu line 1␤␤»
15:57 * [Coke] wonders if MVM_SPESH_DISABLE is only checked when rakudo starts up, or if you can put it inside a block! ;)
15:57 timotimo only checked at startup
16:04 vendethiel joined #p6dev
17:33 vendethiel joined #p6dev
17:34 hankache joined #p6dev
17:55 sortiz joined #p6dev
18:06 hankache_ joined #p6dev
19:21 hankache joined #p6dev
20:41 b2gills joined #p6dev
20:43 nine Ah ha! We _are_ storing MVMFrames into %!mast_frames for the cuid in question. It's just different %!mast_frames as it's a different MASTCompilerInstance!
20:43 timotimo oooooh
20:43 nine It's ye olde 1:1 relation between compilation unit and byte code file assumption again.
20:44 nine So it seems like I should try to share the MASTCompilerInstance between the EVAL's and the outer comp_unit. Or at least those frames.
20:44 nine The latter probably being the easier course of action. At least for a first try.
20:45 jnthn nine: ummmmmm
20:45 nine Note that I've been spectacularily wrong on those decisions up to now :)
20:45 jnthn I'm very doubtful sharing MAST::CompUnit is going to go too well...
20:46 nine Sounds like I really should give just copying %!mast_frames to the outer compiler instance a try.
20:46 jnthn Or put another way
20:46 jnthn You can smudge the definition of comp unit a bit up at Rakudo level
20:46 jnthn But you can't really do that at VM level
20:47 jnthn A given QAST block will, if invoked at compile time, end up being compiled twice or more
20:48 jnthn Well, twice anyways.
20:48 jnthn Not sure it can happen more
20:48 jnthn And it may not be the same QAST the second time
20:48 jnthn 'cus the optimizer will have had a pass over it
20:48 nine I wonder, if my whole approach is just wrong. Isn't a compile time EVAL pretty much exactly like a BEGIN block itself? The compiler encounters the code and immediatly has to compile and run it, yet it's still part of the outer comp_unit
20:59 jnthn nine: Not really, in that EVAL is always treated as a compilation unit of its own so far.
21:00 jnthn nine: I wonder if it's easier to simply "let it be" and approach it as a kind of "merge"
21:00 jnthn Since the sharing approach seems to be more fraught than I'd imagined...
21:04 dalek roast: 92543e1 | usev6++ | S09-hashes/objecthash.t:
21:04 dalek roast: Add test for RT #111498
21:04 dalek roast: review: https://github.com/perl6/roast/commit/92543e196c
21:04 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=111498
21:17 lizmat joined #p6dev
22:02 dalek rakudo/nom: e96d2fa | bartolin++ | README.md:
22:02 dalek rakudo/nom: Remove section "How the compiler works"
22:02 dalek rakudo/nom:
22:02 dalek rakudo/nom: As noted in https://rt.perl.org/Ticket/Display.html?id=127580 the information in 'docs/compiler_overview.pod' is outdated. The README should not reference that file (at least until it's updated).
22:02 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e96d2faf95
22:02 dalek rakudo/nom: a10a468 | bartolin++ | docs/compiler_overview.pod:
22:02 dalek rakudo/nom: Add note that parts of this overview are outdated
22:02 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a10a468d95
22:02 dalek rakudo/nom: d1eeb38 | lizmat++ | / (2 files):
22:02 dalek rakudo/nom: Merge pull request #740 from usev6/patch-1
22:02 dalek rakudo/nom:
22:02 dalek rakudo/nom: Remove section "How the compiler works"

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