Re: Resources folder on mac, and the good old days

[Neville Smythe via use-livecode]

Interesting, and clever!

But how do they do that? Since the app can’t be running at the time it is moved 
to the trash, the code can’t be in the app itself. Which means they must 
install *another piece of code*, probably a daemon, which is running all the 
time; which would be necessary anyway for a security watchdog of course. Then 
does this but of code  uninstall itself? Possible I guess, the daemon file 
itself is not open when it is running so it could be moved to the trash and the 
daemon wasn’t killed it would just stop running the next time you reboot.

Of course for an LC standalone to use such an uninstall strategy you would need 
and Installer; and I don’t think it is really appropriate to have an ordinary 
app to have a daemon running all the time.

> On 31 Mar 2021, at 9:42 pm, Keith Martin  wrote:
> 
> 
>> On Mar 29, 2021, at 11:22 PM, Neville Smythe via use-livecode 
>>  wrote:
>> 
>> 3. There is no need for Installer code, or more problematic, and with a 
>> whiff of sulphur to sensitive old-hand Mac user noses, an Uninstaller
> 
> Hah! Yes, uninstallers should ideally never be required. I'm testing a 
> selection of macOS security tools at the moment (for a magazine, not just for 
> fun!) and I really like how – to give the most recent example – Avira Free 
> Security and Avira Prime (with help from the OS of course) will ask, when the 
> app is moved to the trash, if they should take their system extensions with 
> them. Polite, civilised, Mac-like. 
> 
> Keith
> Keith Martin
> 360 media specialist http://PanoramaPhotographer.com 
> <http://panoramaphotographer.com/>
> Contact and info http://thatkeith.com <http://thatkeith.com/>
> +44 (0)7909541365
> 
> 
> 
>> 

___
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: Resources folder on mac, and the good old days

[Neville Smythe via use-livecode]

> On 30 Mar 2021, at 12:44 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> Unfortunately this has never been true on macOS X.
> 
> The Resources folder (which is in the macOS app bundle) should be 
> treated as read-only…

Mark Waddingham chides me for saying it is OK to write to the Resources folder 
in the app bundle on a Mac. Mark is, as ever absolutely correct. The correct 
place for application support files is the Library/Applications Support folder, 
and this has been the AppleGuideline for a very long time (although I am not 
quite so sure about that *always* being the case..) I was wrong, naughty, and I 
promise… Mea culpa, mea maxima culpa. I strongly advise against this awful 
filthy and degrading practice.

Except m’lud (he said in a very small voice), may I offer some admittedly 
post-hoc and flimsy excuses.

1. The app in which I do this originates from the days before the Application 
Support folder existed (I am pretty sure) and has grown like Topsy ever since. 
It worked then, it still works now. With one big caveat: this is ad hoc 
software, distributed to a small group of users (Colin: by all the usual 
methods - server, email, DropBox… they all work to deliver a working app 
without my having to renew my lapsed Apple Developer registration.) If I were 
to commercialise the app and so notarise it, I would expect writing to the 
Resources folder *not* to work, probably notarising keeps a checksum of the 
whole app bundle not just the executable. Maybe this distinction between ad hoc 
and notarised software is part of the confusion of this very confused thread, 
to which I have regrettably added more confusion.

2. It is a great convenience to my Mac users to be able to move their copy of 
the app to another machine, or give it to a friend, without having to worry 
about finding and transferring auxiliary files (unlike my linux users, who I 
must advise to keep everything together in one directory).

3. There is no need for Installer code, or more problematic, and with a whiff 
of sulphur to sensitive old-hand Mac user noses, an Uninstaller. Again if I 
were to commercialise the app, these would come with the territory of license 
files etc.

4. If my user wants to get at the auxiliary files, it is easy enough to explain 
the arcane process of opening up the Contents of the bundle. Explaining how to 
access the Library is only slightly more arcane, but I really don’t want the 
uninitiated venturing into that dark scary and very dangerous place .

So, readers, don’t do it. But keep it to yourself if you do. And it probably 
won’t work in MacOS 17.6.

Finally on the problem of opening unsafe/unnotarised apps in recent MacOS, I am 
afraid the discussion here has clearly only increased the confusion of the 
original forum user. Surely best to refer to the definitive source, the Apple 
Support documents which you can get by googling “How to open an unsafe app in 
Big Sur” (or Catalina, or Mojave). The instructions from Apple are clear and 
straightforward, unlike some tech forums which start off by talking about using 
the terminal to turn off Gatekeeper. 

Neville



___
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

Resources folder on mac, and the good old days

[Neville Smythe via use-livecode]

> you may already know this, but this will not work in a standalone!
> We will surely not have write permissions in that folder!
> 
> As a workaround I would probably use -> specialfolderpath("temporary")
> Or even write the text to -> the tempname
> 


I find this discussions strange - I had the impression most users here were Mac 
developers and knew this stuff.

There is no problem writing to the resources folder. That’s the logical place 
to put the user-changeable stack files for a standalone, making the auxiliary 
files invisible to external fiddling by the user,  which a Good Thing (although 
that does make the app look different on Windows or Linux).

As for the Good Old Days of free distribution to other Mac (desktop) users, 
they haven’t gone. Apple is making it harder for the uninitiated to find out 
how to open “unsafe” files, but they don't keep it a secret. And while recent 
rumours abound  about unnotarized apps not working at all on some future MacOS, 
it does seem unlikely that will actually happen, and if they do that’s time for 
us all to reboot to Linux.

Neville



___
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: revCopyFolder in LC Server

[Neville Smythe via use-livecode]

Thanks Matthias. I would not have guessed that from the Documentation which 
simply says that revCopyHandler is available for “desktop,server”.

I was thinking I would just use a one-line shell call to replace the handler … 
but I suppose I should install the whole shebang

Neville
___
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

revCopyFolder in LC Server

[Neville Smythe via use-livecode]

I get a “Can’t find handler (revCopyFolder)” error in LC Server from a script 
line
revCopyFolder tTemplateDir,tDirPath

The script works up to that line. Is there a problem with using revCopyFolder 
in LCServer?

Neville

___
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

Call lc from php?

[Neville Smythe via use-livecode]

A slightly less cursory investigation informs me that



works, as I should;d have known.


Neville

___
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

Call lc from php?

[Neville Smythe via use-livecode]

Quick question: is it possible to execute a .lc server script from within php 
(eg from an index.php page)?

This other way is documented, but on a cursory perusal I couldn’t see how to do 
it, and I’ve forgotten more about php than I remember. 

Maybe using a shell command within the php, but is there a way set up php to 
automatically recognise .lc? Php.ini??

Neville
___
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: POST command does not work if Lock messages is set

[Neville Smythe via use-livecode]

For anyone wishing to follow this bug, it has been confirmed by QC at 

https://quality.livecode.com/show_bug.cgi?id=23058 


As for my other fake news problem with data size and POST, please forget I ever 
misspoke.
LiveCode Server is rather a steep learning curve with not a lot of examples out 
there, but I love it already.

Neville
___
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

POST data size bug

[Neville Smythe via use-livecode]

Ah. My bad 

I just discovered

libURLSetExpect100


Neville

___
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

POST data size bug

[Neville Smythe via use-livecode]

I seem to have hit another bug in POSTing data to LiveCoder Server (Community 
9.6.2) 

If the data being posted has 139000 characters the POST succeeds and I get a 
response back from my LC script in about 2.5 seconds. If I try to send about 
14 characters I get a time out error.

I presume the problem is in LC server, not in the internet library in my client.

Neville
___
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

POST does not work under lock messages

[Neville Smythe via use-livecode]

It took me a while to figure this one out. I have a number of scripts which 
POST to LiveCode Server .lc scripts. All were working fine except one which 
always returned the output from whatever POST had last been executed. Evidently 
the previous form request was being resubmitted. Turns out I had a lock 
messages command before calling POST. 

Seems to me that shouldna oughta happen —either it’s a bug, or it should be 
documented 

(I think there is a documented warning about DataGrids needing Lock messages 
off? And wasn’t there a discussion a while back about Lock messages needing 
levels? The current documentation for Lock messages says it blocks “setProp 
triggers, getProp and certain other messages” where “certain”  is left 
undefined.)

Neville
___
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: Secure connection to server

[Neville Smythe via use-livecode]

I have now moved all my code from php to LiveCode server as the middle-ware.

Firstly it appears that the LiveCode post operation does reuse authentication 
credentials to an https connection as long as calls are made within a single 
script. In my case the first call typically takes slightly more than 1 second, 
subsequent calls in the same script take under half a second.

This is still not adequate to conduct a conversation with the remote database, 
as was possible when connecting directly, but at least in my case I can get 
away with just two calls from clients to server: first “tell me the current 
status of all this stuff”, second “please update the db using this stuff”. It 
means packing and unpacking “stuff” into large files at each end, but LC is so 
easy and efficient at text processing that was not difficult. Indeed as usual 
with refactoring, I found a number of code improvements.

The remaining really slow operation involves managing the mail distribution 
lists. DreamHost is still using Mailman 2.x, so that the only way to get the 
current list of subscribers is to scrape the admin web pages. There is a well 
known subscriberlist.py python script to do this but it is painfully slow. When 
used directly (insecurely) from the client, this took 10 seconds or so to 
gather 175 subscribers. Transferring this to the server side with lc 
authentication in-between, it now takes 14 to 15 seconds; I’m not sure why it 
is more that 2 seconds slower but it is what it is. I have rewritten this as an 
lc script, which shaves a couple of seconds off; to be fair the python script 
is doing rather more than my lc script as it is much more generic. And on the 
other hand I can understand what my script is doing, whereas the python script 
is rather opaque (to me).

So overall I am very happy with LC server. And I have a new toy to play with 
for the New Year.

Neville

> On 16 Dec 2020, at 11:32 am, Neville Smythe  
> wrote:
> 
> A little while ago in this forum we were alerted to the fact that LC direct 
> connection to a remote database not using SSL was a security hole. This also 
> applies to managing Mailman lists on a remote server.
> 
> After a steep (re-)learning curve with the various technologies, I now have a 
> working method in place for both mysql and Mailman connections, using php as 
> middleware and posting via curl in a shell script. But it is sooo slooow.
> 
> Direct connection downloaded an sql query in a fraction of a second. It now 
> takes over a second. This is acceptable (barely) for an isolated call,  but I 
> sometimes need to make a sequence of posts. As I understand it, the slowness 
> is due to the time required to establish the secure connection, not an LC 
> problem. For example establishing an ssh connection in Terminal is even 
> slower; but once established an ssh session is super fast. Similarly curl 
> will reuse authentication credentials within a shell session, so I aggregate 
> as many calls as I can with a single shell script before using 
> shell(myscript), and this definitely helps.
> 
> What I would like to do however is use LC server as the middleware: I could 
> then process the required data on the server side; I could not contemplate 
> using php to do this. I suspect the LC post command uses curl under the hood, 
> but I also suspect each post call would create its own session. I don’t think 
> it is possible to establish a single session to talk sequentially to 
> lcserver; if so this would be too slow. Am I correct? 
> 
> Actually I guess I could  just use my present method using curl and shell() 
> instead of post, but addressed to an .lc script instead of .php?
> 
> Or is there a whole better way to do what I want? 
> 
> Neville Smythe
> 
> 


___
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

Secure connection to server

[Neville Smythe via use-livecode]

A little while ago in this forum we were alerted to the fact that LC direct 
connection to a remote database not using SSL was a security hole. This also 
applies to managing Mailman lists on a remote server.

After a steep (re-)learning curve with the various technologies, I now have a 
working method in place for both mysql and Mailman connections, using php as 
middleware and posting via curl in a shell script. But it is sooo slooow.

Direct connection downloaded an sql query in a fraction of a second. It now 
takes over a second. This is acceptable (barely) for an isolated call,  but I 
sometimes need to make a sequence of posts. As I understand it, the slowness is 
due to the time required to establish the secure connection, not an LC problem. 
For example establishing an ssh connection in Terminal is even slower; but once 
established an ssh session is super fast. Similarly curl will reuse 
authentication credentials within a shell session, so I aggregate as many calls 
as I can with a single shell script before using shell(myscript), and this 
definitely helps.

What I would like to do however is use LC server as the middleware: I could 
then process the required data on the server side; I could not contemplate 
using php to do this. I suspect the LC post command uses curl under the hood, 
but I also suspect each post call would create its own session. I don’t think 
it is possible to establish a single session to talk sequentially to lcserver; 
if so this would be too slow. Am I correct? 

Actually I guess I could  just use my present method using curl and shell() 
instead of post, but addressed to an .lc script instead of .php?

Or is there a whole better way to do what I want? 

Neville Smythe



___
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

Rer: Decrypt problem on Windows solved

[Neville Smythe via use-livecode]

> Could you try to textEncode the encrypted data before saving it in the
> custom property, and then, in the other platform, textDecode it before
> decrypting it?

Many thanks Panos, yes, that fixed the problem.

It never occurred to me that reading binary data from the custom properties of 
a stack should be treated with same caveat as downloading from an external 
source. Todays “learnings” (horrible newly fashionable word).

Neville Smythe



___
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

Rer: Decrypt problem on Windows

[Neville Smythe via use-livecode]

The problem is platform-symmetric. That is, a string encrypted in LC on Windows 
will not decrypt on the Mac. Linux will not decrypt a string encrypted on the 
Mac, and presumably vice-versa.

I did toy with the idea that the encryption keys might be device dependent, 
maybe the public and private keys created by the OpenSSL library were being 
stored in the OS somewhere. But no, a string encrypted on one Mac decrypts 
correctly on a different Mac. So my guess is that the keys are being stored by 
the different platform libraries within LC but not in a place known to the 
library for another platform.

I believe this is a bug, that is to say, it is not what is intended; surely one 
should be able to store an encrypted string in an LC stack, and then any user 
with the password should be able to decrypt it. 

A workaround is to store a different encrypted string in the standalone 
compiled for each platform — but to do that you need to run LC on each 
platform, not exactly in the spirit of LC! Or not to use SSL encryption; I 
would assume all of the other ciphers available in OpenSSL would behave the 
same way.

BTW thanks Mark for the suggestion about htppie, it does look cleaner and 
easier than curl. The disadvantage in my case is it would need to be installed 
in each user’s system.

Neville Smythe



___
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

Decrypt problem on Windows

[Neville Smythe via use-livecode]

I am getting a difference in the results from decryption of a variable (stored 
in a stack custom property) between Mac and Windows 10.

The script is

decrypt  using "aes-256-cbc" with password  

On the Mac this decrypts < myEncryptedStr > to its original value

On Windows it gives an empty value, with the result returning “SSL error: Bad 
encrypt”

Could this be a difference in versions between the OpenSSL library built in to  
OSX 10.15.7 and the LiveCode SSL  inclusion for Windows? Or  would a different 
cipher work on both platforms, or perhaps provision of the bit value make it 
work? Or - surely not - do I have to use different encrypted custom properties 
for each platform? 

[I had just recovered strength  from fighting the gratuitously different syntax 
that Windows uses in its implementation of cURL to hit this problem] 


Neville Smythe


___
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: SSL cPanel mySql setup

[Neville Smythe via use-livecode]

> I'm not sure what that DH rep is going on about, because the same set of 
> LC Lessons that describe how to set it up via Apache config also include 
> one on setting it up via .htacces on shared hosts.

Many thanks Richard

I will give it a go.

I was once told by a DreamHost support guy that they didn’t use use Mailman for 
their mail distribution lists. So not too surprising.

Neville
___
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: SSL cPanel mySql setup

[Neville Smythe via use-livecode]

> On 19 Oct 2020, at 3:00 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> Dreamhost never did install LC ... but several of us have made it work.
> Just get the right server executable and permissions.
> I could never get it work account wide but it rocked for individual web
> site installation.

Ah. I got the distinct impression I would need a dedicated server account on 
DreamHost, not a shared environment, to instal LC Server; for this user’s site 
that would not be worth the cost.

To quote the reply from DreamHost:
-
Unfornately we no longer support LiveCode server on our servers at this
time. Looks like current install steps require root/admin access to some
apache config files, which is not something we allow on our managed
server types. 

You could install that on a Dedicated server, or DreamCompute instance if
you wish to, but that would be something you or your developers would
want to do using root on that service. 
-
___
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: SSL cPanel mySql setup

[Neville Smythe via use-livecode]

Thanks to this thread for the realisation my remote db connections are not 
secure. I just checked with Dreamhost and they gave their reasons for not use 
SSL with their mySQL setup — unacceptable burden on their server and 
undesirable for web app access; so in their opinion very few shared host 
environments would enable SSL for mySQL.

