Re: [Harbour] Re: Compile error on r14429
Hi, Two things... 1) Is this not already after the path? Because I stuck it at the end. %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\strawberry\perl\bin;c:\windows\batfiles;c:\mingw\bin;C:\Program Files (x86)\QT Lite\QTSystem;C:\utils\console2;C:\utils\win-bash;C:\utils;C:\lame;C:\gnuwin32\bin After the _C compiler_ tools. There is no C compiler tools in your PATH besides cygwin, so cygwin is detected and tried to be used. 2) I don't really believe it is cygwin, or does it rely on any cygwin DLLs. It's sourceforge page boasts: GnuWin provides Win32-versions of GNU tools, or tools with a similar open source licence. The ports are native ports, that is they rely only on libraries provided with any 32-bits MS-Windows operating system, such as MS-Windows 95 / 98 / 2000 / NT / XP / Nor does it have *cygwin*.* files anywhere in there cygstart.exe is used for cygwin detection. There is no problem in having cygwin tools in PATH, for some targets it's even a requirement (mingwarm). Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - -xhb issues switch -n by default which breaks process
Hello Viktor To be on the quicker side, and if it can be acieved easily, can you provide functionality to call Harbour.exe for each souce separately controllable through some switch, i.e., -componebyone=yes. No sorry, I'd like to find the real solution. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbMK2 - Switch -env: RTE
Hi Pritpal, hbmk2 E:\dev_hbmk\xharbour\cacherdd.hbp -hblib -xhb -q -trace -info -lang=en -width=512 -rebuild -env:__MT__- ... ... Unrecoverable error 9023: hb_xgrab requested to allocate zero bytes Called from HB_SETENV(0) Called from HBMK2(945) in ../../../hbmk2.prg Called from MAIN(473) in ../../../hbmk2.prg This looks like a bug in low level hb_setenv() function. I was trying to supress define, if any, __MT__ and tried as documented: -env:__MT__- -env is not meant to suppress defines, but envvars. To suppress a define, use '-under:__MT__' Harbour option. To forcefully request ST mode in hbmk2, use '-st'. I had to initiate it like this because in one of the C source, these are the lines: #ifdef __MT__ #include hbthread.h static PHB_ITEM s_pMtx = NULL; #endif For Harbour builds, it is OK as I define __MT__ but for xHarbour compiles __MT__ is never defined but still I reach to line; #include hbthread.h and there is no define as such in above C source or elsewhere nor it is visible in the logs. It is a mystery how __MT__ peeps in. __MT__ is not a Harbour internal constant, so it must be defined somewhere in your sources, or maybe in xhb headers. For sure it's not defined (or used) by hbmk2. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - Switch -env: RTE
hbgetenv.c
HB_BOOL hb_setenv( const char * szName, const char * szValue )
{
#if defined( HB_OS_WIN )
{
LPTSTR lpName = HB_TCHAR_CONVTO( szName );
LPTSTR lpValue = HB_TCHAR_CONVTO( szValue );
HB_BOOL bResult = ( SetEnvironmentVariable( lpName, lpValue ) != 0 );
...
hbmk2.prg
CASE _VAR_MODE_DELETE ; hb_SetEnv( tmp[ 2 ] ) ; EXIT
See, const char * szValue , is never sent and is NULL in C.
Also I do not see how a variable gets removed from list in this code.
I will be wrong if an empty value nullifies it.
A NULL should delete it, but the TCHAR macros are
choking on NULL values.
Viktor
___
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:[14436] trunk/harbour
Revision: 14436 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14436view=rev Author: vszakats Date: 2010-05-06 06:33:13 + (Thu, 06 May 2010) Log Message: --- 2010-05-06 08:32 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * src/common/hbgete.c ! Fixed hb_setenv() to not crash on NULL szName parameter. ! Fixed hb_setenv() to handle NULL szValue parameter on win platforms. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/common/hbgete.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] Re: Compile error on r14429
Sorry Viktor, I still don't understand. AFAIK, I don't have ANY cygwin stuff on my computer. I don't see a single cygwin thing in my path, and I don't think TDM mingw is considered a cygwin program under windows. Having installed cygwin a few years ago on a different computer (and hating everything about cygwin after the experience), I vowed never to use Cygwin again. So when you say that there is no C compiler tools in my path besides Cygwin, I am not sure what you mean. And if what I said is true, then I am still confused as to how it would detect stuff in my PATH that it considers Cygwin. On Wed, May 5, 2010 at 11:17 PM, Viktor Szakáts harbour...@syenar.huwrote: There is no C compiler tools in your PATH besides cygwin, so cygwin is detected and tried to be used. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Compile error on r14429
Hi, Can you post the dir listing of your C:\gnuwin32\bin and C:\mingw\bin directories? Viktor On 2010 May 6, at 08:36, smu johnson wrote: Sorry Viktor, I still don't understand. AFAIK, I don't have ANY cygwin stuff on my computer. I don't see a single cygwin thing in my path, and I don't think TDM mingw is considered a cygwin program under windows. Having installed cygwin a few years ago on a different computer (and hating everything about cygwin after the experience), I vowed never to use Cygwin again. So when you say that there is no C compiler tools in my path besides Cygwin, I am not sure what you mean. And if what I said is true, then I am still confused as to how it would detect stuff in my PATH that it considers Cygwin. On Wed, May 5, 2010 at 11:17 PM, Viktor Szakáts harbour...@syenar.hu wrote: There is no C compiler tools in your PATH besides cygwin, so cygwin is detected and tried to be used. ___ 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: Compile error on r14429
I can give you a more exact output list when I go to work tomorrow in about 8 hours, but I am 99% sure they are as follows: 1) gnuwin32\bin directory contents - http://members.shaw.ca/smujohnson/txt/gnuwin32-files.txt 2) c:\mingw\bin - untouched install of TDM's mingw 4.4.1-2 install from their website .exe installer. Thanks for taking an interest in this! On Wed, May 5, 2010 at 11:41 PM, Viktor Szakáts harbour...@syenar.huwrote: Hi, Can you post the dir listing of your C:\gnuwin32\bin and C:\mingw\bin directories? Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Compile error on r14429
I can give you a more exact output list when I go to work tomorrow in about 8 hours, but I am 99% sure they are as follows: 1) gnuwin32\bin directory contents - http://members.shaw.ca/smujohnson/txt/gnuwin32-files.txt There is a cygstart.exe present in this directory. Delete it or rename it. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: PrinterFileText new function
Ranier, My name is Ranier. Sorry ! I think that PrinterFileText is not right place to convert codes. The driver printer can not be PDFCreator, can be any other... It's true ! Regards ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Compile error on r14429
Son of a... Ok. Thanks for your time. On Thu, May 6, 2010 at 12:10 AM, Viktor Szakáts harbour...@syenar.huwrote: I can give you a more exact output list when I go to work tomorrow in about 8 hours, but I am 99% sure they are as follows: 1) gnuwin32\bin directory contents - http://members.shaw.ca/smujohnson/txt/gnuwin32-files.txt There is a cygstart.exe present in this directory. Delete it or rename it. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- smu johnson smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Compile error on r14429
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\strawberry\perl\bin;c:\windows\batfiles;c:\mingw\bin;C:\Program Files (x86)\QT Lite\QTSystem;C:\utils\console2;C:\utils\win-bash;C:\utils;C:\lame;C:\gnuwin32\bin After the _C compiler_ tools. There is no C compiler tools in your PATH besides cygwin, so cygwin is detected and tried to be used. 2) I don't really believe it is cygwin, or does it rely on any cygwin DLLs. It's sourceforge page boasts: GnuWin provides Win32-versions of GNU tools, or tools with a similar open source licence. The ports are native ports, that is they rely only on libraries provided with any 32-bits MS-Windows operating system, such as MS-Windows 95 / 98 / 2000 / NT / XP / Nor does it have *cygwin*.* files anywhere in there cygstart.exe is used for cygwin detection. There is no problem in having cygwin tools in PATH, for some targets it's even a requirement (mingwarm). I have to correct this e-mail of mine. Cygwin _may_ cause harm when included with some other compiler tools, so if someone wants to keep Cygwin in PATH all the time, it's recommended to delete or rename cygstart.exe in cygwin bin dir, if it's not a goal to create cygwin Harbour builds, or compiler autodetection should be manually overridden using HB_COMPILER envvar (this is one the rare occasions). Even though for 99.99% of users, it's better to delete/rename cygstart.exe. Viktor ___ 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:[14339] trunk/harbour
Pritpal: 2010-04-16 07:49 UTC-0800 Pritpal Bedi (pritpal at vouchcac.com) [...] * contrib/hbxbp/hbpprocess.prg * contrib/hbxbp/xbpgeneric.prg * contrib/hbxbp/xbprtf.prg * contrib/hbxbp/xbpstatic.prg [...] David, the QPixmap bug in hbXBP on OS2 was a bug in hbXBP and is fixed. You can test it again to verify if I am correct. Testing it GPF: - Exception c005 at address 0x1dd569ca Exception Code:C005 Exception Address:1DD569CA EAX:0001 EBX:02A9BFB4 ECX:02A9BFBC EDX:0001 ESI: EDI:02A9BF7C EBP:003AF728 CS:EIP:005B:1DD569CA SS:ESP:0053:003AF710 DS:0053 ES:0053 FS:150B GS: Flags:00010246 Called from QPIXMAP:SCALED(0) in ../../../TQPixmap.prg Called from XBPSTATUSBAR:SETPOINTER(0) in ../../../xbpwindow.prg Called from BUILD_STATUSBAR(508) in demoxbp.prg Called from BUILDADIALOG(158) in demoxbp.prg Called from _BUILDADIALOG(107) in demoxbp.prg Called from MAIN(98) in demoxbp.prg Killed by SIGSEGV pid=0x1257 ppid=0x0054 tid=0x0001 slot=0x00c6 pri=0x0200 mc=0x0001 E:\HARBOUR105\HARBOUR\CONTRIB\HBXBP\TESTS\DEMOXBP.EXE LIBC063 0:000669ca cs:eip=005b:1dd569ca ss:esp=0053:003af710 ebp=003af728 ds=0053 es=0053 fs=150b gs= efl=00010246 eax=0001 ebx=02a9bfb4 ecx=02a9bfbc edx=0001 edi=02a9bf7c esi= Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. - hbqt* and qt4 libraries are current (Harbour 14433) and -trace show valid values: gcc.exe E:\var\temp\demoxbp.o E:\var\temp\hbmk_gl33bc.o E:\var\temp\hbmk_86krlp.o -Zomf -lhbxbp -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork -lQtCore4 -lQtGui4 -lQtNet4 -lQtUiTools -lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtos2 -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbrtl -lhbvm -lhbmacro -lhbcplr -lhbpp -lhbcommon -lsocket -lhbpcre -lhbzlib -o demoxbp.exe -LE:\HARBOUR105\HARBOUR\lib\os2\gccomf -LE:\qt4\lib David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2: Harbour 14433 - hbqt
Does not appear on list, re-trying ... Pritpal: hbqt* libraries build fine demoqt build / run fine but with GPF closing dialogs/windows Creating hbide project result in error: Compiling 'idesaveload.prg'... idesaveload.prg(267) Warning W0033 Variable 'CPATH' is never assigned in function 'HBIDE_GETINIPATH(245)' 500 No code generated. Checking idesaveload.prg I see FUNCTION hbide_getIniPath leave cPath un-initialized for all OS except Windows and Unix, and that is bad Adding for tests (it does not solve for rest of OS): -- #elif defined( __PLATFORM__OS2 ) cPath := hbide_DirAddPathSep( GetEnv( HOME ) ) + .hbide/ #endif -- then hbide project build fine GetEnv( HOME ) work in eCS but I do not know if apply for OS/2 Maurilio, any suggestion ? Running hbide.exe it create e:\home\default\.hbide directory but remain empty, and GPF: - Exception c005 at address 0x1dd569ca Exception Code:C005 Exception Address:1DD569CA EAX:0001 EBX:02F36914 ECX:02F3691C EDX:0001 ESI: EDI: EBP:0061FBB8 CS:EIP:005B:1DD569CA SS:ESP:0053:0061FBA0 DS:0053 ES:0053 FS:150B GS: Flags:00010246 Called from QACTION:SETMENU(0) in ../../../TQAction.prg Called from IDETOOLSMANAGER:CREATE(135) in idetools.prg Called from HBIDE:CREATE(409) in hbide.prg Called from MAIN(102) in hbide.prg Killed by SIGSEGV pid=0x11e7 ppid=0x0054 tid=0x0001 slot=0x00c9 pri=0x0200 mc=0x0001 E:\HARBOUR105\HARBOUR\CONTRIB\HBIDE\HBIDE.EXE LIBC063 0:000669ca cs:eip=005b:1dd569ca ss:esp=0053:0061fba0 ebp=0061fbb8 ds=0053 es=0053 fs=150b gs= efl=00010246 eax=0001 ebx=02f36914 ecx=02f3691c edx=0001 edi= esi= Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it. - David Macias ___ 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:[14437] trunk/harbour
Revision: 14437 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14437view=rev Author: vszakats Date: 2010-05-06 13:32:14 + (Thu, 06 May 2010) Log Message: --- 2010-05-06 15:29 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg + Refining cygwin autodetection by additionally looking for gcc.exe next to cygstart.exe. + -o option will now accept macros, filters and will inherit parent path even in -gh and other Harbour-only modes. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[14438] trunk/harbour
Revision: 14438 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14438view=rev Author: druzus Date: 2010-05-06 14:08:53 + (Thu, 06 May 2010) Log Message: --- 2010-05-06 16:08 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/hbsocket.c ! enabled domain and protocol constant values translation in SunOS builds * harbour/src/rtl/hbznet.c ! fixed to return error on some wrong input data for which ZLIB permanently returns Z_STREAM_END - thanks to Aleksander Czajczynski for the information and self contain example. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rtl/hbsocket.c trunk/harbour/src/rtl/hbznet.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:[14439] trunk/harbour
Revision: 14439 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14439view=rev Author: vouchcac Date: 2010-05-06 14:15:25 + (Thu, 06 May 2010) Log Message: --- 2010-05-06 07:13 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/idesaveload.prg ! Fixed hbide_getIniPath() to initialize cPath for OS2. Reported by David. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/idesaveload.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
[Harbour] Re: OS/2: Harbour 14433 - hbqt
David Arturo Macias Corona wrote: Adding for tests (it does not solve for rest of OS): -- #elif defined( __PLATFORM__OS2 ) cPath := hbide_DirAddPathSep( GetEnv( HOME ) ) + .hbide/ #endif -- Fixed. then hbide project build fine GetEnv( HOME ) work in eCS but I do not know if apply for OS/2 Maurilio, any suggestion ? Running hbide.exe it create e:\home\default\.hbide directory but remain empty, and GPF: It will only be written in if hbIDE exist properly. In the case of GPF it will remain blank. - Exception c005 at address 0x1dd569ca Exception Code:C005 Exception Address:1DD569CA EAX:0001 EBX:02F36914 ECX:02F3691C EDX:0001 ESI: EDI: EBP:0061FBB8 CS:EIP:005B:1DD569CA SS:ESP:0053:0061FBA0 DS:0053 ES:0053 FS:150B GS: Flags:00010246 Called from QACTION:SETMENU(0) in ../../../TQAction.prg Called from IDETOOLSMANAGER:CREATE(135) in idetools.prg Called from HBIDE:CREATE(409) in hbide.prg Called from MAIN(102) in hbide.prg :-((( - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/OS-2-Harbour-14433-hbqt-tp5013683p5014411.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] SF.net SVN: harbour-project:[14440] trunk/harbour
Revision: 14440 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14440view=rev Author: vouchcac Date: 2010-05-06 17:07:46 + (Thu, 06 May 2010) Log Message: --- 2010-05-06 09:52 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/THbQtUI.prg + Added functionality for WhatsThis feature of Qt. - contrib/hbide/resources/projectproperties.ui - contrib/hbide/resources/projectproperties.uic - Deleted: no longer required dialog. * contrib/hbide/resources/projectpropertiesex.ui * contrib/hbide/resources/projectpropertiesex.uic * contrib/hbide/resources/shortcuts.ui * contrib/hbide/resources/shortcuts.uic % Shifted: tooltips to WhatsThis slot. Shift+F1 key is the universal key to activate it. Alternatively ? icon appears on the left of X button in titlebat; press it and move over the dialog; where WhatsThis will be defined, cursor will change its shape and click there, tooltip like popup will open. * contrib/hbqt/doc/en/class_hbqplaintextedit.txt * contrib/hbqt/hbqt_hbqplaintextedit.cpp * contrib/hbqt/hbqt_hbqplaintextedit.h * contrib/hbqt/qtgui/HBQPlainTextEdit.cpp * contrib/hbqt/qtgui/THBQPlainTextEdit.prg * contrib/hbqt/qth/HBQPlainTextEdit.qth * contrib/hbide/hbide.hbp + contrib/hbide/ideedit.prg + Added: new source file which contains code to handle editing window at the micro level. It was going unmanageable in single file due to heavy changed needed for future. * contrib/hbide/ideeditor.prg - IdeEdit() class moved to ideedit.prg. + Implemented: base protocol to keep all the three variants of selections, viz., stream, column and line, persistant. It is a work in progress and may be some features of cut may not be working as expected yet. Please play with it a little and tell me about the artifacts it must respect to. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.hbp trunk/harbour/contrib/hbide/ideeditor.prg trunk/harbour/contrib/hbide/resources/projectpropertiesex.ui trunk/harbour/contrib/hbide/resources/projectpropertiesex.uic trunk/harbour/contrib/hbide/resources/shortcuts.ui trunk/harbour/contrib/hbide/resources/shortcuts.uic trunk/harbour/contrib/hbqt/THbQtUI.prg trunk/harbour/contrib/hbqt/doc/en/class_hbqplaintextedit.txt trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.h trunk/harbour/contrib/hbqt/qtgui/HBQPlainTextEdit.cpp trunk/harbour/contrib/hbqt/qtgui/THBQPlainTextEdit.prg trunk/harbour/contrib/hbqt/qth/HBQPlainTextEdit.qth Added Paths: --- trunk/harbour/contrib/hbide/ideedit.prg Removed Paths: - trunk/harbour/contrib/hbide/resources/projectproperties.ui trunk/harbour/contrib/hbide/resources/projectproperties.uic 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] hbmk2 doc
I have to port some apps from C53+Fivewin16 to Harbour+Bcc+Fivewin32. I'm trying to use hbmk2 to replace the old makefiles but I can't find the proper solutions. Where can I find some doc about hbmk2? What I need are two simple things: - create a lib from *.prg and *.c that are in a dir - create an exe from *.prg and libs created in the step above best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 doc
How compile several. PRG lib? *hbmk2* test1 test2 testn -lmylib1 -lmylib2 -lmylibn *hbmk2* test1 test2 testn -lmylib1 -lmylib2 -lmylibn -w3 -gc3 -otes http://harbourlanguage.blogspot.com/search/label/hbmk2 Send me any correction 2010/5/6 Lorenzo Fiorini lorenzo.fior...@gmail.com I have to port some apps from C53+Fivewin16 to Harbour+Bcc+Fivewin32. I'm trying to use hbmk2 to replace the old makefiles but I can't find the proper solutions. Where can I find some doc about hbmk2? What I need are two simple things: - create a lib from *.prg and *.c that are in a dir - create an exe from *.prg and libs created in the step above -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 doc
I think this is a question for users lists. hbmk2 Enter you can see the usage of hbmk2 create an .hbp file that contains. -hblib creates static library -o output file name. and following list all the files that take part of the library Then create another hpb that contains -L the path where you put the above library -l the name of the library follow the list of prgs that you wish to include in your exe but do not take part of the library If you download the sources of harbour you can see the examples how to build with hbmk2. I do not know if this is the best way to do it, but it works for me. Best regards Maurizio El 06/05/2010 02:37 p.m., Lorenzo Fiorini escribió: I have to port some apps from C53+Fivewin16 to Harbour+Bcc+Fivewin32. I'm trying to use hbmk2 to replace the old makefiles but I can't find the proper solutions. Where can I find some doc about hbmk2? What I need are two simple things: - create a lib from *.prg and *.c that are in a dir - create an exe from *.prg and libs created in the step above best regards, Lorenzo ___ 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:[14434] trunk/harbour
Hello, + Implemented: line selection mode. Designated key is F11. It is still a work in progress but a working prototype is there and currently selection is available and paste behaves the standard way. Mindagaus, please explore as the artifacts are OK. My name is Mindaugas. The most strange behaviour is that block forget about its mode. I mean, line blocks usually are pasted as line blocks, stream blocks as stream block, and column blocks as column. In current code paste depends on toolbar button, but not on the block creation mode. This should be very easy to implement for copy block and move block operations. Since you do not need to copy block to clipboard at all. I do not know how this is solved in MultiEdit in case of clipboard copy-paste. Maybe ME saves block mode to some variable and uses SetClipboardData(, NULL), WM_RENDERFORMAL way to determine, if pasted block is copied to clipboard by itself. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 doc
I have to port some apps from C53+Fivewin16 to Harbour+Bcc+Fivewin32. I'm trying to use hbmk2 to replace the old makefiles but I can't find the proper solutions. Where can I find some doc about hbmk2? 1. hbmk2 --help 2. Plenty of live examples in Harbour SVN. (dir /s *.hb*) 3. Massimo's site f.e. For basic stuff it's compatible with hbmk script. What I need are two simple things: - create a lib from *.prg and *.c that are in a dir hbmk2 -hblib *.prg *.c -omylib - create an exe from *.prg and libs created in the step above hbmk2 *.prg -lmylib By and large. Viktor ___ 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:[14434] trunk/harbour
Mindaugas Kavaliauskas wrote: My name is Mindaugas. Really sorry, slips of fingers, running faster than brain. The most strange behaviour is that block forget about its mode. I mean, line blocks usually are pasted as line blocks, stream blocks as stream block, and column blocks as column. In current code paste depends on toolbar button, but not on the block creation mode. This should be very easy to implement for copy block and move block operations. Since you do not need to copy block to clipboard at all. I do not know how this is solved in MultiEdit in case of clipboard copy-paste. Maybe ME saves block mode to some variable and uses SetClipboardData(, NULL), WM_RENDERFORMAL way to determine, if pasted block is copied to clipboard by itself. It will be as it must be. So far I was concentrating on block preservation. Today I will work on cut/paste operations. I need your valuable input exactly how must these behave in different circumstances. You also update me if the selection behavior is upto expectations or not. Also please check for all three variants I committed r14440. Also explain a little why these copy operation must not be posted to clipboad. I am in a position to keep copy information to me only but before I proceed I should know the relevant facts. Thanks for the inputs. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14434-trunk-harbour-tp5009924p5015880.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: hbMK2 - Switch -env: RTE
Viktor Szakáts wrote: I was trying to supress define, if any, __MT__ and tried as documented: -env:__MT__- -env is not meant to suppress defines, but envvars. To suppress a define, use '-under:__MT__' Harbour option. Probably it is '-undef:__MT__'. I tried it but it does not solves the problem. It is true for .prg sources, what is the syntax for similar functionality in C sources? To forcefully request ST mode in hbmk2, use '-st'. The situation does not belong to application, but only a C source. #ifdef __MT__ #include hbthread.h static PHB_ITEM s_pMtx = NULL; #endif For Harbour builds, it is OK as I define __MT__ but for xHarbour compiles __MT__ is never defined but still I reach to line; #include hbthread.h and there is no define as such in above C source or elsewhere nor it is visible in the logs. It is a mystery how __MT__ peeps in. __MT__ is not a Harbour internal constant, so it must be defined somewhere in your sources, or maybe in xhb headers. For sure it's not defined (or used) by hbmk2. I have checked it thoughly if I supply this define anyway, but could not find any occurance. This library comprises 4 prg files and 1 c file, as above. Still at a loss why __MT__ is issued for C sources. Anyway, changing __MT__ to __HB_MT__ solved this issue, but just in case someone comes with a clue will be better. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/hbMK2-Switch-env-RTE-tp5012018p5016055.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: hbMK2 - -xhb issues switch -n by default which breaks process
Viktor Szakáts wrote: To be on the quicker side, and if it can be acieved easily, can you provide functionality to call Harbour.exe for each souce separately controllable through some switch, i.e., -componebyone=yes. No sorry, I'd like to find the real solution. Any clues? Also consider that hbIDE will be using -xhb mode also. So solution should address this situation also. I mean it will be difficult to make changes in compiler code in older xHarbour, IMO. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/hbMK2-xhb-issues-switch-n-by-default-which-breaks-process-tp5005754p5016064.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] SF.net SVN: harbour-project:[14441] trunk/harbour
Revision: 14441 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14441view=rev Author: druzus Date: 2010-05-06 19:34:02 + (Thu, 06 May 2010) Log Message: --- 2010-05-06 21:33 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/Makefile * harbour/src/rtl/hbznet.c + harbour/src/rtl/hbinetz.c * moved HB_INETCOMPRESS() function to separate file * harbour/include/hbexprb.c ! fixed my very bad CP typo (2010-02-04 19:14 UTC+0100) which caused that dummy value was left on HVM stack after post decrementation used as statement. This dummy value could break construciton like FOR EACH, WITH OBJECT, BEGIN SEQUENCE. Here is self contain example which can be used to exploit the problem: proc main() begin sequence p() end sequence return proc p() local nTemp := 0 begin sequence nTemp-- end sequence return Many thanks to Heinz Bergen who reduced his code to similar small example. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbexprb.c trunk/harbour/src/rtl/Makefile trunk/harbour/src/rtl/hbznet.c Added Paths: --- trunk/harbour/src/rtl/hbinetz.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] Re: Compile error on r14429
I think I am going to send an e-mail to the GnuWin32 project leaders, and ask them to remove that if possible, as they seem to boast that their package is cygwin-free. Thanks for all the help. After all these years for me, cygwin rears its ugly head again... On Thu, May 6, 2010 at 4:23 AM, Viktor Szakáts harbour...@syenar.hu wrote: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\strawberry\perl\bin;c:\windows\batfiles;c:\mingw\bin;C:\Program Files (x86)\QT Lite\QTSystem;C:\utils\console2;C:\utils\win-bash;C:\utils;C:\lame;C:\gnuwin32\bin After the _C compiler_ tools. There is no C compiler tools in your PATH besides cygwin, so cygwin is detected and tried to be used. 2) I don't really believe it is cygwin, or does it rely on any cygwin DLLs. It's sourceforge page boasts: GnuWin provides Win32-versions of GNU tools, or tools with a similar open source licence. The ports are native ports, that is they rely only on libraries provided with any 32-bits MS-Windows operating system, such as MS-Windows 95 / 98 / 2000 / NT / XP / Nor does it have *cygwin*.* files anywhere in there cygstart.exe is used for cygwin detection. There is no problem in having cygwin tools in PATH, for some targets it's even a requirement (mingwarm). I have to correct this e-mail of mine. Cygwin _may_ cause harm when included with some other compiler tools, so if someone wants to keep Cygwin in PATH all the time, it's recommended to delete or rename cygstart.exe in cygwin bin dir, if it's not a goal to create cygwin Harbour builds, or compiler autodetection should be manually overridden using HB_COMPILER envvar (this is one the rare occasions). Even though for 99.99% of users, it's better to delete/rename cygstart.exe. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- smu johnson smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - Switch -env: RTE
-env is not meant to suppress defines, but envvars. To suppress a define, use '-under:__MT__' Harbour option. Probably it is '-undef:__MT__'. Yes, typo. It's in Harbour help anyway. #ifdef __MT__ #include hbthread.h static PHB_ITEM s_pMtx = NULL; #endif For Harbour builds, it is OK as I define __MT__ but for xHarbour compiles __MT__ is never defined but still I reach to line; #include hbthread.h and there is no define as such in above C source or elsewhere nor it is visible in the logs. It is a mystery how __MT__ peeps in. __MT__ is not a Harbour internal constant, so it must be defined somewhere in your sources, or maybe in xhb headers. For sure it's not defined (or used) by hbmk2. I have checked it thoughly if I supply this define anyway, but could not find any occurance. This library comprises 4 prg files and 1 c file, as above. Still at a loss why __MT__ is issued for C sources. Anyway, changing __MT__ to __HB_MT__ solved this issue, but just in case someone comes with a clue will be better. Well, you're using it, so I'd assume you know what it does :) If it's not present in any C compiler and xhb headers, it's probably defined by the C compiler. You need to figure how to control it, or just don't use it. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Compile error on r14429
I think I am going to send an e-mail to the GnuWin32 project leaders, and ask them to remove that if possible, as they seem to boast that their package is cygwin-free. Good idea, though cygstart is a simple 'start' like tool, which may be the reason they included a cygwin.dll-free build. Thanks for all the help. After all these years for me, cygwin rears its ugly head again... BTW, I've fixed it for hbmk2. For Harbour build I didn't had the nerve (would take hours for me), but most probably could be done in case this problem would became widespread. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - -xhb issues switch -n by default which breaks process
To be on the quicker side, and if it can be acieved easily, can you provide functionality to call Harbour.exe for each souce separately controllable through some switch, i.e., -componebyone=yes. No sorry, I'd like to find the real solution. Any clues? To me it looks like a regular problem, not some kind of bug. Also consider that hbIDE will be using -xhb mode also. If you think hbmk2 is the suspicious piece one here, simply try the harbour cmdline (printed by -trace) directly. If it behaves differently, it's a HB_COMPILE() function problem, if not, look closer into Clipper/Harbour behavior to find out why it's behaving like it does. Another possibility is some Clipper incompatible behavior of xhb which masked some problems in your code thus far. So solution should address this situation also. I mean it will be difficult to make changes in compiler code in older xHarbour, IMO. I maintain it's not a hbmk2 problem. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Vdei creation of harbour-project
hi, On Wed, May 5, 2010 at 2:25 PM, Viktor Szakáts harbour...@syenar.hu wrote: Hi Smu, git svn clone -s https://harbour-project.svn.sourceforge.net/svnroot/harbour-projectharbour It worked, but looked like it was going to take hours or even days to do. It seemed to start right from revision 1 and work its way up slowly. If it has to do 14,000+ of those, it will take forever. So I won't bother. But I am not sure if that's SVN's fault, as I have cloned some git trees before for other software projects (albeit not as big) and it wasn't unexpectedly long. I believe git also uses zlib to compress a lot of source code through the wires when you pull/push/clone, in case you thought it might send the raw data uncompressed. (sorry I pulled this command from my bash history, and it's possible the exact URL needs tweaking) The URL seemed to work! ___ 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:[14434] trunk/harbour
Hello Mindaugas I have installed multi-edit and have looked into the blocks mechanism. The concept sepates it from regular cut/copy/paste operations. It has another menu to take actions on thus saved blocks. xMate implements block and other operations at same levels. I am thinking of which protocol is better. I think xMate way is too spontaneous. My viewpoint is like this : The selections be the way like xMate provides. Block operations like multi-edit. More opinions are welcome. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14434-trunk-harbour-tp5009924p5016311.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] Vdei creation of harbour-project
On Wed, May 5, 2010 at 2:25 PM, Viktor Szakáts harbour...@syenar.hu wrote: Hi Smu, git svn clone -s https://harbour-project.svn.sourceforge.net/svnroot/harbour-project harbour It worked, but looked like it was going to take hours or even days to do. It seemed to start right from revision 1 and work its way up slowly. If it has to do 14,000+ of those, it will take forever. So I won't bother. But I am not sure if that's SVN's fault, as I have cloned some git trees before for other software projects (albeit not as big) and it wasn't unexpectedly long. I believe git also uses zlib to compress a lot of source code through the wires when you pull/push/clone, in case you thought it might send the raw data uncompressed. It takes time, since Harbour SVN is large. What I did for the gource video [1] was to download the whole SVN database from sf.net with rsync, set it up in my SVN server VM (a copy actually) and git clone from this local SVN server. It was stable, and much faster. BTW, here is a better cmdline: git svn clone -s --no-follow-parent https://harbour-project.svn.sourceforge.net/svnroot/harbour-project harbour Otherwise it gets messed up @ ~r8200. [1] http://www.youtube.com/watch?v=4DrhrxPZhts Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbMK2 - -xhb issues switch -n by default which breaks process
Viktor Szakáts wrote: Any clues? To me it looks like a regular problem, not some kind of bug. If you think hbmk2 is the suspicious piece one here, simply try the harbour cmdline (printed by -trace) directly. No, it is not hbMK2 bug at all. It is Harbour compiler's bug which starts dumping warnings after a certain limit of confronted warnings are reached. It can be illustrated like this: (code - sephagatti - compilable with minimum warning level ) a.prg - 2 lines code; 11000 warnings - compiles fine b.prg - 15000 lines code; 7000 warnings - compiles fine c.prg - 27000 lines code; 13000 warnings - misbehave - warnings are dumped to console and at the end process aborted. Keep on shuffling the order of prgs or add few small ones inbetween the dump appears at other file. Przemek, can you please look into this issue? If it behaves differently, it's a HB_COMPILE() function problem, if not, look closer into Clipper/Harbour behavior to find out why it's behaving like it does. Another possibility is some Clipper incompatible behavior of xhb which masked some problems in your code thus far. If I issue the same command copied from hbIDE log direct on command line, I get the same warning dump and process aborts. I maintain it's not a hbmk2 problem. Me too. BTW, one thought, I can see hb_threadStart() in hbMK2, can I deactivate it any way to see if it improves or alters the results? I have seen something which might belong to this, but reveal later once I am sure it is the default. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/hbMK2-xhb-issues-switch-n-by-default-which-breaks-process-tp5005754p5016412.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: Re[Harbour] moval of non-UNICODE Windows codepath?
On Thu, Apr 29, 2010 at 6:07 AM, Viktor Szakáts harbour...@syenar.huwrote: Hi, Did you try to use unicows lib? If not, I'd suggest to try it, since it solves this problem in quite simple way. All you need to do is adding -lunicows to your hbmk2 make file and bundle unicows.dll with your app. Works with all supported Harbour compilers. Get prebuilt libunicows binaries from here: http://libunicows.sourceforge.net/ Viktor has mentioned it before, but I'd thought I'd tell you anyway... that with the libunicows files, use hbmk2 with the switch -Lpath to libunicows files along with the -lunicows to get everything to work. This will save you some some if you were not aware of this step. BTW There are the Windows applications in two builds - UNICODE and non-UNICODE. There are, but it's unnecessary in case of Harbour apps, and it's generally not a very good idea from several aspects to have different binaries for U and non-U. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] moval of non-UNICODE Windows codepath?
Przemek, if you are reading this thread, could you please comment if you have a moment? I am curious as to what you think about the questions Viktor posed a while back, as this change will affect me in a few tiny ways, and I'm curious about your thoughts. On Thu, Apr 29, 2010 at 5:55 AM, Grigory Filatov gfila...@front.ru wrote: Hello Viktor, Any opinions on this? (removal of non-unicode) ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
Whew! My problem has been resolved by fix in Revision 14441. Thanks all for the insight, code reducing experience and extra thanks to Przemysław Czerpak for the encouragement and final fix. Heinz Heinz V Bergen wrote: Viktor Szakáts wrote: Hi All, Lately I mentioned having random GPFs with my live apps since changing to Harbour r14336. I also mentioned they are gone. This turned out not to be true, they are still present. ... Viktor Hello all, not sure if this is related but I have been fighting with random GPFs also. -was gui gtwvt app, and app would just close with no error, sometimes processing 1 iteration of an Import/Export process, sometimes crash after second. -compiled as non gui without GTWVT, but still got crashes, but now got an error message: Unrecoverable error 9019: Stack underflow and always on the same Return() statement, sometimes on 1st iteration, usually on the second one, but sometimes (rarely) 3rd or more. -compiled with debugger, now get different error: Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:0041F2A3 EAX:ABB4 EBX:000D ECX: EDX:0004 ESI:00BC3874 EDI: EBP:0001 CS:EIP:001B:0041F2A3 SS:ESP:0023:0022F540 DS:0023 ES:0023 FS:003B GS: Flags:00010206 CS:EIP: 80 3B B4 0F 86 B4 00 00 00 C7 44 24 0C 00 00 00 SS:ESP: 00C331D8 03CF 000D 00C226B4 00CAD 7CC 0002 0001 0001 0052C81A 00CAD7CC 0002 00BC33DC 00C56A30 C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... I don't really understand what this means, my guess is some process appears to be damaging the stack. If this is not related to issue, any idea what I need to look at to resolve issue? Thanks, Heinz -- View this message in context: http://old.nabble.com/Harbour-%22random%22-GPFs-tp28375863p28479877.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] Re: hbMK2 - -xhb issues switch -n by default which breaks process
No, it is not hbMK2 bug at all. It is Harbour compiler's bug which starts dumping warnings after a certain limit of confronted warnings are reached. It can be illustrated like this: (code - sephagatti - compilable with minimum warning level ) a.prg - 2 lines code; 11000 warnings - compiles fine b.prg - 15000 lines code; 7000 warnings - compiles fine c.prg - 27000 lines code; 13000 warnings - misbehave - warnings are dumped to console and at the end process aborted. Keep on shuffling the order of prgs or add few small ones inbetween the dump appears at other file. Przemek, can you please look into this issue? Actual code example would greatly help I guess... Me too. BTW, one thought, I can see hb_threadStart() in hbMK2, can I deactivate it any way to see if it improves or alters the results? It's not activated by default. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbMK2 - -xhb issues switch -n by default which breaks process
Viktor Szakáts wrote: To be on the quicker side, and if it can be acieved easily, can you provide functionality to call Harbour.exe for each souce separately controllable through some switch, i.e., -componebyone=yes. No sorry, I'd like to find the real solution. Well I did some experiments and here I get the solution ( though temporary ) until the issue is resolved: hbmk2.prg [ #3972 ] #if 1 /* Original */ cCommand := FN_Escape( DirAddPathSep( PathSepToSelf( l_cHB_BIN_INSTALL ) ) + cBin_CompPRG + cBinExt, nCmd_Esc ) +; + iif( hbmk[ _HBMK_lCreateLib ] .OR. hbmk[ _HBMK_lCreateDyn ], -n1, iif( hbmk[ _HBMK_nHBMODE ] != _HBMODE_NATIVE, -n, -n2 ) ) +; + ArrayToList( l_aPRG_TODO,, nCmd_Esc ) +; iif( hbmk[ _HBMK_lBLDFLGP ], + hb_Version( HB_VERSION_FLAG_PRG ), ) +; iif( ! Empty( GetEnv( HB_USER_PRGFLAGS ) ), + GetEnv( HB_USER_PRGFLAGS ), ) +; iif( ! Empty( hbmk[ _HBMK_aOPTPRG ] ), + ArrayToList( hbmk[ _HBMK_aOPTPRG ] ), ) #else for each cPrg in l_aPRG_TODO cCommand := FN_Escape( DirAddPathSep( PathSepToSelf( l_cHB_BIN_INSTALL ) ) + cBin_CompPRG + cBinExt, nCmd_Esc ) +; + iif( hbmk[ _HBMK_lCreateLib ] .OR. hbmk[ _HBMK_lCreateDyn ], -n1, iif( hbmk[ _HBMK_nHBMODE ] != _HBMODE_NATIVE, -n, -n2 ) ) +; iif( hbmk[ _HBMK_lBLDFLGP ], + hb_Version( HB_VERSION_FLAG_PRG ), ) +; iif( ! Empty( GetEnv( HB_USER_PRGFLAGS ) ), + GetEnv( HB_USER_PRGFLAGS ), ) +; iif( ! Empty( hbmk[ _HBMK_aOPTPRG ] ), + ArrayToList( hbmk[ _HBMK_aOPTPRG ] ), ) +; + cPrg #endif cCommand := AllTrim( cCommand ) IF hbmk[ _HBMK_lTRACE ] IF ! hbmk[ _HBMK_lQuiet ] hbmk_OutStd( hbmk, I_( Harbour compiler command: ) ) ENDIF OutStd( cCommand + _OUT_EOL ) ENDIF IF ! hbmk[ _HBMK_lDONTEXEC ] .AND. ( tmp := hb_processRun( cCommand ) ) != 0 hbmk_OutErr( hbmk, hb_StrFormat( I_( Error: Running Harbour compiler. %1$s ), hb_ntos( tmp ) ) ) IF ! hbmk[ _HBMK_lQuiet ] OutErr( cCommand + _OUT_EOL ) ENDIF IF ! hbmk[ _HBMK_lIGNOREERROR ] IF hbmk[ _HBMK_lBEEP ] DoBeep( .F. ) ENDIF RETURN 6 ENDIF ENDIF #if 0 next #endif This also opens up some interesting possibilities. For example, xMate accepts compiler switches per indivisual file basis. This feature alone has helped our institution to be on the target quickly. Now I am pressing hbMK2 and hbIDE for the job, but here it seems a show-stopper unless I tweak hbMK2 to suit our purpose ( which from the core of my heart, I do not want ). Currently it is a show-stopper for this application to be hooked into hbIDE. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/hbMK2-xhb-issues-switch-n-by-default-which-breaks-process-tp5005754p5017031.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] Re: hbMK2 - -xhb issues switch -n by default which breaks process
Well I did some experiments and here I get the solution ( though temporary ) until the issue is resolved: hbmk2.prg [ #3972 ] #if 1 /* Original */ [snip] #if 0 next #endif So you went along and implemented what I intentionally didn't want to implement. If time is a factor for you and you cannot wait to find the proper solution, pls keep above patch local to your system. This also opens up some interesting possibilities. For example, xMate accepts compiler switches per indivisual file basis. This feature alone has helped our institution to be on the target quickly. I don't agree with such feature, as I already told. IMHO it's wrong direction and really only helps to confuse users and create overcomplicated projects. Also, this solution slows down compilation process greatly, effectively nilling one of my major goals for developing hbmk2. Moreover, if someone wants to do this (per source options), there are other, already working ways to solve it. (f.e. defines, and pragmas). This are make-system agnostic, part of the source code, thus much better. Now I am pressing hbMK2 and hbIDE for the job, but here it seems a show-stopper unless I tweak hbMK2 to suit our purpose ( which from the core of my heart, I do not want ). Currently it is a show-stopper for this application to be hooked into hbIDE. We still cannot see what is the problem. As a start I cannot see how can you get a warning at all when using -w0. Pls provide a reduced example. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbMK2 - -xhb issues switch -n by default which breaks process
Viktor Szakáts wrote: So you went along and implemented what I intentionally didn't want to implement. If time is a factor for you and you cannot wait to find the proper solution, pls keep above patch local to your system. Of course, local. I don't agree with such feature, as I already told. IMHO it's wrong direction and really only helps to confuse users and create overcomplicated projects. Also, this solution slows down compilation process greatly, effectively nilling one of my major goals for developing hbmk2. Moreover, if someone wants to do this (per source options), there are other, already working ways to solve it. (f.e. defines, and pragmas). This are make-system agnostic, part of the source code, thus much better. #pragma could be a solution and have tested and works ok. So this part is now fine with me. One test point to other anomaly when including #pragma directive in the source is that its value is retained for rest of the files too. For example, #prgma /N- is first source is effective for the next sources too. The workaround is : group sources as such that later prgs should include prgmas which can descend to next groups. This issue also has to be addressed. Now I am pressing hbMK2 and hbIDE for the job, but here it seems a show-stopper unless I tweak hbMK2 to suit our purpose ( which from the core of my heart, I do not want ). Currently it is a show-stopper for this application to be hooked into hbIDE. We still cannot see what is the problem. As a start I cannot see how can you get a warning at all when using -w0. Pls provide a reduced example. It cannot be reduced as a self-reduced as the warnings are issued with really large sources written in sephgetti styles. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/hbMK2-xhb-issues-switch-n-by-default-which-breaks-process-tp5005754p5017497.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] Supernova uses HbQt
Supernova (Simple scripting programming language) now uses HbQt http://supernova.sourceforge.net There are two versions of Supernova 1 - MS-Windows Edition developed using PWCT (Programming Without Coding Technology ) based on xHarbour + HarbourMiniGUI Extended 2 - Multi-platform (Ubuntu Linux + MS-Windows) Edition based on Harbour + HbQt HbQt is GREAT ( Multi-platform, Simple to learn, Easy to use and VERY RICH) Greetings, Mahmoud Fayed http://doublesvsoop.sourceforge.net (Programming Without Coding Technology) http://supernova.sourceforge.net (Simple scripting programming language) http://pythonpwct.sourceforge.net (Use PWCT and get Python code) http://www.sourceforge.net/projects/fglib ( Complete GUI project for CA-Clipper) ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Supernova uses HbQt
Hello Samir MAHMOUD SAMIR wrote: HbQt is GREAT ( Multi-platform, Simple to learn, Easy to use and VERY RICH) Can you share your journey through hbQT and the perspective and support behind above statement. Harbour community will gain a lot more confidence in using hbQT for production projects as, it is gathered from your works belonging to different programming languages, that you have a vast experience in other languages also. Group will be specifically interested how did you rate hbQT : HbQt is GREAT ( Multi-platform, Simple to learn, Easy to use and VERY RICH) - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Supernova-uses-HbQt-tp5017694p5017780.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
