Re: [xHarbour-developers] How do you use the profiler?
here works:
PROCEDURE InitProfiler( lInfo )
STATIC oProfile
IF Empty( oProfile )
__setProfiler( .T. )
oProfile := HBProfile():New() // New() is a default method in the class
system that calls :init() to initialize the object
// Turn on profiling.
__setProfiler( .T. )
ENDIF
DEFAULT lInfo := .F.
IF lInfo
// Take a profile snapshot.
oProfile:gather()
/*
// Report on calls greater than 0
!! Todos los metodos y funciones llamados una o mas veces, ordenados
por LLAMADAS
!! HBProfileReportToString():New( oProfile:callSort() ):generate( {|o|
ValType( o:nCalls ) == 'N' .AND. o:nCalls 0 } )
// Sorted by name
!! Todos los metodos y funciones llamados una o mas veces, ordenados
por NOMBRE
!! HBProfileReportToString():New( oProfile:nameSort() ):generate( {|o|
ValType( o:nCalls ) == 'N' .AND. o:nCalls 0 } )
*/
// Ordenado por : nTicks / nCalls mostrando sólo valores 1
!! Todos los metodos y funciones llamados una o mas veces, ordenados
por TIEMPO
aEval( HBProfileReportToArray():New( oProfile:Sort( {|a,b| a:nMeanTicks
b:nMeanTicks } ) ):generate( {|o| o:nMeanTicks
1 } ),;
{|e| __OutDebug( e ) } )
// TBrowse all calls greater than 0
// TBrowse all methods/functions called one or more times
// oProfile:callSort()
// Some closing stats
!! Totals
!! Total Calls: + Str( oProfile:totalCalls() )
!! Total Ticks: + Str( oProfile:totalTicks() )
!! Total Seconds: + Str( oProfile:totalSeconds() )
ENDIF
RETURN
Luis Krause Mantilla escribió:
Hi:
I'm trying to use the profiler but the app dies as soon as I attempt to
use it.
I first rebuilt xharbour using -DHB_USE_PROFILER
Then I build our app using fmstat.lib
I create an hbProfile object and then call
__setProfiler( .F. )
anything I do after (click on a menu, or a button to open a process),
the app dies.
Do I need to use additional flags? add other libs? cross my fingers?
Thanks!
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] 2009-01-15 09:40 UTC+0100 Enrico Maria Giordano e.m.giord...@emagsoftware.it
2009-01-15 09:40 UTC+0100 Enrico Maria Giordano e.m.giord...@emagsoftware.it * include/hbsetup.h * Changed HB_PCODE_VER to 10 EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] freeze to make version
I think we are prepared to freeze to make version. at www.xharbour.org there are version 1.0 and is very different from actual version I think we need to add a new version. Best regards Miguel Angel Marchuet -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] freeze to make version
I agree. Lets freeze and start the build proces. Patrick On Thu, Jan 15, 2009 at 10:21 AM, Miguel Angel Marchuet miguelan...@marchuet.net wrote: I think we are prepared to freeze to make version. at www.xharbour.org there are version 1.0 and is very different from actual version I think we need to add a new version. Best regards Miguel Angel Marchuet -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] freeze to make version
Yes, but we must first have a BUG FREEZE, and address known issues, f.e. the GPF that Miguel reported in calling fm api before init, as well as DESTRUCTORs problem and MT issue on OS/2. I would like to ask everyone here to please UPDATE and CLEAN BUILD, then report status - build issues, hbtest results, as well as detailed report on any open issue you are aware of. Thanks in advance, Ron -- From: Patrick Mast, xHarbour. patrick.m...@xharbour.com Sent: Thursday, January 15, 2009 1:47 AM To: Miguel Angel Marchuet miguelan...@marchuet.net Cc: xharbour developer list xharbour-developers@lists.sourceforge.net Subject: Re: [xHarbour-developers] freeze to make version I agree. Lets freeze and start the build proces. Patrick On Thu, Jan 15, 2009 at 10:21 AM, Miguel Angel Marchuet miguelan...@marchuet.net wrote: I think we are prepared to freeze to make version. at www.xharbour.org there are version 1.0 and is very different from actual version I think we need to add a new version. Best regards Miguel Angel Marchuet -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] freeze to make version
-Messaggio Originale-
Da: Ron Pinkas ron.pin...@xharbour.com
A: Patrick Mast, xHarbour. patrick.m...@xharbour.com; Miguel Angel
Marchuet miguelan...@marchuet.net
Cc: xharbour developer list xharbour-developers@lists.sourceforge.net
Data invio: giovedì 15 gennaio 2009 14.00
Oggetto: Re: [xHarbour-developers] freeze to make version
I would like to ask everyone here to please UPDATE and CLEAN BUILD, then
report status - build issues, hbtest results, as well as detailed report
on
any open issue you are aware of.
Ops, this is a recent issue:
FUNCTION MAIN()
Local aStru:={{'aa','C',3,0},;
{'bb','C',3,0}}
DbCreate('testxxx',aStru); Close
Use testxxx Exclusive New
Append Blank
Replace aa With 'xxx'
Replace bb With 'xxx'
Append Blank
Replace aa With 'ggg'
Replace bb With 'ggg'
Append Blank
Replace aa With 'kkk'
Replace bb With 'kkk'
Sort On aa To testxxx1
RETURN NIL
EMG
--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 Miguel AngelMarchuet miguelan...@marchuet.net
Miguel, Sure, but I never encountered any such problem - do you have any self contained sample that will show such GPF? Ron -- From: Miguel Angel Marchuet miguelan...@marchuet.net Sent: Thursday, January 15, 2009 8:12 AM To: Ron Pinkas ron.pin...@xharbour.com; xharbour developer list xharbour-developers@lists.sourceforge.net Subject: Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 MiguelAngelMarchuetmiguelan...@marchuet.net there are 26509 calls to hb_xgrab, hb_xrealloc previous hx_xinit the debuguer colapse my machine, please can you find this calls ;) to situate in a better place the call to hb_xinit() Best regards, Miguel Angel Marchuet Ron Pinkas escribió: Miguel, It's very easy to find and fix, simply add: assert( hProcessHeap ); Then build with debug info, and you'll get the exact line and call stack leading to the failed assert. Here's my settings for MSVC debug build: SET CFLAGS=/Od /EHsc /RTC1 /MTd /Gs /GS /Gy /GR /Zi /DHB_FM_STATISTICS /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE SET LFLAGS=-DEBUG -DEBUGTYPE:CV Ron -- From: Miguel Angel Marchuet Frutos miguelmarch...@gmail.com Sent: Wednesday, January 14, 2009 10:40 AM To: Ron Pinkas ron.pin...@xharbour.com Cc: xharbour developer list xharbour-developers@lists.sourceforge.net Subject: Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 Miguel AngelMarchuet miguelan...@marchuet.net I don't tested exctly where is called fm.api but if i remove the protection change: # define malloc( n ) ( void * ) HeapAlloc( ( hProcessHeap ? hProcessHeap : GetProcessHeap() ), 0, ( n ) ) # define realloc( p, n ) ( void * ) HeapReAlloc( ( hProcessHeap ? hProcessHeap : GetProcessHeap() ), 0, ( void * ) ( p ), ( n ) ) # define free( p )HeapFree( ( hProcessHeap ? hProcessHeap : GetProcessHeap() ), 0, ( void * ) ( p ) ) with: # define malloc( n ) ( void * ) HeapAlloc( hProcessHeap, 0, ( n ) ) # define realloc( p, n ) ( void * ) HeapReAlloc( hProcessHeap, 0, ( void * ) ( p ), ( n ) ) # define free( p )HeapFree( hProcessHeap, 0, ( void * ) ( p ) ) then GPF is produced because there are a call to hb_xalloc or hb_xrealloc previous to hb_xinit. Harbour has the same problem for this reason prezmek needt to protect too. But i want to remove this protection. Can you say me how to build xharbour with debug info for mscv8 ? I'm evaluating too to create a process heap for each thread to eliminate some locks at MT. Best regards Miguel Angel Marchuet Ron Pinkas escribió: Miguel, WHERE do we use fm api before it's initialized? Ron -- From: Miguel Angel Marchuet miguelan...@marchuet.net Sent: Wednesday, January 14, 2009 2:48 AM To: xharbour developer list xharbour-developers@lists.sourceforge.net Subject: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 Miguel AngelMarchuet miguelan...@marchuet.net 2009-01-14 11:34 UTC+0100 Miguel Angel Marchuet miguelan...@marchuet.net * source\vm\fm.c ! minor optimization, 1 seg more quick speedtst, but remains one important question fmapi is used before its initialization (void hb_xinit( void )) I think this function need be called first of all. - removed test comments. + Added macro HB_FM_LOCALALLOC to use LocalAlloc instead of HeapAlloc. Microsoft says that the use of LocalAlloc need be changed by HeapAlloc, but we leave it here to user election. Best regards, Miguel Angel Marchuet -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3767 (20090115) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour
Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 Miguel AngelMarchuet miguelan...@marchuet.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3767 (20090115) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3769 (20090115) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 Miguel AngelMarchuet miguelan...@marchuet.net
with this entry is solved for Borland compilers HB_CALL_ON_STARTUP_BEGIN( _hb_fm_init_ ) hb_xinit(); HB_CALL_ON_STARTUP_END( _hb_fm_init_ ) #if defined( HB_PRAGMA_STARTUP ) #pragma startup _hb_fm_init_ 64 #elif defined( HB_MSC_STARTUP ) #if defined( HB_OS_WIN_64 ) #pragma section( HB_MSC_START_SEGMENT, long, read ) #endif #pragma data_seg( HB_MSC_START_SEGMENT ) static HB_$INITSYM hb_vm_auto_fm_init = _hb_fm_init_; #pragma data_seg() #endif but remain Microsoft ones Any can help to set correct priority to Microsoft compilers Best regards, Miguel Angel Marchuet -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 Miguel AngelMarchuet miguelan...@marchuet.net
Miguel, I already fixed it in a compiler independent way, and will commit shortly. Ron -- From: Miguel Angel Marchuet miguelan...@marchuet.net Sent: Thursday, January 15, 2009 9:16 AM To: Przemyslaw Czerpak dru...@acn.waw.pl; Ron Pinkas r...@xharbour.com; xharbour developer list xharbour-developers@lists.sourceforge.net Subject: Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 MiguelAngelMarchuetmiguelan...@marchuet.net with this entry is solved for Borland compilers HB_CALL_ON_STARTUP_BEGIN( _hb_fm_init_ ) hb_xinit(); HB_CALL_ON_STARTUP_END( _hb_fm_init_ ) #if defined( HB_PRAGMA_STARTUP ) #pragma startup _hb_fm_init_ 64 #elif defined( HB_MSC_STARTUP ) #if defined( HB_OS_WIN_64 ) #pragma section( HB_MSC_START_SEGMENT, long, read ) #endif #pragma data_seg( HB_MSC_START_SEGMENT ) static HB_$INITSYM hb_vm_auto_fm_init = _hb_fm_init_; #pragma data_seg() #endif but remain Microsoft ones Any can help to set correct priority to Microsoft compilers Best regards, Miguel Angel Marchuet -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 Miguel AngelMarchuet miguelan...@marchuet.net
Witch solution you found ? i changed priority to 64, default is 100 for this reason is the first init to execute. but i don't know the semantic of #pragma data_seg Best regards, Miguel Angel Marchuet Ron Pinkas escribió: Miguel, I already fixed it in a compiler independent way, and will commit shortly. Ron -- From: Miguel Angel Marchuet miguelan...@marchuet.net Sent: Thursday, January 15, 2009 9:16 AM To: Przemyslaw Czerpak dru...@acn.waw.pl; Ron Pinkas r...@xharbour.com; xharbour developer list xharbour-developers@lists.sourceforge.net Subject: Re: [xHarbour-developers] 2009-01-14 11:34 UTC+0100 MiguelAngelMarchuetmiguelan...@marchuet.net with this entry is solved for Borland compilers HB_CALL_ON_STARTUP_BEGIN( _hb_fm_init_ ) hb_xinit(); HB_CALL_ON_STARTUP_END( _hb_fm_init_ ) #if defined( HB_PRAGMA_STARTUP ) #pragma startup _hb_fm_init_ 64 #elif defined( HB_MSC_STARTUP ) #if defined( HB_OS_WIN_64 ) #pragma section( HB_MSC_START_SEGMENT, long, read ) #endif #pragma data_seg( HB_MSC_START_SEGMENT ) static HB_$INITSYM hb_vm_auto_fm_init = _hb_fm_init_; #pragma data_seg() #endif but remain Microsoft ones Any can help to set correct priority to Microsoft compilers Best regards, Miguel Angel Marchuet -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 3769 (20090115) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] Unicode builds and type standarize
Dear Friends I'd like to suggest if possible an new standart for xharbour api functions so we can build xharbour with unicode support is possible to use this standarization for all api declaration for char* /const char* #if defined (_UNICODE) !defined (UNICODE) #define UNICODE #endif #if defined (UNICODE) !defined (_UNICODE) #define _UNICODE #endif #ifndef _WIN32 #include ctype.h typedef unsigned long DWORD; typedef longLONG; typedef int BOOL; typedef unsigned char BYTE; typedef unsigned short WORD; typedef unsigned intUINT; typedef unsigned short WCHAR;// wc, 16-bit UNICODE character typedef const WCHAR *LPCWSTR; typedef const char *LPCSTR; typedef WCHAR *LPWSTR; typedef char *LPSTR; #ifdef _UNICODE typedef wchar_t TCHAR; typedef LPCWSTR LPCTSTR; typedef LPWSTR LPTSTR; #define _T(x) L ## x #else /* _UNICODE */ // r_winnt typedef char TCHAR; typedef LPCSTR LPCTSTR; typedef LPSTR LPTSTR; #define _T(x) x #endif /* _UNICODE */// r_winnt #else #include TCHAR.H #include windows.H #ifndef STRICT #define STRICT #endif #endif and declare our functions From extern HB_FORCE_EXPORT char * hb_parc( int iParam, ... ); /* retrieve a string parameter */ extern HB_EXPORT char * hb_parcx( int iParam, ... ); /* retrieve a string parameter */ to extern HB_FORCE_EXPORT LPTSTR hb_parc( int iParam, ... ); /* retrieve a string parameter */ extern HB_EXPORT LPTSTR hb_parcx( int iParam, ... ); /* retrieve a string parameter */ this will make easy to build xharbour with unicode support Regards Luiz -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] 2009-01-15 13:55 UTC-0430 Ron Pinkas ron/at/xharbour.com
Ron: I don't know if this fix is related or not to the profiler problems I'm experiencing. If you copy source\rtl\profiler.prg to any temp folder and then build as a standalone sample it with -D__TEST__ using bcc55 it will gpf. Regards, Ron Pinkas wrote: 2009-01-15 13:55 UTC-0430 Ron Pinkas ron/at/xharbour.com * source/vm/fm.c - Removed missing initialization protection for hProcessHeap from maloc/realloc/free macros. * source/vm/hvm.c * Moved call to hb_xinit() from hb_vmInit() to hb_vmProcessSymbols() which is called earlier. /* Applications compiled with HB_FM_WIN32_ALLOC should now be faster, as initialization protection will take place only once per compiled module, at application startup, rather than for every malloc()/realloc()/free() */ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- Luis Krause Mantilla lkrausem at shaw dot ca luis_krause at hotmail dot com May the Source be with GNU -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] 2009-01-15 13:55 UTC-0430 Ron Pinkas ron/at/xharbour.com
2009-01-15 13:55 UTC-0430 Ron Pinkas ron/at/xharbour.com * source/vm/fm.c - Removed missing initialization protection for hProcessHeap from maloc/realloc/free macros. * source/vm/hvm.c * Moved call to hb_xinit() from hb_vmInit() to hb_vmProcessSymbols() which is called earlier. /* Applications compiled with HB_FM_WIN32_ALLOC should now be faster, as initialization protection will take place only once per compiled module, at application startup, rather than for every malloc()/realloc()/free() */ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] Unicode builds and type standarize
Miguel sounds interesting, but you still need the type i listed bellow to hold unicode Regards Luiz - Original Message - From: Miguel Angel Marchuet Frutos miguelmarch...@gmail.com To: Luiz Rafael Culik Guimaraes l...@xharbour.com.br Cc: Xharbour-Developers xharbour-developers@lists.sourceforge.net Sent: Thursday, January 15, 2009 5:58 PM Subject: Re: [xHarbour-developers] Unicode builds and type standarize I was thinking about to add flag to string items to inform oem,ansi,wide,utf8... and change operators len,+,left,right,substr,etc... to work properly add function to retrive this flag information then to develop unicode aplication will be easier. what do you think about ? Best regards, Miguel Angel Marchuet Luiz Rafael Culik Guimaraes escribió: Dear Friends I'd like to suggest if possible an new standart for xharbour api functions so we can build xharbour with unicode support is possible to use this standarization for all api declaration for char* /const char* #if defined (_UNICODE) !defined (UNICODE) #define UNICODE #endif #if defined (UNICODE) !defined (_UNICODE) #define _UNICODE #endif #ifndef _WIN32 #include ctype.h typedef unsigned long DWORD; typedef longLONG; typedef int BOOL; typedef unsigned char BYTE; typedef unsigned short WORD; typedef unsigned intUINT; typedef unsigned short WCHAR;// wc, 16-bit UNICODE character typedef const WCHAR *LPCWSTR; typedef const char *LPCSTR; typedef WCHAR *LPWSTR; typedef char *LPSTR; #ifdef _UNICODE typedef wchar_t TCHAR; typedef LPCWSTR LPCTSTR; typedef LPWSTR LPTSTR; #define _T(x) L ## x #else /* _UNICODE */ // r_winnt typedef char TCHAR; typedef LPCSTR LPCTSTR; typedef LPSTR LPTSTR; #define _T(x) x #endif /* _UNICODE */// r_winnt #else #include TCHAR.H #include windows.H #ifndef STRICT #define STRICT #endif #endif and declare our functions From extern HB_FORCE_EXPORT char * hb_parc( int iParam, ... ); /* retrieve a string parameter */ extern HB_EXPORT char * hb_parcx( int iParam, ... ); /* retrieve a string parameter */ to extern HB_FORCE_EXPORT LPTSTR hb_parc( int iParam, ... ); /* retrieve a string parameter */ extern HB_EXPORT LPTSTR hb_parcx( int iParam, ... ); /* retrieve a string parameter */ this will make easy to build xharbour with unicode support Regards Luiz -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] freeze to make version
I would like to ask everyone here to please UPDATE and CLEAN BUILD, then report status - build issues, hbtest results, as well as detailed report on any open issue you are aware of. FWH is working fine, but all FWH sources need be recompiled. Regards, Toninho. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] ChangeLog 2009-01-16 04:53 UTC+0300 Phil Krylov phil a t newstar.rinet.ru
2009-01-16 04:53 UTC+0300 Phil Krylov phil a t newstar.rinet.ru * include/Makefile ! Removed reference to nonexistent hbcomprs.h. * include/classes.h * source/vm/classes.c + Added Harbour-compatible C-level class APIs hb_clsCreate(), hb_clsAdd(), hb_clsAssociate(). Partially borrowed from Harbour code written by Przemyslaw Czerpak. * include/hbapiitm.h * source/vm/eval.c * source/vm/hvm.c * source/vm/itemapi.c + added startup symbol to hb_stack. It gives very good stop condition for all procedures which trace stack calls and resolves the problem with hb_stack.pBase which was never pointing to valid function/procedure symbol when no symbol was put on HVM stack. Now after hb_stackInit() the first item is allocated for hb_stackInit() symbol so hb_stack.pBase is always a pointer to valid function/procedure symbol. * changed the guard condition for buggy code in hb_stackPop() and similar code from: hb_stack.pPos hb_stack.pItems to: hb_stack.pPos = hb_stack.pBase The old condition was generating usable error message only in the startup function. In deeply called functions it was only waste of CPU time on one of the most often call functions. Before it was activated internal stack structures were corrupted. (by Przemyslaw Czerpak, borrowed from Harbour. In xHarbour it's also needed to register classes on startup from C code.) + Added Harbour-compatible hb_itemPutSymbol(). * common.mak * compile.mak * source/rtl/Makefile - source/rtl/terror.prg + source/rtl/einstvar.prg * include/hbapierr.h * source/vm/errorapi.c * Ported Harbour's C-level implementation of ERROR class. This is faster and allows to avoid PCode execution (which can lead to more errors) on error object creation. * include/hbstack.h * include/thread.h * source/rdd/wacore.c * source/vm/thread.c * source/vm/estack.c ! Some RDD data (e.g. current area pointer) must ALWAYS be thread-local in xHarbour, independent of _SET_WORKAREAS_SHARED setting! ! Fixed missing mutex unlock when HB_RDD_MAX_AREA_NUM is reached in hb_rddSelectFirstAvailable(). % Optimized stack access some hb_stack*() functions. * source/vm/dynsym.c ! Fixed a HB_TRACE call. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
