Geth rakudo/nom: d232f3c5f0 | (Nick Logan)++ | .travis.yml
Re-perlify .travis.yml

  .travis.yml should be instructional when possible, so instructing users to explicitly install the jdk in a perl environment makes more sense to an end user than whatever "language: java" might imply.		 01:10
nqp: 5409c853a3 | (Samantha McVey)++ | t/nqp/106-unicodenames.t
Add tests for getstrfromname and codepointfromname

These ops previously had no tests written for them.		 05:54
nqp: 4ffa0c2df6 | (Samantha McVey)++ | src/HLL/Actions.nqp
Remove ifdefs for JVM now that we have getstrfromname op

Tests are in place so this code is now not needed anymore and we can use the same code for both backends.
[Tux] This is Rakudo version 2017.02-240-gd232f3c5f built on MoarVM version 2017.02-39-gd7caeba3 07:46
csv-ip5xs 3.091
test 12.362
test-t 5.032 - 5.077
csv-parser 12.845
lizmat afk until P6W time& 10:17
yoleaux2 12 Mar 2017 21:45Z <MasterDuke> lizmat: what are IO::Path.(Numeric|Int) for? you added them in github.com/rakudo/rakudo/commit/58...f7af43f3d4
lizmat MasterDuke: at former $work, we had a lot of log files that just had the epoch as their name
(one for every second)
so it makes sense to me to allow numerics to convert to IO::Path as well 10:18
really afk&
Geth rakudo: kalkin++ created pull request #1037:
Enhance Pod::To::Text		 13:49
ugexe m: say "/123".IO.Int; # didn't expect this to work... but i can see arguments for why it should and shouldnt 14:35
camelia 123
[Coke] m: say "/what".IO.Str 14:39
camelia /what
[Coke] m: say "/123".Int
camelia Cannot convert string to number: base-10 number must begin with valid digits or '.' in '3ā5/123' (indicated by ā)
in block <unit> at <tmp> line 1

Actually thrown at:
in block <unit> at <tmp> line 1
[Coke] It's inconsistent, at least. :|
moritz m: say "/123".IO.basename.perl 14:40
camelia "123"
ugexe m: say "/one/two/three".IO.Str; say "/1/2/3".IO.Int 14:49
camelia /one/two/three
3
IOninja It's consistent enough, considering making it use full path instead of just basename would make it fail all the time :) 14:54
And it's handy to have IO::Path that is Cool
ugexe the argument would be that IO::Path stringifies to whatever it was originally given (so if it was given an absolute path it stringifies to absolute, relative to relative) 15:46
m: say "foo".IO.Str; say $*CWD.child("foo").IO.Str
camelia foo
/home/camelia/foo
ugexe thats the only real problem with it
IOninja Not "originally given" but "what it is". .child() creates a new IO::Path 16:01
IO::Path is immutable and stringifying it gives you what it is.
IOninja doesn't see a problem with it.
Actually, I see a problem. It doesn't consider IO::Path.Cwd when stringifying 16:28
my $p = "bar".IO; chdir ".."; $p.slurp.say # still works 16:29
my $p = "bar".IO; chdir ".."; $p.Str.IO.slurp.say # doesn't
same with .path attribute... 16:31
[Coke]: did anyone ever not finish their grant? Like... gave up on it 16:32
[Coke] I am sure that has happened, yes. 16:34
IOninja Were they ever be able to apply for a grant again? 16:35
[Coke] There is no hard rule, but as a voting member of the committee, I would certainly take that into consideration on future applications 16:36
IOninja OK.
eDeniAxlal IOninja: please don't :) 16:42
IOninja I won't.
b2gills I think .Bridge should just be replace by .Numeric, as I think all it does is convert it to a Numeric so that it can further be converted to the actual type asked for 16:56
moritz no
IOninja No, to .Num 16:57
moritz .Numeric on a Numeric type should be a no-op
.Num makes more sense
IOninja AFAIK, all .Bridge methods currently just coerce to Num
b2gills So it is only used on Numerics that don't know how to convert directly to say an Int, but aren't themselves a Num? 16:58
IOninja It used to bridge ops on numerics that aren't the same, e.g. multi sub infix:<+>(Real \a, Real \b) { a.Bridge + b.Bridge } 17:01
instead of adding a ton of ops for all the combinations. And ops that can do higher precision (e.g. Rationals) have their own ops
And .Bridge converts to .Num, so what I was saying yesterday is: toss the 2 extra method calls per op and just call Num directly. 17:02
b2gills Well that does make sense since Num supports the most subsets of numbers 17:06
Geth nqp: af47dd56a4 | usev6++ | 2 files
[JVM] Minor code cleanup

  * use .equals("") to test for empty string
  * toss out (typoed) variable that was used only once		 20:01
roast: 7cf1524046 | usev6++ | S03-operators/div.t
Test code from RT #112678 with native int
 20:17
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=112678
[Tux] I am currently upgrading my OpenSUSE 13.2 to OpenSUSE 42.2 21:48
I hope it will not have any influence on timings
jnthn That's...quite a version bump :) 21:49
[Tux] not realy. Version numbering changed. 11.4 12.0 12.1 12.2 12.3 13.1 13.2 42.1 42.2
and in parallel TW (TumbleWeed) which is a rolling distribution 21:50
they promised 13.1 to be a LTR, but it proves not to be :(
anyway, as 13.2 to 42.1 proved to be a move that caused no problems whatsoever, I decided to skip 42.1 and move to 42.2 21:51
jnthn Aha :) 21:54
nine [Tux]: 13.2 to 42.2 is harmless 21:56
The only thing I didn't like was the downgrade of perl from 5.20 to 5.18 :/
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/03/13/...y-da-tags/ 21:59
[Tux] nine, I do not use system perl. I have my own perl version(s) installed 22:01
currently 5.22.0, but I plan to move to 5.24.1 (and 5.26.0 when released) 22:02
nine Tumbleweed (which works incredibly well btw.) is on 5.24.0, which I'm quite happy about :) 22:06
lizmat is tired and goes off for some shuteye 22:10
so good night, #perl6-dev!
nine Good night, lizmat++ :) 22:15

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!