Re: Refactoring is your friend / moving from 6.x to 9.x

[Simon Knight via use-livecode]

> On 7 Jan 2019, at 17:00, Richard Gaskin via use-livecode 
>  wrote:
> 
> Perhaps the biggest flaw I've seen with v9 is the bug report tracking: the 
> Release Notes only include a subset of all issues addressed since work began 
> on it two years ago.  My understanding from conversations with team members 
> is that v9 may well have the largest number of resolved bugs of any release, 
> an amazing feat considering the scope of new features and feature 
> refinements, including huge strides forward with many aspects of performance.

I suspect that this is a fact of life especially in small teams.  My limited 
experience is that people who write code generally hate writing paperwork as 
they want to get on and complete the next task and not create documentation 
about the last.  Not forgetting that a lot of the paperwork generated by the 
big players is just shelf ware and no use to anyone except the manager who 
demanded it.

best wishes

Simon
___
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: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Simon Knight wrote:

> ...I do agree that the team does an extraordinary job of bug
> reduction while adding features and keeping on top of all the
> changes to the list of OS’s that livecode runs on.

LC v9 is particularly strong in this regard.

We have some in our community who've dreamed of a major release that 
focuses exclusively on handling legacy issues that have cropped up.  But 
there are also a great many customers who need new features.


LC v9 adds many features for each of the platforms, including one of my 
favorites, replacing the older sha1Digest with messageDigest for easier 
extensibility, and taking advantage of that extensibility right out of 
the starting gate with sha2 and sha3 hash options.  Now we can build 
password management systems as well as the best of them.


Another key item is the much smarter integration into host OS 
look-and-feel with fine-tuned control appearance, especially with regard 
to label baseline placement.  And with that came new textFont options 
allowing us a range of ways we can adopt system fonts across platforms 
and platform versions with a single property setting.


Perhaps the biggest flaw I've seen with v9 is the bug report tracking: 
the Release Notes only include a subset of all issues addressed since 
work began on it two years ago.  My understanding from conversations 
with team members is that v9 may well have the largest number of 
resolved bugs of any release, an amazing feat considering the scope of 
new features and feature refinements, including huge strides forward 
with many aspects of performance.


--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Simon Knight via use-livecode]

> On 7 Jan 2019, at 08:16, Kay C Lan via use-livecode 
>  wrote:
> 
> And a spookily well timed questions; it's as if the late great Bill
> Marriot hearkens from the grave.  Bill was responsible for the focus
> that took a very flakey Revolution, create the RQCC and develop what
> is clearly a much more effective process for reporting, processing,
> tracking and ultimately eliminating Bugs.  For those who were there
> before Bill can attest, the Team these days does an extraordinary job
> of Bug reduction.  Not perfect but a lot lot better than before the
> RQCC.

I don’t think that I am acting as a relay from the other side… 

but I do agree that the team does an extraordinary job of bug reduction while 
adding features and keeping on top of all the changes to the list of OS’s that 
livecode runs on.

Simon Knight

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Kay C Lan via use-livecode]

On Mon, Jan 7, 2019 at 4:26 AM Richard Gaskin via use-livecode
 wrote:
>
> Simon Knight wrote:
>  > One question why does this thread refer to RQCC ?
>
Richard Replied:
> Old habits.  The bug database used to be called the "Revolution Quality
> Control Center", and the acronym is forever stuck in my typing fingers.

And a spookily well timed questions; it's as if the late great Bill
Marriot hearkens from the grave.  Bill was responsible for the focus
that took a very flakey Revolution, create the RQCC and develop what
is clearly a much more effective process for reporting, processing,
tracking and ultimately eliminating Bugs.  For those who were there
before Bill can attest, the Team these days does an extraordinary job
of Bug reduction.  Not perfect but a lot lot better than before the
RQCC.

I think tomorrow marks the anniversary of Bill's passing. RIP, and thank you.

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Tom Glod via use-livecode]

Thanks for that confirmation Trevor great to hear that.

On Sun, Jan 6, 2019 at 9:45 PM Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Sun, Jan 6, 2019 at 4:56 PM Tom Glod via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> >
> > Seems like signing the exec is a good idea and certainly can't
> hurtand
> > if I have to write some emails to get whitelisted I can do that too.
>
>
> FWIW I always sign my Windows standalones and I haven’t had any reports of
> quarantine issues overs the years. I can’t say for sure that it isn’t
> happening, but my company’s software has had a fair number of Windows
> customers so I would think I would have had a few reports come through
> support it was an issue.
>
> --
> Trevor DeVore
> ScreenSteps
>
> >
> ___
> 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: Refactoring is your friend / moving from 6.x to 9.x

[Trevor DeVore via use-livecode]

On Sun, Jan 6, 2019 at 4:56 PM Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Seems like signing the exec is a good idea and certainly can't hurtand
> if I have to write some emails to get whitelisted I can do that too.


FWIW I always sign my Windows standalones and I haven’t had any reports of
quarantine issues overs the years. I can’t say for sure that it isn’t
happening, but my company’s software has had a fair number of Windows
customers so I would think I would have had a few reports come through
support it was an issue.

-- 
Trevor DeVore
ScreenSteps

>
___
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: Refactoring is your friend / moving from 6.x to 9.x

[Tom Glod via use-livecode]

Thanks, everyone for chiming in here, I want to help narrow down the
circumstances in which windows defender affects the ide but more
importantly standalones.

Richard, I demoed my stack on my mother in laws laptop and her AV (one
I was not familiar with) put my executable into quarantine right away
before I even ran it.  I did not have time to inspect details of the report
since Kevin and Chris were on their way.  So that's all I remember and
want to avoid this like heck going forward. I believe it also quarantined
the dlls in the standalone directory.

Seems like signing the exec is a good idea and certainly can't hurtand
if I have to write some emails to get whitelisted I can do that too.

I admire anyone in the business of creating frameworks on which other
people rest their livelihoods, its a tough job. So many edge cases
variables to account for. yikes.

Happy Monday tomorrow, happy Sunday today



On Sun, Jan 6, 2019 at 5:28 PM Simon Knight via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Richard,
>
> Your are correct but Malte did ask ask about general refactoring (i
> think)  so I just mentioned my latest problem / finding.  As to the PDF
> “feature” itsself I think its now up to Edinburgh to decide what to do; I
> doubt that they intended to have Adobe menus and button bars popping up in
> their RevBrowser.
>
> As to what members of this list can do the answer is to keep offering
> friendly help!
>
> best wishes
>
> Simon Knight
>
>
>
>
>
> > On 6 Jan 2019, at 17:27, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I didn't see Malte's mention of PDF in the post that began this thread,
> but topic drift is a natural part of conversation so no worries.
>
> ___
> 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: Refactoring is your friend / moving from 6.x to 9.x

[Simon Knight via use-livecode]

Richard,

Your are correct but Malte did ask ask about general refactoring (i think)  so 
I just mentioned my latest problem / finding.  As to the PDF “feature” itsself 
I think its now up to Edinburgh to decide what to do; I doubt that they 
intended to have Adobe menus and button bars popping up in their RevBrowser.

As to what members of this list can do the answer is to keep offering friendly 
help!  

best wishes

Simon Knight





> On 6 Jan 2019, at 17:27, Richard Gaskin via use-livecode 
>  wrote:
> 
> I didn't see Malte's mention of PDF in the post that began this thread, but 
> topic drift is a natural part of conversation so no worries.

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Richard:

> If you're satisfied the the progress on yours then of course you
> can safely ignore my passing that along.

Thanks Richard - all great things to bear in mind, when kept realistic. 
Areas affected by performance were pretty widespread, so it'll be easier 
to isolate any remaining areas and create new tests once the current 
memory/array/other improvements are in place. That will be an exciting 
followup.


But looking at LC Mark's optimization items, I am quite pleased with the 
progress so far and the approach taken. My tests and others have been 
converted to benchmarks, and a variety of improvements have been 
tackled, so I think very good things are in store sooner or later. I 
have always believed and promoted that LC 9 beating 6 on speed would be 
possible and desirable, and that day may come soon. Very invigorating. 
My thanks again to LC Mark for these optimization efforts!


Malte:

> And of course, please also be vocal on the positives!!!

That's easy; we're always positive! :D There are so many additions in LC 
7-9 that it would take a while to discuss, but here are some that were 
significant for me.


One of my favorites was column tabAlign in fields. Many LiveCoders still 
don't realize that they can often use a single field rather than a data 
grid for displaying tabbed text. With those column alignments fully 
supported as of LC 9, all the more incentive to keep stacks lean and 
mean when building new or updating. The only thing still lacking is word 
processing style tab aligns for normal text, and of course an option for 
column text wrap would be a huge improvement.


Another item I enjoyed and used for refactoring is the "resolve" keyword 
for images. Not only good for optimization, but also for accuracy and 
avoiding conflicts. That's what I consider a completely positive example 
of refactoring, because it's a definite improvement over even the best 
LC 6 code, rather than an arbitrary change or correcting bad habits.


I was less impressed by the new textDecode function, because while it 
results in cleaner code (and you should use it to ensure accuracy) the 
performance was actually worse than legacy LC 6 methods, if memory 
serves, and in this case I'm talking about an LC 9 versus 9 speed 
comparison with those respective sets of code. It shouldn't be slower, 
if indeed it is; my legacy methods were even jumping a few extra hoops 
for the sake of ~100% Unicode accuracy on older LCs, so textDecode had 
every advantage. That's probably another enhancement request I should 
test and file, the first chance I get.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Malte Pfaff-Brill wrote:

> If there were a list of things that do no longer work as they did non
> previous engines it would have been beneficial for me to check off
> points like „Yes, using that, need to fix / No, does not affect my
> work"

Half of that problem is solved in the Engine Changes section of the 
Release Notes.


That change list is added to with each release within a maintenance 
release (x.x through x.x.x), reset for feature releases (x.x).


But that addresses only half of the problem of the differences between 
two versions: it outlines the changes in the version you're moving to, 
but does not express everything since the version you were last using.


To solve that second half of the problem would require the maintainer of 
the Release Notes to be able to know which version each user had last 
used, and expand the Release Notes for that scope. :)


Of course that's impractical, and if you keep current from version to 
version you only need to read one.


But if you've missed several Stable versions, you may want to skim the 
Engine Changes listing for the Stable builds of the feature releases 
you've skipped:


https://downloads.livecode.com/livecode/

--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Malte Pfaff-Brill via use-livecode]

And of course, please also be vocal on the positives!!!

Old engine Mac: Hi res images were a problem to render (for whatever reason, I 
had to use video player instead of image object to display those images). 
Limitations here have been lifted which for me is a very pleasant change!

Cheers,

Malte
___
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: Refactoring is your friend / moving from 6.x to 9.x

[Malte Pfaff-Brill via use-livecode]

Hi Richard,

>I didn't see Malte's mention of PDF in the post that began this thread,
While that is true, but I am actually (as stated) keen to learn about 
everything that could be a gotcha when transitioning from the old engine to the 
latest, so this is welcome input. Also Marks mention of TAB button behaviour on 
a Mac is something I really appreciate to know, as I use those. To add to my 
list is that some of the inks have been deprecated which resulted in hidden 
elements where I used a deprecated ink.

If there were a list of things that do no longer work as they did non previous 
engines it would have been beneficial for me to check off points like „Yes, 
using that, need to fix / No, does not affect my work"

Cheers,

Malte
___
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: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Simon Knight wrote:

> This thread seems to have diverted away from Malte’s original post.

Somewhat. His post from Dec 30 listed three issues:

-  IDE spams a lot of IDE only messages when creating many objects by
   script -> remedy: Lock messages
Locking messages is a good habit for any context in which system 
messages are not needed.


-  Nested Lock screens are a big "NO-NO“ nowadays
As Mark Waddingham noted, with hi-res displays there is now more impact 
from rendering; 4x more pixels to push.


-  Array operations on larger data sets still slower than they were
Already in progress - see:
https://quality.livecode.com/show_bug.cgi?id=16387
https://github.com/livecode/livecode/pull/6671

All three issues which began this thread are resolved.

The rest was in reply to his open-ended question at the bottom of that post:

   Did anybody of you happen to refactor old code and if so,
   do you have any observations you might want to share?


> For Malte and others I have found that the revBrowser control is
> slower to render PDFs and may insert unwanted menus and button
> thanks to Adobe in version 9.02.
> See  https://quality.livecode.com/show_bug.cgi?id=21776

I didn't see Malte's mention of PDF in the post that began this thread, 
but topic drift is a natural part of conversation so no worries.


Interesting circumstance in your report.  Lots of moving parts there, 
with LC relying on the browser component which in turn relies on Adobe 
components (and FWIW I share your opinion on Adobe ).


Looks like you've made some good progress there.  How can the readers of 
this list help?



> One question why does this thread refer to RQCC ?

Old habits.  The bug database used to be called the "Revolution Quality 
Control Center", and the acronym is forever stuck in my typing fingers.


--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> Richard:
...
>  > As hodge podge of what appear to be very different optimization
>  > opportunities under the hood, it may be difficult for the team to
>  > take action on it/them, and impossible to track. [... ... ...]
...
> ..Moot point, because I didn't have time for a cluster of reports.

(4,000 words later)


> I received good feedback about the test stack and the video

I passed along from guidance provided by members of the core team to 
help reports be actionable.


If you're satisfied the the progress on yours then of course you can 
safely ignore my passing that along.


--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Simon Knight via use-livecode]

This thread seems to have diverted away from Malte’s original post.

For Malte and others I have found that the revBrowser control is slower to 
render PDFs and may insert unwanted menus and button thanks to Adobe in version 
9.02.
See  >

One question why does this thread refer to RQCC ?

best wishes

Simon





> On 30 Dec 2018, at 19:33, Malte Pfaff-Brill via use-livecode 
>  wrote:
> 
> Did anybody of you happen to refactor old code and if so, do you have any 
> observations you might want to share?
> 
> Cheers,
> 
> Malte

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Richard:

> It's a bit confusing, since the Target Version shown there is 7,
> but it was submitted just a few months ago, many years after v7
> was EOL'd.

As you can see (in the message you replied to) I inquired back then, and 
was advised officially then. BTW, that's a bit like the concrete info 
and explanations that were here all the time and it turns out you 
admittedly saw, interacted with, and evaluated - all, as you say 
yourself, very recently. I almost want to blush for you. :)


> As hodge podge of what appear to be very different optimization
> opportunities under the hood, it may be difficult for the team to
> take action on it/them, and impossible to track. [... ... ...]

Priceless drama! Kittens and puppies massacred all over town, no doubt, 
from my being alert enough to notice the problem when others did not, 
and reporting some excellent test cases to prove that more areas were 
affected than originally assumed. I file many pinpointed bugs, as you 
know well from your CCs over the years. I'm sure a cluster of narrowed 
examples would be nice for this performance issue too, nothing against 
it, but who knows yet precisely how many or how few areas and individual 
causes? Overlaps? Moot point, because I didn't have time for a cluster 
of reports. Nor magical space/time control and travel to organize and 
fit the problem to a separately-evolving set of solution/improvement 
efforts (which I'm very hopeful about) that started with arrays.


I received good feedback about the test stack and the video; there was 
enough time to create and maintain one test stack, and it needed to look 
good and perform the video competition too. LC has a somewhat messy set 
of performance issues, not of my own making, and reporting it on my own 
time and expense had to be realistic and finite. Some people might not 
have any real limitations on free time, anything goes, but others know.


I have beaten the odds as one of most prolific consultants and addon 
developers despite extensive handicaps that take up considerable daily 
time and energy themselves. It doesn't just happen that way by itself; 
the system that makes it possible doesn't involve repeating, redoing, 
and restating every single darn thing the livelong day. Precisely the 
opposite; efficiency is key and it will never let you down if you apply 
it consistently and strictly! Take care.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> Richard:
>  > I'd like to follow their progress [...]
>  > supporting the QA process benefits my work as well.
>
> Thanks, Richard! Yes, if you're not on the list for that bug, that
> would superb to sign up. I thought it might be considered old or
> familiar news here since tests and observations had been posted and
> discussed before by myself and others, so at first I didn't want to
> sp*m too much info again. Here we go in reverse chronology:
...

After following out the links in your post I eventually found one link 
where the rubber meets the road with an RQCC report:


https://quality.livecode.com/show_bug.cgi?id=21561

It's a bit confusing, since the Target Version shown there is 7, but it 
was submitted just a few months ago, many years after v7 was EOL'd.


Did you try to tip Heather included in Comment 5 there?


As hodge podge of what appear to be very different optimization 
opportunities under the hood, it may be difficult for the team to take 
action on it/them, and impossible to track.


For example, we know from Mark Waddingham's recent post on array 
optimizations that at least some of the many very different tests there 
will be affected, and likely not others.


Also, textreplace relies on the regex subsystem, which I'd guess is 
independent of the chunk handling code for items, which is different 
again from the allocation options for appends (I thought append had some 
revisions since v7, no?), and likely separate from the math operations.


If I can't even follow the progress on that report, I pity the dev 
assigned to deal with it.


In fact, now that I see it again I recall that the 
everything-in-one-report nature of that is why I subscribe to it when it 
was created in September.


Imagine if we put all bugs from the RQCC into one report.  That seems 
absurd of course, but this is unfortunately just a smaller version of 
the same problem imposed by such a grab-bag approach.


Maybe someone on the team has the resources to break it up into 
actionable elements.  Maybe you do.  I don't right now.


It's too bad that report's recipes have been packaged in such an unusual 
format uniquely difficult to integrate and track within the QA process. 
Looks like some useful details there, currently lost in a black box.



> Hope you enjoyed the R^3 link antimeme joke! :) Miss our periodic
> catch-up calls; maybe we can do one later this year when we have a
> chance.

Yes, good link.  It's been a hectic season but lightening up.  It would 
be good to catch up.


--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Kay C Lan via use-livecode]

On Sat, Jan 5, 2019 at 10:13 AM Bob Sneidar via use-livecode
 wrote:
>
> I just finished a little utility that takes accounting data export from 
> Toshiba copiers ...The customer LOVES us.

OT
You might want to contact the Cuyahoga County Recorder's Office in
Ohio as they clearly have problems with staff and photocopiers:
https://www.youtube.com/watch?v=PZbqAMEwtOE

Emily Maya Mills plays her role to perfection!  There should be Acadmy
Awards for YouTube™ reenactments.

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Richard:

> I'd like to follow their progress [...]
> supporting the QA process benefits my work as well.

Thanks, Richard! Yes, if you're not on the list for that bug, that would 
superb to sign up. I thought it might be considered old or familiar news 
here since tests and observations had been posted and discussed before 
by myself and others, so at first I didn't want to sp*m too much info 
again. Here we go in reverse chronology:


Jan 2019: Current mention, as a reminder and still-the-same 902 status 
update.


Sep 2018: LC Version "Showdown" video with several tests between 6.7 and 
9, to accompany separate Bug Report and Test Stack. (3 Links.)




2018: Several list discussions that touched on performance. Including 
your JS speed comparison suggestion, which I included. Also Mark's note 
about array work, and some array vs list tests by others.


Jan 2017: LC "Fight Night" video with demo tests between LC 6.7, 5.5, 
8.1.2 and 9 dp 4. At that point 9 was still very much under 
construction, so 8 was the stable data point. Didn't have a chance to 
post followups that year.




Prior: As I recall, I noticed performance differences from LC 7/8 on and 
mentioned it, but heard back officially that the new LC would go through 
an optimization stage, so I waited accordingly.


Of course all this may NOT cover all performance issues; it's a limited 
set of tests as examples.


> to rule out all possible impact from type coercions
> which may involve encoding operations.

True enough; I've mentioned my own rule of refraining from speculating 
much on the causes, but pointing out the areas affected, and countering 
a just-Unicode-as-expected meme that pops up now and then. The "Fight 
Night" was designed to pin down what I had encountered in my own work - 
that several areas were affected, not just text and arrays. Some tests 
were designed to avoid type coercions to the extent possible. (I think 
it was especially "Root Loops" - the original version, not the big calc 
variation.) So I can't say for sure that it's not happening, but in 
those cases it shouldn't be.


Hope you enjoyed the R^3 link antimeme joke! :) Miss our periodic 
catch-up calls; maybe we can do one later this year when we have a chance.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> http://curryk.com/NeverGonna.mp4

Thank you for the link to test results relating to specific issues.

What bug reports can I find those test stacks attached to?

I'd like to follow their progress, and perhaps re-run them to see where 
there may have been changes after the seven builds delivered since v9.0 
was released. Happy to help steward issues along as best I can; 
supporting the QA process benefits my work as well.



> Oh boy - I was ALWAYS gullible enough to fall for the "concrete
> concerns" type of line every single time, and rush off to make a newer
> list..

Not really needed.  When you use the RQCC you'll see that searches are 
expressed in the URL, so when communicating about several issues at once 
you needn't really need to spend any time writing each of them down, you 
can copy the search URL you've already bookmarked to monitor issues 
you're following.



> And testing indicated that it's almost certainly NOT just a Unicode
> thing.

Kudos.  I've have neither the time nor the C++ experience to examine the 
code well enough to rule out all possible impact from type coercions 
which may involve encoding operations.


What I have seen in many RQCC discussions is that fixing legacy bugs 
sometimes adds additional overhead.


Admittedly going out on a limb here, but I'm reasonably confident the 
team is neither willfully introducing new code to slow things down for 
no reason, or doing slopping haphazard work with no regard for quality.


With that assumption, when I see performance degradation I'm inclined to 
recognize that what I have is not a lengthy declaration opining about 
what constitutes professional code, or any declaration at all.  What I 
have is inherently a question: Why is this specific operation slower?


When I pose questions as questions I usually get answers in reply, and 
often quite helpful ones, e.g.:


