01:47 ilbot3 joined
teatime github.com/rakudo/rakudo/compare/n...ration1-r1 03:11
github.com/perl6/roast/compare/mas...ration1-r1
^^ my future/soon PR. feedback welcome; still needs work. IIRC the commit messages demo the rationale decently; mainly the goal is to fix RT #127339, and bring Duration closer to the spec in S02 (which is vaguely contradictory at times :) 03:12
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127339
teatime pls ping me w/ changes / stuff I am doing wrong, or if you think I should open the PR ticket. 03:13
06:50 geekosaur joined
jnthn morning, #p6dev 07:41
moritz \o
teatime o/
moritz jnthn: I don't know if you saw it yesterday in #perl6, but I'd propose for v6.d that we make block parameters default to Any, not Mu (only the default, not the type constraint) 07:42
jnthn: do you think that's sensible? 07:43
m: (-> $x? { say $x.^name })()
camelia rakudo-moar d1eeb3: OUTPUTĀ«Muā¤Ā»
jnthn Hm, maybe. Why, ooc? 07:44
It seems something we can do by lang version though
So technically it's probably unproblematic
Something to do with auto-viv, or?
moritz jnthn: no, it's for passing on the optional parameter to a routine 07:45
which defaults to Any as a type constraint 07:46
m: sub f($x?) { say $x.perl }; (-> $x? { f($x) })()
camelia rakudo-moar d1eeb3: OUTPUTĀ«Type check failed in binding $x; expected Any but got Mu (Mu)ā¤ in sub f at /tmp/LIwgjxzO9_ line 1ā¤ in block <unit> at /tmp/LIwgjxzO9_ line 1ā¤ā¤Ā»
moritz that would Just Work[tm] if the default was Any
jnthn Aha 07:58
Yeah, it seems reasonable at first glance
moritz: On rt.perl.org/Ticket/Display.html?id=127878 did you write a test in the end? :) 07:59
moritz jnthn: yes, but I didn't push it, because it turns out that the nqp/moar versions weren't bumped yet
jnthn: ... and I didn't fancy pushing a coredumping test :-) 08:00
... and I was too lazy to bump the versions myself
jnthn Or fudge it? ;-) 08:01
Anyway, looking at the commits that fixed it now
moritz of that, yes
anyway, ill push tonight, one way or another 08:02
*will
and it's good to see that the test does fail with the old version :-)
jnthn aye :)
08:12 RabidGravy joined 09:41 bartolin_ joined 09:44 stmuk joined 09:53 ugexe joined 10:32 stmuk joined 10:39 b2gills joined 11:36 vendethiel joined 11:38 lucs joined 11:43 psch joined
|Tux| rakudobrew perl still at 104 :( 12:21
12:23 lizmat joined
jnthn |Tux|: You're waiting on Moar/NQP revision bumps? 12:23
|Tux| as I said yesterday: I have no idea how perl6 core changes end up in rakudowbrew or (better question) how I can tell rakudobrew to use the bleadiest edge available 12:24
jnthn doesn't use rakudobrew so can't help with that, sorry 12:25
|Tux| if rakudobrew doesn't change, my timings have way less usage and only show the influence of the moon and the butterflies
jnthn I thought that it just pulled latest Rakudo? 12:26
And then used by default the NQP/Moar that were declared as current dependencies
|Tux| that was my impression too, but perl6 --version still shows
This is Rakudo version 2016.03-116-gd1eeb38 built on MoarVM version 2016.03-104-g10d3971
implementing Perl 6.c.
test 20.675
test-t 11.950
csv-parser 24.746
jnthn 2016.03-116-gd1eeb38 is latest Rakudo 12:27
|Tux| and that is what I want to see too
so I can play with utf8-c8 as timotimo fixed it
jnthn I dunno if you can tell it to ignore Rakudo's desired NQP/Moar versions and grab bleading edge of those too 12:28
|Tux| lizmat? (the latest commit in nom was by lizmat, so she might know)
jnthn Anyway, if you just want the latest MoarVM then a way to get it is to cd to wherever rakudobrew checked out MoarVM too, and inside there just git pull && make install 12:29
s/too/so/ 12:30
|Tux| If I build from MoarVM and install: 12:39
This is MoarVM version 2016.03-108-gca1a21a built with JIT support
but that doesn't support -I. -Ilib 12:40
jnthn ...what?
|Tux| perl6 -I. -Ilib test-t.pl 12:41
ERROR: Unknown flag -I..
tux.nl/Files/20160413144116.png
jnthn What on earth, that looks almost as if your perl6 symbol is pointing directly at the moar executable, but I've no idea how that can happen 12:42
|Tux| it is. /me investigates where that goes wrong 12:43
lizmat [Tux] : fwiw, I'm not using rakudobrew either
|Tux| this approach is new to me, so it is likely *I* made the error
jnthn |Tux|: Did you build a separate Moar, or did you do what I suggested and tinker in-place with the rakudobrew managed one? :) 12:44
|Tux| the first: cd git_reference/MoarVM; perl Configure.pl --prefix=/pro/3gl/rakudobrew ; make -j8 ; make install
I'll try now: cd git_reference/MoarVM; perl Configure.pl --prefix=/pro/3gl/rakudobrew/moar-nom/install ; make -j8 ; make install 12:45
[Coke] I would not manually install your copy into rakudobrew. 12:59
I'd just have a location where you can manage your own copy
jnthn [Coke]: Yeah, my point was that he already had a copy, and so updating the repo to latest and a `make install` would do it since there's nothing that needs a Moar re-configure :) 13:00
My "you can get away with X" solutions don't really scale to people thinking and trying to do the right thing. :)
[Coke] I would also point out that you may end up breaking yourself if you're doing nom/master/master - that trio doesn't always work. 13:01
jnthn [Coke]: Don't suppose you know how to force that to happen with rakudobrew, though? 13:02
[Coke] I don't use rakudobrew. :)
jnthn By this point I might as well have just bumped the various revisions :P
Screw it, I'll do that 13:03
[Coke] if you want it in this weekend's release, yes, please.
gives us a few days to kick the tires.
dalek p: a525da3 | jnthn++ | tools/build/MOAR_REVISION:
Get latest MoarVM.

With utf8-c8 and crash fixes.
13:04
kudo/nom: ae2ae92 | jnthn++ | tools/build/NQP_REVISION:
Bump NQP_REVISION.

To get a MoarVM with fixes for the UTF8-C8 encoding and a couple of other crashes.
13:06
jnthn |Tux|: You can just do a latest rakudobrew build now
|Tux| building ā€¦
jnthn [Coke]: Yeah. The next thing I'm working on is fairly major, so will happen in a (MoarVM) branch. 13:07
[Coke] jnthn: danke.
jnthn So I don't have anything else to land this side of release.
|Tux| This is Rakudo version 2016.03-117-gae2ae92 built on MoarVM version 2016.03-108-gca1a21a 13:12
test 21.526 13:16
test-t 12.431
csv-parser 25.762
I get a new error :) - something to dig into! 13:17
is($a,$b,"..."); does not seem to accept Buf 13:23
m: use Test;my $b=Buf.new(61,^2048 .map({256.rand.Int}));my Str $u=$b.decode("utf8-c8");is($b,$u.encode("utf8-c8"),"")
camelia rakudo-moar ae2ae9: OUTPUTĀ«not ok 1 - ā¤ā¤# Failed test at /tmp/u6v9lI0uJX line 1ā¤Cannot use a Buf as a string, but you called the Stringy method on itā¤ in block at /home/camelia/rakudo-m-inst-1/share/perl6/sources/C712FE6969F786C9380D643DF17E85D06868219E (Test) line 145ā¤ ā€¦Ā»
jnthn yeah, is relies on doing string comparison, I think. Use is-deeply instead 13:25
|Tux| *intresting* 13:28
# at 43_binary.t line 23
# expected: "=\x[13]ōæ½xA5Ł¾ōæ½x8ARōæ½x87ōæ½xB4ōæ½x8Erōæ½xE929*ōæ½xAAōæ½xC9/uaōæ½x83"
# got: "=\x[13]ōæ½xA5Ł¾ōæ½x8ARōæ½x87ōæ½xB4ōæ½x8Erōæ½xE929*ōæ½xAAōæ½xC9/uaōæ½x83"
jnthn is failing to spot the difference... 13:31
|Tux| so am I
but it might stem in this:
# at 43_binary.t line 24
# expected: Buf.new(61,165,72,180,71,202,104,86,252,158,233,35,78,224,158,82,18,1,42,185,78)
# got: Blob[uint8].new(61,165,72,180,71,202,104,86,252,158,233,35,78,224,158,82,18,1,42,185,78)
my Buf $b = Buf.new(...); my Str $s = $b.decode("utf8-c8"); my Buf $x = $s.encode("utf8-c8"); 13:34
not?
moritz oh, different type 13:37
can't you just do is-depploy $got.list, $expected.list ? 13:38
I wouldn't want to make it dependent on the actual return type, because something more specific is always OK
|Tux| for my understanding ... 13:57
my Buf $b = Buf.new (...)
my Str $s = $b.decode("utf8-c8"); 13:58
my @f = $s.encode("utf8-c8").list;
my Buf $c = Buf.new(@f); 13:59
now $c should be equal to $b, right?
or should I move this to #perl6
jnthn I'd expect them to contain the same bytes, yeah 14:00
|Tux| the answer seems to be no :(
|Tux| experiment further
14:20 teatime joined
|Tux| gist.github.com/Tux/eac2f0f8c380a8...8617de5204 <= random failures (reproducable) 14:26
does that help?
jnthn |Tux|: Yes, if it reproduces the problem 14:27
timotimo: ^^ if you're about and fancy some more hunting :)
|Tux| thank both of you for enabling me to test even deeper :] 14:31
timotimo that could very well be that invalid read off the end of the input buffer 14:34
hm, the difference is that the "got" one is one byte longer, and that byte is 127 14:36
no, the byte is not deterministic
teatime bah, I wonder how long my client was in a disconnect loop 14:37
timotimo gist.github.com/timo/a4090024c8e59...d34576c47f - need i say more? :P 14:38
jnthn valgrind++ :) 14:40
timotimo the interesting thing is it only outputs that blurb once even though multiple runs of the test fail, but perhaps valgrind deduplicates reports that are 1:1 14:41
15:34 dogbert17 joined 15:47 geekosaur joined 15:49 geekosaur joined 15:51 ugexe joined 16:49 pyrimidine joined 16:52 hankache joined 17:27 lizmat joined 18:41 stmuk joined, lucs joined
dalek ast: 28274ef | moritz++ | integration/weird-errors.t:
RT #127878: Can decode and work with interesting byte sequence
18:42
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127878
19:25 sortiz joined 19:48 bartolin_ joined, jnthn joined 20:09 bartolin_ joined, jnthn joined 20:17 jnthn joined, bartolin joined 20:42 lucs_ joined 20:50 PerlJam joined
dalek kudo/nom: 4f3f1c8 | PerlJam++ | docs/release_guide.pod:
Mention other nick since I'm using it often
21:23
p: c86b601 | PerlJam++ | docs/release_guide.pod:
Mention other nick since I'm using it often
21:25
21:42 bartolin joined 21:49 lucs joined 22:11 bartolin joined