[Harbour] Re: Harbour under OS/2 - eCS
Viktor >2008-06-01 23:56 UTC+0100 Viktor Szakats (harbour.01 syenar hu) > * include/hbvm.h > * source/vm/hvm.c > * source/vm/extrap.c > ! Fixed OS/2 problem reported by David. > (BTW, do we need really need to remove the exception > handler before exiting? If yes, shouldn't we do the > same under Win32?) Current Harbour under OS/2 build fine but report error on executables exit Is first time I see this kind of error on OS/2 hbtest: ... WARNING ! Failures detected Exception c005 at address 0x1c021b0d SYS1808: The process has stopped. The software diagnostic code (exception code) is 0005. hbdot: RDD:| Area:| Dbf:| Index: | #/ Exception c005 at address 0x1c021b0d SYS1808: The process has stopped. The software diagnostic code (exception code) is 0005. [E:\harbour806\harbour\bin]help sys1808 SYS1808: The process has stopped. The software diagnostic code (exception code) is ***. EXPLANATION: The program generated an exception that the system cannot resolve. The soft ware diagnostic code allows determination of what type of exception was generated. ACTION: Correct the problem or try a different version of the program. David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour under OS/2 - eCS
Hi David, Please try to remove OS/2 exception handling stuff in source/vm/extrap.c and see if it helps. Brgds, Viktor On 2008.06.02., at 10:05, David Arturo Macias Corona wrote: Viktor >2008-06-01 23:56 UTC+0100 Viktor Szakats (harbour.01 syenar hu) > * include/hbvm.h > * source/vm/hvm.c > * source/vm/extrap.c > ! Fixed OS/2 problem reported by David. > (BTW, do we need really need to remove the exception > handler before exiting? If yes, shouldn't we do the > same under Win32?) Current Harbour under OS/2 build fine but report error on executables exit Is first time I see this kind of error on OS/2 hbtest: ... WARNING ! Failures detected Exception c005 at address 0x1c021b0d SYS1808: The process has stopped. The software diagnostic code (exception code) is 0005. hbdot: RDD:| Area:| Dbf:| Index: | #/ Exception c005 at address 0x1c021b0d SYS1808: The process has stopped. The software diagnostic code (exception code) is 0005. [E:\harbour806\harbour\bin]help sys1808 SYS1808: The process has stopped. The software diagnostic code (exception code) is ***. EXPLANATION: The program generated an exception that the system cannot resolve. The soft ware diagnostic code allows determination of what type of exception was generated. ACTION: Correct the problem or try a different version of the program. David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 11:34 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-06-02 11:34 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * source/vm/extrap.c ! Blind fix for OS/2. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour under OS/2 - eCS
Viktor
>Please try to remove OS/2 exception handling stuff
>in source/vm/extrap.c and see if it helps.
These are SVN browse of last change (rev 8553, 8562)
What code should I to change ?
-
{
167 hb_errInternal( HB_EI_ERRUNRECOV, "Unable to setup
exception handler (DosSetExceptionHandler())", NULL, NULL );
hb_errInternal( HB_EI_ERRUNRECOV, "Unable to setup exception handler
(DosSetExceptionHandler())", NULL, NULL );
168} }
169 #endif
170 }
171
172 void hb_vmUnsetExceptionHandler( void )
173 {
174 #if defined(HB_OS_OS2) /* Add OS2TermHandler to this thread's
chain of exception handlers */
175 {
176 EXCEPTIONREGISTRATIONRECORD RegRec;/* Exception
Registration Record */
177 APIRET rc; /* Return code
*/
178
179 /* I don't do any check on return code since harbour is
exiting in any case */
180rc = DosUnsetExceptionHandler( &RegRec );
181HB_SYMBOL_UNUSED( rc );
-
David Macias
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 12:00 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-06-02 12:00 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * source/common/hbverdsp.c ! Minor correction. * Wording/layout. C++/C and ANSI C init mode is now in one line as "Other build settings". * contrib/hbcurl/hbcurl.c + Comment extended regarding libcurl version requirement. + Added version guard (not currently effective). -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 12:42 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-06-02 12:42 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbsqlit3/tests/blob.prg * harbour/contrib/hbsqlit3/tests/sqlite3_test.prg * harbour/contrib/hbsqlit3/sqlite3/sqlite3.c * harbour/contrib/hbsqlit3/sqlite3/sqlite3.h * converted TABs to SPACEs best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour under OS/2 - eCS
Viktor >2008-06-02 11:34 UTC+0100 Viktor Szakats (harbour.01 syenar hu) > * source/vm/extrap.c > ! Blind fix for OS/2. > David, please test with current repo. No change, exactly same error: Exception c005 at address 0x1c021b0d ( everything was rebuilt with new extrap.c ) memset( &RegRec, 0, sizeof( RegRec ) ); RegRec.ExceptionHandler = ( ERR ) hb_os2ExceptionHandler; David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 13:32 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-06-02 13:32 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbexprop.h * harbour/include/hbexprb.c * harbour/source/common/expropt2.c + added hb_compExprReducePower() and compile time optimization for: ^ + added compile time optimization for: % when or is not integer value NOTE: both optimizations are not Clipper compatible and disabled when -kc compiler switch is used best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour under OS/2 - eCS
Hi David, I have run out of ideas then, sorry. You could still try to remove all OS/2 stuff from extrap.c and see if it helps. In all OS/2 stuff I mean everything which is guarded with HB_OS_OS2. Brgds, Viktor On 2008.06.02., at 12:50, David Arturo Macias Corona wrote: Viktor >2008-06-02 11:34 UTC+0100 Viktor Szakats (harbour.01 syenar hu) > * source/vm/extrap.c > ! Blind fix for OS/2. > David, please test with current repo. No change, exactly same error: Exception c005 at address 0x1c021b0d ( everything was rebuilt with new extrap.c ) memset( &RegRec, 0, sizeof( RegRec ) ); RegRec.ExceptionHandler = ( ERR ) hb_os2ExceptionHandler; David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Harbour under OS/2 - eCS
David, please test with current repo.
Brgds,
Viktor
On 2008.06.02., at 11:15, David Arturo Macias Corona wrote:
Viktor
>Please try to remove OS/2 exception handling stuff
>in source/vm/extrap.c and see if it helps.
These are SVN browse of last change (rev 8553, 8562)
What code should I to change ?
-
{
167 hb_errInternal( HB_EI_ERRUNRECOV, "Unable to setup
exception handler (DosSetExceptionHandler())", NULL, NULL );
hb_errInternal( HB_EI_ERRUNRECOV, "Unable to setup exception handler
(DosSetExceptionHandler())", NULL, NULL );
168} }
169 #endif
170 }
171
172 void hb_vmUnsetExceptionHandler( void )
173 {
174 #if defined(HB_OS_OS2) /* Add OS2TermHandler to this
thread's chain of exception handlers */
175 {
176 EXCEPTIONREGISTRATIONRECORD RegRec;/* Exception
Registration Record */
177 APIRET rc; /* Return
code*/
178
179 /* I don't do any check on return code since harbour
is exiting in any case */
180rc = DosUnsetExceptionHandler( &RegRec );
181HB_SYMBOL_UNUSED( rc );
-
David Macias
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 13:57 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-06-02 13:57 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbcurl/common.mak * harbour/contrib/hbcurl/hbcurl.c * harbour/contrib/hbcurl/hbcurl.ch * harbour/contrib/hbcurl/Makefile ! set svn:eol-style to native * harbour/contrib/hbcurl/make_gcc.sh ! set svn:eol-style to LF * harbour/contrib/hbcurl/Makefile * added missing rules to install header files and create library * harbour/contrib/hbcurl/hbcurl.ch ! closed uncloused /* comments * harbour/contrib/hbcurl/hbcurl.c ! fixed hb_curl_calloc() to clear allocated memory best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 13:32 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Great, thanks a lot Przemek. Some other candidates for optimizations that sprang to mind (after I wrote that NOTE unfortunately), are the hb_bit*() functions. Not a priority, but they would be useful, when using these functions in #defines to not cause any additional runtime cost. If you agree and have time, these would be also great IMO. (Sorry for forgetting about these when writing my first NOTE) Brgds, Viktor On 2008.06.02., at 13:33, Przemyslaw Czerpak wrote: 2008-06-02 13:32 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbexprop.h * harbour/include/hbexprb.c * harbour/source/common/expropt2.c + added hb_compExprReducePower() and compile time optimization for: ^ + added compile time optimization for: % when or is not integer value NOTE: both optimizations are not Clipper compatible and disabled when -kc compiler switch is used best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 15:40 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-06-02 15:40 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbsqlit3/hbsqlit3.c ! use char * instead of LPSTR to compile in non Windows environment ! fixed one printf() parames ! fixed casting and parameter type in sqlite3_blob_open() * harbour/include/hbexprop.h * harbour/include/hbexprb.c * harbour/source/common/expropt1.c * harbour/source/common/expropt2.c - removed unused hb_compExprAsLong() + added hb_compExprAsLongNum(), hb_compExprReduceBitFunc() + added compiletime optimizatiob for HB_BIT*() functions: HB_BITAND(), HB_BITOR(), HB_BITXOR(), HB_BITSET(), HB_BITRESET() HB_BITSHIFT(), HB_BITNOT(), HB_BITTEST() best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Problem building RDDADS
Hi all, I am trying to build RDDADS using the current CVS - I set HB_DIR_ADS as indicated but I am getting the following build error using MSVC v6: ..\mtpl_vc.mak(112) : fatal error U1023: syntax error in expression Stop. Randy. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem building RDDADS
Hi Randy, Are you sure this file is unmodified? (Line 112 is a comment, and the only change in the recent month was a few flags removed.) Brgds, Viktor On 2008.06.02., at 16:08, Randy Portnoff wrote: Hi all, I am trying to build RDDADS using the current CVS - I set HB_DIR_ADS as indicated but I am getting the following build error using MSVC v6: ..\mtpl_vc.mak(112) : fatal error U1023: syntax error in expression Stop. Randy. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 15:40 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Perfect! Brgds, Viktor On 2008.06.02., at 15:41, Przemyslaw Czerpak wrote: 2008-06-02 15:40 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbsqlit3/hbsqlit3.c ! use char * instead of LPSTR to compile in non Windows environment ! fixed one printf() parames ! fixed casting and parameter type in sqlite3_blob_open() * harbour/include/hbexprop.h * harbour/include/hbexprb.c * harbour/source/common/expropt1.c * harbour/source/common/expropt2.c - removed unused hb_compExprAsLong() + added hb_compExprAsLongNum(), hb_compExprReduceBitFunc() + added compiletime optimizatiob for HB_BIT*() functions: HB_BITAND(), HB_BITOR(), HB_BITXOR(), HB_BITSET(), HB_BITRESET() HB_BITSHIFT(), HB_BITNOT(), HB_BITTEST() best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 15:40 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, One observation: I'd expect HB_CURLPAUSE_ALL to be optimized to one integer value. HB_CURLPAUSE_ALL is hb_bitOr( A, B ) where A = ( 2 ^ 0 ) B = ( 2 ^ 2 ) In the resulting pcode, hb_bitOr() is not optimized, and it's being pushed two doubles with the (width set to 255, 255). Shouldn't or couldn't these values be integers, if they can fit? Also hb_bitOr() is otherwise optimizing doubles, but in this case it doesn't for some reason. Brgds, Viktor On 2008.06.02., at 15:41, Przemyslaw Czerpak wrote: 2008-06-02 15:40 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbsqlit3/hbsqlit3.c ! use char * instead of LPSTR to compile in non Windows environment ! fixed one printf() parames ! fixed casting and parameter type in sqlite3_blob_open() * harbour/include/hbexprop.h * harbour/include/hbexprb.c * harbour/source/common/expropt1.c * harbour/source/common/expropt2.c - removed unused hb_compExprAsLong() + added hb_compExprAsLongNum(), hb_compExprReduceBitFunc() + added compiletime optimizatiob for HB_BIT*() functions: HB_BITAND(), HB_BITOR(), HB_BITXOR(), HB_BITSET(), HB_BITRESET() HB_BITSHIFT(), HB_BITNOT(), HB_BITTEST() best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbexprb.c ! do not optimize HB_BIAND(), HB_BITOR() and HB_BITXOR() when only one parameter is passed to keep RT error compatibility * use hb_compExprListStrip() to optimize function calls also when parameters are passed in parenthesis, f.e.: ? CHR(65), CHR((65)) It's not Clipper compatible and disabled by -kc switch. Viktor it will interact with some hbtest tests when compile time optimization used by Clipper gives different results then RT function f.e. CHR( ( 256 ) ). Please think if we should keep it. It's important optimization if someone uses constant values or expressions defined in parentheses. best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem building RDDADS
Hi Randy,
I think you miss the HB_VISUALC_VER envvar, and
the line no is misreported by nmake (yes, and they
didn't bother to fix even in 9.0 - compatibility
must be the reason ;)
So, please use this:
set HB_VISUALC_VER=60
I'll add something to default to a safely looking value
instead of choking like this. Actually the best would
be to somehow remove this envvar requirement and make
8.0 (and upper) detection automatic. Maybe Marek could
help.
Brgds,
Viktor
On 2008.06.02., at 16:51, Randy Portnoff wrote:
Hi Viktor,
I run MAKE_VC.BAT and this is the output...
Using this .dll: "C:\AXS32\32bit\ace32.dll"
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
..\mtpl_vc.mak(112) : fatal error U1023: syntax error in expression
Stop.
...and here is what is at my line 112 ("# C Compiler Flags" is
apparently at line 112)
# C Compiler Flags
!if $(HB_VISUALC_VER) >= 80
CFLAGS_VER = -Ot2b1 -FD -Gs -D_CRT_SECURE_NO_DEPRECATE
!else
CFLAGS_VER = -Ogt2yb1p -GX- -G6 -YX -FD -Gs
!endif
#---
Randy.
At 10:22 AM 6/2/2008, you wrote:
Hi Randy,
Are you sure this file is unmodified?
(Line 112 is a comment, and the only change
in the recent month was a few flags removed.)
Brgds,
Viktor
On 2008.06.02., at 16:08, Randy Portnoff wrote:
Hi all,
I am trying to build RDDADS using the current CVS - I set HB_DIR_ADS
as indicated but I am getting the following build error using MSVC
v6:
..\mtpl_vc.mak(112) : fatal error U1023: syntax error in expression
Stop.
Randy.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Case insensitive environment vars
Hi all, IMO, any of the environment variables that are set to a value like "yes" (eg. HB_BUILD_ST) should be case insensitive. I had mine set as HB_BUILD_ST=YES and it had no effect - I took me a while to realize what the problem was. Randy. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem building RDDADS
Hi Viktor,
I run MAKE_VC.BAT and this is the output...
Using this .dll: "C:\AXS32\32bit\ace32.dll"
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
..\mtpl_vc.mak(112) : fatal error U1023: syntax error in expression
Stop.
...and here is what is at my line 112 ("# C Compiler Flags" is
apparently at line 112)
# C Compiler Flags
!if $(HB_VISUALC_VER) >= 80
CFLAGS_VER = -Ot2b1 -FD -Gs -D_CRT_SECURE_NO_DEPRECATE
!else
CFLAGS_VER = -Ogt2yb1p -GX- -G6 -YX -FD -Gs
!endif
#---
Randy.
At 10:22 AM 6/2/2008, you wrote:
Hi Randy,
Are you sure this file is unmodified?
(Line 112 is a comment, and the only change
in the recent month was a few flags removed.)
Brgds,
Viktor
On 2008.06.02., at 16:08, Randy Portnoff wrote:
Hi all,
I am trying to build RDDADS using the current CVS - I set HB_DIR_ADS
as indicated but I am getting the following build error using MSVC v6:
..\mtpl_vc.mak(112) : fatal error U1023: syntax error in expression
Stop.
Randy.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 15:40 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Mon, 02 Jun 2008, Szakáts Viktor wrote: Hi Viktor, > One observation: > I'd expect HB_CURLPAUSE_ALL to be optimized > to one integer value. > HB_CURLPAUSE_ALL is > hb_bitOr( A, B ) > where > A = ( 2 ^ 0 ) > B = ( 2 ^ 2 ) > In the resulting pcode, hb_bitOr() is not optimized, > and it's being pushed two doubles with the (width set > to 255, 255). > Shouldn't or couldn't these values be integers, if > they can fit? It will break some compatibility with SET FIXED / SET DECIMAL. Integer number are formatted in different way by VM then double values. > Also hb_bitOr() is otherwise optimizing > doubles, but in this case it doesn't for some reason. It's caused by strictly Clipper compatible behavior in our expression optimizer. See the question in my last commit and decide what we should do. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Case insensitive environment vars
Hi Randy, I think a better approach would be to use 0/1 rather than words. HB_BUILD_MODE is also effected. Look at make_b32.bat to see how many variations are covered explicitly for build targets, and the many hours wasted updating these duplicate lines all over Harbour. So I'd rather not make it any worse. [ IOW for DOS/Win batch files all possible combination should be listed to give a 100% solution, for all such options. ] Brgds, Viktor On 2008.06.02., at 17:09, Randy Portnoff wrote: Hi all, IMO, any of the environment variables that are set to a value like "yes" (eg. HB_BUILD_ST) should be case insensitive. I had mine set as HB_BUILD_ST=YES and it had no effect - I took me a while to realize what the problem was. Randy. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Problem building RDDADS
Thanks - That worked!
At 11:03 AM 6/2/2008, you wrote:
Hi Randy,
I think you miss the HB_VISUALC_VER envvar, and
the line no is misreported by nmake (yes, and they
didn't bother to fix even in 9.0 - compatibility
must be the reason ;)
So, please use this:
set HB_VISUALC_VER=60
I'll add something to default to a safely looking value
instead of choking like this. Actually the best would
be to somehow remove this envvar requirement and make
8.0 (and upper) detection automatic. Maybe Marek could
help.
Brgds,
Viktor
On 2008.06.02., at 16:51, Randy Portnoff wrote:
Hi Viktor,
I run MAKE_VC.BAT and this is the output...
Using this .dll: "C:\AXS32\32bit\ace32.dll"
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
..\mtpl_vc.mak(112) : fatal error U1023: syntax error in expression
Stop.
...and here is what is at my line 112 ("# C Compiler Flags" is
apparently at line 112)
# C Compiler Flags
!if $(HB_VISUALC_VER) >= 80
CFLAGS_VER = -Ot2b1 -FD -Gs -D_CRT_SECURE_NO_DEPRECATE
!else
CFLAGS_VER = -Ogt2yb1p -GX- -G6 -YX -FD -Gs
!endif
#---
Randy.
At 10:22 AM 6/2/2008, you wrote:
Hi Randy,
Are you sure this file is unmodified?
(Line 112 is a comment, and the only change
in the recent month was a few flags removed.)
Brgds,
Viktor
On 2008.06.02., at 16:08, Randy Portnoff wrote:
Hi all,
I am trying to build RDDADS using the current CVS - I set HB_DIR_ADS
as indicated but I am getting the following build error using MSVC
v6:
..\mtpl_vc.mak(112) : fatal error U1023: syntax error in expression
Stop.
Randy.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, We currently also use the '()' non-optimization for HB_SYMBOL_UNUSED(). If we can resolve the above, and make it possible to disable the feature using -k switch, I think we are fine with it. If this involves any complexities though, I'd leave it for after RC1. Brgds, Viktor On 2008.06.02., at 16:46, Przemyslaw Czerpak wrote: 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbexprb.c ! do not optimize HB_BIAND(), HB_BITOR() and HB_BITXOR() when only one parameter is passed to keep RT error compatibility * use hb_compExprListStrip() to optimize function calls also when parameters are passed in parenthesis, f.e.: ? CHR(65), CHR((65)) It's not Clipper compatible and disabled by -kc switch. Viktor it will interact with some hbtest tests when compile time optimization used by Clipper gives different results then RT function f.e. CHR( ( 256 ) ). Please think if we should keep it. It's important optimization if someone uses constant values or expressions defined in parentheses. best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Mon, 02 Jun 2008, Szakáts Viktor wrote: Hi Viktor, > We currently also use the '()' non-optimization for > HB_SYMBOL_UNUSED(). It is and was optimized. For all expressions like: (exp) (exp) our expression optimizer strips parenthesis. It's also not Clipper compatible and maybe we should disable this optimization when -kc is used. Now it's always enabled. We also have some other optimizations not done by Clipper, f.e. Clipper does not make any optimization for when message is sent to , f.e.: ? (10==10):calsname Now this optimization can be disabled by -kc. > If we can resolve the above, and make it possible to disable > the feature using -k switch, I think we are fine with it. > If this involves any complexities though, I'd leave it for after RC1. In last commit I've already done it for function parameters and -kc disable this optimization. Anyhow I think we should update hbtest and use #pragma -kc / #pragma -khx or HB_C52_STRICT macro for some of CHR( ( ) ). See current hbtest results. In general there is a problem with compile time optimizations for CHR( * 256 ) and $ operator in expressions like: "" $ caused by bugs in Clipper compiler. It gives different results then runtime functions/operations. Keeping strict Clipper compatibility is hard in complex expressions. Probably we should think about adding option to set valid results in such situations or we should introduce flag for expressions to mark them as optimized and in such case do not replicate wrong Clipper compile time optimizations. BTW I also thing we should also add INT( ) optimization. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, In general there is a problem with compile time optimizations for CHR( * 256 ) and $ operator in expressions like: "" $ caused by bugs in Clipper compiler. It gives different results then runtime functions/operations. Keeping strict Clipper compatibility is hard in complex expressions. Probably we should think about adding option to set valid results in such situations or we should introduce flag for expressions to mark them as optimized and in such case do not replicate wrong Clipper compile time optimizations. We may guard those with #pragmas for Harbour, to disable compile time optimization for these cases, or better yet, add both versions to make the difference more apparent. One thing I forgot: To do this we'd need a switch which would toggle the parenthesised expression optimization only. BTW, for me it's unclear by looking at the 'harbour /k?' help, which options are enabled by default, and what is the relation between them. It's unclear whether '-kh' actually means all, or a selection of options turned on, or something else. Plus, rather than saying 'lowercase/uppercase significant' it would be more intuitive to just use lowercase for 'J' and 'M', and make casing not to matter, like for the rest of Harbour switches. I can make this, but I wonder if there was any special reason doing it like this? Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 18:59 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-06-02 18:59 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/xhb/hbcompat.ch ! Minor fix in hb to xhb branch. * contrib/hbcurl/hbcurl.ch * '( 2 ** n )' expressions changed to actual values. ; We now have these optimized, but I'm committing anyway, as some folks may be scared away by seeing these, and not knowing it's optimized (and they might not even be optimized on some Clipper platforms...). * contrib/mtpl_vc.mak ! Fixed HB_VISUALC_VER to default to '60' rather than crashing. Same default is used for core make files already. * source/common/hbverdsp.c - Removed 'CA'. + Added word 'compatible' to the 'undocumented' line. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Release Time
What about new harbour's web site and fidonet group? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Barnett Sent: Monday, June 02, 2008 5:01 AM To: Harbour@harbour-project.org Subject: [Harbour] Release Time I know I promised to make the release mark last weekend, but things got in the way and this is the first time I've even gotten back to read the list's email. Wow, what a huge effort on bug fixing. I'm glad this all made it into the release candidate. Please let me know if the bug fixes are all in for everything but contrib and I'll set the mark. If you have a bug fix that needs to go in before we set the RC1 mark, do it now or let us all know when it will go in. I expect to set the RC1 mark Tuesday night. -- Waiting for sunspots. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, We currently also use the '()' non-optimization for HB_SYMBOL_UNUSED(). It is and was optimized. For all expressions like: (exp) (exp) our expression optimizer strips parenthesis. It's also not Clipper compatible and maybe we should disable this optimization when -kc is used. Now it's always enabled. We also have some other optimizations not done by Clipper, f.e. Clipper does not make any optimization for when message is sent to , f.e.: ? (10==10):calsname Now this optimization can be disabled by -kc. This is fine. I've also checked HB_SYMBOL_UNUSED(), and it works. If we can resolve the above, and make it possible to disable the feature using -k switch, I think we are fine with it. If this involves any complexities though, I'd leave it for after RC1. In last commit I've already done it for function parameters and -kc disable this optimization. Anyhow I think we should update hbtest and use #pragma -kc / #pragma -khx or HB_C52_STRICT macro for some of CHR( ( ) ). See current hbtest results. In general there is a problem with compile time optimizations for CHR( * 256 ) and $ operator in expressions like: "" $ caused by bugs in Clipper compiler. It gives different results then runtime functions/operations. Keeping strict Clipper compatibility is hard in complex expressions. Probably we should think about adding option to set valid results in such situations or we should introduce flag for expressions to mark them as optimized and in such case do not replicate wrong Clipper compile time optimizations. We may guard those with #pragmas for Harbour, to disable compile time optimization for these cases, or better yet, add both versions to make the difference more apparent. It's not possible to make a perfect decision here, unless investing extreme energy (like those flags) to keep bug compatibility, not to mention what an ugly inconsistency this is. My personal opinion in this case is to fix this Clipper bug in Harbour, and make it available using a switch for those few ppl who are relying on them and haven't yet corrected their code. I suspect there is not too many such ppl, and even most of this code is probably macro compiled. Question: Do we do all these optimization for macro code too, and do we have a way to disable it? Yes and yes is the answer AFAIK, so IMO we're covered. BTW I also thing we should also add INT( ) optimization. Definitely. I'd plug these just to not forget about them, but these will need new pcodes, so it's a slightly different story: - HB_P_PUSHNIL + HB_P_RETVALUE would become: HB_P_RETNIL - HB_P_FALSE + HB_P_RETVALUE would become: HB_P_RETFALSE - HB_P_TRUE + HB_P_RETVALUE would become: HB_P_RETTRUE - SUBSTR(s,n,1) -> HB_P_SUBSTR1 (or whatever name) - ASC(SUBSTR(s,n,1)) -> HB_P_SUBSTR1ASC (or whatever name) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 19:55 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-06-02 19:55 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbexprop.h * harbour/include/hbexprb.c * harbour/source/common/expropt2.c + added compile time INT( ) optimization * harbour/source/compiler/hbusage.c * updated -k? description to show "(default)" for really set flags best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Show symbol of the square root in console application
Any suggestions/tip for this? TIA Best Regards GVS Guillermo Varona Silupú escribió: Hi I have a small console application in which I want to show the symbol of the square root, but the screen shows me at number 1 as superscript. What should I set to display the symbol of the square root? Env.: WinXP SP2 + Harbour + MinGW TIA Best Regards GVS ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour __ Information from ESET Smart Security, version of virus signature database 3152 (20080602) __ The message was checked by ESET Smart Security. http://www.eset.com ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Mon, 02 Jun 2008, Szakáts Viktor wrote: Hi Viktor, > One thing I forgot: To do this we'd need a switch > which would toggle the parenthesised expression > optimization only. OK, I can add it. > BTW, for me it's unclear by looking at the 'harbour /k?' > help, which options are enabled by default, and what > is the relation between them. It's unclear whether > '-kh' actually means all, or a selection of options > turned on, or something else. I've just updated usage message for -k? so it shows really set flags. You can even test the behavior of different switches using: harbour [some -k switches] -k? In general -kc clears all switches and disables all extensions which have RT interactions so it does not disable jump optimization (-kJ). As I can see it disable macro substitution (-kM) and this is bug which should be fixed. I'll do taht ASAP. > Plus, rather than saying 'lowercase/uppercase significant' > it would be more intuitive to just use lowercase > for 'J' and 'M', and make casing not to matter, like > for the rest of Harbour switches. I can make this, but > I wonder if there was any special reason doing it like > this? Probably Ryszard should answer for this. Now upper letters are used to disable some features. In the future we may need more combinations so maybe it's good idea to keep it case sensitive. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Mon, 02 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
> It's not possible to make a perfect decision here,
> unless investing extreme energy (like those flags)
> to keep bug compatibility, not to mention what an
> ugly inconsistency this is. My personal opinion in this
> case is to fix this Clipper bug in Harbour, and make it
> available using a switch for those few ppl who are relying
> on them and haven't yet corrected their code. I suspect
> there is not too many such ppl, and even most of this
> code is probably macro compiled.
I do not like Clipper behavior. For me it's a bug which may
confuse users, f.e. try this code with Clipper:
? CHR( 256 ) == CHR( 256 ), CHR( 256 ) == CHR( ( 256 ) )
? "" $ "", "" $ (""), ("") $ ""
? AT( "", "" ), AT( ( "" ), "" ), AT( "", ( "" ) )
> Question: Do we do all these optimization for macro
> code too, and do we have a way to disable it? Yes and
> yes is the answer AFAIK, so IMO we're covered.
Clipper does not make any optimizations for macro compiled
code so it gives correct results executing RT functions or
evaluating PCODE. We are making the optimizations but for
macro compiler Harbour calculates correct results so there
is not problem here.
> I'd plug these just to not forget about them, but these
> will need new pcodes, so it's a slightly different story:
> - HB_P_PUSHNIL + HB_P_RETVALUE would become: HB_P_RETNIL
> - HB_P_FALSE + HB_P_RETVALUE would become: HB_P_RETFALSE
> - HB_P_TRUE + HB_P_RETVALUE would become: HB_P_RETTRUE
> - SUBSTR(s,n,1) -> HB_P_SUBSTR1 (or whatever name)
> - ASC(SUBSTR(s,n,1)) -> HB_P_SUBSTR1ASC (or whatever name)
These I'll add after 1.0. Now I do not want to touch PCODE table
as long as we will not find some serious bug which will force
such operation.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] A question about hb_strRemEscSeq ()
It is possible that I lost but .- 2006-03-09 16:30 UTC+0100 Ryszard Glab ... * source/common/hbstr.c * source/rtl/strings.c * added hb_strRemEscSeq() function that removes C-like Esc sequences (\n \t \r \b currently) On the source/rtl/strings.c is not and on the source/common/hbstr.c, Do not need an HB_EXPORT? best regards Xavi ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek,
It's not possible to make a perfect decision here,
unless investing extreme energy (like those flags)
to keep bug compatibility, not to mention what an
ugly inconsistency this is. My personal opinion in this
case is to fix this Clipper bug in Harbour, and make it
available using a switch for those few ppl who are relying
on them and haven't yet corrected their code. I suspect
there is not too many such ppl, and even most of this
code is probably macro compiled.
I do not like Clipper behavior. For me it's a bug which may
confuse users, f.e. try this code with Clipper:
? CHR( 256 ) == CHR( 256 ), CHR( 256 ) == CHR( ( 256 ) )
? "" $ "", "" $ (""), ("") $ ""
? AT( "", "" ), AT( ( "" ), "" ), AT( "", ( "" ) )
We agree. I personally don't need this bug at all.
If you ask me we can just fix it and leave it at that.
Question: Do we do all these optimization for macro
code too, and do we have a way to disable it? Yes and
yes is the answer AFAIK, so IMO we're covered.
Clipper does not make any optimizations for macro compiled
code so it gives correct results executing RT functions or
evaluating PCODE. We are making the optimizations but for
macro compiler Harbour calculates correct results so there
is not problem here.
Even better. So I expect not too many ppl having
Chr( 1024 ) and "" $ "string" in real life code, since
the expressions are pointless, they are side cases
(invalid or close to invalid input) by themselves,
someone using such expressions with _full literals_
is even more pointless. So besides inspecting these
in a lab, like some strange viruses, they serve no
purpose, and I don't expect finding them in too much
real world code.
[ NOTE: Clipper '87 had these right, and I bet
- but I cannot try right now - the rest of Clipper
compiler has this right too. ]
I'd plug these just to not forget about them, but these
will need new pcodes, so it's a slightly different story:
- HB_P_PUSHNIL + HB_P_RETVALUE would become: HB_P_RETNIL
- HB_P_FALSE + HB_P_RETVALUE would become: HB_P_RETFALSE
- HB_P_TRUE + HB_P_RETVALUE would become: HB_P_RETTRUE
- SUBSTR(s,n,1) -> HB_P_SUBSTR1 (or whatever name)
- ASC(SUBSTR(s,n,1)) -> HB_P_SUBSTR1ASC (or whatever name)
These I'll add after 1.0. Now I do not want to touch PCODE table
as long as we will not find some serious bug which will force
such operation.
Absolutely fine.
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 20:16 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-06-02 20:16 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * source/common/hbstr.c ! HB_EXPORT added to hb_strRemEscSeq(). Thanks Javier. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Show symbol of the square root in console application
On Mon, 02 Jun 2008, Guillermo Varona Silupú wrote: > Any suggestions/tip for this? > >I have a small console application in which I want to show the symbol > >of the square root, but the screen shows me at number 1 as superscript. > >What should I set to display the symbol of the square root? > >Env.: WinXP SP2 + Harbour + MinGW It depends on used GT and font. What GT driver do you use? best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
-DHB_FM_STATISTICS_OFF Valid. -DHB_GUI ? Still exists. I think we should somehow remove this (meaning: replace with some superior solution) in the future. Since this is yet another thing to remember at build-time and yet another thing to badly interact with a multi GT app. Actually something like this already in the code (hvm.c), and IMO should be uncommented. -DHB_NO_PROFILER Valid. -DHB_NO_TRACE Not existing anymore. Tracing disabled by default. Enable it with HB_TR_LEVEL_* macros (see include/hbtrace.h) -DHB_WIN32_IO Still existing, but this is the default, so there's no reason to mess with it on user level. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 19:55 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Przemek, 2008-06-02 19:55 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbexprop.h * harbour/include/hbexprb.c * harbour/source/common/expropt2.c + added compile time INT( ) optimization * harbour/source/compiler/hbusage.c * updated -k? description to show "(default)" for really set flags Do you have anything against making -kM and -kJ (and the rest of switches) to work in a case-insensitive fashion? I can only think of the lesser variations this would us, but there would be something seriously wrong with Harbour if we'd be needing more than 25 such switch in the future. Also, is -kh equivalent to -kix ? Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Compile defines
Which of the following symbols are still useful/mandatory? -DHB_FM_STATISTICS_OFF -DHB_GUI -DHB_NO_PROFILER -DHB_NO_TRACE -DHB_WIN32_IO Thank you in advance. 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 ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
On Mon, 02 Jun 2008, Enrico Maria Giordano wrote: > Which of the following symbols are still useful/mandatory? > -DHB_FM_STATISTICS_OFF It's still functional. Default is HB_FM_STATISTICS > -DHB_GUI It disables inkey polling in main HVM loop. In normal programs it means that K_ALT_C and K_ALT_D will not work. It gives some small speed improvement. > -DHB_NO_PROFILER It's default. If you want to use profiler then you have to recompile HVM with -DHB_USE_PROFILER > -DHB_NO_TRACE It disables the possibility of function call tracing which can be enabled in default builds by: __TRACEPRGCALLS( [ ] ) -> It gives some small speed improvement. There is also HB_NO_DEBUG macro which disables debugger also giving some small speed improvement. > -DHB_WIN32_IO It's default for MS-Windows builds. Using Win32 IO API can be disabled by HB_WIN32_IO_OFF. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Plus, rather than saying 'lowercase/uppercase significant' it would be more intuitive to just use lowercase for 'J' and 'M', and make casing not to matter, like for the rest of Harbour switches. I can make this, but I wonder if there was any special reason doing it like this? Probably Ryszard should answer for this. Now upper letters are used to disable some features. In the future we may need more combinations so maybe it's good idea to keep it case sensitive. Well, I really hope so we won't need that many such language modifiers. Unless we want to kill the language that is. The turn off vs on would make sense, but I think it's enough to emphasis that in the description. Maybe Ryszard is here to comment. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 20:11 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-06-02 20:11 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/source/compiler/ppcomp.c * harbour/source/compiler/cmdcheck.c ! do not disable macrotext substitution for -kc best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
-DHB_GUI It disables inkey polling in main HVM loop. In normal programs it means that K_ALT_C and K_ALT_D will not work. It gives some small speed improvement. What do you think of making this a runtime option? (a Set()) -DHB_NO_TRACE It disables the possibility of function call tracing which can be enabled in default builds by: __TRACEPRGCALLS( [ ] ) -> It gives some small speed improvement. There is also HB_NO_DEBUG macro which disables debugger also giving some small speed improvement. Okay, so it does in fact exist, but does something completely different :) Since we already have a TRACE functionality on the C level which has nothing to do with this, I'd like to rename this to HB_NO_TRACEPRG. Or rather, shouldn't we tie this functionality to PROFILER? Opinions? For HB_NO_DEBUG we're talking about maybe 4-6 CPU instructions per Harbour function call. Do we really need this? Is this measurable? Brgds Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
Hi Viktor, -DHB_NO_PROFILER Valid. I cannot find any docs on the purpose of HB_NO_PROFILER - Can you please offer a brief explanation of what it is used for? TIA. Randy. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
-Messaggio Originale- Da: "Przemyslaw Czerpak" <[EMAIL PROTECTED]> A: "Harbour Project Main Developer List." Data invio: lunedi 2 giugno 2008 20.44 Oggetto: Re: [Harbour] Compile defines Thank you. 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 ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
-Messaggio Originale- Da: "Szakáts Viktor" <[EMAIL PROTECTED]> A: "Harbour Project Main Developer List." Data invio: lunedì 2 giugno 2008 20.34 Oggetto: Re: [Harbour] Compile defines Thank you. 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 ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
It disables the possibility of function call tracing which can be enabled in default builds by: __TRACEPRGCALLS( [ ] ) -> It gives some small speed improvement. There is also HB_NO_DEBUG macro which disables debugger also giving some small speed improvement. Okay, so it does in fact exist, but does something completely different :) Since we already have a TRACE functionality on the C level which has nothing to do with this, I'd like to rename this to HB_NO_TRACEPRG. Or rather, shouldn't we tie this functionality to PROFILER? Opinions? Inspecting it a little more, I think we should just use another HB_TRACE level for these messages, and leave the full control to the HB_TRACE setting, rather having another control layer above. Harbour uses DEBUG level for most messages, rarely some INFOs, so I think we should simply make those PRG trace calls to the INFO level. The .prg level switch can be guarded with #if HB_TR_LEVEL >= HB_TR_INFO so the check won't cause any runtime overhead if someone has built Harbour with higher HB_TRACE level. Opinions? Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 21:16 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-06-02 21:16 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * source/vm/hvm.c % Minor opt to __SETPROFILE(), __TRACEPRGCALLS() ! __SETPROFILE() to only set the value if a parameter was passed. This way it's possible to read the value without destroying it. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Warning on unused codeblock parameters
Please look at the following sample:
FUNCTION MAIN()
LOCAL bTest := { | Param | MyFunc() }
RETURN NIL
STATIC FUNCTION MYFUNC()
RETURN NIL
The compiler shows this warning if /w2 or /w3 are used:
Warning W0004 Codeblock parameter: 'PARAM' declared but not used in
function: 'MAIN'
Is it expected? I think it is common to not reference all the codeblock
parameters.
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
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Warning on unused codeblock parameters
On Mon, 02 Jun 2008, Enrico Maria Giordano wrote:
Hi Enrico,
> Please look at the following sample:
> FUNCTION MAIN()
>LOCAL bTest := { | Param | MyFunc() }
>RETURN NIL
> STATIC FUNCTION MYFUNC()
>RETURN NIL
> The compiler shows this warning if /w2 or /w3 are used:
> Warning W0004 Codeblock parameter: 'PARAM' declared but not used in
> function: 'MAIN'
> Is it expected?
Yes, it's expected.
HB_SYMBOL_UNUSED( Param )
disables the warning without any RT overhead.
> I think it is common to not reference all the codeblock parameters.
Probably yes though in some cases it may be usable and will help
to locate wrong code. To make all people happy we will have to add
compiler switch to disable this warning for codeblocks only, f.e.:
-kB turn off unused codeblock parameter warnings
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
On Mon, 02 Jun 2008, Szakáts Viktor wrote: Hi Viktor, > >>-DHB_GUI > >It disables inkey polling in main HVM loop. > >In normal programs it means that K_ALT_C and K_ALT_D will > >not work. It gives some small speed improvement. > What do you think of making this a runtime option? > (a Set()) The idea of using this macro was eliminating all possible overhead from main HVM loop. Using and RT switch like new set() does not make it. Anyhow current code can/should be updated. See the note about hb_set.HB_SET_KEYPOLL I left in main HVM loop few years ago. > For HB_NO_DEBUG we're talking about maybe 4-6 CPU instructions > per Harbour function call. Do we really need this? Is this > measurable? Just like for most of others. Probably only HB_GUI is HB_NO_PROFILER are important because pending code is executed in each HVM loop (for each PCODE). I'll make speed test for HB_GUI to check current difference. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Warning on unused codeblock parameters
Please look at the following sample:
FUNCTION MAIN()
LOCAL bTest := { | Param | MyFunc() }
RETURN NIL
STATIC FUNCTION MYFUNC()
RETURN NIL
The compiler shows this warning if /w2 or /w3 are used:
Warning W0004 Codeblock parameter: 'PARAM' declared but not used in
function: 'MAIN'
Is it expected?
Yes, it's expected.
HB_SYMBOL_UNUSED( Param )
disables the warning without any RT overhead.
I think it is common to not reference all the codeblock parameters.
Probably yes though in some cases it may be usable and will help
to locate wrong code. To make all people happy we will have to add
compiler switch to disable this warning for codeblocks only, f.e.:
-kB turn off unused codeblock parameter warnings
We may, but as the one having went through almost all
the Harbour + contrib code (and own app code) to fix these,
I can tell that in most cases the extra parameters were
simply sloppy coding. The most widespread one is:
AEval( a, {|x, y| whatever(x) } ) kind of code, where
y is simply superfluous as it's not used in most such
calls, so why polluting the source with it?
In my local reference codebase, which is roughly 30MB
of Clipper code, I had to add _only one_ SYMBOL_UNUSED
to a codeblock, and even in this case (which is a
TBColumn():colorBlock value BTW), the parameter could
well be dropped, but I left it there as a sort of
self-documentation.
In any case, this should be a -w modifier option, not
a -k one.
Not for this specific case, but otherwise I think
it would be very helpful to add _more_ warnings to
spot sloppy coding, like usage of '=' in assignments,
if() inline, old-style comments (*) and there are
many others obsolete construct with superior alternatives
in the language. This is a nice way to push the language
ahead, leave old ballast and let space for new stuff
and better quality code in general. (while not breaking
compatibility)
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
On Mon, 02 Jun 2008, Szakáts Viktor wrote: > >Since we already have a TRACE functionality on the > >C level which has nothing to do with this, I'd like > >to rename this to HB_NO_TRACEPRG. Or rather, shouldn't > >we tie this functionality to PROFILER? Opinions? HB_NO_TRACEPRG is OK for me though I'd rather suggest to disable function call tracing and add HB_TRACEPRG > Inspecting it a little more, I think we > should just use another HB_TRACE level > for these messages, and leave the full > control to the HB_TRACE setting, rather > having another control layer above. > Harbour uses DEBUG level for most messages, > rarely some INFOs, so I think we should > simply make those PRG trace calls to the > INFO level. > The .prg level switch can be guarded > with #if HB_TR_LEVEL >= HB_TR_INFO so > the check won't cause any runtime overhead > if someone has built Harbour with higher > HB_TRACE level. > Opinions? 90% users on this list do not know what HB_TR_LEVEL does and how to use it. The above modification will mean for them that we are removing this feature at all. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Show symbol of the square root in console application
Przemyslaw Czerpak escribió: On Mon, 02 Jun 2008, Guillermo Varona Silupú wrote: Any suggestions/tip for this? I have a small console application in which I want to show the symbol of the square root, but the screen shows me at number 1 as superscript. What should I set to display the symbol of the square root? Env.: WinXP SP2 + Harbour + MinGW It depends on used GT and font. What GT driver do you use? Using the GT and font default. I do not set any GT and font. How do I know that GT and font that I am using? TIA Best Regards GVS ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Warning on unused codeblock parameters
-Messaggio Originale- Da: "Przemyslaw Czerpak" <[EMAIL PROTECTED]> A: "Harbour Project Main Developer List." Data invio: lunedi 2 giugno 2008 21.46 Oggetto: Re: [Harbour] Warning on unused codeblock parameters To make all people happy we will have to add compiler switch to disable this warning for codeblocks only, f.e.: -kB turn off unused codeblock parameter warnings It would be great. 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 ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Warning on unused codeblock parameters
-Messaggio Originale-
Da: "Szakáts Viktor" <[EMAIL PROTECTED]>
A: "Harbour Project Main Developer List."
Data invio: lunedì 2 giugno 2008 22.04
Oggetto: Re: [Harbour] Warning on unused codeblock parameters
We may, but as the one having went through almost all
the Harbour + contrib code (and own app code) to fix these,
I can tell that in most cases the extra parameters were
simply sloppy coding. The most widespread one is:
AEval( a, {|x, y| whatever(x) } ) kind of code, where
y is simply superfluous as it's not used in most such
calls, so why polluting the source with it?
Please look at the following FWH sample:
#include "Fivewin.ch"
FUNCTION MAIN()
LOCAL oDlg
LOCAL cVar := SPACE( 30 )
DEFINE DIALOG oDlg
@ 1, 1 GET cVar;
ON CHANGE MYFUNC()
ACTIVATE DIALOG oDlg;
CENTER
RETURN NIL
STATIC FUNCTION MYFUNC()
RETURN NIL
I get these warnings that I can't easily fix:
Warning W0004 Codeblock parameter: 'NKEY' declared but not used in
function: 'MAIN'
Warning W0004 Codeblock parameter: 'NFLAGS' declared but not used in
function: 'MAIN'
Warning W0004 Codeblock parameter: 'SELF' declared but not used in
function: 'MAIN'
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
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
What do you think of making this a runtime option? (a Set()) The idea of using this macro was eliminating all possible overhead from main HVM loop. Using and RT switch like new set() does not make it. Anyhow current code can/should be updated. See the note about hb_set.HB_SET_KEYPOLL I left in main HVM loop few years ago. That's why I was asking. But would one flag comparison be such an overhead there? For HB_NO_DEBUG we're talking about maybe 4-6 CPU instructions per Harbour function call. Do we really need this? Is this measurable? Just like for most of others. Probably only HB_GUI is HB_NO_PROFILER are important because pending code is executed in each HVM loop (for each PCODE). I'll make speed test for HB_GUI to check current difference. Thanks Przemek. Also HB_NO_DEBUG... I saw these were added (along with NO_TRACE) on request last year but IMO there are better ways to squeeze more performance out of Harbour in general. If there is someone who so badly needs more raw VM performance there are most probably a dozen more stuff which could be commented out of Harbour VM/RTL. These customization can be made locally (not on repo) unless they aren't features which give benefit for 'lots' of users IMO. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Show symbol of the square root in console application
On Mon, 02 Jun 2008, Guillermo Varona Silupú wrote: Hi Guillermo, > >It depends on used GT and font. > >What GT driver do you use? > Using the GT and font default. I do not set any GT and font. > How do I know that GT and font that I am using? to check GT driver you can run you program with //info switch, f.e: your_app //info or add to your code: ? hb_gtVersion() the default GT for Windows is GTWIN. The font used by GTWIN is out of Harbour control. You can try to set it for your console window by setting/changing its properties and/or installing font with glyphs you want to use. Maybe some windows users will help you and describe details. The default font and encoding used by console window depends on windows version and national setting. It's not Harbour problem. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Show symbol of the square root in console application
Przemyslaw Czerpak escribió: On Mon, 02 Jun 2008, Guillermo Varona Silupú wrote: Hi Guillermo, It depends on used GT and font. What GT driver do you use? Using the GT and font default. I do not set any GT and font. How do I know that GT and font that I am using? to check GT driver you can run you program with //info switch, f.e: your_app //info or add to your code: ? hb_gtVersion() Ok. Thank you Przmek. This is the GT used: D:\Tst_CT>tst_ct //info Harbour Terminal: Win32 buffered console Harbour devel build 1.1-1 Intl. (Rev. 8358) Windows XP 5.1.2600 Service Pack 2 DS avail=19KB OS avail=2064124KB EMM avail=0KB MemStat:On the default GT for Windows is GTWIN. The font used by GTWIN is out of Harbour control. You can try to set it for your console window by setting/changing its properties and/or installing font with glyphs you want to use. Maybe some windows users will help you and describe details. The default font and encoding used by console window depends on windows version and national setting. It's not Harbour problem. Again, Thank you Przmek, it became clear to me. Best Regars GVS ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Warning on unused codeblock parameters
Well, yes, unfortunately these should be fixed in
FiveWin.ch.
Okay for me. We need to find out the layout of the
granular -w switch.
I'd propose:
-w[+/-] where alpha is single (case-sensitive)
alphabetic letter.
For this one, case sensitivity makes sense, as we can
end up with quote some options. (I'll also leave -k in
this regard).
Also -w? could bring up a subscreen with the possible
options, like -k.
Brgds,
Viktor
On 2008.06.02., at 22:31, Enrico Maria Giordano wrote:
-Messaggio Originale- Da: "Szakáts Viktor" <[EMAIL PROTECTED]
>
A: "Harbour Project Main Developer List." <[EMAIL PROTECTED]
project.org>
Data invio: lunedì 2 giugno 2008 22.04
Oggetto: Re: [Harbour] Warning on unused codeblock parameters
We may, but as the one having went through almost all
the Harbour + contrib code (and own app code) to fix these,
I can tell that in most cases the extra parameters were
simply sloppy coding. The most widespread one is:
AEval( a, {|x, y| whatever(x) } ) kind of code, where
y is simply superfluous as it's not used in most such
calls, so why polluting the source with it?
Please look at the following FWH sample:
#include "Fivewin.ch"
FUNCTION MAIN()
LOCAL oDlg
LOCAL cVar := SPACE( 30 )
DEFINE DIALOG oDlg
@ 1, 1 GET cVar;
ON CHANGE MYFUNC()
ACTIVATE DIALOG oDlg;
CENTER
RETURN NIL
STATIC FUNCTION MYFUNC()
RETURN NIL
I get these warnings that I can't easily fix:
Warning W0004 Codeblock parameter: 'NKEY' declared but not used in
function: 'MAIN'
Warning W0004 Codeblock parameter: 'NFLAGS' declared but not used
in function: 'MAIN'
Warning W0004 Codeblock parameter: 'SELF' declared but not used in
function: 'MAIN'
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
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
On Mon, 02 Jun 2008, Szakáts Viktor wrote: Hi Viktor, > >Just like for most of others. Probably only HB_GUI is HB_NO_PROFILER > >are important because pending code is executed in each HVM loop (for > >each PCODE). I'll make speed test for HB_GUI to check current > >difference. #define N_LOOP 1 proc main() local t, i t:=secondsCPU() for i:=1 to N_LOOP next ? secondsCPU()-t return In this code the speed difference is about 4.3% (12.77 vs. 12.24). Not too much but noticeable. Of course it's not realistic example and in normal code which calls functions the difference will be much smaller anyhow it illustrates the cost of single if() in main HVM loop. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-02 23:33 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-06-02 23:33 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * contrib/make_b32_all.bat * contrib/make_gcc_all.sh * contrib/make_vc_all.bat + contrib/hbsqlit2 + contrib/hbsqlit2/Makefile + contrib/hbsqlit2/make_b32.bat + contrib/hbsqlit2/make_vc.bat + contrib/hbsqlit2/make_gcc.sh + contrib/hbsqlit2/common.mak + contrib/hbsqlit2/hbsqlit2.c + contrib/hbsqlit2/hbsqlit2.ch + contrib/hbsqlit2/LICENSE.txt + contrib/hbsqlit2/TODO.txt + contrib/hbsqlit2/readme.txt + contrib/hbsqlit2/attach.c + contrib/hbsqlit2/auth.c + contrib/hbsqlit2/btree.c + contrib/hbsqlit2/btree.h + contrib/hbsqlit2/btree_rb.c + contrib/hbsqlit2/build.c + contrib/hbsqlit2/config.h + contrib/hbsqlit2/copy.c + contrib/hbsqlit2/date.c + contrib/hbsqlit2/delete.c + contrib/hbsqlit2/encode.c + contrib/hbsqlit2/expr.c + contrib/hbsqlit2/func.c + contrib/hbsqlit2/hash.c + contrib/hbsqlit2/hash.h + contrib/hbsqlit2/insert.c + contrib/hbsqlit2/main.c + contrib/hbsqlit2/opcodes.c + contrib/hbsqlit2/opcodes.h + contrib/hbsqlit2/os.c + contrib/hbsqlit2/os.h + contrib/hbsqlit2/pager.c + contrib/hbsqlit2/pager.h + contrib/hbsqlit2/parse.c + contrib/hbsqlit2/parse.h + contrib/hbsqlit2/pragma.c + contrib/hbsqlit2/printf.c + contrib/hbsqlit2/random.c + contrib/hbsqlit2/select.c + contrib/hbsqlit2/sqlite.h + contrib/hbsqlit2/sqliteInt.h + contrib/hbsqlit2/table.c + contrib/hbsqlit2/tokenize.c + contrib/hbsqlit2/trigger.c + contrib/hbsqlit2/update.c + contrib/hbsqlit2/util.c + contrib/hbsqlit2/vacuum.c + contrib/hbsqlit2/vdbe.c + contrib/hbsqlit2/vdbe.h + contrib/hbsqlit2/vdbeaux.c + contrib/hbsqlit2/vdbeInt.h + contrib/hbsqlit2/where.c + contrib/hbsqlit2/tests/bld_b32.bat + contrib/hbsqlit2/tests/bld_vc.bat + contrib/hbsqlit2/tests/example.db + contrib/hbsqlit2/tests/hbsqlite.prg + Added hbsqlit2 SQLite 2.x interface library. With kind permission from the author: Alejandro de Gárate + Some renames were done here too to better fit into the contrib structure. + Added std make files. + Added to 'all' make files. + Added foreign SQLite 2.8.16 (final 2.x version) source code to the repository. Compiles with an okay amount of warnings under BCC but doesn't compile in C++ mode in MSVC (due to missing casts). ; NOTE: I've added this because this is the original SQLite Harbour interface, clean and working implementation, and SQLite 2 is incompatible with 3, and some may need to access existing 2.x databases from Harbour. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Compile defines
Hi Przemek, Just like for most of others. Probably only HB_GUI is HB_NO_PROFILER are important because pending code is executed in each HVM loop (for each PCODE). I'll make speed test for HB_GUI to check current difference. #define N_LOOP 1 proc main() local t, i t:=secondsCPU() for i:=1 to N_LOOP next ? secondsCPU()-t return In this code the speed difference is about 4.3% (12.77 vs. 12.24). Not too much but noticeable. Of course it's not realistic example and in normal code which calls functions the difference will be much smaller anyhow it illustrates the cost of single if() in main HVM loop. Hm, even less difference for HB_NO_DEBUG, below 2%. (this value is below normal OS background processing) Dunno, we may leave both as non-documented modifiers, but this kind of optimization is like if you'd drop out the passenger seat from your car to get a slightly better 0-100 run. Some ppl even turn off headlights with the same goal :) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-06-03 01:31 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
2008-06-03 01:31 UTC+0100 Viktor Szakats (harbour.01 syenar hu) * source/vm/extend.c ! hb_storclen_buffer() fixed to free the passed buffer in case it couldn't be stored. This situation was easy to miss and difficult to detect for the caller, and it might cause leaks. * contrib/hbw32/Makefile * contrib/hbw32/common.mak + contrib/hbw32/hbw32.ch + contrib/hbw32/w32_reg.prg + contrib/hbw32/w32_regc.c + contrib/hbw32/tests/testreg.prg + Added Windows registry handling stuff. Work of Peter Rees <[EMAIL PROTECTED]> / xhb. * Code cleaned, formatted, optimized a bit. + Added an even simpler interface: w32_regRead( ) -> xValue w32_regWrite( , ) -> where is: "HKCU\key[\subkeys]\entry" -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour & Unicode
We are ASIA country, We need unicode support, Who can help us? ps.At M$ is not Linux. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Release Time
On Monday 02 June 2008 01:05:15 pm Massimo Belgrano wrote: > What about new harbour's web site and fidonet group? What about it? I thought fidonet died about 15 years ago... -- Waiting for sunspots. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 20:16 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
Thanks Viktor,
Why not complete?
In order to send out to full printers and terminals may be useful.
HB_EXPORT char * hb_strRemEscSeq( char *str, ULONG *pLen )
{
ULONG ul = *pLen, ulStripped = 0;
char *ptr, *dst, ch;
ptr = dst = str;
while( ul )
{
if( *ptr == '\\' )
break;
++ptr; ++dst;
--ul;
}
while( ul-- )
{
ch = *ptr++;
if( ch == '\\' )
{
++ulStripped;
if( ul )
{
ul--;
ch = *ptr++;
switch( ch )
{
case 'a': ch = '\a'; break;
case 'b':
ch = '\b';
break;
case 'f': ch = '\f'; break;
case 'n':
ch = '\n';
break;
case 'r':
ch = '\r';
break;
case 't':
ch = '\t';
break;
case 'v': ch = '\v'; break;
case '0':
case '1':
case '2':
case '3':
case '4':
case '5':
case '6':
case '7':
ch -= '0';
if( ul && *ptr >= '0' && *ptr <= '7' )
{
ch = ( ch << 3 ) | ( *ptr++ - '0' );
++ulStripped;
if( --ul && *ptr >= '0' && *ptr <= '7' )
{
ch = ( ch << 3 ) | ( *ptr++ - '0' );
++ulStripped;
--ul;
}
}
break;
case 'x':
ch = 0;
while( ul )
{
if( *ptr >= '0' && *ptr <= '9' )
ch = ( ch << 4 ) | ( *ptr++ - '0' );
else if( *ptr >= 'A' && *ptr <= 'F' )
ch = ( ch << 4 ) | ( *ptr++ - 'A' + 10 );
else if( *ptr >= 'a' && *ptr <= 'f' )
ch = ( ch << 4 ) | ( *ptr++ - 'a' + 10 );
else
break;
++ulStripped;
--ul;
}
break;
default: /* case '\\': // Also any ch */
break;
}
}
else
break;
}
*dst++ = ch;
}
if( ulStripped )
{
*dst = '\0';
*pLen -= ulStripped;
}
return str;
}
best regards
Xavi
Szakáts Viktor escribió:
2008-06-02 20:16 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
* source/common/hbstr.c
! HB_EXPORT added to hb_strRemEscSeq(). Thanks Javier.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] GLOBAL statement
Hi Guys, Is xHarbour's GLOBAL and GLOBAL EXTERNAL statements supported in Harbour ? Thanks, Ed -- View this message in context: http://www.nabble.com/GLOBAL-statement-tp17615771p17615771.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Show symbol of the square root in console application
Guillermo, try this code: ---zz2.prg--- proc test ? chr(251) + "4 = 2" return - bld_b32 zz2 /w/a/n zz2 It works on my NT 4.0 and Win2K both full screen and windowed. My systems are Hebrew enabled, on your code page you might not have CHR(251) as square root. Chen. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-06-02 20:16 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
Hi Javier,
> Why not complete?
I can only guess: No one has written such
a wrapper, yet.
IMO though, besides the conversion itself,
sending out the stripped string to any output
device is not the job of such wrapper.
You can do the latter with existing functions.
Brgds,
Viktor
On 2008.06.03., at 4:14, Javier wrote:
Thanks Viktor,
Why not complete?
In order to send out to full printers and terminals may be useful.
HB_EXPORT char * hb_strRemEscSeq( char *str, ULONG *pLen )
{
ULONG ul = *pLen, ulStripped = 0;
char *ptr, *dst, ch;
ptr = dst = str;
while( ul )
{
if( *ptr == '\\' )
break;
++ptr; ++dst;
--ul;
}
while( ul-- )
{
ch = *ptr++;
if( ch == '\\' )
{
++ulStripped;
if( ul )
{
ul--;
ch = *ptr++;
switch( ch )
{
case 'a': ch = '\a'; break;
case 'b':
ch = '\b';
break;
case 'f': ch = '\f'; break;
case 'n':
ch = '\n';
break;
case 'r':
ch = '\r';
break;
case 't':
ch = '\t';
break;
case 'v': ch = '\v'; break;
case '0':
case '1':
case '2':
case '3':
case '4':
case '5':
case '6':
case '7':
ch -= '0';
if( ul && *ptr >= '0' && *ptr <= '7' )
{
ch = ( ch << 3 ) | ( *ptr++ - '0' );
++ulStripped;
if( --ul && *ptr >= '0' && *ptr <= '7' )
{
ch = ( ch << 3 ) | ( *ptr++ - '0' );
++ulStripped;
--ul;
}
}
break;
case 'x':
ch = 0;
while( ul )
{
if( *ptr >= '0' && *ptr <= '9' )
ch = ( ch << 4 ) | ( *ptr++ - '0' );
else if( *ptr >= 'A' && *ptr <= 'F' )
ch = ( ch << 4 ) | ( *ptr++ - 'A' + 10 );
else if( *ptr >= 'a' && *ptr <= 'f' )
ch = ( ch << 4 ) | ( *ptr++ - 'a' + 10 );
else
break;
++ulStripped;
--ul;
}
break;
default: /* case '\\': // Also any ch */
break;
}
}
else
break;
}
*dst++ = ch;
}
if( ulStripped )
{
*dst = '\0';
*pLen -= ulStripped;
}
return str;
}
best regards
Xavi
Szakáts Viktor escribió:
2008-06-02 20:16 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
* source/common/hbstr.c
! HB_EXPORT added to hb_strRemEscSeq(). Thanks Javier.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
