Christmas Plans

[Josh @ Dreamland]

Very well. At least it's somewhat original. Just likely to get recycled a lot.

In other news, I went ahead and pushed my current working copy of the parser. A lot of integration needs done, but the parser is basically complete. I spent the last day or so shelling out all the old compiler warnings and doing some major reorganization.

This may be done by tomorrow night.

[Josh @ Dreamland]

Didn't happen. Ended up cleaning up some mess in JDI instead, correcting some bugs I was unaware of. Also did some much-needed testing; any test codes welcome so I have something to check before we're ready to unleash this on the masses. Hopefully TGMG will be around to automate that for us again.

In the meantime, the parser reads and gives a dump of test_gml.h in the JDI branch if you build the CBP in either of the standalone modes. It should build without warnings, except in the placeholder file that declares empty versions of the old parse functions to prevent link errors, because the new parser is still not integrated.

In fact, I'm still working out how many passes I should handle up front and how many I should leave to the language plugin. I want to minimize both numbers, but especially the latter, so as to facilitate easy extension of the compiler.

[polygone]

Josh run through the examples posted on the EDC.

[Josh @ Dreamland]

I will when it is building games again. For now, all it can do is single code pieces.

Today will be spent moving code around and writing a pretty printer. If all goes well, I'll finish both things and be done. Otherwise... More delay.

[Josh @ Dreamland]

Just so everyone knows, I am adding something to ENIGMA's specification after the parser is plugged in:

Code: (EDL) [Select]

object0.variable = 10;
int a = object0.id;
a.variable = 20;
object0[a].variable = 30;

Humans can tell what that's doing, but a parser cannot necessarily make that call. Maybe if I spent a great lot of time on it, it could, but in general you should expect this output from the C++ printer:

Code: (CPP) [Select]

((ENIGMA_OBJ_object0*)fetch_instance_by_objectid(object0))->variable = 10;
int a = enigma::fetch_instance_by_objectid(object0)->id;
enigma::varaccess_variable(a) = 20;
((ENIGMA_OBJ_object0*)fetch_instance_by_id(a))->variable = 30;

The idea is that the switch statement used in varaccess_variable is removed, and does not even need to be generated if `variable' is never accessed in that way. It'll still be generated as needed for compatibility, of course.

Note as well that I may optimize it further and generate an inline function for each object as needed, or just access them inline (more likely the former for reasons of error checking and general prettiness). Still, you get the idea.

[TheExDeus]

Wait, is object0 an object or an instance? If its an object and object0.id returns the first instance's ID, then how does object0[a].variable = 30; work? Like why in the parsed code "a" is not used anywhere?

[Josh @ Dreamland]

Because copypasta fail. Thanks. Fix'd.

The variable object0 is an object name, so it's an object_index.

[polygone]

I don't get the point.

[Josh @ Dreamland]

You wouldn't.

[Josh @ Dreamland]

Quick update:

Sorry that this is taking so long. While the parser is basically plugged in, I did not even consider how much work is involved in the other major operation I am taking care of: abstracting the language being compiled to.

The compiler now knows literally nothing about the host language; I have to move tons of ancient code from the global scope to various subclasses to facilitate having multiple implementations for multiple languages. It is genuinely a pain.

I have no accurate ETA, but I'm going to be spending 90% of my waking time on it. It must be done before Sunday night.

[forthevin]

A couple of thoughts and comments:

First off, spending 90% of one's waking time on something sounds less than healthy. Wouldn't it make more sense to postpone the new parser and compiler if it takes unexpectedly more time? ENIGMA seems to work pretty well at the moment, so I have trouble seeing the hurry.

Second off, I am happy to announce that the particle systems system is coming along well. Several examples work now, including the fireworks example from the manual (http://gamemaker.info/en/manual/412_08_example), as well as a nice fire effect example I found (http://blog.martincrownover.com/gamemaker-examples-tutorials/particle-example-fire/). There is still a lot missing, including effects, changers, destroyers, deflectors and attractors, but the system is quite usable at the moment.

Third off, ENIGMA has been very functional for quite a while, and I would therefore like to propose that a forum is created, named Works in Progress, where games in development can be shown and talked about.

[Josh @ Dreamland]

The new parser's is important to me because it means we can finally have extensions and additional host languages (eg, JavaScript). I've made the compiler so modular locally that TGMG should have *zero* difficulty finally making the Android part work out of the box.

Moreover, the compiler was in need of some redesign—a lot of it was thrown together hastily, and in a scatterbrained manner. I can't expect other people to maintain it if I can't even cleanly describe its pieces. After this, it should be much easier to tell what is going on in the compiler code.

[TheExDeus]

Also, I do have many problems with the current parser. Some are bugs, others are just a few suggestions that would be very great improvement over GM.

[The 11th plague of Egypt]

I can't expect other people to maintain it if I can't even cleanly describe its pieces. After this, it should be much easier to tell what is going on in the compiler code.

Well, good luck then. I'm getting curious about how this compiler works, I'd like to see some documentation.

[Josh @ Dreamland]

See the commit message from my last commit to get an idea of where I am.

Restructured and reorganized fuck-everything. Changed around fuck-everything.
My brain hurts from thinking about this shit for so long, and some of it still needs modification.
I have encapsulated most of everything correctly.

Remaining considerations:
- Events.res locals are still loaded by lang_CPP; they should be loaded universally.
- Where are events even parsed? I totally lost track. Being honest.
- We need a system for denoting where something was declared, for error reporting purposes.
- JDI handles some of its AST features funny
  - It checks the left-hand of a function call and bails if it's not a function or cast
  - It crams all the literal types into one AST node type
  - It doesn't handle error reporting very well, and, to top it all off,
  - It isn't fucking modular or extensible at all; nothing is abstract or virtual
- I have no idea if a second pass before pretty-print is actually required
- None of this outside the basic parser has been tested, and it's not blowing me away, either
- No amount of therapy will make this commit okay

I have done some more thinking, and determined that if we want to properly support overloading EDL functions regardless of host language (C and JavaScript being prime examples of languages which do not support overloading), we need a second pass after I'm aware of the types of everything in order to pick the correct overload.

Still haven't decided what to do with generics, for that matter, but that's another case.