LiveCode 7.0.3: a new meme

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

LiveCode 7.0.3: a new meme

Richard Gaskin
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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

dunbarxx
Richard.


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.


Craig



-----Original Message-----
From: Richard Gaskin <[hidden email]>
To: How to use LiveCode <[hidden email]>
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
<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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

 
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Eric Corbett
In reply to this post by Richard Gaskin
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 <[hidden email]> 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
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Michael Doub
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 <[hidden email]> 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
>> [hidden email]
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Richard Gaskin
In reply to this post by dunbarxx
dunbarx wrote:
 > 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.

Very good idea.  I'll set that up this weekend.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Richard Gaskin
In reply to this post by Michael Doub
Michael Doub wrote:

 > 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 also have a strong emotional attachment to having used an engine that
provided so much for so little disk space.

But it really was very small, arguably more so than it's now big.

One of the smallest apps on my Mac right now is Apple's calculator,
weighing in a 9.5 MBs, or their Font Book at 16.4 MBs, compared to the
LiveCode 7.0.3 runtime engine that does so much more in just 12.9 MBs.

I've discussed with Ben the possibility of factoring Unicode out as a
separate component, and while there may be ways to do that for some
things it seems unlikely for Unicode.  Unicode is strings, so anything
that uses strings, from scripts to fields to all object names - it's all
seamlessly Unicode now.  Too deep for too little ROI.

If you any of you find yourself getting bad reviews or streams of
disappointed emails from customers about your app's size, let's collect
those comments and revisit the issue with RunRev to look for other ways
engine size may be reduced.

But as it is, when we look at the other apps on our hard drives, while
LC 7 looks bigger when comparing it to older LC versions, it doesn't
look so big comparing it to other shipping apps.

Sure, there are some.  Maybe even many.  But then there are many more
that are much, much bigger that few complain about:

iCal: 56.8 MBs
Stuffit Expander: 54.9 MBs
Firefox: 167.3 MBs
iMovie: 236.7 MBs
GarageBand: 300.2 MBs
iPhoto: 387.9 MBs
LibreOffice: 597.2 MBs

With LiveCode, stack files are relatively small.  So when we bind those
to the runtime engine, the size doesn't get that much larger than the
bare engine itself.

With lots of media that can grow, but that's not a function of the dev
tool at all, as lots of media will take more space in any app.

