Re: [Harbour] Przemys?aw
On Sun, 14 Sep 2008, [EMAIL PROTECTED] wrote: > >But the encoding in header is correct now: utf-8 and message was also in > >utf-8. > >If you cannot see it then it simply means that you do not have such character > >in your font or your reader wrongly decoded it. > >>From my old system I was sending messages in ISO-8859-2. BTW have you seen > >the slashed L in these messages? > Hi Przemek, your old messages, I see 'Przemyslaw Czerpak' and now I > see Przemys?aw I see, just simply in my old account I used 'l' letter instead of 'ł'. If this will be big problem for you then I can use 'l' letter though it's not correct one ;-) The encoding is not correct but I have to also change encoding in ChangeLog messages which are sent automatically when I commit sth. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13174] trunk/harbour
On Wed, 09 Dec 2009, Mindaugas Kavaliauskas wrote: Hi, > Przemysław Czerpak wrote: > >>Perhaps copy-paste from some of my contrib RDDS. BTW, why RDD has > >>this in symbol table? > >It's necessary for *_GETFUNCTABLE function which is accessed from > >hb_rddRegister() by global symbol table. > Yes, but this answers why f.e. DBFCDX_GETFUNCTABLE is included into > symbol table in dbfcdx1.c. But why DBFCDX is also in symbol table? I > can not find any usage of this symbol in hb_rddRegister(). There are no technical reasons to register it. I can only guess that at the beginning when someone created code to register _GETFUNCTABLE() then he also added () to the symbol table and so far we are using the same method. The exception is only RDDADS library where only one of ADS* RDDs can be requested but all are available so it's good to register all symbols to make type( cRddName+"()" ) working for all available RDDs not only the one which was explicitly REQUESTed. > Do you think it will be a good practice to add a define like: > #define HB_CAIRO_REQUEST_EXTERN > #include "hbcairo.ch" > and put request for all library functions into hbcairo.ch inside ifdef? > Define name can have another structure is this is not suitable: > HB_CAIRO_EXTERN, HB_CAIRO_REQUEST_LIBRARY, HB_EXTERN_CAIRO, etc. Probably HB_CAIRO_EXTERN and HB_CAIRO_DYNAMIC so in the header file we can make: #undef HB_CAIRO_REF #if defined( HB_CAIRO_DYNAMIC ) #define HB_CAIRO_REFEXTERN #elif defined( HB_CAIRO_EXTERN ) #define HB_CAIRO_REFDYNAMIC #endif #ifdef HB_CAIRO_REF HB_CAIRO_REF HB_CAIRO_REF [...] HB_CAIRO_REF #endif and use one list for DYNAMIC and EXTERN declaration. For sure it can be usable but such list have to be synced with library code so it's some additional job. It will be also more flexible to keep them in separated files without any other definitions for 2 main reasons: 1. it's much easier to write helper tool creating automatically file with such list from scratch then tool updating existing file which contains also other definitions and PP directives. In the future we may try to create such tool for few compilers, i.e. I wrote sth like that for my own use as few lines shell script which creates such list for GCC libraries using 'nm'. 2. in some cases different libraries can use incompatible preporcessor directives so their header files cannot be mixed but programmer may need to include extern function declaration for both libraries to create final binaries which will have references to all functions. Keeping function lists in separated files without any other PP directives which may cause collisions resolves the problem. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13198] trunk/harbour
On Thu, 10 Dec 2009, vszak...@users.sourceforge.net wrote:
Hi,
> 2009-12-10 15:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
> * hbwin/win_misc.c
> * hbwin/win_prn1.c
> + Using new UNICODE parameter passing macros instead of HB_TCHAR*() ones.
> (where possible)
Thank you for your modifications but I would like to ask you about
two things:
1. please do not leave any unnecessary casting like:
( LPCTSTR ) HB_PARSTRDEF( ... )
such casting does not give anything (it cannot converts strings
between different formats) but can hide very serious bugs like wrong
HB_PARSTRDEF() body.
2. please use HB_PARSTRDEF() only in places where is strictly necessary.
some of this code comes from xHarbour where few years ago all hb_parc()
where replaced with hb_parcx() by global S&R. From that time I always
used to check and replace unnecessary hb_parcx() with hb_parc().
If you will make mechanical translations all hb_parcx() to HB_PARSTRDEF()
then I will have to also verify HB_PARSTRDEF() calls. So please try
to already clean it at least for such basic things like:
if( HB_ISCHAR( 1 ) )
{
void * hName;
xec->hDLL = LoadLibrary( HB_PARSTRDEF( 1, &hName, NULL ) );
hb_strfree( hName );
}
BTW We can add to strapi.c two very simple functions:
const char * hb_strnull( const char * str )
{
return str ? str : "";
}
const HB_WCHAR * hb_strnull_u16( const HB_WCHAR * str )
{
return str ? str : s_szConstStr;
}
which can be used in HB_PARSTRDEF() macro.
best regards,
Przemek
ps. Now I'm making some minor modifications in win_dll.c so please
do not change it.
___
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:[13198] trunk/harbour
On Fri, 11 Dec 2009, Szak�ts Viktor wrote:
Hi,
> > 1. please do not leave any unnecessary casting like:
> > ( LPCTSTR ) HB_PARSTRDEF( ... )
> > such casting does not give anything (it cannot converts strings
> > between different formats) but can hide very serious bugs like wrong
> > HB_PARSTRDEF() body.
> I know about this, but if I don't cast, MSVC (C++ mode) gives me errors
> on compile. (const WCHAR * cannot be converted to LPCWSTR or something
> like it)
It was enough to tell me about it :)
Last night I committed modification which should resolve it:
2009-12-11 04:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapicdp.h
* define HB_WCHAR as wchar_t on Windows platforms for compilers which
refuse to make conversions between types using the same base type.
> I didn't reevaluate all of them, although I did serious cleanup
> of parcx usage in the past. I was also thinking to fully drop it
> for winapi calls, as I'm sure Windows won't BSOD or crash by
> passing NULL wherever a pointer is required. That's why I didn't
> add yet any special logic to HB_PARSTRDEF() yet. All I wanted
> to do is to keep this information for now.
Windows API is set of functions implemented on different levels
and some of them can crash so it's necessary to check each of
them. We cannot make any global assumption about validation of
NULL pointers. It's even possible that the behavior is different
in Win9x and WinXP, etc.
> > If you will make mechanical translations all hb_parcx() to HB_PARSTRDEF()
> > then I will have to also verify HB_PARSTRDEF() calls. So please try
> > to already clean it at least for such basic things like:
> > if( HB_ISCHAR( 1 ) )
> > {
> > void * hName;
> > xec->hDLL = LoadLibrary( HB_PARSTRDEF( 1, &hName, NULL ) );
> > hb_strfree( hName );
> > }
> This was just out of scope of these modification. To be honest
> I can't easily see how above could be cleaned. In this case the
> winapi docs doesn't mark the parameter as optional, which to me
> means that NULL is not an accepted input. (okay it won't crash
> if passed, so HB_PARSTRDEF() is almost surely unnecessary)
In this case I wanted to show that this code checks HB_ISCHAR( 1 )
so the parameter cannot be NULL and it's not necessary to use
HB_PARSTRDEF() but we can simply use HB_PARSTR()
> > BTW We can add to strapi.c two very simple functions:
> > const char * hb_strnull( const char * str )
> > {
> > return str ? str : "";
> > }
> > const HB_WCHAR * hb_strnull_u16( const HB_WCHAR * str )
> > {
> > return str ? str : s_szConstStr;
> > }
> > which can be used in HB_PARSTRDEF() macro.
> Yes, this would be the perfect solution. Anyhow I didn't
> bother to add default value to HB_PARSTRDEF() yet, as
> in 99% of cases the default is empty string, only one
> was passed some other value, but it's not a requirement
> for WAPI_*() functions to give such extra features so
> it wasn't crucial.
I think that it's necessary in code like:
hb_retnint( ( HB_PTRDIFF ) LoadLibrary( HB_PARSTRDEF( 1, &hName, NULL ) ) );
or at least this code should be fixed.
> If we're at this topic, I've found a few places which
> couldn't be covered by these macros, It'd be very nice
> if you could take a look at them and suggest the
> cleanest way to resolve them. F.e. there are cases
> when retrieved parameter is assigned to win structure,
I do not see the problem, Can you show me the exact code place
where it was problematic?
> there are cases when win return value is returned
> in array elements (win_prn),
We can add hb_array[SG]etStr*() functions.
You can also use hb_arrayGetItemPtr() and hb_itemPutStrLen*()
but I do not like when users use hb_arrayGetItemPtr() function
so in such case try to at least hide it by macros, i.e.:
#if defined( UNICODE )
#define HB_ARRAYSETSTR( arr, n, str ) \
hb_itemPutStrLenU16( hb_arrayGetItemPtr( arr, n ), \
HB_CDP_ENDIAN_NATIVE, str, lstrlenW( str ) )
#define HB_ARRAYSETSTRLEN( arr, n, str, len ) \
hb_itemPutStrLenU16( hb_arrayGetItemPtr( arr, n ), \
HB_CDP_ENDIAN_NATIVE, str, len )
#else
#define HB_ARRAYSETSTR( arr, n, str ) \
hb_itemPutStrLen( hb_arrayGetItemPtr( arr, n ), \
hb_setGetOSCP(), str, strlen( str ) )
#define HB_ARRAYSETSTRLEN( arr, n, str, len ) \
hb_itemPutStrLen( hb_arrayGetItemPtr( arr, n ), \
hb_setGetOSCP(), str, len )
#endif
Please only note that unlike hb_arraySetC[L]() these macros do not
check array size and cannot be safely used with wrong indexes and
HB_ARRAYSETSTRLEN() uses str twice so you should avoid using complex
expressions passing it. It's a problem until we won't have added
hb_arraySetStr*() functions. When we do that then we simply modify
above macros to use new functions.
> there is o
Re: [Harbour] SF.net SVN: harbour-project:[13210] trunk/harbour
On Fri, 11 Dec 2009, vszak...@users.sourceforge.net wrote: Hi, > ; TOFIX: CreateProcessW() second parameter has to be a read/write > buffer. Przemek, do you have an idea how to solve that > the cleanest way? > (for now I kept a cast, assuming that a buffer is > created by Harbour conversion API, but that's not > something it guarantees in the future.) As general solution I'll add: HB_WCHAR * hb_wstrdup( const HB_WCHAR * ); and make hb_wstrlen() public. But for more tuned usage I'll also add: HB_WCHAR * hb_wstrUnShare( void ** hStr, const HB_WCHAR * pStr, ULONG ulLen ); and: char * hb_strUnShare( void ** hStr, const char * pStr, ULONG ulLen ); which can be used to convert (only if necessary) the buffer to writable state so you can use it in WIN_RUNDETACHED() in this way: ULONG ulLen; LPCTSTR lpCommandRO = HB_PARSTR( 2, &hCommandLine, &ulLen ); LPTSTR lpCommand = HB_STRUNSHARE( &hCommandLine, lpCommandRO, ulLen ); It's the cleanest version but if you trust MS that in non unicode version CreateProcessA() never change the buffer then you can make: ULONG ulLen; LPCTSTR lpCommandRO = HB_PARSTR( 2, &hCommandLine, &ulLen ); #if defined( UNICODE ) LPWSTR lpCommand = hb_wstrUnShare( &hCommandLine, lpCommandRO, ulLen ); #else LPSTR lpCommand = ( LPSTR ) lpCommandRO; #endif best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] MSVC C mode warnings in init code
On Fri, 11 Dec 2009, Szak�ts Viktor wrote:
Hi,
> In MSVC C mode (default in hbmk2), I'm getting these warnings:
> ---
> cl.exe -I. -I../../../../../include -nologo -Gs -TC -W4 -wd4127 -Ot2b1
> -EHs-c- -DHB_HAS_PCRE -IF:/work/harbour/harbour/external/pcre -DPCRE_STATIC
> -DHB_HAS_Z
> LIB -IF:/work/harbour/harbour/external/zlib -DUNICODE -Foadir_dyn.obj
> -DHB_DYNLIB -c adir.c
> adir.c
> adir.c(42) : warning C4079: unexpected token 'identifier'
> adir.c(42) : warning C4081: expected 'newline'; found ')'
> ---
It's hard for me to help without MSVC access.
Is it sth new or has it been existing for quite long time?
This warning is generated for this code code:
HB_FUNC( ADIR )
{
[...]
translated by PP to:
_declspec( dllexport ) void HB_FUN_ADIR ( void )
{
[...]
Maybe MSVC does not like _declspec and __declspec should be used instead?
Try to change in hbdefs.h[1534]:
#elif defined( __WATCOMC__ )
#define HB_EXPORT __declspec( dllexport )
to:
#elif defined( __WATCOMC__ ) || defined( _MSC_VER )
#define HB_EXPORT __declspec( dllexport )
and check if it helps.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HB_PARSTRLEN()
On Fri, 11 Dec 2009, Szak�ts Viktor wrote: Hi, > Is it possible to have above macro or function? > hb_parclen() usage needs to be cleaned and prepared > for case when Harbour level string is already in utf8 > (or utf16) CP. > What do you think? We can add it but looking at current code I do not find any place where it's really necessary. Seems that using HB_PARSTR() with 3-rd argument in all cases is more efficient so maybe we should not add it (at least now) to at least indirectly force code cleanup. 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:[13222] trunk/harbour
On Sat, 12 Dec 2009, Szak�ts Viktor wrote: Hi, > I noticed one part where we miss UNICODE support altogether in > core; when copying to clipboard from GTWVT, GTWIN, it > never makes use of CF_UNICODETEXT. Yes it is but in hb_gt_winapi_setClipboard() CF_UNICODETEXT only enable translation to UNICODE before pasting to clipboard so in fact it does not give any new functionality. It's necessary to change this function to accept unicode strings as parameter. > Plus hb_gt_winapi_setClipboard() > will need the new UNICODE API treatment. See above, both functions should be modified. In hb_gt_winapi_setClipboard() uFormat parameter should inform about type of passed text buffer (declared as 'const void *') not the type to which we should make conversion from 'char *' before pasting data to clipboard so this function should not make any conversions. Similar modification should be done also in hb_gt_winapi_getClipboard() so uFormat will inform about expected type of string we want to retrieve and also hb_gt_winapi_getClipboard() will not make any conversions. Alternatively we can modify above functions to use only one PHB_ITEM pItem parameter so they will make all necessary translations internally. This seems to be the easiest way and in such case in UNICODE builds we can always use CF_UNICODETEXT to avoid possible problems with internal windows translations using different CPs. In non UNICODE builds we can check runtime Windows version and if it's support UNICODE by default then we can use CF_UNICODETEXT otherwise CF_TEXT with hb_setGetOSCP() encoding. I guess that windows users used to set hb_setGetOSCP() to "ANSI" encoding. Am I right? > Probably there will > some more locations which use UNICODE conversion without the > HB_TCHAR macros. Or even with HB_TCHAR_*() macros but in places which needs serious modifications to accept unicode strings without any data lost conversions. I.e. file names in FS API. Now we are using HB_TCHAR_*() functions but replacing them with new API does not help in adding real unicode support and FOPEN() or FCREATE() will still accept correctly only strings using characters from single CP only. Such things needs much deeper modifications which we will have to make adding full UNICODE support to HVM. These are not local modifications which we can safely make now. BTW I still hope we can release final 2.0 before Christmas so I would like to ask everybody to test current code in different environments. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] gcc2
On Mon, 14 Dec 2009, Tamas TEVESZ wrote: Hi, > would someone with gcc2 handy get me the output of > gcc -dM -E -xc /dev/null > please? (whatever /dev/null is on your platform; running it on an > empty file is good, too.) On some platform /dev/null in read works like /dev/zero so above command may crash. > please indicate what platform you are on. See __VERSION__ below. > i am not at the moment interested in any other gcc version, only v2. #define __USER_LABEL_PREFIX__ #define __SIZE_TYPE__ unsigned int #define __PTRDIFF_TYPE__ int #define __HAVE_BUILTIN_SETJMP__ 1 #define __i386 1 #define __GNUC_PATCHLEVEL__ 0 #define __ELF__ 1 #define __WCHAR_TYPE__ long int #define __NO_INLINE__ 1 #define __GNUC_MINOR__ 96 #define __WINT_TYPE__ unsigned int #define __tune_i386__ 1 #define __unix 1 #define unix 1 #define __REGISTER_PREFIX__ #define __linux 1 #define __GNUC__ 2 #define i386 1 #define __linux__ 1 #define __VERSION__ "2.96 2731 (Red Hat Linux 7.3 2.96-110)" #define __i386__ 1 #define linux 1 #define __unix__ 1 best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
On Mon, 14 Dec 2009, Bisz István wrote:
Hi,
> Hi Przemek,
[...]
> My question is, do we need to force the USE_DL_PREFIX macro for the mingw
> default builds as for MSC?
It's possible. Replacing default malloc()/free() functions have to be
global. Some compilers may keep some hardcoded references to default
memory manager and in such case they will crash when memory pointers
from two different memory manager are mixed.
In this case with HBQT you are introducing C++ RTL which may use it's
own references to build in memory manager. It's possible that adding
this code to one of HBQT CPP files will resolve the problem:
void * operator new( size_t nSize ) { return hb_xgrab( nSize ); }
void operator delete( void * p ) { hb_xfree( p ); }
You can test it but it may also create new one if some code does not
cleanly removes all allocated objects before HVM exit which may also
deinitialize some other memory managers.
Enabling USE_DL_PREFIX resolves any possible conflicts with C/C++ RTL
though it's less efficient. But if current state creates real problems
then we should change it and enable full memory manager replacement
only on explicit user request by some macro, i.e. HB_FM_DL_PREFIX_OFF.
> Or maybe there are some other approaches like HB_FM_STD_ALLOC macro
> definition.
It's rather inefficients memory manager so for many users it will be
hard to accept 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] porting help needed again
On Tue, 15 Dec 2009, Tamas TEVESZ wrote: Hi, > g++ -DHB_OS_UNIXWARE -I. -I../../../../../include -D_SCO_DS -Wall -W -O3 > -o expropt1.o -c ../../../expropt1.c > In file included from ../../../../../include/hbvmpub.h:56, > from ../../../../../include/hbapi.h:61, > from ../../../../../include/hbcompdf.h:57, > from ../../../../../include/hbmacro.h:62, > from ../../../expropt1.c:58: > ../../../../../include/hbdefs.h:1624: multiple storage classes in declaration > of `PHB_FUNC' > ../../../../../include/hbdefs.h:1625: multiple storage classes in declaration > of `HB_FUNC_PTR' > ../../../expropt1.c: In function `struct HB_EXPR_ * > hb_compExprNewNegate(HB_EXPR_ *, _HB_COMMON *)': > happens only with g++ (2.95), not with gcc or the native c/c++ > compiler. It's the same problem as in borland builds. I tested that it also in my RH7.3. I'll add workaround for gcc2 in a while. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
On Tue, 15 Dec 2009, Bisz István wrote:
Hi,
> >We already have part of this enabled in fm.c, but only
> >when building core in C++ mode, and if FMSTAT is enabled.
> I tried to activate this part with:
> @set HB_BUILD_MODE=cpp
> @set HB_USER_CFLAGS=-DHB_FM_STATISTICS
> in hbqt.hbc:
> from:
> {allgcc}libs=supc++
> to:
> {allgcc}libs=hbvm supc++ (maybe there are more sophisticated
> approaches to eliminate the double defined new/delete build errors )
> But hbide and demoqt crashes on exit, see below...
Are you using single thread HVM intentionally?
> >Maybe we should create a small contrib lib with just
> >that, so that it could be used by any C++ contribs we
> >may happen to have in the future (plus hbqt of course).
> OK, it is useful I think, but will generate other problems as we can see.
As long as USE_DL_PREFIX is not defined then DLMALLOC is not disabled
on HVM exit so we should not have any problems on exit in valid code.
> I just proposed a similar handling of the fm.c mingw build with the MSC
> build.
> More exactly to insert in the subsequent logic the #define USE_DL_PREFIX for
> MinGW. I haven't enough knowledge of the HVM internals to do it, sorry.
> ...
> # elif defined( _MSC_VER )
> # if !defined( USE_DL_PREFIX ) && !defined( HB_FM_DLMT_ALLOC )
> #define USE_DL_PREFIX
> # endif
> # if defined( HB_OS_WIN_CE )
> #define LACKS_FCNTL_H
> # endif
> ...
> This part generates the different MSC and MinGW default builds behavior, as
> I understood correctly.
This part has effect only for single thread HVM. In MT DLMALLOC builds
HB_FM_DLMT_ALLOC is enabled by default so ONLY_MSPACES is defined as 1
what disable all code using USE_DL_PREFIX.
I can define USE_DL_PREFIX as default in ST builds but I'm afraid that
it will only hide some problems in HBQT code instead of resolving them.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: RE: [Harbour] HBQT - demoqt default MinGW build (HB_FM_DL_ALLOC without USE_DL_PREFIX) crashes
On Tue, 15 Dec 2009, Bisz István wrote: Hi, > >I can define USE_DL_PREFIX as default in ST builds but I'm afraid that > >it will only hide some problems in HBQT code instead of resolving them. > The default ST with VS2008 woks, just the default ST with MinGW fails on > the first delete operator. In previous messages you said that it crashes on application exit. Now on 1-st delete operator. So where it crashes really? Anyhow we still do not know why it crashes. Tests which checks that it works in one configuration but does not work in other only help to reduce the problem but are not enough to give an answer what and where is exactly broken. Errors like GPF caused by accessing released memory can be very easy hidden by any modifications which change even a little bit memory allocation strategy and/or addresses of allocated memory blocks so pointers read from freed memory area can be still valid. Program will stop GPF but it does not mean that anything was fixed. It's still broken as it was and sooner or later the problem will be exploited again. 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:[13253] trunk/harbour
On Tue, 15 Dec 2009, Tamas TEVESZ wrote:
Hi,
> now something is broken again. i'm not sure what, as at one point i
> had a working harbour ("working" at this stage i define as "hbrun
> starts"), now for all of gcc/c, native/c, native/c++, when trying to
> run hbrun, i get:
> Error BASE/1003 Variable does not exist: S_AINCDIR
> Called from _APPMAIN(90)
sth like that happens when hbrun is compiled without -n option, i.e.
hbmk hbrun
try:
hbmk -n2 hbrun
I'll add -n2 to default switches in hbmk.
> for all posterity i have the following changed wrt r13253 hbinit.h:
> --- hbinit.h(revision 13253)
> +++ hbinit.h(working copy)
> @@ -112,7 +112,8 @@
> #define HB_CALL_ON_STARTUP_END( func ) \
>}
>
> -#elif defined( HB_INITSEG_STARTUP )
> +#elif ( defined( __USLC__ ) && !defined( __cplusplus ) ) || \
> + defined( HB_INITSEG_STARTUP )
>
> #define HB_INIT_SYMBOLS_BEGIN( func ) \
>static HB_SYMB symbols_table[] = {
> hbtest, for example, runs fine, so this probably has nothing to do
> with this awesome work of yours in the startup area, but then i am at
> a loss what's gone booboo again.
For me it looks like hbrun was compiled separately with different
switches (missing -n harbour compiler switch) but there is question
how it has happened.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] g++2.95/g++3.3 bad build
On Wed, 16 Dec 2009, Tamas TEVESZ wrote: Hi, > it seems that something is wrong with g++2.95 builds afterall. > i took a fresh checkout of 13263, and tried building it on an older > linux/i386 box that has gcc 2.95. > (i changed HB_CMP to gcc-2.05 and g++-2.95 in config/linux/gcc.mk > because this has no gcc and g++ links, but that's all that is.) > both build fine, however the g++-2.95 build does exhibit the problem > of hbrun not being able to start because: > tres:~/tmp/h/harbour$ ./bin/linux/gcc/hbrun > Unrecoverable error 9998: Harbour terminal (GT) initialization failure I've just confirmed your results using RH7.3 with GCC-2.96. > c mode is fine. just run a quick test with gcc 3.3, same situation > there too (same box, same everything); gcc 4.0 is ok in both modes, > and on other boxes gcc 4.4 is ok too. > so i guess this makes it "g++ < 4 builds broken". Yes, it's and it was exploited in last year. I was cleaning the code adding support for g++ about five years ago using xHarbour repository and above RH7.3 with gcc-2.96 and for sure it was working correctly. > since now i am completely confused, would someone do a test build with > g++ 2.95 (and perhaps gcc3 too) to doublecheck me? it'd be probably > nice to know this both on linux and some other non-unixy platform too. Using C++ initialization (HB_STATIC_STARTUP) or recently added HB_INITSEG_STARTUP it works. The problem is only with __attribute__ ((constructor)) used in GCC-2.x C++ mode (I haven't tested GCC-3.x). I think that we exploited this problem in this year. It possible that it's also the reason of problems with SunPRO C builds in Linux, i.e. it GPFs in hbtest because not all constructors are executed and some symbol tables from .prg modules in HBRTL are not initialized. Anyhow it does not have to mean it's Harbour problem. It rather seems to be side effect of exploiting some limits in older GCC or GNU ld versions or maybe modified link command. I'll try to look at it closely but I do not promise that I'll give you the exact answer what is the reason of problem. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] g++2.95/g++3.3 bad build
On Wed, 16 Dec 2009, Przemysław Czerpak wrote: Hi, > Yes, it's and it was exploited in last year. I was cleaning the code > adding support for g++ about five years ago using xHarbour repository > and above RH7.3 with gcc-2.96 and for sure it was working correctly. Update. I've just checked that RH7.3 was used only in chroot env and the real OS I used was newer so I GCC C++ builds were never tested with GCC 2.9x. > Using C++ initialization (HB_STATIC_STARTUP) or recently added > HB_INITSEG_STARTUP it works. The problem is only with > __attribute__ ((constructor)) used in GCC-2.x C++ mode (I haven't > tested GCC-3.x). > I think that we exploited this problem in this year. > It possible that it's also the reason of problems with SunPRO C builds > in Linux, i.e. it GPFs in hbtest because not all constructors are executed > and some symbol tables from .prg modules in HBRTL are not initialized. > Anyhow it does not have to mean it's Harbour problem. It rather seems to > be side effect of exploiting some limits in older GCC or GNU ld versions > or maybe modified link command. I'll try to look at it closely but I do > not promise that I'll give you the exact answer what is the reason of > problem. The problem is trivial. GCC-2.96 when C++ mode is used ignores __attribute__ ((constructor)) and does not add functions with above attribute to .ctors segment. Looks like it was fixed in one of GCC-3.3x releases but I do not know the exact version. For sure it was fixed in the version I used adding g++. It will be good to check exact version to enable in hbinit.h HB_STATIC_STARTUP initialization for older GCC versions using C++ mode. Or maybe we should enable it by default for _ALL_ (also MSVC) compilers using C++ mode? Unlike all other startup initialization methods this one uses only standard C++ functionality without any compiler specific tricks so it's fully portable code in C++ world. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Where is defined function DRAW_LINE ?
On Wed, 16 Dec 2009, Horodyski Marek (PZUZ) wrote: Hi, > In file \harbour\contrib\hbhpdf\tests\harupdf.prg > Is used function draw_line : > ║ 225│ HPDF_Page_SetLineWidth(page, 2.0) > ║ 226│ draw_line(page, 60, 710, "line width = 2.0") > But, when I try used this function in another app ( with all libs from > \harbour\contrib\hbhpdf\tests\hbmk.hbm and \harbour\contrib\hbhpdf\hbhpdf.hbc) > I have this fault : > homar.o:homar.c:(.data+0x1678): undefined reference to `HB_FUN_DRAW_LINE' > > I can not find the substring "DRAW_LINE" in any library. Maybe you should look more carefully at \harbour\contrib\hbhpdf\tests\harupdf.prg: Static Function draw_line2( page, x, y, label ) [...] ;-) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Wed, 16 Dec 2009, Szak�ts Viktor wrote: Hi, > No educated bug report, but just now I tried to > coppy/paste some text from OS X Mail to my app > running GTXWC, and the app just hung with 100% > CPU consumption. Please always try to replicate the problem in reduced example. In a while I'll commit small modification to tests/gtkeys.prg which allow to retrive text from Clippard buffer by CTRL+INS and set new text using CTRL+END. Just use it for tests. In my Linux box all works as expected without any problems. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HB_TRACE() - How to invoke for PRG and C code separately
On Wed, 16 Dec 2009, Pritpal Bedi wrote:
Hi,
> > First build Harbour without HBQT.
> > Then build HBQT in a separate pass with custom options.
> > Rough instructions for that:
> > ---
> > set HB_WITH_QT=
> > win-make
> > cd contrib/hbqt
> > set HB_WITH_QT=C:\qt\include
> > set HB_USER_CFLAGS=-DTR_DEBUG_...
> > set HB_USER_PRGFLAGS=-D__HB_DEBUG__
> > win-make
> > cd ../..
> > ---
> Can you expand <...> in
> set HB_USER_CFLAGS=-DTR_DEBUG_...
> I tried
> set HB_USER_CFLAGS=-DTR_DEBUG
> set HB_USER_CFLAGS=-DHB_TR_LEVEL_ALWAYS
> but without success.
> I am compiling hbqt/hbxbp/hbide only with these flags.
> Harbour is compiled with default switches.
> To be precise as:
> HB_USER_CFLAGS=-D__HB_DEBUG__ -DHB_FM_STATISTICS -DHB_TR_LEVEL_ALWAYS
> HB_USER_PRGFLAGS=-d__HB_WINDEBUG__ -d__HB_DEBUG__
With above you excluded at compile time all HB_TRACE messages
with do not have HB_TR_ALWAYS priority.
To clarify you do not need to recompile anything. It's enough if
you understand how current code works.
-DHB_TR_LEVEL_* is compile time macro used to strip from source code
by PP all HB_TRACE() massages which have bigger priority value.
By default it's set to: HB_TR_LEVEL_WARNING what means that:
HB_TRACE(HB_TR_ALWAYS, ... ); /* 0 */
HB_TRACE(HB_TR_FATAL, ... ); /* 1 */
HB_TRACE(HB_TR_ERROR, ... ); /* 2 */
HB_TRACE(HB_TR_WARNING, ... ); /* 3 */
are compiled and included in final binaries and:
HB_TRACE(HB_TR_INFO,... ); /* 4 */
HB_TRACE(HB_TR_DEBUG, ... ); /* 5 */
are stripped by C preprocessor before compilation so no code is
generated for them.
When you use -DHB_TR_LEVEL_ALWAYS then it means that you exclude
at compile time all HB_TRACE() messages except HB_TR_ALWAYS ones.
At .prg level you can use hb_traceString() function to generate
HB_TR_ALWAYS messages.
below I'm attaching small test code which shows different HB_TRACE
messages generated from C and .prg code.
HB_TRACE() messages which were compiled are filtered also at runtime.
By default the filter is set to HB_TR_WARNING what means that HB_TR_ALWAYS,
HB_TR_FATAL, HB_TR_ERROR and HB_TR_WARNING are shown but HB_TR_INFO and
HB_TR_DEBUG are ignored.
This filter can be changed by HB_TR_LEVEL= envvar set before
application starts, i.e. to show all compiled messages:
set HB_TR_LEVEL=DEBUG
or to show only HB_TR_FATAL and HB_TR_ALWAYS:
set HB_TR_LEVEL=FATAL
By default HB_TRACE() messages are redirected to STDERR and if
you want then you can redirect them to file using 2> shell operator
(of course if it supports it), i.e.:
myprog.exe 2> mytrace.log
Alternatively they can be also redirected to file by setting HB_TR_OUTPUT
envvar, i.e.:
set HB_TR_OUTPUT=mylog.txt
Additionally in Windows builds you can redirect copy of all HB_TRACE()
messages to OutputDebugString() function. It's enough to set HB_TR_WINOUT
envvar to some not empty value, i.e.:
set HB_TR_WINOUT=1
The messages are written to STDERR or user file using stdio functions
which can buffer data. It speedups the execution time but in some cases
you may want to force writing each message immediately, i.e. to trap
messages which can be lost due to GPF before buffer flushing. You can
enable such flushing by setting HB_TR_FLUSH envvar to any non empty
value, i.e.:
set HB_TR_FLUSH=1
This switch has no effect on HB_TR_WINOUT for which Harbour do not
make any buffering.
I hope that now it's more clear for you and other Harbour developers
how HB_TRACE system works. For sure it's much more flexible then direct
calling some *_trace*() function. I hope you will find it very useful.
I.e. in your .c code you can use HB_TR_INFO messages which are stripped
by default at compile time, i.e.:
HB_TRACE(HB_TR_INFO, ("[...@%s]", "this is tracelog test", "INFO"));
and do not cause any runtime overhead in default builds.
But if you will want to enable them, then it's enough to recompile
your code with HB_USER_CFLAGS=-DHB_TR_LEVEL_INFO and then before you
start final application:
set HB_TR_LEVEL=INFO
set HB_TR_OUTPUT=mylog.txt
Unfortunately we do not have such flexible interface at .prg level
and here you can use only hb_traceString() function to generate
HB_TR_ALWAYS messages.
In general .prg level support for HB_TRACE() messages should be extended
and in few places fixed. Now we have three functions:
hb_traceState( [] ) ->
hb_traceLevel( [] ) ->
hb_traceString( ) -> NIL
hb_traceState() enable and disable HB_TRACE system. By default it's
enabled.
Now hb_traceLevel() does not make anything usable. I can only guess it's
mistake of someone who wanted to give .prg level interface for setting
default runtime HB_TRACE message filter so it could be used instead of
setting HB_TR_LEVEL envvar. It should be fixed to work in such way
or removed to nor confuse users.
hb_traceString() convert passed parameters to string using the same
conversion method as ?/?? commands ([Q]QOUT()) so at least its name
is confusing. It shows all messages using only HB_TR_ALWAYS level,
doe
Re: [Harbour] Problems in WIN_MAPISENDMAIL()
On Wed, 16 Dec 2009, Enrico Maria Giordano wrote: Hi, > > Enrico, can you post your example which GPFs? > It doesn't GPF anymore after Toninho hints. I think that Viktor asked about it because he wants to add protection against wrong parameters which may cause such GPF so such information is still valuable for us. Maybe in few places we should use HB_ARRAYGETSTRDEF() instead of HB_ARRAYGETSTR() or maybe we should add support for one dimensional arrays in attachment list or maybe we should skip some wrong items in such arrays. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_xgrab( ULONG )
On Wed, 16 Dec 2009, Szak�ts Viktor wrote: Hi, > hb_x*() functions are supposed to be replicas of > std malloc functions, but hb_xgrab()/hb_x[re]alloc() > expect an ULONG parameter, instead of size_t, like > malloc do. > Shouldn't this be (eventually) fixed? It should be but for sure not now. In all supported by us platforms it makes binary difference only on Win64 but it opens series of other modifications so it's not local only change which we can make just before new release. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Wed, 16 Dec 2009, Szak�ts Viktor wrote: Hi, > I've just checked and same OS X GTXWC app picked what was > placed to clipboard before starting the app (or even > starting X11 for that matter). > I'll keep an open eye to report any clipboard problems > here. Please try it after: 2009-12-17 03:45 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] very strange compile error
On Thu, 17 Dec 2009, Tamas TEVESZ wrote: Hi, > while doing a new port, came across this: > g++ -DHB_OS_UNIXWARE -I. -I../../../../../include -D_SCO_DS -Wall -W > -O3 -o expropt1.o -c ../../../expropt1.c > ../../../expropt1.c: In function `struct HB_EXPR_ * > hb_compExprNewNegate(HB_EXPR_ *, _HB_COMMON *)': > ../../../expropt1.c:1066: integer constant out of range > this only happens with g++. 2.95 is the only one there is, and it is > entirely possible it is a compiler error, as it has other deficiencies > it theoretically shouldn't. Two possible reasons: 1. bug in g++ lexer If the results are correct and not stripped to 32 bits then it minor bug - this part is missing in your tests 2. when g++ is used then in header files LLONG_MAX constant is defined without LL suffix, i.e.: #define LLONG_MAX 9223372036854775807 instead of: #define LLONG_MAX 9223372036854775807LL In both cases it's not Harbour problem and if the results are correct then you can ignore it. 2.95 is quite old version so I do not think it should be reported to GCC authors but if it's the only port of GNUC for SCO then you may want to do inform about it someone who manage it so it can be cleaned. printf( "LLONG_MAX=%lld, [%lld], , [%lld]\n", LLONG_MAX, 1234567890123456LL + 9000LL, 8877665544332211LL ); should give you basic answer if such values are managed correctly by compiler. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13234] trunk/harbour
On Sun, 13 Dec 2009, vszak...@users.sourceforge.net wrote: Hi, > 2009-12-13 14:46 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * utils/hbmk2/hbmk2.prg > + Added support for linux/open64. (Please test) Thank you very much. It works. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HB_TRACE() - How to invoke for PRG and C code separately
On Wed, 16 Dec 2009, Pritpal Bedi wrote: Hi, > Now I can trace PRG level calls in HBIDE with -D__HB_DEBUG__ define > which in turn invokes hb_TraceString( [x] ) which in turn executes > hb_tr_trace( HB_TR_ALWAYS,.. ). > But still I cannot capture HBQT HB_TRACE( HB_TR_DEBUG, ... ) calls. > HBQT compiles and shows up this in log: > gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer > -march=i586 -mtune=pentiumpro -Ic:\Qt\2009.03\qt\include > -Ic:\Qt\2009.03\qt\include/QtCore -Ic:\Qt\2009.03\qt\include/QtGui > -Ic:\Qt\2009.03\qt\include/QtNetwork -D__HB_WINDEBUG__ -D__HB_DEBUG__ > -DHB_FM_STATISTICS -DHB_TR_LEVEL_DEBUG -ohbqt_destruct.o -c > ../../../hbqt_destruct.cpp I have no idea what __HB_WINDEBUG__ does. As I can see it's not used at all. __HB_DEBUG__ is you own macro used in hbqt.ch to disable HBQT_DEBUG() debug messages in .prg code so it does not have to be passed to compile C code. Remove both from your HB_USER_CFLAG settings. > which amply shows that HB_TR_LEVEL_DEBUG is passed to the compiler. And this is correct so all HB_TR_DEBUG level HB_TRACE() messages are not stripped at compile time by C preprocessor and later can be enabled at runtime. > Other envar set are : HB_TR_WINOUT=1 > What I am missing ? > Note that I am looking at output rendered by OutputDebugString() call in > hbtrace.c. > Moreover, in PRG level trace shows up info as: > trace.c:96: HB_TR_ALWAYS 0 Destroy: XBPTOOLBAR 1375326 > 20376 > and there trace.c:96 is the wrong info. You forgot to switch the runtime HB_TRACE message filter level so it's still set to HB_TR_WARNING and ignores all massages having HB_TR_INFO or HB_TR_DEBUG level. set HB_TR_LEVEL=DEBUG change this filter from WARNING to DEBUG level. Just make few tests with code example I sent using different compiletime and runtime filters. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Thu, 17 Dec 2009, Tamas TEVESZ wrote: Hi, > the symptom is that when there is already data in the primary when > this app is started, the first inkey(0) is immediately satisfied (and > then it shows the correct content for the primary selection). > > this doesn't happen absolutely always, but it does most of the time. > if the primary is empty at app startup, then it never happens. I cannot replicate it but I guess what can be source of such behavior and it's not related to selection code. If you replace in your code 'InKey(0)' with '?? InKey(0)' then we can see the keycode returned in such case. I think it's 1101 (K_RESIZE) which can be generated on some slower system if ConfigureNotify is delivered during initial window creating. It's nothing wrong but of course I'll clean it. > another artifact is that upon exit (i start it from an xterm), it > leaves some garbage someplace, which which causes my xterm to > disappear if i press middle button. it's nothing that i could catch > with careful use of xxd waiting for some binary junk, what's more, at > one occasion this even killed my windowmaker (ok, it's not the > stablest wm in the world, but for a couple of month, since > outstandings have been fixed, i've been having much less problems with > it than i used to). > even worse, this doesn't seem to be tied to middle button events. i > have had it by middle button, up arrow in shell, ^C in a shell line i > decided not to execute... > so the guess it that *something* is there that causes clients to exit > unexpectedly. it is not even sure that the client that exits is the > one that has the focus (i was just at this moment playing with other > xterms when this one that runs my mua decided it's been long since i > last saw my desktop background...) Your VM crashes when selection owner does not response. I'll add code to disable own selection in GTXWC exit phase and I hope it will help anyhow real fix should be done in WM code because your description suggests that it may have very serious problems and even crash if selection owner terminates suddenly without clearing the selection i.e. due to delivered asynchronous signal (killall myapp). I'll commit these modifications in a while. Please test if they resolve all your problems. I cannot replicate any of them in my local machine. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Thu, 17 Dec 2009, Tamas TEVESZ wrote: Hi, > this one is solved,, thank you. thank you. > > > so the guess it that *something* is there that causes clients to exit > > > unexpectedly. it is not even sure that the client that exits is the > this one is not. Can you check if problem can be resolved if you add at the end of your test application: hb_gtInfo( HB_GTI_CLIPBOARDDATA, "" ) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Release notes/questions
On Thu, 17 Dec 2009, Szak�ts Viktor wrote: Hi, > - If the binary release is up to me, I'll > leave out DJGPP build, since I don't possess a > dev environment for it anymore. watcom/dos build > can be included, but I'm not sure if it's > worth it. I can create DJGPP and OpenWatcom Harbour binaries. BTW Creating Harbour shared libraries in OW Dos builds does not work due to some insufficient dependencies in DLL startup code so OW tries to link both startup code (also for standalone binaries) into harbour.dll. At least when I use OW in Linux. Does it work for you on other platforms?. If not then I suggest to temporary disable creating harbour.dll in dos/watcom.mk by simple modification like: ifeq ($(HB_BUILD_DLL),yes) DY_RULE = $(create_dynlib) endef Maybe we should also use the same method in DJGPP. If someone adds support for -shared binaries in new DJGPP versions then it will be enough to rebuild Harbour setting HB_BUILD_DLL=yes. Such solution is also more flexible for testing but if you prefer to fully comment DY_RULE then of course it's also OK for me. > - Should we include watcom/os2 and watcom/linux > in final win binary release? IMO the only > reason is for technological showcase, but > I doubt any win users would actually use these. > Leaving it out saves build time, package size > and upload/download time. Maybe we should create separate MS-Windows package with only OW binaries which will allow to create Harbour applications for all platforms? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GTXWC clipboard paste: hang
On Fri, 18 Dec 2009, Tamas TEVESZ wrote: Hi, > > Can you check if problem can be resolved if you add at the end of your > > test application: > >hb_gtInfo( HB_GTI_CLIPBOARDDATA, "" ) > no, but i managed to strace the xterm that got picked by the Client > Killer Phenomenon. :-) > it's last breath was this: > X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 2 (X_ChangeWindowAttributes) > Resource id in failed request: 0x560001e > Serial number of failed request: 1107 > Current serial number in output stream: 1108 [...] > its _only_ the xterms. i have now tried having other apps killed by > this method, but it's always the xterm that dies. > ok, i have found a pattern i seem to be able to reliably reproduce. Now it seems to be a little bit different thing the one you described in previous message or maybe I didn't understood you correctly. > i am running XTerm(235) (ubuntu intrepid x64). the test app is on a > remote box, which is ubuntu karmic x64. ssh in, start the test app (it > doesn't matter whether x is via ssh or via a direct connection). I fixed stupid bug in one of last commits which was exploited on 64bit machines so if possible please check if you can still replicate the problem with current SVN code. Anyhow seems that this modification should not effect any valid 3-rd party code. > when the test app says to copy something in, copy something in from an > xterm. then push through the test app, and after it exits, give focus > to the xterm you have copied from (this may need to be done several > times). i could kill the xterm in at most 5 tries (of giving it focus, > and taking focus away from it). > i've tried other apps, xlib-based, xaw-based, gtk-based, i've even > tried rxvt, but it is invariably the xterm that dies. > i have tried XTerm(243) (this is the latest in ubuntu), same effect. > i've built myself a smokin' fresh XTerm(253), same effect. > > so thus far every finger points at either xterm or xterm-wm > interaction being somehow at fault, and we could have been chasing > ghosts... I cannot replicate it (probably because I cannot exactly replicate your environment settings) so I have to guess but probably you are right. Anyhow thank you very much for your tests. Finally I've found a while to clean the selection code in GTXWC. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Fixed close event in windows console GTWIN.
On Fri, 18 Dec 2009, Xavi wrote: Hi, > If I sent this example is because I thought the difference was obvious. > In my development environment Windows presents the "End program dialog" (with > option to cancel) with //GTWIN and not without. > The reason is that with one is executed the event handler because windows > reused the console and with other not. > But ... !!! ??? is a big surprise to me that, with 'hbmk2 t.prg' my example > program not do the same. > Well Murphy's law and extra work for me. > When find speare time I look exactly what happens. > A little help would be welcome. This behavior depends on application type. GUI applications using WinMain() as startup entry allocates new console and CUI programs starting with main() trys to inherit existing console from calling process. Type of application depends on linker switches. In hbmk2 it can be changed by -gui|-std switches. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] hbmk2 + msvc
On Fri, 18 Dec 2009, Fernando Athayde wrote: Hi, > i didn´t was specified > ex: bcc, it shows error in the end, take a look above, is better to see if > happens any error Don't you see that in both cases it's _EXACTLY_ the same behavior and only the length of executed command is different? If some command fails then hbmk2 shows the full command line: For BCC this command is: ilink32.exe @C:\Users\athayde\AppData\Local\Temp\bt3rrj.lnk For MSVC it's: link.exe -nologo -out:fjfrigo.exe .hbmk\win\msvc\busca.obj .hbmk\win\msvc\database.obj .hbmk\win\msvc\errorsys.obj .hbmk\win\msvc\fj_printsetup.obj .hbmk\win\msvc\funcoes.obj .hbmk\win\msvc\hbrowse.obj .hbmk\win\msvc\hbvpdf.obj .hbmk\win\msvc\hbvpdft.obj .hbmk\win\msvc\hbvpsup.obj .hbmk\win\msvc\hprinter.obj .hbmk\win\msvc\login.obj .hbmk\win\msvc\menu0.obj .hbmk\win\msvc\menu11.obj .hbmk\win\msvc\menu12.obj .hbmk\win\msvc\menu13.obj .hbmk\win\msvc\menu14.obj .hbmk\win\msvc\menu15.obj .hbmk\win\msvc\menu16.obj .hbmk\win\msvc\menu171.obj .hbmk\win\msvc\menu172.obj .hbmk\win\msvc\menu173.obj .hbmk\win\msvc\menu174.obj .hbmk\win\msvc\menu175.obj .hbmk\win\msvc\menu176.obj .hbmk\win\msvc\menu177.obj .hbmk\win\msvc\menu178.obj .hbmk\win\msvc\menu179.obj .hbmk\win\msvc\menu181.obj .hbmk\win\msvc \menu182.obj .hbmk\win\msvc\menu183.obj .hbmk\win\msvc\menu184.obj .hbmk\win\msvc\menu185.obj .hbmk\win\msvc\menu187.obj .hbmk\win\msvc\menu188.obj .hbmk\win\msvc\menu189.obj .hbmk\win\msvc\menu18a.obj .hbmk\win\msvc\menu18b.obj .hbmk\win\msvc\menu191.obj .hbmk\win\msvc\menu192.obj .hbmk\win\msvc\menu193.obj .hbmk\win\ msvc\menu194.obj .hbmk\win\msvc\menu21.obj .hbmk\win\msvc\menu221.obj .hbmk\win\msvc\menu222.obj .hbmk\win\msvc\menu223.obj .hbmk\win\msvc\menu224.obj .hbmk\win\msvc\menu225.obj .hbmk\win\msvc\menu226.obj .hbmk\win\msvc\menu227.obj .hbmk\win\msvc\menu2312.obj .hbmk\win\msvc\menu2322.obj .hbmk\win\msvc\menu2332.obj .hbm k\win\msvc\menu2333.obj .hbmk\win\msvc\menu2334.obj .hbmk\win\msvc\menu234.obj .hbmk\win\msvc\menu241.obj .hbmk\win\msvc\menu242.obj .hbmk\win\msvc\menu243.obj.hbmk\win\msvc\menu244.obj .hbmk\win\msvc\menu245.obj .hbmk\win\msvc\menu246.obj .hbmk\win\msvc\menu311.obj .hbmk\win\msvc\menu312.obj .hbmk\win\msvc\menu313.ob [...] If you do not want to see the full command line for commands which failed then use -quiet hbmk2 option. 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:[13275] trunk/harbour
On Fri, 18 Dec 2009, Pritpal Bedi wrote:
Hi,
> >> Method QPixmap:new(...)
> >> LOCAL aP := hb_aParams()
> >>
> >> aeval( aP, {|x| x := hbqt_ptr( x ) } )
> >> Qt_QPixmap(...) /* How this can be achieved with above syntax */
> >>
> >> RETURN Self
[...]
proc main()
p1( "a", "b", "c", 10, 20, 30, .t. )
return
proc p1( ... )
local v
p2( "Original parameters:", ... )
for each v in { ... }
switch valtype( v )
case "N"; v += 1000; exit
case "C"; v = upper( v ) ; exit
case "L"; v := !v ; exit
endswitch
hb_pvalue( v:__enumIndex(), v )
next
p2( "Modified parameters:", ... )
return
proc p2( msg, ... )
? msg, ...
return
> Because if I implement it QT_QPIXMAP() I have to
> touch around 100 .qth headers which is not viable at this point.
> So I am introducing in generator:
>
> METHOD QSomePlainObject:new( ... )
>LOCAL p
>LOCAL aP := hb_aParams()
>LOCAL nParams := len( aP )
>
>IF nParams > 0
>FOR EACH p IN aP
> p := hbqt_ptr( p )
>NEXT
>ENDIF
>
>DO CASE
>CASE nParams == 6
> ::pPtr := Qt_QSomePlainObject( aP[ 1 ], aP[ 2 ], aP[ 3 ], aP[ 4 ], aP[
> 5 ], aP[ 6 ] )
>CASE nParams == 5
> ::pPtr := Qt_QSomePlainObject( aP[ 1 ], aP[ 2 ], aP[ 3 ], aP[ 4 ], aP[
> 5 ] )
>CASE nParams == 4
> ::pPtr := Qt_QSomePlainObject( aP[ 1 ], aP[ 2 ], aP[ 3 ], aP[ 4 ] )
>CASE nParams == 3
> ::pPtr := Qt_QSomePlainObject( aP[ 1 ], aP[ 2 ], aP[ 3 ] )
>CASE nParams == 2
> ::pPtr := Qt_QSomePlainObject( aP[ 1 ], aP[ 2 ] )
>CASE nParams == 1
> ::pPtr := Qt_QSomePlainObject( aP[ 1 ] )
>OTHERWISE
> ::pPtr := Qt_QSomePlainObject()
>ENDCASE
>
>return self
>
> I am aware of its limitation but I could not find a better way.
> Because it is a one-time code, so it carris no overhead.
> If anybody has better solution please forward.
proc main()
p1( "a", "b", "c", 10, 20, 30, .t. )
return
proc p1( ... )
local v
p2( "Original parameters:", ... )
for each v in { ... }
switch valtype( v )
case "N"; v += 1000; exit
case "C"; v = upper( v ) ; exit
case "L"; v := !v ; exit
endswitch
hb_pvalue( v:__enumIndex(), v )
next
p2( "Modified parameters:", ... )
return
proc p2( msg, ... )
? msg, ...
return
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Fixed close event in windows console GTWIN.
On Sat, 19 Dec 2009, Xavi wrote: Hi, > I have HB_SET_CANCEL = FALSE by default and MinGW compile with -mwindows > Thanks to you and Przemek for your help. > --- t2.prg > REQUEST HB_GT_WIN_DEFAULT > ANNOUNCE HB_GTSYS > PROCEDURE Main() > SetCancel(.F.) > ? "Click [X] to close windows console " > while( LastKey() != 27 ) > Inkey( 1 ) > enddo > RETURN > --- > Use with MINGW 'hbmk2 t2.prg -gui' to build it. > SetCalcel(.F.) don't is executed. Now it's clear what is the problem and you even wrote about it in gtwin.c attached to your 1-st message. SetCalcel(.F.) has no effect because SetConsoleCtrlHandler() is executed before AllocConsole(). > Is it right now? No it isn't. AllocConsole() should be moved few lines down. Thank you. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Any commits/fixes pending?
On Sat, 19 Dec 2009, Szak�ts Viktor wrote: Hi All, > I'd like to ask everyone if there are any > patches, commits or fixes pending? (besides > hbqt related modules) 1. I'm making some experiments with DXE support in DJGPP builds. DXE is sth like DLL for DJGPP. Tomorrow I should finish it. 2. I'll commit ASAP some modifications for DOS DJGPP and OpenWatcom builds which will enable or disable default DLL support for them depending on results of my current tests. If I do not find enough time to finish them then I'll simply disable DLLs in DOS builds as temporary solution. 3. I will want to commit modifications for .prg HB_TRACE() interface ASAP. If possible I'll commit it tomorrow. 4. The name of Greek CP modules should be fixed, Now we have EL* and GR* files and CP names. We should use only one prefix. 5. I think that it's time to finally switch to HB_STATIC_STARTUP in all C++ builds also for MSC and G++. BTW can someone check if it's possible to mix .prg code compiled by MSVC in C and C++ modes without any problems? Please add INIT PROCEDUREs to such module to check if all are registered and executed. The order is less important but it will be good to know if C and C++ modules use the same priority. 6. I'm also working on small Christmas gift but I do not know if I find enough spare time to finish it so it's less important. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbpgsql --enable-auto-import issue
On Sun, 20 Dec 2009, Lorenzo Fiorini wrote: Hi, > Creating my apps under Win using mingw/msys and postgresql 8.4.2 I get: > Info: resolving _PQisnonblocking by linking to __imp__PQisnonblocking > (auto-import) > c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe: > warning: auto-importing has been activated without > --enable-auto-import specified on the command line. Your postgresql dynamic library has been compiled without even single exported symbol. In such case (nothing is exported) MinGW decides that it was programmer mistake and activates "online" exporting of all public symbols in the library (auto-import option). > This should work unless it involves constant data structures referencing > symbols > from auto-imported DLLs. To be more precise unless some structures are not accessed with internal offset calculated at compile time because for such situations it's necessary to generate different ASM code. > The same build works in Linux and OSX. Neither Linux nor OSX use export/import symbol status :-( > I can't find a clean way to fix it. You have to use postgresql DLL compiled with exported symbols or import library which will "hide" the real status of symbols or simply ignore above warning. > Is it safe to add --enable-auto-import to hb-mkdyn? If you do not want to know that you are using DLLs without exported symbols then you can use it to pacify above warning. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Any commits/fixes pending?
On Sat, 19 Dec 2009, Szak�ts Viktor wrote: Hi, > I made a test for mixing C++ and C code, and it worked without > problem with current build. C INIT/EXIT was executed first. Thank you. BTW can you also check if C and C++ modules use the same initialization order? I.e. you have three files with INIT procedures (P1(), P2(), P3()) linked as: f1.obj f2.obj f3.obj When all are compiled in C or C++ mode then they should be executed in the link order: P1, P2, P3. Please check the order for f1.obj(c++) f2.obj(c) f3.obj(c++) and f1.obj(c) f2.obj(c++) f3.obj(c) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Any commits/fixes pending?
On Sat, 19 Dec 2009, Szak�ts Viktor wrote: Hi, > > I think /opt should be removed from HB_SYSLOC logic in global.mk > > /opt is not a system dir > It's fine with me and the modification is an easy one > (and should also be done in hbmk2.prg), but before I > do it, can other *nix experts give a short opinion or > confirmation? It despneds on what you are calling system installation? If you ask about special permissions necessary to access /opt then it's system installation. If you ask about using /opt/*/lib as one one default dynamic loader libraries then it's not system installation but some installers can add /opt/*/lib to dynamic loader library list. If you ask about some strict directory structure used in /opt tree which is defined by filesystem hierarchy standard then /opt is described and should confirm such standards so in this sense it's system installation. > To me /opt looks like a grey area. It's quite precisely defined by FHS (Filesystem Hierarchy Standard). Few months ago I sent this list description of directory structure which should be used by Harbour when it's installed in /opt directory. Below I'm attaching it again. best regards, Przemek '->' means soft link, 1. FHS2.3 compliant localization for add-on applications: = /opt/ /harbour/ /bin/ /lib/ [// ] [/// ] /include/ [// ] /share/ /man/ /man1/ .1 /doc/ [// ] /etc -> /etc/harbour /etc/ /harbour/ /etc/ /opt/ (if exists) /harbour -> /etc/harbour if /opt/bin exists then we should create in this directory soft links to executable files in /opt/harbour/bin if /opt/lib exists then we should create in this directory soft links to harbour shared libraries in /opt/harbour/lib if /opt/man/man1 exists then we should create in this directory soft links to harbour shared libraries in /opt/harbour/share/man/man1 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Any commits/fixes pending?
On Mon, 21 Dec 2009, Szak�ts Viktor wrote: Hi, > It stayed the same. C first, C++ second. Thank you very much. So small note for users not using in their .prg code MAIN() or _APPMAIN() functions as startup application entry. In MSVC Harbour builds when .prg modules were compiled in C and C++ modes then the 1-st function from the 1-st module compiled in C mode is used as startup function. INIT PROCEDUREs from modules compiled in C mode are executed before INIT PROCEDUREs from modules compiled in C++ - this maybe important for some 3-rd party library developers. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Tagging 2.0.0: Tomorrow
On Mon, 21 Dec 2009, Andi Jahja wrote: Hi, > A non-compilation occurs on MSVC 6: > src\pp\pplib.c(76) : error C2375: 'hb_pp_ErrorMessage' : redefinition; > different linkage > src\pp\pplib.c(64) : see declaration of 'hb_pp_ErrorMessage' > src\pp\pplib.c(96) : error C2375: 'hb_pp_Disp' : redefinition; different > linkage > src\pp\pplib.c(67) : see declaration of 'hb_pp_Disp' > src\pp\pplib.c(104) : error C2375: 'hb_pp_CompilerSwitch' : redefinition; > different linkage > src\pp\pplib.c(68) : see declaration of 'hb_pp_CompilerSwitch' > src\pp\pplib.c(115) : error C2375: 'hb_pp_Destructor' : redefinition; > different linkage > src\pp\pplib.c(63) : see declaration of 'hb_pp_Destructor' It's MSVC 6 problem. In this context it uses declarations as separate definition from which function body does not inherit attributes. I'll try to pacify it. Please check. It's possible that you will find few other similar problems yet. If yes then probably we will have to introduce new macros because some other compilers may need such declaration. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Tagging 2.0.0: Tomorrow
On Mon, 21 Dec 2009, Szak�ts Viktor wrote: Hi, > There is one pending WinCE showstopper (posted > few days ago on the list: GetEnvironmentVariable) > which needs to be fixed yet. I added workaround for it to current code. Please test. BTW can you modify hbmk2 to not ignore -shared parameter in DOS builds? 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:[13234] trunk/harbour
On Mon, 21 Dec 2009, Andrzej P. Wozniak wrote: Hi, > Thanks for the clarification, Viktor. It should be included in the > documentation, I think. No it shouldn't. It should be included _only_ if Harbour introduce some limitations. Fortunately now Harbour does not introduce any limitations or some own exceptions which can be source of potential problems for Harbour users so there is nothing to document. Maybe I'm missing sth but can you explain me what is the idea of documenting that Harbour use system or 3-rd party lib function XYZ() without introducing any hiden limitations for XYZ() parameters. Do you plan to create such documentation for _ALL_ library functions used by Harbour? If not then why MAPISendMail() is an exception for you and you want to document that Harbour does not create any limits for passed parameters. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Tagging 2.0.0: Tomorrow
On Mon, 21 Dec 2009, Andi Jahja wrote: Hi, > It's OK now. No other similarity found. Probably new macros are needed > for compilers requiring extern "C" attributes for _static_functions_. Thank you very much for your tests. > To my knowledge, no Windoze C/C++ compilers needs such an attribute. I also do not know Windows compiler which may need it but it may change in the future or the problem can be exploited on some other platforms. AFAIR in popular builds we are making only SunPRO C++ reports 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:[13340] trunk/harbour
On Mon, 21 Dec 2009, vszak...@users.sourceforge.net wrote: Hi, > 2009-12-21 16:13 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) > * utils/hbmk2/hbmk2.prg > + Enabled -shared support for dos/djgpp. Not tested. > + Enabled -hbdyn support for dos/djgpp. Blind coding, not tested. Thank you very much. In a while I'll commit to small fixes yet. 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:[13341] trunk/harbour
On Mon, 21 Dec 2009, Szak�ts Viktor wrote: Hi, > Can you check if it still works by changing this line: >cOpt_Link += " LIB clib3r" > to this?: >AAdd( l_aLIBSYS, "clib3r" ) It's working. Should I 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] Any commits/fixes pending?
On Mon, 21 Dec 2009, Szak�ts Viktor wrote: Hi, > Pls hold these changes until after the release. > GC API decisions will be made only after that. We already took such decision and committed modifications few weeks ago. The new GC API introduced user defined mark functions what allows give GC interface to non core code programmers. This modification also changed the meaning of functions like hb_gcRefInc() and hb_gcRefFree(). Before this modification they were declared as internal HVM functions because they couldn't give anything for non core code programmers. They had only one functionality in external code: they could be used to break internal reference counters and cause GC crash. Now we open the doors for non core programmers to use memory blocks with cross references which can be automatically scanned and freed by our GC but to make the new interface complete we should make above functions public and I've just committed such modification few minutes ago. I really think that this should be done before final release because it may be very important functionality for 3-rd party code programmers so now they can use it updating their code for new Harbour 2.0 API. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Please add required header
On Tue, 22 Dec 2009, Andi Jahja wrote: Hi, > Would you please add "hbapi.h" on top of "hbapifs.h" in: >- src/common/hbfopen.c >- src/rtl/spfiles.c > Reason: HB_PATHNAMES cannot be found if _HB_API_INTERNAL_ is defined. I do not understand above modification. At the beginning of hbapifs.h we have #include "hbapi.h" so this modifications will not change anything. I've just recompiled whole Harbour code with -D_HB_API_INTERNAL_ and with the exception to HBQT rest compiles now correctly. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HBPCRE
Hi, In PCRE library we have in pcreinal.h: extern BOOL _pcre_is_newline(const uschar *, int, const uschar *, int *, BOOL); extern BOOL _pcre_was_newline(const uschar *, int, const uschar *, int *, BOOL); but inside pcrenewl.c: BOOL _pcre_is_newline(USPTR ptr, int type, USPTR endptr, int *lenptr, BOOL utf8) BOOL _pcre_was_newline(USPTR ptr, int type, USPTR startptr, int *lenptr, BOOL utf8) This difference in casting confuse some C++ compilers, i.e. SunCC recognize above declarations as different functions and generates broken code for hbpcre. It should be fixed to use the same declaration 'const uschar *' or 'USPTR' in both versions and probably reported to author. I do not know which one he prefer to change but as temporary solution we can chose anyone (we do not use CUSTOM_SUBJECT_PTR so for use it does not make any difference). Viktor can you change 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] HBPCRE
On Tue, 22 Dec 2009, Szak�ts Viktor wrote: Hi, > I've filed this as: > http://bugs.exim.org/show_bug.cgi?id=939 > How about simply forcing C mode for this library in Harbour? > We're again in a situation where we deviate from standard > build procedure which just causes us problems, so it seems > more convenient to do this instead of maintaining local patches. > What do you think? As you wish though PCRE and ZLIB are a little bit specific. Unlike other external libraries they are referenced from core code so I would like to keep them working in both C and C++ mode. Sooner or later we will work on UNICODE support in HVM and it will be necessary to dig into PCRE much deeper so it's highly possible that at least for some time we will have to use our own strongly modified PCRE code which should work in C and C++ mode. Forcing C mode may strongly reduce the code quality because C compilers are not such restrictive as C++ ones. One of the most value able part of Harbour is portability. It can be easy ported to many different platforms and C/C++ compilers and I would like to keep it for core code. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Please add required header
On Tue, 22 Dec 2009, Andi Jahja wrote: Hi, > I'm very sorry orry, I must be pointing to the wrong codes. > But have you tried to clean build with: _HB_API_INTERNAL_ With this yes just after your message and it works though I've found some problems with casting in C++ mode which I fixed and even serious bug in cairo code also fixed. > HB_STACK_MACROS and HB_API_MACROS defined? These macros do not work for external code in Harbour. They are reserved only for internal code for some limited situations (usually some C compilers which do not have good optimization logic with automatic function inlining) and can be safely used only locally. HB_STACK_MACROS causes that wrong code is generated which cannot be used in MT programs. This code needs to access hb_stack global variable what causes that less efficient slower code have to be generated which calculated offsets at runtime (not during compilation) when members of hb_stack are accessed from code used in different DLL modules (hb_stack is declared with import attribute). Additionally it does not allow to declare hb_stack as static variable in ST HVM what may badly interact with some compile time optimizations - for static variables compiler may chose optimal representation because it know all references to this variable at compile time so it's easier to optimize the code. In summary they can be reactivated only with some limited functionality for ST programs with the cost of reduced speed. I do not think that anyone will want to invest time in such modification. HB_API_MACROS replaces one function call with other or when used without HB_STACK_MACROS with two different ones. In Harbour whole HVM code is compiled as single hvmall.c file by all compilers which supports function autoinlining (from popular modern compilers only BCC does not support it). It means that functions like hb_ret*() are highly optimized by C compiler and already flatten (all nested functions inlined) so in the best case HB_API_MACROS give the same speed as native function call but in the worst one when used without HB_STACK_MACROS it will reduce the speed. With few modifications they can be reactivated but for modern C/C++ compilers they will only reduce the speed and any code compiled with above macros will be hardcoded to work only with less optimal ST HVM version. Keeping the code clean and friendly for C compiler optimization logic is the best way to improve the speed. Just compare the speed of Harbour and xHarbour where nearly everything is "manually inlined" using some modern C/C++ compilers like new GCC or MSVC versions. You can use tests/speedtst.prg. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DMC C start-up (To: Przemek)
On Tue, 22 Dec 2009, Andi Jahja wrote:
Hi,
> With the new start-up codes, I tried to make it work with Digital Mars C Mode
> but so far I achieved no success.
> I know that Digital Mars is not supported due to math bug, but this exercise
> may be a fun.
> Followings are documentation for DMC pragmas which may relate to this subject.
> Perhaps you could help making DMC C Mode working then.
When C++ code is compiled DMC stores pointers to void(*)(void) functions
used to initialize static variables in "XIFM", "XIFL" or "XIFU" segments.
The segment depends on
#pragma init_seg ()
where is compiler ("XIFM"), lib ("XIFL") or user ("XIFU")
At application startup DM CRTL executes startup functions taking
addresses from "XIFM" then "XIFL" and finally form "XIFU" segments.
So all what we need is pragma to control data segment, i.e.:
#include
void init_func( void )
{
printf( "init function\n" );
}
int main( void )
{
printf( "main function\n" );
return 0;
}
#pragma data_seg( "XIFU" )
void ( * _func_ ) ( void ) = init_func;
#pragma data_seg()
but I do not see such pragma in official DMC documentations and also
seems that it's inline assembler does not allow to set data segments.
We only have:
#pragma code_seg( <"seg"> )
but it can be usable only if there is a code section executed by DM
CRTL at startup. I.e. in most of ELF formats .init section has such
functionality. If DMC has such segment then it's enough to make sth
like:
#include
void init_func( void )
{
printf( "init function\n" );
}
int main( void )
{
printf( "main function\n" );
return 0;
}
#pragma code_seg( "INIT" ) // set valid segment name here
__declspec(naked) static void _start_( void )
{
asm call init_func
}
#pragma code_seg()
In summary we need method to set data segment or name of code segment
executed at startup of course if such segment is supported by DMC.
In both cases we need sth what is not officially documented and I'm
afraid it's all what I can say about it after short checking code
generated by DMC.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] watcom/dos build error
On Tue, 22 Dec 2009, Szak�ts Viktor wrote:
Hi,
> The problem is rooted from the fact that HB_BUILD_DLL is
> explicitly enabled when HB_BUILD_PKG=yes. Maybe it'd be better
> to disable dos/watcom .dll generation completely until
> it's fixed. What do you think?
I agree. In such case let's disable DLL in DOS builds also DJGPP ones.
DXE binaries also does not work in default DJGPP 2.04 installation.
It's necessary to fix typo in dxe.h header file, change the
initialization priority and use small trick as workaround for limited
segment size in COFF format.
Too much things to document in simple HOWTO but if possible please leave
undocument way to build such DLLs just for testing in the future, i.e.
change in dos/{djgpp,watcom}.mk:
ifeq ($(HB_BUILD_DLL),yes)
to:
ifeq ($(HB_BUILD_DLL),test)
or sth like that.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in hb_gt_win_SetMode()
On Tue, 22 Dec 2009, Jacek Potempa wrote: Hi, > (sorry for my previous post under invalid subject - please ignore) The subject is not the problem. The real problem is the fact that you didn't start new thread but simply used "replay" option in your mail program so your both messages still belongs to the same initial thread. The context of subject is unimportant for mail programs which can follow threads. Just look at: http://lists.harbour-project.org/pipermail/harbour/2009-December/thread.html#29367 If you want to start new thread then please remember to not use "replay" but always create new clean message and if you want to replay then always use "replay" option in your mail program instead of creating new message. > Recently one of our customers reported bug in Terminal software. > After tracing it down it seems that the actuall problem lays in > xHarbour/Harbour implementation of the hb_gt_win_SetMode() / > gtwin.c > SetConsoleWindow API function cannot set console window larger then > current screen buffer > SetConsoleScreenBufferSize API function cannot set screen buffer > smaller than the current console window size > Due to this limitations, in current implementation SetMode() is > unable to change console size if one ot the new dimentions is larger > then the previous one and at the same time the other one is smaller > then the previous one. For instance, having console 25 X 80, > SetMode( 23, 85 ) will fail. Yes, you are right. Strange that no one reported it for such long time. Thank you very much for the information and patch. > Below my suggested fix for this problem. I have no access to CVS, so > would be nice if somebody familiar with gtwin.c review and implement > the solution. I'll commit your fix (modified a little bit) in a while. I do not have any windows here so please test it. BTW I've just added you to Harbour devel list. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
On Tue, 22 Dec 2009, Szak�ts Viktor wrote: Hi, > I'm glad to announce that after a very heavy 16 months > of development, the final, stable version 2.0.0 is finally > released. I'm very happy seeing it and I would like to thanks to all people who ever helped Harbour in any way to reach current state. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Tamas TEVESZ wrote: Hi, > on platforms where available, what is the significance of including > ieeefp.h, given that even without it, things seem to be doing OK? Probably nothing though sometimes is good to check the details in platform documentation. It's possible that in ieeefp.h some functionality is extended, i.e. some math functions from math.h can be replaced by C99 compatible macros which can operate on any floating point types. In Harbour we are using it only in SunOS builds for finite() function and as I can see this code should be cleaned because it works only for GCC builds. I'll commit the fix 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] some dependency problem in hbffind.c
On Tue, 22 Dec 2009, Tamas TEVESZ wrote: Hi, > preparing a platform that has no S_IFSOCK/S_ISSOCK, i protected the > hb alikes like this: > > include/hbapifs.h: > > #if defined( S_ISSOCK ) > # define HB_FA_SOCKET HB_FA_SPARSE /* S_ISSOCK() */ > #endif This is not necessary. HB_FA_SOCKET is Harbour internal attribute which should be always defined even if platform does not support it. > src/common/hbffind.c: > #if defined( S_ISSOCK ) >if( S_ISSOCK( raw_attr ) ) ulAttr |= HB_FA_SOCKET; > #endif Only S_ISSOCK() and S_IFSOCK usage should be protected so this is OK and should be enough. In theory it's possible that some platforms do not support also S_ISFIFO()/S_IFIFO and S_ISLNK()/S_IFLNK but before we will add such protection like above I strongly suggest to check if above macros are not covered in header files by some global feature set macros, i.e. S_ISSOCK() can be defined only when some BSD compatibility macros are enabled. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF bug tracker#2919327: watcom/dos RDD problem
On Wed, 23 Dec 2009, Chen Kedem wrote: Hi, > A user reported the following on the SF bug tracker: > http://sourceforge.net/tracker/?func=detail&atid=100681&aid=2919327&group_id=681 > I don't know which Harbour version he is using or the type of problem. > Maybe it is a missing SHARE support in that dos environment > (need to run share.exe?) [...] >> Multptform Make procedure in Vista >> HBMK2 test.prg -plat=dos -comp=watcom >> >> Program works in windows dos comand >> but not work in FreeDOS, DOSBOX. >> Only work to first dbCloseArea() and go to blank screen at next dbSetindex() >> command. >> >> Can samone confirm this. I tested it using FreeDOS in DOSEMU and it works as expected just like in my Linux box. I do not think that such problems can be caused by Harbour. Maybe it's side effect caused by some TSRs installed in this FreeDOS session or by DOSBOX, i.e. when program is executed on virtual disks or shared volumes provided by DOSBOX. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0 Key Features
On Wed, 23 Dec 2009, Massimo Belgrano wrote: Hi. > High-performance multiplatform compiler 32/64 -bit The best in Harbour is that is neither 32 nor 64 bit compiler because we do not have any hacks in core code which introduce such limitation :-) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Tamas TEVESZ wrote: Hi, > > Probably nothing though sometimes is good to check the details in > > platform documentation. It's possible that in ieeefp.h some functionality > > is extended, i.e. some math functions from math.h can be replaced by > > C99 compatible macros which can operate on any floating point types. > so, if available, using these is desirable? It really depends what it exactly does on given platform. If it's not necessary at all then it's preferred to not include it at all to not confuse users and increase dependency list. > i'm asking because looking at current src/rtl/math.c, except for a few > specific cases, isinf() is used: > 334 # if defined( HB_OS_SUNOS ) > 335 else if( !finite( dResult ) ) > 336 # elif defined( HB_OS_OS2 ) > 337 else if( !isfinite( dResult ) ) > 338 # else > 339 else if( isinf( dResult ) ) > 340 # endif > > at the same time, looking at the solaris manuals for finite(), > isinf() and finite() here (won't have access to my sol box till next > year): > > http://docs.sun.com/app/docs/doc/819-2246/isinf-3m?l=Ja&a=view > http://docs.sun.com/app/docs/doc/819-2246/isfinite-3m?l=Ja&a=view > http://docs.sun.com/app/docs/doc/801-6680-03/6i11qck75?a=view > > it seems that the currently special-cased finite() for hb_os_sunos > specifically fits your above explanation less than as if it was to let > use isinf() as well. > i may very well be misunderstanding you, though.. isinf() and isfinite() are C99 extensions so they are not available if C99 features are not enabled. There is problem with non GCC unix builds - they do not use HB_MATH_ERRNO handler (I'll fix it in next commit) and it's the reason why current src/rtl/math.c. do not need ieeefp.h. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in hb_gt_win_SetMode()
On Wed, 23 Dec 2009, Saulius Zrelskis wrote:
Hi,
> > Yes, you are right. Strange that no one reported it for such long time.
> Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
> ...
> /* Special case */
> if ( usRows < _GetScreenHeight() && usCols > _GetScreenWidth() )
> {
> HB_GT_FUNC(gt_SetMode( usRows, _GetScreenWidth() ));
> }
> else if ( usRows > _GetScreenHeight() && usCols < _GetScreenWidth() )
> {
> HB_GT_FUNC(gt_SetMode( _GetScreenHeight(), usCols ));
> }
> ...
> Later somehow this disappears.
I do not think so. The above code use old static multi GT API which
I implemented only in xHarbour and it was never part of Harbour where
I created dynamic multi GT API committed at:
2006-02-04 17:05 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
which now it used by both projects.
In Harbour the problem exists from 2002 and it was introduced when
Paul committed my initial alternative GTWIN implementation at:
2002-10-19 16:50 UTC-0500 Paul Tucker
It means that you had to take above code from xHarbour.
I've just check that above fix were committed to xHarbour CVS by Paul at:
2006-07-01 18:35 UTC-0500 Paul Tucker
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0 Key Features
On Wed, 23 Dec 2009, Massimo Belgrano wrote: > Harbour is without any hacks in core code which introduce such > limitation like 32/64? Yes. It can work with any pointer size if compiler supports some integer types larger enough to hold such pointers so it will work also with 128 if we ever have such systems or some more exotic ones like 48bits. It means that core code is not limited to work only with some chosen fixed pointer sizes like 32 or 64 bits. The only two limitations we have are 8bit byte size and ASCII based character set due to hard coded some strict Clipper compatibility. Removing both limits is possible but it needs a lot of work and not all things can be ported to such systems (i.e. some binary file formats). In current days such systems are used very seldom (i,e, some IBM mainframes) so I do not have enough motivation to made it. Also without regular access to the hardware it will be hard to keep such ports alive. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ieeefp.h - what's the significance?
On Wed, 23 Dec 2009, Tamas TEVESZ wrote: Hi, > ok, so there are two places where this is used, in src/rtl/math.c:334 > onwards and src/vm/itemapi.c:2250 onwards. Three. src/common/hbprintf.c also includes it. Here is the only one place when we try to use different C99 FL functions not only finite() and we can use as argument 'long double' values not only double ones. It means that if possible we should not force arguments conversion to double because on some hardware or (and) when some fast math optimization switches are enabled it may cause SIGFPE if argument is not valid FL number. Harbour itself does not use any NaN values so it's not a problem for valid code but in some wrong user code it may cause detecting the source of problem harder. > they are even used for the same purpose, to check whether or not to > signal a range error of sorts on a numeric argument. In itemapi.c we only try to detect finite double values. In math.c when HB_MATH_ERRNO is set we try to detect also NaN values and we should cleaned this code because now it's possible that it will not work with compilers not supporting C++ isnan()/isinf() macros. In hb_snprintf() we additionally try to detect type of infinity and sign bit. I agree that it will be nice to use common macros set in all three files defined in some separate header file, i.e. hbfloat.h which will make all platform dependent #includes and define some HB_*() macros which we can use in other code. > yet the one in itemapi.c is a macro with a screenful of tests for > platforms and compilers and whatnot, whereas the one in math.c is a > very simple conditional for os2-sunos-all-the-rest. notably, it > doesn't have a special case for os/2 -- nb i do not know if > "defined( __RSXNT__ ) || defined( __EMX__ )" covers _all_ of os2; if > it does, then scratch this last remark, but then the notation is > inconstent. > why is this difference? The code in math.c was enabled only in some GCC builds so this trivial condition was working but in fact it's wrong and should be updated to use more precise logic. In some spare time I'll check if I can easy create hbfloat.h file which can be easy used also with hbprintf.c and if yest then I'll commit 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] Harbour 2.0.0: Released
On Thu, 24 Dec 2009, WenSheng wrote:
Hi,
> hbcdpreg.h file define have bug:
I do not see any bugs in this file.
>static HB_CODEPAGE s_codePage =
>{
> HB_MACRO2STRING( HB_CP_ID ),
> HB_CP_INFO,
> HB_CP_UNITB,
> s_flags,
> s_upper,
> s_lower,
> s_sort,
> NULL,
> HB_CDP_ACSORT_NONE,
> 0,
> 0,
> NULL,
> NULL,
> NULL,
>};
> can't compiler use BCC551
It's expected behavior.
This file cannot be compiled as standalone header file.
Just like hbmsgreg.h and hbgtreg.h it can be used only
to define startup code in some modules.
What are you trying to do with this file?
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
On Thu, 24 Dec 2009, Phil Barnett wrote: Hi, > After a successful compile and install on Fedora 12 64 bit, I found that I > had to add a conf file to /etc/ld.so.conf.d > echo "/usr/local/lib64/harbour" > /etc/ld.so.conf.d/harbour.conf' > and then run ldconfig If you create RPMs (mpkg_rpm.sh) then you can install them and use Harbour without any modifications in LD directories. BTW how you compiled and installed Harbour? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Mary Christmas
Hi All, I would like to wish all of you Mary Christmas !!! best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
On Thu, 24 Dec 2009, WenSheng wrote: Hi, > I'm use SVN to update harbour source code and clean, build harbour, > when I compiler to ./source/codepage/cpbg866.c and occur error message > like: > > bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS > -Ov > -Oi -Oc -I"d:\bcc55\bin\..\Include" -ocpbg866.obj -c ../../../cpbg866.c > ../../../cpbg866.c: > Warning W8069 ../../../cpbg866.c 86: Nonportable pointer conversion > Warning W8079 ../../../cpbg866.c 87: Mixing pointers to different 'char' types > Warning W8079 ../../../cpbg866.c 88: Mixing pointers to different 'char' types > Error E2225 ../../../cpbg866.c 89: Too many initializers > Error E2141 ../../../cpbg866.c 89: Declaration syntax error > Error E2190 ../../../cpbg866.c 89: Unexpected } > Error E2190 ../../../cpbg866.c 89: Unexpected } > Warning W8065 ../../../cpbg866.c 91: Call to function 'hb_cdpRegister' with > no p > rototype in function hb_codepage_Init_BG866 > *** 4 errors in Compile *** > win-make[1]: *** [cpbg866.obj] Error 1 > win-make: *** [descend] Error 2 > > at old harbour, I can modify 'cpbg866.c' and recompiler, all right, > but, now I can't to do this. You are not using clean SVN code. cpbg866.c has only 62 lines in SVN and function hb_cdpRegister() is not longer used by Harbour. You mixed old harbour code with current one or Harbour and xHarbour files. BTW I would like to ask you to verify if you are using clean unmodified SVN code before you report problems. We have very limited resources and they are reduced when we have to verify such reports. In clean SVN tree if you use: svn stat then it should show nothing. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
On Thu, 24 Dec 2009, Phil Barnett wrote: Hi, > > > After a successful compile and install on Fedora 12 64 bit, I found that I > > > had to add a conf file to /etc/ld.so.conf.d > > > echo "/usr/local/lib64/harbour" > /etc/ld.so.conf.d/harbour.conf' > > > and then run ldconfig I'll add this to current SVN code. It should help in installations which do not use system library directories. > > If you create RPMs (mpkg_rpm.sh) then you can install them and use > > Harbour without any modifications in LD directories. > > BTW how you compiled and installed Harbour? > I checked out the repository with your supplied 2.0.0 link and did a > make install. > If I do the mpkg rpm.sh, will that create the RPM for Fedora 12/64 or > does it create a generic install? For each system it creates native RPMs. You do not need root privileges to create them. Just simply run mpkg_rpm.sh from non root account and then look for binary RPMs in ~/RPM/RPMS// directory. It's much safer way and you can check what will be installed in your system. > I have Fedora 32 and 64 installed and running here. We do not support cross build RPMs yet so you cannot create RPMs for 32bit installation using 64bit system (at least in easy way though it's possible if you make few tricks). But of course you can create without any problems 32bit binary RPMs using 32bit system and 64bit binaries on 64bit system. You can also take harbour-*.src.rpm created for one of the above systems in ~/RPM/SRPMS and on the second one only recompile it using: rpmbuild -bb harbour-*.src.rpm If you do not have have broken RPM macros inherited from connectiva by few other RPM based distributions (i.e. mandriva) then you can also use -t rpmbuild option for pure harbour-*.tgz file containing harbour SVN sources, i.e. rpmbuild -tb harbour-*.tgz best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0: Released
On Fri, 25 Dec 2009, WenSheng wrote: Hi, > OK, Thank your suggest and I delete all svn and update all then build > harbour, > but I still get error message like this: > > bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS > -Ov > -Oi -Oc -I"d:\bcc55\bin\..\Include" -ocpbg866.obj -c ../../../cpbg866.c > ../../../cpbg866.c: > Error E2380 ../../../../../include\hbcdpreg.h 84: Unterminated string or > charact > er constant in function _hb_codepage_Init_ > + Full parser context > + ../../../cpbg866.c, line 61: #include ../../../../../include\hbcdpreg.h > Error E2121 ../../../../../include\hbcdpreg.h 88: Function call missing ) in > fun > ction _hb_codepage_Init_ > + Full parser context > + ../../../cpbg866.c, line 61: #include ../../../../../include\hbcdpreg.h > *** 2 errors in Compile *** > win-make[3]: *** [cpbg866.obj] Error 1 > win-make[2]: *** [descend] Error 2 > win-make[1]: *** [codepage] Error 2 > win-make: *** [src] Error 2 > > What happens? Is not what I am missing to set? I can only guess that you enabled in your BCC some option which causes that it wrongly decodes strings with national characters. In cpbg866.c[57,58] we have such strings. Try to find why this option was enabled and disable 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:[13402] trunk/harbour
On Mon, 28 Dec 2009, vszak...@users.sourceforge.net wrote:
Hi,
> ; TOFIX:
> va_end() has been commented for all platforms, although
> it's required by all documentation I could verify.
> If this causes problems for specific platforms/compilers,
> we should only add this hack for those targets, and only
> when HB_TR_WINOUT is enabled.
This va_end() is my copy and past mistake and should be fixed by
removing it. Looks that we do not use C compiler which tries to
validate va_start()/va_end() usage by C preprocessor rules.
hb_xgrab() inside hb_snprintf() can be activated only when more
then 16 '%' patterns is used inside formatted strings so it's rather
very seldom situation. I do not think that we have such messages
anyhow it's possible that someone will want to use sth like that.
In such case it creates problems only when fm.c is compiled with
HB_TR_DEBUG what is also rather seldom situation. The problem
is that current protection against recursive calls causes that
log messages are silently ignored in MT mode. I do not think
that it's worth to introduce any non local hacks for windows
only debugging in this code so probably as the easiest hack we
can simply check if the memory statistic module is enabled and
were compiled with HB_TR_DEBUG messages using new function like:
if( hb_xtraced() )
and if yes then the number of non double '%' characters in format
string. If it's greater then 16 we can simply generate message
about it instead of original one with suggestion to divide the
trace log message to use less then 16 parameters.
Please note that we rather need new function like hb_xtraced() instead
of adding sth like hb_xquery( HB_MEM_TRACED ). Anyhow if if want
to use HB_MEM_TRACED then please remember that you have to add code
which will make:
if( iMode == HB_MEM_TRACED )
{
return ...;
}
before HB_TRACE() message inside hb_xquery().
There was never problem with parameters passed to HB_TRACE()
massages in code like:
HB_TRACE( HB_TR_DEBUG, ( "new_QApplication %i B %i KB",
( int ) hb_xquery( 1001 ), hbqt_getmemused() ) );
so this part can be ignored but there is a problem with this code:
TCHAR lpOutputString[ 2048 ];
MultiByteToWideChar( CP_ACP, 0, buffer2, -1,
lpOutputString, sizeof( lpOutputString ) );
OutputDebugString( lpOutputString );
It's potential buffer overflow bug because MultiByteToWideChar()
needs as parameter size of buffer in characters not in bytes though
doubled buffered size reduce it - probably even eliminate it because
I do not think that languages which double number of characters in
unicode representation exists anyhow I strongly suggest to clean this
code and change it to:
TCHAR lpOutputString[ 1024 ];
MultiByteToWideChar( CP_ACP, 0, buffer2, -1, lpOutputString, 1024 );
OutputDebugString( lpOutputString );
HTH
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DBSEEK()
On Tue, 29 Dec 2009, Mindaugas Kavaliauskas wrote:
Hi,
> I have a question/discussion about DBSEEK(). I've started from the
> different ADSCDX and DBFCDX behavior and later included Clipper
> tests.
> #ifdef __HARBOUR__
> REQUEST ADSCDX
> #endif
> REQUEST DBFCDX
> FIELD F
> FUNC main(cADS)
> IF EMPTY(cADS)
> RDDSETDEFAULT("DBFCDX")
> ELSE
> RDDSETDEFAULT("ADSCDX")
> ENDIF
> ? VERSION(), RDDSETDEFAULT()
> DBCREATE("test187", {{"F", "N", 5, 0}},, .T.)
> OrdCreate("test187", "f", "F")
> DBAPPEND(); F := 1
> DBSEEK(10, .T., .F.)
> ? RECNO()
> DBSEEK(10, .T., .T.)
> ? RECNO()
> DBCLOSEALL()
> RETURN 0
> The code above prints:
> C:\cawi32\sample\test>test187.exe
> Harbour 2.0.0 (Rev. 13372) DBFCDX
> 2
> 1
> C:\cawi32\sample\test>test187.exe xxx
>
> Harbour 2.0.0 (Rev. 13372) ADSCDX
> 2
> 2
> C:\cawi32\sample\test>test187.exe
> Clipper (R) 5.2e Intl. (x216) (1995.02.07) DBFCDX
> 2
> 2
Clipper 5.2 does not support 3-rd parameter in dbSeek()
function. This is only CL5.3 DBFCDX feature.
> So, I looks like Harbour's DBFCDX is wrong and ADSCDX is OK, but my
> co-worker said, that Clipper has bugs in softseek. I've tried
Harbour results are correct and are the same as in CL53/COMIX CDX
implementation. Seek last with softseek on should fully revert the
positioning order and when exact key cannot be found should stop
at 1-st smaller value (1 in 1-st record in your example) or at EOF
if smaller value does not exists (try: DBSEEK(0, .T., .T.))
I have no idea if seek last in ADS works correctly or not.
> another test:
> REQUEST DBFCDX
> #ifdef __HARBOUR__
> REQUEST ADSCDX
> #endif
> FIELD F
> PROC main(cADS)
> IF EMPTY(cADS)
> RDDSETDEFAULT("DBFCDX")
> ELSE
> RDDSETDEFAULT("ADSCDX")
> ENDIF
> ? VERSION(), RDDSETDEFAULT()
> DBCREATE("test188", {{"F", "N", 5, 0}},, .T.)
> OrdCreate("test188", "f", "F")
> DBAPPEND(); F := 1
> DBAPPEND(); F := 1
> DBAPPEND(); F := 3
> DBAPPEND(); F := 3
> DBSEEK(2, .T., .F.)
> ? RECNO()
> DBSEEK(2, .T., .T.)
> ? RECNO()
> DBCLOSEALL()
> RETURN
> It prints:
> C:\cawi32\sample\test>test188.exe
> Harbour 2.0.0 (Rev. 13372) DBFCDX
> 3
> 2
So Harbour DBFCDX results are correct.
> C:\cawi32\sample\test>test188.exe xxx
> Harbour 2.0.0 (Rev. 13372) ADSCDX
> 2
> 2
Interesting, looks like both forward and backward seek gives wrong
results in ADS.
> C:\cawi32\sample\test>test188.exe
> Clipper (R) 5.2e Intl. (x216) (1995.02.07) DBFCDX
> 5
> 5
Passing 3 parameters to dbSeek() in CL5.2 breaks the second one.
If you remove the 3-rd parameter then you will have:
3
3
and these are expected Harbour native RDDs compatible results for
forward seek.
> So, we have a different behavior for all of RDD's, and I seems
> Clipper ignores softseek at all.
No. CL5.2 does not support 3-rd parameter in DBSEEK() and using it breaks
the second one. If you fix your test code to be CL5.2 compatible then
it gives the same results as Harbour.
Only ADS seems to be broken. I still cannot find 64 bit ADS local
server client for Linux so I cannot test it and confirm your results
so I cannot tell you if it's Harbour ADSRDD or ADS/ACE problem which
should be reported to Extended System.
> From a printed (CL53) reference guide vol.1 page 2-315 I can read:
> " is specified as true (.T.) to seek the last occurence of
> the specified key value." , but it is not clear how it works if
> specified key does not exists. I can also read on the same page:
> "... for a soft seek, the work area is positioned to the first
> record whose key value is greater than the specified key value. If
> no such record exists, the work area is positioned to LASTREC() + 1
> and EOF() returns true (.T.)".
It's defined indirectly by dynamic descend flag which causes
that seek last should work like in Harbour native RDDs and
CL53/COMIX. In such implementation seek last is fully revertible
by switching to descending order ( ordDescend(,,!ordDescend()) )
and forward seek. Otherwise we will have some anomalies.
> So, in the latter sample (test188) I would expect:
> 3
> 4
No. 3 and 2.
> but not any of the above results from various tests.
> *** So, how soft seek and last seek should work? ***
Just like in Harbour native RDDs.
> The question becomes even more complicated if think about DESCENT index.
No, in clear implementation there is no problem at all (see above)
and in Harbour all native RDDs fully respects seek last in ascending
and descending orders also with dynamic descond flag.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DBSEEK()
On Tue, 29 Dec 2009, Przemysław Czerpak wrote: > Only ADS seems to be broken. I still cannot find 64 bit ADS local > server client for Linux so I cannot test it and confirm your results > so I cannot tell you if it's Harbour ADSRDD or ADS/ACE problem which > should be reported to Extended System. I've just tested 32bit Linux Harbour build on remote machines with and ADS local server in your second tests gives the same results as Harbour (2 3) so it's possible that the problem is only in ADS remote server or in some ACE libraries (I used 9.10) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: [Harbour] SF.net SVN: harbour-project:[13415] trunk/harbour
On Tue, 29 Dec 2009, Bisz István wrote: Hi, > After testing with and without -DHB_TR_LEVEL_DEBUG cflags, it works as > it is expected. Thank you very much for your tests. > In my test case the QApplication.cpp: line 212-214 contains: >HB_TRACE( HB_TR_DEBUG, ( " new_QApplication%i B > %i KB", ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) ); > and DbgView shows with HB_TR_LEVEL_DEBUG defined in fm.c: > 00062246 17:42:34.462[4612] c:\downloads\harbour\src\vm\fm.c:1187: > HB_TR_DEBUG hb_xquery(1001) > 00062247 17:42:34.462[4612] c:\downloads\harbour\src\vm\fm.c:1187: > (???) new_QApplication0 B 3100 KB > My test results: > 1. Analyzing the output produced by the line 212 we can see that the file, > line and level info is altered. Maybe is useful to send here the original > info instead of hb_xquery trace location. It's not hb_xquery() problem. The same will happen for any function which internally calls HB_TRACE() and is used as parameter of some other HB_TRACE() message. In general it's side effect of keeping the file name and the line number in global variables hb_tr_file_ and hb_tr_line_. Also trace massage level is stored in global variable so it can be overwritten in final message though fortunately it does not change the message filter condition. Such solution is neither reentrant safe (problems like above) nor MT safe. We need it for two reasons: 1. to set file name and line number for memory statistics 2. as workaround for limited C preprocessor functionality The 1-st one we can ignore. It's not very important in current days because we have other more precise methods to detect memory leaks with exact allocation places like valgrind instead of showing the last place where HB_TRACE() message. Anyhow if someone wants then we can try to make it MT safe by moving above variables to HVM stack. The 2-nd one is bigger problem. Only C99 defines macros with variable number of arguments so it may be hard to find clean portable method which will not use any global/static variables without allocating buffer for message on C stack what may cause serious problems for total C stack usage. Now in macro HB_TRACE( l, x ) we use x with additional () so for C preprocessor it's like one parameter and we can define it like: #define HB_TRACE( l, x ) hb_tr_trace x and then use it as: HB_TRACE( HB_TR_INFO, ( "msg %d, %d, %d", 1, 2, 3 ) ); It works but such trick does not allow to insert new parameters to x so we cannot switch to hb_tracelog() function. This can be done using ISO C99 __VA_ARGS__ macro, i.e.: #define hb_tr_trace_( ... ) __VA_ARGS__ #define HB_TRACE( l, x ) hb_tracelog( l, __FILE__, __LINE__, \ NULL, hb_tr_trace_ x ) Some C compilers have their own extensions with macros having variable number of parameters, i.e. using GCC we can define hb_tr_trace_ as: #define hb_tr_trace_( args... ) args but still it's not widely portable solution. > 2. The insertion of the hb_xtraced function in nortl.c it was necessary > to build harbour with HB_TR_LEVEL_DEBUG defined: Yes, it has to be added. I'll commit it in a while, thank you for the info. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DBSEEK()
On Tue, 29 Dec 2009, Mindaugas Kavaliauskas wrote:
Hi,
> >It's defined indirectly by dynamic descend flag which causes
> >that seek last should work like in Harbour native RDDs and
> >CL53/COMIX. In such implementation seek last is fully revertible
> >by switching to descending order ( ordDescend(,,!ordDescend()) )
> >and forward seek. Otherwise we will have some anomalies.
> Ok, if understand the idea of seeklast now, then it means "try doing
> seek backward (in reversed index order, like using DESCEND)", but
> not "return the last record (having maximal recno value) of the
> records having the same key value".
Too much complicated for me ;-)
I rather suggest you to think about functionality. This code:
dbSeek( dtFirst, .T., .F. )
while field->DATE <= dtLast .and. !EOF()
[...]
dbSkip( 1 )
enddo
should scan the same record set as this code:
dbSeek( dtLast, .T., .T. )
while field->DATE >= dtFirst .and. !BOF()
[...]
dbSkip( -1 )
enddo
and this also precisely defines which record should be chosen
when the exact key does not exists and for soft seek last.
> But ADS still have bug in the first test. If softseek positions at
> EOF seeklast does not help to stop on last record. Here is the test
> indicating both correct (in some cases) and wrong (in another cases)
> behavior of ADS:
Yes, and your patch is correct though probably we can remove
AdsAtEOF() checking and always call:
u32RetVal = AdsSkip( pArea->hOrdCurrent, -1 );
I also suggest to store in u32RetVal AdsSeek() and AdsSeekLast() results
and move:
if( u32RetVal != AE_SUCCESS )
{
commonError( pArea, EG_CORRUPTION, ( HB_ERRCODE ) u32RetVal, 0, NULL,
EF_CANDEFAULT, NULL );
return HB_FAILURE;
}
to always generate RTE also when AdsSeek*() fails.
Please only check the AdsSeek*() results for empty ADT and DBF tables.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] CodePage different behaviour between 2.0.0beta3 and 2.0.0 (Win)
On Wed, 30 Dec 2009, Vitomir Cvitanovic wrote:
Hi,
> After Clean install of 2.0.0 release (win binaries) no keyboard
> and/or Display
> conversion is active :(
In current Harbour code all conversions use Unicode character
values and so far we do not use any fallback conversion tables.
It means that it's important to define correct Unicode tables
for each CP and for some more advanced translation add fallback
tables to chose the best approximations.
We have two CPs HR437 and SL437 which have national characters
instead of some ASCII ones:
#define HB_CP_UPPER "abc^]d\\efghijklmnopqrs[tu...@xy"
#define HB_CP_LOWER "abc~}d|efghijklmnopqrs{tuvwz`xy"
And here I have a question about real usage.
Does it mean that it's alternative notation so in Croatia and
Slovenia these ASCII glyphs ^...@~]|{` are "readable" for people
as national characters?
If yes then it's necessary to introduce translation fallback
tables to Harbour. It's very interesting feature (i.e. it allows
to translate Cyrillic strings to Latin string in phonetic notation)
but it's not available yet so it will have to wait for someone who
can implement it.
If not and for some historical reasons you used CPs where above ASCII
characters were replaced by your national characters then it means
that from the beginning in Harbour HR437 and SL437 were wrongly defined
because they do not use character glyphs from CP-437 so they were always
broken (also in beta3) though the problem were exploited in different
places i.e. in GTs using Unicode output. In such case the solution
is trivial. We only have to know correct unicode table used in that
encoding which at position ASC( "^" ) has value 0x01C ("Č"), at position
ASC( "~" ) -> 0x010D ("č"), ASC( "]" ) -> 0x0106 ("Ć"), ASC( "]" ) ->
0x0107 ("ć"), etc. For sure it's not CP437 and looking at src/codepahe/uc*.c
files I do not see any CP with such characters so it's necessary to
add it. Try to define such CP (it will be good to find if it already
has some "official" name) so we can add it to SVN and update HR437 and
SL437 to use it. Of course we will have to change their names.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] CodePage different behaviour between 2.0.0beta3 and 2.0.0 (Win)
On Wed, 30 Dec 2009, Przemysław Czerpak wrote: Hi, > add it. Try to define such CP (it will be good to find if it already > has some "official" name) so we can add it to SVN and update HR437 and > SL437 to use it. Of course we will have to change their names. I've found it in VIKI. It's YUSCII, isn't? And I guess that you are still using such encoding because it's quite easy to switch between Latin and Cyrillic YUSCII versions by simple font reloading. So all what we need for fully functional support for such encoding is adding Latin YUSCII table and then using it to replace CP-437 in HR437 and SL437. I think that we should also change their names to not confuse users. I hope that you can give some propositions. I have no idea if names like HRYU and SLYU are acceptable for you. I like żabeceda (I guess that in Poland we'd converted it to żabcia) but it's not good name to use in multilanguage project ;-) BTW you can also define unicode table for Cyrillic YUSCII which can be used as internal encoding if you want to easy switch to Cyrillic though I do not know if it's usable in real life. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] CodePage different behaviour between 2.0.0beta3 and 2.0.0 (Win)
On Wed, 30 Dec 2009, Vitomir Cvitanovic wrote:
Hi,
> YUSCII (CROSCII) had many names (YUSCII, CP-999, CROSCII, CRO-437),
> and this was first
> implementation of our diacritics, and it was 7-bit codepage...
> And again - you are wright it was also called žabeceda, because @
> that is implementation for Ž is before
> letter A :))
> About proposed name, I think it would be ok something like
> CROSCII/SLOSCII (I would like to avoid
> HRYU and SLYU). Or maybe HR999/SL999
I would like to keep two leading letters as ISO language code
so it should be HR and SL. In such case I think the best will
be HR999 and SL999.
> Some explanation:
> ---
> In the 1990s, there was a general confusion about the proper
> character encoding to use to
> write text in Latin Croatian (also Slovenian, Serbian-latin) on computers.
> - An attempt was made to apply the 7-bit coding - "YUSCII" (later
> adapted to CROSCII), which included
> the five letters with diacritics at the expense of five non-letter
> characters ([, ], {, }, @)
> (This "codepage" was called YUSCII, CP-999, CROSCII, CRO-437,...)
> Also this codepage was included with nation support for Clipper 5.2
> (MsgCro.obj, NtxCro.obj)
And this is important information. I've just generated cphr999.c file
using tests/cpinfo.prg and there is important difference between CL52
and Harbour CPs. Clipper uses this order:
#define HB_CP_UPPER "ABC^]D\EFGHIJKLMNOPQRS[TUVWXYZ@"
#define HB_CP_LOWER "abc~}d|efghijklmnopqrs{tuvwxyz`"
and Harbour:
#define HB_CP_UPPER "abc^]d\\efghijklmnopqrs[tu...@xy"
#define HB_CP_LOWER "abc~}d|efghijklmnopqrs{tuvwz`xy"
as you can see they are not binary compatible because letters
XY in Harbour are moved to the end after Ž and xy after ž.
If you need to share indexes between Harbour and Clipper then
Harbour have to use _EXACTLY_ the same sorting as Clipper
otherwise mixed Harbour and Clipper updates will cause index
corruption.
So there is new question:
Is it important difference for Croatian users so we should have
two CPs: HR999 with correct order "...s[tu...@xy" and HR999C
which uses a little bit different but strictly Clipper compatible
collation "...S[TUVWXYZ@" to use when data base files are shared
with Clipper applications?
Or it's not such important because X and Y letters are used very
seldom only in foreign words so only one HR999 but strictly compatible
with Clipper is enough?
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] CodePage different behaviour between 2.0.0beta3 and 2.0.0 (Win)
On Wed, 30 Dec 2009, Przemysław Czerpak wrote: Hi, > > YUSCII (CROSCII) had many names (YUSCII, CP-999, CROSCII, CRO-437), > > and this was first > > implementation of our diacritics, and it was 7-bit codepage... > > And again - you are wright it was also called žabeceda, because @ > > that is implementation for Ž is before > > letter A :)) > > About proposed name, I think it would be ok something like > > CROSCII/SLOSCII (I would like to avoid > > HRYU and SLYU). Or maybe HR999/SL999 > I would like to keep two leading letters as ISO language code > so it should be HR and SL. In such case I think the best will > be HR999 and SL999. I spent some time with google and I've found that this encoding confirms ISO-646 7bit standard and its "official" name is: ISO-646-YU Later is was also called YUSCII, CROSCII and SLOSCII but these are not official names. It's probably the last ISO-646-?? encoding still used in real life anyhow it's possible that someone will want to add to Harbour some others ISO-646 CPs due to compatibility with some old hardware so I would like to keep full official name for internal Unicode table with references to other *SCII names. Then I suggest to use HR646 and SL646 as Harbour CP names. I hope that such proposition is reasonable. What's your opinion? I'll be thankful if you can answer yet about adding HR646C or updating HR646 (current HR437) to use strictly Clipper compatible collation order. What do you prefer? Or maybe current order is wrong? I've just checked that in xHarbour HR* CPs use the same character order as in Clipper but SL* CPs not and are Harbour compatible. What is the correct sort order? Is it different for Croatia and Slovenia? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] CodePage different behaviour between 2.0.0beta3 and 2.0.0 (Win)
Hi Vito and Tomaž, > > Thursday 31 December 2009 06:58:38 je Vitomir Cvitanovic napisal: > > I think, and as far as I know (perhaps someone from Slovenia could verify > > that) that both Croatia and Slovenia have the same sort order. > On Thu, 31 Dec 2009, Tomaž Zupan wrote: > Yes, it is. Thank you for your confirmation. I'll update Slovenian and Croatian CPs in Harbour repository but I have some questions to you. Neither Slovenian nor Croatian collation define the relations to X and Y characters. OK but I do not believe that you never have to sort words having them so what is the common practice in such situations? I.e. how words starting with X or Y are sorted in printed vocabularies? Or maybe it depends on situation and different rules are used in vocabulary, encyclopedia and phone book? Or maybe these area is still undefined so everyone has to take his own arbitrary decision about it? It's possible that there are some differences between Slovenia and Croatia so I would like to hear the answer from both of you. The second part is addressed to Vito and Croatian users. You have three digraph letters: Dž, Lj and Nj. As I can see it created few problems. These digraphs should be sorted as single letter in precisely defined order which is not compatible with simple single character sorting. Dž is sorted as expected between Dz and Đ but Lj and Nj no. Lj should be sorted between Lz and M and Nj between Nz and O. Current Harbour code allows to define such collation but I do not know if it's important to introduce it. For sure it's not compatible with Clipper so if we add it then we have to keep also CP which is strictly ntxcor.obj compatible. Maybe even you will want to duplicate all existing Croatian CPs because though in fact current ones without native support for digraphs are the same as Slovenian CPs with only different names. Do you think it's important to add support for Croatian (and maybe Latin Serbian) collation respecting special order of digraphs? I also found the information that these digraphs were not well chosen because sometimes such character combination should be used as separate letters and real digraphs have own Unicode values. Is it true? If yes can you precisely tell me what are these Unicode values for upper and lower letters? Do you use them in real life? Are they supported by some CPs and/or do you have hardware support (keyboards?) for using them? Is it something what have to be resolved in the future or rather you will try to adopt existing solutions - i.e. in Poland our own national keyboard layout is dieing and now most of us prefer standard QWERTY layout with ALT-GR used to insert Polish national characters (we call it 'Polish programmer keyboard'). The answers should help me also in the future when I work on Unicode support in Harbour. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: [Harbour] Building HBIDE and qtcore4 lib.
On Thu, 31 Dec 2009, Horodyski Marek (PZUZ) wrote: Hi, > > What I'm doing : > Create and run file C:\harbour\contrib\hbxbp\a.bat : > set HB_USER_PRGFLAGS=-l%HB_USER_PRGFLAGS% > C:\harbour\win-make.exe > *- > On monitor I see : > C:\harbour\contrib\hbxbp>a.bat > C:\harbour\contrib\hbxbp>set HB_USER_PRGFLAGS=-l -l disables line numbers and it's set by default in Harbour build switches. You should use -l- to reenable line numbers, i.e.: set HB_USER_PRGFLAGS=-l- best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] CodePage different behaviour between 2.0.0beta3 and 2.0.0 (Win)
Hi Tomaž and Vito, Thank you for your answers. Now it's more clear for me. I'll update Croatian and Slovenian CPs in Harbour to sort X and Y before Z and I'll also send you an example of Croatian sorting using special order for digraphs. Maybe someone will find it useful. I think that Serbian users can be interesting in it because AFAIR some of them are replaced by single Cyrillic characters. In such case CP with correctly defined digraphs with their Unicode values can be used for automatic translations between Cyrillic and Latin alphabets. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Euro symbol support with xxiso codepages
On Thu, 31 Dec 2009, Lorenzo Fiorini wrote: Hi, > I'm moving from ITISB to ITISO to support West European languages and > I'm trying to get Euro symbol working on screen, in reports and in > file exports. Euro symbol is seldom used but it is on the keyboards so > users expect to get it. Euro sign has unicode value: U+20AC In Windows CP-125[02345678], IBM CP-874 and our modified ISO-8859-1B it's at possition 128 so if you use one of the above CPs then: ? CHR( 128 ) should show euro sign. In Windows CP-1251 (Cyrillic) it's at position 136 so you have to use: ? CHR( 136 ) In ISO-8859-7, ISO-8859-15 and ISO-8859-16 it's at position 164. i.e.: ? CHR( 164 ) U+20AC is not present in other Unicode tables so if you use other CP then probably it will not work as you want though due to result of repeated or ignored wrong translations in some configurations it will be shown on the screen or read from keyboard correctly. Anyhow such tricks are unimportant for us because they can stop to work at any moment so cannot be used in production environment. If you do not know exact euro sign encoding for given CP then you can try to define it using Unicode value, i.e.: #define EURO_SIGNHB_UTF8TOSTR( HB_UTF8ASC( 0x20AC ) ) ? EURO_SIGN > I've done few tests changing gtxwc encoding and cpitiso.c to 8859-15 > but without success. Please leave gtxwc working with Unicode fonts (iso10646-1). Otherwise it's possible that you mixed encoding so the results will be unpredictable because they will depend on character lost conversions in 3-rd party code. Even if you reach some expected effects then it's possible that it's not replicable on other machine which uses only one slightly different component and you will not know what is wrong and why. Change only encoding in Harbour CP (i.e. change unicode table in cpitiso.c and set "ITISO" as HVM and GT CP in your program. > Using linux/gtxwc I can type it, it shows like a small square but if I > export to a pdf ( using hbvpdf ) or to an rtf using rtf/ansi charset > it is showed correctly. > However if I import the dbf in an OpenOffice SpreadSheet using > ISO8859-15 encoding it shows like a square and I'm still trying to get > it out using HP PCL codes. > Ideas? Looks like a classic example of problems created by different encodings and wrong translations. Finlay you created combination where repeated wrong or ignored transformation give expected results. Without knowledge what _exactly_ you have modified in Harbour what _exactly_ you set as HVM and GT CPs in your programs and how it's configured your system (used locale) I cannot give you precise answer what has happened. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Happy New Year
Hi Francesco, I wish all the best to you and your family and fast health recovery to your mother. Have a lot of nice days in 2010 :-) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HAPPY NEW YEAR !!!
Hi All, I want to wish all of you HAPPY NEW YEAR !!! It's time to turn off the computer. My next message will be in year 2010 :-) 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:[13457] trunk/harbour
On Sun, 03 Jan 2010, vszak...@users.sourceforge.net wrote: Hi, > * harbour.spec > + Merged lib and static subpackages into main one. > hbmk2 requires that both dynamic and static libs (namely hbcplr) > are present for successful linking. > Please test and comment, I can revert old version in > case of any problems. Separate RPM with Harbour shared library is necessary for user who want to install dynamically linked Harbour applications. Now they have to install whole Harbour compiler though they will never try to compile anything. This part has to be fixed. As long as we do not create shared version of some harbour contrib libraries which needs 3-rd party libs like UnixODBC, postgres, mysql, ADS, ... then we can merge all other packages with static libs into single package because static libraries do not create explicit dependencies. Anyhow if we plan to distribute also shared version of above libraries in the future then they have to be in separated packages to not force installing bound 3-rd party software. Otherwise installing Harbour from RPM we will force installing RPMs with shared libraries for all 3-rt party components. We have also separate RPM with Harbour compiler and tools. Before hbmk2 when only hb* scripts were used it was usable because it was possible to not install harbour static libraries if someone wanted to create only dynamic ones. I still think that hbmk2 should be fixed to work without hbcplr and hbdebug anyhow it's not such important as separate RPM with Harbour shared library so this can be ignored. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Euro symbol support with xxiso codepages
On Sat, 02 Jan 2010, Lorenzo Fiorini wrote:
Hi,
> > In Windows CP-125[02345678], IBM CP-874 and our modified ISO-8859-1B
> > it's at possition 128 so if you use one of the above CPs then:
> > ? CHR( 128 )
> > should show euro sign.
> After many tests with postgresql, mysql, pdf, rtf, xls it seems that
> ITWIN is the best solution also for Linux/OSX.
> Euro sign is shown correctly at 0x80 even in an html page with
> encoding="ISO-8859-1".
Lorenzo, 0x80 is not correct position for euro sign in any ISO CPs.
None of ISO CPs contains characters in range 0x80 - 0x9F. These are
control codes in many hardware devices so such range is excluded.
As usual MS defined unportable CPs using characters in reserved range
so for the rest of world it's a bug. I.e. some terminals may not show
such characters but use them as control codes.
Because this range of characters is not used then in some programs
it's hacked to accept some other characters character. Recently they
begin to convert CHR(0x80) to unicode 0x20AC character as workaround
for buggy programs which use ISO-8850-1 CP with euro sign. ISO-8859-1
does not contain euro sign so any program or text like HTML page which
sets ISO-8859-1 and then try to use euro sign without explicit unicode
value encoding is wrong and has to be fixed. In some software audits
such basic things are checked at the beginning so it's important to
keep correct encoding if you want to expect positive results.
AFAIR in the past you asked me to add such hack for euro sign into
GTXWC so now we have in gtxwc.c this code:
if ( outISO == 0x20ac )
{
buf[0] = (BYTE) 0x80;
n = 1;
}
and as usual dirty hack sooner or later creates new problems.
Above code should be removed and we should implement clean solution
probably using real input context. It needs some additional
modifications but it's necessary also for extended keyboard layouts
in some countries. I do not have time for it now so as temporary
solution I'll replace above code with other hack which will not use
hardcoded euro position and maybe I'll return to this problem in the
future in some spare time and change keyboard code in GTXWC to use
input context.
> In mysql 5.0 latin1 is indeed cp1252 and in oocalc Windows
> 1252/WinLatin1 is the only encoding I found that shows the dbfs
> correctly. Not to mention that it makes easy to share data between
> gtxwc and win/gtwvt apps.
> So I plan to move from:
>REQUEST HB_CODEPAGE_ITISB
>HB_SETCODEPAGE( "ITISB" )
>HB_SETTERMCP( "ITISB", "ITISB", TRUE )
> to
>REQUEST HB_CODEPAGE_ITWIN
>SET( _SET_CODEPAGE, "ITWIN" )
>HB_SETTERMCP( "ITWIN", "ITWIN", TRUE )
> for all my platforms.
> Am I missing anything?
ITISB (ISO-8859-1B) is nothing more then non portable local Harbour CP
anyhow it has euro sign in exactly the same position as in ITWIN
(CP-1250) so above does not change anything for using euro sign.
Of course I'm talking about default Harbour CPs. If you have different
results then it means to you used modified ITISB or you made some mistake
in your tests. It doesn't matter what CP you will use. The only one
important thing is using correct values for different encoding so other
programs can correctly decode the data.
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:[13386] trunk/harbour
On Sat, 02 Jan 2010, Paul Tucker wrote:
Hi,
> I was curious how the original version of this seems to have
> disapeared and it seems that when you started modifying gt, you
> either used whatever version you started with and ignored further
> updates that were made to the code, or you actively excluded this
> code because you didn't know why it was there. (not sure).
> The other piece that I see is missing is that during a SetMode()
> change, the 'correct' way was to make sure that no dispbegin() was
> in effect before updating the console. (Definately Clipper
> compatible). I simply can't look into whether this will be an issue
> or not, but I wrote the code once, so it's still around if you need
> it.
> As for xHarbour, someone just blindly accepted your change as 'the
> way' and replaced the xharbour driver.
I think that you should look at ChangeLog or CVS/SVN history for both
projects. This code disappeard in Harbour SVN when _YOU_ committed
_MY_ new version of GTWIN and was never fixed untill recent Jacek
reports.
After few years you fixed the problem in xHarbour only but it was the
time when I was stopping to work on xHarbour moving to Harbour so I
didn't try to check each commit in xHarbour CVS line by line.
Probably I haven't even seen that you committed it or I simply ignored
such enigmatic ChangeLog message:
* correct potential stack overflow in gt_setmode
because it was for old GT system which in Harbour I replaced by
the new one.
Said that your fix were never applied in Harbour though you knew
the problem long ago. I'll be very happy if you can send even single
line note about any new problems you find in GT code also to Harbour
devel list so we can verify it and fix.
Below is a message with reference to above ChangeLog entries.
Look at dates.
best regards,
Przemek
- Forwarded message from Przemysław Czerpak -
Date: Wed, 23 Dec 2009 12:16:16 +0100
From: Przemysław Czerpak
To: "Harbour Project Main Developer List."
Subject: Re: [Harbour] Bug in hb_gt_win_SetMode()
Lines: 39
On Wed, 23 Dec 2009, Saulius Zrelskis wrote:
Hi,
> > Yes, you are right. Strange that no one reported it for such long time.
> Not true. I found version of gtwin.c dated 2008.01.18 and there were lines:
> ...
> /* Special case */
> if ( usRows < _GetScreenHeight() && usCols > _GetScreenWidth() )
> {
> HB_GT_FUNC(gt_SetMode( usRows, _GetScreenWidth() ));
> }
> else if ( usRows > _GetScreenHeight() && usCols < _GetScreenWidth() )
> {
> HB_GT_FUNC(gt_SetMode( _GetScreenHeight(), usCols ));
> }
> ...
> Later somehow this disappears.
I do not think so. The above code use old static multi GT API which
I implemented only in xHarbour and it was never part of Harbour where
I created dynamic multi GT API committed at:
2006-02-04 17:05 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
which now it used by both projects.
In Harbour the problem exists from 2002 and it was introduced when
Paul committed my initial alternative GTWIN implementation at:
2002-10-19 16:50 UTC-0500 Paul Tucker
It means that you had to take above code from xHarbour.
I've just check that above fix were committed to xHarbour CVS by Paul at:
2006-07-01 18:35 UTC-0500 Paul Tucker
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
- End forwarded message -
___
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:[13386] trunk/harbour
On Mon, 04 Jan 2010, Paul Tucker wrote: Hi, > I added this March 18, 2005. The Dispbegin/DispEnd has been in > since the very first entry in CVS for gtwin.c (2001), but you left > it out of your code for some reason. In any case, the gt code was > replaced by Phil Krylov on March 16 2008 (3 years to the day!) - Not > by me. > Isn't 2005-ish around the time you switched to Harbour? So you made it a year before. I really had to missed it. Sorry but it's probably one of few thousands other users commits in xHarbour CVS I was not checking line by line. Working on new GT code in Harbour I didn't took GTWIN from xHarbour but worked on them using Harbour code. In general I try to not use any code from xHarbour as is. Number of bugs in xHarbour code is too big to follow all of them. Fortunately it's not a problem now. There is nothing in xHarbour what does not exist in Harbour or does not have much better and faster replacement so there is nothing to take. Number of modifications in xHarbour CVS is minimal so there is a big chance that we do not drop sth important. Anyhow explicit info should always help. > As for 'Enigmatic Changelog entry' - I don't know what you mean by > that. If the changelog says that a stack overflow was fixed, why > ignore it? It was meant to describe a fix I made to the original > verion of the code in question. This entry is very clear. I was talking about the one I wrongly referred. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Euro symbol support with xxiso codepages
On Mon, 04 Jan 2010, Lorenzo Fiorini wrote:
Hi,
> BTW I've tried to remove the hack:
> if ( outISO == 0x20ac )
> {
> buf[0] = (BYTE) 0x80;
> n = 1;
> }
> but I can't type the Euro sign without it.
Try GTXWC from current SVN:
2010-01-04 13:10 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
It should work with CPs having euro sign on different position, i.e.
with modified ITISO using ISO-8859-15 or ISO-8859-16.
You can also compile it with HB_USER_CFLAGS=-DHB_XWC_USE_LOCALE.
In such case it enables locale what should help when some local
keyboard layout are used.
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:[13457] trunk/harbour
On Mon, 04 Jan 2010, Szak�ts Viktor wrote: Hi, > hbmk2 could easily be "fixed" simply by not adding > these libs at all in neither static or dynamic builds. > This will however make hbmk2 usage somewhat more > complicated for users. For sure hbdebug is something > I'd let hbmk2 to handle automatically, otherwise > I envision many support questions. Can you make it like in hb* scripts which check if each harbour static library enabled by default exist before adding it to linked library list? It's enough to enable such logic in hbmk2 for hbcplr and hbdebug. Such modification does not change anything for hbmk2 users. 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:[13444] trunk/harbour
On Sun, 03 Jan 2010, Szak�ts Viktor wrote: Hi, > In fact the whole point of previous implementation was > that we warn developers if there _is_ a leak, and stay > silent if there isn't. This way it's apparent when there > is a problem and when not. If we wash together the > two messages, it will be less easy to spot if there is > a problem. I can imagine a 'zero' value could be useful > for testers to see there _was_ testing/measurement done, > yet the result is zero. Probably that's the reason Istvan > added it. If this is the only reason then we should revert this modification. For such functionality we have //info switch which can be used to verify if FM statistic module is enabled and how much memory was allocated and released. Just simply run any applications with this switch, i.e.: myapp.exe //info 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:[13444] trunk/harbour
On Mon, 04 Jan 2010, Szak�ts Viktor wrote:
Hi,
> > If this is the only reason then we should revert this modification.
> > For such functionality we have //info switch which can be used to
> > verify if FM statistic module is enabled and how much memory was
> > allocated and released. Just simply run any applications with this
> > switch, i.e.:
> > myapp.exe //info
> Can you pls do it? I'm unsure what should be the "revert"
> state here, I did about 3-4 modifications after Istvan's
> initial one.
I was talking about these lines added by Istvan:
else
{
hb_conOutErr( hb_conNewLine(), 0 );
hb_snprintf( buffer, sizeof( buffer ), HB_I_("Memory allocated but not
released: none") );
hb_conOutErr( buffer, 0 );
}
When //info runtime switch is used (explicitly as application parameter
or using HARBOUR envvar) then memory statistic is always present so it's
not necessary to show such dummy message.
Before I'll remove it I'll wait for Istvan opinion.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] about xharbour compact.
On Mon, 04 Jan 2010, WenSheng wrote: Hi, > I have a function 'AT()' can not be compiler, > I use 'nPos := At( ';', cPrinters, nStart )', > If I have not joined a custom function, I will be unable to successfully > compile the code. > #xtranslate At(,) => hb_At(,) > Who can I ask this grammar by adding "hbcompat.ch" do? hbcompat.ch is a file which try to hide some differences between Harbour and xHarbour using PP rules. If possible I strongly suggest to to migrate to clean Harbour code and not use it. The AT() function in Harbour is fully compatible with Clipper/xBase/ADS/... AT() function. We do not used to modify any existing xBase functions to not create portability problems when standard functions with extended parameters are used in expressions which are shared between different dbase compatible RTLs or when some code has to be compiled by different compilers. This is very important because using standard dBase functions with unportable extended parameters may exploit serious problems in really unexpected places, i.e. when indexes are used by programs compiled by other compilers or by some remote RDDs like ADS. Harbour is strictly compatible with Clipper/dBase so if it's documented that some other language (except xHarbour :() supports the some dbase functions then they should work in the same way and you do not have to check all parameters and worry that index will be corrupted because foreign code wrongly understand local extensions to standard functions. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
On Mon, 04 Jan 2010, Bisz István wrote: Hi, > First of all Happy New Year! Thank you and Happy New Year. > The intention behind of this message, is to inform the developer that > everything goes well: the FM statistic module collects the necessary > info and the analysis at the end of the program execution detects that > there is no memory leak. In the previous solution the analyzer remained > mute in this situation (no memory leak detected) and the developer tried > to hunt for a possible bug, this was my experience too, maybe it was my > fault. So my impression is that this info can be useful for the developers, > that the all allocated blocks are released correctly. > To be exact, this is the final solution implemented here by Viktor with > the same intention behind as I understood correctly. So such functionality existed before and this modification is redundant and effects output of all programs linked with memory statistic module All what you need is running your progrm with //info parameter. Just try. IMHO it's much better solution then adding the message: "Memory allocated but not released: none" which is always shown when application is closed. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
On Mon, 04 Jan 2010, Bisz István wrote:
> OK. Maybe I was too happy to see this message, sorry.
Ups. I've just seen that it was not always shown but only
when //INFO were used so it's fine for me. I only suggest
to replace:
hb_snprintf( buffer, sizeof( buffer ),
HB_I_("Memory allocated but not released: none") );
hb_conOutErr( buffer, 0 );
with simple:
hb_conOutErr( HB_I_("Memory allocated but not released: none"), 0 );
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: RE: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
On Mon, 04 Jan 2010, Bisz István wrote: > An another issue is I think is in hbtrace.c with the following line: > MultiByteToWideChar( CP_ACP, 0, hb_strncpy( message, buf.psz, > sizeof( message ) - 1 ), -1, > buf.lp, HB_SIZEOFARRAY( buf.lp ) ); > The strncpy( message, buf.psz, sizeof( message ) - 1 ) can lead into a > recursive HB_TRACE call, as it happened in one of my test case. Right. I'll fix it in a while. Thank you very much for information. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
On Mon, 04 Jan 2010, Szak�ts Viktor wrote:
Hi,
> We're lured into the impression that HBQT doesn't leak memory.
> I say this because HBQT in dynamic mode doesn't seem to be
> using our memory allocation functions at all, so nothing is
> tracked, which means we're getting a constant zero leak
> whatever is happening inside HBQT.
> Do you have any suggestions to how to force C++ to use our
> own memory allocation function, or where to look for a solution?
In Linux you can use valgrind to check memory leaks.
Just simply run:
valgrind --tool=memcheck --leak-check=yes -v ./demoqt 2> demoqt.log
and check the memory allocated and not released. If you compile Harbour
with -g GCC option (HB_USER_CFLAGS=-g) and not strip final binaries
then you will also have exact line number information. It's much more
precise information then in our own memory statistic module.
I think that you can also find some tools to test allocated and
not freed resources for MS-Windows (i.e. Pritpal was using sth like
that when he reported that HVM do not destroy internal mutexes on
exit) though probably the reports will not be very precise.
In fm.c we have code to overload C++ new operators but it's enabled
only when core code is compiled in C++ mode. If you want to enable
it in all HBQT builds then these code should be moved to one of it's
.cpp files which is always linked. It's not very elegant but it should
work.
Alternatively we can try to use dlmalloc as full replacement for
standard malloc()/calloc()/realloc()/free() functions and report
info all memory blocks not freed after HVM exit. This is the most
often used method in different devel tools catching memory leaks.
To minimize number of modifications and keep our own FM logs we
can also use dlmalloc with USE_DL_PREFIX and create our own wrappers
to above functions, i.e.:
void * malloc( size_t size )
{
return hb_xalloc( size );
}
void * calloc( size_t size )
{
void * ptr = hb_xalloc( size );
if( ptr )
memset( ptr, 0, size );
return ptr;
}
[...]
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:[13463] trunk/harbour
On Mon, 04 Jan 2010, Vailton Renato wrote: > Thank you! I have noted your precious tips and am aware and I intend > to use this "power" with "great responsibility" and to help whenever > it is within my reach. Welcome on board. 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:[13469] trunk/harbour
On Mon, 04 Jan 2010, vszak...@users.sourceforge.net wrote: Hi, > 2010-01-04 23:28 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * utils/hbmk2/hbmk2.prg > + Will now ignore hbdebug and hbcplr static Harbour libs when > creating dynamic binaries, if these libs are not present. Thank you very much. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] (no subject)
On Mon, 04 Jan 2010, Bisz István wrote: Hi, > ../../../hbtrace.c(250) : error C2664: 'MultiByteToWideChar' : cannot > convert parameter 3 from 'void *' to 'LPCSTR' Fixed, thank you very much for the information. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] difference between Clipper and Harbour
On Mon, 04 Jan 2010, Marco Boeri wrote: Hi, > Hi all, > I'm new to Harbour compiler. Great piece of code ! > Today I tried to compile an old Clipper 5.2e program that still works. > I found a difference between the two compilers. I have made a code example. [...] > The accept command in Clipper works well and there is no wait, while > Harbour needs an ENTER keypress to have same behaviour. I tested your program using CL5.2 and Harbour and in both cases I have exactly the same results so I do not see any difference. Can you tell me how exploit the problem? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ct functions
On Mon, 04 Jan 2010, Marco Boeri wrote: Hi, > some ct fuctions aren't recognized by Harbour. > These are > FontReset( ) > FontLoad( ) > FontSelect( ) > I added in .hbp file the -lhbct option, but without success. > Are they not yet implemented or there are new/other functions > to use instead of ? Such functionality like font reloading is available in practice only in DOS. In all other sysystems it's impossible to load and activate fonts using binary font definition so noone implemented above functions It's possible that they will be added in the future for Harbour DOS builds but you should not expect that they will work in Harbour compiled for other platforms. They will always return -2 'Impossible in current video mode'. Sorry but this part is out of our control and we cannot easy emulate hardware (video adapter) behavior in modern systems where direct access to hardware devices is blocked by OS for native application. If such functionality is a must for you then it can be implemented in DOS Harbour versions (just like SETFONT() is implemented in DJGPP builds) and you can create DOS application and run it in full screen DOS mode using windows if your windows still supports it or using DOSBOX or similar emulator. Other solution is converting your raw font definition to system native font format and loading them using some system settings, i.e. by chosing font for console window in MS-Windows for GTWIN or using hb_gtInfo() with HB_GTI_* actions in grapic GTs like GTWVT or GTXWC. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
