This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
76
Function Peer Review / Re: GM's Data Structures
« on: July 27, 2011, 11:58:31 am »
@IsmAvatar - Yes, I meant ds_lists[id][pos]
78
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 05:10:36 pm »
@Josh C also wouldn't discern the contents of a C structure without being told.
The solution? Telling it what the contents of the structure is.
It's just that the way of telling what the structure is is different between C and LLVM. In C you use a struct statement in some random header file, and in LLVM you use some random different method.
But yes, if ENIGMA's engine is sufficiently decoupled from the EDL language then it should be possible to create a LLVM backend/frontend/whatever to ENIGMA.
The only question is whether it is worth the effort.
The solution? Telling it what the contents of the structure is.
It's just that the way of telling what the structure is is different between C and LLVM. In C you use a struct statement in some random header file, and in LLVM you use some random different method.
But yes, if ENIGMA's engine is sufficiently decoupled from the EDL language then it should be possible to create a LLVM backend/frontend/whatever to ENIGMA.
The only question is whether it is worth the effort.
79
Off-Topic / Re: Will somebody please kill that damn protected keyword!?
« on: July 01, 2011, 02:56:46 pm »
What about Java/C#? They do have abstract, so the whole constructor thing doesn't apply.
Also, are you *sure* the class can't be instantiated on its own?
What about this?
Also, are you *sure* the class can't be instantiated on its own?
What about this?
Code: [Select]
class Foo { protected: Foo() {} };
class FooExt : public Foo { public: FooExt() { new Foo(); } };
80
Off-Topic / Re: Will somebody please kill that damn protected keyword!?
« on: June 30, 2011, 09:01:30 pm »
@RetroX: How is it useful? Like I showed in my previous post, it offers no more encapsulation than public/private. It only makes things uglier to access. Also, I know you could always use pointer arithmetic to access private members, but this method doesn't rely on undefined behavior nor preprocessor tricks.
81
Off-Topic / Will somebody please kill that damn protected keyword!?
« on: June 30, 2011, 07:15:37 pm »
There are several things I hate in programming, such as regular expressions, segmentation faults, those annoying Swing exceptions that pop once in a while out of nowhere and contain only Swing/AWT functions in the stack trace, massive compile times, GCC C++ template error messages, the lack of a standard UI library in .NET, Java's pseudo-generics, the loading times of slow IDEs and the protected access modifier.
Today, I feel like insulting protected to hell. Why? Because it's worthless. Because I hate it almost as much as I hate regular expressions, and because I apparently have nothing better to do with my time.
It's worthless in C++(I'm talking about fields/methods, I haven't thought much about "class foo : protected bar" so I won't comment on that). It's worthless in Java. It's worthless in C#. It's worthless in pretty much any language.
Seriously, we can classify classes in two categories: Those that can be inherited, and those that can not.
Often languages provide special keywords(such as "sealed" and "final") to prevent a class from being inherited. Even if that is not used, private constructors can often put a stop to inheritance.
Protected is worthless in both types of classes.
Let's assume field(or method) Foo is declared in class Bar as protected.
Now class Bar can either be inherited in a given context or it can not.
If, in that context, Bar can't be inherited, then Foo is effectively private(or, at most, the equivalent of C#'s "internal", which is a much better approach to this problem).
If, in that context, Bar can be inherited, then one can create a dummy class BarExtension with only dummy constructors, dummy implementations of abstract methods, and functions declared like "TypeOfFoo GetFoo(Bar* bar)" and "void SetFoo(Bar* bar, TypeOfFoo foo)". These functions can possibly be static(or not, whatever, both would work).
Since now one can modify the Foo of ANY Bar with the help of BarExtension(which can be defined/declared pretty much anywhere), this means that Foo is effectively "public".
So, in any given context, Foo is either private or public.
It just gives a false sensation of security, without solving anything.
Just wanted to share this. Feel free to move along with your lives now.
Today, I feel like insulting protected to hell. Why? Because it's worthless. Because I hate it almost as much as I hate regular expressions, and because I apparently have nothing better to do with my time.
It's worthless in C++(I'm talking about fields/methods, I haven't thought much about "class foo : protected bar" so I won't comment on that). It's worthless in Java. It's worthless in C#. It's worthless in pretty much any language.
Seriously, we can classify classes in two categories: Those that can be inherited, and those that can not.
Often languages provide special keywords(such as "sealed" and "final") to prevent a class from being inherited. Even if that is not used, private constructors can often put a stop to inheritance.
Protected is worthless in both types of classes.
Let's assume field(or method) Foo is declared in class Bar as protected.
Now class Bar can either be inherited in a given context or it can not.
If, in that context, Bar can't be inherited, then Foo is effectively private(or, at most, the equivalent of C#'s "internal", which is a much better approach to this problem).
If, in that context, Bar can be inherited, then one can create a dummy class BarExtension with only dummy constructors, dummy implementations of abstract methods, and functions declared like "TypeOfFoo GetFoo(Bar* bar)" and "void SetFoo(Bar* bar, TypeOfFoo foo)". These functions can possibly be static(or not, whatever, both would work).
Since now one can modify the Foo of ANY Bar with the help of BarExtension(which can be defined/declared pretty much anywhere), this means that Foo is effectively "public".
So, in any given context, Foo is either private or public.
It just gives a false sensation of security, without solving anything.
Just wanted to share this. Feel free to move along with your lives now.
82
General ENIGMA / Re: Game Maker and LLVM
« on: June 21, 2011, 06:44:01 am »
@Fede-lasse "so little text"? Honestly, I can't see any problem with the quantity per paragraph.
83
General ENIGMA / Re: Game Maker and LLVM
« on: June 19, 2011, 03:22:59 pm »
@Josh
Well, in your case, reusing GCC's parsing system for execute_string is a massive overkill, as well as being incredibly unpratical. JITing works better for a) languages that are fast to parse and b) languages that are precompiled to some sort of bytecode. In execute_string, b) is obviously not the case, and GCC is far too slow to qualify for a).
So, in ENIGMA's case, using LLVM or using V8 pretty much is a personal choice - most likely, both will do just fine.
However, GM's case is very different. They can use the exact same compiler system for both the initial compilation and execute_string - that means reusing the entire parser system(which you will most likely need to rewrite - at least partially - since JavaScript is very different from C++) and machine code generation.
So in GM's case, having two compilers doesn't make much sense. So essentially it's best for them to go all out on one single system. Going 100% V8 might not be the best choice - I mean, *you* are using C++ for the initial compilation, so you probably understand what I mean here - so going 100% LLVM might work for them.
Again, in terms of speed, this whole thing depends on implementation. And, of course, the guys of V8 know what they're doing but also keep in mind their variables are most complex, so GM *might* have some optimization chances(after all, GM only has two types of data, right?)
Well, in your case, reusing GCC's parsing system for execute_string is a massive overkill, as well as being incredibly unpratical. JITing works better for a) languages that are fast to parse and b) languages that are precompiled to some sort of bytecode. In execute_string, b) is obviously not the case, and GCC is far too slow to qualify for a).
So, in ENIGMA's case, using LLVM or using V8 pretty much is a personal choice - most likely, both will do just fine.
However, GM's case is very different. They can use the exact same compiler system for both the initial compilation and execute_string - that means reusing the entire parser system(which you will most likely need to rewrite - at least partially - since JavaScript is very different from C++) and machine code generation.
So in GM's case, having two compilers doesn't make much sense. So essentially it's best for them to go all out on one single system. Going 100% V8 might not be the best choice - I mean, *you* are using C++ for the initial compilation, so you probably understand what I mean here - so going 100% LLVM might work for them.
Again, in terms of speed, this whole thing depends on implementation. And, of course, the guys of V8 know what they're doing but also keep in mind their variables are most complex, so GM *might* have some optimization chances(after all, GM only has two types of data, right?)
84
Off-Topic / Re: G-creator forum?
« on: June 19, 2011, 10:08:21 am »
Just for the record, PineDL is hosted here. I just don't mention it very often because I don't want to sound like WiMoMaCon(or whatever it was called in the end).
Also for the record, it isn't really that useful right now.
Also for the record, it isn't really that useful right now.
85
General ENIGMA / Re: Game Maker and LLVM
« on: June 19, 2011, 09:51:06 am »
Considering how slow C++ is to parse(think #includes, etc.), I'd say C++ is one of the worse languages to JIT. Specially if we consider that constructions such as sizeof are compile-time only.
But turning GML to C++ doesn't seem to have ever been YoYo's intention, so I guess it'd be pointless for them to worry about it.
Now, if GML's optimizers use stuff like type inference(which I somewhat doubt, considering how hard stuff like locals vs globals are in GM), then GM does have a chance of competing against ENIGMA in terms of speed. However, do note that this might apply to standard code like "var x = 3; /*x is only being used as an integer*/", so ENIGMA extensions like "int x = 3;" are not being considered here.
So, it all depends on the implementation. However, I think they have made a good decision to use LLVM.
But turning GML to C++ doesn't seem to have ever been YoYo's intention, so I guess it'd be pointless for them to worry about it.
Now, if GML's optimizers use stuff like type inference(which I somewhat doubt, considering how hard stuff like locals vs globals are in GM), then GM does have a chance of competing against ENIGMA in terms of speed. However, do note that this might apply to standard code like "var x = 3; /*x is only being used as an integer*/", so ENIGMA extensions like "int x = 3;" are not being considered here.
So, it all depends on the implementation. However, I think they have made a good decision to use LLVM.
86
Proposals / Re: EGM format: Allow resources in other folders?
« on: May 03, 2011, 01:16:20 pm »
Then I assume default folders can not be erased(and possibly not even renamed)?
87
Proposals / Re: EGM format: Allow resources in other folders?
« on: May 03, 2011, 11:50:28 am »
I can see a problem with allowed integration.
IIRC(it's been a while so it might not be accurate), in GM and LGM when you just create "New object" without having any particular folder selected, it creates the resource(in this case, the object) in the correct folder(though not subfolder).
How would this work with Allowed Integration?
IIRC(it's been a while so it might not be accurate), in GM and LGM when you just create "New object" without having any particular folder selected, it creates the resource(in this case, the object) in the correct folder(though not subfolder).
How would this work with Allowed Integration?
88
Third Party / Re: GMK Parsing library for C++
« on: April 24, 2011, 06:11:42 pm »Quote
Alternative title: GM8 decompilerThis is for the GMK, not the EXE(afaik)
89
Proposals / Re: ENIGMA Project Icons
« on: April 24, 2011, 06:08:21 am »
@IsmAvatar: I understand the concerns. The fact is LGM != LGM+ENIGMA.
Maybe a combined icon for the application?
I guess the branding issue also propagates to GMK files(since they are only used by ENIGMA indirectly). Maybe a LGM paper for GMK, and an ENIGMA paper for ENI files(or whatever they are called)? This could end up looking inconsistent, though...
Maybe a combined icon for the application?
I guess the branding issue also propagates to GMK files(since they are only used by ENIGMA indirectly). Maybe a LGM paper for GMK, and an ENIGMA paper for ENI files(or whatever they are called)? This could end up looking inconsistent, though...
Quote
3) This *should* be defined by the IDE, and I mean fully LGM-side (not plugin). Currently LGM handles the iconOh. I forgot that detail.
90
Proposals / Re: ENIGMA Project Icons
« on: April 23, 2011, 06:00:41 pm »
OK: Here's the proposal:
1. ENIGMA icon for ENIGMA/LGM application;
2. ENIGMA icon in paper for ENIGMA project;
3. ENIGMA icon inside an window for ENIGMA game(default icon, anyway).
Would this work?
1. ENIGMA icon for ENIGMA/LGM application;
2. ENIGMA icon in paper for ENIGMA project;
3. ENIGMA icon inside an window for ENIGMA game(default icon, anyway).
Would this work?