wxMonkey
Monkey Forums/User Modules/wxMonkey
| ||
| wxMonkey v0.12 ------------- a binding of wxWidgets to monkey download: https://github.com/adamredwoods/wxMonkey **CURRENTLY HIGHLY EXPERIMENTAL** - full libraries are not available, currently in a testing and growth phase. - currently only windows with mingw, Mac osx with Xcode TO DO: - get mojo and opengl working To install, you must be able to create a new target comfortably: ..WINDOWS.. 1. download and build wxwidgets (2.8.12) as a static library (recommend non-monolithic + opengl + non-debug switches) 2. remember location of build and include files 3. copy targets/wxmonkey folder to your local monkey/targets folder 4. copy transcc/builders/wxmonkey.monkey to your local src/transcc/builders/ folder 5. rebuild src/transcc, and copy to monkey/bin folder (use the C++_STD TOOL) 6. edit targets/wxmonkey/template/CONFIG.MONKEY, make sure the paths in CONFIG point to wxWidgets paths for include, mingw (or compiler stdlibs), and wx static libs 7. compile minimal example ..OSX (10.6+).. 1. download and build wxwidgets (2.8.12) as a static library (recommend non-monolithic + opengl + non-debug switches, arch i386 no x64) 2. remember location of build and include files 3. copy targets/wxmonkey folder to your local monkey/targets folder 3b. copy xcode folder to monkey/targets/wxmonkey folder 4. copy transcc/builders/wxmonkey.monkey to your local src/transcc/builders/ folder 5. rebuild src/transcc, and copy to monkey/bin folder (use the C++_STD TOOL) 6. rebuild src/trans, and copy to monkey/bin folder 7. edit targets/wxmonkey/template/CONFIG.MONKEY, make sure the paths in CONFIG point to wxWidgets paths for include, and wx static libs 8. compile minimal example again   |
| ||
| there's also a bitmap_example which shows: - file dialog to load a JPG - displays JPG - timer that executes every one second (prints one second) - buttons - file menu - text input ...also to compile wxWidgets, i just used mingw32-make -f makefile.gcc BUILD=release USE_OPENGL=1 CFLAGS=-DwxUSE_GLCANVAS |
| ||
| Don't forget that your CC_OPTS changes are in monkey-ext too. That might be easier for some people than configuring and building trans. |
| ||
| Don't forget that your CC_OPTS changes are in monkey-ext too. I also do some crazy things by extending cppTranslator, which I stuck in the stdcpp target, so it needs to be created. That's why I replaced stdcpp (which does not effect anything else) so people don't have to mess with configuring targets.monkey. |
| ||
| velly nice, |
| ||
| update for Mac OSX version. modifies the stdcpp target, and uses an xcode project to create the app bundle. Install for OSX(10.6+) 1. download and build wxwidgets (2.8.12) as a static library (recommend non-monolithic + opengl + non-debug switches, arch i386 no x64) 2. remember location of build and include files 3. copy targets/stdcpp.monkey to your local monkey/src/trans/targets folder 4. copy xcode folder to monkey/targets/stdcpp folder 5. rebuild src/trans, and copy to monkey/bin folder 6. build the minimal app example... it will fail 7. go inside the .build folder and edit CONFIG.TXT. add the new CC_OPTS from the provided CONFIG_OSX.TXT file. 8. make sure the paths in CONFIG point to wxWidgets paths for include, and wx static libs 9. compile minimal example again, and should be successful To build the OSX wxWidgets (wxMac) library I used: If you don't have 10.5sdk, use your version. It could be possible to use the wx 2.9 version and create x64 Cocoa version. I haven't tried yet. |
| ||
| Very Very Nice |
| ||
| That looks really nice |
| ||
| How is this project working with the new target system? Looking for a nice way to make a simple crossplatform desktop-app - would be awesome to do it in Monkey. Seems wx is the way to go. |
| ||
| I haven't tried the new target system, but shouldn't be a problem. I also managed to get some of mojo working on wx, but still had some odd problems that need to get sorted out first. |
| ||
| Will wxmonkey work with minib3d? |
| ||
| not yet (i tried). i am waiting for monkeyV67 and then I will try again. |
| ||
| updated for monkey v67 https://github.com/adamredwoods/wxMonkey still trying to get mojo to work, but otherwise works ok... EDIT: I'm starting to get Mojo working on this. more to come. |
| ||
| Sounds Good! Will you be including A build of wxwidgets with the final target has i can not figger out how to build it to be honest. |
| ||
| How you handle Garbage Collection? currently non mojo c++ targets don't collect garbage, they just keep garbage growing and growing and it's never collected. I'm very interested on this for other projects I have in mind (like a SDL monkey target, or any third party 3D engine, etc, etc.) |
| ||
| How you handle Garbage Collection? I wrote a quick tutorial: http://monkeycoder.co.nz/Community/posts.php?topic=4105 In wxApps, i call the gc_collect using a wxTimer whenever the application's main window wxIDLE is called. I tried doing it every one second, but the GC was destroying modal windows. Will you be including A build of wxwidgets with the final target has i can not figger out how to build it to be honest. I can. I've also successfully gotten Mojo to work, but miniB3D is crashing hard. not sure why... |
| ||
| Couldn't it be a good idea to make a stdcpp target (that can be extended) that uses one of the avaiables Boehm Demers Weiser garbage collectors for C++? I think this would allow us to create very nice user targets for Monkey, without having to mess with the mojo-dependant GC on C++ based targets. |
| ||
| Couldn't it be a good idea to make a stdcpp target exactly what i am doing. wxMonkey can be used with or without mojo. this is due to the new monkeyV67 changes. EDIT: Updated wxMonkey instructions to clarify. |
| ||
| So you've create a base stdcpp target with a proper garbage collector? I love you. |
| ||
| with a proper garbage collector don't give me your love yet, i'm using Mark's, which is a mark-sweep. it's what monkey uses, but is not a part of mojo. is there a dire need for a better GC? |
| ||
| is there a dire need for a better GC? Yes. I'm not 100% sure on this, but as far as I know current GC does not collect automatically depending on memory presure. Instead it has to be manually called. In mojo it's called from within the app driver (after OnRender, OnUpdate, etc.) so it's transparent on glfw and it works, but on other potential targets it has to be called from the native part.If I don't misunderstand, you're calling it using a timer on wxWidgets. That's all nice and should work most of the time but, how can you balance if the timer interval is short or long enough to collect all possible garbage generated in the interval, even if the device is too fast or too slow, or it has tones of RAM or not? Then, what happens it the eventqueue is manually processed in the middle of method or function? any local variable could be potentially collected while still "alive", introducing a mem access violation. (maybe I'm missing something?) As far as I know, local variables are not took into account on current Mark GC design. This GC is designed to be realtime fast on games and that's a godsend that makes Monkey wonderful when used with Mojo, but it makes it almost unusable to create mojo-less targets that are not always driverbased. I was planing on creating a SDL target and I abandoned it just becouse of this same issue. Also I've paused my Harpl project (temporary) becouse of the same reason. |
| ||
| Then, what happens it the eventqueue is manually processed in the middle of method or function? good points, but to put a new GC in would mean i would have to rewrite most of Monkey lang.cpp since monkey strings and arrays are calling the GC directly. it might be easier to modify the current GC. i'll have to look into this when i have more free time. |
| ||
| @AdamRedwoods, it seems that mark is adding a proper generational GC to c++ target (nothing confirmed, but taking a look to github, it looks like it's on its way!) That super good news for this module (and for potential users like me). It seems you'll have to add a #GC_MODE=2 to enable the Garbage collector to meka a generational collection with a threshold of 8 MegaBytes if I don't get it wrong. It seems to be on the current in-development v71 of Monkey. I hope it gets promoted to official, as my Harpl language compiler and VM suffers from the same problem |
| ||
| right on, dude! // GC mode: // // 0 = disabled // 1 = Full GC every OnUpdate // 2 = Incremental GC every OnUpdate // 3 = Incremental GC every allocation // |
   |