Re: LC 9.0.0 dp8 won't launch iOS simulator

[William Prothero via use-livecode]

Thanks for the ideas. I’ll do those things, Evergreen. I have been using iPhone 
6 and above, but tomorrow, after a night’s sleep, I’ll follow the suggestions.

Thanks!
Bill P


> On Aug 11, 2017, at 10:43 PM, panagiotis merakos via use-livecode 
>  wrote:
> 
> Hi Bill,
> 
> In LC 9dp7 (or dp8, not 100% sure), we removed support for 32bit
> simulators. This means that if your simulator is set to iPhone SE or
> iPhone5, the standalone will not launch. So you have to choose a 64bit
> simulator (iphone6 and above).
> 
> Best regards,
> Panos
> 
> 
> 
> On Aug 12, 2017 05:20, "William Prothero via use-livecode" <
> use-livecode@lists.runrev.com> wrote:
> 
>> Folks:
>> I’m trying to work on a new app that will send an sms message in iOS. But,
>> as it usually happens when I don’t use the simulator and XCode for a month
>> or so, new version come along and chaos seems to ensue. I had all of this
>> working in LC 8.1.4.
>> 
>> I’ve been working with LC 8.2.6 and LC9.0.0 (dp8) I downloaded XCode
>> 8.3.3, but have XCode 8.3 and 8.2 installed. When I started, LC 8.2.6 would
>> launch the simulator ok. But 9.0.0 wouldn’t. After fiddling around a bit,
>> LC 8.2.6 would no longer launch the simulator. I get the following error
>> message on all versions, no matter what I put into the LiveCode preferences
>> for XCode:
>> 
>> “Unable to start simulator 634,0,0,notoolset 573,220,1,
>> revPhoneSetSimulatorSDK
>> 
>> I deleted the LC Preferences files and it didn’t fix anything.
>> 
>> So…. I have 3 versions of XCode (8.2, 8.3, 8.3.3)  in my application
>> folder. These have been downloaded from the developer portal. Is it ok to
>> have all of them in my applications folder, then enter them into the LC
>> Preferences->mobile Support pane? Or will it mix up software from different
>> versions of XCode in my app folder?
>> 
>> Do I need to download additional tools for XCode?
>> 
>> This is extremely frustrating. I did note that there was a red/green box
>> in the LC mobile support pane in preferences, which should indicate the all
>> the XCode support files are correct for the running version of LC. This
>> doesn’t seem to be the case, though. It does respond to the version loaded,
>> though, which is something.
>> 
>> For me, this is the most frustrating part of livecode. Can’t more be done
>> to check configurations and provide clear and complete error messages when
>> things aren’t right?
>> 
>> Best,
>> Bill P
>> 
>> William A. Prothero
>> http://earthlearningsolution.org/
>> 
>> ___
>> 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


___
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: LC 9.0.0 dp8 won't launch iOS simulator

[panagiotis merakos via use-livecode]

Hi Bill,

In LC 9dp7 (or dp8, not 100% sure), we removed support for 32bit
simulators. This means that if your simulator is set to iPhone SE or
iPhone5, the standalone will not launch. So you have to choose a 64bit
simulator (iphone6 and above).

Best regards,
Panos



On Aug 12, 2017 05:20, "William Prothero via use-livecode" <
use-livecode@lists.runrev.com> wrote:

> Folks:
> I’m trying to work on a new app that will send an sms message in iOS. But,
> as it usually happens when I don’t use the simulator and XCode for a month
> or so, new version come along and chaos seems to ensue. I had all of this
> working in LC 8.1.4.
>
> I’ve been working with LC 8.2.6 and LC9.0.0 (dp8) I downloaded XCode
> 8.3.3, but have XCode 8.3 and 8.2 installed. When I started, LC 8.2.6 would
> launch the simulator ok. But 9.0.0 wouldn’t. After fiddling around a bit,
> LC 8.2.6 would no longer launch the simulator. I get the following error
> message on all versions, no matter what I put into the LiveCode preferences
> for XCode:
>
> “Unable to start simulator 634,0,0,notoolset 573,220,1,
> revPhoneSetSimulatorSDK
>
> I deleted the LC Preferences files and it didn’t fix anything.
>
> So…. I have 3 versions of XCode (8.2, 8.3, 8.3.3)  in my application
> folder. These have been downloaded from the developer portal. Is it ok to
> have all of them in my applications folder, then enter them into the LC
> Preferences->mobile Support pane? Or will it mix up software from different
> versions of XCode in my app folder?
>
> Do I need to download additional tools for XCode?
>
> This is extremely frustrating. I did note that there was a red/green box
> in the LC mobile support pane in preferences, which should indicate the all
> the XCode support files are correct for the running version of LC. This
> doesn’t seem to be the case, though. It does respond to the version loaded,
> though, which is something.
>
> For me, this is the most frustrating part of livecode. Can’t more be done
> to check configurations and provide clear and complete error messages when
> things aren’t right?
>
> Best,
> Bill P
>
> William A. Prothero
> http://earthlearningsolution.org/
>
> ___
> 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

LC 9.0.0 dp8 won't launch iOS simulator

[William Prothero via use-livecode]

Folks:
I’m trying to work on a new app that will send an sms message in iOS. But, as 
it usually happens when I don’t use the simulator and XCode for a month or so, 
new version come along and chaos seems to ensue. I had all of this working in 
LC 8.1.4. 

I’ve been working with LC 8.2.6 and LC9.0.0 (dp8) I downloaded XCode 8.3.3, but 
have XCode 8.3 and 8.2 installed. When I started, LC 8.2.6 would launch the 
simulator ok. But 9.0.0 wouldn’t. After fiddling around a bit, LC 8.2.6 would 
no longer launch the simulator. I get the following error message on all 
versions, no matter what I put into the LiveCode preferences for XCode: 

“Unable to start simulator 634,0,0,notoolset 573,220,1,revPhoneSetSimulatorSDK

I deleted the LC Preferences files and it didn’t fix anything. 

So…. I have 3 versions of XCode (8.2, 8.3, 8.3.3)  in my application folder. 
These have been downloaded from the developer portal. Is it ok to have all of 
them in my applications folder, then enter them into the LC Preferences->mobile 
Support pane? Or will it mix up software from different versions of XCode in my 
app folder?

Do I need to download additional tools for XCode?

This is extremely frustrating. I did note that there was a red/green box in the 
LC mobile support pane in preferences, which should indicate the all the XCode 
support files are correct for the running version of LC. This doesn’t seem to 
be the case, though. It does respond to the version loaded, though, which is 
something.

For me, this is the most frustrating part of livecode. Can’t more be done to 
check configurations and provide clear and complete error messages when things 
aren’t right?

Best,
Bill P

William A. Prothero
http://earthlearningsolution.org/

___
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: Ink pullDown menu

[Paul Hibbert via use-livecode]

The fontNames is a built-in function, but there’s no built-in function for ink 
names AFAIK, however, that doesn’t stop you form creating a custom function, 
something like this should work for an option menu button (edit as appropriate):

on mouseEnter
   if word 1 of the selectedObject = "image" then
  put inkNames("img") into me
   else
  put inkNames() into me
   end if
end mouseEnter

function inkNames pChoice
   if pChoice = "img" then
  return "blendPlus" & cr & \
"blendMultiply" & cr & \
"blendScreen" & cr & \
"blendOverlay" & cr & \
"blendDarken" & cr & \
"blendLighten" & cr & \
"blendDodge" & cr & \
"blendBurn" & cr & \
"blendHardLight" & cr & \
"blendSoftLight" & cr & \
"blendDifference" & cr & \
"blendExclusion"
   else
  return "blendClear" & cr & \
"blendSrc" & cr & \
"blendDst" & cr & \
"blendSrcOver" & cr & \
"blendDstOver" & cr & \
"blendSrcIn" & cr & \
"blendDstIn" & cr & \
"blendSrcOut" & cr & \
"blendDstOut" & cr & \
"blendSrcAtop" & cr & \
"blendDstAtop" & cr & \
"blendXor"
   end if
end inkNames

Paul


> On Aug 11, 2017, at 9:39 AM, Richmond Mathewson via use-livecode 
>  wrote:
> 
> I can have a pullDown menu with this sort of script:
> 
> put the fontNames into me
> 
> how can I do the smae sort of thing for Ink?
> 
> e.g. (pseudocode): put the inkNames into me
> 
> Richmond.
> ___
> 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

RE: Livecode Mobile App in Background

[J. Landman Gay via use-livecode]

I think I remember that "wait" is a problem too.

Meanwhile I know of no solution for Android. The OS controls what runs in 
the background and when it gets wiped from RAM. You'll never know when that 
happens either. It's an issue that causes trouble.


If anyone knows of a solution before I talk about this in my presentation 
on Thursday, do tell.


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



On August 11, 2017 9:34:41 PM Ralph DiMola via use-livecode 
 wrote:


There are a couple of hitches.. I believe that Mark said that timers going 
off while running in the background may not work or lock up the app. There 
are other issues but I have not had any problems. It's an option in v9 iOS 
standalone setting but it's a "use at your own risk" type of thing.


Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf 
Of Dan Friedman via use-livecode

Sent: Friday, August 11, 2017 10:12 PM
To: use-livecode@lists.runrev.com
Cc: Dan Friedman
Subject: Re: Livecode Mobile App in Background

Ralph,

Thank you for the detailed reply!   I tried it and it seems to work great.  
 One question… if it’s that simple, why hasn’t LiveCode offered this as a 
feature?   Seems like it would take a few minutes to write this in?   Is 
there a catch to using this method?


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




___
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: Livecode Mobile App in Background

[Ralph DiMola via use-livecode]

There are a couple of hitches.. I believe that Mark said that timers going off 
while running in the background may not work or lock up the app. There are 
other issues but I have not had any problems. It's an option in v9 iOS 
standalone setting but it's a "use at your own risk" type of thing.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Dan Friedman via use-livecode
Sent: Friday, August 11, 2017 10:12 PM
To: use-livecode@lists.runrev.com
Cc: Dan Friedman
Subject: Re: Livecode Mobile App in Background

Ralph,

Thank you for the detailed reply!   I tried it and it seems to work great.   
One question… if it’s that simple, why hasn’t LiveCode offered this as a 
feature?   Seems like it would take a few minutes to write this in?   Is there 
a catch to using this method?

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

Re: common code patterns

[Dan Friedman via use-livecode]

Here’s my silly contribution.   How many times do we write something like this:

put “Are you sure you want to delete the image” && quote & myImageName & quote 
&& “?” into tPrompt

I have a simple q() function in all my projects:

function q inData
  return (quote & inData & quote)
end q

Now, I can simply do this:

put “Are you sure you want to delete the image” && q(myImageName) & “?” into 
tPrompt

Tiny, but mighty.   :)

-Dan
___
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: Livecode Mobile App in Background

[Dan Friedman via use-livecode]

Ralph,

Thank you for the detailed reply!   I tried it and it seems to work great.   
One question… if it’s that simple, why hasn’t LiveCode offered this as a 
feature?   Seems like it would take a few minutes to write this in?   Is there 
a catch to using this method?

-Dan
___
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: common code patterns

[dunbarx via use-livecode]

The subThread about Switch/Case is a current thread on the forum:

  

Craig



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/common-code-patterns-tp4718218p4718394.html
Sent from the Revolution - User mailing list archive at Nabble.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: Livecode Mobile App in Background

[Jonathan Lynch via use-livecode]

Here are the instructions Ralph made. I think you can now load up your own 
custom plist if you want to, but these steps work. 

Big thanks to Ralph for this:)

1) Go to the Applications folder
2) Right click on the LC app you are using and select "Show Package
Contents"
3) Navigate to the "Tools/Runtime/iOS" folder
4) Right click on all the device/simulator folders one at a time and select
"Get Info"
5) At the bottom click on the "Read only" to the right of your account name
and select "Read & Write"
6) Repeat 5 for all device/simulator folders
7) In each of the device/simulator folders edit the setting.plist file.
8) To edit... right click the setting.plist file and select "Open With" and
then "Other..." and select "TextEdit.app".
9) You will get a warning that the file is locked. Choose the Unlock option.

10) Either change UIApplicationExitsOnSuspend key value to "False" or like I
do delete the key all together(2 lines)
11) repeat 8-10 for setting.plist in each of the device/simulator folders.
12) Fire up LC and make an iOS app.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

Sent from my iPhone

> On Aug 11, 2017, at 9:24 PM, jonathandly...@gmail.com wrote:
> 
> The plist can be edited for this. If you search plist on this list, you will 
> find instructions.
> 
> Augmented Earth hibernates rather than being shut down.
> 
> Sent from my iPhone
> 
>> On Aug 11, 2017, at 9:10 PM, Dan Friedman via use-livecode 
>>  wrote:
>> 
>> There’s been a lot of talk about this, but does any one have a working 
>> method for getting the app to not exit when it’s suspended?   Need a 
>> solution for both iOS and Android.  If it could stay alive for like 10 
>> munites, that’s all I need.  My client doesn’t want the app to have to 
>> completely reload (app boot is a little lenghty) just to bring up a 
>> calculator to add a few numbers.   They want it to work like most apps do.
>> 
>> Any solution would be a lifesaver!!
>> 
>> -Dan
>> ___
>> 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

Re: [OT] HyperCard preservation society

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 11:27 am, Mark Wieder via use-livecode 
>  wrote:
> 
> LOL... "PRINT PEEL & STICK VHS LABELS"

Not betamax? C’mon!
___
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: [OT] HyperCard preservation society

[Mark Wieder via use-livecode]

On 08/11/2017 08:00 AM, Ben Rubinstein via use-livecode wrote:

This is fabulous:

http://blog.archive.org/2017/08/11/hypercard-on-the-archive-celebrating-30-years-of-hypercard/ 


LOL... "PRINT PEEL & STICK VHS LABELS"

srsly, though... happy 30th, HyperCard.

--
 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: Livecode Mobile App in Background

[Jonathan Lynch via use-livecode]

The plist can be edited for this. If you search plist on this list, you will 
find instructions.

Augmented Earth hibernates rather than being shut down.

Sent from my iPhone

> On Aug 11, 2017, at 9:10 PM, Dan Friedman via use-livecode 
>  wrote:
> 
> There’s been a lot of talk about this, but does any one have a working method 
> for getting the app to not exit when it’s suspended?   Need a solution for 
> both iOS and Android.  If it could stay alive for like 10 munites, that’s all 
> I need.  My client doesn’t want the app to have to completely reload (app 
> boot is a little lenghty) just to bring up a calculator to add a few numbers. 
>   They want it to work like most apps do.
> 
> Any solution would be a lifesaver!!
> 
> -Dan
> ___
> 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

Re: App Rejected: IPv6 network?

[Andre Garzia via use-livecode]

It used to be the case that Apple would only allow JS to be downloaded, all
other languages could not run. Of course the static analysis system is not
perfect and probably it can't detect that that is what is happening with
our LC apps, but the terms were clear that you could not download code from
outside. That caused rejections in many other communities.

On Thu, Aug 10, 2017 at 4:27 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> jonathandlynch wrote:
> > LC scripts are not executable code?
>
> They are to the LiveCode engine, but not to the OS.
>
> LiveCode Script has no access to the OS, and can't touch anything outside
> of the LiveCode engine.
>
> So from the OS perspective, scripts are just data, like glorified
> spreadsheet formulas.  All sandboxing and other API evaluation is relevant
> to the LC Engine.
>
> --
>  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
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening 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

Livecode Mobile App in Background

[Dan Friedman via use-livecode]

There’s been a lot of talk about this, but does any one have a working method 
for getting the app to not exit when it’s suspended?   Need a solution for both 
iOS and Android.  If it could stay alive for like 10 munites, that’s all I 
need.  My client doesn’t want the app to have to completely reload (app boot is 
a little lenghty) just to bring up a calculator to add a few numbers.   They 
want it to work like most apps do.

Any solution would be a lifesaver!!

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

mobilePick width on iPhone 6

[Dan Friedman via use-livecode]

Anyone know why the width of the click wheel when calling mobilePick on an 
iPhone 6 is only about ¾ of the width of the screen?  How do you go about 
fixing this?

-Dan

___
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: common code patterns

[Alex Tweedly via use-livecode]

On 11/08/2017 23:17, Monte Goulding via use-livecode wrote:

On 11 Aug 2017, at 9:40 am, Alex Tweedly via use-livecode 
 wrote:

repeat with i=1 to paramcount()-1
put param(i)&"," after theValue
end repeat
put param(paramcount()) after theValue

Shorter, faster, and just plain tidier :-)

Hmm… there’s a few reasons I’m not a fan of this pattern:

- you can’t really clearly document the handler parameters although this could 
feasibly be worked around by redefining what a parameter is in your docs
Well, it's not my pattern (in fact, initially I didn't even spot that it 
did this "trick" to handle a point) - so I may be the wrong one to 
defend it - but here goes.


The common use case is where the parameters are any one of
 - one or two points
 - a rect
 - one to four coords
(i.e. anywhere you are basically passing in a rectangle in the various 
common flavours).


I think I've seen it in  few places (presumably Geometry Engine, maybe 
one of the chart libraries, etc.)


-- Alex.

___
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: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 03:21 PM, Monte Goulding via use-livecode wrote:


Ha… I hadn’t considered that you might want the elements sorted instead of the 
keys but of course you might… well I’m not sure I just know I’d really like to 
have a way to iterate sorted keys and elements…
I'm not trying by any means to say that the idea isn't good. I'm also in 
favor of having a way to sort keys and elements other than the obvious. 
I just think that syntax is awkward.


--
 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: common code patterns

[Ralph DiMola via use-livecode]

I may not be obvious but neither is the sort command. When I start LC I
could not grasp "each" and what it did to what from who, but that's me. I
digress. I can't tell you how many times I've done:

Local tKeys
Put the keys of pArray into tKeys
Sort the lines of tKeys numeric
Repeat for each line tKey in tKeys
...



Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Dr. Hawkins via use-livecode
Sent: Friday, August 11, 2017 6:33 PM
To: How to use LiveCode
Cc: Dr. Hawkins
Subject: Re: common code patterns

On Fri, Aug 11, 2017 at 3:08 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/11/2017 02:59 PM, Mike Kerner via use-livecode wrote:
>
>> That is not easier to read.
>>
>
> Heh. Mike beat me to it.


. . .  After seven chalkboards of deprivation, the calculus professor
announce, "therefore, A is obviously equal to B"

A student timidly raised her hand, and said, "That's not obvious,
professor."

He scrawled three more boards, and triumphantly announced, "See, I told you
it was obvious!"

:)

--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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

Re: common code patterns

[Dr. Hawkins via use-livecode]

On Fri, Aug 11, 2017 at 3:08 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/11/2017 02:59 PM, Mike Kerner via use-livecode wrote:
>
>> That is not easier to read.
>>
>
> Heh. Mike beat me to it.


. . .  After seven chalkboards of deprivation, the calculus professor
announce, "therefore, A is obviously equal to B"

A student timidly raised her hand, and said, "That's not obvious,
professor."

He scrawled three more boards, and triumphantly announced, "See, I told you
it was obvious!"

