Ken, thanks for reviewing the idea.
Am 07.04.2011 um 03:55 schrieb Kenneth Lerman: > I think it is a good idea with all of the necessary attributes: > > 1 -- It doesn't break any existing code (well, it might if you already were > using the variable #<_value>. You might consider changing this so that if > you don't have a return value, #<_value> is unchanged.) I understand your argument. However, the downside is: '#<_value>' depend on previous execution if no values are passed on endsub or return, and #<_value> is referred to. See the test case in http://git.mah.priv.at/gitweb/emc2-dev.git/blob/81d6e4fd746f33de2fc9939ea5aeb631e2d0126c:/tests/interp/return-value/test.ngc : The value seen in line 37 would depend on the value returned from a previous subroutine invocation (line 27 in this case) I think it is better to set a default value to 0 on any expressionless return or endsub - less surprise. Here's a reworked patch including regression test, example and manual update: http://git.mah.priv.at/gitweb/emc2-dev.git/commit/81d6e4fd746f33de2fc9939ea5aeb631e2d0126c Manual preview: http://emc.mah.priv.at/docs/html/gcode/main.html#sec:Subroutine-return-values and http://emc.mah.priv.at/docs/html/gcode/overview.html#param:_value -Michael > 2 -- If you don't like it, don't use it. > > Regards, > > Ken > > -----Original Message----- > From: Michael Haberler [mailto:[email protected]] > Sent: Wednesday, April 06, 2011 8:54 PM > To: EMC developers > Subject: [Emc-developers] proposal: o-word subroutine return values > > I'm proposing optional subroutine return values for the 'return' and > 'endsub' o-words. > > This would work as follows: > > - the 'return' and 'endsub' keywords may be followed by an optional > expression. > - this expression is evaluated at procedure return/endsub time > - its value is stored in global named parameter '#<_value>' > - the default value ('return' and 'endsub' without a trailing expression) is > 0. > > Here is an example how that works: > -------------------------------- > o1000 sub > o1010 if [#1 GT 0] > o1010 return [123*[#1]] > o1010 endif > > o1020 if [#1 LT 0] > o1020 return > o1020 endif > > o1000 endsub [4712] > > o1000 call [0] > (debug,call with arg1=0 return #<_value>) > > ; #<_value> is 4712.0 > > o1000 call [2] > (debug,call with arg1=2 return #<_value>) > > ; #<_value> is 246.0 > > o1000 call [-1] > (debug,call with arg1=-1 return #<_value>) > > ; #<_value> is 0.0 > > m2 > -------------------------------- > > Here's a tentative implementation: > http://git.mah.priv.at/gitweb/emc2-dev.git/commit/bdb22fc1bbaed2c7c2cd688172 > 40923cc92adfd4 > > why am I proposing this? > > It became clear to me that commands like Tx/M6 which are remapped to o-word > subs need to be able to pass values back to EMC, for instance to signal > wether an M6 succeeded (change tool) or failed (do not change tool). Return > values are an obvious choice and are generally useful. > > I'd appreciate feedback if find it worthwhile/useless/soso. > > -Michael > > ps: I am aware the same effect can be had by using global variables but then > languages have moved on. > > > ---------------------------------------------------------------------------- > -- > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
