* Attributes 'Version and 'Body_Version @ 2001-11-06 20:58 Marin David Condic 2001-11-07 3:39 ` Robert Dewar 2001-11-07 22:04 ` Keith Thompson 0 siblings, 2 replies; 42+ messages in thread From: Marin David Condic @ 2001-11-06 20:58 UTC (permalink / raw) 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 e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-06 20:58 Attributes 'Version and 'Body_Version Marin David Condic @ 2001-11-07 3:39 ` Robert Dewar 2001-11-07 15:08 ` Marin David Condic 2001-11-07 20:51 ` Tony Gair 2001-11-07 22:04 ` Keith Thompson 1 sibling, 2 replies; 42+ messages in thread From: Robert Dewar @ 2001-11-07 3:39 UTC (permalink / raw) "Marin David Condic" want to do anything more than say "This version > isn't the one I remember" you need to know how to interpret the string. What in the RM gives you the slightest idea that you can expect to do anything more than compare two version numbers? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 3:39 ` Robert Dewar @ 2001-11-07 15:08 ` Marin David Condic 2001-11-07 20:51 ` Tony Gair 1 sibling, 0 replies; 42+ messages in thread From: Marin David Condic @ 2001-11-07 15:08 UTC (permalink / raw) 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 e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0111061939.595b61be@posting.google.com... > > What in the RM gives you the slightest idea that you > can expect to do anything more than compare two version > numbers? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 3:39 ` Robert Dewar 2001-11-07 15:08 ` Marin David Condic @ 2001-11-07 20:51 ` Tony Gair 2001-11-07 16:45 ` Marin David Condic 2001-11-07 23:08 ` Robert Dewar 1 sibling, 2 replies; 42+ messages in thread From: Tony Gair @ 2001-11-07 20:51 UTC (permalink / raw) 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. "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0111061939.595b61be@posting.google.com... > "Marin David Condic" > > > want to do anything more than say "This version > > isn't the one I remember" you need to know how to interpret the string. > > What in the RM gives you the slightest idea that you > can expect to do anything more than compare two version > numbers? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 20:51 ` Tony Gair @ 2001-11-07 16:45 ` Marin David Condic 2001-11-07 18:32 ` Vincent Marciante 2001-11-07 19:54 ` Larry Kilgallen 2001-11-07 23:08 ` Robert Dewar 1 sibling, 2 replies; 42+ messages in thread From: Marin David Condic @ 2001-11-07 16:45 UTC (permalink / raw) 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 e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Tony Gair" <tonygair@donot.spam.btinternet.com> wrote in message news:9sbb1f$2bm$1@plutonium.btinternet.com... > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 16:45 ` Marin David Condic @ 2001-11-07 18:32 ` Vincent Marciante 2001-11-07 19:00 ` Marin David Condic 2001-11-07 19:54 ` Larry Kilgallen 1 sibling, 1 reply; 42+ messages in thread From: Vincent Marciante @ 2001-11-07 18:32 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:9sboee$42f$1@nh.pace.co.uk... > 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. 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) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 18:32 ` Vincent Marciante @ 2001-11-07 19:00 ` Marin David Condic 2001-11-07 23:11 ` Robert Dewar 0 siblings, 1 reply; 42+ messages in thread From: Marin David Condic @ 2001-11-07 19:00 UTC (permalink / raw) 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 e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Vincent Marciante" <marciant_remove@li.net> wrote in message news:W4fG7.11237$ym4.493547@iad-read.news.verio.net... > > 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 ) > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 19:00 ` Marin David Condic @ 2001-11-07 23:11 ` Robert Dewar 2001-11-08 17:28 ` Stephen Leake 2001-11-08 18:55 ` Marin David Condic 0 siblings, 2 replies; 42+ messages in thread From: Robert Dewar @ 2001-11-07 23:11 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9sc0cf$76a$1@nh.pace.co.uk>... > But I still think this is not as useful. 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 :-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 23:11 ` Robert Dewar @ 2001-11-08 17:28 ` Stephen Leake 2001-11-08 17:43 ` Larry Kilgallen 2001-11-08 18:55 ` Marin David Condic 1 sibling, 1 reply; 42+ messages in thread From: Stephen Leake @ 2001-11-08 17:28 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9sc0cf$76a$1@nh.pace.co.uk>... > > But I still think this is not as useful. > > 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 :-) 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-08 17:28 ` Stephen Leake @ 2001-11-08 17:43 ` Larry Kilgallen 2001-11-08 19:03 ` Marin David Condic 0 siblings, 1 reply; 42+ messages in thread From: Larry Kilgallen @ 2001-11-08 17:43 UTC (permalink / raw) In article <ubsidqiif.fsf@gsfc.nasa.gov>, Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes: > 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. I think what Marin wants is not possible. Otherwise I would want it also. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-08 17:43 ` Larry Kilgallen @ 2001-11-08 19:03 ` Marin David Condic 2001-11-08 19:37 ` Larry Kilgallen ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Marin David Condic @ 2001-11-08 19:03 UTC (permalink / raw) This may not be news: I often want what is, in fact, impossible. :-) But so far, I don't think what I want has been shown to *be* impossible. If the compiler is somehow or other capable of determining that the string for '*Version needs to be *different* then how is it impossible to be sure that the next string chosen satisfies the semantics: New_String > Old_String ??? If the relationship only has the meaning: "This version was compiled at a later time than the previous version" and you make no other use of it beyond that, then I don't think doing so is impossible or undesirable. It enables you to use the version string in manners perhaps not originally contemplated by its original designers. That's not necessarily A Bad Thing. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:hrQGkj0SsFUJ@eisner.encompasserve.org... > > I think what Marin wants is not possible. > > Otherwise I would want it also. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-08 19:03 ` Marin David Condic @ 2001-11-08 19:37 ` Larry Kilgallen 2001-11-09 3:50 ` Robert Dewar 2001-11-09 3:55 ` Robert Dewar 2 siblings, 0 replies; 42+ messages in thread From: Larry Kilgallen @ 2001-11-08 19:37 UTC (permalink / raw) In article <9seku6$hes$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > This may not be news: I often want what is, in fact, impossible. :-) > > But so far, I don't think what I want has been shown to *be* impossible. If > the compiler is somehow or other capable of determining that the string for > '*Version needs to be *different* then how is it impossible to be sure that > the next string chosen satisfies the semantics: New_String > Old_String ??? > > If the relationship only has the meaning: "This version was compiled at a > later time than the previous version" and you make no other use of it beyond > that, then I don't think doing so is impossible or undesirable. Yes, that much would be possible. I just don't think it would be much use, for instance in the case where I back out the change to a compilation unit upon which the subject compilation unit depends. A more recent compilation could mean an _earlier_ version of the code. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-08 19:03 ` Marin David Condic 2001-11-08 19:37 ` Larry Kilgallen @ 2001-11-09 3:50 ` Robert Dewar 2001-11-09 3:55 ` Robert Dewar 2 siblings, 0 replies; 42+ messages in thread From: Robert Dewar @ 2001-11-09 3:50 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9seku6$hes$1@nh.pace.co.uk>... > But so far, I don't think what I want has been shown to *be* impossible. If > the compiler is somehow or other capable of determining that the string for > '*Version needs to be *different* then how is it impossible to be sure that > the next string chosen satisfies the semantics: New_String > Old_String ??? Well, so much for the theory that Marin understands 'Version but wants different behavior :-) Marin, you persist in thinking that unit'Version is about the version of the unit in question. Perhaps we should have called the attribute something else, since the name sure is confusing you. Version here does NOT mean the source version of the unit in question, it means the *object* version of the unit, which includes contributions from all the units on which the unit depends. So the notion of newer or older is simply and fundamentally inapplicable, given that this version represents the state of a *set* of files. I trust this makes things clear, if not I give up :-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-08 19:03 ` Marin David Condic 2001-11-08 19:37 ` Larry Kilgallen 2001-11-09 3:50 ` Robert Dewar @ 2001-11-09 3:55 ` Robert Dewar 2 siblings, 0 replies; 42+ messages in thread From: Robert Dewar @ 2001-11-09 3:55 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9seku6$hes$1@nh.pace.co.uk>... > This may not be news: I often want what is, in fact, impossible. :-) It is perfectly reasonable to propose a new attribute say 'Source_Version that returns a string with the kind of attributes you suggest (e.g. it could return a version number from the CM, or the time stamp, or some such). But this has nothing whatsoever to do with the 'Version attribute, and you merely confuse the discussion by thinking otherwise. Try reading the definition in the RM *forgetting* that the name of the attribute is "version" :-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 23:11 ` Robert Dewar 2001-11-08 17:28 ` Stephen Leake @ 2001-11-08 18:55 ` Marin David Condic 1 sibling, 0 replies; 42+ messages in thread From: Marin David Condic @ 2001-11-08 18:55 UTC (permalink / raw) I'm sorry. I don't recall that I was trying to discuss what it *is*. I thought I was trying to discuss what it *might be*. I was under the impression that I was sort of off in the Blue Sky world of saying "Gee... This feature would be more useful if it was more like this...." rather than saying "My understanding of the feature is that it *is* this...." But I could be wrong about what it was I was talking about and I'm willing to stand corrected if someone out there knows more about what I was talking about than I do. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0111071511.6fe3f067@posting.google.com... > > 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 :-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 16:45 ` Marin David Condic 2001-11-07 18:32 ` Vincent Marciante @ 2001-11-07 19:54 ` Larry Kilgallen 2001-11-07 21:49 ` Marin David Condic 1 sibling, 1 reply; 42+ messages in thread From: Larry Kilgallen @ 2001-11-07 19:54 UTC (permalink / raw) In article <9sboee$42f$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > 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. 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 ? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 19:54 ` Larry Kilgallen @ 2001-11-07 21:49 ` Marin David Condic 0 siblings, 0 replies; 42+ messages in thread From: Marin David Condic @ 2001-11-07 21:49 UTC (permalink / raw) 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 e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:bgYJjEmY5R3$@eisner.encompasserve.org... > > 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 ? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 20:51 ` Tony Gair 2001-11-07 16:45 ` Marin David Condic @ 2001-11-07 23:08 ` Robert Dewar 1 sibling, 0 replies; 42+ messages in thread From: Robert Dewar @ 2001-11-07 23:08 UTC (permalink / raw) "Tony Gair" <tonygair@donot.spam.btinternet.com> wrote in message news:<9sbb1f$2bm$1@plutonium.btinternet.com>... > On a hopefully slightly more helpful note :- > > I think it is used in the Glade distrib. annex > examples > to compare versions, Exactly! All you can do is to do an equality comparison to check for identical versions. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-06 20:58 Attributes 'Version and 'Body_Version Marin David Condic 2001-11-07 3:39 ` Robert Dewar @ 2001-11-07 22:04 ` Keith Thompson 2001-11-08 16:34 ` Frank 2001-11-09 3:53 ` Robert Dewar 1 sibling, 2 replies; 42+ messages in thread From: Keith Thompson @ 2001-11-07 22:04 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > 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. 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. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Cxiuj via bazo apartenas ni. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 22:04 ` Keith Thompson @ 2001-11-08 16:34 ` Frank 2001-11-09 3:53 ` Robert Dewar 1 sibling, 0 replies; 42+ messages in thread From: Frank @ 2001-11-08 16:34 UTC (permalink / raw) 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 > 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.) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-07 22:04 ` Keith Thompson 2001-11-08 16:34 ` Frank @ 2001-11-09 3:53 ` Robert Dewar 2001-11-10 0:07 ` Keith Thompson 1 sibling, 1 reply; 42+ messages in thread From: Robert Dewar @ 2001-11-09 3:53 UTC (permalink / raw) Keith Thompson <kst@cts.com> wrote in message news:<yecbsiekzkl.fsf@king.cts.com>... > The version strings used by GNAT look like they might be > 32-bit checksums of the source ^ sources!!!!! It's really important to realize that 'Version is nothing like the version number of the source file, it is the version of the OBJECT, not the source, and hence depends on a whole set of sources. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-09 3:53 ` Robert Dewar @ 2001-11-10 0:07 ` Keith Thompson 2001-11-10 2:16 ` Larry Kilgallen 2001-11-12 21:51 ` Robert Dewar 0 siblings, 2 replies; 42+ messages in thread From: Keith Thompson @ 2001-11-10 0:07 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > Keith Thompson <kst@cts.com> wrote in message > news:<yecbsiekzkl.fsf@king.cts.com>... > > The version strings used by GNAT look like they might be > > 32-bit checksums of the source > ^ > sources!!!!! > > It's really important to realize that 'Version is nothing > like the version number of the source file, it is the > version of the OBJECT, not the source, and hence depends > on a whole set of sources. Here's the RM definition of the 'Version attribute, from E.3(3): P'Version Yields a value of the predefined type String that identifies the version of the compilation unit that contains the declaration of the program unit. And here's what 10.1(2) has to say about compilation units: The text of a program can be submitted to the compiler in one or more compilations. Each compilation is a succession of compilation_units. A compilation_unit contains either the declaration, the body, or a renaming of a program unit. The representation for a compilation is implementation-defined. It certainly looks to me as if 'Version applies to a compilation unit, and a compilation unit is a part of the text of a program. The version of a compilation unit changes whenever the compilation unit changes in a "semantically significant" way; the phrase "semantically significant" is explicitly left undefined. If unit A depends on unit B, a change in B can affect the object generated for A even if the source of A is unchanged. I don't see a requirement for A'Version or A'Body_Version to change when this happens, though I can see that such a requirement would be useful. It's likely that I'm missing something obvious, but I don't know what it is. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Cxiuj via bazo apartenas ni. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-10 0:07 ` Keith Thompson @ 2001-11-10 2:16 ` Larry Kilgallen 2001-11-11 15:18 ` Marin David Condic 2001-11-12 21:51 ` Robert Dewar 1 sibling, 1 reply; 42+ messages in thread From: Larry Kilgallen @ 2001-11-10 2:16 UTC (permalink / raw) In article <yec3d3nij4r.fsf@king.cts.com>, Keith Thompson <kst@cts.com> writes: > If unit A depends on unit B, a change in B can affect the object > generated for A even if the source of A is unchanged. I don't see a > requirement for A'Version or A'Body_Version to change when this > happens, though I can see that such a requirement would be useful. E.3 (5) says: The version of a compilation unit changes whenever the version changes for any compilation unit on which it depends semantically. The version also changes whenever the compilation unit itself changes in a semantically significant way. It is implementation defined whether there are other events (such as recompilation) that result in the version of a compilation unit changing. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-10 2:16 ` Larry Kilgallen @ 2001-11-11 15:18 ` Marin David Condic 2001-11-12 23:06 ` Tony Gair 0 siblings, 1 reply; 42+ messages in thread From: Marin David Condic @ 2001-11-11 15:18 UTC (permalink / raw) The important thing about it is that at runtime, a subsystem can detect if there has been a change in something (either within itself or within something it is using) from some known point. That doesn't have to be because the source file was edited and it would be hard to imagine how the object file could know anything abut that without some kind of recompilation going on. So its clear to me that the meaning is "This module has been recompiled/relinked at a different time than the one you know about..." or "This is the identical compiled/linked image you know about..." The file may be edited a hundred times, but if it never got waved past the compiler/linker how is the object file going to know that? I just thought that the feature would be more useful if the strings were ordered such that you could detect at runtime "This is a *later*/*earlier* issue than the one I know about" rather than just detecting that it is different. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:L9pmQ$PSskWd@eisner.encompasserve.org... > > E.3 (5) says: > > The version of a compilation unit changes whenever the version > changes for any compilation unit on which it depends semantically. > The version also changes whenever the compilation unit itself > changes in a semantically significant way. It is implementation > defined whether there are other events (such as recompilation) > that result in the version of a compilation unit changing. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-11 15:18 ` Marin David Condic @ 2001-11-12 23:06 ` Tony Gair 0 siblings, 0 replies; 42+ messages in thread From: Tony Gair @ 2001-11-12 23:06 UTC (permalink / raw) This would be very useful from a security point of view for downloadable distributed programs from a open source point of view, and I would use it if I could get the hang of the distrib annex (aaaaarrrrgggggghhhh) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:9sm4se$35v$1@nh.pace.co.uk... > The important thing about it is that at runtime, a subsystem can detect if > there has been a change in something (either within itself or within > something it is using) from some known point. That doesn't have to be > because the source file was edited and it would be hard to imagine how the > object file could know anything abut that without some kind of recompilation > going on. So its clear to me that the meaning is "This module has been > recompiled/relinked at a different time than the one you know about..." or > "This is the identical compiled/linked image you know about..." The file may > be edited a hundred times, but if it never got waved past the > compiler/linker how is the object file going to know that? > > I just thought that the feature would be more useful if the strings were > ordered such that you could detect at runtime "This is a *later*/*earlier* > issue than the one I know about" rather than just detecting that it is > different. > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > Web: http://www.mcondic.com/ > > > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message > news:L9pmQ$PSskWd@eisner.encompasserve.org... > > > > E.3 (5) says: > > > > The version of a compilation unit changes whenever the version > > changes for any compilation unit on which it depends semantically. > > The version also changes whenever the compilation unit itself > > changes in a semantically significant way. It is implementation > > defined whether there are other events (such as recompilation) > > that result in the version of a compilation unit changing. > > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-10 0:07 ` Keith Thompson 2001-11-10 2:16 ` Larry Kilgallen @ 2001-11-12 21:51 ` Robert Dewar 2001-11-13 8:07 ` Keith Thompson 1 sibling, 1 reply; 42+ messages in thread From: Robert Dewar @ 2001-11-12 21:51 UTC (permalink / raw) Keith Thompson <kst@cts.com> wrote in message news:<yec3d3nij4r.fsf@king.cts.com>... > I don't see a > requirement for A'Version or A'Body_Version to change > when this happens, Yes, you are missing something obvious, keep reading (all the way to para 5 :-) Once again, the idea of 'Version is that it identifies the *object* executable code of a unit, to see if it is compatible, it has nothing to do with source versions. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-12 21:51 ` Robert Dewar @ 2001-11-13 8:07 ` Keith Thompson 2001-11-25 20:49 ` Nick Roberts 0 siblings, 1 reply; 42+ messages in thread From: Keith Thompson @ 2001-11-13 8:07 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > Keith Thompson <kst@cts.com> wrote in message > news:<yec3d3nij4r.fsf@king.cts.com>... > > I don't see a > > requirement for A'Version or A'Body_Version to change > > when this happens, > > Yes, you are missing something obvious, keep reading (all > the way to para 5 :-) > > Once again, the idea of 'Version is that it identifies > the *object* executable code of a unit, to see if it is > compatible, it has nothing to do with source versions. Aha! In RM95, E.3(5) says: The version of a compilation unit changes whenever the version changes for any compilation unit on which it depends semantically. The version also changes whenever the compilation unit itself changes in a semantically significant way. It is implementation defined whether there are other events (such as recompilation) that result in the version of a compilation unit changing. However, the RM I was using is a version with Technical Corrigendum 1 merged into it. In that version, E.3(5) has been modified and expanded to two paragraphs: The *version* of a compilation unit changes whenever the compilation unit changes in a semantically significant way. This International Standard does not define the exact meaning of "semantically significant". It is unspecified whether there are other events (such as recompilation) that result in the version of a compilation unit changing. If P is not a library unit, and P has no completion, then P'Body_Version returns the Body_Version of the innermost program unit enclosing the declaration of P. If P is a library unit, and P has no completion, then P'Body_Version returns a value that is different from Body_Version of any version of P that has a completion. I still don't see anything that precludes implementing 'Version as, say, a checksum of the source, or perhaps a checksum of a canonically formatted version of the source (so semantically insignificant changes don't affect the version). -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Cxiuj via bazo apartenas ni. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-13 8:07 ` Keith Thompson @ 2001-11-25 20:49 ` Nick Roberts 2001-11-26 2:30 ` Robert Dewar 0 siblings, 1 reply; 42+ messages in thread From: Nick Roberts @ 2001-11-25 20:49 UTC (permalink / raw) I think there's some mileage in the idea that it might be useful for 'Version and 'Body_Version to (be able to) return something more than just a checksum (or the like). I think Tony Gair's comment hints at why. Supposing an Internet web page is offering a download of a partition (program) called Whizzo (which solves all your marital problems by psychology). Different potential users of Whizzo may well have different versions of the partitions (which contain units) that Whizzo depends on. Suppose those units are: Psychospeak; Technobabble; and Generally.Dodgy.Stuff. Each is in a separate partition. To support as many users as possible (before they jump off a bridge), Whizzo has been built in multiple versions supporting the various versions of Psychospeak, Technobabble, and Generally.Dodgy.Stuff, and a table is shown on the web page allowing the user to select the correct version of Whizzo to download. E.g.: Psychospeak Technobabble Generally.Dodgy.Stuff Whizzo 2f10e401 5ea109d0 4ea23310 > 5a1b207a < 7bc195a2 d4216eee 40abba31 > 8a90001b < f9fa51ef 5201ac48 216b6d48 > 21a68c5c < 6d33a902 5201ac48 39b278b7 > d409b12b < etc Which is okay, but it would be nicer if the versions were in a slightly more human-readable form. E.g.: Psychospeak Technobabble Generally.Dodgy.Stuff Whizzo V:2 R:7 (472) V:3 R:11 (1027) V:Pub:1 R:2 (29) > V:1 R:1 (10052) < V:2 R:7 (479) V:3 R:11 (1028) V:Pub:1 R:2 (30) > V:1 R:1 (10051) < V:2 R:7 (480) V:4 R:1 (2475) V:Pub:1 R:2 (32) > V:1 R:1 (10050) < V:2 R:8 (20) V:4 R:1 (2475) V:Pub:1 R:2 (39) > V:1 R:1 (10049) < etc The idea behind the versions shown here is that the build tool (source controller, version manager, whatever) maintains a version and revision number (which the user changes, and can enter prefixes for), and automatically maintains an 'iteration' number (build number), and generates the version string from all of these. But this is just an idea. Recalling back to some of the comments made in this thread, there was the suggestion that a unit could support multiple versions of a service unit, which offered different levels of service. I would suggest that this is best done (in Ada 95) by the technique of the service unit exporting objects of a class (hierarchy) to its clients (via a remote access-to-classwide type and a repository/directory/agency unit or object). This has to be a classic Ada 95 'pattern': the clients are versionistically decoupled* from the servers; servers which add functionality can do it in a totally forwards-compatible way (by deriving from the originally published type, and exporting objects of the derived type); old clients are 'fooled' into getting the old type (and service) they expect; new clients can take advantage of the added functionality; an 'intelligent' client can test the type of the object it gets, and perhaps adapt to the functionality the object provides. -- Best wishes, Nick Roberts *term obtained from the Technobabble unit (C) 2001 Technobabble Inc. All rights reserved. ;-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-25 20:49 ` Nick Roberts @ 2001-11-26 2:30 ` Robert Dewar 2001-11-26 3:31 ` Nick Roberts 0 siblings, 1 reply; 42+ messages in thread From: Robert Dewar @ 2001-11-26 2:30 UTC (permalink / raw) "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9trpj1$4e6v2$1@ID-25716.news.dfncis.de>... > I think there's some mileage in the idea that it might be useful for > 'Version and 'Body_Version to (be able to) return something more than just a > checksum (or the like). <<rest of peculiar ideas deleted :-)>> I am not sure I understand what on earth Nick was talking about here, but for sure it has nothing to do with the existing attributes (*) I think what happens here is that people see the word Version, and it triggers all kinds of entirely irrelevant baggage. The idea is that if two partitions share a package, and communicate in a way that uses this package, they need a way to make sure that they are using the same *compiled* version of the package. How this is guaranteed will depend on the system. For example, in a conventional Ada 83 style library system, it will be good enough to store a precise enough time stamp of the time of compilation, since two packages can only have the same time of compilation in such a system if they are indeed the same (and depend on all the same packages). This is the *very limited* intention of these attributes, they are not in any sense relevant for the purposes of general version control, let alone the more extensive ideas that Nick presents. If any of these extended ideas have merit, I would suggest completely disentangling them from the existing attributes, starting by using entirely different names, otherwise you will perpetuate the confusion. (*) by the way, MD-5 hash codes are indeed used to guarantee getting the right version of things on the internet (have a look at the Farber True Names patent for details of the idea). ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-26 2:30 ` Robert Dewar @ 2001-11-26 3:31 ` Nick Roberts 2001-11-26 15:42 ` Robert Dewar 0 siblings, 1 reply; 42+ messages in thread From: Nick Roberts @ 2001-11-26 3:31 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0111251830.61aaa6be@posting.google.com... > "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9trpj1$4e6v2$1@ID-25716.news.dfncis.de>... > > I think there's some mileage in the idea that it might be useful for > > 'Version and 'Body_Version to (be able to) return something more than just a > > checksum (or the like). > > <<rest of peculiar ideas deleted :-)>> > > I am not sure I understand what on earth Nick was talking > about here, It's tempting to agree :-) > but for sure it has nothing to do with the > existing attributes (*) What am I supposed to say? [pantomime chorus] "Oh, yes it does!" > I think what happens here is that people see the word > Version, and it triggers all kinds of entirely irrelevant > baggage. > > The idea is that if two partitions share a package, > ... I know what the original idea was for the attributes. > This is the *very limited* intention of these attributes, > they are not in any sense relevant for the purposes of > general version control, let alone the more extensive > ideas that Nick presents. But just because they were originally intended for a certain purpose, doesn't mean they cannot be used for another purpose (in addition), does it? > If any of these extended ideas have merit, I would suggest > completely disentangling them from the existing attributes, > starting by using entirely different names, otherwise you > will perpetuate the confusion. Far be it from me to wish to perpetuate any confusion, but often confusion is a problem cured by good documentation, and doesn't necessarily require new attributes. > (*) by the way, MD-5 hash codes are indeed used to guarantee getting > the right version of things on the > internet (have a look at the Farber True Names patent > for details of the idea). I can guess the general idea, and I'm sure it could be very handy sometimes. Sadly, the fact that the process is patented is probably not so handy. In fact, the more important part of my post was the bit at the bottom, about exporting service objects. I presume Robert wasn't commenting on that bit, and I hope nobody loses sight of the importance of that technique. -- Best wishes, Nick Roberts ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-26 3:31 ` Nick Roberts @ 2001-11-26 15:42 ` Robert Dewar 2001-11-26 20:05 ` Nick Roberts 0 siblings, 1 reply; 42+ messages in thread From: Robert Dewar @ 2001-11-26 15:42 UTC (permalink / raw) "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9tsd63$4jjng$1@ID-25716.news.dfncis.de>... > "Robert Dewar" <dewar@gnat.com> wrote in message > news:5ee5b646.0111251830.61aaa6be@posting.google.com... > I know what the original idea was for the attributes. OK, one would not have guessed this from some earlier messages. Certainly others in this thread have been very confused (indeed the entire thread was started by such a confusion). > But just because they were originally intended for a > certain purpose, > doesn't mean they cannot be used for another purpose (in > addition), does it? It should if you are following good language design principles. There is no point in using the same attribute name for two different purposes. Also, extending the meaning of 'Version would be a language extension that would create a non-conforming variant of Ada. That means no one is going to do it without very general consensus, which you simply won't get going in this direction. If you choose a different attribute name, then you are no longer talking about a language extension, and it is much easier to get someone to implement it if they agree it has some merit. > Far be it from me to wish to perpetuate any confusion, > but often confusion is a problem cured by good > documentation, and doesn't necessarily require > new attributes. You can cure someones confusion with documentation if the confusion arises from misunderstanding. If the confusion stems from confused language design, such as in this case suggesting the use of 'Version to mean two rather unrelated things, then documentation won't be enough. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-26 15:42 ` Robert Dewar @ 2001-11-26 20:05 ` Nick Roberts 2001-11-27 3:56 ` Robert Dewar 2001-11-27 17:04 ` Georg Bauhaus 0 siblings, 2 replies; 42+ messages in thread From: Nick Roberts @ 2001-11-26 20:05 UTC (permalink / raw) > > But just because they were originally intended for a > > certain purpose, > > doesn't mean they cannot be used for another purpose (in > > addition), does it? > > It should if you are following good language design > principles. There is no point in using the same attribute > name for two different purposes. Yes there is: simplicity. > Also, extending the meaning of 'Version would be a language > extension that would create a non-conforming variant of > Ada. No it wouldn't. Changing the meaning would, but extending it specifically does not. My suggestion was purely to do with extending the ways in which the attributes (Version and Body_Version) are used; at no point was my suggestion to prevent them from doing what the RM95 requires. > > Far be it from me to wish to perpetuate any confusion, > > but often confusion is a problem cured by good > > documentation, and doesn't necessarily require > > new attributes. > You can cure someones confusion with documentation if the > confusion arises from misunderstanding. If the confusion > stems from confused language design, such as in this case > suggesting the use of 'Version to mean two rather unrelated > things, then documentation won't be enough. I'm sorry, but the confusion in this case is all yours, Robert! -- Best wishes, Nick Roberts ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-26 20:05 ` Nick Roberts @ 2001-11-27 3:56 ` Robert Dewar 2001-11-27 17:51 ` Nick Roberts 2001-11-28 0:44 ` Larry Kilgallen 2001-11-27 17:04 ` Georg Bauhaus 1 sibling, 2 replies; 42+ messages in thread From: Robert Dewar @ 2001-11-27 3:56 UTC (permalink / raw) "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9tu7nj$4v9lc$1@ID-25716.news.dfncis.de>... >> There is no point in using the same attribute >> name for two different purposes. > > Yes there is: simplicity. That's a really peculiar view, confusing two separate concepts by using the same name certainly does not make things simpler, quite the contrary. > > Also, extending the meaning of 'Version would be a > > language > > extension that would create a non-conforming variant of > > Ada. > > No it wouldn't. Nick, you really don't know the RM well enough. You are completely and 100% wrong on this. Please don't make such statements without carefully checking. There is far too much misinformation on this newsgroup. Section 2.8 of the RM is perfectly clear. The only implementation permission is to add implementation dependent pragmas, and the name is required to be different from any other pragma. This is really not a hard rule to find! 14 An implementation may provide implementation-defined pragmas; the name of an implementation-defined pragma shall differ from those of the language-defined pragmas. Changing the meaning of an existing pragma, by extension or otherwise is DEFINITELY a non-conforming language change. That's perfectly clear from the RM. > I'm sorry, but the confusion in this case is all yours, > Robert! Really Nick, you must spend more time reading the RM *carefully* and avoid spreading misinformation! ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-27 3:56 ` Robert Dewar @ 2001-11-27 17:51 ` Nick Roberts 2001-11-28 0:44 ` Larry Kilgallen 1 sibling, 0 replies; 42+ messages in thread From: Nick Roberts @ 2001-11-27 17:51 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0111261956.3df9b8e3@posting.google.com... > Changing the meaning of an existing pragma, by extension > or otherwise is DEFINITELY a non-conforming language > change. That's perfectly clear from the RM. Robert, your reply is about pragmas. All of my posts in this thread have been about attributes, and none has mentioned any pragma. You don't even seem to have read my posts, to which you are replying. If your replies are simply for a 'vexatious' purpose, I'll simply have to k-line you, and perhaps others may also choose to do so. If not, could I ask you, please, to re-read my posts, and then make a proper reply. -- Nick ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-27 3:56 ` Robert Dewar 2001-11-27 17:51 ` Nick Roberts @ 2001-11-28 0:44 ` Larry Kilgallen 2001-11-28 15:49 ` Robert Dewar ` (2 more replies) 1 sibling, 3 replies; 42+ messages in thread From: Larry Kilgallen @ 2001-11-28 0:44 UTC (permalink / raw) In article <5ee5b646.0111261956.3df9b8e3@posting.google.com>, dewar@gnat.com (Robert Dewar) writes: > Section 2.8 of the RM is perfectly clear. The only > implementation permission is to add implementation > dependent pragmas, and the name is required to be > different from any other pragma. This is really not > a hard rule to find! But when followed it does not do a whole lot to prevent current implementation-defined pragmas from conflicting with the names of future language-define pragmas. Was the thought that the set of Ada compiler vendors will always be so small that such issues can be worked out informally ? > 14 An implementation may provide implementation-defined pragmas; the > name of an implementation-defined pragma shall differ from those of > the language-defined pragmas. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-28 0:44 ` Larry Kilgallen @ 2001-11-28 15:49 ` Robert Dewar 2001-11-28 16:53 ` Larry Kilgallen [not found] ` <5ee5b646.0111280749.77fabe6c@posting.google.coOrganization: LJK Software <PFcoNrf74AeG@eisner.encompasserve.org> 2 siblings, 0 replies; 42+ messages in thread From: Robert Dewar @ 2001-11-28 15:49 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<YsaTZ19cOfHh@eisner.encompasserve.org>... > But when followed it does not do a whole lot to prevent > current implementation-defined pragmas from conflicting > with the names of future language-define pragmas. Sure, there is always a problem in using any vendor defined attributes or pragmas that might be redefined by the standard later. But in practice this has been a negligible problem in the past, and I see no reason to think the future will be different. > Was the thought that the set of Ada compiler vendors > will always be so small that such issues can be worked > out informally ? Not particularly, though this is in practice true. The real point is that if you use implementation defined attributes and pragmas, you are making your code incompatible with other compilers, and that might include compilers for some new version of Ada, but in any case that means no more than that going to a new version of Ada might be as difficult as moving to another vendors compiler for the current version of Ada, and we have always used this distance comparison as a measure of acceptable levels of incompatibility with new versions. I see no practical issue here, only a theoretical issue that in practice is of minimal concern. > > > 14 An implementation may provide implementation-defined pragmas; the > > name of an implementation-defined pragma shall differ from those of > > the language-defined pragmas. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-28 0:44 ` Larry Kilgallen 2001-11-28 15:49 ` Robert Dewar @ 2001-11-28 16:53 ` Larry Kilgallen [not found] ` <5ee5b646.0111280749.77fabe6c@posting.google.coOrganization: LJK Software <PFcoNrf74AeG@eisner.encompasserve.org> 2 siblings, 0 replies; 42+ messages in thread From: Larry Kilgallen @ 2001-11-28 16:53 UTC (permalink / raw) In article <5ee5b646.0111280749.77fabe6c@posting.google.com>, dewar@gnat.com (Robert Dewar) writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<YsaTZ19cOfHh@eisner.encompasserve.org>... >> Was the thought that the set of Ada compiler vendors >> will always be so small that such issues can be worked >> out informally ? > > Not particularly, though this is in practice true. The real > point is that if you use implementation defined attributes > and pragmas, you are making your code incompatible with > other compilers, and that might include compilers for some > new version of Ada, but in any case that means no more than > that going to a new version of Ada might be as difficult as > moving to another vendors compiler for the current version > of Ada, and we have always used this distance comparison > as a measure of acceptable levels of incompatibility with > new versions. But going to a newer version of the same vendor's compiler is something programmers expect to be effortless. If that vendor implements a new language-defined attribute rather than its former implementation-defined attribute which had the same name, the expectation might not be realized. > I see no practical issue here, only a theoretical issue > that in practice is of minimal concern. The sort of approach I would have expected would be a division of the namespace. VMS linker (and other) namespace segregation is done with a dollar sign. Not that a dollar sign is appropriate for Ada, but I would expect some area set aside into which the language-defined attributes will not trespass in the future. ^ permalink raw reply [flat|nested] 42+ messages in thread
[parent not found: <5ee5b646.0111280749.77fabe6c@posting.google.coOrganization: LJK Software <PFcoNrf74AeG@eisner.encompasserve.org>]
* Re: Attributes 'Version and 'Body_Version [not found] ` <5ee5b646.0111280749.77fabe6c@posting.google.coOrganization: LJK Software <PFcoNrf74AeG@eisner.encompasserve.org> @ 2001-11-29 3:49 ` Robert Dewar 2001-11-29 11:52 ` Larry Kilgallen [not found] ` <5ee5b646.0111Organization: LJK Software <Kg7U2sTGDFyI@eisner.encompasserve.org> 2 siblings, 0 replies; 42+ messages in thread From: Robert Dewar @ 2001-11-29 3:49 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<PFcoNrf74AeG@eisner.encompasserve.org>... > But going to a newer version of the same vendor's > compiler > is something programmers expect to be effortless. If > that vendor implements a new language-defined attribute > rather than its former implementation-defined attribute > which had the same name, the expectation might not be > realized. If they expect this for going from a vendors compiler for one Ada standard to its successor, they are fooling themselves. Easy yes, effortless no. I remember the project manager for the old ATC system saying that she expected to be able to move from Ada 83 to Ada 95 without changing a single character of source and I shook my head ... > The sort of approach I would have expected would be a > division of the namespace. VMS linker (and other) > namespace > segregation is done with a dollar sign. Not that a > dollar > sign is appropriate for Ada, but I would expect some area > set aside into which the language-defined attributes will > not trespass in the future. Why? This has not been a problem in practice. Why solve problems that do not exist, when the result would be to degrade readability. It is really useful that the assert pragma in GNAT has this name and not something like Implementation_Assert or somesuch junk. If there is an Ada 0x, and if it includes Assert, and if it (surprisingly) is not upwards compatible with the GNAT pragma, then it is annoying but not disastrous to have to run a trivial script to change the name of pragma Asserts. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version [not found] ` <5ee5b646.0111280749.77fabe6c@posting.google.coOrganization: LJK Software <PFcoNrf74AeG@eisner.encompasserve.org> 2001-11-29 3:49 ` Robert Dewar @ 2001-11-29 11:52 ` Larry Kilgallen [not found] ` <5ee5b646.0111Organization: LJK Software <Kg7U2sTGDFyI@eisner.encompasserve.org> 2 siblings, 0 replies; 42+ messages in thread From: Larry Kilgallen @ 2001-11-29 11:52 UTC (permalink / raw) In article <5ee5b646.0111281949.7032e04b@posting.google.com>, dewar@gnat.com (Robert Dewar) writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<PFcoNrf74AeG@eisner.encompasserve.org>... >> The sort of approach I would have expected would be a >> division of the namespace. VMS linker (and other) >> namespace >> segregation is done with a dollar sign. Not that a >> dollar >> sign is appropriate for Ada, but I would expect some area >> set aside into which the language-defined attributes will >> not trespass in the future. > > Why? To automate the detection of errors wherever possible. ^ permalink raw reply [flat|nested] 42+ messages in thread
[parent not found: <5ee5b646.0111Organization: LJK Software <Kg7U2sTGDFyI@eisner.encompasserve.org>]
* Re: Attributes 'Version and 'Body_Version [not found] ` <5ee5b646.0111Organization: LJK Software <Kg7U2sTGDFyI@eisner.encompasserve.org> @ 2001-11-30 2:26 ` Robert Dewar 2001-11-30 2:55 ` Larry Kilgallen 0 siblings, 1 reply; 42+ messages in thread From: Robert Dewar @ 2001-11-30 2:26 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<Kg7U2sTGDFyI@eisner.encompasserve.org>... > To automate the detection of errors wherever possible. Note by the way that GNAT implements the pragma pragma Restrictions (No_Implementation_Pragmas); pragma Restrictions (No_Implementation_Attributes); to help control the use of implementation attributes and pragmas. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-30 2:26 ` Robert Dewar @ 2001-11-30 2:55 ` Larry Kilgallen 0 siblings, 0 replies; 42+ messages in thread From: Larry Kilgallen @ 2001-11-30 2:55 UTC (permalink / raw) In article <5ee5b646.0111291826.276bc16c@posting.google.com>, dewar@gnat.com (Robert Dewar) writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<Kg7U2sTGDFyI@eisner.encompasserve.org>... >> To automate the detection of errors wherever possible. > > Note by the way that GNAT implements the pragma > > pragma Restrictions (No_Implementation_Pragmas); > pragma Restrictions (No_Implementation_Attributes); > > to help control the use of implementation attributes and > pragmas. That sounds good. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Attributes 'Version and 'Body_Version 2001-11-26 20:05 ` Nick Roberts 2001-11-27 3:56 ` Robert Dewar @ 2001-11-27 17:04 ` Georg Bauhaus 1 sibling, 0 replies; 42+ messages in thread From: Georg Bauhaus @ 2001-11-27 17:04 UTC (permalink / raw) Nick Roberts (:) and Robert Dewar debate: :> There is no point in using the same attribute :> name for two different purposes. : : Yes there is: simplicity. :> > Far be it from me to wish to perpetuate any confusion, :> You can cure someones confusion with documentation [iff...] I find the level of confusion in the thread unsatisfying, in that it is at most at O(1). So let me add some loosely related 2c. Or make that 2 centimes belgique :-) package Versions is -- provide versions at run time, for a change, or maybe not type Version is -- to be attached to objects record Version: Natural; -- XXX provide a decent Version type instead of a Natural -- type for versions end record; type Versioned_Versions is (Versi_On, Versi_Off); -- for toggling versioned versions of Version objects -- See Version below. procedure Which_Version(Want_Versioned_Version: Versioned_Versions); -- toggle versioning feature generic Max_Version: in Natural; -- no more than this number of Versions package Versioning is function Version (V: Version) return Version; -- versions V such that Version V has a Versions.Version iff this feature -- has been turned on with Version (See Version above above). end Versioning; end Versions; package body Versions is VV: Versioned_Versions:= Versi_Off; -- modus operandi -- ---------------- -- Which_Version -- ---------------- -- adjust the state variable VV to have the same value as -- Want_Versioned_Version procedure Which_Version(Want_Versioned_Version: Versioned_Versions) is begin VV:= Want_Versioned_Version; end Which_Version; package body Versioning is protected Versigen is -- new version numbers are assigned here up -- to a limit XXX remove the limit entry Next; -- can't proceed when no more versioning could -- possibly be done XXX Add Free(Ver: Natural) -- (No, neither free the storage, nor Free the storage) function Current return Natural; private Ver: Natural:= 0; end Versigen; protected body Versigen is entry Next when Ver < Max_Version is begin Ver:= Natural'Succ(Ver); end Next; function Current return Natural is begin return Ver; end Current; end Versigen; ------------- -- Version -- ------------- function Version (V: Versions.Version) return Versions.Version is Result: Versions.Version; begin if VV = Versi_On then Want_Versioning: declare Wanted_Version: Natural; begin Versigen.Next; Wanted_Version:= Versigen.Current; Result:= (Version => Wanted_Version); end Want_Versioning; else -- Versi_off Result:= V; end if; return Result; end Version; end Versioning; end Versions; ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2001-11-30 2:55 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-11-06 20:58 Attributes 'Version and 'Body_Version Marin David Condic 2001-11-07 3:39 ` Robert Dewar 2001-11-07 15:08 ` Marin David Condic 2001-11-07 20:51 ` Tony Gair 2001-11-07 16:45 ` Marin David Condic 2001-11-07 18:32 ` Vincent Marciante 2001-11-07 19:00 ` Marin David Condic 2001-11-07 23:11 ` Robert Dewar 2001-11-08 17:28 ` Stephen Leake 2001-11-08 17:43 ` Larry Kilgallen 2001-11-08 19:03 ` Marin David Condic 2001-11-08 19:37 ` Larry Kilgallen 2001-11-09 3:50 ` Robert Dewar 2001-11-09 3:55 ` Robert Dewar 2001-11-08 18:55 ` Marin David Condic 2001-11-07 19:54 ` Larry Kilgallen 2001-11-07 21:49 ` Marin David Condic 2001-11-07 23:08 ` Robert Dewar 2001-11-07 22:04 ` Keith Thompson 2001-11-08 16:34 ` Frank 2001-11-09 3:53 ` Robert Dewar 2001-11-10 0:07 ` Keith Thompson 2001-11-10 2:16 ` Larry Kilgallen 2001-11-11 15:18 ` Marin David Condic 2001-11-12 23:06 ` Tony Gair 2001-11-12 21:51 ` Robert Dewar 2001-11-13 8:07 ` Keith Thompson 2001-11-25 20:49 ` Nick Roberts 2001-11-26 2:30 ` Robert Dewar 2001-11-26 3:31 ` Nick Roberts 2001-11-26 15:42 ` Robert Dewar 2001-11-26 20:05 ` Nick Roberts 2001-11-27 3:56 ` Robert Dewar 2001-11-27 17:51 ` Nick Roberts 2001-11-28 0:44 ` Larry Kilgallen 2001-11-28 15:49 ` Robert Dewar 2001-11-28 16:53 ` Larry Kilgallen [not found] ` <5ee5b646.0111280749.77fabe6c@posting.google.coOrganization: LJK Software <PFcoNrf74AeG@eisner.encompasserve.org> 2001-11-29 3:49 ` Robert Dewar 2001-11-29 11:52 ` Larry Kilgallen [not found] ` <5ee5b646.0111Organization: LJK Software <Kg7U2sTGDFyI@eisner.encompasserve.org> 2001-11-30 2:26 ` Robert Dewar 2001-11-30 2:55 ` Larry Kilgallen 2001-11-27 17:04 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox