Josh @ Dreamland
|
|
Reply #30 Posted on: March 06, 2010, 09:32:16 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
This forum isn't on or related to Construct. If you want to talk about construct (or any other really great examples of how a parser can go right), we can make you another board next to Shupaer's.
Until then, I don't want to hear how everything I've done could have gone better if I had taken X method from Y project.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Rusky
|
|
Reply #31 Posted on: March 06, 2010, 09:39:07 pm |
|
|
Joined: Feb 2008
Posts: 954
|
The good design I would use: A real language with types, closures and a good FFI for extensions. A way to extend objects or make simpler structures for things like particles. A good VM to support dynamic language extensions. A good compiler that goes directly to bytecode rather than through C++.
Half or more of that is what you're doing, yes. but you're shoving it into GM's design with doubles to store indexes to everything, with objects and instances in the same space, no infrastructure for extension, etc. and you're having to bend your internal design to match that and C++. For example, the var class. A lot of that work would be unnecessary if you were doing the compilation yourself.
Basically, Enigma has different goals than I do. If you don't want to hear our opinion, stop complaining about your problems.
|
|
|
Logged
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #33 Posted on: March 06, 2010, 10:01:09 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
EDL is the union of GML and C++, not the intersection. If you consider either of those a real language, then I don't see how EDL isn't. EDL has GM's only type, and any type from the C++ STL, as well as any types users care to define. I have no idea how you are defining closures, other than as found in the functional paradigm, and as far as foreign functions go, we have LibFFI for GML's external_define, as well as the ability to just add to your project with other C++ libraries (whether designed specifically for ENIGMA or not). If that's not good enough, feel free to make a suggestion.
Way to extend objects? Easy. Way to make simpler structures? Good thing I just wrote a C++ parser; now you can make as many as you want. I'm having a new script resource added for that purpose. As for "A good compiler that goes directly to bytecode rather than through C++," what the fuck is that? Oh, that's right: A synthetic axiom with the soul purpose of ruling out ENIGMA, not even attached to a valid complaint, such as "not doing it yourself is slow." Perhaps that's because all such complaints could so easily be stricken down.
As for your next paragraph of bitching, it's been an intention of mine to tier ENIGMA to allow for removal of indexing. The first public hint at that was back when I announced that a new instance system I've developed will allow using pointer instead of ID to reference instances. The same could be done with sprites for anyone brave enough (and well-practiced enough) to enable it. I like the idea of C++ being an option; it's a beautiful language, especially when you can create a new project and have the annoying parts done for you. That's all C was ever missing. I would want the language to be a part of the project even if I could create so good an optimizer as that employed by the GCC...
As for your last statement, "If you don't want to hear our opinion, stop complaining about your problems."... this is my damn forum. I paid for it; legally I own it. This is the place where I present the problems of my project, for which this site was founded. Just because you hang around here doesn't mean you are entitled to a say in anything, or that your goals should in any way be reflected by the proceedings of this forum or the project of its topic. I am all for constructive criticism. Making the same suggestion repeatedly as I respectfully decline it isn't constructive, nor is telling me how much better I could have done had I listened to you, especially offering no proof other than child's-play proofs-of-concept and examples of full-fledged teams that have pulled similar stunts.
|
|
« Last Edit: March 06, 2010, 10:08:47 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #35 Posted on: March 07, 2010, 12:07:37 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Never heard it used that way, only in reference to Lisp (or maybe it was Haskell). That can easily be fixed with a small API. I like things compiled natively. As opposed to simply better? I'm not about to debate something as subjective as which language is perfect. C++ is perfect for me.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
serprex
|
|
Reply #36 Posted on: March 07, 2010, 07:40:56 am |
|
|
Smooth ER
Joined: Apr 2008
Posts: 106
|
I think GML is simple enough that it'd be better to compile it more like many ML/Haskell compilers do, native code with calls to a fat libc-esque library for the language I've read that some prefer to hand roll their parsers. Josh is one such such. Rusky, you're complaining that Enigma is hard coded to GML? I wasn't aware it was suppose to be anything else You're a lazy ass. You don't contribute anything to the project but weenieism. Complain with examples; I wrote up a toy implementation of GML's type system catered to GC and type tracing, something Josh hasn't quite explained to me how he plans to deal with. Nothing really came of it, because I was unsure how to integrate it into Enigma. I recall you wrote a bit of a grammar for GML, that could have been useful. Unfortunately, because you didn't implement a patch to integrate it with Enigma, it's shit for dicks
|
|
« Last Edit: March 07, 2010, 07:48:49 am by serprex »
|
Logged
|
|
|
|
Rusky
|
|
Reply #37 Posted on: March 07, 2010, 02:15:51 pm |
|
|
Joined: Feb 2008
Posts: 954
|
Ruby, Java, C++0x, JavaScript, Lua, PHP 5.3 and more all have closures. They are fairly popular with scripting languages.
It is more complicated than just a "small API" to manage resources with a DLL, and to allow the DLL to do non-trivial things with those resources (including things GM doesn't call resources like the screen).
VMs can compile bytecode to native code at start time or JIT, which allows for much more aggressive optimization in addition to more language features. That's a better reason that just liking native code.
I would have the same features (more or less) making it "better," but the architecture would be different, which I would say is better but you wouldn't believe me, so I'll settle for different.
Josh can "hand roll" a parser without making it one big mess.
I may be lazy with respect to Enigma, but you're in no position to judge what I do otherwise. Besides, Josh refused to use my grammar because he didn't write it. I would rather not work on a project with these kinds of problems.
|
|
|
Logged
|
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #40 Posted on: March 07, 2010, 04:35:56 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I don't see how a "'small API'" won't cut it. ENIGMA's resources are stored in an array; giving a DLL read and write access to that array wouldn't take any more than an additional pointer.
That VM idea sounds great when you assume everyone has it installed. I like native code because it runs quickly, doesn't need touched at load time, and doesn't require large VM's that no one has installed. In advance: I don't care about `this awesome language by Google' or `by the Ubuntu team' that Construct was thinking about using because it's so fast, cross platform, and great.
Working from architecture to architecture is nice. It's also not going to happen. Cross-compilation has been invented to come close to the ideals of such.
The parser is only a "big mess" in your opinion. Dedicate some of the time you would spend finding a "decent method" to studying mine before you start criticizing it.
...
It seems the difference between you and me is only that of a few years: In the beginning of the project, I had no direction. I'd see a shiny thing and think WOW THIS WOULD BE GREAT IN ENIGMA! Then I'd see another one and think WOW THIS WOULD BE GREAT IN ENIGMA! Eventually I came to realize that not all of the things that WOULD BE GREAT IN ENIGMA, WOW! can be added; that I have to choose between different systems. I decided that some systems could be added alongside others to be used one at a time when appropriate, such as OpenGL and DirectX, or Win32 and XLib.
I also realized that the foundational language for this project was NOT such a system. And so I chose one. I chose the language that will work on Windows, Mac, and Linux, without it being anyone's fault by my own if it misbehaved, and that would then work on the most non-computer systems (consoles, mainly). That language happened to be C, though I later revised to C++ wanting to provide more to users than GML. C/C++ were my best bet for getting ENIGMA running on the most systems and performing the fastest.
Also in advance: Please spare us your spiel about how C# (or perhaps something similar you may have found) is a beautiful language that half-ass works on Linux as long as you use Mono, and that works on Windows if you're patient, and that works on XBox if you have plenty of time and money, and that works on the Wii if you are X company (look, we have a Barby game written in C# to prove it!). I also don't want to know how many wonderful functional languages people have managed to write a C++-based interpreter for on different consoles. I hate it when people start naming off ten different languages that collaboratively, if magically used all at once, match the ability of C++.
You can, however, feel free to gravitate back to how I should be writing an assembler for each of these architectures myself.
Score_:
They want to pretend that by writing a VM for it, everyone will magically have said VM installed so code will be smaller and cross platform (as one module) and all-around happier for everyone, the end.
|
|
« Last Edit: March 07, 2010, 04:53:35 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
serprex
|
|
Reply #41 Posted on: March 07, 2010, 05:38:59 pm |
|
|
Smooth ER
Joined: Apr 2008
Posts: 106
|
Generating code for an AOT based VM like LLVM is more work than generating C. It's designed for supplanting a machine code generator with a more generic case. C is similar. Haskell's GHC allows for GCC as a back end; albeit deprecated for a machine code generator, and now someone has devoted their PhD to implementing an LLVM backend. Multiple Scheme implementations (Bigloo, Gambit, Chicken, etc) use C as a back end. PHC, the php compiler, converts to C++. All these languages support closures. I love first class functions, my design of Fractaler shows it, but we're just trying to work out a translation of GML here, and GML's closure support is something along the lines of passing strings around to be executed with execute_string. Also notice how all the languages I listed have closures. Scheme is a dialect of Lisp, which introduced closures to the game
I'll agree, I believe LLVM could make a suitable backend for a well designed implementation of GM. Enigma isn't such an implementation though. To use LLVM, you'd have to change the manner by which you go about it. We're attacking this is a completely different manner than code generation
Rusky, I'm not judging anything you do outside of this project. I don't even know what you do Don't pull Josh not accepting anything you do because he didn't do it, you never offered a working fork of Enigma that consists of your work. He's cooperating with the changes I've been making because I'm applying them to a copy of Enigma which can showcase the changes
|
|
« Last Edit: March 07, 2010, 05:41:27 pm by serprex »
|
Logged
|
|
|
|
Rusky
|
|
Reply #42 Posted on: March 07, 2010, 08:20:18 pm |
|
|
Joined: Feb 2008
Posts: 954
|
If you're planning on adding GC, you can't just hand the DLL a pointer. Working from architecture to architecture has already happened and you're making it happen again, using compatibility layers. A VM doesn't need to be a separate thing like the JVM or .NET/Mono. It also doesn't need to be large, especially if it's not a separate installation with all the libraries in the universe. Enigma's engine is linked to each game- a VM could be part of that engine. A VM gives you more portability and more aggressive optimization. You can write a VM in C++ and it will run on other platforms just as easily as if you have the user write in C++. VMs can actually be faster than AOT-compiled C/++, because they know more at optimization time. I know you can compile a language with closures to C. It's hard to get the closed-over variables to work by-reference, though. I know Enigma is meant to compile GML; in fact, that's my point. I wouldn't try to improve GML by adding C++, I would create a new scripting language or use an existing one, designed to have GC, dynamic typing, closures, etc. You say Enigma is "attacking this in a completely different manner" and again, that's my point. I would make a new system rather than improve GM's. Josh asked- What good design would you be torturing with GM's? The reason I didn't offer a fork is that I don't want to work on a system like Enigma. I'm interested in how it turns out, and I offered a system that would make things easier, but Josh had different priorities. He wanted a hand-coded, unstructured code beautifier written and obfuscated by himself rather than a readable, extensible parser. If he had shown any kind of interest in my system I might have tried to merge it in.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #43 Posted on: March 07, 2010, 08:43:12 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
This is C++. There is no GC. There will not be one.
You would evidently have me include a VM for all concerned architectures (And believe me, there are multiple) in with the executable...? Or rather, the platform independent byte code? That would be ginormous. It'd be a 20MB job just like Yoyo's Mac runner.
And it's irrelevant if you wouldn't better GML by mixing in some C++, because I would. Serp would just as soon leave it as GML. And again, since presently we are the only two people doing anything on the project, it doesn't matter what anyone else would do.
If you are interested in how this project turns out, then by all means feel free to watch. Stop bombarding me with facts about languages you think are better than the one months of work have gone into using. Or have someone else fork it. I'm not just dropping all this in favor of a highly idealized VM to magically solve all our problems.
I'd have shown a lot more interest in your system if I thought it had a chance of doing what mine does, or performing as fast. It never would have made it through C++.
Your ideals on the subject seem to be just that. If you could find another C++ parser project to expediently obtain all the class and function definitions for users to take advantage of, that'd be a great start. I don't trust it, maybe you do. Seems all the projects you pointed out parse their own dialect and their own headers rather than that and those of the GCC. So, why do I want GCC's? Because it compiles for every platform I intend to target. Every. One of them.
There isn't a language nor a C++ compiler that you will pick out that can do all the GCC can. To be able to parse the same things as GCC ensures that it is always an option to include headers for the current system. It was my best option from the start, it still is.
Maybe you've noticed that I'm working from the broad to the specific, not vice-versa. Starting with GL rather than DirectX, and other such strategies where possible. If one day it becomes a decent consideration to write my own VM for ENIGMA, then maybe I will. I can't see that happening at this point; the project is young and a 20 MB RUNNER would only scare people away.
|
|
« Last Edit: March 07, 2010, 09:06:03 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|