Zoffix After a day of hacking on this, I think I'm going to reject rt.perl.org/Ticket/Display.html?id=129358 02:54
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
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.
So I'm going to reject that ticket, until there's any reasonable usecase for why Buf.splice needs Callable/Whatever candidates. 02:56
AlexDaniel Zoffix: perhaps copy that into the ticket and leave it open as RFC ? 03:04
Zoffix: I'm just thinking that after a year or two somebody will create a similar ticket 03:05
hm, or maybe a sentence or two can be added to docs 03:06
so that there are less expectations for consistency
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.
AlexDaniel that makes sense 03:07
Zoffix My original argumentation in the ticket was consistency, but that can't be achieved, so... ¯\_(ツ)_/¯
AlexDaniel maybe it should not be called splice then ¯\_(ツ)_/¯ 03:08
lizmat Files=1144, Tests=53187, 229 wallclock secs (12.81 usr 3.61 sys + 1396.79 cusr 132.71 csys = 1545.92 CPU) 10:26
dalek p: 97e7573 | (Pawel Murias)++ | t/nqp/072-rolehow.t:
Fix bug in test.
 10:50
p: 619bc2e | (Pawel Murias)++ | t/nqp/ (53 files):
Use &is in tests instead of &ok and eq.
bartolin could someone take a look at 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: rt.perl.org/rt3//Public/Bug/Displa...?id=129782
[Tux] This is Rakudo version 2016.09-105-g4abc28c built on MoarVM version 2016.09-15-gc8b4228 12:34
csv-ip5xs 3.358
test 15.978
test-t 7.184
csv-parser 17.667
MasterDuke bartolin: purely nitpicking, but if you put the added conditional at the end, the diff would be a little easier to read
(not that one line is all that difficult...) 12:36
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:43
MasterDuke yeah, i was thinking about that after i said it 12:44
since i would definitely prioritize almost any performance difference over the minor change in readability of a one-line commit 12:45
bartolin nods 12:46
psch r: sub f(--> Bool) { so 1 }; say f().WHAT 14:48
camelia rakudo-jvm 2a1605, rakudo-moar 4abc28: OUTPUT«(Bool)␤»
psch r: sub f() { so 1 }; say f().WHAT
camelia rakudo-jvm 2a1605, rakudo-moar 4abc28: OUTPUT«(Bool)␤»
dalek kudo/nom: 28c23a7 | (Zoffix Znet)++ | / (2 files):
Fix unwanted errors when smartmatching against IO::Path

