Micah
|
|
Reply #90 Posted on: May 15, 2010, 10:11:40 am |
|
|
Joined: May 2008
Posts: 128
|
This same thing has happened before. I'm not just making up crap. Have you looked at his freaking parser's source code? I seriously laughed quite a few times looking at it. In the end, it's pretty much a harder-to-understand, less organized, more memory-hogging version of a tokenizing parser with no intermediate abstract syntax tree structure. If he had recognized that, his code would have been much, much shorter, more readable, and more easily modifiable, and parts of it could be reused elsewhere. But he came up with it on his own, so he wouldn't change any of it.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #91 Posted on: May 15, 2010, 10:22:45 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
"more memory-hogging" Clearly you're not making any of this up. Have figures?
"harder-to-understand" For someone who is expecting a token tree with which he has much experience, perhaps. I chose my method because it was so simple, a fifteen-year-old could think it up. GML doesn't require a token tree. Keeping one is pointless. If nothing else, I at least lexed the GML since I would be modifying it.
Reading C++ doesn't require a tree, either. If your program has sufficient understanding to place the code in a tree, your work is already done for my purposes. Perhaps I'd have used something different had you proposed it less than 3/4 way into development.
|
|
« Last Edit: May 15, 2010, 10:34:43 am by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #93 Posted on: May 15, 2010, 10:36:20 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Your method creates a tree. I am 100% certain a copy of the string uses less memory than your tree. Or did you not think about that?
That second string is my lex string. If you knew how the method worked, you'd have seen that from square one.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #95 Posted on: May 15, 2010, 10:44:36 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Now you've made it clear--as I knew you would--that you don't know how ENIGMA obtains its source. I'll save you the reading: it obtains it as a string in memory from Java. All at once. Every code. There is no "reading the source character-by-character until you recognize a token" because there is no source code to read.
And, if you know that I replace "and" with "&&&", "if" with "ss", etc., then you know how I determine what character to lex the token as. And you understand that adding a token is as simple as saying tokens[tokenname] = tokenchar;, and that instead of fiddle-farting around with a new structure for <> when I add templates, that I will instead replace tttt<..........> with tttttttttttttttt, and it will work flawlessly.
But I know you didn't consider that, because you only see the immediate; JOSH ISN'T LISTENING TO ME.
|
|
« Last Edit: May 15, 2010, 10:47:20 am by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Rusky
|
|
Reply #96 Posted on: May 15, 2010, 10:55:43 am |
|
|
Joined: Feb 2008
Posts: 954
|
If you want to reorganize your argument and refocus it... Not what I meant. I meant arguing with you over a specific aspect of design won't change anything, because specific aspects of the design aren't the problem.Comments on the readability of your code is irrelevant, but comments on the readability and organization of Josh's code are? That's really odd! Not quite. Comments on the readability of both are irrelevant, because they are not comparable. They are not comparable because he doesn't include the equivalent of mine, not because he includes less. Josh said himself that his code would be much longer with the actual tiers present. I was commenting on the readability of any code with Josh's method of debugging, so if he could show how he plans to pull off debugging of core behavior without losing the code's focus, I'd drop that argument. I also noticed: there was no expectation for debug code. You're sort of pulling ideas out of thin air to justify your assumptions. What if the debug code he were to add were to be clear and concise? I mean, I really don't get you. All you seem to be talking about is "mine is better, yours isn't readable (if you include all of this [which are of course assumed to be included, people should have an idea of what exactly is going on])" when the general consensus is that yours is not the readable code. Your code honestly just appears too bloated. That's just a personal thought, that's no judgment. I'm not really pulling ideas out of the air, per se. We already know users will want to debug their games, and several of the possibilities I came up with were from experience. The whole readable/example-are-not-equal thing came when Josh started arguing that his code was more readable. I was trying to show how, at this point, that is not really justified. ...where is the major consensus that any of the code given is either focused or unfocused? Perhaps I've missed that, wouldn't be the first time; and again, what is the relevance? Functionality is functionality, no matter how it is presented. Josh is asking you to present your functionality; it is assumed that people understand the functionality of his system as it has been around for a while. The "focused" thing was just talking about how debug and non-debug code co-exist. I think that's pretty objective. In the example code, Josh just left out any debug code. He claims it won't be there at all, but I'm fairly sure people will want to debug how their code interacts with core behavior, and in any case Enigma is meant to be extensible. While Josh's code may do what it needs to, my point is that it won't be as easy to extend in the future. bytheway oh yeah where's your debug code m8? r8 irony innit. That's my point. Again. Component debug code is completely separate- just make another component that wraps the first, adding in any debug behavior it needs. Then applying it is as simple as object->component = new DebugComponent(object->component), and removing it is Component* c = object->component; object->component = c->component; delete c;. This works at runtime and compile time, while Josh's debug code would have to be inserted with #ifs in either the game loop or the core tiers, where it makes code less focused on its real purpose. Evidently there's something wrong with having your own thoughts on something. That seems to be all Russky has to say. "My way is better than yours, so I don't even have to consider yours." Don't you think it would be just a bit fair to have at least somewhat considered the Tiering system as Josh considered your Component system? I suppose I may just be insane to suggest, you know, being fair. Just because I don't post when I consider Josh's systems doesn't mean I don't do it. On the parser: Somehow, Clang manages to use less memory for its AST than the (non-preprocessed) source code. Yes, GCC's tree is much bigger, but obviously that's just one way to do it. Yes, Clang's tree is bigger than the preprocessed source code, but that's again only one way to do it, and I'm fairly sure Josh's parser would use far less information than Clang's tree, which is designed to store as much information as possible. When making a tree, you don't have to keep the entire source in memory at once. Just because it's LGM doing the dirty work for you doesn't mean your parsing method doesn't involve keeping the entire string in memory. Either way, you copy the entire string to make the token stream. You also don't need to represent any more information than you already do with your current method. If you don't want to keep a structure for template arguments, just turn it all into one token exactly the way you do now. In fact, because of the simplicity of the transformations you're making, you probably don't even need an explicit tree. Just use the call stack. When you don't need to know all the information in a token, you just want to transplant it, just store the token's source with it and then print it out when needed. "Oh, but that would be storing the whole source in memory." Not so; it would be split into tokens, which would be discarded once you're done with them. Your current method keeps them all there the whole time.
|
|
« Last Edit: May 15, 2010, 10:59:35 am by Rusky »
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #97 Posted on: May 15, 2010, 11:02:04 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I don't see anything wrong with what you've said about my parser--the good or the bad--; I also don't see any reason to bother using a lookup table to conserve so little space, especially compared to GCC's AST. I know I don't have the skill to write an AST better than Clang's; to forsake a method this simple in an attempt would be asinine.
Anyway, does this mean you are finished defending the component system? At this point, I see no gain in using it instead of tiers for up to the collision system; only loss.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #99 Posted on: May 15, 2010, 11:48:03 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
That's actually just type; and yes, I'd considered doing something like that (using one char and a pointer instead of the full name) if only because it saves space, but then I realized that memory is cheap and that it's pretty much worse it for the ability to just cout << both strings to see if anything is the matter. It could probably be more efficient both in memory and in cycles, which is why I've been considering redoing it for a while with a linked list of such structs. It'll basically happen on a when-I-get-around-to-it basis, though, if it ever does happen. This method has proven quite convenient and simple to code for.
And don't use this as an axiom for why compiled games should be allowed to bloat; the compiler has no effect on the end end user.
And as a fun side note, this was posted through some miracle through the Wifi of a local restaurant or something; I'm in the car right now headed off to some race (against my will, I might add) and will return later.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|
Micah
|
|
Reply #102 Posted on: May 15, 2010, 02:43:22 pm |
|
|
Joined: May 2008
Posts: 128
|
The reason why I don't hack on Enigma is its horrible design. I don't really care too much if Josh succeeds or not, since I'd likely never use it. I feel the same way about my code. When I have a bug and ask for help, instead of getting help I get a bunch of links to other engines which use entirely different methods. Hmm. That's happened... once? And it was because you were trying to code a physics engine from scratch, which works when you have exceedingly simple platforming, but without lots of study and hard work does not work for anything more complicated.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #103 Posted on: May 15, 2010, 05:22:37 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
"Your only argument against using Rusky's parsing method besides that you created the one you're using yourself was that it uses too much memory. Having smashed that argument and you having dropped it, now we're back to how you keep choosing crappy methods just because you came up with them." I acknowledged that replacing the second string with linear-linked structures would be more efficient and would probably be done at some point in the future. Now is not the time, as the only end of that system is to work. Furthermore, I had thought of that idea long, long ago; the method now employed was simply quicker to implement.
Moreover, it is unlikely that the newer method would save memory, but it would probably save insertion time. Because I don't know the gain and the gain is unnecessary, it's not high on my priority list.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|