LiveCode 7.0.3: a new meme

Thu Feb 26 17:41:41 EST 2015

I must say that I agree with Eric on this one.   I never use Unicode and 
the size and performance penalties do not seem like a reasonable 
tradeoff.   I do understand your point about having to maintain multiple 
versions.  I would suggest that solving selectively removing the unicode 
dictionary is the highest priority (if that is in fact the cause of the 
bloat.).   If the size is perceived to be too big for use, then the 
issues of bugs and performance are indeed secondary.

I am a huge fan of livecode and I am anxiously awaiting widgets but I 
fear that is also going to have a significant impact on the size.

-= Mike

On 2/26/15 4:41 PM, Eric Corbett wrote:
> Richard,
>
> I’m wondering if the standalone engine size is a concern for anyone else. I have a standalone for iOS that is 3 times smaller when built with 6 over 7. I think I understand that the unicode dictionary is responsible, but until there is a way to selectively remove that, I would rather have the smaller footprint.
>
> Eric
>
> On Feb 26, 2015, at 12:45 PM, Richard Gaskin <ambassador at fourthworld.com> wrote:
>
>> 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
>> <http://forums.livecode.com/viewtopic.php?f=66&t=23387>
>>
>> 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 past.
>>
>> "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 runrev.com 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 livecode.org
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>