timotimo interesting. all the $!next accesses go through a wval for the type to find the attribute on, and they aren't being translated to a highly performant pointer-offset-read as i think they could 00:04
and of course it's being guardconc'd over and over again :D 00:05
jnthn gfldex: "imposes a maximum of 16 threads on the methods .hyper and .race" - actually on everything scheduled on the pool 00:10
gfldex: The new scheduler will be merged next week, and it's default maximum is 64 00:11
(Though it's much less likely to start threads)
[Coke] AlexDaniel: not really, though in general we should probably be doing both vs & gcc builds (I think someone was working on automated vs testing) 00:12
jnthn *its
'night, #perl6-dev
[Coke] ~~
timotimo well, that made it faster 00:23
m: say 28.6 / 34.8 00:24
camelia 0.821839
MasterDuke cool 00:26
timotimo m: say 27.15 / 34.8 00:34
camelia 0.780172 00:35
timotimo m: say 26.8 / 34.8 00:42
camelia 0.770115
AlexDaniel [Coke]: go for it then? Would be great to have a ticket in roast so that we can compare the failures next time
Geth rakudo/faster-permutations: 697010085b | (Timo Paulssen)++ | src/core/Rakudo/Iterator.pm
25% faster permutations with lexicals instead of attribute

looking at spesh, all accesses to $!next were going through a fully virtual getattr, rather than being optimized to a simple pointer offset read. Not sure why that is, but only doing that once and then using a lexical variable is a lot faster right now.		 00:44
timotimo AlexDaniel: your choice if this makes it into the release. running a spec test now 00:47
spec tests clean on my machine 00:52
AlexDaniel greppable6: permutations 00:58
greppable6 AlexDaniel, gist.github.com/cf79cb97a64ffd0bb7...a5c0923b1e
AlexDaniel timotimo: IMO it can wait. Yes, I don't think anything horrible can happen if we merge it now, but at the same time can't see any reason why it cannot wait till tomorrow :) 01:00
travis-ci Rakudo build passed. Samantha McVey 'Fix spectest.data path for Collation tests' 01:03
travis-ci.org/rakudo/rakudo/builds/276265831 github.com/rakudo/rakudo/compare/c...a695b272ac
Rakudo build errored. Aleks-Daniel Jakimenko-Aleksejev 'Log remaining changes 01:12
travis-ci.org/rakudo/rakudo/builds/276276482 github.com/rakudo/rakudo/compare/e...bb7e4aca2a
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
AlexDaniel what's wrong with travis :/ 01:32
geekosaur connection conniptions 01:34
AlexDaniel if I remove “endwin” here then it passes: github.com/azawawi/perl6-ncurses/b...asic.t#L13 01:35
with endwin it passes too, but not with ｢prove｣
geekosaur prove may not like the extra output (generally it resets cursor to bottom left and outputs deinit sequences; but initscr() is lazy about emitting them, so endwin() outputs both init and deinit!) 01:38
AlexDaniel geekosaur: okay, but why would this commit affect the behavior there? github.com/rakudo/rakudo/commit/4b...77b74cd59d 01:40
geekosaur instead of initscr(), you may want to use (assuming you have bound it) newterm
becuase the output is a pipe, which was (a) default buffered (b) not being autoflushed after that change (that was fixed in a still later commit)] 01:41
AlexDaniel geekosaur: are you saying that it should work on HEAD? 01:52
geekosaur you can also just redirect fd 1/stdout somewhere else; if you need it back, though, you will want to save the old one somewhere (via fcntl(F_DUPFD) operations in C) 01:55
AlexDaniel “But on a real terminal, it's possible it would be left in an odd state” yes, that is so 02:02
well… it runs fine with prove, but breaks the terminal when I execute the file alone
geekosaur another reason to get it off of the pipe to prove, then 02:04
travis-ci Rakudo build errored. Samantha McVey 'Add collation tests to spectest.data' 02:44
travis-ci.org/rakudo/rakudo/builds/276195219 github.com/rakudo/rakudo/compare/c...a71acb33c4
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
AlexDaniel ok, right, I see 03:27
when running prove -j … the output is now buffered, so you'll see no progress
can somebody recommend something smarter than this? gist.github.com/AlexDaniel/486717d...533d3ee312 03:37
it does work, but I find it ugly
samcv guys i fixed nqp compiling properly on Alpine Linux/musl 03:42
AlexDaniel :O \o/
samcv just pushed the fixed to MoarVM
github.com/MoarVM/MoarVM/commit/5528083df7 03:43
AlexDaniel samcv++ # rakudo everywhere! ♥
samcv :-)
that function ideally should be re-written to be not so deeply recursive. though maybe it's okay now that it's very minimal
i know when i did a stacktrace of the crash. i got 212 recursive calls to the same function 03:44
and maybe more below that, that it didn't dump the stacktrace for
so i can see why on some platforms it would not be very happy...
actually slightly curious how much it recurses 03:46
MasterDuke samcv: some old chat about it: irclog.perlgeek.de/moarvm/2017-08-07#i_14979161
samcv yeah. needs to eventually not recurse 03:48
but for now nqp compiles :)
will try out rakudo in a sec though
gonna increase the cpu's given to my vm
AlexDaniel [Coke]: thanks 03:49
releasable6: status 03:50
releasable6 AlexDaniel, Next release will happen when it's ready. 2 blockers. 154 out of 160 commits logged (⚠ 3 warnings)
AlexDaniel, Details: gist.github.com/114fe2a1c5b20575ab...bdeed8ba7d
AlexDaniel releasable6: status
releasable6 AlexDaniel, Next release will happen when it's ready. 1 blocker. 154 out of 160 commits logged (⚠ 3 warnings)
AlexDaniel, Details: gist.github.com/4b0a993370d9e0a74a...106498f701
Geth rakudo/nom: b76f7ccbfe | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/ChangeLog
Resolve Releasable warnings

