Monkey now on Github!
Monkey Forums/Monkey Programming/Monkey now on Github!
| ||
| Hi, After much consideration, I've decided to move the main Monkey repos from my Dropbox account to github. Note that this wont interfere with the normal MonkeyPro releases, these will still continue as normal so you don't have to use github. My experience with community repos' in the past hasn't generally been good - it created tension between those with the ability to access the repos and those without , ie: whenever I committed something 'juicy', suddenly everyone without repos access wanted a full release! I will try and ignore this effect in future... The repos is source only and I'm using the zlib/libpng license, although this could be changed if there's enough demand. Personally, I still dig PD, but it seems to cause confusion/issues so it's probably best to go with a standard license. I've also open sourced the Monkey mojo source code and the native hmtl5 mojo code. All other Mojo code NOT in the repos remains closed source. I'm new to github but am so far loving it - esp. the cool client software. For now I just plan on getting used to it, but I do plan on bringing someone else on board to help me manage it, in particular to take care of 3rd party contributions (modules, targets etc). If you're interested, know a fair bit about github (you might be required to teach me!) and are a Monkey nut, please contact me. One final note: I'm a terrible tinkerer - stuff that shows up in the repos might be gone the next day, so please don't treat anything in there as final until it makes it into a MonkeyPro update! The repos is here: https://github.com/blitz-research/monkey |
| ||
| Excellent news!! One final note: I'm a terrible tinkerer - stuff that shows up in the repos might be gone the next day Don't feel like you need to push everything to the main repo, tinker away on your local repo and only push when you want everyone to see it! |
| ||
| > Don't feel like you need to push everything to the main repo, tinker away on your local repo and only push when you want everyone to see it! Trouble is, I bounce around between several machines many times a day at work (and have a machine at home) so I constantly need to share edits with myself. This is where Dropbox was just awesome - if it had sensible sharing and something like .gitignore I'd probably just use that (no doubt to the disgust of many). Perhaps I should be editing a different branch or something? Also, several tweaks WILL be immediately useful to some people - eg: I just made a useful fix to KeyHit. It's probably possible to transfer just that fix from my branch to the master branch (no idea what's possible), but I fear my head will explode keeping track of all this...I would like to find an approach that doesn't slow me down. |
| ||
| This is where Dropbox was just awesome Keep using Dropbox, have your local repo there so it gets shared between your machines. I do this all the time (but with Hg). but I fear my head will explode keeping track of all this Yeah I know what you mean... I like K.I.S.S :) |
| ||
| > Keep using Dropbox, have your local repo there so it gets shared between your machines. I do this all the time (but with Hg). Does that work? Can you safely stick a git repos in Dropbox? Also...the thing that I hate about dropbox is the lack of a .gitignore style file - EVERYTHING gets synced! In the case of Win8, if you don't set msvc settings correctly (turn of DB source code generation etc) that can result in a 500Meg upload just from building a banana! I've been moaning about it on the dropbox forums for a while now - it's the one thing that really keeps me from sticking EVERYTHING in dropbox - but nothing's obviously gonna happen so it's time explore a new approach anyway. |
| ||
| Does that work? Can you safely stick a git repos in Dropbox? Yep, I've done it with Git, SVN and Hg. the thing that I hate about dropbox is the lack of a .gitignore style file I think the most you can do is selectively sync folders. Just from the top of my head, you could try: * Your main master repo on GitHub * Your main local repo on Dropbox * Separate repos per machine linking to the Dropbox repo Doing it this way would save you uploading heaps to Dropbox, but you would need to Pull a lot from your local repo from the Dropbox repo per machine. It would be kind of working in a team but with yourself. |
| ||
| Sorry, already confused...you guys'll just have to live with a volatile repos until I learn a bit more! |
| ||
| Sorry, already confused...you guys'll just have to live with a volatile repos until I learn a bit more! Sorry! With GIT/Hg its a distributed repo that's why I was suggesting having multiple repos... but for the K.I.S.S approach just have the local repo in your Dropbox folder - done! |
| ||
| Yay, I've just done a successful branch/merge of a separate 'develop' branch with the master branch, as per googled recommendation! I can make all my messy changes to this branch - and they'll still be publicly available at github - and only merge with the master branch when things settle down a bit. I guess if there are other contributors it's a similar story, ie: we take turns merging with the master branch? Quick Q. Is there any real difference between branches in the blitz-research/monkey repos and other cloned branches elsewhere? Are the monkey branches at all 'special'? The branch/merge stuff in github is very cool... |
| ||
| Glad to see this move. Git is intended to make branching trivial and enable a workflow where you constantly create branches for specific features and merge them back in. In practice some people don't get on with that way of working but it can be useful even as a solo dev to branch for large-ish chunks of work. It's a personal taste thing though. If you don't get on with even having stable and dev branches then simply tagging release/stable points can guide those pulling or forking your repo. Maybe if you add an option to redirect the build output and place your output folder outside of dropbox you could resolve the synch issue you describe. |
| ||
| I was a bit surprised at the size to download the zip. I personally would consider git ignoring modules/brl/native/googleadmobadssdk as it is a bit of a pig. |
| ||
| > I personally would consider git ignoring modules/brl/native/googleadmobadssdk as it is a bit of a pig. Oops! That probably shouldn't be in there - I doubt I'm allowed to redistribute it. |
| ||
| Perhaps remove or replace with a link the targets/glfw/oalinst.exe file also. Also, you can halve the size of the bananas folder by removing horsey, but that is perhaps a step too far. |
| ||
| I think you're a bit early, April 1st isn't til next week. :-) This is great news, as long as you're willing to consider pull requests. If not, the repository is a bit of a moot point. |
| ||
| This is a good sign! Woo! http://www.mutuallyhuman.com/blog/2012/06/22/a-git-walkthrough/ http://try.github.com +1 To pull requests! There will be a lot of people who will want to help out. |
| ||
| fantastic! And Mojo for HTML5 is covered, too? I hope this expands the userbase, if it means people can more easily "try before they buy". More peepers on this project seems fantastic. Do you have a general policy for pull requests? |
| ||
| I think one of the values of paying for MonkeyPro is having the toolchain for so many targets, so I wonder about having all targets up there, aside from html5. Ultimately, though, this is just a business preference, as I would want to see Mark make money. Perhaps keeping Mojo private is enough. Otherwise, looks great. Mark: do you want us to put bug issues and feature requests up on GitHub as well? |
| ||
| The only thing that worries me is that people will be forking and making cool language changes, but if they never become part of the main repository, there's no point in using them. One of the things I added to monkey-ext (but never ended up pushing) was optional methods for interfaces. I could fork the official repo and add it, but then my code will only compile with that fork. |
| ||
| I've had zero experience with pull requests or even managing a project, so for starters I just want to get used to github. But yes, a big part of this move is to make it easier for people to contribute. For starters, I'm thinking of things like: * New targets. * Tweaks to transcc (eg; new 'builders') to support new targets etc. * 3rd party modules. However, I don't want to have to end up implicitly supporting a bunch of 3rd party modules so perhaps these should go in a new pubmodules/ dir or something? Whatever, there's a lot of stuff out there that would be nice to collect in one place. This is probably where I could do with the most help... For various reasons, I'm little less keen on major tweaks to either the language or transcc. But any minor/obvious tweaks would be welcome. |
| ||
| * 3rd party modules. However, I don't want to have to end up implicitly supporting a bunch of 3rd party modules so perhaps these should go in a new pubmodules/ dir or something? I *think* you can just add a link to someone else's repo in your repo. So I'd personally keep them out so there's no support confusion. http://git-scm.com/book/en/Git-Tools-Submodules |
| ||
| put bug issues and feature requests up on GitHub This! |
| ||
| > The only thing that worries me is that people will be forking and making cool language changes, but if they never become part of the main repository, there's no point in using them. This is true, but man, I am really, really nervous of adding any 3rd party language changes. A programming language is a reasonably complex thing - there is a LOT that can go wrong and sometimes it can be a real mind#$%! fixing things. And I'm sorry, but I just don't believe that - no matter who makes the change - I wont ever have to become involved at some point. Perhaps if I was a better coder, or the code was cleaner or something I'd feel more comfortable with it. But as things stand, no major language additions will be accepted at this time, sorry. |
| ||
| This is true, but man, I am really, really nervous of adding any 3rd party language changes. You don't have accept the changes before looking at them. Most of the stuff within Monkey only really effects compile time (such as generics). |
| ||
| > You don't have accept the changes before looking at them. Yeah, that may have come across a bit harsh, but I'm just trying to be clear about what I'm likely to accept in the way of contributions. I was mainly talking about the 'optional methods for interfaces' thing - hell, I'd be scared to write that myself, so I'm probably not likely to accept someone else's version of it just yet. Once I get a bit more experience at managing contributions, it may be that I loosen up a bit, but to start with I'm definitely more interested in 'additions' than 'modifications'. If someone does want to add, say, a module, what would be the process? Would they clone the repos, add a branch, add the module to that branch, then send me a 'pull request'? |
| ||
| If someone does want to add, say, a module, what would be the process? Would they clone the repos, add a branch, add the module to that branch, then send me a 'pull request'? Yep (I don't think they need to add a branch though, if they don't want to). |
| ||
| This is a major move in the right direction, and I share your fear of HG, its still really odd to me at times having only been using it for a few projects and nothing as complex as monkey, or as potentially volatile. I hope you can get your head around it all without to many mind fragging mistakes. quick question, as iv never done anything other people would want to grab lol, whats to stop some one just forking monkey taking it off adding in their own selection of targets and then releasing it for free? its not unfeasible that some one could fork, add all the pro targets and then release it as all open source. I am all for open source but that's a situation I for one would NOT! like to see. |
| ||
| whats to stop some one just forking monkey taking it off adding in their own selection of targets and then releasing it for free? Absolutely nothing. They've been able to do that since day one. But why would someone spend as much time as Mark has writing all the Mojo native code, then release it for free? |
| ||
| Excellent news! I'm really glad to hear that. Now it will be easier to send you fixes and improvements, I hope. I think it makes no point to continue to develop in the dropbox, now. You can use the branches to test new features and only then merge them with the master/develop branch. Git branches are very easy to use and should not be a headache. Usually in git branch is created on every big change. For example, adding a new module, new features, etc. After all the changes, they merge into the main branch. Also I would recommend to use tags. It is very convenient to store pointers to the different versions. For example, tags in flixel - https://github.com/devolonter/flixel-monkey/tags Every time the new version is released, you can add a tag to it: For example, git tag V70 git push --tags I also wanted to know whether the Issue Tracker will be used as a bug tracker and control of feature requests? |
| ||
| Mark, good luck with that. I can already imagine the posts of people who think their addition/changes should make it into the official distribution but you didn't accept it. You did a great job in the past and I hope it won't break the stability of Monkey in a general way. |
| ||
| oh iv just realized, THE DOCS ... Mark tell me you will allow more additions when it comes to the docs, I hope you consider the way php docs are done, you have the function text, its short description and then bellow that a selection of code examples of its use contributed by the php community.. I can imagine the same being possible with the docs for monkey, if you accept code contributions in the form of new html, people can add small code samples to the html of their choice , and if some one already has a code example they can just tac theirs on bellow it. the end result in our monkey docs will be something that looks like this.. http://php.net/manual/en/reserved.variables.get.php as you can see the main doc is short at the top, then bellow its user examples of the function/method/class what ever it is, in use. |
| ||
| Excellent! In my opinion a Very BRAVE thing to do. I see a lot of potential in this with this great community. Cool! I love that html5 is "FREE" now is is going to be super easy to show-off the Monkey Language to people. I think and hope it will result in more users adopting the elegance of Monkey! Using DropBox? So that means you have been programming without source control for ever? *Wow* I would probably not sleep good at night without it haha. |
| ||
| Yeah Monkey would have great use for an awesome docs-system now, but the php docs do not have that great design imo. Docs should be clean and simple to browse, easy to find in and be easy to edit for the admins imo. The great thing being that users can contribute examples! I was looking into setting up a MonkeyDoc site using Wordpress. |
| ||
| Yeah I was thinking about doing the same thing for my own personal use, but if mark is going to be open to letting us help out the docs via the repo then that will be a far better option as it will then get those docs built into the pro version. |
| ||
| This is good news and I look forward to seeing how it works out, my code lives on Dropbox across all my computers, be nice to see the process of using git. |
| ||
| personally, I like MSDN docs when it comes to docs with examples :) The only thing I really miss are searchable docs. Some built-in modules' documentation are missing descriptions, too, of course, especially new stuff and "internal" stuff. MSDN and Khronos both give an explanation for just about everything in their system. The HTML docs could easily be expanded to that level of detail, provided someone who knows how to write accessible descriptions / examples are here and want to contribute! |
| ||
| Wow interesting! So are you looking to have fixes/patches for official modules? For example those many minor "bug" reports about missing function overloads that I post. Are you happy to recieve these types of tweaks? I'd be happy for my xml module to be part of some kind of pub and I already mentioned the blitz thing in previous thread. Exciting news :) |
| ||
| Using DropBox? So that means you have been programming without source control for ever? *Wow* I would probably not sleep good at night without it haha. For my own personal projects, i still use dropbox and will continue to do so until i feel the need switch to github or any other repo (at least not yet since no one else touches my code). I do way too much subversioning source control at my day job enough already :). |
| ||
| I have a HG repository in my Dropbox. Best of both worlds :) |
| ||
| Yeah like wiebow I have hg and svn repo's in my dropbox. I mainly use dropbox because it auto syncs across all my computers, and I can sit down at any and simply pick up where I left off without needing to pull any code. its just there. However I have got an hg repo on all my main projects, and commit often on them all, but I think that's more so that I have a little more control over the source and not really because of its team work capabilities. working solo atm. |
| ||
| Jolly good! Also, you can halve the size of the bananas folder by removing horsey, but that is perhaps a step too far. Horsey will always have a safe home in my github repository. |
| ||
| rofl.... poor little horse. |
| ||
| I have a "Repositories" directory in my Dropbox with 60 different repos (Git, Hg and SVN) for every project I've ever cloned. :) |
| ||
| That's great news. Glad you decided to move it over to source control and to potentially accept pull requests for helpgul additions. Now I need to go and find out how to do pull requests myself, and work out if there's a way I can keep using Hg for my repos, or if I have to move some of them over to git. |
| ||
| Im not pro but sure I read that hg and git are so alike their software is actually able to push/pull from each others repo's , their both compatible with each other. might be wrong but sure i read that. |
| ||
| I seem to remember reading something similar, so you may be right on that one. Even if so, my directx-target repos is in a different structure, so I'll have to do some jiggery pokery no doubt. |
| ||
| I use Skydrive and sync it across a work computer, home computer, and 2 laptops. I also keep Monkey in a subfolder and then when a new version comes out I only have to update it in one place. Skydrive also gives you 7GB instead of 2GB. |
| ||
| I use a memory stick. Monkey is portable, no need for any remote stuff. |
| ||
| I use a memory stick. Until your memory stick dies. Before I used Dropbox, I had a bunch of new Diddy code on there that I very stupidly had no backup of. Memory stick died and I had to use HxD to manually read the blocks and recover the file. |
| ||
| That is why i copy it regulary to my mac too. Good or? :-) |
| ||
| A memory stick or a cloud file sharing solution will work to an extent for solo or simple projects. Once you start working in a team, or your project is quite complex, using source control is a far better solution and will increase your productivity (once you get used to it). Sure, any project CAN be "managed" through passing memory sticks about or using dropbox, but you could also write out all your sourcecode by hand and have just one team member typing it all in. It's just not a very efficient solution ;) |
| ||
| Talking about memory sticks, I had a 32 gig stick that I used for monkey and my code, I code over at my mums from time to time and it not only died on me and broke to the point the PC no longer recognized it, but I lost 5 and a half hours worth of work as a result. Never gona use a stick again for anything other than emergency situations. |
| ||
| Great move. And yes, like others said before, you can use git with dropbox. Although dropbox keeps versions itself it plays nicely with git. Remote source control VS usb stick? No contest :P |
| ||
| This GitHub iPad app is free today on AppZapp. Normally $1.99. I don't know how valuable it is, but here's the link: https://itunes.apple.com/us/app/id586045311?mt=8%3Fuo%3D4%3FpartnerId%3D30 |
| ||
| I know GitHub version is for testing/advance user. But I need to update urgent because of the Savestate() issue. Ok could you tell me how do I update from GitHub. I download zip master file. Then I unzip and copy to existing monkey folder? Then change my bin/config to match my computer spec. Is that all? I have a lot compile error here even when I compile bananas. Is my method on update correct? Mark, Could you please release urgent full installations ver:70 on user account. Special case only for this one (because of the Savestate() issue). Thanks. |
| ||
| Ver:70 is already on the user account page. Just scroll down to the bottom of the page, under experimental.. |
| ||
| Great move, Mark! :-) Can I recommend a Smart software to make your life easier? ---> http://www.sourcetreeapp.com/ |
| ||
| Mark, are you interested in me including (and pull requesting) the Diddy multithreading submodule? It has no dependencies and supports C++ targets other than Windows (unlike the BRL implementation). It supports coroutines too. The XNA implementation is incomplete, however. I'll get around to it. ;) http://code.google.com/p/diddy/source/browse/#hg%2Fsrc%2Fthreading |
| ||
| > Mark, are you interested in me including (and pull requesting) the Diddy multithreading submodule? One of the big issues with threading is memory management/GC . If any non-main thread uses 'new', or string ref counting gets interrupted by another thread, or in general does any one of a ton of potentially dangerous things, you're toast. I could attempt to come up with a list of ALL issues I can think of if you want... [edit]Although all news could theoretically be guarded by a mutex, you'd have to do it everywhere 2 threads could be potentially newing at the same time.[/edit] So your thread lib is already kind of broken because it uses box objects to return values from threads, which implies that the thread will be using 'new', so I'd be very reluctant to include it 'as is'. But in general, I do want to add as much as possible to the brl repos, and this will undoubtedly eventually include some 'unsafe' stuff. I think some kind of module rearrangement is likely to occur soon (with community consultation) to deal with the whole 'where do modules go' question, and I have a few ideas about that which I'll be bringing up soon. > It has no dependencies and supports C++ targets other than Windows (unlike the BRL implementation). Hey, mine supports posix (Mac/Linux) too! And java/c#/win8 (sort of...) |
| ||
| > Can I recommend a Smart software to make your life easier? > ---> http://www.sourcetreeapp.com/ Thanks for that! I've started using it and now prefer it to Github's client. I've even started liking the staging stuff, as it allows me to do a bunch of work on separate things in my own random way, but commit them in an apparently sane sequence. Think I'm getting the hang of git now - a big breakthrough was realising it makes more sense to merge peoples pull requests with my local repos, instead of doing it online via the github web interface. |
| ||
| But in general, I do want to add as much as possible to the brl repos what about targets? i don't mean big ones like my wxWidgets but more like my "custom target" target. i still think there's a great need for a custom target so it's not required for users to rebuild trans for things like monkeymax or a user-updated psm target. |
| ||
| You mean like interpreting the builder code? Yes, that'd be nice, but I wont be attempting it for a while yet. As for monkeymax, I'd have no problem with integrating the existing transcc code with the brl repos, ditto mojo.blitzmax.bmx - as long as they're 'usefully' functional. The PSM target transcc code's already in there, so people can tweak that if they really have to - not sure what it needs done to it though. I'll likely be open sourcing the PSM version of Mojo soon too. Yes, you still have to rebuild trans - but people will gain easy access to prebuilt versions when I do monkey updates so they'll at least be a bit easier to access. I'd also still be OK with doing the 'trans looks for trans in the target dir' hack too, but last time I put that idea forward it got nil response so I assumed it was a non starter. Although someone bought it up again recently...you? |
| ||
| You're welcome, Mr.Sibly. :) You already guessed the potential behind remote and local copies management but, browsing their website, I just discovered this little illustrated manual on Git workflows: simply outstanding!! --> http://www.atlassian.com/git/workflows |
| ||
| I'd also still be OK with doing the 'trans looks for trans in the target dir' hack too, but last time I put that idea forward it got nil response so I assumed it was a non starter. Although someone bought it up again recently...you? Yes, i thought it was a flexible idea, so i ran with it: http://monkeycoder.co.nz/Community/posts.php?topic=4932 |
| ||
| Dumb question: Is it possible to make a pull request with changes to mojo on all platforms somehow? Only PSM and HTML5 have mojo on the repository, so this makes it difficult to do in an automated fashion. If there's a private repo for the other mojo platforms, I'm interested in knowing if there's a system in place to request making commits to it. Edit: (4 months later...) There hasn't been a push to support this yet, but I'm guessing sometime soon the develop branch of Monkey should probably have support for the new free platforms. This will substantially lower the bar to make direct push requests to core Mojo now, seeing as GLFW is included. The mobile alterations can be derived from it, or the push request can be seen as a "first step" to full support, if accepted into mainline.... |
| ||
| Silly question but does the github version include all of the targets? What's the catch here? |
| ||
| It only includes Html5 and Desktop |
   |