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 = hb_secondsCPU();
   Sleep( 10 );
   d = hb_secondsCPU() - d;

should give value close to 0.0 because inside Sleep( 10 ) process
is suspended by OS and do not consume CPU at all.

I think that we should add new function to extract real time clock
with high precision. Because precision can be different on different
OS-es then we will have to chose holder which allow to set different
precision. We can use 2 integer numbers for that or single double
number (floating point number are internally divided to mantissa and
exponent what gives us the functionality we are looking for)
Mindaugas used double value in his example and it's reasonable for me.
The return value from such function can be used only to measure some
real time differences because in portable programs it's undefined,
i.e. in Mindaugas'es code it's the time of 1-st call to this function.
I'll add such function ASAP.

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:[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. HB_INETINIT() solves the problem.


Regards,
Mindaugas


___
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:[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 hb_vmAtInit()
 function. Can you verify it?
 You are right. HB_INETINIT() solves the problem.

Thank you for the information. I've just committed:

   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 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.

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:[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 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 does not work... I've put some debug code:

conn = s_fileConnect( pszProcName, NULL, 0, 0 ); in s_netio_procexec() 
returns NULL.


sd = hb_socketOpen( HB_SOCKET_PF_INET, HB_SOCKET_PT_STREAM, 0 ); in 
s_fileConnect() returns -1.



BTW:

../../../netiocli.c:
Warning W8004 ../../../netiocli.c 502: 'size' is assigned a value that 
is never used in function s_n

etio_params


Regards,
Mindaugas
___
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:[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 does not work...

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
So it's expected and probably also startup winsock initialization works.
If possible please check it by adding ' || 1 ' to above #if condition
and replacing:
   hb_vmAtInit( s_netio_init, NULL );
with:
   s_netio_init( NULL );

BTW how expensive (time consuming) is WINSOCK initialization in MS-Windows?

 BTW:
 ../../../netiocli.c:
 Warning W8004 ../../../netiocli.c 502: 'size' is assigned a value
 that is never used in function s_netio_params

Thanks for the info. I'll clean it on next commit.

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:[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 probably also startup winsock initialization works.
If possible please check it by adding ' || 1 ' to above #if condition
and replacing:
   hb_vmAtInit( s_netio_init, NULL );
with:
   s_netio_init( NULL );


Both ways works OK.



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:

netiocli.c:470: HB_TR_ALWAYS hb_socketInit() time=0

Do you have any other test code for it?


Regards,
Mindaugas

___
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:[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:

netiocli.c:470: HB_TR_ALWAYS hb_socketInit() time=0

Do you have any other test code for it?


Some time ago I was testing Python, Ruby, Java, etc speed. I was 
surprised about how Python's clock() function. It returns a lot of 
decimals on Windows. I've looked into the source and found a useful 
Win32 API function QueryPerformanceCounter for implementation of a high 
precision timer in Windows.


Here is the simplest version:
#include windows.h
static LARGE_INTEGER iStart;
static LARGE_INTEGER iFreq = {0};
double hpclock( void )
{
  LARGE_INTEGER iTime;
  if( iFreq.QuadPart == 0 )
  {
QueryPerformanceCounter( iStart );
QueryPerformanceFrequency( iFreq );
  }
  QueryPerformanceCounter( iTime );
  return ( double )( iTime.QuadPart - iStart.QuadPart ) / ( double ) 
iFreq.QuadPart;

}

The modified s_netio_init() code:
  double dTime = hpclock();
  hb_socketInit();
  HB_TRACE( HB_TR_ALWAYS, (hb_socketInit() time=%g, hpclock() - 
dTime) );

  dTime = hpclock();
  Sleep(1000);
  HB_TRACE( HB_TR_ALWAYS, (1 second =%g, hpclock() - dTime) );
  HB_TRACE( HB_TR_ALWAYS, (hpclock() overhead=%g, hpclock() - 
hpclock()) );


prints:

C:\harbour\contrib\hbnetio\testsrpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00185554
netiocli.c:492: HB_TR_ALWAYS 1 second =1.1
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06

.T.
C:\harbour\contrib\hbnetio\testsrpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00119596
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999618
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06

.T.
C:\harbour\contrib\hbnetio\testsrpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00146946
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999511
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.39683e-06

.T.
C:\harbour\contrib\hbnetio\testsrpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00144739
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999809
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06

.T.
C:\harbour\contrib\hbnetio\testsrpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00116998
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999526
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06

.T.
C:\harbour\contrib\hbnetio\testsrpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00183431
netiocli.c:492: HB_TR_ALWAYS 1 second =0.99934
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.39683e-06

.T.
C:\harbour\contrib\hbnetio\testsrpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00191924
netiocli.c:492: HB_TR_ALWAYS 1 second =0.99944
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.95556e-06

.T.
C:\harbour\contrib\hbnetio\testsrpctest.exe
netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00148734
netiocli.c:492: HB_TR_ALWAYS 1 second =0.999669
netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06

.T.

We already have two time functions that return seconds from midnight and 
milliseconds (absolute UTC), but sometimes it is useful to have a higher 
precision time function and a function that ignores adjustment of 
computer time. The proposed function has these properties, but I do not 
know if such implementation is possible in another platforms. I guess 
this clock uses CPU clock counter, so, I do not know how it works in 
real multi-CPU environment.



Regards,
Mindaugas
___
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:[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 = hb_dateMilliSeconds();
  hb_socketInit();
  HB_TRACE( HB_TR_ALWAYS, (hb_socketInit() time=%d, 
 hb_dateMilliSeconds() - ulTime) );
 prints:
 netiocli.c:470: HB_TR_ALWAYS hb_socketInit() time=0
 Do you have any other test code for it?
 
 Some time ago I was testing Python, Ruby, Java, etc speed. I was surprised 
 about how Python's clock() function. It returns a lot of decimals on Windows. 
 I've looked into the source and found a useful Win32 API function 
 QueryPerformanceCounter for implementation of a high precision timer in 
 Windows.
 
 Here is the simplest version:
 #include windows.h
 static LARGE_INTEGER iStart;
 static LARGE_INTEGER iFreq = {0};
 double hpclock( void )
 {
  LARGE_INTEGER iTime;
  if( iFreq.QuadPart == 0 )
  {
QueryPerformanceCounter( iStart );
QueryPerformanceFrequency( iFreq );
  }
  QueryPerformanceCounter( iTime );
  return ( double )( iTime.QuadPart - iStart.QuadPart ) / ( double ) 
 iFreq.QuadPart;
 }
 
 The modified s_netio_init() code:
  double dTime = hpclock();
  hb_socketInit();
  HB_TRACE( HB_TR_ALWAYS, (hb_socketInit() time=%g, hpclock() - dTime) );
  dTime = hpclock();
  Sleep(1000);
  HB_TRACE( HB_TR_ALWAYS, (1 second =%g, hpclock() - dTime) );
  HB_TRACE( HB_TR_ALWAYS, (hpclock() overhead=%g, hpclock() - hpclock()) 
 );
 
 prints:
 
 C:\harbour\contrib\hbnetio\testsrpctest.exe
 netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00185554
 netiocli.c:492: HB_TR_ALWAYS 1 second =1.1
 netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
 
 .T.
 C:\harbour\contrib\hbnetio\testsrpctest.exe
 netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00119596
 netiocli.c:492: HB_TR_ALWAYS 1 second =0.999618
 netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
 
 .T.
 C:\harbour\contrib\hbnetio\testsrpctest.exe
 netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00146946
 netiocli.c:492: HB_TR_ALWAYS 1 second =0.999511
 netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.39683e-06
 
 .T.
 C:\harbour\contrib\hbnetio\testsrpctest.exe
 netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00144739
 netiocli.c:492: HB_TR_ALWAYS 1 second =0.999809
 netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
 
 .T.
 C:\harbour\contrib\hbnetio\testsrpctest.exe
 netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00116998
 netiocli.c:492: HB_TR_ALWAYS 1 second =0.999526
 netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
 
 .T.
 C:\harbour\contrib\hbnetio\testsrpctest.exe
 netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00183431
 netiocli.c:492: HB_TR_ALWAYS 1 second =0.99934
 netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.39683e-06
 
 .T.
 C:\harbour\contrib\hbnetio\testsrpctest.exe
 netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00191924
 netiocli.c:492: HB_TR_ALWAYS 1 second =0.99944
 netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.95556e-06
 
 .T.
 C:\harbour\contrib\hbnetio\testsrpctest.exe
 netiocli.c:489: HB_TR_ALWAYS hb_socketInit() time=0.00148734
 netiocli.c:492: HB_TR_ALWAYS 1 second =0.999669
 netiocli.c:493: HB_TR_ALWAYS hpclock() overhead=-1.67619e-06
 
 .T.
 
 We already have two time functions that return seconds from midnight and 
 milliseconds (absolute UTC), but sometimes it is useful to have a higher 
 precision time function and a function that ignores adjustment of computer 
 time. The proposed function has these properties, but I do not know if such 
 implementation is possible in another platforms. I guess this clock uses CPU 
 clock counter, so, I do not know how it works in real multi-CPU environment.
 
 
 Regards,
 Mindaugas
 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] 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)
  * 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
  * harbour/contrib/hbnetio/netiocli.c
  * harbour/contrib/hbnetio/netiosrv.c
+ implemented RPC in HBNETIO protocol
+ added the following client functions:
  check if function/procedure exists on the server side:
 NETIO_PROCEXISTS( cProcName ) - lExists
  execute function/procedure on server the side,
  do not wait for confirmation:
 NETIO_PROCEXEC( cProcName [, params,...] ) - lSent
  execute function/procedure on the server side and wait for
  confirmation:
 NETIO_PROCEXECW( cProcName [, params,...] ) - lExecuted
  execute function on the server side and wait for its return value:
 NETIO_FUNCEXEC( cFuncName [, params,...] ) - xFuncRetVal
  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 )
+ added new server side functions to enable/disable/check RPC support:
 NETIO_RPC( pListenSocket | pConnectionSocket [, lEnable ] )
   - lEnabled
  if RPC is enabled for listen socket then connection sockets inherit
  this setting.
+ added 4-th parameter lRPC to NETIO_LISTEN() function. .T. enable
  RPC support in returned listen socket which is later inherited by
  connection sockets
* changed protocol version ID - current NETIO clients and servers
  cannot be used with old code

  * harbour/contrib/hbnetio/utils/netiosrv.prg
* added option to enable RPC support in NETIO server

   If you want to make some test then you can execute netiosrv with
   non empty 4-th parameter as server, i.e.:
  ./netiosrv1
   and try this code as client:

  proc main()
 // pass server address to netio_connect() for non localhost tests
 ? NETIO_CONNECT():, netio_connect()
 ?
 ? DATE() function is supported:, netio_procexists( DATE )
 ? QOUT() function is supported:, netio_procexists( DATE )
 ? HB_DATETIME() function is supported:, ;
   netio_procexists( HB_DATETIME )
 ?
 ? netio_procexec( QOUT, repl( =, 50 ) )
 ? netio_procexec( QOUT, This is RPC TEST, date(), hb_datetime() )
 ? netio_procexecw( QOUT, repl( =, 50 ) )
 ? 
 ? SERVER DATE:, netio_funcexec( DATE )
 ? SERVER TIME:, netio_funcexec( TIME )
 ? SERVER DATETIME:, netio_funcexec( HB_DATETIME )
 ?
 ? netio_funcexec( upper, hello world !!! )
  return

   Please remember that only functions linked with server are available.
   If you want to enabled all core functions in netiosrv then please
   uncomment this line in netiosrv.prg:
  REQUEST __HB_EXTERN__


   Have a fun with a new toy. I hope that many Harbour user will find it
   very interesting. Please only be careful !!!. This feature allows to
   execute remotely _ANY_ code on the server side. _NEVER_ leave open ports
   with RPC support for untrusted access.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbnetio/netio.h
trunk/harbour/contrib/hbnetio/netiocli.c
trunk/harbour/contrib/hbnetio/netiosrv.c
trunk/harbour/contrib/hbnetio/utils/netiosrv.prg
trunk/harbour/src/rtl/hbznet.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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)

 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
  * harbour/contrib/hbnetio/netiocli.c
  * harbour/contrib/hbnetio/netiosrv.c
    + implemented RPC in HBNETIO protocol
    + added the following client functions:
      check if function/procedure exists on the server side:
         NETIO_PROCEXISTS( cProcName ) - lExists
      execute function/procedure on server the side,
      do not wait for confirmation:
         NETIO_PROCEXEC( cProcName [, params,...] ) - lSent
      execute function/procedure on the server side and wait for
      confirmation:
         NETIO_PROCEXECW( cProcName [, params,...] ) - lExecuted
      execute function on the server side and wait for its return value:
         NETIO_FUNCEXEC( cFuncName [, params,...] ) - xFuncRetVal
      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 )
    + added new server side functions to enable/disable/check RPC support:
         NETIO_RPC( pListenSocket | pConnectionSocket [, lEnable ] )
               - lEnabled
      if RPC is enabled for listen socket then connection sockets inherit
      this setting.
    + added 4-th parameter lRPC to NETIO_LISTEN() function. .T. enable
      RPC support in returned listen socket which is later inherited by
      connection sockets
    * changed protocol version ID - current NETIO clients and servers
      cannot be used with old code

  * harbour/contrib/hbnetio/utils/netiosrv.prg
    * added option to enable RPC support in NETIO server

   If you want to make some test then you can execute netiosrv with
   non empty 4-th parameter as server, i.e.:
      ./netiosrv1
   and try this code as client:

      proc main()
         // pass server address to netio_connect() for non localhost tests
         ? NETIO_CONNECT():, netio_connect()
         ?
         ? DATE() function is supported:, netio_procexists( DATE )
         ? QOUT() function is supported:, netio_procexists( DATE )
         ? HB_DATETIME() function is supported:, ;
           netio_procexists( HB_DATETIME )
         ?
         ? netio_procexec( QOUT, repl( =, 50 ) )
         ? netio_procexec( QOUT, This is RPC TEST, date(), hb_datetime() )
         ? netio_procexecw( QOUT, repl( =, 50 ) )
         ?
         ? SERVER DATE:, netio_funcexec( DATE )
         ? SERVER TIME:, netio_funcexec( TIME )
         ? SERVER DATETIME:, netio_funcexec( HB_DATETIME )
         ?
         ? netio_funcexec( upper, hello world !!! )
      return

   Please remember that only functions linked with server are available.
   If you want to enabled all core functions in netiosrv then please
   uncomment this line in netiosrv.prg:
      REQUEST __HB_EXTERN__


   Have a fun with a new toy. I hope that many Harbour user will find it
   very interesting. Please only be careful !!!. This feature allows to
   execute remotely _ANY_ code on the server side. _NEVER_ leave open ports
   with RPC support for untrusted access.



-- 
Massimo Belgrano
___
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:[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 little
bit before you ask about sth. Using RPC you can execute any
function or procedure on the server side, MKDIR is not an
exception here, i.e.:

   netio_procexec( MKDIR, C:\TEST )

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 ) )

to register your .hrb file with set of your own functions on
the server side and then execute them using:

   result := netio_funcexec( MYFUNC1, param1, param2, param3 )
   ? netio_funcexec( MYFUNC2, result )

In summary you can do anything, also

   netio_procexec( __run, format D: /u/y )

so please be extremely careful with this 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:[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 find it
   very interesting. Please only be careful !!!. This feature allows to
   execute remotely _ANY_ code on the server side. _NEVER_ leave open ports
   with RPC support for untrusted access.

WOW this is a SUPER gift. Many thanks.

Just a question.

 Please remember that only functions linked with server are available.

This is clear to me, but then you added:

 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, param2, param3 )
  ? netio_funcexec( MYFUNC2, result )

Do you mean that all the functions inside the mycode.hrb are
automatically registered and available without defining them DYNAMIC?

I mean can it be a way to have dynamic non binary libs of functions?

best regards,
Lorenzo
___
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:[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 linked without knowledge or intent, 
and keep verifying .map files to find out.

Brgds,
Viktor

On 2010 Jan 6, at 17:16, dru...@users.sourceforge.net wrote:

 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)
  * 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
  * harbour/contrib/hbnetio/netiocli.c
  * harbour/contrib/hbnetio/netiosrv.c
+ implemented RPC in HBNETIO protocol
+ added the following client functions:
  check if function/procedure exists on the server side:
 NETIO_PROCEXISTS( cProcName ) - lExists
  execute function/procedure on server the side,
  do not wait for confirmation:
 NETIO_PROCEXEC( cProcName [, params,...] ) - lSent
  execute function/procedure on the server side and wait for
  confirmation:
 NETIO_PROCEXECW( cProcName [, params,...] ) - lExecuted
  execute function on the server side and wait for its return value:
 NETIO_FUNCEXEC( cFuncName [, params,...] ) - xFuncRetVal
  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 )
+ added new server side functions to enable/disable/check RPC support:
 NETIO_RPC( pListenSocket | pConnectionSocket [, lEnable ] )
   - lEnabled
  if RPC is enabled for listen socket then connection sockets inherit
  this setting.
+ added 4-th parameter lRPC to NETIO_LISTEN() function. .T. enable
  RPC support in returned listen socket which is later inherited by
  connection sockets
* changed protocol version ID - current NETIO clients and servers
  cannot be used with old code
 
  * harbour/contrib/hbnetio/utils/netiosrv.prg
* added option to enable RPC support in NETIO server
 
   If you want to make some test then you can execute netiosrv with
   non empty 4-th parameter as server, i.e.:
  ./netiosrv1
   and try this code as client:
 
  proc main()
 // pass server address to netio_connect() for non localhost tests
 ? NETIO_CONNECT():, netio_connect()
 ?
 ? DATE() function is supported:, netio_procexists( DATE )
 ? QOUT() function is supported:, netio_procexists( DATE )
 ? HB_DATETIME() function is supported:, ;
   netio_procexists( HB_DATETIME )
 ?
 ? netio_procexec( QOUT, repl( =, 50 ) )
 ? netio_procexec( QOUT, This is RPC TEST, date(), hb_datetime() )
 ? netio_procexecw( QOUT, repl( =, 50 ) )
 ? 
 ? SERVER DATE:, netio_funcexec( DATE )
 ? SERVER TIME:, netio_funcexec( TIME )
 ? SERVER DATETIME:, netio_funcexec( HB_DATETIME )
 ?
 ? netio_funcexec( upper, hello world !!! )
  return
 
   Please remember that only functions linked with server are available.
   If you want to enabled all core functions in netiosrv then please
   uncomment this line in netiosrv.prg:
  REQUEST __HB_EXTERN__
 
 
   Have a fun with a new toy. I hope that many Harbour user will find it
   very interesting. Please only be careful !!!. This feature allows to
   execute remotely _ANY_ code on the server side. _NEVER_ leave open ports
   with RPC support for untrusted access.
 
 Modified Paths:
 --
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbnetio/netio.h
trunk/harbour/contrib/hbnetio/netiocli.c
trunk/harbour/contrib/hbnetio/netiosrv.c
trunk/harbour/contrib/hbnetio/utils/netiosrv.prg
trunk/harbour/src/rtl/hbznet.c
 
 
 This was sent by the SourceForge.net collaborative development platform, the 
 world's largest Open Source development site.
 ___
 Harbour mailing list (attachment size limit: 40KB)
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour

___
Harbour 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:[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, param2, param3 )
   ? netio_funcexec( MYFUNC2, result )
 Do you mean that all the functions inside the mycode.hrb are
 automatically registered and available without defining them DYNAMIC?

Yes but not all function. Only public functions inside loaded .hrb
module will be available and static not. Anyhow I made mistake here.
In current code HRB modules are automatically unloaded if you do not
store return value with pointer to HRB module in some visible for HVM
variable. To eliminate this effect you can create your own procedure
like:

   proc my_hrbLoad( cHrb )
  static s_aHrbHandles := {}
  aadd( s_aHrbHandles, hb_hrbLoad( cHrb ) )
   return

and link it with the netio server.

BTW a small homework ;-) Test for HVM knowledge.
Find a method to register dynamically in HVM such function from
client side using NETIO server which is linked only with default
core functions without any custom extensions.

 I mean can it be a way to have dynamic non binary libs of functions?

Yes, you can load HRB modules or dynamic libraries which register new
functions and they will be available for RPC sever just like are available
for macro 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] 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 
 function being linked without knowledge or intent, 
 and keep verifying .map files to find out.

Any limits by function list are usually very easy to exploit.
As long as you do not plan to give access to some very small
set of functions then sooner or later hacker find a way to
pass some string to macrocompiler and make what he only wants
i.e. if you allow to execute ordListAdd() then he can create
index file with key expression having functions you wanted to
block, etc. Such things has to be resolved inside HVM. See
information I left about it in xhb-diff.txt at the end of
NAMESPACEs section.
Now instead of implementing feature which gives rather illusion
of security instead of real protection I suggest to add very
simply extension. User function which can be registered in
NETIO socket and executed instead of really requested functions
so if user thinks that such list is enough for him then he can
make sth like:

   static s_funcLst := { STR=, DATE=, TIME= }
   func mywrapper( sFunc, ... )
  if sFunc:name $ s_funcLst
 return sFunc:exec( ... )
  endif
   return nil

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:[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 
 function being linked without knowledge or intent, 
 and keep verifying .map files to find out.
 
 Any limits by function list are usually very easy to exploit.
 As long as you do not plan to give access to some very small
 set of functions then sooner or later hacker find a way to
 pass some string to macrocompiler and make what he only wants
 i.e. if you allow to execute ordListAdd() then he can create
 index file with key expression having functions you wanted to
 block, etc. Such things has to be resolved inside HVM. See
 information I left about it in xhb-diff.txt at the end of
 NAMESPACEs section.
 Now instead of implementing feature which gives rather illusion
 of security instead of real protection I suggest to add very
 simply extension. User function which can be registered in
 NETIO socket and executed instead of really requested functions
 so if user thinks that such list is enough for him then he can
 make sth like:
 
   static s_funcLst := { STR=, DATE=, TIME= }
   func mywrapper( sFunc, ... )
  if sFunc:name $ s_funcLst
 return sFunc:exec( ... )
  endif
   return nil

Perfectly fits what I had in mind.

Brgds,
Viktor

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[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 )


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?


Regards,
Mindaugas
___
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:[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 homework ;-) Test for HVM knowledge.
Find a method to register dynamically in HVM such function from
client side using NETIO server which is linked only with default
core functions without any custom extensions.


What does it mean with default core functions? Can I include 
HB_HRBLOAD()? Or this should be done without uncommenting REQUEST 
__HB_EXTERN__ in netiosrv.prg?


If linking of HB_HRBLOAD() is allowed, I propose solution:

homework2.prg (any functions to be registered):
FUNC Hello()
RETURN Hello, World! :)

homework1.prg (registrator module):
STATIC s_hHrb
INIT PROC LoadHello()
#pragma __streaminclude homework2.hrb|s_hHrb := HB_HRBLOAD(%s)
RETURN

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 code prints:
.T.
.T.
.F.
and application hangs up. I can not force HB_HRBLOAD() to work on server 
side, though:

  ? NETIO_FUNCEXEC(STR, 5.1, 7, 2)
prints the expected result.

Regards,
Mindaugas
___
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:[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 code prints:
.T.
.T.
.F.
and application hangs up. 


Sorry. It was a simple typo, should be:
   ? NETIO_PROCEXECW(HB_HRBLOAD, HB_MEMOREAD(homework1.hrb))
^ ^^^
This method works!

BTW, results for this test are:
C:\harbour\contrib\hbnetio\testshomework.exe

.T.
.T.
.F.
.T.
.T.
Hello, World! :)
C:\harbour\contrib\hbnetio\testshomework.exe

.T.
.T.
.T.
.T.
.F.
NIL
C:\harbour\contrib\hbnetio\testshomework.exe

.T.
.T.
.F.
.T.
.T.
Hello, World! :)
C:\harbour\contrib\hbnetio\testshomework.exe

.T.
.T.
.T.
.T.
.F.
NIL

