Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2017-08-20

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:05 AlexDani` joined #perl6-dev
01:09 BenGoldberg joined #perl6-dev
01:10 Zoffix .
01:18 [Coke]
01:18 [Coke] Zoffix: close on fixing the (*&#$ docs cronjob.
01:19 [Coke] 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:20 [Coke] (crap. still failing.)
01:23 [Coke] aha, maybe?
01:24 Zoffix "aha"? What?
01:24 Zoffix m: 0 ^^ -> {say 2}
01:24 camelia rakudo-moar 2545e6: ( no output )
01:25 [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: https://github.com/rakudo/rakudo/blob/2545e6d65/src/core/Bool.pm#L113
01:25 [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
01:26 [Coke] 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: https://github.com/rakudo/rakudo/blob/2545e6d65/src/core/Bool.pm#L134-L145
01:26 [Coke] once that runs, will do a cron based build.
01:27 Zoffix m: &infix:<^^>(1, -> {say 2; False})
01:27 camelia rakudo-moar 2545e6: OUTPUT: «2?»
01:27 Zoffix ahh
01:28 Zoffix so what's the idea behind &infix processing Callables, but the grammar one not?
01:30 [Coke] (it is highlighting things now, so that's win-ish)
01:34 Zoffix Filed the inconsistency as https://rt.perl.org/Ticket/Display.html?id=131932
01:34 Zoffix [Coke]: just be sure to write down all your steps so that we can painlessly get docs up to speed after next system upgrade.
01:44 Zoffix buggable: uptime
01:50 buggable joined #perl6-dev
01:50 Zoffix buggable: eco Ddt
01:50 buggable Zoffix, Ddt 'Distribution Development Tool similar to mi6': https://github.com/kalkin/Ddt 1 other matching results: https://modules.perl6.org/s/Ddt
01:50 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: https://github.com/perl6/ecosystem/blob/master/META.list#L759-L760
01:50 Zoffix I've no idea why people do this and tempted to prune that stuff.
01:50 Zoffix (there are more instances of that)
01:52 ilbot3 joined #perl6-dev
01:52 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
02:17 [Coke] ok. I think docs are now building correctly via cron.
02:17 [Coke] added some pitiful notes to the host admin docs in github.
02:18 Zoffix \o/ [Coke]++
02:34 geekosaur joined #perl6-dev
04:05 samcv no other unicode related stuff has come up since yesterday hopefully?
04:05 samcv checking in as i've been offline most of today
06:23 geekosaur joined #perl6-dev
06:56 ggoebel joined #perl6-dev
08:37 dogbert17 joined #perl6-dev
08:39 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: https://gist.github.com/niner/b71ecb3b0a02a0212e4b8109ad66ef16
08:39 nine I just can't test it as I don't have Windows anywhere.
09:05 AlexDani` .
09:05 yoleaux 08:35Z <nine> AlexDani`: The fix for the Windows build could look like this: https://gist.github.com/niner/b71ecb3b0a02a0212e4b8109ad66ef16
09:05 AlexDaniel .
09:05 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
09:06 AlexDaniel new day, new release quests! Good morning everybody
09:10 AlexDaniel nine: awesome, thanks
09:10 AlexDaniel except that… I don't have windows
09:10 AlexDaniel ugexe: any chance you can test this patch? ?
09:14 nine ugexe is probably asleep for a couple more hours...
09:16 AlexDaniel then we need another hero :)
09:17 AlexDaniel ooor…
09:18 AlexDaniel or we just push the fix and see what happens on AppVeyor
09:23 Geth ¦ rakudo/nqp-lib-windows: 484d2403f0 | (Stefan Seifert)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | 3 files
09:23 Geth ¦ rakudo/nqp-lib-windows: Fix windows build
09:23 Geth ¦ rakudo/nqp-lib-windows: review: https://github.com/rakudo/rakudo/commit/484d2403f0
09:25 stmuk AlexDaniel++
09:25 AlexDaniel hm, it's not going to test it by default on some branch?
09:25 AlexDaniel so I'll have to submit a PR with it
09:26 pmurias joined #perl6-dev
09:26 Geth ¦ rakudo: AlexDaniel++ created pull request #1134: Fix windows build
09:26 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/1134
09:32 * AlexDaniel squints
09:32 AlexDaniel that's a different issue, isn't it?
09:35 nine It couldn't even build moar
09:37 lizmat .
09:38 AlexDaniel https://irclog.perlgeek.de/perl6-dev/2017-08-18#i_15039567
09:38 nine Here's a crazy idea: why not let people who are actually interested in using Windows sort this out?
09:41 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.
09:42 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
09:42 nine pmurias: ^^^
09:45 pmurias command line processing for moarvm too or just for rakudo?
09:46 * pmurias tries to get rid of the NQP_LIB variable and see what happens
09:49 Geth ¦ rakudo/nom: a331c804a9 | pmurias++ | tools/build/Makefile-Moar.in
09:49 Geth ¦ rakudo/nom: Stop using NQP_LIB while building on the moarvm
09:49 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a331c804a9
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
09:50 pmurias the JVM backends seems to be loosing attention :/
09:51 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
09:54 Skarsnik joined #perl6-dev
09:55 stmuk I don't think rakudo has built on windows for 10 days at least according to appveyor
09:55 Skarsnik releasable6, status
09:55 stmuk https://ci.appveyor.com/project/moritz/rakudo/build/1.0.3851 <=- seems last working run
09:55 releasable6 Skarsnik, Next release is just a few moments away. No blockers. 208 out of 215 commits logged
09:55 releasable6 Skarsnik, Details: https://gist.github.com/542ea26201c2729524f5321db226e249
10:01 stmuk I'm going to try building rakudo/nqp-lib-windows in virtualbox with strawberry perl/mingw
10:02 Geth ¦ rakudo/nom: 1eeb943417 | (Stefan Seifert)++ | 2 files
10:02 Geth ¦ rakudo/nom: Replace remaining usage of NQP_LIB by --libdir
10:02 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1eeb943417
10:02 nine stmuk: no longer necessary :)
10:02 nine pmurias++ # actually fixing the darn thing
10:03 stmuk ah cool
10:06 AlexDaniel but it's still broken and that's ok?
10:06 stmuk https://ci.appveyor.com/project/moritz/rakudo/branch/nom/job/h1b47pecl5nkqhr8
10:06 stmuk that still failures with the original (days old) problem
10:09 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:10 lizmat why?  I don't see 2017.08 Moar advertised yet
10:11 AlexDaniel well, there's at least this: https://irclog.perlgeek.de/moarvm/2017-08-19#i_15043625
10:12 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 ?
10:13 AlexDaniel timotimo: hey. Any thoughts on the current moar failure on windows?
10:14 stmuk src\jit\emit_x64.dasc:1829
10:14 stmuk src\jit\emit_x64.dasc:1829: error: bad operand mode in `lea i?,x?':
10:15 stmuk I can reproduce
10:15 timotimo looks like jnthn committed a little bit of wrong assembly for the cas ops
10:16 AlexDaniel is it just a semicolon missing?
10:17 AlexDaniel nah
10:20 stmuk is there a compile time option to disable the jit?
10:20 timotimo yes
10:21 timotimo i know what's wrong
10:22 timotimo |.if WIN32;
10:22 timotimo | mov qword [rsp+0x20], TMP6;
10:22 timotimo |.else;
10:22 timotimo | mov ARG5, TMP6;
10:22 timotimo |.endif
10:22 timotimo needs something like this
10:22 timotimo ARG5 is only A Thing on posix
10:23 * timotimo fixes
10:25 timotimo how do i get appveyor to try my branch?
10:25 timotimo oh, i have my own moarvm appveyor set up
10:27 timotimo https://ci.appveyor.com/project/timo/moarvm/build/job/skr7g2k7tmpddkhc
10:27 timotimo whoops, it doesn't even compile on linux any more
10:27 AlexDaniel timotimo: btw, why no appveyor on the main repo?
10:28 timotimo jnthn would have to do it
10:28 timotimo would be neat if you could give him a little step-by-step to get it right
10:28 timotimo i think my setup got a bit messed up
10:31 stmuk src\jit\emit_x64.dasc:1829: error: bad label definition:
10:31 stmuk |.if WIN32:
10:32 stmuk : or ; ?
10:33 nine ; or nothing
10:35 timotimo yeah
10:35 timotimo the lea line isn't correct yet
10:36 timotimo ok, lea can only go into registers
10:42 AlexDaniel .at 2017-09-15 Check AppVeyor build status, stupid.
10:42 yoleaux AlexDaniel: Sorry, that command (.at) crashed.
10:43 AlexDaniel .at 2017-09-15T15:00 Check AppVeyor build status, stupid.
10:43 yoleaux AlexDaniel: Sorry, that command (.at) crashed.
10:43 AlexDaniel .on 2017-09-15T15:00 Check AppVeyor build status, stupid.
10:43 yoleaux AlexDaniel: Sorry, that command (.on) crashed.
10:43 timotimo what makes the crash in the last build go? :(
10:43 timotimo https://ci.appveyor.com/project/timo/moarvm/build/1.0.23/job/her8whebu5ceyw6c#L838
10:47 stmuk This is MoarVM version 2017.08-2-gbff5385 built with JIT support
10:47 stmuk works for me now
10:48 stmuk (on gcc anyway)
10:48 timotimo oh? does it also survive all tests on rakudo, i.e. including the ones that do cas?
10:48 stmuk I will investigate further
10:50 timotimo i clearly did something wrong
10:51 timotimo oh, huh, even the 32bit version crashes immediately
10:54 timotimo does someone know what the exit code means exactly?
11:00 stmuk I can't build nqp :/ maybe my fault
11:02 Skarsnik (stop breaking stuff!)
11:03 stmuk FWIW https://gist.github.com/stmuk/86ebb013ef0f424c5c2d690a300d9cfb
11:04 Geth ¦ rakudo/nom: 10df9a95b3 | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
11:04 Geth ¦ rakudo/nom: Tweaks for the release guide
11:04 Geth ¦ rakudo/nom:
11:04 Geth ¦ rakudo/nom: Mention Windows, AppVeyor and JVM.
11:04 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/10df9a95b3
11:04 AlexDaniel ? that's all I can do to cover my mistake
11:05 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:06 AlexDaniel lizmat: correct
11:06 lizmat Hmm... I'm quite sure jnthn would also find that not quite acceptable
11:06 stmuk looks like timotimo++ has fixed moar in his branch but there are further problems
11:07 AlexDaniel lizmat: there's no rush
11:08 AlexDaniel and we have some (slow) progress :)
11:11 Skarsnik can't you do a 2017.08.2 release for moar?
11:14 AlexDaniel I hope 2017.08.1 will be enough :)
11:18 Skarsnik ho x.1 is after x ?
11:20 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 AlexDaniel I guess it starts from 0 which you can omit :)
11:24 dogbert17 joined #perl6-dev
11:42 dogbert17 ZOFFLOP: t/spec/S17-lowlevel/atomic-ops.t
11:44 dogbert17 ok 26 - Atomic add of lexical works (2)
11:44 dogbert17 A IntLexRef container does not know how to do an atomic load
11:44 dogbert17 in block <unit> at t/spec/S17-lowlevel/atomic-ops.t line 88
11:46 * AlexDaniel is actually seeing some fails on errata stresstest
11:46 * AlexDaniel looks
11:56 lizmat hmmm... I get the impression we're missing some texas counterparts to some of the atomic ops ?
11:57 lizmat specifically prefix ++? and prefix --? ?
12:03 timotimo stmuk: can you bisect the additional problem? maybe it starts before the atomic ops branches were merged to all our three projects?
12:05 AlexDaniel Geth: ver https://github.com/rakudo/rakudo/commit/92707fac6c8fe9d3a2f6fe9fc8eb99c583d42657
12:05 Geth AlexDaniel, version bump brought in these changes: https://github.com/perl6/nqp/compare/2017.07-44-g152094b76...2017.07-48-gb084530
12:05 AlexDaniel ehhhh
12:05 lizmat timotimo: do you have any idea why there are no texas equivalents to prefix ++? and prefix --? ?
12:06 AlexDaniel c: 2017.07,HEAD https://gist.githubusercontent.com/AlexDaniel/594af0670276d850a1ed0cdfad18df08/raw/4dc95cb613b9ab8415130f2e2c15f039a9b16065/foo.t
12:06 committable6 AlexDaniel, Successfully fetched the code from the provided URL.
12:06 committable6 AlexDaniel, https://gist.github.com/07f20d12106814b88c54905bad7d61e6
12:07 AlexDaniel ? this is one of the errata tests
12:08 AlexDaniel bisectable gives this (not super helpful for me): https://gist.github.com/567e7a840110c1002d53c0c67eadaa2e
12:08 timotimo lizmat: no, i don't
12:09 Skarsnik was it something "there is a chance these operator will be used by 0.0001% of user, so no need for texas"?
12:10 lizmat no, I think it's an oversight, actually best fixed before release  :-(
12:10 lizmat with a rename of atomic-int to atomic-post-inc
12:11 lizmat nother weird thing: I can't find a proto for cas() in the setting, but it happily compiles anyway ?
12:13 AlexDaniel Any ideas on RT #131934 ?
12:13 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=131934
12:15 Zoffix AlexDaniel: git checkout 6.c-errata; git cherry-pick 456b87ddbb1f606140999b5e219e5ca5ce119c6f
12:15 Zoffix AlexDaniel: https://github.com/perl6/roast/commit/456b87ddbb1f606140999b5e219e5ca5ce119c6f
12:15 timotimo i do believe you use atomic increment and decrement mostly in one of the two
12:15 timotimo but we got a prefix and postfix just because that's so natural?
12:16 Zoffix lizmat: one more thing I spot: we have ?+= but not ?-=
12:16 Zoffix (nor ??= )
12:17 lizmat what the diff between ?-= and ??= ?
12:17 lizmat ah, the longer hyphen/minus ?
12:18 Zoffix Yeah, the infamous U+2212 minus
12:19 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 lizmat and it looks like we won't get one until tomorrow
12:20 lizmat 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 lizmat so we can include that in the release tomorrow
12:20 lizmat is that a plan?
12:21 * Zoffix has no objections
12:21 * Zoffix &
12:21 AlexDaniel lizmat: I don't see any other possibility
12:22 lizmat ok, I'll try to make it a single, easily revertable commit
12:23 * lizmat has pinged jnthn and he replies: "Darn, will be a point release then.  May get to it this evening; failing that tomorrow"
12:27 Geth ¦ roast/6.c-errata: 66792f989d | (Jonathan Worthington)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | S17-promise/allof.t
12:27 Geth ¦ roast/6.c-errata: Correct test that tried to mis-use CAS.
12:27 Geth ¦ roast/6.c-errata:
12:27 Geth ¦ roast/6.c-errata: The cheating one didn't have to care for how the world actually works.
12:27 Geth ¦ roast/6.c-errata: :-)
12:27 Geth ¦ roast/6.c-errata: review: https://github.com/perl6/roast/commit/66792f989d
12:28 AlexDaniel Zoffix: I see. Thanks
12:31 stmuk timotimo: I suspect the moar.exe is at fault since I can't use it to build nqp 2017.07 either
12:31 stmuk that should work shouldn't it newer moar than nqp?
12:32 AlexDaniel Geth: ver https://github.com/rakudo/rakudo/commit/f590863e1736c75207c9ce0335ea646e3529060e
12:32 Geth AlexDaniel, version bump brought in these changes: https://github.com/perl6/nqp/compare/2017.07-19-g82d06cc...2017.07-32-gd40d6dc
12:33 brrt joined #perl6-dev
12:38 timotimo hm, yeah, probably
12:45 AlexDaniel does anybody know something about this?
12:45 AlexDaniel c: HEAD https://raw.githubusercontent.com/perl6/roast/6.c-errata/S32-num/complex.t
12:45 committable6 AlexDaniel, Successfully fetched the code from the provided URL.
12:45 committable6 AlexDaniel, https://gist.github.com/06146dc6b8872b41a08ed5baaf6ecf5b
12:46 lizmat AlexDaniel: doesn't fail for me on MacOS
12:49 AlexDaniel bisectable points at https://github.com/rakudo/rakudo/commit/f590863e1736c75207c9ce0335ea646e3529060e
12:53 brrt blame!
12:53 brrt what platform does it break on
12:54 AlexDaniel x86_64 GNU/Linux
12:55 AlexDaniel complex.t, unpolar.t, rat.t fail for this reason
12:57 timotimo .( unpopular )
12:59 timotimo stmuk: i might have just fixed moar completely
13:00 AlexDaniel oh, and fatrat.t also
13:02 AlexDaniel I can create a ticket if somebody needs it
13:21 lucasb joined #perl6-dev
13:34 stmuk timotimo: same result I'm afraid
13:35 timotimo i see it too :(
13:35 timotimo can you try with jit disabled?
13:39 AlexDaniel oh, fwiw, no issue with complex.t, unpolar.t, rat.t, fatrat.t when MVM_SPESH_DISABLE=1
13:45 stmuk timotimo: yes that works and nqp tests (mostly) pass
13:46 stmuk 019-file-ops.t has Failed to symlink file: operation not permitted
13:46 stmuk at t\nqp/019-file-ops.t:301
13:46 stmuk 111 seems to have hung
13:46 timotimo oh, can symlinks work on windows?
13:46 stmuk no :)
13:46 stmuk I assume that's the problem
13:46 timotimo why is that test even running on windows
14:05 Zoffix Symlinks do work on windows, but they're hardlines and need admin privs
14:05 Zoffix *hardlinks
14:05 Zoffix hence the "operation not permitted"
14:07 Zoffix oh wait, hardlinks work without extra perms, but for symlink you need admin
14:09 brrt AlexDaniel, can you check on the branch fix_new_jit_ops_win32
14:09 brrt on MoarVM
14:10 AlexDaniel brrt: sure
14:11 brrt okay, thanks :-)
14:12 [TuxCM] joined #perl6-dev
14:21 stmuk ok exercise & fresh air
14:23 AlexDaniel stmuk: I need that too :)
14:26 lucasb joined #perl6-dev
14:27 releasable6 joined #perl6-dev
14:29 lucasb my OCD was triggered by a single whitespace
14:29 lucasb https://github.com/rakudo/rakudo/blob/nom/src/core/Exception.pm#L2384
14:30 lucasb the only occurrence of "can not". all other places is written as cannot :)
14:31 lizmat PR's welcome  :-)
14:34 AlexDaniel .tell brrt I see no change
14:34 yoleaux AlexDaniel: I'll pass your message to brrt.
14:34 AlexDaniel “on MoarVM version 2017.08-2-g882ed0bc”
14:35 AlexDaniel that's if it was supposed to affect RT #131935
14:35 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=131935
14:37 Geth ¦ rakudo: lucasbuchala++ created pull request #1135: Can not -> Cannot
14:37 Geth ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/1135
14:38 Geth ¦ rakudo/nom: cff51ea1af | (Lucas Buchala)++ (committed using GitHub Web editor) | src/core/Exception.pm
14:38 Geth ¦ rakudo/nom: Can not -> Cannot
14:38 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/cff51ea1af
14:38 Geth ¦ rakudo/nom: bef974e34d | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Exception.pm
14:38 Geth ¦ rakudo/nom: Merge pull request #1135 from lucasbuchala/patch-1
14:38 Geth ¦ rakudo/nom:
14:38 Geth ¦ rakudo/nom: Can not -> Cannot
14:38 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/bef974e34d
14:39 lizmat .oO( I can not believe how many electrons were used to remove a single space :-)
14:39 lizmat lucasb++
14:39 lucasb this has to be my most useful contribution in open source :)
14:40 AlexDaniel lucasb: here's mine: https://github.com/rakudo/rakudo/pull/1130/commits/bf7063d1ae8962d448ee6d273cff60aafa6314fb
14:42 timotimo AlexDaniel: did you do anything besides "SPESH_DISABLE"? i.e. inline or osr?
14:43 AlexDaniel timotimo: still happens with osr_disable=1, but does not happen with inline_disable=1
14:56 Geth ¦ roast/6.c-errata: 3bad2183ff | (Aleks-Daniel Jakimenko-Aleksejev)++ | 2 files
14:56 Geth ¦ roast/6.c-errata: Revert "fix tests that depend on failed parse --> Nil"
14:56 Geth ¦ roast/6.c-errata:
14:56 Geth ¦ roast/6.c-errata: This reverts commit b0044b0751fc13f97abca1ac4f76ccc5bb109112.
14:56 Geth ¦ roast/6.c-errata:
14:56 Geth ¦ roast/6.c-errata: Grammar.parse change was moved to v6.d.PREVIEW, there is no more need
14:56 Geth ¦ roast/6.c-errata: to change v6.c tests.
14:56 Geth ¦ roast/6.c-errata: review: https://github.com/perl6/roast/commit/3bad2183ff
15:03 Geth ¦ rakudo/nom: ca8aafc173 | (Elizabeth Mattijsen)++ | 2 files
15:03 Geth ¦ rakudo/nom: Restructure naming of atomic ops
15:03 Geth ¦ rakudo/nom:
15:03 Geth ¦ rakudo/nom: While writing the Perl 6 Weekly, it became clear to me that there is
15:03 Geth ¦ rakudo/nom: no simple Unicode -> Texas mapping for many of the new atomic ops.
15:03 Geth ¦ rakudo/nom: Since the release is delayed, I took the liberty to make the naming
15:03 Geth ¦ rakudo/nom: more consistent:
15:03 Geth ¦ rakudo/nom:
15:03 Geth ¦ rakudo/nom: <…commit message has 17 more lines…>
15:03 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ca8aafc173
15:04 lizmat AlexDaniel: ^^^
15:04 Geth ¦ roast: 8a43e999a5 | (Elizabeth Mattijsen)++ | S17-lowlevel/atomic.t
15:04 Geth ¦ roast: Follow naming changes of atomic ops
15:04 Geth ¦ roast:
15:04 Geth ¦ roast: As done in https://github.com/rakudo/rakudo/commit/ca8aafc173
15:04 Geth ¦ roast: review: https://github.com/perl6/roast/commit/8a43e999a5
15:05 AlexDaniel lizmat: anything special about it?
15:05 lizmat I tried to describe it in the commit message  :-)
15:05 lizmat https://github.com/rakudo/rakudo/commit/ca8aafc173
15:12 pmurias https://github.com/perl6/roast/blob/master/S02-types/capture.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…
15:12 pmurias https://github.com/perl6/roast/blob/master/S02-types/capture.t#L181 - is the exact order of the stuff returned by antipairs something we can depend on?
15:13 pmurias sorry for pasting twice :/
15:15 pmurias not sure if it's something that I need to fix in rakudo.js or a overzealous test
15:18 AlexDaniel this depends on whether the capture itself stores named arguments in an ordered way
15:19 AlexDaniel as a user I'd expect the result to be no different from .pairs».antipair I think
15:22 lizmat ok, atomic ops doc should now be in line with HEAD and roast
15:23 lizmat pmurias: no, don't think so
15:24 lizmat but testing it with is-deeply, doesn't the order matter anyway ?
15:24 lizmat *not* matter anyway ?
15:27 * lizmat steps away from the keyboard for a few hours
15:32 Zoffix pmurias: yeah, I'd say that's a bogus test
15:34 Zoffix And testing with is-deeply: order matters here because it's testing a .Seq
15:35 * Zoffix would just pop a .sort on both $expected and $got
15:41 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:42 ugexe the real problem here was we keep breaking it casually, which breaks the appveyor build, which is then ignored until days/weeks later
15:43 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?"
15:45 timotimo oh
15:45 timotimo yeah, no, that's not going to fly
15:46 AlexDaniel it was largerly my mistake, so I attempted to fix it with this: https://github.com/rakudo/rakudo/commit/10df9a95b3f5b4940fc7ce6b8ecf49fed0aea2f5
15:47 AlexDaniel 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
15:50 AlexDaniel I don't think we have to be so strict
15:51 AlexDaniel 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
15:51 ugexe and not just by the appveyor bot
15:53 ugexe 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:55 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.
16:00 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:01 stmuk I was amazed by how many complaints I got when there was no R* MSI
16:01 AlexDaniel stmuk: noted.
16:01 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
16:03 Zoffix 30 minutes is a lot of time.
16:04 Zoffix Also: you still have a problem that you can't just branch MoarVM/nqp bumps and roast
16:04 Zoffix Or rather, to do it properly, you have to set up your own MoarVM/NQP/Roast branches just for a single thing
16:05 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:06 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:08 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 AlexDaniel ? this sounds like a better idea. Less intrusive into the workflow at least
16:09 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.
16:09 Zoffix without this system in place.
16:09 Zoffix AlexDaniel: it's completely unworkable with the current system
16:09 Zoffix Version bumps + roast
16:10 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.
16:11 japhb Zoffix: perhaps we can mark roast test commits with the minimum rakudo commit needed to support them?
16:11 japhb So the merge manager doesn't merge the roast test until it merges that rakudo commit?
16:11 Zoffix That could work.
16:11 moritz the other thing we could do is revert breaking changes more quickly
16:12 Zoffix Yeah.
16:12 Zoffix 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.
16:13 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?
16:14 moritz japhb: no, I thought of a more manual/cultural thing
16:14 japhb OIC
16:15 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
16:15 AlexDaniel it can be a bot that keeps whining on this channel if something is clearly not right
16:15 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.
16:15 moritz and shoots me a quick message about why,
16:15 japhb So that anyone on channel can do that easily
16:16 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
16:16 moritz japhb: and if it works out well culturally, we can still do some automation around it
16:17 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
16:17 moritz japhb: at $work, it seems to work fine
16:17 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
16:18 AlexDaniel that too, yes
16:18 AlexDaniel if it was disclosed privately, who'd be testing if it works on windows?
16:19 ugexe well, in the commit (there was no PR)
16:19 ugexe someone on windows?
16:20 ugexe 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
16:20 ugexe nine fixed it for Linux shortly after
16:22 AlexDaniel c: 2017.07 say "a".match(/a/).made.^name
16:22 committable6 AlexDaniel, ¦2017.07: «NQPMu»
16:22 AlexDaniel c: HEAD say "a".match(/a/).made.^name
16:22 committable6 AlexDaniel, ¦HEAD(ca8aafc): «NQPMu»
16:23 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»»
16:24 AlexDaniel ah, that's an old thing
16:35 Geth ¦ rakudo/nom: 7a22d6cff3 | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/ChangeLog
16:35 Geth ¦ rakudo/nom: Log remaining changes
16:35 Geth ¦ rakudo/nom:
16:35 Geth ¦ rakudo/nom: Deliberately not logged:
16:35 Geth ¦ rakudo/nom: 26287a19 1ee8e9f3 7f0acb60 2545e6d6 10df9a95 bef974e3
16:35 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7a22d6cff3
16:48 * AlexDaniel off for a walk
19:37 Skarsnik Good luck with the release, time for bed :)
19:44 pmurias having an automatic build bot report on channel that a commit is broken on windows would be a good start
19:55 gfldex joined #perl6-dev
19:55 gfldex $*INITTIME seams not to be specced. Is that intentional?
19:59 moritz curious, it's been mentioned in #perl6 as early as 2010
20:00 moritz and in S28 since 2009
20:01 moritz ... and it looks like I was the one who implemented it initially: https://github.com/rakudo/rakudo/commit/45bb17e864
20:01 moritz I totally forgot.
20:01 moritz so, seems like it's a desired feature
20:01 lizmat ok, so it *does* seem to be specced, but there are no tests for it
20:02 lizmat AlexDaniel: I have a patch for say "a".match(/a/).made, but will keep that until after the release
20:03 lizmat I'm using nqp::isconcrete to test for NQPMu in HLL Perl 6
20:04 lizmat 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 lizmat fwiw, nqp::ifnull doesn't work
20:04 moritz because it's not null :-)
20:05 moritz could you do a type-check against Mu?
20:05 moritz and if it comes out False, return Mu instead?
20:05 moritz nqp::istype(thething, Mu)
20:07 jnthn lizmat: Where are you getting it from?
20:07 jnthn isconcrete will reliably work on it though
20:07 lizmat m: say "a".match(/a/).made   # jnthn
20:07 camelia rakudo-moar 7a22d6: OUTPUT: «No such method 'gist' for invocant of type 'NQPMu'. Did you mean 'isa'??  in block <unit> at <tmp> line 1??»
20:08 jnthn o.O
20:09 moritz maybe it should be initialized with Mu in Perl 6 match objects
20:09 moritz like in method !MATCH
20:09 gfldex left #perl6-dev
20:11 moritz lizmat: something like http://perlpunks.de/paste/show/5999ece5.6918.326
20:19 lizmat moritz: but that would slow down all Match object creation, no ?
20:20 lizmat moritz: my idea was more about adding: method made() { nqp::if(nqp::isconcrete($!made),$!made,Nil) }
20:20 lizmat which would only slow down whenever one actually calls .made
20:25 brrt joined #perl6-dev
20:54 moritz lizmat: ok, good point
21:08 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.
21:44 * Zoffix goes to bed
21:51 timotimo gnite Zoffix
21:53 timotimo lizmat: we'd have to put 3x3 new multidimref-like ops into moar to get the atposNd optimization back
21:55 Geth ¦ rakudo/nom: 1aee9aa573 | (Elizabeth Mattijsen)++ | src/core/atomicops.pm
21:55 Geth ¦ rakudo/nom: Rename Texas atomic ops as per jnthn's suggestion
21:55 Geth ¦ rakudo/nom:
21:55 Geth ¦ rakudo/nom: https://irclog.perlgeek.de/moarvm/2017-08-20#i_15047166
21:55 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1aee9aa573
21:56 Geth ¦ roast: 795045049b | (Elizabeth Mattijsen)++ | S17-lowlevel/atomic.t
21:56 Geth ¦ roast: Follow renaming of Texas atomic ops
21:56 Geth ¦ roast:
21:56 Geth ¦ roast: As per https://github.com/rakudo/rakudo/commit/1aee9aa573
21:56 Geth ¦ roast: review: https://github.com/perl6/roast/commit/795045049b
22:06 geekosaur joined #perl6-dev
23:38 eater joined #perl6-dev

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary