Monkey2 status ?
Community Forums/Monkey2 Talk/Monkey2 status ?
| ||
| @mark could you post a new (one month later) topic about the development ? I find them very interesting and then people know more about it. |
| ||
| Yeah, would love to read about it too! So +100 from me :-) |
| ||
| +10! (factorial!) |
| ||
| Just bumping for attention! |
| ||
| bump........ |
| ||
| New monkey2 dev blog now up! https://blitz-research.github.io I will attempt to do at least weekly updates here in future... |
| ||
| It's like a surprise Christmas morning! Loving what I'm seeing (reading docs so far). . "End-of-line handling" does that include statements like...? If x>0 then Print "big!" . "Function call parameters must be enclosed in parenthesis" Noooooooooooo ; ) That was one of my favourite MX1 features, but I get Struct, operator overloading, function values, and Lambda in return... I'll be okay. haha . mojo.geom has built-in Vec2/f/i and related. I've also got my own classes (soon to be structs!) using the same names, but I can get around that with the namespacing? |
| ||
| > (reading docs so far). There are docs?!? > "End-of-line handling" does that include statements like...? That should work. It's all very monkey1-ish but a bit stricter for now until I sort out error reporting and line numbering a bit better. > Noooooooooooo ; ) It has indeed been the biggest bummer when it comes to converting mx1 code to mx2, but I think it's well worth it in the long run. > I can get around that with the namespacing? Alias Vec2i:mynamespace.Vec2i Should work, or directly using mynamespace.Vec2i in code. But 'Using mojo' probably shouldn't be automatically 'Using mojo.geom' either - I still haven't quite decided how I'm gonna tackle this stuff. On the one hand, I hate having to start each source file with a huge list of 'usings' or 'imports' the way you do in C#/Java, but on the other hand, namespace pollution! 'D' offers a bunch of ways to deal with this I quite like the look of, so I'm gonna look closer at that eventually. |
| ||
| Nice. I like the stricter, more explicit syntax. |
| ||
| I love the look of the docs on git hub - makes this site look meh. :) This page in particular intones "publish me as an e-book". Is that a github or monkey style for the nice code sample font? https://blitz-research.github.io/monkey2/update/2015/09/14/monkey1-to-monkey2.html |
| ||
| Aha...the github 'docs'! Actually, that's just the default 'jekyll' theme, jeykyll being the default blogging system github pages optionally supports. But yeah, I think the ultra clean look is nice - think I'll pinch it for the default monkey2 docs theme! |
| ||
| If there is no default int (NOOOOOOOOOOOOOOOOOOO) Local i=10 could maybe infer the := ? := look like an emoticon to me ;/ |
| ||
| Will check if i get more debug info now for my c converter now ;) |
| ||
| @marksibly: This looks awesome, but can I get some clarification on how '#Import' and 'Using' work? Do I have to add a bunch of '#Imports' into my programs, or can I use it like 'Import' works now. That is, should existing code use '#Import', or 'Using'. Is 'Using' only going to be a global thing, or is it a matter of putting your game-code into a single namespace? Or am I misinterpreting, and #Import is supposed to be the answer to the old import-system ala 'Include', but closer to Monkey 1? Have you given it enough thought yet, or is it something you're still sorting out? Also, will the new override behavior (Assuming it's staying, which sounds pretty good to me) cause errors when you don't use the keyword? Because that'd help with porting old code over. Is 'Strict' also going to cause errors, because again, that'd help moving forward. Another question is, where does Mojo 2 sit right now? Mojo 1 (Graphics) compatibility isn't a big deal, we can already wrap Mojo 2 pretty easily. But, will it be completely open source? Will Monkey 1 go completely open source after Monkey 2 is stable? Sorry for the long chain of questions, but this is sort of coming out of nowhere. I didn't even realize you were posting in this thread before seeing the GitHub notifications. We definitely need a sticky thread or announcement, even if it has a disclaimer. This is great, and I love the way the language is going. |
| ||
| Great news! Thanks! 2 questions stand out pretty quickly. #1. Using the latest TDM build 5.1.0, All the samples fail to compile with some strange cpp errors when building in "release". Debug building works fine though, did I miss that in the docs that release isn't working? (here are the errors, win7 64bit) http://pastebin.com/3ReEFzL3 #2. I noticed that defining primitive types with %,#,$ isn't working. I very much hope you haven't abandoned these as I find them very useful. It's on the to-do list? |
| ||
| @GW_: Mark mentioned on his Github blog that %#$ are abandoned for good. |
| ||
| > Using the latest TDM build 5.1.0, All the samples fail to compile with some strange cpp errors when building in "release" Erm, that's weird, it's working OK here and a) I'm also using 5.1.0 and b) the build options for debug and release should be the same anyway! Have a look at bin/env_windows.txt to see what compiler/options are being used. Please let me know what the problem is if you find it though, I want to cover as many 'weird compiler errors' as possible. > I noticed that defining primitive types with %,#,$ isn't working. I very much hope you haven't abandoned these as I find them very useful. It's on the to-do list? I wasn't planning on it. I find them #$@?ing ugly, and haven't seen any code that uses them for a while now. In fact, a quick look through bananas suggests I'm the only one that did! I also find := reduces the need for much typing anyway. So unless there's a massive demand for them, they're history sorry! |
| ||
| @GW_: Mark mentioned on his Github blog that %#$ are abandoned for good. Dear God no!! They're so handy!! I can't understand the logic of that. They aren't mandatory, I don't see them adding a lot of complexity to the parser etc. Maybe I'm just overly attached to them... R.I.P. Super-Handy-Time-Saving-Awesome-Language-Feature-Optional-Primitive-Tokens. [edit] @Mark, You probably don't see them often because 'Blide' and 'Jungle' will automatically expand them to there long-form versions. If I sound slightly dramatic about their loss, it's because I've been using them exclusively since b3d launched. |
| ||
| For Main, is it now Void? I was trying to stick to MX1 habits and wasn't working till I changed Main. Old/broken? Which just printed out... New/works? Which successfully printed out... |
| ||
| > I noticed that defining primitive types with %,#,$ isn't working. I very much hope you haven't abandoned these as I find them very useful. It's on the to-do list? I wasn't planning on it. I find them #$@?ing ugly, and haven't seen any code that uses them for a while now. In fact, a quick look through bananas suggests I'm the only one that did! I also find := reduces the need for much typing anyway. I use them all the time and Jungle magically converts them to int/float etc for me... and I never use := as I prefer to know the type myself. But I can live with typing out int/float, I'm a Java coder by profession. |
| ||
| > Maybe I'm just overly attached to them... I was once, going by a ton of monkey1 code anyway! But after seeing how much neater other people's code looked using proper typenames, I made the switch and haven't looked back. > @Mark, You probably don't see them often because 'Blide' and 'Jungle' will automatically expand them to there long-form versions. Well, there's no reason IDE's can't continue doing this of course. Another complicating factor is that I've decided to go all the way with 'unsigned' types (with as-yet-to-be-finalized restrictions on use), so there are now quite a few primitive types, ie: Byte, Short, Int, Long, UByte, UShort, UInt, ULong, Float, Double, String ...with the possible addition of 'Char' and some sort of 'size_t' yet to come. Yeah, we could do %u or @u (did 'short' have a shortcut?) for unsigned, but then it all starts getting a bit messy, and looking even uglier IMO. IDEs could help here too I guess, eg: 'u%' could expand to UInt 'u@' to UByte etc. And ultimately, if everyone's been relying on Jungle to expand shortcuts all along anyway, this feature probably belongs in the IDE! |
| ||
| I never liked %,#,$ stuff, they _are_ definitely ugly. I never use := either for the same reasons as therevills. |
| ||
| > For Main, is it now Void? Yes, see bananas for some sample code. |
| ||
| := reminds me of auto in C++, which I've tried to start using more. Anything that makes the code shorter in a clean, elegant, understandable way I like. Played a bit more. I like the different ways to skin a cat for modules. Print std.math.Sqrt(9) Using std Print Sqrt(9) Alias Sqrt=std.math.Sqrt Print Sqrt(9) |
| ||
| > Using std > Print Sqrt(9) Actually, that one's a bit of an anomaly - it depends on the fact that 'Using std' currently also uses anything that std uses! I do want to retain some way to do this, so it's not a biggy, but the 'correct' way would be: Using std Print math.Sqrt( 9 ) 'coz math is in std. |
| ||
| @mark maybe you want to know that I get a lot of warnings using osx. And the the htmlview example is only showing a pink window. |
| ||
| I noticed that defining primitive types with %,#,$ isn't working I Never liked them so I will not miss them... |
| ||
| GUI module unnecessary. Out of scope. *brings out marshmallows* |
| ||
| Thanks for the update on progress, and thanks for your continuous dedication/commitment, Mark! |
| ||
| "Actually, that one's a bit of an anomaly - it depends on the fact that 'Using std' currently also uses anything that std uses! I do want to retain some way to do this, so it's not a biggy, but the 'correct' way would be:" My bad, I was writing from my phone after the fact, should have been: Print std.math.Sqrt(9) Using std Print math.Sqrt(9) Alias Sqrt=std.math.Sqrt Print Sqrt(9) |
| ||
@nullterm: Don't forget parenthesis. ;)Print( std.math.Sqrt(9) ) Using std Print( math.Sqrt(9) ) Alias Sqrt=std.math.Sqrt Print( Sqrt(9) ) Are namespace names all lowercase, and classes & functions/methods names uppercase? Or class names lowercase, too? |
| ||
| But after seeing how much neater other people's code looked using proper typenames, I made the switch and haven't looked back. I can't argue with opinions but I am a little dismayed things are going more verbose than C++ in monkey2: Local x:Float, y:Float, z:Float vs float x,y,z; |
| ||
| @Danillo, actually it looks like Print is a keyword, not a function. So you don't need parenthesis. |
| ||
| > can I get some clarification on how '#Import' and 'Using' work? Do I have to add a bunch of '#Imports' into my programs, or can I use it like 'Import' works now. That is, should existing code use '#Import', or 'Using'. #import "blah" means 'add this file to the project'. I think of it as a kind of low-level project management directive. Stuff imported this way could theoretically be handled by an IDE, and stored in .project files of some type. An IDE could even generate a makefile.monkey2 that includes all these #imports for you so you didn't even have to type them - or, mx2cc could be passed multiple monkey2 files to compile or something. That's the rough idea anyway, for now #import is the only way to add files to a project. Using means 'look for symbols in this namespace'. You can also use 'Namespace' at the top of a file to declare what namespace the file's symbols belong to. Symbols within a namespace can automatically 'see' any other symbols in the same (or any outer) namespace without having to use a 'Using'. Symbols in a different namespace can be accessed either via a Using, or can be reference by 'namespace path'. See the 'std.math.Sqrt' examples above... There is also a default namespace which symbols are dumped into if you don't use Namespace at the top of your file, which allows you to write stuff without having to worry about namespaces, very much like blitzmax (I think). Symbols in different files that don't declare a Namespace can then automatically see each other since they're in the same (ie: default) namespace. |
| ||
| > actually it looks like Print is a keyword, not a function. So you don't need parenthesis. This will change - Print's currently my debugger! |
| ||
| > maybe you want to know that I get a lot of warnings using osx. Looks like you're using a different, probably older, version of xcode tools. What do you get with "g++ --version"? I get... Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 7.0.0 (clang-700.0.72) Target: x86_64-apple-darwin15.0.0 Thread model: posix My 'command line tools' in xcode/preferences/locations' is also set to "Xcode 7.0.1 (7A1001)" |
| ||
| > Are namespace names all lowercase, Yes, they currently are although I'm not sure they should be? Generally, I use uppercase for public classes/functions/properties etc. |
| ||
| > *brings out marshmallows* I'll bring the pop-corn! |
| ||
| For #import, does that mean a png/wav that isn't #import'ed somewhere isn't part of the build and can't be loaded? Reason I ask is I use alot of data driven processes where data refers to other data. So I'd have a .json or .txt file that refers to .png or .wav files. Which worked great as MX1 just grabbed everything in the Project.data that had the applicable extension. |
| ||
| > For #import, does that mean a png/wav that isn't #import'ed somewhere isn't part of the build and can't be loaded? You can still load stuff from the file system - the current dir will be the root monkey2 dir. #import is still very basic - it recognizes certain filetypes (eg: .c, .m, .a etc) and does some 'magic' on them - anything else it just dumps into an assets folder that you can access with "asset::blah". Even "asset::blah" is just really a shortcut for "file::assets/blah" right now, but eventually it will resolve to ProgramData or whatever. Eventually, there will be more advanced #import support, eg: for importing an entire folder into assets, with filename filtering etc. In the meantime, you could try the zip protocol, eg: stick everything in a zip, #import that, then load files with, eg: Image.Load( "zip::asset::myarchive.zip//myfile.png" ). It may or may not work - I did have it working at one point! |
| ||
| What's the logic behind the Virtual keyword? To me it seems more natural to have this be the default unless eliminated with Final. Unless you're going for something that translates more naturally into C++ than into most modern languages... |
| ||
| "Generally, I use uppercase for public classes/functions/properties etc." Me too. I've found mixed case module names ends up clashing with a class name in the module. Like having a PathFinder class in a pathfinder module, but PathFinder module gets ambiguous if talking about the module or class. |
| ||
| boo on parens... > actually it looks like Print is a keyword, not a function. So you don't need parenthesis. This will change - Print's currently my debugger! and that reply illustrates why.... not to mention that my short fingers really hate typing them.... and IDEs don't seem be a good help either! := love that though... I disliked the duplication that comes without it. short types were especially nice for casting. local a:float, b:float, c:float which I agree is ugly but I found myself adding eol and duplicating the 'local' for crying out loud... I seem fine with that for some reason. other than all that, awesome! |
| ||
| I hate having to add parentheses in PureBasic for non-returning function calls (ie. those not returning a value), just feels like so much typing, even if it's not. I've always liked Ami/BB/BlitzMax's way of parens required when returning a value, optional when not. Never liked Monkey's none-needed-at-all, as in If blah = MouseHit button x = MouseX, just looks so free-form, unclear and messy! (Bad example there, but you get the gist... ) |
| ||
| Hi, Awesome to see progress on MX2:D I can't get the renderer demo to run here on Linux Mint 17.2 64bit. Output: Also I can't get Emscripten to compile on any demo. I get the following on helloworld. I've just started playing with this update so not sure whats up yet. |
| ||
| @Mark: I'm getting the same errors as Richard, plus using file paths for identifiers of class, methods, function etc, will fall flat on it's face unless you convert all the possible legal file path characters into underscores. All it takes is a path such as /home/jason/applications/monkey-x/monkey2/bananas/helloworld/hellowworld.monkey2 and the compiler chokes. Edit: Is the SDL2 lib meant to be built and statically linked into the final executable as it's failing to link? |
| ||
Looks like the assembler errors are related to this code being generatedfor(;frame1.i<$_NUM_0LIGHTS;frame1.i=frame1.i+1){
struct frame2_t : bbGCFrame{
$_MyLight* light{};
bbFloat radius{};
bbFloat an{};
frame2_t(){
}
void gcMark(){
bbGCMark(light);
}
}frame2;
frame2.light=this->layer0->lights->Get(frame1.i);
frame2.radius=120.0f;
> frame2.an=(((bbFloat(frame1.i)*std_math_Pi)*2.0f)/bbFloat($_NUM_0LIGHTS))+(bbFloat(this->Millisecs)/250.0f);
frame2.light->matrix->at(12)=(std::cos(frame2.an)*frame2.radius)+320.0f;
frame2.light->matrix->at(13)=(std::sin(frame2.an)*frame2.radius)+240.0f;
> for(;frame1.i<$_NUM_0LIGHTS;frame1.i=frame1.i+1){
struct frame2_t : bbGCFrame{
$_MyLight* t0{};
frame2_t(){
}
void gcMark(){
bbGCMark(t0);
}
}frame2;
this->layer0->lights->Push((frame2.t0=bbGCNew(new $_MyLight)));
}void _2home_2jason_2applications_2monkeyx_2monkey2_2bananas_2rendererdemo_2rendererdemo_t::initVars(){
static bool done;
if(done) return;
done=true;
modules_2mojo_2app.initVars();
modules_2mojo_2geom.initVars();
modules_2mojo_2view.initVars();
modules_2std_2math.initVars();
modules_2std_2stack.initVars();
> $_NUM_0LIGHTS=5;
}Edit: Ok. Did a few testes and there seems to be a problem with Constants and Global variables and Cast<> isn't being recognized. If any one wants to see mixed c++ and asm debug change the compiler options in builder.monkey from If Not Exec( cmd+" -c -o ~q"+obj+"~q ~q"+src+"~q" ) to If Not Exec( cmd+" -Wa,-adhln -g -c -o ~q"+obj+"~q ~q"+src+"~q > asm.s" ) |
| ||
| > Looks like the assembler errors are related to this code being generated Looks like it's because monkey is generating '$' in var names. A quick fix is to add 'Namespace blah' at the top of rendererdemo (it's using '$' for default namespace, which I need to mung) - but don't let it run too long, it just crashed HARD on my machine! > If any one wants to see mixed c++ and asm debug change the compiler options in builder.monkey You should be able to do tweaks like this by editing the bin/env_config files too. |
| ||
| >Looks like it's because monkey is generating '$' in var names. Here's a related bit of info. You actually get this error when forcing compilation with the -m32 option. It also mentions this in the gcc docs https://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html At first thought I was thinking that it may have been an alignment/pointer issue, until I dug through the gcc bugzilla. >You should be able to do tweaks like this by editing the bin/env_config files too. I suspect that without output redirection you wouldn't see the generated assembler file. Edit: > but don't let it run too long, it just crashed HARD on my machine! With me being a rebel, I did! |
| ||
| and support for multiple windows (which SDL supports so why not?) Could this be used for VR support? |
| ||
| @therevills: I believe someone wrote some code on the Oculus forum to do it with SDL2. So it could. |
| ||
| A quick fix is to add 'Namespace blah' at the top of rendererdemo It worked. :) Do we know why Emscipten is not compiling? |
| ||
| > Do we know why Emscipten is not compiling? Nope, but I haven't done a lot of emscripten testing. It doesn't appear to be failing though, you're only getting a warning. Is there an 'a.html' file in the monkey2 dir after you build? |
| ||
| What's the logic behind the Virtual keyword? To me it seems more natural to have this be the default unless eliminated with Final. Unless you're going for something that translates more naturally into C++ than into most modern languages... I'm also interested in this, since I don't see the trade off/advantage. Does this help with the 'overriding method pattern match' issue monkey has when a derived class has a method with a different signature than the base? I take the implicit overridable nature of monkey methods as a huge advantage for convenience; not sure if this is bad practice, but it seems some other newer languages also make methods virtual by default, so I can't imagine it being that terrible. It certainly makes writing classes more enjoyable than it was in VB.net. |
| ||
| @Nobuyuki Some newer languages do, some don't -- notably C#. This page has a section at the top where the lead designer of C# explains why they chose that path. http://www.artima.com/intv/nonvirtualP.html Monkey is a little different perhaps as the language might not be expected to be as robust or defensive against industrial usage. It also seems possible to avoid the performance issues by "finalising" the methods that aren't extended in the compilation process. Still, just in a design guidance sense -- "Thou shalt think more deeply about whether methods should be overridable" -- it's a reasonable choice. |
| ||
| Regarding the 'virtual' keyword, the monkey2->monkey1 docs are a little misleading - the default is in fact currently 'virtual'. But I'm not yet sure it should be. Do a google for 'should all methods be virtual?' for some opinions on this. I actually think most methods should in fact be 'final', pretty much in line with the first answer to this: http://stackoverflow.com/questions/6606657/why-not-have-all-the-functions-as-virtual-in-c And of course, final methods are also faster, as they can be inlined (if they're not overriding an existing virtual method) which is very cool, esp. for properties. But this is still up in the air... |
| ||
| Is there an 'a.html' file in the monkey2 dir after you build? No html file either in the monkey2 root directory or the build folder. The warning keeps generating over and over until I kill the build. Just FYI. ;) |
| ||
| I agree on this, Mark. Virtual should NOT be default. |
| ||
| As a longtime C++ programmer (who focuses alot of time on performance) I'm gonna go against the flow. IMHO, Monkey Class should stick with the virtual by default. Java and C# (and MX1!) all follow that idea, and they are targeted towards less-hardcore (non-C++) programmers. Simplicity and easy to understand should be the goal, with the option to favour performance for those who understand what the trade offs are. And (even as a C++ programmer) Final seems cleaner than Virtual/Override. Monkey Struct on the other hand should be non-virtual for speed and memory optimization (no vtable needed). |
| ||
| In general, I think the intent of a piece of code (particularly publicly released code or modules) should be as explicit and clear as possible. To that end, and despite some inevitable teething trouble that'll arise, I think both explicit Virtual (for methods and properties at least) and the removal of %#$ are good ideas. Edit: Oh, and enforced parentheses too - I shudder when I see code without them ... |
| ||
| Non-Virtual Methods would be highly recommended. Most important reasons are the possible compiler optimizations, and simply the final size of the executable. With everything Virtual, everthing gets included into the executable - even If not needed/required. With big frameworks this makes a huge difference. GUI lib, for example. To show a simple dialog window with a textbox and two buttons, you just don't need all the other functionality of the GUI lib (changing window title, widget properties and styles, etc.) It's the same for all libs. File system, Packer (zip, rar, etc.), ... with everything Virtual, always everything is (and must be) included. The executable size can be many times bigger than actually neccessary. It's not neccessary to bloat an executable, that would usually be 500k, to 5 MB - just because so much stuff is included/referenced and never used. |
| ||
| @Danilo: At least with Monkey 1's build system, that's not how it worked. Monkey 1 only compiles referenced code (Excluding reflection). Either way, not using a derived class doesn't affect initial code generation. It's only the inlined cases that really leave you with a bad taste in your mouth. That being said, I'm on the line about this. There are some definite benefits of "non-virtual by default", but virtual calls only have overhead when they've actually been overridden. In a situation where you don't intend for the user to override a method, or extend a class, you should either mark that as such ('Final'), or provide a disclaimer in your docs. The big thing I'm worried about is Monkey 2's build system. It's translation-based, but I imagine it doesn't really perform optimizations. Because elements would be built separately, the best a compiler could do to combat the potential virtual calls is to inline/optimize internal uses, but also generate versions for the internal ABI, so code in other objects can link to it. So you might think "final by default" is the best way to do this. Except, it isn't. Though there might be something to say about the design portion, the build system argument doesn't always hold up. Link-time optimization has been huge in MSVC and GCC for a long time now, and is used to help resolve this kind of issue. And since we'll be using O2 or O3 optimization with g++, there's good reason to expect the AST to be broken down well enough to see the static uses of things like interfaces, abstract classes, and even abstract methods. The biggest crutches of virtual methods are dynamic storage and callbacks. A stack of interface references can't just be optimized down. The only exception is when the interface is representing a single type, but that'd probably require stack allocation, and insane optimization (O3 and possibly some extra flags). Function calls on the other hand, would be easily optimizable. There's also the fact that if a virtual call needs to be done anywhere for a class, it's stuck with an entry in the V-table, even if it's inlined everywhere else. Just my two cents. But I do think with the inclusion of '#Import' and 'Using', we'll be seeing a pretty much equal benefit-to-disadvantage ratio. When in doubt, let GCC handle it, I suppose. |
| ||
| I would go for Final by default, at least for properties. That said, it would be nice to require an "Overrides" or something to methods overriding an inherited method, so you can detect if you have a typo in a method you want to override. A bit like the Java @Override, C# override, vb.net Overrides keywords. |
| ||
| I agree with keeping methods and properties virtual by default. (Structs make more sense to be finalized early, though.) Rewriting classes to support extensibility after It's already been written is a chore and borders on pointless ritual. The default should be whatever is most likely to be useful in practice. The tradeoff for runtime speed seems negligible compared to the necessity to refractor classes whenever overrides are wanted if you want to avoid keyword soup. Pre-optimizing code via language design seems to put the cart before the horse, and is more in line with c++ practice then a lot of current languages, IMHO. The same optimizations can be made with the Final keyword, can't they? Seems like an optional one-time pass over the code to add Final keywords during the optimization phase is way more preferable than constant refactoring or ritualistic addition of the virtual keyword during the main development phase... In general, I think the intent of a piece of code (particularly publicly released code or modules) should be as explicit and clear as possible. I'm presuming that you mark most of you methods Final already, then? ;) |
| ||
| > Rewriting classes to support extensibility after It's already been written is a chore and borders on pointless ritual. Yes, but I think this is exactly what 'virtual by default' encourages. IMO, a well written extensible, maintainable class will have a few virtual methods and the rest should be final (esp. properties). By making final the default, class authors have to think up front about what should be virtual, as opposed to having everything being automatically virtual and worrying about the consequences later. And note this is nothing to do with optimization - that's just a very nice side effect. > I'm presuming that you mark most of you methods Final already, then? ;) Well, no one bothers, because it's a chore when virtual is the default! as my link above puts it: While I don't actually make most of my methods final in Java, I probably should... unless a method is designed to be overridden, it probably shouldn't be virtual IMO. |
| ||
| I tend to take the view that if you're extending a class, you get to override anything you like. (For that reason, my preferred default access qualifier is 'protected'.) As for properties, I never use them. If I want to expose fields, I expose fields - if I want to write methods to protect the internal data representation, I write methods. Why expose a 'fake' type? Anyhoo, I'm not the one designing a language. Just giving my two cents. Any of the options being discussed are liveable-with for the most part anyway, whatever the final decision is! |
| ||
| Hmm, I suppose I haven't written enough large class hierarchies to run into the problems. I'm a bit ad-hoc when it comes to OOP design philosophy, so maybe my argument spawns from ignorance. Yes, but I think this is exactly what 'virtual by default' encourages. IMO, a well written extensible, maintainable class will have a few virtual methods and the rest should be final (esp. properties). By making final the default, class authors have to think up front about what should be virtual, as opposed to having everything being automatically virtual and worrying about the consequences later. I'll try to summarize my thoughts on that in one sentence: what you're stating is a hypothetical annoyance as opposed to a real, practical one for people who take virtual methods for granted. I will concede the point that writing methods without regards to whether potential subclasses will override them in the future could cause potentially greater headaches down the line. It still feels like a more hypothetical thing for monkey's most common use case scenarios than a serious issue necessitating the change. Either way though, I know for sure that I find it far easier to write extensible code in monkey than I do in VB, because it lets me iterate faster without getting in the way of my tinkering. For the longest time, I avoided overriding methods due to it being a chore to do so in VB. It's not exactly encouraged, but there are multiple incongruities in the syntax that can make writing classes in VB a chore, so I guess maybe that experience is not directly applicable. Edit: To add to that, that ad-hoc approach to writing classes is also one of the major reasons I lobbied for having the Protected qualifier in the language. Sometimes I "just don't know" if I'm going to want to extend a class in the future, and I like being able to hide fields from external classes without being forced to re-implement functionality in a subclass or refactor. I'm aware that some of the same people who have no use for Protected are some of the same people advocating for the virtual method change now. Hmm, it's starting to feel almost like a philosophy thing... |
| ||
| @ImmutableOctet(SKNG): If you give an Object/Instance of a Virtual class to an external function/method, like a DLL or static LIB, all virtual methods have to be correctly referenced in the vtable. IMO they can't be optimized away. It would lead to Null-Pointer crashes if the virtual methods are not correctly referenced. Same with a Struct that contains a function pointer (lambda, anonymous function, callback function pointer). If you give the Struct to an external (API) function, the Pointer must be set correctly and can't be optimized away, even if the pointer or function is not used internally. |
| ||
| This discussion seems to be primarily between "easy for the code/module creator" vs "easy for the code/module user". People who want to keep automatic virtual methods, optional parenthesis, and %#$ seem to be in the former camp - "don't make my code creation more difficult". Mark's stance seems to be the later - to make things clear and less "risky" for the code/module user. Personally I think Mark's approach is an admirable goal for an open-source language that wants to foster a vibrant module-based ecosystem. I know it'll cause a tiny bit more work for the module creators, but for the future of the language I think it'll be worth it. Edit: to put it another way - my understanding is that the point of the Monkey languages are the translators, not necessarily the creation of a unique language. And I think to increase Monkey 2 adoption it should be accessible to users of other languages who might be looking for a cross-platform solution, and not hang it's hat too heavily on the quirks of Mark's previous languages. |
| ||
| @Arjailer I don't really see that. If anything people who have spent a lot of time creating library code should be the ones that appreciate things like final as default, clear expression of intent and consistency of code. My impression is that you see similar patterns in past discussions about things like Strict mode as default and tighter/more expressive scoping rules. Library writers tend to want them, people who mostly bang out stuff that uses those libraries tend to not. |
| ||
| @Arjailer, I too don't see that... actually, I see the direct opposite as muddy_shoes just articulated. It really bothers me when an upstream programmer has tied my hands because he couldn't think of a downstream use case. At least with requiring final, I expect the programmer to actually put some thought into it. Final by default is fine for large enterprise projects with many programmers where you need to force an orthodoxy but it is (IMO) adding work and time to smaller groups especially single programmers. IMO one of the reasons that we haven't seen more community enhancements in bmx and mx1 is that the classes were difficult to extend. Especially the graphic engines modules. I have yet to understand Marks goals with this language. How is it different than other languages and does it bring anything new? What are the features that will want us to choose this language over all the others? Clearly the c import system is high on his list but that alone doesn't make a language. Ask this question... why did we all like Mark's previous languages? I bet many will answer with that it was quick to prototype and quick to show results. I think some of the choices that are being made are moving towards the java end of the scale... and that's not compatible with those thoughts. Personally... I think the best language would be a static/dynamic hybrid... https://www.ics.uci.edu/~lopes/teaching/inf212W12/readings/rdl04meijer.pdf |
| ||
| I agree with muddy_shoes and dmaz. I think Arjailer is equating "clear and less risky" and "easier to use" for the module user, when they can be opposites. For example, an annoyance for me is that nodes and their fields are private on Monkey.List. I could use access to those when I'm extending List. As for Monkey 2, my impression is that the concept is a combination of "a nicer Monkey" along with the desktop-target efficiency of BlitzMax. |
| ||
| @arjailer: I mostly agree, but you are lumping together default virtual methods ( which are a feature of many languages) with a few shortcuts like type sigils and functions which appear syntactically similar to statements -- The latter two of those are associated with anachronistic practices. And the other is associated with Java, Python, Ruby, etc. In that generation of languages, the standouts are c# and Delphi, both, funny enough, designed by the same guy. Newer languages seem to get around this by avoiding some of the typical oop paradigms altogether. Your comparison is apt where it applies to which approach should be taken based upon what the language is going to likely be used for, and by whom. If we do go with non-virtual by default along with explicit override keyword pairing, I would hope that we eventually see something like rust traits enter the language, so that people still have the freedom to tinker around with stuff without having to design it like it's going to be used in an enterprise production environment first. It feels like it's a reach to compare the current behavior to the other features which are going to be (or already have been) removed. @gerry: totally hear ya. Same thing for the data[] member on stacks before mark switched its visibility to public. That would have been a perfect place to change its visibility to protected, since most people who wanted access to that member wanted to directly manipulate the data for implementing an extension of their own stack class based off the default implementation. (Monkey-timsort was originally going to include classes like these, but it wasn't possible at the time) |
| ||
| @muddy_shoes and @dmaz - fair enough - I can see what you're saying. Perhaps I grabbed the wrong end of that particular stick :-) @Gerry - yep, I found that frustrating with List too, but that particular example is a class/framework design issue rather than a language issue. @Nobuyuki - I was just listing things that I thought had all been complained about recently in a "but that's more typing" context. Looking back Virtual wasn't discussed in that context - sorry about that. I do think that (theoretically at least) a well designed library based on explicit Virtual declarations should lead to a more robust coding experience. But I can also see that, if misused, it could also lead to poor designs and frustration. In practical terms though it might not actually make much difference - although I work on a large C# project in my day job (where explicit Virtual declarations are the norm), I've never actually found Monkey 1's approach to be a problem. In fact I'm generally finding that Monkey 1 offers a really nice balance of complexity vs practicality for the game I'm working on. The only thing I really wish it had is generic methods. |
| ||
| I've brought up before the fact that from a design standpoint, Monkey 1 doesn't have virtual methods, it has mutable/overridable methods. But it got me thinking of how the language got to where it is today. 'Protected' is brand new. It's fantastic, but it's also completely shifted the way I build modules, and for the better. For simple classes, you override public methods (And to a lesser extent, properties) pretty often; but for larger framework classes, I only ever have users override protected methods if they want to extend the framework. The main reason being that the protected methods act as the extension-API (Unless marked as 'Final', undocumented, or otherwise noted as "unsafe"). Whereas the public methods act as the user-level API (Also accessed occasionally from other access-levels), and the private methods are dedicated to internal routines. Usually, through core routines that shouldn't be extended, only used by protected elements, or by base-implementations that the framework requires to be called, or behavior will be undefined. The big thing I take away from this process is that, though public methods are overridden a lot by programmers, protected methods are usually the correct way to go for large frameworks. Which brings me to the conclusion that since "calling up" is very common practice, maybe the best way to allow extension is to sandbox the right amount of your framework, and though you should allow overriding, it should be opt-in for the developer. That being said, I think there's a good way to get around this practice's shortcomings; "extensible methods". Basically, extension without altering protected or publicly delegated behavior; opt-in function injection, in a sense (Just with proper barriers, and potentially, framework-devs would be the ones who opt-in). In other words, constructor behavior, but for methods. Of course, this shouldn't be a default trait to overriding, but I do think it's worth looking into. It'd add a lot of safety, and it would stop bugs where the super-method was intended to be called, but wasn't. I'm sure there's a better way to describe this in the language (Call-backs, etc), but it's an interesting idea when looking at inheritance stability. And having this as a part of the language would definitely streamline the process. My dreams aside, I think you guys have a point, we shouldn't bombard Mark out of the gate. That being said, he doesn't have to listen to everything we suggest, and that's usually what happens. So, I don't see how discussing potential fixes is a big deal. But yeah, we might want to make some more threads about this, rather than flood what has become the main thread. I should also bring up what I believe Mark brought up, D has already faced a number of these issues, and has gone in a great direction with them. But, it also doesn't have a lot of baggage, which is why a lot of "modern C++" guys see it as a solid alternative. |
| ||
| > what you're stating is a hypothetical annoyance as opposed to a real, practical one for people who take virtual methods for granted. Well, it's a hypothetical annoyance for you - for me, it's an actual annoyance as I end up having to mark 90% of my methods final! > This discussion seems to be primarily between "easy for the code/module creator" vs "easy for the code/module user". I think this is a good point. I do want monkey2 to feature a much more robust set of classes that can be more easily extended where necessary, so I am giving much more thought to the 'virtual interface' stuff this time around. Which is what has got me thinking about the idea of 'final by default' in the first place. But I also think that, unless you're writing a very small app, the general idea of 'design for inheritance' is good practice anyway, if you want to avoid the problem of 'fragile' base classes further down the line. I do get that people still want to use monkey2 to write small, 'just do it' stuff, but I also want people to be able to take on more complex stuff too, and for monkey2 to help with this if possible - and if it doesn't end up being too inconvenient for the average user, whoever that turns out to be. > IMO one of the reasons that we haven't seen more community enhancements in bmx and mx1 is that the classes were difficult to extend. Especially the graphic engines modules. I think this is precisely because I didn't give enough thought to how exactly these classes could/should be extended. The combination of all virtual methods and all public fields is incredibly flexible in a way(!) but it means there are really 'no rules' when it comes to extending graphics (or in fact any bmx classes). It also means it's very hard to sanely tweak or enhance such classes, as there may be subclasses out there overriding ANY method (or accessing any public field in the case of bmx), and expect those methods to 'behave' exactly the same way, everytime. Contrast this to my prototype of a 'View' class in mojo, which has just a handful of virtual methods: OnMeasure, OnLayout, OnRender, and some OnEvent methods. Everything's architectured around these methods *being* virtual, which gives me a huge amount of flexibility when it comes to adding stuff to View, or changing how it works internally etc. IMO, it's a better design, and the way I plan to design other stuff from now on. > For example, an annoyance for me is that nodes and their fields are private on Monkey.List. I could use access to those when I'm extending List. Unless you're arguing for removal of 'final' and 'private' altogether, I think this is really just a case of a design decision you don't agree with. Which is fine (I might even agree!), but I do think solutions to problems like 'I want to do XYZ with this class' should be dealt with on a case by case basis, as opposed to just making everything virtual (or protected or whatever) in the first place 'just in case'. > But I can also see that, if misused, it could also lead to poor designs and frustration. IMO making a method final if you're not sure whether it's going to be overridden or not (and you care about this stuff) is a win/win, because while you can always convert a final method to virtual later on without any risk of breaking existing subclasses, the opposite is not always true. But yeah, if you don't care, having to mark everything virtual is annoying. As is having to mark almost everything final if you do care. |
| ||
| Over on StackOverFlow there is a nice quote from the C# lead architect regarding virtual methods: In Java, instance methods are virtual by default—they can be overridden in subclasses unless they are explicitly declared final. In C#, by contrast, instance methods are non-virtual by default. To make a method virtual, the programmer must explicitly declare it virtual. Why is non-virtual the default in C#? There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue. A more important issue is versioning. There are two schools of thought about virtual methods. The academic school of thought says, "Everything should be virtual, because I might want to override it someday." The pragmatic school of thought, which comes from building real applications that run in the real world, says, "We've got to be real careful about what we make virtual." When we make something virtual in a platform, we're making an awful lot of promises about how it evolves in the future. For a non-virtual method, we promise that when you call this method, x and y will happen. When we publish a virtual method in an API, we not only promise that when you call this method, x and y will happen. We also promise that when you override this method, we will call it in this particular sequence with regard to these other ones and the state will be in this and that invariant. Every time you say virtual in an API, you are creating a call back hook. As an OS or API framework designer, you've got to be real careful about that. You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises. And people may not fully understand the promises they are making when they make something virtual. http://www.artima.com/intv/nonvirtualP.html http://stackoverflow.com/questions/973240/why-in-java-functions-are-written-virtual-by-default-and-c-sharp-nonvirtual |
| ||
| Another option would be to allow people to mark entire classes as defaulting to final. This is in fact what I've done already - if you mark a class as 'Static' (ignore the keyword for now) methods will be non-virtual by default, eg: Class Blah Static Property X()... 'final! Property Y()... 'final! Method Update() 'final! Method OnUpdate() Virtual 'virtual! End I actually quite like this approach, except for the 'static' keyword which doesn't make much sense. Perhaps declaring a class as 'Final' could do this? eg: a final class would have final methods by default BUT you could also add virtual methods to it (making it not-really-final). 'SemiFinal' too is tempting after the RWC, but no... Or perhaps, like Public and Private, you could also use Virtual, Final, Override, eg: Public Final Property X()... Property Y()... Protected Virtual Method OnUpdate()... Method OnRender()... Private Final Method UpdateLayout()... Method MeasureChildren()... Public, private protected could all default to virtual, eg: Public Virtual would be the same as Virtual. But I think I prefer the simpler 'Static' approach. |
| ||
| The Static Class thing is actually pretty cool, it reminds me a bit of c# "sealed", which basically only works on classes. I have some +1's to distribute around this thread now :) Maybe the keyword for this can be "Sealed"? |
| ||
| The other/opposite approach is to make methods final by default, unless the class is marked 'virtual' (with obvious results). |
| ||
| I vote for final by default because that's what in most of the cases just fits best. |
| ||
| I think the Static Class idea is a really nice compromise :-) Though I'd personally call it Final as Static means something else ... |
| ||
| yeah, me too, I really like the mark a class static/final idea. With this idea I could even be convinced to go the other way... final by default and marking the whole class virtual with individual parts final. that said and related, I'd still like to see extension methods... |
| ||
When trying to build for Emscripten target, I get the following error (this one is compiling the helloworld sample):modules/lib/miniz/miniz.c:3316:22: error: implicit declaration of function 'ftello' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
mz_int64 cur_ofs = MZ_FTELL64(pZip->m_pState->m_pFile);
^
modules/lib/miniz/miniz.c:2937:24: note: expanded from macro 'MZ_FTELL64'
#define MZ_FTELL64 ftello
^
modules/lib/miniz/miniz.c:3316:22: note: did you mean 'ftell'?
modules/lib/miniz/miniz.c:2937:24: note: expanded from macro 'MZ_FTELL64'
#define MZ_FTELL64 ftello
^
C:\Program Files\Emscripten\emscripten\1.34.1\system\include\libc\stdio.h:76:6: note: 'ftell' declared here
long ftell(FILE *);
^
modules/lib/miniz/miniz.c:3317:74: error: implicit declaration of function 'fseeko' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (((mz_int64)file_ofs < 0) || (((cur_ofs != (mz_int64)file_ofs)) && (MZ_FSEEK64(pZip->m_pState->m_pFile, (mz_int64)file_ofs, SEEK_SET))))
^
modules/lib/miniz/miniz.c:2938:24: note: expanded from macro 'MZ_FSEEK64'
#define MZ_FSEEK64 fseeko
^
modules/lib/miniz/miniz.c:3317:74: note: did you mean 'fseek'?
modules/lib/miniz/miniz.c:2938:24: note: expanded from macro 'MZ_FSEEK64'
#define MZ_FSEEK64 fseeko
^
C:\Program Files\Emscripten\emscripten\1.34.1\system\include\libc\stdio.h:75:5: note: 'fseek' declared here
int fseek(FILE *, long, int);
^
2 errors generated.
ERROR root: compiler frontend failed to generate LLVM bitcode, halting
Execute failed: emcc -std=c99 -Wno-undefined-bool-conversion -s DISABLE_EXCEPTION_CATCHING=0 -O2 -I"." -I"build/emscripten_debug" -I"modules/monkey" -I"modules/lib/sdl2/SDL/include" -I"modules/lib/litehtml/litehtml/include" -c -o "build/emscripten_debug/_modules/lib/miniz/miniz.o" "modules/lib/miniz/miniz.c"
?[?] : Error :Failed to compile source file 'modules/lib/miniz/miniz.c'Of course, I have Emscripten installed. I used the offline version you can download on the link that appears on the README. I have tried to build under Windows 10 64 bits. |
| ||
| When trying to build for Emscripten target Mark mentioned he has not done a lot of Emscripten testing yet, which means it's probably lagging behind a little behind desktop development. He is aware though of Emscripten issues. |
| ||
| > I'd still like to see extension methods... Me too! I keep encountering situations where they'd be really cool, such as: String.Load Canvas.DrawNinePatch Stream.ReadJson ...etc... |
| ||
| just knowing that you're thinking about them is super exciting! |
| ||
| Me too! I keep encountering situations where they'd be really cool, such as: Yes, that would be great! |
| ||
| Further progress: https://blitz-research.github.io/monkey2/update/2015/11/17/makemods-update.html |
| ||
| How is it going, Mark? ;) |
| ||
| Slowly but surely! I'm currently concentrating on doing a little xmas release, that will include a VERY early version of Ted2 (mainly a GUI test) and a semi-playable little stargate clone! I'm also in the process of converting mx2cc to monkey2, cleaning up a bunch of stuff in the process. This has become necessary as compile times from mx2cc in monkey1 are now around 30-40 seconds, which is painful! So far, the parser is 90% of the way there...next is semanter, then translator, finally builder. As I convert stuff, I am looking at cool ways to provide IDE integration, eg: having even just the parser means the IDE can now show simple help pages and provide a source code browser. I'll also post a blog update at the same time laying out where everything's going and what's coming in the future in more detail, stuff I have a much clearer idea of now. |
| ||
| Thanks for the news! Something to play with between christmas and new year sounds good. |
| ||
| Ted Lives!!! This makes me happy, long time happy Ted user. Any language changes since the last drop? Things seemed in a pretty good state, just curious. |
| ||
| All good to see. :D Looking forward to it and interested in blog post. |
| ||
| Ted Lives!!! This makes me happy, long time happy Ted user. So am I. |
| ||
| Ted 2 - How interesting... |
| ||
| As a lifetime Jungle purchaser I am all set for an IDE, but for the longevity and success of Monkey2 I have a lot of hope that Ted 2 will be robust. Beginners will demand it. What Mark is doing is sounds better all the time. (At the very least Ted 2 should have intelli-sense, especially in a language like Monkey. If it is as open as Monkey2 is supposed to be then if it is not in the initial build perhaps community can make it happen.) |
| ||
| At the very least Ted 2 should have intelli-sense I never use that kind of thing and really for me it gets in the way. Maybe the old school coder in me. |
| ||
| Shouldn't be a problem to make new IDE additions optional and configurable using IDE preferences settings (options). This way you get a highly configurable IDE after some time... |
| ||
| i once enjoyed the christmas release of blitzmax for os x. 16 monkey2 related wishes for christmas: #0 focus on less but well supported feature equivalent platforms, like desktop (win/os x[/lin]) first, adding iOS/... later on, no web. #1 support of indentation instead of end statements, like in python. #2 ^ instead of pow. #3 easy c# variables definition, public int a,b,c (generally less writing & more readability) #4 external editor support (like sublime 3) and(/or) something better than ted or ted with many fixes, like copy&paste/cmd+f search/working save&load of preferences/code completion/syntax highlighting/... #5 a reasonable debugger which you also want to use. #6 time saving docs with examples, flexible and open enough to involve the community too. #7 focused basic 3d support, and keeping VR in mind. #8 an up to date stable and more feature rich audio engine, for both 2d and 3d. #9 fast&easy read/write/copy access to all data. #a working joypad/input support on all platforms. #b fast compile times, due to iteration. #c multidimensional arrrays and multiple return values for functions. #d butter smooth scrolling and movements again without sudden/permanent stuttering/jerking. #e monkey2 being able to utalise multiple cores for its engines/components, if wanted. #f trying to stay as small, focused, fast, stable, elegant and easy to use as possible whilst having a clear design goal in mind which also suits users' needs. some points are relevant for a possible success of monkey2, others are due to my personal preferences. |
| ||
| @ taumel: You probably need to do some compromises. We already discussed some points (like Point (1)) many month ago, and it looks like it will not happen. It's too far away from original MonkeyX/BRL language(s) and a change just too big. But, hey, it's just a list of wishes for Santa! At least some of your wishes could become true over time... but most wishes probably can't be realized within 1 week of time. |
| ||
| It's a reasonable list. Obviously i don't expect it all to happen this christmas, if it ever will. It's about a proper direction, inspired by the fun BlitzMax once offered, learning from the past and due to the christmas lights. |
| ||
| From what I read and what we discussed, I expect MX2 to be way more fun than BlitzMax. ;) We just need to be patient (wait patiently), even if it's not that easy... |
| ||
| I can agree with some of the things on your list @taumel but not all, for a start I think html 5 is a must have, it's really not that old and it's already become the standard getting rid of it would be a massive tick in the do not use box for me. You thought on the Documentation is one many of us have had for many many years but I hope that Mark will finally see the light and move to something a little more open, I still contend that the way PHP does its docs is brilliant, each command with a comment sections where users post code examples, with the best examples being up votted as being most relevant, if we had something like that Mark would only need to flesh out the basics and then let us to the rest by filling in all the examples and curating posts via up or down votes. My own personal item for that wish list would be a modern fully functional and feature rich IDE to replace TED as MX2's default environment, I would love this IDE to not only handle the code but I would love it to also in some small way handle assets as well, things I think that could be packed into a good functional IDE would be Texture Packer, Basic Image editing, Sound Player & Recorder for basic sound manipulation, Basic Sound generator like the many found online for creating custom sounds, I would love to be able to preview art/sound/music in the IDE's file lists simply by clicking on them and hitting a play button to the side or an icon to see a preview window with the image inside, I would like to be able to create templates where I can make for example a custom framework template for something like Ignition or Diddy and tell the IDE, "Hay I want a new Diddy Project" and then have it create the initial project and folders from a template I had already setup earlier, I would not mind a clean assets function within the IDE that parses the code and compares all assets loaded with those in the data folder to highlight all files in the data folder that are not actually being used in the project. Would a Monkey2 Target for Monkey be out of the question ? so people could convert their old monkey code over to monkey2 quickly ? |
| ||
| Games in the browser are and always have been a compromise and this won't change within the next years. 3D Groove, Shockwave, Flash, Wild Tangent, Virtools, Unity, HTML-5/Web-GL, ... the need for performance/optimisation still exists (due to resolution/VR/frame rate/mobility), a lack of proper caching/saving (unless you utalise db driven client-server models), size constrains, browser hickups, ... There exist good examples for each technology but quantity related, apart from client work or customized games (which both come with their own constrains), it doesn't matter (for most games which seem to be relevant). Web based online games are different, like touch device games are different to desktop games. I do understand a "me-too"-factor due to a lack of a browser plug-in in earlier years but this shouldn't compromise upcoming technology/limited resources. In the end, if you have the choice, the browser is not the place you want to play games, instead download a game/client or stream its content. |
| ||
| If you are building to push the hardware then browser is a poor choice. But if you are geared towards more casual experience then browser is definitely an option. Then again, if you can offload graphics work into WebGL shaders, you can still pull off some pretty cool stuff: http://acko.net/ |
| ||
| If you need an example of something to set as a reason why html5 should be taken a little more seriously than it is above then http://hexgl.bkcore.com. I would also say this is not the best example of something done in html5 but it's deff a good example. Here is another fine example for html5 http://playcanv.as/p/JtL2iqIH |
| ||
| One wish for MX2 is non cryptic error messages, it's not helpful if there's an error but it's not evident what the error message is. |
| ||
| Side question: while MX2 is still in WIP, there are plans for the documentation/help/etc (wiki, online, offline, phone hot-line !)? I think many syntax (and other) features is already 'fixed' and not subjected to changes. So there's the possibility to have a product AND a documentation ready for the 'launch' of MX2. Alternative: waiting for the launch of MX2 and reading about the usual messages about new/old users on the lack of proper documentation, 'it's the usual BRL ways'... etc etc (just to give the idea!). |
| ||
| I have to disagree with most here.... I've generally thought blitz documentation has been good. That said, I also think as others have said... having the documentation live (ted2 using it) online with real-time vote-able posts from users( or "editor" users) in ted2 would be great. Though you know, the online docs for bmx and older did have comments that were mostly unused but I think that was because it was separated from the docs people actually used which were local. |
| ||
| About the documentation I posted some comments about this, at the very beginning here: http://www.monkey-x.com/Community/posts.php?topic=9891&page=2 documentation is the most important thing about this type of product. |
| ||
| Good docs and example with every command :) The community will not make the docs. With blitzmax there is not a lot of user made documentation and it is so old. If there wont be good docs/examples then there is luckely still the forums to ask things. But it takes more time. |
| ||
| Ok, I agree quite on everything, But I just asked what are the 'official' plan(s) about MX2 documentation. I like the GC-Martin idea to have an online documentation allowing comments and examples, but I would like to have a local version of them on my computer - and maybe vice-versa (this is of course an IDE job... but again, if there's no a plan about this, there will be not any IDE ready for this feature). Sometimes is the community to fill the gap in the documentation, with more explanations or with examples. I think this is a good way to learn a language in any case. And forum - like Pakz said - takes time (and for 'basic' info sometimes people could feel a little sheepish like me with Maps in MonkeyX... no documentation for a basic thing (for others!), sometimes it could be difficult to retrieve the 'right' information etc And a thread often takes different ways, you get mixed results, opinions, other solutions, other problems not related with the initial post and so on. For a documentation, a forum shouldn't be the primary solution. You can have a forum/discussion for each command (if needed) - like for the App section in this website. |
| ||
| Helpful errors messages can be a nice time saver. Due to SDL2 there might be couple of features (back) like collision detection(per pixel), timers, ... mojo and mojo2 were rather disappointing. Did anyone enjoy the way Scale worked, the shortcomings of DrawText, the weird design of mojo2, ...? |
| ||
| > Did anyone enjoy the way Scale worked, the shortcomings of DrawText, the weird design of mojo2, ...? Could you elaborate a bit? What's wrong with the way scale works? What would like DrawText to do? How do I 'un-weird' mojo2? etc... |
| ||
| Good question, sadly i'm in a lack of time for a more in depth explanation right now but generalized: mojo's rendering functionality, coming from Max/Unity/... felt weird and limited due to its least common denominator constrains (especially in the start) and the lack of a proper documentation. mojo2 sounded exiting first but when you were dealing with 2D/3D engines on a regular basis and quite often, apart from the performance related different angle, it's just the same. It somehow felt as a limited and isolated solution. I can't imagine many users making heavy usage of it. I would need more time to answer this more properly though. I haven't used Max/monkey for some time (except for educational purposes) but the way i remember SetScale from Max, it was easier to grasp, setting the scale to 4,4, draw something increased, set scale back to 1,1, everything was fine. With monkey you Scale and from there on it also had an influence on the calculations of the positions of other stuff you were drawing and you couldn't reset it back to normal just by (1,1), instead you need to shrink it back by the same factor (maybe therefore it's Scale instead of SetScale like SetBlend/SetColor/...). DrawText could be way better, so that you want to use it apart from debugging. A.o. a lack of blendmodes (alpha), the calculations of the size of the drawn string, alignment, signed distance fields, ... saying so it would be nice having easy options to set colours in hex/float(0-1)/hsv apart from 0-255 as well (yeah, i know that i can make my own types and classes). In Max DrawText wasn't sexy but also good enough, in monkey it was like: Okay i'll need to replace this once i get serious about it. |
| ||
| I remember trying to use the Scale command. It turns out the scale parameters in DrawImage and DrawImageRect are significantly simpler to use and the Scale command was perhaps a poor choice of name for a command useful for viewport level effects like virtual resolution and not for scaling individual blits. |
| ||
| Yup, you need to be aware of overloading (can come as surprises) and sometimes write a little bit more. |
| ||
| Can I ask, because I haven't seen it mentioned... is there going to be any way to specify where obects sit in RAM relative to each other, so that you can organise data that is accessed linearly into contiguous blocks? Also, what's the functionality of the htmlview planned to entail? ie are there commands planned to process actions in the view (button presses etc) and manipulate the DOM from code at all? Depending on what it can do, I can see it being very handy for a particular project I have in mind. |
| ||
| Sledge, why not allocate a big pool of the objects you need at the start? Of course if there are deep references you would probably have to allocate several pools at the start and hope for the best. But keeping everything fairly shallow is the way to go for your sort of high-efficiency mode anyway. That said, you could probably hack the C++ target to do everything you want - you could allocate a giant block and divvy it up any way you liked. For other targets it would probably be a lot more difficult. |
| ||
| I think, for games, you need a very good reason not to opt for object pooling :) and, that being the case, you naturally want to rattle over them as quickly as possible... which means being cache friendly. While not all targets offer the necessary finesse, as you say, it would be nice if M2's more abstract features were balanced out with some low level control where supported. (More than that, actually -- a high level language that let you map out memory allocation for cache efficiency would be bleeding-edge... does anybody else offer this ATM?) Re hacking the C++ target: A thousand billion times no! Customising somebody else's product makes every official update a crapshoot. In an ideal world, as a product, M2 would be first-party complete. |
| ||
| Okay, but how are you going to make Monkey write Java code that will specify where everything is stored in RAM on an Android target? And Monkey by its nature resembles Java quite a lot - converting to C++ is the most 'distant' translation it does, and only possible really because of the incredible flexibility and expressiveness of C++ which can have efficient abstractions that come half-way to emulate the Java-like Monkey model. Imagine if Monkey had a pure C target - Mark would have to write the equivalent of a JVM to make it work! I could imagine a multi-platform language designed to minimise memory allocation / fragmentation. But I do not think it would resemble Monkey-X... Maybe it could be called Monkey-C! Syntactically, it might resemble a '90s version of Basic, with structs and pointers or 'sorta-pointers' but no real objects. Maybe someone could make a module that manages a DataBuffer in interesting ways? |
| ||
| Okay, but how are you going to make Monkey write Java code that will specify where everything is stored in RAM on an Android target? You're not -- whatever facility there was in the language for specifying a preferred memory layout, it'd have to degrade gracefully. That's probably anathema to the lowest-common-denominator sensibilities of Monkey, but cache efficiency is a pretty big limb to cut off just because Java is a bit naff in this respect. I dunno, this wasn't even on my radar when Monkey was released and yet now, a scant few years down the track, it feels like a significant omission for any new release. I have no idea whether that's just me or if the zeitgeist has actually changed. I could imagine a multi-platform language designed to minimise memory allocation / fragmentation. But I do not think it would resemble Monkey-X... Aye, wheras I'm coming at this from the other direction... I think the next evolutionary step for cross compilers would be to allow Monkey-like syntax alongside efficient memory mapping on targets that support it and maybe even implementations of features that weren't one-to-one mappings of (oft costly) abstractions. |
| ||
| Here is my brief list, inspired by T's 16, I present the 3 ifs: If managed memory model was optional If "packaged" static and dynamic libraries were first class citizens along side executables If unpacking arrays for particle systems could be done with macros |
   |