It's not purposely illegible. This one's at least twice as legible as last time.

It's GPL so people can learn from my method, not make off with a syntax file.

And I'm hurting no one. I understand every last aspect of my parser, and modifying it is a breeze for me. I don't care about anyone else's modifying it; no one else develops it.

Besides, it makes me cringe every time a certain SOMEONE makes off with an entire CPP file. Especially when that someone asks me why the Windows one won't compile for Linux.

They're basically telling me that it'd be easier for me to use someone else's method, because mine's too hard for me to debug and understand.

Plus, if I use Yacc, other projects can make off with even more easily modifiable pieces of ENIGMA.

A C++ interpreter is a HUGE amount of work. I don't really even think I'm cut out for it, but my intention is to start the interpreter small and then see where I can take it from there. That is a ways away, though.

I haven't seen that error since I stopped using Dev. I think I recall it being a linker error to do with zlib. Are you linking to libzlib.a?

GIMP is a lot to take in. But once you realize that there IS a one-pixel pencil tool, it starts to work its way into your heart. <3

Yoyo would have to be pretty desperate to break down and buy ENIGMA. No matter how well it worked.
'Sides, they'd ruin it.

Linux version *should* work on Mac, with a few hours of tinkering.
Most of ENIGMA is from scratch. Two exceptions are ZLib and LibFFI.

3D functions will be what I'm working on when everyone else is doing the easier functions. (Not long after the release of R4).

You're a Linux user. The Developers care what their stuff looks like on Linux, and Linux endorses GTK, so your pidgin download isn't 20MB.

If I had to choose one, it'd be wxWidgets, I imagine. I've used wxWidgets applications without ever knowing they were cross platform. That's more than I can say for so much as one GTK application. I mean, aside from the obvious GIMP, whose main toolbar... WINDOW... is so inconvenient and tedious to find that it isn't worth using it at all (until recently, as it now floats on top, but still kinda wreaks), who everyone knows is GTK, even the ones who don't know what GTK is. Let's look at Pidgin.

One fine day, I'm on Pidgin, as I need to speak to Ism on LGM matters. My contact list isn't enormous, but it's convenient to just type the first few letters of the name you're looking for and hit enter. I do that for all my Windows applications.

So I get as far as the first letter, when the box that pops up freezes. Won't accept input. But it had selected her name.

So I press Enter. Nothing happens.
So I press Escape. Nothing happens.

Each time I forgot in any GTK app, I'd be stuck waiting for five seconds for the damn box to go away. That includes GIMP's file selector.


Oh, and in my getting mad about the little things, I didn't even mention that GTK has a 17 or so MB runtime, that basically every program that uses it comes with an updated version of. The compiler's big enough; MinGW is roughly 10MB zipped. ENIGMA adds another couple to that. Can't really say I want a 19 MB runner if it can be avoided.


However. Despite it all, GTK is relatively clean, and ENIGMA could use an interface that can be natively compiled without incident, or breaking GPL rules. So no matter what runtime/API anyone uses, I'd be happy to see an interface.

Though as the above suggests, I'm partial to wx. I started making a UI one day before I realized what a task it'd be. Did I mention Code::Blocks has a built-in wxWidgets WYSI(basically)WYG editor?

Doesn't matter if the spec is human-authored or not. (And for all you know, it isn't. [That was a joke; you don't have to go calling people morons over it])
ENIGMA's API is human-written. GCC's optimizer is human-written. But there are some things that only a human can optimize.

Maybe a parser's not one of them; maybe it is. It doesn't really matter to me; my way will at very, very least keep up. And considering its comparative performance to GM, Which I'm not going to bother quantifying again, I'd say it'll do much more than that anyway.

Either way, if both methods had identical output with identical speed, I would still stick to this one simply because I'm already writing it, and I'm the only one that will ever be reading it. Anyone that thinks they have the incentive can fork the project and write their own parser that does what mine can.

Until then, we're sticking to what I'm writing.

Yeah. My intention is to assemble a small group of coders ranging anywhere from novice to expert, as long as they have what it takes to rake together some GM functions.

Getting the behind-the-scenes things to work is the hard part; from there, it's all going to start flowing. (I hope.)

When R4 Comes out, you'll notice a new script-like resource that I codenamed whitespace. (The name's cute, but it'd confuse people)

Basically, this is your very own piece of C++ that ENIGMA will parse to gain additional function names. If you recreate an unimplemented GM function (or set of functions where possible) or a potentially useful library of functions, then I'd be happy to add them officially.

If for some reason I don't add them officially, you can still distribute them and others can easily add them in.

The preprocessor is what handles #preprocessor directives.

I believe this is the reason compilation was just "too difficult" for the Game Maker team. They were all thinking in a box; this is the way it must be done. We must use a tree; we can't leave it to a far more experienced, far longer lived team such as the G++ one.

I'll say it again; it takes some nerve to even think we can compete with that compiler. It's totally out of the question to even try. Drop your fantasies, -- or at least, scenarios for usefulness of a token tree -- and realize that there's no need for it. Retro's right: the point is to make it so GCC, a far more capable compiler than either of us could hope to write, can read it. Only this, and nothing more.


You just told me you no longer want to use a complete tree, just a ...not tree... generated parser. So. why don't we let this war die until then.

In fact, until anyone has something to showcase, I don't really want to hear any more about it. The flaming is starting to get on my nerves. So show your knowledge and exhibit your idea by posting progress, not by flaming the hell out of anyone that disagrees with you.


As for me...
Progress: CFile parser is working quite nicely. There's a scope problem I'm just about to fix: checking if a variable already exists to report redeclaration needs to be sensitive to what scope the originally declared thing is in.

For example.

Code Select Expand


struct a;
namespace b;
{
  int a;
}

Currently bitches that I'm naming two types in the declaration (int and ::a). It shouldn't do that.

All right, solved, 12 minutes later.

Optimizing compiler should take care of all that, anyway.

That's why I've redone var at least 100 times.
I'll be modifying std::string next; have to make sure it can interface with var flawlessly. And boy do I have a plan for that.