Talk:IGOR Pro Developers Working Group

From canSAS

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...

Irena Data selection tool (JIL, 12/11/07)

This is my attempt to document Irena data selection tools.

Purpose of these tools (what are they suppose to do): Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.

Features: Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary). Know number of "default" data types: USAXS data, QRS data type, Irena results. But also enable programer to define user type (passed as lookup list by programmer). Can generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always). Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type. Created controls can be moved or even hidden by programmer as appropriate.

Files necessary: IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.


Use (code snippet): 

  Window TestPanel2() : Panel
  PauseUpdate; Silent 1		// building window...
  NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"
  //this example sets User data type to QRS system and enables use of Q and intensity only
  string UserDataTypes="r_*;"   //user data type (Intensity) is recognized as starting with "r_"
  string UserNameString="Test me"   //this is name for the user data type checkbox...
  string XUserLookup="r_*:q_*;"    //this is matching pattern for q vector name
  string EUserLookup="r_*:s_*;"    //this for error
  variable RequireErrorWaves =0    //do not require error
  variable AllowModelData = 0      //disable generating of model data
  //and this creates the controls. More description is in the package about other parameters....
  IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;","AllCurrentlyAllowedTypes;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)
  end

This creates panel with 4 checkboxes to select data types and 4 popups with Folder name, X-wave name, Y wave name, and error wave name. Only folders where at least one appropriate data set exists are presented. There are some smarts to select appropriate Y and error waves if user selects the X wave (if possible)... Anyway, resulting strings arfe found int his case in root:Packages:testpackage2 and you can use the folder name and wave names to copy or do with data what you wish.

Retrieved from "https://wiki.cansas.org/index.php?title=Talk:IGOR_Pro_Developers_Working_Group&oldid=95"