date:20080702

[Harbour] Re: RC2 anything pending?

2008-07-02 Thread David Arturo Macias Corona


>Hi all,

>We're about to release RC2, is there anything pending?

>Also, may I ask everyone to try build under different
>platforms to see if there is still anything not building
>cleanly?

I tested current Harbour with OS/2 and result many messages/errors:

a) There are many lines like this ( at least 14 )
make[2]: *** No rule to make target `first'.  Stop.

Seem to be libraries/systems which does not apply to OS/2
Some catched are:
 gtwvg, hbole, hbw32, hbw32ddr, hbwhat32, hbziparch

In make_gnu.log appear like this:
--
[E:\harbourprerc2\harbour\contrib]make -C gtwvg first
make[2]: Entering directory `/harbourprerc2/harbour/contrib/gtwvg'
make[2]: Leaving directory `/harbourprerc2/harbour/contrib/gtwvg'
--

Can be replaced with behaviour for example like this ?:
--
[E:\harbourprerc2\harbour\doc]make -C en first
make[2]: Entering directory `/harbourprerc2/harbour/doc/en'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/harbourprerc2/harbour/doc/en'
--


b) A long list of warnings
Seem to be related to sqlite
Look below for "B portion" catched from screen

c) Error compiling tpos2.c
Look below for "C portion" catched from screen

d) libraries created:
gtcgi.a
gtos2.a
gtpca.a
gtstd.a
hbbmcdx.a
hbbtree.a
hbclipsm.a
hbcommon.a
hbcpage.a
hbcplr.a
hbct.a
hbdebug.a
hbgfos2.a
hbgt.a
hbhsx.a
hblang.a
hbmacro.a
hbmisc.a
hbmsql.a
hbmzip.a
hbnf.a
hbnulrdd.a
hbodbc.a
hbpcre.a
hbpp.a
hbrdd.a
hbrtl.a
hbsix.a
hbsqlit2.a
hbsqlit3.a
hbtip.a
hbusrrdd.a
hbvm.a
hbvpdf.a
hbzlib.a
rddado.a
rddcdx.a
rddfpt.a
rddntx.a
xhb.a


David Macias




"B portion" ===
../../vdbe.c:3124: warning: `pCrsr' might be used uninitialized in this 
function


../../vdbeaux.c: In function `sqliteVdbeList':
../../vdbeaux.c:556: warning: comparison between signed and unsigned
../../vdbeaux.c: In function `sqliteVdbeReset':
../../vdbeaux.c:838: warning: comparison between signed and unsigned
../../vdbeaux.c: In function `sqliteVdbeFinalize':
../../vdbeaux.c:924: warning: comparison between signed and unsigned
../../vdbeaux.c: In function `sqlite_bind':
../../vdbeaux.c:950: warning: comparison between signed and unsigned
../../where.c: In function `getMask':
../../where.c:97: warning: comparison between signed and unsigned
../../where.c: In function `sqliteWhereBegin':
../../where.c:482: warning: comparison between signed and unsigned
../../where.c:739: warning: comparison between signed and unsigned
../../where.c:867: warning: comparison between signed and unsigned
../../where.c:393: warning: `haveKey' might be used uninitialized in 
this functi

on
../../where.c:951: warning: `leFlag' might be used uninitialized in this 
functio

n
../../where.c:951: warning: `geFlag' might be used uninitialized in this 
functio

n

../../sqlite3/sqlite3.c: In function `sqlite3RunVacuum':
../../sqlite3/sqlite3.c:69145: warning: comparison between signed and 
unsigned

../../sqlite3/sqlite3.c: In function `sqlite3VtabUnlock':
../../sqlite3/sqlite3.c:69286: warning: comparison between signed and 
unsigned

../../sqlite3/sqlite3.c: In function `bestVirtualIndex':
../../sqlite3/sqlite3.c:71291: warning: empty body in an if-statement
../../sqlite3/sqlite3.c:71341: warning: empty body in an if-statement
../../sqlite3/sqlite3.c: In function `bestIndex':
../../sqlite3/sqlite3.c:71679: warning: comparison between signed and 
unsigned

../../sqlite3/sqlite3.c: In function `sqlite3WhereBegin':
../../sqlite3/sqlite3.c:72043: warning: comparison between signed and 
unsigned
../../sqlite3/sqlite3.c:72292: warning: comparison between signed and 
unsigned

../../sqlite3/sqlite3.c: In function `yyStackOverflow':
../../sqlite3/sqlite3.c:74484: warning: unused parameter `yypMinor'
../../sqlite3/sqlite3.c: In function `yy_syntax_error':
../../sqlite3/sqlite3.c:75943: warning: unused parameter `yymajor'
In file included from ../../hbsqlit3.c:45:
../../sqlite3/sqlite3.c: In function `nocaseCollatingFunc':
../../sqlite3/sqlite3.c:77161: warning: unused parameter `NotUsed'
../../hbsqlit3.c: At top level:
../../sqlite3/sqlite3.c:6753: warning: `sqlite3BtreeHoldsMutex' declared 
`static

' but never defined
../../sqlite3/sqlite3.c:6758: warning: `sqlite3BtreeHoldsAllMutexes' 
declared `s

tatic' but never defined


"C portion" ===

../../tpos2.c:164: error: `rxqueue' undeclared (first use in this function)
../../tpos2.c: In function `HB_FUN_P_ISDCD':
../../tpos2.c:175: error: `IOCTL_ASYNC' undeclared (first use in this 
function)
../../tpos2.c:175: error: `ASYNC_GETMODEMINPUT' undeclared (first use in 
this fu

nction)
../../tpos2.c:177: error: `DCD_ON' undeclared (first use in this function)
../../tpos2.c: In function `HB_FUN_P_ISRI':
../../tpos2.c:186: error: `IOCTL_ASYNC' undeclared (first use in this 
function)
../../tpos2.c:186: error: `ASYNC_GETMODEMINP

Re: [Harbour] Re: RC2 anything pending?

2008-07-02 Thread Szakáts Viktor


Hi David,


I tested current Harbour with OS/2 and result many messages/errors:

a) There are many lines like this ( at least 14 )
make[2]: *** No rule to make target `first'.  Stop.

Seem to be libraries/systems which does not apply to OS/2
Some catched are:
gtwvg, hbole, hbw32, hbw32ddr, hbwhat32, hbziparch

In make_gnu.log appear like this:
--
[E:\harbourprerc2\harbour\contrib]make -C gtwvg first
make[2]: Entering directory `/harbourprerc2/harbour/contrib/gtwvg'
make[2]: Leaving directory `/harbourprerc2/harbour/contrib/gtwvg'
--


This is normal.


Can be replaced with behaviour for example like this ?:
--
[E:\harbourprerc2\harbour\doc]make -C en first
make[2]: Entering directory `/harbourprerc2/harbour/doc/en'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/harbourprerc2/harbour/doc/en'
--


Maybe, but I won't start experimenting with it,
since it's far from critical (rather cosmetic),
and the solution isn't very obvious, plus I would
need to retest and refix all platforms. Maybe
after 1.0, if someone has enough drive and
GNU-make experience for it.


b) A long list of warnings
Seem to be related to sqlite
Look below for "B portion" catched from screen


Yes, unfortunately foreign code throws lots of
warnings.

You can try to suppress them with #pragma's
on your OS/2 C compiler. Look at the top of
contrib/hbsqlit3/hbsqlit3.c.


c) Error compiling tpos2.c
Look below for "C portion" catched from screen

"C portion" ===

../../tpos2.c:164: error: `rxqueue' undeclared (first use in this  
function)

../../tpos2.c: In function `HB_FUN_P_ISDCD':
../../tpos2.c:175: error: `IOCTL_ASYNC' undeclared (first use in  
this function)
../../tpos2.c:175: error: `ASYNC_GETMODEMINPUT' undeclared (first  
use in this fu

nction)
../../tpos2.c:177: error: `DCD_ON' undeclared (first use in this  
function)

../../tpos2.c: In function `HB_FUN_P_ISRI':
../../tpos2.c:186: error: `IOCTL_ASYNC' undeclared (first use in  
this function)
../../tpos2.c:186: error: `ASYNC_GETMODEMINPUT' undeclared (first  
use in this fu

nction)
../../tpos2.c:188: error: `RI_ON' undeclared (first use in this  
function)

../../tpos2.c: In function `HB_FUN_P_ISDSR':
../../tpos2.c:197: error: `IOCTL_ASYNC' undeclared (first use in  
this function)
../../tpos2.c:197: error: `ASYNC_GETMODEMINPUT' undeclared (first  
use in this fu

nction)
../../tpos2.c:199: error: `DSR_ON' undeclared (first use in this  
function)

../../tpos2.c: In function `HB_FUN_P_ISCTS':
../../tpos2.c:208: error: `IOCTL_ASYNC' undeclared (first use in  
this function)
../../tpos2.c:208: error: `ASYNC_GETMODEMINPUT' undeclared (first  
use in this fu

nction)
../../tpos2.c:210: error: `CTS_ON' undeclared (first use in this  
function)


Try to add '#define INCL_DOSDEVICES' to the top of the file
and see if it changes anything. If not, someone familiar with
OS/2 will have to fix it.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] BUG: HB_BUILD_DLL=yes and make_vc.bat fails (repost)

2008-07-02 Thread Marek Paliwoda

> Hi Marek and all,
> 
> See as subject. It fails on the .dll building stage
> (both MSVS2005 and 2008 in both cpp and non-cpp modes)

It does EXACTLY what YOU TOLD it to do. You've broken
MSVC builds and now you're saying : "it does not work !".

Sorry, it's up to you to fix it, since I find it quite 
hard to cooperate with you. That's why I decided to lower 
my engagement in Harbour. The fix is quite easy. You're 
absoluty capable to find it yourself. 

In case you're not too capable - here is a hint : 
-DWIN32 in makefile, or better fix hbdefs.h instead.



--
Pogoda na dzis.
Sprawdz >>> http://link.interia.pl/f1e42

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 10:52 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED]>

2008-07-02 Thread Miguel Angel Marchuet


2008-07-02 10:52 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED]>
   * contrib/hbziparch/hbziparc.c
 * corrected library name in comments.

Best regards,
Miguel Angel Marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-01 22:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-01 22:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * source/rtl/gtwvt/gtwvt.c
   * contrib/gtwvg/gtwvg.c
 ! Fixed MSVC warnings.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] BUG: HB_BUILD_DLL=yes and make_vc.bat fails (repost)

2008-07-02 Thread Szakáts Viktor


