Access procedure to pointer

Access procedure to pointer

[Sébastien]

Hi,

I need to convert an access to a procedure to a pointer 
(System.Address). I can't use the System.Address_To_Access_Conversions 
package since I can't define a type on a procedure (only on a procedure 
access).

Is there any way to do it?

Thanks,
Sebastien

Re: Access procedure to pointer

[Ludovic Brenta]

procedure Foo;

Access_Foo : constant access procedure := Foo'Access;

Foo_Address : constant System.Address := Foo'Address;
Foo_Address : constant System.Address := Access_Foo.all'Address;

HTH

--
Ludovic Brenta.

Re: Access procedure to pointer

[Sébastien]

Ludovic Brenta a �crit :
> procedure Foo;
> 
> Access_Foo : constant access procedure := Foo'Access;
> 
> Foo_Address : constant System.Address := Foo'Address;
> Foo_Address : constant System.Address := Access_Foo.all'Address;
> 

It was refused by the compiler, "subtype mark is required here".

I succeed using an unchecked conversion, looks like access to a 
procedure has the same size than System.address since I didn't get any 
warning.

Sebastien

Re: Access procedure to pointer

[Dmitry A. Kazakov]

On Tue, 27 May 2008 17:45:25 +0000, in comp.lang.ada you wrote:

> Ludovic Brenta a �crit :
>> procedure Foo;
>> 
>> Access_Foo : constant access procedure := Foo'Access;
>> 
>> Foo_Address : constant System.Address := Foo'Address;
>> Foo_Address : constant System.Address := Access_Foo.all'Address;
>> 
> 
> It was refused by the compiler, "subtype mark is required here".

Egh? It the following should work:

   procedure Foo;
   pragma Convention (C, Foo); -- You deal with C, right?
   Ptr : constant Address := Foo'Address;

> I succeed using an unchecked conversion, looks like access to a 
> procedure has the same size than System.address since I didn't get any 
> warning.

I would suggest a cleaner:

   type Callback is access procedure;
   pragma Convention (C, Callback);
   
   procedure Foo;
   pragma Convention (C, Foo);
   
   Ptr : constant Callback := Foo'Access;

Callback is an equivalent to C pointer to a function.

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

Re: Access procedure to pointer

[Sébastien]

> I would suggest a cleaner:
> 
>    type Callback is access procedure;
>    pragma Convention (C, Callback);
>    
>    procedure Foo;
>    pragma Convention (C, Foo);
>    
>    Ptr : constant Callback := Foo'Access;
> 
> Callback is an equivalent to C pointer to a function.

The point was I'm not using constant.

My code looks like this:


type Signal is (SIGHUP);
for Signal use (SIGHUP => 1);

type Signal_Callback is access procedure(sig: Signal);

procedure InterceptSignal(sig: in Signal; callback: in Signal_Callback);

procedure c_signal(sig: in Signal; callback: in System.Address);
pragma Import(C, c_signal, "signal");

procedure HelloFromSignal(sig: Signal) is
begin
	Put_Line("Hello from" & Signal'Image(sig));
end HelloFromSignal;

procedure Main is
begin
	InterceptSignal(SIGUP, HelloFromSignal'Access);
	delay 30;
end Main;

So I change the code following your instruction :
procedure c_signal(sig: in Signal; callback: in Signal_Callback);

And did add all the pragma Contention where you told me. It works fine 
and looks like more portable ;-) Thanks for all your answers and help.

Moreover, I discover that sigaction and other Signal function are 
implemented in Gnat 4.3 in the System.OS_Interface. Even if "signal" 
itself is missing, there is some ways to do it without any C interface 
in my code.

Really documentation is missing about what is available in GNAT and 
examples, too bad!

Sebastien

Re: Access procedure to pointer

[Jean-Pierre Rosen]

S�bastien a �crit :

> type Signal is (SIGHUP);
> for Signal use (SIGHUP => 1);
> 
> type Signal_Callback is access procedure(sig: Signal);
> 
> procedure InterceptSignal(sig: in Signal; callback: in Signal_Callback);
> 
> procedure c_signal(sig: in Signal; callback: in System.Address);
> pragma Import(C, c_signal, "signal");
> 
Why don't you simply use Ada.Interrupts?
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Access procedure to pointer

[Sébastien]

> Why don't you simply use Ada.Interrupts?

Two reasons:
1) It didn't know it exists
2) It's not documented, and not intuitive, no example nothing to start.

As a matter of fact, the first problem is solved ;-), if you any help 
about the second problem, I'll be happy to use standard package instead 
of mine.

Sebastien

Re: Access procedure to pointer

[Jean-Pierre Rosen]

S�bastien a �crit :
>> Why don't you simply use Ada.Interrupts?
> 
> Two reasons:
> 1) It didn't know it exists
> 2) It's not documented, and not intuitive, no example nothing to start.
> 
> As a matter of fact, the first problem is solved ;-), if you any help 
> about the second problem, I'll be happy to use standard package instead 
> of mine.
> 
Well, it is documented in the reference manual, and a quick search for 
the word "interrupt" in the index would have put you right there...

However, I think this is an interesting example. I guess the OP simply 
thought "oh, I must handle interrupts, therefore I must interface with 
the system - i.e. use C)", he didn't even imagine that it was provided 
out of the box...

Short answer: to attach statically:
    pragma Attach_Handler (PO.P, Interrupt_Number);

to attach dynamically:
    Ada.Interrupts.Attach_Handler (PO.P'Access, Interrupt_Number);

Note that the handler must be a *protected* procedure (i.e. a procedure 
declared in a protected type), to model the non-reentrant nature of 
interrupt handlers.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Access procedure to pointer

[Jeffrey R. Carter]

Jean-Pierre Rosen wrote:
>
> Well, it is documented in the reference manual, and a quick search for 
> the word "interrupt" in the index would have put you right there...
> 
> However, I think this is an interesting example. I guess the OP simply 
> thought "oh, I must handle interrupts, therefore I must interface with 
> the system - i.e. use C)", he didn't even imagine that it was provided 
> out of the box...

I suspect the OP wasn't looking for "interrupt"; he was looking for "signal". 
What a signal is, and whether it's the same as an interrupt, is highly platform- 
and compiler-dependent. About all you can say is an interrupt handler works for 
GNAT/Linux.

-- 
Jeff Carter
"My dear Mrs. Hemoglobin, when I first saw you, I
was so enamored with your beauty I ran to the basket,
jumped in, went down to the city, and bought myself a
wedding outfit."
Never Give a Sucker an Even Break
111

Re: Access procedure to pointer

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Jean-Pierre Rosen wrote:
>>
>> Well, it is documented in the reference manual, and a quick search for
>> the word "interrupt" in the index would have put you right there...
>> However, I think this is an interesting example. I guess the OP simply
>> thought "oh, I must handle interrupts, therefore I must interface with
>> the system - i.e. use C)", he didn't even imagine that it was provided
>> out of the box...
>
> I suspect the OP wasn't looking for "interrupt"; he was looking for
> "signal". What a signal is, and whether it's the same as an interrupt,
> is highly platform-
> and compiler-dependent. About all you can say is an interrupt handler
> works for GNAT/Linux.

And "signal" appears in the index, too (it says "see interrupt C.3(1)"
among other things).  When I made that index, I tried to think of every
synonym of every term somebody might want to look up.

You shouldn't have to know Ada terminology by heart in order to find
things in the Ada manual!

- Bob

Re: Access procedure to pointer

[Adam Beneschan]

On May 28, 8:26 am, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> Sébastien a écrit :>> Why don't you simply use Ada.Interrupts?
>
> > Two reasons:
> > 1) It didn't know it exists
> > 2) It's not documented, and not intuitive, no example nothing to start.
>
> > As a matter of fact, the first problem is solved ;-), if you any help
> > about the second problem, I'll be happy to use standard package instead
> > of mine.
>
> Well, it is documented in the reference manual, and a quick search for
> the word "interrupt" in the index would have put you right there...

Right, but the reference manual doesn't say that "interrupts" are
"Unix signals", even on a Unix-like system, which is to be expected,
since this is a highly implementation-dependent matter and the RM
can't be expected to speak on what "interrupts" mean in a particular
implementation.  So the RM can't be expected to help solve Sebastien's
problem at all.  I'd think that GNAT documentation *would* give an
answer to this, but a quick search of the GNAT documentation that I
found on AdaCore's site didn't say anything about what the
"interrupts" in Ada.Interrupts refer to.  I may not have been looking
in the right place, though.  I did find the .ads file that defines the
Ada.Interrupts.Names spec in GNAT's runtime, and that did make it
clear that "interrupts" are Unix (or Linux or something) signals.

                                 -- Adam

Re: Access procedure to pointer

[Sebastien Morand]

> Right, but the reference manual doesn't say that "interrupts" are
> "Unix signals", even on a Unix-like system, which is to be expected,
> since this is a highly implementation-dependent matter and the RM
> can't be expected to speak on what "interrupts" mean in a particular
> implementation.  So the RM can't be expected to help solve Sebastien's
> problem at all.  I'd think that GNAT documentation *would* give an
> answer to this, but a quick search of the GNAT documentation that I
> found on AdaCore's site didn't say anything about what the
> "interrupts" in Ada.Interrupts refer to.  I may not have been looking
> in the right place, though.  I did find the .ads file that defines the
> Ada.Interrupts.Names spec in GNAT's runtime, and that did make it
> clear that "interrupts" are Unix (or Linux or something) signals.

Completly agree. Actually I'm not so sure I have the right link to the manual 
you all speak about :-)

There is so many packages in my adainclude directory, that make me sick not to 
know what is inside ;-)

Sebastien

Re: Access procedure to pointer

[Jeffrey R. Carter]

Sebastien Morand wrote:
> 
> Completly agree. Actually I'm not so sure I have the right link to the 
> manual you all speak about :-)

The current ARM is at

http://www.adaic.org/standards/05rm/html/RM-TOC.html

The Ada-95 RM is at

http://www.adaic.org/standards/95lrm/html/RM-TTL.html

Most Ada-related standards are at

http://www.adaic.org/standards/

-- 
Jeff Carter
"My dear Mrs. Hemoglobin, when I first saw you, I
was so enamored with your beauty I ran to the basket,
jumped in, went down to the city, and bought myself a
wedding outfit."
Never Give a Sucker an Even Break
111

Re: Access procedure to pointer

[Sébastien]

> The current ARM is at
> 
> http://www.adaic.org/standards/05rm/html/RM-TOC.html
> 
> The Ada-95 RM is at
> 
> http://www.adaic.org/standards/95lrm/html/RM-TTL.html
> 
> Most Ada-related standards are at
> 
> http://www.adaic.org/standards/

Ok I use it really often then. Sorry if I'm a bit rude but you can easly 
find POSIX signal implementation in ada in this document.

Ok there is the Signal reference in index "See interrups".

But the first sentence of C.3 is:
"This clause specifies the language-defined model for hardware 
interrupts in addition to mechanisms for handling interrupts."

I was not looking for hardware interruption. To me it sounds like int21 
(DOS) int33 (mouse) and so on that I was used to program on my 286 12 
years ago. But that's not what I was looking for. As ada is often used 
for embeded, it's not surprising to me to find out such a package, and I 
move on because that's not what I was looking for.

Now there is another point I want to come up: It's formal description 
about ada, and that's not so easly to understand even If I'm used of 
this kind of description, an example is always better and then you can 
go deeper with formal description (and I could understand it's not the 
purpose of the document)

I think the wikibook is the first entry point for new user in ada and 
package sould be documented with examples as much as possible. Most of 
them are named but with no description (Notice: I understand it's a hard 
job to do it and people can run out of time! And it's really a great 
effort to have such a wikibook!)

Sebastien

Re: Access procedure to pointer

[Jeffrey R. Carter]

S�bastien wrote:
> 
> Ok I use it really often then. Sorry if I'm a bit rude but you can easly 
> find POSIX signal implementation in ada in this document.
> 
> Ok there is the Signal reference in index "See interrups".
> 
> But the first sentence of C.3 is:
> "This clause specifies the language-defined model for hardware 
> interrupts in addition to mechanisms for handling interrupts."

I agree. This is a tough area; what constitutes and interrupt is highly 
compiler- and platform-dependent. The ARM does a decent job of defining a 
platform-independent approach to interrupt handling, but is not a good source 
for solutions to platform-dependent concepts such as POSIX signals.

