Re: Quit Command corrupts standalone (stack called by standalone splash)

[J. Landman Gay via use-livecode]

On February 26, 2018 9:40:58 PM Richard Gaskin via use-livecode 
 wrote:



There are many ways that imagined scenario might for all I know be
accounted for in the way Dropbox is written.  But there may also be
other scenarios that can produce the same corrupted result that I
haven't thought of.


Just so Marty won't worry too much, Dropbox handles file conflicts:
https://www.dropbox.com/help/syncing-uploads/conflicted-copy

"If two people change the same file at the same time, Dropbox won't try to 
merge the changes. Instead, it will save the original file as well as a 
second version which has the same name but is appended with "conflicted 
copy," the name of the person or computer responsible, and the date the 
conflict occurred. By creating a conflicted file, Dropbox ensures that all 
changes are preserved and nobody will overwrite another person's hard work."


I've seen this happen. It's a pain trying to merge the changes if there are 
too many but nothing gets lost.


I've seen the occasional corrupted LC stack, most recently just last night, 
but it was an extreme edge case no one else is likely to encounter and I 
think I know what happened. The solution was "don't do that."


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Quit Command corrupts standalone (stack called by standalone splash)

[Mark Wieder via use-livecode]

On 02/26/2018 07:38 PM, Richard Gaskin via use-livecode wrote:


Consider this scenario with stack files, for example:

Mark writes a stack, then I open it, then you open it.  You and I are 
both making changes, and I save mine a few seconds before you save 
yours. In that scenario, what's on disk?


Keep in mind the Dropbox and Box are primarily single-user storage 
applications. I can, for instance, give read access to others, and if 
I'm feeling wild and crazy I can even give write access, but I have to 
go out of my way to do this. Normally I'm the only one who can write or 
even read the files in my folder, even though they're synced to multiple 
machines under my control.


Corruption is very interesting to me.  Lost data is usually explainable 
through simple multiuser workflow weaknesses, such as inadequate locking 
mechanisms.  But corruption in LC means something interrupted the write, 
or overwrote portions before the write was completed.  And since LC 
stacks files are written in a single pass, whatever caused it to corrupt 
was very efficient at it, as it had little time to do it in.


I *have* had corrupted LiveCode stacks before, and I can count them on 
two fingers of one hand. One of them was actually sitting in my Dropbox 
folder, so who knows what happened to it? But my favorite thing about 
Dropbox is that it stores earlier versions of your files, so I just 
reverted to an earlier copy of that stack and carried on.


--
 Mark Wieder
 ahsoftw...@gmail.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Quit Command corrupts standalone (stack called by standalone splash)

[Richard Gaskin via use-livecode]

Knapp Martin wrote:

> Thanks for the in-depth reply. Are there known issues with saving LC
> stacks to Dropbox? I was thinking of Roland's issue with corruption
> and Phil's suggested fix of watching the file with the tilde character
> before allowing a quit to complete. I have an app where users create
> documents (stacks) and saving them to Dropbox is a built-in option.

My hunch (read, "I'm likely wrong, wait for something more definitive 
from someone on the core team or Brian Milby, since he reads the engine 
source ) is that LC files are less prone to a wide range of 
disk-related issues by virtue of being written in a single pass.


HyperCard, FileMaker, SQLite, and others are read and written in pages, 
which works more reliably in some (SQLite) than others (no one misses 
HC's 504 errors ).  Moving stuff in and out of portions of a file 
that may not change much otherwise isn't necessarily brittle in itself 
(SQLite as a reputation for being enormously robust), but we can 
envision how larger SQLite files may confuse a syncing system that can 
only move chunks of data over a network so quickly.


Since LC files are, near as I recall, written fresh from beginning to 
end with each save command, the result is usually a cleaner file than 
with some paging systems.


And it's also faster to write everything in one pass than writing the 
same amount of data by moving back and forth throughout a file, so my 
hunch would be that LC stack files would likely be less prone to error 
when synced over Dropbox than SQLite files.


But by no means should this be taken as gospel, and certainly not as any 
indication that we should drop SQLite and use stack files instead. 
Different formats for different purposes.


And as Mark Wieder noted, some of the biggest challenges with syncing 
occur with multiple users accessing a given resource simultaneously.


Those are very real challenges, which may be why so many developers over 
the years keep writing their own sync mechanisms, with no single 
solution having emerged as the one-size-fits-all answer.


Consider this scenario with stack files, for example:

Mark writes a stack, then I open it, then you open it.  You and I are 
both making changes, and I save mine a few seconds before you save 
yours. In that scenario, what's on disk?


When I get back to work on the file tomorrow, I'll likely be 
disappointed to find that everything I'd done is now gone.  I can see 
only your changes, since yours were the last saved and when you saved 
you hadn't yet updated to have a copy with my changes.  So after Dropbox 
faithfully performs everything we ask it to do, my changes are gone forever.


Write-locking can help with things like that, and that's a subject in 
itself.  At what level of granularity should we lock?  And before 
editing begins do we first compare what's in memory with what's in the 
data store to ensure what we're about to edit is the most recent copy? 
How do we handle conflicts, when one inevitably occurs?


So many ways to handle sync

> I have one customer who stores their stacks on a network server and
> a few times they've ended up with a corrupted stack.

Corruption is very interesting to me.  Lost data is usually explainable 
through simple multiuser workflow weaknesses, such as inadequate locking 
mechanisms.  But corruption in LC means something interrupted the write, 
or overwrote portions before the write was completed.  And since LC 
stacks files are written in a single pass, whatever caused it to corrupt 
was very efficient at it, as it had little time to do it in.


I can conceive of a possible scenario in which neither Dropbox nor LC 
has a bug per se at all, but which may account for corruption:


1. Your app issues a save command on a large stack.
2. Dropbox begins syncing the file to the server.
3. Your friend has the same file open on his machine.
4. On his machine, Dropbox notices the server has a newer version, and 
prepares to update his copy.

5. He starts a save in his stack.
6. Dropbox has written a portion of the stack from the server to his 
disk, but stopped when it noticed the file was being updated.
7. After your friend's save is done, the corrupted stack is then copied 
to the server, where it later propagates to your machine.

RESULT: everyone now has the same file, and it's broken.

I haven't studied the file system triggers and server monitoring that 
trigger reads and writes in Dropbox.  And if it's proprietary, chances 
are no one outside that company has either.


There are many ways that imagined scenario might for all I know be 
accounted for in the way Dropbox is written.  But there may also be 
other scenarios that can produce the same corrupted result that I 
haven't thought of.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.com

Re: Quit Command corrupts standalone (stack called by standalone splash)

[Mark Wieder via use-livecode]

On 02/26/2018 05:14 PM, Richard Gaskin via use-livecode wrote:

Knapp Martin wrote:

 > Richard, could you elaborate on the issues with Dropbox?

I first came across it in a search at Google for "dropbox sqlite", 
looking for tips on making the most of that relationship.  What I found 
was a long series of support forum and blog posts filled with horror 
stories of out of sync or corrupted DB files.


To counteract some of the FUD, storing a large multiuser database in the 
cloud with long sync times and no proper locking is just a bad idea in 
the first place. But unless you've got a particularly huge LiveCode 
stack, you're not going to see this kind of syncing problem. And 
typically a Dropbox folder is confined to one user, even if it's 
replicated on multiple machines, so you're not going to run into 
multiuser issues. I have quite a lot of files stored on Dropbox, but 
they're fairly small so the update sync time is very fast. And if the 
sync fails because of network issues, the cloud copy isn't updated. But 
I wouldn't put a database on Dropbox precisely because of the problems 
listed in that article.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Quit Command corrupts standalone (stack called by standalone splash)

[Knapp Martin via use-livecode]

Thanks for the in-depth reply. Are there known issues with saving LC stacks to 
Dropbox? I was thinking of Roland's issue with corruption and Phil's suggested 
fix of watching the file with the tilde character before allowing a quit to 
complete. I have an app where users create documents (stacks) and saving them 
to Dropbox is a built-in option. I have one customer who stores their stacks on 
a network server and a few times they've ended up with a corrupted stack. These 
stacks are 1-2 mb in size, so nothing huge, but they are of critical 
importance. I don’t know of anyone having trouble with Dropbox specifically, 
but if I can do something to make the process more robust, then that would be 
of great interest.

Marty

> Knapp Martin wrote:
> 
> > Richard, could you elaborate on the issues with Dropbox?
> 
> I first came across it in a search at Google for "dropbox sqlite", looking 
> for tips on making the most of that relationship.  What I found was a long 
> series of support forum and blog posts filled with horror stories of out of 
> sync or corrupted DB files.
> 
> Some merely lose a record.  Others lose the DB.  And so many have no problem 
> at all that it seems like something we should all be doing, until you look 
> into it far enough to find those who've lost records or the entire DB.
> 
> Of all the things I've read, this forum post covered more ground more 
> succinctly than most:
> 
> 
>   tl;dr: Dropbox fails the ACID test for databases.  So does its
>   competitor Box, which works the same way.  Use it for SQLite
>   databases only if your transfer time exceeds its synch time.
> 
>   
> 
>   Dropbox does not share files across the internet.  It copies
>   changed files from one computer to its server, then from that
>   server to all the other computers which have access to that
>   shared folder.
> 
>   Dropbox copies an entire file every time a part of it is updated.
>   If you have a 200GB database and delete one row, it needs to copy
>   the entire database file to all the other computers that can
>   access it.  While that works fine for small files, it will involve
>   a lot of traffic as your files grow in size.
> 
>   If two copies of the file are updated at the same time on different
>   computers, the changes made in one copy disappear.  Your
>   user-interface will ask you which one you want, but you may not
>   have enough knowledge to pick the 'best' one.
> 
>   If Dropbox decides to take a copy while SQLite is in the middle
>   of processing a transaction, you will temporarily have a copy of
>   the database with a partially-processed transaction on all the
>   computers which have access to that shared area.
> 
>   Dropbox doesn’t understand that the database file and the journal
>   file go together, even if they’re in the same folder.  And in order
>   to stop one user from hogging its servers there’s sometimes a short
>   delay between when it updates its copy of one file and when it
>   updates its copy of another file.  So it’s possible for one computer
>   which has a copy of the database to have a newer database file than
>   its journal file, or vice versa.
> 
>   SQLite autorepairs files when it finds a database file and a journal
>   file which don’t match.  I don’t know what it would do under the
>   above two conditions.  And what it would do would vary depending on
>   which file Dropbox decided to copy first.
> 
>   Given all the above, I might use Dropbox or Box to promulgate copies
>   of a SQLite database, but only if
>   (A) I had an backup of a recent version and the backup system does
>   not involve Dropbox/Box.
>   (B) If I was fairly sure that if I used one computer to update the
>   database, none of the other computers would try to open the file
>   (even just for reading) until a couple of minutes after the updates
>   were done and the service had had time to sync both database and
>   journal file.
> 
> http://sqlite.1065341.n5.nabble.com/Sqlite-Dropbox-tp95173p95177.html
> 
> 
> 
> > Is there a recommended procedure for dealing with it?
> 
> This vendor who uses SQLite for their data storage has the simplest solution 
> for sharing their files via Dropbox:  Don't do it. ;)  At least, not 
> directly, but this isn't going to work for so many users who don't spend much 
> time monkeying with files directly:
> 
> https://www.maxqda.com/faq/a-13-can-i-store-my-maxqda-projects-in-cloud-based-services-like-dropbox
> 
> 
> If the SQlite + Dropbox combo were super-robust we wouldn't see so many 
> purpose-built sync systems out there.  Sync systems aren't fun to write and 
> eat a lot of time, so if devs could avoid it so simply they would.
> 
> But they don't.  So many proprietary syncs out there, almost a new one for 
> every app that syncs.
> 
> And if you look into sync, you find just about every app that came up with a 
> syncing method has a very long blog post about their sync 2.0, needed after 
> 

Re: Quit Command corrupts standalone (stack called by standalone splash)

[Richard Gaskin via use-livecode]

Knapp Martin wrote:

> Richard, could you elaborate on the issues with Dropbox?

I first came across it in a search at Google for "dropbox sqlite", 
looking for tips on making the most of that relationship.  What I found 
was a long series of support forum and blog posts filled with horror 
stories of out of sync or corrupted DB files.


Some merely lose a record.  Others lose the DB.  And so many have no 
problem at all that it seems like something we should all be doing, 
until you look into it far enough to find those who've lost records or 
the entire DB.


Of all the things I've read, this forum post covered more ground more 
succinctly than most:



   tl;dr: Dropbox fails the ACID test for databases.  So does its
   competitor Box, which works the same way.  Use it for SQLite
   databases only if your transfer time exceeds its synch time.

   

   Dropbox does not share files across the internet.  It copies
   changed files from one computer to its server, then from that
   server to all the other computers which have access to that
   shared folder.

   Dropbox copies an entire file every time a part of it is updated.
   If you have a 200GB database and delete one row, it needs to copy
   the entire database file to all the other computers that can
   access it.  While that works fine for small files, it will involve
   a lot of traffic as your files grow in size.

   If two copies of the file are updated at the same time on different
   computers, the changes made in one copy disappear.  Your
   user-interface will ask you which one you want, but you may not
   have enough knowledge to pick the 'best' one.

   If Dropbox decides to take a copy while SQLite is in the middle
   of processing a transaction, you will temporarily have a copy of
   the database with a partially-processed transaction on all the
   computers which have access to that shared area.

   Dropbox doesn’t understand that the database file and the journal
   file go together, even if they’re in the same folder.  And in order
   to stop one user from hogging its servers there’s sometimes a short
   delay between when it updates its copy of one file and when it
   updates its copy of another file.  So it’s possible for one computer
   which has a copy of the database to have a newer database file than
   its journal file, or vice versa.

   SQLite autorepairs files when it finds a database file and a journal
   file which don’t match.  I don’t know what it would do under the
   above two conditions.  And what it would do would vary depending on
   which file Dropbox decided to copy first.

   Given all the above, I might use Dropbox or Box to promulgate copies
   of a SQLite database, but only if
   (A) I had an backup of a recent version and the backup system does
   not involve Dropbox/Box.
   (B) If I was fairly sure that if I used one computer to update the
   database, none of the other computers would try to open the file
   (even just for reading) until a couple of minutes after the updates
   were done and the service had had time to sync both database and
   journal file.

http://sqlite.1065341.n5.nabble.com/Sqlite-Dropbox-tp95173p95177.html



> Is there a recommended procedure for dealing with it?

This vendor who uses SQLite for their data storage has the simplest 
solution for sharing their files via Dropbox:  Don't do it. ;)  At 
least, not directly, but this isn't going to work for so many users who 
don't spend much time monkeying with files directly:


https://www.maxqda.com/faq/a-13-can-i-store-my-maxqda-projects-in-cloud-based-services-like-dropbox


If the SQlite + Dropbox combo were super-robust we wouldn't see so many 
purpose-built sync systems out there.  Sync systems aren't fun to write 
and eat a lot of time, so if devs could avoid it so simply they would.


But they don't.  So many proprietary syncs out there, almost a new one 
for every app that syncs.


And if you look into sync, you find just about every app that came up 
with a syncing method has a very long blog post about their sync 2.0, 
needed after whatever they came up with when they got started didn't 
work out.


Every OS vendor has a sync system in their APIs, but for obvious lock-in 
reasons none of them are compatible with any other.


So it's left up to us to figure this stuff out, a million developers all 
repeating the same wheel-building exercises of Evernote and every other 
sync-based system


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:

Re: Quit Command corrupts standalone (stack called by standalone splash)

[Knapp Martin via use-livecode]

Richard, could you elaborate on the issues with Dropbox? Is there a recommended 
procedure for dealing with it?

Marty

On Feb 26, 2018, at 11:07 AM, Richard Gaskin via use-livecode 
 wrote:

> Stack file corruption is very rare with LiveCode.  It has happened now and 
> then, but is rare enough (and of course serious enough) to merit attention by 
> the LC team.
> 
> Even if we can mitigate the issue by altering your code, the main question 
> remains:  why does a save operation become interrupted, and is that 
> interruption caused by external factors or from an internal bug?
> 
> Unless you know the cause of the corruption (failing hard drive, flaky 
> network with mounted network drive, use of Dropbox or other synced folder 
> with unpredictable behavior, etc.) it may be helpful opening a bug report if 
> only to allow the team to investigate the corrupted file to see if it brings 
> their attention to something internal which may need refinement.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Android Java Virtual Machines

[Sannyasin Brahmanathaswami via use-livecode]

I was using java jdk1.8.0_121.jdk

Even though documentation says it should work (any above 1.6 should work)

It an attempt of get to jdk1.8.0_152.jdk, I had installed Java 9, inadvertently.

To make a long story short, I installed sdkman to manage my Java

(very cool, http://sdkman.io/)

Any ended with up

/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk

No, I am wondering if my built on a Pixel is different from when it was 
jdk1.8.0_121.jdk.

Does anyone have two JDK installed to found out?
I nervous about messing with my Java script set up.
BR

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Quit Command corrupts standalone (stack called by standalone splash)

[Richard Gaskin via use-livecode]

Stack file corruption is very rare with LiveCode.  It has happened now 
and then, but is rare enough (and of course serious enough) to merit 
attention by the LC team.


Even if we can mitigate the issue by altering your code, the main 
question remains:  why does a save operation become interrupted, and is 
that interruption caused by external factors or from an internal bug?


Unless you know the cause of the corruption (failing hard drive, flaky 
network with mounted network drive, use of Dropbox or other synced 
folder with unpredictable behavior, etc.) it may be helpful opening a 
bug report if only to allow the team to investigate the corrupted file 
to see if it brings their attention to something internal which may need 
refinement.


--
 Richard Gaskin
 Fourth World Systems

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Quit Command corrupts standalone (stack called by standalone splash)

[Phil Davis via use-livecode]

Hi Roland,

This is the only reply of yours that I see.


On 2/26/18 4:13 AM, R.H. via use-livecode wrote:

Thanks, Phil and Tom

I already replied, but I cannot see my first reply to your answers.

Did it appear in the list?


Phil:

"quitMe" should be sent before 'saveMe' is executed, because the 'save'

command is blocking. It would prevent 'quitMe' from being sent until (in
this case) 1 second after 'saveMe' has finished.

Well, it is blocking. Issuing "quit" just quits if messages are locked.So,
to quit before save would require not to force a quit. Right? I will test.


You're right, but that's not what my code does. It sends 'quitMe' (which 
contains the 'quit') 1 second after 'saveMe' has started. As you may 
know, 'send in x seconds' adds 'quitMe' to the pendingMessages queue, so 
it will execute as soon as the designated time has passed AND no other 
handler is running.


For what it's worth, the correction I made to my own code is still not 
correct. The whole thing should look like this:



local sMyTildeFilename

on closeStack
    -- create a path to the 'tilde' file (which doesn't yet exist)
    put (the filename of me & "~") into sMyTildeFilename

    -- add 'quitMe' to the pendingMessages
    send "quitMe" in 1 second

    -- save this stack
    saveMe
end closeStack


command saveMe
   lock cursor
   set the cursor to watch
   save me -- creates the tilde file at beginning, deletes it at end
end saveMe


command quitMe
   -- wait until tilde file is gone, then quit
   if there is a file sMyTildeFilename -- 'save' has not completed yet
   then -- try again later
   send "quitMe" to me in 0.5 seconds
   else
       unlock cursor
       lock messages
       quit
   end if
end quitMe



Phil



The main problem is that the IDE is ok, even though saving takes a long
time, but no errors I can see. The standalones are the culprit, and I have
limited to access to other peoples computers using my standalones. And on
my machine the problem does not appear regularly.

// I hope this message appears, otherwise I will have to check what is
wrong sending messages to the list. //

Thanks
Roland
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



--
Phil Davis


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: widget properties

[Richard Gaskin via use-livecode]

Ali Lloyd wrote:

> Essentially my point of view is that a properties property should
> return all properties. Otherwise it can't really work with widgets.

Would it simplify things if what is needed for widgets is done for 
widgets, and the current data derived from engine-native objects remains 
as-is?


--
 Richard Gaskin
 Fourth World Systems

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Question about the result

[Mike Kerner via use-livecode]

It would be nice if we had more consistent locations to check for feedback,
without special cases and provisos.  For example, returning a value from a
function and a command (forget "for value" and "for error") populate it or
the result depending on whether we are using a command or a function.  One
of the side effects of adding "for value" and "for result" is that some of
the error reporting we used to receive if we coded for the incorrect
handler type has gone away.

On Sun, Feb 25, 2018 at 12:20 PM, Mike Bonner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> That is rather strange.  Most of the time LC is exactly what I expect, but
> then there are those head scratcher issues that keep me flummoxed. <--
> (word of the day)
>
> On Sun, Feb 25, 2018 at 9:57 AM, jbv via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > On Sun, February 25, 2018 5:36 pm, Mike Bonner via use-livecode wrote:
> > > Ah, well the only useful part of my answer then would regard the first
> > > issue. The result remaining empty was the correct response because the
> > > base url was valid, so the command didn't fail to connect to the url,
> and
> > > no 404 type or other type errors were returned as part of the headers.
> > >
> >
> > Actually, when I wrote "never went through", that's exactly what
> happened :
> > the request never went through, the server never received that request
> and
> > therefore never returned anything. And even more surprising, the line
> >put URL ("http://mydomain.com/index.php?; & it) into myVar
> > didn't block the execution of the script and the following lines were
> > executed,
> > and myVar was empty.
> >
> > That's the reason why I was surprised to see that the result was empty as
> > well;
> > I would expect something like "data corrupted" or "impossible to send
> > request"...
> > And also to have the script blocked by that line...
> >
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

[ANN] This Week in LiveCode 118

[panagiotis merakos via use-livecode]

Hi all,

Read about new developments in LiveCode open source and the open source
community in today's edition of the "This Week in LiveCode" newsletter!

Read issue #118 here: https://goo.gl/NzB8We

This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around the open source project. New issues will be
released weekly on Mondays. We have a dedicated mailing list that will
deliver each issue directly to you e-mail, so you don't miss any!

If you have anything you'd like mentioned (a project, a discussion
somewhere, an upcoming event) then please get in touch.


-- 

Panagiotis Merakos 
LiveCode Software Developer

Everyone Can Create Apps 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Xcode 9.2 & LC 8.1.9

[panagiotis merakos via use-livecode]

Hi Christer,

>There was an error while saving the standalone application
>..then about 20 ines of groups of numbers and different command logs.

Without seeing the logs it is difficult to guess what is wrong.

Another thing to note is that when using a new Xcode version, you have to
make sure the the Xcode command-line tools are updated correctly (to match
the particular Xcode version). You can do that either from a terminal, or
from Xcode itself:

From terminal:

sudo xcode-select -s /path/to/xcode9.2.app

From Xcode9.2:

- Launch Xcode 9.2
- Go to Xcode -> Preferences -> Locations
- In the Command Line Tools dropdown, choose "Xcode 9.2"

Then quit LC, clear the Prefs and set the path to Xcode 9.2 in LC
mobile prefs. Hopefully this should work.


Some other things to note: You can support iPhone X with Xcode9.2 as
well, you don't need Xcode9.3.

I have installed High Sierra 10.13.2 in one of our office Macs and it
is OK for me so far.

Hope this helps,

Panos

--







On Mon, Feb 26, 2018 at 1:28 PM, Pyyhtiä Christer via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Combination Xcode 9.2 and LC 8.1.9 creating iOS app states:
>
> There was an error while saving the standalone application
> ..then about 20 ines of groups of numbers and different command logs.
>
> However, it sloowly starts in simulator, directly from LC - provided that
> you select only one device from the menu.
>
> Tried carefully make sure the profiles were set up etc.
>
> Of course it can depend on having High Sierra installed, as it was
> recommended if you want to install Xcode 9.3, which is required for iPhone
> X.
>
> Any hints?
>
> PS.  I would definitely recommend NOT installing High Sierra.  It cuts the
> performance, messes up your contacts, applications crash all the time,
> application windows disappear and you need to kill them to get back.  High
> Sierra in my opinion is a big disaster.
>
> Christer Pyyhtiä
> MindCrea Ltd
> chris...@mindcrea.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Xcode 9.2 & LC 8.1.9

[Pyyhtiä Christer via use-livecode]

Combination Xcode 9.2 and LC 8.1.9 creating iOS app states:

There was an error while saving the standalone application
..then about 20 ines of groups of numbers and different command logs.

However, it sloowly starts in simulator, directly from LC - provided that you 
select only one device from the menu.

Tried carefully make sure the profiles were set up etc.

Of course it can depend on having High Sierra installed, as it was recommended 
if you want to install Xcode 9.3, which is required for iPhone X.

Any hints?

PS.  I would definitely recommend NOT installing High Sierra.  It cuts the 
performance, messes up your contacts, applications crash all the time, 
application windows disappear and you need to kill them to get back.  High 
Sierra in my opinion is a big disaster.

Christer Pyyhtiä
MindCrea Ltd
chris...@mindcrea.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Quit Command corrupts standalone (stack called by standalone splash)

[R.H. via use-livecode]

Thanks, Phil and Tom

I already replied, but I cannot see my first reply to your answers.

Did it appear in the list?


Phil:
>> "quitMe" should be sent before 'saveMe' is executed, because the 'save'
command is blocking. It would prevent 'quitMe' from being sent until (in
this case) 1 second after 'saveMe' has finished.

Well, it is blocking. Issuing "quit" just quits if messages are locked.So,
to quit before save would require not to force a quit. Right? I will test.

The main problem is that the IDE is ok, even though saving takes a long
time, but no errors I can see. The standalones are the culprit, and I have
limited to access to other peoples computers using my standalones. And on
my machine the problem does not appear regularly.

// I hope this message appears, otherwise I will have to check what is
wrong sending messages to the list. //

Thanks
Roland
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Quit Command corrupts standalone (stack called by standalone splash)

[Phil Davis via use-livecode]

Let me improve this a bit.


On 2/23/18 4:19 PM, Phil Davis via use-livecode wrote:

Roland,

I believe Tom is exactly right. I would restructure your two closing 
handlers like this:



local sMyFilename

on closeStack
    put the filename of me into sMyFilename
    saveMe
    send "quitMe" in 1 second
end closeStack


on closeStack
    put the filename of me into sMyFilename
    send "quitMe" to me in 1 second
    saveMe
end closeStack


"quitMe" should be sent before 'saveMe' is executed, because the 'save' 
command is blocking. It would prevent 'quitMe' from being sent until (in 
this case) 1 second after 'saveMe' has finished.


Thanks -
Phil




command saveMe
   lock cursor /* Tested with and without locking and showing cursor */
   set the cursor to watch
   save this stack /* auto save, takes a long time, between 10-30 secs */
end saveMe


command quitMe
   if there is a file sMyFilename then
  unlock cursor
  lock messages
  quit
   else
  send "quitMe" to me in 0.5 seconds -- or in your preferred time
   end if
end quitMe


The above was not tested but it should solve the problem.

HTH -
Phil Davis



On 2/23/18 3:20 PM, tbodine via use-livecode wrote:

Hi Roland.

The "~" file is the original  (uncorrupted, unsaved) version of your 
stack
before LC executed your Save cmd. If you remove the "~" from the 
filename,
you'll probably find you can open that. LC creates the "~" file at 
the start
of the save operation and, if all goes well, removes that file when 
save is

complete.

My guess is your problem is rooted in the lengthy save time in the quit
routine. Here are a couple ideas of how you could deal with that:

1) Do the save within a try/catch statement so you can deal with any 
error.


2) If you are just saving some user data like prefs or fairly minor 
stuff,

then why not save that into a separate substack outside of your main
application stack? That should greatly shorten the time it takes to 
save.


Hope that helps.

Tom Bodine



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





--
Phil Davis


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: send "keyUp" / "rawKeyUp" ?

[Richmond via use-livecode]

It always give a "q" as that is the Unicode name for "q".

Richmond.


On 26.02.2018 01:55, J. Landman Gay via use-livecode wrote:

On 2/25/18 1:57 PM, Richmond Mathewson via use-livecode wrote:
I want to send a rawKeyDown signal that fakes typing on the key on my 
keyboard

that has the underlying rawKey code of 113.


What does this give you on a non-US keyboard (untested):

  type numToChar(113)





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode