00:02 dogbert17 joined 00:05 dogbert11 left 00:16 dogbert2 joined 00:19 dogbert17 left 00:22 dogbert11 joined 00:23 dogbert2 left 00:33 dogbert11 left 00:51 dogbert11 joined, Altai-man joined 00:52 dogbert17 joined 00:54 sena_kun left 00:55 dogbert11 left
Geth roast/revert-669-done: e37d7732e1 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Revert "Test Test::done-testing( --> Bool:D)"
00:58 dogbert2 joined
Geth roast: vrurg++ created pull request #670:
Revert "Test Test::done-testing( --> Bool:D)"
roast: e37d7732e1 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Revert "Test Test::done-testing( --> Bool:D)"
roast: a5a75c1507 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #670 from Raku/revert-669-done

Revert "Test Test::done-testing( --> Bool:D)"
Must be using `is_run`.
01:00 dogbert17 left
Geth roast: vrurg++ created pull request #671:
Add test for WalkList.invoke() lazyness
rakudo: vrurg++ created pull request #3863:
Make WalkList.invoke() return a lazy Seq
rakudo: vrurg++ created pull request #3864:
Seq must have own proto for new
02:01 dogbert2 left, dogbert2 joined 02:14 dogbert11 joined 02:16 dogbert2 left 02:25 dogbert17 joined 02:29 dogbert11 left 02:39 chansen_ joined
Geth rakudo: fe40ee1e02 | (Vadim Belman)++ | src/core.c/WalkList.pm6
Make WalkList.invoke() return a lazy Seq

It had to be this way since the beginning.
rakudo: bdd8e70e2e | (Vadim Belman)++ (committed using GitHub Web editor) | src/core.c/WalkList.pm6
Merge pull request #3863 from vrurg/walklist-seq

Make WalkList.invoke() return a lazy Seq
roast: d7f10ed908 | (Vadim Belman)++ | S12-introspection/walk.t
Add test for WalkList.invoke() lazyness

It now returns a lazy `Seq`.
Also, correct another test to reflect this change and fix an incorrect one.
roast: 04bfe4c9ef | (Vadim Belman)++ (committed using GitHub Web editor) | S12-introspection/walk.t
Merge pull request #671 from vrurg/walklist-seq

Add test for WalkList.invoke() lazyness
roast: vrurg++ created pull request #672:
Remove :desc named from parameters
roast: 2ce9ff9323 | (Vadim Belman)++ | 4 files
Remove :desc named from parameters

And redo calls with `:todo` named parameter by using `todo` call.
Resolve Raku/problem-solving#215 and Raku/problem-solving#188
roast: f1c5dc2867 | (Vadim Belman)++ (committed using GitHub Web editor) | 4 files
Merge pull request #672 from vrurg/problem-solving-215

Remove :desc named from parameters
03:02 dogbert11 joined 03:05 dogbert17 left 03:12 dogbert11 left 03:37 dogbert11 joined 03:42 dogbert17 joined, dogbert11 left 03:46 dogbert11 joined 03:49 dogbert11 left, dogbert17 left 03:50 dogbert11 joined 03:54 lucasb left, dogbert11 left 03:56 dogbert11 joined 04:01 dogbert17 joined, dogbert11 left, dogbert17 left 04:02 dogbert17 joined 04:38 dogbert17 left 04:52 sena_kun joined 04:54 Altai-man left 05:05 dogbert17 joined 06:09 dogbert11 joined 06:12 dogbert17 left 06:18 dogbert11 left, dogbert11 joined 06:25 dogbert17 joined 06:29 dogbert11 left 06:33 dogbert11 joined 06:37 dogbert17 left 06:38 dogbert11 left, dogbert11 joined 06:50 dogbert11 left 06:51 Kaiepi joined 06:52 dogbert11 joined 07:15 Kaiepi left, Kaiepi joined
Geth nqp/fetch-and-delete: 7f96e4e384 | (Nicholas Clark)++ | 2 files
Proof of concept bindings for fetch_delete_key and a regression test.
nqp: nwc10++ created pull request #658:
Proof of concept bindings for fetch_delete_key and a regression test.
nwc10 lizmat: I baked you an op, and I didn't eated it. :-) 07:52
08:51 Altai-man joined 08:54 sena_kun left
lizmat nwc10++ 09:35
nwc10: perhaps 'grabkey' is a better, shorter name ? 09:36
nwc10 I like that. and then I thought "but you're grabbing the *value* at that key". 09:44
but it migth work better anyway
lizmat grab implies taking ownership *and* removal from its original location to me 09:46
nwc10 it didn't *immediately* to me. But I need to chew on it for a bit
(also known as "I seem to have no coffee") 09:47
lizmat caffeinated toffees ? 09:48
09:54 Kaiepi left 09:55 Kaiepi joined 09:56 dogbert17 joined 09:59 dogbert11 left 11:03 leont joined 11:15 dogbert11 joined 11:18 dogbert17 left, dogbert17 joined 11:23 dogbert11 left 11:31 Kaiepi left, Kaiepi joined 11:38 Kaiepi left 11:39 Kaiepi joined 11:41 Kaiepi left 11:43 Kaiepi joined 11:45 Altai-man left 11:48 Kaiepi left 11:55 Kaiepi joined 12:00 dogbert11 joined 12:02 dogbert12 joined 12:03 dogbert17 left 12:05 sena_kun joined, dogbert11 left 12:06 dogbert17 joined
sena_kun releasable6, status 12:06
releasable6 sena_kun, Next release in ≈6 hours. 1 blocker. Changelog for this release was not started yet
sena_kun, Details: gist.github.com/630a97e0d5993cd6dc...bf371a0ba3
12:06 dogbert12 left 12:07 dogbert11 joined 12:10 dogbert17 left 12:11 dogbert17 joined 12:13 dogbert11 left 12:16 dogbert11 joined 12:19 dogbert17 left
Geth rakudo: a19996dbce | (Vadim Belman)++ | src/core.c/Seq.pm6
Seq must have own proto for new

Because instantiation with a `Iterator` is the only valid way to initialize a Seq then the `new` candidates from parent classes must not be considered.
rakudo: ee96b37ad3 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core.c/Seq.pm6
Merge pull request #3864 from vrurg/fix-seq-new

Seq must have own proto for new
12:23 dogbert17 joined 12:24 dogbert17 left 12:25 dogbert17 joined, dogbert11 left 12:26 dogbert11 joined 12:29 dogbert12 joined 12:30 dogbert17 left 12:31 dogbert11 left 12:32 dogbert17 joined 12:35 dogbert12 left 12:51 Altai-man joined 12:53 sena_kun left 13:13 dogbert11 joined 13:17 dogbert17 left 13:30 dogbert17 joined 13:33 dogbert11 left 13:46 dogbert11 joined 13:48 dogbert17 left
Altai-man does release 13:49
Geth rakudo/release-2020.08: 6 commits pushed by Altai-man++ 13:52
14:08 dogbert17 joined 14:10 dogbert11 left 14:30 dogbert12 joined 14:32 dogbert17 left 14:37 dogbert17 joined 14:39 dogbert12 left
MasterDuke nwc10, lizmat: eject_key perhaps? 14:46
15:08 lucasb joined 15:19 dogbert11 joined 15:21 dogbert17 left
lizmat MasterDuke: that doesn't imply to me that it returns its value 16:08
Altai-man releasable6, status 16:20
releasable6 Altai-man, Next release in ≈2 hours. 1 blocker. 70 out of 74 commits logged
Altai-man, Details: gist.github.com/cd0f7f37c44d9c185d...a2344f6be7
MasterDuke excise_key, evict_key, extraordinary_rendition_key, extract_key? 16:37
lizmat I guess extract_key comes closer
MasterDuke no idea why all my suggestions start with 'e'... 16:39
lizmat because they're all excellent ? 16:41
MasterDuke elide_key 16:42
exhume_key 16:43
16:52 sena_kun joined 16:54 Altai-man left
Geth nqp/release-2020.08: 4aeb7aaef1 | Altai-man++ | tools/templates/MOAR_REVISION
[release] Bump MoarVM revision to 2020.08
nqp/release-2020.08: 90166ede79 | Altai-man++ | VERSION
[release] Bump VERSION to 2020.08
nqp: Altai-man++ created pull request #659:
Release 2020.08
nqp: 4aeb7aaef1 | Altai-man++ | tools/templates/MOAR_REVISION
[release] Bump MoarVM revision to 2020.08
nqp: 90166ede79 | Altai-man++ | VERSION
[release] Bump VERSION to 2020.08
nqp: 62f28e3e40 | Altai-man++ (committed using GitHub Web editor) | 2 files
Merge pull request #659 from Raku/release-2020.08

Release 2020.08
rakudo: Altai-man++ created pull request #3866:
Release 2020.08
rakudo/master: 7 commits pushed by Altai-man++
MasterDuke sena_kun++ 17:28
lizmat sena_kun++ 17:32
whee! YARR!
Geth rakudo/sorting-with-junctions: a78fb723f9 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Sorting.pm6
Handle the case of cmp returning a Junction

As AlexDaniel++ pointed out, we should *also* check whether cmp returned a Junction, which may also happen in some situations.
This does *not* fix the case of sorting lists that have Junctions in them. The case of sorting Maps/Hashes is even more interesting: it stringifies the Map/Hash for comparison, and this uses sort, and dies doing *that*.
Also abstract the error throwing into a separate sub: DRY!
lizmat sena_kun: I just pulled Rakudo master, and it didn't fetch MoarVM 2020.08 for me? Did you forget to bump NQP ? 17:37
AlexDaniel c: sorting-with-junctions,HEAD say $*PERL.compiler.version 17:40
committable6 AlexDaniel, ¦sorting-with-junctions: «v2020.07.71.gec.08.b.1.b.37␤» ¦HEAD(0e7f426): «v2020.07.81.g.0.e.7.f.426.e.5␤»
AlexDaniel c: sorting-with-junctions,HEAD say $*PERL.compiler.version 17:51
committable6 AlexDaniel, ¦sorting-with-junctions: «v2020.07.72.ga.78.fb.723.f␤» ¦HEAD(0e7f426): «v2020.07.81.g.0.e.7.f.426.e.5␤»
AlexDaniel c: sorting-with-junctions,HEAD say [1 => any(4, 2), 1 => 2].sort: &[cmp]
committable6 AlexDaniel, gist.github.com/e54a0a52cd70e52f17...d228c7ec09
AlexDaniel c: sorting-with-junctions,HEAD say [1 => any(4, 2), 1 => 2].sort: &[eq] 17:57
committable6 AlexDaniel, ¦sorting-with-junctions,HEAD(0e7f426): «This type cannot unbox to a native integer: P6opaque, Junction␤ in block <unit> at /tmp/97TASUhtCk line 1␤␤ «exit code = 1»»
AlexDaniel lizmat: OK I actually expected &[cmp] to do the same but it does nqp::eqaddr(&by,&infix:<cmp>)
lizmat: point is, I think other sort variants that don't go through `compare` are still not checking that they are not getting a junction 17:58
lizmat AlexDaniel: am looking at that
AlexDaniel lizmat: also, let's see what this does: 17:59
c: sorting-with-junctions,HEAD say [<42e0>, 1 => any(4, 2)].sort 18:00
committable6 AlexDaniel, ¦sorting-with-junctions,HEAD(0e7f426): «This type cannot unbox to a native integer: P6opaque, Junction␤ in block <unit> at /tmp/cmdOLQVczH line 1␤␤ «exit code = 1»»
lizmat but am more worried about the release not being 2020.08 internally
AlexDaniel lizmat: so here again only the fallback `compare` multi is doing the checking, the other variants are not (even those that fall back to cmp)
lizmat AlexDaniel: yes, your point is clear :-) 18:01
AlexDaniel well, these are two different issues :)
lizmat m: print slurp $*EXECUTABLE.parent(3).add("VERSION") 18:04
camelia Failed to open file /home/camelia/VERSION: No such file or directory
in block <unit> at <tmp> line 1
lizmat m: print slurp $*EXECUTABLE.parent(2).add("VERSION")
camelia Failed to open file /home/camelia/rakudo-m-inst-2/VERSION: No such file or directory
in block <unit> at <tmp> line 1
lizmat m: print slurp $*EXECUTABLE.parent(1).add("VERSION")
camelia Failed to open file /home/camelia/rakudo-m-inst-2/bin/VERSION: No such file or directory
in block <unit> at <tmp> line 1
lizmat m: dd $*RAKU.compiler.version 18:05
camelia v2020.07.81.g.0.e.7.f.426.e.5
lizmat sena_kun: ^^^
AlexDaniel sena_kun: how did that happen? 18:06
I mean, the sakefile should write the version
if it didn't then I f-ed up :(
lizmat fwiw, the VERSION file is still showing "2020.07" for me
AlexDaniel lizmat: yeah, there was no VERSION file bump
lizmat shit happens
AlexDaniel interestingly, nqp was bumped 18:07
sena_kun no 18:08
just no
AlexDaniel I mean, nqp itself. But the release is still using 2020.07-10-g36670be51
sena_kun: if it's just a typo on the command line then we should add a protection against that 18:09
sena_kun Hmmmm.
lizmat $ raku -v 18:10
This is Rakudo version 2020.07-81-g0e7f426e5 built on MoarVM version 2020.07-16-g03d3e43fa
implementing Raku 6.d.
so it also appears to miss the MoarVM version bump ?
sena_kun AlexDaniel, ok, I see commits bumping version in a checkout created by akefile.
And they are tagged. 18:11
How they did not go into release.
AlexDaniel lizmat: nah it's not just like that. Humans do mistakes and we proved that so many times with releases :) Question is how can we change the tooling so that same mistakes will never happen again
sena_kun resigns 18:12
AlexDaniel lizmat: if the tooling allows to create a release like that then it's not release manager's fault, really
sena_kun so SOMEHOW commits before bumps were tagged and pushed.
lizmat AlexDaniel sena_kun : if you feel I expressed blaming anybody, please tell me how I did that, because I most specifically did *NOT* want to blame anybody 18:13
sena_kun I saw something is not ok with nqp, because commits were not pushed, so I pushed them, as I was in a hurry (I have things to do as well).
lizmat, nah, that's fine. It was a situation-fitting lame joke of mine about resigning.
And now I see rakudo with bump commits not pushed.
AlexDaniel lizmat: nobody is blaming anybody, except me blaming myself and sena_kun blaming themself :) 18:14
sena_kun _THE_ question is how to make it normal again.
AlexDaniel sena_kun: we can't? The tag was pushed
lizmat Bump the VERSION file, wait a few days, and possibly do a point release
sena_kun lizmat, any reasons to wait? 18:15
18:15 travis-ci joined
travis-ci Rakudo build errored. Altai-man 'Merge pull request #3866 from rakudo/release-2020.08 18:15
travis-ci.org/rakudo/rakudo/builds/720236375 github.com/rakudo/rakudo/compare/e...7f426e5610
18:15 travis-ci left
AlexDaniel sena_kun: I mean, point release is the only proper way I think. Another way is rewriting the tag but meh… 18:15
sena_kun: first of all it's probably a good idea to push the bumps 18:16
sena_kun AlexDaniel, rakudo ones?
lizmat sena_kun: in case other problems show up ?
AlexDaniel sena_kun: yes, I mean commits in rakudo that were not pushed
sena_kun They are in a release branch which was already merged, but I'll do another PR/merge now. 18:17
Geth rakudo/release-2020.08: a3cbda8915 | Altai-man++ | tools/templates/NQP_REVISION
[release] Bump NQP revision to 2020.08
rakudo/release-2020.08: 1336e5f3e3 | Altai-man++ | VERSION
[release] Bump VERSION to 2020.08
18:17 finsternis left
sena_kun lizmat, better to patch it now while I have whole night and before too many people noticed this. :] 18:17
Geth rakudo: Altai-man++ created pull request #3867:
Missed 2020.08 tags
AlexDaniel sena_kun: ok now you can also merge that to master
lizmat sena_kun++ # you're the boss :-) 18:18
sena_kun So now there are github.com/rakudo/rakudo/pull/3867
Geth rakudo: a3cbda8915 | Altai-man++ | tools/templates/NQP_REVISION
[release] Bump NQP revision to 2020.08
rakudo: 1336e5f3e3 | Altai-man++ | VERSION
[release] Bump VERSION to 2020.08
rakudo: f2464e3383 | Altai-man++ (committed using GitHub Web editor) | 2 files
Merge pull request #3867 from rakudo/release-2020.08

