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. 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. 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. Ron On Jan 19, 2013, at 2:24 PM, Przemyslaw Czerpak <dru...@poczta.onet.pl> wrote: > On Sat, 19 Jan 2013, Andi Jahja wrote: > > Hi Andi, > >> Seems no comment at all, particularly from what ppl call *nix users. BTW, >> does anyone here have a thought about it? > > I think that xHarbour lost most of them. > >> FYI, we stuck releasing versions officially because there's no-one >> interested in building that *nix stuffs. > > In the last year you made a lot to break *nix builds. Now after your > recent modifications you break them again so maybe few really advanced > users who are patient enough to fix your modifications can create *nix > xHarbour builds - others migrated to Harbour. > >> I would suggest to leave *nix if there's no longer interest in it. >> Usability is much more important than what is called portability. >> Furthermore, I'd swear that 99.99% of xHarbour users are on Windows OS, >> so the rest 0.01% can be disregarded (read: not worthy) > > Bad idea, it will only help to hide bugs which appeared recently in > xHarbour. Some of them can be exploited also on MS-Windows, i.e. custom > memcpy() broke all 64bit builds. Also WIN 64 ones though here xHarbour > applications GPFs when user address space reach 2^32. On serious platforms > such addresses are default at application startup just to catch such buggy > code ASAP and fix it. To be more funny advanced compilers make such > optimizations much better with optimized autoinlined code so it also > reduces the speed. > > There are other serious development reasons to keep support for *nixes, > i.e. there is no tool like VALGRIND for MS-Windows so you won't be able > to catch some serious problems, i.e. I see that in last weeks you started > to fix memory leaks in xHarbour compiler code. But you haven't discovered > yet that it's not possible to make it well in classic way due to bison > behavior. Bison authors also saw this problem so they introduced > expression destructors which should help in such process. Anyhow these > functionality still does not work as expected in some cases what can be > well seen in valgrind logs and you want to drop support for platforms > were such important tool can be used. In practice it means that there is > very small chance that you will ever reach sufficient results in compiler > memory leak fixes. > BTW I've seen your message on xHarbour user list that such memory leaks are > only in compiler. It's not true. Memory leaks which appear due to wrong > syntax are usually caused by unreleased bison grammar expressions so they > exist also in macrocompiler and are runtime memory leaks which can be > exploited in all programs which macrocompile user expressions. > To resolve this problem in Harbour few years ago I created garbage collector > for expressions. To not hide other memory leaks in compiler mode it's > activated on syntax errors only. This job is still before you and you want > to drop support for platform were important helper tools can be used. > Finally it means that you want to drop support for platforms which begins > to be the most popular one on the all world used in most "smart" devices > so it will be very important signal about xHarbour future for users. > >> We should not stop because of it. > > IMHO before new release you should fix some critical problems introduced > in last months. > Porting some things from Harbour you made few typos which later have > unpredictable results, i.e. typo in really small patch which fixed very > slow source code browsing in debugger caused that Luiz (who wrongly check > that the problem was fixed in Harbour) used in xHarbour debugger RTL > classes so now it's not possible to debug them or even use debugger by > users who overloaded some part of RTL classes used in debugger. > Your "improvements" in macro compiler speed caused that now maximum > macrocompiler string size is 8191 bytes in xHarbour. Before your > modifications it was ~32768 and longer strings could cause unpredictible > results (memory corruption) due to bugs in HVM part of macro compiler > code. In Harbour all such bugs have been fixed long time ago and it's > guarantied that Harbour can compile any macro expression up to 16MB and > if longer expressions cannot be compiled then it's guarantied that clean > RT error is generated without any hidden memory corruption. And to compare > Harbour macro compiler is about 3 times faster then xHarbour ones and is > fully reentrant safe so it does not need and MT locks. The whole MT mode > in xHarbour is sth what should be rewritten from scratch. Now number of > MT applications in [x]Harbour community is growing up and they have to > be compiled by Harbour because xHarbour MT mode is unusable for code which > needs stability and some more advanced MT functionality. Good example is > LETO server which cannot be compiled by xHarbour due to critical xHarbour > bugs, missing functionality and wrong MT model. > There are also other problems introduced recently like wrong casting which > pacified warnings when in fact they were bugs exploited in 64bit mode. Now > it's horrible job to clean xHarbour code and make it fully functional for > Win64 bit mode - you hide the most helpful thing: compiler warnings so > you will have to find someone who will check whole xHarbour code line by > line and fix all related code. Of course at the beginning he should have > clear vision what should be done and which types should be used. I do not > thing it's possible to realize it in resonable time so this should not > stop you anyhow I signal serious problem. > > I'll only add that you may have problems with code copied from Harbour. > xHarbour GC does not support custom user mark functions so you should > expect random memory corruptions after GC activation. Very hard to > locate and fix problems. Unlike Harbour xHarobur does not detect them > automatically so it will cause random GPFs in different subsystems. > User will report them but fixing such things using information from > users is like fighting with a ghosts so I strongly suggest to do sth > with it. > > 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_122912 > _______________________________________________ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers ------------------------------------------------------------------------------ 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/learnmore_123012 _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
