Re: 64 bit desktop apps

2017-06-09 Thread Dr. Hawkins via use-livecode
On Fri, Jun 9, 2017 at 11:38 AM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> You can now hear Clarus moofing for yourself:
> http://clarus.chez-alice.fr/
>

Or I could pop in one of my old developer CDs.

I bought my first CD drive when apple started shipping on them instead of
floppies.  $700, less 50% for being a developer, iirc.

And I think it was more like half-speed than single-speed.

I don't recall if it was on the floppies, but I'm pretty sure I gave up or
reuused those decades ago . . .

Back then, it was $600 year to be a developer, but they probably paid close
to that in printing, pressing, and shipping.

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

2017-06-09 Thread Mark Wieder via use-livecode

On 06/08/2017 07:53 AM, Dr. Hawkins via use-livecode wrote:


moof!

(dating myself . . .)




You can now hear Clarus moofing for yourself:
http://clarus.chez-alice.fr/

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

2017-06-09 Thread Richard Gaskin via use-livecode

Mark Waddingham wrote:

Richard's repeated suggestion that such machines should be 'Linux-ised' 
still always was and continues to be an excellent suggestion. Remember 
that as as time goes by the amount of up to date software which *can* 
run on them will dwindle to nothing - for the same reason as we have had 
to look long and hard at our platform support and make changes.


There's another aspect of this worth considering as well:

One of the things Richmond noted, which we've all experienced, is that 
as GUI apps and OSes evolve their hardware requirement grow along with 
them.  Over enough time, GUIs can become sluggish.


These days much of the computing we use is done on servers, machines 
that have no GUI constraints since they need no GUI at all.


I've been meeting a lot of educators here in CA who've had great success 
teaching server admin and even security skills to learners at the high 
school level, and sometimes even in middle school.


Given that the role of servers is expected to only increase, and that 
networking in general is now a ubiquitous part of most app development, 
teaching these sorts of skills will only become ever more important 
going forward.


Right now Linux sys admin positions are plentiful and pay well.

And those with security certifications can earn six figures by their 
second year out of school.  Right now there are some 300,000 infosec 
jobs for US SMBs alone that can't be filled because of a shortage of 
qualified candidates.  We need more white hats in the field.


One of my friends organized a "capture the flag" competition at the 
SoCal Linux Expo, and we see similar infosec exercises becoming popular 
in a wide range of EDU contexts.


Best of all, these don't require great hardware.  Unencumbered by GUI 
requirements, servers really don't need much CPU power at all, and can 
operate with a fraction of the RAM modern GUIs need.


For older machines, server applications can make an ideal role for 
extending the useful life of older machines.


The cloud will only become an ever more pervasive part of our computing 
world, and nearly all of the best software needed to learn and create 
cloud systems is entirely free and open.


Server admin may not be for all learners, but for the "Computer Club" 
types it's a natural extension to also learning client-side development.


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

2017-06-09 Thread Bob Sneidar via use-livecode
Even California does not require you to support something beyond 10 years. 

Bob S


> On Jun 9, 2017, at 07:50 , Mark Waddingham via use-livecode 
>  wrote:
> 
> I'd also point out (again) that we are talking about machines which are now > 
> 10 years old (the last Mac which can only run up to 10.7 was released in 
> 2007).


___
use-livecode mailing list
use-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

2017-06-09 Thread Mark Waddingham via use-livecode

On 2017-06-08 21:16, Richmond Mathewson via use-livecode wrote:

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


Strictly speaking your question was (essentially) "So you don't believe 
in backwards compatibility then?" and then segued into a repeat about 
your usage of PowerPC based Macs... May I suggest you make your 
questions a little clearer (and perhaps less perjorative ;)) then you 
might actually get answers to what you actually meant to ask, instead of 
what it sounded like you asked.


In terms of upping the minimum version requirement for 9.0 to 10.9 then 
using this as reference:


   
http://www.everymac.com/systems/by_capability/maximum-macos-supported.html


Intel Macs fall into four categories:

   - Those which can only run up to 10.6

   - Those which can only run up to 10.7

   - Those which can only run up to 10.11

   - Those which can run current Mac versions

Continuing to support 10.6 and 10.7 is *extremely* difficult due to both 
Cocoa APIs and C++ support. Indeed, continuing to do so would mean two 
things:


  1) Leveraging new APIs on the Mac platform would be much harder, 
meaning that will happen even slower than it has done up until now.


  2) We can't use newer versions of the C++ standard which not only 
makes writing code for the engine harder, but also means that the 
chances of bugs and vulnerabilities increase (because new methods of 
writing C++ which are available in C++11 allow you to do so in much 
'safer' ways). Basically more regressions, more bugs, slower evolution.


I'd also point out (again) that we are talking about machines which are 
now > 10 years old (the last Mac which can only run up to 10.7 was 
released in 2007).


Furthermore, as people have reiterated several times, those OSes are not 
supported by Apple and are hugely insecure in the modern climate. Whilst 
I get what you are saying about 'reusing old hardware' it does seems a 
bit 'off' for 'us' to be palming off old machines onto 'developing' 
countries which we wouldn't use ourselves for those very reasons.


Richard's repeated suggestion that such machines should be 'Linux-ised' 
still always was and continues to be an excellent suggestion. Remember 
that as as time goes by the amount of up to date software which *can* 
run on them will dwindle to nothing - for the same reason as we have had 
to look long and hard at our platform support and make changes.


All Macs which can run 10.8 can also run 10.9 - which is the new minimum 
version for 9. So, yes, there is a set of Intel Macs released between 
2005 and 2007 which will not be able to run 9; but the number of Macs 
which fall outside of this group is many many times larger and will, of 
course, continue to grow year on year.


Warmest Regards,

Mark.

P.S. Please remember that LiveCode is open-source - 95% of changes we 
make to LiveCode as a whole go into the open-source repository. People 
are more than free to fork it and produce a 'legacy version' if they 
wish. A bit like a third-party group has done for FireFox.


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

2017-06-09 Thread Richard Gaskin via use-livecode

Richmond Mathewson wrote:

> I don't see the problem as relating to machines that LiveCode might be
> deployed on, but as machines for which 32-bit
> standalones might be authored.

In my reading of Mark's comment, it doesn't seem that's going away, 
merely tha 64-bit-only builds will become the default:


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


@Mark Waddingham:  If I misunderstand please correct me.

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

2017-06-09 Thread Richmond Mathewson via use-livecode
I don't see the problem as relating to machines that LiveCode might be 
deployed on, but as machines for which 32-bit

standalones might be authored.

My highly theoretical scenario runs a bit likes this;

A number of schools in what are coyly called "third world countries" 
running old machines for content delivery; either in

schools or in, say, government offices.

An author of software for this scenario might have a 64-bit machine, but 
would need the ability to export for the target market.


As there are very many fully-functional 32-bit machines (whether Macs or 
IBM-compats) "out there" (and by "out there"
I mean outwith the slightly smug, self-satisfied circle of charmed 
countries quite incorrectly termed "Western" - Australia, western? -)
that are being put to good purpose rather than clogging up landfills and 
shafting the planet, this scenario does not seem

totally daft to me.

Admittedly, authors could use earlier versions of LiveCode that do 
produce 32-bit standalones to deliver the goods
(I still use 4.5 for stuff I run on a couple of PPC Macs), but, 
obviously, this cuts them off from new capabilities that will be built 
into newer

versions.

Richmond.

On 6/8/17 11:07 pm, Bob Sneidar via use-livecode wrote:

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


___
use-livecode mailing list
use-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

2017-06-08 Thread 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: 64 bit desktop apps

2017-06-08 Thread 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

2017-06-08 Thread 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: 64 bit desktop apps

2017-06-08 Thread 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

2017-06-08 Thread 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: 64 bit desktop apps

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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) 

Re: AW: 64 bit desktop apps

2017-06-08 Thread 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: AW: 64 bit desktop apps

2017-06-08 Thread 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: 64 bit desktop apps

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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 

Re: 64 bit desktop apps

2017-06-08 Thread 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

2017-06-08 Thread 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

2017-06-08 Thread 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 ~ 

Re: AW: 64 bit desktop apps

2017-06-08 Thread 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


AW: 64 bit desktop apps

2017-06-08 Thread Tiemo Hollmann TB via use-livecode
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.
Tiemo


-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von Mark Waddingham via use-livecode
Gesendet: Donnerstag, 8. Juni 2017 08:19
An: How to use LiveCode <use-livecode@lists.runrev.com>
Cc: Mark Waddingham <m...@livecode.com>
Betreff: Re: 64 bit desktop apps

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.

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

2017-06-08 Thread Mark Waddingham via use-livecode

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.

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

2017-06-07 Thread Dr. Hawkins via use-livecode
On Wed, Jun 7, 2017 at 8:44 AM, Colin Holgate via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I’m running High Sierra, the one before the 32 bit ban I guess, and it
> can still run LiveCode 5 ok.
>

I'm *supposed* to be offered beta apple software on this machine, but it
denies that any is available . . .

Hmm, seems that my membership is expired, and it wants annual payments
again???

Huh?


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

2017-06-07 Thread Jerry Jensen via use-livecode
Is this for sure and official? I am working on an LC front end for a legacy 
system that sits upon an old XCode port of a database system called DB Vista 
(written in old testament C as for unix). It is definitely NOT 64 bit. I 
mentioned this to my colleague, who did the port and the first layer on top of 
it. His response was “I am hiding under the blakets with my fingers in my ears”.
.Jerry

> On Jun 7, 2017, at 8:05 AM, Charles Szasz via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> Apple announced that the next MacOS operation system after High Sierra will 
> only support 64 bit desktop apps. What version of LC supports creating 64 bit 
> 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

2017-06-07 Thread hh via use-livecode
64bit mode usually makes apps slower. So what's Apple's intention?
To make their own apps "relatively faster" by making all others slower?

___
use-livecode mailing list
use-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

2017-06-07 Thread Richmond Mathewson via use-livecode
I disagree as there are plenty of Macs "out there" in the worldthat run 
32-bit systems.


Far better to have BOTH possibilities checked as default.

Richmond.

On 6/7/17 10:14 pm, J. Landman Gay via use-livecode wrote:

On 6/7/17 10:41 AM, Mark Waddingham via use-livecode wrote:
The SB by default builds for 32-bit mode, but you can choose 64-bit 
by checking the appropriate box.


When Apple begins requiring 64-bit, it would be a good idea to make 
this the default in the SB.




___
use-livecode mailing list
use-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

2017-06-07 Thread Bob Sneidar via use-livecode
And BTW I can verify it works. It is no longer experimental. :-)

Bob S


> On Jun 7, 2017, at 11:41 , Richmond Mathewson via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> 8.1.3 does.
> 
> Richmond.
> 
> On 6/7/17 6:05 pm, Charles Szasz via use-livecode wrote:
>> Apple announced that the next MacOS operation system after High Sierra will 
>> only support 64 bit desktop apps. What version of LC supports creating 64 
>> bit apps?
>> 
>> 
>> Sent from my iPad
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-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

2017-06-07 Thread J. Landman Gay via use-livecode

On 6/7/17 10:41 AM, Mark Waddingham via use-livecode wrote:
The SB by default builds for 32-bit mode, but you can choose 64-bit by 
checking the appropriate box.


When Apple begins requiring 64-bit, it would be a good idea to make this 
the default in the SB.


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

2017-06-07 Thread Richmond Mathewson via use-livecode

8.1.3 does.

Richmond.

On 6/7/17 6:05 pm, Charles Szasz via use-livecode wrote:

Apple announced that the next MacOS operation system after High Sierra will 
only support 64 bit desktop apps. What version of LC supports creating 64 bit 
apps?


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


___
use-livecode mailing list
use-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

2017-06-07 Thread Colin Holgate via use-livecode
I’m running High Sierra, the one before the 32 bit ban I guess, and it can 
still run LiveCode 5 ok.



> On Jun 7, 2017, at 4:41 PM, Mark Waddingham via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> On 2017-06-07 17:05, Charles Szasz via use-livecode wrote:
>> Apple announced that the next MacOS operation system after High Sierra
>> will only support 64 bit desktop apps. What version of LC supports
>> creating 64 bit apps?
> 
> LiveCode 8.x onwards.
> 
> Currently the IDE runs in 32-bit mode by default (you can change this by 
> using 'Get Info' on the LiveCode app bundle, and unchecking the box).
> 
> The SB by default builds for 32-bit mode, but you can choose 64-bit by 
> checking the appropriate box.
> 
> 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

2017-06-07 Thread Mark Waddingham via use-livecode

On 2017-06-07 17:05, Charles Szasz via use-livecode wrote:

Apple announced that the next MacOS operation system after High Sierra
will only support 64 bit desktop apps. What version of LC supports
creating 64 bit apps?


LiveCode 8.x onwards.

Currently the IDE runs in 32-bit mode by default (you can change this by 
using 'Get Info' on the LiveCode app bundle, and unchecking the box).


The SB by default builds for 32-bit mode, but you can choose 64-bit by 
checking the appropriate box.


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


64 bit desktop apps

2017-06-07 Thread Charles Szasz via use-livecode
Apple announced that the next MacOS operation system after High Sierra will 
only support 64 bit desktop apps. What version of LC supports creating 64 bit 
apps?


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