Starting with 12.9 MBs for a simple app may seem like a lot (esp. if you
don't notice the size of other apps on your HDD), but then you can
multiply your app's features while growing your app's files size only a
little bit.

I'd like to be able to go back to delivering uncommonly tiny apps, but
as a developer I notice these things, while apparently few end-users do.

So let's see how things go.  Deploy great products, and if the worst
thing anyone says about your app is that it's 20 MBs you're off to a
good start, and we can work with the team to see what might be factorable.

--
  Richard Gaskin
  LiveCode Community Manager
  [hidden email]



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Dave Kilroy
In reply to this post by Richard Gaskin
Hi Richard

There are various bugs in 6.7 and 7 that concern me (all of which I can deal with through various kludges) - what I apparently don't have any control over and which is much more serious is the long amount of time it takes apps built with 6.7 or 7 to launch on iOS

Please see http://quality.runrev.com/show_bug.cgi?id=14116 for details - as I say in one of my comments - for me (and I should think all developers building for iOS) - this is high priority.

<start of rant>

In my test 'hello world' stack I recorded 6.7 and 7 being FOUR TIMES slower to launch than the same app built with 6.6.5 - and in one of my current prototypes I recorded a pause which was SEVEN TIMES SLOWER resulting in a pause of FIFTEEN SECONDS before the splash screen was exited.

If this issue can't be fixed soon can we at least have some discussion about how best to mitigate it? The current attitude seems to be something like "yes it's unfortunate but you'll just have to wait <until some unspecified time in the future>"

Thank you for listening

<end of rant>

Kind regards

Dave

Richard Gaskin wrote
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.
"The first 90% of the task takes 90% of the time, and the last 10% takes the other 90% of the time."
Peter M. Brigham
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Dave Kilroy
Quick follow-up - my same prototype app that takes FIFTEEN SECONDS to launch on iOS opens instantly on Android lollipop (or at least so quick I perceive it as instantly)

Kind regards

Dave


Dave Kilroy wrote
Hi Richard

There are various bugs in 6.7 and 7 that concern me (all of which I can deal with through various kludges) - what I apparently don't have any control over and which is much more serious is the long amount of time it takes apps built with 6.7 or 7 to launch on iOS

Please see http://quality.runrev.com/show_bug.cgi?id=14116 for details - as I say in one of my comments - for me (and I should think all developers building for iOS) - this is high priority.

<start of rant>

In my test 'hello world' stack I recorded 6.7 and 7 being FOUR TIMES slower to launch than the same app built with 6.6.5 - and in one of my current prototypes I recorded a pause which was SEVEN TIMES SLOWER resulting in a pause of FIFTEEN SECONDS before the splash screen was exited.

If this issue can't be fixed soon can we at least have some discussion about how best to mitigate it? The current attitude seems to be something like "yes it's unfortunate but you'll just have to wait <until some unspecified time in the future>"

Thank you for listening

<end of rant>

Kind regards

Dave

Richard Gaskin wrote
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.
"The first 90% of the task takes 90% of the time, and the last 10% takes the other 90% of the time."
Peter M. Brigham
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Paul_Hibbert
In reply to this post by Richard Gaskin
Richard,

I'm still seeing a huge slowdown with some parts of the IDE in LC7.0.3 on Mac OS X 10.10.2, for example if I click any title in the main menubar such as 'File' or 'Edit' in 6.x.x the menu appears instantly, but if I click any title in the menuBar of LC7.0.x it takes at least 3 seconds before the menu is displayed. Typing in some LC palette fields can be painfully slow too, sometimes each char takes a couple of seconds to appear. It can get very frustrating.

I've tried, but I can't figure out a way to measure this delay, other than maybe recording my screen, but if there is a way to demonstrate this I'll happily submit a bug report. I'm a big fan of LC too and I like to see it get stronger with each update.

I've just built an iOS app and it's more than twice the size of the LC6.x.x version, increasing from 9.4MB up to 21.7MB, although it doesn't seem to have any apparent effect on the load speed or use of the app on my iPhone 5s. I'll try a few more apps over the next few days.

Paul


> On Feb 26, 2015, at 12:45 PM, Richard Gaskin <[hidden email]> wrote:
>
> 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,


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Kay C Lan
In reply to this post by Richard Gaskin
On Fri, Feb 27, 2015 at 8:35 AM, Richard Gaskin <[hidden email]>
wrote:

>
> But it really was very small, arguably more so than it's now big.
>
> One of the smallest apps on my Mac right now is Apple's calculator,
> weighing in a 9.5 MBs, ... compared to the LiveCode 7.0.3 runtime engine
> that does so much more in just 12.9 MBs.
>
> That's not quite comparing apples with Apples. The original question was
re iOS. On iOS my Scientific Calculator is 241 KB in size. I have at least
a dozen iOS apps which are less than 1 MB and plenty which are single digit
MB. The smallest simplest LC 7.x iOS app I've made seems to come in at
about 22MB.

Now I tend to agree that these are all very small numbers and could be
considered insignificant if performance were not an issue BUT correctly or
incorrectly people naturally associate bloated size, with bloated code,
with bloated start up and execution times.

Once people know how fast it can run, it's hard for them to accept slower
performance. When LC 7.x is as fast as or faster than LC 6.x in identical
tests (i.e. a large non-unicode data parse) all thoughts of size will
magically disappear.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Terence Heaford-2
In reply to this post by Richard Gaskin

> On 26 Feb 2015, at 20:45, Richard Gaskin <[hidden email]> wrote:
>
> #2 Priority: Performance
> ———————————

I am only a mere Community user who recently started using LC (perhaps 12 months or so) and have no axe to grind and do not carry any baggage regarding LC so I hope my comments are taken on face value.

My Bank does not maintain financial records for very long so I thought I would try to develop an application in LC that can use and store the data downloaded on a monthly basis in OFX format. I thought this would be a good evaluation of LC.

Importing OFX proved no problem.

Storing the data in an SQLite database was no problem.

Displaying the data in charts (pie, bar and line) has proved good.

Printing the charts has been straightforward.

Printing out reports has been straightforward.

I am sure all the above could have been scripted better but have been successful.

—————

Now to the one area where I have been less than happy.

I have posted before about the performance of DataGrids and the performance is still lagging in comparison to other development environments.

Visually this is one area where you can tell your solution is scripted rather than compiled.

I am currently using 6.7.3 rather than 7.0.3 because the scrolling of the DataGrid is better in 6.7.3 when compared to 7.0.3..
6.7.3 is not good but is better that 7.0.3 in my estimation by about 10-15%.

I started with a DataGrid that loaded all the data in one hit but as the number of records rose to >2000 I changed to the large data format for the data grid.

The DataGrid consists of 6 columns:

Date, Type, Description, Amount, Balance, Category.

Dates are stored as seconds in the database.

I know the DataGrid is a scripted solution and in it’s day was a solution that other scripting apps did not have but today with LC being touted as THE solution I have to say the DataGrid has seen it’s day.

I suppose LC’s engineers have 2 or perhaps 3 or even 4 options to solve this issue, they should certainly not defend it, rather accept it’s limitations and try to solve them. The solutions I see are:

1. Adjust the code in LC 7 to speed up scrolling.

2. Make the DataGrid part of the engine.

3. Incorporate a native solution (NSTableView, Mac).

4. Ignore the situation until LC 8 and leave it to developers to design their own widget.

Number 4 is a concern. With widgets, is it LC’s intention to allow these to be designed and sold by other developers? If this is the case then the extreme turn of events maybe that LC do nothing for UI but leave it to widget developers and this increases the potential cost for developers.



I hope my comments are taken as an effort to proactively comment of how I see LC for me, as a newish user.


All the best

Terry

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

J. Landman Gay
On February 27, 2015 2:26:17 AM CST, Terence Heaford <[hidden email]> wrote:
>
>The DataGrid consists of 6 columns:
>
>Date, Type, Description, Amount, Balance, Category.

From the description, it sounds like you could use a regular field with tab delimited data, which would give much better scrolling speed. The datagrid is great for form-based grids but if each row can be a single line you can do it with a LiveCode field.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Peter Haworth
Especially since we now have right justified tabs

On Fri, Feb 27, 2015, 8:09 AM J. Landman Gay <[hidden email]>
wrote:

> On February 27, 2015 2:26:17 AM CST, Terence Heaford <[hidden email]>
> wrote:
> >
> >The DataGrid consists of 6 columns:
> >
> >Date, Type, Description, Amount, Balance, Category.
>
> From the description, it sounds like you could use a regular field with
> tab delimited data, which would give much better scrolling speed. The
> datagrid is great for form-based grids but if each row can be a single line
> you can do it with a LiveCode field.
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Klaus major-k
Hi Pete,

> Am 27.02.2015 um 17:11 schrieb Peter Haworth <[hidden email]>:
>
> Especially since we now have right justified tabs

ah, yes, true, but I cannont find it in the dictionary!?
Any hints what term to look for, there is no hint in "tabstops".

Thanks!

> On Fri, Feb 27, 2015, 8:09 AM J. Landman Gay <[hidden email]>
> wrote:
>
>> On February 27, 2015 2:26:17 AM CST, Terence Heaford <[hidden email]>
>> wrote:
>>>
>>> The DataGrid consists of 6 columns:
>>>
>>> Date, Type, Description, Amount, Balance, Category.
>>
>> From the description, it sounds like you could use a regular field with
>> tab delimited data, which would give much better scrolling speed. The
>> datagrid is great for form-based grids but if each row can be a single line
>> you can do it with a LiveCode field.
>>
>> --
>> Jacqueline Landman Gay         |     [hidden email]
>> HyperActive Software           |     http://www.hyperactivesw.com

Best

Klaus
>

--
Klaus Major
http://www.major-k.de
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

BNig
Hi Klaus,

it works beautifully and is called:

from the dictionary 7.x.x

tabAlign

Type: property

Syntax:
set the tabAlign [of line lineNumber] of field to tabAlignList

Kind regards
Bernd
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Peter Haworth
I'll put in a plug in for Bernd's modTablefield, great flexibility, easy to
use.

On Fri, Feb 27, 2015, 8:29 AM BNig <[hidden email]> wrote:

> Hi Klaus,
>
> it works beautifully and is called:
>
> from the dictionary 7.x.x
>
> tabAlign
>
> Type: property
>
> Syntax:
> set the tabAlign [of line lineNumber] of field to tabAlignList
>
> Kind regards
> Bernd
>
>
>
> --
> View this message in context: http://runtime-revolution.
> 278305.n4.nabble.com/LiveCode-7-0-3-a-new-meme-tp4689374p4689443.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Klaus major-k
In reply to this post by BNig

> Am 27.02.2015 um 17:21 schrieb BNig <[hidden email]>:
>
> Hi Klaus,
>
> it works beautifully and is called:
> from the dictionary 7.x.x
> tabAlign

ah, OK, thanks, looks like this is missing in the 6.7.3 dictionary!? :-(
Is it also missing in that engine?

> Kind regards
> Bernd

Best

Klaus

--
Klaus Major
http://www.major-k.de
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Fraser Gordon-3

On 27 Feb 2015, at 16:48, Klaus major-k <[hidden email]> wrote:

>
>> Am 27.02.2015 um 17:21 schrieb BNig <[hidden email]>:
>>
>> it works beautifully and is called:
>> from the dictionary 7.x.x
>> tabAlign
>
> ah, OK, thanks, looks like this is missing in the 6.7.3 dictionary!? :-(
> Is it also missing in that engine?

The feature was added in 7.0.0 - it came about as part of re-factoring the field control to support Unicode (which involved re-writing a substantial portion of it!). Right-aligned tabs were needed for right-to-left languages so enhancing it to allow the tabAlign property was a relatively small step from there.

Regards,
Fraser


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Klaus major-k
Hi Fraser,

> Am 27.02.2015 um 17:58 schrieb Fraser Gordon <[hidden email]>:
> On 27 Feb 2015, at 16:48, Klaus major-k <[hidden email]> wrote:
>>> Am 27.02.2015 um 17:21 schrieb BNig <[hidden email]>:
>>> it works beautifully and is called:
>>> from the dictionary 7.x.x
>>> tabAlign
>> ah, OK, thanks, looks like this is missing in the 6.7.3 dictionary!? :-(
>> Is it also missing in that engine?
> The feature was added in 7.0.0 - it came about as part of re-factoring the field control to support Unicode (which involved re-writing a substantial portion of it!). Right-aligned tabs were needed for right-to-left languages so enhancing it to allow the tabAlign property was a relatively small step from there.

AHA! :-)

Thanks for the info!

> Regards,
> Fraser

Best

Klaus

--
Klaus Major
http://www.major-k.de
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LiveCode 7.0.3: a new meme

Terence Heaford-2
In reply to this post by J. Landman Gay
Maybe for a simple put all the data in and scroll it but not for all the other things that a DataGrid can do.

My post was in response to Richard Gaskin’s request for information regarding areas of poor performance in LC.

I do have knowledge of using the regular field with tab delimited data but it does not give the breadth of opportunity provided by the DataGrid.

The real solution is to have the performance issues of the DataGrid addressed directly by LC engineers.

The limitation of the regular field route is probably why it was designed by Trevor Devore in the first place. I understand LC incorporated the DataGrid into their product.
This explains a lot. Trevor Devore probably designed and implemented the DataGrid to overcome the fact that there was no DataGrid within Revolution.
LC should have implemented there own DataGrid as part of the engine then there would be no speed problem now.
I can understand why they did not do this (I do have experience in Objective-C/Cocoa) as it is not a minor undertaking but if they had the benefits now would be enormous. Also LC voted not to use native controls but emulated so any table would have to be implemented from the ground up rather than using the native say Cocoa NSTableView.

For me, this is a major area of poor performance which needs to be addressed at the core level, by LC engineers, not by workarounds using mods to existing controls that have not really been designed for creating modern tables for a modern environment.


All the best

Terry


> On 27 Feb 2015, at 16:08, J. Landman Gay <[hidden email]> wrote:
>
> From the description, it sounds like you could use a regular field with tab delimited data, which would give much better scrolling speed. The datagrid is great for form-based grids but if each row can be a single line you can do it with a LiveCode field.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123