Dear Przemek,
My sincere thanks, for your kind and generous email and suggestions.
I personally agree with practically all of your observations and suggestions,
with just few reservations.
1. GLOBAL scope ( which is also directly accessible by C code).
2. Name spaces.
3. I never believed that [x]Harbour must be ERROR compatible with Clipper.
Which is a conceptual principal difference. For example, for me supporting
NEGATIVE arguments in Array functions, seems a simple and intuitive extension
(which in my arrogant mind, Nantucket itself would have surely introduced along
those years). in Harbour such extension were refused, and blocked. Just to give
you some idea, if I remember correctly,the actual straw that made me decide to
fork Harbour was when I suggested simple extensions to the Clipper At()
function (by means of ADDITIONAL OPTIONAL ARGUMENTS), which would still keep it
100% backward compatible, yet Victor managed to convince the group to REFUSE
even such simple extensions, and instead force the introduction of a “new”
HB_At() with such extended functionality. Thus, xHarbour was born, and there
were many places where different decisions were taken in the implementation of
specific extensions (Ironically, many of them were imported back to Harbour,
when it was stagnant). and I sincerely can not imagine remembering almost any
of them. But I do remember few were vital (at least in my mind). Naturally one
could use an xHB.lib which overrides the default RTL in such cases. and/or
maybe an #ifdef can be used, etc., the problem is I am not sure anyone has a
COMPLETE LIST of all such INTENTIONAL DIFFERENCES, and some could even be
Compiler level, and or requiring collaboration of the Compiler.
Yet, in retrospect, having lost the desire/willingness to program in general,
and having stopped contributing to the development of xHarbour, and since no
one else really assumed an active roll in keeping it responsive. I must admit
that current Harbour is probably a better choice than the stagnant xHarbour,
and its probably worth it, giving up what ever issues do exists, in return for
a much improved overall product.
In response to your question, I would vote YES, but I believe it should be a
community decision, made by the current active members on this developer list.
Again, my most sincere thanks, for your many years of so many great
contributions, as well as your kindness and consideration of xHarbour.
Ron
> On Apr 26, 2016, at 5:52 PM, Przemyslaw Czerpak <dru...@poczta.onet.pl> wrote:
>
> 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
> <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://vstour.com/
>>>> <http://vstour.com/>> <http://www.vstour.com <http://www.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> <mailto: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> <mailto: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>
>>> <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>
>>> <mailto: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>
>>> <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
