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

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.

Proposals / Re: execute_string via Google V8
« on: March 27, 2010, 08:52:12 am »
The same way it works in GM:
Code: [Select]
var xx,yy;
xx = 0;
yy = 5;
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.

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.

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.

Proposals / Re: execute_string via Google V8
« on: March 26, 2010, 10:24:20 pm »
That wasn't very constructive.

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.

Announcements / Re: Summary
« on: March 26, 2010, 09:51:38 pm »
Car is significantly easier to type than engine...

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:
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
          Continue to the next resource; they should be the same.
        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 ( ==
        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.

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.

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.

Proposals / Rules
« on: March 26, 2010, 09:11:27 pm »
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.

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

Announcements / Re: Collisions
« on: March 26, 2010, 08:17:07 pm »
For as many as you like.

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):

Announcements / Re: Collisions
« on: March 26, 2010, 07:30:34 pm »
min(x,y,z) = min(x,min(y,z))