00:31 sortiz joined 01:47 ilbot3 joined 04:15 geekosaur joined 04:32 lizmat joined 05:57 geekosaur joined
[Tux] test 20.991 06:18
test-t 12.432
csv-parser 25.262
first utf8-c8 tests causes segfault 07:43
gist.github.com/Tux/047f8c52a3f167...3da7fc8547 07:45
07:49 vendethiel joined 08:19 RabidGravy joined
dalek ast: 30db586 | usev6++ | S32-list/permutations.t:
Add test for RT #127777
 09:20
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127777
09:34 vendethiel joined
dalek ast: a261748 | usev6++ | S02-types/array-shapes.t:
Add tests for RT #126800
 09:48
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126800
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:52
[Tux]: Please file the thing that now crashes as an RT. I already fixed the utf8-c8 one that was in RT. 09:53
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:58
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. 09:59
jnthn Nice! :) 10:00
This stuff is probably the trickiest area of the Rakudo/NQP codebase...
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:01
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:02
10:31 vendethiel joined
dalek ast: 4785228 | usev6++ | S32-list/permutations.t:
Fix test description
 10:38
ast: 132d97f | usev6++ | S32-list/combinations.t:
Add tests for RT #127778
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127778
10:57 vendethiel joined
|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:04
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?
I either get corrupted messages or a core dump 11:06
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:10
timotimo nine: "note" is available as a sub in nqp and does the same as sayfh(getstderr...) 11:35
(i was very happy when someone pointed that out to me)
nine woah! 11:40
timotimo: thanks! :) 11:41
timotimo i'm glad you're glad! :) 11:43
|Tux| perl #127878 11:44
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127878
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
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
but it'd surely mitigate the crash
maybe it's about utf8-c8 generating these long strings of "here, this was a b0rked piece of utf8" 12:00
[Tux]: i pushed a commit to moarvm, can you test your utf8-c8 stuff with it? 12:06
|Tux| yes, I will 12:07
timotimo thanks :) 12:08
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
awwaiid ah, 'note' is handy :) 12:09
dalek p: 1201e20 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Avoid declaring useless js variables.
 12:24
|Tux| test 20.690 12:25
test-t 11.994
csv-parser 25.149
I still get a segfault though
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 ***ā¤Ā»
timotimo oh, huh, let's see. 12:27
how often do you have to run it to get it to crash with the newest moarvm?
|Tux| with ^2048 only once :)
with lower values, like ^200 it depends 12:28
timotimo t.h8.lv/no_crashes_here.png
well, i'm unable to reproduce the problem now :( 12:37
dalek p: 15ce590 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] More accurate error messages for stranded next/last/redo etc.
 12:40
timotimo oh, there's still an invalid read during utf8-c8 decoding 12:45
immediately after an ensure_buffer call :\ 12:46
12:46 vendethiel joined
timotimo ah, because it's an invalid *read*, not an invalid *write* 12:49
we probably barf when the incoming string ends in a partial valid utf8 sequence? perhaps? 13:11
13:12 perlpilot joined
|Tux| 256.rand.Int hints towards randomness :) 13:16
I could try to come up with less random reproducable test cases
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:17
i added a "for ^1024" at the end 13:18
still running
|Tux| m: srand(123);Buf.new(61,^179 .map({256.rand.Int})).decode("utf8-c8").subst(/"a"/,"c",:g);
camelia rakudo-moar 40a953: OUTPUTĀ«(signal SEGV)*** Error in `/home/camelia/rakudo-m-inst-2/bin/moar': free(): invalid size: 0x00000000046af0a0 ***ā¤Ā»
timotimo i'm betting camelia doesn't have the current moarvm version 13:21
|Tux| for ^200 {
srand(123);
.say;
Buf.new(61,(^$_).map({256.rand.Int})).decode("utf8-c8").subst(/"a"/,"c",:g);
}
timotimo doesn't crash locally
|Tux| that crashes at different points
This is Rakudo version 2016.03-113-g37857b2 built on MoarVM version 2016.03-104-g10d3971 13:22
dalek ast: f90f4e3 | usev6++ | S02-types/whatever.t:
Add test for RT #127408
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127408
|Tux| that is the most recent, right?
timotimo that doesn't have my fix
|Tux| damn
timotimo This is MoarVM version 2016.03-105-g808fd05 built with JIT support
is what i have
|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
|Tux| maybe I pulled a microsecond too soon 13:24
timotimo could be 13:25
|Tux| re-pull'ed, re-built. still -104 13:29
timotimo :o 13:31
|Tux| tux.nl/Files/20160411153124.png
timotimo well, the fix was in moarvm, not in rakudo 13:32
did you build moar from master or from MOAR_REVISION? 13:33
|Tux| moar-nom 524 > git co master
error: pathspec 'master' did not match any file(s) known to git.
I have the nom branch checked out
timotimo *moar* from master, not rakudo
[Coke] "moar", not "rakudo" 13:34
timotimo nom is a rakudo branch
|Tux| feels unaware: I only have rakudo, and rakudo has moar-nom
that is what I used all these years
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
timotimo oh, interesting
and how do you build? 13:36
|Tux| $ make
timotimo it could very well be it pulled the newest code from moarvm, but didn't rebuild moarvm
is that a custom makefile you've got? because otherwise it won't pull in newer versions of nqp and moar at all
|Tux| tux.nl/Files/20160411153634.png
you mean that one
timotimo aye
you have the right commits there. now you just have to make sure it also gets built 13:37
you ought to see some lines like "compiling src/blahblah/foobar.o"
|Tux| I'll start afresh. have a few moments (it'll take a bit)
timotimo about a hundred or so of these
|Tux| Inline::Perl5 is still a no-go on -Duselongdouble perl5 13:46
timotimo knows nothing about Inline::Perl5 :(
|Tux| This is Rakudo version 2016.03-113-g37857b2 built on MoarVM version 2016.03-104-g10d3971 13:47
timotimo why is that still at 104? :( 13:48
do you use --gen-nqp or --gen-moar or something? 13:49
|Tux| maybe a flaw in rakudo merging MoarVM ?
timotimo if so, you can use --gen-moar=master
rakudo doesn't merge moarvm
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
|Tux| rakudobrew pulls git_reference, otherwise I would not have had that
13:50 RabidGravy joined
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?
timotimo i have no idea what git_reference means :| 13:51
|Tux| I am really sorry to be such a nuisance right now
timotimo don't worry about it
you can get rakudobrew to give you the latest of everything with "rakudobrew triple nom master master"
maybe that is what we need right now
perlpilot |Tux|: you mean as in "perl Configure.pl --backends=moar --gen-moar=SHA1" ?
timotimo it's only a nuisance because i wasn't aware what your local setup looks like :)
doesn't need to be a sha1, can also be "master" in there 13:52
perlpilot right
any commitish actually
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
i don't even know how to work with those in C
is there language support in C or do you work those with inline assembler? 13:54
|Tux| in i; long double d; 13:58
int i; long double d;
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:02
teatime I think it's compiler-dependent 14:03
geekosaur that is, FP regs have 80 bits but memory load/store chops at 64
|Tux| This is perl 5, version 22, subversion 0 (v5.22.0) built for x86_64-linux-thread-multi-ld
nvsize='16';
longdblsize='16';
longlongsize='8';
perlpilot, that didn't help 14:05
perl Configure.pl --backends=moar --gen-moar=master;make;./perl6 --version
This is Rakudo version 2016.03-113-g37857b2 built on MoarVM version 2016.03-104-g10d3971
implementing Perl 6.c.
timotimo o_O 14:06
nine geekosaur: long double is 80 bits extended precision floating point type with a typical storage size of 128 bits. en.wikipedia.org/wiki/Long_double 14:09
usually at least
bartolin |Tux|: did you try: (cd nqp/MoarVM/; make; make install) 14:11
15:52 lucasb joined
lucasb hello 15:52
I thought ticket #127869 was interesting, and I tried to golf it... 15:53
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127869
lucasb I arrived at this: 15:54
m: for ^1000 -> $i { for 1,2,3 { if my $x = ($_ == 2 ?? Nil !! False) { die "$i $x" unless $x } } }
camelia rakudo-moar 40a953: OUTPUTĀ«69 Falseā¤ in block at /tmp/9NTyNXxBA7 line 1ā¤ in block <unit> at /tmp/9NTyNXxBA7 line 1ā¤ā¤Ā»
lucasb Maybe it can be made even shorter :)
timotimo uh oh, spesh bug? 15:55
lucasb exactly :)
with MVM_SPESH_DISABLE=0, it doesn't happen
if I change 'for 1,2,3' to 'for 1,2', the iteration number where the error happens also change 15:56
m: for ^1000 -> $i { for 1,2 { if my $x = ($_ == 2 ?? Nil !! False) { die "$i $x" unless $x } } }
camelia rakudo-moar 40a953: OUTPUTĀ«104 Falseā¤ in block at /tmp/_V8aHqiwmu line 1ā¤ in block <unit> at /tmp/_V8aHqiwmu line 1ā¤ā¤Ā»
[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 17:33 vendethiel joined 17:34 hankache joined 17:55 sortiz joined 18:06 hankache_ joined 19:21 hankache joined 20:41 b2gills joined
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
nine It's ye olde 1:1 relation between compilation unit and byte code file assumption again.
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
The latter probably being the easier course of action. At least for a first try.
jnthn nine: ummmmmm 20:45
nine Note that I've been spectacularily wrong on those decisions up to now :)
jnthn I'm very doubtful sharing MAST::CompUnit is going to go too well...
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
You can smudge the definition of comp unit a bit up at Rakudo level
But you can't really do that at VM level
A given QAST block will, if invoked at compile time, end up being compiled twice or more 20:47
Well, twice anyways. 20:48
Not sure it can happen more
And it may not be the same QAST the second time
'cus the optimizer will have had a pass over it
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
jnthn nine: Not really, in that EVAL is always treated as a compilation unit of its own so far. 20:59
nine: I wonder if it's easier to simply "let it be" and approach it as a kind of "merge" 21:00
Since the sharing approach seems to be more fraught than I'd imagined...
dalek ast: 92543e1 | usev6++ | S09-hashes/objecthash.t:
Add test for RT #111498
 21:04
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=111498
21:17 lizmat joined
dalek kudo/nom: e96d2fa | bartolin++ | README.md:
Remove section "How the compiler works"

As noted in 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
kudo/nom: a10a468 | bartolin++ | docs/compiler_overview.pod:
Add note that parts of this overview are outdated
rakudo/nom: d1eeb38 | lizmat++ | / (2 files):
rakudo/nom: Merge pull request #740 from usev6/patch-1
rakudo/nom:
rakudo/nom: Remove section "How the compiler works"

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!