Wait, the problem, and why it is important to solve

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Wait, the problem, and why it is important to solve

J. Landman Gay via use-livecode
So LiveCode has long has this feature called 'wait' - it is one of those
seemingly innocuous things which, from the surface seems simple (it
allows you to wait for something - it's great when syntax is aptly
named!) however it is perhaps one of the deepest language features we
have.

I think there is some confusion (or puzzlement) as to why I am a little
hung up on it because, on the whole, the 'wait' command is not actually
seen in script that much. Certainly it is part of some people's coding
style (the one thing I love about LiveCode is that it promotes a very
pluralistic style to solving programming problems), but on the whole
many of us rarely if ever use it. Well, we *think* we don't use it.

The thing is that 'wait' is such an important feature to LiveCode that
many pieces of syntax use it without you knowing! The pure mathematician
in my likes classifying and counting things (hey its what we do!), so
here is a reasonably complete list of the places the engine uses it
(this list is alphabetic by source-file in the engine order):

    - it is used to provide the flash of the menu when a menu accelerator
key is pressed

    - it is used to wait for uses of shell() to send back any data so it
can be accumulated for return

    - it is used to wait for a return value from sending an AppleEvent on
Mac (send and request)

    - *it is used to implement 'wait for/until/while ...' (kinda obvious,
but hey, I was trying to be semi-complete ;))*

    - it is used to implement 'read ... with timeout' forms

    - it is used to wait for process death when you do 'kill'

    - *it is used to wait between beeps when you do 'beep <n>'*

    - *it is used to moderate the speed of 'drag from x to y'*

    - *it is used to moderate the speed of 'type STRING '*

    - *it is used to moderate the time between mouseDown and mouseUp when
doing 'click at'*

    - *it is used to wait whilst a non without-waiting form of 'move' is
invoked*

    - it is used in the mobile browser control to wait for JavaScript
evaluation to finish

    - it is used to wait for mobile calendar UI modal panes to return

    - it is used to wait for mobile photo taking panes to return

    - it is used to wait for mobile contact UI modal panes to return

    - it is used to wait for mobile datetime/option picker modal panes to
return

    - it is used to wait for mobile compose mail UI modal panes to return

    - it is used to wait for mobile media picker UI modal panes to return

    - it is used to wait for mobile fullscreen videos to finish

    - it is used to wait for mobile text message UI modal panes to return

    - it is used to wait inbetween vibrations when you use 'iphoneVibrate
<n>'

    - *it is used to wait between frames for visual effects /
transitions*

    - it is used in all forms of blocking socket commands (open, read,
write etc.)

    - it is used to wait for blocking DNS resolution to finish*

    - *it is used to wait for 'modal <stack>' to finish (by closing the
stack)*

    - *it is used (in libURL) to wait for evaluation of 'url <url>' to
finish*

    - *it is used (in libURL) to wait for 'post to url <url>' to finish*

    - *it is used to wait for 'popup widget' to finish*

    - it is used by various other things in externals, and widgets and
libraries to implement things which need to wait for something or some
time in order to have something to return

Phew! The ones surrounded by '*' are ones which would make some sense to
have working in HTML5. Almost all of these can be rendered in a form
without 'wait', they just end up being *slightly* less useful or easy to
use (e.g. get url -> load url, always use 'move without waiting', etc.).

