Some thoughts about future Monkey

Monkey Archive Forums/Monkey Discussion/Some thoughts about future Monkey

AdamRedwoods(Posted 2013) [#1]
Here are some of my random thoughts about Monkey:

1. I may try to create a shared lib target for desktop. this will lead to....
2. better custom target support. if i can create a shared lib target using Monkey, this will allow us to make shared library targets that will require NO RECOMPILATION for every monkey update (MonkeyMax). easier maintenance of custom targets. this will lead to...
3. wxMonkey. i want this to to be a replacement for MaxGUI. or should i just port the darn MaxGUI thing?
4. Android NDK target
5. targets that do incremental compilations. which leads to....
6. live coding via Javascript target. hot hot hot
7. glfw3 = 64 bit. someone's working on this, how's it going?
8. multithreaded GC = multithreading desktop targets. need a better way to hook in a new GC to Monkey.

Any other ideas, please share them.

muddy_shoes(Posted 2013) [#2]
> 4. Android NDK target

Is suspect that this would be less useful than you might imagine unless the GC is improved. While native code might beat out the VM in processing grunt, the VM's GC is far better than the native Monkey one (in all but ancient Android versions).

skid(Posted 2013) [#3]
>3. ...the darn MaxGUI thing...

I started a cocoamaxgui based macos target. Will post more if anything comes of it.

For win32 desktop apps I think I prefer .net implementation of a MaxGUI style API this time around.

Midimaster(Posted 2013) [#4]
It would be helpful to support the native GUIs. Then our apps would have the same look the users are used on each target.

ziggy(Posted 2013) [#5]
wxMonkey: Any way to get an usable GC on Monkey C++ targets? AFAIK, current implementation requires Mojo, which is not nice! I remember someone (maybe you?) using a timer to call the collector on events, but this is not very realiable if you ask me.

AdamRedwoods(Posted 2013) [#6]
wxMonkey: Any way to get an usable GC on Monkey C++ targets?

it works on wxMonkey. i can call the GC after a wxIDLE event to the main window. not the best solution, but usable.

i looked into other GC's, but we need a way to overwrite the current Object class implementation.

ziggy(Posted 2013) [#7]
i can call the GC after a wxIDLE event to the main window.
How do you handle the scenario where too much memory pressure is added in a single pass between wxIDLE events? I've managed to add too much mem pressure to .Net on complex situations (like loading a complete Jungle IDE project + then modules database etc.) I'm saying this just to point out that it can work wonderfully well for small apps, but come back later as a problem when too much mem allocation is done on large irresponsive processes with lots of object creation.
I would really love to have better GC on C++ on Monkey, but maybe that's just me being too much a control freak

AdamRedwoods(Posted 2013) [#8]
I would really love to have better GC on C++ on Monkey

you are correct for these reasons, which is why i tried to implement a different GC, but the GC is embedded into arrays, so it makes any other GC difficult at this point.

AndroidAndy(Posted 2013) [#9]
5. targets that do incremental compilations. which leads to....
6. live coding via Javascript target. hot hot hot

How about:

1. Monkey interpreter. Which leads to...
2. live coding via native Monkey code. and...
3. Native Monkey debugger.

A Monkey "player" would be a given, but I would only expect one for the main dev. environment, for debugging, live coding, etc... not for deployment on general targets.

AdamRedwoods(Posted 2013) [#10]
1. Monkey interpreter.

while i would love a monkey interpreter, just looking at ParrotVM and NekoVM make my eyes water... and Monkey would have to compile to bytecode anyways, so javascript still seems like a better, quicker path.

EdzUp(Posted 2013) [#11]
All i would like to see at this point in time is easy to use system which has the same functionality as blitzmax. At the moment its not because:
1) full screen osx displays are miffed (already a bug report posted)
2) no inbuilt way to change res and switch from windows to fullscreen within a game
3) no server system
4) networking isnt as complete as blitzmax or even blitz3d
5) would be nice to specify the name of the game for all targets
6) incbin of media for all targets
7) loading from arrays or datablocks so we could do our own compression stuff (not have to write it out to disk then load)

All these things can be done with blitzmax very easily and if monkey is to 'replace' blitzmax it also will need to push into these areas as not everyone is writing small apps and coffee break games.

frank(Posted 2013) [#12]
@AdamRedwoods: Live coding via the JS platform is possible already but then you need to do it in JS using different method names than you would use in Monkey. I believe that to resolve the issue, you do need a MonkeyLanguage interpreter (which could backend only to JS and could be written in JS , but if you are making one anyway, why not write one in Monkey?). Which allows you to write 'most of' your code and compile it, but has something like MonkeyInterpret("mydynamicstuff.monkey") which executes, at that point, that file dynamically. Then, with some tinkering (I know how to do that in JS with Node.js as server), you can turn that into live coding where even the mydynamicstuff.monkey file is updated and you can copy/paste, when you are happy, the code from there into your compile regions to make it optimal. Which gives you the best of both worlds. In any case, you really need a Monkey interpreter or a very optimized and more flexible version of the current translator (aka, one who takes into account the current reflection environment and does not go over all the libraries but just translates the code you have.

I think the current parser/semanting things are way too slow for that, they are set up for a different reason, but they can be adapted i'm sure. Anyone any ideas about that? It seems that if you can include the current translation environment (which you can) flexibly (which you can't; it's very restrictive in what it does and how it works and you need to really change quite a bit), you can experiment with this. Of course in the end it's only (easily) viable for the HTML5 version, but Java/C# have on the fly in-process compilation and code swapping, so who knows.

So needing this:

- Parser which can just do standalone Monkey files; if you check/try the public methods you see you need to pass the 'world', so i'm wondering if it's possible to serialize the 'current compiled world' which you then can unserialize at program start and pass to Parser every time you need to recompile a bit. It should however not (try to) recompile any of the modules it already has (they are compiled anyway), only newly introduced, which seems something you might want to prevent in our 'poor-mans-interpreter'

- Allow a subset of Trans to work from any target; this is an issue as it currently breaks any attempt to undertake this kind of thing; it works only with C++ Tool because of the file actions. There should be a version which only inputs and outputs Strings (and possibly forbids use of Import). Input valid Monkey code, run Trans:String(code:String, lang=$LANG, target=$TARGET) and receives a String with the result.

I would really like this to work... Anyone thought about it?

If you 'just' want some REPL/livecoding but don't care if it's Monkey or whatever, you can embed JS in Monkey or Lua (as has been done with the iOS version) in Monkey or use the interpreter someone here wrote in Monkey; this should be possible for almost anything, especially with JS. I don't like this solution as, to get the full performance, you have to rewrite it. That's not a lot of work, but it's annoying (as I would have to change quite a bit in the Trans code) while I think (for someone like Mark) the above Trans features are not exactly rocket science.

Now that Monkey is on github, does Mark accept Pull requests? Because then it might actually be doable for someone (me for instance) here while not losing all the work come the next Monkey iteration.

(Haxe has hscript for this which enabled interpretation, repl, live coding and embedding in the same (subset of) language; this is a complete interpreter, not what I suggest above. In Haxe this is the only way as Haxe is not written in Haxe but in Ocaml; in Monkey the above would work I believe.)

AndroidAndy(Posted 2013) [#13]
@frank - Excellent observations, I think you touched on some viable options and approaches. When I mentioned "Monkey Interpreter" it does not imply that it is built entirely in Monkey, in fact the nature of Monkey lends itself to leveraging any one of the supported targets to piggyback off already existing and battle-tested tooling.

The reality is with limited resources developing a fully featured Monkey interpreter with the tooling around it is probably unrealistic. As Adam mentioned JS would be quicker to actually deliver something.

The nice thing about JS is that you could tap into the existing opensource tooling around it. For example you could create a Monkey debugger by a custom tool that talks to Firebug via crossfire:

I use IntelliJ IDEA and it connects to Firebug in this way and allows you to debug directly in the IDE and not have to switch out to the Firebug plugin in the browser. But I also think they developed some additional small support plugin that may give them more options.

So I could imagine a Monkey debugger that allows you to set break points, watch variables, and step through Monkey code, but it would really be talking to something like Firebug via crossfire. The tricky part would be the TRANS-lation between the Monkey code and the TRANS-lated JS running in the JS debugger.

In this scenario I think the ability to debug Monkey code is a first class citizen, the interpreter and live coding would end up being side effects.