gfldex m: sub niler( --> Int:D ) { return-rw Nil }; my Int $i = niler; dd $i; 01:28
camelia rakudo-moar 041919: OUTPUT«Int $i = Int␤»
gfldex what exactly does `return-rw Nil` return? 01:29
m: sub niler( --> Int:D ) { return-rw Nil }; my Int $i := niler; dd $i;
camelia rakudo-moar 041919: OUTPUT«Type check failed in binding; expected Int but got Nil (Nil)␤ in block <unit> at <tmp> line 1␤␤»
gfldex m: class Baddy is Nil {}; sub niler( --> Any:D ) { return-rw Baddy.new }; my $i := niler; dd $i; 02:01
camelia rakudo-moar 041919: OUTPUT«Nil␤»
gfldex m: class Baddy is Nil {}; sub niler( --> Any:D ) { Baddy.new }; my $i := niler; dd $i;
camelia rakudo-moar 041919: OUTPUT«Nil␤»
gfldex m: class Baddy is Nil {}; sub niler( --> Any:D ) { Baddy.new }; my $i = niler; dd $i; 02:02
camelia rakudo-moar 041919: OUTPUT«Any $i = Any␤»
gfldex m: class Baddy is Nil {}; sub niler( --> Any:D ) { Baddy.new }; my $i = 42; $i = niler; dd $i;
camelia rakudo-moar 041919: OUTPUT«Any $i = Any␤»
gfldex .tell TimToady i somehow feel that definedness contraints on --> and returns are to missleading to have. see: m: class Baddy is Nil {}; sub niler( --> Any:D ) { Baddy.new }; my $i = 42; $i = niler; dd $i; 02:24
yoleaux2 gfldex: I'll pass your message to TimToady.
gfldex m: class Baddy is Nil {}; sub niler( --> Any ) { my Any:D $r = Baddy.new; $r }; my $i = 42; $i = niler; dd $i; 02:25
camelia rakudo-moar 041919: OUTPUT«Type check failed in assignment to $r; expected type Any:D cannot be itself (perhaps Nil was assigned to a :D which had no default?)␤ in sub niler at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
gfldex .tell TimToady what makes me uneasy are lines line the following. A new and aspiring Perl 6 Programmer might take the `--> IO::Path:D` at face value. Given it's IO and we support Windows I would not bet my life on the :D part. docs.perl6.org/type/IO$COLON$COLON...d_absolute 02:32
yoleaux2 gfldex: I'll pass your message to TimToady.
gfldex m: my Nil:D $i = Failure.new('boo boo'); 02:45
camelia ( no output )
gfldex m: my Nil:D $i = Failure.new('boo boo'); say $i;
camelia rakudo-moar 041919: OUTPUT«boo boo␤␤Actually thrown at:␤ in block <unit> at <tmp> line 1␤␤»
gfldex m: my Nil:D $i = Failure.new('boo boo'); say $i.defined; 02:46
camelia rakudo-moar 041919: OUTPUT«False␤»
gfldex m: my Any:D $i = Failure.new('boo boo'); say $i.defined;
camelia rakudo-moar 041919: OUTPUT«False␤»
gfldex this is actually keeping me awake at night. :-> 02:48
dalek p: 560522b | moritz++ | / (90 files):
Some initial parrot removal
11:49
nqp: 0c3d652 | moritz++ | / (4 files):
nqp: More deparroting
kudo/nom: 2efb01b | moritz++ | tools/build/NQP_REVISION:
Bump to an NQP version without parrot support.
11:50
arnsholt moritz++ 11:56
nwc10 moritz++ 12:05
but
Unrecognized revision specifier 'parrot-15-gdd5f3c1'
because my most recent tag in my nqp is 'parrot'
p$ git describe 12:06
parrot-15-gdd5f3c1
moritz nwc10: git describe --match '^20.*' should help
nwc10 $ git describe --match '^20.*'
fatal: No names found, cannot describe anything.
moritz nwc10: eeks, --match '20*'
it's a glob, not a regex, sorry 12:07
nwc10 I was going to say "So it's a glob, not a regex?"
I guess that this means that something in nqp needs tweaking, so that one doesn't build:
$ ./nqp-m --version
This is nqp version parrot-15-gdd5f3c1 built on MoarVM version 2016.07-6-gfd7fe64
moritz fix presently forthcoming 12:10
dalek p: 2cfaf60 | moritz++ | tools/ (2 files):
Prefer numeric tags when generating version numbers from `git describe`
12:12
p: 3593d1f | moritz++ | tools/ (2 files):
Use a more windows-friendly way of quoting things

  ... hopefully
