[Harbour] Thanks to Marcos Gambeta for his exciting and inspiring works
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
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)
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
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
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)
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
-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
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
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
> > 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()
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
> > 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
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()
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
-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()
-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()
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()
-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()
-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
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
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
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
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
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
> > 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
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
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
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
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
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
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
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
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
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
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
> > > 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
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
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
> > > 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
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
> > > 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