🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:00 reportable6 left 00:02 reportable6 joined
Geth roast: 2colours++ created pull request #828:
Test for parameterised hashes as entries to store		 00:12
02:30 nine left, nine joined 03:22 heartburn left 03:23 heartburn joined 05:52 codesections left 06:00 reportable6 left, reportable6 joined
Geth nqp: usev6++ created pull request #795:
[JVM] Handle null in is(int|num|str)		 06:26
07:01 linkable6 left, evalable6 left 07:02 linkable6 joined 07:04 evalable6 joined 07:32 codesections joined 07:38 heartburn left, epony joined 07:46 heartburn joined
Nemokosch github.com/rakudo/rakudo/pull/5169 feel free to join this review; alas, we seem to be stuck at the zeroeth step but one can only make progress with multiple perspectives 09:24
09:49 codesections left 09:54 ab5tract joined
lizmat I have a different fix, running tests now 09:54
10:01 sena_kun joined
Nemokosch a different fix for the same problem? 10:01
Geth rakudo/main: 932df924f8 | (Elizabeth Mattijsen)++ | src/core.c/Hash.pm6
Fix for #5165

The problem was caused by not checking for object hashes when storing a (object or normal) hash into another normal hash.
This takes another approach than Pull Request #5169, in that it does
  *not* impose a penalty for *each* key that is being stored, (even in
normal hashes). Instead, when a Mappy thing is encountered, a special private method STORE_OBJECT_MAP is called that does the whole object hash correctly.
Nemokosch That's a sure way to lose any interest from possible contributors...
and even at the first blink, I find this fix more rigid, to be honest. It hardcodes the handling of a role into the base class. 10:03
lizmat Your approach was valid, but was affecting the standard case significantly by introducing a method call for *each* key being stored 10:04
Nemokosch an easily optimizable method call 10:05
it doesn't seem like a huge penalty but surely, let's benchmark it at least
lizmat if you want to spend time on that, be my guest
Nemokosch Well, you wanted to spend time on an already fixed issue, rather than helping out with how to improve it 10:06
So you made performance assumptions in the first place, not me
lizmat the fact that this bug was there for more than 6 years I think proves that trying to store object hashes in normal hashes doesn't happen very often
Nemokosch You know, I even said > Another solution could be to expose and overload > STORE_MAP directly for the subtypes. 10:08
lizmat indeed
Nemokosch Anyway, do you not feel that what you are doing here is highly destructive?
lizmat in code or in handling the PR ? 10:09
Nemokosch Well, the handling of the situation itself
Basically throwing out someone else's work in the trash bin with like two clicks, rather than discussing what could be done better
lizmat note: I'm in a grumpy mood this morning 10:10
Nemokosch all it would have taken is to say "hey, this will be called 1000 per script, rather work toward your other proposal"
and I would have understood - after all, I needed to melt my brain for like 2 hours to make this rather little change, my judgement may not have been perfect
lizmat about "Basically throwing out someone else's work in the trash bin with like two clicks" 10:12
this happens. I've done it to my own PRs on which I worked *many weeks*
so please, don't give me that:
Nemokosch does that make it less destructive? 10:13
lizmat question yourself: did you learn something from melting your brains for 2 hours ?
Nemokosch You know, I learned that one needs to be a masochist to try and help out with core development.
Geth roast: ba0314c18a | (Márton Polgár)++ (committed using GitHub Web editor) | S09-hashes/objecthash.t
Test for parameterised hashes as entries to store (#828)

Enforces github.com/rakudo/rakudo/issues/5165 should not happen.		 10:14
nine Nemokosch: sorry to say this, but then you just learned the wrong lession.
tellable6 nine, I'll pass your message to Nemokosch
nine, I'll pass your message to Nemokosch 10:15
10:15 linkable6 left 10:16 Geth left, Geth joined
Nemokosch well, good luck finding people who learn the right lesson 10:17
10:17 linkable6 joined
and no, this is not about the technicalities at all. This is the personal responses, your own, for example 10:18
nine Can you please explain that further? From my perspective, all I have done is applying the same review standards that I have used for the past 15 years, both profesionally in multiple companies and with open source work. I fail to understand how that could offend so much, especially since most of what I wrote are just questions. 10:19
Review standards that I myself am happy to fulfil with my own PRs. 10:20
Nemokosch I wouldn't say you offended but I am questioning that you tried to actually help, rather than just inviting to a guessing game of "git gud" literally
lizmat *and* mine, I'd say :-) you just backscroll here
nine Sorry, what does "git gud" mean? 10:21
Nemokosch like "just get better"
nine Mind that we are all coming from different backgrounds and as far as I can tell no one here has English as their first language. 10:22
Nemokosch Yes, fair point
And also, I don't want to equate the two feedbacks coming from you and liz, lol 10:23
10:24 sena_kun left
nine One question on this: do you _really_ think that I want to waste my time on playing silly games in a Github PR? I mean, you must have seen how much time I already spend on Rakudo development. That's on top of my fulltime day job and several other hobbies. Why would I want to waste anyone's time, especially my own? 10:24
Nemokosch Not with the intention of wasting time but you did basically ask me to waste my time - on guessing what you mean by something not being explained that I see it being written down fair and square 10:26
nine "on guessing what you mean" that's exactly how I felt about your PR :D 10:27
Nemokosch Well then it cannot be helped but for the record, I did quote the very part that answered one of your questions, for example 10:28
nine To make one thing clear: you are right, that I did _not_ follow that link. The reasons for that are exactly what I explained. I am 100 % convinced that all the information _must_ be contained in the commit message. That's what 20 years of professional software development and 7 years in Rakudo and MoarVM taught me. And I am not the only one who thinks so.
Nemokosch it was like, say, I paint a room, check the color, seems red to me at least. Then you come and only say "hmm, could you maybe paint it red?" 10:29
and then I would ask you to give me the paint you'd like me to use
nine Sorry, have to leave for an interview now. Will come back later.
10:29 codesections joined
Nemokosch 👍 10:31
by the way, you're also probably right that if somebody ONLY sees the commit with no knowledge of the issue, it will take more time to even adapt to the conceptual framework 10:32
and this is a difference of perspective that is pretty hard to even detect in my opinion. To me, the description seemed complete because I was coming from the assumption that somebody has their mind set up to storing hashes (and especially object hashes) 10:34
Xliff I was thinking about this, while reading the backscroll. 10:35
It might be better if the RSC starts writing guidelines for things like: what to put into a PR, how to write commit messages, how to handle bug reports, etc. 10:36
And then include examples.
This way a user could be guided to examples, and not individual responses that might chafe.
The next thing is that core devs need to learn to be patient. 10:37
If raku is to grow, then people need to not be chased away.
Nemokosch I'd say the CONTRIBUTING.md (I think it's called that) in Rakudo is, well, almost good enough. The general concept is good.
But you know, I absolutely don't like the dynamics of power here 10:38
That I work on an issue for several hours, make a PR and that gets thrown away with two clicks
Xliff The general concept is good, but there are.... gaps. Yes?
Nemokosch Then liz comes - who introduced this bug in the first place, ironically - and just downright adds a commit to the main brainch
Then liz comes - who introduced this bug in the first place, ironically - and just downright adds a commit to the main brainch 10:39
branch*
Xliff And on that note, I need to pass out so I can be up during regular work hours.
lizmat if you want to discuss the number of clicks it took to close the PR: that was one 10:41
Nemokosch It's not even about the "who can get their code into Rakudo" part, rather that I was ready and hoping to get feedback on basically my first core solution, also with heavy NQP involvement. I didn't anticipate that the solution would be immediately perfect, that I did not. But I thought this would be a good learning - and perhaps even social - experience in core development.
lizmat well, I did give feedback in the commit I did to fix the problem 10:42
Nemokosch And instead, the lesson I get to learn is that the same person who introduced the bug, also has a free hand to discard the solution and come up with another solution that might not be that good to avoid all reviewing anyway. 10:43
This seems like a power move
lizmat if you prove that my solution is worse in performance than yours, then I'll gladly revert my commit and merge yours 10:44
Nemokosch What about - I make a PR with exposing STORE_MAP the same way as STORE_AT_KEY is exposed, and add an implementation of that in the role? 10:45
lizmat and "the same person who introduced the bug": with almost 9000 commits in the Rakudo repo, there's bound to be bugs
I'll gladly merge such a PR *if* you can prove that it has no detrimental performance effects 10:46
Nemokosch - which I proposed partially with the intention to "have it tested", in case somebody fancies that approach for some reason
lizmat please note that all of the code in Map / Hash is very hot code, and jnthn and I and others have spent a *LOT* of time optimizing that 10:47
Nemokosch no, that's not up to me to prove. You granted yourself the upper hand for no particular reason. Unless you can reason that it would be significantly slower, it shouldn't be assumed to be such.
invoking STORE_MAP from a role, that is 10:48
lizmat ah, so it should be assumed that your solution *is* better because you melted your brain for 2 hours on it ?
no, it is up to *you* to prove that your solution doesn't hurt performance, especially in that section of Rakudo's code 10:49
Nemokosch there should be two (well, rather three) approaches competing on equal terms
you don't actually know how ANY of these approaches perform, just decided to prefer yours. This is not okay.
Geth rakudo/main: 06397eb715 | (Elizabeth Mattijsen)++ | CONTRIBUTING.md
TPF is TPRF now
 10:50
Nemokosch if we were treated on equal terms, we should be equally interested in doing those benchmarks - probably you'd still have more experience on how to do it at all 10:51
lizmat I *am* interested in benchmarks, I'm just not interested in doing them myself, as I believe this was the best solution based on my previous experience
prove me wrong, I'd say 10:52
Nemokosch I'm not asking for special treatment, mind you - I'm asking for the opposite.
You shouldn't have special treatment.
You made the point that my code has performance impact on key lookup - which I understood. I had an idea that would have leveraged that, one that only differs from your solution in that it doesn't add a method onto the base Hash but to the object hash that actually needs it. 10:54
Geth rakudo/main: c87544fad0 | (Elizabeth Mattijsen)++ | src/core.c/Hash.pm6
Revert "Fix for #5165"

This reverts commit 932df924f828c63aec187443ebcfa849e3c61c46.
roast: 0c45c3b728 | (Elizabeth Mattijsen)++ | S09-hashes/objecthash.t
Revert "Test for parameterised hashes as entries to store (#828)"

This reverts commit ba0314c18a06c6f198820375976d74c9d346c9a0.		 10:55
10:56 linkable6 left
lizmat go ahead, knock yourself out: the issue is open again, the commits have been reverted 10:56
looking forward to your approach and your explanation
Nemokosch Thank you very much - hopefully your commit can improve my own commit message so that nine can also understand 🙂 10:57
lizmat I've also unsubscribed me from the issue
I will not respond to it anymore
10:58 linkable6 joined
lizmat I think the term is: I've recused myself 10:58
lizmat goes back to implementing RakuAST features 10:59
Nemokosch Sorry, one more, can't hold it: another thing I witnessed with some of you is that you seem to think there is a competition of who is the biggest martyr. I don't think this is a healthy competition and I definitely don't try to "win it". And especially, people who are, bluntly put, less autistic than myself, are usually even less willing to keep making sacrifices until their sacrifice gets the biggest. 11:00
spectests running for the second attempt 11:52
nine Nemokosch, taking your message bout "biggest martyr", I wonder how you look at your own message from earlier: "<Nemokosch> That's a sure way to lose any interest from possible contributors..."
Nemokosch as a note that most people won't want to enter the "martyr competition", I'd say 11:53
as long as we can agree that it was not a nice thing from a neutral point of view
nine I'm just catching up with this again. One thing I would like to point out is, that your expectation of being treated equally to lizmat is _both_ correct and unrealistic. Let me elaborate:
Nemokosch btw I realized that I needed to do similar dispatching to my original version anyway - HOWEVER, it won't be in a loop this time 11:54
nine Yes, we did at some point decide that all contributions should go through the Pull Request process, even if they come from long time core contributors. The reasons are not just quality assurance, but because by reviewing one also learns, so PRs are a way to spread know how. 11:55
In that regard, yes, lizmat should also just have opened a "competing" PR. However, reality is, that we have few people who actually review. Having every PR open for a week just to merge it then anyway can be jarring (speaking from my own experience, trying to follow that process).
So I can very much understand lizmat just charging ahead. 11:56
But yes, in principle, the same process should apply to everyone.
The reason why I think it totally unrealistic to expect your contributions to be treated the same as lizmat's is really that: she has 9000 commits on Rakudo and more than a decade of experience (IIRC). She has done tons and tons of optimization work, so she'll have a well trained gut to tell whether something's going to be faster or not. So in doubt, I just go with her opinion, even if she didn't provide 11:57
benchmarks.
That said, I also sometimes disagree, and I think it was just yesterday that she reverted one of her commits because of that. No harm done. Happens all the time. 11:58
You are a new contributor to Rakudo core and don't have that experience yet. Is it surprising that we want to look closer at your PRs? 11:59
lizmat fwiw, I've been proven to be wrong on some occasions wrt benchmarks, so I'll accept PRs that prove that I was wrong, and adjust my knowledge accordingly
Nemokosch Closer look at PRs: No, absolutely not, actually that's what I anticipated.
lizmat I just don't want to be spending time on something I believe to be the fastest way
12:00 reportable6 left
lizmat In layman's terms: I don't want to mathematically prove that 1 + 1 = 2 12:00
yet, if you can prove that I was wrong, I will accept your proof
Nemokosch And also I don't have false expectations that there were a team of professionals only waiting to give essays of feedback on every PR
nine You phrased lizmat's direct commit to main as a power move. That's certainly a valid way to look at it. I'd like to suggest a different way: it's based on trust. We as core development team trust lizmat based on her mountain of contributions and the long experience with her that her commits are sane, well founded and that if they turn out to be wrong after all, they will just get reverted without any fuzz. 12:02
Nemokosch so far the patched-up version seems to work, you'll get to see it soon. I cannot estimate how "hardcoding a dispatch" as an NQP check is faster than actually doing one dispatch but I'd expect the difference to be not worth micro-optimizing
12:02 reportable6 joined
. s/how/how much/ 12:02
- unlike the original version, which indeed did one extra dispatch inside a loop 12:03
nine: also, please consider that you can convince me to look at it as an example of "forgiveness > permission" and similar concepts, but again, if somebody didn't get deeply involved with the community structure (which is possible at least, imo), they could just take their, otherwise reasonable, assumption and turn away 12:10
I also didn't mean to imply that lizmat makes bad code by pointing out that she introduced the bug during an optimization - rather that really everybody can make mistakes, no matter the trust, and as a sidenote, that optimizations are always touchy 12:12
lizmat I am not my code 12:13
which means, that if the code is buggy, it's the code that is buggy, and not me
nine Nemokosch, these ^^^ are words to live by :) And that's a really well meant life advice
lizmat if someone points out that the code that I wrote has a bug, then that's it: the code has a bug and needs to be fixed 12:14
Nemokosch I don't think I even implied that anybody is their code
I said that all people can make mistakes, no matter the trust, and therefore optimally it should always be reviewed
nine You did not say that. But honestly, you behaved like that. You treated your PR getting blocked by questions or sidelined by lizmat's commit like a personal attack.
lizmat en.wiktionary.org/wiki/kill_one%27s_darlings # in any creative process, one must be ready to kill one's darlings 12:15
Nemokosch No, definitely not "personal". And instead of "attack", I would rather say "mistreatment" 12:16
nine I hope if you re-read the whole discussion, you can see that. As I see that we can and should do better when new people try to join the core team.
However you phrase it, you felt bad, didn't you?
Nemokosch I never assumed anything was directly at ME, rather than a newcomer contributor in general
that I didn't just assume but I think said quite clear 12:17
And I do think it was my personal "bulldog mentality" that kept the "newcomer contributor" from just turning away, after seeing how the PR turned out 12:19
12:19 sena_kun joined
nine In my experiences, discussions like this one are easier when one sticks to personal examples, instead of generalizations. I.e. it totally suffices if you say that for example you personally felt badly treated. That's a good enough reason to take a look at the situation. No need to bring in unnamed hypothetical newcomer contributors. We have one right here :) 12:21
Nemokosch Yes, I did feel bad - but I don't think I have social credits left for that, it doesn't seem like that 12:22
and I don't want to make it a "me thing", that seems like a misjudgement of the situation
by the way, I'm back to the commit message again... okay, so let's see... add a code example with how it used to work and how it works now 12:24
do you have anything else in mind? ^^
nine That doesn't make sense to me :) One the one hand you're complaining about uneuqal treatment and on the other hand you discount your own worth in this. Just....don't. Every individual counts. So in my book it doesn't matter if your case could be generalized or not. 12:25
12:25 ab5tract left
nine Bottomline is, I have pointed out something, you can learn from this. And I am thinking about what we as a group can learn as well. 12:25
A code example might just be enough. Like I said, what is the result before and what is it now and why was before wrong and now right? 12:26
You know how obnoxious children can be, asking why? why? why? all over? Basically a commit message should be able to survive this. Because that's all you are ever going to want to know. Like yesterday, when you asked _why_ roles are actually Cool 12:29
Nemokosch by the way, I still don't know that... the commit message wasn't descriptive enough p
😛
nine Exactly! And I have had that problem just too many times. That's why I care so much about it. 12:31
Nemokosch And you know, it would be a whole different story why my personal reputation is the way it is; anyway, you probably know that I even got a suspension around september. I'm also trying to find the suitable attitude, both here and in various other communities, and kinda harmonize the values in personal relations... 12:33
anyway, this is one reason why I don't want to ponder a lot on something that is clearly directed to my personality, and rather focus on things that seem systemic 12:34
12:37 nine left, nine joined
one more: should the commit name should rather be the technical change or the motive of the change? 12:39
nine I'd go after the motive, so "fix foo" rather than "change bar implementation". Because commit messages are e.g. used to populate changelogs and readers of changelogs are interested in what changes they can see instead of what we did internally. 12:49
Nemokosch gotcha 👍 12:53
Xliff Et all: The only way someone is going to learn what a good commit message is, is 1) experience, 2) patience and 3) all of the above. 13:09
Nemokosch is seeking 1
2 was seriously lacking.
There is a #4 and that is "a bit of handholding" but most core devs don't have the patience for it, so we need mid-level people who do. 13:11
So what might be needed is a bit of a mentoring process when someone has the time to figure one out. 13:12
That is the end of my input. Thanks for listening.
lizmat Xliff++ 13:13
Geth rakudo: 2colours++ created pull request #5172:
Fix storing of typed Hashes from a list
lizmat nine++ 642 / 1355
Xliff Thanks, lizmat.
Nemokosch second round, and then it still appeared to me that STORE_MAP could be downright a multi 13:16
lizmat by using map as the invocant, you've basically done that without making a multi 13:17
afk for a few hours&
Nemokosch yes, I kind of went with this double dispatch of Java-like languages 13:21
lack of confidence in how multi's work in this environment 13:22
13:32 ab5tract joined 13:44 NemokoschKiwi joined 13:45 NemokoschKiwi left 15:05 sena_kun left 15:41 sena_kun joined
lizmat nine: does this ring a bell? 16:13
Capture argument is not an object argument for captureposarg. Got 8 instead
trying to make a Block for the POST phaser
nine no 16:14
lizmat ok thanks 16:15
works fine in a separate script, so it's some kind of bootstrapping issue :-( 16:24
16:29 tonyo joined 16:41 Xliff left
tonyo is rakuast_wip the main rakuast branch? 16:46
lizmat nope, rakuast now lives in main
tonyo beautiful 16:47
lizmat only a "use experimental :rakuast" away
nine: the call to the POST phaser appears to be a: nqp::p6capturelexwhere($phaser.clone)($value);
src/Perl6/bootstrap.c/BOOTSTRAP.nqp line 4132 16:48
looks like the error comes from the bowels of MoarVM 17:09
src/6model/reprs/MVMCapture.c line 209 17:10
Geth rakudo/main: 39acef1e11 | (Stefan Seifert)++ | 4 files
RakuAST: fix several places where a RakuAST::Name is not visited

All nodes must be visited by visit-children.		 17:11
rakudo/main: 2cb6fe37a5 | (Stefan Seifert)++ | src/Raku/ast/name.rakumod
RakuAST: visit expressions that are part of a name

Expressions can contain arbitrary RakuAST nodes which may need e.g. BEGIN time processing, so we have to visit them.
Nemokosch quick question: what PseudoStash is the bare :: referring to? does it have a name? 17:23
seems like it is MY:: ? 17:25
nine That stuff confuses me all the time 17:33
Nemokosch no surprise, haha. Trying to live off vrurg's big 2021 workshop for the time being 17:43
Geth rakudo/main: 6846bc1b69 | (Stefan Seifert)++ | src/Raku/ast/circumfix.rakumod
RakuAST: improve canonicalization of ArrayComposer colonpairs

Custom operator lookup relies on the name to be canonicalized before looking up. Thus infix:['<=»'] needs to become infix:<\<=»> We already did this right for normal colonpairs, but array composers still canonicalized to square brackets containing string literals.
I'm not sure if doing this for array composers containing a single statement is enough, but it gets 03-cmp-ok.t passing.		 17:51
nine 110 / 641 :) 17:52
18:00 reportable6 left 18:02 reportable6 joined
[Tux] Rakudo v2022.12-1-gd52342eb0 (v6.d) on MoarVM 2022.12-15-g6b456a6c0
csv-ip5xs0.824 - 0.836
csv-ip5xs-205.544 - 5.607
csv-parser4.034 - 4.112
csv-test-xs-200.413 - 0.414
test6.410 - 6.635
test-t1.404 - 1.464
test-t --race0.892 - 0.953
test-t-2020.908 - 21.058
test-t-20 --race6.537 - 6.553
 18:28
lizmat nine: got one failing test just now: t/spec/S06-signature/unspecified.t 19:04
# 13 19:05
# expected: ':(*@_, *%_)'
# got: ':(*%_, *@_)'
feels like a hash order dependency somehow 19:06
fails about 50% of the time
Nemokosch RAKUDO_RAKUAST=1 raku used to work for running the REPL with the new frontend, any idea why that would fail now? 19:08
fail as in, it gives the prompt back without any output 19:09
lizmat interesting no idea why that would just drop out
Nemokosch can you reproduce or is it on my end? 19:16
lizmat I can reproduce it
Nemokosch that's relieving and painful at the same time 😅 19:21
lizmat well, there's still plenty not working with RAKUDO_RAKUAST=1
are you sure it used to work ? 19:22
Nemokosch yes, I did use it 19:23
it was quite convenient for checking the state of working features 19:24
lizmat and you're sure you spelled the env variable correctly?
because I've been there mistyping it and not noticing RakuAST grammar wasn't activated
Nemokosch yes, first I did almost the same. But the behavior gave it away. I got a REPL where I could type my &foo and get, not even sure, (Mu) or (Any) back 19:25
I wanted to see if it got fixed within the last month, before getting up-to-date with the issue itself, and the REPL didn't start 19:26
if I run the code with -e, it turns out that it still persists
of course I don't know if it worked knowingly/intentionally but there was a time when it definitely seemed to work, roughly a month ago 19:27
for the PR: can't promise that I will do it today, got a bit carried away from work 😅 19:31
lizmat sure, no problem :-) 19:32
Nemokosch so if I won't be resting, I will be probably catching up with work
lizmat nine: so I have the POST phaser ready except for 1 thing: not being able to send a string as a named arg to the exception 20:01
built with StrLiteral.new, it winds up being a BOOTStr, and that bites the named arg handlng of X::Phaser::PrePost.new
causing an exception to be thrown after the original exception thrw 20:02
now, one solution would be to split X::Phaser::PrePost into a X::Phaser::PRE and an X::Phaser::POST
changes are pretty simple, but it would require a number of changes in roast 20:03
ah, meh, X::Phaser::PrePost is also documented... 20:04
ok, I guess the question becomes: how can a send a :phaser<POST> from ast land
without it producing a BOOTStr
I've already tried nqp::hllize 20:05
vrurg linkable6: nqp::box_s? 20:41
lizmat: it was to you, bad completion. :)
nine nqp::hllizefor?
lizmat box_s needs the Str type
lizmat tries 20:43
that did the trick *phew* 20:50
Geth rakudo/main: c8eeb94112 | (Elizabeth Mattijsen)++ | 6 files
Add complete support for POST phasers

  - Grammar / Actions added
  - RakuAST::StatementPrefix::Phaser::Pre classes added
  - Deparsing added
  - Tests added
... (5 more lines)		 21:12
lizmat now at 110 / 641 for me
so no change :-(
21:13 melezhik joined
nine One thing I noticed is that the hardest and seemingly most fundamental fixes never gain you any new tests. Then you implement something trivial and 5 more succeed 21:19
Geth rakudo/main: 7702e6b7d1 | (Elizabeth Mattijsen)++ | src/Raku/ast/code.rakumod
PRE phasers should run before FIRST / ENTER
 21:32
lizmat that gains us t/spec/S04-phasers/pre-post.t 21:33
and that concludes my hacking for today
21:37 melezhik left 21:45 melezhik joined 21:54 melezhik left 21:57 melezhik joined 21:59 melezhik_ joined, melezhik left 22:04 melezhik_ left 22:44 ab5tract left 22:48 ab5tract joined 22:54 squashable6 left 22:57 squashable6 joined 23:09 sena_kun left 23:20 ab5tract left

Powered by Cro and the Raku® Programming Language.

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

Thank you!