Hi Ron, Thank you for your message. I apologize that I was not answering for such long time. Now I'm extremely busy with adopting my programs to SAF-T in Poland: https://www.pwc.ch/news/en/26707/poland-introduce-standard-audit-file-tax-saf-t-1-july-2016 http://www.internationaltaxreview.com/Article/3549775/Poland-Incoming-reporting-changes-in-Poland.html and this will not change in next weeks. As soon I'll find spare time (I hope in a month) I would like to return to this subject and I'll comment your message. Sorry again.
best regards, Przemek On Fri, 29 Apr 2016, Ron Pinkas wrote: > 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>> > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
