AlexDaniel so it's live now 00:56
bisect: dd "SOMETHING".Date
bisectable6 AlexDaniel, Will bisect the whole range automagically because no endpoints were provided, hang tight
AlexDaniel, 00:57
bisectable6 AlexDaniel, Bisecting by output (old=2020.02.1 new=2020.05.1) because on both starting points the exit code is 1 00:57
AlexDaniel
now what was that…
who wants to bet that deleting precomp files will fix that :) 00:58
AlexDaniel bisect: dd "SOMETHING".Date 01:06
bisectable6 AlexDaniel, Will bisect the whole range automagically because no endpoints were provided, hang tight
AlexDaniel, Output on all releases: gist.github.com/53c1691079edb36551...ae0d5efe90
AlexDaniel, Bisecting by output (old=2020.02.1 new=2020.05.1) because on both starting points the exit code is 1
AlexDaniel told ya!
bisectable6 AlexDaniel, bisect log: gist.github.com/55b46efbe3f3aa6f55...59a8c0f6d1
AlexDaniel, (2020-02-29) github.com/rakudo/rakudo/commit/d9...d198747f09
AlexDaniel, Bisecting by output (old=2017.05 new=2017.06) because on both starting points the exit code is 1
AlexDaniel, bisect log: gist.github.com/b7d7eb947cfeb80641...f1667cf2a8 01:07
AlexDaniel, (2017-06-01) github.com/rakudo/rakudo/commit/7c...656b955cd7
AlexDaniel, Bisecting by output (old=2016.09 new=2016.10) because on both starting points the exit code is 1
AlexDaniel, bisect log: gist.github.com/c5d07d9a5b24e85cd5...62036f582a
AlexDaniel, (2016-09-27) github.com/rakudo/rakudo/commit/22...0f14b9c05c
AlexDaniel, Output on all releases and bisected commits: gist.github.com/5693dccf20877f45d6...59cad6d62a
AlexDaniel OK, I know, not that impressive at all because I already showed that in the past. But look, it's committed now! And the code is not as horrible as it was! 01:08
anyway, expect a bit of a bumpy road at first because I can't really know if this is going to work in real world :) 01:09
there are some quirks I know about, but we'll see if anybody notices… :)
nine AlexDaniel: but deleting precomp files should never be necessary? 05:55
Geth nqp: usev6++ created pull request #643:
[JVM] Make gather work with last/next/redo in loop
06:25
[Tux] Rakudo version 2020.05.1-289-gf11d75084 - MoarVM version 2020.05-95-gc177e85cc
csv-ip5xs0.797 - 0.816
csv-ip5xs-207.676 - 7.852
csv-parser25.641 - 26.846
csv-test-xs-200.380 - 0.388
test7.973 - 8.048
test-t1.910 - 1.912
test-t --race0.827 - 0.934
test-t-2031.610 - 31.713
test-t-20 --race9.041 - 9.594
06:34
bartolin_ my above PR tackles a problem I've tried to fix (or at least understand) since more than five years. I guess, I've worked hundreds of hours on it (over the years). When I started out I've never heard about Java bytecode, so I guess I've learned one or two things ;)
nine Woah, bartolin_++ 06:55
moritz bartolin_++ indeed 07:13
Geth problem-solving: b0601e0a8a | (JJ Merelo)++ | solutions/ecosystem-versioning.md
Solution for issue #72
08:51
problem-solving: a13560b211 | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | solutions/ecosystem-versioning.md
Merge pull request #202 from JJ/master

Solution for issue #72: spin off module publishing tutorial in the documentation. No one has spoken against, or actually seem to care, so I guess I could as well merge it.
lizmat Files=1306, Tests=111382, 217 wallclock secs (28.93 usr 8.60 sys + 3029.01 cusr 287.12 csys = 3353.66 CPU) 08:58
Geth nqp/new-disp: c0d4f2f289 | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Ensure dispatch upholds flattening ordering rules
10:30
AlexDaniel nine: that is correct, but it doesn't change the fact that it solves issues sometimes 11:15
Geth problem-solving/revert-202-master: c6710b85f1 | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | solutions/ecosystem-versioning.md
Revert "Solution for issue #72: spin off module publishing tutorial in the documentation."
11:18
problem-solving: AlexDaniel++ created pull request #205:
Revert "Solution for issue #72: spin off module publishing tutorial in the documentation."
problem-solving: c6710b85f1 | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | solutions/ecosystem-versioning.md
Revert "Solution for issue #72: spin off module publishing tutorial in the documentation."
problem-solving: f616d5fd48 | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | solutions/ecosystem-versioning.md
Merge pull request #205 from Raku/revert-202-master

Revert "Solution for issue #72: spin off module publishing tutorial in the documentation."
JJMerelo AlexDaniel what's the problem with merging that? It's been 19 days with no feedback, positive or negative. 11:20
AlexDaniel JJMerelo: that's exactly the problem
JJMerelo: jnthn said “Please do; I'll review the solution.”, did he do that?
if so, he was supposed to indicate that the PR is ready, or something 11:21
just because something didn't get a response doesn't mean it's good
kinda the opposite really
JJMerelo AlexDaniel don't want to add additional load to the repo people, jnthn is the last of them. 11:23
But really, it's less work to review the proposal than reverting the commit.
AlexDaniel if jnthn said he'll review the solution then he's ok reviewing the solution
JJMerelo Process is important, but it's only as important as what's at stake here. 11:24
which is, basically, creating an issue in another repo.
AlexDaniel but if you violate the process all the time then there's no process at all
JJMerelo You have mentioned that 14 days have passed, so it can be merged 11:26
I really don't care about opening it back. You want to do that, feel free.
AlexDaniel my understanding has always been that it's 14 days once it is ready. That is when somebody says “ok, it's ready now, please review” 11:27
otherwise it's hard to know if you should review it at all, “draft” feature for PRs is relatively new and people don't use it as often 11:28
which is maybe why you didn't get any reviews, by the way
so to make it clear, you just submitted a PR, never indicated that it's ready, never pinged any reviewers, didn't wait for jnthn to give you the promised review, then went ahead and decided to merge it yourself 11:30
do you understand that this way you can merge pretty much any change, no matter how wrong or right it is?
JJMerelo not to get too picky on this, but your PR to revert my merge should have followed the same process github.com/Raku/problem-solving/pull/205
It didn't
So what you're basically saying is that only you can merge (or revert) any change, no matter how wrong or right it is. 11:31
AlexDaniel you're going to tell me how I violated the process I designed after you did it?
you had no assignee, so I'd say it was self-assigned. You called for a shortcut and merged it without following the process.
I object. Meaning that the change can be reverted 11:32
that's according to the process, if it's not clear
nine JJMerelo: that the revert was in the form of a PR doesn't mean that the full process has to apply. That's just a technical means to retroactively rejecting.
AlexDaniel: following the process is important of course. This particular issue doesn't look like it really needed the problem-solving process in the first place though. 11:33
After all the merged "solution" was really just an elaborate "we'll improve the docs"
JJMerelo As a matter of fact, it does. Because it's not taking the repo to the initial state, which would have been PR open and waiting for feedback.
AlexDaniel nine: I agree, but there was a PR, so what do we do
nine I suggest relaxing a little :) The damage if any is quite minimal 11:34
AlexDaniel nine: ideally someone should've just said “OK this particular idea doesn't need a PR so just go ahead and work on it”
nine absolutely, yes
AlexDaniel there's no damage, but let's not start complaining that the PR was reverted
nine JJMerelo: btw. I'm all for improving our module author's docs. Please do :)
JJMerelo AlexDaniel or "this particular idea does not need a PR so it's not a big deal that it's been merged"
nine we need to do that. Badly. 11:35
I'm not going to restore the PR. I'm going to do what was requested in the unmerged repo, which was basically that.
nine I understand that the problem-solving process is a hot topic. After all I was in the middle of the recent discussions. I do concur that we need to stick to a process until we decide to change the process.
As for this particluar issue, I'd say lets put it to rest. 11:36
JJMerelo Suppose you want to extract all use/need/require statements from a distro. What do you think would be the best way? Regexes? Using Perl6::Parser? Is there anything in core that allows you to do that already? 11:56
I think it would be very convenient to have a Test::Dependencies in the ecosystem that would test that what you have in META6.json is actually what you are using, and you've not left some boilerplate or old stuff there. 11:57
lizmat perhaps install a custom $*REPO that will records all requests for loading a given module 12:00
but that would imply all that is needed should already be available
but I guess in this case that would be ok, since you want to check whether a *working* module has all of its dependencies recorded in its META6.json 12:01
JJMerelo Right 12:03
m: my $*REPO = $*REPO but "say $_"; use Test; say $*REPO 12:10
camelia Unexpected named argument 'value' passed
in block <unit> at <tmp> line 1
JJMerelo I guess I'll have to find a way to create a custom $*REPO. If I can't figure it out, there's always regexen.
using $*REPO.need, I guess docs.raku.org/language/compilation#$*REPO 12:12
nine JJMerelo: create a class doing the CompUnit::Repository role. The `need` method can record the dependency and forward the request to self.next-repo 12:27
JJMerelo That's what I'm trying to do... Don't know about forwarding the request, really, after all, we don't really want to load the dependency, right? 12:28
nine Sure you do. Otherwise the test file won't be able to continue compiling 12:30
JJMerelo nine I'm trying this github.com/JJ/my-raku-examples/blo...om-repo.p6 12:33
nine and I get the error in "use Test": Too few positionals passed; expected 3 arguments but got 2 12:34
nine Because $precomp ought to be optional and have a default 12:35
JJMerelo nine right! 12:36
Got it working. Thanks!
Geth rakudo: afe851108f | (Elizabeth Mattijsen)++ | src/core.c/ForeignCode.pm6
Simplify EVAL(:check) handling

