HTML5 no wait syntax

[[-hh]]

I'll prepare a demo/input stack for the bug, so we can see IDE speed and standalone-speed both with dp9 (my current favourite) and dp14.

One thing I like very much in the UK is the disciplined "queuing" of people. This is most effective for the overall speed. So I'll go at the end of your queue, *just now*, and you'll have the demo until Monday.

[Brahmanathaswami]

Aloha, Peter...

At Hermann's suggestion I'm hopping over here. I usually "live and die" on the mailing.

Question: is Wait is disabled now in 8 LC 14? I'm getting a total failure on one stack that I think should run. I have 4 wait commands in different card scripts. I believe I can easily change those to send in time methods without much difficulty.

Side question: If the LiveCode team had *their* choice of LC use behaviors, would prefer to interact with us via these forums or the mailing lists?

As you know LC standalone seem to be failing completely in FFox 44... I'm standing by on that one.

[peter-b]

Question: is Wait is disabled now in 8 LC 14? I'm getting a total failure on one stack that I think should run. I have 4 wait commands in different card scripts. I believe I can easily change those to send in time methods without much difficulty.

Yes, you need to use "send in time" for now, please. Sorry for the inconvenience. It's a really thorny problem that can only be solved fully by basically rewriting the LiveCode engine, so there will be workarounds in the short term. It's also blocking provision of usable "url" syntax, much to my frustration.

Side question: If the LiveCode team had *their* choice of LC use behaviors, would prefer to interact with us via these forums or the mailing lists?

I personally find it easier to interact with users via the mailing list, but I try to keep a reasonable overview of things that are relevant to me on the forums.

As you know LC standalone seem to be failing completely in FFox 44... I'm standing by on that one.

That's a change in behaviour in Firefox interacting poorly with a non-standard piece of JS in the HTML5 engine, and there are already fixes queued for build in both Firefox and LiveCode.

[peter-b]

I'll prepare a demo/input stack for the bug, so we can see IDE speed and standalone-speed both with dp9 (my current favourite) and dp14.

It will be really useful to have something that can be used to quantify relative speed -- thank you.

[[-hh]]

At Hermann's suggestion I'm hopping over here. I usually "live and die" on the mailing.

Now you have a notification about an answer in your *mail*

Hi Brahmanathaswami,
of course everybody should use what he likes (or likes more).
It was more a hint for appropriate information and an invitation to contribute to the subforum. Here your contributions have a better visibility ...
For me it is a good solution that some people use (with different weights) both, forum and use-list and 'connect' these. By that usually no important information for help is lost in the never ending stream of mailing lists.

Hermann

p.s. At first forced by the non-availibility of wait for HTML5 I meanwhile totally stopped to use it: Send <in time> is a wonderful tool, for more than avoiding waiting.
I miss only a substitute for forcing screen updates alike "wait 0 millisecs with messages".

[[-hh]]

Attached you'll find is a simplified TESTSTACK for comparisons between dp-releases.
Mainly tested (with timing measured) is
"send <in time>" and smoothness of "move ... without waiting".

The stack has an action every full next second, that is

Code: Select all

on handler
  ...
  send "handler" to me in 1000-(the millisecs mod 1000) millisecs
end handler

It 'highlights' an appropriate item in a text field, that contains the constants zero, one, ..., nine in an order that is randomized every 10 seconds.
Check button 'Move' causes a move of the 'highlight' to the new target without waiting.
There is no accurate timing for that, it's more for testing the CPU load and for looking at an object that should move "smoothly" an arrive at full second.

These are the results I found with my tests.

• dp9 HTML5 standalone
  9 ms (avg of 150). Using move 11 ms (avg of 150)
• dp14 HTML5 standalone
  190 ms (avg of 150). Using move 185 ms (avg of 150)
  pauses sometimes for two to three seconds.
• [dp-9 IDE: 1 ms (avg of 150), with move 1 ms (avg of 150)]
• [dp14 IDE 1 ms (avg of 150), with move 1 ms (avg of 150)]

Between versions the quotient dp14-value/dp9-value is of interest.
This quotient will be about the same for slow to fast machines, that is roughly 15-20.

Tests above made on MacOS X 10.11.3, Mac mini 2.5 HGz, using locally browser Safari.

[[-hh]]

Peter solved the speed-problem in 8.0.0-dp15 -- and didn't say a single word!!

Thank you very much Peter, and respect for that great work, now you gave us the speed you had in mind and announced.

Testing with the stack from my last post here, I got a new record with Firefox (and in average we are back to the dp9 speed).

dp15 HTML5 standalone (Firefox):
5 ms (avg of 150). Using move 5 ms (avg of 150) <-- Incredible result, try yourself!

dp15 HTML5 standalone (Chrome, Opera, Safari):
18-20 ms (avg of 150). Using move 20 ms (avg of 150)

Hermann

[Edit. Now It's correct, sorry. Had to repost for such a record!]