Manish Goregaokar comments

Results 1179 comments of


                                            Manish Goregaokar

Baked data is big, and compiles slowly, for finely sliced data markers

2 sounds compelling if we can make it work cleanly in our baking infra

Baked data is big, and compiles slowly, for finely sliced data markers

potentially have a flag for data keys that marks them as "VZV packable"

Baked data is big, and compiles slowly, for finely sliced data markers

One thing databake could potentially do is have a way for the CrateEnv to collect auxiliary codegen, which would work by: - CrateEnv gets a map you can append to,...

Baked data is big, and compiles slowly, for finely sliced data markers

LGTM as well

Baked data is big, and compiles slowly, for finely sliced data markers

Do we know which compiler pass is actually slow (`-Z time-passes`, I believe) Would be useful to compare that output to that of a normal utils crate and see where...

Baked data is big, and compiles slowly, for finely sliced data markers

Filed https://github.com/rust-lang/rust/issues/134404, with reduced testcase https://github.com/Manishearth/icu4x_compile_sample. Further reduced testcase in rm-macro that shows the difference when you avoid the macro step.

Baked data is big, and compiles slowly, for finely sliced data markers

I agree that they are still on the table. Option 2 doesn't sound _too_ bad. We could have toggles for data loading in the baked system that can produce baked...

Baked data is big, and compiles slowly, for finely sliced data markers

Another idea I had was that the Baked context could grow a helper method that shortens imports. Basically instead of generating ```rust // thousands of times icu::experimental::dimension::provider::units::UnitsDisplayNameV1 { patterns: icu::experimental::relativetime::provider::PluralPatterns...

Decide on names for icu_datetime and icu_calendar errors over FFI

This is blocked on https://github.com/unicode-org/icu4x/issues/5940 We don't seem to need a discussion yet, Shane plans to make a PR when ready and we can discuss if there is controversy.

"PRs must not be merged with pending reviews" section of our contribution policy

A couple beliefs/axioms I hold here: - It is uncommon to need multiple reviews for a PR - Exceptions: changes that touch multiple components in a nontrivial way, changes that...