[Tux] This is Rakudo version 2017.09-38-g78a4824b8 built on MoarVM version 2017.09.1-18-g3a2eab52 06:28
csv-ip5xs 1.345 - 1.493
test 9.903 - 10.491
test-t 3.441 - 3.481
csv-parser 12.786 - 12.944
samcv, your changes still not merged? 06:29
Error encoding UTF-8 string: could not encode codepoint 1939620 (0x1D98A4), codepoint out of bounds. Cannot encode higher than 1114111 (0x10FFFF)
in block <unit> at 88.t line 7
samcv i will merge it right now. let me just check appveyor
[Tux] Error encoding UTF-8 string: could not encode Unicode Surrogate codepoint 56625 (0xDD31)
in block <unit> at 88.t line 7
samcv ok bumping now 06:30
Geth nqp: a5f92f2fe3 | (Samantha McVey)++ | tools/build/MOAR_REVISION
Bump MoarVM: Fix 2 big utf8-c8 bugs & fix MacOS build

utf8-c8: Fixes a bug where encoding values above 0x10FFFF or Surrogate codepoints would throw and fail.
Fixes a bug with utf8-c8 where concatenation, replace, or ... (11 more lines)		 06:38
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...-g523725a3
rakudo/nom: 963a0f0657 | (Samantha McVey)++ | tools/build/NQP_REVISION
Bump Moar/NQP: Fix 2 big utf8-c8 bugs & fix MacOS build

utf8-c8: Fixes a bug where encoding values above 0x10FFFF or Surrogate codepoints would throw and fail.
Fixes a bug with utf8-c8 where concatenation, replace, or ... (15 more lines)		 06:39
samcv [Tux], ok :) go ahead
Geth ¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....ga5f92f2fe
samcv if you have the time to run the tests again
[Tux] samcv++; # 88.t doesn't crash anymore! 06:48
samcv :-)
i think i fixed basically everything in my grant tbh :P 06:49
[Tux] HUGS are in place :)
you deserve them
samcv well if i come back to NL i will accept a hug :) 06:50
and to think i was worried about meeting the grant, but ended up exceeding it
[Tux] This is Rakudo version 2017.09-39-g963a0f065 built on MoarVM version 2017.09.1-21-g523725a3 06:51
csv-ip5xs 1.322 - 1.341
test 9.810 - 9.912
test-t 3.407 - 3.577
csv-parser 12.585 - 13.040
within the noise range. no significant slowdown 06:52
lizmat Files=1227, Tests=75100, 295 wallclock secs (14.55 usr 5.20 sys + 1997.49 cusr 211.59 csys = 2228.83 CPU) 07:08
Geth rakudo: stmuk++ created pull request #1167:
japhb++ die where --jobs > 1 used 		09:28
rakudo/nom: 99f90e6528 | (Steve Mynott)++ | t/harness6
japhb++ catch case where --jobs used
 10:40
rakudo/nom: 045ef448b6 | lizmat++ (committed using GitHub Web editor) | t/harness6
Merge pull request #1167 from stmuk/nom

  japhb++ die where --jobs > 1 used
rakudo/supply-block-refactor: 9d903408e3 | (Jonathan Worthington)++ | src/core/Supply.pm
Push Tap objects down to subscribers

The `.tap(...)` call now takes an optional `:&tap` named argument that will be called, synchronously and ahead of any `emit`/`done`/`quit`, with the Tap object. This means that there is now a reliable way to get the Tap object, no matter the behavior of the source Supply. There were two notable cases where we had trouble: ... (14 more lines)		 11:15
nqp/master: 9 commits pushed by pmurias++ 12:06
jdv79 what's a easy way to build and use a modified moar? 12:41
jnthn Easy to understand what's going on? Just get checkouts of NQP and Rakudo, and perl Configure.pl --prefix=/path/to/moar/install 12:43
For most MoarVM changes you won't need to rebuild NQP/Rakudo
You can just change stuff and make -j install in MoarVM
jdv79 ok 12:55
lizmat commute to NR.pm meeting& 12:56
jnthn I just had to write this gist.github.com/jnthn/25349dee44f2...dbe504c39e to help me debug a problem 14:02
Figure it may be useful more generally
Polished version of it could end up as a module
timotimo oh, that's cute 14:03
jnthn Hate bugs that rarely show up though 14:06
Though presumably if I could always get it to show up in 20,000-30,000 requests before, surviving 250,000 would be a decent indication I got it 14:07
Well, it did 14:15
(having a big supply-using thing to test on)++ 14:16
Geth rakudo/supply-block-refactor: 0d600a0cb6 | (Jonathan Worthington)++ | src/core/Supply.pm
Don't re-acquire lock after running supply body

Instead, just use the one we're already holding to decrement the active tap count. Prevents a potential deadlock if an `emit` gets in from one of the `whenever`s and then does some kind of `await`.		 14:22
jnthn Wow, that fix also gets performance back to being pretty good :) 14:26
Guess that was contended over quite a bit
That leaves me with just the throttle issue 14:30
"just" 14:37
DrForr Ah, "just". That final 80% that you find after digging through the first 80%. 14:40
jnthn I do somewhat fear that it might unravel a bunch of the changes too :/
Just discovered a Cro HTTP/2 hang, which I somewhat feared may happen because it uses a "supplies in the chain talking to each other" approach also 14:42
jdv79 not sure what that means. 14:44
sounds racy though
DrForr girds himself for his first Prague.pm social.
jnthn DrForr: Hm, when/where's that? I thought I was on the mailing list but didn't see anything for ages... 14:48
DrForr Tonight at 7pm, "Prague Perl Mongers meeting is planned for Thursday September 21st at 7 PM at the "BeerGeek" bar, Jiřího z Poděbrad. 14:49
I don't know if it got to the mailing list, I'm not on it myself.
Maybe someone *thinks* they're sending announcements to a dead list? 14:50
beergeek.cz at Vinohradska' 62 apparently.
I'm close enough that I can drop my bag off at home and head over.
jnthn DrForr: Wait, you're based in Prague these days? 14:51
DrForr Moved here on the 1st as it happens. 14:52
DrForr waves from the GoodData offices.
jnthn Ah. :-)
Zoffix :) 14:53
jnthn Yeah, www.mezl.eu/praha-pm doesn't mention it at all :)
DrForr I also note that most of the Mailing List links are crossed out. 14:55
jnthn Yeah
Just noticed that
If you know (or find out) how I can find out when meetings happen, I'd love to know :) 14:56
Can't make it tonight, alas; if I'd known some days sooner I probably coulda. Next time... 14:57
DrForr I just asked the person that passed me the info what's going on, so I'll pass it along to you when I get it.
No worries, I figured that was the case.
I'm outta here, off to said meeting. 15:00
o/
jnthn Have fun o/
m: my $s1 = Supplier.new; my $s2 = Supplier.new; Supply.merge($s1.Supply, $s2.Supply).tap: { say $_; $s2.emit(2) }; $s1.emit(1) 15:25
camelia (timeout)1
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2…
jnthn That hangs in my branch also, after the say 1 15:27
m: my $s1 = Supplier.new; $s1.Supply.tap: { say $_; $s1.emit(2) }; $s1.emit(1) 15:29
camelia (timeout)1
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2…		 15:30
jnthn m: my $s1 = Supplier.new; $s1.Supply.tap: { say $_; $s1.emit(2); say "here" }; $s1.emit(1) 15:31
camelia (timeout)1
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2…
jnthn oh hah, because it was using a reentrant mutex for the protection...
DWIM is hard. 15:34
Hm, well, I may have something approaching a solution... 16:50
ah, no :( 16:53
Or at least, not without further changes
nine So still _approaching_ a solution, not already there 16:54
jnthn Yeah, hopefully 16:55
jnthn is curious what the spectest fallout will be
It does actually fix some stuff
sjn if there's no solution, it's all precipitate :)
jnthn I guess while what I have works it introduces a tad too much concurrency in places 16:56
And that maybe is the reason things break 16:57
Wow, the only regression is a new hang 16:58
In 1 file
OK, maybe it's not so wildly off given I know of 2 things that are probably still a bit wrong, then
Geth roast/rt132135: b0cd4b3edf | (Justin DeVuyst)++ | S32-io/IO-Socket-Async.t
Tests for async socket returned port values. See RT#132135.
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132135
jnthn In the very best case, the mechanism I've come up with now might eliminate and solve more problems that the one I did yesterday. Not sure yet. 17:03
We'll see tomorrow. 17:04
b2gills Sometimes you have to go down the wrong route for a while to find the right one 17:15
nine Aw crap. Compiling the optimized body for a native sub in a CHECK phaser would require the setup for that routine to have already run. But that actually loads the library which we do only at runtime. 17:31
So...I'd have to export an INIT phaser, too which runs the setups? 17:32
But the nativecallbuild op which loads the library as part of setup also returns whether we can JIT compile the call or not. 17:40
So I'd need to restructure that whole part of the code to get the information in a separate step without loading the library :/ 17:41
At least I just found out why compiling the optimized code for subs called at BEGIN time fails: the $!do attribute is bound at runtime during the fixup. So while I did set it just fine after compilation, it got overwritten by the original block: { * } 17:56
Geth nqp: 1177ace084 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java
Revert "Error reporting tweak."

