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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
916
General ENIGMA / Re: EGMJS
« on: December 18, 2012, 12:51:41 pm »
Sounds great. As I see it, this is what you'll have to do:
1) Create methods in C++ to populate a JDI context with function and variable definitions. You'll have, for instance, a define_global(string name), and a define_function(string name, something). I can write these for you, if you need.
2) Create Java methods which call the C++ methods. Basically, just wrappers through JNA, like we do for everything else that goes on between ENIGMA and LateralGM.
3) Create JavaScript functions through Rhino which call the JNA wrapper functions. So the JavaScript function def_function() calls the Java function DefineFunction, which uses JNA to call the C++ method define_function(). Just for example.
4) Using Rhino and JavaScript reflection, call the JavaScript functions for each member. As I left the system, each function contained a variable representing its minimum and maximum number of parameters.
Depending on if you want to support overloading, they may need to contain more information than that. It's that information which ultimately determines the other parameters to define_function(). JDI supports storing any type of function C++ supports; it's up to you how many to simulate in the JavaScript engine. It may be that all define_function() needs is name, parameter names, and minimum/maximum parameter counts (for variadic functions, the maximum would be -1).
1) Create methods in C++ to populate a JDI context with function and variable definitions. You'll have, for instance, a define_global(string name), and a define_function(string name, something). I can write these for you, if you need.
2) Create Java methods which call the C++ methods. Basically, just wrappers through JNA, like we do for everything else that goes on between ENIGMA and LateralGM.
3) Create JavaScript functions through Rhino which call the JNA wrapper functions. So the JavaScript function def_function() calls the Java function DefineFunction, which uses JNA to call the C++ method define_function(). Just for example.
4) Using Rhino and JavaScript reflection, call the JavaScript functions for each member. As I left the system, each function contained a variable representing its minimum and maximum number of parameters.
Depending on if you want to support overloading, they may need to contain more information than that. It's that information which ultimately determines the other parameters to define_function(). JDI supports storing any type of function C++ supports; it's up to you how many to simulate in the JavaScript engine. It may be that all define_function() needs is name, parameter names, and minimum/maximum parameter counts (for variadic functions, the maximum would be -1).
917
General ENIGMA / EGMJS
« on: December 14, 2012, 01:57:26 pm »
TGMG's interested in maintaining the EGMJS port I started a while back, and doing that under the new parser will be pretty easy, imo.
This topic is to try to make it even easier for him.
I will record general notes to all implementers on the Wiki. Notes specifically concerning my thoughts on the implementation of EGMJS will go in this topic.
My first concern is on how TGMG will load definitions. Presently, ENIGMA uses a central JDI context to store its definitions. Since JDI is inherently a C++ parser, this is done by invoking it on the engine file directly. JDI is not a JavaScript parser. However, JDI's structure is easy to figure out, and JavaScript is capable of reflection. The way I see it, there are three ways you can go about this:
1) Choose the language that is going to host the crawler.
This can be Java using javax.script.ScriptEngine (javax.script.ScriptEngineManager.getEngineByName("JavaScript")), or in C++ using Google V8. Both methods have their advantages:
The bottom line is, by this method, you need to use JavaScript reflection to communicate a list of available functions to ENIGMA so the parser can do syntax checking.
The other method that I can see you using is having emscripten parse the JavaScript engine, and then polling it for definition names to pack into JDI classes. This method has similar advantages. On the downside, it means that EGMJS is dependent on LLVM—that's a heavy dependency that I'm in general not fond of. On the other hand, it means that you'll be asking LLVM for the definitions and (probably) using LLVM to store the code so emscripten can compile the code, which would open doors for ENIGMA to compile to other languages for which LLVM has pretty-printers. It might also introduce some issues in the translation, but from what I can tell, as long as you keep within a relatively decent-sized subset of LLVM instructions, you should avoid such issues.
I see a great amount of merit in each option, so I do not care which method you choose. If you go with the V8/ScriptEngine method, I will be happy to have a two-megabyte JavaScript export extension. If you go with emscripten, I will be happy to have LLVM as an abstraction layer. Let me know what you're thinking, though.
This topic is to try to make it even easier for him.
I will record general notes to all implementers on the Wiki. Notes specifically concerning my thoughts on the implementation of EGMJS will go in this topic.
My first concern is on how TGMG will load definitions. Presently, ENIGMA uses a central JDI context to store its definitions. Since JDI is inherently a C++ parser, this is done by invoking it on the engine file directly. JDI is not a JavaScript parser. However, JDI's structure is easy to figure out, and JavaScript is capable of reflection. The way I see it, there are three ways you can go about this:
1) Choose the language that is going to host the crawler.
This can be Java using javax.script.ScriptEngine (javax.script.ScriptEngineManager.getEngineByName("JavaScript")), or in C++ using Google V8. Both methods have their advantages:
- If you use Java's ScriptEngine class, no additional libraries need included or set up. Java's also pretty good about doing the integration for you, and building V8 for Windows is an impossible task (it requires MSVC++). The difficulty is that you have to get this information back to ENIGMA, and it adds ENIGMA.jar as a dependency to the process (meaning a CLI build without Java will be completely impossible).
- If you use Google V8, everything can be done from within C++; you can use JavaScript reflection to call native methods directly. The C++ methods can populate JDI structures in memory while the JavaScript engine is doing the iteration. This is bound to be more efficient, as Java does not guarantee its scripting engines are even compiled, to my knowledge.
The bottom line is, by this method, you need to use JavaScript reflection to communicate a list of available functions to ENIGMA so the parser can do syntax checking.
The other method that I can see you using is having emscripten parse the JavaScript engine, and then polling it for definition names to pack into JDI classes. This method has similar advantages. On the downside, it means that EGMJS is dependent on LLVM—that's a heavy dependency that I'm in general not fond of. On the other hand, it means that you'll be asking LLVM for the definitions and (probably) using LLVM to store the code so emscripten can compile the code, which would open doors for ENIGMA to compile to other languages for which LLVM has pretty-printers. It might also introduce some issues in the translation, but from what I can tell, as long as you keep within a relatively decent-sized subset of LLVM instructions, you should avoid such issues.
I see a great amount of merit in each option, so I do not care which method you choose. If you go with the V8/ScriptEngine method, I will be happy to have a two-megabyte JavaScript export extension. If you go with emscripten, I will be happy to have LLVM as an abstraction layer. Let me know what you're thinking, though.
918
Announcements / Re: JDI ↔ Parser: Code formatting, completion
« on: December 11, 2012, 10:22:53 pm »
Then that's the plan.
919
Announcements / Re: JDI ↔ Parser: Code formatting, completion
« on: December 11, 2012, 12:53:43 pm »
Yes, I can. It'll be a bigger pain later, but only slightly.
920
Announcements / JDI ↔ Parser: Code formatting, completion
« on: December 11, 2012, 11:39:46 am »
Tomorrow I take the last of my finals, and so by tomorrow evening I should, finally, be free to work on ENIGMA again. Forthevin has been doing a great job of adding things left and right, but I don't expect him (much less anyone else) to be able to help much with the parser. Especially if I haven't laid out any plans for it publicly.
I was looking at what I have done and what I need to do with it, when I noticed that one of the smaller bullet points for the parser—the ability to automatically format code neatly—is not presently possible for two simple reasons: comments and preprocessors.
Until those can be resolved, the parser will be incapable of correctly formatting code without dropping comments and potentially preprocessing away some code. The solution is simple, but it involves me editing JDI some more, which probably isn't what anyone wants to hear.
So let me present another benefit that can come from having JDI sew comments and preprocessor blocks into returned tokens: Javadoc-esque code completion.
If JDI reads comments in, ENIGMA or LGM can parse out formal comments like Javadoc and Doxygen do. Basically, we could use Doxygen to describe the purpose of GM functions in-line. When the user selects the function in the code completion menu, we could display information about each parameter and what exactly the function does, instead of just the names of the function and its parameters.
Another option is to have some duplicate code and let ENIGMA parse its own expressions independent of JDI. There is no other benefit to doing this, as JDI can handle any unary prefix, unary postfix, binary, or ternary operator already, including GML's ^^ and <> operators.
Or, I can just belay the code formatting idea all together and get the parser working how it does now.
It's up to you people, but try to decide before tomorrow when I actually have time to do some real coding.
I was looking at what I have done and what I need to do with it, when I noticed that one of the smaller bullet points for the parser—the ability to automatically format code neatly—is not presently possible for two simple reasons: comments and preprocessors.
Until those can be resolved, the parser will be incapable of correctly formatting code without dropping comments and potentially preprocessing away some code. The solution is simple, but it involves me editing JDI some more, which probably isn't what anyone wants to hear.
So let me present another benefit that can come from having JDI sew comments and preprocessor blocks into returned tokens: Javadoc-esque code completion.
If JDI reads comments in, ENIGMA or LGM can parse out formal comments like Javadoc and Doxygen do. Basically, we could use Doxygen to describe the purpose of GM functions in-line. When the user selects the function in the code completion menu, we could display information about each parameter and what exactly the function does, instead of just the names of the function and its parameters.
Another option is to have some duplicate code and let ENIGMA parse its own expressions independent of JDI. There is no other benefit to doing this, as JDI can handle any unary prefix, unary postfix, binary, or ternary operator already, including GML's ^^ and <> operators.
Or, I can just belay the code formatting idea all together and get the parser working how it does now.
It's up to you people, but try to decide before tomorrow when I actually have time to do some real coding.
921
Off-Topic / Re: Introductions
« on: December 08, 2012, 11:01:40 am »
Welcome aboard!
We're doing our best to make ENIGMA's flavor of GML into a serious language, because most of us here feel the same way. The idea is to give the language features of C/C++ while preserving features of GML and sprinkling in some features of JavaScript and Python.
Examples are always welcome; if something in particular is preventing them from working, feel free to post a topic and I or another developer will probably help make the needed corrections to ENIGMA.
Cheers
We're doing our best to make ENIGMA's flavor of GML into a serious language, because most of us here feel the same way. The idea is to give the language features of C/C++ while preserving features of GML and sprinkling in some features of JavaScript and Python.
Examples are always welcome; if something in particular is preventing them from working, feel free to post a topic and I or another developer will probably help make the needed corrections to ENIGMA.
Cheers
922
Proposals / Re: Automatic updating for particle systems
« on: December 06, 2012, 07:59:18 pm »
All right, I'll see about adding a "mode: static" setting that just puts a piece of code or function call in the event function instead of the loop. Do we want to keep "instead" for it, or just make it "code:" or something? I'm happy with leaving it "instead: ", but I'm open to input on the matter.
923
Proposals / Re: Automatic updating for particle systems
« on: December 06, 2012, 02:45:24 pm »
@polygone: And Ism ignored the suggestion, and I didn't push the issue. Now we have two update hacks in that file, and as ENIGMA grows, we're bound to have more legitimate events as well. Having instances use different files is by far more work for Ism in the UI than it is for me.
@forthevin: The built-in sprites sound to me like the kinds of things that can be generated with simple math functions, which beats the shit out of any compression format we'd use.
And yes. It inserts the global updater itself. Polygone hacked in the local updater the same way you did.
Also, forthevin: Are you sure you need that "default" code? Does it just not insert the event without it?
@forthevin: The built-in sprites sound to me like the kinds of things that can be generated with simple math functions, which beats the shit out of any compression format we'd use.
And yes. It inserts the global updater itself. Polygone hacked in the local updater the same way you did.
Also, forthevin: Are you sure you need that "default" code? Does it just not insert the event without it?
924
Proposals / Re: Automatic updating for particle systems
« on: December 06, 2012, 02:24:18 pm »
Whatever.
Point is, it needs restructuring so IDs don't need supplied. And while we're at it, we may as well make LGM use the file, too.
Point is, it needs restructuring so IDs don't need supplied. And while we're at it, we may as well make LGM use the file, too.
925
General ENIGMA / Re: Gamasutra article on GameMaker's recent DRM problems
« on: December 06, 2012, 01:48:22 pm »
Indeed; we've been laughing about that on the IRC for a few days now. People bitch about GPL's quirks, but it'll be a cold day in hell before a FOSS project pulls something like that.
The funniest part is that the crack, I'm told, does not exhibit that problem. They've succeeded only in hurting their user base. Fortunately for them, lawsuit likelihood is a function of age, income, and IQ—their user base in general tends to minimize one of these.
The funniest part is that the crack, I'm told, does not exhibit that problem. They've succeeded only in hurting their user base. Fortunately for them, lawsuit likelihood is a function of age, income, and IQ—their user base in general tends to minimize one of these.
926
Proposals / Re: Automatic updating for particle systems
« on: December 06, 2012, 01:40:00 pm »
If particles were the only systems requiring such an event, I'd probably go with the hack, but since they certainly are not, it's definitely better to do something else about them. Polygone already hacked up events.res to update some globals in a weird spot ages ago, and I haven't gotten around to dealing with that yet, either. So for now, go ahead and push your changes to master and the issue can stew for a while until I have time to do something about it.
I'd kind of like to reformat events.res into basic e-Yaml anyway, so LGM can read it. Otherwise we can't add new events in one spot later on. This might be a good place to talk about what that system should look like.
I'd kind of like to reformat events.res into basic e-Yaml anyway, so LGM can read it. Otherwise we can't add new events in one spot later on. This might be a good place to talk about what that system should look like.
927
General ENIGMA / Re: Hi. I'm MahFreenAmeh
« on: December 06, 2012, 10:29:20 am »
Yeah, and a2h disappeared.
It's okay, though; I made changes to the structure of the site so plugging in his changes should be a snap.
The code that does the background effects, the header, and the footer now appears only once on this server in one PHP file. Even the nnosnese board uses that same header and fucks it up locally (that was a2h's doing).
It's okay, though; I made changes to the structure of the site so plugging in his changes should be a snap.
The code that does the background effects, the header, and the footer now appears only once on this server in one PHP file. Even the nnosnese board uses that same header and fucks it up locally (that was a2h's doing).
928
General ENIGMA / Re: Hi. I'm MahFreenAmeh
« on: December 05, 2012, 11:32:11 pm »
Today I broke everything.
Yay.
Yay.
929
Announcements / Re: Thanksgiving Holiday Updates
« on: December 05, 2012, 10:59:46 am »
I was thinking we'd make a good Red Ribbon Army.
Then I thought better of it.
Then I thought better of it.
930
Announcements / Re: Thanksgiving Holiday Updates
« on: December 03, 2012, 04:33:58 pm »
Done. Your login isn't changed, because I figure you'll change your mind about your lame name in a few minutes.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »