GNAT Stream Read processing problem

GNAT Stream Read processing problem

[Bruce Detter]

I am using GNAT 3.10p on NT4.0.  I have the following code written to read a
binary file:

   type Position is
      record
         x, y: Float;
      end record;

   type PositionArray is array (1 .. 5000) of Position;

   type Data_Points is
      record
         elements: Long_Integer;
         PS: PositionArray;
      end record;

   type DataArray is array (1 .. 256) of Data_Points;

   Data: DataArray;
   ndx: Long_Integer := 0;

   procedure LoadData is
      Dat: File_Type;
      S: Stream_Access;
      i: Long_Integer;
   begin
      Open(Dat, In_File, "Data.bin");
      S := Stream(Dat);
      while not End_Of_File(Dat) loop
         Long_Integer'Read(S, Data(ndx).elements);
         for i in 1 .. Data(ndx).elements loop
            Float'Read(S, Data(ndx).PS(i).x);
            Float'Read(S, Data(ndx).PS(i).y);
         end loop;
         ndx := ndx + 1;
      end loop;
      Close(Map);
   end LoadData;


When I compile this no matter what type is specified for the Read attribute
and the data element to be read into, I get the following errors three
times:
... expected type "Standard.Integer"
... found type "Standard.Long_Integer"

and it points me to the second parameter of each 'Read.  Can someone suggest
what it is I'm doing wrong.

Thanks in advance...
BCD3

Re: GNAT Stream Read processing problem

[Tom Moran]

>... expected type "Standard.Integer"
>... found type "Standard.Long_Integer"

>and it points me to the second parameter of each 'Read.  Can someone suggest
>what it is I'm doing wrong.
Yes.   You are using a Long_Integer, i,  to index PS, which, takes a
Standard_Integer as an index.
  Note that "for i in" has 'i' take its type from its range, which is
"1 .. Data(ndx).elements" and " elements: Long_Integer;" so i is a
Long_Integer.  Note also that PS is a  "type PositionArray is array (1
.. 5000)" and, since it doesn't say otherwise for the range, 1 .. 5000
is taken to mean "Standard_Integer range 1 .. 5000" so PS takes a
Standard_Integer as an index.
  You can either decide that Position_Array should be indexed by
Long_Integer, or you can use "Integer(i)" as a subscript to convert
the long i to a regular integer.  (With the obvious possibility of an
out of range value, either in converting i to a Standard_Integer, or
in trying to use a Standard_Integer outside the 1 .. 5000 range).

Re: GNAT Stream Read processing problem

[Bruce Detter]

Thanks Tom,
That did the trick.  It just didn't occur to me that I was dealing with an
Indexing problem.  So much to learn, so little time...

Thanks again...
BCD3

Tom Moran wrote in message <36928385.8520314@news.pacbell.net>...
>>... expected type "Standard.Integer"
>>... found type "Standard.Long_Integer"
>
>>and it points me to the second parameter of each 'Read.  Can someone
suggest
>>what it is I'm doing wrong.
>Yes.   You are using a Long_Integer, i,  to index PS, which, takes a
>Standard_Integer as an index.
>  Note that "for i in" has 'i' take its type from its range, which is
>"1 .. Data(ndx).elements" and " elements: Long_Integer;" so i is a
>Long_Integer.  Note also that PS is a  "type PositionArray is array (1
>.. 5000)" and, since it doesn't say otherwise for the range, 1 .. 5000
>is taken to mean "Standard_Integer range 1 .. 5000" so PS takes a
>Standard_Integer as an index.
>  You can either decide that Position_Array should be indexed by
>Long_Integer, or you can use "Integer(i)" as a subscript to convert
>the long i to a regular integer.  (With the obvious possibility of an
>out of range value, either in converting i to a Standard_Integer, or
>in trying to use a Standard_Integer outside the 1 .. 5000 range).

Re: GNAT Stream Read processing problem

[dewar]

In article <76tsgd$s0o1@svlss.lmms.lmco.com>,
  "Bruce Detter" <bruce.detter@lmco.com> wrote:

> When I compile this no matter what type is specified for
> the Read attribute and the data element to be read into,
> I get the following errors three times:

> ... expected type "Standard.Integer"
> ... found type "Standard.Long_Integer"
>
> and it points me to the second parameter of each 'Read.
> Can someone suggest what it is I'm doing wrong.

Surely if you use -gnatv to point out the EXACT location of
the error:

    30.          Long_Integer'Read(S, Data(ndx).elements);
                                           |
        >>> expected type "Standard.integer"
        >>> found type "Standard.long_integer"

that should be enough of a clue, it is VERY specifically
telling you that the subscript of Data must be of type
Standard.integer, and you are using long_integer.

While you are learning Ada 95, use -gnatv as a matter of
course to tell exactly where the error message is being
posted. GNAT goes to great pains to try to post the error
in exactly the most helpful place, take advantage of this!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: GNAT Stream Read processing problem

[Matthew Heaney]

dewar@gnat.com writes:

> Surely if you use -gnatv to point out the EXACT location of
> the error:
> 
>     30.          Long_Integer'Read(S, Data(ndx).elements);
>                                            |
>         >>> expected type "Standard.integer"
>         >>> found type "Standard.long_integer"
> 
> that should be enough of a clue, it is VERY specifically
> telling you that the subscript of Data must be of type
> Standard.integer, and you are using long_integer.
> 
> While you are learning Ada 95, use -gnatv as a matter of
> course to tell exactly where the error message is being
> posted. GNAT goes to great pains to try to post the error
> in exactly the most helpful place, take advantage of this!


If you use emacs with gnat, then C-x ` (the command "next-error") will
take you to the exact line and column containing the error.

Emacs is not just an editor, it's a way of life.  Ya know?

Elaborate compile-time error messages (was: GNAT Stream Read ...)

[Larry Kilgallen]

In article <76uv4j$njr$1@nnrp1.dejanews.com>, dewar@gnat.com writes:

> Surely if you use -gnatv to point out the EXACT location of
> the error:
> 
>     30.          Long_Integer'Read(S, Data(ndx).elements);
>                                            |
>         >>> expected type "Standard.integer"
>         >>> found type "Standard.long_integer"
> 
> that should be enough of a clue, it is VERY specifically
> telling you that the subscript of Data must be of type
> Standard.integer, and you are using long_integer.
> 
> While you are learning Ada 95, use -gnatv as a matter of
> course to tell exactly where the error message is being
> posted. GNAT goes to great pains to try to post the error
> in exactly the most helpful place, take advantage of this!

That certainly is a high quality error message.  I am curious as to
why it is not the default.  Is there some set of programmers who get
really mad at having the compiler be smarter than they are about the
nature of a problem.

I first used Ada with DEC Ada, where the error messages are also
quite complete, and it has never occurred to me to look for a way
to make them shorter.

Larry Kilgallen

Re: Elaborate compile-time error messages (was: GNAT Stream Read ...)

[bourguet]

In article <1999Jan6.072356.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> In article <76uv4j$njr$1@nnrp1.dejanews.com>, dewar@gnat.com writes:
>
> > Surely if you use -gnatv to point out the EXACT location of
> > the error:
> >
> >     30.          Long_Integer'Read(S, Data(ndx).elements);
> >                                            |
> >         >>> expected type "Standard.integer"
> >         >>> found type "Standard.long_integer"
> >
> > that should be enough of a clue, it is VERY specifically
> > telling you that the subscript of Data must be of type
> > Standard.integer, and you are using long_integer.
> >
> > While you are learning Ada 95, use -gnatv as a matter of
> > course to tell exactly where the error message is being
> > posted. GNAT goes to great pains to try to post the error
> > in exactly the most helpful place, take advantage of this!
>
> That certainly is a high quality error message.  I am curious as to
> why it is not the default.  Is there some set of programmers who get
> really mad at having the compiler be smarter than they are about the
> nature of a problem.

AFAIK, the only thing that -gnatv change is the way the error position
is referenced (and Robert message does not let me think otherwise).
Without -gnatv, gnat issue an error message with the position given as
filename:linenum:colnum.
With -gnatv gnat issue the same message but with the position given by a
two line listing and a | pointing to the character.

Why is it not the default? I do not know for sure: the default is more
dense and correspond to the coding standard of the FSF (other compilers
based on gcc issue the same kind of messages, emacs is able to parse
these error messages and use them to point you directly on the problem).
When I do not compile under emacs I usually use the -gnatv (or even
recompile under emacs when I see a problem :-).

> I first used Ada with DEC Ada, where the error messages are also
> quite complete, and it has never occurred to me to look for a way
> to make them shorter.

The error messages from gnat are the best I've ever seen in a compiler.
I'd like the c++ compiler I use at work issue half as good error messages
(it issue routinely when there is a problem in template instanciation the
worst error message I've ever seen: a crash preceded by a totaly irrelevant
message applyed to a random line number).

-- Jean-Marc

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Elaborate compile-time error messages (was: GNAT Stream Read ...)

[Marin David Condic]

Larry Kilgallen wrote:
> 
> 
> That certainly is a high quality error message.  I am curious as to
> why it is not the default.  Is there some set of programmers who get
> really mad at having the compiler be smarter than they are about the
> nature of a problem.

Just a guess, but have you noticed how one error early on in a
compilation can have the bad effect of cascading down, generating
hundreds of other messages? If the error messages are in full detail,
this gets crowded quickly and might make it harder to find the original
problem.

> 
> I first used Ada with DEC Ada, where the error messages are also
> quite complete, and it has never occurred to me to look for a way
> to make them shorter.
> 
I've always had a good deal of respect for the quality of the DEC
compilers. (any language) They generate decent code, are well documented
with lots of detail down to the bits&bytes level and generally provide
good diagnostics. DEC seems to be out of the Ada compiler business, but
I think other vendors could look at what they did and learn a lot from
it. They may not have provided some spiffy graphic development
environment, but they always gave me what mattered most: simple,
reliable operation, quality code generation and really good
documentation so I knew how to get the compiler to do what I wanted it
to do.

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Eagles may soar, but a weasle never gets sucked up into a jet engine."

        --  Author Unknown

Re: Elaborate compile-time error messages (was: GNAT Stream Read ...)

[Georg Bauhaus]

Marin David Condic (condicma@bogon.pwfl.com) wrote:
: Larry Kilgallen wrote:

: > Is there some set of programmers who get
: > really mad at having the compiler be smarter
: > than they are about the nature of a problem.

(Two questions below.)

Given two source files, both plain wrong (a.k.a. nonsense),
admittedly, and differing only in the spelling of one
character, namely the P in these two lines:

<   N : Integer := Private;  -- capital "P" (yes, wrong anyway)
>   N : Integer := private;  -- small "p" (yes, wrong anyway)

----------------
package Emsg is -- not: emsg! (small "e")
   N : Integer := Private;  -- capital "P" (yes, wrong anyway)
end Emsg;
----------------

gnatf -v -ds emsg.ads

GNATF 3.09 (970121) Copyright 1991-1996 Free Software Foundation, Inc.

Checking: emsg.ads (source file time stamp: 1998-12-29 02:42:43)
Source recreated from tree for Emsg (spec)
------------------------------------------


package emsg is
   n : integer := private;
end emsg;


     2.    N : Integer := Private;  -- "P" (yes, wrong anyway)
                          |
        >>> reserved word "private" cannot be used as identifier

 3 lines: 1 error

Compilation exited abnormally with code 1 at Tue Dec 29 03:42:43

To me, this error message is quite satisfactory.  Then

----------------
package Emsg is -- not: emsg! (small "e")
   N : Integer := private;  -- small "p" (yes, wrong anyway)
end Emsg;
----------------

gnatf -v -ds emsg.ads

GNATF 3.09 (970121) Copyright 1991-1996 Free Software Foundation, Inc.

Checking: emsg.ads (source file time stamp: 1998-12-29 02:30:36)
Source recreated from tree for Emsg (spec)
------------------------------------------


package emsg is
   n : integer := <error>;
end emsg;


     2.    N : Integer := private;  -- "P" (yes, wrong anyway)
                         |
        >>> missing operand

 3 lines: 1 error

Compilation exited abnormally with code 1 at Tue Dec 29 03:30:38

So, this time I understand that ":=" is missing an operand.
(right?) I explained to myself that these two very different
error messages might be the result of GNAT checking style.
Is this true?

QUESTION 1:
Why does GNAT behave so very differently when things
are spelled differently? (Try compiling with "emsg"
replacing "Emsg" in the above examples.)

I came across this when brooding over an error message that
informed me of a missing operand and an "is" that should be
":=", which felt right (
   N : Integer is private;
   -- operand missing between "Integer" and "is",
   -- then "is" should be ":=".
Is "is" an operator?  GNAT 1.83 just wants a ";" there.).
But, not knowing  how a compiler works internally and the
formal aspects of languages in general, I was wondering where
the operator was. "is"? So, here is my second question:

QUESTION 2:
Is there a chance that someday GNAT will tell me *which*
operator is missing what? (Or have I overlooked something?)
More generally: Is there a way to have GNAT shout *why* it
was expecting something?

(Let me note (1) that it's still a pleasure working with GNAT
while thinking of C/Perl and what the compilers say when you
forgot to place a ';' somewhere. And (2), I see that I
had better know how compilation is done in order to understand
error messages, much like if I'm driving a car through the
desert and know something about motors and brakes.
But then, some people just want to ride somewhere...)

with best regards,
  Georg

Re: Elaborate compile-time error messages (was: GNAT Stream Read ...)

[Simon Wright]

sb463ba@d250-hrz.uni-duisburg.de (Georg Bauhaus) writes:

> QUESTION 1:
> Why does GNAT behave so very differently when things
> are spelled differently? (Try compiling with "emsg"
> replacing "Emsg" in the above examples.)

I don't know when 3.11p is coming out, but 3.10p handles these cases
identically:

    pogner[17]$ gcc -c -gnatc -gnatv emsg.ads

    GNAT 3.10p (970814) Copyright 1992-1997 Free Software Foundation, Inc.

    Checking: emsg.ads (source file time stamp: 1999-01-13 06:45:32)

         2.    n : integer := Private;
                              |
            >>> reserved word "private" cannot be used as identifier

     3 lines: 1 error

and

    pogner[19]$ gcc -c -gnatc -gnatv emsg.ads

    GNAT 3.10p (970814) Copyright 1992-1997 Free Software Foundation, Inc.

    Checking: emsg.ads (source file time stamp: 1999-01-13 06:48:50)

         2.    n : integer := private;
                              |
            >>> reserved word "private" cannot be used as identifier

     3 lines: 1 error

also

    pogner[20]$ gnatf -v -ds emsg.ads

    GNATF 3.10p (970814) Copyright 1992-1997 Free Software Foundation, Inc.

    Checking: emsg.ads (source file time stamp: 1999-01-13 06:48:50)
    Source recreated from tree for emsg (spec)
    ------------------------------------------


    package emsg is
       n : integer := private;
    end emsg;


         2.    n : integer := private;
                              |
            >>> reserved word "private" cannot be used as identifier

     3 lines: 1 error

Re: Elaborate compile-time error messages (was: GNAT Stream Read ...)

[dewar]

In article <1999Jan6.072356.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> In article <76uv4j$njr$1@nnrp1.dejanews.com>,
dewar@gnat.com writes:
>
> That certainly is a high quality error message.  I am
> curious as to why it is not the default.  Is there some
> set of programmers who get really mad at having the
> compiler be smarter than they are about the
> nature of a problem.

First, to be clear, the *error messages* are exactly the
same in default mode, and the error messages give column
numbers. The difference is in printing out the source line,
and flagging the column of the error. Most programmers do
NOT want this as the default, and note in particular that
when you are using an editor that is integrated with the
compiler, e.g. EMACS, the verbosity of -gnatv just gets in
the way and is unhelpful.

> I first used Ada with DEC Ada, where the error messages
> are also quite complete, and it has never occurred to me
> to look for a way to make them shorter.

Yes, but many people feel that the messages from the DEC
Ada compiler are *too* verbose at times.

If you like long and detailed messages, and don't mind
redundant messages (GNAT works hard to eliminate them!),
then you might also try the -gnatf switch which stands for
full error messages, and gives additional detailed messages
in some cases, e.g. every occurrence of an undefined
identifier will be flagged -- normally only the first is
flagged.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Elaborate compile-time error messages (was: GNAT Stream Read ...)

[Larry Kilgallen]

In article <771agj$rmc$1@nnrp1.dejanews.com>, dewar@gnat.com writes:
> In article <1999Jan6.072356.1@eisner>,
>   Kilgallen@eisner.decus.org.nospam wrote:
>> In article <76uv4j$njr$1@nnrp1.dejanews.com>,
> dewar@gnat.com writes:
>>
>> That certainly is a high quality error message.  I am
>> curious as to why it is not the default.  Is there some
>> set of programmers who get really mad at having the
>> compiler be smarter than they are about the
>> nature of a problem.
> 
> First, to be clear, the *error messages* are exactly the
> same in default mode, and the error messages give column
> numbers. The difference is in printing out the source line,
> and flagging the column of the error. Most programmers do
> NOT want this as the default, and note in particular that
> when you are using an editor that is integrated with the
> compiler, e.g. EMACS, the verbosity of -gnatv just gets in
> the way and is unhelpful.

Saying that the source quotation is not part of the error
message seems a bit pedantic, perhaps due to specialized
meanings within the ACT shop.

At any rate, the idea that GNAT defaults to presuming a
tightly coupled editor makes a lot of sense, as that is
the environment recommended to those who have no reason
to choose otherwise.

Larry Kilgallen

Re: Elaborate compile-time error messages (was: GNAT Stream Read ...)

[robert_dewar]

In article <1999Jan7.081644.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> Saying that the source quotation is not part of the error
> message seems a bit pedantic, perhaps due to specialized
> meanings within the ACT shop.
>
> At any rate, the idea that GNAT defaults to presuming a
> tightly coupled editor makes a lot of sense, as that is
> the environment recommended to those who have no reason
> to choose otherwise.
>
> Larry Kilgallen


Well I guess the "specialized meaning" that we give to
"error message" in the ACT shop is that it is a message
telling you what error you have, and right, the source
line is most certainly NOT an error message in this
specialized sense :-)

As for tightly coupled editors, lots of people prefer
brief error messages even if they do not use such an
editor. Certainly my own taste is that the line number
is almost always sufficient (and of course the GNAT
error messages do give column number as well).

Anyway, if you do prefer the more verbose errors message
listings, which include the source line in error and the
error flag, then by all means use -gnatv!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: GNAT Stream Read processing problem

[Bruce Detter]

Robert,
Thanks for the tip about the -gnatv option, I will add it to the compiler
options.  GNAT has a lot of power and I'm just now beginning to learn how to
take advantage of more of the capabilities.

Thanks again...
BCD3

dewar@gnat.com wrote in message <76uv4j$njr$1@nnrp1.dejanews.com>...
>In article <76tsgd$s0o1@svlss.lmms.lmco.com>,
>  "Bruce Detter" <bruce.detter@lmco.com> wrote:
>
>> When I compile this no matter what type is specified for
>> the Read attribute and the data element to be read into,
>> I get the following errors three times:
>
>> ... expected type "Standard.Integer"
>> ... found type "Standard.Long_Integer"
>>
>> and it points me to the second parameter of each 'Read.
>> Can someone suggest what it is I'm doing wrong.
>
>Surely if you use -gnatv to point out the EXACT location of
>the error:
>
>    30.          Long_Integer'Read(S, Data(ndx).elements);
>                                           |
>        >>> expected type "Standard.integer"
>        >>> found type "Standard.long_integer"
>
>that should be enough of a clue, it is VERY specifically
>telling you that the subscript of Data must be of type
>Standard.integer, and you are using long_integer.
>
>While you are learning Ada 95, use -gnatv as a matter of
>course to tell exactly where the error message is being
>posted. GNAT goes to great pains to try to post the error
>in exactly the most helpful place, take advantage of this!
>
>Robert Dewar
>Ada Core Technologies
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own