MarseyFX #206

Closed
transbitch wants to merge 21 commits from <deleted>:marseyfx into master

Revamped emoji rendering engine. Includes 12+ new modifiers.

TODO:

  • Fix titles
  • Golden emojis
  • Random emojis
  • Support username handles as emojis
  • Heavy counting

Here is a sample post which you can use to test out all of the features:

Heyoo! It's your favorite programmer @transbitch here, and I've got something new I would like to show you...
:#marsey.meme("MARSEYFX").party:

MarseyFX is a new rendering engine for emojis. The main differences are that (1) modifiers (love, pat, etc) now have a dot before them, and (2) some modifiers now can accept arguments like this: `marsey.meme("Hello World")`. Note that random emojis have NOT changed, so to specify a random emoji, do `:marseyrandom:`.

Additionally, if you make a mistake with MarseyFX, you'll hopefully get a good error:

`:marsey.abcd(` becomes :marsey.abcd(:

Here all of the currently implemented effects (hover to see the code):

## Old effects
These should be mostly the same, but the code that renders them is completely different.

:#marsey::#marsey.pat::#marsey.love::#marsey.talking::#marsey.genocide:

## New effects

:#marsey.party::#marsey.says("Trans rights!")::#marsey.fallover::#marsey.transform("translate(30px, 30px)")::#marsey.enraged::#marsey.meme("Hello", "World")::#marsey.spin(2)::#marsey.triumphs(capy)::#marsey.nested(marsey)::#marsey.morph(marseyfemboy)::#marsey.prohibition::#marsey.scope::#marsey.fucks(capy)::#marsey.glow::#marsey.echo::#marsey.rentfree:
Revamped emoji rendering engine. Includes 12+ new modifiers. TODO: - [x] Fix titles - [x] Golden emojis - [x] Random emojis - [x] Support username handles as emojis - [x] Heavy counting Here is a sample post which you can use to test out all of the features: ``` Heyoo! It's your favorite programmer @transbitch here, and I've got something new I would like to show you... :#marsey.meme("MARSEYFX").party: MarseyFX is a new rendering engine for emojis. The main differences are that (1) modifiers (love, pat, etc) now have a dot before them, and (2) some modifiers now can accept arguments like this: `marsey.meme("Hello World")`. Note that random emojis have NOT changed, so to specify a random emoji, do `:marseyrandom:`. Additionally, if you make a mistake with MarseyFX, you'll hopefully get a good error: `:marsey.abcd(` becomes :marsey.abcd(: Here all of the currently implemented effects (hover to see the code): ## Old effects These should be mostly the same, but the code that renders them is completely different. :#marsey::#marsey.pat::#marsey.love::#marsey.talking::#marsey.genocide: ## New effects :#marsey.party::#marsey.says("Trans rights!")::#marsey.fallover::#marsey.transform("translate(30px, 30px)")::#marsey.enraged::#marsey.meme("Hello", "World")::#marsey.spin(2)::#marsey.triumphs(capy)::#marsey.nested(marsey)::#marsey.morph(marseyfemboy)::#marsey.prohibition::#marsey.scope::#marsey.fucks(capy)::#marsey.glow::#marsey.echo::#marsey.rentfree: ```
transbitch added 12 commits 2023-09-24 06:07:03 +00:00
transbitch added 1 commit 2023-09-25 21:14:48 +00:00
transbitch added 1 commit 2023-09-25 21:49:09 +00:00

jesus christ

jesus christ

I thought this was finished since there was talk of a merge but seems like there are still some things you want to do add so I won't do a full review. It's cool work, I like the new features, can't wait to put bulges on all the marseys.

Here are the main things I nooticed:

On style:
It would be good if there were some docstrings to explain the basics of the syntax of the language and architecture of the code as well as non-obvious arguments and returns for all functions, especially those with multiple returns like parse_emoji.
You left some prints in. ( 1 in parser, 2 in modifiers)
White-space only change at the end of const.py with bad indent
Dead code in sanitize lines 228, 318, 324.
It'd be good not to rely on wildcard imports for new code (sanitize line 293)
"match" is a keyword since 3.10 sanitize line 628

On the architecture, I'm not sure you need OO for a lot of this stuff. Your tokenizer could be a single function half that length since you don't even use the polymorphism as far as I can tell and just check the instance type every time, and it'd be more readable. Making it a generator could be good, not sure, I haven't groked the parser fully yet.

The heavy function in modifiers.py doesn't need to be a decorator. Also you can define the arguments as self, *args, **kwargs, rather than doing *args, **kwargs and self = args[0] in all decorators, you can use self instead of slf, it's not a keyword.
Your classes (Modifier, ModifierContextFrame) should be data tuples if they are only meant to hold a couple values and no methods, unless they interact in some way with the soup that I don't know about.

I don't understand what context_frames do but my gut is something is odd since they're just added then popped, something to do with the soup? If they are not needed this decorator would also work as just a function.

One last thing that concerned me with these changes, beside the regexes which I haven't looked at, is whether the changes are backward compatible.

That's from a cursory first look, I might look more tomorrow.

One love.

I thought this was finished since there was talk of a merge but seems like there are still some things you want to do add so I won't do a full review. It's cool work, I like the new features, can't wait to put bulges on all the marseys. Here are the main things I nooticed: On style: It would be good if there were some docstrings to explain the basics of the syntax of the language and architecture of the code as well as non-obvious arguments and returns for all functions, especially those with multiple returns like parse_emoji. You left some prints in. ( 1 in parser, 2 in modifiers) White-space only change at the end of const.py with bad indent Dead code in sanitize lines 228, 318, 324. It'd be good not to rely on wildcard imports for new code (sanitize line 293) "match" is a keyword since 3.10 sanitize line 628 On the architecture, I'm not sure you need OO for a lot of this stuff. Your tokenizer could be a single function half that length since you don't even use the polymorphism as far as I can tell and just check the instance type every time, and it'd be more readable. Making it a generator could be good, not sure, I haven't groked the parser fully yet. The heavy function in modifiers.py doesn't need to be a decorator. Also you can define the arguments as self, *args, **kwargs, rather than doing *args, **kwargs and self = args[0] in all decorators, you can use self instead of slf, it's not a keyword. Your classes (Modifier, ModifierContextFrame) should be data tuples if they are only meant to hold a couple values and no methods, unless they interact in some way with the soup that I don't know about. I don't understand what context_frames do but my gut is something is odd since they're just added then popped, something to do with the soup? If they are not needed this decorator would also work as just a function. One last thing that concerned me with these changes, beside the regexes which I haven't looked at, is whether the changes are backward compatible. That's from a cursory first look, I might look more tomorrow. One love.

They are totally backwards compatible since rDrama "renders" every post into HTML when you submit it and then just stores that HTML. So nothing needs to be done regarding other posts.

IMO you never "need" OO for this kind of stuff, but I prefer it -- makes things easier to reason about.

Context frames are a concept borrowed from React (simply called "context" in React). Its an implicit way of passing variables from parent to child.

They are totally backwards compatible since rDrama "renders" every post into HTML when you submit it and then just stores that HTML. So nothing needs to be done regarding other posts. IMO you never "need" OO for this kind of stuff, but I prefer it -- makes things easier to reason about. Context frames are a concept borrowed from React (simply called "context" in React). Its an implicit way of passing variables from parent to child.

It would be good if there were some docstrings to explain the basics of the syntax of the language and architecture of the code as well as non-obvious arguments and returns for all functions, especially those with multiple returns like parse_emoji.

I don't think you know what codebase ur reviewing πŸ˜‚πŸ˜‚πŸ˜‚

> It would be good if there were some docstrings to explain the basics of the syntax of the language and architecture of the code as well as non-obvious arguments and returns for all functions, especially those with multiple returns like parse_emoji. I don't think you know what codebase ur reviewing πŸ˜‚πŸ˜‚πŸ˜‚

Yeah asking for docstrings in this is a lost cause lol.

Looks really nice, big supporter of improving this part of the codebase.

That being said @transbitch a couple of things you'll need to make this ready to merge (maybe you already know):

  • make sure you edit the preview js to include all of these modifiers too.
  • Make sure you can add multiple modifiers to the same marsey without breaking the styling and with preserved order (talking enraged marsey being different from enraged talking marsey)
Yeah asking for docstrings in this is a lost cause lol. Looks really nice, big supporter of improving this part of the codebase. That being said @transbitch a couple of things you'll need to make this ready to merge (maybe you already know): - make sure you edit the preview js to include all of these modifiers too. - Make sure you can add multiple modifiers to the same marsey without breaking the styling and with preserved order (talking enraged marsey being different from enraged talking marsey)

Maintainers, please reject this PR.

Maintainers, please reject this PR.
transbitch added 1 commit 2023-09-28 05:02:29 +00:00

Yeah asking for docstrings in this is a lost cause lol.

I think it's self-documenting enough. Dora voice: Can YOU guess what the @modifier decorator means?

Looks really nice, big supporter of improving this part of the codebase.

Thx :marseyhearts:

make sure you edit the preview js to include all of these modifiers too.

Maybe but honestly that can be put on a later update. I really dont want to fuck with frontend stuff without any view framework, its awful. Maybe @Aevann would be open to having a little itty bitty framework?

Make sure you can add multiple modifiers to the same marsey without breaking the styling and with preserved order (talking enraged marsey being different from enraged talking marsey)

This is already the case. It is designed with this in mind, it is entirely compositional

@top

> Yeah asking for docstrings in this is a lost cause lol. I think it's self-documenting enough. Dora voice: Can YOU guess what the `@modifier` decorator means? > Looks really nice, big supporter of improving this part of the codebase. Thx :marseyhearts: > make sure you edit the preview js to include all of these modifiers too. Maybe but honestly that can be put on a later update. I really dont want to fuck with frontend stuff without any view framework, its awful. Maybe @Aevann would be open to having a little itty bitty framework? > Make sure you can add multiple modifiers to the same marsey without breaking the styling and with preserved order (talking enraged marsey being different from enraged talking marsey) This is already the case. It is designed with this in mind, it is entirely compositional @top

The modifier decorator is a good example because it's not clear what it 's for. You already have modifier functions which you would expect to hold that logic. And the role of the ContextFrame as a recursive name stack would be clearer if the syntax of the modifiers had been documented as compositional somewhere.

I guessed there was something like this going on but without even a short description of how the system works anywhere in the code I had no idea what the actual syntax of an emoji was supposed to be short of my reverse-engineering of the parsers and tokenizer.

I think some explanation of the syntax like you did in the readme would go a long way to make the code easier to interpret, as well as some selective info about the idiosyncracies and interplay of each architectural element (parser, modifier, tokenizer).

Anyway that's my $2c but it's your free time so I get if you don't want to waste it on this.

The modifier decorator is a good example because it's not clear what it 's for. You already have modifier functions which you would expect to hold that logic. And the role of the ContextFrame as a recursive name stack would be clearer if the syntax of the modifiers had been documented as compositional somewhere. I guessed there was something like this going on but without even a short description of how the system works anywhere in the code I had no idea what the actual syntax of an emoji was supposed to be short of my reverse-engineering of the parsers and tokenizer. I think some explanation of the syntax like you did in the readme would go a long way to make the code easier to interpret, as well as some selective info about the idiosyncracies and interplay of each architectural element (parser, modifier, tokenizer). Anyway that's my $2c but it's your free time so I get if you don't want to waste it on this.

Yeah asking for docstrings in this is a lost cause lol.

I meant docstrings for this codebase lol

Maybe but honestly that can be put on a later update. I really dont want to fuck with frontend stuff without any view framework, its awful. Maybe Aevann would be open to having a little itty bitty framework?

I get that it's a pain in the ass but it's kinda required so that users know what their comment will look like before they post. If you really don't want to do it I can port over your python code.

Good that it works for all manner of modifier combinations, I really only skimmed it lol

> Yeah asking for docstrings in this is a lost cause lol. I meant docstrings for this codebase lol > Maybe but honestly that can be put on a later update. I really dont want to fuck with frontend stuff without any view framework, its awful. Maybe Aevann would be open to having a little itty bitty framework? I get that it's a pain in the ass but it's kinda required so that users know what their comment will look like before they post. If you really don't want to do it I can port over your python code. Good that it works for all manner of modifier combinations, I really only skimmed it lol
transbitch added 1 commit 2023-10-08 23:46:58 +00:00
transbitch added 1 commit 2023-10-09 00:49:46 +00:00

Only 10 merge conflicts wow

Only 10 merge conflicts wow
transbitch added 1 commit 2023-10-09 01:06:04 +00:00
transbitch added 1 commit 2023-10-09 01:59:42 +00:00
transbitch changed title from WIP: MarseyFX to MarseyFX 2023-10-09 02:00:32 +00:00
transbitch added 1 commit 2023-10-11 15:35:28 +00:00
transbitch added 1 commit 2023-10-11 15:36:08 +00:00

too many pointless changes, unreviewable

too many pointless changes, unreviewable
Aevann closed this pull request 2023-10-27 09:31:52 +00:00

Pull request closed

Sign in to join this conversation.
There is no content yet.