cldr icon indicating copy to clipboard operation
cldr copied to clipboard

CLDR-15817 Update Example Generator

Open haytenf opened this issue 1 year ago • 2 comments

CLDR-15817

First draft

  • [ ] This PR does not complete the ticket.

ALLOW_MANY_COMMITS=true

haytenf avatar Aug 21 '24 15:08 haytenf

Incomplete draft that creates a new method that calls createExampleHtml passing a list as an additional argument and updates one of the handlers ( handleDateRangePattern) to use this list -- doesn't pass tests since only one handler has been changed to fit new approach. Just to make sure on the right track for updating the handlers. If anyone could take a look when they get a chance @macchiati @srl295

haytenf avatar Aug 21 '24 15:08 haytenf

@haytenf to fix the formatting you can run this: mvn --file=tools/pom.xml spotless:apply && sh tools/cldr-apps/js/test/pretty.sh

btangmu avatar Aug 27 '24 18:08 btangmu

@btangmu @srl295 @macchiati In the most recent commit, I've added a unit test comparing the old/new example generator, cleaned up the commented out code, and added before/after screenshots that show the example doesn't change.

I also wanted to explain a change I made that isn't related to the purpose of this ticket. With the new unit test I added (TestRefactoring), I ended up running into a null pointer exception (in both the old example generator and the updated example generator) that I traced back to the getOtherGender method that handleMinimalPairs calls. The exception was an issue with calling grammarInfo.get(GrammaticalTarget.nominal, GrammaticalFeature.grammaticalGender, GrammaticalScope.units); in line 1221 since grammarInfo could be null, so that's why I made that change.

I also wanted to note for that the unit test, TestRefactoring, I ended up using the unresolved cldr files to get the paths that I would test over, since attempting with the resolved file led to an extremely long run time (in fact, it never completed and I ran out of memory before it could). I'm not sure if there's something I could do to improve the efficiency of the test and eventually use the resolved files, but for now that's how I've left it.

haytenf avatar Sep 04 '24 00:09 haytenf

attempting with the resolved file led to an extremely long run time

that's a puzzle -- does anyone know why?

btangmu avatar Sep 05 '24 18:09 btangmu

attempting with the resolved file led to an extremely long run time

that's a puzzle -- does anyone know why?

locally or on the github build? if it's the github build could have just been random.

srl295 avatar Sep 05 '24 18:09 srl295

attempting with the resolved file led to an extremely long run time

that's a puzzle -- does anyone know why?

locally or on the github build? if it's the github build could have just been random.

I'm still not sure what could be the issue. It was an issue locally--it ended up running for 12+ hours at which point it ran into a runtime exception/memory error from running out of heap space.

haytenf avatar Sep 05 '24 19:09 haytenf

@srl295 @btangmu @macchiati I've modified the test so that it only checks the paths that are shown to users. If that's looking ok, I can remove the old file (ExampleGeneratorOld.java) from the PR.

haytenf avatar Sep 09 '24 16:09 haytenf

@haytenf Thanks! 🎉

srl295 avatar Sep 10 '24 14:09 srl295

@haytenf Thanks! 🎉

Thank you!

haytenf avatar Sep 10 '24 17:09 haytenf