On Tue, 08 Jan 2008, Szakáts Viktor wrote: > I understand, thanks for the tip. I've just committed this > modification.
Thank you. > Something's still not right though. When compiling checkbox.prg > (the first OO code in the build process), lots of syntax errors > appear, then - after a slight pause - comes a memory allocation error: > >harbour checkbox.prg /p /n /w /i..\include > Harbour devel build 1.1-1 Intl. > Copyright (c) 1999-2008, http://www.harbour-project.org/ > Compiling 'checkbox.prg' and generating preprocessed output to > 'checkbox.ppo'... > checkbox.prg(69) Error E0030 Syntax error: "syntax error at '.'" In strict C52 mode we do not have support for functions with variable number of parameters and ... operator. This can be easy resolved. > checkbox.prg(81) Error E0030 Syntax error: "syntax error at 'BITMAPS'" > checkbox.prg(82) Error E0030 Syntax error: "syntax error at 'BUFFER'" > checkbox.prg(83) Error E0030 Syntax error: "syntax error at 'CAPCOL'" > checkbox.prg(84) Error E0030 Syntax error: "syntax error at 'CAPROW'" > checkbox.prg(85) Error E0030 Syntax error: "syntax error at 'CAPTION'" > checkbox.prg(86) Error E0030 Syntax error: "syntax error at 'COL'" [...] For SETGET methods we also need identifier concatenation too add "_" prefix. This cannot be easy resolved because Clipper's PP does allow to concatenate any identifiers. For this we will have to use stringify and RT function which will convert strings to symbols. > Unrecoverable error 9006: hb_xgrab can't allocate memory Side effect of possible recursions which can appear in strict C52 mode because Clipper always preporcess nested directive in result pattern. To eliminate it we will have to make some deeper modifications in our hbclass.ch or use trick with #include like in class(y).ch You can also easy disable strict compatibility here by modification in hbpp.h, look at: #ifdef HB_C52_STRICT # define HB_PP_TOKEN_ISEOS(t) HB_PP_TOKEN_ISEOL(t) # define HB_PP_TOKEN_ISEOP(t,l) HB_PP_TOKEN_ISEOL(t) #else /* End Of Subst - define how many tokens in line should be translated, Clipper translate whole line */ and change it to: #ifdef HB_C52_STRICT_INFO # define HB_PP_TOKEN_ISEOS(t) HB_PP_TOKEN_ISEOL(t) # define HB_PP_TOKEN_ISEOP(t,l) HB_PP_TOKEN_ISEOL(t) #else /* End Of Subst - define how many tokens in line should be translated, Clipper translate whole line */ Memory allocation error is not good results of such recursive substitution but also in Clipper it's possible to create rules which will give the same results. Unfortunately it's one of situations which cannot be easy trap and reported without introducing some fixed limits which may reduce functionality. The translation counter does not help because I can easy create rule which will double tokens in translated line, f.e.: #command CMD <*x*> => CMD <x>, <x> CMD 1 and as you can easy calculate the memory allocation will be geometric (2^N) to number of iterations. In such simple example it's possible to easy detect cycle so this can be resolved but it's also possible to create other examples where in practice it cannot be done. The only one possible solution to avoid memory allocation errors seems to be hardcoding some fixed limit for total allocate memory or number of allocated tokens and report error like 'expression to complex' when such limit is reached. So far I haven't added it intentionally to not reduce functionality but I'll add such limit in the future for programs which uses PP at RT. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
