Next topic

[sorlok_reaves]

Ok, my array branch is stable; should fix about 30% of the problems with arrays (the rest are far more fundamental and will require a separate fix).

Please test!

https://github.com/sorlok/enigma-dev/tree/array_fix

[Goombert]

Sorlok you're amazing!!! 

Josh wanted to pull it right away but I want to pull and test it first, I am extremely swamped atm but I will make the time to test this and get it merged as soon as I can.

Edit:
I have reviewed the pull request and everything is great except warnings in the console.
https://github.com/enigma-dev/enigma-dev/pull/856

I took the liberty of documenting the new functions for everyone.
http://enigma-dev.org/docs/Wiki/Data_Structure_Functions

[sorlok_reaves]

Thanks for testing this! I've updated the pull request with the fixes you requested.

[Goombert]

As of the following pull request we now have working array length functionality that has been tested and confirmed to work mostly as we expect with the exception of is_array() which is not yet ECMA compliant.
https://github.com/enigma-dev/enigma-dev/pull/856

Everyone give sorlok a round of applause! Yay sorlok! 



You can get these changes by using git-bash to pull from master. I will updating the Portable ZIP in a few days.

[Goombert]

I'd like to add to this post that I've recently sent a patch for some additional array fixes, specifically those which use primitives like int[] or double[]
https://github.com/enigma-dev/enigma-dev/pull/905

I believe Harri was complaining about these bugs, it was broken by fundies just before the new JDI was merged back in 2012. The code for coercing the type was destroyed however because secondary parse is supposed to use an AST, but I temporarily hacked around that using a map. I would appreciate if the pull request could be regression tested by everyone to ensure I haven't broken anything else in the process.

[TheExDeus]

Thank you! This is so awesome! Does it also work with 2d arrays? This bug is the reason why I have often used ds_ instead of arrays, because often regular arrays were parsed wrong as well. Like when used in scripts.
Also, do these arrays (together with EDL arrays) extend to more than 2 dimensions? I actually don't like that GM limitation of only having 2 dimensions. EDL arrays will probably be stuck there, but if the parser bugs are fixed and these are used as regular C++ arrays, then at least they should allow n-dimensions.
I will test all of this later. Thank you!

[Goombert]

You are welcome Harri, and it looks like that is the next thing to fix while I am in here.

Code (EDL) Select Expand


int d[5][5];
d[5][5] = 3;
show_message(string(d[5][5]));


Gives me...

Code Select Expand


C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_objectfunctionality.h:54:17: error: expression cannot be used as a function
     d[int(5)] (5)= 3;
                 ^
C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_objectfunctionality.h:55:39: error: expression cannot be used as a function
     show_message(toString(d[int(5)] (5) ));
                                       ^


So I still have some work to do, I'll try and see if I can get it fixed.

Edit: I fixed the multi-dimensional arrays as well in the following commit.
https://github.com/enigma-dev/enigma-dev/pull/908

Code (EDL) Select Expand


int d[5][5][5];
d[5][5][5] = 4;
show_message(string(d[5][5][5]));


Will now properly parse into the following.

Code (CPP) Select Expand


int d[5] [5] [5];
d[int(5)] [int(5)] [int(5)]= 4;
show_message(toString(d[int(5)] [int(5)] [int(5)] ));


Edit: Fixes tested and merged.
https://github.com/enigma-dev/enigma-dev/pull/908