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

General ENIGMA / Re: Useful Tips
« on: December 27, 2009, 09:31:45 PM »
Actually, you're both wrong. The result is what you would get if you cast the string to int*, subtracted 2, and dereferenced. String is just a char* prefixed with a length followed by a reference count, representing the number of objects sharing that pointer.

What I mean by that is that for each string, or each shared string, somewhere in memory is an int for length followed immediately by an int for number of objects sharing the string, followed immediately by the string itself, not a pointer to it.

Announcements / Re: Merry Christmas
« on: December 27, 2009, 09:18:04 PM »
var a;
a[xsize,ysize]; will work just fine. Or in R3, I believe you may need to add an =0; to that.
Also, you can declare int a[xsize][ysize]; but then the array bounds are non-negotiable and unforgiving.

General ENIGMA / Re: Useful Tips
« on: December 27, 2009, 06:59:24 PM »
Few bones to pick.

Tip 5. Switch statements are nice in a real language, not in GML. The problem with switch() in GM (and ultimately in ENIGMA) is that a real switch statement uses integers alone. And only constants. None of that "case hspeed:" shit. ENIGMA will only be able to generate an efficient switch() statement if the 'arguments,' if you will, sent to the case labels are constant integers (Preferably literals [like 0, 1, 2...], though consts like c_red are fine).

Tip Luis. ...That tip is practically useless here. In C, it'd be helpful, but this isn't C anymore, and the assumption is that a good C programmer knows that. In C++ (and therefore ENIGMA), std::string::size() operates in constant time. for(size_t i = 0; i < somestr.size(); i++) is just as efficient as if you had precalculated it. (Save some decrementing and dereferencing, which would probably be optimized anyway). For best practice, I suppose it would be a good idea to declare it as const, assuming the size of the loop doesn't change (which it is prone to, anyway), but I don't see it as necessary, and it's probably a bad idea to tell people to do that when it'll end up costing some poor bastard's loop to end early (or, God help him, late). Furthermore, if the size wasn't going to change, and you are only incrementing i by one each iteration, for (size_t i = 0; somestr[i ]; i++) would be your best bet.

Announcements / Re: Merry Christmas
« on: December 25, 2009, 10:08:50 AM »
It's manageable. Will probably cost me more code, in addition to some more thought, but it'll be fine.

Announcements / Merry Christmas
« on: December 25, 2009, 03:01:18 AM »
I wanted to have a community-size test out today to begin the debug process, but STL provided me with more debugging goodness than I could ever have wanted.
For example, as it happens, they have created a set of templates (templates can be defined as 'crude, bitter replacements for a system that has worked for years without triangular-bracket goodness') which compare if two types are equal. It looks like this:

Code: [Select]
  template<typename, typename>
    struct __are_same
      enum { __value = 0 };
      typedef __false_type __type;

  template<typename _Tp>
    struct __are_same<_Tp, _Tp>
      enum { __value = 1 };
      typedef __true_type __type;

ENIGMA produces a loud wail if the first template above has anything in it. Yes, that's my fault entirely, but this shouldn't be a concern; these templates effectively accomplish nothing but are included by things anyway. Honestly, it's like saying string("string") just to be sure you're dealing with a string. And that's the closest I can compare it to in GML. I remeber when Dylan implemented is_real.

double is_real(double) { return true; }
double is_real(int) { return true; }
double is_real(bool) { return true; }

Anyone who understands a little about operator overloading is laughing right now, but only the truly brave are laughing at the templates above.

But anyway, it's Christmas. A time to forget how angry you are at every code input box in your vicinity, as well as the developers who made said box possible. A time to pretend that the godawful wail is actually a none-to-well-executed rendition of Jingle Bells. Best wishes to everyone; I'll probably be a few 60 miles north of here tomorrow with my lap top. Maybe sleeping, considering it's three in the morning and all I wanted was to have something to pass out today. <____<"

Instead, I'll just be passing out in general, and I welcome you all to do the same.
Merry Christmas guys, and thanks for your support.

(Maybe I can squeeze out a release by New Year's if I keep sleeping like this... [Actually, I'm better off taking the sleep])

Announcements / Re: Hats
« on: December 23, 2009, 05:30:58 PM »
Yes, when I started ENIGMA, it was for a couple reasons.

1) Mark thought compiling GML would be "too difficult." It was on his list of things that will never happen for that very reason. I thought he was wrong.
2) GM could no longer satisfy my need to experiment. I knew all the GML there was to know, and the bleeding edge of GM's progress was slow and cumbersome.
3) For a long time I thought it unfitting that there was a Java port of GM, but not a C one. I'd heard from many people that GML was syntactically similar to C, and I figured it was only a matter of time before someone would step up to the plate. When I was fed up with GM, That someone ended up being me.

The project has made it this far because there's always been another something to understand. As I've worked with C++, I've grown to love it more and more, and have likewise grown more efficient. As parts of the project fell into my immediate understanding and thus became too easy for my taste, I moved on to another set.

Now that I'm starting to understand all of C++ (very easy to do when you're writing a parser for it), the stuff once marked as boring and tedious is now marked as so simple, it can be done in a matter of minutes. For this reason, when all the hard parts are done, everything that remains will be child's play...

What keeps me going is Yoyo's infinite stupidity paired with my original commitment. Originally I didn't intend to use ENIGMA myself as I felt it was too limiting. But now that it can do C++... ahahahah, there is no limit.

Announcements / Re: Hats
« on: December 23, 2009, 11:11:40 AM »
That's odd, I never thought the major allure would be price just yet. I mean, yes, it's nice to save 20 bucks, but ENIGMA doesn't have all GM's resources yet; I figured people would be more interested in the tack-on-ables.

Announcements / Re: Hats
« on: December 22, 2009, 11:39:14 PM »
Well, my work there was just done for me. *Digresses to avoid poisoning the well*

Announcements / Hats
« on: December 22, 2009, 01:03:59 PM »
I've had to purchase two new hats today just to have something to eat each time I was dead wrong about something. It's mildly annoying, but don't worry.

That code I showed yesterday is nearly working; it ignores the second specialization for a reason I am now looking into.

Yoyo has evidently released a new version of GM, which I won't be trying number one because I hate their EULAs and number two because I'm on Ubuntu. If someone would be so kind as to provide me with a list of new functions, though, I'll see to it that they are on my todo list.

Also, serp has R3 compiling R4 correctly and is optimizing that. I rewrote var again and to my dismay, it will be very difficult to get string() working as a constructor to std::string rather than a function. I will at least attempt it, however.

I've been hoping to have a small (community) debug release soon, and Yoyo actually managing to make a release has only amplified that desire. Will post updates as they become relevant.

Announcements / Re: Standings
« on: December 22, 2009, 08:06:15 AM »
Yoyo prefers unfulfillable release dates to progress reports.

Announcements / Re: Standings
« on: December 21, 2009, 08:07:55 PM »
It does make a difference. Instead of size_t, R3 used unsigned int. Comparing it to npos would always return false. Serp's solution was to use unsigned(-1) instead, mine was to just use size_t instead of unsigned int.

Announcements / Re: Standings
« on: December 21, 2009, 11:09:50 AM »
Serp chooses to use -1 in place of npos because string should never exceed 32 bit size limit anyway, which is rational, but I prefer to just use size_t because that's apparently the expectation and if it fails, it's STL's fault.

*eats hat*

Announcements / Re: Standings
« on: December 21, 2009, 09:14:16 AM »
That is test code for the parser. The actual code it will be parsing is much worse.

Announcements / Standings
« on: December 20, 2009, 07:15:09 PM »
Serp's been working on fixing up R3 with the R4 code. He's on Ubuntu, and stuff seems to just not want to work for him. The entire parser kinda stopped working for him, halting and all... Not really sure why.

As for me, I'm working on this last little piece of C++:

Code: [Select]
template<class c> struct squirrel
  int nuts;
  int tree;
squirrel<bool> epitome;

template<> struct squirrel<1>
template<> struct squirrel<2>

As soon as that parses correctly, the STL headers should all parse, and then it'll all be over.

To be honest, I'll probably have R4 done before serp finishes making R3's compiler work on Linux.

General ENIGMA / Re: State of the project
« on: December 19, 2009, 10:14:33 PM »
Certainly. Since the extent of d3d was... Its sad excuse for a model format.