[Harbour] Server maintenance
Hi All, Yesterday evening (UTC) the mailing list server abended, so right now Phil is doing backups and maintenance on it to get it back online as soon as possible. Pls be patient and take the offline time for some quality non-Harbour activity :) Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] testing 123
Testing Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] testing
testing ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about WinCE build
Hi,
The error message shows exactly what's missing, install it.
It's not Harbour problem.
Viktor
On 2010 May 31, at 13:57, Jaroslaw Kadziola wrote:
Hi Viktor,
When i'm trying to build WinCE harbour i get :
! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: win-make.exe 3.81 D:/cygwin/bin/sh.exe clean install
! HB_INSTALL_PREFIX: D:\harbour\
! HB_HOST_PLAT: win (x86) HB_SHELL: nt
! HB_PLATFORM: wce (arm)(autodetected)
! HB_COMPILER: mingwarm (autodetected: D:/cegcc/opt/mingw32ce/bin/)
! HB_BIN_COMPILE: D:\harbour\bin\win\mingw
! Component: 'zlib' found in D:/harbour/external/zlib (local)
! Component: 'pcre' found in D:/harbour/external/pcre (local)
! Component: 'openssl' not supported on wce platform
! Component: 'gpm' not supported on wce platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not found. Configure with HB_WITH_CURSES.
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on wce platform
! 'bz2' library skipped (unused)
! 'gtcrs' library skipped (component not found)
! 'gtdos' library skipped (platform not supported)
! 'gtos2' library skipped (platform not supported)
! 'gtsln' library skipped (component not found)
! 'gttrm' library skipped (platform or compiler not supported)
! 'gtwin' library skipped (platform not supported)
! 'gtxwc' library skipped (component not found)
! 'gtwvg' library skipped (platform not supported)
! 'hbbz2' library skipped ('bzip2' not supported on wce platform)
! 'gtalleg' library skipped ('allegro' not supported with mingwarm compiler)
! 'hbblat' library skipped (platform not supported)
! 'hbcairo' library skipped ('cairo' not found. Configure with HB_WITH_CAIRO.)
! 'hbcups' library skipped ('cups' not found. Configure with HB_WITH_CUPS.)
! 'hbcurl' library skipped ('libcurl' not found. Configure with HB_WITH_CURL.)
! 'hbfbird' library skipped ('firebird' not found. Configure with
HB_WITH_FIREBIRD.)
! 'hbfimage' library skipped ('freeimage' not found. Configure with
HB_WITH_FREEIMAGE.)
! 'hbgd' library skipped ('libgd' not found. Configure with HB_WITH_GD.)
! 'hbmysql' library skipped ('mysql' not found. Configure with HB_WITH_MYSQL.)
! 'hbpgsql' library skipped ('postgresql' not found. Configure with
HB_WITH_PGSQL.)
! 'hbqt' library skipped ('qt' not found. Configure with HB_WITH_QT.)
! 'hbssl' library skipped (component not found)
! 'rddads' library skipped ('ads' not found. Configure with HB_WITH_ADS.)
! 'sddfb' library skipped ('firebird' not found. Configure with
HB_WITH_FIREBIRD.)
! 'sddmy' library skipped ('mysql' not found. Configure with HB_WITH_MYSQL.)
! 'sddoci' library skipped ('ocilib' not supported on wce platform)
! 'sddpg' library skipped ('postgresql' not found. Configure with
HB_WITH_PGSQL.)
! Skip install, destination dir 'D:\harbour\\doc' is the same as source
! Skip install, destination dir 'D:\harbour\\doc/en' is the same as source
! Skip install, destination dir 'D:\harbour\\include' is the same as source
arm-mingw32ce-gcc -I. -I../../../../../include -W -O2 -fomit-frame-pointer
-DHB_LEGACY_TYPES_OFF -DUNICODE -DUNDER_CE -D_WIN32_WCE -osqlite3.o -c
../../../sqlite3.c
/cygdrive/d/cegcc/opt/mingw32ce/libexec/gcc/arm-mingw32ce/4.4.0/cc1.exe:
error while loading shared libraries: cygmpfr-1.dll: cannot open shared
object file: No such file or directory
win-make.exe[3]: *** [sqlite3.o] Error 1
win-make.exe[2]: *** [descend] Error 2
win-make.exe[1]: *** [sqlite3.inst] Error 2
win-make.exe: *** [external.inst] Error 2
-
my batch :
SET PATH=D:\cegcc\opt\mingw32ce\bin;D:\cygwin\bin;%PATH%
SET CYGWIN=nodosfilewarning
HB_BUILD_UNICODE=no
SET HB_BIN_COMPILE=D:\harbour\bin\win\mingw
SET HB_INSTALL_PREFIX=%~dp0
win-make.exe clean install %1 %2 log-mingwarm.txt 21
---
What's wrong ?
--
Regards,
Jaroslaw Kadziola
___
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: Qt - Distribution Licensing Clarification
Massimo Belgrano wrote: or possible 2.1 beta? This has what relation to my query ? I guess it's in relation to avoid a non-official distro for the sake of HBQT. Proper solution would be to detach HBQT/HBXBP/HBIDE release schedule from core and make them available as a normal extra component which plugs into Harbour core distribution. (which should be created separately) As for QT libs, I don't know, but to me packaging everything but the kitchen sink together just to save one official download and official installation of QT component look like a very bad idea, even if it's legal. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Qt - Distribution Licensing Clarification
Proper solution would be to detach HBQT/HBXBP/HBIDE release schedule from core and make them available as a normal extra component which plugs into Harbour core distribution. (which should be created separately) Ok. So how can one obtain the latest binaries including hbQT, hbXBP, hbIDE ? Nightly zips ? I also find it really cumbersome to package everything in one for sake of _out-of-the-box_ scenario. As for QT libs, I don't know, but to me packaging everything but the kitchen sink together just to save one official download and official installation of QT component look like a very bad idea, even if it's legal. It is bad I know, but what if they do not have any interest in Qt. 225 MB vs 12 MB is a huge difference. We only need 4 .a files for this purpose. Isn't there a runtime only download package somewhere on Nokia's QT website? Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Qt - Distribution Licensing Clarification
Viktor Szakáts wrote: Isn't there a runtime only download package somewhere on Nokia's QT website? Before exploring this possibility, a little doubt, is Qt runtime enough for materializing an .exe to be build with hbIDE ? Yes. We made the decision at the beginning that only HBQT lib depends on QT headers, so the only occasion you need QT headers is when building HBQT. If you ship HBQT as binary (f.e. in Harbour binary distro), there is no need for them. Same goes for HBXBP. There is only one thing to pay attention to: QT runtime .dlls should match the version of QT headers used for building HBQT libs. Probably a major+minor match is enough, so 4.5.x .dlls should have matching HBQT libs built with 4.5.x, and 4.6.x .dlls matching with 4.6.x HBQT libs. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Qt - Distribution Licensing Clarification
Before exploring this possibility, a little doubt, is Qt runtime enough for materializing an .exe to be build with hbIDE ? Yes. If this is the case then we do not need complete run-time of Qt. Only 4 dll's matching the version we compiled hbQT* is enough. Can we embed them in our nightly zips ? This way it will ensure that there is no mismatch. No. This would mean to include these 3rd party .dlls in our SVN. It's not the way to go for several reasons. F.e. the nightly is a source distribution, so 1) it's up to users to decide what QT version to use 2) it's a source distro which shouldn't contain .dlls 3) .dlls are huge 4) .dlls are 3rd party ones and it's not Harbour's job to keep them up to date. The simplest solution is if you pack these .dlls in a .zip and provide a link for them on your website, if HBQT users find it troubling to deal with Nokia's official website. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Documentation storm on user's list
Hi All, ..I'd prefer to we follow a Harbour-Fund financing model. That is, we start making donations to a common-treasure and let project leaders decide and make hiring agreements for manual creation, or whatever would help project's improvement. But, of course, let's hear other harbour followers opinions. xHarbour.com has excellent documentation and for last four or five years they have not been able to sell enough copy to receive back money they had to pay for professional documentation writer. And here we have ready product not sth what may appear in the future. If ready to use product cannot be sold in enough number of copies then for sure we have no chance to collect enough money for sth what does not exist yet. Instead starting such foundation may be the end of Harbour. It will not allow to collect enough money to pay professional documentation writer but it may be the source of never ending discussion when the documentation will have been finished addressed to me and some other core developers. I'm not slave of Harbour users and for sure I will not tolerate such messages for long time. This is my last massage in this thread. I strongly suggest to invest resources necessary to create such long messages about how to create harbour documentation in creating some real documentation. It will be really productive. Very well summed up. Small addition: _Asking others_ to create a fund (just like doing the same with docs) won't help the case either (I also don't have any notion to deal with any sort of common money, as discussed a few times in the past). Pls note that _anyone_ is free to create a fund and deal with the sponsoration of doc writing, or any other matter whatsoever. Harbour admins/core developers aren't needed for this. To make it clear: I'm personally not interested in writing docs even if paid for, and other core developers has stated this clearly too in the past. [ After waiting some days for the original thread on user's list taking any sort of constructive direction, I had made the decision to ban the thread starter, on the grounds that he went into an unstoppable monologue, which is off-topic regarding Harbour user's list, and really doesn't help to solve any problems. ] Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error trying to compile hbide (Rev.14648)
Hi, Yes. Pls read relevant section in INSTALL (look for 'HB_WITH_QT') or past message about this topic, it has been quite well discussed here. Viktor On 2010 May 31, at 20:04, jparada wrote: Hi, I have been able to compile demohbqt and demoxbp without any problem, but when trying to compile hbide (hbmk2 hbide.hbp), I get errors like this, please take a look. C:/QT/4.6.2/lib/libQtUiTools.a(abstractformbuilder.o):abstractformbuilder.cpp:(. text+0x1b0): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(abstractformbuilder.o):abstractformbuilder.cpp:(. text+0x273): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(abstractformbuilder.o):abstractformbuilder.cpp:(. text+0x2c7): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(abstractformbuilder.o):abstractformbuilder.cpp:(. text+0x31b): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(abstractformbuilder.o):abstractformbuilder.cpp:(. text+0x550): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(abstractformbuilder.o):abstractformbuilder.cpp:(. text+0x6e3): más referencias a `_Unwind_Resume' sin definir a continuación C:/QT/4.6.2/lib/libQtUiTools.a(abstractformbuilder.o):abstractformbuilder.cpp:(. eh_frame+0x12): referencia a `__gxx_personality_v0' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilder.o):formbuilder.cpp:(.text+0x6a): refe rencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilder.o):formbuilder.cpp:(.text+0x419): ref erencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilder.o):formbuilder.cpp:(.text+0x51e): ref erencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilder.o):formbuilder.cpp:(.text+0x60e): ref erencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilder.o):formbuilder.cpp:(.text+0x6a2): ref erencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilder.o):formbuilder.cpp:(.text+0x736): más referencias a `_Unwind_Resume' sin definir a continuación C:/QT/4.6.2/lib/libQtUiTools.a(formbuilder.o):formbuilder.cpp:(.eh_frame+0x12): referencia a `__gxx_personality_v0' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(textbuilder.o):textbuilder.cpp:(.text+0xfc): refe rencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(textbuilder.o):textbuilder.cpp:(.eh_frame+0x12): referencia a `__gxx_personality_v0' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilderextra.o):formbuilderextra.cpp:(.text+0 x5df): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilderextra.o):formbuilderextra.cpp:(.text+0 x6cb): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilderextra.o):formbuilderextra.cpp:(.text+0 xd45): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilderextra.o):formbuilderextra.cpp:(.text+0 xdec): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilderextra.o):formbuilderextra.cpp:(.text+0 xe84): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(formbuilderextra.o):formbuilderextra.cpp:(.text+0 x152d): más referencias a `_Unwind_Resume' sin definir a continuación C:/QT/4.6.2/lib/libQtUiTools.a(formbuilderextra.o):formbuilderextra.cpp:(.eh_fra me+0x12): referencia a `__gxx_personality_v0' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(moc_properties_p.o):moc_properties_p.cpp:(.eh_fra me+0x11): referencia a `__gxx_personality_v0' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(ui4.o):ui4.cpp:(.text+0x4440): referencia a `_Unw ind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(ui4.o):ui4.cpp:(.text+0x4a0d): referencia a `_Unw ind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(ui4.o):ui4.cpp:(.text+0x4ff1): referencia a `_Unw ind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(ui4.o):ui4.cpp:(.text+0x5669): referencia a `_Unw ind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(ui4.o):ui4.cpp:(.text+0x5c4d): referencia a `_Unw ind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(ui4.o):ui4.cpp:(.text+0x6231): más referencias a `_Unwind_Resume' sin definir a continuación C:/QT/4.6.2/lib/libQtUiTools.a(ui4.o):ui4.cpp:(.eh_frame+0x12): referencia a `__ gxx_personality_v0' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(resourcebuilder.o):resourcebuilder.cpp:(.text+0x9 1f): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(resourcebuilder.o):resourcebuilder.cpp:(.text+0x9 80): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(resourcebuilder.o):resourcebuilder.cpp:(.text+0x9 9d): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(resourcebuilder.o):resourcebuilder.cpp:(.text+0xa 8c): referencia a `_Unwind_Resume' sin definir C:/QT/4.6.2/lib/libQtUiTools.a(resourcebuilder.o):resourcebuilder.cpp:(.eh_frame +0x12):
Re: [Harbour] improve clang a bit
Hi Tamas, Thanks for the patch. We already had LLVM/Clang C detection inside the __GNUC__ branch, is it still necessary, or can we now safely delete it? Viktor On 2010 May 30, at 14:44, Tamas TEVESZ wrote: - clang 2 does c++ now, so only fall back to c mode if we are running clang1 - clang2 has some nice macros for version stuff, use them tested with both clang2 (bsd) and clang1 (linux), both appear to be fine. thanks to viktor for solving my troubles with the $($(shell(($($((subst))$)zoink))$)$))kaboom)$)) madness. Index: src/common/hbver.c === --- src/common/hbver.c(revision 14637) +++ src/common/hbver.c(working copy) @@ -700,6 +700,18 @@ iVerPatch = 0; #endif +#elif defined( __llvm__ ) defined( __clang_major__ ) + + pszName = LLVM/Clang C; + + iVerMajor = __clang_major__; + iVerMinor = __clang_minor__; + iVerPatch = __clang_patchlevel__; + + #if defined( __cplusplus ) + hb_strncpy( szSub, ++, sizeof( szSub ) - 1 ); + #endif + #elif defined( __GNUC__ ) #if defined( __DJGPP__ ) @@ -783,6 +795,15 @@ else hb_strncpy( pszCompiler, (unknown), COMPILER_BUF_SIZE - 1 ); +#if defined( __clang_version__ ) + if (strstr( __clang_version__, ()) + /* 2.0 (trunk 103176) - (trunk 103176) */ + hb_snprintf( szSub, sizeof( szSub ), %s, strstr( __clang_version__, ()); + else + hb_snprintf( szSub, sizeof( szSub ), (%s), __clang_version__); + hb_strncat( pszCompiler, szSub, COMPILER_BUF_SIZE - 1 ); +#endif + #if defined( __DJGPP__ ) hb_snprintf( szSub, sizeof( szSub ), (DJGPP %i.%02i), ( int ) __DJGPP__, ( int ) __DJGPP_MINOR__ ); hb_strncat( pszCompiler, szSub, COMPILER_BUF_SIZE - 1 ); Index: config/bsd/clang.mk === --- config/bsd/clang.mk (revision 14637) +++ config/bsd/clang.mk (working copy) @@ -3,8 +3,11 @@ # ifeq ($(HB_BUILD_MODE),cpp) - # -ccc-clang-cxx - HB_CMP := clang + ifneq ($(findstring clang$(subst x, ,x)version$(subst x, ,x)1,$(shell clang --version)),) + HB_BUILD_MODE := c + else + HB_CMP := clang++ + endif else HB_CMP := clang endif Index: config/linux/clang.mk === --- config/linux/clang.mk (revision 14637) +++ config/linux/clang.mk (working copy) @@ -3,8 +3,11 @@ # ifeq ($(HB_BUILD_MODE),cpp) - # -ccc-clang-cxx - HB_CMP := clang + ifneq ($(findstring clang$(subst x, ,x)version$(subst x, ,x)1,$(shell clang --version)),) + HB_BUILD_MODE := c + else + HB_CMP := clang++ + endif else HB_CMP := clang endif -- [-] mkdir /nonexistentclang.diff___ 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] Multiple Definition ?
I've checked and xhb doesn't have a FILESIZE, so it can be deleted from xhb. Viktor On 2010 May 30, at 19:30, Bruno Luciani wrote: It is posible that this function: filesize exists in two libraries ? files.c in LIBHBCT and xhbfs.c in LIBXHB Thanks for any help Bruno ___ 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 InetInit().....
Do you read the asnwers?
On 2010 May 30, at 21:40, Ale SB wrote:
hbrtl.lib(hbsocket.obj) : error LNK2019: external symbol __imp__wsaio...@36
unresolved referred to in the function _hb_socketGetIFaces
Function to return the machine's local IP.
This function normally in previous versions.
function Ip_Local() //== IP == xxx.xxx.xxx.xxx
local cEstacao := netname(.f.)
local aHosts := {}
InetInit()
aHosts := HB_InetGetHosts( cEstacao )
if aHosts == NIL
aHosts := HB_InetGetAlias( cEstacao )
endif
if Empty(aHosts)
aHosts := hb_InetGetAlias( cEstacao )
endif
InetCleanup()
return ahosts[ 1 ]
How to solve this problem?
Thanks, Ale
--
View this message in context:
http://old.nabble.com/Error-InetInit%28%29.-tp28724310p28724310.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
___
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:[14641] trunk/harbour
Hi, On 2010 May 30, at 22:10, Tamas TEVESZ wrote: On Sun, 30 May 2010, vszak...@users.sourceforge.net wrote: + Clearing forced C++ mode if clang 1.x is detected. (Patch from Tamas Tevesz. Slight fix added by me to set HB_CMP when falling back to C mode. I didn't make tests though.) ; NOTE: Probably HB_BUILD_MODE=c should be export-ed to avoid double evaluation. Pls test it. it appears to be working as i think it should. Thanks. (just noticed, shouldn't the darwin clang spec updated, too? or will this xcode-thing work this out differently?) It's not supported by latest xcode yet, so didn't want to pre-implement it (usually such predictions don't work out ;) Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error InetInit().....
I read yes. But I did not find the solution to this problem with inetinit (). It will be a very tough process to find the solution if you miss to give feedback for the answer I'm giving. I'm out of this thread. 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:[14632] trunk/harbour
Hi Pritpal, I noticed that .hbp file still contains local, system specific settings: --- -3rd=hbide_location=C:\harbour\contrib\gtwvg\tests\ -3rd=hbide_workingfolder=C:\harbour\contrib\gtwvg\tests --- As a rule all Harbour files should be totally relocatable and environment agnostic. IOW, most users won't have above directories in their systems (for *nix users it's outright impossible), so such setting won't work. Can you pls fix or remove them? Viktor On 2010 May 29, at 02:39, vouch...@users.sourceforge.net wrote: Revision: 14632 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14632view=rev Author: vouchcac Date: 2010-05-29 00:39:20 + (Sat, 29 May 2010) Log Message: --- 2010-05-28 17:27 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) + contrib/gtwvg/tests/demowvg.hbp + Project definition. + contrib/gtwvg/tests/wvgactivex.prg + contrib/gtwvg/tests/wvgcuigdialog.prg + contrib/gtwvg/tests/wvgdyndialogs.prg + contrib/gtwvg/tests/wvgmodal.prg + contrib/gtwvg/tests/wvgqt.prg + contrib/gtwvg/tests/wvgtbrowser.prg + contrib/gtwvg/tests/wvgutilities.prg + contrib/gtwvg/tests/wvgwvtclasses.prg + contrib/gtwvg/tests/wvgxbp.prg + Code organized in logical units. * contrib/gtwvg/tests/demowvg.prg - Code moved to smaller modular sources as logical units. This demo was written few years back and then at that point of time no standradized make system was aavailable which led me to club everything in one source. Now because we have an excellent hbMK2 in place so this move has been possible. It is the first in series of reforms pertaining to GTWVG. More are scheduled to be followed. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/tests/demowvg.prg Added Paths: --- trunk/harbour/contrib/gtwvg/tests/demowvg.hbp trunk/harbour/contrib/gtwvg/tests/wvgactivex.prg trunk/harbour/contrib/gtwvg/tests/wvgcuigdialog.prg trunk/harbour/contrib/gtwvg/tests/wvgdyndialogs.prg trunk/harbour/contrib/gtwvg/tests/wvgmodal.prg trunk/harbour/contrib/gtwvg/tests/wvgqt.prg trunk/harbour/contrib/gtwvg/tests/wvgtbrowser.prg trunk/harbour/contrib/gtwvg/tests/wvgutilities.prg trunk/harbour/contrib/gtwvg/tests/wvgwvtclasses.prg trunk/harbour/contrib/gtwvg/tests/wvgxbp.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Making Harbour program with Static Qt Libraries in Linux
That's all. You are ready to make Harbour/GCC/HbQt program with static Qt access. Obviously, you need use HBMK2 for make it and you need add the necessaries Linux libraries in link stage to resolve externals references. Can you tell what are those lib? This information is the only interesting missing bit from current Harbour. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] moc detection in linux environment
Hi, I'm trying making Harbour binaries for linux platform with the last Qt version (4.6.2), but my linux have headers for qt 4.5.2 pre instaled at /usr/include I'm using: export HB_WITH_QT=/home/cdq/qt-everywhere-opensource-src-4.6.2_for_dynamic/include to override the /usr/include folder but HBMK2 has detected the moc utility in the default Linux location and has ignored my override setting ! Using QT 'moc' executable: /usr/bin/moc (autodetected) gcc -I. -I../../../../../include -W -Wall -O3 -DHB_LEGACY_TYPES_OFF -I/home/cdq/qt-everywhere-opensource-src-4.6.2_for_dynamic/include -I/home/cdq/qt-everywhere-opensource-src-4.6.2_for_dynamic/include/QtCore -I/home/cdq/qt-everywhere-opensource-src-4.6.2_for_dynamic/include/QtGui -I/home/cdq/qt-everywhere-opensource-src-4.6.2_for_dynamic/include/QtNetwork -omoc_hbqt_hbdbfmodel.o -c moc_hbqt_hbdbfmodel.cpp moc_hbqt_hbdbfmodel.cpp:14:2: error: #error This file was generated using the moc from 4.5.2. It moc_hbqt_hbdbfmodel.cpp:15:2: error: #error cannot be used with the include files from this version of Qt. moc_hbqt_hbdbfmodel.cpp:16:2: error: #error (The moc has changed too much.) make[3]: * [moc_hbqt_hbdbfmodel.o] Error 1 make[2]: * [descend] Error 2 make[1]: * [hbqt.inst] Error 2 make: * [contrib.inst] Error 2 Can you help me to detected the moc utility from the folder /home/cdq/qt-everywhere-opensource-src-4.6.2_for_dynamic/include? Set HB_QT_MOC_BIN. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Making Harbour program with Static Qt Libraries in Linux
This Recipe , allow harbour to create hbqts.a hbqtcores.a hbqtguis.a hbqtnetworks.a Library that permits compile an HBQT program using static QT libraries That's not news for me, I gave them these names. in order to , for example create an installer compiled static , thats works in all linux distribution without need to install any shared library. No, this is not the recipe. The most important information is still missing: What are the necessary libs to create static qt apps on Linux? 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:[14626] trunk/harbour
Hi Przemek, Hi Viktor, ; Tried to add hbolesrv.c as direct source 'sources=hbolesrv.c', but it requires this source (+ headers) to be distributed along the binaries, plus it didn't resolve the watcom issue, so I dropped it. Using hbolesrv.c directly in the project resolves multiple entry point error in Watcom Builds. I tested it. I got a large number of unresolved externals. I think we should handle the watcom problem as a whole. Until then hbolesrv.c can just be added after regular server sources to solve the multiple entry problem. Plus there is also the distribution problem. Overall it'd be much cleaner to have everything in hbwin lib, since it's required anyways. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBMK2 problem
Hi Przemek, It's hard for me to test current OpenWatcom behavior using WINE because some results can be strictly bound with Linux and WINE emulation so I cannot say if they are correct or not, i.e. the things I should test like detaching from terminal and allocating console windows works differently in WINE then in native Windows. I'll try but I cannot say I will have any valuable results. I understand. [ my offer for remotely accessible Windows environment still stands though. Just tell me. ] The problem is only for users who will want to use harbour.dll created by Open Watcom with some other C languages so it's not very common. Probably we should ignore it now switch to register calling convention and then if possible look for some solutions which can force using C calling convention for exported Harbour functions. It also causes that watcom builds cannot utilized harbour.dll created with non-watcom compiler, which is a problem, because in windows unified build I include harbour.dll built with mingw, so in effect watcom -shared mode doesn't work by default. For me it's a feature because OpenWatcom harbour.dll used with other C compiler GPFs immediately. I strongly prefer such behavior instead of some strange bug reports for which I invest time looking the reason of problem and then I'm finding that it's caused by some small differences between used C compilers, i.e. BCC uses 8bytes alignment and most of other MS-Windows C compilers 4 bytes alignment what can cause corruption of some HVM structures. So I strongly suggest to never mix DLLs created by different compilers and I would like to know about such situation when anyone reports bugs. To me such approach seems to defeat the almost whole point of having .dlls. I think .dlls should be able to interoperate, otherwise we lose one of their basic features. IMO when creating a .dll we should provide a standard and documented ABI, which means a standard set of available functions and a standard calling convention (and aligment). So far we're doing good and only bcc stands off from the pack, but bcc isn't such important (plus it very much seems impossible to bend it right) so it's okay. But, if there is any way to juggle settings to make this dream possible for as much targets we support, we should IMO try it. F.e. this feature makes it possible to ship the unified Windows binary package in proper way. The shipped .dlls are mingw built which in turn works well with msvc, pocc and watcom. Same is true if .dlls are built with msvc. And the same is true for x64 .dlls (currently built with msvc64, but by now also mingw64 works). Do you see any notion or chance to fix the issue by using __cdelc for watcom? This seems to be quite easy to introduce by small modification in HB_EXPORT macro so we can make some experiments when we restore original OpenWatcom calling convention. That would be very nice. I reached a dead-end with my experiments, hopefully you can breath some fresh air into the matter :) 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:[14626] trunk/harbour
Hi Przemek, I got a large number of unresolved externals. I think Because you haven't recompiled whole Harbour code with -r6 watcom compiler switch. I know, I use default build. Most users will use default build, so that's what we shall make work. we should handle the watcom problem as a whole. Until then hbolesrv.c can just be added after regular server sources to solve the multiple entry problem. For me this are two different things. 1. broken watcom binaries due to forces stack calling convention. It's broken either way. Default is broken for OLE servers, special build is broken for non-watcom Harbour .dlls. 2. chosing startup entry point for created binaries and interaciton with existing hack with hb_forceLinkMainWin()/hb_forceLinkMainStd(). I never got that topic, so all I can add is that it would be great to drop any hack, including this one, if possible :) Plus there is also the distribution problem. Overall it'd be much cleaner to have everything in hbwin lib, since it's required anyways. I agree with having everything in hbwin lib. But for this we have to remove or update hb_forceLinkMainWin()/hb_forceLinkMainStd() bindings from hvm.c and adopt and if necessary adopt for this modification link command in GNU make system and HBMK2. Okay with me. 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:[14626] trunk/harbour
Hi Viktor, For me this are two different things. 1. broken watcom binaries due to forces stack calling convention. It's broken either way. Default is broken for OLE servers, special build is broken for non-watcom Harbour .dlls. The default build is broken for any OLE code and maybe some other type of code. And it's broken for very long time. The problem was reported few times to this list in the past, i.e. in last year Marek reported it and because we haven't fixed it then he droped OpenWatcom and switched to MinGW. Probably also many other users changed C compiler and now no one reports problems with OpenWatcom builds. In summary MS-Windows OpenWatcom builds has been not usable for users who need some functionality like OLE for over year. The problem with harbour.DLL exists only for users who want to mix C compilers and use harbour.dll compiled by different C compiler then the one used for static libraries and user code what is not a problem for users who do not plan to make such mix. It's a problem for all users trying to use the unified Windows builds in watcom -shared mode. The other is a problem for users who want to use OLE. The point is: It's broken in both ways, just differently. If it helps I can delete win/watcom target from unified package, which solves my concern, though it's far from a proper solution. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Documentation storm on user's list
To put it an other way, the crucial subject today, is not any more the open source code. It is (and always was) the open knowledge. Nobody ever promised that knowledge or mastery will automatically fly into the users' brains, just by having access to the information, be it open source, blueprints, scientific papers or the wikipedia. Pls remember that even such _quite well documented_, _fully open_ and long time known systems as Linux, have several companies _earning_ large sums of money by supporting them (f.e. Red Hat), selling workforce who do actually understand the system and _translates_ that to knowledge for the benefit of customers/users, even in the form of documentation. All of these require an _effort_. You can do this effort yourself, or you can ask other to do that. In latter case, you either pay for it or motivate them by other means. Second option seems more complicated with documentation (than with code) as it is huge work and the one who does it doesn't benefit from it in too many ways. Looks like it's not enough to give something for free to expect any sort of return for it. Why we have such a brilliant and huge amount of excellent code, like Harbour has become thanks to your (and all of developers) tremendous efforts and not an analogous documentation? See above. We said, it is difficult to create documentation. but if we think it better, difficulty is not the main reason. The main reason is that nobody wants documentation so much, nobody is burned to create it. and the deeper cause of this, is the lack of belief to the great value of a documentation, is the lack of belief to the vital significance of a manual, it is because we are much eager for I think nobody ever questioned that documentation and samples are nice and useful, or even crucial. That was never a question. Viktor, i 'm not interest to bugging you, (i don't know what exactly the bugging is, or means, but if it is related to the activity of a bug, then i think it's my time to start feeling offended. However, feeling offended or not, doesn't cure my real displeasure to feel almost guilty because i can't find a practical way to effectively contribute documentation. Bugging is: write documentation friendly code, create samples, create good comments Did you notice I created INSTALL, with 330 updates in the last 15 months? Did you notice Przemek creating lots of e-mails which are better than most written documentation, or not to mention xhb-diff.txt, which is almost like an academic paper? Or I could mention docs created by Pritpal for HBIDE. Can you imagine how much time does it take to create these thing? If you don't, just keep on asking for more, or telling what you tell, you risk that some will find it as bugging. Overall, I see no lack in lead by example here... The problem is there is nobody to follow. Demanding more without appreciating work already done is probably the surest motivation killer [ especially in open source, where appreciation is the most important (or only) motivation factor ]. ___ P.S. Strangely enough, i see no reaction to the challenging idea of harbour-xhb merging. Does the harbour community think it was a joke or this deafening silence express their glacial indifference about the future of Harbour? It wasn't a joke. 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:[14621] trunk/harbour
Hi Rossine, With this change, i have GPF down: Thanks for your report, I've made the necessary correction, pls check again after r14631. [ it's possible some more tweaks will be needed, f.e. original CALLDLL32 is very unsafe by directly modifying string buffers, so in the new compatibility version, such string parameters will have to be passed by reference. ] 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:[14631] trunk/harbour
Hi, bcc32.exe -I. -I../../../../../include -q -tWM -CP437 -w -Q -w-sig- -d -6 -O2 -OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF -Ic:\bcc582\bin\bcc32.exe c:\bcc582\bin\ ..\Include -DHB_GC_AUTO -DHB_FM_STATISTIC -ohbpp_dyn.obj -DHB_DYNLIB -c ../.. /../hbpp.c ../../../hbpp.c: ilink32.exe -Lc:\bcc582\bin\bcc32.exe c:\bcc582\bin\..\Lib -Lc:\bcc582\bin\bcc32.exe c:\bcc582\bin\..\Lib\PSDK -L..\..\..\..\..\lib\win\bcc -Gn -Tpe c0x32.obj hbpp.obj, ..\..\..\..\..\bin\win\bcc\hbpp.exe, nul, hbnortl hbcommon kernel32 user32 ws2_32 advapi32 gdi32 cw32mt import32,, Again some weird local configuration problem. Probably doubly included BCC dir in PATH. I've just updated INSTALL yesterday to highlight this very problem. I'd like to ask all users to pay more attention to messages on this list, and particularly to INSTALL docs. Ppl cry for docs, but don't read what's available. Viktor ___ 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:[14611] trunk/harbour
+ contrib/hbqt/hbqt.h + Added: constants hbqt_par_Qsci* ; TODO make them local. This is serious modularization fault, even for an initial upload. Pls fix it. Yes, sure. I need a name of such .h - hbqt_local.h ? contrib/hbqt/qscintilla/hbqscintilla.h which refers to ../hbqt.h + Initial upload of wrappers for QScintilla. To generate the sources auto you need to stay in hbqt/hbqscintilla and issue ../generator/hbqtgen. HB_WITH_QSCINTILLA and HB_WITH_QT need be properly defined. I am still finding where to host modified QScintilla, any tips ? Are you sure you need to modify this external lib to make it work with HBQT? My experiments say it is must. 1. Flagship lexer is not implemented in QScintilla which I did. Smells like an upstream patch. 2. May be it can go, but a lot of warnings while compiling QScintilla as per Harbour make system. It can be suppressed, or just simply ignored. It's not our code, they are not our warnings, if it works, it's good for us. 3. I could only build static lib, .a, and do not know how to a shared one, .dll. That's a problem hitting distribution, not code hosting. If the code needs to be patched, it looks like a definite upstream patch. 4. One serious issue which I could not resolve, commenting out a line delete [] words; solved the problem, otherwise GPF. I know it may lead to leaked memory but unless someone with more knowledge look into it, I could not fix. words is defined as - char * words. Looks like a serious problem to me. Current solution is not a very good hack. Could be upstream bug to fix, I don't know. 5. It is just the begining, I may need some more tweaking to achieve some more goals, so may be needing to tweak Scintilla sources itself. That's bad direction, I'd very strongly suggest to avoid forking. Take it a black-box and use as is, as documented. If there is a problem, report back to author or qscintilla forums. 6. Author, Phil Thomson, did not reply when I offered Flagship lexer code to him plus few fixes to get rid of the warnings. His only reply was, I don't understand this. By including QScintilla your application must becompatible with the GPL. This means that you must make all the source codeavailable to your users, and allow them to rebuild the application. So whycan't you build it yourself as well? Because we do not want to fork. But it's possible that your patch wasn't generic or had other problems, so upstream patch is not always the answer, or it may need to be reiterated. It was on request that if he can provide a binary distro anyway because Harbour users do not know enough about Qt and its build system. As hbIDE itself is open source, it confirm to GPL license, so no issues. The only problem is how to manage it. My impression is still that it'd be the best to move hosting of complete HBIDE and even HBQT to a different repository with more lax rules, so you could manually maintain a fork if you think it's the best solution. While I believe it should be technically possible to avoid the fork and solve everything without massive (or even any) QSCINTILLA patches), I see a very bumpy road ahead and lots of wasted energy. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBMK2 Inquiry
Hi, hbmk2: Compiling... hbmk2: Linking... conso.exe Info: resolving vtable for __cxxabiv1::__si_class_type_info by linking to __imp_ __ZTVN10__cxxabiv120__si_class_type_infoE (auto-import) Info: resolving vtable for __cxxabiv1::__class_type_info by linking to __imp___Z TVN10__cxxabiv117__class_type_infoE (auto-import) Info: resolving vtable for __cxxabiv1::__vmi_class_type_info by linking to __imp ___ZTVN10__cxxabiv121__vmi_class_type_infoE (auto-import) Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import) c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: warning: a uto-importing has been activated without --enable-auto-import specified on the c ommand line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. Can someone explain what this means? No clue from here, maybe a broken mingw installation. To tell more pls post -trace output and hbmk2 cmdline. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBMK2 problem
Hi Przemek, Another thing I noticed is that I cannot build watcom servers, not clients. For servers it complains about 'Error! E2030: file clib3s.lib(cstrtwwt): multiple starting addresses found', for clients there are unresolved symbol, even if I comment the special -cflag in .hbp. You have to recompile whole Harbour core code with HB_USER_CFLAGS=-6r to resolve insufficient dependencies. The multiple entry points are probably caused by DllMain() in hbwin.lib and WinMain() in hbvm.lib so linker does not know which one should chose. Yes. Maybe it can be resolved by adding some linker command to hbolesrv-watcom.def. For sure it can be done by linking hbolesrv.c directly not from library. In such case linker gives higher priority to code in .obj files so takes DllMain() from hbolesrv.obj before begins to scan libraries. If you link OLE server dynamically then it also resolves this problem. Alternatively we can move WinMain() to separate library or remove strict binding to HVM (hb_forceLinkMainWin()) and add some code to HBMK2 which will force linking with WinMain() if necessary (GUI application is created). hb_forceLinkMainWin reference was added to HVM code for quite old OpenWatcom versions and maybe can be eliminated now or maybe it's enough to add some commands to link script by HBMK2. Removing hb_forceLinkMainWin() reference from watcom builds should resolve the problem. You only have to check if HBMK2 can still create static GUI binaries for using OW. I'd appreciate if you could find some to make some patches, I'll try to follow it with hbmk2. I think watcom should truly be fixed by switching to default callconv on the Harbour level, though in this case for win/watcom builds all HB_EXPORT declarations need have a __cdecl modifier added between return type and function name. And this is currently not possible without creating a new scheme for public C function declaration (at least I could not find a painless solution). The problem is only for users who will want to use harbour.dll created by Open Watcom with some other C languages so it's not very common. Probably we should ignore it now switch to register calling convention and then if possible look for some solutions which can force using C calling convention for exported Harbour functions. It also causes that watcom builds cannot utilized harbour.dll created with non-watcom compiler, which is a problem, because in windows unified build I include harbour.dll built with mingw, so in effect watcom -shared mode doesn't work by default. Shipping special watcom .dlls is not a good option due to size, so maybe win/watcom libs can just be dropped from the distro as a solution, albeit a drastic one and rather a workaround. Do you see any notion or chance to fix the issue by using __cdelc for watcom? 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:[14609] trunk/harbour
Thanks very much, I'll update the code. I have two questions/notes: - I noticed that COM_NUM may not be what original CT does, though the NG is a little bit easy to misunderstand. It looks COM_NUM() now returns next free slot, while in CT it returned maximum number of com ports. - If COM_NUM() returns max number of port slots, how to retrieve next free one? Viktor On 2010 May 27, at 09:05, Przemysław Czerpak wrote: On Wed, 26 May 2010, vszak...@users.sourceforge.net wrote: Hi, 2010-05-27 00:15 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/examples/contribf.hbc * contrib/Makefile + contrib/hbcomm + contrib/hbcomm/Makefile + contrib/hbcomm/hbcomm.hbc + contrib/hbcomm/hbcomm.prg + contrib/hbcomm/hbcomm.hbp + contrib/hbcomm/tests + contrib/hbcomm/tests/hbmk.hbm + contrib/hbcomm/tests/test.prg + Added HBCOMM compatibility library. It's based on hbct COM functions. Not tested with real port. Also see one TOFIX and one INCOMPATIBILITY note inside. The latter belongs to INCHR() function which in original HBCOMM library will do HVM corruption by overwriting string content passed as 3rd parameter. In Harbour 3rd parameter needs to be passed by reference. Also added fully adapted test code from HARBOUR MINIGUI project. Interestingly this code was using the return value of INCHR() to get the returned buffer, which was in sync with included HBCOMM code. Anyway, hopefully this can be finalized based on report from real users. Thank you for your contribution. I do not know HBCOMM library so I cannot help you much but you wrote in the code: /* Send out characters. Returns .t. if successful. */ FUNCTION OUTCHR( nPort, cString ) RETURN com_send( nPort, cString ) and this function return number of character which were not sent. If your comment is correct then it should be changed to: FUNCTION OUTCHR( nPort, cString ) RETURN com_send( nPort, cString ) == 0 otherwise the description should be updated. best regards, Przemek ___ 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] Vouch32 ActiveX Server - Unrestricted Version
Thank you Pritpal for this contribution to the Harbour community. I'm going to check VOUCH now. Viktor On 2010 May 27, at 09:27, Pritpal Bedi wrote: Hello All I have just uploaded Vouch32 ActiveX Server with all the necessary files; application code with .hbp, .chm help and the server without any restrictions. It is compiled with latest Harbour and Przemek's excellent contribution towards this end. You do not need to ask for license key. Use it. It has all the powerful print engine with preview, graphic and charts plus report generator, and is extremly easy to use. The samples/harbour/V32xDemo.prg demonstrate the application specific constructs and is accompanied by .hbp. The server behaves best under GTWVG or GTWVT, where it executes the dialogs in separate thread. But console ( windows ) applications like GTWIN can also use it. Demo code also shows how to register server programatically. More details and screen-shots can be found at http://www.vouch32.com/ - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Vouch32-ActiveX-Server-Unrestricted-Version-tp5107328p5107328.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Documentation storm on user's list
To Pete, [ Sorry to reply here, but I'm readonly user of users-list. ] yeah, sure! very well and very idealistic.. (but please keep in mind that idealism is the container of fanaticism -and of any obnoxious -ism in general. we don't need them any more.) asking is not only a right, is the creative trigger for everything being made by human race; and please don't confuse asking with demanding nor user with consumer. Into the subject now, maybe it's difficult to understand and accept it but, documenting is more valuable than coding itself. IMHO, documentation is (or must be) on upper top, in the scale of open source priorities, since documents, or better the lack of documents, is straightly against to the spirit of open source initiative, because if open source, due to lack of documents, is not easily understandable/self-learn-able, becomes unusable to wider programmer-cycles and degenerates to a cryptic tool in hands of an illuminated elite, less or not at all, different than closed software. And this is a real problem with wider consequences than you can imagine. Of course nobody can demand from developers to write manuals. All that one could ask from them is to be, their coding, more documentation friendly, ensuring this way that their valuable and very respectable labor and creation won't go in vain.. Strange and insulting thoughts towards anyone who have dedicated huge amount (many years) of (maybe even full time) to take this project where it is now. Maybe you could elaborate on what you mean by documentation friendly code... If coding means nothing to you, pls delete all the Harbour sources and try to use it after... If documentation is so important, why wasn't there even a single person (f.e. you?) who would take the pain and write even a small snippet of it? By now if every user who benefitted from this free product named Harbour, would have done so, we'd probably have a full documentation. All information is right there in the source, mailing list and ChangeLog, open and accessible to everyone, and all educated questions (unlike the one that started off this thread) used to be answered on our forums, and yes it sometimes triggers ideas as you say, but the emphasis is on educated. Remember you got something for free, so before demanding anything, asking for more or complaining like children, think about what _you_ can do to change the situation. Idealism is thinking that you get can everything from thin air, without thinking, learning, contributing and/or paying for it. In reality potential users have three choices for _all_ open source software: - don't use it - accept what's offered - contribute (that's also the best form to say thank you) Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBMK2 Inquiry
Hi Jerry, No clue from here, maybe a broken mingw installation. To tell more pls post -trace output and hbmk2 cmdline. I did some research and found out that this is a bug from mingw 4.5. It was fixed before but I don't know why it resurface. So for now Im dropping 4.5 and wait for the official release. I'm using official mingw 4.5 release without such problem, though this may depend on the input (or build options) you're trying use. BTW can you check if nxcompat is supported for TDM mingw 4.4? Im getting an error compiling It doesn't, so for all 4.4 mingw versions, nxcompat is disabled. Quote from mingw.mk: --- # It is also supported by official mingw 4.4.x and mingw64 4.4.x, # but not supported by mingw tdm 4.4.x, so I only enable it on or # above 4.5.0. --- hbpp.exe with gcc saying nxcompat is not a valid option. You should delete HB_COMPILER=mingw and let the build autodetect everything. It will work. 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:[14614] trunk/harbour
FUNCTION SubscribeNow( ... )
RETURN {| mtx, nTimeOut, lSubscribed |
local xSubscribed
lSubscribed := hb_mutexSubscribeNow( mtx, iif( hb_isNumeric(
nTimeOut ), nTimeOut / 1000, ), @xSubscribed )
return xSubscribed
}:eval( ... )
Why this code is written in such complicated way???
Only because I mechanically converted translations.
Anyhow this version got deleted in the next commit,
and now the already existing clean version is live
again.
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] --nxcompat MingW
On 2010 May 27, at 18:31, Itamar Lins wrote: Hi! Please see this: Win XP SP3 with MingW. r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: unrecognized option '--nxcompat' c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use the -- help option for usage information collect2: ld returned 1 exit status win-make.exe[3]: *** [harbour-21.dll] Error 1 win-make.exe[2]: *** [descend] Error 2 win-make.exe[1]: *** [dynlib.inst] Error 2 win-make.exe: *** [src.inst] Error 2 PS. Is possible be my fault enviroment config. I change my HD. I've replied this like 50 times, the last time about 2 hours ago. Delete HB_COMPILER envvar. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error with bcc582
Hello Viktor,
I suggest to use hbmk2 to build hbcomm...
OK i rebuilt harbour release 14618 the traditional way:
\harbour\bin\mingw32-make.exe clean install
...and also your app, and it should link properly.
OK. But the error continues.
I use for compile this command:
hbmk2 -trace -info -n -gc3 /I. -ic:\minigui\include myprog %1 myprog.hbm
myprog.hbc comp.log
In my .hbc i have:
{bcc}libs=hbcomm
What can it be ?
Sorry, I don't know. HBCOMM lib is built using non-hbmk2
solution, so I cannot tell you what was messed up along
the way, C++ is tricky to build, probably something is
messed up.
Try building HBCOMM using hbmk2 also (I tested this case
and it DID work for me), or try using recently added HBCOMM
lib emulation inside Harbour contrib area. It's pure .prg code
and unlike original C++ HBCOMM lib, it won't cause HVM
corruption.
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: --nxcompat MingW
Pls post the BEGINNING of your log to see what autodetection does. Viktor On 2010 May 27, at 19:00, Itamar Lins wrote: Em 27/5/2010 13:57, Viktor Szakáts escreveu: On 2010 May 27, at 18:31, Itamar Lins wrote: Hi! Please see this: Win XP SP3 with MingW. r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: unrecognized option '--nxcompat' c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use the -- help option for usage information collect2: ld returned 1 exit status win-make.exe[3]: *** [harbour-21.dll] Error 1 win-make.exe[2]: *** [descend] Error 2 win-make.exe[1]: *** [dynlib.inst] Error 2 win-make.exe: *** [src.inst] Error 2 PS. Is possible be my fault enviroment config. I change my HD. I've replied this like 50 times, the last time about 2 hours ago. Delete HB_COMPILER envvar. Viktor But this is envvar HB_COMPILER not set for here. See my envvar: ALLUSERSPROFILE=C:\Documents and Settings\All Users APPDATA=C:\Documents and Settings\Itamar\Dados de aplicativos CLIENTNAME=Console CommonProgramFiles=C:\Arquivos de programas\Arquivos comuns COMPUTERNAME=ACER3000 ComSpec=C:\WINDOWS\system32\cmd.exe FP_NO_HOST_CHECK=NO HB_INSTALL_PREFIX=c:\dev\harbour HB_WITH_BLAT=C:\blat\blat262\full\source HB_WITH_QT=C:\Qt\2009.04\qt\include HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Itamar LOGONSERVER=\\ACER3000 MAQ=FSICAL NUMBER_OF_PROCESSORS=1 OS=Windows_NT Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\mingw\bin;C:\Dev\Harbour\bin;C:\Arquivos de programas\TortoiseSVN\bin;C:\Arquivos de programas\CVSNT\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\mingw\bin;C:\Dev\Harbour\bin;C:\Arquivos de programas\TortoiseSVN\bin;C:\ARQUIV~1\ARQUIV~1\MUVEET~1\030625 PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 15 Model 44 Stepping 2, AuthenticAMD PROCESSOR_LEVEL=15 PROCESSOR_REVISION=2c02 ProgramFiles=C:\Arquivos de programas PROMPT=$P$G SESSIONNAME=Console SystemDrive=C: SystemRoot=C:\WINDOWS TCX=ITAMAR TEMP=C:\DOCUME~1\Itamar\CONFIG~1\Temp TMP=C:\DOCUME~1\Itamar\CONFIG~1\Temp USERDOMAIN=ACER3000 USERNAME=Itamar USERPROFILE=C:\Documents and Settings\Itamar windir=C:\WINDOWS Best regards, Itamar M. Lins Jr. ___ 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: --nxcompat MingW
! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org ! MAKE: win-make.exe 3.81 sh.exe INSTALL ! HB_INSTALL_PREFIX: c:\dev\harbour ! HB_HOST_PLAT: win (x86) HB_SHELL: nt ! HB_PLATFORM: win (x86) (autodetected) ! HB_COMPILER: mingw (v45) (autodetected: C:/mingw/bin/gcc.exe C:/mingw/bin/) ! Component: 'zlib' found in C:/harbour/trunk/harbour/external/zlib (local) ! Component: 'pcre' found in C:/harbour/trunk/harbour/external/pcre (local) ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. ! Component: 'gpm' not supported on win platform ! Component: 'slang' not found. Configure with HB_WITH_SLANG. ! Component: 'curses' not found. Configure with HB_WITH_CURSES. ! Component: 'x11' not found. Configure with HB_WITH_X11. ! Component: 'wattcp/watt-32' not supported on win platform Thank you. Pls also post the content of C:/mingw/bin/ directory. Also pls tell what is the source of this mingw distro? Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: --nxcompat MingW
God. The how to f*ck up contest continues :( You have mingw two times in PATH. Remove one. Viktor On 2010 May 27, at 19:27, Itamar Lins wrote: Em 27/5/2010 14:21, Viktor Szakáts escreveu: ! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org ! MAKE: win-make.exe 3.81 sh.exe INSTALL ! HB_INSTALL_PREFIX: c:\dev\harbour ! HB_HOST_PLAT: win (x86) HB_SHELL: nt ! HB_PLATFORM: win (x86) (autodetected) ! HB_COMPILER: mingw (v45) (autodetected: C:/mingw/bin/gcc.exe C:/mingw/bin/) ! Component: 'zlib' found in C:/harbour/trunk/harbour/external/zlib (local) ! Component: 'pcre' found in C:/harbour/trunk/harbour/external/pcre (local) ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. ! Component: 'gpm' not supported on win platform ! Component: 'slang' not found. Configure with HB_WITH_SLANG. ! Component: 'curses' not found. Configure with HB_WITH_CURSES. ! Component: 'x11' not found. Configure with HB_WITH_X11. ! Component: 'wattcp/watt-32' not supported on win platform Thank you. Pls also post the content of C:/mingw/bin/ directory. Also pls tell what is the source of this mingw distro? Viktor C:\MinGW\bin 27/05/2010 14:23DIR . 27/05/2010 14:23DIR .. 03/02/2009 11:10 545.280 addr2line.exe 03/02/2009 11:10 562.688 ar.exe 03/02/2009 11:10 968.704 as.exe 04/10/2009 21:13 227.840 c++.exe 03/02/2009 11:10 544.256 c++filt.exe 05/07/2001 13:11 226.816 cpp.exe 03/02/2009 11:10 588.800 dlltool.exe 03/02/2009 11:1057.856 dllwrap.exe 04/10/2009 21:13 227.840 g++.exe 05/07/2001 13:11 225.280 gcc.exe 05/07/2001 13:1116.207 gccbug 05/07/2001 13:1151.219 gcov.exe 23/04/2008 22:09 2.584.576 gdb.exe 23/04/2008 22:0958.880 gdbserver.exe 03/02/2009 11:10 605.184 gprof.exe 03/02/2009 11:10 785.408 ld.exe 05/07/2001 13:12 239.328 libgcc_s_sjlj-1.dll 04/10/2009 21:13 227.840 mingw32-c++.exe 04/10/2009 21:13 227.840 mingw32-g++.exe 05/07/2001 13:11 225.280 mingw32-gcc-4.4.1.exe 05/07/2001 13:11 225.280 mingw32-gcc.exe 05/06/2008 10:36 165.376 mingw32-make.exe 14/08/2009 23:5718.207 mingwm10.dll 03/02/2009 11:10 555.008 nm.exe 03/02/2009 11:10 692.224 objcopy.exe 03/02/2009 11:10 1.011.712 objdump.exe 13/05/2001 10:4771.886 pthreadGC2.dll 13/05/2001 10:47 120.455 pthreadGCE2.dll 03/02/2009 11:10 562.688 ranlib.exe 03/02/2009 11:10 281.600 readelf.exe 03/02/2009 11:10 547.328 size.exe 03/02/2009 11:10 546.304 strings.exe 03/02/2009 11:10 692.224 strip.exe 03/02/2009 11:10 567.296 windmc.exe 03/02/2009 11:10 649.728 windres.exe Mingw is Tdragon: 18/10/2009 20:4227.414.487 tdm-mingw-1.908.0-4.4.1-2.exe Best regards, Itamar M. Lins Jr. ___ 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] BUG: hb_arrayToParams( {} )
Hi Przemek,
Accidentally found this:
---
PROC MAIN()
QOUT( hb_arrayToParams( {} ) )
RETURN
---
- GPF (tested on win/mingw)
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: --nxcompat MingW
C:\harbour\trunk\harbourwin-make.exe install ! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org ! MAKE: win-make.exe 3.81 sh.exe install ! HB_INSTALL_PREFIX: c:\dev\harbour ! HB_HOST_PLAT: win (x86) HB_SHELL: nt config/global.mk:971: *** ! HB_COMPILER not set, could not autodetect. Stop. C:\harbour\trunk\harbourset path=c:\mingw\bin;%PATH% C:\harbour\trunk\harbourwin-make.exe install Now compiling fine until here: lp.o dbgtinp.o dbgtmenu.o dbgtmitm.o dbgtwin.o debugger.o dbgtarr.o dbgthsh.o db gtobj.o tbrwtext.o dbgwa.o dbgbrwsr.o ) || del /q /f ..\..\..\..\..\lib\win\min gw\libhbdebug.a 1 arquivo(s) copiado(s). gcc -Wl,--nxcompat -Wl,--dynamicbase -shared -L../../../../../lib/win/mingw -o ../../../../../bin/win/mingw/harbour-21.dll __dyn__.tmp -lkernel32 -luser32 -lw s2_32 -ladvapi32 -lgdi32 -Wl,--out-implib,../../../../../lib/win/mingw/libharbou r-21.a,--output-def,../../../../../bin/win/mingw/harbour-21.def c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: unrecogniz ed option '--nxcompat' c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: use the -- help option for usage information collect2: ld returned 1 exit status win-make.exe[3]: *** [harbour-21.dll] Error 1 win-make.exe[2]: *** [descend] Error 2 win-make.exe[1]: *** [dynlib.inst] Error 2 win-make.exe: *** [src.inst] Error 2 Pls clean up your environment, I cannot help more. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: --nxcompat MingW
Em 27/5/2010 15:36, Itamar Lins escreveu: ---8 Using prompt tdradgon, the result is: Path=C:\MinGW\bin;C:\WINDOWS\system32; --8--- Maybe upper case M and GW of word MinGW ? No, it doesn't matter. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: --nxcompat MingW
2010/5/27 Itamar Lins itamarl...@gmail.com mailto:itamarl...@gmail.com Em 27/5/2010 14:50, Viktor Szakáts escreveu: C:\harbour\trunk\harbourset path=c:\mingw\bin;%PATH% You not clean Hi! Only one version MinGW on HD. The path c:\mingw\bin, if I set for exemple 2 times, is the same MinGW version. Remove one of the same entries from PATH. Why not listen? Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Documentation storm on user's list
[I finally managed to discover that my post in users-forum had been replied here. so, here it is my humble yet belated answer] are you sure you have understood my words? I 'm afraid you don't! What I am not sure for, is the reason for this misunderstanding. Perhaps, is it due to my bad English or what? And how did you find insulting thoughts, there where it doesn't exist? When I am saying documentation is more valuable than coding, in no way mean that coding is nothing. Yes, it read just that way. Maybe one day someone will teach me how to write documentation instead, so something valuable can be done at least. Maybe some day someone will teach us how to create documentation friendly code in my free time. It just means that without documentation, many parts of code is almost unusable, for many people (users). We all agree with you that if every individual harbour user would be willing to write some (small) part of documentation, the Harbour manual would perhaps be already here. But life has shown that it is not that simple. Months ago we have had the very same discussion. many people had then declared their interest to contribute, some of them had shown their valuable ideas and had made specific proposals. Unfortunately after a while the interest had faded out, and the only real remained/result was an documenting extension into hbide, which supposedly would help to write documentation. I have tried to use it. It didn't work (not in operational meaning of the term). Beyond this, i 've had spent hours digging into sources, trying to format some pieces of documentation. the results were not significant. why? because writing documentation is indeed difficult, actually is more difficult than somebody can imagine and for sure more difficult than coding. that's why, i suppose, for every thousands good coders correspond few -very few or even none- good documenters. We didn't need HBIDE documentation extension, and we still don't need it to create docs. Unfortunately all our attempts to solve documentation quickly becomes a tool frenzy. Maybe when such pops up, you should voice your opinion in time. The only upside of last discussion is that we more or less nailed out the final NFDOC documentation format, but not enough that anyone would feel to pick it up and continue (or tell something better). Regarding your definition of idealism, i couldn't put it better. thinking, learning, contributing and/or paying is the only realistic approach. Starting from the later, please don't have any doubt that I (and I believe many other Harbour users) would be more than willing to _pay_ for a manual if anything did exist. Contributing is another crucial story. Unfortunately if users are willing to pay for what doesn't exist, it won't help us the smallest bit. Plus the existing xhb documentation is available for money since years, yet nobody buys it. So what am I missing? All I see is empty words. Nobody's _demanding_ anything from developers. And how one could do that? But asking for documentation should not considered as a demand. Is a very normal and absolutely expected query for any newcomer to Harbour. The do it yourself is a pushing away answer. What insulting do you find in this paragraph? Demanding and asking are two very different things, and it's usually easy to tell apart after having some time spent on public forums. Demanding: Asking others to do something. Asking: Asking a question in an interactive or productive fashion. Notice that the latter sometimes may even be considered as contribution. Huge difference. By documentation friendly code i mean two simple and very well known things. a. Short introductory description on top of source code (in place of this long and more or less useless copyright reminding replica ) b. in-line comments. c. sample program. [OK, they are three, but any combination of two will perfectly do the job ;)] I find this largely offensive. Did you check the code for comments? What exactly do you expect, hidden full blown documentation inside the source? Sample programs: all developers have done their fair share, so pls don't continue bugging us with it. But, the short and generic answer is: DO IT if you miss it. All I see is you criticizing from the high ground without even considering how much work is what you ask for, and how much work has been done totally unnoticed by you... You seem to miss the ground rule of open source: everyone does something to scratch an itch. Some of us many times do much more than that, but pls don't ask for more, more and more, just do it. P.S.: merging harbour-xhb? (wow! this question could be a real philosophical dilemma). although this is a core-developers decision, you better don't have doubts that the great majority of the users, in case they'd been asked for, would loudly vote No! While your conclusion is valuable, perhaps
Re: [Harbour] SF.net SVN: harbour-project:[14624] trunk/harbour
Thank you very much. Viktor On 2010 May 27, at 22:56, dru...@users.sourceforge.net wrote: Revision: 14624 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14624view=rev Author: druzus Date: 2010-05-27 20:56:44 + (Thu, 27 May 2010) Log Message: --- 2010-05-27 22:56 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/hvm.c ! fixed GPF when hb_arrayToParams() is used with empty array reported by Viktor. 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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Console Terminal with GUI Application under Linux
Hi, I have compiled my application under Ubuntu 10.4 with -gui -gtxwc from my .hbp. I also have REQUEST HB_GT_XWC in my main module. When I execute the application, the terminal console is not being released and remains inactive from the background. Any switch that I might be missing? I noticed that I don't have gtgui lib not like in Windows. Thanks for any help. Mario ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano Hi Massimo, I have tried your suggestion but the inactive console window is still present. Append '' to the command line. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] vise the return of the functions: TimeToSec andSecToTime...
In case of HBCT we aim to be fully compatible with CA-T*ols (which was a commercial extension lib for Clipper 5.x). Whole Clipper was commercial - and what of that ? For me, CA sold it with CA-TOOLS. They were two standalone products. This doesn't mean they couldn't be sold in a bundle, but f.e. I bought my 5.3 without CA-Tools. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBMK2 problem
Hi Przemek,
Please try to use hbmk2 to compile some OLE server examples.
hbmk2 olesrv1.hbp
hbmk2: Processing local make script: hbmk.hbm
Error BASE/1066 Argument error: conditional (Quit)
Error BASE/1066 Argument error: conditional
Called from FN_EXPAND(0)
Called from HBC_PROCESSONE(0)
Called from HBMK2(0)
Called from MAIN(0)
It's caused by source=... commands.
If you change:
sources={mingw}hbolesrv-mingw.def
to
{mingw}hbolesrv-mingw.def
then it works correctly.
With such syntax the .def files are simply ignored in .hbc files,
Can you fix it?
Ops, I've found it, thank you. It was older oversight
(missed to pass obligatory parameter to FN_EXPAND()),
and only affected *nix builds.
BTW. If you decided to split olesrv?.hbp files then I suggest to move
-hbdynvm to hbolesrv.hbc hbolesrv.c code is designed for inproc DLLs
only.
Target mode selection is not supported in .hbc file,
because I think it could easily make things too
confusing. It looks cleaner to select mode form a .hbp
file, so that it's easy to see what will happen.
Let's see how OLE server creation will evolve and
maybe we can further simplify some things.
Another thing I noticed is that I cannot build
watcom servers, not clients. For servers it
complains about 'Error! E2030: file clib3s.lib(cstrtwwt): multiple starting
addresses found',
for clients there are unresolved symbol, even
if I comment the special -cflag in .hbp.
I think watcom should truly be fixed by switching
to default callconv on the Harbour level, though
in this case for win/watcom builds all HB_EXPORT
declarations need have a __cdecl modifier added
between return type and function name. And this is
currently not possible without creating a new scheme
for public C function declaration (at least I could
not find a painless solution).
I think also that hbolesrv.hbc should contain also libs=hbwin so user
can easy use it to create his own inproc DLLs.
You're right, I've added it.
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error with bcc582
Hi Rossine, I suggest to use hbmk2 to build hbcomm and also your app, and it should link properly. Viktor On 2010 May 26, at 22:35, Rossine wrote: Hi Enrico, This is my c:\bcc582\bin\bcc32.cfg [CFG] -Ic:\bcc582\include;c:\bcc582\include\dinkumware;c:\harbour\include -Lc:\bcc582\lib;c:\harbour\lib [/CFG] I changed this file and recompiled my application but the error continues. I will generate binaries harbour again with these new settings to see if it works. Best Regards, Rossine. -- View this message in context: http://old.nabble.com/Error-with-bcc582-tp28685607p28686008.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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF bug tracker#3007590: Unwanted ANSI escape sequences in output
Hi Chen, The following was submitted to the Harbour SF bug tracker: http://sourceforge.net/tracker/?func=detailatid=100681aid=3007590group_id=681 Anonymous wrote: When I compile a simple Hello world program with the hbmk2 compiler, the output always includes various ANSI escape sequences, and there appears to be no way to turn this off for a simple console application. This creates a serious problem when using the compiled binaries (which I'm using on NetBSD 5) for CGI output within Apache HTTPd v2.x. I stumbled across hbmk which resolves the problem for the exact same code, but I would prefer to use the newer if possible (am I correct to assume that hbmk2 is newer?). This is not the expected behaviour of the compiled binaries. Probably he should use -gtcgi option. 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:[14611] trunk/harbour
Hi, + contrib/hbqt/hbqt.h + Added: constants hbqt_par_Qsci* ; TODO make them local. This is serious modularization fault, even for an initial upload. Pls fix it. + Initial upload of wrappers for QScintilla. To generate the sources auto you need to stay in hbqt/hbqscintilla and issue ../generator/hbqtgen. HB_WITH_QSCINTILLA and HB_WITH_QT need be properly defined. I am still finding where to host modified QScintilla, any tips ? Are you sure you need to modify this external lib to make it work with HBQT? My suggestion is to keep modifications to barest minimum, subclass instead, include Harbour specific stuff (like lexer) inside the wrapper lib, and submit any fixes to author, until he applies them (IF he applies them) workaround your wrapper code to work with plain vanilla unfixed QSCINTILLA code. This way everyone can get the QSCINTILLA component from its original, official source, just like they do for all other 3rd party components. This method scales much better than if you start maintaining a 3rd party library source and users have no other choice than relying on you (and only you) to get those sources in usable form. They also rely on you to get updates. This is essentially a QSCINTILLA _fork_ as of current state. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Question regardin the good hbide
-lhbpcre -lhbzlib -Wl,--end-group -ocurd.exe -LC:/HARBOUR/lib/win/mingw -ocurd.exe Note: ( which you miss time and again ) in Flags tab provide full path as -o_path_to_exe_plus_exename_without_extension_ How is possible that executable is detected but non found??? Hope it will be clear now. Instead of replying what I asked you to verify, you posted another query which I repled in first messages, go through all them. Why you do not understand the basics ? Something is definitely wrong here in HBIDE, since it's abnormal to require users to use absolute dirs just to make HBIDE launching feature work. Pls read my other mail. It's possible that it's wrong in other ways, but for sure HBIDE should try harder to be sync with hbmk2 and it's output filenames. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbQT - QScintilla - First Impression
I have to modify some sources of QScintilla itself, bugs and warnings, both. I am still at a loss should I proceed further in this direction or not. So far I kept it on experimental boundaries. You should publish these changes and fixes upstream to QScintilla author. There is little point for any Harbour hosted tools to rely on specially patched 3rd party components, so in order to integrate, this is crucial. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Question regardin the good hbide
I agree. Here is my argument: hbMK2 has filters parsing at -o level which I cannot manage. I have requested you many times to give a proper token to output name but you have always deferred it. So what is wrong if I provide an option at -o level or provide a slot as a field? You have the final output name parsed from hbmk2 output so you don't need any of those, neither parsing -o option or maintain you own copy of it (which will most probably not emulate -o behavior properly). I will retuen to this point a bit later to rework the detection logic. Why do you think it's me who should solve this problem for you? You pass me back this all the time, while you never have invested any effort to even understand or test this problem. You stay in the folder where executable is, hbIDE do not. Just provide a token with full path, that's it. No, you have to complete the non-absolute path to a relative one using current dir as a base, if your proprietary launching solution is unable to use current dir of caller application. Get back to me if these options failed. 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:[14569] trunk/harbour
2010-05-24 19:53 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
* contrib/sddoci/sddoci.c
! Attempting to fix wrong numeric size for plain 'NUMERIC'
(without size) type. I'm guessing so I'd appreciate if
someone could dive into this more deeply.
Still wrong in expressions. I see :
7.OB_PRZYPIS N : 12 -0.00
8.OB_WPLATY N : 22 -153
But without zeros after the decimal point.
Try :
CREATE TABLE test_dec
(
PI NUMBER
)
insert into test_dec (pi) values (3.1415926536)
commit
select * from test_dec
and from app in Harbour :
// 1. ODBC
if ( connect := RDDINFO( 1001, { ODBC, ~~ }, 'SQLMIX' )) != 0
DBUSEAREA( .T., 'SQLMIX', select pi from test_dec, test_dec)
? pi // 3 via ODBC always wrong
// 2. OCILIB
if ( connect := RDDINFO( 1001, { OCILIB, ---, --- }, 'SQLMIX' )) != 0
DBUSEAREA( .T., 'SQLMIX', select pi from test_dec, test_dec)
? pi // 3.1415926536 , hurra
Test_dec-( dbCloseArea())
DBUSEAREA( .T., 'SQLMIX', select pi+0 pi from test_dec, test_dec1)
? pi // 3 :(
The only that can be done is forcing decimals
for all numeric fields.
I cannot help.
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] vise the return of the functions: TimeToSec and SecToTime...
Hi, Maurulio, Sorry, but that has to do with the Clipper 5.2 Harbour? I'm referring to the functions and TimeToSec SecToTime the Harbour, has nothing to do with Clipper. Harbour has everything to do with Clipper, since we aim to be fully compatible with it. In case of HBCT we aim to be fully compatible with CA-T*ols (which was a commercial extension lib for Clipper 5.x). The functions you reported are part of HBCT, so they should be compatible with CA-T*ols. Maurilio reported the CA-T*ols results. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Contrib´s not build with 14457
Hi,
The part I need is missing from the posted .log fragments.
It's at the end.
Viktor
On 2010 May 25, at 16:00, Rossine wrote:
Hello Viktor,
Use 'clean install' as documented (with lowercase).
OK. I use: \harbour\bin\mingw32-make.exe clean install
Now fbclient.lib is created, but ace32.lib and freeimage.lib. are not
created in c:\hrb_bcc\lib
This is my sets for harbour:
[SETS]
set HB_BUILD_DLL=yes
set HB_DIR_IMPLIB=yes
set HB_BUILD_IMPLIB=yes
set HB_BUILD_LOG=yes
set HB_CONTRIB_ADDONS=yes
set HB_BUILD_UNICODE=no
rem set HB_BUILD_UNICODE=yes
set HB_WITH_PGSQL=C:\pgsql84\include
set HB_WITH_ADS=C:\ads81
set HB_WITH_QT=C:\Qt\qt\include
set HB_WITH_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1\include
set HB_WITH_FREEIMAGE=C:\FreeImg\3131\Dist
set HB_DIR_PGSQL=C:\pgsql84
set HB_DIR_ADS=C:\ads81
rem set HB_DIR_QT=C:\Qt\qt\include
set HB_DIR_QT=C:\Qt\qt
set HB_DIR_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1
set HB_DIR_FREEIMAGE=C:\FreeImg\3131\Dist
set HB_INC_PGSQL=C:\pgsql84\include
set HB_INC_ADS=C:\ads81
set HB_INC_QT=C:\Qt\qt\include
set HB_INC_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1\include
set HB_INC_FREEIMAGE=C:\FreeImg\3131\Dist
set HB_LEX=SIMPLEX
set HB_USER_CFLAGS=-DHB_GC_AUTO -DHB_FM_STATISTIC
set HB_PATH=c:\hrb_bcc
set HB_INSTALL_PREFIX=%HB_PATH%
set HB_BIN_INSTALL=%HB_PATH%\bin
set HB_LIB_INSTALL=%HB_PATH%\lib
set HB_INC_INSTALL=%HB_PATH%\include
set HB_DOC_INSTALL=%HB_PATH%\doc
set HB_DYN_INSTALL=%HB_PATH%\dyn
set HB_COMPILER=bcc
set BCC_DIR=c:\bcc55
[/SETS]
This is my LOG:
[LOG]
C:\harbour-#BCC#\harbour\bin\mingw32-make.exe clean install
! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: C:/harbour/bin/mingw32-make 3.81 sh.exe clean install
! HB_USER_CFLAGS: -DHB_GC_AUTO -DHB_FM_STATISTIC
! HB_INSTALL_PREFIX: c:\hrb_bcc
! HB_BIN_INSTALL: c:\hrb_bcc\bin
! HB_LIB_INSTALL: c:\hrb_bcc\lib
! HB_DYN_INSTALL: c:\hrb_bcc\dyn
! HB_INC_INSTALL: c:\hrb_bcc\include
! HB_DOC_INSTALL: c:\hrb_bcc\doc
! HB_BUILD_DLL: yes
! HB_BUILD_IMPLIB: yes
! HB_BUILD_UNICODE: no
! HB_CONTRIB_ADDONS: yes
! HB_HOST_PLAT: win (x86) HB_SHELL: nt
! HB_PLATFORM: win (x86) (autodetected)
! HB_COMPILER: bcc
! Component: 'zlib' found in C:/harbour/external/zlib (local)
! Component: 'pcre' found in C:/harbour/external/pcre (local)
! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on win platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not found. Configure with HB_WITH_CURSES.
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on win platform
! 'gtcrs' library skipped (component not found)
! 'gtdos' library skipped (platform not supported)
! 'gtos2' library skipped (platform not supported)
! 'gtsln' library skipped (component not found)
! 'gttrm' library skipped (platform or compiler not supported)
! 'gtxwc' library skipped (component not found)
! 'gtalleg' library skipped ('allegro' not found. Configure with
HB_WITH_ALLEGRO
.)
! 'hbcairo' library skipped ('cairo' not found. Configure with
HB_WITH_CAIRO.)
! 'hbcups' library skipped ('cups' not found. Configure with HB_WITH_CUPS.)
! 'hbcurl' library skipped ('libcurl' not found. Configure with
HB_WITH_CURL.)
! 'hbgd' library skipped ('libgd' not found. Configure with HB_WITH_GD.)
! 'hbmysql' library skipped ('mysql' not found. Configure with
HB_WITH_MYSQL.)
! 'hbqt' library skipped ('qt' not supported with bcc compiler)
! 'hbssl' library skipped (component not found)
! 'sddmy' library skipped ('mysql' not found. Configure with HB_WITH_MYSQL.)
! 'sddoci' library skipped ('ocilib' not found. Configure with
HB_WITH_OCILIB.)
! 'hbxbp' library skipped (compiler not supported)
1 arquivo(s) copiado(s).
1 arquivo(s) copiado(s).
1 arquivo(s) copiado(s).
...
[/LOG]
This is the contents of my C:\ads81
[ADS]
Pasta de C:\ads81
..DIR 13/05/2009 16:31
. DIR 13/05/2009 16:31
ace32dll995.376 08/01/2007 08:10
axcws32 dll167.936 08/01/2007 08:10
ansi chr 24.128 08/01/2007 08:10
adsloc32 dll 1.241.088 08/01/2007 08:10
extend chr 28.348 08/01/2007 08:10
adslocal cfg 2.370 19/03/2007 15:41
ace h 219.472 17/08/2007 17:42
ads ch 13.894 04/06/2008 12:07
rddads h 11.360 04/06/2008 12:07
adsext~1 ch 6.576 04/07/2008 19:56
unixut~1 h 96 06/04/2009 11:53
unins000 exe686.111 11/04/2009 09:20
unins000 dat 1.121 11/04/2009 09:20
ace32lib 55.808 13/05/2009 16:31
[\ADS]
Best Regards,
Rossine.
--
View this message in context:
Re: [Harbour] Contrib´s not build with 1445 7
Rossine,
Are you using MingW or BCC?
MingW (TDM) is the recomended one. BCC is not as good according to tests
made by the developers.
Seems to me you are mixing it and you also have too many enviroment
variables set.
As I understand the instructions in INSTALL, it should be simpler. Did you
read it?
If you are using MingW it will not generate *.lib files but *.a files
instead.
I recomend you to re-read the INSTALL. There you will find clear
instructions how to build the libs.
I hope it will help you.
I can confirm that most of the envvars are not needed.
The problem here was most probably a recent typo in hbmk2,
although without seeing relevant part of log output (the
RTE should be right there!), I can only guess.
Looks like it's a cry into the void to try to make these
envvars dropped, but I will do this one more final time:
So that huge amount of envvars could be replaced by these
without losing functionality inside Harbour build:
--
set HB_BUILD_IMPLIB=yes
set HB_BUILD_UNICODE=no
set HB_WITH_PGSQL=C:\pgsql84\include
set HB_WITH_ADS=C:\ads81
set HB_WITH_QT=C:\Qt\qt\include
set HB_WITH_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1\include
set HB_WITH_FREEIMAGE=C:\FreeImg\3131\Dist
set HB_USER_CFLAGS=-DHB_GC_AUTO -DHB_FM_STATISTIC
set HB_INSTALL_PREFIX=c:\hrb_bcc
rem QUESTION: Is this really intended?:
set HB_DYN_INSTALL=%HB_INSTALL_PREFIX%\dyn
set PATH=c:\bcc55;%PATH%
win-make clean install
--
Viktor
- Original Message - From: Rossine qii...@ig.com.br
To: harbour@harbour-project.org
Sent: Tuesday, 25 de May de 2010 11:00
Subject: Re: [Harbour] Contrib´s not build with 14457
Hello Viktor,
Use 'clean install' as documented (with lowercase).
OK. I use: \harbour\bin\mingw32-make.exe clean install
Now fbclient.lib is created, but ace32.lib and freeimage.lib. are not
created in c:\hrb_bcc\lib
This is my sets for harbour:
[SETS]
set HB_BUILD_DLL=yes
set HB_DIR_IMPLIB=yes
set HB_BUILD_IMPLIB=yes
set HB_BUILD_LOG=yes
set HB_CONTRIB_ADDONS=yes
set HB_BUILD_UNICODE=no
rem set HB_BUILD_UNICODE=yes
set HB_WITH_PGSQL=C:\pgsql84\include
set HB_WITH_ADS=C:\ads81
set HB_WITH_QT=C:\Qt\qt\include
set HB_WITH_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1\include
set HB_WITH_FREEIMAGE=C:\FreeImg\3131\Dist
set HB_DIR_PGSQL=C:\pgsql84
set HB_DIR_ADS=C:\ads81
rem set HB_DIR_QT=C:\Qt\qt\include
set HB_DIR_QT=C:\Qt\qt
set HB_DIR_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1
set HB_DIR_FREEIMAGE=C:\FreeImg\3131\Dist
set HB_INC_PGSQL=C:\pgsql84\include
set HB_INC_ADS=C:\ads81
set HB_INC_QT=C:\Qt\qt\include
set HB_INC_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1\include
set HB_INC_FREEIMAGE=C:\FreeImg\3131\Dist
set HB_LEX=SIMPLEX
set HB_USER_CFLAGS=-DHB_GC_AUTO -DHB_FM_STATISTIC
set HB_PATH=c:\hrb_bcc
set HB_INSTALL_PREFIX=%HB_PATH%
set HB_BIN_INSTALL=%HB_PATH%\bin
set HB_LIB_INSTALL=%HB_PATH%\lib
set HB_INC_INSTALL=%HB_PATH%\include
set HB_DOC_INSTALL=%HB_PATH%\doc
set HB_DYN_INSTALL=%HB_PATH%\dyn
set HB_COMPILER=bcc
set BCC_DIR=c:\bcc55
[/SETS]
This is my LOG:
[LOG]
C:\harbour-#BCC#\harbour\bin\mingw32-make.exe clean install
! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: C:/harbour/bin/mingw32-make 3.81 sh.exe clean install
! HB_USER_CFLAGS: -DHB_GC_AUTO -DHB_FM_STATISTIC
! HB_INSTALL_PREFIX: c:\hrb_bcc
! HB_BIN_INSTALL: c:\hrb_bcc\bin
! HB_LIB_INSTALL: c:\hrb_bcc\lib
! HB_DYN_INSTALL: c:\hrb_bcc\dyn
! HB_INC_INSTALL: c:\hrb_bcc\include
! HB_DOC_INSTALL: c:\hrb_bcc\doc
! HB_BUILD_DLL: yes
! HB_BUILD_IMPLIB: yes
! HB_BUILD_UNICODE: no
! HB_CONTRIB_ADDONS: yes
! HB_HOST_PLAT: win (x86) HB_SHELL: nt
! HB_PLATFORM: win (x86) (autodetected)
! HB_COMPILER: bcc
! Component: 'zlib' found in C:/harbour/external/zlib (local)
! Component: 'pcre' found in C:/harbour/external/pcre (local)
! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on win platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not found. Configure with HB_WITH_CURSES.
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on win platform
! 'gtcrs' library skipped (component not found)
! 'gtdos' library skipped (platform not supported)
! 'gtos2' library skipped (platform not supported)
! 'gtsln' library skipped (component not found)
! 'gttrm' library skipped (platform or compiler not supported)
! 'gtxwc' library skipped (component not found)
! 'gtalleg' library skipped ('allegro' not found. Configure with
HB_WITH_ALLEGRO
.)
! 'hbcairo' library skipped ('cairo' not found. Configure with
HB_WITH_CAIRO.)
! 'hbcups' library skipped ('cups' not found. Configure with HB_WITH_CUPS.)
! 'hbcurl' library skipped ('libcurl' not found. Configure with
HB_WITH_CURL.)
! 'hbgd' library skipped ('libgd' not found. Configure with HB_WITH_GD.)
!
Re: [Harbour] SF.net SVN: harbour-project:[14579] trunk/harbour
Hi Przemek, That sounds great, may I ask for a simple example which show the usefulness of this feature over regular hashes? Viktor On 2010 May 25, at 13:20, dru...@users.sourceforge.net wrote: Revision: 14579 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14579view=rev Author: druzus Date: 2010-05-25 11:20:34 + (Tue, 25 May 2010) Log Message: --- 2010-05-25 13:20 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbapi.h * harbour/src/vm/hashes.c * harbour/src/vm/hashfunc.c + added support for keeping strict assign order in hash arrays. It's enabled optionally by setting HB_HASH_KEEPORDER hash array flag. It gives the same functionality as associative arrays in xHarbour (enabled by HSETAACOMPATIBILITY()) but this implementation is internally completely different. It does not introduce linear scan in add operation so enabling it should not reduce the performance in this operation. It can even improve it on some hardware reducing number of memory bytes which have to be moved. Only delete operation will force linear index scan. The most important in this implementation is that it does not need any additional functions like HAA*() in xHarbour. Just simply all existing functions operating on position indexes like HB_HPOS(), HB_HKEYAT(), HB_HVALUEAT(), HB_HPAIRAT(), HB_HDELAT(), HB_HSCAN() use as index natural order in which items were added to hash array. Also HB_HKEYS(), HB_HVALUES() and FOR EACH iterations respect it. + added new PRG functions HB_HKEEPORDER( hValue [, lNewSetting ] ) - lPrevSetting HB_HSETORDER( hValue [, lNewSetting ] ) - hValue which cam be used to enable/disable strict order in hash array. Enabling strict order for non empty hash arrays accept the order created after sorting existing item not the original assign order. Disabling strict order for non empty hash arrays may change the items order. ; TODO: add translation for xHarbour's HAA*() functions to hbcompat.ch and/or xhb library. * harbour/contrib/hbnetio/netiocli.c * harbour/contrib/hbnetio/netiosrv.c % reenabled TCP_NODELAY on client and server side I had to be really tired when I was making tests and I mixed hb_socketSetNoDelay() with hb_socketSetBlockingIO(). Thanks to Aleksander Czajczynski who noticed the delay in his tests. * harbour/contrib/hbwin/olecore.c * minor cleanup Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbnetio/netiocli.c trunk/harbour/contrib/hbnetio/netiosrv.c trunk/harbour/contrib/hbwin/olecore.c trunk/harbour/include/hbapi.h trunk/harbour/src/vm/hashes.c trunk/harbour/src/vm/hashfunc.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 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:[14586] trunk/harbour
So f.e. this can be done:
--- plugin.prg
FUNCTION hbmk2_plugin_show_target( hbmk2 )
SWITCH hbmk2[ cSTATE ]
CASE post_all
IF hbmk2[ nErrorLevel ] == 0
hbmk2_OutStd( hbmk2, @@ TARGET: + hbmk2[ cTARGETTYPE ] + : +
hbmk2[ cTARGETNAME ] )
hbmk2_OutStd( hbmk2, @@ TARGET (ABSOLUTE): +
hbmk2_PathMakeAbsolute( hbmk2[ cTARGETNAME ], hbmk2_Macro( hbmk2,
${hb_curdir} ) ) )
ENDIF
EXIT
ENDSWITCH
RETURN
---
(in above example there is nothing which
is really special hbmk2 knowledge regarding
the absolute path creation, but it shows the
capabilities nevertheless)
Viktor
On 2010 May 25, at 19:09, vszak...@users.sourceforge.net wrote:
Revision: 14586
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14586view=rev
Author: vszakats
Date: 2010-05-25 17:09:12 + (Tue, 25 May 2010)
Log Message:
---
2010-05-25 19:08 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
* utils/hbmk2/hbmk2.prg
+ Extended plugin API:
- New macro expansion function:
hbmk2_Macro( ctx, str )
- New host variables:
cTARGETTYPE, cTARGETNAME, lDEBUG, lMAP, lSTRIP, lINFO,
lBEEP, lRUN, nErrorLevel
* include/hbextern.ch
+ Added two recently added functions.
* package/winuni/RELNOTES
* Update one version number.
Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/include/hbextern.ch
trunk/harbour/package/winuni/RELNOTES
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 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:[14579] trunk/harbour
Hi Przemek,
This code illustrates the difference between regular and
associative hash arrays:
proc main()
[...]
return
As you can see executing it the order of items in associative array
is strictly defined and it's the same as the order in which new item
were added. It means that you have two strictly defined indexes. One
which can be used with [] operator and any hash item keys and the
second numeric only index. It's usable in many different places.
This is the part of ChangeLog message I created for Harbour OLE
servers. It's very nice example of practical usage.
Thanks a lot, I got it now, so f.e. it's useful to have a data
structure (like 'LOCAL hbmk' in hbmk2) with both numeric and
string indexing, where numeric has the speed while string based
has the advantage that it can be accessed without messing
with headers, or most importantly to guarantee exact
positions (f.e. external access). I faced partially similar
problem in hbmk2 plugin system.
hAction is optional parameter with hash array containing messages
and instance variables used by OLE server. The keys in hash array
are strings with message names and values are actions. Codeblock
and symbol items means that given message is a method call and
any other value means that it's variable.
By default the same hash array is shared between all objects
created by registered server. It's important when hash array
contains values which are neither codeblock nor symbol items
so they are not used as method but rather as instance variables
because such instance variables are shared between OLE objects.
Setting 4-th parameter lHashClone to .T. causes that each
objects receives it's own copy of hAction item so instance
variables inside hash array are also local to OLE object.
Alternatively programmer can use bAction or sAction to create
seprate copy of hash array for each object, i.e.:
bAction := {|| hb_hClone( hValue ) }
When hash array contains symbol item (@funcName()) then when it's
executed by OLE object message it's possible to access the hash
array bound with given OLE object using QSelf() function. It maybe
useful if hash array contains instance variables and programmer
wants to access them.
Please remember that using hash array which was initialized to keep
original assign order by HB_HKEEPORDER( hAction, .T. ) before
adding its items you can define strict message numbers (DISPIDs), i.e.:
hAction := {=}
HB_HKEEPORDER( hAction, .T. )
hAction[ OPEN ] := @myole_open() // DISPID=1
hAction[ CLOSE ] := @myole_close()// DISPID=2
hAction[ SAVE ] := @myole_save() // DISPID=3
hAction[ LOAD ] := @myole_load() // DISPID=4
hAction[ PRINT ] := @myole_print()// DISPID=5
(see example in olesrv2.prg)
Great stuff.
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:[14589] trunk/harbour
Hi Pritpal (again), Now, if you want to make it absolutely complicated and use a plugin for this purpose, you should _generate_ the plugin code to a temporary file and pass that to hbmk2. Or you can put it into 'resources' dir if you don't mind being less elegant. Otherwise, after this change of yours, suddenly HBIDE needs to be distributed with its own source code, otherwise it won't work. If you look a little bit further, probably you could also easily complete the output name with CURDIR() and CURDRIVE() _inside HBIDE code_ and just use that. There is no magic done in this plugin as I told. If it doesn't work, it means you DO CHANGE the current directory, even if you don't know about it, so in this case you must explore the QT launching stuff to see how to disable it. Here's the proof in ideprojmanager.prg @ line 1323: ::oProcess:workingPath := hbide_pathToOSPath( ::oProject:location ) Where you DO change current dir for subprocess. I'm not sure why you do it though, for hbmk2 it's not needed. Anyway to fix the output file problem, all you need to do is to make the detected output path relative to above directory: Add this line to ideprojmanager.prg @ line 1397: cExe := hbide_PathProc( cExe, hbide_pathToOSPath( ::oProject:location ) ) So you can delete the whole hbmk2 plugin hack from HBIDE. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about hbmk2 and icons
Hi, I use Harbour for Win32. I was wondering if hbmk2 allows (or can allow someday) support for multiple icons? We're leaning towards having two icons in our .EXE builds. If this was ever supported... I am not sure what the file delimiter would be. Any thoughts? '-icon' option is meant to provide an _easy_ way to add an application icon, and in majority of cases this can be solved with one icon file (please note that you can combine multiple icons with different resolutions into one .ico file and it should be accepted and utilized by Windows). If you need something special, you can always add any number of icons or any other resources via .rc files, which will be automatically built into the target executable 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: SF.net SVN: harbour-project:[14589] trunk/harbour
If it doesn't work, it means you DO CHANGE the current directory, even if you don't know about it, so in this case you must explore the QT launching stuff to see how to disable it. Let me explain a bit how hbIDE forks process to Qt and why I cannot take this approach. Calling hbMK2: is done in a attached Qt process. The called process is started in project location. hbIDE process does not change its directory. Called process creates the executable and returns. And here is the problem. Called process (hbmk2) is started in project location, so you DO alter current dir for the subprocess, but you didn't correct detected output name accordingly. curdir for hbmk2 != curdir for HBIDE That's why I told a few e-mails back to either not alter current dir for subprocess, or correct the output name. You need to do the latter anyway, the only question is what is the base directory; if you alter it, it's the dir which you set as current dir, if you don't it's CURDIR(). Executing target: executable is detected by whatever means I was/am adopting. A new detached Qt process is initiated which fires the executable and stays in the Start in folder, if provided. This should be irrelevant once you have an absolute path pointing to the target executable. The point is to have an absolute path formed based on a base dir and the output name detected (which can be relative or absolute). Though based on your description, it's unnecessary to change directory when launching hbmk2. I left it, but I still don't understand why you do it. It just adds complexity without any benefit. hbmk2 doesn't require any such tricks to make it work. I'm very sad you only hear the wrong solutions from my mails and I'm a little bit afraid to tell anything, since I'm not happy to help creating bad solutions. Me too, but believe me I could never find a satisfactory way to detect. Every method went weired at one stage or the other. So do not be so rude, please. Sorry if I was. Pls verify my recent commit, wether it seems to solve the problem in your view and tests. Viktor ___ 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:[14590] trunk/harbour
--- 2010-05-25 22:28 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbide/ideprojmanager.prg ! Fixed output directory issue without the need for an hbmk2 plugin. HBIDE was changing current dir when calling hbmk2, so the detected output filename needs to be rebased from that directory. Yep, this solves this issue. And I am amazed how simple it is. One note though: HBIDE was changing current dir No, hbIDE does not change directory, the process is started in project location and it is terminated after build. At time of execution another process is started without changing hbIDE's location. So it changes current dir in context of the subprocess it calls compared to the one it uses on its own. We can juggle the words, but you do change current dir throughout HBIDE, since hbmk2 isn't started in the same dir as is HBIDE. Anyhow it's not relevant at the end since you have to rebase path anyway, because you change current dir also for running the executable. BTW changing curdir for hbmk2 could be avoided and replaced by '-oproject_dir/' hbmk2 option. Viktor ___ 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:[14589] trunk/harbour
Though based on your description, it's unnecessary to change directory when launching hbmk2. I left it, but I still don't understand why you do it. It just adds complexity without any benefit. hbmk2 doesn't require any such tricks to make it work. hbIDE process does not change directory. Process responsible for calling hbMK2 stays in the folder where project is located. So it does, though in Qt way. For Harbour, curdir() ( in hbIDE ) shows up the folder from where hbIDE is started, always. The final effect was that hbmk2 was run in a different directory. It's irrelevant whether HBIDE changed its own curdir which hbmk2 inherited, or HBIDE configured a different dir for its own subprocess. It's sad you still cannot see the root cause which was causing error reports for several months on this list. Viktor ___ 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:[14590] trunk/harbour
this is what I am trying to convey. It depend how hbIDE is invoked. One can invoke it with desktop icon with/without Start in: field entry on Shortcut tab in Properties dialog when selection with right-click on appln icon. the other can call as: C:\MyOwnFolder\E:\harbour\contrib\hbide\hbide.exe then the curdir() if called in hbIDE will show up MyOwnFolder The actual content of CURDIR() doesn't matter in context of our discussion. The only point is to deal with it properly whatever it is. Other than that CURDIR() neutrality is a very important (and many times forgotten in DOS/Windows world) programming rule, so I hope HBIDE behaves well whatever the actual current directory is. It's also basic requirement for Mac OS X apps. So far HBIDE looks clean in this regard. hbmk2 works correctly regardless of current dir. BTW changing curdir for hbmk2 could be avoided and replaced by '-oproject_dir/' hbmk2 option. I did not know. Where .hbmk folder will be created ? At '-oproject_dir/' or where from this is called ? I knew that -o option is to place the target executable. Does it also affect the intermediatory files ? Yes. '.hbmk' dir is created in -o directory (unless manually overridden using -workdir option). In non-incremental mode all intermediate files are created in temporary directory. [ BTW -o is quite flexible, f.e. you can use both '-ohello' and '-omydir/' at the same time, the first will define the name of the target, the second the directory. Of course you can use '-omydir/hello', too, and you can also combine them in various ways. The end result is that you can configure output filename in .hbp file and output directory via separate cmdline options. ] Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbMK2 - plug_moc.prg
Hi Pritpal,
now I am looking at how to construct
moc files and include it in the project.
I need to know how should I pass params
leading to moc creation - in .hbp or on the
commandline ?
A small example will be helpful.
Here is a little .hbp sample I used for testing:
---
-hblib
-inc
-i${HB_WITH_QT}
-i${HB_WITH_QT}/QtCore
-i${HB_WITH_QT}/QtGui
-plugin=plug_moc.prg
-pi=hbqt_hbdbfmodel.h
hbqt_hbdbfmodel.cpp
---
[ Everything works the same way when issued from cmdline. ]
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:[14579] trunk/harbour
Sorry for my intromision but, where is olesrv2.prg ? On my hard drive ;) I haven't committed this code yet. Just simply I have had no time so far to make some real test in MS-Windows. I only tested the base version few days ago but I made many other modifications later and they are not tested at all, i.e. olesrv2.prg was also not tested. If MS-Windows developers can make such tests then I can commit this code soon. I'm sure they can :) 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:[14593] trunk/harbour
Hi Przemek,
It's great. I hope we can nail the watcom tricks and .def file
chaos in the future.
I've successfully tested olesrv2 with oletst2.
Then I tried to access olesrv2 from jscript/vbscript. Since
I'm using Win7 x64, first I built olesrv2 with msvc64,
and registered it, which went OK. msvc64 compilation showed
these warnings:
..\hbolesrv.def : warning LNK4104: export of symbol 'DllRegisterServer'
should be PRIVATE
..\hbolesrv.def : warning LNK4104: export of symbol 'DllUnregisterServer'
should be PRIVATE
With these scripts:
--- tst2.jscript
{
var tst2 = new ActiveXObject( MyOleTimeServer );
WScript.stdout.WriteLine( tst2.TIME() );
}
--- tst2.vbscript
Dim tst2 : Set tst2 = WScript.CreateObject(MyOleTimeServer)
WScript.stdout.WriteLine tst2.TIME()
---
Both worked when run from 'cscript'. They also worked with
(default) 'wscript' when using GUI output function:
--- tst2.vbs
Dim tst2 : Set tst2 = WScript.CreateObject(MyOleTimeServer)
WScript.CreateObject(Wscript.Shell).Popup tst2.TIME()
---
The only thing I noticed is that TIME() is case-sensitive,
so probably a HB_HSETCASEMATCH() call would be needed in sample
server.
Great job!
Viktor
On 2010 May 26, at 00:04, dru...@users.sourceforge.net wrote:
Revision: 14593
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14593view=rev
Author: druzus
Date: 2010-05-25 22:04:04 + (Tue, 25 May 2010)
Log Message:
---
2010-05-26 00:03 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbwin/Makefile
+ harbour/contrib/hbwin/hbolesrv.c
+ added inproc OLE server implementation. It allows to create OLE/ACTIVEX
COM server in Harbour. Such OLE server allows can be used by programs
written in any languages supporting OLE automation (also in other
Harbour applications)
User ole server code should be linked as DLL which later can be
register in MS-Windows by regsvr32.exe program, i.e.:
regsvr32 myolesrv.dll
The OLE server code should contain DLLMAIN() PRG function which
is executed just after loading OLE inproc DLL server as server from
other application and also by regsrv32.exe during registration and
unregistration procedure. It has to initialize at least OLE server
ID and name usinf WIN_OleServerInit().
+ added new PRG function which intitialize OLE server:
WIN_OleServerInit( cClassID, cServerName, ;
[ hAction | oAction | bAction | sAction ], ;
[ lHashClone | lAcceptAll ] ) - lServerActive
cClassID is registered OLE server class GUID
cServerName is OLE server class name
hAction is optional parameter with hash array containing messages
and instance variables used by OLE server. The keys in hash array
are strings with message names and values are actions. Codeblock
and symbol items means that given message is a method call and
any other value means that it's variable.
By default the same hash array is shared between all objects
created by registered server. It's important when hash array
contains values which are neither codeblock nor symbol items
so they are not used as method but rather as instance variables
because such instance variables are shared between OLE objects.
Setting 4-th parameter lHashClone to .T. causes that each
objects receives it's own copy of hAction item so instance
variables inside hash array are also local to OLE object.
Alternatively programmer can use bAction or sAction to create
seprate copy of hash array for each object, i.e.:
bAction := {|| hb_hClone( hValue ) }
When hash array contains symbol item (@funcName()) then when it's
executed by OLE object message it's possible to access the hash
array bound with given OLE object using QSelf() function. It maybe
useful if hash array contains instance variables and programmer
wants to access them.
Please remember that using hash array which was initialized to keep
original assign order by HB_HKEEPORDER( hAction, .T. ) before
adding its items you can define strict message numbers (DISPIDs), i.e.:
hAction := {=}
HB_HKEEPORDER( hAction, .T. )
hAction[ OPEN ] := @myole_open() // DISPID=1
hAction[ CLOSE ] := @myole_close()// DISPID=2
hAction[ SAVE ] := @myole_save() // DISPID=3
hAction[ LOAD ] := @myole_load() // DISPID=4
hAction[ PRINT ] := @myole_print()// DISPID=5
(see example in olesrv2.prg)
oAction is optional parameter with Harbour object which is used
as base for all newly created OLE objects. All messages (method and
instance variables) supported explicitly by oAction object (except
ONERROR message redirecting) are inherited by OLE objects. Each
newly created OLE object uses the
Re: [Harbour] SF.net SVN: harbour-project:[14591] trunk/harbour
Hi,
2010-05-25 23:40 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
+ config/bsd/clang.mk
+ Base implementation of bsd/clang target.
Based on patch by Tamas Tevesz with modifications:
- deleted HB_DYN_COPT
- replaced dynamic lib rules with bsd/gcc.mk.
(both fully untested)
almost there. it seems that $hb_install_prefix/lib*.so -
$hb_install_prefix/harbour/ links are not being made, for
postinst.sh appears to be not doing a thing.
is it possible that in some shape, way or form something along these
lines is needed?
It's very much possible. The thing is that these
remaining bash scripts are on the far side of my
attention.
I was exploring to move any link-creation activities
to postinst.prg, but didn't get there yet. I'm also
hoping for some help here.
Index: bin/postinst.sh
===
--- bin/postinst.sh (revision 14593)
+++ bin/postinst.sh (working copy)
@@ -270,7 +270,8 @@
[ $HB_COMPILER = djgpp ] || \
[ $HB_COMPILER = icc ] || \
[ $HB_COMPILER = sunpro ] || \
- [ $HB_COMPILER = open64 ]
+ [ $HB_COMPILER = open64 ] || \
+ [ $HB_COMPILER = clang ]
then
if [ -n ${HB_TOOLS_PREF} ]; then
hb_mkdyn=${HB_INST_PKGPREF}${HB_BIN_INSTALL}/${HB_TOOLS_PREF}-mkdyn
this seems to have fixed this remaining issue here, and hbmk2 is quite
happily churning out clang-compiled binaries.
Great, thanks. I will apply this change in a next
commit.
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBMK2 with -rebuild/-clean
Hi Mario, I tried the -rebuild parameter (hbmk2 proj1.hbp -rebuild) but I got the following error: = Error BASE/1066 Argument error: conditional (Quit) Error BASE/1066 Argument error: conditional Called from HBMK2(0) Called from MAIN(0) = I got the same error under Ubuntu 10.4 and Win7/BCC58. Thanks, I've fixed it. Also, from my existing project using xMate, it compiles successfully but immediately GPFs when executed. It's impossible to tell without full trace (and maybe .hbp) information. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HB in MT mode + testsvc.prg = service don't start.
Hi Vailton, I was making some tests with testsvc.prg (Harbour SVN 5.5.1 + BCC) and discovered some problems because it does not execute correctly when compiled with -mt in hbmk2. Apparently the problem comes in win_serviceStart () but I could not detect why the service does not run. Using log files, I discovered that the problem occurs in function hb_vmRequestReenter () and not in function win_serviceStart () as I suspected initially. I'm still doing some tests to see what might be influencing this behavior, but so far not encountered any problem. So does it work now? Or does it work sometimes and sometimes not? Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HB in MT mode + testsvc.prg = service don't start.
Hi Vailton, So does it work now? Or does it work sometimes and sometimes not? The service do not start... It installs, uninstalls, but does not start.But based on comments from Przemysław I have an idea to tease this problem: i'll make an application to run as service and launch another application with features powered bye hbnetio.. like Firebird Guardian - this should help me in need. For this purpose it's probably simpler to use an already existing utility such as SRVANY. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HB in MT mode + testsvc.prg = service don't start.
The service do not start... It installs, uninstalls, but does not start.But based on comments from Przemysław I have an idea to tease this problem: i'll make an application to run as service and launch another application with features powered bye hbnetio.. like Firebird Guardian - this should help me in need. For this purpose it's probably simpler to use an already existing utility such as SRVANY. Thanks for the tip and I really understand what is not feasible in many cases reinventing the wheel, but my intention is due to the fact that we have an event for developers Harbour+FiveWin here in Brazil in November and I would like to demonstrate the possibilities that these new tools in Harbour has offered us, so my intention is also to release all these demo applications with full source in prg format. My intention is to highlight how easy it is to create service applications and application servers with Harbour, what is a little different from traditional applications in the world Clipper, which many here are accustomed. Oh okay, nice, and I understand. In this case yes, SRVANY can now be easily rewritten using .prg code + hbwin. [ Maybe one day we will have a portable 'service API' in Harbour core, this is just the first step. ] Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Contrib´s not build with 14457
Hi Vicktor, My name is 'Viktor'. Updated today the harbour to release 14566 and again is not building these libs: - fbclient.lib - freeimage.lib - ace32.lib I need to change something here in order to build these libs ? I don't think so. Pls post the log output (beginning and the end where implibs are generated) 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:[14564] trunk/harbour
Intresting! Maj be used prg in hbide keyboard mapping macro script? No, this is means to add custom build capabilities to hbmk2. F.e. using a plugin you can generate code from non .prg sources, or do any sort of non-standard conversion seamlessly integrated into the hbmk2 process. Other interesting things can be implemented, f.e. uploading result to server, starting packaging process, signaling build status to build-server, etc. (some of these may need new callback event, but these are quite easy to add to the infrastructure). Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: INSTALL file - HBQTS and linux
anyway if I am compiling an opensource program I can use static version exist a way to do that in linux ? Probably it's documented somewhere, check QT website. BTW if you have an opensource software, it's probably not a problem to require QT package to be installed in order to run it. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: INSTALL file - HBQTS and linux
We have an opensource software based in HBQT , and we like to distribute it in static version this is why I asking for hbqts in linux You're asking it at wrong place. This is not a Harbour issue. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: INSTALL file - HBQTS and linux
Viktor do you not understand my question I need to create LIBHBQTS.a to compile our harbour aplication in static mode in windows we don not have problems , but in linux I do not know how to declare , location of static qt libraries and indicates to harbour to compile hbqts I'm sure all list readers already understood your original question. You even got answers. this is my question , INSTALL file don't have this information INSTALL contains information which is _relevant_ for Harbour users and that I have _accurate information_ about. None is true for what you're asking for. If you want to contribute something valuable, ask about this topic on relevant forums, and post here the results, maybe someone will care of updating INSTALL then, but as Angel already answered to you, QT static support has very low priority in Harbour. Reasons were already explained. Read them. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: INSTALL file - HBQTS and linux
Sorry viktor , I wouldn't want to say that INSTALL file have inaccurate information or like that The only think is that I first check it to not ask a question that is in this file I understand, but it's not there because I don't know it (and it's not important information for most users). I don't know how to tell you this clearly. I don't know which is relevant forum to this question if not this , where i can ask a question relevant to develop an aplicattion using HBQT ?? This question has nothing specific to HBQT or Harbour. You can use the official forums of QT as already suggested. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Contrib´s not build with 14457
Hi Rossine, Use 'clean install' as documented (with lowercase). Viktor On 2010 May 24, at 22:27, Rossine wrote: Hi Viktor, This is my log: [LOG] C:\harbour-#BCC#\harbour\bin\mingw32-make.exe CLEAN INSTALL config/global.mk:234: ! Warning: HB_BUILD_IMPLIB option works only when 'install' is requested. ! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org ! MAKE: C:/harbour/bin/mingw32-make 3.81 sh.exe CLEAN INSTALL ! HB_USER_CFLAGS: -DHB_GC_AUTO -DHB_FM_STATISTIC ! HB_INSTALL_PREFIX: c:\hrb_bcc ! HB_BIN_INSTALL: c:\hrb_bcc\bin ! HB_LIB_INSTALL: c:\hrb_bcc\lib ! HB_INC_INSTALL: c:\hrb_bcc\include ! HB_DOC_INSTALL: c:\hrb_bcc\doc ! HB_BUILD_DLL: yes ! HB_BUILD_IMPLIB: no ! HB_BUILD_UNICODE: no ! HB_CONTRIB_ADDONS: yes ! HB_HOST_PLAT: win (x86) HB_SHELL: nt ! HB_PLATFORM: win (x86) (autodetected) ! HB_COMPILER: bcc ! Component: 'zlib' found in C:/harbour/external/zlib (local) ! Component: 'pcre' found in C:/harbour/external/pcre (local) ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. ! Component: 'gpm' not supported on win platform ! Component: 'slang' not found. Configure with HB_WITH_SLANG. ! Component: 'curses' not found. Configure with HB_WITH_CURSES. ! Component: 'x11' not found. Configure with HB_WITH_X11. ! Component: 'wattcp/watt-32' not supported on win platform ! 'gtcrs' library skipped (component not found) ! 'gtdos' library skipped (platform not supported) ! 'gtos2' library skipped (platform not supported) ! 'gtsln' library skipped (component not found) ! 'gttrm' library skipped (platform or compiler not supported) ! 'gtxwc' library skipped (component not found) ... [/LOG] See this line: config/global.mk:234: ! Warning: HB_BUILD_IMPLIB option works only when 'install' is requested. ...and: ! HB_BUILD_IMPLIB: no My parameters were well defined set HB_DIR_IMPLIB=yes set HB_BUILD_IMPLIB=yes I remove this line: set HB_BUILD_IMPLIB=yes ...and yet does not generate the libs from contrib. Best Regards, Rossine. -- View this message in context: http://old.nabble.com/Contrib%C2%B4s-not-build-with-14457-tp28527275p28661493.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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbMK2 - Feature Request - Auto generated moc_*.cpp files
Hi Pritpal,
I am almost done with QScintilla wrappers which completely
isolate the need to host QScintilla sources into our repository,
but still wrappers be genrated from .qth files and placed in
hbqt/qscintilla.
This folder contents are isolated from the main build system of
hbqt. The only reference needed for them to work is to include
hbqt.h. A qscintilla.hbp file is there to build the library via
hbMK2. This folder only contains wrapper classes to QScintilla.
Everything is working fine except the moc_*.cpp files which
I have to create manually. Is there a chance this can be done
in hbMK2 ? It will greatly simplyfy the build process plus
will open the way to build contrib Qt based libs with similar
fluency as per current Harbour make system. All other aspects
are already in hbMK2.
Maybe the only generic way to integrate such needs with
hbmk2, is to create an separate external tool (non-hbmk2)
and call it as part of of 'preprocessing'. So what needs
to be done in hbmk2 is to allow to run external tools at
specific stages of the process, f.e. 'preflight',
'postflight', 'prelink'.
I hope to hear ideas on the specifics of such
implementation.
Though until this is implemented I'd suggest to do the
'moc' creation as part of the generator tool.
-incpath=${QT_WITH_SCINTILLA}/qt// where QScintilla headers are
In the context of Harbour, QT_WITH_SCINTILLA
should be named HB_WITH_QSCINTILLA.
hbqtgen.prg is tuned to spread sources in the folder its
Class Folder = qscintilla /Class section defines.
The clean solution would be to store QSCINTILLA
related sources inside another .qtp file, instead
of adding more to the existing qt45.qtp file.
Pls make it that way. Then the generator can parse
all existing .qtp files, so there is no change in
usage.
Another (maybe obvious) rule is to strictly avoid
any qscintilla references in HBQT generated sources.
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] NETIOSRV Unable to compile with -static
With the latest SVN, I was not able to compile the netiosrv with -static. I'm using Ubuntu 10.4. Thanks for any help. What is the error? Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBMK2 problem
Hi Przemek, HBMK2 create temporary .c file with non random names in temporary directory. It causes that it cannot be used in multiuser environment because during compilation different HBMK2 processes may overwrite temporary files. Can you fix it? AFAIK the only .c files created with non-random names are the intermediate .c output files created by Harbour compiler. Or, did you find something else? The only way to fix the above case without losing functionality (and performance) is to create these files in a local temporary working directory (created by hbmk2 then deleted before exit). BTW, this can already be forced locally by using -workdir option, and it's only an issue when not using -inc mode, since in the latter case a local workdir is automatically used. What is the use-case in which you experienced this? Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] NETIOSRV Unable to compile with -static
Hi, I have a pending patch regarding gpm and hbmk.cfg, but this is for yesterday's changes. You seem to be using much older Harbour version, not latest SVN. Viktor On 2010 May 23, at 15:37, Mario H. Sabado wrote: On 5/23/2010 8:44 PM, harbour-requ...@harbour-project.org wrote: Message: 6 Date: Sun, 23 May 2010 09:03:22 +0200 From: Viktor Szak?tsharbour...@syenar.hu Subject: Re: [Harbour] NETIOSRV Unable to compile with -static To: Harbour Project Main Developer List. harbour@harbour-project.org Message-ID:f8eebd2c-8c27-4a50-817b-d0b17fe04...@syenar.hu Content-Type: text/plain; charset=us-ascii With the latest SVN, I was not able to compile the netiosrv with -static. I'm using Ubuntu 10.4. Thanks for any help. What is the error? Viktor Hi Viktor, Please find below error I encountered when compiling. Thanks, Mario = hbmk2: Processing local make script: hbmk.hbm hbmk2: Processing configuration: /usr/local/bin/hbmk.cfg Harbour 2.1.0beta1 (Rev. 14277) Copyright (c) 1999-2010, http://www.harbour-project.org/ Compiling 'netiosrv.prg'... Lines 1008, Functions/Procedures 7 Generating C source output to '/tmp/netiosrv.c'... Done. Compiling 'netiocmd.prg'... Lines 1093, Functions/Procedures 3 Generating C source output to '/tmp/netiocmd.c'... Done. /usr/local/lib/harbour/libgttrm.a(gttrm.o): In function `hb_gt_trm_mouse_Hide': gttrm.c:(.text+0x16e): undefined reference to `gpm_visiblepointer' /usr/local/lib/harbour/libgttrm.a(gttrm.o): In function `hb_gt_trm_mouse_Show': gttrm.c:(.text+0x4c3): undefined reference to `gpm_zerobased' gttrm.c:(.text+0x4c8): undefined reference to `_gpm_arg' gttrm.c:(.text+0x4ce): undefined reference to `_gpm_buf' gttrm.c:(.text+0x4d5): undefined reference to `gpm_visiblepointer' gttrm.c:(.text+0x503): undefined reference to `gpm_consolefd' gttrm.c:(.text+0x50b): undefined reference to `_gpm_buf' /usr/local/lib/harbour/libgttrm.a(gttrm.o): In function `hb_gt_trm_mouse_SetPos': gttrm.c:(.text+0x14b4): undefined reference to `gpm_visiblepointer' gttrm.c:(.text+0x14cb): undefined reference to `gpm_zerobased' gttrm.c:(.text+0x14d1): undefined reference to `_gpm_arg' gttrm.c:(.text+0x14d7): undefined reference to `_gpm_buf' gttrm.c:(.text+0x1504): undefined reference to `_gpm_buf' gttrm.c:(.text+0x1510): undefined reference to `gpm_consolefd' /usr/local/lib/harbour/libgttrm.a(gttrm.o): In function `hb_gt_trm_Refresh': gttrm.c:(.text+0x161e): undefined reference to `gpm_visiblepointer' gttrm.c:(.text+0x1633): undefined reference to `gpm_zerobased' gttrm.c:(.text+0x1638): undefined reference to `_gpm_arg' gttrm.c:(.text+0x163e): undefined reference to `_gpm_buf' gttrm.c:(.text+0x1669): undefined reference to `gpm_consolefd' gttrm.c:(.text+0x1671): undefined reference to `_gpm_buf' /usr/local/lib/harbour/libgttrm.a(gttrm.o): In function `set_gpmevt': gttrm.c:(.text+0x2a51): undefined reference to `Gpm_GetEvent' /usr/local/lib/harbour/libgttrm.a(gttrm.o): In function `hb_gt_trm_Exit': gttrm.c:(.text+0x4d68): undefined reference to `gpm_fd' gttrm.c:(.text+0x4e0a): undefined reference to `Gpm_Close' /usr/local/lib/harbour/libgttrm.a(gttrm.o): In function `hb_gt_trm_Init': gttrm.c:(.text+0x5db9): undefined reference to `gpm_zerobased' gttrm.c:(.text+0x5dc3): undefined reference to `gpm_visiblepointer' gttrm.c:(.text+0x5dd7): undefined reference to `Gpm_Open' gttrm.c:(.text+0x5de4): undefined reference to `gpm_fd' gttrm.c:(.text+0x5e15): undefined reference to `gpm_fd' gttrm.c:(.text+0x5e36): undefined reference to `gpm_fd' gttrm.c:(.text+0x5e5e): undefined reference to `gpm_fd' gttrm.c:(.text+0x5e79): undefined reference to `gpm_fd' /usr/local/lib/harbour/libgttrm.a(gttrm.o):gttrm.c:(.text+0x5e92): more undefined references to `gpm_fd' follow collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 gcc /tmp/netiosrv.o /tmp/netiocmd.o /tmp/hbmk_lywx6k.o -Wl,--start-group -lhbnetio -lhbextern -lhbdebug -lhbvmmt -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgttrm -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lm -lpthread -ldl -lrt -lpcre -lz -Wl,--end-group -ohbnetio_linux -L/usr/local/lib/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: hbMK2 - Feature Request - Auto generated moc_*.cpp files
Maybe the only generic way to integrate such needs with
hbmk2, is to create an separate external tool (non-hbmk2)
and call it as part of of 'preprocessing'. So what needs
to be done in hbmk2 is to allow to run external tools at
specific stages of the process, f.e. 'preflight',
'postflight', 'prelink'.
I hope to hear ideas on the specifics of such
implementation.
Sounds good. But I am at a loss to understand what type of
tool it could be. You have embedded moc_ creation in Harbour
build system nicely, rather very nicely.
It's a local extension to HBQT, it's not embedded in core
in any ways.
Note however that GNU Make is a much more generic tool
than hbmk2, with different goals.
Though until this is implemented I'd suggest to do the
'moc' creation as part of the generator tool.
I will think but probably it is not possible due the fact
that at the time of generation the path_to_headers is not
known neither cared. It will increase the complexity IMO.
Complexity is unavoidable, the only question is where
to put it.
If hbmk2 can call an external tool with a preconfigured
list of input files and that external tool can convert
these to whatever else input files, we're done.
-incpath=${QT_WITH_SCINTILLA}/qt// where QScintilla headers
are
In the context of Harbour, QT_WITH_SCINTILLA
should be named HB_WITH_QSCINTILLA.
HB_WITH_QSCINTILLA seems more appropriate, I will change.
Thank you.
Another (maybe obvious) rule is to strictly avoid
any qscintilla references in HBQT generated sources.
Probably this is the most difficult part and probably not viable.
hbqt_par_Q* - hbqt.h
Why cannot QSCINTILLA wrapper sources reference
hbqt.h?
And why do HBQT files need to reference QSCINTILLA
files? If they do, something is wrong, if they
don't, you don't have to mix them.
Pls keep separate components cleanly separated.
It's a basic rule in Harbour.
These must have to go inside hbqt.h otherwise we will end up
replication because the other members are referenced from within
all external lib wrappers anyway. i.e., QFont, QColor, etc.
extern QT_G_FUNC( hbqt_gcRelease_Q* ) - hbqt_garbage.cpp
extern void * hbqt_gcAllocate_Q*l( void * pObj, bool bNew ) -
hbqt_garbage.cpp
These can be somehow isolated in local file like
hbqt_garbage_qscintilla.cpp.
Other implementation could be to create a composite file clubbing _par_
and _gcAllocate_, _gcRelease_ together in the local folder.
I cannot see the nature of complication. There
is no theory which would explain why separate
components need to have mashed-together parts
in order to work.
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem with upper and lower based on CDP
Hi Leandro, These are internal structures, so there if is any notion of writing stable code I strongly suggest to not use them directly at all. I think the bug here is that you can access these members at all. IMO they should be protected like HB_ITEM members. You must be right. The .C code was just an attempt to illustrate what we thought that could help to find a solution if you guys at Houston agree that we have a problem ;) The real problem I want to ask you about is, shouldn't Upper() and Lower() consider the selected codepage? It is important (at least for latin codepage users like PT850) to have case change functionality based upon the selected codepage and not just the default codepage, because in our language we have to use lots of accents. Upper() and Lower() prg level functions seems to have been written to fullfill this need, but if they are then they are not working well... :( UPPER() and LOWER() are considering CP setting. code procedure main() REQUEST HB_LANG_PT REQUEST HB_CODEPAGE_PT850 hb_CDPselect(PT850) ? upper(coração) quit /code This example shows CORAþÒO, but shouldn't it show CORAÇÃO? This is impossible to tell when pasted to an e-mail. Anyhow I've checked it locally directly in the source and to me the PT850 looks alright. Try to open src/codepage/cppt850.c with an editor which you can set to 850 CP, or your browser. Or do the same with above test after your write the result in a file instead of showing it on screen. The problem is probably in your display or output settings. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem with upper and lower based on CDP
The problem is probably in your display or output settings. Viktor Thank you Viktor! I got confused because I used an ANSI editor to write the PRG code when the codepage table code is written in OEM. Yes, the codepage you chose is CP850, which means OEM in Microsoft-speak. Once that is figured out we will write ANSIUpper() and ANSILower() functions to convert the parameter string from ANSI to OEM before passing it to Upper() and Lower() and then convert their return back to OEM. That is not so fast and practical but should work. I don't see why such complication is necessary, or what do you really want to do. If you need ANSI codepage, why don't you use PTISO, or it's also possible to add a PTWIN codepage if you (or anybody else) can provide one. But, as a suggestion, I think that it can be very usefull if Harbour can support ANSI based codepage. I mean, instead of always converting strings from OEM to ANSI or converting source code to OEM one could just select the code page as ANSI or OEM at hb_CDPselect(cdpID,bAnsi) or with a Set(_SET_ANSI_CODEPAGE). Then when ANSI codepage mode was set, the upper and lower char tables could be converted to ANSI inside hb_buildCodePage before the get to cdp-lower and cdp-lower members, or (and this would be more complex) cdp structure could be extent to carry also ANSI lower and upper tables. What do you think about it? ANSI and OEM are totally confusing Microsoft (Windows-specific) terms so we stay out of using them in Harbour. We already support both, but with other names. ANSI is usually ??WIN, and OEM is usually ??85n. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Building libs with hbmk2
Hi, I have this .hbp file: -trace -info -hblib -omylib -inc -workdir=hbobj -iInclude -prgflag=-b and then a list of about 20 source files. this files are compiled and I find the .obj files in directory hbobj From these files a mylib.lib is assembled. Now I'm linking this library in a program using -lmylib and I find the linker loads the WHOLE mylib.lib, not just the used functions... is it normal ? Are you sure? While t's theoretically possible that a linker is so simple to link everything regardless of what is used, but I haven't seen such a thing, not even with BCC. So, if indeed everything is linked, it can only be the result of real references. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem with upper and lower based on CDP
Hi Qatan, ANSI and OEM are totally confusing Microsoft (Windows-specific) terms so we stay out of using them in Harbour. We already support both, but with other names. ANSI is usually ??WIN, and OEM is usually ??85n. Viktor Are not ??ISO and ??WIN the same thing? Thanks for your help. They are similar but not the same. You may not notice the difference for everyday uses though. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem with the generation of Ace32.lib
Hi, It's always generated now. Does it not work now for you? Viktor On 2010 May 21, at 18:40, Ale SB wrote: The latest revisions of Hb, is not generating correctly Ace32.lib from Ace32.dll. Ace32.Lib Gerand by Hb == 105Kb Ace32.lib of Ads\AceSdk == 113Kb With the revisions of Release 2.0, the Ace32.Lib was generated correctly. makeVc2008.bat rem - debug test rem set HB_BUILD_DEBUG=yes rem set HB_TR_OUTPUT=hb_debug.txt rem SET HB_TR_LEVEL=hb_tr_debug set HB_COMPILER_VER=900 set HB_WITH_ADS=C:\ads_8_1\acesdk set HB_DIR_ADS=C:\ADS_8_1\acesdk set HB_BUILD_IMPLIB=yes set HB_BUILD_DLL=yes set HB_COMPILER=msvc set HB_INSTALL_PREFIX=d:\hbvc2008 There is something whose wrong in my Make.bat ? Thank, Ale -- View this message in context: http://old.nabble.com/Problem-with-the-generation-of-Ace32.lib-tp28636274p28636274.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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Erros Rev 14550...MsVc 2008
Hrs_Main.obj : error LNK2001: símbolo externo _HB_FUN_CURDRIVE sin resolver Hrs_Inde.obj : error LNK2001: símbolo externo _HB_FUN_DBPACK sin resolver FiveHm.lib(DATABASE.obj) : error LNK2019: símbolo externo _HB_FUN_DBPACK sin resolver al que se hace referencia en la función _HB_FUN_TDATABASE_ROLLBACK FiveHm.lib(XBROWSE.obj) : error LNK2001: símbolo externo _HB_FUN_DBSKIPPER sin resolver Link hbxpp lib. hbrtl.lib(hbsocket.obj) : error LNK2019: símbolo externo __imp__wsaio...@36 sin resolver al que se hace referencia en la función _hb_socketGetIFaces Use hbmk2. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem with the generation of Ace32.lib
: símbolo externo _adsmgconn...@16 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGCONNECT rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmgdisconn...@4 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGDISCONNECT rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmgkillu...@12 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGKILLUSER rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetservert...@8 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETSERVERTYPE rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetinstalli...@12 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETINSTALLINFO rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetactivityi...@12 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETACTIVITYINFO rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetcommst...@12 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETCOMMSTATS rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmgresetcommst...@4 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGRESETCOMMSTATS rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetconfigi...@20 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETCONFIGINFO rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetuserna...@20 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETUSERNAMES rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetlockow...@24 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETLOCKOWNER rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetopentab...@24 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETOPENTABLES rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetopeninde...@28 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETOPENINDEXES rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetlo...@28 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETLOCKS rddads.lib(adsmgmnt.obj) : error LNK2019: símbolo externo _adsmggetworkerthreadactiv...@16 sin resolver al que se hace referencia en la función _HB_FUN_ADSMGGETWORKERTHREADACTIVITY Thank, Ale Viktor Szakáts wrote: Hi, It's always generated now. Does it not work now for you? Viktor On 2010 May 21, at 18:40, Ale SB wrote: The latest revisions of Hb, is not generating correctly Ace32.lib from Ace32.dll. Ace32.Lib Gerand by Hb == 105Kb Ace32.lib of Ads\AceSdk == 113Kb With the revisions of Release 2.0, the Ace32.Lib was generated correctly. makeVc2008.bat rem - debug test rem set HB_BUILD_DEBUG=yes rem set HB_TR_OUTPUT=hb_debug.txt rem SET HB_TR_LEVEL=hb_tr_debug set HB_COMPILER_VER=900 set HB_WITH_ADS=C:\ads_8_1\acesdk set HB_DIR_ADS=C:\ADS_8_1\acesdk set HB_BUILD_IMPLIB=yes set HB_BUILD_DLL=yes set HB_COMPILER=msvc set HB_INSTALL_PREFIX=d:\hbvc2008 There is something whose wrong in my Make.bat ? Thank, Ale -- View this message in context: http://old.nabble.com/Problem-with-the-generation-of-Ace32.lib-tp28636274p28636274.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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- View this message in context: http://old.nabble.com/Problem-with-the-generation-of-Ace32.lib-tp28636274p28637217.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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about Curl detection during compile process
# looks like a problem hbmk2: Warning: Source dynamic library not found: /ver10/curl-7.20.1-devel-mingw32/include/../libcurl.dll # looks like it worked? hbmk2: Created import library: G:/harbour/lib/win/mingw/liblibcurl.a = /ver10/curl-7.20.1-devel-mingw32/include/../bin/libcurl.dll It's normal. There are multiple places Harbour will look for the .dll. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] file path delimiter
use (db) = dbusearea(,,linux((db)),...) Such modification is still only workaround for the problem which is hardcoded in some other place. You should switch to / or use hb_osPathSeparator() if you want to eliminate any filename conversions. yes, unfortunately it is just a workaround, but its advance is that, once developed, is immediately applicable to all other, yet not ported apps The only thing some may wonder is why such workaround is good for you, when you can get much better coverage for the problem by adding 1-2 lines of .prg code. You can add it even in a new .prg as INIT PROC and simply link it to your app, so only the make file have to changed by adding this one new .prg. 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:[14518]
off Though for this to be true the editor is best to support moving past EOL. Something which is not supported by HBIDE and several other editors (f.e. vi, MSVS). I had just found recently how to set it in MSVS2005: Tools | Options | Text Editor | All Languages (or just the lang you want) There is the checkbox which the cryptic name Enable virtual space when checked it allow you to freely move the keyboard cursor. /off Oh indeed, it works (tried in MSVS 2010). Thanks Chen. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbMK2 - Command Line vs hbIDE - difference
Hi Prital,
Thanks, it seems mingw is sensitive to ending pathseps
in -I options. Pls retry with r14535.
Viktor
On 2010 May 20, at 09:46, Pritpal Bedi wrote:
Hello Viktor
I defined QScintilla ( greatly trimmed ) library project from hbIDE
and could build the library properly. Then I tried the same .hbp from
command line. Below are the results for one of the files:
hbMK2 direct from command line:
---
hbmk2: Compiling C++...
hbmk2: C/C++ compiler command:
g++.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -W -Wall
-pipe -IC:/harbour_dev/harbour/mingw/include -I./ -Iqt -IC:/qt/4
.6.2/qt/include -IC:/qt/4.6.2/qt/include/qtcore
-IC:/qt/4.6.2/qt/include/qtgui -IC:/qt/4.6.2/qt/include/qtnetwork
-I../../hbqt qt/ListBoxQt.
cpp -o .hbmk/win/mingw/ListBoxQt.o
In file included from qt/ListBoxQt.cpp:32:
qt/ListBoxQt.h:36:22: error: Platform.h: No such file or directory
hbIDE executing same .hbp
--
hbmk2: Compiling C++...
hbmk2: C/C++ compiler command:
g++.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -W -Wall
-pipe -IC:/harbour_dev/harbour/mingw/include
-IC:/harbour/contrib/hbide/qscintilla
-IC:/harbour/contrib/hbide/qscintilla/qt -IC:/qt/4.6.2/qt/include
-IC:/qt/4.6.2/qt/include/qtcore -IC:/qt/4.6.2/qt/include/qtgui
-IC:/qt/4.6.2/qt/include/qtnetwork -IC:/harbour/contrib/hbqt
C:/harbour/contrib/hbide/qscintilla/qt/ListBoxQt.cpp -o
C:/harbour/contrib/hbide/qscintilla/.hbmk/win/mingw/ListBoxQt.o
Here is QScintilla.hbp
-3rd=hbide_version=1.0
-3rd=hbide_type=Lib
-3rd=hbide_title=qscintilla
-3rd=hbide_location=C:\harbour\contrib\hbide\qscintilla\
-3rd=hbide_workingfolder=
-3rd=hbide_destinationfolder=
-3rd=hbide_output=qscintilla
-3rd=hbide_launchparams=
-3rd=hbide_launchprogram=
-3rd=hbide_backupfolder=
-3rd=hbide_xhb=NO
-3rd=hbide_xpp=NO
-3rd=hbide_clp=NO
-inc
-w2
-es2
-incpath=.
-incpath=./qt
-incpath=${HB_WITH_QT}/include
-incpath=${HB_WITH_QT}/include/qtcore
-incpath=${HB_WITH_QT}/include/qtgui
-incpath=${HB_WITH_QT}/include/qtnetwork
-oqscintilla
../../hbqt/hbqt.hbc
AutoComplete.cpp
CallTip.cpp
Decoration.cpp
Document.cpp
DocumentAccessor.cpp
Editor.cpp
ExternalLexer.cpp
Indicator.cpp
KeyMap.cpp
KeyWords.cpp
LexCPP.cpp
LexFlagship.cpp
LineMarker.cpp
CellBuffer.cpp
CharClassify.cpp
ContractionState.cpp
PerLine.cpp
PositionCache.cpp
PropSet.cpp
RESearch.cpp
RunStyles.cpp
ScintillaBase.cpp
Style.cpp
StyleContext.cpp
UniConversion.cpp
ViewStyle.cpp
WindowAccessor.cpp
XPM.cpp
qt/ListBoxQt.cpp
qt/moc_qscilexer.cpp
qt/moc_qscilexercpp.cpp
qt/moc_qsciscintilla.cpp
qt/moc_qsciscintillabase.cpp
qt/moc_SciClasses.cpp
qt/PlatQt.cpp
qt/qsciabstractapis.cpp
qt/qsciapis.cpp
qt/qscicommand.cpp
qt/qscicommandset.cpp
qt/qscidocument.cpp
qt/qscilexer.cpp
qt/qscilexercpp.cpp
qt/qscimacro.cpp
qt/qsciprinter.cpp
qt/qsciscintilla.cpp
qt/qsciscintillabase.cpp
qt/qscistyle.cpp
qt/qscistyledtext.cpp
qt/SciClasses.cpp
qt/ScintillaQt.cpp
-
enjoy hbIDEing...
Pritpal Bedi
http://hbide.vouch.info/
--
View this message in context:
http://harbour-devel.1590103.n2.nabble.com/hbMK2-Command-Line-vs-hbIDE-difference-tp5078595p5078595.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 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:[14537] trunk/harbour
Hi Pritpal, Please move HBIDE hosting to a separate repository, because by now it grew just large and popular enough to stand on its own feet, takes a huge portion of SVN and communication of our core development list, and in general has not much to do with out primary goals, and the two projects have apparently quite different and colliding goals. Viktor On 2010 May 20, at 16:18, vouch...@users.sourceforge.net wrote: Revision: 14537 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14537view=rev Author: vouchcac Date: 2010-05-20 14:18:25 + (Thu, 20 May 2010) Log Message: --- 2010-05-20 07:14 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/ideprojmanager.prg * contrib/hbide/idesources.prg % Modified: to present the project location folder to select sources in the Project Properties dialog. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/ideprojmanager.prg trunk/harbour/contrib/hbide/idesources.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 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:[14536] trunk/harbour
Sorry Pritpal, but I will remove this from SVN. Viktor On 2010 May 20, at 16:13, vouch...@users.sourceforge.net wrote: Revision: 14536 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14536view=rev Author: vouchcac Date: 2010-05-20 14:13:24 + (Thu, 20 May 2010) Log Message: --- 2010-05-20 06:56 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) + contrib/hbide/qscintilla + contrib/hbide/qscintilla/qt Initial port of QScintilla ( http://www.riverbankcomputing.co.uk/software/qscintilla/intro ) This port is greatly trimmed one excluding all lexer code except CPP and FLAGSHIP which are relevant to Xbase code at present. Also directory structure is normalized and sources are modified to respect them. SVN properties are eol:native, I am not sure what other properties should go inside. QScintilla actually is divided into two libs but for sake of convinience I have kept them as one. It is a base commit. In the next days a Harbour wrapped is scheduled to be built onto it and then actual application experiments will follow. On success, current edit component of hbIDE will be transferred. I am poor in looking at licensing, so please feel free to delete this commit if it does not confirm to original intent. I have also touched the sources to suppress a lot of warnings and library seems to be working fine after these changes. Still some warnings are there which I could not supress, please look. To build the lib qscintilla.hbp is there, just issue hbmk2 qscintilla.hbp while residing in hbide/qscintilla. Modified Paths: -- trunk/harbour/ChangeLog Added Paths: --- trunk/harbour/contrib/hbide/qscintilla/ trunk/harbour/contrib/hbide/qscintilla/Accessor.h trunk/harbour/contrib/hbide/qscintilla/AutoComplete.cpp trunk/harbour/contrib/hbide/qscintilla/AutoComplete.h trunk/harbour/contrib/hbide/qscintilla/CallTip.cpp trunk/harbour/contrib/hbide/qscintilla/CallTip.h trunk/harbour/contrib/hbide/qscintilla/CellBuffer.cpp trunk/harbour/contrib/hbide/qscintilla/CellBuffer.h trunk/harbour/contrib/hbide/qscintilla/CharClassify.cpp trunk/harbour/contrib/hbide/qscintilla/CharClassify.h trunk/harbour/contrib/hbide/qscintilla/CharacterSet.h trunk/harbour/contrib/hbide/qscintilla/ContractionState.cpp trunk/harbour/contrib/hbide/qscintilla/ContractionState.h trunk/harbour/contrib/hbide/qscintilla/Decoration.cpp trunk/harbour/contrib/hbide/qscintilla/Decoration.h trunk/harbour/contrib/hbide/qscintilla/Document.cpp trunk/harbour/contrib/hbide/qscintilla/Document.h trunk/harbour/contrib/hbide/qscintilla/DocumentAccessor.cpp trunk/harbour/contrib/hbide/qscintilla/DocumentAccessor.h trunk/harbour/contrib/hbide/qscintilla/Editor.cpp trunk/harbour/contrib/hbide/qscintilla/Editor.h trunk/harbour/contrib/hbide/qscintilla/ExternalLexer.cpp trunk/harbour/contrib/hbide/qscintilla/ExternalLexer.h trunk/harbour/contrib/hbide/qscintilla/Indicator.cpp trunk/harbour/contrib/hbide/qscintilla/Indicator.h trunk/harbour/contrib/hbide/qscintilla/KeyMap.cpp trunk/harbour/contrib/hbide/qscintilla/KeyMap.h trunk/harbour/contrib/hbide/qscintilla/KeyWords.cpp trunk/harbour/contrib/hbide/qscintilla/KeyWords.h trunk/harbour/contrib/hbide/qscintilla/LexCPP.cpp trunk/harbour/contrib/hbide/qscintilla/LexFlagship.cpp trunk/harbour/contrib/hbide/qscintilla/License.txt trunk/harbour/contrib/hbide/qscintilla/LineMarker.cpp trunk/harbour/contrib/hbide/qscintilla/LineMarker.h trunk/harbour/contrib/hbide/qscintilla/Partitioning.h trunk/harbour/contrib/hbide/qscintilla/PerLine.cpp trunk/harbour/contrib/hbide/qscintilla/PerLine.h trunk/harbour/contrib/hbide/qscintilla/Platform.h trunk/harbour/contrib/hbide/qscintilla/PositionCache.cpp trunk/harbour/contrib/hbide/qscintilla/PositionCache.h trunk/harbour/contrib/hbide/qscintilla/PropSet.cpp trunk/harbour/contrib/hbide/qscintilla/PropSet.h trunk/harbour/contrib/hbide/qscintilla/RESearch.cpp trunk/harbour/contrib/hbide/qscintilla/RESearch.h trunk/harbour/contrib/hbide/qscintilla/RunStyles.cpp trunk/harbour/contrib/hbide/qscintilla/RunStyles.h trunk/harbour/contrib/hbide/qscintilla/SString.h trunk/harbour/contrib/hbide/qscintilla/SVector.h trunk/harbour/contrib/hbide/qscintilla/SciLexer.h trunk/harbour/contrib/hbide/qscintilla/Scintilla.h trunk/harbour/contrib/hbide/qscintilla/ScintillaBase.cpp trunk/harbour/contrib/hbide/qscintilla/ScintillaBase.h trunk/harbour/contrib/hbide/qscintilla/ScintillaWidget.h trunk/harbour/contrib/hbide/qscintilla/SplitVector.h trunk/harbour/contrib/hbide/qscintilla/Style.cpp trunk/harbour/contrib/hbide/qscintilla/Style.h
