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

2221
Proposals / Re: Idea for var
« on: March 28, 2010, 09:58:29 AM »
I want the new var to offer casts to all scalars, optional overloads for iostream and fstream, and a copy-on-write system for arrays (allowing arrays to be passed as function parameters and script arguments).

To preserve speed, we sacrifice memory. It's always been that way with ENIGMA since I found a clue what I was doing. I thought of methods that would make var eight bytes, but I don't want to implement them as they waste instructions.

2222
Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 09:54:25 AM »
Only on C++ things that aren't in GML. Since execute_string is more for compatibility, I'm not concerned with having it support C, really.

2223
Announcements / Re: Collisions
« on: March 27, 2010, 10:09:54 PM »
Man, that's hackish even by my standards. I'll do it.

2224
Proposals / Re: Collaboration by Timestamps
« on: March 27, 2010, 05:58:50 PM »
Quite.

2225
Announcements / Re: Collisions
« on: March 27, 2010, 12:32:18 PM »
Bahaha, yes, all of those things.

2226
Announcements / Re: Collisions
« on: March 27, 2010, 09:06:24 AM »
Game_boy:
Not at present; I could generate one, but I don't think some of the systems I coded are all in there. Like text file manipulation and DLL's.

The 11th plague of Egypt:
Assuming you're talking about ds_lists, they are global. Don't worry, this new system won't break ds_list; it'll supply an alternative to them. Lists are stored somewhat like sprites; a global array of things GM users don't understand, which they can access by an integer from absolutely anywhere. So, a=ds_list_create() will add to that list, "list a;" won't.

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

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

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

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

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

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

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

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

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