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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
2266
Function Peer Review / Re: Brainstorming
« on: March 23, 2010, 07:00:55 AM »
Nice to see so many people taking interest in coding things.
...
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.
...

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.
2267
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.
2268
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.
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.
2269
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.
Ism's getting Java to pass resources to DLLs and the like.
2271
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.
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.
2272
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.
2273
Announcements / Re: Another choice.
« on: March 16, 2010, 05:41:32 PM »
@miky
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.
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.
2274
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.
2275
Announcements / Re: Another choice.
« on: March 16, 2010, 12:33:34 PM »Quote
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.
2276
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.
2277
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.
2278
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
...heh.
All of those will. Even global var, which will be done like so:
#define globalvar global var
...heh.
2279
Announcements / Re: Another choice.
« on: March 14, 2010, 11:23:23 AM »
My thoughts ^
Breaks this v
And by "breaks," I mean "fixes in a way that may piss off a very small percentage of GM users."
Breaks this v
Code: [Select]
if (true)
{
var a;
a = 3.14;
}
show_message(string(a));
And by "breaks," I mean "fixes in a way that may piss off a very small percentage of GM users."
2280
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.
Essentially,
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.
Essentially,
Quote
Josh @ Dreamland:
he whole dilemma here is that we don't know what Mark was thinking because he implemented it badly
retep998:
WHO CARES WHAT HE WAS THINKING?
retep998:
I LIKE IT THAT WAY
retep998:
AND IT WORKS
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:
haha.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »