Zoffix . 01:10
[Coke] … 01:18
Zoffix: close on fixing the (*&#$ docs cronjob.
installed newer node; then had to fix the pathing in the cron job. then had to recompile the highlights. ... now it's failing in non-cron also, with a version mismatch. I think I just fixed the last issue blocking that. testing. 01:19
(crap. still failing.) 01:20
aha, maybe? 01:23
Zoffix "aha"? What? 01:24
m: 0 ^^ -> {say 2}
camelia ( no output )
[Coke] current guess: it's node-gyp; it was only installed in the OLD node/npm, not the new (working) one,. 01:25
Zoffix I would've thought there'd be output based on: github.com/rakudo/rakudo/blob/2545...ol.pm#L113
[Coke] and it's standaone, so none of the new npm calls worked with the old compiles of the old node-gyp. installed node-gyp via the new node/npm, testing now
ok. unbroke the live-from-the-user's shell build. 01:26
Zoffix Seems Callable candidates for infix and/or/xor can be removed; they do the same thing as mu: github.com/rakudo/rakudo/blob/2545...#L134-L145
[Coke] once that runs, will do a cron based build.
Zoffix m: &infix:<^^>(1, -> {say 2; False}) 01:27
camelia 2?
Zoffix ahh
so what's the idea behind &infix processing Callables, but the grammar one not? 01:28
[Coke] (it is highlighting things now, so that's win-ish) 01:30
Zoffix Filed the inconsistency as rt.perl.org/Ticket/Display.html?id=131932 01:34
[Coke]: just be sure to write down all your steps so that we can painlessly get docs up to speed after next system upgrade.
buggable: uptime 01:44
buggable: eco Ddt 01:50
buggable Zoffix, Ddt 'Distribution Development Tool similar to mi6': github.com/kalkin/Ddt 1 other matching results: modules.perl6.org/s/Ddt
Zoffix timotimo: the "says 2" was because of an off-by-one. Why there are two is because the author listed two meta files for it: github.com/perl6/ecosystem/blob/ma...#L759-L760
I've no idea why people do this and tempted to prune that stuff.
(there are more instances of that)
[Coke] ok. I think docs are now building correctly via cron. 02:17
added some pitiful notes to the host admin docs in github.
Zoffix \o/ [Coke]++ 02:18
samcv no other unicode related stuff has come up since yesterday hopefully? 04:05
checking in as i've been offline most of today
nine Oh, I just realized that I posted this on MoarVM. All the Windows build needs is someone to figure out how to set an environment variable in a Makefile. The fix could look like this: gist.github.com/niner/b71ecb3b0a02...09ad66ef16 08:39
I just can't test it as I don't have Windows anywhere.
AlexDani` . 09:05
yoleaux 08:35Z <nine> AlexDani`: The fix for the Windows build could look like this: gist.github.com/niner/b71ecb3b0a02...09ad66ef16
AlexDaniel .
yoleaux 08:29Z <nine> AlexDaniel: really everything that's missing for unbreaking the Windows build is someone to figure out how to set an environment variable in a Makefile on Windows
AlexDaniel new day, new release quests! Good morning everybody 09:06
nine: awesome, thanks 09:10
except that… I don't have windows
ugexe: any chance you can test this patch? ?
nine ugexe is probably asleep for a couple more hours... 09:14
AlexDaniel then we need another hero :) 09:16
ooor… 09:17
or we just push the fix and see what happens on AppVeyor 09:18
Geth rakudo/nqp-lib-windows: 484d2403f0 | (Stefan Seifert)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | 3 files
Fix windows build
 09:23
stmuk AlexDaniel++ 09:25
AlexDaniel hm, it's not going to test it by default on some branch?
so I'll have to submit a PR with it
Geth rakudo: AlexDaniel++ created pull request #1134:
Fix windows build		 09:26
AlexDaniel squints 09:32
that's a different issue, isn't it?
nine It couldn't even build moar 09:35
lizmat . 09:37
AlexDaniel irclog.perlgeek.de/perl6-dev/2017-...i_15039567 09:38
nine Here's a crazy idea: why not let people who are actually interested in using Windows sort this out?
pmurias nine: why do we need that NQP_LIB env var? 09:41
AlexDaniel timotimo: any thoughts on the current appveyor failure? There's probably not much we can do about it, but still.
pmurias nine: why can't we just pass --libpath? 09:42
nine 20:03 < nine> Won't work as command line processing happens after we already load some modules
pmurias: ^^^
pmurias command line processing for moarvm too or just for rakudo? 09:45
pmurias tries to get rid of the NQP_LIB variable and see what happens 09:46
Geth rakudo/nom: a331c804a9 | pmurias++ | tools/build/Makefile-Moar.in
Stop using NQP_LIB while building on the moarvm
 09:49
nine Btw. noone seems to have tried building the JVM backend on Windows in ages. Because that's where I have the NQP_LIB=blib trick from
pmurias the JVM backends seems to be loosing attention :/ 09:50
nine Sooooo....why the hell didn't this work when I tried it?! 09:51
AlexDaniel at least it builds on linux, yesterday it didn't
stmuk I don't think rakudo has built on windows for 10 days at least according to appveyor 09:55
Skarsnik releasable6, status
stmuk ci.appveyor.com/project/moritz/rak...d/1.0.3851 <=- seems last working run
releasable6 Skarsnik, Next release is just a few moments away. No blockers. 208 out of 215 commits logged
Skarsnik, Details: gist.github.com/542ea26201c2729524...1db226e249
stmuk I'm going to try building rakudo/nqp-lib-windows in virtualbox with strawberry perl/mingw 10:01
Geth rakudo/nom: 1eeb943417 | (Stefan Seifert)++ | 2 files
Replace remaining usage of NQP_LIB by --libdir
 10:02
nine stmuk: no longer necessary :)
pmurias++ # actually fixing the darn thing
stmuk ah cool 10:03
AlexDaniel but it's still broken and that's ok? 10:06
stmuk ci.appveyor.com/project/moritz/rak...ecl5nkqhr8
that still failures with the original (days old) problem
AlexDaniel if I get it right, the problem is in MoarVM, and it's unlikely we are going to have another moar release now 10:09
lizmat why? I don't see 2017.08 Moar advertised yet 10:10
AlexDaniel well, there's at least this: irclog.perlgeek.de/moarvm/2017-08-19#i_15043625 10:11
timotimo lizmat: there's a release tarball and a tag in the github 10:12
lizmat ah, perhaps a point release is in order then ?
AlexDaniel timotimo: hey. Any thoughts on the current moar failure on windows? 10:13
stmuk src\jit\emit_x64.dasc:1829 10:14
src\jit\emit_x64.dasc:1829: error: bad operand mode in `lea i?,x?':
I can reproduce 10:15
timotimo looks like jnthn committed a little bit of wrong assembly for the cas ops
AlexDaniel is it just a semicolon missing? 10:16
nah 10:17
stmuk is there a compile time option to disable the jit? 10:20
timotimo yes
i know what's wrong 10:21
|.if WIN32; 10:22
| mov qword [rsp+0x20], TMP6;
|.else;
| mov ARG5, TMP6;
|.endif
needs something like this
ARG5 is only A Thing on posix
timotimo fixes 10:23
how do i get appveyor to try my branch? 10:25
oh, i have my own moarvm appveyor set up
ci.appveyor.com/project/timo/moarv...k7tmpddkhc 10:27
whoops, it doesn't even compile on linux any more
AlexDaniel timotimo: btw, why no appveyor on the main repo?
timotimo jnthn would have to do it 10:28
would be neat if you could give him a little step-by-step to get it right
i think my setup got a bit messed up
stmuk src\jit\emit_x64.dasc:1829: error: bad label definition: 10:31
|.if WIN32:
: or ; ? 10:32
nine ; or nothing 10:33
timotimo yeah 10:35
the lea line isn't correct yet
ok, lea can only go into registers 10:36
AlexDaniel .at 2017-09-15 Check AppVeyor build status, stupid. 10:42
yoleaux AlexDaniel: Sorry, that command (.at) crashed.
AlexDaniel .at 2017-09-15T15:00 Check AppVeyor build status, stupid. 10:43
yoleaux AlexDaniel: Sorry, that command (.at) crashed.
AlexDaniel .on 2017-09-15T15:00 Check AppVeyor build status, stupid.
yoleaux AlexDaniel: Sorry, that command (.on) crashed.
timotimo what makes the crash in the last build go? :(
ci.appveyor.com/project/timo/moarv...eyw6c#L838
stmuk This is MoarVM version 2017.08-2-gbff5385 built with JIT support 10:47
works for me now
(on gcc anyway) 10:48
timotimo oh? does it also survive all tests on rakudo, i.e. including the ones that do cas?
stmuk I will investigate further
timotimo i clearly did something wrong 10:50
oh, huh, even the 32bit version crashes immediately 10:51
does someone know what the exit code means exactly? 10:54
stmuk I can't build nqp :/ maybe my fault 11:00
Skarsnik (stop breaking stuff!) 11:02
stmuk FWIW gist.github.com/stmuk/86ebb013ef0f...0a300d9cfb 11:03
Geth rakudo/nom: 10df9a95b3 | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Tweaks for the release guide

Mention Windows, AppVeyor and JVM.		 11:04
AlexDaniel ? that's all I can do to cover my mistake
lizmat so, if I understand the situation correctly, if we use the current MoarVM tarball, we would lose WIndows for Rakudo Perl 6 2017.08 ? 11:05
AlexDaniel lizmat: correct 11:06
lizmat Hmm... I'm quite sure jnthn would also find that not quite acceptable
stmuk looks like timotimo++ has fixed moar in his branch but there are further problems
AlexDaniel lizmat: there's no rush 11:07
and we have some (slow) progress :) 11:08
Skarsnik can't you do a 2017.08.2 release for moar? 11:11
AlexDaniel I hope 2017.08.1 will be enough :) 11:14
Skarsnik ho x.1 is after x ? 11:18
AlexDaniel I don't think we had a point release of moar yet, but that's how it is done with rakudo, yes. 11:20
I guess it starts from 0 which you can omit :)
dogbert17 ZOFFLOP: t/spec/S17-lowlevel/atomic-ops.t 11:42
ok 26 - Atomic add of lexical works (2) 11:44
A IntLexRef container does not know how to do an atomic load
in block <unit> at t/spec/S17-lowlevel/atomic-ops.t line 88
AlexDaniel is actually seeing some fails on errata stresstest 11:46
AlexDaniel looks
lizmat hmmm... I get the impression we're missing some texas counterparts to some of the atomic ops ? 11:56
specifically prefix ++? and prefix --? ? 11:57
timotimo stmuk: can you bisect the additional problem? maybe it starts before the atomic ops branches were merged to all our three projects? 12:03
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/92...c583d42657 12:05
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2017....8-gb084530
AlexDaniel ehhhh
lizmat timotimo: do you have any idea why there are no texas equivalents to prefix ++? and prefix --? ?
AlexDaniel c: 2017.07,HEAD gist.githubusercontent.com/AlexDan...6065/foo.t 12:06
committable6 AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, gist.github.com/07f20d12106814b88c...5bad7d61e6
AlexDaniel ? this is one of the errata tests 12:07
bisectable gives this (not super helpful for me): gist.github.com/567e7a840110c1002d...c67eadaa2e 12:08
timotimo lizmat: no, i don't
Skarsnik was it something "there is a chance these operator will be used by 0.0001% of user, so no need for texas"? 12:09
lizmat no, I think it's an oversight, actually best fixed before release :-( 12:10
with a rename of atomic-int to atomic-post-inc
nother weird thing: I can't find a proto for cas() in the setting, but it happily compiles anyway ? 12:11
AlexDaniel Any ideas on RT #131934 ? 12:13
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131934
Zoffix AlexDaniel: git checkout 6.c-errata; git cherry-pick 456b87ddbb1f606140999b5e219e5ca5ce119c6f 12:15
AlexDaniel: github.com/perl6/roast/commit/456b...a5ce119c6f
timotimo i do believe you use atomic increment and decrement mostly in one of the two
but we got a prefix and postfix just because that's so natural?
Zoffix lizmat: one more thing I spot: we have ?+= but not ?-= 12:16
(nor ??= )
lizmat what the diff between ?-= and ??= ? 12:17
ah, the longer hyphen/minus ?
Zoffix Yeah, the infamous U+2212 minus 12:18
lizmat AlexDaniel: looks to me like we're going to need a point release of MoarVM before we can release Rakudo 2017.08 12:19
and it looks like we won't get one until tomorrow
so if it's all ok to you and timotimo and Zoffix, I will fix the current inconsistencies / omissions in atomicops / roast now 12:20
so we can include that in the release tomorrow
is that a plan?
Zoffix has no objections 12:21
Zoffix &
AlexDaniel lizmat: I don't see any other possibility
lizmat ok, I'll try to make it a single, easily revertable commit 12:22
lizmat has pinged jnthn and he replies: "Darn, will be a point release then. May get to it this evening; failing that tomorrow" 12:23
Geth roast/6.c-errata: 66792f989d | (Jonathan Worthington)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | S17-promise/allof.t
Correct test that tried to mis-use CAS.

The cheating one didn't have to care for how the world actually works.
  :-)		 12:27
AlexDaniel Zoffix: I see. Thanks 12:28
stmuk timotimo: I suspect the moar.exe is at fault since I can't use it to build nqp 2017.07 either 12:31
that should work shouldn't it newer moar than nqp?
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/f5...6e3529060e 12:32
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2017....2-gd40d6dc
timotimo hm, yeah, probably 12:38
AlexDaniel does anybody know something about this? 12:45
c: HEAD raw.githubusercontent.com/perl6/ro.../complex.t
committable6 AlexDaniel, Successfully fetched the code from the provided URL.
AlexDaniel, gist.github.com/06146dc6b8872b41a0...baaf6ecf5b
lizmat AlexDaniel: doesn't fail for me on MacOS 12:46
AlexDaniel bisectable points at github.com/rakudo/rakudo/commit/f5...6e3529060e 12:49
brrt blame! 12:53
what platform does it break on
AlexDaniel x86_64 GNU/Linux 12:54
complex.t, unpolar.t, rat.t fail for this reason 12:55
timotimo .( unpopular ) 12:57
stmuk: i might have just fixed moar completely 12:59
AlexDaniel oh, and fatrat.t also 13:00
I can create a ticket if somebody needs it 13:02
stmuk timotimo: same result I'm afraid 13:34
timotimo i see it too :( 13:35
can you try with jit disabled?
AlexDaniel oh, fwiw, no issue with complex.t, unpolar.t, rat.t, fatrat.t when MVM_SPESH_DISABLE=1 13:39
stmuk timotimo: yes that works and nqp tests (mostly) pass 13:45
019-file-ops.t has Failed to symlink file: operation not permitted 13:46
at t\nqp/019-file-ops.t:301
111 seems to have hung
timotimo oh, can symlinks work on windows?
stmuk no :)
I assume that's the problem
timotimo why is that test even running on windows
Zoffix Symlinks do work on windows, but they're hardlines and need admin privs 14:05
*hardlinks
hence the "operation not permitted"
oh wait, hardlinks work without extra perms, but for symlink you need admin 14:07
brrt AlexDaniel, can you check on the branch fix_new_jit_ops_win32 14:09
on MoarVM
AlexDaniel brrt: sure 14:10
brrt okay, thanks :-) 14:11
stmuk ok exercise & fresh air 14:21
AlexDaniel stmuk: I need that too :) 14:23
lucasb my OCD was triggered by a single whitespace 14:29
github.com/rakudo/rakudo/blob/nom/...n.pm#L2384
the only occurrence of "can not". all other places is written as cannot :) 14:30
lizmat PR's welcome :-) 14:31
AlexDaniel .tell brrt I see no change 14:34
yoleaux AlexDaniel: I'll pass your message to brrt.
AlexDaniel “on MoarVM version 2017.08-2-g882ed0bc”
that's if it was supposed to affect RT #131935 14:35
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131935
Geth rakudo: lucasbuchala++ created pull request #1135:
Can not -> Cannot		 14:37
rakudo/nom: cff51ea1af | (Lucas Buchala)++ (committed using GitHub Web editor) | src/core/Exception.pm
Can not -> Cannot
 14:38
rakudo/nom: bef974e34d | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Exception.pm
Merge pull request #1135 from lucasbuchala/patch-1

Can not -> Cannot
lizmat
.oO( I can not believe how many electrons were used to remove a single space :-)
 14:39
lucasb++
lucasb this has to be my most useful contribution in open source :)
AlexDaniel lucasb: here's mine: github.com/rakudo/rakudo/pull/1130...aafa6314fb 14:40
timotimo AlexDaniel: did you do anything besides "SPESH_DISABLE"? i.e. inline or osr? 14:42
AlexDaniel timotimo: still happens with osr_disable=1, but does not happen with inline_disable=1 14:43
Geth roast/6.c-errata: 3bad2183ff | (Aleks-Daniel Jakimenko-Aleksejev)++ | 2 files
Revert "fix tests that depend on failed parse --> Nil"

This reverts commit b0044b0751fc13f97abca1ac4f76ccc5bb109112.
Grammar.parse change was moved to v6.d.PREVIEW, there is no more need to change v6.c tests.		 14:56
rakudo/nom: ca8aafc173 | (Elizabeth Mattijsen)++ | 2 files
Restructure naming of atomic ops

While writing the Perl 6 Weekly, it became clear to me that there is no simple Unicode -> Texas mapping for many of the new atomic ops. Since the release is delayed, I took the liberty to make the naming more consistent:
... (17 more lines)		 15:03
lizmat AlexDaniel: ^^^ 15:04
Geth roast: 8a43e999a5 | (Elizabeth Mattijsen)++ | S17-lowlevel/atomic.t
Follow naming changes of atomic ops

As done in github.com/rakudo/rakudo/commit/ca8aafc173
AlexDaniel lizmat: anything special about it? 15:05
lizmat I tried to describe it in the commit message :-)
github.com/rakudo/rakudo/commit/ca8aafc173
pmurias github.com/perl6/roast/blob/master...ure.t#L181 - is the exact order of the stuff returned by antipairs something we can depend on? 15:12
AlexDaniel lizmat: Well, as I see it, it simply makes the naming more consistent, I don't see how it could affect the release process. cas proto change is interesting though…
pmurias github.com/perl6/roast/blob/master...ure.t#L181 - is the exact order of the stuff returned by antipairs something we can depend on?
sorry for pasting twice :/ 15:13
not sure if it's something that I need to fix in rakudo.js or a overzealous test 15:15
AlexDaniel this depends on whether the capture itself stores named arguments in an ordered way 15:18
as a user I'd expect the result to be no different from .pairs».antipair I think 15:19
lizmat ok, atomic ops doc should now be in line with HEAD and roast 15:22
pmurias: no, don't think so 15:23
but testing it with is-deeply, doesn't the order matter anyway ? 15:24
*not* matter anyway ?
lizmat steps away from the keyboard for a few hours 15:27
Zoffix pmurias: yeah, I'd say that's a bogus test 15:32
And testing with is-deeply: order matters here because it's testing a .Seq 15:34
Zoffix would just pop a .sort on both $expected and $got 15:35
ugexe nine: because the people that want it to work on windows aren't usually the ones who broke it - you cant expect windows people to vet every commit, especially when most commits are done directly and not PR 15:41
the real problem here was we keep breaking it casually, which breaks the appveyor build, which is then ignored until days/weeks later 15:42
timotimo what message was that in response to? 15:43
ugexe "Here's a crazy idea: why not let people who are actually interested in using Windows sort this out?"
timotimo oh 15:45
yeah, no, that's not going to fly
AlexDaniel it was largerly my mistake, so I attempted to fix it with this: github.com/rakudo/rakudo/commit/10...fed0aea2f5 15:46
I could've started pinging people about the windows build 10 days before the release and I didn't, so… 15:47
ugexe sure, but it could be argued that maybe we are at the point where we should only be pushing green builds to nom
AlexDaniel I don't think we have to be so strict 15:50
we had a failing build for 10 days and nobody cared, that's the problem. Not even a ticket 15:51
ugexe it was mentioned in irc
and not just by the appveyor bot
what we need is a travisci/appveyor setup that *only* tests blead so that its not slowed down by the other bajillion builds that have to happen for each commit 15:53
japhb It's too bad we don't have a really reliable/performant CI tester ... we could do everything on branches, and have the CI auto-approve merges if all platforms approve. Sortof like Debian's method for moving packages unstable --> testing. 15:55
AlexDaniel no matter how much I'd love to see a technology solution for this, I don't see how stuff mentioned above can help. It shows red status faster? This won't make us care about it. Everything is on branches? OK maybe, but is it worth all of the merge conflicts we'd get because of that? 16:00
stmuk I was amazed by how many complaints I got when there was no R* MSI 16:01
AlexDaniel stmuk: noted.
ugexe you can push your PR and wait the 30 minutes to go green and merge it yourself. no need to make this out to be a huge ordeal
Zoffix 30 minutes is a lot of time. 16:03
Also: you still have a problem that you can't just branch MoarVM/nqp bumps and roast 16:04
Or rather, to do it properly, you have to set up your own MoarVM/NQP/Roast branches just for a single thing
ugexe a long time for what? I dont think 30 minutes is a long time to wait until merging something. The CI tests arent supposed to be instant unit test feedback mechanism 16:05
Zoffix "failing build for 10 days and nobody cared" That's not true. I mentioned I couldn't build last week. Also even if no one bothered enough to complain about it, how many wanted to try out Rakudo, got a failed build and just moved on? 16:06
AlexDaniel “<[Coke]> AlexDaniel: at some point, we probably want to switch to a develop/master branching strat, where develop is auto-promoted to master once sufficient testing occurs.” 16:08
? this sounds like a better idea. Less intrusive into the workflow at least
Zoffix ugexe: a long time for development, if you proxy everything through PRs, not only do I have to suffer the 1.5m build (often several times) and 4-minute spectest, I now have to also wait for a 30-minute greenlight before I can consider thing finished and move on. Also: often you develop several things in sequence where one relies on the other. Also: it's not unusual for Travis to be a day behind and that's 16:09
japhb wonders if version bumps can be handled automatically, by being able to mark a commit with "NEEDS: nqp feedbeef" and have the merge controller do the bumps as appropriate to the things merged so far.
Zoffix without this system in place.
AlexDaniel: it's completely unworkable with the current system
Version bumps + roast
japhb Which is why I was saying, none of this is workable unless we have a highly available and highly performant CI toolset and merge manager 16:10
Zoffix If I fix a bug and add roast tests, your development branch is now failing because of the new test.
japhb Zoffix: perhaps we can mark roast test commits with the minimum rakudo commit needed to support them? 16:11
So the merge manager doesn't merge the roast test until it merges that rakudo commit?
Zoffix That could work.
moritz the other thing we could do is revert breaking changes more quickly
Zoffix Yeah. 16:12
In fact: revert right away and then think how to fix it in a branch. This cuts down on all the time spent trying to chase down the author of the breakage.
moritz +1 16:13
japhb Let me see if I understand: Do you (moritz and Zoffix) mean to commit to head, and have something that checks CI and automatically reverts from head and moves it to a branch if the CI fails?
moritz japhb: no, I thought of a more manual/cultural thing 16:14
japhb OIC
moritz japhb: if I break the build (or spectests or whatever), and Zoffix comes along and notices, Zoffix reverts my commit 16:15
japhb Though a tool/bot to say "Revert last, move to branch, send a message to author" might help that
AlexDaniel it can be a bot that keeps whining on this channel if something is clearly not right
Zoffix For the revert thing: I meant if we find out there's a problem on HEAD, we revert right away and then figure out how to fix it. For example, the recent Grammar.parse issue. It took a couple of days to confer with the author of the commit before we did anything. In the new system: we'd revert right away and then discuss how to best handle it.
moritz and shoots me a quick message about why,
japhb So that anyone on channel can do that easily
Zoffix Probably a good idea to see how Rust folks do it. I've seen an article about them testing on a ton of system and also on GitHub they have an assisting bot 16:16
moritz japhb: I'd say we experiment first with doing it manually
japhb: and if it works out well culturally, we can still do some automation around it
japhb moritz: I'm certainly fine with that, I just note that step 2 is often lost ("Author can just pull it from history!") which doesn't give them an affordance to do their fix attempts on a branch. 16:17
japhb is in the "affordances matter more than one might expect" camp
moritz japhb: at $work, it seems to work fine
ugexe moritz: one problem this time was that the PR that would be reverted was marked as SECURITY, e.g. it disclosed a vulnerability in the PR only
AlexDaniel that too, yes 16:18
if it was disclosed privately, who'd be testing if it works on windows?
ugexe well, in the commit (there was no PR) 16:19
someone on windows?
not only that, it broke the build system for ALL OS 16:20
moritz AlexDaniel: if I had been in that situation, I'd ask around in here if anybody was available for testing stuff on windows, and I'd share that patch by email or private gist or so
ugexe nine fixed it for Linux shortly after
AlexDaniel c: 2017.07 say "a".match(/a/).made.^name 16:22
committable6 AlexDaniel, ¦2017.07: «NQPMu»
AlexDaniel c: HEAD say "a".match(/a/).made.^name
committable6 AlexDaniel, ¦HEAD(ca8aafc): «NQPMu»
AlexDaniel commit: 2017.07 say "a".match(/a/).made 16:23
committable6 AlexDaniel, ¦2017.07: «No such method 'gist' for invocant of type 'NQPMu'. Did you mean 'isa'?? in block <unit> at /tmp/7cVUy2jUAP line 1? «exit code = 1»»
AlexDaniel ah, that's an old thing 16:24
Geth rakudo/nom: 7a22d6cff3 | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/ChangeLog
Log remaining changes

Deliberately not logged: 26287a19 1ee8e9f3 7f0acb60 2545e6d6 10df9a95 bef974e3		 16:35
AlexDaniel off for a walk 16:48
Skarsnik Good luck with the release, time for bed :) 19:37
pmurias having an automatic build bot report on channel that a commit is broken on windows would be a good start 19:44
gfldex $*INITTIME seams not to be specced. Is that intentional? 19:55
moritz curious, it's been mentioned in #perl6 as early as 2010 19:59
and in S28 since 2009 20:00
... and it looks like I was the one who implemented it initially: github.com/rakudo/rakudo/commit/45bb17e864 20:01
I totally forgot.
so, seems like it's a desired feature
lizmat ok, so it *does* seem to be specced, but there are no tests for it
AlexDaniel: I have a patch for say "a".match(/a/).made, but will keep that until after the release 20:02
I'm using nqp::isconcrete to test for NQPMu in HLL Perl 6 20:03
jnthn timotimo moritz is there a better way? NQPMu doesn't live in HLL land, nor do I think we want to expose it 20:04
fwiw, nqp::ifnull doesn't work
moritz because it's not null :-)
could you do a type-check against Mu? 20:05
and if it comes out False, return Mu instead?
nqp::istype(thething, Mu)
jnthn lizmat: Where are you getting it from? 20:07
isconcrete will reliably work on it though
lizmat m: say "a".match(/a/).made # jnthn
camelia No such method 'gist' for invocant of type 'NQPMu'. Did you mean 'isa'?? in block <unit> at <tmp> line 1??
jnthn o.O 20:08
moritz maybe it should be initialized with Mu in Perl 6 match objects 20:09
like in method !MATCH
lizmat: something like perlpunks.de/paste/show/5999ece5.6918.326 20:11
lizmat moritz: but that would slow down all Match object creation, no ? 20:19
moritz: my idea was more about adding: method made() { nqp::if(nqp::isconcrete($!made),$!made,Nil) } 20:20
which would only slow down whenever one actually calls .made
moritz lizmat: ok, good point 20:54
lizmat .ask jnthn I'm confused about 61e1f4d5f5a4c03cd7bbfd , it looks to me reverting to an older situation, basically making the atposNd_i ops useless ? 21:08
yoleaux lizmat: I'll pass your message to jnthn.
Zoffix goes to bed 21:44
timotimo gnite Zoffix 21:51
lizmat: we'd have to put 3x3 new multidimref-like ops into moar to get the atposNd optimization back 21:53
Geth rakudo/nom: 1aee9aa573 | (Elizabeth Mattijsen)++ | src/core/atomicops.pm
Rename Texas atomic ops as per jnthn's suggestion

  irclog.perlgeek.de/moarvm/2017-08-20#i_15047166		 21:55
roast: 795045049b | (Elizabeth Mattijsen)++ | S17-lowlevel/atomic.t
Follow renaming of Texas atomic ops

As per github.com/rakudo/rakudo/commit/1aee9aa573		 21:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!