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.

Today I had to turn in Paper 3 for English 101. It was a 4-5 page requirement. I also had to turn in a 10-12 page essay on a self-help book for psychology. In both cases, I barely scraped the minimum requirement. I just hope I manage a good grade for them. Truthfully, I did the entire psych essay yesterday. All ten pages, including reading the book. THAT is an accomplishment. Unsurprisingly I am ending the venture as a slightly more religious person than when I began.

It is a nice feeling, to move that self help book and the accompanying essay to ~/Hell. I won't miss it.

Progress:

Um. I can't remember. My brain is full of psychology and English fluff. Moment... Ah, yes. __asm. Totally forgot.

Code Select Expand

int returns_one() __asm(":mov $1, %eax");

That particular piece of code threw a parse error. After some WUTs, I fixed the problem. That's when I took a look at my psychology essay requirement and realized it was 10 pages. So I will be continuing now...

Also, we seem to be having some server trouble today. Don't worry, they're on it.

I have successfully implemented 90% of everything, and am working on the rest of the ten percent as I attempt to parse system headers.

Let me tell you, I'm surprised. Those coders managed to write headers that have attitude. These things are sentient, angry source codes, and they don't like new parsers. Honestly, the things are some sort of intelligent. They have to be.

Code Select Expand


Including file from features.h
Including file from sys/cdefs.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
...Repeats past max SMF character limit...
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Parse time: 1340 milliseconds

Line 330, position 25: Failed to include sys/cdefs.h: File not found
Macros (44):
 _ATFILE_SOURCE: 1
 _BSD_SOURCE: 1
 _FEATURES_H: 1
 _ISOC99_SOURCE: 1
 _LARGEFILE64_SOURCE: 1
 _LARGEFILE_SOURCE: 1
 _POSIX_C_SOURCE: 200112L
 _POSIX_SOURCE: 1
 _SVID_SOURCE: 1
 _SYS_CDEFS_H: 1
 _XOPEN_SOURCE: 600
 _XOPEN_SOURCE_EXTENDED: 1
 __FAVOR_BSD: 1
 __GLIBC_HAVE_LONG_LONG: 1
 __GLIBC_MINOR__: 9
 __GLIBC_PREREQ(maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min): \
       ((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
 __GLIBC__: 2
 __GNUC_PREREQ(maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min): 0
 __GNU_LIBRARY__: 6
 __KERNEL_STRICT_NAMES: #endif
 __STDC_IEC_559_COMPLEX__: 1
 __STDC_IEC_559__: 1
 __STDC_ISO_10646__: 200009L
 __USE_ANSI: 1
 __USE_ATFILE: 1
 __USE_BSD: 1
 __USE_FILE_OFFSET64: 1
 __USE_FORTIFY_LEVEL: 0
 __USE_GNU: 1
 __USE_ISOC95: 1
 __USE_ISOC99: 1
 __USE_LARGEFILE: 1
 __USE_LARGEFILE64: 1
 __USE_MISC: 1
 __USE_POSIX: 1
 __USE_POSIX199309: 1
 __USE_POSIX199506: 1
 __USE_POSIX2: 1
 __USE_REENTRANT: 1
 __USE_SVID: 1
 __USE_UNIX98: 1
 __USE_XOPEN: 1
 __USE_XOPEN2K: 1
 __USE_XOPEN_EXTENDED: 1

Variables:auto:   Serves as typename
bool:   Serves as typename
char:   Serves as typename
const:   Serves as typename
double:   Serves as typename
float:   Serves as typename
int:   Serves as typename
long:   Serves as typename
register:   Serves as typename
short:   Serves as typename
signed:   Serves as typename
static:   Serves as typename
unsigned:   Serves as typename
volatile:   Serves as typename


The best I can make of that output is that somewhere along the line, I had too many files open.
...Fixed. Now it loops forever like... like it should, I suppose.

I know the error is because I forgot to share my macro function implementation with the expression evaluator, and will fix that next. I just thought I'd share the O___o moment and the news that the basics are al(most)l working.

This is the second time Ubuntu dropped its ass.

The power went out, and I rebooted to find X thinking it was a fairy again.

In other news, I just finished my economics rough draft, and my next English papers are due at the end of the month. Biology exam next Wednesday. I have some time to work.

That's all, really.

In other, other news, I was thinking, man, it sucks having all this economics homework.
Then I thought to myself, Well, it could be worse. I could end up working on Game Maker and being down 600,000 USD. BAHAHAHAHHAHAHAHAHA. </verbal abuse>

= No.

My drivers suck. Tried to fix that with Retro, as well as my mouse problems... Long story short, I Just finished reinstalling the X server. <_<"

Anyway, my sound quality sucks so bad I can't test audio here. I'll do that on Windows, but it should still work in Linux for anyone whose drivers don't suck as bad as mine.

Other issue is template instantiation, which I'm going to have to do every time a template is used. (Because map<var,var> is different than map<int,int> in enough ways that I need to keep track separately).
Though, honestly, I can't really think of a good reason to keep track to the level of instantiating them, so maybe I'll drop the idea before it hurts something.

I have to attend some English garbage at some point, but for the most part, no more homework in there for a while. What I do need to do is draft a large economics paper, read some biology crap, and work on my psychology things. Hopefully those do not consume TOO Much time.

Templates are one of the few remaining obstacles. I'm going to run through the rest of the process to see when I would need to know anything but how many args are optional. It may turn out that I don't need to know anything else. If that's the case, it's solved. That leaves with(), switch(), and #include.

I'll keep you posted when each of those is cleared.

I called it fair and square.

Today consisted mostly of school and battling code. But I had fun, and made another awesome dent, at least.

Code Select Expand


Macros:
a:   Serves as typename : struct
{
  b:   Serves as typename : struct
  {
    member1:  int 
    member2:  int 
  };

  itsanintyoubastard:  int 
  nested_struct_instance:  b 
};

auto:   Serves as typename
bool:   Serves as typename
char:   Serves as typename
socks:  int 
colligma:   namespace
{
  a:  int 
  b:  float 
  c:  double 
  d:  somethin 
  e:  somethin 
  f:  char 
  g:  int  Dereference path: (params = 0)</group>
  h:  int  Dereference path: </group>[]*</group>
  somethin:   Serves as typename : struct
  {
    d:  int 
  };

};

const:   Serves as typename
double:   Serves as typename
effing_a:  a 
float:   Serves as typename
int:   Serves as typename
lime:   Serves as typename : struct
{
  candy:  bool 
  disease:  int 
};

long:   Serves as typename
register:   Serves as typename
short:   Serves as typename
signed:   Serves as typename
some_big_ass_function:  int  Dereference path: (params = 0)</group>
static:   Serves as typename
tt1:   Serves as typename : struct
{
  tt2:   Serves as typename : struct
  {
    tt3:   Serves as typename : struct
    {
      a:  int 
    };

    tt3i:  tt3 
  };

  tt2i:  tt2 
};

tt1i:  tt1 
unsigned:   Serves as typename
volatile:   Serves as typename


That was generated from this code:

Code Select Expand

struct a

{

  int itsanintyoubastard;

  struct b

  {

    int member1, member2;

  } nested_struct_instance;

} effing_a;



namespace colligma

{

  int a;

  float b;

  double c;

 

  struct somethin

  {

    int d;

  } d;

  somethin e;

 

  const mutable char f;

 
  long unsigned int (h)*[2];
 

  int g()

  {

    heh; this does nothing;;;;;;

  }

}

int some_big_ass_function()
{
  some code
}

int socks;

struct tt1
{
  struct tt2
  {
    struct tt3
    {
      int a;
    } tt3i;
  } tt2i;
} tt1i;

struct lime
{
  int disease;
  bool candy;
 
  int operator + ();
};

Pretty awesome. Almost awesome enough to cut it.
Rusky will be amused to know I just moved a 500 line if statement to its own source file. Hahahahahaha. That thing was getting in MY way. Will probably move more.

Things you may have noticed: Supports nested bloody everything. Reports types. Reports references (including functions) in some stack for reverse-iteration. Ignores code.  Clunks out at operator+ because it's skipping another huge-ass if statement I just moved. End of list.

It's damn late, and I'm tired. I'll be up at six tomorrow, so. Just bookmarking this day; it's still mine.
(I'll prolly shoot for some [nearly] equally monumental day coming up, which I will justify with some line of BS.)

Ism is working on an SVN-based updater. This is after we fixed her computer, which is also on Ubuntu, that decided to take a dump and lose her partition table. Through some googling we managed to get it working again from a LiveCD.

Would have made an awesome fish tale if we'd still had time to finish. Nyet...

And night.

We're on a new server, with a new host. This resulted in some disagreements.

I... Listen, the CFile parser -- and the others, really -- are approaching a stage where they can be released, even without being 100% complete.

Would everyone like an early preview, if I can make one by the ninth?

With some gearing, the preview could have an updater. So there'd be no more wait for R4; You could just download updates.

I've actually been running Ubuntu for several days now. But I'm just now posting about it.

I haven't told many people at this point, but college started last Monday. Since then, I've had next to no free time. Even now I should be reading... checking what I have to do for economics tomorrow...

Whatever.

I'm trying to work, but my free time has just been sliced. Every day, a new chapter in my biology book (which I should mention has its own orbit) as well as some awful essay or other worthless priceless piece of shit information from this book calledThe Presence of Others. The thing opens "This is a book for and about reading." Jesus.

Anyway, the good news is that everything I expected to work on Linux does in fact do so. With a little luck (and less homework, mind you) I could probably get this thing working on Mac, too. BUt that's complicated in addition by the fact that I don't have a Mac. (I'll just VM It).

Also, I believe ubuntu fixed my card problem by ignoring it. It's piping things through the card, but it is slow as molasses. (Talking of screen savers, not ENIGMA, don't worry)

Now I need to come up with a molecule-based reason that gas (well, Isooctane) burns better than ethanol for my BIOLOGY class. Have a paper to write for economics on the topic that I had some say in choosing: "Does America 'going green' make economic sense?"... I imagine I can sink my teeth into that one. For the same class, though, I'm supposed to read "The Nature of Man", which is some 40 pages. <_<"

At least English... oh, no wait... In addition to that book about reading I mentioned, there's a paper due. Yeah.

Not to mention random calculus assignments, which are basically just numerous and annoying. (Rather than challenging. Our last task was to give intervals on a graph that were increasing and intervals that are decreasing. I could get a kindergartener to do that)

So basically, I'm swamped. I killed more time than I'd liked to have, just writing this.

Not sure what else to say. I'm in no position to make promises. But I will work some on it today.

In fear of some readers being more pious than others, I'd like to clear some things up.
In other words, stop reading at the first big caption.


In summary, Rusky's trying to get me to use a token tree parser by starting work on one as a proof of concept. I assume he will continue to develop it from time to time, until it actually competes with the one I wrote as a competent proof of concept or until I'm all done. Whichever comes first.

I met it with some pretty harsh skepticism. But it's not because I feel token trees are bad.

A tree is a very useful tool. It will allow you to easily skip over large chunks of data to weed out only what you need. They are used in probably more than 90% of modern parsers. I'm not looking up an actual statistic, sorry math fans.

However, I don't feel they're appropriate for the formatter-type parser.

The entire point of the formatter parser is to add semicolons and weed out variable names by declaration. It doesn't really call for a tree, in my opinion.

Here's a sample code:

Code Select Expand

a=0b=1

That code is valid GML. So now, how do we deal with it?

Those who are weak of heart should stop reading now.

Token tree method:
The code is read into memory in a structure called a tree. A representation is depicted below:

Code Select Expand


=
├─a
└─0
=
├─b
└─1

To save size, a symbol table is used. It's basically a list of variable names/other things that appear in the code. The table makes comparison of strings from the time of its completion onward operate in constant time by comparing them as an index, not byte for byte. (Means it's efficient)
The code is then rebuilt with all proper punctuation.

My method:
The code undergoes a (somewhat) organized series of stream-like modification.

First, the code is reread into its current buffer free of comments and excess whitespace. This won't affect the code above.
Next, a second block of memory is allocated the size of the first. The first is named code, the second synt.

They look like this:

Code Select Expand

a=0b=1

Code Select Expand

n=0n=0

Next, the blocks are reallocated at twice the size for all upcoming changes. A pass is made that keeps a look out for patterns of tokens. You'll notice above in the syntax string that variable names have been replaced with n, while numbers have been replaced with 0. This is so only one check has to be made to tell what any given character in the code is a part of.

Notice the "0n". A pass is made to look out for things like that.


More complicated code
Trees are usually, or at least very often, done by using a parser generator of sort, which takes a grammar file that can be easily edited. It organizes the process by giving what I've seen to be a regex-like interface for manipulating what patterns of tokens the parser looks for.

My method's basically a hard-coded version of that. I specify what tokens require a semicolon between them in a separate function, instead of using a generator that reads that info from a text file.

In the code

Code Select Expand

if 0a=10else b=10 the token tree would do just what it did above, using if as a root of another sublevel, then putting the next = token inside it. It would then look up the rules for what's inside if to see what it puts next.

Mine does this, instead:   semis->push(')','s'); write_symbol('(');
Which does nothing but insert a left parenthesis and tell it, next time it needs to insert a semicolon, use ')' instead. This is still done in that pass.
(If I were using only find and replace like I said I could, I'd replace "if(.*);" with "if\($0\)"  )

Rusky said he didn't add for loops to his proof of concept. Wouldn't make much sense for me to do so, because all I had to do to implement for() was push two semicolons and an end parenthesis onto the stack, like I did above.


Partitioning my parser
Rusky's other complaint is that my parser is divided into sections. One's responsible for syntax check, one's responsible for C definitions, one's responsible for adding semicolons/other GM-C replacements. I don't really see what there's to criticize about that, but here's a nice reason to do so...

The formatter parser has more passes and gets more attention than both the syntax check and C parsers combined. However... They're what Rusky will call a disaster, and what I'll tell you are faster than greased lightning.

Instead of lexing, they keep a couple variables handy (integers, actually) that I like to refer to as registers. (I may in fact devote a register to each of them, as they are so few.) They let the CFile parser identify what it's going through now. Each C++ key word has an ID. (not dissimilar to the symbol table of the token tree).
In addition to this ID, a second variable is kept indicating mode. I keep track of these mentally, because that's how I goddamn roll. (Ask score_under). That's the part that really makes Rusky cringe; I rarely comment, and I don't document, because I just memorize all the values, or review my thinking to get back to them.

This ID, however, is the difference between "using" and "using namespace", just for example.

( Typedef is handled differently. Typedef's value is 128 or some crap, so I can just OR whatever I have by it to indicate that I'm typedef'ing it. (C and C++ will let you totally whore typedef) )

The most complicated thing to deal with is what may require a stack, and that's pointers to arrays to pointers....of functions.


Now, here's the kicker: I use a tree to store scope data. Le gasp, right? Each variable is stored the same way. An integer can have members if I really want to. And I can tell you just from using them there how beautiful a system they can be. But knowing that, I still say a pair of aligned strings is the way to go with a formatter.


Benefits/Downfalls

• 
  Tree offers O(1) string comparison. But the parser doesn't need that.
  
• 
  Tree does all punctuation in one pass. But it's liable to leave out, say, entire else statements. And not understand unary unless begged.
  
• 
  String requires multiple passes, but offers some find-replace methodology. To find a declaration, for example, I just search "d".
  
• 
  Tree is more comprehensive. I'm not sure if that's good or bad. I bring up unary again... Luis's parser had a fit on it. And Rusky's won't treat ++ as adding a unary-positive real value, or as incrementing the previous. (But he'll tell you how easy it is to add if you ask him)
  
• 
  Being component based means that my parser's syntax check only needs to do what's necessary for syntax checking... It never touches the C parser. The formatter needs to know the members of declared classes, so it calls the C parser to get that. Syntax check can just add the name as a type.
  

Okay, this is the single longest thing I've ever typed up. If you did any more than just skim it, I feel sorry for you.

That other one wandered off.
Anyway, this is progress:

Code Select Expand


int a = 0 if a = 1 b=2c=3     else d=4 e=5 f='test removal of strings'g="poop"  endorphin = /*removal of comments*/ 6 motherlicker = 7 //or eight
end break label: goto label awful_code() a=b=c + d  *  e / f do do a = b until c until d if 1if 0else else c()return 0  /*


Parses to

Code Select Expand


int a = 0;
if(a = 1)
  b = 2;
c = 3;
else d = 4;
e = 5;
f = "test removal of strings";
g = "poop";
endorphin = 6;
motherlicker = 7;
end;
break;
label:
goto label;
awful_code();
a = b = c + d * e / f;
do do a = b;
until(c);
until(d);
if(1)
  if(0)
    else;
  else c();
return 0;


And yes, I know the syntax is invalid. The parser doesn't care.
Here's another:

Code Select Expand

long unsigned int a

b = 0
cd = 'str'+"ing"

do
{
a=b-0c=d-1
while a a--
}
while c

do until 0

with a b.c = e
if d exit

Becomes

Code Select Expand

long unsigned int  a;
b = 0;
cd = "string";
do
{
  a = b - 0;
  c = d - 1;
  while(a)
    a --;
}
while(c);
with(a)
  b . c = e;
if(d)
  exit;


Nothing you didn't see in R3. Except else; else and some indenting.
The difference is the mechanism.

Notice the first statement: int a = 0;
In R3, this was done with some sketchy additions to the parser; it wasn't originally planned to support that. But now it's an official part. What's this mean?
This means that additional types, including structures that I know the more intelligent users will grow to love, can be added and used withing EDL.

What's left:
Make begin and end actually work, instead of acting like a statement XD
switch() magic
with() supermagic (I have the perfect plan)
Re-fetching declared variables (five minute job thanks to the parser's system)
Pass struct{} and the like to CFile parser, as those are its forte
Make sure syntax checker supports struct and the like

I dug up the new instance system. (Irony, yes, but I'll take it).


I've been hopping back and forth between Linux and Windows. I want to re-commit all the code to the SVN to make that process easier. Not to mention it'll make things better for me considering my college schedule I've been sorting out over the last couple of days.

(The thing's terrible. It's like Swiss cheese; three hour gaps on a good day ;_; )


Anyway, what else... Future plans for before the release.

Incorporate at least backgrounds, possibly sounds, but I'm not sure.
Make sure there's an updater. This will make releases cost less blood.
Test the new instance system with various options set (there are three things to set with two or three choices each.)
Implement a derivative of the string class specifically for ENIGMA. (this will fix so much, efficiency wise)

...And that's it. I was expecting more, but the list is looking short. I like that.

[this]

I told a2h to rag on me to post what I've done each day.
Don't get your hopes up though; I'm not updating the stupid 'completed functions' page.

Recent activities include collecting all my work from the last few months and organizing them into the same root directory.
What's basically happening is I'm hooking up the Expression evaluator, CFile Parser, Syntax Checker, and EDL Parser up to the Compiler, regardless of what's done and what's not.
This will, ideally, allow me to get them all working together and add on as I go.

I've also begun a large-part recode around the original EDL Parser. It has to be done at some point. Why? Well...

It's a somewhat-known fact that the EDL Parser is written in GML. A lot of you are thinking "wtf" right now. I wrote the parser, then exported it, and parsed it to C++ with itself. And it worked. (With the addition of function names around each script it parsed).

It instantly gained at least a tenfold speed increase, but that's not enough.
(Not to mention parsed GML is plug ugly; NO comments, which is 1% less than the 'desired' percentage of comments I normally leave, and no whitespace or structure)

Basically, the idea's brilliant, but the code's a bit sluggish and eww since it used to be GML. Was the ultimate benchmark, but now things need to be implemented that GML can't describe.

Please take the next couple minutes to get over the fact the parser is/was GML. Read on when you're ready.


Moving on, then, the new parser will not use < to indicate tokens in its stream. Instead, it will add a couple more letters for equally fast, less ambiguous indexing.

Scripts were scoped into each object that used them in R3. In R4, they will be defined in the global scope, and will be passed this. (The C++ loose-equivalent of id) This corrects a problem where with (a) scrname() doesn't work. You probably didn't notice.

Also, localv is being changed to local in light of Yoyo deciding that global var a; was a good idea. Now you can say local var a;, which is about as useless as saying self.varname, but is useful for saying local int a; or local double a; and not wasting all that space and time. (Though not much of either, really.)


Those who pay attention and have decent footing between these two languages know that you will now have the entirety of C++ at your disposal. If you really wanted, you could #include <iostream> and cout << "something";. Unless I decide that I'm going to maintain checking for assignment operator, in which case you'd have to say something stupid before it with an =. Haha.


There's another chunk of work I'm not looking forward to, which involves the new format. We've added basically every resource to the format, but this doesn't mean they all work yet. I'll derive background from sprite, but sound is gonna be a pain in the arse.


Another change, for those with good footing in C++, is that string() will not be a function anymore. GML fans,  don't panic: Saying string() will still work. The difference is purely technical; string() will be a constructor of a new datatype.
I had a problem with var that prohibited me from taking int as an argument type, which hindered efficiency. The new string class should fix that problem. It will be derived from std::string, with some additional namespace magic to prevent screwups.

If anyone really needs me to explain the details of that, I can, but I'm not going to unless someone asks.



In other other news, I'll be continuing development on Linux. Most of you know ENIGMA works on Linux now. Since the OS is more picky with things--for instance, file name capitalization--I think it'd be a good idea to move to it. And file names aren't the extent of it; big GCC, as in, the GCC which is not minimalist or for Windows and likely has the majority of GNU devs on its case, offers more precise error checking and warns on more things. Which is nice, as it prevents errors down the road.


Anyway, I'ma get back to working on the compiler. I have to find my new instance system and put it in the shell folder. After it's at a good stop point, I'm wiping the SVN and reuploading everything. (Makes it easier switching back and forth between platforms).


No news on ENIGMA's LibOGC frontend.

Cheers. A2h will hopefully make me edit this tomorrow. Maybe even post new.

I'm pleased to inform that the expression evaluator is working just as I'd hoped.
I'd like it to have a public test.

There are two versions. The C++ one, and the GML one. The C++ one is for macros, and so does not allow strings or floats. (Numbers that aren't integers.) Also as per preprocessors, it doesn't allow casts. (Though, there is a cast system implemented.)
This means that 5/2 = 2.
The GML one does allow strings and floats. It should work just like you're used to.

Note that functions and variables aren't in yet. It's an expression evaluator. It's designed for #if. Variables will be treated as zero. I just overkilled it a bit so I could more easily make a full fledged interpreter later on.

Other changes include that ternary exists, and there are more than two string comparison operators.
(("str"=="str")?"true":"false")+"zor" is my favorite string test.
Also, note that single quotes are treated as numbers in C++, and I think I left them that way in the GML one. So 'str' is a number, "str" is a string.

This means one less step on my todo list. One more item checked off.

Those who wish to try it out can download it here:

Both as 7z / as zip
C++ as 7z / as zip
GML as 7z / as zip

When the window pops up, you are immediately allowed to type. You can clear the screen by typing c or cls, and close it by typing x. (And pressing enter.)


Anyway, I'm going back to the CFile parser now, which I've been told by many is the impossible task for one person with no tools. But I don't care what they think. ^_^

Also, feel free to keep guessing at the secret from last topic.
I'll be working.

Questions that have been haunting me since day one, and I'm sick of dealing with them, so I'll present them to my user base.

• Var can't return int, string, double, and char*. It just can't; it leads to ambiguity out the back end to where your game won't compile.
  
  Knowing this, do I have all the functions take double and string as parameters (a 100% waste of memory and at least 800% waste of speed), or do I alienate std::string as a return type?
  
  Neither of those are very attractive choices. There is a middle option where I have the user decide whether or not they want to keep var as a type, and re-compile ENIGMA optionally to take scalar arguments. (Scalar meaning one type, in this case of the smallest needed size)
  
  I will try again to get var to work with conflicting cast types, but std::string is the one that causes ambiguity. Even though I added an explicit cast function for it in var. (Meaning I told it exactly what to do to convert var to string, but it errored anyway.)
  
  
• Game Maker does not have functions that don't return anything. Even functions in GM that return nothing will actually behave as zero, and can be used in assignment and arithmetic. This isn't the case in C++.
  
  For the first three releases, I returned zero in all those functions, as int for max speed.
  
  Why not do away with them? Some people like to add a function that needs called but returns nothing to a function that must be called after the first function, in order to call them in one statement. Like registry_set_root(3)+registry_read_real_ext("blah","blah")
  
  That's an ugly, yet useful feature of the language. I was considering having function return ENIGMA_VOID, and the return statement at the end be return_void;. This would enable the user to choose whether or not to do this and recompile.
  
  
• Game Maker does not return success or fail. Especially for functions like registry_write_string(). A lot of functions that are VERY prone to failure have unclear methods or no method at all of determining whether it worked.
  
  Should ENIGMA return error codes as WinApi does? For registry functions, this would also eliminate combining things like registry_set_root(3)+registry_read_real_ext("blah","blah"), though since registry_set_root will never fail and the latter returns nonzero normally, that's not exactly the best example here.
  
  Maybe a function to check if the last calls succeeded?
  
  
• WinApi has developed some since its first release in 1912. As such, we have a set of 16 bit functions that are preserved for compatibility with 95 and 98, but then more recent functions that are meant for 2000+ and may not work on really old Windows systems.
  

The problem here is, do we stick with the old ones and risk being obsolete come Windows 7, or do we lose 95 and 98 compatibility and go with the new? Again, this can be fixed by compiling separate releases for each operating system, but that's not exactly attractive as an option.



There are plenty more conflicts, but these are just a few that are immediately bothering me.
If you haven't guessed, registry functions have been implemented.

College classes are nearly over; I have a huge take-home final exam to worry about this weekend, followed by 23 more days of high school. But then I'm done, and will actually have a decent amount of time to work. I hope.

Since people are beginning to freak out, I decided I'd best be more liberal with my updates.
...No, I will not get a Twitter. Ever. That would kill me on the inside.

Continuing.

DLL's are working. That doesn't mean they're finished, though; I have some stdcall testing to do now that I have cdecl working.

The endeavor looked something like this:
7:58 - Code is riddled with inline asm. Output is gobbly gook in the form of a message box.
8:?? - Clam mentions the name of LibFFI, which I'd heard of previously but then no one knew its name, so I stopped looking.
8:43 - Clam fixed me up with windows-ready LibFFI junk and a demo.
9:16 - Code is riddled with FFI garbage. Output is somewhat different gobbly gook in the form of a message box.
9:19 - Found the problem, fixed it. Working.

So now DLLs are working, at least with cdecl. Actually, cdecl was the one I wasn't sure how to do,  but since it's working, stdcall should be a snap.

As for days previous, I now have a working expression evaluator. There are a couple things left to do so it can support all the types. (Right now it only does int, double, and char*). I was designing it for parsing #define, but it has so many other uses that I intend to make it full-featured. (#define is a C++ macro which I will need to parse in the CFile parser I mentioned earlier. It doesn't support floating points or type casts, but I've implemented those anyway.)

If this works well, I can eventually add a couple things to that evaluator and have an interpreter for debugging purposes. It'd probably help to be able to execute new code in debug mode. And don't worry; since enigma's compiled, it'd be next to impossible to access the debug window unless the game is in debug mode. The only way it would be possible is if a very skilled programmer converted the whole game back to assembly and hand coded the new debug interface, which would be such a massive task, there isn't a person on the planet with that sort of motivation. (They'd sooner just hack your game with a disassembler while it ran.)

And don't give my post that look; there's nothing you can do to make any game totally unhackable. I'm pretty sure everyone knows that and has come to terms with it. ENIGMA just isn't particularly easy to hack, unlike *some*.

The expression evaluator is a suprisingly small 900 lines so far. The CFile parser 630; It's about half done. Still have some keywords and er.... As a general "back to the drawing board" sort of thing, I'm adding support for basically every feature C++ offers. So you won't have to use the awful ds_ functions, you'll have something easily 30x more powerful at your disposal. Not to mention structs, so you have a convenient way of storing things. Oh, and I can't live without ++, so I'm adding that as an option (default to ON). I've also added the ternary operator (a?b():c()) into the expression parser.

All these changes and additions I'm making will mean some recoding in the syntax checker as well as the parser. Shouldn't be difficult; I'm not worried.

Or at least I wasn't, then I found out C++0x supports lambda, and I didn't know what to think. Either way, I'm sure it'll be fine.

Ism has been making things compile on Linux, which was met without much incident. So things are looking bright, overall.

Anyway, I'ma get back to work.

[using]

First and foremost for those who don't catch on as quickly, we weren't really bought out by Yoyo. Come on. We don't even mean anything to them yet; we're not even on the competition radar.

ANYWAY. Due to constant bother from someone who wanted to pilfer ENIGMA's resource attachment code and for some reason couldn't use the stuff from R3, I hosted the source code.

Which means the most recent ENIGMA is available in the SVN at the sourceforge page, etc.

However, this doesn't mean that the code is operational. It's not that individual pieces don't work, it's that they have not been fitted together.

Those of you with weak constitutions and those of you who do not know C++ can skip this next part.
{
For the rest of you, I'm not going to bother posting the link to the SVN because you're probably resourceful enough to find it, and I'm not exactly enthralled to have functionless code on the intarblagz. It's like coming in one day with a rusty robot then being asked to put its severed limbs on display while you're working on them. Kinda destroys the splendor of the situation.

Nonetheless, it is hosted. I won't be checking it for updates before overwriting it, so if you have any changes to make (which, considering my code is just C++ - formatted manifestation of my ramblings and is therefore illegible, I highly doubt) please let me know here instead. Shouldn't be a problem, because I don't think any C++ programmers have SVN privileges anyway.

There's another set of files that I'm working on, which are the workings of a CFile parser. They are not hosted yet.

Rest assured, I'm good at seeing the big picture. R2 and 3 both looked like this days before their releases.
}

Okay, now for those of all or no C++ skill level, here's what's changing:

• Recoded the syntax checker to support structures. It will also support macros and namespaces. Much easier to code the second time, and I did a much better job. It's about to where it would have been originally (completion wise) at the moment, if I had not decided to support all these nice C++ things. (SVN people can feel free to test what I have, such as nested loops and statements)
  
  
• Parser will undergo minor recoding also. The main concept, structure and code flow will stay, as those were all brilliant, imo, though I will be recoding small chunks of it for the sake of optimization-- it should read through the code less than 10% as many times as the first version. (The parser is primarily find-replace. To the point where almost all of it is such, call after call. I want to write something to replace those things in mass, so I don't have to keep iterating through it)
  
  
• The macros thing is as simple as making a stack structure that behaves like a string, but has a push and pop function. Instead of just saying while (pos<len), I'll have a condition to be sure that at the end of the string I pop the stack to the next string down. It's probably what G++ does. Namespaces, I'll just keep a list of variables that exist in the global scope, and those that exist in a namespace invoked by or were themselves invoked by the using token.
  
  
• Scripts are being rethought. Instead of each object having a script, this (Pointer to current instance) will be cast to WILDCLASS (so it has all the locals for a short time) and sent to the script. This way you can still call locals like in R3, but it's more efficient for multiple variables and works in with(){} statements.
  
  
• Last, but not least, Luda has promised he'll finish recoding Colligma as soon as ENIGMA is operable. Meaning I'll hold a private release in the meantime while he's doing his thing, then give another few days of testing before the release. This is still in the future, though.
  

Some of you are mad now because I'm wasting time on a CFile parser, and you don't know why. It's because now you can #include <map> in a new resource in ENIGMA I've named "whitespace." The resource is simply a C++ script editor, which lets you define functions and classes for use in ENIGMA. (Like scripts, only still more efficient)

And finally, I am pleased to announce it is Spring Break. So I have ten days almost completely to myself to work on ENIGMA. I've tried not to complain much, but the workload is pretty big, and I'm actually enrolled in a college course at the same time as the high school ones. So things get hectic sometimes. I'm typing with my eyes closed at this moment, because I'm sorta too tired to keep them open. (Plus, this monitor is killing my eyes on its own. -.-)

That being said... I don't even know what I want from you people. Just hang in there, we're not dead yet.

Final note to SVN crawlers:
All the bugs from R3 are fixed. If you can pick out the fixed codes and patch R3 with them, feel free to hold a private release. May prove a challenge, considering... but feel free to give it a shot.
However, I don't wanna hear how poorly commented my code is, and how ill-structured it is, and how badly it abuses empty space, and how you don't find my choice of profane variable names funny. The code was released under the GPL solely to be in good spirit and ensure free-ness, not because I expect or even want your help and rude commentary.

Thank you.
Sorry if I don't sound myself, I'm pretty tired. Just figured I'd disclaim my SVN before I go to bed, and before it becomes a total train wreck.

A2h just reminded me to the fact that I never tell you people anything. I guess I'm only really good at creating mob mentalities, as far as public relations go.

Anyway, progress. Um... Whew...

I guess I'll name stuff off as it comes to me.

get_string()
get_color()
show_menu()
show_menu_ext()
show_menu_ext_nl()
clipboard_get_text()
clipboard_set_text()
clipboard_has_text()
draw_sprite_part() works now. I'll probably go over them all again and replace things.

I also never mentioned the new version works on Linux, so I guess that'd be noteworthy...

Oh right, last version didn't have game_end(), so that's in now...
Also, a lot of key systems have been and are being redone, new version allows some neater things:
1) Heredity, at your option. To my dearest cynics: it's not as easy as putting :public parentobject after the child object's name; please wake up and smell the coffee.
2) Annoying variables don't have to be there; I'm implementing a system to let you get rid of the ones no one ever uses. (And perhaps some of the ingrown ones like hspeed and vspeed-- though to remove one is to screw the link between them and direction and speed)
3) You can now replace instance ids returned by instance functions with pointers. This will have a screwy effect on room systems if you remove ID completely. Still working out some bugs.
4) I recoded the syntax checker and intend to redo a couple pieces of the parser for efficiency and further extendability; this will allow C++ users to define functions in C++ as well as structures, so you don't have to use ds_stack garbage all the time. (Not that those are implemented yet anyway)
5) A long time ago now I added a system to let you change compiler flags. This lets you strip the outputted exe, and have the compiler run optimizations on it.
6) Compile takes less than a third the time it did before, and will probably end up taking even less as more systems are redone externally.
7) Scripts and variable access have both been rethought. The new system incorporates "other", and is even more efficient than the last one. Instead of dynamically casting objects myself, I'm going to have the compiler add some functions to the class responsible for such conversions. This means slightly less ugly output code, number one, but more importantly, it means only the variable you need is given attention. It'll use an array for best efficiency of lookup time; this will cost a byte for each object for each variable accessed by means of (a).b.

There's probably more, but I'm working on a new C file parser so I can stop going through my headers manually collecting function names. Now this'll do it for me, which will put more information at the hands of the compiler.

So yeah, I have work to do, as always. To be honest, I have no idea when I'm going to release it. I've fixed all the bugs I heard about since R3, so I guess I could make a stub of a release after I wrap some more of this up, but... I guess I'll decide later. If you gripe enough, I'll prolly release it.

Oh, and we're adding the rest of the resources to the format. They're not hard to pull off. Except maybe time lines. I'm too lazy to do more code resources <_<"

...Fine, I'll do them. Leave me alone, I have work to do.


Oh right, show_menu_ext is new. I'll show ext_nl, see if you get the picture.

Code Select Expand

show_menu_ext_nl(m.x,m.y,"
Item 1
Item 2
Item 3
-
[]unchecked
[*]checked
()unradiod
(*)radiod
-
/Disabled
/Censored by Catholic Church
-
>Submenu
  Submenu Item ZOMG
  And another
  What do we have here?
  >Another SUBMENU
    Goodness gracious
    >More?
      Yes there is!
    <How about that?
  <
<First level again
-
>One more submenu
  With some more fixins
  -
  Like that separator
  /and this disabled thing");

That exact code produces this:


Also, here are the Linux shots:

Dave--
Quit undermining my authority. I'm clearly never wrong. >=[ ...haha

Also, wait. You hate ENIGMA, why are you still here?

score_under--
That would be painful.

It's not bragging if you can back it up, right?

Ism and I implemented a syntax checker. Yay. Now you can test if your code will compile (or at least, SHOULD compile) before you press the actual button, and have to go digging, yay.

Right now, Ism just displays my results in a message box. I'm hoping she makes it highlight the line soon, but that's not what I'm here to brag about.

I repeated the line
if a do if a=0 b=0 else c=d  until x=0 else d=e f=0.1
about 2800 times, followed by
a b
at the very end.

I ran syntax check in LGM. Finished in about 3.3 seconds.
I then ran the same code through... another program that some of you may be familiar with. It took about 15.1 seconds.

So I am in a pretty decent mood, considering that even accounting for the overhead from passing files back and forth between ENIGMA and LGM, we're still outperforming other editors by... a lot.

With less nested things, the times are closer. Like 2 seconds vs 2.5. But ENIGMA's always ahead.

I guess that's the beauty of not generating a token tree every time you need to check syntax.

Also, ENIGMA not only gives line number, but an absolute index.
Say you have draw_line(1,2,3,4,5,6,7). It'll return the position of the comma following the 4. That way it's less confusing. I want Ism to highlight that, too, but again, we'll see.

Anyway, I'm tired. It's like... Not Saturday anymore. Gnight.

Figured I should say Merry Christmas.

Todo:
- Go through and replace all return 0; with return ENIGMA_VOIDVAL and all worthless int functions with ENIGMA_VOID
- Make all worthless doubles into ENIGMA_INTVAL (for less memory waste and easier transition to C++)
- Make rooms force performance of creation codes later, and to save an if() check in ctor, move create() from end of constructor to end of instance_create()
- Go back and redo draw_primitive_() (they're pretty terrible)
- Make sure sprites are optimized (they use map, God help us)
- Take care of vsync (that's the reason your framerate is 60)
- Fix window caption if it doesn't fix itself (it's liable to)
- Make sure going to different rooms works (I prolly broke that at some point, had a problem with creating two instances of some things)
- Add sprite_set_alpha_from_sprite() (had multiple requests for it, and it's easy)
- Allow using draw buffer as texture (Possible without framebuffer extension? With it?)
- Check alarm events, add collision events, add/fix/redo "other" (depending on what pieces of it I have. I want all this good stuff in asap)

This is all in addition to what I'm doing now, which is composing an interchangeable system for instance tracking, depending on the functions you use.

I'm thinking of having quite a few options, actually, including these:
instance storage:
- keeping instances listed in one big array
- keeping instances in a standard linked list (for games with lots of destroying but not a lot of instance_ functions)
- keeping instances in a map (long standing method)
depth tracking:
- keeping depth in a linked list (for games with two or three depths. Or like, less than ten.)
- keeping depth in a map (for those who say depth=-y)
- no depth (gonna be as big a pain to undo, but I'd like it as an option)
instance reference:
- id is an integer used for finding instances (slow like GM)
- id is an integer representation of the C++ keyword `this', and can be used for instant lookup (fast and hazardous)
- id doesn't exist; only `this' is used (plum crazy for our purposes, but it's efficient)

As for what's already done, I'm too lazy to list that. And it's Christmas. At 10 PM. So even though I had some good news a month ago that I still haven't shared... I'll just build up some things to throw at you all.
As for what I'm planning for bigger and better releases, that's subject to change as well as to hard criticism. Plus it's all totally unrealistic anyway, right? (Just like Build Mode, and, well, the entire rest of the ENIGMA project.) So I think I'll just say nothing on that, as usual.

Anyway, good night all, and Merry Christmas.

I can't decide what to do next, actually.

I made a system that implements depth. The system can have a few different options, each of which has some unappealing drawback, I'm sure.

What I was going to go with was a red-black tree, just like STL uses in their map. (I may break down and just use STL, depending on how angry I am at them when I wake up tomorrow.)

What I designed the system with originally had no conventional sorting method.

Let me explain.

Instances were just added to a standard linked list for simplicity of working with them.
Then I have a list of event types, which point to a list of depths, which point to both a start and end position on a list of instance pointers. The instance pointers will have their corresponding event accessed.

This was so if you had 10,000 instances, three of which had a step event, ENIGMA would execute only the step events of those three.

I believe this is what "other software" does, so I guess I really had no choice.

Okay, now that I typed a page of exposition, here's the breakdown.

Positive: The nodes on the depth list point to the right points on the list of instances with each event just fine. There is no need to change the instance-event list.
Problem 1: The depths are accessed simply by iterating through the list until you find the right depth. So for those of you who say depth=-y, you may just run into a speed problem. (Nothing major, I promise, but it could still be a few milliseconds faster per call. Big deal, ha?)
Problem 2: The reason I'm mad at STL is because "other software" defies the laws of C++ and 'proper coding.' Meaning that when you say instance_destroy(), STL cries, cuz I'd have to delete an instance that God knows how many iterators are pointing at. (There actually should be just one, but I'd feel icky about just moving the iterator so I could defile the map) Knowing this, if I don't do anything, and just delete the instance from the map, the game will crash.

What I did in my tests was just 'orphan' the node. It's a term I coined for unlinking it, then deleting it after all iterations are complete. (At the very, very end of the step, when framerate is calculated, etc)

So yeah, I'm in a pickle.

Really smart people: Gimme suggestions
Everyone else: Just keep in mind I'm fussing over milliseconds here, and don't go whining "zomg enigmaare vap0rawre!11!"

Final thought:
If you post another newspost over my important questions and announcements, a2h, I will poke you with a VERY sharp stick. >=[[ And the new forum look sucks so I'd 'preciate it if you fixed that please and thank you. :3

As some of you fantasize in your over-idealistic views of ENIGMA, I'm doing my very best to make sure ENIGMA runs as efficiently as possible.

It's always a tear between memory and speed: with enough memory, you can make anything efficient.

Anyway, it's been trial and error. Here's an example of error:

Sprites, to date, have been kept in an std::map for storage. This way, if you have 2 sprites with sprite id's of 64 and 256, you only store two sprites worth of memory. That's a best-case scenario, though.
More often, you have some 8 sprites, all in order, and the lookup time for each sprite totally outweighs the benefit.

Other times you have a slower system that makes error reporting possible. Like when you try to create a nonexisting object, you get a friendly reminder that it doesn't exist.

So from now on, here's how it's going to be:
Everything in ENIGMA is going to be well oiled, but if you, say, request a non-existing sprite, the game will just die. No errors, no nothing. To get the errors, you will have to run the game in debug mode, in which the game will run far less efficiently, but will report any such silly errors.

This way, your end result will be a much, much faster game, but will be expected to have basically no errors at all.
(Honestly, would you release a game that still had errors in it?)

So let me put it simply.
If I do this, the end result will likely be around 10x faster, give or take. However, If an error would result in a segmentation fault, (C++ terminology for 'nasty error caused by memory access violations that kills the program without warning') your game will end without displaying any error messages or anything. (See list below for typical errors)
This harsh reaction, however, will only apply in release mode; debug mode will report any such errors and continue to run the game.

So if you're developing the game, you should be running it in debug mode pretty much the whole time, using build/run mode only after all the errors are out, either to verify final speed or to edit your rooms.

I'd like to know if you feel it'd be worth it. I know I do, but I guess it's only fair to tell you before I implement it.

List of typical errors:

• Accessing an undefined sprite: Fatal, debug mode will report it
  
• Accessing an undefined script: Will error at compile time
  
• Accessing any other undefined resource: Fatal, debug mode will report it
  
• Going past an array limit in a VAR: Not fatal, don't think debug mode will report it though
  
• Going past an array limit with pointers: Just fatal. It's a C++ thing.
  
• Division by zero: Fatal, debug mode will report it in var, cannot report it with int/double/etc
  
• Nonexisting variable: Totally impossible, may implement something to track that
  

So in comparison, debug mode will be lagtastic. But it'll still be fast enough, and it'll help you get all the errors out.
I'll see what I can do as far as debugging certain things at once goes.

The system will take a lot more work, and of course space, but hopefully it gets the job done.

Send me your thoughts.

-Josh

Just so you people know I'm still alive.

I've fixed a lot since R3. You'll find basically all of this on the todo page, but since many aren't aware it exists, I'm posting it here.

• I redid pretty much everything and remade the syntax file (fnames.txt). And by redid everything, I mean I went over all the code and made corrections, minor, optimizational, or otherwise.
• draw_text no longer messes up the projection.
• Variables declared in scripts now work in any object that runs the script
• room_restart() and game_end() are now implemented. I also added room_next() and room_previous(), though it should be noted room errors in enigma are not fatal. (Division by zero, however, is VERY fatal. Don't divide by zero, ...<_<
• WILDCLASS now uses pointer-to-pointer-to types. Any kind of variable can now be referenced between objects.
• The script-path tracer is fixed, scripts are totally fine now.
• The parser's treating of typenames and casts is now fixed. The system makes a lot of assumptions that my thinking suggests are safe bets 100% of the time. In case of any compile errors in the upcoming release, PLEASE inform me.
• Array indexes involving arithmetic now work. What a sad glitch I had missed.
• The window resizes as room changes.
• Room background color is no longer inverted.
• Decimals with no preceding whole integer work again.
• Window functions now actually work. I just never bothered to test them before R3.
• Build mode will no longer freeze if either of the grid dimensions is set to zero.
• Friction is now accurate.
• Sprite indexes are now initialized properly.
• Views work 100% now.
• keyboard_check... and mouse_check... now use correct types.
• Instances that skipped an id number are no longer created twice.

I also have a special surprise in store, of which I'm sure a few of you are already aware. You'll be hearing about it quite soon.

As one last thing, ENIGMA R3b shouldn't be very long either. I'm mostly waiting for Luda to finish Colligma while going back and fixing errors, at this point.

What I'm currently working on:
- Redoing instances to fix a potential problem with rooms, as well as implement depth
- Working with create events and destroy events to avoid more problems with rooms

What I've recently done:
- Added something called PCS, or "Pre/Post-compile script", which will allow you to pass parameters to GCC as well as execute functions on the exe before resources are added. This will really help with filesize and speed.

Cheers.

So I fixed a lot of the surprise errors from yesterday. The important part is that it held up to basics and showed the improvements to the compilation process. There are still improvements to be made regarding the size and speed of compile.

For now, however, you can download a patch which fixes several errors, including object. and global., as well as transparency. There are a few more fixes to be made, but that will be done as we are able.

Also, place_free checks solidity now. LGM may have a problem conveying an object's solidity, so place solid=1; in the create event until that is resolved.

An automatic updater is planned, and in progress, but isn't available quite yet.

Download the Patch

Well, I can say with some certainty that I've never released something just right the first time, in my entire life.

However, bare with us. At the last minute, we noticed a few things that weren't working, and scrambled to make them do so. This kind of thing generally leads to more mess.

I don't want to spend much time preaching about it, however, tomorrow a patch will be released to fix the majority of the known problems. You'll notice that ENIGMA-R2 has an a at the end. This is because it took me five minutes to realize I'd done something wrong there and reupload.

Tomorrow I'll sort out some of the rest of the stuff. The worst of it includes some borkage with place_free, an explanation for which can be found here:
http://edc.enigma-dev.org/index.php?p=blog&id=33

draw_text will hopefully be reimplemented, global. and object. will work again, and the world will be happy.
All of these, along with LGM's importation of build mode edits, were broken without anyone realizing it. This kind of thing is forgivable with such a huge project, right?

The version you have now is still somewhat usable, but tomorrow we'll patch the holes.

(Disclaimer: I could be lying)

Note: Some of you may have found that you downloaded R2 from SourceForge. We apologize. I'm not telling you whose fault that is, so THERE.

Anyway, I haven't slept in two days. Which probably doesn't help the disorder, so if you'll forgive me, I'm going to try that.

I had a request for the executables that were used in the making of that movie.
Here they are, as zip:
Download