| 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 |