Przemek,
I've learned to accept that Harbour developers reserve the rights to rename
function names they borrow, to "rewrite from scratch" borrowed ideas and
extensions, to introduce borrowed yet modified syntax, all with complete
disregard to API or user code compatibility. Obviously the claim is that the
reasons are always noble, well justified, and have nothing to do with
xHarbour.
As far as I know, xHarbour does not include any idea borrowed from Harbour,
that was implemented in an intentionally incompatible manner. I hope that
Harbour developers will decide to compromise their infinite need to improve
on ideas borrowed from xHarbour, at least when such improvement breaks
compatibility. I also hope that Harbour developers will understand the value
of a unified user community, even if development efforts are not unified.
Please, let's move on to better things.
Ron
--------------------------------------------------
From: "Przemyslaw Czerpak" <dru...@acn.waw.pl>
Sent: Friday, April 24, 2009 8:38 AM
To: "Xharbour-Developers List" <xharbour-developers@lists.sourceforge.net>
Subject: Re: [xHarbour-developers] [Harbour] Some xhb
developersgivingnocreditwhen copying work from Harbour
> On Fri, 24 Apr 2009, Ron Pinkas wrote:
>> 3. For many years when the Harbour project was completely dormant,
>> practically all commits were borrowed from my work, or other xHarbour
>> developers, and I vividly remember how frustrating it was having to ask
>> for
>> due credit, and seeing it falling on death ears.
>
> I hope that you are not referring to me. For quite long time I was working
> on both projects and most of synchronization was my own code. Each time
> I was borrowing sth from xHarbour I was referring to this fact. Of course
> it's possible that I missed sth. In such case I'm very sorry and of course
> I'll immediately fix any missing information.
>
>> 4. Additionally, much of my work was borrowed, with just enough
>> modifications (f.e. renaming of API I introduced in fastapi.c) only to
>> avoid
>> giving me or xHarbour due credit. What makes that worse, is that even
>> COMPATIBILITY was sacrificed only to avoid mention of xHarbour.
>> F.e. I'd love to hear what was the critical reasoning to introduce:
>> hb_itemMove()
>> instead of borrowing xHarbour's:
>> hb_itemForwardValue()
>> and giving credit due?
>
>>From Harbour ChangeLog:
>
> 2003-01-26 16:20 UTC+0300 Alexander Kresin <a...@belacy.belgorod.su>
> * include/hbapiitm.h
> * source/vm/itemapi.c
> * source/vm/hvm.c
> * hb_itemMove() function added, which is intended for use instead of
> the
> hb_itemCopy( pDest,pSource )
> hb_itemClear( pSource )
> This allows to speed up some internal vm functions.
> The idea was borrowed from xHarbour.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>> There are dozens of such xHarbour based additions, that were introduced
>> to
>> Harbour with different names or semantics, only to avoid due credit, or
>> even a mention of xHarbour.
>
> Can you tell me about them? I'm very interested in clearing all such
> places. If some credits are missing then I'll add them.
>
>> I spent many years withOUT these childish arguments, and hope it will
>> take
>> few more years before I'm forced into such silly bickering, yet again.
>
> Probably I'm missing sth and you point me to exact things which we should
> clear in Harbour project and add missing credit notes.
> BTW few times in the past I've seen you said that sth was borrowed from
> xHarbour when it was not true. AFAIK most of xHarbour like extensions
> which are in Harbour core code were implanted from scratch without any
> references to xHarbour source code and internally use different
> implementation/solution. The funny is that this code is now ported to
> xHarbour.
> Few weeks ago I added timestamp support to Harbour. And here I
> intentionally
> hadn't look at xHarbour source code but made extensive tests of runtime
> behavior instead. I wanted to fully control each peace of code used
> in my implementation due to very important internal differences between
> both
> projects which might cause bad bugs if I would try to copy some code
> directly.
> The bad result of modification mad in such way is incompatible API but its
> not longer my priority to keep Harbour and xHarbour compatible though for
> quite long time I was investing a lot of time to keep them very close.
> The good is that these implementation resolves some problems which exists
> in xHarbour and because I was implementing everything from scratch I
> haven't
> replicated some small bugs which exist in xHarbour so now some peace of
> the Harbour code can be borrowed to xHarbour to fix them, f.e. check the
> result of this code:
>
> proc main()
> #ifdef __XHARBOUR__
> SET TIME FORMAT TO "hh:mm:ss.ccc"
> #else
> SET TIME FORMAT TO "hh:mm:ss.fff"
> #endif
> ? { ^ 2009/03/31 15:34:56.123 }
> return
>
>> On my part, I did NOT know that Miguel borrowed that code from Harbour.
>> In
>> the past I noticed number of Miguel's commit crediting Przemek. I regret
>> such due omission and I ask xHarbour developers to be EXTRA careful to
>> never
>> neglect due credit to any external source.
>
> I believe it was not intentional but in fact except few small
> modifications
> nearly everything what Miguel commited in last years in RDD, HVM and
> compiler
> code is borrowed from Harbour. And very often just like in the recent
> commit
> Harbour source code is directly copied. I have nothing against such
> modification and I'm happy that someone is finding my code useful but
> I think it's very good practice to leave at least some basic information
> about the source of such modifications. F.e. in the last commit the cvs
> diff -r1.290 -r1.290 for dbfcdx1.c has 215388 bytes and after this commit
> the diff between Harbour's dbfcdx1.c has 21109. So it was nothing more
> then
> taking Harbour source code and adding some of xHarbour modifications.
> IMHO quite reasonable full synchronization for easier updating in the
> future of course if developer understands all modifications and
> interactions
> with other code. Anyhow I expect to see some information about it in the
> ChangeLog.
> I hope that existing Changelog entries will be updated in both projects
> and any missing credits added.
>
> best regards,
> Przemek
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> xHarbour-developers mailing list
> xHarbour-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xharbour-developers
>
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
