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 »
2611
General ENIGMA / Re: XOR DOES NOT WORK
« on: August 05, 2009, 11:05:57 am »
Retro: Doubles are always 64 bits anyway. Long doubles are not though, so don't be fooled. I've seen long doubles of size 8, 12, 16... ung.
Serpy: Lambda kills kittens. I saw it. Don't use it.
Oh, and as serpy says, there are 10 byte doubles. But I've never actually seen one. score_under was telling me about an instruction for dealing with those a couple days ago, so I imagine they're somewhere. But since long double is 12 bytes anyway, there's really no need to be troubled with details of a 10 byte one.
Serpy: Lambda kills kittens. I saw it. Don't use it.
Oh, and as serpy says, there are 10 byte doubles. But I've never actually seen one. score_under was telling me about an instruction for dealing with those a couple days ago, so I imagine they're somewhere. But since long double is 12 bytes anyway, there's really no need to be troubled with details of a 10 byte one.
2612
General ENIGMA / Re: Alternate to cpp {}
« on: August 05, 2009, 11:03:26 am »
As of R4, C++ is totally usable anyway. Meaning ++ and cout will both be available to you.
I may leave cpp {} in for people who understand parsed-EDL syntax, and are faced with a compile error that is not yet fixed.
I may leave cpp {} in for people who understand parsed-EDL syntax, and are faced with a compile error that is not yet fixed.
2613
General ENIGMA / Re: Writting Enigma's IDE in C#
« on: August 05, 2009, 10:58:18 am »
If it's on page one, I think bumping it's fair game.
Bumping newsposts is >_<" though.
Bumping newsposts is >_<" though.
2614
Announcements / Re: Subject
« on: August 04, 2009, 11:51:18 pm »
And the Commodore 64, sure. I just have to write up a couple window functions for t-- oh, that's right.
But seriously, all the major OSes either are Microsoft, or they support XLib. So that's BASICALLY everything with a monitor. And since GL guarantees two colors, and XLib doesn't guarantee shit, we're good.
Progress:
(ddd)a is ccccca instead, so )a isn't misread and replaced with );a
Still working toward finishing parsers. Tomorrow I must experiment with syntax checker, making sure it's finished and incorporating inline structures/classes. (And inline asm if syntax check doesn't have that in yet).
But seriously, all the major OSes either are Microsoft, or they support XLib. So that's BASICALLY everything with a monitor. And since GL guarantees two colors, and XLib doesn't guarantee shit, we're good.
Progress:
(ddd)a is ccccca instead, so )a isn't misread and replaced with );a
Still working toward finishing parsers. Tomorrow I must experiment with syntax checker, making sure it's finished and incorporating inline structures/classes. (And inline asm if syntax check doesn't have that in yet).
2615
Announcements / Re: Subject
« on: August 01, 2009, 09:25:45 pm »
whaddsoft--
If you mean that I should use something cross platform, there's nothing *that* cross platform for me to use. I'm writing it in as low a level interfaces as I can manage. From what I'm seeing, it should work on everything with a monitor.
...Okay, not really. But from what I can tell, pretty much everything in the realm of computers that doesn't support Win32Api supports XLib. And everything else... Well, I'll get to it.
Anyway, as for progress:
Becomes these so far:
Although I was originally considering total removal of spaces, it's proven to work efficiently without doing so thus far. I think I may yet do so for later efficiency/ease, however.
As for explanation of methodology here...
This is a more insightful revamping of my original parser; the one written in GML. However, this one is more capable of handling all the C++ tokens, too. The old one was modified to do so; this one is being designed for it.
I'm still using the original flow of things, though, so I think I can get away with saying it was still originally GML. The idea was good enough that it operated fine for its time... now it just needs some polishing up.
Anyway, how it works is relatively easy when you break it down. The code is first stripped of all comments, strings, and whitespace for workability. Comments/Other whitespace become a single space. Strings of any type are replaced with the quote character ("). Variable names become "n". They are then broken down into specific treatments based on if they represent a statement...
Statements requiring () are replaced with "s". These include if(), with(), switch()...
Statements requiring a parameter without needing or plain without () become "p". Take return x; and goto lbl; for example.
Statements requiring an immediate semicolon are parsed as "b". This is raising some questions as to what to do with "do" and "else".
Those two exceptions ("do" and "else") cannot be treated the same.
The first code is valid if "do do" is left alone. The second is only valid if it becomes "else; else". The semicolon there means "do nothing". I'm considering just adding a token for each of them. (Probably "c" for do and "e" for else).
These will mean a couple extra rules added in two simple functions.
The code will seem so simple when it's all laid out. But for now, it's scraping brain matter.
If you mean that I should use something cross platform, there's nothing *that* cross platform for me to use. I'm writing it in as low a level interfaces as I can manage. From what I'm seeing, it should work on everything with a monitor.
...Okay, not really. But from what I can tell, pretty much everything in the realm of computers that doesn't support Win32Api supports XLib. And everything else... Well, I'll get to it.
Anyway, as for progress:
Code: [Select]
int a = 0; if a = 1 b=2c=3 else d=4 e=5 f='test removal of strings'g=\"poop\" \
endorphin = /*removal of comments*/ 6; motherlicker = 7; //or eight\r\n end\
break; label: goto label; awful_code() return 0 /*
Becomes these so far:
Code: [Select]
ddd n = 0; ss(n = 0);n=0;n=0;bbbb;n=0;n=0;n=";n=";nnnnnnnnn = 0; nnnnnnnnnnnn = 0; nnn;bbbbb; nnnnn: pppp nnnnn; nnnnnnnnnn();pppppp 0;
Code: [Select]
int a = 0; if(a = 1);b=2;c=3;else;d=4;e=5;f=";g=";endorphin = 6; motherlicker = 7; end;break; label: goto label; awful_code();return 0;
Although I was originally considering total removal of spaces, it's proven to work efficiently without doing so thus far. I think I may yet do so for later efficiency/ease, however.
As for explanation of methodology here...
This is a more insightful revamping of my original parser; the one written in GML. However, this one is more capable of handling all the C++ tokens, too. The old one was modified to do so; this one is being designed for it.
I'm still using the original flow of things, though, so I think I can get away with saying it was still originally GML. The idea was good enough that it operated fine for its time... now it just needs some polishing up.
Anyway, how it works is relatively easy when you break it down. The code is first stripped of all comments, strings, and whitespace for workability. Comments/Other whitespace become a single space. Strings of any type are replaced with the quote character ("). Variable names become "n". They are then broken down into specific treatments based on if they represent a statement...
Statements requiring () are replaced with "s". These include if(), with(), switch()...
Statements requiring a parameter without needing or plain without () become "p". Take return x; and goto lbl; for example.
Statements requiring an immediate semicolon are parsed as "b". This is raising some questions as to what to do with "do" and "else".
Those two exceptions ("do" and "else") cannot be treated the same.
Code: [Select]
do do a=b() until c=d until e=f
Code: [Select]
if a if b c() else else d()
The first code is valid if "do do" is left alone. The second is only valid if it becomes "else; else". The semicolon there means "do nothing". I'm considering just adding a token for each of them. (Probably "c" for do and "e" for else).
These will mean a couple extra rules added in two simple functions.
The code will seem so simple when it's all laid out. But for now, it's scraping brain matter.
2617
Announcements / Re: Subject
« on: July 30, 2009, 11:07:13 am »
And var xy; xy.a=0; will error "Undefined variable xy", even though you declared it. var x; errors that you can't redefine a builtin variable. Which is dumb. I may have to make EINGMA error if you say local int x; though.
2618
No, you see, Windows and Linux have trouble communicating sometimes. I wanted to rename the folder because my host thought one of the files was malicious. Trying to rename that directory, though, ended up in what seemed be files that were linked to multiple times. It left a copy of the original folders with nothing inside. Deleting those caused fail.
2619
General ENIGMA / Re: What limitations does Enigma have?
« on: July 30, 2009, 08:35:36 am »
I meant in execute_string. Pointers have been allowed in full force since R3.
Also, you try that, and I'll take out my knife and shoot you.
Also, you try that, and I'll take out my knife and shoot you.
2620
General ENIGMA / Re: XOR DOES NOT WORK
« on: July 29, 2009, 01:08:21 am »
What serp said. Probably a good idea.
2621
General ENIGMA / Re: What limitations does Enigma have?
« on: July 29, 2009, 12:27:19 am »
a2h--
Realize the simplicity.
Variables users add can be stored in a separate hash map. Think: if the variable, asdfWHATEVERghjkl, isn't referenced in the compiled code, there is no need to keep the compiled vars extensible; only to make sure that they can be accessed from within the string to execute.
Hash maps are a safe way to do that, too. I probably won't allow access to non-primitives in execute_string. Meaning the best you can do is int, double, char, and so on. Structs and pointers would therefore be disallowed, with exception, I imagine, of string. (And of course var)
At the moment I'm ready to go to bed, and am too tired to give it much thought. But thinking about how var and string would be allowed, I could *probably* add support for any predeclared structures; the ones I know at compile time. Dynamic structures, ones defined in execute_string, are probably out of the question, unless they are scopeless... Overall seems like too much work to bother with. Too much room to do something inefficiently.
But as for your basic GM execute_string, it doesn't seem all that hard, really.
Realize the simplicity.
Variables users add can be stored in a separate hash map. Think: if the variable, asdfWHATEVERghjkl, isn't referenced in the compiled code, there is no need to keep the compiled vars extensible; only to make sure that they can be accessed from within the string to execute.
Hash maps are a safe way to do that, too. I probably won't allow access to non-primitives in execute_string. Meaning the best you can do is int, double, char, and so on. Structs and pointers would therefore be disallowed, with exception, I imagine, of string. (And of course var)
At the moment I'm ready to go to bed, and am too tired to give it much thought. But thinking about how var and string would be allowed, I could *probably* add support for any predeclared structures; the ones I know at compile time. Dynamic structures, ones defined in execute_string, are probably out of the question, unless they are scopeless... Overall seems like too much work to bother with. Too much room to do something inefficiently.
But as for your basic GM execute_string, it doesn't seem all that hard, really.
2622
Announcements / Re: Subject
« on: July 29, 2009, 12:11:39 am »
It's worse than int x; x.whatever;
In that code, you at least have four bytes to work with. This offers nothing; the structure has no member by that name, and it certainly can't be treated as an integer, so ENIGMA really has nothing to do with that but error.
In that code, you at least have four bytes to work with. This offers nothing; the structure has no member by that name, and it certainly can't be treated as an integer, so ENIGMA really has nothing to do with that but error.
2623
General ENIGMA / Re: What limitations does Enigma have?
« on: July 27, 2009, 10:06:53 am »
Only one millennium.
But yeah. Executing a string will hopefully be possible, too. Really wanna see such a thing put to use in debug mode. But er, execute_string prolly will bite you if you declare something as int.
ENIGMA, being C++, technically has an infinite extensibility; anything C++ can do, it can do. This doesn't mean that I'll offer a help file over everything that C++ offers, as that would be impossible, due to the fact that it's so big. It also doesn't mean that it will always be as easy as a function with a 30-character name that you can guess at.
C++ is a huge language. Putting that at the fingertips of the user removes any limits, so long as you're willing to learn and willing to put some real work into it.
But yeah. Executing a string will hopefully be possible, too. Really wanna see such a thing put to use in debug mode. But er, execute_string prolly will bite you if you declare something as int.
ENIGMA, being C++, technically has an infinite extensibility; anything C++ can do, it can do. This doesn't mean that I'll offer a help file over everything that C++ offers, as that would be impossible, due to the fact that it's so big. It also doesn't mean that it will always be as easy as a function with a 30-character name that you can guess at.
C++ is a huge language. Putting that at the fingertips of the user removes any limits, so long as you're willing to learn and willing to put some real work into it.
2624
Announcements / Re: Subject
« on: July 26, 2009, 10:51:54 pm »
Today's progress:
Got the syntax map working with basic tokens, and the rest of it is still being planned out.
The simplistic find-and-replace style of the original parser will no longer cut it, due to this trinket:
Depending on the practicality of your thoughts and your knowledge of C++, you're either saying "oh boy, can't wait", "who cares", or "he'll never pull it off".
Maybe one of you is thinking "good luck," but somehow I don't think so. sadface
That assessment will be based on whether the class you named has a method of casting as int, and whether or not it contains a member by that name. This was a real no-brainer scenario. Not sure what to do if someone says
Will probably try to throw a syntax error.
Got the syntax map working with basic tokens, and the rest of it is still being planned out.
The simplistic find-and-replace style of the original parser will no longer cut it, due to this trinket:
Code: [Select]
struct type
{
int value;
type& operator int() { return value; }
}
type a;
a.value = instace_nearest(x,y,object0); //This sets the 'value' member of 'a'
a.b = c; //This pretends 'a' is an integer, treats it like an id, and thus sets object0.b to the id of whatever the nearest object0 was
Depending on the practicality of your thoughts and your knowledge of C++, you're either saying "oh boy, can't wait", "who cares", or "he'll never pull it off".
Maybe one of you is thinking "good luck," but somehow I don't think so. sadface
That assessment will be based on whether the class you named has a method of casting as int, and whether or not it contains a member by that name. This was a real no-brainer scenario. Not sure what to do if someone says
Code: [Select]
struct a {} b;
b.a=0;
Will probably try to throw a syntax error.
2625
General ENIGMA / Re: Game Maker 8
« on: July 26, 2009, 10:43:33 pm »
Results from incompetence. Maybe they're expanding things as much as I am, and GM9 will support C++ too.
...GAHAHAHAHA
score_under--
We of the ENIGMA team do not support such piracy, yadda yadda, etc, etc. The ENIGMA team, in fact, discourages piracy, and posting pirated software here is prohibited... I'm having a hard time sounding all official on that due to the fact that I honestly don't care. But yknow, don't do that here.
...GAHAHAHAHA
score_under--
We of the ENIGMA team do not support such piracy, yadda yadda, etc, etc. The ENIGMA team, in fact, discourages piracy, and posting pirated software here is prohibited... I'm having a hard time sounding all official on that due to the fact that I honestly don't care. But yknow, don't do that here.
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 »