New Script Optimizer

[Troll-Brain]

I don't get this sentence :

Also I don't remove the white-spaces, they just aren't printed.

So if a map script contains X white spaces, they will be kept, no matter they are not necessary ?
Or, white spaces in strings are also removed ?

 

[Magtheridon96]

Actually, it would be looping through every 6 characters and if the string is equal to "==true", then you would do nothing but add 6 to the index in the loop and skip it
But, if the first character is ", then you'd have to loop until you hit another " (making sure the character before it has isn't a backslash. :3
When you hit the second ", you'd continue deleting.

 

[Frotty]

I don't get this sentence :
So if a map script contains X white spaces, they will be kept, no matter they are not necessary ?
Or, white spaces in strings are also removed ?

No. As I said, Froptimizer will/is part of WurstScript Compiler (a project me and peq are working on).
And the JassPrinter module has 2 modes, 1 with whitespaces and one without.
Basically I'm just not looping through the whole script.

Actually, it would be looping through every 6 characters and if the string is equal to "==true", then you would do nothing but add 6 to the index in the loop and skip it
But, if the first character is ", then you'd have to loop until you hit another " (making sure the character before it has isn't a backslash. :3
When you hit the second ", you'd continue deleting.

dont overcomplicate it.

Btw @the EF and TRVE name compressing.
At the moment they are handled this way:
-If the argument inside EF/TRVE is only a constant string, it will be compressed.

-If it is a mix of a constant string and an expression, e.g. I2S all functions that have the same pattern ( const + expr | expr + const | expr + const + expr ) will be ignored from name compression.

You could ofc compress the constant part of the pattern, but what the heck, just use short names if you wanna have expressions in EF/TRVE

 

[Troll-Brain]

Glad to know that you've choiced the hardest but most powerfull way to handle ExecuteFunc.
I suppose you will do the same with (globals) real variables and TriggerRegisterVariableEvent ?

Btw what is WurstCompiler, "just" a jass script optimizer (don't take me wrong i'm not trying to reduce its usefulness), or more ?

 

[Frotty]

Glad to know that you've choiced the hardest but most powerfull way to handle ExecuteFunc.
I suppose you will do the same with (globals) real variables and TriggerRegisterVariableEvent ?

Btw what is WurstCompiler, "just" a jass script optimizer (don't take me wrong i'm not trying to reduce its usefulness), or more ?

Yea. Choiced.
I did write EF/TRVE since they are kinda the same
What about global reals?

WurstScript will be a new scripting language (will be presented here soon~)

 

[Magtheridon96]

Any samples of what WurstScript is going to look like?
I hope you don't change the verbosity
We're all used to that ;/

 

[Frotty]

adapt

 

[Troll-Brain]

I don't make typos, i make new wrods, and in my world choiced = chosen.

What about global reals?

You mean you won't handle local reals ? seems fine.

Verbosity is such an ugly thing, Zinc is quite good, as a concept.

 

[Frotty]

Wurst will be python-like, but lets keep on topic.

And do you mean reals used within TRVE or what?

 

[Troll-Brain]

I don't know what TRVE stands for, but i just mean reals used by TriggerRegisterVariableEvent.
Btw, the "__protected" keyword i've suggested should still be also implemented, because sometimes the string argument could be a variable without any constant string.

OFF-TOPIC :

Erf, indent based language.

 

[Frotty]

what is it with reals used in TRVE (TriggerRegisterVariableEvent).

 

[Troll-Brain]

Same than a function with ExecuteFunc, no more, no less.
I just don't think that it does make sense to handle local reals and TRVE together, even if it's possible, it's a senseless usage.

 

[Bribe]

Locals don't work with TRVE. Though it is pretty pointless to handle I2S calls with that event, as it's nowhere near as dynamic as ExecuteFunc.

Just remember to not call TRVE or ExecuteFunc on a variable with name "S" if there is a name "s" because the JASS interpreter ignores capitalization.

 

[Troll-Brain]

Did some tests :

/*
wc3 version : 1.26.0.6401
text displayed :

variable event x
variable event X
variable event x
variable event X
f1
F1

*/

library Test initializer init

    globals
        real x = 0
        real X = 0
    endglobals

    function f1 takes nothing returns nothing
        call BJDebugMsg("f1")
    endfunction
    
    function F1 takes nothing returns nothing
        call BJDebugMsg("F1")
    endfunction
    
    function F takes nothing returns nothing
        call BJDebugMsg("variable event local")
    endfunction
    
    private function VE_x takes nothing returns nothing
        call BJDebugMsg("variable event x")
    endfunction
    
    private function VE_X takes nothing returns nothing
        call BJDebugMsg("variable event X")
    endfunction
    
    private function init takes nothing returns nothing
        local trigger trig
        local real r = 0
        
        call TriggerSleepAction(0) // for message available in the box
        
        call TriggerRegisterVariableEvent(trig,"r",EQUAL,1)
        call TriggerAddAction(trig,function F)
        set r = 1
        
        set trig = CreateTrigger()
        call TriggerRegisterVariableEvent(trig,"x",EQUAL,1)
        call TriggerAddAction(trig,function VE_x)
        
        set trig = CreateTrigger()
        call TriggerRegisterVariableEvent(trig,"X",EQUAL,1)
        call TriggerAddAction(trig,function VE_X)
        
        set x = 1
        set X = 1
        
        call ExecuteFunc("f1")
        call ExecuteFunc("F1")
    endfunction

endlibrary

Conclusion :

Yep, local reals don't work with TriggerRegisterVariableEvent, so no problem.
Yes, TRVE don't care about the case, which shouldn't be a problem for a decent coder, but must be definetely taken in consideration for a script optimizer.
No, ExecuteFunc hopefully care about the case.

 

[Bribe]

Hmm ExecuteFunc is case sensitive now? I wonder though if it would still execute the wrong-case function if the right-case function was not found.

 

[Troll-Brain]

Hmm ExecuteFunc is case sensitive now? I wonder though if it would still execute the wrong-case function if the right-case function was not found.

Are you sure you don't confuse with gamecache ?
I've never used ExecuteFunc but that doesn't really make sense, his behavior probably has never changed during patches.

I will test your doubt right after my lunch.

Done :

/*
wc3 version : 1.26.0.6401

displayed text :

no crash, yeah !

*/

library Test initializer init

    function f1 takes nothing returns nothing
        call BJDebugMsg("f1")
    endfunction
    
    function F2 takes nothing returns nothing
        call BJDebugMsg("F1")
    endfunction
    
    private function init takes nothing returns nothing
        local trigger trig = CreateTrigger()
        local real r = 0
        
        call TriggerSleepAction(0) // for message available in the box
        
        call ExecuteFunc("")
        call ExecuteFunc(null)
        call ExecuteFunc("/n")
        call ExecuteFunc("this is a sentence")
        call ExecuteFunc("whatever")
        
        call ExecuteFunc("F1")
        call ExecuteFunc("f2")
        
        call BJDebugMsg("no crash, yeah !")
    endfunction

endlibrary

Now, that i'm posting it, i remember that ExecuteFunc made a wc3 crash when an invalid string argument was used (at least that's what i've read).
So it could make sense that his previous behavior was not case sensitive.

An unknown old bug fix is still better than an unknown new bug

 

[Frotty]

the strings used for TRVE and EF are lowercase and start with a "z", the "z" is not used in the normal compressed ones.
Shouldnt get any mix-up there.

 

[Troll-Brain]

See, there !
It seems better than wc3mapoptimizer.
Speedfreaks will probably stop their lame short names usage.
And then jass submissions will be better.

 

[Frotty]

See, there !
It seems better than wc3mapoptimizer.
Speedfreaks will probably stop their lame short names usage.
And then jass submissions will be better.

Yes, we hope so.
That short naming shit is really annoying

 

[Troll-Brain]

To be honest if i would be mod, i would reject such resources.
Hell, even historic languages where the short names had a reason tend to forbid this behavior.

Like the "new" C convention : C99 (i know it's not the newest but all features are still not yet fully implemented even for popular compilers, such as gcc).

I mean there is a simple reason behind that :

human != computer

Sorry for off-topic but i had to say it

 

[Bribe]

Yeah the speed difference to be gained from short names is pretty much only useful for stuff that happens many times per second and on a really poor computer like mine. And at that you'd have to be talking thousands of operations per instance that all have to do with those variables.

 

[Luorax]

To be honest if i would be mod, i would reject such resources.

I'd delete them instantly, telling the owner that trolling is not allowed here. But that's just me, for some reason, even sh*t code is approved sometimes.

I did not read the whole thread, so let me ask: is there an ETA already? I'd use it on my map once both is done.

 

[Bribe]

"Sh*t code" being approved is just because I have to do something with it. I first told other people to take the position because I have only been coding for X amount of time but none of the more qualified people were interested in the job. I made some mistakes and took some early action at some points, but the choice was either for me to do it or for no one to do it. If someone else comes along like Troll-Brain whose got the time I don't mind him taking over.

 

[Frotty]

"Sh*t code" being approved is just because I have to do something with it. I first told other people to take the position because I have only been coding for X amount of time but none of the more qualified people were interested in the job. I made some mistakes and took some early action at some points, but the choice was either for me to do it or for no one to do it. If someone else comes along like Troll-Brain whose got the time I don't mind him taking over.

Cool story bro.
now get back on topic.

project will be released when i got the updater working.

 

[Troll-Brain]

So that means all the features are already implemented ?

Or good enough for now, but you're still implementing some ?

 

[Frotty]

the optimizer has all mentioned features implemented, Wurst has enough to make some stuff

 

[Troll-Brain]

Btw, you reserve one letter for locals variables ?

 

[Troll-Brain]

Some other ideas :

- Player(X), should be remplaced by P[X] where P is a global player array initialized with the 16 players.
- Same for GetLocalPlayer(), except of course it doesn't need to be an array (you can't use GetLocalPlayer in a global definition, because wc3 crashes, but the "main" function is enough for that)
- Remove unused variables (yes it is very possible to have many of them, especially using vJass, think about scope/library created in an empty trigger, there is still the gg_trg... trigger globals lying in the script)

Also i repeat myself, but plz allow it to be used in command line, it's not hard to implement anyway and will be useful.

 

[Frotty]

Btw, you reserve one letter for locals variables ?

no

Some other ideas :

- Player(X), should be remplaced by P[X] where P is a global player array initialized with the 16 players.
- Same for GetLocalPlayer(), except of course it doesn't need to be an array (you can't use GetLocalPlayer in a global definition, because wc3 crashes, but the "main" function is enough for that)

The user can do that without a problem

- Remove unused variables (yes it is very possible to have many of them, especially using vJass, think about scope/library created in an empty trigger, there is still the gg_trg... trigger globals lying in the script)

Unused functions and variables will be removed by the inlining module.
But vJass won't be supported anyway.

Also i repeat myself, but plz allow it to be used in command line, it's not hard to implement anyway and will be useful.

there is a cmd line for wurst, but don't think its needed.

 

[Troll-Brain]

no

Hmm it's bad since if you do that, you will be able to use many more times one letter words.

The user can do that without a problem

Not really it's annoying to have a library with an initializer just for that.
I prefer use Player()

Unused functions and variables will be removed by the inlining module.
But vJass won't be supported anyway.

While i understand it's a pain in the ass to support multiple grammars, i'm lost, are we not talking about a script optimizer here ?!
I mean we are not talking about a jass preprocessor here.
If you want to talk about wurst, you should create a new thread.

there is a cmd line for wurst, but don't think its needed.

Actually i was suggesting it for the script optimizer.

Btw i'm afraid now, are you basically saying that we won't be able to use the script optimizer without your jass preprocessor, all will be merged ?

 

[Nestharus]

Ok, if you are doing a whole new script, here are some things you should probably let everyone know about...


support for importing external script files
Lua support (is it still a pain in the ass to do it in WE, or is it just plain not supported?)
all the other pre processing stuff vjass supports
nested macros?
macros calling macros?
smart modules?
smart inliner?
will the syntax still be open for w/e (like structs that extend arrays), or are you forcing private code like a lot of the scripting languages for SC2 do.


I'm personally of the idea that Lua would be a wonderful preprocessing language since it's already used by grimoire.

etc

 

[Frotty]

While i understand it's a pain in the ass to support multiple grammars, i'm lost, are we not talking about a script optimizer here ?!
I mean we are not talking about a jass preprocessor here.
If you want to talk about wurst, you should create a new thread.
Btw i'm afraid now, are you basically saying that we won't be able to use the script optimizer without your jass preprocessor, all will be merged ?

Yes, I mentioned that 2 times allready...
The optimizer will be inbuilt into the compiler, since it uses the same parsing.
I could probably make it as a halfass standalone application, but things like inlining and removing unused stuff is much easier to handle by the compiler.

Ok, if you are doing a whole new script, here are some things you should probably let everyone know about...

support for importing external script files y
Lua support (is it still a pain in the ass to do it in WE, or is it just plain not supported?)
all the other pre processing stuff vjass supports
nested macros?
macros calling macros? there won't be any macros
smart modules? whatever you understand by that
smart inliner? y, also forced inlining at some point
will the syntax still be open for w/e (like structs that extend arrays), or are you forcing private code like a lot of the scripting languages for SC2 do.
Wurst will be very different from vJass and I don't know what sc2 does tbh.

etc

The Thread will be opened soon enough, so dont post it here.

 

[Troll-Brain]

Hmm, i'm really disapointed then, a standalone optimizer is a must for me, not a should (ofc this is just me, and it's not an order ...)

 

[Luorax]

Okay, wassup with the optimizer? I'd like to use a proper optimizer that's capable of compressing names; I'd spare almost half a MegaByte with that. So, how is it going?

 

[Frotty]

It is working, but as you can see above, it is not a standalone application but implemented into a compiler.

 

[Troll-Brain]

I said that you couldn't expect that the jass vm prioritizes locals against globals variables, in case they share the same name, but it appears i was wrong (or it was true in an older patch).
Maybe you've probably tested yourself, but meh i had to say it.

Here is a proof

 

[Frotty]

No, I didn't know that. If it really works I will probably implement own shortnames for each function.

Oh and I also implemented your Jass Grammar thing - mostly. The names now also may contain numbers after digit 1.

 

[Troll-Brain]

Good, all you need now is to make the script optimiser standalone

 

[Frotty]

nah

 

[Nestharus]

so are you saying that people have to use your special language in order to use the optimizer?

 

[Frotty]

I wanted people to use it as standalone, now it's not standalone anymore, but a feature of wurst.
The optimizer does does most optimizations on the intermediate language (between wurst and jass). Ripping it out of the enviroment wouldn't be easy to do and some features would be missing (have to write a jass parser just for that).
As said 10 times before, yes.
Maybe there will be a standalone, but it's not a high priority

 

[Nestharus]

Maybe there will be a standalone, but it's not a high priority

then have fun using it on your own ^)^. I doubt the community will turn all JASS and vJASS into your own special language just to use your optimizer. I know I certainly won't ; ).

 

[Frotty]

Lol. as if it's about the optimizer.

 

[Frotty]

Sooo, I wrote a jassParser (which will get public when I finish validating) and rethought the idea of a standalone Optimizer and revived Froptimizer.
The basic features are implemented and should work, as all of my testing did.
Download & extract the File from the first post and run FroptimizerUI.jar

Even though vexorian fixed the native-bug in his optimizer, he doesn't fix it in EF and TRVE (?) so imo this project still has the right to exist and will be updated with more features regarding mapscript-optimization and maybe a few general optimizations.

Please test & report any bugs. Thx

 

[Magtheridon96]

He could easily fix them, so what I suggest is to make yours better in order to keep it alive.

 

[Frotty]

It's not always about better, but also different.
I could design a small executable which would be executed by grimoire after mapsave so that you could test your map with an optimized code without having to externally/manually do it.

And it might get better inlining functionality which vex' probably won't add.

 

[Troll-Brain]

It's not always about better, but also different.
I could design a small executable which would be executed by grimoire after mapsave so that you could test your map with an optimized code without having to externally/manually do it.

Go for it.
You will even have more testers, as JNGP is the most common way to write (v)Jass code.
It will also make benchmarks code more realiable, or at least less annoying to do.

 

[Frotty]

Go for it.
You will even have more testers, as JNGP is the most common way to write (v)Jass code.
It will also make benchmarks code more realiable, or at least less annoying to do.

I will when I finished my JassParser so it can replace pjass, as I need it to build the AST for the optimizer anyway.

 

[Troll-Brain]

I'm really glad you've reconsidered the idea of a standalone optimizer.
Now, i could also hope that you would also implement a command line.

 

[Frotty]

Well, adding a commandline to the .jar isn't that big of a deal, but how would that help you?