japhb ShimmerFairy: OK, finally got a free minute to take a look at your commit. It looks like I'll need to manually merge, but there's good stuff to pull in on both sides. 02:06
Out of curiosity, why did you rewrite the handling of emoji versions to use actual Version objects? Was that a preference, or a bugfix? 02:07
Oh, and side note: It's generally preferable to do a separate commit for the tool changes and the unicode DB changes. Not a big deal here, but nice in general. 02:08
ShimmerFairy japhb: The reason for the version objects is that the new location for that emoji data is inside the main Unicode dirs, which naturally use 17.0.0 versions. I know the emoji versions are sync'd with Unicode versions, but I don't know if it's safe to drop the last component from the Unicode version, so .Num no longer worked. 02:31
If that's really a thing to worry about, then all the other code touching emoji data should be modified to handle three-component versions too, but I only did it here where I had to write some code already. 02:32
japhb ShimmerFairy: Ah, OK, that makes sense. OK, will keep that in mind. 02:46
Unicode has been ... kinda weird about their versions. 02:47
They seem to try to standardize on how they are going to version things, and then a release or two later change it.
ShimmerFairy While the way they write the emoji versions (17.0) implies you can drop the third part, UTS#51 says "[...] the repertoire of emoji characters is synchronized with the Unicode Standard, and has the same version numbering system." which is vaguer than I'd like. 02:48
japhb Yeah, that changed a few times too.
ShimmerFairy At this moment, my gut says the safe approach is to consistently use three components, including attaching a harmless .0 to the pre-sync versions. 02:49
japhb And since you commented about it in your code: Apparently the reason for reading all of the emoji versions starting at a certain point is that some of the emoji names have been changed over time. In order to not break old Raku code, we need to recognize the names they all *used* to have.
So we go all Pokemon on the emoji DB 02:50
ShimmerFairy: Once we go to Version objects as you suggest, the internal logic of Version objects should make it all Just Work for us.
(WRT handling number of components changing, sorting, etc.) 02:51
It's like someone *designed* this concept! ;-P
ShimmerFairy I don't know offhand how magical Version objects are, but they seemed to work well enough for a simple three-number version scheme. 02:52
japhb nodnod 02:54
Geth MoarVM/main: 5 commits pushed by (Geoffrey Broadwell)++ 03:27
japhb ^^ First part of merge work, easy to salvage bits out of my WIP
ShimmerFairy Looks good, although the comment about "flat.dotted.case" stands out to me, because I generally understand Rakudo to be very strict on property names and the like, wasn't aware it had any aliasing at all. 03:42
japhb MoarVM (and thus Rakudo) recognizes a few particular alias types for Unicode property values. That added comment was just me commenting existing code to explain why it existed -- one of the things about working on these is that there wasn't much commented originally, which made it a morass of hard to understand not-quite-spaghetti. 03:57
So as I was working in those file, I added a lot of comments to each section before attempting to refactor it. 03:58
(I was *just* starting refactor of emit_unicode_property_value_keypairs when I got sidelined by other things.)
ShimmerFairy Yeah, it's obvious it's just an added explanation, I just couldn't help but notice since I've frequently been frustrated by things like /<:Whitespace>/ not working like they should. 04:02
In general I think Rakudo (at whatever level(s) relevant) should implement all the loose matching rules for character names and properties, but I don't know if that would be considered a language change. 04:03
japhb Second part of merge work pushed, combining both our ideas for UCD-download improvements 04:35
ShimmerFairy: Actually it looks like I can take your new derived_core_props sub ucd2c.pl wholesale. If you'd like git history credit for that, can you separate that out into its own patch and I'll merge just that bit before continuing? 04:48
ShimmerFairy I can go ahead and do that, it should only take a few minutes. 04:49
Geth MoarVM: ShimmerFairy++ created pull request #1974:
Update ucd2c.pl for Unicode 17		 05:01
ShimmerFairy japhb: there you go, figured putting it in pull request form would be the simplest way to hand over a git commit. (Also gave me the chance to fix a typo in an error message I added.) 05:02
Geth MoarVM/main: d7b4fa16c3 | Faye++ | tools/ucd2c.pl
Update ucd2c.pl for Unicode 17

This involves two fixes: the first is that DerivedCoreProperties.txt now includes enumerated properties alongside binary properties, and thus handling for that had to be added. At present it just has hardcoded support for the new Indic_Conjunct_Break property, but it shouldn't be too hard to generalize if ever needed.
The second fix is simply to include support for a new CJK Ideograph Extension.		 06:24
MoarVM/main: 40f51a84ea | (Geoffrey Broadwell)++ (committed using GitHub Web editor) | tools/ucd2c.pl
Merge pull request #1974 from ShimmerFairy/derived-core-prop-fix

Part of merge of Unicode 17 update WIP bits from japhb and ShimmerFairy++
japhb OK, merged that one in too. 06:25
Do you want to pick it up the work from here?
ShimmerFairy Sure, I can try my hand at updating everything for Unicode 17. I might need help from others, since "update the graphemes" is certainly a choice for one's first time doing the update procedure, but I'll do what I can. 06:30
At the very least, I wouldn't want you to feel latent pressure to get back to working on it.
japhb Appreciated! 07:15
And that way I can get back to working on the Terminal::* modules. :-) 07:16
Speaking of which, if you're interested in terminal stuff, we hang out on #mugs.
(I wanted #raku-mugs, but apparently there's a namespace thing on Libera.Chat.)
ShimmerFairy No clue what any of that's for, but I'll keep it in mind (at the very least, I've got a fair chunk of ANSI escape codes memorized at this point, so chances are I'd be interested) 07:20
At this precise moment, by the way, I've decided to start by carefully reading the release notes for everything since 15.0, so I can get a sense of what's changed and might need looking into. I'll share the list I'm making for anyone else who's interested. 07:21
japhb Yes please! :-) 07:52
ShimmerFairy: We've got modules for SGR coding, terminal escape parsing, line editing, capabilities autodetection, terminal testing, TUI building, etc. 07:54
A few of us are slowly building a collection of the all the terminal handling tasks you might want. :-) 07:55
ShimmerFairy What captured my attention a little while back are all of the late-stage terminal features that got dropped as we moved to the emulator era, things like sixel or vector graphics stuff.
08:14 Voldenet_ joined
japhb ShimmerFairy: Several emulators now do sixels again, and with the invention of the kitty graphics protocol, we can do considerably better than that even. 08:15
(Note that I have not yet implemented support for the KGP in the Terminal:: modules, but it's probably only a matter of time. ;-) )
08:15 Voldenet left, Voldenet_ is now known as Voldenet
japhb Recently there's been a renaissance of terminal emulators, which just warms my heart. 08:16
ShimmerFairy While sending a jpeg or whatever over the wire is a natural evolution, and would've happened sooner if hardware terminals stuck around, a part of me can't help but think that makes it "too easy". Feels like it ought to involve a lot more jank, like converting to sixels or something. 08:27
If I got into terminal emulation more, my interest would likely lie in *actually* emulating terminal hardware, since all the normal terminal "emulators" are naturally focused on being usable in modern systems. 08:28
Here's a gist of what changes are discussed from Unicode 15.1 thru 17: gist.github.com/ShimmerFairy/eb6bb...23b1109028 13:03
I made up this list mainly to get myself to go over the list of changes, and so that anyone who knows more about how to upgrade Unicode support can chime in and go "oh, looks like we'll need to change XYZ in NQP" or the like. 13:04
patrickb That's nice. Thank you! 13:18
ShimmerFairy At the moment I'm updating roast tests so I can see how badly an updated MoarVM does. (Seems the autogen tests and docs could do with some touchup in the process.) 13:25
Tomorrow I'll begin working on fixing the NFG support. It seems, if I got it right, the procedure will be to update ucd2c.pl (since it invents an NFG_QC property for normalization purposes), and then updating the C code. 15:33
lizmat ++ShimmerFairy 16:30
japhb ++ShimmerFairy for sure! 16:57
21:56 librasteve_ joined 23:50 vrurg left

Powered by Cro and the Raku® Programming Language.

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

Thank you!