On my way to playing around with something else, I started looking at the
results of the attributes 'Version and 'Body_Version with Gnat 3.13p on
WinNT. They appear to be intended for distributed systems, but could
potentially be useful within any system that uses someone's library of
stuff - a means of verifying that any assumed behavior from a given version
is still valid. Or, for example, a means of recording the version of a
package that produced some particular output so that on input, version
differences can be accommodated.

Looking at the strings from a particular package (a generic instantiatiation
at that) I see a pair of strings that look like: "2daafe2a" (spec)
"21adf138" (body) I didn't encounter anything in the ARM indicating what the
format of the string should be nor did I see anything in the GNAT documents
that explained how to interpret the string. Obviously, this is going to be
system dependent, but if you want to do anything more than say "This version
isn't the one I remember" you need to know how to interpret the string. Has
anybody used this before and possibly have some insight? Thanks.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution

Web:       http://www.*-*-*.com/

"Marin David Condic"

 want to do anything more than say "This version

What in the RM gives you the slightest idea that you
can expect to do anything more than compare two version
numbers?

On a hopefully slightly more helpful note :-

I think it is used in the Glade distrib. annex (Godinspired Labour, Design
and Engineering)
examples to compare versions, my interest would be in checking a client from
a server to
check the version of the client.

On the subject of the RM though has anyone read this ...
The glade user guide, RM and a certain book written by John Barnes
is far less likely to send you asleep.

I don't recall ever saying that the RM gave me the idea that I could do
anything but compare the two version numbers for equality. I think what I
said was that having discovered these strings, I might conceivably find some
use for them in identifying software versions in a manner that would be
dependent on the particular implementation - assuming one knew how those
numbers got built.

For example: Suppose you wrote a class that wants to store/load its data
to/from a file. Suppose that part of what it wrote to that file was the
version string. On reading the version string back in, it is possible for
the class to detect if it is consistent with the content of the file.
However, it might be more useful if it can detect some sequence to those
version strings so that it might be able to say "This file was created two
versions ago" or "This file was created by one version later than I am..."
and make intelligent decisions about what content to read in. I could
imagine how an implementation might have information coded in the strings
that might make it possible to determine lots of things about compatibility.
I could also imagine how some implementation defined pragmas might just be
able to add additional information to the string that might let the user
provide some compatibility information. So knowing how the strings change
and what can be detected from their content might just be useful
information - implementation dependent, but useful.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution

Web:      http://www.mcondic.com/

Well, its useful enough for an application to be able to say: "I know I am
dependent on version 'LMNOP' and if the version is anything but 'LMNOP' then
I'd better take evasive action because something may not work." But if there
is some ability to determine order for the version strings, you get even
more usefulness out of it. You can then write code that can say things like
"I know that version '12345' and greater support feature X so it is O.K. for
me to use feature X." or "Versions prior to '54321' only support data items
A, B, and C, while versions between '54321' and '54323' support D, ane E,
and so now I know what I can read in and display..."

Like I said, it won't be "standard" but it still might be useful.

It might not hurt for Ada0x to insist that Something'Version and
Something'Body_Version yield a string that is increasing in sort order with
each change. That at least would let you do "<" and ">" comparisons and know
you are still portable.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution

Web:      http://www.mcondic.com/

But you do know the order order of earlier versions and can store that list
in each new version othe code.  You also know that any version that was
not a past version (not in the stored list) must be a new version and can
then
deside what to do in that case (this case will only come up when a past
version of the code is attempting to work with a newer version )

Vincent Marciante

(please remove underbar remove from my email address to reply directly)

O.K. You can get there from here. Sort of. If you dutifully record every
version string of a released component you at least know the valid history
and you can check against it. But I still think this is not as useful.

Example:

package Somepackage is    --  Version 1.0 (my number)
    A, B, C : Integer ;
end Somepackage ;

package Somepackage is    --  Version 2.0 (my number)
    A, B, C : Integer ;
    D, E, F : Integer ;
end Somepackage ;

So assuming I know something about when features are introduced and that my
project (attempts to) maintain upward compatibility and all that, what, if
anything, might I know about Version 1.5? If I know that D, E and F were
introduced in 2.0 and my calling module detects 2.0 *or greater* then it is
O.K. to use D, E and F. If it sees a module that is *less than* 2.0, it
knows not to use D, E and F. If, for some reason, a 1.5 version were to
exist out there, I'd know by the order that it wasn't compatible.

Granted, this is a contrived example and the compiler would catch any
invalid use of D E and F (thank you, Ada.) But one can easily imagine cases
that are more complex in which an ordered version string would help.

It isn't a perfect thing and it isn't a substitute for good configuration
management and knowing what is going on with one's software, but I could
imagine situations where this might be helpful if it were ordered. You can
always Roll Your Own and this may, in some circumstances, be a better idea.
(What causes the 'Version or 'Body_Version to be incremented? Every time you
edit the file? Every time you compile it? Every time there is some semantic
difference? What if you revert to a prior version of the file? What if you
need to be compiler-independent? Etc?) The weaknesses of 'Version &
'Body_Version may make it impractical for some uses - but making it Ordinal
would probably have been a good thing. (Any reason *not* to make it
Ordinal?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution

Web:      http://www.mcondic.com/

At first glance this sounds like VMS shareable image matching
controls that are done manually, where numeric comparisons are
possible.  But the Ada feature seems to require something like
VMS shareable image matching controls that are done automatically,
and necessarily allows only equality comparisons.  I will not be
available to code the fully automatic relationship-comparing
version until I finish the required preliminary work on the
DWIM subprogram :-).

=======

Consider:

Something'*Version is required by the standard to change anytime
there is a change in a compilation unit referred to by Something.

So presume one changes both SubOne and SubTwo and then recompiles
Something.  Say the compiler takes the next logical sort ordered
value.

Then what happens if one rolls back SubTwo to what it used to be,
but retains the changed version of SubOne ?  The result we have is
_logically_ between the original and the first modification, but that might
be hard to achieve in the sort order.  Or what if we make _another_
version that has the original version of SubOne but retains the
change to SubTwo ?  How does the value of _that_ string relate
to the value of the one whose context is vice versa ?

If you want to know which version is "older" or "newer", I can't think
of any good way to define the concepts (other than perhaps the source
file timestamp, but that can be changed by copying the file).  Knowing
whether a version is older or newer than the one you expected might be
useful if you can assume upward compatibility, but that can't be
enforced by the language; compatibility can be upward, downward, both,
or neither, and may apply only to some features of a package.

If you're looking for a configuration management system, I suggest
using a configuration management system.  If you want a version
indication in your package that gives you more information than
equality/inequality, it should be easy enough to add one yourself.
(For example, if you use RCS or CVS, you can have a version string
that's automatically updated whenever the source file is checked in.)

The version strings used by GNAT look like they might be 32-bit
checksums of the source, in hexadecimal, but that's just a guess.

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

Well, as I said elsewhere, there's no substitute for formal CM and
understanding your own software. I understand the case you are describing
and I don't think I'd expect the compiler to be able to figure out that I
reverted to some prior version of a subprogram. That's a bit much to expect
from a poor, dumb compiler!

If you need that kind of version control, it seems to me you're going to
have to apply some human intelligence and Roll Your Own version numbering
scheme. I don't see the '*Version as something to take advantage of in rapid
iterations of the EditCompileLinkRun Development Methodology - but as
something you might use in conjunction with formal CM in environments where
you have possible multiple versions of a subsystem or you are using it to
control the artifacts of what a subsystem creates. (Recording version
numbers in the output from a subsystem.)

But is it a) impossible and/or b) undesirable to have the Something'*Version
increment with every compile? It might be nice to know that a unit you are
calling is a later compile or earlier compile than the one you know about
rather than the only information you have is that it is *not* the one you
know about. You still need to be able to answer the question "What can I do
about it?". You can't do much unless you know something about what changes
happened between versions. When you *do* know what the differences are, you
*might* be able to make some use of the ordering of the versions. Just an
idea that might be useful....

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution

Web:      http://www.mcondic.com/

Exactly! All you can do is to do an equality comparison to
check for identical versions.

I think you are quite confused about the semantics of
version, this string identifies a unit and all the units
on which it depends. It is nothing like a numerical version
number of the source for a particular unit. I would suggest
you review the RM, you have got a completely wrong idea
here. Perhaps if 'Version had been called 'Octupus you
would not have read this irrelevant semantics into the
attribute :-)

Hi!

In another development tool I worked on, we made a array of strings
containing all files and their versions that were
built into the executable. This array could be dumped into a file by a
pushbutton in the "about" box.
The array were populated by code in each source code file, this code was a
part of the coding standard, and after it was
initially there PVCS(configuration tool) was the only "one" worrying about
it.
I belive something similar can be done in Ada also. If you create a package
that has logic administrating the array, and a function
to set the array element this function could be called by all other
packages' main block. One constraint I see is that purity pragmas can
break this approach.

Frank

Actually, I think Marin has been quite up front in acknowledging how
the RM defines 'Version. He is simply wishing it was defined
differently.

Think of this as a feature request, for a new attribute, that does
what Marin wants it to.

Marin; if you want Robert and other language lawyers to hear a
feature request, you need to state it as a new attribute; they simply
will not consider redefining an existing one! :)

--
-- Stephe

I think what Marin wants is not possible.

Otherwise I would want it also.