Re: [Harbour] Re: SF.net SVN: harbour-project:[10724]

[Francesco Saverio Giudice]

Hi Chen,

Il 30/03/2009 7.10, Chen Kedem ha scritto:

Angel Pais wrote:

Performance went to the sky !
Scalability not so much...

:

03/29/09 17:58:22 Windows Server 2003 / XP x64 5.2.3790
Harbour 1.1.0dev (Rev. 10726) (MT)+ Microsoft Visual C++ 14.0.24999 (32-bit)


It looks like Windows 64-bit version and 32-bit executable. Can it effect the 
results?

No, O.S. it is not correctly detected, in mine case, but I think also in 
Angel case, is Windows 2003 Server 32 bit. I have to fix OS detection.


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

Re: [Harbour] Re: SF.net SVN: harbour-project:[10724]

[Viktor Szakáts]

It's correctly detected, but could be made more accurate by using some
additional techniques to distinguish between
Server 2003 and XP x64. The same version number is returned
for both of these OSes by MS, which is a bit misleading.

--
Viktor

On Mon, Mar 30, 2009 at 9:12 AM, Francesco Saverio Giudice <
i...@fsgiudice.com> wrote:

> Hi Chen,
>
> Il 30/03/2009 7.10, Chen Kedem ha scritto:
>
>> Angel Pais wrote:
>>
>>> Performance went to the sky !
>>> Scalability not so much...
>>>
>> :
>>
>>> 03/29/09 17:58:22 Windows Server 2003 / XP x64 5.2.3790
>>> Harbour 1.1.0dev (Rev. 10726) (MT)+ Microsoft Visual C++ 14.0.24999
>>> (32-bit)
>>>
>>
>> It looks like Windows 64-bit version and 32-bit executable. Can it effect
>> the results?
>>
>>  No, O.S. it is not correctly detected, in mine case, but I think also in
> Angel case, is Windows 2003 Server 32 bit. I have to fix OS detection.
>
> Best regards,
> Francesco
>
>
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: SF.net SVN: harbour-project:[10724]

[Francesco Saverio Giudice]

Hi Viktor,


Il 30/03/2009 9.19, Viktor Szakáts ha scritto:
It's correctly detected, but could be made more accurate by 
using some additional techniques to distinguish between 
Server 2003 and XP x64. The same version number is returned 
for both of these OSes by MS, which is a bit misleading.




No, please check below function and compare with that in SVN.


Best Regards,
Francesco

//
// Product types
// This list grows with each OS release.
//
// There is no ordering of values to ensure callers
// do an equality test i.e. greater-than and less-than
// comparisons are not useful.
//
// NOTE: Values in this list should never be deleted.
//   When a product-type 'X' gets dropped from a
//   OS release onwards, the value of 'X' continues
//   to be used in the mapping table of GetProductInfo.
//

#define PRODUCT_UNDEFINED   0x

#define PRODUCT_ULTIMATE0x0001
#define PRODUCT_HOME_BASIC  0x0002
#define PRODUCT_HOME_PREMIUM0x0003
#define PRODUCT_ENTERPRISE  0x0004
#define PRODUCT_HOME_BASIC_N0x0005
#define PRODUCT_BUSINESS0x0006
#define PRODUCT_STANDARD_SERVER 0x0007
#define PRODUCT_DATACENTER_SERVER   0x0008
#define PRODUCT_SMALLBUSINESS_SERVER0x0009
#define PRODUCT_ENTERPRISE_SERVER   0x000A
#define PRODUCT_STARTER 0x000B
#define PRODUCT_DATACENTER_SERVER_CORE  0x000C
#define PRODUCT_STANDARD_SERVER_CORE0x000D
#define PRODUCT_ENTERPRISE_SERVER_CORE  0x000E
#define PRODUCT_ENTERPRISE_SERVER_IA64  0x000F
#define PRODUCT_BUSINESS_N  0x0010
#define PRODUCT_WEB_SERVER  0x0011
#define PRODUCT_CLUSTER_SERVER  0x0012
#define PRODUCT_HOME_SERVER 0x0013
#define PRODUCT_STORAGE_EXPRESS_SERVER  0x0014
#define PRODUCT_STORAGE_STANDARD_SERVER 0x0015
#define PRODUCT_STORAGE_WORKGROUP_SERVER0x0016
#define PRODUCT_STORAGE_ENTERPRISE_SERVER   0x0017
#define PRODUCT_SERVER_FOR_SMALLBUSINESS0x0018
#define PRODUCT_SMALLBUSINESS_SERVER_PREMIUM0x0019
#define PRODUCT_HOME_PREMIUM_N  0x001A
#define PRODUCT_ENTERPRISE_N0x001B
#define PRODUCT_ULTIMATE_N  0x001C
#define PRODUCT_WEB_SERVER_CORE 0x001D
#define PRODUCT_MEDIUMBUSINESS_SERVER_MANAGEMENT0x001E
#define PRODUCT_MEDIUMBUSINESS_SERVER_SECURITY  0x001F
#define PRODUCT_MEDIUMBUSINESS_SERVER_MESSAGING 0x0020
#define PRODUCT_SMALLBUSINESS_SERVER_PRIME  0x0021
#define PRODUCT_HOME_PREMIUM_SERVER 0x0022
#define PRODUCT_SERVER_FOR_SMALLBUSINESS_V  0x0023
#define PRODUCT_STANDARD_SERVER_V   0x0024
#define PRODUCT_DATACENTER_SERVER_V 0x0025
#define PRODUCT_ENTERPRISE_SERVER_V 0x0026
#define PRODUCT_DATACENTER_SERVER_CORE_V0x0027
#define PRODUCT_STANDARD_SERVER_CORE_V  0x0028
#define PRODUCT_ENTERPRISE_SERVER_CORE_V0x0029
#define PRODUCT_HYPERV  0x002A

#define PRODUCT_UNLICENSED  0xABCDABCD


#if _WIN32_WINNT >= 0x0501
WINBASEAPI void WINAPI
GetNativeSystemInfo(
OUT LPSYSTEM_INFO lpSystemInfo
);
#endif


// from microsoft SDK
HB_FUNC( XGUI_API_GETWINVERSTRING )
{
   OSVERSIONINFOEX osvi;
   SYSTEM_INFO si;
   BOOL bOsVersionInfoEx;

   char szResult[ STR_LEN ];
   char szBuff[ 80 ];

   //szResult = ( char * ) hb_xgrab( STR_LEN + 2 );
   strcpy( szResult, "" );

   // Try calling GetVersionEx using the OSVERSIONINFOEX structure.
   // If that fails, try using the OSVERSIONINFO structure.

   ZeroMemory(&si, sizeof(SYSTEM_INFO));
   ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
   osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);

   if( !(bOsVersionInfoEx = GetVersionEx ((OSVERSIONINFO *) &osvi)) )
   {
  osvi.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
  if (! GetVersionEx ( (OSVERSIONINFO *) &osvi) )
 hb_retc( "version unknown" );
 return;
   }


   switch (osvi.dwPlatformId)
   {
  // Test for the Windows NT product family.

  case VER_PLATFORM_WIN32_NT:

  // Test for the specific product.

  if ( osvi.dwMajorVersion == 6 && osvi.dwMinorVersion == 0 )
  {
 // alternative call for BCC55
 typedef BOOL (WINAPI *PGPI)(DWORD, DWORD, DWORD, DWORD, PDWORD);

 PGPI pGPI;
 DWORD dwType;

 if( osvi.wProductType == VER_NT_WORKSTATION )
 {
 strcat( szResult, "Mic

Re: [Harbour] Re: SF.net SVN: harbour-project:[10724]

[Viktor Szakáts]

Both returns 5.2, and I didn't bother to do any above heavy lifting.
Most of these version details is probably unnecessary for Harbour,
but XP x64 and Server 2003 detection would be useful.

Although this code from below:
---
 else if( si.wProcessorArchitecture==PROCESSOR_ARCHITECTURE_IA64 &&
 osvi.wProductType == VER_NT_WORKSTATION )
{
   strcat( szResult, "Microsoft Windows XP Professional x64 Edition
" );
}
---

looks a bit suspicious to me as it checks for IA64 to detect x64? Could
be correct seeing the mess around Windows version though ;)

--
Viktor

On Mon, Mar 30, 2009 at 9:32 AM, Francesco Saverio Giudice <
i...@fsgiudice.com> wrote:

> Hi Viktor,
>
>
> Il 30/03/2009 9.19, Viktor Szakáts ha scritto:
>
>> It's correctly detected, but could be made more accurate by using some
>> additional techniques to distinguish between Server 2003 and XP x64. The
>> same version number is returned for both of these OSes by MS, which is a bit
>> misleading.
>>
>>
> No, please check below function and compare with that in SVN.
>
>
> Best Regards,
> Francesco
>
> //
> // Product types
> // This list grows with each OS release.
> //
> // There is no ordering of values to ensure callers
> // do an equality test i.e. greater-than and less-than
> // comparisons are not useful.
> //
> // NOTE: Values in this list should never be deleted.
> //   When a product-type 'X' gets dropped from a
> //   OS release onwards, the value of 'X' continues
> //   to be used in the mapping table of GetProductInfo.
> //
>
> #define PRODUCT_UNDEFINED   0x
>
> #define PRODUCT_ULTIMATE0x0001
> #define PRODUCT_HOME_BASIC  0x0002
> #define PRODUCT_HOME_PREMIUM0x0003
> #define PRODUCT_ENTERPRISE  0x0004
> #define PRODUCT_HOME_BASIC_N0x0005
> #define PRODUCT_BUSINESS0x0006
> #define PRODUCT_STANDARD_SERVER 0x0007
> #define PRODUCT_DATACENTER_SERVER   0x0008
> #define PRODUCT_SMALLBUSINESS_SERVER0x0009
> #define PRODUCT_ENTERPRISE_SERVER   0x000A
> #define PRODUCT_STARTER 0x000B
> #define PRODUCT_DATACENTER_SERVER_CORE  0x000C
> #define PRODUCT_STANDARD_SERVER_CORE0x000D
> #define PRODUCT_ENTERPRISE_SERVER_CORE  0x000E
> #define PRODUCT_ENTERPRISE_SERVER_IA64  0x000F
> #define PRODUCT_BUSINESS_N  0x0010
> #define PRODUCT_WEB_SERVER  0x0011
> #define PRODUCT_CLUSTER_SERVER  0x0012
> #define PRODUCT_HOME_SERVER 0x0013
> #define PRODUCT_STORAGE_EXPRESS_SERVER  0x0014
> #define PRODUCT_STORAGE_STANDARD_SERVER 0x0015
> #define PRODUCT_STORAGE_WORKGROUP_SERVER0x0016
> #define PRODUCT_STORAGE_ENTERPRISE_SERVER   0x0017
> #define PRODUCT_SERVER_FOR_SMALLBUSINESS0x0018
> #define PRODUCT_SMALLBUSINESS_SERVER_PREMIUM0x0019
> #define PRODUCT_HOME_PREMIUM_N  0x001A
> #define PRODUCT_ENTERPRISE_N0x001B
> #define PRODUCT_ULTIMATE_N  0x001C
> #define PRODUCT_WEB_SERVER_CORE 0x001D
> #define PRODUCT_MEDIUMBUSINESS_SERVER_MANAGEMENT0x001E
> #define PRODUCT_MEDIUMBUSINESS_SERVER_SECURITY  0x001F
> #define PRODUCT_MEDIUMBUSINESS_SERVER_MESSAGING 0x0020
> #define PRODUCT_SMALLBUSINESS_SERVER_PRIME  0x0021
> #define PRODUCT_HOME_PREMIUM_SERVER 0x0022
> #define PRODUCT_SERVER_FOR_SMALLBUSINESS_V  0x0023
> #define PRODUCT_STANDARD_SERVER_V   0x0024
> #define PRODUCT_DATACENTER_SERVER_V 0x0025
> #define PRODUCT_ENTERPRISE_SERVER_V 0x0026
> #define PRODUCT_DATACENTER_SERVER_CORE_V0x0027
> #define PRODUCT_STANDARD_SERVER_CORE_V  0x0028
> #define PRODUCT_ENTERPRISE_SERVER_CORE_V0x0029
> #define PRODUCT_HYPERV  0x002A
>
> #define PRODUCT_UNLICENSED  0xABCDABCD
>
>
> #if _WIN32_WINNT >= 0x0501
> WINBASEAPI void WINAPI
> GetNativeSystemInfo(
>OUT LPSYSTEM_INFO lpSystemInfo
>);
> #endif
>
>
> // from microsoft SDK
> HB_FUNC( XGUI_API_GETWINVERSTRING )
> {
>   OSVERSIONINFOEX osvi;
>   SYSTEM_INFO si;
>   BOOL bOsVersionInfoEx;
>
>   char szResult[ STR_LEN ];
>   char szBuff[ 80 ];
>
>   //szResult = ( char * ) hb_xgrab( STR_LEN + 2 );
>   strcpy( szResult, "" );
>
>   // Try calling GetVersionEx using the OSVERSIONINFOEX structure.
>   // If that fails, try using the OSVERSIONINFO structure.
>
>   ZeroMemory(&si

Re: [Harbour] Re: SF.net SVN: harbour-project:[10724]

[Francesco Saverio Giudice]

Viktor,

Il 30/03/2009 9.43, Viktor Szakáts ha scritto:

Both returns 5.2, and I didn't bother to do any above heavy lifting.

Most of these version details is probably unnecessary for Harbour, 
but XP x64 and Server 2003 detection would be useful.


Although this code from below:
---
 else if( si.wProcessorArchitecture==PROCESSOR_ARCHITECTURE_IA64 &&
 osvi.wProductType == VER_NT_WORKSTATION )
{
   strcat( szResult, "Microsoft Windows XP Professional x64 
Edition " );

}
---

looks a bit suspicious to me as it checks for IA64 to detect x64? Could 
be correct seeing the mess around Windows version though ;)




I get code from MS Win SDK plus added unsupported versions (9x, etc).
You can check it at:
ms-help://MS.LHSMSSDK.1033/MS.LHSWinSDK.1033/sysinfo/base/getting_the_system_version.htm

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

RE: [Harbour] Re: SF.net SVN: harbour-project:[10724]

[Chen Kedem]

Viktor,

(maybe a bit off topic here, but you asked something like that a few days ago)
The following MS link is useful to check when was a given MS DLL shipped
and in what product: http://support.microsoft.com/dllhelp/

Hmm, well, their database use to include ALL the old products, now I can see
only Win2000 and later. Too bad (long time since I used that link).


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

[Harbour] SF.net SVN: harbour-project:[10732] trunk/harbour

[vszakats]

Revision: 10732
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10732&view=rev
Author:   vszakats
Date: 2009-03-30 08:03:36 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 10:01 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * config/win/owatcom.cf
  * config/linux/owatcom.cf
  * config/os2/owatcom.cf
- Reverted yesterdays attempt to make owatcom builds faster.
  After the change the compilation time went slower, the
  binaries got smaller, but execution speed got actually worse.
  I've left -oz option removed for win, that's the only
  remaining change, plus -5r in os2/dos.
  owatcom seems not very useful for production.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/linux/owatcom.cf
trunk/harbour/config/os2/owatcom.cf
trunk/harbour/config/win/owatcom.cf


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: SF.net SVN: harbour-project:[10724]

[Viktor Szakáts]

Thanks Chen.
MS also removed any pre-2000 information from MSDN pages, moreover
they've removed all obsolete (but nevertheless available) functions from
documentation, so I have to check headers, and they've even removed
pre-2000
availability information which is even worse (and they gained nothing). All
this Windows API world is very miserable to work with.

--
Viktor

On Mon, Mar 30, 2009 at 9:58 AM, Chen Kedem  wrote:

> Viktor,
>
> (maybe a bit off topic here, but you asked something like that a few days
> ago)
> The following MS link is useful to check when was a given MS DLL shipped
> and in what product: http://support.microsoft.com/dllhelp/
>
> Hmm, well, their database use to include ALL the old products, now I can
> see
> only Win2000 and later. Too bad (long time since I used that link).
>
>
>  Chen.
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



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

Re: [Harbour] Re: SF.net SVN: harbour-project:[10724]

[Viktor Szakáts]

You must be right, if you have code I can try on Windows XP x64 as I
have a legal
copy running in a VM here.

I've found this one:
http://www.codeguru.com/cpp/w-p/system/systeminformation/article.php/c8973__2/
[ but it seem to have forgotten about XP x64 ]

--
Viktor

On Mon, Mar 30, 2009 at 9:59 AM, Francesco Saverio Giudice <
i...@fsgiudice.com> wrote:

> Viktor,
>
> Il 30/03/2009 9.43, Viktor Szakáts ha scritto:
>
>> Both returns 5.2, and I didn't bother to do any above heavy lifting.
>>
>> Most of these version details is probably unnecessary for Harbour, but XP
>> x64 and Server 2003 detection would be useful.
>>
>> Although this code from below:
>> ---
>>  else if( si.wProcessorArchitecture==PROCESSOR_ARCHITECTURE_IA64 &&
>> osvi.wProductType == VER_NT_WORKSTATION )
>>{
>>   strcat( szResult, "Microsoft Windows XP Professional x64 Edition
>> " );
>>}
>> ---
>>
>> looks a bit suspicious to me as it checks for IA64 to detect x64? Could be
>> correct seeing the mess around Windows version though ;)
>>
>>
> I get code from MS Win SDK plus added unsupported versions (9x, etc).
> You can check it at:
>
> ms-help://MS.LHSMSSDK.1033/MS.LHSWinSDK.1033/sysinfo/base/getting_the_system_version.htm
>
> Best regards,
> Francesco
>
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



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

[Harbour] SF.net SVN: harbour-project:[10731] trunk/harbour

[vszakats]

Revision: 10731
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10731&view=rev
Author:   vszakats
Date: 2009-03-30 07:37:28 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 09:37 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * utils/hbmk2/hbmk2.prg
+ Added two Windows system libs. (also needed for QT)

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/utils/hbmk2/hbmk2.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[10733] trunk/harbour

[petr_ch]

Revision: 10733
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10733&view=rev
Author:   petr_ch
Date: 2009-03-30 08:23:58 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 11:30 UTC+0200 Petr Chornyj (myorg63 at mail.ru)
   * contrib/hbsqlit3/hbsqlit3.ch
   * contrib/hbsqlit3/hbsqlit3.c
  * Added support for sqlite_exec() callback. 
 Now the 3rd parameter is an optional callback that is invoked
 once for each row of any query results.
  * Now we can pass name of logfile as third parameter of
 sqlite3_trace(), sqlite3_profile(). 
  + Added sqlite3_set_authorizer() - 
 Compile-Time Authorization Callbacks.
  + Added sqlite3_busy_handler() - 
 A Callback To Handle SQLITE_BUSY Errors.
  + Added sqlite3_progress_handler() - Query Progress Callbacks.
  + Added sqlite3_commit_hook(), sqlite3_rollback_hook() -
 Commit And Rollback Notification Callbacks
  + Added sqlite3_backup_*() API for backups purposes.
  + Added sqlite3_initialize(), sqlite3_shutdown(), sqlite3_interrupt(),
 sqlite3_status(), sqlite3_db_status(), sqlite3_stmt_status(), 
 sqlite3_sql(), sqlite3_extended_errcode(), sqlite3_threadsafe(),
 sqlite3_memory_used(), sqlite3_memory_highwater(). 
  ! Fixed sqlite3_table_column_metadata().
  - Temporary disabled sqlite3_db_handle().
  * Minor changes, cleanup and formating. 
   + contrib/hbsqlit3/tests/authorizer.prg 
   + contrib/hbsqlit3/tests/backup.prg 
   + contrib/hbsqlit3/tests/hooks.prg 
  + Added for demonstration of new possibilities.
   + contrib/hbsqlit3/tests/metadata.prg 
  * Minor changes 

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbsqlit3/hbsqlit3.c
trunk/harbour/contrib/hbsqlit3/hbsqlit3.ch
trunk/harbour/contrib/hbsqlit3/tests/metadata.prg

Added Paths:
---
trunk/harbour/contrib/hbsqlit3/tests/authorizer.prg
trunk/harbour/contrib/hbsqlit3/tests/backup.prg
trunk/harbour/contrib/hbsqlit3/tests/hooks.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[10729] trunk/harbour

[Massimo Belgrano]

Very good!

2009/3/30 Przemyslaw Czerpak :
> On Sun, 29 Mar 2009, vouch...@users.sourceforge.net wrote:
>
> Hi,
>
>>     ; REQUEST ( Przemek ) - Can you please provide a GTWVT.C like
>>              skeleton .cpp which I could use as a base for GTQTC ?
>
> I'll try to make it in this week.
>
> best regards,
> Przemek
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



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

Re: [Harbour] Harbour Distribution - Ready-to-Use

[Massimo Belgrano]

Hi Pritpal
I have same Italian user that want route to the ready to use distribution
Is this last version?
are planed near update?

Have you made same progress regarding your old project of documentation?

Thanks in advance!


>
> On Wed, Mar 4, 2009 at 9:59 AM, Pritpal Bedi 
> wrote:
>>
>> WELCOME
>>
>> http://www.vouch.info/downloads/HarbourDev_10523_2009-03-04.exe
>>
>> This is Harbour's ready-to-use distibution
>> planned to be released once in a month including
>> the changes committed to SVN till the date of
>> release. This is not the rule. I may post
>> more than once in a month if there are major
>> commits and/or some important feature is
>> added/modified.
>>
>> This distro is aimed at newbies who find it
>> difficult to start with Harbour though everybody
>> can take advantage to the maximum.
>>
>> Please note that this is not an official release.
>> So you may expect bumps here-and-there. My
>> efforts will focus on the facts that release
>> maintain a standard to let the applns compile
>> properly.
>>
>> Every release will bear the "Revision No" and
>> "Date" in its setup name as -
>> HarbourDev_10523_2009-03-04.exe
>> which will facilitate to identify upto which
>> commit this release contain.
>>
>> The tree structure ( outlined below ) can be
>> used for production level development scenario.
>> It contains batch files to get Harbour binaries
>> from SVN tree for four compilers. As you can now
>> compile your applns with different compilers,
>> this enhances your productivity level to judge
>> which compiler is giving you the fastest and
>> optimum appln.
>>
>> To keep the tasks simple, I am assuming drive "C"
>> the development drive where Harbour SVN tree and
>> "harbour_dev" tree is hosted. All paths in the
>> batch files and xMate project files points to
>> c:\harbour and c:\harbour_dev.
>>
>> This distribution includes only binaries. Please
>> download SVN tree if you need sources or want to
>> play with the latest commits. It is not necessary
>> for your applications.
>>
>> In case you decide to have latest SVN binaries
>> then host it on drive C as module name "harbour".
>> Then invoke one of the makegnu_*.bat, depending
>> on the compiler of your choice. It will place
>> harbour binaries in respective subfolder of
>> "c:\harbour_dev".
>>
>> This distribution includes MINGW compiler under
>> c:\harbour_dev\mingw folder as its root. So
>> one is able to build appln for this compiler
>> without any extra effort. You can download other
>> compilers and place them in respective folders
>> in c:\harbour_dev, i.e., Borland's BCC under
>> c:\harbour_dev\bcc ( no suffix after bcc ), Sybase's
>> Open Watcom under c:\harbour_dev\watcom, Microsoft's
>> Visual C++ under c:\harbour_dev\msvc.
>> Once installed, just invole respective makegnu_*.bat.
>> Harbour binaries will be in place.
>>
>> As I has been working with xMate since its birth way
>> back in 2004, I have choosen it to be Project Builder
>> for this distribution. You are free to deploy
>> whatever you are accustomed to.
>>
>> As a demo appln I have selected
>> harbour/contrib/gtwvg/tests/demowvg.prg. This
>> demo unfolds Harbour power in depth plus different
>> ways one can employ to migrate his/her Clipper
>> applications to GUI world strating with
>> intermediatery semi GUI proto and culminating to
>> pure GUI proto. This demo also deploys the
>> in-development Xbase++ Parts clone whaich may
>> attract your attention. Moreoever, this demo
>> demonstrates MT ( multi-threading ) and multi-window
>> GT which can be a big productivity boost right
>> from the begining.
>>
>>
>> Following is the tree structure this disto contains.
>>
>>
>> c:\harbour_dev\
>>
>>   harbour\
>>      bcc\
>>         bin
>>         include
>>         lib
>>      msvc\
>>         bin
>>         include
>>         lib
>>      mingw\
>>         bin
>>         include
>>         lib
>>      watcom\
>>         bin
>>         include
>>         lib
>>
>>
>>   bcc\
>>      * distro tree
>>   msvc\
>>      * tree
>>   mingw\
>>      * tree
>>   watcom\
>>      * tree
>>
>>
>>
>>   xmate\
>>      *.files | folders
>>      /
>>      wvgBCC.env         ( tied with demowvgBCC.xhp )
>>      wvgMSVC.env        ( tied with demowvgMSVC.xhp )
>>      wvgMINGW.env       ( tied with demowvgMINGW.xhp )
>>      wvgWATCOM.env      ( tied with demowvgWATCOM.xhp )
>>
>>
>>   dev_projects\
>>      demowvg\
>>         demowvgBCC.xhp
>>         demowvgMSVC.xhp
>>         demowvgMINGW.xhp
>>         demowvgWATCOM.xhp
>>
>>      demoxbp\
>>         demoxbp.xhp
>>         * folders
>>      developers_own_folders\
>>         developer_project.xhp
>>
>>
>>
>>   dev_sources\
>>      demowvg\
>>         *.files
>>      tests\
>>         *.files
>>
>>
>>   dev_libs\
>>      # All together - it is a better design
>>
>>
>>   dev_exes\
>>      # All together of by project
>>        May be it is dependant on other resource files
>>
>>
>>
>>   ChangeLog   ( Harbour SVN ChangeLog : Binaries Upto : Top

[Harbour] SF.net SVN: harbour-project:[10734] trunk/harbour

[vszakats]

Revision: 10734
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10734&view=rev
Author:   vszakats
Date: 2009-03-30 08:30:30 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 10:27 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * utils/hbmk2/hbmk2.prg
! Don't attempt to strip leading 'lib' from libnames, since
  this breaks libs which actually begin with 'lib', not meant
  as a prefix. F.e. libpng, libhpdf, libjpeg.

  * contrib/hbqt/tests/hbqt.hbp
+ Added static QT libname as comment (for now).

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/tests/hbqt.hbp
trunk/harbour/utils/hbmk2/hbmk2.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Viktor Szakáts]

Hi Massimo, please try again with latest rev.
--
Viktor

On Sun, Mar 29, 2009 at 12:43 PM, Massimo Belgrano wrote:

> I have tried compiling tests
>
> c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib
> hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg
> hbmk: Processing: hbhpdf.hbp
> Harbour 1.1.0dev (Rev. 10721)
> Copyright (c) 1999-2009, http://www.harbour-project.org/
> Compiling 'harupdf.prg'...
> Lines 2245, Functions/Procedures 18
> Generating C source output to 'harupdf.c'... Done.
> C:\devl\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe:
> cann
> t find -lhpdf
> collect2: ld returned 1 exit status
> hbmk: Error: Running C compiler. 1:
>
>
> 2009/3/29  :
> > Revision: 10721
> >
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10721&view=rev
> > Author:   vszakats
> > Date: 2009-03-29 09:09:24 + (Sun, 29 Mar 2009)
> >
> > Log Message:
> > ---
> > 2009-03-29 11:02 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
> >  * INSTALL
> >  * external/Makefile
> >  + external/libhpdf/*
> >  + external/libpng/*
> >+ Added libharu and libpng to Harbour repository.
> >  Now it's possible to use libhpdf as static lib on all
> >  platforms. This is useful because this lib isn't yet part
> >  of Linux distros.
> >  libpng is only built for win/dos/os2 platforms.
> >  It's possible to override libpng location by using
> >  HB_INC_LIBPNG envvar.
> >
> >  * contrib/hbhpdf/Makefile
> >+ Look for libharu headers in /external dir.
> >
> >  * external/sqlite3/Makefile
> >- Disabled for bcc. Latest sqlite3 version breaks with this compiler:
> >  ---
> >  Error E2293 ../../sqlite3.c 29156: ) expected in function
> winCurrentTime
> >  Warning W8013 ../../sqlite3.c 29157: Possible use of 'timeW' before
> definition in function winCurrentTime
> >  Error E2379 ../../sqlite3.c 29157: Statement missing ; in function
> winCurrentTime
> >  Error E2379 ../../sqlite3.c 29158: Statement missing ; in function
> winCurrentTime
> >  Error E2379 ../../sqlite3.c 29160: Statement missing ; in function
> winCurrentTime
> >  Error E2293 ../../sqlite3.c 29161: ) expected in function
> winCurrentTime
> >  Error E2379 ../../sqlite3.c 29162: Statement missing ; in function
> winCurrentTime
> >  Error E2293 ../../sqlite3.c 29163: ) expected in function
> winCurrentTime
> >  Warning W8057 ../../sqlite3.c 29171: Parameter 'prNow' is never used
> in function winCurrentTime
> >  *** 7 errors in Compile ***
> >  ---
> >  bcc users can report this problem here:
> >  http://www.sqlite.org/cvstrac/tktnew
> >
> >  + tests/bnch_win.bat
> >  - tests/bnchmark
> >* Moved bnch_win.bat to tests.
> >
> > Modified Paths:
> > --
> >trunk/harbour/ChangeLog
> >trunk/harbour/INSTALL
> >trunk/harbour/contrib/hbhpdf/Makefile
> >trunk/harbour/external/Makefile
> >trunk/harbour/external/sqlite3/Makefile
> >
> > Added Paths:
> > ---
> >trunk/harbour/external/libhpdf/
> >trunk/harbour/external/libhpdf/Makefile
> >trunk/harbour/external/libhpdf/README
> >trunk/harbour/external/libhpdf/hpdf.h
> >trunk/harbour/external/libhpdf/hpdf_annotation.c
> >trunk/harbour/external/libhpdf/hpdf_annotation.h
> >trunk/harbour/external/libhpdf/hpdf_array.c
> >trunk/harbour/external/libhpdf/hpdf_binary.c
> >trunk/harbour/external/libhpdf/hpdf_boolean.c
> >trunk/harbour/external/libhpdf/hpdf_catalog.c
> >trunk/harbour/external/libhpdf/hpdf_catalog.h
> >trunk/harbour/external/libhpdf/hpdf_conf.h
> >trunk/harbour/external/libhpdf/hpdf_config.h
> >trunk/harbour/external/libhpdf/hpdf_consts.h
> >trunk/harbour/external/libhpdf/hpdf_destination.c
> >trunk/harbour/external/libhpdf/hpdf_destination.h
> >trunk/harbour/external/libhpdf/hpdf_dict.c
> >trunk/harbour/external/libhpdf/hpdf_doc.c
> >trunk/harbour/external/libhpdf/hpdf_doc.h
> >trunk/harbour/external/libhpdf/hpdf_doc_png.c
> >trunk/harbour/external/libhpdf/hpdf_encoder.c
> >trunk/harbour/external/libhpdf/hpdf_encoder.h
> >trunk/harbour/external/libhpdf/hpdf_encoder_cns.c
> >trunk/harbour/external/libhpdf/hpdf_encoder_cnt.c
> >trunk/harbour/external/libhpdf/hpdf_encoder_jp.c
> >trunk/harbour/external/libhpdf/hpdf_encoder_kr.c
> >trunk/harbour/external/libhpdf/hpdf_encrypt.c
> >trunk/harbour/external/libhpdf/hpdf_encrypt.h
> >trunk/harbour/external/libhpdf/hpdf_encryptdict.c
> >trunk/harbour/external/libhpdf/hpdf_encryptdict.h
> >trunk/harbour/external/libhpdf/hpdf_error.c
> >trunk/harbour/external/libhpdf/hpdf_error.h
> >trunk/harbour/external/libhpdf/hpdf_ext_gstate.c
> >trunk/harbour/external/libhpdf/hpdf_ext_gstate.h
> >trunk/harbour/external/libhpdf/hpdf_font.c
> >trunk/harbour/external/libhpdf/hpdf_font.h
> >trunk/harbour/external/libhpdf/hpdf_font_cid.c
> >trunk/harbour/external/libh

Re: [Harbour] Re: SF.net SVN: harbour-project:[10724]

[Francesco Saverio Giudice]

Hi Viktor,
try my systemwatch executable I sent to you privately.

Best regards,
Francesco

Il 30/03/2009 10.10, Viktor Szakáts ha scritto:
You must be right, if you have code I can try on Windows XP x64 as I have a 
legal copy running in a VM here.


I've found this one:
http://www.codeguru.com/cpp/w-p/system/systeminformation/article.php/c8973__2/
[ but it seem to have forgotten about XP x64 ]

--
Viktor

On Mon, Mar 30, 2009 at 9:59 AM, Francesco Saverio Giudice 
mailto:i...@fsgiudice.com>> wrote:


Viktor,

Il 30/03/2009 9.43, Viktor Szakáts ha scritto:

Both returns 5.2, and I didn't bother to do any above heavy lifting.

Most of these version details is probably unnecessary for
Harbour, but XP x64 and Server 2003 detection would be useful.

Although this code from below:
---
 else if( si.wProcessorArchitecture==PROCESSOR_ARCHITECTURE_IA64 &&
osvi.wProductType == VER_NT_WORKSTATION )
   {
  strcat( szResult, "Microsoft Windows XP Professional
x64 Edition " );
   }
---

looks a bit suspicious to me as it checks for IA64 to detect
x64? Could be correct seeing the mess around Windows version
though ;)


I get code from MS Win SDK plus added unsupported versions (9x, etc).
You can check it at:

ms-help://MS.LHSMSSDK.1033/MS.LHSWinSDK.1033/sysinfo/base/getting_the_system_version.htm

Best regards,
Francesco

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




--
Viktor




___
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] SF.net SVN: harbour-project:[10721] trunk/harbour

[Massimo Belgrano]

done

c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib
hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg
hbmk: Processing: hbhpdf.hbp
Harbour 1.1.0dev (Rev. 10734)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'harupdf.prg'...
Lines 2245, Functions/Procedures 18
Generating C source output to 'harupdf.c'... Done.
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x13
): undefined reference to `png_get_io_ptr'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x8d
): undefined reference to `png_get_error_ptr'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xf0
): undefined reference to `png_get_PLTE'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x26
0): undefined reference to `png_create_read_struct'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x27
4): undefined reference to `png_create_info_struct'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x29
8): undefined reference to `png_set_sig_bytes'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x2b
8): undefined reference to `png_set_read_fn'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x2c
f): undefined reference to `png_read_info'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x2f
d): undefined reference to `png_read_update_info'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x3e
a): undefined reference to `png_destroy_read_struct'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x43
6): undefined reference to `png_get_valid'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x47
1): undefined reference to `png_get_tRNS'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x5f
e): undefined reference to `png_get_rowbytes'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x66
8): undefined reference to `png_set_strip_16'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x7c
f): undefined reference to `png_get_color_type'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x81
b): undefined reference to `png_get_interlace_type'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x83
a): undefined reference to `png_get_rowbytes'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x88
1): undefined reference to `png_read_rows'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x92
5): undefined reference to `png_destroy_read_struct'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x95
3): undefined reference to `png_get_rowbytes'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xa2
7): undefined reference to `png_read_image'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xab
1): undefined reference to `png_get_rowbytes'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xaf
0): undefined reference to `png_read_image'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xd5
2): undefined reference to `png_read_image'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x10
56): undefined reference to `png_sig_cmp'
c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x12
28): undefined reference to `png_sig_cmp'
collect2: ld returned 1 exit status
hbmk: Error: Running C compiler. 1:
gcc.exe harupdf.c C:\Users\MBELGR~1\AppData\Local\Temp\hbmk_p3ene1.c-O3  -oh
arupdf.exe -Ic:/harbour/mingw/include -Lc:/harbour/mingw/lib -mconsole -Wl,--sta
rt-group -lhbcpage -lhblang -lhbcommon -lhbcplr -lhbdebug -lhbvm -lhbrdd -lhbusr
rdd -lhbuddall -lhbhsx -lhbsix -lrddntx -lrddnsx -lrddcdx -lrddfpt -lhbrtl -lhbp
p -lhbmacro -lhbextern -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbpcre
-lhbzlib -lhbhpdf -llibhpdf -lhbct -lhbhpdf -luser32 -lgdi32 -ladvapi32 -lws2_32
 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -lole32 -loleaut32 -luuid -lmpr -lwi
nmm -lmapi32 -limm32 -lmsimg32 -Wl,--end-group


2009/3/30 Viktor Szakáts :
> Hi Massimo, please try again with latest rev.
> --
> Viktor
>
> On Sun, Mar 29, 2009 at 12:43 PM, Massimo Belgrano 
> wrote:
>>
>> I have tried compiling tests
>>
>> c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib
>> hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg
>> hbmk: Processing: hbhpdf.hbp
>> Harbour 1.1.0dev (Rev. 10721)
>> Copyright (c) 1999-2009, http://www.harbour-project.org/
>> Compiling 'harupdf.prg'...
>> Lines 2245, Functions/Procedures 18
>> Generating C source output to 'harupdf.c'... Done.
>> C:\devl\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe:
>

[Harbour] SF.net SVN: harbour-project:[10736] trunk/harbour

[vszakats]

Revision: 10736
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10736&view=rev
Author:   vszakats
Date: 2009-03-30 09:21:52 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 11:21 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * contrib/hbqt/Makefile
- Disabled for owatcom due to compilation error.

  * contrib/hbhpdf/tests/hbhpdf.hbp
+ Added libpng.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbhpdf/tests/hbhpdf.hbp
trunk/harbour/contrib/hbqt/Makefile


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Massimo Belgrano]

c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib hblibpng.lib
hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg
hbmk: Processing: hbhpdf.hbp
Harbour 1.1.0dev (Rev. 10734)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'harupdf.prg'...
Lines 2245, Functions/Procedures 18
Generating C source output to 'harupdf.c'... Done.
C:\devl\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: canno
t find -lhblibpng
collect2: ld returned 1 exit status
hbmk: Error: Running C compiler. 1:
gcc.exe harupdf.c C:\Users\MBELGR~1\AppData\Local\Temp\hbmk_rmoy10.c-O3  -oh
arupdf.exe -Ic:/harbour/mingw/include -Lc:/harbour/mingw/lib -mconsole -Wl,--sta
rt-group -lhbcpage -lhblang -lhbcommon -lhbcplr -lhbdebug -lhbvm -lhbrdd -lhbusr
rdd -lhbuddall -lhbhsx -lhbsix -lrddntx -lrddnsx -lrddcdx -lrddfpt -lhbrtl -lhbp
p -lhbmacro -lhbextern -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbpcre
-lhbzlib -lhbhpdf -llibhpdf -lhbct -lhbhpdf -lhblibpng -luser32 -lgdi32 -ladvapi
32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -lole32 -loleaut32 -luuid
 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -Wl,--end-group

2009/3/30 Viktor Szakáts :
> yes, please add libpng also to the liblist.
> --
>


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

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Viktor Szakáts]

On Mon, Mar 30, 2009 at 11:26 AM, Massimo Belgrano wrote:

> c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib libpng.lib
> hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg
> hbmk: Processing: hbhpdf.hbp
> Harbour 1.1.0dev (Rev. 10734)
> Copyright (c) 1999-2009, http://www.harbour-project.org/
> Compiling 'harupdf.prg'...
> Lines 2245, Functions/Procedures 18
> Generating C source output to 'harupdf.c'... Done.
>
>
> But executing it hargup


I don't know what that means. I've just tried it with MinGW 4.3.3
and myharu.pdf was created without any problems here.

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

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Francesco Saverio Giudice]

Also here with msvc.

Best regards,
Francesco

Il 30/03/2009 12.08, Viktor Szaka'ts ha scritto:


I don't know what that means. I've just tried it with MinGW 4.3.3 
and myharu.pdf was created without any problems here.




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

[Harbour] SF.net SVN: harbour-project:[10737] trunk/harbour

[vszakats]

Revision: 10737
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10737&view=rev
Author:   vszakats
Date: 2009-03-30 10:34:36 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 12:32 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * contrib/hbqt/Makefile
- Disabled for bcc and pocc due to compilation error.
; Maybe it's possible to make them work (at least bcc) by using 
  some special defines, please play with it if you're interested.
  QT seems to like MinGW the best MSVC is also high on the 
  support list, so IMO we should also put the focus there.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/Makefile


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[10738] trunk/harbour

[vszakats]

Revision: 10738
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10738&view=rev
Author:   vszakats
Date: 2009-03-30 11:15:54 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 13:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * INSTALL
* Split Windows compiler list to 'recommended' and 'supported'
  sublists. Recommended are MinGW and MSVC.
  Some comments on the rest:
  - pocc: lack of 3rd party support, mediocre performance.
  - owatcom: lack of 3rd party support, bad performance,
proprietary object/dll format.
  - bcc: lack of 3rd party support, mediocre performance, has known bugs,
proprietary object/dll format.
  - xcc: for testing only.
  - icc: for testing and code validation only.
  - cygwin: for some niche purposes. MinGW is a superior choice.

  * mpkg_win.bat
+ Added support for mingw64 and mingwce.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/INSTALL
trunk/harbour/mpkg_win.bat


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Massimo Belgrano]

seem that is posted the problem
http://www.sqlite.org/cvstrac/tktview?tn=3759,38


2009/3/30 Viktor Szakáts :
> Thanks Chen.
> Now we can choose to create a local patch and create an
> infrastructure for applying local patches before build [ I don't
> have time for this now ], or we can report this to author with
> your solution, hopefully they'll include it in next revision.
> QT also has a patch (regarding localtime) which makes it
> compile for WinCE, BTW.
> Brgds,
> Viktor
>
> On Mon, Mar 30, 2009 at 1:54 PM, Chen Kedem  wrote:
>>
>> > 2009-03-29 11:02 UTC+0200 Viktor Szakats (harbour.01 syenar hu
>> :
>> >  * external/sqlite3/Makefile
>> >    - Disabled for bcc. Latest sqlite3 version breaks with this compiler:
>>
>> BCC does not use LL to mark LONG LONG constants.
>> It needs suffix like i64 (or ui64): 8640LL --> 8640i64
>>
>> These is one section that use it in sqlite3.c (lines 29156-29163). It do
>> complie
>> (don't know if it runs) if I changes all the LL to i64
>>
>>
>>  Chen.
>> ___
>> 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
>
>



-- 
Massimo Belgrano

Analisi e sviluppo software per Lan e Web - Consulenza informatica - Formazione
Delta Informatica S.r.l. http://www.deltain.it/   +39 0321 455962
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[10735] trunk/harbour

[vszakats]

Revision: 10735
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10735&view=rev
Author:   vszakats
Date: 2009-03-30 09:12:57 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 11:12 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * external/libhpdf/Makefile
- Disabled for owatcom due to compilation error.
  If someone is interested in patching it for this compiler,
  please do.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/external/libhpdf/Makefile


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Massimo Belgrano]

I have deleted old/incomplete myharu.pdf and not all works

Thanks!
2009/3/30 Francesco Saverio Giudice :
> Also here with msvc.
>
> Best regards,
> Francesco
>
> Il 30/03/2009 12.08, Viktor Szaka'ts ha scritto:
>>
>> I don't know what that means. I've just tried it with MinGW 4.3.3 and
>> myharu.pdf was created without any problems here.
>>
>
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



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

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Przemyslaw Czerpak]

On Mon, 30 Mar 2009, Chen Kedem wrote:
> > 2009-03-29 11:02 UTC+0200 Viktor Szakats (harbour.01 syenar hu
> >  * external/sqlite3/Makefile
> >- Disabled for bcc. Latest sqlite3 version breaks with this compiler:
> BCC does not use LL to mark LONG LONG constants.
> It needs suffix like i64 (or ui64): 8640LL --> 8640i64
> These is one section that use it in sqlite3.c (lines 29156-29163). It do 
> complie
> (don't know if it runs) if I changes all the LL to i64

In Harbour we have macro HB_LL() which should be used for such numbers.
Most of Windows compilers does not support well LL sufix. In the past some
of them were not even generating errors but stirpped upper 32 bits from
then number. Unfortunately i64/ui64 suffix is not portable solution so
cannot be used instead LL.
I suggest to always use HB_LL(), f.e.:
   HB_LL( 8640 )

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

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Viktor Szakáts]

you've added hblibpng, not libpng.
--
Viktor

On Mon, Mar 30, 2009 at 11:18 AM, Massimo Belgrano wrote:

> c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib hblibpng.lib
> hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg
> hbmk: Processing: hbhpdf.hbp
> Harbour 1.1.0dev (Rev. 10734)
> Copyright (c) 1999-2009, http://www.harbour-project.org/
> Compiling 'harupdf.prg'...
> Lines 2245, Functions/Procedures 18
> Generating C source output to 'harupdf.c'... Done.
> C:\devl\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe:
> canno
> t find -lhblibpng
> collect2: ld returned 1 exit status
> hbmk: Error: Running C compiler. 1:
> gcc.exe harupdf.c C:\Users\MBELGR~1\AppData\Local\Temp\hbmk_rmoy10.c-O3
>  -oh
> arupdf.exe -Ic:/harbour/mingw/include -Lc:/harbour/mingw/lib -mconsole
> -Wl,--sta
> rt-group -lhbcpage -lhblang -lhbcommon -lhbcplr -lhbdebug -lhbvm -lhbrdd
> -lhbusr
> rdd -lhbuddall -lhbhsx -lhbsix -lrddntx -lrddnsx -lrddcdx -lrddfpt -lhbrtl
> -lhbp
> p -lhbmacro -lhbextern -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui
> -lhbpcre
> -lhbzlib -lhbhpdf -llibhpdf -lhbct -lhbhpdf -lhblibpng -luser32 -lgdi32
> -ladvapi
> 32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -lole32 -loleaut32
> -luuid
>  -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -Wl,--end-group
>
> 2009/3/30 Viktor Szakáts :
> > yes, please add libpng also to the liblist.
> > --
> >
>
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Chen Kedem]

> 2009-03-29 11:02 UTC+0200 Viktor Szakats (harbour.01 syenar hu
:
>  * external/sqlite3/Makefile
>- Disabled for bcc. Latest sqlite3 version breaks with this compiler:

BCC does not use LL to mark LONG LONG constants.
It needs suffix like i64 (or ui64): 8640LL --> 8640i64

These is one section that use it in sqlite3.c (lines 29156-29163). It do complie
(don't know if it runs) if I changes all the LL to i64


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

Re: [Harbour] SF.net SVN: harbour-project:[10738] trunk/harbour

[Przemyslaw Czerpak]

On Mon, 30 Mar 2009, vszak...@users.sourceforge.net wrote:
> Revision: 10738
>   
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10738&view=rev
> Author:   vszakats
> Date: 2009-03-30 11:15:54 + (Mon, 30 Mar 2009)
> Log Message:
> ---
> 2009-03-30 13:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
>   * INSTALL
> * Split Windows compiler list to 'recommended' and 'supported'
>   sublists. Recommended are MinGW and MSVC.
>   Some comments on the rest:
>   - pocc: lack of 3rd party support, mediocre performance.
>   - owatcom: lack of 3rd party support, bad performance,
> proprietary object/dll format.

You killed the performance by setting -bm flag as default.
When -bm is used OpenWatcom uses some different memory allocator
which is extremely slow. The next switch which probably reduce the
performance is -5s but I haven't made any real tests here and I only
guess that stack calling convention is slower then register one.
Anyhow here the difference will be probably minor.
Without this switches OpenWatcom gives the fastest code in few places.
F.e. even ICC is not close to OpenWatcom results in T029 and T030.
The overall performance is also quite good. In my tests it was noticable
better then BCC or POCC.

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

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Viktor Szakáts]

yes, please add libpng also to the liblist.
--
Viktor

On Mon, Mar 30, 2009 at 11:09 AM, Massimo Belgrano wrote:

> done
>
> c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib
> hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg
> hbmk: Processing: hbhpdf.hbp
> Harbour 1.1.0dev (Rev. 10734)
> Copyright (c) 1999-2009, http://www.harbour-project.org/
> Compiling 'harupdf.prg'...
> Lines 2245, Functions/Procedures 18
> Generating C source output to 'harupdf.c'... Done.
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x13
> ): undefined reference to `png_get_io_ptr'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x8d
> ): undefined reference to `png_get_error_ptr'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xf0
> ): undefined reference to `png_get_PLTE'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x26
> 0): undefined reference to `png_create_read_struct'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x27
> 4): undefined reference to `png_create_info_struct'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x29
> 8): undefined reference to `png_set_sig_bytes'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x2b
> 8): undefined reference to `png_set_read_fn'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x2c
> f): undefined reference to `png_read_info'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x2f
> d): undefined reference to `png_read_update_info'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x3e
> a): undefined reference to `png_destroy_read_struct'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x43
> 6): undefined reference to `png_get_valid'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x47
> 1): undefined reference to `png_get_tRNS'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x5f
> e): undefined reference to `png_get_rowbytes'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x66
> 8): undefined reference to `png_set_strip_16'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x7c
> f): undefined reference to `png_get_color_type'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x81
> b): undefined reference to `png_get_interlace_type'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x83
> a): undefined reference to `png_get_rowbytes'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x88
> 1): undefined reference to `png_read_rows'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x92
> 5): undefined reference to `png_destroy_read_struct'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x95
> 3): undefined reference to `png_get_rowbytes'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xa2
> 7): undefined reference to `png_read_image'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xab
> 1): undefined reference to `png_get_rowbytes'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xaf
> 0): undefined reference to `png_read_image'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0xd5
> 2): undefined reference to `png_read_image'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x10
> 56): undefined reference to `png_sig_cmp'
>
> c:/harbour/mingw/lib/liblibhpdf.a(hpdf_image_png.o):hpdf_image_png.c:(.text+0x12
> 28): undefined reference to `png_sig_cmp'
> collect2: ld returned 1 exit status
> hbmk: Error: Running C compiler. 1:
> gcc.exe harupdf.c C:\Users\MBELGR~1\AppData\Local\Temp\hbmk_p3ene1.c-O3
>  -oh
> arupdf.exe -Ic:/harbour/mingw/include -Lc:/harbour/mingw/lib -mconsole
> -Wl,--sta
> rt-group -lhbcpage -lhblang -lhbcommon -lhbcplr -lhbdebug -lhbvm -lhbrdd
> -lhbusr
> rdd -lhbuddall -lhbhsx -lhbsix -lrddntx -lrddnsx -lrddcdx -lrddfpt -lhbrtl
> -lhbp
> p -lhbmacro -lhbextern -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui
> -lhbpcre
> -lhbzlib -lhbhpdf -llibhpdf -lhbct -lhbhpdf -luser32 -lgdi32 -ladvapi32
> -lws2_32
>  -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -lole32 -loleaut32 -luuid -lmpr
> -lwi
> nmm -lmapi32 -limm32 -lmsimg32 -Wl,--end-group
>
>
> 2009/3/30 Viktor Szakáts :
> > Hi Massimo, please try again with latest rev.
> > --
> > Viktor
> >
> > On Sun, Mar 29, 2009 at 12:43 PM, Massimo Belgrano  >
> > wrote:
> >>
> >> I have tried compiling tests
> >>
> >> c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib
> >> hbmk: Processing configuration: c:\har

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Massimo Belgrano]

c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib libpng.lib
hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg
hbmk: Processing: hbhpdf.hbp
Harbour 1.1.0dev (Rev. 10734)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'harupdf.prg'...
Lines 2245, Functions/Procedures 18
Generating C source output to 'harupdf.c'... Done.


But executing it hargup

c:\harbour\contrib\hbhpdf\tests>harupdf



2009/3/30 Viktor Szakáts :
> you've added hblibpng, not libpng.
> --
> Viktor
>
> On Mon, Mar 30, 2009 at 11:18 AM, Massimo Belgrano 
> wrote:
>>
>> c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib hblibpng.lib
>> hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg
>> hbmk: Processing: hbhpdf.hbp
>> Harbour 1.1.0dev (Rev. 10734)
>> Copyright (c) 1999-2009, http://www.harbour-project.org/
>> Compiling 'harupdf.prg'...
>> Lines 2245, Functions/Procedures 18
>> Generating C source output to 'harupdf.c'... Done.
>> C:\devl\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe:
>> canno
>> t find -lhblibpng
>> collect2: ld returned 1 exit status
>> hbmk: Error: Running C compiler. 1:
>> gcc.exe harupdf.c C:\Users\MBELGR~1\AppData\Local\Temp\hbmk_rmoy10.c
>>  -O3  -oh
>> arupdf.exe -Ic:/harbour/mingw/include -Lc:/harbour/mingw/lib -mconsole
>> -Wl,--sta
>> rt-group -lhbcpage -lhblang -lhbcommon -lhbcplr -lhbdebug -lhbvm -lhbrdd
>> -lhbusr
>> rdd -lhbuddall -lhbhsx -lhbsix -lrddntx -lrddnsx -lrddcdx -lrddfpt -lhbrtl
>> -lhbp
>> p -lhbmacro -lhbextern -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui
>> -lhbpcre
>> -lhbzlib -lhbhpdf -llibhpdf -lhbct -lhbhpdf -lhblibpng -luser32 -lgdi32
>> -ladvapi
>> 32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -lole32 -loleaut32
>> -luuid
>>  -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -Wl,--end-group
>>
>> 2009/3/30 Viktor Szakáts :
>> > yes, please add libpng also to the liblist.
>> > --
>> >
>
>
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
>



-- 
Massimo Belgrano

Analisi e sviluppo software per Lan e Web - Consulenza informatica - Formazione
Delta Informatica S.r.l. http://www.deltain.it/   +39 0321 455962
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

RE: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Chen Kedem]

Massimo,

> seem that is posted the problem
> http://www.sqlite.org/cvstrac/tktview?tn=3759,38

Ok, added my remark there too (anonymos have page edit privilege, oh, well)

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

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Viktor Szakáts]

Thanks Chen.
Now we can choose to create a local patch and create an
infrastructure for applying local patches before build [ I don't
have time for this now ], or we can report this to author with
your solution, hopefully they'll include it in next revision.

QT also has a patch (regarding localtime) which makes it
compile for WinCE, BTW.

Brgds,
Viktor

On Mon, Mar 30, 2009 at 1:54 PM, Chen Kedem  wrote:

> > 2009-03-29 11:02 UTC+0200 Viktor Szakats (harbour.01 syenar hu
> :
> >  * external/sqlite3/Makefile
> >- Disabled for bcc. Latest sqlite3 version breaks with this compiler:
>
> BCC does not use LL to mark LONG LONG constants.
> It needs suffix like i64 (or ui64): 8640LL --> 8640i64
>
> These is one section that use it in sqlite3.c (lines 29156-29163). It do
> complie
> (don't know if it runs) if I changes all the LL to i64
>
>
>  Chen.
> ___
> 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] SF.net SVN: harbour-project:[10739] trunk/harbour

[vszakats]

Revision: 10739
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10739&view=rev
Author:   vszakats
Date: 2009-03-30 11:53:23 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 13:53 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * contrib/gtalleg/Makefile
- Disabled for minwgce.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/gtalleg/Makefile


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[10738] trunk/harbour

[Viktor Szakáts]

Hi Przemek,


> > 2009-03-30 13:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
> >   * INSTALL
> > * Split Windows compiler list to 'recommended' and 'supported'
> >   sublists. Recommended are MinGW and MSVC.
> >   Some comments on the rest:
> >   - pocc: lack of 3rd party support, mediocre performance.
> >   - owatcom: lack of 3rd party support, bad performance,
> > proprietary object/dll format.
>
> You killed the performance by setting -bm flag as default.
> When -bm is used OpenWatcom uses some different memory allocator
> which is extremely slow. The next switch which probably reduce the


I didn't want to kill it, just wanted to tweak it for MT.. we're using such
MT switch for most compilers to force MT friendly runtine/code generation/
whatever. Isn't this needed for owatcom?

---
-bm build target is a multi-thread environment
---
---
bm  (Netware, OS/2, Windows NT only) This option causes the
compiler to imbed the appropriate multi-thread library name in the object
file. The macro __SW_BM is predefined if bm is selected.
---


> performance is -5s but I haven't made any real tests here and I only
> guess that stack calling convention is slower then register one.


It's definitely slower, but needed for compatible .dll generation
as far as I understood Andi's mail. Didn't spend time to do
side-by-side comparison though.


> Anyhow here the difference will be probably minor.
> Without this switches OpenWatcom gives the fastest code in few places.
> F.e. even ICC is not close to OpenWatcom results in T029 and T030.
> The overall performance is also quite good. In my tests it was noticable
> better then BCC or POCC.


Great, so if you say -bm isn't needed for MT support I can remove it.
Shall I go for it?

Unfortunately owatcom has the same problem as bcc/pocc: lack
of support, so some libs had to be disabled due to compile errors
(libhpdf, hbqt), but I otherwise I have no problem keeping it in first line.

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

[Harbour] telepahty, output overflow

[AbeB]

Hi All,


I'm printing to serial printer with  hbtpathy.lib

f.e.
tp_send(1, 
replic("012345678901234567890012345678901234567890"+chr(13)+chr(10),1000 ) )
but it whould cause overflow in the printed output.

any help?

Thanks,
Abe
-- 
View this message in context: 
http://n2.nabble.com/telepahty%2C-output-overflow-tp2557549p2557549.html
Sent from the harbour-devel mailing list archive at Nabble.com.

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

[Harbour] Unified Harbour 1.1.0dev (beta) release

[Viktor Szakáts]

Hi All,
I've made available a unified and self-contained Windows release
package, which is able to create x86, x64, WinCE/ARM executables
(both shared and static) out of the box without the need of any
external tools or settings.

Download:
http://www.syenar.hu/harbour/hb-1.1.0dev.7z
(size: 136MB)

To use:
1) unpack to any directory (C:\hb-1.1.0dev)
2) go to bin dir (optional if you specify path for hbmk2)
3) For x86 executable type: 'hbmk2 ../tests/hello.prg'
4) For x64 executable type: 'hbmk2 ../tests/hello.prg -comp=mingw64'
5) For WinCE/ARM executable type: 'hbmk2 ../tests/hello.prg -comp=mingwce'

The package also contains Harbour libraries to build MSVC 2008,
Open Watcom 1.8 and Borland C 5.5.1 executables. For these,
you need to have these compilers installed on your computer. The libs
will automatically be picked by hbmk2.

The package contains MinGW 4.3.3, MinGW 4.4.0 for x64 and
MinGW 4.1.0 for ARM/CE embedded.

I've used 7-Zip instead of .zip, because it cut the archive size by
a factor of 2-3. If this package will get good reception I may add
installer with de-selectable x64, WinCE and additional target libs.
While it takes significant amount of time to assemble such package,
nevertheless IMO it should be the definitive and official release
methods instead of the separate compiler/CPU target specific
packages we offer for 1.0.1.

Following external dependencies were used to build corresponding
Harbour libs:

ace 9.10
allegro 4.2.2
blat 2.6.2
libcurl 7.19.3
firebird 2.1.1
freeimage 3.11.0
gd 2.0.34
mysql 5.0.67
openssl 0.9.8j
pgsql 8.3.3
qt 4.5.0 (2009.01)

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

Re: [Harbour] telepahty, output overflow

[Alex Strickland]

AbeB wrote:


I'm printing to serial printer with  hbtpathy.lib

f.e.
tp_send(1, 
replic("012345678901234567890012345678901234567890"+chr(13)+chr(10),1000 ) )
but it whould cause overflow in the printed output.

any help?


Not specific to telepathy, but you must enable flow control on the printer and 
in your software. Most common are DTR/DTS (hardware) or XOn/XOff (software).


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

Re: [Harbour] Harbour Distribution - Ready-to-Use

[Pritpal Bedi]

Hi


Massimo Belgrano-3 wrote:
> 
> I have same Italian user that want route to the ready to use distribution
> Is this last version?
> are planed near update?
> 
> Have you made same progress regarding your old project of documentation?
> 

At the moment I am concentrating on QT implementation.
But of couse I cn upload new distro, wait a couple of days more.

Documentation - you are talking about GTWVG ? - well I plan to 
write it after GTQTC and GTQTG are in place.

Regards
Pritpal Bedi
-- 
View this message in context: 
http://www.nabble.com/Harbour-Distribution---Ready-to-Use-tp22326050p22784874.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] telepahty, output overflow

[AbeB]

Hi Alex,
Thanks for quick reply.

In the printer it's enabled, but in software i have no clue how.

Any guidance?

Thanks,
abe



AbeB wrote:

> I'm printing to serial printer with  hbtpathy.lib
> 
> f.e.
> tp_send(1, 
> replic("012345678901234567890012345678901234567890"+chr(13)+chr(10),1000 ) )
> but it whould cause overflow in the printed output.
> 
> any help?

Not specific to telepathy, but you must enable flow control on the printer and 
in your software. Most common are DTR/DTS (hardware) or XOn/XOff (software).

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



-- 
View this message in context: 
http://n2.nabble.com/telepahty%2C-output-overflow-tp2557549p2557628.html
Sent from the harbour-devel mailing list archive at Nabble.com.

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

[Harbour] msvc64 regression / hbatomic.h

[Viktor Szakáts]

cl.exe -nologo -I. -I../../../../include -Gs -TP -W4 -wd4127 -Ot2b1 -EHs-c-
-MT-DHB_FM_STATISTICS_OFF -DHB_DYNLIB -c ../../thread.c -Fothread.obj
thread.c
../../../../include\hbatomic.h(270) : error C4235: nonstandard extension
used : '__asm' keyword not supported on this architecture
../../../../include\hbatomic.h(270) : error C2065: 'mov' : undeclared
identifier
../../../../include\hbatomic.h(270) : error C2146: syntax error : missing
';' before identifier 'eax'
../../../../include\hbatomic.h(270) : error C2065: 'eax' : undeclared
identifier
../../../../include\hbatomic.h(271) : error C4235: nonstandard extension
used : '__asm' keyword not supported on this architecture
../../../../include\hbatomic.h(271) : error C2146: syntax error : missing
';' before identifier 'lock'
../../../../include\hbatomic.h(271) : error C2065: 'lock' : undeclared
identifier
../../../../include\hbatomic.h(271) : error C2146: syntax error : missing
';' before identifier 'inc'
../../../../include\hbatomic.h(271) : error C2065: 'inc' : undeclared
identifier
../../../../include\hbatomic.h(271) : error C2146: syntax error : missing
';' before identifier 'dword'
../../../../include\hbatomic.h(271) : error C2065: 'dword' : undeclared
identifier
../../../../include\hbatomic.h(271) : error C2146: syntax error : missing
';' before identifier 'ptr'
../../../../include\hbatomic.h(271) : error C2065: 'ptr' : undeclared
identifier
../../../../include\hbatomic.h(271) : error C2065: 'eax' : undeclared
identifier
../../../../include\hbatomic.h(272) : error C2143: syntax error : missing
';' before '}'
../../../../include\hbatomic.h(278) : error C4235: nonstandard extension
used : '__asm' keyword not supported on this architecture
../../../../include\hbatomic.h(278) : error C2065: 'mov' : undeclared
identifier
../../../../include\hbatomic.h(278) : error C2146: syntax error : missing
';' before identifier 'eax'
../../../../include\hbatomic.h(278) : error C2065: 'eax' : undeclared
identifier
../../../../include\hbatomic.h(279) : error C4235: nonstandard extension
used : '__asm' keyword not supported on this architecture
../../../../include\hbatomic.h(279) : error C2146: syntax error : missing
';' before identifier 'lock'
../../../../include\hbatomic.h(279) : error C2065: 'lock' : undeclared
identifier
../../../../include\hbatomic.h(279) : error C2146: syntax error : missing
';' before identifier 'dec'
../../../../include\hbatomic.h(279) : error C2065: 'dec' : undeclared
identifier
../../../../include\hbatomic.h(279) : error C2146: syntax error : missing
';' before identifier 'dword'
../../../../include\hbatomic.h(279) : error C2065: 'dword' : undeclared
identifier
../../../../include\hbatomic.h(279) : error C2146: syntax error : missing
';' before identifier 'ptr'
../../../../include\hbatomic.h(279) : error C2065: 'ptr' : undeclared
identifier
../../../../include\hbatomic.h(279) : error C2065: 'eax' : undeclared
identifier
../../../../include\hbatomic.h(280) : error C4235: nonstandard extension
used : '__asm' keyword not supported on this architecture
../../../../include\hbatomic.h(280) : error C2146: syntax error : missing
';' before identifier 'setne'
../../../../include\hbatomic.h(282) : error C2065: 'setne' : undeclared
identifier
../../../../include\hbatomic.h(282) : error C2146: syntax error : missing
';' before identifier 'c'
../../../../include\hbatomic.h(282) : error C2143: syntax error : missing
';' before 'return'

It also happens in plain C mode.

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

[Harbour] Re: msvc64 regression / hbatomic.h

[Viktor Szakáts]

Also pocc64:
pocc.exe -I. -Ze -Go -MT -W1 -Ot -I../../../../include /Tamd64-coff
 -DHB_FM_STATISTICS_OFF  -c ../../thread.c -Fothread.obj
harbour\include\hbatomic.h(270): error #2206: No inline assembly support for
this target.

Brgds,
Viktor

On Mon, Mar 30, 2009 at 4:59 PM, Viktor Szakáts wrote:

> cl.exe -nologo -I. -I../../../../include -Gs -TP -W4 -wd4127 -Ot2b1 -EHs-c-
> -MT-DHB_FM_STATISTICS_OFF -DHB_DYNLIB -c ../../thread.c -Fothread.obj
> thread.c
> ../../../../include\hbatomic.h(270) : error C4235: nonstandard extension
> used : '__asm' keyword not supported on this architecture
> ../../../../include\hbatomic.h(270) : error C2065: 'mov' : undeclared
> identifier
> ../../../../include\hbatomic.h(270) : error C2146: syntax error : missing
> ';' before identifier 'eax'
> ../../../../include\hbatomic.h(270) : error C2065: 'eax' : undeclared
> identifier
> ../../../../include\hbatomic.h(271) : error C4235: nonstandard extension
> used : '__asm' keyword not supported on this architecture
> ../../../../include\hbatomic.h(271) : error C2146: syntax error : missing
> ';' before identifier 'lock'
> ../../../../include\hbatomic.h(271) : error C2065: 'lock' : undeclared
> identifier
> ../../../../include\hbatomic.h(271) : error C2146: syntax error : missing
> ';' before identifier 'inc'
> ../../../../include\hbatomic.h(271) : error C2065: 'inc' : undeclared
> identifier
> ../../../../include\hbatomic.h(271) : error C2146: syntax error : missing
> ';' before identifier 'dword'
> ../../../../include\hbatomic.h(271) : error C2065: 'dword' : undeclared
> identifier
> ../../../../include\hbatomic.h(271) : error C2146: syntax error : missing
> ';' before identifier 'ptr'
> ../../../../include\hbatomic.h(271) : error C2065: 'ptr' : undeclared
> identifier
> ../../../../include\hbatomic.h(271) : error C2065: 'eax' : undeclared
> identifier
> ../../../../include\hbatomic.h(272) : error C2143: syntax error : missing
> ';' before '}'
> ../../../../include\hbatomic.h(278) : error C4235: nonstandard extension
> used : '__asm' keyword not supported on this architecture
> ../../../../include\hbatomic.h(278) : error C2065: 'mov' : undeclared
> identifier
> ../../../../include\hbatomic.h(278) : error C2146: syntax error : missing
> ';' before identifier 'eax'
> ../../../../include\hbatomic.h(278) : error C2065: 'eax' : undeclared
> identifier
> ../../../../include\hbatomic.h(279) : error C4235: nonstandard extension
> used : '__asm' keyword not supported on this architecture
> ../../../../include\hbatomic.h(279) : error C2146: syntax error : missing
> ';' before identifier 'lock'
> ../../../../include\hbatomic.h(279) : error C2065: 'lock' : undeclared
> identifier
> ../../../../include\hbatomic.h(279) : error C2146: syntax error : missing
> ';' before identifier 'dec'
> ../../../../include\hbatomic.h(279) : error C2065: 'dec' : undeclared
> identifier
> ../../../../include\hbatomic.h(279) : error C2146: syntax error : missing
> ';' before identifier 'dword'
> ../../../../include\hbatomic.h(279) : error C2065: 'dword' : undeclared
> identifier
> ../../../../include\hbatomic.h(279) : error C2146: syntax error : missing
> ';' before identifier 'ptr'
> ../../../../include\hbatomic.h(279) : error C2065: 'ptr' : undeclared
> identifier
> ../../../../include\hbatomic.h(279) : error C2065: 'eax' : undeclared
> identifier
> ../../../../include\hbatomic.h(280) : error C4235: nonstandard extension
> used : '__asm' keyword not supported on this architecture
> ../../../../include\hbatomic.h(280) : error C2146: syntax error : missing
> ';' before identifier 'setne'
> ../../../../include\hbatomic.h(282) : error C2065: 'setne' : undeclared
> identifier
> ../../../../include\hbatomic.h(282) : error C2146: syntax error : missing
> ';' before identifier 'c'
> ../../../../include\hbatomic.h(282) : error C2143: syntax error : missing
> ';' before 'return'
>
> It also happens in plain C mode.
>
> Brgds,
> Viktor
>
>
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Harbour Distribution - Ready-to-Use

[Massimo Belgrano]

I agree with qt prioriry
XBase++ Parts by gtwvg have XBPStatics (not present in demoxbp) ?
Do you still plan support gtwvg ?
What are  GTQTC and GTQTG ?

2009/3/30 Pritpal Bedi :
>
> Hi
>
>
> Massimo Belgrano-3 wrote:
>>
>> I have same Italian user that want route to the ready to use distribution
>> Is this last version?
>> are planed near update?
>>
>> Have you made same progress regarding your old project of documentation?
>>
>
> At the moment I am concentrating on QT implementation.
> But of couse I cn upload new distro, wait a couple of days more.
>
> Documentation - you are talking about GTWVG ? - well I plan to
> write it after GTQTC and GTQTG are in place.
>
> Regards
> Pritpal Bedi
> --
> View this message in context: 
> http://www.nabble.com/Harbour-Distribution---Ready-to-Use-tp22326050p22784874.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
>



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

RE: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Chen Kedem]

I wrote:
>> seem that is posted the problem
>> http://www.sqlite.org/cvstrac/tktview?tn=3759,38

> Ok, added my remark there too (anonymos have page edit privilege, oh, well)

Looking at that link, it seems that it was just fixed.
http://www.sqlite.org/cvstrac/chngview?cn=6408

You just got to love open source :)


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

Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour

[Viktor Szakáts]

:) Great indeed.
--
Viktor

On Mon, Mar 30, 2009 at 6:01 PM, Chen Kedem  wrote:

> I wrote:
> >> seem that is posted the problem
> >> http://www.sqlite.org/cvstrac/tktview?tn=3759,38
>
> > Ok, added my remark there too (anonymos have page edit privilege, oh,
> well)
>
> Looking at that link, it seems that it was just fixed.
> http://www.sqlite.org/cvstrac/chngview?cn=6408
>
> You just got to love open source :)
>
>
> Niki.
> ___
> 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] SF.net SVN: harbour-project:[10740] trunk/harbour

[vszakats]

Revision: 10740
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10740&view=rev
Author:   vszakats
Date: 2009-03-30 16:31:50 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 17:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * contrib/hbfbird/Makefile
  * contrib/gtalleg/Makefile
- Disabled for poccce due to errors.

  * contrib/hbfimage/fi_winfu.c
- Disabled Windows specific functions for poccce due to errors.

  * config/win/owatcom.cf
% Removed -bm (MT mode) switch, because besides creating MT friendly
  code, it kills performance. Pls shout if MT mode is now broken in
  any ways.

  * mpkg_win.bat
* Generate .zip file first.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/win/owatcom.cf
trunk/harbour/contrib/gtalleg/Makefile
trunk/harbour/contrib/hbfbird/Makefile
trunk/harbour/contrib/hbfimage/fi_winfu.c
trunk/harbour/mpkg_win.bat


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Unified Harbour 1.1.0dev (beta) release

[Massimo Belgrano]

Still Compliment Victor
Great result for made x86,x64 ,WinCE/ARM with mingw/harbour
What step can i do fo make same result with my svn?
If you describe how  compile, also other distribution Gan give this benefit


2009/3/30 Viktor Szakáts :
> Hi All,
> I've made available a unified and self-contained Windows release
> package, which is able to create x86, x64, WinCE/ARM executables
> (both shared and static) out of the box without the need of any
> external tools or settings.
> Download:
> http://www.syenar.hu/harbour/hb-1.1.0dev.7z
> (size: 136MB)
> To use:
> 1) unpack to any directory (C:\hb-1.1.0dev)
> 2) go to bin dir (optional if you specify path for hbmk2)
> 3) For x86 executable type: 'hbmk2 ../tests/hello.prg'
> 4) For x64 executable type: 'hbmk2 ../tests/hello.prg -comp=mingw64'
> 5) For WinCE/ARM executable type: 'hbmk2 ../tests/hello.prg -comp=mingwce'
> The package also contains Harbour libraries to build MSVC 2008,
> Open Watcom 1.8 and Borland C 5.5.1 executables. For these,
> you need to have these compilers installed on your computer. The libs
> will automatically be picked by hbmk2.
> The package contains MinGW 4.3.3, MinGW 4.4.0 for x64 and
> MinGW 4.1.0 for ARM/CE embedded.
> I've used 7-Zip instead of .zip, because it cut the archive size by
> a factor of 2-3. If this package will get good reception I may add
> installer with de-selectable x64, WinCE and additional target libs.
> While it takes significant amount of time to assemble such package,
> nevertheless IMO it should be the definitive and official release
> methods instead of the separate compiler/CPU target specific
> packages we offer for 1.0.1.
> Following external dependencies were used to build corresponding
> Harbour libs:
> ace 9.10
> allegro 4.2.2
> blat 2.6.2
> libcurl 7.19.3
> firebird 2.1.1
> freeimage 3.11.0
> gd 2.0.34
> mysql 5.0.67
> openssl 0.9.8j
> pgsql 8.3.3
> qt 4.5.0 (2009.01)
> Brgds,
> Viktor
>
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
>



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

Re: [Harbour] Unified Harbour 1.1.0dev (beta) release

[Viktor Szakáts]

Well, I've posted MinGW CE sample script already on the list, the 64-bit
version is almost like it with some changes (easy to copy from other
cross-builds). Besides the above,
all files were created using usual and documented mpkg_win.bat
scripts and files copied together as a final stage. Anyhow this
time my goal isn't to go into great detail to teach how to do
this, even more so since current method cannot be considered
final. I'd rather be interested in this package's usefulness and
whether it's working and making things simpler for other
developers.

Brgds,
Viktor

On Mon, Mar 30, 2009 at 6:31 PM, Massimo Belgrano wrote:

> Still Compliment Victor
> Great result for made x86,x64 ,WinCE/ARM with mingw/harbour
> What step can i do fo make same result with my svn?
> If you describe how  compile, also other distribution Gan give this benefit
>
>
> 2009/3/30 Viktor Szakáts :
> > Hi All,
> > I've made available a unified and self-contained Windows release
> > package, which is able to create x86, x64, WinCE/ARM executables
> > (both shared and static) out of the box without the need of any
> > external tools or settings.
> > Download:
> > http://www.syenar.hu/harbour/hb-1.1.0dev.7z
> > (size: 136MB)
> > To use:
> > 1) unpack to any directory (C:\hb-1.1.0dev)
> > 2) go to bin dir (optional if you specify path for hbmk2)
> > 3) For x86 executable type: 'hbmk2 ../tests/hello.prg'
> > 4) For x64 executable type: 'hbmk2 ../tests/hello.prg -comp=mingw64'
> > 5) For WinCE/ARM executable type: 'hbmk2
> ../tests/hello.prg -comp=mingwce'
> > The package also contains Harbour libraries to build MSVC 2008,
> > Open Watcom 1.8 and Borland C 5.5.1 executables. For these,
> > you need to have these compilers installed on your computer. The libs
> > will automatically be picked by hbmk2.
> > The package contains MinGW 4.3.3, MinGW 4.4.0 for x64 and
> > MinGW 4.1.0 for ARM/CE embedded.
> > I've used 7-Zip instead of .zip, because it cut the archive size by
> > a factor of 2-3. If this package will get good reception I may add
> > installer with de-selectable x64, WinCE and additional target libs.
> > While it takes significant amount of time to assemble such package,
> > nevertheless IMO it should be the definitive and official release
> > methods instead of the separate compiler/CPU target specific
> > packages we offer for 1.0.1.
> > Following external dependencies were used to build corresponding
> > Harbour libs:
> > ace 9.10
> > allegro 4.2.2
> > blat 2.6.2
> > libcurl 7.19.3
> > firebird 2.1.1
> > freeimage 3.11.0
> > gd 2.0.34
> > mysql 5.0.67
> > openssl 0.9.8j
> > pgsql 8.3.3
> > qt 4.5.0 (2009.01)
> > Brgds,
> > Viktor
> >
> > ___
> > Harbour mailing list
> > Harbour@harbour-project.org
> > http://lists.harbour-project.org/mailman/listinfo/harbour
> >
> >
>
>
>
> --
> Massimo Belgrano
> ___
> 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] SF.net SVN: harbour-project:[10738] trunk/harbour

[Przemyslaw Czerpak]

On Mon, 30 Mar 2009, Szak�ts Viktor wrote:

Hi,

> I didn't want to kill it, just wanted to tweak it for MT.. we're using such
> MT switch for most compilers to force MT friendly runtine/code generation/
> whatever. Isn't this needed for owatcom?

We were discussing about it when OW OS2 port was added.
If you want to set this flag as default then you have to
also enable DL malloc as default memory manager. It will
reduce a little bit the performance in single thread application
but MT once will be usable. The problem is with OS2 builds because
dlmalloc does not support this OS.
So far I haven't found time to check in OpenWatcom source code why the
memory manager used of MT mode is such slow.

> ---
> -bm build target is a multi-thread environment
> ---
> bm  (Netware, OS/2, Windows NT only) This option causes the
> compiler to imbed the appropriate multi-thread library name in the object
> file. The macro __SW_BM is predefined if bm is selected.
> ---

I know what it does. And for sure it's good to use it if necessary.
But it will be also good if you will test the results of switching
you are enabling. I know that it's time consuming but in some cases
we also lost information about already tested and updated settings.
Probably now when we do not use CRTL *printf() functions familly
then we do not use any other functions which needs separate MT/ST
versions (except memory allocator) so it should be enough to compile
only hbvm with this switch. Anyhow it's not good practice because
we do not know what exactly this switch does. We should ask on Open
Watcom devel list or look in the source code for details.

> > performance is -5s but I haven't made any real tests here and I only
> > guess that stack calling convention is slower then register one.
> It's definitely slower, but needed for compatible .dll generation
> as far as I understood Andi's mail. Didn't spend time to do
> side-by-side comparison though.

It's only necessary if you want to use OpenWatcom harbour.dll with
other Harbour builds. It's not necessary if you want to use OpenWatcom
harbour.dll with OpenWatcom Harbour builds.
Anyhow if for some reasons you want to make harbour.dll with OpenWatcom
and use it later with other compilers then it's enough to change only
attributes of exported functions and it's not necessary to manipulate
with calling convention of the whole build. Just like you do not have
to change it for static builds. Such option can be set only for DLLs.
Personally I'd prefer to use native for compiler settings.
If I want to make something different then I can use HB_USER_CFLAGS.
Anyhow in this particular case the calling convention options should
be changed extremely carefully. In OS2 builds they were badly interact
when some OS2 16bit API functions were called and we were fighting for
quite long time with GPF in MT mode. Finally Maurilio set it to value
which were playing well OS2 16bit API but in fact we haven't checked
if this can be resolved by local only modification not by global
calling convention change.
Unlike most of other C compiler we are using OpenWatcom comes with
quite big set of own CRTL functions and programmers should carefully
read manuals to check which ones can be separately enabled/disabled
to not cause some bad interactions.

BTW hbmk2 should inherit some of the above flags.
Now when we moved all C compiler flags settings to *.cf files we have
nothing to detect them at runtime. I think that it will be good to
use one common for all compiler make variable with C flags which we
can pass to hbpp and store in header files. Otherwise you will have
problem with keeping hbmk2 synced and it will not be possible to use
it with custom Harbour builds which may needs some special settings,
f.e. calling convention. Not all C compiler settings can be disabled
by setting some opposite options second time.

> > Anyhow here the difference will be probably minor.
> > Without this switches OpenWatcom gives the fastest code in few places.
> > F.e. even ICC is not close to OpenWatcom results in T029 and T030.
> > The overall performance is also quite good. In my tests it was noticable
> > better then BCC or POCC.
> Great, so if you say -bm isn't needed for MT support I can remove it.
> Shall I go for it?

If you plan to leave it in such version then for sure yes. I'd prefer
fully functional and quite fast ST builds then unsable.
Anyhow it is necessary for MT support but it's always good to check what
it does. In this case I'd prefer to enable DLMALLOC as default for
OpenWatcom Windows builds.

Viktor, no offence but it's a problem when you are making some local
tests for only few possible conditions and then you are updating SVN
code to your results which does not have to be representative.
In this case we end with such information in ChangeLog:

- Reverted yesterdays attempt to make owatcom builds faster.
  After the change the compilation time went slower, the
  binaries got smaller, but exec

Re: [Harbour] Harbour Distribution - Ready-to-Use

[Pritpal Bedi]

Hi

>I agree with qt prioriry

:-)

>XBase++ Parts by gtwvg have XBPStatics (not present in demoxbp) ?

Are you sure? Did you examine demoxbp.prg ?

>Do you still plan support gtwvg ?

100%.

>What are  GTQTC and GTQTG ?

Console and GUI based terminals just like GTWVT and GTWVG
but independant of operating systems.


Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/Harbour-Distribution---Ready-to-Use-tp22326050p22788909.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] SF.net SVN: harbour-project:[10741] trunk/harbour

[fsgiudice]

Revision: 10741
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10741&view=rev
Author:   fsgiudice
Date: 2009-03-30 18:14:42 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 20:13 UTC+0200 Francesco Saverio Giudice (info/at/fsgiudice.com)
  * harbour/contrib/examples/uhttpd/uhttpd.prg
+ added support for closing console using "X" system button
  using hb_GTInfo() functions. Tested only in windows.
* formatting
  * harbour/contrib/examples/uhttpd/uhttpdc.c
* added WM_CLOSE event in win_SysRefresh()
  * harbour/contrib/examples/uhttpd/session.prg
* minor change

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/examples/uhttpd/session.prg
trunk/harbour/contrib/examples/uhttpd/uhttpd.prg
trunk/harbour/contrib/examples/uhttpd/uhttpdc.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Harbour Distribution - Ready-to-Use

[Massimo Belgrano]

i was searched in demoxbp XBPStatic instead wvgStatic
  oStatic := WvgStatic():new( oDA )
   oStatic:type:= WVGSTATIC_TYPE_TEXT
   oStatic:options := WVGSTATIC_TEXT_CENTER
   oStatic:caption := chr(13)+'Implemented   Xbase++ Parts'

I think that in demoxbp will better having #translate  xbpStatic >
WvgStatic and use in demoxbp the know   xbpStatic
In future translation will be easy adapted to other lib and sound ok
for xbase++ user

I am very intrested by idea of having gt with gui capability
independant of operating systems.
I hope that will be able to switch from GTWVG to  GTQTG whitout rewrite


2009/3/30 Pritpal Bedi :
>
> Hi
>
>>I agree with qt prioriry
>
> :-)
>
>>XBase++ Parts by gtwvg have XBPStatics (not present in demoxbp) ?
>
> Are you sure? Did you examine demoxbp.prg ?
>
>>Do you still plan support gtwvg ?
>
> 100%.
>
>>What are  GTQTC and GTQTG ?
>
> Console and GUI based terminals just like GTWVT and GTWVG
> but independant of operating systems.
>
>
> Regards
> Pritpal Bedi
>
> --
> View this message in context: 
> http://www.nabble.com/Harbour-Distribution---Ready-to-Use-tp22326050p22788909.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
>



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

[Harbour] SF.net SVN: harbour-project:[10742] trunk/harbour

[fsgiudice]

Revision: 10742
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10742&view=rev
Author:   fsgiudice
Date: 2009-03-30 19:07:18 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 21:05 UTC+0200 Francesco Saverio Giudice (info/at/fsgiudice.com)
  * harbour/contrib/examples/uhttpd/uhttpd.prg
* error string formatting
  using hb_GTInfo() functions. Tested only in windows.
  * harbour/contrib/examples/uhttpd/session.prg
+ added retrying in case of error in writing / deleting session files.
  * harbour/contrib/examples/uhttpd/cgifunc.prg
* changed FCreate() to hb_FCreate()

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/examples/uhttpd/cgifunc.prg
trunk/harbour/contrib/examples/uhttpd/session.prg
trunk/harbour/contrib/examples/uhttpd/uhttpd.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Unified Harbour 1.1.0dev (beta) release

[Massimo Belgrano]

Thanks for clarification
I don't found msys in your distributions..is correct?


Which package can be used for x stable version?:
mingw
mingw-w64
http://sourceforge.net/project/showfiles.php?group_id=202880&package_id=241675
migw32ce 
http://downloads.sourceforge.net/cegcc/cygwin-cegcc-mingw32ce-0.51.0-1.tar.gz?use_mirror=switch
msys 1.0.11  
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963

what about mingw automatic installer (can we made similar for harbour?)
http://sourceforge.net/project/downloading.php?group_id=2435&use_mirror=kent&filename=MinGW-5.1.4.exe&a=2687957

2009/3/30 Viktor Szakáts :
> Well, I've posted MinGW CE sample script already on the list,
> the 64-bit version is almost like it with some changes
> (easy to copy from other cross-builds). Besides the above,
> all files were created using usual and documented mpkg_win.bat
> scripts and files copied together as a final stage. Anyhow this
> time my goal isn't to go into great detail to teach how to do
> this, even more so since current method cannot be considered
> final. I'd rather be interested in this package's usefulness and
> whether it's working and making things simpler for other
> developers.
> Brgds,
> Viktor
>
> On Mon, Mar 30, 2009 at 6:31 PM, Massimo Belgrano 
> wrote:
>>
>> Still Compliment Victor
>> Great result for made x86,x64 ,WinCE/ARM with mingw/harbour
>> What step can i do fo make same result with my svn?
>> If you describe how  compile, also other distribution Gan give this
>> benefit
>>
>>
>> 2009/3/30 Viktor Szakáts :
>> > Hi All,
>> > I've made available a unified and self-contained Windows release
>> > package, which is able to create x86, x64, WinCE/ARM executables
>> > (both shared and static) out of the box without the need of any
>> > external tools or settings.
>> > Download:
>> > http://www.syenar.hu/harbour/hb-1.1.0dev.7z
>> > (size: 136MB)
>> > To use:
>> > 1) unpack to any directory (C:\hb-1.1.0dev)
>> > 2) go to bin dir (optional if you specify path for hbmk2)
>> > 3) For x86 executable type: 'hbmk2 ../tests/hello.prg'
>> > 4) For x64 executable type: 'hbmk2 ../tests/hello.prg -comp=mingw64'
>> > 5) For WinCE/ARM executable type: 'hbmk2
>> > ../tests/hello.prg -comp=mingwce'
>> > The package also contains Harbour libraries to build MSVC 2008,
>> > Open Watcom 1.8 and Borland C 5.5.1 executables. For these,
>> > you need to have these compilers installed on your computer. The libs
>> > will automatically be picked by hbmk2.
>> > The package contains MinGW 4.3.3, MinGW 4.4.0 for x64 and
>> > MinGW 4.1.0 for ARM/CE embedded.
>> > I've used 7-Zip instead of .zip, because it cut the archive size by
>> > a factor of 2-3. If this package will get good reception I may add
>> > installer with de-selectable x64, WinCE and additional target libs.
>> > While it takes significant amount of time to assemble such package,
>> > nevertheless IMO it should be the definitive and official release
>> > methods instead of the separate compiler/CPU target specific
>> > packages we offer for 1.0.1.
>> > Following external dependencies were used to build corresponding
>> > Harbour libs:
>> > ace 9.10
>> > allegro 4.2.2
>> > blat 2.6.2
>> > libcurl 7.19.3
>> > firebird 2.1.1
>> > freeimage 3.11.0
>> > gd 2.0.34
>> > mysql 5.0.67
>> > openssl 0.9.8j
>> > pgsql 8.3.3
>> > qt 4.5.0 (2009.01)
>> > Brgds,
>> > Viktor
>> >
>> > ___
>> > Harbour mailing list
>> > Harbour@harbour-project.org
>> > http://lists.harbour-project.org/mailman/listinfo/harbour
>> >
>> >
>>
>>
>>
>> --
>> Massimo Belgrano
>> ___
>> 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
>
>



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

[Harbour] SF.net SVN: harbour-project:[10743] trunk/harbour

[druzus]

Revision: 10743
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10743&view=rev
Author:   druzus
Date: 2009-03-30 20:10:32 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 22:17 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/source/vm/dlmalloc.c
! fixed casting

  * harbour/source/vm/fm.c
% use DLMALLOC as default memory manager in OpenWatcom Windows builds.
  Warning: HB_FM_DLMT_ALLOC does not work with OpenWatcom.

  * harbour/config/dos/owatcom.cf
  * harbour/config/win/owatcom.cf
  * harbour/config/linux/owatcom.cf
  * harbour/config/os2/owatcom.cf
* changed alignment settings from 8 to 4
* synced optimization flags used in different builds
! fixed linker parameters when HB_BUILD_DEBUG=yes is set
; TOVERIFY: I do not remember what calling convention should be used
  in OpenWatcom MT OS2 builds to eliminate GPF when APIENTRY16 functions
  are called. It's possible that current settings are wrong.

  * harbour/config/win/owatcom.cf
* removed STACK=65536 from OpenWatcom linker parameters.
  This switch probably was inherited from old DOS WatcomC builds.
  Later I'll test current OpwnWatcom builds to check if we can also
  remove it from DOS builds when cwstub.exe is used.
* restored -bm switch. When DLMALLOC is used it does not cause
  noticeable performance reduction.
* use default register calling convention. We can change it
  in the future but 1-st we should check the performance overhead.
  If calling convention is a problem only for .DLLs then it can
  be resolved by modifying HB_EXTERN declaration and adding function
  attributes which will force given calling convention.

  * harbour/config/linux/owatcom.cf
* enabled pentium pro instruction in OpenWatcom Linux builds.
  It reduces the code size and increase performance a little bit.
  Windows users which do not need pure pentium CPU support can make
  the same.

  * harbour/utils/hbmk2/hbmk2.prg
! fixed object extension used in OpenWatcom Linux builds: it's .o not .obj
! fixed linker parameters in OpenWatcom Linux builds: DEBUG ALL is single
  option
! fixed OpenWatcom calling convention settings. Viktor you cannot chose
  simultaneously register and stack calling convention. You have to chose
  one and keep it synced with Harbour compile time settings. Otherwise
  you will have unresolved external or you will force creating by linker
  dynamically function call wrappers (of course if OW support such
  functionality) what may strongly reduce the performance.
! removed -j compile time switch - it's not used to compile core code
* synced optimization flags with core code

   I'm really interested in current OpenWatcom speedtst results compared
   with other Windows builds (MSVC, MinGW, BCC, POCC) in ST and MT builds.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/dos/owatcom.cf
trunk/harbour/config/linux/owatcom.cf
trunk/harbour/config/os2/owatcom.cf
trunk/harbour/config/win/owatcom.cf
trunk/harbour/source/vm/dlmalloc.c
trunk/harbour/source/vm/fm.c
trunk/harbour/utils/hbmk2/hbmk2.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[10744] trunk/harbour

[druzus]

Revision: 10744
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10744&view=rev
Author:   druzus
Date: 2009-03-30 20:56:21 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 23:02 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/contrib/gtwvg/Makefile
! check HB_ARCHITECTURE=win before compiling GTWVG.
  It fixes non Windows OpenWatcom and ICC builds.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/gtwvg/Makefile


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[10745] trunk/harbour

[fsgiudice]

Revision: 10745
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10745&view=rev
Author:   fsgiudice
Date: 2009-03-30 21:58:45 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-30 23:56 UTC+0200 Francesco Saverio Giudice (info/at/fsgiudice.com)
  * harbour/contrib/examples/uhttpd/uhttpd.prg
! fixed CGI POST variables handling
  now it sends correctly variables to external executables.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/examples/uhttpd/uhttpd.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Unified Harbour 1.1.0dev (beta) release

[Viktor Szakáts]

>
> Thanks for clarification
> I don't found msys in your distributions..is correct?


msys is only needed to build Harbour from source.
No need for it to *use* Harbour. [ well, except if you
want to use hbmk scripts, but I didn't include these
in this package for simplicity. ]

To put it short: yes, it's correct.


> Which package can be used for x stable version?:
> mingw
> mingw-w64
> http://sourceforge.net/project/showfiles.php?group_id=202880&package_id=241675 migw32ce>


No, I used this one:
http://downloads.sourceforge.net/mingw-w64/mingw-w64-bin_i686-mingw_20090110.zip?use_mirror=switch


> migw32ce migw32ce>
> http://downloads.sourceforge.net/cegcc/cygwin-cegcc-mingw32ce-0.51.0-1.tar.gz?use_mirror=switch


I don't know, but I've posted the link in one of my messages, in
reply to Przemek AFAIR. Either this or there is another similar
package with different CCPREFIX. You can compare with the
one in my package.


> msys 1.0.11
> http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963


Not needed here, but for building Harbour this looks okay.


> what about mingw automatic installer (can we made similar for harbour?)
>
> http://sourceforge.net/project/downloading.php?group_id=2435&use_mirror=kent&filename=MinGW-5.1.4.exe&a=2687957


I don't plan to develop something like this. Unstandard and for me
at least as irritating than classic Windows installers. Can save
bandwidth, maybe that's the point of it. But 100-150MB install
isn't such big these days, bandwidth isn't a problem if we use
sf.net to host the file.

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

Re: [Harbour] Re: XBASE++ speedtst

[Viktor Szakáts]

Hi Angel,
Just one note: Be aware with VNC, as it can suck significant amount
of CPU time in server mode. [ It uses poll method plus bitmap compression
in real-time. ] If you also have RDC connection I recommend that for
testing.

Another small one:
You can remove this line, it's the default, and there is now a different
settings to force old version (see in INSTALL):
set HB_VISUALC_VER=90

Brgds,
Viktor

2009/3/29 Angel Pais 

> Here new set of results with download link included...
> Please other windows users download and post results here
>
> HTH
> Angel
>
>
> Przemyslaw Czerpak escribió:
>
>  Can you also check what will happen if you rebuild Harbour with:
>>   set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_WIN_ALLOC
>>
>> best regards,
>> Przemek
>>
>
>
> Computer PIV Dual COre 3.0 win 2003 server, used tru VNC
>
> 03/29/2009 14:04:15 Windows XP 05.02 Build 03790
> Xbase++ (R) Version 1.90 (MT)+
> THREADS: 2
> N_LOOPS: 100
>1 th.  2 th.  factor
>
> 
> [ T001: x := L_C ]  0.13   0.12 ->
>  1.08
> [ T002: x := L_N ]  0.11   0.09 ->
>  1.22
> [ T003: x := L_D ]  0.08   0.08 ->
>  1.00
> [ T004: x := S_C ]  0.22   0.20 ->
>  1.10
> [ T005: x := S_N ]  0.17   0.16 ->
>  1.06
> [ T006: x := S_D ]  0.18   0.28 ->
>  0.64
> [ T007: x := M->M_C ]_  0.47   0.49 ->
>  0.96
> [ T008: x := M->M_N ]_  0.34   0.36 ->
>  0.94
> [ T009: x := M->M_D ]_  0.34   0.36 ->
>  0.94
> [ T010: x := M->P_C ]_  0.47   0.53 ->
>  0.89
> [ T011: x := M->P_N ]_  0.58   0.40 ->
>  1.45
> [ T012: x := M->P_D ]_  0.77   0.81 ->
>  0.95
> [ T013: x := F_C ]  0.74   0.70 ->
>  1.06
> [ T014: x := F_N ]  0.64   0.58 ->
>  1.10
> [ T015: x := F_D ]  0.59   0.64 ->
>  0.92
> [ T016: x := o:Args ]_  0.42   0.47 ->
>  0.89
> [ T017: x := o[2] ]___  0.19   0.16 ->
>  1.19
> [ T018: round( i / 1000, 2 ) ]  3.43   3.33 ->
>  1.03
> [ T019: str( i / 1000 ) ]_ 21.55  21.41 ->
>  1.01
> [ T020: val( s ) ]  0.96   1.00 ->
>  0.96
> [ T021: val( a [ i % 16 + 1 ] ) ]_  2.38   2.33 ->
>  1.02
> [ T022: dtos( d - i % 1 ) ]___  3.25   3.25 ->
>  1.00
> [ T023: eval( { || i % 16 } ) ]___  3.01   3.18 ->
>  0.95
> [ T024: eval( bc := { || i % 16 } ) ]_  1.78   1.68 ->
>  1.06
> [ T025: eval( { |x| x % 16 }, i ) ]___  1.38   1.41 ->
>  0.98
> [ T026: eval( bc := { |x| x % 16 }, i ) ]_  1.05   1.09 ->
>  0.96
> [ T027: eval( { |x| f1( x ) }, i ) ]__  1.56   1.71 ->
>  0.91
> [ T028: eval( bc := { |x| f1( x ) }, i ) ]  1.42   1.55 ->
>  0.92
> [ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ]___  2.04   1.99 ->
>  1.03
> [ T030: x := &( 'f1(' + str(i) + ')' ) ]__ 60.67  60.14 ->
>  1.01
> [ T031: bc := &( '{|x|f1(x)}' ), eval( bc, i ) ]__ 61.03  61.48 ->
>  0.99
> [ T032: x := valtype( x ) +  valtype( i ) ]___  1.02   0.90 ->
>  1.13
> [ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ] 23.69  23.80 ->
>  1.00
> [ T034: x := a[ i % 16 + 1 ] == s ]___  0.90   0.94 ->
>  0.96
> [ T035: x := a[ i % 16 + 1 ] = s ]  1.36   1.38 ->
>  0.99
> [ T036: x := a[ i % 16 + 1 ] >= s ]___  1.35   1.38 ->
>  0.98
> [ T037: x := a[ i % 16 + 1 ] <= s ]___  1.33   1.40 ->
>  0.95
> [ T038: x := a[ i % 16 + 1 ] < s ]  1.32   1.35 ->
>  0.98
> [ T039: x := a[ i % 16 + 1 ] > s ]  1.26   1.36 ->
>  0.93
> [ T040: ascan( a, i % 16 ) ]__  2.11   2.10 ->
>  1.00
> [ T041: ascan( a, { |x| x == i % 16 } ) ]_ 14.21  14.74 ->
>  0.96
> [ T042: iif( i%1000==0, a:={}, ), aadd(a,{i,1,.t.,s, ] 20.09  20.55 ->
>  0.98
> [ T043: x := a ]__  0.12   0.11 ->
>  1.09
> [ T044: x := {} ]_  1.18   1.46 ->
>  0.81
> [ T045: f0() ]  0.47   0.35 ->
>  1.34
> [ T046: f1( i ) ]_  0.54   0.47 ->
>  1.15
> [ T047: f2( c[1...8] ) ]__  0.42   0.43 ->
>  0.98
> [ T048: f2( c[1...4] ) ]__  0.45   0.45 ->
>  1.00
> 

Re: [Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour

[Francesco Saverio Giudice]

Hi Przemek,

here are speedtst logs for Vista Ultimate with Intel(R) Core(TM)2 Duo 
CPU T8300 @ 2.40GHz


Next message with 2 x Intel(R) Xeon(TM) CPU 3.00GHz Dual Core (4 Core in 
total) Microsoft Windows Server 2003, Standard Edition Service Pack 2 
(Build 3790)


All tests with speedtest built with:
hbmk2.exe speedtst.prg -mt -gc3 -l -ko

Best regards,
Francesco

03/30/09 00:31:37 Windows Vista 6.0.6001 Service Pack 1
Harbour 1.1.0dev (Rev. 10728) (MT)+ Microsoft Visual C++ 15.0.26569 (32-bit)
THREADS: 4
N_LOOPS: 100
1 th.  4 th.  factor

[ T001: x := L_C ]  0.36   0.20 ->  1.76
[ T002: x := L_N ]  0.22   0.13 ->  1.74
[ T003: x := L_D ]  0.22   0.13 ->  1.74
[ T004: x := S_C ]  0.42   0.31 ->  1.35
[ T005: x := S_N ]  0.26   0.14 ->  1.88
[ T006: x := S_D ]  0.26   0.17 ->  1.55
[ T007: x := M->M_C ]_  0.48   0.27 ->  1.83
[ T008: x := M->M_N ]_  0.31   0.19 ->  1.67
[ T009: x := M->M_D ]_  0.31   0.19 ->  1.66
[ T010: x := M->P_C ]_  0.36   0.22 ->  1.63
[ T011: x := M->P_N ]_  0.31   0.19 ->  1.67
[ T012: x := M->P_D ]_  0.31   0.20 ->  1.54
[ T013: x := F_C ]  1.00   0.55 ->  1.83
[ T014: x := F_N ]  0.84   0.45 ->  1.87
[ T015: x := F_D ]  0.50   0.26 ->  1.88
[ T016: x := o:Args ]_  0.89   0.48 ->  1.84
[ T017: x := o[2] ]___  0.62   0.34 ->  1.82
[ T018: round( i / 1000, 2 ) ]  1.00   0.55 ->  1.83
[ T019: str( i / 1000 ) ]_  2.42   1.28 ->  1.89
[ T020: val( s ) ]  1.15   0.61 ->  1.90
[ T021: val( a [ i % 16 + 1 ] ) ]_  1.83   1.00 ->  1.83
[ T022: dtos( d - i % 1 ) ]___  1.89   1.01 ->  1.86
[ T023: eval( { || i % 16 } ) ]___  2.59   1.78 ->  1.46
[ T024: eval( bc := { || i % 16 } ) ]_  1.17   0.62 ->  1.88
[ T025: eval( { |x| x % 16 }, i ) ]___  1.87   1.48 ->  1.26
[ T026: eval( bc := { |x| x % 16 }, i ) ]_  1.20   0.69 ->  1.75
[ T027: eval( { |x| f1( x ) }, i ) ]__  2.15   1.62 ->  1.33
[ T028: eval( bc := { |x| f1( x ) }, i ) ]  1.44   0.83 ->  1.74
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ]___  1.50   0.80 ->  1.88
[ T030: x := &( "f1(" + str(i) + ")" ) ]__ 11.90   6.54 ->  1.82
[ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ]__ 14.91   8.91 ->  1.67
[ T032: x := valtype( x ) +  valtype( i ) ]___  1.89   1.04 ->  1.81
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ]  3.17   1.72 ->  1.85
[ T034: x := a[ i % 16 + 1 ] == s ]___  1.40   0.76 ->  1.84
[ T035: x := a[ i % 16 + 1 ] = s ]  1.45   0.80 ->  1.82
[ T036: x := a[ i % 16 + 1 ] >= s ]___  1.47   0.80 ->  1.84
[ T037: x := a[ i % 16 + 1 ] <= s ]___  1.47   0.81 ->  1.81
[ T038: x := a[ i % 16 + 1 ] < s ]  1.47   0.81 ->  1.81
[ T039: x := a[ i % 16 + 1 ] > s ]  1.51   0.81 ->  1.87
[ T040: ascan( a, i % 16 ) ]__  1.44   0.76 ->  1.88
[ T041: ascan( a, { |x| x == i % 16 } ) ]_ 14.77   8.45 ->  1.75
[ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s ]  4.32   2.65 ->  1.63
[ T043: x := a ]__  0.39   0.20 ->  1.92
[ T044: x := {} ]_  1.04   0.95 ->  1.10
[ T045: f0() ]  0.44   0.25 ->  1.76
[ T046: f1( i ) ]_  0.61   0.33 ->  1.86
[ T047: f2( c[1...8] ) ]__  0.73   0.39 ->  1.88
[ T048: f2( c[1...4] ) ]__  0.72   0.41 ->  1.77
[ T049: f2( @c[1...4] ) ]_  0.51   0.28 ->  1.84
[ T050: f2( @c[1...4] ), c2 := c ]  0.77   0.40 ->  1.89
[ T051: f3( a, a2, s, i, s2, bc, i, n, x ) ]__  2.23   1.15 ->  1.93
[ T052: f2( a ) ]_  0.69   0.39 ->  1.76
[ T053: x := f4() ]___  3.17   1.73 ->  1.83
[ T054: x := f5() ]___  1.44   0.76 ->  1.88
[ T055: x := space(16) ]__  1.19   0.64 ->  1.86
[ T056: f_prv( c ) ]__  2.53   1.34 ->  1.88
===

Re: [Harbour] SF.net SVN: harbour-project:[10743] trunk/harbour

[Viktor Szakáts]

Hi Przemek,


>  * harbour/source/vm/fm.c
>% use DLMALLOC as default memory manager in OpenWatcom Windows builds.
>  Warning: HB_FM_DLMT_ALLOC does not work with OpenWatcom.
>

Thanks.


>  * harbour/config/dos/owatcom.cf
>  * harbour/config/win/owatcom.cf
>  * harbour/config/linux/owatcom.cf
>  * harbour/config/os2/owatcom.cf
>* changed alignment settings from 8 to 4
>* synced optimization flags used in different builds
>! fixed linker parameters when HB_BUILD_DEBUG=yes is set
>; TOVERIFY: I do not remember what calling convention should be used
>  in OpenWatcom MT OS2 builds to eliminate GPF when APIENTRY16 functions
>  are called. It's possible that current settings are wrong.
>

They almost surely *are* wrong. I've just copied them from
win version in the hope OS/2 users will be interested and
tweak it.


>  * harbour/config/win/owatcom.cf
>* removed STACK=65536 from OpenWatcom linker parameters.
>  This switch probably was inherited from old DOS WatcomC builds.
>  Later I'll test current OpwnWatcom builds to check if we can also
>  remove it from DOS builds when cwstub.exe is used.
>* restored -bm switch. When DLMALLOC is used it does not cause
>  noticeable performance reduction.
>* use default register calling convention. We can change it
>  in the future but 1-st we should check the performance overhead.
>  If calling convention is a problem only for .DLLs then it can
>  be resolved by modifying HB_EXTERN declaration and adding function
>  attributes which will force given calling convention.
>

Thanks, IMO we must do this as the definitive goal is to have
interchangeable harbour dll. This is very important and one of the
main points of .dlls. Notice that .dll support in win/owatcom is
broken due some startup procedure problems.

 * harbour/config/linux/owatcom.cf
>* enabled pentium pro instruction in OpenWatcom Linux builds.
>  It reduces the code size and increase performance a little bit.
>  Windows users which do not need pure pentium CPU support can make
>  the same.
>

We're already PPro level for some compiler, so IMO it's safe to do for
win/owatcom.


>  * harbour/utils/hbmk2/hbmk2.prg
>! fixed OpenWatcom calling convention settings. Viktor you cannot chose
>  simultaneously register and stack calling convention. You have to
> chose
>  one and keep it synced with Harbour compile time settings. Otherwise
>  you will have unresolved external or you will force creating by linker
>  dynamically function call wrappers (of course if OW support such
>  functionality) what may strongly reduce the performance.
>

Well, I just copied them from .cf files, which weren't developed by
me, so don't blame me :)

After settling with the switches in .cf files I was planning to do a
sync with hbmk2. It's in the included TODO list.

Thanks for your changes.

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

Re: [Harbour] SF.net SVN: harbour-project:[10738] trunk/harbour

[Viktor Szakáts]

Hi Przemek,


> We were discussing about it when OW OS2 port was added.
> If you want to set this flag as default then you have to
> also enable DL malloc as default memory manager. It will
> reduce a little bit the performance in single thread application
> but MT once will be usable. The problem is with OS2 builds because
> dlmalloc does not support this OS.
> So far I haven't found time to check in OpenWatcom source code why the
> memory manager used of MT mode is such slow.


Could you enable DLMALLOC for owatcom? [ I don't want to mess it up ]

[ I see you committed most of the things along these lines. Hereby thanks
and sorry for some double thoughts in this mail. ]


> I know what it does. And for sure it's good to use it if necessary.
> But it will be also good if you will test the results of switching
> you are enabling. I know that it's time consuming but in some cases
> we also lost information about already tested and updated settings.
> Probably now when we do not use CRTL *printf() functions familly
> then we do not use any other functions which needs separate MT/ST
> versions (except memory allocator) so it should be enough to compile
> only hbvm with this switch. Anyhow it's not good practice because
> we do not know what exactly this switch does. We should ask on Open
> Watcom devel list or look in the source code for details.


A quick check today revealed that it doesn't change generated machine code,
but it will link against the MT C RTL instead of ST one plus I see a symbol
in
the .obj named __imthread. I didn't investigate what it does or how it's
used.


> > > performance is -5s but I haven't made any real tests here and I only
> > > guess that stack calling convention is slower then register one.
> > It's definitely slower, but needed for compatible .dll generation
> > as far as I understood Andi's mail. Didn't spend time to do
> > side-by-side comparison though.
>
> It's only necessary if you want to use OpenWatcom harbour.dll with
> other Harbour builds. It's not necessary if you want to use OpenWatcom
> harbour.dll with OpenWatcom Harbour builds.


The idea is that harbour.dlls are interchangeable (I think this is a major
point in .dlls), so we should allow for this definitely. [ BTW, owatcom
.dll
support still doesn't work for other reasons. ]


> Anyhow if for some reasons you want to make harbour.dll with OpenWatcom
> and use it later with other compilers then it's enough to change only
> attributes of exported functions and it's not necessary to manipulate
> with calling convention of the whole build. Just like you do not have
> to change it for static builds. Such option can be set only for DLLs.
> Personally I'd prefer to use native for compiler settings.


It would be better indeed, but I have no idea how to tweak exported
function attributes. We can remove this once this is set. Maybe it
already is, someone should check. [ or maybe I will with new rev. ]

If I want to make something different then I can use HB_USER_CFLAGS.
> Anyhow in this particular case the calling convention options should
> be changed extremely carefully. In OS2 builds they were badly interact
> when some OS2 16bit API functions were called and we were fighting for
> quite long time with GPF in MT mode. Finally Maurilio set it to value
> which were playing well OS2 16bit API but in fact we haven't checked
> if this can be resolved by local only modification not by global
> calling convention change.


Hm, and that leads me to the point that os2/owatcom.cf was added by
me by copying one of the existing copies, so the settings there are
*almost surely wrong*. It would need OS/2 users to tweak it, test it or
just to set those good looking settings you mention above.


> BTW hbmk2 should inherit some of the above flags.

Now when we moved all C compiler flags settings to *.cf files we have
> nothing to detect them at runtime. I think that it will be good to
> use one common for all compiler make variable with C flags which we
> can pass to hbpp and store in header files. Otherwise you will have
> problem with keeping hbmk2 synced and it will not be possible to use
> it with custom Harbour builds which may needs some special settings,
> f.e. calling convention. Not all C compiler settings can be disabled
> by setting some opposite options second time.


Yes, I was thinking about something like this, for me it would be many
times important to retrieve the default settings of a given build, and
currently there is no way to do it (also for default Harbour flags). Such
information could be included in speedtst output even. If you could
lay the infrastructure for this, I would finish it.

Since every file/lib can have different settings, we should keep this
effect on current minimum level in the future.


> If you plan to leave it in such version then for sure yes. I'd prefer
> fully functional and quite fast ST builds then unsable.
> Anyhow it is necessary for MT support but it's always good to check what
> it

[Harbour] SF.net SVN: harbour-project:[10746] trunk/harbour

[vszakats]

Revision: 10746
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10746&view=rev
Author:   vszakats
Date: 2009-03-30 23:29:16 + (Mon, 30 Mar 2009)

Log Message:
---
2009-03-31 01:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * external/libhpdf/Makefile
  * external/libpng/Makefile
  * contrib/hbqt/Makefile
- Disabled for poccce due to errors.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/Makefile
trunk/harbour/external/libhpdf/Makefile
trunk/harbour/external/libpng/Makefile


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] telepahty, output overflow

[Barry Jackson]

May be worth looking at the functions in 
SVN/harbour/contrib/hbtpathy/telepath.prg

tp_ctrlcts( nPort, nNewCtrl )
tp_ctrlrts( nPort, nNewCtrl )
tp_iscts( nPort ) etc...
I think you will need to experiment as there is little documentation for 
this.

You could send text in small packets and wait for tp_iscts( nPort ) == .T.
between each.

Barry


AbeB wrote:

Hi Alex,
Thanks for quick reply.

In the printer it's enabled, but in software i have no clue how.

Any guidance?

Thanks,
abe



AbeB wrote:

  

I'm printing to serial printer with  hbtpathy.lib

f.e.
tp_send(1, 
replic("012345678901234567890012345678901234567890"+chr(13)+chr(10),1000 ) )
but it whould cause overflow in the printed output.

any help?



Not specific to telepathy, but you must enable flow control on the printer and 
in your software. Most common are DTR/DTS (hardware) or XOn/XOff (software).


HTH
Alex
___
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: XBASE++ speedtst

[Angel Pais]

Hi Viktor
Thank your very much for your recommendations.
When I can put my hands on another dual core pc, I will redo all tests 
just out of curiosity.
It was weekend and the only pc with 2 processors I could access was that 
 one.


Best Regards
Angel

Note: 19 people have downloaded my set of tests.
Almost all of them from South America and East Europe.
West Europe: 1 from Italy
Oceania: None
Asia: None
North America: None
Africa: None
Interesting profile indeed !


Viktor Szakáts escribió:

Hi Angel,

Just one note: Be aware with VNC, as it can suck significant amount 
of CPU time in server mode. [ It uses poll method plus bitmap compression 
in real-time. ] If you also have RDC connection I recommend that for 
testing.


Another small one:
You can remove this line, it's the default, and there is now a different 
settings to force old version (see in INSTALL):

set HB_VISUALC_VER=90

Brgds,
Viktor


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

Re: [Harbour] SF.net SVN: harbour-project:[10743] trunk/harbour

[Viktor Szakáts]

I just tested new build with Open Watcom regarding .dll compatibility
and unfortunately it
doesn't work anymore, so we need to do something, but what?

Brgds,
Viktor

On Mon, Mar 30, 2009 at 10:10 PM,  wrote:

> Revision: 10743
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10743&view=rev
> Author:   druzus
> Date: 2009-03-30 20:10:32 + (Mon, 30 Mar 2009)
>
> Log Message:
> ---
> 2009-03-30 22:17 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
>  * harbour/source/vm/dlmalloc.c
>! fixed casting
>
>  * harbour/source/vm/fm.c
>% use DLMALLOC as default memory manager in OpenWatcom Windows builds.
>  Warning: HB_FM_DLMT_ALLOC does not work with OpenWatcom.
>
>  * harbour/config/dos/owatcom.cf
>  * harbour/config/win/owatcom.cf
>  * harbour/config/linux/owatcom.cf
>  * harbour/config/os2/owatcom.cf
>* changed alignment settings from 8 to 4
>* synced optimization flags used in different builds
>! fixed linker parameters when HB_BUILD_DEBUG=yes is set
>; TOVERIFY: I do not remember what calling convention should be used
>  in OpenWatcom MT OS2 builds to eliminate GPF when APIENTRY16 functions
>  are called. It's possible that current settings are wrong.
>
>  * harbour/config/win/owatcom.cf
>* removed STACK=65536 from OpenWatcom linker parameters.
>  This switch probably was inherited from old DOS WatcomC builds.
>  Later I'll test current OpwnWatcom builds to check if we can also
>  remove it from DOS builds when cwstub.exe is used.
>* restored -bm switch. When DLMALLOC is used it does not cause
>  noticeable performance reduction.
>* use default register calling convention. We can change it
>  in the future but 1-st we should check the performance overhead.
>  If calling convention is a problem only for .DLLs then it can
>  be resolved by modifying HB_EXTERN declaration and adding function
>  attributes which will force given calling convention.
>
>  * harbour/config/linux/owatcom.cf
>* enabled pentium pro instruction in OpenWatcom Linux builds.
>  It reduces the code size and increase performance a little bit.
>  Windows users which do not need pure pentium CPU support can make
>  the same.
>
>  * harbour/utils/hbmk2/hbmk2.prg
>! fixed object extension used in OpenWatcom Linux builds: it's .o not
> .obj
>! fixed linker parameters in OpenWatcom Linux builds: DEBUG ALL is
> single
>  option
>! fixed OpenWatcom calling convention settings. Viktor you cannot chose
>  simultaneously register and stack calling convention. You have to
> chose
>  one and keep it synced with Harbour compile time settings. Otherwise
>  you will have unresolved external or you will force creating by linker
>  dynamically function call wrappers (of course if OW support such
>  functionality) what may strongly reduce the performance.
>! removed -j compile time switch - it's not used to compile core code
>* synced optimization flags with core code
>
>   I'm really interested in current OpenWatcom speedtst results compared
>   with other Windows builds (MSVC, MinGW, BCC, POCC) in ST and MT builds.
>
> Modified Paths:
> --
>trunk/harbour/ChangeLog
>trunk/harbour/config/dos/owatcom.cf
>trunk/harbour/config/linux/owatcom.cf
>trunk/harbour/config/os2/owatcom.cf
>trunk/harbour/config/win/owatcom.cf
>trunk/harbour/source/vm/dlmalloc.c
>trunk/harbour/source/vm/fm.c
>trunk/harbour/utils/hbmk2/hbmk2.prg
>
>
> This was sent by the SourceForge.net collaborative development platform,
> the world's largest Open Source development site.
> ___
> 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: SF.net SVN: harbour-project:[10724] trunk/harbour

[Przemyslaw Czerpak]

On Mon, 30 Mar 2009, Francesco Saverio Giudice wrote:

Hi,

> here are speedtst logs for Vista Ultimate with Intel(R) Core(TM)2 Duo
> CPU T8300 @ 2.40GHz
> and with 2 x Intel(R) Xeon(TM) CPU 3.00GHz Dual Core (4 Core in
> total) Microsoft Windows Server 2003, Standard Edition Service Pack 2
> (Build 3790)
> also if this server has lot of running services but on Sunday night it 
> works lesser.
> All tests with speedtest built with:
> hbmk2.exe speedtst.prg -mt -gc3 -l -ko
> SVN built with:
> set HB_USER_CFLAGS=-DHB_LEGACY_OFF -DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC
> Mail sent again with zipped log (I forgot list limit)

Thank you very much. The results suggests that scallability strongly
depends on Hardware and exact CPU model. Looks that there are different
multiCPU x86 machines.
There are also serious differences in resolving simultanouse write access
between computers. It can be well seen in T044 test:
   [ T044: x := {} ]___  1.98   3.71 ->  0.53
and:
   [ T044: x := {} ]___  1.06   0.95 ->  1.11
Allocating new GC item (array, hash, codeblock, GC pointer) needs lock
which serializes thread execution. The cost of this lock strongly depends
on used hardware. In normal application it should not be big problem because
there is small chance that few threads will only allocate and release new
array in a loop in the same time. But it's the last such place in whole
Harbour code and the possible conflict and performance reduction can be
resolved with the cost of some static overhead but I do not know if it's
worth to pay. Maybe in some spare time I'll implement it to make some tests.

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

Re: [Harbour] SF.net SVN: harbour-project:[10688] trunk/harbour

[Przemyslaw Czerpak]

On Sun, 29 Mar 2009, Szak�ts Viktor wrote:

Hi,

> > BTW: in hbsetup.h you added:
> > ( defined(__POCC_TARGET__) && __POCC_TARGET__ == 2 )
> > to detect HB_OS_WIN_CE builds. Maybe it's documented method in POCC
> > and in such case should be left but if not then I suggest to rather
> > use sth like:
> > ( defined( HB_OS_WIN ) && defined( _M_ARM ) )
> Maybe I'm missing something, but _M_ARM doesn't seem to work in POCC 5,
> I've found no better solution back then, that's why I opted for this route.
> --- test.c
> #if defined( _M_ARM )
>#error defined
> #else
>#error not defined
> #endif
> ---
> >pocc -Tarm-coff test.c

Hm, In such case this seems to be much more serious problem.
I do not have the newest POCC but in version 4.50 header files needs
_M_ARM, _ARM_ and _WINCE and UNICODE macros for PocketPC builds.
If they are not set then it's possible that we will generate wrong
binaries and probably we should set them manually probably using
-D pocc.exe option.
I think it will be good to ask Pelle about it.

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

[Harbour] SF.net SVN: harbour-project:[10747] trunk/harbour

[druzus]

Revision: 10747
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10747&view=rev
Author:   druzus
Date: 2009-03-31 00:39:37 + (Tue, 31 Mar 2009)

Log Message:
---
2009-03-31 02:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/config/dos/owatcom.cf
  * harbour/config/win/owatcom.cf
  * harbour/config/linux/owatcom.cf
  * harbour/config/os2/owatcom.cf
  * harbour/utils/hbmk2/hbmk2.prg
* removed unnecessary linker options
* use 'SYS causeway' to enable causeway stub in DOS builds instead
  of setting it manually. DOS users can also use DOS4G (default) or
  PMODE (commercial) stubs.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/dos/owatcom.cf
trunk/harbour/config/linux/owatcom.cf
trunk/harbour/config/os2/owatcom.cf
trunk/harbour/config/win/owatcom.cf
trunk/harbour/utils/hbmk2/hbmk2.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[10688] trunk/harbour

[Viktor Szakáts]

>
> > > BTW: in hbsetup.h you added:
> > > ( defined(__POCC_TARGET__) && __POCC_TARGET__ == 2 )
> > > to detect HB_OS_WIN_CE builds. Maybe it's documented method in POCC
> > > and in such case should be left but if not then I suggest to rather
> > > use sth like:
> > > ( defined( HB_OS_WIN ) && defined( _M_ARM ) )
> > Maybe I'm missing something, but _M_ARM doesn't seem to work in POCC 5,
> > I've found no better solution back then, that's why I opted for this
> route.
> > --- test.c
> > #if defined( _M_ARM )
> >#error defined
> > #else
> >#error not defined
> > #endif
> > ---
> > >pocc -Tarm-coff test.c
>
> Hm, In such case this seems to be much more serious problem.
> I do not have the newest POCC but in version 4.50 header files needs
> _M_ARM, _ARM_ and _WINCE and UNICODE macros for PocketPC builds.
> If they are not set then it's possible that we will generate wrong
> binaries and probably we should set them manually probably using
> -D pocc.exe option.
> I think it will be good to ask Pelle about it.


5.00.1 headers also seem to need _M_ARM. _ARM_ is automatically
defined, so it's not needed to be set explicitly. I'll do it. Above
__TARGET__*
check isn't needed, as _WINCE is already there to detect WinCE.
I'm doing some tests and commit.

Slightly off:

Now I know how to create x86/CE builds. But with this
the number of combinations is so high we'd really need a separate
CPU make layer, or some other solution like separating WinCE
compilers to a distinct HB_ARCHITECTURE 'wce'. This is the
way used by QT for example, and WinCE *is* a different OS, despite
resembling to win in many aspects. So our new arch would look like:
wce/mingwarm
wce/msvcarm
wce/poccarm
wce/poccx86

If there is no strong opinion against it, I'd like to do this. It will
also help excluding/including libs for WinCE.

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

[Harbour] SF.net SVN: harbour-project:[10748] trunk/harbour

[vszakats]

Revision: 10748
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10748&view=rev
Author:   vszakats
Date: 2009-03-31 01:11:22 + (Tue, 31 Mar 2009)

Log Message:
---
2009-03-31 02:58 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
  * include/hbsetup.h
% '( defined(__POCC_TARGET__) && __POCC_TARGET__ == 2 ) )'
  removed altogether. WinCE is detected anyway by using _WINCE.

  * external/sqlite3/Makefile
- Disabled for poccce due to errors.

  * external/libpng/Makefile
! Fix to prev (poccce).

  * config/win/poccce.cf
! Added -D_M_ARM.

  * config/win/owatcom.cf
* Pentium Pro scheduling.
* Changed back to __cdecl calling convention from register based
  until we find a way to tweak HB_EXPORT to force __cdecl for 
  .dll exported functions.
; TOFIX: Find out how to force __cdecl for HB_EXPORT functions in owatcom.
 Or, if this is no good solution for owatcom users, or not 
 an option and performace is more important, we must rename
 owatcom Harbour .dlls to a distinct name: harbour[mt]-11-ow.dll.
 We should try to avoid that.

  * config/win/bcc.cf
* -4 -> -6 for Pentium Pro instructions. Looking at the generated
  code this looks like rescheduling, if someone now can test Harbour
  or plain Pentium, it would be good to know if it still works.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/win/bcc.cf
trunk/harbour/config/win/owatcom.cf
trunk/harbour/config/win/poccce.cf
trunk/harbour/external/libpng/Makefile
trunk/harbour/external/sqlite3/Makefile
trunk/harbour/include/hbsetup.h


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[10748] trunk/harbour

[Viktor Szakáts]

>
>  * config/win/bcc.cf
>* -4 -> -6 for Pentium Pro instructions. Looking at the generated
>  code this looks like rescheduling, if someone now can test Harbour
>  or plain Pentium, it would be good to know if it still works.
>

Some more info on above:

Turns out that -6 generates the *exact same* code as -4, with both
5.5 and 5.8. Quite interesting, but true. I did some tests using -5
also, and it turned out to be significantly slower than -4/-6. So, the
quick conclusion is that we should stick with -4 or -6. Please comment
or make some locals test to deny or confirm these findings.

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

Re: [Harbour] telepahty, output overflow

[AbeB]

Am I wrong thinking that it's only implimented on Linux?


May be worth looking at the functions in 
SVN/harbour/contrib/hbtpathy/telepath.prg
tp_ctrlcts( nPort, nNewCtrl )
tp_ctrlrts( nPort, nNewCtrl )
tp_iscts( nPort ) etc...
I think you will need to experiment as there is little documentation for 
this.
You could send text in small packets and wait for tp_iscts( nPort ) == .T.
between each.

Barry


AbeB wrote:
> Hi Alex,
> Thanks for quick reply.
>
> In the printer it's enabled, but in software i have no clue how.
>
> Any guidance?
>
> Thanks,
> abe
>
>
>
> AbeB wrote:
>
>   
>> I'm printing to serial printer with  hbtpathy.lib
>>
>> f.e.
>> tp_send(1, 
>> replic("012345678901234567890012345678901234567890"+chr(13)+chr(10),1000 ) )
>> but it whould cause overflow in the printed output.
>>
>> any help?
>> 
>
> Not specific to telepathy, but you must enable flow control on the printer 
> and 
> in your software. Most common are DTR/DTS (hardware) or XOn/XOff (software).
>
> HTH
> Alex
> ___
> 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



-- 
View this message in context: 
http://n2.nabble.com/telepahty%2C-output-overflow-tp2557549p2560715.html
Sent from the harbour-devel mailing list archive at Nabble.com.

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

Re: [Harbour] Re: XBASE++ speedtst

[Chen Kedem]

Angel,

> Note: 19 people have downloaded my set of tests.
> Almost all of them from South America and East Europe.
:
> Interesting profile indeed !

You can see similar results in Piwik statistics for Harbour SF pages:
(go to Visitors | Locations & Provider)

http://apps.sourceforge.net/piwik/harbour-project/index.php?module=CoreHome&action=index&idSite=1&period=month&date=today


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