No need to coerce to Bool or set up a default, as Any is also falsy. Won't help much with performance, but every little bit helps.
14:02
sena_kun releasable6, status 14:10
releasable6 sena_kun, Next release in ≈4 days and ≈4 hours. 1 blocker. 143 out of 290 commits logged (⚠ 4 warnings)
sena_kun, Details: gist.github.com/4a5be11a68f9266cf5...72fbc97903
releasable6 Next release in ≈4 days and ≈3 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
nine Oh, this actually makes sense. The first object pulling in t/02-rakudo/03-corekeys-6c.t as a dependency of Test::Helpers.pm6 is the "Test" Stash. Both the script and Test::Helpers use this module and it gets repossessed into Test::Helpers 16:40
nine Which unfortunately brings me back to MoarVM refusing to load modules multiple times. Because of this we of course get the same objects for such symbols which causes them to get repossessed which inevitably drags in those dependencies. 16:56
jnthn If it did load the bytecode multiple times, the SC handle would still be identical 17:00
So you'd still not solve anything
At least, not only by making it not do that 17:01
nine Yes, that's why I gave up on that approach yesterday. I don't really have any other idea though :/ 17:02
jnthn I guess our separate compilation ain't as separate as we'd wish... 17:03
Each thing having its own GLOBALish only solves the problem one level deep 17:04
nine Indeed, as these different GLOBALishs already share the same values 17:05
Incidentally that's the same restriction as lexical module loading 17:06
jnthn Yup
.WHO hangs off the stable, which hangs off the type object, and we expect there to be one of those...
Well, do a degree we do 17:07
*to
I wonder how far that's really true
nine Would it be possible to create a repossession barrier? I.e. tell the VM to not repossess objects that were created before that point but just clone them into the current SC? 17:12
jnthn Hmm...but then we end up with multiple of the same object in memory? 17:13
Or did we want to throw them all away again after precomp? 17:14
nine We do...at least for now
lizmat likes to be reminded why the Match object isn't a value type? 20:45
I mean, it *is* immutable, ls it not ?
moritz it's .ast is mutable at least 20:48
the rest shouldn't be, after it's finished
lizmat hmmm... 20:49
ok, not a value type then :-) 20:51
FWIW, /me is working on a version of Match that is *not* a child class of Capture, and which does *not* have any additional attributes 20:52
which basically means it won't need any post-processing when it is returned from NQP 20:53
Geth nqp: 7b67febc70 | (Christian Bartolomäus)++ | src/vm/jvm/QAST/Compiler.nqp
[JVM] Minimal fix for comment and alignment

  (Those extra spaces have distracted me far too often, so they
have to go.)
21:02