JassHelper 0.A.2.B - A vJass and Zinc 2 Jass compiler

[Barade]

First just a little question: Don't you want to create a bug tracker for JassHelper somewhere.
It's a kind of annoying clicking through all those replies and searching for your ones to feature requests and bug reports.
I just remember you wrote something about don't using import macros in function definitions when I reported a bug about static ifs.
In fact I am using static ifs for many import macro calls since I don't need much of my code when not saving the map in debug mode.
It would be really useful to implement the ignoration of preprocessor statements.
Btw. did you delete my second memory exhausted bug mention?

[Vexorian]

Regarding the memory exhausted thing. I asked you to give me inputwar3map.j if I remember correctly we've been through this 600 times already, so please always include an inputwar3map.j with your bugs.

If you use //! import inside of static if it is likely not going to work one day, unless you are calling //! import inside a function or something awful like that, I guess.

I think I will add something like //! import debug vjass though one question, is it a big issue not just isabling the initializer of your debug library using the static if? If you are worried about the code garbage, that's really not that important altogether and gets cleaned eventually anyway...


I am not going to make any bug tracker, this is fine for me.

Edit: I could use a bug tracker but then it would have to be attached to this forum or something, don't plan moving this stuff to another site or something silly like that. I would have to code the bug tracker or try getting one from vBulletin or something like that, as of now the annoyance involved in having to do all that stuff is lesser than the annoyance I get from just using this thread.

If you are doing //! import inside static ifs, it is by far a big coincidence that it works. Really. The file is most likely being included any way. Just the static if removes the stuff AFTER it is imported.

It will not change. static ifs run after the modules phase which is faaar away from the import phase.

[Barade]

Hmm, I would have prefered something like //! if and //! define since those ifs do belong to the preprocessor phase (in my opinion) and shouldn't necessarily use Jass globals (though might be useful in some cases to give a variable the value of a definition).
The problem is that my debug library isn't small and it would be really useful to drop its code automatically when saving in non-debug mode to decrease map size for fast downloads. The problem about my inputwar3map.j is (I guess we had this about 600 times, too) that I'm using many separated files and it doesn't seem to be a code error.
I thought it would be an exception thrown by your code.
About my bug tracker suggestion:
It's not only for you as developer. People can see more easily how bug states are but anyways, it's your decision.

[Vexorian]

it is caused by my code, but I need your code to reproduce it.. If I don't reproduce a bug it is very hard to think I'll ever fix it.


Running anything like ifdef before library phase does not make a lot of sense due to how order is hard to control in Jass. The reason I went with static ifs is precisely to avoid people doing these things outside of functions. Even with ifdef, it would have to run after importing anyway...


if all you want to do is save code, just make your libraries do stuff onInit during debug mode. Then the optimizer will kill them, jasshelper will do some better optimizing soon as well.

JASS:

library myDebugLibrary initializer init
    function somethingThatIsOnlyCalledInReturnMode takes nothing returns nothing
    endfunction
    function init takes nothing returns nothing
        static if( DEBUG_MODE) then
              //blah blah blah
        endif
    endfunction
     
endlibrary

Then something like the optimizer will remove the code.

[Deaod]

Vex, optimizing explicit .evaluate/.execute calls to simple calls (if possible) in structs caused me some headaches. You might want to rethink that optimization.

At least dont optimize when explicitely stated.

[Earth-Fury]

Deaod: http://www.wc3c.net/showthread.php?t=108012

Moving the discussion here:

picking a new name for a version of .evaluate() that does the optimizations would be a very good thing. .evaluate() is named after TriggerEvaluate, so that's what it should do... Old code may get a tiny bit slower, yeah, but it won't break or anything.

Whereas, if you continue to use .evaluate() as the optimized version, the language will become even more arcane and inaccessible.

As for telling people to use .execute()... If you're hitting the op limit, you're almost surely working insanely hard to optimize the fuck out of code... sure, the value of TriggerExecute is negligible compared to the op limit, but every little bit helps.

[Vexorian]

except this little bit of help does not help at all. The amount of time a function that breaks the old limit is magnitudes higher than the difference between .execute and .evaluate. We are not talking of a difference in tens or hundreds of times but thousands of times... The more you make me think of this the less sense it makes in the first place that you wouldn't just use .execute and let me do the optimization.

Wouldn't adding a new method is the option that would makes the language less accessibl?. Never in the manual is .evaluate specified as a form to avoid the op limit but as a way to call the function. It actually does advertise .execute as a way to run it in another thread. I would have to redocument that stuff, we'll have to tell people that for some reason they shouldn't use .evaluate in the cases that the manual used to suggest but should instead use the new method...

So right now I head towards not changing anything and always allow jasshelper to optimize .evaluate calls.

Second choice is adding a method called .triggerEvaluate for your rather strange needs.

I am not going to migrate all code from .evaluate to another more random name just to conform to the idea of saving a little bitof time in situations in which it wouldn't make a difference. If you want me to rename .evaluate to something like .invoke or .run (which sound awkward in cases where you want a return value) you will need to make a good argument, like what you are trying to do and why wouldn't .execute work for it

[Earth-Fury]

TriggerEvaluate waits for the child thread to join, TriggerExecute doesn't. That alone precludes TriggerExecute for a lot of things that return a value...

Sooo... Whatever solution you pick, you will still need a .evaluate() and a .execute(), as well as a third that either replaces .evaluate() or adds the "new" functionality of ensuring a TriggerEvaluate. Why not make the names match the actual purpose, instead of the historical purposes? As for a name for the new one... .threaded() if it uses TriggerEvaluate always? (.triggerEvaluate() is just awful of a name...) If you do as I want and make the new one the optimized one, I still think .invoke() is awesome...

[ToukoAozaki]

TriggerEvaluate waits for the child thread to join, TriggerExecute doesn't. That alone precludes TriggerExecute for a lot of things that return a value...

Jass2 VM is not a multi-threaded environment. It utilizes time-sharing technique for code execution, which makes "op-limit" necessary. Due to its nature, it will not return to the calling context unless it hits op-limit or certain things like TriggerSleepAction is called.

Therefore, it is not right to simply say "TriggerExecute doesn't wait". If there is nothing like TriggerSleepAction, then TriggerExecute can still be used for that purpose.

[Vexorian]

bah, nevertheless .execute cannot return a value.

I don't like .invoke, as in... seriously.

I'd even rather just remove the method altogether.

JASS:

function interface xxx takes integer x returns integer
    
function test takes xxx F returns nothing
   local integer x = F(56)
endfunction

I don't think there is right now a case in which when a function uses .evaluate it won't run TriggerEvaluate. Is there? Then I'll just make it so .evaluate in methods forces evaluate somehow, after that normal () will work and get optimized, but that's when there is a good optimizer.

I do not think that if I make .evaluate force TriggerEvaluate, you will need it not to be optimizable for interfaces, and stubs. So those will count as using () as well.

[grim001]

.exists is broken for static methods or thistype:

JASS:

struct Foo
    static method bar takes nothing returns nothing
        if Foo.bar.exists then
            //Compile error: Malformed method passing data
        endif
    endmethod
endstruct

Also, trying to use it with a static if is broken:

JASS:

struct Foo
    static method bar takes nothing returns nothing
        static if thistype.bar.exists then
            //Compile error: Expected not, library name, or static boolean but got "Foo.bar.exists" instead
        endif
    endmethod
endstruct

[Earth-Fury]

Originally Posted by ToukoAozaki

Jass2 VM is not a multi-threaded environment. It utilizes time-sharing technique for code execution, which makes "op-limit" necessary. Due to its nature, it will not return to the calling context unless it hits op-limit or certain things like TriggerSleepAction is called.

Therefore, it is not right to simply say "TriggerExecute doesn't wait". If there is nothing like TriggerSleepAction, then TriggerExecute can still be used for that purpose.

Weaaddar once said: "Jass cannot and will not run threads in parrallel. If you somehow suceed in getting threads to run in parrallel you will get it to crash hard. (Its been impossible since around 1.03 to get them to run in parrallel)." which implies that it was, at one point, possible to get threads to run in parallel, which implies that the internal implementation is in fact based on threading...


----------------------------

Edit: Vex, I would really love textmacros calling textmacros. Do you have any idea when you'll get around to adding that?

[Vexorian]

Originally Posted by grim001

.exists is broken for static methods or thistype:

JASS:

struct Foo
    static method bar takes nothing returns nothing
        if Foo.bar.exists then
            //Compile error: Malformed method passing data
        endif
    endmethod
endstruct

Also, trying to use it with a static if is broken:

JASS:

struct Foo
    static method bar takes nothing returns nothing
        static if thistype.bar.exists then
            //Compile error: Expected not, library name, or static boolean but got "Foo.bar.exists" instead
        endif
    endmethod
endstruct

exists is only supposed to work for interfaces, I did not add them to static ifs yet.

[grim001]

Originally Posted by Vexorian

exists is only supposed to work for interfaces, I did not add them to static ifs yet.

OK, I must have misinterpreted the patch notes...

[Rikim4ru]

0.A.2.4

In Zinc I get errors for trying to use more than 1 numbers after decimal point:

BJDebugMsg(R2S(123.456));
->
Unexpected "56"