So I need some middleware. LC Server would have been ideal, but Dreamhost no 
longer install it ;-(. I particularly could have used LC Server to drive 
mailman distribution list subscription/unsubscription tasks from the database 
for which I do not have a good solution at the moment.

Neville



___
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: Modal stacks cpu usage

[Neville Smythe via use-livecode]

Jacque wrote
> If the Project Browser is open, try closing it. On my Mac, the CPU usage 
> while idle is usually close to 0 when in the background.

Interesting. I would indeed have expected a good-citizen app doing nothing in 
the background to use less than 1% cpu: Mail, Safari. Finder, BBEdit, Keyboard 
Maestro are currently all close to 0% But I never see LC using less than 4.3% 
with no user stacks open, no palettes, no plugins, no scripts, just the IDE. 
Adding revSmartSave brings it up to 15%. The only odd thing about the process I 
can see is the unusually high number of “idle wake ups”, sometimes over 100 in 
the Activity Monitor sampling period: no other process excepting kernel_task 
has anything like this number.

Of course it’s a mug’s game — if that is a phrase in your neck of the woods— 
trying to second guess OS time-sharing parameters, but it does look like LC is 
not a very nice (pun intended) citizen at least in this configuration: Catalina 
10.15.6, Mac Air 2020 quad core, LC 9.6.1 Community! 

Neville





___
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: Modal stacks cpu usage

[Neville Smythe via use-livecode]

Looks like Elanor beat me to it Bug 22929 
 

Neville Smythe
___
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: Modal stacks cpu usage

[Neville Smythe via use-livecode]

> Confirmed here on macOS 10.14.5.  The CPU load is indeed quite dramatic 
> with modal dialogs.
> 
> I also checked on Linux (Ubuntu 18.04), and LC does not exhibit the 
> problem there.


Thanks Richard for confirming, and testing on Linux. Yes I will file a bug 
report.

It occurred to me that LC shouldn’t be using as much as 34% cpu when it is just 
idling anyway, even when not running a modal stack. Testing just now shows that 
is down to around 16%; of course LC’s time share will depend on lots of OS 
factors and other running apps, but that’s still way too high for an app 
supposedly doing nothing but waiting for events. Turning off the Rinaldi 
revSmartSave plugin brings it down to between 4 and 7%, which is more 
reasonable; presumably something to do with displaying its progress bar, 
perhaps another wait side effect.

Neville Smythe
___
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

Modal stacks cpu usage

[Neville Smythe via use-livecode]

I have just noticed something curious. 

I am running LiveCode 8.1 IDE 9.6.1 on a Mac Air 2020 quad core Catalina.  

Typically LC cpu usage shows about 34%  (presumably of 1 core).  When a modal 
stack is opened it immediately ramps up to 99% ; the fan kicks in, and if left 
for a while the OS boosts the kernel_task daemon which I have been told is a 
protection device to prevent overheating. This has the effect of very markedly 
slowing down all apps as they get less cpu time.

If the stack is opened in non-modal mode, cpu usage stays around 34% . I don’t 
understand why a modal stack should be a cpu hog, indeed it seems like a bug to 
me. 

I have a suspicion the wait with messages command  may have the same effect on 
cpu performance, so it could be the culprit.





___
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

Catalina and Apple mail

[Neville Smythe via use-livecode]

Graham: before updating to Catalina definitely make a back of everything. When 
I updated I lost 35000 emails. Not just that they weren't loaded  by Mail, they 
were actually deleted from the computer. That said, that was some months ago, 
and Catalina has since solved that problem - reportedly; I have certainly had 
no problems since recent OS updates. Also it is safest to do a clean instal if 
you can rather an update from Mojave or whatever.

The experience was quite nasty. But in the process of using some LC code to 
recover my emails from a backup [BTW TimeMachine wouldn’t do the recovery 
automatically] I learnt a huge amount about mailbox structures and sqlite 
databases and found thousands of duplicate emails.

Neville

> On 18 May 2020, at 2:00 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> Send use-livecode mailing list submissions to
>   use-livecode@lists.runrev.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.runrev.com/mailman/listinfo/use-livecode
> or, via email, send a message with subject or body 'help' to
>   use-livecode-requ...@lists.runrev.com
> 
> You can reach the person managing the list at
>   use-livecode-ow...@lists.runrev.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of use-livecode digest..."
> 
> 
> you can find the archives for this list at:
> 
> http://lists.runrev.com/pipermail/use-livecode/
> 
> and search them using this link:
> 
> http://www.google.com/advanced_search?q=site:lists.runrev.com
> 
> 
> Today's Topics:
> 
>   1. Re: Apps to fight COVID-19 (Dar Scott Consulting)
>   2. Re: Sad truth about iOS apps (kee nethery)
>   3. Re: Sad truth about iOS apps (Graham Samuel)
> 
> 
> --
> 
> Message: 1
> Date: Sat, 16 May 2020 11:30:39 -0600
> From: Dar Scott Consulting 
> To: How to use LiveCode 
> Subject: Re: Apps to fight COVID-19
> Message-ID: <0e24ee6e-635f-4835-a635-14fb51258...@swcp.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Covid Watch (where I'm working) is decentralized. (of course) 
> 
>> On May 14, 2020, at 10:35 AM, Mark Wieder via use-livecode 
>>  wrote:
>> 
>> Updated news: Germany steps up to the plate
>> 
>> https://www.bbc.com/news/technology-52650576
>> https://github.com/corona-warn-app/cwa-documentation
>> 
>> -- 
>> 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
> 
> 
> 
> 
> --
> 
> Message: 2
> Date: Sat, 16 May 2020 15:01:32 -0700
> From: kee nethery 
> To: How to use LiveCode 
> Subject: Re: Sad truth about iOS apps
> Message-ID: <6d75b644-1acf-4279-a960-840585638...@elloco.com>
> Content-Type: text/plain; charset=utf-8
> 
> Replaced or just deleted any 32 bit apps I had. Opened files in 32 bit apps 
> and converted them into something else, typically Text or PDF. Lots of files 
> I printed to PDF and stored the PDF versions. 
> 
> Bought some software to open MacDraw files and save them as PDF.
> 
> I had some WriteNow files that I had to move to a really old laptop, print to 
> PDF, and then move back. 
> 
> All in all, I?m pretty sure that every file I now have can be viewed under 
> Catalina. And thus, I have migrated to Catalina. It took a bunch of time, but 
> hey, have lots of time right now.
> 
> Kee
> 
>> On May 16, 2020, at 6:40 AM, Rick Harrison via use-livecode 
>>  wrote:
>> 
>> For those who upgrade to Catalina, remember you will lose any 32 bit apps
>> as Apple has forced everyone to move to 64 bit apps.
>> 
>> Good luck!
>> 
>> Rick
>> 
>>> On May 16, 2020, at 5:42 AM, Erik Beugelaar via use-livecode 
>>>  wrote:
>>> 
>>> Update: You can direclty upgrade from High Sierra to Catalina using the 
>>> macOS Catalina Patcher.
>>> Be sure that High Sierra is up-to-date and using APFS (new Apple File 
>>> System) instead of HFS+.
>> 
>> ___
>> 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
> 
> 
> 
> 
> --
> 
> Message: 3
> Date: Sun, 17 May 2020 09:31:53 +0200
> From: Graham Samuel 
> To: How to use LiveCode 
> Subject: Re: Sad truth about iOS apps
> Message-ID: <23f7cb91-5af3-47a7-bbc7-8243fcabf...@mac.com>
> Content-Type: text/plain; charset=utf-8
> 
> There is a consistent tale (more than a rumour, I think) that Catalina can 
> mess up some people's mail messages, if you use Apple Mail. Did that affect 
> you? It?s the thing about Catalina that scares me most - after all, we?ve had 
> lots of warning about 32 bit 

Re: DataGrid table DeleteIndex

[Neville Smythe via use-livecode]

BobS wrote

> Did you try the plural form of deleteIndex(es)? 

Well you see I read the documentation. Which says “DeleteIndexes” is a synonym 
of “DeleteIndex”. So I didn’t try it (didn’t try “DeleteIndices” either). 
Thanks Bob, that does work! So the documentation is wrong. There is no separate 
entry for DeleteIndexes.

> The data grid does not use threads. Nothing in LC does.

I know LC doesn’t but I thought it just possible that DataGrid uses a C 
external which employs threads. Clutching at straws of course.

Neville


___
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

DataGrid table DeleteIndex

[Neville Smythe via use-livecode]

Am I doing something wrong? 

I put a comma delimited list into tIndexes, then dispatch DeleteIndex to my 
DataGrid with tIndexes. Only the first index in my list is actually deleted. LC 
9.5.1, Mac Catalina.

[Also, If I perform another action in the same handler as the call to delete 
indexes (indices please)  which modifies the content of the datagrid, it leaves 
the datagrid in a very strange state, which can only be recovered by hitting 
the Refresh DataGrid in its Property Inspector. Something to do with the timing 
of the row deletion not having completed I suspect, but that is another matter 
and may be my code. Hmm, does DataGrid use threads??]

Neville
___
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: Go to card has become slow

[Neville Smythe via use-livecode]

Mark Waddingham wrote
> Each paragraph has at least one style run - even if no styles are 
> applied so this is a general thing.
> 
> Most of the text in your generated test (data) stack was unstyled anyway 
> (as it uses 'the text of' to replicate the data) so minimizing those API 
> calls should affect all stacks with a reasonable amount of field data in 
> them.

Ah, my bad. I have updated the SlowSaveWithStyle test stack.

So table fields and datagrids  will indeed be affected. Excellent!

Neville

___
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: Go to card has become slow

[Neville Smythe via use-livecode]

Mark Waddingham wrote
> There appear to be two reasons for the difference:
> 
>   1) When saving each style run (block) in a field the engine is making 
> three Win32 API calls.
> 
>   2) The saving method uses (and always has used) direct Win32 system 
> calls to manipulate files without any buffering (on other platforms we 
> wrap the standard C library stdio FILE which has its own buffer).


Wonderful Mark!

I hadn’t really flagged the fact that I was using styled test in my test set. 
Given your comment that seemed to point to styled text being the bottleneck I 
tweaked my test stack to give the option of plain text. It is available at

https://www.dropbox.com/sh/kgc7u7xpqu63hef/AAAdblOyIcx8SIuurB_QfHyHa?dl=0 


But no, it shaved only 1 second off a 7 second save for styled text (elderly 
MacPro running Windows 10 VM) So your engine modifications must be having a 
much wider effect, not just on reducing the 3 API calls for styled as opposed 
to plain text ??

I hope so because the actual problem in the production stack was large numbers 
of table fields, not styled text. I only used ordinary text fields in the 
sample stack I submitted to QC in order to simplify and isolate the problem. 
Will we get a speed-up for table fields (and DataGrids) when it rolls out?

Neville
___
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: Go to card has become slow

[Neville Smythe via use-livecode]

Sorry Brian, I uploaded from the wrong folder. Here is the update test set. But 
the only difference is that you don’t need to hold down the shift key to see 
the binary save timing.

https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0 


Colin, the test set here shows the timing of saving of stacks; the times for 
Windows 10 are a large multiple of Mac/Unix and we discussing possible reasons 
before updating the bug report  bug 21305 
  for Quality Control

Neville
___
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: Go to card has become slow

[Neville Smythe via use-livecode]

> On 11 Apr 2020, at 2:00 am, Brian Milby wrote
> 
> I just imported a 500kb image to the card, removed the text from the field,
> created 300 cards.
> 0.756 seconds normal (171MB).  1.124 from a variable. (image instead of
> text)
> 8.311 seconds normal (8.2MB).  0.047 from a variable.  (original text)
> 
> I'll need to clean this up with a better image (something I can share) and
> try on my Mac for comparison when I get off today, but this points squarely
> at the serialization of the field object being the difference.

