travis-ci Rakudo build passed. Elizabeth Mattijsen 'Don't use private method for AT-KEY-CONTAINER 00:26
travis-ci.org/rakudo/rakudo/builds/359300928 github.com/rakudo/rakudo/compare/8...b7f464e670
Geth nqp: e82bf8a97c | (Jeremy Studer)++ | src/vm/moar/profiler/template.html
Profiler Template: Sort by time Instead of Pct

Have the code in the profiler page sort by InclusiveTime/ExclusiveTime values instead of percent. Fixes subtle misordering of routines.		 01:05
nqp: b73a9b60bc | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 4 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...5-gafdcad4 afdcad4 Use char* for pointer addition to please MSVC 32d66d5 Speed up index 50% for flat haystack and diff type needle 15b4b9f Fix compiler warning by explicitly casting to MVMuint8* fc7da5c fix bytecodedump to understand inlines		 02:22
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...5-gafdcad4
rakudo: 23af1f4aae | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] Brings 3 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....0-gb73a9b6 b73a9b6 [MoarVM Bump] Brings 4 commits e82bf8a Profiler Template: Sort by time Instead of Pct 0736a0c [JVM] Adjust 'getrusage' to fix rakudo build
... (5 more lines)
rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....0-gb73a9b6
05816139ea | (Elizabeth Mattijsen)++ | src/core/Proc.pm6
travis-ci Rakudo build passed. Zoffix Znet 'Ignore whole /gen 02:46
travis-ci.org/rakudo/rakudo/builds/359348726 github.com/rakudo/rakudo/compare/1...a576e62e64
Rakudo build passed. Elizabeth Mattijsen 'Implement Array.grab, as discussed in GH R#1658' 03:23
travis-ci.org/rakudo/rakudo/builds/359406934 github.com/rakudo/rakudo/compare/8...e5e880580c
synopsebot R#1658 [open]: github.com/rakudo/rakudo/issues/1658 [@LARRY][NYI][testneeded] Why do Array / Hash not have .grab like QuantHashes do?
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Merge pull request #1664 from rakudo/fails-like 03:58
travis-ci.org/rakudo/rakudo/builds/359414496 github.com/rakudo/rakudo/compare/6...a0e706537d
Rakudo build passed. Elizabeth Mattijsen 'Remove some leftover code 04:37
travis-ci.org/rakudo/rakudo/builds/359433086 github.com/rakudo/rakudo/compare/a...82292562a4
samcv i think i've decreased the runtime by 1/2 of that script 06:57
if everything is going fine :) got it down to 6 seconds from 11.5 to get to 256kb
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Move proto method splice: Mu -> Any 07:04
travis-ci.org/rakudo/rakudo/builds/359589156 github.com/rakudo/rakudo/compare/f...d61bd94527
[Tux] Rakudo version 2018.03-122-g23af1f4aa - MoarVM version 2018.03-35-gafdcad424
csv-ip5xs0.911 - 1.002
csv-ip5xs-208.790 - 9.000
csv-parser37.820 - 39.399
csv-test-xs-200.467 - 0.504
test9.201 - 9.475
test-t2.510 - 2.587
test-t --race1.030 - 1.108
test-t-2046.053 - 46.464
test-t-20 --race15.505 - 18.882
 07:12
lizmat Files=1238, Tests=76257, 310 wallclock secs (14.69 usr 5.26 sys + 2124.06 cusr 206.65 csys = 2350.66 CPU) 07:39
samcv since this is such a common codepath i tried really hard to get as many tight loops as possible. even though i may need many more loops and fallthroughs 07:43
travis-ci Rakudo build passed. usev6 '[JVM] Work around problem with native arrays 07:46
travis-ci.org/rakudo/rakudo/builds/359591592 github.com/rakudo/rakudo/compare/8...acc5a4537c
rakudo: 5ad102ea76 | (Elizabeth Mattijsen)++ | src/core/Proc.pm6
Make sure Proc.pid is Nil if we didn't run yet
 08:05
rakudo/js: 58f577a1b1 | pmurias++ | src/Perl6/Metamodel/BOOTSTRAP.nqp
[js] Enable phasers cloning code on js backend too
 08:26
rakudo/js: 8a999990d3 | pmurias++ | src/core/traits.pm6
Revert "Revert "Fix 'is export' on constants assigned to routines""

This reverts commit c5383a1cf3685016e324b03e63da020ba18cb30f.
lizmat .ask jnthn how do you feel about if a producer of a fixed data size would change the batchsize so that each :degree would only get 1 batch to process 08:34
yoleaux lizmat: I'll pass your message to jnthn.
lizmat afk for a few hours& 08:35
AlexDaniel` samcv: sounds awesome 09:32
samcv AlexDaniel`: i also got a loop to vectorize into SSE or AVX instructions. which is neat. not sure how much faster that is, but i'll have to test it later 09:35
AlexDaniel` 6 seconds is not that far from 1-2s :) 09:36
samcv but i'd think that'd be many times faster. though sadly we check each grapheme to make sure it fits in 8 bits, so that section can't vecorize. but i did a lot of work to get the loop as tight as possible. and it made a big difference in addition to more loops. basically i first iterate over each strand, looping as long as there's room in the result to copy the whole strand 09:37
so if the strand is 8bit it uses memcpy. if it's not it uses a tight loop that goes for the length of he strand, if i encouners a 32 bit grapheme then i use a goto statement 09:38
timotimo hm, say ...
how about we go through whole bunches of graphemes at a time to do the 8bit bounds checks?
samcv yeah i thought about that as well
timotimo maybe a quick check against a bit mask could help
samcv heh we think alike
#define can_fit_into_8bit_unsafe(g) (!((((g) & 0xffffff80) + 0x80) & (0xffffff80-1))) 09:39
timotimo %)
samcv it's not faster than an if condition but i figure we could remove the if condition and just do a batch of graphemes
then after that check the value
timotimo yeah
maybe go through four or five cache lines worth of data at a time with a check, then copy 09:40
the earlier we notice we'll have to abort and do 32 instead, the better we'll be off, too
samcv i'd think that checking a fair number at a time, then copying that many 09:41
and then the copy would be able to be vectorized
timotimo *nod*
samcv timotimo: you can pass -Rpass=loop-vectorize to clang and it'll tell you which loops were vectorized and the vectorization width 09:46
timotimo on, nice
samcv and -Rpass-analysis=loop-vectorize will tell you why loops were'n't vectorized
timotimo right. cool. 09:47
we could have monitoring for that, too %)
samcv (will dump out a lot of things)
timotimo for sure
samcv most not too useful
since a lot of things aren't good candidates
timotimo just to see that things that were once vectorized don't get unvectorized without us knowing about it? 09:51
looks like gcc has -fopt-info-vec-missed; not sure if -ftree-vectorize is necessary 09:52
samcv hmm yeah could be useful once i play around with it some more 09:56
jnthn .tell Zoffix ecosystem fallout from the addition of `fails-like`: travis-ci.org/croservices/cro-http...7808#L1459 10:53
yoleaux 08:34Z <lizmat> jnthn: how do you feel about if a producer of a fixed data size would change the batchsize so that each :degree would only get 1 batch to process
jnthn: I'll pass your message to Zoffix.
jnthn lizmat: Depends entirely on if the user specified :batch or not
If they didn't, or only specified :degree but not batch, sure. If they did, then we should honor that
lizmat ok, so basically, setting the default in .hyper/.race is too early 10:54
jnthn But when :batch and/or :degree are not set, that's our invitation to try and apply what heuristics we can to pick someting good
Yes
lizmat ok, I'll run with that
Zoffix jnthn: are methods safe to callstatic once resolved to a Method object? github.com/rakudo/rakudo/pull/1665 10:55
jnthn Funnily enough, the ecosystem fallout pretty much speaks in favor of `fails-like` being provided :P
Zoffix: I'm confused what on earth code that is generating, to be honest :) 10:56
In that I thought callstatic fell back to call in the non-named case, but since you spot a difference, I want to know what it's doing :)
Zoffix Ohhh 10:57
jnthn (Which means I need to look at the output bytecode, which I didn't get time to do yet)
Zoffix greppable6: fails\-like
greppable6 Zoffix, 12 lines, 2 modules: gist.github.com/0f201f5100fdfeb6fb...cc548e59f5
Zoffix Wonder why Cro's not in the list... 10:58
jnthn Zoffix: The ecosystem fallout isn't in Cro itself, it's in a module Cro depends on 10:59
Zoffix Ooohh
Easy to fix, since it's my module :P
jnthn IO::Path::ChildSecure
yes ;)
Zoffix Fix pushed 11:01
dogbert17 Zoffix: FYI, the NQP program you supplied in G#1667 crashes on 32 bit systems (at least on mine :) 11:02
Zoffix R#1667 11:03
synopsebot R#1667 [open]: github.com/rakudo/rakudo/issues/1667 [perf] Some string benchmark
dogbert17 gah, I always get that wrong :(
Zoffix dogbert17: and non-NQP doesn't crash? That's weird, because I copy-pasted the guts of .subst
dogbert17 the crash is an out of memory one 11:04
MoarVM panic: Memory allocation failed; could not allocate 691840 bytes
Zoffix Ah 11:05
|90d see if we can improve sum algo: en.wikipedia.org/wiki/Kahan_summat...hancements twitter.com/johnmyleswhite/status/...6904882178
ZofBot Zoffix, Will remind you on 2018-06-27T07:05:54.184636-04:00 about see if we can improve sum algo: en.wikipedia.org/wiki/Kahan_summat...hancements twitter.com/johnmyleswhite/status/...6904882178
dogbert17 it eats through memory like there's no tomorrow :) 11:06
timotimo eating memory really, really, really fast is often an infinite recursion 11:14
lizmat So I'm looking at why the null-line of the supervisor loop is still calling List.sink 3 times every iteration 11:16
(which now comes to something like 1% overhead and additional BootHash allocations 11:19
suggestions? 11:20
pmurias do we have data/graph how the numbers of spectest the jvm backend is passing progressess? 11:22
Geth rakudo: ae91db887b | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm6
Replace .elems by nqp::elems() in scheduler

Reduces CPU usage of idling supervisor by 5%, and reduces the number of Int and BOOTHash allocations siginificantly.		 11:58
rakudo: f8c441642c | (Elizabeth Mattijsen)++ | src/core/ThreadPoolScheduler.pm6
Only check affinity-workers if there are any

Shaves off another 2% of CPU usage of the idle supervisor loop		 12:23
lizmat [Tux]: updated Text::CSV with "is default" on the attributes 12:28
|Tux| lizmat++ 12:29
lizmat afk for a bit& 12:30
samcv |Tux|: this seems to show some drop tux.nl/Talks/CSV6/images/test-t-d10.png 12:45
since the mvm change i made today
|Tux| samv, you were looking too quickly :) 12:46
this might be due to lizmat's change. I just re-ran the tests:
Rakudo version 2018.03-122-g23af1f4aa - MoarVM version 2018.03-35-gafdcad424
csv-ip5xs0.893 - 0.897
csv-ip5xs-208.592 - 8.631
csv-parser36.272 - 36.762
csv-test-xs-200.448 - 0.456
test8.891 - 8.955
test-t2.372 - 2.379
test-t --race1.005 - 1.026
test-t-2041.926 - 42.787
test-t-20 --race14.929 - 15.409
samcv oh 12:47
|Tux| 👍
samcv the threadpool scheduler or another |Tux|
|Tux| ? 12:48
samcv i just made a big change to the string indexing code github.com/MoarVM/MoarVM/commit/32...f92f98c689 i got 0.5x to 3x speed improvement i even saw
went from 2.0685436 to 0.3240215s on this test gist.github.com/samcv/adc8d50df303...p6-L15-L25 12:51
the commit description should give info on the change 12:52
[Coke] samcv: so, I read 3x speed improvement as "runs in 1/3 the time"... if *that's* right, then 0.5 would mean in twice the time. 12:57
Can you explain 0.5x to 3x improvement?
(not how you did it, just what those numbers mean?) 12:58
samcv sorry ignore my wording. it's confusing saying 0.5x faster. i mean 1.5x the speed as before or it takes 2/3 to 1/4 the time 13:03
and technically in that one test it completed in 1/6 the time, but aside from that. the math i was using was 50% faster: original_time * 100/(100+50) = original_time * 2/3 13:05
though that's not on that test, it's just an overall thing i observed so picked a conservative amount. since not all things complete in 1/6 the time like that one test 13:06
jnthn grrr, github.com/rakudo/rakudo/issues/1660 seems to be some memory corruption issue...but no luck getting valgrind to show it up 16:03
Hurrah, ASAN finds it 16:07
Not that the output immediately makes clear what's up 16:08
dogbert17 +jnthn+ 16:09
jnthn: managed to trip my ASAN as well: MVM_fixed_size_alloc src/core/fixedsizealloc.c:188 16:29
did you get the same?
jnthn Yeah, but it makes...not a huge amount of sense 16:36
I did spot something problematic and fixed it, but it didn't help
dogbert17 perhaps it fixes some other problem though 16:37
Geth rakudo: a12ea10690 | (Moritz Lenz)++ | CONTRIBUTING.md
Fix grammar error in CONTRIBUTING.md
 16:38
moritz the sentence still reads awkwardly, IMHO
jnthn dogbert17: perhaps, yes
dogbert17 jnthn: I got a better ASAN barf: gist.github.com/dogbert17/dfcb5716...4348b27e9c 16:40
jnthn o.O 16:41
Well, that one does make sense 16:45
And I've probably got a fix for that too
But it doesn't help with the original ASAN trace I see
dogbert17 argh 16:47
so multiple problems then 16:48
jnthn Multiple fixes too :P 16:49
Just not to the primary issue
AddressSanitizer can not describe address in more detail (wild memory access suspected).
SUMMARY: AddressSanitizer: heap-buffer-overflow src/gc/collect.c:367 MVM_gc_mark_collectable
That about sums it up...there's a comletely nuts SC index in there
dogbert17 and valgrind doesn't want to play ball either :( 16:51
jnthn Well, it ain't giving up its secrets easily 17:24
Really weird. I'm looking at something that looks like a frame, but with a wildly bogus SC index, but the bogus indices are in a union with the pointer it uses to chain STables for cleanup 17:31
And that is a valid pointer to an STable
Which can't be just down to chance
But only an ST can ever be put onto that linked list, and I don't see how that bit could be going wrong 17:33
Ah well, will continue tomorrow 17:35
dogbert17 jnthn: got this: gist.github.com/dogbert17/08b377bf...4697ad0820 17:44
Geth rakudo: 924310c5ff | usev6++ | src/core/ThreadPoolScheduler.pm6
[JVM] Remove superfluous call to .shift

Leftover from github.com/rakudo/rakudo/commit/4ef28a7bcb		 18:44
bartolin for some reasons the following test has started to fail on the JVM backend: 18:59
r: use Test; is (^10).grep(Int, :!kv), [^10]
camelia ok 1 -
bartolin r: dd (^10).grep(Int, :!kv); dd [^10]
camelia (0, 1, 2, 3, 4, 5, 6, 7, 8, 9).Seq
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
bartolin it's from S32-list/grep-kv.t: github.com/perl6/roast/blob/4c1a52...p-kv.t#L73 19:01
would it make sense to change the test to use is-deeply, like this? 19:02
r: use Test; is-deeply (^10).grep(Int, :!kv), [^10].Seq
camelia ok 1 -
bartolin (that still passes with HEAD on rakudo-j
Zoffix bartolin: yeah, `is` is a completely inappropriate routine in this case as (1, (2, (3, ...) and all sorts of other variations would pass... But what does the failure look like? 19:17
bartolin Zoffix: oops, I just run it standalone and it passes. I'm afraid I raised a false alarm -- probably I messed something up. 19:20
sorry, it looks like I mis-read the output from running the test file. it was another test that failed -- and that failure is for real 19:21
bartolin should head to bed, obviously
Zoffix Ah 19:22
Geth rakudo: 7572983a41 | (Jonathan Worthington)++ | src/core/Supply.pm6
Make Supply.interval a serial Supply

Previously, it was non-serial, and relied on something downstream calling `.serialize`. The `whenever` construct would do exactly that, so the only way to observe this was a `.tap` on the interval `Supply` directly.
... (19 more lines)		 19:35
6.d-prep: ed472e08e3 | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/FEATURES.md
List Str.subst-mutate for deprecation and removal
 19:42
6.d-prep: 138e73aab8 | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/FEATURES.md
Remove `Make `.?` safecall actually safe`

I no longer think that's the right path to follow, so as the Stakeholder, I'm tossing the entire proposal.
The .? safety will be significantly improved once the :D calls on Nil are fixed up		 19:45
nine LOL I wrote a make in NQP in an evening and it builds rakudo 20:29
tadzik :D 20:30
damn, that's good :)
. o O ( not quite make )
dogbert17 nine++: perhaps you should call it nmake :) 20:37
jnthn
.oO( nine make? :D )
lizmat NQM ? 20:44
nine Just shy of 250 LOC and it makes it through make install. Really fun coding exercise :) 20:45
gist.github.com/niner/a959cb893820...392d4c16cb for the curious 20:46
jnthn That's amaziong :D 20:48
lizmat notable6 weekly: gist.github.com/niner/a959cb893820...392d4c16cb
AlexDaniel : or , 20:49
well…
lizmat notable6 weekly, gist.github.com/niner/a959cb893820...392d4c16cb
AlexDaniel weekly: gist.github.com/niner/a959cb893820...392d4c16cb
notable6 AlexDaniel, Noted!
lizmat argh ok
AlexDaniel alternatively “notable6: weekly https………”
lizmat understood
Kaiepi for rakudo's Configure.pl, i'm wondering if adding a --moar-options flag that lets you pass multiple flags at once would be a good idea 21:41
like this is a lot of typing: ./Configure.pl --gen-moar --moar-option=--has-dyncall --moar-option=--cc=egcc --moar-option=--telemeh --moar-option=--optimize=0 --moar-option=--debug=3 --prefix=$HOME/.perl6 21:42
or modify --moar-option so that that'd work
so instead --moar-option(s?)='--has-dyncall --cc=egcc --telemeh --optimize=0 --debug=3' would work 21:43
AlexDaniel Kaiepi: can't you just concat them all? 22:03
hm maybe not, but I thought you can… 22:04
like '--moar-option==--foo --bar …'
Kaiepi Unknown option: cc-egcc --has-dyncall _ 22:13
oh typo 22:14
yeah that works
i feel it's not very obvious though
wait 22:15
egcc: error: unrecognized command line option '--has-dyncall'
nope, doesn't work
AlexDaniel did you quote it correctly? :) 22:26
but yeah, maybe it doesn't work
Kaiepi i did '--moar-option='--cc=egcc --has-dyncall _' 22:29
* '--moar-option=--cc=egcc --has-dyncall _'
also, i might throw up a couple more bots like BeastieBot/PufferBot in vms on my system 22:36
i only have the ram to feasibly run two atm though
what systems desperately need testing?
i was thinking netbsd and solaris, but i'm wondering about systems on other architectures 22:37
like maybe testing for arm on debian 22:42
one thing i've noticed is the stage parse parts of building rakudo take much longer on openbsd compared to other systems 23:46
like ~70s compared to ~30s in an alpine vm 23:47
i know there's overhead from the additional security features openbsd has, but i'm wondering if there are ways to help optimize it
like using pledge in moarvm
MasterDuke your vm must be pretty beefy, i get 80s stage parse not in a vm
Kaiepi i use moar, if that's what you mean 23:50
MasterDuke same here 23:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!