Show Posts

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.


Messages - Josh @ Dreamland

916
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:
  • 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.

917
Announcements / Re: JDI ↔ Parser: Code formatting, completion
« on: December 11, 2012, 10:22:53 PM »
Then that's the plan.

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

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

920
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

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

922
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?

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

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

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

926
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).

927
General ENIGMA / Re: Hi. I'm MahFreenAmeh
« on: December 05, 2012, 11:32:11 PM »
Today I broke everything.

Yay.

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

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

930
Announcements / Re: Thanksgiving Holiday Updates
« on: December 03, 2012, 01:25:06 PM »
Changing a username isn't trivial. Changing the display name is, but we can't have people changing their name every ten seconds. Maybe now we can, but later on it'd be a bad idea. Some people would piss others off, delete their post, and change their names. Or whatever. Just not really a good idea.