[GRASS-dev] graph function input limitations

[Paulo van Breugel]

On Thu, Nov 22, 2012 at 9:15 PM, Glynn Clements <glynn at gclements.plus.com>wrote:

>
> Paulo van Breugel wrote:
>
> > > To be honest, I'm not sure that it's worth increasing this value in
> > > the standard version. 5000 arguments in a function call is rather
> > > extreme, and probably a hint that alternative approaches should be
> > > considered.
> >
> > What are the possible disadvantages of increasing this limit?
>
> 1. We have to decide upon a limit. If ~5000 arguments isn't enough, is
> 10,000? 100,000? A million?
>

Good point.


>
> 2. If someone actually uses 5000 arguments, forcing them to seek help
> might be considered a good thing.
>

I can hardly disagree of course :-). your help did help me for sure


>
> > But you are right, there aren't probably many user cases where more
> > then 5000 arguments are used. And as my case illustrates, there
> > might be better alternatives. In any case, would it be possible to
> > change the error message when the limit is surpassed from the
> > generic 'memory exhausted', to something along the lines of "maximum
> > number of function arguments exceeded"?
>
> Changing it would require a non-portable hack. The actual string is
> part of the parser skeleton, which is beyond our control. For bison,
> it's passed to the YY_() macro used for localisation. We could
> re-implement that macro, but that would affect other localised
> messages. And may cause problems for other versions of yacc.
>

OK, that does sound the trouble out-weights the benefits

>
> > And possibly, this limitation could be mentioned in the help file?
>
> The current limit is implementation-dependent, i.e. if GRASS was built
> using a different version of yacc, the limit might be different. Also
> YYMAXDEPTH isn't specified by POSIX, so setting it wouldn't make the
> limit not implementation-dependent.
>
>
The main purpose would be for the user to recognize the possible cause when
confronted with an error message about 'memory exhausted'. The limit at
which this happens is less important in that case. Of course, if there are
other problems that will give the same error message, that would't help
much. Anyway, we are talking about a limitation and corresponding error
message that I reckon not many people will encounter anyway.

Thanks for all the explanation, it shows it clearly is easy to
underestimate the complexity of the code :-/



> --
> Glynn Clements <glynn at gclements.plus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20121122/ecd69b90/attachment.html>