Kaiepi did i open github.com/MoarVM/MoarVM/issues/794 in the wrong place? 00:30
array_of_scalars Can anybody point me to a URL/paper that keeps tracks of speed/performance changes across the various moarVM/rakudo star releases? 00:46
MasterDuke array_of_scalars: here's one tux.nl/Talks/CSV6/speed4.html 00:49
Kaiepi: i think so. can you recompile your MoarVM with --debug=3 ? 00:51
that should give a more useful backtrace
array_of_scalars MasterDuke: Cheers, that's cool. 00:52
MasterDuke array_of_scalars: we also have ways to run code on previous releases, if you have something in particular you'd like to benchmark 00:53
array_of_scalars MasterDuke: I am trying to make the case to move from a Perl 5 DBI and XML::Parser to the Perl 6 DBIish and XML::Parser::Tiny. Comparative performance between Perl 5 and 6 is of no interest. What is of interest is for me to prove that things are improving. 00:58
MasterDuke they definitely are that 00:59
tbrowder Zoffix: in all my experiments with your code and with the nqp test 111*spawn*t i have NOT been able to capture stderr. something seems to block when trying to simply substitute stderr for stdout. the moarvm underlying code so far has not revealed anything to me but i have just started looking at it to get familiar with mapping of vars and hash keys. i need some smart person to demonstrate capturing stderr! 01:16
AlexDaniel reportable6: 2018-02-05T00:00:00Z 2018-02-12T00:00:00Z 03:20
reportable6 AlexDaniel, OK, working on it! This may take up to 40 seconds
AlexDaniel, gist.github.com/3ac0cdfe3b4eb15c83...a98aec5a9e 03:21
AlexDaniel weekly: gist.github.com/3ac0cdfe3b4eb15c83...a98aec5a9e
notable6 AlexDaniel, Noted!
Zoffix Someone said I should do this week's weekly again. 06:23
lizmat Zoffix: working on it 06:25
almost finished
Zoffix Ah, OK :) 06:26
lizmat you're off the hook :-) 06:27
And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/02/12/...om-apopka/ 06:56
nine lizmat++ # thanks a lot! 07:45
[Tux] Rakudo version 2018.01-185-g00af9ce27 - MoarVM version 2018.01-82-g296620e86
csv-ip5xs0.802 - 0.832
csv-ip5xs-207.567 - 7.795
csv-parser11.630 - 11.975
csv-test-xs-200.429 - 0.457
test9.307 - 9.394
test-t2.586 - 2.635
test-t --race1.082 - 1.085
test-t-2047.881 - 48.521
test-t-20 --race16.549 - 17.365
 08:29
dogbert2_ m: for 1..1000 { $^i %% $_ && put "$_ " for ^$i } 10:42
camelia (signal SEGV)1
1
1
2
1
1
2
3
1
1
2
4
1
3
1
2
5
1
1
2
3
4
6
1
1
2
7
1
3
5
1
2
4
8
1
1
2
3
6
9
1
1
2
4
5
10
1
3 …
dogbert2_ commit: 2018.01 for 1..1000 { $^i %% $_ && put "$_ " for ^$i }
committable6 dogbert2_, ¦2018.01: «1 ␤ «exit signal = SIGSEGV (11)»»
dogbert2_ commit: 2017.12 for 1..1000 { $^i %% $_ && put "$_ " for ^$i }
committable6 dogbert2_, gist.github.com/043319c6ee7aec7c0b...939c5c68dd 10:43
Geth rakudo: 34b3356fda | (Zoffix Znet)++ | 2 files
Make &wanted mark passed node as wanted…

  …if none of the other conditions managed to take care of it.
Looks like some constructs, like macro calls, just wanted() things like QAST::Vars and QAST::WVals, without them wrapped in anything else. We missed those, which resulted in spurious useless use warnings produced.
Fixes R#1512: github.com/rakudo/rakudo/issues/1512		 10:47
synopsebot R#1512 [open]: github.com/rakudo/rakudo/issues/1512 [regression][useless useless] Useless useless use warning in OO::Monitors
roast: d648005e4c | (Zoffix Znet)++ | S12-coercion/coercion-types.t
Revert test for coercers not coercing defaults

There's a problematic case where target isn't a subclass of source, filed as github.com/rakudo/rakudo/issues/1517
So I'm reverting the original fix that made this work, for now.		 12:15
rakudo: e72eb01ed0 | (Zoffix Znet)++ | src/Perl6/Actions.nqp
Revert "Use target type as default default for coercers"

This reverts commit ae697080d2d522552e7fb8d168a1bfd2da127bae.
Needs a bit more cooking, in light of R#1517 github.com/rakudo/rakudo/issues/1517
Fixes R#1519 github.com/rakudo/rakudo/issues/1519
synopsebot R#1517 [open]: github.com/rakudo/rakudo/issues/1517 Type coercion turns optional named argument into required one substantially
synopsebot R#1519 [open]: github.com/rakudo/rakudo/issues/1519 [⚠ blocker ⚠] Recent coercer work blows up in fast-path binder: "Internal error: inconsistent bind result"
nqp: tbrowder++ created pull request #408:
add a test for pod panic, but stderr is blocking		 12:30
tbrowder ref my nqp PR #408, could stderr hanging on spawnasync be symptomatic of other problems? i don’t see any existing tests for capturing stderr. 12:36
i just added a new issue for nqp::spawnprocasync not testing stderr or merge capture. 12:46
is the problem that each output stream needs its own buffer? 12:47
*buffer for capture? investigating that avenue... 12:48
don’t think so, unique seq num per read i think... 12:56
trying to understand func spawn_permit in moarvm io procops.c 13:14
jnthn stdout and stderr are separate streams with their own sequence numbers 13:33
Zoffix buggable: toast 13:41
buggable Zoffix, Between 2018.01-187-ge72eb01 and 2018.01: 21 (2.14%) modules got burnt; 25 (2.55%) got unsucced; 278 (28.34%) out of 981 modules appear unusable. See toast.perl6.party/ for details.
Zoffix Ran a toast, though log showed it exited with signal 11 (so that's a SEGV in the runner?)
Also, I didn't re-run 2018.01 release, so it's possible the modules got broken by new commits to their source since the 2018.01-121-g0bf735a run 13:42
tbrowder jnthn: is the $seq number the 1 or 2 for fd for stdout stderr? 13:46
Zoffix Bunch of "could not open file", like Failed to open file /home/cpan/.zef/store/JSON-Fast-0.9.9.tar.gz/JSON-Fast-0.9.9/META6.json: No such file or directory 13:48
and a bunch of stuff about sockets
And Malformed UTF-8 in LWP::Simple 13:49
(which is used by a bunch of modules)
jnthn tbrowder: It's just an incrementing number per buffer emitted
tbrowder jnthn: ok, can the two streams share the same buffer for capture or do they each need their own buffer? 13:51
Zoffix I think I'll clean the VM, build 2018.01 to use for the runner and then re-toast 2018.01 + master.
jnthn tbrowder: merge, in theory, will put them into a single buffer 13:53
If you put callbacks for stdout and stderr bytes, then you get two streams
tbrowder right now the config hash for spawnprocasync only show one ‘buffer’ to be used for either or both streams.
jnthn Oh
buffer is just the type to use 13:54
tbrowder *shows
jnthn I thought you were talking about the callbacks, sorry
Note that buffer is used purely for its type
Data is *not* put into that
It's delivered via the callbacks 13:55
tbrowder ok, then the current practice of passing the one buffer for the queue should be good. 13:56
jnthn Yeah, maybe having called it buffer_type woulda been better :)
tbrowder any idea of why reading from stderr is causing a hang? 13:57
jnthn There is no "read from" so far as spawnprocasync goes, it pushes stuff out as its available 13:58
So that'd be a problem in how it's being utilized
Well, unless the stream isn't being given a permit, perhaps
In which case it won't start the reader
tbrowder can you look at nqp PR #408? and see if that has a problem or is it deeper in the permit code. i see there the stderr piggy backs with stdout. 14:00
at least for merge.
jnthn Sorry, had to take care of soemthing else. Will look in a minute. 14:08
tbrowder thnx! 14:12
jnthn tbrowder: Which test is unhappy? 14:15
Maybe spotted the issue 14:16
Left a comment
tbrowder oh, the 005-pod-panic.t is to show the problem. if you run it by itself it hangs on the third call.
thanks! 14:17
jnthn ah, 3rd call matches the problem I mentioned :)
tbrowder jnthn: almost fixed, using channel 1 for stdout only works fine, channel 2 for stderr works fine, channel 0 for both (merge) runs but i get “unreadable output”. 14:58
i got the channel 0 from reading procops.c for the merge case 14:59
jnthn tbrowder: What does "unreadable output" mean? :) 15:05
tbrowder the channel references are for nqp::permit 15:07
that’s the error message from the regex test on output from using nqp::permit channel 0 for the merged capture 15:11
sorry, the msg is “cannot stringify this”... 15:15
jnthn ah, that one probably is just trying to use something as a string that isn't one (and can't turn into one, which most things in NQP cannot) 15:16
tbrowder ok, i think i’m confusing you with my errors now. i think i’m on the right track and i’ll tighten up the testing. but one question: is it correct that nqp::permit channel 0 is for the nerge 15:24
*merge_bytes output?
jnthn tbrowder: Yes, that seems to match what Proc::Async does too 15:25
tbrowder ok, thank you very much, and good hunting with the grant!
AlexDaniel notable6: weekly 15:26
notable6 AlexDaniel, 6 notes: gist.github.com/e2ddbb2b25b0f64835...7f969633ee
AlexDaniel notable6: clear weekly
notable6 AlexDaniel, Moved existing notes to “weekly_2018-02-12T15:26:28Z”
AlexDaniel “I have applied for a Perl6 core grant to deal with this documentation” 15:27
:O
I hope there are funds for that
tyil applying is always possible afaik 15:28
funds or no
AlexDaniel I mean, I hope it will be funded :)
tyil same
I find Perl 6 docs to be pretty good already for the most part 15:29
but making it even better is never a bad thing
AlexDaniel tyil: judging by the amount of issues and its dynamics, I don't think the docs are good enough :) 15:33
look here for example
github.com/rakudo/rakudo/wiki/Mont...Squash-Day
280 → 294 → 304
tyil there's always room for improvement, but as a casual user of Perl 6 I am much more happy with the Perl 6 docs than I was with the Rust docs when I was trying that out 15:34
AlexDaniel right now we have 291, which I guess is the result of JJ's work
Zoffix buggable: toast 16:21
buggable Zoffix, Between 2018.01-187-ge72eb01 and 2018.01: 8 (0.82%) modules got burnt; 12 (1.22%) got unsucced; 255 (25.99%) out of 981 modules appear unusable. See toast.perl6.party/ for details.
Zoffix k, much more polished toast results now.
tyil hmm 16:22
Zoffix AlexDaniel: SQUASHathon idea: ^ making those 255 failing modules work again.... Possibly sorted by how recently the author was active on GitHub
tyil can I see the list of modules that are failing rn, so I can see if any of my modules are breaking?
Zoffix Still seeing the "Malformed UTF-8 at line 8 col 12678" from LWP::Simple 16:23
AlexDaniel note: squashathon making those 255 failing modules work again irclog.perlgeek.de/perl6-dev/2018-...i_15809006
notable6 AlexDaniel, Noted!
Zoffix tyil: the bot did include the link
tyil oh
I should learn to read
AlexDaniel Zoffix: IIRC it fetches a web page that indeed has malformed utf8 lol
Zoffix AlexDaniel: but why does it pass on 2018.01? 16:24
AlexDaniel it's different every run
Zoffix eco: LWP::Simple 16:25
buggable Zoffix, LWP::Simple 'LWP::Simple quick & dirty implementation for Rakudo Perl 6': github.com/perl6/perl6-lwp-simple
Zoffix It's a perl6 org's module. We could fix that...
AlexDaniel this issue: github.com/perl6/perl6-lwp-simple/issues/13
Zoffix bisect: old=2018.01,new=HEAD try ｢sub func(Numeric(Rat) $v?) { dd $v; 42 }()｣.EVAL; die "meow" if $!; 16:28
bisectable6 Zoffix, On both starting points (old=2018.01 new=e72eb01) the exit code is 0 and the output is identical as well
Zoffix, Output on both points: «Rat␤»
Zoffix bisect: old=2018.01,new=HEAD~10 try ｢sub func(Numeric(Rat) $v?) { dd $v; 42 }()｣.EVAL; die "meow" if $!;
bisectable6 Zoffix, Bisecting by exit code (old=2018.01 new=HEAD~10). Old exit code: 0
Zoffix, bisect log: gist.github.com/61cfe6c0d4cc6712cf...b7eb148d1a
Zoffix, There are 5 candidates for the first “new” revision. See the log for more details
Zoffix AlexDaniel: also, why does it saw "5 candidates" blah blah, when it was just a single commit that made the change. Is it because the commit was made on post-release branch that was later merged? 16:29
s/saw/say/;
AlexDaniel c: 426a39a6ef867f8ef7378a11482f18aca842c33d try ｢sub func(Numeric(Rat) $v?) { dd $v; 42 }()｣.EVAL; die "meow" if $!;
committable6 AlexDaniel, ¦426a39a: «Cannot test this commit (Commit exists, but a perl6 executable could not be built for it)»
AlexDaniel let's try rebuilding this to see if it helps…
c: 426a39a6ef867f8ef7378a11482f18aca842c33d try ｢sub func(Numeric(Rat) $v?) { dd $v; 42 }()｣.EVAL; die "meow" if $!; 16:30
committable6 AlexDaniel, ¦426a39a: «No build for this commit»
AlexDaniel k, will try again in a few minutes once it's done 16:31
Zoffix: typically it means that someone has split his work into several commits in a way that makes it impossible to build rakudo on these intermediate commits. Sometimes this is because of nqp bumps (rakudo changed first to depend on something in nqp, but nqp is bumped later) 16:32
there's a chance that it just failed for some random reason, which is why I'm deleting the build to let it try again 16:33
s/his/their/
Zoffix Ah, OK.
AlexDaniel c: 426a39a6ef867f8ef7378a11482f18aca842c33d try ｢sub func(Numeric(Rat) $v?) { dd $v; 42 }()｣.EVAL; die "meow" if $!; 16:34
committable6 AlexDaniel, ¦426a39a: «Cannot test this commit (Commit exists, but a perl6 executable could not be built for it)»
Zoffix ok, whatever.
AlexDaniel yea, can't do that. We can take a look at the log actually
shareable6: 426a39a6ef867f8ef7378a11482f18aca842c33d
shareable6 AlexDaniel, /426a39a6ef867f8ef7378a11482f18aca842c33d
AlexDaniel …
Zoffix Just wanted to make sure it's not that all post-release branch commits are unbisectable. 16:35
AlexDaniel no that's not a problem at all. In theory post-release commits should be bisectable even when post-release is not even merged yet
Zoffix cool
AlexDaniel but I haven't tried that in a while so maybe that doesn't work entirely
shareable6: 426a39a6ef867f8ef7378a11482f18aca842c33d 16:37
shareable6 AlexDaniel, whateverable.6lang.org/426a39a6ef8...aca842c33d
AlexDaniel Zoffix: just FYI, these archives contain log files from running `make`, so here's the reason: gist.github.com/AlexDaniel/833671a...931e60d57d 16:38
Zoffix Oh, OK :) 16:44
(this is the "forgot to bump NQP" case)
AlexDaniel whateverable++ then for being correct consistently 16:51
… and whateverable-- for not being able to look through the commits and use its intellect to understand what actually happened 16:52
:P
jnthn++ # oh my god that sounds so great 17:18
(fixes for memory “leaks”)
jnthn There was a real leak too 17:19
But mismanagement can be as troublesome as a leak
timotimo a leak by any other name ... 17:22
jnthn valgrind: the 'impossible' happened: LibVEX called failure_exit(). 17:23
...oops :)
japhb I'm always impressed by corruption that manages to blow up the tooling used to investigate corruption 18:25
It's like bringing a canary into a coal mine and having it explode.
Can we bump after jnthn++'s last two MoarVM fixes? 18:26
AlexDaniel is wondering that as well 18:27
[Coke] if we're early in the month, bump early & often.
japhb [Coke]: ~1 week to release, I think 18:28
[Coke] (once a day after jnthn goes on a tear seems like a good frequency. :)
japhb Should be early enough to make sure his fixes get some serious wearing-in time
[Coke] I assume since those hit master he's intending for them to be in the moar release; but one more day wouldn't hurt.
Geth nqp: 51b9df0a89 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 6 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...gc6519f4c3 c6519f4c3 Clean up one-shot timers after firing cf523c89c Test the current thread's frame in heap snapshot 004680a03 Don't spesh log if we have a spesh_cand da41e397f Implement unmanaged_size in MVMSpeshLog repr 48d98a183 Merge pull request #801 from wukgdu/fix_format c27af6a54 fix format string's parameters		 18:45
AlexDaniel well, let's see :)
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...gc6519f4c3
rakudo: d74dac816a | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 6 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....g51b9df0a8 51b9df0a8 [MoarVM Bump] Brings 6 commits 135154876 [js] eslint --fix 48dcb3f30 [js] Start taking grapheme boundaries into account more fc524076c [js] Make enumcharlist work better with graphemes 4c8ea814c [js] Strip marks more correctly in weird cases 9d664e6d6 [js] Scan in regexes by graphemes not by bytes
rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....g51b9df0a8
c83202db0a | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION

This reverts commit d74dac816a73e0da18860389136e3c7f06f93a9e.
Just to unbreak it for anyone who is relying on HEAD too much. See
travis-ci NQP build failed. Aleks-Daniel Jakimenko-Aleksejev '[MoarVM Bump] Brings 6 commits 19:04
travis-ci.org/perl6/nqp/builds/340623204 github.com/perl6/nqp/compare/13515...b9df0a8925
AlexDaniel I guess that was not a great idea! :) 19:11
hmm… but no complaints about rakudo repo 19:12
AlexDaniel looks
heh, segfault 19:13
yea, that was a mistake, should've looked at Moar's CI status 19:18
timotimo aye, a fix to spesh has caused more stuff to be considered by the expr jit, making many workloads fail much sooner than they otherwise would have 19:19
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....0-g2c51764
AlexDaniel ……… see #1520 of course…
yea, don't start lines in your commit message with “#” 19:22
timotimo :D 19:23
travis-ci Rakudo build failed. Aleks-Daniel Jakimenko-Aleksejev '[NQP Bump] Brings 6 commits 19:31
travis-ci.org/rakudo/rakudo/builds/340623280 github.com/rakudo/rakudo/compare/e...4dac816a73
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
travis-ci Rakudo build failed. Aleks-Daniel Jakimenko-Aleksejev 'Revert "[NQP Bump] Brings 6 commits" 20:12
travis-ci.org/rakudo/rakudo/builds/340637658 github.com/rakudo/rakudo/compare/d...3202db0a67
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
Geth nqp: 4c93027640 | (Tom Browder)++ (committed using GitHub Web editor) | docs/ops.markdown
correct return values for ```decoderempty```, they were reversed
 22:15
travis-ci NQP build failed. Tom Browder 'correct return values for ```decoderempty```, they were reversed' 22:30
travis-ci.org/perl6/nqp/builds/340710537 github.com/perl6/nqp/compare/51b9d...9302764027

Powered by Cro and the Raku® Programming Language.

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

Thank you!