2008-05-21 13:00 UTC+0700 Andi Jahja
- include/hbcomprs.h
* file is no longer required, hence removed.
* source/compiler/harbour.c
! in generated C files, __PRG_SOURCE__ now include path when available
* source/compiler/gen.c
! minor fix on hb_compGenCAddProtos() to only declar
2008-05-2 23:00 UTC-0430 Ron Pinkas
* source/vm/arrays.c
* Bad typo I introduced in my last commit
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atd
Brian,
IMO, Victor's answer is nothing but a poor attempt at an excuse. He
doesn't list any technical reason what so ever. IMO, there was no
reason what so ever to change the name. If the name would not be
changed there would NOT be:
- Any "environment variations".
- "higher priority" c
Ron:
> I was just annoyed
> at the lack of interest in preserving compatibility. This is not the
> first and probably not the last time we have to deal with name
> changes in Harbour sources, for no reason at all.
I had the same first reaction, that preserving compatibility should
have more impor
Ron:
> > SET ADS_LIB_VERSION=710
> This appears to be a mindless change - why would the define name NEED
> to be changed?
I wouldn't characterize it as mindless, though by the
time it was fully evolved it may not have *needed* to change
but still might be better to change. I can see where having
Brian,
As I said, I will support what ever you'll decide. I was just annoyed
at the lack of interest in preserving compatibility. This is not the
first and probably not the last time we have to deal with name
changes in Harbour sources, for no reason at all.
Ron
On May 20, 2008, at 11:11 A
2008-05-21 01:30 UTC+0700 Andi Jahja
* contrib/hpdf/*.*
* contrib/hpdf/test/*.*
* contrib/png/*.*
* makefile.bc
* makefile.vc
* makefile.dc
* makefile.gc
* makefile.wc
* contrib.pc
* common.mak
* compile.mak
* mdir.bat
+ libharu and png sources for hbhpdf.lib
--
Andi
Ron:
I can only guess the approach he chose might require less calls to
#undef ... and either approach would have worked the same but
now for the sake of making things simpler to compare with any
changes features vs Harbour it just keep things as simple as
possible.
At this point I'd say Brian wo
Sorry, I still can't understand. I see no reason why the name must be
changed. What would be the problem with:
#if ADS_REQUIRE_VERSION == 5
#undef ADS_REQUIRE_VERSION
#define ADS_REQUIRE_VERSION 500
#elif ADS_REQUIRE_VERSION == 6
#undef ADS_REQUIRE_VERSION
#define ADS_REQUIRE_VER
Ron:
I believe it's due to the fact that it would be difficult to
compare single digit vs triple digit values in the constants
being that they are not strings, but also in the way Viktor
implemented the auto-detect feature:
From rddads.h in the harbour svn:
#include "ace.h"
/* Autodetect ACE v
> ADS_REQUIRE_VERSION becomes obsolete so you should not
> define it. Instead, you would use ADS_LIB_VERSION as in
>
> SET ADS_LIB_VERSION=700
> or
> SET ADS_LIB_VERSION=710
>
> depending if your users have 7.0 or 7.1
>
> And then build rddads.lib
This appears to be a mindless change - why would
ADS adds functions and features on incremental releases, so the
major-version-only usage of ADS_REQUIRE_VERSION was problematic
in accurately isolating code to match libs and dlls.
In the Harbour project, Viktor created a new more accurate
ADS_LIB_VERSION to handle 3 or more digits of version#s
2008-05-20 20:00 UTC+0300 Pavel Tsarenko
* common.mak
* compile.mak
* added source/ct/setlast.c to compile
Best regards, Pavel Tsarenko-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R)
Toninho:
> Brian, ...I agree with Ron, but I have one doubt about:
> >ADS_REQUIRE_VERSION issue; Viktor has replaced it with a better
> >#define as part of his "auto-detecting" ...
> I, for example: have ADS 9.0 installed in my machine for tests
> pourposes, but I always compile RDDADS with ADS_R
Toninho:
Auto-detect isn't mandatory. I've been testing Viktor's changes and they
work just fine once you do the minor adjustments to you compile
environment.
ADS_REQUIRE_VERSION becomes obsolete so you should not
define it. Instead, you would use ADS_LIB_VERSION as in
SET ADS_LIB_VERSION=700
Ron,
given that Eduardo has a collection of applets to test, we could start by
testing them (I mean, if Eduardo wants to do this test).
I agree with you that a rewrite, sometimes, is a better thing than several
years of patches.
Looking at the code it seems to me that Przemyslaw tbrowse is super
-Messaggio Originale-
Da: "Ron Pinkas" <[EMAIL PROTECTED]>
A: "Enrico Maria Giordano" <[EMAIL PROTECTED]>
Cc: "Patrick Mast, xHarbour.com" <[EMAIL PROTECTED]>;
"xHarbour-Developers"
Data invio: martedì 20 maggio 2008 13.37
Oggetto: Re: [xHarbour-developers] Time for a release?
> Enric
Maurilio,
I didn't.
Eduardo
- Mensagem original
> De: Maurilio Longo <[EMAIL PROTECTED]>
> Para: Eduardo Fernandes <[EMAIL PROTECTED]>
> Cc: Xharbour-Developers List
> Enviadas: Terça-feira, 20 de Maio de 2008 8:10:32
> Assunto: Re: [xHarbour-developers] Res: ChangeLog,v 1.6101 2008/0
>Brian,
>I completely trust what ever your decision will be.
>Ron
Brian, Thanks for your great job. I agree with Ron, but I have one
doubt about:
>We should start a separate thread on the
>ADS_REQUIRE_VERSION issue; Viktor has replaced it with a better
>#define as part of his "auto-detecting" th
Enrico,
There's a problem with converting all NILs to OleDefaultArg() because
we have no way to detect explicit NIL, vs. implied NIL. IOW:
o:SomeOleCall( 1, , 3 )
o:SomeOleCall( 1, NIL, 3 )
We have no way to know if the 2nd argument was an explicit NIL, or an
omitted argument. Thus
Guys,
Please take the time to review and evaluate the new TBrowse, before
rushing to state your preference. I'd prefer we first have a LIST of:
1. Missing xHarbour features.
2. Incompatibles if any - compared to both existing xHarbour as well
as Clipper.
3. Pending issues with existing TBrows
Brian,
I completely trust what ever your decision will be.
Ron
On May 20, 2008, at 12:56 AM, bhays wrote:
> I know people hate it when I write long msgs, but this is very
> important so please everyone wade through it to find the pieces
> that apply to you. I can also use some guidance on hand
Maurilio
I agree with Eduardo
Atenciosamente
Luiz Rafael Culik Guimaraes
Suporte Xharbour
www.xharbour.com.br
Tue, 20 May 2008 03:41:13 -0700 (PDT), Eduardo Fernandes <[EMAIL PROTECTED]>
escreveu:
> Maurilio,
>
> I disagree. I have more than 50 small samples with bugs that has been fixed
Eduardo,
did you test your applets with harbour tbrowse?
Maurilio.
PS. I've also written code for our tbrowse and spent a lot of time trying to
make it better, anyway, I think we should simply take the best code and use it.
Eduardo Fernandes wrote:
> Maurilio,
>
> I disagree. I have more than
Maurilio,
I disagree. I have more than 50 small samples with bugs that has been fixed
along the last 4 years. Our tbrowse is very stable now and I think we need only
clean the code.
best regards,
Eduardo
- Mensagem original
> De: Maurilio Longo <[EMAIL PROTECTED]>
> Para: Eduardo Fern
-Messaggio Originale-
Da: "Ron Pinkas" <[EMAIL PROTECTED]>
A: "Enrico Maria Giordano" <[EMAIL PROTECTED]>
Cc: "xHarbour-Developers" ;
"Patrick Mast, xHarbour.com" <[EMAIL PROTECTED]>
Data invio: martedì 20 maggio 2008 1.23
Oggetto: Re: [xHarbour-developers] Time for a release?
> The co
-Messaggio Originale-
Da: "Ron Pinkas" <[EMAIL PROTECTED]>
A: "Enrico Maria Giordano" <[EMAIL PROTECTED]>
Cc: "Patrick Mast, xHarbour.com" <[EMAIL PROTECTED]>;
"xHarbour-Developers"
Data invio: martedì 20 maggio 2008 1.23
Oggetto: Re: [xHarbour-developers] Time for a release?
> The co
I know people hate it when I write long msgs, but this is very
important so please everyone wade through it to find the pieces
that apply to you. I can also use some guidance on handling
cvs and the changelog. When pulling whole files over, should
I attempt to gather the myriad changelogs from th
Eduardo,
I think we should borrow harbour tbrowse, which has been written from scratch
bt Przemyslaw and is a much more clean and thought-over code.
Best regards.
Eduardo Fernandes wrote:
>* source\rtl\tbrowse.prg
> ! fixed bug in a filtered table. Bug reported from comp.lang.xharbour
There is a issue with by-reference variables created inside .c code which are
not recognized as such when calling, for example, fread().
Best regards.
Patrick Mast, xHarbour.com wrote:
> Hello all,
>
> User feedback on bugs seems to be low at this point. Are we ready for
> a new release? Shall w
30 matches
Mail list logo
