🦋 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.
01:55 MasterDuke left 02:23 MasterDuke joined
ab5tract_ I get CI failures even when pushing RakuAST changes, which AFAIK shouldn't happen right? 09:05
Geth rakudo: ab5tract++ created pull request #5411:
RakuAST: Fix binding of $_ on smartmatch RHS		 10:27
lizmat in my experience the CI is not very useful, as it cries wolf too often :-( 10:34
I run make test / spectest 99.99% of the time before pushing
0.01% is when I thought I did the testing, and I didn't :-( 10:35
Geth rakudo/main: 5 commits pushed by ab5tract++ 10:49
rakudo/main: 9180ad7729 | (Elizabeth Mattijsen)++ | 11 files
RakuAST: add support for postcircumfix adverbs localization

  - added adverb-pc group in localizations
  - added support for adverb-pc in RakuAST::L10N
  - simplified hash generation: only add entries if key ne value
  - simplified method generation: identity return if no translated elements
  - did the NL translation		 11:02
11:04 Geth left, Geth joined
ugexe i think your view of CI might be skewed in some way. every business i've worked at uses it despite the fact that flappers existed 12:03
lizmat github.com/rakudo/rakudo/pull/5411 12:04
5 failing and 6 successful checks
ugexe so the JVM is broken again?? 12:09
yeah look slike the L10N commits broken JVM 12:10
kind of a point for CI there
there is only one flapper in that link, the profiler test on macOS. And yeah it sucks to have flappers but what I've seen done elsewhere is opening a ticket/issue about the flakey test so that someone can potentially fix/work around it in the future. And in the mean time just rerunning the test. However, most of those test failures are because the JVM build is no longer working. When those tests 12:12
failed arguably the commits should not be merged in
because now, indeed, the CI tests are mostly worthless because the longer we have that red X the more and more people think to just ignore CI tests because Thats Just How It Is 12:13
another alternative is we just get rid of the JVM backend since we can't seem to keep it working on the main ranch 12:17
Geth rakudo/main: 668913d976 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: remove "constant"

in an attempt to see whether that kills CI on the JVM backend		 12:20
ab5tract_ I'm not sure if the folks keeping the lights on the JVM backend are actually using it or just keeping it running 12:31
but it seems to me a few doors would open if we shut that door 12:34
jdv wasn't the original point of the jvm to make it so that its possible for multiple backends. that's not desired anymore? 12:36
lizmat actually, historically jnthn created the JVM backend to show that it was possible to have multiple backends 12:37
so initially it was Parrot and JVM
MoarVM was only started after the PoC of the JVM backend worked
ab5tract_ I sometimes wonder what a ground up fresh, Java 21 implementation would look like relative to the quite robust yet relatively quickly developed version that we have now. 12:38
lizmat it would probably look a lot better :-)
ab5tract_ Having multiple backends is great in theory, but in practice the JVM has always lagged in features and is seemingly forever on the edge of breakage either through bitrot or feature development 12:39
it's like how the JS backend is just sort of quietly not mentioned 12:40
not because its bad, but because its incomplete and the incomplete corners aren't immediately apparent
because one doesn't know what will or won't work, it's better to use moar. 12:41
lizmat ugexe: do you know why somme CI tests take over an hour? 12:42
ugexe which ones in particular? my hunch is raku is just slow on many systems 12:43
ab5tract_ the CI instances are probably quite low powered.. I've actually been marveling at how much of Rakudo was built under much _slower_ circumstances 12:45
ugexe if it is just taking a long time to start, that is because we are using up all our workers (a good thing - it means people are commiting code)
ab5tract_ slower interpreters, slower computers with fewer cores, relatively same spec suite
ugexe it might be possible to get more workers in that case
yeah the JVM backend used to be explicitly set to use 2G of ram. now (according to CI a few months ago) it takes 6G 12:46
ab5tract_ ouch 12:47
ugexe i dont know if that speaks to the amount of optimization to the non-jvm paths, or the amount of bit-rot to the jvm paths 12:48
ab5tract_ I know it's kind of rough but I think we should deprecate it and dream of a better JVM implementation
ugexe i think there is one benefit to having the JVM (and arguably the js) backends - it gives us 3 backends which is (to many) the minimum number of implementations of something you need to properly design interfaces for other yet-to-exist implementations 12:49
ab5tract_ Or, alternatively, go all in on a single implementation 12:50
but do we run our CI for JS?
ugexe no 12:51
we did have jvm, parrot, and moarvm all working at the same time at one point tho
ab5tract_ the momentum switched to moarvm pretty quickly once that came alive, though, and that has never really changed 12:52
lizmat well, that was pre-Christmas
as we dropped Parrot because of the GLR, and that was pre-Christmas 12:53
ugexe yeah, but its existence helped to design interface that lends itself to general backends 12:54
which, at least at one time, was a goal (multiple backends)
ab5tract_ well, the desire to get off of Parrot helped a fair amount in that too
ugexe its hard to just tack that on after the fact
ab5tract_ I think we close some important doors by always abstracting ourselves away from the implementation the way we do 12:55
ugexe yeah 12:56
ab5tract_ absolutely difficult to tack on after the fact, that's true. but I think it might be a point of humbleness on our part to scope down Rakudo to be a single implementation of Raku, if it were to gain us some sanity, some ease of development, and heaps of performance :) 13:00
we aren't exactly working with the same number of active contributors as we have in the past, like the Parrot or even JVM/MoarVM migration days. if the onboarding was easier (fewer moving parts and abstraction layers) maybe we could find ourselves with plenty more, but that's only a what if. 13:03
nemokosch well, it's safe to say that the JS backend is bad 13:14
by all means 13:15
ab5tract_ I don't have any experience with it, so I didn't want to comment on its quality
nemokosch this is based on user feedback from the time there were people who tried to use it. I suppose the problem is the same as for the "JVM backend", except magnified 13:17
these are rather runtimes implemented with a certain tech stack than runtimes that can interface with the given environment
loading dozens of megabytes to even start up because you gotta host the runtime itself in JS 13:20
given the current situation, I would seriously think about giving up on the abstract language standard, and consequently the dream of defining the language by Roast 13:25
the language is not implementable currently, and even if somebody speculated enough to come up with an allowed implementation, they'd have to face that most Raku code actually in use wouldn't work with it because of Rakudo-specific stuff all code out there is using 13:26
ugexe that problem has existed and corrected itself before when people wrote modules assuming it would be run on parrot 13:30
nemokosch well, now we are back to that problem on two levels: on MoarVM's level (how does C integration work with the JVM backend, for example?) and even more importantly, on Rakudo level 13:31
ugexe we even had testesr.p6c.org i think, which showed a testing matrix of all modules on various backends and os 13:32
nemokosch everything that uses the metamodel in a nontrivial way is straight in the trash bin with an independent implementation
lizmat so the question is really: is the metamodel part of Raku or not ? 13:33
nemokosch that's the most obvious question but answering that question alone wouldn't make the problem go away. A considerable amount of modules downright use NQP, and I wouldn't know by heart how much (pseudo)stashes and core-setting stuff is defined 13:34
the metamodel is just the elephant in the room 13:35
At the end of the day, one could try and knock the number of Rakudo-specific modules down but I think one can see that some modules will have to remain Rakudo-specific. Currently, I don't know any user-space solution to express that, other than some inspectional check in the code itself. 13:38
This is one of the problems that would immediately go away if Rakudo simply absorbed Raku
The severely unsufficient, potentially unsalvageable state of the Raku specification would be another one it could mitigate 13:40
ugexe it would be trivial to add some sort of dependency on Rakudo itself in a meta6.json
you can do a naive version of this already with rakudo:from<bin>, although that isn't completely sufficient for such a features final form 13:41
vrurg A problem of Rakudo-dependency in a module is totally pulled from the thin air. Until there is only one compiler no module can know if it's gonna be compatible with another one. "So, why bother?" – most devs would say then and do what's best for them. 13:42
nemokosch the technical part would be easy but one would have to move on to the next problem, namely that Rakudo has no particular release and support strategy
ugexe we will always have to move onto the next problem 13:43
nemokosch it's all just "we ain't gonna break anything* and just release when we feel like, duh", where the asterisk stands for "anything that matters" in the super vague form of Roast 13:44
vrurg: this is a legitimate observation but then there is no point to pretend that there "could be" another implementation 13:46
for all practical purposes, there couldn't
vrurg I see no way how the first part of your statement leads to the second one, false in all aspects. Anybody pretends? Or we just keep in mind that there _could be_ one? 13:47
ugexe i mean one day we had someone pop in here talking about implementing perl6 with something they called fanlang
nemokosch I mean, for all practical purposes, we don't "keep it in mind"
it's like we use two different meanings of "allowing" 13:48
vrurg Don't say "we" when it's you doing it. Can you tell the same for me? So, there is no "we".
And then this is why it's hard to dispute with you. 13:49
ugexe they had pretty much no involvement with the community at large other than popping in every once in awhile to mention fanlang
nemokosch do you notice that I quoted you? lol
> Anybody pretends? Or we just keep in mind that there could be one?
and this is why I say prejudices get in the way 13:50
doc.openresty.com/en/plus/fanlang/ there, fanlang 13:54
seems like a complete scam to be honest 🤣 13:55
ugexe its being used in production from what i remember 13:56
lizmat it smells a bit or RPerl 13:57
*of
nemokosch hm, according to anything else but this site? 😄
ugexe yes, i've never seen that site 13:58
nemokosch for "allowance", the way the possibility of other implementation is kept in mind is akin to allowing someone to swim through the Atlantic ocean
lizmat well, it takes a subset of an established programming language that is deemed too slow, and creates a pre-processor that transmogrifies source into another compiled language
RPerl -> C++ (if I remember correctly) 13:59
FanLang -> Lua
nemokosch huh, interesting
maybe this is not a scam then
anyway, frankly, there are so many interconnected problems with the relation of Rakudo and user code that I ended up beating a shadow. Of course, for a hypothetical implementation, the problem isn't that existing user code cannot indicate dependency on Rakudo releases. 14:06
The problem is that a huge amount of user code depends on Rakudo "accidentally", or due to lack of awareness
ugexe as i mentioned before we have had that problem before and it corrects itself once the proper signals are in place (i.e. they have feedback their code isn't working in some scenario) 14:07
nemokosch but it's a catch-22 situation: the situation in which their code wouldn't work, won't happen 14:09
it won't happen - partially - because of the mere amount of stutt that suddenly wouldn't work
stuff* 14:10
ugexe that didn't seem to matter to fanlang, or to the C# backend when that was a thing
so i think your assumption that it is a catch-22 may not be correct
nemokosch I don't know that situation so I cannot react to that but also can't just take at face value if you don't mind 14:11
There is no feasible way one could even detect whether certain code depends on Rakudo or not, this follows from the non-exhaustive nature of the spec 14:12
one cannot validate code against the Raku spec, all feedback for user code is essentially "works in Rakudo" 14:13
ugexe do you think feature detection is not feasible?
nemokosch I think it cannot be done in an extensive enough way. There will always be way too many false negatives. 14:15
ugexe There will? Always? 14:16
nemokosch You can check for things like using nqp or certain metamodel features but you cannot check for ad-hoc things like boolifying an infinite range
Something that didn't appear in the spec and Rakudo arguably had wrong 14:17
every time you stumble upon something like this, you essentially do depend on the compiler that promised to not break your code once you released it 14:18
I can't really think of a way to eliminate this sort of chaos, other than essentially making Rakudo the spec 14:20
ugexe i mean without thinking about it more than 60 seconds i can imagine something where the language defines individual features / behaviors (and probably sets of these things, like v6.X implies) 14:22
not defines, but declares that is has/supports 14:23
nemokosch so much like OG Perl?
ugexe the point is that it isn't impossible, which is what the language you're using seems to imply 14:24
nemokosch Well I can't see how that would solve the general problem that real code always exceeds the spec 14:25
lizmat well, it's a generic issue / feature
it's the IT equivalent of "Life will find a way" 14:26
nemokosch My point is that one thing letting Rakudo just absorb Raku would solve "for free" is the insecurity about the countless ways features can combine and what they should do, something that I do think is outright impossible to cover by mere test cases written in Raku 14:29
either because a good lot of the core could be converted into formal descriptions about the behavior, or alternatively a "blessed version" could be used as the oracle for validating code 14:30
to be clear, we don't have anything like that, we can just never say a module is according to the specs 14:31
at the moment, that is
Geth rakudo/main: d7cb307073 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add localization of postfix adverbs

  - add "set-key" method to ColonPairs
  - use that to translate keys for POSTFIX-EXPR		 14:35
rakudo/main: 6b598859cb | (Elizabeth Mattijsen)++ | 12 files
RakuAST: add support for postcircumfix adverbs localization

  - added adverb-rx group in localizations
  - added support for adverb-rx in RakuAST::L10N
  - simplified hash generation of deparsing: only add entries if key ne value
  - simplified deparsing method generation: identity if no translated elements
  - did the NL translation
lizmat oops, copypasto: add support for regex adverbs localization 14:36
nemokosch Natural Language translation
[Coke] (PRs trigger CI)+++++++++ 15:04
(rakudo absorb raku) There have been multiple non-rakudo implementations that covered a LOT of ground (in haskell, .NET, hypothetically the fanlang one). I would rather improve support in that area than throw it out. 15:09
[Coke] wonders if would be better to try to revive niecza than add .NET to nqp
ab5tract_ was it just me or did niecza went from preferred to second place to gone in very rapid succession? 15:11
s/went/go/
[Coke] it had one person working on it 15:12
ab5tract_ that's crazy impressive 15:13
nemokosch Well, there are several things. 15:17
First, those times ain't coming back
People expect stability, maturity, performance to be served when it comes to technology that has been out there for this long 15:19
It's really really hard to count on somebody showing up to dump a tremendous amount of work into Raku of all things, rather than doing something brand new or aiming for a well-established market 15:20
[Coke] and if they want stability, maturity, performance, there is currently an implementation to look at. That doesn't change the desire/need to have the spec separate from the implementation 15:21
nemokosch The point is that a language this old has consumers, not an upstream of volunteers 15:23
[Coke] how does that point help your argument that we should eliminate the difference between spec and implementation?
nemokosch By saying that your argument about historical implementations isn't relevant? 15:24
It was a reply
[Coke] The historical implementations are an example. They are not WHY we should keep the distinction 15:25
they are an example that it can be done, sure.
The fact that there are none now is also not a reason why we should eliminate the distinction. 15:26
nemokosch That situation was significantly different from the current one. It was much more about speculation than maintenance.
I wouldn't know for sure but I'm not convinced doing the same thing would seem like "working" nowadays, with much more code and promised stability 15:27
Right now, Rakudo itself often shapeshifts when user code is caught broken, imagine this with multiple contradictory implementations 15:28
Anyway, there is a given problem, and it's that the spec doesn't fulfill its purpose. That's neither the fault of Rakudo, nor the lack of other implementations. Performing a very finite number of tests written in Raku against a compiler is just not enough. 15:31
My point was that this is both an obstacle for new implementations that should be mitigated to even talk about the possibility 15:32
And that this could be addressed by giving up on the dream about other implementations and letting Rakudo become the spec
Which would still be a better spec than the current one
There can be other solutions, perhaps. But the topic happened to be letting go of theoretical flexibility. 15:34
16:17 discord-raku-bot left, unicodable6 left, discord-raku-bot joined 16:18 coverable6 left 16:19 sourceable6__ joined, sourceable6 left, benchable6 left, notable6 left, benchable6__ joined, notable6__ joined 16:20 unicodable6 joined 16:21 coverable6 joined, nebuchad` left 16:24 unicodable6 left, unicodable6 joined
ab5tract_ I don't find pointing people to a heap of necessarily golfed test cases in lieu of what one would normally expect when asking for a specification to be particularly friendly 16:28
Defining a Raku as anything that passes the spec suite still sounds reasonable to me, but I honestly think there is something on the wrong end of hubristic to hold back on the potential gains a singularization could make based on some eventual multiplicity of Raku implementations. 16:31
[Coke] A written spec that is carried out by the tests would be better than just the tests. 16:36
and both of those are better than "it's (just) rakudo"
ab5tract_ [Coke] agreed on all counts 16:39
I'd like all three to be true, I think 16:40
[Coke] Certainly we can be more strong about saying "and rakudo is currently the only implementation and has the best expectations for support and maintenance" or something 16:43
We would need a tech writer and access to the devs (with corresponding loss of dev time) to work on a written spec. I would suggest someone open a problem-solving ticket for that where maybe we can workshop an outline 16:44
ugexe just train an llm on the spec and have it write the spec 16:48
on the roast^
[Coke] not sure if you missed the /s tag there or not. :)
nemokosch I don't think the current situation is better than "it's (just) rakudo" - at the end of the day, this was probably the main point 16:54
it isn't just unfriendly (towards anybody who tries to validate some concept, including us) as it is now 16:56
it cannot be taken seriously, and please understand it as literally as possible
it doesn't actually define the language
compare this with the specification of just C
[Coke] And if we make it rakudo, we give up defining the language, and are instead defining a specific compiler.
Yes. to me, the takeaway of the current situation is to improve the spec, not to eliminate it. 16:57
nemokosch I don't think there is any amount of Raku tests that could specify the language
any language, really
[Coke] I didn't say "improve roast", but "the spec" 16:58
lizmat so what if we take the design notes, rip out anything not implemente, add the things implemented but not specced ?
[Coke] I think we can use that for ideas, but it's not going to be a simple lift and shift, I think. 16:59
jdv is there a real need for a written spec?
[Coke] We could use the old design notes to get the topics to cover, for sure. 17:00
nemokosch yes, there is
[Coke] jdv: as compared to ad hoc tests? yes. If we want to say the spec is separate, we should have an actual spec.
jdv iirc back in the day either jnthn and/or larry declared roast is the single source of truth on the matter
nemokosch every time something works in a strange way, which does happen quite regularly, we have no clue to even decide whether it's intended or a bug
the only choice to be made is ensuring Rakudo backwards compatibility, even though Rakudo should have no business in most user code 17:01
jdv but who concretely needs/wants this written spec?
nemokosch this is an interesting question
also, you named two people who basically aren't involved anymore
[Coke] Yes, I don't think aside from folks in this chat, outside users are asking for it. But I would argue that if we want to keep the distinction between rakudo & raku, having a written spec is going to be more useful than *just* roast. 17:02
so, language implementors (even rakudo), language designers (they can make the intent clear in prose rather than just text), and language users (what is this language supposed to do) 17:03
But it's a huge effort.
ab5tract_ yeah, no small feat 17:04
[Coke] Alternative option: Add pod blocks in each test file that accurately describe what is being tested. (this could be automatically consolidated into a single document) 17:06
ab5tract_ not sure which would take more time, to be honest
[Coke] Could start with the latter, could do it piecemeal, at least. 17:07
ab5tract_ true
[Coke] But I'd definitely want feedback from RSC on the idea.
jdv we definitely have plenty of resources for that:)
[Coke] jdv: yes, we have historically been understaffed for what we need to be doing 17:08
jdv i feel its worse now. there used to be more peeps around. 17:10
good times
nemokosch the current solution is basically nonexistent, it's not that "there is room for improvement" 17:11
at the moment, we are doing Raku = Rakudo, just don't admit it
[Coke] afk
nemokosch of course one can keep doing that but then really, what even is the point of talking about it
jdv "whatever works" maybe;) 17:12
ab5tract_ I think it's a bit of a contentious issue. I also think it would have been a more contentious discussion even a year or two ago. 17:17
I mean, on the one hand the whole focus on multiple backends has the feel of a YAGNI optimization. But on the flip side of that very coin, it proved very useful in the history of Rakudo to have done so. 17:18
bartolin Oh, wow, it looks like I triggered a big discussion. ugexe++ for raising the question if we should get rid of the JVM backend. Not necessarily, because I think that we should, but because I think it should be seriously considered. (Once or twice I even started to write something in that direction, but never sent it.) 17:19
I'd very much like to hear what jnthn thinks about that. He invested quite some time into the JVM backend -- also after Christmas, when MoarVM was already far ahead. 17:22
For the record: I don't use the JVM backend myself. I mostly tried to keep it alive, because I thought that having multiple backends would benefit Rakudo. 17:25
(of course I was not the only one who invested time to keep it alive.) 17:26
lizmat there was a time when I would run all spectests with Parrot and the JVM 17:27
before each commit
but there where a lot less spectests then
bartolin Regarding roast and the language specification: I seem to remember a presentation from pmichaud where he argued strongly for a specification in the form of tests. Maybe it was this one: archive.fosdem.org/2015/schedule/e...s_learned/ (And I could also mix something up here.) 17:30
jdv full spec run for me on a monster aws box is a 3/4 m8ns iirc
*mins
might be 2 now
nemokosch it seems to me that almost everything pmichaud has ever argued for turned out to be unmaintainable in the long run 17:33
Geth rakudo/main: bbb57adbca | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: add localization of regex adverbs
 17:35
nemokosch I'm curious about the video but it most certainly won't invalidate all the cases of "test needed" and ecosystem breakage
jdv pmichaud did a lot back in the day 17:36
nemokosch I don't doubt that
also, he genuinely seems like a humble and knowledgeable person 17:37
that's all the more awkward to see old discussions where he regularly made choices that have caused so much trouble in the long run... 17:38
bartolin nemokosch: I definitely don't share that view
I mean the "turned out to be unmaintainable".
nemokosch the stance against the concept of "official", the stance for things like the Cool class and values pretending to be single-element lists 17:39
to make it more concrete
The term "hubris" was pretty popular in this community, or at least what was the predecessor of the current community 17:47
ehh... I think we (as in, quite possibly all people) have a natural tendency to take someone's public content as authoritative or evidence supporting a claim. It's almost like "asking to ask" or XY questions 18:11
there is never any time (or any point) in taking up on all claims 18:12
however, let me say not sure anybody who recites a presentation like this one would agree to the implied statement that it can be a good idea to derive from classes like Int 18:19
And for "arguing in favor of the test suite" - the presentation itself happened before the language got released. For the first 7 years of "tests as the specification", it was absolutely a great argument that the specification changes often, it's hard to version, doesn't help the convergence of implementations etc. but that all stopped in less than a year from this presentation. The specification of a released 18:28
language won't and can't change often.
Geth rakudo: ab5tract++ created pull request #5412:
RakuAST: Fix $_ scoping issue with `.say for m:g//`		 18:52
18:54 Geth left, Geth joined
Geth rakudo/main: 80557f3aa4 | ab5tract++ (committed by Elizabeth Mattijsen) | src/Raku/ast/statement-mods.rakumod
RakuAST: Fix $_ scoping issue with `for m:g//`
 19:25
19:28 Geth left, Geth joined 19:30 tellable6 left, tellable6 joined
[Coke] (JVM) I was one of the people stumping for it to help with enterprise adoption at my work... where I no longer work. now .NET is (for me) a better draw. 20:19
I think having it be an aspirational item that at least doesn't break even if it doesn't gather more features is better than deleting it. 20:21
(If nothing else, it can serve as an example of how to add more backends to nqp, and we should at the very least save it in a branch if we don't want it in main0
Geth rakudo: ab5tract++ created pull request #5413:
RakuAST: Set mod topic temporarization correctly		 20:44
MasterDuke just some random thoughts re JVM backend. aiui, the JVM backend started out ahead of both MoarVM and Parrot in the multithreading/concurrency support and jnthn depended on it to prove out the design/implementation of those. also, probably the best way forward for the JVM backend would be to use Truffle/GraalVM, like TruffleRuby, et al. pmurias 20:52
started on that for NQP (and i contributed a tiny amount) but it still needs a large amount of work
[Coke] MasterDuke: do you want to write that up as a project description somewhere so people who have some java experience can take on parts? (raising my own hand here0 21:19
.seen sorear 21:20
tellable6 [Coke], I haven't seen sorear around, did you mean saraaa?
[Coke] so, just forked niecza, tried to build. First issue: github.com/downloads/sorear/niecza...cza-24.zip is missing 21:28
.seen colomon 21:29
tellable6 [Coke], gist.github.com/d25f200bae5c61e2be...45869d0273
[Coke] Hopefully someone somewhere has a copy of those. 21:30
afk
ugexe github.com/sorear/niecza/archive/r...gs/v24.zip 22:00
that downloads as niecza-24.zip
Geth rakudo/main: f45297d578 | ab5tract++ (committed by Elizabeth Mattijsen) | src/Raku/ast/statement-mods.rakumod
RakuAST: Set mod topic temporarization correctly

We actually only want to do this in the case that we have a QuotedRegex for an expression.		 22:12
[Coke] pokes half-heartedly at github.com/coke/niecza/tree/cleanup2023 22:23
Happy to give out access 22:44
23:18 buildable6 left 23:21 buildable6 joined
nemokosch Half-heartedly? 23:23
23:32 coleman left 23:33 coleman joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!