[Harbour] Re: rddsetdefault

[Alexander S.Kresin]

Przemysław Czerpak writes:


I am with problem here.
Function Main
   REQUEST LETO
   RDDSETDEFAULT( "LETO" )
Error DBCMD/1015  Argument error: RDDSETDEFAULT
Called from RDDSETDEFAULT(0)
Is a problem of  RDD LetoDb correct?


Yes, it's LetoDb problem.
add to letodb/source/client/leto1.c just befor last line with
   #endif
this code:
   #elif defined( HB_DATASEG_STARTUP )
  #define HB_DATASEG_BODYHB_DATASEG_FUNC( leto1__InitSymbols ) \
 HB_DATASEG_FUNC( _hb_leto_rdd_init_ )
  #include "hbiniseg.h"



   Since what release this became necessary ? I ask this, because I 
need to add there ( __HARBOUR__ - 0 ) > some_value to provide 
compatibility with old releases.
   And why I didn't get rddsetdefault error without this fragment of 
code ( I tried a short test with Harbour 13587 ( 2010-01-14 18:21 
UTC-0800 Pritpal Bedi (prit...@vouchcac.com)) ) ?


Regards, Alexander.

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

[Harbour] Re: rddsetdefault

[Alexander S.Kresin]

Przemek,

  thanks for comments.


Probably you haven't used compiler which needs HB_DATASEG_STARTUP
initialization like MSC or OpenWatcom so it was not necessary to
register to change registration code. But here I only guess.


 Yes, I still use Bcc5.5.

Regards,
   Alexander.

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

[Harbour] gt for linux

[Alexander S.Kresin]

Hi All,

  for a few years I use for Harbour Linux console applications the 
gtcrs, but last time more and more new distributions goes with UTF8 
coding and gtcrs doesn't show national characters ( possibly, ncursesw 
should be used instead of ncurses, but this is other issue ).


  Which gt can I use now with distributions, based on UTF8, to see 
national characters properly ?


  I've tried gtxwc, but, most likely, I've missed something, and 
cyrillic characters was showed incorrectly, too. SO the second question 
is - what I need to set ( codepage, font, something other ... ) to see 
cyrillic letters properly with gtxwc ?


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Error compiling with + Hwgui Harbour.

[Alexander S.Kresin]

Leonardo,

 I've renamed few HwGUI's functions, including deletefile(), adding to 
them "hwg_" prefix.


Regards, Alexander.


I'm trying to compile my application with MSVC, and it returns me the errors
below, someone would give me a tip to avoid this error?

Note: Both the Harbour as Hwgui been compiled with MSVC 9.0 and Harbour SVN
is to the day 04/23/2009.

Note: If you compile with the error BCC5.5.1 not any.

***ERROR
hbmk: Linker command:
hbct.lib(files.obj) : error LNK2005: ya se definió _HB_FUN_DELETEFILE en
hwgui.lib(misc.obj)
LINK : fatal error LNK1104: no se puede abrir el archivo 'LIBC.lib'
***END ERROR

Leonardo Machado


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbmk2: any features still missing?

[Alexander S.Kresin]

Viktor Szakáts writes:

Hi All,

Is there any important feature still missing from hbmk2?



 Yes - documentation :), at least, very basic.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbmk2: any features still missing?

[Alexander S.Kresin]

> BTW, if there is anything unclear/incomplete in the current help, please
speak up,I'd like to make it usable.
> 

 Ok. The main thing, which is unclear for me from the help is about scripts.
 What are .hbm files, are they different from .hbp ?
 Are the "libs", "cflags", "ldflags", "libpaths", "gui|..." the only options
of .hbp, or there may be others ( I ask this, because I was supposed that,
as usually, such kind of files may include any option from command line ) ?
 The help says, that ".hbp option files in current dir are automatically
processed." What may be a reason of having few .hbp files in current
directory and processing all of them while building a project ?
 What filters may be intended for ? As I suppose, they limits the usage of a
library for a choosen platform. But why may I need to designate a library in
a command line ( -l ), if I don't use it for current build process ?

Regards, Alexander.





___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed.

[Alexander S.Kresin]

Hi All,


Application Internal Error - C:\letodb\bin\letodb.exe
Terminated at: 2009.05.18 17:22:09
Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed.


 The internal errors may be a problem for any kind of "NETRDD", they 
cause terminating of server's program in case of tables or index corruption.
 Maybe, we could refuse of using the hb_errInternal() in RDD code, 
replacing it with a common error handler ? Or, at least, add a 
possibility to set a callback function in hb_errInternal(), to be able 
output some additional info about a problem ?


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed.

[Alexander S.Kresin]

Hi All,


Application Internal Error - C:\letodb\bin\letodb.exe
Terminated at: 2009.05.18 17:22:09
Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed.


 The internal errors may be a problem for any kind of "NETRDD", they 
cause terminating of server's program in case of tables or index 
corruption.
 Maybe, we could refuse of using the hb_errInternal() in RDD code, 
replacing it with a common error handler ? Or, at least, add a 
possibility to set a callback function in hb_errInternal(), to be able 
output some additional info about a problem ?




 After thinking a bit I've inderstood that the second option ( callback 
function ) isn't needed, because I can simply override hb_errInternal(), 
placing a function with this name in my code. In letodb such function 
may write to the log all necessary info ( a problem table name, for 
example ) and close all tables before terminating.


But, anyway, I believe that RDD code shouldn't use the hb_errInternal(). 
Replacing it with a standard error handler is a very hard and unpleasant 
work, though ...


Regards, Alexander.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Source code formatter

[Alexander S.Kresin]

Hi All,

   for a long time I used Click to format prgs, but last time I get 
some problems with it and became to look for something other. The only 
one I've found is xMate, but it isn't convenient for me, because it 
doesn't include formatter as a standalone utility and to format a file, 
I need to create a project, add this file and open it with an editor. 
Besides, it have too few options and I can't format prg in a way I like.
   That's why week ago I've decided to wright the formatter myself and 
now I get it with the basic functionality, which is enough for me.


   If nobody has objection, I'll upload it to the utils/ directory. 
Could someone prompt me how to add new directory and files in it ( I 
never did it with SVN ) ?


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Source code formatter

[Alexander S.Kresin]

Yesterday I was thinking of committing a recently written
reindentor :)


 I had a feeling that I must hurry :)



Not a full blown formatter (like my tool 'DST'
was trying to be, written 17 years ago), but it can change
indentation (including continued lines), it assumes a properly
and consistently indented source, autodetects it and can
change this to any number of chars or tabs.



 Mine for now, if it is pointed in options, indents source, changes 
case of commands, functions and booleans, inserts/deletes empty lines 
and inserts spaces before/after operators and brackets, changes EOL.



Do you think we can make the default setup to produce
std Harbour .prg formatting?



 I plan to set default options in accordance of how Harbour's prg files 
are formatted now.


Regards, Alexander.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Source code formatter

[Alexander S.Kresin]

Paul,


Hi Alexander and All,

I ported Click to Harbour for use on Linux.  The code is untested on 
Windows but may compile and run.   Added "Calls to" information in 
function headers and made stand alone executable.  Need to update code 
in few days but current source and bin is posted on Google Code under 
harbourclick.

harbourclick 



  As I wrote before, I used Click for a long time, but there are some 
problems ( maybe, bugs ), which forced me to look for other formatter.


  Probably, because Click doesn't know about some Harbour's control 
structures, it moves comments to other lines sometimes.


  The real problems for me bacames when I tried to set 
CASE_OF_FUNCTIONS=LIKEINFILE. I thought that Click simply makes case 
conversion due to click.ini function patterns, but it tried to 
autocomplete some of them - this, of course, caused bugs in my source 
files, which I could find not immedeately (:.


  These all should be cleaned before using it with Harbour.

Regards, Alexander.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Formatter uploaded

[Alexander S.Kresin]

Hi All,

Since the automated procedure has been mailed only the Changelog entry 
header here, I post the whole entry ( possibly it's needed to update the 
doc/howtosvn.txt ):


2009-05-25 10:30 UTC+0300 Alexander Kresin 
  + utils/hbformat
  + utils/hbformat/hbformat.prg
  + utils/hbformat/hbformat.ini
  + utils/hbformat/Makefile
+ Harbour source formatter utility has been added. The command line 
to call it:

 hbformat [-r] [options] [...@config.ini] file[s]

  -r option ( recursive ) forces formatting files in all nested 
directories.
  Default options ( their values you may find commented in a 
provided hbformat.ini )
  provides the style, accepted in Harbour prgs. The hbformat.ini 
must be in the same
  directory, where the hbformat.exe is. You can use additional ini 
file and point to
  it in a command line with the '@' before it. Options in a command 
line are the same,
  which are in ini file - for example, -lCase=no forces to not make 
case conversion.


  * utils/Makefile
* Makefile has been changed to build the hbformat


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Formatter uploaded

[Alexander S.Kresin]

Just try to format hbformat.prg.
C:\dev\harbour_bcc\bin\>hbformat.exe hbformat.prg

Initialization error  3 on line 75 : nLineVar = -1



 That was an error reading the hbformat.ini, the program didn't 
undestand the -1 value.

 Now it's fixed.

 Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Alexander S.Kresin]

  * utils/hbformat/hbformat.ini
  + utils/hbformat/hbformat.hbm
  * utils/hbformat/hbformat.prg
  * utils/hbformat/Makefile
! Added SVN props.
+ Added hbformat.hbm (hbmk2 make file).
% Deleted forced MT mode from Makefile (not needed for hbformat)
! Separated C code from .prg.


Viktor, it seems, you forgot to add the hbformac.c.
BTW, what's bad in using #pragma BEGINDUMP ... #pragma ENDDUMP ?

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Source code formatter

[Alexander S.Kresin]

> If you can submit the smallest possible code fragments which display the 
> bad behavior, it would help the debugging process.

Ok. Below are two samples.
1) The code:

// --
CLASS HDBRecSet

   DATA aRecs// line1
 // line2
 // line3
   DATA cargo

ENDCLASS
// --

is converted by Click to:

// --
   // line2
   // line3
CLASS HDBRecSet

   DATA aRecs   // line1
   DATA cargo

ENDCLASS
   // --

2) ( CASE_OF_FUNCTIONS=LIKEINFILE) The code:

// ---
func XXX( handle )
Local cBuff

   Fread( handle, cBuff, 10 )
   dbCreate( "a1", arr )
   dbCommit()
return
// ---

is converted by Click to:

// ---
FUNC XXX( handle )

LOCAL cBuff

   Freadstr( handle, cBuff, 10 )
   Dbcreateind( "a1", arr )
   Dbcommitall()
RETURN
// ---

> If Click! doesn't work like you expect it to, it's broken and we can 
> work on fixing it.

Sure.

Regards, Alexander.




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbformat a bit too eager to convert files

[Alexander S.Kresin]

Chen,


Was looking at hbformat.exe (r11148 bcc32)
and trying to see if there is a command line help
I executed the following in the harbour bin directory:

hbformat ?

The eager program started converting ALL files in that
directory, did that very quick (before I had the chance
to stopped it), and stopped only when it choked on its
own EXE and exit with an RTE.

Is there an option to make the program more selective
on its file selection?



 It's fixed now. The program accepted '?' as a file mask symbol, but 
processed it incorrectly.


 The only help info available now, is the command line syntax, which 
appears, if you run the hbformat.exe without parameters. Information 
about options may be found in hbformat.ini. Command line options are the 
same as in ini file and override them. For example:


 hbformat.exe -cExtSave=new myfile.prg

will force the hbformat to save converted file with ,new extension ( in 
this case the extension of original file remains as it was before ).


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Mingw and hb_errInternal()

[Alexander S.Kresin]

Hi All,

 as I wrote before, I overloaded hb_errInternal() in letodb source 
file. Bcc and Linux gcc accepted this normally, but mingw gives error - 
multiply definition of hb_errInternal. Is there any way to solve this 
problem ?


Regards, ALexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Mingw and hb_errInternal()

[Alexander S.Kresin]

Massimo Belgrano writes:

I try a reply with information that i know.
You can't overload a function (hb_errInternal) but a module object 
represented by entire file prg.


 hb_errInternal() is the only function in the module ( errint.c ) - at 
least, at the version of Harbour I use, so I supposed that it's possible 
to overload it. I'll try to separate it, though.


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Mingw and hb_errInternal()

[Alexander S.Kresin]

Petr Chornyj writes:


I think you can try with

gcc ... -Wl,--allow-multiple-definition



 Yes, this helps, thanks.

 Now there is other problem - letodb.exe, compiled with mingw, doesn't 
run, it gives a message ".dll isn't found" ( 
 is a sequence of casual non character symbols ). Does 
anyone know why this could happen ?


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Mingw and hb_errInternal()

[Alexander S.Kresin]

Viktor Szakáts writes:

There should also be hb_errInternalRaw() (also public function) in
that source file.

"allow multiple definition" is very dubious to me, as there it's very difficult
to know for sure which of the multiple definitions will actually be effective
at runtime.


 I supposed that placing hb_errInternal() in a letodb kernel file, I 
guarantee that it will be called at runtime - that's why I didn't add 
the whole errint.c as a separate file.

 But, probably, having a separate errint.c is really a more clean way.
Anyhow, now the outstanding problem for me is that one I wrote in 
previous message - with that strange dll, which is demanded by 
letodb.exe, build with mingw.


 Regards, Alexander.


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Mingw and hb_errInternal()

[Alexander S.Kresin]

This is the only working solution, unless we move the other
function to a separate function inside Harbour source tree.
I'll do that.



  Probably, it isn't needed. I added the modified errint.c to letodb 
sources, it looks now like the following ( without headers ):


static BOOL   bErrHandlerRun = 0;
extern leto_errInternal( ULONG ulIntCode, const char * szText, const 
char * szPar1, const char * szPar2 );


void hb_errInternalRaw( ULONG ulIntCode, const char * szText, const char 
* szPar1, const char * szPar2 )

{

   if( szPar1 == NULL )
  szPar1 = "";

   if( szPar2 == NULL )
  szPar2 = "";

   if( !bErrHandlerRun )
   {
  bErrHandlerRun = 1;
  leto_errInternal( ulIntCode, szText, szPar1, szPar2 );
   }
   else
   {
  FILE * hLog;
  hLog = hb_fopen( "letodb_crash.log", "a+" );

  if( hLog )
  {
 fprintf( hLog, "Unrecoverable error %lu: ", ulIntCode );
 if( szText )
fprintf( hLog, "%s %s %s\n", szText, szPar1, szPar2 );
 fclose( hLog );
  }
   }

}

void hb_errInternal( ULONG ulIntCode, const char * szText, const char * 
szPar1, const char * szPar2 )

{
   hb_errInternalRaw( ulIntCode, szText, szPar1, szPar2 );

   /* release console settings */
   hb_conRelease();

   if( hb_cmdargCheck( "ERRGPF" ) )
   {
   int *pGPF = NULL;
   *pGPF = 0;
   *(--pGPF) = 0;
   }

   exit( EXIT_FAILURE );
}

bErrHandlerRun is used to prevent cycling if closing databases by 
leto_errInternal() will cause anouther internal error.



Quite strange, I've never seen that. Did you try to create letodb with
hbmk2? I would wonder if you'd get the same error. In case you do,
please post your MinGW version and -trace output.




 It's solved, as I just wrote.

Regards, ALexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Mingw and hb_errInternal()

[Alexander S.Kresin]

 Now there is other problem - letodb.exe, compiled with mingw, doesn't 
run, it gives a message ".dll isn't found" ( 
 is a sequence of casual non character symbols ). Does 
anyone know why this could happen ?




  It's solved. I've made an error in a Makefile ( I still don't 
understand clear enough all those $@ $^ ), which cause the following 
command line:


gcc -Wall -mwindows -oletodb.exe bin/letodb.exe obj\w32/server.o ...

and produces an interesting effect: probably, gcc tried to link 
bin/letodb.exe ( it was there, build by bcc ) in a resulting exe and 
link it (!) without warnings, and this resulting exe behaves so strange.


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Mingw and hb_errInternal()

[Alexander S.Kresin]

 > BTW, is there anything missing to use hbmk2 to build letodb?



  I don't know, I didn't tried it yet.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Mingw and hb_errInternal()

[Alexander S.Kresin]

> Attached new ones after minor update, this way it's enough to do this
> to create both targets:
> 
   Thank you, Viktor. I'll try it.

Regards, Alexander.




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Mingw and hb_errInternal()

[Alexander S.Kresin]

> 
> hbmk2 letodb.hbp rddleto.hbp
> 

  I've copied  these two files to the letodb directory, executed this
command and got the following:

hbmk: Processing configuration: c:\harbour\bin\hbmk.cfg
hbmk: Processing: letodb.hbp
hbmk: Processing: rddleto.hbp

hbmk: Error: No source files were specified.

What I did wrong ?

Regards, ALexander.





___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Formatter error (hwgui's prg)

[Alexander S.Kresin]

Alexey,

  thanks for the info. It's fixed now.

Regards, Alexander.


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Mingw and hb_errInternal()

[Alexander S.Kresin]

Viktor Szakáts writes:


Attached new ones after minor update, this way it's enough to do this
to create both targets:

hbmk2 letodb.hbp rddleto.hbp



 I've uploaded them with a minor modifications:

-oletodb   ->   -obin/letodb
-orddleto  ->   -olib/rddleto

The only problem I had is that I still use the official release 1.0.1. I 
 couldn't build exe with it, because I've got a message about lacking 
of hbuddall.lib. Maybe, it's normal that hbmk can be used only with the 
Harbour distribution where it is included, though ...

Or there is some way to exclude libraries from the default link list ?

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: OFF: letodb + MSVC errors

[Alexander S.Kresin]

Viktor Szakáts writes:

Hi Alexander,

'hbmk2 rddleto.hbp' results in this:
(after making makefile.vc work, it gave me the exact same result)



  Hm... I didn't compile it with a MSVC for a long time ( I even 
haven't MSVC ).

 I'll try to check it. Thanks for the info.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: OFF: letodb suggestions

[Alexander S.Kresin]

Viktor Szakáts writes:


Two macro solutions and better (automatic) replacements:
---
#if ( defined( HARBOUR_VER_AFTER_101 ) )
->
#if defined( __HARBOUR__ ) && __HARBOUR__ > 0x010100
---

---
#elif defined( HARBOUR_VER_BEFORE_100 )
->
#if ! defined( __HARBOUR__ )
---



 The problem is that __HARBOUR__ was defined before 1.00, but it hadn't 
a number, so with an old version


#if ! defined( __HARBOUR__ )

will always a FALSE and the

#if defined( __HARBOUR__ ) && __HARBOUR__ > 0x010100

will give the compile error.



[ both work only after #including any Harbour headers and when
__XHARBOUR__ is not defined. ]

If this is implemented in the code, there is no need to do
manual tricks with these macros


 I don't like this manual tricks, too, but I simply didn't find a way 
to do this with Harbour's __HARBOUR__, HB_VER_...


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Formatter error (hwgui's prg)

[Alexander S.Kresin]

vatzct writes:


I can't build hwgui after reformat the hwinprn.prg, see below:

MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
   c:\dev\harbour\bin\harbour.exe -iinclude;c:\dev\harbour\include -n 
-q0 -w -es2 -gc0   source\hwinprn.prg -oobj\b32\hwinprn.c


source\hwinprn.prg(290) Error E0020  Incomplete statement or unbalanced 
delimiters




  Yes, I see, it just added an empty line where is shouldn't - because 
it didn't notice the ';', it isn't a last char in the line, there is 
comment after it.

  I'll fix it.

Regards, ALexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: OFF: letodb suggestions

[Alexander S.Kresin]

This needs 'HB_PRE10' to be #defined for pre-Harbour 1.0.0 releases:
---
#if defined( __XHARBOUR__ )
   /* code for xhb */
#endif

#if ! defined( __XHARBOUR__ ) && defined( __HARBOUR__ )
   /* code for harbour */
#endif

#if ! defined( __XHARBOUR__ ) && defined( __HARBOUR__ ) && defined( HB_PRE10 )
   /* code for harbour-pre-10x */
#endif

#if ! defined( __XHARBOUR__ ) && defined( __HARBOUR__ ) && ! defined( HB_PRE10 )
   #if __HARBOUR__ >= 0x01 && __HARBOUR__ < 0x010100
  /* code for harbour-10x */
   #endif
#endif

#if ! defined( __XHARBOUR__ ) && defined( __HARBOUR__ ) && ! defined( HB_PRE10 )
   #if __HARBOUR__ >= 0x010100
  /* code for harbour-11x-or-upper */
   #endif
#endif
---


  For to not make many changes in the code, it will be enough to write 
in funcleto.h insead of


/* #define HARBOUR_VER_BEFORE_100 */
/* #define HARBOUR_VER_AFTER_101 */

the following:

/* #define HARBOUR_VER_BEFORE_100 */
#if ! defined( __XHARBOUR__ ) && defined( __HARBOUR__ ) && ! defined( 
HARBOUR_VER_BEFORE_100 )

   #if __HARBOUR__ >= 0x010100
  #define HARBOUR_VER_AFTER_101
   #endif
#endif

Thanks for the tip.


Things get simpler if you decide to drop support for very old Harbour versions:
---


 I don't like to force people to get rid of old versions without really 
serious reasons.


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: OFF: letodb suggestions

[Alexander S.Kresin]

It can be quite easy resolved for both C .prg preprocesors.
For C code instead of:
   #if defined( __HARBOUR__ ) && __HARBOUR__ > 0x010100
simply use:
   #if defined( __HARBOUR__ ) && __HARBOUR__ - 0 > 0x010100

and for .prg code instead of:
   #if defined( __HARBOUR__ ) .and. __HARBOUR__ > 0x010100
use:
   #if defined( __HARBOUR__ ) .and. __HARBOUR__ - 0 > 0x010100



  Great, thank you for a tip. I never knew about such trick.


I think that such auto detection is better and much safer then manual
setting by user.



  Indeed.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: OFF: letodb suggestions

[Alexander S.Kresin]

One reason will be that new harbour version is better and more stable 
and more powerfull


 Harbour versions before 1.00 was quite stable, too. I, for example, 
worked with the code, dated by 2008-01-25 ( don't know, what version it 
is :) ) till last month and have migrated to 1.01 because ... I don't 
know why :), but not due to problems or limitations with an old one.


In corner of letodb suggestion 
Is possible think a letodb server version as a service?


 Yes, I think. I haven't concern in this, because I don't know, what 
advantages letodb could get being a service.



letodb supoport all c compiler/platform supported by harbour?



 I've tested it on Windows ( bcc, msvc, mingw ) and on Linux.
 MSVC, though, doesn't compile current code, as Viktor informed today.

Regards, ALexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: letodb .hbc file

[Alexander S.Kresin]

Viktor,
> Would you mind adding this file to the letodb repository:
> ...

Thanks, I'll add it.

BTW, there are some problems with the letodb.hbp:
the letodb.exe, built with it ( bcc ) , creates a console box after
starting. I wanted to look at link options, but the only info is ( get with
-traceonly ):
ilink32.exe @C:\DOCUME~1\ALE\LOCALS~1\Temp\du48kl.lnk
and the du48kl.lnk is absent ( most likely, autodeleted ). I tried to set in
letodb.hbp options I use linking the letodb.exe:

-ldflag={bcc}-lGn -lTpe -laa

but it gives an error:
Fatal: Unable to open file 'TPE.LIB'

So, there are two questions:
how can I set the -lGn -lTpe -laa for a linker and is there a way to look at
used linker options ?

Regards, Alexander.





___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: letodb .hbc file

[Alexander S.Kresin]

> Maybe you run it with different parameters, or missed the output,
> but 'hbmk2 -traceonly letodb.hbp' should display even the content
> of the temp file above.

 Yes, really, it's here.
 
> 2) Instead of -aa I'd recommend -gui which enables the same switch for
BCC,

 Ok. it works.
 Now there is another problem, quite strange. Letodb.exe, built with hbmk,
gives an error creating dbf, which includes memos, while that one, built
with make_b32.bat, creates it normally ( I use the same client side exe for
both ). What may be a reason ?

Regards, ALexander.





___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: letodb .hbc file

[Alexander S.Kresin]

After some testing the solution turned out to be that
rddleto.lib got included in letodb after the addition of rddleto.hbc,
which had this effect on the end results. Probably rooted in
some symbol name clashes.



 Really. After updating the .hbp's it works properly. Thanks.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: letodb .hbc file

[Alexander S.Kresin]

> I recommend this command to build the whole package, with test program:
> ---
> hbmk2 [-hb10|-xhb] rddleto.hbp letodb.hbp -target=teststest_ta.prg
> ---

 I added this info to the readme.txt.

> This - and also x64 compatibility - can be fixed in
> source/client/leto1.c, by changing init section at the end with this:
> ...

 Thanks for the tip. Fixed now.

Regards, Alexander.





___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: letodb .hbc file

[Alexander S.Kresin]

> Find patch file attached.
> 

 Thanks, updated.

Regards, Alexander.




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: letodb .hbc file

[Alexander S.Kresin]

> Perhaps, Alexander, now you are back on hwgui, you will take note?
> 
  Sure.

Regards, Alexander.




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hwgui .hbp and .hbc files

[Alexander S.Kresin]

Viktor,

thanks for provided files.


If it's okay with you, please commit attached hbmk2 make files for hwgui.



  Uploaded


- I didn't deal with Linux targets, since I don't know anything about them.


  Ok, I'll try to create appropriate .hbp myself.

Regards, Alexander.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hwgui .hbp and .hbc files

[Alexander S.Kresin]

You missed the hwgui.hbc file.


 No, I didn't. It's on the place.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: How to simulate select ... where ... order by ... limit ... offset

[Alexander S.Kresin]

Lorenzo,


...
I know the index to use so I can use SET SCOPE to set the range, now
I'm looking to the best way simulate WHERE  ORDER BY 
 and LIMIT start, limit.

Any suggestion is welcome.



  I had wrote a set of functions many years ago, which interprets the 
full "select ..." query and executes it. The "LIMITS" clause isn't 
interpreted, though, because I never heard about it.

  I can send you working source file, if you need it.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: How to simulate select ... where ... order by ... limit ... offset

[Alexander S.Kresin]

Yes please.


 Sent to your private email.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: How to simulate select ... where ... order by ...limit ... offset

[Alexander S.Kresin]

Here isn't join, subselect, acces to remote table and many othes things.


 It doesn't support the keyword "JOIN" - probably, because this keyword 
 wasn't included in SQL standard at the time when it was written, but 
it supports the join operation itself:


select table1.num, table2.name, ... from table1, table2 where table2.num 
= table1.num and ...


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: dbu

[Alexander S.Kresin]

Now there is another problem: there are multiple versions of DBU
sources, the patch is for 5.2e version. (for RL it's 5.3, because I
cannot find 5.2e sources of it - If someone has them, could I
get it?)


 5.2e and 5.3 sources of RL seems to be identical.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: dbu

[Alexander S.Kresin]

Davor Siklic writes:


Maybe we can include another dbu clone, Alexander's dbc come in mind 
(Hello Alex :-))


Hi, glad to see you :)

I'm ready to provide dbc sources under common Harbour license.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: dbu

[Alexander S.Kresin]

Many thanks for this offer, we can for sure place it inside
'examples/dbc'. Feel free to commit it, or I can do it if you
send me the files.


 I'll commit it after reviewing and reformatting.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: dbu

[Alexander S.Kresin]

Plus now also EOL conversion is
needed, which again doesn't seem to have an easy and portable
*nix command.



 hbformat -nEol=2 -lIndent=no -lCase=no -lSpaces=no some_prg.prg

will change EOL to *nix without formating the content.
I can add an option to lowercase the filename, if needed :).

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: dbu

[Alexander S.Kresin]

Does it work with wildcards?
$ hbformat -nEol=2 -lIndent=no -lCase=no -lSpaces=no *.prg



   Yes, it does.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: dbu

[Alexander S.Kresin]

> Now our .dif files need native EOL (=hb_osNewLine()) format,
> while -nEol=2 seems to set fixed LF format. Can you add an
> option to convert to native EOL format?

 I'll do it.

Regards, Alexander. 




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Harbour forum tryout

[Alexander S.Kresin]

> Opinions from others? We need something more than
> silence :)

 I vote for this Sourecforge based phpBB forum.
PhpBB is, IMO, a very good engine, convenient to use. We shouldn't occupy
the comp.lang.clipper, it is intended for other issues and is a common
territory for Clipper and all Clipper clones.

Regards, Alexander.




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Debugger

[Alexander S.Kresin]

> I found small problem in debbuger
> when try to locate some text in source file debbuger chrashed:

 Fixed.

Regards, Alexander.




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Harbour forum tryout

[Alexander S.Kresin]

> There has been a Harbour Developers forum created on
> the Forums.
> 
> I'm not sure this is a very good idea, as it will split
> development flow and information between this list and
> the forum. So, for developers it can mean double effort
> to track what's happening and potentially lost or missed
> information.
> 

  I don't see any sense in adding developers forum, too. We told about users
forum, aren't we ? 

Regards, Alexander.




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Bug in HWGUI/CVS (for Alex Kresin)

[Alexander S.Kresin]

Sergio,

 I believe that this list isn't an appropriate place for HwGUI specific
issues. It will be better to use HwgUI developers mailing list
hwgui-develop...@lists.sourceforge.net ( to subscribe:
https://lists.sourceforge.net/lists/listinfo/hwgui-developers ) or the users
forum: http://sourceforge.net/forum/forum.php?forum_id=325950

 And, please, tell, what kind of error you get.

Regards, Alexander.




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Alexander S.Kresin]

> Hi Alexander,
> 
> I've tested latest rev on darwin, with CRLF input files and -nEol=0
> option, and the converted files still have CRLF, while hb_osNewLine()
> returns Chr( 10 ) on darwin.
> 
> What could be the problem?

  Fixed now. I was too lazy to check it on the Linux :).
BTW, now I discovered another problem - on the Linux the *.prg in a command
line is extended to a list of all prg's in directory ( I suppose, bash does
this ), but hbformat now handles only the one ( last ). Temporary decision
may be enclose the mask in quotes : "*.prg".

Regards, Alexander.





___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] HB_EXPORT for errorapi.c functions

[Alexander S.Kresin]

Hi,

 are there objections to make functions from rtl/errorapi.c ( 
hb_errNew(), hb_errPutGenCode(), ... ) HB_EXPORT ?

This could allow to build as dll third party RDD's, etc.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Alexander S.Kresin]

I'm attaching patch. Alexander please look at it.


 Thanks, Przemek, I'll review them.
 I'll need to add some code to provide compatibility with older Harbour 
versions and xHarbour.


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Alexander S.Kresin]

Hi Przemek,



This time it may be really hard.
Maybe it will be better to keep current code for older version and
start new branch.



 This way looks unacceptable for me, at least now. I haven't energy and 
time enough to support two versions of code.


 For now I've solved the problem partially - have fixed errors and 
didn't touch warnings. It works for the time being ...


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Alexander S.Kresin]

I updated the patch so now LETO can be compiled also by Harbour
and probably also by old Harbour though I haven't restored wrong
casting for [const] char|BYTE * strings so C++ some compilers
may refuse to compile LETO with xHarbour or old Harbour header files.
With C compilers it should work.



 I've noticed this message just now, I'll review the patches today.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

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

[Alexander S.Kresin]

Przemek,


I've just merge it with you recent leto CVS update.
It cleans nearly all GCC/MinGW warnings except few ones which
I think you should pacify yourself because they may be source
of real errors and I would only hide them. See below.
It also updates for UNICODE compilation in windows and cleanes
unsigned char * / char * usage what eliminates most of explicit
conversions so I was bale to add 'const' to declaration and now
compiler can catch and warn in all places where some literal strings
are passed unprotected. It should help in detecting possible corruption
of readonly area.


 I've uploaded these changes, all seems to work Ok. Thank you.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Incompatibility with Clipper in macro substitution

[Alexander S.Kresin]

Hi All,

Maybe, this issue was discussed already, but ...
This code gives an error with Harbour, but works with Clipper:

PROCEDURE main
PRIVATE arr[10], r

   arr[1] := "OO"

   r = 'arr[1]'
   &r += '*'// Runtime "Syntax error: &" with Harbour
   ? arr[1], r

Return Nil

Is this error or a feature :) ?

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Incompatibility with Clipper in macro substitution

[Alexander S.Kresin]

Hi Xavi,


Hi Alexander,

