Indeed! That is the crux of the problem. Neither Android nor iOS have 'wait' (or the underlying OS feature you need to implement it) either. However those platforms have general threads so you can emulate it.
HTML5 does not have general threads (although it probably will in about 2-3 years - assuming none of the big players in effect veto the proposal at some point by choosing never to implement the spec currently being worked on) so that option is not available in (what is for us) a reasonable timescale (you all have already been waiting long enough for us to deliver it, after all!). As has been discussed about the 'async' problem with the browser widget - the wait command (and indirect forms of it - which do in browser is) actually makes many kinds of code easier to write and maintain - so it is really important in a language which professes to be 'easier' (for some definition of 'easy'). Ergo it is really important to be able to support it - however imperfect its implementation in LiveCode may be (and it is really quite imperfect - but it works!). Now the situation we are in is purely down to the current implementation of the engine and not a problem with the idea. It is the recursive nature of the engine's 'vm' implementation and UI framework code (in C++) that is causing us the headache. When I evaluated the HTML5 project I did factor in a significant amount of time (and we are talking in man years here - there's a good reason we set out to raise what we did) to solve the problem in a worst case scenario - which was (in good part) based upon the assumption that the 7 refactor would actually go a great deal further than we actually managed with the eventual budget and time constraints we were under. (What can I say - we live in an imperfect world - events often transpire to bite you in places you really wish they wouldn't!). Even with hindsight I don't think I could have done any better (not that I'm an introspective sort, at all...) Particularly as I had already noticed that some things which were being done in emscripten itself could help mitigate the problem (there's always risk in estimation of anything, always error - and there's only so much time you can spend analysing to mitigate these risks as otherwise you would end up never doing anything). Wind forward a bit - the low-level thing in emscripten which I had hoped would play a significant part became a dead end - asyncify. They have essentially abandoned it as an unviable solution - and it is at the *C++* code level - particularly at the scale of our codebase - the cyclomatic complexity is too high. 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. So I go back to doing the detailed planning of the worst case scenario - refactoring (or should I say a vigorous Moomin) of the C++ code in what is called 'continuation passing style'. This can be done - however it comes at a greater cost than my original estimates - the churn in the source it requires is far more than I am comfortable with (I have the 7 refactor over my shoulder lurking as a reminder of the cascade effects of what such large stop-the-world projects can cause) and whilst we might have a much better development and quality process now, and an ever growing test suite - it is simply not yet good enough to support this endeavour. So I am sorry to say that the first 'stable' version of the HTML5 engine is very unlikely to support wait - there are enough projects out there which do not use wait to make this perfectly reasonable. Instead we will be focusing most of our (html5 focused) energies on ensuring that as much of the rest of LiveCode as we can possibly make work in HTML5 will work as close to the other platforms as we possibly can. That includes text entry, native layers (which are actual HTML elements in this world), the clipboard, the slightly quirky (in the modern OS world) async input state features, in fact the majority of things which make LiveCode a diverse platform (in terms of the way people use it). Now, I did say 'most' of the html5 energy. The wait problem WILL be solved. I have evaluated countless other strategies in recent months (I did mention about the fact that a lot of the work we have done as not being user visible - writing code is one thing, but figuring out what code to write often takes just as long, if not longer) and after a lot of what seems like going round in circles I find myself returning to my original hope - asyncify. The asyncify idea essentially relies upon the fact you can rewrite any code which uses wait in a 'threaded style' - i.e. using callbacks (we saw that in a previous post). At the C++ level this cannot work for us - it would produce an explosion in code paths which would render the engine (and its 1.25million+ lines of code) into something no browser could load. This is because the engine is general - it is the thing which runs the specific code that you all write. So we just raise the level - we asyncify the livecode script at the point an html5 standalone is built. We write a tool - extrinsic to the existing engine code - which does the necessary analysis and rewrites the code you write automatically and transparently. At this level the analysis is tractable, the amount of code which is needed on is orders of magnitude less and (most importantly) as the tool is extrinsic it can be done without touching a single line of the existing source base - so there's no way we can break any part of the functionality of the existing engine whilst working towards this goal. So anyway, that is essentially the story of wait in HTML5. With hindsight the solution is blindingly obvious - however (as is often the case), the right solution often does not appear until you have seen all the wrong ones. Warmest Regards, Mark. Sent from my iPhone > On 28 Jul 2017, at 18:18, Jonathan Lynch via use-livecode > <use-livecode@lists.runrev.com> wrote: > > I thought that JS/HTML5 did not have a wait function? One can loop the > engine, which is horrible, or one can set timeouts for functions. What > functionality do you access to induce a wait? > > Sent from my iPhone > >> On Jul 28, 2017, at 8:29 PM, Mark Waddingham via use-livecode >> <use-livecode@lists.runrev.com> wrote: >> >> Hi Hermann, >> >> First of all please don't take any offence at my email as none was intended. >> >> I was mainly trying to explain that whilst there are many things the HTML5 >> engine does not do, which means many stacks will not work without >> changes/workarounds (indeed, somewhat significant ones) - there are >> increasing numbers of those which do work and this is set to continue and >> expand as we have more time to spend on the 'surface' features as opposed to >> the core. >> >>> On 2017-07-28 22:22, hh via use-livecode wrote: >>> Probably the "one" (=checking if the mouse is "down") pledged and bought a >>> HTML5 >>> license, the "at least other 2" (=never using it) didn't pledge nor >>> buy a license. >> >> To be honest, this really is probably not true. >> >> The thing is that 'the mouse' has long reported the event-asynchronous mouse >> state, which is almost never what you actually want on modern purely >> event-driven OSes - so over time its use has diminished as if you use it to >> do certain things (not all - admittedly), you will end up noticing >> 'interaction faults' which can be fixed by tracking mouseDown / mouseUp >> using the event loop. Also, it is generally used alongside 'wait' - which of >> course does not currently work. >> >> Obviously you do use it, as do others, so it isn't that it is not important, >> just that there are lots of other things that we have been working on in the >> HTML5 engine first which *are* used much more widely. >> >> It isn't actually possible to get the async mouse state on HTML5, so it will >> not be 100% the same (although to be fair, the approximation we can use >> there is probably more correct anyway). It is just a matter of time before >> we get it to work, not if. >> >>> I reported to quality center in Dec 2015/Jan 2016, that the state of the >>> mouse >>> and modifier keys aren't recognized and that all menu buttons crash >>> the standalone. >> >> Similarly, the modifierKeys. Text entry and keyboard states for the LiveCode >> engine in HTML5 is another what is a seemingly 'simple' thing from the >> outside, but is actually not that simple at all under the hood. >> >> We are still working on solving some issues with text entry - we will solve >> the problem in time, but again as with other facets of this endeavour some >> things are taking a lot longer than we had originally anticipated. >> >>> Since the start of this *395 thousand dollars* project in July 2014 I made >>> at >>> about 60 "successful tests" to show 'oh the HTML5 engine does this' and >>> 'oh it does that'. This wasn't easy at all, needed a _lot_ of workarounds >>> ... >> >> You've mentioned the amount of money raised several times; however, one >> thing which everyone has to appreciate is that every project we have >> crowd-funded has had the value raised matched at least by a factor of 2 from >> other sources (in some cases significantly more). My point here is not to >> undervalue the contribution that a good number of you have made, but to >> illustrate that the scale of the projects we have crowd-funded have been >> significantly larger than the dollar value we went out to the community to >> raise would suggest. >> >> Indeed, we have already spent far in excess of $400k on the HTML5 project >> when taking into account all work that we have undertake to do it (it isn't >> just each line of code which is written, but also infrastructure, >> maintenance, systems and a huge variety of other factors almost all entirely >> not user/publicly visible). >> >> There is no problem here (I assure you) - we expected it - we knew it was >> going to be a large, difficult project. However it is one which was, is, and >> remains a vital project to finish for our ecosystem as a whole and finish it >> will shall. >> >>> So I'll better stop now and wait for the suitable percentage of 'unchanged' >>> LiveCode demos (although "wait" is not allowed in HTML5 deployment). >> >> I would hope that you will continue to do as you have been - because it has >> been great to see many of the things you have achieved with the HTML5 engine >> despite its various obvious omissions in functionality. It also helps us, >> the engineering team, to see visible progress by users on a project which is >> large, long and complex (and somewhat frustrating at times!) - particularly >> when much of the work we are doing, and have been doing is entirely non-user >> visible! >> >>> What the team made in HTML deployment until now is *very* good, especially >>> the >>> "do as javascript" part is excellent. Just put more of the funds (and by >>> that >>> 'bandwidth') into it, so that also basic things (e.g. typing UTF-8 into a >>> field) >>> do work. >> >> Getting two way communication working in the HTML5 engine has been a >> significant step forward. Particularly as it means we can now do the >> absolute minimum in JavaScript and much more in LiveCode Script (what's the >> point of engineering a language, if one does not use it oneself, after all!). >> >> Indeed, I envisage a good deal of the engine functionality we need to still >> implement relative to JavaScript should start being able to be done in >> LiveCode Script - the networking stuff Michael has been working on, is an >> implementation of libUrl in LiveCode Script and uses the JavaScript >> interoperation features we have to provide its services. >> >>> p.s. HTML5 standalones can talk to each other, several of them, in one >>> browser >>> window. I just successfully tested that --- and trashed the demo. >> >> This sounds very interesting in-and-of itself (perhaps not the trashing part >> - please file a bug report if you can / have time to isolate the issue!). >> >> Warmest Regards, >> >> Mark. >> >> P.S. At some point I'll write at length about the 'wait' problem in HTML5. >> Whilst I try not to let myself be kept awake at night by engineering >> problems related to work - if ever there was one which did, it would be that >> one! >> >> -- >> 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 > > _______________________________________________ > 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
