Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-10-02

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:48 buggable joined #perl6-dev
01:49 ilbot3 joined #perl6-dev
01:49 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today
02:54 Zoffix After a day of hacking on this, I think I'm going to reject https://rt.perl.org/Ticket/Display.html?id=129358
02:55 Zoffix Bufs have a bit different candidates in that they take native int arrays, or other Bufs, and they replacement arrays need to have int things in them. So basically exact match between Array.splice and Buf.spice won't happen.
02:55 Zoffix That leaves to adding Callable and Whatever candidates to Buf.splice, but IMO that's overengineering, and the 31 candidates for Arrays.splice are telling of that.
02:56 Zoffix So I'm going to reject that ticket, until there's any reasonable usecase for why Buf.splice needs Callable/Whatever candidates.
03:04 AlexDaniel Zoffix: perhaps copy that into the ticket and leave it open as RFC ?
03:05 AlexDaniel Zoffix: I'm just thinking that after a year or two somebody will create a similar ticket
03:06 AlexDaniel hm, or maybe a sentence or two can be added to docs
03:06 AlexDaniel so that there are less expectations for consistency
03:06 Zoffix And that's when we'll consider it. I don't want people to start coming up with imaginary reasons for why we should add extra candidates. I'd rather see an organic, real-world usecase.
03:07 AlexDaniel that makes sense
03:07 Zoffix My original argumentation in the ticket was consistency, but that can't be achieved, so... ¯\_(ツ)_/¯
03:08 AlexDaniel maybe it should not be called splice then ¯\_(ツ)_/¯
08:50 FROGGS joined #perl6-dev
08:52 pyrimidine joined #perl6-dev
09:46 ggoebel joined #perl6-dev
10:26 lizmat Files=1144, Tests=53187, 229 wallclock secs (12.81 usr  3.61 sys + 1396.79 cusr 132.71 csys = 1545.92 CPU)
10:44 pyrimidi_ joined #perl6-dev
10:50 dalek nqp: 97e7573 | (Pawel Murias)++ | t/nqp/072-rolehow.t:
10:50 dalek nqp: Fix bug in test.
10:50 dalek nqp: review: https://github.com/perl6/nqp/commit/97e75733f9
10:50 dalek nqp: 619bc2e | (Pawel Murias)++ | t/nqp/ (53 files):
10:50 dalek nqp: Use &is in tests instead of &ok and eq.
10:50 dalek nqp: This should give much better diagnostics when a test fails.
10:50 dalek nqp: review: https://github.com/perl6/nqp/commit/619bc2eeb0
12:24 bartolin could someone take a look at https://github.com/usev6/rakudo/commit/a547db7ebe ? It's an attempt to fix RT #129782 but I'm not sure if there is indeed a (kind of) bug in the optimizer or if the fix has to happen in the JVM specific code.
12:24 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=129782
12:34 [Tux] This is Rakudo version 2016.09-105-g4abc28c built on MoarVM version 2016.09-15-gc8b4228
12:34 [Tux] csv-ip5xs        3.358
12:34 [Tux] test            15.978
12:34 [Tux] test-t           7.184
12:34 [Tux] csv-parser      17.667
12:34 MasterDuke bartolin: purely nitpicking, but if you put the added conditional at the end, the diff would be a little easier to read
12:36 MasterDuke (not that one line is all that difficult...)
12:43 bartolin MasterDuke: thanks, noted. I wondered where the additional check should be placed wrt performance, since the order could make a difference performance wise, couldn't it? But, I've no idea how hot that path is
12:44 MasterDuke yeah, i was thinking about that after i said it
12:45 MasterDuke since i would definitely prioritize almost any performance difference over the minor change in readability of a one-line commit
12:46 * bartolin nods
13:49 lucasb_ joined #perl6-dev
14:06 AlexDaniel joined #perl6-dev
14:48 psch r: sub f(--> Bool) { so 1 }; say f().WHAT
14:48 camelia rakudo-jvm 2a1605, rakudo-moar 4abc28: OUTPUT«(Bool)␤»
14:48 psch r: sub f() { so 1 }; say f().WHAT
14:48 camelia rakudo-jvm 2a1605, rakudo-moar 4abc28: OUTPUT«(Bool)␤»
14:48 dalek rakudo/nom: 28c23a7 | (Zoffix Znet)++ | / (2 files):
14:48 dalek rakudo/nom: Fix unwanted errors when smartmatching against IO::Path
14:48 dalek rakudo/nom:
14:48 dalek rakudo/nom: The smartmatch uses the given thing to construct an IO::Path object
14:48 dalek rakudo/nom: against which the self is to be compared. However, only Cool:D can
14:48 dalek rakudo/nom: be used to make an IO::Path object, and anything else will either emit
14:48 dalek rakudo/nom: undef stringification warnings or spill guts about wrong args to IO::Path.new
14:48 dalek rakudo/nom:
14:48 dalek rakudo/nom: Restrict ACCEPTS to Cool:D and let Any.ACCEPTS handle the rest.
14:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/28c23a781f
14:48 psch r: sub f() { so 1 }; say f().perl
14:48 camelia rakudo-jvm 2a1605, rakudo-moar 4abc28: OUTPUT«Bool::True␤»
14:48 psch r: say (so 1).perl
14:49 camelia rakudo-jvm 2a1605: OUTPUT«1␤»
14:49 camelia ..rakudo-moar 4abc28: OUTPUT«Bool::True␤»
14:49 psch that is honestly weird
14:49 psch bartolin: i'm inclined to think that the QAST::Want behavior is the actual problem though
14:52 psch r: sub f { sub { say 1 } }; f()() # i am somehow reminded of this
14:52 camelia rakudo-moar 4abc28: OUTPUT«1␤»
14:52 camelia ..rakudo-jvm 2a1605: ( no output )
14:52 psch aw don't be shy camelia, show the NPE :P
14:52 psch r: sub f { sub { say 1 } }; f()() # i
14:52 camelia rakudo-moar 4abc28: OUTPUT«1␤»
14:52 camelia ..rakudo-jvm 2a1605: OUTPUT«java.lang.NullPointerException␤  in block <unit> at <tmp> line 1␤␤»
14:57 bartolin psch: so, you would say it makes sense to have a QAST::Want with a QAST::WVal for the 'True' and a QAST::IVal for the '1'?
14:59 bartolin psch: ... and the interpretation of that QAST::Want on JVM is wrong?
14:59 nine .botsnack
14:59 synopsebot6 om nom nom
14:59 yoleaux2 :D
14:59 yoleaux2 1 Oct 2016 09:11Z <Zoffix> nine: maybe you'll have a better idea of how this can be fixed: https://rt.perl.org/Ticket/Display.html?id=129776
15:00 psch bartolin: well, moar inlines it to Want <> with WVal(Bool) and IVal(1) as children
15:00 psch bartolin: the &so call, that is
15:00 bartolin psch: oh, your last evaluation does not give a NPE with --optimize=off -- I didn't know that
15:00 nine Zoffix: wil have to benchmark different solutions. If we can get away with it, I'd very much like to stick with checking the files' contents.
15:00 Zoffix nine, how come we can't just use absolute path of the Filesystem repo as a thing to sha?
15:01 nine Because then we don't notice when one of the file changes.
15:01 bartolin psch: yeah, the QAST is the same on JVM (if I'm not mistaken)
15:01 psch bartolin: and considering the post-optimize QAST looks the same across the backends but doesn't give the same result... well there's probably something wrong in the wrong backend :)
15:01 Zoffix Ah
15:01 psch bartolin: i'd guess it's probably something with how we have to do returns out of band on jvm and sometimes don't carry the right $*WANT around or so
15:02 psch bartolin: but honestly those bits of the QAST -> JAST Compiler aren't particularly transparent to me :)
15:02 nine And file modifcation time stamps have worst case resolution of 2 full seconds which leads to fun debugging this
15:03 Zoffix The problem is we're checking what aren't even Perl 6 modules (some of the repos in the dir where I originally discovered this were Perl 5 modules). I'm wondering if we couldn't just consider only the modules loaded by the program rather than recursing and slurping any file that looks like a P6 module.
15:12 nine We need that information for loading modules. Checking it afterwards is too late :)
15:12 Zoffix oh :)
15:12 nine We need it to check if the precompiled dependencies are still up to date or if maybe an updated dependency of our dependencies appeared in a -Ilib
15:12 nine See the bugreport that prompted the addition of the code
15:13 nine I usually try to leave very descriptive commit messages :)
15:13 moritz at $work, we believe more in commit messages (and tickets linked to from the commit messages) than in comments
15:14 moritz one can always git blame and find the commit message
15:14 timotimo we believe more in commit messages than in commits
15:14 moritz whereas comments tend to become out of date rather quickly
15:14 bartolin psch: from the comments (https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Optimizer.nqp#L1433) I got the impression that those QAST::Want are really only meant for Int, Num and Str (in order to add a native variant) -- and not for Bool
15:15 bartolin timotimo: maybe you can shed some light? (wrt https://github.com/usev6/rakudo/commit/a547db7ebe)
15:15 nine moritz: same here
15:15 timotimo whoops, that want is totally broken :)
15:16 timotimo it should have the Ii and the IVal at the same level as the WVal(Bool)
15:16 bartolin timotimo: sorry, that was my fault
15:16 timotimo oh, phew
15:16 bartolin fixed
15:16 timotimo your patch may be right
15:17 bartolin r: my $value = 42 but False; say ?$value
15:18 camelia rakudo-jvm 2a1605: OUTPUT«True␤»
15:18 camelia ..rakudo-moar 28c23a: OUTPUT«False␤»
15:18 timotimo o_O
15:18 bartolin r-j gives False with --optimize=off here
15:19 timotimo ugh ;(
15:19 bartolin I guess it's the same problem (according to the output generated with RAKUDO_OPTIMIZER_DEBUG=1)
15:20 timotimo might be, yeah :\
15:20 bartolin so, if my patch makes sense, it is not complete
15:27 psch bartolin: well, Bool is Int on one hand
15:27 psch bartolin: and on the other, there's demonstrably other cases where the optimizer produces something related to Wants that works on moar and doesn't on jvm
15:28 psch bartolin: so i think the optimizer isn't to blame
15:28 timotimo would stage parse performance benefit from having "numish" a tiny bit faster?
15:29 bartolin psch: yeah. but do we really need the Want there? I mean, both the optimizer and the JVM backend could be wrong :-)
15:29 psch m: sub f(int $) { say "yup" }; f Bool
15:29 camelia rakudo-moar 28c23a: OUTPUT«Cannot unbox a type object␤  in sub f at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤»
15:29 psch m: sub f(int $) { say "yup" }; f True
15:29 camelia rakudo-moar 28c23a: OUTPUT«yup␤»
15:29 psch j: sub f(int $) { say "yup" }; f True
15:29 camelia rakudo-jvm 2a1605: OUTPUT«yup␤»
15:31 psch bartolin: afaiu the Want means "here's the native value in case you need it", and an IVal makes perfect sense for in the case of Bool
15:32 bartolin psch: ok, at least I understood the meaning of the Want, then :-)
15:33 bartolin bbl
15:33 timotimo well, something is mishandling that case, though
15:33 psch yeah, the Want handling in JAST::Compiler, probably :S
15:34 psch but that seems to be complicated stuff and i don't get it
15:34 timotimo right, the jast compiler isn't easy
15:40 travis-ci joined #perl6-dev
15:40 travis-ci Rakudo build failed. Zoffix Znet 'Fix unwanted errors when smartmatching against IO::Path
15:40 travis-ci https://travis-ci.org/rakudo/rakudo/builds/164435335 https://github.com/rakudo/rakudo/compare/4abc28ca0712...28c23a781fa1
15:40 travis-ci left #perl6-dev
15:40 buggable [travis build above] ☠ Did not recognize some failures. Check results manually
15:47 bartolin ok, so I won't open a PR then, but will add the discussion to the ticket
15:48 Zoffix t/04-nativecall/13-union.t
16:10 nine Zoffix: I'm not concatenating the file contents, I'm concatenating the sha1s of the contents.
16:11 nine Though that should be quite simple to replace by a join if that's faster
16:12 Ven_ joined #perl6-dev
16:44 Zoffix m: say Int + 4
16:44 camelia rakudo-moar 28c23a: OUTPUT«Invocant requires an instance of type Int, but a type object was passed.  Did you forget a .new?␤  in block <unit> at <tmp> line 1␤␤»
16:44 Zoffix m: say Any + 4
16:44 camelia rakudo-moar 28c23a: OUTPUT«Use of uninitialized value of type Any in numeric context␤  in block <unit> at <tmp> line 1␤4␤»
16:45 Zoffix (one's a warning; the other's an exception)
16:48 Zoffix Would you say a Bag:U "contains" the same elements as Bag:D with no elements in it?
16:49 Zoffix Trying to make this behave more cleanly:
16:49 Zoffix m: say Bag ~~ Bag.new: <a b c>
16:49 camelia rakudo-moar 28c23a: OUTPUT«Use of uninitialized value of type Any in numeric context␤  in block <unit> at <tmp> line 1␤False␤»
16:49 Zoffix Which leads to this:
16:49 Zoffix m: say Bag.new(<a b>) ≼ Bag
16:49 camelia rakudo-moar 28c23a: OUTPUT«Use of uninitialized value of type Any in numeric context␤  in block <unit> at <tmp> line 1␤False␤»
16:49 Zoffix And ultimately to whether this should be a True or False:
16:49 Zoffix m: say Bag.new ≼ Bag
16:49 camelia rakudo-moar 28c23a: OUTPUT«True␤»
16:58 Zoffix I'm gonna go with yes, that should be true, 'cause:
16:58 Zoffix m: say Bag.keys eqv Bag.new.keys
16:58 camelia rakudo-moar 28c23a: OUTPUT«True␤»
17:34 dalek rakudo/nom: fa23855 | (Zoffix Znet)++ | src/core/set_operators.pm:
17:34 dalek rakudo/nom: Fix Baggy:U ~~ Baggy:D emitting gut-referencing warnings
17:34 dalek rakudo/nom:
17:34 dalek rakudo/nom: The smartmatch uses (<+) op under the hood to compare the two Baggies that
17:34 dalek rakudo/nom: compares them by using > op over key's values. The key lookup of a Baggy:U
17:34 dalek rakudo/nom: returns an Any, which causes a warning to emit about undef in num comparison.
17:34 dalek rakudo/nom:
17:34 dalek rakudo/nom: Add extra candidates to (<+) to handle :U cases, equating a Baggy:U to being
17:34 dalek rakudo/nom: an empty Baggy:D (reasoning: Bag.keys has same empty list as Bag.new.keys).
17:34 dalek rakudo/nom:
17:34 dalek rakudo/nom: Note: for mirror symmetry, the same type of handling has been added to (+>) op,
17:34 dalek rakudo/nom: but not other setty/baggy ops that most definitely need the same treatment to
17:34 dalek rakudo/nom: avoid issuing gut-referencing warnings.
17:34 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/fa23855d2f
18:00 dalek rakudo/nom: 3a6cd8a | (Zoffix Znet)++ | src/ (2 files):
18:00 dalek rakudo/nom: Improve X::Redeclaration
18:00 dalek rakudo/nom:
18:00 dalek rakudo/nom: - Put '' only over the symbol and do not include postfix message in
18:00 dalek rakudo/nom: - Do not require `postfix` argument to be prepended with a space for
18:00 dalek rakudo/nom:     it to be correctly rendered.
18:00 dalek rakudo/nom:
18:00 dalek rakudo/nom: lucasb++ for noticing
18:00 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3a6cd8a730
18:02 timotimo m: say "filetest-d took { 3594 / 268118 }ms per invocation"
18:02 camelia rakudo-moar fa2385: OUTPUT«filetest-d took 0.0134045ms per invocation␤»
18:21 MasterDukeLaptop joined #perl6-dev
18:26 MasterDukeLaptop i was wondering this morning, is there a good/easy way to get metrics on which test makes a conditional pass or fail?
18:27 MasterDukeLaptop if so, we could reorder conditionals for more efficient short-circuiting
18:29 travis-ci joined #perl6-dev
18:29 travis-ci Rakudo build failed. Zoffix Znet 'Fix Baggy:U ~~ Baggy:D emitting gut-referencing warnings
18:29 travis-ci https://travis-ci.org/rakudo/rakudo/builds/164461897 https://github.com/rakudo/rakudo/compare/28c23a781fa1...fa23855d2fe7
18:29 travis-ci left #perl6-dev
18:29 buggable [travis build above] ☠ Did not recognize some failures. Check results manually
18:35 Zoffix t/04-nativecall/13-union.t
19:09 travis-ci joined #perl6-dev
19:09 travis-ci Rakudo build failed. Zoffix Znet 'Improve X::Redeclaration
19:09 travis-ci https://travis-ci.org/rakudo/rakudo/builds/164466041 https://github.com/rakudo/rakudo/compare/fa23855d2fe7...3a6cd8a73070
19:09 travis-ci left #perl6-dev
19:09 buggable [travis build above] ☠ Did not recognize some failures. Check results manually
19:14 timotimo t/04-nativecall/13-union.t
19:47 gfldex jnthn: i finally managed to golf something thread-related: https://gist.github.com/f76cb5e18309eaf8fdf9bf8b458c812e
19:47 gfldex i shall rakudobug
20:03 timotimo gfldex: looks good
20:03 gfldex timotimo: good in the sense that it fails on your side in the same way?
20:03 gfldex it's #129787
20:03 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=129787
20:04 timotimo don't know how it fails on your end. i get a bit more than 500 numbers, a whole bunch more "bad"s and then it freezes
20:05 gfldex i get many things, as listed in the rakudobug
20:06 Zoffix What's the way to return a Failure so it doesn't reference the guts? I tried with X::Assignment::RO.new(typename => $a.^name).fail, but it has "in any  at ././CORE.setting.moarvm line 1" in its output
20:07 timotimo the output code for exception should filter out for you
20:07 Zoffix :\
20:09 timotimo wow, yeah, gfldex, we're exploding trying to write something to a libuv stream for example
20:11 timotimo huh, looks a little like two threads trying to write to that stream at the same time, and one of them frees a buffer that goes with it while another tries to write to it?
20:11 timotimo no clue
20:11 Zoffix It's not catching it's a setting line 'cause it reads `././CORE.setting.moarvm` instead of `gen/moar/m-CORE.setting`
20:13 AlexDaniel gfldex: sometimes segfaults here
20:16 Zoffix doing it as ``fail X::Assignment::RO.new(typename => $a.^name)`` seems to have fixed the issue
20:18 gfldex timotimo: i'm trying to get a trace of that bug for halve a year now :)
20:21 Ven_ joined #perl6-dev
20:38 Ven_ joined #perl6-dev
20:57 gfldex there are 5 exceptions under X::Parameter but there is no such role. Is that rakudobug-worthy?
20:57 Zoffix What would that role provide?
21:00 Zoffix Many of them already do X::Comp and one does X::Syntax
21:03 gfldex Zoffix: one could smart match against X::Parameter. Not sure if that is in itself useful right now. A editor written in Perl 6 might want to do that. Also, consistent Consistency.
21:10 bartolin psch, timotimo: I think, I've found a clean way to fix the QAST::Want handling on JVM: https://github.com/perl6/nqp/pull/309
21:10 bartolin stresstest is still running, but it looks promising so far
21:24 dalek roast: 82115a3 | MasterDuke17++ | S06-other/misc.t:
21:24 dalek roast: Test multiple *s/expressions in a double closure
21:24 dalek roast:
21:24 dalek roast: They should die with the error that they are in a double closure, not
21:24 dalek roast: silently live without enforcing the where clause.
21:24 dalek roast:
21:24 dalek roast: Tests for RT #129780
21:24 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=129780
21:24 dalek roast: review: https://github.com/perl6/roast/commit/82115a385c
21:33 psch bartolin: ooh, nice!
21:33 psch bartolin: that's the one part i never investigated in compile_all_the_stmts
21:33 psch i mean, what exactly &want does
21:34 psch bartolin: really curious if that fixed all the weirds we assume are linked to that
21:34 psch bartolin: i.e. the mixin bug as well as the implicit anon sub return one
21:35 bartolin psch: it looks like it didn't fix the NPE you showed earlier (but the mixin bug is gone)
21:37 bartolin psch: there is a QAST::Op(null) in the generated QAST from the optimizer. (I didn't look closer, yet)
21:37 bartolin ./perl6-j -e 'my $value = 42 but False; say ?$value'
21:37 bartolin False
21:39 bartolin psch: interestingly in src/vm/moar/QAST/QASTCompilerMAST.nqp there is an additional check for '$type != $MVM_reg_obj'. we don't have that for JVM
21:41 bartolin https://github.com/perl6/nqp/blob/master/src/vm/moar/QAST/QASTCompilerMAST.nqp#L657
21:43 psch bartolin: well, we do have $RT_OBJ on JVM
21:43 bartolin I tried to add a similiar check (type != $RT_OBJ). With that the NPE was gone -- but other things went wrong
21:43 psch bartolin: ah, okay.  i suppose that might be some difference in the logic in compile_all_the_stmts -- or something else entirely
21:43 bartolin e.g. this code didn't die, anymore:
21:44 bartolin r: [4, 8, 15, 16, 23][* - 42]
21:44 camelia rakudo-jvm 2a1605: OUTPUT«Effective index out of range. Is: -37, should be in 0..Inf␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in block <unit> at <tmp> line 1␤␤»
21:44 camelia ..rakudo-moar 3a6cd8: OUTPUT«Effective index out of range. Is: -37, should be in 0..Inf␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in block <unit> at <tmp> line 1␤␤»
21:44 psch bartolin: like, we have a check for VarWithFallback on JVM in compile_all_the_stmts that we don't have on moar
21:44 psch bartolin: but yeah, it's pretty hard to entangle because it might depend on impl differences in the other as_jast methods...
21:44 bartolin hmm, I don't know about that (VarWithFallback)
21:45 psch i have no idea what it's good for, except that on moar it only has it's own as_jast method but on jvm there's that check in compile_all_the_stmts
21:46 bartolin however, the QAST::Want with a QAST::Op(null) looks strange to me. if I find some time, I'll take another look
21:48 psch well, two of three for one (or something..?) is pretty great, in any case :)
21:48 bartolin yeah, I'm happy with that \o/
21:49 bartolin and I learned a lot while poking around :-)
21:50 * bartolin should really look at jnthn's++ 'rakudo and nqp internal' course
21:52 psch the course is pretty good, but afair it doesn't deal with the nqp backend layers that much
21:52 psch i might misremember though, but afair it's mostly about "how to build a language in nqp assuming the compilation to the backend already works"
21:53 psch but yeah, i might be wrong or didn't read it well enough :l
23:56 dalek roast: d63dad7 | MasterDuke17++ | S06-operator-overloading/infix.t:
23:56 dalek roast: Test dynamic operator names
23:56 dalek roast:
23:56 dalek roast: Tests for RT #68024
23:56 dalek roast: review: https://github.com/perl6/roast/commit/d63dad7427
23:56 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=68024

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary