[00:30] <ShimmerFairy> I just found a really bad problem with codepoint integer property retrieval, namely that U+FFFE and U+FFFF ultimately return values of 0 unconditionally (except for something to do with general categories). This is why the new U+FFFE collation behavior breaks, since we implement simple weights as properties, but you can see the issue more simply today.

[00:30] <ShimmerFairy> m: say "\xFFFE".uniprop("Age") # This should be "1.1"

[00:30] <camelia> rakudo-moar e17a1d43b: OUTPUT: «Unassigned␤»

[00:32] <ShimmerFairy> I'm pretty much done with the upgrade work (which I can share if it's not too close to release to merge in, or if people just want the branches in general), but I've been poking at the collation stuff in particular as a next thing to fix, and I keep finding curious things in the code.

[01:19] *** kjp left
[01:23] <[Coke]> it's too close. :)

[01:23] *** kjp joined
[01:23] <[Coke]> thank you and we can merge it in right after the release.

[02:24] <ShimmerFairy> I had a feeling the timing was a bit tight, which is why I was spending time looking at other Unicode stuff instead of pushing branches. That's fine though, it'd be nice to spend the next month trying to clean up the annoying faults I'd otherwise have to paper over.

[03:13] *** vrurg_ left
[03:24] <[Coke]>  

[10:13] *** sugarbeet left
[10:13] *** sugarbeet joined
[17:07] <Geth> ¦ MoarVM: ugexe++ created pull request #2047: Fix shared coverage slot for same line BBs

[17:07] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/2047

[17:41] <disbot> <_.mu._> Is it a known and/or accepted issue that MoarVM's background spesh can cause nondeterministic memory usage and runtime -- e.g., identical input producing multi-GB differences in peak/retained RSS between runs?

[17:43] <lizmat> pretty sure it's known, because spesh runs in its own thread and is thus dependent on whatever the OS can give it in resources

[17:44] <lizmat> which means that optimizations may kick in at different times, or not at all

[17:44] <lizmat> but multi-GB differences in peak/retained RSS between runs feels like a lot

[18:08] <Geth> ¦ MoarVM/main: 6e2ce2f373 | (Nick Logan)++ (committed using GitHub Web editor) | src/instrument/line_coverage.c

[18:08] <Geth> ¦ MoarVM/main: Fix shared coverage slot for same line BBs (#2047)

[18:08] <Geth> ¦ MoarVM/main: 

[18:08] <Geth> ¦ MoarVM/main: The comment says consecutive BBs on the same line should share one slot, but they were getting the next line's slot. That line then never got reported.

[18:08] <Geth> ¦ MoarVM/main: review: https://github.com/MoarVM/MoarVM/commit/6e2ce2f373

[20:18] <disbot> <_.mu._> My codebase is somewhat    … pathological.    There are 2 or 3 observations, and I shouldn't have started with nondeterminism. More important is this:

[20:18] <disbot> <_.mu._> Memory footprint and time measured processing a    29k token input for different values for MVM_SPESH_LIMIT:

[20:18] <disbot> <_.mu._> LIMIT         peak RSS       wall                                                   100           0.6    GB         20s                                                   500           0.6 GB        20s                                                        1000          0.6 GB        20s                                                        2000          3.7    GB         61s                                                    

[20:18] <disbot> 5000          4.7    GB         84s unlimited   4.75 GB     84s

[20:19] <disbot> <_.mu._> So memory blows    up at a    certain    point, and my question is if this solely is a property of my codebase or if there also is a MoarVM issue. My interpretation    is that    the number of possible specializations is exhausted somewhere    below 5000.

[20:19] <disbot> <_.mu._> So to rephrase my question: Is it expected that    you have to find the sweet spot    yourself (1000 in my case), and    that specializations accumulate memory with no eviction and no admission-cost/benefit control, so the VM can install dead weight that costs memory and time while earning nothing?