Ported app silently fails to save on Linux x64

[richmond62]

One thing you have to remember is that a standalone cannot save itself!

So, what a standalone can do is either save to a substack or write to some sort
of external file such as a tab or comma delimited text file.

Is your Mum using the thing you wrote her, like Hypercard, within the
IDE as a stack or series of stacks, or as a 64 bit Linux standalone?

[PhilHudson]

It's all there in the preceding posts. Forget HyperCard; I mentioned it to give a sense of the visual style and index-card metaphor I recalled from HC. That's where the HC influence ends. I only mentioned it so old HC hands would have a clear image of what I had developed (in LiveCode, 100%, start to finish).

I developed on a Mac, and originally deployed on Windows, where it worked flawlessly to spec. This is a crucial point to bear in mind: the app works, correctly and to spec, and did so for many months. That same machine then had Windows wiped and Linux 64 installed, and I re-built (in LiveCode, 100%, on the same Mac used for original development) the app for L64, believing I was doing it identically.

[richmond62]

Why don't you run off a 32 bit Linux standalone, ring up my Dad and ask if you can
try it out for 15 minutes on his laptop?

Another thing you might like to consider is installing the 64 bit version of Livecode on your
Mum's computer and building the standalone there . . .

I have fallen foul of this type of thing before. For instance, I have made Mac standalones
on Linux which have refused to work on Mac. When I have used exactly the same source stack
to build a Mac standalone on a Mac the thing has worked.

As a result, whenever I build a new version of my apps I test run them on various manky old
computers I have lying around (Mac G5 - Mac 10.4 and 10.5, Mac G3 Mac 9.2.2, Windows XP) and various other systems
I have running inside VMWare on my Linux tank (Mac Intel 10.8, Windows 7, Windows 8,).

One of the advantages of living in Bulgaria is that one can pick up manky old computers
for about 12 quid!

Presumably ??? You are the son of Derek Hudson who my father says used to work in a bank in Botswana.

If you want you can send me your source stack via email [richmondmathewson@gmail.com] or via dropBox
and I can try building you a 64 bit Linux standalone on Ubuntu 32 bit, as well as a 32 bit one, and fiddle around
with it a bit.

Interested to know which church in Wincanton actually runs to a library - quite impressed.

[FourthWorld]

Do on Linux what works on Windows and it'll work on Linux.
...
Currently we express our build intentions with the settings in the Standalone Builder.

I take the reproof. I thought I had done exactly the same, but I guess I must have toggled something. Now I just have to locate what it was. Thanks all for helping me see my own unforced error, since that looks increasingly like the most likely explanation.

I would focus on the Stacks tab in the Standalone Builder, looking at the settings for the Windows build that works well for you and the Linux one which doesn't. If you don't see the difference immediately feel free to post here and we'll see what we can do to help make one like the other.

As for "reproof", my apologies. I didn't intend that to read like that. On the contrary, I included "currently" because I like to believe there's always an easier way. While we may not have found a bug here, we might have the roots of something that could become an enhancement request.

Issues related to standalones not saving to themselves come up frequently.

On a certain level it doesn't matter so much that no other apps save to themselves, or that the User Guide section on the Standalone Builder includes a large brightly-colored warning box describing this along with solutions for it.

What does matter, at least from a usability standpoint, is that we can construct stacks during development that work one way, and then find the behavior is different when we build a standalone from that stack.

In a perfect world there would be a simple solution, but our world isn't perfect and developing software is inherently complex. This complexity is compounded by LiveCode's flexibility and the range of needs from the many different people who use it.

For example, Android is a wonderfully usable system for the billion end-users who enjoy it, but the Android SDK developers work with is a usability nightmare, somewhat necessarily so given the broad needs of its audience and the scope of things people do with it, so different from the end-user software produced with it.

We've discussed possible options for minimizing confusion on this standalone, here in the forums, on the use-livecode mailing list, in our local user group, and elsewhere. Lots of good ideas, but we've not yet found one which both provides the guidance which would make this confusion go away while still preserving the flexibility that makes LiveCode so powerfully useful for so many different things.

So for now I'll say the SB settings is how we handle this "currently", and optimistically leave the door open to exploring possible options for the future that make things even clearer.

[PhilHudson]

Presumably ??? You are the son of Derek Hudson who my father says used to work in a bank in Botswana.

Yes.

If you want you can send me your source stack via email or via dropBox
and I can try building you a 64 bit Linux standalone on Ubuntu 32 bit, as well as a 32 bit one, and fiddle around
with it a bit.

Very kind, but I have a pretty good assortment of hardware and OSes to hand. I'm writing this on another 64-bit Linux system; there's a 32-bit one handy if I swivel my chair around. The Mac is downstairs if I need it.

