"You can write a code editor in a day?"
Welcome to not-GML.

"Also, what's so wrong with our code editor anyways?"
Can't drag text, no line numbers,... does tab increase all selected area's indent? *checks* Nope, it replaces selected text with a tab. No semblance of intelligent indentation, for better or for worse. Only highlights parentheses to the right of mouse instead of both sides, left having precedence. Incorrectly highlights multiple aspects of GML, most aspects of C. Doesn't highlight literals of any kind. Inextensible for syntax check purposes, or most other purposes.

Quite a bit. ENIGMA finally stops segfaulting if it fails to load, as Ism just stops calling it if it returns nonzero. LGM will only show ENIGMA if it succeeds.
Also, it now works from platform to platform, right off the bat, provided only that it can find a version of the GCC. If it can't, Ism will ask for it.
I'm not sure about including JNA with the repository; I've no idea on its license (though I can't imagine it would forbid doing so), and Ism didn't include it...

If you check out the SVN and run a game with ENIGMA, right now, it will write all the files needed for compile, but it won't call GCC as I'm swapping out R3's system for Make. Furthermore, I'm swapping out R3's variable initializer for a less dated equivalent; this one will more accurately detect scoping now that we're mostly C++ compliant. The SVN repo will make you declare your variables until I keep track of used, undeclared ones as well as the declared ones. (This will be fixed first, probably).

Ism doesn't yet keep track of whitespace. She'll be working on that. LGM's code editor sucks. I'll be taking an attempt at coding a better one today, I believe.

Waiting for a thread to finish loading something is going to be risky.
I can't think of a good way to do it faster in GML... Threads will have to work for now.

A[100]=0 isn't anything special.

In GM, a map is used for array indexes, as far as I can discern.
A[100] creates a single new node in the map, and does some rearranging to improve lookup time later.

In ENIGMA, A[100] = 0 will in fact /allocate/ an array of that size for you to use, and will set the 100th element to zero.

I was considering adding a var::drop() or array_free(var& x) to take care of that in ENIGMA.
As far as I know, you can't deallocate an array in GM, except temporaries. Which are automatically freed at the end of the code.

Ah. Disk size. Now fix my 30 dollar / mo 100 KB / sec internet connection.
Also, I'm sure Australians aren't happy, considering their bandwidth usage is metered. They are capped in speed if they go over a certain limit.

Rusky--
Yes, everyone that's done any real C knows that. What I was getting at is that Java likely lacks a way to specify which variables you would like to remain in the registers, as C/C++ does. I find it likely that Java lacks such a flag, seeing that it doesn't even have "unsigned."

Game_boy:
You pretty much ARE me, then. I also hate basically all lyrics. Those first two songs... I love them. Ever listen to any OC Remixes?

"(such as register allocation)"
I know Java lacks "unsigned," but I figure Java programmers would know about flags such as that and "register," which, as you say, 'allocates' a register. Not in Visual Studio, of course, as Microsoft shares the new philosophy that some day, computers will be able to run Windows 7 and Crisis! By that point in time, a typical programmer won't even need to know what a register is, or deal with nasty, old C++. Unless they intend to program for something other than the PC.

I see people comparing the Java-C++ relationship to that of C++-assembly. The difference seems to be that in C++, I can say asm("") to get to a faster language. In Java, you're pretty much stuck with what you have. Getting ENIGMA, as a DLL, to work with LateralGM has been one of the most tedious processes I've ever undergone while programming. The only worse experience was in GML, where I'm never sure if it's an error or if I'm truly missing something (twice out of three it's proven to be the former; the third time was inconclusive). But that's neither here nor there.

I am reasonably certain that everyone in this topic is aware of the concept of JIT compilation. It offers a lot of neat tricks. The problem is, it requires a large runtime that isn't necessarily portable to all systems.

High, high level scripting languages (GML is NOT in this group; GML offers so amazingly little that it isn't funny), I'm talking mostly about Python and Haskell, maybe even Lua (though I'm not aware of the particulars of that language), are relatively easy to embed in a C++-compiled program. By relatively, I mean easily done with a good library. Granted, true interface is difficult, but small-scale embedding is just not that hard to pull off. My best example is JavaScript via V8, hence me considering using it for the interpreter. V8 seamlessly integrates the two languages; I can call JavaScript from C++; the JavaScript can call C++ methods and functions. And it's JIT compiled, which means it has amazing speed relative to regular, interpreted versions.

"Proving all indexes to be in-bounds at compile-time is perfectly possible."
Given a large number of conditions are met, sure.

"C++ is the best PERIOD"
Don't put words in my mouth. C++ is the best for me.

R1 used templates for parameters for a while. I thought it was a great idea at the time, praised Dylan for it... It's a terrible idea in retrospect.

"It's that cplusplus.com has a terrible way of explaining them."
This is what I was thinking. Hopefully using them in ENIGMA breaks down the disoriented feeling you get when working with C++ for the first time. This way, you don't have to cope with the loss of knowledge of all the language's functions.

Thanks for understanding, guys. Does mean a lot.
freezway: I promise.

MrJackSparrow2:
I believe you're right that the iPhone is some sort of Unix. If nothing else, I know C++ is an option on it. If the iPhone has its own GCC, porting will be basically effortless. However, acquiring the API will be tedious for not only me, but users. Apple requires licenses and multiple-hundred-megabyte downloads to develop anything.

Too much work to port? Nah. To acquire? Possibly. It is something I would like to see happen. I'd say the odds are better than XBox 360, but I lack the info to make an educated guess on how that will turn out.

Freezway:
None of the UI tricks from R3 work. I'm unsure of with() and (a).b's standings following this last edit. What does work is finding the GCC, parsing the ENIGMA engine (this is the HUGE accomplishment of R4) parsing... local? Seems to work now; conducting further testing as we speak. Collision system is a no until it stops being "barf." Ism's status is "I can't really think right now. Ask me again tomorrow or something," meaning successful output redirection (as in R4) is not happening tonight. I have been putting off projects and homework for the last week working, so I need to allocate three hours or so tomorrow to the cause. Compiling a basic game has worked off and on as I made fundamental changes in structure for the sake of organization and faster compile. Organization is in preparation for more easily replaced systems (particularly the window system, which will change constantly from platform to platform). Distinguishing that version works, thanks to locating the GCC (which also works, as mentioned above).

Oh Josh, how will files and such work? I am eagerly learning C++. Will I be able to see the output files? I'm sure it will look like shit due to parsing taking out syntax tabbing but I'll live. Is this a possibility; seeing the C++ before it compiles?

You can look at all the object code you want by going to the Preprocessor_Environment_Editable/ folder and looking at the sources therein. You'll want IDE_EDIT_object*.cpp. The code will be missing comments from the original GML, but will be decently well-structured and possible auto-commented.

Also, I don't know C++ very well, but I think I heard you can compile sort of "engines" into lib files I think. Could we possibly make a lib for the collision system to cut compile time? I'm sorry if I got this completely wrong, as I said I'm a damn n00b with C++.

Presently the majority of the engine is left in unlinked object files to save time. Linking them into one big engine file could possibly save more time, and has been a consideration for some time. I have no figures. But yes, that's a good idea and is worth looking into.

I'm trying, I'm trying. I really am. But every time I make some kind of progress with ENIGMA, the Java end is one step further behind. At present we can't even display compiler output, so if we don't get it corrected, users will have to run the jar from the terminal every time, and that's really annoying. (At least to me.)

Plus, I'd then have to convey that to everyone.
All syntax check output is also terminal-only; Ism is going to add a status bar, but I don't know when...

I've been doing my own debugging and am still finding enough small problems to not justify asking anyone else for them. Really, I'm better off waiting, I've decided... It pains me to do so, especially after how promising it looked even hours ago, but I keep just assuming that all the communication and such will just go smoothly one of these revisions. Luda calls me a relentless optimist.

In the last five days, ENIGMA's revision cound has approximately doubled. We have gone through more than 50 of them; each time I commit something, Ism adds something, and vice-versa. It's a seemingly never-ending cycle; the good news is that it means progress every iteration.

Those who check out the SVN repo can probably compile themselves a working version, and in fact, would probably be better off. I've not recently checked for what files are missing, but will probably do that shortly. If all the files are there, it will work. If some are missing or out of date, the compile may fail, or the project may just not work without warning. That's what we're looking at right now until we can get some real ground laid.

Luda describes the current state of Colligma as vomit, or something like that I think his wording contained "barf." Needless to say, it's not exactly plug-and-play material.

Really, I'm hoping serp will step back in and just do something I'm afraid to; like release a program that can't convey its own syntax check information.