Reference++? What the hell is leaking here.

06-06-2006, 04:08 AM

I'm working on a compiler that will take a lambda calc like code and convert it to jass.

I want to do in-thread evaluation of passed in function.

I.e.
(define mergesort
(lambda (list pred)
....)))

Where pred would be a function past to mergesort which would define how sorting was done.

I was hoping that boolexprs would allow passing wrong values, but since it doesn't I decided to exploit the fact that evaluating a triggers condition will have to execute the function and return its value. (true or false). Using that I just pass it the function to evaluate and I want to store things in my environment. The environment will probably be like a list of lists of symbols and variables.

However, just toying with the system I seem to have discovered something is leaking and I have no idea why.

JASS:

function Tester takes nothing returns boolean
    local trigger t=GetTriggeringTrigger()
    call BJDebugMsg(I2S(H2I(t)))
    set t=null
    return true
endfunction
function testescape takes nothing returns nothing
    local trigger t=CreateTrigger()
    local conditionfunc bx=Condition(function Tester)
    local triggercondition tc=TriggerAddCondition(t,bx)
    call TriggerEvaluate(t))
    call TriggerRemoveCondition(t,tc)
    call DestroyCondition(bx)
    call DestroyTrigger(t)
    set t=null
    set bx=null
    set tc=null
endfunction

Each time I run testescape the reference count goes up! Why? Shouldn't it be recycling entries? I'm pretty damn sure I kill everything and its mother..

Non edit:
DestroyCondition is broken! Joy of joys it doesn't do shit. In its place use call DestroyBoolExpr(bx). It then uses the same four or so references over and over again, which I can live with.

06-06-2006, 05:44 AM

PipeDream

Quote:

Non edit:
DestroyCondition is broken! Joy of joys it doesn't do shit. In its place use call DestroyBoolExpr(bx). It then uses the same four or so references over and over again, which I can live with.

So that's a solution? OK.

Goddamn.. I've been working on an interpreter. You're going to blow it out of the water if you write a compiler.

06-06-2006, 01:32 PM	#3
Vexorian	If you just destroy the boolexpr the condition won't leak?

06-06-2006, 01:34 PM

weaaddar

It's very basic right now, the only three things I'm trying to get at this point are

JASS:

exp::=symbol //symbol is a metavariable, variable look up.
exp::='lambda'(symbol) exp // anon function declaration.
exp::=(exp exp) //function application.

Considering that the above code is roughly what a function application and declaration will look up, my code will probably not really be the optimal solution.

edit:
Vex, no you need to destroy the boolexpr, the triggercondition, and the trigger or else the reference count keeps flying up with each execution.

However, as a slight optimization I might just keep one global trigger to use as my execution trigger and add triggerconditions and possibly cache boolexprs to save time.

06-06-2006, 02:38 PM	#5
Vexorian	That explains cubasis' experiment that had the conclusion that triggerremovecondition didn't work so you had to destroy the boolexpr as well, that's good to know may be I'll start using trigger conditions now that I can clean them.

06-06-2006, 02:44 PM	#6
weaaddar	Yeah, its going to use the same 3 or 4 references in a loop. 17 18 23 17 18 21 23... Such a small amount of references is small enough that I won't care. get on irc.