Test for Recompile?

Share icon

Mon, 08/09/2010 - 11:58 am

How can I test for a recompile in an experiment? Ideally, I want to have a "hook" so that I can run a function after a user puts a #include statement in the general procedure window and recompiles.
I don't think there is a specific built-in hook for this situation. Do you really need a hook function? How responsive do you need to be? Is it not sufficient to rebuild, say, a list of the functions (FunctionList()) presently available or a list of the presently open windows (WindowList(), maybe with optional parameter "INDEPENDENTMODULE:1") just before you do whatever you're doing?
Wolfgang

August 13, 2010 at 03:59 pm - Permalink

harneit wrote:
I don't think there is a specific built-in hook for this situation. Do you really need a hook function? How responsive do you need to be? Is it not sufficient to rebuild, say, a list of the functions (FunctionList()) presently available or a list of the presently open windows (WindowList(), maybe with optional parameter "INDEPENDENTMODULE:1") just before you do whatever you're doing?


Actually, I would specifically like the equivalent of an AfterRecompile() hook function. I want to auto-initialize a newly loaded procedure file such that it stores information about itself in the experiment directly after it is loaded. Here is a very simple example of what I do NOT want to have to do (even in this simple form).

Function Initialize()

    // do the auto-initialization
    variable/g autoi=1
    return 0
end

Function DoSomething()

     // are we initialized?

     NVAR/Z autoi
     if (NVAR_exists(autoi))
         Initialize()
     endif

     // now do the function stuff
     // ...

     // ...

     return 0
end


I know this works, however it drags in significant overhead this way when for example the DoSomething() function is called from a long for-endfor loop.

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

August 13, 2010 at 08:52 pm - Permalink

Igor reestablishes dependencies after a recompile, so if you have:

Variable/G input;
Variable/G output := AfterCompileHook(input)

Function AfterCompileHook(var)
    Variable var
   
    Print datetime
    return 0
End


you might get what you want.

--Jim Prouty
Software Engineer, WaveMetrics, Inc.

August 13, 2010 at 11:40 pm - Permalink

JimProuty wrote:
Igor reestablishes dependencies after a recompile, so if you have:
....
you might get what you want.


I created a procedure with this, saved and killed it, and then re-opened it and recompiled. I also killed it and did an #include "...".

Either way, it does not do anything.

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

August 14, 2010 at 09:49 am - Permalink

It works only if it you have a dependency (the name is arbitrary):
Use either := or SetFormula.
Variable/G input;
Variable/G output := AfterCompileHook(input)

--Jim Prouty
Software Engineer, WaveMetrics, Inc.

August 15, 2010 at 11:21 pm - Permalink

JimProuty wrote:
It works only if it you have a dependency ....


Oh! Oh, oh, oh!

The first two lines are executed on the command line in order to create the input/output variables. They are not part of the procedure file.

Now I see how it works. Thanks!

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

August 16, 2010 at 05:51 am - Permalink

JimProuty wrote:
Igor reestablishes dependencies after a recompile....


OK, great! This has worked wonderfully to set up a function that will automatically initialize a package after Igor completes a compile cycle. Basically, I have a function that checks for and executes all functions of a certain template type:

Static Function AfterCompileHook()

    string theList, theOne
    variable ic, nt
   
    theList = FunctionList("PTAfterCompileHook_*",";","KIND:7")
    nt = ItemsInList(theList)
    for (ic=0;ic<nt;ic+=1)
        theOne = StringFromList(ic,theList)
        FUNCREF AfterCompileHookProto f = $theOne
        f()
    endfor 
    return nt
end


The one problem with this is, any function of the template type that is within an independent module is invisible. The way around this involves knowing the name of every independent module in the current experiment. Does a way exist to get this information? The function would then run as follows:

Static Function AfterCompileHook()

    string theList, theOne, theIMList, theIMOne
    variable ic, nt
   
    theList = FunctionList("PTAfterCompileHook_*",";","KIND:7")
    nt = ItemsInList(theList)
    for (ic=0;ic<nt;ic+=1)
        theOne = StringFromList(ic,theList)
        FUNCREF AfterCompileHookProto f = $theOne
        f()
    endfor
    theIMList = IndependendModuleList()
    nt = ItemsInList(theIMList)
        Execute/Q/Z "SetIgorOption IndependentModuleDev=1"
    for (ic=0;ic<nt;ic+=1)
                theIMOne = StringFromList(ic,theIMList)
                sprintf theList, "KIND:23,WIN:[%s]", theIMOne
        theOne = FunctionList("PTAfterCompileHook_*",";",theList)
                if (strlen(theOne)!=0)
                       sprintf theOne, "%s#%s", theIMOne,theOne
               FUNCREF AfterCompileHookProto f = $theOne
               f()
                       nt+=1
                endif
    endfor 
        Execute/Q/Z "SetIgorOption IndependentModuleDev=0"
    return nt
end


ADDENDUM:
Based on a bit of playing around, I think that having a way to get a list of independent modules would make the above AfterCompileHook function solid and reliable as a way for programmers to interface and initialize their packages as "plug-and-play modules" into an experiment. Whatever the name space (ProcGlobal or Independent Module) of a procedure file, one could use this type of function to assure that it was always initialized properly when opened or included without having to play games within the procedure file itself in determining when/how to append ProcGlobal and when/whether to use Execute or not. The use of such a robust AfterCompileHook() function that itself calls template functions (PTAfterCompileHook_* in this case) would also cut out the need to have Initialize() type functions throughout every function call in a procedure file when that procedure file requires some type of initialization or setup to run properly.

Even better would be when Igor recognized hook functions of the form IgorAfterCompileHook() entirely on its own!

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

August 19, 2010 at 10:34 am - Permalink