[Mark SiblyKeymaster]

Alas, it’s not working here – I get the glClearColor changes but nothing else.

I had a quick look at the code and you appear to be linking the shader twice. Also, you need to glBindAttribute *before* linking the shader I believe.

But I fixed these and still no go so I’m not sure what’s up, will take another look tomorrow.

And thanks for the write up, will be linking to it soon!

[Mark SiblyKeymaster]

Yep, that should work. There’s also Varptr:

Monkey

Local texture:GLuint glGenTextures( 1,Varptr texture )

1 2 3

Local texture:GLuint glGenTextures( 1,Varptr texture )

And of course there always good old ‘malloc’:

Monkey

Local fp:=Cast<Float Ptr>( libc.malloc( 1024 ) ) fp[0]=1 fp[1]=2 libc.free( fp )

1 2 3 4 5

Local fp:=Cast<Float Ptr>( libc.malloc( 1024 ) ) fp[0]=1 fp[1]=2 libc.free( fp )

looks like its much closer to the “metal” than I thought which is nice…

You can indeed use it *very* close to the metal! The general idea is that if you write code without the use of pointers, the code should be 100% ‘safe’. Once you go into pointer land you’re on your own so you need to be careful, but at the same time mx2 doesn’t do anything to stop you doing this if you want/need to.

[Mark SiblyKeymaster]

are “normal” mx2 float arrays guaranteed to be contiguous in memory…

Yes, and arrays also have a ‘Data’ property that returns the raw memory used by the array in the form of a pointer, eg: an Int[] will return an Int Ptr.

You can also use a DataBuffer and poke in values using PokeFloat etc, or even a Stack<Float> which also has a Data property only it returns the underlying array, eg:

Monkey

Local buf:=New Stack<Float> For Local i:=0 until 1000 buf.Push( i ) Next Local rawData:=buf.Data.Data 'A float ptr pointing to 0,1,2,3...!

1 2 3 4 5

Local buf:=New Stack<Float> For Local i:=0 until 1000     buf.Push( i ) Next Local rawData:=buf.Data.Data    'A float ptr pointing to 0,1,2,3...!

Also note that if the stack is modified, the underlying array may have to be resized (therefore changed) so you need to be a bit careful using stack like this.

[Mark SiblyKeymaster]

But yeah going off topic a little.

Not at all, this is good stuff! The more approaches we know about, the better the chances of coming up with decent solutions.

[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

[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?

[Mark SiblyKeymaster]

the polyshape funcs definitions in shape.monkey2 still had cpBody Ptr as argument so I replaced them with cpBody.

Thanks, will fix (along with others…).

The other problem is actually ‘our’ fault! The ‘mass’ var is of type int, so when you assign 0.3 to it you’re really assigning 0, which chipmunk doesn’t like. It’d be nice to trap the error somehow too…

With that fixed it runs fine – it’s actually really fascinating watching even simple physics happening!

[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…

[Mark SiblyKeymaster]

I appear to have broken extensions…fix up at the ‘develop’ branch if you’re feeling brave. You’ll need to updatemx2cc.

[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…

[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

[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 current state of reflection is that, yes, it does add some overhead to an app so it’s now optional – you need to use #Import “<reflection>” to activate it. This is currentlyall or nothing. Eventually, reflection will be selectable on a module by module basis. I’ve reduced reflection overhead a bit and will be reducing it further in future, but reflection will never be ‘free’.

Without reflection, you can still use Variants and Typeinfo should work for built-ins types. However, all objects will always return ‘Class Object’ for typeinfo. It should be possible to add ‘minimal’ type info for all classes eventually too, even with reflection off, so you can at least inspect class names.

[Mark SiblyKeymaster]

See the glwindowtest banana for an example of using raw GL ‘inside’ mojo. The other way to go is to use SDL directly, but then you’ve got to do input etc handling yourself.

Currently, there are only GL bindings for GLES20, but longer term I’d like to do add a GLEW module that gives you access to any version of GL.

[Mark SiblyKeymaster]

but not the File->Quit from the MacOS “bar

Aha! I’d forgotten that even existed…

[Author]

Posts