[TuxCM] This is Rakudo version 2016.10-293-g58a4826 built on MoarVM version 2016.10-172-g1ba1dd2 07:19
csv-ip5xs 3.029
test 14.547
test-t 6.594
csv-parser 14.778
lizmat alas, the new hash scheme doesn't make things faster :-( 09:18
and good *, #perl6-dev!
DrForr o/' 09:40
|Tux| Second run 09:50
csv-ip5xs 2.974
test 13.990
test-t 6.379
csv-parser 14.728
brrt (what new hash scheme?) 10:19
oh, the flat strings thingy
unshared strings
dalek kudo/nom: 2d56751 | lizmat++ | src/core/Shaped1Array.pm:
Fix .rotate/.reverse on 1dimmed assigning to self

Turns out the problem was really in the .STORE candidate for identical shapes. If the target list contains containers that also occur in the source list (e.g. from a .reverse or a .rotate), then just assigning without creating new containers, will mess up things thoroughly, because earlier assignments can then influence the values of later assignments.
So this basically fixes:
   my @a[5] = ^5; @a = @a.rotate;
85c7072 | (Zoffix Znet)++ | src/core/Str.pm: Teach Str.parse-base to handle signed numbers
This makes it able to reverse any Real.base() output, such as
  (-16).base(16).parse-base(16), making it the only available way
to do so, since :16("...") method does not accept signed numbers.		 11:08
lizmat review: github.com/rakudo/rakudo/commit/2d56751 11:09
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Fix .rotate/.reverse on 1dimmed assigning to self 12:05
travis-ci.org/rakudo/rakudo/builds/176666957 github.com/rakudo/rakudo/compare/5...56751abe24
ast: ca3eb95 | (Zoffix Znet)++ | S32-str/parse-base.t:
Test Str.parse-base can handle signed numbers
ast: a932240 | lizmat++ | S09-multidim/methods.t:
Add tests for fix in 2d56751abe248c019116
 14:19
viki .ask TimToady was − (fancy minus) meant to work everywhere a regular minus works or just with literals? "−42".Numeric and sub (−4) {} fail for example. Should those be fixed? 14:36
yoleaux2 viki: I'll pass your message to TimToady.
viki Very interesting ticket: rt.perl.org/Ticket/Display.html?id...et-history 14:51
A negative zero exists only in Nums, but a "-0".Num convertion first results in an Int that is then converted to Num :) 14:52
Which makes sense, but is an implementation detail and isn't what the end user asked for.
At the same time, what point is there for a negative zero at this level? 14:53
viki is considering a WONTFIX for this one.
I guess I can ask him for usecases of negative zeros.. 14:54
dalek ast: ec2218c | (Zoffix Znet)++ | S32-str/parse-base.t:
Make it more clear we're testing fancy Unicode minus

Based on comments on
  github.com/perl6/roast/commit/ca3e...1fa9461f0e		 15:23
FROGGS o/ 15:47
AlexDaniel m: "-0e0".Num.perl.say 16:01
camelia rakudo-moar 85c707: OUTPUT«0e0␤»
dalek ast: 839566c | (Zoffix Znet)++ | S05-capture/match-object.t:
Add tests for smartmatch with regex-in-a-variable

For fix implemented in github.com/rakudo/rakudo/commit/5ac593e		 16:16
viki geekosaur: we do support negative zero. 16:17
geekosaur: what are limits of series and how does that translate to casting strings to numerics? 16:18
geekosaur en.wikipedia.org/wiki/Series_(mathematics) 16:19
... urgh, banner /o\
and you care about this when reading input relating to the limit of such a series.
(negative vs. positive comes in when the series relates to transcendental numbers; losing the sign is apt to put e.g. arctangent in the wrong quadrant, so the limit is signed even when zero) 16:20
viki OK. Worth implementing a fix then.
val() is kinda wonky anyway. Maybe need some rethinking anyway 16:22
geekosaur actually "numerical methods" might be the better search term; series are the focal point for negative zero but numerical methods are why they matter
viki m: quietly say val Nil
camelia rakudo-moar 85c707: OUTPUT«Nil␤»
viki m: quietly say val "42", :val-or-fail
camelia rakudo-moar 85c707: OUTPUT«42␤»
viki m: quietly say val Nil, :val-or-fail
camelia rakudo-moar 85c707: OUTPUT«Unexpected named argument 'val-or-fail' passed␤ in block <unit> at <tmp> line 1␤␤»
viki (and val() is what does the conversion in "-0".Num) 16:23
dalek kudo/nom: 7f32243 | (Zoffix Znet)++ | src/core/Complex.pm:
Fix Complex exponentiation involving zeros

Use the same rules as other numerics: 0**n == 0, but 0**0 == 1
Fixes RT#128785: rt.perl.org/Ticket/Display.html?id=128785		 17:27
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128785
dalek ast: 6cf2e01 | (Zoffix Znet)++ | S32-num/complex.t:
Test Complex exponentiation involving zeros

RT#128785: rt.perl.org/Ticket/Display.html?id=128785
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128785
viki ponders removing Rat.base(Int:D, Whatever) and is testing if any breakage occurs 17:54
I meant Rational.whatever
ohh 17:56
I can't
brain mixed stuff up
dat code github.com/rakudo/rakudo/blob/85c7...#L124-L159 17:59
eh, screw it. I'm not decrypting that. 18:02
we have Rational.base(Int:D, Whatever) that does something special and that's undocumented....
oh, now I rember how I got here... Rational.base(Int:D, Whatever) is a cause of a bug... so I guess I have to decrypt it :( 18:04
dalek p: 26c952f | (Pawel Murias)++ | src/vm/js/ (4 files):
[js] Make nqp::radix and nqp::radix_I use slurpy_array from the HLL.
 18:40
p: fe0f17f | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Make nqp::islist work properly on VMArray objects.
p: ec8f19d | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Make nqp::split use the slurpy_array from the hll.
kudo/nom: 29db214 | FROGGS++ | src/core/Label.pm:
fix Label.gist, 34f7f36 broke it
 19:36
kudo/nom: 2432c46 | (Zoffix Znet)++ | src/core/Rational.pm:
Improve readability of Rational.base algo

  - get rid of single-letter variables
  - simplify some of the logical paths
Part of the bug hunt for 0.9999999999999999999999.[base(10)|perl] giving "0.A"		 19:45
lizmat FROGGS: can a p6box_s() ever be null ?? 20:19
psch lizmat: afaik it should die internally whenever it gets something that would mean null 20:20
lizmat: note though that that might not hold on nqp-j
lizmat: the degenrate case -- i.e. passing a JVM-level null into p6box_s -- is caught on nqp-j 20:21
+e
but yeah, the result should be meaningfully stringy or the op should die 20:22
that seems to be the contract, in any case
lizmat well, it feels to me the p6box_s should be outside of the nqp::ifnull, not inside 20:25
FROGGS lizmat: you are right, my patch is wrong too...
lizmat otherwise you can forget about the nqp::ifnull anyway, since it can never be null
psch doesn't have the context
if you hand VMNull to p6box_s it dies
FROGGS lizmat: wouldnt it make sense to revert my patch an 34f7f36? 20:26
lizmat no, I think you do have a point
- nqp::ifnull(nqp::p6box_s(nqp::getlexdyn('$?FILES')), '<unknown>')); 20:27
+ nqp::p6box_s(nqp::ifnull(nqp::getlexdyn('$?FILES')), '<unknown>'));
is my suggestion
psch m: use nqp; say nqp::ifnull(nqp::p6box_s(nqp::null), "foo")
camelia rakudo-moar 2432c4: OUTPUT«Cannot unbox a type object (VMNull) to a str.␤ in block <unit> at <tmp> line 1␤␤»
psch lizmat++
lizmat m: use nqp; say p6box_s(nqp::ifnull(nqp::null, "foo")) 20:28
camelia rakudo-moar 2432c4: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤ p6box_s used at line 1␤␤»
lizmat m: use nqp; say nqp::p6box_s(nqp::ifnull(nqp::null, "foo"))
camelia rakudo-moar 2432c4: OUTPUT«foo␤»
FROGGS it is not actually boxed twice, is it?
lizmat don't think so 20:29
psch m: use nqp; say nqp::what(nqp::getlexdyn('$?FILES')) 20:30
camelia rakudo-moar 2432c4: OUTPUT«(Str)␤»
psch m: use nqp; my str $x = "foo"; say nqp::what($x)
camelia rakudo-moar 2432c4: OUTPUT«(Str)␤»
lizmat yeah, it gets upgraded automagically 20:31
psch autoboxing... *shakes fist*
m: use nqp; my \x = Label.new; say nqp::getattr(x, Label, '$!file').^methods 20:33
camelia rakudo-moar 2432c4: OUTPUT«Cannot unbox a type object (Any) to a str.␤ in block <unit> at <tmp> line 1␤␤»
psch *really* roundabout, but that seems to suggest 'str $!file'
not sure we have to manually take of the boxing anyway
lizmat m: use nqp; my \x = Label.new; say nqp::getattr(nqp::decont(x), Label, '$!file').^methods 20:35
camelia rakudo-moar 2432c4: OUTPUT«Cannot unbox a type object (Any) to a str.␤ in block <unit> at <tmp> line 1␤␤»
lizmat ah
ok
psch *take care
FROGGS can we just interpolate a str in a qq-string? 20:36
psch m: my str $x = "fooey"; say "so we $x"
camelia rakudo-moar 2432c4: OUTPUT«so we fooey␤»
FROGGS I'm quite sure it caused trouble back then when I implemented Labels
j: my str $x = "fooey"; say "so we $x"
camelia rakudo-jvm 76b061: OUTPUT«so we fooey␤»
dalek kudo/nom: 29f8fd0 | (Zoffix Znet)++ | src/core/Int.pm:
Unify accepted .base() arguments

Currently second argument to base can be a Whatever, but only if the invocant is a Rational. This creates a special case for the method, and the user has to watch out what type of a Real the invocant is, before using the Whatever precision.
Unify the method's behaviour by providing degenerate cases of Whatever precision for the rest of the Reals where it acts as if precision was not specified.
FROGGS well, we might be lucky
psch *that* would've terrified me :)
viki ooopps
psch i mean, if it had failed on r-j
dalek kudo/nom: c1d2599 | (Zoffix Znet)++ | src/core/Real.pm:
Add missing file for .base(...Whatever) commit

These changes are part of work in commit
  github.com/rakudo/rakudo/commit/29...8c565bb708		 20:37
ast: bf90578 | (Zoffix Znet)++ | S32-num/base.t:
Test all Reals can handle Whatever as precision in .base()
 20:38
kudo/nom: 53d7b72 | lizmat++ | src/core/Label.pm:
Fix Label.gist, FROGGS++
 20:39
FROGGS gnight 20:41
lizmat NR.PM meeting shutting down& 21:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!