The smartmatch uses the given thing to construct an IO::Path object against which the self is to be compared. However, only Cool:D can be used to make an IO::Path object, and anything else will either emit undef stringification warnings or spill guts about wrong args to IO::Path.new
Restrict ACCEPTS to Cool:D and let Any.ACCEPTS handle the rest.
psch r: sub f() { so 1 }; say f().perl
camelia rakudo-jvm 2a1605, rakudo-moar 4abc28: OUTPUT«Bool::True␤»
psch r: say (so 1).perl
camelia rakudo-jvm 2a1605: OUTPUT«1␤» 14:49
..rakudo-moar 4abc28: OUTPUT«Bool::True␤»
psch that is honestly weird
bartolin: i'm inclined to think that the QAST::Want behavior is the actual problem though
r: sub f { sub { say 1 } }; f()() # i am somehow reminded of this 14:52
camelia rakudo-moar 4abc28: OUTPUT«1␤»
( no output )
psch aw don't be shy camelia, show the NPE :P
r: sub f { sub { say 1 } }; f()() # i
camelia rakudo-moar 4abc28: OUTPUT«1␤»
..rakudo-jvm 2a1605: OUTPUT«java.lang.NullPointerException␤ in block <unit> at <tmp> line 1␤␤»
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:57
psch: ... and the interpretation of that QAST::Want on JVM is wrong? 14:59
nine .botsnack
synopsebot6 om nom nom
yoleaux2 :D
1 Oct 2016 09:11Z <Zoffix> nine: maybe you'll have a better idea of how this can be fixed: rt.perl.org/Ticket/Display.html?id=129776
psch bartolin: well, moar inlines it to Want <> with WVal(Bool) and IVal(1) as children 15:00
bartolin: the &so call, that is
bartolin psch: oh, your last evaluation does not give a NPE with --optimize=off -- I didn't know that
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.
Zoffix nine, how come we can't just use absolute path of the Filesystem repo as a thing to sha?
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)
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 :)
Zoffix Ah
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
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
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:03
nine We need that information for loading modules. Checking it afterwards is too late :) 15:12
Zoffix oh :)
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
See the bugreport that prompted the addition of the code
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
one can always git blame and find the commit message 15:14
timotimo we believe more in commit messages than in commits
moritz whereas comments tend to become out of date rather quickly
bartolin psch: from the comments (github.com/rakudo/rakudo/blob/nom/...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
timotimo: maybe you can shed some light? (wrt github.com/usev6/rakudo/commit/a547db7ebe) 15:15
nine moritz: same here
timotimo whoops, that want is totally broken :)
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
timotimo oh, phew
bartolin fixed
timotimo your patch may be right
bartolin r: my $value = 42 but False; say ?$value 15:17
camelia rakudo-jvm 2a1605: OUTPUT«True␤» 15:18
..rakudo-moar 28c23a: OUTPUT«False␤»
timotimo o_O
bartolin r-j gives False with --optimize=off here
timotimo ugh ;( 15:19
bartolin I guess it's the same problem (according to the output generated with RAKUDO_OPTIMIZER_DEBUG=1)
timotimo might be, yeah :\ 15:20
bartolin so, if my patch makes sense, it is not complete
psch bartolin: well, Bool is Int on one hand 15:27
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
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?
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
camelia rakudo-moar 28c23a: OUTPUT«Cannot unbox a type object␤ in sub f at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
psch m: sub f(int $) { say "yup" }; f True
camelia rakudo-moar 28c23a: OUTPUT«yup␤»
psch j: sub f(int $) { say "yup" }; f True
camelia rakudo-jvm 2a1605: OUTPUT«yup␤»
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:31
bartolin psch: ok, at least I understood the meaning of the Want, then :-) 15:32
bbl 15:33
timotimo well, something is mishandling that case, though
psch yeah, the Want handling in JAST::Compiler, probably :S
but that seems to be complicated stuff and i don't get it 15:34
timotimo right, the jast compiler isn't easy
travis-ci Rakudo build failed. Zoffix Znet 'Fix unwanted errors when smartmatching against IO::Path 15:40
travis-ci.org/rakudo/rakudo/builds/164435335 github.com/rakudo/rakudo/compare/4...c23a781fa1
buggable [travis build above] ☠ Did not recognize some failures. Check results manually
bartolin ok, so I won't open a PR then, but will add the discussion to the ticket 15:47
Zoffix t/04-nativecall/13-union.t 15:48
nine Zoffix: I'm not concatenating the file contents, I'm concatenating the sha1s of the contents. 16:10
Though that should be quite simple to replace by a join if that's faster 16:11
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␤␤»
Zoffix m: say Any + 4
camelia rakudo-moar 28c23a: OUTPUT«Use of uninitialized value of type Any in numeric context␤ in block <unit> at <tmp> line 1␤4␤»
Zoffix (one's a warning; the other's an exception) 16:45
Would you say a Bag:U "contains" the same elements as Bag:D with no elements in it? 16:48
Trying to make this behave more cleanly: 16:49
m: say Bag ~~ Bag.new: <a b c>
camelia rakudo-moar 28c23a: OUTPUT«Use of uninitialized value of type Any in numeric context␤ in block <unit> at <tmp> line 1␤False␤»
Zoffix Which leads to this:
m: say Bag.new(<a b>) ≼ Bag
camelia rakudo-moar 28c23a: OUTPUT«Use of uninitialized value of type Any in numeric context␤ in block <unit> at <tmp> line 1␤False␤»
Zoffix And ultimately to whether this should be a True or False:
m: say Bag.new ≼ Bag
camelia rakudo-moar 28c23a: OUTPUT«True␤»
Zoffix I'm gonna go with yes, that should be true, 'cause: 16:58
m: say Bag.keys eqv Bag.new.keys
camelia rakudo-moar 28c23a: OUTPUT«True␤»
dalek kudo/nom: fa23855 | (Zoffix Znet)++ | src/core/set_operators.pm:
Fix Baggy:U ~~ Baggy:D emitting gut-referencing warnings

