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

1966
General ENIGMA / Re: ENIGMA's value
« on: May 16, 2010, 04:45:42 PM »
What are you saying? :troll:

1967
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 04:45:15 PM »
Oh, that was just one of the 600 problems I've encountered on the way. Indented comments were executed; that was a more recent one.

The one I'm dealing with now is that parameters work differently on Windows. make GRAPHICS=OpenGL doesn't work anymore.

1968
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 02:16:12 PM »
You forgot the :troll:

Also, that's why "Compile" lets you choose the full filename. The 'exe' is meant for ENIGMA to run/work with.

1969
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 02:07:11 PM »
As a matter of fact, Linux is the only OS they work on at the moment, because Windows can't call make. ^_^
System() can't parse the program name from the arguments.
CreateProcess() can't find mingw32-make.
So really, it only works on Linux at the moment.

Makefile is given priority over makefile; other than that, either is fine.

Only one makefile should be outputting an exe, and it's the one under SHELL. Windows will only run EXE, Linux will run anything given --e permissions. So I used exe.

1970
Announcements / Re: Fixed those Makefiles
« on: May 16, 2010, 12:21:57 PM »
The splash screen doesn't display here; I assumed you'd removed it.

1971
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 09:31:15 PM »
Well, it's an irremovable part of ENIGMA's philosophy. And it's a bit late to fork the project over it. If you don't like it, you don't like ENIGMA, and you probably don't belong here.

1972
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 08:25:19 PM »
In the case that it is declared as "local int", "local string", or what have you, in a later event, which could be considered bad practice, but it seems asinine to disallow that over the minuscule amount of work taken to support it.

1973
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:55:06 PM »
COBOL did work fine, then we found something better.
Hey, go find something better.

Don't give me "lots and lots" bullshit; I can enumerate every inconsistency with the languages and what's been done about it. There are roughly five. Holding lexed code to determine what type an object is before acting on it isn't one of those inconsistencies.

1974
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:46:05 PM »
I recall no such people.

C++ isn't a problem with the architecture; clearly it's working fine. Just not with your proposal. This doesn't agree with your idea of what I should be doing, so you see it as a problem.

1975
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:42:43 PM »
Great ad hominem. Is there an argument to go with it?

1976
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:40:59 PM »
And to that I'm saying "Fuck you."

1977
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:39:41 PM »
That's impossible to do from a compiled language with integer-id access.
Furthermore, neither of us know that for certain.

1978
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:36:46 PM »
There is no difference between what ENIGMA is doing and what Mark did with globalvar.

Also, if you're going to forward that ENIGMA should introduce no new functionality over its "ingredients," you destroy your component argument for systems that can actually use them later on. Or rather, your brother's; you never actually forwarded an argument.

1979
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:33:41 PM »
Good argument. (Y)

What ENIGMA does with its token string later on is essentially what C++ does while it links. It's also what Mark has to do to check if a variable was previously declared as globalvar.

1980
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 06:09:40 PM »
Nah, I don't like that idea. :troll:

Anyway, the tokens need to remain in memory so I can go back over them for another pass as more information becomes available, such as localized types and members by certain types.

For example, a.size would mean two different things based on the type of "a." If left undeclared, or declared scalar, the meaning is to access "a" as an object by id, then access implicit member "size." Otherwise, it should be left as-is.