Is there a way to check procedures for possible problems with older Igor versions or at least show me which functions or parameters were not available for these? I am now in the situation to write some (not too fancy) code in Igor 6 on my PC to share with my group, which unfortunately is mostly on Igor 5. I haven't worked that much with Igor 5 in the past, so I don't know too well what was 'possible' at that time. Even after trying to write extra ground-down functions without (seemingly) much shorthand expressions I often have to realize that, brought over to another PC, the compilation is hanging on many details. This brings me to sit down on another members PC for quite some time to fix this stuff, blocking their and my work. I am looking for a way to improve this situation.
Well one option which springs to my mind is to capture the output of FunctionList and OperationList in all IP versions you can get your hands on. Then you can generate a 2D feature matrix of functions and operations including their first occurence like
Some more scripting further, again using FunctionList and OperationList, you could check the procedures you are writing against the target IP version and the wave from above. For Functions one can even check return values and number of parameters see FunctionInfo, for Operations I have not found any possibility to query the flags.
Of course it would be best if #pragmaIgorVersion = 5.0 would do that on its own and enforce all used operations and functions to be compatible with IP5.
We sometimes mention in the documentation when a function/operation or flag or parameter was added, but not always.
Thomas's idea will work at the function/operation level, but especially with operations we might have added new flags or keywords that OperationList has no way to track.
If it were me, I would do my best to get my group to update to the latest Igor. Igor 5 is about 10 years old now. Life is easier if everyone is using the same version of Igor.
Thanks so far for the suggestions. I will look into writing some simple check for at least the function names. If there is not too much difference between the versions it would probably be sufficient to pin a sheet of paper to my monitor with things to look out for. I sometimes see a hint on changes in the documentation, albeit that is not very useful for maintaining backwards compatibility. Of course I would like to get everyone to jump to the latest version, but unfortunately I am only in the position to appeal and not to demand.
Of course I would like to get everyone to jump to the latest version, but unfortunately I am only in the position to appeal and not to demand.
Well in that case, you might be able to attract users to new Igor versions by IPv6 only features. Using #idef and friends you can have one codebase for both. For example add some threading support which makes it much faster or add a fancy Gizmo visualization. Of course you must mention in the GUI that this feature is unfortunately only available in IP6 :)
Thomas
PS: I currently have the same need to code for some older IP version. I plan to post some code based on my ideas in the following days.
FunctionListandOperationListin all IP versions you can get your hands on. Then you can generate a 2D feature matrix of functions and operations including their first occurence likename | v5 | v6 | v6.2<br />
Grep | - | + | +<br />
DataFolderRefsEqual | - | - | +<br />
Some more scripting further, again using
FunctionListandOperationList, you could check the procedures you are writing against the target IP version and the wave from above. For Functions one can even check return values and number of parameters seeFunctionInfo, for Operations I have not found any possibility to query the flags.Of course it would be best if
#pragma IgorVersion = 5.0would do that on its own and enforce all used operations and functions to be compatible with IP5.March 5, 2014 at 03:07 am - Permalink
Thomas's idea will work at the function/operation level, but especially with operations we might have added new flags or keywords that OperationList has no way to track.
If it were me, I would do my best to get my group to update to the latest Igor. Igor 5 is about 10 years old now. Life is easier if everyone is using the same version of Igor.
March 5, 2014 at 05:43 am - Permalink
March 5, 2014 at 06:35 pm - Permalink
Well in that case, you might be able to attract users to new Igor versions by IPv6 only features. Using
#idefand friends you can have one codebase for both. For example add some threading support which makes it much faster or add a fancy Gizmo visualization. Of course you must mention in the GUI that this feature is unfortunately only available in IP6 :)Thomas
PS: I currently have the same need to code for some older IP version. I plan to post some code based on my ideas in the following days.
March 6, 2014 at 07:25 am - Permalink
Out of curiosity, what's keeping the rest of your group from upgrading to Igor 6?
March 6, 2014 at 06:09 am - Permalink
March 6, 2014 at 10:54 am - Permalink