dalek kudo/nom: a09c8dc | (Zoffix Znet)++ | src/core/Mix (2 files):
Make Mix/MixHash.Bag/BagHash .Int not .round

Per discussion[^1] with lizmat++ and TimToady++, the .Int is more correct here. Also, it is 4.8 times faster... Yey performance gains \o/
  [1] irclog.perlgeek.de/perl6-dev/2016-...i_13399264		 00:05
ast: 887a35f | (Zoffix Znet)++ | S02-types/mix (2 files):
Correct Mix/MixHash.Bag/BagHash test

The correct behaviour is for weights to be .Inted, not .rounded. The test was added today, as part of coverage work and after a discussion[^1], the behaviour has been amended[^2].
  [1] irclog.perlgeek.de/perl6-dev/2016-...i_13399264
  [2] github.com/rakudo/rakudo/commit/a09c8dc99e		 00:06
Zoffix What does this bit do? It seems to fetch an attribute and set it right back in: github.com/rakudo/rakudo/blob/nom/...pm#L72-L74 00:47
geekosaur decontainerizes all of them in one go 00:48
after setting %!elems to the raw elems passed in, which might include containers
Zoffix OK. Thanks.
Hm. Found a strange bug in core that I can't reproduce. 01:24
m: Bag.new-from-pairs: 1 => -1; 01:25
camelia rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤ in block <unit> at <tmp> line 1␤Use of Nil in string context␤ in block <unit> at <tmp> line 1␤Found negative values for in ␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> l…»
Zoffix Those Nils? It's the two interpolated blocks on this line: github.com/rakudo/rakudo/blob/nom/...ggy.pm#L48
If I change it to this: my $wat = @toolow.join: ' '; my $name = self.^name; fail "Found negative values for $wat in $name" if @toolow; then the bug goes away.
m: role Foo { method !meow { my @meows = <foo bar ber>; fail "some {@meows}" if @meows; }; method moo { self!meow; 42 } }; class :: does Foo {}.moo
camelia rakudo-moar a09c8d: OUTPUT«some foo bar ber␤ in method meow at <tmp> line 1␤ in method moo at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in method moo at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
Zoffix But can't reproduce it ^ :/ 01:26
MasterDuke committable6: releases Bag.new-from-pairs: 1 => -1
Zoffix It'll be muddied up by Baggy reorganization 01:27
MasterDuke uh oh, it ran into a bad tar file anyway 01:28
Zoffix Rakudobugged: rt.perl.org/Ticket/Display.html?id=129874 01:32
m: role Foo { method !meow (-->Nil) { my @meows = <foo bar ber>; fail "some {@meows}" if @meows; }; method moo { self!meow; 42 } }; class :: does Foo {}.moo 01:35
camelia rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤ in method meow at <tmp> line 1␤some ␤ in method meow at <tmp> line 1␤ in method moo at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in method moo at <tmp> line 1␤ in block <unit> …»
Zoffix haw
m: sub (-->Nil) { fail "{42}"; }() 01:36
camelia rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤ in sub at <tmp> line 1␤␤ in sub at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
Zoffix m: sub (-->Nil) { say "wat {42} heh"; }() 01:38
camelia rakudo-moar a09c8d: OUTPUT«Use of Nil in string context␤ in sub at <tmp> line 1␤wat heh␤»
Zoffix m: sub () { say "wat {42} heh"; }()
camelia rakudo-moar a09c8d: OUTPUT«wat 42 heh␤»
Zoffix trippy
MasterDuke damn weird
geekosaur mm? should produce the last value, which will be 1 01:41
Zoffix Huh?
geekosaur m: dd (sub () { say "wat {42} heh"; })()
camelia rakudo-moar a09c8d: OUTPUT«wat 42 heh␤Bool::True␤»
geekosaur oh, True, sorry
return value of say, which will be success/failure of the write on stdouyt
Zoffix Yeah, but I'm not outputting that value. 01:42
I'm trying to `say` a string inside a sub that has an interpolated block and that block is affected. 01:46
geekosaur right, but without the --> Nil you are producing the result of that say, which is Bool
Zoffix doesn't get the relevance
It doesn't get returned from a sub with -->Nil in it
m: dd sub (-->Nil) { 'whatever' }()
camelia rakudo-moar a09c8d: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant string "whatever" in sink context (line 1)␤Nil␤»
Zoffix m: sub () { say "wat {42} heh"; 42 }()
camelia rakudo-moar a09c8d: OUTPUT«wat 42 heh␤»
geekosaur looks to me like you were trying to tell why it was behaving differently between the two
Zoffix m: sub (-->Nil) { say "wat {42} heh"; 42 }()
camelia rakudo-moar a09c8d: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant integer 42 in sink context (line 1)␤Use of Nil in string context␤ in sub at <tmp> line 1␤wat heh␤»
Zoffix geekosaur, yes, I am.
geekosaur, it's a bug.
The string that should not be affected is affected by the sub's return constraint.
geekosaur is not seeing that here
Zoffix The say should output "wat 42 heh", but it outputs "wat heh" (along with a Nil warning)
geekosaur ... finally spots the {} vs. (). sorry
MasterDuke .tell psch you seem to know a bit about the JVM implementation, any suggestions for how to tackle the BOOTSTRAPATTR -> Attribute problem i've been working on? 02:17
yoleaux2 MasterDuke: I'll pass your message to psch.
MasterDuke .tell pmurias you seem to know a bit about the JVM implementation, any suggestions for how to tackle the BOOTSTRAPATTR -> Attribute problem i've been working on?
yoleaux2 MasterDuke: I'll pass your message to pmurias.
AlexDaniel committable6: releases Bag.new-from-pairs: 1 => -1 02:42
committable6 AlexDaniel, gist.github.com/1f32141e3ac0a2dbc4...ad4a903990 02:43
AlexDaniel MasterDuke: “Found negative values for in” /o\ 02:44
travis-ci Rakudo build failed. Zoffix Znet 'Revert "Convert some BOOTSTRAPATTRs to Attributes" 05:23
travis-ci.org/rakudo/rakudo/builds/167363851 github.com/rakudo/rakudo/compare/5...5a2c9d167b
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
[Tux] This is Rakudo version 2016.09-193-ga09c8dc built on MoarVM version 2016.09-47-g736364c 06:12
csv-ip5xs 3.337
test 16.060
test-t 6.970
csv-parser 17.544
travis-ci Rakudo build failed. Zoffix Znet 'Fix Mixy.Bag/.BagHash coercers 07:39
travis-ci.org/rakudo/rakudo/builds/167376704 github.com/rakudo/rakudo/compare/2...7945eec5e4
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
psch ~ 08:31
yoleaux2 02:17Z <MasterDuke> psch: you seem to know a bit about the JVM implementation, any suggestions for how to tackle the BOOTSTRAPATTR -> Attribute problem i've been working on?
psch MasterDuke: well, assuming you did the same thing to HEAD as i did to get the "Flattening named mumble VMHash mumble" error -- which is adding istype Mu checks -- i don't think that's the right solution 08:33
s/to/past/ 09:19
travis-ci Rakudo build failed. Zoffix Znet 'Fix Cool.IO coercion 09:28
travis-ci.org/rakudo/rakudo/builds/167455558 github.com/rakudo/rakudo/compare/b...16cbbc4556
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
dalek p: b392903 | MasterDuke17++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/CallSiteDescriptor.java:
Include the bad REPR type in error message
 09:29
