January 24, 2017 at 7:45 pm #6800
I’ve opened a gitHub organization for working on the integrated docs community side.
It would be great if you participate, mainly by posting issues. For the motivated ones by trying to solve issues.
I see it based a lot on issues and requests, that way we have the user point of view.
Some monkey’s have accepted the invitation, if you want to be invited (for writing, no need to be member for posting issues I think) just ask here and give your github id so I can invite you.
-Why do you do that?
Because I often see “this should be documented” in forum posts. And because I often know the info is somewhere on the Forum but forgot the title of the topic. And there has been several post about docs, being volunteer,… This is my way to take action (I’m working on chipmunk examples too but it’s something else)
-But it’s Mark’s Job, and he said he’s working on it now, so why would you do that?
Because we are the end users and we’ll probably meet gaps or unanswered questions even after Mark has done some more work on it.
And I think that we can help Mark saving time thus us having more mx2 features!
-Will Mark use that work?
Dunno. But a good job will probably interest him or any mx2 user. I see it as a good way to learn the language deeper. So even if it’s not used, I’m happy to do it. He’s open to it in some way, said he’ll think of a way to work.(see this post: http://monkey2.monkey-x.com/forums/topic/mark-thoughts-on-help-with-example/page/2/#post-6768)
I want to start collecting issues even if he proposes another way to work with the community.
-Isn’t merging going to be a big problem?
Probably but a git is made for that. The aim is to maintain the “mergability” with the dev branch, the fork should always be up-to-date code wise. If Mark wants he’ll be able to pull it himself without hastle at a moment the docWork branch has been set up-to-date and conflict free for merging.
-What can the community do?
First posting a max of issues about things you’ve missed, don’t get,…. Then discuss what to do with that.
Adding monkeydocs too, witch can be reviewed/criticized then corrected.
Posting issues is fast and easy and can help a lot to understand where are the problems for someone using the docs for learning or as reference.
I’m ready to write thing too but my English is very limited. My mother tongue is french. So It’ll have to be corrected nearly systematically. I’ll try anyway as it’s educative for me!
-But what we need is examples!
I’m ok with that, and it would be nice to have links to examples but the docs can not be walls of code. The sample directory by module would be great for everyone, newcomers and early years monkeys.
It would be great if issues about docs were added by community on the repo.
I’m ready to check for update/merge and look at forum question to detect a question due to incomplete/not_understood doc and add issues.
I don’t care if it is only a transitional work or if it’s not used in the end. I’m sure it’ll be usefull in some way. At least for me. (learning mx2 and git)
It would be great if we manage to create nice community work and make mx2 an easy to apprehend language.
@Mark Sibly : I hope the community can do some work that’s worth taking a bit of your time for checking it. You’re of course very welcome in the organization too. I’m sorry I wrote your name so often in this post (Mark blah, He’s blah) and I hope you don’t have problems with that. When I was a monkey-x newcomer I was writing “Blitz Research” instead of “Mark”… but then I got used to read “Mark” everywhere!January 26, 2017 at 5:18 am #6814
This is a great initiative, I’ve often been curious about github and its benefits. My time is limited regarding how I can contribute, nevertheless I’m off to have a look now. Good luck with it.January 26, 2017 at 7:05 am #6817
What I want from that community work is to see all these extra docs inside of every monkey release.
How to do that? Just pooling into official repository. I think we can do the merges but after there will be considerable and nice-looking extra docs in this separate repository.
Also there is a wiki sections on github. We can ask Mark to open it. I see a way of using wiki as a temporary buffer for official docs. So anyone can write some useful info there, and Mark can grab suitable texts into official docs/examples.
I consider the wiki as an additional / intermediate resource, but which can live by itself.January 27, 2017 at 9:31 pm #6842
I’d quite like to have a play with this and see how it works out. Abakobo, if you’re OK with being in charge of making ‘pull requests’ (containing *only* docs edits please!) I’ll have a go at merging them into the official develop branch. Is this what the general idea is?
If it works, perhaps we can move the wiki+branch to official monkey2 github, but in case it doesn’t probably best to just leave it where it is for now.
One thing that may not be working yet docs-wise is linking to sample code. I think this is better than bloating out source code with samples but I’m not sure if works so for now no examples in source files please! Will look into this ASAP – it was going at one point so shouldn’t be a biggy.February 13, 2017 at 2:21 pm #7133
you can have a look at the docs WIP at http://turdus.be/monkey2docs/docs/
Index(currently half empty)
No modif of existing pages for now..
Please leave comments, critics,…
And please post issues at the github repo when you have difficulties understanding something via the docs or any other suggestion/request
thxFebruary 15, 2017 at 9:20 am #7161
Did you adapt (or planning to) monkey1 docs to monkey2 analogue?
Many things can be adapted, not need to write from scratch.February 15, 2017 at 11:53 am #7162
OMG! I didn’t even thought about it! Will do so.May 28, 2017 at 9:29 pm #8344
I’ve had the first merge conflict some days ago but it was just a little thing (preprocessor page that I started and that is now created on mx2-dev).. It’s a good occasion for me to up this post (though it’s sticked).
Sadly this has not been a community work at all.. but anyway I’d like to show you where I am (and if it’s relevant to “pull request”).
You can have a direct look at the docs WIP at http://turdus.be/monkey2docs/docs/ (updated may28)
Only the language part has been touched, no modules (well the monkey module only).
What has been added for now:
-Preprocessor (is now marks original with display problems resolved)
-Index(keywords, operators, types and preprocessor)
-Try/Catch error handling
-And an empty page with suggestions for assets imports & management.
what’s left in issues:
-importing assets, File stream stream assetdir currentdir… what about it depending on platforms (& file formats). Import wildcards and the @ token. (only a page has been created for this with htese suggestions on it)
-generics would deserve a topic? “where” and “implements” for generics type constrain are not documented.
-char_t and other libc structs are missing though they have #rem monkeydoc!
-staticIf, is it a feature?
-User defined object’s operators partly undoccumented (only visible in “Expressions>operator overloading” section)
-it would be nice if inherited properties, methods,…. were visible in the child’s section
-c2mx2 is not copying api docs
-mojo app OnBlah stuff mx1 style is now implemented as ‘signals’ in AppInstance. a note for mx1 users would be nice.
-protected, private, public: shared things when in the same .monkey2 file
I feel a bit lonely on this so i’m not shure I’ll continue as I’m not good enough in english to write it properly.
Please leave comments, critics,…
you can participate at
(the default branch of this fork is up to date with brl/dev branch as of may 28 and can be merged without conflict)
grtzJune 15, 2017 at 11:18 am #8748
There has been some docs additions from BRL recently.
The http://turdus.be/monkey2docs/docs has been updated with it (with some MarkDown corrections)June 16, 2017 at 12:30 pm #8772
extension added to user defined types section
encaplsulation (private,protected,public) added in misc section
please review if you have some timeJune 16, 2017 at 3:33 pm #8774
Thanks for your continued work in this abakobo.
Would it be possible to get the entire reference manual as a single page? Sometimes I like to print out manuals and read at leisure without a screen …June 17, 2017 at 12:55 pm #8794
here is a printable (.docx) version (it’s a 43 pages manual!):
or in .md format if you want to convert it your way:
https://github.com/mx2DocsCommunity/monkey2/blob/wipdocs/modules/monkey/docs/printableDocs.mdJune 19, 2017 at 1:10 pm #8817
Bullet physics has been added to modules! (can’t wait to see mojo 3d)
For this occasion I udated the module section on http://turdus.be/monkey2docs/docs/July 14, 2017 at 10:16 pm #9325
hey abakobo, nice work on the docs. I just read through some of the stuff you noted as new above and made a pull request to your fork with a few typo and grammar fixes. If this is helpful for you let me know and I can keep going through it.July 16, 2017 at 10:14 am #9358
If this is helpful for you let me know and I can keep going through it.
Hi arawkins, yes this is very helpfull! Because my english is bad and I won’t make pull request if the english is not corrected by a native.
I merged the pull request and invited you to be owner of the fork so you can merge by yourself if you want. No code should be modified, only docs..
To see all the changes you can see the linked “compare” page->”File changed” page. This way you’ll be able to see every new AND modified files.
You made my day!
You must be logged in to reply to this topic.