So, first thing to point out, even without 'wait', if we manage to
implement all the existing things which make sense in the HTML5 engine,
'greenfield' (new projects) will work fine (as you avoid the things
which don't work in HTML5), and a reasonable number of existing projects
(particularly ones which are already written to use 'load url' rather
than 'get url') will also work. However, there will still be a
substantial number of existing projects which will not, without
significant code changes.

One of the things we pride ourselves on is that (on the whole) an app
written on one platform will work, largely unchanged on all the others
(particularly if platform-specific features are avoided). However, we
can't really keep that mantra, if something such as 'wait' is abandoned
because it is deemed 'too hard to implement'. It means for any project
targetting HTML5, you have to write in a different style, and avoid a
reasonable number of features that many use day-to-day.

Now, if these features were 'just' things like 'drag' or 'click' or pick
any specific (non-general language feature) that we have things wouldn't
be too bad. However, 'wait' is a different kettle of fish altogether.

Wait is essentially LiveCode's implementation of 'async' - this is
something that C# has (which is a much newer language than LiveCode -
and its HyperTalk heritage); it is something JavaScript is in the
process of adding. The simple reason is that event-driven coding is so
ubiquitous these days (we've known its important for a long time) that
other languages are gradually catching up to the need to have some way
to do it easily.

Of course, async (i.e. wait) in LiveCode is not perfect - it is
recursive, and not side-by-side (or 'round-robin' would be another way
to put it) - and it is a little bit specific. However, on the whole, the
fact that it exists at all *and* the engine uses it in various commands
*does* simplify things.

So, 'wait' is important. Indeed, one of my hopes is that through getting
wait to work in HTML5, we will also be able to *then* improve wait to
bring it on par with other languages much more recent 'async'
implementations. Indeed, my hope is that we can get to a point that code
which needs to be written in a threaded/callback style now in LiveCode
could actually be written without callbacks - this is the goal of the
additions to JavaScript (due to node.js and its pure event-driven
nature) - and if they can do it without having had a 'wait'
implementation to build on, why can't we?

Anyway, the 'wait' beast in HTML5 has almost been slain (at least in
thought). I think we almost have a solution which will require modest
C++ code changes (which are doable without huge churn); and the rest can
be done as a process that transforms the scripts we write. It might be
upon further analysis, that another angle of attack actually makes more
sense - compiling the current syntax to a bytecode, and using a VM which
understands how to wait to execute it. To get performant code out, the
asyncify algorithm / process would still be needed at some point; so it
is merely a matter of ordering. At the moment, I *think* asyncifying at
the script level will take less time to engineer and thus gets us to a
fully compatible HTML5 engine quicker; however, we shall see what the
next few months bring.

Warmest Regards,

Mark.

P.S. One other possibility I've toyed with is doing LCS->BYTECODE, then
BYTECODE->ASYNCIFIED_JAVASCRIPT. The latter would be particularly easy
if targetting browsers which have already implemented the new async
JavaScript features. Since it looks like the HTML5 engine will only
become truly widely usable when we move to WASM, this might well be a
much more maintainable, and relatively quicker option.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps


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

Re: Wait, the problem, and why it is important to solve

J. Landman Gay via use-livecode
Wow. You say (using stars) it would make sense to implement wait
in HTML5 for some features that do _not_ (yet) work in HTML5.
Will be a great enhancement side-effect. I look forward to that.

Peter-B already implemented wait in 2015, see bug #16076.
This caused an _additional_ slow down by a factor of 16 that was
*overall*, i.e. also in handlers not containing any form of wait.

We had since then, not counting browser improvements, a speed up
in the HTML5 engine by a factor of up to 8. So "wait" would cause
in sum (better: in product) a slowdown by a factor of at least 2.

The slow down compared to desktop standalones of the same source
was originally 15-20. so we would arrive for that comparison at
a slowdown of 30-40 by the HTML5 engine.

This is at about the same factor as with RaspberryPiB. RaspberryPi3
has a slow down factor of at about 10.

So the move of the HTML5 engine to WebAssembly may be a necessary
condition?


> Mark wrote:
> So LiveCode has long has this feature called 'wait' - it is one of those
> seemingly innocuous things which, from the surface seems simple (it
> allows you to wait for something - it's great when syntax is aptly
> named!) however it is perhaps one of the deepest language features we
> have.
>
> I think there is some confusion (or puzzlement) as to why I am a little
> hung up on it because, on the whole, the 'wait' command is not actually
> seen in script that much. Certainly it is part of some people's coding
> style (the one thing I love about LiveCode is that it promotes a very
> pluralistic style to solving programming problems), but on the whole
> many of us rarely if ever use it. Well, we *think* we don't use it.
>
> The thing is that 'wait' is such an important feature to LiveCode that
> many pieces of syntax use it without you knowing! The pure mathematician
> in my likes classifying and counting things (hey its what we do!), so
> here is a reasonably complete list of the places the engine uses it
> (this list is alphabetic by source-file in the engine order):
>
>     - it is used to provide the flash of the menu when a menu accelerator
> key is pressed
>     - it is used to wait for uses of shell() to send back any data so it
> can be accumulated for return
>     - it is used to wait for a return value from sending an AppleEvent on
> Mac (send and request)
>     - *it is used to implement 'wait for/until/while ...' (kinda obvious,
> but hey, I was trying to be semi-complete ;))*
>     - it is used to implement 'read ... with timeout' forms
>     - it is used to wait for process death when you do 'kill'
>     - *it is used to wait between beeps when you do 'beep <n>'*
>     - *it is used to moderate the speed of 'drag from x to y'*
>     - *it is used to moderate the speed of 'type STRING '*
>     - *it is used to moderate the time between mouseDown and mouseUp when
> doing 'click at'*
>     - *it is used to wait whilst a non without-waiting form of 'move' is
> invoked*
>     - it is used in the mobile browser control to wait for JavaScript
> evaluation to finish
>     - it is used to wait for mobile calendar UI modal panes to return
>     - it is used to wait for mobile photo taking panes to return
>     - it is used to wait for mobile contact UI modal panes to return
>     - it is used to wait for mobile datetime/option picker modal panes to
> return
>     - it is used to wait for mobile compose mail UI modal panes to return
>     - it is used to wait for mobile media picker UI modal panes to return
>     - it is used to wait for mobile fullscreen videos to finish
>     - it is used to wait for mobile text message UI modal panes to return
>     - it is used to wait inbetween vibrations when you use 'iphoneVibrate
> <n>'
>     - *it is used to wait between frames for visual effects /
> transitions*
>     - it is used in all forms of blocking socket commands (open, read,
> write etc.)
>     - it is used to wait for blocking DNS resolution to finish*
>     - *it is used to wait for 'modal <stack>' to finish (by closing the
> stack)*
>     - *it is used (in libURL) to wait for evaluation of 'url <url>' to
> finish*
>     - *it is used (in libURL) to wait for 'post to url <url>' to finish*
>     - *it is used to wait for 'popup widget' to finish*
>     - it is used by various other things in externals, and widgets and
> libraries to implement things which need to wait for something or some
> time in order to have something to return
>
> Phew! The ones surrounded by '*' are ones which would make some sense to
> have working in HTML5. Almost all of these can be rendered in a form
> without 'wait', they just end up being *slightly* less useful or easy to
> use (e.g. get url -> load url, always use 'move without waiting', etc.).
>
> So, first thing to point out, even without 'wait', if we manage to
> implement all the existing things which make sense in the HTML5 engine,
> 'greenfield' (new projects) will work fine (as you avoid the things
> which don't work in HTML5), and a reasonable number of existing projects
> (particularly ones which are already written to use 'load url' rather
> than 'get url') will also work. However, there will still be a
> substantial number of existing projects which will not, without
> significant code changes.
>
> One of the things we pride ourselves on is that (on the whole) an app
> written on one platform will work, largely unchanged on all the others
> (particularly if platform-specific features are avoided). However, we
> can't really keep that mantra, if something such as 'wait' is abandoned
> because it is deemed 'too hard to implement'. It means for any project
> targetting HTML5, you have to write in a different style, and avoid a
> reasonable number of features that many use day-to-day.
>
> Now, if these features were 'just' things like 'drag' or 'click' or pick
> any specific (non-general language feature) that we have things wouldn't
> be too bad. However, 'wait' is a different kettle of fish altogether.
>
> Wait is essentially LiveCode's implementation of 'async' - this is
> something that C# has (which is a much newer language than LiveCode -
> and its HyperTalk heritage); it is something JavaScript is in the
> process of adding. The simple reason is that event-driven coding is so
> ubiquitous these days (we've known its important for a long time) that
> other languages are gradually catching up to the need to have some way
> to do it easily.
>
> Of course, async (i.e. wait) in LiveCode is not perfect - it is
> recursive, and not side-by-side (or 'round-robin' would be another way
> to put it) - and it is a little bit specific. However, on the whole, the
> fact that it exists at all *and* the engine uses it in various commands
> *does* simplify things.
>
> So, 'wait' is important. Indeed, one of my hopes is that through getting
> wait to work in HTML5, we will also be able to *then* improve wait to
> bring it on par with other languages much more recent 'async'
> implementations. Indeed, my hope is that we can get to a point that code
> which needs to be written in a threaded/callback style now in LiveCode
> could actually be written without callbacks - this is the goal of the
> additions to JavaScript (due to node.js and its pure event-driven
> nature) - and if they can do it without having had a 'wait'
> implementation to build on, why can't we?
>
> Anyway, the 'wait' beast in HTML5 has almost been slain (at least in
> thought). I think we almost have a solution which will require modest
> C++ code changes (which are doable without huge churn); and the rest can
> be done as a process that transforms the scripts we write. It might be
> upon further analysis, that another angle of attack actually makes more
> sense - compiling the current syntax to a bytecode, and using a VM which
> understands how to wait to execute it. To get performant code out, the
> asyncify algorithm / process would still be needed at some point; so it
> is merely a matter of ordering. At the moment, I *think* asyncifying at
> the script level will take less time to engineer and thus gets us to a
> fully compatible HTML5 engine quicker; however, we shall see what the
> next few months bring.
>
> Warmest Regards,
>
> Mark.
>
> P.S. One other possibility I've toyed with is doing LCS->BYTECODE, then
> BYTECODE->ASYNCIFIED_JAVASCRIPT. The latter would be particularly easy
> if targetting browsers which have already implemented the new async
> JavaScript features. Since it looks like the HTML5 engine will only
> become truly widely usable when we move to WASM, this might well be a
> much more maintainable, and relatively quicker option.

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

Re: Wait, the problem, and why it is important to solve

J. Landman Gay via use-livecode
On 2017-07-30 11:13, hh via use-livecode wrote:
> Wow. You say (using stars) it would make sense to implement wait
> in HTML5 for some features that do _not_ (yet) work in HTML5.
> Will be a great enhancement side-effect. I look forward to that.

I don't think that was the implication. The implication was that those
things marked '*' all make sense in HTML5 - i.e. they actually *could*
be implemented (the other things are mainly mobile related things which
make no sense). The further point I made was that *all* of them are
useful (if not identical) if wait does not work.

i.e. We get a more effective HTML5 engine by implementing them even if
we don't have wait.

Ergo, the HTML5 engine gets even better when we do have wait - in terms
of ability to use code without modification.

> Peter-B already implemented wait in 2015, see bug #16076.
> This caused an _additional_ slow down by a factor of 16 that was
> *overall*, i.e. also in handlers not containing any form of wait.

Indeed - hence the paragraph in one of my previous emails where I
stated:

"The alternative - emterpreter - works perfectly but (as anyone who used
the early wait-supporting versions will know) is waaaaaaaaaaaay too slow
to be viable. Not an ideal situation, to say the least."

