Ported app silently fails to save on Linux x64

[PhilHudson]

I wrote a simple library stack for my mother to catalogue her church library. Since deploying to Linux Mint Debian Edition 64-bit it silently fails to save new cards added to the stack. In all other respects it seems to continue to work correctly, including allowing new cards to be created and sorted into place by my newCard-intercepting handler; they're just never persisted to disk, AFAICT. New cards behave and are accessible as expected until quit; on relaunch, they are gone. File ownership and permissions on the deployed 64-bit all-in-one binary seem correct: <username> <usernamegroup> 755.

I wrote it on a Mac and originally deployed it successfully to a Windows PC -- hugely impressed, by the way. How cool is that? Since then I have deployed the same app, with no coding or config changes, to the same physical PC now running Linux Mint Debian Edition 64-bit. Porting to Linux seemed at first sight to be just as impressive and even quicker, now that I knew what to expect.

The app uses native stack-based persistence, that is, no external database, with import and export supported via delimited text files. (This may give me a workaround for my issue, but I'd still like to know the solution). It's a simple card-index-style one-stack flat database, or rather it would have been one stack in HyperCard or SuperCard, where I gained my previous xCard experience; it's actually more than one stack, but AIUI that's just to accommodate the LiveCode style/requirement of separating the immutable UI-entrypoint stack from the mutable data. No doubt that's familiar to people on this forum. The size of the collection is on the order of one hundred books and it is not expected to grow much larger than that. The app provides classic Hypercard-style icon buttons for first-prev-next-last, add, delete, find and print, plus two textual buttons for delimited-text import and export, and automatic sorting as mentioned. Five fields. Plain and simple, nothing fancy; old hands can probably picture more or less exactly what it looks like.

I'm hoping this is a well-known issue that somebody has the solution for at their fingertips. Otherwise, I really need a pointer to where to start looking for debug info. I see nothing that seems to come from LiveCode in any log files in the Gnu/Linux standard /var/log directory. Thanks in advance for any help.

[SparkOut]

Complete guess here..
But I have been tripped by mint with regard to the home path. Perhaps when you start the app it is loading the data stack from a location relative to the main stack, and when you are saving the data stack it is saved in the root of the home folder rather than the documents folder?

[PhilHudson]

SparkOut: nice tip, thanks, but it didn't pan out.

Got me thinking though: I'm very suspicious about the all-in-one binary having no side files. I just checked the archived Windows deployment, and that consisted of the following:

Code: Select all

-rwxrwxrwx 2  428373 Sep 24  2013 CatalogueData.livecode*
drwxrwxrwx 1       0 Sep 24  2013 Externals/
-rwxrwxrwx 2  293098 Sep 24  2013 Wincanton LM Library Catalogue.rev*
-rwxrwxrwx 2 2301952 Sep 24  2013 Wincanton LM Library.exe*

Whereas the current Linux deployment consists of this:

Code: Select all

drwxr-xr-x 2     4096 Nov 23 14:51 Externals/
-rwxr-xr-x 1 11062592 Nov 23 14:51 Wincanton LM Library Catalogue data*

Which implies that the binary is self-modifying, a big no-no in most OSes. That can't be right.

Anyone got a cross-developed stack working on Linux 64 bit and able to compare notes?

[PhilHudson]

Another data point: As far as I can tell, nothing has been written to the . runrev directory since installation .

Code: Select all

 . runrev / :
total 20
drwxr-xr-x 2 4096 Nov 23 14:38 cache /
drwxr-xr-x 2 4096 Nov 23 14:38 crashlogs /
drwxr-xr-x 2 4096 Nov 23 14:38 licenses /
drwxr-xr-x 2 4096 Nov 23 14:38 logs /
drwxr-xr-x 2 4096 Nov 23 14:51 preferences /

 . runrev / cache :
total 0

 . runrev / crashlogs :
total 0

 . runrev / licenses :
total 4
-rwxr-xr-x 1 136 Nov 23 14:39 livecode-community-7_0_0-10018 . lclk*
-rwxr-xr-x 1   0 Nov 23 14:38 livecode-firstrun . lcf*

 . runrev / logs :
total 24
-rw-r--r-- 1 21953 Nov 23 14:39 livecode_tools_log . txt

 . runrev / preferences :
total 28
-rwxr-xr-x 1 26147 Nov 23 14:51 livecode7 . rev*

(Spaces added around / and : and . characters to placate the forum's no-links rule)

[MaxV]

It seems to me that you developed your program with another tool (hypercard or superCard) and now you are using livecode. Livecode changes the behaviour of some commands, so I'll start to check the code. I suggest you to read http://translate.google.com/translate?j ... nt_92.html and http://translate.google.com/translate?j ... nt_80.html
and start debugging.

[FourthWorld]

Which implies that the binary is self-modifying, a big no-no in most OSes. That can't be right.

Anyone got a cross-developed stack working on Linux 64 bit and able to compare notes?

I spend at least half my time in Ubuntu, but this seems mystifyingly platform-independent for the reason you noted: since no modern OS allows an executable to save to itself, how does your Windows version work?

Maybe you've changed the settings in the Standalone Builder so it's now including what used to be an external stack file?

[PhilHudson]

MaxV: You have jumped to a false conclusion. This is a project 100% originated and completed in LiveCode.

[PhilHudson]

FourthWorld: This sounds like it might be leading somewhere:

Maybe you've changed the settings in the Standalone Builder so it's now including what used to be an external stack file?

The thing is, I deliberately tried to avoid making any config changes other than saying I wanted to build for Linux now. Will check and see if that gives any joy. Thanks.

[PhilHudson]

since no modern OS allows an executable to save to itself, how does your Windows version work?

The listings above show that in the Windows deployment there was indeed an external data stack.

I think I may have uncovered a bug in the app builder. It should not be possible even accidentally to build an all-in-one standalone that is intended to be self-modifying. How might the build procedure/UI automatically prevent this happening?

[FourthWorld]

since no modern OS allows an executable to save to itself, how does your Windows version work?

The listings above show that in the Windows deployment there was indeed an external data stack.

Precisely. Do on Linux what works on Windows and it'll work on Linux.

It should not be possible even accidentally to build an all-in-one standalone that is intended to be self-modifying. How might the build procedure/UI automatically prevent this happening?

Sometimes we want to save data in stacks, other times we want to rely on the stacks we're using to be in the state we left them at build time in each new session.

So the question is: How do we express our intentions to LiveCode?

Currently we express our build intentions with the settings in the Standalone Builder.

[richmond62]

If you live in Wincanton, Somerset you might think of going round to see Donald Mathewson in Church street . . .

He has both a laptop that runs Xubuntu and a son who works with both Linux and Livecode

[PhilHudson]

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.

[PhilHudson]

If you live in Wincanton, Somerset you might think of going round to see Donald Mathewson in Church street . . .

He has both a laptop that runs Xubuntu and a son who works with both Linux and Livecode

What? Here in the boondocks? Great news! Thanks. Maybe it's time to start a LLUG.

Think I'll try and find some other way of contacting them first though.

[richmond62]

Well, boondock as boondocks go: Donald Mathewson can be reached at 01963 33563, and I am his son,
and I stay in Bulgaria; which makes Wincanton seem almost cosmopolitan

I really wonder why you decided to use a 64 bit version: no particular benefit unless you are doing
really high end stuff such as shifting video files while editing.

I have a couple of 64 bit machines on which I use 32 bit versions of Linux because, frankly, I'm far too lazy to
spend ages messing around getting things to behave themselves on 64 bit Linux: probably in 3 or 4 years I'll
move to 64 bit.

[PhilHudson]

I really wonder why you decided to use a 64 bit version

You credit me with too much consideration of the matter. If there was any thinking that went into it at all, it went: "64-bit machine, 64-bit distro, 64-bit libs installed by default, um, 64-bit then."

Thanks for your dad's contact number. I'll definitely be in touch.