Running SpiderMonkey JavaScript shell

[Alejandro Tejada via use-livecode]

Hi All,

Recently, I have been looking at running Javascript libraries inside
LiveCode (like bzip2 decompress) but instead of using RevBrowser or CEF
Browser, have been taken a look at using SpiderMonkey JavaScript shell:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Introduction_to_the_JavaScript_shell

I am looking for your advice and caveats about running SpiderMonkey
JavaScript shell from LiveCode.
Thanks in advance!

Al
___
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: Changes to Msg Path from LC 7 to 8?

[hh via use-livecode]

> JLG wrote:
> ... "t" for handler-local variables, "g" for globals,
> "s" for script-locals, and "k" for constants ...
> If you adopt a system like this, you'll never have a
> naming conflict.

> Mark W. wrote:
> tExt is all I'll say ;) (thanks to Ken Ray for that one)

The LC Builder StyleGuide recommends "m" for widget static variables.
There is indeed a useful thing one can do with that, so that a lot
of things sound familiar to me(!).

private variable mE as ScriptObject
put my script object into mE

Now this is valid and unambiguous code both in LCB and LCS

send "mouseDown" to mE  ;-)


___
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: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> On 08/06/2017 22:37, Richard Gaskin via use-livecode wrote:
>> Alex Tweedly wrote:
>>
>> > On 08/06/2017 20:20, Richard Gaskin wrote:
>> >> If you're committed to a script-only stack there's no decision to
>> >> make: every control must be instantiated dynamically, because a
>> >> script-only stack contains the stack script only, no objects.
>> >>
>> > Well, not quite "every control".
>> >
>> > You could :
>> >   - if the relevant template control/group exists - copy it
>> >   - if not, create it dynamically, and then copy it
>> >
>> > This way
>> >   - the stack can be script-only
>> >   - most instantiations take minimal time
>>
>> True, to the degree that your app uses non-script-only stacks, you
>> won't need to do everything in script only. :)
>>
>>
> No, I'm actually doing this all within a script-only stack.
> It's a behaviour stack, which is used as a behaviour attached to
> groups in the main app stack (which could be binary or script-only).
> The behaviour is defined to create controls (actually, groups) as
> requested by the main stack - which basically sets up a list of needed
> controls, and then calls a handler in the behaviour.
>
> So something vaguely like 
>
> on preOpenCard
>
>settheEditingMode ofgrp"grp1"ofmetoFALSE
>
> settheSpec ofgrp"grp1"ofmetogSpec
>
> dispatch"buildGroup"togrp"grp1"
>
> ...
>
> and within 'buildgroup' it does the
>   check for the template group existing, create it (from an internal
> default set of properties) if needed
>
> This also (I think) allows for the app stack to pre-define the
> template groups ahead of time, thereby pre-empting the creation of the
> groups within the behaviour stack. Haven't actually done that yet, or
> fully considered the problems doing so will create - but it's a
> loophole I'm leaving myself in case I need it :-)


I don't understand.  A script-only stack contain no objects, so even if 
you later copy them, they still need to be dynamically instantiated at 
some point, no?


Like a Zen koan: how can there be a binary object where there is no 
binary object?


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

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

Re: Changes to Msg Path from LC 7 to 8?

[Dr. Hawkins via use-livecode]

On Thu, Jun 8, 2017 at 2:39 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Would name-spaces help?


I'm no fan of C, but I'd sure like to get its variable scoping into
livecode . . .

[*duck*]


-- 
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: Instantiaing Grouped Controls - Templates - Responsive

[Alex Tweedly via use-livecode]

On 08/06/2017 22:37, Richard Gaskin via use-livecode wrote:

Alex Tweedly wrote:

> On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
>> If you're committed to a script-only stack there's no decision to
>> make: every control must be instantiated dynamically, because a
>> script-only stack contains the stack script only, no objects.
>>
> Well, not quite "every control".
>
> You could :
>   - if the relevant template control/group exists - copy it
>   - if not, create it dynamically, and then copy it
>
> This way
>   - the stack can be script-only
>   - most instantiations take minimal time

True, to the degree that your app uses non-script-only stacks, you 
won't need to do everything in script only. :)



No, I'm actually doing this all within a script-only stack.
It's a behaviour stack, which is used as a behaviour attached to groups 
in the main app stack (which could be binary or script-only). The 
behaviour is defined to create controls (actually, groups) as requested 
by the main stack - which basically sets up a list of needed controls, 
and then calls a handler in the behaviour.


So something vaguely like 

on preOpenCard

  settheEditingMode ofgrp"grp1"ofmetoFALSE

settheSpec ofgrp"grp1"ofmetogSpec

dispatch"buildGroup"togrp"grp1"

...


and within 'buildgroup' it does the
 check for the template group existing, create it (from an internal 
default set of properties) if needed


This also (I think) allows for the app stack to pre-define the template 
groups ahead of time, thereby pre-empting the creation of the groups 
within the behaviour stack. Haven't actually done that yet, or fully 
considered the problems doing so will create - but it's a loophole I'm 
leaving myself in case I need it :-)


-- 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: Changes to Msg Path from LC 7 to 8?

[Tom Glod via use-livecode]

glad u worked it out Tom

On Thu, Jun 8, 2017 at 5:22 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> There's a spoil-sport in every crowd. :P
>
>
> On 6/8/17 4:19 PM, Mark Waddingham via use-livecode wrote:
>
>> tExt is all I'll say ;) (thanks to Ken Ray for that one)
>>
>> Warmest Regards,
>>
>> Mark.
>>
>> Sent from my iPhone
>>
>> On 8 Jun 2017, at 22:07, J. Landman Gay via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>>
>>> On 6/8/17 3:19 PM, tbodine via use-livecode wrote:
 Thanks for the encouragement, Richard. Looks like I'll be doing the
 "Humility
 Workout" for quite some time.
 For future list searchers who might have this same symptom, I found the
 cause: One of my stack level scripts used "theme" as a parameter name,
 but
 apparently that's a reserved term that is strictly enforced in LC 8.
 Changing that allowed all my stack scripts to run normally.

>>>
>>> That's the main reason I preface all variables with a letter, usually
>>> "t" for handler-local variables, "g" for globals, "s" for script-locals,
>>> and "k" for constants. You don't have to use the same letters but those
>>> have pretty much become the standards (some people prefer "c" for
>>> constants, but I use that for custom properties.)
>>>
>>> If you adopt a system like this, you'll never have a naming conflict.
>>>
>>> --
>>> 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
>>
>>
>
> --
> 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: 64 bit desktop apps

[Dr. Hawkins via use-livecode]

On Thu, Jun 8, 2017 at 7:44 AM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> here is no logical reason a 64 bit app would run slower than a 32 bit one.


At least in the special case of needing to load data that gets stored in 64
bit words where 32 bit words would have been sufficient, you could end up
with twice as many memory accesses.


-- 
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: Changes to Msg Path from LC 7 to 8?

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> Jacque wrote:
>> That's the main reason I preface all variables with a letter, usually
>> "t" for handler-local variables, "g" for globals, "s" for script-
>> locals, and "k" for constants. You don't have to use the same letters
>> but those have pretty much become the standards (some people prefer
>> "c" for constants, but I use that for custom properties.)
>>
>> If you adopt a system like this, you'll never have a naming conflict.
>
> tExt is all I'll say ;) (thanks to Ken Ray for that one)

Would name-spaces help?

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

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
>> If you're committed to a script-only stack there's no decision to
>> make: every control must be instantiated dynamically, because a
>> script-only stack contains the stack script only, no objects.
>>
> Well, not quite "every control".
>
> You could :
>   - if the relevant template control/group exists - copy it
>   - if not, create it dynamically, and then copy it
>
> This way
>   - the stack can be script-only
>   - most instantiations take minimal time

True, to the degree that your app uses non-script-only stacks, you won't 
need to do everything in script only. :)


Even simpler, as long as you're mixing binary and script-only stacks, 
just use binary stacks for the UI driven by behaviors defined in 
script-only stacks.


That's how I do most of my stuff these days.  I think of the UI stacks 
as somewhat akin to NeXT/Apple NIB files, with most of the code separate 
from them.


This lets me keep code where code is most productive (plain text), and 
lets me keep UI where UI is most productive (building the visual 
elements visually in the IDE).


I don't work in production teams large enough to require multiple 
developers crafting UIs in the same window at the same time, so keeping 
UI in binary stacks has worked well for me.  YMMV.



>> Which reminds me: before I run off an spend an afternoon writing one,
>> has anyone here written a tool that reads a stack laid out with
>> objects and produces the script needed to recreate it from a
>> script-only stack?
>
> Haven't done it - but I really should have done by now :-)

Please consider it. I could get it done, but it would be a long script. 
If you write it it'll be a three-liner done with some clever use of 
arrays. :)


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

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

Re: Changes to Msg Path from LC 7 to 8?

[J. Landman Gay via use-livecode]

There's a spoil-sport in every crowd. :P

On 6/8/17 4:19 PM, Mark Waddingham via use-livecode wrote:

tExt is all I'll say ;) (thanks to Ken Ray for that one)

Warmest Regards,

Mark.

Sent from my iPhone


On 8 Jun 2017, at 22:07, J. Landman Gay via use-livecode 
 wrote:


On 6/8/17 3:19 PM, tbodine via use-livecode wrote:
Thanks for the encouragement, Richard. Looks like I'll be doing the "Humility
Workout" for quite some time.
For future list searchers who might have this same symptom, I found the
cause: One of my stack level scripts used "theme" as a parameter name, but
apparently that's a reserved term that is strictly enforced in LC 8.
Changing that allowed all my stack scripts to run normally.


That's the main reason I preface all variables with a letter, usually "t" for handler-local variables, "g" 
for globals, "s" for script-locals, and "k" for constants. You don't have to use the same letters but those 
have pretty much become the standards (some people prefer "c" for constants, but I use that for custom properties.)

If you adopt a system like this, you'll never have a naming conflict.

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




--
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: Changes to Msg Path from LC 7 to 8?

[Mark Waddingham via use-livecode]

tExt is all I'll say ;) (thanks to Ken Ray for that one)

Warmest Regards,

Mark.

Sent from my iPhone

> On 8 Jun 2017, at 22:07, J. Landman Gay via use-livecode 
>  wrote:
> 
>> On 6/8/17 3:19 PM, tbodine via use-livecode wrote:
>> Thanks for the encouragement, Richard. Looks like I'll be doing the "Humility
>> Workout" for quite some time.
>> For future list searchers who might have this same symptom, I found the
>> cause: One of my stack level scripts used "theme" as a parameter name, but
>> apparently that's a reserved term that is strictly enforced in LC 8.
>> Changing that allowed all my stack scripts to run normally.
> 
> That's the main reason I preface all variables with a letter, usually "t" for 
> handler-local variables, "g" for globals, "s" for script-locals, and "k" for 
> constants. You don't have to use the same letters but those have pretty much 
> become the standards (some people prefer "c" for constants, but I use that 
> for custom properties.)
> 
> If you adopt a system like this, you'll never have a naming conflict.
> 
> -- 
> 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: [ANN] Introducing Remote DB Lib

[Richard Gaskin via use-livecode]

Andre Garzia wrote:

> On Wed, Jun 7, 2017 at 7:43 PM, Richard Gaskin wrote:
>> VPSes are great when you need custom configuration, but they can be a
>> challenge to set up when you're learning, and a bigger challenge to
>> harden sufficiently, things a shared hosting service takes care of.
>
>> Is your library for the LC Server CGI, or does it require a custom LC
>> standalone daemon?
>
> The server part is PHP for maximum compatibility with cheap VPS
> everywhere but I am thinking about doing a LC based one as well.

To clarify, my question was mostly focused on whether your solution will 
work well on shared hosting services as it on VPSes.


Written in PHP, it sounds like it will.

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

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

Re: Changes to Msg Path from LC 7 to 8?

[J. Landman Gay via use-livecode]

On 6/8/17 2:35 PM, tbodine via use-livecode wrote:

Another clue... If I use the message box to call any simple stack level
handler, LC 8 changes that command to a put statement.

Example:

I type in msg box: zzShow -- a stack level handler
Msg box changes my cmd to "put zzShow" and then puts "zzShow" in the output
area.


It surprised me too the first time I saw it, but this is now the 
behavior when the message box can't find a handler.


--
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: Changes to Msg Path from LC 7 to 8?

[J. Landman Gay via use-livecode]

On 6/8/17 3:19 PM, tbodine via use-livecode wrote:

Thanks for the encouragement, Richard. Looks like I'll be doing the "Humility
Workout" for quite some time.

For future list searchers who might have this same symptom, I found the
cause: One of my stack level scripts used "theme" as a parameter name, but
apparently that's a reserved term that is strictly enforced in LC 8.
Changing that allowed all my stack scripts to run normally.


That's the main reason I preface all variables with a letter, usually 
"t" for handler-local variables, "g" for globals, "s" for script-locals, 
and "k" for constants. You don't have to use the same letters but those 
have pretty much become the standards (some people prefer "c" for 
constants, but I use that for custom properties.)


If you adopt a system like this, you'll never have a naming conflict.

--
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: Changes to Msg Path from LC 7 to 8?

[tbodine via use-livecode]

Thanks for the encouragement, Richard. Looks like I'll be doing the "Humility
Workout" for quite some time.

For future list searchers who might have this same symptom, I found the
cause: One of my stack level scripts used "theme" as a parameter name, but
apparently that's a reserved term that is strictly enforced in LC 8.
Changing that allowed all my stack scripts to run normally.

Tom B.





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Changes-to-Msg-Path-from-LC-7-to-8-tp4715613p4715619.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: Instantiaing Grouped Controls - Templates - Responsive

[Alex Tweedly via use-livecode]

On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:

In general I try to "go to TOWN": Touch Only What's Needed.

If I don't need to create an object I probably won't, adjusting an 
existing object instead.  It only saves one step, but its a savings 
just the same.


If you're committed to a script-only stack there's no decision to 
make: every control must be instantiated dynamically, because a 
script-only stack contains the stack script only, no objects.



Well, not quite "every control".

You could :
 - if the relevant template control/group exists - copy it
 - if not, create it dynamically, and then copy it

This way
 - the stack can be script-only
 - most instantiations take minimal time



Which reminds me: before I run off an spend an afternoon writing one, 
has anyone here written a tool that reads a stack laid out with 
objects and produces the script needed to recreate it from a 
script-only stack?


Seems tedious to write, but less tedious than writing instantiation 
code for every property of every object of every card of every stack I 
might make script-only.



Haven't done it - but I really should have done by now :-)

-- 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: 64 bit desktop apps

[Bob Sneidar via use-livecode]

Simple: Unicode support. It's not 64 bit that is slowing you down. Not sure how 
you make that connection. 

Bob S


> On Jun 8, 2017, at 09:08 , JosebaTELUR via use-livecode 
>  wrote:
> 
> Hello:
> 
> Why LiveCode 8 or 9 in 64bits are more slwww than LiveCode 5.5.4 in my 
> new iMac with Sierra??
> Please LiveCode programmers move forward, not back  
> 
> Un saludo.
> 
> Joseba Aguayo Fernández
> (jagu...@telur.es)

___
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: 64 bit desktop apps

[Bob Sneidar via use-livecode]

Microsoft suffered for years over backwards compatibility with DOS. MS wanted 
to move forward with their OS at a quicker pace but there were so many 
"critical" apps running under DOS that talked directly with the hardware, that 
no one wanted MS to depricate it. Windows 95 was supposed to be the first 
version of Windows to break the chain, but had to retain some functionality 
still. Even Windows 98 was still bound in some ways with DOS. 

The point is, you have the right to expect backwards compatibility... to a 
point. Where is that point? Well let's see, how long ago did Apple stop 
suporting 32 bit OS? As far as I am concerned, that is the point beyond which 
backwards compatibility is gratis. 

Bob S


> On Jun 8, 2017, at 03:04 , Richmond via use-livecode 
>  wrote:
> 
> So, backwards compatibility does not interest you?
> 
> I, for one, run Mac Machines running MacOS 10.4 PPC.
> 
> A lot of these machine are being dumped in poor countries where they can be 
> used
> for good purposes.
> 
> Richmond.
> 
> On 08/06/17 09:19, Mark Waddingham via use-livecode wrote:
>> On 2017-06-07 21:59, Richmond Mathewson via use-livecode wrote:
>>> I disagree as there are plenty of Macs "out there" in the worldthat
>>> run 32-bit systems.
>> 
>> Not that LiveCode supports.
>> 
>>> Far better to have BOTH possibilities checked as default.
>> 
>> Only if there existed a Mac which can run LiveCode but cannot run 64-bit 
>> apps - which is the case for LiveCode 9.x as it supports 10.9+.
>> 
>> Indeed it would be far better to have no possibility at all (simpler) - just 
>> build for 64-bit since...
>> 
>> 64-bit support has been around since 10.6, at that time there were machines 
>> which could run 10.6 which were 32-bit only.
>> 
>> However, all macs which will run 10.7 will run 64-bit apps.
>> 
>> Therefore, if LiveCode only supports 10.7 and above, then LiveCode and any 
>> apps you build with it need only be 64-bit.
>> 
>> 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


___
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: Changes to Msg Path from LC 7 to 8?

[Tom Glod via use-livecode]

Hey Tom...I jsut yesterday switched my huge project to 8.1.4  and when
i first started migrating i had a lot of issues .

i don't have an answer to your particular problem except to say that LC 8.1
engine is much more strict and actually more trustworthy and less ambiguous.

every error i had that worked on 7.1  was my error.  be patient and i think
u will be bale to fix the issues. but trust the engine before you trust
yourself. chances are its you.

i avoided the switch because i as never sure if i was dealing with lc bug
or my own. aside from 1 ..it was all me...and a few pieces of sloppy
code.

its worth doing.


On Thu, Jun 8, 2017 at 3:35 PM, tbodine via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Another clue... If I use the message box to call any simple stack level
> handler, LC 8 changes that command to a put statement.
>
> Example:
>
> I type in msg box: zzShow -- a stack level handler
> Msg box changes my cmd to "put zzShow" and then puts "zzShow" in the output
> area.
>
> Tom
>
>
>
> --
> View this message in context: http://runtime-revolution.
> 278305.n4.nabble.com/Changes-to-Msg-Path-from-LC-7-to-8-
> tp4715613p4715614.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
>
___
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: Changes to Msg Path from LC 7 to 8?

[tbodine via use-livecode]

Another clue... If I use the message box to call any simple stack level
handler, LC 8 changes that command to a put statement.

Example:

I type in msg box: zzShow -- a stack level handler
Msg box changes my cmd to "put zzShow" and then puts "zzShow" in the output
area.

Tom



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Changes-to-Msg-Path-from-LC-7-to-8-tp4715613p4715614.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

Changes to Msg Path from LC 7 to 8?

[tbodine via use-livecode]

Hi all.

I am migrating a big project from LC 7.1.4 to LC 8.1.4, and hitting a wall
right away.

When my card scripts call stack level scripts directly, LC 8 throws a "can't
find handler" error. (I confirmed that the defaultStack is my main stack.)
LC 7 had no problem with this.

Example:

Card script:
on preopencard
centerThisCard
end preopencard

Stack script:
on centerThisCard
-- do stuff
end centerThisCard

Any theories or insights on why LC 8 won't do this when LC 7 will?

Thanks,
Tom B.




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Changes-to-Msg-Path-from-LC-7-to-8-tp4715613.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: 64 bit desktop apps

[Richmond Mathewson via use-livecode]

On 6/8/17 6:56 pm, Richard Gaskin via use-livecode wrote:

Roger Eller wrote:

> On Thu, Jun 8, 2017 at 10:56 AM, Richard Gaskin wrote:
>> Using a supported version of an OS that's receiving critical security
>> patches along with other updates is the safest choice, and one that
>> could not be more economical given a purchase price for most Linux
>> distros of zero.
...
>
> But even with PPC Linux to revive old hardware, if LiveCode usage is
> your end game, there isn't a PPC Linux version (or is there?).

Good point, touching on two aspects:

Security: Not only do OSes need to be updated to remain secure, but 
from time to time apps do too.


Viability:  When a user base for a given configuration is sufficiently 
low, it may be difficult to find resources to maintain it.


IIRC no computer running an OS LC supports has shipped with a PPC 
processor in about 12 years (Apple switched in 2005).  While I'm a big 
fan of minimizing landfills by extending the life of older hardware as 
much as practical, that's the key word, "practical".


If LC plays a critical role on a PPC machine revived with a supported 
OS, it will require that someone compile a version of LC for that CPU 
and OS.


At the moment, AFAIK the size of the audience for such a build is 
currently 1.


The size of the audience for a Linux PPC build is probably ZERO as I am 
not interested in one
(see my recent posting on Lubuntu on a PPC), and, while I am sure there 
are thousands of closet
PPC Linux users out there dying because they are deprived of LiveCode . 
. . .


This is a redundant discussion.

Richmond.


So clearly if this were to happen at all it would have to be a 
community project.


Given the time required, it may be more cost-effective to either 
replace the machines with any Intel-based system that can support 
modern OSes (here in the States many EDU orgs get donated Core Duo and 
Core 2 Duo machines from local businesses who've upgraded), or replace 
the LiveCode role on those machines with something that supports PPC.


With the latter option, though, it may buy only a little time but not 
much:  since no new mainstream computers have been made with PPC CPUs 
in more than a decade, it's only a matter of time before more and more 
projects stop supporting that architecture.  Over time the range of 
supported software for PPC can only get ever smaller.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.com http://www.FourthWorld.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: 64 bit desktop apps

[Richmond Mathewson via use-livecode]

Has anyone apart from me actually tried running Linux on a Mac PPC machine.

A few years ago I installed Lubuntu on a MacMini PPC and tried to build 
a PPC Linuxversion of Livecode,

and got nowehere.

Quite apart from my sad efforts at that, the machine was as slow as wet 
cement; functionally useless.


Linux LiveCode standalones do not run on Linux PPC distros.

Running 10.4 on a MacMini PPC is just fine unless one has a desire to 
hook up to the internet, at which point there is a (slight)

risk of complications.

Richmond.

On 6/8/17 5:56 pm, Richard Gaskin via use-livecode wrote:

Richmond wrote:

> So, backwards compatibility does not interest you?
>
> I, for one, run Mac Machines running MacOS 10.4 PPC.
>
> A lot of these machine are being dumped in poor countries where they
> can be used for good purposes.

I can appreciate the desire to get full life out of hardware, and 
indeed it would be nice of Apple continued supporting older machines.


But the choice to stop supporting older hardware and OS versions is 
Apple's, not LiveCode's.


Moreover, there is a solution available to extend the life of 
otherwise-unsupported hardware: Linux.


Using a supported version of an OS that's receiving critical security 
patches along with other updates is the safest choice, and one that 
could not be more economical given a purchase price for most Linux 
distros of zero.


For hardware that old you may find Lubuntu more satisfying than Ubuntu 
or other distros with steeper RAM and graphics requirements.  Both 
Alejandro and myself use Lubuntu and have found LiveCode runs quite 
well on it.


In fact, if you use my LiveNet plugin (bundled in the IDE; see 
Development -> Plugins -> GoLiveNet) the feeds on the second card 
there are aggregated, packaged, and posted every five minutes by a 
LiveCode app running on my Lubuntu box.


You can find more info on Lubuntu for PPC here:




___
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: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> 1) does it make sense to build this dynamically as needed from script
> using "create" and then you put this "create control" script into a
> library? It has the advantage of no binary object, so you can keep it
> in your text only "stacks" .livecodescript, but could be slow?
>
> OR
>
> 2) is it faster (on Android or iOS especially)  to create it as a
> template group  then use
>
> copy grp "info-display"  of card 1 of stack "dialog-templates" to this
> card
>
> ??
>
> What has your experience led you to choose as your best practice and
> why and how do you do it?

In general I try to "go to TOWN": Touch Only What's Needed.

If I don't need to create an object I probably won't, adjusting an 
existing object instead.  It only saves one step, but its a savings just 
the same.


If you're committed to a script-only stack there's no decision to make: 
every control must be instantiated dynamically, because a script-only 
stack contains the stack script only, no objects.



Which reminds me: before I run off an spend an afternoon writing one, 
has anyone here written a tool that reads a stack laid out with objects 
and produces the script needed to recreate it from a script-only stack?


Seems tedious to write, but less tedious than writing instantiation code 
for every property of every object of every card of every stack I might 
make script-only.


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

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

Re: 64 bit desktop apps

[Richmond Mathewson via use-livecode]

On 6/8/17 1:19 pm, Mark Waddingham via use-livecode wrote:

On 2017-06-08 12:04, Richmond via use-livecode wrote:

So, backwards compatibility does not interest you?


Seriously - you ask that question?

LiveCode 9 still happily runs stacks which were written in the early 
days of MetaCard.


We are *extremely* careful not to break existing scripts and stacks - 
we either do accidentally (if that is so, we fix those issues with a 
high degree of priority); if intentionally then it is only for a very 
good reason.



I, for one, run Mac Machines running MacOS 10.4 PPC.


LiveCode 6.6.5 was the last version of LiveCode to support PowerPC on 
Mac - so given we are talking about LiveCode *9* you point is entirely 
moot.


A lot of these machine are being dumped in poor countries where they 
can be used

for good purposes.


I appreciate that, but since Apple haven't supported PowerPC for a 
very long time, and their toolchains (the things we need to use to 
build the engine) haven't for a very long time - there's little hope 
of PowerPC being resurrected in a future LiveCode version unless 
someone stumps up a very very large amount of cash (we are talking on 
the order of $100,000+ as a start, and then a significant amount for 
ongoing maintenance) and even then finding reliable hardware which has 
the specs needed to do engine development is becoming increasingly 
difficult, if not impossible.


I'm afraid you misread my question. When I stated I was running MacOS 
10.4 PPC it was not in expectation of your leaping
up and down and say "Well, yes, Just for you, Richmond, we're going to 
set things up for future versions of LiveCode to

build Mac PPC standalones."

What I was concerned about was people running Early Intel Macintoshes 
that have 32-bit processors.


Warmest Regards,

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: 64 bit desktop apps

[Richmond Mathewson via use-livecode]

Tut, tut, Roger: you forgot the kilt!

Richmond.

On 6/8/17 1:34 pm, Roger Eller via use-livecode wrote:

-- In a dark back office, Richmond, wearing dark glasses, a fedora, and a
tan trenchcoat, dumps a large bag of Monopoly money onto the table.  Marks
eyes are now like saucers.  "Moot", Richmond says under his breath, then
leaves the room with a strut, as if he is carrying the world in his pocket.
--

~Roger

On Jun 8, 2017 6:19 AM, "Mark Waddingham via use-livecode" <
use-livecode@lists.runrev.com> wrote:


On 2017-06-08 12:04, Richmond via use-livecode wrote:


So, backwards compatibility does not interest you?


Seriously - you ask that question?

LiveCode 9 still happily runs stacks which were written in the early days
of MetaCard.

We are *extremely* careful not to break existing scripts and stacks - we
either do accidentally (if that is so, we fix those issues with a high
degree of priority); if intentionally then it is only for a very good
reason.

I, for one, run Mac Machines running MacOS 10.4 PPC.
LiveCode 6.6.5 was the last version of LiveCode to support PowerPC on Mac
- so given we are talking about LiveCode *9* you point is entirely moot.

A lot of these machine are being dumped in poor countries where they can

be used
for good purposes.


I appreciate that, but since Apple haven't supported PowerPC for a very
long time, and their toolchains (the things we need to use to build the
engine) haven't for a very long time - there's little hope of PowerPC being
resurrected in a future LiveCode version unless someone stumps up a very
very large amount of cash (we are talking on the order of $100,000+ as a
start, and then a significant amount for ongoing maintenance) and even then
finding reliable hardware which has the specs needed to do engine
development is becoming increasingly difficult, if not impossible.

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: 64 bit desktop apps

[JosebaTELUR via use-livecode]

Hello:

Why LiveCode 8 or 9 in 64bits are more slwww than LiveCode 5.5.4 in my new 
iMac with Sierra??
Please LiveCode programmers move forward, not back  

Un saludo.

Joseba Aguayo Fernández
(jagu...@telur.es)


___
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: 64 bit desktop apps

[Rick Harrison via use-livecode]

Hi Richmond,

Did you miss the memo about:

Apple Zero-Day Flaw Leaves OS X Systems Vulnerable to Attack

Zero day flaws have always been there in the Mac OS X operating system
from the very beginning.  These have been patched in later versions of
Mac OS X, but earlier versions were never patched.  You are probably
vulnerable to such things on those older computers.

If you aren’t on the internet with any of those computers, and you scan all 
software for viruses before you install it, you might be fine. 

Or do you have some work around that no one knows about?

Cheers,

Rick


> On Jun 8, 2017, at 6:04 AM, Richmond via use-livecode 
>  wrote:
> 
> So, backwards compatibility does not interest you?
> 
> I, for one, run Mac Machines running MacOS 10.4 PPC.
> 
> A lot of these machine are being dumped in poor countries where they can be 
> used
> for good purposes.
> 
> 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: 64 bit desktop apps

[Richard Gaskin via use-livecode]

Roger Eller wrote:

> On Thu, Jun 8, 2017 at 10:56 AM, Richard Gaskin wrote:
>> Using a supported version of an OS that's receiving critical security
>> patches along with other updates is the safest choice, and one that
>> could not be more economical given a purchase price for most Linux
>> distros of zero.
...
>
> But even with PPC Linux to revive old hardware, if LiveCode usage is
> your end game, there isn't a PPC Linux version (or is there?).

Good point, touching on two aspects:

Security: Not only do OSes need to be updated to remain secure, but from 
time to time apps do too.


Viability:  When a user base for a given configuration is sufficiently 
low, it may be difficult to find resources to maintain it.


IIRC no computer running an OS LC supports has shipped with a PPC 
processor in about 12 years (Apple switched in 2005).  While I'm a big 
fan of minimizing landfills by extending the life of older hardware as 
much as practical, that's the key word, "practical".


If LC plays a critical role on a PPC machine revived with a supported 
OS, it will require that someone compile a version of LC for that CPU 
and OS.


At the moment, AFAIK the size of the audience for such a build is 
currently 1.


So clearly if this were to happen at all it would have to be a community 
project.


