* Another problem with stream reading. @ 2002-03-25 18:53 Erik Sigra 2002-03-25 19:01 ` Dan Andreatta 2002-03-26 17:54 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 16+ messages in thread From: Erik Sigra @ 2002-03-25 18:53 UTC (permalink / raw) Now I have the program with Ada; use Ada; with Text_IO; use Text_IO; with Ada.Streams; use Streams; with Ada.Streams.Stream_IO; use Stream_IO; procedure Streamtest is The_File : Stream_IO.File_Type; begin Open (The_File, In_File, "data"); declare The_Stream : Stream_Access := Stream (The_File); type Byte is range 0 .. 255; for Byte'Size use 8; B : Byte; begin while not End_Of_File (The_File) loop Byte'Read (The_Stream, B); Put_Line ("Read B = " & B'Img); end loop; end; end Streamtest; The data file contains "����" (hexadecimal "ff fe fd fc") (decimal "255 254 253 252). The output of the program is: Read B = 255 Read B = 253 The problem is that it reads 2 bytes instead of 1 and thus skips each second byte. Why? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-25 18:53 Another problem with stream reading Erik Sigra @ 2002-03-25 19:01 ` Dan Andreatta 2002-03-25 19:14 ` Erik Sigra 2002-03-26 17:54 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 16+ messages in thread From: Dan Andreatta @ 2002-03-25 19:01 UTC (permalink / raw) Erik Sigra <sigra@home.se> wrote in news:mailman.1017082205.9199.comp.lang.ada@ada.eu.org: > procedure Streamtest is > The_File : Stream_IO.File_Type; > begin > Open (The_File, In_File, "data"); > declare > The_Stream : Stream_Access := Stream (The_File); > type Byte is range 0 .. 255; > for Byte'Size use 8; > B : Byte; > begin > while not End_Of_File (The_File) loop > Byte'Read (The_Stream, B); > Put_Line ("Read B = " & B'Img); > end loop; > end; > end Streamtest; Don't know exactly why, but is you modify: type Byte is mod 256; it works properly. Dan ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-25 19:01 ` Dan Andreatta @ 2002-03-25 19:14 ` Erik Sigra 2002-03-25 22:20 ` Jeffrey Carter 2002-03-25 22:28 ` Stephen Leake 0 siblings, 2 replies; 16+ messages in thread From: Erik Sigra @ 2002-03-25 19:14 UTC (permalink / raw) m�ndagen den 25 mars 2002 20.01 skrev du: > Erik Sigra <sigra@home.se> wrote in > > news:mailman.1017082205.9199.comp.lang.ada@ada.eu.org: > > procedure Streamtest is > > The_File : Stream_IO.File_Type; > > begin > > Open (The_File, In_File, "data"); > > declare > > The_Stream : Stream_Access := Stream (The_File); > > type Byte is range 0 .. 255; > > for Byte'Size use 8; > > B : Byte; > > begin > > while not End_Of_File (The_File) loop > > Byte'Read (The_Stream, B); > > Put_Line ("Read B = " & B'Img); > > end loop; > > end; > > end Streamtest; > > Don't know exactly why, but is you modify: > > type Byte is mod 256; > > it works properly. Yes it works here to, thanks! Does anyone know what causes this behaviour? Is it specified or should I report it to the compiler maker? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-25 19:14 ` Erik Sigra @ 2002-03-25 22:20 ` Jeffrey Carter 2002-03-25 22:28 ` Stephen Leake 1 sibling, 0 replies; 16+ messages in thread From: Jeffrey Carter @ 2002-03-25 22:20 UTC (permalink / raw) Erik Sigra wrote: > > m�ndagen den 25 mars 2002 20.01 skrev du: > > Erik Sigra <sigra@home.se> wrote in > > > > news:mailman.1017082205.9199.comp.lang.ada@ada.eu.org: > > > procedure Streamtest is > > > The_File : Stream_IO.File_Type; > > > begin > > > Open (The_File, In_File, "data"); > > > declare > > > The_Stream : Stream_Access := Stream (The_File); > > > type Byte is range 0 .. 255; > > > for Byte'Size use 8; > > > B : Byte; > > > begin > > > while not End_Of_File (The_File) loop > > > Byte'Read (The_Stream, B); > > > Put_Line ("Read B = " & B'Img); > > > end loop; > > > end; > > > end Streamtest; > > > > Don't know exactly why, but is you modify: > > > > type Byte is mod 256; > > > > it works properly. > > Yes it works here to, thanks! > > Does anyone know what causes this behaviour? Is it specified or should I > report it to the compiler maker? Probably because "range 0 .. 255" gives Byte'Base'Size of 16 and you're running it on a little-endian machine, while "mod 2 ** 8" gives Byte'Base'Size of 8; -- Jeffrey Carter ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-25 19:14 ` Erik Sigra 2002-03-25 22:20 ` Jeffrey Carter @ 2002-03-25 22:28 ` Stephen Leake 1 sibling, 0 replies; 16+ messages in thread From: Stephen Leake @ 2002-03-25 22:28 UTC (permalink / raw) Erik Sigra <sigra@home.se> writes: > m�ndagen den 25 mars 2002 20.01 skrev du: > > Erik Sigra <sigra@home.se> wrote in > > > > news:mailman.1017082205.9199.comp.lang.ada@ada.eu.org: > > > procedure Streamtest is > > > The_File : Stream_IO.File_Type; > > > begin > > > Open (The_File, In_File, "data"); > > > declare > > > The_Stream : Stream_Access := Stream (The_File); > > > type Byte is range 0 .. 255; > > > for Byte'Size use 8; > > > B : Byte; > > > begin > > > while not End_Of_File (The_File) loop > > > Byte'Read (The_Stream, B); > > > Put_Line ("Read B = " & B'Img); > > > end loop; > > > end; > > > end Streamtest; > > > > Don't know exactly why, but is you modify: > > > > type Byte is mod 256; > > > > it works properly. > > Yes it works here to, thanks! > > Does anyone know what causes this behaviour? Is it specified or should I > report it to the compiler maker? Stream_IO must read and write the base type of the object. For "type Byte is range 0 .. 255", the base type is a signed integer, so it takes 16 bits. for "type Byte is mod 256", the base type is 8 bits. To see why Stream_IO must read and write the base type, consider: declare A : Byte'base; begin Byte'Write (The_Stream, A); end; It gets worse; some compilers choose a 16 bit base type for "type Signed_Byte is -128 .. 127;", and they are compliant with the Ada standard. So basically, Stream_IO is _not_ guaranteed to be compatible between compilers. -- -- Stephe ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-25 18:53 Another problem with stream reading Erik Sigra 2002-03-25 19:01 ` Dan Andreatta @ 2002-03-26 17:54 ` Warren W. Gay VE3WWG 2002-03-27 15:53 ` Erik Sigra 1 sibling, 1 reply; 16+ messages in thread From: Warren W. Gay VE3WWG @ 2002-03-26 17:54 UTC (permalink / raw) Just shooting from the hip here, I think the problem is that you gave the compiler an impossible assignment. By that, I mean that you've declared type Byte to have integer range 0..255 and at the same time said its size has to be 8 bits. There is no room for that range and a sign bit (since it is integer here) to exist in 8 bits (you need 9). As a result of lying to HAL, HAL decided to disregard your statement "for Byte'Size use 8" and used 16 instead. If you want signed numbers, you need to fix the range. If you want unsigned numbers, then you need a modulo type. Erik Sigra wrote: > Now I have the program > > with Ada; use Ada; > with Text_IO; use Text_IO; > with Ada.Streams; use Streams; > with Ada.Streams.Stream_IO; use Stream_IO; > > procedure Streamtest is > The_File : Stream_IO.File_Type; > begin > Open (The_File, In_File, "data"); > declare > The_Stream : Stream_Access := Stream (The_File); > type Byte is range 0 .. 255; > for Byte'Size use 8; > B : Byte; > begin > while not End_Of_File (The_File) loop > Byte'Read (The_Stream, B); > Put_Line ("Read B = " & B'Img); > end loop; > end; > end Streamtest; > > > The data file contains > "����" (hexadecimal "ff fe fd fc") (decimal "255 254 253 252). The output of > the program is: > Read B = 255 > Read B = 253 > > > The problem is that it reads 2 bytes instead of 1 and thus skips each second > byte. Why? > -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-26 17:54 ` Warren W. Gay VE3WWG @ 2002-03-27 15:53 ` Erik Sigra 2002-03-27 21:22 ` Warren W. Gay VE3WWG ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Erik Sigra @ 2002-03-27 15:53 UTC (permalink / raw) tisdagen den 26 mars 2002 18.54 skrev du: > Just shooting from the hip here, I think the problem is that > you gave the compiler an impossible assignment. By that, I > mean that you've declared type Byte to have integer range > 0..255 and at the same time said its size has to be 8 bits. > There is no room for that range and a sign bit (since it is > integer here) to exist in 8 bits (you need 9). As a result > of lying to HAL, HAL decided to disregard your statement > "for Byte'Size use 8" and used 16 instead. If you look carefully at my code you can se that i did NOT write "Integer range", just "range". And there is certainly no need for a sign bit for the range 0 .. 255. If I lie to the compiler, it does certainly not disregard it. It complais loudly. If I for example say "for Byte'Size use 7;", it replies "size for "Byte" too small, minimum allowed is 8" > If you want signed numbers, you need to fix the range. If > you want unsigned numbers, then you need a modulo type. I should not need a modulo type for unsigned numbers. See "Programming in Ada 95" by John Barnes, 2nd edition, page 552: " For example we can specify the amount of storage to be allocated for objects of a type, for the storage pool of an access type and for the working storage of a task type. This is done by an attribute definition clause. Thus type Byte is range 0 .. 255; for Byte'Size use 8; indicates that objects of type Byte should occupy only 8 bits. The size of individual objects can also be specified." > Erik Sigra wrote: > > Now I have the program > > > > with Ada; use Ada; > > with Text_IO; use Text_IO; > > with Ada.Streams; use Streams; > > with Ada.Streams.Stream_IO; use Stream_IO; > > > > procedure Streamtest is > > The_File : Stream_IO.File_Type; > > begin > > Open (The_File, In_File, "data"); > > declare > > The_Stream : Stream_Access := Stream (The_File); > > type Byte is range 0 .. 255; > > for Byte'Size use 8; > > B : Byte; > > begin > > while not End_Of_File (The_File) loop > > Byte'Read (The_Stream, B); > > Put_Line ("Read B = " & B'Img); > > end loop; > > end; > > end Streamtest; > > > > > > The data file contains > > "����" (hexadecimal "ff fe fd fc") (decimal "255 254 253 252). The output > > of the program is: > > Read B = 255 > > Read B = 253 > > > > > > The problem is that it reads 2 bytes instead of 1 and thus skips each > > second byte. Why? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-27 15:53 ` Erik Sigra @ 2002-03-27 21:22 ` Warren W. Gay VE3WWG 2002-03-27 22:50 ` Dan Andreatta 2002-03-27 23:55 ` Randy Brukardt 2 siblings, 0 replies; 16+ messages in thread From: Warren W. Gay VE3WWG @ 2002-03-27 21:22 UTC (permalink / raw) Erik Sigra wrote: > tisdagen den 26 mars 2002 18.54 skrev du: > >>Just shooting from the hip here, I think the problem is that >>you gave the compiler an impossible assignment. By that, I >>mean that you've declared type Byte to have integer range >>0..255 and at the same time said its size has to be 8 bits. >>There is no room for that range and a sign bit (since it is >>integer here) to exist in 8 bits (you need 9). As a result >>of lying to HAL, HAL decided to disregard your statement >>"for Byte'Size use 8" and used 16 instead. >> > > If you look carefully at my code you can se that i did NOT write "Integer > range", just "range". And there is certainly no need for a sign bit for the > range 0 .. 255. If I lie to the compiler, it does certainly not disregard it. > It complais loudly. If I for example say "for Byte'Size use 7;", it replies > "size for "Byte" too small, minimum allowed is 8" Well, I did say that I was "shooting from the hip". I guess I missed this time :-P -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-27 15:53 ` Erik Sigra 2002-03-27 21:22 ` Warren W. Gay VE3WWG @ 2002-03-27 22:50 ` Dan Andreatta 2002-03-27 23:55 ` Randy Brukardt 2 siblings, 0 replies; 16+ messages in thread From: Dan Andreatta @ 2002-03-27 22:50 UTC (permalink / raw) Erik Sigra <sigra@home.se> wrote in news:mailman.1017244142.7106.comp.lang.ada@ada.eu.org: > tisdagen den 26 mars 2002 18.54 skrev du: >> Just shooting from the hip here, I think the problem is that >> you gave the compiler an impossible assignment. By that, I >> mean that you've declared type Byte to have integer range >> 0..255 and at the same time said its size has to be 8 bits. >> There is no room for that range and a sign bit (since it is >> integer here) to exist in 8 bits (you need 9). As a result >> of lying to HAL, HAL decided to disregard your statement "for >> Byte'Size use 8" and used 16 instead. > > If you look carefully at my code you can se that i did NOT write > "Integer range", just "range". And there is certainly no need for a > sign bit for the range 0 .. 255. If I lie to the compiler, it does > certainly not disregard it. It complais loudly. If I for example say > "for Byte'Size use 7;", it replies "size for "Byte" too small, minimum > allowed is 8" > You are right. If you try with Sequential_IO, everything works perfectly. I don't know why, but the size of the base type for your definition of byte is 16. I did some tests too, and I found: type Byte is range 0..255 'Size => 8 'Base'Size => 16 type Byte is range -128..127 'Size => 8 'Base'Size => 8 type Byte is mod 256 'Size => 8 'Base'Size => 8 (all with "for Byte'Size use 8 ;" ) Why this happen? I don't know! Dan ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-27 15:53 ` Erik Sigra 2002-03-27 21:22 ` Warren W. Gay VE3WWG 2002-03-27 22:50 ` Dan Andreatta @ 2002-03-27 23:55 ` Randy Brukardt 2002-03-28 0:18 ` David Bolen ` (2 more replies) 2 siblings, 3 replies; 16+ messages in thread From: Randy Brukardt @ 2002-03-27 23:55 UTC (permalink / raw) Erik Sigra wrote in message ... >If you look carefully at my code you can se that i did NOT write "Integer >range", just "range". And there is certainly no need for a sign bit for the >range 0 .. 255. If I lie to the compiler, it does certainly not disregard it. >It complais loudly. If I for example say "for Byte'Size use 7;", it replies >"size for "Byte" too small, minimum allowed is 8" That's the form of a declaration for a signed integer type. And negative values must be provided for the base type, read the RM! http://www.adaic.org/standards/95lrm/html/RM-3-5-4.html, paragraph 9. > I should not need a modulo type for unsigned numbers. You (usually) don't. But streams always read and write the base type, and that is always signed unless use use a modular type. And your original question was about the behavior of streams. It would be nice if Ada had real unsigned types with checking, etc., but I brought that up repeatedly during the design of Ada 95, and there was no support. And that has not changed, so don't expect it to change in Ada 0y. So we have only modular types if we really need unsigned behavior. Janus/Ada, at least, will generate code for your type byte as if it is unsigned (that has necessary for Ada 83, which had no unsigned types at all), with all of the checking. But where the language requires the base type (such as in streams), we have to use signed 16-bits. The place this matters, of course, is for the largest unsigned type. If you declare type Unsigned is range 0 .. (2**32)-1; in Janus/Ada for Windows, you'll get an error, because there is no signed base type large enough to fit it. That's unfortunate, given that the code generator is able to generate the operations, but that is the price of having a good language standard. (We could have, and probably should have, implemented a pragma to let the compiler ignore the language rules here -- that is explicitly allowed by the standard - see "non-standard integer types" (paragraph 26 in the same RM section referenced above) -- but we never had a business reason for doing so. Besides, I hate pragmas. :-) Randy Brukardt. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-27 23:55 ` Randy Brukardt @ 2002-03-28 0:18 ` David Bolen 2002-03-28 22:30 ` Randy Brukardt 2002-03-28 0:33 ` tmoran 2002-03-28 15:21 ` Marin David Condic 2 siblings, 1 reply; 16+ messages in thread From: David Bolen @ 2002-03-28 0:18 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Janus/Ada, at least, will generate code for your type byte as if it is > unsigned (that has necessary for Ada 83, which had no unsigned types at > all), with all of the checking. But where the language requires the base > type (such as in streams), we have to use signed 16-bits. > > The place this matters, of course, is for the largest unsigned type. If > you declare > type Unsigned is range 0 .. (2**32)-1; > in Janus/Ada for Windows, you'll get an error, because there is no > signed base type large enough to fit it. How would you typically work around this, if you really wanted to be working with 32-bit unsigned quantities in your code? If there's no signed base type large enough (sans 64-bit support presumably) would you have to implement your own set of operations on, say, a data type made out of two 16-bit values? -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-28 0:18 ` David Bolen @ 2002-03-28 22:30 ` Randy Brukardt 0 siblings, 0 replies; 16+ messages in thread From: Randy Brukardt @ 2002-03-28 22:30 UTC (permalink / raw) David Bolen wrote in message ... >"Randy Brukardt" <randy@rrsoftware.com> writes: > >> Janus/Ada, at least, will generate code for your type byte as if it is >> unsigned (that has necessary for Ada 83, which had no unsigned types at >> all), with all of the checking. But where the language requires the base >> type (such as in streams), we have to use signed 16-bits. >> >> The place this matters, of course, is for the largest unsigned type. If >> you declare >> type Unsigned is range 0 .. (2**32)-1; >> in Janus/Ada for Windows, you'll get an error, because there is no >> signed base type large enough to fit it. > >How would you typically work around this, if you really wanted to be >working with 32-bit unsigned quantities in your code? If there's no >signed base type large enough (sans 64-bit support presumably) would >you have to implement your own set of operations on, say, a data type >made out of two 16-bit values? Portably, I think you'd have to do something like that. Another option would be to use a 32-bit modular type, and do overflow checking explicitly. For instance, for "+", if the result is smaller than either of the operands, you've overflowed. Doing that for "*" is unpleasant (you pretty much have to emulate the multiply), but its easy for all of the other operations. It would be easy to define a package like that (that is essentially how the Janus/Ada compiler handles value for code generation purposes). A pragma or something to get to the code generator's DW type would probably be the best solution for Janus/Ada, since that would use the processor's carry flag to do the overflow check. But of course that wouldn't be portable. Randy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-27 23:55 ` Randy Brukardt 2002-03-28 0:18 ` David Bolen @ 2002-03-28 0:33 ` tmoran 2002-03-28 15:21 ` Marin David Condic 2 siblings, 0 replies; 16+ messages in thread From: tmoran @ 2002-03-28 0:33 UTC (permalink / raw) > But streams always read and write the base type, Default streams. If you write your own you can do whatever you please. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-27 23:55 ` Randy Brukardt 2002-03-28 0:18 ` David Bolen 2002-03-28 0:33 ` tmoran @ 2002-03-28 15:21 ` Marin David Condic 2002-03-29 11:30 ` Larry Kilgallen 2 siblings, 1 reply; 16+ messages in thread From: Marin David Condic @ 2002-03-28 15:21 UTC (permalink / raw) Unsigned integers for Ada0y might be interesting, but I'm not sure what you would do with them that you can't already do with modular types. If you need a 32 bit unsigned that doesn't have the base type problem, you can get that with a modular type. Is it that one might want overflow & underflow rather than wraparound semantics? If that's the case, I'd think it would be nice to have numeric types that saturate as well. One of Ada's strengths is that it can describe in detail the exact needs of a given data type. Perhaps adding unsigned integers (and math types that saturate) would add to that strength. Arguing that you can get there from here by just doing blah blah blah is interesting, but not necessarily compelling. Its always nice to have direct language support for a feature that is likely to see a lot of use. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:ua4mt7p1nif778@corp.supernews.com... > > It would be nice if Ada had real unsigned types with checking, etc., but > I brought that up repeatedly during the design of Ada 95, and there was > no support. And that has not changed, so don't expect it to change in > Ada 0y. So we have only modular types if we really need unsigned > behavior. > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-28 15:21 ` Marin David Condic @ 2002-03-29 11:30 ` Larry Kilgallen 2002-03-29 14:33 ` Marin David Condic 0 siblings, 1 reply; 16+ messages in thread From: Larry Kilgallen @ 2002-03-29 11:30 UTC (permalink / raw) In article <a7vceg$lto$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > Unsigned integers for Ada0y might be interesting, but I'm not sure what you > would do with them that you can't already do with modular types. If you need > a 32 bit unsigned that doesn't have the base type problem, you can get that > with a modular type. Is it that one might want overflow & underflow rather > than wraparound semantics? If that's the case, I'd think it would be nice to > have numeric types that saturate as well. > > One of Ada's strengths is that it can describe in detail the exact needs of > a given data type. Perhaps adding unsigned integers (and math types that > saturate) would add to that strength. Arguing that you can get there from > here by just doing blah blah blah is interesting, but not necessarily > compelling. Its always nice to have direct language support for a feature > that is likely to see a lot of use. What would be compelling is real-world of experience of how useful the blah blah blah version has been, or the experimental version of GNAT. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another problem with stream reading. 2002-03-29 11:30 ` Larry Kilgallen @ 2002-03-29 14:33 ` Marin David Condic 0 siblings, 0 replies; 16+ messages in thread From: Marin David Condic @ 2002-03-29 14:33 UTC (permalink / raw) True. From experience with blah blah blah versions of saturated math, I *know* this is useful in real world applications. However, I don't know how *generally* useful it might be - just useful within certain problem domains. (It has applications wherever you have some object with known limits that cannot be exceeded - such as an actuator that has a fixed range of motion or a graphics screen that has some fixed boundaries. Elsewhere? Only experience could tell...) The problem with things like saturated math or unsigned integers is that without direct support in the compiler, your garden variety cobbled together solution starts having some serious performance penalties. Not necessarily a big deal in workstation apps, but usually a big deal for the folks that need it the most. A modified version of GNAT? That's always a possibility that could prove interesting - but who would do it? ACT won't unless one or more of their customers starts asking for it and I certainly don't have the time (or commercial need, at the moment) to go figure out how to do it myself. Maybe there's enough GNAT users out there interested in it, but unless they develop a group consensus on it, it isn't likely to make it into the compiler. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:BM$h1dY1PyDK@eisner.encompasserve.org... > > What would be compelling is real-world of experience of how useful the > blah blah blah version has been, or the experimental version of GNAT. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2002-03-29 14:33 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-03-25 18:53 Another problem with stream reading Erik Sigra 2002-03-25 19:01 ` Dan Andreatta 2002-03-25 19:14 ` Erik Sigra 2002-03-25 22:20 ` Jeffrey Carter 2002-03-25 22:28 ` Stephen Leake 2002-03-26 17:54 ` Warren W. Gay VE3WWG 2002-03-27 15:53 ` Erik Sigra 2002-03-27 21:22 ` Warren W. Gay VE3WWG 2002-03-27 22:50 ` Dan Andreatta 2002-03-27 23:55 ` Randy Brukardt 2002-03-28 0:18 ` David Bolen 2002-03-28 22:30 ` Randy Brukardt 2002-03-28 0:33 ` tmoran 2002-03-28 15:21 ` Marin David Condic 2002-03-29 11:30 ` Larry Kilgallen 2002-03-29 14:33 ` Marin David Condic
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox