Survex news

[Olly Betts]

[Copied to the Survex list as this is of geenral interest]

In message <9718D3B1ED18D31180F000A0C99DE2235A3978@ihmdex03.ih.navy.mil>, Thrun
 Robert IHMD writes:
>I looked at the Survex web site to see what was new
>and downloaded some of the newer source versions.
>The file that was supposed to be the Survex 0.94
>source seems to be an unbelievably long install/
>configure script.

I've just checked and all the source archives are fine.  However they are
tar files which is I suspect is causing your problem if you are trying
to unpack under DOS or MS Windows.  I believe winzip can unpack them -
otherwise you'll need to find a DOS or MS Windows version of gzip and tar.
For DOS versions try http://www.delorie.com/djgpp/ .

>My one request before you freeze
>Survex is that you add a data export facility.

Unfortunately the current parser is rather too tightly entwined with the
data processing code.  Taco van Ieperen wrote a CDI converter for Survex.
I've not looked at it, but it's probably the way to go:

http://members.home.net/tacovan/

If you try it, let me know how well it works.  It's likely it's a better HTO
import/export route than hto2svx and svx2hto.

>I would be very curious to hear the details of the
>plug-in mechanism.  I am not familiar with plug-ins.
>It seems to me that they would be restricted in where
>they can be inserted and what they can do.

Mark's technique allows a C++ class to be placed into a shared library/DLL
and loaded on demand without the code using it being aware of this.  So
effectively a plug-in can go anywhere that a class can, and the various
plug-in interfaces are just class interfaces.  And if a platform lacks
shared library support, we can just compile all the classes in statically.

So to define a particular plug-in interface we declare a base class which
the plug-in classes inherit from.  For plug-ins that are known at compile
time, we can then just create the object in the plug-in as we would any
other object - either with new, or as an automatic variable.

For plug-ins which aren't known at compile time, some sort of factory class
or function will be needed to return new instances of the object given a
description (probably as a string).  New instances are returned as pointers
to the base class type.

To illustrate, suppose we have an InformationWindow class, for things such
as compasses, rose diagrams, etc.  Then in the spud sources we have:

class InformationWindow {
    // definition of interface
};

Then suppose some third party wants to implement a window showing dip
angles.  She or he creates a subclass:

class DipInformationWindow : public InformationWindow {
    // etc
};

And puts that in a shared library.  And a second tiny shared library
contains the factory function, with a standard name:

InformationWindow *
make_information_window(const string & name)
{
    if (name == "dip") return new DipInformationWindow();
    return NULL;
}

Note that we know the DipInformationWindow class name at compile time for
the factory shared library.  And the factory shared library can be given a
filename with a known format and contains a function with a known name to
call.

There are other ways the factory could work, which may be better (for
example if there are going to be lots of plug-ins of one sort then the
linear look-up this forces is bad).  But this at least illustrates that it
can be done.

Cheers,
Olly