[Harbour] Thanks to Marcos Gambeta for his exciting and inspiring works

2009-03-19 Thread Massimo Belgrano
Thanks to Marcos Gambeta for his exciting and inspiring works
HB QT is a Great Milestone for harbour comunity now we will  able
develop state-of-the-art graphical user interfaces for harbour, and
easily port them to new platforms
Harbour and QT are either Mature,Modern,Portable,Efficient   and the
marriage hb,qta will give Popular and beautiful
Still Thanks also to all harbour developer that have joined to qt idea
-- 
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


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

2009-03-19 Thread vszakats
Revision: 10651
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10651&view=rev
Author:   vszakats
Date: 2009-03-19 08:14:22 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 09:10 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
  * bin/postinst.bat
- Removed generation of odbc32.lib for BCC.
  You should configure BCC to include /Lib/PSDK in
  the lib paths in bcc32.cfg and ilink32.cfg. It's not
  Harbour's job to generate it.

  - contrib/hbodbc/tests/harbour.mdb
  + contrib/hbodbc/tests/test.mdb
  * contrib/hbodbc/tests/odbcdemo.prg
  * contrib/hbodbc/tests/odbccall.prg
  * contrib/hbodbc/tests/testodbc.prg
* Created working test table from test.dbf.
  (previous .mdb was broken)

  * contrib/hbodbc/tests/odbcdemo.prg
  * contrib/hbodbc/tests/odbccall.prg
  * contrib/hbodbc/tests/testodbc.prg
  * contrib/hbodbc/todbc.prg
  * contrib/hbodbc/browodbc.prg
  * contrib/hbodbc/sql.ch
* Formatting.
* Optimizations and cleanups. (could still use a lot more)
! Fixed to not use Alert().

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/bin/postinst.bat
trunk/harbour/contrib/hbodbc/browodbc.prg
trunk/harbour/contrib/hbodbc/sql.ch
trunk/harbour/contrib/hbodbc/tests/odbccall.prg
trunk/harbour/contrib/hbodbc/tests/odbcdemo.prg
trunk/harbour/contrib/hbodbc/tests/testodbc.prg
trunk/harbour/contrib/hbodbc/todbc.prg

Added Paths:
---
trunk/harbour/contrib/hbodbc/tests/test.mdb

Removed Paths:
-
trunk/harbour/contrib/hbodbc/tests/harbour.mdb


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] nasty bug: in RDDADS + scopeactive + dbskip(0)

2009-03-19 Thread Przemyslaw Czerpak
On Wed, 18 Mar 2009, Edmer wrote:

Hi,

> Is this a confirmed bug ?
> >> dbskip(0) will move the record pointer to phantom record (honoring the
> >> scope). other RDDS don't do that

It's cause by ADS behavior.

> >> #include "ads.ch"
> >> proc main()
> >> rddregister( "ADS", 1 )

Not necessary from over 5 years, please remove this line from
all you Harbour and xHarbouyr sopurce code.

> >> rddsetdefault( "ADSCDX" )
> >> set server local
> >> adslocking(  .f. )
> >> adssetfiletype(ADS_CDX)

It's not necessary if you are using ADSCDX, ADSNTX, ADT RDDs.
adssetfiletype() is used only by "ADS" RDD for backward compatibility.
As above, please remove it.

> >> adslocking(  .f. )

Repeated. Always try to no add any redundant code to examples or developers
will have to look if it's not a reason of problem.

> >> dbcreate("test.dbf",{ ;
> >> {"tick" ,"n" , 10,0} })
> >> use test via "ADSCDX" excl
> >> index on tick tag tick
> >> ordscope(0, 100)
> >> ordscope(1, 200 )
> >> ? rddname()
> >> for lop := 1 to 10
> >>dbappend(  .t. )
> >> //refresh buffer (server's trigger populated some fields)
> >>dbskip( 0 )

Here new record is out of scope, dbSkip(0) is redirected to AdsSkip(0)
functions which checks scopes and if record is out of the scope then
it moves records to phantom record (EOF position). It's not Clipper
compatible behavior but ADS work in such way. There are many others
incompatibilities to Clipper in ADS though this one we can try to
hide in our code if it's real problem.
It enough to comment line 1154 in ads.c:
   AdsSkip( (pArea->hOrdCurrent) ? pArea->hOrdCurrent : pArea->hTable, 0 );
Just try.

> >>//goto recn()  //<- this is ok
> >>field->tick := 100 + lop

Here you are updating phantom record so nothing is written to table.

> >>? field->tick ,eof()
> >> next
> >> browse()   // looks like a corrupted index file , try browsing

It's not corrupted but empty. I guess because I haven't try to execute
this code.

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


[Harbour] Harbour compile error

2009-03-19 Thread elart

I'm using

gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)

--
And i get the error below compiling from svn trunk
Thank you
--

make -C main
make[2]: ingresso nella directory «/usr/src/harbour/harbour/source/main»
make[3]: ingresso nella directory
«/usr/src/harbour/harbour/source/main/linux/gcc»
gcc -I. -I../../../../include -Wall -W -O3-c ../../harbour.c
-oharbour.o
gcc -Wall -W -O3 -oharbour harbour.o -L../../../../lib/linux/gcc 
-Wl,--start-group   -lhbcplr  -lhbpp  -lhbcommon -lm -lrt -ldl
-Wl,--end-group
harbour.o: In function `main':
harbour.c:(.text+0xee2): undefined reference to `hb_compMain'
collect2: ld returned 1 exit status
make[3]: *** [harbour] Errore 1
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


[Harbour] xhb parts ported

2009-03-19 Thread Viktor Szakáts
Hi All,
I've 'ported' these xhb files to the state where they compile without
warnings/errors:
xhb/hbserv.c
xhb/trpc.prg
xhb/trpccli.prg
xhb/ttable.prg

I don't know if they work. One piece is definitely missing: hbsrlraw.c,
but this file need some additional rework to avoid internals, it also
uses time support.

Should I upload current state?

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


Re: [Harbour] Re: Updated Instructions for Logo Display (Renato)

2009-03-19 Thread Vailton Renato
Yes Chen! And not only that, but I'm also finishing a series of
articles and tutorials to put on the site. Already the weekend this
will be updated with new content.

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


[Harbour] hbqt can't be built under Ubuntu 8.10

2009-03-19 Thread Lorenzo Fiorini
Just few notes:

1 - include path is /usr/include/qt4
2 - #include  should use /
3 - ‘class QDialog’ has no member named
‘open’  hbqt_qdialog.cppharbour/contrib/hbqtline 122C/C++ 
Problem
   method open is only in qt4.5

I think it's better to state that hbqt requires qt4.5.

Stable distros like RHEL, Suse Enterprise, Debian, Centos may take
time to get qt4.5.
This means that for years hbqt will remain "de facto" a GPL lib.

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


Re: [Harbour] hbqt can't be built under Ubuntu 8.10

2009-03-19 Thread Viktor Szakáts
Thanks for the corrections.

Yes, obviously we don't want to focus on supporting older versions due the
licensing. (well, technically we could, but
it isn't worth the effort as I doubt users would use this lib for open
source development, nor do I think many would
like to buy a license).

I guess it's possible to use QT 4.5 on these Linuxes by
installing QT package downloaded from Nokia, so no need
to wait for the distro makers. (I didn't try)

If anyone knows a way how to check for QT version inside
source files, let us know.

Rgds,
Viktor

On Thu, Mar 19, 2009 at 12:01 PM, Lorenzo Fiorini  wrote:

> Just few notes:
>
> 1 - include path is /usr/include/qt4
> 2 - #include  should use /
> 3 - ‘class QDialog’ has no member named
> ‘open’  hbqt_qdialog.cppharbour/contrib/hbqtline 122
>  C/C++ Problem
>   method open is only in qt4.5
>
> I think it's better to state that hbqt requires qt4.5.
>
> Stable distros like RHEL, Suse Enterprise, Debian, Centos may take
> time to get qt4.5.
> This means that for years hbqt will remain "de facto" a GPL lib.
>
> best regards,
> Lorenzo
> ___
> 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: Updated Instructions for Logo Display (Renato)

2009-03-19 Thread Massimo Belgrano
Good news

2009/3/19 Vailton Renato :
> Yes Chen! And not only that, but I'm also finishing a series of
> articles and tutorials to put on the site. Already the weekend this
> will be updated with new content.
>
> Vailton Renato
> ___
> 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] hbqt can't be built under Ubuntu 8.10

2009-03-19 Thread Viktor Szakáts
Found it, don't bother.

On Thu, Mar 19, 2009 at 12:16 PM, Viktor Szakáts wrote:

> Thanks for the corrections.
>
> Yes, obviously we don't want to focus on supporting older versions due the
> licensing. (well, technically we could, but
> it isn't worth the effort as I doubt users would use this  lib for open
> source development, nor do I think many would
> like to buy a license).
>
> I guess it's possible to use QT 4.5 on these Linuxes by
> installing QT package downloaded from Nokia, so no need
> to wait for the distro makers. (I didn't try)
>
> If anyone knows a way how to check for QT version inside
> source files, let us know.
>
> Rgds,
> Viktor
>
>
> On Thu, Mar 19, 2009 at 12:01 PM, Lorenzo Fiorini <
> lorenzo.fior...@gmail.com> wrote:
>
>> Just few notes:
>>
>> 1 - include path is /usr/include/qt4
>> 2 - #include  should use /
>> 3 - ‘class QDialog’ has no member named
>> ‘open’  hbqt_qdialog.cppharbour/contrib/hbqtline 122
>>  C/C++ Problem
>>   method open is only in qt4.5
>>
>> I think it's better to state that hbqt requires qt4.5.
>>
>> Stable distros like RHEL, Suse Enterprise, Debian, Centos may take
>> time to get qt4.5.
>> This means that for years hbqt will remain "de facto" a GPL lib.
>>
>> best regards,
>> Lorenzo
>> ___
>> 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:[10652] trunk/harbour

2009-03-19 Thread vszakats
Revision: 10652
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10652&view=rev
Author:   vszakats
Date: 2009-03-19 11:28:18 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 12:27 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
  * contrib/xhb/Makefile
  + contrib/xhb/hbserv.h
  + contrib/xhb/hbserv.ch
  + contrib/xhb/trpccli.prg
  + contrib/xhb/hbrpc.ch
  + contrib/xhb/ttable.prg
  + contrib/xhb/trpc.prg
  + contrib/xhb/ttable.ch
  + contrib/xhb/hbserv.c
+ Added few components from xhb. They compile without warnings, 
  but I didn't try any of them.

  * contrib/hbqt/hbqt_qabstractbutton.cpp
  * contrib/hbqt/hbqt_qdialog.cpp
  * contrib/hbqt/hbqt.h
  * contrib/hbqt/Makefile
+ Added QT_VERSION(), QT_VERSION_STR()
+ Added QT version protection.
! Fixed to use forward slashes in #include filenames.
* Changed Linux include dir autodetection.
* Changed autodetection to look for qglobal.h.

  * contrib/rddads/tests/testmg.prg
- Removed unnecessary lines.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/Makefile
trunk/harbour/contrib/hbqt/hbqt.h
trunk/harbour/contrib/hbqt/hbqt_qabstractbutton.cpp
trunk/harbour/contrib/hbqt/hbqt_qdialog.cpp
trunk/harbour/contrib/rddads/tests/testmg.prg
trunk/harbour/contrib/xhb/Makefile

Added Paths:
---
trunk/harbour/contrib/xhb/hbrpc.ch
trunk/harbour/contrib/xhb/hbserv.c
trunk/harbour/contrib/xhb/hbserv.ch
trunk/harbour/contrib/xhb/hbserv.h
trunk/harbour/contrib/xhb/trpc.prg
trunk/harbour/contrib/xhb/trpccli.prg
trunk/harbour/contrib/xhb/ttable.ch
trunk/harbour/contrib/xhb/ttable.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] hbWhat construct

2009-03-19 Thread Viktor Szakáts
Hi,
Setup your Harbour build environment and issue the
'make' or 'mingw32-make' command in the hbwhat dir.

Brgds,
Viktor

On Thu, Mar 19, 2009 at 11:00 AM, Claudio G Torrillo
wrote:

>  Sorry, but of course age does not come alone. ;)
>
>
>
> >> you can build it using the GNU Make system.
>
>
>
> I do not understand how to apply the GNU Make system.
>
>
>
> There are some instructive?
>
> Could someone tell me how to do it?
>
>
>
> TIA.
>
>
>
> Claudio Torrillo
>
>
>
> *De:* harbour-boun...@harbour-project.org [mailto:
> harbour-boun...@harbour-project.org] *En nombre de *Viktor Szakáts
> *Enviado el:* miércoles, 18 de marzo de 2009 04:10 p.m.
>
> *Para:* Harbour Project Main Developer List.
> *Asunto:* Re: [Harbour] hbWhat construct
>
>
>
> Hi Claudio,
>
>
>
>  I need to build the hbWhat library.
>
> What should I do?
>
>
>
> You can find it in contrib/examples/hbwhat/ and you can build
>
> it using the GNU Make system.
>
>
>
>   I need to use some functions of the Windows API, for example :
>
>
>
> GETMODULEFILENAME()
>
>
>
> Use hb_ProgName() instead, which is portable.
>
>
>
>   GetLastError()
>
>
>
> This is implemented in hbwin lib.
>
>
>
> Brgds,
>
> 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


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

2009-03-19 Thread vszakats
Revision: 10653
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10653&view=rev
Author:   vszakats
Date: 2009-03-19 11:59:40 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 12:58 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
  * config/rules.cf
% Removed -ko option as it slightly decreases performance in -gc3 mode.
  (it's better in -gc[0-2] only)

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/config/rules.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] hbWhat construct

2009-03-19 Thread Claudio G Torrillo
Sorry, but of course age does not come alone. ;)

 

>> you can build it using the GNU Make system.

 

I do not understand how to apply the GNU Make system.

 

There are some instructive? 

Could someone tell me how to do it?

 

TIA.

 

Claudio Torrillo

 

De: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] En nombre de Viktor Szakáts
Enviado el: miércoles, 18 de marzo de 2009 04:10 p.m.
Para: Harbour Project Main Developer List.
Asunto: Re: [Harbour] hbWhat construct

 

Hi Claudio,

 

I need to build the hbWhat library.

What should I do?

 

You can find it in contrib/examples/hbwhat/ and you can build 

it using the GNU Make system.

 

I need to use some functions of the Windows API, for example :

 

GETMODULEFILENAME()

 

Use hb_ProgName() instead, which is portable.

 

GetLastError()

 

This is implemented in hbwin lib.

 

Brgds,

Viktor

 

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


Re: [Harbour] Speedtest results

2009-03-19 Thread Viktor Szakáts
Here is mine, just for fun :) [ BTW, Chen, you'd wonder how much faster
Harbour would be with MSVC or MinGW. ]

For sure Clipper is slower, and this can be felt when running
my real-life app. I blamed console output, but it seems it's not just
that. By dropping legacy stuff and using new Harbour techniques
(like hashes), my app startup time went from several seconds
to just instantenious. This got better and better in last half year
due to several Harbour enhancements in multiple areas.

See also an xhb test run (-gc3 ST), plus a Harbour -gc3 ST for
comparison, and also my previous posted XPP.

[ P4 2.6 HT 3GB RAM. Conditions similar to my other recent test results. ]

--- exe size: 271KB (static)
03/18/09 14:07:14 DOS 5.00
Clipper (R) 5.2e Intl. (x216)  (1995.02.07)
THREADS: 0
N_LOOPS: 100
[ T000: empty loop overhead ]...1.10

[ T001: x := L_C ]..0.11
[ T002: x := L_N ]..0.16
[ T003: x := L_D ]..0.11
[ T004: x := S_C ]..0.11
[ T005: x := S_N ]..0.16
[ T006: x := S_D ]..0.11
[ T007: x := M->M_C ]...0.33
[ T008: x := M->M_N ]...0.33
[ T009: x := M->M_D ]...0.33
[ T010: x := M->P_C ]...0.32
[ T011: x := M->P_N ]...0.33
[ T012: x := M->P_D ]...0.33
[ T013: x := F_C ]..1.48
[ T014: x := F_N ]..2.52
[ T015: x := F_D ]..0.87
[ T016: x := o:Args ]...0.93
[ T017: x := o[2] ].0.33
[ T018: round( i / 1000, 2 ) ]..3.84
[ T019: str( i / 1000 ) ]...3.85
[ T020: val( s ) ]..3.02
[ T021: val( a [ i % 16 + 1 ] ) ]...6.20
[ T022: dtos( d - i % 1 ) ].4.45
[ T023: eval( { || i % 16 } ) ].3.79
[ T024: eval( bc := { || i % 16 } ) ]...3.07
[ T025: eval( { |x| x % 16 }, i ) ].3.46
[ T026: eval( bc := { |x| x % 16 }, i ) ]...3.07
[ T027: eval( { |x| f1( x ) }, i ) ]1.98
[ T028: eval( bc := { |x| f1( x ) }, i ) ]..1.54
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ].2.08
[ T030: x := &( "f1(" + str(i) + ")" ) ]...17.47
[ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ]...18.89
[ T032: x := valtype( x ) +  valtype( i ) ].2.36
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ].15.60
[ T034: x := a[ i % 16 + 1 ] == s ].3.35
[ T035: x := a[ i % 16 + 1 ] = s ]..3.89
[ T036: x := a[ i % 16 + 1 ] >= s ].3.96
[ T037: x := a[ i % 16 + 1 ] <= s ].3.95
[ T038: x := a[ i % 16 + 1 ] < s ]..3.90
[ T039: x := a[ i % 16 + 1 ] > s ]..3.90
[ T040: ascan( a, i % 16 ) ]...11.04
[ T041: ascan( a, { |x| x == i % 16 } ) ]..37.29
[ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s,s2,a2 ]9.50
[ T043: x := a ]0.11
[ T044: x := {} ]...0.44
[ T045: f0() ]..0.49
[ T046: f1( i ) ]...0.55
[ T047: f2( c[1...8] ) ]0.60
[ T048: f2( c[1...4] ) ]0.55
[ T049: f2( @c[1...4] ) ]...0.60
[ T050: f2( @c[1...4] ), c2 := c ]..0.77
[ T051: f3( a, a2, s, i, s2, bc, i, n, x ) ]0.93
[ T052: f2( a ) ]...0.55
[ T053: x := f4() ].4.66
[ T054: x := f5() ].0.99
[ T055: x := space(16) ]0.55
[ T056: f_prv( c ) ]1.42

[ total application time: ]...259.30
[ total real time: ].

RE: [Harbour] Speedtest results

2009-03-19 Thread Horodyski Marek (PZUZ)
 



From: Viktor Szakáts [mailto:harbour...@syenar.hu] 
Sent: Wednesday, March 18, 2009 2:39 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] Speedtest results


Here is mine, just for fun :) [ BTW, Chen, you'd wonder how  
much faster Harbour would be with MSVC or MinGW. ] 
 

[...]

 
--- exe size: 586KB (static)
03/18/09 11:10:46 Windows XP 5.1.2600 Service Pack 3
Harbour 1.1.0dev (Rev. 10642) Microsoft Visual C++ 15.0.26569 (32-bit)
THREADS: 0
N_LOOPS: 100
[ T000: empty loop overhead ]...0.05

[ T001: x := L_C ]..0.03
 

[...]

 [ T056: f_prv( c ) ]0.39

[ total application time: ]29.81
[ total real time: ]...29.98

Viktor,
can you present too test with OW on this computer ?
 
Regards,
Marek Horodyski
 
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


Re: [Harbour] Speedtest results

2009-03-19 Thread Viktor Szakáts
Hi Marek,
Yes, I've run tests ST and MT with pocc, ow, bcc, mingw and
icc for comparison,
also included previous Clipper, xpp and xhb tests.

Get them here:
http://www.syenar.hu/harbour/winbench.zip

Machine:
P4 2.6 HT 3GB RAM. No other apps running.
Command lines:
hbmk2 speedtst.prg -gc3 -mt -ospeedtstmt
hbmk2 speedtst.prg -gc3

Ranks based on "Total app time" [sec]:
st-hb-icc  ..27.39
st-hb-msvc ..29.88
st-hb-mingw432 ..40.08
st-hb-mingw433 ..41.91
st-hb-bcc  ..42.81
st-hb-pocc ..42.86
mt-hb-icc  ..48.22
mt-hb-msvc ..49.66
st-hb-ow   ..53.56
mt-hb-mingw433 ..56.94
mt-hb-mingw432 ..57.02
mt-hb-bcc  ..64.47
mt-hb-pocc ..69.09
mt-hb-ow   ..77.03
mt-xpp .108.45
st-xhb-xcc .116.11
st-c52bli  .259.30

Rgds,
Viktor

2009/3/19 Horodyski Marek (PZUZ) 

>
>
>  --
> *From:* Viktor Szakáts [mailto:harbour...@syenar.hu]
> *Sent:* Wednesday, March 18, 2009 2:39 PM
> *To:* Harbour Project Main Developer List.
> *Subject:* Re: [Harbour] Speedtest results
>
> Here is mine, just for fun :) [ BTW, Chen, you'd wonder how  much faster
> Harbour would be with MSVC or MinGW. ]
>
>
> [...]
>
>
> --- exe size: 586KB (static)
>  03/18/09 11:10:46 Windows XP 5.1.2600 Service Pack 3
> Harbour 1.1.0dev (Rev. 10642) Microsoft Visual C++ 15.0.26569 (32-bit)
> THREADS: 0
> N_LOOPS: 100
> [ T000: empty loop overhead ]...0.05
> 
> [ T001: x := L_C ]..0.03
>
>
> [...]
>
>   [ T056: f_prv( c ) ]0.39
> 
> [ total application time: ]29.81
> [ total real time: ]...29.98
>
> Viktor,
> can you present too test with OW on this computer ?
>
> Regards,
> Marek Horodyski
>
>
> ___
> 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] Speedtest results

2009-03-19 Thread Massimo Belgrano
Intresting
in Multi Thread mode these are ranking (harbour vs xbase++)
Compilertime
mt-hb-icc intel   48,22
mt-hb-msvc microsoft 49,66
mt-hb-mingw43256,94
mt-hb-mingw43257,02
mt-hb-bcc borland  64,47
mt-hb-ppoc pelles  69,09
mt-hb-ow watcom  77,03
mt-xpp xbase++ 108,45

In Single Thread mode harbour vs clipper/xharbour.com
Compilertime
st-hb-icc intel  27,39
st-hb-msvc microsoft   29,88
st-hb-mingw432. 40,08
st-hb-mingw433  41,91
st-hb-bcc borland42,81
st-hb-pocc pelles42,86
st-hb-ow watcom 53,56
st-xhb-xcc xharbour com116,11
st-c52bli clipper   259,3


seem that harbour confirm his faster as light!

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


Re: [Harbour] Speedtest results

2009-03-19 Thread Viktor Szakáts
Additional information, ranks by executable size in KB, plus some
conclusions:
st-c52bli271
st-hb-msvc   566
mt-hb-msvc   586
st-hb-bcc629
mt-hb-bcc652
st-hb-pocc   669
mt-hb-pocc   695
st-hb-ow 760
mt-hb-ow 807
st-hb-icc811
mt-hb-icc843
st-xhb-xcc   962
st-hb-mingw432  1076
st-hb-mingw433  1100
mt-hb-mingw432  1136
mt-hb-mingw433  1160

mt-xpp   252 (shared)

For me the clear winner in all technical aspects is MSVC,
creating almost the quickest executables (probably LTCG
can enhance it a bit), and the smallest ones. It's also
gratis, supports x64, unfortunately it's not free software
and not multiplatform at all, but very-well supported by
3rd parties. Next one is MinGW, which is free, open source
and multiplatform, also very well supported, gives the best speed
amongst free tools (and the smallest MT overhead), but it
generates huge executables on Windows. ICC stays being
a curiosity because it's payware, Open Watcom performs
unfortunately poorly in all aspects, I'm not sure what benefit
can it do us for now, maybe in the future, or maybe it's possible
to tweak performance. BCC and POCC have similar middle-ground
performance, both closed-source and gratis, both with bugs
and largely missing support from 3rd parties, uncertain future.
POCC supports ARM and x64, uses standard COFF libs and
all editions are gratis (not just some old versions with weird
licensing), POCC can also generate proper .dlls, so it clearly
wins over BCC.

So my overall rank goes like this:
- MSVC
- MinGW (top rank, if being free software is important)
- POCC

Maybe owatcom, if it can be made faster, but otherwise,
it's unfortunately useless. I see no reason to deal with
BCC at all, since POCC is a better alternative.

Most of these isn't news, what's new is that POCC is a very
good replacement for BCC (if MSVC and MinGW isn't an option),
and the unfortunate results of Open Watcom.

[ Notice that Open Watcom's .dll support in Harbour is broken.
Anyone to help fixing it? ]

Rgds,
Viktor

On Thu, Mar 19, 2009 at 2:14 PM, Viktor Szakáts wrote:

> Hi Marek,
> Yes, I've run tests ST and MT with pocc, ow, bcc, mingw and
> icc for comparison,
> also included previous Clipper, xpp and xhb tests.
>
> Get them here:
> http://www.syenar.hu/harbour/winbench.zip
>
> Machine:
> P4 2.6 HT 3GB RAM. No other apps running.
> Command lines:
> hbmk2 speedtst.prg -gc3 -mt -ospeedtstmt
> hbmk2 speedtst.prg -gc3
>
> Ranks based on "Total app time" [sec]:
> st-hb-icc  ..27.39
> st-hb-msvc ..29.88
> st-hb-mingw432 ..40.08
> st-hb-mingw433 ..41.91
> st-hb-bcc  ..42.81
> st-hb-pocc ..42.86
> mt-hb-icc  ..48.22
> mt-hb-msvc ..49.66
> st-hb-ow   ..53.56
> mt-hb-mingw433 ..56.94
> mt-hb-mingw432 ..57.02
> mt-hb-bcc  ..64.47
> mt-hb-pocc ..69.09
> mt-hb-ow   ..77.03
> mt-xpp .108.45
> st-xhb-xcc .116.11
> st-c52bli  .259.30
>
> Rgds,
> Viktor
>
> 2009/3/19 Horodyski Marek (PZUZ) 
>
>>
>>
>>  --
>> *From:* Viktor Szakáts [mailto:harbour...@syenar.hu]
>> *Sent:* Wednesday, March 18, 2009 2:39 PM
>> *To:* Harbour Project Main Developer List.
>> *Subject:* Re: [Harbour] Speedtest results
>>
>> Here is mine, just for fun :) [ BTW, Chen, you'd wonder how  much faster
>> Harbour would be with MSVC or MinGW. ]
>>
>>
>> [...]
>>
>>
>> --- exe size: 586KB (static)
>>  03/18/09 11:10:46 Windows XP 5.1.2600 Service Pack 3
>> Harbour 1.1.0dev (Rev. 10642) Microsoft Visual C++ 15.0.26569 (32-bit)
>> THREADS: 0
>> N_LOOPS: 100
>> [ T000: empty loop overhead ]...0.05
>> 
>> [ T001: x := L_C ]..0.03
>>
>>
>> [...]
>>
>>   [ T056: f_prv( c ) ]0.39
>> 
>> [ total application time: ]29.81
>> [ total real time: ]...29.98
>>
>> Viktor,
>> can you present too test with OW on this computer ?
>>
>> Regards,
>> Marek Horodyski
>>
>>
>> ___
>> 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] hbqt.lib - How to build

2009-03-19 Thread Pritpal Bedi

Hello Viktor

I have put in batch file:

set HB_INC_QT=C:\devl\Qt\2009.01\qt\include
set HB_DIR_QT=C:\devl\Qt\2009.01\qt

But the make system does not enter contrib/hbqt.

Do I have to build it separately? If yes, what minimum 
I have to do ?

Also you have specified in 
   hbq_base.cpp
but I do not see this in SVN.

Regards
Pritpal Bedi


-- 
View this message in context: 
http://www.nabble.com/QT-and-some-...-tp22580862p22600993.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] hbqt.lib - How to build

2009-03-19 Thread Viktor Szakáts
Hi Pritpal,

I have put in batch file:
>
> set HB_INC_QT=C:\devl\Qt\2009.01\qt\include
> set HB_DIR_QT=C:\devl\Qt\2009.01\qt
>
> But the make system does not enter contrib/hbqt.


That's just generic configuration, for now only the
first line is important and hbqt is fully left out of the
default build so it won't enter automatically.

I could in fact enable it, since it won't be built anyway
unless someone has the QT environment setup.

Do I have to build it separately? If yes, what minimum
> I have to do ?


Same thing I wrote to Claudio just a few e-mails ago.

You need to setup your environment for Harbour build,
and start GNU Make in the hbqt dir. This method works
in every dirs which has a Makefile in it. It's very useful
feature.

The other method is to set this, and do a full Harbour build:
set HB_CONTRIB_ADDONS=hbqt


> Also you have specified in 
>   hbq_base.cpp
> but I do not see this in SVN.


True, sorry.

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


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

2009-03-19 Thread vszakats
Revision: 10654
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10654&view=rev
Author:   vszakats
Date: 2009-03-19 14:34:33 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 15:33 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
  * INSTALL
  * contrib/Makefile
+ Added QT to the mainstream build. See INSTALL how to 
  enable it. We will disable it before release if it will 
  be a build blocker.

  + contrib/hbqt/hbqt_base.cpp
+ Added missing file from previous commit.

  * utils/hbmk2/hbmk2.prg
+ Added -dflag: and -aflag: options.

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

Added Paths:
---
trunk/harbour/contrib/hbqt/hbqt_base.cpp


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] Speedtest results

2009-03-19 Thread frank van nuffel
Hi Viktor, 

To be concluded from your ranks is that POCC is indeed more intersting than 
BCC; is POCC the same as Pelles ISO C Compiler 2.70 
On their website there's only a download for version 5.00.1 - am i missing sth? 

best regards, 

frank 