p: 670806b | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/CallSiteDescriptor.java:
Merge pull request #312 from MasterDuke17/remove_BOOTSTRAPATTR_where_possible

Include the bad REPR type in error message
psch oh, there was a PR sitting there... 09:30
jnthn Figured I'd do something useful and merge a PR while waiting for a build :)
psch yeah, i straight up didn't check... 09:31
cool, so i'll build nqp HEAD and nom HEAD and see if that works, and if not why not 09:32
from the looks of it, if we do check for $!compstuff ~~ Mu it works when we don't have Capture with Attribute instead of BOOTSTRAPATTR 09:33
which seems to mean that bindcapsig or something is not deconting/dehllizing enough i guess
uhm, nqp HEAD doesn't build 09:39
the indexingoptimized impl seems to be incomplete
ah 09:42
no stage0 bump for jvm 09:43
so we try to compile stage1, which uses indexingoptimized, without a stage0 that knows indexingoptimized
jnthn o.O 09:44
Yeah, I had it #?if moar'd so I'd not have to do that dance with the JVM 09:45
I guess somebody decided to...
psch pmurias i think brought it to all backends
though as noop on jvm i think?
jnthn Though not sure how they'd have gotten it to build
Ah
psch well, i'd assume the jvm hasn't been build with the op implemented :)
jnthn It should just return identity on JVM, yeah
Yeah, ops that get used in the NQP source need a bootstrap update 09:46
So that you compile with a compiler that knows about them
Maybe the JavaScript backend late-binds things enough to get away with it
psch so i remove all the uses of indexingoptimized, rebuild with the op defined but unused, then run the make target that copies to stage0/ and then reintroduce the usage of the op and build again to see everything works..? 09:48
jnthn Yes 09:49
psch well, it builds at least 10:09
got 5 failures in t/qast/01-qast.t though :l
three about state vars, two about boxing... 10:11
Zoffix :( 10:14
.oO( at least it's not about wrestling... )
psch i think we have that ticketed on the rakudo level though 10:15
i mean, something being wonky with state var
maybe i can figure it out :S
r: sub f { loop { say $++; last } }; f;f;f;f; #128661 10:16
camelia rakudo-moar a09c8d: OUTPUT«0␤0␤0␤0␤»
..rakudo-jvm 2a1605: OUTPUT«0␤1␤2␤3␤»
psch RT #128661 # /o\
anyway, yeah
that's probably it
or rather, that'll fall out from passing the nqp test, i hope :) 10:17
Zoffix Is that JVM-only failure? 10:20
All tests were passing on last release.
psch it's nqp 10:21
at least the failing test i'm talking about
and yes, it's jvm :)
i'm not really testing anything else tbh :P
Zoffix So are we going to release despite that regression or does it need to be fixed before the release? 10:22
psch well, the nqp test is from 2016-10-08 10:23
and the rakudo level bug is ticketed since 2016-07-18
Zoffix ok 10:24
psch so i don't think it's really a regression
we just didn't test for it in nqp before, and might still not test for it in roast
Zoffix We don't have any fudging mechanism in nqp, do we?
psch nope
Zoffix 'cause that failure will make the release robot abort :( I guess I'll need to teach it to ignore it when told to 10:25
psch are we releasing nqp-j and r-j?
i wasn't aware
maybe i'm thinking star 10:26
Zoffix I was running nqp-j tests in last releases... but mostly 'cause they were passing, I guess :)
Last release, I was unable to build r-j, so I ran no tests.
Or maybe it did build but R test suite was failing. it's the stuff you fixed for travis 10:27
psch that was mostly NativeCall iirc..?
Zoffix yeah
I think we should comment out the failing test for the release and then uncomment it. To avoid confusion for whoever may be building/packaging this downstream and seeing test failures where none were in the past. 10:37
psch hmm, the state var setup code does look pretty much identical across the two backends i looked at :/ 11:26
github.com/MoarVM/MoarVM/blob/mast...ame.c#L598 11:28
github.com/perl6/nqp/blob/master/s....java#L148
except, well, C is obviously a bit more verbose there
but maybe i'm also just missing something really obvious vOv
wait, there's one difference i think? 11:30
moar allocates a new MVMRegister, while JVM just assigns something from the staticCodeInfo 11:31
otoh, we clone on JVM..? 11:32
MasterDuke_ psch: i'm not sure what you mean by "adding istype Mu checks". i was getting the flattening error on the branch that had my second PR (with my first PR already merged) 11:46
psch MasterDuke_: which branch?
MasterDuke_ github.com/MasterDuke17/rakudo/tre...e_possible 11:47
my second PR was this commit: github.com/rakudo/rakudo/pull/902/...f106d79c19 11:48
psch okay, so whatever i'm doing on nom/HEAD probably has nothing at all to do with what you're doing 11:50
MasterDuke_ at first i thought it was just the changes to the Code class, but if i put all its Attributes back to BOOTSTRAPATTR i was getting the same error
oh interesting, so you are getting the same error with your work?
psch anyway, what i *did* figure out is that adding a 'nqp::istype($cs, Mu)' check in all the spots that deal with $!compstuff and also reverting the Capture Attributes to BOOTSTRAPATTR makes it work
where $!compstuff is a Code Attribute 11:51
that was against todays HEAD, maybe like 3 hours ago or so i think 11:52
since then i've been poking at nqp-j instead because that's broken too
or rather, we have new tests :)
so, i'm thinking that p6bindcaptosig is what doesn't know how to deal with Attribute instead of BOOTSTRAPATTR
but yeah, i haven't looked closer at it 11:53
MasterDuke_ cool, that's more progress than i made 11:54
psch okay, that branch merged rebased onto nom builds fine here 12:04
...i think
i might've mishandled git :)
p3rln00b xkcd.com/1597/ 12:07
MasterDuke_ my branch? nice, what'd you do to fix it? 12:11
psch nothing? i pulled it against nom 12:12
MasterDuke_ huh. did you do a make install?
psch i think so, yeah 12:13
but well, i'm not really sure git did what i thought it did so yeah
MasterDuke_ ha
psch i'm also somewhat confused with the commits in the branch, honestly 12:16
MasterDuke_ well, there may have been some git mishaps on my end also 12:20
on that branch i first made two commits, those were merged into nom with my first PR 12:21
p3rln00b m: class Foo { method dispatch:<!>(Mu \SELF: \name, Mu \type, |c) { say 'cannot call that, bruh' }; }!meow 12:22
camelia rakudo-moar a09c8d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Private method call to meow must be fully qualified with the package containing the method␤at <tmp>:1␤------> { say 'cannot call that, bruh' }; }!meow⏏<EOL>␤ expecting any of:␤ met…»
MasterDuke_ then i made another commit, and created a PR for that
p3rln00b What's all of these dispatch:<> methods? Are they available to users to override? github.com/rakudo/rakudo/blob/nom/...Mu.pm#L658 12:23
MasterDuke_ but somewhere along the way i merged nom into the branch and pushed the commits it brought along
or is it my commits you're confused about? 12:24
psch MasterDuke_: well, 26 behind and 18 ahead doesn't seem right is all 12:25
commits that is
p3rln00b m: class Foo { method dispatch:<.*>(Mu \SELF: \name, |c) { say 'cannot call that, bruh' }; }.*meow
camelia rakudo-moar a09c8d: OUTPUT«cannot call that, bruh␤»
p3rln00b w00t
psch p3rln00b: you can't use ! like that is the error
p3rln00b psch: to me it looks like a bug vis-a-vis overriding dispatch:<!> method 12:26
psch m: class Foo { method dispatch:<!>(Mu \m, |c) { say "nope" }; method bar { self!whatever } }; Foo.new.bar
camelia rakudo-moar a09c8d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤No such private method 'whatever' for invocant of type 'Foo'␤at <tmp>:1␤------> , |c) { say "nope" }; method bar { self!⏏whatever } }; Foo.new.bar␤»
MasterDuke_ psch: yeah, i may have done the merge/push/whatever incorrectly
psch m: class Foo { method dispatch:<!>(Mu \m, |c) { say "nope" }; method bar { self!whatever }; method !whatever { } }; Foo.new.bar
camelia ( no output )
p3rln00b m: class Foo { method dispatch:<.+>(Mu \SELF: \name, |c) { say "cannot call {name} like that, bruh" }; }.+meow
camelia rakudo-moar a09c8d: OUTPUT«cannot call meow like that, bruh␤»
psch p3rln00b: there might be something wrong with overriding dispatch:<!>, but it's not that you cannot call a private method from outside the class 12:27
m: class Foo { method !bar { } }!bar
camelia rakudo-moar a09c8d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Private method call to bar must be fully qualified with the package containing the method␤at <tmp>:1␤------> class Foo { method !bar { } }!bar⏏<EOL>␤ expecting any of:␤ method argu…»
psch ^^^ that error always happens like that
p3rln00b psch: ah, ok
I see what you mean
psch MasterDuke_: fwiw, after each PR i always ditch the branch completely, and branch again from the upstream HEAD, nom in our case 12:28
MasterDuke_: anyway, afaict the issue is with whatever we get in p6bindcaptosig, and how we don't handle that correctly 12:29
MasterDuke_: the interesting question is, why does what arrives there change on jvm and not on moar
MasterDuke_ psch: that's what i've done in the past (and probably exclusively will do from now on!), but in this case i was pretty sure i would do multiple PRs that were all very related 12:30
psch: yep, and unfortunately i know very little about the JVM implementation 12:31
but i am willing to try and learn more 12:34
psch cool :)
the place stuff goes wrong is in CallSiteDescriptor.explodeFlattening 12:35
moritz it has explode in the name, what do you expect? :-) 12:36
psch afair my debugging there we get a 2-elem array in oldArgs, where the first is a VMArray and the second is Mu
dalek ast: 001fb73 | (Zoffix Znet)++ | S02-types/mu.t:
[coverage] Cover all routine calls in Mu
psch so i'd assume that somehow the %hash part of the Capture doesn't make it, for one reason or another
dalek kudo/nom: e4fdc32 | (Zoffix Znet)++ | t/spectest.data:
Add S02-types/mu.t test file to list of files to run
 12:37
psch i could work around that by not converting Capture to Attribute and adding the istype Mu checks for $!compstuff, as mentioned earlier
buut i didn't save any of that anywhere and messed around a lot with my repo so yeah :P
MasterDuke_ and after you did that the rest of the BOOTSTRAPATTR -> Attribute changes worked fine you say? make install worked, did you run a j-spectest? 12:41
psch i only ran 'make test' iirc 12:42
MasterDuke_ well, that's farther than i got 12:46
dalek p: a365b62 | peschwa++ | src/vm/jvm/stage0/ (10 files):
Update JVM stage0
 13:00
p3rln00b .tell p3rln00b test 13:01
yoleaux2 p3rln00b: Talking to yourself is the first sign of madness.
p3rln00b m: { CONTROL { when CX::Warn { say "caught"; } }; warn 'foo'; say "hi"; } 13:08
camelia rakudo-moar e4fdc3: OUTPUT«caught␤»
p3rln00b TIL catching warnings aborts further code in that block
psch m: { CONTROL { when CX::Warn { say "caught"; .resume } }; warn 'foo'; say "hi"; }
camelia rakudo-moar e4fdc3: OUTPUT«caught␤hi␤»
p3rln00b m: { { warn 'foo'; say "hi"; }; CONTROL { when CX::Warn { say "caught"; } }; } 13:09
camelia rakudo-moar e4fdc3: OUTPUT«caught␤»
p3rln00b It's kinda like you're fatalizing them :/
jnthn No, it's just completley normal exception handling semantics
If you want to resume, you write that in the handler
p3rln00b m: { CONTROL { when CX::Warn { say "caught"; .resume } }; warn 'foo'; say "hi"; }
camelia rakudo-moar e4fdc3: OUTPUT«caught␤hi␤»
p3rln00b Neat.
jnthn warn is one of the few exception handlers where you do what to resume (even other control exceptions don't want that) 13:10
Well, except take I guess :)
But it's unusual to be writing a custom handler for take :) 13:11
p3rln00b ZOFVM: Files=1197, Tests=129741, 135 wallclock secs (21.25 usr 3.16 sys + 2396.22 cusr 204.47 csys = 2625.10 CPU) 13:17
dalek kudo/nom: b08ef96 | (Zoffix Znet)++ | src/core/Nil.pm:
Fix Nil.chrs

  .chrs wants to be called on an Int, not a Str. I suspect the .Str
