AlexDaniel has the release ready locally, now is double-checking everything 00:13
looks alright 00:19
let's go! 00:22
AlexDaniel … 00:25
let's go! # №2 00:28
Geth nqp: 4a3a35cbf9 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[release] Bump MoarVM revision to 2017.09.1
 00:29
nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2....2017.09.1
13ddad3dbb | (Aleks-Daniel Jakimenko-Aleksejev)++ | VERSION
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2....2017.09.1
rakudo/nom: b4ba33af43 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[release] Bump NQP revision to 2017.09
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017.......2017.09
ce12e48031 | (Aleks-Daniel Jakimenko-Aleksejev)++ | VERSION
¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017.......2017.09
roast: skids++ created pull request #323:
Rt126890		 01:17
roast: 56ec035996 | skids++ | S02-literals/pairs.t
Add test for RT#126890
roast: 614621d9e7 | skids++ | 4 files
Update some links in roast comments.

The colabti.de links were not just dead but had been squatted.
   Suggest a search of all project trees to eliminate any more.
   Also, update comments on boolean pair syntax to match S02 changes
   made back in 2009.
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126890
roast: 10f7c115b6 | skids++ (committed using GitHub Web editor) | 4 files
Merge pull request #323 from skids/rt126890

Rt126890
travis-ci Rakudo build failed. Aleks-Daniel Jakimenko-Aleksejev '[release] Bump VERSION to 2017.09' 01:29
travis-ci.org/rakudo/rakudo/builds/276659273 github.com/rakudo/rakudo/compare/8...12e480316e
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
MasterDuke ^^^ segv when building NQP travis-ci.org/rakudo/rakudo/jobs/276659274 01:32
just one of the configurations though 01:33
japhb .ask AlexDaniel Why does Geth report "version bump brought these changes" when bumping the repo's version, rather than the file indicating its *dependency's* version? 05:36
yoleaux japhb: I'll pass your message to AlexDaniel.
geekosaur isn't the point to allow someone doing a bisect that hits that commit to see what changes in the dependency might be involved, since those changes are not in the dependent's commit history otherwise? 05:52
oh, I see. I think what happens is what you want for all but rakudo's own version?
see b4ba33af43 05:53
but I don't think geth can track whether a given revision file refers to the current or some other repo
because it's not repo metadata but build metadata
so you get extraneous output for some revision files but the info you need is present for the revision files that need it 05:55
Geth rakudo: Gnouc++ created pull request #1162:
Add trim* subroutines for Cool instance		 06:28
roast: Gnouc++ created pull request #324:
Add tests for trim* subroutines on Cool instance
[Tux] This is Rakudo version 2017.09 built on MoarVM version 2017.09.1 06:40
csv-ip5xs 1.351 - 1.365
test 9.861 - 9.901
test-t 3.406 - 3.426
csv-parser 10.818 - 11.066
jnthn morning, #perl6-dev 08:41
So, we had a release? :) 08:42
Looks like. Thus...I can merge le new scheduler 08:47
lizmat Files=1227, Tests=75076, 295 wallclock secs (14.58 usr 5.25 sys + 1995.80 cusr 207.07 csys = 2222.70 CPU) 08:50
Geth rakudo/nom: 14 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/c...61a77e60a7		 09:09
jnthn There we go.
That deals with RT #122709, RT #130370, and perhaps makes enough of a dent in RT #131915 to be happy too 09:11
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=122709
Link: rt.perl.org/rt3/Public/Bug/Display...?id=130370
Link: rt.perl.org/rt3/Public/Bug/Display...?id=131915
cuonglm jnthn: How do you think about this PR github.com/rakudo/rakudo/pull/1162...-330166633 09:31
jnthn I suspect doing .Stringy inside of the Cool candidate would be preferable from a performance perspective 09:34
cuonglm jnthn: But we already have `trim` for `Cool`, which actually call .Stringy.trim
if anything changed, we have to make changes in 2 places 09:35
jnthn Yeah, but it creates a slightly shallower call graph
Probably not a big difference though
But if we're going to do that then there's no reason to duplicate the candidate for Cool and Str 09:36
Just change the existing thing to be Cool and be done with it
Otherwise if anything changed, we have to make changes in 2 places :P 09:37
cuonglm jnthn: Hmm, no 2 places in this case, because Cool is Stringy first, so we only have to change in `trim*` methods, not subroutines 09:39
From user perspective, `trim*` variants are dedicated for string
jnthn Yeah, but it's still duplicate code, and it's not like multi is totally free 09:40
cuonglm jnthn: yep, so we will go with Cool for `trim*` subroutines 09:41
jnthn Works fine for me
cuonglm so the document must change, too :)
Oh, I see no documentation for `trim*` subroutine yet 09:42
jnthn: Another problem, do you have any suggestion for fixing this issue 09:43
m: my @a is default(0) = 1...*; @a[1]:delete; dd @a[1]:exists; dd @a
camelia Bool::True
Array @a = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10... lazy list)
cuonglm I made some changes to Array `DELETE-POS` method with no luck 09:44
not sure what did I missed
jnthn It seems to be assuming that if we didn't reify that many elems, they won't exist 09:52
Which isn't actually tree 09:53
*true
In the lazy case
cuonglm Hmm, I try to reify in DELETE-POS but it isn't work 09:56
In the lazy case, does this condition true github.com/rakudo/rakudo/blob/nom/...ay.pm#L593
jnthn Not always; if nothing was reified yet, for example, may not be 09:57
cuonglm I guess it's false, because this print 0
m: my @a is default(0) = 1...*; dd @a[1]:delete; dd @a[1]:exists; dd @a
camelia 0
Bool::True
Array @a = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10... lazy list)
cuonglm Hmm, so I think a check if array is lazy, then reify it first is ok, how do you think? 09:58
jnthn Yeah, I think reify it up to and including the element we'll delete 09:59
I think $!todo will be always set if there's unreified things
So that's probably the cheap thing to check
cuonglm thanks +1, let me try it 10:00
Geth rakudo/nom: 48406db639 | (Elizabeth Mattijsen)++ | src/core/Encoding/Registry.pm
Streamline registering an encoding

Not much for something that only needs to be done once, you might argue. But we're doing *7* of these at *every* perl6 startup. This shaves 1-2 milliseconds off of each perl6 startup.		 10:03
rakudo/nom: 4 commits pushed by (Cuong Manh Le)++, lizmat++ 10:11
travis-ci Rakudo build failed. Jonathan Worthington 'Merge branch 'better-sched' into nom' 10:30
travis-ci.org/rakudo/rakudo/builds/276765863 github.com/rakudo/rakudo/compare/c...a77e60a7d9
buggable [travis build above] ✓ All failures are due to timeout (0), missing build log (0), GitHub connectivity (0), or failed make test (3). Across all jobs, only t/04-nativecall/21-callback-other-thread.t test file failed.
jnthn Hmm
lizmat timeouts, jnthn , no worries :-) 10:37
jnthn ah, ok 10:38
Geth roast: c1d8794b82 | (Cuong Manh Le)++ (committed by Zoffix Znet) | S32-str/trim.t
Add tests for trim* subroutines on Cool instance (#324)

  * Add tests for trim* subroutines on Cool instance
  * Test trim* with Int make more sense
  * Using IO::Path for testing trim* routines		 10:49
Zoffix Nah, it's t/04-nativecall/21-callback-other-thread.t test file failed
Though I seen it flop recently 10:51
Though now it's 3 jobs that have the same failure
jnthn urgh 10:52
Zoffix The bot's message is "✓ All failures are due to" (timeout => 0, "missing build log" => 0, "GitHub connectivity" => 0, "or failed make test" => 3) with the number showing how many jobs had such a failure
jnthn Not sure why failing make test requires a tick
I saw the tick and totally ignored the rest :) 10:53
Geth roast: 8b5e390937 | (Jonathan Worthington)++ | S17-promise/lock-async.t
Add tests for Lock::Async

A non-blocking mechanism for mutual exclusion soon to be added into Rakudo, most immediately for Supply internals but it's a useful thing to make available to users also.		 11:16
rakudo/supply-locking-refactor: 53dd776c9a | (Jonathan Worthington)++ | 2 files
Add Lock::Async

Which will be used in order to do concurrency control in a more scalable way for supplies.		 11:17
rakudo/supply-locking-refactor: 4a8038c295 | (Jonathan Worthington)++ | src/core/Supply.pm
Start using Lock::Async in some Supply internals

No regressions in stresstest from this, which is a promising sign.
rakudo/supply-locking-refactor: 0ffff8596c | (Jonathan Worthington)++ | t/spectest.data
Run S17-promise/lock-async.t
AelxDnaiel buggable: bugs 11:18
buggable AelxDnaiel, Total: 1684; BUG: 1079; UNTAGGED: 398; LTA: 180; NYI: 96; REGEX: 69; RFC: 61; TESTNEEDED: 56; JVM: 53; CONC: 50; REGRESSION: 38; UNI: 29; PERF: 28; SEGV: 26; @LARRY: 23; IO: 23; NATIVECALL: 23; POD: 21; TODO: 18; PRECOMP: 14; OO: 13; BUILD: 11; TESTCOMMITTED: 10; OPTIMIZER: 9; STAR: 7; PARSER: 6; BOOTSTRAP: 5; REPL: 5; GLR: 4; MATH: 4; OSX: 4; WINDOWS: 3; RT: 2; WEIRD: 2;
AelxDnaiel buggable: tag untagged 11:19
buggable AelxDnaiel, There are 398 tickets tagged with UNTAGGED; See fail.rakudo.party/t/UNTAGGED for details
AelxDnaiel rt.perl.org/Public/Bug/Display.htm...et-history 11:20
jnthn lunch & 11:32
Zoffix jnthn: I added it when it was flopping in make test. I guess I could untick those failures now 11:33
tbrowder .tell jnthn think there are possible future optimizations for ascii read by declaring the encoding? 11:54
yoleaux tbrowder: I'll pass your message to jnthn.
Zoffix hm, so much for making a small change in buggable. Restarting it made it use updated rakudo and now it dies with "===SORRY!=== 12:11
Missing serialize REPR function for REPR VMException (BOOTException)"
No line number or even filename :/
AelxDnaiel :| 12:14
Geth rakudo/supply-locking-refactor: 85bdd38afa | (Jonathan Worthington)++ | 2 files
Use Lock::Async in supply sequencer
 12:20
jnthn Should be able to give a filename for that, but there's no real way to race the point the problem occurs back to a line number
yoleaux 11:54Z <tbrowder> jnthn: think there are possible future optimizations for ascii read by declaring the encoding?
jnthn .tell tbrowder I think there are ways to squeeze a bit more out of it, both on the encode and encode paths, and especially so if we get it to better understand strings stored at 8-bit width 12:24
yoleaux jnthn: I'll pass your message to tbrowder.
jnthn s/race/trace/ about :)
*above, grr
m: say 0x7FFFFFFF * 0.001 12:26
camelia 2147483.647
jnthn m: say (0x7FFFFFFF * 0.001) / 3600
camelia 596.52323528
jnthn m: say ((0x7FFFFFFF * 0.001) / 3600) / 24
camelia 24.855134803
jnthn Hmm.
I guess a Perl 6 process could feasibly run for more than 25 days :) 12:27
Quite a bit mor
*more
Zoffix huggable: uptime
huggable Zoffix, nothing found
jnthn was wondering about using an atomicint for Supply.interval, but we can only be sure of 32 bits
Zoffix Geth_: uptime
Geth_ Zoffix, 5 days, 20 hours, 14 minutes, and 30 seconds
jnthn Note that you'd have to use Supply.interval at its maximum resolution 12:28
(1ms ticks)
So overflow it
m: say ((0x7FFFFFFFFFFFFFFF * 0.001) / 3600) / 24
camelia 106751991167.300645914
jnthn On 64-bit it's less of a problem ;-) 12:29
m: say ((0x7FFFFFFFFFFFFFFF * 0.001) / 3600) / (365.25 * 24)
camelia 292271023.045313198944
jnthn If somebody files a but in 292,271 millenia then somebody else can fix it :P
*bug 12:30
So the 64-bit case would be fine
Zoffix :)
jnthn just switches interval to use Lock::Async for now
I guess we could try and detect the size of an atomic int and decide which to use at runtime 12:31
But probably not worth it for now
Zoffix Well, I give up. 12:35
Commenting out a bunch of modules showed as if the /win lottery plugin was the issue, but commenting out just the lottery plugin while uncommenting other modules made it throw again 12:36
github.com/zoffixznet/perl6-buggable if anyone wants to give it a go. perl6 bin/buggable.p6 dies with the aforementioned error 12:37
Zoffix &
Geth rakudo/supply-locking-refactor: 388964020c | (Jonathan Worthington)++ | src/core/Supply.pm
Use Lock::Async in Supply.interval
 12:55
jnthn Nice, those changes seem to not only not break cro, but also increase the requests/second a bit too 13:00
IO::Socket::Async::SSL tests also look good
Seems there's some issues with a test I recently added though; will investigate that 13:01
And those changes will utterly busticate JVM, so I should look into that also
AlexDaniel he
yoleaux 05:36Z <japhb> AlexDaniel: Why does Geth report "version bump brought these changes" when bumping the repo's version, rather than the file indicating its *dependency's* version?
AlexDaniel japhb: hmmm… I don't understand the question 13:03
japhb: but perhaps consider creating an issue here github.com/perl6/geth/issues
Zoffix .tell japhb Geth *does* report when bumping the deps file, but the URL it gives are to a list of changes in the dependant repo the bump brought in, not to the file with the change 13:07
yoleaux Zoffix: I'll pass your message to japhb.
tbrowder jnthn: i suppose using nativecall to access libc read funs 13:13
yoleaux 12:24Z <jnthn> tbrowder: I think there are ways to squeeze a bit more out of it, both on the encode and encode paths, and especially so if we get it to better understand strings stored at 8-bit width
tbrowder *funcs wouldn't pay off? 13:14
jnthn Those are what we end up calling anyway to do the actual I/O, but that still gives a bunch of bytes that need checking if they really are ASCII (0 < c <= 127), and the \r\n turned into a single grapheme. 13:15
I suspect an amount of the cost is in that last step 13:16
tbrowder use a pragma to turn off some of that?
jnthn Well, you can read latin-1 if you don't care about the range check :) 13:17
And at some point we'll have the Uni type to decide to not care about NFG 13:18
tbrowder thanks! 13:19
jnthn Also, as spesh and the JIT continue to improve, the code from the Perl 6 pieces of it all will speed up some more too
So there's some room to improve there 13:20
AlexDaniel buggable: tags
buggable AlexDaniel, Total: 1685; BUG: 1079; UNTAGGED: 398; LTA: 181; NYI: 96; REGEX: 69; RFC: 61; TESTNEEDED: 56; JVM: 53; CONC: 50; REGRESSION: 38; UNI: 29; PERF: 28; SEGV: 26; @LARRY: 23; IO: 23; NATIVECALL: 23; POD: 21; TODO: 18; PRECOMP: 14; OO: 13; BUILD: 11; TESTCOMMITTED: 10; OPTIMIZER: 9; STAR: 7; PARSER: 6; BOOTSTRAP: 5; REPL: 5; GLR: 4; MATH: 4; OSX: 4; WINDOWS: 3; 13:21
AlexDaniel Zoffix: can't reproduce. Maybe try with a fresh db, or maybe try deleting precomp files…
buggable: version 13:22
This is Rakudo version 2017.09-19-g9190a3b80 built on MoarVM version 2017.09.1
(x86_64 GNU/Linux) 13:23
Zoffix AlexDaniel: fresh db of what?
AlexDaniel Zoffix: win-db-file
I created an empty file for it and it worked 13:24
Zoffix It crashes without the win lottery plugin 13:25
This is Rakudo version 2017.09-19-g9190a3b built on MoarVM version 2017.09.1 13:26
AlexDaniel :| no idea then 13:27
Geth nqp: fc97d64e1b | (Jonathan Worthington)++ | 3 files
Add atomic ref ops and container methods on JVM

This doesn't actually implement the ops such that they are functional, it just paves the way for the Rakudo Scalar container handling in the Rakudo repository to be able to implement them.		 13:38
Zoffix AlexDaniel: what did you use for config.json? 13:39
AlexDaniel Zoffix: { "win-db-file": "foo.db" } 13:41
japhb AlexDaniel, Zoffix: See irclog.perlgeek.de/perl6-dev/2017-...i_15178419 -- notice how "version bump brought these changes" is reported twice for nqp and twice for rakudo -- in each case, once for the dependency bump, and then again for the repository *itself* getting a version bump 14:26
yoleaux 13:07Z <Zoffix> japhb: Geth *does* report when bumping the deps file, but the URL it gives are to a list of changes in the dependant repo the bump brought in, not to the file with the change
japhb It's not that it reports the changes -- I love that -- it's that it reports it both when it's appropriate and when it's not. 14:27
Zoffix Ah
AlexDaniel yeah, I see it now 14:28
Zoffix Don't know how it manages to do that. There is a check for filename: github.com/perl6/geth/blob/master/...m6#L31-L41 14:29
Geth rakudo/supply-locking-refactor: 32e4a1de29 | (Jonathan Worthington)++ | 2 files
Basic atomic reference op support on JVM backend

Still missing enforcing any type checks on the container, but enough to allow for Lock::Async to work.		 14:31
rakudo/supply-locking-refactor: 6170cb9d2a | (Jonathan Worthington)++ | tools/build/jvm_core_sources
Add Lock::Async to the JVM CORE.setting build

With this, it now successfully sanity tests again (meaning that supplies, which now use Lock::Async, are working at least well enough for Proc::Async, which precomp uses).		 14:32
jnthn really didn't fancy writing a second less efficient version of Lock::Async just for JVM, so ended up putting in support for atomic reference ops (atomic integer ones will be possible, but a good bit of work) 14:33
Zoffix kicks Geth 14:34
lizmat
.oO( I don't geth it )
nine jnthn: so you wrote a tool to write a tool to help a tool. Very damiany of you ;)
Zoffix I'm trying to redeliver the buggy webhook that triggered the version bump thing, but it apparently isn't getting gethed 14:35
Geth nqp: 4a3a35cbf9 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[release] Bump MoarVM revision to 2017.09.1
 14:36
nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2....2017.09.1
13ddad3dbb | (Aleks-Daniel Jakimenko-Aleksejev)++ | VERSION
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2....2017.09.1
Zoffix :| 14:37
jnthn Yeah, my top level task is to make non-blocking await play nicely with supplies, so that was at least 3 levels deep in yak shave :)
jdv79 my app doesnt die with the unknowm lock issue anymore. yay. 14:40
Geth rakudo/nom: 66c2d05f29 | (Elizabeth Mattijsen)++ | src/core/Mu.pm
Fix for RT #132117

This appears to break some test in S03-operators/eqv.t , which by the looks of it, are not very good tests.		 14:41
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132117
jdv79 now it just seems to stall and eat cpu but chugs along eventualky
Geth rakudo/supply-locking-refactor: 59c4117ff4 | (Jonathan Worthington)++ | src/vm/jvm/runtime/org/perl6/rakudo/RakudoContainerSpec.java
Enforce container types in atomic ops on JVM
 14:47
rakudo/supply-locking-refactor: 6ba16f84a7 | (Jonathan Worthington)++ | t/spectest.data
cas.t and cas-loop.t now pass on JVM
 14:49
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Streamline registering an encoding 14:50
travis-ci.org/rakudo/rakudo/builds/276783234 github.com/rakudo/rakudo/compare/6...406db63918
Zoffix k, see the problem with geth 14:51
jdv79 what gives? 14:52
Zoffix or maybe more like a glitch with github. One of the hooks has empty <commits> array, with the missing commit shipped in the previous hook
Geth_ geth: 6718dfdcf8 | (Zoffix Znet)++ | 2 files
Fix duplicate version bump reports

