Fun with WebAda/GNAT

Fun with WebAda/GNAT

[Ken Garlington]

I created a driver procedure for a package I wanted to test, and
accidentally called the procedure's file "person_test.ads". I
got a warning about the file name, so I copied the file to 
"person_test.adb" -- without deleting the .ads file. Here's the fun
error I got:

GNAT Compiler Version 3.04 Copyright 1991-1996 Free Software Foundation, 
Inc.

Checking: 
/export/user_data/ada_source/cliffy.lfwc.lockheed.com/person_test.adb 
(source file time stamp: 1996-08-14 22:30:22)

     1. with Person;
     2. procedure Person_Test is
                  |
        >>> file "person_test.ads" does not contain expected unit
        >>> expected unit "Person_Test"
        >>> found unit "Person_Test"

 
-- 
LMTAS - "Our Brand Means Quality"

Re: Fun with WebAda/GNAT

[Robert Dewar]

Key Garlington said

"I created a driver procedure for a package I wanted to test, and
accidentally called the procedure's file "person_test.ads". I
got a warning about the file name, so I copied the file to
"person_test.adb" -- without deleting the .ads file. Here's the fun
error I got:"

Well version 3.04 is a little out of date by now, and I am afraid that
the latest version of GNAT will spoil the fun :-)

person_test.adb:1:11: file "person_test.ads" does not contain expected unit
person_test.adb:1:11: expected unit "person_test (spec)"
person_test.adb:1:11: found unit "person_test (body)"

I fixed this bug this morning, it is really strange sometimes how bug
reports come in pairs!

Re: Fun with WebAda/GNAT

[David Weller]

In article <32120233.484C@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>I created a driver procedure for a package I wanted to test, and
>accidentally called the procedure's file "person_test.ads". I
>got a warning about the file name, so I copied the file to 
>"person_test.adb" -- without deleting the .ads file. Here's the fun
>error I got:
>     1. with Person;
>     2. procedure Person_Test is
>                  |
>        >>> file "person_test.ads" does not contain expected unit
>        >>> expected unit "Person_Test"
>        >>> found unit "Person_Test"
>

But wait!  There's more!

We noticed a similar problem in the project we were doing.  It was
clear there was a lurking .ads file around, but it wasn't in the
directory.  We were a little confused until we realized that it was
finding it in one of the directories in the ADA_INCLUDE_PATH !

This isn't a slam against GNAT -- it's just a wierd error message
(which they always strive to make more understandable).  I had
intended to send this in as a "please fix?" request.  I'm sure RObert
will comment on this, but I"m going to cc report@gnat.com for this
post.

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Fun with WebAda/GNAT

[Ken Garlington]

David Weller wrote:
> 
> In article <32120233.484C@lmtas.lmco.com>,
> Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
> >I created a driver procedure for a package I wanted to test, and
> >accidentally called the procedure's file "person_test.ads". I
> >got a warning about the file name, so I copied the file to
> >"person_test.adb" -- without deleting the .ads file. Here's the fun
> >error I got:
> >     1. with Person;
> >     2. procedure Person_Test is
> >                  |
> >        >>> file "person_test.ads" does not contain expected unit
> >        >>> expected unit "Person_Test"
> >        >>> found unit "Person_Test"
> >
> 
> But wait!  There's more!
> 
> We noticed a similar problem in the project we were doing.  It was
> clear there was a lurking .ads file around, but it wasn't in the
> directory.  We were a little confused until we realized that it was
> finding it in one of the directories in the ADA_INCLUDE_PATH !

Of course, with WebAda this sort of problem is really annoying, since
as far as I can tell there's no way to delete files!

-- 
LMTAS - "Our Brand Means Quality"

Re: Fun with WebAda/GNAT

[Robert Dewar]

"But wait!  There's more!

We noticed a similar problem in the project we were doing.  It was
clear there was a lurking .ads file around, but it wasn't in the
directory.  We were a little confused until we realized that it was
finding it in one of the directories in the ADA_INCLUDE_PATH !

This isn't a slam against GNAT -- it's just a wierd error message
(which they always strive to make more understandable).  I had
intended to send this in as a "please fix?" request.  I'm sure RObert
will comment on this, but I"m going to cc report@gnat.com for this
post."

Ken's experience was certainly a weirdness, but this just seems a matter
of not knowing exactly what is going on. Of COURSE the path is searched
for the spec, that's what it is for! For example, you could have multiple
bodies for the same spec, and control which body you got by using
appropriate paths.

There is nothing to fix that I can see!

If you find that the use of paths is confusing, stick to the use of
-I switches to explicitly say where to look for with'ed files.

Re: Fun with WebAda/GNAT

[Robert Dewar]

Ken Garlington said, answering me

"> If you find that the use of paths is confusing, stick to the use of
> -I switches to explicitly say where to look for with'ed files.

Of course, WebAda does not give you that option - all files are kept in
a single directory. Combine that with an inability to delete or rename
files, and a file naming mistake can really cause some excitement!

Sometimes, simple GUI interfaces can be just a little _too_ simple..."

There seems to be a disconnect here. You reported a bug, since fixed,
which did indeed cause a strange message from a misnamed file, but that
was simply a bug.

The issue with paths is quite different, and as you point out, irrelevant
to the use of WebAda.

Re: Fun with WebAda/GNAT

[Ken Garlington]

Robert Dewar wrote:

> If you find that the use of paths is confusing, stick to the use of
> -I switches to explicitly say where to look for with'ed files.

Of course, WebAda does not give you that option - all files are kept in
a single directory. Combine that with an inability to delete or rename
files, and a file naming mistake can really cause some excitement!

Sometimes, simple GUI interfaces can be just a little _too_ simple...

-- 
LMTAS - "Our Brand Means Quality"

Re: Fun with WebAda/GNAT

[Doug Smith]

In article <dewar.840313386@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> Ken Garlington said, answering me
> 
> "> If you find that the use of paths is confusing, stick to the use of
> > -I switches to explicitly say where to look for with'ed files.
> 
> Of course, WebAda does not give you that option - all files are kept in
> a single directory. Combine that with an inability to delete or rename
> files, and a file naming mistake can really cause some excitement!
> 
> Sometimes, simple GUI interfaces can be just a little _too_ simple..."
> 
> There seems to be a disconnect here. You reported a bug, since fixed,
> which did indeed cause a strange message from a misnamed file, but that
> was simply a bug.
> 
> The issue with paths is quite different, and as you point out, irrelevant
> to the use of WebAda.

I think Ken's criticism of WebAda is valid. To get to the first release,
there were many obvious compromises, and I wondered how long until the
missing delete unit feature would become an issue.

Ken describes the worst problem, and the list of units also starts to grow
too large. The delete unit operation will be available soon. It is not as
straightforward as it sounds to have a clean interface using forms and
cgi scripts and to maintain some level of protection from accidentally
deleting someone else's file (or a predefined package specification!).

Doug Smith
dsmith@clark.net

Re: Fun with WebAda/GNAT

[Robert Dewar]

Doug says

"Ken describes the worst problem, and the list of units also starts to grow
too large. The delete unit operation will be available soon. It is not as
straightforward as it sounds to have a clean interface using forms and
cgi scripts and to maintain some level of protection from accidentally
deleting someone else's file (or a predefined package specification!).

Doug Smith"

Yes, of course that is true, but what on earth does it have to do with
file naming errors -- the issue that started this rather curious thread!

Re: Fun with WebAda/GNAT

[Ronald Cole]

dewar@cs.nyu.edu (Robert Dewar) writes:
> There is nothing to fix that I can see!

Sure there is!  Just print the path names for the files/specs in the
error message.

> If you find that the use of paths is confusing, stick to the use of
> -I switches to explicitly say where to look for with'ed files.

Thank RMS that gcc has the good sense to print the filenames and line
numbers of the files involved...

X redefined						<---  sucks!

xxx.c:10425:  X redefined				<---  doesn't suck
xxx.h:35678:  location of previous definition of X

-- 
Ronald Cole                                     E-mail: ronald@ridgecrest.ca.us
President, CEO                                          zippy@ecst.csuchico.edu
Forte International                                Fax: (619) 384-2346
     My PGP fingerprint: E9 A8 E3 68 61 88 EF 43  56 2B CE 3E E9 8F 3F 2B

Re: Fun with WebAda/GNAT

[Robert Dewar]

Ronald says

  "Sure there is!  Just print the path names for the files/specs in the
  error message."

We have discussed this, but path names in typical Unix systems are so
long that this generates an unacceptable level of noise in the normal
case. We do of course print references for multiple definitions, so
I am not quite sure what that is about:

q.adb:2:03: "x" conflicts with declaration at q.ads:2

But are you really sure you want to see

/nile.a/ada/ada/gnatbugs/fixed/0000-020/q.adb:2:03: "x" conflicts with
declaration at /nile.a/ada/ada/gnatbugs/fixed/0000-020/q.ads:2

we think not. I suppose one could put in a switch, but there are lots of
switches already, and typically no one reads the documentation carefully,
so no one knows about them!

I certainly have never had trouble with the lack of full paths in error
messages, and it is not something that any of our users have ever requested.
Error messages are always a matter of balance, and we tend to trying to keep
them short and content rich.

A little tool that shows you where something is on the ada include path
sounds trivial, and useful in cases where someone is confused as to where
something is. Actually that would be nice to build into EMACS.

Re: Fun with WebAda/GNAT

[Doug Smith]

I was going to change the subject line, but it seems even more
appropriate now:

In article <dewar.840403100@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> [snip]
> 
> But are you really sure you want to see
> 
> /nile.a/ada/ada/gnatbugs/fixed/0000-020/q.adb:2:03: "x" conflicts with
> declaration at /nile.a/ada/ada/gnatbugs/fixed/0000-020/q.ads:2

[Answering for myself:]

Eventually, yes. I would like gnat to begin moving toward some standard
markup of error messages and other output. Obviously, the markup I would
recommend is HTML. Currently, WebAda takes the output of the compiler and
echos it as pre-formatted text (which it most certainly is). But there
is nothing to prevent the output from indicating more information in a
form that can be rendered in a readable way:

<pre>
  <a
href="surfada?file=/nile.a/ada/ada/gnatbugs/fixed/0000-020/q.adb">q.adb</a>:2:03:
<b>x</b> conflicts with declaration at <a
href="surfada?file=/nile.a/ada/ada/gnatbugs/fixed/0000-020/q.ads">q.ads</a>:2
</pre>

If your news reader does not render the html above, it would look something
like:

  q.adb:2:03: x conflicts with declaration at q.ads:2

Which does not necessarily make the problem apparent. However, browsers
will indicate the target of a link when pointing at that link. Of course,
I've made a link that uses my surfada tool, and GNAT would probably need
to define an environment variable or configuration file which could be
changed to use a different tool (which would have to recognize the file
parameter).

> we think not. I suppose one could put in a switch, but there are lots of
> switches already, and typically no one reads the documentation carefully,
> so no one knows about them!

In this case, the switch would indicate that a standard markup is used
for tools to render the output. This allows you to add italics, color,
etc. Not everyone gets excited about color, but some people find it
helpful. An alternative would be to define your own markup which a
tool (such as WebAda) could translate into html (or whatever) and
render for the developer.

> I certainly have never had trouble with the lack of full paths in error
> messages, and it is not something that any of our users have ever requested.
> Error messages are always a matter of balance, and we tend to trying to keep
> them short and content rich.
> 
> [snip]

Good point. And towards that goal, much of the information in an error
message can be rendered more efficiently when that information is in
markup. In the example above, a browser would render a single line, yet
contain significantly more information than the text only message.

Doug

p.s. The phrase "conflicts with declaration" could also be linked to a page
     providing detailed explanations and references to the LRM, tutorials,
     etc. ACT would need only map each error message to a unique file
     path which the Ada community could begin to maintain for everyone's
     benefit. (I'm trying to ease the burden on the ACT folk so that it
     might be more feasible to implement my proposal)

Re: Fun with WebAda/GNAT

[Robert Dewar]

Ken explained about the lack of delete function in Web Ada causing trouble ...

Ah, yes, I see what you mean! Yes, indeed the delete is fundamental in
a case like this. Note that it can also arise if you do the following
steps:

a) compile a package spec called x.ads that does not need a body

b) compile subsequently a procedure body called x.adb that either needs
no spec or a corresponding procedure spec.

The RM specifically says that the procedure body overrides the spec in
this case, but GNAT insists that the dubious file be removed. Note that
if you have no delete, then there is no solution AT ALL to the problem
I outline above other than supplying a dummy procedure spec.

Worse still, the new 3.07 version of GNAT has a new check that there is
no junk body file around. Now imagine:

a) compile a procedure body x.adb

b) compile a generic instantiation x.ads

GNAT will now insist that you removed the junk x.adb file before proceeding,
and if you have no delete file, then you are *really* stuck, since there
is no corresponding dummy body that can be supplied.

So I agree, a delete file functionality is fundamental to the source
based model that GNAT uses, since in some cases removing things from the
environment requires the deletion of the correspoinding source files.

Note: the ACVC requires that these deletions occcur automatically, so for
the ACVC, we use a special script that actually deletes the junk files
silently, but it is hard to believe that anyone would want this to be a
normal mode of operation.

Re: Fun with WebAda/GNAT

[Ken Garlington]

Robert Dewar wrote:
> 
> Yes, of course that is true, but what on earth does it [lack of delete function
> in WebAda] have to do with file naming errors -- the issue that started this
> rather curious thread!

Here's the sequence of events:

1. I wrote a test driver procedure for the Zoo package, named (quite creatively)
"Zoo_Driver."

2. I saved the procedure as Zoo_Driver.ads. This was a (minor) bad thing. GNAT
complained that I had saved a procedure body as a procedure spec, with the
humorous error message I posted originally.

3. I copied Zoo_Driver.ads to Zoo_Driver.adb. GNAT still complained that the .ads
file was misnamed (of course).

4. I tried to delete Zoo_Driver.ads.  No such function exists in WebAda.

5. I deleted the contents of Zoo_Driver.ads - made it a null file. GNAT complained
that it was a null file.

6. Finally, I put a specification for Zoo_Driver in Zoo_Driver.ads, namely:

   procedure Zoo_Driver;

and all was well. However, it's a little annoying - a delete function would have
been handy.

By the way, Doug Smith says:

> The delete unit operation will be available soon. It is not as
> straightforward as it sounds to have a clean interface using forms and
> cgi scripts and to maintain some level of protection from accidentally
> deleting someone else's file (or a predefined package specification!).

I'm not sure I see the difficulty. Currently, WebAda only shows me my files
on the file list. I can't edit other people's files, or pre-defined packages,
from that list. Just add a Delete button next to the Edit button on the file
list.

-- 
LMTAS - "Our Brand Means Quality"

Re: Fun with WebAda/GNAT

[Ronald Cole]

dewar@cs.nyu.edu (Robert Dewar) writes:
> We have discussed this, but path names in typical Unix systems are so
> long that this generates an unacceptable level of noise in the normal
> case.

If you're willing to toss out clarity and exactness in favor of
aesthetic pleasantness, then so be it.  It's your compiler and your
error messages...

-- 
Ronald Cole                                     E-mail: ronald@ridgecrest.ca.us
President, CEO                                          zippy@ecst.csuchico.edu
Forte International                                Fax: (619) 384-2346
     My PGP fingerprint: E9 A8 E3 68 61 88 EF 43  56 2B CE 3E E9 8F 3F 2B

Re: Fun with WebAda/GNAT

[Doug Smith]

In article <32181E12.7427@lmtas.lmco.com>, Ken Garlington
<garlingtonke@lmtas.lmco.com> wrote:
> [snip]
> 
> By the way, Doug Smith says:
> 
> > The delete unit operation will be available soon. It is not as
> > straightforward as it sounds to have a clean interface using forms and
> > cgi scripts and to maintain some level of protection from accidentally
> > deleting someone else's file (or a predefined package specification!).
> 
> I'm not sure I see the difficulty. Currently, WebAda only shows me my files
> on the file list. I can't edit other people's files, or pre-defined packages,
> from that list. Just add a Delete button next to the Edit button on the file
> list.

Ohhh, but you can see other people's files. And you can surf the units
which gives you an edit button. Try this:
 
<http://sw-eng.falls-church.va.us/cgi-bin/webada/surfada?file=/export/user_data/ada_source/dsmith.clark.net/sort.adb>

You are surfing some code in my WebAda directory. Notice the edit button!
Guess what happens.....drum roll.....you get a copy in your own directory
to edit. You'll have to "edit" the spec also to get your copy to compile.

Now consider what happens when I add the delete cgi-bin script. You could
type in a URL by hand, such as the one above, and substitute "delete" for
"surfada". I have to make sure you don't delete my file.

By the way, you can surf the predefined packages and edit them...well at
least a copy which goes into your own directory. All the more reason to
have a delete operation!

And, of course, I plan (and have already started) to add a library
(i.e. directory) search path ability to WebAda. Which will allow clients
to more easily share their code...again, I don't want anyone to delete
units that aren't theirs.

No unix permissions don't help here because everyone going through the http
server has the same permissions.

Well, I've talked this one to death. I need to work on the problem instead
of talking about it!

Doug.

Re: Fun with WebAda/GNAT

[Ken Garlington]

Doug Smith wrote:
> 
> Ohhh, but you can see other people's files. And you can surf the units
> which gives you an edit button. Try this:

[very long string follows]

To which I say: Pish and tosh!

It's a teaching compiler, for Pete's sake! Do we really need to protect each
other's files from malicious access, or just accidental ones? My point was
that providing the delete button should prevent _accidental_ deletions, which
is certainly acceptable security for how I use WebAda. If someone needs to
be better protected, let them copy their files to their local node periodically.
I wouldn't waste too much time on an ultra-secure implementation.

-- 
LMTAS - "Our Brand Means Quality"

Re: Fun with WebAda/GNAT

[Robert Dewar]

Ronald Cole says

"> We have discussed this, but path names in typical Unix systems are so
> long that this generates an unacceptable level of noise in the normal
> case.

If you're willing to toss out clarity and exactness in favor of
aesthetic pleasantness, then so be it.  It's your compiler and your
error messages..."

On the contrary, it does NOT improve clarity at all to give full path
names, but instead obscures the clarity of the messages in the normal
case. Given that you can trivially find out what file is being referenced
in the rare case where you don't immediately know, it seems clear that
it is best NOT to disturb the clarity of ordinary messages.

If you want to experiment with this, it is an obvious one token chanbge
in errout to generate the full file name ...

Re: Fun with WebAda/GNAT

[Richard A. O'Keefe]

Ronald Cole <ronald@ridgecrest.ca.us> writes:

>dewar@cs.nyu.edu (Robert Dewar) writes:
>> We have discussed this, but path names in typical Unix systems are so
>> long that this generates an unacceptable level of noise in the normal
>> case.

>If you're willing to toss out clarity and exactness in favor of
>aesthetic pleasantness, then so be it.  It's your compiler and your
>error messages...

Surely there is a compromise possible?
It was my understanding that Gnat already by default buffers error
messages.  Now, *path* names may be long, but that's mainly because
they include a directory prefix as well as a file name.

So, compress!  Instead of
	a-long-dir/sub-dir/foo/uck.adb:27: ...
	a-long-dir/sub-dir/foo/ick.adb:19: ...
	a-long-dir/sub-dir/bar/zoo.adb:10: ...
	a-long-dir/sub-dir/bar/goo.adb:99: ...
generate
	#d1=a-long-dir/sub-dir
	#d2=$d1/foo
	$d2/uck.adb:27: ...
	$d2/ick.adb:19: ...
	#d3=$d1/bar
	$d3/zoo.adb:10: ...
	$d3/goo.adb:99: ...

This can be automatically generated from a full-form error list.
A full-form error list can be automatically generated from it.
It combines the merits of brevity AND exactness.

For what it's worth, when students have a problem, it is often useful
to be able to see from their transcript whether the problem was in one
of their own files or whether it was something from the library path.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Fun with WebAda/GNAT

[Robert Dewar]

Richard said

"For what it's worth, when students have a problem, it is often useful
to be able to see from their transcript whether the problem was in one
of their own files or whether it was something from the library path.
"

Having taught Ada using GNAT more than once, I can't see this as a problem.
We have our students work in well defined environments with preset paths,
where we know immediately from the units involved where they are.

Also, I don't work at all from "transcripts", students send me source
code. I run it in the identical environment that they do, so I know
exactly what is happening -- I think this works out much better in
practice.

Re: Fun with WebAda/GNAT

[Robert Dewar]

Doug said

"p.s. The phrase "conflicts with declaration" could also be linked to a page
     providing detailed explanations and references to the LRM, tutorials,
     etc. ACT would need only map each error message to a unique file
     path which the Ada community could begin to maintain for everyone's
     benefit. (I'm trying to ease the burden on the ACT folk so that it
     might be more feasible to implement my proposal)"

Actually we have done a lot of thinking about this kind of extended
error message handling with hypertext links. We even have a name for
the corresponding utility, it is called GNOME, for GNAT Online Message
Explanation. A great name :-) but no code yet :-(

But sure, I agree with what Doug said, my comments were solely about
what the default text of the message says (i.e. what you see in Emacs
as you go through the program checking error messages).