Merge OhmniParse (clever branch name right;)) Allowing parsing of real haxe files

[NicoM1]

@Ohmnivore these are my changes, some notable ones: parser is very lenient now, so while real haxe files are allowed through, so are much simpler files like:

//parser doesnt care about parameters, or class, or package, but will still compile with them

function init 
{

}
function update
{
}

I stuck with init, if you really want to change it we can, but so you know, it does not affect auto-complete. I also made the request syntax as simple as possible: request MyClass depending on your IDE this may be underlined, but it should not break completion.

One big change, that had no relation to your code, I temporarily have removed the semi-live-scripting (the version that relies on openfl's asset system, as I believe I broke it at some point, and its really not overly useful now that full-live-scripting is in...

[Ohmnivore]

You should merge lol. I haven't had the time to work on IceEntity recently, I'll be more active next week.

[NicoM1]

ok, just wanted your approval:), I'll merge once I have time to rewrite the scripting documentation....

[NicoM1]

ahhh, forgot one main feature and its turning out pretty complicated: declaring variables at the start of a script (only way to get full completion)

[NicoM1]

@Ohmnivore never thought of this: hscript doesn't have a way of calling constructors...we may have to build something like this: http://mromecki.fr/blog/post/hscript

[NicoM1]

I think I'm gonna delay merging this untill we can implement variable declarations (sorta have it working), and constructors, write the docs, maybe write some tests, and then possibly call it v1.0.0....

[Ohmnivore]

From the top of my head here's what I think about variable declarations:

1) Outside the bodies of functions you can write pretty much anything, so you can still declare stuff like "public var test:TestType;". 2) Inside functions, if we set allowTypes to true for our parser instance it might help, although I'm not sure if it handles the "var" keyword. Worst case scenario we can strip the "var" keyword away... 3) Wait I think you mentioned that hscript can't make new instances of classes. Is this for real?

[Ohmnivore]

Reading through the issues at hscript I stumbled upon this: https://github.com/DavisDevelopment/GryffinScript

It's like an augmented version of hscript, but it's quiet new and there are no docs.

[NicoM1]

for your first comment: my point isnt that we cant currently type stuff there, its that those declarations should be actually used in the script, as currently, you declare variables in init while this is fine in a script, it means you will not get completion for those variables, as your IDE considers them local to init my idea is: we can simply append those variable declarations onto the start of the init function, here is my first (ugly, likely slow) attempt: https://gist.github.com/NicoM1/095b31c2f282d39afa90

2) I couldn't get allowtypes to work, maybe I did something wrong, but for now I just strip them out with a regex (probably slow, but we have to remember this is only called if there is a change, not every time the file is reloaded). Hscript does support the var keyword, but for whatever reason whenever I try to use it I get errors, so I decided to warn against it and not worry for now...

3) Yeah:/ I never realized this either, I had only been messing with parameters on already created objects in scripts, so I never noticed, it really breaks usability currently...

I will look into GriffinScript, I remember stumbling accross that issue before, but at that point he hadn't acutally put the repo up so I couldn't check it out... I am weary of using something so new and untested....but thats kind of what IceEntity is anyway;)

[Ohmnivore]

Oh wait actually constructors do work. Maybe only a particular species of classes can't be constructed, but others work fine?

[Ohmnivore]

allowTypes half works. The following doesn't generate an error: var folder:Folder; folder = new Folder([], "TestFolder");

but the following does: var folder:Folder = new Folder([], "TestFolder"); It says that "new" isn't expected. Perhaps we can fix that?

[NicoM1]

one thing to check, constructors didn't actually fail on me, they just didn't do anything, try actually checking a value that was set in the constructor, when I tried it was always null (or whatever the default was) ie: e = new Entity("entitytag"); trace(e.Tag); traces null.

[Ohmnivore]

Hm that issue doesn't happen for this class for example: https://github.com/Ohmnivore/FlxShell/blob/master/source/flxsys/Folder.hx

[NicoM1]

hmm could you try with an IceEntity entity? just create one in your script, and trace its tag. Also, unrelated question, are you interested in becoming an official IceEntity collaborator? ie: full write access to the repo?

[NicoM1]

@Ohmnivore

[Ohmnivore]

Sorry it took me so long to respond, I've been working hard on FlxShell. With the newest ohmniparse branch I ran the following script, and the proper tag was traced. It seems that constructors are working, I can also confirm that they're working when I use them in FlxShell.

P.S.: I think pull requests are good enough, there's no need for full write access. Anyways until I start actively contributing code to IceEntity casual pull requests are easier to use, but thanks for the offer!

package ;

import flixel.FlxG; import ice.entity.Entity;

class Test { public function init() { //test = false; is added here FlxG.log.add("Test");

    x = new Entity( -1, "myTag");
    FlxG.log.add(x.Tag);
}

public function update()
{
    //we now get completion for test in functions
}

public function reload()
{

}

}

[NicoM1]

Ok, I'll look into it more (been busy myself), also, the collaborator thing was more of just an official thing, then I can put you up as part of the team, everything (other than tiny bug fixes) should be done through pull requests anyway (including my changes), still, up to you:D

[NicoM1]

@Ohmnivore SOLVED IT!!!!! oh god I feel dumb, its due to how dynamic hscript is: in standard haxe, if I type: var e:Entity = new Entity("mytag"); //omit the first parameter it will compile, because it knows that the string cannot be an Int, so it puts it in as the second parameter, wheras in hscript, it does'nt care about the types, so it passes the "mytag" string as the GID, and doesn't warn me. I think I will make GID the last parameter (as, while it used to be needed, it is now actually dangerous to mess with it, (maybe I should get rid of the option completely)), god, it feels good to figure that out, no need for messing with gryfin script:D

[NicoM1]

that last push is likely ugly, it was a rough draft done several days ago, but it does work as a proof of concept, except for one thing (at least), if a variable is not initialized, ie: var E:Entity; it will fail, as the parser will turn it into just E;. but the var and Entity are stripped out properly in general use, so what we have left to do for ohmniparse is:

• [ ] Clean up variable parser
• [x] Eliminate redundant code: var E:Entity; (remember, this does nothing, as variables don't need to be created with the varkeyword)
• [x] Look into allowing var keyword and types inside of methods (var should work in hscript, but we may want to just strip it)

[NicoM1]

tried to google: "hscript var keyword" most of the results are links to IceEntity...

[NicoM1]

so var does work, why I thought it wasn't (I believe) was because I was adding types to the variables when I used var...

[NicoM1]

so instead of using allowtypes, I'm just stripping them out with a simple regex, there are problems to this: likely the entire parsing system is farrrrr slower with all my regex usage, and if people have syntax in their comments it could cause problems potentially, but I think that can be dealt with if it ever comes up, and speed shouldn't be a real issue, I remember unity blipping for a second on reload...

[NicoM1]

@Ohmnivore I see you havent been on recently, so I'm not trying to spam you, but just for interest, do you have any thoughts on calling this v1.0.0 when its done? (I know you will probably say its up to me, but I just want to know if you think its feature-complete enough for a real (haxelib?) release)?

[NicoM1]

ok, I think this might be ready, @ibloat @gamedevsam are either of you willing to play around with this before release, to make sure its not too bug filled? the new readme should explain everything, note that this is in no way backward compatible, but I think thats ok because its for one a major increment, and also the 1.0

[NicoM1]

oh and I know the gifs need to be updated, will do soon

[Ohmnivore]

Pretty cool! I'll check for bugs later tonight.

[NicoM1]

Thanks, unfortunately just thought of two major missing features (by all means still test if you're willing, but will have to delay release again:/)

• [x] Parsing functions, so you can call functions as you would in a real class (hscript supports it, but currently you actually have to declare your functions inside of the init function, which is ugly and ruins the feeling of coding in haxe)
• [x] Live variable-reloading, this I'm not so sure about, but I feel that if you add a variable it should be usable without reopening the game, but this could be hard due to the fact that if you reload them all then you are resetting some things, going to have to figure out a way to determine what has and hasnt been already added, and add everything that hasnt been added into the reload function (I may actually work on this after release, less critical)

Personally I think its kind of cool how all the solutions I've found to these problems, eg. getting variables from the declarations at the top, have involved just hacking into the parsed scripts before passing them to hscript (that might only make sense to me)

[NicoM1]

maybe, temporarily, I'll add another special syntax: //@ ... //@ for placing all your helper functions in, shouldn't be too annoying I dont think, although when I have time to think about I'm sure I could find a better way (ignore the script functions somehow)

[NicoM1]

nothing is ever as easy as I feel it should be, just realized variable parsing isnt working for scripts without a class, even though I built it so it would

[NicoM1]

@Ohmnivore how does this syntax for variables and functions look to you? https://gist.github.com/NicoM1/df04e3e80fc878c54c05

[NicoM1]

@Ohmnivore I've been busy/procrastinating lately, do you think its worth pushing this update without live-reloading for functions or variable declarations?

[Ohmnivore]

Yeah I think you should push this update. The new system is way better than what the old system was, even if it's not finished yet. Man I haven't checked this code in a while, I'll have to get used to it again. Also I'm out of town from Tuesday till Sunday, but I'll try to get the template thing going once I come back. I'm so tired of parsing lol.

[NicoM1]

I think I agree, maybe I'll say its a release-candidate not a 1.0, as for the code, its a mess of hacks, your flxshell stuff looks much cleaner, I did about 3min work on variable reloading, got fed up and played with other stuff, my motivations gone for a bit, so probably better to get people interested again to renew my own interest. I think I'll check through it once more tommorrow and then check the docs, and then push it. Just realized I havent even commited the function parsing stuff.

On another note, you seem to be interested in compilers/interpreters and parsers, I found this: http://jayconrod.com/posts/37 Its really interesting, although I find the python to be a huge, huge language barrier, do to it being so non-strict, I have a lot of trouble actually duplicating its code, its why I always type my variables even though I dont need too...but nonetheless, its an interesting read, I've finished the initial tokenizer section into haxe (yeah, I should have done iceentity work but I'm stuck)

[NicoM1]

I got functions to reload, variables should too but something is wrong....

[NicoM1]

ugg it always comes back to the "var" keyword, I'm gonna strip it out again

[NicoM1]

ugg now I broke it and I never committed it, ahhhhhhhhhhhhhhhhhhhhhhhhhh I dont know what I did

[NicoM1]

@Ohmnivore well....this is probably the uggliest code I've ever written....but....IT WORKS....(I think) basically, on reload, variables are checked to see if they already exist, and if not, are stuck on top of the users reload function, that way, by the time they attempt to call a function or access a variable, it has already been created inside of reload, I'd Love if you could do some testing, or especially if you have time to see if you can think of ways to clean it up:D

[NicoM1]

@Ohmnivore woops, the new system wasnt checking for blacklisted or blocked expose attempts:O

[NicoM1]

hmm, scripthandler should probably be blocked by default, otherwise a hacker could unblock a class themselves:O

[NicoM1]

ok, so that will close #12

Notable things:

~entity's are not created unless they have instance="true" as an attribute or have a matching <instance/> element

~instances can override tag and position of templates

~I did some refactoring, just split some stuff up, I recommend that when you come back, you make the same changes to your json parser, that way we can have readable code, and also templates and instances can be added to the json easily as well:D

[NicoM1]

@Ohmnivore sorry to pester, but I'd like to make this public soon, and I'd rather you test it out first, thanks:)

[Ohmnivore]

Hey Nico, I've done some thinking since I came back from vacation and realized that I was sacrificing too much for my coding habits. I'm really tired of it all now. I also need to take care of lots of things I was neglecting, so that will keep me busy.

This means you probably won't see me working on projects anymore. This decision doesn't have anything to do with anyone, it's just something I was going to realize sooner or later. I don't think this is the end forever, but yeah I'll stay away from the computer for a month or so.

Long story short: I was programming at the expense of my health, social life, etc., now I want those things back xD

Best of luck with your projects!

[NicoM1]

I completely understand, you shouldn't sacrifice your life for a hobby. I hope you can manage to find a compromise that let's you keep everything, but until then, good luck:D

On 2014-07-23, at 12:58 PM, Ohmnivore notifications@github.com wrote:

Hey Nico, I've done some thinking since I came back from vacation and realized that I was sacrificing too much for my coding habits. I'm really tired of it all now. I also need to take care of lots of things I was neglecting, so that will keep me busy.

This means you probably won't see me working on projects anymore. This decision doesn't have anything to do with anyone, it's just something I was going to realize sooner or later. I don't think this is the end forever, but yeah I'll stay away from the computer for a month or so.

Long story short: I was programming at the expense of my health, social life, etc., now I want those things back xD

Best of luck with your projects!

— Reply to this email directly or view it on GitHub.