A small variation if it helps. :)



 I believe, that there are different ways to eliminate the problem ( 
each situation, which haven't ways out, have, at least, two ways out :) ).

 The point is - compatibility.
 One user from Russian Harbour forum write this sample as one of 
problems while migrating from xHarbour to Harbour...


Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Incompatibility with Clipper in macro substitution

[Alexander S.Kresin]

> I'll analyze deeper the problem and I'll fix it to make Harbour
> fully Clipper compatible. Probably in next week.
> 
   Thank you.

Regards, Alexander.




___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: letodb patch

[Alexander S.Kresin]

Pls find attached patch for letodb. Changes:
- Added *nix support to hbmk2 make files.
- Added HUISO to server CP list.
- Fixed -w3 warnings.

Instead of __LINUX__ macro, it's be probably better to
use __PLATFORM__UNIX, which is automatically defined by
Harbour.


  Thanks, Viktor.
  Uploaded, few lines reverted, though - in hs_opentable() function.
  cFlags is used and can't be a constant, cAlias will be used soon.

Regards, Alexander.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: letodb patch

[Alexander S.Kresin]

Just noticed I missed to add HB_CODEPAGE_HUISO to
the Harbour branch, to line #107 of server.prg, could
you add it?

BTW, I've added hbextcdp.ch to include all codepages
in Harbour rev 11797, maybe it'd be the best to use it
with these versions.



 Added.

Regards, Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] hbinet.c

[Alexander S.Kresin]

Hi,

first of all - Happy New Year to all of you!

I need to write few new socket functions, but have some problems with 
hbinet.c
This module introduces a special structure HB_SOCKET_STRUCT, which 
returns to harbour level socket functions.
To get this structure as a parameter it uses macro HB_PARSOCKET(n), 
which is defined as


#define HB_PARSOCKET( n ) ( ( HB_SOCKET_STRUCT * ) hb_parptrGC( 
hb_inetSocketFinalize, n ) )


Personally I don't understand what this mean, but this is half of a 
trouble, I could simply use it as it is. But if I want to pass to the C 
level function an array of these sockets and return to Harbour level an 
another array of sockets,  what function should I use to get them from 
array and put them there ?


The second problem is with hb_inetSocketFinalize.
I wrote few C socket functions, which uses that HB_SOCKET_STRUCT and for 
be able to compile them include all definitions from hbinet.c, but still 
get an error "Undefined symbol hb_inetSocketFinalize" - in the line with
HB_PARSOCKET(n). I didn't find a defition of this 
'hb_inetSocketFinalize' anywhere in Harbour ...


Regards,
  Alexander
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbinet.c

[Alexander S.Kresin]

On  Saturday, December 29, 2007, 13:12 Alexander S.Kresin <[EMAIL PROTECTED]> 
wrote:

ASK> The second problem is with hb_inetSocketFinalize.
ASK> I wrote few C socket functions, which uses that HB_SOCKET_STRUCT and for 
ASK> be able to compile them include all definitions from hbinet.c, but still 
ASK> get an error "Undefined symbol hb_inetSocketFinalize" - in the line with
ASK> HB_PARSOCKET(n). I didn't find a defition of this 
ASK> 'hb_inetSocketFinalize' anywhere in Harbour ...

 This problem is solved - the
  static HB_GARBAGE_FUNC( hb_inetSocketFinalize )
 is the declaration of hb_inetSocketFinalize() function and must be
 included to any other c file, using sockets, compatible wuth
 hbinet.c.

 

Regards,
 Alexander
http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: How to get the pid of a app started with run()?

[Alexander S.Kresin]

On Jan 8, 2008 8:40 AM, Lorenzo Fiorini <[EMAIL PROTECTED]> wrote:


I need to start several instances of the same Harbour app and I'd like
to create an html "console" interface to see which are running.


Googling I've found a way to dot it.

Is this safe?




 I think, yes.
 But isn't it simpler to use getpid() to determine the pid of a process 
instead of forking it ?


 Regards,
   Alexander.
 http://kresin.belgorod.su
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: How to get the pid of a app started with run()?

[Alexander S.Kresin]

Lorenzo Fiorini:

On Jan 9, 2008 10:53 AM, Alexander S.Kresin <[EMAIL PROTECTED]> wrote:


  But isn't it simpler to use getpid() to determine the pid of a process
instead of forking it ?


Probably yes but I didn't find viable examples.



 As I have understood just now, you need to get the pid from external 
process, not from inside - so the getpid() function can't help.

 Possible solutions are:
 1) using of KVM (kernel virtual memory interface) functions:
kvm_getprocs(), kvm_getenvv(), kvm_getargv(), ...
 2) processing of the output of ps command

Regards,
   Alexander.
 http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: How to get the pid of a app started with run()?

[Alexander S.Kresin]

Lorenzo Fiorini:

On Jan 9, 2008 10:53 AM, Alexander S.Kresin <[EMAIL PROTECTED]> wrote:


  But isn't it simpler to use getpid() to determine the pid of a process
instead of forking it ?


Can hb_fsPOpen in source/rtl/filesys.c be a start?



 Hm... I don't see how the hb_fsPOpen() code is related to this issue.
 The third way ( in addition to mentioned in my previous message ) is 
scanning the /proc directory. Each working process have appropriate 
subdir there with a name, which is a process pid. You can go through all 
that subdirs and read some files in them, 'cmdline', for example, keeps 
the command line, which was used to run the process.


Regards,
   Alexander.
 http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Strange Ascan behavior

[Alexander S.Kresin]

Hi All,

this is a short code fragment, which gives results, strange for me ( or 
I worked too much today ? :) )


#include "hbclass.ch"

function main
Local o

   o := HTest():New()
   Aadd( HTest():aObjects, o )
   ? Ascan(HTest():aObjects,o)// 0 ()
   ? Ascan(HTest():aObjects,{|o1|o1==o})  // 1 ( as expected )
   ?
return nil

CLASS HTest

   CLASS VAR aObjects  INIT {}
   METHOD New()   INLINE Self

ENDCLASS

first Ascan returns 0, second - 1 ...


Regards,
  Alexander

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Strange Ascan behavior

[Alexander S.Kresin]

On  Thursday, January 10, 2008, 17:33 Przemyslaw Czerpak <[EMAIL PROTECTED]> 
wrote:

PC> It's correct. ASCAN() uses EQUAL comparison not EXACTLY EQUAL comparison.

 That's clear.
 What I don't understand - how two objects can be EXACTLY EQUAL and in
 the same time NOT simply EQUAL.

Regards,
 Alexander
http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Strange Ascan behavior

[Alexander S.Kresin]

On  Thursday, January 10, 2008, 20:42 Przemyslaw Czerpak <[EMAIL PROTECTED]> 
wrote:

>>  What I don't understand - how two objects can be EXACTLY EQUAL and in
>>  the same time NOT simply EQUAL.

PC> Ask Clipper authors why:
PC> a:={}; ? a==a
PC> shows .T. and:
PC> a:={}; ? a=a
PC> causes RT error.
PC> We are only compatible but the decisions about above and ascan() behavior
PC> was not taken by us.

 Ok, thanks for explanations.


Regards,
 Alexander
http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Licence question

[Alexander S.Kresin]

Hi All,

 I do some work, which I plan to upload to Sourceforge as a new project 
with the same licence as Harbour.
 It includes, among other things, code from hbinet.c and net.c - I was 
need to rework them for purposes of my project.
Does the licence allow me to include that code to other files with 
Harbour licence ? Must I designate Giancarlo Niccolai, Ron Pinkas, 
Marcelo Lombardo, Przemyslaw Czerpak, Viktor Szakats, Luiz Rafael Culik 
as copyright holders in the new files or it is enough to mention them as 
original authors ?


 Regards,
  Alexander
  http://kresin.belgorod.su
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Licence question

[Alexander S.Kresin]

Phil Barnett пишет:

On Wednesday 23 January 2008 01:56:31 am Alexander S.Kresin wrote:

Hi All,

  I do some work, which I plan to upload to Sourceforge as a new project
with the same licence as Harbour.
  It includes, among other things, code from hbinet.c and net.c - I was
need to rework them for purposes of my project.
Does the licence allow me to include that code to other files with
Harbour licence ? Must I designate Giancarlo Niccolai, Ron Pinkas,
Marcelo Lombardo, Przemyslaw Czerpak, Viktor Szakats, Luiz Rafael Culik
as copyright holders in the new files or it is enough to mention them as
original authors ?


You cannot remove their copyright from the files.


 Just to be clear: I don't want to infringe their interests in any way :).
 If I include those files with my modifications in a new project - then 