I am intrigued by the fact that save stack (for a stack with on-disk file size 
171MB) took *less* time than saving its binary data representation. Doesn’t 
that mean that the images were already on disk, and the in-memory stack was 
very much smaller than 171 MB, containing only image references. In which case 
I’m not sure we are comparing like with like, as compared with the text version 
(unless "save stack as newStackFile" might be give more comparable info?).

My hunch is that Richard’s point about the Windows write-to-file overhead is 
still the key, not the serialisation. One would to need to compare the number 
of writes used by the engine for the two stack versions. That I do not know how 
to do , but I think the incomparable Brian could do it!

Neville
___
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: Go to card has become slow

[Neville Smythe via use-livecode]

I have updated the SlowSave test stack with Richard's enhancement to also show 
the time to save the binary data (no need to use the shift button)

https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0

Pleased to see everyone is seeing the problem at last, it doesn’t seem to be 
related to the particular Windows 10 installation. But 38 seconds for 8 MB!! 

Neville
___
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: Go to card has become slow

[Neville Smythe via use-livecode]

Richard:

OK, so my impression, that LC saving a (binary) file on Windows 10 is not the 
problem, is correct, as you deduce it lies in the serialisation of the stack.

Now why would that be platform, indeed OS, dependent? Could the LC 
cache/virtual memory settings be different for Windows 10 from those for MacOS 
or Linux? But if that were the case you would expect to see a slow down in 
other parts of LC, such as perhaps script editing in the IDE, and that doesn’t 
happen, does it (!!)

Neville
___
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: Go to card has become slow

[Neville Smythe via use-livecode]

Richard

Here is a link to the test stack for testing the speed of save stack

https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0

I don’t know why the test stacks I supplied disappeared from the QC bug report.

You need the SlowSave.livecode and the data.livecode stacks. They are both 
small, but SlowSave creates a large stack with 300 cards and the lorem ipsum 
text data to build an 8 MB stack, and displays the timing for saving. On my 
MacBook Air it takes 0.13 seconds to save; on Windows 10 installations I have 
seen times from 3 seconds to 10 seconds.

In this test, the stack has just 300 cards, 1 field on each, and lots of ascii 
text (so there should be no problems converting to utf-8 before saving in the 
unlikely event that is happening, and in any case would happen on all 
platforms). I haven’t tested stacks with large numbers of controls or large 
images rather than large text data.

Other apps on Windows 10 certainly don’t display this behaviour, which  
indicates it is a LC problem not a Windows problem. Antivirus software and 
Defender were off during the test. I was under the impression that saving files 
from LC, rather than stacks, was not slower than normal, but Bob’s recently 
experience with saving data to a database may contradict that.

Some people have had trouble verifying my observations (other LC Forum users 
have confirmed). QC originally could not confirm the bug until they tried it 
“on an older PC”. However one of my users recently updated to a *very* fast HP 
box; it cut the save time down significantly but was still at least 20 times 
slower than on a typical Mac, ie almost usable. So maybe it has something to do 
with the Windows installation, though the ones I used were stock standard. I 
can’t see how fonts could be involved, for example. 

Neville
___
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: Go to card has become slow

[Neville Smythe via use-livecode]

Richard wrote 

> Bob Sneidar wrote:
> 
>> In review, I tested saving stacks on a standalone Windows Workstation,
>> a VMWARE VM on a very robust server host, a Parallels VM on a
>> workstation and my Mac. As I am saving the stack, I am watching the
>> folder the stack is in. I see the tilde version pop up and go away. On
>> Mac it?s almost instantaneous. On Windows it can be 3 to 4 seconds.
> 
> My messages don't seem to be getting through, because each time this 
> observation method of measuring write throughput comes up I post the 
> same reply, yet it keeps coming up.  Please confirm if you can see this:

Yes we see this. But as you know in 2018 I reported this slow saving of stacks 
under Windows10, using LC timing of just the save handler rather than the 
visual perception of the screen update, and it has been confirmed as a bug.  
bug 21305  The time to save 
is extreme for large stacks. It took some time for QualityControl to confirm, 
because apparently  it doesn’t seem happen on every Windows 10 installation - 
just every one  that I or my users have tried. It has not been fixed since 
2018. 

Regards

Neville
___
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: Mobile Wondering

[Neville Smythe via use-livecode]

I had been wondering when the third-class status of mobile platforms in the LC 
world, particularly in relation to scrolling fields and groups, would crop up 
here.

Some time ago I looked at converting an iOS project to LC, and was appalled at 
the crude 1984-style appearance of scroll bars. I presume they look that way to 
inhibit their use, since the scrolling idiom on mobile platforms iOS is quite 
different from the desktop. But I reckon the native-scroller thingy which you 
had to use in its place seemed an awful hack:  its appearance in a different 
layer meant other objects got overwritten in a completely unacceptable way (has 
that changed?); and the separation of the testing regime from the IDE turned 
back the clock on the development process, again to 1984 when you developed on 
the Lisa, tested on the Mac. (Yes, I was there!)

So I developed a custom scrollbar which worked on both desktop and iOS. It is 
doable, with a modicum of fiddly stuff.
You need

1. An installer stack or widget. When you drag a scrollbar template onto a 
field (or group), it registers the field id with the scrollbar, snaps the 
scrollbar to fit the field dimensions with the desired vertical or horizontal 
orientation, and adjusts the thumb to match the field content. It also installs 
a backscript and frontscript in the stack.  

2. The front script captures mouse events/ drag touch gestures intended for the 
field, filters for scrolling events and diverts those to the appropriate custom 
scrollbar.  For 2-dimensional scrolling I used two separate scrollbars which 
needed some cross-mediation of gesture directions; a combined double-scrollbar 
would have been better. 

3. The backscript catches changes to the field affecting content, position or 
dimensions which need to be reflected in the scrollbars.

I had it working pretty well, to the point of a mostly complete examples / 
installer stack . You can customise all sorts of things, such as the appearance 
of the thumb and scrollbar background, whether the thumb length should reflect 
field content proportionally or not, visible-on-demand or as-needed or hidden 
thumb, the number of thumb positions - for example you could have a stepper 
with just 5 positions and a custom image as thumb - and even have left side or 
top mounted scrollbars. You could even have a desktop look and feel if you 
wanted, and why not if Apple can flout their own UI guidelines?

The  iOS project lapsed, running the maze of Apple distribution requirements 
became discouraging and I lost interest. But it can be done.

Neville
___
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: Unicode mysteries

[Neville Smythe via use-livecode]

I have filed a bug report  bug_22561 
  re the misreporting of 
codepoints for unicode characters.

I am pretty convinced the treatment of the Rainbow flag emoji as three separate 
characters should be treated as incorrect behaviour and therefore a bug, I 
think the problem is that the vertical join codepoint 200D is not being treated 
as a codepoint within a character rather than starting a new character (while 
the glyph variation codepoints FE00-FE0F and the Variation Selectors E01xx are 
correctly interpreted).

 It is interesting to  see how the “transgender flag”, which is a new emoji not 
yet implemented in the Apple Color Emoji font but is supported by Google and 
Facebook, is displayed in various apps: in LC it appears as 4 glyphs (if the 
Gnu Unicode font is installed) but 3 separate characters; in BBedit it shows as 
2 glyphs, in Pages as 4 glyphs but in both these case as a single character 
(delete char 1 or backspace eliminates the whole thing, you cannot place a text 
insertion between the glyphs).

One final LC bug. A number of Apple Color Emoji font characters, in particular 
the digits 1,2..0 are clipped at the top when shown in text size larger than 9. 
This is true with Fixed Line Height turned off - LC doesn’t adjust the lines 
for the extra ascent for some reason, and I don’t know of any other text 
setting we have in LC to fix the problem(?) Other apps show the characters 
correctly so it is not a design flaw in the font.

Neville



___
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: Unicode mysteries

[Neville Smythe via use-livecode]

> 
>> Which should correspond to codepoints
>>   1F3F4 E0067 E0062 E0073 E0063 E0074 E007F
>> And indeed if I manually build a UTF-16 string with these code points
>> it does display as the flag of Scotland. So the lesson is that the
>> reported chunks are not to be naively trusted  --- tho not exactly a
>> bug given the documentation warning.
> 
> Well this would be a bug! If you try codepoint 1..14 - then you will see 
> that they alternate between a codepoint and zero - the codepoints appear 
> to correspond to the relevant surrogate pair codeunits. i.e. codepoint 
> is misinterpreting the index as a codeunit index, rather than a 
> codepoint index :|
> 
> If you file a bug then I suspect this can be fixed quite quickly (famous 
> last words of course!).


Thanks Mark, I will file a bug report.

I don’t *really* need the actual font the system uses to display unsupported 
codepoints. I was thinking of using it as a lazy way to find out which single 
codepoints are supported rather than having to parse the cmap tables in the 
font file. As a way of learning about unicode I was trying to writing an LC 
version of the character map/PopChar utilities; a project doomed to failure 
because it’s just too hard to find out which multi-codepoint glyphs are 
supported by a font. This is a question frequently asked on forums, but it 
seems there is no answer other than reverse engineering the morx table in the 
fontfile, which is way too complex to be worth the effort. There is a published 
list for Emoji fonts but that would not be possible for general ligatures or 
glyph variations presumably.

Any comment on the LC behaviour of treating the Rainbow flag (which is a 
multi-codepoint glyph composed of three characters)
as 3 separate text characters, requiring 3 backspace operations to delete it in 
a field, rather than a single backspace as works in TextEdit?  [The first 
backspace eliminates the rainbow flag glyph but leaves the white flag showing; 
the second backspace eliminates the invisible join codepoint, so to the user 
seems to do nothing; the third backspaced finally eliminates the last glyph.]  
Is this a design choice or a bug?

Bob: I am looking at the Digest, where nonstandard characters (even, 
annoyingly, quotes) are replaced by question marks, which makes code snippets 
very hard to read. Is there a setting I should change to fix this?

Neville
___
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

Unicode mysteries

[Neville Smythe via use-livecode]

I am trying to understand the mysteries of unicode encodings; the following may 
(or may not) be useful (or confusing) to others.

 The docs say the full chunk expression for a unicode character is
  byte i of codeunit j of codepoint k of character c  of str
(with the warning that this is 'not of general utility’ … indeed!)

Taking a look at the Emoji ‘flag of Scotland’ character gbsct which won’t 
display here but exists in the Apple Color Emoji font and in corresponding 
fonts for other platforms, I get

put gbsct into str
number of chars of str: 1

char 1 of str : gbsct number of codepoints of char 1 of str:  7
 codepoint:11F3F4   with 2 codeunits (D83C DFF4)
 codepoint:20   with 0 codeunits - seems to be a 
placeholder rather an actual codepoint
 codepoint:3E0067   (DB40 DC67)
 codepoint:40   
 codepoint:5E0062   (DB40 DC62)
 codepoint:60   
 codepoint:7E0073   (DB40 DC73)

number of codepoints of str: 7
number of codeunits of str: 14
number of codeunits of char 1 of str: 14

So there are 6 codeunits which are not in any codepoints (or at least not as 
reported by LC). They can be enumerated by looping over “codeunit j of str” 
rather than 'codeunit j of codepoint k of ..' Or by textEnccode(str,”UTF-16”) 
and then by enumerating the bytes of the binary encoded str.

Bytes in binary encoding = all the codeunits (encoding is actually in 
littleendian byte order, but given here in bigendian order, which is the order 
reported by enumerating the codeunits)
   D83C DFF4 DB40 DC67 DB40 DC62 DB40 DC73 DB40 DC63 DB40 DC74 DB40 DC7F

Which should correspond to codepoints
   1F3F4 E0067 E0062 E0073 E0063 E0074 E007F
And indeed if I manually build a UTF-16 string with these code points it does 
display as the flag of Scotland. So the lesson is that the reported chunks are 
not to be naively trusted  --- tho not exactly a bug given the documentation 
warning.

1F3F4 by the way is a black flag; the remaining codepoints are in the 
Variations unicode block. Amusingly the Rainbow flag emoji  is made up of 3 
characters, char 1 is a white flag, char 2 is an invisible vertical join 
instruction, char 3 is a rainbow. BTW, backspacing over the displayed Rainbow 
flag actually has to be done in three steps to remove the displayed glyph, 
which I think is not correct behaviour for an editor since it appears to the 
user as one unicode character. Apple's TextEdit for example deletes the Rainbow 
flag with a single backspace. There are nasties lurking here for text 
manipulation LC code. Perhaps there should be a new string element 
‘unicodeChar’? BTW I have nothing but huge admiration for the LC unicode 
implementation team, it is a subject of extreme complexity.

Another question (which I think has been raised before but I don’t think there 
was an answer?). When a character (codepoint) in a string is displayed, if the 
requested font does not have that codepoint the OS substitutes a glyph from 
another font (or the missing character glyph if no font supports the 
codepoint). So for example if you change the font of the above flag of Scotland 
to Arial, it still displays as the flag of Scotland, even though this glyph is 
not in Arial. LC will still report that the font of this character is Arial: 
from what I can gather this is not the fault of LC, the OS is doing this 
substitution behind its back (TextEdit does the same). But is there any way to 
find out (programatically) the actual font being used? 
   
   


___
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: Bug drawing card in LC9

[Neville Smythe via use-livecode]

A workaround for the bug is to use any visual effect in the Go to Card B script

In fact to force a redraw of a card you can use

visual effect plain
go to this cd

for example in an openCard handler. In interesting trick to remember!

Neville Smythe




___
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

Bug drawing card in LC9

[Neville Smythe via use-livecode]

In LC 9.0.1 and later, a card in a stack is incorrectly drawn under the 
following circumstances:
.  the stack has a menubar set as the stack menu, and the stack is running on a 
Mac
.  the user is on card A and moves to card B

The bottom part of card B (the height of the Mac menubar) is not redrawn, it 
still shows that part of card A. This bug occurs in the IDE and standalone. 

This is most easily seen if card A and card B have different background 
colours;  an example is at  bug 22027 
 — Panos has confirmed the 
bug.

If you resize the stack, card B is correctly displayed; or in edit mode if you 
drag the mouse in the bottom band, parts of card B appear under the mouse. 
Evidently the cliprect or invalRect used for refreshing the screen after 'Go to 
card x' is set incorrectly. On Windows or Linux, where the stack is not 
scrolled to hide the menubar, the card is drawn correctly.

Strange that this doesn’t seem to have been reported before; I suppose like me 
people don’t usually use this lower margin of a card or perhaps only for a 
shared background navigation bar, and use the same background colour for all 
cards in a stack.

A workaround until the bug is fixed would be to force a redraw in an openCard 
handler -- though now I come to think of it how does one do that? I can’t find 
a redraw or invalidateRect command…

Neville Smythe



___
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: What is Macintosh equivalent of relaunch handler?

[Neville Smythe via use-livecode]

Bill:

I agree sockets is the way go for communication between apps. AppleScript is 
great but can be frustrating until you get the hang of it.

The recipe for setting up socket communication is briefly:

. write a small unix shell script which your LC app installs [one caveat: the 
client must allow your app to install an executable script into /usr/local/bin]
this app simply collects the input parameters, opens a socket with 
“nc   ” 
and send the the params to the socket

The 3rd part app calls this script with a shell command “/usr/local/bin 
myScript param1 param2 “ etc [multi world parameters in quotes to form a single 
string]

. on the LC side, your app on launch (or whenever) opens a socket with
“accept connections on port  with message “clientConnected”

Then whenever the shell script is called, your “clientConnected” handler will 
be invoked. 

You read the message sent with"read from socket …” and parse the message sent 
and process it.
You can also write back to the shell with "write to socket…” if you want, for 
the 3rd party to use a reply directly (or of course send data via item files)

Works great! I actually use it to send a filename as first parameter, where the 
file is an LC script, and the processing is simply ”do script ”, 
having put any extra parameters into local variables. This way I can open up 
the whole of the LC app to remote control. You can provide the client with 
prepared script files for particular jobs, without have to rewrite your LC app 
when you want to open up access to a feature. Do script could open up a 
security risk, but you could only accept encrypted files if this is a worry.

As opposed to using AppleScript, this approach will also work if the client 
runs your LC app on a Linux box.

Question for the forum: how to make this work on a Windows box — is there an nc 
equivalent in a command shell for Windows? (I am not a Windows user but some of 
my clients are) 



Neville Smythe



___
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

tabbed windows

[Neville Smythe via use-livecode]

Extraordinary thanks, Paul, you have reduced my blood pressure by 30 points. I 
can’t think why I so obtuse as to not think of going to a different app and 
then sliding from the Development menu to the View menu! Simples!



___
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

tabbed windows in Mac - as setProp

[Neville Smythe via use-livecode]

Well it seems the feature is “tabbed” windows. It is a feature of High Sierra. 
However for non-Apple apps it has to be implemented by the third party, and in 
this case I think the LC implementation is faulty.  I can add windows to the 
tabs, but not remove the last tab.There is supposed to be a menu item in the 
Windows menu to turn the feature on and off, but it’s not there. I can’t turn 
it off and I have no idea how it got turned on, presumably a combination of 
option keys while the cat was walking across the keyboard. Yesterday upon the 
stair I met a man who wasn’t there … I wish, I wish he’d go away.
___
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

setProp question - stacked windows

[Neville Smythe via use-livecode]

Aha. My first thought was that it must be a Mac system “feature” since the 
iconised version looked Mac-ish rather than LC-ish. But I hadn’t updated to 
Mojave, and I had just updated to LC9.0.1 and it didn’t affect LC8, so I 
deduced it was down to LC. Thanks Brian, you have given me a place to look for 
configuring this ”stacked widows” thingie. 
___
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 setProp question

[Neville Smythe via use-livecode]

Thanks for the replies about may setProp question a little while back. But 
no-one game me any info about the annoying problem I raised concerning windows 
under LC9 and it’s driving me nuts.

To recap: new stacks (but not old stacks)  and some engine windows such as for 
scripts and the dictionary open up with a second title bar just under the main 
one. The bar gives no extra information and apart from wasting space the only 
purpose seems to be to provide a way to iconise the window when it is dragged, 
reducing the window to a small square and then redisplaying it in sometimes 
strange places, like offscreen, and sometimes expanded to fill the whole screen 
with the bottom below the Mac dock so it is not resizable. I hadn’t noticed it 
in a dp release of LC9 so I presume it is an “enhancement” in LC9.0.1; the 
stacks display as usual under LC8 [The question marks which will replace my 
quotes around the word enhancement are entirely appropriate]. 

So maybe you all see it. But does it really behave for you as it does for me — 
every time the window opens it appears further up the screen by the width of 
the bar, and soon the top of the window disappears under the Mac menu bar, and 
so  becomes uncloseable. With a small script in the 4DDevo tool I can now 
reposition and resize it with a single click but it remains a major annoyance 
when trying to manage screen real estate on a laptop. Surely there is a way to 
turn this thing off. Grrr!
___
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

setProp question

[Neville Smythe via use-livecode]

Is there any way to intercept setProp messages for properties you *don’t* want 
to set?

I find with my poor typing skills I keep typing

Set the  of 

where NonexistentProperty is a mistype of SomePropertyWhichHasASetPropHandler

and so I keep creating lots of superfluous properties for the object. Annoying 
and sometime painful to clean up.
When you are initially creating the object properties this is not a problem but 
once the structure is set up I'd like to declare “enough”, maybe with a 
LockProperties command
(come to think of it locking changes to existing properties might be useful 
too, though that can be coded into each SetProp handler)

Also, on another topic: my LiveCode windows have suddenly acquired a second 
title line, which when dragged tends to miniaturise the window and then display 
it somewhere else or at full screen, and each time a script editor window is 
opened it is moved higher up the screen until it moves under the menubar and 
becomes unusable. Looks look a system thing (Mac High Sierra) but I’ve never 
seen it before and only just changed to LC9.0.1. Any suggestions as to how to 
stop this major annoyance would be appreciated - or at least configure it if it 
really is a new LC ”feature".
___
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: Slow LC 9 Performance

[Neville Smythe via use-livecode]

ops, I should have waited for the next use-livecode email for the answer to my 
question! Thanks Curry


Neville Smythe
___
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: Slow LC 9 Performance

[Neville Smythe via use-livecode]

Curry:

Your last benchmark mentioned that this was a test for Windows 10. I may have 
missed this qualifier in the previous discussion: do I take it that the 
slowdown in performance noted are all Windows 10 tests? Has performance on Mac 
and Linux also degraded by similar amounts?

I ask because of the earlier discussion of the drastic slowdown in saving a 
stack under Windows 10 [bug 21305 
] (from x10 to x30 longer 
than on a Mac or Linux box). This applies to LC 8, and is a comparison between 
platforms rather than versions of LC, but if the answer to my second question 
above is no, then it would particularly direct attention of the engineers to 
the Windows engine.

BTW, just for interest I ran the repeat loop  benchmark in LC8 on my Mac, and 
then Windows 10 and  Linux Ubuntu 16.04 both under Parallels emulation on the 
same Mac. As expected the Windows 10 run was a little slower (about 12% slower) 
than the Mac 64 bit test, understandable given it is running in emulation. But 
the Linux run was about  10% *faster* than the Mac!!

Neville Smythe
___
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: how to clear residual garbage in a stack?

[Neville Smythe via use-livecode]

> I haven't actually tried it but would it work to just put empty into the 
> field before deleting the card? That would be sort of a "clean as you go" 
> approach.

That’s a very neat workaround which should leave at most a couple of bytes of 
uncollected garbage, until the bug is squashed.

Of course most people wouldn’t need to worry about the problem at all, the 
memory leak involved would hardly be noticeable for most stacks, it’s just that 
it accumulates over time.

I have submitted the bug, and also the Windows 10 saving problem which is 
really my concern, to QualityControl.

Neville Smythe  
___
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: how to clear residual garbage in a stack?

[Neville Smythe via use-livecode]

So now we have confirmed the 
“delete-card-with-unshared-textfield-leaves-unreferenced-text-which-compact-does-not-remove”
 bug (thanks to Brian and Richard) the question remains how to actually remove 
the garbage.

As Brian says deleting the background groups will remove the residual text; you 
then  have the task of replacing the groups. I have found that a simpler 
method: turning on sharedText, then turning it back off and replacing text also 
works.

So, a recipe is
1. Copy the target stack, don’t work on the original
2. Go through the stack (and its substacks) to find background groups which 
have fields with sharedText false (this is an outer loop for each stack)
3. Find all cards which such groups
4. Save the text from every found field from every found card into an array
5. Turn on sharedText for each field
6. Visit each card and put empty into each found field (not sure if this step 
is necessary, but I think it is)
7. compact the stack
8. Turn off sharedText for each field
9. Visit each card to replace the individual text saved in the array
10.Save the stack.

Sounds complex but the process took only a couple of seconds to clean up my  
9MB stack with 325 cards + lots of substacks and lots of groups. It saved 
1.5MB, not as much as I was hoping but still worthwhile. That’s 15% off the 
time Windows 10 users have wait for save to finish.

This is not a workaround for the bug. It is a fix for affected stacks.
  
Neville Smythe
___
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: how to clear residual garbage in a stack?

[Neville Smythe via use-livecode]

Thanks Richard. 

Disregard my nonsense about the EOF at 28KB, I misread the BBEdit output. The 
file did indeed have extra garbage after deleting all but 1 card. 

The extraneous data actually consists of the text of the background field from 
the deleted cards: “Lorem ipsum” occurs 2024 in the hex dump, but Find and 
Replace can only find 18 instances, all in the single card remaining.  Very 
similar to the unplaced background groups left over as you reported if the 
cards are created by copy-and-paste, but in this case I created them with new 
card (with a field in a background group). This bug is worse because there is 
no handle to the orphaned text in the browser or menus! Note that I’m still 
thinking of this as a bug, rather than a problem with my system :-) - it 
happens in Windows as well.

Brian Milby tells me that he could not replicate the bug in LC 9 if the cards 
are created with with copy-and-paste and no background groups.  I’ll do some 
more testing with LC9, with and without a background group and the two methods 
of creating cards (and on Windows and Linux). My guess is that compact stack is 
not working correctly in the case of deleting cards with background fields in 
LC8, and this may or may not have been fixed in LC9. 

Brian does also confirm the slow saving in Windows 10, in fact his times are 
much worse. Are there no longer any Windows 10 users of LC? (to be fair my 
stacks compiled under LC 8.1.x do perform well under Windows 10 except for the 
terrible saving problem). 

Neville Smythe
___
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: how to clear residual garbage in a stack?

[Neville Smythe via use-livecode]

Hmm, excellent suggestions from Phil and Richard, but evidently something else 
is going on.

> Use "compact stack" to get rid of space formerly used by now-deleted 
> objects.

compact stack did not recover the 8 MB after deleting all but the first card 
from my test stack to reduce it to what should be a 28KB file.

> Does your card contain a group with its backgroundBehavior set to true?
> 
> If so, and if the cards are created with copy and paste, I believe you 
> may find a large number of unplaced groups in the stack.

The extra cards were created using create, not copy-and-paste, there is only 1 
group in the stack before and after deleting extra cards.

Actually I just did a hex dump of the 8MB file saved from the 1 card stack; and 
lo! it has an EOF at about the 28KB position, at which point BBEdit stops 
dumping the file; up to that point it appears to be the correct data for a 1 
card stack, no extraneous garbage. But the system reports it as an 8MB file. 
Doesn’t that mean the file was not closed correctly by the save stack command, 
or that compact stack is not working correctly to reduce the internal memory 
and save stack is blindly writing bytes beyond the EOF, so either way it is a 
bug?
 
All of which is peripheral to my original aim of finding out what is going on 
with LC and Windows 10


Neville Smythe
___
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: how to clear residual garbage in a stack?

[Neville Smythe via use-livecode]

Thanks Phil, I knew there had to be a command. Of all the synonyms I tried I 
got close with compress ;-)

Turns out a stack of  mine used by national organisation for 20 years had 
bloated from 3MB to 9MB.

> Use "compact stack" to get rid of space formerly used by now-deleted 
> objects.

 
Neville Smythe
___
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

how to clear residual garbage in a stack?

[Neville Smythe via use-livecode]

I am constructing a large stack as a test for a bug report (to report the slow 
saving of large stacks for a standalone Windows 10 app under LC 8.x). I start 
with a stack with a single card which saves as a 28 KB file. I then use a 
script to create 299 copies of card 1. The resulting stack saves to a 8.2 MB 
file. As expected. 

I then deleted all but the first card, and re-ran the script so it again had 
300 cards. This saves to a 16.4 MB file! Repeating the delete-and-create gives 
a 24 MB file. Evidently the data for the deleted cards has not been removed. I 
can think of efficiency reasons why this might be useful in the IDE, but there 
must/should be a way to reduce the file size to a minimum, otherwise stacks 
which continually delete and create data will just grow in a very 
user-unfriendly way. 

I can’t find any command such as clean or purge or free or compress or release 
garbage which will reduce the file size to its actual requirements. I have a 
vague memory of this being raised some years ago but I can’t find the 
reference. Surely there must be a built-in command? Because the only way I can 
see to reduce the size would be to create a new stack and copy over all cards 
and scripts and substacks before saving, which is ridiculous.

BTW The bug: The 8.2MB stack saves on a Mac in 0.27 seconds. On Windows 10 
saving time is 6.4 seconds. Other apps on Windows save an 8 MB file in under a 
second so the problem is not with the Windows OS or antivirus virus software or 
the particular machine. Possibly this bug is related to the reported 
unusablility of LC 9 IDE on Windows 10, of which I have heard no more since it 
was raised in this forum a few weeks ago, although my context is a standalone 
compiled under LC  8.x. 

Neville Smythe
___
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

LC on Windows 10

[Neville Smythe via use-livecode]

My users find Windows 10 takes 10 seconds or more to save a 9Mb stack with app 
compiled under 8.1.x, Mac and Linux save in a fraction of a second. Very 
annoying as the app freezes while saving.

$@%?$@%?$@%?$@%?$@%?$@%?
Neville Smythe
IGF Director (Oceania)
VicePresident, Australian Go Association


Sent from my iPad

___
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