Re: [Harbour] RDD: ADT -> ADSADT
Nope from here. Brgds, Viktor On 2009 Nov 27, at 03:29, Mindaugas Kavaliauskas wrote: > Hi, > > > current ADS RDD is registered using names: ADS, ADT, ADSCDX, ADSNTX, > ADSVFP. RDD SYSNAME method (i.e., RDDNAME()) can return one of the > following values: ADSADT, ADSCDX, ADSNTX, ADSVFP. Original C level ADS > defines for different database types are: ADS_CDX, ADS_NTX, ADS_VFP, > ADT_ADT. > > I propose to rename RDD from ADT to ADSADT, thus making both correct > RDDNAME() return value and to be compatible with naming scheme of > another ADS RDDs. Any objections? > > > Regards, > Mindaugas > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problems updating from SVN
Bruno Luciani napsal(a): Something Strange happens when i try to update via SVN Bruno // br...@notebook:~$ svn co https://harbour-project.svn.sourceforge.net/svnroot/harbour-project/trunk harbour_svn svn: Error al convertir la entrada en el directorio «harbour_svn/harbour/contrib/hbide» a UTF-8 svn: Datos UTF-8 válidos (hex:) seguidos de una secuencia UTF-8 inválida (hex: d0 d3 43) br...@notebook:~$ ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour export LC_ALL=C svn co https://harbour-project.svn.sourceforge.net/svnroot/harbour-project/trunk/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: [xHarbour-developers] RDD: ADT -> ADSADT
On Thu, 26 Nov 2009, Brian Hays wrote: Hi Brian, > The addition of specific "sub-rdds" of ADSCDX etc. came years later. > I, and I imagine a lot of other people who started using rddads > early on, never had a need to explicitly use those other rdds by name. Any one who has code like: proc copy_table( cSrc, cSrcRDD, cDst, cDstRDD ) use (cSrc) via (cSrcRDD) copy to (cDst) via (cDstRDD) return designed to work with different RDDs in Clipper, needs ADS* RDDs to port his code without introducing unnecessary and incompatible with other RDDs modifications which are necessary to make working code like: copy_table( "sales", "ADSCDX", "sales2", "ADSADT" ) In fact "ADS" RDD can be safely removed because the only one reason to keep it are user habbits but ADS* RDDs cannot be removed without reducing important functionality - working VIA clause in different command/functions which allows to easy switch between RDDs. > Are you suggesting that we should now have to re-write our apps by > converting ADS to ADSADT? But wait: IIRC (I'm not sure), > ADSCDX is the DEFAULT for ADS, so converting it to ADT doesn't > really make sense, does it? > If you're suggesting a change that would require people to change > code that's been growing for 9 years, there needs to be a stronger > reason to force the change than just compatibility with other rdds, > IMHO. > Or am I missing something? Mindaugas wants to change only "ADT" RDD to "ADSADT" and you are not using it so it's not a problem for you. Anyhow you wrote that it's 9 years code. In the past I left "ADS" RDD only for backward compatibility: 2005-09-02 20:10 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) + register ADS as three separate RDDs: ADSNTX, ADSCDX, ADT (ADS RDD left for backward compatibility) - they do not need to set table type. so in fact you had over four years to update your code. This suggests that forcing some modification immediately is better because four years ago it was only 5 years code ;-) Was it my mistake that I left "ADS" RDD? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Hi, Przemysław Czerpak wrote: Yes it's really nice though it probably can be even simpler without recursion. This code allocates memory for index array using hb_xgrab() and needs recursion only for allocating dynamically lFrom and lTo on C stack. It means that it should be enough to allocate memory 3 times bigger for lIndex[es], lFrom[s] and lTo[s] and convert array in two nested loops. I had this idea, but it's a kind of implementing carry flag for each number (dimension in this case) position manualy. Recursion was an easier for me :) Hmm, it will be shorter and probably a little bit faster but I cannot say if such version is more readable. It's necessary to compare final code to answer. Maybe in some spare time ;-) I guess it will be only faster, but not shorter :) BTW in MS documentation dimensions are stored in 'unsigned int' instead of 'int'. Maybe we should follow it? MSDN writes: HRESULT SafeArrayGetDim( SAFEARRAY FAR* psa ); BCC wtypes.h has: #ifndef _HRESULT_DEFINED #define _HRESULT_DEFINED typedef LONG HRESULT; #endif // !_HRESULT_DEFINED So, it's long, not unsigned int. But the most strange thing is that SafeArrayGetDim return HRESULT. Sounds like a handler, and this stopped me from beeper analysis. I just used int. Actually it was a bad idea, to not check real type. Please, fix it. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] RDD: ADT -> ADSADT
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote: Hi, > current ADS RDD is registered using names: ADS, ADT, ADSCDX, ADSNTX, > ADSVFP. RDD SYSNAME method (i.e., RDDNAME()) can return one of the > following values: ADSADT, ADSCDX, ADSNTX, ADSVFP. Original C level ADS > defines for different database types are: ADS_CDX, ADS_NTX, ADS_VFP, > ADT_ADT. > I propose to rename RDD from ADT to ADSADT, thus making both correct > RDDNAME() return value and to be compatible with naming scheme of > another ADS RDDs. Any objections? It's OK for me. In fact "ADT" as RDD name was my bad choice in the past. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote: Hi, > I've also looked at SafeArrayToArray() function from xHarbour > win32ole.prg, but after 10 seconds I've understood it's better not > to look at this, because I can start to replicate it. So, that's the > reason why hb_oleSafeArrayToItem() is so short and simple :) Yes it's really nice though it probably can be even simpler without recursion. This code allocates memory for index array using hb_xgrab() and needs recursion only for allocating dynamically lFrom and lTo on C stack. It means that it should be enough to allocate memory 3 times bigger for lIndex[es], lFrom[s] and lTo[s] and convert array in two nested loops. Hmm, it will be shorter and probably a little bit faster but I cannot say if such version is more readable. It's necessary to compare final code to answer. Maybe in some spare time ;-) BTW in MS documentation dimensions are stored in 'unsigned int' instead of 'int'. Maybe we should follow it? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13034] trunk/harbour
Revision: 13034 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13034&view=rev Author: snaiperis Date: 2009-11-27 03:31:20 + (Fri, 27 Nov 2009) Log Message: --- 2009-11-27 05:31 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) * harbour/contrib/hbwin/olecore.c * more beautiful and speed optimized version of last commit Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/olecore.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Hi, But we have new one. Looks that VariantInit( &vItem ); at line 517 is missing. I know, but you are faster this time :) Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13033] trunk/harbour
Revision: 13033 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13033&view=rev Author: snaiperis Date: 2009-11-27 03:21:53 + (Fri, 27 Nov 2009) Log Message: --- 2009-11-27 05:21 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) * harbour/contrib/hbwin/olecore.c ! added missing VARIANT initialization Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/olecore.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Hi, Przemysław Czerpak wrote: yes, good job. Again thank you very much. I've also looked at SafeArrayToArray() function from xHarbour win32ole.prg, but after 10 seconds I've understood it's better not to look at this, because I can start to replicate it. So, that's the reason why hb_oleSafeArrayToItem() is so short and simple :) Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
On Fri, 27 Nov 2009, Przemysław Czerpak wrote: Hi > > I found two: > > if( lFrom >= lTo ) // cause hb_itemClear() fall through > > and > > hb_arrayGetItemPtr( pItem, ul++ ) (or ul = 0;) // GPF > I haven't seen the second one. > > I've not replicated it. > yes, good job. Again thank you very much. But we have new one. Looks that VariantInit( &vItem ); at line 517 is missing. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote: Hi, > >I've just check that there is also bad typo which causes that it does > >not convert even one dimensional VT_ARRAYS to Harbour items. > >I'll commit fix in a while so if this code needs only one dimensional > >arrays the it may be enough. > >Please test. > I found two: > if( lFrom >= lTo ) // cause hb_itemClear() fall through > and > hb_arrayGetItemPtr( pItem, ul++ ) (or ul = 0;) // GPF I haven't seen the second one. > I've not replicated it. yes, good job. Again thank you very much. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
On Fri, 27 Nov 2009, Przemysław Czerpak wrote: > I've just check that there is also bad typo which causes that it does > not convert even one dimensional VT_ARRAYS to Harbour items. > I'll commit fix in a while so if this code needs only one dimensional > arrays the it may be enough. > Please test. Ups, you were faster :-) Thank you. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Hi, Przemysław Czerpak wrote: I've just check that there is also bad typo which causes that it does not convert even one dimensional VT_ARRAYS to Harbour items. I'll commit fix in a while so if this code needs only one dimensional arrays the it may be enough. Please test. I found two: if( lFrom >= lTo ) // cause hb_itemClear() fall through and hb_arrayGetItemPtr( pItem, ul++ ) (or ul = 0;) // GPF I've not replicated it. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
On Fri, 27 Nov 2009, Mindaugas Kavaliauskas wrote: > Enrico Maria Giordano wrote: > >In the following sample, GetRows() method returns NIL (correctly > >returns an array using xHarbour): > Current Harbour OLE implementation supports only one dimensional > array. I'll try to add support for multidimensional array in spare > time. Hi, I've just check that there is also bad typo which causes that it does not convert even one dimensional VT_ARRAYS to Harbour items. I'll commit fix in a while so if this code needs only one dimensional arrays the it may be enough. Please test. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] RDD: ADT -> ADSADT
Hi, current ADS RDD is registered using names: ADS, ADT, ADSCDX, ADSNTX, ADSVFP. RDD SYSNAME method (i.e., RDDNAME()) can return one of the following values: ADSADT, ADSCDX, ADSNTX, ADSVFP. Original C level ADS defines for different database types are: ADS_CDX, ADS_NTX, ADS_VFP, ADT_ADT. I propose to rename RDD from ADT to ADSADT, thus making both correct RDDNAME() return value and to be compatible with naming scheme of another ADS RDDs. Any objections? Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13032] trunk/harbour
Revision: 13032 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13032&view=rev Author: snaiperis Date: 2009-11-27 02:29:37 + (Fri, 27 Nov 2009) Log Message: --- 2009-11-27 04:29 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) * harbour/contrib/hbwin/olecore.c + added support (VARIANT to ITEM) for multidimensional arrays Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/olecore.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem in OLE implementation
Enrico Maria Giordano wrote: In the following sample, GetRows() method returns NIL (correctly returns an array using xHarbour): Hi, Current Harbour OLE implementation supports only one dimensional array. I'll try to add support for multidimensional array in spare time. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Problems updating from SVN
Something Strange happens when i try to update via SVN Bruno // br...@notebook:~$ svn co https://harbour-project.svn.sourceforge.net/svnroot/harbour-project/trunkharbour_svn svn: Error al convertir la entrada en el directorio «harbour_svn/harbour/contrib/hbide» a UTF-8 svn: Datos UTF-8 válidos (hex:) seguidos de una secuencia UTF-8 inválida (hex: d0 d3 43) br...@notebook:~$ ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Qt libs static link
Hi ! After setting HB_QT_STATIC = yes, I could generate HBQT static version libs, but when I try to build hbide.hbp (or any other hbxbp + hbqt based sample) using hbqts.hbc instead of hbqt.hbc (at hbxbp.hbc) hbmk2 mounts the executable, but the executable doesn't work. Hbmk2 shows the following message: = C:\harbour\contrib\hbide>hbmk2 hbide.hbp hbmk2: Processing environment options: -platform=win -compiler=mingw hbmk2: Linkando... hbide.exe Info: resolving QObject::staticMetaObject by linking to __imp___ZN7QObject16staticMetaObjectE (auto-import) Info: resolving QString::codecForCStrings by linking to __imp___ZN7QString16codecForCStringsE (auto-import) Info: resolving QListData::shared_null by linking to __imp___ZN9QListData11shared_nullE (auto-import) Info: resolving QAction::staticMetaObject by linking to __imp___ZN7QAction16staticMetaObjectE (auto-import) Info: resolving QVectorData::shared_nullby linking to __imp___ZN11QVectorData11shared_nullE (auto-import) Info: resolving QSyntaxHighlighter::staticMetaObjectby linking to __imp___ZN18QSyntaxHighlighter16staticMetaObjectE (auto-import) Info: resolving QTableView::staticMetaObjectby linking to __imp___ZN10QTableView16staticMetaObjectE (auto-import) Info: resolving QAbstractItemModel::staticMetaObjectby linking to __imp___ZN18QAbstractItemModel16staticMetaObjectE (auto-import) Info: resolving QWidget::staticMetaObject by linking to __imp___ZN7QWidget16staticMetaObjectE (auto-import) Info: resolving QMainWindow::staticMetaObjectby linking to __imp___ZN11QMainWindow16staticMetaObjectE (auto-import) Info: resolving QString::shared_null by linking to __imp___ZN7QString11shared_nullE (auto-import) Info: resolving QByteArray::shared_nullby linking to __imp___ZN10QByteArray11shared_nullE (auto-import) Info: resolving vtable for QEventby linking to __imp___ZTV6QEvent (auto-import) Info: resolving vtable for QMouseEventby linking to __imp___ZTV11QMouseEvent (auto-import) Info: resolving QVariant::handler by linking to __imp___ZN8QVariant7handlerE (auto-import) Info: resolving vtable for QBitmapby linking to __imp___ZTV7QBitmap (auto-import) Info: resolving QCoreApplication::self by linking to __imp___ZN16QCoreApplication4selfE (auto-import) C:\MINGW\BIN\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. = Even linked to static version of hbqt libs, the executable looks/asks for QtCore4.dll and if the DLL is reachable it crashes with message "Aplication Error - Application not initialized correctly" Am I doing something wrong? Thanks Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
On Thu, 26 Nov 2009, Przemysław Czerpak wrote: Hi David, > Sorry but now I'm really confused. All what I know about results > of real life OS/2 test comes from you and Maurilio messages. > Now I'm OpenWatcom builds reading that it was never working > correctly in MT mode in whole Harbour history and always fail > in MT mode when second thread accessed GTOS2 function (I guess > that speedtst works correctly with current SVN code when is linked > with GTCGI). > Can you and Maurilio confirm it? I've reread again old messages and you wrote that the problem can be resolved by removing -s compile time switch. Can you confirm that it is still true and if you remove -s from config/os2/watcom.mk[42] and utils/hbmk2/hbmk2.prg[2706] then MT version of speedtst --thread works? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13031] trunk/harbour
Thank you very much. Brgds, Viktor On 2009 Nov 26, at 23:12, vouch...@users.sourceforge.net wrote: > Revision: 13031 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13031&view=rev > Author: vouchcac > Date: 2009-11-26 22:12:44 + (Thu, 26 Nov 2009) > > Log Message: > --- > 2009-11-26 14:09 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/gtwvg/tests/demowvg.prg >! Removed all hb_ToOutDebug() calls. > > * contrib/gtwvg/tests/demoxbp.prg >! Removed all hb_ToOutDebug() calls. > > * contrib/hbide/hbide.prg >! Few more artifacts fixed. > > * contrib/xhb/Makefile >! Reverted back to original before my last commit. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/gtwvg/tests/demowvg.prg >trunk/harbour/contrib/gtwvg/tests/demoxbp.prg >trunk/harbour/contrib/hbide/hbide.prg >trunk/harbour/contrib/xhb/Makefile > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13031] trunk/harbour
Revision: 13031 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13031&view=rev Author: vouchcac Date: 2009-11-26 22:12:44 + (Thu, 26 Nov 2009) Log Message: --- 2009-11-26 14:09 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/gtwvg/tests/demowvg.prg ! Removed all hb_ToOutDebug() calls. * contrib/gtwvg/tests/demoxbp.prg ! Removed all hb_ToOutDebug() calls. * contrib/hbide/hbide.prg ! Few more artifacts fixed. * contrib/xhb/Makefile ! Reverted back to original before my last commit. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/tests/demowvg.prg trunk/harbour/contrib/gtwvg/tests/demoxbp.prg trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/xhb/Makefile This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Error in command: @...GET LISTBOX, The list box's drop-down buttonn not appear
Przemysław Czerpak escribió: On Thu, 26 Nov 2009, http://news.gmane.org/gmane.comp.db.sqlite.general wrote: Hi, Something strange is happening, when I put full screen (with ALT + Enter), alli if it appears. In Clipper appears in both modes. Any TIP? Yes, change the font in your console window setting and chose the one which have the character you want to see. It's not Harbour problem. [SPA] Bien Pzremek, Gracias por responder. La ventana de la consola, solamente tiene 2 fuentes: 1.- Fuentes de Mapa de Bits, y 2.- Lucida Console El problema es con Lucida Console. Con los fuentes de mapa de bits funciona bien, sin embargo se ve la pantalla muy chica, aun cuando use el tamaño máximo (10x18). Como dije antes, en clipper se muestra correctamente usando cualquiera de los 2 modos. ¿Habrá alguna otra forma de solucionar este problema? [ENG] By Google Pzremek Well, Thanks for responding. The console window, only has 2 sources: 1 .- Bitmap fonts, and 2 .- Lucida Console The problem is with Lucida Console. With the bitmap fonts work well, however the screen is too small, even when using the maximum size (10x18). As I said before, in clipper is displayed correctly using any of the 2 modes. Will there be any other way to solve this problem? TIA BestRegards GVS ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Error in command: @...GET LISTBOX, The list box's drop-down buttonn not appear
On Thu, 26 Nov 2009, http://news.gmane.org/gmane.comp.db.sqlite.general wrote: Hi, > Something strange is happening, when I put full screen (with ALT + > Enter), alli if it appears. > In Clipper appears in both modes. > Any TIP? Yes, change the font in your console window setting and chose the one which have the character you want to see. It's not Harbour problem. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12970] trunk/harbour
On Thu, 26 Nov 2009, Tamas TEVESZ wrote:
> > I've just committed it:
> >
> > 2009-11-26 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> a typo seems to have snuck in.
> Index: src/vm/hvm.c
> ===
> --- src/vm/hvm.c (revision 13028)
> +++ src/vm/hvm.c (working copy)
> @@ -11401,7 +11401,7 @@
>
> void hb_vmUpdateAllocator( PHB_ALLOCUPDT_FUNC pFunc, int iCount )
> {
> - HB_TRACE(HB_TR_DEBUG, ("hb_vmUpdateAllocator(%p, %d)", pFunc, int
> iCount));
> + HB_TRACE(HB_TR_DEBUG, ("hb_vmUpdateAllocator(%p, %d)", pFunc, iCount));
>
> #if defined( HB_MT_VM )
> if( s_vmStackLst )
Yes, thank you for information.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13030] trunk/harbour
Revision: 13030 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13030&view=rev Author: druzus Date: 2009-11-26 21:35:09 + (Thu, 26 Nov 2009) Log Message: --- 2009-11-26 22:35 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/hvm.c ! fixed typo in HB_TRACE message - thanks to Tamas for the info. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/vm/hvm.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13029] trunk/harbour
Revision: 13029 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13029&view=rev Author: druzus Date: 2009-11-26 21:26:13 + (Thu, 26 Nov 2009) Log Message: --- 2009-11-26 22:26 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/garbage.c % small improvement in HB_GC_AUTO code * harbour/include/hbdefs.h ! reverted the hack which casted file handles to unsigned values I added two weeks ago - it was also converting FS_ERROR value from -1 to 4294967295. Please remember that on some platforms negative handles can exist and are valid. Only -1 indicates an error. * harbour/utils/hbtest/rt_file.prg + added regression test for FOPEN() FS_ERROR value * harbour/contrib/hbwin/legacycd.c * harbour/contrib/hbwin/legacyco.c * added missing EOL at EOF Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/legacycd.c trunk/harbour/contrib/hbwin/legacyco.c trunk/harbour/include/hbdefs.h trunk/harbour/src/vm/garbage.c trunk/harbour/utils/hbtest/rt_file.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] speedtst and vm
On Thu, 26 Nov 2009, Maurilio Longo wrote:
Hi,
> the second one is built with
> hbmk2 -mt -gc3 speedtst
> and not -gc2 as I wrongly wrote before.
> > I've made a couple of tests: in the first one speedtst was built with
> > hbmk2 -mt speedtst
> > in the second with
> > hbmk2 -mt -gc2 speedtst
> >
> > Now, calling
> > speedtst --thread=2 --scale
> >
> > on a PIV HT with OS/2 and a SMP kernel I see that the first speedtst when
> > run
> > has a scaling factor of 1.18 while the second one has a scaling factor of
> > 1.32.
> >
> > Question is: is this simply a result of the more work the vm has to do
> > compared to the -gc3 build or are there serialization points inside the vm
> > which slow the first speedtst compared to the second?
No. Just simply the proportions between cost of different operations has
been changed or it's effect of some activity of other processes which
reduce simultaneous access to two different CPUs. Please remember that
in this test real time is used so any other code executed by OS strongly
reduce the scalability factor.
Harbour core code is MT safe in practice without any internal locks.
There is only one exception bound with memory allocation. Allocating
new complex items like codeblocks, arrays, hashes or GC pointers activates
code which needs mutex lock to register new GC memory block in a list of
GC blocks. It's very short lock but when you execute test like --scale in
speedtst where two threads make exactly the same operations in a loop then
it can highly exploits this fact and reduce scalability factor. How much it
depends on used hardware and OS. In speedtst.prg few tests allocates and
destroys complex items in a loop. [ T044: x := {} ] which does not make
anything more is the best to illustrate maximal overhead using given
hardware and OS. The cost of failing locks strongly depends on hardware
and test shows that sometimes there are huge differences between very
similar computers which use only a little bit different mainboards and/or
CPUs. Important is also the cost of suspending and resuming threads when
lock fails which depends on used OS (sometimes also CRTL).
It's very important for good scalability to eliminate all possible locks
which can often fail. The best is the code which is fully reentrant safe
and do not use any locks but test shows that locks which nearly always
success do not reduce performance.
As I said in Harbour core code only memory allocation for complex items
uses internal locks. But also outside Harbour core code memory manager
which is not optimized to work well in MT environment can use internal
locks and reduce the scalability. In such case HB_FM_DLMT_ALLOC can be
used which uses 16 separate memory pools to reduce possible conflicts
on multi CPU machines.
In the future we can try to use similar trick to reduce possible conflicts
in code which allocates new complex items. For sure it will nicely improve
scalability in tests like [ T044: x := {} ] but in real applications which
make also other things then allocating empty array in a loop the chance for
lock conflict is much smaller so it's not be such important. Anyhow I plan
to make it so it can be enabled at least optionally at Harbour build time
for some machines which have really big number of CPUs and programs which
use many threads extensively using existing CPUs.
BTW I've just made test on my 3 CPU machine to compare scalability for
2 threads. I intentionally used 2 threads in test instead of 3 to reduce
the factor reduction by other processes running in this system. I also
disable power saving mode with automatic CPU frequency updating - it
can hardly reduce scalability in some cases. Below are detail results.
Then I repeated it with disabled tests allocating complex items in a loop:
./speedtst --thread=2 --scale --exclude=023,025,027,031,041,042,044
Results are also below. DLMT was used as memory manager in this Harbour
build. As you can see we have nearly perfect scalability and only factor in:
[ T004: x := S_C ]__ 0.14 0.24 -> 0.59
is not close to 2.0 and it's expected behavior because in this test two
threads operate on exactly the same string item increasing and decreasing
its reference counter in hardware atomic inc/dec operations what of course
needs low level hardware synchronization between CPUs. T004 is also quite
good test to check the hardware cost of lock failing because it's comparable
to conflict in LOCK INC/ LOCK DEC operations.
best regards,
Przemek
2009.11.26 21:44:59 Linux 2.6.31.5-0.1-desktop x86_64
Harbour 2.0.0beta3 (Rev. 13026) (MT)+ GNU C 4.4 (64-bit) x86-64
THREADS: 2
N_LOOPS: 100
1 th. 2 th. factor
[ T001: x := L_C ] 0.12 0.06 -> 2.00
[ T002: x := L_N ] 0.10 0.05 -> 1.96
[ T003: x := L_D ]_
[Harbour] Re: Error in command: @...GET LISTBOX, The list box's drop-down buttonn not appear
[SPA]
Algo extraño esta pasando, cuando pongo pantalla completa (con
ALT+Enter), alli si aparece.
En Clipper aparece en ambos modos.
¿Algún TIP?
[ENG] By Google
Something strange is happening, when I put full screen (with ALT +
Enter), alli if it appears.
In Clipper appears in both modes.
Any TIP?
TIA
BestRegards
GVS
Massimo Belgrano escribió:
I have tried but harbour report
Tipo : Tipo 2▼
Follow my //build
Harbour Build Info
---
Version: Harbour 2.0.0beta3 (Rev. 13026)
Compiler: MinGW GNU C 4.4.1 (32-bit)
Platform: Windows 7 6.1.7600
PCode version: 0.2
ChangeLog last entry: 2009-11-26 12:18 UTC+0100 Przemyslaw Czerpak (druzus/at/pr
iv.onet.pl)
ChangeLog ID: ChangeLog 13026 2009-11-26 11:18:25Z druzus
Built on: Nov 26 2009 12:22:47
Build options:
Language options: (Clipper 5.3) (Clipper 5.x undoc) (Xbase++) (Flagship)
---
// info
Harbour Terminal: Windows native console
Harbour 2.0.0beta3 (Rev. 13026)
Windows 7 6.1.7600
DS avail=1085800KB OS avail=2063320KB EMM avail=0KB MemStat:Off MT:Off
2009/11/26 http://news.gmane.org/gmane.comp.db.sqlite.general
:
--
#include "inkey.ch"
procedure main
LOCAL wTipo := "T2", aTipo := {}
AADD(aTipo,{"Tipo 1","T1"})
AADD(aTipo,{"Tipo 2","T2"})
AADD(aTipo,{"Tipo 3","T3"})
//
SET( _SET_EVENTMASK, INKEY_ALL )
MSETCURSOR( .T. )
CLS
@ 05,40,10,70 GET wTipo LISTBOX aTipo CAPTION '&Tipo :' DROPDOWN SCROLLBAR
COLOR "W/N,B/W+,W/N,W+/B,W/N,N/W*,G/W*,N/G"
READ
RETURN
--
Output in Clipper:
Tipo : Tipo 2▼
Output in Harbour:
Tipo : Tipo 2
The list box's drop-down buttonn not appear
TIA
Best Regards
GVS
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13028] trunk/harbour
Hi Pritpal, > Viktor Szakáts wrote: >> >> Could you pls tell, why changing the order of xhb >> objs was needed? >> >> So far the obj order was not significant in _any_ >> of our libs, and I'd like to know why is xhb lib >> an exception now. >> > > If you remember I reported back that in hb_ToOutDebug(), > hb_outDebug() is called, which, in mingw environment was being > flagged as "unresolved external". Changing this order fixed it. > > It was long back and I exactly do not know now what I did > as we have changed debugging proto for HBQT. This change was > just hanging in my local environment so I committed. > May be this is unimportant now. Yes, it seems unimportant now, and it was never a good fix. Please note, that the order of file listing inside Makefiles, doesn't give a guarantee on the order of objects inside libs. Depending on target compiler lib assembly implementation, it may be changed by f.e. by incremental build. What counts is the ordering of libs. Probably you did it when lib grouping change was in a temporary state on SVN. I did a quick test with hbmk2 with and without -nolibgrouping and it works properly with old obj order. Please retest and if there is any error report it. If not, IMO you should restore it, otherwise we may keep wondering in the future why was this change needed. BTW, as we're closing a release, I think you can also safely disable these debug calls from the GTWVG demo code. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12970] trunk/harbour
On Thu, 26 Nov 2009, Przemysław Czerpak wrote:
hi,
> I've just committed it:
>
> 2009-11-26 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
a typo seems to have snuck in.
Index: src/vm/hvm.c
===
--- src/vm/hvm.c(revision 13028)
+++ src/vm/hvm.c(working copy)
@@ -11401,7 +11401,7 @@
void hb_vmUpdateAllocator( PHB_ALLOCUPDT_FUNC pFunc, int iCount )
{
- HB_TRACE(HB_TR_DEBUG, ("hb_vmUpdateAllocator(%p, %d)", pFunc, int iCount));
+ HB_TRACE(HB_TR_DEBUG, ("hb_vmUpdateAllocator(%p, %d)", pFunc, iCount));
#if defined( HB_MT_VM )
if( s_vmStackLst )
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13028] trunk/harbour
Hi Viktor Szakáts wrote: > > Could you pls tell, why changing the order of xhb > objs was needed? > > So far the obj order was not significant in _any_ > of our libs, and I'd like to know why is xhb lib > an exception now. > If you remember I reported back that in hb_ToOutDebug(), hb_outDebug() is called, which, in mingw environment was being flagged as "unresolved external". Changing this order fixed it. It was long back and I exactly do not know now what I did as we have changed debugging proto for HBQT. This change was just hanging in my local environment so I committed. May be this is unimportant now. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13028--trunk-harbour-tp26532755p26534421.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13028] trunk/harbour
Hi Pritpal, Could you pls tell, why changing the order of xhb objs was needed? So far the obj order was not significant in _any_ of our libs, and I'd like to know why is xhb lib an exception now. Brgds, Viktor On 2009 Nov 26, at 18:37, vouch...@users.sourceforge.net wrote: > Revision: 13028 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13028&view=rev > Author: vouchcac > Date: 2009-11-26 17:37:41 + (Thu, 26 Nov 2009) > > Log Message: > --- > 2009-11-26 09:34 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > - contrib/hbide/resources/tabmodified.PNG > * contrib/xhb/Makefile >! Changed the order of files in linklist. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/gtwvg/tests/demowvg.prg >trunk/harbour/contrib/xhb/Makefile > > Removed Paths: > - >trunk/harbour/contrib/hbide/resources/tabmodified.PNG > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wince + Tone() or PlaySound()
On Thu, 26 Nov 2009, AbeB wrote:
> Does TONE() work on WinCE for anyone? (dosn't work for me)
TONE() is implemented by GT subsystem so the most important question
is which GT you are using in your applications.
In WinCE builds Beep() WIN API function is used for Harbour TONE() function
in the following GTs: GTWIN, GTWVT, GTGUI.
If it works or not depends on used hardware and system.
> how about PlaySound()
> this is what i have in test.prg
> ---
> Proc main()
> PLAYSOUND( ".\SOUND_OK.WAV")
> #PRAGMA BEGINDUMP
> #include
> #include
> #include
> HB_FUNC( PLAYSOUND )
> {
>hb_retl( PlaySound( hb_parc(1), NULL,SND_ASYNC | SND_FILENAME ) );
> }
> #PRAGMA ENDDUMP
> --
> warning: passing argument 1 of 'PlaySound' from incompatible pointer type
Very good warning - this code really uses incompatible pointer.
It should be fixed for all windows builds to be compatible with UNICODE
WIN API. In WinCE only UNICODE API exists.
Here is modified version which should work with all windows version.
It needs current SVN code.
#include
#include
#include "hbapistr.h"
#include "hbset.h"
#ifdef UNICODE
#define HB_PARSTR( n, s, l ) \
hb_parstr_u16( n, HB_CDP_ENDIAN_NATIVE, s, l )
#else
#define HB_PARSTR( n, s, l ) hb_parstr( n, hb_setGetOSCP(), s, l )
#endif
HB_FUNC( PLAYSOUND )
{
LPCTSTR lpStr;
void * hStr;
hStr = HB_PARSTR( 1, &lpStr, NULL );
hb_retl( hStr && PlaySound( lpStr, NULL, SND_ASYNC | SND_FILENAME ) );
hb_strfree( hStr );
}
I haven't tested it. Just written.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13027] trunk/harbour
Thanks a bunch Pritpal. Brgds, Viktor On 2009 Nov 26, at 18:33, vouch...@users.sourceforge.net wrote: > Revision: 13027 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13027&view=rev > Author: vouchcac > Date: 2009-11-26 17:33:37 + (Thu, 26 Nov 2009) > > Log Message: > --- > 2009-11-26 09:32 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > - contrib/hbide/resources/tabmodified.PNG > + contrib/hbide/resources/tabmodified.png >! Lower cased file name. > > Modified Paths: > -- >trunk/harbour/ChangeLog > > Added Paths: > --- >trunk/harbour/contrib/hbide/resources/tabmodified.png > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] fopen(), fcreate(), etc.
On Thu, 26 Nov 2009, Massimo Belgrano wrote: > Good add sample to regression hbtest? Yes, thank you. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Wince + Tone() or PlaySound()
Hi,
Does TONE() work on WinCE for anyone? (dosn't work for me)
how about PlaySound()
this is what i have in test.prg
---
Proc main()
PLAYSOUND( ".\SOUND_OK.WAV")
#PRAGMA BEGINDUMP
#include
#include
#include
HB_FUNC( PLAYSOUND )
{
hb_retl( PlaySound( hb_parc(1), NULL,SND_ASYNC | SND_FILENAME ) );
}
#PRAGMA ENDDUMP
--
warning: passing argument 1 of 'PlaySound' from incompatible pointer type
--
View this message in context:
http://n2.nabble.com/Wince-Tone-or-PlaySound-tp4072493p4072493.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] fopen(), fcreate(), etc.
Good add sample to regression hbtest?
2009/11/26 Przemysław Czerpak :
> On Thu, 26 Nov 2009, bill robertson wrote:
>
> Hi,
>
>> There is a problem with fopen() and I suspect fcreate(), etc in
>> philes.c. In philes.c, you will notice that hb_fsOpen is cast to
>> HB_NHANDLE which is typedef as a pointer to unsigned int in
>> hbdefs.h. This means that the F_ERROR (-1) is made positive (2^32-1
>> or +4,294,967,295) so you have an invalid file pointer if a file
>> doesn't exist.
>> For example this pgm returns invalid handle 2^32-1
>> //-
>> function main()
>> ? "File Handle:", fopen("Nonsense.file")
>> return 0
>
> You are right and it's side effect of hack I added here:
>
> 2009-11-14 04:21 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> * harbour/include/hbdefs.h
> * added small hack to eliminate negative handles from 32 bit windows
> builds. Please remember that this trick can work only in 32 bit
> windows version. In 64 bit ones valid handle after casting to integer
> value can give negative 64 bit number so checking for wrong handle
> please compare them with FS_ERROR (-1) instead of using < 0 or sth
> like that. Otherwise your code may not work properly with some new
> windows versions or may even suddenly stop to work with existing
> ones even if they worked for some time without problems.
>
> I'll remove it soon.
> Thank you for the information.
> To all users. Please remember that on some platforms negative handles
> can be valid and only -1 indicates wrong handle (0 is valid handle on
> all supported platforms).
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] fopen(), fcreate(), etc.
On Thu, 26 Nov 2009, bill robertson wrote:
Hi,
> There is a problem with fopen() and I suspect fcreate(), etc in
> philes.c. In philes.c, you will notice that hb_fsOpen is cast to
> HB_NHANDLE which is typedef as a pointer to unsigned int in
> hbdefs.h. This means that the F_ERROR (-1) is made positive (2^32-1
> or +4,294,967,295) so you have an invalid file pointer if a file
> doesn't exist.
> For example this pgm returns invalid handle 2^32-1
> //-
> function main()
> ? "File Handle:", fopen("Nonsense.file")
> return 0
You are right and it's side effect of hack I added here:
2009-11-14 04:21 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbdefs.h
* added small hack to eliminate negative handles from 32 bit windows
builds. Please remember that this trick can work only in 32 bit
windows version. In 64 bit ones valid handle after casting to integer
value can give negative 64 bit number so checking for wrong handle
please compare them with FS_ERROR (-1) instead of using < 0 or sth
like that. Otherwise your code may not work properly with some new
windows versions or may even suddenly stop to work with existing
ones even if they worked for some time without problems.
I'll remove it soon.
Thank you for the information.
To all users. Please remember that on some platforms negative handles
can be valid and only -1 indicates wrong handle (0 is valid handle on
all supported platforms).
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13028] trunk/harbour
Revision: 13028 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13028&view=rev Author: vouchcac Date: 2009-11-26 17:37:41 + (Thu, 26 Nov 2009) Log Message: --- 2009-11-26 09:34 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) - contrib/hbide/resources/tabmodified.PNG * contrib/xhb/Makefile ! Changed the order of files in linklist. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/tests/demowvg.prg trunk/harbour/contrib/xhb/Makefile Removed Paths: - trunk/harbour/contrib/hbide/resources/tabmodified.PNG This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13027] trunk/harbour
Revision: 13027 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13027&view=rev Author: vouchcac Date: 2009-11-26 17:33:37 + (Thu, 26 Nov 2009) Log Message: --- 2009-11-26 09:32 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) - contrib/hbide/resources/tabmodified.PNG + contrib/hbide/resources/tabmodified.png ! Lower cased file name. Modified Paths: -- trunk/harbour/ChangeLog Added Paths: --- trunk/harbour/contrib/hbide/resources/tabmodified.png This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] fopen(), fcreate(), etc.
I confirm that display
File Handle: 4294967295
2009/11/26 bill robertson :
> Hi All,
>
> There is a problem with fopen() and I suspect fcreate(), etc in philes.c. In
> philes.c, you will notice that hb_fsOpen is cast to HB_NHANDLE which is
> typedef as a pointer to unsigned int in hbdefs.h. This means that the
> F_ERROR (-1) is made positive (2^32-1 or +4,294,967,295) so you have an
> invalid file pointer if a file doesn't exist.
>
> For example this pgm returns invalid handle 2^32-1
>
> //-
> function main()
> ? "File Handle:", fopen("Nonsense.file")
> return 0
>
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13025] trunk/harbour
I have Verified basic find and works List only is not managed (when activated must exclude replace) Search in current project,In folder/ subdir is not managed Possible have numbered row ,Goto possible multiple file in command line or open a hbp as list of field Having same command line that hbide so will be easy compile in hbmk A project strutture based on builder structure will be easy to develop For translation of hbide have you same way? My question are because i want try daily use for editing 2009/11/26 : > * contrib/hbide/ideactions.prg > + Implemented "Find" functionality. CTRL_F or icon can be clicked. > Input some string in "Find what" field and keep on pressing . > + Implemented "Print with Preview" of current source code. > ! Document Tab Image is toggled for "Modified and UnModified" states. > ! Fixed some more artifacts. > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] fopen(), fcreate(), etc.
Hi All,
There is a problem with fopen() and I suspect fcreate(), etc in philes.c. In
philes.c, you will notice that hb_fsOpen is cast to HB_NHANDLE which is
typedef as a pointer to unsigned int in hbdefs.h. This means that the
F_ERROR (-1) is made positive (2^32-1 or +4,294,967,295) so you have an
invalid file pointer if a file doesn't exist.
For example this pgm returns invalid handle 2^32-1
//-
function main()
? "File Handle:", fopen("Nonsense.file")
return 0
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13020] trunk/harbour
Hi Mindaugas,
First a Thank You.
Nothing related to these modifications but to ADS.
I reported a while back a bug in ads which is still not fixed.
after poisoning the record pointer by doing a SKIP, a index..while will
start from record 1, instead of from the current record
it's only on REMOTE
and only after a SKIP.
here is a test.
--
#INCLUDE "ads.ch"
PROC MAIN()
FIELD FLD1
LOCAL I
REQUEST ADS
//SET SERVER LOCAL
SET SERVER REMOTE
rddSetDefault( "ADSCDX" )
? "rdd:", rddSetDefault()
ERASE( "test.cdx" )
DBCREATE( "test.dbf", {{"FLD1", "N", 10 , 0}} )
USE test
INDEX ON FLD1 TAG TEMP
ORDSETFOCUS( "TEMP" )
? ORDSETFOCUS()
FOR I := 1 TO 100
APPEND BLANK
FLD1 := I
NEXT
ERASE("temp2.idx")
GO TOP
SKIP 50
//SEEK fld1 // <-will fix it.
INDEX ON FLD1 TAG TEMP2 WHILE FLD1 < 99 TO temp2.idx
? ORDSETFOCUS()
? ""
ORDSETFOCUS( "TEMP" )
? ORDSETFOCUS()
GO TOP
? FLD1
GO BOTTOM
? FLD1
ORDSETFOCUS( "TEMP2" )
? ORDSETFOCUS()
GO TOP
? FLD1
GO BOTTOM
? FLD1
USE
RETURN
-
result shoul be
rdd: ADSCDX
TEMP
TEMP2
TEMP
1
100
TEMP2
51
98
--
snaiperis wrote:
>
> Revision: 13020
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13020&view=rev
> Author: snaiperis
> Date: 2009-11-25 17:11:56 + (Wed, 25 Nov 2009)
>
>
>
--
View this message in context:
http://n2.nabble.com/SF-net-SVN-harbour-project-13020-trunk-harbour-tp4066231p4072049.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Error in command: @...GET LISTBOX, The list box's drop-down buttonn not appear
I have this:
D:\prueba>\hrbmingw\bin\harbour -build
Harbour 2.0.0beta3 (Rev. 13026)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Harbour Build Info
---
Version: Harbour 2.0.0beta3 (Rev. 13026)
Compiler: MinGW GNU C 3.4.5 (32-bit)
Platform: Windows XP 5.1.2600 Service Pack 3
PCode version: 0.2
ChangeLog last entry: 2009-11-26 12:18 UTC+0100 Przemyslaw Czerpak
(druzus/at/priv.onet.pl)
ChangeLog ID: ChangeLog 13026 2009-11-26 11:18:25Z druzus
Built on: Nov 26 2009 09:50:19
Build options:
Language options: (Clipper 5.3) (Clipper 5.x undoc) (Xbase++) (Flagship)
---
D:\prueba>lbh //info
Harbour Terminal: Windows native console
Harbour 2.0.0beta3 (Rev. 13026)
Windows XP 5.1.2600 Service Pack 3
DS avail=725864KB OS avail=2079616KB EMM avail=0KB MemStat:Off MT:Off
What could be?
Suggestions / help are welcome
TIA
BestRegars
GVS
Massimo Belgrano escribió:
I have tried but harbour report
Tipo : Tipo 2▼
Follow my //build
Harbour Build Info
---
Version: Harbour 2.0.0beta3 (Rev. 13026)
Compiler: MinGW GNU C 4.4.1 (32-bit)
Platform: Windows 7 6.1.7600
PCode version: 0.2
ChangeLog last entry: 2009-11-26 12:18 UTC+0100 Przemyslaw Czerpak (druzus/at/pr
iv.onet.pl)
ChangeLog ID: ChangeLog 13026 2009-11-26 11:18:25Z druzus
Built on: Nov 26 2009 12:22:47
Build options:
Language options: (Clipper 5.3) (Clipper 5.x undoc) (Xbase++) (Flagship)
---
// info
Harbour Terminal: Windows native console
Harbour 2.0.0beta3 (Rev. 13026)
Windows 7 6.1.7600
DS avail=1085800KB OS avail=2063320KB EMM avail=0KB MemStat:Off MT:Off
2009/11/26 http://news.gmane.org/gmane.comp.db.sqlite.general
:
--
#include "inkey.ch"
procedure main
LOCAL wTipo := "T2", aTipo := {}
AADD(aTipo,{"Tipo 1","T1"})
AADD(aTipo,{"Tipo 2","T2"})
AADD(aTipo,{"Tipo 3","T3"})
//
SET( _SET_EVENTMASK, INKEY_ALL )
MSETCURSOR( .T. )
CLS
@ 05,40,10,70 GET wTipo LISTBOX aTipo CAPTION '&Tipo :' DROPDOWN SCROLLBAR
COLOR "W/N,B/W+,W/N,W+/B,W/N,N/W*,G/W*,N/G"
READ
RETURN
--
Output in Clipper:
Tipo : Tipo 2▼
Output in Harbour:
Tipo : Tipo 2
The list box's drop-down buttonn not appear
TIA
Best Regards
GVS
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error in command: @...GET LISTBOX, The list box's drop-down buttonn not appear
I have tried but harbour report
Tipo : Tipo 2▼
Follow my //build
Harbour Build Info
---
Version: Harbour 2.0.0beta3 (Rev. 13026)
Compiler: MinGW GNU C 4.4.1 (32-bit)
Platform: Windows 7 6.1.7600
PCode version: 0.2
ChangeLog last entry: 2009-11-26 12:18 UTC+0100 Przemyslaw Czerpak (druzus/at/pr
iv.onet.pl)
ChangeLog ID: ChangeLog 13026 2009-11-26 11:18:25Z druzus
Built on: Nov 26 2009 12:22:47
Build options:
Language options: (Clipper 5.3) (Clipper 5.x undoc) (Xbase++) (Flagship)
---
// info
Harbour Terminal: Windows native console
Harbour 2.0.0beta3 (Rev. 13026)
Windows 7 6.1.7600
DS avail=1085800KB OS avail=2063320KB EMM avail=0KB MemStat:Off MT:Off
2009/11/26 http://news.gmane.org/gmane.comp.db.sqlite.general
:
>
> --
> #include "inkey.ch"
>
> procedure main
> LOCAL wTipo := "T2", aTipo := {}
>
> AADD(aTipo,{"Tipo 1","T1"})
> AADD(aTipo,{"Tipo 2","T2"})
> AADD(aTipo,{"Tipo 3","T3"})
>
> //
> SET( _SET_EVENTMASK, INKEY_ALL )
> MSETCURSOR( .T. )
> CLS
>
> @ 05,40,10,70 GET wTipo LISTBOX aTipo CAPTION '&Tipo :' DROPDOWN SCROLLBAR
> COLOR "W/N,B/W+,W/N,W+/B,W/N,N/W*,G/W*,N/G"
> READ
>
> RETURN
> --
>
> Output in Clipper:
>
> Tipo : Tipo 2 ▼
>
> Output in Harbour:
>
> Tipo : Tipo 2
> The list box's drop-down buttonn not appear
>
> TIA
>
> Best Regards
> GVS
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] speedtst and vm
Sorry, the second one is built with hbmk2 -mt -gc3 speedtst and not -gc2 as I wrongly wrote before. Maurilio. Maurilio Longo wrote: > Przemyslaw, > > I've made a couple of tests: in the first one speedtst was built with > > hbmk2 -mt speedtst > > in the second with > > hbmk2 -mt -gc2 speedtst > > Now, calling > > speedtst --thread=2 --scale > > on a PIV HT with OS/2 and a SMP kernel I see that the first speedtst when run > has a scaling factor of 1.18 while the second one has a scaling factor of > 1.32. > > Question is: is this simply a result of the more work the vm has to do > compared to the -gc3 build or are there serialization points inside the vm > which slow the first speedtst compared to the second? > > Best regards. > > Maurilio. > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error in command: @...GET LISTBOX, The list box's drop-down buttonn not appear
--
#include "inkey.ch"
procedure main
LOCAL wTipo := "T2", aTipo := {}
AADD(aTipo,{"Tipo 1","T1"})
AADD(aTipo,{"Tipo 2","T2"})
AADD(aTipo,{"Tipo 3","T3"})
//
SET( _SET_EVENTMASK, INKEY_ALL )
MSETCURSOR( .T. )
CLS
@ 05,40,10,70 GET wTipo LISTBOX aTipo CAPTION '&Tipo :' DROPDOWN
SCROLLBAR COLOR "W/N,B/W+,W/N,W+/B,W/N,N/W*,G/W*,N/G"
READ
RETURN
--
Output in Clipper:
Tipo : Tipo 2▼
Output in Harbour:
Tipo : Tipo 2
The list box's drop-down buttonn not appear
TIA
Best Regards
GVS
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Qt libs static link
I'd suggest to peek into INSTALL doc, where you'll find answers for all your build related questions. Found it on harbour INSTALL doc Thanks Viktor! Leandro Damasio -- From: "Viktor Szakáts" Sent: Thursday, November 26, 2009 10:35 AM To: "Harbour Project Main Developer List." Subject: Re: [Harbour] Qt libs static link Hi Leandro, I'd suggest to peek into INSTALL doc, where you'll find answers for all your build related questions. Brgds, Viktor On 2009 Nov 26, at 15:16, Leandro Damasio wrote: I mean, how to build HBqt based programs with QT libs statically linked? tks Leandro Damasio From: Leandro Damasio Sent: Thursday, November 26, 2009 10:21 AM To: Harbour Project Main Developer List. Subject: [Harbour] Qt libs static link Hello How to build hbqt programs with QT static libs, independent from QT dlls? Is it possible? Thanks Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
On Thu, 26 Nov 2009, David Arturo Macias Corona wrote:
Hi,
> About:
> "When Maurilio changed some OpenWatcom switches used to control calling
> convention then the problem disappeared"
>
> The problem never disappeared. After his tests I explained about
> switches and suggested him to review entire messages related to
> tests
> Before we tried with any switch combinations and never resolved. I
> have track of it
> So we are as we left in December 2008
Sorry but now I'm really confused. All what I know about results
of real life OS/2 test comes from you and Maurilio messages.
Now I'm OpenWatcom builds reading that it was never working
correctly in MT mode in whole Harbour history and always fail
in MT mode when second thread accessed GTOS2 function (I guess
that speedtst works correctly with current SVN code when is linked
with GTCGI).
Can you and Maurilio confirm it?
> The proper way is to review those messages to recall tests state,
> refresh our minds and then continue with new suggestions
Did it work in the past after modifications in build time switches or not?
If not then there is no reason to look for old messages.
> As was and is "hard to locate the exact problem" perhaps we should
> leave to resolve after Harbour 2.0 ( Dec 2009, "Harbour Winter 2009
> edition" )
To be clear. It _was_ hard to locate to exact problem but after your
test I know the exact problem so this part is resolved and it's not
related to Harbour source code at all. The problem is caused by code
generated by OpenWatom for functions which have in their body calls to
some of APIENTRY16 functions like KbdCharIn(). When non main thread
tries to execute such function then it GPFs. It's unimportant how
APIENTRY16 function is used. Important is only the fact that it's
used. I.e. if we have function like:
static int hb_gt_os2_ReadKey( PHB_GT pGT, int iEventMask )
{
return 0;
}
then it works but if we have function like:
static int hb_gt_os2_ReadKey( PHB_GT pGT, int iEventMask )
{
if( pGT == NULL )
KbdCharIn( s_key, IO_NOWAIT, ( HKBD ) * s_hk );
return 0;
}
Then it will GPF though pGT is always not NULL so KbdCharIn() is never
executed.
Above conclusion is the result of your test done in last year.
So there is only question about finding workaround in OpenWatcom build
configuration to resolve it. Of course if such workaround exists.
I thought that more or less intentionally Maurilio found it and it
was committed to Harbour repository.
These should be switches related to C stack usage i.e. switches to
control calling convention.
It's also possible that we may find some programing workaround,
i.e. using functions to encapsulate calls to APIENTRY16, i.e.
void hb_os2_KbdCharIn( PKBDKEYINFO pKbdInfo, USHORT flags, HKBD hKbd )
{
KbdCharIn( pKbdInfo, flags, hKbd );
}
and then use hb_os2_KbdCharIn() in hb_gt_os2_ReadKey() instead of
KbdCharIn(). It may help because hb_gt_os2_ReadKey() is used indirectly
by pointer to function and maybe only in such situation the OpenWatcom
bug is exploited. But such method is only hack which may not work or
suddenly stop to work in the future due to compile and link time
optimizations, i.e. compiler may automatically inline above function
creating the same code as for initial version.
> but if you want ( and I want ) to resolve immediatly, give me
> guidelines :-)
If you have some time to make tests then we can try to look for
workarounds for the problem but 1-st I would like to be sure if it
was working in the past and if yes then restore exact build time
switches used for working version to locate the ones which helped
to resolve the problem.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Short or long variable names ?
Thank you very much for your clarification. Part of my code dates back to dBaseIII+ fully interpreted code... I'm thinking about a particular case... I will test it and in case I will ask you again... thank you again Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Errore Excel with TOLE
Hello, using the class "Tole" to enter into the Excel object is created I get an error "-2147024891" (from the Microsoft documentation is returned to the following description of the General Access Denied Error). The program that runs on an error by the virtualization of a terminal server 2003 or 2000. Someone can help me? Thanks ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Qt libs static link
Hi Leandro, I'd suggest to peek into INSTALL doc, where you'll find answers for all your build related questions. Brgds, Viktor On 2009 Nov 26, at 15:16, Leandro Damasio wrote: > I mean, how to build HBqt based programs with QT libs statically linked? > tks > Leandro Damasio > > > From: Leandro Damasio > Sent: Thursday, November 26, 2009 10:21 AM > To: Harbour Project Main Developer List. > Subject: [Harbour] Qt libs static link > > Hello > How to build hbqt programs with QT static libs, independent from QT dlls? > Is it possible? > Thanks > Leandro Damasio > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Qt libs static link
I mean, how to build HBqt based programs with QT libs statically linked? tks Leandro Damasio From: Leandro Damasio Sent: Thursday, November 26, 2009 10:21 AM To: Harbour Project Main Developer List. Subject: [Harbour] Qt libs static link Hello How to build hbqt programs with QT static libs, independent from QT dlls? Is it possible? Thanks Leandro Damasio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13026] trunk/harbour
Fixed, thanks. Maurilio. dru...@users.sourceforge.net wrote: > Revision: 13026 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13026&view=rev > Author: druzus > Date: 2009-11-26 11:18:25 + (Thu, 26 Nov 2009) > > Log Message: > --- > 2009-11-26 12:18 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/vm/fm.c > ! fixed stupid typo I made just before recent commit which caused > GPF when not all mspaces where initialized > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/src/vm/fm.c > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
On Thu, 26 Nov 2009, David Arturo Macias Corona wrote: Hi, > and a summary ... > Harbour 13017, except where noted > Below are results using: > >hbmk2 -m -n -w -es2 -l -kmo -gc3 speedtst.prg > speedtst.exe >hbmk2 -m -n -w -es2 -l -kmo -gc3 -mt speedtst.prg > speedtst.exe > speedtst.exe --thread > speedtst.exe --thread=2 --scale > > and in same order > Same hardware used with OpenWatcom, gcc433, gcc335, so comparison > between C compilers are valid in this case > Strange result for OpenWatcom (13006) If you are talking about very slow MT mode then it's the cost of -bm switch. MT safe memory manager in OpenWatcom is very slow. BTW instead of using older version of SVN (13006) then you can use: set HB_USER_CFLAGS=-DHB_FM_STD_ALLOC to force default memory manager in given C compiler. > Everything is better with -DHB_FM_DL_ALLOC Thank you for your tests. I expected similar results. > Question (sorry but I do not what imply): > executables created with same source but different library type ( > OMF, a.out ) should have same performance ? It depends on internal format. It's possible that the speed will be noticeable different if two formats forces different addressing and code reallocation modes. I.e. some formats may forbid using direct memory global addresses and the code will be slower due to forced indirect addressing or runtime offset calculations. I do not know the details of OMF and a.out formats in OS/2 to given you precise answer. > Example: speedtst.exe build with gcc335 in OMF type and a.out type Your test results suggest that there is no significant speed difference between both formats. > OpenWatcom, with -DHB_FM_DL_ALLOC enabled by default > [ total application time: ]15.48 > [ total real time: ]...15.46 > > [ total application time: ]23.55 > [ total real time: ]...23.62 > > OpenWatcom, without -DHB_FM_DL_ALLOC ( and without -bm ) > > Note: Rev. 13006 > [ total application time: ]15.74 > [ total real time: ]...15.69 > > [ total application time: ]62.94 > [ total real time: ]...62.99 So in both cases OpenWatcom builds do not work in MT mode when more then one thread is created and GTOS2 is used and I would like to ask you to make tests with build switches (see my other mail) to reactivate settings which resolved the problem in the past. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] speedtst and vm
Przemyslaw, I've made a couple of tests: in the first one speedtst was built with hbmk2 -mt speedtst in the second with hbmk2 -mt -gc2 speedtst Now, calling speedtst --thread=2 --scale on a PIV HT with OS/2 and a SMP kernel I see that the first speedtst when run has a scaling factor of 1.18 while the second one has a scaling factor of 1.32. Question is: is this simply a result of the more work the vm has to do compared to the -gc3 build or are there serialization points inside the vm which slow the first speedtst compared to the second? Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Short or long variable names ?
On Thu, 26 Nov 2009, francesco perillo wrote: Hi, > > If you are asking about runtime speed overhead caused by longer variable > > names then there is no difference if you are using shorter or smaller > > variables names. LOCAL variable names are not stored in final binaries > > at all (with the exception to code emitted for debugger with -b switch) > For LOCALs, ok. They have a certain visibility and the compiler can > create optimized code. > For PRIVATE/PUBLIC... I can create these variables at runtime using > macros or internal calls... Yes it is but also in macro compiler they are accessed using addresses in symbol table. Looking for address is symbol table is done using binary search. > > > and PUBLIC, PRIVATE, FILED variables are not accessed by name but using > > pointers to symbol table > Sorry, just to have more infos.. > > Imagine a PUBLIC variable created at runtime; in this case the > compiler can't refer directly to symbol table position but must lookup > the variable name at runtime somehow... I may understand from your > words that harbour creates a local symbol table with only the variable > names and then does a "runtime binding" when entering the function > in this way it can handle visibility PUBLIC/PRIVATE... > In this way, in the pcode harbour only references "position 1 in the > symbol table" and it will be runtime engine to fill it with correct > values (or pointers to correct values) > I imagine it is more complicated than this, I just wanted to validate > the general idea When you compile code which uses memvars (public or private variables) then compiler generates references to symbol table which is register in global symbol table at application startup so later when application is executed it does not cause any speed overhead. Just simply accessing memvar variable which is -th symbol in generated symbol table we have PCODE like: HB_P_PUSHMEMVAR and then it's executed as: hb_stackPush( symbol_table[ ]->memvar ); without any name lookup, etc. As you can see in speedtst there is very minor speed difference (in practice unnoticable) between locals, statics and memvars. When you create memvar variable dynamically using macro compiler (in code like: 'var := 1' compiler knows that 'var' variable should be used and if it does not exists created so it adds 'var' to module symbol table and use this entry to access corresponding memvar variable without any name lookup) then macrocompiler also converts all symbols in compiled text into references to global symbol table and then generate PCODE which operates only on such addresses in similar as in PCODE generated by compiler but instead of using module symbol table it stores addresses directly in generated PCODE. So during execution there is also no name lookup. The only name scanning is part of macro compilation process and it uses binary search scanning global symbol table. Such scanning is done for all symbols in macrocompiled code, i.e. function and message names or fields not only for memvars and here the length of used symbols is in practice unimportant for speed. To see the difference you will have to create some program which will use only symbols like: "001" "002" [...] "XYX" [...] for all memvars, fields, function, messages, class names, etc. and even in such case the speed difference will be very small and hard to measure/notice and of course it will effect only the cost of macrocompilation but it's absolutely unimportant for later execution of such macrocompiled code. The same is in Clipper though the maximum symbol length (10 characters) is smaller then in Harbour. I know that you can find some incredible theories about memvars in Clipper using different mail list archives but 95% of them was created by people who did not know too much about real Clipper internals. Probably the only real serious problem with memvars in Clipper was limited size of global symbol table in 16-bit applications and then series memory problems which were exploited when this limit was exceed. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
Przemek: >> b) Failure of --thread (--scale) with GPF >> OS/2-Harbour-OpenWatcom 1.7a was failing in MT with more than one >>thread >> I expected it was fixed with 1.8, but no >> As you may remember, cause was isolated until routines for devices >>input >> When you decide we can continue to fix it >It was a bug in OpenWatcom which was exploited in some calling >convention when some specific OS2 API functions were used, i.e. some >mouse and keyboard functions in GTOS2. It was hard to locate the exact >problem because this bug was corrupting C call stack indirectly and the > problem was not exploited when the given OS2 API function was executed > but when Harbour function containing calls to such OS2 API function >was executed. >When Maurilio changed some OpenWatcom switches used to control calling >convention then the problem disappeared. I thought that we are keeping >these settings but if not then we will have to find them again and >reactivate. >It will be necessary to recompile Harbour using different switches. >First please try to remove -bm. >If it does not help in next step then please try to use stack calling >convention instead of register one and change: > CFLAGS += -5r -fp5 >to: > CFLAGS += -5s -fp5 >(If you are suing hbmk2 to create final application then you will have >to sync this switch and change -5r ot -5s in hbmk2.prg[2704] >If it does not help too then we will have to make some deeper tests. >Thank you very much. >In your tests DLMALLOC is also noticeable faster then memory managers >used by GCC in both versions though on single CPU machine the >difference is not so huge in MT tests. >The last thing which we should check is OpenWatcom OS2 build which >seems to fail with current build switches in MT mode. Can you make >some tests with different build switches, i.e. using stack calling >convention instead of register one? (-5r -> -5s) I tested with Harbour 13017 changing (-5r -> -5s) in os2\watcom.mk and hbmk2.prg Failure is the same: * 2009.11.26 06:15:24 OS/2 4.50 Harbour 2.0.0beta3 (Rev. 13017) (MT)+ Open Watcom C++ 12.80.8 (32-bit) x86 THREADS: 2 N_LOOPS: 100 1 th. 2 th. factor SYS1 808: The process has stopped. The software diagnostic code (exception code) is 0001. [E:\harbour911b\harbour\bin\os2\watcom] [E:\harbour911b\harbour\bin\os2\watcom]help sys1808 SYS1808: The process has stopped. The software diagnostic code (exception code) is ***. EXPLANATION: The program generated an exception that the system cannot resolve. The soft ware diagnostic code allows determination of what type of exception was generated. ACTION: Correct the problem or try a different version of the program. * About: "When Maurilio changed some OpenWatcom switches used to control calling convention then the problem disappeared" The problem never disappeared. After his tests I explained about switches and suggested him to review entire messages related to tests Before we tried with any switch combinations and never resolved. I have track of it So we are as we left in December 2008 The proper way is to review those messages to recall tests state, refresh our minds and then continue with new suggestions As was and is "hard to locate the exact problem" perhaps we should leave to resolve after Harbour 2.0 ( Dec 2009, "Harbour Winter 2009 edition" ) but if you want ( and I want ) to resolve immediatly, give me guidelines :-) David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Qt libs static link
Hello How to build hbqt programs with QT static libs, independent from QT dlls? Is it possible? Thanks Leandro Damasio___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 rev 13024
Przemyslaw Czerpak escreveu: Yes, stupid "last second" modification just before commit and without any tests :-(. Should be fixed by: 2009-11-26 12:18 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) Yes, is ok now (after a clean build). Thanks! Marcos Gambeta ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Short or long variable names ?
> If you are asking about runtime speed overhead caused by longer variable > names then there is no difference if you are using shorter or smaller > variables names. LOCAL variable names are not stored in final binaries > at all (with the exception to code emitted for debugger with -b switch) For LOCALs, ok. They have a certain visibility and the compiler can create optimized code. For PRIVATE/PUBLIC... I can create these variables at runtime using macros or internal calls... > and PUBLIC, PRIVATE, FILED variables are not accessed by name but using > pointers to symbol table Sorry, just to have more infos.. Imagine a PUBLIC variable created at runtime; in this case the compiler can't refer directly to symbol table position but must lookup the variable name at runtime somehow... I may understand from your words that harbour creates a local symbol table with only the variable names and then does a "runtime binding" when entering the function in this way it can handle visibility PUBLIC/PRIVATE... In this way, in the pcode harbour only references "position 1 in the symbol table" and it will be runtime engine to fill it with correct values (or pointers to correct values) I imagine it is more complicated than this, I just wanted to validate the general idea Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
Przemek: and a summary ... Harbour 13017, except where noted Below are results using: hbmk2 -m -n -w -es2 -l -kmo -gc3 speedtst.prg speedtst.exe hbmk2 -m -n -w -es2 -l -kmo -gc3 -mt speedtst.prg speedtst.exe speedtst.exe --thread speedtst.exe --thread=2 --scale and in same order Same hardware used with OpenWatcom, gcc433, gcc335, so comparison between C compilers are valid in this case Strange result for OpenWatcom (13006) Everything is better with -DHB_FM_DL_ALLOC Question (sorry but I do not what imply): executables created with same source but different library type ( OMF, a.out ) should have same performance ? Example: speedtst.exe build with gcc335 in OMF type and a.out type David Macias OpenWatcom, with -DHB_FM_DL_ALLOC enabled by default [ total application time: ]15.48 [ total real time: ]...15.46 [ total application time: ]23.55 [ total real time: ]...23.62 OpenWatcom, without -DHB_FM_DL_ALLOC ( and without -bm ) Note: Rev. 13006 [ total application time: ]15.74 [ total real time: ]...15.69 [ total application time: ]62.94 [ total real time: ]...62.99 gcc433, OMF type, with -DHB_FM_DL_ALLOC [ total application time: ]19.00 [ total real time: ]...18.94 [ total application time: ]24.94 [ total real time: ]...24.84 [ total application time: ].0.03 [ total real time: ]...25.33 [ total application time: ]50.58 [ total real time: ]..100.74 gcc433, OMF type, without -DHB_FM_DL_ALLOC [ total application time: ]24.26 [ total real time: ]...24.16 [ total application time: ]28.52 [ total real time: ]...28.40 [ total application time: ].0.06 [ total real time: ]...28.93 [ total application time: ]58.55 [ total real time: ]..115.96 gcc335, OMF type, with -DHB_FM_DL_ALLOC [ total application time: ]16.48 [ total real time: ]...16.46 [ total application time: ]23.19 [ total real time: ]...23.23 [ total application time: ].0.10 [ total real time: ]...22.15 [ total application time: ].0.06 [ total real time: ]...87.19 gcc335, OMF type, without -DHB_FM_DL_ALLOC [ total application time: ]22.06 [ total real time: ]...22.07 [ total application time: ]26.13 [ total real time: ]...26.06 [ total application time: ].0.26 [ total real time: ]...26.25 [ total application time: ]52.06 [ total real time: ]..103.38 gcc335, a.out type, with -DHB_FM_DL_ALLOC [ total application time: ]16.39 [ total real time: ]...16.19 [ total application time: ]22.03 [ total real time: ]...21.95 [ total application time: ].0.10 [ total real time: ]...22.53 [ total application time: ]44.35 [ total real time: ]...89.49 gcc335, a.out type, without -DHB_FM_DL_ALLOC [ total application time: ]22.16 [ total real time: ]...22.16 [ total application time: ]25.87 [ total real time: ]...25.87 [ total application time: ].0.13 [ total real time: ]...26.31 [ total application time: ].
Re: [Harbour] Short or long variable names ?
On Thu, 26 Nov 2009, francesco perillo wrote: Hi, > I'm doing some refactoring on really old old code. I have some 1 > letter, no meaning, confusing variable names... > I'd like to know if there is a "cost" associated with using longer > variable names in PUBLIC, PRIVATE and LOCAL. If you are asking about runtime speed overhead caused by longer variable names then there is no difference if you are using shorter or smaller variables names. LOCAL variable names are not stored in final binaries at all (with the exception to code emitted for debugger with -b switch) and PUBLIC, PRIVATE, FILED variables are not accessed by name but using pointers to symbol table so length of real names is unimportant. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 rev 13024
On Thu, 26 Nov 2009, Maurilio Longo wrote: FRANČEK, Marcos, Maurilio, > I've activated dlmalloc on OS/2 build, updated svn to rev. 13024, now, calling > hbmk2, even without passing any parameter to it I get: [...] > Exception c005 at address 0x1d44dc9f [..] > This is inside harbourm.dll and while exiting from the program. Can it be > something related to hb_xclean() ? Yes, stupid "last second" modification just before commit and without any tests :-(. Should be fixed by: 2009-11-26 12:18 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
On Wed, 25 Nov 2009, David Arturo Macias Corona wrote: > I send this message three times: send, no reject, never arrive to > Harbour list > Seem to be due message length Yes, the limit is 40KB. Longer messages have to be accepted by moderator. In such case you can store results in .zip file as Chen suggested. > This is the SECOND half ( gcc335 results ) Thank you very much. In your tests DLMALLOC is also noticeable faster then memory managers used by GCC in both versions though on single CPU machine the difference is not so huge in MT tests. The last thing which we should check is OpenWatcom OS2 build which seems to fail with current build switches in MT mode. Can you make some tests with different build switches, i.e. using stack calling convention instead of register one? (-5r -> -5s) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Book "Programming with Harbour"
Przemysław Czerpak escreveu: On Tue, 24 Nov 2009, Ranier Vilela wrote: Hi Ranier, I´d like invite you to write a book to Harbour "Programming with Harbour". I strong believe that your name is reference for all xbase developers, and your expertise will have large chance of success in sales. Clear part dedicated to xBase, I´d like suggest the chapter "C API", covered by topics about interfacing C with Harbour. This chapter is my greatest interest. I believe that book will be improve the development with Harbour. Thank you very much for you proposition but it's rather impossible that I will ever try to realize it. 1-st my English is too poor to even try. 2-nd I will not find time for it. I have a lot of my own business jobs and it's very hard for me to find enough spare time to develop Harbour. I also have family (wonderful wife, two daughters and son) and I would like to spend some time with them. I'm really sorry but finding additional spare time to write books is unrealistic idea for me now :-) best regards, Przemek Thank you for the answer. Sometimes we forget that we have family. Congratulations for your beautiful family. Best regards, Ranier Vilela ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13026] trunk/harbour
Revision: 13026 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13026&view=rev Author: druzus Date: 2009-11-26 11:18:25 + (Thu, 26 Nov 2009) Log Message: --- 2009-11-26 12:18 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/fm.c ! fixed stupid typo I made just before recent commit which caused GPF when not all mspaces where initialized Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/vm/fm.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Short or long variable names ?
I'm doing some refactoring on really old old code. I have some 1 letter, no meaning, confusing variable names... I'd like to know if there is a "cost" associated with using longer variable names in PUBLIC, PRIVATE and LOCAL. Francesco PS: I know the cost in negligible nowadays... just curious ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
Przemek:
more and more results ...
Harbour 13017
Below are results using:
hbmk2 -m -n -w -es2 -l -kmo -gc3 speedtst.prg
speedtst.exe
hbmk2 -m -n -w -es2 -l -kmo -gc3 -mt speedtst.prg
speedtst.exe
speedtst.exe --thread
speedtst.exe --thread=2 --scale
for:
e) gcc335, OMF type, with -DHB_FM_DL_ALLOC
f) gcc335, OMF type, without -DHB_FM_DL_ALLOC
Same hardware used with OpenWatcom, gcc433, gcc335, so comparison
between C compilers are valid in this case
David Macias
*** Start, e) gcc335, OMF type, with -DHB_FM_DL_ALLOC ***
2009.11.26 03:26:06 OS/2 4.50
Harbour 2.0.0beta3 (Rev. 13017) EMX GNU C 3.3.5 (32-bit) x86
THREADS: 0
N_LOOPS: 100
[ T000: empty loop overhead ]...0.03
[ T001: x := L_C ]..0.03
[ T002: x := L_N ]..0.00
[ T003: x := L_D ]..0.00
[ T004: x := S_C ]..0.03
[ T005: x := S_N ]..0.03
[ T006: x := S_D ]..0.00
[ T007: x := M->M_C ]...0.03
[ T008: x := M->M_N ]...0.03
[ T009: x := M->M_D ]...0.03
[ T010: x := M->P_C ]...0.03
[ T011: x := M->P_N ]...0.03
[ T012: x := M->P_D ]...0.03
[ T013: x := F_C ]..0.10
[ T014: x := F_N ]..0.13
[ T015: x := F_D ]..0.06
[ T016: x := o:Args ]...0.13
[ T017: x := o[2] ].0.06
[ T018: round( i / 1000, 2 ) ]..0.13
[ T019: str( i / 1000 ) ]...0.55
[ T020: val( s ) ]..0.16
[ T021: val( a [ i % 16 + 1 ] ) ]...0.29
[ T022: dtos( d - i % 1 ) ].0.29
[ T023: eval( { || i % 16 } ) ].0.26
[ T024: eval( bc := { || i % 16 } ) ]...0.16
[ T025: eval( { |x| x % 16 }, i ) ].0.19
[ T026: eval( bc := { |x| x % 16 }, i ) ]...0.16
[ T027: eval( { |x| f1( x ) }, i ) ]0.23
[ T028: eval( bc := { |x| f1( x ) }, i ) ]..0.16
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ].0.19
[ T030: x := &( "f1(" + str(i) + ")" ) ]2.10
[ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ]2.23
[ T032: x := valtype( x ) + valtype( i ) ].0.29
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ]..0.55
[ T034: x := a[ i % 16 + 1 ] == s ].0.19
[ T035: x := a[ i % 16 + 1 ] = s ]..0.26
[ T036: x := a[ i % 16 + 1 ] >= s ].0.23
[ T037: x := a[ i % 16 + 1 ] <= s ].0.23
[ T038: x := a[ i % 16 + 1 ] < s ]..0.23
[ T039: x := a[ i % 16 + 1 ] > s ]..0.23
[ T040: ascan( a, i % 16 ) ]0.26
[ T041: ascan( a, { |x| x == i % 16 } ) ]...1.97
[ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s,s2,a2 ]0.55
[ T043: x := a ]0.03
[ T044: x := {} ]...0.06
[ T045: f0() ]..0.03
[ T046: f1( i ) ]...0.06
[ T047: f2( c[1...8] ) ]0.06
[ T048: f2( c[1...4] ) ]0.06
[ T049: f2( @c[1...4] ) ]...0.03
[ T050: f2( @c[1...4] ), c2 := c ]..0.06
[ T051: f3( a, a2, s, i, s2, bc, i, n, x ) ]0.19
[ T052: f2( a ) ]...0.06
[ T053: x := f4() ].0.55
[ T054: x := f5() ].0.16
[ T055: x := space(16) ]0.10
[ T056: f_prv( c ) ]0.26
[ total application time: ]16.48
[ total real time: ]...16.46
2009.11.26 03:26:33 OS/2 4.50
Harbour 2.0.0beta3 (Rev.
[Harbour] Re: SF.net SVN: harbour-project:[12970] trunk/harbour
>The list block every post which is longer than 40KB. Such post wait for > the list moderator to manually approve it (as you can see all your >messages found their way to the list at the end). >In the future, just ZIP such long text and attached it to the message. OK, thanks Chen Just for comment, sometimes my mail service provider or any other in the road block messages with .zip attached without notification, so I try to avoid .zip attachments David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13024] trunk/harbour
> Hi Viktor, > > Nobody desire this, OK, I just proposed an another way to build them in the > future. No, I f.e. absolutely desire this, but IMO it's just premature to start this cleanup with the build system. So far I saw no reaction whatsoever to any of my propositions regarding the removal of monolithic parts of hbqt lib, which gives me not much motivation to invest more time on the build-side, since it may well turn out to be a waste of time. That's all. To repeat: If someone cleans hbqt from any such cross QT subsystem dependencies, I'll be the first to adapt the build system accordingly. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13025] trunk/harbour
Hi Pritpal, One minor report: One of the files have uppercase .PNG extension. This will create problems on case-sensitive file systems, so could you correct it to have lowercase .png? With SVN you first have to delete it and readd it afterwards. Brgds, Viktor On 2009 Nov 26, at 11:29, vouch...@users.sourceforge.net wrote: > Revision: 13025 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13025&view=rev > Author: vouchcac > Date: 2009-11-26 10:29:57 + (Thu, 26 Nov 2009) > > Log Message: > --- > 2009-11-26 02:27 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbqt/hbqt_slots.cpp > * contrib/hbqt/hbqt_slots.h > > * contrib/hbqt/qtgui/QLabel.cpp > * contrib/hbqt/qth/QLabel.qth > > + contrib/hbide/resources/tabcmodified.png > + contrib/hbide/resources/tabmodified.PNG > + contrib/hbide/resources/tabreadonly.png > + contrib/hbide/resources/tabunmodified.png > > * contrib/hbide/hbide.prg > * contrib/hbide/ideactions.prg >+ Implemented "Find" functionality. CTRL_F or icon can be clicked. > Input some string in "Find what" field and keep on pressing . >+ Implemented "Print with Preview" of current source code. >! Document Tab Image is toggled for "Modified and UnModified" states. >! Fixed some more artifacts. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbide/hbide.prg >trunk/harbour/contrib/hbide/ideactions.prg >trunk/harbour/contrib/hbqt/hbqt_slots.cpp >trunk/harbour/contrib/hbqt/hbqt_slots.h >trunk/harbour/contrib/hbqt/qtgui/QLabel.cpp >trunk/harbour/contrib/hbqt/qth/QLabel.qth > > Added Paths: > --- >trunk/harbour/contrib/hbide/resources/tabcmodified.png >trunk/harbour/contrib/hbide/resources/tabmodified.PNG >trunk/harbour/contrib/hbide/resources/tabreadonly.png >trunk/harbour/contrib/hbide/resources/tabunmodified.png > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] SF.net SVN: harbour-project:[13024] trunk/harbour
Hi Viktor, Nobody desire this, OK, I just proposed an another way to build them in the future. Best regards, István -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts Sent: 2009. november 26. 11:22 To: Harbour Project Main Developer List. Subject: Re: [Harbour] SF.net SVN: harbour-project:[13024] trunk/harbour Hi Istvan, Pritpal, BTW, I've just checked, and webkit references (in .mk file) and sources are still on SVN, although they are not used anymore. IMO, these should be deleted. Can someone of you do this? Brgds, Viktor On 2009 Nov 26, at 10:34, Bisz István wrote: > Hi Viktor, > >> + Added QtUiTools for darwin. (tested) >> + Added QtUiTools for linux. (not tested) >> ! Added QtUiTools lib for static QT hbqts.hbc. > > I think we will not have problems with the QtUiTools integration on the > native linux builds. As we know, the problem with QtWebkit appears just > during the cross builds, making the hbqt lib build impossible. Now this is > solved with a drastic temporary solution by cutting out the references to > QtWebkit headers and functions from hbqt_slots.h and hbqt_slots.c. Probably > the final solution will contain new hbqtWebKit_slots.h and hbqtWebKit_slots.c > in qtwebkit subfolder. > > My proposal is to help the designers in building new Qt interfaces with > correct interdependencies, avoiding a monolithic structure, with updating the > Qt make system. > > Now we have the following sequence in the hbqt/detect.mk: > ... > ifneq ($(HB_HAS_QT),) > ifeq ($(_QT_DARWIN),yes) > HB_CFLAGS += -I/Library/Frameworks/QtCore.framework/Headers > HB_CFLAGS += -I/Library/Frameworks/QtGui.framework/Headers > HB_CFLAGS += -I/Library/Frameworks/QtNetwork.framework/Headers > HB_CFLAGS += -I/Library/Frameworks/QtWebKit.framework/Headers > else > HB_CFLAGS += $(foreach d,$(HB_HAS_QT),-I$(d) -I$(d)/Qt -I$(d)/QtCore > -I$(d)/QtGui -I$(d)/QtNetwork -I$(d)/QtWebKit) > endif > ... > > The above sequence offers undesired references. For example HB_CFLAGS should > not contain -I/Library/Frameworks/QtWebKit.framework/Headers or the linux > correspondent (etc.) in the hbqt, hbqtcore, hbqtgui and hbqtnetwork builds. > This include-path should be used just for the hbqtwebkit library build. > > Please analyze the idea mentioned above, taking into consideration that a new > element will appear soon due to Pritpal developments. > A flexible solution here will make the Qt interface more clear without > undesired interdependencies. > > Best regards, > István > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13025] trunk/harbour
Revision: 13025 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13025&view=rev Author: vouchcac Date: 2009-11-26 10:29:57 + (Thu, 26 Nov 2009) Log Message: --- 2009-11-26 02:27 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/hbqt_slots.cpp * contrib/hbqt/hbqt_slots.h * contrib/hbqt/qtgui/QLabel.cpp * contrib/hbqt/qth/QLabel.qth + contrib/hbide/resources/tabcmodified.png + contrib/hbide/resources/tabmodified.PNG + contrib/hbide/resources/tabreadonly.png + contrib/hbide/resources/tabunmodified.png * contrib/hbide/hbide.prg * contrib/hbide/ideactions.prg + Implemented "Find" functionality. CTRL_F or icon can be clicked. Input some string in "Find what" field and keep on pressing . + Implemented "Print with Preview" of current source code. ! Document Tab Image is toggled for "Modified and UnModified" states. ! Fixed some more artifacts. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/ideactions.prg trunk/harbour/contrib/hbqt/hbqt_slots.cpp trunk/harbour/contrib/hbqt/hbqt_slots.h trunk/harbour/contrib/hbqt/qtgui/QLabel.cpp trunk/harbour/contrib/hbqt/qth/QLabel.qth Added Paths: --- trunk/harbour/contrib/hbide/resources/tabcmodified.png trunk/harbour/contrib/hbide/resources/tabmodified.PNG trunk/harbour/contrib/hbide/resources/tabreadonly.png trunk/harbour/contrib/hbide/resources/tabunmodified.png This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13024] trunk/harbour
Hi Istvan, Pritpal, BTW, I've just checked, and webkit references (in .mk file) and sources are still on SVN, although they are not used anymore. IMO, these should be deleted. Can someone of you do this? Brgds, Viktor On 2009 Nov 26, at 10:34, Bisz István wrote: > Hi Viktor, > >> + Added QtUiTools for darwin. (tested) >> + Added QtUiTools for linux. (not tested) >> ! Added QtUiTools lib for static QT hbqts.hbc. > > I think we will not have problems with the QtUiTools integration on the > native linux builds. As we know, the problem with QtWebkit appears just > during the cross builds, making the hbqt lib build impossible. Now this is > solved with a drastic temporary solution by cutting out the references to > QtWebkit headers and functions from hbqt_slots.h and hbqt_slots.c. Probably > the final solution will contain new hbqtWebKit_slots.h and hbqtWebKit_slots.c > in qtwebkit subfolder. > > My proposal is to help the designers in building new Qt interfaces with > correct interdependencies, avoiding a monolithic structure, with updating the > Qt make system. > > Now we have the following sequence in the hbqt/detect.mk: > ... > ifneq ($(HB_HAS_QT),) > ifeq ($(_QT_DARWIN),yes) > HB_CFLAGS += -I/Library/Frameworks/QtCore.framework/Headers > HB_CFLAGS += -I/Library/Frameworks/QtGui.framework/Headers > HB_CFLAGS += -I/Library/Frameworks/QtNetwork.framework/Headers > HB_CFLAGS += -I/Library/Frameworks/QtWebKit.framework/Headers > else > HB_CFLAGS += $(foreach d,$(HB_HAS_QT),-I$(d) -I$(d)/Qt -I$(d)/QtCore > -I$(d)/QtGui -I$(d)/QtNetwork -I$(d)/QtWebKit) > endif > ... > > The above sequence offers undesired references. For example HB_CFLAGS should > not contain -I/Library/Frameworks/QtWebKit.framework/Headers or the linux > correspondent (etc.) in the hbqt, hbqtcore, hbqtgui and hbqtnetwork builds. > This include-path should be used just for the hbqtwebkit library build. > > Please analyze the idea mentioned above, taking into consideration that a new > element will appear soon due to Pritpal developments. > A flexible solution here will make the Qt interface more clear without > undesired interdependencies. > > Best regards, > István > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbmk2 rev 13024
Przemyslaw, I've activated dlmalloc on OS/2 build, updated svn to rev. 13024, now, calling hbmk2, even without passing any parameter to it I get: hbmk2 [options] [] Options: -ooutput file name -llink with library. should be without path, extension and 'lib' prefix (unless part of libname). -Ladditional path to search for libraries -i|-incpath= additional path to search for headers -static|-sharedlink with static/shared libs -mt|-stlink with multi/single-thread VM -gt link with GT GT driver, can be repeated to link with more GTs. First one will be the default at runtime -hblib create static library -hbdyn create dynamic library -help|--help long help Exception c005 at address 0x1d44dc9f Killed by SIGSEGV pid=0x6194 ppid=0x0050 tid=0x0001 slot=0x00e1 pri=0x0200 mc=0x0001 E:\HARBOUR\BIN\HBMK2.EXE HARBOURM 0:002adc9f cs:eip=005b:1d44dc9f ss:esp=0053:021aff20 ebp=021aff38 ds=0053 es=0053 fs=150b gs= efl=00010202 eax= ebx=1e5b0358 ecx=0005 edx=045602bc edi=0001 esi= Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. This is inside harbourm.dll and while exiting from the program. Can it be something related to hb_xclean() ? Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13024] trunk/harbour
Hi Istvan, >> + Added QtUiTools for darwin. (tested) >> + Added QtUiTools for linux. (not tested) >> ! Added QtUiTools lib for static QT hbqts.hbc. > > I think we will not have problems with the QtUiTools integration on the > native linux builds. As we know, the problem with QtWebkit appears just > during the cross builds, making the hbqt lib build impossible. Now this is > solved with a drastic temporary solution by cutting out the references to > QtWebkit headers and functions from hbqt_slots.h and hbqt_slots.c. Probably > the final solution will contain new hbqtWebKit_slots.h and hbqtWebKit_slots.c > in qtwebkit subfolder. > > My proposal is to help the designers in building new Qt interfaces with > correct interdependencies, avoiding a monolithic structure, with updating the > Qt make system. > > Now we have the following sequence in the hbqt/detect.mk: > ... > ifneq ($(HB_HAS_QT),) > ifeq ($(_QT_DARWIN),yes) > HB_CFLAGS += -I/Library/Frameworks/QtCore.framework/Headers > HB_CFLAGS += -I/Library/Frameworks/QtGui.framework/Headers > HB_CFLAGS += -I/Library/Frameworks/QtNetwork.framework/Headers > HB_CFLAGS += -I/Library/Frameworks/QtWebKit.framework/Headers > else > HB_CFLAGS += $(foreach d,$(HB_HAS_QT),-I$(d) -I$(d)/Qt -I$(d)/QtCore > -I$(d)/QtGui -I$(d)/QtNetwork -I$(d)/QtWebKit) > endif > ... > > The above sequence offers undesired references. For example HB_CFLAGS should > not contain -I/Library/Frameworks/QtWebKit.framework/Headers or the linux > correspondent (etc.) in the hbqt, hbqtcore, hbqtgui and hbqtnetwork builds. > This include-path should be used just for the hbqtwebkit library build. > > Please analyze the idea mentioned above, taking into consideration that a new > element will appear soon due to Pritpal developments. > A flexible solution here will make the Qt interface more clear without > undesired interdependencies. I know about this, but until the source code itself contains monolithic code, I don't see any point on spending time to solve this problem on the build level. I would just be a waste of time at this point. As I wrote in prev mail, IMO it'd be much better to avoid hbqt lib altogether and move any lib dependent stuff (including above flags) to qt lib level. But, this job needs to be solved on source level first, and it's enough to follow by build system afterwards. After the source will have been changed and hbqt eliminated, above build level change is quite easy to make. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2, Visual C++ 2008 Express and GPF
Marcos Gambeta escreveu: > Compiling Harbour (r.13024) with Visual C++ 2008 Express, i have gpf´s when calling hbmk2. Sorry, i reported the same problem reported by Francek Prijatelj. Regards, Marcos Gambeta ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] SF.net SVN: harbour-project:[13024] trunk/harbour
Hi Viktor, >+ Added QtUiTools for darwin. (tested) >+ Added QtUiTools for linux. (not tested) >! Added QtUiTools lib for static QT hbqts.hbc. I think we will not have problems with the QtUiTools integration on the native linux builds. As we know, the problem with QtWebkit appears just during the cross builds, making the hbqt lib build impossible. Now this is solved with a drastic temporary solution by cutting out the references to QtWebkit headers and functions from hbqt_slots.h and hbqt_slots.c. Probably the final solution will contain new hbqtWebKit_slots.h and hbqtWebKit_slots.c in qtwebkit subfolder. My proposal is to help the designers in building new Qt interfaces with correct interdependencies, avoiding a monolithic structure, with updating the Qt make system. Now we have the following sequence in the hbqt/detect.mk: ... ifneq ($(HB_HAS_QT),) ifeq ($(_QT_DARWIN),yes) HB_CFLAGS += -I/Library/Frameworks/QtCore.framework/Headers HB_CFLAGS += -I/Library/Frameworks/QtGui.framework/Headers HB_CFLAGS += -I/Library/Frameworks/QtNetwork.framework/Headers HB_CFLAGS += -I/Library/Frameworks/QtWebKit.framework/Headers else HB_CFLAGS += $(foreach d,$(HB_HAS_QT),-I$(d) -I$(d)/Qt -I$(d)/QtCore -I$(d)/QtGui -I$(d)/QtNetwork -I$(d)/QtWebKit) endif ... The above sequence offers undesired references. For example HB_CFLAGS should not contain -I/Library/Frameworks/QtWebKit.framework/Headers or the linux correspondent (etc.) in the hbqt, hbqtcore, hbqtgui and hbqtnetwork builds. This include-path should be used just for the hbqtwebkit library build. Please analyze the idea mentioned above, taking into consideration that a new element will appear soon due to Pritpal developments. A flexible solution here will make the Qt interface more clear without undesired interdependencies. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbmk2, Visual C++ 2008 Express and GPF
Compiling Harbour (r.13024) with Visual C++ 2008 Express, i have gpf´s when calling hbmk2. hb_out.log Application Internal Error - D:\hrbsvnmsvc\harbour-project\harbour\bin\hbmk2.exe Terminated at: 2009.11.26 07:21:38 Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:0043C336 EAX: EBX:0001 ECX: EDX: ESI:004FC2F8 EDI: EBP:0012FF88 CS:EIP:001B:0043C336 SS:ESP:0023:0012FF00 DS:0023 ES:0023 FS:003B GS: Flags:00010202 CS:EIP: 8B 47 20 33 ED 3B 05 70 C3 4F 00 75 48 39 2D 74 SS:ESP: 0001 0012FF88 0043EFC5 001522A4 0006 004568B6 001841B0 7FFD7000 00456CBC 0001 0001 00152334 C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... 0043C336 0012FF88 0012FF94 7604D0E9 7FFD7000 7604D0E9 0012FF94 0012FFD4 76E619BB 7FFD7000 7676586C 7FFD7000 C005 7609FD89 7609FD89 76E619BB 0012FFD4 0012FFEC 76E6198E 00488518 7FFD7000 Modules: 0x0040 0x00101000 D:\hrbsvnmsvc\harbour-project\harbour\bin\hbmk2.exe 0x76E2 0x00127000 C:\Windows\system32\ntdll.dll 0x7600 0x000DC000 C:\Windows\system32\kernel32.dll 0x75D4 0x0009D000 C:\Windows\system32\USER32.dll 0x754F 0x0004B000 C:\Windows\system32\GDI32.dll 0x760E 0x000C6000 C:\Windows\system32\ADVAPI32.dll 0x761B 0x000C3000 C:\Windows\system32\RPCRT4.dll 0x754D 0x0001E000 C:\Windows\system32\IMM32.DLL 0x756D 0x000C8000 C:\Windows\system32\MSCTF.dll 0x76FC 0x000AA000 C:\Windows\system32\msvcrt.dll 0x7707 0x9000 C:\Windows\system32\LPK.DLL 0x75CC 0x0007D000 C:\Windows\system32\USP10.dll OS is Vista Ultimate SP2. Regards, Marcos Gambeta ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error compiling last revision
Hi Building last revision (platform : WinXP MSVC8), i get following errors: ./bin/win/msvc/hbrun.exe --hb:gtcgi ./bin/postinst.prg ! Making C:\HRB\msvc_D_Tr\bin\hbmk.cfg... .\bin\postinst.bat ! Making shared version of Harbour binaries... hbrun.c Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:0043C3F6 EAX: EBX:0001 ECX: EDX: ESI:004FE3B8 EDI: EBP: CS:EIP:001B:0043C3F6 SS:ESP:0023:0012FF2C DS:0023 ES:0023 FS:003B GS: Flags:00010202 CS:EIP: 8B 47 20 33 ED 3B 05 30 E4 4F 00 75 48 39 2D 34 SS:ESP: 0001 0043F0B5 003B22A4 0006 00456806 0A28 00143088 7C80AA49 0012FFC0 00456C1C 0001 0001 C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... Modules: 0x0040 0x00103000 C:\HRB\SVN\SRC-SVN\bin\win\msvc\hbmk2.exe 0x7C90 0x000B C:\WINDOWS\system32\ntdll.dll 0x7C80 0x000F4000 C:\WINDOWS\system32\kernel32.dll 0x77D4 0x0009 C:\WINDOWS\system32\USER32.dll 0x77F1 0x00046000 C:\WINDOWS\system32\GDI32.dll 0x77B4 0x00022000 C:\WINDOWS\system32\Apphelp.dll 0x77DD 0x0009B000 C:\WINDOWS\system32\ADVAPI32.DLL 0x77E7 0x00091000 C:\WINDOWS\system32\RPCRT4.dll hbmk2.c Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:0043C3F6 EAX: EBX:0001 ECX: EDX: ESI:004FE3B8 EDI: EBP: CS:EIP:001B:0043C3F6 SS:ESP:0023:0012FF2C DS:0023 ES:0023 FS:003B GS: Flags:00010202 CS:EIP: 8B 47 20 33 ED 3B 05 30 E4 4F 00 75 48 39 2D 34 SS:ESP: 0001 0043F0B5 003B22A4 0006 00456806 0A28 00143088 7C80AA49 0012FFC0 00456C1C 0001 0001 C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... Modules: 0x0040 0x00103000 C:\HRB\SVN\SRC-SVN\bin\win\msvc\hbmk2.exe 0x7C90 0x000B C:\WINDOWS\system32\ntdll.dll 0x7C80 0x000F4000 C:\WINDOWS\system32\kernel32.dll 0x77D4 0x0009 C:\WINDOWS\system32\USER32.dll 0x77F1 0x00046000 C:\WINDOWS\system32\GDI32.dll 0x77DD 0x0009B000 C:\WINDOWS\system32\ADVAPI32.DLL 0x77E7 0x00091000 C:\WINDOWS\system32\RPCRT4.dll BRGS Franček <>___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12970] trunk/harbour
> I also think that it's time to enable by default HB_GC_AUTO. With new +1 Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
