HTML5 no wait syntax
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
HTML5 no wait syntax
I have been trying the HTML5 standalone in version 8 dp1-7.
The "wait"syntax is not supported. This is required for my app to look right.
I have replaced the wait with the following code.
It works in the IDE, but not in the html5 standalone.
--wait 30ticks
call "nextSpot"
on nextSpot
repeat with x=1 to 500
put x into field "delay"
end repeat
end nextSpot
Is there plans to add this feature in upcoming releases.
Is there a better way to workaround the wait syntax.
The "wait"syntax is not supported. This is required for my app to look right.
I have replaced the wait with the following code.
It works in the IDE, but not in the html5 standalone.
--wait 30ticks
call "nextSpot"
on nextSpot
repeat with x=1 to 500
put x into field "delay"
end repeat
end nextSpot
Is there plans to add this feature in upcoming releases.
Is there a better way to workaround the wait syntax.
Re: HTML5 no wait syntax
Indeed, as mentioned in the HTML5 Deployment Guide, and the release notes, and as discussed in bug 160176.
You can use send instead.
You can use send instead.
Code: Select all
send "nextSpot" to me in 30 ticks
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com
Re: HTML5 no wait syntax
Thank you for your reply.
The suggestion did not work.
I have experimented with timers and loops from the game forums.
per the dictionary
"Use the send command to override the normal message path,
or to delay a command until a specified time"
This did not work like the wait command.
The send to me command does not stop the script from running and the spots appear with no delay.
The simple timer I used works , and delays the spots as it should.
My app is on google play and itunes, and at some point would like people to preview it on my website.
I may have to wait for future HTML builds to deal with timing.
The suggestion did not work.
I have experimented with timers and loops from the game forums.
per the dictionary
"Use the send command to override the normal message path,
or to delay a command until a specified time"
This did not work like the wait command.
The send to me command does not stop the script from running and the spots appear with no delay.
The simple timer I used works , and delays the spots as it should.
My app is on google play and itunes, and at some point would like people to preview it on my website.
I may have to wait for future HTML builds to deal with timing.
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
This means, that you could break your code into parts and call these parts by 'send in time'. For exampleUse the send command to override the normal message path, or to delay a command until a specified time.
Code: Select all
on startGame -- first part of your code
send "showSpots" to me in 2345 millisecs
end startGame -- first part of code ends here
on showSpots
show grc "spots"
send "do2ndPart" to me in 1234 millisecs
end showSpots
on do2ndPart
-- second part of your code
send "do3rdPart" to me in 1234 millisecs
end do2ndPart
Such a technique is -- THMO -- (in most cases) better than blocking a "weak" device for half a second by "wait" anyway.
You may have a look at my HTML5-example "Wake up Neo", that uses this technique for "typing". See here the source code.
shiftLock happens
Re: HTML5 no wait syntax
I have experimented with a new stack to test timer routines.
I pondered your suggestions and came up with a working routine in the HTML build
here is my code , hope it helps other in need of timing.
objects
field called delay
button called start
button called clear
graphic called led
card script
on cardOpen
put empty into field "delay"
put empty into field "delay"
end cardOpen
command spot1
put "1" into field "delay"
end spot1
command spot2
if field "delay" is not empty then
put "2" into field "delay"
end if
end spot2
command spot3
if field "delay" is not empty then
put "3" into field "delay"
end if
end spot3
button start
on mouseUp
set the opaque of graphic "led" to "true"
send "spot1"to me in .5 sec
send "spot2"to me in 1.sec
send "spot3"to me in 1.5sec
end mouseUp
button clear
on mouseUp
put empty into field "delay"
set the opaque of graphic "led" to "false"
end mouseUp
It will take some time to rework my app , but I think I am on my way to succeed.
Thank you for helping
I pondered your suggestions and came up with a working routine in the HTML build
here is my code , hope it helps other in need of timing.
objects
field called delay
button called start
button called clear
graphic called led
card script
on cardOpen
put empty into field "delay"
put empty into field "delay"
end cardOpen
command spot1
put "1" into field "delay"
end spot1
command spot2
if field "delay" is not empty then
put "2" into field "delay"
end if
end spot2
command spot3
if field "delay" is not empty then
put "3" into field "delay"
end if
end spot3
button start
on mouseUp
set the opaque of graphic "led" to "true"
send "spot1"to me in .5 sec
send "spot2"to me in 1.sec
send "spot3"to me in 1.5sec
end mouseUp
button clear
on mouseUp
put empty into field "delay"
set the opaque of graphic "led" to "false"
end mouseUp
It will take some time to rework my app , but I think I am on my way to succeed.
Thank you for helping
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
Now 'wait' works in dp12 and dp13.
But what a price we had to pay for that, 25 times more time needed compared to dp9!
I didn't use 'wait' , I don't need it and I hate waiting now. So, I stop testing with HTML5 until speed comes back. One hour each day is OK (with dp9), but the whole day (with dp12 or dp13) for the same simple runs?
No, thanks. Not a 'iota' of fun with that ...
But what a price we had to pay for that, 25 times more time needed compared to dp9!
I didn't use 'wait' , I don't need it and I hate waiting now. So, I stop testing with HTML5 until speed comes back. One hour each day is OK (with dp9), but the whole day (with dp12 or dp13) for the same simple runs?
No, thanks. Not a 'iota' of fun with that ...
shiftLock happens
Re: HTML5 no wait syntax
I'm thinking about possibilities for the next DP. Please be patient! I discussed disabling "wait" syntax again in DP13 with Mark, but other more important things came up.
I'm not a miracle worker, and (as explained in my mailing list post), this is a very difficult problem to solve.
It is possible to just compile your own (very fast) Community engine with all ability to "wait" disabled, if you want? Let me know if you would like more info on how to do that.
I'm not a miracle worker, and (as explained in my mailing list post), this is a very difficult problem to solve.
It is possible to just compile your own (very fast) Community engine with all ability to "wait" disabled, if you want? Let me know if you would like more info on how to do that.
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com
-
- VIP Livecode Opensource Backer
- Posts: 4027
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: HTML5 no wait syntax
Hi Peter,
I followed the discussion on the use-list and your postings here why "wait" was important as a way to enable get URL.
I know people that heaily depend on getting server stuff that don't touch HTML5 until that is possible.
On the other hand there are others that use HTML5 to do animation as Hermann and I did. And it used to work surprisingly well with a few changes to code.
I just tested HTML5 in DP13 with just a text field to find out how that would fare. It worked, but too slow for real input. Selecting and deleting text crashed the thing repeatedly.
Now I really don't know what to test in HTML5. It is basically not useable because of the slowness. As livecode.tv once had the tag-line: "like watching paint dry" , or along the same line: like watching a chess game replayed in slow motion.
Please don't get me wrong: I admire what Livecode and you did to get HTML5 to work. It has a lot of potential in my opinion. But in its current form I wonder who would want to use it for what.
And I am patiently waiting for where HTML5 is heading and I am confident, that you will find a way to make HTML5 a viable deployment platform for Livecde.
Kind regards
Bernd
I followed the discussion on the use-list and your postings here why "wait" was important as a way to enable get URL.
I know people that heaily depend on getting server stuff that don't touch HTML5 until that is possible.
On the other hand there are others that use HTML5 to do animation as Hermann and I did. And it used to work surprisingly well with a few changes to code.
I just tested HTML5 in DP13 with just a text field to find out how that would fare. It worked, but too slow for real input. Selecting and deleting text crashed the thing repeatedly.
Now I really don't know what to test in HTML5. It is basically not useable because of the slowness. As livecode.tv once had the tag-line: "like watching paint dry" , or along the same line: like watching a chess game replayed in slow motion.
Please don't get me wrong: I admire what Livecode and you did to get HTML5 to work. It has a lot of potential in my opinion. But in its current form I wonder who would want to use it for what.
And I am patiently waiting for where HTML5 is heading and I am confident, that you will find a way to make HTML5 a viable deployment platform for Livecde.
Kind regards
Bernd
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
Peter,
Hermann
I'm one of the idiots that backed 'HTML5' and bought a HTML5 license (does it really work meanwhile, yes?). And now I'm getting such an answer from a LC-staff member?peter-b wrote:It is possible to just compile your own (very fast) Community engine with all ability to "wait" disabled, if you want? Let me know if you would like more info on how to do that.
Hermann
shiftLock happens
Re: HTML5 no wait syntax
I've explained the current situation with the HTML5 engine, in detail, and the challenges that are currently confronting me in improving its performance while including the features that users expect.
I understand that you're upset by the current performance problems, because they're considerable. I'm very disappointed by the current situation of the HTML5 engine. However, compiling an 8.0.0-dp-13 Community engine without "wait" support is a practical and constructive suggestion for how you might obtain a faster engine for your HTML5 apps, and under the circumstances it's exactly what I would do if I was in your position. It's only because the LiveCode engine is open source -- thanks, in part, to your contributions -- that you even have that option.
If you had not backed the HTML5 engine campaign, then the HTML5 engine wouldn't exist at all, rather than existing and being rather slow/buggy. Also, please don't forget that the HTML5 engine is currently in an alpha state, as very clearly stated pretty much everywhere that it is described (documentation, release notes, etc.) but you seem to be demanding it to be production quality now. Is that really a reasonable expectation?
I know that you are not happy. I am not happy either. Does it make the situation any better to get angry at me? Probably not, because I have just spent half an hour trying to decide what to write in this forum thread, instead of working on the HTML5 engine.
I understand that you're upset by the current performance problems, because they're considerable. I'm very disappointed by the current situation of the HTML5 engine. However, compiling an 8.0.0-dp-13 Community engine without "wait" support is a practical and constructive suggestion for how you might obtain a faster engine for your HTML5 apps, and under the circumstances it's exactly what I would do if I was in your position. It's only because the LiveCode engine is open source -- thanks, in part, to your contributions -- that you even have that option.
If you had not backed the HTML5 engine campaign, then the HTML5 engine wouldn't exist at all, rather than existing and being rather slow/buggy. Also, please don't forget that the HTML5 engine is currently in an alpha state, as very clearly stated pretty much everywhere that it is described (documentation, release notes, etc.) but you seem to be demanding it to be production quality now. Is that really a reasonable expectation?
I know that you are not happy. I am not happy either. Does it make the situation any better to get angry at me? Probably not, because I have just spent half an hour trying to decide what to write in this forum thread, instead of working on the HTML5 engine.
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
Peter,
OK, agreed. I was angry because in your answer it sounds very easy to compile the 'fast' HTML5 engine. So I wondered why you didn't it simply by yourself and wrote instead snippy answers.
But now I apologize (in case you are insulted), please forgive me and forget it. Let's look forward.
The problem is, that I don't like low level compiling from several reasons -- one of the reasons I use LC. But if I have to do it anyway, I'm in danger to use directly XCode or similar on other OS and write native software, going away from LC.
But now I'll invest some time and make the 'fast' dp-variant parallel for all here that don't (currently) need the 'wait-package'.
I'm on Linux 64bit and downloaded emscripten and necessary additions (cmake, jre etc.) and also from github the livecode-develop.zip. Now I need, one time, your 'more info on how to do that'.
Hermann
OK, agreed. I was angry because in your answer it sounds very easy to compile the 'fast' HTML5 engine. So I wondered why you didn't it simply by yourself and wrote instead snippy answers.
But now I apologize (in case you are insulted), please forgive me and forget it. Let's look forward.
The problem is, that I don't like low level compiling from several reasons -- one of the reasons I use LC. But if I have to do it anyway, I'm in danger to use directly XCode or similar on other OS and write native software, going away from LC.
But now I'll invest some time and make the 'fast' dp-variant parallel for all here that don't (currently) need the 'wait-package'.
I'm on Linux 64bit and downloaded emscripten and necessary additions (cmake, jre etc.) and also from github the livecode-develop.zip. Now I need, one time, your 'more info on how to do that'.
Hermann
shiftLock happens
Re: HTML5 no wait syntax
Sure. The reason I didn't "just" make a non-waiting engine build is because I was urgently addressing the other bug that you kindly highlighted earlier this week![-hh] wrote:But now I'll invest some time and make the 'fast' dp-variant parallel for all here that don't (currently) need the 'wait-package'.
I'm on Linux 64bit and downloaded emscripten and necessary additions (cmake, jre etc.) and also from github the livecode-develop.zip. Now I need, one time, your 'more info on how to do that'.
Okay, so in the livecode-develop.zip file, there's an INSTALL-emscripten.md file that contains instructions for getting the engine to build. First, try to make sure that you can build the engine following those steps (I have just noticed some typos and I'll fix them shortly!)
Next, edit engine/src/em-whitelist.json. This is a list of regular expressions that are used to decide which functions in the engine should be compiled with Emterpreter. For your build, you probably just want to remove all the entries from line 14 ("MCWidgetExecOn") onward. Then recompile.
Dann werden dich ein schnelles Programm haben.
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
Peter,
after signing up to github, forking and cloning LiveCode, everything runs smoothly here. Compiling is OK and after erraneously producing the debug version (72 MByte) a release version compiled. This one is nearly as large as the 'normal' dp-13 version (40 MByte).
The standalones run with that version, but I can't see (and also couldn't measure) *any* increase in speed with the release-'fast'-version, so the JS is still a 'normal' version (but the files *are* different, I checked).
Hope you'll find some time to elaborate out what else but shortening the 'em-whitelist.json' is to do for removing effectively the speed-break.
Anyway I saw now how thoroughly compiling is prepared, for every platform, far above my expectations: I needed four hours only, incl. the whole first-time-process, from signing up to github to the first standalone test here. [I did it twice. Needed four hours for the second 'full run', starting with a naked OS on my machine. If not beeing root all the time I had unexplainable crashes]. Honestly, the files are chaos at some higher level, but it works and it works deterministically, not randomly
Whoever did all that stuff to facilitate compiling (especially you for the HTML5 build):
Brilliant, excellent, never found before such a comfortable 'public environment' for compiling a rather complex product. Thank you and thank you all, LC team and other helpers, for that!
Hermann
One thing in advance.
If I have the 'fast' version, how do I share it with other community members? If I use it for my example standalones then everybody with minimal HTML knowlege has it anyway. So it should be OK if I make it separately downloadable with some info, may be also a helper/utility stack , and a simple link to the LC license stuff on github?
after signing up to github, forking and cloning LiveCode, everything runs smoothly here. Compiling is OK and after erraneously producing the debug version (72 MByte) a release version compiled. This one is nearly as large as the 'normal' dp-13 version (40 MByte).
The standalones run with that version, but I can't see (and also couldn't measure) *any* increase in speed with the release-'fast'-version, so the JS is still a 'normal' version (but the files *are* different, I checked).
Hope you'll find some time to elaborate out what else but shortening the 'em-whitelist.json' is to do for removing effectively the speed-break.
Anyway I saw now how thoroughly compiling is prepared, for every platform, far above my expectations: I needed four hours only, incl. the whole first-time-process, from signing up to github to the first standalone test here. [I did it twice. Needed four hours for the second 'full run', starting with a naked OS on my machine. If not beeing root all the time I had unexplainable crashes]. Honestly, the files are chaos at some higher level, but it works and it works deterministically, not randomly
Whoever did all that stuff to facilitate compiling (especially you for the HTML5 build):
Brilliant, excellent, never found before such a comfortable 'public environment' for compiling a rather complex product. Thank you and thank you all, LC team and other helpers, for that!
Hermann
One thing in advance.
If I have the 'fast' version, how do I share it with other community members? If I use it for my example standalones then everybody with minimal HTML knowlege has it anyway. So it should be OK if I make it separately downloadable with some info, may be also a helper/utility stack , and a simple link to the LC license stuff on github?
shiftLock happens
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
Hi Peter, [edit: corrected mistyped name]
LC changed a lot of things in dp14, also regarding HTML5.
Thanks for some great improvements, most striking: Behaviour of the scriptEditor.
Regarding the HTML5 standalone builder:
One important thing I can NOT reproduce, is the "return to the old speed (dp9)" by removing the 'wait' syntax. I have still a large loss of speed from dp9 to dp14.
For example clocks that are beated to display every (next) full second by
send "runMe" to me in 1000 - (the millisecs mod 1000) millisecs
and that were displaying every second on Raspi2 with a dp9-HTML5 standalone are now displaying every 5 seconds on a 3GHz machine with a dp14-HTML5 standalone.
Means: What needed < 1 sec before needs now between 4 and 5 secs.
In average I measured a speed loss by a factor of 10 from dp9 to dp14.
That's now not fast enough to display more than the seconds a simple text clock ...
Could you please give a hint to the location of the new "brake"? Then I would try to recompile according to your already given instructions.
Hermann
LC changed a lot of things in dp14, also regarding HTML5.
Thanks for some great improvements, most striking: Behaviour of the scriptEditor.
Regarding the HTML5 standalone builder:
One important thing I can NOT reproduce, is the "return to the old speed (dp9)" by removing the 'wait' syntax. I have still a large loss of speed from dp9 to dp14.
For example clocks that are beated to display every (next) full second by
send "runMe" to me in 1000 - (the millisecs mod 1000) millisecs
and that were displaying every second on Raspi2 with a dp9-HTML5 standalone are now displaying every 5 seconds on a 3GHz machine with a dp14-HTML5 standalone.
Means: What needed < 1 sec before needs now between 4 and 5 secs.
In average I measured a speed loss by a factor of 10 from dp9 to dp14.
That's now not fast enough to display more than the seconds a simple text clock ...
Could you please give a hint to the location of the new "brake"? Then I would try to recompile according to your already given instructions.
Hermann
Last edited by [-hh] on Fri Feb 05, 2016 11:29 pm, edited 1 time in total.
shiftLock happens
Re: HTML5 no wait syntax
Well, that's not good news.
I actually can't think of any good reason why the DP 14 engine should be slower than the DP 9 engine. Actually, it should be faster!
Maybe file a bug report for this, and then I will make sure it gets added at my queue of things to look at (which is unfortunately quite long at the moment).
I actually can't think of any good reason why the DP 14 engine should be slower than the DP 9 engine. Actually, it should be faster!
Maybe file a bug report for this, and then I will make sure it gets added at my queue of things to look at (which is unfortunately quite long at the moment).
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com