lizmat llfourn: fwiw, I *have* Inline::Perl5 installed, but didn't notice: I guess it assumed Inline::Perl5 was simply not installed 06:09
Files=1217, Tests=67446, 227 wallclock secs (13.65 usr 4.81 sys + 1386.70 cusr 139.25 csys = 1544.41 CPU)
[Tux] This is Rakudo version 2017.07-77-g5d89cef9f built on MoarVM version 2017.07-15-g0729f841 06:52
csv-ip5xs 2.581
test 12.294
test-t 4.088 - 4.108
csv-parser 11.806
Geth rakudo: cono++ created pull request #1123:
Add myself to CREDITS		 07:18
rakudo/nom: 59e5564629 | cono++ | CREDITS
Add myself to CREDITS

07:12 <+yoleaux> 12 Jun 2017 19:38Z <eveo> cono: you should add yourself to CREDITS file: github.com/rakudo/rakudo/blob/nom/CREDITS		 07:19
rakudo/nom: 99375e4aad | niner++ (committed using GitHub Web editor) | CREDITS
Merge pull request #1123 from cono/nom

Add myself to CREDITS
rakudo/nom: 1a74a8c345 | (Samantha McVey)++ | src/core/array_slice.pm
Improve error for [ ] called with a type object

Previous error was difficult to understand, and doesn't use the same terminology we use for other error messages.		 07:23
lizmat .ask jnthn any thoughts on the performance difference between "1".match(/1/) and 1.match(/1/) ? ( easily seen in a for ^10000) 08:09
yoleaux lizmat: I'll pass your message to jnthn.
lizmat the latter being 7x slower 08:18
meeting& 08:37
jnthn 7x is odd; I'd expect it to have to coerce to Str which would cost something 08:53
travis-ci Rakudo build failed. Samantha McVey 'Improve error for [ ] called with a type object 08:54
travis-ci.org/rakudo/rakudo/builds/258037213 github.com/rakudo/rakudo/compare/9...74a8c3458a
buggable [travis build above] ? Did not recognize some failures. Check results manually. 08:55
Geth nqp/async-await-continuations: 8e5e3376d2 | pmurias++ | 3 files
[js] Tweak code emitting

With async/await disabled we should get the same code that we had before it was added.		 09:11
perl6-lwp-simple: Tickles-BV++ created pull request #19:
Fix put requests and add unit test for it.		 12:34
mr_ron .ask jnthn (or samcv) WRT RT #131774 - jnthn mentions on IRC that repeated string concatenation is O(n ** 2) because strings are immutable. But we have ropes/(strands) as a possible underling representation. Node JS (V8 engine) seems to use ropes to get around the problem. Might that fix it for us at some point? irclog.perlgeek.de/perl6/2015-12-15#i_11720228 rt.perl.org/Ticket/ 13:15
yoleaux 21 Jul 2017 02:02Z <MasterDuke> mr_ron: i've found heaptrack (github.com/KDE/heaptrack) very useful for collecting and visualizing memory metrics
mr_ron: I'll pass your message to jnthn.
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131774
mr_ron Display.html?id=131774
Geth perl6-lwp-simple: 4cfe68dfbb | (Tickles BV)++ | lib/LWP/Simple.pm
Bugfix: Updated put request method to use 'RequestType::PUT' instead of 'RequestType::Delete' so request_shell uses the right method.
 13:24
perl6-lwp-simple: 05a5477003 | (Tickles BV)++ | t/put-request.t
Enhancement: Added put request unit test. This uses httpbin.org for testing and is based on the get and post requests that do the same.
perl6-lwp-simple: 75d58b4bf2 | (Zoffix Znet)++ (committed using GitHub Web editor) | 2 files
Merge pull request #19 from Tickles-BV/master

Fix put requests and add unit test for it.
perl6-lwp-simple: bae9ddcae9 | (Zoffix Znet)++ | 2 files
Bump version
 13:25
jnthn Strands are basically a restricted form of ropes where you just have a single level, and there's an upper bound on how long the stand array can get before it collapses them 13:26
yoleaux 13:15Z <mr_ron> jnthn: (or samcv) WRT RT #131774 - jnthn mentions on IRC that repeated string concatenation is O(n ** 2) because strings are immutable. But we have ropes/(strands) as a possible underling representation. Node JS (V8 engine) seems to use ropes to get around the problem. Might that fix it for us at some point? irclog.perlgeek.de/perl6/2015-12-15#i_11720228 rt.perl.org/Ticket/
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131774
jnthn They avoid copying when making substrings, and avoid or delay the work needing doing with concatenation.
mr_ron Wouldn't delaying the work needed for concatenation allow for better than O(n ** 2) in RT #131774 and the IRC example from llfourn? 13:28
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131774
jnthn The No 13:29
*No
It just lowers the constant factor
However
mr_ron It appears to work for Node JS ...
jnthn If you were to do a scheme like
Once the first strand's length is greatly more than the sum of the rest, then leave it alone and collapse the rest into a second strand 13:30
Then it'd probably avoid a good amount of the copying 13:31
Maybe Node.js actually have ropes for real?
mr_ron gist.github.com/ronaldxs/10f3794b7...cde72c5e8e
jnthn Also we could cheat pretty hard at this benchmark and do no copying at all 13:32
And just bump the repetition count
Which would be great for an artificial benchmark
But about useless for the real world :P
As for the memory use growth, I suspect that's just a lack of GC pressure being applied 13:34
mr_ron If it is ok - I will write up what I learned including this discussion on the ticket and we can go from there. Java seems to gone around this problem with StringBuffer/StringBuilder classes and Python 2.7 cheated by making strings mutable for concat when the reference count was 1.
jnthn For Perl 6, just make an array and join it is the best bet really 13:35
mr_ron thanks
jnthn We can do various tricks (and I'm sure we will) to make concat faster, I'm sure.
'cus people will write code like that anyway 13:36
pmurias aren't strands supposed to make the concat faster but just for smaller numbers of things?
jnthn pmurias: Well, they make it faster in general than just doing all of the copies would be. 13:37
mr_ron while this discussion is ongoing - are native str also immutable as claimed in S02 and if so why would they be so much faster? 13:53
jnthn They are indeed immutable 13:54
Faster because they don't have box/unbox overhead
Str is a P6opague that points to a str 13:55
*opaque
mr_ron m: for (150_000, 300_000) -> $limit {my str $x; my str $y = "x" x 100; $x ~= $y for (1..$limit); say "$limit: ", now - ENTER now} 13:58
camelia 150000: 0.14992304?300000: 0.26772330?
mr_ron m: for (25_000, 50_000) -> $limit {my Str $x; my str $y = "x" x 100; $x ~= $y for (1..$limit); say "$limit: ", now - ENTER now}
camelia 25000: 0.0428633?50000: 0.05416075?
mr_ron m: for (25_000, 50_000) -> $limit {my Str $x; my Str $y = "x" x 100; $x ~= $y for (1..$limit); say "$limit: ", now - ENTER now}
camelia 25000: 0.93613433?50000: 3.6073818? 13:59
mr_ron m: for (300_000, 900_000) -> $limit {my str $x; my str $y = "x" x 100; $x ~= $y for (1..$limit); say "$limit: ", now - ENTER now} 14:00
camelia 300000: 0.29287224?900000: 0.94590595?
mr_ron native str looks O(n)
jnthn Maybe it is somehow hitting the "just increase the repetition count" case 14:01
But I dunno why the boxed case would not 14:03
mr_ron I'll throw that on the ticket in the next few days. thanks ...
jnthn I wonder if there's a difference in whether the "x" x 100 gets constant folded or not?
mr_ron You mentioned that memory growth might be lack of GC pressure. If I ulimit -v 3072000 I het MoarVM panic: memory allocation failed ... Don't know if that is what you meant ... 14:10
jnthn Just meant that the GC isn't being told there's objects with large internal buffers being created, so it should run more often 14:12
mr_ron thank you 14:13
timotimo github.com/MoarVM/MoarVM/commit/bb...6d54f7b9fd - mr_ron 15:03
Geth nqp: 39f1133065 | (Jonathan Worthington)++ | tools/build/MOAR_REVISION
Bump MOAR_REVISION.
 15:42
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...3-g6941cad
lizmat . 15:56
mr_ron If I try to build rakudobrew build moar-blead it fails with failure like:
src/vm/moar/ops/perl6_ops.c: In function ‘p6finddispatcher’:
src/vm/moar/ops/perl6_ops.c:590:38: error: ‘MVMFrame’ has no member named ‘special_return’
lizmat jnthn: the 7x slower is probably because: a. the method lookup isn't getting cached, and find_best_dispatchee is called over and over again 15:58
and b. Str.splice has *many* candidates
Geth rakudo/nom: 4561c2696c | (Jonathan Worthington)++ | 2 files
Follow MoarVM frame changes.
 16:02
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....3-g39f1133
48ce47e6fa | (Jonathan Worthington)++ | 2 files
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....3-g39f1133
9658dd98c9 | (Jonathan Worthington)++ | tools/build/NQP_REVISION

This brings in some major changes to MoarVM. Of note:
  * Specialization and JIT compilation now take place on a background
   thread. The entire way data is collected and analyzed has been
   changed. Also, it plays less fast and loose with aliasing. The
... (29 more lines)
¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....3-g39f1133
jnthn heartily recommends reading that commit message 16:03
lizmat does, pulls, builds and runs a spectest
jnthn No regressions here, and for the first time probably ever spectest actually passes with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 (or at least, did a day or so ago). 16:05
lizmat jnthn++ # excellent reading
jnthn Those two flags btw are the spesh "stress test"
For those working on rakudo/nqp, MVM_SPESH_BLOCKING=1 is the new flag to know about
It forces threads to wait after they have submitted spesh log data for the specializer to do its thing 16:06
Effectively giving you back synchronous working
Which is much better when bug hunting
lizmat jnthn: fwiw, test-t is a bit slower now 16:07
jnthn Remind what test-t is again?
*me
lizmat the Text::CSV test of tuc 16:08
tux
our canary :-)
jnthn Oh, right :)
Zoffix huggable: csv
huggable Zoffix, github.com/Tux/CSV (see `bench csv` for how to run bench)
Zoffix huggable: bench csv
huggable Zoffix, export PATH=`pwd`/install/bin:$PATH; cd CSV; for i in $(seq 1 10000); do echo 'hello,","," ",world,"!"'; done > /tmp/hello.csv; time perl6 -Ilib -MText::CSV test-t.pl </tmp/hello.csv
jnthn I was like, what does that makefile target do :P
Yeah, as noted, there will be some things that lose out in the immediate aftermath of this merge
But if I held back merging until I thought I'd nailed them all then (a) this big set of changes would get less testing prior to release, and (b) I'd probably not know about some of the cases that need most attention 16:09
lizmat yeah, understandable... :-) 16:11
jnthn: also, looks like the spectest became quite a bit slower as well 16:13
just fyi for you and everybody else :) 16:14
jnthn Yeah, that I see also; it seems notably the biggest sufferer. I do wonder if it's that the optimal number of tests to run at once may have shifted
(Due to each MoarVM instances now having a second thread)
lizmat ah so maybe I need to play with TEST_JOBS= 16:15
hmmm
jnthn Yeah; I didn't have chance to do that yet 16:16
lizmat normally I run with =8, now with =7
jnthn had 16
|Tux| This is Rakudo version 2017.07-83-g9658dd98c built on MoarVM version 2017.07-243-g6941cada 16:20
csv-ip5xs 2.537
test 12.478
test-t 4.381 - 4.488
csv-parser 13.341
(just to verify)
Error encoding UTF-8 string: could not encode codepoint 1870264 (0x1C89B8), codepoint out of bounds. Cannot encode higher than 1114111 (0x10FFFF) 16:21
(the utf8-c8 test)
jnthn oh heck, not again :/
|Tux| not again, still
sorry
jnthn Yes, I mean I'm darn tired of having to fix utf8-c8 and wish I'd never created it by now :P
|Tux| remove it 16:22
jnthn Well, too late really :(
If we want rid of it, we have to stop making all paths, command line arguments, environment varaibles, etc. Str
lizmat 288 -> 267 wallclock (for TEST_JOBS=8 -> 7)
jnthn And that'll be...inconvenient
|Tux| I have not seriously created the implementation of CSV using utf8-c8 yet, because it is still broken, so I won't be upset 16:23
jnthn I'd suggest making it an option when you do fwiw
Though probably that was your plan :)
Oh, did you have an outstanding issue on wanting to control if newline translation happens also? 16:24
|Tux| I wanted to have it automagically work, but I'll discuss with lizmat (much) later
yes, no hurry either
jnthn Well, on that one I did all the hard work already to let it happen :-)
|Tux| :) 16:25
jnthn It just needs explosing as an option to open
*exposing
|Tux| jnthn++
|Tux| needs to commute now
lizmat jnthn: also bare startup seems to have lost a few milliseconds as well
jnthn lizmat: That one surprises me a tad in that in theory we're doing less spesh work on the main thread at startup :) 16:26
lizmat well, atm on my machine it is consistely above 130 msecs
it used to be consistently below it (only just) 16:27
ok, forget what I said
must have been something else in the background
122 msecs now
jnthn Yeah, I don't even see any spesh stuff in the callgrind output for it really (above the threshold it sets) 16:33
There are lots of juicy things to look into with startup though :) 16:34
Zoffix Don't see much slowdown in stresstest, but now 4 files flopped at the same time :/ gist.github.com/zoffixznet/a1d0e52...ee28c04ebc 16:43
All clean on second run tho 16:47
ZOFVM: Files=1267, Tests=144423, 128 wallclock secs (20.46 usr 3.71 sys + 2547.62 cusr 219.25 csys = 2791.04 CPU)
lizmat dinner& 16:52
AlexDaniel “MoarVM panic: Internal error: invalid thread ID 858866954 in GC work pass” … ok that's new 17:47
timotimo that'd be memory corruption 17:49
made sure to rebuild your rakudo?
oh, it'd explode more violently if you hadn't
AlexDaniel it happened randomly during whateverable tests
… the first time I ran one of the files 17:50
timotimo ah frick, the -pedantic warning messages again
AlexDaniel well, we'll see how it goes, but so far not a good sign :) 17:51
Zoffix disables renewal on perl6.fail 17:55
"Update auto-renewal settings: Temporarily not available" 17:56
booo
timotimo huh
Zoffix gonna be fail.rakudo.party once I set it up.
timotimo will ah
Zoffix Cleaning up my fancy domains now that the cheap first year pricing is gone :) 17:57
AlexDaniel yea, this MoarVM panic is definitely happening 17:58
timotimo right, they do get incredibly expensive after the first year 18:01
i hope the majority of people dump their domains after the first year
stmuk clang 4 seems pretty fast 18:10
AlexDaniel .tell MasterDuke I'm going to take a nap now, but… bots are broken :) Feel free to investigate: github.com/perl6/whateverable/issu...-318444466 18:37
yoleaux AlexDaniel: I'll pass your message to MasterDuke.
AlexDaniel .tell MasterDuke well, not completely broken, but a chance of getting MoarVM panic when you do something is really high. 18:38
yoleaux AlexDaniel: I'll pass your message to MasterDuke.
Zoffix Thinking Proc::Async.start could use a .finish alias (or something like that). .start reads really confusing when using react/whenever www.reddit.com/r/perl/comments/6pw...l/dkt2j1s/ 20:05
or .finishes
.ends
$p.start ... await $p.finish 20:07
wont need to mess with variables as a bonus
timotimo do we have anything like .run?
well, we do have "run"
jnthn Zoffix: .start is consistently used for that in a few places 20:08
Promise.start for example
But yeah, with whenever it does read a tad odd 20:09
otoh
I've written `whenever start { blah } { ... }` some times before and never been so bothered by it
Zoffix jnthn: sure, I'm suggesting a near-alias. something that .starts unless already started and returns the .start's promise at all times
jnthn Could always just do my $exit = $proc.start; whenever $exit { } :) 20:10
Zoffix heh
Zoffix takes own advice against adding things :) 20:13
jnthn Yeah, I'm a tad uncomfortable about an alias just to make things read better in one (admittedly somewhat common) case 20:14
Though I think the very nature of asynchronous programming is that you start stuff and react whenever it happens
It just has...another reading that could be a bit misleading I guess 20:15
Zoffix :)
jnthn
.oO( This is why I prefer to work on semantics... :P )
 20:16
timotimo "okay rakudo, please alert me every time this program is started" 20:19
lizmat m: 1.match(/1/) for ^10000; say now - INIT now 20:48
camelia 0.9945535?
lizmat m: "1".match(/1/) for ^10000; say now - INIT now
camelia 0.16021462?
lizmat m: say 0.9945535 / 016021462
camelia Potential difficulties:? Leading 0 has no meaning. If you meant to create an octal number, use '0o' prefix; like, '0o16021462'. If you meant to create a string, please add quotation marks.? at <tmp>:1? ------> 3say 0.9945535 / 0160214627…
lizmat m: say 0.9945535 / 0.16021462
camelia 6.20763261?
lizmat ok, so not 7x slower, only 6 or so 20:49
jnthn That's still surprising given it should in theory just be a coercion and re-dispatch 21:35
m: 1.Str..match(/1/) for ^10000; say now - INIT now 21:42
camelia 5===SORRY!5=== Error while compiling <tmp>?Undeclared routine:? match used at line 1. Did you mean 'CATCH'???
jnthn m: 1.Str.match(/1/) for ^10000; say now - INIT now
camelia 0.15881912?
jnthn m: say 1.^mro
camelia ((Int) (Cool) (Any) (Mu))?
jnthn m: say 1.^find_method('match').package 21:43
camelia (Cool)?
jnthn m: 1.Stringy.match(/1/) for ^10000; say now - INIT now 21:44
camelia 0.1616643?
jnthn Wow
Well, nothing I've energy left to look into today 21:45
But I've still a Perl 6 tuit support for the coming weeks, so... :) 21:46
Zoffix jnthn_: it's more than just redispatch, it also messes around with $/ so that Str.match sets the right one 23:17
I suspect same perf issue exists with .subst too
and .subst-mutate 23:18
Geth_ star: 9c2f2b51a9 | (Timo Paulssen)++ | tools/star/Makefile
moarvm.org has https now; always check https certificates
star: 9339d23375 | (Timo Paulssen)++ | Configure.pl
make it more obvious Configure.pl directly is A Bad Idea
 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!