Anaphase

[RetroX]

I still don't understand the point of using Java ever.

It's "cross-platform," but so is C/C++ with wxwidgets. :/

[IsmAvatar]

In Java's context, cross-platform means not having to recompile for every platform. Not to mention, the language is much simpler for higher level purposes such as GUI and string handling.

[retep998]

I just finished attending Easter liturgy for 6 hours, from 9 PM to 3 AM.
It'll be nice to have Enigma for Easter!
Christ is Risen!

[IsmAvatar]

Just because you said that, now Enigma's never going to be released.

[luiscubal]

@RetroX
Once you use Java and C#, you'll barely see the point of going back to C++.
Java and C# are/have, unlike C++:
 - Better working environments: OO programming and lack of preprocessor makes writing IDEs far easier, and autocompletion is more relevant.
 - Consistent APIs. In C you have no core library. You have a "standard" library which isn't exactly implemented the same way by everyone and then you need third-party libraries for anything that matters. Sometimes I'm frustrated by lack of library functionality in Java and C#, but this is nowhere as bad as C(++)'s problem.
 - Garbage collection. C's static allocation is good when it works, but it's not always enough so you have to use malloc/free eventually, which are pain to handle. C++ added lots of features that make pointers easier to handle, such as T& pointers, but the problems remain. In Java and C#, it *just* works. No memory leaks. C++ wasn't designed for garbage collection, so C++ GCs are always ugly, imperfect and/or inefficient.
 - It just works. No segfaults. In C, you have weird errors. You have to compile again in debug mode, try to reproduce the error and use gdb to have some chance of finding the problem. In Java and C#, you get an exception, which points you to exact file, class, function and line where the error is. When it crashes without warning it is typically because of C parts(JNI/JNA).
 - Good enough runtime speed. Aside from some GUI slowness which is a library rather than a language problem, Java and C# are fast enough for most purposes. In many cases, they can match C's speed thanks to Just-In-Time compilation(Java and C# are typically *NOT* interpreted languages)
 - Compilation of "real projects" takes some minutes, as opposed to several hours in C++.
 - Great languages, although C# is technically superior to Java, both are much less frustrating than C++. In Java, I can just write xyz.replaceAll("\n", "\n\t"). The equivalent is much more painful in C, and better but still annoying in C++. Not to mention that regular expressions are available if you need them, without needing to go fetch some weird libraries and check if they work on your compiler.

I think I made my point. For games, I admit C++ may be a good idea, since audio is simply disgusting in Java and C#. C++ lacks audio support, but you can use SDL/SFML to add it.

[freezway]

@11th:
yeah that would be helpful.

[Josh @ Dreamland]

Indeed, I am on Ubuntu.
Ism is also presently on Ubuntu.
I run 9.04, Ism 9.10.

I've not seen Luda today. Easter festivities are underway here, presumably where Luda is, too. Happy Easter, everyone. A lot of trinkets hinge on further teamwork, but I can at least give you all something that compiles under the new system to promote development.

Something will be released today. What all it can do... I can't presently determine.

[RetroX]

- Better working environments: OO programming and lack of preprocessor makes writing IDEs far easier, and autocompletion is more relevant.

I don't understand how this is a conceivable argument at all.  Object-Oriented programming is, well, in some cases, good, but in other cases, like Java, really bad.  Instantiating classes and creating classes uses memory, which is... well, extremely inefficient at best.  And don't give me any optimization crap, because I know that Java does none of that.  IDEs are language-independent.

- Consistent APIs. In C you have no core library. You have a "standard" library which isn't exactly implemented the same way by everyone and then you need third-party libraries for anything that matters. Sometimes I'm frustrated by lack of library functionality in Java and C#, but this is nowhere as bad as C(++)'s problem.

The point of C++ is that there is no API.  You get to do whatever that you want.  If you want a standard API, you can make one, and tell everyone to use that.  That's essentially what Java and C# are, however, it forces you to use that API.

- Garbage collection. C's static allocation is good when it works, but it's not always enough so you have to use malloc/free eventually, which are pain to handle. C++ added lots of features that make pointers easier to handle, such as T& pointers, but the problems remain. In Java and C#, it *just* works. No memory leaks. C++ wasn't designed for garbage collection, so C++ GCs are always ugly, imperfect and/or inefficient.

See the above.  You can't use the argument that "when things are made in Java, they just 'happen' to be better."

- It just works. No segfaults. In C, you have weird errors. You have to compile again in debug mode, try to reproduce the error and use gdb to have some chance of finding the problem. In Java and C#, you get an exception, which points you to exact file, class, function and line where the error is. When it crashes without warning it is typically because of C parts(JNI/JNA).

See above.  Additionally, debuggers use loads of space, and slow-down the program.  If you want a debugger, make one.  It should not be required.

- Good enough runtime speed. Aside from some GUI slowness which is a library rather than a language problem, Java and C# are fast enough for most purposes. In many cases, they can match C's speed thanks to Just-In-Time compilation(Java and C# are typically *NOT* interpreted languages)

You can't just say that "it's good enough, so, on a good computer, you won't notice the difference."  I've always seen a significant gap in speed between Java and C/C++.

- Compilation of "real projects" takes some minutes, as opposed to several hours in C++.

It's always been the same to me.  Even on older computers.

- Great languages, although C# is technically superior to Java, both are much less frustrating than C++. In Java, I can just write xyz.replaceAll("\n", "\n\t"). The equivalent is much more painful in C, and better but still annoying in C++. Not to mention that regular expressions are available if you need them, without needing to go fetch some weird libraries and check if they work on your compiler.

"I just like Java better."

[MrJackSparrow2]

I love you RetroX.
Mr. Dreamland I am VERY excited for Enigma! Release, release, release!

[Josh @ Dreamland]

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.

[MrJackSparrow2]

Hey I've got a question. The iPhone/iPod/iPad OS is technically Unix based if I understand it properly. I do know it happens to use OpenGL rendering. Now, how much porting would be necessary to be able to compile an iApp? (Gay ass Apple and their "i" prefixes. >_>)
Anyway, basically is it too much work to even consider writing a port for the iOS?

We could call it iPlugin for iEnigma to make iGames. I would click the magic iCompile and go!

(Seriously though is this even a possible consideration? Of course you'd probably need a jail broken iDevice.)

[freezway]

.... put that as LOW priority. Josh: as of now what works? what doesnt? what works if u say the magic word and do a dance and beg?

[MrJackSparrow2]

Sorry for the double post. I'm sort of disappointed to hear more delays. However I agree a jar ran from a console every time would be an inconvient pain in the asshole. I really wish that I knew java (eww) or C++ so I could help. Until then, good luck Josh and Ism.


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?

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


@freezway: Of course extremely low priority! I'm just thinking some day.

[Josh @ Dreamland]

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.

[MrJackSparrow2]

Yea I've heard about Apples AWESOME SDK! Totally small only weighing a mere 400 megs or so. Also available for the BEST and GREATEST OS! [/dry Apple bashing sarcasm.]

That's why I said jailbreak the device, hopefully getting around that.

I'm also glad to hear I'll get to see the C++! I'm learning classes and pointers/references. Real basic stuff. I want to eventually only program in C++ with the effiency I program in GML. Also good to hear about the lib files.

Also, ironically enough, the last 3 messages I wrote were from my iPod Touch. Damn hypocracy.