> Mark Waddingham:
>
>  > It hasn't as yet - that PR
>  > (https://github.com/livecode/livecode/pull/6671) has actually
>  > turned into a mini-grab bag of things [...]
>
>  > - reduction of memory usage of the 'handle' structures used to
>  > hold values (particularly on 64-bit)
>  > - faster processing of integer index access in arrays
>  > - faster short-path array access (both storing and fetching) [...]
>
> Yes!!! Just what I was hoping to hear, that this is still in the
> works. Thank you, sir. It should help a great deal.


My interest is in getting results. I wish I had time for anything as 
colorful as "circling wagons", but alas like most people here I simply 
have software to deliver and need to stay focused where I can on 
specific actionable outcomes.


To that end, my method here is as straightforward as with anyone I work 
with:


1. Learn from the people doing the work I'm relying on
   how best to support their efforts.

2. Then I do that.

FWIW, using this method I see a lot of issues I report get resolved. 
Some very quickly.  And the ones not yet resolved are usually 
accompanied by an explanation of what's involved so I can understand the 
priorities at play.


--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Richard:

> Is there an actual list of concrete concerns here [...]
> or did I just spend an hour reading that I'll never get back?
> I feel rickrolled.

A profound question, my friend. :D You may notice something special 
about the following link, adapted in honor of the situation:


http://curryk.com/NeverGonna.mp4

Oh boy - I was ALWAYS gullible enough to fall for the "concrete 
concerns" type of line every single time, and rush off to make a newer 
list, until finally I wised up to the world's ways and realized that 
(outside of bug reports and specific issues) such statements are 
sometimes used merely to deflect - it's not always a matter of actually 
wanting more details, but rather quite simply an unwanted message.


These days, I am usually prepared in advance and merely smile and point 
a finger toward the information; the answer long preceded the question!


Many of the details had been in place and waiting for some time, by 
myself and others. They've been presented and discussed before, so I 
didn't anticipate the need to reference every single one yet again; 
perhaps I should have. But I understand that memories can be convenient, 
and assumptions and agendas can be strong enough to brush aside what we 
already know every now and then.


So, the "reverse rickrolled" link above connects to some aging stats 
that still hold generally true on the subject of performance. In many 
very basic tasks (math, loops, arrays) LC 9 has fallen short by 1.x or 
even 2.x, and that's still the case as of 902 final.


And testing indicated that it's almost certainly NOT just a Unicode 
thing. I'm sorry if that makes me the messenger of inconvenient news, or 
a destroyer of attractive explanations, but I prefer the plain truth of 
reality. Repeatable, proven, public tests, videotaped and distributed; 
sorry, but it's fact. No line of talk or alternate authoritative studies 
can alter that. Test it yourself, or look the other way if you must, but 
the facts persist either way.


I'm going to wait until there are relevant engine changes to update the 
results chart and test stack. It'll be fair as usual; in the original 
round of testing I went out of my way to make sure 9 had at least one 
match in its favor, and now I know a few other areas thanks to these 
talks. Hopefully after said engine changes, 9 will be the big winner!


When it comes to another matter of efficiency and saving work by 
avoiding repetition, I've always been a big fan of Richard's own rather 
extensive and lengthy rhetoric on the subject, and his repertoire of 
catchy acronyms such as WET (We Enjoy Typing) versus DRY (Don't Repeat 
Yourself). But I do believe in following through and applying the 
fundamental concepts consistently across the board, including reasonably 
minimizing repetition of the work itself. In fact Richard, there was a 
very eloquent past message of yours on a similar subject, if memory 
serves me well. I may post a link eventually if I have time to hunt it 
down, and defer to your own words on that; it was very well said.


Bob:

> Some may think I'm overstating my case, but I think Livecode
> stands alone in development environments for speedy development
> and ease of use.

You may be surprised that I agree! But of course you wouldn't be 
surprised if you noticed that for many years now, I am 100% specialized 
and 100% dedicated to LiveCode consulting and development. It's all I 
do. I walk the walk, while others talk; all LiveCode, all the time.


So I understand if you feel an impulse to circle the wagons, but it's 
preaching to the choir or perhaps to the preacher himself. That question 
of which tool was settled long ago, and I'm a bigger LC proponent than 
almost anyone, especially since my skin is 100% in the game as a 
dedicated and exclusive specialist in that one tool. What we are looking 
at here is the question of making THE tool better in some areas. And if 
that's a bad thing, then count me guilty as charged, because I use, 
teach, and promote this tool 24/7/365 year after year, there are big 
plans ahead, and there are certain things I want in place for LC's own 
benefit, for yours, and for my own. Far from being a threat, they will 
help LC maintain its advantage against any potential competition.


Mark Waddingham:

> It hasn't as yet - that PR
> (https://github.com/livecode/livecode/pull/6671) has actually
> turned into a mini-grab bag of things [...]

> - reduction of memory usage of the 'handle' structures used to
> hold values (particularly on 64-bit)
> - faster processing of integer index access in arrays
> - faster short-path array access (both storing and fetching) [...]

Yes!!! Just what I was hoping to hear, that this is still in the works. 
Thank you, sir. It should help a great deal.


And THAT is the reason I engage in these particular discussions, and 
make myself cannon fodder at times to get the info out there: there are 
amazing benefits still to be realized, even when using such a

Re: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

+1

I'm just elated I can write apps again after such a long drought from 
Hypercard, and the disappointment I had with Supercard. I personally think LC 
is what Hypercard should ALWAYS have been, or would have become had Apple had 
kept it up, or had someone else taken it up. Now I do not develop in Windows or 
Linux, so there may be/have been some real concerns there. Still, what we can 
do, what many of us have done is nothing short of breathtaking. My service 
manager who was rolling his eyes when I told him what I was going to do with 
Forms Generator is now tickled pink that we can generate forms on demand, on 
site, that look professional. That app had a lot to do with my present status 
in the company. I took the job as a copier installer. I'm now the Systems 
Administrator for the entire comany, and they are training me for Pre-Sales 
Software Consultation and support. 

I just finished a little utility that takes accounting data export from Toshiba 
copiers and adds up the color and black totals that make some kind of sense 
(the export file decidedly does NOT make sense) in a great looking interface, 
and then outputs a PDF report, or a tab delimited txt file for use in Excel. 
The customer I wrote it for initially had his doubts about our company, but 
after I sent him that little gem he LOVES us. So does his accounting department 
who no longer has to cobble all the data together themselves. 

The time it took to do all this would have been unthinkable in a C derivative 
or in a Java based environment. Never mind all the new features and updates 
I've been adding all along. Some may think I'm overstating my case, but I think 
Livecode stands alone in development environments for speedy development and 
ease of use. 

Bob S



> On Jan 3, 2019, at 22:40 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Read through this whole thread, optimistic that I'd find the list of things 
> that differentiate v6 and v9 so we can hone in on actual solutions.
> 
> I learned two things:
> 
> - lock/unlock changed
> 
> - It's apparently easier to write a thousands of words philosophizing
>   about how a small team of C++ programmers should provide a uniform
>   scripting interface for a nearly unprecedented number of OSes,
>   stay on top of ongoing API changes in every one of those OSes,
>   multiply features, fix bugs, incorporate Unicode, maintain or improve
>   all aspects of performance, and keep the joint running than it is to
>   even briefly summarize concerns about any of the above.
> 
> Is there an actual list of concrete concerns here that the team may be able 
> to take action on or at least explain how/why the change exists, or did I 
> just spend an hour reading that I'll never get back?
> 
> I feel rickrolled.
> 
> 
> I've worked with too many people moving from Drupal 7 to Drupal 8, or Python 
> 2 to 3, or any version of Apple's C headers in the '90s that broke 
> declarations quarterly, or HyperCard 2 to 3, to get too out-of-breath about 
> undoing workarounds in old code to work with-the-grain for v9's enhancements 
> and fixes for long-standing anomalies.  When I describe LC's high priority 
> for backward compatibility to nearly any other experienced dev I know, they 
> look at me like I'm high and spouting tales of dancing ponies; many 
> professional development systems consider backward compatibility a very minor 
> nice-to-have, if they devote time to it at all. Many of us here buy computers 
> from a hardware vendor with a similar view.
> 
> As for performance, in threads with Geoff Canyon, Mark Talutto, and others 
> who provided real-world use cases and metrics, we do see some performance 
> degradation in v9 from v6 in some cases, a surprising amount on par given how 
> relatively little work v6 had to do under the hood with encodings and types, 
> a few things a wee bit faster, and overall such a strong comeback from the v7 
> series that it should be clear to those earnestly following along that the 
> team has indeed been quite evidently working on performance, and delivering 
> improvements over the v9 cycle.
> 
> Then again, my work may not touch the items on the concern list.  I can't 
> know, because I couldn't find such a list in this long thread.
> 
> --
> 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


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

Re: Refactoring is your friend / moving from 6.x to 9.x

[Mark Wieder via use-livecode]

On 1/4/19 3:40 AM, Malte Pfaff-Brill via use-livecode wrote:


Actually I did not expect this thread to turn into philosophical discussions. 
What I was searching for was input on gotchas you guys and girls may have 
experienced when moving from the monolith engine to the refactored one., so 
that I would get an idea on what to look out for when continuing to refactor my 
old project(s).


Here's one that bit me:

In LC 8 dp15 a change was made to tab controls: they are now 
transparent, even if you set a background color and make them opaque, 
but *only on Mac OS*. My workaround is to set an opaque rectangle behind 
the tab controls. It's not in the release notes.


https://quality.livecode.com/show_bug.cgi?id=17219

--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Malte Pfaff-Brill via use-livecode]

>  Of course, the latter is making the assumption that 
> Malte has a Retina mac...
Indeed he has (now and did not back in the days where the app was written)


Actually I did not expect this thread to turn into philosophical discussions. 
What I was searching for was input on gotchas you guys and girls may have 
experienced when moving from the monolith engine to the refactored one., so 
that I would get an idea on what to look out for when continuing to refactor my 
old project(s). 

I was aware of the unicode related changes and am trying to remove all the 
stuff that has been deprecated (like charToNum, useUnicode, and the like). That 
is pretty well documented and understandable. Marks explanation on my redrawing 
issues are explanations that are understandable, make sense and I am aware now. 
The „fun“ part is, that something like this will never be able to be caught by 
unit tests or simple example stacks. One will need real world projects of a 
certain size to see the effect. To put things into perspective here, the app I 
am refactoring has to draw/redraw about 1500 controls, of which only a couple 
are changing positions / get a new label etc. Retina quite surely is a factor 
here. Also settings for „accelerated rendering“ might play a role.

While I applaud Currys effort to set up real world benchmarking stacks to 
compare between engines, I lack the self confidence to be convinced to write 
perfect code. I surely do not, especially if like in my case the number of 
lines of code go into the 10 thousands. I *try* to avoid redundancy . Most of 
the time I succeed and if I do find areas that are redundant, I refactor. The 
engine got a long way here. Behaviors, and nested behaviours (this me anyone?) 
are a very good example on how the engine matured over the years. I would not 
dare to expect that code written 10 years ago for an engine that was current 10 
years ago is still useable without optimisations. I just have been away for too 
long to be able to know what to look out for.

I am indem looking forward to the array optimisations to come, as once that is 
off the table I am looking forward to actually having something that will be 
much faster than I had it in previous versions.

Cheers,

Malte

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Mark Waddingham via use-livecode]

On 2019-01-04 09:03, Kay C Lan via use-livecode wrote:

So what I can't confirm is whether PR6671 has been implemented into a
current version of LC9, but what I will say is this, if it hasn't then
Malte can look forward to an eventual speed improvement in large Array
operations as Mark Wa has already identified this problem and is
working on a fix.  If it has been implemented then Malte needs to take
a look at Mark Wa examples and see where he can use some of Mark Wa's
good code to replace his own poorly performing code.


It hasn't as yet - that PR 
(https://github.com/livecode/livecode/pull/6671) has actually turned 
into a mini-grab bag of things which need to be separated out slightly:


  - reduction of memory usage of the 'handle' structures used to hold 
values (particularly on 64-bit)

  - faster processing of integer index access in arrays
  - faster short-path array access (both storing and fetching)
  - 'static' switch optimization (switches with all literal cases are 
now constant time and not linear in the number of cases)
  - params([, ) which returns an numeric array of parameters  
up to 

  - sequence and array literals
  - a try(expr, error-expr) function (evaluates error-expr as the result 
if expr throws)

  - array meta-indexing (tArray[first], tArray[last], tArray[next])

The only one which is unlikely to survive is the meta-indexing as (1) 
they don't quite work correctly and (2) Monte had a better suggestion 
which I've not had a chance to implement.


It also contains benchmarks derived from my talk at LCG on optimization, 
and Curry's which he posted a while back.


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: Refactoring is your friend / moving from 6.x to 9.x

[Mark Waddingham via use-livecode]

On 2019-01-04 07:40, Richard Gaskin via use-livecode wrote:

Read through this whole thread, optimistic that I'd find the list of
things that differentiate v6 and v9 so we can hone in on actual
solutions.

I learned two things:

 - lock/unlock changed


Except it hasn't - lock/unlock screen work the same as they always have 
- they nest.


Differences since 5 however, include:

  - rendering was changed to use Skia
  - support for Retina displays was added (4x as many pixels to render 
on more modern Macs)
  - screen updates only happen once per command execution and only if 
necessary (if the screen is unlocked)


As suggested in another post, I suspect Malte's speed difference was 
actually caused by over-unlocking (or interaction with a slightly wrong 
IDE script in the 5 IDE - assuming he was timing in the IDE) and the 
fact that Retina macs have 4x as many pixels to render (5.x did not do 
Retina resolution). Of course, the latter is making the assumption that 
Malte has a Retina mac...


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: Refactoring is your friend / moving from 6.x to 9.x

[Kay C Lan via use-livecode]

On Fri, Jan 4, 2019 at 6:03 PM Richard Gaskin via use-livecode
 wrote:

> Is there an actual list of concrete concerns here that the team may be
> able to take action on ...

I think the closest would be:

>Malte wrote:
>Not yet fixable for me:
>Array operations on larger data sets still slower than they were

Which leads me to the post titled: On Performance of Array Access
posted 31 Aug 2018 relating specifically to large array data sets.

>The wise Mark Wa (on a 2018MBP) wrote:
>Generally, I don't tend to like to 'jump the gun' on anything related to
>optimization lest it is not what it seems when running in the real world
>but...

His scripts used for the tests are all public, repeatable and
objective, but if you don't want to bother finding that Post here are
the results  (PR6671 refers to a GitHub Pull Request into the LC9
engine)

>LC6.7.11: 1117ms
>LC9.0.1:  4020ms
>PR6671: 1017ms

>6.7.11: 1055ms
>9.0.1:  3281ms
>PR6671: 497ms

>6.7.11: 16872ms
>9.0.1:  8305ms
>PR6671: 4315ms

>6.7.11: 16508ms
>9.0.1:  6397ms
>PR6671: 3001ms

>REAL WORLD CASE

>Now, I'm always a little skeptical about using synthetic benchmarks for
>performance. However, both of the above are actually real-world
>examples. Furthermore, when running a rather large LCS project on an
>engine with PR6671, I got a 2x speed up - one particular input took
>3mins to process, rather than 6mins (one phase of processing actually
>saw a 5x speed up!).

So what I can't confirm is whether PR6671 has been implemented into a
current version of LC9, but what I will say is this, if it hasn't then
Malte can look forward to an eventual speed improvement in large Array
operations as Mark Wa has already identified this problem and is
working on a fix.  If it has been implemented then Malte needs to take
a look at Mark Wa examples and see where he can use some of Mark Wa's
good code to replace his own poorly performing code.

How this thread diverged from a problem that was clearly resolved by
fixing poor code, to, what seems to me, 'our poor code should run just
as fast in LC9 as LC5', I don't know. Sorry.

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Geoff Canyon wrote:

> I wasn't sure what people were talking about with lock screen
> performance issues, so I did a simple test
...
> ...and found that in 6.7.3 that change increased the duration to about
> 1.25 seconds -- a performance hit of about 30x just because a locked-
> screen button is actually moving. In 9.0.1, the time changed to about
> 0.35 seconds. So if the button *isn't* moving, 6.7.3 is much faster,
> but in the more practical and likely case that the button *is* moving,
> 9.0.1 is faster. So ¯\_(ツ)_/¯

That seems a good balance of priorities by use case.  After all, when 
nothing's moving the wait time may not even be noticeable, but with 
moving objects performance can be critical.


--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Geoff Canyon via use-livecode]

I wasn't sure what people were talking about with lock screen performance
issues, so I did a simple test: I set up a button to either lock the screen
once, or twice, and then timed setting the loc of the button while the
screen was locked. I didn't time locking the screen; just the movement
while locked. As I hoped, I didn't find any difference between locking once
or twice, either in 6.7.3, or in 9.0.1 (on an up-to-date Mac).

But...

There was a significant performance difference between 6.7.3 and 9.0.1.
*Maybe* this is Unicode related? In any case, this script takes about 0.04
seconds in 6.7.3, and 0.24 seconds in 9.0.1:

on mouseUp
   put the loc of me into L1
   put L1 into L2
   lock screen
   put the long seconds into T
   repeat 10
  set the loc of me to L2
  set the loc of me to L1
   end repeat
   put the long seconds - T into T
   unlock screen
   put T
end mouseUp

Then I noticed that I had forgotten one line of code. I changed it to this:

on mouseUp
   put the loc of me into L1
   put L1 into L2
   add 100 to item 1 of L2
   lock screen
   put the long seconds into T
   repeat 10
  set the loc of me to L2
  set the loc of me to L1
   end repeat
   put the long seconds - T into T
   unlock screen
   put T
end mouseUp

...and found that in 6.7.3 that change increased the duration to about 1.25
seconds -- a performance hit of about 30x just because a locked-screen
button is actually moving. In 9.0.1, the time changed to about 0.35
seconds. So if the button *isn't* moving, 6.7.3 is much faster, but in the
more practical and likely case that the button *is* moving, 9.0.1 is
faster. So ¯\_(ツ)_/¯


On Thu, Jan 3, 2019 at 11:03 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Read through this whole thread, optimistic that I'd find the list of
> things that differentiate v6 and v9 so we can hone in on actual solutions.
>
> I learned two things:
>
>   - lock/unlock changed
>
>   - It's apparently easier to write a thousands of words philosophizing
> about how a small team of C++ programmers should provide a uniform
> scripting interface for a nearly unprecedented number of OSes,
> stay on top of ongoing API changes in every one of those OSes,
> multiply features, fix bugs, incorporate Unicode, maintain or improve
> all aspects of performance, and keep the joint running than it is to
> even briefly summarize concerns about any of the above.
>
> Is there an actual list of concrete concerns here that the team may be
> able to take action on or at least explain how/why the change exists, or
> did I just spend an hour reading that I'll never get back?
>
> I feel rickrolled.
>
>
> I've worked with too many people moving from Drupal 7 to Drupal 8, or
> Python 2 to 3, or any version of Apple's C headers in the '90s that
> broke declarations quarterly, or HyperCard 2 to 3, to get too
> out-of-breath about undoing workarounds in old code to work
> with-the-grain for v9's enhancements and fixes for long-standing
> anomalies.  When I describe LC's high priority for backward
> compatibility to nearly any other experienced dev I know, they look at
> me like I'm high and spouting tales of dancing ponies; many professional
> development systems consider backward compatibility a very minor
> nice-to-have, if they devote time to it at all. Many of us here buy
> computers from a hardware vendor with a similar view.
>
> As for performance, in threads with Geoff Canyon, Mark Talutto, and
> others who provided real-world use cases and metrics, we do see some
> performance degradation in v9 from v6 in some cases, a surprising amount
> on par given how relatively little work v6 had to do under the hood with
> encodings and types, a few things a wee bit faster, and overall such a
> strong comeback from the v7 series that it should be clear to those
> earnestly following along that the team has indeed been quite evidently
> working on performance, and delivering improvements over the v9 cycle.
>
> Then again, my work may not touch the items on the concern list.  I
> can't know, because I couldn't find such a list in this long thread.
>
> --
>   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
>
___
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: Refactoring is your friend / moving from 6.x to 9.x

[Richard Gaskin via use-livecode]

Read through this whole thread, optimistic that I'd find the list of 
things that differentiate v6 and v9 so we can hone in on actual solutions.


I learned two things:

 - lock/unlock changed

 - It's apparently easier to write a thousands of words philosophizing
   about how a small team of C++ programmers should provide a uniform
   scripting interface for a nearly unprecedented number of OSes,
   stay on top of ongoing API changes in every one of those OSes,
   multiply features, fix bugs, incorporate Unicode, maintain or improve
   all aspects of performance, and keep the joint running than it is to
   even briefly summarize concerns about any of the above.

Is there an actual list of concrete concerns here that the team may be 
able to take action on or at least explain how/why the change exists, or 
did I just spend an hour reading that I'll never get back?


I feel rickrolled.


I've worked with too many people moving from Drupal 7 to Drupal 8, or 
Python 2 to 3, or any version of Apple's C headers in the '90s that 
broke declarations quarterly, or HyperCard 2 to 3, to get too 
out-of-breath about undoing workarounds in old code to work 
with-the-grain for v9's enhancements and fixes for long-standing 
anomalies.  When I describe LC's high priority for backward 
compatibility to nearly any other experienced dev I know, they look at 
me like I'm high and spouting tales of dancing ponies; many professional 
development systems consider backward compatibility a very minor 
nice-to-have, if they devote time to it at all. Many of us here buy 
computers from a hardware vendor with a similar view.


As for performance, in threads with Geoff Canyon, Mark Talutto, and 
others who provided real-world use cases and metrics, we do see some 
performance degradation in v9 from v6 in some cases, a surprising amount 
on par given how relatively little work v6 had to do under the hood with 
encodings and types, a few things a wee bit faster, and overall such a 
strong comeback from the v7 series that it should be clear to those 
earnestly following along that the team has indeed been quite evidently 
working on performance, and delivering improvements over the v9 cycle.


Then again, my work may not touch the items on the concern list.  I 
can't know, because I couldn't find such a list in this long thread.


--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Sorry Bob (not to single you out, on the contrary thanks for your reply 
and sharing your experience) but just be aware I never not enter a 
thread lightly, nor were my words hasty. This has been a situation years 
in the making, with plenty of evidence behind it, and I've been many 
years in the LC arena. My list and forum silence may sometimes mask my 
eternal presence and busy contributions. I realize that the human mind 
tends to favor the loudest and most frequent voices (in marketing it's 
recognized that an audience needs to hear a message repeated 3 times to 
even notice it, whereas if you repeat yourself 3 times in code you've 
broken a rule) so when popping up now and then, I will remind the hasty 
of reply that while my points are easy to dismiss on the subjective 
basis of being heard less frequently, they are built on solid ground and 
difficult to overturn by factual or logical approach.


(I don't have spare time to be one of the loudest and most frequent 
voices here, so for better or worse this post must satisfy the 
obligatory 3 times mentioning, and unfortunately that's all I can spare; 
I'll be back in lurk/work mode soon after this because as my clients 
know, they come first; no exceptions. Even addons come second and 
conversation is last. To sum up what years of factual records will show, 
I'm not one of the most frequent posters here on the list, but I am one 
of the most frequently involved consultants in the LC world. So)



Not to put too fine a point on this, but ALL development
environments suffer from this.


Not all to the same extent. And there's the difference, adding to 
personal preference and work needs/range of experience. Without going 
too far down that potentially red herring road, when it could be called 
suffering it's too much. When done right it doesn't cause suffering. 
That will vary per personal preference, bias, and experience, but what 
stays true is that efficiency is better than a lack of it. I'm sure you 
have many examples, but I would have many counter-examples, plus I think 
arguing for quality and efficiency is a stronger position that arguing 
for a lower-quality, lower-efficiency bandwagon. Winning an irrelevant 
contest of examples would not weaken my point, so we can probably save 
that particular trip.



I moved projects from LC6 to LC9 with little difficulty.
My problems revolved around app building, and I got through
that fairly simply.


I'm genuinely happy for you there! I work for a wide variety of client 
projects and my own addons and other projects, so it takes me lots of 
places within LC. Not one platform nor approach nor area of LC 
endeavors. I also have spent a lot of time tracking down issues to 
report, investing my own addon income right back in LC debugging rather 
than own products, to help LC through the transitions, and many of those 
bugs have been fixed. You may have benefited from those and the efforts 
of others who dedicated a lot of time to that. So I applaud your own 
luck and lack of trouble, but perhaps fortunately you were in an area 
that benefited from the most attention to fixes and the least need for 
performance.


But never mind me; for anyone to argue that there was no extra work 
involved, they would have to scrub some messages from the list in 
general and this thread in particular. I'm not sure if you read the 
original post in this thread, but the extra work was acknowledged right 
there when starting this thread, by others. Without that, we wouldn't be 
having this conversation in the first place, no matter whether criticism 
or justification, so I feel no need to say more on that point; 
sufficiently documented although perhaps not a universal condition. But 
remember, not everyone who became frustrated came back. There were other 
discussions, including a somewhat hilarious one that I can't relate here 
due to privacy agreements but where I was the person complaining the 
LEAST of many prominent LC members in that particular conversation.


(Likewise, those separate points of defense argue against themselves to 
a degree; if there was no trouble in your case, then do all environments 
indeed suffer the problem? Separately good defenses, but together, not 
quite as strong.)


Sorry again (and nothing personal, I appreciate your comments) and can 
understand your POV from your particular experience, but no amount of 
talk can disprove (A) repeatable test results and (B) the economics of 
efficiency. Those will stand on their own.



I could go on singing my own praises, but my point is, the
assessment of profitability often depends largely on where you
decide to plant your flag.


As I said, I'm stable here, as are the laws of this universe - no 
running off disappointed or depressed, no coming back and gushing over 
it. No urge to overly defend or rationalize the last two years, nor any 
need to criticize beyond an objective measure.


My work has been consistent and steady, and in fact I've als

Re: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

Not to put too fine a point on this, but ALL development environments suffer 
from this. Even if everything is done "right", future OS enhancements, new and 
improved plugins, LC feature enhancements and even developer enhancements can 
all lend themselves to the necessity for refactoring. 

It also begs the question what is meant by doing things right. With a fairly 
forgiving scripting environment like LC, right simply means, "compiles and runs 
without any errors." I moved projects from LC6 to LC9 with little difficulty. 
My problems revolved around app building, and I got through that fairly simply. 

What is missing here I think is what is great about developing in LC. The time 
it takes you to build an app is a fraction of the time it would have taken you 
in C variants or even Java, and the manpower needed is also dramatically 
reduced (and dare I say more cost effective to employ). It's a little like my 
boss telling me that I need to make more money getting customers to pay for IT 
services if I expect a raise. 

The elephant in the room however is that I have been saving them a boatload of 
money these 4 years, ever since I took over managing all their internal IT 
support allowing them to can their prior contractor (who was expensive and not 
nearly as responsive as we would have liked them to be). Not only that, but I 
have produced an in-house application used by all the IT technicians for 
generating professional looking customer forms onsite, as well as revamping all 
our internal forms and standardizing them. 

I could go on singing my own praises, but my point is, the assessment of 
profitability often depends largely on where you decide to plant your flag. I 
think from reading you email, that you might want to consider planting the flag 
a bit further back into your own territory. 

Bob S


> On Jan 3, 2019, at 10:12 , Curry Kenworthy via use-livecode 
>  wrote:
> 
> Likewise, in 2 years LC has required one heck of a lot of refactoring. That 
> may be fine and dandy for people who write loose and sloppy code the first 
> time and love rewriting everything, but it's not quite so cool for 
> responsible, experienced coders who do it right the first time, and build 
> reliable and optimized code to last as a smart value for their clients and 
> customers. If you love retyping, redoing, and refactoring every 2 years, 
> along with multiplied costs, then I totally understand the celebration. 
> Personally I don't love that model. My ideal is just the opposite - smart 
> code that is built to last and already optimized and reasonably well written 
> from the start.


___
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: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Bob:

> This is largely due to unicode support in everything,
> as I understand it.

Nope, I think that was more of a prior assumption going in, and held 
onto despite test results to the contrary, than a conclusion derived 
from testing. :)


Some tests were designed to rule out the effects of text to the maximum 
extent possible, so slowdowns were almost certainly (or if so, should 
not be) the result of unicode. And some text features maintained or 
gained speed despite unicode. So whatever part it played, there's much 
more to the story.


As I say, tests are repeatable; there will be nothing left to difference 
of opinion or chance. I tested an RC of 902 with the same old slow 
results. Soon when I have a chance, I will test 902 final. Whenever an 
LC version comes along with significant improvements, I'll be all over 
it and make the tests extremely public. Not the case so far, we're still 
in the speed limit zone AFAIK!


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

This is largely due to unicode support in everything, as I understand it. This 
performance hit is, I think, completely understandable. But there definitely 
is/was something else going on when developing under Windows. As other threads 
have amply demonstrated, V9 introduced a massive performance hit, and it's my 
understanding that those issues have been somewhat or wholly addressed in 
9.0.2. 

I will be corrected if inaccurate. 

Bob S


> On Jan 3, 2019, at 10:12 , Curry Kenworthy via use-livecode 
>  wrote:
> 
> Objective, repeatable testing has showed that LC 9 is considerably slower 
> than LC 6 in a number of areas. In 2 years, LC has become twice as slow at 
> some basic tasks. This pretty much negates the benefits of Moore's Law (and 
> similar advances driving current and future hardware) and deprives coders and 
> users of what would otherwise be a trend toward (offset a bit by OS 
> flashiness) general 1.x improvement in performance over time. And that's 
> passive gain; any work on code improvements would yield a multiple of 
> performance.


___
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: Refactoring is your friend / moving from 6.x to 9.x

[Mark Waddingham via use-livecode]

On 2019-01-03 12:13, Malte Pfaff-Brill via use-livecode wrote:
It might be that I stand corrected for the behaviour of lock / unlock 
screen.

But then I also stand puzzled on the effect it has between engines.
Same code which redrew the screen within 2.5 seconds on the 5.x series
took 11 secs in 8/9. After debugging libraries. Being used to make
sure that lock screens no longer nested brought this down to 1.5
seconds. Rest of the code left unchanged! I really do not get it. That
said, I am pretty happy with the fact. I only wish I would have
found/tried this earlier.


I wonder if this is combination of one too many unlock screens (so the 
screen wasn't actually locked for the whole process you timed); and 
having a Retina screen...


If so, in 5.x the screen was probably being redrawn when you didn't 
intend also, but it was rendering 1/4 of the number of pixels so took 
1/4 of the time or thereabouts (5.x would have been rendering to a 1/4 
size buffer which was then upscaled by the OS to full-resolution Retina; 
it was only 6.x+ which started to render to a full-retina resolution 
window buffer on retina displays).


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: Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy via use-livecode]

Howdy LiveCoders,

I'm very happy to see people succeeding, optimizing, and coming back and 
LiveCoding. That's heartwarming.


But I'm making one of my rare appearances here, chiming in lest this 
thread end while consisting only of celebrating extra work that was put 
in to overcome slowdowns. To me putting in double work (or 1.x work) to 
achieve the result is not ideal.


Therefore, while I'm very happy people are back on track and "OK" - 
while I share in their relief and renewed optimism - I don't think it 
rises to the level of celebration. Quite the reverse. That would be 
celebrating a model where requiring more work to produce fewer results 
(or repeated work to achieve the same result) is considered a good 
thing. I consider that a bad thing.


Objective, repeatable testing has showed that LC 9 is considerably 
slower than LC 6 in a number of areas. In 2 years, LC has become twice 
as slow at some basic tasks. This pretty much negates the benefits of 
Moore's Law (and similar advances driving current and future hardware) 
and deprives coders and users of what would otherwise be a trend toward 
(offset a bit by OS flashiness) general 1.x improvement in performance 
over time. And that's passive gain; any work on code improvements would 
yield a multiple of performance.


Likewise, in 2 years LC has required one heck of a lot of refactoring. 
That may be fine and dandy for people who write loose and sloppy code 
the first time and love rewriting everything, but it's not quite so cool 
for responsible, experienced coders who do it right the first time, and 
build reliable and optimized code to last as a smart value for their 
clients and customers. If you love retyping, redoing, and refactoring 
every 2 years, along with multiplied costs, then I totally understand 
the celebration. Personally I don't love that model. My ideal is just 
the opposite - smart code that is built to last and already optimized 
and reasonably well written from the start.


Imagine all the hours, dollars, pounds, and euros spent on refactoring 
for 7/8/9 - multiplied by all the projects and clients. It's staggering. 
I'm confident that a good portion of that was avoidable. And STILL the 9 
engine is slow and has more bugs and arbitrary problematic changes than 
it should.


For my own addons, with VERY few exceptions, it has been due to LC's own 
bugs and arbitrary changes when they have broken or had problems. LC 
breaks it, I have to fix it. That's OK now and then, but it's not OK 
when LC gets sloppy, because when it's one person against a team, it 
becomes faster for a team to make a mess and break things than an 
individual to follow behind for clean up and repair. And one of those 
very few exceptions was a slowdown that another person added to my code 
when I permitted them to tweak the project, something I rarely do; I 
write very few bugs myself and that's how I like it. Don't you?


Sometimes I'm slower than ideal in following and repairing the breaks 
with my own updates, but it's a team vs one situation, updates go 
through a process, and the "one" is not the one doing the breaking. (Hi 
Klaus, old buddy old pal.) More updates are close, BTW - I have a little 
less extra steam for updates after my regular client work during winter, 
but it'll pick up again in the spring.


How much time and money have you put into your own 7-9 refactoring and 
debugging? Minus your bad code, of course. (If you're thinking "it all 
needed refactoring anyway" that's not proving your point, it's proving 
you were very naughty when coding.) :) For any code riding on top of 
another layer, as ours does, it makes sense to minimize engine and 
syntax breaks as much as reasonably possible. Otherwise some of the 
advantages of the layered environment are lost. There will be some 
breaks over time with generational improvements, but we're way over the 
ideal. And a steady loss of performance over time is just not a good 
thing in any possible universe. (Well, maybe a universe with inverse 
physics.)


Can we survive with this model? Heck yeah. Here we are, at least a good 
number of us. Was it ideal? Not in your wildest dreams. Here I must note 
that we have a lot of bad examples from the big industry players. They 
are taking planned obsolescence to extremes to make big bucks, in 
software as well as hardware. They don't mind if you have to pay N times 
(or work a reasonable amount of hours multipled by N extra times) to 
achieve the same results. They love your money more than they love YOU 
the person. I'm the opposite. I care about YOU - all of you, LC Ltd and 
the entire community.


So when people are frustrated and depressed and give up and then come 
back and try again and put in some renewed time and energy, I get it. 
I'm happy too. But I'm locally happy, for them as an individual, not 
globally happy for us as a community. Because this is inefficient. I'm 
not a very emotional person. I don't get depressed and give up and t

Re: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

I'm curious if issuing a new screen lock inadvertently and for an instant 
unlocks the screen and a redraw happens? Not the desired effect obviously but 
that would explain things somewhat. 

Bob S


