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 »
2236
Proposals / Re: execute_string via Google V8
« on: March 27, 2010, 08:59:16 am »
What? That had nothing to do with pointers... GM users won't even know it's running V8 or that anything is being passed by pointers. It'll look to them just like it did in GM.
2237
Proposals / Re: execute_string via Google V8
« on: March 27, 2010, 08:52:12 am »
The same way it works in GM:
Now, had I used "x" as you proposed, it also would have behaved like GM: execute_string() would call V8, V8 would see "x" which is implemented as an accessor. The accessor will load the current instance (as determined by the C++ proceedings of ENIGMA)'s x coordinate and return it for the JavaScript to use and to write to. Accessors have both a read and and write C++ event.
And by "own scope," I mean a scope from which it cannot find "var xx" and must use this->xx.
Code: [Select]
var xx,yy;
xx = 0;
yy = 5;
execute_string("xx="+string(yy)+";");
show_message(string(xx));
Shows zero; execute_string() gets its own scope.Now, had I used "x" as you proposed, it also would have behaved like GM: execute_string() would call V8, V8 would see "x" which is implemented as an accessor. The accessor will load the current instance (as determined by the C++ proceedings of ENIGMA)'s x coordinate and return it for the JavaScript to use and to write to. Accessors have both a read and and write C++ event.
And by "own scope," I mean a scope from which it cannot find "var xx" and must use this->xx.
2238
Announcements / Re: Collisions
« on: March 27, 2010, 08:21:53 am »
Not that I think anyone that needs the min() or max() of that many arguments shouldn't be using an array and iterating it him/herself.
It's just nice to shed GM's limits.
It's just nice to shed GM's limits.
2239
Announcements / Re: Collisions
« on: March 27, 2010, 07:59:33 am »
I think he's remembering the good ol' days when I was satisfied just to have 4x as many as Mark.
2240
Proposals / Re: execute_string via Google V8
« on: March 26, 2010, 10:24:20 pm »
That wasn't very constructive.
2241
Announcements / Re: Summary
« on: March 26, 2010, 10:16:13 pm »
> anyway, what all is left for R4? also, are there gunna be any native binaries of this example?
Finishing scopes in the GML formatter and syntax checker; not imperative but still desirable. Formatting with() and implementing improved switch().
That's enough work until Sunday.
Then all that's left is setting up communications between LGM and ENIGMA, including better resource translation and error reporting/lookup.
Finishing scopes in the GML formatter and syntax checker; not imperative but still desirable. Formatting with() and implementing improved switch().
That's enough work until Sunday.
Then all that's left is setting up communications between LGM and ENIGMA, including better resource translation and error reporting/lookup.
2242
Announcements / Re: Summary
« on: March 26, 2010, 09:51:38 pm »
Car is significantly easier to type than engine...
2243
Proposals / Collaboration by Timestamps
« on: March 26, 2010, 09:50:48 pm »
Serp remarks that GM is unsuitable for collaboration due to resources all being in one file.
I think a nice fix for this would be to store a time of creation (milliseconds-since-Jan-1970 style) as well as a time of last modification and time of last splice in with every resource.
LGM could then offer a splice function that would check each of the three things, like so:
I think a nice fix for this would be to store a time of creation (milliseconds-since-Jan-1970 style) as well as a time of last modification and time of last splice in with every resource.
LGM could then offer a splice function that would check each of the three things, like so:
If the resource exists in A (true, we're iterating)
{
If it doesn't in B (!B)
{
Keep A
}
else, it does exist in B (B)
{
If the time stamps of creation are the same (A.created == B.created)
{
If the time stamp of modification of A matches the time stamp of last splice of A (A.modified == A.spliced)
{
If the time stamp of modification of B does NOT match the timestamp of splice of B (B.modified != B.spliced)
Assume B is newer, and copy B to A
Else
Continue to the next resource; they should be the same.
}
else
{
If the time stamp of modification of B matches the timestamp of splice of B (B.modified == B.spliced)
Assume A is newer; keep it
Else (B.modified != B.spliced and A.modified != A.spliced)
I have no idea what to do here. Ask the user, show a Diff somehow. This is what requires work.
}
}
else, they are different resources entirely (A.created != B.created)
{
If the names are the same, both users may have been thinking the same thing (A.name == B.name)
If on prompt for action the user says to skip it
Continue to next resource
Increment the id of B to the next available resource ID.
}
}
}
2244
Proposals / execute_string via Google V8
« on: March 26, 2010, 09:25:32 pm »
GML's consistency with C++ is nothing compared to that with JavaScript. I could add a newline after everything and not have to worry about adding semicolons. Hell, I could put everything in parentheses, too; I wouldn't even need a lexer. V8 is amazingly fast, and it compiles the JS Just-in-Time.
I believe I mentioned earlier that JavaScript even has a with().
I'm vaguely familiar with the workings of V8, and it would not be difficult to use some basic accessors to simulate odd effects of GML, such as speed/direction - hspeed/vspeed correlations.
Functions are also amazingly simple to add to either language across V8.
I believe I mentioned earlier that JavaScript even has a with().
I'm vaguely familiar with the workings of V8, and it would not be difficult to use some basic accessors to simulate odd effects of GML, such as speed/direction - hspeed/vspeed correlations.
Functions are also amazingly simple to add to either language across V8.
2245
Proposals / Debug mode: Tracking array bounds on scalars
« on: March 26, 2010, 09:20:20 pm »
Var makes it so users don't have to worry about their array bounds. Scalars allocated in bulk do not.
The idea of present is abstract and unresearched. Basically, we create a structure to proxy for each scalar*, such as int* or double*. A second proxy (or perhaps just the class of the first) will be used with calls to new[], having that operator overloaded.
So, in int_allocator::operator new[] (size_t sz), we do something like this:
value = new int[sz+1];
*value++ = sz;
Treating the struct as an int* will work just like a regular int*, but more operators could be overloaded to ensure correct performance.
#define is also an option; this is just a debug mode.
Upon access via the other class, int_proxy, the allocator class will be decremented and dereferenced for a bounds check.
The idea of present is abstract and unresearched. Basically, we create a structure to proxy for each scalar*, such as int* or double*. A second proxy (or perhaps just the class of the first) will be used with calls to new[], having that operator overloaded.
So, in int_allocator::operator new[] (size_t sz), we do something like this:
value = new int[sz+1];
*value++ = sz;
Treating the struct as an int* will work just like a regular int*, but more operators could be overloaded to ensure correct performance.
#define is also an option; this is just a debug mode.
Upon access via the other class, int_proxy, the allocator class will be decremented and dereferenced for a bounds check.
2246
The rest of the forum's rules apply here, too. Go figure.
Anyway, the rules here vary according to the mood of the moderators. Your topic may be praised one day and locked the next on the grounds that it is "stupid."
This forum was made mostly as a notepad that I don't have to leave open all the bloody time. Bonus: Other people can read, comment, build onto, and suggest, not only on my ideas, but on each others'.
That said, no "stupid" ideas. But do feel free to make suggestions.
Your suggestions are subject to being flamed to hell before ever being considered. Being flamed to hell does not mean that your suggestion has not nor will not be considered.
I still encourage such suggestions, however. Especially the useful ones.
This IS a place for debate.
Something about tacos.
Anyway, the rules here vary according to the mood of the moderators. Your topic may be praised one day and locked the next on the grounds that it is "stupid."
This forum was made mostly as a notepad that I don't have to leave open all the bloody time. Bonus: Other people can read, comment, build onto, and suggest, not only on my ideas, but on each others'.
That said, no "stupid" ideas. But do feel free to make suggestions.
Your suggestions are subject to being flamed to hell before ever being considered. Being flamed to hell does not mean that your suggestion has not nor will not be considered.
I still encourage such suggestions, however. Especially the useful ones.
This IS a place for debate.
Something about tacos.
2247
Announcements / Re: Summary
« on: March 26, 2010, 08:59:08 pm »
> Just curious, but shouldn't an error like that be reported in a more typical fashion, rather than crashing to hell?
We can have a debate over this if we need, but basically I think it's best to leave errors for the testing phase and let the fast code be fast on its own.
The goal is to incorporate some sort of tracker for bounds overflows, but that can be difficult when a scalar type is used. Also, that's really something for debug mode.
We can have a debate over this if we need, but basically I think it's best to leave errors for the testing phase and let the fast code be fast on its own.
The goal is to incorporate some sort of tracker for bounds overflows, but that can be difficult when a scalar type is used. Also, that's really something for debug mode.
2249
Announcements / Re: Summary
« on: March 26, 2010, 07:43:43 pm »
Heh, don't worry, guys, it wasn't an ENIGMA bug. Just an error with how the particle system was designed (specifically when I started using double instead of var).
Those who are interested can download the fix (and some extra-hoursepower builds, three total):
http://dl.dropbox.com/u/1052740/SHELL.zip
Those who are interested can download the fix (and some extra-hoursepower builds, three total):
http://dl.dropbox.com/u/1052740/SHELL.zip
2250
Announcements / Re: Collisions
« on: March 26, 2010, 07:30:34 pm »
min(x,y,z) = min(x,min(y,z))
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 »