LiveCode 7.0.3: a new meme

dunbarx at dunbarx at
Thu Feb 26 15:55:41 EST 2015


Do you think it a good idea to open a new category in the forum, perhaps in the "Talking LiveCode" area? It would allow issues to aired, and to be vetted before they are submitted as bugs. I suspect many of the new aspects of v.7 will just take getting used to, and should not be taken as problems.


-----Original Message-----
From: Richard Gaskin <ambassador at>
To: How to use LiveCode <use-livecode at>
Sent: Thu, Feb 26, 2015 3:46 pm
Subject: LiveCode 7.0.3: a new meme

The road to enhanced support for Cocoa, Unicode, GTK, iOS, and all the 
other things that make up v7 has been a long one, and while it's not 
been without difficulty this third point release seems very promising.

But don't take my word for it.  I'm just a fanboy - you can safely 
ignore anything I write. :)

Instead, enjoy this post I came across in the forums today for a fresh 
take on v7 - excerpt:

     So I got to try out LiveCode 7.0.3 today and I have to say I
     am impressed, the engine is the fastest I've used since the
     open source revamp began

His post is well worth reading, and in my thank you reply I also 
included some details about that performance boost in 7.0.3 and an 
earlier change with copy-on-write-only which may be of interest to those 
who've seen performance issues in the past.

Looking ahead:

Right now RunRev maintains three versions, 6.x, 7.x, and 8.x.  This is 
of course more expensive than maintaining two, so it's in everyone's 
interest to see a productive migration to v7 ASAP so we can have the 
team focusing on the things we truly need rather than just patching the 

"Version 6, we loved ya', but we gotta move on to the present."

But of course this needs to be truly productive, and that's where you 
come in.

In the past we've discussed isolated benchmarks, but as Peter Brett 
explained here a few weeks ago, and Ben explained to me in more detail 
in our last meeting, the changes in v7's core are so deep and pervasive 
that isolated benchmarks are far less useful than we might think.

In some areas, given the larger amount of data and automatic encoding 
detection for Unicode, we know some aspects of v7 will be slower.

But in many other areas, with copy-on-write-only and other algorithmic 
changes under the hood, many other areas have become much faster.

So the real focus now is two-fold:

#1 Priority: Bugs
If you're seeing a bug in v7.0.3 that you do not see in v6.7.3, please 
report it ASAP.

Of course data-loss bugs will get priority, and bugs for which simple 
workarounds exist may get a lower priority.  But let's do make sure we 
catalog any issues unique to v7 so we can all move forward with confidence.

#2 Priority: Performance
Given the holistic nature of the changes in v7, the key here is to find 
applications that are noticeably slower.  If you have one, send it to 
support AT with a note explaining where the performance 
difference can be found.

No need to worry about trade secrets and all that:  RunRev regularly 
works with very sensitive projects, and discards everything noted as 
such as soon as their analysis is complete.

The main thing is that they see it, so if you see a noticeable 
performance loss and are concerned about sensitivity of the materials, 
please at least write to them describing the issue and your concerns and 
let's find a way to take care of it.

I write this as an ardent fan of v6.7.x.  It's been good to me, and it's 
enjoyed a favored position in my Mac's Dock and my Ubuntu Launcher.

But as of today I'm migrating all new work to v7. I want 2D physics, GPU 
rendering, stack views, and more, and those only take longer as long as 
the core team is saddled with v6.x backports.

And for us Linux fanboys, much the enhanced GTK support we crave is 
already in v7 (thanks, Fraser!).

If you have any other concerns about migrating your work to v7, let me 
know.  Probably best to discuss them here so we can all benefit, but if 
it's a sensitive issue you can send me an email if you prefer and I'll 
do my best to reply quickly.

  Richard Gaskin
  LiveCode Community Manager
  richard at

use-livecode mailing list
use-livecode at
Please visit this url to subscribe, unsubscribe and manage your subscription 


More information about the use-livecode mailing list