The smartmatch uses (<+) op under the hood to compare the two Baggies that compares them by using > op over key's values. The key lookup of a Baggy:U returns an Any, which causes a warning to emit about undef in num comparison.
Add extra candidates to (<+) to handle :U cases, equating a Baggy:U to being an empty Baggy:D (reasoning: Bag.keys has same empty list as Bag.new.keys).
Note: for mirror symmetry, the same type of handling has been added to (+>) op, but not other setty/baggy ops that most definitely need the same treatment to avoid issuing gut-referencing warnings.		 17:34
kudo/nom: 3a6cd8a | (Zoffix Znet)++ | src/ (2 files):
Improve X::Redeclaration

  - Put '' only over the symbol and do not include postfix message in
  - Do not require `postfix` argument to be prepended with a space for
   it to be correctly rendered.
  lucasb++ for noticing		 18:00
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␤»
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:26
if so, we could reorder conditionals for more efficient short-circuiting 18:27
travis-ci Rakudo build failed. Zoffix Znet 'Fix Baggy:U ~~ Baggy:D emitting gut-referencing warnings 18:29
travis-ci.org/rakudo/rakudo/builds/164461897 github.com/rakudo/rakudo/compare/2...23855d2fe7
buggable [travis build above] ☠ Did not recognize some failures. Check results manually
Zoffix t/04-nativecall/13-union.t 18:35
travis-ci Rakudo build failed. Zoffix Znet 'Improve X::Redeclaration 19:09
travis-ci.org/rakudo/rakudo/builds/164466041 github.com/rakudo/rakudo/compare/f...6cd8a73070
buggable [travis build above] ☠ Did not recognize some failures. Check results manually
timotimo t/04-nativecall/13-union.t 19:14
gfldex jnthn: i finally managed to golf something thread-related: gist.github.com/f76cb5e18309eaf8fd...8b458c812e 19:47
i shall rakudobug
timotimo gfldex: looks good 20:03
gfldex timotimo: good in the sense that it fails on your side in the same way?
it's #129787
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129787
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:04
gfldex i get many things, as listed in the rakudobug 20:05
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:06
timotimo the output code for exception should filter out for you 20:07
Zoffix :\
timotimo wow, yeah, gfldex, we're exploding trying to write something to a libuv stream for example 20:09
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
no clue
Zoffix It's not catching it's a setting line 'cause it reads `././CORE.setting.moarvm` instead of `gen/moar/m-CORE.setting`
AlexDaniel gfldex: sometimes segfaults here 20:13
Zoffix doing it as ``fail X::Assignment::RO.new(typename => $a.^name)`` seems to have fixed the issue 20:16
gfldex timotimo: i'm trying to get a trace of that bug for halve a year now :) 20:18
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?
Many of them already do X::Comp and one does X::Syntax 21:00
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:03
bartolin psch, timotimo: I think, I've found a clean way to fix the QAST::Want handling on JVM: github.com/perl6/nqp/pull/309 21:10
stresstest is still running, but it looks promising so far
dalek ast: 82115a3 | MasterDuke17++ | S06-other/misc.t:
Test multiple *s/expressions in a double closure

They should die with the error that they are in a double closure, not silently live without enforcing the where clause.
Tests for RT #129780		 21:24
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129780
psch bartolin: ooh, nice! 21:33
bartolin: that's the one part i never investigated in compile_all_the_stmts
i mean, what exactly &want does
bartolin: really curious if that fixed all the weirds we assume are linked to that 21:34
bartolin: i.e. the mixin bug as well as the implicit anon sub return one
bartolin psch: it looks like it didn't fix the NPE you showed earlier (but the mixin bug is gone) 21:35
psch: there is a QAST::Op(null) in the generated QAST from the optimizer. (I didn't look closer, yet) 21:37
./perl6-j -e 'my $value = 42 but False; say ?$value'
False
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:39
github.com/perl6/nqp/blob/master/s...T.nqp#L657 21:41
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
psch bartolin: ah, okay. i suppose that might be some difference in the logic in compile_all_the_stmts -- or something else entirely
bartolin e.g. this code didn't die, anymore:
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␤␤»
..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␤␤»
psch bartolin: like, we have a check for VarWithFallback on JVM in compile_all_the_stmts that we don't have on moar
bartolin: but yeah, it's pretty hard to entangle because it might depend on impl differences in the other as_jast methods...
bartolin hmm, I don't know about that (VarWithFallback)
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:45
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:46
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/
and I learned a lot while poking around :-) 21:49
bartolin should really look at jnthn's++ 'rakudo and nqp internal' course 21:50
psch the course is pretty good, but afair it doesn't deal with the nqp backend layers that much 21:52
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"
but yeah, i might be wrong or didn't read it well enough :l 21:53
dalek ast: d63dad7 | MasterDuke17++ | S06-operator-overloading/infix.t:
Test dynamic operator names

Tests for RT #68024		 23:56
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...l?id=68024

Powered by Cro and the Raku® Programming Language.

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

Thank you!