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 / Re: Christmas Plans
« on: January 09, 2013, 12:49:33 AM »
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.

Proposals / Re: Weird stuff that works in GM but fails in ENIGMA
« on: January 08, 2013, 06:26:24 PM »
You would use .so files in Linux, right?
Correct. FFI works with whatever's native; it's pretty extensive.

Honestly, I wouldn't bother.
If I were to seriously implement an execute_string, it would be language sensitive, with the default being loose GML which I would format as JavaScript. It would serve 99.9% of all "legitimate" execute_string purposes, not to imply that there's a very legitimate purpose for it.

Funny, that's exactly what I was using them for in that old project. Once again, I wouldn't bother.
That's all anyone uses them for, ever. For var and variant, it's as simple as assigning a bogus default type. The type will be fixed upon assignment. The only issue is packing them all into a map by reference. So variable_local_exists will only ever check if implicit vars exist, never declared types. Really not that hard, which is why I thought polygone could do it.

Proposals / Re: Weird stuff that works in GM but fails in ENIGMA
« on: January 08, 2013, 02:50:22 AM »
Okay, sorry this reply took so long; it took insanely longer than I thought to the compiler building correctly again, but now it's mostly up with the new system and I can at least use it to prepare a response.

1. Bogus for statment.
Your for (i = 0; i < stuff; i += 1;) {} is actually the less bogus of the two for() issues. The weirder one is for ({i = 0;} i < stuff; { i += 1; } ) {}. The raw output for the two of these in the new parser is as follows:

Code: [Select]
Warning(Code,38,6): Blocks not actually allowed in `for' parameters
Warning(Code,38,26): Blocks not actually allowed in `for' parameters
Warning(Code,38,33): Semicolon should follow statement at this point

  for ((i) = (0); (i) < (stuff); (i) += (1);)
  for (  (i) = (0); (i) < (stuff);   (i) += (1);)

It doesn't warn about the trailing semicolon, and in fact, includes it in the output because the dump function always puts a semicolon after statements. The C++ pretty-printer will not do that.

In fact, more work will need done in the pretty printer to support the latter for() loop, as it is basically unsalvageable. Code output will look like this instead:

Code: (C++) [Select]
  {i = 0;}
  while (i < stuff) {
    i += 1;

The pretty-printer already needs to be able to support custom break and continue labels in order to support continue 2.

2. Checking for inequality with <>.
When I wrote the old pretty-printer, I'd forgotten about <>. It pretty much indiscriminately puts spaces everywhere. Output for if a <>  b c = d is as follows:

Code: [Select]
  if ((a) <> (b))
    (c) = (d);

3. Giving a variable the name of a C++ data type or the name of a function.
Yes, its silence on the matter is an issue. The new parser accepts the code as well; this is its text-dump:

Code: [Select]
  ((alarm)[0]) = ((100) - ((random)  (int)));

The AST tells another story:

I haven't decided if I want it to bitch out in a frenzy or let the pretty-printer salvage it (which, as you can see, is possible). In compatibility mode, the lexer will not honor "int" as a type, and the problem becomes moot, so really, it's in the air. I have a little more work to do to help scope resolution in the AST builder anyway, so we shall see.

4. Resources that would have the same name, if not for an asterisk one of them has.
Asterisks are invalid in resource names in GM and ENIGMA alike. GM doesn't care because it is in charge of the entire AST, anyway. ENIGMA is in charge of the AST only until it is converted to C++. While it was originally supposed to be LGM's job to verify resource name integrity, during my rewrite of practically everything in the compiler, I decided to handle this myself. A correct structure name is now generated for the objects up front, and objects themselves are referred to exclusively by ID during print.

5. Other stuff you probably know about already.
dll functions: These are implemented in Windows using libFFI. The same code can be ported to Linux with very little modification (only what is required to use the system FFI library instead of the one included in ENIGMA for Windows).
ini functions: I think someone started working on these, but probably got bored. No one uses INI anymore, so they've been given pretty low priority.
execute_string: This is implemented in EGMJS, and is liable to stay that way for quite some time. Otherwise, a substantial portion of the compiler must be included with the engine; it's just messy. ENIGMA is compiled, not interpreted.
variable_local_exists: In C++ (among other compiled languages), a variable can't conditionally exist. A key in a map can conditionally exist. I might implement this for var and variant, but the truth is, there is never a good reason to use this function. Its only valid use case in GM is to work around the stupid order in which Mark handled instance creation codes in rooms (room instance creation code was fired before instance creation code). In ENIGMA, as well as in later versions of GM, this has been corrected.
user_event: I have a bigger, better plan for these that doesn't involve Mark's shoddy, pathetically finite and otherwise very ugly and limited implementation of "User events". Think local scripts.
event_inherited: I wanted polygone to implement this as practice. Never happened. So I guess I'll handle it while I finish recoding the rest of the compiler.
sprite_create_from_screen: I thought someone had coded this by copying my implementation of screen_save. I guess that isn't the case, but for anyone whose interested, this can be written by copying my implementation of screen_save.
file_exists: I can't believe this isn't implemented. On Windows, this is CreateFile(). On Linux, this is stat().

I was already aware of most of this stuff, but I don't mind a refresher.

ALLCAPS BOARD / Re: cheeseshit
« on: January 06, 2013, 05:24:54 PM »
Sometimes I wish more people would just

General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:42:10 PM »
We communicate over IRC; network freenode, channel #enigma. There's a web interface on the forum index.

General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:36:28 PM »
Correct. I do not think we have a Wiki page on the matter because interest in writing an IDE is low, but we could easily start one.

General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:30:18 PM »
I don't do roadmaps; they change too easily.

General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:28:03 PM »
We already compile our scripts natively. Their use of LLVM is simply not a threat to us.

As for shaders, those are still in the planning phase. We need to come up with a unified syntax that will work over DX, GLES, and GL. I am already laying out a method of importing scripting languages into ENIGMA, though, so using multiple shader languages is a really simple solution.

General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:18:51 PM »
LateralGM's development is at a low, yes, but it's still maintained. As for it looking like shit, I'll grant that.

Anyway, we'd be happy to support your IDE in the same way we support LGM; we just ship it with the compiler. All you have to do is implement the same methods you can see done in Enigma.jar, and you can load ENIGMA and call it in the same way LGM does. The two projects are very separate.

General ENIGMA / Re: ENIGMA losing ground to studio?
« on: January 06, 2013, 02:06:53 PM »

I have been working on a new parser for a much more capable dialect of GML than the one employed by Yoyo. I am aware of their potential hike in speed from trying to compile their games, but I'm afraid that it will not do them any good when you compare the price tags. Even if they do match our speed, 100%, they will still not be competition for us ceteris paribus due to their incredible pricing scheme. That said, I don't see that we've lost any battle.

With the new parser I want to make ENIGMA at least as easy to use for mobile development as GM:S. At that point, it will come down to price and language features—ENIGMA will curb-stomp GM in both departments.

In addition to static typing, the new flavor of EDL I have written (and am still writing) will offer a lot of features that Dailly turned his nose up at, and a few more that he had expressed a desire to implement but did not believe he would find time for. Among these features are static typing (which we've always supported), much better support for arrays, support for closures, support for C++ operators, support for class/structure declarations, etc.

We also have a special surprise planned that we had introduced in R3, but that has since fallen into the history books. We'll be reintroducing it soon; ideally before Yoyo ever comes up with it. It's guaranteed to make development easier, especially for games like yours.

So yes, while Yoyo is catching up to us in performance, we'll still be in a league of our own in pricing and capability.

Proposals / Re: Returning multiple variables
« on: January 06, 2013, 01:07:31 PM »
Yeah, return type and parameter types will default to variant.

Proposals / Re: Returning multiple variables
« on: January 05, 2013, 09:24:49 PM »
I'm hijacking this thread. This thread is now about determining a syntax for functions declarations.

My plan to allow doing what you are describing is to use the Definitions resource that's been on Ism's plate for six centuries to allow declaring EDL functions.

Do we stick to C++ syntax, or somehow incorporate a function keyword?

ENIGMA handles its declarations manually, so we can do basically anything.

The benefit to using the function keyword is that it makes closures syntactically unambiguous. Consider function() { return 1.337; }. I could easily enough coerce that for a type, but that isn't the point. The alternative is double() { return 1.337; }, but double() already means "the default value of a double," which is 0d.

The hybrid alternative is a little uglier, but completely unambiguous: function double() { return 1.337; }, or function double my_script() { return some_double; }.

If these functions can't have return types, then there's no point to having them over scripts. So the question is, which do we want more: closures, or not having to use the function keyword?

An array type for [a,b,c] is in progress, by the way, HaRRi.

Announcements / Re: Christmas Plans
« on: January 05, 2013, 06:01:09 PM »
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.

Announcements / Re: Christmas Plans
« on: January 03, 2013, 04:47:15 PM »
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.

Announcements / Re: Christmas Plans
« on: January 02, 2013, 09:10:20 PM »
You wouldn't.