ENIGMA Development Environment

Yeah. I believe with() is Delphi, but I'm not certain. It'd make sense if it was. You can see it in JavaScript as well.

Posted about having to write an essay elsewhere. I'm nearly done.
Ism's getting Java to pass resources to DLLs and the like.

I'll be essaying for the next day and a half or so.

Didn't think it was worth a news post.

Ism got DLL's working in Java. She's now looking in to how resources can be passed via function calls. Shouldn't be hard to get ENIGMA DLL-ized from there.

@miky
Oh, you're right. I should just include the GCC with it like you first said; wouldn't want to risk the project looking "stupid" to someone.

Also, I'd really like to see an English->French translator hard coded over the two languages' twelve similarities.

@The 11th plague of Egypt
It's actually probable that the majority of users will try their best to avoid LGM, doing major development in Game Maker then bitching when they've used something ENIGMA doesn't support yet a month later when they're ready to compile.

"Also, breaking one of the most idiotic features of GML in order to save one of the smartest features of C++ seems a good trade to me."
Now this, I like.

Directly converting GML to C++ is impossible. They should not expect it.

IMHO we are just trying to make C++ and GML live togheter.

Call me a philosopher, but I'm not sure what you mean by "impossible" or "directly converting." ENIGMA's purpose is to convert GML to C++. I started the project because I noticed enough similarities in syntax that doing so would be relatively easy, in fact. Some things will obviously never work in plain C++, the first of those being with() {}.

@miky as well: Including a C++ compiler is certainly unnecessary for implementing execute_string() for backwards compatibility with GM, and is not really necessary for interpreting most C++ features, either. Yes, there are projects that can interpret C++, but I'm reasonably certain such projects are bloody massive. A smaller alternative is to do a bit more parsing and pass strings to Google V8 (A damn nice JavaScript JIT compiler). With V8, I can link in globals at runtime, and write a variable accessor class called Cthis, which will be appended before all locals (or all variables in general). So, the user's code will be for example, x = 0; y = 0;. It'll be passed to V8 as Cthis.x = 0; Cthis.y = 0;. V8 will call Cthis's accessor for "x," which is a C++ function I register. It'll behave just like GM's interpreter, only, sad as it may be, probably faster. The work for me would be so small as to be laughable.

a = 0;
var a;
a = 3;

Would work just like GM, because after they declare var, I just remove it and stop adding Cthis before the variable. This can be done entirely linearly, and without buffer resize as I can just space out "var" (as in, replace it with "   ").

The only things that may require a new buffer is adding semicolons to the code, which isn't always necessary in JavaScript, either; only when no newline is given. Hell, I might even be able to edit V8 to not require newline either, if I really wanted. Though, that's quite unlikely.

Did I mention it's JIT compiled?


As for scripts returning the value of the last-called script... Heh, that's kind of neat, I was unaware it did that; that's usually a behavior defined in interpreted language. I can't replicate that, as far as I know, simply by not providing a return value in lieu of the user's... I could if the last reference were left in EAX, which is unlikely.

I don't think I'll be replicating any useless GM bugs.

Like I said, C++ people make this particular mistake a lot. It happens, and it could likely piss people off.

My thoughts ^

Breaks this v
if (true)
{
  var a;
  a = 3.14;
}
show_message(string(a));

And by "breaks," I mean "fixes in a way that may piss off a very small percentage of GM users."