mojox, events need to run on new fiber

[skn3Participant]

Sorry for the topic spam. I am spending some time this weekend coding, so just posting stuff as I find it.

So I have come across an issue in my app, and isolated it to a runnable example:

Monkey

[crayon-5cba820522745080753514 inline="true" ]#Import "<std>" #Import "<mojo>" #Import "<mojox>" Using std.. Using mojo.. Using mojox.. Class MyWindow Extends Window Field list:ListView Method New() Super.New("Simple Mojo Gui App",640,480,WindowFlags.Resizable) list = New ListView ContentView = list list.AddItem("click list item") list.AddItem("please click me") list.AddItem("press the left mouse on me") list.ItemClicked = Lambda(item:ListView.Item) DoFiberThing(item.Text) End End Method DoFiberThing:Void(text:String) Local value := TextDialog.Run("blah blah",text,New String[]("ok")) End End Function Main() New AppInstance New MyWindow App.Run() End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

[crayon-5cba820522745080753514 inline="true" ]#Import "<std>" #Import "<mojo>" #Import "<mojox>"   Using std.. Using mojo.. Using mojox..   Class MyWindow Extends Window Field list:ListView Method New() Super.New("Simple Mojo Gui App",640,480,WindowFlags.Resizable) list = New ListView ContentView = list list.AddItem("click list item") list.AddItem("please click me") list.AddItem("press the left mouse on me") list.ItemClicked = Lambda(item:ListView.Item) DoFiberThing(item.Text) End End Method DoFiberThing:Void(text:String) Local value := TextDialog.Run("blah blah",text,New String[]("ok")) End End   Function Main() New AppInstance New MyWindow App.Run() End

[/crayon]

Upon clicking any list item the app throws *Can’t suspend main fiber*. By looking at the mojox code this makes sense, the event handler is not run on a fiber.

At first it confused me as I had a toolbar action lambda trigger that worked fine. It seems that the mojox toolbar currently has some built-in code to circumvent this with an Async flag, indicating if the callbacks should be run on a fiber. It appears this is the only place that has this functionality.

What is the best course of action here?

Can we perhaps be allowed to instruct mojox/mojo to **always** handle events on a fiber?

[skn3Participant]

I created a small util function:

Monkey

[crayon-5cba820526b43473763655 inline="true" ]Function CallFunction:Void(func:Void()) #if __TARGET__ <> "emscripten" New Fiber(func) #Else func() #endif End

1 2 3 4 5 6 7

[crayon-5cba820526b43473763655 inline="true" ]Function CallFunction:Void(func:Void()) #if __TARGET__ <> "emscripten" New Fiber(func) #Else func() #endif End

[/crayon]

Which is used like:

Monkey

[crayon-5cba820526b49417231000 inline="true" ]list.ItemClicked = Lambda(item:ListView.Item) CallFunction(Lambda() DoFiberThing(item.Text) End) End

1 2 3 4 5

[crayon-5cba820526b49417231000 inline="true" ]list.ItemClicked = Lambda(item:ListView.Item) CallFunction(Lambda() DoFiberThing(item.Text) End) End

[/crayon]

It doesn’t work. Now it fails to build with

C:/dev/projects/monkey1/conveyor/tools/itemMaker/itemMaker.buildv1.0.91/windows_debug/src/itemMaker_classes_2utils.cpp:192:27: error: declaration of ‘t_std_fiber_Fiber l_func’ shadows a parameter

t_std_fiber_Fiber(l_func);

If I change it to the follow, then it works:

Monkey

[crayon-5cba820526b4f423063456 inline="true" ]Function CallFunction:Void(func:Void()) #if __TARGET__ <> "emscripten" New Fiber(Lambda() func() End) #Else func() #endif End

1 2 3 4 5 6 7 8 9

[crayon-5cba820526b4f423063456 inline="true" ]Function CallFunction:Void(func:Void()) #if __TARGET__ <> "emscripten" New Fiber(Lambda() func() End) #Else func() #endif End

[/crayon]

But this does seem a bit cludge!

[Mark SiblyKeymaster]

(I HATE this fancy JS editor!)

Anyway…

At first it confused me as I had a toolbar action lambda trigger that worked fine.

This is due to the ‘Action’ class which has an Async property which, if true (the default), runs triggered on a fiber. Except on emscripten, which doesn’t support fibers…

 

Can we perhaps be allowed to instruct mojox/mojo to **always** handle events on a fiber?

This is an interesting idea and something I tried once but couldn’t get working. But there have been several bugfixes since then so perhaps it’s worth trying again.

But there’s also the issue of which callbacks from App to run on a fiber. Event handlers? App.Idle? AppActivated? Everything?

Currently, Mojo is ‘fiber free’ which means it works everywhere, and callbacks at least know which fiber they’re running on! it’s a pretty simple/clean setup and I want to think pretty carefully before sacrificing that.

Anyway, this should fix your problem for now:

Monkey

list.ItemClicked = Lambda(item:ListView.Item) New Fiber( Lambda() DoFiberThing(item.Text) End ) End

1 2 3 4 5

list.ItemClicked = Lambda(item:ListView.Item)    New Fiber( Lambda() DoFiberThing(item.Text)    End ) End

Perhaps mojox should *always* create fibers for OnClicked etc code?

[Mark SiblyKeymaster]

The other alternative is:

Monkey

list.ItemClicked = DoFiberThing . . . Method DoFiberThing:Void( item:ListView.Item ) New Fiber( Lambda() Local value := TextDialog.Run("blah blah",item.Text,New String[]("ok")) End ) End

1 2 3 4 5 6 7 8 9

list.ItemClicked = DoFiberThing . . . Method DoFiberThing:Void( item:ListView.Item )    New Fiber( Lambda()       Local value := TextDialog.Run("blah blah",item.Text,New String[]("ok"))    End ) End

[skn3Participant]

Yeah the JS editor is a pain in the ass when adding code! Is there a markdown plugin for wordpress? Would be nice to use that instead! (https://en.support.wordpress.com/markdown/)

Well I guess everything would have to be on a fiber. Anything else and you are always going to find a scenario where this may happen?

Could we potentially tag our functions/lambdas as async, which indicates their calling mechanism? So it could be used like so:

Monkey

[crayon-5cba820532893193525323 inline="true" ]Function DoFiberThing:Void() Async Local value := TextDialog.Run("blah blah",text,New String[]("ok")) End list.Clicked += DoFiberThing

1 2 3 4

[crayon-5cba820532893193525323 inline="true" ]Function DoFiberThing:Void() Async Local value := TextDialog.Run("blah blah",text,New String[]("ok")) End list.Clicked += DoFiberThing

[/crayon]

or

Monkey

[crayon-5cba82053289a809462723 inline="true" ]list.Clicked += Async() 'this is a lambda, but async version End

1 2 3

[crayon-5cba82053289a809462723 inline="true" ]list.Clicked += Async() 'this is a lambda, but async version End

[/crayon]

I am surprised that emscripten doesn’t support fibers. future versions of JS will have generators, which are similar… https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*

[Mark SiblyKeymaster]

Yeah, Async’s an option, but I’m not ready to go down that road just yet, ie: having to return a ‘future’ for non-void async funcs etc. Want to explore alternatives here, as this stuff gets confusing.

Also, it doesn’t improve the situation much anyway as you can still forget to add async and end up in the same situation, althoguh it does make it easier to solve. Running ALL event handlers on a fiber does fix things, but in a too-blunt-for-my-liking way right now anyway.

The best solution for now IMO is to tweak mojox so it creates fibers when necessary so the user doesn’t even have to think about it, but I’m gonna think on this one for a while…

[skn3Participant]

When I was writing the previous reply, trying to ponder the ramifications of the Async suggestion, I did burn a few thousand braincells in the process! So yeah thats gonna be a long trip down the rabbit hole if you go that route!

The mojox thing does sound like a decent stop gap, as your not gonna break anything core in monkey2.

.

[skn3Participant]

.

[Mark SiblyKeymaster]

I think the general idea is more like:

Monkey

Function Await<T>:T( future:Future<T> ) Return future.Get() End Function AsyncFunc:Future<Int>( blah:String ) Local future:=New Future<Int> New Fiber( Lambda() Local result:=SomeBlockingFunc( blah ) future.Set( result ) End ) Return future End Function Main() Local result=Await( AsyncFunc( "Test" ) ) End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Function Await<T>:T( future:Future<T> )     Return future.Get() End   Function AsyncFunc:Future<Int>( blah:String )     Local future:=New Future<Int>     New Fiber( Lambda()          Local result:=SomeBlockingFunc( blah )          future.Set( result )     End )     Return future End   Function Main()     Local result=Await( AsyncFunc( "Test" ) ) End

…so the AsyncFunc returns it’s ‘future’ result immediately (so it can run asynchronously – calling Get() effectively blocks) and it’s up to caller to actually await the result – or not, it can also just return the future without awaiting on it and itself return immediately, leaving it up to *its* caller to await etc.

Adding ‘true’ (as in, this is what languages seem to be doing these days) async support to monkey2 would mean you’d be able to write the above async func something like this:

Monkey

Function AsyncFunc:Future<Int>( blah:String ) Async Local result:=SomeBlockingFunc( blah ) Return result 'note: we just return an Int here! End

1 2 3 4 5

Function AsyncFunc:Future<Int>( blah:String ) Async    Local result:=SomeBlockingFunc( blah )    Return result   'note: we just return an Int here! End

The compiler would then internally create the future and fiber for you, and convert ‘return’ to ‘future.Set’.

Note that my knowledge of this is purely academic – I haven’t had much experience coding like this ( a little in WinRT). I think I get it, but I also think it’s a style of coding you’ve got to really be ‘all in’ on, as it’s true benefit seems to lie in passing the future around. Perhaps someone here could clarify whether I’ve even got this right?!?

But most of all, I’m curious if I can make it easier to use…

[skn3Participant]

I removed my code above as was getting it to work. And here is the finished result

Monkey

[crayon-5cba820540b4f210664799 inline="true" ]Namespace myapp #Import "<std>" #Import "<mojo>" Using std.. Using mojo.. 'await code Function Await<T>:T(callback:Void(Resolve:Void(value:T),Yield:Void())) Local future := New Future<T> 'create fiber to handle our await Local fiber := New Fiber(Lambda() 'sleep the fiber so we get a chance to start the future Fiber.Sleep(0) 'execute callback callback(Lambda(value:T) 'Resolve() future.Set(value) End, Lambda() 'Yield() Fiber.Sleep(0) End) End) Return future.Get() End Function Main:Void() New AppInstance New MyWindow App.Run() End Class MyWindow Extends Window Method OnRender( canvas:Canvas ) Override App.RequestRender() canvas.DrawText( "Hello World! "+Rnd(0,1),Width/2,Height/2,.5,.5 ) End Method OnKeyEvent( event:KeyEvent ) Override If event.Type = EventType.KeyUp Select event.Key Case Key.Space 'create wrapper fiber so we are not executing on main fiber New Fiber(Lambda() 'await value Print Await<Int>(Lambda(Resolve:Void(value:Int), Yield:Void()) Local start := App.Millisecs While App.Millisecs - start < 3000 Yield() Wend Resolve(123) End) 'await value Print Await<Int>(Lambda(Resolve:Void(value:Int), Yield:Void()) Local start := App.Millisecs While App.Millisecs - start < 2000 Yield() Wend Resolve(555) End) End) End Endif End End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

[crayon-5cba820540b4f210664799 inline="true" ]Namespace myapp   #Import "<std>" #Import "<mojo>"   Using std.. Using mojo..   'await code Function Await<T>:T(callback:Void(Resolve:Void(value:T),Yield:Void())) Local future := New Future<T> 'create fiber to handle our await Local fiber := New Fiber(Lambda() 'sleep the fiber so we get a chance to start the future Fiber.Sleep(0) 'execute callback callback(Lambda(value:T) 'Resolve() future.Set(value) End, Lambda() 'Yield() Fiber.Sleep(0) End) End) Return future.Get() End   Function Main:Void() New AppInstance New MyWindow App.Run() End   Class MyWindow Extends Window Method OnRender( canvas:Canvas ) Override App.RequestRender() canvas.DrawText( "Hello World! "+Rnd(0,1),Width/2,Height/2,.5,.5 ) End Method OnKeyEvent( event:KeyEvent ) Override If event.Type = EventType.KeyUp Select event.Key Case Key.Space 'create wrapper fiber so we are not executing on main fiber New Fiber(Lambda() 'await value Print Await<Int>(Lambda(Resolve:Void(value:Int), Yield:Void()) Local start := App.Millisecs While App.Millisecs - start < 3000 Yield() Wend Resolve(123) End) 'await value Print Await<Int>(Lambda(Resolve:Void(value:Int), Yield:Void()) Local start := App.Millisecs While App.Millisecs - start < 2000 Yield() Wend Resolve(555) End) End) End Endif End End

[/crayon]

[skn3Participant]

Well clearly myn is a fugly LOL! I was trying to make it a self contained pattern, also similar to javascript with the commands passed to the callback/promise.

Anyway, I just tried your version and this works a charm. My example modified to yours:

Monkey

[crayon-5cba820545b30283549870 inline="true" ]Namespace myapp #Import "<std>" #Import "<mojo>" Using std.. Using mojo.. 'await code Function Await<T>:T(future:Future<T>) Return future.Get() End Function Async:Future<Int>(callback:Int()) Local future:=New Future<Int> New Fiber(Lambda() Local result:=callback() future.Set(result) End) Return future End Function Main:Void() New AppInstance New MyWindow App.Run() End Class MyWindow Extends Window Method OnRender( canvas:Canvas ) Override App.RequestRender() canvas.DrawText( "Hello World! "+Rnd(0,1),Width/2,Height/2,.5,.5 ) End Method OnKeyEvent( event:KeyEvent ) Override If event.Type = EventType.KeyUp Select event.Key Case Key.Space 'create wrapper fiber so we are not executing on main fiber New Fiber(Lambda() 'await value Print Await<Int>(Async(Lambda:Int() Local start := App.Millisecs While App.Millisecs - start < 3000 Fiber.Sleep(0) Wend Return 555 End)) Print Await<Int>(Async(Lambda:Int() Local start := App.Millisecs While App.Millisecs - start < 3000 Fiber.Sleep(0) Wend Return 123 End)) End) End Endif End End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

[crayon-5cba820545b30283549870 inline="true" ]Namespace myapp   #Import "<std>" #Import "<mojo>"   Using std.. Using mojo..   'await code Function Await<T>:T(future:Future<T>)     Return future.Get() End Function Async:Future<Int>(callback:Int())     Local future:=New Future<Int>     New Fiber(Lambda()          Local result:=callback()          future.Set(result)     End)     Return future End   Function Main:Void() New AppInstance New MyWindow App.Run() End   Class MyWindow Extends Window Method OnRender( canvas:Canvas ) Override App.RequestRender() canvas.DrawText( "Hello World! "+Rnd(0,1),Width/2,Height/2,.5,.5 ) End Method OnKeyEvent( event:KeyEvent ) Override If event.Type = EventType.KeyUp Select event.Key Case Key.Space 'create wrapper fiber so we are not executing on main fiber New Fiber(Lambda() 'await value Print Await<Int>(Async(Lambda:Int() Local start := App.Millisecs While App.Millisecs - start < 3000 Fiber.Sleep(0) Wend Return 555 End)) Print Await<Int>(Async(Lambda:Int() Local start := App.Millisecs While App.Millisecs - start < 3000 Fiber.Sleep(0) Wend Return 123 End)) End) End Endif End End

[/crayon]

So your correct about the theory. Once you start pushing around those async operations you have to keep doing so.

I have had most experience using Promises in Javascript. With those you fire off a ton of operations which signal to the promise when they are complete. Like so:

Monkey

[crayon-5cba820545b37202662729 inline="true" ]New Promise(function(resolve,reject) { 'do something blocking let success = blocking(); if (success) { resolve(123); } else { reject(new Error('uh oh)); } }).then(result) console.log(result);'123 .catch(function(err){ 'errortime })

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

[crayon-5cba820545b37202662729 inline="true" ]New Promise(function(resolve,reject) { 'do something blocking let success = blocking(); if (success) { resolve(123); } else { reject(new Error('uh oh)); } }).then(result) console.log(result);'123 .catch(function(err){ 'errortime })

[/crayon]

The awesomeness is you can keep returning new promises from your promise, or your .then() to chain together functionality into you callbacks. So you can break your code up into say, fetchUser(), generateImage(), updateCounters(), etc and have each return a promise. You can then piece together complex tasks and receive your result back in a chain of .then()’s.

There is also Promise.All([]) which fires off a list of promises at once, and then() is called once all have finished.

But anyway…

[Mark SiblyKeymaster]

I believe promises are pretty much the same as futures, or more precisely, they’re the ‘other end’ of a future, ie: you ‘get’ the promise and ‘set’ the future (or vice versa). This decouples storage from sync mechanism (apparently). Your promise code doesn’t make much sense to me though – what ‘type’ are ‘resolve’ and ‘reject’?

The ‘then’ stuff confuses me too. I encountered it in WinRT and it just didn’t make any sense. Why do this…

Monkey

dothis().then{ dothat().then{ killself(); } }

1 2 3 4 5

dothis().then{    dothat().then{       killself();    } }

…when you can (or should be able to) simpy do this:

Monkey

dothis(); dothat(); killself();

1 2 3

dothis(); dothat(); killself();

…as all you’re doing is executing some stuff in sequence?

Even if dothis(), dothat() are async, surely ‘await dothis()’, ‘await dothat()’ is nicer?

The WinRT demos were full of convoluted ‘then’ chains like this (with some very complex rules for exception handling) often just to load a bunch of resources, connect to servers etc. It just seemed nuts to me.

But thinking about it now, I guess the point is to be able to sequence *any* series of functions decided upon at runtime, passing the output of one to the input of the next? Or am I still missing the point?

[skn3Participant]

Well how about something like this:

Monkey

[crayon-5cba82054f2b2650933932 inline="true" ]function loadUser() { return fetchUserData("skn3") .then(function(user) { return downloadImage(user); }); } function fetchUserData(id) { return new Promise(resolve, reject) { return database.users.query.where('username',id) .then(function(user) { if (user.banned) { reject(new Error('access denied')); } else { resolve(user); } }); } } function downloadImage(user) { return new Promise(function(resolve, reject) { if (!network.isConnected) { reject(new Error('not connected foo)); } else { let localPath = '/localFiles/users/'+user.username+'.png'; return network.get('http://www.images.com/users/'+user.username+'.png', localPath) .then(function(image) { user.image = localPath; resolve(user); }); } }) } class userWidget() { constructor(id) { this.id = id; this.user = null; this.div = document.append this.div = document.createElement('div'); this.div.style.width = '100px'; this.div.style.height = '100px'; let that = this; this.div.addEventListener('click',function(event) { if (that.user == null) { that.load(); } }); document.body.appendChild(this.div); } load() { let that = this; loadUser(this.id) .then(function(user) { that.user = user; that.div.style.backgroundImage = 'url('+user.localPath+')'; }) .catch(function(err) { console.log('failed'); }) } }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

[crayon-5cba82054f2b2650933932 inline="true" ]function loadUser() { return fetchUserData("skn3") .then(function(user) { return downloadImage(user); }); }   function fetchUserData(id) { return new Promise(resolve, reject) { return database.users.query.where('username',id) .then(function(user) { if (user.banned) { reject(new Error('access denied')); } else { resolve(user); } }); } }   function downloadImage(user) { return new Promise(function(resolve, reject) { if (!network.isConnected) { reject(new Error('not connected foo)); } else { let localPath = '/localFiles/users/'+user.username+'.png'; return network.get('http://www.images.com/users/'+user.username+'.png', localPath) .then(function(image) { user.image = localPath; resolve(user); }); } }) }   class userWidget() { constructor(id) { this.id = id; this.user = null; this.div = document.append this.div = document.createElement('div'); this.div.style.width = '100px'; this.div.style.height = '100px'; let that = this; this.div.addEventListener('click',function(event) { if (that.user == null) { that.load(); } }); document.body.appendChild(this.div); } load() { let that = this; loadUser(this.id) .then(function(user) { that.user = user; that.div.style.backgroundImage = 'url('+user.localPath+')'; }) .catch(function(err) { console.log('failed'); }) } }

[/crayon]

I can create modular promises that can perform async operations, and then have one final destination for catching exceptions.

async and await are nice, but at the same time promises do have their merits. They fall down when you need to pass around more information then just one thing. You either have to contain the data in the parent closure, or build objects by passing it down the .then() chain. Its also possible to use Promise.all([]) and then build your object at the end. The .then() of Promise.all([]) receives an array with each promises result.

[Mark SiblyKeymaster]

Nah, still don’t get it sorry. To me, that just look like an incredibly long windowed way of executing fetchUserData followed by downloadImage!

Actually, just looking through MDN docs for promises and it’s a bit clearer now, but I can’t help feeling JS is stuck with promises because it don’t have fibers or async functions. But mx2 does and I don’t know if there’s any need for then() because of this, eg:

Monkey

Function LoadUser:Future<User>( id:String ) Local result:=New Future<User> New Fiber( Lambda() Local user:=FetchUser( id ) DownloadImage( user ) future.Set( user ) End ) Return result End

1 2 3 4 5 6 7 8 9

Function LoadUser:Future<User>( id:String )    Local result:=New Future<User>    New Fiber( Lambda()       Local user:=FetchUser( id )       DownloadImage( user )       future.Set( user )    End )    Return result End

[skn3Participant]

I think the benefit of promises cant really be shown in just one small snippet. For promises to be useful, everything has to be promises. So fetching from database, a promise. Creating an object, promise. Everything a promise. Then you can just encapsulate all your routines as promises. You can flow them together without really thinking. You can have one catch to rule them all as well. Regardless of which library the promise lives.

But pretty much your correct. Promises are are to *fix* javascript lack of async/fiber. They were also introduced to solve the problem of a nested nightmare of callbacks.

However javascript does have async/await on the horizon https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function it’s just not fully mainstream yet. I get the impression they are implementing this to *fix* the issues that promises brought with it.

But yeah going off topic a little. I agree with tyou, mx2 should not go the promise route. The async/await using fibers/futures is much nicer!

[Author]

Posts