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
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
Post by Przemyslaw CzerpakHi 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.
/*
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
&( "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
Post by Walter NegroHi, Ron
I'm fine, many responsability, working with xHarbour.
*** New Macro: >>>(file_alias = $1)<<< Len: 17
Starting parse
Entering state 0
Reducing Delimiter: '(' As: 40
Passing through: 40
Returning: 40
Next token is token '(' ()
Shifting token '(' ()
Entering state 23
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
$1 = token IDENTIFIER ()
-> $$ = nterm IdentName ()
Stack now 0 23
Entering state 26
Checking 28 Selfs for = At: >= $1)<
Reducing Delimiter: '=' As: 1085
Returning Dont Reduce 61
Returning: 61
Next token is token '=' ()
$1 = nterm IdentName ()
-> $$ = nterm Variable ()
Stack now 0 23
Entering state 38
Next token is token '=' ()
$1 = nterm Variable ()
-> $$ = nterm SimpleExpression ()
Stack now 0 23
Entering state 57
$1 = nterm SimpleExpression ()
-> $$ = nterm Expression ()
Stack now 0 23
Entering state 106
Next token is token '=' ()
Shifting token '=' ()
Entering state 197
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
$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.
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
--------------------------------------------------------------------------------
*:: VSTour.COM <http://vstour.com/> <http://www.vstour.com <http://www.vstour.com/>> :: *
Post by Ron PinkasHey 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
Post by Walter NegroProcedure 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
https://lists.sourceforge.net/lists/listinfo/xharbour-developers <https://lists.sourceforge.net/lists/listinfo/xharbour-developers>