ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on January 09, 2013, 11:14:27 am

Title: Trello
Post by: Josh @ Dreamland on January 09, 2013, 11:14:27 am
We have a Trello, now (https://trello.com/board/enigma/50bcfd24ae519514700035dc).

ENIGMA's development interest has been booming lately—despite Ism and me not having very much time to devote to the project, in general. As such, I figured now's a good time to acquaint everyone with Trello. Dazappa has been putting his to-do points up, and I've been putting the simpler points of mine, If anyone is interested, they are welcome to take on any of them. Just let us know or move the card to "doing" yourself, so two people don't end up doing the same thing.

So. Developers, go ahead and have a look. If you're interested in participating, create a Trello account real quick and we'll add you. There is no qualification for "developer" other than "is interested in developing." Don't be shy.

The alternative is to live vicariously by telling us which card you want and which you have finished. Your choice.
Title: Re: Trello
Post by: daz on January 09, 2013, 11:43:08 am
Please note there is a horizontal scrollbar (unless you have a damn hi-res screen) which shows more categories.

In my personal opinion, I would say only add things to the board that have been pre-approved or you personally are working on. For instance, most of the stuff I added to the LGM ToDo list there isn't on the wiki, but I plan on adding unless someone beats me to it. This is just to keep the distinction between suggestions, and actual features that are planned to be worked on.
Title: Re: Trello
Post by: Josh @ Dreamland on January 09, 2013, 11:57:15 am
Yeah, the Trello is for immediate-priority or very short-order stuff, otherwise I would have added my plans for the engine to it. Feature requests belong on the wiki or in the bug tracker if they're pretty small and pretty widely used. Plans for later belong on the Proposals board, or elsewhere on the forums.
Title: Re: Trello
Post by: Ideka on January 09, 2013, 03:20:24 pm
Isn't this done already? https://trello.com/card/add-keyboard-navigation-to-the-resource-tree/50bcfd24ae519514700035dc/6
I can do it in my copy of lateralgm (though it is an old version, because it's the only one I can get to work with ENIGMA).
Title: Re: Trello
Post by: daz on January 09, 2013, 04:12:32 pm
Isn't this done already? https://trello.com/card/add-keyboard-navigation-to-the-resource-tree/50bcfd24ae519514700035dc/6
I can do it in my copy of lateralgm (though it is an old version, because it's the only one I can get to work with ENIGMA).
This is not working for me under Windows. Maybe it's an OS-specific feature of the JTree? It's worth looking into more.
Title: Re: Trello
Post by: Josh @ Dreamland on January 09, 2013, 07:29:16 pm
Maybe it's an OS-specific feature of the JTree? It's worth looking into more.

May very well be; it's working for me on Linux as well. I made a request on the card anyway, though. Space and enter do nothing, even on Linux.

Also, commenting is open to the public.
Title: Re: Trello
Post by: Josh @ Dreamland on January 13, 2013, 11:03:43 pm
Update:

You may or may not have guessed this, but I ran out of time and everything went south. I'm stuck using XNA, of all libraries, to make my game in this quarter, so development of an Ogre ass-end for ENIGMA is out of the question. One of my group members seems to know what he's doing, so this may be painless enough that I have enough time to work. I committed all of my changes to the compiler before I got engrossed in this semester's workload: if you are feeling brave, you might be able to finish it, or at least tackle the to-do points I have made for it on Trello.

If not, I will deal with it as soon as I can.

If you'll excuse me, in the meantime, I have stillborn game code to write.
Title: Re: Trello
Post by: TheExDeus on January 14, 2013, 07:25:29 am
Soo parser?
Title: Re: Trello
Post by: Josh @ Dreamland on January 14, 2013, 09:28:59 am
The parser is done, or basically done. It's in the JDI branch with my other changes. The pretty-printer needs written, after those two to-do points are done.

All right, let me use my little remaining free-time to elaborate.
To-do point (1) on the Trello defines a class that can be used to create recursive AST operations from outside of the AST. To-do point number two helps in building the AST in more complicated EDL situations--the kind that aren't supported in the current parser, even.

Once to-do point one is complete, the pretty-printer will be written to simply implement the EDL_ASTOperator class, defining each method as necessary to print the AST out as valid C++. So AST_Node_Statement_for will print a for() statement (or hack something together with goto's if necessary), AST_Node_Statement_repeat will print a while() statement, etc.

Depending on what my schedule looks like today, I might actually get around to work on it. But I also wanted to do some maintenance on JDI, whose template handling is pretty weak.
Title: Re: Trello
Post by: forthevin on January 25, 2013, 05:28:38 pm
Just posting to say that I would like to be added on Trello, and that I plan to do the first to-do point on the parser.
Title: Re: Trello
Post by: Josh @ Dreamland on January 25, 2013, 09:49:19 pm
<rant></rant>

<tl:dr>
</tl:dr>
Title: Re: Trello
Post by: forthevin on January 26, 2013, 08:46:03 am
Yes, forthevin is the right account. In regards to committing, I have decided to make the change in a fork and then make a pull request, just to keep things cleaner.

In regards to the current parser and abstract syntax tree, I have indeed spent some time looking at it and learning from it. Using classes and inheritance instead of unions and enums to represent abstract syntax trees in C++ can be a good idea, but I must admit that I prefer tagged unions when the language used provides support for them (which C++ does not). I don't like that (Const)ASTOperator and AST_Node are so tightly coupled, but the way you have set them up should ensure that they are decoupled in practice, which is pretty neat.

There are still some changes required; in my work so far, I found out that the "friend" concept does not extend to subclasses. So, when AST_Node declares that it is a friend of (Const)ASTOperator, that does not include the children of (Const)ASTOperator, and so children of (Const)ASTOperator cannot access anything in AST_Node. So far, I have handled that issue by declaring everything in AST_Node "public" instead of "protected".

What kind of operations do you have in mind should be performed on the abstract syntax tree (apart from printing EDL to C++ and javascript)?

I don't have much in terms of plans regarding what to work on after the first to-do, but I believe that I will work towards finishing up the particle systems. It works pretty well at the moment, but there are some non-core functionality that is still missing, such as effects, attractors, changers, destroyers and deflectors, and emitters are not fully implemented yet.
Title: Re: Trello
Post by: Josh @ Dreamland on January 26, 2013, 11:58:10 am
> In regards to committing, I have decided to make the change in a fork and then make a pull request, just to keep things cleaner.
That's fine. I'll review it before I pull it, then.

> I must admit that I prefer tagged unions when the language used provides support for them
Indeed, such a system would be messier in C++. You'll find that the structures JDI uses to represent macros are similar to a tagged union; instead of a vtable, they rely on a boolean to determine whether they contain a function or a scalar. Dealing with those in C++ can be a headache, though, and so I try to limit my use of them.

Another consideration was to pack all the functions for dealing with ASTs into an array, and then use the type enum to choose the correct call from it, but arrays of member functions could prove problematic. Virtual classes seemed like the best way of dealing with the problem, but if you have a better way, it would honestly not be hard to switch them out.

> I don't like that (Const)ASTOperator and AST_Node are so tightly coupled
If this were C#, we'd use its built-in "Extension method" system that seemingly violates all manner of encapsulation, and we wouldn't need AST_Operator at all. However, this is C++, so sometimes promoting extensibility requires putting in more code to make the object extensible.

> I found out that the "friend" concept does not extend to subclasses.
Yikes. I assumed that since the methods were pure virtuals, C++ would have to let you implement them in children of any kind. Somewhat of an unfounded assumption, I suppose. Anyway, go ahead and make them all public, then; I very rarely use [snip]protected:[/snip] and almost never use [snip]private:[/snip] for this sort of reason. I thought it would be good to denote which members serve typical use-case purposes in JDI and which are for people extending or developing it, but I suppose we'll probably be the only people to ever use JDI, anyway.

Another idea, though: Could this be handled using a typedef from within the ASTOperator class? It probably cannot, but you could try it if you value the protection level.

> What kind of operations do you have in mind should be performed on the abstract syntax tree (apart from printing EDL to C++ and javascript)?
Really, I don't have any plans for them apart from pretty-printing. Those two classes were created to replace the lack of ability to add member functions to the node classes, for general-purpose recursive operations. My having a plan for them would therefore be a detriment to that purpose. In the event that there exists a more elegant way to add this capability, those classes can be scrapped. I'm open to suggestions.

> I don't have much in terms of plans regarding what to work on after the first to-do, but I believe that I will work towards finishing up the particle systems. It works pretty well at the moment, but there are some non-core functionality that is still missing, such as effects, attractors, changers, destroyers and deflectors, and emitters are not fully implemented yet.
That's fine. Like I said, I wasn't actually expecting that anyone would pick up the torch while I'm doing school things.

Even if I had the pretty-printer ready right now, there's still a cluster of little shit that needs done to the compiler to maintain its interface with the API LGM currently uses to work with ENIGMA. For instance, the new parser throws multiple syntax errors and warnings; LGM displays only one, like GM. LGM (or to be more accurate, the ENIGMA plugin for LGM) will eventually need fixed up, and Ism isn't really available to do the work, either. I have no idea how long this will get delayed as a result of the two of us being busy.


When I do have the free-time required to finish this integration and test it, the real test for this new system will be if TGMG is able to hook in his JavaScript port. That will prove that the system is modular enough to support any kind of language we want to add to it, and that it's simple enough to be read and understood by someone who did not write it.

In the meantime, the project will limp by with the old translator, which seems to be doing an "ok" job.


When this thing is all in, though, the first thing on my list is to get rid of the globals used to identify the current instance. The new pretty-printer should be in charge of passing the necessary information to each function to work with the current instance. I will probably want all the help I can get doing that.
Title: Re: Trello
Post by: forthevin on January 26, 2013, 01:22:30 pm
I have implemented and tested the changes, and submitted a pull request. I think the solution with the ASTOperator is decent, especially given that classes and inheritance are used for representing the abstract syntax tree. I have decided to let AST members stay public, since as you say the probability of someone using them outside the ASTOperator is minimal.
Title: Re: Trello
Post by: Josh @ Dreamland on January 26, 2013, 02:21:27 pm
Nicely done.
Maybe tonight or tomorrow night I'll be back on Linux and can do something myself.
Title: Re: Trello
Post by: Josh @ Dreamland on January 29, 2013, 10:12:27 am
forthevin: I'm hearing that you forgot to commit your particle attractor header. Someone posted this error over the IRC:
[snip]Graphics_Systems/OpenGL/ParticleSystems/PS_particle_system.cpp:33:35: fatal error: PS_particle_attractor.h: No such file or directory[/snip]
Title: Re: Trello
Post by: forthevin on January 29, 2013, 02:53:17 pm
I'm horribly sorry, I will be more careful in the future. They have been added in the latest commit. I only just saw it myself when I made the latest commit.
Title: Re: Trello
Post by: Josh @ Dreamland on January 29, 2013, 09:20:48 pm
No biggie; that's why git has the ability to check out previous revisions.