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 »
2416
Announcements / Re: Happy New Year
« on: January 07, 2010, 09:37:12 am »
miky:
Specialization and accessing of templates based on enumerated constants is the latest loop I've been thrown for. They've kept coming.
Specialization and accessing of templates based on enumerated constants is the latest loop I've been thrown for. They've kept coming.
2417
Announcements / Re: Happy New Year
« on: January 06, 2010, 10:17:11 pm »
Which will be possible thanks to this EVER-CLOSER-DRAWING TO COMPLETION MOTHER FUCKING PARSER.
2418
Off-Topic / Re: Hello I assure Quob
« on: January 05, 2010, 04:02:34 pm »
I think our best bet with this situation is to remove "recaptcha" from the id's of the involved tags >_<"
2419
Announcements / Re: Happy New Year
« on: January 02, 2010, 10:10:39 am »
kkg--
Correct. The parser will need some testing by the general userbase. I have a file of general GML to run it on, but there are so many new scenarios... It'll be best just to have a bunch of users bombard it with test code while some other C coders and I do more functions.
Correct. The parser will need some testing by the general userbase. I have a file of general GML to run it on, but there are so many new scenarios... It'll be best just to have a bunch of users bombard it with test code while some other C coders and I do more functions.
2420
Announcements / Happy New Year
« on: January 01, 2010, 02:55:36 am »
And a happy new decade along with that.
I just finished getting cpp_type_traits.h to parse correctly. That's an accomplishment. Along with that, however, is a regular type_traits.h, which I will be attacking next.
I don't want to give a release date after what happened last time, but I realize now that release dates are the only reason releases happen, so I guess I'm going to have to set one before the end of the month. I don't want to name the date I'm fancying now, some may be able to guess, but the rest of you can just not get your hopes up until I see what the rest of STL brings.
Anyway, a happy new year (and decade) to everyone, and quick recovery to some of my drunker friends.
...I can't stay awake much longer.
I thought this was working a minute ago, but evidently it was just something similar.
Honestly, it'd help to have a list of all template hacks up front. No, not just a reference on templates. A list of these goddamn hacks.
Anyway, good night.
I just finished getting cpp_type_traits.h to parse correctly. That's an accomplishment. Along with that, however, is a regular type_traits.h, which I will be attacking next.
I don't want to give a release date after what happened last time, but I realize now that release dates are the only reason releases happen, so I guess I'm going to have to set one before the end of the month. I don't want to name the date I'm fancying now, some may be able to guess, but the rest of you can just not get your hopes up until I see what the rest of STL brings.
Anyway, a happy new year (and decade) to everyone, and quick recovery to some of my drunker friends.
...I can't stay awake much longer.
I thought this was working a minute ago, but evidently it was just something similar.
Code: [Select]
template<bool, typename>
struct __enable_if
{ };
template<typename _Tp>
struct __enable_if<true, _Tp>
{ _Tp __type; };
Honestly, it'd help to have a list of all template hacks up front. No, not just a reference on templates. A list of these goddamn hacks.
Anyway, good night.
2421
Issues Help Desk / Re: R4... when?
« on: January 01, 2010, 12:58:35 am »
Score_ was joking. I left it at that because I hate setting release dates; something else always has to be done. However, I'm starting to realize that there's always something else that needs done.
I'm not letting this go much longer. I hate to put an answer in months, but less than two.
I'm not letting this go much longer. I hate to put an answer in months, but less than two.
2422
Off-Topic / Re: GM8 .gmres
« on: December 31, 2009, 08:33:52 pm »
All I can say is 'wow.' O_o
I'll notify Ism. She may have this documented already, but may find this useful.
I'll notify Ism. She may have this documented already, but may find this useful.
2423
General ENIGMA / Re: Enigma on other platforms
« on: December 30, 2009, 10:20:03 pm »
Wii is the most readily at my disposal. Hopefully DS will follow. For now, the main concern pertains to Windows, Linux, and ideally Mac.
By design, ENIGMA is meant to be able to switch to the appropriate interfaces for additional consoles. Obviously not all functions will work from platform to platform, but hopefully the vast majority will.
By design, ENIGMA is meant to be able to switch to the appropriate interfaces for additional consoles. Obviously not all functions will work from platform to platform, but hopefully the vast majority will.
2424
General ENIGMA / Re: Useful Tips
« on: December 27, 2009, 10:29:48 pm »
The string pointed to by char* is prefixed with an integer. It's no separate variable; it, in fact, is not referred to by any variable. Much less a private one.
2425
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.
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.
2426
Announcements / Re: Merry Christmas
« on: December 27, 2009, 09:18:04 pm »
Plague:
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.
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.
2427
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.
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.
2428
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.
2429
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:
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])
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])
2430
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.
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.
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 »