Problem parsing similar variables when names overlap

[kawaiipantsu]

Problem parsing similar variables when names overlap

[frikky]

Describe the bug When you have multiple variables with similar names but still not the same, you can't process/call them very well unless you do it in a order where names go from longest to smallest so that the names never cross or confuses shuffle. It's like it's caching the first variable name it sees and then it wont let you use anything in the same naming convention. Always just sending the first variable names value back.

Version: 1.3.3

To Reproduce Check screenshot.

Make 2 keys that are similar like the following: test1key = 1234 test1keyname = Hello world

Try to print them out like so:

$test1key
$test1keyname

The output you get is wrong, well it's really not but there is no way to diiferenciate between variable names. Normally you would be able to put your variable between $(this.is.my.full.name) or ${this.is.myfull.name} and then it would know what part to use and not get confused...

1234
1234name

...

Expected behavior I would expect to see output like:

1234
Hello world

Screenshots If applicable, add screenshots to help explain your problem.

Hey!

Describe the bug When you have multiple variables with similar names but still not the same, you can't process/call them very well unless you do it in a order where names go from longest to smallest so that the names never cross or confuses shuffle. It's like it's caching the first variable name it sees and then it wont let you use anything in the same naming convention. Always just sending the first variable names value back.

Version: 1.3.3

To Reproduce Check screenshot.

Make 2 keys that are similar like the following: test1key = 1234 test1keyname = Hello world

Try to print them out like so:

$test1key
$test1keyname

The output you get is wrong, well it's really not but there is no way to diiferenciate between variable names. Normally you would be able to put your variable between $(this.is.my.full.name) or ${this.is.myfull.name} and then it would know what part to use and not get confused...

1234
1234name

...

Expected behavior I would expect to see output like:

1234
Hello world

Screenshots If applicable, add screenshots to help explain your problem.

Hey!

Thanks for reporting this - weird how it hasn't been caught before somehow 👀 It also works correctly in our frontend interpreter somehow (JS).

It has to do with the SDK somehow, and it looks to be in this area. Problem should just be the check of an "equals exactly" vs "contains".

Shuffle/backend/app_sdk/app_base.py

Line 2251 in 06ac921

actionname_lower = parsersplit[0][1:].lower()

[kawaiipantsu]

Yes i was wondering how it have not been caught to, but i do believe that has something to do with many run their own "python" code directly in many cases and are not reliant so much on the build in features. But yeah i was building a "template" for a Discord webhook so was doing a lot of output with all my strings and ran into this very much so.

I was concerned that it was a cacheing problem mixup etc.
But i can see in the code that you might be right, it's simply making sure that at first it equals then contain etc.

I hope you get it fixed in the next push, cheers!

[frikky]

Yes i was wondering how it have not been caught to, but i do believe that has something to do with many run their own "python" code directly in many cases and are not reliant so much on the build in features. But yeah i was building a "template" for a Discord webhook so was doing a lot of output with all my strings and ran into this very much so.

I was concerned that it was a cacheing problem mixup etc. But i can see in the code that you might be right, it's simply making sure that at first it equals then contain etc.

I hope you get it fixed in the next push, cheers!

I think the only reason it hasn't showed up much is because the autogenerator for names of nodes typically adds a number to everything, meaning they don't at all overlap, and if you type your own names, they are typically very descriptive.

Up to @0x0elliot when it's gonna be fixed ;)

[frikky]

Fixed in the latest SDK! It was a problem of using replace(source, dest) instead of replace(source, dest, 1)

Apparently replace() in python does replaceAll by default, without requiring -1