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

Re: Musings on Architect, MVC, Nested Behaviors

[Andre Alves Garzia via use-livecode]

Be aware that YAML is tricky to parse, there are better formats such as 
TOML which are much easier and tend to be less error prone. It is very 
easy to get some indentation wrong in YAML and move something up or down 
a level. TOML is IMHO a better format for such stuff.


  YAML: http://yaml.org

  TOML: https://github.com/toml-lang/toml

There is also StrictYAML which removes some problematic features from 
YAML. Anyway, I think that if all you need is something that maps to a 
hashmap that is not too deep (thats important) then TOML is a better format.


On 28/12/2018 18:00, Richard Gaskin via use-livecode wrote:

Sannyasin Brahmanathaswami wrote:
> @ y'all about revision control of  binary stacks and YAML properities
> (front matter) for text only scripts.. cool musings! but they might
> want/need different threads?

One of your team members requested extending the format of script-only 
stacks specifically to support your project's goals.


YAML is a notation for expressing name-value pairs in a format 
optimized for human writing, something we LC fans like in a language.  
It would seem to lend itself well to the request made here in support 
of your work.


Not at all my intention to hijack your thread by exploring that option 
further to see if we can arrive at an actionable plan.  On the 
contrary, it is in direct support of pursuing solutions specific to 
your needs.


We could rename this part of the discussion, but since it involves 
nested behaviors, MVC, and architecture, and is occurring for the 
purpose of helping your work, if we did so you might miss something 
useful for 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