FWIW, it's several years since I've encountered or even heard of a 32/64-bit issue on Linux, apart from the few closed-source apps that ship binary-only and insist on 32-bit libs even on 64-bit machines. Pretty much everything in the Debian testing repos has ironed out all such bugs; 64-bit is now rock-solid stable and glitch-free. It was hell while it lasted, but it's over now and it's been over for quite a while. I'm not inclined to think that this is such an issue.

Interested to know which church in Wincanton actually runs to a library - quite impressed.

Quakers, so not technically a "church", rather a "meeting".

[PhilHudson]

So for now I'll say the SB settings is how we handle this "currently", and optimistically leave the door open to exploring possible options for the future that make things even clearer.

I appreciate your further exposition of the issues around the standalone builder. I'll try to get well-enough informed to make a useful contribution; I have some vague ideas ATM around static analysis and dependency graphs.

[FourthWorld]

I have some vague ideas ATM around static analysis and dependency graphs.

I'm glad to hear you say that. Static analysis is an area ripe for exploration with LiveCode. I have a few modest tools I'll be sharing soon (read "in the coming months, client work gets priority" <g>), and they'll be released under GPL license to encourage sharing and expansion. When I look at some of the SA tools for languages like VB I think we have a wide world of opportunities for all sorts of useful things. And if we can come up with something that also benefits this standalone issue, even better.

[mwieder]

Wally- what version of LiveCode are you using to cross-compile the linux binaries?
If you're not using a 7.x series then you'll only be generating 32-bit binaries (not that this should have any bearing on the monolithic structure you're seeing).
I just created a linux binary from OSX and it seems to have come out fine (multiple stacks are intact).

[PhilHudson]

(It's Phil, not Wally)

I've just regenerated the app in both 64- and 32-bit versions for Linux using the original known-good Windows deployed version. Both now create a similar-looking directory tree, with one .livecode and one .rev stack, but *BOTH* fail to persist new cards when run. This is *really* annoying, and as before, absolutely zero useful diagnostic output anywhere to explain how and why my changes are being discarded.

At this point I'm getting very close to abandoning LiveCode and trying some other method.

One last go-round:

1. Just to confirm: is there at least one participant in this thread who has an existence proof of a working example of a correctly-working new-card-persisting standalone app working on Linux?

2. Can anyone think of anything that might make a previously successfully persisting standalone app on any platform *stop* persisting, regardless of platform?

[PhilHudson]

Wally- what version of LiveCode are you using to cross-compile the linux binaries?
If you're not using a 7.x series then you'll only be generating 32-bit binaries (not that this should have any bearing on the monolithic structure you're seeing).
I just created a linux binary from OSX and it seems to have come out fine (multiple stacks are intact).

7.0.1 now, 7.0 originally.

[FourthWorld]

At this point I'm getting very close to abandoning LiveCode and trying some other method.

No executable made with any language can modify itself. This is a function of the OS itself, consistent across pretty much all modern OSes. You could write your app in Assembler but you still won't be able to get past this OS kernel security feature without also altering the kernel itself.

To help developers anticipate this OS feature and design for it, p299 of the LiveCode User Guide section on building standalones includes:

Note: A stack file directly attached to a standalone application cannot have changes saved to it. This stack is bound directly to the executable file that runs. The OS locks an executable file while it is running. If you want to save changes in your standalone application, split your stack up until multiple files. A common technique is to create a "splash screen" stack that contains a welcome screen and then loads the stacks that make up the rest of your application. These stacks are referenced as stackFiles on this pane in the standalone settings screen. It is thus possible to automatically update these component stacks, or to save changes to them. You may also want to consider creating preference files in the appropriate location on your end user's system (see the specialFolderPath function and query/setRegistry functions for more information).

All applications made with any language running on any OS always store persistent data external to the app executable file itself. This is commonly done in user-writable folders, such as can be found with LC's specialFolderPath function. The data may be a text file, a binary file, database file, or even a stack file. But in all cases, all data expected to persist between sessions must be stored outside of the executable file.

This tutorial by Sarah Reichelt may help with some tips on working with external data:
http://livecodejournal.com/tutorials/sa ... ution.html

One common method that can be helpful is to clone a stack from the standalone and set the clone's filename property to some location in user space, and then use the save command to write it to disk. There are many other options as well, but in all cases the data will have to be in a separate file from the executable.

One last go-round:

1. Just to confirm: is there at least one participant in this thread who has an existence proof of a working example of a correctly-working new-card-persisting standalone app working on Linux?

If it ever appeared possible the poster was mistaken, since no modern OS allows it.

2. Can anyone think of anything that might make a previously successfully persisting standalone app on any platform *stop* persisting, regardless of platform?

The earlier file listings given on p1 of this thread showed the Windows build using an external stack file. As I wrote earlier, do on Linux what works on Windows and it'll work on Linux.

[FourthWorld]

Tip re. this thread title:

It turns out that the "save" command doesn't fail silently when attempting to use it on a stack within a standalone.

Most error conditions in LiveCode are reported to the executing handler in "the result", which will generally be empty if no error occurred. If we check the value of "the result" immediately after attempting a "save" command in a standalone it reports:

can't save into standalone

You can verify this by building a standalone with one button and one field, with this in the button script:

Code: Select all

on mouseUp
   save this stack
   put the result into fld 1
end mouseUp

[PhilHudson]

At this point I'm getting very close to abandoning LiveCode and trying some other method.

No executable made with any language can modify itself. This is a function of the OS itself, consistent across pretty much all modern OSes. You could write your app in Assembler but you still won't be able to get past this OS kernel security feature without also altering the kernel itself.

Yes. If you notice, I flagged this up myself right at the beginning of this thread.

To help developers anticipate this OS feature and design for it, p299 of the LiveCode User Guide section on building standalones includes:

Note: A stack file directly attached to a standalone application cannot have changes saved to it. This stack is bound directly to the executable file that runs. The OS locks an executable file while it is running. If you want to save changes in your standalone application, split your stack up until multiple files. A common technique is to create a "splash screen" stack that contains a welcome screen and then loads the stacks that make up the rest of your application. These stacks are referenced as stackFiles on this pane in the standalone settings screen. It is thus possible to automatically update these component stacks, or to save changes to them. You may also want to consider creating preference files in the appropriate location on your end user's system (see the specialFolderPath function and query/setRegistry functions for more information).

Indeed. I read that and implemented its recommendation in my app, which I then successfully deployed to Windows and which worked for many months, silently accepting and persisting changes. It was only when I came to re-deploy exactly the same app to Linux that this issue arose.

All applications made with any language running on any OS always store persistent data external to the app executable file itself. This is commonly done in user-writable folders, such as can be found with LC's specialFolderPath function. The data may be a text file, a binary file, database file, or even a stack file. But in all cases, all data expected to persist between sessions must be stored outside of the executable file.

This tutorial by Sarah Reichelt may help with some tips on working with external data:
http://livecodejournal.com/tutorials/sa ... ution.html

One common method that can be helpful is to clone a stack from the standalone and set the clone's filename property to some location in user space, and then use the save command to write it to disk. There are many other options as well, but in all cases the data will have to be in a separate file from the executable.

I think I've made it clear by now that I understand this. The breach of the principle of least astonishment came when I found that LiveCode had generated an all-in-one standalone binary for Linux from a project for which it had previously correctly generated a two-stack deployment for Windows, for what reason I know not. I do not even see an option that would permit that in the SA Builder, so how it came about is a mystery to me. No doubt it was something I did inadvertently, but what that might be is beyond me, and not my main interest at this point, since as I posted earlier, even today's new, apparently "correct", two-stack deployment also fails to persist changes.

One last go-round:

1. Just to confirm: is there at least one participant in this thread who has an existence proof of a working example of a correctly-working new-card-persisting standalone app working on Linux?

If it ever appeared possible the poster was mistaken, since no modern OS allows it.

I am unable to parse that last sentence. Perhaps my question did not make it clear that I understood and expected that such a working example must be two-stack deployment, but I did. I really did. Honestly.

2. Can anyone think of anything that might make a previously successfully persisting standalone app on any platform *stop* persisting, regardless of platform?

The earlier file listings given on p1 of this thread showed the Windows build using an external stack file. As I wrote earlier, do on Linux what works on Windows and it'll work on Linux.

[/quote]

Please re-read carefully my post of 15:02 today. What you recommend here is exactly what I did, and the problem still recurs: my changes are discarded silently, even with a two-stack deployment.

[SparkOut]

I don't live in the boondocks, but in Kent, which might as well be in Bulgaria for the use the distance is, but I do have Linux Mint in 32 and 64 bit flavours. I could happily test your project and see if there is any more light that can be discovered about what is going wrong. If you would like me to and don't mind making it available, drop a note and we can work out how to send it.

[FourthWorld]

No executable made with any language can modify itself. This is a function of the OS itself, consistent across pretty much all modern OSes. You could write your app in Assembler but you still won't be able to get past this OS kernel security feature without also altering the kernel itself.

Yes. If you notice, I flagged this up myself right at the beginning of this thread.

I did, and indeed it was because you had seemed to already have that understanding that I was confused as to what exactly was being requested when you asked:

is there at least one participant in this thread who has an existence proof of a working example of a correctly-working new-card-persisting standalone app working on Linux?

It seems clear now that we can move past that altogether, and focus instead on the real question here:

How does your Windows app work while your Linux app doesn't?

Several suggestions have been made here about how to have savable stack files separate from the application, along with some hopeful tips on what to look for in the Standalone Builder settings which may help account for any differences between your Windows and Linux builds.

In all fairness, I'm not sure there's much more we can do without seeing the stack itself.

And even then, it would be ideal to also have a copy from which you successfully made your working Windows version.

Are you still able to generate a version for Windows that works as you expect?

If your Linux stack is now using a separate stack file, what is the value of "the result" immediately after you issue your "save" command?