Hi Marek,

Yes, I know I do nothing else but breaking
things in Harbour, but nevertheless I'd
appreciate if you could help, just like I
used to do when I'm fixing loads of things
"broken" by other developers.

You bet that when I happen to break anything,
this is not my goal (neither is the goal of
anyone else doing mistakes), and it's definitely
not an attack against you, or your competence.

I've found 2008-05-27 04:15 where I've removed
WIN32, __WIN32__, __WINDOWS__ from *vc.mak files.

So, if you say we need WIN32 from this list,
I still wonder about the reason, could you tell
some words about it? Or how to fix this properly
in hbdefs.h?

BTW, I don't know what purpose does it serve
to insult me personally in your messages,
I don't think I've ever did that (rather the
contrary), in my messages towards you. [ If I
did, sorry, I certainly didn't mean it. ]

Nice to see you anyways, and we all miss your
contributions, I definitely do.

Brgds,
Viktor

On 2008.07.02., at 10:47, Marek Paliwoda wrote:


Hi Marek and all,

See as subject. It fails on the .dll building stage
(both MSVS2005 and 2008 in both cpp and non-cpp modes)


It does EXACTLY what YOU TOLD it to do. You've broken
MSVC builds and now you're saying : "it does not work !".

Sorry, it's up to you to fix it, since I find it quite
hard to cooperate with you. That's why I decided to lower
my engagement in Harbour. The fix is quite easy. You're
absoluty capable to find it yourself.

In case you're not too capable - here is a hint :
-DWIN32 in makefile, or better fix hbdefs.h instead.



--
Pogoda na dzis.
Sprawdz >>> http://link.interia.pl/f1e42



___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Miguel Angel Marchuet


Sorry Szakats, I see that you removed EXIT function.

HB_FUNC_EXIT( HBZIPCLEANUP )

this function is called at XHARBOUR on exit application

Are you saying that harbour don't executes HB_FUNC_EXIT functions never ?

or I don't understand anything ?

Best regards,
Miguel Angel marchuet

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor




Hi Miguel,


Sorry Szakats, I see that you removed EXIT function.

HB_FUNC_EXIT( HBZIPCLEANUP )

this function is called at XHARBOUR on exit application

Are you saying that harbour don't executes HB_FUNC_EXIT functions  
never ?


or I don't understand anything ?


HB_EXIT_FUNC() is indeed used by the compiler to mark
EXIT PROC/FUNCs as such, but it's part of a broader logic.
Used like this - by itself -, it never gets executed.

It was actually reported by all compilers as unused static
function, which it was.

[ I wouldn't be surprised if HB_EXIT_FUNC() wouldn't be called
in xhb either, but I didn't check. ]

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 11:21 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-02 11:21 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * include/hbdefs.h
 ! Fixed DLL creation for MSVC (and maybe compilers, too).
   Thanks to Marek Paliwoda for the hint.

   * contrib/hbtpathy/tpos2.c
 ! Blind attempt to fix OS/2 compile error.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Przemyslaw Czerpak

On Wed, 02 Jul 2008, Szakáts Viktor wrote:
> HB_EXIT_FUNC() is indeed used by the compiler to mark
> EXIT PROC/FUNCs as such, but it's part of a broader logic.
> Used like this - by itself -, it never gets executed.
> It was actually reported by all compilers as unused static
> function, which it was.
> [ I wouldn't be surprised if HB_EXIT_FUNC() wouldn't be called
> in xhb either, but I didn't check. ]

Yes. Neither Harbour not xHarbour execute HB_EXIT_FUNC() and/or
HB_INIT_FUNC() automatically. HB_EXIT_FUNC/HB_INIT_FUNC are only
macros to define special unique names for compiler but they not
cause that anything will be executed.

The HB_EXIT_FUNC removed from hbziparch library from the beginning
was dummy code never executed in both project.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] RC2 checklist

2008-07-02 Thread Szakáts Viktor


Pending, critical:

- Darwin Harbour compiler problem.

Pending, non-critical:

- OS/2 hbtpathy.lib fails. (long-time problem)
- 64bit C-mode startup not implemented in hbinit.h.

Postponed:

- FreeImage under Linux fails.

Cleared:

- .dll creation with all MSVC compilers. Thanks Marek!

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 11:57 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

2008-07-02 Thread Przemyslaw Czerpak

2008-07-02 11:57 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/xhb/Makefile
  * harbour/contrib/xhb/common.mak
  - harbour/contrib/xhb/hbchksum.c
* removed HB_CHECKSUM() code - it's not necessary

  * harbour/contrib/xhb/xhbfunc.c
+ redirected HB_CHECKSUM() to HB_ADLER32()

  * harbour/source/rtl/gtwvt/gtwvt.c
! fixed WINCE builds. It was only for MiGWCE which partially emulates
  GetSystemMenu() but probably other builds will report that this
  function is missing.
  If possible please test if current Harbour application can be
  executed in real WinCE environment.

  * harbour/make_deb.sh
* updated contrib library list

  * harbour/contrib/hbmysql/mysql.c
! fixed compilation for older MYSQL versions

  * harbour/contrib/gtwvg/gtwvg.c
  * harbour/contrib/gtwvg/wvgutils.c
! fixed UNICODE builds

  + harbour/config/none.cf
+ added dummy header file for GNU make to avoid errors on unsupported
  platforms

  * harbour/contrib/hbw32ddr/Makefile
  * harbour/contrib/hbmysql/Makefile
  * harbour/contrib/hbodbc/Makefile
  * harbour/contrib/hbwhat32/Makefile
  * harbour/contrib/hbtpathy/Makefile
  * harbour/contrib/hbw32/Makefile
  * harbour/contrib/hbole/Makefile
  * harbour/contrib/hbapollo/Makefile
  * harbour/contrib/hbfbird/Makefile
  * harbour/contrib/hbziparch/Makefile
  * harbour/contrib/hbcurl/Makefile
  * harbour/contrib/hbhpdf/Makefile
  * harbour/contrib/rddado/Makefile
  * harbour/contrib/gtwvg/Makefile
  * harbour/contrib/hbpgsql/Makefile
  * harbour/contrib/rddads/Makefile
  * harbour/contrib/hbfimage/Makefile
  * harbour/contrib/hbgd/Makefile
  * harbour/contrib/hbgf/hbgfw32/Makefile
  * harbour/contrib/hbgf/hbgfos2/Makefile
  * harbour/contrib/hbgf/hbgfgtk/Makefile
  * harbour/contrib/hbtip/Makefile
  * harbour/contrib/hbbmcdx/Makefile
* updated to not generate errors for unsupported builds

best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Miguel Angel Marchuet


Przemyslaw Czerpak escribió:

On Wed, 02 Jul 2008, Szakáts Viktor wrote:

HB_EXIT_FUNC() is indeed used by the compiler to mark
EXIT PROC/FUNCs as such, but it's part of a broader logic.
Used like this - by itself -, it never gets executed.
It was actually reported by all compilers as unused static
function, which it was.
[ I wouldn't be surprised if HB_EXIT_FUNC() wouldn't be called
in xhb either, but I didn't check. ]


Yes. Neither Harbour not xHarbour execute HB_EXIT_FUNC() and/or
HB_INIT_FUNC() automatically. HB_EXIT_FUNC/HB_INIT_FUNC are only
macros to define special unique names for compiler but they not
cause that anything will be executed.

The HB_EXIT_FUNC removed from hbziparch library from the beginning
was dummy code never executed in both project.




False i test it at xharbour with OutputDebugString and is executed at end of 
application

I this is because has the next lines:

#define __PRG_SOURCE__ (char*) "zip.c"
#ifdef HB_PCODE_VER
#  undef HB_PRG_PCODE_VER
#  define HB_PRG_PCODE_VER HB_PCODE_VER
#endif

HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
{ (char*) "HBZIPCLEANUP$", {HB_FS_EXIT | HB_FS_LOCAL}, {HB_EXIT_FUNCNAME( 
HBZIPCLEANUP )}, &ModuleFakeDyn }
HB_INIT_SYMBOLS_END( hbzip_CLEANUP )

#if defined(HB_PRAGMA_STARTUP)
   #pragma startup hbzip_CLEANUP
#elif defined(HB_MSC_STARTUP)
   #if _MSC_VER >= 1010
  #pragma data_seg( ".CRT$XIY" )
  #pragma comment( linker, "/Merge:.CRT=.data" )
   #else
  #pragma data_seg( "XIY" )
   #endif
   static HB_$INITSYM hb_vm_auto_SymbolInit_INIT = hbzip_CLEANUP;
   #pragma data_seg()
#endif

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor


Hi Miguel,

Yes, with the extra lines, the logic is complete,
and it should work.

The problem is that these lines were not added
to Harbour.

Brgds,
Viktor

On 2008.07.02., at 12:08, Miguel Angel Marchuet wrote:


Przemyslaw Czerpak escribió:

On Wed, 02 Jul 2008, Szakáts Viktor wrote:

HB_EXIT_FUNC() is indeed used by the compiler to mark
EXIT PROC/FUNCs as such, but it's part of a broader logic.
Used like this - by itself -, it never gets executed.
It was actually reported by all compilers as unused static
function, which it was.
[ I wouldn't be surprised if HB_EXIT_FUNC() wouldn't be called
in xhb either, but I didn't check. ]

Yes. Neither Harbour not xHarbour execute HB_EXIT_FUNC() and/or
HB_INIT_FUNC() automatically. HB_EXIT_FUNC/HB_INIT_FUNC are only
macros to define special unique names for compiler but they not
cause that anything will be executed.
The HB_EXIT_FUNC removed from hbziparch library from the beginning
was dummy code never executed in both project.



False i test it at xharbour with OutputDebugString and is executed  
at end of application


I this is because has the next lines:

#define __PRG_SOURCE__ (char*) "zip.c"
#ifdef HB_PCODE_VER
#  undef HB_PRG_PCODE_VER
#  define HB_PRG_PCODE_VER HB_PCODE_VER
#endif

HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
{ (char*) "HBZIPCLEANUP$", {HB_FS_EXIT | HB_FS_LOCAL},  
{HB_EXIT_FUNCNAME( HBZIPCLEANUP )}, &ModuleFakeDyn }

HB_INIT_SYMBOLS_END( hbzip_CLEANUP )

#if defined(HB_PRAGMA_STARTUP)
  #pragma startup hbzip_CLEANUP
#elif defined(HB_MSC_STARTUP)
  #if _MSC_VER >= 1010
 #pragma data_seg( ".CRT$XIY" )
 #pragma comment( linker, "/Merge:.CRT=.data" )
  #else
 #pragma data_seg( "XIY" )
  #endif
  static HB_$INITSYM hb_vm_auto_SymbolInit_INIT = hbzip_CLEANUP;
  #pragma data_seg()
#endif

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Miguel Angel Marchuet


I prefer to add it and forgot to call manually to this function.


Can I add it ?



#define __PRG_SOURCE__ (char*) "zip.c"
#ifdef HB_PCODE_VER
#  undef HB_PRG_PCODE_VER
#  define HB_PRG_PCODE_VER HB_PCODE_VER
#endif

HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
{ (char*) "HBZIPCLEANUP$", {HB_FS_EXIT | HB_FS_LOCAL}, 
{HB_EXIT_FUNCNAME( HBZIPCLEANUP )}, &ModuleFakeDyn }

HB_INIT_SYMBOLS_END( hbzip_CLEANUP )

#if defined(HB_PRAGMA_STARTUP)
  #pragma startup hbzip_CLEANUP
#elif defined(HB_MSC_STARTUP)
  #if _MSC_VER >= 1010
 #pragma data_seg( ".CRT$XIY" )
 #pragma comment( linker, "/Merge:.CRT=.data" )
  #else
 #pragma data_seg( "XIY" )
  #endif
  static HB_$INITSYM hb_vm_auto_SymbolInit_INIT = hbzip_CLEANUP;
  #pragma data_seg()
#endif




Best regards,
Miguel Angel Marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor


It looks a bit hackish, but if there is no other way to
solve this, I think you should commit it.

Brgds,
Viktor

On 2008.07.02., at 12:21, Miguel Angel Marchuet wrote:


I prefer to add it and forgot to call manually to this function.


Can I add it ?



#define __PRG_SOURCE__ (char*) "zip.c"
#ifdef HB_PCODE_VER
#  undef HB_PRG_PCODE_VER
#  define HB_PRG_PCODE_VER HB_PCODE_VER
#endif

HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
{ (char*) "HBZIPCLEANUP$", {HB_FS_EXIT | HB_FS_LOCAL},  
{HB_EXIT_FUNCNAME( HBZIPCLEANUP )}, &ModuleFakeDyn }

HB_INIT_SYMBOLS_END( hbzip_CLEANUP )

#if defined(HB_PRAGMA_STARTUP)
 #pragma startup hbzip_CLEANUP
#elif defined(HB_MSC_STARTUP)
 #if _MSC_VER >= 1010
#pragma data_seg( ".CRT$XIY" )
#pragma comment( linker, "/Merge:.CRT=.data" )
 #else
#pragma data_seg( "XIY" )
 #endif
 static HB_$INITSYM hb_vm_auto_SymbolInit_INIT = hbzip_CLEANUP;
 #pragma data_seg()
#endif




Best regards,
Miguel Angel Marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: BUG: HB_BUILD_DLL=yes and make_vc.bat fails (repost)

2008-07-02 Thread Marek Paliwoda


Viktor,

[Quotes reordered]

> BTW, I don't know what purpose does it serve
> to insult me personally in your messages,
> I don't think I've ever did that (rather the
> contrary), in my messages towards you. [ If I
> did, sorry, I certainly didn't mean it. ]

You are absolutly right. My post was a kind of
a personal attack and it was meant to be so :).
And after posting it I feel a lot better ;-).

To clarify things to all others - I *very much*
(and when I say "very much" I really mean "*very
much*") appreciate your contributions. In fact
whithout you - Harbour would be dead long ago.

But there are areas where I do not agree with
your solutions at all. And in those areas you
force your solutions without listening to any
(even resonable) arguments. That's why I find
it hard to contribute something usefull to
Harbour at a moment (besides others, much more
important, private healthy problems, which are
still valid unfortunately).


Yes, I know I do nothing else but breaking
things in Harbour, but nevertheless I'd
appreciate if you could help, just like I
used to do when I'm fixing loads of things
"broken" by other developers.


See above.


You bet that when I happen to break anything,
this is not my goal (neither is the goal of
anyone else doing mistakes), and it's definitely
not an attack against you, or your competence.


I never had a feeling you want to impair my
competence. I rather had a feeling you want
to have a final word. That's a difference :).


I've found 2008-05-27 04:15 where I've removed
WIN32, __WIN32__, __WINDOWS__ from *vc.mak files.

So, if you say we need WIN32 from this list,
I still wonder about the reason, could you tell
some words about it? Or how to fix this properly
in hbdefs.h?


"hbdefs.h" has the following :

#if defined( __EXPORT__ )
   #if defined( __RSXNT__ )
  /* RSXNT does not support any type of export keyword.
 Exported (i.e., public) names can be obtained via
 the emxexp utility and the output can be used for
 input to a module definition file. See emxdev.doc
 in the RSXNT doc/ directory for more information. */
  #define HB_EXPORT

   #elif defined( __GNUC__ ) && defined( HB_OS_WIN_32 )
  #define HB_EXPORT __attribute__ (( dllexport ))

   #elif defined( __GNUC__ ) && defined( HB_OS_LINUX )
  #define HB_EXPORT __attribute__ ((visibility ("default")))

   #elif defined( __BORLANDC__ )
  #define HB_EXPORT __declspec( dllexport )

   #elif defined( __WATCOMC__ )
  #define HB_EXPORT __declspec( dllexport )

   #elif defined( ASANLM ) || defined( ASANT )
  #define HB_EXPORT

   #elif defined( WIN32 )
  #define HB_EXPORT _declspec( dllexport )

   #else
  #define HB_EXPORT

   #endif
#else
   #define HB_EXPORT
#endif


As you can see MSVC is not explicitly listed in the above.
Instead it relies on #elif defined( WIN32 ) path.

AFAIK In MSVC WIN32 is not required to be always defined.
Only _WIN32 is guaraneed to be always defined (I may be
wrong here). Either way it is better to explicitly define
HB_EXPORT for MSVC in the above also.

--

Marek

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 12:29 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-02 12:29 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * contrib/hbapollo/make_b32.bat
   * contrib/hbapollo/make_vc.bat
   * contrib/hbcurl/make_b32.bat
   * contrib/hbcurl/make_vc.bat
   * contrib/hbfbird/make_b32.bat
   * contrib/hbfbird/make_vc.bat
   * contrib/hbfimage/make_b32.bat
   * contrib/hbfimage/make_vc.bat
   * contrib/hbgd/make_b32.bat
   * contrib/hbgd/make_vc.bat
   * contrib/hbhpdf/make_b32.bat
   * contrib/hbhpdf/make_vc.bat
   * contrib/hbmysql/make_b32.bat
   * contrib/hbmysql/make_vc.bat
   * contrib/hbpgsql/make_b32.bat
   * contrib/hbpgsql/make_vc.bat
   * contrib/rddads/make_b32.bat
   * contrib/rddads/make_vc.bat
 ! Fixed previous modification. More to come.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Miguel Angel Marchuet


MORE OR LESS rdd uses the same system to add INIT functions

HB_INIT_SYMBOLS_BEGIN( dbfcdx1__InitSymbols )
{ "DBFCDX",  {HB_FS_PUBLIC|HB_FS_LOCAL}, {HB_FUNCNAME( DBFCDX )}, 
NULL },
{ "DBFCDX_GETFUNCTABLE", {HB_FS_PUBLIC|HB_FS_LOCAL}, {HB_FUNCNAME( 
DBFCDX_GETFUNCTABLE )}, NULL }
HB_INIT_SYMBOLS_END( dbfcdx1__InitSymbols )

HB_CALL_ON_STARTUP_BEGIN( _hb_dbfcdx_rdd_init_ )
   hb_vmAtInit( hb_dbfcdxRddInit, NULL );
HB_CALL_ON_STARTUP_END( _hb_dbfcdx_rdd_init_ )

#if defined(HB_PRAGMA_STARTUP)
#  pragma startup dbfcdx1__InitSymbols
#  pragma startup _hb_dbfcdx_rdd_init_
#elif defined(HB_MSC_STARTUP)
#  if _MSC_VER >= 1010
# pragma data_seg( ".CRT$XIY" )
# pragma comment( linker, "/Merge:.CRT=.data" )
#  else
# pragma data_seg( "XIY" )
#  endif
   static HB_$INITSYM hb_vm_auto_dbfcdx1__InitSymbols = dbfcdx1__InitSymbols;
   static HB_$INITSYM hb_vm_auto_dbfcdx_rdd_init = _hb_dbfcdx_rdd_init_;
#  pragma data_seg()
#endif

Best regards,
Miguel Angel Marchuet


Szakáts Viktor escribió:

It looks a bit hackish, but if there is no other way to
solve this, I think you should commit it.

Brgds,
Viktor

On 2008.07.02., at 12:21, Miguel Angel Marchuet wrote:


I prefer to add it and forgot to call manually to this function.


Can I add it ?



#define __PRG_SOURCE__ (char*) "zip.c"
#ifdef HB_PCODE_VER
#  undef HB_PRG_PCODE_VER
#  define HB_PRG_PCODE_VER HB_PCODE_VER
#endif

HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
{ (char*) "HBZIPCLEANUP$", {HB_FS_EXIT | HB_FS_LOCAL}, 
{HB_EXIT_FUNCNAME( HBZIPCLEANUP )}, &ModuleFakeDyn }

HB_INIT_SYMBOLS_END( hbzip_CLEANUP )

#if defined(HB_PRAGMA_STARTUP)
 #pragma startup hbzip_CLEANUP
#elif defined(HB_MSC_STARTUP)
 #if _MSC_VER >= 1010
#pragma data_seg( ".CRT$XIY" )
#pragma comment( linker, "/Merge:.CRT=.data" )
 #else
#pragma data_seg( "XIY" )
 #endif
 static HB_$INITSYM hb_vm_auto_SymbolInit_INIT = hbzip_CLEANUP;
 #pragma data_seg()
#endif




Best regards,
Miguel Angel Marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour



___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor


Okay, this way it's perfect, because the PCODE version hack is missing.

Brgds,
Viktor

On 2008.07.02., at 12:40, Miguel Angel Marchuet wrote:


MORE OR LESS rdd uses the same system to add INIT functions

HB_INIT_SYMBOLS_BEGIN( dbfcdx1__InitSymbols )
{ "DBFCDX",  {HB_FS_PUBLIC|HB_FS_LOCAL},  
{HB_FUNCNAME( DBFCDX )}, NULL },
{ "DBFCDX_GETFUNCTABLE", {HB_FS_PUBLIC|HB_FS_LOCAL},  
{HB_FUNCNAME( DBFCDX_GETFUNCTABLE )}, NULL }

HB_INIT_SYMBOLS_END( dbfcdx1__InitSymbols )

HB_CALL_ON_STARTUP_BEGIN( _hb_dbfcdx_rdd_init_ )
  hb_vmAtInit( hb_dbfcdxRddInit, NULL );
HB_CALL_ON_STARTUP_END( _hb_dbfcdx_rdd_init_ )

#if defined(HB_PRAGMA_STARTUP)
#  pragma startup dbfcdx1__InitSymbols
#  pragma startup _hb_dbfcdx_rdd_init_
#elif defined(HB_MSC_STARTUP)
#  if _MSC_VER >= 1010
# pragma data_seg( ".CRT$XIY" )
# pragma comment( linker, "/Merge:.CRT=.data" )
#  else
# pragma data_seg( "XIY" )
#  endif
  static HB_$INITSYM hb_vm_auto_dbfcdx1__InitSymbols =  
dbfcdx1__InitSymbols;
  static HB_$INITSYM hb_vm_auto_dbfcdx_rdd_init =  
_hb_dbfcdx_rdd_init_;

#  pragma data_seg()
#endif

Best regards,
Miguel Angel Marchuet


Szakáts Viktor escribió:

It looks a bit hackish, but if there is no other way to
solve this, I think you should commit it.
Brgds,
Viktor
On 2008.07.02., at 12:21, Miguel Angel Marchuet wrote:

I prefer to add it and forgot to call manually to this function.


Can I add it ?



#define __PRG_SOURCE__ (char*) "zip.c"
#ifdef HB_PCODE_VER
#  undef HB_PRG_PCODE_VER
#  define HB_PRG_PCODE_VER HB_PCODE_VER
#endif

HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
{ (char*) "HBZIPCLEANUP$", {HB_FS_EXIT | HB_FS_LOCAL},  
{HB_EXIT_FUNCNAME( HBZIPCLEANUP )}, &ModuleFakeDyn }

HB_INIT_SYMBOLS_END( hbzip_CLEANUP )

#if defined(HB_PRAGMA_STARTUP)
#pragma startup hbzip_CLEANUP
#elif defined(HB_MSC_STARTUP)
#if _MSC_VER >= 1010
   #pragma data_seg( ".CRT$XIY" )
   #pragma comment( linker, "/Merge:.CRT=.data" )
#else
   #pragma data_seg( "XIY" )
#endif
static HB_$INITSYM hb_vm_auto_SymbolInit_INIT = hbzip_CLEANUP;
#pragma data_seg()
#endif




Best regards,
Miguel Angel Marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 12:43 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-02 12:43 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * contrib/hbapollo/make_b32.bat
   * contrib/hbapollo/make_vc.bat
   * contrib/hbcurl/make_b32.bat
   * contrib/hbcurl/make_vc.bat
   * contrib/hbfbird/make_b32.bat
   * contrib/hbfbird/make_vc.bat
   * contrib/hbfimage/make_b32.bat
   * contrib/hbfimage/make_vc.bat
   * contrib/hbgd/make_b32.bat
   * contrib/hbgd/make_vc.bat
   * contrib/hbhpdf/make_b32.bat
   * contrib/hbhpdf/make_vc.bat
   * contrib/hbmysql/make_b32.bat
   * contrib/hbmysql/make_vc.bat
   * contrib/hbpgsql/make_b32.bat
   * contrib/hbpgsql/make_vc.bat
   * contrib/rddads/make_b32.bat
   * contrib/rddads/make_vc.bat
 + Added possibility to use HB_INC_* envvars to 
   specify the header directories for external 
   packages. This way _all_ Harbour make systems 
   now able to use the same common logic to specify 
   external header dirs. (For GNU-make you can even 
   use a dir list).
   If HB_INC_* is used with the non-GNU make system, 
   the .dll to .lib generation _won't_ happen, which 
   is desirable for binary builds for distribution.
   HB_DIR_* envvars continue to work, in this case 
   .libs are copied/generated from the external .dlls, 
   and this is useful who build their Harbour from 
   source.
   For official Harbour binary distributions HB_INC_* 
   must be used.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 13:06 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED]>

2008-07-02 Thread Miguel Angel Marchuet


2008-07-02 13:06 UTC+0100 Miguel Angel Marchuet <[EMAIL PROTECTED]>
   * contrib/hbziparch/hbziparc.c
 + Added HBZIPCLEANUP() as EXIT function to clean. It will be called
   automatically at end application.

Best regards,
Miguel Angel marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: BUG: HB_BUILD_DLL=yes and make_vc.bat fails (repost)

2008-07-02 Thread Szakáts Viktor


Hi Marek,


You are absolutly right. My post was a kind of
a personal attack and it was meant to be so :).
And after posting it I feel a lot better ;-).


:) Okay, maybe I'm taking your comments too personal.
I surely don't think it makes you feel better, I just
wonder about the reasons behind, but maybe my threshold
is put to low in this regard.


To clarify things to all others - I *very much*
(and when I say "very much" I really mean "*very
much*") appreciate your contributions. In fact
whithout you - Harbour would be dead long ago.


Thanks.


But there are areas where I do not agree with
your solutions at all. And in those areas you
force your solutions without listening to any
(even resonable) arguments. That's why I find
it hard to contribute something usefull to
Harbour at a moment (besides others, much more
important, private healthy problems, which are
still valid unfortunately).


I wish you the best to recover from your health
problems, that's with no question more important
than anything else, especially any geeking around,
even if it's Harbour related. I hope you'll be in
perfect health ASAP.

..as for technical stuff, I know you had a big concern
regarding .dll -> .lib generation. I fully agree it
is a problem when doing binary builds for distribution,
so I hopefully fixed this with the last two commits.
Your comment are welcome.

The other issue I remember is merging libs. We can
get back to it after 1.0, or maybe even after MT
implementation, if there is enough interest. I'd
be definitely happier with less .libs to list in
my make files.

Was there anything else? :/


You bet that when I happen to break anything,
this is not my goal (neither is the goal of
anyone else doing mistakes), and it's definitely
not an attack against you, or your competence.


I never had a feeling you want to impair my
competence. I rather had a feeling you want
to have a final word. That's a difference :).


Well, I think you're right. I'm far from perfect,
that goes without a question. I'll try to check
myself a bit more.


  #elif defined( WIN32 )

 #define HB_EXPORT _declspec( dllexport )


Yes, I've found the same, based on your hint. The problem
was that WIN32 was used a sort of hidden communication
between the make files and this specific part of
Harbour internals. Since we have a sure way to detect
Win32 inside the core, I've used HB_OS_WIN_32 here,
it should be a safe default if any compiler specific
exceptions were checked before.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Przemyslaw Czerpak

On Wed, 02 Jul 2008, Miguel Angel Marchuet wrote:
> >Yes. Neither Harbour not xHarbour execute HB_EXIT_FUNC() and/or
> >HB_INIT_FUNC() automatically. HB_EXIT_FUNC/HB_INIT_FUNC are only
> >macros to define special unique names for compiler but they not
> >cause that anything will be executed.
> >The HB_EXIT_FUNC removed from hbziparch library from the beginning
> >was dummy code never executed in both project.
> False i test it at xharbour with OutputDebugString and is executed at end 
> of application

Miguel you used to check only part of problem and then create
very wide conclusions.
You are wrong. HB_EXIT_FUNC/HB_INIT_FUNC macros _does_not_ cause
any function execution and never did.

> I this is because has the next lines:
> #define __PRG_SOURCE__ (char*) "zip.c"
> #ifdef HB_PCODE_VER
> #  undef HB_PRG_PCODE_VER
> #  define HB_PRG_PCODE_VER HB_PCODE_VER
> #endif
> HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
> { (char*) "HBZIPCLEANUP$", {HB_FS_EXIT | HB_FS_LOCAL}, {HB_EXIT_FUNCNAME( 
> HBZIPCLEANUP )}, &ModuleFakeDyn }
> HB_INIT_SYMBOLS_END( hbzip_CLEANUP )
> 
> #if defined(HB_PRAGMA_STARTUP)
>#pragma startup hbzip_CLEANUP
> #elif defined(HB_MSC_STARTUP)
>#if _MSC_VER >= 1010
>   #pragma data_seg( ".CRT$XIY" )
>   #pragma comment( linker, "/Merge:.CRT=.data" )
>#else
>   #pragma data_seg( "XIY" )
>#endif
>static HB_$INITSYM hb_vm_auto_SymbolInit_INIT = hbzip_CLEANUP;
>#pragma data_seg()
> #endif

This code causes that function HB_EXIT_FUNCNAME( HBZIPCLEANUP )
will be executed by HVM because it registers new symbol table
in HVM internal structure. But it's done by this additional code
not the HB_EXIT_FUNC() macro. You can change the function name
to any other one, f.e.:

   void my_func( void ) { doSomeThing(); }
   HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
  { "$", {HB_FS_EXIT | HB_FS_LOCAL}, { doSomeThing }, &ModuleFakeDyn }
   HB_INIT_SYMBOLS_END( hbzip_CLEANUP )
   [...] // pragmas

and it will be executed too. HB_INIT_FUNC/HB_EXIT_FUNC macros are used
_ONLY_ for giving unique function name for .prg INIT/EXIT procedures
which will not cause conflict with other function/procedure names used
in the same module.
So far ZIPARCH cleanup function was dummy function from the beginning in
both projects because this additional code was missing.

Anyhow with additional code it will work but it's not efficient method for
C code. HB_INIT_SYMBOLS_BEGIN/HB_INIT_SYMBOLS_END should be used only for
.prg code or if you want to register some public symbols inside HVM.
It also has bad side effect because we are not able to control the order
of execution INIT/EXIT procedures so it can be executed before some other
.prg EXIT procedure which will try to access some ZIPARCH functions.
If you want to make it well and execute C function at HVM startup/cleanup
phase then use:
   void hb_vmAtInit( HB_INIT_FUNC pFunc, void * cargo );
   void hb_vmAtExit( HB_INIT_FUNC pFunc, void * cargo );
See in harbour/source/rtl/inkey.c how C exit function can
be registered and executed. If you need automatic registration of
init/exit functions at application startup then see end of file
harbour/source/rtl/gtwvt/gtwvt.c:
   HB_CALL_ON_STARTUP_BEGIN( file_unique_name )
  [...code_using hb_vmAtInit/hb_vmAtExit...]
   HB_CALL_ON_STARTUP_END( file_unique_name )
   [...pragmas...]

Functions registered in such way does not allocate unnecessary symbol
table in HVM and it's guarantied that INIT functions will be executed
just before .prg INIT procedures and exit functions just after all .prg
EXIT procedures.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: RC2 anything pending?

2008-07-02 Thread David Arturo Macias Corona


With current code:

>>a) There are many lines like this ( at least 14 )
>>make[2]: *** No rule to make target `first'.  Stop.

Fixed with changes made by Przemek, thanks

>>b) A long list of warnings
>>Seem to be related to sqlite

>Yes, unfortunately foreign code throws lots of
>warnings.

OK
As I see it was not compiled under Harbour rc1, and now appear in rc2

These warnings appear in your tests too (Win, Linux, ...) ?

>>c) Error compiling tpos2.c
>>Look below for "C portion" catched from screen

>#ifdef HB_OS_OS2

>#define INCL_BASE
>#define INCL_DOS
>#define INCL_DOSERROR
>#define INCL_DOSDEVICES

Same errors

David Macias


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: RC2 anything pending?

2008-07-02 Thread Szakáts Viktor


Hi David,


>Yes, unfortunately foreign code throws lots of
>warnings.

OK
As I see it was not compiled under Harbour rc1, and now appear in rc2

These warnings appear in your tests too (Win, Linux, ...) ?


Yes. Most foreign code we have in the contrib will
generate all sorts of warnings in different compilers/platforms.

sqlite2, sqlite3, ZipArchive and some foreign headers. For
ZipArchive I've reported some of them to the author already.

We'll need to develop some #pragma ways to suppress these.

Harbour's standard warning level is seemingly much higher
than of other projects.


>#define INCL_BASE
>#define INCL_DOS
>#define INCL_DOSERROR
>#define INCL_DOSDEVICES

Same errors


I have no idea then. This seems to be a long time problem
with this code, and the only reason it didn't come up earlier
is that it was also never included in OS/2 builds.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-01 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Miguel Angel Marchuet


Please can you do it necessary changes to ziparch

Best regards,
Miguel Angel Marchuet

Przemyslaw Czerpak escribió:

On Wed, 02 Jul 2008, Miguel Angel Marchuet wrote:

Yes. Neither Harbour not xHarbour execute HB_EXIT_FUNC() and/or
HB_INIT_FUNC() automatically. HB_EXIT_FUNC/HB_INIT_FUNC are only
macros to define special unique names for compiler but they not
cause that anything will be executed.
The HB_EXIT_FUNC removed from hbziparch library from the beginning
was dummy code never executed in both project.
False i test it at xharbour with OutputDebugString and is executed at end 
of application


Miguel you used to check only part of problem and then create
very wide conclusions.
You are wrong. HB_EXIT_FUNC/HB_INIT_FUNC macros _does_not_ cause
any function execution and never did.


I this is because has the next lines:
#define __PRG_SOURCE__ (char*) "zip.c"
#ifdef HB_PCODE_VER
#  undef HB_PRG_PCODE_VER
#  define HB_PRG_PCODE_VER HB_PCODE_VER
#endif
HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
{ (char*) "HBZIPCLEANUP$", {HB_FS_EXIT | HB_FS_LOCAL}, {HB_EXIT_FUNCNAME( 
HBZIPCLEANUP )}, &ModuleFakeDyn }

HB_INIT_SYMBOLS_END( hbzip_CLEANUP )

#if defined(HB_PRAGMA_STARTUP)
   #pragma startup hbzip_CLEANUP
#elif defined(HB_MSC_STARTUP)
   #if _MSC_VER >= 1010
  #pragma data_seg( ".CRT$XIY" )
  #pragma comment( linker, "/Merge:.CRT=.data" )
   #else
  #pragma data_seg( "XIY" )
   #endif
   static HB_$INITSYM hb_vm_auto_SymbolInit_INIT = hbzip_CLEANUP;
   #pragma data_seg()
#endif


This code causes that function HB_EXIT_FUNCNAME( HBZIPCLEANUP )
will be executed by HVM because it registers new symbol table
in HVM internal structure. But it's done by this additional code
not the HB_EXIT_FUNC() macro. You can change the function name
to any other one, f.e.:

   void my_func( void ) { doSomeThing(); }
   HB_INIT_SYMBOLS_BEGIN( hbzip_CLEANUP )
  { "$", {HB_FS_EXIT | HB_FS_LOCAL}, { doSomeThing }, &ModuleFakeDyn }
   HB_INIT_SYMBOLS_END( hbzip_CLEANUP )
   [...] // pragmas

and it will be executed too. HB_INIT_FUNC/HB_EXIT_FUNC macros are used
_ONLY_ for giving unique function name for .prg INIT/EXIT procedures
which will not cause conflict with other function/procedure names used
in the same module.
So far ZIPARCH cleanup function was dummy function from the beginning in
both projects because this additional code was missing.

Anyhow with additional code it will work but it's not efficient method for
C code. HB_INIT_SYMBOLS_BEGIN/HB_INIT_SYMBOLS_END should be used only for
.prg code or if you want to register some public symbols inside HVM.
It also has bad side effect because we are not able to control the order
of execution INIT/EXIT procedures so it can be executed before some other
.prg EXIT procedure which will try to access some ZIPARCH functions.
If you want to make it well and execute C function at HVM startup/cleanup
phase then use:
   void hb_vmAtInit( HB_INIT_FUNC pFunc, void * cargo );
   void hb_vmAtExit( HB_INIT_FUNC pFunc, void * cargo );
See in harbour/source/rtl/inkey.c how C exit function can
be registered and executed. If you need automatic registration of
init/exit functions at application startup then see end of file
harbour/source/rtl/gtwvt/gtwvt.c:
   HB_CALL_ON_STARTUP_BEGIN( file_unique_name )
  [...code_using hb_vmAtInit/hb_vmAtExit...]
   HB_CALL_ON_STARTUP_END( file_unique_name )
   [...pragmas...]

Functions registered in such way does not allocate unnecessary symbol
table in HVM and it's guarantied that INIT functions will be executed
just before .prg INIT procedures and exit functions just after all .prg
EXIT procedures.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour



___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: BUG: HB_BUILD_DLL=yes and make_vc.bat fails (repost)

2008-07-02 Thread Fritz Eichelhardt

Marek:
> > And after posting it I feel a lot better ;-).

fine



Viktor:
> I'll try to check 
> myself a bit more.

fine



puuuh, all problems solved!!

perfect precondition to continue this marvellous project.

-- 
Mit freundlichen Grüßen

Fritz Eichelhardt
Brückenstr. 1
53545 Linz
Tel.: 02644 - 3784
Fax/UMS: 01212 - 517045068
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 14:09 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

2008-07-02 Thread Przemyslaw Czerpak

2008-07-02 14:09 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/hbtpathy/tpos2.c
* moved INCL_* definitions before harbour header files

best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 15:34 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

2008-07-02 Thread Przemyslaw Czerpak

2008-07-02 15:34 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/hbziparch/hbziparc.c
- removed HB_FUNC_EXIT( HBZIPCLEANUP )
  * harbour/contrib/hbziparch/hbzipnew.cpp
+ added automatic callback destructor registered by hb_vmAtExit()
  at 1-st callback set

best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] RC2 checklist update #2

2008-07-02 Thread Szakáts Viktor


Pending, critical:
- Darwin Harbour compiler problem.
  Lorenzo, any feedback from you as a Darwin user?

Pending, non-critical:
- 64bit C-mode startup not implemented in hbinit.h.
- WinCE compatible screen selection code in gtwvt.c.

Postponed:
- FreeImage under Linux fails.

Cleared:
- OS/2 hbtpathy.lib fails. Thanks Przemek!
- .dll creation with all MSVC compilers. Thanks Marek!
- HB_ZIPARCHCLEAN() issue. Thanks Przemek and Miguel.
- To not build .dll .libs for binary distros.

Cleared platforms:
- Win32
- OS/2

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] BUG: HB_BUILD_DLL=yes and make_vc.bat fails (repost)

2008-07-02 Thread Pritpal Bedi


Marek

<<<
That's why I find
it hard to contribute something usefull to
Harbour at a moment (besides others, much more
important, private healthy problems, which are
still valid unfortunately).
>>>

May LORD bless you with robust health, we pray.
Certainly Harbour MISSES you a lot.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/BUG%3A-HB_BUILD_DLL%3Dyes-and-make_vc.bat-fails-%28repost%29-tp18226979p18238460.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] RC2 checklist update #2

2008-07-02 Thread Przemyslaw Czerpak

On Wed, 02 Jul 2008, Szakáts Viktor wrote:
> - Darwin Harbour compiler problem.
>   Lorenzo, any feedback from you as a Darwin user?

This looks really critical and for sure the problem has to be
located and fixed. Unfortunately I do not have MacOSX to make
test myself.

> Pending, non-critical:
> - 64bit C-mode startup not implemented in hbinit.h.
Only for MSVC. I do not know if it supports startup
code for C mode at all. GCC uses constructor attribute
and it works well. See in MSVC64 documentation if it's
possible to mark function as executed at startup.

> - WinCE compatible screen selection code in gtwvt.c.
> Postponed:
> - FreeImage under Linux fails.

- The hbsqlit2 and hbsqlit3 produce a lot of warnings and cannot
  be compiled in C++ mode so they will not work for any compilers
  we are using in C++ mode (f.e. OpenWatcom, G++). They need serious
  cleanup for C++ which probably can be joined with warning cleanup.

- HBZipArch still produce a lot of warnings and it cannot be compiled
  in pure C mode. It's mostly C++ code which needs C++ compiler.
  If core harbour code was compiled in C mode the final application
  will need two sets of RTL libraries: CRTL and C++RTL what strongly
  increased binaries size.

For the above I think that these three libraries should be excluded
from default RC2 builds.

Later I'll make tests with DOS and HPUX builds.
I'm still looking for someone who can make tests with SunOS.
Maybe some of you knows some free shell hosts where such tests
can be done. SF compile farm is down.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] RC2 checklist update #2

2008-07-02 Thread Szakáts Viktor




Hi Przemek,


- Darwin Harbour compiler problem.
 Lorenzo, any feedback from you as a Darwin user?


This looks really critical and for sure the problem has to be
located and fixed. Unfortunately I do not have MacOSX to make
test myself.


Okay. What bothers me, is that there is no
line number or anything in the error message.


Pending, non-critical:
- 64bit C-mode startup not implemented in hbinit.h.

   Only for MSVC. I do not know if it supports startup
   code for C mode at all. GCC uses constructor attribute
   and it works well. See in MSVC64 documentation if it's
   possible to mark function as executed at startup.


I won't have time for that now (not to mention I have
no 64 bit XP/Vista running anywhere). So lets leave it
for later, it's not critical.


- WinCE compatible screen selection code in gtwvt.c.
Postponed:
- FreeImage under Linux fails.


- The hbsqlit2 and hbsqlit3 produce a lot of warnings and cannot
 be compiled in C++ mode so they will not work for any compilers
 we are using in C++ mode (f.e. OpenWatcom, G++). They need serious
 cleanup for C++ which probably can be joined with warning cleanup.

- HBZipArch still produce a lot of warnings and it cannot be compiled
 in pure C mode. It's mostly C++ code which needs C++ compiler.
 If core harbour code was compiled in C mode the final application
 will need two sets of RTL libraries: CRTL and C++RTL what strongly
 increased binaries size.

For the above I think that these three libraries should be excluded
from default RC2 builds.


Also hbw32ddr is affected, although I have a version which can
be compiled as .c. I'm not sure it'd be wise to change it
in RC2, maybe in RC3 or final.

Let's make this more granular. For the builds I've tried,
both hbsqlit-s work okay, so I see no reason to exclude them as is.
Same goes for hbziparch, which worked for me under Win32/BCC.

Other than that I fully agree to tame somehow these, or
exclude them where they really don't work.


Later I'll make tests with DOS and HPUX builds.
I'm still looking for someone who can make tests with SunOS.
Maybe some of you knows some free shell hosts where such tests
can be done. SF compile farm is down.


Thanks a lot.

Unfortunately I don't, I only have Darwin. BTW, if you need
an account on either of my Macs (one PPC, one Core2), I can
set it up for you for SSH access. Just tell.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] RC2 checklist update #2

2008-07-02 Thread Massimo Belgrano


If you do not have MacOSX can use a emulator
Try with pearpc http://pearpc.sourceforge.net/ as describet at 
http://www.windowsdevcenter.com/pub/a/windows/2005/01/18/PearPC.html


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Przemyslaw 
Czerpak
Sent: Wednesday, July 02, 2008 4:50 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] RC2 checklist update #2

On Wed, 02 Jul 2008, Szakáts Viktor wrote:
> - Darwin Harbour compiler problem.
>   Lorenzo, any feedback from you as a Darwin user?

This looks really critical and for sure the problem has to be
located and fixed. Unfortunately I do not have MacOSX to make
test myself.


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Question about hbziparch

2008-07-02 Thread Miguel Angel Marchuet


At line 318 of hbzipnew.cpp there is this comment

// bAdded = true;

I think that was uncorrected comment.


Isn't it?

Best regards,
Miguel Angel marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Trapping recurrsion

2008-07-02 Thread Randy Portnoff


Hi all,

Similar to the way Harbour now traps GPF's (and logs some info in a 
text file), can it also detect  race conditions and log that as well? 
I am referring to situations where recursion occurs repeatedly which 
causes the app to just exit (ie. vanish). Ideally, a runtime error 
would be best.


For example, this causes the app to vanish.

func main()
SomeFunc()
return nil

func SomeFunc()
Main()
return nil

Regards,
Randy.


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hbziparch

2008-07-02 Thread Szakáts Viktor


Hi Miguel,

You're right. I'll commmit it ASAP.

Brgds,
Viktor

On 2008.07.02., at 17:22, Miguel Angel Marchuet wrote:


At line 318 of hbzipnew.cpp there is this comment

   // bAdded = true;

I think that was uncorrected comment.


Isn't it?

Best regards,
Miguel Angel marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Trapping recurrsion

2008-07-02 Thread Szakáts Viktor


Hi Randy,

This is a good idea, as I've already met such situation
in real life, and it's really annoying to see the
screen just "vanish" with no trace.

Maybe the general answer to this, is that we may
redirect all internal errors to a file, because
internal errors are currently inherently lost in
most full screen apps. (Recursive errors are
generating internal errors already IIRC).

Brgds,
Viktor

On 2008.07.02., at 17:21, Randy Portnoff wrote:


Hi all,

Similar to the way Harbour now traps GPF's (and logs some info in a  
text file), can it also detect  race conditions and log that as  
well? I am referring to situations where recursion occurs repeatedly  
which causes the app to just exit (ie. vanish). Ideally, a runtime  
error would be best.


For example, this causes the app to vanish.

func main()
SomeFunc()
return nil

func SomeFunc()
Main()
return nil

Regards,
Randy.


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Question about hbziparch

2008-07-02 Thread Miguel Angel Marchuet


I think it will be completely removed too in hbzipcom.cpp

Best regards,
Miguel Angel marchuet

Szakáts Viktor escribió:

Hi Miguel,

You're right. I'll commmit it ASAP.

Brgds,
Viktor

On 2008.07.02., at 17:22, Miguel Angel Marchuet wrote:


At line 318 of hbzipnew.cpp there is this comment

   // bAdded = true;

I think that was uncorrected comment.


Isn't it?


Best regards,
Miguel Angel marchuet
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour



___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-02 11:57 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

2008-07-02 Thread Szakáts Viktor


Hi Przemek,

  ! fixed WINCE builds. It was only for MiGWCE which partially  
emulates

GetSystemMenu() but probably other builds will report that this
function is missing.
If possible please test if current Harbour application can be
executed in real WinCE environment.


Can you please try attached gtwvt.c with WinCE?
I've restored a complete implementation of screen
selection, which doesn't use InvertRgn(). If it work,
we could use it for WinCE.


I've tried now, and it won't work because the
selection logic above has changed. Otherwise
InvertRect() also doesn't exist in WinCE, but
PatBlt() can be used as an equivalent.

I'll leave this for now.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 18:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

2008-07-02 Thread Przemyslaw Czerpak

2008-07-02 18:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/hbodbc/Makefile
* added test for header files in non W32 builds
  ODBC is not standard system part in other then MS-Window platforms

  * harbour/contrib/hbgf/hbgfgtk/Makefile
* updated path check for GTK header files
  In fact it still can give wrong results in different
  Linux or other *nixes distributions. The real path to GTK
  header files is unknown and should be always tested by
  pkg-config

best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 18:52 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-02 18:52 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * contrib/hbziparch/hbzipcom.cpp
   * contrib/hbziparch/hbzipnew.cpp
 ! Two lines commented by mistake now reenabled.
   Thanks Miguel.

   * source/rtl/gtwvt/gtwvt.c
 * Minor naming, formatting.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-02 18:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

2008-07-02 Thread Szakáts Viktor


Hi Przemek,

I think #include should be updated in odbc.c Linux branch,
as they are now trying to access with a hardcoded path.

Brgds,
Viktor

On 2008.07.02., at 18:39, Przemyslaw Czerpak wrote:


2008-07-02 18:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
 * harbour/contrib/hbodbc/Makefile
   * added test for header files in non W32 builds
 ODBC is not standard system part in other then MS-Window  
platforms


 * harbour/contrib/hbgf/hbgfgtk/Makefile
   * updated path check for GTK header files
 In fact it still can give wrong results in different
 Linux or other *nixes distributions. The real path to GTK
 header files is unknown and should be always tested by
 pkg-config

best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-02 18:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

2008-07-02 Thread Przemyslaw Czerpak

On Wed, 02 Jul 2008, Szakáts Viktor wrote:

Hi Viktor,

> I think #include should be updated in odbc.c Linux branch,
> as they are now trying to access with a hardcoded path.

Only for OpenWatcom builds. It's old temporary hack. I'll remove it.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] RC2 checklist update #2

2008-07-02 Thread Lorenzo Fiorini

On Wed, Jul 2, 2008 at 4:13 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote:

> Pending, critical:
> - Darwin Harbour compiler problem.
>  Lorenzo, any feedback from you as a Darwin user?

Sorry I'm a bit busy and often out of office until Friday.

I'll do my best.

best regards,
Lorenzo
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] RC2 checklist update #3

2008-07-02 Thread Szakáts Viktor


Pending, critical:
- Darwin Harbour compiler problem.

Postponed:
- FreeImage under Linux fails.
- 64bit C-mode startup not implemented in hbinit.h.
- WinCE compatible screen selection code in gtwvt.c.

Cleared:
- OS/2 hbtpathy.lib fails. Thanks Przemek!
- .dll creation with all MSVC compilers. Thanks Marek!
- HB_ZIPARCHCLEAN() issue. Thanks Przemek and Miguel.
- To not build .dll .libs for binary distros.
- ODBC/HBGFGTK issues.

Cleared platforms:
- Win32
- OS/2
- Linux

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] RC2 checklist update #3

2008-07-02 Thread Przemyslaw Czerpak

On Wed, 02 Jul 2008, Szakáts Viktor wrote:

Hi Viktor,

> Pending, critical:
> - Darwin Harbour compiler problem.

I've just made HPUX on BSD builds and except hbzpiarch, hbsqlit2 and
hbsqlit3 all is build cleanly. The problem you noticed with darwin
is probably local to your configuration. Please be sure that you made
clean build and old/new harbour header files are not mixed. It's also
possible that it's caused by setting some include dirs which change
system header order precedence.
Just like I've just check that I cannot remove the OpenWatcom hack
from Linux builds because OpenWatcom uses it's own set of header
files and setting /usr/include as include directory breaks it.
So for OpenWatcom build I even have to remove C_USR+=-D/usr/include

> Postponed:
> - FreeImage under Linux fails.

It' snot compiled when FrreImage is not installed. It's not
standard linux library so it's not a problem.

> - 64bit C-mode startup not implemented in hbinit.h.

Not 64-bit mode but only MSVC64.

> - WinCE compatible screen selection code in gtwvt.c.

Can be ignored but we have to test if final Harbour GTWVT application
can be executed in PocketPC. It's possible that C RTL supports some
functions which does not exist in real installation. If someone has
PocketPC and can make test then it will be nice.

> - ODBC/HBGFGTK issues.

The dir autodection and setting it in C_USR is problem for *nix builds
where header C files are part of system and non system C compilers comes
with their own set of headers.

BTW I do not know if HBGF is usable. Does any one uses it?

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 20:00 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

2008-07-02 Thread Przemyslaw Czerpak

2008-07-02 20:00 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/hbgf/Makefile
* do not include dir.cf when there is no platform dependent
  hbgf* library

best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] RC2 checklist update #2

2008-07-02 Thread Przemyslaw Czerpak

On Wed, 02 Jul 2008, Szakáts Viktor wrote:
> Let's make this more granular. For the builds I've tried,
> both hbsqlit-s work okay, so I see no reason to exclude them as is.
> Same goes for hbziparch, which worked for me under Win32/BCC.

Then please include them when you will make BCC binaries.
I only want to exclude from contrib/Makefile libraries
which cannot be cleanly compiled so by default:
   make install
should make clean build without any warnings or errors.
If you want to create additional libraries which cannot
be cleanly compiled if will be enough to set HB_CONTRIBLIBS
or execute
   make install
in given contrib library directory.

> Other than that I fully agree to tame somehow these, or
> exclude them where they really don't work.

And they don't for some compilers. hbsqlit* cannot be compiled
by any C++ compiler and hbziparch cannot be compiled by any C
compiler which does not also support C++ mode. So they work only
for chosen builds and only for such builds should be enabled.
If we clean hbsqlit* then IMHO they should be included.
The hbziparch is different problem. IMHO instead of investing
time in this library we should extend hbmzip and add missing
functionality.

> Unfortunately I don't, I only have Darwin. BTW, if you need
> an account on either of my Macs (one PPC, one Core2), I can
> set it up for you for SSH access. Just tell.

If you will still have the problem with MacOSX builds then I will
have to ask you about it.
But first please try to redirect stderr to file, f.e.
   ./make_gnu.sh 2> log_drw.err; set >> log_drw.err
and send it to me. Maybe it will have some warnings which
tell us what is wrong.

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] RC2 checklist update #3

2008-07-02 Thread Szakáts Viktor




Hi Przemek,


Hi Viktor,


Pending, critical:
- Darwin Harbour compiler problem.


I've just made HPUX on BSD builds and except hbzpiarch, hbsqlit2 and
hbsqlit3 all is build cleanly. The problem you noticed with darwin
is probably local to your configuration. Please be sure that you made
clean build and old/new harbour header files are not mixed. It's also
possible that it's caused by setting some include dirs which change
system header order precedence.


Thanks. You might well be right. I didn't check
the most obvious... I indeed just did an update and
a build. Not even a clean. Arrggh.

Will redo ASAP.


Just like I've just check that I cannot remove the OpenWatcom hack
from Linux builds because OpenWatcom uses it's own set of header
files and setting /usr/include as include directory breaks it.
So for OpenWatcom build I even have to remove C_USR+=-D/usr/include


Okay.


Postponed:
- FreeImage under Linux fails.


It' snot compiled when FrreImage is not installed. It's not
standard linux library so it's not a problem.


Okay. Let's solve this later.


- 64bit C-mode startup not implemented in hbinit.h.


Not 64-bit mode but only MSVC64.


Yes of course, that's what I meant.


- WinCE compatible screen selection code in gtwvt.c.


Can be ignored but we have to test if final Harbour GTWVT application
can be executed in PocketPC. It's possible that C RTL supports some
functions which does not exist in real installation. If someone has
PocketPC and can make test then it will be nice.


I don't have any. I generally hate WinCE, which got
even worse when I had to deal with "industrial strength"
PocketPC machines as part of work. Other than that it
could be useful from a business POV, companies (and even
ppl) like it anyway for some reason.


- ODBC/HBGFGTK issues.


The dir autodection and setting it in C_USR is problem for *nix builds
where header C files are part of system and non system C compilers  
comes

with their own set of headers.


Yes. I had something like your solution in mind.


BTW I do not know if HBGF is usable. Does any one uses it?


I doubt. It's an interesting initiative, but since
it was not a trivial thing to even compile it, it
was dead for a long time. non-GNU make system still
'all' option still doesn't compile it.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] RC2 checklist update #2

2008-07-02 Thread Szakáts Viktor




Hi Przemek,


On Wed, 02 Jul 2008, Szakáts Viktor wrote:

Let's make this more granular. For the builds I've tried,
both hbsqlit-s work okay, so I see no reason to exclude them as is.
Same goes for hbziparch, which worked for me under Win32/BCC.


Then please include them when you will make BCC binaries.
I only want to exclude from contrib/Makefile libraries
which cannot be cleanly compiled so by default:
  make install
should make clean build without any warnings or errors.
If you want to create additional libraries which cannot
be cleanly compiled if will be enough to set HB_CONTRIBLIBS
or execute
  make install
in given contrib library directory.


Can we please do this after RC2? Or cannot we add some
hacks to exclude it locally?

I simply don't want to retest the whole build process
and start to mess with manual contrib override, because
of this modification.

This problem was obvious since months, so if we want
to change it let's give it some more though and let's
do it with the less impact this close to RC2.


And they don't for some compilers. hbsqlit* cannot be compiled

by any C++ compiler and hbziparch cannot be compiled by any C
compiler which does not also support C++ mode. So they work only
for chosen builds and only for such builds should be enabled.
If we clean hbsqlit* then IMHO they should be included.
The hbziparch is different problem. IMHO instead of investing
time in this library we should extend hbmzip and add missing
functionality.


I don't personally care about hbziparch, I don't use it,
and don't plan to use it, it's probably the ugliest code
in whole Harbour. I use hbmzip, too. Yet it seems to be
a popular contrib.

I don't know, let the group decide.

In any case, you can disable it for additional platforms,
compilers as you wish.


Unfortunately I don't, I only have Darwin. BTW, if you need
an account on either of my Macs (one PPC, one Core2), I can
set it up for you for SSH access. Just tell.


If you will still have the problem with MacOSX builds then I will
have to ask you about it.
But first please try to redirect stderr to file, f.e.
  ./make_gnu.sh 2> log_drw.err; set >> log_drw.err
and send it to me. Maybe it will have some warnings which
tell us what is wrong.


I got that part okay.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] BUG: hb_errInternal() -> abnormal app close

2008-07-02 Thread Szakáts Viktor


Hi Przemek and all,

I've just run into a very important problem with Harbour.

An internal error will close the apps window, but the
app will continue to run eithout a window, with all the
files locked, etc, until I kill the process from Task
Manager.

I've tested with with Windows / GTWVT, so your milage
may vary.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Trapping recurrsion

2008-07-02 Thread Szakáts Viktor


Hi Randy,

Here is the internal error logging implemented.
Copy the file to source/rtl/ and recompile.

Brgds,
Viktor



errorint.c
Description: Binary data




On 2008.07.02., at 17:21, Randy Portnoff wrote:


Hi all,

Similar to the way Harbour now traps GPF's (and logs some info in a  
text file), can it also detect  race conditions and log that as  
well? I am referring to situations where recursion occurs repeatedly  
which causes the app to just exit (ie. vanish). Ideally, a runtime  
error would be best.


For example, this causes the app to vanish.

func main()
SomeFunc()
return nil

func SomeFunc()
Main()
return nil

Regards,
Randy.


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 20:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-02 20:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * make_gcc.sh
   * make_gnu.sh
 + Added Darwin to architecure autodetection.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] RC2 checklist update #4

2008-07-02 Thread Szakáts Viktor


Pending:
- hb_errInternal() problem: not terminating app (with GTWVT).
  anyhow the exit() call looks a bit suspicious there by now.
- Excluding unclean libs:
Linux/HPUX/BSD: hbsqlit2, hbsqlit3, hbziparch
Windows: hbwhat32
  I suggest to use some Makefile local method for this,
  or some other temp hacks.
- SunOS to be tested.

Postponed:
- FreeImage (if available) under Linux fails.
- Win64 C-mode startup not implemented in hbinit.h.
- WinCE compatible screen selection code in gtwvt.c.

Cleared:
- Darwin problem turned out to be a build mistake.
- OS/2 hbtpathy.lib fails. Thanks Przemek!
- .dll creation with all MSVC compilers. Thanks Marek!
- HB_ZIPARCHCLEAN() issue. Thanks Przemek and Miguel.
- To not build .dll .libs for binary distros.
- ODBC/HBGFGTK issues.

Cleared platforms:
- Win32
- Win64
- OS/2
- Linux
- Darwin PPC
- Darwin Unibin
- HPUX
- BSD

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 21:26 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

2008-07-02 Thread Przemyslaw Czerpak

2008-07-02 21:26 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/make_xmingwce.sh
  * harbour/bin/hb-mkslib.sh
  * harbour/make_tgz.sh
+ added Darwin and OS2 to architecure autodetection.

best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] RC2 checklist update #5

2008-07-02 Thread Szakáts Viktor


Pending:
- hb_errInternal() problem: not terminating app (with GTWVT).
 anyhow the exit() call looks a bit suspicious there by now.
- Excluding unclean libs:
   Linux/HPUX/BSD: hbsqlit2, hbsqlit3, hbziparch
   GCC: hbsqlit2, hbsqlit3 (just noticed error in Windows)
   Windows: hbwhat32
 I suggest to use some Makefile local method for this,
 or some other temp hacks.
- SunOS to be tested.
- DOS32/DJGPP 4.2.3 warnings:
../../spd.c: In function 'SCItm':
../../spd.c:80: warning: unused parameter 'ulMaxBuf'
../../hbmzip.c: In function 'hb_zipStoreFile':
../../hbmzip.c:545: warning: unused variable 'TODO'
../../hbmzip.c: In function 'hb_unzipExtractCurrentFile':
../../hbmzip.c:760: warning: unused variable 'TODO'

Postponed:
- FreeImage (if available) under Linux fails.
- Win64 C-mode startup not implemented in hbinit.h.
- WinCE compatible screen selection code in gtwvt.c.

Cleared:
- Darwin problem turned out to be a build mistake.
- OS/2 hbtpathy.lib fails. Thanks Przemek!
- .dll creation with all MSVC compilers. Thanks Marek!
- HB_ZIPARCHCLEAN() issue. Thanks Przemek and Miguel.
- To not build .dll .libs for binary distros.
- ODBC/HBGFGTK issues.
- hbsqlit2, hbsqlit3 excluded from DOS builds.

Cleared platforms:
- Win32
- Win64
- OS/2
- Linux
- Darwin PPC
- Darwin Unibin
- HPUX
- BSD
- DOS32 (DJGPP 4.2.3) (with few contrib warnings)

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 22:27 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-02 22:27 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * contrib/hbsqlit2/Makefile
   * contrib/hbsqlit3/Makefile
 ! Excluded from DOS builds.

   * contrib/Makefile
 - Commented following contribs from GNU-make default builds 
   until different platform/compiler issues and excessive 
   warnings are resolved:
   hbsqlit2, hbsqlit3, hbw32ddr, hbwhat32, hbziparch
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] RC2 checklist update #6

2008-07-02 Thread Szakáts Viktor


Pending:
- hb_errInternal() problem: not terminating app (with GTWVT).
  anyhow the exit() call looks a bit suspicious there by now.
- SunOS to be tested.
- DOS32/DJGPP 4.2.3 warnings:
../../spd.c: In function 'SCItm':
../../spd.c:80: warning: unused parameter 'ulMaxBuf'
../../hbmzip.c: In function 'hb_zipStoreFile':
../../hbmzip.c:545: warning: unused variable 'TODO'
../../hbmzip.c: In function 'hb_unzipExtractCurrentFile':
../../hbmzip.c:760: warning: unused variable 'TODO'

Cleared:
- Exlcuded unclean contribs from GNU-make system.

Cleared platforms:
- Win32
- Win64
- OS/2
- Linux
- Darwin PPC
- Darwin Unibin
- HPUX
- BSD
- DOS32 (DJGPP 4.2.3) (with few contrib warnings)

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 22:42 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-02 22:42 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * contrib/hbsqlit3/Makefile
   * contrib/Makefile
 + Reenabled hbsqlit3 for w32 platform.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 14:35 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])

2008-07-02 Thread Pritpal Bedi


2008-07-02 14:35 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])
  * contrib/gtwvg/gtwvg.c
  * source/rtl/gtwvt/gtwvt.c
! Changed the wat EXIT procedure works.
; The change is provided by Ron Pinkas so I have implemented as is.
  Before also I was not finding any problems on Harbour but 
  appln was GPFing on Exit with GTWVG.
; TOCHECK: Viktor see if it resolves the EXIT problem you are reporting 

Regards
Pritpal Bedi
-- 
View this message in context: 
http://www.nabble.com/2008-07-02-14%3A35-UTC-0800-Pritpal-Bedi-%28pritpal%40vouchcac.com%29-tp18247414p18247414.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 23:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-02 23:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * source/rtl/gtwvt/gtwvt.c
 ! Removed unused variable.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 2008-07-02 14:35 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])

2008-07-02 Thread Szakáts Viktor


Thanks a lot Pritpal (and also to Ron), it does resolve
the problem for me.

Brgds,
Viktor

On 2008.07.02., at 23:38, Pritpal Bedi wrote:



2008-07-02 14:35 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])
 * contrib/gtwvg/gtwvg.c
 * source/rtl/gtwvt/gtwvt.c
   ! Changed the wat EXIT procedure works.
   ; The change is provided by Ron Pinkas so I have implemented as is.
 Before also I was not finding any problems on Harbour but
 appln was GPFing on Exit with GTWVG.
   ; TOCHECK: Viktor see if it resolves the EXIT problem you are  
reporting


Regards
Pritpal Bedi
--
View this message in context: 
http://www.nabble.com/2008-07-02-14%3A35-UTC-0800-Pritpal-Bedi-%28pritpal%40vouchcac.com%29-tp18247414p18247414.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] RC2 checklist update #7

2008-07-02 Thread Szakáts Viktor


Pending:
- SunOS to be tested.
- DOS32/DJGPP 4.2.3 warnings:
../../spd.c: In function 'SCItm':
../../spd.c:80: warning: unused parameter 'ulMaxBuf'
I'd suggest to postpone these two, as these are signs
for missing implementations:
../../hbmzip.c: In function 'hb_zipStoreFile':
../../hbmzip.c:545: warning: unused variable 'TODO'
../../hbmzip.c: In function 'hb_unzipExtractCurrentFile':
../../hbmzip.c:760: warning: unused variable 'TODO'

Cleared:
- Exlcuded unclean contribs from GNU-make system.
- hb_errInternal() problem: not terminating app (with GTWVT/GTWVG).
  (Thanks Ron and Pritpal)

Cleared platforms:
- Win32
- Win64
- OS/2
- Linux
- Darwin PPC
- Darwin Unibin
- HPUX
- BSD
- DOS32 (DJGPP 4.2.3) (with few contrib warnings)

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-02 23:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-02 23:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * source/rtl/gtwvt/gtwvt.c
 ! Removed unused variable.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Harbour Online Help # 2

2008-07-02 Thread Pritpal Bedi


Hello Everybody

Please approve new layout of Harbour Online Help Manual at

http://www.voych.info/harbour

Please click harbour/contrib/gtwvg

Rest pages will be uploaded within a day or two.

Your comment/suggesions are highly appreciated.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/Harbour-Online-Help---2-tp18249507p18249507.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Harbour Online Help # 2

2008-07-02 Thread Phil Barnett

On Wednesday 02 July 2008 08:18:15 pm Pritpal Bedi wrote:
> Hello Everybody
>
> Please approve new layout of Harbour Online Help Manual at
>
> http://www.voych.info/harbour

I get unknown host on that web address.

-- 
Waiting for sunspots.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Harbour Online Help # 2

2008-07-02 Thread Pritpal Bedi


Phil

Check the message agian. Edited typo mistake.

http://www.vouch.info/harbour

Regards
Pritpal Bedi


-- 
View this message in context: 
http://www.nabble.com/Harbour-Online-Help---2-tp18249507p18249693.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Internal errors to hb_out.log

2008-07-02 Thread Szakáts Viktor


Hi all,

Find attached hb_errInternal() function which
writes internal error details, along with the
stack, to hb_out.log (by default).

The code looks quite humble, tested okay under
BCC, logic is similar to the logging we use in
fm.c and extrap.c.

Please comment, if we should include this before
RC2. I personally think it's extremely useful,
especially to gather possible RC2 problems.

[ Credits to Randy Portnoff for the idea. ]

Brgds,
Viktor



errorint.c
Description: Binary data


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Harbour Online Help # 2

2008-07-02 Thread Phil Barnett

On Wednesday 02 July 2008 08:40:28 pm Pritpal Bedi wrote:
> Phil
>
> Check the message agian. Edited typo mistake.
>
> http://www.vouch.info/harbour
>
> Regards
> Pritpal Bedi

Who can add items and data to it?

-- 
Waiting for sunspots.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: RC2 anything pending?

2008-07-02 Thread David Arturo Macias Corona

With current Harbour code under OS/2 build fine with just "well known" 
messages:


-
[E:\harbourprerc2\harbour]make -r   1>make_gnu.log
../../gtstd.c: In function `hb_gt_std_ReadKey':
../../gtstd.c:389: warning: unused variable `TODO'
../../hbmzip.c: In function `hb_zipStoreFile':
../../hbmzip.c:545: warning: unused variable `TODO'
../../hbmzip.c: In function `hb_unzipExtractCurrentFile':
../../hbmzip.c:760: warning: unused variable `TODO'
-

Testing hbtpathy it build hbtpathy.a with these messages:
-
../../tpos2.c: In function `HB_FUN_P_INITPORTSPEED':
../../tpos2.c:72: warning: unused variable `rc'
../../tpos2.c: In function `HB_FUN_P_WRITEPORT':
../../tpos2.c:157: warning: signed and unsigned type in conditional 
expression

../../tpos2.c: In function `HB_FUN_P_OUTFREE':
../../tpos2.c:163: warning: missing initializer
../../tpos2.c:163: warning: (near initialization for `rxqueue.cb')
-

Based in results and maybe fixes, can be hbtpathy included in standard 
build again ?


David Macias


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: Re: [Harbour] RC2 anything pending?

2008-07-02 Thread Petr Chornyj

Szakáts Viktor wrote:
> 
> 
>> b) A long list of warnings
>> Seem to be related to sqlite
>> Look below for "B portion" catched from screen
> 
> Yes, unfortunately foreign code throws lots of
> warnings.
> 
> 

>From SQLite FAQ

(17) I get hundreds of compiler warnings when I compile SQLite. Isn't this a
problem? Doesn't it indicate poor code quality?

Quality assurance in SQLite is done using full-coverage testing, not by
compiler warnings or other static code analysis tools. In other words, we
verify that SQLite actually gets the correct answer, not that it merely
satisfies stylistic constraints. Over two-thirds of the SQLite code base is
devoted purely to testing. The SQLite test suite runs many thousands of
separate test cases and many of those test cases are parameterized so that
hundreds of thousands of tests involving millions of SQL statements are run
and evaluated for correctness prior to every release. The developers use
code coverage tools to verify that all paths through the code are tested.
Whenever a bug is found in SQLite, new test cases are written to exhibit the
bug so that the bug cannot recur undetected in the future.

