[Harbour] SF.net SVN: harbour-project:[12800] trunk/harbour
Revision: 12800 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12800&view=rev Author: vszakats Date: 2009-10-31 09:47:47 + (Sat, 31 Oct 2009) Log Message: --- 2009-10-31 10:45 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) + w64-make.exe + Added win64 build of GNU Make 3.81.90-CVS-20090901. Experimental. On 64-bit Windows systems it's generally recommended to use this version, but please be aware of the experimental nature of this build yet. There are some pending patches in GNU Make bug tracker, plus latest CVS is broken so I used the latest good one. Modified Paths: -- trunk/harbour/ChangeLog Added Paths: --- trunk/harbour/w64-make.exe This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12801] trunk/harbour
Revision: 12801 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12801&view=rev Author: druzus Date: 2009-10-31 11:44:18 + (Sat, 31 Oct 2009) Log Message: --- 2009-10-31 12:44 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rdd/dbfcdx/dbfcdx1.c % added small protection against code which may want to create degenerated index tree using very large keys (over 158 bytes length) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12802] trunk/harbour
Revision: 12802 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12802&view=rev Author: druzus Date: 2009-10-31 15:42:51 + (Sat, 31 Oct 2009) Log Message: --- 2009-10-31 16:42 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/rddads/ads1.c ! In APPEND metohd generate RT error EG_APPENDLOCK only if ACE returns 1024 error code (Append Lock Failed). In all other cases generate EG_CORRUPTION RTE. This modifications allows to early detect some serious problems like index corruptions in Mindaugas example with long keys in ADSCDX. Warning! Before ADS RDD generated EG_APPENDLOCK for each errors returned by AdsAppendRecord() and they were caught by default error handler (ERRORSYS) and silently converted to NetErr(). Now only for 1024 ACE error which is real append lock error EG_APPENDLOCK is generated and all other errors will not be silently ignored so it's also possible that this modification will exploit some errors in concurrent accessed which are not reported by ADS/ACE as 1024 and maybe we will have to report them as EG_APPENDLOCK too. In such case please send information about such error codes here. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/rddads/ads1.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12803] trunk/harbour
Revision: 12803 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12803&view=rev Author: vouchcac Date: 2009-10-31 17:36:49 + (Sat, 31 Oct 2009) Log Message: --- 2009-10-31 10:23 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/generator/hbqtgen.prg * contrib/hbqt/hbqt.h * contrib/hbqt/hbqt_destruct.cpp * contrib/hbqt/hbqt_slots.cpp * contrib/hbqt/hbqt_slots.h * contrib/hbqt/moc_slots.cpp * contrib/hbxbp/tests/demoxbp.prg * contrib/hbxbp/xbpbrowse.prg * contrib/hbxbp/xbpdialog.prg * contrib/hbxbp/xbpgeneric.prg * contrib/hbxbp/xbpmenubar.prg * contrib/hbxbp/xbpwindow.prg * contrib/qtgui/QTableView.cpp * contrib/qtgui/TQTableView.prg ! Some more debug information included. Please note that the build may be broken, so bear with me for a couple of days. Lorenzo, you can continue with experiments. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/generator/hbqtgen.prg trunk/harbour/contrib/hbqt/hbqt.h trunk/harbour/contrib/hbqt/hbqt_destruct.cpp trunk/harbour/contrib/hbqt/hbqt_slots.cpp trunk/harbour/contrib/hbqt/hbqt_slots.h trunk/harbour/contrib/hbqt/moc_slots.cpp trunk/harbour/contrib/hbqt/qtgui/QTableView.cpp trunk/harbour/contrib/hbqt/qtgui/TQTableView.prg trunk/harbour/contrib/hbqt/qth/QTableView.qth trunk/harbour/contrib/hbxbp/tests/demoxbp.prg trunk/harbour/contrib/hbxbp/xbpbrowse.prg trunk/harbour/contrib/hbxbp/xbpdialog.prg trunk/harbour/contrib/hbxbp/xbpgeneric.prg trunk/harbour/contrib/hbxbp/xbpmenubar.prg trunk/harbour/contrib/hbxbp/xbpwindow.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HBQT - HBXBP - Releaseing the Objects and Memory
Hello Everybody Here are the results of debug output of demoxbp.exe. http://old.nabble.com/file/p26144968/2.zip 2.zip And this is the consolidated result of log file above: OBJECTCreated Released == QApplication 1 => 1 QWidget 9 => 9 QVariant 1 => 1 QEventLoop1 => 1 QSize-- => 2 QDesktopWidget1 => 1 QColor 33 => 33 QMenuBar 1 => 1 QMenu 4 => 4 QAction 12 => 12 QKeySequence 2 => 2 QStatusBar1 => 1 QPixmap 3 => 9 QCursor 5 => 5 QToolBar 1 => 1 QTabWidget1 => 1 QFrame 16 => 16 QScrollBar4 => 4 QHeaderView 3 => 3 QGridLayout 1 => 1 QFontMetrics 12 => 12 QFont-- => 12 QTextEdit 2 => 2 QCheckBox 4 => 4 QRadioButton 4 => 4 QSpinBox 3 => 3 QTreeWidget 2 => 2 QTreeWidgetItem 99 => 100 ( 220-417 == 98 Items ) QTreeWidgetItem 99 => 100 ( 422-619 == 98 Items ) QListView 2 => 2 QStringList 2 => 2 QStringListModel 2 => 2 QLineEdit 3 => 3 QComboBox 1 => 1 QPushButton 15 => 15 QTextCursor -- => 7 QTextCharFormat -- => 9 QBrush2 => 4 QWebView 1 => 1 QUrl 1 => 1 QGroupBox 1 => 1 QLabel7 => 7 QImage1 => 1 QIcon-- => 1 QPoint1 => 1 QModelIndex -- => 6 hbqt_ptrTOgcpointer 46 => -- -- 37 QPixmap 6 QBrush 2 45 It is one-to-one means whatever objects appln is creating with new Q() or creating dynamically is being released properly. But still 1.3 MB of memory is never reclaimed with next invocation of "One More Dialog". Application reclaims 1.7 MB but cannot reclaim 1.3 MB. If we look at the zipped 2.log file, we can see that at system level no memory is released though Harbours internal items gets released. Only at the end of the Main() function system releases 1.7 MB. Any ideas what could be points to see through or debug more. It is verified that Qt level delete ( Q* ) ph ; is executed as intended and object is releases but system memory stays the same. This is the only issue left with Harbour-Qt. Once we resolve it we are through. Note that before introducing collectible pointers not even a single byte was being reclaimed. Now at least we are able to get back more than half of memory. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBQT---HBXBP---Releaseing-the-Objects-and-Memory-tp26144968p26144968.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT - HBXBP - Releaseing the Objects and Memory
Hi Pritpal, Huge effort and very nice job. I'm worried about one remaining thing: the monolithic nature of hbqt_slots.cpp. I'm not sure of the meaning of it, but it seems to contain references to various QT objects (f.e. even QTWebKit) in one central location. These object are now implemented in separate libs, and I wonder if referencing them like this wouldn't cause pulling of unnecessary parts in final apps? After testing demoxbp, the Web tab doesn't load all images, plus it flickers when moving around with the mouse, sometimes the whole page reappears only when going above the title bar f.e. Same effect can be seen in Lists tab with the scrollbars. Brgds, Viktor On 2009 Oct 31, at 19:48, Pritpal Bedi wrote: Hello Everybody Here are the results of debug output of demoxbp.exe. http://old.nabble.com/file/p26144968/2.zip 2.zip And this is the consolidated result of log file above: OBJECTCreated Released == QApplication 1 => 1 QWidget 9 => 9 QVariant 1 => 1 QEventLoop1 => 1 QSize-- => 2 QDesktopWidget1 => 1 QColor 33 => 33 QMenuBar 1 => 1 QMenu 4 => 4 QAction 12 => 12 QKeySequence 2 => 2 QStatusBar1 => 1 QPixmap 3 => 9 QCursor 5 => 5 QToolBar 1 => 1 QTabWidget1 => 1 QFrame 16 => 16 QScrollBar4 => 4 QHeaderView 3 => 3 QGridLayout 1 => 1 QFontMetrics 12 => 12 QFont-- => 12 QTextEdit 2 => 2 QCheckBox 4 => 4 QRadioButton 4 => 4 QSpinBox 3 => 3 QTreeWidget 2 => 2 QTreeWidgetItem 99 => 100 ( 220-417 == 98 Items ) QTreeWidgetItem 99 => 100 ( 422-619 == 98 Items ) QListView 2 => 2 QStringList 2 => 2 QStringListModel 2 => 2 QLineEdit 3 => 3 QComboBox 1 => 1 QPushButton 15 => 15 QTextCursor -- => 7 QTextCharFormat -- => 9 QBrush2 => 4 QWebView 1 => 1 QUrl 1 => 1 QGroupBox 1 => 1 QLabel7 => 7 QImage1 => 1 QIcon-- => 1 QPoint1 => 1 QModelIndex -- => 6 hbqt_ptrTOgcpointer 46 => -- -- 37 QPixmap 6 QBrush 2 45 It is one-to-one means whatever objects appln is creating with new Q() or creating dynamically is being released properly. But still 1.3 MB of memory is never reclaimed with next invocation of "One More Dialog". Application reclaims 1.7 MB but cannot reclaim 1.3 MB. If we look at the zipped 2.log file, we can see that at system level no memory is released though Harbours internal items gets released. Only at the end of the Main() function system releases 1.7 MB. Any ideas what could be points to see through or debug more. It is verified that Qt level delete ( Q* ) ph ; is executed as intended and object is releases but system memory stays the same. This is the only issue left with Harbour-Qt. Once we resolve it we are through. Note that before introducing collectible pointers not even a single byte was being reclaimed. Now at least we are able to get back more than half of memory. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBQT---HBXBP---Releaseing-the-Objects-and-Memory-tp26144968p26144968.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12803] trunk/harbour
On Sat, Oct 31, 2009 at 6:36 PM, wrote: > Please note that the build may be broken, so bear with me for a > couple of days. Lorenzo, you can continue with experiments. Unfortunately, I get the same errors. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT - HBXBP - Releaseing the Objects and Memory
dempxbp also ended with a Runtime Error in MSVCRT here. (used mingw 4.4.1 for these tests) Brgds, Viktor On 2009 Oct 31, at 21:43, Viktor Szakáts wrote: Hi Pritpal, Huge effort and very nice job. I'm worried about one remaining thing: the monolithic nature of hbqt_slots.cpp. I'm not sure of the meaning of it, but it seems to contain references to various QT objects (f.e. even QTWebKit) in one central location. These object are now implemented in separate libs, and I wonder if referencing them like this wouldn't cause pulling of unnecessary parts in final apps? After testing demoxbp, the Web tab doesn't load all images, plus it flickers when moving around with the mouse, sometimes the whole page reappears only when going above the title bar f.e. Same effect can be seen in Lists tab with the scrollbars. Brgds, Viktor On 2009 Oct 31, at 19:48, Pritpal Bedi wrote: Hello Everybody Here are the results of debug output of demoxbp.exe. http://old.nabble.com/file/p26144968/2.zip 2.zip And this is the consolidated result of log file above: OBJECTCreated Released == QApplication 1 => 1 QWidget 9 => 9 QVariant 1 => 1 QEventLoop1 => 1 QSize-- => 2 QDesktopWidget1 => 1 QColor 33 => 33 QMenuBar 1 => 1 QMenu 4 => 4 QAction 12 => 12 QKeySequence 2 => 2 QStatusBar1 => 1 QPixmap 3 => 9 QCursor 5 => 5 QToolBar 1 => 1 QTabWidget1 => 1 QFrame 16 => 16 QScrollBar4 => 4 QHeaderView 3 => 3 QGridLayout 1 => 1 QFontMetrics 12 => 12 QFont-- => 12 QTextEdit 2 => 2 QCheckBox 4 => 4 QRadioButton 4 => 4 QSpinBox 3 => 3 QTreeWidget 2 => 2 QTreeWidgetItem 99 => 100 ( 220-417 == 98 Items ) QTreeWidgetItem 99 => 100 ( 422-619 == 98 Items ) QListView 2 => 2 QStringList 2 => 2 QStringListModel 2 => 2 QLineEdit 3 => 3 QComboBox 1 => 1 QPushButton 15 => 15 QTextCursor -- => 7 QTextCharFormat -- => 9 QBrush2 => 4 QWebView 1 => 1 QUrl 1 => 1 QGroupBox 1 => 1 QLabel7 => 7 QImage1 => 1 QIcon-- => 1 QPoint1 => 1 QModelIndex -- => 6 hbqt_ptrTOgcpointer 46 => -- -- 37 QPixmap 6 QBrush 2 45 It is one-to-one means whatever objects appln is creating with new Q() or creating dynamically is being released properly. But still 1.3 MB of memory is never reclaimed with next invocation of "One More Dialog". Application reclaims 1.7 MB but cannot reclaim 1.3 MB. If we look at the zipped 2.log file, we can see that at system level no memory is released though Harbours internal items gets released. Only at the end of the Main() function system releases 1.7 MB. Any ideas what could be points to see through or debug more. It is verified that Qt level delete ( Q* ) ph ; is executed as intended and object is releases but system memory stays the same. This is the only issue left with Harbour-Qt. Once we resolve it we are through. Note that before introducing collectible pointers not even a single byte was being reclaimed. Now at least we are able to get back more than half of memory. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBQT---HBXBP---Releaseing-the-Objects-and-Memory-tp26144968p26144968.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error making _hbhbpdf.c
Hi! Microsoft Windows XP [versão 5.1.2600] Envar for harbour maker. HB_COMPILER=msvc HB_DIR_NSIS=%ProgramFiles%\NSIS\ HB_DIR_QT=C:\Qt\2009.04\qt HB_DIR_ZIP=C:\info-zip\ HB_INSTALL_PREFIX=C:\DEV\HARBOUR HB_PATH=C:\DEV\HARBOUR HB_PLATFORM=win HB_WITH_QT=C:\Qt\2009.04\qt\include c:\>cd\harbour\trunk\harbour C:\harbour\trunk\harbour>win-make.exe clean install ... cl.exe -nologo -I. -I../../../../../include -Gs -TC -Ot2b1 -EHs-c- -MT -IC:/h arbour/trunk/harbour/external/zlib -IC:/harbour/trunk/harbour/external/libpng -D UNICODE -Fo_hbhbpdf.obj -c ../../../_hbhbpdf.c process_begin: CreateProcess(NULL, cl.exe -nologo -I. -I../../../../../include - Gs -TC -Ot2b1 -EHs-c- -MT -IC:/harbour/trunk/harbour/external/zlib -IC:/harbour/ trunk/harbour/external/libpng -DUNICODE -Fo_hbhbpdf.obj -c ../../../_hbhbpdf.c, ...) failed. make (e=2): O sistema nÒo pode encontrar o arquivo especificado. win-make.exe[3]: *** [_hbhbpdf.obj] Error 2 win-make.exe[2]: *** [descend] Error 2 win-make.exe[1]: *** [libhpdf.inst] Error 2 win-make.exe: *** [external.inst] Error 2 Best regards, Itamar M. Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Documentation
Where I can found Documentation of howto use , sintaxis etc etc of Tform( ) TDbwindow( ) Tmenu( ) Thanks in advance Bruno ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error making _hbhbpdf.c
You're forcing MSVC compiler, but you don't have it in your PATH. I'd like to strongly suggest every Windows user to **FORGET** HB_COMPILER settings. Don't use it, not needed, unnecessary. It's just a way to mess up things. Rely on setting up your PATH right and leave the rest to AUTODETECTION. Brgds, Viktor Microsoft Windows XP [versão 5.1.2600] Envar for harbour maker. HB_COMPILER=msvc HB_DIR_NSIS=%ProgramFiles%\NSIS\ HB_DIR_QT=C:\Qt\2009.04\qt HB_DIR_ZIP=C:\info-zip\ HB_INSTALL_PREFIX=C:\DEV\HARBOUR HB_PATH=C:\DEV\HARBOUR HB_PLATFORM=win HB_WITH_QT=C:\Qt\2009.04\qt\include c:\>cd\harbour\trunk\harbour C:\harbour\trunk\harbour>win-make.exe clean install ... cl.exe -nologo -I. -I../../../../../include -Gs -TC -Ot2b1 -EHs-c- - MT -IC:/h arbour/trunk/harbour/external/zlib -IC:/harbour/trunk/harbour/ external/libpng -D UNICODE -Fo_hbhbpdf.obj -c ../../../_hbhbpdf.c process_begin: CreateProcess(NULL, cl.exe -nologo -I. - I../../../../../include - Gs -TC -Ot2b1 -EHs-c- -MT -IC:/harbour/trunk/harbour/external/zlib - IC:/harbour/ trunk/harbour/external/libpng -DUNICODE -Fo_hbhbpdf.obj -c ../../../ _hbhbpdf.c, ...) failed. make (e=2): O sistema nÒo pode encontrar o arquivo especificado. win-make.exe[3]: *** [_hbhbpdf.obj] Error 2 win-make.exe[2]: *** [descend] Error 2 win-make.exe[1]: *** [libhpdf.inst] Error 2 win-make.exe: *** [external.inst] Error 2 Best regards, Itamar M. Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Error making _hbhbpdf.c
Viktor Szakáts escreveu: Rely on setting up your PATH right and leave the rest to AUTODETECTION. Brgds, Viktor Ok but if I run only C:\harbour\trunk\harbour>win-make clean ... C:\harbour\trunk\harbour>win-make Run without errors. Best regards, Itamar M. Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Error making _hbhbpdf.c
Viktor Szakáts escreveu: You're forcing MSVC compiler, but you don't have it in your PATH. This is not true, see. My path is: C:\harbour\trunk\harbour>set path Path=C:\Arquivos de programas\Microsoft Visual Studio 9.0\Common7\IDE;C:\Arquivo s de programas\Microsoft Visual Studio 9.0\VC\BIN;C:\Arquivos de programas\Microsoft Visual Studio 9.0\Common7\Tools;C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\ WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Arquivos de programas\Microsoft Visual Studio 9.0\VC\VCPackages;C:\Arquivos de programas\Microsoft SDKs\Windows\v6 .0A\bin;C:\Arquivos de programas\Microsoft Visual Studio 9.0\Common7\IDE;C:\Arquivos de programas\Microsoft Visual Studio 9.0\VC\BIN;C:\Arquivos de programas\Mi crosoft Visual Studio 9.0\Common7\Tools;C:\WINDOWS\Microsoft.NET\Framework\v3.5; C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Arquivos de programas\Microsoft Visual Studio 9.0\VC\VCPackages;C:\Arquivos de programas\Microsoft SDKs\Windows \v6.0A\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\Arquivos de programas\Microsoft SQL Server\100\Tools\Binn\;c:\Arquivos de programas\Microsoft SQL Server\100\DTS\Binn\;C:\Arquivos de programas\TortoiseSVN\bin;C:\DEV\HARBOUR\bin;C:\Arquivos de programas\QuickTime\QTSystem\;C:\Arquivos de programas\C VSNT\ PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH C:\harbour\trunk\harbour> Best regards, Itamar M. Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Error making _hbhbpdf.c
Viktor Szakáts escreveu: I'd like to strongly suggest every Windows user to **FORGET** HB_COMPILER settings. Don't use it, not needed, unnecessary. It's just a way to mess up things. Rely on setting up your PATH right and leave the rest to AUTODETECTION. without HB_COMPILER :-( C:\harbour\trunk\harbour>win-make.exe clean install ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org ! MAKE: win-make.exe 3.81 sh.exe clean install ! HB_INSTALL_PREFIX: C:\DEV\HARBOUR ! HB_HOST_PLAT: win (x86) HB_SHELL: nt config/global.mk:917: *** ! HB_COMPILER not set, could not autodetect. Stop. C:\harbour\trunk\harbour> Best regards, Itamar M. Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