Report only once even if a hook has multiple commits		 14:53
japhb Zoffix: Huh. That's pretty odd
Zoffix Well, that may or may not be the fix. I can't test it because geth too now gives me "Missing serialize REPR function for REPR VMException (BOOTException)" error :| 14:54
Zoffix tries going back to rakudobrew installation
jdv79 the vm exceptions are frustrating:( 14:55
Geth_ geth: 77b08e52c3 | (Zoffix Znet)++ (committed using GitHub Web editor) | lib/Geth/GitHub/Hooks/Preprocessor.pm6
Fix wrong key name
jnthn Did anyone manage to bisect the VMException issue yet?
lizmat t/04-nativecall/21-callback-other-thread.t caused the build to fail in travix 14:56
*travis
jnthn lizmat: Yeah, I've managed to reproduce it locally also
Zoffix jnthn: AlexDaniel couldn't repro the problem on his box
Geth rakudo/nom: a845ac3d3f | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Mu.pm
Fix typo in error message; MasterDuke++
 15:02
lizmat MasterDuke++ :-) 15:04
Zoffix lizmat: the failings tests… the look to be failing because only one of the iterables is lazy and types differ. Maybe we don't have to die in those cases since we reliably know the answer is False? 15:05
m: dd (1…∞).List eqv (1…∞) 15:06
camelia Cannoy eqv lazy Iterables
in block <unit> at <tmp> line 1
travis-ci Rakudo build failed. lizmat 'Merge pull request #1162 from Gnouc/nom
travis-ci.org/rakudo/rakudo/builds/276785371 github.com/rakudo/rakudo/compare/4...90a3b80c6b
Zoffix c: HEAD~10 dd (1…∞).List eqv (1…∞)
committable6 Zoffix, ¦HEAD~10: «Bool::False»
Zoffix like ^ here we don't really care that they're lazy. We can see that types don't match
Zoffix wonders where laziness falls on the equivalency landscape. would `(lazy 1,) eqv (2,)` die or return False because it can see laziness doesn't match 15:08
AlexDaniel .tell Skarsnik I remember you had some patch that improved the situation with Gumbo slightly. Where was it?
yoleaux AlexDaniel: I'll pass your message to Skarsnik.
Zoffix The counter argument would be: all the specialness makes it harder to explain when `eqv` would die; "dies if any arg is lazy" is easy to learn 15:09
jnthn Grrr, the moment I go to debug that 21-callback-other-thread.t it runs 100 times in a row without failing :/ 15:12
Zoffix :)
jnthn ah, got it to fail when run under the harness 15:13
Maybe it needs load
hah, yes, running it in a loop while doing make stresstest got it 15:14
Hmmmm. Wat.
lizmat uh oh 15:15
japhb Zoffix: Did you notice that the error message you got ~10 minutes ago starts with the typo 'Cannoy'? ;-) 15:16
Zoffix japhb: yup, it was fixed already
japhb (y)
Dangit, I always forget that doesn't convert to thumbs-up in IRC
Zoffix oh no! 15:21
rakudobrewed rakudo works (doesn't have the VMException issue)
Does anyone see an error in my bash alias to install rakudo? github.com/zoffixznet/r#linux
Apparently the issue is due to that installation method :\ 15:22
if only there were a way to find out what exactly that exception is :\ 15:23
japhb Zoffix: FWIW, my rebuild script has gotten *paranoid* over the years. I never build in a tree I've built in previously; I keep clean clones that I pull into, and then I soft-clone them locally into a fresh new build tree. Just too many times that leftovers from previous have broken things and no amount of cleaning seems to be sufficient in all cases. 15:26
Zoffix I did try with a clean clone and the issue was still there 15:27
Geth_ nqp: 4a3a35cbf9 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[release] Bump MoarVM revision to 2017.09.1
 15:31
nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2....2017.09.1
13ddad3dbb | (Aleks-Daniel Jakimenko-Aleksejev)++ | VERSION
Zoffix bug's fixed
Geth geth: f6d935a0fe | (Zoffix Znet)++ | lib/Geth/Plugin/GitHub.pm6
Fix incorrect object used to get SHA from
 15:32
Zoffix Just need to update One True Geth™ to latest commits
travis-ci.org/rakudo/rakudo/builds/276785371 15:35
buggable [travis build above] ☠ All failures are due to timeout (0), missing build log (0), GitHub connectivity (0), or failed make test (2). Across all jobs, only t/04-nativecall/21-callback-other-thread.t test file failed.
Zoffix And this too fixed. No longer shows a check mark if there are test failures
jdv79 woohoo! 15:38
why are there so many timeouts on test runs? 15:39
Zoffix haven't seen any timeouts recently 15:41
Geth rakudo/nom: 48a84d6aff | (Elizabeth Mattijsen)++ | src/core/Mu.pm
Return False if only either side is lazy.
 15:47
Zoffix travis-ci.org/rakudo/rakudo/builds/276785371 15:51
buggable [travis build above] ☠ All failures are due to: failed make test (2 failures). Across all jobs, only t/04-nativecall/21-callback-other-thread.t test file failed.
Zoffix Made message a bit more understandable (and tossed failures that are 0) 15:52
jnthn Not having much luck fixing it, alas :( 15:54
Ah, think I finally found it 16:19
Zoffix \o/
jnthn There were some unlikely races, which I have fixes for all of anyway
But even that didn't nail it 16:20
Turns out that there was an issue that could cause it to not even store the native thread ID correctly in the first place
lizmat
.oO( runaway threads! )
 16:23
timotimo run away! threads! 16:35
jnthn MoarVM HEAD should unflap the native calling test on dyncall 16:36
I want to factor the code out and make dyncall and libffi share it
But getting a bit tired, so will do that later, or tomorrow :)
Geth rakudo/nom: 476741e77d | (Elizabeth Mattijsen)++ | src/core/Hash.pm
Map/Hash have their own optimized .sort

So no need to first create a Seq that generates Pairs. This should at least make Hash.perl/gist a bit more memory friendly and a bit faster.		 16:38
jnthn eh, I did the libffi thing anyway 16:50
So fixed whichever is used 16:51
I'll leave version bumping to someone else. Time to make dinner :) 16:54
[Coke] jnthn++ 16:59
Skarsnik releasable6, status 17:17
yoleaux 15:08Z <AlexDaniel> Skarsnik: I remember you had some patch that improved the situation with Gumbo slightly. Where was it?
releasable6 Skarsnik, Next release in 33 days and ≈1 hour. No blockers. Changelog for this release was not started yet
Skarsnik, Details: gist.github.com/a67665b9c2149beb46...57162d3952
Skarsnik Nice :) 17:18
AlexDaniel, it's pushed, but does not help the gumbo crash really x) 17:19
AlexDaniel it does, a little bit
Zoffix buggable: speed 3 17:26
buggable Zoffix, ▃▁▁ dates: 2017-09-17–2017-09-18; range: 3.406s–3.503s; speed: 3% faster
Zoffix Mhhmmm
Nuked rakudobrew and used my rakudo install alias now. The VMException error is gone :/ 17:27
A wild guess is some prereq module was missing or something. Oh well, we'll never know
or maybe the alias doesn't work for upgrading 17:30
Zoffix tries
Geth nqp: 862cde8ed4 | (Elizabeth Mattijsen)++ | tools/build/MOAR_REVISION
Bump Moar to get the latest libuv
 18:43
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...7-geeb664e
jnthn Also the flappy test fix :) 18:44
lizmat :-) that too! :-) 18:46
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Fix for RT #132117
travis-ci.org/rakudo/rakudo/builds/276882202 github.com/rakudo/rakudo/compare/9...c2d05f2995
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132117
Zoffix travis-ci.org/rakudo/rakudo/builds/276882202
buggable [travis build above] ☠ All failures are due to: failed make test (1 failure). Across all jobs, only t/04-nativecall/21-callback-other-thread.t test file failed.
Zoffix Hm. Upgrading with the rakudo bash alias also didn't have the VMException error. Good I guess.
Geth rakudo/nom: 198b84971d | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
Bump nqp: new libuv and fix for thread ID race
 18:59
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....2-g862cde8
0beeef9baa | (Elizabeth Mattijsen)++ | src/core/Mu.pm

All S03-operators/eqv.t tests pass again
AlexDaniel ⚠ Rakudo SQUASHathon 2017-10-07 github.com/rakudo/rakudo/wiki/Mont...Squash-Day 19:08
Skarsnik hm maybe a toaster run could be nice with a bump of libuv ^^ 19:09
timotimo well, we've done it after the release 19:13
we'll have a full month of bleeding-edge-user testing before stability-craving users get it
skids notices an unreproduceable flapper in S10-packages/basic.t test 83. 19:58
lizmat has seen that flap every now and then as well 20:02
skids Maybe we should have a "flapper" test directive that runs the test but won't trigger "TODO passed" 20:05
lizmat this feels like the "meh" command that brian d foy proposed for 5.28
skids "meh" would work too :-) 20:06
Geth rakudo: skids++ created pull request #1163:
Add Scalar indicators to Hash[].perl when needed (fix RT#132119)		 20:22
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132119
roast: skids++ created pull request #325:
Add tests for RT#132119		 20:24
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132119
nqp/jit_nativecall: cc438c5814 | (Stefan Seifert)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Map the new nativecallinvokejit OP

nativecallbuild now has a return value indicating whether we were able to JIT compile code for the call site		 20:50
nqp/jit_nativecall: 5d88bb1c98 | (Stefan Seifert)++ | 12 files
Turn nativecallinvokejit into a proper invocation op

The return type object for boxing is passed as the first child of the MAST::Call node. Includes a rebootstrap for the extension of MAST::Call
rakudo/jit_nativecall: 9 commits pushed by (Stefan Seifert)++ 20:56
gfldex can I tell Rakudo to use more OS threads then it thinks it should? 21:10
Geth rakudo/nom: 47d6c66e9f | skids++ | src/core/Hash.pm
Add Scalar indicators to Hash[].perl when needed (fix RT#132119)
rakudo/nom: da5c36c134 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Hash.pm
Merge pull request #1163 from skids/rt132119

Add Scalar indicators to Hash[].perl when needed (fix RT#132119)
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132119
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132119
roast: f775ffedaa | skids++ | S32-hash/perl.t
Add tests for RT#132119
 21:11
roast: e10819ad1f | skids++ (committed using GitHub Web editor) | S32-hash/perl.t
Merge pull request #325 from skids/rt132119

Add tests for RT#132119
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132119
Zoffix gfldex: I think that's RAKUDO_MAX_THREADS env var, innit? 21:14
skids: FWIW nine++ fixed a flopper with module tests and had a suggestion for how other floppers might be fixed: irclog.perlgeek.de/perl6-dev/2017-...i_15072650 21:16
timotimo gfldex: there's multiple knobs you can twist, RAKUDO_MAX_THREADS is one, another is to create a new ThreadPoolScheduler and putting that into your $*SCHEDULER 21:18
jnthn is also currently working on a new and much improved version of the ThreadPoolScheduler that'll handle creating new threads much more intelligently 21:19
skids Zoffix: hrm, well, that last test does rely on cwd not being changed... 21:20
jnthn timotimo: I already merged it today :) 21:21
The default maximum is now 64, fwiw 21:22
gfldex my golfed httpd is sieged by 25 worker threads and load is at 0.60 on a 6core/12thread host
timotimo cool
gfldex but then, I should check if the network stack is the bottleneck before I complain 21:24
yoleaux Zoffix: go through ecosystem and convert .child -> .add 21:27
gfldex it's the network stack :-/ 21:30
timotimo you mean the parts of rakudo that handle networking? or the actual OS? 21:31
gfldex OS 21:32
geekosaur lots of resources for linux tuning, fewer for windows and os x but they exist
for high performance web servers 21:33
jnthn enjoys this moment where Rakudo was not the bottleneck ;)
Zoffix .in 60d go through ecosystem and convert .child -> .add 21:38
yoleaux Zoffix: I'll remind you on 17 Nov 2017 21:38Z
gfldex i found the culprit. Siege needs more worker threads. 21:40
jnthn Well, there goes my enjoyment :)
lizmat and yet another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/09/18/...me-booked/ 21:41
jnthn has typically used ab on Cro with 50 and 100 concurrent workers, fwiw
lizmat: Groan :)
timotimo lizmat++ # good post 21:46
japhb OOC, is there a reason we don't expose nqp::readlink() as a Perl 6 method on IO::Path? As far as I can see, it's only available internally to the .resolve method, and that's not useful for someone writing code to check symlink correctness (especially if a long path has some symlinks that constantly change, and the user is only caring about the relatively stable symlinks within that path). 22:01
lizmat japhb: I think portability was an issue ? 22:02
japhb lizmat: Hmmm ... it doesn't look like the nqp::readlink() call in IO::Path.resolve is surrounded by #?if marks, so either that should be fixed, or the portability problem was dealt with at some point I'd guess. 22:05
timotimo probably portability between windows and the rest?
that'd be "in a different file"
japhb Oh, hmmm
Do we have a POSIX or similar module yet, wherein we get to include all that stuff that Windows users don't have? 22:06
lizmat github.com/cspencer/perl6-posix 22:07
but hasn't been updated for the past 2 years 22:08
so could well be suffering some bitrot
Zoffix lizmat++ # good weekly 22:09
Nice to see someone wrote a plugin for IRC::Client :)
japhb lizmat: Ah, and only seems to include the bits for passwd/group management 22:10
ugexe you have to use "```perl 6" to get highlighting 23:03

Powered by Cro and the Raku® Programming Language.

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

Thank you!