On Sun, 20 Jan 2013, Ron Pinkas wrote: Hi,
> I fully agree with Przemek, that we can NOT aford to drop support for Linux. > There are too many reasons to count, and Przmek did mention most of them. > I would only add, that many prospective open source contributors are Linux > users. > > As to the other obsevations and comments of Przemek, I must sadly agree. > It is time for a serious cleanup of our code base, and a serious commitment > to avoid localized hiding of Compiler warnings. > > Finally, I would like to personally invite Przemek, to help us. I sincerely > believe that you, Przemek, understand the important role of xHarbour in the > development of Harbour, and I hope that you do recognize that the difference > in spirit, between the 2 projects is still very important. While at THIS > point in time, we are clearly behind, in terms of stability, performance, > and code quality, we still pionereed many innovations, and for many years > it was Harbour, that was dormant, and clearly behind. I hope you agree that > Harbour would not be what it is today, without xHarbour. 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. > Przemek, since you personally have revived Harbour, practically > single-handedly, and you are intimately familiar with all the issues > that you already fixed, and rewrote, for Harbour, I would like to > wholeheartedly invite you, to help us, so that our creative differences > may once again bring new life to both projects. 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. 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. 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. 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. 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. The namespace support is sth what you will have to make yourselves. I'm not familiar with this code. 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. 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. 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. 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. 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. 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. I believe that you can quite fast catch all such differences and agree what to do with them. HTH. > 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. best regards, Przemek ------------------------------------------------------------------------------ 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
