Looking for Python2 Developer for Small Patch

[RealityRipple]

I'm working on Emoji 17 support, but I think it's definitely time to update UXP's Unicode components. Fortunately (or unfortunately for me), the ICU has moved their sources lists from the MAKEFILE proper to a sources.txt in the same folder, with each entry on a lovely new line, which should make reading them much more efficient than icu_sources_data.py's current method of loading and parsing the OBJECTS statement using pymake. I know a lot of other languages, but I've never touched Python in my life, so I could use some help with this step.

The task should be somewhat simple. A single function in icu_sources_data.py, get_sources_from_makefile at lines 136 through 147 (and 179 for the file path), needs to be rewritten to read the sources.txt files from the common and i18n folders and return the file paths, same as the current code does.

I'm sure this should be easy as heck to do, if you know the language, but as I said, I don't.
Anyone willing to spend a few minutes on this?

Edit:
Or just tell me if I've done anything stupid or wrong here:

Code: Select all

def get_sources_from_txtfile(sourcetxt):
    srcdir = os.path.dirname(sourcetxt)
    lines = []
    with open(sourcetxt, 'r') as srcfile:
      for ln in srcfile:
        lines.append(find_source_file(srcdir, ln.rstrip('\n')))
    return sorted(lines, key=lambda x: x.lower())

[adoxa]

Seems fine. 'r' is the default open mode and whitespace is stripped by default, so those arguments aren't strictly necessary; and you only need key=str.lower. You could perhaps sort in place (lines.sort(key=str.lower) and return lines), but probably not big enough to worry about.

[RealityRipple]

Well, I think it worked... now there's a couple dozen non-dll-interface classes being used as bases for dll-interface classes and a handful of bool/UBool conversions to smooth over...


And of course I had to try this with the one version they added these non-dll-interface descriptors to make their base classes private. And of course, it has to be in some elements that are compiled to throw errors instead of warnings for that specific error code. Guess I'm adding directives to disable warnings C4251 and C4275 around all the relevant exported ICU classes in yet another patch. Eighteen files because of course you can't wrap the suppressor around the inherited class, just the inheriting one.

Next-day update: the warning suppression let it compile! And it flippin ran! And all* the emojis are rendering correctly for once!


*Except some minimally qualified gender variations which I believe are caused by the font being built with emojibase-data v16.0.3.

[RealityRipple]

Alright, everything's a-running on Windows for me on PM, so now it's time to branch out.

If any developers (not just python) would like to help test compile ANY UXP APPLICATION with the ICU update, I've got a branch with an alpha version of Emoji 17 at https://repo.palemoon.org/RealityRipple/UXP/src/branch/emoji-17.0-alpha (still waiting on a dependency to update from Emoji 16 to 17 to fix a couple partially-qualified misrenderings, thus alpha) that should be ready for initial testing. The commits can be cherry-picked over to the release branch if you don't want to run on master; I'm posting this from such a compile right now. I also need to know what happens on non-Windows systems, with and without system-provided ICU libraries.


However, there's one tzdata change that I'd like some additional python2 dev help with: they finally deleted the never-used US/Pacific-New timezone, and also decided to kill Etc/Unknown while they were at it. But I need some help on this front. The make_intl_data.py file has a handful of functions that modify the various lists of timezones for various purposes, and I only added the two lines I absolutely needed to get this thing rolling; I don't know what else is needed, or if I killed something I shouldn't have. I also don't quite understand how some of this worked before I made the edits - the zones set already deleted Etc/Unknown, but it was still in the links dictionary, which I had to remove it from. I did this by using the key, Factory, which I found particularly amusing since there's code all over the rest of this script for an option to ignoreFactory, but it's not in the function where I ended up needing it. Anyway, I'd really appreciate a more experienced eye on this particular file due to Etc/Unknown's previous use as a null value.

[RealityRipple]

Branch moved to https://repo.palemoon.org/RealityRipple/UXP/src/branch/emoji-17.0 with the release of emojibase-data 17! Twemoji 17 PR at https://repo.palemoon.org/MoonchildProductions/twemoji-colr/pulls/10! All emojis looking flawless on Windows.

[BenFenner]

Good job with the Python. I almost jumped in since Ruby is my wheelhouse, but ehhh...

Off-topic:

emojis

emojis

"Emojis" is not a word.
"Emoji" is both singular and plural, like all nouns borrowed from Japanese.
(Just like "sushi", "samurai", "ramen", "pokemon", "anime", etc.)

viewtopic.php?p=264723#p264723

If you have "emojis" anywhere in code or comments, you should fix that.

Off-topic:

thus alpha

It sounds like you're using app behavior to dictate alpha/beta versioning. Just a reminder, that is not how this style of versioning works. Alpha and Beta have very specific meaning, and they have nothing to do with the quality of the code or the app behavior.
Alpha versions are test/pre-release versions available only to those within the source development organization.
Beta versions are test/pre-release versions available to those [possibly inside, but] necessarily outside the organization, either limited in some fashion (a second party, the customer, sign-up list, random selection from the public, etc.) or completely public.

[Moonchild]

Off-topic:

"Emojis" is not a word.
"Emoji" is both singular and plural, like all nouns borrowed from Japanese.
(Just like "sushi", "samurai", "ramen", "pokemon", "anime", etc.)

Oh boy, I'm disagreeing with you a lot today, it seems
Both plural forms are accepted (at least in US-English), and in fact, the barbarism has been adopted so broadly that it is more often than not considered an accepted English term subject to English grammar rules, that isn't a historical plural rules exception.

The debate between these two pluralizations of emoji has been raging for almost as long as emojis have existed. To quote Bustle writer Lucia Peters, the answer to this question is both “incredibly simple and unexpectedly complicated.”

The Short Answer—Emojis

The Associated Press took a hard stand on this issue in March 2013, making it one of the first style guides to draw a line in the sand in favor of “emojis.” Since then, major publications like The Atlantic and The New York Times have mostly adopted this spelling as well, and the emoji-tracking dictionary Emojipedia has officially supported the “-s” pluralization for ease of use. Although neither spelling is technically incorrect, “emojis” follows the normal inflection pattern of English nouns, giving it a slight advantage over “emoji.”

The discussion of emoji pluralization is both simple and complex, but, simply put, English usually makes plurals using English plural rules. To quote Mark Allen, a board member of the American Copy Editors Society, “When words enter English, we usually make them play by our rules, so I think ‘emojis’ has the edge. A corollary might be the Japanese word ‘tsunami.’ We’re more likely to speak of ‘a series of tsunamis’ rather than ‘a series of tsunami.’”

As an aside, I prefer the Japanese-inspired plural myself, just like you, but the -s plural has been accepted as equally valid so it then just becomes a question of preference or requested style (e.g. when being a translator or editor). Sometimes difficult to do if you have a strong preference for one of the two alternatives and have to use the other; I know first hand from past work

[BenFenner]

Off-topic:
"Indian" was also incorrectly accepted in US-English for centuries to describe a "Native American". It does not mean those of us who know better should lay down. I will continue to fight the good fight, and I have centuries to wait.

[RealityRipple]

Off-topic:
I've got a sample case of all of two that I've spoken to directly about the subject and they both preferred the term "Indian".

On-topic, my use of the word alpha was completely intentional and by-the-book definition. No one that doesn't compile and test from the repo was supposed to touch it. However...

Off-topic:
this seems like a pedantic conflation to me. The definition of alpha being relegated to developers and core test members is BECAUSE of its stability and featureset. Confusing surface-level-cause and purpose, and following cause instead is how you get a tax code instead of math.