- Original Message - 
  From: Viktor Szakáts 
  To: Harbour Project Main Developer List. 
  Sent: Thursday, March 19, 2009 3:09 PM
  Subject: Re: [Harbour] Speedtest results


  Additional information, ranks by executable size in KB, plus 
  some conclusions:


  st-c52bli271
  st-hb-msvc   566
  mt-hb-msvc   586
  st-hb-bcc629
  mt-hb-bcc652
  st-hb-pocc   669
  mt-hb-pocc   695
  st-hb-ow 760
  mt-hb-ow 807
  st-hb-icc811
  mt-hb-icc843
  st-xhb-xcc   962
  st-hb-mingw432  1076
  st-hb-mingw433  1100
  mt-hb-mingw432  1136
  mt-hb-mingw433  1160


  mt-xpp   252 (shared)


  For me the clear winner in all technical aspects is MSVC, 
  creating almost the quickest executables (probably LTCG 
  can enhance it a bit), and the smallest ones. It's also 
  gratis, supports x64, unfortunately it's not free software 
  and not multiplatform at all, but very-well supported by 
  3rd parties. Next one is MinGW, which is free, open source 
  and multiplatform, also very well supported, gives the best speed 
  amongst free tools (and the smallest MT overhead), but it 
  generates huge executables on Windows. ICC stays being 
  a curiosity because it's payware, Open Watcom performs 
  unfortunately poorly in all aspects, I'm not sure what benefit 
  can it do us for now, maybe in the future, or maybe it's possible 
  to tweak performance. BCC and POCC have similar middle-ground 
  performance, both closed-source and gratis, both with bugs 
  and largely missing support from 3rd parties, uncertain future. 
  POCC supports ARM and x64, uses standard COFF libs and 
  all editions are gratis (not just some old versions with weird 
  licensing), POCC can also generate proper .dlls, so it clearly 
  wins over BCC.


  So my overall rank goes like this:
  - MSVC
  - MinGW (top rank, if being free software is important)
  - POCC


  Maybe owatcom, if it can be made faster, but otherwise, 
  it's unfortunately useless. I see no reason to deal with 
  BCC at all, since POCC is a better alternative.


  Most of these isn't news, what's new is that POCC is a very 
  good replacement for BCC (if MSVC and MinGW isn't an option), 
  and the unfortunate results of Open Watcom.


  [ Notice that Open Watcom's .dll support in Harbour is broken.
  Anyone to help fixing it? ]


  Rgds,
  Viktor


  On Thu, Mar 19, 2009 at 2:14 PM, Viktor Szakáts  wrote:

Hi Marek,


Yes, I've run tests ST and MT with pocc, ow, bcc, mingw and icc for 
comparison, 
also included previous Clipper, xpp and xhb tests.


Get them here:
http://www.syenar.hu/harbour/winbench.zip


Machine:
P4 2.6 HT 3GB RAM. No other apps running.
Command lines:
hbmk2 speedtst.prg -gc3 -mt -ospeedtstmt
hbmk2 speedtst.prg -gc3


Ranks based on "Total app time" [sec]:
st-hb-icc  ..27.39
st-hb-msvc ..29.88
st-hb-mingw432 ..40.08
st-hb-mingw433 ..41.91
st-hb-bcc  ..42.81
st-hb-pocc ..42.86
mt-hb-icc  ..48.22
mt-hb-msvc ..49.66
st-hb-ow   ..53.56
mt-hb-mingw433 ..56.94
mt-hb-mingw432 ..57.02
mt-hb-bcc  ..64.47
mt-hb-pocc ..69.09
mt-hb-ow   ..77.03
mt-xpp .108.45
st-xhb-xcc .116.11
st-c52bli  .259.30


Rgds,
Viktor


2009/3/19 Horodyski Marek (PZUZ) 




From: Viktor Szakáts [mailto:harbour...@syenar.hu] 
Sent: Wednesday, March 18, 2009 2:39 PM
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] Speedtest results


Here is mine, just for fun :) [ BTW, Chen, you'd wonder how  
much faster Harbour would be with MSVC or MinGW. ] 

  [...]

--- exe size: 586KB (static)
03/18/09 11:10:46 Windows XP 5.1.2600 Service Pack 3
Harbour 1.1.0dev (Rev. 10642) Microsoft Visual C++ 15.0.26569 (32-bit)
THREADS: 0
N_LOOPS: 100
[ T000: empty loop overhead ]...0.05

[ T001: x := L_C ]..0.03

  [...]
 [ T056: f_prv( c ) ]0.39

[ total application time: ]29.81
[ total real time: ]...29.98
  Viktor,
  can you present too test with OW on this computer ?

  Regards,
  Marek Horodyski



  ___

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

2009-03-19 Thread Przemyslaw Czerpak
On Thu, 19 Mar 2009, vszak...@users.sourceforge.net wrote:
> 2009-03-19 12:58 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
>   * config/rules.cf
> % Removed -ko option as it slightly decreases performance in -gc3 mode.
>   (it's better in -gc[0-2] only)

Viktor,
Please compile speedtst with -gc2 and safe (f.e. using MSVC and MINGW)
and safe your results.
Then recompile whole core Harbour code with -gc2 instead of -gc3 then
once again rebuild speedtst with -gc2 and compare results.
Use static speedtst builds only.
If possible please send the results here.

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


Re: [Harbour] Speedtest results

2009-03-19 Thread Viktor Szakáts
Hi Frank,
On Thu, Mar 19, 2009 at 3:44 PM, frank van nuffel <
clipper5_...@versateladsl.be> wrote:

>  To be concluded from your ranks is that POCC is indeed more intersting
> than BCC; is POCC the same as Pelles ISO C Compiler 2.70
> On their website there's only a download for version 5.00.1 - am i missing
> sth?
>

Yes, pocc is Pelles C. It has different versions, the one used
(and probably bought source/distribution licenses) by xhb is an
old version, numbered 2.70 and named xcc by xhb team, the
newest version is 5.00.1, which is a free download for everyone,
and this what I used for these tests.

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


Re: [Harbour] hb_mouse_Col()

2009-03-19 Thread Lorenzo Fiorini
On Thu, Mar 19, 2009 at 3:57 PM, Enrico Maria Giordano
 wrote:

> How about the function hb_mouse_Col()? I don't know what it is for but an
> italian colleague is trying to use it and get unresolved external.

Could it be hb_mouseCol()?

Here are the hb_mouseXYZ funcs I found:

extern HB_EXPORT BOOL   hb_mouseIsPresent( void );
extern HB_EXPORT BOOL   hb_mouseGetCursor( void );
extern HB_EXPORT void   hb_mouseSetCursor( BOOL bVisible );
extern HB_EXPORT inthb_mouseCol( void );
extern HB_EXPORT inthb_mouseRow( void );
extern HB_EXPORT void   hb_mouseGetPos( int * piRow, int * piCol );
extern HB_EXPORT void   hb_mouseSetPos( int iRow, int iCol );
extern HB_EXPORT void   hb_mouseSetBounds( int iTop, int iLeft,
int iBottom, int iRight );
extern HB_EXPORT void   hb_mouseGetBounds( int * piTop, int *
piLeft, int * piBottom, int * piRight );
extern HB_EXPORT inthb_mouseStorageSize( void );
extern HB_EXPORT void   hb_mouseSaveState( BYTE * pBuffer );
extern HB_EXPORT void   hb_mouseRestoreState( BYTE * pBuffer );
extern HB_EXPORT inthb_mouseGetDoubleClickSpeed( void );
extern HB_EXPORT void   hb_mouseSetDoubleClickSpeed( int iSpeed );
extern HB_EXPORT inthb_mouseCountButton( void );
extern HB_EXPORT BOOL   hb_mouseButtonState( int iButton );
extern HB_EXPORT BOOL   hb_mouseButtonPressed( int iButton, int *
piRow, int * piCol );
extern HB_EXPORT BOOL   hb_mouseButtonReleased( int iButton, int *
piRow, int * piCol );
extern HB_EXPORT inthb_mouseReadKey( int iEventMask );

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


Re: [Harbour] Speedtest results

2009-03-19 Thread Enrico Maria Giordano


-Messaggio Originale- 
Da: "Viktor Szakáts" 

A: "Harbour Project Main Developer List." 
Data invio: giovedì 19 marzo 2009 15.09
Oggetto: Re: [Harbour] Speedtest results



POCC can also generate proper .dlls, so it clearly
wins over BCC.


I don't know what do you exactly mean with "proper .dlls" but I have no 
problem to make DLLs using BCC.


EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic 


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


Re: [Harbour] Speedtest results

2009-03-19 Thread Massimo Belgrano
I propose to renato copy this post in harbour website
so it will be intresting for all harbour newbbies
2009 Speed Comparision

2009/3/19 Viktor Szakáts :
> Additional information, ranks by executable size in KB, plus
> some conclusions:
> st-c52bli        271
> st-hb-msvc       566
> mt-hb-msvc       586
> st-hb-bcc        629
> mt-hb-bcc        652
> st-hb-pocc       669
> mt-hb-pocc       695
> st-hb-ow         760
> mt-hb-ow         807
> st-hb-icc        811
> mt-hb-icc        843
> st-xhb-xcc       962
> st-hb-mingw432  1076
> st-hb-mingw433  1100
> mt-hb-mingw432  1136
> mt-hb-mingw433  1160
> mt-xpp           252 (shared)
> For me the clear winner in all technical aspects is MSVC,
> creating almost the quickest executables (probably LTCG
> can enhance it a bit), and the smallest ones. It's also
> gratis, supports x64, unfortunately it's not free software
> and not multiplatform at all, but very-well supported by
> 3rd parties. Next one is MinGW, which is free, open source
> and multiplatform, also very well supported, gives the best speed
> amongst free tools (and the smallest MT overhead), but it
> generates huge executables on Windows. ICC stays being
> a curiosity because it's payware, Open Watcom performs
> unfortunately poorly in all aspects, I'm not sure what benefit
> can it do us for now, maybe in the future, or maybe it's possible
> to tweak performance. BCC and POCC have similar middle-ground
> performance, both closed-source and gratis, both with bugs
> and largely missing support from 3rd parties, uncertain future.
> POCC supports ARM and x64, uses standard COFF libs and
> all editions are gratis (not just some old versions with weird
> licensing), POCC can also generate proper .dlls, so it clearly
> wins over BCC.
> So my overall rank goes like this:
> - MSVC
> - MinGW (top rank, if being free software is important)
> - POCC
> Maybe owatcom, if it can be made faster, but otherwise,
> it's unfortunately useless. I see no reason to deal with
> BCC at all, since POCC is a better alternative.
> Most of these isn't news, what's new is that POCC is a very
> good replacement for BCC (if MSVC and MinGW isn't an option),
> and the unfortunate results of Open Watcom.
> [ Notice that Open Watcom's .dll support in Harbour is broken.
> Anyone to help fixing it? ]
> Rgds,
> Viktor
> On Thu, Mar 19, 2009 at 2:14 PM, Viktor Szakáts 
> wrote:
>>
>> Hi Marek,
>> Yes, I've run tests ST and MT with pocc, ow, bcc, mingw and
>> icc for comparison,
>> also included previous Clipper, xpp and xhb tests.
>> Get them here:
>> http://www.syenar.hu/harbour/winbench.zip
>> Machine:
>> P4 2.6 HT 3GB RAM. No other apps running.
>> Command lines:
>> hbmk2 speedtst.prg -gc3 -mt -ospeedtstmt
>> hbmk2 speedtst.prg -gc3
>> Ranks based on "Total app time" [sec]:
>> st-hb-icc      ..27.39
>> st-hb-msvc     ..29.88
>> st-hb-mingw432 ..40.08
>> st-hb-mingw433 ..41.91
>> st-hb-bcc      ..42.81
>> st-hb-pocc     ..42.86
>> mt-hb-icc      ..48.22
>> mt-hb-msvc     ..49.66
>> st-hb-ow       ..53.56
>> mt-hb-mingw433 ..56.94
>> mt-hb-mingw432 ..57.02
>> mt-hb-bcc      ..64.47
>> mt-hb-pocc     ..69.09
>> mt-hb-ow       ..77.03
>> mt-xpp         .108.45
>> st-xhb-xcc     .116.11
>> st-c52bli      .259.30
>> Rgds,
>> Viktor
>> 2009/3/19 Horodyski Marek (PZUZ) 
>>>
>>>
>>>
>>> 
>>> From: Viktor Szakáts [mailto:harbour...@syenar.hu]
>>> Sent: Wednesday, March 18, 2009 2:39 PM
>>> To: Harbour Project Main Developer List.
>>> Subject: Re: [Harbour] Speedtest results
>>>
>>> Here is mine, just for fun :) [ BTW, Chen, you'd wonder how
>>> much faster Harbour would be with MSVC or MinGW. ]
>>>
>>>
>>> [...]
>>>
>>>
>>> --- exe size: 586KB (static)
>>> 03/18/09 11:10:46 Windows XP 5.1.2600 Service Pack 3
>>> Harbour 1.1.0dev (Rev. 10642) Microsoft Visual C++ 15.0.26569 (32-bit)
>>> THREADS: 0
>>> N_LOOPS: 100
>>> [ T000: empty loop overhead ]...0.05
>>> 
>>> [ T001: x := L_C ]..0.03
>>>
>>>
>>> [...]
>>>
>>>  [ T056: f_prv( c ) ]0.39
>>> 
>>> [ total application time: ]29.81
>>> [ total real time: ]...29.98
>>>
>>> Viktor,
>>> can you present too test with OW on this computer ?
>>>
>>> Regards,
>>> Marek Horodyski
>>>
>>> ___
>>> 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

Re: [Harbour] Speedtest results

2009-03-19 Thread frank van nuffel
Thank you, Viktor, for confirming 

btw, my ISP account will expire within a few days, and i will unsubscribe from 
the Harbour list, for perhaps a year or longer, to remain offline; meanwhile i 
wish everyone here even more success with the results that are now already 
excellent; 

take care and all the best, 

frank 

  - Original Message - 
  From: Viktor Szakáts 
  To: Harbour Project Main Developer List. 
  Sent: Thursday, March 19, 2009 3:58 PM
  Subject: Re: [Harbour] Speedtest results


  Hi Frank,


  On Thu, Mar 19, 2009 at 3:44 PM, frank van nuffel 
 wrote:

To be concluded from your ranks is that POCC is indeed more intersting than 
BCC; is POCC the same as Pelles ISO C Compiler 2.70
On their website there's only a download for version 5.00.1 - am i missing 
sth?


  Yes, pocc is Pelles C. It has different versions, the one used 
  (and probably bought source/distribution licenses) by xhb is an 
  old version, numbered 2.70 and named xcc by xhb team, the 
  newest version is 5.00.1, which is a free download for everyone, 
  and this what I used for these tests.


  Brgds,
  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] Speedtest results

2009-03-19 Thread Viktor Szakáts
>
> POCC can also generate proper .dlls, so it clearly
>> wins over BCC.
>>
>
> I don't know what do you exactly mean with "proper .dlls" but I have no
> problem to make DLLs using BCC.


Proper means exported symbols don't have a Borland proprietary
underscore prepended to them.

If you stay inside the Borland world and master implib with or
without -a switch you're safe (with surprises from time to time).
Otherwise it's a problem.

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


[Harbour] hb_mouse_Col()

2009-03-19 Thread Enrico Maria Giordano
How about the function hb_mouse_Col()? I don't know what it is for but an 
italian colleague is trying to use it and get unresolved external.


EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic 


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


Re: [Harbour] Speedtest results

2009-03-19 Thread Viktor Szakáts
>
> btw, my ISP account will expire within a few days, and i will unsubscribe
> from the Harbour list, for perhaps a year or longer, to remain offline;
> meanwhile i wish everyone here even more success with the results that are
> now
>

I envy you :)


> already excellent;
>
take care and all the best,
>

I hope to see you back soon. Wishing you a very nice offline time.

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


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

2009-03-19 Thread vouchcac
Revision: 10655
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10655&view=rev
Author:   vouchcac
Date: 2009-03-19 15:18:05 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 08:10 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * harbour/contrib/hbqt/hbqt.h
  * harbour/contrib/hbqt/hbqt_qdialog.cpp
  * harbour/contrib/hbqt/hbqt_qabstractbutton.cpp
  + harbour/contrib/hbqt/hbqt_qabstractitemview.cpp
  + harbour/contrib/hbqt/hbqt_qabstractprintdialog.cpp
  + harbour/contrib/hbqt/hbqt_qwidget.cpp
! Formatting and new additions.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/Makefile
trunk/harbour/contrib/hbqt/hbqt.h
trunk/harbour/contrib/hbqt/hbqt_qabstractbutton.cpp
trunk/harbour/contrib/hbqt/hbqt_qdialog.cpp

Added Paths:
---
trunk/harbour/contrib/hbqt/hbqt_qabstractitemview.cpp
trunk/harbour/contrib/hbqt/hbqt_qabstractprintdialog.cpp
trunk/harbour/contrib/hbqt/hbqt_qwidget.cpp


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] hb_mouse_Col()

2009-03-19 Thread Francesco Saverio Giudice

Hi,

or could it be MCol() as from CA Clipper 5.3 and as defined in
harbour/source/rtl/mouse53.c ?

Other mouse functions are:
MPRESENT
MHIDE
MSHOW
MSETCURSOR
MROW
MSETPOS
MLEFTDOWN
MRIGHTDOWN
MDBLCLK
MSAVESTATE
MRESTSTATE
MSETBOUNDS
HB_MMIDDLEDOWN

Obviously they are redirected to below harbour function list.

Best regards,
Francesco


Il 19/03/2009 16.04, Lorenzo Fiorini ha scritto:

On Thu, Mar 19, 2009 at 3:57 PM, Enrico Maria Giordano
 wrote:


How about the function hb_mouse_Col()? I don't know what it is for but an
italian colleague is trying to use it and get unresolved external.


Could it be hb_mouseCol()?

Here are the hb_mouseXYZ funcs I found:

extern HB_EXPORT BOOL   hb_mouseIsPresent( void );
extern HB_EXPORT BOOL   hb_mouseGetCursor( void );
extern HB_EXPORT void   hb_mouseSetCursor( BOOL bVisible );
extern HB_EXPORT inthb_mouseCol( void );
extern HB_EXPORT inthb_mouseRow( void );
extern HB_EXPORT void   hb_mouseGetPos( int * piRow, int * piCol );
extern HB_EXPORT void   hb_mouseSetPos( int iRow, int iCol );
extern HB_EXPORT void   hb_mouseSetBounds( int iTop, int iLeft,
int iBottom, int iRight );
extern HB_EXPORT void   hb_mouseGetBounds( int * piTop, int *
piLeft, int * piBottom, int * piRight );
extern HB_EXPORT inthb_mouseStorageSize( void );
extern HB_EXPORT void   hb_mouseSaveState( BYTE * pBuffer );
extern HB_EXPORT void   hb_mouseRestoreState( BYTE * pBuffer );
extern HB_EXPORT inthb_mouseGetDoubleClickSpeed( void );
extern HB_EXPORT void   hb_mouseSetDoubleClickSpeed( int iSpeed );
extern HB_EXPORT inthb_mouseCountButton( void );
extern HB_EXPORT BOOL   hb_mouseButtonState( int iButton );
extern HB_EXPORT BOOL   hb_mouseButtonPressed( int iButton, int *
piRow, int * piCol );
extern HB_EXPORT BOOL   hb_mouseButtonReleased( int iButton, int *
piRow, int * piCol );
extern HB_EXPORT inthb_mouseReadKey( int iEventMask );

best regards,
Lorenzo
___
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] Speedtest results

2009-03-19 Thread Enrico Maria Giordano


-Messaggio Originale- 
Da: "Viktor Szakáts" 

A: "Harbour Project Main Developer List." 
Data invio: giovedì 19 marzo 2009 16.15
Oggetto: Re: [Harbour] Speedtest results



Proper means exported symbols don't have a Borland proprietary
underscore prepended to them.

If you stay inside the Borland world and master implib with or
without -a switch you're safe (with surprises from time to time).
Otherwise it's a problem.


Ok, thank you.

EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic 


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


Re: [Harbour] hb_mouse_Col()

2009-03-19 Thread Enrico Maria Giordano


-Messaggio Originale- 
Da: "Lorenzo Fiorini" 

A: "Harbour Project Main Developer List." 
Data invio: giovedì 19 marzo 2009 16.04
Oggetto: Re: [Harbour] hb_mouse_Col()



Could it be hb_mouseCol()?


Most likely, thank you.

EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic 


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


Re: [Harbour] hb_mouse_Col()

2009-03-19 Thread Lorenzo Fiorini
On Thu, Mar 19, 2009 at 4:29 PM, Enrico Maria Giordano
 wrote:

> Most likely, thank you.

I've also found this:

2007-12-07 10:43 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/include/hbgtcore.h
  * harbour/source/rtl/hbgtcore.c
  * harbour/source/rtl/gtapi.c
  * harbour/source/rtl/inkeyapi.c
  * harbour/source/rtl/mouseapi.c
- removed hb_gt_*(), hb_inkey_*(), hb_mouse_*() functions
+ implemented HB_GTSELF_*() functions and changed HB_GTSUPER_*()
  ones to operate on GT context passed ad 1-st parameter.
  Now GT API allows to create many GTs working simultaneously
+ added hb_gt_Base() core function which returns GT context
  it will be extended soon to allow using many GT contexts,
  setting thread default one or switch between them using some
  .prg function.

so maybe that function existed in the past.

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


Re: [Harbour] hb_mouse_Col()

2009-03-19 Thread Enrico Maria Giordano


-Messaggio Originale- 
Da: "Francesco Saverio Giudice" 

A: "Harbour Project Main Developer List." 
Data invio: giovedì 19 marzo 2009 16.19
Oggetto: Re: [Harbour] hb_mouse_Col()



Hi,

or could it be MCol() as from CA Clipper 5.3 and as defined in
harbour/source/rtl/mouse53.c ?


No, I'm starting to think that he mixed old and new libraries.

EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic 


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


Re: [Harbour] hb_mouse_Col()

2009-03-19 Thread Enrico Maria Giordano


-Messaggio Originale- 
Da: "Lorenzo Fiorini" 

A: "Harbour Project Main Developer List." 
Data invio: giovedì 19 marzo 2009 16.31
Oggetto: Re: [Harbour] hb_mouse_Col()



I've also found this:


Thank you.

EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic 


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


[Harbour] SF.net SVN: harbour-project:[10656] trunk/harbour/contrib/hbqt/hbqt.h

2009-03-19 Thread vouchcac
Revision: 10656
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10656&view=rev
Author:   vouchcac
Date: 2009-03-19 16:20:04 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 09:20 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * harbour/contrib/hbqt/hbqt.h
! Fix to last commit.

Modified Paths:
--
trunk/harbour/contrib/hbqt/hbqt.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


[Harbour] Compile Error

2009-03-19 Thread Pritpal Bedi

Hi

C:\harbour\source\vm\maindllp>if not exist ..\..\..\lib\win\msvc\. md
..\..\..\lib\win\msvc 
make.exe[4]: Entering directory `C:/harbour/source/vm/maindllp/win/msvc'
cl.exe -nologo -W4 -wd4127 -Gs -I. -I../../../../../include -TP -Ot2b1
-EHs-c- -MT   -DHB_DYNLIB  -c ../../../maindllp.c -Fomaindllp.obj
maindllp.c
../../../maindllp.c(112) : error C2059: syntax error :
'__declspec(dllexport)'
make.exe[4]: *** [maindllp.obj] Error 2


It was clean install build

May be some params are changed I am unable to recall.

Regards
Pritpal Bedi
-- 
View this message in context: 
http://www.nabble.com/Compile-Error-tp22603984p22603984.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] Speedtest results

2009-03-19 Thread Massimo Belgrano
How using hashes or other technique you have the smallest startup
times with harbour compiled app?
Probably do you use msvc as compiler because it generate smallest and
fastest executable

2009/3/18 Viktor Szakáts :
> Here is mine, just for fun :) [ BTW, Chen, you'd wonder how
> much faster Harbour would be with MSVC or MinGW. ]
> For sure Clipper is slower, and this can be felt when running
> my real-life app. I blamed console output, but it seems it's not just
> that. By dropping legacy stuff and using new Harbour techniques
> (like hashes), my app startup time went from several seconds
> to just instantenious. This got better and better in last half year
> due to several Harbour enhancements in multiple areas.
> See also an xhb test run (-gc3 ST), plus a Harbour -gc3 ST for
> comparison, and also my previous posted XPP.

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


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

2009-03-19 Thread vszakats
Revision: 10657
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10657&view=rev
Author:   vszakats
Date: 2009-03-19 17:08:33 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 18:06 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
  * source/vm/maindll.c
  * source/vm/maindllp.c
! Fixed placement of HB_EXPORT in declaration.

  * contrib/hbmysql/tmysql.prg
* Reformatting (heavy). Minor optimizations along the way. Pls test.
! S&R typo fixed.
+ Added lFormat parameter to FieldDec() method.
  Submitted by Mitja Podgornik.

  * contrib/xhb/Makefile
  + contrib/xhb/fparse.c
+ Added part from xhb RTL.
  (pls review changed PHB_ITEM usage)

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbmysql/tmysql.prg
trunk/harbour/contrib/xhb/Makefile
trunk/harbour/source/vm/maindll.c
trunk/harbour/source/vm/maindllp.c

Added Paths:
---
trunk/harbour/contrib/xhb/fparse.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


[Harbour] Re: TIMESTAMP/DATETIME conversions

2009-03-19 Thread Mario Simoes Filho

Hi Przemyslaw Czerpak

I would like to make a suggestion for the function dTOc (), a second 
parameter with the output format, something like this:

? dtoc (date (), "MM-DD-)
? dtoc (date (), "MM-)
? dtoc (date (), "-DD)

I did this on xHarbour, follows the source:

#pragma BEGINDUMP
#include 
#include "hbapi.h"
#include "hbapierr.h"
#include "hbapiitm.h"
#include "hbset.h"
#include "hbdate.h"

HB_FUNC(  DTOC )
{
   if( ISDATE( 1 ) )
   {
  char szDate[9];
  char szFormatted[ 11 ];
  hb_retc( hb_dateFormat( hb_pardsbuff( szDate, 1 ), szFormatted, 
(ISCHAR(2)?hb_parcx(2):hb_set.HB_SET_DATEFORMAT) ) );

   }
else
{
   hb_errRT_BASE_SubstR( EG_ARG, 1118, NULL, "DTOC", 1, 
hb_paramError( 1 ) );

}
 }

#pragma ENDDUMP





Przemyslaw Czerpak escreveu:

Hi All,

I would like to ask VFP users to give me an information about some
timestamp/datetime transformations in this language.
I'm interesting in existing functions transform pictures, etc.
I'm ready to commit timestamp support to HVM but I do not want
to reinvent the wheel and create corresponding functions which
will return different results then in other xbase languages.
In longer terms such differences creates serious problems, f.e.
when you try to share tables and indexes.
xHarbour has set of functions to operate on timestamp values but
I do not know if they exactly replicates VFP results. I'm interesting
mostly on functions like:
   TTOS()
   TTOC()
   CTOS()
   CTOT()
   
f.e. what is the results of this code:
   proc main()
  ? TTOS( {^ 2009/03/31 11:34:56.123 PM } )
  ? TTOC( {^ 2009/03/31 11:34:56.123 PM } )
   return

I'm also interesting also in picture modifiers which are used for
timestamp/datetime values in TRANSFORM() function and GET system.
Of course if any exists.

If someone has some knowledge about timestamp/datetime type conversions
in other xbase languages then I would like to hear about them too.

I hope that you can help. Otherwise I will have to make some arbitrary
decisions myself.

best regards,
Przemek


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


Re: [Harbour] Speedtest results

2009-03-19 Thread Viktor Szakáts
>
> How using hashes or other technique you have the smallest startup
> times with harbour compiled app?
> Probably do you use msvc as compiler because it generate smallest and
> fastest executable


Yes, I'm using MSVC on Windows, with MinGW as a backup.

The other question is very generic and really falls out of scope
of this mailing list to discuss the hundreds of changes that can
be made from Clipper to Harbour to run things more efficiently.
Not only for startup time of course.

Hashes in particular can search more quickly than AScan() or
even sorted array manual search methods.

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


Re: [Harbour] Re: TIMESTAMP/DATETIME conversions

2009-03-19 Thread Przemyslaw Czerpak
On Thu, 19 Mar 2009, Mario Simoes Filho wrote:

Hi,

> I would like to make a suggestion for the function dTOc (), a second 
> parameter with the output format, something like this:
> ? dtoc (date (), "MM-DD-)
> ? dtoc (date (), "MM-)
> ? dtoc (date (), "-DD)

I already added such parameters to HB_DTOC() and HB_TTOC() with
other timestamp modifications.

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:[10657] trunk/harbour

2009-03-19 Thread Przemyslaw Czerpak
On Thu, 19 Mar 2009, vszak...@users.sourceforge.net wrote:

Hi,

> ---
> 2009-03-19 18:06 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
>   * source/vm/maindll.c
>   * source/vm/maindllp.c
> ! Fixed placement of HB_EXPORT in declaration.

Which compiler needs separate declaration for DllEntryPoint()
with HB_EXPORT flag?
Maybe we can simply remove it?

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:[10657] trunk/harbour

2009-03-19 Thread Viktor Szakáts
I've added it for one of them... maybe it was ICC, or MSVC, otherwise it
warned that the entry point won't be exported.

Brgds,
Viktor

On Thu, Mar 19, 2009 at 6:32 PM, Przemyslaw Czerpak wrote:

> On Thu, 19 Mar 2009, vszak...@users.sourceforge.net wrote:
>
> Hi,
>
> > ---
> > 2009-03-19 18:06 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
> >   * source/vm/maindll.c
> >   * source/vm/maindllp.c
> > ! Fixed placement of HB_EXPORT in declaration.
>
> Which compiler needs separate declaration for DllEntryPoint()
> with HB_EXPORT flag?
> Maybe we can simply remove it?
>
> best regards,
> Przemek
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


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

2009-03-19 Thread Przemyslaw Czerpak
On Thu, 19 Mar 2009, Szak�ts Viktor wrote:
> I've added it for one of them... maybe it was ICC, or MSVC, otherwise it
> warned that the entry point won't be exported.

OK. Only one note:

   BOOL HB_EXPORT WINAPI DllEntryPoint( HINSTANCE hInstance, DWORD fdwReason, 
PVOID pvReserved );

always add HB_EXPORT before return type otherwise you may have
unexpected behavior, f.e.:

MYTYPE HBEXPORT func( void );

can be compiled if MYTYPE is defined as:
   typdef char * MYTYPE
but if you make:
   #define MYTYPE char *
then some compiler refuse compilation because they do not accept export
function attribute after * in return type.

So this should be changed to:

   HB_EXPORT BOOL WINAPI DllEntryPoint( HINSTANCE hInstance, DWORD fdwReason, 
PVOID pvReserved );

AFAIK it's the only one portable method which will not cause some
wrong results when different compilers are used.
And if possible please check if setting attribute directly in function is
not enough in this case.
In summary it's exception.

HB_EXPORT BOOL WINAPI DllEntryPoint( HINSTANCE hInstance, DWORD fdwReason, 
PVOID pvReserved )
{
   ...
}

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:[10657] trunk/harbour

2009-03-19 Thread Viktor Szakáts
Thanks for your notes.
I'll move HB_EXPORT to the beginning of declaration.

Truth is that I totally forgot which scenario and which
compiler was the complaining one, so I cannot test
if HB_EXPORT is enough in the definition. I remember
the warning said that a 'declaration' was missing, so
that's what I did.

I hope someone can jump in for these .dll things, as
it's still a grey area for me. My last thought, but I
didn't continue experimenting, was that pcode .dlls
will need different liblist in hbmk2 in order to succeed.
But the whole thing is trial and error for me.

Rdgs,
Viktor

On Thu, Mar 19, 2009 at 6:49 PM, Przemyslaw Czerpak wrote:

> On Thu, 19 Mar 2009, Szak�ts Viktor wrote:
> > I've added it for one of them... maybe it was ICC, or MSVC, otherwise it
> > warned that the entry point won't be exported.
>
> OK. Only one note:
>
>   BOOL HB_EXPORT WINAPI DllEntryPoint( HINSTANCE hInstance, DWORD
> fdwReason, PVOID pvReserved );
>
> always add HB_EXPORT before return type otherwise you may have
> unexpected behavior, f.e.:
>
> MYTYPE HBEXPORT func( void );
>
> can be compiled if MYTYPE is defined as:
>   typdef char * MYTYPE
> but if you make:
>   #define MYTYPE char *
> then some compiler refuse compilation because they do not accept export
> function attribute after * in return type.
>
> So this should be changed to:
>
>   HB_EXPORT BOOL WINAPI DllEntryPoint( HINSTANCE hInstance, DWORD
> fdwReason, PVOID pvReserved );
>
> AFAIK it's the only one portable method which will not cause some
> wrong results when different compilers are used.
> And if possible please check if setting attribute directly in function is
> not enough in this case.
> In summary it's exception.
>
> HB_EXPORT BOOL WINAPI DllEntryPoint( HINSTANCE hInstance, DWORD fdwReason,
> PVOID pvReserved )
> {
>   ...
> }
>
> best regards,
> Przemek
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


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

2009-03-19 Thread vszakats
Revision: 10658
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10658&view=rev
Author:   vszakats
Date: 2009-03-19 18:13:33 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 19:05 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
  * source/vm/maindll.c
  * source/vm/maindllp.c
! HB_EXPORT moved to beginning of declaration.

  * contrib/hbmysql/tmysql.prg
  * contrib/hbmysql/tsqlbrw.prg
* More formatting.

  * xhb/Makefile
  * xhb/hbcompat.ch
  + xhb/xhbis.c
  + xhb/xhbscr.c
  + xhb/xhbat.c
  + xhb/txtline.c
  + xhb/dumpvar.prg
+ Added xhb remaining stuff:
  ISALNUM()
  ISSPACE()
  ISXDIGIT()
  ISCNTRL()
  ISGRAPH()
  ISPRINT()
  ISPUNCT()
  ISASCII()
  SCROLLFIXED()
  ATSKIPSTRINGS()
  HB_TABEXPAND()
  HB_READLINE()
  __OutDebug()
  HB_DumpVar()
  HBCONSOLELOCK() (emulation, might be wrong)
  HBCONSOLEUNLOCK() (emulation, might be wrong)
; Please review, my only goal was to make them compile.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbmysql/tmysql.prg
trunk/harbour/contrib/hbmysql/tsqlbrw.prg
trunk/harbour/contrib/xhb/Makefile
trunk/harbour/contrib/xhb/hbcompat.ch
trunk/harbour/source/vm/maindll.c
trunk/harbour/source/vm/maindllp.c

Added Paths:
---
trunk/harbour/contrib/xhb/dumpvar.prg
trunk/harbour/contrib/xhb/txtline.c
trunk/harbour/contrib/xhb/xhbat.c
trunk/harbour/contrib/xhb/xhbis.c
trunk/harbour/contrib/xhb/xhbscr.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


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

2009-03-19 Thread vszakats
Revision: 10659
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10659&view=rev
Author:   vszakats
Date: 2009-03-19 18:50:21 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 19:49 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
  * xhb/Makefile
  * xhb/dumpvar.prg
  + xhb/decode.prg
+ Added HB_DECODE().
* Syntax adapted for Harbour.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/xhb/Makefile
trunk/harbour/contrib/xhb/dumpvar.prg

Added Paths:
---
trunk/harbour/contrib/xhb/decode.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:[10660] trunk/harbour

2009-03-19 Thread vszakats
Revision: 10660
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10660&view=rev
Author:   vszakats
Date: 2009-03-19 19:37:56 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-19 20:37 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
  * contrib/xhb/Makefile
  + contrib/xhb/stream.prg
  + contrib/xhb/traceprg.prg
  + contrib/xhb/xhberr.prg
  * contrib/xhb/xhbfunc.c
+ More ports: HB_CMDARGARGV(), HB_VMMODE(), TRACELOG(), Stream classes,
  xhb errorsys (activate by calling xhb_ErrorSys())

  * contrib/xhb/fparse.c
  * contrib/xhb/dumpvar.prg
  * contrib/xhb/xhbat.c
  * contrib/xhb/ttable.prg
  * contrib/xhb/txtline.c
* Fixes/cleanups to previous ports.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/xhb/Makefile
trunk/harbour/contrib/xhb/dumpvar.prg
trunk/harbour/contrib/xhb/fparse.c
trunk/harbour/contrib/xhb/ttable.prg
trunk/harbour/contrib/xhb/txtline.c
trunk/harbour/contrib/xhb/xhbat.c
trunk/harbour/contrib/xhb/xhbfunc.c

Added Paths:
---
trunk/harbour/contrib/xhb/stream.prg
trunk/harbour/contrib/xhb/traceprg.prg
trunk/harbour/contrib/xhb/xhberr.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] hbWhat construct

2009-03-19 Thread Viktor Szakáts
Hi Claudio,
BTW, we can copy lighter functions from hbwhat to
hbwin (which is Harbour's official Windows lib), just
post the functions you'd need.

Brgds,
Viktor

On Thu, Mar 19, 2009 at 12:00 PM, Viktor Szakáts wrote:

> Hi,
> Setup your Harbour build environment and issue the
> 'make' or 'mingw32-make' command in the hbwhat dir.
>
> Brgds,
> Viktor
>
> On Thu, Mar 19, 2009 at 11:00 AM, Claudio G Torrillo <
> clips...@yahoo.com.ar> wrote:
>
>>  Sorry, but of course age does not come alone. ;)
>>
>>
>>
>> >> you can build it using the GNU Make system.
>>
>>
>>
>> I do not understand how to apply the GNU Make system.
>>
>>
>>
>> There are some instructive?
>>
>> Could someone tell me how to do it?
>>
>>
>>
>> TIA.
>>
>>
>>
>> Claudio Torrillo
>>
>>
>>
>> *De:* harbour-boun...@harbour-project.org [mailto:
>> harbour-boun...@harbour-project.org] *En nombre de *Viktor Szakáts
>> *Enviado el:* miércoles, 18 de marzo de 2009 04:10 p.m.
>>
>> *Para:* Harbour Project Main Developer List.
>> *Asunto:* Re: [Harbour] hbWhat construct
>>
>>
>>
>> Hi Claudio,
>>
>>
>>
>>  I need to build the hbWhat library.
>>
>> What should I do?
>>
>>
>>
>> You can find it in contrib/examples/hbwhat/ and you can build
>>
>> it using the GNU Make system.
>>
>>
>>
>>   I need to use some functions of the Windows API, for example :
>>
>>
>>
>> GETMODULEFILENAME()
>>
>>
>>
>> Use hb_ProgName() instead, which is portable.
>>
>>
>>
>>   GetLastError()
>>
>>
>>
>> This is implemented in hbwin lib.
>>
>>
>>
>> Brgds,
>>
>> 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:[10653] trunk/harbour

2009-03-19 Thread Przemyslaw Czerpak
On Thu, 19 Mar 2009, Szak�ts Viktor wrote:

Hi Viktor,

> Attached the -gc2 results. Notice that the results aren't
> suited for -ko comparison as I've used different revisions.
> I hope this wasn't your goal. If it was I can redo -gc3
> tests with current build (-ko disabled).

Thank you very much for test but I asked about reverted test. I want to
compare harbour-gc2 + speedtst-gc2 with harbour-gc3 + speedtst-gc2.
Can you send also harbour-gc3 + speedtst-gc2.

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:[10653] trunk/harbour

2009-03-19 Thread Viktor Szakáts
>
> > Attached the -gc2 results. Notice that the results aren't
> > suited for -ko comparison as I've used different revisions.
> > I hope this wasn't your goal. If it was I can redo -gc3
> > tests with current build (-ko disabled).
>
> Thank you very much for test but I asked about reverted test. I want to
> compare harbour-gc2 + speedtst-gc2 with harbour-gc3 + speedtst-gc2.
> Can you send also harbour-gc3 + speedtst-gc2.


Sorry, I didn't explain the filenames:

Harbour -gc3 + speedtst -gc2 (yesterday's builds):
   st-hb-icc-gc2.txt
   st-hb-msvc-gc2.txt
   st-hb-mingw433-gc2.txt
Harbour -gc2 + speedtst -gc2 (recent builds):
   st-hb-msvc-gc2-gc2.txt
   st-hb-mingw433-gc2-gc2.txt

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


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

2009-03-19 Thread vszakats
Revision: 10661
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10661&view=rev
Author:   vszakats
Date: 2009-03-19 23:42:42 + (Thu, 19 Mar 2009)

Log Message:
---
2009-03-20 00:41 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
  + contrib/xhb/inet.h
+ Added from xhb.

  * contrib/xhb/xhbfunc.c
+ Added HB_POINTER2STRING() and HB_STRING2POINTER().
  Just for the record, I've commented them, as they're both
  very dangerous and violating basic programming rules.

  * contrib/hbwin/win_prn2.c
+ Added XISPRINTER() from xhb.
% Optimizations / cleanups in Windows spaghetti code.
  Would need a complete 'refactor'.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbwin/win_prn2.c
trunk/harbour/contrib/xhb/xhbfunc.c

Added Paths:
---
trunk/harbour/contrib/xhb/inet.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:[10653] trunk/harbour

2009-03-19 Thread Przemyslaw Czerpak
On Fri, 20 Mar 2009, Szak�ts Viktor wrote:
> > Thank you very much for test but I asked about reverted test. I want to
> > compare harbour-gc2 + speedtst-gc2 with harbour-gc3 + speedtst-gc2.
> > Can you send also harbour-gc3 + speedtst-gc2.
> Sorry, I didn't explain the filenames:
> Harbour -gc3 + speedtst -gc2 (yesterday's builds):
>st-hb-icc-gc2.txt
>st-hb-msvc-gc2.txt
>st-hb-mingw433-gc2.txt
> Harbour -gc2 + speedtst -gc2 (recent builds):
>st-hb-msvc-gc2-gc2.txt
>st-hb-mingw433-gc2-gc2.txt

Viktor, 2-3 degrees difference in room temperature has noticeable speed
overhead for modern computers and I do not joke. It's documented by CPU
producers. Test should be done in as close period of time as possible
or repeated many times in long periods to well catch average results.

I can believe in many different things but I do not belive that:

03/19/09 23:05:24 Windows XP 5.1.2600 Service Pack 3
Harbour-gc2+speedtst-gc2 gives:
[ T000: empty loop overhead ]...0.06

Harbour-gc3+speedtst-gc2 gives:
03/19/09 23:45:50 Windows XP 5.1.2600 Service Pack 3
[ T000: empty loop overhead ]...0.11

:-)

The 1-st one for sure in not yesterday's builds and for sure speedtst
was not compiled with -gc2 but with -gc3 in this test.

No offence but I think that in similar way you found that -ko
gives slower code what is technically impossible because it only
reduce the code a little bit by stripping some dummy expressions
or replacing:

   1
   plus
with:

   inc

Anyhow now I would like to should you sth funny what can help you
in the future in checking the results.

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:[10653] trunk/harbour

2009-03-19 Thread Viktor Szakáts
>
> > Sorry, I didn't explain the filenames:
> > Harbour -gc3 + speedtst -gc2 (yesterday's builds):
> >st-hb-icc-gc2.txt
> >st-hb-msvc-gc2.txt
> >st-hb-mingw433-gc2.txt
> > Harbour -gc2 + speedtst -gc2 (recent builds):
> >st-hb-msvc-gc2-gc2.txt
> >st-hb-mingw433-gc2-gc2.txt
>
> Viktor, 2-3 degrees difference in room temperature has noticeable speed
> overhead for modern computers and I do not joke. It's documented by CPU
> producers. Test should be done in as close period of time as possible
> or repeated many times in long periods to well catch average results.


In recent days I always did a reference measurement
using a known combination. I did it now too, and it stayed
well within the second threshold, it was in fact almost
identical (I used MSVC -gc3 ST mode). My environment
was pretty static in the last few days (both ambient and
inside the computer), I've always shut down all processes and
apps while running the tests, there was no network activity
and I didn't touch the mouse/keyboard. These values are
all repeatable.


> I can believe in many different things but I do not belive that:
>
> 03/19/09 23:05:24 Windows XP 5.1.2600 Service Pack 3
> Harbour-gc2+speedtst-gc2 gives:
> [ T000: empty loop overhead ]...0.06
>
> Harbour-gc3+speedtst-gc2 gives:
> 03/19/09 23:45:50 Windows XP 5.1.2600 Service Pack 3
> [ T000: empty loop overhead ]...0.11
>
> :-)


In fact it's not funny.

In this specific test (and only this one, it was the last one),
I was impatient and run the test while the last part of the
build process (zip.exe) didn't end yet. And you spotted it.
So I've rerun this test, see it at the end of this mail. Don't
discredit the rest of the results though, they were all run
in clean idle states.

The 1-st one for sure in not yesterday's builds and for sure speedtst
> was not compiled with -gc2 but with -gc3 in this test.


Are you talking about st-hb-icc-gc2.txt ?

It *is* a -gc3 default build I did on 2008-03-18, and
speedtst was compiled with -gc2 command.
I can send you the .exe if you don't believe me.

No offence but I think that in similar way you found that -ko
> gives slower code what is technically impossible because it only
> reduce the code a little bit by stripping some dummy expressions
> or replacing:
>   
>   1
>   plus
> with:
>   
>   inc


In -gc3 the only difference is a parameter passed
in normal mode and no parameter in -ko mode
passed to a different hb_xvm*() function. That
different function looks more heavy than the other,
that might explain. The difference is marginal, but
repeatable on my system. In -gc3 there is no
change in number of HVM calls made in -ko
and non--ko modes.

Specifically:
-ko mode:
if( hb_xvmDec() ) break;
default mode:
if( hb_xvmAddInt( -1 ) ) break;


> Anyhow now I would like to should you sth funny what can help you
> in the future in checking the results.


Sorry, I didn't get this :/

Finally the repeated "st-hb-mingw433-gc2-gc2.txt" result:
---
03/20/09 01:39:22 Windows XP 5.1.2600 Service Pack 3
Harbour 1.1.0dev (Rev. 10660) MinGW GNU C 4.3.3 (32-bit)
THREADS: 0
N_LOOPS: 100
[ T000: empty loop overhead ]...0.06

[ T001: x := L_C ]..0.11
[ T002: x := L_N ]..0.05
[ T003: x := L_D ]..0.05
[ T004: x := S_C ]..0.09
[ T005: x := S_N ]..0.05
[ T006: x := S_D ]..0.03
[ T007: x := M->M_C ]...0.08
[ T008: x := M->M_N ]...0.06
[ T009: x := M->M_D ]...0.06
[ T010: x := M->P_C ]...0.09
[ T011: x := M->P_N ]...0.06
[ T012: x := M->P_D ]...0.05
[ T013: x := F_C ]..0.20
[ T014: x := F_N ]..0.38
[ T015: x := F_D ]..0.14
[ T016: x := o:Args ]...0.25
[ T017: x := o[2] ].0.17
[ T018: round( i / 1000, 2 ) ]..0.66
[ T019: str( i / 1000 ) ]...2.98
[ T020: val( s ) ]..0.47
[ T021: val( a [ i % 16 + 1 ] ) ]...0.78
[ T022: dtos( d - i % 1 ) ].0.66
[ T023: eval( { || i % 16 } ) ].0.84
[ T024: eval( bc := { || i % 16 } ) ]...0.39
[ T025: eval( { |x| x % 

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

2009-03-19 Thread Przemyslaw Czerpak
On Fri, 20 Mar 2009, Szak�ts Viktor wrote:

Hi,

> > I can believe in many different things but I do not belive that:
> > 03/19/09 23:05:24 Windows XP 5.1.2600 Service Pack 3
> > Harbour-gc2+speedtst-gc2 gives:
> > [ T000: empty loop overhead ]...0.06
> > Harbour-gc3+speedtst-gc2 gives:
> > 03/19/09 23:45:50 Windows XP 5.1.2600 Service Pack 3
> > [ T000: empty loop overhead ]...0.11
> > :-)
> In fact it's not funny.
> 
> In this specific test (and only this one, it was the last one),
> I was impatient and run the test while the last part of the
> build process (zip.exe) didn't end yet. And you spotted it.
> So I've rerun this test, see it at the end of this mail. Don't
> discredit the rest of the results though, they were all run
> in clean idle states.

If the above is true then it discards all your results :-(
because your Windows calculated this second .zip process as
the speedtst time:
   [ total application time: ]49.13
   [ total real time: ]...49.45
The application time and real time are nearly identical. Such overhead
by other process should create huge difference between both times
and real time should be noticeable bigger.

> The 1-st one for sure in not yesterday's builds and for sure speedtst
> > was not compiled with -gc2 but with -gc3 in this test.
> Are you talking about st-hb-icc-gc2.txt ?

No, see times above. They come from MinGW builds.

> It *is* a -gc3 default build I did on 2008-03-18, and
> speedtst was compiled with -gc2 command.
> I can send you the .exe if you don't believe me.

You do not have to I see results :-)

> In -gc3 the only difference is a parameter passed
> in normal mode and no parameter in -ko mode
> passed to a different hb_xvm*() function. That
> different function looks more heavy than the other,
> that might explain. The difference is marginal, but
> repeatable on my system. In -gc3 there is no
> change in number of HVM calls made in -ko
> and non--ko modes.

You are talking about INC only so please look the body
of hb_vmInc() and hb_vmAddInt() and check if this parameter
is the only difference and it explains the difference.

> Specifically:
> -ko mode:
> if( hb_xvmDec() ) break;
> default mode:
> if( hb_xvmAddInt( -1 ) ) break;

Yes it is and look at this functions.
But this is only one modification in generated code which
should increase the speed.
-ko makes also other modifications, f.e. compare the code for:
   proc main()
   local x := 20
  ? x + 10 + 15 + 30 * 5 + 40 + 7
   return

> > Anyhow now I would like to should you sth funny what can help you
> > in the future in checking the results.
> Sorry, I didn't get this :/
> Finally the repeated "st-hb-mingw433-gc2-gc2.txt" result:

Thank you.

You are the 1-st on this list (and also xHarbour list) who does not
report small speed reduction when Harbour code code is compiled with
-gc3 and speedtst with -gc2. All other users reported small speed
overhead 1-2% in comparison to core code compiled with -gc2.
It is visible in both -gc3 and -gc2 compilations:
   timeof( harbour-gc2 + speedtst-gc2 ) < timeof( harbour-gc3 + speedtst-gc2 )
and:
   timeof( harbour-gc2 + speedtst-gc3 ) < timeof( harbour-gc2 + speedtst-gc3 )

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:[10653] trunk/harbour

2009-03-19 Thread Viktor Szakáts
>
> > In this specific test (and only this one, it was the last one),
> > I was impatient and run the test while the last part of the
> > build process (zip.exe) didn't end yet. And you spotted it.
> > So I've rerun this test, see it at the end of this mail. Don't
> > discredit the rest of the results though, they were all run
> > in clean idle states.
>
> If the above is true then it discards all your results :-(


Why?? I did this mistake only when testing this _one and
only_ combination.


> > speedtst was compiled with -gc2 command.
> > I can send you the .exe if you don't believe me.
>
> You do not have to I see results :-)


What you're trying to say, that I'm lying?

I can send you the .exes, but as far as I can see it from
here, the whole purpose of you asking me results is to make
a fool of me and discredit all my tests.

You are the 1-st on this list (and also xHarbour list) who does not
> report small speed reduction when Harbour code code is compiled with
> -gc3 and speedtst with -gc2. All other users reported small speed
> overhead 1-2% in comparison to core code compiled with -gc2.
> It is visible in both -gc3 and -gc2 compilations:
>   timeof( harbour-gc2 + speedtst-gc2 ) < timeof( harbour-gc3 + speedtst-gc2
> )
> and:
>   timeof( harbour-gc2 + speedtst-gc3 ) < timeof( harbour-gc2 + speedtst-gc3
> )


Yes, I inventing these numbers to entertain the list and myself.
I'm inventing them consistently for all compilers and all combinations,
just to mislead you. Then I'd like to ask the group to send similar
tests, because I've never ever seen any such comparison on
Harbour list.

As for -gc3 I can even *see* the difference visually in my own app.
It's clearly apparent with any larger TBrowse() object, no need
to really measure it.

I promise I won't ever send you any benchmark results in the
future, it's very time consuming and at the end is always
you ridiculing me in various ways. Very frustrating.

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