ENIGMA Forums
General fluff => General ENIGMA => Topic started by: Goombert on October 10, 2014, 02:42:33 am
-
I was going to do a little something, and realized that arrays were fixed. I can't quite recall who or what fixed them or when they did it, but they do seem to work now.
The following builds fine for me on the latest master.
var ass;
ass[0] = 69;
show_message(string(ass[0]));
Whoever it was, thank you!
Additionally that thing I was trying to do was provide an array length function, but sadly JDI fails to parse the templates, it keeps saying the function is undefined unless I change the parameter
template <unsigned array_size>
unsigned array_length_1d(variant (&v)[array_size]);
-
I think nobody fixed the arrays. It was always possible to declare arrays with var. The problem is that it's possible to use arrays only with var type. Currently it's not possible to declare strongly type arrays.
In the past i updated already the wiki :
Arrays
An array is always declared as a variant data type with the keyword var, followed by its name.
http://enigma-dev.org/docs/Wiki/ENIGMA:Specification
-
Arrays are not, I think, entirely fixed. The way they're copied and garbage collected seems a bit off to me (I'm also debugging array-based problems in Spelunky).
But, yes, basic array usage works just dandy.
-
Do you have any ideas on implementing array length sorlok? I was wanting to add some like sprite_getpixels and surface_getpixels or even d3d_model_vertices(var vertices[]) functions that return an array to avoid multiple bindings for each pixel. Without JDI supporting collections in EDL yet and me not wanting the functions to rely on the data structure extension, we are left with returning arrays. But they are unusable if the user can not get the array dimensions with the Studio function.
-
I never knew arrays were broken they always worked for me. :D
-
Do you have any ideas on implementing array length sorlok? I was wanting to add some like sprite_getpixels and surface_getpixels or even d3d_model_vertices(var vertices[]) functions that return an array to avoid multiple bindings for each pixel. Without JDI supporting collections in EDL yet and me not wanting the functions to rely on the data structure extension, we are left with returning arrays. But they are unusable if the user can not get the array dimensions with the Studio function.
I can probably figure it out. I'd like to remove the "placement new" that Josh put in first, because it I find it confusing (and he said I could). At that point, it's just a matter of fiddling around with the lua_table struct. So, yep, I'll give it a shot.
I never knew arrays were broken they always worked for me. :D
Another satisfied customer! :D
-
Another satisfied customer! :D
If I had the authority, I'd double your salary sorlok. If you could fix arrays and give me the array length, I would be very happy and implement a lot of powerful functions that would completely remove the need for even dealing with buffers to read surfaces, I honestly don't know why YYG always has to overcomplicate things too.
-
I honestly don't know why YYG always has to overcomplicate things too.
Well if that were not the case maybe ENIGMA would never have been born :D
@Sorlok: You hear that ? Double the salary, now that is something you cannot resist :D
-
Var arrays have always worked as far as I know. Like this:
var arr;
arr[0] = 69;
Or just this:
arr[255] = 69;
What hasn't worked is this:
local int arr[256];
arr[2] = 10;
And that is been a problem for a few years for me, as data structures and var arrays are A LOT slower than a regular C++ array. Another thing we could do is implement STL containers. But for that we need access to classes, which sadly don't work. I'm still waiting on that new parser Josh.... though seeing how the old one is band-aided all the time, it seems the development on the new one has slowed.
-
Oh ok thanks for refreshing my memory Harri, indeed....I am used to the C++ arrays, I remembered we could not use those in ENIGMA sadly..... Imagine if we could though, would this require a massive change ? Sorlok ???
-
Oh ok thanks for refreshing my memory Harri, indeed....I am used to the C++ arrays, I remembered we could not use those in ENIGMA sadly..... Imagine if we could though, would this require a massive change ? Sorlok ???
For now I'm looking into the array length questions.
Local primitive arrays shouldn't be too difficult, but reclaiming the memory when it becomes unused is a little trickier.
Does GM:S offer "local int arr[255]"? I'm not familiar with the syntax, but then again most of my work is with GM 5.
-
No, GM doesn't have any types. ENIGMA has types. To create a local variable with a type you have to have "local" in front of it. So this:
a = 10; //This is variant local for the instance
var a = 10; //This is temporary variant for the script
int a = 10; //This is a temporary integer for the script
local int a = 10; //This is an integer local for the instance
-
No, GM doesn't have any types.
In fact i forgot this ! :D This means arrays don't need fixing, still it would be cool to add length functions, even if it's not mandatory.
-
I've got a work-in-progress for array lengths:
https://github.com/sorlok/enigma-dev/compare/enigma-dev:master...sorlok:array_fix
This works for 1D arrays, but is still broken for 2D arrays (due to some minor storage details). Also, array copying and memory access doesn't yet work. And printing arrays (string(a)) isn't in there yet. So it's not ready to merge yet.
-
Hahahah, that's amazing sorlok! You're my hero! (Y)
-
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
-
Sorlok you're amazing!!! (Y)
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
-
Thanks for testing this! I've updated the pull request with the fixes you requested.
-
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! (Y)
(http://www.wpclipart.com/holiday/party/party_balloons.png)
You can get these changes by using git-bash to pull from master. I will updating the Portable ZIP in a few days.
-
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.
-
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!
-
You are welcome Harri, and it looks like that is the next thing to fix while I am in here.
int d[5][5];
d[5][5] = 3;
show_message(string(d[5][5]));
Gives me...
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
int d[5][5][5];
d[5][5][5] = 4;
show_message(string(d[5][5][5]));
Will now properly parse into the following.
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