Talk:IGOR Pro Developers Working Group
Hello All,
Now with the canSAS report out, and the creation of the wikis, we can really get started. Right before the holidays, of course, when everyone will be on vacation and not excited to do a lot of coding...
Anyways, I thought it would be good to re-focus what we are trying to accomplish, and what steps we can take (easiest first). This is my first pass at the list. This e-mail has been crudely pasted on the wiki, since this should morph into our list.
--Steve
What do we want? - things we really need to be able to do
(1) avoid code namespace clashes so we can all get along well together. This means internal structures, functions/macros, and XOPs.
(2) documentation of file formats, so we can read each others' data (reduced data, ready for analysis)
(3)...
What would we like? - things that would make our lives easier (maybe)
(1) code to share - common readers, analysis models/modules, so we can all save some work.
(2) common internal data handling***
(3)...
What do we do about these things?
For "Want" #1:
- the suggestion of putting intermediate "stuff" into facility specific data folders such as "root:Packages:NIST:" is a good one, and we'll implement that. If someone has "root:Packages:XXXXX:" lying around somewhere, it's probably not a big deal if "XXXXX" is obscure enough.
- Naming conventions for functions. "_KCL" or similar tags is an OK idea. Maybe just one letter as a suffix tag? I'd hate to give away 4 when I can only use 31 to start with.
- So we can each test for conflicts, there needs to be a simple way for us to include each others procedures - master #includes that bring up menus with more choices of what to include (and remove!) are good code snippets to put on the wiki. And a link to everyone's "current" version to test against.
- Use Igor to the fullest. There are ways of hiding functions from the global namespace. Static declarations, and #pragmas Module or IndependentModule increase the coding complexity slightly, but keep a tighter control on the namespace. I will look to use these wherever I can.
- XOPs - Currently only NCNR and ANSTO are writing XOPs, and since they are for very different purposes, I think we can stay out of each others' way. We currently add an "X" suffix to our XOP names.
For "Want" #2:
- this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.
For "Like" #1:
- If we can get Want #1 to work, we can include/remove each others "Packages" on demand. Following WM's "Packages" idea seems to be pretty good. For example, Jan's analysis package could be loaded (from a menu item) that #includes what is needed. Then his "Package" for size distributions could be loaded. It would play in a folder "root:Packages:XXXX" or "root:packages:APS:XXXXX". These folders can be created/killed as the package is loaded/unloaded. Any bits of analysis that can be packaged in this way should be easy to share. For how the data is internally handled, see Like#2.
- We'll soon? have a common 1D XML format, and an XOP of base functions to read them in with.
For "Like" #2:
- ugh. I don't know if this is a productive use of anyone's time. Jan maybe got some of this done in his code, but I don't know how. Everyone is tied into a particular naming scheme that is required to be able to present a nice interface to the users. To find a "common" naming scheme that everyone changes their code to adhere to is in my opinion, more work than its benefit. I propose that each facility's package keeps its internal folder structure (Ken!) so no functionality is broken. Then to play together well, to use NCNR packages, the data must be read in by a NCNR data loader which will enforce NCNR schemes. This would require each package to identify if there was "valid" data loaded, and instruct the user if data needs to be (re)loaded (but not overwritten). Yes, a bit messier of an experience for the user, but it seems like a solution that may actually be possible to implement. Since there's a lot of work potentially involved, this is certainly up for debate.
Items #3 and beyond are to be determined...
