Re: Slice and Unbounded String

Re: Slice and Unbounded String

[Robert A Duff]

In article <01bbdc70$2e557160$262a6282@cln49ae>,
Pascal Obry <pascal.obry@der.edfgdf.fr> wrote:
>S := Ada.Strings.Unbounded.Slice (U, 6, 8);
>
>Should S have a range 6 .. 8 or a range 1 .. 3.

See A.4.5(82), A.4.4(101), A.4.4(1) "whose low bound is 1", A.4.3(2),
and AI-128.  The correct result is 1..3.

(Life would be easier if type String behaved that way, so all Strings
were 1..something -- not so.)

- Bob

Re: Slice and Unbounded String

[Robert Dewar]

Pascal asks:

"With the following command :

S := Ada.Strings.Unbounded.Slice (U, 6, 8);

Should S have a range 6 .. 8 or a range 1 .. 3.

For me (after reading the RM) the first solution is the good one.

The answer will told me if GNAT or ObjectAda has a bug :-)"



The range should be 1 .. 3. This is unambiguously clear from the RM.
!.45(1) says

1   The language-defined package Strings.Unbounded provides a private type
Unbounded_String and a set of operations.  An object of type Unbounded_String
represents a String whose low bound is 1 and whose length can vary
conceptually between 0 and Natural'Last.  The subprograms for fixed-length
string handling are either overloaded directly for Unbounded_String, or are
modified as needed to reflect the flexibility in length.  Since the
Unbounded_String type is private, relevant constructor and selector
operations are provided.


Note the important statement here about the low bound being 1. So
all unbounded strings always have a lower bound of 1.

GNAT certainly returns a lower bound of 1 in accordance with the RM
requirement.

Re: Slice and Unbounded String

[Robert Dewar]

Robert Duff says

"See A.4.5(82), A.4.4(101), A.4.4(1) "whose low bound is 1", A.4.3(2),
and AI-128.  The correct result is 1..3.
"


Hmmm! I don't have AI-128 here, but I don't think the RM references are
conclusive. A.4.4(1) refers only to bounded string values (and that is
also true of the "whose low bound is 1" phrase), so it does not apply.
A.4.5(82) merely points us to A.4.4(101), which to my reading suggests
the other interpretation (low bound not necessarily 1), but only suggests ..

A.4.3(2) is conclusive, but applies to Fixed_Strings.

Now it maybe that AI-128 does indeed clear this up, but the wording should
be checked. It seems a bit anomolous that Slice returns a String rather than
an unbounded String ....


P.S. In Strings.Unbounded, what on earth is

7      type String_Access is access all String;
       procedure Free (X : in out String_Access);


these declarations are not referenced elsewhere in the package and are,
as far as I can see, completely irrelevant rubbish -- perhaps thjey had
some historical significance.

I could see providing these standard delcarations in Ada.Strings, but
not in Ada.Strings.Unbounded.

Re: Slice and Unbounded String

[Robert A Duff]

In article <dewar.849335191@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>P.S. In Strings.Unbounded, what on earth is
>
>7      type String_Access is access all String;
>       procedure Free (X : in out String_Access);

Somebody stuck this in at the last minute, just as a convenience.

>I could see providing these standard delcarations in Ada.Strings, but
>not in Ada.Strings.Unbounded.

Yeah, that would probably make more sense.

- Bob

Re: Slice and Unbounded String

[Robert Dewar]

Bob Duff said (of the bogus declaration of String_Access in
Ada.Strings.Unbounded):

"Somebody stuck this in at the last minute, just as a convenience."

Are you sure of this? Who? And why did it end up so obviously in the
wrong place? With a bogus justification:

75   The type String_Access provides a (non-private) access type for explicit
processing of unbounded-length strings.  The procedure Free performs an
unchecked deallocation of an object of type String_Access.


Since the type String_Access has nothing whatsoever to do with the
type Unbounded_String, I find the wording in para 75 incomprehensible.

Mind you a standard String_Access type would be a VERY helpful addition
to the language, because then everyone could use it easily, and you would
get better interchangable reuse of standard components using this type.

Ada.Strings would be a good place to put it, since there is almost
nothing there now, but you definitely do NOT want to casually drag
in Strings.Unbvounded just to get this definition.

Re: Slice and Unbounded String

[Ben Brosgol]

