File Read/Write &/or Exit/Resume (in Simulators)

Platypus

Hi, guys.

If I run the Gideros sample app called "Application Lifecycle" in the desktop Gideros Player, it runs smoothly. If I then click the Gideros Player's "stop" button, the app exits smoothly. However, if I then rerun the app, it crashes with the error:

"attempt to concatenate upvalue 'frame' (a nil value)"

Sometimes it even crashes the Gideros Player.

Why is that?

Platypus

(Ahem)

OZApps

comment the line loadState() (should be line 81 in the project) and it runs perfectly fine. The problem lies in the application trying to read the previous state from file on the device, for some reason the frame is saved as nil and that causes the error. The fix is to change that line (should be 61) to

frame = file:read("*number") or 0

this is something that is very easy to implement in Lua, setting default values and not many use it. It should be used to avoid such errors.

Platypus

Thanks very much, @OZApps.

I believe that writing/loading files should work properly in the simulator (the desktop Gideros Player) too. I wish it did.

Is there any chance this problem (files not being written/read properly) would occur on handheld devices as well?

OZApps

The data is saved to the file on two ocassions, once onExit and once onSuspend. It is never saved to file, so when the data is tried to be loaded, the frames is nil as it never had any data in the first place and it overwrites the variable frame with a nil which causes the error. Hence we need the or 0 to ensure that the default value set is 0 in case of nil.

On the device, you would have triggered the onSuspend or the onExit which would have saved some data for the frames and hence would not have the possibility of an error in comparison.

I guess that the sample should have the "or 0" added to make it more robust. @atilim/@ar2rsawseen ...

Platypus

I agree.

What concerns me is that "onExit" is indeed properly triggered in the desktop Gideros Player when I click the "stop" icon, and "applicationExit" is printed, but "frame" is still "nil" when I restart the app* - even if I quit both the Gideros Player and Gideros Studio and restart them.

[*If I implement the excellent failsafe you (@OZApps) suggested, "frame" always loads as zero (because it was "nil"); whereas the button starts (as it should) in "resume" mode.]

Either way, the app does not work as an example of how to save data.

It also crashes the Gideros Player four times out of five.

@Atilim? @Ar2rsawseen? et al.?

Cheers, guys.
Platypus

ar2rsawseen

@Platypus I can't seem to reproduce it, everything is saved and works even without @OZApps fix.
Maybe you have some sort of restriction, that it create empty file, but can't read values from it, or something like that

Platypus

@Ar2rsawseen,

Thank you very much for checking. Perhaps it only happens on Mac computers. @Atilim?

ar2rsawseen

Maybe there were specific steps to reproduce it?
Will try to test more

Platypus

Nope. It happens all the time. I turn my computer on, open Gideros Studio, open "Application Lifecycle", open the Gideros Player, click the Gideros Player's "start" icon, click the in-app "Pause"/"Resume" button a few times, click the Gideros Player's "stop" icon, ensure that "applicationExit" is printed, click the Gideros Player's "start" icon again => CRASH!

I am pretty sure it only happens on Mac.

Platypus

ARRRRGGH! This is getting so frustrating!

The truth is, I've been trying to implement this in my app for over a week now, and it never works, no matter what method I try. I think it is a bug in the Mac version of the Gideros Player. Files are not being saved.

All I want to do is bookmark the user's page in my e-book.

When the app starts:

pageNumber = io.read() or 0 --Thanks to <a href="http://forum.giderosmobile.com/profile/OZApps" rel="nofollow">@OZApps</a>!

Then, each time the user turns the page:

io.write(pageNumber)

ar2rsawseen

@Platypus I will get back home in couple of hours and try it on my Mac

Platypus

Thanks a lot, bud. I really appreciate it.

ar2rsawseen

Yes, it seems that you are right, it produces the error on my Mac with Mountain Lion on it. But works on Android, Ipod, Ipad and Windows, so it is save to implement it in the app
And I will notify @atilim about the issue

Platypus

@Ar2rsawseen,
Thanks, mate.

OZApps

@ar2r, just wondering what does the rt and wt stand for? I did not come across the t in the Lua API or I might have missed something.

The problem on the Mac seems like a timing issue where the data written is unreliable. Insert a couple of print statements, there is some data saved (still not correct)

ar2rsawseen

@OZApps have no idea, I haven't written a single book about Lua, so don't ask me
But yes you are right, these are not in Lua docs, so only @atilim could answer that. @OZApps you experience same issue on your Mac? If values changed to proper r and w values, does the problem persist?

OZApps

@ar2r, ... tsk tsk tsk...

I tried to remove the t and run, the problem still persisted, I tried to read the data using '*n' instead of '*number' and at times I could read a number, with the '*number' I would get 'nan' most of the times. There were definitely some timing issues which resulted in saving or not saving the data to file. Though the data stored to the file was different than the value stored in frame.

In my opinion, I would generally have the data stored per line rather than continuous unless it was in binary format 'b'. That way I can read line1 for the frame, ine2 for the paused, etc.

and lastly the fix was simply adding the optional default value to the variable by using 'or 0' fixes a whole lot of things.

Te question that still remains and kind of related with @MrMells questions earlier, is there something related with file io that makes Gideros weak in the knees? In this case it crashes and makes the player unstable (could be a Gideros-Mac related issue).

ar2rsawseen

@OZApps honestly don't know, but @atilim is already aware of the issue

Platypus

ARRRRGGH! This is getting so frustrating!

The truth is, I've been trying to implement this in my app for over a week now, and it never works, no matter what method I try. I think it is a bug in the Mac version of the Gideros Player. Files are not being saved.

All I want to do is bookmark the user's page in my e-book.

When the app starts:

pageNumber = io.read() or 0 --Thanks to <a href="http://forum.giderosmobile.com/profile/OZApps" rel="nofollow">@OZApps</a>!

Then, each time the user turns the page:

io.write(pageNumber)

@Atilim, how soon can you fix this?

Platypus

@Atilim, how soon can you fix this?

A) Within one week.
Within one month.
C) Within one year.
D) Within one decade.

@Atilim, please type one character (A, B, C or D) and click "Post Comment".
That would be really helpful. Thanks.

Platypus

Not A, then?

atilim

Hi,

Sorry for late reply. Currently, I can produce it on my Mac and trying to understand the exact reason behind. I'll be fixed with the next release therefore the answer is between A and B

Scouser

Woohoo @atilim has just told us that the next release will be before 2nd week in July

atilim

oh yes. sorry for keeping you wait so long.

Scouser

I can only assume that by next release you actually mean v2012.09.11 , not v2013.06.01

atilim

yes. unfortunately it's 2012.09.11.

and I've fixed the bug. it's all related to file write layer.

Scouser

@Platypus will be happy

Platypus

Thank you, @Atilim.

To any future readers of this thread:
If you want to employ an alternative method, the following tutorial by @WauloK is very helpful.
http://bluebilby.com/2013/05/04/gideros-mobile-tutorial-loading-and-saving-data/#codesyntax_2

Platypus

By the way, @Atilim, I should probably let you know that running the "Application Lifecycle" project (and my own similar project) inserted some kind of ongoing crashing problem into my desktop Gideros Player. After running those projects, the player could not shut down ("Quit") without crashing (no matter how many completely different projects I had run since, and no matter how many times I restarted my computer). The "io.read" and "io.write" commands didn't save or load data when the app was run in the Xcode simulator either.

However, the crashing stopped after I ran a few projects using @WauloK's method. It not only miraculously repaired the Gideros Player's crashing problem, it also worked as a method of saving and loading data - both in the Gideros Player and the Xcode simulator.

Platypus

In the meantime, instead of this code:

When the app starts:

pageNumber = io.read() or 0 --Thanks to <a href="http://forum.giderosmobile.com/profile/OZApps" rel="nofollow">@OZApps</a>!

Then, each time the user turns the page:

io.write(pageNumber)

...I have been using the following code:

When the app starts:

local fileUnderstander = io.open("|D|worthRemembering.txt","r+")   if not fileUnderstander then pageNumber = 0 else pageNumber=fileUnderstander:read("*number") fileUnderstander:close() end

Then, each time the user turns the page:

local fileScribe=io.open("|D|worthRemembering.txt","w+") fileScribe:write(pageNumber .. "\n") fileScribe:close()

It works perfectly, but the app seems to run sluggishly now. It was so snappy and responsive before. I'm pretty sure I'm not imagining it.