Procedure loading dependency tree

Dear Igorians,

Is there a way to ensure that my procedure is loaded last by Igor upon start (i.e. after some dependencies have been loaded already)?

All help is much appreciated.
thomas_braun wrote:
May I ask the bold question what you like to do?


I am facing a bunch of functions written by somebody else. This code is comprised of a large number of functions and external functions with their own dependencies. As I use some of the functions from that body of code every now and then I get an error, as something hasn't been loaded yet by Igor upon igor start. But the moment I start adding ipf includes then the dependency walk starts getting deep and convoluted. This could be due to the way the code is written, but this is another story.

If I load my functions after loading has been complete, dependencies have settled, and all is good.

best,
_sk
#include really is the right way to do it.

If you have some package involving multiple procedure files that you want to be loaded when Igor starts up, put the package files in User Procedures and prepare a single procedure file that contains nothing by #include statements for the various procedure files needed. Put that master file into Igor Procedures.

And, of course, the User Procedures and Igor Procedures folders should be the ones in the Igor Pro User Files folder.

If doing this results in errors of some sort, then you have some problem other than #include statements. Do you have functions with the same name defined in multiple procedure files? In that case, you may need the Static keyword to hide some of those function definitions outside of the file where they are defined.

If this doesn't address your problem, perhaps you could give us some more details on exactly what sorts of errors occur.

John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
johnweeks wrote:
#include really is the right way to do it.

If you have some package involving multiple procedure files that you want to be loaded when Igor starts up, put the package files in User Procedures and prepare a single procedure file that contains nothing by #include statements for the various procedure files needed. Put that master file into Igor Procedures.

And, of course, the User Procedures and Igor Procedures folders should be the ones in the Igor Pro User Files folder.

If doing this results in errors of some sort, then you have some problem other than #include statements. Do you have functions with the same name defined in multiple procedure files? In that case, you may need the Static keyword to hide some of those function definitions outside of the file where they are defined.

If this doesn't address your problem, perhaps you could give us some more details on exactly what sorts of errors occur.

John Weeks
WaveMetrics, Inc.
support@wavemetrics.com


Thank you for the comment. I agree that this is the way to do multi-file function dependencies. But I have code at my hand that does not comply with these recommendations. Unfortunately, I cannot rewrite the code due to the sheer volume of it and I cannot influence the people responsible to do so either.

At any rate, I came up with a hacky solution: figuring out which is the last function to be loaded and execute/p including my file from a non-special directory.

best,
_sk
Sorry for begin so persistent but I'm not understanding it completely.

How can you write code in IP that depends on the order of compilation?
All code in ProcGlobal, or an IM, is compiled at the same time. So either all compiles, it does not compile, or you found an Igor bug.
thomas_braun wrote:
Sorry for begin so persistent but I'm not understanding it completely.

How can you write code in IP that depends on the order of compilation?
All code in ProcGlobal, or an IM, is compiled at the same time. So either all compiles, it does not compile, or you found an Igor bug.


I don't know what the corner case here is. Probably it has to do with buried execute/p "DELETEINCLUDE " and execute/p "INSERTINCLUDE " statements somewhere. And before I forget, I am certainly not advising such coding practices.

best,
_sk
_sk wrote:

I don't know what the corner case here is. Probably it has to do with buried execute/p "DELETEINCLUDE " and execute/p "INSERTINCLUDE " statements somewhere. And before I forget, I am certainly not advising such coding practices.

Very seductive and bad. When that was all new (several years ago...) I wrote a clever package that actually generated procedure code programmatically. Since you can't manipulate procedure window text programmatically, it generated it in a plain text notebook, saved the notebook and closed it, then used execute/p "INSERTINCLUDE " to load it. Pleased with my cleverness I included it as a package in the next Igor release. I quickly found that the whole thing was much too clever and fragile and pulled the package from the next release. I spent maybe a year of answering tech support queries about how to undo the effects of my cleverness.

John Weeks
WaveMetrics, Inc.
support@wavemetrics.com