Hi Ron, Sorry for late response. I'm very busy recently. Because my message below I address to all xHarbour developers I'm setting CC to xHarbour devel list.
I do not think it's worth to port single modifications from Harbour to xHarbour. Just simply it's full time job for many months. There are many different things which should be ported and it will be very hard to avoid bugs in this process. Much simpler would be take current Harbour code and add xHarbour extensions which are missing. There are only few of them which we decided to not add to Harbour core code. Many of them where implemented in Harbour in XHB library without touching the core code though in some cases with a little bit changed behavior. If you want to add it to core code then I have nothing against I would only want to cover them by #ifdef __XHARBOUR__ macro just simply to keep the code as close as possible for future synchronization. I can help in this process but only if other xHarbour developers agree with this idea and can help at least reporting differences. What are the main drawbacks of such synchronization: - in Harbour we hide internal HVM structures so 3-rd party C code programmers which want to access them directly have to include hbvmint.h - there are some differences between internal structures so 3-rd party C code which exploits them have to be updated. Above are the simplest methods to update existing 3-rd party xHarbour C code though not suggested one. As preferred solution I strongly suggest to use only documented API because it does not block adding new [x]Harbour improvements and extensions. Just simply most of things in core code can be changed and such modifications do not break exiting code using official API (this functionality allows Harbour to have only one library HVM which is needed to chose between ST and MT modes). This API is also precisely defined (i.e. const attribute) so it helps programmers to find potential bugs and create correct code. Because core structures are not directly accessed then Harbour users does not have to replicate the same C compiler switches as the ones used to compile core code just to keep the same alignment. The visible structures where slightly changed just to force the same alignment though this part is not finished yet - so far I haven't changed some structures which would force 3-rd party code upgrades, I plan to make it but to not increase the cost for Harbour users I want to make it once probably with some stable release. What are the main profits: - Harbour gives much better optimized PCODE and faster HVM code. On pure PCODE evaluation Harbour is nearly twice faster then xHarbour. - Much cleaner API which does not block introducing new modifications due to backward compatibility. - Smaller memory overhead, i.e. depending on used alignment and 32/64 bit mode even simple HB_ITEM structure is between 25% to 50% smaller so less memory is used and many operation faster, i.e. ADel() or AIns() because smaller memory blocks have to be updated (it also gives better CPU cache usage). Also memory fragmentation in Harbour is noticeable smaller then in xHarbour. - Completed and in practice finished MT mode which allows to write big production ready servers. Only one library have to be replaced to converts ST program to MT one: HVM -> HVMMT. The overhead of MT mode is also much smaller the total speed difference between Harbour and xHarbour so Harbour MT programs are still much faster then xHarbour ST ones. - Automatic optimization of many operations which are not optimized in xHarbour at all or optimized only when programmer explicitly add code to enable such optimization, i.e. array resizing or hash tables which do not need separate associative array functionality because it exists by default and the implementation is faster then xHarbour one. - Many new features like socket filters, replaceable file IO drivers, etc. - Really big number of fixes and much better Cl*pper compatibility. - Support for new platforms, i.e. WinCE/Mobile, Android, OSX, AIX, Minix, QNX, BEOS/Haiku. - Rewritten compiler code which is reentant and MT safe without any memory leaks so Harbour compiler can be used in user code to compile and execute PRG code though here programmer should remember that compiler library is pure GPL code. Basic HBRUN which uses Harbour compiler library and gives all xbscript functionality but with really native speed was written in few lines. - Many others things - the total list is really long, read: https://github.com/harbour/core/blob/master/doc/xhb-diff.txt if you need more information and ask about details if necessary. So my final question is: Are you interesting in taking current Harbour code and adding xHarbour extensions which were not ported to Harbour core code and you think are important just to keep base code for both compilers as close as possible. In practice it would mean also that well written 3-rd party code for both compilers is compatible. I can help in many places though I hope that some standalone contrib libraries can be ported by their authors or at least active users. best regards, Przemek On Thu, 21 Apr 2016, Ron Pinkas wrote: > Many thanks for your help Przemek. :-) > > Please fell welcome to import your compiler expression GCs to xHarbour. We > would all be very grateful. > > Best regards, > > Ron > > > On Apr 20, 2016, at 1:02 PM, Przemyslaw Czerpak <dru...@poczta.onet.pl> > > wrote: > > > > Hi Ron and Walter. > > > > The problem can be exploited by many different > > syntax errors. > > When syntax error appears we cannot trust that > > our expression destructor is executed because > > we do not know where exactly the error was > > detected by bison and if all sub expressions > > created so far have internal bindings which > > allow to free them all. > > Bison has %destructor directive which can help > > to resolve such problems with memory leaks but > > it needs well defined grammar rules which do > > not overwrite expressions on the bison stack > > and expressions which are still on bison stack > > do have internal bindings used in their > > destructors. In [x]Harbour none of the above > > is true so %destructor cannot be used. > > > > I left this note in harbour.y: > > > > /* > > We cannot use destructors for expressions. The internal bison logic cannot > > detect properly if the expression was used or not in our grammar > > definition > > so it's possible that destructors will never be executed or executed for > > expressions which we freed ourselves. > > > > %destructor { > > HB_COMP_EXPR_FREE( $$ ); > > } > > Argument ArgList ElemList ... > > */ > > > > For this example you can change grammar rules > > just to force execution of expression destructor. > > But it's not general solution because in a while > > someone else may create other example with completely > > different code with syntax syntax error, i.e.: > > &( "a[1" ) // one not freed expression > > or > > &( "a(b(c(d(e" ) // four not freed expressions > > > > The simplest solution for this problem is > > implementing garbage collector for generated > > expressions in macrocompiler and also in > > compiler if you ever plan to add support for > > runtime PRG code compilation and evaluation. > > I implemented such GC-es in Harbour about 10 > > years ago so you can port them to xharbour. > > BTW There are many other things which should > > be fixed in xHarbour macrocompiler. Just look > > at ChangeLog in Harbour for modifications > > related to macro/macro.y > > > > best regards, > > Przemek > > > > > > On Wed, 20 Apr 2016, Walter Negro wrote: > >> Hi, Ron > >> > >> I'm fine, many responsability, working with xHarbour. > >> > >> Adding debug to parser I have this sequence: > >> > >> > >> *** New Macro: >>>(file_alias = $1)<<< Len: 17 > >> Starting parse > >> Entering state 0 > >> Reading a token: > >> Reducing Delimiter: '(' As: 40 > >> Passing through: 40 > >> Returning: 40 > >> Next token is token '(' () > >> Shifting token '(' () > >> Entering state 23 > >> Reading a token: > >> Checking 4 Streams for E At: >e_alias = $1)< > >> Token: "FILE_ALIAS" Ommited: ' ' > >> Pre-Scaning Words for Token: FILE_ALIAS at Positions: 1-1 > >> iLenMatch 10 > >> iKeyLen: 5 iLen2Match: 10 comparing: [FILE_ALIAS] with: [FIELD?WS?->] > >> Trying Next Word Pattern... [FILE_ALIAS] > [FIELD?WS?->] > >> Continue with: [HAS] > >> Reducing Element: "FILE_ALIAS" > >> Element "FILE_ALIAS" is 258 > >> Passing through: 258 > >> Returning: 258 > >> Next token is token IDENTIFIER () > >> Shifting token IDENTIFIER () > >> Entering state 86 > >> Reducing stack by rule 8 (line 379): > >> $1 = token IDENTIFIER () > >> -> $$ = nterm IdentName () > >> Stack now 0 23 > >> Entering state 26 > >> Reading a token: > >> Checking 28 Selfs for = At: >= $1)< > >> Reducing Delimiter: '=' As: 1085 > >> Returning Dont Reduce 61 > >> Returning: 61 > >> Next token is token '=' () > >> Reducing stack by rule 30 (line 533): > >> $1 = nterm IdentName () > >> -> $$ = nterm Variable () > >> Stack now 0 23 > >> Entering state 38 > >> Next token is token '=' () > >> Reducing stack by rule 109 (line 820): > >> $1 = nterm Variable () > >> -> $$ = nterm SimpleExpression () > >> Stack now 0 23 > >> Entering state 57 > >> Reducing stack by rule 126 (line 839): > >> $1 = nterm SimpleExpression () > >> -> $$ = nterm Expression () > >> Stack now 0 23 > >> Entering state 106 > >> Next token is token '=' () > >> Shifting token '=' () > >> Entering state 197 > >> Reading a token: > >> Reducing Delimiter: '$' As: 1060 > >> Returning Dont Reduce 36 > >> Returning: 36 > >> Next token is token '$' () > >> Error: popping token '=' () > >> Stack now 0 23 106 > >> Error: popping nterm Expression () > >> Stack now 0 23 > >> Error: popping token '(' () > >> Stack now 0 > >> Shifting token error () > >> Entering state 1 > >> Reducing stack by rule 7 (line 359): > >> $1 = token error () > >> Cleanup: discarding lookahead token '$' () > >> Stack now 0 > >> > >> source\vm\fm.c:971: HB_TR_ERROR Block 1 00923AA8 (size 11) MAIN(10), > >> "FILE_ALIAS." > >> source\vm\fm.c:971: HB_TR_ERROR Block 2 00A5A2D0 (size 40) MAIN(10), > >> "A83A92000000000010D6E80000000000010002008000000000000000010000001A00000000000000" > >> > >> > >> Testing several expression to force error and reduce stack by rule 7, i > >> found that other expression free memory using s_Pending. > >> > >> If code is: > >> > >> file_alias = $1 > >> > >> the stack is reduced by rule 6 > >> > >> I test adding a rule > >> > >> | '(' Expression error > >> > >> similar to > >> > >> | Expression error > >> > >> and the parser reduce in this rule instead of rule > >> > >> | error > >> > >> and now no more memory leaks, but is this a correct solution? > >> > >> Thank you > >> > >> > >> > >> > >> *Walter Negro* > >> Desarrollo e Investigación > >> VsTour - Softmagic S.R.L. > >> ( 54 ) ( 11 ) 5218-6616 > >> Av. Corrientes 2294 Piso 7 Of.33 > >> C1046AAN - Buenos Aires - Argentina > >> wne...@vstour.com > >> -------------------------------------------------------------------------------- > >> *:: VSTour.COM <http://vstour.com/> <http://www.vstour.com > >> <http://www.vstour.com/>> :: * > >> > >> 2016-04-19 16:53 GMT-03:00 Ron Pinkas <ron.pin...@xharbour.com > >> <mailto:ron.pin...@xharbour.com>>: > >> > >>> Hey Walter, :-) > >>> > >>> (How are you?) > >>> > >>> How much memory, and what is stored int it? > >>> > >>> We need to follow the EXPRESSION TREE, and find which element is not > >>> released. > >>> > >>> It should be a Parenthesized Exp, which has a single element, being an > >>> EQUATION where the left side is the IDENTIFIER file_alias, and the right > >>> side is where the syntax error occurs as $ was encountered. > >>> > >>> We must be sure that the pending expression (the Parenthesis ) is released > >>> as well as the expression of the current token (the $ operator). > >>> > >>> Ron > >>> > >>>> On Apr 7, 2016, at 12:35 AM, Walter Negro <wne...@vstour.com > >>>> <mailto:wne...@vstour.com>> wrote: > >>>> > >>>> > >>>> Procedure Main() > >>>> > >>>> TRY > >>>> // ? &( "file_alias = $1" ) // No memory leaks > >>>> ? &( "(file_alias = $1)" ) // Memory leaks > >>>> CATCH > >>>> ? "Catched" > >>>> END > >>>> > >>>> Return > >>>> > >>>> --------------------------- > >>>> This code > >>>> &( "file_alias = $1" ) > >>>> > >>>> End in the rule (macro.y) > >>>> Main : Expression error > >>>> > >>>> --------------------------- > >>>> This code > >>>> &( "(file_alias = $1)" ) > >>>> > >>>> End in the rule (macro.y) > >>>> Main : error > >>>> > >>>> I not understand how to fix the rule or > >>>> > >>>> Walter Negro > > > > ------------------------------------------------------------------------------ > > Find and fix application performance issues faster with Applications Manager > > Applications Manager provides deep performance insights into multiple tiers > > of > > your business applications. It resolves application problems quickly and > > reduces your MTTR. Get your free trial! > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > > <https://ad.doubleclick.net/ddm/clk/302982198;130105516;z> > > _______________________________________________ > > xHarbour-developers mailing list > > xHarbour-developers@lists.sourceforge.net > > <mailto:xHarbour-developers@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > > <https://lists.sourceforge.net/lists/listinfo/xharbour-developers> ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers