"troubles" moving from 2016.06 to 2016.08

pie · August 2016

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 · August 2016

Can you print `shape` content before crush?

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

pie · August 2016

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 · August 2016

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

pie · August 2016

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 · August 2016

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 · August 2016

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

hgy29 · August 2016

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

n1cke · August 2016

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

pie · August 2016

@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 · August 2016

> 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 · August 2016

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

pie · August 2016

Allright, I will wait
Thank you

antix · August 2016

@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 · August 2016

@pie: first test: Lua without int64 lib.

pie · August 2016

@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 · August 2016

@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 · August 2016

Test 2: default type metatable removed from all tables.

pie · August 2016

@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 · August 2016

@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 · August 2016

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 · August 2016

@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 · August 2016

@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 · August 2016

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

n1cke · August 2016

@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 · August 2016

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 · August 2016

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 · August 2016

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

jdbc · August 2016

@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 · August 2016

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 · August 2016

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

Howdy, Stranger!

Categories

In this Discussion

Top Posters

"troubles" moving from 2016.06 to 2016.08

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

"troubles" moving from 2016.06 to 2016.08

Comments