r.mapcalc compile trouble - was Re: [GRASS5] I18N for GRASS: continued discussion

[Scott W Mitchell]

Any chance there was a typo in that fix that some compilers don't mind, 
but mine does ?

I was very excited to read that the history is back in, so updated my 
source code and tried compiling.  On a linux/debian/AMD box, I got the 
following error when it was working on mapcalc3:

#################################################################
/usr/local/src/grass/src/raster/r.mapcalc3
   make -f OBJ.i686-pc-linux-gnu/make.rules

bison -y -d mapcalc.y
mapcalc.y:75.8: parse error, unexpected ":", expecting ";" or "|"
make: *** [y.tab.c] Error 1

I've looked at that line and the preceding ones in the source, and 
don't see anything obvious, but then again I don't have a clue how 
bison and friends work, so I'm just comparing to other lines in the 
same file.

Thanks for any suggestions,

Scott Mitchell

On Sunday, November 17, 2002, at 06:27 AM, Glynn Clements wrote:

>
> Glynn Clements wrote:
>
>> Updating the history file probably wouldn't be that hard in itself.
>> However, when reading from stdin, the original form of the expression
>> isn't currently stored anywhere, so you would get e.g. 
>> "add(a,mul(b,c))"
>> instead of "a+b*c". To fix this, I would need to add code to record 
>> the
>> input when reading from stdin.
>
> I've committed an update to CVS which stores the expression in the
> history.
>
> The expression is regenerated from the parse tree, rather than from
> stored input. The main reason for taking this approach is that the
> input can consist of multiple definitions, and you can't reliably tell
> where the boundaries lie without actually parsing the input.
>
> Consequently, using stored input would require that the complete input
> was stored for each map. If the input consisted of a large number of
> expressions, or the expressions were particularly complex, this could
> result in the history being truncated, so the expressions for the
> later maps wouldn't be stored at all.
>
> I also changed certain aspects of the parser and the parse tree to
> allow the original expression to be reconstructed more accurately.
> Specifically, where the input uses infix operators, the stored version
> will now use infix operators instead of prefix functions. Also, any
> type conversion functions which are inserted by the type checking code
> won't appear in the output.
>
> Obviously, certain aspects of the input won't be reflected in the
> stored version, e.g. the amount and type of whitespace, or extraneous
> parentheses.
>
> -- 
> Glynn Clements <glynn.clements at virgin.net>
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
------
Scott W. Mitchell						smitch at geog.utoronto.ca
Department of Geography					Phone: (613) 730-5375
University of Toronto at Mississauga	UTM fax: (905) 828-5273
3359 Mississauga Road					Local fax (613) 822-5143
Mississauga, ON L5L 1C6					Canada