Josh @ Dreamland
|
|
Posted on: November 12, 2009, 10:37:36 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Hello, all.
I'm happy to say stdio.h parses correctly, which means it's all uphill from here. (That saying makes no sense. Isn't going up hill more difficult than going down?) Okay, how about, it's smooth sailing from here.
Now, note that stdio is by far not the most difficult header to parse. Overall, it probably only tests 70% of what needs testing. The C++ headers will present plenty of challenge, as scopes will turn into my worst enemies. However, having stdio compile means that I can rely on some very basic things working as I tackle the more complicated problems. I can't really think of an analogy for what that means.
I'm very confident that quite soon, map<var,var> will be ENIGMA-parser-friendly.
Anyway, I'm going to move on to other C headers first, as there are some aspects of C that I've not yet focused on. These include the following, for those who are literate in the language:
#define concat(x,y) x##y This appears in many headers stdio includes. It's a wonder stdio actually works, unless I've implemented it and forgotten, which is a distinct possibility.
int (*blah)(int,int)[]; Not sure how it will handle the parentheses around blah, or no identifier being named after int. It will probably bitch about both, so I'll run some isolated tests on that before I parse anything else. Do note that the system was designed with those in mind.
...Actually, that's it. Everything else should follow once those are done. Then we move on to templates (mostly implemented), class (needs to be integrated into the piece of code that handles struct), scope operator (see below) and tacos.
Scope operator (from bits/stl_tree.h):
pair<typename _Rb_tree<_Key,_Val,_KeyOfValue,_Compare,_Alloc>::iterator,bool> In honesty, that was just to scare people. Like I told that one guy that none of you have ever heard of, that line doesn't look so scary when read character by character at millions of chars per second.
End.
|
|
« Last Edit: November 12, 2009, 10:39:07 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 #2 Posted on: November 12, 2009, 05:45:55 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
That question is actually pretty vague, considering how ENIGMA works. I am 90% positive GCC supports them, though I've never used one myself. I was considering an implementation of my own format for them to make syntax checking faster, but really, I'm not sure if there's a point. Ideally ENIGMA would be loaded as a DLL, and could do a lot of precompiling at start, which would save time later at the cost of startup time. However, it's really not that much time anyway... parsing those headers takes significantly less time than actually compiling them, obviously.
So, assuming you are talking about my parser, I might implement my own precompilation, but probably not right away, and almost definitely not GCC's. (Being able to work with GCC's output would void the point of parsing this myself.)
As for using precompiled headers in GCC to speed up compile time, that was something I intended to look into. I have no plan for it yet.
|
|
|
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 #4 Posted on: November 15, 2009, 11:11:16 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I suppose you could consider it peripheral. It has to be done at some point, however. It probably won't help GM conversion directly, but indirectly it will be able to parse the headers itself. What that means is that it can enable selection of which headers to include for later.
Basically, it brings the system closer to C++. Var is no longer just a type, it's a structure. And that structure has a method for casting to int, which can be used to identify an instance. It makes for a more intelligent parse that will make life easier down the road.
That being the case, although it doesn't directly help pure-GM games, it's not something I want to put off.
|
|
|
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 #6 Posted on: November 15, 2009, 09:49:54 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
It may turn out that Ism will have to start saving ENIGMA files in the format we use to communicate between the two apps, depending on how many of EINGMA's non-GM features we can cram into GMK format.
As for arrays by reference, your question is inapplicable. Ha. var::operator double() will return the first element. var::operator =(const var&) will ideally "copy" the entire array by reference as std::string does. This will be O(1). Editing an element from that point until the freeing of the first var will be O(N) for the first time, then O(1) from the second edit on. (The array is only physically copied when necessary).
For example.
//script0: var array; //do some stuff to array return array;
//Step event: var a = script0(); a[1] = 10;
Everything in that code operates in O(1), constant time.
var array; //do stuff to array var b = a; //copies reference to array, operates in O(1) b = 1; //sets b[0] to 1, operates in O(N) b[5] = 2; //Obvious what it does. operates in O(1) var c = b; //operates in O(1) once more if (c) //operates in O(1) b[5] = 0; //operates in O(N) b[3] = 2; //operates in O(1) if c[0] != 0, otherwise operates in O(N)
Hopefully that clears it up rather than confusing people.
Current var doesn't do that, but minor modification will make that possible. This is planned, and easy to do.
Edit: Progress As it happens, Linux stdio takes advantage of all those nice things I said still needed testing. So I've been working my ass off to get those to work. Also, apparently __const is a GCC keyword. Along with asm, __asm, and apparently __asm__, thanks score_under. v..v"
Furthermore, I'm tired, and still have psychoblah homework to do. Guess I'll do it tomorrow morning.
|
|
« Last Edit: November 15, 2009, 10:18:27 pm 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 #9 Posted on: November 16, 2009, 10:31:43 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
It's a wrapper to ShellExecute. It's not implemented due to uselessness.
Serpy-- Because I ground all COW into BEEF.
|
|
|
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
|
|
|
|
|
|
|
|
|