PC Toledo

Código: Selecionar todos

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