> On Jan 3, 2019, at 03:13 , Malte Pfaff-Brill via use-livecode 
>  wrote:
> 
> It might be that I stand corrected for the behaviour of lock / unlock screen.
> But then I also stand puzzled on the effect it has between engines. Same code 
> which redrew the screen within 2.5 seconds on the 5.x series took 11 secs in 
> 8/9. After debugging libraries. Being used to make sure that lock screens no 
> longer nested brought this down to 1.5 seconds. Rest of the code left 
> unchanged! I really do not get it. That said, I am pretty happy with the 
> fact. I only wish I would have found/tried this earlier.


___
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: Refactoring is your friend / moving from 6.x to 9.x

[Malte Pfaff-Brill via use-livecode]

It might be that I stand corrected for the behaviour of lock / unlock screen.
But then I also stand puzzled on the effect it has between engines. Same code 
which redrew the screen within 2.5 seconds on the 5.x series took 11 secs in 
8/9. After debugging libraries. Being used to make sure that lock screens no 
longer nested brought this down to 1.5 seconds. Rest of the code left 
unchanged! I really do not get it. That said, I am pretty happy with the fact. 
I only wish I would have found/tried this earlier.

Regarding strictness of the parser, I am actually quite glad that the parser is 
less forgiving nowadays. :-) Have been working in strict compile mode for ages 
and this has saved me from shooting my own foot numerous times.
Thank you all for your input on this. If anyone of you has any more gotchas to 
look out for I am most interested to learn. :-)

Cheers,

Malte
___
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: Refactoring is your friend / moving from 6.x to 9.x

[Kay C Lan via use-livecode]

On Mon, Dec 31, 2018 at 9:17 AM Mark Wieder via use-livecode
 wrote:
>
> Yes, it is definitely a change in behavior.
I want to strongly disagree with your conclusion here ;-)
>
> This isn't the only place where the dictionary is wrong.

My 9.0.2 Dictionary quite clearly states for the property 'lockScreen'
that it was introduced and hasn't changed since version 1.0.  Which
means, as Craig said, it's exactly the same as it was in HC. The
Dictionary also clearly states:

"LiveCode keeps count of how many times the screen has been locked.
You must balance each unlock with a lock; if you lock the screen twice
and then unlock it once, the screen remains locked."

Yes it is unfortunate that that important statement doesn't appear in
the other relevant lock screen and unlock screen entries.

I'm with Herman, learnt a long long time ago to use a simple if
statement to keep the lockScreen count to 1.

___
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: Refactoring is your friend / moving from 6.x to 9.x

[J. Landman Gay via use-livecode]

I first saw this loop in a script by Brett Sher, who called it
"unlockReally", so you're close. :)

(I accidentally put this response in the wrong thread at first where it 
doesn't make any sense, sorry about that.)

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 2, 2019 5:26:11 AM Andre Garzia via use-livecode 
 wrote:



That loop is briliant. I am tempted to place it into a command called
"unlockScreenForReal"

On Mon, Dec 31, 2018, 16:38 dunbarxx via use-livecode <
use-livecode@lists.runrev.com wrote:


Not sure if this is still relevant in LC, but in HC, lock screen commands
were queued. So the fix, so that one did not have to count the number of
locks through perhaps several handlers, was:

repeat until the lockScreen is false
unlock screen
end repeat

Craig



--
Sent from:
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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: Refactoring is your friend / moving from 6.x to 9.x

[J. Landman Gay via use-livecode]

I first saw this loop in a script by Brett Sher, who called it 
"unlockReally", so you're close. :)

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 2, 2019 5:26:09 AM Andre Garzia via use-livecode 
 wrote:



That loop is briliant. I am tempted to place it into a command called
"unlockScreenForReal"

On Mon, Dec 31, 2018, 16:38 dunbarxx via use-livecode <
use-livecode@lists.runrev.com wrote:


Not sure if this is still relevant in LC, but in HC, lock screen commands
were queued. So the fix, so that one did not have to count the number of
locks through perhaps several handlers, was:

repeat until the lockScreen is false
unlock screen
end repeat

Craig



--
Sent from:
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

only sqLite. 

Bob S


> On Dec 31, 2018, at 13:32 , J. Landman Gay via use-livecode 
>  wrote:
> 
> I'm generally deficient when it comes to databases but curious how one 
> creates a memory based one. Is there a trick, and does it work with others 
> besides sql?
> 
> This is probably a newbie question.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On December 31, 2018 11:31:15 AM Bob Sneidar via use-livecode 
>  wrote:
> 
> 


___
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: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

put revOpenDatabase("sqlite",":memory:") into tDBID

Bob S


> On Dec 31, 2018, at 13:32 , J. Landman Gay via use-livecode 
>  wrote:
> 
> I'm generally deficient when it comes to databases but curious how one 
> creates a memory based one. Is there a trick, and does it work with others 
> besides sql?
> 
> This is probably a newbie question.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On December 31, 2018 11:31:15 AM Bob Sneidar via use-livecode 
>  wrote:
> 
> 


___
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: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

What if you accidentally use the wrong name reference, then want to change it? 

Bob S


> On Dec 31, 2018, at 10:38 , Geoff Canyon via use-livecode 
>  wrote:
> 
>> I wish we had better refactoring tools
>> so that we could rename a handler and all code that called that handler
>> was fixed, or stuff such as rename variable...
>> 
> 
> One of the reasons I like experimenting with different environments is to
> see what advantages they have. One advantage that FileMaker Pro has had for
> 25 years, is that all references to tables, fields, and layouts, are based
> on underlying unique IDs. Meaning that if you rename something, the
> underlying reference ID doesn't change, and anywhere the reference occurs,
> the name change is reflected automatically. Obviously this would require
> significant effort to work in any text-file-based system, but it has always
> amazed me that I have never seen this feature replicated elsewhere.


___
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: Refactoring is your friend / moving from 6.x to 9.x

[Ali Lloyd via use-livecode]

> Is there a way to "safely" add to LC contextual menu in the script editor?

Yes! It is in a script-only stack behavior of the editor field:
https://github.com/livecode/livecode-ide/blob/develop/Toolset/palettes/script%20editor/behaviors/revseeditorbehavior.livecodescript#L1024

There is also the script editor's menu bar code in a script only stack:
https://github.com/livecode/livecode-ide/blob/develop/Toolset/palettes/script%20editor/behaviors/revsemenubarbehavior.livecodescript

On Wed, Jan 2, 2019 at 11:34 AM Andre Garzia via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Bob,
>
> Yes but it is not as ergonomic. Let me tell an example from a different
> platform. I was working in WebStorm IDE in a JavaScript project. I was
> refactoring a ton of it.
>
> One of the functions worked better with a different parameter order than
> what I originally used. I could select the function declaration, use the
> refactor contextual menu, use "change signature" and alter the param order.
> The IDE then made sure that all code that called that function was changed
> to support the new order automatically.
>
> There was a piece of code inside a function that was useful elsewhere.
> Click refactor, select "extract to new function", fill the new function
> name. It creates a new function and place a call to that function in the
> original place where it was.
>
> These are just two examples. Those refactor tools go much deeper than that.
> It makes it easy and even fun to rework your code.
>
> It would be hard to have the same power in LC because LC is more dynamic
> than JS in terms of scope and what is available. JS modern IDEs maintain an
> AST in memory for your software so that when you refactor, they can locate
> and fix the side effects of your changes. It is more powerful and flexible
> than text replacements because the IDEs actually understand the code
> through having their own parser and stuff.
>
> Buut some of it could be done in LC with simple text replacement based
> tools.
>
> Is there a way to "safely" add to LC contextual menu in the script editor?
>
> On Mon, Dec 31, 2018, 17:33 Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com wrote:
>
> > Find/Replace works great. I've done it a few times, so long as the thing
> > you are finding has a unique name that cannot be a part of any other bit
> of
> > code, you should be fine. Backup your stack of course before doing
> > something so drastic.
> >
> > A while ago, the LC dev team optimized the search engine so that it is
> > orders of magnitude faster.
> >
> > Bob S
> >
> >
> > > On Dec 30, 2018, at 11:57 , Andre Alves Garzia via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> > >
> > > Malte,
> > >
> > > So happy that you're back here my friend. I too spent some time away.
> > >
> > > So, refactoring and constantly trying to erase mistakes of my past
> > coding self are a constant here. I wish we had better refactoring tools
> so
> > that we could rename a handler and all code that called that handler was
> > fixed, or stuff such as rename variable...
> > >
> > > Cheers
> > >
> > > andre
> >
> >
> > ___
> > 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: Refactoring is your friend / moving from 6.x to 9.x

[Andre Garzia via use-livecode]

Bob,

Yes but it is not as ergonomic. Let me tell an example from a different
platform. I was working in WebStorm IDE in a JavaScript project. I was
refactoring a ton of it.

One of the functions worked better with a different parameter order than
what I originally used. I could select the function declaration, use the
refactor contextual menu, use "change signature" and alter the param order.
The IDE then made sure that all code that called that function was changed
to support the new order automatically.

There was a piece of code inside a function that was useful elsewhere.
Click refactor, select "extract to new function", fill the new function
name. It creates a new function and place a call to that function in the
original place where it was.

These are just two examples. Those refactor tools go much deeper than that.
It makes it easy and even fun to rework your code.

It would be hard to have the same power in LC because LC is more dynamic
than JS in terms of scope and what is available. JS modern IDEs maintain an
AST in memory for your software so that when you refactor, they can locate
and fix the side effects of your changes. It is more powerful and flexible
than text replacements because the IDEs actually understand the code
through having their own parser and stuff.

Buut some of it could be done in LC with simple text replacement based
tools.

Is there a way to "safely" add to LC contextual menu in the script editor?

On Mon, Dec 31, 2018, 17:33 Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com wrote:

> Find/Replace works great. I've done it a few times, so long as the thing
> you are finding has a unique name that cannot be a part of any other bit of
> code, you should be fine. Backup your stack of course before doing
> something so drastic.
>
> A while ago, the LC dev team optimized the search engine so that it is
> orders of magnitude faster.
>
> Bob S
>
>
> > On Dec 30, 2018, at 11:57 , Andre Alves Garzia via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Malte,
> >
> > So happy that you're back here my friend. I too spent some time away.
> >
> > So, refactoring and constantly trying to erase mistakes of my past
> coding self are a constant here. I wish we had better refactoring tools so
> that we could rename a handler and all code that called that handler was
> fixed, or stuff such as rename variable...
> >
> > Cheers
> >
> > andre
>
>
> ___
> 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: Refactoring is your friend / moving from 6.x to 9.x

[Andre Garzia via use-livecode]

That loop is briliant. I am tempted to place it into a command called
"unlockScreenForReal"

On Mon, Dec 31, 2018, 16:38 dunbarxx via use-livecode <
use-livecode@lists.runrev.com wrote:

> Not sure if this is still relevant in LC, but in HC, lock screen commands
> were queued. So the fix, so that one did not have to count the number of
> locks through perhaps several handlers, was:
>
> repeat until the lockScreen is false
>   unlock screen
> end repeat
>
> Craig
>
>
>
> --
> Sent from:
> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
>
> ___
> 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: Refactoring is your friend / moving from 6.x to 9.x

[Paul Hibbert via use-livecode]

Malte,

I think the info you were probably looking for is buried within the dictionary 
entry for the “lockScreen” Property, maybe this should be referenced a little 
better in the dictionary entries for “lock screen” and “unlock screen”, see 
below:

LiveCode keeps count of how many times the screen has been locked. You must 
balance each unlock with a lock; if you lock the screen twice and then unlock 
it once, the screen remains locked. For example, the following pair of handlers 
draws everything while the display is still locked:

on mouseUp
lock screen-- first lock
drawStuff  -- gets locked again and unlocked in drawStuff
show image "Sprite"
unlock screen  -- now unlocked - 2 locks balanced by 2 unlocks
end mouseUp

on drawStuff
lock screen-- screen now locked twice
show field "Notify"
unlock screen  -- not unlocked yet - locked twice, unlocked once
end drawStuff

Paul

> On Dec 30, 2018, at 13:55, Malte Pfaff-Brill via use-livecode 
>  wrote:
> 
> Hey Mark,
> 
> At least it is behaviour that changed between engine releases. :-)
> Thinking of a counter here is a good way to describe the behaviour, however, 
> it is not what is written in the dictionary.
> 
> 
> "unlock screen
> 
> Sets the lockScreen property to false, updating the screen and displaying any 
> changes made since the screen was locked.“
> 
> If unlock screen sets a property, the expectation would be to take effect as 
> soon as one unlock screen is issued, as a property can only have one state. 
> Nesting is not described in the dictionary. Not that I can not live with the 
> change, that is not my point 
> ___
> 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: Refactoring is your friend / moving from 6.x to 9.x

