Hi Przemek, > I agree. Both projects benefited from each other. > A lot of code was borrowed from Harbour to xHarbour and from xHarbour to > Harbour after the fork. Also ideas were shared even if the implementations > were completely different.
:-) > I can try to help you in some spare time but recently I'm really busy > due my business jobs and so called "spare time" is something really rare > in my life :( > Please only remember that I was not alone in Harbour modifications in > last years. Viktor made really great job in general code and used types > cleanup. Mindaugas added important extensions to compiler and HVM/RTL > code, Pritapl is extensively working on set of addons like HBIDE, HBQT, > HBXBPP. Also many other people worked on Harbour. Thanks for your modesty, but I am convinced that none of this would ever take place, unless you first revived Harbour, single handedly, as you did, and even after, those IMO, are minor, and superficial contributions, compared to your work. :-) > If you think about real milestone in xHarbour developing then I would like > to say sth what may be a shock for you but I strongly suggest to seriously > rethink it before you answer. > Updating current xHarbour code will be time consuming process which in > practice would mean that Harbour code is copied to xHarbour and then > adopted. Many problems and bugs can appear even due to stupid typos. > So I suggest you to create new branch and copy whole current Harbour code > just as is. Then working on this branch add or enable xHarbour extensions > you think are really usable. Some of them you can be added as > modifications > in core code some others in separate libraries. As you can see most of > xHarbour extensions were replicated in Harbour inside XHB library so it > should not be hard job. > If you want we can discuss each of them before commit and I'll try to > tell you how it can be implemented and how it may interact with some > other code or future extensions. > This should help to sync code between both projects what can help in > the future in code exchanging, i.e. 3-rd party projects can work with > both Harbour and xHarbour without or with minimal modifications. > In Harobur there is text filewhere I tried to discribe main differences > between both projects: > http://http://harbour-project.svn.sourceforge.net/viewvc/harbour-project/trunk/harbour/doc/xhb-diff.txt?view=log > This may show you what should be done. I'll try to update this file > and add some information about other differences. > As you can seen not too much. I think that in less then month all > modifications can be finished. Actually this is not shocking for me, and I was debating it my self. I am not sure what would be easier, as it mostly depends on the DRIVE of the specific individual[s] interested in caring this task. Sadly, I am not in a position to volunteer for this Job, for many personal reasons, so I can not suggest what would be easier. I trust that the person willing to take on this Job, will have his preference. > The main problem I can see are some classes like TBROWSE, TGET and > TIP library. The RTL TBROWSE and TGET classes in Harbour are much > more compatible with Clipper then xHarbour ones. It greatly helps > Clipper users but may create some problems for xHarbour users who > used some specific to xHarbour only behavior. Probably it will be > necessary to keep the previous implementation in separated library, > i.e. as TBROWSEOLD. The TIP library is sth what I do not want to > comment - I'm not familiar with this code. I have no idea how it's > compatible with Harbour. Agree. > The windows only extensions and windows API wrappers have WIN_ and > WAPI_ prefixes in Harbour and are part of HBWIN library. I think it's > good solution because it well separates non portable MS-Windows only > code what helps users to create portable programs and isolate local > to system extensions. Agree, except, I would in general prefer resolution by means of namespace support. IMO, NameSpaces are critical feature of any modern compiler, and long ago we should have implemented and standardized namespace usage to have code like this: USING NAMESPACE Clipper To force usage of STRICT Clipper compatible RTL Functions, vs. USING NAMESPACE Harbour To prefer EXTENDED Clipper RTL. or of course manual overrriding: Clipper.SubStr(...) vs. Harbour.SubStr(), etc. As well as: USING NAMESPACE Windows I hope you agree that it is more flexible, and elegant, then using prefixes. > xHarbour support directly windows printers in SET PRINTER TO command. > Harbour doesn't so it have to be added. I would suggest to make it > using replaceable FILE IO API so it won't be necessary to introduce > platform oriented code to HVM. It also add possibilities to register > other printing systems, i.e. for terminal server programs. Agree. > The namespace support is sth what you will have to make yourselves. > I'm not familiar with this code. It has been many years since I wrote it, and I know it is not 100% elegant, due to reliance on PP code, and having to use multiple compilation when cyclic reliance between 2 sources exists, but I believe it to be very complete and stable, and it offers great flexibility and full namespace support, to both C code, and PRG code, as well as Macro executed code. I would strongly appreciate your review \xharbour\doc\namespaces.txt for the full set of functionality it offers, in terms of a Namespace MODEL, then we could discuss the code, which I am really much less interested in. > When the base version will be ready people can begin tests and if > they report some missing functionality then it can be added. > Please also note that you can make next release using current SVN > code. I even suggest to do that so without any time pressure from > users you can work on new code in second branch. > Harbour is much more restrictive in some cases then xHarbour, i.e. > it hides many internals so they can be used by 3-rd party code. > Fortunately in last years most of 3-rd party projects have been > adopted to Harbour so it should not be a problem for them though > for sure some code will have to be updated. Agree, I have always been in favor of a solid API, and was just as frustrated as you, by wild and unsafe use of internals, by developers. :-) > In Harbour compiler can be used at runtime. It means that > program which works like xBaseScript can be implemented in just few > lines and .prg files are executed with full speed just like > after -gc2 compilation. Interesting - what about the copyright exception which was NOT given to the Compiler sources? > I even create hbscript which can be used as active script in > MS-Windows. I haven't committed it yet. It covers similar functionality > from xHarbour.com - I tested it with xHarbour examples and they > worked well. Very good :-) > The real problem can appear at runtime and is caused by binary > compatibility with older code. > HB_SERIALIZE() gives incompatible results. It means that > HB_DESERIALIZE() from Harbour cannot decode data encoded by > current xHarbour HB_SERIALIZE(). > HB_SERIALIZE() is used by SQLRD so this problem is not such trivial > because it may block migrating to new xHarbour version. > Probably this can be resolved adding support for signatures used > by xHarbour in serialization code. I haven't though about it > before. I'll look at it closer and if it's possible I'll commit > such patch to Harbour. Saw you already committed. :-) > The exception ic created by codeblocks. They cannot be desrialized even > if you copy codeblock serialization code from current xHarbour to Harbour > due to differences in PCODE. It's possible to write translation > function though in general it's problematic extension which needs > other solution to make it really functional. I.e. xbase++ stores > with codeblock their string representation which is later used in > serialization code. In deserialization such strings are macrocompiled > Simple solution but I haven't checked how they resolved some potential > problems like access to static functions or values of detached locals. > Mayve they added support for context in macrocompiler or maybe they > do not touched the problem at all. > In the past I made some runtime tests and they show that xbase++ > documentation is often very far from real behavior in problematic > places. Yes, It is possible to create an Expression De-Compiler, and add support for LOCAL/STATIC( <pFunctionContext>, <LocalNumber>, <nDetach-ByRef-Etc-Flags> ), so that Block can be stored as decompiled expression, including references to lexically scoped variables, and recompiled on demand, allowing access to the same variables, without naming info. Of course, security could be an issue, unless codeblocks added a metadata, of context authorization, which would be required when Macro Compiling. > hb_valToExp() gives different results then ValToPrg() but in fact > Harbour creates real expressions which can be macrocompiled so it's > rather like a fix for current xHarbour behavior. Mmm, are you not aware of xHarbour's ValToPrgExp()? > I believe that you can quite fast catch all such differences and > agree what to do with them. Yes, tough I suspect there are many more hidden, such as extension to Clipper RTL functions, that in Harbour were either not implemented, or implemented as new HB_<SomeFunc>(). > HTH. Always appreciated. >> BTW, again I would like to offer my sincerest apology, for having >> offended >> you, many years ago. I give you my word again, that I sincerely did not >> mean to be offensive, it was a simple misunderstanding due to a language >> difference. Now that I have lived for some 7 years, in a non English >> speaking culture, I better understand why you got so offended from the >> term "creature", but I gurantee you that in English, the the phrase, >> "what a funny creature, you are" is not used in that offensive context, >> rather, it is a fairly common, synical phrase. Eitherway, please accept >> my sincere apology. > > Let's forget about it and all other unnecessary personal digressions > from the past. Yes, of course, but it is very important for me that you KNOW, that I never, ever, would have intended to offend you as you perceived it. We had many arguments and heated discussions, and most of them, for me, had to do with me trying to convince you to be more respectful toward others, because in your crusade for technical perfection, IMO, you were being very harsh with your critical comments, and so, I can assure you, that resorting to PERSONAL OFFENSES was NOT what I would consider a good response. > best regards, Greatly appreciated, and returned. :-) Ron ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
