00:17 [Coke] joined 00:42 ds7832 left 05:48 lizmat_ joined 05:52 coverable6__ joined 05:53 vrurg_ joined 05:56 nativecallable6_ joined, evalable6 left, notable6 left, bisectable6 left, shareable6 left, coverable6 left, greppable6 left, committable6 left, benchable6 left, tellable6 left, lizmat left, vrurg left, evalable6 joined, shareable6 joined, notable6 joined, benchable6 joined, committable6 joined, nativecallable6 left, tellable6 joined 05:58 bisectable6 joined 05:59 greppable6 joined 08:45 melezhik joined 09:13 lizmat_ left, lizmat joined
patrickb If in a Rakudo installation, the "share/perl6" folder is symlinked to the share/perl6 folder of some other Rakudo installation, which Rakudo should be used to run scripts that are installed in contained CURIs? 10:16
lizmat feels like a bad idea to do? 10:21
patrickb I.e. if the script tries to find it's rakudo executable, by looking for "../../../../bin/rakudo" relative to it's own dir (i.e. it tries to resolve /home/foo/inst/share/perl6/site/bin/../../../../bin/rakudo.exe), should it resolve symlinks or not?
I agree it's a bad idea, but we still have to decide how raki do should behave in that case.
Unsure if this could have security ramifications. 10:22
lizmat also, disk space wise, with a lot of precomp files hanging around? 10:23
patrickb I agree this is stupid. Still we need to define the behavior. But maybe this is pretty obvious. The OS already defines the semantics of .. in a path. Let's just follow that. 10:25
lizmat ugexe: given that raku.land/zef:lizmat/Slang::Nogil is at 1.0 11:33
and the previous version was at 0.09
m: say v1.0 cmp v0.09 # and give that 1.0 > 0.09 11:34
camelia More
lizmat why is it that "zef install Slang::Nogil" is trying to install the old one?
could it be that it has :api<1> ?
and the new one has no specific :api setting 11:35
timo github.com/rakudo/rakudo/pull/6005 i would love someone to just give this a quick look and hopefully merge 11:38
Geth rakudo/main: 5154f2a1cd | timo++ (committed using GitHub Web editor) | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Make CORE.c setting build reproducibly

The last thing missing was the array of capture names getting a different order depending on hash randomization, thus breaking reproducibility.		 11:46
timo neat, thanks ... whoever that was? :D 11:49
lizmat 11:50
timo i feel that the benefit to debian should be palpable 11:51
lizmat meh, t/spec/S17-promise/nonblocking-await.t just hung for me once 11:53
unrepeatable, so probably unrelated
timo: what about github.com/rakudo/rakudo/pull/5999 ? 11:55
timo that generator i wrote for trying to concurrently load stuff turned out to not be much of a stress test at all, it looked like it didn't manage to explode on main rakudo at all 11:56
i would like to brainstorm approaches to handling regexes that just infinitely loop 12:14
lizmat perhaps a thread that does own-up logic repeatedly and checks the stack traces ? 12:15
timo things i've thought of so far: we can compile quantifiers to code that would detect that since the previous iteration, the position of the cursor hasn't changed. we can emit code that runs a kind of check after 1000 iterations have been reached, there's many more options we can explore 12:35
firing up a thread that watches over regex execution sounds kind of wasteful, especially when we can essentially completely freely change how the code is compiled 12:49
lizmat well, your suggestions would create overhead for all regexes 12:52
whereas my idea would only create overhead when that thread is actually started, e.g. with a pragma 12:53
timo but then you have to know ahead of time if you're going to have the problem of infinitely matching nothing and getting stuck in a regex match
another thing i need to address is the question of "what if someone actually somehow relies on being able to keep the regex engine not progressing when doing an infinite quantifier" 12:57
the code i had looked at for stumbling upon this topic again was i think actually capturing instances of zero-width matches, so the problem was not simply getting stuck and doing nothing, it was actually creating more and more captures 13:00
we don't want to end up in a place where we say "actually, capturing infinite copies of the same zero characters long match is undefined behaviour, so we just skip over it in the optimizer" which is a thing that gives C and C++ programmers fun "wtf" moments every now and again when it's brought up 13:01
lizmat hmmm 13:02
timo we can statically determine when something can result in a zero-width match - easiest is when a construct like <?...> or <!...> is used, since they literally set "zerowidth" on the QRegex node
but if we have something like a role that expects to be applied to a grammar, we can't know enough at compile time to necessarily warn about that 13:03
Geth rakudo: patrickbkr++ created pull request #6025:
Normalize rakudo-home path
lizmat yeah, we don't want false positives
timo we can in theory warn at composition time, but that would imply another pass over everything whenever a mixin of roles into grammars happens 13:04
lizmat ouch, and that is slow enough already
timo that's a few of the reasons that brought me to the idea of putting a "has progress happened?" check into the compiled code we make from quantifiers
and choosing a high-but-not-too-high point at which we check if any progress has happened and doing something to prevent trouble. could be throwing an exception, could be returning a Failure from the match, could be continuing as if the quantifier had been exhausted 13:05
in a way, compiling `a*` as if it were really `a ** {0,100000}` is a (possibly poor) way to fix this 13:06
of course, if we choose a too-low value, we will give someone a very, very confusing misbehaviour when they match their regex against a rather long piece of input where it's legitimate to match a single * quantifier 100000 times in a row 13:07
lizmat is that counter a 32bit or 64bit one? 13:08
timo moarvm int register, so 64bit
64bit signed integer probably 13:09
also, do we want to be thorough in checking statically if there's a possibility that a piece of regex is capable of matching zero characters, and throw an error ahead of time? 13:12
ab5tract brought up the possibility of an adverb to control how all of this is handled 13:14
could be something that has the same effect as putting a `& .+?` next to the can-match-zero thing so that if it matches zero, it has to backtrack and try something else 13:16
lizmat ack 13:19
timo it seems like a simple thing to put in, but it shouldn't be default for everywhere, because there's absolutely many places where you want something to be able to match zero width. if we only make it the default for the thing that's quantified with a *, then it'll give people a surprise too, just a different kind of surprise from the infinite looping one 13:24
Geth rakudo: patrickbkr++ created pull request #6026:
Win MSI: Remove stale command
rakudo/main: 635279c8f9 | (Patrick Böker)++ | tools/build/binary-release/msi/build-msi.ps1
Win MSI: Remove stale command

Forgot to remove this during the last refactor		 13:25
rakudo/main: 5140c3c647 | (Patrick Böker)++ (committed using GitHub Web editor) | tools/build/binary-release/msi/build-msi.ps1
Merge pull request #6026 from patrickbkr/msi-stale-command-cleanup

Win MSI: Remove stale command
melezhik Another idea , for brownie usage - add unit tests for PR via dedicated zef module ( installed from git repo ) this would allow quickly test PRs idea 13:37
timo can you explain a bit more? 13:45
melezhik One sec 13:46
pasteboard.co/KATwJ4XFjoTb.png 13:47
source code checkbox checked means Rakudo commit is going to be compiled from source code 13:48
It works already
Anyone could pick a commit for respected PR and try it out - github.com/rakudo/rakudo/pulls 13:49
The second part is I imaging having a regular zef module with some unit tests covering cases for a PR 13:50
Such a Raku module could be pointed via module text input as a regular git repo as zef understands such a format 13:51
This allows quickly run PR unit tests against complied Rakudo 13:52
timo so you're suggesting this would be used when you make a change to rakudo that you expect will fix the tests in an existing module? 14:19
ab5tract Or to verify that a change doesn’t affect anything in the ecosystem 14:29
timo that would need a full blin run though right? 14:30
ab5tract Ah, I didn’t read carefully enough 14:34
melezhik The idea is to run only against a specific module with tests , however it’s possible to run against entire eco system or subset ( 2,10,100,200,1000,2000 modules) which is default 15:07
“5:19 PM <timo> so you're suggesting this would be used when you make a change to rakudo that you expect will fix the tests in an existing module?” Oh, this could be that too, did not think about that. ) 15:52
Or create a Raku module with some unit tests that prove PR will fix the issue 15:53
Geth rakudo/main: 3b80351fa6 | rir++ (committed using GitHub Web editor) | 2 files
Eliminate magic 37 in Instant class. Modify some comments

  * Eliminate magic 37 in Instant class. Modify some comments
  * Remove unused $offset-nanos declar
  * Calculate current UTC offset once in Instant class. Restore a comment		 17:04
ab5tract hrm, this is an interesting wrench -- ParametricRoleHOW.compose returns a ParametricRoleGroupHOW ?? 18:32
m: role R {}; role S does R {}; dd role T does S { }.HOW.compose(T).HOW
camelia Perl6::Metamodel::ParametricRoleGroupHOW.new
lizmat that's because mixin in a role in a role creates a new role ? 18:56
19:21 librasteve_ joined
librasteve_ rakudoweekly.blog/2025/11/17/2025-...lease-187/ 19:24
Geth setup-raku/dependabot/npm_and_yarn/js-yaml-3.14.2: 8fb72d01ce | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
Bump js-yaml from 3.14.1 to 3.14.2

Bumps [js-yaml](github.com/nodeca/js-yaml) from 3.14.1 to 3.14.2.
  - [Changelog](github.com/nodeca/js-yaml/blob/mas...NGELOG.md)
  - [Commits](github.com/nodeca/js-yaml/compare/......3.14.2)
  ---
... (7 more lines)		 19:59
setup-raku: dependabot[bot]++ created pull request #43:
Bump js-yaml from 3.14.1 to 3.14.2		 20:00
20:45 melezhik left
ab5tract lizmat: sure, but the compose method returns the (modified) type object that is passed in, I don't see $target being re-assigned 21:24
lizmat: also, the role is supposed to be composed already, at least from what the code suggests 21:25
21:31 librasteve_ left
ab5tract this behavior (ParametricRoleHOW.compose => ParametricRoleGroupHOW) is also not present when calling compose inside of RakuAST::Role :( 21:45
m: role R {}; role S does R {}; use nqp; dd nqp::istype(role T does S { }.HOW.compose(T).HOW, R); dd nqp::istype(role U does S {}, R); 21:57
camelia 0
0
ab5tract m: role R {}; role S does R {}; use nqp; dd nqp::istype(role T does S { }.HOW.compose(T), R); dd nqp::istype(role U does S {}, R);
camelia 1
0
Geth rakudo: patrickbkr++ created pull request #6027:
Another vararg test: passing `Int`s		 22:44
[Coke] jdv: can you take 2025.12 ? 23:46
releasable6: next 23:47
releasable6 [Coke], Release date for Rakudo 2025.11 is listed in “Planned future releases”, but it was already released.
[Coke], and I oop! Backtrace: gist.github.com/c6ac62b0c8a4222ec2...4585dc7a23

Powered by Cro and the Raku® Programming Language.

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

Thank you!