It's ok to return null if exception has no message.
This reverts commit d228c929f85fa96e043fc30c3439880169e9484d.		 18:42
jnthn nine: Doing anything at INIT time for native calls is probably now roth it 20:42
*worth
nine: Since typically only so many of the possible native subs are called by a given application
So it's cheaper to pay for just some of 'em
nine jnthn: would be nice if we could at least do the compilation at CHECK time. Inline::Perl5 does use quite a few native subs even for trivial programs. And it should be possible to move a part of the setup cost to installation time. 20:46
And it actually is! I don't actually need the decision right away. As it's installation time (or worst precomp time), I can just compile both versions, the JIT compiled and the fallback and only decide which of those to install at runtime.
jnthn Yeah, CHECK time makes more sense 20:47
old.cd.cz/zazitky/kam-na-vylet/1758...nice-v-pid
oops
Since JIT happens at runtime the resolution happens late enough for it to produce the good code, so all's well 20:48
gfldex is a long running program meant to segfault when I rebuild the Rakudo it is using? 20:58
jnthn I guess you'd have to re-install it to affect things? 20:59
I've hard this before, though 21:00
*heard
nine has seen it happen a couple of times 21:03
jnthn So, sounds like it does. As for "meant to", I'm pretty sure nobody set out with it as an explicit goal. ;) 21:06
Maybe a consequence of us mmap'ing stuff and then it changes underneath us? 21:07
gfldex on linux the mmaped file (as opposed to the files directory entry) should stay intact until the last filehandle is closed (and thus the inode in /proc/$pid/fd/ is gone) 21:24
i will try to do some digging on the weekend 21:25
teatime iirc, this is often caused by overwriting existing executable rather than unlinking the old and creating the new; if you unlink, as gfldex says the old file continues to exist as long as stuff has it open. 21:26
jnthn Ah, maybe our install does a copy and that's not doing the unlink/create new thing 21:27
teatime iirc again, cp actually does unlink first for this reason. 21:29
gfldex takes notes not to build Rakudo on windows
teatime hrm, or actually, I think it's mv that does that, possibly not cp 21:38
timotimo i've put a bit of work into making rakudo install not just cp into existing .moarvm files 22:08
to prevent exactly that kind of crash you're describing
could very well be i missed a case or two
look for a perl6 command inside the makefile
it'll also show up in the output of "make install"
Geth 6.d-prep: 795b56ead6 | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/README.md
List passing Windows strestest

as a TODO item for release		 22:10
ugexe i've gotten into a chicken/egg spot with the perl6 file deletion inside the makefile before 22:41
teatime there's also install, if you don't want to mv; I was wrong about cp and thinking of mv 22:44
timotimo is there install on windows in nmake? 22:51
teatime I know almost nothing about windows :) 22:52
timotimo yeah, putting smarter stuff into the makefile is a great way to break the build on a platform hardly anybody tests at the moment 22:54
Geth roast: skids++ created pull request #327:
Add test for RT#129812		 23:25
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=129812
roast: fd1a92f9e9 | skids++ | S06-traits/misc.t
Add test for RT#129812
roast: 63181b3c9f | skids++ (committed using GitHub Web editor) | S06-traits/misc.t
Merge pull request #327 from skids/rt129812

Add test for RT#129812
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=129812
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=129812
roast: c8a7565a68 | (Zoffix Znet)++ | S05-match/positions.t
Test all regex blocks update $/

RT#126249: rt.perl.org/Public/Bug/Display.html?id=126249		 23:51
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126249

Powered by Cro and the Raku® Programming Language.

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

Thank you!