Pass a serial port as user data in a GTK callback handler?

Pass a serial port as user data in a GTK callback handler?

[hreba]

Hi,

I am new to Ada and still overwhelmed by the complexity of the language.

My actual programming exercise has a GTK GUI, and I want a callback 
handler to communicate through a serial port, so I need to pass the port 
in my user data, which must be of

    type User_Type (<>) is private;

which means it must be nonlimited.

But GNAT.Serial_Communications.Serial_Port is limited:

    type Serial_Port is new Ada.Streams.Root_Stream_Type with private;
    type Root_Stream_Type is abstract tagged limited private;

I tried to pass a reference to the port, and it must be an "access all" 
(because it is not allocated by my, but a preexisting variable (hardware 
resource), as I understand it):

    port: access all GNAT.Serial_Communications.Serial_Port;

But then I get an error message

    "all" is not permitted for anonymous access types.

Is there a solution?
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: Pass a serial port as user data in a GTK callback handler?

[Jeffrey Carter]

On 02/15/2014 04:32 PM, hreba wrote:
>
>     "all" is not permitted for anonymous access types.
>
> Is there a solution?

You should never use anonymous access types if you can avoid them.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: Pass a serial port as user data in a GTK callback handler?

[Niklas Holsti]

On 14-02-16 01:32 , hreba wrote:
> Hi,
> 
> I am new to Ada and still overwhelmed by the complexity of the language.
> 
> My actual programming exercise has a GTK GUI, and I want a callback
> handler to communicate through a serial port, so I need to pass the port
> in my user data, which must be of
> 
>    type User_Type (<>) is private;
> 
> which means it must be nonlimited.
> 
> But GNAT.Serial_Communications.Serial_Port is limited:
> 
>    type Serial_Port is new Ada.Streams.Root_Stream_Type with private;
>    type Root_Stream_Type is abstract tagged limited private;
> 
> I tried to pass a reference to the port, and it must be an "access all"
> (because it is not allocated by my, but a preexisting variable (hardware
> resource), as I understand it):

On my machine (Win 7), the type Serial_Port is declared in
GNAT.Serial_Communications by deriving from
Ada.Streams.Root_Stream_Type, adding a component which refers AIUI to a
Windows "handle". This is definitely a SW object; the HW resource is
hidden beind Windows.

On some bare-machine GNAT port, Serial_Port might be closer to the HW,
but it is no doubt still a stream class, so it will not itself be mapped
to some HW register. It might contain the address of (i.e. a reference
to) a HW register.

Therefore, you should be able to create your own Serial_Port objects on
the stack, on the heap, or statically.

>    port: access all GNAT.Serial_Communications.Serial_Port;
> 
> But then I get an error message
> 
>    "all" is not permitted for anonymous access types.
> 
> Is there a solution?

Give the type a name so that it isn't "anonymous":

   type Port_Ref is access all GNAT.Serial_Communications.Serial_Port;

   port : Port_Ref;

Also remember to mark the actual Serial_Port object as "aliased" so that
you can take its 'Access.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Pass a serial port as user data in a GTK callback handler?

[Dmitry A. Kazakov]

On Sat, 15 Feb 2014 21:32:58 -0200, hreba wrote:

> My actual programming exercise has a GTK GUI, and I want a callback 
> handler to communicate through a serial port, so I need to pass the port 
> in my user data, which must be of

Additionally to other responses.

There cannot be any reason to pass a stream object to GTK signal handler.
It is most certainly wrong to do any I/O from a signal handler, as it would
block the UI.

In some cases the UI may indeed be aware of I/O objects, like a COM port
configuration dialog or cancel button. In these cases there is a larger
object that contains the I/O object usually as a private member.

Specifically to GTK, you should better use smart pointers rather than raw
access types when dealing with callbacks and pass them around. The point
that UI and I/O will run in independent tasks. It is difficult to prevent
dangling pointers otherwise. [I don't consider global variables, of course]

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

Re: Pass a serial port as user data in a GTK callback handler?

[hreba]

On 02/16/2014 04:45 AM, Niklas Holsti wrote:

> Give the type a name so that it isn't "anonymous":
>
>     type Port_Ref is access all GNAT.Serial_Communications.Serial_Port;
>
>     port : Port_Ref;
>
> Also remember to mark the actual Serial_Port object as "aliased" so that
> you can take its 'Access.

It is the first time I stumbled about anonymous types. Looked it up in 
my Ada book (it is in one of the last chapters). Thanks for the 
clarification.
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: Pass a serial port as user data in a GTK callback handler?

[hreba]

On 02/15/2014 10:35 PM, Jeffrey Carter wrote:
> On 02/15/2014 04:32 PM, hreba wrote:
>>
>>     "all" is not permitted for anonymous access types.
>>
>> Is there a solution?
>
> You should never use anonymous access types if you can avoid them.
>

Thanks for the hint.
Looked up "anonymous" only now.
See my reply to Niklas.
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: Pass a serial port as user data in a GTK callback handler?

[hreba]

On 02/16/2014 06:20 AM, Dmitry A. Kazakov wrote:
> On Sat, 15 Feb 2014 21:32:58 -0200, hreba wrote:
>
>> My actual programming exercise has a GTK GUI, and I want a callback
>> handler to communicate through a serial port, so I need to pass the port
>> in my user data, which must be of
>
> Additionally to other responses.
>
> There cannot be any reason to pass a stream object to GTK signal handler.
> It is most certainly wrong to do any I/O from a signal handler, as it would
> block the UI.

So far I am only trying to open/close the port when the window 
opens/closes, or check the availability of /dev/ttyUSB0 upon a button press.

> In some cases the UI may indeed be aware of I/O objects, like a COM port
> configuration dialog or cancel button. In these cases there is a larger
> object that contains the I/O object usually as a private member.

I think this is what I am trying right now.

> Specifically to GTK, you should better use smart pointers rather than raw
> access types when dealing with callbacks and pass them around. The point
> that UI and I/O will run in independent tasks. It is difficult to prevent
> dangling pointers otherwise. [I don't consider global variables, of course]

So I will be back when I have to fight with task programming in Ada, as 
soon as I begin with the real communication part.

I did a fast search without finding a data structure "smart pointer" in 
GObject, GLib or GTK (devhelp), only as part of the C++ language (which 
I don't know). But I am using Ada. Could you give a hint/reference/link 
to that?

-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: Pass a serial port as user data in a GTK callback handler?

[Dmitry A. Kazakov]

On Sun, 16 Feb 2014 13:57:42 -0300, hreba wrote:

>> Specifically to GTK, you should better use smart pointers rather than raw
>> access types when dealing with callbacks and pass them around. The point
>> that UI and I/O will run in independent tasks. It is difficult to prevent
>> dangling pointers otherwise. [I don't consider global variables, of course]
> 
> So I will be back when I have to fight with task programming in Ada, as 
> soon as I begin with the real communication part.
> 
> I did a fast search without finding a data structure "smart pointer" in 
> GObject, GLib or GTK (devhelp), only as part of the C++ language (which 
> I don't know).

GObject and GValue in the case of GTK.

The former is the base type of all GTK widgets. One possible design is that
your custom widget contains the communication object it deals with. The
handlers of the signals pass the access to the widget as the user
parameter. There are means in GTK to ensure that signals from other widgets
(when not children) that pass the widget's pointer around are disconnected
when the widget disappears before the signal emitting widgets do. That
prevents dangling pointers.

A problem with this design is that the widget type in GtkAda is not
limited. You cannot put a limited member into a non-limited widget object.
So you might need a smart pointer again.

In simpler cases you could just allocate the limited object in Initialize
(called from Gtk_New) with new-allocator and keep the returned pointer it
the widget object. In the handler of the widget's Destroy signal you would
do Unchecked_Deallocate on the pointer.

> But I am using Ada. Could you give a hint/reference/link 
> to that?

You use a controlled object derived from Ada.Finalization.Controlled. The
implementation of Finalize does Unchecked_Deallocate on the pointer if the
reference count drops to 0. There are many implementations of this schema
available. But it is not really difficult to do just from scratch.

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

Re: Pass a serial port as user data in a GTK callback handler?

[adambeneschan]

On Saturday, February 15, 2014 3:32:58 PM UTC-8, hreba wrote:
> Hi,
> 
> I am new to Ada and still overwhelmed by the complexity of the language.
> 
> My actual programming exercise has a GTK GUI, and I want a callback 
> handler to communicate through a serial port, so I need to pass the port 
> in my user data, which must be of
> 
>     type User_Type (<>) is private;
> 
> which means it must be nonlimited.
> 
> But GNAT.Serial_Communications.Serial_Port is limited:
> 
>     type Serial_Port is new Ada.Streams.Root_Stream_Type with private;
>     type Root_Stream_Type is abstract tagged limited private;
> 
> I tried to pass a reference to the port, and it must be an "access all" 
> (because it is not allocated by my, but a preexisting variable (hardware 
> resource), as I understand it):
> 
>     port: access all GNAT.Serial_Communications.Serial_Port;
> 
> But then I get an error message
> 
>     "all" is not permitted for anonymous access types.
> 
> Is there a solution?

I agree with everyone else that anonymous access types aren't needed in this case, and you're better off using a named access type or something else.  Having said that, I just wanted to point out something about Ada: all anonymous access types are automatically "access all", i.e. they can refer to aliased variables.  So you could have solved the problem by just removing the "all" keyword.

                                 -- Adam

Re: Pass a serial port as user data in a GTK callback handler?

[adambeneschan]

On Monday, February 17, 2014 8:13:09 AM UTC-8, I wrote:
> On Saturday, February 15, 2014 3:32:58 PM UTC-8, hreba wrote:

> I agree with everyone else that anonymous access types aren't needed in this case, and you're better off using a named access type or something else.  Having said that, I just wanted to point out something about Ada: all anonymous access types are automatically "access all", i.e. they can refer to aliased variables.  So you could have solved the problem by just removing the "all" keyword.

To expound on this a bit, since you mentioned you were overwhelmed by the complexity of the language: This particular inconsistency is there because of backward compatibility.  Ada 83 did not have access types that could point to variables, nor did it have anonymous access types.  Those were added in Ada 95.  The Ada 95 designers decided that since Ada 83 access types didn't have to be implemented as addresses, it was necessary to have some way to distinguish between an access type that could point to a variable and an access type that was required to point to something allocated with "new"; in order not to break existing Ada 83 programs, the "access all" type was added, which I'm sure they hated having to do (adding the extra keyword), but sometimes there just isn't a good solution.  

                                     -- Adam

Re: Pass a serial port as user data in a GTK callback handler?

[Robert A Duff]

adambeneschan@gmail.com writes:

> To expound on this a bit, since you mentioned you were overwhelmed by
> the complexity of the language: This particular inconsistency is there
> because of backward compatibility.  Ada 83 did not have access types
> that could point to variables, nor did it have anonymous access types.
> Those were added in Ada 95.  The Ada 95 designers decided that since
> Ada 83 access types didn't have to be implemented as addresses, it was
> necessary to have some way to distinguish between an access type that
> could point to a variable and an access type that was required to
> point to something allocated with "new"; in order not to break
> existing Ada 83 programs, the "access all" type was added, which I'm
> sure they hated having to do...

We didn't have to do it, and Tucker didn't want to do it, but I
convinced him it was a good idea.  I later realized I was wrong,
too late.  Mea Culpa.

>... (adding the extra keyword)

"all" was already a keyword in Ada 83, so I guess you mean
"adding it to the syntax for access types".

>..., but sometimes
> there just isn't a good solution.

- Bob

Re: Pass a serial port as user data in a GTK callback handler?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc38jhl93l.fsf@shell01.TheWorld.com...
> adambeneschan@gmail.com writes:
>
>> To expound on this a bit, since you mentioned you were overwhelmed by
>> the complexity of the language: This particular inconsistency is there
>> because of backward compatibility.  Ada 83 did not have access types
>> that could point to variables, nor did it have anonymous access types.
>> Those were added in Ada 95.  The Ada 95 designers decided that since
>> Ada 83 access types didn't have to be implemented as addresses, it was
>> necessary to have some way to distinguish between an access type that
>> could point to a variable and an access type that was required to
>> point to something allocated with "new"; in order not to break
>> existing Ada 83 programs, the "access all" type was added, which I'm
>> sure they hated having to do...
>
> We didn't have to do it, and Tucker didn't want to do it, but I
> convinced him it was a good idea.  I later realized I was wrong,
> too late.  Mea Culpa.

Fascinating. I wouldn't consider that wrong; the problem is the 
inconsistency with anonymous access types (which would be easily solved by 
not introducing them in the first place. ;-). What Ada calls general access 
and pool-specific access types ought to be separated somehow.

Requiring the representation of all access types to be the same would force 
pool-specific types to have a worse representation than otherwise 
necessary -- on the U2200, general access types had to include byte-pointers 
(for C compatibility), but pool-specific types could assume word alignment. 
That was a substantial performance difference.

Janus/Ada also uses stronger checking on pool-specific types (for an access 
type using the standard pool, if the value isn't inside the pool, we raise 
an exception rather than trash memory). Can't do that for general access 
types.

I suppose we could have used an aspect for the difference (if we had had 
aspects in 1993), but having legality depend on aspects is always a bit 
dodgy.

                                 Randy.

                                      Randy.

Re: Pass a serial port as user data in a GTK callback handler?

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Fascinating. I wouldn't consider that wrong; the problem is the 
> inconsistency with anonymous access types (which would be easily solved by 
> not introducing them in the first place. ;-). What Ada calls general access 
> and pool-specific access types ought to be separated somehow.

I agree that there is some value in distinguishing general from
pool-specific access types.  But it comes at a cost in language
complexity -- we commonly see programmers getting confused by it.
So I ended up concluding that the language would be better off
(simpler) if all access types were general, and you can't say
"access all".

I also agree that the inconsistency with anonymous access types
exacerbates the problem.  Anonymous access types should be a
simple short-hand for what you get if you declare a named
access type in the usual place.  Unfortunately, they have all
sorts of magical properties (coextensions, dynamic accessibility, etc).

The term "pool-specific" is a misnomer, by the way.  That's also my
fault -- I was momentarily confused into thinking that a "storage pool"
and a "collection" are the same thing.  Perhaps they should be, but
they're not in Ada.

> Requiring the representation of all access types to be the same would force 
> pool-specific types to have a worse representation than otherwise 
> necessary -- on the U2200, general access types had to include byte-pointers 
> (for C compatibility), but pool-specific types could assume word alignment. 
> That was a substantial performance difference.

I don't understand that.  Access types don't need to be C-compatible
unless you say Convention(C).  And anyway, I would expect an int*
on such a machine to be represented by a word-aligned address.
And you can convert from pool-specific to general, so whatever your
representation is, it must allow for that.

> Janus/Ada also uses stronger checking on pool-specific types (for an access 
> type using the standard pool, if the value isn't inside the pool, we raise 
> an exception rather than trash memory). Can't do that for general access 
> types.

At some efficiency cost, you can check for dangling pointers, which
is even better than what you say above.  Well, "better" in catching
bugs, but probably a lot worse in terms of efficiency.

> I suppose we could have used an aspect for the difference (if we had had 
> aspects in 1993), but having legality depend on aspects is always a bit 
> dodgy.

Yes, if the distinction is to be made, I have no problem using the
"access all" syntax for that.

- Bob

Re: Pass a serial port as user data in a GTK callback handler?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc8ut64uao.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> Fascinating. I wouldn't consider that wrong; the problem is the
>> inconsistency with anonymous access types (which would be easily solved 
>> by
>> not introducing them in the first place. ;-). What Ada calls general 
>> access
>> and pool-specific access types ought to be separated somehow.
>
> I agree that there is some value in distinguishing general from
> pool-specific access types.  But it comes at a cost in language
> complexity -- we commonly see programmers getting confused by it.
> So I ended up concluding that the language would be better off
> (simpler) if all access types were general, and you can't say
> "access all".

I see.

> I also agree that the inconsistency with anonymous access types
> exacerbates the problem.  Anonymous access types should be a
> simple short-hand for what you get if you declare a named
> access type in the usual place.  Unfortunately, they have all
> sorts of magical properties (coextensions, dynamic accessibility, etc).

Not just the magical properties, but also the simple fact that you can't 
even make them *look* the same. I wanted to allow/encourage "all" in their 
syntax in order that they at least *look* like general access types, making 
the existing syntax obsolescent. But I didn't get much support for that. So 
now we have the weird situation that you have to have "all" to use 'Access 
with a named access type, but you must NOT use "all" with an anonymous 
access type. Bah!

> The term "pool-specific" is a misnomer, by the way.  That's also my
> fault -- I was momentarily confused into thinking that a "storage pool"
> and a "collection" are the same thing.  Perhaps they should be, but
> they're not in Ada.

Yeah, you got rid of the term collection in Ada 95, and we just now put it 
back in Ada 2012. So I think you were confused for a fairly long moment - a 
bit under 17 years. :-)

If we had left it around, things would be better.

Note that pool-specific access types are a bit safer in general, because you 
can (with effort, admittedly not usually done) make deallocation safe. 
Whereas with general access, even if you have a valid (non-dangling) access 
object, you can't figure out whether it is safe (and necessary) to 
deallocate it or if you should just drop it on the floor. And if you get 
that wrong, you have storage leaks or erroneous execution.

At least in Ada 2012 you can create a convinient smart pointer abstraction 
that takes care of all of that. Probably we ought to have considered adding 
such a thing to the standard library.

>> Requiring the representation of all access types to be the same would 
>> force
>> pool-specific types to have a worse representation than otherwise
>> necessary -- on the U2200, general access types had to include 
>> byte-pointers
>> (for C compatibility), but pool-specific types could assume word 
>> alignment.
>> That was a substantial performance difference.
>
> I don't understand that.  Access types don't need to be C-compatible
> unless you say Convention(C).

That's true in theory, but as a practical matter trying to force alignment 
on I/O was too expensive to contemplate. Unfortunately, practice can screw 
up a lot of otherwise good ideas.

>  And anyway, I would expect an int*
> on such a machine to be represented by a word-aligned address.

You'd be wrong about that. They tried that, and no existing C code 
(especially Unix) would work. That's one of those functional requirements 
that don't show up in a language standard. They ended up making all C 
pointers byte-pointers. And of course we had to interface to that existing 
compiler, especially since our target was their POSIX emulation (as opposed 
to their raw OS).

> And you can convert from pool-specific to general, so whatever your
> representation is, it must allow for that.

Yes, but that's easy: just add a byte pointer to byte 0. Converting in the 
other direction is not possible in general, because dropping a non-zero 
byte-pointer would lead to reading and writing the wrong memory.

>> Janus/Ada also uses stronger checking on pool-specific types (for an 
>> access
>> type using the standard pool, if the value isn't inside the pool, we 
>> raise
>> an exception rather than trash memory). Can't do that for general access
>> types.
>
> At some efficiency cost, you can check for dangling pointers, which
> is even better than what you say above.  Well, "better" in catching
> bugs, but probably a lot worse in terms of efficiency.

Right. We couldn't of course do that in our Z-80 compiler (this check was 
inserted essentially at day 1 for Janus/Ada, because we were having a lot of 
trouble with uninitialized pointers). It's probably less useful now than it 
once was (the heap being a fairly large part of the address space), but I've 
never wanted to lose functionality going forward.

>> I suppose we could have used an aspect for the difference (if we had had
>> aspects in 1993), but having legality depend on aspects is always a bit
>> dodgy.
>
> Yes, if the distinction is to be made, I have no problem using the
> "access all" syntax for that.

But it sure would help if named and anonymous access used the same syntax. 
:-)

                         Randy.

Re: Pass a serial port as user data in a GTK callback handler?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Note that pool-specific access types are a bit safer in general,
> because you can (with effort, admittedly not usually done) make
> deallocation safe.  Whereas with general access, even if you have a
> valid (non-dangling) access object, you can't figure out whether it is
> safe (and necessary) to deallocate it or if you should just drop it on
> the floor. And if you get that wrong, you have storage leaks or
> erroneous execution.
>
> At least in Ada 2012 you can create a convinient smart pointer
> abstraction that takes care of all of that. Probably we ought to have
> considered adding such a thing to the standard library.

Most of the component libraries that started life with Ada 95 include
smart pointers. I must admit that my effort wasn't convenient or very
safe (access values were visible, and the user was expected not to
deallocate them).

Re: Pass a serial port as user data in a GTK callback handler?

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Yeah, you got rid of the term collection in Ada 95, and we just now put it 
> back in Ada 2012. So I think you were confused for a fairly long moment - a 
> bit under 17 years. :-)

;-)

No, not that long.  I don't remember when I was confused, and when
I wised up, but I just didn't bother to reinstate "collection"
when I wised up.

> You'd be wrong about that. They tried that, and no existing C code 
> (especially Unix) would work.

Interesting.  Such C code is broken (or at least deliberately written
to be nonportable).  It doesn't surprise me.

> But it sure would help if named and anonymous access used the same syntax. 
> :-)

Agreed.

- Bob