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
