RE: [Plplot-devel] Sequence numbers (was Remove the deprecated sections in drivers.h and plcore.h?)

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > Thanks, Geoffrey, for your quick reply.  I will resolve this by documenting
 > well enough so I feel comfortable removing those code blocks.
 > 
 > I have been attempting to document what is going on with the drivers, and in
 > fact I have found a mess with the sequence numbers.  The driver code values
 > are discordant with configure.in. For example, configure.in says the null
 > device is 42 while null.c says it is 41, and vice versa for pstex.  I have
 > found a fair number of other cases as well.  Obviously things are working
 > okay right now, but there may be some subtle errors from this discordance
 > between configure.in numbers and the drivers/*.c numbers.  Therefore, I have
 > decided to make configure.in the definitive source of these numbers and
 > change the drivers/*.c values appropriately.  Hope this is the right thing
 > to do since I don't have deep understanding of how the sequence numbers are
 > actually used.

The only thing sequence numbers do, is determine the order of
presentation of devices in the device list.  The only reason to have
them, is so this display is consistent over time.  My first work on
dyndrv didn't preserve them, and I wound up with something other than
xwin at the top of the list, which immediately motivated me to put the
sequence numbers back in.  However, I doubt anything would go
particularly "wrong" if they were messed up.  It's just a
stability-of-public-image thing.  And somewhat a utility thing, since
we use them to try to get the interactive devices high on the list,
and the non-interactive devices (file oriented devices) low on the
list.

The "right" fix, would involve somehow the creation of a new file, a
device registry, which would contain the sequence number for each
device, and then configure.in would use that file, rather than having
the numbers hard coded into its gross autoconf jumble monstrosity.

But I cannot commit to build such a fastidious system on any
particuolar timescale.  

-- 
Geoffrey Furnish         fu...@ga...