fivedev/harbour-core
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
6,879 Commits 1 Branch 0 Tags
5e19a3c8fd6016e4a8cc02218caec7b68a8ea1c7
Commit Graph

4 Commits

Author SHA1 Message Date
Przemyslaw Czerpak
c448973306 2006-11-15 14:20 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) 
* harbour/include/hbapi.h
    + added
         void * pLex;
      member to HB_MACRO structure - it will be necessary for MT safe
      macro parser

  * harbour/include/set.ch
  * harbour/include/hbexprb.c
  * harbour/source/macro/macro.l
  * harbour/source/macro/macro.y
    * indenting, formatting and converting tabs to spaces

  * harbour/include/hbpp.h
  * harbour/source/compiler/ppcomp.c
  * harbour/source/pp/ppcore.c
  * harbour/source/pp/ppgen.c
  * harbour/source/pp/pplib.c
    * make HB_PP_TOKEN structure public for other code and changed
      public PP API to not force including static rules by programs
      which does not need them.
    + added basic API for using PP as lexer
    * divided HB_PP_TOKEN_MACRO to HB_PP_TOKEN_MACROVAR and
      HB_PP_TOKEN_MACROTEXT and mark
         [<keyword>][&<keyword>[.[<nextidchars>]]]+
      as HB_PP_TOKEN_MACROTEXT not pair HB_PP_TOKEN_KEYWORD and
      HB_PP_TOKEN_MACRO
      It allows easier integration PP as (macro)compiler lexer and
      fixes preprocessing [<keyword>][&<keyword>[.[<nextidchars>]]]+
      in some patterns.

  * harbour/utils/hbtest/Makefile
    + added PP library to linked library list

  * harbour/source/macro/macro.y
    + added seaport to use PP as lexer. It's disabled by default and
      can be enabled using by defining HB_PP_MACROLEX. It eliminates
      using FLEX or SIMPLEX lexer in macro compiler. Now it emulates
      the behavior of FLEX lexer because I wanted to minimize the
      modification but in fact because parsed token are freed when
      macro compiler finish its job then we can resolve RT memory
      leaks which apear during parsing wrong expressions. It will be
      enough to drop allocating memory for new terminal symbols and
      using them as is like in compiler. It will also quite nice
      simplify include/hbexpr*.c code and will allow to move some
      functions to COMMON library. I want to make also pure compiler
      code MT safe so I will have to add passing pointer to a structure
      with compiler context just like in macro compiler. It means that
      if we define a structure which will be common to compiler and macro
      compiler with local (not common) data stored in other structure for
      which will will keep only a pointer then we will be able to move most
      of include/hbexpr*.c code to common library. But I do not want to
      make farther modification without consultation without Ryszard.
      Also to make PP default lexer some farther modifications should
      be done in core PP code and include/hbexpr*.c files to not reduce
      the speed. Now using HB_PP_MACROLEX for sure will have to cause
      speed reduction in macro compiler. But if we make necessary
      modifications then we should keep at least the same speed or
      probably reach noticeable better results.
 2006-11-15 13:21:20 +00:00
Przemyslaw Czerpak
b560fd5a77 2006-11-14 13:50 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) 
* harbour/TODO
    * removed to resolved problems from TODO/TOFIX list

  * harbour/include/hbexprb.c
    * indenting and tab to spaces conversion

  * harbour/source/compiler/ppcomp.c
    ! fixed typo which cased that dump buffer was not ended
      with \0 character
 2006-11-14 12:51:34 +00:00
Przemyslaw Czerpak
c2b4a94705 2006-11-10 02:05 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) 
* harbour/include/hbcomp.h
  * harbour/include/hbpp.h
  * harbour/source/compiler/cmdcheck.c
  * harbour/source/compiler/hbusage.c
  * harbour/source/compiler/ppcomp.c
  * harbour/source/pp/ppcore.c
  * harbour/source/pp/ppgen.c
  * harbour/source/pp/pplib.c
    * restored support for old hb_inLine() syntax
    + added support for hb_inLine() to new PP. It can be enabled by
      -kI compiler switch. It's disabled by default.
      The new hb_inLine{} syntax is:
         [ <exp> ] hb_inLine [ ( [<params,...>] ) ] { [ <c_code> ] } [ <exp> ]
      <c_code> can contain new line characters.
      Nested hb_inLine{} in <params,...> is not supported. If you think
      it's important I can add it in few lines.
      This version does not break any valid Clipper syntax, hb_inLine is
      not reserved word and hb_inLine can be repeated many times in the
      same line. F.e. this code can be properly preprocessed and compied if
      you disable in compiler old hb_inLine() syntax and enable the new one
      by -kcI Harbour compiler switch:

         proc main()
         local hb_inLine := " (var) "
         ? hb_inLine{ hb_retc("inLine"); } + hb_inLine(" parameter ") {
              hb_retc( hb_parc( 1 ) );
              } + "!" + hb_inLine + hb_inLine() { hb_retc( ":-)" ); } + ;
           hb_inLine() + "{}"
         return
         function hb_inLine()
         return " func() "

      So from user point of view this version have real "inline" syntax.
      To be clear: I'm not a fun of any C inline extensions. They works
      only when we use .c code as compiler backend so the code which uses
      them cannot be used in .hrb files and any other format we will add
      in the future which do not support later C code compilation. F.e it
      will not work in compiler integrated with HVM or with .NET
      Anyhow if someone finds it useful then I think that it should be
      properly implemented. This is the reason I added the new version.
      The old one I left only for backward compatibility. It breaks any
      code which uses hb_inLine keyword can be used only once in a line
      and it does not have "inline" so IMHO it should not be enabled by
      default.
      I would like to hear your opinion about default compiler switches:
         1. should we disable both: hb_inLine() and hb_inLine {}
         2. should we disable hb_inLine() and enable hb_inLine {}
         3. should we disable hb_inLine {} and enable hb_inLine()
         4. should we enable both: hb_inLine() and hb_inLine {}

  + harbour/tests/hbinline.prg
    + added test code for new hb_inLine{} syntax

  * harbour/tests/inline_c.prg
    ! replaced direct access to HB_ITEM body by API function calls
 2006-11-10 01:12:49 +00:00
Przemyslaw Czerpak
437b04a8ea 2006-11-08 12:55 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) 
* 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.
 2006-11-08 12:06:17 +00:00