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 »
2116
General ENIGMA / Re: ENIGMA on iPhone - Now legally impossible
« on: April 11, 2010, 03:13:34 pm »
int main() is an intermediate layer.
No? Well, then int game_step() is.
Therefore, all games containing more than one source file or function calling from the Apple iPhone API are hereby outlawed.
I'll bet any sum of money that the vast majority of iPhone games keep calls to make the main game screen, &c., in a separate, easy-to-call function. They can't outlaw ENIGMA without outlawing those.
Also, this message was posted from the Eclipse IDE. If that makes sense, *mumble mumble*.
No? Well, then int game_step() is.
Therefore, all games containing more than one source file or function calling from the Apple iPhone API are hereby outlawed.
I'll bet any sum of money that the vast majority of iPhone games keep calls to make the main game screen, &c., in a separate, easy-to-call function. They can't outlaw ENIGMA without outlawing those.
Also, this message was posted from the Eclipse IDE. If that makes sense, *mumble mumble*.
2117
Announcements / Re: Anaphase
« on: April 11, 2010, 11:21:57 am »
Fixed, and then some. Going to do some homework while I ponder my next move.
2118
Announcements / Re: Anaphase
« on: April 11, 2010, 10:42:53 am »
For some reason, instance_destroy does nothing at all. Fixing...
2120
General ENIGMA / Re: ENIGMA on iPhone - Now legally impossible
« on: April 11, 2010, 09:52:27 am »
On a separate note,
"But you need to put it on the App Store or no one will be able to use it without jailbreaking. And then they'll notice and remove it."
How will they notice it? ENIGMA doesn't contain a DLL labeled make_enigma_games_work_for_iphone_lulz.dll. An ENIGMA game is indistinguishable from a standardly compiled C++ game: It IS a standardly compiled C++ game.
"But you need to put it on the App Store or no one will be able to use it without jailbreaking. And then they'll notice and remove it."
How will they notice it? ENIGMA doesn't contain a DLL labeled make_enigma_games_work_for_iphone_lulz.dll. An ENIGMA game is indistinguishable from a standardly compiled C++ game: It IS a standardly compiled C++ game.
2121
General ENIGMA / Re: ENIGMA on iPhone - Now legally impossible
« on: April 11, 2010, 09:50:05 am »
Their clause on originality is easily worked around; regardless of who (or, in this case, what) wrote the code, it is written in C++ by compile time.
Also, look at Unity. They use JavaScript. How does this fare with that license?
Furthermore, the "compatibility layer" can't really apply to ENIGMA; ENIGMA's API is entirely platform-specific code. Using ENIGMA's API is no different than making your own calls in a separate function, or using someone else's in library form.
This license has essentially no bearing on the project; if anything should make them kiss their hopes good bye, it's me neither owning nor intending to own an iPhone. The closest lexical match between their newly founded restrictions and the concept of ENIGMA is that ENIGMA would enable you to compile your code on multiple platforms without changing any of your own code. This isn't done dynamically, though, from a separate API such as SDL; it's a (usually) custom-coded (at compile time, by ENIGMA) part of your game.
It's worth mentioning that the only true function of the parser is to add semicolons and declare variables. That's hardly a cause for license violations; the newest was targeted primarily at Flash compilers. They don't want Flash games being compiled and sold.
So basically, to accuse ENIGMA of being illegal on the iPhone would say that Unity (for one) and most libraries/user-defined functions are also illegal. The trick is that the parser does a lot of coding for the user, ultimately producing an "original" C++ source code.
Argument, as synopsis:
i. ENIGMA lacks a compatibility layer; it's just a library-esque implementation of GML-like functions, making it no different from an entirely user-coded library. Since the API they will be using is a static set of simple functions designed solely and entirely for the iPhone, it is not a compatibility layer.
ii. ENIGMA games' source is originally C++. Since ENIGMA is not a compiler, but a parser, the original code they will be compiling is still C++.
iii. ENIGMA does not "link to Documented APIs" at all. GCC does the linking for ENIGMA; GCC is an authorized tool.
iv. To outlaw ENIGMA is to outlaw anyone else doing any coding for you, as well as to outlaw the creation of functions for the sole purpose of calling one or more Apple Documented API functions.
Also, look at Unity. They use JavaScript. How does this fare with that license?
Furthermore, the "compatibility layer" can't really apply to ENIGMA; ENIGMA's API is entirely platform-specific code. Using ENIGMA's API is no different than making your own calls in a separate function, or using someone else's in library form.
This license has essentially no bearing on the project; if anything should make them kiss their hopes good bye, it's me neither owning nor intending to own an iPhone. The closest lexical match between their newly founded restrictions and the concept of ENIGMA is that ENIGMA would enable you to compile your code on multiple platforms without changing any of your own code. This isn't done dynamically, though, from a separate API such as SDL; it's a (usually) custom-coded (at compile time, by ENIGMA) part of your game.
It's worth mentioning that the only true function of the parser is to add semicolons and declare variables. That's hardly a cause for license violations; the newest was targeted primarily at Flash compilers. They don't want Flash games being compiled and sold.
So basically, to accuse ENIGMA of being illegal on the iPhone would say that Unity (for one) and most libraries/user-defined functions are also illegal. The trick is that the parser does a lot of coding for the user, ultimately producing an "original" C++ source code.
Argument, as synopsis:
i. ENIGMA lacks a compatibility layer; it's just a library-esque implementation of GML-like functions, making it no different from an entirely user-coded library. Since the API they will be using is a static set of simple functions designed solely and entirely for the iPhone, it is not a compatibility layer.
ii. ENIGMA games' source is originally C++. Since ENIGMA is not a compiler, but a parser, the original code they will be compiling is still C++.
iii. ENIGMA does not "link to Documented APIs" at all. GCC does the linking for ENIGMA; GCC is an authorized tool.
iv. To outlaw ENIGMA is to outlaw anyone else doing any coding for you, as well as to outlaw the creation of functions for the sole purpose of calling one or more Apple Documented API functions.
2122
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 11, 2010, 12:17:39 am »
"You couldn't just plop dependent typing into C. But that would give an error, since the size of x could be smaller than 25. You'd have to be checking that i is less than the size of the array, and then you'll pass the type checker with no runtime information."
So, we've gone from it fixing things for you, to it informing you a check is a good idea, to it actually erroring if you don't check. At this point, I can't even tell if you're referring to one concept, let alone one language.
"Libraries definitely cannot provide everything that a high-level language can provide. Stop arguing this. Using C's macro language is a horrible idea to make it higher-level. It's disgusting. And what do you mean by "a separate parser"? Something like what you're doing with Enigma and EDL? Because that is very, very far from being the best option."
Since all of this is either opinionated or unreinforced, I've no response.
So, we've gone from it fixing things for you, to it informing you a check is a good idea, to it actually erroring if you don't check. At this point, I can't even tell if you're referring to one concept, let alone one language.
"Libraries definitely cannot provide everything that a high-level language can provide. Stop arguing this. Using C's macro language is a horrible idea to make it higher-level. It's disgusting. And what do you mean by "a separate parser"? Something like what you're doing with Enigma and EDL? Because that is very, very far from being the best option."
Since all of this is either opinionated or unreinforced, I've no response.
2123
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 11:48:44 pm »
"You haven't provided any cases where a runtime check for array bounds is necessary."
"But it does not give you the productivity of a high-level language."
Sure. That's up to a good library. And/or a good set of macros. Like serp's continue(2) hack. Or a separate parser, which often isn't even the most efficient answer itself, but seems to be the best option.
Code: [Select]
int x[ftoi((scanf("%d",&a),a))];
for (int i=0; i<25; i++)
x[i] = properties[i];
"But it does not give you the productivity of a high-level language."
Sure. That's up to a good library. And/or a good set of macros. Like serp's continue(2) hack. Or a separate parser, which often isn't even the most efficient answer itself, but seems to be the best option.
2125
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 11:09:12 pm »
"How? You said that there have to be runtime checks. I was saying how there do not have to be runtime checks. How is that beating around the bush?"
You've provided one more case to cling to the idea that a runtime check isn't necessary. You've in no way shown that they are rendered unnecessary.
"LOL INVALID IS JUST A WORD YOU USE TO SOUNDS SMART"
Note the italicized word "argument." A premise, as I said before, can not be invalid. It can be true or false. Describing a premise as invalid is done in a failed attempt to sound smart. ...Nice try, though.
"Valgrind is a hack because it's meant to work around the limits of C++. And Valgrind does not provide even close to what high-level languages provide. And you still haven't shown that it provides even just what dependent typing provides."
So it's a limit of a language only if every implementation of said language doesn't come with the feature. Hm.
Also, you've nothing to back that up, and I have no idea what proof you could want of what valgrind can do. Look it up. Find a project worth using it on.
"Care to explain what you mean by this remark? I'm not sure what you're getting at."
No. I chose to leave that open to interpretation.
You've provided one more case to cling to the idea that a runtime check isn't necessary. You've in no way shown that they are rendered unnecessary.
"LOL INVALID IS JUST A WORD YOU USE TO SOUNDS SMART"
Note the italicized word "argument." A premise, as I said before, can not be invalid. It can be true or false. Describing a premise as invalid is done in a failed attempt to sound smart. ...Nice try, though.
"Valgrind is a hack because it's meant to work around the limits of C++. And Valgrind does not provide even close to what high-level languages provide. And you still haven't shown that it provides even just what dependent typing provides."
So it's a limit of a language only if every implementation of said language doesn't come with the feature. Hm.
Also, you've nothing to back that up, and I have no idea what proof you could want of what valgrind can do. Look it up. Find a project worth using it on.
"Care to explain what you mean by this remark? I'm not sure what you're getting at."
No. I chose to leave that open to interpretation.
2126
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 10:25:54 pm »Quote
Because JavaScript was designed for Unity. Exactly.Never stated the former. I stated merely that JavaScript was not designed in a manner that only supports web browsers.
Also, you can use C# or Boo with Unity if you don't like JavaScript's divide-by-zero handling.
The latter is irrelevant.
Quote
I never claimed that they're all better than C++.Likewise, I assure you.
Quote
But it can check if you're checking that the length is greater than the indices you're using on it.All these buts are just beating around the bush.
Now, in the rest of your post, you finally start building an argument. Which quickly runs invalid. This is how you show an argument is invalid.
i. We decided that Valgrind and dependent typing are the same in that "Valgrind is a hack to replace dependent typing; both let you do the debugging up front."
ii. What was not defined, to this point, is how Valgrind is a hack. I asserted "So, it's non-hackish because it's done automatically instead of by request" without resistance.
iii. You assert that dependent typing only informs of what needs checked.
iv. Valgrind only informs of what needs checked.
Seeing that premise ii implies an inequality which premise iv destroys, one of those must be false. Care to define a new grounds by which Valgrind is a hack?
"This has never been about low-level languages versus high-level languages. This has been about using the right tool for the job--using low-level languages for low-level tasks and high-level languages for high-level tasks."
My, what a perfect world it would be if you could just embed a low level language into a high, or even just mix--ffffffffffffffffffuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu
2127
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 09:24:17 pm »
This design is probably mainly due to the environment in which JavaScript almost always runs: browsers.
See Unity. Marbs is presently writing Dominoes 3 in JavaScript.
One example of a language that makes it hard to find bugs related to division by zero does not mean that C++ is better for everything than high-level languages.
And vice-versa, mind you.
"Arrays can be resized. It would change the type. If you had dependent typing in an imperative programming language, you just wouldn't make a specific size part of the array variable's type. Values can have more specific types than the variables that contain them."
Yes, yes, yes. Now tell me what size type int x[ftoi((scanf("%d",&a),a))] has, and how many witty optimizations can be done around it. Rusky stated how such was handled (though then dropped out): runtime.
From there, it's down to personal preference. Valgrind and dependent typing we've decided to be the same, so. In the event of the unforseen, I prefer the program to die rather than to waste time every access making sure it lives.
See Unity. Marbs is presently writing Dominoes 3 in JavaScript.
One example of a language that makes it hard to find bugs related to division by zero does not mean that C++ is better for everything than high-level languages.
And vice-versa, mind you.
"Arrays can be resized. It would change the type. If you had dependent typing in an imperative programming language, you just wouldn't make a specific size part of the array variable's type. Values can have more specific types than the variables that contain them."
Yes, yes, yes. Now tell me what size type int x[ftoi((scanf("%d",&a),a))] has, and how many witty optimizations can be done around it. Rusky stated how such was handled (though then dropped out): runtime.
From there, it's down to personal preference. Valgrind and dependent typing we've decided to be the same, so. In the event of the unforseen, I prefer the program to die rather than to waste time every access making sure it lives.
2128
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 09:04:19 pm »Quote
Infinity and NaN are pretty much errors for numbers in JS. They are in no way glitching.So, you're denying that treating a number as Infinity and proceeding like nothing happened could ever produce a behavior not accounted for by the programmer. I see.
Quote
You were saying that you'd rather do things Valgrind's way. He was saying that dependent typing is a non-hackish way to do the same things that Valgrind does.So, it's non-hackish because it's done automatically instead of by request? Pffft.
Quote
Obviously you haven't really learned how dependent typing works. The length of an array would be in its type. If there is ever the possibility that an array can be indexed out-of-bounds, i.e. it is indexed with a number whose range is not completely a subset of its range of indices, you will get an error.Uh-huh. So I guess arrays can simply never be resized, especially to an arbitrary or user-defined size. Well, at least it's safe and efficient.
Quote
You completely misunderstood what Rusky said. Non-trivial programming is not something that would not produce segfaults. Non-trivial programming is programming non-trivial things, in which segfaults would probably happen much more often in low-level languages than they would when programming trivial things.Meant trivial programming. Fixed.
2129
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 08:37:55 pm »
"Uh, what? Do you have any sources at all to back up this utter nonsense? Did you even think at all about this statement before posting it? That is completely false."
Buffer overflows kill the program nine times out of ten. The rest are detected 100% of the time by any decent debugger.
Languages with better exception handling can catch such things; not all do. JavaScript's my favorite example of one that doesn't react in any way to division by zero; defining it as Infinity won't always cause the correct behavior.
"...Yes. Your argument was that you wanted to do "debugging up front" with Valgrind instead of using a good high-level language and type system, which, for some reason, you dubbed "letting the program do it constantly" (whatever the heck that means). Rusky was stating that that is completely invalid."
He seemed to be comparing Valgrind to dependent typing, not stating that anything was "invalid" (Which, I might add, a simple premise can't be; people just like to say "invalid" to sound smart). Consistent checking didn't refer to dependent typing; quit pretending that dependent typing can account for 100% of bounds error checking. It catches much; the rest is handled runtime.
"Please try writing more clearly. I have no idea what you mean by this."
Probably because that was a very serprex-ish statement. Trivial programming--the kind that would not produce segfaults--is what the really-high-level languages are apparently good for.
Quote
Josh @ Dreamland:So much for being "completely false," as you regard most of my statements that aren't to your liking.
js: 1/0
js:
Infinity
Buffer overflows kill the program nine times out of ten. The rest are detected 100% of the time by any decent debugger.
Languages with better exception handling can catch such things; not all do. JavaScript's my favorite example of one that doesn't react in any way to division by zero; defining it as Infinity won't always cause the correct behavior.
"...Yes. Your argument was that you wanted to do "debugging up front" with Valgrind instead of using a good high-level language and type system, which, for some reason, you dubbed "letting the program do it constantly" (whatever the heck that means). Rusky was stating that that is completely invalid."
He seemed to be comparing Valgrind to dependent typing, not stating that anything was "invalid" (Which, I might add, a simple premise can't be; people just like to say "invalid" to sound smart). Consistent checking didn't refer to dependent typing; quit pretending that dependent typing can account for 100% of bounds error checking. It catches much; the rest is handled runtime.
"Please try writing more clearly. I have no idea what you mean by this."
Probably because that was a very serprex-ish statement. Trivial programming--the kind that would not produce segfaults--is what the really-high-level languages are apparently good for.
2130
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 07:39:51 pm »
"Valgrind is a hack to replace dependent typing; both let you do the debugging up front."
Does anything follow from that, or...
"Segfaults aren't the only error that comes from using lower level languages."
You chose not to name examples, or...
"Null pointer exceptions don't exist in actually-higher-level languages (i.e. excluding Java)."
Neither do divide by zero errors; they just cause glitching.
"Not having run into segfaults means you haven't done any non-trivial programming."
Like the kind one might use a high level language for to avoid such...
Does anything follow from that, or...
"Segfaults aren't the only error that comes from using lower level languages."
You chose not to name examples, or...
"Null pointer exceptions don't exist in actually-higher-level languages (i.e. excluding Java)."
Neither do divide by zero errors; they just cause glitching.
"Not having run into segfaults means you haven't done any non-trivial programming."
Like the kind one might use a high level language for to avoid such...
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 »