coersion was accidentally copy-pastaed from Nil.ords method.		 13:18
ast: ea0aeff | (Zoffix Znet)++ | S02-types/nil.t:
[coverage] Cover all naked methods in Nil.pm
p3rln00b m: my $x = 42 but role meow {}; dd $x; $x++; dd $x 13:24
camelia rakudo-moar e4fdc3: OUTPUT«Int+{meow} $x = 42␤Int $x = 43␤»
p3rln00b Is this a bug? I very vaguelly recall this discussed before. 13:25
gfldex no
p3rln00b OK
gfldex the mixin happens on the object
p3rln00b Yeah. I pictured it more like a method call, rather than a sub that takes two things and makes a new thing out of them, for a second. 13:29
gfldex m: class A {}; role R { method m { say 'oi‽' } }; my $A = A but R; my $a1 = $A.new; $a1.m; my $a2 = $A.new; $a2.m; 13:42
camelia rakudo-moar b08ef9: OUTPUT«oi‽␤oi‽␤»
p3rln00b m: sub postfix:<++> (Any:D \x) {my \z = x; x.new: x+1; z }; my $x = 42 but role meow {}; dd $x; $x++; dd $x 13:50
camelia rakudo-moar b08ef9: OUTPUT«Int+{meow} $x = 42␤Int+{meow} $x = 42␤»
p3rln00b m: sub postfix:<++> (Any:D \x) {my \z = x; x = x.new: x+1; z }; my $x = 42 but role meow {}; dd $x; $x++; dd $x 13:51
camelia rakudo-moar b08ef9: OUTPUT«Int+{meow} $x = 42␤Int $x = 43␤»
p3rln00b Ah, right.
Int's .new is speshul
dalek kudo/nom: 0337137 | lizmat++ | src/core/Str.pm:
Guard .split when there is no .match

Basically, guard it from handling a List without $!reified, which will be the case after the Str.match refactor.		 13:53
lizmat m: say "1234567890".match(/./,:x(3..4)) # is this correct behaviour ? 14:14
camelia rakudo-moar 033713: OUTPUT«(｢1｣ ｢2｣ ｢3｣ ｢4｣)␤»
lizmat if so: yuck :-)
also, why isn't there any documentation on Str.match (at least on docs.perl6.org/type/Str) 14:16
p3rln00b I recall opening an issue about that. 14:17
There some docs for the adverbs on docs.perl6.org/routine/subst (bottom page) 14:18
The types are wrong tho: github.com/perl6/doc/issues/919 14:19
s/wrong/don't match implementation/; 14:20
lizmat yeah... there's a lot of that :-(
p3rln00b I'd expect :x(3..4) to give 3rd and 4th matches
lizmat am going to think about that
yes, me too, but if you don't do that, a lot of internals break 14:21
if you want 3rd and 4th match, you need to do :nth(3..4)
p3rln00b oh
lizmat anyways, going to think about this with some fresh air
Ah, and the good news is:
p3rln00b m: say "123".match(/./,:x(4))
camelia rakudo-moar 033713: OUTPUT«()␤»
p3rln00b m: say "123".match(/./,:x(3..4)) 14:22
camelia rakudo-moar 033713: OUTPUT«(｢1｣ ｢2｣ ｢3｣)␤»
lizmat yeah, stuff like that, *sigh*
anyways, the good news is, is that Str.match will be at least 2x as fast
p3rln00b lizmat: then the current behaviour makes sense to me. :x(Range) gives at most Range matches
wooo \o/
lizmat but that will be for after the release :-)
afk& 14:23
travis-ci Rakudo build failed. Zoffix Znet 'Add S02-types/mu.t test file to list of files to run' 15:19
travis-ci.org/rakudo/rakudo/builds/167632421 github.com/rakudo/rakudo/compare/a...fdc32d6d90
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
FROGGS o/ 15:20
p3rln00b \o\ 15:23
m: rand() 15:25
camelia rakudo-moar 033713: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unsupported use of rand(); in Perl 6 please use rand␤at <tmp>:1␤------> rand⏏()␤»
p3rln00b Inturresting...
m: say &rand 15:26
camelia rakudo-moar 033713: OUTPUT«sub rand ( --> Num:D) { #`(Sub+{Callable[Num:D]}|58001408) ... }␤»
p3rln00b m: my &fancyrand = &rand; fancyrand()
camelia ( no output )
p3rln00b m: my &fancyrand = &rand; fancyrand().say
camelia rakudo-moar 033713: OUTPUT«0.45808259520736␤»
p3rln00b How come we got two of them? The other one is, allegedly, uncovered living as a sub in Num: perl6.wtf/src_core_Num.pm.coverage.html#L442 15:27
And from what I understand, the `rand` just calls rand(): github.com/rakudo/rakudo/blob/nom/....nqp#L5381 15:30
OOC, how come we can't call rand?
*rand()
moritz because it's a term 15:31
if it were a function, rand - 0.5 wouldn't DWIM, or some such
p3rln00b Ahh. Thanks 15:32
m: my Num $v; ($v++).^name.say; 15:47
camelia rakudo-moar 033713: OUTPUT«Int␤»
p3rln00b Oh, it's a trivial fix. I can do it on my own :P 15:48
Making it another bug found by coverage reports \o/ 15:49
japhb p3rln00b: How many is that now? 15:55
p3rln00b japhb: not sure. Lots. Enough to make a nice bug sandwich :) Second one just today. 15:58
dalek kudo/nom: 8268ffb | (Zoffix Znet)++ | src/core/Num.pm:
Fix Num:U++

The postfix increment on a :U type is meant to return zero, but here it returns an Int zero instead of a Num zero.		 16:00
FROGGS m: my Num $v; ($v--).^name.say; 16:01
camelia rakudo-moar 033713: OUTPUT«Num␤»
FROGGS m: my Num $v; (++$v).^name.say;
camelia rakudo-moar 033713: OUTPUT«Num␤»
FROGGS m: my Num $v; (--$v).^name.say;
camelia rakudo-moar 033713: OUTPUT«Num␤»
FROGGS :o)
tbrowder Zoffix: ref roast and fudged tests: do I have to add the fudge-generated file to spectest.data? 16:09
p3rln00b tbrowder: no, the original 16:10
m: my int $x; my num $v; dd [ $x, $v ] 16:11
camelia rakudo-moar 033713: OUTPUT«[0, NaN]␤»
tbrowder Okay, thanks!
p3rln00b So default num is a NaN? That's correct, right?
ilmari m: say Num.new 16:12
camelia rakudo-moar 8268ff: OUTPUT«0␤»
ilmari m: say num.new
camelia rakudo-moar 8268ff: OUTPUT«0e0␤»
p3rln00b 'cause it messes up postfix ++/-- 16:13
m: dd (my num $)++;
camelia rakudo-moar 8268ff: OUTPUT«NaN␤»
gfldex float does provide a undefined value. No reason not to use it. 16:14
m: say NaN.defined; 16:15
camelia rakudo-moar 8268ff: OUTPUT«True␤»
gfldex i take that back
p3rln00b Oh, prefix is also ded 16:16
gfldex problem is that natives don't fit all that well into the type system of Perl 6
p3rln00b m: dd --(my num $);
camelia rakudo-moar 8268ff: OUTPUT«NaN␤»
p3rln00b m: dd --(my Num $);
camelia rakudo-moar 8268ff: OUTPUT«-1e0␤» 16:17
gfldex also, --(my num $) may be platform dependent
p3rln00b Why?
gfldex num maps to double and that is meant to be handled by the CPU 16:18
p3rln00b What about --(my int $)?
timotimo no, it's just that the default value of a native num var is not 0.0, it's NaN 16:19
it's strange to have that differ from the Num default value, though
p3rln00b OK. Then I'm making the tests to expect a NaN 16:21
gfldex see design.perl6.org/S02.html#line_787 16:22
IIRC that is a hole in the spec/rakudo 16:23
p3rln00b: you may want to invoke [Larry]
timotimo Since native types cannot represent Perl's concept of undefined values, in the absence of explicit initialization, native floating-point types default to NaN, while integer types (including bit) default to 0.
p3rln00b m: use Test; is-deeply NaN, NaN 16:25
camelia rakudo-moar 8268ff: OUTPUT«not ok 1 - ␤␤# Failed test at <tmp> line 1␤# expected: NaN␤# got: NaN␤»
p3rln00b Maybe we should amend it watch for this special case 16:26
timotimo m: use Test; is NaN, NaN
camelia rakudo-moar 8268ff: OUTPUT«ok 1 - ␤»
geekosaur NaN is a lousy choice, and I could argue that this is similar to how Date was using two different defaults (today vs. release date)
gfldex m: use Test; ok NaN === NaN
camelia rakudo-moar 8268ff: OUTPUT«ok 1 - ␤»
geekosaur 0 makes more sense, and doesn't drag IEEE754 semantics into things unexpectedly
p3rln00b m: use Test; is 'NaN', NaN 16:27
camelia rakudo-moar 8268ff: OUTPUT«ok 1 - ␤»
gfldex the whole point of native types is to drag IEEE754 semantics into Perl 6
that's why I wont use them :) 16:28
geekosaur I mean having them appear immediately when a value is created seems like asking for trouble
basically it feels to me like someone wanted to treat NaN as a native type object (or perl5 undef). it is neither and this just causes confusion for zero gain 16:29
gfldex m: say 1/NaN, 1/0
camelia rakudo-moar 8268ff: OUTPUT«Attempt to divide 1 by zero using div␤ in block <unit> at <tmp> line 1␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
geekosaur NaN is *stranger* than a type object
dalek ast: 2a3cdb2 | (Zoffix Znet)++ | S02-types/num.t:
[coverage] Num.pm: cover .Range, .new, and nude pre/postfix ++/-- candidates
 16:30
p3rln00b .tell TimToady I've added tests for uninitialized num pre/post ++/-- that expect the values to be NaN. If that's incorrect behaviour, let me know and I'll amend them: github.com/perl6/roast/blob/2a3cdb...#L215-L217 16:31
yoleaux2 p3rln00b: I'll pass your message to TimToady.
gfldex what do c/c++ do in that case? (asking because natives are used in NCI a lot)
p3rln00b &
gfldex well, c++ defaults to 0
but not sure about C
geekosaur C doesn't do defaults 16:32
p3rln00b .ask jnthn based on github.com/perl6/doc/issues/970#is...-253824298 ... then this can be tossed? github.com/rakudo/rakudo/blob/nom/...#L686-L688 16:33
yoleaux2 p3rln00b: I'll pass your message to jnthn.
gfldex undefined undefinedness it is
geekosaur the "default" is whatever happened to be in the memory location. for malloc from a pristine heap or calloc, it'll be 0. for non-pristine malloc or stack allocation, it'll be some value left behind by the last user of that chunk of memory
dalek ast: f1ab1c7 | (Tom Browder)++ | S26-documentation/07 (2 files):
Add tests for issue RT #129862

  * split table tests into current and 'skipped'; add tests for #129862, PR903
  * add a note ref future tests
  * move toward incorporating Zoffix's comments
  * add plan back in
  * removed 'done-testing' from both table test files		 17:18
ast: e596ce6 | (Zoffix Znet)++ | S26-documentation/07a-tables-todo-skipped.t:
Add missing plan
 17:19
kudo/nom: 663b03a | (Tom Browder)++ | t/spectest.data:
add new test
 17:20
kudo/nom: 41c0750 | (Zoffix Znet)++ | t/spectest.data:
Merge pull request #904 from tbrowder/new-test

add new test
p3rln00b ZOFVM: Files=1198, Tests=129754, 135 wallclock secs (21.22 usr 3.02 sys + 2397.80 cusr 211.15 csys = 2633.19 CPU) 17:32
travis-ci Rakudo build passed. Zoffix Znet 'Fix Nil.chrs 17:43
travis-ci.org/rakudo/rakudo/builds/167642174 github.com/rakudo/rakudo/compare/e...8ef9666e32
p3rln00b spots a travis bug 17:48
The closing ' is missing :) And based on chat logs, looks like it flops from being there and not being there 17:49
geekosaur it's multiline commit messages 17:59
travis chops at the embedded newline and loses the rest of that line of the template, including the close quote 18:00
p3rln00b Ah. Mistery solved :} 18:03
lucasb_ FWIW, I am +1 for making 'my num $x' default to 0e0 18:36
would there be any problem in doing that? 18:37
this goes against the 6.c specification/roast?
and for the record, in C, if the variable is a 'static', then it *is* initialized to 0.0 18:40
p3rln00b Yeah, 6.c has explicit test: is $num, NaN, 'num default value'; 18:43
in S02-types/native.t
lucasb_ ah, I didn't know that. I find that unfortunate :( 18:44
[Coke] well, if you want it changed for 6.d, it's a possibility 18:46
probably open a ticket on github.com/perl6/specs/issues ? 18:47
p3rln00b We have a document for 6d: github.com/perl6/specs/blob/master/v6d.pod
[Coke] the doc does make it harder to discuss individual issues. 18:48
which I didn't think about at the time.
p3rln00b Maybe then Issues with a 6.d label on 'em 18:49
[Coke] added a 6.d label to specs, fwiw 18:50
I mean, we need a place to talk about possible changes, we also need a place to map out a plan. 18:51
lucasb_ 6.d is planned for this Xmas?
p3rln00b lucasb_: no, some time next summer
lucasb_ ah, ok
[Coke] suggestion: when copying roast to a 6.d branch, maybe rip out fudged tests instead of leaving them fudged.
lucasb_: no
p3rln00b: ... maybe. :) 18:52
p3rln00b is in no hurry
My personal feedback on roast, from someone who never read the speculations: I wish organization was different. Maybe base it on types + features. Currently we have, lists in S02 and in S32-list (IIRC) and it's just really confusing to be finding tests in the current structure. 18:53
dalek ast: 836112b | usev6++ | S17-supply/zip-latest.t:
Skip test for RT #128694 for JVM (hangs)
masak p3rln00b: maybe the current directory structure has indeed outlived its usefulness. 18:54
p3rln00b: I can see it as being entirely *possible* to re-arrange everything according to a better scheme. Git even makes it kind of cheap to rename everything. 18:55
p3rln00b yeah
masak p3rln00b: the challenge will be to do some up-front design of a better structure, IMO
p3rln00b nods
psch [Coke]: i'm assuming by "fudged" you mean "fudged for all backends"? 18:59
oh, also i agree that restructuring roast is probably a good idea, but might not be worth the effort to create something significantly better 19:12
i recognize the weirdness in order for people who haven't read the synopses, but there is at least some order in them
p3rln00b Maybe not on 6.d but later, when it'll become even gnarlier. 19:13
'cause it's not just the test file locations only, but contents of files too.
psch right, it's the pitfall with marking the synopses out of date 19:14
because roast was based on the structure in the synopses, and we're now saying "better don't look at the synopses" it will get weird eventually
note, i'm *not* saying that we need to keep the synopses up to date
[Coke] well, and that structure is from the camel 19:15
psch so maybe, going forward, the question is "how would we want a perl6 camel to be structured" 19:16
and then the polyglot buffs can read the spec instead of a book and instantly know the whole language ;P
s/the spec/roast/ #
ooc, how prevalent are runnable test suites as language specification anyway? 19:17
[Coke] I suspect we'll know a lot more about how a 6amel will look -after- 6.d is released. 19:21
psch okay, so we somehow have to figure out how we -- that probably is the perl6 community, not the core devs -- would structure a 6amel so we can structure roast accordingly..? 19:28
[Coke] I mean, someone is theoreticaly working on that book. 19:30
but I have no idea when it's due
*cally
psch i don't think we should toss tests fudged for less-than-all backends at all, and tests fudged for all backends probably should be tossed deliberately 19:35
...to get back to that
reason being, that there's most likely nothing in roast that doesn't have any reason behind being there
of course, the validity of those reasons might have changed in cases, but that's a by-case decision 19:36
and if "it fails on jvm" could be a reason for tossing tests r-j would be spectest clean... :)
[Coke] psch: the problem is that some of these things were added back in early pugs days.
so the rationale for anything older than, say, GLR might want to be questioned at that point 19:37
psch [Coke]: yes, but it still demands at least some @LARRY attention
i'm not categorically against removing fudged tests, i'm just saying that a spec that gets reduced because the primary implementation doesn't pass it is kind of weird
unfortunately i'm not speaking from a position where i do have the knowledge or authority to decide if any given fudged test should go, so i'm just making more work for other volunteers with my position 19:38
i am willing to do a first pass, but that would probably result in 95% "can't decide" rate :S 19:39
re #129878, which i just got an email for 20:24
what even is a REGIONAL INDICATOR SYMBOL LETTER
[Coke] en.wikipedia.org/wiki/Regional_Indicator_Symbol ? 20:26
psch oh, right, the flag building ones
masak psch: it's one of 26 letters A..Z for specifying country codes.
psch i'm not sure that makes the bug report more clear or more confusing though 20:27
for the record, it's about
m: say ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" x 2).chars #=> 2
camelia rakudo-moar 41c075: OUTPUT«2␤»
psch m: say ([~] "\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2).chars #=> 1
camelia rakudo-moar 41c075: OUTPUT«1␤»
psch what trips me up is infix:<x> vs infix:<xx>
m: say ([~] ("\c[REGIONAL INDICATOR SYMBOL LETTER G]" xx 2)).chars #=> 1 # but extra parens don't change it 20:28
camelia rakudo-moar 41c075: OUTPUT«1␤»
psch m: my $x = "\c[REGIONAL INDICATOR SYMBOL LETTER G]"; say [~] $x, $x
camelia rakudo-moar 41c075: OUTPUT«🇬🇬␤»
psch m: my $x = "\c[REGIONAL INDICATOR SYMBOL LETTER G]"; say ([~] $x, $x).chars
camelia rakudo-moar 41c075: OUTPUT«1␤»
psch m: my $x = "\c[REGIONAL INDICATOR SYMBOL LETTER G]"; say ($x ~ $x).chars 20:29
camelia rakudo-moar 41c075: OUTPUT«1␤»
psch so maybe infix:<x> is wrong and this is tangetially related to the substr thing?
psch wishes to actually remember the substr thing... 20:30
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Guard .split when there is no .match
travis-ci.org/rakudo/rakudo/builds/167650498 github.com/rakudo/rakudo/compare/b...371374760c
psch r: my $a = '.' x 4 ~ 'a'; $a.substr-rw(1,1) = ''; say $a 20:31
camelia rakudo-jvm 2a1605, rakudo-moar 41c075: OUTPUT«...a␤»
psch well, that apparently got fixed
psch should probably head bedwards anyway o/
cygx o/ 21:08
I went with regional indicators as an example because I was looking into the grapheme cluster algorithm, of which they are a special case 21:10
the mail lacks details because I reported it just before heading out
at a guess, the low-level grapheme count implementation for strands probably just multiplies the grapheme number of the base string with the repetition count, but I haven't checked 21:11
again at a guess, the difference in the xx case is because it probably doesn't generate a strand, but flattens 21:12
cygx heads out again 21:13
early day tomorrow...
jnthn Yes, the problem is the strands opt (which came pre-NFG) should check if two of the chars in a row might form a grapheme 21:52
yoleaux2 16:33Z <p3rln00b> jnthn: based on github.com/perl6/doc/issues/970#is...-253824298 ... then this can be tossed? github.com/rakudo/rakudo/blob/nom/...#L686-L688
jnthn .tell p3rln00b I'd guess so, but do a spectest to be sure 21:53
yoleaux2 jnthn: I'll pass your message to p3rln00b.
jnthn psch: yes, I fixed that x and substr bug a few months ago :)
japhb jnthn: What's the state of your work on decoding and *::Async? Is it finished? Or still more to do? 22:07
jnthn japhb: A decoding error and no longer bring down the process 22:08
japhb: Just propagated as an async exception (e.g. quit)
uh, s/and no/can no/ 22:09
japhb Yeah, I decoded that after a few seconds. ;-)
jnthn Well, if that exception goes unhandled I guess it can :)
Yeah, bit tired ;)
japhb It's what, 1 AM or so?
jnthn Also I put in support for picking the encoding
Only midnight.
japhb Ah, +9 from here then. 22:10
Picking the encoding per handle will be useful on Proc::Async. I have an insane tool I need to work with that inputs binary and outputs JSON encoded in Latin-1.
jnthn Yeah, I put that in. 22:11
Just a couple of days back :)
japhb *excellent*
jnthn So, good timing ;)
japhb Heh
timotimo also different encoding on stdout and stderr :)
jnthn Plan to have streaming decoders separated out from I/O also, so you can re-use that building block in fancier situations 22:12
japhb Thank you!
jnthn Also to enable user-space encoders/decoders 22:13
So, plenty of stuff in the pipeline. Of course, that's competing with dozens of other things I want to look at :) 22:14
japhb Oh, when I was skimming backlog I saw some discussion about whether perl6 used as a filter should be allowed to canonify Unicode en passant, and ISTR the answer was something along the lines of "If you want that, declare that you want to input into Uni instead of Str". Is that actually the real plan, or was that just a brainstorming idea?
Er, If you *don't* want that
jnthn Well, if Str is a grapheme-level representation, it pretty much has to normalize 22:15
japhb Yeah, I saw some discussion about keeping two copies of the Str data (normalized and unnormalized), the former for comparisons, the latter to print back out, but that seemed to be not the general sentiment. 22:16
jnthn Yeah, I don't think everyone should pay for that
japhb Agreed.
So in your new world, how does one ask for Proc::Async or IO::Socket::Async to return Uni instead of Str or Buf? 22:17
jnthn As the Unicode consortium's own FAQ notes, (a) any other Unicode-supporting program should compare things normalized anyway so this isn't a question of Perl 6 not roundtripping *Unicode*, but rather codepoints, and (b) NFC is already the common case anyway. 22:18
I'd expect something like :norm(Uni) 22:19
japhb Ah, OK
jnthn Where :norm(Str) is the default 22:20
japhb Right
jnthn Since that way :norm(NFC) will Just Work also
japhb :-)
My main use case for caring that I roundtrip codepoints is dealing with making bulk changes to versioned files, and avoiding having files that didn't "change" in the Unicode sense, but merely got canonicalized, being added to the changeset. 22:21
jnthn Yeah. That's a case of other tools not understanding Unicode sufficiently yet. :) 22:22
In the meantime, it's reasonably enough to want to work at codepoint level in such situations. 22:23
japhb My secondary case is writing debugging tools that help me diagnose and fix other Unicode-broken tools. (If I input as Str, I might either throw exceptions left and right, or not see that the other tool is outputing unnormalized junk.)
Yeah 22:24
Anyway, thanks for your work on this stuff!
jnthn np :) 22:27
eek, just tried to make install rakudo HEAD on windows and get: 22:40
.\perl6-m.bat tools/build/install-core-dist.pl C:\consulting\MoarVM\install/share/perl6 Failed to create directory 'C:\consulting\MoarVM\install\share\perl6\precomp\77F0C951005AAFB73434E4327826E9DE79524193.1476482719.86227' with mode '0o777': Failed to mkdir: 0
in any at ././CORE.setting.moarvm line 1
in block <unit> at tools/build/install-core-dist.pl line 27
timotimo dir already exists? maybe?
is the 0 there the errno? it shouldn't be 0, right?
jnthn Pretty sure it's an errno 22:42
timotimo so basically "error: success"?
something in between reset errno because something else we did was successful?
like, a printf or something?
isn't that the common error?
jnthn Maybe so 22:43
Well, too tired to look now
timotimo understood
jnthn But yeah, the directory does already exist 22:44
timotimo probably the MVM_free right ni front of it
resets the errno
oh, wait, this is with GetLastError()
it's checking if it's != ERROR_ALREADY_EXISTS and only then will it throw 22:45
so mkdir_p returns nonzero, but GetLastError returns 0?
jnthn Odd 22:46
Thing is, if I try and mkdir something that already exists on Windows with a simple "mkdir" program it's totally fine
So there's a bit more do it than this, it seems 22:47
So yeah, harder than I have brane for right now :)
timotimo on linux it looks at errno after MVM_free is used, which could be bogus 22:48
jnthn stackoverflow.com/questions/3056998...-set-errno fwiw 22:50
summary: "it's complicated" but yes, it could be bogus
geekosaur yep, free() is one of the functions that I make sure to grab errno before calling 22:51
timotimo i've put a few int blah_errno = errno into the code 22:53
probably wants a tiny bit of extra care across the whole codebase for trouble like that 22:54
this is only dirops.c
geekosaur the safest thing to do is always grab errno immediately after an operation that sets it, if you will need it. making sure it will survive across another call can be prohibitively difficult even if you control all the code in question 22:55
(because you may have to change something such that it trashes errno and then you have to rewrite all the code that uses that something...)
jnthn bah, turns out if you run the thing enough times it eventually works 22:58
So it whines on each directory it creates but seems to have created it anyway
So the next time it gets a step further
timotimo god damn it. how is that possible?
jnthn No idea 22:59
timotimo maybe "directory already exists but the mode is wrong"?
and ... somehow it ends up setting the mode ?!?!?
jnthn Will be something silly anyway
timotimo the fuck? :)
jnthn Because everything "works" if only you retry sufficiently many times for it to trip over every directory it wants to make
travis-ci Rakudo build errored. Zoffix Znet 'Fix Num:U++ 23:02
travis-ci.org/rakudo/rakudo/builds/167685259 github.com/rakudo/rakudo/compare/0...68ffbc1ae5
buggable [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0). All failures are on JVM only.
jnthn sleep; 'night 23:18

Powered by Cro and the Raku® Programming Language.

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

Thank you!