* include/std.ch
! SET STRICTREAD command definition fixed.
* include/hbextern.ch
! Fixed placement of MENUMODAL, to compile when HB_COMPAT_C53
is turned off.
* contrib/libmisc/Makefile
! Fixed test dir name. (broken since yesterday)
* contrib/pdflib/common.mak
+ Added another file.
+ contrib/pdflib/Makefile
+ Added GNU make file for pdflib.
* utils/hbdoc/ft_funcs.prg
* utils/hbmake/ft_funcs.prg
* utils/hbmake/hbmake.prg
! Made them compile with HB_COMPAT_C53 turned off.
There is a loss of functionality in this case.
(MAKEDIR(), DIRCHANGE() and @ CHECKBOX are used here)
* source/rtl/menuto.prg
* source/rtl/tgetlist.prg
! Fixed to compile when HB_COMPAT_C53 is turned off.
* include/hbextern.ch
* source/rtl/defpath.c
* source/rtl/adir.prg
* __DEFPATH() is now always included, not just when HB_C52_UNDOC
is defined, since we use this function from core, and __*()
functions are okey to be included without this guard.
DEFPATH() is still marked as HB_C52_UNDOC.
! ADIR() now uses __DEFPATH() instead of DEFPATH() to compile
with HB_C52_UNDOC turned off.
; TOFIX: There are still a few functions we use from core, which
are guarded with HB_C52_UNDOC: NATIONMSG(), ISNEGATIVE()
* source/vm/memvars.c
* Changed HB_EXTENSION to HB_C52_STRICT. Reason: This
is a Harbour internal (undocumented) function, where extension
is possible. CA-Cl*pper internal (undocumented) function __MRESTORE()
is mapped to this function, which is still okey. We could
create a fully CA-Cl*pper compatible, non-extended __MRESTORE()
without any trouble, if this is an issue.
* include/std.ch
* Removed HB_EXTENSION guard from around SET commands
implementing Harbour _SET_* extensions. The reason:
_SET_* extensions are not marked as extensions (and
it would be nearly impossibly to do so), so it's more
consistent to behave the same way for their command
counterparts.
* utils/hbpp/hbpplib.c
! Removed HB_EXTENSION guard from around __PP*() functions
which are Harbour undocumented ones, so they don't need to
be guarded. We're also in sync with hbextern.ch now.
* utils/hbtest/rt_stra.prg
! Removed HB_EXTENSION guard from around hb_ValToStr() calls,
because this function is no longer marked as HB_EXTENSION.
* contrib/hgf/os2pm/tmenu.prg
* contrib/hgf/os2pm/tmenuitm.prg
* contrib/hgf/gtk/shared.ch
* contrib/hgf/gtk/dispatch.c
* contrib/hgf/gtk/creamenu.c
* contrib/hgf/gtk/msginfo.c
* contrib/hgf/gtk/creabutt.c
* contrib/hgf/gtk/general.c
* contrib/hgf/gtk/creawin.c
* contrib/hgf/gtk/harbgtk.h
* contrib/hgf/gtk/menuitem.prg
* contrib/hgf/win32/button.prg
* contrib/hgf/win32/edit.prg
* contrib/hgf/win32/form.prg
* contrib/hgf/win32/menu.prg
* contrib/hgf/win32/menuitem.prg
* contrib/hgf/win32/winctrl.prg
* contrib/hgf/tests/bld_b32.bat
* contrib/hgf/tests/form2.prg
* contrib/hgf/tests/form3.prg
* contrib/hgf/tests/form3.hbf
* contrib/hgf/tests/form3res.prg
* contrib/hgf/tests/formtext.prg
* contrib/hgf/tests/testctrl.prg
* contrib/hgf/tests/testform.prg
! Fixed bld_b32.bat to link properly.
! Changed HBMenuItem CLASS to HGFMenuItem() to not collide with
Harbour class HBMenuItem() (C53 compatibility class).
; The above reported by Petr Chornyj.
! Added CRLF at the end of each source file where there was none.
! Fixed version headers.
; TOFIX1: HBPersistent():LoadFromFile() has a bug where it doesn't
load the last line if it doesn't end with newline.
; TOFIX2: HBPersistent() uses At() "dirty" extension.
* contrib/odbc/test/odbcdemo.prg
- contrib/odbc/test/browodbc.prg
* contrib/odbc/test/odbccall.prg
* contrib/odbc/test/testodbc.prg
* contrib/odbc/common.mak
+ contrib/odbc/browodbc.prg
! Moved back browodbc.prg to /contrib/odbc (since it was not a test,
just missing from the non-GNU make files)
Reported by Petr Chornyj.
! Added browodbc.prg to non-GNU makefile.
! Added version headers.
* harbour/include/std.ch
* cover ENDSEQUENCE translation with HB_C52_STRICT macro
+ added translations for END SWITCH, END WITH, END OBJECT
* harbour/source/compiler/complex.c
* harbour/source/compiler/harbour.y
* harbour/source/compiler/harbour.yyc
* harbour/source/compiler/harbour.yyh
+ added support for ENDSEQ[UENCE], ENDSW[ITCH] and ENDW[ITH]
* harbour/source/rtl/hbgtcore.c
! changed string to color number translation to be fully Clipper
compatible. Now I do not know any examples which we translate
differently - if someone will find any them then please inform me.
The only one intentional difference between Harbour and Clipper
is in color number to string translation and background highlighting
attribute "*", Clipper put it just before "/" as part of foreground
color (f.e.: 248 => "N*+/W") but Harbour as part background color
(f.e.: 248 => "N+/W*") - Clipper compatible behavior is enabled when
Harbour is compiled with HB_C52_STRICT macro
* harbour/utils/hbtest/rt_misc.prg
* control the position of background highlighting attribute (*) in
expected results depending on HB_C52_STRICT. Harbour passes correctly
all included color translation tests.
* harbour/bin/hb-func.sh
+ pass GTK paths to GCC in hb* scripts when -xbgtk switch is used
* harbour/contrib/rdd_ads/rddads.h
* harbour/contrib/rdd_ads/adsfunc.c
* indenting and casting
* harbour/source/rdd/dbfcdx/dbfcdx1.c
* cleaned typos in comments
+ harbour/tests/speedtst.prg
+ added speed test
* harbour/include/hbpp.h
* harbour/source/pp/ppcore.c
+ added HB_PP_TOKEN_ISNEUTRAL() macro to make code a little bit more
readable
* harbour/include/std.ch
+ added some missing old PP commands
* harbour/source/Makefile
* minor modification in order of compiled libraries
* harbour/source/pp/pplib.c
* changed the PP interface for .prg code.
Now following functions are supported:
__PP_INIT( [<cIncludePath>] [, <cStdChFile> ] ) -> <pPP>
initialize new PP context and return pointer to it.
when <cStdChFile> is empty string ("") then no default rules are
used only the dynamically created #defines like __HARBOUR__,
__DATE__, __TIME__, __PLATFORM__*
__PP_FREE( <pPP> )
free PP context.
__PP_PATH( <pPP>, <cPath> [, <lClearPrev>] )
add new (or replace previous) include paths.
__PP_RESET( <pPP> )
reset the PP context (remove all rules added by user or
preprocessed code)
__PP_ADDRULE( <pPP>, <cDirective> )
preprocess and execute new preprocessor directive
__PREPROCESS( <pPP>, <cCode> ) -> <cPreprocessedCode>
preprocess given code and return result
User can create more then one PP context and then use each of them
separately. Any modification in one context have no effect in other.
* harbour/bin/hb-func.sh
+ added linker parametrs to hbcc
* harbour/include/hbapi.h
+ added hb_retclenAdoptRaw()
* harbour/include/hbapifs.h
* harbour/source/common/hbfsapi.c
* changed first parameters of hb_fsAddSearchPath() to const char *
* harbour/include/hbclass.ch
* update for new PP. I think that now we can try to create final
version of our OOP rules.
* harbour/include/hbdefs.h
+ added UCHAR and SCHAR typedefs
* harbour/include/hbrddcdx.h
* indenting
* harbour/source/rdd/workarea.c
! fixed minor typo
* harbour/source/common/hbdate.c
* harbour/source/rtl/dates.c
* moved hb_dateToday() and hb_dateTimeStr() from RTL to COMMON library
- harbour/include/hbpp.h
- harbour/source/pp/ppcomp.c
- harbour/source/pp/ppcore.c
- harbour/source/pp/pplib.c
- harbour/source/pp/pptable.c
- harbour/source/pp/pragma.c
* harbour/utils/hbpp/Makefile
* harbour/utils/hbpp/hbpp.c
+ harbour/utils/hbpp/hbpp.h
+ harbour/utils/hbpp/ppcomp.c
+ harbour/utils/hbpp/ppcore.c
+ harbour/utils/hbpp/pplib.c
+ harbour/utils/hbpp/pptable.c
+ harbour/utils/hbpp/pragma.c
* moved all PP code to harbour/utils/hbpp
It's interesting and working preprocessor and the code can be
usable for some other things so I do not want to remove it.
Probablly we should move it to contrib/hbpptext
* harbour/include/hbcomp.h
* harbour/include/hberrors.h
* harbour/include/hbsetup.ch
+ harbour/include/hbpp.h
+ harbour/include/hbstdgen.ch
* harbour/source/common/hbstr.c
* harbour/source/compiler/Makefile
* harbour/source/compiler/cmdcheck.c
* harbour/source/compiler/harbour.c
* harbour/source/compiler/harbour.l
* harbour/source/compiler/hbgenerr.c
+ harbour/source/compiler/ppcomp.c
* harbour/source/pp/Makefile
+ harbour/source/pp/ppcore.c
+ harbour/source/pp/pplib.c
+ harbour/source/pp/ppgen.c
+ New PP code written from scratch. It works in similar way to
Clipper PP even the error codes are replicated. The code is MT
safe does not have any limitation on size of preprocessed code,
line, etc. It's also Clipper compatible lexer. It means that
we do not longer need FLEX or SIMPLEX which can be replaced
by new PP after some small modifications. Anyhow I haven't
decided to make it myself. I would like to agree with with the
rest of developers. I will be very happy if such modifications
will be done by someone else, Ryszard?
Meanwhile I current PP join on output the line tokens and give
the string line to FLEX/SIMPLEX. It does not have any sense and
all FLEX/SIMPLEX limitations are still existing. Ryszard, even
if we keep it then I hope you can remove at least FLEX line buffer
and use the one returned from PP.
Because string tokens in parsed line are converted to text which is
later once again decoded to tokens by FLEX I had to introduce new
string format which supports embedded string delimiters. I chose
modified version of xHarbour extension with escaped strings e"<sting>"
so now FLEX understand such strings and decode them like C escaped
strings. It means that you can use them also in the .prg code f.e.:
outstd( e"Hello\n\rWorld" )
The new PP is also noticeable faster. You should see the difference
compiling long files. The build in PP rules are generated automatically
by ppgen program created from source/pp/ppgen.c
I had to add to GNU source/pp/Makefile these two lines:
pptable.c : ppgen$(EXE_EXT)
./ppgen$(EXE_EXT) $(TOP)$(ROOT)include/hbstdgen.ch -opptable.c -q
Sth like that will have to be done also in non GNU make system.
Now Harbour can be compiled only using GNU make.
Marek can you update non GNU make files? I would like to leave this
modification to you or other developers who can test it.
It was quite big modification and I do not believe that I haven't
make any mistakes but I hope that in few weeks I'll fix any reported
bugs and it will resolve any PP problems.
TODO:
* error messages
create one common list of errors and warnings and keep it
in common library. PP and compiler can still generate different
errors with the same number. It can be confusing for the users
and hard to document and add i18n translations.
If possible we should also try to keep Clipper error numbers.
In new PP code I added Clipper error numbers but I cannot use
them until compiler code is not updated.
We should aslo remove the ctype passed to error functions and
hack with first character in warning messages and use only
error number. The codes from 1000 to 1999 should be warnings
where range 1000:1099 is activated by -w, 1100:1199 by -w1,
1200:1299 by -w2, etc. 2000:2999 are errors and 3000:3999
fatal errors. All compiler functions which generate an error
should expect that error function will not stop the compiler
but return and cleanly finished their job. It's necessary for
MT support in compiler and making compiler part of some other
programs which may still work and compile different source code.
* FLEX/SIMPLEX
remove them at all and add some final pass to PP to create
more precise tokens for grammar parser or at least add better
integration to remove some redundant code and existing limits.
* hb_inLine() support - it's broken in new PP but as I can see
it was never working correctly. I can add a hack to PP to support
hb_inLine() but I'm not sure it's worth to do. Maybe in few days.
+ harbour/include/std.ch
+ added new std.ch. It was created without using Clipper's std.ch.
It's quite possible that some rules are wrong and should be fixed
so please help. Anyhow I created a set of programs based on new PP
code generating all possible combinations of different commands I
collected from different source code, documentation and match patterns
of rules I was adding to new std.ch and then I was comparing .ppo
files generated by Clipper and Harbour so I do not expect any bigger
problems then some minor typos. I had to introduce some modifications
in spacing as workaround for FLEX/SIMPLEX which cannot properly decode
text preprocessed by Clipper after stringify.
* harbour/utils/hbpptest/pretest.prg
* updated for new PP
It reports 16 wrong translations but some of them are valid
and some others are caused by escaped string e"..." (one of hack
for FLEX/SIMPLEX support)
I also had to remove all spaces in comparison the results
because they were not Clipper ocmpatible at all. Ryszard please
look at it.
