strange error message

strange error message

[evangeli]

hi all

does anybody know the meaning of this message (at the runtime) :

------------------------------------------------
Xlib: unexpected async reply (sequence 0x1530)!
------------------------------------------------

my code has been compiled with gnat 3.14
i post this message just in case if someone got this message and 
resolved the problem

thanks for any response.

Sami Evangelista

Re: strange error message

[Stephen Leake]

evangeli <evangeli@cnam.fr> writes:

> hi all
> 
> does anybody know the meaning of this message (at the runtime) :
> 
> ------------------------------------------------
> Xlib: unexpected async reply (sequence 0x1530)!
> ------------------------------------------------

This appears to be an X Windows error message. It is clearly _not_ a
GNAT run-time error message. You'll probably get more help on an X
Windows newsgroup.

-- 
-- Stephe

Strange error message

[Charly]

Hi,

when I defined a class hierarchy I encountered a problem, that I could reduce 
to the following few lines:

This version compiles without problems:
-----------------
package Test is

   type Base is tagged private;
   function Create return Base;

   type High is new Base with private;

private

   type Base is tagged null record;

   type High is new Base with null record;

end Test;
-----------------

but this one

-----------------
package Test is

   type Base is tagged private;
   function Create return Base;

   type High is new Base with private;

private

   type Base is tagged null record;

   type High is new Base with record     --
      H_Val : Natural := 0;              -- these lines are changed
   end record;                           --

end Test;
-----------------

does not compile an I get an error:

   type must be declared abstract or "Create" overridden

Why do I have to overide the function Create for type High.
I don't see the necessity.

Btw. I'm using GNAT GPL 2014 but the same happens with 2013 version.

Charly
  

Re: Strange error message

[Dmitry A. Kazakov]

On Sun, 1 Jun 2014 03:24:02 -0700 (PDT), Charly wrote:

> when I defined a class hierarchy I encountered a problem, that I could reduce 
> to the following few lines:
> 
> This version compiles without problems:
> -----------------
> package Test is
> 
>    type Base is tagged private;
>    function Create return Base;
> 
>    type High is new Base with private;

You must override Create for High, *always*.
 
> Why do I have to overide the function Create for type High.
> I don't see the necessity.
> 
> Btw. I'm using GNAT GPL 2014 but the same happens with 2013 version.

I believe it was a recent hack (wrongly) added to Ada that you need not to
override primitive operations returning the tagged type when the derived
type does not actually extend. I don't know if making that public or
privately changes anything. You did that privately.

It is an awful idea in any form. You should always override such
operations, and all out-operations, because inheriting them is a priori
unsafe.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Strange error message

[Charly]

Am Sonntag, 1. Juni 2014 13:11:08 UTC+2 schrieb Dmitry A. Kazakov:
> On Sun, 1 Jun 2014 03:24:02 -0700 (PDT), Charly wrote:
> 
> You must override Create for High, *always*.
> 
>  
.........
> 
> 
> I believe it was a recent hack (wrongly) added to Ada that you need not to
> 
> override primitive operations returning the tagged type when the derived
> 
> type does not actually extend. I don't know if making that public or
> 
> privately changes anything. You did that privately.
> 
> 
> 
> It is an awful idea in any form. You should always override such
> 
> operations, and all out-operations, because inheriting them is a priori
> 
> unsafe.
> 
> 
> 
> -- 
> 
> Regards,
> 
> Dmitry A. Kazakov
> 
> http://www.dmitry-kazakov.de

> -- 
> 
> Regards,
> 
> Dmitry A. Kazakov
> 
> http://www.dmitry-kazakov.de


Thank you for the rapid answer. I wondered if it is a bug in GNAT.
I thought, that I always have to override abstract function and 
procedures in concrete types and can override concrete functions
and procedures only as needed.


Charly

Re: Strange error message

[Simon Wright]

Charly <carl.weierstrass@googlemail.com> writes:

> Thank you for the rapid answer. I wondered if it is a bug in GNAT.
> I thought, that I always have to override abstract function and 
> procedures in concrete types and can override concrete functions
> and procedures only as needed.

This is in the AARM 3.9.3(6) [1]. It'ss apparently intended to replace
'type renaming', and (in the comments on AI95-00391 [2]) is described as
'a last minute "quick fix."'.

[1] http://www.ada-auth.org/standards/12aarm/html/AA-3-9-3.html#p6
[2] http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00391.txt?rev=1.9

Re: Strange error message

[Robert A Duff]

Charly <carl.weierstrass@googlemail.com> writes:

> Hi,
>
> when I defined a class hierarchy I encountered a problem, that I could reduce 
> to the following few lines:
>
> This version compiles without problems:
> -----------------
> package Test is
>
>    type Base is tagged private;
>    function Create return Base;
>
>    type High is new Base with private;
>
> private
>
>    type Base is tagged null record;
>
>    type High is new Base with null record;
>
> end Test;
> -----------------
>
> but this one
>
> -----------------
> package Test is
>
>    type Base is tagged private;
>    function Create return Base;
>
>    type High is new Base with private;
>
> private
>
>    type Base is tagged null record;
>
>    type High is new Base with record     --
>       H_Val : Natural := 0;              -- these lines are changed
>    end record;                           --
>
> end Test;
> -----------------
>
> does not compile an I get an error:
>
>    type must be declared abstract or "Create" overridden
>
> Why do I have to overide the function Create for type High.
> I don't see the necessity.

Because whatever Create does, it doesn't set any value for H_Val,
because H_Val doesn't exist in Base.  So it makes no sense to inherit
it as is.  [*] But see below.

In your first version, High adds no new components.  Ada 95 used to
require overriding in that case, too, but the overriding is always:

    function Create return High is
    begin
        return (Base with null record);
    end Create;

What else would it be?  So the language was changed to provide that
overriding by default in the "null record" case.

I don't know why Dmitry and Randy want us to write that out explicitly;
it seems like an obviously useful and safe default.

[*] Your H_Val has a default of 0, so it might make sense to define
the language to provide an automatic default overriding:

    function Create return High is
    begin
        return (Base with H_Val => 0);
    end Create;

That's not how the language is now, and I suspect Dmitry and Randy
would be appalled at the idea.  I don't really understand their
point of view -- I mean, I love consistency and all, but "A FOOLISH
consistency is the hobgloblin... etc".

By the way, Tucker wanted the current rule for Ada 95.  I argued him
out of it.  That is, in 1993 or so, I agreed with Dmitry's and Randy's
current position.  I've since changed my mind.

- Bob

Re: Strange error message

[Dmitry A. Kazakov]

On Sun, 01 Jun 2014 17:18:03 -0400, Robert A Duff wrote:

> Charly <carl.weierstrass@googlemail.com> writes:
> 
>> when I defined a class hierarchy I encountered a problem, that I could reduce 
>> to the following few lines:
>>
>> This version compiles without problems:
>> -----------------
>> package Test is
>>
>>    type Base is tagged private;
>>    function Create return Base;
>>
>>    type High is new Base with private;
>>
>> private
>>
>>    type Base is tagged null record;
>>
>>    type High is new Base with null record;
>>
>> end Test;

> I don't know why Dmitry and Randy want us to write that out explicitly;
> it seems like an obviously useful and safe default.

The first objection is that the legality of inheriting Create in

   type Base is tagged private;
   function Create return Base;

   type High is new Base with private;
 
depends on the private part of the package. This is not good.

The second objection is, if the above is not good then

   type High is new Base with null record;

should make no difference.

---------------
Of course one could argue in favor of the rule that all primitive
operations are in some sense overridden anyway. It is only the way the
bodies are constructed (inherited vs. provided by the user), what makes
difference. I.e. whether

   overriding function Create return High;

appears in the public part of the package or not, that is an implementation
detail uninteresting to the clients. I would agree with that, but it is not
how the language is designed presently.

It is, as always, too late, but probably overriding (with new body) were to
appear strictly in the package body. Then the rule of null extension would
be all OK to me.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Strange error message

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> The first objection is that the legality of inheriting Create in
>
>    type Base is tagged private;
>    function Create return Base;
>
>    type High is new Base with private;
>  
> depends on the private part of the package. This is not good.

Privacy breakage is not good, but there is no privacy breakage here.
Privacy breakage happens when the legality of clients depends on the
contents of the private part.  Here, the legality of the package itself
depends on the contents of the private part (which is always the case!).

Clients can only see the visible part as quoted above.
The private part could be:

    private
       type Base is tagged null record;
       type High is new Base with null record;

or:

    private
       type Base is tagged null record;

       type High is new Base with record
          H_Val : Natural;
       end record;
       overriding function Create return High is
         (Base'(Create) with H_Val => <>);

both of which are legal.  The visible part promises that there
will be a function Create returning High.  The first private part
above accomplishes that by using the one implicitly generated
by the compiler, which looks like this:

       function Create return High is (Base'(Create) with null record);

If you wrote it by hand (as you were required to do in Ada 95), you
would almost certainly write something equivalent.  What else could it
reasonably do?

The compiler can't automatically create Create in the second case,
because it doesn't know what value you want for H_Val.

> The second objection is, if the above is not good then
>
>    type High is new Base with null record;
>
> should make no difference.

Well, since your first objection is invalid, the premise of
your second objection is false.  ;-)

> ---------------
> Of course one could argue in favor of the rule that all primitive
> operations are in some sense overridden anyway. It is only the way the
> bodies are constructed (inherited vs. provided by the user), what makes
> difference. I.e. whether
>
>    overriding function Create return High;
>
> appears in the public part of the package or not, that is an implementation
> detail uninteresting to the clients. I would agree with that, but it is not
> how the language is designed presently.

Not sure what you mean.  You can put the above "overriding..." in the
visible part or the private part, or (in the null record case) leave it
out.  It makes no difference to clients.

> It is, as always, too late, but probably overriding (with new body) were to
> appear strictly in the package body.

Yes, that would make sense.  I suggested that during Ada 9X.  The
reasons not to do that have to do with making compilers easier to write.

In fact, private parts should not exist; that stuff belongs in the body.

>...Then the rule of null extension would
> be all OK to me.

Is it OK with you now, having read my comments above?

- Bob

Re: Strange error message

[Dmitry A. Kazakov]

On Mon, 02 Jun 2014 09:49:13 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> The first objection is that the legality of inheriting Create in
>>
>>    type Base is tagged private;
>>    function Create return Base;
>>
>>    type High is new Base with private;
>>  
>> depends on the private part of the package. This is not good.
> 
> Privacy breakage is not good, but there is no privacy breakage here.
> Privacy breakage happens when the legality of clients depends on the
> contents of the private part.  Here, the legality of the package itself
> depends on the contents of the private part (which is always the case!).

OK

> Is it OK with you now, having read my comments above?

Yes, you convinced me.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Strange error message

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Yes, you convinced me.

Cool!  :-)

Let's see if Randy agrees.

- Bob

Re: Strange error message

[Shark8]

On 02-Jun-14 07:49, Robert A Duff wrote:
> In fact, private parts should not exist; that stuff belongs in the body.

I'm not sure I agree -- it would be the ideal case, yes... but the 
private part can, and should [IMO] be used to convey information that 
isn't, strictly-speaking, required for the specification but /is/ for 
interfacing. eg: the size of a private-type, import, convention, etc.

Granted. virtually all of those are [in Ada 2012] fairly obsolescent 
with the aspect mechanism there are some that are not covered 
(record-representations and enumeration-value specifications come 
immediately to mind).

Re: Strange error message

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcctx84qqgk.fsf@shell01.TheWorld.com...
...
> [*] Your H_Val has a default of 0, so it might make sense to define
> the language to provide an automatic default overriding:
>
>    function Create return High is
>    begin
>        return (Base with H_Val => 0);
>    end Create;
>
> That's not how the language is now, and I suspect Dmitry and Randy
> would be appalled at the idea.  I don't really understand their
> point of view -- I mean, I love consistency and all, but "A FOOLISH
> consistency is the hobgloblin... etc".

Not speaking for others, but my concern with automatically generating Create 
for null records is that it is a maintenance problem. When one later adds a 
component (and you ALWAYS end up adding a component sooner or later), you 
suddenly have to override a bunch of routines. This is extremely annoying, 
because the entire reason (for me at least) for declaring the null record is 
to get the structure (all of the routines that I need to implement) correct 
before I bother with any actual implementation.

You can avoid the problem with a junk component, but that's nasty.

I'd be happy if there was a way for the automatic construction to extend to 
other types as well. The one you suggested would work as well as any. I 
tried to make such a proposal in AI12-0083-1 (in response to a question from 
Adam), but it got approximately 0% support (which is why it's currently on 
the hold of death). I'm surprised that you suddenly are in favor of it now, 
because you surely weren't when we discussed it (or you missed that 
meeting).

                                               Randy.