* Suggestion for gnatstub @ 2002-11-08 11:14 Victor Porton 2002-11-08 12:56 ` Marc A. Criley 0 siblings, 1 reply; 23+ messages in thread From: Victor Porton @ 2002-11-08 11:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-08 11:14 Suggestion for gnatstub Victor Porton @ 2002-11-08 12:56 ` Marc A. Criley 2002-11-08 13:23 ` Marin David Condic 0 siblings, 1 reply; 23+ messages in thread From: Marc A. Criley @ 2002-11-08 12:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-08 12:56 ` Marc A. Criley @ 2002-11-08 13:23 ` Marin David Condic 2002-11-08 21:09 ` chris.danx 2002-11-09 14:15 ` Simon Wright 0 siblings, 2 replies; 23+ messages in thread From: Marin David Condic @ 2002-11-08 13:23 UTC (permalink / raw) 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.) > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-08 13:23 ` Marin David Condic @ 2002-11-08 21:09 ` chris.danx 2002-11-15 17:08 ` Wes Groleau 2002-11-09 14:15 ` Simon Wright 1 sibling, 1 reply; 23+ messages in thread From: chris.danx @ 2002-11-08 21:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-08 21:09 ` chris.danx @ 2002-11-15 17:08 ` Wes Groleau 2002-11-15 17:35 ` Stephen Leake 2002-11-16 14:36 ` Marin David Condic 0 siblings, 2 replies; 23+ messages in thread From: Wes Groleau @ 2002-11-15 17:08 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-15 17:08 ` Wes Groleau @ 2002-11-15 17:35 ` Stephen Leake 2002-11-16 14:36 ` Marin David Condic 1 sibling, 0 replies; 23+ messages in thread From: Stephen Leake @ 2002-11-15 17:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-15 17:08 ` Wes Groleau 2002-11-15 17:35 ` Stephen Leake @ 2002-11-16 14:36 ` Marin David Condic 1 sibling, 0 replies; 23+ messages in thread From: Marin David Condic @ 2002-11-16 14:36 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-08 13:23 ` Marin David Condic 2002-11-08 21:09 ` chris.danx @ 2002-11-09 14:15 ` Simon Wright 2002-11-09 14:50 ` Marin David Condic 2002-11-09 15:44 ` Robert A Duff 1 sibling, 2 replies; 23+ messages in thread From: Simon Wright @ 2002-11-09 14:15 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-09 14:15 ` Simon Wright @ 2002-11-09 14:50 ` Marin David Condic 2002-11-09 20:05 ` Simon Wright 2002-11-09 15:44 ` Robert A Duff 1 sibling, 1 reply; 23+ messages in thread From: Marin David Condic @ 2002-11-09 14:50 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-09 14:50 ` Marin David Condic @ 2002-11-09 20:05 ` Simon Wright 2002-11-10 15:58 ` Marin David Condic 0 siblings, 1 reply; 23+ messages in thread From: Simon Wright @ 2002-11-09 20:05 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-09 20:05 ` Simon Wright @ 2002-11-10 15:58 ` Marin David Condic 2002-11-10 20:31 ` Robert A Duff 2002-11-11 6:31 ` Simon Wright 0 siblings, 2 replies; 23+ messages in thread From: Marin David Condic @ 2002-11-10 15:58 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-10 15:58 ` Marin David Condic @ 2002-11-10 20:31 ` Robert A Duff 2002-11-11 13:46 ` Marin David Condic 2002-11-11 6:31 ` Simon Wright 1 sibling, 1 reply; 23+ messages in thread From: Robert A Duff @ 2002-11-10 20:31 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-10 20:31 ` Robert A Duff @ 2002-11-11 13:46 ` Marin David Condic 2002-11-11 15:31 ` Robert A Duff 0 siblings, 1 reply; 23+ messages in thread From: Marin David Condic @ 2002-11-11 13:46 UTC (permalink / raw) 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] ====================================================================== ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-11 13:46 ` Marin David Condic @ 2002-11-11 15:31 ` Robert A Duff 2002-11-11 20:32 ` Randy Brukardt 0 siblings, 1 reply; 23+ messages in thread From: Robert A Duff @ 2002-11-11 15:31 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-11 15:31 ` Robert A Duff @ 2002-11-11 20:32 ` Randy Brukardt 0 siblings, 0 replies; 23+ messages in thread From: Randy Brukardt @ 2002-11-11 20:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-10 15:58 ` Marin David Condic 2002-11-10 20:31 ` Robert A Duff @ 2002-11-11 6:31 ` Simon Wright 1 sibling, 0 replies; 23+ messages in thread From: Simon Wright @ 2002-11-11 6:31 UTC (permalink / raw) "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! ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-09 14:15 ` Simon Wright 2002-11-09 14:50 ` Marin David Condic @ 2002-11-09 15:44 ` Robert A Duff 2002-11-09 20:08 ` Simon Wright 1 sibling, 1 reply; 23+ messages in thread From: Robert A Duff @ 2002-11-09 15:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-09 15:44 ` Robert A Duff @ 2002-11-09 20:08 ` Simon Wright 2002-11-09 21:56 ` Robert A Duff 0 siblings, 1 reply; 23+ messages in thread From: Simon Wright @ 2002-11-09 20:08 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-09 20:08 ` Simon Wright @ 2002-11-09 21:56 ` Robert A Duff 2002-11-10 8:42 ` Pascal Obry 0 siblings, 1 reply; 23+ messages in thread From: Robert A Duff @ 2002-11-09 21:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-09 21:56 ` Robert A Duff @ 2002-11-10 8:42 ` Pascal Obry 2002-11-10 12:20 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Pascal Obry @ 2002-11-10 8:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-10 8:42 ` Pascal Obry @ 2002-11-10 12:20 ` Simon Wright 2002-11-10 16:04 ` Marin David Condic 2002-11-14 20:10 ` Robert I. Eachus 2 siblings, 0 replies; 23+ messages in thread From: Simon Wright @ 2002-11-10 12:20 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-10 8:42 ` Pascal Obry 2002-11-10 12:20 ` Simon Wright @ 2002-11-10 16:04 ` Marin David Condic 2002-11-14 20:10 ` Robert I. Eachus 2 siblings, 0 replies; 23+ messages in thread From: Marin David Condic @ 2002-11-10 16:04 UTC (permalink / raw) 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 ! > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Suggestion for gnatstub 2002-11-10 8:42 ` Pascal Obry 2002-11-10 12:20 ` Simon Wright 2002-11-10 16:04 ` Marin David Condic @ 2002-11-14 20:10 ` Robert I. Eachus 2 siblings, 0 replies; 23+ messages in thread From: Robert I. Eachus @ 2002-11-14 20:10 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2002-11-16 14:36 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-11-08 11:14 Suggestion for gnatstub Victor Porton 2002-11-08 12:56 ` Marc A. Criley 2002-11-08 13:23 ` Marin David Condic 2002-11-08 21:09 ` chris.danx 2002-11-15 17:08 ` Wes Groleau 2002-11-15 17:35 ` Stephen Leake 2002-11-16 14:36 ` Marin David Condic 2002-11-09 14:15 ` Simon Wright 2002-11-09 14:50 ` Marin David Condic 2002-11-09 20:05 ` Simon Wright 2002-11-10 15:58 ` Marin David Condic 2002-11-10 20:31 ` Robert A Duff 2002-11-11 13:46 ` Marin David Condic 2002-11-11 15:31 ` Robert A Duff 2002-11-11 20:32 ` Randy Brukardt 2002-11-11 6:31 ` Simon Wright 2002-11-09 15:44 ` Robert A Duff 2002-11-09 20:08 ` Simon Wright 2002-11-09 21:56 ` Robert A Duff 2002-11-10 8:42 ` Pascal Obry 2002-11-10 12:20 ` Simon Wright 2002-11-10 16:04 ` Marin David Condic 2002-11-14 20:10 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox