Monkey Extras

Monkey Programming Forums/User Modules/Monkey Extras

Samah(Posted 2012) [#1]
Alright, so I've put all the public domain (ie. non-Mojo) content from MonkeyPro onto Google Code, and started up some branches for enhancements. The first complete enhancement is to add support for a MODULE_PATH configuration variable.

The branches are as follows:
default: The contents of MonkeyPro**.zip, minus the mojo module.
stable: Enhancements to the Monkey language (usually changes to trans) which have been tested and are considered "working".
development: Work-in-progress enhancements that aren't necessarily considered "usable" yet.

As Mark adds features to Monkey that make any of these redundant, they will likely be backed out, and/or branches closed.


Tibit(Posted 2012) [#2]
Great start!

therevills(Posted 2012) [#3]
I've added a couple of download links to the Google Code page so people can easily download the enhancements.

therevills(Posted 2012) [#4]
Just added DATA_PATH to the config file.

For example:

This means that you don't create a but you do create a "data" folder and store all your media in there.

therevills(Posted 2012) [#5]
Monkey-ext has been updated to Monkey v62.

fsoft(Posted 2012) [#6]
therevills, just discovered your monkey-ext project.

Sounds cool :-)

I'd like to help you out with small changes needed to compile and have monkey work on Linux. Can I join the project?

therevills(Posted 2012) [#7]
therevills, just discovered your monkey-ext project.

It's mainly Samah's project, I'm just here for the ride ;)

I'd like to help you out with small changes needed to compile and have monkey work on Linux. Can I join the project?

Sounds good to me... just to make sure your changes will just affect Monkey and not Mojo? We can't add Mojo files to this project.

Samah(Posted 2012) [#8]
fsoft just make a clone on Google Code and push your changes. I'll push to the main repo once I've looked at it. Sorry to sound paranoid, but if therevills merges the wrong thing I can actually physically hit him (and I will). ;)
Click "Create a clone" to make your own Google Code repository, then clone to your computer. Push to Google Code when you're done.

You might want to enable the queues extension to let you strip bad revisions if you commit the wrong thing before you push (I was a noob and did this the other day). Open your .hg/hgrc file and add:

mq =')
Don't forget, if you catch your mistake straight away you can rollback exactly one transaction.

fsoft(Posted 2012) [#9]
Samah, just committed my changes in my clone repository.

It is called fabiorotondo-monkey-linux

Changes are:

- Added support for Linux platform where needed
- Added new command line option "-build-all" that allows to transcode
to a target that shouldn't be supported by the hosting platform.

- Added trans_linux in the "bin" directory
- Modified config.linux.txt

Waiting for comments and critics ;-)

Samah(Posted 2012) [#10]
Changes look good, but a few things:
You should be working from the development branch, not the default. Delete and re-clone your Google Code repository to get rid of your commit, update to the development tip, reapply your changes, then push.

[monkeycode]If Html5Target.IsValid() Or build_all Then valid.Push "html5"[/monkeycode]For each of these if statements, put the build_all check first so that it will short-circuit instead of calling IsValid().

In vanilla trans, if you pass in no -target argument, you'll get "No target specified". In your version, you'll get "Command line error - invalid target:" with no target name.

Delete this existing line:
[monkeycode]If Not target Die "No target specified"[/monkeycode]and add this line between "Next" and "target=SelectTarget..."
[monkeycode]If Not target_name Die "No target specified"[/monkeycode]

fsoft(Posted 2012) [#11]
Created the new clone: fabiorotondo-monkey-linux-dev and switched to the development branch.

Applied the changes again, following your hints.

Samah(Posted 2012) [#12]
Don't forget to push. ;)

fsoft(Posted 2012) [#13]
Ops ... :-)

Actually I did, but I got a network error and I was out of office when it happened.

Now the push succeded.

Samah(Posted 2012) [#14]
Coolies, just one more thing. With your current changes, trans will always display "TRANS FAILED: No target specified" no matter what target you give it.

trans.monkey line 235:
[monkeycode]If Not target Die "No target specified"[/monkeycode]
[monkeycode]If Not target_name Die "No target specified"[/monkeycode]

Rebuild trans, commit, and push. I'd do it myself, but I haven't got a setup for compiling trans on Linux. I guess I'll have to at some point...
You don't need to blow away your changes, just commit on top of your current version. That's what development branches are for. :)

fsoft(Posted 2012) [#15]
Committend (and pushed) all the changes.

I used the new trans_linux to compile itself ;-)

fsoft(Posted 2012) [#16]
Just pushed Ted.x86 in "monkey/bin" directory. It is Ted for Linux x86 architectures. :-)

Samah(Posted 2012) [#17]
So you've tested Ted and it's all working fine? If so I'll merge with stable.

fsoft(Posted 2012) [#18]
yes, everything is working fine.
I am not sure if Ted will start at all on different platforms

I can produce a shell script to compile Ted on Linux if there are issues

therevills(Posted 2012) [#19]
Well I've finally install Ubuntu on Virtual Box and installed Hg and TortoiseHg.

Cloned the repository and managed to launch Ted.x86... and it looks good to me, but of course I can't compile anything yet as I need mojo. Downloading now.

Works pretty well, good job Fabio!

fsoft(Posted 2012) [#20]
Great! :-)

Don't you think it would be better to create a mailing list or google group related the monkey-ext? I think that sometimes this is not the right place for some messages.

Also, I have a few questions on hg (the commandline version, not tortoise) I'd like to ask to you ... :-)

Samah(Posted 2012) [#21]
Merged into stable and pushed to monkey-ext.

therevills(Posted 2012) [#22]
New zip added: Monkey v63-monkey-ext

Stable Branch:

•Modules Directory Config Option
•Data Directory Config Option
•iOS Arm v6 support
•iOS Hide the statusbar
•Linux support

AdamRedwoods(Posted 2012) [#23]
Just throwing this out there-- but i added a "CC_OPTS" option for the CONFIG.TXT file, similar to what blitzmax had from a Brucey bmk mod.

the cc_opts check I added to the stdcpp target (config method), was easy to add.

overall, it allowed me to add the "-L" or "-I" option to the compiler/linker so I didn't have to copy over the full library sources for wxWidgets. And since it's a CONFIG.TXT file, different CC_OPTS for different platforms (pc/mac).

therevills(Posted 2012) [#24]
Post the code Adam or clone the project and we'll have a look at it :)

fsoft(Posted 2012) [#25]
Adam, could you add the CC_OPTS also for the glfw target? This would help me port glfw to Linux more easyly.

AdamRedwoods(Posted 2012) [#26]

Class StdcppTarget Extends Target

Field cc_opts:String
Field use_wx:Int=0

Function IsValid()
If FileType( "stdcpp" )<>FILETYPE_DIR Return False
Select HostOS
Case "winnt"
If MINGW_PATH Return True
Case "macos"
Return True
Case "linux"
Return True

Method Begin()


Method Config$()
Local config:=New StringStack
For Local kv:=Eachin Env

If kv.Key<>"CC_OPTS"
config.Push "#define CFG_"+kv.Key+" "+kv.Value
cc_opts=cc_opts.Join([kv.Value," "])
Return config.Join( "~n" )

Method MakeTarget()

Case "debug" Env.Set "DEBUG","1"
Case "release" Env.Set "RELEASE","1"
Case "profile" Env.Set "PROFILE","1"

Local main$


main=ReplaceBlock( main,"TRANSCODE",transCode )
main=ReplaceBlock( main,"CONFIG",Config() )

SaveString main,"main.cpp"


Local out$="main_"+HostOS
DeleteFile out

Print "cc_opts: "+cc_opts

Case "macos"
Case "release"
Execute "g++ -arch i386 -read_only_relocs suppress -mmacosx-version-min=10.3 -O3 -o "+out+" main.cpp"+cc_opts
Case "debug"
Execute "g++ -arch i386 -read_only_relocs suppress -mmacosx-version-min=10.3 -o "+out+" main.cpp"+cc_opts
Case "release"
Execute "g++ -O3 -o "+out+" main.cpp "+cc_opts
Case "profile"
Execute "g++ -O3 -o "+out+" main.cpp -lwinmm "+cc_opts
Case "debug"
Execute "g++ -o "+out+" main.cpp "+cc_opts

Execute "~q"+RealPath( out )+"~q"


so then in my CONFIG.TXT in the build folder, i just set CC_OPTS to the proper line command.
unfortunately, the Key/map thing in the config function only allows one CC_OPTS, but just one-line everything.

CC_OPTS= -I"C:\Monkey\modules\wxmonkey\wxMSW-2.8.12\include" -L"c:/mingw/lib" -L"C:\Monkey\modules\wxmonkey\wxMSW-2.8.12\lib\gcc_lib" -static -lwxjpeg -lwxregex -lwxexpat -lwxmsw28_core -lwxbase28 -Wl,--subsystem,windows -mwindows -D__WXRELEASE__ -D__WXMSW__ -lstdc++ -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lodbc32

this will work for any target, just add the right lines in to the glfw target class.

Samah(Posted 2012) [#27]
I assume we can take out this line:
[monkeycode]_trans=New wxTranslator[/monkeycode]

Is it possible to do this a different way, like a separate file? CONFIG.txt appears to be only for #define CFG_ and I didn't really want to change that. It doesn't seem right putting a special case in for CC_OPTS, otherwise we'll need to do it every time you want to add another variable.

I think make another file in the same directory as CONFIG.txt. Pick a filename and change your code to load it.

AdamRedwoods(Posted 2012) [#28]
I think make another file in the same directory as CONFIG.txt

but then you're dealing with more files. i lean towards simplicity for the user end. Offhand I can't think of other options you would want at compile time.

i guess you could go the build.txt file route, where it checks for a build file and builds off that (mingw target).

Samah(Posted 2012) [#29]
I don't see the problem with another file, if we just include an empty one. The user will have it if they're using monkey-ext. It could be one line per parameter too.


therevills(Posted 2012) [#30]
I'd prefer Adam's change in the CONFIG.txt, it makes sense to keep all target configs in one place.

Samah(Posted 2012) [#31]
Guess I'm outvoted then. :)

On an unrelated note, I have array compare-by-reference working on all the targets I've tested (HTML5, Flash, stdcpp, GLFW, Android). Just gotta test out XNA, iOS, and PSM. If stdcpp and GLFW work, iOS and PSM should work. XNA should be fine too since I believe the syntax is the same.

Samah(Posted 2012) [#32]
Array compare-by-reference committed to development branch and pushed. Go go break it. ;)

marksibly(Posted 2012) [#33]

One thing to be aware of with array reference comparisons is that empty arrays might cause problems.

The C++ target (others...?) shares the same data rep for empty arrays, so comparing 2 empty arrays will always return true. Other targets don't - or, if they do, an array returned by a native call wont, eg:

Local x[],y[]
Print Int( x=y ) 'will depend on target.

You could possibly kludge the comparison so that comparing empty arrays always returns true, but that's no longer 'compare by reference' and could lead to unexpected results:

Function Blah( x[],y[],p,q )
Print Int( x[p..]=y[q..] ) 'will depend on what p and q are!

Alternately, you could remove the empty array opt altogether, but I think it's a good 'un and something I'd like to apply to more targets.

I honestly don't miss being able to compare arrays - IMO, arrays are best thought of as simple building blocks used to pass temporary data around in, or to store stuff privately. If you need a public, mutable container, use something higher level like a Stack or ArrayList or WorldMap or whatever.

Samah(Posted 2012) [#34]
One thing to be aware of with array reference comparisons is that empty arrays might cause problems.

Given that you can't change the contents of an empty array, I don't see any problem in them being considered the same "object". If the empty array comparison is going to have different results on different targets, I'd just force it to say all empty arrays are equal.

I honestly don't miss being able to compare arrays

I don't per se, but there have been a few times I've wanted to.

If you need a public, mutable container, use something higher level like a Stack or ArrayList or WorldMap or whatever.

Which has more overhead.

Samah(Posted 2012) [#35]
Adam, did you want to do the CC_OPTS thing yourself? I'll review it and push it to the master repo.

1) Clone the master Google Code repo online
2) Clone that locally
3) Update to development branch
4) Make your changes and commit
5) Push to your online clone
6) Tell me :)

AdamRedwoods(Posted 2012) [#36]
6) Tell me :)

Telling you.

oh, so i made it so CC_OPTS can be in multiple lines with anything that starts with CC_OPTS, like CC_OPTS1, CC_OPTS2, etc. Sometimes easier to edit that way.

Samah(Posted 2012) [#37]
3) Update to development branch

You applied your changes to default branch... orz

If you want I'll just copy/paste your code and put your name in the commit comments.

Edit: Would it be better to just reuse CC_OPTS and append it each time? It would make it more along the lines of how MODULE_PATH works.
Edit 2: That might be too hard actually...

AdamRedwoods(Posted 2012) [#38]
Would it be better to just reuse CC_OPTS and append it each time?
I wanted it that way, but the core "Env" is a Map-- which doesn't allow duplicates.
You applied your changes to default branch... orz

Did you mean this one? fabiorotondo-monkey-linux-dev
doh, sorry. Yes, just copy/paste it, easiest. it's just the preconfig() and +cc_opts at the end of the lines.

Samah(Posted 2012) [#39]
I grafted your changeset to the development branch (I love Mercurial) so it kept your name and timestamp. I had to add the cc_opts field though!

slenkar(Posted 2012) [#40]
how about monk for linux?

therevills(Posted 2012) [#41]
Whats wrong with Ted?

slenkar(Posted 2012) [#42]
I didnt think I would be able to compile it, ill have a go :)

jondecker76(Posted 2012) [#43]
Ted for linux would be great

I'd also like to see:
- GLFW as a linux target (there is a tutorial on it here somewhere)
- MonkeyMax included

therevills(Posted 2012) [#44]
Ted for Linux is included, thanks to fsoft.

MonkeyMax could be added, but it relies on Mojo so it wouldn't work out of the box so to speak...

For GLFW, it depends on how much Mojo is needed for the Linux change, we can not include Mojo as part of MonkeyExt.

jondecker76(Posted 2012) [#45]
The GLFW target for linux doesn't need any mojo changes. This thread details it very well:

As far as MonkeyMax relying on Mojo - isn't it standard practice for Monkey-ext users to copy mojo over from a standard monkey install? Is there a way to cleanly detect that the mojo module is available in code to enable the target?


fsoft(Posted 2012) [#46]
therevills, I am planning to port GLFW for Linux (again! :-) in monkey-ext.

Should I begin from my monkey-ext clone, on the "development" branch?

therevills(Posted 2012) [#47]

Yes, it looks like we should be able to add GFLW Linux without any Mojo troubles and since Fabio is planning on doing it anyway it sounds like a plan forward :)

isn't it standard practice for Monkey-ext users to copy mojo over from a standard monkey install?

Yep, but thats the issue. MonkeyMax alters one Mojo file which actually checks the target to see if it valid target, so if we include MonkeyMax that file would be the altered file, but then the user copies over Mojo and will blow away that change.

I guess we could include the Trans MonkeyMax changes, get the user to copy over Mojo and then get them to copy of the MojoMonkeyMax changes...

Should I begin from my monkey-ext clone, on the "development" branch?

Yep, sounds good - just remember to pull all the latest changes :)

Samah(Posted 2012) [#48]
isn't it standard practice for Monkey-ext users to copy mojo over from a standard monkey install?

I keep mojo in a separate directory and use the MODULE_PATH variable.

I guess we could include the Trans MonkeyMax changes, get the user to copy over Mojo and then get them to copy of the MojoMonkeyMax changes...

I didn't really want to include any 3rd party targets. Linux is a compilation of existing code, whereas MonkeyMax has its own project page.

muddy_shoes(Posted 2013) [#49]
I've just discovered that an attempt at using reflection causes Monkey to baulk at a potential array comparison in a generic class that never happens usually.

The situation is a bit of a mess and I'd like to look at how you've implemented array identity comparisons. The repo history doesn't have a helpful "this is where we did array comparisons" commit so any chance you could point me in the right direction?

muddy_shoes(Posted 2013) [#50]
Aha, I found it in the development branch.