Zoffix 🍝 04:02
yoleaux 19 Nov 2017 09:21Z <ufobat_> Zoffix: I've updated the PR github.com/rakudo/rakudo/pull/1249 with your suggestions
[Tux] Rakudo version 2017.10-215-g85105077a - MoarVM version 2017.10-86-g89fae17a6
csv-ip5xs1.108 - 1.126
csv-ip5xs-2013.005 - 13.118
csv-parser12.521 - 12.616
csv-test-xs-200.419 - 0.433
test12.173 - 13.059
test-t3.237 - 3.263
test-t --race1.374 - 1.441
test-t-2059.445 - 60.790
test-t-20 --race20.287 - 20.754
06:58
Retry was better, 07:09
Rakudo version 2017.10-215-g85105077a - MoarVM version 2017.10-86-g89fae17a6
masak wait, you're allowed to re-run the perf test if it looks slow? :P 07:14
this changes everything!
[Tux] masak, if I see a (big) change, I run it a second (actually a third and forth run as it already runs twice per test) to check if it was not influenced by heavy load 07:33
I do this when I see a change both upwards and downwards
masak :) 07:34
[Tux] off to work
nine I always take downward jumps at face value. Because there's just no spurious event that could make a program run too fast. If anything the lowest runtime reflects the actual resource usage of a program best. 07:37
yoleaux 19 Nov 2017 22:13Z <geekosaur> nine: [19 21:36:17] <Brumbazz> Hi guys. I'm using AnyEvent-XMPP(perl5) in my perl6 project. So far I don't get any errors during compilation when I run my script, however after it print's some text is crashed with a "[2] 708 segmentation fault perl6 xmpp_who_am_i.pl"
masak during the weekend I got `macro infix:<ff>` to work primitively in 007. this is a significant step up from what Rakudo currently supports. I'm hopeful I'll be able to land this in 007's master branch soon. 07:41
nine masak: sounds like it would get us closer to a LINQ like sublanguage implemented as macros? 07:50
Geth roast: 05c0fd8365 | (Samantha McVey)++ | S15-unicode-information/uniprop.t
uniprop: Add tests for every General Category

Tests to close rakudo/rakudo#1254
08:07
synopsebot RAKUDO#1254 [closed]: github.com/rakudo/rakudo/issues/1254 [regression][testneeded][UNI][⚠ blocker ⚠] Incorrect General_Category property for ascii-range uppercase letters (say ‘A’.uniprop)
masak nine: quite possibly 08:10
I still don't feel ready to think about all-out slangs for some reason, but I'd like to move into treating 007 expressions as not something that necessarily gets evaluated but the structure gets used for other things 08:11
see github.com/masak/007/issues/268
AlexDaniel timotimo: I guess this doesn't really help? github.com/rakudo/rakudo/issues/12...-345680579 12:23
I no longer see any hopes for GH#1257 fix in this release, so here: github.com/rakudo/rakudo/issues/12...-345723351 15:08
synopsebot GH#1257 [open]: github.com/rakudo/rakudo/issues/1257 [regression][⚠ blocker ⚠] Rakudo 2017.10 fails to build on Debian big endian systems
AlexDaniel please comment if you agree, disagree or whatever
moritz we'd need a CI system on a big endian machine 15:11
AlexDaniel the same ticket talks about some other issue on arm, which may be a little bit easier to fix I think 15:14
but then there's this also: irclog.perlgeek.de/perl6/2017-11-20#i_15472974
Geth nqp/master: 7 commits pushed by pmurias++ 15:20
ilmari when did Geth start including the branch name for commits to the default branch? 15:22
[Coke] probably when the default branch was changed? 15:33
timotimo oh, huh.
[Coke] (on rakudo, I mean. but Iunno)
timotimo nqp has the same problem
or "has that problem"
just last night the reports for both rakudo and nqp didn't have the default branch name 15:37
actually, it was the day before last night
[Coke] ah, good catch 15:56
Geth geth: 6ad5fe6e28 | (Zoffix Znet)++ (committed using GitHub Web editor) | lib/Geth/GitHub/Hooks/Preprocessor.pm6
Fix nqp bump watcher

Fixes #11
16:00
rakudo: 8ccb60e39f | (Zoffix Znet)++ (committed using GitHub Web editor) | .gitignore
Add /*.dll.a to ignore

These get generated on Windows during make test.
16:51
tyil I want to implement the EXISTS-KEY method for Distribution::Resources in Rakudo (used for %?RESOURCES), so I can use :exists and :!exists on it, would anyone with more knowledge have any outright objections as to why this could be unwanted or undoable before I spend time tring to understand it better? 17:28
japhb nine, re "there's just no spurious event that could make a program run too fast" -- that presupposes that the program 1. completed successfully, and 2. gave the correct answer. Failure to detect those two cases has resulted in many bad benchmark results, where faster-but-wrong or faster-but-crashed-partway-through were unnoticed. 17:56
[Coke] I have fallen into that trap before. "my god, this is faster than the thing I ported it from!" "oh, right, because it gave the wrong answer REALLY fast." :) 18:03
ugexe m: say $*VM.desc; # what is this intended to mean? 18:49
camelia 2017-11-20T19:49:10.602511+01:00
ugexe m: say $*VM.desc; # what is this intended to mean?
camelia 2017-11-20T19:49:18.268098+01:00
ugexe here is a timestamp that represents the first time you called .desc ?
AlexDaniel huh… the timestamp is introduced in this commit and there's no explanation: github.com/rakudo/rakudo/commit/db...d772eefc15 18:54
before that commit it was just an unitialized Str 18:55
lizmat . 19:11
yoleaux 19 Nov 2017 15:56Z <AlexDaniel> lizmat: gist.github.com/AlexDaniel/bf7d916...604981b70e
ugexe yea but that was when it was $?VM, which makes sense 19:39
for $*VM, not so much
lizmat tyil: irclog.perlgeek.de/perl6-dev/2017-...i_15474137 can't think of any reason against it 19:41
tyil alright, I'll take a serious look at it :> 20:33
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/11/20/...ia-videos/ 22:28
El_Che ha, I made it to the paper :) 22:36
lizmat :-) 22:38
lizmat feels knackered and goes to bed 22:43
&
El_Che thx lizmat
great job