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

Function Peer Review / Re: Brainstorming
« on: March 23, 2010, 07:00:55 AM »
Nice to see so many people taking interest in coding things.
... :P

They probably want to wait for a new working version before they start coding. Those who will do any coding for the project at all, I mean. I don't blame them, really.

Besides, 'Whitespace' will make it so they can implement their functions in C++ just as it will look if included in the release, and will let them test their new functions themselves.

Announcements / Re: Another choice.
« on: March 21, 2010, 06:41:30 PM »
Yeah. I believe with() is Delphi, but I'm not certain. It'd make sense if it was. You can see it in JavaScript as well.

Off-Topic / Re: Essay
« on: March 19, 2010, 09:19:02 AM »
Heh, it's just where you pretend to know what you're talking about by writing a paper on a topic you may or may not have any interest in.
Anyway, I'm done now, but am currently dealing with other personal issues and should be back to work in a few hours following school today.

Announcements / Re: Another choice.
« on: March 18, 2010, 09:28:47 AM »
Posted about having to write an essay elsewhere. I'm nearly done.
Ism's getting Java to pass resources to DLLs and the like.

Off-Topic / Re: Essay
« on: March 17, 2010, 10:53:46 PM »
Yes, I did mean libraries in general, but I will use DLL because most users can relate to that name better, and I'll probably use EXE because Unix doesn't have an extension and "exe" is short for "executable" anyway.

Off-Topic / Essay
« on: March 17, 2010, 06:11:31 PM »
I'll be essaying for the next day and a half or so.

Didn't think it was worth a news post.

Ism got DLL's working in Java. She's now looking in to how resources can be passed via function calls. Shouldn't be hard to get ENIGMA DLL-ized from there.

Announcements / Re: Another choice.
« on: March 17, 2010, 06:10:50 PM »
If it's of any consolation, I replied to you in the wrong thread.

Announcements / Re: Another choice.
« on: March 16, 2010, 05:41:32 PM »
Oh, you're right. I should just include the GCC with it like you first said; wouldn't want to risk the project looking "stupid" to someone.

Also, I'd really like to see an English->French translator hard coded over the two languages' twelve similarities.

@The 11th plague of Egypt
It's actually probable that the majority of users will try their best to avoid LGM, doing major development in Game Maker then bitching when they've used something ENIGMA doesn't support yet a month later when they're ready to compile.

"Also, breaking one of the most idiotic features of GML in order to save one of the smartest features of C++ seems a good trade to me."
Now this, I like.

Announcements / Re: Another choice.
« on: March 16, 2010, 01:13:42 PM »
Would be too big and slow to include GCC with everything. I'll need to write a fifty-some line parser to make GML look like JavaScript, then presto.

Announcements / Re: Another choice.
« on: March 16, 2010, 12:33:34 PM »
Directly converting GML to C++ is impossible. They should not expect it.

IMHO we are just trying to make C++ and GML live togheter.

Call me a philosopher, but I'm not sure what you mean by "impossible" or "directly converting." ENIGMA's purpose is to convert GML to C++. I started the project because I noticed enough similarities in syntax that doing so would be relatively easy, in fact. Some things will obviously never work in plain C++, the first of those being with() {}.

@miky as well: Including a C++ compiler is certainly unnecessary for implementing execute_string() for backwards compatibility with GM, and is not really necessary for interpreting most C++ features, either. Yes, there are projects that can interpret C++, but I'm reasonably certain such projects are bloody massive. A smaller alternative is to do a bit more parsing and pass strings to Google V8 (A damn nice JavaScript JIT compiler). With V8, I can link in globals at runtime, and write a variable accessor class called Cthis, which will be appended before all locals (or all variables in general). So, the user's code will be for example, x = 0; y = 0;. It'll be passed to V8 as Cthis.x = 0; Cthis.y = 0;. V8 will call Cthis's accessor for "x," which is a C++ function I register. It'll behave just like GM's interpreter, only, sad as it may be, probably faster. The work for me would be so small as to be laughable.

a = 0;
var a;
a = 3;

Would work just like GM, because after they declare var, I just remove it and stop adding Cthis before the variable. This can be done entirely linearly, and without buffer resize as I can just space out "var" (as in, replace it with "   ").

The only things that may require a new buffer is adding semicolons to the code, which isn't always necessary in JavaScript, either; only when no newline is given. Hell, I might even be able to edit V8 to not require newline either, if I really wanted. Though, that's quite unlikely.

Did I mention it's JIT compiled?

As for scripts returning the value of the last-called script... Heh, that's kind of neat, I was unaware it did that; that's usually a behavior defined in interpreted language. I can't replicate that, as far as I know, simply by not providing a return value in lieu of the user's... I could if the last reference were left in EAX, which is unlikely.

I don't think I'll be replicating any useless GM bugs.

Announcements / Re: Another choice.
« on: March 15, 2010, 08:59:34 PM »
Didn't want to bring up that difference in example code of another difference.

Announcements / Re: Quick Poll
« on: March 14, 2010, 03:39:08 PM »
Like I said, C++ people make this particular mistake a lot. It happens, and it could likely piss people off.

Announcements / Re: Another choice.
« on: March 14, 2010, 12:44:11 PM »
Game_boy: Should make that a priority, actually.

All of those will. Even global var, which will be done like so:
#define globalvar global var

Announcements / Re: Another choice.
« on: March 14, 2010, 11:23:23 AM »
My thoughts ^

Breaks this v
Code: [Select]
if (true)
  var a;
  a = 3.14;

And by "breaks," I mean "fixes in a way that may piss off a very small percentage of GM users."

Announcements / Re: Another choice.
« on: March 14, 2010, 11:15:05 AM »
For the first pair, 1 and 2 were both defining var's behavior.
The second and third, we can't make that assumption...

The third option specifically seems contradictory to the philosophy of a keyword. Defining where the var is coming from should be retro-active. You mentioned function declarations in Python; same principle. Most people put their vars at the top. Most Python people put their imports at the top.

I believe the manual uses the word "declare" for "var," which is basically all the proof I need that Mark intended it to be like a real language... Think JavaScript scoping, again. I'll look for the page in question.

Josh @ Dreamland:
he whole dilemma here is that we don't know what Mark was thinking because he implemented it badly
Josh @ Dreamland:
well, if we're going to turn this into a huge genetic fallacy we may as well have our facts straight
Josh @ Dreamland: