[Harbour] Re: symlink attack vuln in hb
On Wed, 02 Jun 2010, Szak�ts Viktor wrote: Hi Viktor and Tamas, The security problem with links appears when any file is open for writing and previous contents of the file is not released so application cannot use 'unlink' and O_EXCL flag (or workarond with 'link' for race condition in old NFS = 3.0 protocols). BTW for security reasons we should have such code The idea with copping the file original file body to new one when log is created does not resolve the problem but replace it with the new one even worser, i.e.: ln -s /ets/shadow /tmp/hb_out.log and I can read encrypted passwords for brutal force attack. Of course any soft links can be eliminated by using O_NOFOLLOW open() flag on systems which support it but it does not help for hard links so the problem still exists (good admins used to keep vital system files on separate partitions without any write access for users so they cannot create any hard links) but we can try to make farther protection and use fstat() to check number of links. It's still not perfect because we have race condition which cracker may try to exploit but if we can compare fstat() results with stat() results to be sure we are talking about the same file. It's efficient solution for systems which supports O_NOFOLLOW but this is not POSIX flag and some older *nixes may not have it. If you want then I can add such protection. All programs opening/creating files have such problems and it's programmer job to create application protected against such attack, i.e. my production applications drop root privileges switching to some other user and group ID. In this particular case we are talking about hb_out.log files created when harbour application crashes so it's not sth what should appear in production code but it cannot be excluded. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12253] trunk/harbour
On Sat, 22 Aug 2009, Jarosław Kądzioła wrote: Hi, $ hbmk2 testole hbmk: Processing local make script: hbmk.hbm hbmk: Processing configuration: F:\msys\1.0\hb-mingw\bin\hbmk.cfg hbmk: Processing: hbwin.hbc Harbour 2.0.0beta2 (Rev. 12247) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling 'testole.prg'... Lines 429, Functions/Procedures 12 Generating C source output to 'testole.c'... Done. F:/msys/1.0/hb-mingwarm/lib/libhbwin.a(olecore.o):olecore.c:(.text+0x18ec): undefined reference to `GetActiveObject' F:/msys/1.0/hb-mingwarm/lib/libhbwin.a(oleinit.o):oleinit.c:(.text+0x14): undefined reference to `OleInitialize' F:/msys/1.0/hb-mingwarm/lib/libhbwin.a(oleinit.o):oleinit.c:(.text+0x50): undefined reference to `OleUninitialize' collect2: ld returned 1 exit status Can you repeat your tests with current SVN code? Not it should link cleanly but I'm interesting if current OLE code is really working in WinCE. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12253] trunk/harbour
On Mon, 31 May 2010, Przemysław Czerpak wrote: Can you repeat your tests with current SVN code? Not it should link cleanly but I'm interesting if current ^^^ Now OLE code is really working in WinCE. sorry for stupid typo. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14646] trunk/harbour
On Mon, 31 May 2010, vszak...@users.sourceforge.net wrote:
Hi,
2010-05-31 13:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
+ contrib/hbwin/tests/oletst2.vbs
+ contrib/hbwin/tests/oletst2.js
+ Added vbscript and jscript test code.
Thank you.
Can you create some more complicated example for VBS or
some other languages to test data exchanging.
Something like oletst4.prg can be used to test different
item types.
BTW now Harbour passes parameters by reference using strong type
based on original value, i.e.:
var := 123
oOle:msg( @var )
passes 'var' as VT_I4 | VT_BYREF. Such method was chosen after
Toninho and/or Alex tests. Sorry I do not remember who exactly
tested it but the results sent to this list suggested that some
OLE servers do not accept more general version with parameters
passed as VT_VARIANT | VT_BYREF which allow to change the type
of assigned value.
Anyhow such implementation is limitation and maybe we should
add an option to always use VT_VARIANT | VT_BYREF when parameters
are passed by reference. It works very nice when client and inporc
server are written using Harbour (ole{srv,tst}4.prg is such code
example) but now it's necessary to use NIL as passed value to force
using VT_VARIANT | VT_BYREF.
I'm thinking about adding sth like:
__oleStrongRef( pOle [, lNewSetting ] ) - lPrevSetting
but I would like to know if OLE users will find it useful and
if other non strong type languages pass OLE parameters by reference
using VT_VARIANT | VT_BYREF so I'm interesting in test results, i.e.
how such parameters are passed by xbase++?
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour-users] A few points wondering
On Mon, 31 May 2010, Bicahi Esgici wrote: Hi, - Does Harbour have COMPRESSSTRING(), UNCOMPRESSSTRING() functions ? (equivalents (?) of xHarbour's CHARPACK() and CHARUNPACK() functions) ( According to a Harbour.chm, yes; according to hbmk2, no; even REQUEST; ( undefined reference to ... ) ) I do not know COMPRESSSTRING() and UNCOMPRESSSTRING() and AFAIK xHarbour does not contain such functions. CHARPACK() and CHARUNPACK() are Clipper Tools functions which exists in HBCT library. To use them you have to add HBCT library to linked library list using '-lhbct' hbmk2 switch. Both Harbour and xHarbour use the same implementation of this function which supports only method 0 and method 1 (bit oriented algorithm in CA-CT3) is not supported. Harbour has also few other compression method much more efficient. In core code it support SIX3 compatible compression Sx_Compress()/ Sx_Decompress() and ZLIB compatible HB_ZCOMPRESS()/HB_ZUNCOMPRESS(). In hbbz2 library it also supports BZIP2 compression HB_BZ2_COMPRESS()/ HB_BZ2_UNCOMPRESS(). It needs BZIP2 compression library and -lhbbz2 -lbz2 hbmk2 switches. HBBZ2 library is not available in Harbour2.0. In xHarbour there are also HB_COMPRESS() and HB_UNCOMPRESS() functions. They are wrappers to ZLIB library and available in Harbour in xHarbour compatibility library (xhb.lib). To use them you need to specify -lxhb HBMK2 switch but I strongly suggest to use native Harbour ZLIB API which has much cleaner interface (HB_ZCOMPRESS()/HB_ZUNCOMPRESS()) - hbmk2 say : ...lib/libhbct.a(charop.o):charop.c:(.text+0xa40): multiple definition of `HB_FUN_CHARXOR' ...lib/libcrypt.a(c_crypt.o):c_crypt.c:(.text+0x0): first defined here Sorry but libcrypt.a is not part of Harbour. I do not know where did you take this library from and what it does but it tries creates name conflict with CHARXOR() function in HBCT library. You should contact with this library author and ask about the fix. - Harbour give 4 for expression : LEN( W2BIN( BIN2W( 2^10 ) ) ) ) According to a Harbour.chm, W2BIN() return a two bytes character string. AFAIK W stand for word and word is 16 bit encoded unsigned short integer; does I'm wrong? You are right. It's typo in W2BIN() in HBXPP (xbase++ compatible) library. I'll fix it ASAP. Thanks for the info. best regards, Przemek ___ Harbour-users mailing list (attachment size limit: 40KB) Harbour-users@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour-users
Re: [Harbour] Re: Documentation storm on user's list
On Sat, 29 May 2010, pete_westg wrote: Hi, ..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. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14626] trunk/harbour
On Fri, 28 May 2010, vszak...@users.sourceforge.net wrote: 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. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14626] trunk/harbour
On Fri, 28 May 2010, Szak�ts Viktor wrote: Hi Viktor, I got a large number of unresolved externals. I think Because you haven't recompiled whole Harbour code with -r6 watcom compiler switch. 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. 2. chosing startup entry point for created binaries and interaciton with existing hack with hb_forceLinkMainWin()/hb_forceLinkMainStd(). 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. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14626] trunk/harbour
On Fri, 28 May 2010, Szak�ts Viktor wrote: 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. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBMK2 problem
On Wed, 26 May 2010, Szak�ts Viktor wrote: Hi Viktor, 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. 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 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. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14609] trunk/harbour
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
Re: [SPAM] [Harbour] Re: SF.net SVN: harbour-project:[14593] trunk/harbour
On Tue, 25 May 2010, Pritpal Bedi wrote:
Hi,
Below is the converted code which registers itself successfully.
-
#define CLS_Name Vouch32.Vouch.1
#define CLS_ID {1F6C0963-1581-498a-9035-E75A0F546CA5}
//---//
PROCEDURE DllMain()
WIN_OleServerInit( CLS_ID, CLS_Name, {|| Vouch32ActiveX():new() }, .t. )
RETURN
[...]
Why you added .T. as 4-th parameter?
It means that all OLE messages will be redirected to your object as
string 1-st parameter in EVAL() method.
It's necessary when you want to accept any message names like in
olesrv1.prg which is NETIO OLE server but your Vouch32ActiveX()
does not even have EVAL message:
Error BASE/1004 Message not found: VOUCH32ACTIVEX:EVAL
Called from __ERRRT_SBASE(0) Server
Called from VOUCH32ACTIVEX:ERROR(0) nication
Called from (b)HBOBJECT(0) ial Communication II
Called from VOUCH32ACTIVEX:MSGNOTFOUND(0)
Called from (b)EVAL(0) SMTP Server
You should simply use:
WIN_OleServerInit( CLS_ID, CLS_Name, {|| Vouch32ActiveX():new() } )
or because Vouch32ActiveX object does not have any instance variables
to safe some memory and increase a little bit the speed you can use
only one HVM Vouch32ActiveX object for all OLE object:
WIN_OleServerInit( CLS_ID, CLS_Name, Vouch32ActiveX():new() )
Both versions will work for you.
But the problem is when I am accessing its methods as such:
Function Main()
Local oGraph, oServer
if !( CreateVouch32( @oServer ) )
Return nil
endif
oGraph := oServer:Vouch32GraphicsServer()/* IT IS OK HERE */
oGraph:Create()/* RTE - See Below */
oGraph:Destroy()
Return nil
I think the RTE is in this line:
oGraph := oServer:Vouch32GraphicsServer()/* IT IS OK HERE */
If you remove the 4-rd .T. parameter from WIN_OleServerInit() then
this line will work successfully but your code will fail in this line:
oGraph:Create()/* RTE - See Below */
because oGraph is NIL not OLE object. It will happen because I haven't
implemented so far automatic conversion of HVM object returned by OLE
methods to OLE objects.
Is above description correct?
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [SPAM] [Harbour] Re: SF.net SVN: harbour-project:[14593] trunk/harbour
On Tue, 25 May 2010, Pritpal Bedi wrote: Hi, But the problem is when I am accessing its methods as such: Function Main() Local oGraph, oServer if !( CreateVouch32( @oServer ) ) Return nil endif oGraph := oServer:Vouch32GraphicsServer()/* IT IS OK HERE */ oGraph:Create()/* RTE - See Below */ oGraph:Destroy() Return nil I think the RTE is in this line: oGraph := oServer:Vouch32GraphicsServer()/* IT IS OK HERE */ If you remove the 4-rd .T. parameter from WIN_OleServerInit() then this line will work successfully but your code will fail in this line: oGraph:Create()/* RTE - See Below */ because oGraph is NIL not OLE object. It will happen because I haven't implemented so far automatic conversion of HVM object returned by OLE methods to OLE objects. Is above description correct? Absolutely yes. Fine. I've just added conversion of HVM objects returned by Harbour OLE server methods to OLE objects. Please check after: 2010-05-26 11:19 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) Sorry but I haven't tested it at all. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HBMK2 problem
Hi Viktor,
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.
Can you fix it?
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.
I think also that hbolesrv.hbc should contain also libs=hbwin so user
can easy use it to create his own inproc DLLs.
best regards,
Przemek
___
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...
On Tue, 25 May 2010, Ale SB wrote: Hi, 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. TimeToSec() and SecToTime() are Clipper Tools functions. In Harbour they are implemented in HBCT library and this implementation should replicate original Clipper/CT3 behavior. If it doesn't then we should check the exact difference and fix it. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14579] trunk/harbour
On Tue, 25 May 2010, Szak�ts Viktor wrote:
Hi,
That sounds great, may I ask for a simple example which
show the usefulness of this feature over regular hashes?
This code illustrates the difference between regular and
associative hash arrays:
proc main()
local h
h := { = }
? regular hash array
tst( h )
h := { = }
? associative hash array
hb_hKeepOrder( h, .T. )
tst( h )
return
proc tst( h )
local v, i
h[ 'zxc' ] := 1.000
h[ 'qwe' ] := 2.000
h[ 'abc' ] := 3.000
h[ 'dfg' ] := 4.000
h[ 'rbc' ] := 5.000
? for each:
for each v in h
? v:__enumIndex(), v:__enumKey(), v
next
? access by index:
for i := 1 to len( h )
? i, hb_hValueAt( h, i )
next
?
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.
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)
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14579] trunk/harbour
On Tue, 25 May 2010, Lautaro Moreira wrote: Hi, 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. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14560] trunk/harbour
On Sun, 23 May 2010, vszak...@users.sourceforge.net wrote: Hi Viktor, 2010-05-23 20:54 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.pt_BR.po * utils/hbmk2/hbmk2.hu_HU.po * utils/hbmk2/hbmk2.prg + In non-incremental mode when no workdir is manually set, hbmk2 will now create a temp subdir inside temp dir and create any intermediate output files there. (previously it was using the temp dir without creating a temp subdir inside). ; Please test and report leftover temp files and dirs, also test it on *nix platforms. Thank you very much. It works very nice with native Linux hbmk2 binaries and also with Windows ones (BCC and OWC) executed with WINE. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HB in MT mode + testsvc.prg = service don't start.
On Mon, 24 May 2010, Vailton Renato wrote: Hi, 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. I'm not familiar with services in MS-Windows so I hope that real MS-Windows programmers can verify the text below. MSDN says that StartServiceCtrlDispatcher() makes calling thread service dispatcher which creates new thread to execute the appropriate ServiceMain function when a new service is started. It means that current win_svc.c code cannot work with MT HVM because it does not initialize new HVM stack for newly created thread. It also does not unlock HVM stack used by thread calling StartServiceCtrlDispatcher() what will cause deadlock when some other thread activates GC. It works with ST HVM because thread created for ServiceMain function reuses the HVM stack bound with thread calling StartServiceCtrlDispatcher() taking its address from static variable. It does not work with MT HVM because in MT mode each HVM thread extracts HVM stack pointer from TLS so newly create thread takes NULL as its own stack pointer. If you want to use this code with MT HVM then it has to be adopted to work safely with it. It should create and destroy on exit new HVM stack and encapsulate call to StartServiceCtrlDispatcher() into hb_vmUnlock()/ hb_vmLock(). best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14575] trunk/harbour/ChangeLog
On Tue, 25 May 2010, tfonro...@users.sourceforge.net wrote: Hi, Log Message: --- 2010-05-24 19:19 UTC-0500 Teo Fonrouge (teo/at/windtelsoft/dot/com) * contrib/hbtip/thtml.prg * removed old FOR EACH limitation Thank you for your modification but this entry can seriously confuse users. Harbour never had such FOR EACH limitation. Only xHarbour has such limits and they still exists in xHarbour compiler so xHarbour still needs such hacks and you removed only workaround for xHarbour's FOR EACH limitation. If possible please update the ChangeLog entry. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HBMK2 problem
Hi Viktor, 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? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Setting File Permission with NetIO
On Fri, 21 May 2010, Mario H. Sabado wrote: Hi, How can I set the file permission when creating index file via NetIO server under Linux? I have to chmod each time I reindex to reset file permission settings of the created index. Set umask before you run the server. See: man umask for details. Maybe in some spare time I'll add to contrib some wrappers for LIBC/POSIX functions, i.e. hbposix library. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] file path delimiter
On Thu, 20 May 2010, sali wrote: Hi, porting big app from clipper/win to harbour/linux, and having lot of hard-coded and/or composed file/index paths with back-slash '\' embedded is there some 'set' setting to at 'run-time-level' replace [convert] windows-style '\' to linux-style '/' paths directly changing source is not an option, It's always the best option. / as path separator works in all systems. my second thought is to tweak at pp-level Everything what can be done on PP level can also be done in source code so there is no reason to make such things on PP level. any suggestion? SET( _SET_DIRSEPARATOR, \ ) makes what you need inside Harbour code but please remember that if you pass some parameters to externally executed commands then you should make conversion to native OS directory separator. You may also have similar problems with file case. In *nixes file systems are case sensitive. SET( _SET_FILECASE, LOWER | UPPER | MIXED ) SET( _SET_DIRCASE, LOWER | UPPER | MIXED ) can be used to enable (disable) conversions arbitrary conversions of all file/dir names used inside Harbour code. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] file path delimiter
On Thu, 20 May 2010, sali wrote: Hi, my second thought is to tweak at pp-level Everything what can be done on PP level can also be done in source code so there is no reason to make such things on PP level. thnx for the tips just to explain, regarding pp, of course that it can be done in source, but tweaking pp, i may have prg source totaly untouched [which is important to keep application compatibility, no need for additional quality testing] like this part replacing std.ch ... 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. best regards, Przeemk ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_rexexlike and hb_regexhas not work
On Thu, 20 May 2010, Adam Lubszczyk wrote: Hi! Try sample: FUNCTION main() LOCAL reg := hb_regexcomp(.*B.*) LOCAL cText := ABC LOCAL x ? hb_regexlike(reg,cText) ? hb_regexhas(reg,cText) IF VALTYPE(x:=hb_regex(reg,cText)) == A ? FOUND:,x[1] ENDIF RETURN nil Write: .F. .F. FOUND: ABC Harbour ver: 2.1.0beta1 (Rev. 14520) hbpcre.lib ver: 8.02 2010-03-19 .T. .T. FOUND: ABC So all is correct. 10 against 1 that you created the problem yourself by linking application manually using wrong library order so the very old PCRE library which is part of BCC CRTL used to emulate POSIX regex is partially linked instead of HBPCRE. Please use HBMK2. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] sunpro-compiled hbrun doesn't work anymore
On Thu, 20 May 2010, Tamas TEVESZ wrote: Hi, as $subject says. i have bisected the problem to have been introduced in r12466 (r12465 is fine). r12466 only says segmentation fault, leaving an empty hb_out.log; r14542 is a bit more verbose with: Application Internal Error - /home/ice/w/xhb/hbci/harbour-bisect/harbour/inst/linux/sunpro/c/bin/hbrun Terminated at: 2010.05.20 22:26:52 Unrecoverable error 6005: Exception SIGSEGV at address 0x1b800ad5268 Called from GET(73) Called from GETNEW(1978) Called from __GET(70) Called from HB_DOTPROMPT(162) in ../../../hbrun.prg Called from _APPMAIN(124) in ../../../hbrun.prg (backtraces for both cases are below). this only happens if hbrun is requested to run interactively (eg. using the dot console); if it is to run a program (at least a simple one), it's ok. i also have not been able to find anything similar with the other compilers i'm testing with. build environment is ubuntu 10.04/x64 and ubuntu 6.06/i386, with the following settings: Linux SUNPRO port has very serious bug. It does not correctly generate code for all constructors. We are exploiting this problem from time to time. It probably depends on total binary size which may interact with the contents of some uninitialized memory. I do not know exectly where inside SUNPRO the problem is but I've checked the final results in harbour application. Startup code for some PRG modules is not executed so they are not registered in HVM and their symbol tables are not initialized but other modules contains references to functions from unregistered modules and when they are executed application GPFs when trying to access PHB_DYNS pointers in symbol tables. In the past I reported few times that in my SunPRO builds hbtest GPFs due to this problem. Now I've tested current builds and it works OK. I can executed without any problems hbtest and hbrun. I'm using suse1...@x86_64. Anyhow I expect that it can stop to work in any moment when some modification change total memory alignment and the problem will be exploited again. Looks that in your system is still exploited. Program received signal SIGSEGV, Segmentation fault. 0x00429ae1 in hb_vmPushStatic (uiStatic=1) at ../../../hvm.c:6960 6960 pStatic = ( ( PHB_ITEM ) hb_stackGetStaticsBase() )-item.asArray.value-pItems + uiStatic - 1; The symbol table of executed module was not registered so static frame was not initialized and now executed code tries to access the array of static variables using NULL pointer and GPFs. I know what's the reason of problem but I'm afraid that I cannot resolve it well. It has to be fixed inside SunPRO compiler/linker code. It's probably only in Linux port. I've never exploited it in SunOS. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Return of hb_LibLoad()
On Wed, 19 May 2010, Itamar Lins wrote: Hi Itamar, VALTYPE() can never return '0'. HB_LIBLOAD() will return empty value (NIL) on failure and pointer on success. Yes, the return is U undefined if not found file dll. And 0 if run ok. You used to ignore answers. Valtype cannot rerurn 0. My tests is Win 7, with MingW, ChangeLog 14527 I have no idea what and where you have tested but for sure the results you presented are only your personal imagination not real test results. Please be more precise if you expect that someone will invest time to verify such messages. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] turn of hb_LibLoad()
On Wed, 19 May 2010, Petr Chornyj wrote: Hi, Yes, because rmchart.dll no p-code dll. You can use the function hb_libLoad and Co only with p-code dll. It's not true. hb_libLoad() can and should be used to any type of libraries. It doesn't matter if they contain PCODE or not. The important extension in hb_libLoad() is that it allows to safely load any libraries when pure wrappers to LoadLibrary() WIN API may cause HVM corruption so it's recommended to always use it. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DTR/DSR hardware handshake on linux
On Wed, 19 May 2010, Bisz István wrote: Hi István, Please find attached the hbcon.c patch allowing on some linux distroes the DTR/DSR hardware handshake. The DTR/DSR is a very often used handshake for serial printers, at least in the POS field. A lot of supermarket cash registers are in fact PCs with special hardware, which for some historical reason typically knows only about DTR/DSR handshaking . So its important to support this feature in harbours serial communication for linux distroes offering an implementation like Red Hats EL5 and derivatives (CentOS 5). Please analyze the attachments and if it fits to our needs, apply it in an adequate version. Thank you very much for patches. This code uses Linux specific extensions which are included in new only kernels. It allows to access some additional low level serial port settings using IOCTLs/functions defined in linux/termios.h and linux/serial.h. So far I haven't use it due to rather pure portability and because I was to lazy to add to our make system autodetection for Linux version and header files. Anyhow I'll think yet about adding it and also requested by Mindaugas COM status line waiting. Again thank you very much for you help and fixing my typo in CLOCAL flag. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_atomic_* not exported
On Wed, 19 May 2010, Szak�ts Viktor wrote: Hi Viktor, I'm trying to create -shared Harbour app while linking hbnetio, and hb_atomic_* functions are missing from Harbour .dll so it fails. Shouldn't they be declared 'extern HB_EXPORT'? (now there is not qualifier before declaration) Yes, they should just like few other public Harbour thread API functions. I'll fix it ASAP. Thank you for the information. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Return of hb_LibLoad()
On Wed, 19 May 2010, Itamar Lins wrote: Itamar, Yes, the return is U undefined if not found file dll. And 0 if run ok. My tests is Win 7, with MingW, ChangeLog 14527 Sorry my fault, return of valtype is 'N'. Value is 0. Very busy for here... :( I still have no idea what you are testing but it's not Harbour. In Harbour HB_LIBLOAD() cannot return 0. This function can return NIL on error or pointer item ( VALTYPE(result) - P ). It never returns numeric value. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14518] trunk/harbour
On Tue, 18 May 2010, Szak�ts Viktor wrote: Hi, What is the reason you want to handle line selection separately from stream selection? Line selection looks like a stream which ends and begins at column zero. Could be much simpler with two modes: stream and block. It's not the same. When you paste line selected block then you do not have to keep cursor at column 0 to insert it as whole lines. Stream block has such condition otherwise pasted text will start at current cursor column. In general line blocks allow to select and paste whole lines without respecting the cursor column position. It's really useful feature. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14515] trunk/harbour
On Tue, 18 May 2010, Przemysław Czerpak wrote: Hi Viktor, 2010-05-18 02:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.pt_BR.po * utils/hbmk2/hbmk2.hu_HU.po * utils/hbmk2/hbmk2.prg + Added experimental -hbdynvm mode. + Added support for .def input file in -hbdyn/-hbdynvm modes. Thank you very much. I'll check it tomorrow. -hbdynvm enables static libraries (-nohblib-) and this works correctly. It does not enable linking temporary .c files with additional settings like requested and default driver, i.e. -gtgui is ignored. I also think that now -hbdyn (without 'vm' suffix) should not enable Harbour shared library by default when -shared switch is used. Separate switch -hbdynvm allows user to control it so and this is much better solution. So we need two additional modification: 1. enable the same temporary .c file used for .EXE files with HVM startup settings with -gt* or -main=* switches when dynamic library is created with -hbdynvm switch. 2. disable linking with harbour-*.dll when -hbdyn and -shared are used The .def files with MinGW and MinGWCE builds work as expected. Thank you very much. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14518] trunk/harbour
On Tue, 18 May 2010, Szak�ts Viktor wrote: Hi, I know I have to also paste it in column 1. And this is the very inefficient part in stream block pasting which causes that they are not such flexible as line blocks when whole lines are copied. Just simply it forces additional horizontal cursor synchronization which is not necessary in line blocks. You may not use line blocks at all but believe me that for people who used real line blocks like in ME stream blocks is not serious alternative for whole line coping. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14515] trunk/harbour
On Tue, 18 May 2010, vszak...@users.sourceforge.net wrote: Hi, 2010-05-18 02:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) ; TODO: Couldn't find how to pass .def files to Open Watcom wlink. Anybody with an experience here? As I can see OW supports .def files only in 'link' command and wlink uses a little bit different format. It's necessary to use EXPORT command in .lnk file or include separate file with such definitions using @filename command. Here are commands I used with Open Watcom: EXPORT DllGetClassObject = '_dllgetclassobj...@12' PRIVATE EXPORT DllCanUnloadNow = '_dllcanunload...@0' PRIVATE EXPORT DllRegisterServer = '_dllregisterser...@0' EXPORT DllUnregisterServer = '_dllunregisterser...@0' EXPORT DllMain = '_dllm...@12' We can add function which will translate .def files to this format or we can leave it for users and include them as separate in link script. But here we still have the problem that HBMK2 ignores commands like -ldfl...@myolesrv.def Viktor for me it's a bug which should be fixed. Why you decided that HBMK2 should ignore compiler and linker command specified by user if they do not start with - character? In my opinion any text passed as -*flag=text should be passed to corresponding Harbour/C compiler/linker and HBMK2 should not silently ignore only some of them. In some situations like above it's serious limitation. There is also yet another important problem with current OpenWatcom MS-Windows builds. Current harbour OW build time switches forces stack calling convention and not all Open Watcom libraries are compiled in this mode. It causes that it's not possible to use some extensions like OLE code due to unresolved external, i.e. try to link contrib/hbwin/tests/testax.prg If user wants to use OLE with Open Watcom builds then it has to recompile whole Harbour code with: HB_USER_CFLAGS=-6r and then use -cflag=-6r HBMK2 parameter. Can we switch back OpenWatcom builds to its default calling convention? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Database close during index open failure
On Tue, 18 May 2010, Mindaugas Kavaliauskas wrote: Hi, 3 similar samples with different error, so, perhaps we have memory corruption here. This is expected and documented few times on this list behavior. Of course it's a bug but it cannot be well fixed without very serious modifications in RDD code and all code (also 3-rd part one) which access any RDD methods. It's necessary to introduce sth like: pArea = hb_rddLockCurrentArea(); [...] // any RDD methods hb_rddFreeArea( pArea ); hb_rddLockCurrentArea()/hb_rddLockArea(iArea) will increase reference counter and hb_rddFreeArea() will decrease it. non zero reference counter will delay releasing the pArea structure until hb_rddFreeArea() will set it to 0. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14515] trunk/harbour
On Tue, 18 May 2010, Szak�ts Viktor wrote: Hi, Before going further can you help define in normal words what is the description / distinction between -hbdyn and -hbdynvm modes? -hbdyn creates DLL which is not linked with HVM. -hbdynvm creates DLL which is linked with HVM and other Harbour core libraries. When do we use which mode? When we need or not HVM to be linked with final dynamic library so it depends on the code I'm linking. I can use -hbdyn to create DLL which does not have any references to Harbour core code. I can use -hbdyn and -lhbmaindllp to create DLL containing compiled .PRG modules (PCODE DLL) which can be dynamically loaded by static or dynamic Harbour application. I can use -hbdyn and -static to create self contain DLL which uses it's own private copy of HVM and Harbour RTL library which can be linked statically or loaded dynamically with/from any other applications, this application can use it's own HVM copy which will not interact with the one included in DLL in any way. I can use -hbdynvm and -shared to create PCODE DLL which can be linked statically or loaded dynamically by shared linked Harbour application and HVM code and structures are shared in such case. There are also many other situations when user may need -hbdyn or -hbdynvm. [ we now have .prg .dlls, normal .dlls, VM .dlls, but I'm starting to get confused, which means it's difficult to organize the internals. F.e. now I can introduce a new sub-switch inside -hbdyn mode for 'vm', or I could cleanup the modes into a flat list. ] See above. Please also remember that dynamic shared libraries using HVM are initialized just like normal EXE files and when they contain their own HVM switches like -gt* should be enabled just for executable binaries. If they share HVM then you can also enable them and they will be ignored so you do not have to implement any special case for such situation. Enabling specific features based on the mode is less of a problem. Bonus: Do you have any hint how to use .def files with watcom compiler? Spent 1 hour on it to no avail, maybe it's too obvious or it was too late. See my second message. WLINK seems to not accept .DEF files directly and uses a little bit different syntax. Only LINK can accept them and probably internally translates them to WLINK format. We can add translation from .DEF files to this format or we can simply include .DEF files directly using @ command in WLINK .lnk file and user will have to use OpenWatcom compatible format for them. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Database close during index open failure
On Tue, 18 May 2010, Mindaugas Kavaliauskas wrote:
Hi,
This is expected and documented few times on this list behavior.
Of course it's a bug but it cannot be well fixed without very serious
modifications in RDD code and all code (also 3-rd part one) which
access any RDD methods.
It's necessary to introduce sth like:
pArea = hb_rddLockCurrentArea();
[...] // any RDD methods
hb_rddFreeArea( pArea );
hb_rddLockCurrentArea()/hb_rddLockArea(iArea) will increase
reference counter and hb_rddFreeArea() will decrease it.
non zero reference counter will delay releasing the pArea
structure until hb_rddFreeArea() will set it to 0.
Thank You. I though it could something like:
2010-03-15 14:04 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/src/rdd/dbfcdx/dbfcdx1.c
! fixed bad copy and past typo which could cause internal error when
new index using existing order (subindex) was created without
ADDITIVE
clause. Bug reported by Mindaugas - many thanks for the information.
because we found this bug in a similar way in the same project.
Not this time. We do not have any protection against closing WA
from any user code (i.e. key/for/filter/relation expressions or
from error handler) when it's used by RDD code :-(
Anyhow looking at your example I can see that one of them generates
internal error due to illegal value returned by error block.
This is also expected and Clipper compatible behavior.
Here is reduced example you can test also in Clipper:
PROC MAIN()
ErrorBlock( {|| NIL } )
BEGIN SEQUENCE
? array(0)[1]
END SEQUENCE
RETURN
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Error with hb_regex()
On Mon, 17 May 2010, Adam Lubszczyk wrote:
Hi!
I use Harbour compilator and library from MiniGui {compile also to console
mode}
Sorry but it may be problem with this build only so I cannot help you.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14511] trunk/harbour
On Mon, 17 May 2010, Mindaugas Kavaliauskas wrote: Hi, On 2010.05.17 14:37, dru...@users.sourceforge.net wrote: + added to C functions: int hb_dynsymToNum( PHB_DYNS pDynSym ); PHB_DYNS hb_dynsymFromNum( int iSymNum ); which can be used to make conversion between dynamic symbols and numbers It is interesting, what new code is behind this modifications? :) Remote function/method execution or that? :) Yes. I've wrote inproc OLE server for Harbour and it uses above functions to convert function/method/memvar symbols to DISPID in GetIDsOfNames() dispatch method and they are later converted back to symbols in Invoke() method. I've finished the code but I have no idea if it works or not. I've wrote everything using only documentation in the internet and haven't made any real life test so far so I do not want to make it public it yet. The idea is to create library which can be used by users to easy create own OLE servers. My current code should fully emulate the xHarbour.com ole server API: http://xharbour.com/index.asp?page=add_on_oleservershow_sub=7show_i=1 and this is one of the possible usage method. I also plan to add OLE wrappers to HBNETIO so users can use HBNETIO RPC from any other language which supports OLE, i.e. from Visual Basic or some .NET language. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Vouch32 - Under Harbour Contrib
On Mon, 17 May 2010, Pritpal Bedi wrote: Hi Pritpal, You may be familiar with Vouch32 library and its counterpart Vouch32 Active-X Server. If not please visit. http://www.vouchcac.com/vouch32/vouch32.htm A Free Windows Extended Utilities Library for Clipper, Xbase++ and (x)Harbour http://www.vouch32.com Home of Vouch32 ActiveX Server This famous library has been downloaded more than 9000+ times since 2003 so I believe it had been widely used. [...] Today, 17 May 2010, I have decided to put it under Harbour contribs. But I want to retain vouch32 folder name in harbour/contrib/vouch32. This is the only recognistion I need plus your willingness to polish the code. I would have certainly be happy to polish it but due to heavy involvement with hbQt+ direction, I cannot spare time onto that. Thank you very much for it. I think that many Harbour users will find your decision as really great. If group is willing I can start the process under harbour/contrib/vouch32. As Viktor suggested it's probably a lot of work to update such code to current Harbour contrib level so adding it as is to contrib may cause problems for next releases. Anyhow it's good to have this code close to Harbour so we have two choices: add it to harbour/examples/vouch (just like GTWVW) or create new SF project to host it. Also I wil pull-out CT3 compatible COM_* components as these are now available with Harbour anyway and also due to fact that I had contributed this library to xhb.com and my professional ethics do not permit so. Just for information only. Have you implemented COM_KEY(), COM_SKEY(), COM_EVENT() functions, lNoDelete in COM_READ() and additional parameters (2,3,4) in COM_OPEN()? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14511] trunk/harbour
On Mon, 17 May 2010, Mindaugas Kavaliauskas wrote: Hi, Yes. I've wrote inproc OLE server for Harbour and it uses above functions to convert function/method/memvar symbols to DISPID in GetIDsOfNames() dispatch method and they are later converted back to symbols in Invoke() method. I've finished the code but I have no idea if it works or not. I've wrote everything using only documentation in the internet and haven't made any real life test so far so I do not want to make it public it yet. Perhaps one of the most amazing things is how can you write software without testing!!! :) Usualy I can not write more than 30 lines of code without trying to run it. Probably each of us likes to tests the code anyhow in the past I had to create some bigger peaces of code without any way to make real tests until I finished nearly whole project and believe me it's possible. In this particular case the code is relatively small ~500 lines. The most amazing is the fact that I've just compiled it and executed using WinXP machine in my office and it works correctly without any modifications. I can compile the .PRG client and server example from xHarbour.com OLE server page. I only have to link at least one of components (server or client) statically because both linked dynamically with the same harbour.dll shares the same HVM so server fails inside hb_vmInit(). I can add protection against multiple HVM initialization anyhow using the same HVM for client and server code introduces interactions between them which do not use OLE API, i.e. they will use the same static variables. I'm interesting if it's possible to link both client and sever dynamically with xhbdll.dll using xHarbour.com. If yes and users need it then I can also emulate it. The idea is to create library which can be used by users to easy create own OLE servers. My current code should fully emulate the xHarbour.com ole server API: http://xharbour.com/index.asp?page=add_on_oleservershow_sub=7show_i=1 Very old time ago, after I've seen it. It looked a little strange to me. Why the whole application is presented as a single object? This allows to call all public functions from external code. I thought it is more common to create some Harbour level object and share it via OLE server, thus making methods and properties of OLE object to be methods and properties of Harbour object (instead of public functions and memvars of Harbour application). I also think that opening whole HVM is limited only to some rather small subset of possible applications and probably more restrictive servers which make public only some well defined set of methods using object or hash array will be more popular. But it's not my job to force how user will use it. The xHarbour.com compatible interface is only one of possible choices. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14511] trunk/harbour
On Mon, 17 May 2010, Szak�ts Viktor wrote: Hi Viktor, Very nice, count me to those who are eagerly awaiting it. (even if in not yet fully cooked state) Thank you. There are some things which should be added/modified in hbmk2. First is support for .def files. This is .def file I used to link inproc OLE server DLL: EXPORTS DllCanUnloadNow PRIVATE DllGetClassObjectPRIVATE DllUnregisterServer DllRegisterServer DllMain HBMK2 does not support .DEF files and I had to pass it using -dflag parameter: -dflag=olesrv.def but I discovered that HBMK2 ignores parameters specified with *flags=params if params does not start with - so I have to hack above -dflag parameter to: -dflag=-W olesrv.def Can you recognize .def files and pass them directly to linker? Why HBMK2 ignore -*flag=params if params does not start with - character? Can you eliminate this restruction? The next thing is building DLL and passing some link time parameters which are used with standalone EXE files. It would be nice if we can have an option to enable support for -gt and similar switches when -hbdyn option is used, i.e. this option can be extended to -hbdyn[vm] and -hbdynvm will enable support for startup options specified in .c temporary file used for normal executable files and also harbour core libraries in inked library list. If only -hbdyn is used then Harbour libraries should nor be linked by default. Do you think it possible to add it? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Vouch32 - Under Harbour Contrib
On Mon, 17 May 2010, Pritpal Bedi wrote: Hi, Just for information only. Have you implemented COM_KEY(), COM_SKEY(), COM_EVENT() functions, lNoDelete in COM_READ() and additional parameters (2,3,4) in COM_OPEN()? Com_Key() = No Com_SKey() = No Com_Event() = No The all three functions need Overlapped and asynchronous CreateFile() protocol, which at that times, I was not able to handle. Com_Read( nPort, nBytesToRead, lNoDelete ) = No Again this can only be possible with asynchronous and overlapped structures. COM_OPEN(nComPort,nBufferIn,nBufferOut, [lTrapMode]) -- lStatus nBufferIn, nBufferOut = YES lTrapMode = NO nBufferIn, nBufferOut as: if valtype( nInBuffer ) == 'N' DEFAULT nOutBuffer TO 1024 if !SetupComm( nHandle, nInBuffer, nOutBuffer ) CloseHandle( nHandle ) return .f. endif endif Thank you very much. This is exactly what I expected and it's in practice the same as in the code I committed. I only haven't added support for nBufferIn and nBufferOut because only MS-Windows support it and it's not clear how it effect low level serial driver. Anyhow I'll think about adding it in the future. BTW does anyone know the default size of serial IO buffers in MS-Windows? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14515] trunk/harbour
On Tue, 18 May 2010, vszak...@users.sourceforge.net wrote: Hi, 2010-05-18 02:25 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.pt_BR.po * utils/hbmk2/hbmk2.hu_HU.po * utils/hbmk2/hbmk2.prg + Added experimental -hbdynvm mode. + Added support for .def input file in -hbdyn/-hbdynvm modes. Thank you very much. I'll check it tomorrow. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] tipclientsmtp problem with MT
On Sat, 15 May 2010, Fernando Athayde wrote: Hi, i try your suggestion port 587 now on 2 examples not runs return .F. strange with port 465 runs fine without MT, but with MT dont´t run well i think there is a problem with kernel mt of harbour I do not think so. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: [Harbour] tipclientsmtp problem with MT
On Sat, 15 May 2010, Fernando Athayde wrote: Hi, Przemek, i was think, may be problem is the multithread support of openssl dll´s i was trying build openssl, but without success If non HVM thread tries to access HVM, i.e. to execute some .prg code then it simply GPF so I do not think it's the source o your problem. but if you test gmail.prg with -MT you´ll see the problem Both MT and ST versions returns .T. so they seem to work but valgrind produces for both of them 285KB log with 336 errors: Conditional jump or move depends on uninitialised value(s) inside low level SSL code so there is sth wrong with SSL library or rather with Harbour wrapper to this library (hbssl) and this may cause any unpredictable results depending on values in uninitialised memory. Probably in your MT builds this memory contains data which breaks communication process. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: Res: [Harbour] tipclientsmtp problem with MT
On Sat, 15 May 2010, Fernando Athayde wrote: bur Przemek look this: [...] Don't you understand the results are in practice random due to uninitialized memory? You have .T. for ST and .F. for MT. I have .T. for both modes. Someone else can have .F. for ST and .T. for MT. It doesn't change anything and it does not give any valuable information. Conditional jump which depends on uninitialized memory means that all possible combinations can appear in some situations. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: Res: [Harbour] tipclientsmtp problem with MT
On Sat, 15 May 2010, Szak�ts Viktor wrote: Hi, It's possible (and should fixed, just not by my eyes), but my suspect in this case is an MT requirement of OpenSSL, which isn't satisfied in hbssl. Yes, but it's important only for concurrent access. It does not change anything when only single thread access SSL code like in gmail.prg so for sure it cannot be source of the problem. See here: http://books.google.hu/books?id=FBYHEBTrZUwCpg=PA74lpg=PA74dq=OPENSSL+multithreadsource=blots=Am7l5e1yJLsig=r7QaLIfah-KE8lQDx4RbSXVPPJIhl=enei=btbuS_vZI-STOO7C8fYHsa=Xoi=book_resultct=resultresnum=8ved=0CDAQ6AEwBw#v=onepageq=OPENSSL%20multithreadf=false I tried, but couldn't adapt the code to Harbour threading API. Seems that it can be done quite easy. I'll look at it in next week but it's completely different thing not related to Fernando problem which probably should be resolved before so we can add some concurrent access tests. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] :__enumKey()
On Wed, 12 May 2010, Mindaugas Kavaliauskas wrote:
Hi,
perhaps this is a known issue, but looks like a strange limitation
of __enumKey() message. This code could not be compiled because of:
test202.prg(5) Warning W0031 Invalid variable 'XVALUE' for
enumerator message
FUNC main()
LOCAL xValue
FOR EACH xValue IN {'a'='A', 'b'='B'}
? xValue:__enumKey()
? EVAL({|| xValue:__enumKey()})
NEXT
RETURN NIL
It's intentional. You cannot eat cake and have cake ;-)
Most of people (at least those who asked about it in the past) prefer
that codeblocks detach enumerated values not enumerators itself.
This example illustrate it:
FUNC main()
LOCAL xValue, aCode := {}
FOR EACH xValue IN {'a'='A', 'b'='B'}
AADD( aCode, {|| xValue } )
NEXT
AEVAL( aCode, { |x| QOUT( EVAL( x ) ) } )
RETURN NIL
and for such behavior the above warning is correct.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF Bug tracker#3001388: HB_SPINLOCK_TRY !x86 typo
On Fri, 14 May 2010, Chen Kedem wrote: Hi, The following was posted on our SF bug tracker: http://sourceforge.net/tracker/?func=detailatid=100681aid=3001388group_id=681 Anonymous wrote: There is a typo in this macro, prevents building on ppc. And there is a patch attached to that report. Can someone please take a look? Thanks for the info. Fixed 2010-05-14 15:12 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about Preprocessor 2
On Thu, 13 May 2010, CarozoDeQuilmes wrote:
Hi,
Hi, I have an little question:
This translate:
#xtranslate value1.value2 = myFun( value1 , value2 )
function main()
aeval( aTmp , { *|x|* level1.level2 } )
return .T.
It will be generate the followed sentence:
function main()
aeval( aTmp , { myFun( *|x|* level1 , level2 ) } )
return .T.
I think that it is wrong
I think the correct translation should be:
function main()
aeval( aTmp , { *|x|* myFun( level1 , level2 ) } )
return .T.
Am I wrong?
Yes you are ;-)
You want that PP will respect some operator precedence which
is only in your head but PP does not even know anything about
operator precedence and syntax in Clipper/Harbour language.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about Preprocessor
On Tue, 11 May 2010, CarozoDeQuilmes wrote: Hi, Hi, when I put the following #translate in my program always convert the parameter myparm to literal myparm. It is good for me. The question is: how make it in reverse ? (convert literal or variable to variable) PP does not support nested parsing string tokens, i.e. it cannot convert: QOUT(1) to: QOUT ( 1 ) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
On Wed, 12 May 2010, Massimo Belgrano wrote: Hi Massimo, About an idea of completely different implementation of pragma I want remember that xbase++ support an intersting preprocessor directive #pragma library (mylib.lib) Is possible implement also in harbour for minigw? or at least adapt something like #pragma BEGINDUMP #pragma comment( lib, mylib.lib ) #pragma ENDDUMP This is not portable extension. I can implement it inside PP but it will not change the fact that most of C compilers/platforms used by Harbour do not support storing library references inside .o|.obj files so it will not work. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error with hb_regex()
On Thu, 13 May 2010, Adam Lubszczyk wrote: Hi, If used in procedur any function of HB_REGEX..() it work OK, but when return from procedur application GPF. [...] Called from TEST(16) in test.prg Called from MAIN(2) in test.prg Compile with BCC551 on Windows98SE I cannot confirm it. It works as expected without any problems. I tested Linux GCC and win BCC and MinGW builds. Maybe you are using some incompatible PCRE library or you wrongly linked your code with old PCRE lib which is part of BCC CRTL. Have you used HBMK2 to compile and link your code? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14461] trunk/harbour
On Wed, 12 May 2010, Szak�ts Viktor wrote: Hi Viktor, 2010-05-12 02:26 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbct/dummy.c * removed dummy CT3 serial communication functions ; such files with dummy functions introduces very serious problems for user code because they do not respect original module granularity effectively breaking overloading only chosen functions so it breaks also some real Clipper code. This file is not included in hbct library, so it won't cause any such harm. It's mere a place where we can track what's implemented and what's not. Thank you for the information. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14461] trunk/harbour
On Wed, 12 May 2010, Chen Kedem wrote:
Hi Chen,
What is the different between this and the functions we have in
contrib/hbtpathy?
hbtpathy supports only small subset of hbcom functionality, i.e.
such important things like hardware/software flow control or DTR/RTS
flags cannot be controlled by user in hbtpathy.
After verification of the new HBCOM code probably we can quite easy
tune and extend HBTPATHY code by replacing its current low level code
with HBCOM.
OS2 builds:
- discard card is not supported
Is this the character to place when erroneous data is received?
No. It's character which can be used to erase recive buffer by remote
station.
I don't have original OS/2 headers, but in my (VERY) old OS/2 program
I had this working:
typedef struct
{
WORDwrite_tmo ;/* Write timeout in 10 ms ( 0 - 10, 1 - 20 )
*/
WORDread_tmo ;/* Read timeout in 10 ms ( 0 - 10, 1 - 20 )
*/
BYTEflag1 ;
BYTEflag2 ;
BYTEflag3 ;
BYTEerr_rep;
BYTEbrk_rep;
BYTExon_char ;
BYTExoff_char ;
} DCBINFO ;
DCBINFO dcb ; /* Device control block information */
/* ... after port is opened */
if ( !(nErr = DOSDEVIOCTL ((BYTE far*) dcb, NULL, 0x73, 1,
pSio-shandle)))
{
dcb.read_tmo = zcom_readtmo ; /* 10 ms */
dcb.write_tmo = zcom_writetmo ; /* 10 ms */
dcb.flag1 = 0 ;
dcb.flag2 = 4|8 ;/* Error repl | 0-stripp */
dcb.flag3 = 2 ;/* Timeout proceccing bits */
dcb.err_rep = 'X';/* Error replace char */
dcb.brk_rep = 0 ;/* Break replace char */
if ( !(nErr = DOSDEVIOCTL (NULL, (BYTE far*) dcb, 0x53, 1,
pSio-shandle)))
{
/* set baud and other staff ... */
}
}
Thank you very much.
Current hbcom code already uses DCBINFO in OS2 builds to set different
hardware and software flow controls, error char, break char, XON/XOFF
chars, read/write timeouts, etc.
Anyhow I do not find in OS2 API documentation anything what can be used
to simulate remote erase char functionality.
It can be emulated by us inside read code by simple reading data to our
own buffer and then looking for erase char but it creates additional
overhead so I do not want to make it if it's not strictly necessary for
users. Anyhow such implementation also adds support for lNoDelete
parameter in COM_READ() (see the ChangeLog) so maybe I'll add it in the
future though in such case I'll try to move this part of code to CTCOM
to not introduce such hacks to general HBCOM library.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
On Tue, 11 May 2010, Szak�ts Viktor wrote: Hi, Then I searched the sources for #pragma directives. Because I am not the author of those sources, I never knew that multiple #pragma directives were in use. And that was the potential reason to get thousands of warnings which ultimately was killing the process. So this was the problem. I hope Przemek can take an expert look on this issue, as I'm sure it's not intentional that such options are changing across sources. F.e. this causes unpredictable results for anyone using 'harbour *.prg' on a *nix system f.e. These pragmas are meant to be per file. It was intentional. At least it was strictly necessary in the past when we haven't full support for .CLP files in Harbour compiler and additional modules included from .CLP files or by DO command where compiled just like any other .prg files specified in the command line so we have to fully replicate Clipper logic in few different places, i.e. PP should reset newly added user rules but should keep modifications in standard rules, i.e. if you make #undef _SET_CONSOLE in 1-st .prg module then _SET_CONSOLE is not visible also in the next ones. But if you add: #define MY_SET then MY_SET is reset before new module is compiled. After: 2009-09-02 14:08 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) we can exclude from above scenario .prg files passed in command line and make full compiler reset (in practice it means that we will have to deallocate nearly everything and allocate and initialize everything from scratch again) but before you change it please make some tests with Clipper to not break current behavior for @name.clp files and SET PROCEDURE TO ... / DO ... [ WITH ... ] statements. If you make some experiments with -D parameter then you will find also some other interesting things in Clipper. Some of them looks like bugs. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Slow create index under threads
Hi, The time of creating very long index is mostly reduced by disk IO. In systems like MS-Windows it can be performance killer due the very inefficients method of buffer flushing. Creating more threads for simultaneous indexing only increases the problem becaue it increase number of non linear buffer flushing dividing the available cache memory to many threads so it's technical nonsense. Please forget about it. It may help only if nearly whole operation is done in memory. If you want to really reduce the time of indexing then you have to reduce disk IO usage. The easiest method is migrating to system which manage IO operation better and using server with big number of memory so the whole operation can be done with very small disk IO usage. For test you can try to use some new Linux distro with EXT4 with enabled delayed write operation. If you have to keep existing OS then you can try to increase the memory used by Harbour RDD driver for buffers during indexing. In src/rdd/dbfcd/dbfcdx1.c[9191] I described how DBFCDX allocates memory. As you can see in the comment it should not allocate more then 35Mb memory. For modern computers such memory block seems to be quite small so you can try to increase it, i.e. to 256MB. In line 9167: ulSize = ( 1L 20 ) / ( iLen + 4 ); change the default memory block size, i.e.: ulSize = ( 1L 27 ) / ( iLen + 4 ); recompile DBFCDX (all whole Harbour) and make speed tests. Please only remember to not execute any other processes or threads during indexing because it may cause that your indexing process will not have access to physical memory and swap will be used what can completely kill the performance. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
On Wed, 12 May 2010, Szak�ts Viktor wrote: Hi Viktor, My only concern is #pragmas. Here compatibility doesn't apply as Clipper didn't have them. Do you think it can be fixed to reset the #pragma settings to initial state after compiling each separate source file? Probably yes but this sentence suggests that you want to not only hack one reported by user problem. I thought that you want to introduce full separation of compiled PRG modules specified at command line so hbmk2 which now passed all prg modules to harbour compiler in single call can be safely used without any interactions between compiled files. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
On Wed, 12 May 2010, Szak�ts Viktor wrote: Hi Viktor, I thought that you want to introduce full separation of compiled PRG modules specified at command line so hbmk2 which now passed all prg modules to harbour compiler in single call can be safely used without any interactions between compiled files. Not to hack, but solve. IMO #pragma settings and macros are two different issues, though for me it's not a problem to handle them together and come up with a fuller solution. The only problem is that I can't really add any valuable input to the macro side. My only slight, and maybe not justified concern is that if we reset everything between files, it may cause a performance hit compared to current state, at least it looked like so by reading your prev mail. IOW, I don't know how much do we want to complicate this and introduce undesired side-effects, other than that a full solution is always a good thing. the #pragma low level behavior strictly depends on current compiler implementation. It may change in the future or may need some completely different implementation for modified compiler code so it should not be sth what we can define as strict part of language because we can block farther modifications, i.e. current behavior of -km switch needs online PCODE generation, if we add support for multiline expressions to intorduce interline optimizations on expression level (now we only have them in very limited way operating on generated PCODE) then this switch will stop to work and to implement it we will have to make some deeper compiler modifications and decide what is the expected behavior for code generated for merged lines when some of them were compiled with and some other without -m optimization. Some other pragmas effects only some chosen compiler phases and it's less important where they are located in the source code, i.e jump optimization (-kj) is executed after compiling whole function in PCODE generated for full function body. In the future we may introduce inter procedural optimization or even inter module optimizations. It means that we may have pragmas with such scope so there is no clear solution that we can reset all pragams between modules. Now some pragmas has effect only on newly compiled modules, i.e. -n. If we add resetting for all pragmas then support for -n does not make any sense and should be removed. If you want the we can add such resetting but in such case we should start from updating current list of programs to check which are usable in such case (I hope that so far no one used current functionality using files with compiler pragma settings without real code to control switches between compiled modules). Anyhow I would like to note that this may change in the future and such functionality cannot be sth what may block farther compiler optimizations. The cost of resetting PP should be acceptable if user does not use -u harbour compiler switch with his own long list of PP directives in .ch file. Parsing such .ch file for each .prg module for sure will be noticeable in the total compilation time. BTW we can also introduce #pragma push/pop which can be used by user to resolve the problem of interaction between compiler switches in much more flexible way. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14461] trunk/harbour
On Wed, 12 May 2010, Mindaugas Kavaliauskas wrote: Hi, I has a code that seems does not fit under the new code. I have a simple button (well, there is a RS-latch to avoid contact bouncing) and I need to record time when the button is pressed. Button is connected to DSR (or CTS), so I need some way to monitor this register and obtain some kind of interrupt on delta DSR (or CTS). I do this using SetCommMask() and WaitCommEvent() under Win32. Is it possible to have some multiplatform way to get this functionality? I'm afraid it will be hard to implement it for all platforms. It needs direct hardware access to set interrupt on DSR (or CTS) line modification or at least method to access delta DSR (or CTS) bit from MSR. In the code I sent only in OS2 builds DELTA MSR bits are supported. In *nixes there is no portable way to access them. I haven't implemented ir for windows too because WaitCommEvent() is blocking function (at least in the documentation) for non overlapped handles and I do not know any other method to read all MSR bits. I can add some type of wrapper for WaitCommEvent() to new code but it will work only in MS-Windows, in DOS builds if we have it and maybe in OS2 ones but I had to read OS2 documentation to give precise answer. I do not see any way to make implement it for POSIX systems using termios. Such extension had to be implemented in non standard way sometimes even using root privileges. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14461] trunk/harbour
On Wed, 12 May 2010, Mindaugas Kavaliauskas wrote: Hi, On 2010.05.12 16:21, Mindaugas Kavaliauskas wrote: I've very surprised :( I expected to be some way to wait for line change event in POSIX/UNIX/Linux. I just guessed that there is a way to make line change to emit error condition, ex., ioctl(fd, TIO_ERROR_ON_CHANGE, TIO_DSR)); Looking to Wine source I found some text about TIOCMIWAIT, the sad part of story is that it says: TIOCMIWAIT is not adequate and Wine uses 10ms pooling to emulate Windows behaviour, see: dlls/ntdll/serial.c:wait_for_event() Thanks for the hint, I'll look at it. Google finds some samples of code that implements ioctl( fd, TIOCMIWAIT, wait_mask ), ex.: http://www.linuxquestions.org/questions/programming-9/serial-port-programming-285597/ http://www.dslreports.com/forum/r21801613-Linux-Interrupt-based-on-serial-port-pin The main problem with TIOCMIWAIT is that it does not respect modifications on inspected lines which appeared before you called this function. In some protocols it may even cause deadlock because you can freeze application waiting for event which come just before you called TIOCMIWAIT. Anyhow if it's acceptable then it can be used though it's also not well portable extension. It should work with modern Linux kernels though I do not know if all TTY devices supports it. For sure standard RS-232 serial ports should. I'll think about it and also about adding some other extensions which probably exists only in Linux, i.e. TIOCM_OUT1/TIOCM_OUT2/ TIOCM_LOOP or TIOCSERGETLSR. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Slow create index under threads
On Wed, 12 May 2010, Maurilio Longo wrote: Hi, Przemysław Czerpak wrote: If you have to keep existing OS then you can try to increase the memory used by Harbour RDD driver for buffers during indexing. In src/rdd/dbfcd/dbfcdx1.c[9191] I described how DBFCDX allocates memory. As you can see in the comment it should not allocate more then 35Mb memory. For modern computers such memory block seems to be quite small so you can try to increase it, i.e. to 256MB. In line 9167: ulSize = ( 1L 20 ) / ( iLen + 4 ); change the default memory block size, i.e.: ulSize = ( 1L 27 ) / ( iLen + 4 ); recompile DBFCDX (all whole Harbour) and make speed tests. What about a runtime Set() option and/or have the default using more memory? Todays pc should be able to handle 256Mb buffers without problems. You never know how much memory other processes may need so allocating too big memory blocks may cause problems for programs executed when other programs with hi memory consumption are running. Ideal situation is when OS can manage effectively write buffers. As alternative we can add runtime switch as you suggested to control the maximum size of allocated memory so user can tune it for the used environment but increasing the default settings may not be good idea even due to possible bad interactions in multiprocess environment. best regards, Przemek ps. can you check OS2 hbcom builds? ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
On Wed, 12 May 2010, Pritpal Bedi wrote:
Hi Pritpal,
I thought that you want to introduce full separation of compiled
the #pragma low level behavior strictly depends on
current compiler implementation. It may change in
My current requirement is to just get rid of the unresolved
external _errno which is called in ppcore.c in pp.lib in xHarbour
of year 2007 October.
Looking at your message I can only say to you mixed C source code
compiled with and without MT BCC switches. Looks that BCC generates
incompatible code for both modes and they cannot be mixed to create
final binaries.
You have to decide which mode you want to use and recompile xHarbour
core code and your own project with the same MT switches. The problem
is exploited at link time so different CRTLs are used for MT and ST
mode. If BCC does not set automatically library dependencies in .obj
files then you will have to inform linker about valid RTL.
In BCC32.EXE -tWM switch is used to enable MT mode. If you link your
application using BCC32.EXE too then such switch used during compile
and link time is enough. If you are using ILINK32.EXE then probably
you will have to set valid CRTL library manually. cw32mt.lib is MT
safe CRTL which should be used for code compiled with -tWM BCC switch
and cw32.lib is ST CRTL.
I have tweaked hbMK2 ( my local copy ) to send PRG sources
to harbour.exe one-by-one and is sufficient to cover all discussed
above, though I would like to see this happen in a proper manner
in Harbour.
Because this project has to be compiled with older xHarbour which
I wanted to do so through hbIDE, and where I think we will not be
touching the compiler code at all, I am looking for some out of the
compiler code solution.
Important is only using valid MT compile and link time switches
for xHarbour core code and your own code. Please remember that
some problems may not be exploited at link time as the errno you
reported and only not fully functional binaries are created.
Probably the xHarbour code you are using was compiled without
-tWM flag. In such case you should force ST mode in HBMK2 too
probably by disabling -tWM BCC compile time switch and changing
in linker command CW32MT to CW32. I do not know if BCC support
opposite to -tWM switch which can disable -tWM used before and
if HBMK2 recognize it and updates default library list passed
to ILINK32.EXE. Probably not.
Alternatively you can recompile whole xHarbour code with -tWM
but it may also force some modifications in xHarbour makefile.bc
to enable MT safe CRTL at link time without setting HB_MT. This
is probably the safest way because allows to use non HVM MT code
using CRTL in final application.
In one of my prgs I am calling this code:
[...]
Maybe this code is the culprit. May be I
need to do it somehow differently. The above
code belongs to CacheRDD I developed on top of UsrRDD.
I tried to introduce
int errno()
{
return 0;
}
but other type of warnings are there, so I believe this is
not the solution.
Any help is appreciated.
I am really struck at this.
It's completely unimportant which code exploited the problem in
visible way. Important is only that you are mixing files compiled
for ST and MT mode (with and without -tWM flag) during linking
final application and this is the source of your problem.
All what you have to do is eliminating it.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
On Wed, 12 May 2010, Pritpal Bedi wrote: Hi, It's completely unimportant which code exploited the problem in visible way. Important is only that you are mixing files compiled for ST and MT mode (with and without -tWM flag) during linking final application and this is the source of your problem. All what you have to do is eliminating it. This is probably the _REAL_ cause. I have checked, if not otherwise nullified, even if -st flag is sent to hbMK2, it always compiles C code as : bcc32.exe -c -q -tWM -d -6 -O2 -OS -Ov -Oi -Oc -w -Q -w-sig- -nE:\dev_hbmk\xharbour\obj\cacherdd -IC:\xharbour\include -ID:\Projects\CacheRDD\Include E:\dev_hbmk\xharbour\obj\cacherdd\CacheRDD.c and in link script cw32mt.lib is visible. So I need to wait till Viktor's response. I've just check HBMK2 code and I do not know if Viktor can help you much. In fact the problem is that xHarbour uses different switches for MT and ST libraries and not all core libraries are compiled for MT mode. It means that all xHarbour MT BCC binaries are potentially broken because they contains code compiled for MT and ST mode. Such things cannot be fixed by HBMK2. You simply need xHarbour binaries fully recompiled with -tWN. Otherwise it may not be safe to create any MT application. Anyhow if you do not need any MT code and you are creating only ST applications then it should be enough to add some switch to HBMK2 which will force ST in BCC compiler and linker but only in XHB compatibility mode. Harbour is correctly compiled and linked in MT safe mode so Viktor cannot use -st switch for it because it would break correctly compiled Harbour and xHarbour binaries. It has to be sth different, i.e. -xhb switch can be extended to -xhb[st]. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
On Wed, 12 May 2010, Pritpal Bedi wrote: Hi, xMate compiles the same source as: [1]:Bcc32.Exe -D__xDEVELOPMENT__ -D__xCACHE2009__ -D -d -5 -6 -a8 -c -O2 -tW -DHB_FM_STATISTICS_OFF -DHB_NO_DEFAULT_API_MACROS -DHB_NO_DEFAULT_STACK_MACROS -DHB_OS_WIN_32 -IInclude -IC:\Dev\BCC55\Include;c:\xHarbour\Include -nObj Obj\CacheRDD.c Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland obj\cacherdd.c: Here it is only -tW instead of -tWM. So it does not generate MT safe code and cannot be used for MT applications. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
On Wed, 12 May 2010, Szak�ts Viktor wrote: Is it not enough to select between -tWM / cw32mt and -tW / cw32 based on the -st/-mt flag when in -xhb mode? As I said it will break user custom builds which use -tWM flag to compile whole xHarbour code. Such users will have to use -mt HBMK2 switch what will force MT version of xHarbour HVM and some other libraries what will exploit many other problems you do not want to even hear about ;-) Anyhow for default xHb build time switches it should be enough to create binaries without compile and link time errors though as I said the MT ones are potentially broken. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] com on darwin
On Thu, 13 May 2010, Szak�ts Viktor wrote: Hi, I'm seeing this in hbcom.c: --- # elif defined( HB_OS_DARWIN ) hb_snprintf( buffer, size, /dev/cuaa%d, pCom-port - 1 ); --- Above is only default value. and these are the /dev/cu* files on my Snow Leopard: --- ~$ ls -l /dev/cu* crw-rw-rw- 1 root wheel 11, 7 4 May 20:22 /dev/cu.Bluetooth-Modem crw-rw-rw- 1 root wheel 11, 3 4 May 20:22 /dev/cu.Bluetooth-PDA-Sync crw-rw-rw- 1 root wheel 11, 1 4 May 20:22 /dev/cu.vszakats_6230i-COM1-1 crw-rw-rw- 1 root wheel 11, 5 4 May 20:22 /dev/cu.vszakats_6230i-COM1-2 --- New com interface expects a number to select the com port, but here they are named. How can they be opened? COM_DEVNAME( 1, /dev/cu.Bluetooth-Mode ) COM_DEVNAME( 2, /dev/cu.Bluetooth-PDA-Sync ) COM_DEVNAME( 3, /dev/cu.vszakats_6230i-COM1-1 ) COM_DEVNAME( 4, /dev/cu.vszakats_6230i-COM1-2 ) COM_OPEN( 1 ) COM_INIT( 1, ... ) COM_OPEN( 2 ) COM_INIT( 1, ... ) [...] best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14412] trunk/harbour
On Wed, 05 May 2010, Szak�ts Viktor wrote: Hi Viktor, In the 4 working days of live testing the GPFs seem to have disappeared and I got no crash reports from users either. Thank you for the information. Let me know if you find any problems. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14415] trunk/harbour
On Fri, 30 Apr 2010, Mindaugas Kavaliauskas wrote: Hi, In case of item stream, received items are buffered on client side and NETIO_GETDATA() return array of items. In case of char stream, data is concatenated and NETIO_GETDATA() return a single stream. Function NETIO_GETDATA() is not blocking function and returns NIL if no data are received. Am I right? Yes you area. You've mentioned in the past, that these communication streams allows server application to give access to local resources like COM ports, etc. In most cases, f.e. COM port, communication is bidirectional, but I found communication stream unidirectional (from server to client). How do you suggest to do data transfer in the opposite direction? Just use standard RPC calls to set COM port parameters and send data and communication streams to receive incoming data. The streams are unidirectional only because standard RPC allows to send data from client to server. In the sample code, the communication streams are closed after NETIO_DISCONNECT(). Is data transfer allowed in between of NETIO_DISCONNECT() and NETIO_CLOSESTREAM() calls? Each NETIO_CONNECT() increase reference counter in given connection and needs corresponding number of NETIO_DISCONNECT(). Each file open as net:* also increase the reference counter which is decreased when file is closed. Opening 1-st stream connection increase the reference counter too and it's decreased when all streams in given connection are closed. The order of executed command is unimportant here. The connection is closed when the reference counter reach 0. Are connection stream ids unique among multiple connection? As far as I can see, each connection has it's own connection ideas, and this requires to use additional cServer and nPort parameters to distinguish different connections. NETIO tries to reuse existing connection looking in open connections for the connection which has the same server and port number and if such connection exists then it's used and reference counter is increased. Otherwise new connection is created. I see s_fileGetConnParam(), hb_socketResolveAddr(), s_fileConFind() in NETIO_GETDATA(). Isn't this a bottleneck for applications what needs a lot of data transfers? The same question for RPC calls. Probably only hb_socketResolveAddr() may cause noticeable speed overhead and here it's really better to use IP addresses to not activate DNS connection. Probably I should eliminate it adding support for pointer item with connection reference which can be used as 1-st parameter of RPC calls and connection streams. I'll think about it. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] netiotst.prg
On Mon, 03 May 2010, Alex Strickland wrote: Hi When testing netio using netiotst.prg I inadvertently caused this error by editing the browse. Error DBFCDX/1022 Lock required══ Called from FIELDPUT(0) Called from (b)FIELDBLOCK(0) Called from DOGET(0) Called from BROWSE(0) Called from TESTDB(129) Called from MAIN(60) This is expected. The table is open in shared mode and BRWOSE() just like in Clipper does not have any locking code. Error NETIO/1003 Read error: hb_stackInit (DOS Error 15) Error NETIO/1002 Write error: hb_stackInit (DOS Error 15) Error NETIO/1002 Write error: hb_stackInit (DOS Error 15) C:\Users\Alex\ECR7.0\tests\hbnetio\tests Can someone tell me why does hb_stackInit appear in the NETIO messages? And why DOS Error 15 (Invalid drive was specified)? It's also expected. In this case you have server and client code executed by the same application in different threads. The main thread of this application was terminated by above RT error. Because it was the main thread then after terminate signal was send also to all other threads and server was also terminated. Depending on the order of task switching in your system it's possible that thread with the server is finished earlier then clean up code in threads with client code which is closing all used workareas and it was happen in your case. It causes that the client code generated above RT errors just after leaving all your PRG functions - hb_stackInit is the 1-st function pushed on HVM stack which is reported as execution context when no other PRG code is evaluated. When communication errors appears NETIO subsystem as OS error codes uses HB_SOCKET_ERR_* values defined in hbsocket.ch and 15 means HB_SOCKET_ERR_CONNABORTED what is correct value which well describes the reason of RTE. So all is correct and reported as expected. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
On Mon, 03 May 2010, Heinz V Bergen wrote: Hi, OK, using latest Harbour (r14422) and did a mingw32-make clean install, then recompiled my app with hbmk2 as console app, no GTs and tested, still got error. When Windows dialog to send error report, I clicked on debug window opening VS2005 debugger, showed error in disassembled code as Unhandled exception at 0x0041f2a3 in Hb2Ftr.exe: 0xC005: Access violation reading location 0x000d, in case this helps? [...] -recompiled my app with Harbour release 2.0 and tested, had no errors. Clipper also has no errors. -tryed various combinations and discovered issue is caused by latest HBMK2, as using HBMK2 from Version 2.0 distro, copying it to with latest SVN Harbour\Bin, rebuild app, test and appears to run fine with no more errors, does that make sense? Can you send here the body of function which creates this problem? If possible please try to reduce it removing all code which can be deleted and the error is still generated. HBMK2 is linked with Harbour compiler library and such errors can be caused by wrong code generated by compiler. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour random GPFs
On Tue, 04 May 2010, Heinz V Bergen wrote: Hi, Error occurs on the Return() of the function and all processes within were completed successfully. The function creates Directories, copies files, creates an FTP script, calls external RUN to PkZip and FTP and then erases files and removes directories, thought maybe RUN calls were the culprit, so I have bypassed PKZIP and FTP calls, just replacing with Copy File so process can continue, and error still occurs. Not sure if posting function in a usable form will be possible, but I will continue trying to narrow it down and see if I can come up with something. One item of note though, is that the latest SVN hbmk2 and release 2.0 hbmk2 do create different application EXE sizes. I know that the error appears on RETURN but it means that somewhere earlier some value was wrongly removed from HVM stack. It can be _any_ PRG construction executed before the RETURN statement. If you can remove some code from your function then it may help to locate the place where is the critical code which is the reason of problem. You can also send this function to me and maybe I'll be able to find the problem without code reduction only looking at PRG constructions used by you. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Error in hbide right click on editor tab
On Tue, 04 May 2010, Szak�ts Viktor wrote: Hi, I still cannot see why f.e. you cannot update to the latest version, if it is important for you. Let's say that there are some problems with current xHarbour code and there is a chance that they will be exploited by such update. Anyway, you can simply create a dummy lib as Massimo suggested and get around the problem once and for all. or simply copy dbfntx as dbfnsx. This seems to be the easiest solution. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
On Thu, 29 Apr 2010, Szak�ts Viktor wrote: Hi, If that simplifies things (which it definitely does), and the majority of developers agree with it, we can drop non-UNICODE mode altogether from Harbour source code. It's unlikely we shall ever support Windows 3.x or Win32s, and unicows solution works just perfect now to cover Win9x/ME host versions, so I can see no hard reason to maintain duplicate code paths for both UNICODE and non-UNICODE Windows API support. Having only UNICODE path could greatly simplify code in many crucial points, making it easier to maintain, extend, debug and keep bug free. Especially if we want to move towards internal (HVM) unicode support in the future. I would like to keep support for non unicode windows builds. I do not see anything what give noticeable simplification in Harbour core code because we will still have to keep support for other platforms which do not use unicode. For me native Win9x support is as important as WinCE port and I want to be able to create application which can be executed on Win9x without any overhead due to dummy emulation layer and I do not plan to fight with any more or less important problems or incompatibilities in libunicows and look for workarounds or send patches to the authors. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi Viktor, Sorry but I do not understand why do you want to delete already working code. In longer terms it may cause that we will create problems for platform which do not use Unicode forcing Unicode everywhere reducing Harbour functionality to current Java or Phyton level. For me it will be end of this project. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] International characters next
On Tue, 27 Apr 2010, Siny wrote: Hi, I set the codepage succesfully. There are correct characters on the screen and on the keyboard, too. But... The seek do not works when the string certains a Hungarian character. I think that there are old-coded characters in the databases. So you haven't set CP correctly. Copy past from examples sent by other users without investing sometime to check what some functions do is not good idea because like above you resolved one problem creating other ones. Do anyone know a tool which can change this characters in databases into a given type? For example into iso852 or unicode852. And I am interesting in it regardin to changing soure code automatically You have to understand what different CP functions do before you will use them and you will find that you can set all what you need in few different versions. SET( _SET_CODEPAGE, cCDP ) - cPrevCDP sets internal HVM codepage which is used in string comparison operation functions like UPPER()/LOWER()/ISALPHA()/ISUPPER()/ISLOWER()/ISDIGIT()/... and also as default CP for RDD when new table is open and for GT in HB_SETTERMCP()/HB_SETDISPCP()/HB_SETKEYCP(). Some GTs also use it even without calling above functions. HB_CDPSELECT(...) makes the same job as SET( _SET_CODEPAGE, ... ). HB_SETTERMCP( cTermCP [,cHostCP] [,lBoxChar] ) Sets terminal CP and enables automatic translation between cHostCP (HVM CDP) and cTermCP in all IN (keyboard) / OUT (screen) operations. If lBoxChar is .T. then it forces using national letters also in box drawing effectively disabling using CP437 box characters in DISPBOX() and related functions. HB_SETDISPCP() sets only output (screen) translation and HB_SETKEYCP() sets only input (keyboard) translation. When new table is open then you can use CODEPAGE clause in USE command to enable automatic translation between HVM code, i.e.: USE myTable CODEPAGE cCDP It also controls collating order but please remember that it cannot be used if table contains binary data. If you want to avoid such problems then you should use the same HVM CP as your tables. So you can specify CODEPAGE in USE command (or as 7-th parameter of dbUseArea() function) but you can also set the same CP as you used in your Clipper/... programs and which is used by your DBF files using SET( _SET_CODEPAGE, cCDP ) or HB_CDPSELECT( cCDP ) and only set valid output CP using HB_SETTERMCP(). In UNICDOE Harbour builds is enough to make: SET( _SET_CODEPAGE, cCDP ) HB_SETTERMCP( cTermCDP, cCDP ) HTH best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: CLASSES - Instance Variable as Object - Access/Assign Elsewhere
On Fri, 23 Apr 2010, Pritpal Bedi wrote: Hi, Tell me why my application running absolutely fine with BCC, MSVC till 15 Mar 2010 stopped on one feature after that. Without changing anything in other code ? Because the bugs was not exploited so far. A classic example of long term problems which used to appear when the code is not written to be safe in all possible cases and generate RTE in some abnormal conditions but never GPF. If code is not written in such way then you have to accept that changing a color of some text printed in completely different part of application may cause global crash because it may change the contents of some memory used without valid intialization or type checking in other code. You can thing about non direct inline method calling just like about above color changing which may but does not have cause application crash due to exploiting some hidden so far problems. Unfortunately not. It is first OLE, second based entirely on GTWVG which are Windows only applications. Please make some test using GTWVG code from the beginning of march. It may give you some answers. If your code needs MS-Windows than I suggest to try CodeGuard in BCC builds. It can give similar to Valgrind reports though it's not general CPU with OS API emulator but rather compiled code extension. It needs special C compile time switches to enable some additional protection/ statistic code and link with special runtime library. You should recompile Harbour core code with it and then your code. See INSTALL for info about this BCC CodeGuard switches. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Make NETIO RTE if called in ST mode?
On Fri, 23 Apr 2010, Szak�ts Viktor wrote: Hi, Shouldn't the NETIO server API call make an RTE if not called in MT mode? Only one function needs MT in NETIO server part. It's NETIO_MTSERVER(). All other code perfectly well works in single thread mode and are fully usable. I.e. someone can prefer single thread server only for some dedicated connection or using HB_FORK() and do not want to use MT HVM. The example of HBNETIO server uses: REQUEST HB_MT so it cannot be linked with non MT HVM version due to link time error. So we can talk noly about NETIO_MTSERVER() function. Now this function return pListenSocket or NIL on any errors (i.e. the IP port is already in used or code was linked with non MT HVM so user should always check the return value. If you think that it may help users then such RTE can be added only to this function as: ELSE [...] // gen RTE in the 'IF hb_mtvm()' statement in netiomt.prg but other code should not force in any way MT mode. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: CLASSES - Instance Variable as Object - Access/Assign Elsewhere
On Fri, 23 Apr 2010, Pritpal Bedi wrote: Hi, Is the following thread ? http://harbour-devel.1590103.n2.nabble.com/What-wrong-with-this-example-Harbour-Qt-hbxbp-td4880826.html#a4880826 Yes, but your project files do not allow to compile them in a standard way. This I had pointed you in one of my messages. Anyway, for this show I have the .hbp(s) ready to be build in contrib/hbide/projects/shum folder. I am awaiting Przemeks response, and will post here accordingly. After replacing HBXBP and HBQT references with some other OOP code all works without any problems so I can confirm that the problem is inside HBXBP and/or HBQT. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] NETIO Questions
On Fri, 23 Apr 2010, Winston Garcia wrote: Hi, What requirements are needed the computer server ? for 10 conections ? for 50 conections ? for 100 conections ? It depends on what you want to do with it. It gives two things. Dedicated for RDD file server and here are similar conditions to file server computers. Probably the most important is system performance and as servers Linux seems to be much better choice. The second thing realized by HBNETIO is RPC support so you can move some parts of your application to the server side. Here you have to decide yourself what is necessary to execute your code on the server side by many different client. When I'll find some spare time then I'll also add to HBNETIO support for server communication channels what should nicely extend HBNETIO functionality, i.e. HBNETIO server can be used on client side to give direct access to local devices/resources controlled by server side application and also to send simultaneously asynchronous events like incoming data on COM ports when they appear without explicit requests from the application. This should help users to move most of the application to the server side and make this part event driven. This will be the 3-rd HBNETIO job. I already implemented this extension for my own use but it's not ready to commit to SVN because I have to clean yet its public API. I think I'll do that in next month. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: CLASSES - Instance Variable as Object - Access/Assign Elsewhere
On Thu, 22 Apr 2010, Pritpal Bedi wrote: Hi, I am helpless that I cannot create a self-reduced sample. What I did, just created the standard methods instead of calling INLINE and everything went fine. I am not sure if changing the method calling convension has anything to do with OLE object. It has nothing to anything. It works just like standard methods though it's a less efficient due to one additional function stack frame which is created during execution of inline methods so the memory alignment is a little bit different and it can interact with some buggy code which access non initialized memory or use wrong pointers or even keep some indirect references to function methods in C structures. For now my problem is over and in future I will always take care that INLINE instance variable access/assign should never peep into my programs. Just to remmeber, I re-mention that the same code worked absolutely OK before 15 Mar and this code has nothing to do with OLE changes in GTWVG. I am using my local implementaion of ActiveX code because of one nasty active-x ( VisiLabel ) which is not standradized OLE. The fact that in the past some code was executed without GPF does not mean that it was ever correct. In this particular case GTWVG ActiveX code is still not production ready. As I can some things have been fixed by coping some parts of contrib/hbwin/axcore.c to contrib/gtwvg/wvgsink.c but still some other are not resolved, i.e. WVG_AXSETUPCONNECTIONPOINT() allocates memory for OLE objects and this memory is never released and the code which should do that is commented, probably due to GPFs. I do not see any code which increase reference counter before returning the pointer to PRG code so such GPF is expected behavior inside WVG_AXSHUTDOWNCONNECTIONPOINT(). And as far as I know this code existed here for very long time. Of course it's probably not the reason of your problems but it shows that this code is not such perfect as you suggested. There is one pending issue of similar nature which Shum posted some days back. If will be kind if you look into that issue. It pertains to object instance access/assign from within exe to an object created in a Harbour compiled .dll. Shum, can you show that code again ? I've seen this message and I haven't found anything what suggested any problems in core code but maybe you see sth what I'm missing so please be so kind and tell me what I should check or better please create self contain as small as possible example which we can compile and test ourselves. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx and fopen64()
On Fri, 23 Apr 2010, Szak�ts Viktor wrote: Hi, fopen64() is not present on OS X. After above warning (which is not pacified), it results in link time failure with this symbol missing. It was pacified and still is in GCC builds on all platforms. Anyhow please check feature set macros in MacOSX and how to enable 64bit file offset support in standard stdio commands like fopen(). If only fopen64() was missing and functions like ftello64() and fseeko64() exists then probably it does not need fopen64() and your recent modification only disabled long file support in Darwin MINIZIP builds. In such case only #define fopen64 fopen should be added for this platform. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: [Harbour] gpf with dbcreate and char field
On Fri, 23 Apr 2010, Horodyski Marek (PZUZ) wrote:
Hi,
this sample generates an GPF
struct := {{campo1,C,65000,0},{campo2,C,65000,0}}
dbcreate(test1.dbf,struct)
---
It is normal or I'm doing something wrong ?
No it should be RTE instead of GPF.
In DBF maximum record size is 64KB and above example needs
*
I have in mind that limit the size of record in the Clipper was the amount of
physical memory.
Record size in DBF is limited to 65535 bytes due to DBF structure only.
The size of record is stored in two bytes (16bit) inside DBF header.
In theory we can create incompatible DBF files which will not respect
this limit but probably only Harbour can read them.
Clipper also can create DBF files with record size up to 64KB.
If any memory limitation exists (I haven't exploited them) then
they work just like any other system resource limitations and
interacts also with all other things. The record size is not
an exception here.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: CLASSES - Instance Variable as Object - Access/Assign Elsewhere
On Thu, 22 Apr 2010, Pritpal Bedi wrote: Hi, This code works. So the issue is shortlisted to INLINE keyword. Przemek, are you around to set me right ? If I have to change my sources like above, it will be a huge task. I'll look at it as soon as you create self contain example which I can compile and test so it should not use MyActiveX() or any other non Harbour functions. If you cannot create such example then probably your problems are caused by memory corruption in MyActiveX() or some other non harbour code which are exploited as GPF in some cases, i.e. when you make some modification in your code like above switching between inline and standard methods. In such case non of us can help. BTW there were some modifications in OLE code used by GTWVG. Maybe they are related to your problem. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14363] trunk/harbour
On Thu, 22 Apr 2010, snaipe...@users.sourceforge.net wrote:
Hi,
2010-04-22 18:45 UTC+0300 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt)
* harbour/contrib/rddads/ads1.c
! Fixed date handling in area putValue method for .dbf tables.
ADS does not support dates smaller than 0001-01-01 and stores
invalid values in .dbf without any error. F.e., -01-01 is
stored as '-0011231', CTOD()+5 is stored as '1128'. Such
invalid filed values generates ADS runtime error 5095 later on
getValue area method.
DBF RDD stores empty dates in case of unsupported date range.
This fix makes ADS RDD behaviour more compatible to DBF RDD.
ADSADT behaviour is not changed because ADS allows to store
and retrieve field values for dates before 0001-01-01.
ADS should support in DBF (at least in VFP mode) julian date fields
as 32bit little endian integer values {D, 4, 0} which do not use
string representation.
As I can see your modification effected also such fields.
I think that you should change the condition from:
pArea-iFileType != ADS_ADT
to:
pField-uiLen == 8
or
pField-uiLen != 4
(AFAIR uiLen == 3 in ADS DBFs is SIX3 packed date with the same
restrictions as string version)
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] osx and fopen64()
On Thu, 22 Apr 2010, Szak�ts Viktor wrote: Hi, I'm getting this on OS X: --- /Developer/usr/bin/clang -I. -I../../../../../include -fno-common -O3 -DHB_LEGACY_TYPES_OFF -DHB_HAS_ZLIB -I/usr/include -o ioapi.o -c ../../../ioapi.c ../../../ioapi.c:122:14: warning: incompatible integer to pointer conversion assigning 'int', expected 'FILE *' file = fopen64((const char*)filename, mode_fopen); ^ ~~ 1 diagnostic generated. --- fopen64() seems to be missing on OS X. What is the best way to fix this? Please enable warnings in CLANG builds. It's hard to guess what exactly is missing and why and which builds/platforms/C compilers are affected. Maybe also GCC binaries are broken but here all warnings in all /external/* libraries in all GCC based builds are pacified so only runtime tests can exploit GPF or other problems. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] gpf with dbcreate and char field
On Thu, 22 Apr 2010, Lautaro Moreira wrote:
Hi,
this sample generates an GPF
struct := {{campo1,C,65000,0},{campo2,C,65000,0}}
dbcreate(test1.dbf,struct)
---
It is normal or I'm doing something wrong ?
No it should be RTE instead of GPF.
In DBF maximum record size is 64KB and above example needs
130001 bytes for record exceeding this limit.
I'll update DBF RDD to generate RTE in such case.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] [Przemek] Call HB_GCAll() inside AltD()
On Thu, 22 Apr 2010, Teo Fonrouge wrote: Hi, When using the debugger and having objects with destructors, sometimes when the AltD() function is executed and the program execution is paused the destructor code is not called until the first InKey( 0 ) call is issued and causing the execution of the destructor code right after entering the debugger. The workaround is to have: HB_GCAll() ; AltD() Can we have HB_GCAll() inside AltD() by default ? It will not resolve the problem because commands execute inside debugger may also activate GC and PRG destructor code compiled with -b harbour compiler flag. In general I do not see big problem with current behavior and your proposition may badly interact with debugging destructor code though I haven't analyzed it deeply. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] NETIO Questions
On Thu, 22 Apr 2010, Winston Garcia wrote: Hi, Have you a sample of Netio server what received many conections ? The samples en contrib/netio only accept one conection at time ? The server example code in contrib/hbnetio/utils/netiosrv.prg accepts many connections. Number of connections is limited only by system resources. NETIO_MTSERVER() in HBNETIO library is a function which activates such server. It has to be linked with MT HVM (-mt hbmk2 switch). best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBMZIP myzip.prg GPF
On Mon, 19 Apr 2010, Szak�ts Viktor wrote: Hi, What operating system and compiler? All. Just fixed. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error with 14333
On Wed, 14 Apr 2010, Szak�ts Viktor wrote: Hi, I hope someone can fix these. These were so far hidden because of turned off warnings for exotic compilers like bcc/pocc/xcc when building external libs. Now they are visible. This bug exists with _ALL_ C compilers we are using. Just simply your recent modifications enabled warnings only for few compilers but many others like all GCC based ones still does not report any warnings so such bugs are invisible. Missing prototypes means that C compiler may incorrectly create function call frame so final code will GPF or fail in other way depending on used ABI and type of parameters. If the problems won't be resolved, I will simply disable failing libs for these targets. To fix such problems it's necessary to know about them and this library is yet another example that disabled warnings may cause that we are creating wrong binaries without any knowledge about it. The problem is that nearly all of these libraries uses autoconf to generate configuration header files but we not and we are using in all builds only some statically defined for chosen platform files without real system dependent configuration so such definition can be wrong and broken code is generated. With fully disabled warnings we do not know about it. In this particular case (JPEG library) HAVE_PROTOTYPES definition is missing and it's the reason of above errors in _all_ builds (we do not support any old C compiler which does not support prototypes). best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] sf.net bug: codepage translation
On Wed, 14 Apr 2010, Szak�ts Viktor wrote: Hi, Here's a new bug report / fix suggestion: http://sourceforge.net/tracker/index.php?func=detailaid=2987157group_id=681atid=100681 Any comment? [ Seems valid to me at first read. ] It's not correct solution. It only breaks few things instead of fixing real problem. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] MSVC warnings (uninit variable)
On Wed, 14 Apr 2010, Szak�ts Viktor wrote: Hi, I've found these warning with recent Harbour versions, reported by both MSVC 2008 and 2010: --- \harbour\src\compiler\obj\win\msvc\harboury.c(7035) : warning C4701: potentially uninitialized local variable 'hb_complval' used \harbour\src\rtl\hbzlib.c(249) : warning C4701: potentially uninitialized local variable 'pDest' used \harbour\src\rtl\hbzlib.c(249) : warning C4701: potentially uninitialized local variable 'pDest' used \harbour\src\macro\obj\win\msvc\macroy.c(2996) : warning C4701: potentially uninitialized local variable 'hb_macrolval' used \harbour\src\macro\obj\win\msvc\macroy.c(2996) : warning C4701: potentially uninitialized local variable 'hb_macrolval' used \harbour\contrib\hbbz2\hbbz2.c(354) : warning C4701: potentially uninitialized local variable 'pDest' used --- All are false alarms. I can pacify the warnings adding redundant initialization in hbzlib.c and hbbz2.c but it will be hard to make something with harboury. and macroy.c because it's code generated by bison. I already use a little bit patched bison to generate our grammar files so I can add some farther modification to pacify also above MSVC warnings. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HBIDE Project build start folder problem
On Mon, 12 Apr 2010, Pritpal Bedi wrote: Hi, Unix: The started process will run in its own session and act like a daemon. I do not know what exactly this means in unix. Also I do not know how to cover it. Someone with more nixes knowldge should tell us. It is similar to running a service in windows. It is not attached to any input or output device. Thanks Alex for the info. So the question is how to invoke it as application but in detached manner. More investigation is needed from Qt documentation. hb_processRun( cCommand, [ cStdIn ], [ @cStdOut ], [ @cStdErr ], ; [ lDetach ] ) - nResult lDetach must not be .T. if you do not want to execute process in background (as daemon). This command is implemented for all platforms. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14324] trunk/harbour
On Tue, 13 Apr 2010, Szak�ts Viktor wrote: Hi, Maybe msvc ones can be suppressed with a #pragma? and setting _CRT_SECURE_NO_WARNINGS. Seem that all can be done in zutil.h and gzguts.h. Can you do it? It's not very good to have 40KB of warning in normal builds. Sorry but I do not have any version of MSVC installed and it does not work with WINE. I do not even know it's pragma parameters. BTW this version does not set -DZLIB_DLL when compiled as dynamic code. Can you be more specific? I've been looking for ZLIB_DLL trick in our own build code, but couldn't find any so to me it looks the same as before. Can be I missed something. harbour/external/zlib/ChangeLog: 2008-08-05 21:39 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * harbour/source/hbzlib/zconf.h + Setting ZLIB_DLL if HB_DYNLIB is defined. Now I can see in harbour/ChangeLog that you removed it: 2008-08-06 22:56 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * source/hbzlib/zconf.h * Undone previous ZLIB_DLL related change, as it causes these warnings, when compiled with MSVS: hbzlib.obj : warning LNK4217: locally defined symbol _inflateEnd imported in function _hb_zlibUncompressedSize hbzlib.obj : warning LNK4217: locally defined symbol _inflate imported in function _hb_zlibUncompressedSize It was enough to force dllexport instead of dllimport in zconf.h when HB_DYNLIB argument is set to avoid above warnings. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HBIDE Project build start folder problem
On Mon, 12 Apr 2010, Pritpal Bedi wrote: Hi, hb_processRun( cCommand, [ cStdIn ], [ @cStdOut ], [ @cStdErr ], ; [ lDetach ] ) - nResult lDetach must not be .T. if you do not want to execute process in background (as daemon). This command is implemented for all platforms. If lDetach == .F. then the process will run under hbIDE's process space, right? If yes, then when the control will return to hbIDE ? Immediately after initiating the process or after initiated process will terminate? Look at parameters. They give you the answer. To set cStdOut, cStdErr and nResult is necessary to wait inside hb_processRun() until executed command terminates. If you want to still execute your foreground process then use: hb_processOpen( cCommand, ; [ @hStdIn ], [ @hStdOut ], [ @hStdErr ], ; [ lDetach ], [ @nPID ] ) - hProcess | F_ERROR and then: hb_processValue( hProcess [, lWait=.T. ] ) - nResult or: hb_processClose( hProcess [, lGentle=.T. ] ) - lTerminated hStdIn, hStdOut and hStdErr are file handles from which you can read and write using FREAD()/FWRITE(). nResult is value returned by executed process (errorLevel()), lWait is .T. by default, lGentle is .T. by default, when it's .F. the process is killed unconditionally. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HBIDE Project build start folder problem
On Tue, 13 Apr 2010, Pritpal Bedi wrote: Hi, Look at parameters. They give you the answer. To set cStdOut, cStdErr and nResult is necessary to wait inside hb_processRun() until executed command terminates. If you want to still execute your foreground process then use: hb_processOpen( cCommand, ; [ @hStdIn ], [ @hStdOut ], [ @hStdErr ], ; [ lDetach ], [ @nPID ] ) - hProcess | F_ERROR and then: hb_processValue( hProcess [, lWait=.T. ] ) - nResult or: hb_processClose( hProcess [, lGentle=.T. ] ) - lTerminated hStdIn, hStdOut and hStdErr are file handles from which you can read and write using FREAD()/FWRITE(). nResult is value returned by executed process (errorLevel()), lWait is .T. by default, lGentle is .T. by default, when it's .F. the process is killed unconditionally. I tried this: hb_processRun( cExecutable, NIL, NIL, NIL, .F. ) Executable is invoked but control is returned to the caller after termination of executable. hb_processRun( cExecutable, NIL, NIL, NIL, .T. ) Executable is active without showing up interface ( as a daemon ) but still control is not returned back to caller, hangs forever and has to be killed via task manager. Exactly as I described above. I know that my English is fatal but To set cStdOut, cStdErr and nResult is necessary to wait inside hb_processRun() until executed command terminates. seems to be clear. I need a functionality where new process executes normally at its own and control is returned back to caller. How this can be achieved with hb_processRun() ? You have to read my message once again. I gave you all necessary information. You have to use hb_processOpen(), i.e.: hProccess := hb_processOpen( cExecutable ) if hProccess != F_ERROR while ( nResult := hb_processValue( hProccess, .F. ) ) == -1 ? waiting for process... hb_idleSleep( 1 ) enddo ? process terminated with result:, nResult endif best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: HBIDE Project build start folder problem
On Tue, 13 Apr 2010, Szak�ts Viktor wrote: Hi, If I run from command line :- [...@jackodesktop hash]$ hbmk2 ash.hbp -run then ash is built and runs, but it is in a terminal window labelled hash:hbmk2 If I kill the hbmk2 process then the running ash process drops to a prompt, with ./ash still taking 25% cpu and showtime() still running, displaying the time (as it does in ash). It's the same with: [...@jackodesktop hash]$ hbmk2 ash.hbp -hbrun The launched process still depends on hbmk2. Is there a way to launch a new terminal window and run the process in that, so the launched app is truly independant ? I don't know, but if someone gives me some hints, it's very easy to implement in hbmk2. It already works for win, darwin and os2. For *nix it's AFAIK desktop dependent, and we should also have a default version which is plain terminal based. Here is my code to do that, but I'd highly appreciate if *nix experts would comment on it, before I add it to Harbour: --- IF ! Empty( GetEnv( GNOME_DESKTOP_SESSION_ID ) ) nResult := hb_run( gnome-open + cFileName ) ELSEIF ! Empty( GetEnv( KDEDIR ) ) nResult := hb_run( kfmclient exec + cFileName ) ELSE nResult := hb_run( cFileName ) ENDIF --- This is different thing. When you are working with XWindow then you can execute new programs in separated terminal windows. Such functionality should be optional, i.e. hbide can have an option: [x] execute in new terminal so user can set it when he thinks it's necessary for his program. In such case the application should be executed using some terminal emulator, i.e. xterm, pterm, rxvt, konsole, gnome-terminal, ... It would be niece if user can choose preferred terminal. As default hbide can use: xterm -e as most portable setting and user can change it i.e. to: konsole -e or pterm -e ... -e cmd args,... is the standard option in most of terminal emulators. Warning some gnome-terminal versions have problems with this functionality. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
