MonkeyCoder

[jontheramer2]

I have been working for a long time with the Monkey Language (http://monkeycoder.co.nz). Unfortunately it didn't work on the Pandora. Today I decided to bite the bullet and fix this, at least for my on-the-road coding/tinkering/testing wishes: 

https://github.com/tluyben/GLFW-3-Monkey-target

It's not 100% solid yet, but it will be soon as I work almost fulltime in this language meaning it needs to be robust for my purposes. 

Hope more people will use/learn this great toolkit and all it's modules!

 

[iprice]

It'd be great to have Monkey as another language to code with for the Pandora. I was a Blitz3D and Max user for a number of years - I still visit the BlitzBasic forum daily. Monkey just wasn't that great when i first tried it, but it looks to have come on in leaps and bounds.

Keep us informed of your progress.

 

[Pickle]

Glad to see someone that uses this is trying this, I was researching what it might take but never started. I would have to buy a license and wasnt sure if I would use it. (Just to post it GLFW port occurred here https://github.com/elmindreda/glfw/pull/6)

 

[jontheramer2]

Yes, that pull was the one that made it EGL compatible indeed. Luckily for me. It works fine now ; I'll make the process better and make a PND. 

I am wondering though; some of the libs are default only in de cdevtools; that's not very handy (I installed them outside manually); what is the best way to go? Static compile or include them or demand people to have them installed? The latter seems to not be the PND philosophy so I guess that's not it  

What I like about Monkey over Haxe is that it is just *practical*; when it runs it will most likely run on *all* targets with very little change and when you need something native it takes around the same amount as it would take to make the actual native part *only*. The native integration is very easy IMHO. 

Of course there are enough downsides; shabby debugging in the language itself, no interpreter / embeddable version and immature editors. However I can let that slide easily for the cross compilation. It's very satisfying , after a few weeks of hacking, to see that your code simply *works* on your phone (and now Pandora) without you targetting or even actively trying to support it. 

 

[mcobit]

You should just include all needed libs in the pnd.
Static compilation is a good option, too.

Choose what you like best

 

[Jimage]

Will this still work with the latest version of Monkey-X? I am considering purchasing the pro version but only if it will work for me on the Pandora.

With the freeware version, I managed to compile this app on the Pandora itself using glshim and the code generated for the desktop platform. This seems to work for a few seconds, including sound, graphics and input, but then the Pandora locks up (though the mouse movement still works). A basic app with only import mojo.app and placeholder methods has the same result.

 

[Jimage]

Hmm, so it seems there's a certain version of a library that causes this lockup. Running it from an older firmware works, allowing me to switch between windows and so forth without hanging. But if I run the dev tools package and try to run the app from within that environment, or run it in a newer copy of the OS (not the newest--trying that next) from an SD card, the lockup occurs.

Update:

Just reflashed the SD card with SuperZaxxon 1.60 and the freeze occurs there, too. The previous version that hangs was version 1.55. 1.54 is the one installed on the NAND that works correctly. Next I'll try copying the relevant libs from there and figure out which one is causing the problem.

Another Update:

Hmm, it actually still crashes on 1.54 after certain X11 events such as pressing a key or clicking the window title or the panel. I must have just been being more careful when it worked earlier.