[Peter Bogdanoff via use-livecode]

Is what you mean by creating a memory database as covered in this tutorial?

http://lessons.livecode.com/m/4069/l/565718-how-to-create-and-use-an-sqlite-database
 
<http://lessons.livecode.com/m/4069/l/565718-how-to-create-and-use-an-sqlite-database>

Peter


> On Dec 31, 2018, at 5:16 PM, Ralph DiMola via use-livecode 
>  wrote:
> 
> A SQLite memory database is the same as a SQLite file database except it's
> created for just the instance that app is running. You have to create
> table(s) and field(s) for those table(s). Then the app then populates the
> data and queries it. SQLite memory database supports the same SQL syntax as
> a file based SQLite database. When opening an SQLite database if you don't
> supply a file spec then it's created in memory( I think that ":memory:" for
> the file spec also works). If you supply a file spec and the db does not
> exist then an empty one is created just like a memory database. Of course a
> memory database is faster than a disk based database. I find that SQL
> invaluable for dealing with complex data relationships.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
> Of J. Landman Gay via use-livecode
> Sent: Monday, December 31, 2018 4:32 PM
> To: How to use LiveCode
> Cc: J. Landman Gay
> Subject: Re: Refactoring is your friend / moving from 6.x to 9.x
> 
> I'm generally deficient when it comes to databases but curious how one
> creates a memory based one. Is there a trick, and does it work with others
> besides sql?
> 
> This is probably a newbie question.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software |
> http://www.hyperactivesw.com On December 31, 2018 11:31:15 AM Bob Sneidar
> via use-livecode  wrote:
> 
>> For multiple recursions into an array I came up with a method for 
>> loading an array into a memory based sql database. Subsequent queries 
>> take less time, depending of course on how complex they are, but you 
>> can do lots of cool thinks, like complex filtering / sorts, 
>> calculations, etc. to a cursor, then I have a function that converts a
> cursor to an array.
>> 
>> I originally used it to get the topmost, leftmost, bottommost and 
>> rightmost objects on a card that were visible by using min and max 
>> queries on a list of the objects. But of course the method can be expanded
> to do almost anything.
>> 
>> Bob S
>> 
>> 
>>> On Dec 30, 2018, at 11:33 , Malte Pfaff-Brill via use-livecode 
>>>  wrote:
>>> 
>>> Not yet fixable for me:
>>> Array operations on larger data sets still slower than they were
>>> 
>>> Non engine related:
>>> My SQL-Fu has improved a bit ;-) Quite a bit of performance to gain
> there.
>>> 
>>> Did anybody of you happen to refactor old code and if so, do you have 
>>> any observations you might want to share?
>>> 
>>> Cheers,
>>> 
>>> Malte
>> 
>> 
>> ___
>> 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

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Ralph DiMola via use-livecode]

A SQLite memory database is the same as a SQLite file database except it's
created for just the instance that app is running. You have to create
table(s) and field(s) for those table(s). Then the app then populates the
data and queries it. SQLite memory database supports the same SQL syntax as
a file based SQLite database. When opening an SQLite database if you don't
supply a file spec then it's created in memory( I think that ":memory:" for
the file spec also works). If you supply a file spec and the db does not
exist then an empty one is created just like a memory database. Of course a
memory database is faster than a disk based database. I find that SQL
invaluable for dealing with complex data relationships.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay via use-livecode
Sent: Monday, December 31, 2018 4:32 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: Refactoring is your friend / moving from 6.x to 9.x

I'm generally deficient when it comes to databases but curious how one
creates a memory based one. Is there a trick, and does it work with others
besides sql?

This is probably a newbie question.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software |
http://www.hyperactivesw.com On December 31, 2018 11:31:15 AM Bob Sneidar
via use-livecode  wrote:

> For multiple recursions into an array I came up with a method for 
> loading an array into a memory based sql database. Subsequent queries 
> take less time, depending of course on how complex they are, but you 
> can do lots of cool thinks, like complex filtering / sorts, 
> calculations, etc. to a cursor, then I have a function that converts a
cursor to an array.
>
> I originally used it to get the topmost, leftmost, bottommost and 
> rightmost objects on a card that were visible by using min and max 
> queries on a list of the objects. But of course the method can be expanded
to do almost anything.
>
> Bob S
>
>
>> On Dec 30, 2018, at 11:33 , Malte Pfaff-Brill via use-livecode 
>>  wrote:
>>
>> Not yet fixable for me:
>> Array operations on larger data sets still slower than they were
>>
>> Non engine related:
>> My SQL-Fu has improved a bit ;-) Quite a bit of performance to gain
there.
>>
>> Did anybody of you happen to refactor old code and if so, do you have 
>> any observations you might want to share?
>>
>> Cheers,
>>
>> Malte
>
>
> ___
> 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: Refactoring is your friend / moving from 6.x to 9.x

[J. Landman Gay via use-livecode]

I'm generally deficient when it comes to databases but curious how one 
creates a memory based one. Is there a trick, and does it work with others 
besides sql?


This is probably a newbie question.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 31, 2018 11:31:15 AM Bob Sneidar via use-livecode 
 wrote:


For multiple recursions into an array I came up with a method for loading 
an array into a memory based sql database. Subsequent queries take less 
time, depending of course on how complex they are, but you can do lots of 
cool thinks, like complex filtering / sorts, calculations, etc. to a 
cursor, then I have a function that converts a cursor to an array.


I originally used it to get the topmost, leftmost, bottommost and rightmost 
objects on a card that were visible by using min and max queries on a list 
of the objects. But of course the method can be expanded to do almost anything.


Bob S


On Dec 30, 2018, at 11:33 , Malte Pfaff-Brill via use-livecode 
 wrote:


Not yet fixable for me:
Array operations on larger data sets still slower than they were

Non engine related:
My SQL-Fu has improved a bit ;-) Quite a bit of performance to gain there.

Did anybody of you happen to refactor old code and if so, do you have any 
observations you might want to share?


Cheers,

Malte



___
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: Refactoring is your friend / moving from 6.x to 9.x

[Mark Wieder via use-livecode]

On 12/30/18 8:52 PM, Tom Glod via use-livecode wrote:


 and definitely had a couple of "how did this code ever work?" moments

...heh...been there...

--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Geoff Canyon via use-livecode]

On Sun, Dec 30, 2018 at 11:58 AM Andre Alves Garzia via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I wish we had better refactoring tools
> so that we could rename a handler and all code that called that handler
> was fixed, or stuff such as rename variable...
>

One of the reasons I like experimenting with different environments is to
see what advantages they have. One advantage that FileMaker Pro has had for
25 years, is that all references to tables, fields, and layouts, are based
on underlying unique IDs. Meaning that if you rename something, the
underlying reference ID doesn't change, and anywhere the reference occurs,
the name change is reflected automatically. Obviously this would require
significant effort to work in any text-file-based system, but it has always
amazed me that I have never seen this feature replicated elsewhere.
___
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: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

Find/Replace works great. I've done it a few times, so long as the thing you 
are finding has a unique name that cannot be a part of any other bit of code, 
you should be fine. Backup your stack of course before doing something so 
drastic. 

A while ago, the LC dev team optimized the search engine so that it is orders 
of magnitude faster. 

Bob S
 

> On Dec 30, 2018, at 11:57 , Andre Alves Garzia via use-livecode 
>  wrote:
> 
> Malte,
> 
> So happy that you're back here my friend. I too spent some time away.
> 
> So, refactoring and constantly trying to erase mistakes of my past coding 
> self are a constant here. I wish we had better refactoring tools so that we 
> could rename a handler and all code that called that handler was fixed, or 
> stuff such as rename variable...
> 
> Cheers
> 
> andre


___
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: Refactoring is your friend / moving from 6.x to 9.x

[Bob Sneidar via use-livecode]

For multiple recursions into an array I came up with a method for loading an 
array into a memory based sql database. Subsequent queries take less time, 
depending of course on how complex they are, but you can do lots of cool 
thinks, like complex filtering / sorts, calculations, etc. to a cursor, then I 
have a function that converts a cursor to an array. 

I originally used it to get the topmost, leftmost, bottommost and rightmost 
objects on a card that were visible by using min and max queries on a list of 
the objects. But of course the method can be expanded to do almost anything. 

Bob S


> On Dec 30, 2018, at 11:33 , Malte Pfaff-Brill via use-livecode 
>  wrote:
> 
> Not yet fixable for me:
> Array operations on larger data sets still slower than they were
> 
> Non engine related:
> My SQL-Fu has improved a bit ;-) Quite a bit of performance to gain there.
> 
> Did anybody of you happen to refactor old code and if so, do you have any 
> observations you might want to share?
> 
> Cheers,
> 
> Malte


___
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: Refactoring is your friend / moving from 6.x to 9.x

[hh via use-livecode]

> Craig wrote:
> Not sure if this is still relevant in LC, but in HC, lock screen
> commands were queued. So the fix, so that one did not have to count
> the number of locks through perhaps several handlers, was:
> 
> repeat until the lockScreen is false
>unlock screen
> end repeat

Yes! Or lock only once:

if not the lockScreen then lock screen

___
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: Refactoring is your friend / moving from 6.x to 9.x

[dunbarxx via use-livecode]

Not sure if this is still relevant in LC, but in HC, lock screen commands
were queued. So the fix, so that one did not have to count the number of
locks through perhaps several handlers, was:

repeat until the lockScreen is false
  unlock screen
end repeat

Craig



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Geoff Canyon via use-livecode]

In 6.7.3 on a Mac, this results in true for me.
Checked in 5.0, also resulted in true.

On Sun, Dec 30, 2018 at 1:26 PM Malte Pfaff-Brill via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Regarding lock screen, here is one simple example:
>
> on mouseUp
> lock screen
> subhandler
> unlock screen
> answer the lockscreen
> end mouseUp
>
>
> on subhandler
> lock screen
> — other stuff may follow, but do not unlock
> end subhandler
>
> My expectation in the answer would be „false“, but guess what. :-)
___
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: Refactoring is your friend / moving from 6.x to 9.x

[Tom Glod via use-livecode]

a very interesting thread ...lots to learn.

I refactored a project from 7 to 9  and definitely had a couple of "how
did this code ever work?" moments, meaning i found the most recent versions
of the engine to be more strict with syntax.

As far as performance comparisons I don't have a lot to add, for me LC has
always been performant enough for the most part.   When I hear about
possible future optimizations I am thrilled to think my software will be
that much more performant.

When something is slow I often just blame my computer. lol but populating
fields seems something that has gotten a lot slower. so I've had to
work around it a bit.  (built my handler to not put more text into a field
than what is visible, solved my particular problem, but not a universal
solution.)

These kinds of threads are gold mines.  Thanks to all.








On Sun, Dec 30, 2018 at 6:40 PM Ralph DiMola via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Task: Add ellipses if text does not fit visible field width.
>
> V4, v5 and v6 I put the data into the field and then looped thru the lines.
> If text was too wide I chopped off 1/2 of the overflow chars(rough guess)
> and then iterated what was left using the formattedwidth as the last chars
> were deleted with the added ellipses to see if it's all visible.
>
> Simple enough but as 7, 8, 9 were released this became very slow. On
> Android
> device using v9 a list 200-300 hundred lines long(only 25 visible) took
> about 6 seconds to render with the screen locked. I never timed it but it
> seemed like the time increased exponentially as the list grew.
>
> Refactor:
> 1) Insert the field text/styles using a pre-loaded styledText array
> 2) Calculating the ellipses in that array using the measureText function.
> Now the same list took about 1.5 seconds. That's about 4 times faster and
> the seems that the time is more linier as the list grows.
>
> That begs 2 questions for me(at least)
> 1) A charAtPixel function in the engine would make the adding ellipses much
> faster.
> 2) When operating on a field that was hidden, screen locked or you just
> don't care if you see delayed changes Have the field object only
> operate
> on an internal styledText array and only start the "go down the hall, into
> a
> room, open the closet... as Richard's prose said" when you want to render
> the field on the screen. Now there may be times for reasons I can't think
> of
> right now that the internal styledText array might need to be flushed to
> the
> field before the field is visible or the screen is unlocked.
>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
>
>
> ___
> 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: Refactoring is your friend / moving from 6.x to 9.x

[Ralph DiMola via use-livecode]

Task: Add ellipses if text does not fit visible field width.

V4, v5 and v6 I put the data into the field and then looped thru the lines.
If text was too wide I chopped off 1/2 of the overflow chars(rough guess)
and then iterated what was left using the formattedwidth as the last chars
were deleted with the added ellipses to see if it's all visible.

Simple enough but as 7, 8, 9 were released this became very slow. On Android
device using v9 a list 200-300 hundred lines long(only 25 visible) took
about 6 seconds to render with the screen locked. I never timed it but it
seemed like the time increased exponentially as the list grew.

Refactor:
1) Insert the field text/styles using a pre-loaded styledText array
2) Calculating the ellipses in that array using the measureText function.
Now the same list took about 1.5 seconds. That's about 4 times faster and
the seems that the time is more linier as the list grows.

That begs 2 questions for me(at least)
1) A charAtPixel function in the engine would make the adding ellipses much
faster.
2) When operating on a field that was hidden, screen locked or you just
don't care if you see delayed changes Have the field object only operate
on an internal styledText array and only start the "go down the hall, into a
room, open the closet... as Richard's prose said" when you want to render
the field on the screen. Now there may be times for reasons I can't think of
right now that the internal styledText array might need to be flushed to the
field before the field is visible or the screen is unlocked.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


___
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: Refactoring is your friend / moving from 6.x to 9.x

[Mark Wieder via use-livecode]

On 12/30/18 1:55 PM, Malte Pfaff-Brill via use-livecode wrote:

Hey Mark,

At least it is behaviour that changed between engine releases. :-)
Thinking of a counter here is a good way to describe the behaviour, however, it 
is not what is written in the dictionary.


Yes, it is definitely a change in behavior. I'm fairly certain it's in a 
release note somewhere along the way, although I can't find it, so I'm 
not sure where I learned it.


This isn't the only place where the dictionary is wrong. Back in the day 
we used to be able to add user notes to the dictionary to take care of 
things like this.


--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Malte Pfaff-Brill via use-livecode]

Hey Mark,

At least it is behaviour that changed between engine releases. :-)
Thinking of a counter here is a good way to describe the behaviour, however, it 
is not what is written in the dictionary.


"unlock screen

Sets the lockScreen property to false, updating the screen and displaying any 
changes made since the screen was locked.“

If unlock screen sets a property, the expectation would be to take effect as 
soon as one unlock screen is issued, as a property can only have one state. 
Nesting is not described in the dictionary. Not that I can not live with the 
change, that is not my point 
___
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: Refactoring is your friend / moving from 6.x to 9.x

[Mark Wieder via use-livecode]

On 12/30/18 1:25 PM, Malte Pfaff-Brill via use-livecode wrote:

Hi Kaveh,

Thanks for the kind words. :-)

Regarding lock screen, here is one simple example:

on mouseUp
lock screen
subhandler
unlock screen
answer the lockscreen
end mouseUp


on subhandler
lock screen
— other stuff may follow, but do not unlock
end subhandler

My expectation in the answer would be „false“, but guess what. :-)
Regarding screen not being immediately released, I am not down to the cause 
yet. App is complex (multi group / people calendar)


I want to strongly disagree with your conclusion here.

Locking and unlocking the screen is a matter of counting when it comes 
to nesting. In your example, the mouseUp handler increments the count to 
1, then the subhandler increases it to 2, and finally the mouseUp 
handler decrements the count with the unlock command. That still leaves 
the lock counter nonzero, so the screen is still locked.


A more correct approach would be to unlock the screen at the end of the 
subhandler, i.e., lock the screen when you need it locked, then unlock 
it *in the same handler* when you're done needing it locked. I nest lock 
and unlock commands all the time, and it's second nature now to pair 
them the same way I pair if/end if, repeat/end repeat, etc.


--
 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: Refactoring is your friend / moving from 6.x to 9.x

[Malte Pfaff-Brill via use-livecode]

Hi Kaveh,

Thanks for the kind words. :-)

Regarding lock screen, here is one simple example:

on mouseUp
lock screen
subhandler
unlock screen
answer the lockscreen
end mouseUp


on subhandler
lock screen
— other stuff may follow, but do not unlock
end subhandler

My expectation in the answer would be „false“, but guess what. :-)
Regarding screen not being immediately released, I am not down to the cause 
yet. App is complex (multi group / people calendar)

Cheers,

Malte


___
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: Refactoring is your friend / moving from 6.x to 9.x

[Kaveh Bazargan via use-livecode]

I don't think LiveCode without Malte is really LiveCode, so glad you are
back. :-)

Could you pls elaborate on the lock screen strategy? You said we should not
nest, and you also said that screen will not immediately be unlocked after
a handler. I was under the impression that multiple locks were not a
problem (e.g. one handler locks, then calls another that also locks). Then
when the main handler is done, screen is released. Any more info on that
would be appreciated.

Regards
Kaveh

On Sun, 30 Dec 2018 at 19:58, Andre Alves Garzia via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Malte,
>
> So happy that you're back here my friend. I too spent some time away.
>
> So, refactoring and constantly trying to erase mistakes of my past
> coding self are a constant here. I wish we had better refactoring tools
> so that we could rename a handler and all code that called that handler
> was fixed, or stuff such as rename variable...
>
> Cheers
>
> andre
>
> On 30/12/2018 19:33, Malte Pfaff-Brill via use-livecode wrote:
> > Hi list,
> >
> > I finally found the time to test / move one of my old projects from the
> 6.x (started in 3.x) to the 9.x engine. At first I was very very
> disappointed about performance. The stack was somewhat between acceptable
> and snappy in the 6.x engine series, rather unusable on 8 and on 9. This
> basically led to so much frustration that I basically gave up on the
> project, coding and LiveCode as a whole.
> >
> > I had a bit of time on my own during the holidays, so I started to
> analyse where the slowdowns actually happened. It seems I do owe the 9.x
> engine an apology, expecting everything to work as it used to in 6 is not
> the way I should have gone. After a refactor of my scripts I am now sitting
> with a version of my stack that works faster as it did in 5.x / 6.x.
> >
> > General and fixable observations:
> >
> > The IDE spams a lot of IDE only messages when creating many objects by
> script -> remedy: Lock messages
> > Nested Lock screens are a big "NO-NO“ nowadays
> > You can not rely on the screen being unlocked immediately at the end of
> a handler
> >
> > Not yet fixable for me:
> > Array operations on larger data sets still slower than they were
> >
> > Non engine related:
> > My SQL-Fu has improved a bit ;-) Quite a bit of performance to gain
> there.
> >
> > Did anybody of you happen to refactor old code and if so, do you have
> any observations you might want to share?
> >
> > Cheers,
> >
> > Malte
> >
> >
> >
> > ___
> > 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



-- 
Kaveh Bazargan
Director
River Valley Technologies  • Twitter
 • LinkedIn

___
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: Refactoring is your friend / moving from 6.x to 9.x

[Andre Alves Garzia via use-livecode]

Malte,

So happy that you're back here my friend. I too spent some time away.

So, refactoring and constantly trying to erase mistakes of my past 
coding self are a constant here. I wish we had better refactoring tools 
so that we could rename a handler and all code that called that handler 
was fixed, or stuff such as rename variable...


Cheers

andre

On 30/12/2018 19:33, Malte Pfaff-Brill via use-livecode wrote:

Hi list,

I finally found the time to test / move one of my old projects from the 6.x 
(started in 3.x) to the 9.x engine. At first I was very very disappointed about 
performance. The stack was somewhat between acceptable and snappy in the 6.x 
engine series, rather unusable on 8 and on 9. This basically led to so much 
frustration that I basically gave up on the project, coding and LiveCode as a 
whole.

I had a bit of time on my own during the holidays, so I started to analyse 
where the slowdowns actually happened. It seems I do owe the 9.x engine an 
apology, expecting everything to work as it used to in 6 is not the way I 
should have gone. After a refactor of my scripts I am now sitting with a 
version of my stack that works faster as it did in 5.x / 6.x.

General and fixable observations:

The IDE spams a lot of IDE only messages when creating many objects by script 
-> remedy: Lock messages
Nested Lock screens are a big "NO-NO“ nowadays
You can not rely on the screen being unlocked immediately at the end of a 
handler

Not yet fixable for me:
Array operations on larger data sets still slower than they were

Non engine related:
My SQL-Fu has improved a bit ;-) Quite a bit of performance to gain there.

Did anybody of you happen to refactor old code and if so, do you have any 
observations you might want to share?

Cheers,

Malte



___
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

Refactoring is your friend / moving from 6.x to 9.x

[Malte Pfaff-Brill via use-livecode]

Hi list,

I finally found the time to test / move one of my old projects from the 6.x 
(started in 3.x) to the 9.x engine. At first I was very very disappointed about 
performance. The stack was somewhat between acceptable and snappy in the 6.x 
engine series, rather unusable on 8 and on 9. This basically led to so much 
frustration that I basically gave up on the project, coding and LiveCode as a 
whole. 

I had a bit of time on my own during the holidays, so I started to analyse 
where the slowdowns actually happened. It seems I do owe the 9.x engine an 
apology, expecting everything to work as it used to in 6 is not the way I 
should have gone. After a refactor of my scripts I am now sitting with a 
version of my stack that works faster as it did in 5.x / 6.x.

General and fixable observations:

The IDE spams a lot of IDE only messages when creating many objects by script 
-> remedy: Lock messages
Nested Lock screens are a big "NO-NO“ nowadays
You can not rely on the screen being unlocked immediately at the end of a 
handler

Not yet fixable for me:
Array operations on larger data sets still slower than they were

Non engine related:
My SQL-Fu has improved a bit ;-) Quite a bit of performance to gain there.

Did anybody of you happen to refactor old code and if so, do you have any 
observations you might want to share?

Cheers,

Malte



___
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