ENIGMA Forums
General fluff => Announcements => Topic started 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.
-
=). 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.
-
I saw Anaphase and got all excited... Damn, oh well. I'm very anxious for this Josh. :)
-
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***
-
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
-
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.
-
Why not just post such small updates on SVN, or whatever you're using?
-
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
-
Though I visit everyday, I don't post very much. But I really felt the need to relay my excitement ;D
-
YAY ENIGMA
:dance:
-
As I said, I'm correcting you. GNU/Linux. Tired is not an excuse.
-
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.
-
it would be awesome if enigma could reach GM's functionality (be fully backwards compatible) by 2nd semester next year..
-
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...
-
thats great.... i wouldn't put execute_string() at too high a priority, its not used much... and bad coding to use it.
-
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.
-
I'm assuming that we'll be able to disable execute_string to cut on file size?
-
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?
-
output redirection? also, i assume it works with linux?
-
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
-
i say have it out before 5:00 PM pacific time!
-
On Easter, you mean?
Can strive for.
-
oh yeah i forgot 2morro is easter!
-
Glad to hear the project is progressing well :). Good work guys.
-
Releasing on Easter is what all true warriors strive for mah boi
-
That will be epic in sufficient proportions. ^_^
-
Purely out of curiosity, what Linux Distro do you use?
-
Purely out of curiosity, what Linux Distro do you use?
I think he uses Ubuntu
-
Focus on free GM compatibility first, and only then go after the Pro features.
-
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
-
I still don't understand the point of using Java ever.
It's "cross-platform," but so is C/C++ with wxwidgets. :/
-
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.
-
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!
-
Just because you said that, now Enigma's never going to be released.
-
@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.
-
@11th:
yeah that would be helpful.
-
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.
-
- Better working environments: OO programming and lack of preprocessor makes writing IDEs far easier, and autocompletion is more relevant.
I don't understand how this is a conceivable argument at all. Object-Oriented programming is, well, in some cases, good, but in other cases, like Java, really bad. Instantiating classes and creating classes uses memory, which is... well, extremely inefficient at best. And don't give me any optimization crap, because I know that Java does none of that. IDEs are language-independent.
- Consistent APIs. In C you have no core library. You have a "standard" library which isn't exactly implemented the same way by everyone and then you need third-party libraries for anything that matters. Sometimes I'm frustrated by lack of library functionality in Java and C#, but this is nowhere as bad as C(++)'s problem.
The point of C++ is that there is no API. You get to do whatever that you want. If you want a standard API, you can make one, and tell everyone to use that. That's essentially what Java and C# are, however, it forces you to use that API.
- Garbage collection. C's static allocation is good when it works, but it's not always enough so you have to use malloc/free eventually, which are pain to handle. C++ added lots of features that make pointers easier to handle, such as T& pointers, but the problems remain. In Java and C#, it *just* works. No memory leaks. C++ wasn't designed for garbage collection, so C++ GCs are always ugly, imperfect and/or inefficient.
See the above. You can't use the argument that "when things are made in Java, they just 'happen' to be better."
- It just works. No segfaults. In C, you have weird errors. You have to compile again in debug mode, try to reproduce the error and use gdb to have some chance of finding the problem. In Java and C#, you get an exception, which points you to exact file, class, function and line where the error is. When it crashes without warning it is typically because of C parts(JNI/JNA).
See above. Additionally, debuggers use loads of space, and slow-down the program. If you want a debugger, make one. It should not be required.
- Good enough runtime speed. Aside from some GUI slowness which is a library rather than a language problem, Java and C# are fast enough for most purposes. In many cases, they can match C's speed thanks to Just-In-Time compilation(Java and C# are typically *NOT* interpreted languages)
You can't just say that "it's good enough, so, on a good computer, you won't notice the difference." I've always seen a significant gap in speed between Java and C/C++.
- Compilation of "real projects" takes some minutes, as opposed to several hours in C++.
It's always been the same to me. Even on older computers.
- Great languages, although C# is technically superior to Java, both are much less frustrating than C++. In Java, I can just write xyz.replaceAll("\n", "\n\t"). The equivalent is much more painful in C, and better but still annoying in C++. Not to mention that regular expressions are available if you need them, without needing to go fetch some weird libraries and check if they work on your compiler.
"I just like Java better."
-
I love you RetroX.
Mr. Dreamland I am VERY excited for Enigma! Release, release, release!
-
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.
-
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.)
-
.... 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?
-
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
-
MrJackSparrow2:
I believe you're right that the iPhone is some sort of Unix. If nothing else, I know C++ is an option on it. If the iPhone has its own GCC, porting will be basically effortless. However, acquiring the API will be tedious for not only me, but users. Apple requires licenses and multiple-hundred-megabyte downloads to develop anything.
Too much work to port? Nah. To acquire? Possibly. It is something I would like to see happen. I'd say the odds are better than XBox 360, but I lack the info to make an educated guess on how that will turn out.
Freezway:
None of the UI tricks from R3 work. I'm unsure of with() and (a).b's standings following this last edit. What does work is finding the GCC, parsing the ENIGMA engine (this is the HUGE accomplishment of R4) parsing... local? Seems to work now; conducting further testing as we speak. Collision system is a no until it stops being "barf." Ism's status is "I can't really think right now. Ask me again tomorrow or something," meaning successful output redirection (as in R4) is not happening tonight. I have been putting off projects and homework for the last week working, so I need to allocate three hours or so tomorrow to the cause. Compiling a basic game has worked off and on as I made fundamental changes in structure for the sake of organization and faster compile. Organization is in preparation for more easily replaced systems (particularly the window system, which will change constantly from platform to platform). Distinguishing that version works, thanks to locating the GCC (which also works, as mentioned above).
Oh Josh, how will files and such work? I am eagerly learning C++. Will I be able to see the output files? I'm sure it will look like shit due to parsing taking out syntax tabbing but I'll live. Is this a possibility; seeing the C++ before it compiles?
You can look at all the object code you want by going to the Preprocessor_Environment_Editable/ folder and looking at the sources therein. You'll want IDE_EDIT_object*.cpp. The code will be missing comments from the original GML, but will be decently well-structured and possible auto-commented.
Also, I don't know C++ very well, but I think I heard you can compile sort of "engines" into lib files I think. Could we possibly make a lib for the collision system to cut compile time? I'm sorry if I got this completely wrong, as I said I'm a damn n00b with C++.
Presently the majority of the engine is left in unlinked object files to save time. Linking them into one big engine file could possibly save more time, and has been a consideration for some time. I have no figures. But yes, that's a good idea and is worth looking into.
-
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.
-
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++
-
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.
-
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.
-
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
-
@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.
-
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?
-
@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.
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.
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.
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."
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.
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.
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.
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]
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.
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.
-
:munch: (also josh: do NOT rewrite everything at this point!)
-
Thanks for understanding, guys. Does mean a lot.
freezway: I promise. :P
-
- 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.]
-
@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.
-
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.
-
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.
-
Sadly.
-
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:
- design of object files that removes the need for header files and their associated extra parsing/compilation
- more cooperation between libraries (for C/++ this would probably mean a new .NET like super-library for an OS)
- garbage collected heap rather than manual new/delete
- safer memory management and pointer usage
-
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.
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.
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.
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):
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:
#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:
#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.
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 :
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.
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.
-
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.
-
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!!!
-
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.
-
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.
-
Rusky is into solving the halting problem
-
@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.
-
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.
-
"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.
-
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.
-
Well, I believe Josh meant this:
int x = get random number between 1 and 10;
int[] y = new int[x];
y[5] = 3; //Is this OK?
-
That code would be proven to have the possibility of out-of-bounds indices.
This code would not have that possibility:
x = get random number between 1 and 10
y = array[x]
if x >= 5
y[5] = 3
else
do something else
-
@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.
-
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.
-
... 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.
-
http://coq.inria.fr/stdlib
Click a few links, you'll see some Coq code. This isn't the language suited for implementing Enigma
-
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?
-
@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:
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?
-
@josh: ur image link is broken
-
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/++.
-
@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.
-
There is an off-topic section for this kind of discussions.
I wonder if these people code as much as they debate.
-
VISUAL BASIC IS THE BEST LANGUAGE LOLOLOLOLLOL
...
-
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?
-
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.
-
Any news from the Devs? Josh, Ism?
-
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.
-
JNA is LGPL.
Also, what's so wrong with our code editor anyways?
-
You can write a code editor in a day? :o
-
Yes.
{
JTextArea a = new JTextArea();
add(a);
}
-
"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.
-
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.
-
Fair enough. The compiler gets priority; I'll tell you when to update.
-
Sweetness. I'm excited!
-
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:
-
i agree with MJS. i want the meat!
...
would it be posisble to make a syntax highliter for like... say... gedit?
-
@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.
-
"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.
-
@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.
-
I'm sorry a figure of speech upset you people. I figured we were more mature than that.
-
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...
-
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.
-
keep in mind this is not a final release of R4, we dont have to have the editor done.
-
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. :)
-
"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.
-
Get the engine working... THEN the editor!
-
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.
-
so... will it be released this weekend!?
-
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...)
-
WHAT IS OUTPUT REDIRECTION?
-
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.
-
so..... its a crapshoot either way?
-
Not necessarily. It's just that each solution brings a new problem.
-
With JNI it looks like it would be possible to pass Enigma a Java stream. However, that would require an extra layer...
-
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.
-
Could you try to get a stack trace so that, on printing, you could check where the output was coming from?
-
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.
-
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.
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.
-
@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?
-
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.
-
Buh?
-
uh?
-
h?
-
?
-
-
For some reason, instance_destroy does nothing at all. Fixing...
-
Fixing...
-
Fixed, and then some. Going to do some homework while I ponder my next move.
-
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..."
-
Or, "It's absolutely pointless to find a solution, just give up."?
-
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? >:
-
any news?
-
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).
-
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.
-
Can't you just make a makefile rather than a C::B project? :/
-
/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 ===|
-
Resolved: Replaced pertinent instances of size_t and unsigned with "pt," typedefed as the former.
Re-check out if this affects you.
-
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)
-
The following is an example of non-erroring output:
$ 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)
-
now compiles on 64 bit linux.
-
enigma compiles correctly, but LGM hangs on loading plugins. here is the output from the terminal
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)
-
Are you sure you compiled the linux version, not the windows version?
Why don't you check if the .so file exists?
-
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:
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
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)
-
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.
-
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.
-------------- 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
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?
-
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.
-
-------------- 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
-
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.
-
@retrox:
add -fPIC to build options > other options
-
-------------- 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.
-
And I feel stupid. I was building the Windows version.
It still breaks.
-------------- 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.
-
oh... LGM is randomly segfaulting when i hit RUN
-
On clicking compile:
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)
-
I get the same or similar when I hit compile. Hitting run also brings LGM down.
-
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...
-
if you want i can also try on my 32 bit ubuntu box. g2g eat now. chow.