:)

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: common code patterns

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 8:06 am, Mark Wieder via use-livecode 
>  wrote:
> 
>> I guess we could have more explicit syntax here which might be more flexible 
>> too
>> repeat for each element tElement and key tKey in tArray ordered numeric 
>> ascending
> 
> I must be channeling Mark Waddingham here... I'm worried that the syntax is 
> borderline not-xtalky. For instance, it's not obvious from looking at that 
> whether tElement or tKey is sorted numerically. By guess is that you intend 
> tKey to be sorted.

Ha… I hadn’t considered that you might want the elements sorted instead of the 
keys but of course you might… well I’m not sure I just know I’d really like to 
have a way to iterate sorted keys and elements…

Cheers

Monte
___
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: Speed of control lookup (Was Re: Parent of Target)

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 8:11 am, Mark Wieder via use-livecode 
>  wrote:
> 
>> Hmm… Would it be a good idea to create a new ID form with the bare minimum 
>> to identify an object. 
> 
> 
> UUID
> 

Let’s not start that again ;-)
___
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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 9:40 am, Alex Tweedly via use-livecode 
>  wrote:
> 
> repeat with i=1 to paramcount()-1
>put param(i)&"," after theValue
> end repeat
> put param(paramcount()) after theValue
> 
> Shorter, faster, and just plain tidier :-)

Hmm… there’s a few reasons I’m not a fan of this pattern:

- you can’t really clearly document the handler parameters although this could 
feasibly be worked around by redefining what a parameter is in your docs
- if any of your parameters may contain whatever delimiter you are using when 
parsing the params then everything breaks if you are using comma as suggested 
above then it’s not safe to pass object references to the handler.

So my question therefore is are there many people that use this pattern and 
should we throw it around a bit to get a more robust form or is this an edge 
case of a particular developer’s scripting style?

Cheers

Monte

___
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: Speed of control lookup (Was Re: Parent of Target)

[Mark Wieder via use-livecode]

On 08/11/2017 02:58 PM, Monte Goulding via use-livecode wrote:

Hmm… Would it be a good idea to create a new ID form with the bare minimum to identify an object. 



UUID


--
 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: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 02:59 PM, Mike Kerner via use-livecode wrote:

That is not easier to read.


Heh. Mike beat me to it.

--
 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: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 02:46 PM, Monte Goulding via use-livecode wrote:


I guess we could have more explicit syntax here which might be more flexible too

repeat for each element tElement and key tKey in tArray ordered numeric 
ascending


I must be channeling Mark Waddingham here... I'm worried that the syntax 
is borderline not-xtalky. For instance, it's not obvious from looking at 
that whether tElement or tKey is sorted numerically. By guess is that 
you intend tKey to be sorted.


--
 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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Mark Wieder via use-livecode]

On 08/11/2017 01:44 PM, J. Landman Gay via use-livecode wrote:


At the risk of starting a platform war.




No platform war on my part. I hate operating systems. Linux comes 
closest to what I want because I can configure it, it (mostly) doesn't 
keep dumbing down the interface and (mostly) doesn't try to tell me what 
I can have or try to be more in touch with what I want than I am.


searches I just don't use Chrome.) Android Now is close to psychic, 
volunteering information I want without my asking. I walked out of a 
theater one night and Android offered a map showing me where I'd parked. 
I didn't have to ask, it was just there. You can turn off these things 
but I find them useful. If you don't want Google to know where you are, 
turn off location services.


The scary part of that, of course, is that (Google in this case, but 
feel free to insert whatever mobile OS or government agency you want) 
knows exactly where you are.


--
 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: common code patterns

[Mike Kerner via use-livecode]

That is not easier to read.

On Fri, Aug 11, 2017 at 5:46 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> > On 12 Aug 2017, at 1:37 am, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > So, let me rephrase - what are the use-cases people can see for allowing
> (some variant of):
> >
> >   repeat ... with counter tCounter starting from tStart
>
> Hmm…. what about:
>
> repeat for each line tLine in line 5 to -1 of tLines with counter tCounter
> starting from 5
>
> BTW if we ever do this could the following be ordered if the array is a
> 1..N sequence… I’m not really sure if repeat for each element is ordered in
> any way currently.
>
> repeat for each element tElement in tArray with counter tCounter
>
> I guess we could have more explicit syntax here which might be more
> flexible too
>
> repeat for each element tElement and key tKey in tArray ordered numeric
> ascending
>
> Cheers
>
> Monte
>
>
> ___
> 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

Re: Speed of control lookup (Was Re: Parent of Target)

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 1:23 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> It has also suggested (to me, at least) a slightly different approach - we 
> make the return value of the 'long id' property of objects what you might 
> call a StringyLongId value. Instead of returning a string:
> 
>  button id 1003 of group id 1004 of card id 1002 of stack "MyStackName"
> 
> It would be a value which acts like a string, but internally stores:
> 
>[ BUTTON, 1003, [ 1004 ], 1002, "MyStackName" ]

Hmm… Would it be a good idea to create a new ID form with the bare minimum to 
identify an object. Say:

 id  of card id  of stack “”

Although I guess unplaced groups would need just  id  of stack 
“”

That would mean speed improvements could be done on an object reference that is 
relatively robust to changes in the object tree and unless you are creating an 
IDE you would be very unlikely to need to do the LCB object reference 
repository thing.

Cheers

Monte
___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Roger Eller via use-livecode]

I recently heard that Apple is planning a revolutionary smartwatch which
has calling functions built-in.  Seriously, no need to carry a phone!

Now Google it and see how many of these have existed for several years.
Revolutionary idea stealin' bunch!  lol

~Roger

On Aug 11, 2017 4:44 PM, "J. Landman Gay via use-livecode" <
use-livecode@lists.runrev.com> wrote:

On 8/11/17 10:51 AM, Dr. Hawkins via use-livecode wrote:

> I'd be tempted to switch to an android (I actually had the original
> gphone), but the privacy, hacks, and whathaveyou stop me.
>

At the risk of starting a platform war...



I love my Mac but I don't like iOS. It's too dumbed down to be useful.
Android has many advantages over iOS, the main one being that it has an
accessible file system like the Mac Finder (which I see iOS is about to
implement finally.) Not to mention launcher widgets, which I can't live
without, dozens of different launcher app options, and the ability to
customize almost anything the phone can do. It has menus and tooltips so
you don't have to memorize obscure gestures. Android Assistant is more
intelligent than Siri. Google provides unlimited photo storage without data
caps and uses intelligent algorithms to find photos without the need for
content tagging.

There are multiple apps for any purpose so you aren't required to use a
single authorized browser, email client, or anything else. I have three
browsers on my phone and four keyboards for different purposes. I had to
laugh when Apple finally allowed third-party keyboards. It's a start. (Try
SwiftKey, its prediction algorithms are the smartest anywhere and it is now
available for iOS.)

While Android malware is somewhat more prevalent than iOS, the actual risks
are exaggerated. Google has taken aggressive steps to reduce occurances,
which is only a tiny fraction of one percent anyway. There are nine layers
of security checks for every app you install. If you stick to the
authorized app stores you won't have trouble since almost all malware comes
from third-party downloads. Android also scans your apps in the background
even if you didn't download from their store, and recently added a manual
scan so you can check on demand. I've had 8 Android devices over the years
and never had any malware.

Privacy: Google gives you more control than Apple. You can delete all or
part of the data it stores at any time. You can control what it collects.
The trade-off, in my view, is worth the data collection. (One advantage of
multiple browsers is when I don't want Google to track my searches I just
don't use Chrome.) Android Now is close to psychic, volunteering
information I want without my asking. I walked out of a theater one night
and Android offered a map showing me where I'd parked. I didn't have to
ask, it was just there. You can turn off these things but I find them
useful. If you don't want Google to know where you are, turn off location
services.

I see Google as the pioneer that Apple used to be, and in fact, Apple has
started adopting popular Android features and claiming them as their own
(Windows 1.0 anyone?) Most of the upcoming iOS 11 features Apple is
bragging about incorporate Android features, most of which have been around
for years:

Notification system, document scanning, Finder-like file system, drag and
drop files to local storage or cloud services, language translations,
System UI Tuner ("customizable control center",) advanced camera control
apps, Android Beam ("AirDrop"), app drawer, customizable Do Not Disturb,
peer-to-peer Android Pay/Wallet ("Apple Pay",) Swapps ("persistent Dock".)
Apple says Siri now learns from you and syncs across devices. Android has
always done that.

Etc.




-- 
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
___
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: common code patterns

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 1:37 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> So, let me rephrase - what are the use-cases people can see for allowing 
> (some variant of):
> 
>   repeat ... with counter tCounter starting from tStart

Hmm…. what about:

repeat for each line tLine in line 5 to -1 of tLines with counter tCounter 
starting from 5

BTW if we ever do this could the following be ordered if the array is a 1..N 
sequence… I’m not really sure if repeat for each element is ordered in any way 
currently.

repeat for each element tElement in tArray with counter tCounter

I guess we could have more explicit syntax here which might be more flexible too

repeat for each element tElement and key tKey in tArray ordered numeric 
ascending

Cheers

Monte


___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[J. Landman Gay via use-livecode]

On 8/11/17 10:51 AM, Dr. Hawkins via use-livecode wrote:

I'd be tempted to switch to an android (I actually had the original
gphone), but the privacy, hacks, and whathaveyou stop me.


At the risk of starting a platform war...



I love my Mac but I don't like iOS. It's too dumbed down to be useful. 
Android has many advantages over iOS, the main one being that it has an 
accessible file system like the Mac Finder (which I see iOS is about to 
implement finally.) Not to mention launcher widgets, which I can't live 
without, dozens of different launcher app options, and the ability to 
customize almost anything the phone can do. It has menus and tooltips so 
you don't have to memorize obscure gestures. Android Assistant is more 
intelligent than Siri. Google provides unlimited photo storage without 
data caps and uses intelligent algorithms to find photos without the 
need for content tagging.


There are multiple apps for any purpose so you aren't required to use a 
single authorized browser, email client, or anything else. I have three 
browsers on my phone and four keyboards for different purposes. I had to 
laugh when Apple finally allowed third-party keyboards. It's a start. 
(Try SwiftKey, its prediction algorithms are the smartest anywhere and 
it is now available for iOS.)


While Android malware is somewhat more prevalent than iOS, the actual 
risks are exaggerated. Google has taken aggressive steps to reduce 
occurances, which is only a tiny fraction of one percent anyway. There 
are nine layers of security checks for every app you install. If you 
stick to the authorized app stores you won't have trouble since almost 
all malware comes from third-party downloads. Android also scans your 
apps in the background even if you didn't download from their store, and 
recently added a manual scan so you can check on demand. I've had 8 
Android devices over the years and never had any malware.


Privacy: Google gives you more control than Apple. You can delete all or 
part of the data it stores at any time. You can control what it 
collects. The trade-off, in my view, is worth the data collection. (One 
advantage of multiple browsers is when I don't want Google to track my 
searches I just don't use Chrome.) Android Now is close to psychic, 
volunteering information I want without my asking. I walked out of a 
theater one night and Android offered a map showing me where I'd parked. 
I didn't have to ask, it was just there. You can turn off these things 
but I find them useful. If you don't want Google to know where you are, 
turn off location services.


I see Google as the pioneer that Apple used to be, and in fact, Apple 
has started adopting popular Android features and claiming them as their 
own (Windows 1.0 anyone?) Most of the upcoming iOS 11 features Apple is 
bragging about incorporate Android features, most of which have been 
around for years:


Notification system, document scanning, Finder-like file system, drag 
and drop files to local storage or cloud services, language 
translations, System UI Tuner ("customizable control center",) advanced 
camera control apps, Android Beam ("AirDrop"), app drawer, customizable 
Do Not Disturb, peer-to-peer Android Pay/Wallet ("Apple Pay",) Swapps 
("persistent Dock".) Apple says Siri now learns from you and syncs 
across devices. Android has always done that.


Etc.



--
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Curry Kenworthy via use-livecode]

Mark:

> I think Johnathan made the best point here - if you want into the
> iOS world and the AppStore Apple provide you have to abide by their
> rules. However, if you don't care about the AppStore, then just
> jailbreak your phone and run free - no-one is stopping you.

> It is entirely your choice :)

No, it's not merely a personal matter by any stretch of the imagination. 
This is a social and tech reality that affects all of us, our 
technological environment. You are framing this as primarily a security 
matter to save the masses, with a handy personal jail break or xCode 
opt-out that solves the matter for any individual who feels differently. 
(No thanks on JB, nor do I generally recommend that to others. Nor is my 
interest mainly personal, but rather as a consultant and developer. I 
doubt most true end users feel comfy with xCode, assuming they even have 
a Mac.) Sorry, I tend to be a frame breaker! It's missing out on the 
bigger picture of Apple's system, and similarly the impact of tech 
trends, not only from Apple but other major players.


Much more complex, and it affects us far beyond our own choices. While 
someone here is waxing poetic about the security benefits, at one time 
or another someone has likely iPhoned that person's own data around 
insecurely in ways that would alarm you! Perhaps it has happened to you 
too without your knowledge. I've seen it too many times, very 
widespread. Often by people working for a reputable company or providing 
a vital professional service, but clueless or careless. Neither is the 
data completely secure even with companies that are more careful - the 
masses don't realize that. At the same time people are desensitized to 
sharing more data than ever. That makes them - and through them, 
sometimes you - very vulnerable.


Security goes way beyond malware. Security is an integral part of 
Apple's system, but it's not a system primarily for the sake of 
security. Fairly easy to have safe apps outside of a particular app 
store. One way would be setting up other download repositories that are 
checked. Another is using networked antivirus systems, which are already 
popular and advanced.


Going beyond security - breaking that frame again - it's much bigger. 
Richmond already had some good points, so maybe I don't need to add any, 
but for example: Actual publishing standards and choices are not all 
about security, quality, decency, and good style as advertised. 
Marketing versus reality. What viewpoints, topics, or potentially 
beneficial technologies might be suppressed? That would not be a big 
deal when there are multiple venues, but when there is one


The whole society is also affected by tech trends, and the circle goes 
around, consumer behavior and choices, how professionals use and 
sometimes misuse the tech (I'm seeing that too, it can be within the law 
but extremely harmful for consumers), data expectations and 
proliferation, over-availability or under-availability of information, 
control, ideology, intrusive or invasive trends, healthy awareness and 
ability versus dangerous dumbing down and complacency, more 
comprehensive security versus a sense of security or partial security, 
the effects of dependency on a single venue and its viewpoint and its 
quirks - in the end, everyone is touched.


Perceiving how technology trends impact society, and in turn come back 
to impact each of us, is very valuable and all too easy to overlook as 
we rush to keep up with those trends and create new ones. Definitely 
worth a look for those who don't want to avoid one type of risk only to 
fall into another! Stay safe. Hope everyone is doing well -- I haven't 
been able to pop up much here in the list lately.


Best wishes,

Curry Kenworthy

Custom Software Development
http://curryk.com/consulting/

___
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 LC Apps Downloading Stacks After installation

[Sannyasin Brahmanathaswami via use-livecode]

Mark, thanks for the thorough explanation.

I would go on record to say that "vision" for our use of such  post/sideloading 
option would fall well within th UI/UX of the existing app, since, from a 
design point of view our goals would want it to be virtually transparent.

That said, the CMS can get a bit snakey over time, and possibly a better way to 
go, at least in our context of wanting to add on new modules, would be to 
bundle the LC binary/views/script into updates that would be reviewed and then 
post download only   image-sounds-words-jsons-assets.gz bundles. unpack these 
and then binary uses them…

This then allow us to add more to the app without adding more  MB to the 
package size (since these LC binaries as pure view can be as small as 50 K) and 
then we just use side loading for what really *is* only *data*

this would be playing it very safe, and in someways, guard against ad hoc dev 
CMS which is too easy to do with LC 


BR

On 8/10/17, 9:56 PM, "use-livecode on behalf of Mark Waddingham via 
use-livecode"  wrote:

Taken from this point of view, and looking at very successful Apps 
(typically games) in the stores then you are probably fine if your 
stackfiles have data/code in them which parameterize the *existing* 
actions of the main app in reasonably limited ways.

So, for example, providing levels to a game where some parts require 
computations of expressions or triggering of particular events - as long 
as those levels are consistent with 'what the game is meant to do' (i.e. 
you don't make it do anything different from what it did with the levels 
bundled with the original submitted app). This model applies to any sort 
of 'content player' - language learning flash cards or lessons would be 
similar - you just have to be careful to make sure you don't end up 
expanding the ability of the main app in a way which is not directly 
'seeable' in the original submitted app.

___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Roger Eller via use-livecode]

You too, Richmond!   I agree with you that it's more about Apple greed than
making a safe, malware-free environment.  Stay safe from the Kool-ade.  :)

Kind regards,
~Roger



Roger Eller
Graphics Systems Analyst

803 North Maple Street P: 864.967.1625
Simpsonville, SC 29681 C: 864.908.0337
SealedAir.com  roger.e.el...@sealedair.com




On Fri, Aug 11, 2017 at 2:03 PM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Wow, Roger!
>
> You have "out devil's advocated me".
>
> Hope you have a great weekend.
>
> Richmond.
>
>
> On 8/11/17 8:38 pm, Roger Eller via use-livecode wrote:
>
>> On Fri, Aug 11, 2017 at 1:28 PM, Mark Waddingham via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>> On 2017-08-11 19:22, Richmond Mathewson via use-livecode wrote:
>>>
>>> So, I wonder why there is not a way of putting one's iPad app onot the
 web in a way (and I don't mean via Cydia)
 that will allow people to download it onto their tablets
 independently, as one can do on an Android device?

 There is - you build your app signed with your provisioning profile. You
>>> upload it. Someone else downloads it, and resigns it with there's.
>>>
>>> I'm sure there must be a utility out there which makes this 'easy' - it
>>> certainly seems simple enough to me - okay so not a nice 'store' type
>>> interface on your phone; you need to attach it to a computer. However,
>>> that
>>> is just a small wall to step over.
>>>
>>> Of course, it is contigent on having a Apple developer account but I'm
>>> pretty sure these days you don't need to pay the $99 unless you want to
>>> submit an app
>>>
>>> Um, and a Mac.  Some iOS device owners have PCs, and therefore no access
>> to
>> Xcode.
>>
>>
>> Warmest Regards,
>>>
>>> Mark.
>>>
>>> --
>>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>>> LiveCode: Everyone can create apps
>>>
>>
>>
>> ~Roger
>> ___
>> 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
>
___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Richmond Mathewson via use-livecode]

Wow, Roger!

You have "out devil's advocated me".

Hope you have a great weekend.

Richmond.

On 8/11/17 8:38 pm, Roger Eller via use-livecode wrote:

On Fri, Aug 11, 2017 at 1:28 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 2017-08-11 19:22, Richmond Mathewson via use-livecode wrote:


So, I wonder why there is not a way of putting one's iPad app onot the
web in a way (and I don't mean via Cydia)
that will allow people to download it onto their tablets
independently, as one can do on an Android device?


There is - you build your app signed with your provisioning profile. You
upload it. Someone else downloads it, and resigns it with there's.

I'm sure there must be a utility out there which makes this 'easy' - it
certainly seems simple enough to me - okay so not a nice 'store' type
interface on your phone; you need to attach it to a computer. However, that
is just a small wall to step over.

Of course, it is contigent on having a Apple developer account but I'm
pretty sure these days you don't need to pay the $99 unless you want to
submit an app


Um, and a Mac.  Some iOS device owners have PCs, and therefore no access to
Xcode.



Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps



~Roger
___
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

Re: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Roger Eller via use-livecode]

On Fri, Aug 11, 2017 at 1:28 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-11 19:22, Richmond Mathewson via use-livecode wrote:
>
>> So, I wonder why there is not a way of putting one's iPad app onot the
>> web in a way (and I don't mean via Cydia)
>> that will allow people to download it onto their tablets
>> independently, as one can do on an Android device?
>>
>
> There is - you build your app signed with your provisioning profile. You
> upload it. Someone else downloads it, and resigns it with there's.
>
> I'm sure there must be a utility out there which makes this 'easy' - it
> certainly seems simple enough to me - okay so not a nice 'store' type
> interface on your phone; you need to attach it to a computer. However, that
> is just a small wall to step over.
>
> Of course, it is contigent on having a Apple developer account but I'm
> pretty sure these days you don't need to pay the $99 unless you want to
> submit an app
>

Um, and a Mac.  Some iOS device owners have PCs, and therefore no access to
Xcode.


>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps



~Roger
___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Dr. Hawkins via use-livecode]

On Fri, Aug 11, 2017 at 9:54 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Well, I always drive below the speed limit and I always wear a seatbelt
> (and have always done so whether or not it was
> a legal requirement in the country I happened to be living in at the time).
>

I won't leave the driveway without a seat belt, but if you drive below the
posted speed around here, you better check your medical insurance first . .
.

With our new law, our Highway Patrol is actually citing people now for
driving below the posted speed in the left lane . . .

>
> This is not quite the same as keeping goats and hens in the back of your
> car (which was not illegal last time I looked).
>
> While keeping goats and hens in the car may prove extremely smelly it


Both would be quite heavy objects to be flying around in a collision . .
 --
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 19:22, Richmond Mathewson via use-livecode wrote:

So, I wonder why there is not a way of putting one's iPad app onot the
web in a way (and I don't mean via Cydia)
that will allow people to download it onto their tablets
independently, as one can do on an Android device?


There is - you build your app signed with your provisioning profile. You 
upload it. Someone else downloads it, and resigns it with there's.


I'm sure there must be a utility out there which makes this 'easy' - it 
certainly seems simple enough to me - okay so not a nice 'store' type 
interface on your phone; you need to attach it to a computer. However, 
that is just a small wall to step over.


Of course, it is contigent on having a Apple developer account but I'm 
pretty sure these days you don't need to pay the $99 unless you want to 
submit an app


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 18:49, Curry Kenworthy via use-livecode wrote:

Richmond, this may be rare but I'm 100% in agreement with you! My
device, my management. I don't have the right to do something illegal
or endanger others, but otherwise, I call the shots.


Indeed - you are free to do whatever you want with your device.

You can JailBreak it for a start - you won't be able to use the Apple 
AppStore, because if they were to allow that it punches a large whole in 
the 'security blanket' (however thin it might be) that the locked-down 
device + 'controlled' AppStore environment Apple provide.



For virus and malware in particular, yes. But that type of safety
could be achieved in other specific ways. This system is primarily
about control - a lot of it is financial, some perhaps even
ideological. Safety is also a big component of the system, but not the
defining one.


What other specific ways? The best defense against virii and malware is 
to minimize the surface area of vulnerabilities - there is simply no 
better way. The less 'holes' which can be exploited, the less exploits 
that can exist.


I think Johnathan made the best point here - if you want into the iOS 
world and the AppStore Apple provide you have to abide by their rules. 
However, if you don't care about the AppStore, then just jailbreak your 
phone and run free - no-one is stopping you.


It is entirely your choice :)

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Update: Crash with mobilePickPhoto and Android

[Roger Eller via use-livecode]

Also, you shouldn't have to use a workaround just because it is Android.
The mobile syntax should work the same for either OS.

~Roger


On Fri, Aug 11, 2017 at 12:32 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This needs a bug report. Crashes are high priority fixes.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
>
>
>
> On August 11, 2017 10:17:35 AM Dan Friedman via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> For those who may be interested, here’s a fun one…
>>
>> If acceleratedRendering is enabled, mobilePickPhoto will crash the app on
>> Android.  Here’s your workaround:
>>
>>   set the acceleratedRendering of stack "main" to false
>>   mobilePickPhoto "camera"
>>   set the acceleratedRendering of stack "main" to true
>>
>> Perhaps LC will fix this or add this limitation to the documentation.
>>
>> -Dan
>>
>>
>> Hello!   Having some trouble with mobilePickPhoto on an Android device.
 I call mobilePickPhoto "library"
 (or mobilePickPhoto "camera") and I can choose the photo or take the
 picture, but as soon as I accept the
 image (when LC should have control again) the app crashes with the
 prompt “[appName] has stopped”.
 LC 8.1.5, Moto g5 Plus running Android 7.0.   Any thoughts?

 Any assistance would be GREATLY appreciated!

 -Dan

>>>
>> ___
>> 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
>
___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Richmond Mathewson via use-livecode]

On 8/11/17 8:18 pm, Mark Waddingham via use-livecode wrote:

On 2017-08-11 18:54, Richmond Mathewson via use-livecode wrote:

Now putting a LiveCode standalone onto an iPad that does thing that
Apple doesn't like isn't always the same thing as putting things onto
an iPad that is unsafe.


I've already pointed out that you can put whatever you want onto 
*your* iPad or *your* iPhone - you just need an Apple Developer 
account, a provisioning profile and away you go. There are also 
numerous ways to share such apps with your friends and colleagues, or 
indeed anyone you like (beta test codes etc. - or just sending them 
the built app bundle which they can then resign to install themselves 
through Xcode onto their own devices).


For organisations, it is also bypass the *consumer* AppStore - by 
having an organisation wide AppStore. Again, these come with no review 
or restrictions.


The restrictions are about what your app is allowed to do when you 
submit to the *Consumer* Apple App Store - i.e. when you are making 
your app potentially available to millions of people.


So, I wonder why there is not a way of putting one's iPad app onot the 
web in a way (and I don't mean via Cydia)
that will allow people to download it onto their tablets independently, 
as one can do on an Android device?


Therefore allowing those "millions" of people (i.e. the 25 who are 
interested in "Fred Flintstone's" app) the abi;lity to choose for 
themselves.


Richmond.


Warmest Regards,

Mark.




___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 18:54, Richmond Mathewson via use-livecode wrote:

Now putting a LiveCode standalone onto an iPad that does thing that
Apple doesn't like isn't always the same thing as putting things onto
an iPad that is unsafe.


I've already pointed out that you can put whatever you want onto *your* 
iPad or *your* iPhone - you just need an Apple Developer account, a 
provisioning profile and away you go. There are also numerous ways to 
share such apps with your friends and colleagues, or indeed anyone you 
like (beta test codes etc. - or just sending them the built app bundle 
which they can then resign to install themselves through Xcode onto 
their own devices).


For organisations, it is also bypass the *consumer* AppStore - by having 
an organisation wide AppStore. Again, these come with no review or 
restrictions.


The restrictions are about what your app is allowed to do when you 
submit to the *Consumer* Apple App Store - i.e. when you are making your 
app potentially available to millions of people.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Jonathan Lynch via use-livecode]

If we buy an iPad, we are buying both the device and the services that go with 
it. To use a service, like iTunes, we are agreeing to operate by their rules.

It seems acceptable for Apple to impose restrictions on use of their device and 
their services simply because people have the choice to agree to those terms or 
not. We are not forced to buy it.

Basically, I don't complain about a closed ecosystem since I elected to partake 
of that system, especially since we have alternatives.

Sent from my iPhone

> On Aug 11, 2017, at 12:54 PM, Richmond Mathewson via use-livecode 
>  wrote:
> 
> Well, I always drive below the speed limit and I always wear a seatbelt (and 
> have always done so whether or not it was
> a legal requirement in the country I happened to be living in at the time).
> 
> This is not quite the same as keeping goats and hens in the back of your car 
> (which was not illegal last time I looked).
> 
> While keeping goats and hens in the car may prove extremely smelly it cannot 
> be said to be unsafe
> (unless one wants to drive the car with a nanny goat sitting on one's lap).
> 
> Now putting a LiveCode standalone onto an iPad that does thing that Apple 
> doesn't like isn't always the same thing as putting things onto an iPad that 
> is unsafe.
> 
> I'm absolutely sure that an awful lot of the creative potential of tablets is 
> being lost because of unnecessary restrictions.
> 
>> On 8/11/17 6:44 pm, Mark Waddingham via use-livecode wrote:
>>> On 2017-08-11 16:44, Richmond Mathewson via use-livecode wrote:
>>> I cannot quite see how people are prepared to go on buying Apple iPads when
>>> there are such draconian restrictions as to what one can run on them.
>>> 
>>> While the Android "thing" may not be much better, at last one can
>>> side-load almost anything one wants.
>> 
>> One can on iOS too - if you want to Jailbreak your device. Or, indeed, if 
>> you have a Apple dev account (which I believe are now free until you want to 
>> submit an app - someone please correct me if I'm wrong) you can put on it 
>> whatever you like.
>> 
>>> There is a whole world of difference between a set of actions one
>>> cannot do because of the
>>> physical limitations of a thing and a set of actions one is not
>>> allowed to do because a bunch of people
>>> in California want to carry on mucking you around even after they ahve
>>> successfully manipulated you into buying their
>>> over-priced product.
>> 
>> That might be true - but as much as these restrictions *might* be because 
>> the vendors 'want complete control of their walled garden to scalp us for 
>> cash', I honestly do think it is much more about ensuring these devices are 
>> *safe* for people to use in regards to all the very critical information we 
>> tend to hold on our devices.
> 
> I don't see that, so much as the possibility that Apple and Google are 
> scalping developers for cash;
> and even that does not make much sense as they could still "scalp" if the 
> restrictions were not so tight.
> 
> I don't think the developers of these machines or their operating systems are 
> worried that much about
> the end-users' safety; surely they are more interested in keeping their 
> shareholders happy.
> 
>> 
>> It is important to remember that the majority of people who use mobile 
>> phones, tablets and computers use them like they do their car or washing 
>> machine. They have little interest in how the thing works, just that it does 
>> what they need to - does it well and does it safely.
> 
> Yes, I am sure you are right. But, by imposing these restrictions they do not 
> give the end-user a choice; and a world in which choice seems to be 
> increasingly restricted is not good.
> 
> It would seem that the use of over-regulation and over-restriction is a way 
> of dodging the very heavy moral responsibility of teaching people to
> make sensible decisions.
>> 
>> Sure some people complain about seat-belts and speed limits but the reality 
>> is that those *legally enforceable requirements* make the roads a great deal 
>> safer for everyone.
>> 
>> Warmest Regards,
> 
> Not half as warm as over here in Bulgaria; hit 43 Centigrade today!
>> 
>> Mark.
>> 
> 
> Best, Richmond.
> 
> ___
> 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

Re: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Richmond Mathewson via use-livecode]

Well, I always drive below the speed limit and I always wear a seatbelt 
(and have always done so whether or not it was

a legal requirement in the country I happened to be living in at the time).

This is not quite the same as keeping goats and hens in the back of your 
car (which was not illegal last time I looked).


While keeping goats and hens in the car may prove extremely smelly it 
cannot be said to be unsafe

(unless one wants to drive the car with a nanny goat sitting on one's lap).

Now putting a LiveCode standalone onto an iPad that does thing that 
Apple doesn't like isn't always the same thing as putting things onto an 
iPad that is unsafe.


I'm absolutely sure that an awful lot of the creative potential of 
tablets is being lost because of unnecessary restrictions.


On 8/11/17 6:44 pm, Mark Waddingham via use-livecode wrote:

On 2017-08-11 16:44, Richmond Mathewson via use-livecode wrote:
I cannot quite see how people are prepared to go on buying Apple 
iPads when

there are such draconian restrictions as to what one can run on them.

While the Android "thing" may not be much better, at last one can
side-load almost anything one wants.


One can on iOS too - if you want to Jailbreak your device. Or, indeed, 
if you have a Apple dev account (which I believe are now free until 
you want to submit an app - someone please correct me if I'm wrong) 
you can put on it whatever you like.



There is a whole world of difference between a set of actions one
cannot do because of the
physical limitations of a thing and a set of actions one is not
allowed to do because a bunch of people
in California want to carry on mucking you around even after they ahve
successfully manipulated you into buying their
over-priced product.


That might be true - but as much as these restrictions *might* be 
because the vendors 'want complete control of their walled garden to 
scalp us for cash', I honestly do think it is much more about ensuring 
these devices are *safe* for people to use in regards to all the very 
critical information we tend to hold on our devices.


I don't see that, so much as the possibility that Apple and Google are 
scalping developers for cash;
and even that does not make much sense as they could still "scalp" if 
the restrictions were not so tight.


I don't think the developers of these machines or their operating 
systems are worried that much about
the end-users' safety; surely they are more interested in keeping their 
shareholders happy.




It is important to remember that the majority of people who use mobile 
phones, tablets and computers use them like they do their car or 
washing machine. They have little interest in how the thing works, 
just that it does what they need to - does it well and does it safely.


Yes, I am sure you are right. But, by imposing these restrictions they 
do not give the end-user a choice; and a world in which choice seems to 
be increasingly restricted is not good.


It would seem that the use of over-regulation and over-restriction is a 
way of dodging the very heavy moral responsibility of teaching people to

make sensible decisions.


Sure some people complain about seat-belts and speed limits but the 
reality is that those *legally enforceable requirements* make the 
roads a great deal safer for everyone.


Warmest Regards,


Not half as warm as over here in Bulgaria; hit 43 Centigrade today!


Mark.



Best, Richmond.

___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Curry Kenworthy via use-livecode]

Richmond:

> I cannot quite see how people are prepared to go on buying
> Apple iPads when there are such draconian restrictions as to
> what one can run on them.

> While the Android "thing" may not be much better, at last one
> can side-load almost anything one wants.

> But, Like Richard Stallman, I suffer from the "horrible" belief
> that once one has bought something it belongs to you and you
> should not be told what you can and cannot do with it.

Richmond, this may be rare but I'm 100% in agreement with you! My 
device, my management. I don't have the right to do something illegal or 
endanger others, but otherwise, I call the shots.


Safer? Ha! I can assure everyone that at least in the U.S., your own 
confidential information is fairly likely to be transmitted insecurely 
even by professions, regardless of which phone or computer they are 
using. I've seen it again and again - social security numbers, sensitive 
records, photo ID, banking and financial, the works. Dumbing things 
down, the resulting ignorance and complacency hasn't helped. I'm not 
even getting into other long-term implications of recent technology trends.


For virus and malware in particular, yes. But that type of safety could 
be achieved in other specific ways. This system is primarily about 
control - a lot of it is financial, some perhaps even ideological. 
Safety is also a big component of the system, but not the defining one.


Best wishes,

Curry Kenworthy

Custom Software Development
http://curryk.com/consulting/


___
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

Ink pullDown menu

[Richmond Mathewson via use-livecode]

I can have a pullDown menu with this sort of script:

put the fontNames into me

how can I do the smae sort of thing for Ink?

e.g. (pseudocode): put the inkNames into me

Richmond.
___
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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Jonathan Lynch via use-livecode]

It seems that this is another reason to use LC's HTML5 deployment.

Since external javascript is permitted, one could do the "sideloading" by 
accessing a website created with LC.

It would just be an LC HTML5 app displayed inside of a browser widget.

Of course, it would be easy to abuse this by adding in function calls to LC on 
the mobile device, so we would need to be careful.

In Augmented Earth, reports can have ads added to them. The report, with the 
ad, is displayed through a browser widget. This will allow advertisers to place 
high-quality ads, which they will love.

However, nothing in the app would give them access to extra system calls. It is 
still sandboxed, but only by choice.

So, that great power thing still applies - and thanks to the great Stan Lee for 
that meme!

Sent from my iPhone

> On Aug 11, 2017, at 12:20 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> In this case, the restrictions are to prevent malware from entering the app 
> stores, which hardly sounds Draconian to me. Even so, there have been a 
> handful of apps that made it through the vetting process and affected dozens 
> or hundreds of users. It's rare but it has happened.
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> 
>> On August 11, 2017 9:46:37 AM Richmond Mathewson via use-livecode 
>>  wrote:
>> 
>> I cannot quite see how people are prepared to go on buying Apple iPads when
>> there are such draconian restrictions as to what one can run on them.
>> 
>> While the Android "thing" may not be much better, at last one can
>> side-load almost anything one wants.
>> 
>> But, Like Richard Stallman, I suffer from the "horrible" belief that
>> once one has bought something
>> it belongs to you and you should not be told what you can and cannot do
>> with it.
>> 
>> OK, OK, I'm back off to the kitchen to carry on slicing vegetables with
>> a roll of toliet paper.
>> 
>> There is a whole world of difference between a set of actions one cannot
>> do because of the
>> physical limitations of a thing and a set of actions one is not allowed
>> to do because a bunch of people
>> in California want to carry on mucking you around even after they ahve
>> successfully manipulated you into buying their
>> over-priced product.
>> 
>> Currently trying to get my ASUS Intel Tablet  which runs Android to do a
>> few things I want it to, but Google [wouldn't Douglas Adams
>> have a fit of the dry boak?] do want me to do with it.
>> 
>> Richmond.
>> 
>>> On 8/11/17 5:35 pm, Jonathan Lynch via use-livecode wrote:
>>> If we could have our own LC App Store, where people could play an app with 
>>> a player app on different platforms, it would be quite excellent.
>>> 
>>> At the very least, I think Apple would object.
>>> 
>>> Sent from my iPhone
>>> 
 On Aug 11, 2017, at 10:09 AM, Roger Eller via use-livecode 
  wrote:
 
 Several companies HAVE their own app stores.  Samsung is one that comes to
 mind.  http://joyofandroid.com/android-app-store-alternatives/
 
 ~Roger
 
 
 On Fri, Aug 11, 2017 at 10:00 AM, Jonathan Lynch via use-livecode <
 use-livecode@lists.runrev.com> wrote:
 
> If Apple and Google allowed player apps that play external code, companies
> could essentially set up their own app stores, bypassing google play and
> iTunes.
> I cannot imagine either company would appreciate that.
> 
> Sent from my iPhone
> 
>> On Aug 11, 2017, at 9:52 AM, Ralph DiMola via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>> Mark,
>> 
>> Thanks for weighing in. I would like to read into those licenses that I
>> could update my core LCS, but I know in my soul that if I do that it's
> just
>> a shoe waiting to drop that could affect not only my license but the
> entire
>> LC community. I also feel that when I create an extra button(with stub
> code)
>> because a "data" update offers more options that I am staying within the
>> guidelines and the spirit of the App/Play store rules. I see this as
> simple
>> decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
>> says "no" because he did not eat "A" cookie but ate 3 cookies. I am not
> a 2
>> year old and know what these rules were intended to prevent.
>> 
>> By the way, I was once rejected because my data update "answer" dialog
> was
>> worded as "An app update is available". I explained that it was a data
>> update and not code and changed the verbiage of the dialog. I then passed
>> the review. Moral: The review team can look VERY close at any app during
>> review.
>> 
>> As it was said in Goodfellows... At least, that's how I feel.
>> 
>> Ralph DiMola
>> IT Director
>> Evergreen 

Re: Bug 20255 - Simple Loop Labeling

[Mark Wieder via use-livecode]

On 08/11/2017 08:50 AM, Mark Waddingham via use-livecode wrote:

> they aren't likely to happen until someone actually has some 'time' 
to do the necessary thinking


Um. Yes. That would be you.

--
 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: Update: Crash with mobilePickPhoto and Android

[J. Landman Gay via use-livecode]

This needs a bug report. Crashes are high priority fixes.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On August 11, 2017 10:17:35 AM Dan Friedman via use-livecode 
 wrote:



For those who may be interested, here’s a fun one…

If acceleratedRendering is enabled, mobilePickPhoto will crash the app on 
Android.  Here’s your workaround:


  set the acceleratedRendering of stack "main" to false
  mobilePickPhoto "camera"
  set the acceleratedRendering of stack "main" to true

Perhaps LC will fix this or add this limitation to the documentation.

-Dan


Hello!   Having some trouble with mobilePickPhoto on an Android device.  I 
call mobilePickPhoto "library"
(or mobilePickPhoto "camera") and I can choose the photo or take the 
picture, but as soon as I accept the
image (when LC should have control again) the app crashes with the prompt 
“[appName] has stopped”.

LC 8.1.5, Moto g5 Plus running Android 7.0.   Any thoughts?

Any assistance would be GREATLY appreciated!

-Dan


___
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

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 08:42 AM, Alex Tweedly via use-livecode wrote:


Is it really worth doing this by changing each of the lines ?
Is it not easier, clearer and very likely just as fast, to do:


put empty into tNewBreaks
repeat for each line tBreak in tBreaks
  put item 1 of tBreak into tID
  put the long id of control id tID of the topstack into tObjectID
  put tObjectID & the itemDel & item 2 to -1 of tBreak  after 
tNewBreaks

end repeat
return char 1 to -1 of tNewBreaks 

With a bonus that deleting lines (i.e. not copying them) is easier.


It is indeed. Thanks.
Refactoring... er... moomin... FTW.

--
 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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[J. Landman Gay via use-livecode]

In this case, the restrictions are to prevent malware from entering the app 
stores, which hardly sounds Draconian to me. Even so, there have been a 
handful of apps that made it through the vetting process and affected 
dozens or hundreds of users. It's rare but it has happened.


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



On August 11, 2017 9:46:37 AM Richmond Mathewson via use-livecode 
 wrote:



I cannot quite see how people are prepared to go on buying Apple iPads when
there are such draconian restrictions as to what one can run on them.

While the Android "thing" may not be much better, at last one can
side-load almost anything one wants.

But, Like Richard Stallman, I suffer from the "horrible" belief that
once one has bought something
it belongs to you and you should not be told what you can and cannot do
with it.

OK, OK, I'm back off to the kitchen to carry on slicing vegetables with
a roll of toliet paper.

There is a whole world of difference between a set of actions one cannot
do because of the
physical limitations of a thing and a set of actions one is not allowed
to do because a bunch of people
in California want to carry on mucking you around even after they ahve
successfully manipulated you into buying their
over-priced product.

Currently trying to get my ASUS Intel Tablet  which runs Android to do a
few things I want it to, but Google [wouldn't Douglas Adams
have a fit of the dry boak?] do want me to do with it.

Richmond.

On 8/11/17 5:35 pm, Jonathan Lynch via use-livecode wrote:
If we could have our own LC App Store, where people could play an app with 
a player app on different platforms, it would be quite excellent.


At the very least, I think Apple would object.

Sent from my iPhone

On Aug 11, 2017, at 10:09 AM, Roger Eller via use-livecode 
 wrote:


Several companies HAVE their own app stores.  Samsung is one that comes to
mind.  http://joyofandroid.com/android-app-store-alternatives/

~Roger


On Fri, Aug 11, 2017 at 10:00 AM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:


If Apple and Google allowed player apps that play external code, companies
could essentially set up their own app stores, bypassing google play and
iTunes.
I cannot imagine either company would appreciate that.

Sent from my iPhone


On Aug 11, 2017, at 9:52 AM, Ralph DiMola via use-livecode <

use-livecode@lists.runrev.com> wrote:

Mark,

Thanks for weighing in. I would like to read into those licenses that I
could update my core LCS, but I know in my soul that if I do that it's

just

a shoe waiting to drop that could affect not only my license but the

entire

LC community. I also feel that when I create an extra button(with stub

code)

because a "data" update offers more options that I am staying within the
guidelines and the spirit of the App/Play store rules. I see this as

simple

decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
says "no" because he did not eat "A" cookie but ate 3 cookies. I am not

a 2

year old and know what these rules were intended to prevent.

By the way, I was once rejected because my data update "answer" dialog

was

worded as "An app update is available". I explained that it was a data
update and not code and changed the verbiage of the dialog. I then passed
the review. Moral: The review team can look VERY close at any app during
review.

As it was said in Goodfellows... At least, that's how I feel.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On

Behalf

Of Mark Waddingham via use-livecode
Sent: Friday, August 11, 2017 7:24 AM
To: How to use LiveCode
Cc: Mark Waddingham
Subject: Re: Mobile LC Apps Downloading Stacks After installation


On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
I know the reviewers at app stores are not always careful, but
something like an LC player would surely get their notice.

Review, from my understanding, is heavily automated (it has to be - if

you

think of the scale of the App Stores these days). However, there is

always a

means to get in contact with a human about specific issues (which can

take a

while to get escalated with someone who can actually do something - but

at

least it is possible).


They do allow us to import JS, but JS is way more sandboxed than LC.

Yes - this is true - however, as I noticed this morning Apple no longer

have

their advisory about allowing arbitrary JS to be downloaded and run

within a

WebView. This is simply because you can could build a host app which

gives

access to every single OS API on iOS and make all of them callable from

JS

(even if the JS bundled with the app does not use any of it).

So, the point is the language is not the point - what the 

Re: common code patterns

[Malte Pfaff-Brill via use-livecode]

HI Alex,

> put param(1) into isLeft
> put param(2) into isTop
> etc.
> 
> This always has fewer lines (i.e. the same number of lines as the 
> "recombine" part), and removes the loop completely.
> 
But would change the way the functions are intended to be able to called.

myFunction(the loc of control 1) has one comma delimited Parameter
while
myFunction(item 1 of the loc of control 1,item 2 of the loc of control 1) has 2 
parameters

Thus combining all params into a literal first and then breaking out the items 
of that in the desired order

> 
> 
> repeat with i=1 to paramcount()-1
>  put param(i)&"," after theValue
> end repeat
> put param(paramcount()) after theValue
> 
> Shorter, faster, and just plain tidier :-)
> 

Agreed. :-)

Cheers,

Malte


___
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 20255 - Simple Loop Labeling

[Dr. Hawkins via use-livecode]

On Thu, Aug 10, 2017 at 6:24 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> 2. automagical maintenance if the comments exist and you change the
> conditio
>

Oooh, yes; automagical maintenance would be wonderful!  (really? my
spellchecker recognizes "automagical" as a word?)

And to be clear, I am *NOT* suggesting in any way that Livecode get a GOTO;
I was suggesting that there are *very* rare cases where they are useful.
 (I can probably count the number I have *ever* used on my fingers,
possibly of one hand [unless you count the ones driven by performance and
how memory was accessed in interpreters, but that still gave you two per
program {jump to high/slow area for onetime setup, then to mid-memory main
loop above time critical subroutines, and possibly a third from the end of
the main loop to the beginning if the language couldn't loop forever}]).

(and as dust drifts about the cobwebs of my memory, I think that on what I
think of as "my goto" was used instead of putting the common section into
another routine to avoid the computational cost of that context switch;
this was in the recursive core routine that was called zillions of times in
the program which ran for a couple of days [initially more than that].   If
you need that kind of optimization/performance, livecode will be fairly low
on your list of choices . . .)

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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 LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 18:00, Mike Kerner via use-livecode wrote:
That's not what I'm saying.  What I'm saying is while telling everyone 
to
control themselves is good, removing these capabilities from LC is bad, 
so

if the time comes where it is necessary to do something to stop someone
from behaving badly, please make sure we have a switch in place that 
allows

the rest of us to continue as-is.


Hence my comment about 'when being run from an App Store installed 
environment'. It is easy to check if an App is running when installed 
from an AppStore...


Indeed, you have to build such things using a 'distribution profile' 
specific to the store - so any action would be at standalone-build time, 
rather than anywhere else.


To be fair, I don't think it is likely to happen... However, unlikely 
does not mean impossible!


Warmest Regards,

Mark.

P.S. I'd also rather not have to expend the resources doing it - there 
are far better things we could be doing than figuring out ways to turn 
dynamic features into static ones, or reworking stuff so the dynamic 
features could be turned off. I much prefer the 'with great power comes 
great responsibility' approach - i.e. trust!


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Mobile LC Apps Downloading Stacks After installation

[Mike Kerner via use-livecode]

That's not what I'm saying.  What I'm saying is while telling everyone to
control themselves is good, removing these capabilities from LC is bad, so
if the time comes where it is necessary to do something to stop someone
from behaving badly, please make sure we have a switch in place that allows
the rest of us to continue as-is.

On Fri, Aug 11, 2017 at 11:31 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-11 16:35, Mike Kerner via use-livecode wrote:
>
>> Unless I read your post incorrectly, mark, "Do" works just fine, at least
>>
>
> Yes it does - the point I was making was that breaking the rules in the
> App Store could end up with us having to restrict what the LiveCode engine
> can do when being run in an App Store Installed environment to ensure that
> we aren't blocked from said App Store. The blunt instrument would be not
> allowing *any* dynamic code execution (which is essentially what Apple
> *did* do for a while in 2010).
>
> The sideloading/bootstrapping capabilities in LC are a fantastic way to
>> work on corporate apps, force updates, and save everyone time and hassle.
>>
>
> What happens inside corporations within the Enterprise schemes the App
> Stores have is not the issue here. There you can do whatever you like -
> within what the IT departments allow, at least.
>
> This is the consumer facing App Store(s) which have these restrictions.
> Primarily to protect people who don't want to have to understand all the
> details of the risks involved with having hugely powerful computational
> devices in their pockets which can download and run code provided by (what
> are, in reality) very loosely vetted organisations/businesses/individuals.
> Particularly when those computational devices also tend to store their
> entire 'lives' (in terms of personal details, financial details, contacts,
> etc.).
>
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: 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
>



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

Re: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Dr. Hawkins via use-livecode]

On Fri, Aug 11, 2017 at 8:44 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> It is important to remember that the majority of people who use mobile
> phones, tablets and computers use them like they do their car or washing
> machine. They have little interest in how the thing works, just that it
> does what they need to - does it well and does it safely.
>

This.

Word processor, spreadsheet, browser, email, and a few games probably
covers 99% of users.

On a phone, many want their facetwit applications, too.

My interest in a smart phone ends at navigation, camera, and caller ID.
Oh, and enough voice control to place calls.

I'd be tempted to switch to an android (I actually had the original
gphone), but the privacy, hacks, and whathaveyou stop me.

Security and privacy *are* what I'm buying when I pay extra for an iOS
device.



-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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 20255 - Simple Loop Labeling

[Mark Waddingham via use-livecode]

On 2017-08-11 17:40, Mark Wieder via use-livecode wrote:

On 08/11/2017 02:51 AM, Mark Waddingham via use-livecode wrote:

Naming loops in a syntactic way certainly sounds like a useful thing 
to do:


I should point out here that Robert Cailliau has complained about the
lack of named loops as one of the main deficiencies of LiveCode for
some ten years now.


I know - it has come up numerous times. I wasn't presenting it as a new 
idea - because it most certainly isn't (although it isn't all that 
common, when you look across the vast range of programming languages 
which do exist...)


Robert has also suggested a 'with' construct, allowing quotes in quoted 
strings (I think his suggestion is "") and probably many other things 
(he did a talk many years ago which listed quite a few...)


The reality is though, as there has never been a truly concrete proposal 
for any of those which take into account all the constraints of the 
current implementation - they aren't likely to happen until someone 
actually has some 'time' to do the necessary thinking that is required 
to turn them from a theoretical notion, to an implementable 
specification aligned with what could actually be done.


As the topic of naming of loops came up (admittedly from a different 
point of view) it seemed useful to garner some more detail on the idea - 
since it was on quite a few people's minds :)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: [OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 16:44, Richmond Mathewson via use-livecode wrote:
I cannot quite see how people are prepared to go on buying Apple iPads 
when

there are such draconian restrictions as to what one can run on them.

While the Android "thing" may not be much better, at last one can
side-load almost anything one wants.


One can on iOS too - if you want to Jailbreak your device. Or, indeed, 
if you have a Apple dev account (which I believe are now free until you 
want to submit an app - someone please correct me if I'm wrong) you can 
put on it whatever you like.



There is a whole world of difference between a set of actions one
cannot do because of the
physical limitations of a thing and a set of actions one is not
allowed to do because a bunch of people
in California want to carry on mucking you around even after they ahve
successfully manipulated you into buying their
over-priced product.


That might be true - but as much as these restrictions *might* be 
because the vendors 'want complete control of their walled garden to 
scalp us for cash', I honestly do think it is much more about ensuring 
these devices are *safe* for people to use in regards to all the very 
critical information we tend to hold on our devices.


It is important to remember that the majority of people who use mobile 
phones, tablets and computers use them like they do their car or washing 
machine. They have little interest in how the thing works, just that it 
does what they need to - does it well and does it safely.


Sure some people complain about seat-belts and speed limits but the 
reality is that those *legally enforceable requirements* make the roads 
a great deal safer for everyone.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: common code patterns

[Alex Tweedly via use-livecode]

On 11/08/2017 16:26, Mark Wieder via use-livecode wrote:


case 2:
iterating through a cr-separated list and needing to modify lines
(note: this is even more extreme if I need to delete lines):

put tBreaks into tNewBreaks
put 1 into tLine
repeat for each line tBreak in tBreaks
  put item 1 of tBreak into tID
  put the long id of control id tID of the topstack into tObjectID
  put tObjectID into item 1 of line tLine of tNewBreaks
  add 1 to tLine
end repeat
return tNewBreaks


Is it really worth doing this by changing each of the lines ?
Is it not easier, clearer and very likely just as fast, to do:


put empty into tNewBreaks
repeat for each line tBreak in tBreaks
  put item 1 of tBreak into tID
  put the long id of control id tID of the topstack into tObjectID
  put tObjectID & the itemDel & item 2 to -1 of tBreak  after 
tNewBreaks

end repeat
return char 1 to -1 of tNewBreaks 

With a bonus that deleting lines (i.e. not copying them) is easier.

Regards,
Alex

___
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 20255 - Simple Loop Labeling

[Mark Wieder via use-livecode]

On 08/11/2017 02:51 AM, Mark Waddingham via use-livecode wrote:


Naming loops in a syntactic way certainly sounds like a useful thing to do:


I should point out here that Robert Cailliau has complained about the 
lack of named loops as one of the main deficiencies of LiveCode for some 
ten years now.


--
 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: common code patterns

[Mark Waddingham via use-livecode]

On 2017-08-11 17:26, Mark Wieder via use-livecode wrote:

On 08/11/2017 02:24 AM, Mark Waddingham via use-livecode wrote:

Not quite on topic for the thread, but this interested in me in terms 
of - what are the use cases?


Somewhat similar to Ralph's use cases, this paradigm comes up quite
often in my code. Probably the most common case is where I want the
performance of a 'repeat for each' loop but don't have a proper
iterator to use, so I have to use a doppelganger. Examples here from
actual working code:


Hehe - I wasn't clear enough there... I meant 'use-cases for a 
generalized form allowing start index to be specified'.


Although, Ralph's suggestion of allowing a counter alongside *any* 
repeat perhaps suggests the generalization *might* be worthwhile (after 
all there isn't a thing you are counting from 1 there - unlike in repeat 
for each).


So, let me rephrase - what are the use-cases people can see for allowing 
(some variant of):


   repeat ... with counter tCounter starting from tStart

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 16:35, Mike Kerner via use-livecode wrote:
Unless I read your post incorrectly, mark, "Do" works just fine, at 
least


Yes it does - the point I was making was that breaking the rules in the 
App Store could end up with us having to restrict what the LiveCode 
engine can do when being run in an App Store Installed environment to 
ensure that we aren't blocked from said App Store. The blunt instrument 
would be not allowing *any* dynamic code execution (which is essentially 
what Apple *did* do for a while in 2010).



The sideloading/bootstrapping capabilities in LC are a fantastic way to
work on corporate apps, force updates, and save everyone time and 
hassle.


What happens inside corporations within the Enterprise schemes the App 
Stores have is not the issue here. There you can do whatever you like - 
within what the IT departments allow, at least.


This is the consumer facing App Store(s) which have these restrictions. 
Primarily to protect people who don't want to have to understand all the 
details of the risks involved with having hugely powerful computational 
devices in their pockets which can download and run code provided by 
(what are, in reality) very loosely vetted 
organisations/businesses/individuals. Particularly when those 
computational devices also tend to store their entire 'lives' (in terms 
of personal details, financial details, contacts, etc.).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 02:24 AM, Mark Waddingham via use-livecode wrote:

Not quite on topic for the thread, but this interested in me in terms of 
- what are the use cases?


Somewhat similar to Ralph's use cases, this paradigm comes up quite 
often in my code. Probably the most common case is where I want the 
performance of a 'repeat for each' loop but don't have a proper iterator 
to use, so I have to use a doppelganger. Examples here from actual 
working code:


case 1:
setting up an array of constants:

put 0 into tCount
repeat for each item tConst in tConsts
  put tConst into tArray[tCount]
  add 1 to tCount
end repeat

case 2:
iterating through a cr-separated list and needing to modify lines
(note: this is even more extreme if I need to delete lines):

put tBreaks into tNewBreaks
put 1 into tLine
repeat for each line tBreak in tBreaks
  put item 1 of tBreak into tID
  put the long id of control id tID of the topstack into tObjectID
  put tObjectID into item 1 of line tLine of tNewBreaks
  add 1 to tLine
end repeat
return tNewBreaks

case 3:
parsing data and needing an iterator:

command SetVarFieldColors pFieldName
  local x

  put 1 into x
  set the itemdelimiter to tab
  repeat for each line tLine in field pFieldName
switch item 3 of tLine
  case "C"
set the forecolor of item 2 to 3 of line x of field pFieldName 
to sDebugColors["declarations"]

break
  case "P"
set the forecolor of item 2 to 3 of line x of field pFieldName 
to sDebugColors["parameters"]

break
  default
break
end switch
add 1 to x
  end repeat
end SetVarFieldColors


--
 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: Fwd: Speed of control lookup (Was Re: Parent of Target)

[Mark Waddingham via use-livecode]

On 2017-08-11 14:57, Mark Waddingham via use-livecode wrote:

The question of course is 'how fast could we get long id parsing to
be' (as that is the bottleneck here, or at least appears to be).


Okay so I got stuck on what I am *meant* to be doing, so spent a little 
time trying to answer this question.


The results are quite encouraging...

So, my idea was this - long ids which the engine generates have a *very* 
strict structure - so write a very fast parser for them which fails as 
soon as it encounters anything it doesn't expect. If this happens you 
just use the existing (relatively slow) method which handles all the 
edge cases.


It turns out you can hand-craft a parser for 'the long id' in about 150 
lines of C (char-bashing, one might call it, as opposed to bit-bashing) 
and assuming you restrict yourself to only looking up things on the 
current card of the target stack, and don't check group ownership 
(oops!) you end up with something which can resolve a long id in about 
the same time as you could if you hand-coded the syntax. i.e.


  put "button id 1003 of group id 1004 of card id 1002 of stack " & 
quote & "MyStackName" & quote into tRuggedId

  get the id of tRuggedId

  -- has about the same speed (assuming all those objects are in the 
cache) as


  put the id of button id 1003 of group id 1004 of card id 1002 of stack 
"MyStackName"


Now, I do wonder if the long id parsing method we currently have is 
actually using the stack-id cache everywhere it could (this code is 
somewhat old and knotty - so it is quite hard to see) - so I'm not sure 
quite how fair the above comparison is with current long id parsing 
(were the latter as optimal as it potentially could be) but there is 
obviously quite a significant overhead in the way chunks are parsed from 
strings (which I kind of already knew - but perhaps not just *how 
much*!).


Anyway, it is quite pleasing to know that we perhaps don't need the 
complexity of 'caching an object-handle along side a string from which a 
long id has been parsed' (where getting the cache validation right is 
going to be hard to do performantly enough) as we can probably make 
parsing of long ids (or variants of) themselves so quick, that the time 
taken to do so is thoroughly lost in the actual operation they are being 
used for.


This was just an 'experiment', so I can't really say when this change 
might (if ever) appear - however, it certainly suggests a slightly less 
fiddly approach than the caching method.


It has also suggested (to me, at least) a slightly different approach - 
we make the return value of the 'long id' property of objects what you 
might call a StringyLongId value. Instead of returning a string:


  button id 1003 of group id 1004 of card id 1002 of stack "MyStackName"

It would be a value which acts like a string, but internally stores:

[ BUTTON, 1003, [ 1004 ], 1002, "MyStackName" ]

i.e. A list of component parts - [ main chunk, main chunk id, [ group 
id, ... ], card id, stack name/filename ]


This has the advantage that you use up a great deal less memory for long 
ids of very frequently referenced objects (filenames / names can be 
quite long!). They can be resolved quickly assuming the stack-id cache 
(and if we add a name / filename cache for top-level stacks); compared 
more quickly; and still be rendered as a string when doing stringy 
things to them (it would also be possible to optimize the 'word' chunk 
for them).


This has the *distinct* advantage of not needing to be validated (long 
ids change as objects move around in the hierarchy or id / names change 
] before use.


Of course, this actually requires a bit of machinery we don't actually 
have (but could be used for other things) - the ability for a value 
(internally) to be able to act like a string, but not actually be a 
string.


On balance the optimized long id chunk parser is probably less work (as 
it only needs a bit of code in *one* place - in the chunk evaluator); 
and probably less prone to causing regressions - especially if we only 
used the optimized code path in cases where we were sure there weren't 
any 'difficult' edge-cases to deal with.


I suppose I should now get back to what I was meant to be doing...

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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

Update: Crash with mobilePickPhoto and Android

[Dan Friedman via use-livecode]

For those who may be interested, here’s a fun one…

If acceleratedRendering is enabled, mobilePickPhoto will crash the app on 
Android.  Here’s your workaround:

  set the acceleratedRendering of stack "main" to false
  mobilePickPhoto "camera"
  set the acceleratedRendering of stack "main" to true

Perhaps LC will fix this or add this limitation to the documentation.

-Dan


>> Hello!   Having some trouble with mobilePickPhoto on an Android device.  I 
>> call mobilePickPhoto "library"
>> (or mobilePickPhoto "camera") and I can choose the photo or take the 
>> picture, but as soon as I accept the
>> image (when LC should have control again) the app crashes with the prompt 
>> “[appName] has stopped”.
>> LC 8.1.5, Moto g5 Plus running Android 7.0.   Any thoughts?
>>
>> Any assistance would be GREATLY appreciated!
>>
>> -Dan

___
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

[OT] HyperCard preservation society

[Ben Rubinstein via use-livecode]

This is fabulous:

http://blog.archive.org/2017/08/11/hypercard-on-the-archive-celebrating-30-years-of-hypercard/

Submit your jewels of yesteryear!

best

Ben

___
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: App Rejected: IPv6 network?

[Bob Sneidar via use-livecode]

I think they mean a binary executable, one that can instruct the processor to 
go do something. The engine is a binary executable. The scripts the engine 
interprets and runs is not, even though they are "compiled" in a sense. They 
are not compiled like a C++ code would be. It's more like compressed. 

Bob S


> On Aug 10, 2017, at 12:20 , J. Landman Gay via use-livecode 
>  wrote:
> 
> On 8/10/17 2:10 PM, Mike Kerner via use-livecode wrote:
>> I didn't know that downloading stacks onto an app was ever a problem.  It's
>> not downloading a file of any sort that has been a no-no, it's loading
>> executable code, which LC scripts are not, and LC stacks are not.
> 
> If a script isn't executable code, I'm not sure what is.
> 
> -- 
> 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

[OT] Draconian computer company policies, was: Mobile LC Apps Downloading Stacks After installation

[Richmond Mathewson via use-livecode]

I cannot quite see how people are prepared to go on buying Apple iPads when
there are such draconian restrictions as to what one can run on them.

While the Android "thing" may not be much better, at last one can 
side-load almost anything one wants.


But, Like Richard Stallman, I suffer from the "horrible" belief that 
once one has bought something
it belongs to you and you should not be told what you can and cannot do 
with it.


OK, OK, I'm back off to the kitchen to carry on slicing vegetables with 
a roll of toliet paper.


There is a whole world of difference between a set of actions one cannot 
do because of the
physical limitations of a thing and a set of actions one is not allowed 
to do because a bunch of people
in California want to carry on mucking you around even after they ahve 
successfully manipulated you into buying their

over-priced product.

Currently trying to get my ASUS Intel Tablet  which runs Android to do a 
few things I want it to, but Google [wouldn't Douglas Adams

have a fit of the dry boak?] do want me to do with it.

Richmond.

On 8/11/17 5:35 pm, Jonathan Lynch via use-livecode wrote:

If we could have our own LC App Store, where people could play an app with a 
player app on different platforms, it would be quite excellent.

At the very least, I think Apple would object.

Sent from my iPhone


On Aug 11, 2017, at 10:09 AM, Roger Eller via use-livecode 
 wrote:

Several companies HAVE their own app stores.  Samsung is one that comes to
mind.  http://joyofandroid.com/android-app-store-alternatives/

~Roger


On Fri, Aug 11, 2017 at 10:00 AM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:


If Apple and Google allowed player apps that play external code, companies
could essentially set up their own app stores, bypassing google play and
iTunes.
I cannot imagine either company would appreciate that.

Sent from my iPhone


On Aug 11, 2017, at 9:52 AM, Ralph DiMola via use-livecode <

use-livecode@lists.runrev.com> wrote:

Mark,

Thanks for weighing in. I would like to read into those licenses that I
could update my core LCS, but I know in my soul that if I do that it's

just

a shoe waiting to drop that could affect not only my license but the

entire

LC community. I also feel that when I create an extra button(with stub

code)

because a "data" update offers more options that I am staying within the
guidelines and the spirit of the App/Play store rules. I see this as

simple

decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
says "no" because he did not eat "A" cookie but ate 3 cookies. I am not

a 2

year old and know what these rules were intended to prevent.

By the way, I was once rejected because my data update "answer" dialog

was

worded as "An app update is available". I explained that it was a data
update and not code and changed the verbiage of the dialog. I then passed
the review. Moral: The review team can look VERY close at any app during
review.

As it was said in Goodfellows... At least, that's how I feel.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On

Behalf

Of Mark Waddingham via use-livecode
Sent: Friday, August 11, 2017 7:24 AM
To: How to use LiveCode
Cc: Mark Waddingham
Subject: Re: Mobile LC Apps Downloading Stacks After installation


On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
I know the reviewers at app stores are not always careful, but
something like an LC player would surely get their notice.

Review, from my understanding, is heavily automated (it has to be - if

you

think of the scale of the App Stores these days). However, there is

always a

means to get in contact with a human about specific issues (which can

take a

while to get escalated with someone who can actually do something - but

at

least it is possible).


They do allow us to import JS, but JS is way more sandboxed than LC.

Yes - this is true - however, as I noticed this morning Apple no longer

have

their advisory about allowing arbitrary JS to be downloaded and run

within a

WebView. This is simply because you can could build a host app which

gives

access to every single OS API on iOS and make all of them callable from

JS

(even if the JS bundled with the app does not use any of it).

So, the point is the language is not the point - what the code running in
the language does is important.

Like Google, Apple are wanting to know precisely what OS APIs your app is
calling at the point of review - so they have some idea of the surface

area

of attack for any malicious intent. How much analysis they currently do,
no-one really knows - however the guidelines means that (in principal)

they

have reasons to pull any apps very quickly if they find that they are

doing

something which is 'not allowed'.

Warmest Regards,

Mark.

--
Mark Waddingham ~ 

Subject: Re: Local File in Browser Widget on Android - Fail

[Dan Friedman via use-livecode]

Sannyasin,

Thank you for the reply!   I have discovered that it’s not the local path the 
is the issue.  If I do this, I see “123” in the browser:

   put “123” into url ("file:" & specialFolderPath("documents") & "/map.html")
   set the url of widget "Browser1" to ("file:" & 
specialFolderPath("documents") & "/map.html")

However, the html document I am trying to load references images that were 
included in the app. These images are here: specialFolderPath("engine").  Note 
that a “there is a file” test proves the existence of the file.

So, here’s what I do, I load the html template from a custom property.  In my 
html document, I have this:

   historicalOverlay = new 
google.maps.GroundOverlay('/MapFinal.png',imageBounds);

I then insert the local path:

   replace "" with specialFolderPath("engine") in mapFile

Then I save the file to disk and load it into the browser widget.  On my mac 
and iOS it works famously.  On Android, I just get a broken image icon.

Do I have to alter the local image path somehow?

Again, thank you for the response and assistance!

-Dan

 

On 8/11/17, 2:33 AM, "use-livecode on behalf of 
use-livecode-requ...@lists.runrev.com"  wrote:

make sure your slashes are all correct. on iOS and desktop  are forgiving 
with double// in URLs; but android is not.. .this bit me many times

file:/somepath/somefile.html

works

file://somepath/somefile.html  

doesn't  

So If you have path setters here and there, one needs to follow some 
convention, either leave folder string *always* with no closing slash and all 
appended url strings begin with a slash.. I started that way but this was 
always confusing to me because on web / means "from DOCROOT"   so slowly I am 
refactoring all these to

function path_Assets
return specialFolderPath("documents") & "/assets/" 
end path_Assets

then in any module we use 

play sound (path_Assets() & "bells-whistles/ding.mp3")  because this is 
"relative" # very subjective..

So what started failing on Android --  really hard to debug!

where instances of 

play sound (path_Assets() & "/bells-whistles/ding.mp3") 

because these would work on Mac desktop and only fail on Android so you are 
beating your head "what is wrong."


On 8/10/17, 1:28 PM, "use-livecode on behalf of Dan Friedman via 
use-livecode"  wrote:

I?m having a problem loading a local file on Android in the Browser 
Widget in LC 8.1.5.  I am experiencing what is described in bug 19036.  But, 
bug 19036?s status is ?Resolved? in version 8.0.0.   So, is something else up?  
Anyone have any insight?

-Dan

___
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 LC Apps Downloading Stacks After installation

[Mike Kerner via use-livecode]

Unless I read your post incorrectly, mark, "Do" works just fine, at least
for ad hoc apps, as well it better, because it is a critically important
part of trying to debug mobile apps at runtime, with some of the rather
annoying things that happen at runtime, like some failure in a script
causing that script to silently exit without any notice or message.  "Do"
lets me add the equivalent of the message box when I'm working on an app.
Before I realized that it worked, about half of the lines of code in any
app I wrote was related to debugging some issue or another.  The ability to
use "Do" means far fewer debugging builds and a lot less shaking my
monitor, cursing the runtime engine for being so unhelpful, and me for
choosing coding over septic technician.

The remote debugger is a great new tool to have in the toolbox, but "do" is
still the one that saves me when everything just stops.

The sideloading/bootstrapping capabilities in LC are a fantastic way to
work on corporate apps, force updates, and save everyone time and hassle.
___
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 LC Apps Downloading Stacks After installation

[Jonathan Lynch via use-livecode]

If we could have our own LC App Store, where people could play an app with a 
player app on different platforms, it would be quite excellent.

At the very least, I think Apple would object.

Sent from my iPhone

> On Aug 11, 2017, at 10:09 AM, Roger Eller via use-livecode 
>  wrote:
> 
> Several companies HAVE their own app stores.  Samsung is one that comes to
> mind.  http://joyofandroid.com/android-app-store-alternatives/
> 
> ~Roger
> 
> 
> On Fri, Aug 11, 2017 at 10:00 AM, Jonathan Lynch via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> If Apple and Google allowed player apps that play external code, companies
>> could essentially set up their own app stores, bypassing google play and
>> iTunes.
>> I cannot imagine either company would appreciate that.
>> 
>> Sent from my iPhone
>> 
>>> On Aug 11, 2017, at 9:52 AM, Ralph DiMola via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Mark,
>>> 
>>> Thanks for weighing in. I would like to read into those licenses that I
>>> could update my core LCS, but I know in my soul that if I do that it's
>> just
>>> a shoe waiting to drop that could affect not only my license but the
>> entire
>>> LC community. I also feel that when I create an extra button(with stub
>> code)
>>> because a "data" update offers more options that I am staying within the
>>> guidelines and the spirit of the App/Play store rules. I see this as
>> simple
>>> decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
>>> says "no" because he did not eat "A" cookie but ate 3 cookies. I am not
>> a 2
>>> year old and know what these rules were intended to prevent.
>>> 
>>> By the way, I was once rejected because my data update "answer" dialog
>> was
>>> worded as "An app update is available". I explained that it was a data
>>> update and not code and changed the verbiage of the dialog. I then passed
>>> the review. Moral: The review team can look VERY close at any app during
>>> review.
>>> 
>>> As it was said in Goodfellows... At least, that's how I feel.
>>> 
>>> Ralph DiMola
>>> IT Director
>>> Evergreen Information Services
>>> rdim...@evergreeninfo.net
>>> 
>>> 
>>> -Original Message-
>>> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
>> Behalf
>>> Of Mark Waddingham via use-livecode
>>> Sent: Friday, August 11, 2017 7:24 AM
>>> To: How to use LiveCode
>>> Cc: Mark Waddingham
>>> Subject: Re: Mobile LC Apps Downloading Stacks After installation
>>> 
 On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
 I know the reviewers at app stores are not always careful, but
 something like an LC player would surely get their notice.
>>> 
>>> Review, from my understanding, is heavily automated (it has to be - if
>> you
>>> think of the scale of the App Stores these days). However, there is
>> always a
>>> means to get in contact with a human about specific issues (which can
>> take a
>>> while to get escalated with someone who can actually do something - but
>> at
>>> least it is possible).
>>> 
 They do allow us to import JS, but JS is way more sandboxed than LC.
>>> 
>>> Yes - this is true - however, as I noticed this morning Apple no longer
>> have
>>> their advisory about allowing arbitrary JS to be downloaded and run
>> within a
>>> WebView. This is simply because you can could build a host app which
>> gives
>>> access to every single OS API on iOS and make all of them callable from
>> JS
>>> (even if the JS bundled with the app does not use any of it).
>>> 
>>> So, the point is the language is not the point - what the code running in
>>> the language does is important.
>>> 
>>> Like Google, Apple are wanting to know precisely what OS APIs your app is
>>> calling at the point of review - so they have some idea of the surface
>> area
>>> of attack for any malicious intent. How much analysis they currently do,
>>> no-one really knows - however the guidelines means that (in principal)
>> they
>>> have reasons to pull any apps very quickly if they find that they are
>> doing
>>> something which is 'not allowed'.
>>> 
>>> Warmest Regards,
>>> 
>>> Mark.
>>> 
>>> --
>>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>>> LiveCode: 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
>>> 
>>> 
>>> ___
>>> 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 

RE: common code patterns

[Ralph DiMola via use-livecode]

Mark,

Again thanks for chiming in.
Here's an example:

Local tIndex, tDataArray
put getMyRecordSet() into tRS
put 1 into tIndex
repeat while not isEof(tRS)
 Put makeThisRecordIntoAnArray(tRS) into tDataArray[tIndex]
 Add 1 to tIndex
End repeat

Now I can sort the keys of the array to ripple thru the records.

This is what I imagined:

local tDataArray
put getMyRecordSet() into tRS
repeat while not isEof(tRS) with counter tIndex
 Put makeThisRecordIntoAnArray(tRS) into tDataArray[tIndex]
end repeat

Another example:

repeat for each word tWord in tWords with counter tIndex
 switch tIndex
  case 1
   -- first word stuff
  break
  case the number of words in tWords
  -- last word stuff
  break
  default
   -- not first or last word stuff
 end switch
 -- all stuff
end repeat

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Mark Waddingham via use-livecode
Sent: Friday, August 11, 2017 5:25 AM
To: How to use LiveCode
Cc: Mark Waddingham
Subject: RE: common code patterns

On 2017-08-10 19:38, Ralph DiMola via use-livecode wrote:
> To make this even more flexible:
> 
> repeat for each line tLine in tLines with [counter] tIndex [start] 
> [{1}|x] [step] [{1}|y]
> 
> end repeat

Not quite on topic for the thread, but this interested in me in terms of
- what are the use cases?

The common code pattern we see as justification for 'repeat for each line
tLine and index tIndex in tLines' is that it allows you to use the
efficiency of iteration over a primary container, whilst still retaining the
index of the chunk being iterated over. i.e.

   put 0 into tIndex
   repeat for each line tLine in tContainer
 add 1 to tIndex
 if tLine is not line tIndex of tContainer then
   answer "Oh dear - something is *really* wrong"
 end if
   end repeat

So an extension to the syntax with 'index' means you get both pieces of
information and a good amount of duality which justifies its existence.

In what kinds of situation do you find yourself wanting an offset index,
relative to the index of the iterated chunk?

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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


___
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 LC Apps Downloading Stacks After installation

[Roger Eller via use-livecode]

Several companies HAVE their own app stores.  Samsung is one that comes to
mind.  http://joyofandroid.com/android-app-store-alternatives/

~Roger


On Fri, Aug 11, 2017 at 10:00 AM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:

> If Apple and Google allowed player apps that play external code, companies
> could essentially set up their own app stores, bypassing google play and
> iTunes.
> I cannot imagine either company would appreciate that.
>
> Sent from my iPhone
>
> > On Aug 11, 2017, at 9:52 AM, Ralph DiMola via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Mark,
> >
> > Thanks for weighing in. I would like to read into those licenses that I
> > could update my core LCS, but I know in my soul that if I do that it's
> just
> > a shoe waiting to drop that could affect not only my license but the
> entire
> > LC community. I also feel that when I create an extra button(with stub
> code)
> > because a "data" update offers more options that I am staying within the
> > guidelines and the spirit of the App/Play store rules. I see this as
> simple
> > decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
> > says "no" because he did not eat "A" cookie but ate 3 cookies. I am not
> a 2
> > year old and know what these rules were intended to prevent.
> >
> > By the way, I was once rejected because my data update "answer" dialog
> was
> > worded as "An app update is available". I explained that it was a data
> > update and not code and changed the verbiage of the dialog. I then passed
> > the review. Moral: The review team can look VERY close at any app during
> > review.
> >
> > As it was said in Goodfellows... At least, that's how I feel.
> >
> > Ralph DiMola
> > IT Director
> > Evergreen Information Services
> > rdim...@evergreeninfo.net
> >
> >
> > -Original Message-
> > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
> Behalf
> > Of Mark Waddingham via use-livecode
> > Sent: Friday, August 11, 2017 7:24 AM
> > To: How to use LiveCode
> > Cc: Mark Waddingham
> > Subject: Re: Mobile LC Apps Downloading Stacks After installation
> >
> >> On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
> >> I know the reviewers at app stores are not always careful, but
> >> something like an LC player would surely get their notice.
> >
> > Review, from my understanding, is heavily automated (it has to be - if
> you
> > think of the scale of the App Stores these days). However, there is
> always a
> > means to get in contact with a human about specific issues (which can
> take a
> > while to get escalated with someone who can actually do something - but
> at
> > least it is possible).
> >
> >> They do allow us to import JS, but JS is way more sandboxed than LC.
> >
> > Yes - this is true - however, as I noticed this morning Apple no longer
> have
> > their advisory about allowing arbitrary JS to be downloaded and run
> within a
> > WebView. This is simply because you can could build a host app which
> gives
> > access to every single OS API on iOS and make all of them callable from
> JS
> > (even if the JS bundled with the app does not use any of it).
> >
> > So, the point is the language is not the point - what the code running in
> > the language does is important.
> >
> > Like Google, Apple are wanting to know precisely what OS APIs your app is
> > calling at the point of review - so they have some idea of the surface
> area
> > of attack for any malicious intent. How much analysis they currently do,
> > no-one really knows - however the guidelines means that (in principal)
> they
> > have reasons to pull any apps very quickly if they find that they are
> doing
> > something which is 'not allowed'.
> >
> > Warmest Regards,
> >
> > Mark.
> >
> > --
> > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> > LiveCode: 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
> >
> >
> > ___
> > 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
>
___
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 LC Apps Downloading Stacks After installation

[Jonathan Lynch via use-livecode]

If Apple and Google allowed player apps that play external code, companies 
could essentially set up their own app stores, bypassing google play and iTunes.
I cannot imagine either company would appreciate that.

Sent from my iPhone

> On Aug 11, 2017, at 9:52 AM, Ralph DiMola via use-livecode 
>  wrote:
> 
> Mark,
> 
> Thanks for weighing in. I would like to read into those licenses that I
> could update my core LCS, but I know in my soul that if I do that it's just
> a shoe waiting to drop that could affect not only my license but the entire
> LC community. I also feel that when I create an extra button(with stub code)
> because a "data" update offers more options that I am staying within the
> guidelines and the spirit of the App/Play store rules. I see this as simple
> decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
> says "no" because he did not eat "A" cookie but ate 3 cookies. I am not a 2
> year old and know what these rules were intended to prevent.
> 
> By the way, I was once rejected because my data update "answer" dialog was
> worded as "An app update is available". I explained that it was a data
> update and not code and changed the verbiage of the dialog. I then passed
> the review. Moral: The review team can look VERY close at any app during
> review.
> 
> As it was said in Goodfellows... At least, that's how I feel.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
> 
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
> Of Mark Waddingham via use-livecode
> Sent: Friday, August 11, 2017 7:24 AM
> To: How to use LiveCode
> Cc: Mark Waddingham
> Subject: Re: Mobile LC Apps Downloading Stacks After installation
> 
>> On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
>> I know the reviewers at app stores are not always careful, but 
>> something like an LC player would surely get their notice.
> 
> Review, from my understanding, is heavily automated (it has to be - if you
> think of the scale of the App Stores these days). However, there is always a
> means to get in contact with a human about specific issues (which can take a
> while to get escalated with someone who can actually do something - but at
> least it is possible).
> 
>> They do allow us to import JS, but JS is way more sandboxed than LC.
> 
> Yes - this is true - however, as I noticed this morning Apple no longer have
> their advisory about allowing arbitrary JS to be downloaded and run within a
> WebView. This is simply because you can could build a host app which gives
> access to every single OS API on iOS and make all of them callable from JS
> (even if the JS bundled with the app does not use any of it).
> 
> So, the point is the language is not the point - what the code running in
> the language does is important.
> 
> Like Google, Apple are wanting to know precisely what OS APIs your app is
> calling at the point of review - so they have some idea of the surface area
> of attack for any malicious intent. How much analysis they currently do,
> no-one really knows - however the guidelines means that (in principal) they
> have reasons to pull any apps very quickly if they find that they are doing
> something which is 'not allowed'.
> 
> Warmest Regards,
> 
> Mark.
> 
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: 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
> 
> 
> ___
> 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

RE: Bug 20255 - Simple Loop Labeling

[Ralph DiMola via use-livecode]

I did not want to be the one to rehash this again but I would love to have
this as I do it manually all the time with comments. +1

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Mark Waddingham via use-livecode
Sent: Friday, August 11, 2017 5:51 AM
To: How to use LiveCode
Cc: Mark Waddingham
Subject: Re: Bug 20255 - Simple Loop Labeling

On 2017-08-10 21:33, Dr. Hawkins via use-livecode wrote:
> In fact, what I would *like* is modern Fortran style labelling or 
> something like that, and the ability to the those labels to controls 
> like next and exit.  This, however, would accomplish so much with so 
> little.

Thinking out loud here and taking into account suggestions people have made
in the past...

Naming loops in a syntactic way certainly sounds like a useful thing to
do:

repeat for each line tLine in tContainer named LineLoop
   repeat for each item tItem in tLine named ItemLoop
 if some complicated condition then
   exit repeat ItemLoop
 else if some other complicated condition then
   exit repeat LineLoop
 end if

 -- do other stuff
 if some even more complicated condition then
   next repeat LineLoop
 end if
   end repeat ItemLoop
end repeat LineLoop

Certainly 'exit repeat ...' would not be harmful, 'next repeat ...' I'd have
to analyze more deeply.

The main problem with GOTO (apart from the ability to create very hard to
understand code) is that it allows creation of what is called 'unstructured
control-flow'. Basically that means that you have to work
*exceptionally* hard to untangle it in a compile to perform any sort of
reasonable optimization.

At present LiveCode only allows you to produce 'structured control flow'.
Adding 'next repeat ...', doesn't change that... However, 'next repeat ...'
is not so clear (I think it is probably fine, but need to check some
algorithmics).

The only other issue with the above (beyond implementing it) is the
syntax... It would reserve 'named' as a non-operator in this context. If we
did ever have reason to have 'X named Y' then in repeats you'd have to do:

   repeat for each line tLine in (tContainer named ...) named ...

Although - without knowing what 'named' might do as an operator, or being
able to think of anything it could do - that is probably a safe addition
from that point of view.

(Of course we could use 'labelled' instead of 'named' in the repeat context
- 'labelled' seems for some reason less likely to be leveragable as a binary
operator!)

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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


___
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 LC Apps Downloading Stacks After installation

[Ralph DiMola via use-livecode]

Mark,

Thanks for weighing in. I would like to read into those licenses that I
could update my core LCS, but I know in my soul that if I do that it's just
a shoe waiting to drop that could affect not only my license but the entire
LC community. I also feel that when I create an extra button(with stub code)
because a "data" update offers more options that I am staying within the
guidelines and the spirit of the App/Play store rules. I see this as simple
decision. I call it the "Johnny, did you eat a cookie?" scenario. Johnny
says "no" because he did not eat "A" cookie but ate 3 cookies. I am not a 2
year old and know what these rules were intended to prevent.

By the way, I was once rejected because my data update "answer" dialog was
worded as "An app update is available". I explained that it was a data
update and not code and changed the verbiage of the dialog. I then passed
the review. Moral: The review team can look VERY close at any app during
review.

As it was said in Goodfellows... At least, that's how I feel.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Mark Waddingham via use-livecode
Sent: Friday, August 11, 2017 7:24 AM
To: How to use LiveCode
Cc: Mark Waddingham
Subject: Re: Mobile LC Apps Downloading Stacks After installation

On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:
> I know the reviewers at app stores are not always careful, but 
> something like an LC player would surely get their notice.

Review, from my understanding, is heavily automated (it has to be - if you
think of the scale of the App Stores these days). However, there is always a
means to get in contact with a human about specific issues (which can take a
while to get escalated with someone who can actually do something - but at
least it is possible).

> They do allow us to import JS, but JS is way more sandboxed than LC.

Yes - this is true - however, as I noticed this morning Apple no longer have
their advisory about allowing arbitrary JS to be downloaded and run within a
WebView. This is simply because you can could build a host app which gives
access to every single OS API on iOS and make all of them callable from JS
(even if the JS bundled with the app does not use any of it).

So, the point is the language is not the point - what the code running in
the language does is important.

Like Google, Apple are wanting to know precisely what OS APIs your app is
calling at the point of review - so they have some idea of the surface area
of attack for any malicious intent. How much analysis they currently do,
no-one really knows - however the guidelines means that (in principal) they
have reasons to pull any apps very quickly if they find that they are doing
something which is 'not allowed'.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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


___
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 20255 - Simple Loop Labeling

[Mark Waddingham via use-livecode]

On 2017-08-11 14:56, Lagi Pittas via use-livecode wrote:
I thought you didn't agree with USING next repeat as a structured way 
of

programming - Reading and understanding before my Brain was in gear.


Sorry - I should have made that more clear - 'next repeat' and 'exit 
repeat' are definitely immeasurably better than GOTO or hand-coded 
bools.


Just to clarify - I meant 'harmful with respect analyses the compiler 
might want to do in the future' when not tied to the directly enclosing 
loop. I answered my own question by responding to you though - it is 
almost the same transform required as for 'exit repeat' :)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Drag Queen

[Richmond Mathewson via use-livecode]

Thanks Both, Klaus and Mark.

Richmond.

On 8/11/17 2:00 pm, Mark Waddingham via use-livecode wrote:

On 2017-08-11 12:43, Richmond Mathewson via use-livecode wrote:

I am in trouble because I cannot work out why this is not working:

on scrollbarDrag NVAL
   put "NVAL,0,0" into KARRAY["color"]
   put 50 into KARRAY["opacity"]
   set the coloroverlay of img "BB" to KARRAY
end scrollbarDrag


Try:

put NVAL,0,0 into KARRAY["color"]

Warmest Regards,

Mark.



___
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

Fwd: Speed of control lookup (Was Re: Parent of Target)

[Mark Waddingham via use-livecode]

On 2017-08-11 11:12, Mark Waddingham via use-livecode wrote:

On 2017-08-10 21:10, Richard Gaskin via use-livecode wrote:

How might I measure the benefits of long ID caching?


Here is perhaps a better set of simple benchmarks to compare approaches 
to lookup (related to ids, anyway):




on mouseUp
   local tIterations
   put 10 into tIterations

   -- card id is 1002
   -- button id is 1003
   -- group id is 1004
   local tLongId
   put the long id of button id 1003 of group id 1004 of card id 1002 
into tLongId


   local tButtonIdOfStack
   put "button id 1003 of stack" && quote & "LongIdSpeedTest" & quote 
into tButtonIdOfStack


   local tButtonIdOfCardIdOfStack
   put "button id 1003 of card id 1002 of stack" && quote & 
"LongIdSpeedTest" & quote into tButtonIdOfCardIdOfStack


   local tTime
   put the millisecs into tTime
   repeat tIterations times
  get the id of me
   end repeat
   put "Control" && (the millisecs - tTime) & return into msg

   put the millisecs into tTime
   repeat tIterations times
  get the id of tLongId
   end repeat
   put "GetIdOfLongIdInString" && (the millisecs - tTime) & return after 
msg


   put the millisecs into tTime
   repeat tIterations times
  get the id of tButtonIdOfCardIdOfStack
   end repeat
   put "GetIdOfButtonIdOfCardIdOfStackInString" && (the millisecs - 
tTime) & return after msg


   put the millisecs into tTime
   repeat tIterations times
  get the id of tButtonIdOfStack
   end repeat
   put "GetIdOfButtonIdOfStackInString" && (the millisecs - tTime) & 
return after msg


   put the millisecs into tTime
   repeat tIterations times
  get the id of button id 1003 of group id 1004 of card id 1002 of 
stack "LongIdSpeedTest"

   end repeat
   put "GetIdOfButtonIdOfGroupIdOfCardIdOfStack" && (the millisecs - 
tTime) & return after msg


   put the millisecs into tTime
   repeat tIterations times
  get the id of button id 1003 of card id 1002 of stack 
"LongIdSpeedTest"

   end repeat
   put "GetIdOfButtonIdOfCardIdOfStack" && (the millisecs - tTime) & 
return after msg


   local tStackString
   put "LongIdSpeed" & "Test" into tStackString

   put the millisecs into tTime
   repeat tIterations times
  get the id of button id 1003 of group id 1004 of card id 1002 of 
stack tStackString

   end repeat
   put "GetIdOfButtonIdOfGroupIdOfStackNotName" && (the millisecs - 
tTime) & return after msg


   put the millisecs into tTime
   repeat tIterations times
  get the id of button id 1003 of card id 1002 of stack tStackString
   end repeat
   put "GetIdOfButtonIdOfCardIdOfStackNotName" && (the millisecs - 
tTime) & return after msg

end mouseUp



On my machine (in 8.1.5) I get:

Control 21
GetIdOfLongIdInString 714
GetIdOfButtonIdOfCardIdOfStackInString 497
GetIdOfButtonIdOfStackInString 320
GetIdOfButtonIdOfGroupIdOfCardIdOfStack 56
GetIdOfButtonIdOfCardIdOfStack 53
GetIdOfButtonIdOfGroupIdOfStackNotName 65
GetIdOfButtonIdOfCardIdOfStackNotName 63

So, currently, there is a significant overhead to getting a control 
reference out of a string - the minimum you actually need in a string to 
uniquely identify a control (which may or may not have per-card data) is 
"control id ... of card id ... of stack ...".


Indeed - using the minimal info you need hard-coded in syntax:

  get the id of button id 1003 of card id 1002 of stack tStackString

Is about 10 times faster than using a long id in a string and about 8 
times faster than using a modified form of a string id to cut out the 
(strictly) unnecessary bits:


  get the id of "button id 1003 of card id 1002 of stack 
LongIdSpeedTest" -- quoted name, appropriately


So, my advice changes *slightly* - if you are doing tight loops which 
need to manipulate lots of controls in the current card of the 
defaultStack use:


  control id 

If the things aren't on the current card of the default stack, then 
extract the card id and stack name outside of the loop and use:


  control id  of card id tCardId of stack tStackName

The question of course is 'how fast could we get long id parsing to be' 
(as that is the bottleneck here, or at least appears to be).


Warmest Regards,

Mark.

P.S. Due to a mailing server glitch any mails which were sent here 
between 12:30BST and 14:00BST will not have got through.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Bug 20255 - Simple Loop Labeling

[Lagi Pittas via use-livecode]

HI Mark,

I was probably reading more into this ...

"Certainly 'exit repeat ...' would not be harmful, 'next repeat ...' I'd
have to analyze more deeply"

I thought you didn't agree with USING next repeat as a structured way of
programming - Reading and understanding before my Brain was in gear.

But if nothing else we got another erudite exposition about programming
methodology (and I am being sincere here lest you think I'm yanking your
chain).

We could do a "Mark On Software"  a bit like "Joel on Software" - always
readable and you learn something - even if it's about Baking Bread (look it
up).

I think these threads in the mailing list with the engineers such as
yourself, Monte, Ali and Panos  is something I don't think any other
development system has - I might be wrong - and such a great way of honing
the system that I would like to thank you all again for LC (Other than the
 dot notation, the open language  ...
https://www.youtube.com/watch?v=Y7tvauOJMHo  ;-) )

Kindest Regards Lagi



On 11 August 2017 at 12:16, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-11 12:51, Lagi Pittas via use-livecode wrote:
>
>> Hi Mark,
>>
>> I Beg to Differ about Next Repeat.
>>
>> "It's not wat you do it's the way that you do it" comes to mind
>>
>> Someone who writes spaghetti code can do it very well in any language but
>> its much more difficult without the structure brought in by the
>> Algol/Pascal/Modula.
>>
>
> I'm not sure I quite get your point here...
>
> Pure structured control flow does not allow any exit from a loop (it's
> definition is actually related to properties of the 'control-flow graph'
> (CFG) created by what are called 'basic blocks' when you analyze code at a
> more fundamental level than the syntax - structured control-flow only
> produces 'reducible CFGs' which have nice properties).
>
> However, there are relatively straightforward transformation you can apply
> to mostly-structured-control-flow with 'exit' to turn it into pure
> structured control flow:
>
>   repeat while tCondition
> ... before ...
>
> exit repeat
>
> ... after ...
>   end while
>
> Can be re-written as:
>
>   repeat while tCondition and not tExit
> ... before ...
>
> put true into tExit
>
> if not tExit then
>   ... after ...
> end if
>   end repeat
>
> The latter is 'pure structured control flow' - so 'exit loop' does no
> harm; the compiler can do an 'easy' transformation on the code to make it
> work; and that transformation is something which you have to do by hand if
> 'exit loop' is not available.
>
> The key thing here is extending 'exit loop' to allow you to exit from more
> than one loop at once - if a language does not have this ability directly,
> then you have to write code to do it yourself (which is always possible -
> by the above transformation). Needing to exit multiple loops is not
> uncommon - which is why that extension might well be useful.
>
> Similarly, 'next repeat' is often useful at least in the current loop -
> I'm not sure how useful it is for nested loops - it might not be. However,
> there is a transformation you can do for that as well:
>
>   repeat while tCondition
> ... before ...
>
> next repeat
>
> ... after ...
>   end while
>
> Becomes:
>
>   repeat while tCondition
> ... before ...
>
> put true into tNext
>
> if not tNext then
>   ... after ...
> end if
>   end while
>
> So, having written that, clearly it is fine (it is actually the same as
> 'exit repeat'; except that the boolean flag you need to create doesn't
> become part of the loop condition).
>
> If you only allow GOTOS within a procedure to a NON numeric label then you
>> can write structured code in any language.
>>
>
> Not strictly true - I think the rules (in terms of the actual underlying
> definition of structured control flow) is that you must not jump into a
> block of code which has a jump from elsewhere at the top. e.g.
>
> void func()
> {
>while(condition)
>{
>  ...
> foo:
>   if (baz)
> goto bar:
>}
>
>while(othercondition)
>{
>  ...
> bar:
>  if (foobar)
>goto foo:
>}
> }
>
> This produces a non-reducible CFG if memory serves. So as soon as you
> allow general GOTO, you end up with the ability to create irksome CFGs from
> the point of view of a compiler.
>
> Of course if it is time critical and every millisecond saved is important
>> then if spaghetti code is needed to get the speed then there is no "best
>> way" . But as I have said I have never missed Goto in nearly 40 Years of
>> Coding in High level languages (you can't not use them in Machine code
>> which Dijkstra was acknowledging in his "Goto Considered Harmful"
>> article).
>>
>
> Indeed - the ability for a compiler to analyse code is the thing which
> makes it potentially run faster. With GOTO you can do the optimizations
> yourself; however, in almost all cases if you can only produce 

Re: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 12:20, Jonathan Lynch via use-livecode wrote:

I know the reviewers at app stores are not always careful, but
something like an LC player would surely get their notice.


Review, from my understanding, is heavily automated (it has to be - if 
you think of the scale of the App Stores these days). However, there is 
always a means to get in contact with a human about specific issues 
(which can take a while to get escalated with someone who can actually 
do something - but at least it is possible).



They do allow us to import JS, but JS is way more sandboxed than LC.


Yes - this is true - however, as I noticed this morning Apple no longer 
have their advisory about allowing arbitrary JS to be downloaded and run 
within a WebView. This is simply because you can could build a host app 
which gives access to every single OS
API on iOS and make all of them callable from JS (even if the JS bundled 
with the app does not use any of it).


So, the point is the language is not the point - what the code running 
in the language does is important.


Like Google, Apple are wanting to know precisely what OS APIs your app 
is calling at the point of review - so they have some idea of the 
surface area of attack for any malicious intent. How much analysis they 
currently do, no-one really knows - however the guidelines means that 
(in principal) they have reasons to pull any apps very quickly if they 
find that they are doing something which is 'not allowed'.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Bug 20255 - Simple Loop Labeling

[Mark Waddingham via use-livecode]

On 2017-08-11 12:51, Lagi Pittas via use-livecode wrote:

Hi Mark,

I Beg to Differ about Next Repeat.

"It's not wat you do it's the way that you do it" comes to mind

Someone who writes spaghetti code can do it very well in any language 
but

its much more difficult without the structure brought in by the
Algol/Pascal/Modula.


I'm not sure I quite get your point here...

Pure structured control flow does not allow any exit from a loop (it's 
definition is actually related to properties of the 'control-flow graph' 
(CFG) created by what are called 'basic blocks' when you analyze code at 
a more fundamental level than the syntax - structured control-flow only 
produces 'reducible CFGs' which have nice properties).


However, there are relatively straightforward transformation you can 
apply to mostly-structured-control-flow with 'exit' to turn it into pure 
structured control flow:


  repeat while tCondition
... before ...

exit repeat

... after ...
  end while

Can be re-written as:

  repeat while tCondition and not tExit
... before ...

put true into tExit

if not tExit then
  ... after ...
end if
  end repeat

The latter is 'pure structured control flow' - so 'exit loop' does no 
harm; the compiler can do an 'easy' transformation on the code to make 
it work; and that transformation is something which you have to do by 
hand if 'exit loop' is not available.


The key thing here is extending 'exit loop' to allow you to exit from 
more than one loop at once - if a language does not have this ability 
directly, then you have to write code to do it yourself (which is always 
possible - by the above transformation). Needing to exit multiple loops 
is not uncommon - which is why that extension might well be useful.


Similarly, 'next repeat' is often useful at least in the current loop - 
I'm not sure how useful it is for nested loops - it might not be. 
However, there is a transformation you can do for that as well:


  repeat while tCondition
... before ...

next repeat

... after ...
  end while

Becomes:

  repeat while tCondition
... before ...

put true into tNext

if not tNext then
  ... after ...
end if
  end while

So, having written that, clearly it is fine (it is actually the same as 
'exit repeat'; except that the boolean flag you need to create doesn't 
become part of the loop condition).


If you only allow GOTOS within a procedure to a NON numeric label then 
you

can write structured code in any language.


Not strictly true - I think the rules (in terms of the actual underlying 
definition of structured control flow) is that you must not jump into a 
block of code which has a jump from elsewhere at the top. e.g.


void func()
{
   while(condition)
   {
 ...
foo:
  if (baz)
goto bar:
   }

   while(othercondition)
   {
 ...
bar:
 if (foobar)
   goto foo:
   }
}

This produces a non-reducible CFG if memory serves. So as soon as you 
allow general GOTO, you end up with the ability to create irksome CFGs 
from the point of view of a compiler.


Of course if it is time critical and every millisecond saved is 
important
then if spaghetti code is needed to get the speed then there is no 
"best
way" . But as I have said I have never missed Goto in nearly 40 Years 
of

Coding in High level languages (you can't not use them in Machine code
which Dijkstra was acknowledging in his "Goto Considered Harmful"  
article).


Indeed - the ability for a compiler to analyse code is the thing which 
makes it potentially run faster. With GOTO you can do the optimizations 
yourself; however, in almost all cases if you can only produce 
structured control flow, then a suitable competent compiler can do the 
work for you - making your code easier to read and maintain, whilst 
still not loosing performance.


Warmest Regards,

Mark.

P.S. I should point out that LCS is not a 'suitably competent compiler' 
as yet - however, that does not mean we should introduce language 
features which make it much harder for it to be given greater 
competence.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Drag Queen

[Klaus major-k via use-livecode]

Hi Richmond,

> Am 11.08.2017 um 12:43 schrieb Richmond Mathewson via use-livecode 
> :
> 
> I am in trouble because I cannot work out why this is not working:
> 
> on scrollbarDrag NVAL

## You are passing the STRING NVAL and not its value:

>  ## put "NVAL,0,0" into KARRAY["color"]
put NVAL & ",0,0" into KARRAY["color"]
>   put 50 into KARRAY["opacity"]
>   set the coloroverlay of img "BB" to KARRAY
> end scrollbarDrag
> 
> Richmond.

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
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: Drag Queen

[Mark Waddingham via use-livecode]

On 2017-08-11 12:43, Richmond Mathewson via use-livecode wrote:

I am in trouble because I cannot work out why this is not working:

on scrollbarDrag NVAL
   put "NVAL,0,0" into KARRAY["color"]
   put 50 into KARRAY["opacity"]
   set the coloroverlay of img "BB" to KARRAY
end scrollbarDrag


Try:

put NVAL,0,0 into KARRAY["color"]

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Bug 20255 - Simple Loop Labeling

[Lagi Pittas via use-livecode]

Hi Mark,

I Beg to Differ about Next Repeat.

"It's not wat you do it's the way that you do it" comes to mind

Someone who writes spaghetti code can do it very well in any language but
its much more difficult without the structure brought in by the
Algol/Pascal/Modula.

I have not used a Goto Since I used Fortran, Basic  and Cobol at Uni  they
introduced Pascal later and it was a breath of fresh air.
If you really want to be pedantic down at the assembler and machine code
level it's Gotos all the way BNE,  BCC, BEQ anyone?

If you only allow GOTOS within a procedure to a NON numeric label then you
can write structured code in any language.

What is EXIT to Top if not a GOTO so rules are always there to be broken in
certain  cases - a simple comment next to the "NEXT REPEAT"  and all is
good.

The problem arises when procedure with "jumps" in (EXIT, NEXT REPEAT, LOOP
etc are too big to fit on a page.

Personally I hate too many if then else's and many a time code the "If
then" inline because the second one will never be executed - the amount of
extra time in execution is minimal.  I don't do it too often but usually if
the routine starts to get too wide for the screen, but then I might break
each one up into its own Procedure and use a switch statement to call them.

Of course if it is time critical and every millisecond saved is important
then if spaghetti code is needed to get the speed then there is no "best
way" . But as I have said I have never missed Goto in nearly 40 Years of
Coding in High level languages (you can't not use them in Machine code
which Dijkstra was acknowledging in his "Goto Considered Harmful"  article).

Regards Lagi



On 11 August 2017 at 10:51, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-08-10 21:33, Dr. Hawkins via use-livecode wrote:
>
>> In fact, what I would *like* is modern Fortran style labelling or
>> something
>> like that, and the ability to the those labels to controls like next and
>> exit.  This, however, would accomplish so much with so little.
>>
>
> Thinking out loud here and taking into account suggestions people have
> made in the past...
>
> Naming loops in a syntactic way certainly sounds like a useful thing to do:
>
> repeat for each line tLine in tContainer named LineLoop
>   repeat for each item tItem in tLine named ItemLoop
> if some complicated condition then
>   exit repeat ItemLoop
> else if some other complicated condition then
>   exit repeat LineLoop
> end if
>
> -- do other stuff
> if some even more complicated condition then
>   next repeat LineLoop
> end if
>   end repeat ItemLoop
> end repeat LineLoop
>
> Certainly 'exit repeat ...' would not be harmful, 'next repeat ...' I'd
> have to analyze more deeply.
>
> The main problem with GOTO (apart from the ability to create very hard to
> understand code) is that it allows creation of what is called 'unstructured
> control-flow'. Basically that means that you have to work *exceptionally*
> hard to untangle it in a compile to perform any sort of reasonable
> optimization.
>
> At present LiveCode only allows you to produce 'structured control flow'.
> Adding 'next repeat ...', doesn't change that... However, 'next repeat ...'
> is not so clear (I think it is probably fine, but need to check some
> algorithmics).
>
> The only other issue with the above (beyond implementing it) is the
> syntax... It would reserve 'named' as a non-operator in this context. If we
> did ever have reason to have 'X named Y' then in repeats you'd have to do:
>
>   repeat for each line tLine in (tContainer named ...) named ...
>
> Although - without knowing what 'named' might do as an operator, or being
> able to think of anything it could do - that is probably a safe addition
> from that point of view.
>
> (Of course we could use 'labelled' instead of 'named' in the repeat
> context - 'labelled' seems for some reason less likely to be leveragable as
> a binary operator!)
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: 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
>
___
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

Drag Queen

[Richmond Mathewson via use-livecode]

I am in trouble because I cannot work out why this is not working:

on scrollbarDrag NVAL
   put "NVAL,0,0" into KARRAY["color"]
   put 50 into KARRAY["opacity"]
   set the coloroverlay of img "BB" to KARRAY
end scrollbarDrag

Richmond.
___
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: JPNG

[hh via use-livecode]

@Mark

*** Thanks for your expertise. I couldn't do that this perfectly. ***

One of the reasons for posting this JPNG stack is to show the power of LC:
The essential code of compressing PNG -> JPNG and decompresing PNG -> JPNG
is both less than 10 *essential* lines of code, using comfortable LC tools.

It is currently "en vogue" to try using JPEG compression together with
transparency. The js- and/or objC-people have to do _a lot more_ for that.

So take my demo stack as 'suggestion for the engine', to add a JPNG format
to LiveCode with a compression parameter and an useAlphaDataOrMaskData switch.
[ Possibly also with adding JPEG 2000 (.jp2)? ]
The work is nearly done as it is already available in the engine to a big part.
And for the dictionary entry use your post ;-)

This all could contribute to make the size of standalones that contain a lot
of PNG-compressed images significantly smaller. An may also be of advantage
for a usage together with the browser widget.
Once again, with a JPEGquality of 80 I have here in average JPNG-compressed
sizes of 30% compared to the original PNG-compressed sizes.

[I'll update the JPNG stack today for use on RaspberryPi 2/3 (and in LC 6/7).]


Mark wrote:
> On 2017-08-11 09:29, Richmond Mathewson via use-livecode wrote:
> > In theory that sounds both impressive and useful . . .
> > 
> > But, what, apart from your stack can read the format/compression
> > method properly.
> 
> I think Hermann's suggestion is a bespoke way of reducing resource size 
> for built apps and their content - as there isn't a 'standard' for JPNG 
> (yet) it isn't really useful for interchange between apps, but it might 
> be that a standard does appear at some point.
> 
> > Can your stack export a JPNG image?
> 
> It doesn't need to in order to be useful. This is something which could 
> be used at the point of building a standalone (in a standaloneSaving 
> handler, for example) to convert PNG images into a smaller form for use 
> by the app at runtime.
> 
> > "This may even result in a larger data size than the original when
> > decompressing."
> 
> I'm not sure I quite understand that comment...
> 
> Any (loss-less) compression algorithm will produce output which is 
> larger than the input for some inputs 
> (https://en.wikipedia.org/wiki/Lossless_compression#Limitations). So all 
> (such) compression algorithms tend to have a flag in their encoded 
> output which says 'this is not compressed'. When the compressor runs, if 
> the output is greater in size than the original input it just emits the 
> output with that flag and the original data. (In this case, if the JPNG 
> process produces a data size larger than the original PNG, just use the 
> original PNG!).
> 
> In this case the JPNG idea exploits the fact that color images tend to 
> withstand data-loss, but alpha data (masks) do not - JPEG is lossy, it 
> removes information which our eyes cannot see. PNG compression (a 
> variant of gzip IIRC) is loss-less, it preserves the exact values of the 
> inputs. So you use the lossy method (JPEG) on the part of the image 
> which makes no difference to our eyes, and the loss-less method (PNG) on 
> the part of the image which our eyes would notice a difference in.
> 
> Warmest Regards,
> 
> Mark.


___
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: Weird thing I noticed with a graphics speed test

[Jonathan Lynch via use-livecode]

This explains - thanks! So I need to compare performance between the android 
and iOS devices to get a valid comparison.

The group has 20 small images. I will turn them into large images to increase 
the demand on pixel processing.

Sent from my iPhone

> On Aug 11, 2017, at 5:37 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
>> On 2017-08-10 03:38, Jonathan Lynch via use-livecode wrote:
>> Actually, I had forgotten to set the layermode of the group.
>> Now the number of passes on my Mac is 47 and on the android it is 31.
>> This still seems rather close. I expected the slow android device to
>> be like a quarter as fast.
> 
> How many device pixels are there in your group when on your Mac compared to 
> on your slow android device?
> 
> On Android and iOS, the engine uses OpenGLES to blit tiles to the screen 
> meaning that specific operation comes at virtually no cost.
> 
> On Desktop it doesn't use OpenGL, so blitting is in software. On Mac, there 
> are two options CoreGraphics or software - I think the former tends to be a 
> bit quicker than the latter (particularly for larger numbers of pixels).
> 
> Generally (for simple cases, where no mutation beyond movement is happening 
> in your display) you should find that acceleratedRendering will make 
> something on iOS/Android about the same speed as you would get on Desktop 
> without acceleratedRendering turned on.
> 
> Warmest Regards,
> 
> Mark.
> 
>> Sent from my iPhone
>>> On Aug 9, 2017, at 9:27 PM, jonathandly...@gmail.com wrote:
>>> I created a group with ten buttons. I have a function that scrolls this 
>>> group as many times as it can in a second.
>>> With acceleratedrendering on, it can scroll 30 times on my Mac. My very 
>>> slow android device also scrolls it 30 times.
>>> With accelerated rendering off, it can scroll the group 87 times on the Mac 
>>> and 35 times on the android.
>>> Why would the scrolling be faster with accelerated rendering off?
>>> Why do both devices have the same speed with accelerated rendering on?
>>> I thought accelerated rendering used the graphics card? Shouldn't this 
>>> graphically slow android be slower?
>>> Sent from my iPhone
>> ___
>> 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
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: 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

___
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 LC Apps Downloading Stacks After installation

[Jonathan Lynch via use-livecode]

Thank you, Mark.

This was a great explanation.

I know the reviewers at app stores are not always careful, but something like 
an LC player would surely get their notice. 

They do allow us to import JS, but JS is way more sandboxed than LC.

Sent from my iPhone

> On Aug 11, 2017, at 3:55 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> Okay so the thread from which this post came has some glaringly large and 
> obvious incorrect statements in it so I think it wise I correct them.
> 
> First of all being able to submit apps to the App Stores which exist today is 
> critically important to our ecosystem - those App Stores come with rules 
> about what is allowed and what is not - the players involved here have 
> demonstrated that they can and will change those rules without consultation 
> and also have budgets larger than you can imagine so, no, you will not win a 
> fight with them so I strongly suggest not trying in the first place. (Also, 
> remember these are *their* gardens - they are not public - they are free to 
> do what they want and see fit!).
> 
> From my perspective, there are numerous things we could do technically to the 
> engine in order to completely prevent any Apps in our ecosystem violating the 
> critical rules which seem to cause a lot of confusion. I'd rather not do this 
> as it would be a very large blunt instrument based on a very strict 
> interpretation of said rules which would mean a lot of you would have to 
> rewrite a fair bit of code (e.g. We completely remove the ability to compile 
> code at runtime if the engine is running in the context of one of those 
> stores - no 'do' or variants, no ability to create objects with any code 
> attached etc).
> 
> So, first question - is script 'executable code'? Yes. Script is code (they 
> are essentially synonyms in our 'world'); Script is executable - it is 
> executable by the LiveCode engine. Let's be clear about this - one can 
> 'hypothesise' about the boundary between code and data but it is pointless. 
> Data is code if it can be executed and *is* executed - i.e. cause a physical 
> processor to execute instructions which is parameterized by that data. (e.g. 
> 'Machine code' is data until it is put into an executable page and called - 
> so even as data it is code, if it is executed at some point).
> 
> Second question - do stackfiles contain executable code? Only if you put data 
> in them which could be considered to be executable - script is obviously 
> covered here. Whether that script be set as the script properties of buttons, 
> or as strings which you then set as a script on an existing object, or 
> execute with 'do'. The means by which a script is executed, or could be 
> executed, is immaterial. If your app takes data from a stackfile and causes 
> the engine to execute steps parameterized by that data, then your stackfile 
> contains executable code.
> 
> Third question - what are the rules?
> 
> The Apple App Store(s) Review Guidelines are here:
> 
> https://developer.apple.com/app-store/review/guidelines/
> 
> The Google Play Guidelines are here:
> 
> https://play.google.com/about/developer-content-policy/#!?modal_active=none
> 
> The critical parts related to 'executable code' for Apple's App Stores is:
> 
>  2.5.2 Apps should be self-contained in their bundles, and may not read or 
> write
>data outside the designated container area, nor may they download, 
> install,
>or execute code, including other apps. Apps designed to teach, 
> develop, or
>test executable code may, in limited circumstances, download code 
> provided
>that such code is not used for other purposes. Such apps must make the
>source code provided by the Application completely viewable and 
> editable
>by the user.
> 
> The critical parts related to 'executable code' for Google's Play Store is:
> 
>  Malicious Behavior
>  We don’t allow apps that steal data, secretly monitor or harm users, or are
>  otherwise malicious.
> 
>  An app distributed via Google Play may not modify, replace, or update itself
>  using any method other than Google Play’s update mechanism. Likewise, an app
>  may not download executable code (e.g. dex, JAR, .so files) from a source 
> other
>  than Google Play. This restriction does not apply to code that runs in a 
> virtual
>  machine and has limited access to Android APIs (such as JavaScript in a 
> webview
>  or browser).
> 
>  The following are explicitly prohibited:
>Viruses, trojan horses, malware, spyware or any other malicious software.
>Apps that link to or facilitate the distribution or installation of 
> malicious
>software.
>Apps or SDKs that download executable code, such as dex files or native 
> code,
>from a source other than Google Play.
>Apps that introduce or exploit security vulnerabilities.
>Apps that steal a user’s authentication information (such as usernames or
>passwords) 

Re: Bug 20255 - Simple Loop Labeling

[Mark Waddingham via use-livecode]

On 2017-08-10 21:33, Dr. Hawkins via use-livecode wrote:
In fact, what I would *like* is modern Fortran style labelling or 
something
like that, and the ability to the those labels to controls like next 
and

exit.  This, however, would accomplish so much with so little.


Thinking out loud here and taking into account suggestions people have 
made in the past...


Naming loops in a syntactic way certainly sounds like a useful thing to 
do:


repeat for each line tLine in tContainer named LineLoop
  repeat for each item tItem in tLine named ItemLoop
if some complicated condition then
  exit repeat ItemLoop
else if some other complicated condition then
  exit repeat LineLoop
end if

-- do other stuff
if some even more complicated condition then
  next repeat LineLoop
end if
  end repeat ItemLoop
end repeat LineLoop

Certainly 'exit repeat ...' would not be harmful, 'next repeat ...' I'd 
have to analyze more deeply.


The main problem with GOTO (apart from the ability to create very hard 
to understand code) is that it allows creation of what is called 
'unstructured control-flow'. Basically that means that you have to work 
*exceptionally* hard to untangle it in a compile to perform any sort of 
reasonable optimization.


At present LiveCode only allows you to produce 'structured control 
flow'. Adding 'next repeat ...', doesn't change that... However, 'next 
repeat ...' is not so clear (I think it is probably fine, but need to 
check some algorithmics).


The only other issue with the above (beyond implementing it) is the 
syntax... It would reserve 'named' as a non-operator in this context. If 
we did ever have reason to have 'X named Y' then in repeats you'd have 
to do:


  repeat for each line tLine in (tContainer named ...) named ...

Although - without knowing what 'named' might do as an operator, or 
being able to think of anything it could do - that is probably a safe 
addition from that point of view.


(Of course we could use 'labelled' instead of 'named' in the repeat 
context - 'labelled' seems for some reason less likely to be leveragable 
as a binary operator!)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Weird thing I noticed with a graphics speed test

[Mark Waddingham via use-livecode]

On 2017-08-10 03:38, Jonathan Lynch via use-livecode wrote:

Actually, I had forgotten to set the layermode of the group.

Now the number of passes on my Mac is 47 and on the android it is 31.

This still seems rather close. I expected the slow android device to
be like a quarter as fast.


How many device pixels are there in your group when on your Mac compared 
to on your slow android device?


On Android and iOS, the engine uses OpenGLES to blit tiles to the screen 
meaning that specific operation comes at virtually no cost.


On Desktop it doesn't use OpenGL, so blitting is in software. On Mac, 
there are two options CoreGraphics or software - I think the former 
tends to be a bit quicker than the latter (particularly for larger 
numbers of pixels).


Generally (for simple cases, where no mutation beyond movement is 
happening in your display) you should find that acceleratedRendering 
will make something on iOS/Android about the same speed as you would get 
on Desktop without acceleratedRendering turned on.


Warmest Regards,

Mark.


Sent from my iPhone


On Aug 9, 2017, at 9:27 PM, jonathandly...@gmail.com wrote:

I created a group with ten buttons. I have a function that scrolls 
this group as many times as it can in a second.


With acceleratedrendering on, it can scroll 30 times on my Mac. My 
very slow android device also scrolls it 30 times.


With accelerated rendering off, it can scroll the group 87 times on 
the Mac and 35 times on the android.


Why would the scrolling be faster with accelerated rendering off?

Why do both devices have the same speed with accelerated rendering on?

I thought accelerated rendering used the graphics card? Shouldn't this 
graphically slow android be slower?


Sent from my iPhone


___
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


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Bug 20255 - Simple Loop Labeling

[Lagi Pittas via use-livecode]

+100 To Mark for that one

In fact it could copy the complicated condition AND any comment after it -
best of all possible worlds

Lagi

On 11 August 2017 at 02:38, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/10/2017 06:24 PM, Monte Goulding via use-livecode wrote:
>
> So we need:
>>
>> 1. an optional way to add such comments (even users that want them might
>> not want them unless they are making spaghetti)
>> 2. automagical maintenance if the comments exist and you change the
>> condition
>> 3. work out whether tags rather than the actual condition is what people
>> really want because the condition might add too much clutter:
>>
>> if some complicated condition then # I’m a makin’ spaghetti
>> — spaghetti
>> end if # I’m a makin' spaghetti
>>
>
> I would actually argue against this. For me, the useful part would be
>
> end if # some complicated condition
>
> Otherwise, making the user come up with a comment that basically says
> "some complicated condition" anyway, and doing all the maintentance you've
> described above sounds like a lot of work for very little gain.
>
> --
>  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
___
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: common code patterns

[Mark Waddingham via use-livecode]

On 2017-08-10 19:38, Ralph DiMola via use-livecode wrote:

To make this even more flexible:

repeat for each line tLine in tLines with [counter] tIndex [start] 
[{1}|x]

[step] [{1}|y]

end repeat


Not quite on topic for the thread, but this interested in me in terms of 
- what are the use cases?


The common code pattern we see as justification for 'repeat for each 
line tLine and index tIndex in tLines' is that it allows you to use the 
efficiency of iteration over a primary container, whilst still retaining 
the index of the chunk being iterated over. i.e.


  put 0 into tIndex
  repeat for each line tLine in tContainer
add 1 to tIndex
if tLine is not line tIndex of tContainer then
  answer "Oh dear - something is *really* wrong"
end if
  end repeat

So an extension to the syntax with 'index' means you get both pieces of 
information and a good amount of duality which justifies its existence.


In what kinds of situation do you find yourself wanting an offset index, 
relative to the index of the iterated chunk?


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: JPNG

[Mark Waddingham via use-livecode]

On 2017-08-11 10:41, Richmond Mathewson via use-livecode wrote:

It may not, but the stack does export images with a .lcjpng suffix . .
. and the question is what for?


Perhaps so it can be loaded again by code which knows how to decompress 
them as images in LiveCode? After all you have to *store* resources 
somewhere, disk tends to be quite a good place ;)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Parent of Target

[Mark Waddingham via use-livecode]

On 2017-08-10 21:10, Richard Gaskin via use-livecode wrote:

How might I measure the benefits of long ID caching?


It isn't long ids which are cached - it is ids.

I made a few adjustments, tweaked a few things to remove some overheads 
which aren't relevant here:


private function MarkObjRef1 pCount
   repeat with x = 1 to pCount
  get the long id of button x of group 1 of card 1 of this stack
   end repeat
end MarkObjRef1

private function MarkObjRef2 pCount
   put the long id of group 1 of card 1 of this stack into tGrpObj
   repeat with x = 1 to pCount
  get the long id of button x of tGrpObj
   end repeat
end MarkObjRef2

private function MarkObjRef3 pCount
   repeat with x = 1 to pCount
  get the long id of sObjRefsA[x]
   end repeat
end MarkObjRef3

private function MarkObjRef4 pCount
   repeat with x = 1 to pCount
  get the long id of button id word 3 of sObjRefsA[x] of this stack
   end repeat
end MarkObjRef4

I get these results for (100 iterations with) 1000 groups:

0.000801 - Method 1 - full expression by number
0.001399 - Method 2 - mixed expression
0.001786 - Method 3 - long ID only
0.000665 - Method 4 - ID only
0.05 - Control

0.000796 - Method 1 wo Control - full expression by number
0.001394 - Method 2 wo Control - mixed expression
0.001781 - Method 3 wo Control - long ID only
0.00066 - Method 4 wo Control- ID only

And these results for (10 interations with) 1 groups:

0.05243 - Method 1 - full expression by number
0.05965 - Method 2 - mixed expression
0.0498 - Method 3 - long ID only
0.00697 - Method 4 - ID only
0.6 - Control

0.05237 - Method 1 wo Control - full expression by number
0.05959 - Method 2 wo Control - mixed expression
0.04974 - Method 3 wo Control - long ID only
0.00691 - Method 4 wo Control - ID only

Here you can see that:

Method 1 takes 65 times as long, even though the number of groups has 
only increased 10 times
Method 2 takes 42 times as long, even though the number of groups has 
only increased 10 times
Method 3 takes 30 times as long, even though the number of groups has 
only increased 10 times
Method 4 takes 10 times as long - the same factor as the increase in 
number of groups.


Here Method 4 is the only one truly exploiting the id cache to maximum 
effect - Methods 2 and 3 both have a stack lookup too - which is *not* 
currently cached.


The modified code is below.

Warmest Regards,

Mark.

=

local sObjRefsA

on mouseUp
   put 10 into n
   put (the number of btns of grp 1) * n into tIterations
   put 1 into tCount
   --
   put the millisecs into t
   repeat n
  put MarkObjRef1(tCount) into r1
   end repeat
   put the millisecs - t into t1
   --
   put the millisecs into t
   repeat n
  put MarkObjRef2(tCount) into r2
   end repeat
   put the millisecs - t into t2
   --
   -- Last test requires that we first obtain the object refs to
   -- measure the benefits of long ID caching:
   repeat with i = 1 to the number of btns of grp 1
  put the long id of btn i of grp 1 into sObjRefsA[i]
   end repeat
   --
   put the millisecs into t
   repeat n
  put MarkObjRef3(tCount) into r3
   end repeat
   put the millisecs - t into t3
   --
   put the millisecs into t
   repeat n
  put MarkObjRef4(tCount) into r4
   end repeat
   put the millisecs - t into t4

   put the millisecs into t
   repeat n
  put MarkObjRefControl(tCount) into r5
   end repeat
   put the millisecs - t into t5

   put the millisecs into t
   repeat n
  put MarkObjRefControlStackLookup(tCount) into r6
   end repeat
   put the millisecs - t into t6
   
   put t1/tIterations &" - Method 1 - full expression by number "  \
   &   t2/tIterations &" - Method 2 - mixed expression"   \
 &   t3/tIterations &" - Method 3 - long ID only"  \
 &   t4/tIterations &" - Method 4 - ID only"  \
 &   t5/tIterations &" - Control" & cr\
  & t6/tIterations & " - Control Stack Lookup" & cr

   put (t1 - t5)/tIterations &" - Method 1 - full expression by number " 
 \

   &  (t2 - t5)/tIterations &" - Method 2 - mixed expression"   \
 &   (t3 - t5)/tIterations &" - Method 3 - long ID only"  \
 &   (t4 - t5)/tIterations &" - Method 4 - ID only" after msg
end mouseUp

private function MarkObjRef1 pCount
   repeat with x = 1 to pCount
  get the long id of button x of group 1 of card 1 of this stack
   end repeat
end MarkObjRef1

private function MarkObjRef2 pCount
   put the long id of group 1 of card 1 of this stack into tGrpObj
   repeat with x = 1 to pCount
  get the long id of button x of tGrpObj
   end repeat
end MarkObjRef2

private function MarkObjRef3 pCount
   repeat with x = 1 to pCount
  get the long id of sObjRefsA[x]
   end repeat
end MarkObjRef3

private function MarkObjRef4 pCount
   repeat with x = 1 to pCount
  get the long id of button id (word 3 of sObjRefsA[x]) of this 
stack

   end repeat
end MarkObjRef4

private 

Re: JPNG

[Richmond Mathewson via use-livecode]

On 8/11/17 11:13 am, Mark Waddingham via use-livecode wrote:

On 2017-08-11 09:29, Richmond Mathewson via use-livecode wrote:

In theory that sounds both impressive and useful . . .

But, what, apart from your stack can read the format/compression
method properly.


I think Hermann's suggestion is a bespoke way of reducing resource 
size for built apps and their content - as there isn't a 'standard' 
for JPNG (yet) it isn't really useful for interchange between apps, 
but it might be that a standard does appear at some point.



Can your stack export a JPNG image?


It doesn't need to in order to be useful. This is something which 
could be used at the point of building a standalone (in a 
standaloneSaving handler, for example) to convert PNG images into a 
smaller form for use by the app at runtime.


It may not, but the stack does export images with a .lcjpng suffix . . . 
and the question is what for?


Richmond.


"This may even result in a larger data size than the original when
decompressing."


I'm not sure I quite understand that comment...

Any (loss-less) compression algorithm will produce output which is 
larger than the input for some inputs 
(https://en.wikipedia.org/wiki/Lossless_compression#Limitations). So 
all (such) compression algorithms tend to have a flag in their encoded 
output which says 'this is not compressed'. When the compressor runs, 
if the output is greater in size than the original input it just emits 
the output with that flag and the original data. (In this case, if the 
JPNG process produces a data size larger than the original PNG, just 
use the original PNG!).


In this case the JPNG idea exploits the fact that color images tend to 
withstand data-loss, but alpha data (masks) do not - JPEG is lossy, it 
removes information which our eyes cannot see. PNG compression (a 
variant of gzip IIRC) is loss-less, it preserves the exact values of 
the inputs. So you use the lossy method (JPEG) on the part of the 
image which makes no difference to our eyes, and the loss-less method 
(PNG) on the part of the image which our eyes would notice a 
difference in.


Warmest Regards,

Mark.




___
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: JPNG

[Mark Waddingham via use-livecode]

On 2017-08-11 09:29, Richmond Mathewson via use-livecode wrote:

In theory that sounds both impressive and useful . . .

But, what, apart from your stack can read the format/compression
method properly.


I think Hermann's suggestion is a bespoke way of reducing resource size 
for built apps and their content - as there isn't a 'standard' for JPNG 
(yet) it isn't really useful for interchange between apps, but it might 
be that a standard does appear at some point.



Can your stack export a JPNG image?


It doesn't need to in order to be useful. This is something which could 
be used at the point of building a standalone (in a standaloneSaving 
handler, for example) to convert PNG images into a smaller form for use 
by the app at runtime.



"This may even result in a larger data size than the original when
decompressing."


I'm not sure I quite understand that comment...

Any (loss-less) compression algorithm will produce output which is 
larger than the input for some inputs 
(https://en.wikipedia.org/wiki/Lossless_compression#Limitations). So all 
(such) compression algorithms tend to have a flag in their encoded 
output which says 'this is not compressed'. When the compressor runs, if 
the output is greater in size than the original input it just emits the 
output with that flag and the original data. (In this case, if the JPNG 
process produces a data size larger than the original PNG, just use the 
original PNG!).


In this case the JPNG idea exploits the fact that color images tend to 
withstand data-loss, but alpha data (masks) do not - JPEG is lossy, it 
removes information which our eyes cannot see. PNG compression (a 
variant of gzip IIRC) is loss-less, it preserves the exact values of the 
inputs. So you use the lossy method (JPEG) on the part of the image 
which makes no difference to our eyes, and the loss-less method (PNG) on 
the part of the image which our eyes would notice a difference in.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: 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: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

Okay so the thread from which this post came has some glaringly large 
and obvious incorrect statements in it so I think it wise I correct 
them.


First of all being able to submit apps to the App Stores which exist 
today is critically important to our ecosystem - those App Stores come 
with rules about what is allowed and what is not - the players involved 
here have demonstrated that they can and will change those rules without 
consultation and also have budgets larger than you can imagine so, no, 
you will not win a fight with them so I strongly suggest not trying in 
the first place. (Also, remember these are *their* gardens - they are 
not public - they are free to do what they want and see fit!).


From my perspective, there are numerous things we could do technically 
to the engine in order to completely prevent any Apps in our ecosystem 
violating the critical rules which seem to cause a lot of confusion. I'd 
rather not do this as it would be a very large blunt instrument based on 
a very strict interpretation of said rules which would mean a lot of you 
would have to rewrite a fair bit of code (e.g. We completely remove the 
ability to compile code at runtime if the engine is running in the 
context of one of those stores - no 'do' or variants, no ability to 
create objects with any code attached etc).


So, first question - is script 'executable code'? Yes. Script is code 
(they are essentially synonyms in our 'world'); Script is executable - 
it is executable by the LiveCode engine. Let's be clear about this - one 
can 'hypothesise' about the boundary between code and data but it is 
pointless. Data is code if it can be executed and *is* executed - i.e. 
cause a physical processor to execute instructions which is 
parameterized by that data. (e.g. 'Machine code' is data until it is put 
into an executable page and called - so even as data it is code, if it 
is executed at some point).


Second question - do stackfiles contain executable code? Only if you put 
data in them which could be considered to be executable - script is 
obviously covered here. Whether that script be set as the script 
properties of buttons, or as strings which you then set as a script on 
an existing object, or execute with 'do'. The means by which a script is 
executed, or could be executed, is immaterial. If your app takes data 
from a stackfile and causes the engine to execute steps parameterized by 
that data, then your stackfile contains executable code.


Third question - what are the rules?

The Apple App Store(s) Review Guidelines are here:

https://developer.apple.com/app-store/review/guidelines/

The Google Play Guidelines are here:

https://play.google.com/about/developer-content-policy/#!?modal_active=none

The critical parts related to 'executable code' for Apple's App Stores 
is:


  2.5.2 Apps should be self-contained in their bundles, and may not read 
or write
data outside the designated container area, nor may they 
download, install,
or execute code, including other apps. Apps designed to teach, 
develop, or
test executable code may, in limited circumstances, download 
code provided
that such code is not used for other purposes. Such apps must 
make the
source code provided by the Application completely viewable and 
editable

by the user.

The critical parts related to 'executable code' for Google's Play Store 
is:


  Malicious Behavior
  We don’t allow apps that steal data, secretly monitor or harm users, 
or are

  otherwise malicious.

  An app distributed via Google Play may not modify, replace, or update 
itself
  using any method other than Google Play’s update mechanism. Likewise, 
an app
  may not download executable code (e.g. dex, JAR, .so files) from a 
source other
  than Google Play. This restriction does not apply to code that runs in 
a virtual
  machine and has limited access to Android APIs (such as JavaScript in 
a webview

  or browser).

  The following are explicitly prohibited:
Viruses, trojan horses, malware, spyware or any other malicious 
software.
Apps that link to or facilitate the distribution or installation of 
malicious

software.
Apps or SDKs that download executable code, such as dex files or 
native code,

from a source other than Google Play.
Apps that introduce or exploit security vulnerabilities.
Apps that steal a user’s authentication information (such as 
usernames or
passwords) or that mimic other apps or websites to  trick users into 
disclosing

personal or authentication information.
Apps that install other apps on a device without the user’s prior 
consent.
Apps designed to secretly collect device usage, such as commercial 
spyware apps.


These are pretty clear - at the point of submission to the app stores, 
you must present the full 'code' of your app and ensure that it is 
possible to execute it through some interaction with your app. Code 
(regardless of 

Re: JPNG

[Richmond Mathewson via use-livecode]

In theory that sounds both impressive and useful . . .

But, what, apart from your stack can read the format/compression method 
properly.


Also, for the sake of argument: LiveCode can export images in the .PNG, 
.JPG, .GIF and the (horribly obscure ?) .PBM formats.


Can your stack export a JPNG image?

And, if, so; what will read it?

AND this:

"This may even result in a larger data size than the original when 
decompressing."


doesn't bode well.

Richmond.

On 8/11/17 2:56 am, hh via use-livecode wrote:

JPNG (named using JPEG and PNG) is not an image format but a compression method.
We use the file ending ".lcjpng" for that.

It takes features from both JPEG (setting JPEGquality to compress the imageData
and from the PNG compression the alphaData/transparency). It saves the 
alphaData,
optionally the maskData, and the JPEG-compressed imageData in one file. The
JPNG-compressed image has here, using a JPEGquality of 80, around 25% of the
PNG-compressed size.

So this may be interesting for people who wish to compress (significantly in
size) the PNG-images containing transparency in their stack/standalone and
decompress only some images for "current" use.

Compression/Decompression is very fast.

See stack "JPNG" via the "Sample stacks" of the LC toolbar or (slower) here:
http://livecodeshare.runrev.com/stack/841/JPNG
This sample stack compresses to files or to (numbered) custom properties.

Note: I don't use the JPNG data structure of js or objC, but you can easily
convert it to that.


___
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