12:14
moritz it would be nice if somebody on Windows could test that
dalek kudo/nom: b294e9b | moritz++ | tools/build/NQP_REVISION:
Bump to an even newer NQP

where hopefully the version number generation is not broken by the "parrot" tag
12:15
moritz I really should have made it a branch, not a tag :(
nwc10++ # quick feedback 12:32
jnthn A non-annotated tag woulda been fine too 13:07
Since git describe only sees the annotated ones 13:08
nwc10 works on "my" machine 13:10
ilmari jnthn: except gen-version does 'git describe --tags', which includes non-annotated ones 14:20
jnthn d'oh 14:21
I thought the reason we -a'd them was for that script
I'll stop bothering then :)
The commit messages are kinda pointless... git tag -a 2016.07 ... "Tag 2016.07 release." .oO( You don't say??? ) 14:22
ilmari another use of annotated tags is that they can be signed 14:23
timotimo maybe we should annotate these release tags with wikipedia's article of the day
jnthn Yeah, but we're not doing that :)
That'd be a more sensible reason to use them, though 14:24
And arguably we should consider signing them at some point
ilmari the NQP and Rakudo ones seem to be
but not moarvm
brrt is pro-signing 14:40
anyone with a GPG key and a commit bit can sign a release, no?
unmatched} Yes. 14:41
We do that now (for Rakudo at least) 14:42
and nqp 14:43
brrt and next tags don't have to come from the same person? 14:44
then I don't see a problem with moarvm releases having signed tags
perlpilot GPG isn't required even (wasn't last time I checked)
brrt how are they signed then? 14:45
unmatched} It is required
And no, doesn't have to be same person for next tags
dalek p: 0e66b0f | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] When looking up and binding variables that are stored on context, refer directly to correct scope instead of dynamically walking over the scopes.
15:17
p: 255d2e9 | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Optimize nqp::bindattr($obj, Foo, '$!foo', $value) and nqp::getattr($obj, Foo, '$!foo') when we know Foo and '$!foo' and compile time.
nine masak: I have a probable fix for the S04-statements/return.t and S10-packages/basic.t failures 15:52
The fix is just a couple of characters. The real challenge is writing a good commit message because that will show if I 100 % understand why it fixes this issue. 15:55
dalek kudo/nom: 22e46b5 | niner++ | src/core/CompUnit/Repository/FileSystem.pm:
Fix merge global symbols failures when changing repositories

Given: use lib 'lib'; use A; use lib 'other-lib'; use B; # which uses A
A will be precompiled into lib/.precomp. B will be precompiled into other-lib against A. So everyone should have been happy. But we tried to be extra careful to not load a precomp file that was compiled when not the whole repo-chain was available. We therefore included the identity of the whole repo chain in a module's precomp id. So The A our B is precompiled against had a d7838c3 | moritz++ | tools/build/check-versions.pl: Remove parrot-specific, obsolete tool
  nwc10++ for brining it up