Emterpreter (due to the way things are structured in the C++ engine) is
an all or nothing thing. It makes little difference whether things call
wait or not.

Also to actually determine this 'calls wait' / 'doesn't call wait'
attribute requires a level of abstract analysis of script which would
essentially mean we were performing asyncification anyway. So that is
what we might as well do, and not pay the cost of emterpretation at all.

> We had since then, not counting browser improvements, a speed up
> in the HTML5 engine by a factor of up to 8. So "wait" would cause
> in sum (better: in product) a slowdown by a factor of at least 2.

Well, compared to now perhaps.

I'd be wary of using such 'approximation' math on things like this. Just
because we have numbers for certain combinations, it does not mean you
can just recombine them with other assumptions (we don't know that the
actual performance metrics can be added or multiplied either
associatively or distributively).

The only way to know what the speed of a certain combination of
implementation strategies and execution environments is to actually run
performance tests.

> This is at about the same factor as with RaspberryPiB. RaspberryPi3
> has a slow down factor of at about 10.

I'm not sure relating this to RaspPi is useful. The reason is that if I
am wanting to move my Desktop app (Mac, Windows, Linux) app to HTML5
then I'd want the performance in the browser to be within a reasonable
distance of that when on the Desktop.

Comparing different platforms (which are slower due to hardware
implementation - slower memory buses, in particular) isn't all that
helpful in determining the veracity of the HTML5 engine's performance.

> So the move of the HTML5 engine to WebAssembly may be a necessary
> condition?

WASM will likely make a significant difference to size and startup time.
Performance, is probably more going to be in the 10-15% range. However,
that is not a number to be relied upon. The only way to find out is to
test and benchmark.

All I'm really saying, speculating based on the numbers we have, or
against other (completely different) platforms isn't going to give us
much, if any insight. The only thing we can do is try, measure and
iterate. Then try, measure and iterate again.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: Wait, the problem, and why it is important to solve

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
> Mark wrote:
> I'm not sure relating this to RaspPi is useful. The reason is that if I
> am wanting to move my Desktop app (Mac, Windows, Linux) app to HTML5
> then I'd want the performance in the browser to be within a reasonable
> distance of that when on the Desktop...
> ...The only way to know what the speed of a certain combination of
> implementation strategies and execution environments is to actually run
> performance tests.

Well, I compare "scenarios", that is "target-platforms" and  LC versions
that generate the standalone, running on "medium" hardware (mine, for tests).

May be some say I'm going to compare apples to oranges. Yes, I do, both are
fruits and I can eat the one or the other or both. These are my experiences,
without "wait":
Say I'm on medium fast machines (2.5GHz), and say I am going to make an
animation using graphics, with the fastest method (send in time, no wait) and
everything needed is already available in LC 6.7.11.

Such scripts will run at about the same speed on desktop Mac/Win/linux (what
is an excellent result).
This is the base speed I keep in mind, it is at about the same for standalones
or still being in the IDE.
And this is probably one of the most used standalone version that is compared
to HTML5 standalones, the latter built with "unchanged" source.

Now I will have here a slow down by a factor of (best cases)...
... 10 or 20 when running on Raspi2B+ or Raspi3.
... 2-3 when when running in LC 8/9 on the same machine.
... 6-32 when running in the newest version of the most used browser on
Mac/Win/linux in a HTML5 standalone.

*** For me these are good-to-know thumb-rules, mostly very close to real tests.
And running a test-stack on Raspi3 in the 6.5.1 IDE is at about the average
speed I'll get in a HTML5 standalone on a medium fast machine with Mac/Win/linux.

Once again, compared to LC 8/9 desktop standalones, the slow down factor is...
... 3-16 when running in the newest version of the most used browser on
Mac/Win/linux in a HTML5 standalone (what is an excellent result).

The lowest slowdown for HTML5 standalone is when using the 'fastest' browser of
Safari/Firefox/Chrome/Opera which is currently Safari on Mac. For the 'slowest'
browser (Chrome/Opera) there is AGAIN, compared to Safari, a slow down of 3-4.
[-> But Opera Developer is already close to Safari!!]

In sum, if I wish to display a "complicated" clock animation every second (also
having the different refresh rates of the different main browsers in mind) then
I know I have to reach less than 30 millisecs per cycle in LC 6.7.11 or 60
millisecs per cycle in LC 8/9. And I have to "work-around" for the worst case.

And if you wish to be below the refresh rate of 54 millisecs of Firefox on
Mac/Win/linux with your HTML5 standalone, then you have to reach 5-6 millisecs
per cycle in the LC 8/9 IDE on the same machine.

Such good results are in the dreams only of some other comparable IDE's.

So no exaggeration is needed. Take it as good as it is. And go on, LC-team, with
your excellent work to improve it.

_______
One possible "test-stack" to reproduce my thumb-rule statements on your own
machine(s) is the source code of the "LCD"-HTML5 standalone.
Start there with preset 7 for comparing browsers on the same machine:
http://hh.on-rev.com/html5/LCD-01e-8.0.2X.html
(replace "X.html" with ".zip" for the source)
There is also Raspi stack #79 which is (probably) that source code
http://forums.livecode.com/viewtopic.php?p=145528#p145528


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

Re: Wait, the problem, and why it is important to solve

J. Landman Gay via use-livecode
Hi Herman,

This is all very useful information I must confess.

I guess I'm wary of just extrapolating potential performance from piecing together results from very different underlying architecture (e.g emterpreter vs no emterpreter) over bastions different html5 engine iterations.

Of course your post has made me wonder whether a hybrid approach might work (i.e. emterpret enough to get wait working but not so much it damages performance - I'm sure there was a technical reason why this wasn't an option - but it is probably worth trying again).

Also it might be worth doing two versions one wait capable (slow speed); one non-wait capable (faster speed).

At least then users have a choice and it will depend on their app which they need to use.
 
Anyway, I'm on holiday for a week now so might be a bit quiet on here (compared to recently, anyway). However I will return to this, and everything else when I'm back.

Warmest Regards,

Mark.

Sent from my iPhone

On 30 Jul 2017, at 19:25, hh via use-livecode <[hidden email]> wrote:

>> Mark wrote:
>> I'm not sure relating this to RaspPi is useful. The reason is that if I
>> am wanting to move my Desktop app (Mac, Windows, Linux) app to HTML5
>> then I'd want the performance in the browser to be within a reasonable
>> distance of that when on the Desktop...
>> ...The only way to know what the speed of a certain combination of
>> implementation strategies and execution environments is to actually run
>> performance tests.
>
> Well, I compare "scenarios", that is "target-platforms" and  LC versions
> that generate the standalone, running on "medium" hardware (mine, for tests).
>
> May be some say I'm going to compare apples to oranges. Yes, I do, both are
> fruits and I can eat the one or the other or both. These are my experiences,
> without "wait":
> Say I'm on medium fast machines (2.5GHz), and say I am going to make an
> animation using graphics, with the fastest method (send in time, no wait) and
> everything needed is already available in LC 6.7.11.
>
> Such scripts will run at about the same speed on desktop Mac/Win/linux (what
> is an excellent result).
> This is the base speed I keep in mind, it is at about the same for standalones
> or still being in the IDE.
> And this is probably one of the most used standalone version that is compared
> to HTML5 standalones, the latter built with "unchanged" source.
>
> Now I will have here a slow down by a factor of (best cases)...
> ... 10 or 20 when running on Raspi2B+ or Raspi3.
> ... 2-3 when when running in LC 8/9 on the same machine.
> ... 6-32 when running in the newest version of the most used browser on
> Mac/Win/linux in a HTML5 standalone.
>
> *** For me these are good-to-know thumb-rules, mostly very close to real tests.
> And running a test-stack on Raspi3 in the 6.5.1 IDE is at about the average
> speed I'll get in a HTML5 standalone on a medium fast machine with Mac/Win/linux.
>
> Once again, compared to LC 8/9 desktop standalones, the slow down factor is...
> ... 3-16 when running in the newest version of the most used browser on
> Mac/Win/linux in a HTML5 standalone (what is an excellent result).
>
> The lowest slowdown for HTML5 standalone is when using the 'fastest' browser of
> Safari/Firefox/Chrome/Opera which is currently Safari on Mac. For the 'slowest'
> browser (Chrome/Opera) there is AGAIN, compared to Safari, a slow down of 3-4.
> [-> But Opera Developer is already close to Safari!!]
>
> In sum, if I wish to display a "complicated" clock animation every second (also
> having the different refresh rates of the different main browsers in mind) then
> I know I have to reach less than 30 millisecs per cycle in LC 6.7.11 or 60
> millisecs per cycle in LC 8/9. And I have to "work-around" for the worst case.
>
> And if you wish to be below the refresh rate of 54 millisecs of Firefox on
> Mac/Win/linux with your HTML5 standalone, then you have to reach 5-6 millisecs
> per cycle in the LC 8/9 IDE on the same machine.
>
> Such good results are in the dreams only of some other comparable IDE's.
>
> So no exaggeration is needed. Take it as good as it is. And go on, LC-team, with
> your excellent work to improve it.
>
> _______
> One possible "test-stack" to reproduce my thumb-rule statements on your own
> machine(s) is the source code of the "LCD"-HTML5 standalone.
> Start there with preset 7 for comparing browsers on the same machine:
> http://hh.on-rev.com/html5/LCD-01e-8.0.2X.html
> (replace "X.html" with ".zip" for the source)
> There is also Raspi stack #79 which is (probably) that source code
> http://forums.livecode.com/viewtopic.php?p=145528#p145528
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Wait, the problem, and why it is important to solve

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
On 07/29/2017 09:23 PM, Mark Waddingham via use-livecode wrote:

> P.S. One other possibility I've toyed with is doing LCS->BYTECODE, then
> BYTECODE->ASYNCIFIED_JAVASCRIPT. The latter would be particularly easy
> if targetting browsers which have already implemented the new async
> JavaScript features. Since it looks like the HTML5 engine will only
> become truly widely usable when we move to WASM, this might well be a
> much more maintainable, and relatively quicker option.
>

I also want to point out (thanks for that long well-thought-out post)
that many of the use cases you list might be better served with callback
functions than with a cobbled-together 'wait' command. Javascript on its
own doesn't have a wait or sleep command, and while there are ways to
simulate the effect, they are problematic in a real-world environment
where network timing issues are out of control of the calling code.

--
  Mark Wieder
  [hidden email]

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

Re: Wait, the problem, and why it is important to solve

J. Landman Gay via use-livecode
Indeed - we can make all the things on the list I made have a callback / without waiting form too.

In terms of wait itself - it is the HyperTalk way of doing 'async' - allowing you to write such code without the 'headache' of nested callbacks / closures and such - this is why it is important to retain and improve. It makes coding event driven things easier.

The fact that C# has async, and JS is getting it (because node.js primarily) shows that it is an important pattern. One we've had for years, just in a restricted (recursive) form.

Warmest Regards,

Mark.

Sent from my iPhone

> On 31 Jul 2017, at 16:39, Mark Wieder via use-livecode <[hidden email]> wrote:
>
>> On 07/29/2017 09:23 PM, Mark Waddingham via use-livecode wrote:
>>
>> P.S. One other possibility I've toyed with is doing LCS->BYTECODE, then BYTECODE->ASYNCIFIED_JAVASCRIPT. The latter would be particularly easy if targetting browsers which have already implemented the new async JavaScript features. Since it looks like the HTML5 engine will only become truly widely usable when we move to WASM, this might well be a much more maintainable, and relatively quicker option.
>
> I also want to point out (thanks for that long well-thought-out post) that many of the use cases you list might be better served with callback functions than with a cobbled-together 'wait' command. Javascript on its own doesn't have a wait or sleep command, and while there are ways to simulate the effect, they are problematic in a real-world environment where network timing issues are out of control of the calling code.
>
> --
> Mark Wieder
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Wait, the problem, and why it is important to solve

J. Landman Gay via use-livecode
I agree.

i have yet to use the HTML output .... but I would have a hard time meeting
my needs without the wait feature as I use it to keep the UI from ever
being blocked ....which is part of a major feature of the software I am
building.

While I don't  anticipate having this need to output to HTML anytime soon,
if ever, it seems impractical to exclude it for all the reasons you
mentioned.  If we want the HTML engine to be anywhere near as robust and
(precisely controllable) as it is for the desktops, it just has to be there.

On Mon, Jul 31, 2017 at 12:01 PM, Mark Waddingham via use-livecode <
[hidden email]> wrote:

> Indeed - we can make all the things on the list I made have a callback /
> without waiting form too.
>
> In terms of wait itself - it is the HyperTalk way of doing 'async' -
> allowing you to write such code without the 'headache' of nested callbacks
> / closures and such - this is why it is important to retain and improve. It
> makes coding event driven things easier.
>
> The fact that C# has async, and JS is getting it (because node.js
> primarily) shows that it is an important pattern. One we've had for years,
> just in a restricted (recursive) form.
>
> Warmest Regards,
>
> Mark.
>
> Sent from my iPhone
>
> > On 31 Jul 2017, at 16:39, Mark Wieder via use-livecode <
> [hidden email]> wrote:
> >
> >> On 07/29/2017 09:23 PM, Mark Waddingham via use-livecode wrote:
> >>
> >> P.S. One other possibility I've toyed with is doing LCS->BYTECODE, then
> BYTECODE->ASYNCIFIED_JAVASCRIPT. The latter would be particularly easy if
> targetting browsers which have already implemented the new async JavaScript
> features. Since it looks like the HTML5 engine will only become truly
> widely usable when we move to WASM, this might well be a much more
> maintainable, and relatively quicker option.
> >
> > I also want to point out (thanks for that long well-thought-out post)
> that many of the use cases you list might be better served with callback
> functions than with a cobbled-together 'wait' command. Javascript on its
> own doesn't have a wait or sleep command, and while there are ways to
> simulate the effect, they are problematic in a real-world environment where
> network timing issues are out of control of the calling code.
> >
> > --
> > Mark Wieder
> > [hidden email]
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Loading...