* DECAda/VMS - calling GETJPI @ 1996-06-03 0:00 Alan Paterson 1996-06-03 0:00 ` Stuart Palin ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Alan Paterson @ 1996-06-03 0:00 UTC (permalink / raw) Here's one for the VMS gurus (I can't post it to comp.os.vms, 'cos there's a psychopath there who throws abuse at me): I want to examine all processes currently active. The system service to do this is, of course, GetJPI (either in Starlet or Lib). To perform wildcard process search, this procedure expects to receive a value of -1 for the process_id parameter. Unfortunately, in the "official" spec-files for these procedures, this parameter has the type UNSIGNED_LONGWORD. Ada, quite correctly, objects to this kind of thing :-) So, what I now do is the following: PID : UNSIGNED_LONGWORD; PID0 : INTEGER; for PID0 use at PID'address; begin PID0 := -1; loop GetJPI(..., Process_Id => PID, ...); This works, but I can't help but wonder if there isn't a more elegant way to do it. Does anyone have experience with this? -- Alan Paterson Berne, Switzerland ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-03 0:00 DECAda/VMS - calling GETJPI Alan Paterson @ 1996-06-03 0:00 ` Stuart Palin 1996-06-03 0:00 ` Michael F Brenner 1996-06-03 0:00 ` Mats Weber 1996-06-03 0:00 ` Ken Garlington 2 siblings, 1 reply; 24+ messages in thread From: Stuart Palin @ 1996-06-03 0:00 UTC (permalink / raw) To: Alan, Paterson, paterson I've no specific experience of using DEC Ada with GETJPI but this looks very similar to the general problem Ada 83 has with unsigned integers. Basically an unsigned type must be bound by an integer range constraint (LRM 3.5.4 (3)). An unsigned longword usually creates a problem since the base type integer is also usally longword based. This means the upper constarint on unsigned_longword is 2**32-1 which is not a valid integer expression (integer'last = 2**31-1). Many implementations (certainly the version of DEC Ada I am using) gets around this by defining the unsigned_longword as: unsigned_longword is range -2**31..2**31-1; -- or something equivalent This creates all sorts of problems for defining values in the upper range (16#80000000# .. 16#FFFFFFFF#) since they map on to negative values (but the bit image is correct!!). A reasonable way of accessing these values is to define a constant: Hex_80000000 : constant unsigned_longword(-16#80000000#); Now you can do things such as: ulong := Hex_80000000 + 16#456789AB#; Now for your -1 value what you need to use is 16#FFFFFFFF#; (which is the bit image equivalent of the longword integer representation of -1); this could be defined as a constant: Hex_FFFFFFFF : constant unsigned_longword(-1); though you will probably want to use a name more appropriate to your application. -- Stuart Palin | GEC Marconi Avionics Ltd Consultant Engineer | Airport Works Flight Systems Division | Rochester G-NET 791 4197 | Kent. ME1 2XX ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-03 0:00 ` Stuart Palin @ 1996-06-03 0:00 ` Michael F Brenner 1996-06-03 0:00 ` Robert Dewar 0 siblings, 1 reply; 24+ messages in thread From: Michael F Brenner @ 1996-06-03 0:00 UTC (permalink / raw) Under Ada 95, assuming that unsigned_longword was defined as type unsigned_longword is mod 2**64; or type unsigned_longword is mod 2**32; you could just assign it: integer_minus_1: integer := -1; x: unsigned_longword := unsigned_longword (integer_minus_1); because Ada 95 modular types truncate numbers to their modular range without giving a constraint_error. However, if unsigned_longword is defined using one of the Ada-83 workarounds earlier in this thread, then the workarounds earlier in this thread could be attempted, with appropriate tests to make sure they are doing what you think they are doing. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-03 0:00 ` Michael F Brenner @ 1996-06-03 0:00 ` Robert Dewar 1996-06-04 0:00 ` Michael F Brenner 1996-06-04 0:00 ` Ken Garlington 0 siblings, 2 replies; 24+ messages in thread From: Robert Dewar @ 1996-06-03 0:00 UTC (permalink / raw) Micheal Brenner said: "you could just assign it: integer_minus_1: integer := -1; x: unsigned_longword := unsigned_longword (integer_minus_1); because Ada 95 modular types truncate numbers to their modular range without giving a constraint_error." That's quite wrong, the type conversoin checks that the value is in range, and the value is outside the range. Indeed if you add a constant to the declaration of integer_minus_1, the out of range condition will be detected at compile time by GNAT: 1. procedure z is 2. type ul is mod 2 ** 64; 3. integer_minus_1: constant integer := -1; 4. x: ul := ul (integer_minus_1); | >>> warning: static value out of range of type "ul" defined at line 2 >>> warning: "constraint_error" will be raised at runtime 5. begin 6. null; 7. end; Yes, you can apply the unary minus operator to an unsigned vaue and get modular results as expected, but here the minus is applied to a signed type and generates a real minus one, which is definitely outside the range of any unsigned type. It's probably time again to repost the plea that if you suggest a solution to a problem, compile an example and make sure it works. No one is realiable enough to be 100% accurate without such a backup check, and posting incorrect information on Ada can cause a lot of confusion! IN fact the proper solution in this case is trivial: procedure z is type unsigned_longword is mod 2 ** 64; x: unsigned_longword := -1; begin null; end; or, if you want the constant integer_minus_1, define it as type ul to start with. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-03 0:00 ` Robert Dewar @ 1996-06-04 0:00 ` Michael F Brenner 1996-06-04 0:00 ` Robert Dewar 1996-06-04 0:00 ` Ken Garlington 1 sibling, 1 reply; 24+ messages in thread From: Michael F Brenner @ 1996-06-04 0:00 UTC (permalink / raw) That's quite right, GNAT gives the error message below, but in doing so it violates the Ada 95 Reference Manual and Rationale. Specifically, (Rationale 3.3.2 fourth paragraph): The normal arithmetic operations apply [to modular types] ... overflow cannot occur. (3.3.2 fifth paragraph) Conversion from modular to signed integer types works in a useful manner so that overflow does not occur. (3.3.2 sixth paragraph) We can think of this conversion as being somewhat akin to the sliding of array conversions. (2.12) ... the removal of the notorious irritation that for I in -1..100 loop was not allowed in Ada 83. It is allowed in Ada 9X. (3.8) We have generalized implicit subtype conversions on arrays (sliding) to apply in more circumstances. These new rules should minimize the times when an unexpected constraint_error arises when the length of the array value is appropriate, but the upper and lower bounds do not match the applicable index constraint. ... the bounds may be freely readjusted to fit the context. (3.3.2 paragraph 2) The modular types are unsigned integer types which exhibit cyclic arithmetic. They thus correspond to the unsigned types of some other languages such as C. (RM 3.5.4(1)) A modular type is an integer type with all arithmetic modulo a specified positive modulus. Such a type corresponds to an unsigned type with wrap-around semantics. (RM 3.5.4(19)) For a modular type, if the result of the execution of a predefined operator (see 4.5) is outside the base range of the type, the result is reduced modulo the modulus of the type to a value that is within the base range of the type. For a signed integer type, the exception constraint_error is raised by the execution of an operation that cannot deliver the correct result because it is outside the base range of the type. For any integer type constraint_error is raised by the operators /, REM, and MOD if the right operand is zero. (RM 4.6(30)) Numeric Type Conversion: If the target and the operand types are both integer types, then the result is the value of the target type that corresponds to the same mathematical integer as the operand. > Robert Dewar wrote: > It's probably time again to repost the plea that if you suggest a solution > to a problem, compile an example and make sure it works. No one is realiable > enough to be 100% accurate without such a backup check, and posting incorrect > information on Ada can cause a lot of confusion! I compiled my example before posting this, and reported it as a bug in gnat, with an example. The fact that it fails in gnat does not mean the solution is erroneous; the other possibility is that the gnat interpretation of the Reference Manual and Rationale violates the above sentences. Gnat's erroneous interpretation places us at risk of creating another notorious irritation, another unexpected constraint_error, a needless inefficiency, and a contradiction to the meaning of the words: Modular, Cycle, Sliding, Reduced, Wrap-Around Semantics, Useful, and Cannot Occur. Recommendation: To avoid causing a lot of confusion, please change gnat to comply with the above sentences from the Reference Manual and Rationale, permitting modular, cyclical, reduced, wrap_around semantics to occur when converting a signed integer to an unsigned integer, providing a Useful operation where constraint_error does not occur. Mike Brenner <mikeb@mitre.org> > Mike Brenner said: > > "you could just assign it: > > integer_minus_1: integer := -1; > x: unsigned_longword := unsigned_longword (integer_minus_1); > > because Ada 95 modular types truncate numbers to their modular range > without giving a constraint_error." > > Dewar replied: > > That's quite wrong, the type conversoin checks that the value is in > range, and the value is outside the range. Indeed if you add a constant > to the declaration of integer_minus_1, the out of range condition will > be detected at compile time by GNAT: > > 1. procedure z is > 2. type ul is mod 2 ** 64; > 3. integer_minus_1: constant integer := -1; > 4. x: ul := ul (integer_minus_1); > | > >>> warning: static value out of range of type "ul" defined at line 2 > >>> warning: "constraint_error" will be raised at runtime > 5. begin > 6. null; > 7. end; > > Yes, you can apply the unary minus operator to an unsigned vaue and get > modular results as expected, but here the minus is applied to a signed > type and generates a real minus one, which is definitely outside the > range of any unsigned type. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-04 0:00 ` Michael F Brenner @ 1996-06-04 0:00 ` Robert Dewar 1996-06-04 0:00 ` Michael F Brenner 0 siblings, 1 reply; 24+ messages in thread From: Robert Dewar @ 1996-06-04 0:00 UTC (permalink / raw) Mike Brenner says "That's quite right, GNAT gives the error message below, but in doing so it violates the Ada 95 Reference Manual and Rationale. Specifically, (Rationale 3.3.2 fourth paragraph): The normal arithmetic operations apply [to modular types] ... overflow cannot occur. (3.3.2 fifth paragraph) Conversion from modular to signed integer types works in a useful manner so that overflow does not occur. (3.3.2 sixth paragraph) We can think" Yes, that's right GNAT violates the Rationale here. That's because the Rationale is wrong. TO be fair, the problem is that it reflects the language design as it was prior to the meeting in England. Mike, always read the RM, not the Rationale, when they disagree, the Ratoinale has no official status whatsoever. You cannot violate the Rationale really, since it is not an official document. You can disagree with it, and most certainly should, when the Rationale is incorrect. The RM is quite clear on this point (I notice you did not try to quote the RM to back up your incorrect interpretation, though it is certainly understandable that you would assume that what you read in the Rationale was correct). The conversion raises constraint error because the value in question is outside the range of the target type. Nowhere in the RM can you find a suggestion that modular types are treated specially in such conversions because there is no such special treatment. There are not many technical errors in the Rationale of this type. All the ones I know about are in this category, they reflect a change to the language made late on, where the Rationale did not track the change. It would be quite useful to have a comprehensive errata list for the Rationale, but I do not know of one. Anyway, bottom line, GNAT is right, Mike is wrong! P.S. for the RM archeologists, the most obvious reference is in section 4.6 28 For the evaluation of a type_conversion that is a value conversion, the operand is evaluated, and then the value of the operand is converted to a corresponding value of the target type, if any. If there is no value of the target type that corresponds to the operand value, Constraint_Error is raised; this can only happen on conversion to a modular type, and only when the operand value is outside the base range of the modular type. Additional rules follow: [seems clear enough to me!] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-04 0:00 ` Robert Dewar @ 1996-06-04 0:00 ` Michael F Brenner 1996-06-04 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Michael F Brenner @ 1996-06-04 0:00 UTC (permalink / raw) Mike Brenner said: "you could just assign it: integer_minus_1: integer := -1; x: unsigned_longword := unsigned_longword (integer_minus_1); because Ada 95 modular types truncate numbers to their modular range without giving a constraint_error." ------------ Robert Dewar replied: > That's quite wrong, the type conversoin checks that the value is in > range, and the value is outside the range. Indeed if you add a constant > to the declaration of integer_minus_1, the out of range condition will > be detected at compile time by GNAT: > 2. type ul is mod 2 ** 64; > 3. integer_minus_1: constant integer := -1; > 4. x: ul := ul (integer_minus_1); > | > >>> warning: static value out of range of type "ul" defined at line 2 > >>> warning: "constraint_error" will be raised at runtime > > Yes, you can apply the unary minus operator to an unsigned vaue and get > modular results as expected, but here the minus is applied to a signed > type and generates a real minus one, which is definitely outside the > range of any unsigned type. ------------ Mike Brenner responded: > That's quite right, GNAT gives the error message below, but in doing > so it violates the Ada 95 Reference Manual and Rationale. Specifically, > (Rationale 3.3.2 fourth paragraph): The normal arithmetic operations > apply [to modular types] ... overflow cannot occur. (3.3.2 fifth paragraph) > Conversion from modular to signed integer types works in a useful manner > so that overflow does not occur. (3.3.2 sixth paragraph) We can think > of this conversion as being somewhat akin to the sliding of array > conversions. (2.12) ... the removal of the notorious irritation that > for I in -1..100 loop was not allowed in Ada 83. It is allowed in Ada 9X. > (3.8) We have generalized implicit subtype conversions on arrays (sliding) > to apply in more circumstances. These new rules should minimize the times > when an unexpected constraint_error arises when the length of the array > value is appropriate, but the upper and lower bounds do not match the > applicable index constraint. ... the bounds may be freely readjusted to fit > the context. (3.3.2 paragraph 2) The modular types are unsigned integer > types which exhibit cyclic arithmetic. They thus correspond to the > unsigned types of some other languages such as C. (RM 3.5.4(1)) A modular > type is an integer type with all arithmetic modulo a specified positive > modulus. Such a type corresponds to an unsigned type with wrap-around > semantics. (RM 3.5.4(19)) For a modular type, if the result of > the execution of a predefined operator (see 4.5) is outside the base > range of the type, the result is reduced modulo the modulus of the type > to a value that is within the base range of the type. For a signed integer > type, the exception constraint_error is raised by the execution of an > operation that cannot deliver the correct result because it is outside > the base range of the type. For any integer type constraint_error is > raised by the operators /, REM, and MOD if the right operand is zero. > (RM 4.6(30)) Numeric Type Conversion: If the target and the operand types > are both integer types, then the result is the value of the target type > that corresponds to the same mathematical integer as the operand. ------------ Robert Dewar responded: It's probably time again to repost the plea that if you suggest a solution to a problem, compile an example and make sure it works. No one is realiable enough to be 100% accurate without such a backup check, and posting incorrect information on Ada can cause a lot of confusion! ------------ Mike Brenner responded: > I compiled my example before posting this, and reported it as a bug > in gnat, with an example. The fact that it fails in gnat does not mean > the solution is erroneous; the other possibility is that the gnat > interpretation of the Reference Manual and Rationale violates the > above sentences. Gnat's erroneous interpretation places us at risk of > creating another notorious irritation, another unexpected constraint_error, > a needless inefficiency, and a contradiction to the meaning of the words: > Modular, Cycle, Sliding, Reduced, Wrap-Around Semantics, Useful, and > Cannot Occur. > Recommendation: To avoid causing a lot of confusion, please change gnat > to comply with the above sentences from the Reference Manual and Rationale, > permitting modular, cyclical, reduced, wrap_around semantics to occur when > converting a signed integer to an unsigned integer, providing a Useful > operation where constraint_error does not occur. ------------ Robert Dewar responded: That's right GNAT violates the Rationale here. That's because the Rationale is wrong. TO be fair, the problem is that it reflects the language design as it was prior to the meeting in England. Mike, always read the RM, not the Rationale, when they disagree, the Ratoinale has no official status whatsoever. You cannot violate the Rationale really, since it is not an official document. You can disagree with it, and most certainly should, when the Rationale is incorrect. The RM is quite clear on this point (I notice you did not try to quote the RM to back up your incorrect interpretation, though it is certainly understandable that you would assume that what you read in the Rationale was correct). The conversion raises constraint error because the value in question is outside the range of the target type. Nowhere in the RM can you find a suggestion that modular types are treated specially in such conversions because there is no such special treatment. There are not many technical errors in the Rationale of this type. All the ones I know about are in this category, they reflect a change to the language made late on, where the Rationale did not track the change. It would be quite useful to have a comprehensive errata list for the Rationale, but I do not know of one. Anyway, bottom line, GNAT is right, Mike is wrong! P.S. for the RM archeologists, the most obvious reference is in section 4.6 28 For the evaluation of a type_conversion that is a value conversion, the operand is evaluated, and then the value of the operand is converted to a corresponding value of the target type, if any. If there is no value of the target type that corresponds to the operand value, Constraint_Error is raised; this can only happen on conversion to a modular type, and only when the operand value is outside the base range of the modular type. [seems clear enough to me!] ------------ Mike Brenner responds Six of the quotes came from the Rationale, three of the quotes came from the RM, and there is no contradiction between the six and the three. The gnat interpretation is an inefficient interpretation because it requires extra checks and extra consternation on the part of maintenance and development programmers. The gnat interpretation is an incorrect interpretation because it does not comply with the Reference Manual 3.5.4(19) requiring reduction modulo the modulus; it does not comply with the Reference Manual 3.5.4(1) requiring ALL arithmetic to be modulo the modulus (including type casting); it does not comply with Reference Manual 4.6(30) requiring type conversion to go to the same mathematical integer, which according to Reference Manual 3.5.4(1) is modulo the modulus. After going modulo the modulus, no number can be outside the range of a modular type. Paragraph 28 of Section 4.6 states that constraint_error on conversion <can only happen on conversion to a modular type>. This is a typographical error. It makes no sense, and it contradicts both the above three paragraphs in the Reference Manual, and it contradicts the fact that constraint_error is raised only on converting to a non-modular type. It should be changed to read <can only happen on conversion to a non-modular type>. For example, when converting to type integer and the value is out of range of integer'first..integer'last, a constraint_error is generated. Since modular types must never give a constraint_error, and since non-modular types must always give a constraint_error when an out of range value is provided to a type converter, this typographical error should be corrected. Recommendation: Fix this typographical error through the proper channels, but in the meanwhile, change your interpretation of modular types back to that of the Rationale, change gnat to convert modular types without giving a constraint_error, and please give a reference to the meeting in England which overrides the Rationale and how I can participate in future meetings of this sort. Mike Brenner ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-04 0:00 ` Michael F Brenner @ 1996-06-04 0:00 ` Robert Dewar 1996-06-05 0:00 ` Robert A Duff ` (2 more replies) 1996-06-04 0:00 ` DECAda/VMS - calling GETJPI Robert Dewar 1996-06-05 0:00 ` Adam Beneschan 2 siblings, 3 replies; 24+ messages in thread From: Robert Dewar @ 1996-06-04 0:00 UTC (permalink / raw) Mike asked:: "Recommendation: Fix this typographical error through the proper channels, but in the meanwhile, change your interpretation of modular types back to that of the Rationale, change gnat to convert modular types without giving a constraint_error, and please give a reference to the meeting in England which overrides the Rationale and how I can participate in future meetings of this sort." This was a meeting of WG9 and the DR's (one of a few joint meetings at this stage). Of course now the DR's no longer exist, so the issue is WG9 meetings. At these meetings, participants are members of their appointed national delegations. You need to apply through the proper channels which vary from country to country if you wish to be a member of the delegation from a given country. There was no question of "overriding" the Rationale, since as I said, it is not an official WG9 document (or for that matter an official anything document). What the meeting in England did was decide to change the way modular operations were handled, and in particular to change the semantics of conversion to avoid the implicit modular conversion. There were a number of closely related issues, and when considered together, it was clearly an advantageous change, as evidenced by the fact that the vote in favor of this change was unanimous by delegations. The Rationale is an informal attempt to describe the reasoning behind the major design decisions. It always had the trouble of tracking a moving target, and in this case, it tracked an earlier vresion of the RM, and the relevant section did not get properly updated. As I said earlier, always read the RM for technical details on the language (or a good book like Norman Cohen's book that accurately discusses the language). Read the RM for a general appreciation of the design princiles, but not for technical details. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-04 0:00 ` Robert Dewar @ 1996-06-05 0:00 ` Robert A Duff 1996-06-05 0:00 ` Robert Dewar 1996-06-05 0:00 ` Fergus Henderson 1996-06-05 0:00 ` Wraparound on modular conversion (was: DECAda/VMS - calling GETJPI) Tucker Taft 2 siblings, 1 reply; 24+ messages in thread From: Robert A Duff @ 1996-06-05 0:00 UTC (permalink / raw) Robert is correct -- a type conversion of -1 to a modular type will raise C_E. -1 and 255 are *not* the "same mathematical integer". Mike is, perhaps, confused between converting to a *type* and converting to a *subtype*. 4.6(51) says that when converting to a subtype, you first convert to the type, and then do a constraint check. This can, indeed, raise an exception when converting to a non-modular *subtype*, such as Integer. However, when converting to a *type*, the only exceptions are when the target type is modular. Robert's description of the history is correct: an earlier version of Ada 9X did what Mike says, but it was changed. (Robert has a better memory than I as to which meeting that decision was made at, and where the meeting was held.) This language change explains why the Rationale is wrong -- it was simply not updated correctly to match the RM in this case. Nobody is actively working on the Rationale at this point, as far as I know, so this bug in the Rationale will remain unfixed. Bugs in the RM, on the other hand, are addressed by the ARG. There are instructions at the front of the RM telling where to send any comments on the RM, so that the ARG will see them. - Bob ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-05 0:00 ` Robert A Duff @ 1996-06-05 0:00 ` Robert Dewar 0 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1996-06-05 0:00 UTC (permalink / raw) The basic idea here is that type conversion converts the type, but not the value, of course floating-point to int already violates this somewhat as Bob points out, but not quite as dramatically. Consider the following example: type x is mod 10; subtype y is x range 0 .. 5; vy : y; vy := y (-4) -- raises constraint error vy := y (-6) -- ok, gives result of 4 At the meeting we accumulated a series of odd examples of this kind, and decided that it is just a bit too weird to have type conversion generating what amounts to a significant arithmetic computation. P.S. in my comments in the example above, I am assuming for the moment the old semantics. In current Ada 95, BOTH assigments to vy raise constraint error, since -1 is not in the range 0 .. 5. Actually to be strict, the constraint error is raised by the conversion because -1 is not in the set of values for modular type x (0 .. 10). ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-04 0:00 ` Robert Dewar 1996-06-05 0:00 ` Robert A Duff @ 1996-06-05 0:00 ` Fergus Henderson 1996-06-05 0:00 ` Robert A Duff 1996-06-05 0:00 ` Wraparound on modular conversion (was: DECAda/VMS - calling GETJPI) Tucker Taft 2 siblings, 1 reply; 24+ messages in thread From: Fergus Henderson @ 1996-06-05 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) writes: >What the meeting in England did was decide to change the way >modular operations were handled, and in particular to change the semantics >of conversion to avoid the implicit modular conversion. There were a number >of closely related issues, and when considered together, it was clearly >an advantageous change, as evidenced by the fact that the vote in favor >of this change was unanimous by delegations. It would be helpful if someone were to give a brief explanation of the arguments in favour of this design decision. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-05 0:00 ` Fergus Henderson @ 1996-06-05 0:00 ` Robert A Duff 0 siblings, 0 replies; 24+ messages in thread From: Robert A Duff @ 1996-06-05 0:00 UTC (permalink / raw) In article <4p32m3$51g@mulga.cs.mu.OZ.AU>, Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote: >It would be helpful if someone were to give a brief explanation >of the arguments in favour of this design decision. I can't remember all the details of the arguments at the time. I think part of it was that people thought the old rules were confusing. People felt that since -1 is simply not a value of the modular type, that it ought to raise C_E on conversion. Arithmetic purely within the modular type is different -- you can never get the value -1 in the first place. One might like type conversions to be reversible. I: Integer := -1; subtype S1 is Integer range 0..255; X: S1 := 255; subtype S2 is Integer range -128..127; Y: S2 := -1; type M is mod 256; Z: M; Now converting 255 of type M to type Integer produces 255, clearly, and not -1. So: Z := M(I); -- Contraint_Error happens here, but if it didn't, then I := Integer(Z); -- ...now I has changed its value, which some -- might consider strange. Z := M(Y); -- OK. X := Integer(Z); -- Here, X has the same value it did before. Z := M(X); -- Contraint_Error happens here, but if it didn't, then Y := Integer(Z); -- ...you'd get Constraint_Error here. Whether this would confuse is, I suppose, a matter of opinion. Now, consider: procedure P(Param: in out M) is begin null; end P; I: Integer := -1; P(M(I)); Here, I is converted to type M before the call, and converted back to type Integer after the call. It might seem strange for a procedure containing just a null statement to modify its parameter (changing -1 to 255). (On the other hand, floating point types have the same trouble.) In other cases, a call to P would raise Constraint_Error while trying to convert back to the integer type. Consider also modular-to-modular conversions. E.g.: type M1 is mod 4; type M2 is mod 3; Now, should converting from M1 to M2 and back to M1 change the value? Or is it better to consider it an error when the conversion is not reversible (that is, when the original value is 3)? One final example: type T is range -1..100; type M is mod 2**32; If we convert the value 101 of type M to SUBtype T, it will clearly raise Constraint_Error. Should converting 2**32-1 do the same, or should it return -1? - Bob ^ permalink raw reply [flat|nested] 24+ messages in thread
* Wraparound on modular conversion (was: DECAda/VMS - calling GETJPI) 1996-06-04 0:00 ` Robert Dewar 1996-06-05 0:00 ` Robert A Duff 1996-06-05 0:00 ` Fergus Henderson @ 1996-06-05 0:00 ` Tucker Taft 1996-06-05 0:00 ` Robert Dewar 2 siblings, 1 reply; 24+ messages in thread From: Tucker Taft @ 1996-06-05 0:00 UTC (permalink / raw) Robert is right, the letter and the intent of RM95 is that conversions to a modular type do *not* do a "modulo" operation. We discussed this particular issue at length during one of the 9X language review meetings, and ultimately decided it this way. This approach prevents unintended wraparound on conversion. In retrospect, I am not positive we made the right decision, since I do find myself on occasion wishing there were some way to have the conversion do the modulo operation. One way that will sometimes work is: X : Signed_Int; Y : Modular_Int := Modular_Int(Signed_Int'Pos(X) mod Modular_Int'Modulus); This will do the modulo operation in "root_integer" which is fine so long as Modular_Int'Modulus is <= System.Max_Int. Otherwise, you will get a compile-time error, and you may have to revert to unchecked_conversion or to a sequence of statements that avoid the overflow. For example, if Modular_Int'Modulus is > Signed_Int'Last, the following sequence of statements will work without a possibility of overflow: if X >= 0 then Y := Modular_Int(X); else -- X is < 0, make it positive, convert, and then subtract -- with wraparound. Y := Modular_Int(X - Signed_Int'First) - (Modular_Int(-1 - Signed_Int'First) + 1); end if; Probably the best long term solution would be to add an attribute function, analogous to 'Val, that does the modulo operation as part of the conversion. E.g. Modular_Int'Modulo(X) would never overflow, and would perform the modulo operation as part of the conversion. Might be a good "Uniformity Rapporteur Group" (URG) idea... -Tucker Taft stt@inmet.com Intermetrics, Inc. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Wraparound on modular conversion (was: DECAda/VMS - calling GETJPI) 1996-06-05 0:00 ` Wraparound on modular conversion (was: DECAda/VMS - calling GETJPI) Tucker Taft @ 1996-06-05 0:00 ` Robert Dewar 0 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1996-06-05 0:00 UTC (permalink / raw) "Probably the best long term solution would be to add an attribute function, analogous to 'Val, that does the modulo operation as part of the conversion. E.g. Modular_Int'Modulo(X) would never overflow, and would perform the modulo operation as part of the conversion. Might be a good "Uniformity Rapporteur Group" (URG) idea..." That sounds useful, I think we will put this in the next version of GNAT. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-04 0:00 ` Michael F Brenner 1996-06-04 0:00 ` Robert Dewar @ 1996-06-04 0:00 ` Robert Dewar 1996-06-05 0:00 ` Adam Beneschan 2 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1996-06-04 0:00 UTC (permalink / raw) Mike said "Six of the quotes came from the Rationale, three of the quotes came from the RM, and there is no contradiction between the six and the three. The gnat interpretation is an inefficient interpretation because it requires extra checks and extra consternation on the part of maintenance and development programmers. The gnat interpretation is an incorrect interpretation because it does not comply with the Reference Manual 3.5.4(19) requiring reduction modulo the modulus; it does not comply with the Reference Manual 3.5.4(1) requiring ALL arithmetic to be modulo the modulus (including type casting); it does not comply with Reference Manual 4.6(30) requiring type conversion to go to the same mathematical integer, which according to Reference Manual 3.5.4(1) is modulo the modulus." 3.5.4(19) is about predefined opertors, conversion is not a predefined opertor, so this paragraph is irrelevant to the discussion and does not apply. 3.5.1(1) talks about arithmetic being modular, conversion is not an arithmetic operation in the RM sense, so this paragraph is irrelevant to the discussion. Mike your reading is just wrong, sorry. You seem to be tenaciously holding on to it, but it is unsupportable. Note in particular that the idea that -1 and 255 (or whatever) are the same mathematical integer is particularly bizarre. The sentence you call a typographical error is not a typographical error at all. The sentence in question: 28 For the evaluation of a type_conversion that is a value conversion, the operand is evaluated, and then the value of the operand is converted to a corresponding value of the target type, if any. If there is no value of the target type that corresponds to the operand value, Constraint_Error is raised; this can only happen on conversion to a modular type, and only when the operand value is outside the base range of the modular type. Additional rules follow: ONly applies to modular types, since it is only modular types where the set of values is limited. The conceptual set of values for signed integer types includes the full set of integers (of course subsequently a constraint error may occur from violating a constraint on the type. For example: x : integer := integer (999999999999999999999999); raises a constraint error, not because of anything in paragraph 28, but because the resulting value violates the constraint on integer. On the other hand x : integer'base := integer'base (9999999999999999999999999999); may not necessarily raise CE, since no constraint check is required since Integer'Base is an unconstrained type. For modular types however, the set of values includes the full set of values in the base type (e.g. 0,1,2,3 for mod 4) but no other values. So this is not a typographical error, though I can see with your style of "wishful reading" you would hope that it was one! To repeat again, GNAT is correct, Mike's interpretatoin of the RM (aided and abetted by some obsolete errors in the Rationale) is wrong. The RM is not an easy document to read, and chapter 3 especially has to be read very carefully without any sloppiness in terminology. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-04 0:00 ` Michael F Brenner 1996-06-04 0:00 ` Robert Dewar 1996-06-04 0:00 ` DECAda/VMS - calling GETJPI Robert Dewar @ 1996-06-05 0:00 ` Adam Beneschan 1996-06-07 0:00 ` Norman H. Cohen 2 siblings, 1 reply; 24+ messages in thread From: Adam Beneschan @ 1996-06-05 0:00 UTC (permalink / raw) mfb@mbunix.mitre.org (Michael F Brenner) writes: > Robert Dewar replied: > >> That's quite wrong, the type conversoin checks that the value is in >> range, and the value is outside the range. Indeed if you add a constant >> to the declaration of integer_minus_1, the out of range condition will >> be detected at compile time by GNAT: >> 2. type ul is mod 2 ** 64; >> 3. integer_minus_1: constant integer := -1; >> 4. x: ul := ul (integer_minus_1); >> | >> >>> warning: static value out of range of type "ul" defined at line 2 >> >>> warning: "constraint_error" will be raised at runtime . . . > ------------ > Mike Brenner responded: > >> That's quite right, GNAT gives the error message below, but in doing >> so it violates the Ada 95 Reference Manual and Rationale. Specifically, >> (Rationale 3.3.2 fourth paragraph): The normal arithmetic operations >> apply [to modular types] ... overflow cannot occur. (3.3.2 fifth paragraph) >> Conversion from modular to signed integer types works in a useful manner >> so that overflow does not occur. (3.3.2 sixth paragraph) We can think >> of this conversion as being somewhat akin to the sliding of array >> conversions. (2.12) ... the removal of the notorious irritation that >> for I in -1..100 loop was not allowed in Ada 83. It is allowed in Ada 9X. >> (3.8) We have generalized implicit subtype conversions on arrays (sliding) >> to apply in more circumstances. These new rules should minimize the times >> when an unexpected constraint_error arises when the length of the array >> value is appropriate, but the upper and lower bounds do not match the >> applicable index constraint. ... the bounds may be freely readjusted to fit >> the context. (3.3.2 paragraph 2) The modular types are unsigned integer >> types which exhibit cyclic arithmetic. They thus correspond to the >> unsigned types of some other languages such as C. (RM 3.5.4(1)) A modular >> type is an integer type with all arithmetic modulo a specified positive >> modulus. Such a type corresponds to an unsigned type with wrap-around >> semantics. (RM 3.5.4(19)) For a modular type, if the result of >> the execution of a predefined operator (see 4.5) is outside the base >> range of the type, the result is reduced modulo the modulus of the type >> to a value that is within the base range of the type. For a signed integer >> type, the exception constraint_error is raised by the execution of an >> operation that cannot deliver the correct result because it is outside >> the base range of the type. For any integer type constraint_error is >> raised by the operators /, REM, and MOD if the right operand is zero. >> (RM 4.6(30)) Numeric Type Conversion: If the target and the operand types >> are both integer types, then the result is the value of the target type >> that corresponds to the same mathematical integer as the operand. . . . >Mike Brenner responds > >Six of the quotes came from the Rationale, three of the quotes came from the >RM, and there is no contradiction between the six and the three. The gnat >interpretation is an inefficient interpretation because it requires extra >checks and extra consternation on the part of maintenance and development >programmers. The gnat interpretation is an incorrect interpretation because >it does not comply with the Reference Manual 3.5.4(19) requiring reduction >modulo the modulus; it does not comply with the Reference Manual 3.5.4(1) >requiring ALL arithmetic to be modulo the modulus (including type casting); >it does not comply with Reference Manual 4.6(30) requiring type conversion >to go to the same mathematical integer, which according to Reference Manual >3.5.4(1) is modulo the modulus. Sorry, Mike, but 3.5.4(19) isn't relevant. 3.5.4(19) talks about the result of the execution of a predefined operator; and type conversion is not a predefined operator. See 4.5. 3.5.4(1) really doesn't apply either, since it says "all arithmetic [is] modulo a specified positive modulus." Type conversions really don't qualify as arithmetic, although I suppose that could be open to debate. The RM doesn't define the term "arithmetic". > >After going modulo the modulus, no number can be outside the range of a >modular type. > >Paragraph 28 of Section 4.6 states that constraint_error on conversion ><can only happen on conversion to a modular type>. This is a typographical >error. It makes no sense, and it contradicts both the above three >paragraphs in the Reference Manual, and it contradicts the fact that >constraint_error is raised only on converting to a non-modular type. > >It should be changed to read <can only happen on conversion to a >non-modular type>. I'm not qualified to determine whether this is a typo. Actually, the only people that can say for sure are those involved in writing the RM. I'll have to admit that I don't know what the paragraph as written means. -- Adam ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-05 0:00 ` Adam Beneschan @ 1996-06-07 0:00 ` Norman H. Cohen 1996-06-11 0:00 ` Adam Beneschan 0 siblings, 1 reply; 24+ messages in thread From: Norman H. Cohen @ 1996-06-07 0:00 UTC (permalink / raw) In article <4p547s$n99@krusty.irvine.com>, adam@irvine.com (Adam Beneschan) writes: |> mfb@mbunix.mitre.org (Michael F Brenner) writes: ... |> >Paragraph 28 of Section 4.6 states that constraint_error on conversion |> ><can only happen on conversion to a modular type>. This is a typographical |> >error. It makes no sense, and it contradicts both the above three |> >paragraphs in the Reference Manual, and it contradicts the fact that |> >constraint_error is raised only on converting to a non-modular type. |> > |> >It should be changed to read <can only happen on conversion to a |> >non-modular type>. |> |> I'm not qualified to determine whether this is a typo. Actually, the |> only people that can say for sure are those involved in writing the |> RM. I'll have to admit that I don't know what the paragraph as |> written means. It's not a typo, but it is a case of the RM getting overly pedantic and obscure. For reasons that Tucker may remember but I do not, all numeric types other than modular types are described as having an infinite "set of values", some of which belong to a finite "base range": RM95 3.5.4(8): "The set of values for a signed integer type is the (infinite) set of mathematical integers, though only values of the base range of the type are fully supported for run-time operations. The set of values for a modular integer type are the values from 0 to one less than the modulus, inclusive." RM95 3.5.6(8): "The set of values of a floating-point type is the (infinite) set of rational numbers." RM95 3.5.9(8): "The set of values of a fixed-point type comprise integral multiples of number called the _small_ of the type." (Base ranges are described in RM95 3.5(6).) Thus RM95 4.6(28) is correct when it states: "If there is no value of the target type that corresponds to the operand value, Constraint_Error is raised. This can only happen on conversion to a modular type, and only when the operand value is outside the base range of the modular type." (Nonnumeric value conversions are always to a target type that has a corresponding value for each value of the operand type. Since all numeric types other than modular types are conceptually infinite, conversions to a numeric type other than a modular type are always to such a target type; conversions to a modular type are not.) The word "This" in 4.6(28) refers to the raising of Constraint_Error specifically because there is no corresponding value in the target type, not to the raising of Constraint_Error in general. Yet we all know that given the declaration type T is range 1 .. 10; the conversion T(11) raises Constraint_Error, so what's going on here? The answer is found in RM95 4.6(51): "After conversion of the value to the target type, if the target subtype is constrained, a check is performed that the value satisfies this constraint." In short, a value conversion consists of converting to the target type, which can only raise Constraint_Error when the target type is a modular type, followed by a check that the converted value obeys the constraint of the target subtype, which generally has the potential to raise Constraint_Error for any target type. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-07 0:00 ` Norman H. Cohen @ 1996-06-11 0:00 ` Adam Beneschan 0 siblings, 0 replies; 24+ messages in thread From: Adam Beneschan @ 1996-06-11 0:00 UTC (permalink / raw) In article <4p9k71$11a1@watnews1.watson.ibm.com> ncohen@watson.ibm.com writes: >Thus RM95 4.6(28) is correct when it states: > > "If there is no value of the target type that corresponds to the > operand value, Constraint_Error is raised. This can only happen on > conversion to a modular type, and only when the operand value is > outside the base range of the modular type." > Thank you for explaining the meaning of this paragraph so clearly. -- Adam ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-03 0:00 ` Robert Dewar 1996-06-04 0:00 ` Michael F Brenner @ 1996-06-04 0:00 ` Ken Garlington 1996-06-06 0:00 ` Robert Dewar 1 sibling, 1 reply; 24+ messages in thread From: Ken Garlington @ 1996-06-04 0:00 UTC (permalink / raw) Robert Dewar wrote: > > IN fact the proper solution in this case is trivial: > > procedure z is > type unsigned_longword is mod 2 ** 64; > x: unsigned_longword := -1; > begin > null; > end; > I thought the original post required a solution compatible with DEC Ada hosted on VAX/VMS. I don't think this solution is going to fly in that environment :) On the other hand, I _did_ compile my solution before posting it, so there! -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-04 0:00 ` Ken Garlington @ 1996-06-06 0:00 ` Robert Dewar 0 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1996-06-06 0:00 UTC (permalink / raw) Ken Garlington said, replying to a post by me "> procedure z is > type unsigned_longword is mod 2 ** 64; > x: unsigned_longword := -1; > begin > null; > end; > I thought the original post required a solution compatible with DEC Ada hosted on VAX/VMS. I don't think this solution is going to fly in that environment :)" Sure, that's true enough, but I was responding to some incorrect Ada 95 code that was proposed with some correct Ada 95 code! But it cerainly will not work on Dec Ada hosted on VAX/VMS :-( Maybe one day we will be able to compile the above program on VAX/VMS who can tell? :-) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-03 0:00 DECAda/VMS - calling GETJPI Alan Paterson 1996-06-03 0:00 ` Stuart Palin @ 1996-06-03 0:00 ` Mats Weber 1996-06-03 0:00 ` Ken Garlington 2 siblings, 0 replies; 24+ messages in thread From: Mats Weber @ 1996-06-03 0:00 UTC (permalink / raw) In article <31B2AF74.668E@dial.eunet.ch>, Alan Paterson <paterson@dial.eunet.ch> wrote: >Here's one for the VMS gurus (I can't post it to comp.os.vms, >'cos there's a psychopath there who throws abuse at me): > >I want to examine all processes currently active. The system >service to do this is, of course, GetJPI (either in Starlet or >Lib). To perform wildcard process search, this procedure >expects to receive a value of -1 for the process_id parameter. >Unfortunately, in the "official" spec-files for these >procedures, this parameter has the type UNSIGNED_LONGWORD. Ada, >quite correctly, objects to this kind of thing :-) The best way of doing this is by calling process_scan (in Starlet or lib). I have once written a program that does all this and displays all kinds of process info (much better than show system). If you want it, send me e-mail and I'll give you the source. >So, what I now do is the following: > > PID : UNSIGNED_LONGWORD; > PID0 : INTEGER; > for PID0 use at PID'address; This is erroneous in Ada 83, and at least dangerous without a pragma Volatile or something. You should prefer Unchecked_Conversion, which will work when Standard.Integer becomes 64 bits. >begin > PID0 := -1; > loop > GetJPI(..., Process_Id => PID, ...); > >This works, but I can't help but wonder if there isn't a more >elegant way to do it. Does anyone have experience with this? Yes, there is: PID : UNSIGNED_LONGWORD := -1; begin PID := -1; loop GetJPI(..., Process_Id => PID, ...); works because System.UNSIGNED_LONGWORD is -2**31 .. 2**31 - 1. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-03 0:00 DECAda/VMS - calling GETJPI Alan Paterson 1996-06-03 0:00 ` Stuart Palin 1996-06-03 0:00 ` Mats Weber @ 1996-06-03 0:00 ` Ken Garlington 2 siblings, 0 replies; 24+ messages in thread From: Ken Garlington @ 1996-06-03 0:00 UTC (permalink / raw) Alan Paterson wrote: > > So, what I now do is the following: > > PID : UNSIGNED_LONGWORD; > PID0 : INTEGER; > for PID0 use at PID'address; > begin > PID0 := -1; > loop > GetJPI(..., Process_Id => PID, ...); > > This works, but I can't help but wonder if there isn't a more > elegant way to do it. Does anyone have experience with this? I tried this on DEC Ada V3.0A-9 on a VAXStation 4000 running VMS 5.5-2. I can assign -1 to objects of System.Unsigned_Longword just fine, so long as the "-" operator is visible (e.g., put in a "use System;"). For this version of DEC Ada, System.Unsigned_Longword is defined as range System.Min_Int .. System_Max_Int, with System.Min_Int = -(2**31). See the DEC Ada documentation, or read file ADA$PREDEFINED:SYSTEM_.ADC. If, on your version of DEC Ada, the range has been changed, try this: Minus_1 : constant System.Unsigned_Longword := System."not"(0); -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI @ 1996-06-06 0:00 George Haddad 1996-06-07 0:00 ` Robert Dewar 0 siblings, 1 reply; 24+ messages in thread From: George Haddad @ 1996-06-06 0:00 UTC (permalink / raw) Robert Dewar wrote: > Consider the following example: > type x is mod 10; > subtype y is x range 0 .. 5; [snip] > Actually to be strict, the constraint error is raised by the > conversion because -1 is not in the set of values for > modular type x (0 .. 10). At last! An opportunity to nitpick one of the comp.lang.ada greats. (Or embarrass myself horribly -- you be the judge. :-)) I would certainly hope that the allowable range of values for type x is 0..9. ;-) Otherwise, what about this: V1 : constant x := 0; V2 : constant x := 10; if (V1 = V2) then Text_IO.Put_Line("Zero equals Ten."); end if; -- I found these opinions on my doorstep, would you please give them a good home? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: DECAda/VMS - calling GETJPI 1996-06-06 0:00 George Haddad @ 1996-06-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1996-06-07 0:00 UTC (permalink / raw) George said " At last! An opportunity to nitpick one of the comp.lang.ada greats. (Or embarrass myself horribly -- you be the judge. :-)) I would certainly hope that the allowable range of values for type x is 0..9. ;-) Otherwise, what about this: V1 : constant x := 0; V2 : constant x := 10; if (V1 = V2) then Text_IO.Put_Line("Zero equals Ten."); end if;" A correct nitpick indeed :-) yes, of course I meant 0 .. 9 (to bad there is no way to compile and test english commentary containing odd bits of Ada :-) The code snippet above is statically illegal, because 10 is outside he base range (the type x is mod 10 in this example). P.S. sorry for missed characters and transposed characters in my posts, my keyboard is sticking and fighting, but I am finally getting it replaced next week, so that should help :-) ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~1996-06-11 0:00 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-06-03 0:00 DECAda/VMS - calling GETJPI Alan Paterson 1996-06-03 0:00 ` Stuart Palin 1996-06-03 0:00 ` Michael F Brenner 1996-06-03 0:00 ` Robert Dewar 1996-06-04 0:00 ` Michael F Brenner 1996-06-04 0:00 ` Robert Dewar 1996-06-04 0:00 ` Michael F Brenner 1996-06-04 0:00 ` Robert Dewar 1996-06-05 0:00 ` Robert A Duff 1996-06-05 0:00 ` Robert Dewar 1996-06-05 0:00 ` Fergus Henderson 1996-06-05 0:00 ` Robert A Duff 1996-06-05 0:00 ` Wraparound on modular conversion (was: DECAda/VMS - calling GETJPI) Tucker Taft 1996-06-05 0:00 ` Robert Dewar 1996-06-04 0:00 ` DECAda/VMS - calling GETJPI Robert Dewar 1996-06-05 0:00 ` Adam Beneschan 1996-06-07 0:00 ` Norman H. Cohen 1996-06-11 0:00 ` Adam Beneschan 1996-06-04 0:00 ` Ken Garlington 1996-06-06 0:00 ` Robert Dewar 1996-06-03 0:00 ` Mats Weber 1996-06-03 0:00 ` Ken Garlington -- strict thread matches above, loose matches on Subject: below -- 1996-06-06 0:00 George Haddad 1996-06-07 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox