ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on April 02, 2010, 11:50:10 PM

Title: Anaphase
Post by: Josh @ Dreamland on April 02, 2010, 11:50:10 PM
If I release it now, it'll be missing some things I think can be in not long into tomorrow. One of those is Linux support, which I don't want to throw out a release without ensuring: Number one, Linux has proven to be much more strict about what is used and included, and number two, wouldn't really be fair to freezeway, now, would it?

Also, it seems likely that given just a little more time, we can have the collision system hooked up and iterating. Luda has rotated rectangles basically good to go; he can develop the rest of the system during the test phase, but the framework would be nice to have laid out.

As for the aforementioned Linux progress, we can't actually compile it on Linux at present due to some case labels skipping initializations, which Windows didn't even notice for some reason...

I'm quite tired. A lot of work went into the engine just today, but there's no sweeter payoff than seeing the system working again. It's a beautiful sort of thing.

I imagine everyone will understand the decision to prolong the release again; one of my bigger fears is immediate mediocrity. (Did I mention the syntax check button once again doesn't do anything? :P It spent most of R3 like that... I won't let it for R4).

This doesn't change the amazingly close proximity of the test. Besides, I had to squeeze anaphase in here somewhere.

While Luda and Ism are busying themselves with the aforementioned provisions, I will get started on other resources that R3 didn't have. So who knows what you'll be seeing; hopefully perfected features from R3 and a simple collisions system.
Title: Re: Anaphase
Post by: freezway on April 03, 2010, 12:01:49 AM
=). thanks! btw, not to pick nits, but its freezway (no 3rd e). I think it should be released when this is reasonably ready, I personally think this project will draw a huge linux crowd just because there is no GM for linux.
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 03, 2010, 01:09:36 AM
I saw Anaphase and got all excited... Damn, oh well. I'm very anxious for this Josh. :)
Title: Re: Anaphase
Post by: kkg on April 03, 2010, 07:19:47 AM
It's all good dude, I'm sure we'd much rather point out the more hidden floors than continuously posting the ones you already have knowledge about :)

It gives us more time to flex our "how-to-replicate-the-bug-we-found" fingers ;)

Keep it up mates ^_^

Edit: as you can tell I'm a professional speller T_T flaws***
Title: Re: Anaphase
Post by: score_under on April 03, 2010, 07:26:28 AM
It's all good dude, I'm sure we'd much rather point out the more hidden floors than continuously posting the ones you already have knowledge about :)

It gives us more time to flex our "how-to-replicate-the-bug-we-found" fingers ;)

Keep it up mates ^_^
(http://images.icanhascheezburger.com/completestore/2008/9/27/128670320998849909.jpg)
He's actually belly-sliding on one of your "hidden floors" which you would rather have pointed out.

Hint: Flaws. :p
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 03, 2010, 08:09:48 AM
Thanks for understanding. Was hoping you wouldn't get mad. ^_^"
I just think we've a lot to gain if we wait on a couple more features that will make all the difference. I've not yet seen Luda or Ism, so I'll be working to improve the engine. I'll post small things I do here.

- Modified code that prints each object's constructor in such a way that object_set_sprite() will minutely lower efficiency, but will integrate smoothly. Sprite indexes are hard-coded into the constructor if object_set_sprite() is never called.
Title: Re: Anaphase
Post by: Fede-lasse on April 03, 2010, 10:56:24 AM
Why not just post such small updates on SVN, or whatever you're using?
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 03, 2010, 01:54:41 PM
Through effort and patience, mostly on my uncle's part, my Linux box is back up and running.
ENIGMA R4 should be ready for Windows and Linux upon its release.

-Fixed local and global's behavior when treated as an integer rather than a keyword
Title: Re: Anaphase
Post by: jimmyjames on April 03, 2010, 02:39:39 PM
Though I visit everyday, I don't post very much. But I really felt the need to relay my excitement   ;D
Title: Re: Anaphase
Post by: retep998 on April 03, 2010, 03:18:48 PM
YAY ENIGMA
 :dance:
Title: Re: Anaphase
Post by: RetroX on April 03, 2010, 07:39:51 PM
As I said, I'm correcting you.  GNU/Linux.  Tired is not an excuse.
Title: Re: Anaphase
Post by: Grundoko on April 03, 2010, 08:06:04 PM
As someone who has been a Windows/Linux Mint dual booter for almost a year, and has just completely removed Windows in favor of Linux Mint, I'd love to see Linux compatability on Enigma.

There's no rush, I think we're all willing to wait a bit longer and let enigma cook properly. The last thing we want is for it to come out all soggy and wet! When it comes out, it should have a nice crunch to it.
Title: Re: Anaphase
Post by: freezway on April 03, 2010, 08:35:05 PM
it would be awesome if enigma could reach GM's functionality (be fully backwards compatible) by 2nd semester next year..
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 03, 2010, 08:41:26 PM
Depending on execute_string, that may be a distinct possibility. This is still the "hard part." After this, it should be smooth sailing. Of course, alternative collision engines will give just as much hassle, minus the fact that they will be done. >_<
I don't blame luda; he didn't have near enough time. But this is dragsome. I think I'll put a cap on what I'm doing and release something small...
Title: Re: Anaphase
Post by: freezway on April 03, 2010, 09:06:13 PM
thats great.... i wouldn't put execute_string() at too high a priority, its not used much... and bad coding to use it.
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 03, 2010, 09:14:11 PM
Indeed. We tried making the syntax checker free of R3's file-pass method. It looked like this:

Checkpoint 1. Script count 85858264, address 0x51e1b98
  Script 0 is named
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

's a pretty long script name.
Title: Re: Anaphase
Post by: RetroX on April 03, 2010, 09:59:41 PM
I'm assuming that we'll be able to disable execute_string to cut on file size?
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 03, 2010, 10:02:10 PM
Sweet Christmas, yes. I couldn't even conceive otherwise with a clean conscience. That function ruins EVERYTHING.

-Syntax check fails to report the error, but completes successfully.
-Output redirection is still a no-go.
Should I release?
Title: Re: Anaphase
Post by: freezway on April 03, 2010, 10:03:53 PM
output redirection? also, i assume it works with linux?
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 03, 2010, 10:09:43 PM
Freezway-
I'm typing from my Linux box now. Works exactly as well on Linux as on Windows. I word it that way because this isn't my standard of "working" on either platform. Ism is adding a status bar to display line number and syntax error string... I offered to recode a textbox for her if she got this ready for release. I'm not sure when to stop adding features and just release the thing... I wanted the UI to be comfortable at least...

I'm torn. I met my date to the best of my ability, and the Java-C++ communication is still in pieces. So I figure I'll just sit here asking what to do while I work. XD
Title: Re: Anaphase
Post by: freezway on April 03, 2010, 11:03:56 PM
i say have it out before 5:00 PM pacific time!
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 03, 2010, 11:14:31 PM
On Easter, you mean?
Can strive for.
Title: Re: Anaphase
Post by: freezway on April 03, 2010, 11:17:06 PM
oh yeah i forgot 2morro is easter!
Title: Re: Anaphase
Post by: Stevenup7002 on April 03, 2010, 11:22:42 PM
Glad to hear the project is progressing well  :). Good work guys.
Title: Re: Anaphase
Post by: Grundoko on April 03, 2010, 11:28:46 PM
Releasing on Easter is what all true warriors strive for mah boi
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 04, 2010, 12:09:41 AM
That will be epic in sufficient proportions. ^_^
Title: Re: Anaphase
Post by: Grundoko on April 04, 2010, 02:14:38 AM
Purely out of curiosity, what Linux Distro do you use?
Title: Re: Anaphase
Post by: notachair on April 04, 2010, 02:50:13 AM
Purely out of curiosity, what Linux Distro do you use?
I think he uses Ubuntu
Title: Re: Anaphase
Post by: luiscubal on April 04, 2010, 05:48:22 AM
Focus on free GM compatibility first, and only then go after the Pro features.
Title: Re: Anaphase
Post by: The 11th plague of Egypt on April 04, 2010, 05:56:41 AM
Having a nice program is a necessary but not sufficient condition for a good release.

Before releasing you need to:
- have a working bug-tracker, something we can understand
- write some documentation, at least a changelog describing what works and what not
- tell us what needs to be tested, and how we can help
Title: Re: Anaphase
Post by: RetroX on April 04, 2010, 09:24:13 AM
I still don't understand the point of using Java ever.

It's "cross-platform," but so is C/C++ with wxwidgets. :/
Title: Re: Anaphase
Post by: IsmAvatar on April 04, 2010, 09:45:29 AM
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.
Title: Re: Anaphase
Post by: retep998 on April 04, 2010, 10:37:10 AM
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!
Title: Re: Anaphase
Post by: IsmAvatar on April 04, 2010, 10:57:12 AM
Just because you said that, now Enigma's never going to be released.
Title: Re: Anaphase
Post by: luiscubal on April 04, 2010, 11:06:09 AM
@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.
Title: Re: Anaphase
Post by: freezway on April 04, 2010, 11:55:12 AM
@11th:
yeah that would be helpful.
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 04, 2010, 02:10:10 PM
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.
Title: Re: Anaphase
Post by: RetroX on April 04, 2010, 04:40:33 PM
- 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.

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

Quote
- 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."

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

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

Quote
- 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."
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 04, 2010, 07:34:46 PM
I love you RetroX.
Mr. Dreamland I am VERY excited for Enigma! Release, release, release!
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 04, 2010, 10:41:23 PM
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.
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 04, 2010, 10:44:55 PM
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.)
Title: Re: Anaphase
Post by: freezway on April 04, 2010, 10:49:47 PM
.... 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?
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 04, 2010, 10:55:42 PM
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. :P

Title: Re: Anaphase
Post by: Josh @ Dreamland on April 04, 2010, 11:37:08 PM
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).


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

Quote
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.
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 04, 2010, 11:47:11 PM
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.
Title: Re: Anaphase
Post by: Grundoko on April 05, 2010, 02:36:31 AM
I'd much rather see it put to making Android apps, as Android is Linux based, and I hate Apple's products, mainly because of how closed they are.
Too bad Android apps use Java, and not C++
Title: Re: Anaphase
Post by: The 11th plague of Egypt on April 05, 2010, 02:51:22 AM
People relax and let him work. We don't want all this excitement to stress his life.

Good luck with the release. I'll wait.
Title: Re: Anaphase
Post by: Grundoko on April 05, 2010, 03:26:16 AM
Meh, this is the internet. We can worry about his life as little as needed.
Josh, finish Enigma R4. Sleep is not a priority >: (

But seriously, take your time, we can wait.
Title: Re: Anaphase
Post by: luiscubal on April 05, 2010, 04:12:15 AM
- 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.
No, they are not. IDEs are VERY language dependent.
In C, for instance, you had no namespaces, so all functions were in the global scope. Therefore, pressing Ctrl+Space would put lots of useless junk, and some times omit the things that matter.
In C++, namespaces and classes made this *a bit* better, but it's still essentially the same crap. C++'s #includes are less IDE-friendly than Java's imports.

Quote
Quote
- 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.
At least the API is *consistent*. You rarely need just a single API. And, when you do need two C++ APIs to interop, you've got trouble, because they just don't. No matter what you say, you always need an API unless you're writing a kernel. So C is very good for kernels, but usually sucks for everything else. Everything uses java.lang.String, and java.util.List. Of course, C++ has the C interop thing, so it has an unfair disadvantage due to C strings and arrays(which are computer-friendly but definitively not programmer-friendly).

Quote
Quote
- 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."
I can't? Since when? Oh, and "see the above", you can't use any argument that disagrees with me. Why, you may ask? Oh, for no particular reason, but since you can dismiss arguments by just pretending they don't exist I figured I could do the same.

Quote
Quote
- 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.
If your program leaks memory everywhere and crashes in unclear and strange ways even after hours of testing and debugging, you're doing it wrong. Slow is better than unstable. Using so little memory is irrelevant when you can't work for two days without running into a non-trivial memory leak.

Quote
Quote
- 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++.
I can quote sources: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html Can you?
In the above benchmarks, you can see Java can be either faster or slower than C, depending on the cases(depending on problem and compiler/optimization mode). Once again, it's important to remember that Java IS compiled. Its compilation might actually be better than C's.
If you read the whole article, it actually has some reasons about why Java should be faster than C.
Garbage collection may actually be faster than malloc/free for reasons related to the computer's cache.

Quote
Quote
- 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.
I've let my computer alone compiling some projects from source(because some people thought open-source didn't need binaries, only source code). In a dual core(with both cores being used), it would still take hours.
Java projects are way faster to compile. This is more noticeable in big projects, but even on small ones I'm starting to notice this.
See: http://stackoverflow.com/questions/318398/why-does-c-compilation-take-so-long
I think I might be seeing terrible compilation times in my small personal C++ projects because I aggressively use templates, but I did see this problem in big C-only projects, so it can't just be my code.

Quote
- 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."
[/quote]
I mentioned enough cases of why my "liking Java" is justified.

I've seen lots of contradictory benchmarks, but here is the essential parts:
 - Java/C# are not too slow compared to C.
 - Java/C# have consistent APIs. C++ "has no API"(your words).
 - Java/C# are FAR FAR FAR faster than C++ when it comes to *compilation* time.
 - Garbage collection is not a handicap.
 - Java/C# are nice to code in. C is masochism.
 - C may be nice when it works, but it hardly does and it is awful when it doesn't. Java/C# are just as nice when they work, but greatly attempt to prevent things from not working(memory leaks, segfaults, etc.)

And a new argument: Java/C# are safer than C. Running C is a security risk. Buffer overflows security vulnerabilities, for instance, are VERY rare in Java, while very common in C.

You seem to say that C is "better than Java", but it's not the case.
Java and C#'s are easy to use, fast enough and safer than C. When those things matter, C always loses.
C only seems to win in some particular speed benchmarks(and not all!), really low-level tasks(such as kernels and drivers, which are also possible in C#/Java, by the way, even if rare) and supporting legacy code(huge code bases such as Mozilla, which would be perfectly fine if started in Java/C# from the ground up).
So don't ever say C is always better again. When you have a problem, look at the problem and only then decide the language.
Title: Re: Anaphase
Post by: Game_boy on April 05, 2010, 05:13:03 AM
@luiscubal

Why, then, does no one use Java or .NET for desktop programs? It may be prevalent in enterprise, but I have exactly zero programs on my computer that use Java/C#, (open or proprietary, Linux or Windows). Why aren't developers starting new projects in Java, if it is suitable for some things?

I also see very few Java applets on the web, except for ancient educational pages.
Title: Re: Anaphase
Post by: luiscubal on April 05, 2010, 06:49:11 AM
FlashDevelop and Paint.NET use C#, for instance, and Eclipse, NetBeans and LGM use Java. FlashDevelop may not be important for non-flash app devs, but Paint.NET is among the best image editors I've ever seen(its Linux port - Pinta - is heading the right way too). Eclipse is one of the most widely use IDEs ever.

On Linux, besides Pinta, Tomboy and F-Spot are written in .NET.

If you're planning to use ENIGMA, you'll pretty soon going to use LGM too, which means, you'll have a Java application installed.

On to the real explanation: Java is being defeated by .NET. .NET, however, hasn't caught up in Linux/Mac yet, primarly because Microsoft patent fears have only recently stopped, and not for all APIs(WPF is still under FUD, for example), so Mono is still kind of feared.
Also, old legacy applications are not rewritten every day, so those big legacy projects(Firefox, WebKit, GNOME, KDE, etc.) are stuck in legacy languages.
GNOME, however, recognizes the need for more productivity, so they have the Vala language. The fact that a primarly C environment feels the need to clone the Java/.NET environment in a C-compatible way proves the fact that these higher-level languages do matter.

As for the Applets, have you seen modern Flash? ActionScript code looks a LOT like Java.
You may say Flash is being replaced by HTML5, but last time I checked, HTML, SVG, CSS and JavaScript are definitively not C. Will you say nobody uses those?
Title: Re: Anaphase
Post by: RetroX on April 05, 2010, 07:50:26 AM
@MrJackSparrow: The iPod/iPhone is literally running the full version of OS X.  The entire operating system is on there.

No, they are not. IDEs are VERY language dependent.
In C, for instance, you had no namespaces, so all functions were in the global scope. Therefore, pressing Ctrl+Space would put lots of useless junk, and some times omit the things that matter.
In C++, namespaces and classes made this *a bit* better, but it's still essentially the same crap. C++'s #includes are less IDE-friendly than Java's imports.
I still have no clue what the hell that you're talking about.  Saying that "java forces you to sort everything" is really stupid.  It does not matter what language that you use.  You can code in C++ like you code in Java; I don't care.  It'll be a lot more efficient, and will solve your "sorting" issue.  Just change a few key words and then "WOW, IT WORKS."  But really, I don't see why you'd want to do that in Java.  Sacrificing speed for sorting the code is not acceptable, or at least, in my opinion.

Quote
At least the API is *consistent*. You rarely need just a single API. And, when you do need two C++ APIs to interop, you've got trouble, because they just don't. No matter what you say, you always need an API unless you're writing a kernel. So C is very good for kernels, but usually sucks for everything else. Everything uses java.lang.String, and java.util.List. Of course, C++ has the C interop thing, so it has an unfair disadvantage due to C strings and arrays(which are computer-friendly but definitively not programmer-friendly).
Stop using these areguments.  You can't say that "Java just happens to be consistent because it's there."  There are loads of programs with standard APIs.  GTK, Qt, and wxwidgets are in that category.  So are WinAPI and XLib.

Quote
I can't? Since when? Oh, and "see the above", you can't use any argument that disagrees with me. Why, you may ask? Oh, for no particular reason, but since you can dismiss arguments by just pretending they don't exist I figured I could do the same.
...you're just trying to prove your point with nothing.  Please give me a legit argument, and I'll gladly listen to you.  I mean it, too; I'd like to know why you like Java and C# so much.

Quote
If your program leaks memory everywhere and crashes in unclear and strange ways even after hours of testing and debugging, you're doing it wrong. Slow is better than unstable. Using so little memory is irrelevant when you can't work for two days without running into a non-trivial memory leak.
No, it's not.  There are plenty of debuggers that can be used, and besides, if you do have a memory leak and can't find-out where it could have been, you need to learn how to code correctly.  Memory leaks don't "just happen."

Quote
I can quote sources: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html Can you?
In the above benchmarks, you can see Java can be either faster or slower than C, depending on the cases(depending on problem and compiler/optimization mode). Once again, it's important to remember that Java IS compiled. Its compilation might actually be better than C's.
If you read the whole article, it actually has some reasons about why Java should be faster than C.
Garbage collection may actually be faster than malloc/free for reasons related to the computer's cache.
C: 1.1
Java: 9.0

Yes, the third one is faster.  Big whoop.  I doubt that they were using the same codes for both; they probably just had written it better in Java than in C.  And in the case that you didn't know, Java is written in C.


Quote
I've let my computer alone compiling some projects from source(because some people thought open-source didn't need binaries, only source code). In a dual core(with both cores being used), it would still take hours.
Java projects are way faster to compile. This is more noticeable in big projects, but even on small ones I'm starting to notice this.
See: http://stackoverflow.com/questions/318398/why-does-c-compilation-take-so-long
I think I might be seeing terrible compilation times in my small personal C++ projects because I aggressively use templates, but I did see this problem in big C-only projects, so it can't just be my code.
C compiles slower when people compile the entire thing at once, whereas most of Java's utilities are pre-compiled classes.  That's why you have libraries and object files that you compile for the stuff that is already done.  It's not like you need an entirely different mentality to compile in a different language.

Quote
I've seen lots of contradictory benchmarks, but here is the essential parts:
 - Java/C# are not too slow compared to C.
 - Java/C# have consistent APIs. C++ "has no API"(your words).
 - Java/C# are FAR FAR FAR faster than C++ when it comes to *compilation* time.
 - Garbage collection is not a handicap.
 - Java/C# are nice to code in. C is masochism.
 - C may be nice when it works, but it hardly does and it is awful when it doesn't. Java/C# are just as nice when they work, but greatly attempt to prevent things from not working(memory leaks, segfaults, etc.)
Please give me several reliable sources that aren't your opinion and/or something that I can actually try-out, or stop arguing.

Quote
And a new argument: Java/C# are safer than C. Running C is a security risk. Buffer overflows security vulnerabilities, for instance, are VERY rare in Java, while very common in C.
[citation needed]

Quote
You seem to say that C is "better than Java", but it's not the case.
Java and C#'s are easy to use, fast enough and safer than C. When those things matter, C always loses.
C only seems to win in some particular speed benchmarks(and not all!), really low-level tasks(such as kernels and drivers, which are also possible in C#/Java, by the way, even if rare) and supporting legacy code(huge code bases such as Mozilla, which would be perfectly fine if started in Java/C# from the ground up).
So don't ever say C is always better again. When you have a problem, look at the problem and only then decide the language.
More opinion.  Big whoop.  Please learn how to support an argument.

Quote
I mentioned enough cases of why my "liking Java" is justified.
No, you haven't.  If you'd like to PM me or message me on MSN (however, not this week; I have relatives that are coming over later today), then feel free.  But I'm not clogging-up this topic any more.

Besides, Pinta, Tomboy and F-Spot aren't very good, nor are they fast.

You can't argue that Java/C# are faster than C/C++.  For starters, they are both written in C, so, no matter what, the lower-level language will be better.  Secondly, while they are both compiled, they require a separate runtime that's running to run the compiled code.  It can be argued that the speed isn't enough to worry about, but not that it's not there.
Title: Re: Anaphase
Post by: freezway on April 05, 2010, 08:27:08 AM
 :munch: (also josh: do NOT rewrite everything at this point!)
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 05, 2010, 08:42:04 AM
Thanks for understanding, guys. Does mean a lot.
freezway: I promise. :P
Title: Re: Anaphase
Post by: score_under on April 05, 2010, 08:44:20 AM
- Java/C# are nice to code in. C is masochism.
 - C may be nice when it works, but it hardly does and it is awful when it doesn't. Java/C# are just as nice when they work, but greatly attempt to prevent things from not working(memory leaks, segfaults, etc.)
Actually, I quite like the ability to access a function without goin' all "namespace.class.pointer.otherobject.function()", and instead just using "function(pointer[2])".
Lack of OOP is just personal preference, though.

And "C may be nice when it works, but it hardly does and it is awful when it doesn't"... C has always worked for me, and if you can't get it to work then you don't know the language. Really, you shouldn't code in languages you don't actually know. [Also, ever heard of __try{}/__catch(){}? Works in C++, and can be implemented through function calls in C. Catches errors, you can deal with them however you want.]
Title: Re: Anaphase
Post by: Game_boy on April 05, 2010, 09:11:35 AM
@luis

I wasn't bashing Java. I really was asking why it wasn't more widely used.

And, yes, LGM will be the first Java app I use regularly.
Title: Re: Anaphase
Post by: IsmAvatar on April 05, 2010, 09:38:28 AM
Quote
There are loads of programs with standard APIs.  ...[like] XLib.
Excuse me, I just threw up a little in my mouth.

Source:
I wrote the xlib UI for enigma.
Title: Re: Anaphase
Post by: RetroX on April 05, 2010, 12:42:14 PM
Quote
There are loads of programs with standard APIs.  ...[like] XLib.
Excuse me, I just threw up a little in my mouth.

Source:
I wrote the xlib UI for enigma.
It's still a standard API.
Title: Re: Anaphase
Post by: IsmAvatar on April 05, 2010, 01:07:44 PM
Sadly.
Title: Re: Anaphase
Post by: Rusky on April 05, 2010, 01:15:15 PM
IDEs are language dependent. Syntax highlighting and intellisense require language-specific behavior. The main difference here, however, is #include vs import/using. #include is part of the preprocessor and can thus be abused. Header files require extra maintenance and that public APIs be parsed at least twice- once in the header and once at the definition. Java and C#'s way is much better- it's faster in compilation and development time, because it's not redundant and gets the information it needs directly from its source. However, this is completely independent of the rest of the language. Java/C# could easily have been implemented with #include, and C/++ could easily be implemented with import.

Java and C# have standard APIs. All the different parts interoperate pretty much perfectly. C/++ has several commonly used APIs, yes, but they're not standardized as part of the language and they aren't designed to cooperate. Java and C# implement this by including the enormous standard library in a runtime that must be downloaded separately, C/++ has no standard so the APIs all have their own runtime libraries or are included in each and every program that uses them. The idea with .NET is to become like WinAPI, part of the OS. We're still in a transition phase, so it's slightly painful, but it allows programs to be much smaller while still accessing large support libraries. Both approaches have advantages and drawbacks, so it really depends on your target platform which one is better in this case.

In addition to header files and pre-distributed runtimes, there's another factor involved in compile time. C/++ object files and the APIs they use are less standardized and so (especially open source) libraries usually distribute the source uncompiled. In Java and C#, libraries (and the equivalent of header files; this is the biggest part) are already compiled, so there is no extra parsing or compilation. This design makes building large projects much, much faster. While this is still not dependent on the actual language, it is a better design.

Garbage collection is undoubtedly a good thing. It's not good for every situation, no. I would never use GC in a device driver. However, it is not the only reason, or even the biggest reason, for Java and C#'s (lack of) speed. A bigger problem is Java/C#'s relative lack of static allocation. When everything's on the heap, things will be slower. Although C# has a lot more types that can be allocated on the stack, it still has to deal with automatic boxing and unboxing. It would be possible, I believe, to improve the situation a lot, without giving up GC.

Think about C/++'s dynamic allocation for a minute- things would be a lot slower if you malloc/new'd everything (and free/delete'd it afterwards) because of all the extra work on the heap. Now, if you don't consider that inequality, which as I explained could be fixed, the only difference is that GC does all the hard work on deallocation, while manual memory management does it on allocation. C/++ must walk through the heap looking for enough space and modify the list to mark the memory used. All GC requires for allocation is an add. On deallocation, C/++ doesn't always have to do as much work as GC, but it still does quite a bit. It has to walk the list again, insert the free memory and merge it with surrounding blocks. Despite all that, a manual heap can get fragmented. GC follows references and compacts the heap. Compacting can be expensive, but generational GC helps this quite a bit, and there are plenty of designs that figure out good times to start collection.

Java/C# are also safer by design. You cannot create an arbitrary pointer to anywhere you want like "int* x = (int*)0xDEADBEEF". You cannot cast said pointer to a function pointer. Buffer overruns and other such code injection vulnerabilities are nearly impossible. In the case of Java/C# specifically, these kinds of security holes are all in the VM, which is extremely hardened code as it is used in every single program in existence. In another language like this, it would be in the VM or in the compiler, depending on how it was implemented. None of this requires any runtime support, either. It would be just as fast as C/++ if casting rules were tightened rather than changed to Java/C#-style.

C/++ and Java/C# both have their advantages. While most of the community here seems to blindly follow Josh on his "C++ is the best PERIOD" opinion, that is not the case. C/++, or a language much like them with the same speed and target use cases, could be greatly improved with several things straight from Java/C# land:
Title: Re: Anaphase
Post by: luiscubal on April 05, 2010, 01:58:27 PM
Java is written in C, but so is GCC. I could write a C compiler in Java too, and that wouldn't necessarily make C run slower than Java.
Java is nowadays typically compiled.

As for buffer overflows, consider this code in C.
Code: [Select]
char x[100];
char inTrustMode = isInTrustMode();
//...
gets(x);
//...
if (inTrustMode) {
 //Do trusted(unsafe) operation
}

In this example, what happens if you input a 100th character. This is a typical C security vulnerability. I believe GCC even outputs a warning for using gets. Maybe it's just gets that's badly designed, but the fact is even strcpy has an associated security vulnerability.
Now, C++ might have improved the situation for strings, but the remaining types of arrays are still unsafe.
In Java, this is a Out of bounds exception and that's the end of it. So, you get a nasty exception(that can be caught) instead of having malware installed in your computer.

Last time I tried, I could use try/catch in C++ without the double underscore prefix. It still can't catch out of bounds.

Quote
they probably just had written it better in Java than in C
Then you're saying the application code matters more than the language. And, in that case, I'd rather be solving problems(and coding better) than being stuck with C.

Quote
GTK, Qt, and wxwidgets are in that category.  So are WinAPI and XLib.
Of all your examples, only wxWidgets(and possibly Qt) are worth discussing. XLib was a particularly miserable example.
However, I'll grant that Swing is less than optimal, and C# GUI is not-so-brilliant if you need cross-platform.
However, Java+Swing coding is simpler than C+wxWidgets. With the time I get left, I can actually figure out where/why my code is being slow and optimize the parts that matter, instead of trying to reinvent the wheel or recompile some C++ library, so the end user gets an application that's safer, faster and - most important of all - is actually released!

Regarding IDE writing, Java code is more predictable than C++ code.
For instance, consider the following pseudo-code(translate it to Java and C++ in your mind):
Code: [Select]
class Foo{
 Content goes here
}

what is that? A Java IDE would correctly assume it is a class. A C++ IDE *could* try to assume it is a class. However, the C++ IDE first needs to be sure(in order to be accurate) that this particular piece of code does not appear:
Code: [Select]
#define class enum
Which, guess what, is valid C++.
Also, the above code could be in a header file of its own, so I could have:
Code: [Select]
#define class enum
#include "Foo_definition.h"
So when editing Foo_definition, there'd be absolutely no reference to the class definition as enum.

The C++ IDEs can, therefore:
 - Incorrectly assume that all classes are classes. I believe most IDEs do this.
 - Check for #defines in the same file. As I showed earlier, this is not always correct behavior.
 - Infer usage based on previous compilations. This does not work on the first time and works badly when headers are used in multiple contexts.
 - Implement some fancy system that's not intuitive(hence nobody will use your IDE), takes 3 years to theorize, 5 years to understand and another 4 years to implement, and takes O(n^n) time to run, making even IE6's JScript look fast.

Quote
Besides, Pinta, Tomboy and F-Spot aren't very good, nor are they fast.
I provided examples, which was what I was asked to do.

Some citations:
http://en.wikipedia.org/wiki/Buffer_overflow :
Quote
Programming languages commonly associated with buffer overflows include C and C++, which provide no built-in protection against accessing or overwriting data in any part of memory and do not automatically check that data written to an array (the built-in buffer type) is within the boundaries of that array.
Quote
The Java and .NET bytecode environments also require bounds checking on all arrays. Nearly every interpreted language will protect against buffer overflows, signalling a well-defined error condition.

http://golang.org/doc/go_faq.html
Go features fast compilation (as opposed to C) as a language feature. So it obviously isn't just for me that it matters.
Title: Re: Anaphase
Post by: Rusky on April 05, 2010, 02:43:25 PM
C/++ doesn't have out of bounds exceptions because it doesn't check. In Java/C#, there is no way not to check, so arrays will always be slower. In C/++, you can use vectors, which are closer to Java/C# arrays. Not to re-open this discussion, but none of these language have the best solution here. You either get runtime checking or no checking.
Title: Re: Anaphase
Post by: retep998 on April 05, 2010, 02:49:36 PM
C/++ doesn't have out of bounds exceptions because it doesn't check. In Java/C#, there is no way not to check, so arrays will always be slower. In C/++, you can use vectors, which are closer to Java/C# arrays. Not to re-open this discussion, but none of these language have the best solution here. You either get runtime checking or no checking.
Exactly.
So it's a choice
sacrifice safety for speed
or speed for safety
I prefer speed, since I take the time to ensure my code works well, and if i want to segfault my computer, I WANT TO BE ABLE TO DO IT WITHOUT ANY RUNTIME CHECKS STOPPING ME!!!
Title: Re: Anaphase
Post by: Rusky on April 05, 2010, 02:54:13 PM
No, you misunderstand. In C, C++, Java or C# you get either runtime checking or no checking. There is a third choice- compile-time checking. I'm not saying you shouldn't have a choice; you should, you need it for things like drivers and kernels. However, C/++ is just as braindead as Java/C# in this regard.
Title: Re: Anaphase
Post by: retep998 on April 05, 2010, 02:58:19 PM
Well, it looks like we're split into 3 groups here.

1. The c++ group. They want to have fully compiled exe's with no runtime checks wasting time.
2. The java group which hates the freedom of c++, and wants runtime checks to keep everything safe and slow. (just like the tortoise, slow and steady wins the race...)
3. The whateverruskyissupportingidontknowwhattocallit, where everything is checked at compile time, and whatever benefits rusky claims it has. I'm not very well educated on this area.
Title: Re: Anaphase
Post by: serprex on April 05, 2010, 03:03:42 PM
Rusky is into solving the halting problem
Title: Re: Anaphase
Post by: Rusky on April 05, 2010, 03:05:01 PM
@retep: No, not really. Nobody hates the freedom or speed of C++, so I suggest you stop being a moron and blindly following everyone else. It's really more of the C++ group which wants fully compiled exes with no runtime checks because they heard that's the fastest and they only care about speed, and the smart group which actually thinks about what they say.

C++ is only one way of going about things. It does some things badly and some things well. Neither is perfect, and despite popular opinion here, the same is true of Java- it is not completely worthless. There are also other ways to do things that neither C++ nor Java use, which also have their own advantages and disadvantages.
Title: Re: Anaphase
Post by: Micah on April 05, 2010, 03:06:37 PM
Rusky is into solving the halting problem
Proving all indices to be in-bounds at compile-time is perfectly possible.

Retep, I would suggest that you shut up, go away and stop worshipping every stupid little thing that Josh says, and go actually learn how to program.
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 05, 2010, 03:11:22 PM
"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.
Title: Re: Anaphase
Post by: Micah on April 05, 2010, 03:14:09 PM
Given a large number of conditions are met, sure.
I'm not sure what you mean. Please elaborate.

Also, C++ is the best for you because you're a Blub programmer.
Title: Re: Anaphase
Post by: luiscubal on April 05, 2010, 03:19:23 PM
Well, I believe Josh meant this:
Code: [Select]
int x = get random number between 1 and 10;
int[] y = new int[x];
y[5] = 3; //Is this OK?
Title: Re: Anaphase
Post by: Micah on April 05, 2010, 03:23:47 PM
That code would be proven to have the possibility of out-of-bounds indices.

This code would not have that possibility:

Code: [Select]
x = get random number between 1 and 10
y = array[x]
if x >= 5
  y[5] = 3
else
  do something else
Title: Re: Anaphase
Post by: Rusky on April 05, 2010, 03:30:18 PM
@Josh: You can't know it's the best for you because you haven't tried the alternatives. All you can reasonably claim is that it's the best for you out of what you've used, which doesn't include any of the stuff we're talking about.

The reasoning behind dependent typing is that the compiler finds possible bugs. Luiscubal's example has a possible bug, so the compiler would find it and either error until you fixed it like miky's example, or insert it's own check. The compiler could always behave one way or behave one of those ways depending on a compiler switch or something in the code.
Title: Re: Anaphase
Post by: luiscubal on April 05, 2010, 03:33:50 PM
Assuming your arrays are 0-started, but I get your point.
Although possible, that's notably hard.
There are two possible choices for that:
 - Have a really REALLY strong type system.
 - Have an amazingly efficient type inference system.

Neither are possible with C nor Java.
So instead of "C is perfect" or "C and Java are the best choice in different cases", we got to "both C++ and Java suck".

That requires a specific paradigm of programming languages that, for some reason, never really became mainstream.
That particular paradigm is really annoying to program in(since very often it is terribly hard to find out the code possibilities, and we end up with annoying errors), but also really bug-safe. Once again, we have something that's more adequate in some cases than others.
Title: Re: Anaphase
Post by: Rusky on April 05, 2010, 03:43:23 PM
... not really? You could add dependent typing to C. That particular example would require no extra code, just a better compiler. The only extra code required in general would be type annotations. However, these annotations would actually be useful, rather than just mindless "int" or "float." You would, for example, tell the compiler that random can generate numbers between 1 and 10 (or its arguments, or whatever it does return numbers between). Depending on the implementation, even that wouldn't always be required.
Title: Re: Anaphase
Post by: serprex on April 05, 2010, 03:53:51 PM
http://coq.inria.fr/stdlib
Click a few links, you'll see some Coq code. This isn't the language suited for implementing Enigma
Title: Re: Anaphase
Post by: RetroX on April 05, 2010, 04:13:39 PM
I haven't read all of this, but what the hell happened in the last few hours.

C/C++ is a better language.  If you want to make loads of standard libraries in C++ for GC, pointer allocation, etc., that's fine with me.  In fact, I'd love that.

But forcing people to use them in the language is a completely terrible and bad thing to do.

You can't use the argument "IT'S JUST BETTER WITH JAVA" because it's not.  Yes, some Java APIs are better than what C++ has.  It does not mean that Java is a better language.

If the APIs aren't used by everyone, that means that they're obviously not good enough.  How many people use WinAPI?  How many Unix APIs have XLib as a base?
Title: Re: Anaphase
Post by: luiscubal on April 05, 2010, 04:28:54 PM
@seprex
Coq looks math. It could be considered at most functional programming, while C++(and Java too, by the way) is imperative.
GML is imperative too, making its implementation(or, should I say, translation) easier in C++ than in Coq.
Rusky already said that a modification to the C compiler would possibly work.

@RetroX
Here was I thinking that the flamewar was over. My mistake, sorry.

C/C++ is not a better language. It is different. Which is why you have so much trouble accepting Java and C#.
Pointer allocation is called malloc, calloc or new. It already exists in C++ and is widely used.
There is also GC for C++(see Boehm's, for example). However, they are imperfect. Far worse than GCs for GC-designed languages like Java.
Sure, C++ can have lots of things, but with each layer of abstraction you add, the syntax gets uglier and the language more complex. Java does the opposite. It adds those features and *still* has a simpler syntax. Java assumes everybody wants GC and turns out they were right for a HUGE percentage of all cases.

Now, to put this in a way you understand:
Java is a better language. If you want to make loads of standard libraries in Java for non-GC memory, pointer management, etc., that's fine with me. In fact, I'd love that.
But forcing people to use them(pointers, non-GC memory) in the language is a completely terrible and bad thing to do.

You can't use the argument "IT'S JUST BETTER WITH C++" because it's not. Yes, some C++ APIs are better than what Java has. It does not mean that C++ is a better language.

If the APIs are duplicated every day with no interoperability, that means they're obviously not standard enough.

---
Now that I put this out.
The above example is just to prove RetroX that his arguments can be used against him.
I don't consider Java to be absolutely better than C++ the way RetroX seems to think C++ is absolutely better than Java.
I certainly wouldn't care about a non-GC memory/pointer manipulation Java library(JNI-based, I guess).
C++ APIs are available in quantity, but that means fragmentation. Java includes lots of things in the standard library in a (partially successful) attempt to avoid that problem.
For the record, I don't consider Java to be the best language ever. I consider C# to be the best language, although I dislike GUI C# library inconsistent because it's the same problem C++ has. So the thing I hate most in C# happens to be a "feature" of C++? Neat, huh?

EDIT:
Quote
If the APIs aren't used by everyone, that means that they're obviously not good enough.  How many people use WinAPI?  How many Unix APIs have XLib as a base?
I actually missed that flaw. C++ APIs aren't used by everyone. The "not good enough" is obviously a C++ problem, not a Java problem(since everybody uses java.lang). So you just attacked your own language.
Exactly what are you trying to prove with the WinAPI/Xlib argument?
Title: Re: Anaphase
Post by: freezway on April 05, 2010, 05:06:34 PM
@josh: ur image link is broken
Title: Re: Anaphase
Post by: Rusky on April 05, 2010, 06:25:17 PM
Coq is not the only dependently typed language or way to implement dependent typing. As I said, you could add dependent typing to C.

@RetroX: No, C/++ is not a better language. GC and the safer memory design in Java/C# would require language-level changes before working in C/++. Java/C# doesn't require you to use the standard libraries either, any more than you're required to use your OS's API. Personally, I think Java is a worse language overall compared to C/++. What I'm saying is that it has several aspects where it is better, and some of those are impossible in C/++.
Title: Re: Anaphase
Post by: Micah on April 05, 2010, 06:34:40 PM
@serprex: Coq is not really what Rusky is talking about. It has dependent typing, but it's more of a theorem prover than a programming language. You could easily put dependent typing in a normal imperative programming language.

@RetroX, luiscubal: Java and C# are loads better than C++ for anything that's not low-level, but they're not nearly high-level enough. Basically, I would never choose them unless there were some library (e.g. XNA) on the frameworks around which they're built that wasn't anywhere else. Given the choice between them and C++, I would choose them every time, unless I needed to do something which actually needed pointers and manual memory management, in which case most of the abstractions with which C++ provides you would be stupid to use.
Title: Re: Anaphase
Post by: The 11th plague of Egypt on April 06, 2010, 06:47:33 AM
There is an off-topic section for this kind of discussions.

I wonder if these people code as much as they debate.
Title: Re: Anaphase
Post by: kkg on April 06, 2010, 10:28:16 PM
VISUAL BASIC IS THE BEST LANGUAGE LOLOLOLOLLOL


...
Title: Re: Anaphase
Post by: The 11th plague of Egypt on April 07, 2010, 06:39:11 AM
A quick question. It just came to my hear that you can deallocate a whole array in GM using the var trick

var A;
A[100]=0

Will it deallocate the whole array in Enigma too?
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 07, 2010, 07:53:13 AM
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.
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 09, 2010, 10:43:13 AM
Any news from the Devs? Josh, Ism?
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 09, 2010, 01:06:49 PM
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.

Title: Re: Anaphase
Post by: IsmAvatar on April 09, 2010, 01:48:11 PM
JNA is LGPL.

Also, what's so wrong with our code editor anyways?
Title: Re: Anaphase
Post by: The 11th plague of Egypt on April 09, 2010, 01:58:26 PM
You can write a code editor in a day? :o
Title: Re: Anaphase
Post by: IsmAvatar on April 09, 2010, 02:16:10 PM
Yes.

{
 JTextArea a = new JTextArea();
 add(a);
}
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 09, 2010, 02:32:41 PM
"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.
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 09, 2010, 02:35:52 PM
Dude, honestly I could care less about the code editor. I could use GM8's code editor for now. Or hell, notepad suites me for now just fine. I want the meat of Enigma. I want a working, compiled game. LGM/interface can come at a later time.
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 09, 2010, 02:37:48 PM
Fair enough. The compiler gets priority; I'll tell you when to update.
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 09, 2010, 02:41:27 PM
Sweetness. I'm excited!
Title: Re: Anaphase
Post by: score_under on April 09, 2010, 04:47:00 PM
Dude, honestly I could care less about the code editor.
I could care less about the code editor.
I could care less
I could care less
I could care less
:eng99:
Title: Re: Anaphase
Post by: freezway on April 09, 2010, 05:16:51 PM
i agree with MJS. i want the meat!
...
would it be posisble to make a syntax highliter for like... say... gedit?
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 09, 2010, 05:26:50 PM
@score_under: Is a code editor really that important to you? I mean you should know how to code, and I know the colors/bold text helps, but if he is holding off release due to something as simple as that, I think that's stupid. I can use GM for my GML and Code::Blocks for my C++. (granted it won't know all of enigmas functions and only mine, but whatever)

I would eventually like to see a code editor, but honestly that is not a top priority in my opinion.
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 09, 2010, 05:35:33 PM
"i agree with MJS. i want the meat!"
Working on it.

"would it be posisble to make a syntax highliter for like... say... gedit?"
GEdit does have one... open any header in it.

Also, a code editor wouldn't slow the release much.
Title: Re: Anaphase
Post by: Rusky on April 09, 2010, 05:42:00 PM
@score_under: Is a code editor really that important to you? I mean you should know how to code, and I know the colors/bold text helps, but if he is holding off release due to something as simple as that, I think that's stupid. I can use GM for my GML and Code::Blocks for my C++. (granted it won't know all of enigmas functions and only mine, but whatever)

I would eventually like to see a code editor, but honestly that is not a top priority in my opinion.
The problem was "I could care less." If you could, please do so.
Title: Re: Anaphase
Post by: MrJackSparrow2 on April 09, 2010, 05:44:34 PM
I'm sorry a figure of speech upset you people. I figured we were more mature than that.
Title: Re: Anaphase
Post by: Rusky on April 09, 2010, 06:27:21 PM
It's your incorrect use of a figure of speech- the correct usage is "I couldn't care less."
It didn't really upset anyone either- I don't see a flamewar...
Title: Re: Anaphase
Post by: The 11th plague of Egypt on April 09, 2010, 06:54:50 PM
Dude, honestly I could care less about the code editor.
i agree with MJS. i want the meat!

People, people, the facade is important. Imagine what the first Enigma users will see, they'll see something that looks inferior.
After all this work, we want to give a good impression.

Also, a code editor wouldn't slow the release much.
He just said he can make it in a day or so. Trust him.
Title: Re: Anaphase
Post by: freezway on April 09, 2010, 06:58:40 PM
keep in mind this is not a final release of R4, we dont have to have the editor done.
Title: Re: Anaphase
Post by: Micah on April 09, 2010, 07:14:07 PM
After all this work, we want to give a good impression.
You talk like you actually contributed a lot besides posts on the forum.

He just said he can make it in a day or so. Trust him.
Just like you did on the parser. :)
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 09, 2010, 07:30:31 PM
"We" refers to the group of people who are here because they actually want to see ENIGMA succeed. That includes him; it's sensible that anyone who cared for the success of ENIGMA would want to make a good impression.

As for the C parser, that I'll grant; it took a lot longer than I'd hoped, as I decided as I went to add more features. Originally I wanted to just collect function and class names, but then I realized I could do so much more with a full description of what was included...

I can't really say the same for a simple code editor.
Title: Re: Anaphase
Post by: freezway on April 09, 2010, 10:19:51 PM
Get the engine working... THEN the editor!
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 09, 2010, 10:43:31 PM
Yes, that's what was decided...
Aragon is actually taking care of the makefiles now. Which makes him important. With a little luck, ENIGMA will simply pass a couple flags to the makefile and be done. Then only cross-compiler makefiles, such as that for the Wii, will be separate.
Title: Re: Anaphase
Post by: freezway on April 09, 2010, 11:00:11 PM
so... will it be released this weekend!?
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 10, 2010, 12:09:27 AM
God, I hope so. If no one yet cares about interface, for which output redirection currently is STILL BROKEN, then I don't see why not. As long as the makefile gets written. I've asked Aragon to allow for parameters GRAPHICS=GL, WINDOW=WIN32, and WINDOW=XLIB. If he can add those... We'll be in good shape.

I'm going to add template tolerance and automation tomorrow. Ism can hopefully fix output redirection as soon as/before Aragon has makefile working. All else is looking good. Just fixed/seemingly finished implicit typing again. Have to make sure scope applies to it...

Presently it will flip shit if you say, for example,
if (true)
  int a = 0;
As the behavior of that is meaningless in C++ and undefined in ENIGMA. Will see what I can do about it. (It's technically as simple as finding non-'n' letter tokens and pushing the scope until ';', but...)
Title: Re: Anaphase
Post by: freezway on April 10, 2010, 12:20:50 PM
WHAT IS OUTPUT REDIRECTION?
Title: Re: Anaphase
Post by: IsmAvatar on April 10, 2010, 01:20:20 PM
Output redirection is where you print something to stdout, but instead of it being printed to the console, it gets redirected to something else, like a file or a window.

In the context of Enigma, the problem is that before, when I ran Enigma as an executable, output was put in a stream, rather than printed to stdout, and I could decide what to do with it. Now that enigma is a dll, it uses Java's stdout, so I need to redirect my own stdout to wherever I want it to go, and then put it back to terminal output afterwards.

The problem with this is that it's *my* stdout, which means that if *I* want to print something while I'm redirecting Enigma's stdout, it means that *my* output also gets redirected. This is a non-issue if I just redirect output, call the dll, and then reset output - but it's not as simple as that, because calling the dll can take time, which means that LGM would freeze while it's waiting for the dll, and you wouldn't see the output until the dll finishes, when it all comes at once.

To solve *that* problem, I would normally thread enigma (run it in its own thread, or simultaneous to LGM, rather than freezing and waiting for it to finish). However, that solution means that while I have output redirected and while Enigma is running, LGM is also running and could potentially produce output. If it does so, said output will be redirected, which is undesirable.
Title: Re: Anaphase
Post by: freezway on April 10, 2010, 01:29:11 PM
so..... its a crapshoot either way?
Title: Re: Anaphase
Post by: IsmAvatar on April 10, 2010, 01:35:25 PM
Not necessarily. It's just that each solution brings a new problem.
Title: Re: Anaphase
Post by: Rusky on April 10, 2010, 02:43:45 PM
With JNI it looks like it would be possible to pass Enigma a Java stream. However, that would require an extra layer...
Title: Re: Anaphase
Post by: IsmAvatar on April 10, 2010, 03:08:22 PM
I have no objections to using JNI, and would have liked to have used it in the first place, but I was never able to get it to work.
Title: Re: Anaphase
Post by: luiscubal on April 10, 2010, 04:06:01 PM
Could you try to get a stack trace so that, on printing, you could check where the output was coming from?
Title: Re: Anaphase
Post by: RetroX on April 10, 2010, 05:45:28 PM
GRAPHICS=GL, WINDOW=WIN32, and WINDOW=XLIB. If he can add those... We'll be in good shape.
Have DirectX graphics been implemented yet, or is that purely there for preparation?  Also, in the future, would it be possiblw to write things for ENIGMA (not necessarily you, but maybe someone else could help with it after r4 is released) for WINDOW=WIN64, WINDOW=GTK, and WINDOW=WXWIDGETS?

Yes, you can compile for Win64 with MinGW; Google mingw-w64.  It's mostly experimental, but it works.

EDIT: If ENIGMA is a DLL, what is going to be used for the GNU/Linux version?  You can't link Java to a shared library, afaik.
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 10, 2010, 06:25:14 PM
Quote
Have DirectX graphics been implemented yet, or is that purely there for preparation?  Also, in the future, would it be possiblw to write things for ENIGMA (not necessarily you, but maybe someone else could help with it after r4 is released) for WINDOW=WIN64, WINDOW=GTK, and WINDOW=WXWIDGETS?
Purely preparatory. Yes, all of those would be fine if they are structured the same way as the two currently implemented systems.

Quote
EDIT: If ENIGMA is a DLL, what is going to be used for the GNU/Linux version?  You can't link Java to a shared library, afaik.
Can, and did.
Title: Re: Anaphase
Post by: Rusky on April 10, 2010, 07:01:38 PM
@luiscubal- Then you'd end up with LGM stack traces in the Enigma log.
@Retro- What would be the point of JNI without DLLs and SOs?
Title: Re: Anaphase
Post by: RetroX on April 10, 2010, 10:47:49 PM
SOs and DLLs don't operate in the same way.  DLLs have options to load functions from strings.  You can't do that with SOs, afaik.
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 10, 2010, 11:11:05 PM
Buh?
Title: Re: Anaphase
Post by: The 11th plague of Egypt on April 11, 2010, 07:23:28 AM
uh?
Title: Re: Anaphase
Post by: Fede-lasse on April 11, 2010, 09:32:59 AM
h?
Title: Re: Anaphase
Post by: Game_boy on April 11, 2010, 10:31:36 AM
?
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 11, 2010, 10:41:33 AM
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 11, 2010, 10:42:53 AM
For some reason, instance_destroy does nothing at all. Fixing...
Title: Re: Anaphase
Post by: retep998 on April 11, 2010, 11:02:29 AM
Fixing...
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 11, 2010, 11:21:57 AM
Fixed, and then some. Going to do some homework while I ponder my next move.
Title: Re: Anaphase
Post by: RetroX on April 11, 2010, 08:47:11 PM
You should pull a Microsoft and add pop-up messages into ENIGMA that say things like "Josh @ Dreamland is finding bugs..." and "Josh @ Dreamland is fixing bugs..."
Title: Re: Anaphase
Post by: antidote on April 11, 2010, 08:48:17 PM
Or, "It's absolutely pointless to find a solution, just give up."?
Title: Re: Anaphase
Post by: kkg on April 11, 2010, 11:27:45 PM
Then he'll spam us while we're trying things out, to rape any poor 3G modem user >:

*Sits waiting anxiously*

EDIT: goodbye at my avatar? >:
Title: Re: Anaphase
Post by: freezway on April 14, 2010, 06:55:56 PM
any news?
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 14, 2010, 07:33:00 PM
Anyone that would like to test at this point can checkout the SVN and operate the project. Windows users will need a copy of libzlib, available here:
http://dl.dropbox.com/u/1052740/libzlib.a

Place that in additional/zlib if you're on Windows, otherwise Code::Blocks will know what to do if you select the correct build target.

Furthermore, no one I've talked to is proficient enough in Make to write a makefile taking parameters to indicate which graphics system and window system to use (Like GRAPHICS=GL, or just _ instead of = if need be). That being the case, either write one and post it here, (specifying systems is as simple as selecting which directories to iterate for sources), or you can join everyone else and test it by pressing Run in ENIGMA, then building the game in Code::Blocks (from ENIGMAsystem/SHELL/ENIGMAengine.cbp). You must hit "Run" in ENIGMA first, or your sources will not be authored.

Furthermore, instance_create is behaving very slowly on Ubuntu when an instance has not been recently destroyed. This indicates to me that allocation of memory for the new instance is painfully slow for one reason or another. I'm looking into the problem; it could be anything.

So yes, if you're intelligent enough to get what's available working for you, please feel free. If you're not, or would prefer not to anyway, just wait until ENIGMA's to the developers' liking (That includes Ism and me).
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 14, 2010, 07:58:45 PM
Procedure in general is as follows: (Subject to revision; pay attention)

Revision 0

-Have Code::Blocks and some SVN client, or a whole lot of creativity.
-Check out the SVN repository (from command line, use  svn co https://enigma-dev.svn.sourceforge.net/svnroot/enigma-dev enigma-dev )
-Go to Trunk
-Go to CompilerSource
-Open the Code::Blocks project. Find the dropdown that likely reads "release." If you're on Linux, set it to "Release-Linux"
-Hit compile (blue gear)
-Go back up to Trunk
-Run LateralGM, best with a terminal via "java -jar lateralgm16b4.jar"
---If that errors, paste output here
-Make something simple (just a single object drawing a graded circle is what I've been using as a preliminary)
-Under the "Enigma" menu, hit "Run"
-Open trunk/ENIGMAsystem/SHELL/ENIGMAengine.cbp
-Select your OS from the dropdown box once more (Debug is faster to build, release will run fastest)
-Press Compile
---If anything errors and you think you followed the above correctly, right click the error list, select "Copy Contents to Clipboard," and paste them all here.
-Press run.
---If it doesn't behave as expected, describe what went wrong here

Repeat the step starting at "Make something simple" until you're sick of finding bugs.
The most immediate concern is that everyone can achieve a simple circle.
Title: Re: Anaphase
Post by: RetroX on April 14, 2010, 08:00:06 PM
Can't you just make a makefile rather than a C::B project? :/
Title: Re: Anaphase
Post by: freezway on April 14, 2010, 08:25:03 PM
/home/andrew/enigma/trunk/CompilerSource/cfile_parse/macro_functions.cpp||In function ‘bool preprocess_separately(std::string&)’:|
/home/andrew/enigma/trunk/CompilerSource/cfile_parse/macro_functions.cpp|109|error: invalid initialization of reference of type ‘unsigned int&’ from expression of type ‘size_t’|
/home/andrew/enigma/trunk/CompilerSource/cfile_parse/macro_functions.cpp|58|error: in passing argument 3 of ‘bool macro_function_parse(std::string, std::string, unsigned int&, std::string&, varray<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, int, int, bool)’|
||=== Build finished: 2 errors, 0 warnings ===|
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 14, 2010, 09:15:56 PM
Resolved: Replaced pertinent instances of size_t and unsigned with "pt," typedefed as the former.
Re-check out if this affects you.
Title: Re: Anaphase
Post by: retep998 on April 14, 2010, 09:49:39 PM
Can't you just make a makefile rather than a C::B project? :/
Furthermore, no one I've talked to is proficient enough in Make to write a makefile taking parameters to indicate which graphics system and window system to use (Like GRAPHICS=GL, or just _ instead of = if need be)
Title: Re: Anaphase
Post by: IsmAvatar on April 14, 2010, 10:15:53 PM
The following is an example of non-erroring output:

Code: [Select]
$ java -jar lgm16b4.jar
Java Version: 10600 (1.6.0_15)
Loading lib files in /home/ismavatar/Desktop/enigma-dev/lgm16b4.jar
01_move.lgl 02_main1.lgl 03_main2.lgl 04_control.lgl
 05_score.lgl 06_extra.lgl 07_draw.lgl
SvnKit missing, corrupted, or unusable. Please download and place next to the enigma plugin in order to enable auto-update.
Initializing Enigma: Intializing Parsers.Probing for GCC...
GCC located. Path: `'
Successfully loaded GCC definitions
Unable to load plugin: jna.jar: null: Missing plugin entry point (LGM-Plugin)
Title: Re: Anaphase
Post by: freezway on April 14, 2010, 10:25:18 PM
now compiles on 64 bit linux.
Title: Re: Anaphase
Post by: freezway on April 14, 2010, 10:30:19 PM
enigma compiles correctly, but LGM hangs on loading plugins. here is the output from the terminal
Code: [Select]
Java Version: 10600 (1.6.0_0)
Loading lib files in /home/andrew/enigma/trunk/lgm16b4.jar
01_move.lgl 02_main1.lgl 03_main2.lgl 04_control.lgl
 05_score.lgl 06_extra.lgl 07_draw.lgl
SvnKit missing, corrupted, or unusable. Please download and place next to the enigma plugin in order to enable auto-update.
Initializing Enigma: Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'compileEGMf': libcompileEGMf.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:164)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:237)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:200)
at com.sun.jna.Native.register(Native.java:1013)
at org.enigma.backend.EnigmaStruct.<clinit>(EnigmaStruct.java:72)
at org.enigma.EnigmaRunner.initEnigmaLib(EnigmaRunner.java:97)
at org.enigma.EnigmaRunner.<init>(EnigmaRunner.java:73)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at org.lateralgm.main.LGM.loadPlugins(LGM.java:297)
at org.lateralgm.main.LGM.main(LGM.java:512)
Title: Re: Anaphase
Post by: retep998 on April 14, 2010, 10:44:22 PM
Are you sure you compiled the linux version, not the windows version?
Why don't you check if the .so file exists?
Title: Re: Anaphase
Post by: freezway on April 14, 2010, 11:01:43 PM
where would it be. i did a quick search and there are no .so files in my home folder.

actaully, it may have something to do with this:
Code: [Select]
Linking dynamic library: ../libcompileEGMf.so
/usr/bin/ld: .objs/cfile_parse/cfile_parse.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
.objs/cfile_parse/cfile_parse.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
this was the end of my build log

EDIT: you need to add -fPIC to other options to get it to work. also, LGM now runs... but i cant use enigma. it says its now missing JNA

Code: [Select]
Java Version: 10600 (1.6.0_0)
Loading lib files in /home/andrew/enigma/trunk/lgm16b4.jar
01_move.lgl 02_main1.lgl 03_main2.lgl 04_control.lgl
 05_score.lgl 06_extra.lgl 07_draw.lgl
SvnKit missing, corrupted, or unusable. Please download and place next to the enigma plugin in order to enable auto-update.
Initializing Enigma: Intializing Parsers.Probing for GCC...
GCC located. Path: `'
Successfully loaded GCC definitions
Undefining _GLIBCXX_EXPORT_TEMPLATE
# 1 "blank.txt"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "blank.txt"
8dirs:
"/usr/include/c++/4.4/"
"/usr/include/c++/4.4/x86_64-linux-gnu/"
"/usr/include/c++/4.4/backward/"
"/usr/local/include/"
"/usr/lib/gcc/x86_64-linux-gnu/4.4.1/include/"
"/usr/lib/gcc/x86_64-linux-gnu/4.4.1/include-fixed/"
"/usr/include/x86_64-linux-gnu/"
"/usr/include/"
Successfully parsed ENIGMA's engine (0ms)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing EDL Parser... Done.
Unable to load plugin: jna.jar: null: Missing plugin entry point (LGM-Plugin)
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 15, 2010, 06:16:26 AM
freezway--
The ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ means it was successful. Running from LGM won't build the exe since the makefile isn't written; you'll have to build with Code::Blocks after you hit run.

I will add -fPIC to the Linux target. I don't understand why yours was the only one that complained about it.
Title: Re: Anaphase
Post by: freezway on April 15, 2010, 09:27:50 AM
when I use C::B to try to compile it I get errors, I believe I emailed them to joshy. I'll post them here.
Code: [Select]

-------------- Build: lin-debug in Game ---------------

Compiling: Graphics_Systems/OpenGL/GSblend.cpp
Compiling: Graphics_Systems/OpenGL/GScolors.cpp
Compiling: Graphics_Systems/OpenGL/GSenable.cpp
Compiling: Graphics_Systems/OpenGL/GSmiscextra.cpp
Compiling: Graphics_Systems/OpenGL/GSprmtvs.cpp
Compiling: Graphics_Systems/OpenGL/GSscreen.cpp
Compiling: Graphics_Systems/OpenGL/GSsprite.cpp
Compiling: Graphics_Systems/OpenGL/GSspriteadd.cpp
Compiling: Graphics_Systems/OpenGL/GSstdraw.cpp
Compiling: Graphics_Systems/OpenGL/GSsurface.cpp
Compiling: Graphics_Systems/OpenGL/OPENGLStd.cpp
Compiling: Graphics_Systems/OpenGL/graphics_object.cpp
WARNING: Can't read file's timestamp: /home/andrew/enigma/trunk/ENIGMAsystem/SHELL/Platforms/xlib/XLIBmain.cpp
Compiling: Platforms/xlib/XLIBwindow.cpp
Compiling: Preprocessor_Environment_Editable/IDE_EDIT_wildclass.cpp
Compiling: SHELLmain.cpp
In file included from /home/andrew/enigma/trunk/ENIGMAsystem/SHELL/SHELLmain.cpp:157:
/home/andrew/enigma/trunk/ENIGMAsystem/SHELL/initialize.h: In function ‘int initialize_everything()’:
/home/andrew/enigma/trunk/ENIGMAsystem/SHELL/initialize.h:62: error: ‘instdata’ was not declared in this scope
Process terminated with status 1 (0 minutes, 2 seconds)
1 errors, 0 warnings

also, heres a full output from LGM

Code: [Select]
Java Version: 10600 (1.6.0_0)
Loading lib files in /home/andrew/enigma/trunk/lgm16b4.jar
01_move.lgl 02_main1.lgl 03_main2.lgl 04_control.lgl
 05_score.lgl 06_extra.lgl 07_draw.lgl
SvnKit missing, corrupted, or unusable. Please download and place next to the enigma plugin in order to enable auto-update.
Initializing Enigma: Intializing Parsers.Probing for GCC...
GCC located. Path: `'
Successfully loaded GCC definitions
Undefining _GLIBCXX_EXPORT_TEMPLATE
# 1 "blank.txt"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "blank.txt"
8dirs:
"/usr/include/c++/4.4/"
"/usr/include/c++/4.4/x86_64-linux-gnu/"
"/usr/include/c++/4.4/backward/"
"/usr/local/include/"
"/usr/lib/gcc/x86_64-linux-gnu/4.4.1/include/"
"/usr/lib/gcc/x86_64-linux-gnu/4.4.1/include-fixed/"
"/usr/include/x86_64-linux-gnu/"
"/usr/include/"
Successfully parsed ENIGMA's engine (0ms)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing EDL Parser... Done.
Unable to load plugin: jna.jar: null: Missing plugin entry point (LGM-Plugin)
time taken to load file: 24 ms
Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: org.lateralgm.resources.Sprite$MaskShape cannot be cast to java.lang.Integer
at org.enigma.EnigmaWriter.populateSprites(EnigmaWriter.java:186)
at org.enigma.EnigmaWriter.populateStruct(EnigmaWriter.java:103)
at org.enigma.EnigmaWriter.prepareStruct(EnigmaWriter.java:95)
at org.enigma.EnigmaRunner.compile(EnigmaRunner.java:355)
at org.enigma.EnigmaRunner.actionPerformed(EnigmaRunner.java:391)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:374)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1688)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1732)
at java.awt.Component.processMouseEvent(Component.java:6108)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:5873)
at java.awt.Container.processEvent(Container.java:2105)
at java.awt.Component.dispatchEventImpl(Component.java:4469)
at java.awt.Container.dispatchEventImpl(Container.java:2163)
at java.awt.Component.dispatchEvent(Component.java:4295)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4461)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4125)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4055)
at java.awt.Container.dispatchEventImpl(Container.java:2149)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4295)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:604)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)

about the -fPIC, maybe 64bit?
Title: Re: Anaphase
Post by: RetroX on April 15, 2010, 03:39:04 PM
Furthermore, no one I've talked to is proficient enough in Make to write a makefile taking parameters to indicate which graphics system and window system to use (Like GRAPHICS=GL, or just _ instead of = if need be)
Hello.
Title: Re: Anaphase
Post by: RetroX on April 15, 2010, 03:44:36 PM
Code: [Select]
-------------- Build: Release in compileEGMf ---------------

Compiling: cfile_parse/cfile_parse.cpp
Compiling: cfile_parse/cfile_parse_macros.cpp
Compiling: cfile_parse/cfile_pushing.cpp
Compiling: cfile_parse/cparse_components.cpp
Compiling: cfile_parse/cparse_shared.cpp
Compiling: cfile_parse/expression_evaluator.cpp
Compiling: cfile_parse/handle_letters.cpp
Compiling: cfile_parse/keyword_operator.cpp
Compiling: cfile_parse/macro_functions.cpp
Compiling: cfile_parse/main.cpp
Compiling: cfile_parse/skipping.cpp
Compiling: cfile_parse/template_handlers.cpp
Compiling: compiler/compile.cpp
Compiling: compiler/compile_includes.cpp
Compiling: compiler/output_locals.cpp
Compiling: compiler/pcs/pcs.cpp
Compiling: externs/externs.cpp
Compiling: externs/references.cpp
Compiling: gcc_interface/gcc_backend.cpp
Compiling: general/darray.cpp
Compiling: general/string.cpp
Compiling: general/textfile.cpp
Compiling: main.cpp
Compiling: parser/collect_variables.cpp
Compiling: parser/object_storage.cpp
Compiling: parser/parser.cpp
Compiling: parser/parser_components.cpp
Compiling: syntax/checkfile.cpp
Compiling: syntax/syntax.cpp
Compiling: varnames/varnames.cpp
Linking dynamic library: ../compileEGMf.so
/usr/bin/ld: .objs/cfile_parse/cfile_parse.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
.objs/cfile_parse/cfile_parse.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 46 seconds)
0 errors, 0 warnings
Title: Re: Anaphase
Post by: IsmAvatar on April 15, 2010, 03:57:40 PM
Quote from: freezway
LGM now runs... but i cant use enigma. it says its now missing JNA
No it doesn't. It says JNA is not a plugin. This is correct.
Title: Re: Anaphase
Post by: freezway on April 15, 2010, 07:03:04 PM
@retrox:
add -fPIC to build options > other options
Title: Re: Anaphase
Post by: RetroX on April 15, 2010, 07:18:11 PM
-------------- Build: Release in compileEGMf ---------------

g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cfile_parse.cpp -o .objs/cfile_parse/cfile_parse.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cfile_parse_macros.cpp -o .objs/cfile_parse/cfile_parse_macros.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cfile_pushing.cpp -o .objs/cfile_parse/cfile_pushing.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cparse_components.cpp -o .objs/cfile_parse/cparse_components.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cparse_shared.cpp -o .objs/cfile_parse/cparse_shared.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/expression_evaluator.cpp -o .objs/cfile_parse/expression_evaluator.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/handle_letters.cpp -o .objs/cfile_parse/handle_letters.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/keyword_operator.cpp -o .objs/cfile_parse/keyword_operator.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/macro_functions.cpp -o .objs/cfile_parse/macro_functions.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/main.cpp -o .objs/cfile_parse/main.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/skipping.cpp -o .objs/cfile_parse/skipping.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/template_handlers.cpp -o .objs/cfile_parse/template_handlers.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/compiler/compile.cpp -o .objs/compiler/compile.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/compiler/compile_includes.cpp -o .objs/compiler/compile_includes.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/compiler/output_locals.cpp -o .objs/compiler/output_locals.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/compiler/pcs/pcs.cpp -o .objs/compiler/pcs/pcs.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/externs/externs.cpp -o .objs/externs/externs.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/externs/references.cpp -o .objs/externs/references.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/gcc_interface/gcc_backend.cpp -o .objs/gcc_interface/gcc_backend.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/general/darray.cpp -o .objs/general/darray.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/general/string.cpp -o .objs/general/string.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/general/textfile.cpp -o .objs/general/textfile.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/main.cpp -o .objs/main.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/parser/collect_variables.cpp -o .objs/parser/collect_variables.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/parser/object_storage.cpp -o .objs/parser/object_storage.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/parser/parser.cpp -o .objs/parser/parser.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/parser/parser_components.cpp -o .objs/parser/parser_components.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/syntax/checkfile.cpp -o .objs/syntax/checkfile.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/syntax/syntax.cpp -o .objs/syntax/syntax.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/varnames/varnames.cpp -o .objs/varnames/varnames.o
g++ -shared  .objs/cfile_parse/cfile_parse.o .objs/cfile_parse/cfile_parse_macros.o .objs/cfile_parse/cfile_pushing.o .objs/cfile_parse/cparse_components.o .objs/cfile_parse/cparse_shared.o .objs/cfile_parse/expression_evaluator.o .objs/cfile_parse/handle_letters.o .objs/cfile_parse/keyword_operator.o .objs/cfile_parse/macro_functions.o .objs/cfile_parse/main.o .objs/cfile_parse/skipping.o .objs/cfile_parse/template_handlers.o .objs/compiler/compile.o .objs/compiler/compile_includes.o .objs/compiler/output_locals.o .objs/compiler/pcs/pcs.o .objs/externs/externs.o .objs/externs/references.o .objs/gcc_interface/gcc_backend.o .objs/general/darray.o .objs/general/string.o .objs/general/textfile.o .objs/main.o .objs/parser/collect_variables.o .objs/parser/object_storage.o .objs/parser/parser.o .objs/parser/parser_components.o .objs/syntax/checkfile.o .objs/syntax/syntax.o .objs/varnames/varnames.o   -o ../compileEGMf.so -s 
/usr/bin/ld: .objs/cfile_parse/cfile_parse.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
.objs/cfile_parse/cfile_parse.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 47 seconds)
0 errors, 0 warnings

-DBUILD-DLL only works for Windows.  It should be -fPIC for .so.
Title: Re: Anaphase
Post by: RetroX on April 15, 2010, 07:26:00 PM
And I feel stupid.  I was building the Windows version.

It still breaks.
Code: [Select]
-------------- Build: Release-Linux in compileEGMf ---------------

g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cfile_parse.cpp -o .objs/cfile_parse/cfile_parse.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cfile_parse_macros.cpp -o .objs/cfile_parse/cfile_parse_macros.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cfile_pushing.cpp -o .objs/cfile_parse/cfile_pushing.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cparse_components.cpp -o .objs/cfile_parse/cparse_components.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/cparse_shared.cpp -o .objs/cfile_parse/cparse_shared.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/expression_evaluator.cpp -o .objs/cfile_parse/expression_evaluator.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/handle_letters.cpp -o .objs/cfile_parse/handle_letters.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/keyword_operator.cpp -o .objs/cfile_parse/keyword_operator.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/macro_functions.cpp -o .objs/cfile_parse/macro_functions.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/main.cpp -o .objs/cfile_parse/main.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/skipping.cpp -o .objs/cfile_parse/skipping.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/cfile_parse/template_handlers.cpp -o .objs/cfile_parse/template_handlers.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/compiler/compile.cpp -o .objs/compiler/compile.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/compiler/compile_includes.cpp -o .objs/compiler/compile_includes.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/compiler/output_locals.cpp -o .objs/compiler/output_locals.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/compiler/pcs/pcs.cpp -o .objs/compiler/pcs/pcs.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/externs/externs.cpp -o .objs/externs/externs.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/externs/references.cpp -o .objs/externs/references.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/gcc_interface/gcc_backend.cpp -o .objs/gcc_interface/gcc_backend.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/general/darray.cpp -o .objs/general/darray.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/general/string.cpp -o .objs/general/string.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/general/textfile.cpp -o .objs/general/textfile.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/main.cpp -o .objs/main.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/parser/collect_variables.cpp -o .objs/parser/collect_variables.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/parser/object_storage.cpp -o .objs/parser/object_storage.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/parser/parser.cpp -o .objs/parser/parser.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/parser/parser_components.cpp -o .objs/parser/parser_components.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/syntax/checkfile.cpp -o .objs/syntax/checkfile.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/syntax/syntax.cpp -o .objs/syntax/syntax.o
g++ -Wall  -O3 -O2 -Wall -DBUILD_DLL     -c /home/alex/enigma-dev/trunk/CompilerSource/varnames/varnames.cpp -o .objs/varnames/varnames.o
g++ -shared  .objs/cfile_parse/cfile_parse.o .objs/cfile_parse/cfile_parse_macros.o .objs/cfile_parse/cfile_pushing.o .objs/cfile_parse/cparse_components.o .objs/cfile_parse/cparse_shared.o .objs/cfile_parse/expression_evaluator.o .objs/cfile_parse/handle_letters.o .objs/cfile_parse/keyword_operator.o .objs/cfile_parse/macro_functions.o .objs/cfile_parse/main.o .objs/cfile_parse/skipping.o .objs/cfile_parse/template_handlers.o .objs/compiler/compile.o .objs/compiler/compile_includes.o .objs/compiler/output_locals.o .objs/compiler/pcs/pcs.o .objs/externs/externs.o .objs/externs/references.o .objs/gcc_interface/gcc_backend.o .objs/general/darray.o .objs/general/string.o .objs/general/textfile.o .objs/main.o .objs/parser/collect_variables.o .objs/parser/object_storage.o .objs/parser/parser.o .objs/parser/parser_components.o .objs/syntax/checkfile.o .objs/syntax/syntax.o .objs/varnames/varnames.o   -o ../libcompileEGMf.so -s -fPIC 
/usr/bin/ld: .objs/cfile_parse/cfile_parse.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
.objs/cfile_parse/cfile_parse.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 46 seconds)
0 errors, 0 warnings

EDIT: To fix the Linux build, add -fPIC to the extra build options.
Title: Re: Anaphase
Post by: freezway on April 15, 2010, 07:29:18 PM
oh... LGM is randomly segfaulting when i hit RUN
Title: Re: Anaphase
Post by: RetroX on April 15, 2010, 07:37:47 PM
On clicking compile:
Code: [Select]
Initializing EDL Parser... Done.
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at org.enigma.EnigmaRunner.compile(EnigmaRunner.java:358)
at org.enigma.EnigmaRunner.actionPerformed(EnigmaRunner.java:406)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:374)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1688)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1732)
at java.awt.Component.processMouseEvent(Component.java:6108)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:5873)
at java.awt.Container.processEvent(Container.java:2105)
at java.awt.Component.dispatchEventImpl(Component.java:4469)
at java.awt.Container.dispatchEventImpl(Container.java:2163)
at java.awt.Component.dispatchEvent(Component.java:4295)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4461)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4125)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4055)
at java.awt.Container.dispatchEventImpl(Container.java:2149)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4295)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:604)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)
Title: Re: Anaphase
Post by: freezway on April 15, 2010, 07:47:47 PM
I get the same or similar when I hit compile. Hitting run also brings LGM down.
Title: Re: Anaphase
Post by: Josh @ Dreamland on April 15, 2010, 08:03:24 PM
Wonder if it incorrectly passes resource data as a result, causing your segfault. I can't be certain at this point. Have some other things to debug; hopefully I can soon reproduce that error.

It may also result from JNA's types versus C++'s, as I was worried about long ago... Ism assured me they were kept the same, but...
Title: Re: Anaphase
Post by: freezway on April 15, 2010, 08:11:43 PM
if you want i can also try on my 32 bit ubuntu box. g2g eat now. chow.