CLDR-15817 Update Example Generator
CLDR-15817
First draft
- [ ] This PR does not complete the ticket.
ALLOW_MANY_COMMITS=true
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 to fix the formatting you can run this:
mvn --file=tools/pom.xml spotless:apply && sh tools/cldr-apps/js/test/pretty.sh
@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.
attempting with the resolved file led to an extremely long run time
that's a puzzle -- does anyone know why?
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.
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.
@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 Thanks! 🎉
@haytenf Thanks! 🎉
Thank you!