During testing, the SQLite library is compiled with special
instrumentation that allows the test scripts to simulate a wide variety of
failures in order to verify that SQLite recovers correctly. Memory
allocation is carefully tracked and no memory leaks occur, even following
memory allocation failures. A custom VFS layer is used to simulate operating
system crashes and power failures in order to insure that transactions are
atomic across these events. A mechanism for deliberately injecting I/O
errors shows that SQLite is resilient to such malfunctions. (As an
experiment, try inducing these kinds of errors on other SQL database engines
and see what happens!)

We also run SQLite using _valgrind_ on Linux and verify that it detects
no problems.

Some people say that we should eliminate all warnings because benign
warnings mask real warnings that might arise in future changes. This is true
enough. But in reply, the developers observe that all warnings have already
been fixed in the compilers used for SQLite development (various versions of
GCC). Compiler warnings only arise from compilers that the developers do not
have access to.

Regards,
Petr

-- 
View this message in context: 
http://www.nabble.com/RC2-anything-pending--tp18218739p18252685.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-03 08:48 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-03 08:48 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * contrib/hbtpathy/tpos2.c
 ! Blind fix for three OS/2 warnings. David please test.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 2008-07-03 08:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu)

2008-07-02 Thread Szakáts Viktor

2008-07-03 08:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
   * contrib/hbsqlit3/Makefile
 * Changed so that only failing BSD and HPUX platforms 
   are excluded.
--
Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] RC2 anything pending?

2008-07-02 Thread Szakáts Viktor


Thanks Petr. I'm personally confident that the SQLite is a very
mature and well tested product. These lines confirmed it.

   Some people say that we should eliminate all warnings because  
benign
warnings mask real warnings that might arise in future changes. This  
is true
enough. But in reply, the developers observe that all warnings have  
already
been fixed in the compilers used for SQLite development (various  
versions of
GCC). Compiler warnings only arise from compilers that the  
developers do not

have access to.


With SQLite3, I could see no problem either, but the number of warnings
is still high. We're probably using some higher level that them.

I've adjusted its Makefile to only exclude BSD and HPUX, which
were reported as failing platforms by Przemek.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

76 matches

Mail list logo