Geth rakudo: 900c1b598e | (Zoffix Znet)++ | 3 files
Awesomify and test unit-scope sub error

Fixes #1364		 01:05
synopsebot RAKUDO#1364 [open]: github.com/rakudo/rakudo/issues/1364 Vague unit-scope error msg for semi-colon at end of a header [LTA]
Geth rakudo: 96a3582c44 | (Zoffix Znet)++ | src/Perl6/Grammar.nqp
Fix overly-long line
 01:08
travis-ci Rakudo build errored. Zoffix Znet 'Awesomify and test unit-scope sub error 02:57
travis-ci.org/rakudo/rakudo/builds/325277203 github.com/rakudo/rakudo/compare/f...0c1b598e54
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
Geth rakudo: 5ed59dd8e2 | (Zoffix Znet)++ | src/Perl6/World.nqp
Document nqp::nulls in coercer finder betterer
 03:00
travis-ci Rakudo build errored. Zoffix Znet 'Fix overly-long line' 03:37
travis-ci.org/rakudo/rakudo/builds/325277813 github.com/rakudo/rakudo/compare/9...a3582c4473
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. Across all jobs, only t/04-nativecall/01-argless.t test file failed.
travis-ci Rakudo build failed. Zoffix Znet 'Improve DefiniteHOW coercers 04:34
travis-ci.org/rakudo/rakudo/builds/325300302 github.com/rakudo/rakudo/compare/9...47a4c11a80
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. Across all jobs, only t/05-messages/01-errors.t test file failed.
Geth rakudo: 9cf2f99861 | (Nick Logan)++ (committed using GitHub Web editor) | src/core/CompUnit/Repository/Locally.pm
Fix CURFS/CURI .perl output

CompUnit::Repository::Locally repos -- CompUnit::Repository::FileSystem, CompUnit::Repository::Installation -- take a named parameter instead of a positional (a pre-v6c artifact)		 04:54
travis-ci Rakudo build failed. Zoffix Znet 'Document nqp::nulls in coercer finder betterer' 05:29
travis-ci.org/rakudo/rakudo/builds/325300666 github.com/rakudo/rakudo/compare/3...d59dd8e2d6
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. Across all jobs, 2 unique test files failed.
travis-ci Rakudo build failed. Nick Logan 'Fix CURFS/CURI .perl output 06:24
travis-ci.org/rakudo/rakudo/builds/325318132 github.com/rakudo/rakudo/compare/5...f2f998618f
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. Across all jobs, 2 unique test files failed.
[Tux] Rakudo version 2017.12-103-g9cf2f9986 - MoarVM version 2017.12-20-g571034087
csv-ip5xs1.138 - 1.143
csv-ip5xs-2013.373 - 13.670
csv-parser12.547 - 13.796
csv-test-xs-200.449 - 0.491
test12.046 - 12.143
test-t3.010 - 3.058
test-t --race1.309 - 1.380
test-t-2053.278 - 53.877
test-t-20 --race18.661 - 19.023
 08:26
lizmat Files=1231, Tests=76000, 328 wallclock secs (14.86 usr 5.38 sys + 2268.31 cusr 232.46 csys = 2521.01 CPU) 09:07
gfldex lizmat: are those range checks fast? github.com/rakudo/rakudo/blob/mast...ime.pm#L69 10:28
lizmat it could probably use a more optimized version in the Dateish role 10:31
because we can be sure we're dealing with Int's there ? 10:32
in any case, Range.in-range could probably use to be a multi that has two candidates: one with, and one without a $what 10:35
gfldex m: my $a; for ^1000000 { $a = (0..59).in-range(59.rand(), 'hour') }; say now - BEGIN now; 10:39
camelia 8.0017520
gfldex m: my $a; for ^1000000 { $a = 0 ≤ 59.rand() ≤ 59 }; say now - BEGIN now;
camelia 1.4841637
gfldex I like 1.4s better :)
lizmat yup, that's better, but in-range also throws when it is not in range 10:44
gfldex m: my $a; for ^1000000 { $a = 0 ≤ 59.rand() ≤ 59 || Exception.new('ouch‼').throw }; say now - BEGIN now; 10:46
camelia 1.47866273
gfldex m: my $a; for ^1000000 { $a = 0 ≤ 60.rand() ≤ 59 || die('ouch‼') }; say now - BEGIN now; 10:47
camelia ouch‼
in block <unit> at <tmp> line 1
gfldex I have a usecase that is very DateTime heavy. Any speedup would be very welcome. 10:49
lizmat macros would have been nice here 10:54
I would accept a pull request that would transform those .in-range calls to foo < x < bar || bang! 10:55
gfldex I am at home today but will work the next two days. I will see what I can do.
tbrowder .tell AlexDaniel this is your periodic invitation to kindly review rakudo PR #1339 and its tests in roast PR #371 11:16
yoleaux tbrowder: I'll pass your message to AlexDaniel.
gfldex I got a failing spectest in t/spec/S29-os/system.rakudo.moar 11:29
lizmat reliably or a flapper ? 11:34
gfldex always it seams gist.github.com/anonymous/dc3893e3...09ab81c091 12:35
lizmat gfldex: it doesn't for me on MacOS 12:39
gfldex I didn't touch anything! 12:40
:->
Linux vm-debian-jessie 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux 12:41
MasterDuke gfldex: i set the same output when i run the .moar file directly, but if you make the .t file it shows that it passes because that test is todo'ed 12:51
*get
gfldex odd
MasterDuke what does `make t/spec/S29-os/system.t` do for you? 12:52
gfldex not ok 33 - LAST phaser gets triggered when using -n command line switch # TODO RT 128398 12:54
synopsebot RT#128398 [open]: rt.perl.org/Ticket/Display.html?id=128398 [BUG] LAST does not work with -n in Rakudo
MasterDuke but no 'Result: PASS' at the end? 12:55
gfldex Result: FAIL 12:56
MasterDuke huh
that is odd
gfldex it's a fairly clean VM and rakudo is build as root 12:57
lizmat fwiw, afaik, mine isn't build as root, perhaps that could be it ??
gfldex goes to build rakudo in coward-mode 12:58
Zoffix gfldex: what's the full output of the run? 13:09
yoleaux 4 Jan 2018 16:17Z <tyil> Zoffix: The issue I ran into with zef has a ticket open, in case you're interested in the cause: github.com/ugexe/zef/issues/157
Zoffix huggable: zef no deps :is: Issue with zef reporting empty list of missing deps: github.com/ugexe/zef/issues/157 13:10
huggable Zoffix, Added zef no deps as Issue with zef reporting empty list of missing deps: github.com/ugexe/zef/issues/157
Zoffix gfldex: I mean of `make t/spec/S29-os/system.t` or `t/fudgeandrun t/spec/S29-os/system.t` Your gist doesn't include harness results output 13:11
gfldex as non-root I get different errors. 13:20
lizmat: are you spectesting on a nfs share?
lizmat nope
it's all happening on my MBP with SSD 13:21
gfldex I am: gist.github.com/86940b79472637fcc1...9d3195750b
lizmat perhaps the speed difference of the SSD could be the reason I'm not seeing it ?
gfldex the vm got more then anough RAM to never touch any disk
Zoffix gfldex: what's the output of t/fudgeandrun t/spec/S32-io/io-handle.t t/spec/S32-io/io-cathandle.t t/spec/S32-io/open.t ? 13:22
gfldex All tests successful. 13:23
Zoffix :S
gfldex that's as root on non-nfs
Geth rakudo: 36d71a39e8 | (Elizabeth Mattijsen)++ | src/core/DateTime.pm
Make DateTime creation about 1.6x as fast

  - using Positional interface, possibly less pronounced with other inputs
  - if possible, don't use Range.in-range tests for testing whether in range
  - put leap-second check in separate private method
   - this should increase the chance of new-from-positional to be inlined
  - don't use attribute binding in the signature of SET-SELF
... (6 more lines)
lizmat gfldex: ^^^
gfldex lizmat: tyvm 13:24
Zoffix no idea then
gfldex that's as non-root on non-nfs gist.github.com/anonymous/771af6f1...4aa404c3c0 13:47
making assumptions about /dev/pts/0 can be tricky
rakudo doesn't like it if you `su -l username` it seams 13:48
timotimo lizmat: huh, there must be some way to make binding to private attributes fast in signatures ... 13:51
lizmat timotimo: probably :-) 13:53
perhaps there was something else going on
it was just empirically faster that way
gfldex buildin rakudo and spectesting in boring-mode works without FAILs 13:57
Geth roast: 49ba4076fa | (Zoffix Znet)++ | 2 files
Rephrase .t tests

Check .open on TTY succeeds as well, as it fails on some systems:
  irclog.perlgeek.de/perl6-dev/2018-...i_15654787
lizmat afk& 14:09
7JTAC9F9L Rakudo build failed. Elizabeth Mattijsen 'Make DateTime creation about 1.6x as fast 14:25
travis-ci.org/rakudo/rakudo/builds/325440142 github.com/rakudo/rakudo/compare/9...d71a39e813
Geth rakudo/master: 6 commits pushed by (Itsuki Toyota)++, (Zoffix Znet)++ 14:33
roast: e1aeb1d690 | (Itsuki Toyota)++ | S32-temporal/Date.t
Make sure Date.new(Int, 1, 1) dies

Fixes: rt.perl.org/Public/Bug/Display.html?id=127016
roast: 287d65038e | (Itsuki Toyota)++ | S32-temporal/Date.t
Make sure both Date.new(2010, 12/2, 3) and Date.new('2018', '1', '4') live

Fixes RT#127016: rt.perl.org/Public/Bug/Display.html?id=127016
This fix is a characterization test to make sure it doesn't break the previous behavior.
synopsebot RT#127016 [new]: rt.perl.org/Ticket/Display.html?id=127016 [LHF][BUG] Date can have undefined year
roast: 1ec04ae356 | (Zoffix Znet)++ (committed using GitHub Web editor) | S32-temporal/Date.t
Merge pull request #374 from titsuki/fix-date-new

Fix RT#127016
rakudo: 8023d21293 | (Zoffix Znet)++ | 2 files
Remove automated release guide

The described process is no longer in use.		 14:47
gfldex t/spec/S29-os/system.rakudo.moar doesn't like to run as root, nfs is not involved in the FAILs I got 14:56
Zoffix gfldex: that's just a bad test. It's using wrong perl6 15:17
gfldex lizmat: I told andrewshitov that his blog made Rakudo faster. :) 15:30
Zoffix g2g, but will look into it tonight. Filed the problem as S#375 15:39
synopsebot S#375 [open]: github.com/perl6/roast/issues/375 Broken tests in S29-os/system.t
Zoffix |8h S#375
ZofBot Zoffix, Will remind you on 2018-01-05T18:39:20.483077-05:00 about S#375
travis-ci Rakudo build failed. Zoffix Znet 'Disallow :U values in DateTime.new 15:53
travis-ci.org/rakudo/rakudo/builds/325464363 github.com/rakudo/rakudo/compare/3...8b1ea76016
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. Across all jobs, 2 unique test files failed.
travis-ci Rakudo build failed. Zoffix Znet 'Remove automated release guide 17:08
travis-ci.org/rakudo/rakudo/builds/325468886 github.com/rakudo/rakudo/compare/0...23d2129317
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. Across all jobs, only t/02-rakudo/08-slangs.t test file failed.
Zoffix pinged travisci-status on twitter about ^these
Geth roast: 420b3365f1 | (Zoffix Znet)++ | S29-os/system.t
Fix run/shell :cwd/:ENV tests

Fixes github.com/perl6/roast/issues/375		 17:11
Zoffix gfldex: all test failrues you reported today should be fixed. ^ that fixes S29-os/system and earlier commit fixed the io-*handle failures 17:12
gfldex Zoffix++ 17:16
Geth rakudo: 7a4743be31 | (Moritz Lenz)++ | src/core/Proc.pm
#1366: introduce Proc!set-status

the plan is to deprecate the public candidate that sets the status		 21:14
AlexDaniel greppable6: status\( 22:08
greppable6 AlexDaniel, gist.github.com/7a5cfd4dc52192dc82...358ab9c336
AlexDaniel greppable6: \.status\(
greppable6 AlexDaniel, gist.github.com/81a59c392e219e4b17...f217214aee
lizmat m: my $a = 42; for ^1000000 { my $b = 42 < $a < 666 }; say now - INIT now 22:15
camelia 0.54265194
lizmat m: my $a = 42; for ^1000000 { my $b = 42 < $a && $a < 666 }; say now - INIT now
camelia 0.2490039
lizmat somehow I would think performance of these two constructs should be closer to each other ? 22:16
Geth rakudo: 5571d7f72b | (Zoffix Znet)++ | 2 files
Make unit-scope sub error message less presice

Per github.com/rakudo/rakudo/issues/13...-355645824		 22:21
jnthn lizmat: In theory the first could be faster, even 22:30
lizmat yes, so I'm a bit disappointed :-) 22:31
jnthn: should I make an issue ?
jnthn Could do 22:32
lizmat GH #1368 22:37
github.com/rakudo/rakudo/issues/1368
Geth rakudo: b7170f835f | (Elizabeth Mattijsen)++ | src/core/Date.pm
Make Date.new about 1.6x faster

  - just like with DateTime.new earlier today
  - JITting *is* taking place here, so not sure what the difference is
  - replacing 1 <= $a <= 12 by 1 <= $a && $a <= 12 would make it 30% faster still
   - but am not sure that's a currently botched optimization in Moar or not
   - so keeping the code like this for now
   - see GH #1368
  - also, did not change self === Date to nqp::istype(self.WHAT,Date)
   - because the effect was only about 0.5%, so maybe for later		 22:39
synopsebot RAKUDO#1368 [open]: github.com/rakudo/rakudo/issues/1368 "42 < $a < 666" should be faster than "42 < $a && $a < 666", but is 2x as slow
jnthn fwiw, I suspect it'll be something in Perl6::Optimizer's handling of chaining 22:42
timotimo yeah, it has some code for chaining 22:43
i never really tried to understand how the chain depth handling works, someone recently found a bug in it, i think?
probably the zoff
jnthn As I remember it, it was a bail-out to avoid mis-optimization 22:46
Zoffix Yeah, there was some sort of a bug, but the chained version is deliberatelly not constant folded, so that's why the slowdown in the issue 22:55
Or rather, why the C1 < C2 && C2 < C3 is faster
deliberately == when I was fixing the bug I know there was code that checked for chain == 2; don't know the reason why 22:56
m: my $a = 42; for ^1000000 { my $b = rand < $a < rand }; say now - INIT now
camelia 1.21604896
Geth roast: b534478149 | (Elizabeth Mattijsen)++ | S32-exceptions/misc.t
Fix OutOfRange test that is too specific
Zoffix m: my $a = 42; for ^1000000 { my $b = rand < $a && $a < rand }; say now - INIT now 22:57
camelia 1.031527
Zoffix m: my $a = ½; for ^1000000 { my $b = rand < $a && $a < rand }; say now - INIT now
camelia 1.03467780
Zoffix m: my $a = ½; for ^1000000 { my $b = rand < $a < rand }; say now - INIT now
camelia 1.1789591
Zoffix m: my $a = rand; for ^1000000 { my $b = rand < $a < rand }; say now - INIT now
camelia 0.75051262
Zoffix m: my $a = rand; for ^1000000 { my $b = rand < $a && $a < rand }; say now - INIT now
camelia 0.38909410
Zoffix ok, so then it's more than just constant folding bit
jnthn I wonder if they're being emitted as calls rather than static calls 22:59
Zoffix looks like it yeah
jnthn The latter is an opt where we promise it won't change or have closure variants, 'cus it comes from the setting
It used to be the case that only static calls could be inlined 23:00
Since last summer's spesh work, that's not the case
However, it's a guard less
And a lookup by name less
In otherwise tight code, those could add up a lot 23:01
Zoffix Gonna give it a go and try to make it static sometime this weekend, unless someone beats me :) 23:02
Geth rakudo: f719a471db | (Elizabeth Mattijsen)++ | src/core/Match.pm
Make sure we don't interpolate hashes

  - fixes GH #1367
  - this cannot be a compile time test only
   - it also needs to be able to handle: my $h := { a => "b" }; say "b" ~~ / $h /
  - a compile time test for %-sigilled vars could be appropriate
   - then again, it could produce false positives		 23:08
synopsebot RAKUDO#1367 [open]: github.com/rakudo/rakudo/issues/1367 Using a hash variable in a regex should give a better error message
travis-ci Rakudo build failed. Moritz Lenz '#1366: introduce Proc!set-status 23:09
travis-ci.org/rakudo/rakudo/builds/325613262 github.com/rakudo/rakudo/compare/8...4743be31a5
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. Across all jobs, 2 unique test files failed.
Geth rakudo: 00797d07ef | (Elizabeth Mattijsen)++ | src/core/Match.pm
Don't allocate a nqp::list if it's not necessary
 23:22

Powered by Cro and the Raku® Programming Language.

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

Thank you!