Missed 2020.08 tags
sena_kun Merged.
AlexDaniel sena_kun: these are just the bumps in files, nothing to do about tags, but it makes the situation a bit more right
sena_kun Also, I know for sure what's wrong with me using akefile, so I'll patch it later to not do such disaster again. 18:19
Okay. Okay, now manual bumps, tagging and, ugh, basically whole re-packing. 18:20
AlexDaniel sena_kun: why manual bumps?
18:20 MasterDuke left
AlexDaniel sena_kun: just run the akefile again with RAKUDO_VERSION=2020.08.1 18:20
sena_kun needs to think a bit
AlexDaniel, it will take commits from master and I don't want that, because some of them are untested. 18:21
AlexDaniel I actually noticed that in the release guide, releasable not mentioned for point releases even though the akefile can do them
sena_kun We can actually checkout a branch from the commit I consider safe and cherry bumps there, but this will make things more confusing. OTOH, no need to patch changelog. 18:22
AlexDaniel sena_kun: BRANCH_RAKUDO=my-new-point-release-branch
sena_kun Yeah.
AlexDaniel no cherry-picking
just BRANCH_RAKUDO=my-new-point-release-branch VERSION_RAKUDO=2020.08.1
sena_kun AlexDaniel, where do you suggest to checkout a branch from? HEAD?
AlexDaniel oooh I see what you mean 18:23
lizmat sena_kun: should we now get a MoarVM 2020.08 ?
sena_kun a - b - c (this commit I released) - d - e (untested folks) - (bumps)
lizmat because I'm still not getting that after a reconfig
AlexDaniel sena_kun: from release-2020.08 I think 18:24
sena_kun lizmat, github.com/MoarVM/MoarVM/blob/master/VERSION ?
AlexDaniel, so cherry-picking bumps, right?
lizmat ]$ cat nqp/tools/templates/MOAR_REVISION 18:25
sena_kun ^^
sena_kun lizmat, but this is not moar version, this is nqp moar revision.
lizmat shouldn't that be 2020.08 ?
sena_kun lizmat, ah, I got what you mean. Well, what you observe is the part of the problem, yes.
lizmat, it should, I screwed it both with rakudo and nqp, so nqp is screwed as well. 18:26
sena_kun prepares branches for a point 18:27
AlexDaniel ooooh the nqp tag is old also…
at least the commits are there…
sena_kun: question! Are reverts supposed to be in the release?
sena_kun AlexDaniel, yes.
They are totally planned.
AlexDaniel sena_kun: then release-2020.08 already has bumps 18:28
sena_kun: no cherry picking required from what I can see, it just needs new commits for the point release 18:29
sena_kun revives deleted branches
AlexDaniel sena_kun: because you never merged anything into release-2020.08, you merged release-2020.08 into master 18:30
sena_kun: you can also start a new branch from 1336e5f3e and that'd be even better
linkable6 (2020-08-22) github.com/rakudo/rakudo/commit/1336e5f3e3 [release] Bump VERSION to 2020.08
sena_kun Ok, so now we have github.com/Raku/nqp/commits/release-2020.08 and github.com/rakudo/rakudo/commits/r...se-2020.08 18:31
I'm starting ake with them specified. 18:32
And it should work out. 18:33
AlexDaniel sena_kun: to double check, it should look like this: VERSION=2020.08 VERSION_RAKUDO=2020.08.1 VERSION_NQP=2020.08.1 BRANCH_RAKUDO=release-2020.08 BRANCH_NQP=release-2020.08 18:34
sena_kun TEST_JOBS=24 VERSION=2020.08.1 VERSION_MOAR=2020.08 BRANCH_ROAST=e37d7732e1d7479de8802b5cbcd4b22a7b2d6f17 BRANCH_RAKUDO=release-2020.08 BRANCH_NQP=release-2020.08
AlexDaniel that's also correct!
sena_kun AlexDaniel, why VERSION 2020.08 if we want a point?
AlexDaniel sena_kun: to set the version for MOAR. Your version is also right! 18:35
sena_kun Ah, okay. Now I am a bit confused. Anyway, _this_ time I'll double check before pushing tars.
AlexDaniel it's all good, two releases for the price of one :)
18:35 MasterDuke joined
sena_kun How people even survive releasing for, say, a year, without a mistake, while not having all this automation around. 18:37
AlexDaniel, thanks for your help, sorry for all the bother.
AlexDaniel sena_kun: I enjoy git puzzles :) 18:38
sena_kun Guess I am not paranoid and pedantic enough to triple-check things, especially while in a great hurry. :\
AlexDaniel sena_kun: that's one of the reasons why I couldn't do them any longer, I'd usually do the whole thing in several goes, each time checking everything to make sure I didn't miss something. By the end I'd be like “interesting, I can't see any issues… is it like… ready?” and then check everything again several times… paranoid yes. 18:43
and for me it'd take all my mental power just to keep everything in mind, even though it isn't much actual work 18:44
but it doesn't matter because I think I did like 4 point releases in total anyway?
because of the bugs and stuff 18:45
so maybe it's a better idea to perfect point releases and let yourself be a bit sloppy :)
sena_kun While I don't mind running roast times and times now and it isn't particularly hard to release, I am starting to worry if such a loose release manager can damage actual image of the whole team.
AlexDaniel stop it, you're doing great 18:46
sena_kun And that is something I'd rather not do, so my only way is to patch code.
AlexDaniel there were only 3 people who were able to do it continuously. Zoffix, me and now you 18:47
but then take a look at my “MONTHLY” releases
you brought it back in order by actually making them monthly
(to order? I dunno… English is hard, you get my point)
sena_kun Yeah. 18:48
I think it's *to, but prepositions are hard and I suck at English more than average. :]
AlexDaniel btw there was also [Coke], even though that's early times when the stakes were a bit lower I guess, still pretty good work tho! 18:49
sena_kun Ok, nqp is built.
This is nqp version 2020.08.1 built on MoarVM version 2020.08
This seems about right.
AlexDaniel yeah, `git log` to double check the tag
(that it's on the last commit) 18:50
sena_kun (HEAD -> release-2020.08, tag: 2020.08.1) for [release] Bump VERSION to 2020.08.1
AlexDaniel yaay
sena_kun Ok, now time for roasting some tests~ 18:51
Oh-uh. 18:53
I guess I need to mark point in release_guide.
AlexDaniel yeah also you probably need a release announcement 18:54
sena_kun Yeah.
AlexDaniel you can let the tests and everything run, make the commits, move the git tag…
though you decide if it's safer to just rerun the akefile :) 18:55
sena_kun Yesh. 18:56
Geth rakudo/release-2020.08: e706b5ada7 | Altai-man++ | 3 files
2020.08.1 release announcement + changelog
sena_kun ^ should be good
"these are just the bumps in files, nothing to do about tags" <- oh, this is very right, but I am not best at naming things when panik. :S 19:21
19:28 dogbert17 joined 19:30 dogbert12 joined 19:32 dogbert13 joined, dogbert11 left 19:35 dogbert17 left, dogbert12 left 19:42 dogbert13 left, dogbert13 joined
lizmat remembers actually having done 5 releases 19:46
19:53 dogbert17 joined 19:56 dogbert13 left 19:57 dogbert11 joined 20:02 dogbert17 left, travis-ci joined
travis-ci Rakudo build passed. Altai-man 'Merge pull request #3867 from rakudo/release-2020.08 20:02
travis-ci.org/rakudo/rakudo/builds/720248518 github.com/rakudo/rakudo/compare/0...464e3383d9
20:02 travis-ci left 20:05 dogbert17 joined 20:07 dogbert11 left 20:23 dogbert11 joined
AlexDaniel lizmat: not in a row! :) 20:25
sena_kun AlexDaniel, 3 releases were in a row.
Including a point.
20:26 dogbert17 left
AlexDaniel all people who did releases are wonderful, but what I'm trying to say is that doing that kind of work continuously is a different kind of effort 20:28
and you're doing great, sena_kun
sena_kun AlexDaniel, I deeply appreciate your cheering. 20:29
dogbert11 so when will the point release be out? 20:30
lizmat also cheers our Release Manager! 20:31
sena_kun dogbert11, today, I hope.
dogbert11 ++sena_kun
lizmat AlexDaniel: indeed. 2 in a row + a point release :-) been there, done that 20:34
sena_kun Nooooooo. 20:49
===SORRY!=== Error while compiling /home/koto/.zef/store/Inline-Perl5-0.50.tar.gz/Inline-Perl5-0.50/t/v6.t
Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' (from '/home/koto/.zef/store/Inline-Perl5-0.50.tar.gz/Inline-Perl5-0.50/lib/Inline/Perl5.pm6 (Inline::Perl5)')
20:51 Altai-man joined
Altai-man Another interesting detail: I have 2020.08.1 in VERSION in rakudo repo, but if I do ./install/bin/rakudo --version it shows `This is Rakudo version 2020.07-81-g97119432f`. 20:52
I am getting this second time in a row, so cleaning everything and starting from scratch does not help against `Missing or wrong version`.
20:54 sena_kun left
Altai-man In rakudo dir in `gen/moar` I don't even have `stage2`. 20:55
Oh, it should be in nqp land. 20:58
Geth roast: 256f7acfaf | (Elizabeth Mattijsen)++ | S32-list/sort.t
Add some more tests for sorting with Junctions
21:05 dogbert11 left 21:08 dogbert11 joined 21:14 dogbert17 joined 21:17 dogbert11 left 21:22 AlexDaniel left 21:23 dogbert17 left, dogbert17 joined
Geth roast: ziuq++ created pull request #673:
Fix #669 by using is_run
linkable6 ROAST#669 [closed]: github.com/Raku/roast/pull/669 Test Test::done-testing( --> Bool:D)
Altai-man Ok, third time in a row, time to stop. 21:40
Geth rakudo/sorting-with-junctions: 39457b0914 | (Elizabeth Mattijsen)++ | 5 files
Globalize local compare function

CMP_DISALLOW_JUNCTIONS is now a global "implementation-detail" sub that provides a faster infix:<cmp> that does not allow Junctions and returns a native int rather than an Order enum. This is now also used by the @a cmp @b logic.
... (7 more lines)
lizmat Altai-man++ # perseverance
Altai-man Well, I still have no clue what is wrong with `Missing or wrong version of dependency`, this seems to be very screwed. 21:42
lizmat lemme double check here
Altai-man lizmat, you'd need to use releasable script.
lizmat well, if I could repro it on master, you'd have another datapoint :-) 21:43
can't repro on sorting-with-junctions branch 21:44
nor on master :-( 21:45
Altai-man lizmat, is it normal version from VERSION file in rakudo and what `/install/bin/rakudo --version` tells you after make install differs? 21:46
lizmat no, I don't think so 21:47
Altai-man :/
Geth rakudo/sorting-with-junctions: 1512369d9a | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Sorting.pm6
Fix nit
Altai-man ouch 22:04
lizmat, around?
no, wait, that's oot the problem 22:05
lizmat Altai-man: still here, somewhat 22:07
Altai-man lizmat, I thought maybe Inline::Perl5 is broken in general and was going to ask you to try to install it in your branch, but now that I think of it maybe that's not a nice plan, because I made a release and it was ok. 22:10
lizmat yeah... I tried it already in my sorting junctions branch 22:11
and it was ok
Altai-man Hm.
So something is off somewhere else.
lizmat double checked, but both "make spectest" run the Inline::Perl5 tests ok, as well as "make test" in Inline::Perl5 itself 22:12
Altai-man lizmat++ for checking
22:39 Kaeipi joined 22:40 Kaiepi left 22:46 Kaeipi left 23:42 Altai-man left