| Geth | rakudo/main: 23b853957b | (Nick Logan)++ (committed using GitHub Web editor) | 4 files RakuAST: do not import EXPORTHOW from a loaded unit's GLOBALish (#6538) A unit that declares a my scoped EXPORTHOW also carries an EXPORTHOW entry in its GLOBALish aliasing the setting's own EXPORTHOW module. Previously loading such a unit imported that entry as a generated lexical alongside the rest of the GLOBALish. A later my scoped EXPORTHOW declaration in the loading unit then merged into that ... (11 more lines) |
01:22 | |
| rakudo: ugexe++ created pull request #6541: RakuAST: let a begin-time indirect lookup see the unit's lexicals |
01:34 | ||
| ugexe | 6541 fixes SBOM:::Raku | ||
| [Coke] | ah, nice. | 02:23 | |
| Geth | rakudo/23b853957-but-rakuast: ca335b6376 | (Will Coleda)++ | src/main.nqp Change default to AST, add RAKUDO_LEGACY |
02:33 | |
| rakudo: ugexe++ created pull request #6542: Make the 6.e sprintf produce C compatible output |
03:54 | ||
| rakudo: ugexe++ created pull request #6543: Port two missed fixes to the 6.e Grammar |
04:08 | ||
|
04:46
vrurg joined
04:48
vrurg_ left
07:20
rnddim left
07:21
ShimmerFairy joined
08:08
kurahaupo joined
|
|||
| Geth | rakudo/main: 26c5e6ca8a | (Nick Logan)++ | 2 files Port the Grammar.parse sanity check to the 6.e Grammar Previously a rule returning something other than a Match failed on the first Match operation applied to the return value, giving under 6.e a binding error that names neither the rule nor the value. The 6.c Grammar gained a check for this in 92ead2bdff, but the 6.e Grammar reimplements parse and never received it. A non-Match return now dies naming the rule, its return value and its type, as it does outside 6.e. |
09:46 | |
| rakudo/main: 515fbfe987 | (Nick Logan)++ | 2 files Complete the Mu actions port in the 6.e Grammar Specifying Mu as the actions means: no actions. The commit that introduced this, be9b0742ee, updated the method bodies of both the 6.c and the 6.e Grammar, but only gave the 6.c subparse the Mu type on its actions parameter. Previously subparse under 6.e therefore rejected an explicit Mu in the signature binding that its own body is ready to handle. The 6.e subparse now accepts Mu, as parse already does. |
|||
| rakudo/main: 55124f43ec | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files Merge pull request #6543 from ugexe/ugexe/grammar-6e-parse-fixes Port two missed fixes to the 6.e Grammar |
|||
|
10:22
finanalyst joined
12:41
SmokeMachine left
12:43
summerisle left,
ugexe left,
summerisle joined
12:56
SmokeMachine joined
12:57
ugexe joined
|
|||
| [Coke] | ugexe: did another blin ast run, 1702 out of 2505 modules processed (67.94%) before OOM this time, after 3 hours. | 13:22 | |
| Will upload the results... | 13:23 | ||
| pushed. | 13:26 | ||
| I need to have a better pointer on memory issues. :| | |||
| ugexe | a lot of stuff like "No candidates found matching identity: AVL-Tree" | 13:50 | |
| the first 5 results are like that again | |||
| i wonder if Blin is launching like 6 instances of zef at once and there is some sort of ecosystem index file race | 14:08 | ||
| [Coke] | I believe it's downloading the indexes from each eco at the top of the run, then using that for the rest for the run | 14:15 | |
| (one at a time at the top) | |||
| AVL-Tree has no deps, fwiw | 14:38 | ||
| ugexe | i dont think its related to deps | 14:41 | |
| github.com/coke/raku-ast-blin-resu...er_0.0.2_0 | |||
| the module in question isn't being found for the first 5 results. which happened during your last run as well | 14:42 | ||
| and its not exactly the same modules as last time | |||
| but if its downloading the indexes up front and reusing those then yeah that wouldnt be the cause | 14:43 | ||
| anyways regarding the blin run... i think most of what can be fixed in rakudo has been at this point (save a few stragglers I have have overlooked). the remaining failures either require module updates (mostly things using $*W), require moarvm fixes, or use stuff we aren't supporting in 6.e (p5 regex, macros) | 15:43 | ||
| if anyone notices a failure that they don't think falls into one of those categories feel free to point it out | 15:44 | ||
|
15:46
finanalyst_ joined
|
|||
| ugexe | the blin runs are still useful though since it will still catch regressions introduced by rakuast commits | 15:47 | |
| Geth | rakudo/main: 7952a69f30 | (Nick Logan)++ (committed using GitHub Web editor) | 14 files RakuAST: let a begin-time indirect lookup see the unit's lexicals (#6541) An indirect lookup performs its lookup when the expression evaluates, through a pseudo-stash that walks contexts rather than reading a name the compiler resolved. Code the compiler runs at BEGIN time lives in a frame whose outer is wired to the setting, so that walk reached setting symbols and nothing the unit being compiled declares. A unit-local name ... (53 more lines) |
15:53 | |
| [Coke] | oh. I'm using "MemoryMax" which triggers the OOM killer. there is a "MemoryHigh" which instead heavily throttles things when that limit is hit. | 16:41 | |
| let me try that. | 16:42 | ||
| timo | is the blin process itself being killed, rather than the processes belonging to the test? having one `systemd-run` per tested thing can help with that, you may have to turn some options from the memory accounting feature set on for that invocation, but then you can have the oom killer kill that entire cgroup and leave the other one alone. you may also have to tell the thing that runs blin to not | 16:45 | |
| stop when anything inside of it gets killed by the oom killer, if it's in like a service or so | |||
| [Coke] | right, your initial setup got me to run blin in a cgroup, and every thing it execs is in that group, so the OOM killer is reporting blin was killed. | 16:48 | |
| timo | ah, yes. a cgroup will by default act as a "unit of kill" | 16:49 | |
| [Coke] | I think yes, I have to be much more "in" on systemd and use it on each invocation so I can track what died individually. We'll see if using MemoryHigh instead (setting to 96% instead of a # of G) helps | ||
| (we're already "only works on linux" with blin, trying not to make it "only works on ubuntu", but honestly, no one else is running it so that's probably fine) | 16:51 | ||
| timo | you can try what its effect will be by setting it to a very low amount and seeing what it does | ||
| it could be that the throttling effect will just make stuff run extremely slow and take forever and perhaps eventually get killed after all if something is actually blowing past what's reasonable in terms of memory usage | 16:53 | ||
| [Coke] | well, it does make it run very slow, that's for sure. | 16:56 | |
| nothing dead yet | |||
|
17:21
finanalyst left,
finanalyst_ left
|
|||
| coleman | how many disks does your new mini PC have, coke | 17:30 | |
| tellable6 | 2026-08-03T12:46:22Z #raku-dev <finanalyst> coleman The docs.raku.org actions seem to have stalled on June 3. The docs site 'about' shows last rendering was June 3 | ||
| [Coke] | disk? | 17:50 | |
| 1 | |||
| I have it split between windows and ubuntu. | |||
| lizmat | m: say .name for Match.^roles[0] # apparently NQP knowhow's don't have find_method, wonder if this is a dispatch issue | ||
| camelia | Cannot find method 'find_method' on object of type NQPParametricRoleHOW in block <unit> at <tmp> line 1 |
||
| [Coke] | have about 576G on ubuntu | ||
| timo: with it set very low, OOM killer eventually ran after 62 out of 2505 modules processed (2.47%) | 17:51 | ||
| Geth | rakudo: ugexe++ created pull request #6544: Deliver spawn failures to the merged output supply |
19:26 | |
| [Coke] | whelp, that didn't help. got to ⏳ 1727 out of 2505 modules processed (68.94%) with an oom-kill | 19:37 | |
| timo | right, that's what I was afraid of | ||
| just asking the process to slow down when it's nearing the memory limit won't necessarily reduce the memory usage | 19:38 | ||
| [Coke] | running it with the low limit didn't really help because I'm sure there are some tests that rightfully take more than a few G to run. | ||
| timo | and blin is still in the same invocation as the tests that run, right? that's probably the most important next step to put them in separate memory accounting groups or whatever it's called | 19:40 | |
| Geth | Blin: coke++ created pull request #51: Coke/cleanup |
19:43 | |
| Blin/master: 25 commits pushed by (Will Coleda)++ review: github.com/Raku/Blin/compare/89417...405a69bb70 |
19:44 | ||
| [Coke] | ... I just renamed master to main... and now it's saying the primary branch is coke/json-class. :(] | 19:46 | |
| ... but you can't say "no, main is the default", you can only say "rename coke/json-class to main". (*&#$ github | 19:47 | ||
| ah, slightly hidden option in settings. | 19:48 | ||
| blin is now on main | |||
| timo | thanks to the main tainer ;) | 19:49 | |
| [Coke] | timo: if I put each thing in it's own group, that's not going to work either, is it? if I have 32 tests running, each with its own chunk of memory.. can they overlap? Or will I be stuck with 1/32nd of the memory for each run? | 19:51 | |
|
19:52
jdv joined
|
|||
| timo | there's a distinct setting that works more like a reservation, but the memory limit you're using here isn't like that | 19:54 | |
| and having the tests in their own group should prevent the blin runner from being taken down by the oom killer | |||
| [Coke] | so I want blin itself not in any group (it's well behaved), and then each copy of raku I run from it should be in a different group, so the different module tests don't kill each other | 20:02 | |
| yes? | |||
| timo | you can safely run blin in its own thing, or outside of any thing, I believe | ||
| Geth | rakudo/main: ed6913c556 | (Nick Logan)++ (committed using GitHub Web editor) | 3 files Deliver spawn failures to the merged output supply (#6544) Previously a Proc::Async with a tapped .Supply whose process could not be spawned crashed the thread pool with a null callback invocation instead of reporting the failure, and the same happened for a pty process without a tapped stdout. MoarVM reports a spawn failure once for each pipe it had created, under the stdout_bytes and stderr_bytes ... (11 more lines) |
20:13 | |
| lizmat | m: for IO.WHO.values { dd .WHO.values } # expected | 20:25 | |
| camelia | ().Seq (IO::Spec::Win32, IO::Spec::QNX, IO::Spec::Unix, IO::Spec::Cygwin).Seq ().Seq ().Seq ().Seq ().Seq (IO::Path::Cygwin, IO::Path::Spec, IO::Path::Win32, IO::Path::QNX, IO::Path::Unix, IO::Path::Parts).Seq (IO::Notification::Change,)… |
||
| lizmat | m: for Bool.WHO.values { dd .WHO.values } # WOT ? | ||
| camelia | (Bool::False, Bool::True).Seq (Bool::False, Bool::True).Seq |
||
| lizmat | heh,, seems like all enums have that | 20:27 | |
| m: for Order.WHO.values { dd .WHO.values } | |||
| camelia | (Order::More, Order::Same, Order::Less).Seq (Order::More, Order::Same, Order::Less).Seq (Order::More, Order::Same, Order::Less).Seq |
||
| lizmat | not sure whether that is expected or not... | 20:28 | |
| Geth | rakudo: ugexe++ created pull request #6545: Complete the merged output supply on its last stream EOF |
20:29 | |
| timo | m: dd Bool::True::False::True::False::False::True | 20:39 | |
| camelia | Bool::True | ||
| timo | they all share the same .WHO ... and how could they not? the WHO sits on the type, doesn't it? | ||
| Geth | Blin/coke/systemd: 3ef33cc67c | (Will Coleda)++ | lib/Blin/Processing.rakumod Run testing through systemd |
23:06 | |
| Blin/coke/systemd: 7ef96c7033 | (Will Coleda)++ | lib/Blin/Processing.rakumod Run testing through systemd |
23:17 | ||
| [Coke] | timo: ^^ That's (at least sort of) working | 23:21 | |
| hurm. worked for a small subset on an AST run, but not a normal one. weird. | 23:38 | ||
| ah, bet it's due to missing env. | 23:39 | ||
| Geth | rakudo: ugexe++ created pull request #6546: Report unhandled exceptions from threads like any other |
23:56 | |