16:12
nine different precomp id (due to the different repo-chain) than the A we loaded in the main program. This caused the collision. Since we now have the means to safely access precomp stores of the whole repo chain, we don't need this extra carefulness anymore. Indeed it's actually harmful. github.com/rakudo/rakudo/commit/22...9360f59c0c 16:13
[Coke] loves the code vs. comment ratio there. :) 16:20
nine++ for continuing to fight the precomp batle.
*battle
[TuxCM] This is Rakudo version 2016.07.1-60-g22e46b5 built on MoarVM version 2016.07-4-g236058a 17:32
test 14.802
test-t 7.955
csv-parser 15.910
jnthn should have a decent Perl 6 tuit supply tomorrow o/ 18:04
Might well dig into concurrency things (race, hyper, etc.) 18:05
unmatched} Woohoo \o/
[Coke] ++jnthn 18:10
RT: 1325; @LARRY: 4; CONC: 7; GLR: 5; JVM: 68; LHF: 1; LTA: 81; NEW: 868; NYI: 28; OSX: 6; PERF: 18; POD: 9; PRECOMP: 8; RFC: 22; SEGV: 25; STAR: 1; TESTNEEDED: 10; TODO: 8; UNI: 12; UNTAGGED: 656; WEIRD: 3 18:17
unmatched} Is this really an LHF? rt.perl.org/Ticket/Display.html?id=126087 18:21
m: use JSON::XS::from<Perl5>
camelia rakudo-moar 22e46b: OUTPUT«===SORRY!===␤Could not find JSON::XS::from at line 1 in:␤ /home/camelia/.perl6␤ /home/camelia/rakudo-m-inst-2/share/perl6/site␤ /home/camelia/rakudo-m-inst-2/share/perl6/vendor␤ /home/camelia/rakudo-m-inst-2/share/perl6␤ CompUnit…»
psch unmatched}: the naive thing would be to check for a final package in the use named "from" 18:22
unmatched}: that solution is pretty LHF, yes
unmatched} That's too naive
That means I can't have a package with 'from' in it. 18:23
psch the next safety would be to check for a positional parameter to the use that fits a Repository spec
unmatched} And there are already Config::From and Term::From
psch 'from' ne 'From'
unmatched} Details :) 18:24
Also: windows
psch so on windows "use lWp::uSErAgENt" works? 18:25
perlpilot checking if the last bit is "::from" isn't too naive. You only have to do it when the Whatever::from isn't found and then only do to suggest that they may have meant :from instead 18:28
s/do to/do it to/
So ... LHF to make the error message non-LTA 18:29
unmatched} psch: yup 18:30
psch well, that's definitely a bug
perlpilot indeed.
psch also probably not LHF :)
unmatched} gist.github.com/zoffixznet/55d55bd...8ed2925754 18:32
But how would it know that the file isn't the right one if there's no case sensitivity on Windows? 18:33
unmatched} I don't need a "unit class Foo;" in there. It can be just a bunch of subs, or even a plain sub EXPORT and nothing else :/ 18:34
Another LTA-ness in the same area: 18:44
m: use Test:From<Perl5>'
camelia rakudo-moar 22e46b: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Confused␤at <tmp>:1␤------> use Test:From<Perl5>⏏'␤»
unmatched} m: use Test:From<Perl5> # I mean this
camelia ( no output )
jnthn I *think* for installed modules (e.g. not coming via -Ilib) even on Windows it's case sensitive. 19:00
unmatched} Yeah, it is. Just the files 19:01
Yeah, it is. Just the files where this ambiguity happens. 19:02
jnthn Yeah... That may be resolvable too
unmatched} :o
jnthn If you can see what the directory actually contains by querying the file system, you can see if it matches up, for example. :) 19:03
unmatched} Neat.
jnthn Just 'cus the file system is case insensitive doesn't mean it doesn't know which case the user typed :)
On Windows at least.
otoh, that kind of introspection does of course give some risk of race conditions... 19:04
pub &
[Coke] CSRF failures from rakudo to RT have been resolved. 19:24
I only ever saw them when I wasn't logged in, now they're gone.
timotimo \o/ 19:26
travis-ci Rakudo build passed. Moritz Lenz 'Remove parrot-specific, obsolete tool 19:47
travis-ci.org/rakudo/rakudo/builds/147553740 github.com/rakudo/rakudo/compare/2...838c3c9bfc
dalek kudo/nom: c57ac29 | lizmat++ | src/core/Any-iterable-methods.pm:
Fix comment
21:48