Given the time required, it may be more cost-effective to either replace 
the machines with any Intel-based system that can support modern OSes 
(here in the States many EDU orgs get donated Core Duo and Core 2 Duo 
machines from local businesses who've upgraded), or replace the LiveCode 
role on those machines with something that supports PPC.


With the latter option, though, it may buy only a little time but not 
much:  since no new mainstream computers have been made with PPC CPUs in 
more than a decade, it's only a matter of time before more and more 
projects stop supporting that architecture.  Over time the range of 
supported software for PPC can only get ever smaller.


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

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

Re: 64 bit desktop apps

[Roger Eller via use-livecode]

On Thu, Jun 8, 2017 at 10:56 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Richmond wrote:
>
> > So, backwards compatibility does not interest you?
> >
> > I, for one, run Mac Machines running MacOS 10.4 PPC.
> >
> > A lot of these machine are being dumped in poor countries where they
> > can be used for good purposes.
>
> I can appreciate the desire to get full life out of hardware, and indeed
> it would be nice of Apple continued supporting older machines.
>
> But the choice to stop supporting older hardware and OS versions is
> Apple's, not LiveCode's.
>
> Moreover, there is a solution available to extend the life of
> otherwise-unsupported hardware: Linux.
>
> Using a supported version of an OS that's receiving critical security
> patches along with other updates is the safest choice, and one that could
> not be more economical given a purchase price for most Linux distros of
> zero.
>
> For hardware that old you may find Lubuntu more satisfying than Ubuntu or
> other distros with steeper RAM and graphics requirements.  Both Alejandro
> and myself use Lubuntu and have found LiveCode runs quite well on it.
>
> In fact, if you use my LiveNet plugin (bundled in the IDE; see Development
> -> Plugins -> GoLiveNet) the feeds on the second card there are aggregated,
> packaged, and posted every five minutes by a LiveCode app running on my
> Lubuntu box.
>
> You can find more info on Lubuntu for PPC here:
> 
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com



But even with PPC Linux to revive old hardware, if LiveCode usage is your
end game, there isn't a PPC Linux version (or is there?).

~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: 64 bit desktop apps

[Richard Gaskin via use-livecode]

Richmond wrote:

> So, backwards compatibility does not interest you?
>
> I, for one, run Mac Machines running MacOS 10.4 PPC.
>
> A lot of these machine are being dumped in poor countries where they
> can be used for good purposes.

I can appreciate the desire to get full life out of hardware, and indeed 
it would be nice of Apple continued supporting older machines.


But the choice to stop supporting older hardware and OS versions is 
Apple's, not LiveCode's.


Moreover, there is a solution available to extend the life of 
otherwise-unsupported hardware: Linux.


Using a supported version of an OS that's receiving critical security 
patches along with other updates is the safest choice, and one that 
could not be more economical given a purchase price for most Linux 
distros of zero.


For hardware that old you may find Lubuntu more satisfying than Ubuntu 
or other distros with steeper RAM and graphics requirements.  Both 
Alejandro and myself use Lubuntu and have found LiveCode runs quite well 
on it.


In fact, if you use my LiveNet plugin (bundled in the IDE; see 
Development -> Plugins -> GoLiveNet) the feeds on the second card there 
are aggregated, packaged, and posted every five minutes by a LiveCode 
app running on my Lubuntu box.


You can find more info on Lubuntu for PPC here:


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

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

Re: 64 bit desktop apps

[Roger Eller via use-livecode]

LOVE IT!!!  Thanks for that info, Richard.

~Roger


On Thu, Jun 8, 2017 at 10:46 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Roger Eller wrote:
> > Once in a while I still miss running "Revolution" on Irix.  We move
> > forward, not backward.
>
> FWIW, IRIX is coming back - and as a Linux desktop, so we should be able
> to use the Linux build of LiveCode with it:
>
> Silicon Graphics' IRIX and Magic Desktop return as Linux desktop
>  desktop_revives_sgi_irix_and_magic_desktop/>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: 64 bit desktop apps

[Dr. Hawkins via use-livecode]

On Thu, Jun 8, 2017 at 3:34 AM, Roger Eller via use-livecode <
use-livecode@lists.runrev.com> wrote:

> -- In a dark back office, Richmond, wearing dark glasses, a fedora, and a
> tan trenchcoat, dumps a large bag of Monopoly money onto the table.  Marks
> eyes are now like saucers.  "Moot", Richmond says under his breath, then
> leaves the room with a strut, as if he is carrying the world in his pocket.
> --
>

moof!

(dating myself . . .)


-- 
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: 64 bit desktop apps

[Richard Gaskin via use-livecode]

Roger Eller wrote:
> Once in a while I still miss running "Revolution" on Irix.  We move
> forward, not backward.

FWIW, IRIX is coming back - and as a Linux desktop, so we should be able 
to use the Linux build of LiveCode with it:


Silicon Graphics' IRIX and Magic Desktop return as Linux desktop


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

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

Re: 64 bit desktop apps

[Bob Sneidar via use-livecode]

I was going to respond to this earlier but I decided not to. There is no 
logical reason a 64 bit app would run slower than a 32 bit one. Certainly not 
noticably slower. In fact, there is every reason to expect it to be faster in 
some respects, as the pipe to the processor is twice as wide. Not sure why 
Mark's benchmarks do not reflect that, but I am not an engineer. 

Of course the real benefit is that an app has access to more memory as the 
address space increases dramatically. 

Bob S


> On Jun 8, 2017, at 01:18 , Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2017-06-07 22:14, hh via use-livecode wrote:
>> 64bit mode usually makes apps slower. So what's Apple's intention?
>> To make their own apps "relatively faster" by making all others slower?
> 
> Do you have some benchmarks to back that up? I'd be interested to know what 
> sort of workloads the difference in processor affects.
> 
> For example, I ran the simple benchmarks we have in the engine source tree 
> using Community 8.1.3 once for 32-bit and once for 64-bit. The first number 
> is 64-bit, the second 32-bit:


___
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: AW: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 16:19, Paul Dupuis via use-livecode wrote:

On 6/8/2017 3:54 AM, Mark Waddingham via use-livecode wrote:

As a general request, can people let us know if they are relying on
externals on Mac which are currently 32-bit only?


Forgive the dumb question Mark, but how does someone tell whether
externals are 32 bit or 64 bit?


You can do it from the terminal:

otool -hv .bundle/Contents/MacOS/

Will list what executable 'slices' are in the external's executable.


In my first LC 8.1.3 64 bit build, I accidentally included
revVideoGrabber in my inclusions (we don;t use it, it had been checked
by accident). I discovered my OSX standalone would not even launch with
NO error messages or crash report. Only by opening the App bundle to
look around and double-clicking on the actual executable did I get a 
OSX

Terminal listing that showed error with LiveCode trying to start
revVideoGrabber and failing. Removing that from the Inclusion list
allowed creation of a Standalone that launched.


Could you file that as a bug? The S/B should ignore inclusions which are 
not available on the specified architecture and warn if there are 
mismatches.



Then we noticed that the default text font or text flow is different in
8.1.3 from 6.7.11 and test in our splash screen and a licensing dialog
is cut off under 8.1.3 vs 6.7.11. These are the details that add up to 
a

length migration time for large applications.


Yes - this is one thing which did change between 7 and 8 - unavoidably 
so as we moved to using CoreText to render text on Mac, rather than 
ATSUI.



As another example, in testing our LC6.7.11 app under LC8.1.4, I
discovered that the 'standaloneSaved pDestinationFolder' message 
returns:


 'C:/Users/Paul/Desktop/TestProject' under LC6.7.11. Note that the name
of the Standalone folder 'HyperRESEARCH' is not included and there is 
no

ending slash.

but

'C:/Users/Paul/Desktop/TestProject/HyperRESEARCH/" under LC8.1.3, Note
that the name of the Standalone folder 'HyperRESEARCH' is included and
there is a trailing slash


There has been a bit of churn in the SB messages since 6.7 - various 
attempts to fix various bugs. If you file a bug with this particular 
case, Panos will be able to check whether there is still a problem 
there.




On this topic, I applaud LiveCode for having 64 bit support. I curse
Apple for removing 32 bit support. I still have apps under LC6.7.11 and
LC 5.5.5 that now need to migrate to LC8.1.4+ in the next 6 months and 
I
am really annoyed at Apple for doing this. To be fair, we've known 
we've
need to catch up to current LiveCode releases for a good long while, 
but

between business pressures to add new features and fix customer visible
bugs, cleaning up code that needs fixing just due to engine changes
unfortunately always falls to last place. Now, fortunately or
unfortunately due to Apple's heavy handedness, it now moves to first
place for us.


Actually, things are not quite as they might appear from my reading.

Apple will not allow 32-bit slices in *new* apps submitted to the Mac 
App Store from January 2018, and will not accept updates to any app 
containing 32-bit slices from June 2018:


  https://9to5mac.com/2017/06/06/ios-11-32-bit-mac-app-store-64-bit/

Versions of Mac OS *after* High Sierra will no longer support 32-bit 
slices in apps:


   
https://www.imore.com/after-high-sierra-32-bit-games-mac-are-kicked-curb-0


So, right now, if you don't put your app into the MacAppStore - there is 
no need to worry.


If you are looking to submit a new app to MacAppStore then if you don't 
get it in before January 2018, it has to be 64-bit.


If you have an app in the MacAppStore, or will have before January 2018, 
then you have until June 2018 to make sure that it is 64-bit.


Everyone has until September 2018 (projected release date, based on 
history, for the version of mac after High Sierra) to make sure their 
apps can be 64-bit.


In regards to where LiveCode stands:

  - LiveCode started supporting 64-bit Mac from 8.x

  - In 9.0 we will be making 64-bit Mac mode the default for both IDE 
and Standalones


  - If you app works in 9.0, then the only thing blocking you from 
turning off the 32-bit slice is whether you use externals which are Mac 
32-bit only.


  - If you app works in 8.0, then the only thing blocking you from 
turning off the 32-bit slice is whether you use externals which are Mac 
32-bit only, or use QuickTime.


Hopefully this makes things a bit clearer.

We need to do a bit more research before deciding on the date of axing 
32-bit slices in LiveCode - however when we do this will *only* affect 
the 'develop' version at the time (i.e. 8.x will continue to be 
universal, as will all maintenance versions up to the axe date).


Again - please do contact me (off-list is fine, and better perhaps!) if 
any apps you have (and are intending to update / need to run on versions 
of Mac into the future) do rely on 32-bit Mac externals which we 
(LiveCode) d

Re: AW: 64 bit desktop apps

[Paul Dupuis via use-livecode]

On 6/8/2017 3:54 AM, Mark Waddingham via use-livecode wrote:
> As a general request, can people let us know if they are relying on
> externals on Mac which are currently 32-bit only?

Forgive the dumb question Mark, but how does someone tell whether
externals are 32 bit or 64 bit?


In my first LC 8.1.3 64 bit build, I accidentally included
revVideoGrabber in my inclusions (we don;t use it, it had been checked
by accident). I discovered my OSX standalone would not even launch with
NO error messages or crash report. Only by opening the App bundle to
look around and double-clicking on the actual executable did I get a OSX
Terminal listing that showed error with LiveCode trying to start
revVideoGrabber and failing. Removing that from the Inclusion list
allowed creation of a Standalone that launched.

Then we noticed that the default text font or text flow is different in
8.1.3 from 6.7.11 and test in our splash screen and a licensing dialog
is cut off under 8.1.3 vs 6.7.11. These are the details that add up to a
length migration time for large applications.

As another example, in testing our LC6.7.11 app under LC8.1.4, I
discovered that the 'standaloneSaved pDestinationFolder' message returns:

 'C:/Users/Paul/Desktop/TestProject' under LC6.7.11. Note that the name
of the Standalone folder 'HyperRESEARCH' is not included and there is no
ending slash.

but

'C:/Users/Paul/Desktop/TestProject/HyperRESEARCH/" under LC8.1.3, Note
that the name of the Standalone folder 'HyperRESEARCH' is included and
there is a trailing slash

A small difference, undoubtedly covered in release notes, but another
cause of code that needed to be changed to accommodate the differences
between 2 versions of the engine.


On this topic, I applaud LiveCode for having 64 bit support. I curse
Apple for removing 32 bit support. I still have apps under LC6.7.11 and
LC 5.5.5 that now need to migrate to LC8.1.4+ in the next 6 months and I
am really annoyed at Apple for doing this. To be fair, we've known we've
need to catch up to current LiveCode releases for a good long while, but
between business pressures to add new features and fix customer visible
bugs, cleaning up code that needs fixing just due to engine changes
unfortunately always falls to last place. Now, fortunately or
unfortunately due to Apple's heavy handedness, it now moves to first
place for us.



___
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 8.1.4 and Xcode 8.3.3

[hlowe via use-livecode]

Thank you Panos.

Henry



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/LC-8-1-4-and-Xcode-8-3-3-tp4715579p4715596.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: AW: 64 bit desktop apps

[Trevor DeVore via use-livecode]

On Thu, Jun 8, 2017 at 2:55 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> As a general request, can people let us know if they are relying on
> externals on Mac which are currently 32-bit only?


I have a couple of externals I use in my apps that are 32-bit. I haven't
set up my new dev computer to work on externals. I was hoping to just
convert the externals to modules once a Cocoa bridge was available and the
C bridge improved some.

-- 
Trevor DeVore

>
___
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 8.1.4 and Xcode 8.3.3

[panagiotis merakos via use-livecode]

Hi Henry,

This will be fixed in the next LC 8.1.5 RC1 release.

For anyone interested, see the bug report (and the fix):
http://quality.livecode.com/show_bug.cgi?id=19826

Best,
Panos
--

On Thu, Jun 8, 2017 at 8:32 AM, panagiotis merakos <
panos.mera...@livecode.com> wrote:

> Hi Henry,
>
> It seems that Xcode 8.3.3. was released yesterday, too. I will have a look
> at this issue. My guess is that in Xcode 8.3.3., Apple has (again!) changed
> some internal frameworks we use for deploying to simulator, so we need to
> tweak our code to workaround this.
>
> So yes, I suggest sticking to Xcode 8.3.2 for now, which is the latest
> tested Xcode that works with LiveCode 8.1.4.
>
> Best,
> Panos
> --
>
> On Thu, Jun 8, 2017 at 6:56 AM, hlowe via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> The release docs for LC 8.1.4 state:
>>
>>  "Last but not least, LiveCode 8.1.4 includes support for building iOS
>> apps
>> using the latest iOS SDKs, included in Xcode 8.3.x."
>>
>> Installed LC Indy 8.1.4 on a Mac under MacOS 10.12.5, installed the new
>> version of Xcode (8.3.3) and I get this error message when attempting to
>> run
>> an LC iOS app in the simulator:
>>
>> "Unable to start simulator: 634,0,0,iPhone Simulator version not found
>> 573,220,1,reviPhoneSetSimulatorSDK"
>>
>> Going to Preferences>Mobile Support and pointing at the newly installed
>> Xcode did not help. Reinstalled xCode 8.3.2 and everything back to normal.
>>
>> Henry
>>
>>
>>
>> --
>> View this message in context: http://runtime-revolution.2783
>> 05.n4.nabble.com/LC-8-1-4-and-Xcode-8-3-3-tp4715579.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
>>
>
>
>
> --
> Panagiotis Merakos 
> LiveCode Software Developer
>
> Everyone Can Create Apps 
>



-- 
Panagiotis Merakos 
LiveCode Software Developer

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

AW: Ben Beaumont jumps ship.

[Tiemo Hollmann TB via use-livecode]

Congratulations!

>> Heather
>> (who is now the longest surviving staff member other than Kevin)



___
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: 64 bit desktop apps

[Mark Schonewille via use-livecode]

I use a G4 Quicksilver as a server. I have taken it apart and put it back 
together several times, something I can't do with a Mac Mini or MacBook. I use 
Revolution 4.x for special server tasks. It would be convenient if I could use 
the latest version of LiveCode to build not only for Windows, Linux and Intel 
Macs but also for PowerMac. Obviously it would be cool if I could use all 
features of LiveCode 9 on the PowerMac, but I'd be happy already with just the 
possibility to build standalones for OSX 10.4. 


⁣Verzonden door BlueMail ​

Op 8 jun. 2017 12:06, om 12:06, Richmond via use-livecode 
 schreef:
>So, backwards compatibility does not interest you?
>
>I, for one, run Mac Machines running MacOS 10.4 PPC.
>
>A lot of these machine are being dumped in poor countries where they
>can 
>be used
>for good purposes.
>
>Richmond.
>
>On 08/06/17 09:19, Mark Waddingham via use-livecode wrote:
>> On 2017-06-07 21:59, Richmond Mathewson via use-livecode wrote:
>>> I disagree as there are plenty of Macs "out there" in the worldthat
>>> run 32-bit systems.
>>
>> Not that LiveCode supports.
>>
>>> Far better to have BOTH possibilities checked as default.
>>
>> Only if there existed a Mac which can run LiveCode but cannot run 
>> 64-bit apps - which is the case for LiveCode 9.x as it supports
>10.9+.
>>
>> Indeed it would be far better to have no possibility at all (simpler)
>
>> - just build for 64-bit since...
>>
>> 64-bit support has been around since 10.6, at that time there were 
>> machines which could run 10.6 which were 32-bit only.
>>
>> However, all macs which will run 10.7 will run 64-bit apps.
>>
>> Therefore, if LiveCode only supports 10.7 and above, then LiveCode
>and 
>> any apps you build with it need only be 64-bit.
>>
>> 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
___
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: 64 bit desktop apps

[Roger Eller via use-livecode]

Once in a while I still miss running "Revolution" on Irix.  We move
forward, not backward.

On Jun 8, 2017 6:39 AM, "Mark Waddingham via use-livecode" <
use-livecode@lists.runrev.com> wrote:

> On 2017-06-08 12:34, Roger Eller via use-livecode wrote:
>
>> -- In a dark back office, Richmond, wearing dark glasses, a fedora, and a
>> tan trenchcoat, dumps a large bag of Monopoly money onto the table.  Marks
>> eyes are now like saucers.  "Moot", Richmond says under his breath, then
>> leaves the room with a strut, as if he is carrying the world in his
>> pocket.
>> --
>>
>
> If you could pay for things in Monopoly money, then that would be more
> than welcome! ;)
>
> 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: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 12:34, Roger Eller via use-livecode wrote:
-- In a dark back office, Richmond, wearing dark glasses, a fedora, and 
a
tan trenchcoat, dumps a large bag of Monopoly money onto the table.  
Marks
eyes are now like saucers.  "Moot", Richmond says under his breath, 
then
leaves the room with a strut, as if he is carrying the world in his 
pocket.

--


If you could pay for things in Monopoly money, then that would be more 
than welcome! ;)


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: 64 bit desktop apps

[Roger Eller via use-livecode]

-- In a dark back office, Richmond, wearing dark glasses, a fedora, and a
tan trenchcoat, dumps a large bag of Monopoly money onto the table.  Marks
eyes are now like saucers.  "Moot", Richmond says under his breath, then
leaves the room with a strut, as if he is carrying the world in his pocket.
--

~Roger

On Jun 8, 2017 6:19 AM, "Mark Waddingham via use-livecode" <
use-livecode@lists.runrev.com> wrote:

> On 2017-06-08 12:04, Richmond via use-livecode wrote:
>
>> So, backwards compatibility does not interest you?
>>
>
> Seriously - you ask that question?
>
> LiveCode 9 still happily runs stacks which were written in the early days
> of MetaCard.
>
> We are *extremely* careful not to break existing scripts and stacks - we
> either do accidentally (if that is so, we fix those issues with a high
> degree of priority); if intentionally then it is only for a very good
> reason.
>
> I, for one, run Mac Machines running MacOS 10.4 PPC.
>>
>
> LiveCode 6.6.5 was the last version of LiveCode to support PowerPC on Mac
> - so given we are talking about LiveCode *9* you point is entirely moot.
>
> A lot of these machine are being dumped in poor countries where they can
>> be used
>> for good purposes.
>>
>
> I appreciate that, but since Apple haven't supported PowerPC for a very
> long time, and their toolchains (the things we need to use to build the
> engine) haven't for a very long time - there's little hope of PowerPC being
> resurrected in a future LiveCode version unless someone stumps up a very
> very large amount of cash (we are talking on the order of $100,000+ as a
> start, and then a significant amount for ongoing maintenance) and even then
> finding reliable hardware which has the specs needed to do engine
> development is becoming increasingly difficult, if not impossible.
>
> 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: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 12:28, hh via use-livecode wrote:

1) You are comparing 64bit and 32bit modes on a 64bit architecture.
This is the correct answer for my cheeky post above (by the way that
wasn't targeted, to the special case LiveCode and was a bit caused by
the fact that the first 64bit-Finder was 80-100% slower than the 32bit
variant).


The 32-bit Finder was Carbon and had been in development for years 
(moved forward from Arch to Arch).


The 64-bit Finder was completely rewritten in Cocoa - it would have 
taken a while for it to get optimized to the extent of the previous 
version - I suspect the performance differences were largely completely 
unrelated to even the move to Cocoa... Just the fact it was 'brand new 
code'.



2) My simple user experiences are that some 32bit apps perform on a
32bit architecture obviously faster than the 64bit variant on 64bit
architecture.

For example on Mac LC 6.5-standalones run the same optimized code (with
large imageData) on 32bit-architecture/slower CPU still 3-5 times 
faster

than the 64bit-LC 8.1.4 standalones variant on 64bit-architecture.


Heh - that's not comparing like with like though is it? ;)

The speed difference there is nothing to do with architecture of the 
CPU, but architecture of the engine. Which is a separate issue :)


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: 64 bit desktop apps

[hh via use-livecode]

Thanks for the enlightening explanation.
Of course I don't go into a technical discussion with an expert.

Only two remarks:

1) You are comparing 64bit and 32bit modes on a 64bit architecture.
This is the correct answer for my cheeky post above (by the way that
wasn't targeted, to the special case LiveCode and was a bit caused by
the fact that the first 64bit-Finder was 80-100% slower than the 32bit
variant).

2) My simple user experiences are that some 32bit apps perform on a
32bit architecture obviously faster than the 64bit variant on 64bit
architecture.

For example on Mac LC 6.5-standalones run the same optimized code (with
large imageData) on 32bit-architecture/slower CPU still 3-5 times faster
than the 64bit-LC 8.1.4 standalones variant on 64bit-architecture.

> On 2017-06-07 22:14, hh via use-livecode wrote:
> > 64bit mode usually makes apps slower. So what's Apple's intention?
> > To make their own apps "relatively faster" by making all others slower?
> 
> Do you have some benchmarks to back that up? I'd be interested to know 
> what sort of workloads the difference in processor affects.
> 
> For example, I ran the simple benchmarks we have in the engine source 
> tree using Community 8.1.3 once for 32-bit and once for 64-bit. The 
> first number is 64-bit, the second 32-bit:
> 
> Running RepeatForever...
>   3152 / 3136 ms
> Running RepeatCount...
>   526 / 523 ms
> Running RepeatWith...
>   407 / 412 ms
> Running ArrayNameKeys...
>   Store[] 291 / 266 ms
>   Fetch[] 215 / 217 ms
>   Store[][] 465 / 413 ms
>   Fetch[][] 318 / 313 ms
> Running ArrayIndexKeys...
>   Store[] 831 / 833 ms
>   Fetch[] 734 / 681 ms
>   Store[][] 1448 / 1403 ms
>   Fetch[][] 1278 / 1253 ms
> Running ArrayStringKeys...
>   Store[] 309 / 313 ms
>   Fetch[] 215 / 261 ms
>   Store[][] 471 / 493 ms
>   Fetch[][] 345 / 387 ms
> Running VariableFetchLocal...
>   Get Base 23 / 22 ms
>   Get Base[] 120 / 141 ms
>   Get Base[] 583 / 661 ms
>   Get Base[] 151 / 171 ms
>   Get Base[] 307 / 310 ms
>   Get Base[][] 152 / 177 ms
>   Get Base[][] 1072 / 1081 ms
>   Get Base[][] 214 / 240 ms
>   Get Base[] 454 / 463 ms
> Running VariableStoreLocal...
>   Replace Into Base 32 / 31 ms
>   Replace Into Base[] 39 / 34 ms
>   Replace Into Base[] 180 / 174 ms
>   Replace Into Base[] 44 / 41 ms
>   Replace Into Base[] 93 / 78 ms
>   Replace Into Base[][] 48 / 42 ms
>   Replace Into Base[][] 304 / 285 ms
>   Replace Into Base[][] 61 / 54 ms
>   Replace Into Base[] 120 / 121 ms
> 
> So, certainly for variable access and repeat loop overhead, the 
> differences are within the margin of error for such measurements - which 
> would probably go away if I ran them on a completely empty machine and 
> with increased number of iterations. The story is the exactly the same 
> for the 'strings' benchmarks we have there too.
> 
> Most of Apple's apps are 64-bit only and have been for quite some time 
> as there is no value in them shipping universal versions on any OS since 
> 10.6 (the only reason they would have done in previous versions is for 
> apps which they had not yet ported to Cocoa and away from QuickTime) - 
> all that does is waste download bandwidth and disk space.
> 
> Also, on the whole, Intel 64-bit machine code is can be much more 
> efficient than 32-bit. The 64-bit Intel architecture actually has a 
> measurable number of registers! 32-bit Intel processors have a huge 
> amount of logic inside them to alias memory locations and such 
> (essentially meaning memory accesses under specific conditions are akin 
> to accessing registers). Of course all that costs silicon which could be 
> used for better things - like caching and multiple cores. Basically, the 
> 64-bit Intel architecture is superior to the 32-bit one which does show 
> its age quite a bit.
> 
> FWIW, when we got LiveCode on 64-bit Linux, Fraser did some performance 
> tests which indicated on the whole, it ran about 5-10% faster than its 
> 32-bit counterpart. This was, admittedly, mainly in the area of graphics 
> - since the types of things you do to rasterize graphics at this level 
> benefits disproportionately from the number of registers available.
> 
> The thing is that most users won't ever notice whether an app is 32-bit 
> or 64-bit because Apple's approach (universal binaries) means that it 
> isn't possible to tell unless you go digging in Activity Monitor. (One 
> would expect for this to be the case - Apple have done the processor 
> architecture switch thing 3 times now - and in those cases it was to 
> completely different architectures).
> 
> The main reason to not bother with 32-bit builds when there is no reason 
> to is that it makes you much more efficient from the engineering point 
> of view. It removes any question (when writing code) as to whether "is 
> this correct for 32 and 64-bit" (admittedly, you try and structu

Re: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 12:04, Richmond via use-livecode wrote:

So, backwards compatibility does not interest you?


Seriously - you ask that question?

LiveCode 9 still happily runs stacks which were written in the early 
days of MetaCard.


We are *extremely* careful not to break existing scripts and stacks - we 
either do accidentally (if that is so, we fix those issues with a high 
degree of priority); if intentionally then it is only for a very good 
reason.



I, for one, run Mac Machines running MacOS 10.4 PPC.


LiveCode 6.6.5 was the last version of LiveCode to support PowerPC on 
Mac - so given we are talking about LiveCode *9* you point is entirely 
moot.


A lot of these machine are being dumped in poor countries where they 
can be used

for good purposes.


I appreciate that, but since Apple haven't supported PowerPC for a very 
long time, and their toolchains (the things we need to use to build the 
engine) haven't for a very long time - there's little hope of PowerPC 
being resurrected in a future LiveCode version unless someone stumps up 
a very very large amount of cash (we are talking on the order of 
$100,000+ as a start, and then a significant amount for ongoing 
maintenance) and even then finding reliable hardware which has the specs 
needed to do engine development is becoming increasingly difficult, if 
not impossible.


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: 64 bit desktop apps

[Richmond via use-livecode]

So, backwards compatibility does not interest you?

I, for one, run Mac Machines running MacOS 10.4 PPC.

A lot of these machine are being dumped in poor countries where they can 
be used

for good purposes.

Richmond.

On 08/06/17 09:19, Mark Waddingham via use-livecode wrote:

On 2017-06-07 21:59, Richmond Mathewson via use-livecode wrote:

I disagree as there are plenty of Macs "out there" in the worldthat
run 32-bit systems.


Not that LiveCode supports.


Far better to have BOTH possibilities checked as default.


Only if there existed a Mac which can run LiveCode but cannot run 
64-bit apps - which is the case for LiveCode 9.x as it supports 10.9+.


Indeed it would be far better to have no possibility at all (simpler) 
- just build for 64-bit since...


64-bit support has been around since 10.6, at that time there were 
machines which could run 10.6 which were 32-bit only.


However, all macs which will run 10.7 will run 64-bit apps.

Therefore, if LiveCode only supports 10.7 and above, then LiveCode and 
any apps you build with it need only be 64-bit.


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: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-07 22:14, hh via use-livecode wrote:

64bit mode usually makes apps slower. So what's Apple's intention?
To make their own apps "relatively faster" by making all others slower?


Do you have some benchmarks to back that up? I'd be interested to know 
what sort of workloads the difference in processor affects.


For example, I ran the simple benchmarks we have in the engine source 
tree using Community 8.1.3 once for 32-bit and once for 64-bit. The 
first number is 64-bit, the second 32-bit:


Running RepeatForever...
3152 / 3136 ms
Running RepeatCount...
526 / 523 ms
Running RepeatWith...
407 / 412 ms
Running ArrayNameKeys...
Store[] 291 / 266 ms
Fetch[] 215 / 217 ms
Store[][] 465 / 413 ms
Fetch[][] 318 / 313 ms
Running ArrayIndexKeys...
Store[] 831 / 833 ms
Fetch[] 734 / 681 ms
Store[][] 1448 / 1403 ms
Fetch[][] 1278 / 1253 ms
Running ArrayStringKeys...
Store[] 309 / 313 ms
Fetch[] 215 / 261 ms
Store[][] 471 / 493 ms
Fetch[][] 345 / 387 ms
Running VariableFetchLocal...
Get Base 23 / 22 ms
Get Base[] 120 / 141 ms
Get Base[] 583 / 661 ms
Get Base[] 151 / 171 ms
Get Base[] 307 / 310 ms
Get Base[][] 152 / 177 ms
Get Base[][] 1072 / 1081 ms
Get Base[][] 214 / 240 ms
Get Base[] 454 / 463 ms
Running VariableStoreLocal...
Replace Into Base 32 / 31 ms
Replace Into Base[] 39 / 34 ms
Replace Into Base[] 180 / 174 ms
Replace Into Base[] 44 / 41 ms
Replace Into Base[] 93 / 78 ms
Replace Into Base[][] 48 / 42 ms
Replace Into Base[][] 304 / 285 ms
Replace Into Base[][] 61 / 54 ms
Replace Into Base[] 120 / 121 ms

So, certainly for variable access and repeat loop overhead, the 
differences are within the margin of error for such measurements - which 
would probably go away if I ran them on a completely empty machine and 
with increased number of iterations. The story is the exactly the same 
for the 'strings' benchmarks we have there too.


Most of Apple's apps are 64-bit only and have been for quite some time 
as there is no value in them shipping universal versions on any OS since 
10.6 (the only reason they would have done in previous versions is for 
apps which they had not yet ported to Cocoa and away from QuickTime) - 
all that does is waste download bandwidth and disk space.


Also, on the whole, Intel 64-bit machine code is can be much more 
efficient than 32-bit. The 64-bit Intel architecture actually has a 
measurable number of registers! 32-bit Intel processors have a huge 
amount of logic inside them to alias memory locations and such 
(essentially meaning memory accesses under specific conditions are akin 
to accessing registers). Of course all that costs silicon which could be 
used for better things - like caching and multiple cores. Basically, the 
64-bit Intel architecture is superior to the 32-bit one which does show 
its age quite a bit.


FWIW, when we got LiveCode on 64-bit Linux, Fraser did some performance 
tests which indicated on the whole, it ran about 5-10% faster than its 
32-bit counterpart. This was, admittedly, mainly in the area of graphics 
- since the types of things you do to rasterize graphics at this level 
benefits disproportionately from the number of registers available.


The thing is that most users won't ever notice whether an app is 32-bit 
or 64-bit because Apple's approach (universal binaries) means that it 
isn't possible to tell unless you go digging in Activity Monitor. (One 
would expect for this to be the case - Apple have done the processor 
architecture switch thing 3 times now - and in those cases it was to 
completely different architectures).


The main reason to not bother with 32-bit builds when there is no reason 
to is that it makes you much more efficient from the engineering point 
of view. It removes any question (when writing code) as to whether "is 
this correct for 32 and 64-bit" (admittedly, you try and structure your 
source base so only specific areas suffer from this overhead - but it 
still is there in the back of your mind). It means you only have to 
compile your source-base once (you don't magically get 64-bit code when 
compiling, you compile once for 32-bit and once for 64-bit). It 
eliminates one split in the test matrix. It halves the size of all your 
code deliverables - which is good for disk space and bandwidth (which, 
whilst less of an issue as time goes on - people do still tend to notice 
the difference between 500Mb download a 1Gb download!).


So, the reason Apple are doing it will undoubtedly be because of 
efficiency. It means they can focus all their energies on 64-bit Intel 
architecture (for Mac), and put all there resources into building and 
testing the 64-bit version of Mac.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.live

Re: AW: 64 bit desktop apps

[Mark Waddingham via use-livecode]

On 2017-06-08 08:48, Tiemo Hollmann TB via use-livecode wrote:
I would love to build 64-bit for Mac, but up to now, the Valentina 
extension

is still 32-bit, I hope they'll get it fixed by time.


I must confess that we always had the intent of dropping the 32-bit 
slice of the engine on Mac from 9 onwards. However, the case of people 
having to rely on 32-bit only externals potentially puts a spanner in 
that - so we might have to hold over to 'the next major version'.


The reason this would be good to do is that:

  1) Beyond the (legacy) 32-bit externals problem there is no advantage 
to the 32-bit slice


  2) It means our Mac builds will halve in time (which is important for 
CI, in particular) as it only has to compile once (and not twice) per 
build


  3) It is one less 'thing to think about' when doing Mac engine work.

  4) It makes LiveCode and the apps it builds more compact.

At the very least, we'll certainly be switching the IDE to 64-bit (by 
default) and make the SB build 64-bit only (by default) in 9+.


I'll see if we can get in contact with Valentina and find out what would 
be needed to do a 64-bit version.


As a general request, can people let us know if they are relying on 
externals on Mac which are currently 32-bit only?


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: LC 8.1.4 and Xcode 8.3.3

[panagiotis merakos via use-livecode]

Hi Henry,

It seems that Xcode 8.3.3. was released yesterday, too. I will have a look
at this issue. My guess is that in Xcode 8.3.3., Apple has (again!) changed
some internal frameworks we use for deploying to simulator, so we need to
tweak our code to workaround this.

So yes, I suggest sticking to Xcode 8.3.2 for now, which is the latest
tested Xcode that works with LiveCode 8.1.4.

Best,
Panos
--

On Thu, Jun 8, 2017 at 6:56 AM, hlowe via use-livecode <
use-livecode@lists.runrev.com> wrote:

> The release docs for LC 8.1.4 state:
>
>  "Last but not least, LiveCode 8.1.4 includes support for building iOS apps
> using the latest iOS SDKs, included in Xcode 8.3.x."
>
> Installed LC Indy 8.1.4 on a Mac under MacOS 10.12.5, installed the new
> version of Xcode (8.3.3) and I get this error message when attempting to
> run
> an LC iOS app in the simulator:
>
> "Unable to start simulator: 634,0,0,iPhone Simulator version not found
> 573,220,1,reviPhoneSetSimulatorSDK"
>
> Going to Preferences>Mobile Support and pointing at the newly installed
> Xcode did not help. Reinstalled xCode 8.3.2 and everything back to normal.
>
> Henry
>
>
>
> --
> View this message in context: http://runtime-revolution.
> 278305.n4.nabble.com/LC-8-1-4-and-Xcode-8-3-3-tp4715579.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
>



-- 
Panagiotis Merakos 
LiveCode Software Developer

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