Next topic

[Josh @ Dreamland]

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:

Code Select Expand

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

Code Select Expand

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):

Code Select Expand

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.

[luiscubal]

I have a question. Is ENIGMA able to handle precompiled headers?

[Josh @ Dreamland]

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.

[Game_boy]

Will any of these new additions help with pure-GM users? For example, by making it easier for you to code some GM functions or systems? If not, it seems a lot of work to implement a peripheral feature, when you could release without it and add it later.

[Josh @ Dreamland]

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.

[RetroX]

Stupid question: is referring to an array going to be able to refer to the first element purely for GM compatibility?  Personally, I'd never enable this, ever, but it would be useful for those directly converting from GM.  Also, is LGM/unfinished IDE going to use a format better than GMK/GM6?  Please?

[Josh @ Dreamland]

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.

Code Select Expand


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

Code Select Expand


  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.

[serprex]

Why are you explaining COW without stating it so?

[RetroX]

You could use execute_asm(). :/
Also, another question - why is execute_shell() not implemented when it really is just a call for system()? or is it?

[Josh @ Dreamland]

It's a wrapper to ShellExecute. It's not implemented due to uselessness.

Serpy--
Because I ground all COW into BEEF.

[RetroX]

Also, something I found out:

Code Select Expand

int (*blah)(int,int)[];
Is a pointer to a function which returns an array (and, functions cannot).

Code Select Expand

int (*blah[])(int,int);
Is an array of function pointers.

[score_under]

Also, something I found out:

Code Select Expand

int (*blah)(int,int)[];
Is a pointer to a function which returns an array (and, functions cannot).

Who says they can't?

[RetroX]

Also, something I found out:

Code Select Expand

int (*blah)(int,int)[];
Is a pointer to a function which returns an array (and, functions cannot).

Who says they can't?

Apparently, the GCC.  It yelled at me when I tried.

[luiscubal]

Try using pointers instead of arrays. It works for me.

int x[] = int* x

[RetroX]

Try using pointers instead of arrays. It works for me.

int x[] = int* x

Yes, dynamic arrays work.  Static arrays do not work unless you actually define the size of the array, which usually isn't what you want.