A little update...

Community Forums/Monkey2 Talk/A little update...

marksibly(Posted 2015) [#1]
Hi all,

Just a quick update on what I've been working on lately:

The preprocessor has been moved fully into the parser and should be in a much more usable state now. #rem and #end are back, although I have no real objection to also adding /* and */ or equivalent if there's the demand. I do like #rem and #end though, as they nest properly, allowing you to 'comment out comments' far more easily than you can in c++.

I'm also considering changing the 'line comment' char, as I think it'd be nice to make apostrophe available for char literals. My preference for line comments would probably be '#', but then that stuffs up the preprocessor. So either the preprocessor symbol needs to change, or the line comment. Suggestions?

The preprocessor also recognizes the '#rem monkeydoc' tag, and adds the docs to the subsequent decl. I've built this into the parser because it was just so easy to do and pretty much eliminates the need for 'makedocs' (since the 'doc tree' is already there in the form of the type tree). In fact, you can now run mx2cc with a makedocs switch, and it will dump the entire type tree along with docs in JSON format. I also have an embryonic Ted2 (although Ted1 will remain the 'usable' IDE for a while yet) that uses this JSON to product a 'help' tree.

As far as online docs go, I am still against using an online system for actually editing docs (and every programmer I've talked to about this agrees). But I do think a doc annotation system where people can add comments to the docs online would be very cool.

This is all part of an ongoing effort to hopefully make things easier for IDE writers. Eventually, the plan is for IDE writers to be able to use mx2cc to generate parse/type info which they can use for auto-completion, jump to definition/uses etc. This has entailed making the compiler far better at handling errors (as opposed to just exiting on the first error ala monkey1) which, from my experience so far, is likely to be an ongoing battle!

I also whipped a little mx2toc of my own, but it's far from perfect and I think GC-Martijns python app is a better long term solution as it makes use of an existing, full featured C parser. Must learn more python! In the meantime, I've got a large chunk of SDL2 and OpenGL going.

The modules are really just experimental right now, I'm throwing things in mainly just to see how they *might* look in the long run.

One thing I'd like some opinions on right now is whether the std modules should use 'fine grained' namespaces or not, eg: should math functions go in plain 'std' or in 'std.math'? C++ throws most of it's std lib stuff in 'std', whereas C#/Java etc have pretty complex 'trees' of namespaces for their standard libs (I think).

I prefer the c++ way, because I think it actually encourages people to fully qualify stuff since it's much easier to just stick 'std.' in front of everything than std.list, std.math, std.map etc. This is what I do these days myself, whereas I used to stick 'using std' at the top of all my source files. But I also kind of like the structure finer grained namespaces give - it just makes it more of a pain to either fully qualify everything, or add a ton of Using's at the top of code. And of course, however I end up doing it is not how all modules have to do it...

The build system has been tweaked a bit so it now generates dependancy info for all c++ files, and uses this to minimize the amount of stuff that needs to be rebuilt as much as possible. This started out as a quick hack to make things more bearable, but I've ended up really liking it! It means that you can edit *any* file - even a low level guts file like bbgc.h - and exactly the right files get rebuilt. I only really have to have to delete the build dir (ie: rebuild all) if I change the compiler. There will still be a 'prebuilt' library system in there eventually, but for now the build system is pretty sweet!

Finally, much work has been done on GC and I even had a stab at adding threads - which of course, always turns out to be a much bigger and more complex job than it seems! I have a *very* rough threaded GC system going now (although I'm not 100% sure it's quite 'correct' yet) but really need some more complex code to test it with so will be returning to normal coding soon. Still, it feels to good to at least have made a start on threads and to be more aware of what it will entail. There's a pretty good series of articles about the intricacies of low-level thread code here if you're interested...

http://cbloomrants.blogspot.ca/2012/06/06-12-12-another-threading-post-index.html

...and of course, it'll be Monkey2's job to hide as much of this from users as possible!

As far as the next release goes, I will probably put something together similar to the last release soon - it'll still be rough as guts, but slightly more interesting/useful than the last release. I am a bit torn about whether to stuck it on github yet though. It is still not usable, and I'm worried that having it there will lead people to think it is in some way 'release ready'. Anyone who downloads/builds it without know the state of things will be in for a shock!

I guess I could make the github version available to patreon members - you could just send me your github account name and I'll give you access to the (as yet non-existant) private repos. Would anyone be interested in that?

Bye!
Mark


Samah(Posted 2015) [#2]
@marksibly: I also have an embryonic Ted2...

Could you please not use Qt? Any program that uses it pops up an error dialog on startup if you have Wacom tablet drivers installed. It's a well-known bug and the Qt developers basically just said "meh".

@marksibly: Must learn more python!

Better warm up that tab key!

@marksibly: This is what I do these days myself, whereas I used to stick 'using std' at the top of all my source files.

Java, C#, C++, Python all support this.

@marksibly: Finally, much work has been done on GC and I even had a stab at adding threads...

It would be awesome if you could put some magic for coroutines/continuations directly into the syntax. It's technically not "multi-threading", but threads can help implement it. Check out Diddy's implementation.
https://github.com/swoolcock/diddy/blob/master/src/threading/coroutine.monkey
Function Foo:Void()
	<do some code here>
	' temporarily return control to the calling function, return value of Resume will be 1
	Local val:Int = Yield(1)
	Print val ' prints 10
End

' function pointer to Foo
Local func:(func pointer) = Foo

' start Foo as a coroutine, return value of Resume will be arg to Yield()
Local val:Int = func.Resume()
Print val ' prints 1

' resume Foo, return value for Yield() will be 10
func.Resume(10)


Github username is swoolcock, as with Diddy.


DruggedBunny(Posted 2015) [#3]

you could just send me your github account name and I'll give you access to the (as yet non-existant) private repos


Would give me a reason to start using my Github account!

This all sounds really cool anyway.


Nobuyuki(Posted 2015) [#4]
I'm also considering changing the 'line comment' char, as I think it'd be nice to make apostrophe available for char literals. My preference for line comments would probably be '#', but then that stuffs up the preprocessor. So either the preprocessor symbol needs to change, or the line comment. Suggestions?


Keep both as-is? What do you want to use this for? Char literals? I'm fine with the current convention, although you could always use some other kind of sigil for this (VB appends a c to the end of a string after the quotes to indicate a char literal).

One thing I'd like some opinions on right now is whether the std modules should use 'fine grained' namespaces or not, eg: should math functions go in plain 'std' or in 'std.math'? C++ throws most of it's std lib stuff in 'std', whereas C#/Java etc have pretty complex 'trees' of namespaces for their standard libs (I think).


Depends on how you can import namespaces I suppose? Using a big hierarchy to organize classes into namespaces can be a problem if they're not put in the right place the first time, but they provide the advantage of being relatively easy to look for with a good IDE, and also easy to find in the documentation without a search tool. I personally prefer fully-qualifying stuff, too, especially when the namespace operator and the member fetch operator are one and the same (preferably "."). That being said, I probably would import std at the top of my projects if they're not a huge mess. Or maybe I wouldn't, if I don't plan on using most of it! (the way the brl module arranges things is pretty decent...)

Finally, much work has been done on GC and I even had a stab at adding threads - which of course, always turns out to be a much bigger and more complex job than it seems! I have a *very* rough threaded GC system going now (although I'm not 100% sure it's quite 'correct' yet) but really need some more complex code to test it with so will be returning to normal coding soon.


Anything to reduce frame thrash and have to think less about "lower-level" optimizations is a win in my book.

As far as the next release goes, I will probably put something together similar to the last release soon - it'll still be rough as guts, but slightly more interesting/useful than the last release. I am a bit torn about whether to stuck it on github yet though. It is still not usable, and I'm worried that having it there will lead people to think it is in some way 'release ready'. Anyone who downloads/builds it without know the state of things will be in for a shock!


In my experience, no one uses public source on github if it's left mostly undocumented and without a website... The code just kinda "sits there", waiting for someone to come along and explain it to the public. The people who know what to use it for are typically ready to dig in themselves. That being said..... I'd still be interested in taking a peek, if only to see the commit messages :V


Samah(Posted 2015) [#5]
@Nobuyuki: I'd still be interested in taking a peek, if only to see the commit messages :V

Ten dollars on one changeset: "Initial commit."


Xaron(Posted 2015) [#6]
Count me in. My GitHub account name is the same as my forum name here. :)


dawlane(Posted 2015) [#7]
@Samah: Unfortunately Qt is possibly the best cross platform GUI frame work out there. I've used a GTK, FLTK, wxWidgets on Windows, OS X and Linux. And I have found that Qt is the better choice.
I did stumble across a blog last year that stated that support of Wacom had been improved in Qt 5.4 for Windows and OS X. There was a few articles claiming that it was going to be dropped altogether.


Shagwana(Posted 2015) [#8]
What is "GC-Martijns python app", got a link?


tiresius(Posted 2015) [#9]
I'm also considering changing the 'line comment' char, as I think it'd be nice to make apostrophe available for char literals.

I've grown rather fond of ' as a comment. Another Basic dialect uses ` for comments which I found harder to type (once I got used to Monkey's ', that is)

What about `' pairs for character literals and leave ' as a comment ?


ziggy(Posted 2015) [#10]
Great news!
I would not use /* and */ for comments, unless they accept nesting, which, in this case, I prefer #REM and #END. That said, single comment character, I like ! myself. It makes comments sort of important :) Love the single quotes being used for char literals.
Also, all the GC stuff is very promising. Threading + anonymous functions + interfaces allow for very powerful and nice designs.


Pharmhaus(Posted 2015) [#11]
Awesome :D. My GitHub Account name is Pharmhaus-2.

I've grown rather fond of ' as a comment.


Me too. All these C style comments and what people come up with are hard to type as hell.


I'm also considering changing the 'line comment' char, as I think it'd be nice to make apostrophe available for char literals.


To be honest the number of times I used char literals in my C# projects have been pretty low.
I would rather change the char literal maybe even to "" (unpopular opinion probably).


One thing I'd like some opinions on right now is whether the std modules should use 'fine grained' namespaces or not, eg: should math functions go in plain 'std' or in 'std.math'? C++ throws most of it's std lib stuff in 'std', whereas C#/Java etc have pretty complex 'trees' of namespaces for their standard libs (I think).


More finegrained namespaces would make sense to me but only if import would eleminate typing the full namespace by default.
Its just pure pain to type ExtremeLongNameSpace.ExtremeObfuscatedSubNameSpace.Something just to use Print.
I know that a lot of purist really *love* this but the day I get confused which Print() or Sin() to use has no yet come any close to me.
Think of System.Runtime.Remoting.Metadata.W3cXsd2001 the namespace in C# to convert bytes to base16, back and forth.
No sane being on earth would ever type that out of intuition.
If you need to fire up google or the forum search for every tiny thing that you would like to do then its not a win for me.


GC-Martijn(Posted 2015) [#12]
@Shagwana
https://github.com/gcmartijn/C2MX2

I did take a short break waiting for the next release etc.
It's very rough alpha testing code at the moment, and is not written perfect.
(and it was my first github project)


Nobuyuki(Posted 2015) [#13]
I would not use /* and */ for comments, unless they accept nesting, which, in this case, I prefer #REM and #END. That said, single comment character, I like ! myself. It makes comments sort of important :) Love the single quotes being used for char literals.


any character for comments that requires me to press the shift key (or for foreign guys to press AltGr) seems like it would be a non-starter for me. That's just my personal opinion, however! Using single quotes for char literals reminds me too much of Perl's garbage mess of quotes and even if the apostrophe weren't already being used for something, seems like a waste of a unique symbol at plane 0, where no modifier keys are required. I heard one convincing argument against the current convention, that it unduly troubles QWERTZ (and likely other non-us104 keyboard users) to type "a"[0] due to the square brackets and double quotes. I'd prefer appropriating a context-specific sigil for this purpose, the way VB does, or using the grave accent character instead (which isn't already in use): `a`

I had a check and noticed that BS 4822 has the grave accent on plane 0 in the same place as US-104, so there's no worries there. Grave accents are on plane 1 with QWERTZ, a mere Shift away. This seems more acceptable a compromise to me to improve the current char literal situation, because 1. it doesn't change the current commenting convention, and 2. Comments are used way more than char literals are throughout code, or at least they should be.


Playniax(Posted 2015) [#14]
Nice to see some real progress! :)


marksibly(Posted 2015) [#15]
> (VB appends a c to the end of a string after the quotes to indicate a char literal)

I quite like this general approach - some kind of less ugly shortcut for "X"[0]...

Changing ' and # does seem a bit drastic for the sake of char literals, esp. as the rest of monkey2 is turning out to be highly backward compatible.


Samah(Posted 2015) [#16]
@dawlane: Unfortunately Qt is possibly the best cross platform GUI frame work out there.

Assuming you're restricting yourself to C++.


dawlane(Posted 2015) [#17]
Assuming you're restricting yourself to C++.
Not sure what you mean by that Samah. There are other language bindings for the many of the cross platform GUI frame works out there, and Qt is no exception with the most popular language being used for many is Python. There are even binding for Free Pascal for Qt4 that can be used when using the Lazarus IDE.


PixelPaladin(Posted 2015) [#18]
Sounds really great!

@marksibly: I'm also considering changing the 'line comment' char [...]


Some modern languages like python or ruby use # for comments. At the same time these languages do not really have a preprocessor. Languages which use a preprocessor mostly use # for preprocessor directives – so maybe # should stay for the preprocessor.
To use ' for single characters we only need something different for comments. I would personally prefer -- like in Lua (should be no problem since Monkey does not have a -- operator like c, c++) or ; like in BlitzBasic.
If # should become the new character for comments then what about ~ for preprocessor directives?

Please don't use ` for comments because it is hard to type.


skid(Posted 2015) [#19]

I am a bit torn about whether to stuck it on github yet though. It is still not usable, and I'm worried that having it there will lead people to think it is in some way 'release ready'. Anyone who downloads/builds it without know the state of things will be in for a shock!



I think the next drop would be good for IDE developers. I'm more than keen to add the intelli-token stuff to Monk.

And looking forward to seeing if community tools on github are any use, the bug tracking one I think would be good to test.

How about Chr$(int) and Char%(String) operators?


Samah(Posted 2015) [#20]
@skid: How about Chr$(int) and Char%(String) operators?

Isn't the Basic de facto standard for char->int the Asc() function?


skid(Posted 2015) [#21]

Isn't the Basic de facto standard for char->int the Asc() function?



Yes, but that would be a misnomer as it is returning a complete 32 bit character code and not a 7 or 8 bit ascii value.

On second thought I think I prefer "A"[0] over Char("A") for sake of backward compatibility


GW_(Posted 2015) [#22]
Great news!
I'd hate to see the single quote go away, I'm quite fond of it, but If it had to go, I would prefer something that didn't require a the <shift> key to type.
It may sound flippant, but the fewer hits to shift key are better all around. C style '//' would be a decent compromise.
As for releases, I say put it on the these forums until you reach an alpha/beta state that you're comfortable with wider exposure/judgement.
With the libs, I agree with Pharmhaus. I like the ease and intuitiveness of saying: :framework brl.basic; Import brl.glmax2d: and then I can go to town and not worry about getting syntax errors for the next 5 mins while having to fine tune all the imports.


Xaron(Posted 2015) [#23]
Well GW, for German keyboards you always have to press shift, that's true for ' and // as well. :D


GC-Martijn(Posted 2015) [#24]
I don't have to press shift for this: // ' (osx)
both keys are next to each other. I don't care if it's ' or //


Richard Betson(Posted 2015) [#25]
Yay, news. :)

I am cool with whatever for line comments but I prefer " ' " (Apostrophe) as I have used it all along here in Monkey and BlitzMax. On qualifying imported libraries, just remember that some of us will need to be 'headless' in some of our applications. ;)

you could just send me your github account name and I'll give you access to the (as yet non-existant) private repos

Can't wait for another go at MX2 and my git hub account stands by (RichardBetson) and already following.


MikeHart(Posted 2015) [#26]
' is fine with me. But I also love //


AndroidAndy(Posted 2015) [#27]
+1 for #rem and #end due to the nesting benefits you described, but it would be nice to be able to use c style /* */ especially when porting c style code from other languages to MX2.

+1 for changing inline comments from ' (apostrophe) to // and freeing up ' (apostrophe) for string literals.

Another option for ' in string literals is to use c style escape \' so "That\'s Good!" or double up the apostrophe for "That''s Real Good". I guess the biggest concern of changing the inline comment from ' (apostrophe) is what happens when existing Monkey code is ported, will there be a simple way to deal with that?


Shinkiro1(Posted 2015) [#28]
# comments would 'fit' the language better I think, it's just that the preprocessor already used that
// is still better than ' imo


Samah(Posted 2015) [#29]
#Rem
#End
' foo

Done.


dawlane(Posted 2015) [#30]
Personally I think that the (#)End is too ambiguous and should be more explicit such as (#)End(closing statement).
e.g #Rem/#EndRem, Select/EndSelect etc.
How end is current used can leave it too open for errors to creep in and reported errors can be some what misleading.


PixelPaladin(Posted 2015) [#31]
For compatibility reasons it would be nice to keep # for preprocessor directives and ' for comments. For single characters ` (accent) could be used (it may be harder to type but will not be used this often).

#rem
#end
' comment
If a = `*` Then Foo()


But please don't use //.


dawlane(Posted 2015) [#32]
@marksibly: I think with some of the changes your are thinking of doing; then backward compatibility with MX1 should go out of the window.
Maybe the hash(#) should strictly be for preprocessing, the colon (:) as a statement separator for single line commands as it was used in the 80's BASIC languages, the single quote for single character type as in C/C++ and comments being actual commands or the use of a semi-colon(;) . e.g.
; This is a single line comment
Rem This is a single line comment
RemStart
This is
A multi-line comment
RemEnd


Danilo(Posted 2015) [#33]
@dawlane:
The colon (:) is reserved for type declarations in Monkey. x:Int, func:Byte(), ...
Using it as statement separator would require different type declarations, too.
In this case it would be a completely different language, not an iteration in the sense of MX v1, v2, v3, ...


secondgear(Posted 2015) [#34]
I think PixelPaladin nailed it: keep it compatible with old Monkey code and use ` for chars.


Samah(Posted 2015) [#35]
@secondgear: I think PixelPaladin nailed it: keep it compatible with old Monkey code and use ` for chars.

Agreed. I like the idea of having syntax for char literals, but changing single line comments so we can use apostrophes is just silly. Backtick is probably good enough.

Most people's suggestions here have been "I'm used to X language and that does it a certain way, so MX2 should do it that way." There really is no need to change it. BlitzMax and Monkey-X have done fine as they are.


nullterm(Posted 2015) [#36]
@marksibly, If you setup a github, I'm nullterm there too. Thanks!


DruggedBunny(Posted 2015) [#37]
My Github's DruggedBunny BTW!


k.o.g.(Posted 2015) [#38]
My Github account: 7sevenx7


Playniax(Posted 2015) [#39]
My Github account: playniax


Xaron(Posted 2015) [#40]
My Github account: KrautApps


Nobuyuki(Posted 2015) [#41]
Github: nobuyukinyuu


degac(Posted 2015) [#42]
Hi to all.
There's some real progress?
I mean for 'comment markers' ('. #rem, // and so on), general dev environment and so on.
I'm 'thinking' to start to write something in MX1 (and converting some stuff I wrote eons ago to mojo2) and considering my times to complete something (=months) I would avoid to rewrite (again) stuff to port it to MX2.

ps: I don't want the Github access to look around... it's just like watching a surgeon during an operation...things can change! :D I just want a simple update on these things
Thanks!


ziggy(Posted 2015) [#43]
Are we finally getting Monkey2 source dode? Just in case, I'm ziggybcn at github


Simonsuuri(Posted 2015) [#44]
if ' will be replaced i would like // for single line comment,
i have anyways used lately both of those in my comments just to get comment pop out from code, little better like;
' // PLAYER MOVEMENT // '


Samah(Posted 2015) [#45]
@Simonsuuri: ' // PLAYER MOVEMENT // '

''''' PLAYER MOVEMENT '''''

I generally find that suffices for breaking up code chunks.


nullterm(Posted 2015) [#46]
I understand about using ' for strings (Python) or chars (C), but I'd still like to see it stay as comment marker for monkey.

Char literals are so relatively rare compared to strings and comments, I'd almost prefer to stick to simple length 1 string and have Chr/Ord to convert.

I prefer the single data type with lots of functionality approach. Everytime you specialize for specific cases (char = length 1 string) then the conversions back n forth add complication.


Samah(Posted 2015) [#47]
@nullterm: I understand about using ' for strings (Python) or chars (C), but I'd still like to see it stay as comment marker for monkey.

Char literals are so relatively rare compared to strings and comments, I'd almost prefer to stick to simple length 1 string and have Chr/Ord to convert.

I prefer the single data type with lots of functionality approach. Everytime you specialize for specific cases (char = length 1 string) then the conversions back n forth add complication.

+1 to all of that.


Samah(Posted 2015) [#48]
@marksibly: I guess I could make the github version available to patreon members - you could just send me your github account name and I'll give you access to the (as yet non-existant) private repos. Would anyone be interested in that?

Any word on this yet? Itching to play with it.


abakobo(Posted 2015) [#49]
my github has the same name as this id... and i'll be happy to see it during my october hollidays!


GW_(Posted 2015) [#50]
and those who don't use github are left out of the fun.


DruggedBunny(Posted 2015) [#51]
Not if they create an account...


nullterm(Posted 2015) [#52]
Think people are jumping the gun. I think the github for backers is still in the idea stage. : ) "When it's ready" as they say.


MaxPower(Posted 2015) [#53]
I thought i read on Mark Sibley`s blog that Monkey 2 was going to be free for Monkey Pro buyers.So why do i have to be a patreon donator,to test Monkey 2.mind boggled.

I AM!!! going to say it "STOP RIPPING YOUR LOYAL CUSTOMERS OFF".To make money and bring out something that is finished.Been using Blitz Products since Blitz 1
on the ST/Amiga.It is very sad to see what you are doing.Ban me for having an opinion Sham on you.


Qube(Posted 2015) [#54]
I thought i read on Mark Sibley`s blog that Monkey 2 was going to be free for Monkey Pro buyers.So why do i have to be a patreon donator,to test Monkey 2.mind boggled

It will be free when it's ready. At the moment it's in such an early state that Mark just wanted to provide donators a little look as a thanks.

Hope that's un-boggled your mind.


nullterm(Posted 2015) [#55]
Exactly. I find it boggling that someone would jump on a forum to rip a product and developer that hasn't finished yet. Oh wait... internet... I know.

I'm a Patreon supporter cause I wanna support Mark's effort to build Monkey 2. I've loved his products for a long time now and know he's taking it in a good direction from what he's said and allowed a peek at.

If that gives me the odd sneak peak under the covers, well that's just gravy. It'll be the meat and potatoes release I'm eagerly and patiently waiting for. I'd rather wait for a properly cooked meal than get something half baked.


GW_(Posted 2015) [#56]
Seriously, Mark'a given away and open sourced more stuff than just about anyone, doesn't charge for bug fixes or subscriptions.
Monkey took about a year to stabilize and Blitzmax about the same amount of time. It's ready when it's ready. M2 will be totally worth the any wait.
I'd just prefer not to be left out because I don't use github though.


Samah(Posted 2015) [#57]
@GW_: I'd just prefer not to be left out because I don't use github though.

It's that hard to create an account? Once Mark's given access you don't even need to install a Git client. Just click the nice big "download" button.


Qube(Posted 2015) [#58]
I AM!!! going to say it "STOP RIPPING YOUR LOYAL CUSTOMERS OFF"

You added this after I replied to your original post... You must be having a laugh considering the quality and price BRL have charged over the years for their products, right?. BRL have always in my opinion undercharged considering the quality of the language you get in return + free updates.

Don't get me wrong. I've been vocal about BRL producing game based languages of the past vs Monkey ( I bought Monkey within 48hrs of it's release ) and a few days ago I purchased Monkey X Studio plus a Pyro license. The quality and time this little lot will save me is an absolute bargain. Less than £200 for a multi device language + excellent IDE and two top notch 2D frameworks is a no brainer. Anyway, I digress...

Monkey 2 will be free when Mark feels it's ready for public release and I fail to see how that can be a rip-off?.


Danilo(Posted 2015) [#59]
Removed blah blah, sorry.


EdzUp(Posted 2015) [#60]
I still think that Blitzmax should be updated like bmx-ng proves it can be done.

Max was the best language BRL made but sadly neglected in favour of mx1, no it's not feature complete there are still bugs which need addressing but will never be addressed.

It was to this end I made a decision to jump to C++ and make my own engine which I have started.


Playniax(Posted 2015) [#61]
Max was the best language BRL made


I get why in some respects someone will find Blitzmax better but Monkey is the superior language.


EdzUp(Posted 2015) [#62]
Not to be argumentative but if monkey was the better language why mx2?

From my perspective monkey looks like a cut down Max with additions for mobile targets, its this which seems like a step back.

Brucey has already proven Max can be extended to support mobile targets with more work it would be a better replacement than monkey tbh.


Playniax(Posted 2015) [#63]
I mean language wise Monkey is better and more modern (for example interfaces, case sensitivity (yes, I think CASE SENSITIVITY is better :), etc.)

Max in some areas is more capable (for example, Max has better file system support, pixmaps, etc.)

I am experienced in both and there is almost nothing I can't do with Monkey that I can do with Max.
But for example, writing tools is easier in Max simply because of the file system support.

why mx2?

Max is getting older and Monkey is limited by the way html5 is supported now.
Max does not have mobile support.
I guess Mark wants to adress these shortcomings and create something that combines the strengths of both.

I think MX2 will be the 'perfect' marriage between the 2.


Playniax(Posted 2015) [#64]
"STOP RIPPING YOUR LOYAL CUSTOMERS OFF"


Yeah, I payed 99 dollars 3 or 4 years ago and I am only getting endless support, updates and improvements without paying a cent extra. Not forgetting all the fun I had to go through coding countless of hours thanks to Monkey. Sure sounds like a rip off! seriously?


EdzUp(Posted 2015) [#65]
I mean language wise Monkey is better and more modern (for example interfaces, case sensitivity (yes, I think CASE SENSITIVITY is better :), etc.)

Yes I agree case sensitivity is brilliant its why I use Code::Blocks with C++.


Max in some areas is more capable (for example, Max has better file system support, pixmaps, etc.)

I am experienced in both and there is almost nothing I can't do with Monkey that I can do with Max.

Editing images, pixmaps, audio etc all are easier in max, also loading media from buffers as well is so much easier. Its these that i wanted in monkey but never got as its internal it would be impossible to implement audio loading from a byte array.



But for example, writing tools is easier in Max simply because of the file system support.


Yeah its so much easier to write tools in Max even with MaxGUI as it is.



why mx2?
Max is getting older and Monkey is limited by the way html5 is supported now.

MX2 is getting HTML5 iirc



Max does not have mobile support.

Brucey has proven its not only viable in theory but possible with bmx-ng, Max digesteroids on ios and android would seem to indicate that statement is false.



I guess Mark wants to adress these shortcomings and create something that combines the strengths of both.

I think MX2 will be the 'perfect' marriage between the 2.

I hope for BRLs sake that it's the be all end all language that does it all for the future as keep reinventing the wheel every few years is killing interest and one of the reasons I chose C++ over MX2. I'm not getting any younger and going from bb2d>>b3d>>Max>>monkey learning it all as I go its headache inducing so I chose C++ as once done I can add to it as required and do my own thing. Nothing against MX2 but I chose to do things differently instead of learning MX2 or mojo2 which is different from mojo I chose OpenGL/OpenAL and C++.


Playniax(Posted 2015) [#66]
Like you, not to be argumentative but... :)

MX2 is getting HTML5 iirc


Initially he took it out because it was the common lowest denominator holding MX1 back. Using emscripten should solve that problem.

Brucey has proven its not only viable in theory but possible with bmx-ng, Max digesteroids on ios and android would seem to indicate that statement is false


I don't see why that statement is false but next time I will add the word 'originally' :)

Anyway, at he end it is just about the right tool for the job and MX1 is perfect for me. I have no doubt MX2 will be better.


therevills(Posted 2015) [#67]
Brucey has proven its not only viable in theory but possible with bmx-ng, Max digesteroids on ios and android would seem to indicate that statement is false

You could argue (and we are not being argumentative in this thread ;)) that BMX-NG, isnt BlitzMax anymore it just uses BlitzMax's syntax...


MaxPower(Posted 2015) [#68]
@Playniax not ripping ppl off.He does not finish 1 coding language,then starts another one asking for money ie:Patreon behave yourself.

The guys had the ultimate coding language,"BlitzMax"in his hands and he decided to leave it.He could of created a compiler for Max ,he done it for Monkey.Should have followed the path.Mr Sibley.


skid(Posted 2015) [#69]
What an extraordinary display of self entitlement.


Difference(Posted 2015) [#70]
HELP! I mistakenly starred MaxPowers post. How do unstar?

I, as most others, think Mark is doing a great job, and are totally happy with Monkeys progress.


Amon(Posted 2015) [#71]
""STOP RIPPING YOUR LOYAL CUSTOMERS OFF""


Comments like this are only fueled by an ignorant perception of a subject. The comment author is clearly not able to fully understand what is happening and results in the "Spewing Of Mouthage". Proof of that is in the statement:

I thought i read on Mark Sibley`s blog that Monkey 2 was going to be free for Monkey Pro buyers.So why do i have to be a patreon donator,to test Monkey 2


To add further proof the author of these comments is, and I quote,
mind boggled
.

***NOTE***
The activity known as "Spewing Of Mouthage" is a term coined by myself, Amon, to describe in a clean way people who make comments and posts on forums where they are clearly "Chatting Sh&*t".


EdzUp(Posted 2015) [#72]
You could argue (and we are not being argumentative in this thread ;)) that BMX-NG, isnt BlitzMax anymore it just uses BlitzMax's syntax...


It's a different direction but its still Max it just shows there is life in the old dog yet, I would like to see it brought up to date giving it new life. MX2 is a nice idea but I hope it lives up to the hype


skape(Posted 2015) [#73]
not ripping ppl off.He does not finish 1 coding language,then starts another one asking for money ie:Patreon behave yourself.


O_o

Who said MX1 "isn't finished?" It is 100% usable in its current state and you began using it without any rightful expectation of a certain length of time for "improvements..."

Anyhow, Mark hasn't indicated that he is abandoning MX1 completely...


therevills(Posted 2015) [#74]
It's a different direction but its still Max

I think Brucey is doing a great job.... but it isnt Max anymore just the syntax, the whole build chain is totally different.


Danilo(Posted 2015) [#75]
How long will it take to produce an minimaly useable result (Compiler System for the basic language)?
How long will it take to produce a good useable system (Compiler + IDE + and many Libs) - (File, FileSystem, GUI, Screen, ...)?

Something like a plan would be nice. Currently I think it could take up to 5 years to have something really useable, and
at 5 years x 12 month it may cost between $60 and $1.800 to support the project, and have an useable product.

Of course, paying $10 or $20 or $30 monthly for a period of 5 years (without any outcome) isn't (that) easy....


marksibly(Posted 2015) [#76]
> How long will it take to produce an minimaly useable result (Compiler System for the basic language)?

You should be able to build mojo2-ish apps before the end of the year. Beyond that is too far in the future for me to be able to even guess at right now, and some of it will come down to what people want me to do anyway. Wish I could be clearer, but I can't.

If you feel I'm working too slowly or whatever, then by all means reduce or cancel your Patreon pledge. You can always get involved again later when things are further along and you are more comfortable with the direction monkey2 is taking.


CopperCircle(Posted 2015) [#77]
Thanks for the update, looking forward to spending Christmas playing with mojo2-ish apps :)


Skn3(Posted 2015) [#78]
Wow havn't been around here much recently but sounds like a shitstorm a bit...

Can't see how any products Mark/BRL have ever released could be considered "rip-off". More and more dev software is going to subscription model these days (maybe unity is bucking this trend though). I think if you consider what the goals of monkey1 were, the language has turned out amazingly. If you look at the evolution from BlitzBasic (PC) to BlitzMax and then make a direct correlation as to what MX1 will be moving to MX2... I think it is safe to say that we are in for a treat!

Looking forward to having a play at Crimbo too!


Danilo(Posted 2015) [#79]
marksibly wrote:
You should be able to build mojo2-ish apps before the end of the year. Beyond that is too far in the future for me to be able to even guess at right now, and some of it will come down to what people want me to do anyway. Wish I could be clearer, but I can't.

Thank you for the answer, Mark!
marksibly wrote:
If you feel I'm working too slowly or whatever, then by all means reduce or cancel your Patreon pledge. You can always get involved again later when things are further along and you are more comfortable with the direction monkey2 is taking.

I don't think you are working too slowly, because I don't know the current status anyway.
A status update message every few weeks or so would be nice. Maybe once a month, with Patreon payments (or using your blog page)...
so people are up-to-date about the current status. Thanks again!