There are no checks which is a valid character but not ASCII.

Removed input validation altogether as per a suggestion on Discord.

random tests need to be adjusted, and null character needs to be specifically tested.

Updated the description to mention that characters can be unicode too, added a fixed test with just the null character, and random tests may now generate null characters.

what happens if emoji numbers like 069 or 007 appear in the input?

They're valid. Random tests now randomly precede ~1% of characters' strings with a 0 emote.

Also put the fixed/random tests into two separate blocks (suggested by saudiGuy) and doubled number of random tests.

Once you find out earlier research on the topic, it becomes clear. Puzzle tag seems acceptable here. Since various algorithms and solutions can be found online, this kata will not likely be approved at a difficult kyu level. Current ranking votes show this. I can approve at current average vote of 5 kyu, and probably should add a link to the wiki page describing this problem.

its better to have separate blocks of fixed and random tests.

I believe C# also has a rich set of Grapheme functions. But sure, it would be interesting to see this kata in C#.

Well I added JS translation, and it turns out only slightly trickier than Python. Internal representation of strings is different, but String API is rich enough to ensure smooth experience for solvers.

I will try with another language tomorrow. Maybe C#?

In the meantime, feel free everybody to get the JS version a shot!

This description is written for academici.

For given p, your task is to find the smallest generator of multiplicative group of residues modulo p.

Sure, let's do that .. let us first look online what all of this means.

Also, p is not always prime. Though the description makes it look like it is.

I changed the description a little bit, is it satisfactorily now ?

out-of-bounds ASCII charcode

The test does not test this correctly; first, the invalid test only inputs a number 2345678, which is completely outside the Unicode range, so it isn't even a valid character, and fails any checks without question. There are no checks which is a valid character but not ASCII.

Secondly, random tests generate random charcodes in range 1 - 256 (randint is inclusive in both sides), but the valid range for ASCII is 0 - 127. Yes, null character is valid too. So the random tests need to be adjusted, and null character needs to be specifically tested.

(Also, what happens if emoji numbers like 069 or 007 appears in the input? are they considered valid? This needs to be clarified and tested too.)

Should be fixed now.

2nd sample test case is incorrect:

test.assert_equals(deemojify(';) >(  :D :) :D  :D :) ^.^  :D :) ^.^  :D :D :D  >:C >(  :D :D :(  :D :D :D  :D :) :/  :D :) :)  >:C >:C'), 'Hello world!')

This translates to Hello wohd!. You can even tell without translating since there are not enough chains.

The kata description should state what keycap emojis are, so the user can look for their codes in the kata description instead of digging through the specification.

C++ translation published

Blocking approval, see earlier comment about 2nd language to be added.

Modulus will be around 32 bits

Input passed by random tests go up to 64 bits.