However, the index reference "see interrupts" should indicate that (on some 
platforms, at least) "signal" is a synonym for "interrupt" and that in those 
cases C.3 applies to them as well. From there you might discover the existence 
of Ada.Interrupts.Names, and look at its implementation for your compiler, and 
there find SIGHUP as one of the names.

Then again, the ARM is not the most easily read document, and you might not (and 
didn't). The Ada-83 RM, while less formal and precise, was much more readable, 
and Ada-83 developers often referred to it. Many of us still like to refer to 
the ARM. Other sources might be better for others. Many people use the AARM, but 
it's not really any better for your problem.

-- 
Jeff Carter
"Unix and C are the ultimate computer viruses."
Richard Gabriel
99

Re: Access procedure to pointer

[Jean-Pierre Rosen]

Sebastien Morand a �crit :
> There is so many packages in my adainclude directory, that make me sick 
> not to know what is inside ;-)
> 
Sigh... and to think that so many people complain that there are not 
enough predefined packages in standard Ada!

OTOH, I doubt anybody in the world knows exactly what's delivered with 
Java...

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Access procedure to pointer

[Sébastien]

> Sigh... and to think that so many people complain that there are not 
> enough predefined packages in standard Ada!
> 
> OTOH, I doubt anybody in the world knows exactly what's delivered with 
> Java...

Javadoc is pretty well done, there is a lot of bad things about java 
(and a lot good) but about documentation, it easy to get inside ;-)

Re: Access procedure to pointer

[Jean-Pierre Rosen]

S�bastien a �crit :
>> Sigh... and to think that so many people complain that there are not 
>> enough predefined packages in standard Ada!
>>
>> OTOH, I doubt anybody in the world knows exactly what's delivered with 
>> Java...
> 
> Javadoc is pretty well done, there is a lot of bad things about java 
> (and a lot good) but about documentation, it easy to get inside ;-)

It's not exactly what I meant. Once you know a function, I agree it is 
pretty easy to find out what it does. But there are so many of them that 
it is difficult to know whether you already have a class that does what 
you want...

I suspect that most people have a small set of favorite classes, and 
rewrite all the rest on top of them, even if there are predefined 
classes to do the job. People more knowledgeables in Java are welcome to 
support or refute this statement...
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Access procedure to pointer

[Stephen Leake]

Sebastien Morand <seb.morand@gmail.com> writes:

> There is so many packages in my adainclude directory, that make me
> sick not to know what is inside ;-)

You could read the .ads files. They are well written and concise. I
don't see what other form of documentation would be much better. 

You mention javadoc in another post. That's just a massaged form of
comments and code from java source code. In java, that makes sense,
because there is no separation of interface from implementation (no
analogy of .ads vs .adb). So reading the java source files is tedious
and confusing, if all you want is a list of functions you could call.

For Ada, that's simply not necessary; .ads files serve the same
purpose, without needing a separate tool. 

You _know_ the .ads files are accurate (the code parts, anyway :) and
up-to-date; you don't know that with javadoc output.

-- 
-- Stephe

Re: Access procedure to pointer

[Sébastien]

> You could read the .ads files. They are well written and concise. I
> don't see what other form of documentation would be much better. 

I can and I do, but just because I don't have any choice. Of course Ada 
is easy to read, but there is no hyperlink navigation, this is quite 
boring. For instance you find out a function, let's say the 
documentation is clear, yes but ada is strongly typed and then have a 
lot of new type in order to assure safety and quality of the code. So 
you have then to find the definition of the type and so on...

Documentation is the most important part of any technology. Even if Ada 
code is well documented, a user friendly version of the documentation 
easy to read and to navigate will be a better way to promote the 
language and help new developer. If your technology is reliable, well 
designed but with no documentation, don't even try to promote it in 
professional world, it will be a waste of time.

> You mention javadoc in another post. That's just a massaged form of
> comments and code from java source code. In java, that makes sense,
> because there is no separation of interface from implementation (no
> analogy of .ads vs .adb). So reading the java source files is tedious
> and confusing, if all you want is a list of functions you could call.
> 
> For Ada, that's simply not necessary; .ads files serve the same
> purpose, without needing a separate tool. 

I completly disagree, even if ada source code is far easier to read than 
any other language. See remarks above.

Moreover, a document should hide the implementation detail in order to 
be clearer and more concise. In ada, ads and adb are often in the same 
directory in all installation I tried, so it's not really helping.

Moreover no documentation means no index or any stuff like that, no 
search form to find all the files that could be usefull for you. At 
least, the name of the file in ada distribution are not really 
meaningful, s-interr.ads does not mean anything to me.

Re: Access procedure to pointer

[Georg Bauhaus]

S�bastien schrieb:
>> You could read the .ads files. They are well written and concise. I
>> don't see what other form of documentation would be much better. 
> 
> I can and I do, but just because I don't have any choice. Of course Ada 
> is easy to read, but there is no hyperlink navigation, this is quite 
> boring.

Load the sources into your favorite IDE. You will then have
navigation. IMHO  computers can be more helpful at a level
above the file system level.

If you can make good use of AdaCore's GNAT library (which works
with GNAT), it is probably best to ask their support whether
or not they can add separate documentation. OTOH, GNAT is
free software, everyone could contribute his or her thoughts
about the library, its use, or its implementation.

The Ada library is documented elsewhere.
Doesn't a browsing style of learning a library have
its counterpart in a scribbling approach to programming?

Re: Access procedure to pointer

[Jeffrey R. Carter]

S�bastien wrote [concerning the GNAT adainclude directory]:
>> You could read the .ads files. They are well written and concise. I
>> don't see what other form of documentation would be much better. 
> 
> I can and I do, but just because I don't have any choice. Of course Ada 
> is easy to read, but there is no hyperlink navigation, this is quite 
> boring. For instance you find out a function, let's say the 
> documentation is clear, yes but ada is strongly typed and then have a 
> lot of new type in order to assure safety and quality of the code. So 
> you have then to find the definition of the type and so on...

The a-*.ad? files are the standard library (package Ada and its descendants) and 
its implementation. These are well documented in the ARM, primarily Annex A. 
This is readable and the online version is hyperlinked.

The i-*.ad? files are package Interfaces and its descendants, and their 
implementation. These are also well documented in the ARM, Annex B.

The s-*.ad? files are package System and its descendants, and their 
implementation. These are also documented in the ARM, section 13.

The g-*.ad? files are GNAT-specific units. Some are for general use and some are 
GNAT internal units. Documentation is up to the compiler supplier.

-- 
Jeff Carter
"He didn't get that nose from playing ping-pong."
Never Give a Sucker an Even Break
110

Re: Access procedure to pointer

[Pascal Obry]

Jeffrey R. Carter a �crit :
> The g-*.ad? files are GNAT-specific units. Some are for general use and 
> some are GNAT internal units. Documentation is up to the compiler supplier.

And they are described into the GNAT Reference Manual. But who read a 
manual those days :)

Note also that they are all listed into the GPS's
[Help] -> [GNAT Runtime] menu.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Access procedure to pointer

[Sébastien Morand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> The a-*.ad? files are the standard library (package Ada and its
> descendants) and its implementation. These are well documented in the
> ARM, primarily Annex A. This is readable and the online version is
> hyperlinked.
> 
> The i-*.ad? files are package Interfaces and its descendants, and their
> implementation. These are also well documented in the ARM, Annex B.
> 
> The s-*.ad? files are package System and its descendants, and their
> implementation. These are also documented in the ARM, section 13.
> 
> The g-*.ad? files are GNAT-specific units. Some are for general use and
> some are GNAT internal units. Documentation is up to the compiler supplier.

Ok for theses pieces of information. Actually I was not trying to
polemic, and I apologize if I did. The matter is:
- - Ada is a really beautiful language if a lot of feature included,
well-designed
- - There is not a lot of people out there thinking that Ada could be an
industrial language in other domain is used to be. I'm not a simple
developer at home trying to get fun coding. I'm working in a big company
and I can see people reacting when I talking about Ada or trying to
explain why I will choose ada if I could as a programming language.

The question is how to help promoting Ada? Clear and visible
documentation is one of the key. ARM is far easy to understand, with no
example, no remarks about usage. It's a formal description reserved for
people which are looking some precision or are used to this kind of
documentation, but knowing what they are looking for! No documentation
could replace ARM, we agree about that. But I think and effort such the
wikibook is really what Ada is missing most.

Tomorrow if I'm asked to show what ada can do, I can't show him what is
in this wikibook and nothing else, and a lot are missing (not meaning
people writing wikibook are doing bad job!!!) but let's be honest about it.

I'm quite busy at work in this moment, but I'll be happy to help in a
few weeks to help in this effort.

Anyway, I thank all people on this forum who answer quite fast to all
the questions asked by new people with good explanation and good
references to documentation.

Sebastien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFIRReJ+zV9xm4PlDQRAvntAJ9VxFBQvsLbwom2wYcet/BpxQhLhwCdGNJ0
dKJCCV+jgQWX2HyzuX5186w=
=J4UT
-----END PGP SIGNATURE-----

Re: Access procedure to pointer

[Ed Falis]

On Tue, 03 Jun 2008 06:06:01 -0400, Sébastien Morand  
<seb.morand@gmail.com> wrote:
...
> Tomorrow if I'm asked to show what ada can do, I can't show him what is
> in this wikibook and nothing else, and a lot are missing (not meaning
> people writing wikibook are doing bad job!!!) but let's be honest about  
> it.

See the papers here:
http://www.adacore.com/category/developers-center/reference-library/technical-papers

and the Ada Gems series at:

http://www.adacore.com/category/developers-center/gems/

They might help a bit.

Re: Access procedure to pointer

[Stephen Leake]

S�bastien <seb.morand@gmail.com> writes:

>> You could read the .ads files. They are well written and concise. I
>> don't see what other form of documentation would be much better. 
>
> I can and I do, but just because I don't have any choice. Of course
> Ada is easy to read, but there is no hyperlink navigation, 

As others have mentioned, any decent Ada IDE will provide hyperlinks
from the source. If the IDE can parse the GNAT .ali files, so much the
better. 

> this is quite boring. For instance you find out a function, let's
> say the documentation is clear, yes but ada is strongly typed and
> then have a lot of new type in order to assure safety and quality of
> the code. So you have then to find the definition of the type and so
> on...

Yes. In Emacs Ada mode, that's what C-c C-d is for.

> Documentation is the most important part of any technology. 

Only for people who haven't learned it yet :).

>> You mention javadoc in another post. That's just a massaged form of
>> comments and code from java source code. In java, that makes sense,
>> because there is no separation of interface from implementation (no
>> analogy of .ads vs .adb). So reading the java source files is tedious
>> and confusing, if all you want is a list of functions you could call.
>> For Ada, that's simply not necessary; .ads files serve the same
>> purpose, without needing a separate tool. 
>
> I completly disagree, even if ada source code is far easier to read
> than any other language. See remarks above.

The only thing you mentioned that javadoc has that plain Ada source
doesn't have is hyperlinks; that's a solved problem.

> Moreover, a document should hide the implementation detail in order to
> be clearer and more concise. In ada, ads and adb are often in the same
> directory in all installation I tried, so it's not really helping.

Hmm. I guess if you grep *.ad? that would be a problem. But that's
what grep *.ads is for. Why, specifically, is it a problem that the
*.ads and *.adb are in the same directory?

> Moreover no documentation means no index or any stuff like that, 

True, no index. Others have pointed out that the GNAT manual does have
an index for the GNAT packages that are supposed to be available to
the user. As Robert Dewar would say "please read the super-secret
documentation". 

> no search form to find all the files that could be usefull for you.

grep "foo" *.ads ?

What, specifically, is wrong with that?

> At least, the name of the file in ada distribution are not really
> meaningful, s-interr.ads does not mean anything to me.

That's true. That one you'll have to blame on Bill Gates, not Ada or
AdaCore. Although I think it's time AdaCore gave up ISO CDROM
compatibility and convert to long file names.

You can run gnatchop on the files to get long filenames, but that's
cheating. 

-- 
-- Stephe

Re: Access procedure to pointer

[Adam Beneschan]

On May 30, 10:52 pm, Stephen Leake <Stephe.Le...@nasa.gov> wrote:
> Sebastien Morand <seb.mor...@gmail.com> writes:
> > There is so many packages in my adainclude directory, that make me
> > sick not to know what is inside ;-)
>
> You could read the .ads files. They are well written and concise.

Yes, and the file names are especially concise.  What a joy to look at
a directory listing of a directory containing 1,070 Ada sources all
with names like i-forbla.ads and trying to figure out which one you
need to look at to get your question answered.

> I don't see what other form of documentation would be much better.

Something, somewhere, that describes how the package works, in English
(or maybe French, in Sebastien's case), and with a index so that you
can find what you're looking for.

Suppose you wanted to ask, "Does the GNAT library have a facility for
handling UNIX signals?"  The first place I'd look is in the manuals,
either searching for "signal" or looking in the index for it.  If,
instead, I tried to use grep to search the .ads files for references
to "signal", I'd find there are 27 of them, and in all probability I'd
probably start by looking at g-signal.ads since that looks the most
promising.  That would probably lead to nowhere, unless maybe I could
guess what to do next.

But I think the idea that a library vendor can just release the
sources of the package specifications and assume that will be enough
documentation, is just plain wrong.

                                -- Adam

Re: Access procedure to pointer

[Jean-Pierre Rosen]

Adam Beneschan a �crit :
> On May 30, 10:52 pm, Stephen Leake <Stephe.Le...@nasa.gov> wrote:
>> Sebastien Morand <seb.mor...@gmail.com> writes:
>>> There is so many packages in my adainclude directory, that make me
>>> sick not to know what is inside ;-)
>> You could read the .ads files. They are well written and concise.
> 
> Yes, and the file names are especially concise.  What a joy to look at
> a directory listing of a directory containing 1,070 Ada sources all
> with names like i-forbla.ads and trying to figure out which one you
> need to look at to get your question answered.
> 
No, you would access it from the Help/Gnat-runtime menu of GPS, which 
gives perfectly readable names, and that would load it in a GPS window 
which provides full references for any element.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Access procedure to pointer

[Stephen Leake]

Adam Beneschan <adam@irvine.com> writes:

> But I think the idea that a library vendor can just release the
> sources of the package specifications and assume that will be enough
> documentation, is just plain wrong.

GNAT is free software. Perhaps someone could contribute an index in a
useful form.

Apparently AdaCore's customers find the current situation acceptable;
they are footing the bill, after all.

-- 
-- Stephe

Re: Access procedure to pointer

[Sébastien]

> 2) It's not documented, and not intuitive, no example nothing to start.
> 
> As a matter of fact, the first problem is solved ;-), if you any help 
> about the second problem, I'll be happy to use standard package instead 
> of mine.

I answer to my own question. Here is a sample code it works fine:

    package AdaInterrupsTest is

       protected Test is
          procedure TestHandler;
          pragma Interrupt_Handler(TestHandler);
       end Test;

    end AdaInterrupsTest;

    package body AdaInterrupsTest is

       protected body Test is
          procedure TestHandler is
          begin
             Put_Line("Hello from test");
          end TestHandler;
       end Test;

    end AdaInterrupsTest;

    procedure TestAdaInterrupt is
       use AdaInterrupsTest;
       use Ada.Interrupts;
       use Ada.Interrupts.Names;
    begin
       Attach_Handler(Test.TestHandler'Access, SIGHUP);
       delay 30.0;
    end TestAdaInterrupt;

Then get the pid before the end of the delay and then kill -1 <pid> give 
me "Hello from test" on stdout

Thanks about the tip

Sebastien

Re: Access procedure to pointer

[Simon Wright]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> S�bastien a �crit :
>
>> type Signal is (SIGHUP);
>> for Signal use (SIGHUP => 1);
>>
>> type Signal_Callback is access procedure(sig: Signal);
>>
>> procedure InterceptSignal(sig: in Signal; callback: in Signal_Callback);
>>
>> procedure c_signal(sig: in Signal; callback: in System.Address);
>> pragma Import(C, c_signal, "signal");
>>
> Why don't you simply use Ada.Interrupts?

Perhaps because interrupts are not signals? (of course GNAT maps
signals to interrupts for 'complex' targets eg Linux, Windows and I
believe Mac OS X, but on VxWorks interrupts are interrupts and signals
are another matter altogether!)

Re: Access procedure to pointer

[Jeffrey R. Carter]

S�bastien wrote:
> Ludovic Brenta a �crit :
>> procedure Foo;
>>
>> Access_Foo : constant access procedure := Foo'Access;
>>
>> Foo_Address : constant System.Address := Foo'Address;
>> Foo_Address : constant System.Address := Access_Foo.all'Address;
> 
> It was refused by the compiler, "subtype mark is required here".

Required where? If at "constant access procedure", then perhaps your compiler 
doesn't implement this feature of the new standard yet, in which case

type Foo_Ptr is access procedure;

Access_Foo : constant Foo_Ptr := Foo'Access;

Should work.

> I succeed using an unchecked conversion, looks like access to a 
> procedure has the same size than System.address since I didn't get any 
> warning.

This is highly compiler dependent. Even if they have the same size, there's no 
guarantee that they have the same representation.

-- 
Jeff Carter
"What's the amount of the insult?"
Never Give a Sucker an Even Break
104

Re: Access procedure to pointer

[Adam Beneschan]

On May 27, 10:45 am, Sébastien <seb.mor...@gmail.com> wrote:
> Ludovic Brenta a écrit :
>
> > procedure Foo;
>
> > Access_Foo : constant access procedure := Foo'Access;
>
> > Foo_Address : constant System.Address := Foo'Address;
> > Foo_Address : constant System.Address := Access_Foo.all'Address;
>
> It was refused by the compiler, "subtype mark is required here".

Where?  If it's complaining about "constant access procedure", that's
an Ada 2005 construct that some compilers may not yet handle.  In any
case, that's not the point.  It sounded from your original post that
you might already have an access-to-procedure object, and Ludovic just
gave an example of what your declaration might look like, I think.
But if you already have an access-to-procedure object X, just use
X.all'Address, however you declare the type of X.  If you don't have
one, you don't need to create one just to get the procedure address.


> I succeed using an unchecked conversion, looks like access to a
> procedure has the same size than System.address since I didn't get any
> warning.

Don't count on this always being the case.  Access-to-procedures often
have to carry extra information besides just the address.

                               -- Adam

Re: Access procedure to pointer

[Jeffrey R. Carter]

S�bastien wrote:
> 
> I need to convert an access to a procedure to a pointer 
> (System.Address). I can't use the System.Address_To_Access_Conversions 
> package since I can't define a type on a procedure (only on a procedure 
> access).

Why do you need to do this?

Note that System.Address is not necessarily the same as a pointer, whether you 
mean an Ada access value or a C pointer. Assuming so can cause portability 
problems, and I can't recall a situation where it was necessary.

-- 
Jeff Carter
"What's the amount of the insult?"
Never Give a Sucker an Even Break
104

Re: Access procedure to pointer

[Sébastien]

> Why do you need to do this?
> 
> Note that System.Address is not necessarily the same as a pointer, 
> whether you mean an Ada access value or a C pointer. Assuming so can 
> cause portability problems, and I can't recall a situation where it was 
> necessary.

I need this to use posix signal.

Re: Access procedure to pointer

[Jeffrey R. Carter]

S�bastien wrote:
> 
> I need this to use posix signal.

You mean you're calling an Ada subprogram with a parameter of type 
System.Address? If you're interfacing to C, a convention-C access type as 
Kazakov suggested is a better and safer way.

-- 
Jeff Carter
"What's the amount of the insult?"
Never Give a Sucker an Even Break
104

Re: Access procedure to pointer

[Jacob Sparre Andersen]

S�bastien wrote:

> I need this to use posix signal.

As far as I know, you don't need any access types or pointers to use
the package POSIX.Signals.

Greetings,

Jacob
-- 
Infinite loop: n., see loop, infinite.
Loop, infinite: n., see infinite loop.

Re: Access procedure to pointer

[Sébastien]

> As far as I know, you don't need any access types or pointers to use
> the package POSIX.Signals.

I don't have such a package. I assume you are talking about florist?

Re: Access procedure to pointer

[Jacob Sparre Andersen]

S�bastien wrote:

>> As far as I know, you don't need any access types or pointers to
>> use the package POSIX.Signals.
>
> I don't have such a package. I assume you are talking about florist?

Sort of.  Florist is the only implementation of the POSIX packages I
know of.  But technically it is just an ISO standard.

Greetings,

Jacob
-- 
"It is very easy to get ridiculously confused about the
 tenses of time travel, but most things can be resolved
 by a sufficiently large ego."