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: Parsers -- A novel by Josh @ Dreamland
« on: August 29, 2009, 11:24:16 AM »
There's a certain trust that comes with GPL software. If you're going to start a project under a new name with a new purpose that operates almost entirely off of code you stole from me, that's not right.

However, I don't really care, and I don't ask him to stop; I'm just not going to help him do it.

At this point, probably the only way anyone is going to be able to make off with my parser is if they have no intention to modify it. I still don't care. I'm not going out of my way to be a team player for Yacc just to make it easier for other people.

And I've stopped working on my parser for a month in the past, and still came back and modified exactly what I needed to. Actually, it was more like three or four months. And my memory is pretty damn good. Being perfect has nothing to do with it.

And now this brings me to trying to determine why you're so sore about me not using a parser generator. Most of the other teams have successfully devised an at least almost-working parser in it... Basically, if it's so damn easy to make a parser in it, what does anyone have to gain from me doing so? They can just off and make their own, just like Rusky.

Every benefit to using a generated parser that you named off, you later alienated to make a new case. You've managed to make me lose what little respect I had left for the idea.

Announcements / Re: Parsers -- A novel by Josh @ Dreamland
« on: August 29, 2009, 10:53:18 AM »
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.

Announcements / Re: Parsers -- A novel by Josh @ Dreamland
« on: August 29, 2009, 10:20:26 AM »
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.

Issues Help Desk / Re: *solved* execute_string
« on: August 26, 2009, 05:14:22 PM »
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.

Issues Help Desk / Re: Compiling Enigma
« on: August 26, 2009, 05:12:53 PM »
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?

Issues Help Desk / Re: Suggest image editor?
« on: August 26, 2009, 05:08:30 PM »
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

General ENIGMA / Re: Expanding Enigma
« on: August 26, 2009, 05:03:19 PM »
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).

General ENIGMA / Re: Enigma IDE (written in C++ using GTK+)
« on: August 24, 2009, 10:34:31 PM »
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.

General ENIGMA / Re: Enigma IDE (written in C++ using GTK+)
« on: August 24, 2009, 09:23:41 PM »
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?

Announcements / Re: Parsers -- A novel by Josh @ Dreamland
« on: August 24, 2009, 06:40:11 PM »
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.

General ENIGMA / Re: Expanding Enigma
« on: August 23, 2009, 08:06:38 PM »
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.)

General ENIGMA / Re: Expanding Enigma
« on: August 23, 2009, 07:39:01 PM »
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.

Announcements / Re: Parsers -- A novel by Josh @ Dreamland
« on: August 23, 2009, 07:36:21 PM »
The preprocessor is what handles #preprocessor directives.

Announcements / Re: Parsers -- A novel by Josh @ Dreamland
« on: August 22, 2009, 08:40:33 PM »
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]
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.

Announcements / Re: Parsers -- A novel by Josh @ Dreamland
« on: August 22, 2009, 12:32:29 PM »
Optimizing compiler should take care of all that, anyway.