|
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 | |||