the answer is clear - as yours.

 But I want to use parts of that code in other files.
 Just for example:

 I need to include to my file aaa.c a function netname() from net.c, 
modified in such a way that it can be call from a C level - with a name 
aaa_netname(). Can I do this, or I must include the original net.c ?


 Regards,
  Alexander
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Licence question

[Alexander S.Kresin]

If you will duplicate HBINET cod in other project then such extension
will not work for you so I strongly suggest to invest time in updating
Harbour API. If you present what you exactly need then I can help in
this job.



 I'd prefer to not duplicate hbinet.c and make all necessary 
modifications there, too. But I don't sure that all my changes will be 
suitable for others.

 I've made already all what I need now.
 First of all - C level API. Appropriate functions are rewritten, so 
the  Harbour level functions ( HB_FUNC(...) ) are wrappers over those C 
level functions. This is made, though, only for the basic functions, 
which I need - connect, accept, send, receive, select.

 Secondly, I've added functions to select from multiply sockets.
 And, finally, and this is what, probably, will not be suitable for 
others - I got rid of the HB_SOCKET_STRUCT and appropriate stuff, so the 
sockets are directly passed as parameters and returned, assuming that 
included in HB_SOCKET_STRUCT things may be moved to Harbour level, if 
needed in specific application.
 I did this to make the code less complicated, to simplify writing 
additional functions - now, due to the hb_inetSocketFinalize() and all 
related gc things I can't place new functions in other file ( see the 
hbinet.c thread ).


 The project I'm working on is a db server with appropriate rdd as a 
substitution for ADS. ADS is a perfect product, but it isn't free and it 
 is quite expensive. Besides, writing such a server specially for 
Harbour will help to avoid some problems, which ADS has ( now to solve 
them we need to invent different workarounds ). And, finally, we can 
implement some new interesting stuff - as server-side harbour level 
procedures, for example.
 I've wrote basic part already, and few my applications works perfectly 
with it ( including such a big as Personnel and Salary accounting ).


 Regards,
   Alexander.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Licence question

[Alexander S.Kresin]

Przemyslaw Czerpak writes:

 And, finally, and this is what, probably, will not be suitable for 
others - I got rid of the HB_SOCKET_STRUCT and appropriate stuff, so the 
sockets are directly passed as parameters and returned, assuming that 
included in HB_SOCKET_STRUCT things may be moved to Harbour level, if 
needed in specific application.


So you introduced very serious limitations for your own code.
Harder portability and you you will not be able to use other type
of connections when we will add them. HB_SOCKET_STRUCT should hide
platform and protocol differences.


  I don't see limitations here. Server part is written mostly on 
Harbour, at least those parts, which works with sockets - at Harbour 
level there is no differense, what kind of data the socket is, the only 
operation with it is pass it to appropriate socket function ( from 
hbinet.c or any other ).
  The C level socket API is used in client part, because the RDD is 
written on C. I don't see serious problem here, too, because I'm sure 
that in the case of necessity appropriate separated parts can be easily 
adopted.



Can you give me any reason why you are not using PHB_ITEM pointers
but low level OS handles directly?


 The main reason was that I cannot place my additional socket functions 
not in hbinet.c, but in my source files without making 
hb_inetSocketFinalize() public - I suppose that if it is static, there 
are reasons for it.
 The second is that I don't understand why hb_parptrGC(), 
hb_inetSocketFinalize() are used instead of usual hb_parptr() and how to 
work with them, I found it more easy for me to rewrite appropiate parts 
of code than dig in it :).



I saw this thread and I thought that Mindaugas perfectly explain that
it's not necessary to touch socket internals at all and there is no
problem with hb_inetSocketFinalize() at all. You only need C level API
to access Harbour sockets and of course we should add it. It will be
very small modification so I can give it even today if it helps you.


  It's very appreciated. And with hb_inetSocketFinalize() public :).

 >>  I've wrote basic part already, and few my applications works 
perfectly

with it ( including such a big as Personnel and Salary accounting ).


Again, It's very nice news. And if you can updated your code to use
PHB_ITEM pointers as connection handles then I'll add Harbour public
socket API ASAP.


 Almost nothing should be updated there. Just a type of socket variable 
in the workarea structure and calls of it in a couple of functions.


 Regards,
   Alexander
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Licence question

[Alexander S.Kresin]

Maurilio Longo writes:


Alexander,
very interesting!
Is your server using .dbf/.cdx files?


 Yes.

 Regards,
   Alexander

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Next Beta Release

[Alexander S.Kresin]

Phil Barnett writes:

Przemek,

Are we ready to do another beta release?


 Why Beta, Phil ?
 It has no a big importance for me how the current version is called, 
simply I don't see any reason to consider it Beta.


Regards,
  Alexander
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: Licence question

[Alexander S.Kresin]

Massimo Belgrano writes:

your project support optimized set filter?


  I don't sure what kind of optimization are you mean.
The server which I write, supports, of course, server-side filtering - 
so it may be called "optimized" :).



I have an application who made intensive use of ads optimized set filter
how can try with your db server?


After it will be uploaded.


Why not add your project in harbour cvs?


Harbour's contrib section is overfilled, IMO. We discussed here some 
time ago making it a separate Sourceforge project.
That db server isn't a single library, it includes server itself, rdd 
library, management utility and, probably some more stuff ( I've started 
to do it less than month ago ). So it seems to me more convenient to 
have it as separate project.



Will be intresting Having a standard Client Server in harbour tanks to a
db server with appropriate rdd 
The server side can be windows/linux/ ?


Yes. But personally I think more about Linux version.


Which name have your project of dbserver?


It hasn't a name yet. This usually is a problem for me :)

Regards,
  Alexander.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Licence question

[Alexander S.Kresin]

On  Thursday, January 24, 2008, 17:14 Przemyslaw Czerpak 
<[EMAIL PROTECTED]> wrote:



  The C level socket API is used in client part, because the RDD is
written on C. I don't see serious problem here, too, because I'm sure 
that in the case of necessity appropriate separated parts can be easily 
adopted.


PC> So how it will work with compressed socket when we add native
PC> support for stream compression?

 Just borrowing appropriate piece of code. I hope that such important
 additions won't come every month :).

PC> And what if Harbour socket will not have usable OS handle at all
PC> on some platforms? What if it will be necessary to hide some
PC> OS dependent differences? F.e. select() works a little bit different
PC> in MS-Windows then in *nixes. Even between *nixes there are some
PC> important differences in this function. Do you know these differences?

 No. But I tested my code under both XP and Linux and didn't find any
 difference. Maybe, I didn't dig deeply enough, though.

PC> Can you tell me what functionality is necessary for you?

  See below.

PC> If it will be portable then we will add it to hbinet.c.
PC> There is absolutely no reason to make hb_inetSocketFinalize
PC> public until we want to keep sockets internals 3-rd party
PC> code independent and easy expandable.

 So, you confirm that hbinet.c can't be extended by 3-rd party 
libraries and if someone need any changes or additions, he have to 
modify the hbinet.c. And what if this changes aren't fully portable or 
suitable for general use, but satisfy his specific needs ? Isn't this a 
limitation, too ?


 The second is that I don't understand why hb_parptrGC(), 
hb_inetSocketFinalize() are used instead of usual hb_parptr() and how to 
work with them, I found it more easy for me to rewrite appropiate parts 
of code than dig in it :).


PC> The answer is very simple. .prg code should protect against low level
PC> errors like GPF. hb_parptrGC() validate if given pointer is a pointer
PC> to valid socket structure. hb_parptr() will also work but it will accept
PC> all possible pointer items not only these one which point to socket
PC> structure. Look at HWGUI. There is no validation at all so user can pass
PC> wrong pointers or handles to functions which will accept them and later
PC> GPF. Such code is unsafe. We should always try to write code as safe
PC> as possible.

 You are right. Harbour's rtl is written for general use and this code 
may be used in any kinds of applications, including those, where this 
kind of safety is important - I mean, first of all, pieces of code, 
which are intended for executing by some server.
 In case of common desktop applications it is, IMO, isn't important. 
Imagine, that programmer made a mistake and pass some bad word :) 
instead of a handle to a function. Only his desktop application will 
crash and after some time of hunting he will find that mistake. And, 
probably, in case of GPF it will be more easy to identify the mistake 
than if the GPF doesn't occur and he get some 'strange' application 
behavior. That's why, for example, I don't worry about such things in 
HwGUI - as any other GUI library, it is intended for desktop applications.
 In the case of rdd for the db server it isn't an issue at all, because 
the socket handle is hidden in workarea structure.


PC> As I said it's not necessary at all and so far you haven't answer
PC> why you need it. Again, please tell me which additional functionality
PC> is necessary for you and I'll add them to hbinet.c.

Ok. Below are the functions I've added:

static fd_set rd_fds, active_fds;
static unsigned int rd_maxfd;

HB_FUNC( HB_IP_RFD_SET )
{
   HB_SOCKET_T hSocket = (HB_SOCKET_T)hb_parnl(1);

   if( !hSocket )
   {
  return;
   }

   HB_SOCKET_ZERO_ERROR();

   FD_SET( hSocket, &rd_fds );
   rd_maxfd = ( rd_maxfd > hSocket )? rd_maxfd : hSocket;
}

HB_FUNC( HB_IP_RFD_ZERO )
{
   FD_ZERO( &rd_fds );
   rd_maxfd = 0;
}

HB_FUNC( HB_IP_RFD_CLR )
{
   HB_SOCKET_T hSocket = (HB_SOCKET_T)hb_parnl(1);
   FD_CLR( hSocket, &rd_fds );
}

HB_FUNC( HB_IP_RFD_SELECT )
{
   struct timeval tv = {0,0};
   int iTimeOut;

   if( hb_pcount() == 1 )
   {
  iTimeOut = hb_parni( 1 );
  tv.tv_sec = iTimeOut / 1000;
  tv.tv_usec = (iTimeOut % 1000) * 1000;
   }
   active_fds = rd_fds;

   iTimeOut = select( rd_maxfd + 1, &active_fds, NULL, NULL, &tv);

   hb_retni( iTimeOut );
}

HB_FUNC( HB_IP_RFD_ISSET )
{
   HB_SOCKET_T hSocket = (HB_SOCKET_T)hb_parnl(1);
   hb_retl( FD_ISSET( hSocket,&active_fds ) );
}

 I know that this code isn't proper for general use, because it uses 
one static rd_fds and, so this set of functions can't be used for 
selecting concurrently from two sets of sockets. But it fully satisfies 
my needs - at least now.


Other small change is that I've added 3'rd value of iMode to read and 
send functions - to avoid the call of hb_selectReadSocket(), because I 
check the socket before calling send() and receive() every time and 
don't need 

Re: [Harbour] Re: Licence question

[Alexander S.Kresin]

Massimo Belgrano writes:

I confirm it was at http://www.idep.org.uk/xbase


 Now the link is broken.


As name for upcoming project I suggest netrdd in honor to Przemek's
original Idea



 Hm... NETRDD is a RDD, not a server.
And probably, Przemek will decide to implement it himself at some time, 
who knows ...


 Regards,
  Alexander.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] hbini error

[Alexander S.Kresin]

Hi All,

 I tried to test the hbini module and have no success.
This short sample:

Function Main
Local aIni := HB_IniRead( "a1.ini" )
Return

where a1.ini is:

[abcd]
ppp=xyz

gives an error:

ERROR BASE/ Argument error: LEN
Called from LEN(0)
Called from HB_INIRDLOW(154)
Called from HB_INIREAD(106)
Called from Main(2)

 Could someone, who ported it from the xHarbour, look at it ?


Regards,
  Alexander
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbini error

[Alexander S.Kresin]

Lorenzo Fiorini writes:

On Jan 25, 2008 11:13 AM, Alexander S.Kresin <[EMAIL PROTECTED]> wrote:


  I tried to test the hbini module and have no success.


I've tried it under Linux/Fc8 and I see the "Ok".



 After rebuilding Harbour with latest sources ( previous was from 
17.12.2007 ) it works here, too.

 Sorry for a confusion.

Regards,
  Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Licence question

[Alexander S.Kresin]

On  Friday, January 25, 2008, 23:46 Szakбts Viktor <[EMAIL PROTECTED]> wrote:

SV> Just an idea (if NETRDD is occupied):
SV> CLIRDD
SV> THINRDD

SV> After all I see no reason why an RDD couldn't have
SV> a server and a client part and still called an RDD.
SV> (the client part would have to called RDD anyway IMO)

SV> Brgds,
SV> Viktor

SV> On 2008.01.25., at 15:35, Massimo Belgrano wrote:

>> NetcsdNet client server dbf
>> Dbf.net
>> Net.hds Harbour Database server by net

 I don't like such kinds of abbreviations, they pretend to be
 informative, but aren't informative in fact and are difficult to
 pronounce, to hear and to differ one from another. All those
 abcdeGUI and ghklmnRDD ...
 
 My first idea ( which presents in current code in form of server's
 welcome message and RDD methods prefixes ) was: "Harbour remote db
 server" for a server and rmtrdd ( rmt - remote ) for RDD. But I don't
 like it because of the above ( yet another ghklmnRDD ) and because I
 don't sure that 'remote' is a proper name.
 
 Now I want to call it 'Leto': 'Leto db server', letoRDD, rddleto.lib,
 letoSkipRaw() method ...
 'Leto' is a 'summer' on Russian.
 Why summer ? Because I like it and I miss it much :). Maybe because
 'Summer' was the first Clipper version, which many of us started
 with.
 Why on Russian ? I think that using of national languages gives
 additional colors. And because if it will be named 'Summer', everyone
 will ask 'Why Summer ? How it is related to the ...' :), while 'Leto' is a 
incomprehensible word
 for many people and will not cause such a questions :). And it is simple
 to pronounce and not unattractive for an ear.
 

Regards,
 Alexander
http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Leto DB Server

[Alexander S.Kresin]

Hi All,

 finally I've created this project and uploaded initial files to CVS - 
http://sourceforge.net/projects/letodb/.
Release packages are available, too - letodb-0.1.src.zip and 
letodb-0.1.src.tar.gz.


 There are server itself, rdd and management utility - this one is 
written for HwGUI, but I'll add a console utility later for to not force 
people use HwGUI.


 Of course, it's far from production state yet, but can be used for 
some tasks if there aren't many users.


 The socket library is an adopted and truncated hbinet.c I've talked 
about. If and when there hbinet.c will be modified, it may be used instead.


 Currently the server uses a simplest sequential mode, when each query 
is processed one after another. We haven't threads yet in Harbour, so I 
plan to use processes to work up queries, which demands more time ( 
indexing, walking through the filtered database, etc. ).


 The server main cycle and queries recognition is made in simplest way 
now - I wanted to have it working as soon as possible. Later it should 
be rewritten as C routine, I think.


 Not all basic methods are implemented yet ( scopes aren't, for example 
) - I did those, which I use in my programs to be able to test it.
 The server is up for few days in my server at work, sometimes I open 
up to 15 client programs from different workstations - and it works :).


 Regards,
  Alexander
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Leto DB Server

[Alexander S.Kresin]

Szakáts Viktor writes:

Hi Alexander,

Great stuff again, thanks a lot.

Would it help you to eliminate net.c, if I'd create
a C level version of NETNAME()?



 Yes, of course, but I will still need to leave it for some time for 
those, who don't use latest code and for xHarbour users.


 Regards,
  Alexander.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: CHANGELOG: 2008-01-31 17:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)

[Alexander S.Kresin]

On  Thursday, January 31, 2008, 19:47 Szakáts Viktor <[EMAIL PROTECTED]> wrote:

SV>  [ ... ]
SV>* source/rtl/net.c
SV>* include/hbapi.h
SV>  + Added hb_netname() and hb_username() low level versions 
SV>of NETNAME() and hb_USERNAME().


 Thanks, Viktor.


Regards,
 Alexander
http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Leto DB Server

[Alexander S.Kresin]

Pritpal Bedi writes:


Hello Alexander


Alexander S.Kresin wrote:

  finally I've created this project and uploaded initial files to CVS -
http://sourceforge.net/projects/letodb/. Release packages are available,
too - letodb-0.1.src.zip and letodb-0.1.src.tar.gz.



I need write permissions, if you agree. My SourceForge ID = vouchcac.

Regards
Pritpal Bedi, INDIA-USA



 You has been added to the developers list.

Regards,
  Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Version numbers suggestion

[Alexander S.Kresin]

 Hi All,

 it become more and more difficult for 3-rd party products developers
 to fight with differences between Harbour and xHarbour and between
 versions of the same compiler.

 Just a couple of examples.
 
 1) At() - hb_At() issue in Harbour. As a result now we have At() in
 xHarbour and in official Harbour distribution, which accept 4
 parameters, At() in new Harbour code, which accepts only 2 and
 hb_At() in new Harbour, accepting 4 parameters, which is absent in
 xHarbour and in older Harbour.
 The only decision I've found to get a code, working with ALL
 versions, is to duplicate hb_At() with a new name in my code ( HwGUI,
 Leto db server ).

 2) Recently the base workarea structure was changed in xHarbour. You
 know that every RDD have it's own workarea structure with first
 fields from a basic and some other, specific for this RDD, after the
 basic, and this structure is kept in a new header file.
 Now, if I want to keep the Leto RDD working for both Harbour and
 xHarbour, it's latest and previous versions, I need to provide two
 header files and leave a note for users of latest xharbour to rename
 xrddleto.h to rddleto.h before compiling the RDD.

 I understand and agree that such kind of changes is unavoidable and
 suggest the following:

 1) Introduce a [x]Harbour internal version number, at least, at C
 level for to be possible to use constructions like
 
 #if HARBOUR_VERSION >= 188

 and increment this number after every change, which may require
 changes in 3-rd party code ( not 3-rd party only, end applications,
 too ).

 2) Try to do such changes together with other changes of this type
 for to have too much version numbers.

 3) Create a special log in [x]Harbour repository for such changes -
 for people could know what they need to correct and don't spend hours
 looking the root of a problem.

 4) It would be nice to introduce such version number and appropriate
 pp possibilities on Harbour level, too.

 I ask xHarbour developers, who read this list, to discuss the
 possibility to introduce such a C level version number - for now, at
 least, in hbapirdd.h, something like #define WORKAREA_VERSION NNN, to
 be possible for 3-rd party RDD creators to write in new RDD structure
 definition:

 #ifdef __XHARBOUR__
 #if WORKAREA_VERSION >= NNN
USHORT uiFieldHidden; /* Total number of fields hidden */
 #endif
 #endif

 It's not my only problem, the same is for other RDD's - Mediator, for
 example.
 

Regards,
 Alexander

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Version numbers suggestion

[Alexander S.Kresin]

On  Saturday, February 02, 2008, 22:53 Szakбts Viktor <[EMAIL PROTECTED]> wrote:

>> 2) Recently the base workarea structure was changed in xHarbour. You
>> know that every RDD have it's own workarea structure with first
>> fields from a basic and some other, specific for this RDD, after the
>> basic, and this structure is kept in a new header file.
>> Now, if I want to keep the Leto RDD working for both Harbour and
>> xHarbour, it's latest and previous versions, I need to provide two
>> header files and leave a note for users of latest xharbour to rename
>> xrddleto.h to rddleto.h before compiling the RDD.

SV> Wouldn't this work ?:
SV> #ifdef __XHARBOUR__
SV> #include "xrddleto.h"
SV> #else
SV> #include "rddleto.h"
SV> #endif

 Yes - for respecting the difference between Harbour and xHarbour
 workareas, but not - for the difference between xHarbour's official
 release and it CVS code.

SV> I think we already have that on Harbour level, where
SV> __HARBOUR__ will return you a number.

 I didn't know that. Thanks for a tip.
 

Regards,
 Alexander
http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: [LetoDB] Error Building Utils\Manager

[Alexander S.Kresin]

Mario H. Sabado writes:


Hi,
I got the following error building LetoDB Manager.  Thanks for any help.
[ ... ]

 > Error: Unresolved external '_HB_FUN_TRACELOG' referenced from

D:\HWGUI\LIB\HWGUI .LIB|hedit


 Someone forgot to remove his ( xHarbour specific ) debugging stuff 
from HwGUI code.
 Just comment or remove the line with a tracelog() call from the 
hwgui/source/hedit.prg



Regards,
  Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Version numbers suggestion

[Alexander S.Kresin]

I've found accidentally this message on a 
http://lists.harbour-project.org/, but it's absent in my mailbox.


Przemyslaw Czerpak writes:

> Now I suggest to use HB_AT() and add to your project HB_AT() function
> for xHarbour build until xHarbour will not support it.

>   #ifdef __XHARBOUR__
>  HB_FUNC( HB_AT ) { HB_FUNC_EXEC( AT ); }
>   #endif

 This could be a decision if we had Harbour/xHarbour issue only. But 
what to do with Harbour distributions, including a latest offical 
release ? That's why we need an internal version number.


,---
| >  2) Recently the base workarea structure was changed in xHarbour. You
| >  know that every RDD have it's own workarea structure with first
| >  fields from a basic and some other, specific for this RDD, after the
| >  basic, and this structure is kept in a new header file.
| >  Now, if I want to keep the Leto RDD working for both Harbour and
| >  xHarbour, it's latest and previous versions, I need to provide two
| >  header files and leave a note for users of latest xharbour to rename
| >  xrddleto.h to rddleto.h before compiling the RDD.
`---

> And this I'd like to dedicate to you ;-)

 :).

[ ... ]
> In summary it seems to be xHarbour only problem and you should ask
> xHarbour developers about it.

 Patrick, Ron, Brian, are you hear us :) ?

Regards,
  Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Leto db server - build2

[Alexander S.Kresin]

 Hi All,

next build of a Leto db Server is uploaded to Sourceforge.
Al incompatibilities with different Harbour/xHarbour versions are 
eliminated. Fixed few bugs, added few basic methods.


Those, who use latest Harbour sources, need to change library names in 
makefile.bc.


It would be very interesting if anyone, who are able to build Harbour 
for mobile devices, tested how a client program on a smatrphone or 
pocket pc works with a Leto db, installed on some server.


Regards,
  Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: 2008-02-04 09:31 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

[Alexander S.Kresin]

On  Friday, February 08, 2008, 5:12 Przemyslaw Czerpak <[EMAIL PROTECTED]> 
wrote:

PC> Brian, can you ask extended system if we can have ace.h in
PC> our SVN/CVS repositories?

 I had requested for such permission in December, 1999. And I got an
 answer from them, which I immedeately posted to this mail list.

 Here is this answer:

===
"The full source thing answers the question.  We should not care if
ACE.H
gets distributed as part of the Harbour source.  The copyright notice
needs
to be maintained, though.  Alexander may want to add some information
somewhere about where to get updates if necessary (i.e. the Advantage
web
site)."

This is the reply I got from Mike Lydon our R&D manager.  You should
have
all the software.  Just add a copyright notice to your licensing and
that
should work.  



Bill Schuler
Database Products
Southeast Sales Manager
Phone (800)235-7576 ext. 6051
  (208)322-7575 ext. 6051
Fax   (208)327-5006
[EMAIL PROTECTED]
5777 N. Meeker Ave. 
Boise, ID 83711
http://www.advantagedatabase.com
http://solutions.advantagedatabase.com



Regards,
 Alexander
http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] C level error api

[Alexander S.Kresin]

Hi All,

 have we a C level error api ? In other words, are there C level 
functions to catch up errors, which on prg level we handle with BEGIN 
SEQUENCE ... END SEQUENCE ?


Regards,
  Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: __HRBLOAD of a string

[Alexander S.Kresin]

On  Sunday, March 02, 2008, 12:44 Lorenzo Fiorini <[EMAIL PROTECTED]> wrote:

LF> Could __HRBLOAD get the input from a string?

 Yes. The first parameter may be a filename or a string with hrb
 content.
 

Regards,
 Alexander
http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: Time for a release?

[Alexander S.Kresin]

Przemyslaw Czerpak writes:


And second thing. I would like to ask someone to control the release
process. Can some of you do it?


  If you mean creating release and packages on a Sourceforge - I can.
  What I don't know is how to tag the SVN as I did this with CVS.

 Regards,
  Alexander.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Leto DB build 5 has been released

[Alexander S.Kresin]

All basic RDD functionality has been implemented. Relations, orderListAdd, 
orderListClear has been added.

The server works im multithread mode now. First thread listen sockets,
accept connections and answers to commands, which doesn't demand database 
access and Harbour's VM/stack functions.
The second answers to all other commands.

DBFNTX support has been added. The driver, which will be used to open a table ( 
DBFCDX or DBFNTX ) is determined
 at server side from the letodb.ini - see readme.txt for details.


Regards,
 Alexander
http://kresin.belgorod.su

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour