ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

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
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.

1967
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.

1968
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.

1969
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.

1970
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.

1971
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.

1972
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.

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

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

1975
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.

1976
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.

1977
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.

1978
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.

1979
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 05:52:29 PM »
Except that each operator would require its own element in the list, with a forward and reverse pointer. Unless I'm missing some magical way to eliminate that, we'd be multiplying by either 9 or 17 the size of each operator.

1980
Proposals / Re: Tiering vs Components
« on: May 15, 2010, 05:22:37 PM »
"Your only argument against using Rusky's parsing method besides that you created the one you're using yourself was that it uses too much memory. Having smashed that argument and you having dropped it, now we're back to how you keep choosing crappy methods just because you came up with them."
I acknowledged that replacing the second string with linear-linked structures would be more efficient and would probably be done at some point in the future. Now is not the time, as the only end of that system is to work. Furthermore, I had thought of that idea long, long ago; the method now employed was simply quicker to implement.

Moreover, it is unlikely that the newer method would save memory, but it would probably save insertion time. Because I don't know the gain and the gain is unnecessary, it's not high on my priority list.