"troubles" moving from 2016.06 to 2016.08

pie

Hi, I just upgraded to 2016.08 and I can no longer run my projects - which run fine on 2016.04 and 2016.06 ( on this release I could test them on android player only because I had the openGL bug on my windows player):

The first project crashes at a shape:clear() method, stating that this method doesn't exist.
The other one crashes in GTween, here:

gtween.lua:229: attempt to call field 'ease' (a table value)

I checked shape:clear() in the example project alone and it still works, and GTween never complained about ease
Maybe it has to do with some changed loading time of Gideros? Both crashes are just after the "uploading finished" message.
Do you have any suggestion to investigate/avoid the problem?

Thank you

n1cke

Can you print `shape` content before crush?

for k,v in pairs(shape) do print(k,v) end

pie

yes, it is the list of the functions that compose my "balloon class":

update function: 06353A44 init function: 06353690 drawCustomShape function: 06353A2C getSizedBalloon function: 063535A0 quadraticCurveTo function: 063539D4 getLateralSizedBalloon function: 063539BC getLabelBalloon function: 063536A8 getRoundedLabel function: 06353570 getContainer function: 06353588 super table: 063362D0 __new function: 06350D5C __index table: 063509F4 new function: 06353674

Inside this class I get my shape through drawCustomShape() like this:

local function drawCustomShape(x,y,z) local shape = Shape.new.... --shape stuff   return shape   end   self.balloon = drawCustomShape(...)   --then on update I call self.balloon:clear() --and here it breaks

thank you

n1cke

Can you show content of `shape.__index` before `return shape` in `drawCustomShape`?
Not `shape` but `shape.__index`, sorry.

pie

Actually I was wrong, I'm sorry: it was breaking at the beginning of drawCustomShape, where I had a redundancy of self.balloon:clear() I forgot about, that never gave problems until today
I presume that it was trying to remove the shape before it was created (this means that gideros is faster than before because I was checking if self.balloon existed to call it - and in previous releases self.balloon was not existing, otherwise I would have had the same error).

Commenting it out lead me to an error similar to the other project: in GTween

gtween.lua:225: attempt to call field 'ease' (a table value)

so I tried printing out "ease" values and I got

gtween.lua:225: bad argument #1 to 'pairs' (table expected, got function)

Meanwhile, my gideros player went blank and there is no way to reset it (similar to the behaviour I had in 2016.06, but without crash, and the output window works ) I have to reboot now to see if it comes back. [edit: player working again after reboot]

thank you

pie

I'm still trying to understand what could cause this gtween issue, and I have other projects that suffer from "never seen before (2016.08) errors".
One thing all my crashing projects have in common is GiderosCodingEasy by @ar2rsawseen: since it is changing a lot of parameters/overriding methods etc.. and I believe it's a bit outdated - could there be something that I should look for inside it that could cause issues?
I'm asking because I noticed that in one project where I was not doing an extensive use of gideroscodingeasy it was enough to extract a couple of helper functions I needed and exclude the file from execution to see my project running again.

Thank you

ar2rsawseen

Honestly for now have no idea, could be related to this:
http://giderosmobile.com/forum/discussion/comment/49610#Comment_49610

hgy29

Could be yes, lua as evolved a lot in Gideros 2016.8, maybe @n1cke have some idea ?

n1cke

Easy to test: replace your "lua.dll" (2016.08) from Gideros folder with this "lua.dll" (2016.06).

pie

@n1cke @hgy29 @ar2sawseen
every project that before was crashing is now working (with lua.dll provided by n1cke)! =D>
Thank you, that's really good news to me

Now, what should I do? I suppose that this is just a workaround.. maybe I can leave giderosCodingEasy if I extract the helper functions that I already use.. or is there something better to do to update it for everyone else?

Thanks

n1cke

> Now, what should I do?
You can help to fix that error. I will try to remove some patches, recompile lua and you will test it.

n1cke

Or you can give me that piece of your project with error, if you trust me. This will be much faster.

pie

Allright, I will wait
Thank you

antix

@pie or just hack y9our project down to include just a portion that has the issue. Maybe even make a quick new project that shows the issue and send it to @n1cke

n1cke

@pie: first test: Lua without int64 lib.

pie

@n1cke first test failed,
I'll try to reproduce the error in a smaller project, actually it happens on "big" projects but these are still work in progress and are plenty of garbage I could send you one of those but I am ashamed of their code structure..

n1cke

@pie: for now just wait for second test, I am trying to remove type metatables powerpatch.
> I am ashamed of their code structure..
Why? You said this is WIP anyway

n1cke

Test 2: default type metatable removed from all tables.

pie

@n1cke >- That's it! You're great! Thanks!
What feature are we missing exactly?

p.s. my code is my learning book - I don't have basics in coding, and everything I learned comes from this forum and some reading around.
I love gideros because my code works despite my lack of skills - but when I see arturs'libs or your textArea I am amazed by tidiness, and I feel like nobody should ever see my code..

n1cke

@pie Thanks for testing!
We are missing almost nothing: table type metatable was just syntax sugar for usual tables (instead of table.insert(t, x) you could write t:insert(x)). And int64 library is mostly useful for plugins I think so plugin developers can easily add it to their plugins themselves.

pie

I wish we'd have more plugins developers here who could miss int64 library..
If I create an empty project now, would I build a 2016.08 patched android player?

thank you again

n1cke

@pie: you need patched `liblua.so` for Android. You can try to replace your `liblua.so` in`lib/armeabi-v7a/` with attached file and build patched Android Player in Android Studio or Eclipse. I know little about Android so maybe it will not work at all.

pie

@n1cke thanks, it was worth a try
there are several liblua.so, I replaced
gideros/sdk/lib/android and the one under Android Template/libs
I'm sorry I used a wrong release to export, I'm a bit tired.. it crashed complaining about it can't load libgnustl_shared.so

ar2rsawseen

@n1cke so I think mt power patch was the reason right?
so int64 can go back into release?

n1cke

@ar2rsawseen: yes, small part of mt power patch was broken (maybe for Gideros only) which I removed. int64 library relies on mt patch too but it should not break things. However I have changed my mind about int64: if somebody needs it then he/she can include that one file into his/her plugin so I have removed it too. But if you think it is useful as first-class Lua library then I can push it back.

ar2rsawseen

As I remember there were talks on forum about storing larger numbers in lua for Gideros, so if it does not break anything I think yes we should have it

jdbc

I got the same problem... removing 2016.08 and installing previous version. But I will try use MovieClip instead of gtween in my games.

pie

@jdbc did you try replacing lua.dll with this one?
http://giderosmobile.com/forum/discussion/comment/49635#Comment_49635

jdbc

@jdbc did you try replacing lua.dll with this one?
http://giderosmobile.com/forum/discussion/comment/49635#Comment_49635

I have MacOS, but I have replace lua file with 201606 and still does not work.

john26

We have now withdrawn the 2016.8 release due to the serious errors being shown in this thread. Thanks for letting us know. We attempted to make some changes to the Lua language (actually the code was downloaded from lua-users.org) but succeeded in breaking Lua such that correct Lua code will not run in, admittedly, fairly specific circumstances. Clearly this is extremely serious and we have withdrawn 2016.8. We will release its replacement 2016.8.1 in a few days.

n1cke

@pie: please also test this `lua.dll` from upcoming 2016.8.1 in your project.