Nothing wrong with longer shas, but it's 8 for consistency.		 03:53
samcv so it makes 99 recursive calls
total 100 if you include the outermost call to optimize_bb (this in when compiling nqp)
actually i think i can remove all recursion that happens when there's only one subnode 03:54
i just thought of something
so it will only have to do a recursive call if there's at least 2 subnodes, not just 1 03:55
Geth rakudo/unbuffered-for-prove: d3f542d65b | (Aleks-Daniel Jakimenko-Aleksejev)++ | lib/Test.pm6
Fix needless buffering when running prove with -j

  See RT #132108		 03:56
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132108
MasterDuke good deal
samcv that reduced recursion to 29 03:57
Geth rakudo: AlexDaniel++ created pull request #1160:
Fix needless buffering when running prove with -j
MasterDuke and i'm outa here. later...
AlexDaniel me too
samcv bye!
AlexDaniel .tell jnthn ? green light from me. SNAFU with Windows and JVM spectests, but it builds fine. No more blockers besides minor RT #132108 (it's a rakudo issue so doesn't prevent you from cutting a moar release). Besides that, everything looks fine from here. Good luck with moar release! ♥ 04:06
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132108
yoleaux AlexDaniel: I'll pass your message to jnthn.
AlexDaniel If somebody knows about some potentially serious issue, please .tell me or create a ticket. Don't expect me to magically read your mind :) 04:08
see you in ≈9 hours o/
.oO( if not more )
 04:09
samcv even without my fix which reduces recursion at least in nqp compile by 1/3, i can still pass roast as well :) 04:15
yay for fixes
Geth roast: skids++ created pull request #321:
Add fudged tests for RT#129215		 07:35
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=129215
roast: 741df515b3 | skids++ | 2 files
Add fudged tests for RT#129215

Perplexingly not be replicable by CompUnit::, needs a real "use"		 07:36
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=129215
Geth roast: 272ce38005 | skids++ (committed using GitHub Web editor) | 2 files
Merge pull request #321 from skids/rt129215

Add fudged tests for RT#129215
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=129215
gfldex i keeped the golfed httpd under siege over night and rsize went from ~500MB to 1.5GB. So there must be a small memory leak somewhere. 07:41
code: gist.github.com/c11e196c2d1c371184...291a98703e 07:42
moritz does anybody happen to know where <( and )> handling in regexes is implemented? 09:08
<( and )> are not so great to grep for
or a greppable name would also help 09:09
found it: token metachar:sym<from> { '<(' <.SIGOK> } 09:14
lizmat Files=1227, Tests=74774, 295 wallclock secs (11.68 usr 4.77 sys + 1997.32 cusr 207.97 csys = 2221.74 CPU) 09:39
.tell timo good catch with 1ca81432af51b842ca0f0 That was really a typo 09:43
yoleaux lizmat: I'll pass your message to timo.
moritz m: say "abc" ~~ m/b/; 09:46
camelia ｢b｣
moritz m: say "fooABCdef" ~~ /\w+ & ABC.+/ 10:00
camelia Nil
moritz m: say "fooABCdef" ~~ /\w+ & [ABC.+]/
camelia ｢ABCdef｣
moritz I thought & was supposed to be pretty close to | in precedence 10:01
was I wrong? or is that a bug in rakudo?
the parse tree with --target=parse also looks very different for these two cases 10:02
timotimo A. 10:22
oops, i was timo before, now yoleaux has a message for me on that nick
lizmat ah well, you go the message :-) 10:26
timotimo aye 10:30
did you see i found the opportunity for a 25% speedup in permutations? :)
lizmat is that committed already ? 10:31
timotimo nope, on a branch for after the release 10:32
i saw in the spesh log that $!next was being compiled to a rather wasteful version for some reason
lizmat ah, ok, no, didn't see
timotimo so i took it out into a lexical
lizmat ah, that
yeah, that's a general issue with attributes 10:33
and one that according to jnthn, can not be fixed easily
generally
many push-all candidates use lexicals instead of attributes for that very reason
timotimo hmm 10:34
anyway, that gets us to a little more than 10x slower than python 10:35
lizmat somtimes I think we should use "is cached" on that :-)
timotimo it'd be cool if we had a really fast skip method 10:38
i was looking at the fannkuch benchmark which runs computations over all permutations of the list of numbers from 1 through n
in the energy-benchmark thingie you linked to recently the implementation was using multiple threads 10:39
and those programs have implementations of permutations that can skip ahead to any point with only fractional computation i guess
so splitting the whole work up is much faster
i mean, we can copy the pull-one code and just not create the clone of the values and that'll already be a bit faster 10:40
Skarsnik Hello 10:46
timotimo hi 10:51
Skarsnik releasable6, status 10:54
releasable6 Skarsnik, Next release will happen when it's ready. 1 blocker. 154 out of 161 commits logged
Skarsnik, Details: gist.github.com/a7579cf6fc177e24ad...65f2fe2dbd
Skarsnik :) 10:55
timotimo hm. why is it "skip-at-least"? why not "skip-at-most"? 11:01
"at least" looks like it'd skip more if it wants to
so you can't use that to skip to an exact position
pmurias if I'm emulating uint8, uint16, int8, int16 etc on the js backend should I emulate the wrapping? 11:05
that is when storing a bigger than 2**8 value in a uint8 simulate an overflow with a modulo?
Skarsnik m: my uint8 $a = 255; say ++$a; 11:06
camelia 0
Skarsnik m: my uint8 $a = 255; say $a;
camelia 255
Skarsnik m: my uint16 $a = 2**16; say $a; say ++$a 11:10
camelia 0
1
Skarsnik m: my uint16 $a = 2**16 - 1; say $a; say ++$a
camelia 65535
0
Skarsnik dang this get fixed recently?
timotimo huh 11:19
i don't remember a fix for that going in
Skarsnik I remember the uint8 warping to -1 x) 11:20
lizmat timotimo: re skip-at-least: skip-at-most could indicate it could skip less if it wanted to 11:21
timotimo implementing skip-at-least in the permutations iterator by just not cloning the $permutated array every step and putting the loop inside the method makes it crazy fast
lizmat: okay, then why not skip-exactly?
lizmat because you cannot guarantee that you *can* skip that many ? 11:22
timotimo why is it okay if i permutations(9).skip(1000) to get, for example, element 5000 instead?
lizmat it's not: it's supposed to skip that many if it can
# Skip the given number of values. Return true if succesful in 11:23
# skipping that many values.
timotimo in that case i still find the name strange :)
it's far too late now to change anything, but i'd've perhaps gone with "try-skip-exactly"
lizmat well, I guess I was inspired by "push-at-least"
timotimo why not inspired by push-exactly? 11:24
push-exactly can also push fewer than requested
lizmat ah... the mists of time
I guess the answer is: why didn't anybody point that out to me 2 years ago :-) 11:25
timotimo yes!
past-timo has been slacking off recently
lizmat hmm.. actually, about a year ago 11:26
:q
oops
nine So...where do those args get boxed again? :( 11:37
lizmat nine? 11:38
nine Looks like my native sub gets an Int again, after all the trouble to write a real native i64 to a local register. But I don't see where it could get boxed. The arg_i op just assigns an i64 to the arg register. And the source is the result of a decont_i. 11:41
lizmat there's a lot of places where native ints get boxed :-) 11:43
automagically 11:44
nine But that should be visible in the bytecode at least, and I don't see it: gist.github.com/niner/a0f2dd8d4efe...eda2d1c636
The code before the prepargs is the same as in the working version, so I assume it's correct. And then there's just arg_i which simply does not box. 11:45
Even more, between the prepargs and ncinvoke we are guaranteed not to allocate anything, which rules out boxing. 11:46
timotimo how and where do you notice it's boxed? 11:47
nine Here's the corresponding MAST: gist.github.com/niner/b32b5f9df57b...48f600f264
timotimo: fprintf(stderr, "first arg: %d\n", tc->cur_frame->args[0].i64); gives me "Got: -275024512" 11:48
timotimo i'm entirely unused to reading MAST with its "arguments on separate lines" shtick 11:49
nine timotimo: which looks like a pointer to me and true: fprintf(stderr, "first param: %s\n", tc->cur_frame->params.args[0].o->st->debug_name); gives me "first param: Int"
timotimo right, i see it clearly setting the 0 value into the local that it's later using in the call node 11:50
nine timotimo: the 0 is only the case when we pass an undefined Int. line 21/24 is the normal case
timotimo have you tried reverse debugging with rr?
nine Not yet. The undefined int32 case seems to actually work 11:52
But that of course might just be accidentally
[Tux] This is Rakudo version 2017.08-161-gb76f7ccbf built on MoarVM version 2017.08.1-171-gcf95892e 11:53
csv-ip5xs 1.316 - 1.337
test 9.647 - 9.895
test-t 3.476 - 3.503
csv-parser 10.825 - 11.037
nine Ok, it may be an Int, but it's not the actual arg (value is 0, should be 42). So I'm looking in the wrong place for that parameter. 12:00
timotimo it's the right call, though, right? 12:01
nine So where would my arg be if not in tc->cur_frame->args[0]?
timotimo you're not accidentally looking at what your frame is being called with?
well, that's where the arg_* ops write 12:02
nine Oh, I actually meant tc->cur_frame->params.args[0].i64 12:03
Though both seem to give the same value 12:04
timotimo cur_frame->args is where the values from arg_* are written
so i assume cur_frame->params.args is what got passed to the current frame when it was invoked
nine So cur_frame->args might actually be the better place to look, as ncinvoke won't set up a new call frame and thus not initialize cur_frame->params.args 12:11
Ooooh...the value I'm looking for is actually in tc->cur_frame->args[1].i64. I wonder how it ends up in 1 instead of 0 12:15
Skarsnik 0 is return value or something weird like that? 12:16
jnthn Nope, returns aren't done via the args buffer
Perhaps an off-by-one in code-gen? 12:17
nine Well I do pass the return type object as first child of the nativecallinvokejit op. QASTOperationsMAST's $call_gen shifts it out of @args, just like it does with the callee. 12:18
But of course, I then pass it on as part of @arg_regs. 12:19
Ah, I think, I see it. I correctly initialize arg_pos in the MAST compiler, to skip this in args processing, but args_pos is also written to the bytestream for indexing the args array. 12:20
I'll have to subtract it there, too.
samcv did yapc eu videos ever get published? 12:46
timotimo are you refering to TPCiA? 12:47
samcv uh the one in amsterdam
timotimo yeah, there's a few videos on line from that
samcv i mean there were preliminary videos but what about the nicer ones with mics
i heard were gonna come out a month after the conf 12:48
timotimo huh, no mention in the weekly, eh
it must be like you say, then
nine All tests successful. :) 12:49
timotimo cool!
a bit too late for the release, but still exciting 12:50
i need an example xhtml file for the web server test thinige
Skarsnik github.com/Skarsnik/perl6-gumbo/bl...fancy.html ? 12:51
timotimo gfldex: i ctrl-c'd siege while running against your web server and moar crashed with a broken pipe signal :o 13:04
Geth nqp/jit_nativecall: 38a26adceb | (Stefan Seifert)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Turn nativecallinvokejit into a proper invocation op

The return type object for boxing is passed as the first child of the MAST::Call node.		 13:09
nqp/jit_nativecall: ac6e45ae46 | (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		 13:10
rakudo/jit_nativecall: fc4d784617 | (Stefan Seifert)++ | lib/NativeCall.pm6
Explicitly pass the params to nativecallinvokejit
 13:11
rakudo/unbuffered-for-prove: aca6f9bfa8 | (Aleks-Daniel Jakimenko-Aleksejev)++ | lib/Test.pm6
Oops. Un-buffer stderr, not stdin
 14:22
AlexDaniel o/ 14:28
lizmat AlexDaniel: feels to me that should go in before the release ? 14:30
Skarsnik should I toast this? 14:31
Not sure I have time left on the vm instance thou before having to rebuild it
AlexDaniel lizmat: yeah, I think so 14:32
Skarsnik: as for toasting this, I really can't see how it can possibly affect anything negatively… but we've been proven wrong so many times :) 14:33
.oO( prove…n )
so IMO toasting not necessary, but if you have willingness to do it I wouldn't object :) 14:34
lizmat hmmm... did we just gain 8K tests in roast ? 14:39
I guess we did in the past 36 hours or so 14:40
AlexDaniel collation? 14:41
lizmat I guess
AlexDaniel github.com/perl6/roast/commit/5568...145eaae55d
anything wrong with that?
lizmat yup, that'd be the one
no, I was just wondering where they came from 14:42
AlexDaniel /o\ when was the last bump 14:50
Skarsnik_ bumpable6, when 14:51
timotimo did something go wrong in the mean time?
AlexDaniel timotimo: not sure, what's the meaning of this? ci.appveyor.com/project/rakudo/rak...ql54fxyn1j 14:52
timotimo somehow it's trying to use make instead of nmake 14:53
oh 14:54
that's only after the explosion
are we running into some nmake limitation again? =o
samcv AlexDaniel, i'm investigating that zef issue now 14:59
AlexDaniel samcv: OK. Let me know if you find something
timotimo AlexDaniel: can you get appveyor to output the makefile? 15:00
AlexDaniel timotimo: Dunno. Looking at the dates of these failures, maybe it's this commit? github.com/MoarVM/MoarVM/commit/23...43678d73ac 15:02
:S
timotimo perhaps nmake doesn't understand this ifneq thing? 15:03
!IF "a" == "b" (also !=) ifeq (a, b)
(also ifneq)
nmake on the left, gnu make on the right
and it wants an !ENDIF at the end
Geth rakudo/unbuffered-for-prove: bc6b1160ba | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Frequent bumps are good before the release
 15:10
AlexDaniel dammit /o\ wrong branch
timotimo heh
Geth rakudo/nom: 85514723da | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Frequent bumps are good before the release
 15:11
Zoffix parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}
export PS1="\u@\h\[\033\]\w\[\033\]\$(parse_git_branch)\[\033\]$ "
put in your bash files to show current branch in bash prompt 15:12
AlexDaniel that's a good idea, yea 15:13
timotimo: remind me, why is there no appveyor for moarvm repo? 15:16
timotimo um, i think the moarvm repo owner has to set it up?
AlexDaniel github.com/MoarVM/MoarVM/issues/693 15:18
timotimo: I think you had it working in your fork? Maybe you can give some hints on how to do that in a comment? 15:20
timotimo i don't remember >_< 15:21
AlexDaniel ok that was quick
timotimo also it'd be nice if the appveyor would be under the moarvm org
what was?
AlexDaniel github.com/MoarVM/MoarVM/commits/master 15:22
look
timotimo oh, huh
gfldex m: my &note = BEGIN &note; 15:23
camelia 5===SORRY!5=== Error while compiling <tmp>
Cannot use variable &note in declaration to initialize itself
at <tmp>:1
------> 3my &note = BEGIN &7⏏5note;
expecting any of:
term
samcv .ask lizmat any clue when the official YAPC-EU-2017 videos will be coming out? Thanks! 15:24
yoleaux samcv: I'll pass your message to lizmat.
lizmat .
yoleaux 15:24Z <samcv> lizmat: any clue when the official YAPC-EU-2017 videos will be coming out? Thanks!
lizmat I asked Sawyer about 2 weeks ago, no answer
so I'm afraid they'll be there when they're there :-( 15:25
samcv :-(
Geth rakudo/nom: d3f542d65b | (Aleks-Daniel Jakimenko-Aleksejev)++ | lib/Test.pm6
Fix needless buffering when running prove with -j

  See RT #132108		 15:54
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132108
Geth rakudo/nom: aca6f9bfa8 | (Aleks-Daniel Jakimenko-Aleksejev)++ | lib/Test.pm6
Oops. Un-buffer stderr, not stdin
rakudo/nom: 9073a4dc7f | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | lib/Test.pm6
Merge pull request #1160 from rakudo/unbuffered-for-prove

Fix needless buffering when running prove with -j
Zoffix New blog post: "The Rakudo Book Project": rakudo.party/post/The-Rakudo-Book-Project 16:33
Skarsnik good luc on this big project :) 16:36
Zoffix Thanks :)
Zoffix gets cracking 16:37
travis-ci Rakudo build errored. Aleks-Daniel Jakimenko-Aleksejev 'Merge pull request #1160 from rakudo/unbuffered-for-prove 16:50
travis-ci.org/rakudo/rakudo/builds/276542491 github.com/rakudo/rakudo/compare/8...73a4dc7f69
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
Geth rakudo: Gnouc++ created pull request #1161:
remove bad comment of srand		 17:01
rakudo/nom: 9eeb357111 | (Cuong Manh Le)++ | src/core/Num.pm
remove bad comment of srand
 17:36
rakudo/nom: 7b9e103736 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Num.pm
Merge pull request #1161 from Gnouc/nom

remove bad comment of srand
nqp: 71c775feee | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
Pre-release MOAR_REVISION bump
 17:55
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...-gf76ae338
rakudo/nom: 3f47eba373 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
Pre-release NQP_REVISION bump
 17:57
¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....g71c775fee
travis-ci Rakudo build passed. Zoffix Znet 'Merge pull request #1161 from Gnouc/nom 18:23
travis-ci.org/rakudo/rakudo/builds/276565331 github.com/rakudo/rakudo/compare/9...9e103736be
AlexDaniel didn't quite bump to the last moar version, heh :) 18:30
travis-ci Rakudo build passed. Aleks-Daniel Jakimenko-Aleksejev 'Pre-release NQP_REVISION bump' 18:52
travis-ci.org/rakudo/rakudo/builds/276569831 github.com/rakudo/rakudo/compare/7...47eba3734c
lizmat AlexDaniel: fwiw, tests clean on my machine 19:15
(on Moar, I don't do JVM anymore)
timotimo dangit
the appveyor build failed, and there's no explanation in the log 19:16
perhaps it timed out from too much work
AlexDaniel timotimo: which one? 19:21
ah, in MoarVM repo?
timotimo nah, under timo/ 19:25
ci.appveyor.com/project/timo/moarvm
Geth roast: skids++ created pull request #322:
Add tests for RT#111474		 20:39
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=111474
roast: 24de54a28d | skids++ | S05-metasyntax/interpolating-closure.t
Add tests for RT#111474
roast: 1bbe3c9d35 | skids++ (committed using GitHub Web editor) | S05-metasyntax/interpolating-closure.t
Merge pull request #322 from skids/rt111474

Add tests for RT#111474
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=111474
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=111474
roast: 951079df0d | (Elizabeth Mattijsen)++ | S32-encoding/registry.t
Encoding.alternative-names should return a List
 20:41
nqp: 1fd30a8963 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
Pre-release MOAR_REVISION bump
 20:49
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...-g0f59f0cf
rakudo/nom: 68e54f98f0 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
Pre-release NQP_REVISION bump
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....g1fd30a896
1c985681c0 | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/ChangeLog

Enforcing short line length to be more email-friendly. Novel MoarVM subsubsection is interesting, but if we do it we should be doing it consistently, therefore I will leave out it for now.
One change is without a sha reference but that's OK. ... (5 more lines)
AlexDaniel wants this badly: github.com/perl6/whateverable/issues/232
lizmat pulls, builds and runs a spectest 20:51
AlexDaniel lizmat: well, this only contains the nmake fix (revert) for MoarVM 20:53
lizmat well, can't hurt to run them anyway, right?
AlexDaniel of course :)
lizmat++
ehh… t\04-nativecall\21-callback-other-thread.t on windows. Is it a flapper or… 20:57
timotimo i think i've heard it flap in recent days 21:01
AlexDaniel yea 21:03
created a ticket for it: RT #132114 21:04
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132114
AlexDaniel but it looks good
lizmat looks ok to me
samcv AlexDaniel, i wasn't able to reproduce that zef issue. it could be rakudobrew based, not sure 21:07
at least should prolly not be an issue since i was able to install it manually
AlexDaniel ok
timotimo: what would be the short description for your [1ca81432][488ca6f0] commits? 21:18
timotimo oh where were those? 21:19
AlexDaniel github.com/rakudo/rakudo/commit/1ca81432 github.com/rakudo/rakudo/commit/488ca6f0
timotimo oh 21:20
AlexDaniel “Fixed permutations/combinations iterator” sounds too big :)
timotimo sorry, can't browser right now
AlexDaniel and anything more specific wraps on multiple lines…
timotimo hm, it probably only has a performance impact, if at all
i don't think it needs to be mentioned in the changelog
AlexDaniel but wasn't it about some actual bug that needed fixing? 21:21
timotimo only if you manually grab the Rakudo::Iterator.permutations i think 21:25
AlexDaniel OK 21:26
lizmat perhaps a new JVM backend target: www.eclipse.org/openj9/oj9_faq.html 21:37
lizmat calls it a day 21:48
rakudo/nom: 9d2dabf5d2 | (Aleks-Daniel Jakimenko-Aleksejev)++ | 3 files
Make it clear that this is a Perl 6 script

Also add a shebang. “pl6” because other files in that folder use “pl6”.		 22:06
rakudo/nom: 213c3e3e6f | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/announce/2017.09.md
Generate release announcement for 2017.09
AlexDaniel huggable: ^delete no relase 22:10
huggable AlexDaniel, Didn't find no relase in the database
AlexDaniel huggable: ^delete no release
huggable AlexDaniel, Didn't find no release in the database
AlexDaniel huggable: ^delete no release?
huggable AlexDaniel, Marked factoid `no release?` as deleted
AlexDaniel OK, Moar release is there, so indeed we're a few moments away from Rakudo release now :) 22:34
Geth rakudo/nom: 8b05c34ac7 | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Reflect actual date, claim next release
 23:14

Powered by Cro and the Raku® Programming Language.

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

Thank you!