Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-10 Thread Przemysław Czerpak
On Thu, 07 Jan 2010, Szak�ts Viktor wrote: Hi, We have hb_secondsCPU() in core, maybe code below could be incorporated into it. It's not exactly the same. If possible (supported bu OS) hb_secondsCPU() returns number CPU cycles consumed by programs not real time clock. It means that d =

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-07 Thread Mindaugas Kavaliauskas
Hi, Przemysław Czerpak wrote: PROC main() HB_INETINIT() ? NETIO_PROCEXISTS(127.0.0.1:2941:STR) RETURN but it's possible that when it's executed as startup code then such initialization do not work and we should use hb_vmAtInit() function. Can you verify it? You are right.

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-07 Thread Przemysław Czerpak
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote: Hi, Przemysław Czerpak wrote: PROC main() HB_INETINIT() ? NETIO_PROCEXISTS(127.0.0.1:2941:STR) RETURN but it's possible that when it's executed as startup code then such initialization do not work and we should use

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-07 Thread Mindaugas Kavaliauskas
Hi, Przemysław Czerpak wrote: 2010-01-07 14:14 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbnetio/netiocli.c ! use hb_vmAtInit() to initialize NETIO - looks that winsock initialization in startup code does not work - please test If possible

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-07 Thread Przemysław Czerpak
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote: Hi, If possible please verify if this code: PROC main() ? NETIO_PROCEXISTS(127.0.0.1:2941:STR) RETURN works after above modification. I cannot test it in Linux because in WINE WINSOCK initialization is not necessary. It still

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-07 Thread Mindaugas Kavaliauskas
Hi, Przemysław Czerpak wrote: Ups. Sorry I forgot that automatic initialization is not enabled by default. In netiocli.c it's covered by: #if defined( HB_NETIO_STARTUP_INIT ) [...] #endif Yes :) By adding a few more tracelog, I've also found this reason :) So it's expected and

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-07 Thread Mindaugas Kavaliauskas
Hi, Mindaugas Kavaliauskas wrote: BTW how expensive (time consuming) is WINSOCK initialization in MS-Windows? HB_ULONG ulTime = hb_dateMilliSeconds(); hb_socketInit(); HB_TRACE( HB_TR_ALWAYS, (hb_socketInit() time=%d, hb_dateMilliSeconds() - ulTime) ); prints:

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-07 Thread Viktor Szakáts
We have hb_secondsCPU() in core, maybe code below could be incorporated into it. Brgds, Viktor On 2010 Jan 7, at 16:56, Mindaugas Kavaliauskas wrote: Hi, Mindaugas Kavaliauskas wrote: BTW how expensive (time consuming) is WINSOCK initialization in MS-Windows? HB_ULONG ulTime =

[Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread druzus
Revision: 13489 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13489view=rev Author: druzus Date: 2010-01-06 16:16:22 + (Wed, 06 Jan 2010) Log Message: --- 2010-01-06 17:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) *

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Massimo Belgrano
possible now create directories automatically if not there on the remote? 2010/1/6 dru...@users.sourceforge.net: Revision: 13489           http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13489view=rev Author:   druzus Date:     2010-01-06 16:16:22 + (Wed, 06 Jan 2010)

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Przemysław Czerpak
On Wed, 06 Jan 2010, Massimo Belgrano wrote: Hi, possible now create directories automatically if not there on the remote? Massimo, what is not clear in my ChangeLog entry? I even updated NETIO server example and added to ChangeLog demonstration code. Please don't be so fast and think a

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Lorenzo Fiorini
On Wed, Jan 6, 2010 at 5:16 PM, dru...@users.sourceforge.net wrote:  * harbour/contrib/hbnetio/netio.h  * harbour/contrib/hbnetio/netiocli.c  * harbour/contrib/hbnetio/netiosrv.c    + implemented RPC in HBNETIO protocol ...   Have a fun with a new toy. I hope that many Harbour user will

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Viktor Szakáts
Great feature. Thanks a lot for it. Too smoothen the security edge of this feature, maybe it would be nice to allow to limit the set of functions made available through RPC on the server side. This way programmer could have total control over this aspect without worrying about function being

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Przemysław Czerpak
On Wed, 06 Jan 2010, Lorenzo Fiorini wrote: It's only important that the functions you want to execute are linked with server code or where loaded dynamically. you can even make sth like: netio_procexec( HB_HRBLOAD, hb_memoread( mycode.hrb ) ) result := netio_funcexec( MYFUNC1, param1,

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Przemysław Czerpak
On Wed, 06 Jan 2010, Szak�ts Viktor wrote: Too smoothen the security edge of this feature, maybe it would be nice to allow to limit the set of functions made available through RPC on the server side. This way programmer could have total control over this aspect without worrying about

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Viktor Szakáts
On Wed, 06 Jan 2010, Szak�ts Viktor wrote: Too smoothen the security edge of this feature, maybe it would be nice to allow to limit the set of functions made available through RPC on the server side. This way programmer could have total control over this aspect without worrying about

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Mindaugas Kavaliauskas
Hi, All above functions use default connection set by NETIO_CONNECT() for RPCs but it's also possible to specify server address and port in cProcName/cFuncName just like in cFileName parameter in RDD functions, i.e.: NETIO_PROCEXISTS( 192.168.0.1:10005:MYFUNC )

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Mindaugas Kavaliauskas
Hi, Przemysław Czerpak wrote: On Wed, 06 Jan 2010, Lorenzo Fiorini wrote: It's only important that the functions you want to execute are linked with server code or where loaded dynamically. you can even make sth like: netio_procexec( HB_HRBLOAD, hb_memoread( mycode.hrb ) ) BTW a small

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Mindaugas Kavaliauskas
Hi, Mindaugas Kavaliauskas wrote: homework.prg (test module): PROC main() ? netio_connect() ? NETIO_PROCEXISTS(HB_HRBLOAD) ? NETIO_PROCEXISTS(HELLO) ? NETIO_PROCEXECW(HB_HRBLOAD, HB_MEMOREAD(homework2.prg)) ? NETIO_PROCEXISTS(HELLO) ? NETIO_FUNCEXEC(HELLO) RETURN Unfortunately test

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Pritpal Bedi
Hello Przemek Log Message: --- 2010-01-06 17:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/hbznet.c ! do not use DEF_MEM_LEVEL to avoid potential problems when zutil.h is not available * harbour/contrib/hbnetio/netio.h *

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Przemysław Czerpak
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote: Hi, Mindaugas Kavaliauskas wrote: homework.prg (test module): PROC main() ? netio_connect() ? NETIO_PROCEXISTS(HB_HRBLOAD) ? NETIO_PROCEXISTS(HELLO) ? NETIO_PROCEXECW(HB_HRBLOAD, HB_MEMOREAD(homework2.prg)) ?

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Przemysław Czerpak
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote: Hi, PROC main() ? netio_connect() ? NETIO_PROCEXISTS(STR) RETURN prints: .T. .T. but PROC main() ? NETIO_PROCEXISTS(127.0.0.1:2941:STR) RETURN prints: .F. What I'm missing? It's working for me in my Linux box so I can only

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Przemysław Czerpak
On Wed, 06 Jan 2010, Pritpal Bedi wrote: Hi, I can sense this commit is the basis for NETRDD or NETGT of future. Am I right ? It can be useful for both but in fact it's side effect of some other job not directly related to Harbour. Anyhow I plan to work on GTNET in the nearest future so above

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Pritpal Bedi
Hi Przemysław Czerpak wrote: Anyhow I plan to work on GTNET in the nearest future so above code should greatly help. I could not hear a better with than above few words, for 2010. Regards Pritpal Bedi -- View this message in context:

Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour

2010-01-06 Thread Massimo Belgrano
Very good news! can we plan promote a 2.1 with GTnet and hbide is some month? 2010/1/7 Przemysław Czerpak dru...@acn.waw.pl: On Wed, 06 Jan 2010, Pritpal Bedi wrote: Hi, I can sense this commit is the basis for NETRDD or NETGT of future. Am I right ? It can be useful for both but in