Add Snake to Camel Case and Camel to Snake Case

[briandowns]

Add Snake to Camel Case and Camel to Snake Case

What's Changed:

Added 2 methods to the string type.

Type of Change:

• Bug fix
• New feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Housekeeping:

• Tests have been updated to reflect the changes done within this PR (if applicable).
• Documentation has been updated to reflect the changes done within this PR (if applicable).

Screenshots (If Applicable):

[Jason2605]

Looks as though it's still having a little bit of trouble tracking the memory on this one, I'll see if I can figure out what is happening later on today then get this one reviewed for you!

[briandowns]

This is a classic case of "worked on my machine". I pushed it up and work got crazy. I've been trying to get back to it. :/

[Jason2605]

Haha yeah I’ve been pretty busy too! Honestly no sweat tho, I appreciate any time you get and of course life comes first!

[Jason2605]

Apologies been inactive on this, I'm actually on holiday for 5 weeks but I promise I will get around to it!!

[briandowns]

No worries. I got the memory issue resolved and need to figure out the Mac issue now. Been super busy with work but I think I can wrap this up this week. Thanks!

[Jason2605]

Mac issue should be sorted now! I’ll take a look at the memory issue sometime tomorrow hopefully. I’ve been a bit inactive on this and need to get back into it, apologies

[briandowns]

It's insanely coincidental that you looked at this as just last night I did as well but it's been awhile and my Mac has updated so I'm fighting through getting the project to build again. What was the fix?

[Jason2605]

It's insanely coincidental that you looked at this as just last night I did as well but it's been awhile and my Mac has updated so I'm fighting through getting the project to build again. What was the fix?

The mac actions issue was the fact that -latest is now on an ARM processor so the FFI module was failing, but @liz3 sorted that out for us!

[Jason2605]

Very strange happenings on Mac:

int i, j;
    for (i = j = 0; i < string->length; i++, j++) {
        if (string->chars[i] == '_' && false) {
            temp[j] = toupper(string->chars[++i]);
        } else {
            temp[j] = string->chars[i];
        }
    }
    temp[j+1] = '\0';

    printf("%d %d %d %lu %lu \"%s\"\n", i, j, string->length + 1, strlen(temp) + 1, strlen(temp), temp);

    if (i != j) {
        temp = SHRINK_ARRAY(vm, temp, char, string->length + 1, strlen(temp) + 1);
        x -= (string->length + 1);
        printf("1: %d\n", x);
        x += (strlen(temp) + 1);
    }

The very odd occasion I get erroneous output:

>>> x.snakeToCamelCase();
19 19 20 20 19 "test_test_test_test"
20
test_test_test_test
>>> x.snakeToCamelCase();
19 19 20 21 20 "test_test_test_test�"
20
test_test_test_test

[liz3]

This is super dangerous, it does assumptions about the length of string, if a string ends with "_" this will append the null byte as content to temp, if toupper handles that

[Jason2605]

Yeah valid point, probably need a length check here

[liz3]

this is a missmatch in behaviour, because the later implementation returns a new string, this returns a pointer to the existing string if i am not mistaken.

[Jason2605]

It's not the end of the world, strings are interned in the VM anyways

[liz3]

Very strange happenings on Mac:

int i, j;
    for (i = j = 0; i < string->length; i++, j++) {
        if (string->chars[i] == '_' && false) {
            temp[j] = toupper(string->chars[++i]);
        } else {
            temp[j] = string->chars[i];
        }
    }
    temp[j+1] = '\0';

    printf("%d %d %d %lu %lu \"%s\"\n", i, j, string->length + 1, strlen(temp) + 1, strlen(temp), temp);

    if (i != j) {
        temp = SHRINK_ARRAY(vm, temp, char, string->length + 1, strlen(temp) + 1);
        x -= (string->length + 1);
        printf("1: %d\n", x);
        x += (strlen(temp) + 1);
    }

The very odd occasion I get erroneous output:

>>> x.snakeToCamelCase();
19 19 20 20 19 "test_test_test_test"
20
test_test_test_test
>>> x.snakeToCamelCase();
19 19 20 21 20 "test_test_test_test�"
20
test_test_test_test

i do think the temp[j+1] = '\0'; has to be temp[j] = '\0';

    printf("%s %d %lu\n", temp, j, strlen(string->chars));

produces

>>> var x = "test_test_test_test";
>>> x.snakeToCamelCase();
test_test_test_test 19 19
test_test_test_test
>>> 

which makes sense since we need to set the length index for the 0 byte.
So your faulty byte is whatever is there in the data.

You can even see it:

 
    int i, j;
    for (i = j = 0; i < string->length; i++, j++) {
        if (string->chars[i] == '_' && false) {
            temp[j] = toupper(string->chars[i+1]);
            i++;
        } else {
            temp[j] = string->chars[i];
        }
    }
    temp[j] = 'X';
    temp[j+1] = '\0';

    printf("%s %d %lu\n", temp, j, strlen(string->chars));

    if (i != j) {
        temp = SHRINK_ARRAY(vm, temp, char, string->length + 1, strlen(temp) + 1);
    }

    return OBJ_VAL(takeString(vm, temp, j));

Dictu Version: 0.29.0
>>> var x = "test_test_test_test";
>>> x.snakeToCamelCase();
test_test_test_testX 19 19
test_test_test_test
>>> 

(and yes temp[j+1] = '\0'; is a one byte buffer overflow but it works!

[Jason2605]

Very strange happenings on Mac:

int i, j;
    for (i = j = 0; i < string->length; i++, j++) {
        if (string->chars[i] == '_' && false) {
            temp[j] = toupper(string->chars[++i]);
        } else {
            temp[j] = string->chars[i];
        }
    }
    temp[j+1] = '\0';

    printf("%d %d %d %lu %lu \"%s\"\n", i, j, string->length + 1, strlen(temp) + 1, strlen(temp), temp);

    if (i != j) {
        temp = SHRINK_ARRAY(vm, temp, char, string->length + 1, strlen(temp) + 1);
        x -= (string->length + 1);
        printf("1: %d\n", x);
        x += (strlen(temp) + 1);
    }

The very odd occasion I get erroneous output:

>>> x.snakeToCamelCase();
19 19 20 20 19 "test_test_test_test"
20
test_test_test_test
>>> x.snakeToCamelCase();
19 19 20 21 20 "test_test_test_test�"
20
test_test_test_test

i do think the temp[j+1] = '\0'; has to be temp[j] = '\0';

    printf("%s %d %lu\n", temp, j, strlen(string->chars));

produces

>>> var x = "test_test_test_test";
>>> x.snakeToCamelCase();
test_test_test_test 19 19
test_test_test_test
>>> 

which makes sense since we need to set the length index for the 0 byte. So your faulty byte is whatever is there in the data.

You can even see it:

 
    int i, j;
    for (i = j = 0; i < string->length; i++, j++) {
        if (string->chars[i] == '_' && false) {
            temp[j] = toupper(string->chars[i+1]);
            i++;
        } else {
            temp[j] = string->chars[i];
        }
    }
    temp[j] = 'X';
    temp[j+1] = '\0';

    printf("%s %d %lu\n", temp, j, strlen(string->chars));

    if (i != j) {
        temp = SHRINK_ARRAY(vm, temp, char, string->length + 1, strlen(temp) + 1);
    }

    return OBJ_VAL(takeString(vm, temp, j));

Dictu Version: 0.29.0
>>> var x = "test_test_test_test";
>>> x.snakeToCamelCase();
test_test_test_testX 19 19
test_test_test_test
>>> 

(and yes temp[j+1] = '\0'; is a one byte buffer overflow but it works!

Yep that was it 🤦 it should have been j not j+1 great spot!

[Jason2605]

Gonna close this out for now with the new UTF8 strings coming in, but happy for this method to be re-added

[liz3]

Im thinking this is maybe something which could be implemented in dictu itself, the reason being that some functionality might not be used enough no need the speedup in c. Comparing to js/python here.
I think it might be a useful idea to limit the standard library to functionality which is commonly expected from a std lib.