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

2116
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.

2117
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.

2118
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."
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.

2119
Announcements / Re: Anaphase
« on: April 10, 2010, 11:11:05 PM »
Buh?

2120
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.

2121
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.
Also, you can use C# or Boo with Unity if you don't like JavaScript's divide-by-zero handling.
Never stated the former. I stated merely that JavaScript was not designed in a manner that only supports web browsers.
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

2122
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.

2123
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.

2124
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."
Quote
Josh @ Dreamland:
js: 1/0
js:
Infinity
So much for being "completely false," as you regard most of my statements that aren't to your liking.
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.

2125
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...

2126
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 06:28:59 PM »
"They happen once every 2 days on average."
I've had four segfaults in total in the past year. They each took between five and twenty minutes to fix.

2127
Announcements / Re: Anaphase
« on: April 10, 2010, 06:25:14 PM »
Quote
Have DirectX graphics been implemented yet, or is that purely there for preparation?  Also, in the future, would it be possiblw to write things for ENIGMA (not necessarily you, but maybe someone else could help with it after r4 is released) for WINDOW=WIN64, WINDOW=GTK, and WINDOW=WXWIDGETS?
Purely preparatory. Yes, all of those would be fine if they are structured the same way as the two currently implemented systems.

Quote
EDIT: If ENIGMA is a DLL, what is going to be used for the GNU/Linux version?  You can't link Java to a shared library, afaik.
Can, and did.

2128
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 05:14:13 PM »
*cough*
Valgrind

I'd rather invest any amount of time into debugging up front than let the program do it constantly.
...But that's just me.

2129
Announcements / Re: Anaphase
« on: April 10, 2010, 12:09:27 AM »
God, I hope so. If no one yet cares about interface, for which output redirection currently is STILL BROKEN, then I don't see why not. As long as the makefile gets written. I've asked Aragon to allow for parameters GRAPHICS=GL, WINDOW=WIN32, and WINDOW=XLIB. If he can add those... We'll be in good shape.

I'm going to add template tolerance and automation tomorrow. Ism can hopefully fix output redirection as soon as/before Aragon has makefile working. All else is looking good. Just fixed/seemingly finished implicit typing again. Have to make sure scope applies to it...

Presently it will flip shit if you say, for example,
if (true)
  int a = 0;
As the behavior of that is meaningless in C++ and undefined in ENIGMA. Will see what I can do about it. (It's technically as simple as finding non-'n' letter tokens and pushing the scope until ';', but...)

2130
Announcements / Re: Anaphase
« on: April 09, 2010, 10:43:31 PM »
Yes, that's what was decided...
Aragon is actually taking care of the makefiles now. Which makes him important. With a little luck, ENIGMA will simply pass a couple flags to the makefile and be done. Then only cross-compiler makefiles, such as that for the Wii, will be separate.