I.e. every second time existing function is destroyed by unsuccessful 
overload. I'm not sure (not tested the details) if it is a bug in 
runner.c or some strange side effect, like: the second time code s_hHrb 
:= HB_HRBLOAD(...) is called, HB_HRBLOAD() fails because Hello() 
already exists. So, HB_HRBLOAD() returns empty value and destroys the 
last pointer to loaded hrb module in static variable. The next time 
module does not clashes with existing functions, so, it's loaded again.


Modification of homework1.prg solves the problem:
STATIC s_hHrb
INIT PROC LoadHello()
IF EMPTY(s_hHrb)
#pragma __streaminclude homework2.hrb|s_hHrb := HB_HRBLOAD(%s)
ENDIF
RETURN


Regards,
Mindaugas
___
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:[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
   * harbour/contrib/hbnetio/netiocli.c
   * harbour/contrib/hbnetio/netiosrv.c
 + implemented RPC in HBNETIO protocol
 

Time and again you through bliss on us in terms of highly useful 
and advanced features, this is one in those gems, thank you very much.

I can sense this commit is the basis for NETRDD or NETGT of future.
Am I right ?

Regards
Pritpal Bedi

-- 
View this message in context: 
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13489--trunk-harbour-tp27046268p27055352.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 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))
   ? NETIO_PROCEXISTS(HELLO)
   ? NETIO_FUNCEXEC(HELLO)
 RETURN
 Unfortunately test code prints:
 .T.
 .T.
 .F.
 and application hangs up.
 Sorry. It was a simple typo, should be:
? NETIO_PROCEXECW(HB_HRBLOAD, HB_MEMOREAD(homework1.hrb))
 This method works!

Yes and it's _exactly_ what I have in mind though I haven't thought
about using #pragma __streaminclude. Very nice solution.
Thank you very much.
It also shows what clever programmer can do if he knows well HVM
internals. It's enough to leave even small peace code and he can
make what he only wants and it's the reason why protection by
available function list can work only if this is rather short list
of small and simple functions well known that work without any side
effects.

 BTW, results for this test are:
[...]
 I.e. every second time existing function is destroyed by
 unsuccessful overload. I'm not sure (not tested the details) if it
 is a bug in runner.c or some strange side effect, like: the second
 time code s_hHrb := HB_HRBLOAD(...) is called, HB_HRBLOAD() fails
 because Hello() already exists.

It's not a bug. See include/hbhrb.ch.
HRB module was loaded with HB_HRB_BIND_DEFAULT what means:
   /* do not overwrite any functions, ignore
  public HRB functions if functions with
  the same names already exist in HVM */
So when it's loaded second time public HELLO() function still exists
in HVM as part of previously loaded module and the new one is ignored.
Just after loading the new module you cleared s_hHrb so the old module
with HELLO() function was unloaded so all is correct.

 So, HB_HRBLOAD() returns empty value
 and destroys the last pointer to loaded hrb module in static
 variable. The next time module does not clashes with existing
 functions, so, it's loaded again.
 Modification of homework1.prg solves the problem:
 STATIC s_hHrb
 INIT PROC LoadHello()
 IF EMPTY(s_hHrb)
 #pragma __streaminclude homework2.hrb|s_hHrb := HB_HRBLOAD(%s)
 ENDIF
 RETURN

Yes it's enough. Other solution is clearing the old module before
registering the new one so its public functions will not be used,
i.e.:

   STATIC s_hHrb
   INIT PROC LoadHello()
   s_hHrb := NIL // clear the old module
   #pragma __streaminclude homework2.hrb|s_hHrb := HB_HRBLOAD(%s)
   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] 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 guess that it's a
problem with socket initialization in windows builds. Please try:

   PROC main()
  HB_INETINIT()
  ? NETIO_PROCEXISTS(127.0.0.1:2941:STR)
   RETURN

We have in netiocli.c:

   HB_CALL_ON_STARTUP_BEGIN( _hb_file_netio_init_ )
  s_netio_init();
   HB_CALL_ON_STARTUP_END( _hb_file_netio_init_ )

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?

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:[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 code
should greatly help.

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:[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: 
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13489--trunk-harbour-tp27046268p27055841.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] 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 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 code
 should greatly help.




-- 
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour