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

[Tom Glod 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 <
use-livecode@lists.runrev.com> 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 <
> use-livecode@lists.runrev.com> 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
> > 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
>
>
> ___
> 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: Wait, the problem, and why it is important to solve

[Mark Waddingham 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 
>  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
> 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


___
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: Wait, the problem, and why it is important to solve

[Mark Wieder 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
 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: Wait, the problem, and why it is important to solve

[Mark Waddingham 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  
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
> 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: Wait, the problem, and why it is important to solve

[hh 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
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: Wait, the problem, and why it is important to solve

[Mark Waddingham 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 wy 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 ~ 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: Wait, the problem, and why it is important to solve

[hh 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 '*
> - *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 
> '
> - *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 ' to finish (by closing the 
> stack)*
> - *it is used (in libURL) to wait for evaluation of 'url ' to 
> finish*
> - *it is used (in libURL) to wait for 'post to 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 

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

[Mark Waddingham 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 '*

   - *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 
'


   - *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 ' to finish (by closing the 
stack)*


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


   - *it is used (in libURL) to wait for 'post to 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