The feature set of the new 3.1 version of PaleoMag has now reached the point where I suggest that most users should check it out. There are some important caveats: the statistics (especially the line+plane types) need some better checking before being totally trusted (and the Bingham statistic is still poor for girdle distributions like poles to planes--this is an old problem). Main features now present:
Of course some important features are still absent, but for many users this should include the core functionality. Additionally, the code runs on MacOS X, PowerPC MacOS, and Windows machines, and has a large number of enhancements to the interface relative to 2.3 (multiple samples, least-squares files can be open at once; live update of statistics and fits as points are selected/deselected, more direct feedback when zooming, selecting points, drag-and-drop, read Wyoming .APP, 2G's .DAT, and other formats directly, etc.). 68k Mac code could be provided if requested. Please give it a spin and send some email.
The 3.1 code is now approaching beta test stage (meaning I will stop adding new things and focus on fixing bugs). This should be short as the extended duration of this development has included a lot of debugging.
3.0 ran afoul of my joining the teaching faculty here at CU and VIP's discarding of their development environment (having been burned by that before, I didn't continue development despite the fact that the compiler still works, I think). RealBasic is now a widely adopted rapid development tool; its underpinnings are quite different from the other environments I have used, so porting the code is, once again, non-trivial. The really good thing is that RealBasic allows very rapid inclusion of things that were deadly difficult before (the coding for the List Window was far worse then any of you might have believed possible).
The bad news was that FutureBasic has a ratty debugger, has lousy support for floating point math, and is the first development environment I've encoutered that can corrupt the Mac System files--not pleasant stuff. So I gave up on FutureBasic and instead tried learning C++. (Caveat: Staz software has done a lot of work on FutureBasic and it now could be much better).
Only problem there was the immense time it takes to rewrite a proceedural code from the ground up--time I don't have. Then there was another BASIC environment, VIP Basic, which can read in QuickBasic codes. It had a very nice interface (compared with FutureBasic) but did not directly compile code--it either did runtime interpretation or exports C for compilation in, say, CodeWarrior. This was not all bad. What was bad was that it was dropped.
Now we are up to RealBasic which, unlike its predecessors, has been widely adopted and is now makes applications for Mac OS 9 and previous, Mac OS X, and Windows (apparently from 95 to XP). We'll see if I can port the old code before this thing goes under ;-) It cannot import QuickBasic code, unfortunately, so I have to paste code in and see what oddities have to be cleaned out, but as the environment is totally unlike QuickBasic, import wasn't going very far anyway.
The solution?: Coding is ongoing. I had intended to merely port the old wonder-code first and then rip it apart, but it quickly became apparent that that was too inefficient. So I am making a number of structural improvements to the code, most notably a modern memory management approach that will allow multiple samples and sites to be open, and for memory to be allocated in the most efficient manner possible.
C. H. Jones | CIRES | Dept. of Geological Sciences | Univ. of Colorado at Boulder
Last modified on Wednesday, September 3, 2003 11:25 AM