Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Josh @ Dreamland

Announcements / Quick Poll
« on: March 08, 2010, 08:58:12 am »
As the more conscious of you realize by now, ENIGMA allows for C++-style declarations to be used in your projects. As you all should know, GM is very loose about its semicolons.

I asked Ism to create a script-like resource that will allow users to define their own structures and functions for use in the rest of the project. However, it is also legal in C to define structs in your code, and I don't want to alienate that as a feature.

For those who are new to C, structs are a simple data structure that lays out how chunks of memory look. They allow you to keep track of multiple things, like a named array. Instead of having, for example, a 2-Dimensional array to store x-y pairs, you could create a structure like the one featured below.

Veterans know that R3 allowed for cpp {} to handle such things. The cpp statement created a block of un-parsed code to allow users access to C++ without the parser having to check it for error, creating a workaround as well as a decent expandability. That block is no longer necessary for its old purpose; now we can choose to have it serve a new one along with it.

Say that in a create event, you want to create a structure with an X and Y pair. I don't know why you'd want to do this since you may as well just keep two arrays, but for the sake of example pretend you do.

Being used to the GM way, you say this:

Code: [Select]
struct xy {
  var x;
  var y;
direction = 0
speed = 0

That's a problem.
The parser would naively make your code look like this:
Code: [Select]
struct xy {
  var x;
  var y;
direction = 0;
speed = 0;

The above code looks correct, but in actuality, it redeclares direction as an xy structure in that piece of code. This is because the proper form for structure declaration in C is this:
Code: [Select]
struct name { int members; } instance; I'm sure you can all imagine why that isn't good... For those who can't, it means that for the rest of that code, the word "direction" will NOT refer to the builtin variable direction. It will instead refer to an instance of your xy structure, which behaves like an instance in GML. You could say direction.x = 0; direction.y = 1;, and it would be valid. To fix this, preventing the instantiation of immediate varnames (in this case, direction), you would simply add a semicolon following the closing brace.

Code: [Select]
struct xy {
  var x;
  var y;
direction = 0;
speed = 0;
The above piece behaves as one would expect.

All this considered, we are left with three options.
  • We can leave it up to the user to remember that semicolon.
     I still forget that semicolon at times. It is one of the most common mistakes in C/C++.
     It won't error, because direction is declared elsewhere. You'll have to figure it out yourself.
  • We can disallow immediate instantiation.
     This means that code will be treated as if the {} had been followed by a semicolon immediately, and that you cannot declare a new structure and instantiate it with one semicolon.
  • We can use cpp %{ %} for such declarations, erroring if the struct isn't in one.
     This is like the first option, but it will remind users to watch what they're doing. It's also pretty inconvenient, in my opinion. Whenever you want a new structure, you will have to input code similar to that below. I did like this suggestion when Miky made it, but then I couldn't make up my mind.

Code as entered for option 3:
Code: [Select]
cpp %{
  struct a {
    int b;
  } c;
Creates a structure called a, with a member called b, and instantiates it in a variable called c. You can say c.b = 0, for example.

Please read over carefully and make your choice; feel free to ask questions or justify your answer. You can change your vote (assuming SMF works like the checkbox implies it will), so don't be afraid to just place one.

Note that the script-like resource mentioned is pure C++, and so expects perfect grammar. This does not apply to it.

I also ask that you don't just randomly pick one, though picking one because your retarded friend told you to do so is fine. I figure cheating on polls is a good thing; it reflects who cares most.

Announcements / Re: Prophase
« on: March 08, 2010, 07:22:31 am »
Why am I making this work for Windows, again? >_>

Oh right, GM userbase. *begrudgingly gets back to work*

Announcements / Re: Pride
« on: March 07, 2010, 09:52:38 pm »
No one asked why you didn't work, we stated that you didn't. You defended yourself. We didn't ask for such.

C++ isn't an afterthought to me. Granted, it wasn't truly part of the plan from the beginning, but as far as I am concerned, it was. I will be treating it like it was.

If the users allocate things, it's up to them to free them. C++ has destructors; what more does it need? The only place I introduced anything resembling a GC was for instance_destroy, and that was only to prevent a delete this; followed by invalidating an iterator. Nothing else in the project is particularly prone to leak...

"You need a separate executable for every architecture anyway." Good, may as well make it all native and strip unused goodies as per the original plan.

"Clang is more standards-compliant than GCC." Again, I'm not using Clang. I don't care how standards compliant it is; I don't see it compiling for all the things the GCC compiles for.

Announcements / Re: Pride
« on: March 07, 2010, 08:43:12 pm »
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.

Announcements / Re: Pride
« on: March 07, 2010, 04:35:56 pm »
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.


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.

Announcements / Re: Pride
« on: March 07, 2010, 12:07:37 am »
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.

Tips, Tutorials, Examples / Re: lol streams
« on: March 06, 2010, 10:18:28 pm »
Yeah, compiler presently concatenates "" + "" automatically. For "" + anything else, I want it to cast first "" to variant.

Announcements / Re: Pride
« on: March 06, 2010, 10:01:09 pm »
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.

Announcements / Re: Pride
« on: March 06, 2010, 09:32:16 pm »
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.

Announcements / Re: Pride
« on: March 06, 2010, 08:53:00 pm »
What good design would you be torturing with GM's?

Also, the only thing which would require a complete change in the logic of my parsers is a complete change in the language itself. New keywords can be added to the GML parser by changing one line, and to the C++ parser (more comprehensive) by adding in roughly three places (The switch of keywords, the list of token codes, and the handler for each under the semicolon/comma handler).

Announcements / Re: Pride
« on: March 06, 2010, 02:43:50 pm »
Feel free to read it over and discern what has been reinvented.

...Also, writing a parser for one language does not imply that you can write one for any language. Especially not C++.

Announcements / Re: Encryption
« on: March 06, 2010, 02:01:54 pm »
I don't see why you're distinguishing operator= from any other member function. Operator= (and the implied other assignment operators) would just be the only good reason to use a type for this, as it would prevent me having to parse in a new block of code myself.

Announcements / Re: Pride
« on: March 06, 2010, 01:39:35 pm »
All right, that's finally starting to bother me. If any of those things were the case, where the hell was anyone that was going to prove that? Hm?
I was the only one doing fuck-anything on this project. I expressed countless times that I hate the recursive decent method. I don't care if you'd rather study one of those methods than learn mine; mine's faster. And no, using recursive-descent would not have made the project finish faster, because I would have given up. Or needed an entire fucking team to help me.

I'm getting sick of your cynical opposition at every turn. If you think you can do this job better than me, feel free. It's even open source. Until that time, stop pretending that because you can read about a method that you can understand it and replicate it faster than I can.

I scarcely think you understand some of the things my parser can read. Let me tell you, I wrote the parser, and there were things it parsed that I didn't understand.

Announcements / Re: Prophase
« on: March 06, 2010, 09:22:24 am »
Only the next three newsposts.

Announcements / Prophase
« on: March 06, 2010, 12:47:05 am »
The C Parser is now hooked up such that it is self sufficient in collecting information.

On initialization, it asks the GCC to dump built-in #defines into a file that it can read. It parses those to gain the ability to correctly evaluate later preprocessors and the like, then it begins parsing SHELLmain.cpp, which will soon be moved (for the most part) to a separate header, since that particular source file shouldn't be responsible for all of that.

While getting it to work, I was met only with the problem of setting the working directory, which is currently temporarily resolved: I set it manually with a relative path that will have to be changed for the release compile.

However, once that was implemented, it made it through the entire project without incident. I asked it to print the contents of the enigma namespace to be sure it got it all, and was blown away.

At that, mission accomplished. I will make sure the GML parser and syntax checker are performing adequately tomorrow, which they shouldn't be, considering I am recoding a chunk of each to use the new input.

Expect material to be tested this coming week (Surprise). Don't expect anything grandiose during testing; I've not even hooked up the DLL functions yet. What you should see is vastly improved compile time and some small bugfixes that were made before the split. Serp's optimized code as well as the things that have been implemented since R3 are not part of the equation at this point.

In fact, the struggle of the next several days is going to be getting LGM to communicate better with ENIGMA, which has officially outgrown its separate-module form. I remember when syntax check rang in at 13x faster than GM's while code was being sent as a file. XD Those days are over, and now we'll be faster with dignity.

*commits code in whatever state it may be*

I haven't seen Ism today. I'll definitely need her for this part...
Ed suggests we use JNA to handle the interface as a DLL. We'll see how that works for us.

Ciao for now.