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 »
2281
Announcements / Re: Another choice.
« on: March 17, 2010, 06:10:50 pm »
If it's of any consolation, I replied to you in the wrong thread.
2282
Announcements / Re: Another choice.
« on: March 16, 2010, 05:41:32 pm »
@miky
Oh, you're right. I should just include the GCC with it like you first said; wouldn't want to risk the project looking "stupid" to someone.
Also, I'd really like to see an English->French translator hard coded over the two languages' twelve similarities.
@The 11th plague of Egypt
It's actually probable that the majority of users will try their best to avoid LGM, doing major development in Game Maker then bitching when they've used something ENIGMA doesn't support yet a month later when they're ready to compile.
"Also, breaking one of the most idiotic features of GML in order to save one of the smartest features of C++ seems a good trade to me."
Now this, I like.
Oh, you're right. I should just include the GCC with it like you first said; wouldn't want to risk the project looking "stupid" to someone.
Also, I'd really like to see an English->French translator hard coded over the two languages' twelve similarities.
@The 11th plague of Egypt
It's actually probable that the majority of users will try their best to avoid LGM, doing major development in Game Maker then bitching when they've used something ENIGMA doesn't support yet a month later when they're ready to compile.
"Also, breaking one of the most idiotic features of GML in order to save one of the smartest features of C++ seems a good trade to me."
Now this, I like.
2283
Announcements / Re: Another choice.
« on: March 16, 2010, 01:13:42 pm »
Would be too big and slow to include GCC with everything. I'll need to write a fifty-some line parser to make GML look like JavaScript, then presto.
2284
Announcements / Re: Another choice.
« on: March 16, 2010, 12:33:34 pm »Quote
Directly converting GML to C++ is impossible. They should not expect it.
IMHO we are just trying to make C++ and GML live togheter.
Call me a philosopher, but I'm not sure what you mean by "impossible" or "directly converting." ENIGMA's purpose is to convert GML to C++. I started the project because I noticed enough similarities in syntax that doing so would be relatively easy, in fact. Some things will obviously never work in plain C++, the first of those being with() {}.
@miky as well: Including a C++ compiler is certainly unnecessary for implementing execute_string() for backwards compatibility with GM, and is not really necessary for interpreting most C++ features, either. Yes, there are projects that can interpret C++, but I'm reasonably certain such projects are bloody massive. A smaller alternative is to do a bit more parsing and pass strings to Google V8 (A damn nice JavaScript JIT compiler). With V8, I can link in globals at runtime, and write a variable accessor class called Cthis, which will be appended before all locals (or all variables in general). So, the user's code will be for example, x = 0; y = 0;. It'll be passed to V8 as Cthis.x = 0; Cthis.y = 0;. V8 will call Cthis's accessor for "x," which is a C++ function I register. It'll behave just like GM's interpreter, only, sad as it may be, probably faster. The work for me would be so small as to be laughable.
a = 0;
var a;
a = 3;
Would work just like GM, because after they declare var, I just remove it and stop adding Cthis before the variable. This can be done entirely linearly, and without buffer resize as I can just space out "var" (as in, replace it with " ").
The only things that may require a new buffer is adding semicolons to the code, which isn't always necessary in JavaScript, either; only when no newline is given. Hell, I might even be able to edit V8 to not require newline either, if I really wanted. Though, that's quite unlikely.
Did I mention it's JIT compiled?
As for scripts returning the value of the last-called script... Heh, that's kind of neat, I was unaware it did that; that's usually a behavior defined in interpreted language. I can't replicate that, as far as I know, simply by not providing a return value in lieu of the user's... I could if the last reference were left in EAX, which is unlikely.
I don't think I'll be replicating any useless GM bugs.
2285
Announcements / Re: Another choice.
« on: March 15, 2010, 08:59:34 pm »
Didn't want to bring up that difference in example code of another difference.
2286
Announcements / Re: Quick Poll
« on: March 14, 2010, 03:39:08 pm »
Like I said, C++ people make this particular mistake a lot. It happens, and it could likely piss people off.
2287
Announcements / Re: Another choice.
« on: March 14, 2010, 12:44:11 pm »
Game_boy: Should make that a priority, actually.
All of those will. Even global var, which will be done like so:
#define globalvar global var
...heh.
All of those will. Even global var, which will be done like so:
#define globalvar global var
...heh.
2288
Announcements / Re: Another choice.
« on: March 14, 2010, 11:23:23 am »
My thoughts ^
Breaks this v
And by "breaks," I mean "fixes in a way that may piss off a very small percentage of GM users."
Breaks this v
Code: [Select]
if (true)
{
var a;
a = 3.14;
}
show_message(string(a));
And by "breaks," I mean "fixes in a way that may piss off a very small percentage of GM users."
2289
Announcements / Re: Another choice.
« on: March 14, 2010, 11:15:05 am »
For the first pair, 1 and 2 were both defining var's behavior.
The second and third, we can't make that assumption...
The third option specifically seems contradictory to the philosophy of a keyword. Defining where the var is coming from should be retro-active. You mentioned function declarations in Python; same principle. Most people put their vars at the top. Most Python people put their imports at the top.
I believe the manual uses the word "declare" for "var," which is basically all the proof I need that Mark intended it to be like a real language... Think JavaScript scoping, again. I'll look for the page in question.
Essentially,
The second and third, we can't make that assumption...
The third option specifically seems contradictory to the philosophy of a keyword. Defining where the var is coming from should be retro-active. You mentioned function declarations in Python; same principle. Most people put their vars at the top. Most Python people put their imports at the top.
I believe the manual uses the word "declare" for "var," which is basically all the proof I need that Mark intended it to be like a real language... Think JavaScript scoping, again. I'll look for the page in question.
Essentially,
Quote
Josh @ Dreamland:
he whole dilemma here is that we don't know what Mark was thinking because he implemented it badly
retep998:
WHO CARES WHAT HE WAS THINKING?
retep998:
I LIKE IT THAT WAY
retep998:
AND IT WORKS
Josh @ Dreamland:
well, if we're going to turn this into a huge genetic fallacy we may as well have our facts straight
Josh @ Dreamland:
haha.
2290
Announcements / Re: Another choice.
« on: March 14, 2010, 11:05:04 am »
Game_boy:
It would really blow your mind at this point if I described the difference between objects in GM and objects in C++, but basically the difference is that in C++, it's legal to say "object0 a;" instead of instance_create(object0). The implications of doing this would be difficult to explain here, so for now, disregard that.
I guess I'll start by elaborating on terms.
Type:
Most decent languages have some sort of data type. All languages work with data types internally. Even the really ugly one my favorite critics were just about to cite. These tell the compiler and, ultimately, the computer, what the program will be doing with a certain block of memory. Types can have different sizes and different precision, and allow different features. For example, those coming from Game Maker unknowingly work with two types: "double" (called "real") and "string" (called the same). Both of these are represented by the type "var."
Class:
In Object-Oriented Programming, a class is a method of communicating to the compiler how a chunk of memory is laid out. "Structure," or "struct," is synonymous with "class" for our purposes. They can be used to lump a bunch of variables in one place, and are great for working with arrays of multiple values without going multidimensional. For example, you could store a direction and a magnitude to represent a vector in memory. In C++, that would look like this:
You could then declare and manipulate an array of them like this:
Keyword:
We'll define keyword for now as words like "if" and "while," and in option 1 of this poll, "local." These keywords don't represent anything: think about it. They are used entirely to tell the compiler how to treat code (note that a type name tells the *computer* as well as the compiler how to treat something physical, namely memory). "If" tells the compiler to make the computer execute the next command conditionally. "While" tells it to keep executing it conditionally. "Local" tells ENIGMA, in one word, "don't declare this HERE; move it to the struct declaration."
By those definitions, "local" as denoted by option 1 would be a keyword, as described in that section above. "Var," however, remains ambiguous: it could do one of two things:
1) Tell Game Maker that this variable should be treated local to the script, as a keyword (Wow! that's what var does!)
2) Tell Game Maker that the following name should be declared in this scope as a block of memory to be treated as either a string or real (Wow! that's what var does too!)
So when we start adding more types, it's a matter of which is more convenient to assume.
Prototype Releases 1-3 all have var declared as a class. This makes it integrate flawlessly with C++; the behavior is very, very similar to GM. But it's not identical:
For years, the community has complained (or at least, the ones that are more aware of other languages) that Game Maker handles scopes badly. These are the people that would choose Option 1 in a pinch. However, there *are* differences in behavior, as outlined here:
The above code would do two different things in ENIGMA and GM6. I have no information on GM7 and 8.
In ENIGMA, it would print 0.
In Game Maker 6, it would print 3.14.
The reason for this is ambiguous.
1) Mark didn't think it through well enough and did a bad job implementing scopes. (This would not be a first, sorry folks).
2) Mark intended for "var" only to signify that the variable was local to the code.
Option two looks *really* attractive to the common onlooker now (A certain someone was about to start typing a heated response).
However, here's behavioral evidence for option 1 (assume that "a" is declared in the create event as "a = 0" and that this code is run for one step prior):
This will print 3.14 again, meaning that Mark's parser is only aware of the point in time that the variable was declared. So, what was it?
1) Did he forgot/feel too lazy to go back over the code making "a" local throughout?
2) Did he intend for the keyword to not be retroactive? That makes it behave more like a declaration than a keyword...
3) Did he, again, really mean for it to be used as a declarator (type name) but fail to implement scopes?
Hope this helps.
It would really blow your mind at this point if I described the difference between objects in GM and objects in C++, but basically the difference is that in C++, it's legal to say "object0 a;" instead of instance_create(object0). The implications of doing this would be difficult to explain here, so for now, disregard that.
I guess I'll start by elaborating on terms.
Type:
Most decent languages have some sort of data type. All languages work with data types internally. Even the really ugly one my favorite critics were just about to cite. These tell the compiler and, ultimately, the computer, what the program will be doing with a certain block of memory. Types can have different sizes and different precision, and allow different features. For example, those coming from Game Maker unknowingly work with two types: "double" (called "real") and "string" (called the same). Both of these are represented by the type "var."
Class:
In Object-Oriented Programming, a class is a method of communicating to the compiler how a chunk of memory is laid out. "Structure," or "struct," is synonymous with "class" for our purposes. They can be used to lump a bunch of variables in one place, and are great for working with arrays of multiple values without going multidimensional. For example, you could store a direction and a magnitude to represent a vector in memory. In C++, that would look like this:
Code: [Select]
struct vector
{
double direction;
double magnitude;
}
You could then declare and manipulate an array of them like this:
Code: [Select]
vector a[100];
a[0].magnitude = 0;
a[0].direction = 0;
Pretty convenient, huh?Keyword:
We'll define keyword for now as words like "if" and "while," and in option 1 of this poll, "local." These keywords don't represent anything: think about it. They are used entirely to tell the compiler how to treat code (note that a type name tells the *computer* as well as the compiler how to treat something physical, namely memory). "If" tells the compiler to make the computer execute the next command conditionally. "While" tells it to keep executing it conditionally. "Local" tells ENIGMA, in one word, "don't declare this HERE; move it to the struct declaration."
By those definitions, "local" as denoted by option 1 would be a keyword, as described in that section above. "Var," however, remains ambiguous: it could do one of two things:
1) Tell Game Maker that this variable should be treated local to the script, as a keyword (Wow! that's what var does!)
2) Tell Game Maker that the following name should be declared in this scope as a block of memory to be treated as either a string or real (Wow! that's what var does too!)
So when we start adding more types, it's a matter of which is more convenient to assume.
Prototype Releases 1-3 all have var declared as a class. This makes it integrate flawlessly with C++; the behavior is very, very similar to GM. But it's not identical:
For years, the community has complained (or at least, the ones that are more aware of other languages) that Game Maker handles scopes badly. These are the people that would choose Option 1 in a pinch. However, there *are* differences in behavior, as outlined here:
Code: [Select]
if (true)
{
var a;
a = 3.14;
}
show_message(string(a));
The above code would do two different things in ENIGMA and GM6. I have no information on GM7 and 8.
In ENIGMA, it would print 0.
In Game Maker 6, it would print 3.14.
The reason for this is ambiguous.
1) Mark didn't think it through well enough and did a bad job implementing scopes. (This would not be a first, sorry folks).
2) Mark intended for "var" only to signify that the variable was local to the code.
Option two looks *really* attractive to the common onlooker now (A certain someone was about to start typing a heated response).
However, here's behavioral evidence for option 1 (assume that "a" is declared in the create event as "a = 0" and that this code is run for one step prior):
Code: [Select]
show_message(string(a));
a = 3.14;
var a;
a = 2;
This will print 3.14 again, meaning that Mark's parser is only aware of the point in time that the variable was declared. So, what was it?
1) Did he forgot/feel too lazy to go back over the code making "a" local throughout?
2) Did he intend for the keyword to not be retroactive? That makes it behave more like a declaration than a keyword...
3) Did he, again, really mean for it to be used as a declarator (type name) but fail to implement scopes?
Hope this helps.
2291
Announcements / Re: Another choice.
« on: March 13, 2010, 07:07:32 pm »
The changes that I've made polls for so far (or may yet make polls for) don't affect GM interoperability. However, I intend for ENIGMA-GM communication to be one-way. I'm kind of glad that most users are going with my take on this issue, because part of the philosophy behind these changes is for ENIGMA to be able to see off its users with a smile instead of a sore ass.
Game_boy admits to not thinking of "var" being a type; he never expected to see anything other than var in GM, I guess. I was always on the lookout for something other than "var," I didn't think a keyword very useful that just says something is local. And when I heard the word "declaration" attached to it, and started catching wind of more powerful languages than GM, I just kind of assumed (correctly) that they would parallel this structure with less ambiguous types.
Game_boy: when you think about "var" as a class rather than simply a keyword, does it seem more logical? Or less?
Right now, GM is breeding a wave of people who don't understand that == is an operator. I can't allow ENIGMA to be like that. This is what will happen as a result:
The ENIGMA default configuration when creating a new file is currently as follows:
When importing a GM file, a separate set of default settings will be used, currently differing by one setting:
The settings for either can be modified at any time, and will be saved with the EGM file.
Now, with that in mind, what I meant by "see[ing] off its users with a smile" is this: As users become used to ENIGMA, they'll start looking through its new features. The most obvious features will likely be the first they use, take the for loop example from before. What they once knew in GML will be made easier (and much, much faster) in EDL:
Now users can legitimately declare their variables inside a for loop (with better scoping) and can take advantage of a type literally hundreds of times faster than what they are used to.
This will be revolutionary for all of ten uses, and they'll be accustomed to it like everyone else. It'll once more be no big deal.
Then they'll find other nice things:
Or object-local:
And then, as they get used to that:
Slowly, their default options list will get closer to mine:
At that point, ENIGMA will, like GM, cease being a challenge. Maybe cease to offer what they feel they need. Also like in GM, maybe they'll start developing for the project; DLLs or, since this is compiled, just a new library. And if ENIGMA still isn't enough for them anymore, they can move on, knowing a decent amount of a pretty good language.
Game_boy admits to not thinking of "var" being a type; he never expected to see anything other than var in GM, I guess. I was always on the lookout for something other than "var," I didn't think a keyword very useful that just says something is local. And when I heard the word "declaration" attached to it, and started catching wind of more powerful languages than GM, I just kind of assumed (correctly) that they would parallel this structure with less ambiguous types.
Game_boy: when you think about "var" as a class rather than simply a keyword, does it seem more logical? Or less?
Right now, GM is breeding a wave of people who don't understand that == is an operator. I can't allow ENIGMA to be like that. This is what will happen as a result:
The ENIGMA default configuration when creating a new file is currently as follows:
Strings: | GM Style ("\") |
Comparison: | = or == |
Operator ++: | Enabled |
struct {}: | Treat } as }; |
When importing a GM file, a separate set of default settings will be used, currently differing by one setting:
Strings: | GM Style ("\") |
Comparison: | = or == |
Operator ++: | Disabled |
struct {}: | Treat } as }; (inapplicable) |
The settings for either can be modified at any time, and will be saved with the EGM file.
Now, with that in mind, what I meant by "see[ing] off its users with a smile" is this: As users become used to ENIGMA, they'll start looking through its new features. The most obvious features will likely be the first they use, take the for loop example from before. What they once knew in GML will be made easier (and much, much faster) in EDL:
Code: [Select]
/* Old: */
var i;
for (i=0; i<10; i+=1)
draw_circle(x-16+random(32),y-16+random(32),random(5)+5,1);
/* New: */
for (int i=0; i<10; i+=1)
draw_circle(x-16+random(32),y-16+random(32),random(5)+5,1);
Now users can legitimately declare their variables inside a for loop (with better scoping) and can take advantage of a type literally hundreds of times faster than what they are used to.
This will be revolutionary for all of ten uses, and they'll be accustomed to it like everyone else. It'll once more be no big deal.
Then they'll find other nice things:
Code: [Select]
/* Before: */
var a;
a = ds_list_create();
/* After: */
list a;
Or object-local:
Code: [Select]
/* Before: */
a = ds_list_create();
/* After: */
local list a;
And then, as they get used to that:
Code: [Select]
local list<int> a;
Slowly, their default options list will get closer to mine:
Strings: | C++ Style ("\\") |
Comparison: | == |
Operator ++: | Enabled |
struct {}: | ISO |
At that point, ENIGMA will, like GM, cease being a challenge. Maybe cease to offer what they feel they need. Also like in GM, maybe they'll start developing for the project; DLLs or, since this is compiled, just a new library. And if ENIGMA still isn't enough for them anymore, they can move on, knowing a decent amount of a pretty good language.
2292
Announcements / Re: Another choice.
« on: March 13, 2010, 04:35:54 pm »
"In GM, the scope of a variable is decided by the keyword... In C++, the scope of a variable is decided by where it is declared"
Are you suggesting that in GM, where it is declared has nothing to do with it? Certainly you aren't, since you said "`var` means script-/event-local scope" and didn't seem to think that was decided at random...
Let's look at JavaScript.
function script0()
{
var a; // "a" is local to script0()
b = 0; // b is local to the current context, such as a web page
}
This is probably a better example of var scoping, with var working just like a class in C++, and behavior of undeclared variables mirroring that of GM. JavaScript, of course, is classless, so you won't see that done with any type other than var. Does that make var JS and GML's only type, or just another keyword? The behavior is the same; that makes it a matter of opinion.
Game_boy:
I understand. In fact, that's a really good point. Give it a vote.
Are you suggesting that in GM, where it is declared has nothing to do with it? Certainly you aren't, since you said "`var` means script-/event-local scope" and didn't seem to think that was decided at random...
Let's look at JavaScript.
function script0()
{
var a; // "a" is local to script0()
b = 0; // b is local to the current context, such as a web page
}
This is probably a better example of var scoping, with var working just like a class in C++, and behavior of undeclared variables mirroring that of GM. JavaScript, of course, is classless, so you won't see that done with any type other than var. Does that make var JS and GML's only type, or just another keyword? The behavior is the same; that makes it a matter of opinion.
Game_boy:
I understand. In fact, that's a really good point. Give it a vote.
2293
Announcements / Re: Another choice.
« on: March 13, 2010, 10:09:12 am »
Game_boy--
I wasn't sure what people expected. When I say "int x;" in any language of that syntax, I expect "x" to last only as long as the script does. I was hoping to glean an accurate representation of the GM mindset; I just assumed that like "var a;", users would expect "int a;" to make a script-local, and would never even consider modifying object-locals like "x" and "y". But then again, I can see it becoming confusing when they want to identify that a regular local they are using as that particular type.
The thing is, when they discover that ENIGMA has types, will they treat them exactly like var, or will they assume they can just la-dee-dah define object-locals with it?
How many will actually go to the manual to see how they work? Assuming I ever even write a manual. I'm lazy with easy tasks that take time. If they all went to the manual, I think "local int" would be perfect for object-locals. Since that probably won't happen, I need to know the mindset and minimize damage when they misuse it.
I wasn't sure what people expected. When I say "int x;" in any language of that syntax, I expect "x" to last only as long as the script does. I was hoping to glean an accurate representation of the GM mindset; I just assumed that like "var a;", users would expect "int a;" to make a script-local, and would never even consider modifying object-locals like "x" and "y". But then again, I can see it becoming confusing when they want to identify that a regular local they are using as that particular type.
The thing is, when they discover that ENIGMA has types, will they treat them exactly like var, or will they assume they can just la-dee-dah define object-locals with it?
How many will actually go to the manual to see how they work? Assuming I ever even write a manual. I'm lazy with easy tasks that take time. If they all went to the manual, I think "local int" would be perfect for object-locals. Since that probably won't happen, I need to know the mindset and minimize damage when they misuse it.
2294
Announcements / Re: Another choice.
« on: March 13, 2010, 12:25:48 am »Quote
a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.I meant object-local that time, yes. Fix'd:
a = 0; //"a" is assumed to be an OBJECT-local variable, accessible from all events, and will be given type "var" if no one else says anything.
And yes, I suppose, but two overlap.
1) Not declaring variable: Both GM and ENIGMA assume object-local var
2) var a: Both assume script-local var
int a: ENIGMA assumes script-local int
3) local int a: ENIGMA creates object-local int
2295
Announcements / Re: Another choice.
« on: March 12, 2010, 09:46:43 pm »
Grundoko:
No, "local" tells the compiler that the following declaration belongs to the current instance rather than the current script.
In GM, "var" declares variables in the current script, and these variables are freed after the script is called. There is no way to declare an instance-local variable (such as x or y) in GM, because there is no need to; GM's only type is var. In ENIGMA, however, we have more than one type. So.
In GM, you'd say
However, as I said, GM doesn't offer a way to declare object-local variables like x and y, because its only type is var. To bring other types into the mix, R3 used a keyword "localv."
Saying "localv int a;" made sure that "a" was the same variable in all codes called from that object, and ensured that it was an int.
Now, I can leave it like it is, or I can change "localv" to "local," or I can remove "local" entirely and use "var int" when declaring SCRIPT-local variables, making our for loop from before look like this:
SO. If we use "local" this way, here's the layout:
local int a; //Declares variable "a" as an integer. "a" behaves like variables such as "x" and "y".
int a; //Declares variable "a" in the current script. It cannot be used in other events or codes, like "var a" in GML.
a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.
No, "local" tells the compiler that the following declaration belongs to the current instance rather than the current script.
In GM, "var" declares variables in the current script, and these variables are freed after the script is called. There is no way to declare an instance-local variable (such as x or y) in GM, because there is no need to; GM's only type is var. In ENIGMA, however, we have more than one type. So.
In GM, you'd say
Code: [Select]
var i;
for (i = 0; i < 10; i += 1)
...
in ENIGMA, you'd say Code: [Select]
for (var i = 0; i < 10; i += 1)
...
OR you can say Code: [Select]
for (int i = 0; i < 10; i += 1)
...
That's an easy way to speed up your code, since int is more than 10x faster than var in ENIGMA alone (there's really no point comparing it to GM's var's speed).However, as I said, GM doesn't offer a way to declare object-local variables like x and y, because its only type is var. To bring other types into the mix, R3 used a keyword "localv."
Saying "localv int a;" made sure that "a" was the same variable in all codes called from that object, and ensured that it was an int.
Now, I can leave it like it is, or I can change "localv" to "local," or I can remove "local" entirely and use "var int" when declaring SCRIPT-local variables, making our for loop from before look like this:
Code: [Select]
for (var int i = 0; i < 10; i += 1)
...
SO. If we use "local" this way, here's the layout:
local int a; //Declares variable "a" as an integer. "a" behaves like variables such as "x" and "y".
int a; //Declares variable "a" in the current script. It cannot be used in other events or codes, like "var a" in GML.
a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.
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 »