| 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 booActually 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>Confusedat <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 |