Robert Dewar wrote:
> 
> Bob Duff said (of the bogus declaration of String_Access in
> Ada.Strings.Unbounded):
> 
> "Somebody stuck this in at the last minute, just as a convenience."
> 
> Are you sure of this? Who? And why did it end up so obviously in the
> wrong place? With a bogus justification:
> 
> 75   The type String_Access provides a (non-private) access type for explicit
> processing of unbounded-length strings.  The procedure Free performs an
> unchecked deallocation of an object of type String_Access.
> 
> Since the type String_Access has nothing whatsoever to do with the
> type Unbounded_String, I find the wording in para 75 incomprehensible.
> 
> Mind you a standard String_Access type would be a VERY helpful addition
> to the language, because then everyone could use it easily, and you would
> get better interchangable reuse of standard components using this type.
> 
> Ada.Strings would be a good place to put it, since there is almost
> nothing there now, but you definitely do NOT want to casually drag
> in Strings.Unbvounded just to get this definition.

I am the "somebody" whom you can blame (or thank :-) for the presence of
String_Access and the accompanying Free procedure in
Ada.Strings.Unbounded.
Contrary to Bob Duff's comment, this was not done at the last minute 
(sorry but I recently tossed out my earlier versions of the RM so I
can't 
pinpoint exactly when it was introduced.)  The declarations could not go
in 
Ada.Strings since we wanted to keep Ada.Strings Pragma(Pure)-able, and
pure packages are not allowed to declare (named) access types.

As this thread has suggested, the access type is declared in a
predefined
package as a convenience to the programmer, since it is quite common to
need
to deal with access values designating String objects.  Whether
Ada.Strings.Unbounded
is the best place for it is arguable, I suppose, but there did not
seem to be a more appropriate home.

Ben Brosgol
Aonix
brosgol@aonix.com

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

Peter Herman said

Your inquiry above will lead to a repost by Robert Dewar, in which he will
explain that you should have reported this to report@gnat.com.
Of course you are not a paying customer and therefore your report
will be of lowest priority and possibly never considered.

  On the contrary, all reports will be considered, and many such reports
  in the past have been corrected.

In the past, a very large world-wide community of volunteers sent their
bug reports which were neatly classified and the status of the bug
could be traced. Times have changed due to lack of sponsoring.
But unfortunately, the mechanism too, which I personally consider
a great disadvantage for all of us volunteers and especially for ACT.

  I see that non-paying customers would like to get free support of this
  kind, and would consider it an advantage, but tracking bugs externally
  and corresponding on their status is time consuming, and is a service
  we provide only for our customers.

The important point is the traceability of a bug inquiry.
If this is no more given, then the number of volunteer reports,
which IS a kind of energy/money too, will go dramatically down.

In the past, I gave several dozens of bug reports although
this has never been publicly recognized in e.g. a list of contributors.
Nevertheless I am satisfied with the feeling to have contributed to
the maturing of a good product GNAT.

  And I am pleased to say that we have many volunteers who continue to
  send us useful bug reports, no doubt on a similar basis of satisfaction
  to help contribute.


Today: Why should I send a bug report?:

  -- Will they care?

        Absolutely, all bug reports get looked at and if there is a bug,
        fixed in a future version. We are pleased to receive such
        reports. They may have low priority, but they will get looked at.

  -- Did they receive it?

        You should get a response acknowledging the receipt of the report.
        If you do not, you should assume we did not receive it. This response
        may sometimes take a few days to appear.

  -- Did they classify my bug?

        Yes, eventually all reported bugs get filed, classified and
        examined (e.g. if they are a simple misunderstanding, then
        we discard them, but if they show a real bug, we file them).

  -- Is my problem already known there?
  -- Is it fixed in Version 3.07?

        It would take us time that is not directly helpful to us. These are
        the kind of services, along with figuring out work arounds and
        user problems in Ada and the use of GNAT, that we provide on a
        supported basis.

Our primary priority is support for paying customers. Our secondary priority
is continuing development and improvement of the system. As part of this
continuing development, we certainly spend time looking at bug reports from
non-supported users, but this is definitely not a priority activity, and we
work to minimize the amount of effort required for such activities.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

Larry says

If we agree that ACT gives priority to support customers, presumably
that includes not only defects reported by those customers but also
defects those customers are likely to encounter in the future.  It
may be that the defect reported by the original poster is judged as
quite likely to be hit by others, which presumably will escalate the
priority.

   Indeed, we assign priorites based on the perceived seriousness of the
   bug, and it is true that sometimes unsupported users report bugs that
   we give highish priority to (never as high as bugs from supported
   users, but high enough to get looked at more rapidly).

So what can ACT vary to provide "added value" and encourage support
contracts ?  Certainly feedback on bug status is one item (I have
no idea whether they have more feedback for paying customers).

   Exactly, for supported customers, who identify their reports to us
   by using their customer number, we provide immediate responses, and
   high priority fixing of bugs. Most of the time "bug status" is not
   an issue, since we work hard to fix customer bugs very rapidly, but
   for less urgent bugs, absolutely, we provide whatever feedback is
   required.

   In practice, only a fraction of bug reports from both supported and
   non-supported users are actual GNAT bugs. The rest of the time they
   come from a misunderstanding of Ada 95, or of GNAT, or simply from
   program bugs. For supported customers, we help them sort through
   these category of problems as well.

   It is not a matter so much of encouraging support contracts. It is more
   a matter of providing services that some find useful that is commensurate
   with the resources involved. Our customers find this support worthwhile.
   I quite understand that non-paying customers would like the same level
   of support, or perhaps some support at a lower level, but we cannot
   manufacturer resources for such free support. We do spend the time to
   continue to make public releases available, and we do accept bug reports
   from unsupported users, but that is the extent of the resources we can
   spend for unsupported users.

A somewhat softer response, which I gather ACT does not offer to
non-customers is "we understand the cause and hope to include a fix
in Version X".

   I don't know where you gather false information like this :-)
   Here is the usual response to reports from non-supported users:

     Thank you for submitting this GNAT bug report to Ada Core Technologies.
     We will investigate this when we have time and if indeed there is a bug
     in GNAT, a fix will be available in a future release of GNAT. Please note
     that we are unable to guarantee any specific response to bug reports from
     unsupported users of GNAT or to provide information on the tracking of
     these bugs, but we will eventually examine all reports.
     
     If you need rapid and/or guaranteed response to problems, please contact
     our support department by sending email to support@gnat.com. Supported
     customers can receive guaranteed timely response to problems, and also
     prereleases of new versions of the system. We are also able to answer
     general questions on the use of Ada and GNAT for supported customers.
     
     We are not able to provide help or answer questions for unsupported
     users of GNAT, but we suggest that you join our informal mailing list,
     chat@gnat.com by sending mail to chat-request@gnat.com with subject
     line "subscribe xxx", where xxx is your email address. This mailing
     list allows users of GNAT to informally discuss problems, and may be
     a source of help for you.

   The one thing that is missing is the X, but there is a good reason for
   this, in our experience, even unsupported users would regard this as a
   commitment, and yell at us for not meeting it. We are very careful not
   to make commitments that we cannot meet, and indeed we only make
   commitments with a definite date to our customers!

One courtesy ACT could provide to all would be an automated mail
message saying "Internet Mail worked, and we received your bug
report entitled 'Please change method syntax to be more like C++'".

   The above message is NOT an automated mail message. I send it out manually
   as I process the bug report. I don't like the use of automated messages
   for this purpose. This takes a little more work, but it means that when
   you get the above response, you know that the message really was received.

That mail message could include an ACT serial number, I suppose,
but then someone will complain that their syntax change request
never got included in a subsequent version and nobody at ACT has
chosen to engage them in a lengthy discourse regarding the obvious
superiority of the C++-style syntax !

   We do supply the ACT bug tracking number to customers, and we are quite
   happy to discuss all suggestions with our customers, although our
   commitment to serving our customers needs does not extend to adding
   "superior" C++ syntax to the language :-)

Gnat v3.05 bug or compilation problem

[MAKOUDI Jaouad (Stag. Kermarrec)]

While compiling a DSA program, I got this message : 

....


building dsa/receiver/rns.adb from /dsa/lib/garlic/rns.adb

+===========================GNAT BUG DETECTED==============================+
| Error detected at "rns.adb", line 36:4                                   |
| Please submit bug report by email to report@gnat.com                     |
| Use a subject line meaningful to you and us to track the bug             |
| Include full sources in ASCII in a format compatible with gnatchop       |
| First line of sources must be marked by an Ada -- comment line           |
| Last line of sources must be last line of email message (no signature!)  |
| See gnatinfo.txt file for more info on procedure for submitting bugs     |
| 3.05 (960607) (m68k-rtems) Gigi abort, Code=999                          |
+==========================================================================+
/projets/l/hostgnat/adainclude/i-cporte.ads:120:04: warning: alignment exceeds 2 (maximum allowed for target)
............



I don't really understand the meaning of that !!!

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Peter Hermann]

MAKOUDI Jaouad (Stag. Kermarrec) (makoudi@titan.enst-bretagne.fr) wrote:

: While compiling a DSA program, I got this message : 

: building dsa/receiver/rns.adb from /dsa/lib/garlic/rns.adb
                                              ^^^^^^  maybe your smelling problem ;-)
: +===========================GNAT BUG DETECTED==============================+
: | Error detected at "rns.adb", line 36:4                                   |
: | Please submit bug report by email to report@gnat.com                     |
: | Use a subject line meaningful to you and us to track the bug             |
: | Include full sources in ASCII in a format compatible with gnatchop       |
: | First line of sources must be marked by an Ada -- comment line           |
: | Last line of sources must be last line of email message (no signature!)  |
: | See gnatinfo.txt file for more info on procedure for submitting bugs     |
: | 3.05 (960607) (m68k-rtems) Gigi abort, Code=999                          |
: +==========================================================================+

: I don't really understand the meaning of that !!!

And you will possibly never understand it.

The root of the GNAT/ACT problem is the following:
Your inquiry above will lead to a repost by Robert Dewar, in which he will 
explain that you should have reported this to report@gnat.com.
Of course you are not a paying customer and therefore your report 
will be of lowest priority and possibly never considered.

In the past, a very large world-wide community of volunteers sent their
bug reports which were neatly classified and the status of the bug
could be traced. Times have changed due to lack of sponsoring.
But unfortunately, the mechanism too, which I personally consider
a great disadvantage for all of us volunteers and especially for ACT.
Why for ACT?
For us non-paying customers
(it is not always money, it is sometimes an institutional anti-Ada-attitude)
it is sufficient and acceptable to get bug-fixing on the lowest priority level.
ACT must live on the basis of the customers' money, of course.
The important point is the traceability of a bug inquiry.
If this is no more given, then the number of volunteer reports,
which IS a kind of energy/money too, will go dramatically down.
In the past, I gave several dozens of bug reports although
this has never been publicly recognized in e.g. a list of contributors.
Nevertheless I am satisfied with the feeling to have contributed to the maturing
of a good product GNAT.
Today: Why should I send a bug report?:
  -- Will they care?
  -- Did they receive it?
  -- Did they classify my bug?
  -- Is my problem already known there?
  -- Is it fixed in Version 3.07?

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Gnat v3.05 bug or compilation problem

[Larry Kilgallen]

In article <58h301$gad@alfali.enst-bretagne.fr>, makoudi@titan.enst-bretagne.fr (MAKOUDI Jaouad (Stag. Kermarrec)) writes:
> 
> While compiling a DSA program, I got this message : 
> 
> building dsa/receiver/rns.adb from /dsa/lib/garlic/rns.adb
> 
> +===========================GNAT BUG DETECTED==============================+
> | Error detected at "rns.adb", line 36:4                                   |
> | Please submit bug report by email to report@gnat.com                     |
> | Use a subject line meaningful to you and us to track the bug             |
> | Include full sources in ASCII in a format compatible with gnatchop       |
> | First line of sources must be marked by an Ada -- comment line           |
> | Last line of sources must be last line of email message (no signature!)  |
> | See gnatinfo.txt file for more info on procedure for submitting bugs     |
> | 3.05 (960607) (m68k-rtems) Gigi abort, Code=999                          |
> +==========================================================================+
> /projets/l/hostgnat/adainclude/i-cporte.ads:120:04: warning: alignment exceeds 2 (maximum allowed for target)
> ............
> I don't really understand the meaning of that !!!

What's not to understand ???  There is a compiler bug, and you are
asked to report it via electronic mail.

Having no experience with GNAT, the only possible confusion I
see for someone with electronic mail experience is:

> | Include full sources in ASCII in a format compatible with gnatchop       |

But as I read it, the definition of that term "gnatchop" might be the
next two lines:

> | First line of sources must be marked by an Ada -- comment line           |
> | Last line of sources must be last line of email message (no signature!)  |

Since you have the GNAT software, however, you probably have the
instructions file:

> | See gnatinfo.txt file for more info on procedure for submitting bugs     |

which might elaborate on "gnatchop".

If all of that turns out to not be exactly what they wanted, so what ?
You send the report in with your best effort at following the requested
format, and if you were slightly wrong the maintainers may amend the
message which is printed for such compiler errors giving more explicit
guidance to others in the future.

Every compiler has defects, and the ability to detect the situation
where such a defect is encountered is of tremendous benefit to the
producer and the consumer alike.  For various products (not just
compilers) the major variation I have seen on the above theme is
how much internal obscure information is output for you to relay
to the vendor, and that is the vendor's choice.

Larry Kilgallen

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Larry Kilgallen]

In article <58h6n2$2hbi@info4.rus.uni-stuttgart.de>, ica2ph@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes:

> Your inquiry above will lead to a repost by Robert Dewar, in which he will 
> explain that you should have reported this to report@gnat.com.
> Of course you are not a paying customer and therefore your report 
> will be of lowest priority and possibly never considered.

I am not sure how you know the original poster is not paying for support.
My opinion is that ACT should not share that information without special
permission from the customer in question.

If we agree that ACT gives priority to support customers, presumably
that includes not only defects reported by those customers but also
defects those customers are likely to encounter in the future.  It
may be that the defect reported by the original poster is judged as
quite likely to be hit by others, which presumably will escalate the
priority.

I would imagine the area where input from non-customers gets particularly
low priority is feature requests, which presumably is agreeable to all.
Second lowest might be disagreements, where interpretation of some part
of the standard is questioned.  But the example shown is neither.  It
is a situation where the compiler admits to being lost in the weeds,
and a reproducer for such makes the job for ACT potentially quite
straightforward (fix the bug).

> In the past, a very large world-wide community of volunteers sent their
> bug reports which were neatly classified and the status of the bug
> could be traced. Times have changed due to lack of sponsoring.

So what can ACT vary to provide "added value" and encourage support
contracts ?  Certainly feedback on bug status is one item (I have
no idea whether they have more feedback for paying customers).

When it comes right down to it though the only totally reliable
response possible is "fixed in version X", and that might as well
be included in the version X kit as it cannot be totally known until
version X actually is final.  I would hope that is available in an
easy-to-scan form to everyone who receives version X.

A somewhat softer response, which I gather ACT does not offer to
non-customers is "we understand the cause and hope to include a fix
in Version X".

One courtesy ACT could provide to all would be an automated mail
message saying "Internet Mail worked, and we received your bug
report entitled 'Please change method syntax to be more like C++'".

> ACT must live on the basis of the customers' money, of course.
> The important point is the traceability of a bug inquiry.

That mail message could include an ACT serial number, I suppose,
but then someone will complain that their syntax change request
never got included in a subsequent version and nobody at ACT has
chosen to engage them in a lengthy discourse regarding the obvious
superiority of the C++-style syntax !

Larry Kilgallen

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Norman H. Cohen]

Peter Hermann wrote:

> Your inquiry above will lead to a repost by Robert Dewar, in which he will
> explain that you should have reported this to report@gnat.com.
> Of course you are not a paying customer and therefore your report
> will be of lowest priority and possibly never considered.
...
> Today: Why should I send a bug report?:
>   -- Will they care?
>   -- Did they receive it?
>   -- Did they classify my bug?
>   -- Is my problem already known there?
>   -- Is it fixed in Version 3.07?

Peter:

I am not a supported ACT customer.  In October I encountered a GNAT bug
in v3.04a (a back-level version released by a company other than ACT)
and reported it to ACT.  Almost immediately, I received a polite
one-line thank-you note, and several weeks later I received a note
reporting that the bug had been fixed in 3.08w.

So my experience is yes, they do care, and they do appreciate receiving
bug reports.

I am happy to submit such reports even though I have no right to depend
on a timely response.  (In practice, I find ACT more responsive to
nonpaying users than some Ada-83 vendors were when I was a paying
customer!)  A more robust GNAT serves the interest of the entire Ada
community and improves a tool that I use.  ACT, of course, is eager to
improve the quality of GNAT for their paying customers, and will work on
a problem that they deem important even if it is a nonpaying user who
encounters the problem first.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Tom Moran]

If folks regularly cc-ed bug messages to report@gnat.com to c.l.a. then
a suitable thread or archive search could show what's been reported.  It
would of course be up to user/readers to figure out whether a particular
report was relevant to them.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

Peter Herman said

"I simply asked for more transparency.
The process became too opaque for non-customers.
Robert's statements deserve agreement, no doubt.
But I can't identify and trace my item submitted, that's all.

In summary I made the same good experience like Norman H. Cohen wrote,
therefore I really can't complain. However I think,
that ACT does not have to do more work when preserving the
visibility of the bug report mechanism of the old days.
I even see an advantage: The low priority assignments for a non-customer
could drive him to a customer  ;-)"


Yes, I know what you are asking for, but despite your "think", it does in
practice take significant resources to "preserve the visibility of the
bug report mechanism of the old days" for non-paying customers. In the
old days, the DoD supported GNAT directly, and we did provide free
support, now it doesn't, and we don't!

We do continue to provide public releases of GNAT. Often people are under
the impression that somehow this is required by the GPL, but it is not.
The GPL does not require you to distribute anything, and does not require
you to distribute it free if you do (there is much confusion on this issue,
for example, the text at adahome contains some completely incorrect statements
on this issue).

However, we feel that it is sufficiently important for the Ada community
for GNAT to be easily available, that we do spend the necessary resources
to make these free releases, even though this work is not supported by
anyone. But we definitely do NOT have the time to exchange bug tracking
information with unsupported users.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

Larry said

"and the text you offer, while quite helpful in explaining what seems
to be a perfectly reasonable maintenance policy indeed does not make
the claim that "we understand the cause".  Even given non-automated
response tactics, there must be occasions when acknowledgements can
only be timely by preceeding full understanding."


Actually, understanding the cause is 90% of the effort in many, perhaps
most cases, of difficult bug reports. Often it takes a long time before
we can even look at a report from an unsupportd user. In practice, the
more carefully the report is prepared, the more likely we are to look
at it earlier. This is particularly true for runtime problems, where
it makes things much easier if they are carefully narrowed down. 

A substantial number of reports are incomplete, or are not bug reports
at all, just misunderstandings, and those of course do not get filed.
We also do not have the resources to provide general Ada 95 assistance
to the world in such cases, so we don't have time to explain people's
misconceptions to them, except in cases where it is trivial to do so.
Of course, explaining misconceptiojns etc is very much part of our
support activities for supported customers.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

"By the way, if such a database were made available, I would strongly
recommend keeping rejected problem reports in there. They can serve as a
very useful FAQ supplement..."

Well people are always very ready to suggest ways that we can spend more
of our time without providing support for that time :-)

Right now, we are not planning any changes in the way we handle our
bug data base, except possibly in response to customer needs. If someone
is interested in funding something more extensive, we would certainly
be willing to consider it!

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Peter Hermann]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
:    The one thing that is missing is the X, but there is a good reason for
:    this, in our experience, even unsupported users would regard this as a
:    commitment, and yell at us for not meeting it.

Which is clearly not justified.
ACT is certainly not responsible for impudent children.

I simply asked for more transparency. 
The process became too opaque for non-customers.
Robert's statements deserve agreement, no doubt.
But I can't identify and trace my item submitted, that's all.

In summary I made the same good experience like Norman H. Cohen wrote,
therefore I really can't complain. However I think,
that ACT does not have to do more work when preserving the 
visibility of the bug report mechanism of the old days.
I even see an advantage: The low priority assignments for a non-customer
could drive him to a customer  ;-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Larry Kilgallen]

In article <dewar.850183545@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry says

> A somewhat softer response, which I gather ACT does not offer to
> non-customers is "we understand the cause and hope to include a fix
> in Version X".
> 
>    I don't know where you gather false information like this :-)

Well, certainly not directly from ACT, since I have not used GNAT and
thus have never submitted a bug report.

>    Here is the usual response to reports from non-supported users:

and the text you offer, while quite helpful in explaining what seems
to be a perfectly reasonable maintenance policy indeed does not make
the claim that "we understand the cause".  Even given non-automated
response tactics, there must be occasions when acknowledgements can
only be timely by preceeding full understanding.

>    The one thing that is missing is the X, but there is a good reason for
>    this, in our experience, even unsupported users would regard this as a
>    commitment, and yell at us for not meeting it. We are very careful not
>    to make commitments that we cannot meet, and indeed we only make
>    commitments with a definite date to our customers!

I worry about getting firm promises of "fixed in version X" well
in advance of release, since it may indicate the vendor will not
retract that fix before release even if a regression is discovered
to be introduced by the fix.

Of course promising a _date_ to a supported customer is different,
since ACT could roll them a special version if that customer is
not likely to be hit by the regression, and then address the
regression later.

> One courtesy ACT could provide to all would be an automated mail
> message saying "Internet Mail worked, and we received your bug
> report entitled 'Please change method syntax to be more like C++'".
> 
>    The above message is NOT an automated mail message. I send it out manually
>    as I process the bug report. I don't like the use of automated messages
>    for this purpose. This takes a little more work, but it means that when
>    you get the above response, you know that the message really was received.

Yes, "An ACT human has seen your mail" certainly is a step above
"An ACT computer has seen your mail". I suppose this is to be
expected from those with an academic background who are familiar
with "The dog<DEL><DEL><DEL>computer ate my homework!".

>    We do supply the ACT bug tracking number to customers, and we are quite
>    happy to discuss all suggestions with our customers, although our
>    commitment to serving our customers needs does not extend to adding
>    "superior" C++ syntax to the language :-)

I guess even support customers would have to pay extra for that --
LOTS extra :-)

Larry Kilgallen

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Tom Moran]

>One courtesy ACT could provide to all would be an automated mail
>message saying "Internet Mail worked, and we received your bug
  I just send the report again on those occasions when there's been no
response after a couple of days.  Getting lost once in e-mail often
happens, but the probability of getting lost twice is low.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Ken Garlington]

Robert Dewar wrote:
> 
>   I see that non-paying customers would like to get free support of this
>   kind, and would consider it an advantage, but tracking bugs externally
>   and corresponding on their status is time consuming, and is a service
>   we provide only for our customers.

Has there been some consideration of having a site where anyone could
log
in anonymously, and run queries against a problem tracking database?
SD-Scicon experimented with such a system some time back, and I found it
very useful. The GNAT bug list delivered with the compiler is useful,
but
of course it's not a complete list, nor do the titles alone always
explain
the bug.

Bonus points: Have the developers add status to the problem reports, so
that everyone can see what you guys at ACT do all day (when you're not
on
c.l.a, of course)!

By the way, if such a database were made available, I would strongly
recommend keeping rejected problem reports in there. They can serve as a
very useful FAQ supplement...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Norman H. Cohen]

Larry Kilgallen wrote:
 
> In article <32AE0EDC.4D4B@bix.com>, Tom Moran <tmoran@bix.com> writes:
> > If folks regularly cc-ed bug messages to report@gnat.com to c.l.a. then
> > a suitable thread or archive search could show what's been reported.  It
> > would of course be up to user/readers to figure out whether a particular
> > report was relevant to them.
> 
> If folk were to do that, those of us who do not use GNAT might insist
> on creation of comp.lang.ada.gnat and the result would be a newsgroup
> situation as convoluted as comp.lang.pascal.*.*.
> 
> Perhaps cc- might be helpful, but NOT to c.l.a.

Larry is absolutely right--copying bug reports to c.l.a would clutter
this newsgroup with unwanted data.  The problem is not only that, as
Larry pointed out, many (well, some) c.l.a readers do not use GNAT; it
is also that many GNAT bug reports result from "pilot error" and are
thus not of general interest.  

There is already a list server (chat-request@gnat.com to subscribe,
chat@gnat.com to post messages) specifically for GNAT users.  That is a
far more appropriate forum than c.l.a for posting reports of possible
bugs.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Tom Moran]

> chat@gnat.com to post messages) specifically for GNAT users.  That is a
> far more appropriate forum than c.l.a for posting reports of possible
> bugs.
  Is there an easy way to scan back through listerver messages for a
topic?
That's why I said c.l.a. instead of chat@gnat.com, which I agree is much
more
appropriate.  But the tools appear more convenient for newsgroups.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

Larry says, regarding GNAT bug reports

"Perhaps cc- might be helpful, but NOT to c.l.a."

I think that is good advice. The one time it is sometimes worth a CLA
discussion is if there is some interesting language discussion that comes
out of a possible GNAT bug. But if you are getting a compiler crash, then
sending a copy of the bug box to CLA is for most readers a zero content
message!

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

Peter Herman says

"Ken Garlington wrote good ideas, too.
Does ACT want a parallel organisation caring for non-customers?"

We don't have any particular reaction. Certainly people are welcome to do
anything they like. The chat@gnat.com list acts a little like this, but
generally you can't expect to get real bugs fixed on this list!

If you have not joined chat@gnat.com, I recommend you do so, it may meet
your needs, particuarly for things like installation problems.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

Tom Moran says

"  I just send the report again on those occasions when there's been no
response after a couple of days.  Getting lost once in e-mail often
happens, but the probability of getting lost twice is low."


Actually, it is probably better to wait more than a couple of days, often
we get a little behind in processing messages from unsupported users,
especially after an event like Tri-Ada and "The Maiden and the Mandates"
absorbs quite a bit of our time :-)

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

Tom Moran says

"If folks regularly cc-ed bug messages to report@gnat.com to c.l.a. then
a suitable thread or archive search could show what's been reported.  It
would of course be up to user/readers to figure out whether a particular
report was relevant to them."

please do NOT cc comments to report@gnat.com to any other mailing list
or newsgroup. Send a separate message, otherwise we cannot process the
report properly. Thanks. We should probably emphasize this in the documentation
I will update it right away.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Peter Hermann]

Tom Moran (tmoran@bix.com) wrote:
: If folks regularly cc-ed bug messages to report@gnat.com to c.l.a. then
: a suitable thread or archive search could show what's been reported.  It
: would of course be up to user/readers to figure out whether a particular
: report was relevant to them.

Ken Garlington wrote good ideas, too.
Does ACT want a parallel organisation caring for non-customers?
DEC | DECUS
ACT | ACTUS                ;-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Larry Kilgallen]

In article <32AE0EDC.4D4B@bix.com>, Tom Moran <tmoran@bix.com> writes:
> If folks regularly cc-ed bug messages to report@gnat.com to c.l.a. then
> a suitable thread or archive search could show what's been reported.  It
> would of course be up to user/readers to figure out whether a particular
> report was relevant to them.

If folk were to do that, those of us who do not use GNAT might insist
on creation of comp.lang.ada.gnat and the result would be a newsgroup
situation as convoluted as comp.lang.pascal.*.*.

Perhaps cc- might be helpful, but NOT to c.l.a.

Larry Kilgallen

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Larry Kilgallen]

In article <32AF4E35.5AD7@bix.com>, Tom Moran <tmoran@bix.com> writes:
>> chat@gnat.com to post messages) specifically for GNAT users.  That is a
>> far more appropriate forum than c.l.a for posting reports of possible
>> bugs.
>   Is there an easy way to scan back through listerver messages for a
> topic?
> That's why I said c.l.a. instead of chat@gnat.com, which I agree is much
> more
> appropriate.  But the tools appear more convenient for newsgroups.

Perhaps "the" tools are more convenient in your particular environment,
but not in mine.  Much as everyone should learn 5 languages to better
understand some smaller number, I think everyone should spend some time
using each of 5 operating systems as their "home" environment.

And only one of them should be some variant of "Unix" :-).

Larry Kilgallen

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[John Cosby]

Tom Moran wrote:
> 
> If folks regularly cc-ed bug messages to report@gnat.com to c.l.a. then
> a suitable thread or archive search could show what's been reported.  It
> would of course be up to user/readers to figure out whether a particular
> report was relevant to them.

Not just that - one of our guys was downloading the source for GNAT
yesterday because he couldn't find any other way of finding out if a
bug was fixed.  A link from the ACT page to a list of bug reports, 
with the version of GNAT that fixes the corresponding bugs, would be
nice and save lots of download time.

John
-- 
John Cosby                    SAIC Orlando               
John.D.Cosby@cpmx.saic.com    (407) 282-6700 x216

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

John Cosby said

"Not just that - one of our guys was downloading the source for GNAT
yesterday because he couldn't find any other way of finding out if a
bug was fixed.  A link from the ACT page to a list of bug reports,
with the version of GNAT that fixes the corresponding bugs, would be
nice and save lots of download time."


Well that makes no sense at all to me. Either this "guy" was supported or
he was not. If he was not supported, then there is insufficient information
anyway to determine whether his bug has been fixed. If he was supported,
then he received detailed information about his bug when it was fixed,
and can in any case ask for an update.

Actually we have found that publishing the list of open bugs is often
a complete waste of time. Any time people have tried to deduce information
from this list as to whether a particular bug is the same as theirs, they
have never been able to provide useful additional input. Many of the bugs
listed as open their are essentially undigested, and even the brief
description can be completely wrong, since it is often based on the origial
user report which turns out to be confused.

Properly classifying and understanding a bug report is often 90% of th3
work in fixing the bug, or figuring out that there is no bug in the first
place (undoubtedly a number of the bugs listed as open are not bugs at all),
so detailed analyses simply are not available.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Tom Moran]

> Of course, once the first email is lost, the second is just as likely as
> any other transmission to be lost (perhaps more).  %-)
  Of course the problem is 'did the first e-mail get lost, or did they
just fail to respond'.

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Ted Dennison]

Tom Moran wrote:
> 
> >One courtesy ACT could provide to all would be an automated mail
> >message saying "Internet Mail worked, and we received your bug
>   I just send the report again on those occasions when there's been no
> response after a couple of days.  Getting lost once in e-mail often
> happens, but the probability of getting lost twice is low.

Of course, once the first email is lost, the second is just as likely as
any other transmission to be lost (perhaps more).  %-)

That reminds me of a scene from "The Life According to Garp"  (Yes, yes.
I *know* it was a book first. I watch way more movies than I read
books.) Garp is shopping for houses, and an airplane crashes right into
the house he is looking at. He agrees to purchase the property on the
spot, reasoning that the odds of that happening *twice* are
astronomical. Looking at the smoldering wreckage, he hugs his wife and
tells her "We'll be safe here."



-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Root of a GNAT problem (was: Gnat v3.05 bug or compilation problem

[Robert Dewar]

"  Of course the problem is 'did the first e-mail get lost, or did they
just fail to respond'."

You should always get at least the default response to any bug report you
send to report@gnat.com. Sometimes (if you are a non-supported user), it
may take several days, or even a week or two, to get this response, but
if you have heard nothing after a while, it means that either we did not
get it, or our return mail got lost, or your message had invalid headers
and we could not find an address to respond to. 

Robert Dewar
Ada Core Technologies