Suggestion for gnatstub

Suggestion for gnatstub

[Victor Porton]

Please change gnatstub so that it would put

begin
   raise Program_Error; -- FIXME: implement
end;

instead of

begin
   null;
end;

for bodies of procedures. Placing that is now is obviously unreliable.
At very least gnatstub should put the comment indicating that  it is
only a stub.

Re: Suggestion for gnatstub

[Marc A. Criley]

Victor Porton wrote:
> 
> Please change gnatstub so that it would put
> 
> begin
>    raise Program_Error; -- FIXME: implement
> end;
> 
> instead of
> 
> begin
>    null;
> end;
> 
> for bodies of procedures. Placing that is now is obviously unreliable.
> At very least gnatstub should put the comment indicating that  it is
> only a stub.

Making such a suggestion in comp.lang.ada will have zero effect, as few
ACT personnel peruse this newsgroup with any regularity.  And as Robert
Dewar was wont to say, "We don't take suggestions from public
newsgroups!"

Anyway, the gnatstub sources are readily available, modify it to
generate the output you desire.

(I do think it would be useful to have gnatstub operate as you suggest,
though perhaps make it selectable via a command-line switch, e.g., 
-gnatharsh.)

Marc A. Criley
Quadrus Corporation
www.quadruscorp.com

Re: Suggestion for gnatstub

[Marin David Condic]

Actually, I dislike gnatstub because it doesn't generate null functions. I
often want the stubs to be executable so I can test higher level code and do
iterative builds. ("O.K. I got *this* function working right, now lets go
build the next one..." Saves on having to build test harnesses.) I'd imagine
it would be fairly straightforward to include an option that let the user
select the desired behavior - raise exceptions or generate working code.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Marc A. Criley <mcq95@earthlink.net> wrote in message
news:3DCBC4C9.AD436CD9@earthlink.net...
>
> Making such a suggestion in comp.lang.ada will have zero effect, as few
> ACT personnel peruse this newsgroup with any regularity.  And as Robert
> Dewar was wont to say, "We don't take suggestions from public
> newsgroups!"
>
> Anyway, the gnatstub sources are readily available, modify it to
> generate the output you desire.
>
> (I do think it would be useful to have gnatstub operate as you suggest,
> though perhaps make it selectable via a command-line switch, e.g.,
> -gnatharsh.)
>

Re: Suggestion for gnatstub

[chris.danx]

Marin David Condic wrote:

> Actually, I dislike gnatstub because it doesn't generate null 
> functions. I often want the stubs to be executable so I can test 
> higher level code and do iterative builds. ("O.K. I got *this* 
> function working right, now lets go build the next one..." Saves on 
> having to build test harnesses.) I'd imagine it would be fairly 
> straightforward to include an option that let the user select the 
> desired behavior - raise exceptions or generate working code.


I'd also like to see some revisions to gnatstub like this.  Something 
that smartly creates stub functions that work when possible.  I'm wrote 
quite a few packages over the summer and wanted to try out an iterative 
development style tought in our software development course (to test it 
out... :) ).  The package spec would be written, then a stub generated, 
then a higher level module coded and tested.  The stub would then be 
replaced with the correct code, tested with the aid of the higher level 
(coordinate) module plus some extra code.  The scheme worked well, but I 
found that gnatstub was not all that useful, because it generated 
function bodies that needed recoding to be stubs.

I would also like it to put the comments from the spec, which could be 
controlled by a flag.  Also the ability to specify a test code function 
(and location) that it could use to generate code of the form

procedure make_type (xx : in yy) is
begin
    some_log_routine ("make_type called with value", xx);
end make_type;

or something like that.  Even if it just put the name of the procedure 
being called to the log routine it would cut down a heck of a lot of 
work.  This strategy is what I use to write code now (atleast in Ada).

I take a problem, write a spec, generate a stub (usually by hand) and 
then write the test code.  Finally, the code for the implementation is 
filled in and tested incrementally.  It is very effective and I would 
benefit greatly from a smarter gnatstub (sadly I have no time to modify 
or redesign it, too much bloody work!).


Chris
-- 
for personal replies change spamoff to chris

Re: Suggestion for gnatstub

[Simon Wright]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Actually, I dislike gnatstub because it doesn't generate null
> functions. I often want the stubs to be executable so I can test
> higher level code and do iterative builds. ("O.K. I got *this*
> function working right, now lets go build the next one..." Saves on
> having to build test harnesses.) I'd imagine it would be fairly
> straightforward to include an option that let the user select the
> desired behavior - raise exceptions or generate working code.

My ColdFrame framework generator goes to a lot of trouble to generate
compilable subprograms that raise Program_Error if executed. I think
there is one case where this doesn't work (functions returning a value
of an imported type, eg GNAT.Socket_Type, that turns out to be
private).

Re: Suggestion for gnatstub

[Marin David Condic]

Well, yeah, but that's exactly what I *don't* want. I'd like a stub
generator that built something that would execute without raising an
exception. (Unless, of course, there was something else wrong with the code.
Id est, returning some default value that caused a calculation to go awry.)

I used to have a stub generator of my own that worked with Ada83 code.
Procedures simply had a "null ;" statement. Functions would declare a
temporary variable of the return type and to the extent that the tool could
figure out the kind of type it was, it provided an initial value to the
temporary. Then it just generated a "return Temp ;" statement. 99.9% of the
time, what it built was "Good Enough" for testing purposes. Occasionally,
you'd have to add some modifications by hand to get something usable as a
stub. But the point was, for getting a set of stubs built for
quick-and-dirty Smoke Testing, it saved a bunch of time. You could run your
main program and test its behavior and do iterative builds as you went
along.

Generating an exception instead is dramatically less useful. To be able to
successfully call the stub and move on with tests, you've got to hand modify
the code. Not impossible, but it does add labor.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================
Simon Wright <simon@pushface.org> wrote in message
news:x7vn0oizv5j.fsf@smaug.pushface.org...
>
> My ColdFrame framework generator goes to a lot of trouble to generate
> compilable subprograms that raise Program_Error if executed. I think
> there is one case where this doesn't work (functions returning a value
> of an imported type, eg GNAT.Socket_Type, that turns out to be
> private).

Re: Suggestion for gnatstub

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> My ColdFrame framework generator goes to a lot of trouble to generate
> compilable subprograms that raise Program_Error if executed. I think
> there is one case where this doesn't work (functions returning a value
> of an imported type, eg GNAT.Socket_Type, that turns out to be
> private).

Presuming the goal is to get the code to compile, but not run,
you could generate:

    function F(X, Y: Integer) return GNAT.Socket_Type is
    begin
        raise Program_Error;
        return F(X, Y); -- bogus return to keep compiler from griping
    end F;

Actually, I suspect the compiler might gripe about infinite recursion,
so maybe you need this:

    function F(X, Y: Integer) return GNAT.Socket_Type is
    begin
        raise Program_Error;
        pragma Warnings(Off);
        return F(X, Y); -- bogus return to keep compiler from griping
        pragma Warnings(On);
    end F;

Bleah.  It's pretty annoying that Ada requires a return statement on
paths that *obviously* raise exceptions.

- Bob

Re: Suggestion for gnatstub

[Simon Wright]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

(posting after the thing he's replying to! please don't!!)

> Simon Wright <simon@pushface.org> wrote in message
> news:x7vn0oizv5j.fsf@smaug.pushface.org...
> >
> > My ColdFrame framework generator goes to a lot of trouble to generate
> > compilable subprograms that raise Program_Error if executed. I think
> > there is one case where this doesn't work (functions returning a value
> > of an imported type, eg GNAT.Socket_Type, that turns out to be
> > private).

> Well, yeah, but that's exactly what I *don't* want. I'd like a stub
> generator that built something that would execute without raising an
> exception. (Unless, of course, there was something else wrong with the code.
> Id est, returning some default value that caused a calculation to go awry.)
> 
> I used to have a stub generator of my own that worked with Ada83 code.
> Procedures simply had a "null ;" statement. Functions would declare a
> temporary variable of the return type and to the extent that the tool could
> figure out the kind of type it was, it provided an initial value to the
> temporary. Then it just generated a "return Temp ;" statement. 99.9% of the
> time, what it built was "Good Enough" for testing purposes. Occasionally,
> you'd have to add some modifications by hand to get something usable as a
> stub. But the point was, for getting a set of stubs built for
> quick-and-dirty Smoke Testing, it saved a bunch of time. You could run your
> main program and test its behavior and do iterative builds as you went
> along.

One of the advantages of an open code gnerator is that you can fix it
to do this sort of thing.

However, I would seriously question what you're suggesting. I don't
want the slightest chance that code like this could make it into the
delivered system unnoticed. And what value can there possibly be in a
test that doesn't pick up the fact that values being returned are
arbitrarily different from what they should be?

Re: Suggestion for gnatstub

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Presuming the goal is to get the code to compile, but not run,
> you could generate:
> 
>     function F(X, Y: Integer) return GNAT.Socket_Type is
>     begin
>         raise Program_Error;
>         return F(X, Y); -- bogus return to keep compiler from griping
>     end F;
> 
> Actually, I suspect the compiler might gripe about infinite recursion,
> so maybe you need this:
> 
>     function F(X, Y: Integer) return GNAT.Socket_Type is
>     begin
>         raise Program_Error;
>         pragma Warnings(Off);
>         return F(X, Y); -- bogus return to keep compiler from griping
>         pragma Warnings(On);
>     end F;
> 
> Bleah.  It's pretty annoying that Ada requires a return statement on
> paths that *obviously* raise exceptions.

I had thought about

    function F(X, Y: Integer) return GNAT.Socket_Type is
       Dummy : GNAT.Socket_Type;
       pragma Warnings (Off, Dummy);
    begin
        raise Program_Error;
        return Dummy;
    end F;

Re: Suggestion for gnatstub

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> I had thought about
> 
>     function F(X, Y: Integer) return GNAT.Socket_Type is
>        Dummy : GNAT.Socket_Type;
>        pragma Warnings (Off, Dummy);
>     begin
>         raise Program_Error;
>         return Dummy;
>     end F;

Usually OK, but doesn't work for limited types.

- Bob

Re: Suggestion for gnatstub

[Pascal Obry]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Simon Wright <simon@pushface.org> writes:
> 
> > I had thought about
> > 
> >     function F(X, Y: Integer) return GNAT.Socket_Type is
> >        Dummy : GNAT.Socket_Type;
> >        pragma Warnings (Off, Dummy);
> >     begin
> >         raise Program_Error;
> >         return Dummy;
> >     end F;
> 
> Usually OK, but doesn't work for limited types.

Not only limited types but with unconstraint types like String which is
very common !

Pascal.

-- 

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

Re: Suggestion for gnatstub

[Simon Wright]

Pascal Obry <p.obry@wanadoo.fr> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
> > Simon Wright <simon@pushface.org> writes:
> > 
> > > I had thought about
> > > 
> > >     function F(X, Y: Integer) return GNAT.Socket_Type is
> > >        Dummy : GNAT.Socket_Type;
> > >        pragma Warnings (Off, Dummy);
> > >     begin
> > >         raise Program_Error;
> > >         return Dummy;
> > >     end F;
> > 
> > Usually OK, but doesn't work for limited types.
> 
> Not only limited types but with unconstraint types like String which is
> very common !

I would hope it wouldn't work for limited types :-)

Re: Suggestion for gnatstub

[Marin David Condic]

Obviously, I can sit down and write it all from scratch if I like, too.
That's not nearly so satisfying as getting it done by someone else for you
free of charge. :-) Seriously, its just a suggestion as a "desirable"
switch-selectable feature. If it never gets implemented, it is hardly the
end of civilization as we know it - one just has to hand-mod the produced
code. You've got to do that eventually anyway.

In the world I live in, it would not be possible to leave stubs in a
delivered system, so I'm not worried about that. Ultimately, if you do worry
about such things, there's nothing to stop hand-generated stubs or bad
subroutines or any other sort of trash from getting through, so why worry
about a machine generated stub? And besides, what about procedures with only
a "null ;" statement? That's sort of an envisioned use - test stubs - so
maybe they should have been disallowed by the language?

As to the value? I've often had a higher level procedure where I want to
check the logical flow or correctness in some "grand overview" sense without
worrying so much that it got the right answer to anything. In a case like
that, stubs that simply execute but produce no useful output are a fine
thing. It shouldn't be hard to imagine such a case. A high level thing gets
some user input & parses it to decide what calculations to do, then goes
back to get more input from the user. Initially, you just want to check that
your parser is working right and you aren't interested in the calculations.
If the functions all raise exceptions rather than return zeros or some other
innocuous - yet wrong - value, its a bit of a pain in the posterior to have
it crash with an exception in the middle of your smoke testing. I could
easily come up with more examples. The whole concept of "iterative builds"
is built around such development practices.

As a switch selectable choice, if you don't consider such a thing to be
"safe" you don't have to use it. For those who would find it useful and
aren't concerned about potential safety issues, well, there it is!

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Simon Wright <simon@pushface.org> wrote in message
news:x7v8z0233vr.fsf@smaug.pushface.org...
>
> One of the advantages of an open code gnerator is that you can fix it
> to do this sort of thing.
>
> However, I would seriously question what you're suggesting. I don't
> want the slightest chance that code like this could make it into the
> delivered system unnoticed. And what value can there possibly be in a
> test that doesn't pick up the fact that values being returned are
> arbitrarily different from what they should be?

Re: Suggestion for gnatstub

[Marin David Condic]

It doesn't have to work 100% of the time. Just often enough that it is
useful in saving someone from having to generate lots of stuff by hand.
Remember that the goal is not to produce a working, correct program, but to
produce something that saves the developer some time in the process of
getting to that working, correct program. If it works on 70% of the
situations and I've got to go in and fix a compiler error on the other 30%,
I still got 70% of my work done for me and probably 90% of the remaining 30%
of the work done on the stuff I have to modify. That's not a bad deal, is
it?

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Pascal Obry <p.obry@wanadoo.fr> wrote in message
news:u8z01byub.fsf@wanadoo.fr...
>
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>
> >
> > Usually OK, but doesn't work for limited types.
>
> Not only limited types but with unconstraint types like String which is
> very common !
>

Re: Suggestion for gnatstub

[Robert A Duff]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> In the world I live in, it would not be possible to leave stubs in a
> delivered system, so I'm not worried about that. Ultimately, if you do worry
> about such things, there's nothing to stop hand-generated stubs or bad
> subroutines or any other sort of trash from getting through, so why worry
> about a machine generated stub? And besides, what about procedures with only
> a "null ;" statement? That's sort of an envisioned use - test stubs - so
> maybe they should have been disallowed by the language?

To me, "null;" means "this procedure does nothing".  You're suggesting
to overload it to also mean "I haven't gotten around to writing this
procedure yet".

> As to the value? I've often had a higher level procedure where I want to
> check the logical flow or correctness in some "grand overview" sense without
> worrying so much that it got the right answer to anything.

I don't normally use that style, because when the thing crashes, you
have to expend energy debugging whether it's a "real" bug (in the grand
overview code) versus a "stub" that is generating bogus data, and then
the grand code is tripping over it.

> As a switch selectable choice, if you don't consider such a thing to be
> "safe" you don't have to use it. For those who would find it useful and
> aren't concerned about potential safety issues, well, there it is!

Hmm.  If I'm *using* the program *you* write, I just hope the reason you
"aren't concerned about potential safety issues" is that you've solved
them some other way.  Too many programmers "aren't concerned ..." due to
sloppiness.  ;-)

Having said all that, I admit none of this is a big deal.

- Bob

Re: Suggestion for gnatstub

[Simon Wright]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Obviously, I can sit down and write it all from scratch if I like, too.
> That's not nearly so satisfying as getting it done by someone else for you
> free of charge. :-) Seriously, its just a suggestion as a "desirable"
> switch-selectable feature. If it never gets implemented, it is hardly the
> end of civilization as we know it - one just has to hand-mod the produced
> code. You've got to do that eventually anyway.

Well, you _almost_ convince me!

Re: Suggestion for gnatstub

[Marin David Condic]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
news:wcc65v5maiv.fsf@shell01.TheWorld.com...
>
> To me, "null;" means "this procedure does nothing".  You're suggesting
> to overload it to also mean "I haven't gotten around to writing this
> procedure yet".
>
I can't think of too many other reasons to write a null procedure. If it was
going to stay null forever, then why have it at all. Seems like the
mechanism is there so you can have a procedure waiting for the programmer to
find the elusive Round Tuit. :-)


>
> I don't normally use that style, because when the thing crashes, you
> have to expend energy debugging whether it's a "real" bug (in the grand
> overview code) versus a "stub" that is generating bogus data, and then
> the grand code is tripping over it.
>
Well, everybody has different styles and sometimes its a matter of what is
appropriate for the application at hand. Sometimes writing a bunch of test
drivers is the way to go. Sometimes maybe one should just fill in all the
code and get staarted testing the thing in one big gigantic thrust. But I
think you can see that lots of things get built in iterative builds where
some portion of the system remains as stubs to be filled in at a later time.


>
> Hmm.  If I'm *using* the program *you* write, I just hope the reason you
> "aren't concerned about potential safety issues" is that you've solved
> them some other way.  Too many programmers "aren't concerned ..." due to
> sloppiness.  ;-)
>
Chances are, you might have if you've ever strapped an F22 or JSF fighter to
your back and gone for a ride. :-) The process we use for building engine
controls for such creatures includes too many audits to think it is possible
to get a null procedure or function through into production unless you
really meant to do that. If such a problem could get through that far, I'd
have even more fear and trembling about getting through a stub that
contained an exception in it. An incorrect function return *might* allow the
control to continue operating but an exception would throw it straight into
a reboot. That could be "bad". :-)


> Having said all that, I admit none of this is a big deal.
>
Sure. If its a switch selectable thing, you can use whichever approach makes
more sense for the situation at hand.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Suggestion for gnatstub

[Robert A Duff]

"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
> news:wcc65v5maiv.fsf@shell01.TheWorld.com...
> >
> > To me, "null;" means "this procedure does nothing".  You're suggesting
> > to overload it to also mean "I haven't gotten around to writing this
> > procedure yet".
> >
> I can't think of too many other reasons to write a null procedure. If it was
> going to stay null forever, then why have it at all. Seems like the
> mechanism is there so you can have a procedure waiting for the programmer to
> find the elusive Round Tuit. :-)

I can't think of "too many", either, but I can think of some.  Just the
other day I wrote a generic procedure to walk a tree.  The generic takes
two generic formal procedures, Pre_Action and Post_Action, which are
called during the tree at the points you would guess.  They have
defaults, "is Do_Nothing", so you can specify one or the other.
Guess what procedure Do_Nothing looks like.  ;-)

> Well, everybody has different styles and sometimes its a matter of what is
> appropriate for the application at hand. Sometimes writing a bunch of test
> drivers is the way to go. Sometimes maybe one should just fill in all the
> code and get staarted testing the thing in one big gigantic thrust. But I
> think you can see that lots of things get built in iterative builds where
> some portion of the system remains as stubs to be filled in at a later time.

Just to be clear on what I was saying about my style (which I agree is
not everybody's style): I often test and debug one procedure in a
package before writing some other procedure in the same package.  For
that, I'd like the editor to insert compile-able but not runnable code.
But I don't usually debug one procedure while the procedures it calls
have not yet been written.

- Bob

Re: Suggestion for gnatstub

[Randy Brukardt]

Robert A Duff wrote in message ...
>"Marin David Condic" <mcondic.auntie.spam@acm.org> writes:
>
>> I can't think of too many other reasons to write a null procedure. If
it was
>> going to stay null forever, then why have it at all. Seems like the
>> mechanism is there so you can have a procedure waiting for the
programmer to
>> find the elusive Round Tuit. :-)
>
>I can't think of "too many", either, but I can think of some.  Just the
>other day I wrote a generic procedure to walk a tree.  The generic
takes
>two generic formal procedures, Pre_Action and Post_Action, which are
>called during the tree at the points you would guess.  They have
>defaults, "is Do_Nothing", so you can specify one or the other.
>Guess what procedure Do_Nothing looks like.  ;-)


Most action routines (callbacks) in Claw are defined as procedure
When_something (...) is null; end When_something;
These may be overridden in for a derived type, but the original routine
is likely to remain with a null body forever. I believe this is common
in object-oriented code.

            Randy.

Re: Suggestion for gnatstub

[Robert I. Eachus]

Pascal Obry wrote:
> Not only limited types but with unconstraint types like String which is
> very common !

I used to have this problem until I realized a trick.  It shouldn't be 
necessary, but it works:

     function F(X, Y: Integer) return GNAT.Socket_Type is
        type Junk is access GNAT.Socket_Type;
        Junk_Reference: Junk;
     begin
       TBD("F(X, Y: Integer) return GNAT.Socket_Type");
       return Junk_Reference.all;
     end F;

The procedure TBD in package Incomplete normally prints a message:

     procedure TBD(S: in String) is
     begin Put_Line(S & " not yet implemented."); end TBD;

There are also a couple of useful functional forms returning Strings, 
Integers, Floats, and Booleans:

     function TBD(S: in String) return String is
     begin Put_Line(S & " not yet implemented."); return S; end TBD;

One of the reasons I like this approach is that any library unit body 
that is unfinished needs a "with Incomplete; use Incomplete;" to compile 
without errors...

Re: Suggestion for gnatstub

[Wes Groleau]

> I'd also like to see some revisions to gnatstub like this.  Something 
> that smartly creates stub functions that work when possible.  I'm wrote 

Suppose you have the spec for a subprogram.

You could have an ASIS routine that looks at the spec,
and generates a stub that prints out something like

    Executing stub for function ... ( ... ) return ...
       with parameters: param1 => ......

Stephen Leake's Auto_Text_IO can do 90% of this already.

Re: Suggestion for gnatstub

[Stephen Leake]

Wes Groleau <wesgroleau@despammed.com> writes:

> > I'd also like to see some revisions to gnatstub like this.
> > Something that smartly creates stub functions that work when
> > possible.  I'm wrote
> 
> Suppose you have the spec for a subprogram.
> 
> You could have an ASIS routine that looks at the spec,
> and generates a stub that prints out something like
> 
>     Executing stub for function ... ( ... ) return ...
>        with parameters: param1 => ......
> 
> Stephen Leake's Auto_Text_IO can do 90% of this already.

Hmm. Auto_Text_IO was patterned after a previously written ASIS
program that did ..... (drum roll) ..... subprogram stub generation.
It's called gnatstub. Comes with GNAT (since at least 3.12). Works
fine. People are complaining about the details :). 

I suppose if you want to get really fancy, Auto_Text_IO has some
type-info-gathering stuff that gnatstub might need. But starting with
gnatstub is certainly the first thing to do, if you want a better
gnatstub.

Thanks for the plug, though. 

-- 
-- Stephe

Re: Suggestion for gnatstub

[Marin David Condic]

There is yet another good idea for a stub generation option. Gnatstub might
be made to optionally output A) nulled out procedures & functions that
execute with minimally impacting results or B) Exceptions so that calling
them results in a runtime error, yet they remain compilable/linkable or C)
One or more types of Text_IO statements to indicate that the subprogram got
executed and what (if any) are the values of its parameters.

It might generate all three in the output and comment out the ones that were
not selected. I wouldn't worry too much about it being able to handle 100%
of the cases because its just a development aid that ultimately has to be
replaced by hand coded stuff anyway. A few oddball cases where it generates
something unusable without mods is probably fine.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Wes Groleau <wesgroleau@despammed.com> wrote in message
news:AS9B9.2090$c6.2552@bos-service2.ext.raytheon.com...
>
> Suppose you have the spec for a subprogram.
>
> You could have an ASIS routine that looks at the spec,
> and generates a stub that prints out something like
>
>     Executing stub for function ... ( ... ) return ...
>        with parameters: param1 => ......
>
> Stephen Leake's Auto_Text_IO can do 90% of this already.
>