Re: [Harbour] How to build and use pCode DLL with hbmk2
On Wed, 10 Feb 2010, 2D Info - Leandro Damasio wrote: Hi, But in the .prg code used for EXE file when you are calling functions which do not exist in it and are loaded dynamically then all such functions should be declared as DYNAMIC otherwise you will have link time error (function does not exist). In my case of use the functions in the DLL are called by the EXE via macro evaluation (because I don't have their names until I load the DLL) so it is not possible/needed declare them as DYNAMIC in the EXE, I guess. Is it going to work anyway? It will work but I do not understand how it's possible to call function by macro knowing it's name when macro value is created but in other context you do not know this name. Your above description does not make any sense or you simply forgot to say about some important conditions. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: USE error ?
Przemek: Something has changed for this case since Aug 2007 ? I created new code for MT mode which also can use BSD or POSIX locks for deny flags emulation so now it works between aliased work areas even in single process. This code were copied from Harbour repository to xHarbour CVS by: 2008-10-22 10:30 UTC+0100 Miguel Angel Marchuet miguelangel at marchuet.net even with my original ChangeLog notes but without even single word that these were my modifications :-( So this code is present in xHarbour. I haven't checked if it was ported correctly or not. Few times in last years my code from Harbour was copied without necessary updates to work correctly with xHarbour internal structures so you should ask about details xHarbour developers. [...] Code is present but I do not have time to test current xHarbour CVS locate the bugs and document them. The are bugs I reported four or more years ago to xHarbour devel list and never fixed though some of them are even registered at xHarbour bug track so I think it's waste of time. Thanks, with these explanations now is more clear: - In Linux nothing prevent two applications open file in EXCLUSIVE from each side - Harbour applications can emulate EXCLUSIVE mode if them are build with this feature - Maybe xHarbour have same feature if it was properly copied/implemented - So EXCLUSIVE may work between Harbour-xHarbour applications if work properly in xHarbour - hbnetio is an alternative in remote environment to properly manage EXCLUSIVE, in place of Samba I found this old subject due I was searching for locking-scheme to ensure proper implementation. Until now my conclusions are: - Two applications, one build with Harbour and other with xHarbour may have locking-corruption problems if each one is using a different locking scheme in same RDD type So we must to check which is default locking-scheme in each compiler or force same in both - Two applications, both build with Harbour may have locking-corruption problems if each one is using a different locking scheme in same RDD type So we must to check which is default locking-scheme in each build or force same in both builds - Two applications, one build with (x)Harbour and other with other compiler (Clipper, FoxPro, ... ) may have locking-corruption problems if each one is using a different locking scheme in same RDD type So we must to check which is default locking-scheme in each build or force same in both builds I was relying in default locking scheme in any build David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13842] trunk/harbour
Revision: 13842 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13842view=rev Author: vszakats Date: 2010-02-11 11:33:10 + (Thu, 11 Feb 2010) Log Message: --- 2010-02-11 12:32 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/direct.c * int - HB_SIZE * contrib/hbwin/wapi_wingdi.c ! Fixed return value of WAPI_SELECTOBJECT() * contrib/hbwin/tests/testdll.prg + Minor. * contrib/hbwin/win_dll.c ! Fixed typo in byref parameter handling. Thanks to Xavi for noticing it. * Deleted unused union members from win32 retval support, renamed the rest. * utils/hbmk2/hbmk2.prg + Added -3rd= option. This is always ignored by hbmk2 and it allows to store extra, non-hbmk2 information in hbmk2 make files. F.e.: -3rd=-hbide_friendlyname=MyProject Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/tests/testdll.prg trunk/harbour/contrib/hbwin/wapi_wingdi.c trunk/harbour/contrib/hbwin/win_dll.c trunk/harbour/src/rtl/direct.c trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13843] trunk/harbour
Revision: 13843 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13843view=rev Author: vszakats Date: 2010-02-11 11:37:58 + (Thu, 11 Feb 2010) Log Message: --- 2010-02-11 12:37 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/wapi_wingdi.c ! Fixed return value of WAPI_SELECTOBJECT() again. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/wapi_wingdi.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Przemek: .DBT and .FPT file confusion
Przemek: Any you want. DBT allows to store only strings and uses 512 bytes blocks. FPT allows to store also other data types (numbers, dates, arrays, ...) and user can set block size (default is 64 bytes) so it's more flexible and creates smaller files. It also contains garbage collector which allow to reuse freed regions. SMT is SIX3 format which have most of FPT features. All formats are recognized by Harbour. In fact it even recognize different implementations of FPT formats which can be controlled by: rddInfo( RDDI_MEMOVERSION, DB_MEMOEXT_* [, cRDD] ) Some weeks ago I posted a question based on tests: - ? SET( _SET_MFILEEXT ), SET( _SET_MFILEEXT ) ? SET( _SET_MBLOCKSIZE ), SET( _SET_MBLOCKSIZE ) ? SET( _SET_AUTORDER ), SET( _SET_AUTORDER ) ? SET( _SET_AUTOPEN ), SET( _SET_AUTOPEN ) ? DBINFO( DBI_MEMOBLOCKSIZE ), DBINFO( DBI_MEMOBLOCKSIZE ) e) Results with Clipper 5.3a, as expected (not create/add, just values and record pointer movement) SET( _SET_MFILEEXT ) SET( _SET_MBLOCKSIZE ) 64 SET( _SET_AUTORDER ) 0 SET( _SET_AUTOPEN ) .T. DBINFO( DBI_MEMOBLOCKSIZE ) 64 f) Results with Harbour NTFS: -- SET( _SET_MFILEEXT ) SET( _SET_MBLOCKSIZE ) 0 SET( _SET_AUTORDER ) 0 SET( _SET_AUTOPEN ) .T. DBINFO( DBI_MEMOBLOCKSIZE ) 64 -- g) Why Clipper and Harbour show different ? : SET( _SET_MBLOCKSIZE ) 64 SET( _SET_MBLOCKSIZE ) 0 It must be fixed ? - If some old (Clipper) application rely on SET( _SET_MBLOCKSIZE ) result, then will fail in Harbour behaviour David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi Xavi,
On 2010 Feb 11, at 05:20, Xavi wrote:
Hi Viktor,
You've introduced a new permanently set macro called HB_OS_WIN64_32,
redefined a Harbour type (which should be avoided by all means)
Is to work with win64 implementation in win32 with minimal changes.
If the system is win32, not be used HB_U64 used HB_U32 to compile only
win_dll.c
That can work, but it means we don't support int64/double
parameters and int64/double/float/char return values anymore.
Currently we do, so maybe it'd be good to take care of it.
We should also support both cdecl and stdcall versions.
You check what happens by looking at asm output for this source (gcc):
---
_stdcall int hello1( int a, int b ) { return 30; }
_stdcall long hello2( long a, long b ) { return 30; }
_stdcall short hello3( short a, short b ) { return 30; }
_stdcall unsigned char hello4( unsigned char a, unsigned char b ) { return 30; }
_stdcall double hello5( double a, double b ) { return 30; }
_stdcall long long hello6( long long a, long long b ) { return 30; }
_stdcall float hello7( float a, float b ) { return 30; }
_cdecl int hello1c( int a, int b ) { return 30; }
_cdecl long hello2c( long a, long b ) { return 30; }
_cdecl short hello3c( short a, short b ) { return 30; }
_cdecl unsigned char hello4c( unsigned char a, unsigned char b ) { return 30; }
_cdecl double hello5c( double a, double b ) { return 30; }
_cdecl long long hello6c( long long a, long long b ) { return 30; }
_cdecl float hello7c( float a, float b ) { return 30; }
void main( void )
{
hello1( 100, 200 ); hello1c( 100, 200 );
hello2( 100, 200 ); hello2c( 100, 200 );
hello3( 100, 200 ); hello3c( 100, 200 );
hello4( 100, 200 ); hello4c( 100, 200 );
hello5( 100, 200 ); hello5c( 100, 200 );
hello6( 100, 200 ); hello6c( 100, 200 );
}
---
and shifted parameter offset by one for reference types,
It's a bad typo in win64. Try testdll.prg with MinGW in Win32, use CC_FLAGS .-
-Wall -Wextra -march=i586 -mtune=pentiumpro -O3 -fomit-frame-pointer
Oh it's possible and thank you. I've committed the fix.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2: Harbour 13841
I made tests with * $Id: ChangeLog 13841 2010-02-11 03:26:15Z jarabal $ 2010-02-11 04:25 UTC+0100 Xavi (jarabal/at/gmail.com) and new os2gcc442 - I saw there are new libraries in Harbour - So os2gcc reach 32K limit again and harbourm.dll can not build Except for harbourm.dll build error, Harbour build entirely with 0 errors and lot of warnings, most of them of new library Below are summary with known/unknown status Default Harbour .exe files run fine (hbtest, hbrun, ...) David Macias ! Building Harbour 2.1.0dev from source - http://www.harbour-project.org ! MAKE: make 3.81 E:\OS2\CMD.EXE w ! HB_USER_CFLAGS: -DTCPV40HDRS -DHB_FM_STATISTICS_OFF ! HB_USER_LDFLAGS: -Le:\usr\lib\tcpipv4 ! HB_HOST_PLAT: os2 (x86) HB_SHELL: os2 ! HB_PLATFORM: os2 (x86) (autodetected) ! HB_COMPILER: gccomf ! Component: 'zlib' found in E:/harbour102/harbour/external/zlib (local) ! Component: 'pcre' found in E:/harbour102/harbour/external/pcre (local) ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. ! Component: 'gpm' not supported on os2 platform ! Component: 'slang' not found. Configure with HB_WITH_SLANG. ! Component: 'curses' not supported on os2 platform ! Component: 'x11' not found. Configure with HB_WITH_X11. ! Component: 'wattcp/watt-32' not supported on os2 platform ! HB_INSTALL_PREFIX automatically set to: E:\harbour102\harbour [known] ../../../sqlite3.c: In function 'sqlite3_os_init': ../../../sqlite3.c:21244: warning: initialization from incompatible pointer type [unknown] ../../../hpdfimap.c: In function 'ReadPngData_Interlaced': ../../../hpdfimap.c:113: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:118: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:119: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:129: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:138: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c: In function 'ReadPngData': ../../../hpdfimap.c:159: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c: In function 'ReadTransparentPaletteData': ../../../hpdfimap.c:186: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:192: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:210: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:211: warning: 'width' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:632) ../../../hpdfimap.c:212: warning: 'width' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:632) ../../../hpdfimap.c:215: warning: 'width' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:632) ../../../hpdfimap.c:222: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c: In function 'ReadTransparentPngData': ../../../hpdfimap.c:248: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:254: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:274: warning: 'width' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:632) ../../../hpdfimap.c:275: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:276: warning: 'width' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:632) ../../../hpdfimap.c:279: warning: 'width' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:632) ../../../hpdfimap.c:289: warning: 'width' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:632) ../../../hpdfimap.c:290: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c:291: warning: 'width' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:632) ../../../hpdfimap.c:294: warning: 'width' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:632) ../../../hpdfimap.c:309: warning: 'height' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:633) ../../../hpdfimap.c: In function 'LoadPngData': ../../../hpdfimap.c:451: warning: 'bit_depth' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:639) ../../../hpdfimap.c:461: warning: 'color_type' is deprecated (declared at E:/harbour102/harbour/external/libpng/png.h:640) ../../../hpdfimap.c:481: warning: 'width' is deprecated (declared at
Re: [Harbour] Re: USE error ?
On Thu, 11 Feb 2010, David Arturo Macias Corona wrote: Hi, Thanks, with these explanations now is more clear: - In Linux nothing prevent two applications open file in EXCLUSIVE from each side No. In Linux and other POSIX system there is no EXCLUSIVE mode at all. Only shared mode exists though some *nixes have kernel side support to emulated DOS DENY flags usually to implement some file servers for DOS/Windows machines. It's not standard functionality and we do not use them. - Harbour applications can emulate EXCLUSIVE mode if them are build with this feature It's enabled by default. - Maybe xHarbour have same feature if it was properly copied/implemented Probably yes but I haven't tested it. - So EXCLUSIVE may work between Harbour-xHarbour applications if work properly in xHarbour Yes but now there are some other problems in data sharing. We have fixed CP support so it's not possible to share data with xHarbour applications which uses incompatible CP implementation. It will cause index file corruption so it's necessary to precisely verify if both application uses the same binary collation order. The same CP in both applications may not be enough. - hbnetio is an alternative in remote environment to properly manage EXCLUSIVE, in place of Samba It's an alternative to properly manage all types of synchronization locks not only EXCLUSIVE mode when files are accessed remotely using SAMBA, NFS, MARS or any other file server. It's also an alternative for system or network redirector limitations like maximum file size, i.e. DOS applications using HBNETIO can work with 64bit length file IO API if server running HBNETIO supports it. I found this old subject due I was searching for locking-scheme to ensure proper implementation. Until now my conclusions are: - Two applications, one build with Harbour and other with xHarbour may have locking-corruption problems if each one is using a different locking scheme in same RDD type So we must to check which is default locking-scheme in each compiler or force same in both Yes. But it's also true between two Harbour applications. All of them have to use exactly the same locking schemes. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Przemek: .DBT and .FPT file confusion
On Thu, 11 Feb 2010, David Arturo Macias Corona wrote: Hi, g) Why Clipper and Harbour show different ? : SET( _SET_MBLOCKSIZE ) 64 SET( _SET_MBLOCKSIZE ) 0 It must be fixed ? 0 means use RDD default. 64 for FPT and 32 for SMT. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: Harbour 13841
Hi David, On 2010 Feb 11, at 12:58, David Arturo Macias Corona wrote: I made tests with * $Id: ChangeLog 13841 2010-02-11 03:26:15Z jarabal $ 2010-02-11 04:25 UTC+0100 Xavi (jarabal/at/gmail.com) and new os2gcc442 - I saw there are new libraries in Harbour - So os2gcc reach 32K limit again and harbourm.dll can not build :( I could be seen in advance. I can't give any solution, but I hope someone will. Except for harbourm.dll build error, Harbour build entirely with 0 errors and lot of warnings, most of them of new library The iTODO is obvious (should not be huge work for an OS/2 programmer), the rest is in 3rd party code. I'll suppress the libharu warnings. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13844] trunk/harbour
Revision: 13844 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13844view=rev Author: vszakats Date: 2010-02-11 12:12:51 + (Thu, 11 Feb 2010) Log Message: --- 2010-02-11 13:12 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * external/libhpdf/Makefile * Suppressing 'deprecated' warnings in libharu code until it gets updated for libpng 1.4. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/external/libhpdf/Makefile This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
But in the .prg code used for EXE file when you are calling
functions which do not exist in it and are loaded dynamically
then all such functions should be declared as DYNAMIC otherwise
you will have link time error (function does not exist).
In my case of use the functions in the DLL are called by the EXE via
macro evaluation (because I don't have their names until I load the
DLL) so it is not possible/needed declare them as DYNAMIC in the
EXE, I guess. Is it going to work anyway?
It will work but I do not understand how it's possible to call
function by macro knowing it's name when macro value is created
but in other context you do not know this name. Your above
description does not make any sense or you simply forgot to say
about some important conditions.
Hi Przemek
Below is some code to exemplify what I couldn't explain to you textually.
Maybe it helps.
Rgds
Leandro
**
function CarregarDLLs(cFolder)
**
local aFiles:=Directory(cFolder+\*.dll),aVersion
local ddd,hh
local cFunction,cID
for ddd = 1 to len(aFiles)
hh := LibLoad( cFolder + aFiles[ddd,1] )
cID := substr(afiles[ddd,1],4,2)
cFunction := __DLL__ + strtran(aFiles[ddd,1],.DLL,)
if !FunctionExists(cFunction) // if the dll doesn't have such function
we don't need it
LibFree(hh)
loop
endif
aVersion := (cFunction + '()')
oDLL := DLL2D():New(hh,aVersion)
oDLL :dFile := ListaArq[ddd,2]
oDLL :cFiletime := ListaArq[ddd,3]
oDLL :nFileLen := ListaArq[ddd,4]
LibFree(hh)
next
Return
////
////
////
////
CLASS DLL2D
CLASS VAR aAllDLL INIT {}
DATA cCode,cName,nVersion,cPrefix,cCompileTime,cFileTime INIT
DATA dCompile,dFile INIT ctod()
DATA nFileLen INIT 0
DATA aList,aTopics INIT {}
METHOD New()
...
ENDCLASS
////
METHOD New(vetor) CLASS DLL2D
Local aaa,cFunction,aVersion
::cCode := vetor[ 1]
::cName := vetor[ 3]
::nVersion := vetor[ 4]
::cPrefix := vetor[ 5]
::dCompile := vetor[ 6]
::cCompileTime := vetor[ 7]
::aList := vetor[8]
for aaa = 1 to len(::aList)
aadd(::aTopics,{::aList[aaa,1],.f.,NIL,len(::aList[aaa])=1})
next
for aaa = 1 to len(::aTopics)
if ::aTopics[aaa,4]
cFunction := __2D_ + ::cPrefix + ::aTopics[aaa,1]
if FunctionExists(cFunction)
::aTopics[aaa,2] := .t.
if ::aTopics[aaa,1] $ KT-KR
::aTopics[aaa,3] := (cFunction + '(TDK)')
else
::aTopics[aaa,3] := (cFunction + '(,TDX)')
endif
endif
else
::aTopics[aaa,2] := .t.
endif
next
aadd(::aAllDLL,Self)
Return Self
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2: Harbour and os2gcc
As Paul Smedley was releasing os2gcc404, os2gcc432, os2gcc433, os2gcc440 I was testing Harbour with them Later my choice was to use Harbour+os2gcc433 as reference and Harbour 2.0.0 for OS/2 was released with this version too Since Dec 2009 are available os2gcc434 and os2gcc442 I tested them with Harbour and reported results The new Qt 4.5.1 GA Release (for OS/2) state: = Improvements: * general: Switched the compiler to the GCC 4.4.2 build provided by Paul Smeldey. This gives better standard conformance, better code optimization and provides more compact DLLs and EXEs whose size is greater than ~1M. = They were using os2gcc335 in OMF type Some of their words are agree with mine as I said when proposed os2gcc4xx: ...better standard conformance, better code optimization... together with newest compiler, common in most modern OS, ... Perhaps I will move to use Harbour+os2gcc442 as reference What I do not like is the long time to build Harbour In Dec I requested to Paul, with no answer: - Since years I have a doubt: Why os2gcc is so slow ? Current Harbour build times are, in a fast Core2Duo E8400 3Ghz: os2gcc335-OMF 28 minutes os2gcc433 60 minutes os2gcc434 60 minutes os2gcc442 90 minutes os2-OpenWatcom 1.8 8 minutes - David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
On Thu, 11 Feb 2010, Leandro Damasio wrote: Hi, It will work but I do not understand how it's possible to call function by macro knowing it's name when macro value is created but in other context you do not know this name. Your above description does not make any sense or you simply forgot to say about some important conditions. Below is some code to exemplify what I couldn't explain to you textually. Maybe it helps. It was enough to say that you are using DLL name as part of name of your DLL entry function :-). With HRB file it can be implemented easier using static function with fixed name, i.e. HRBMAIN() in each module which needs initialization. BTW LIBLOAD()/LIBFREE() are xHarbour compatible functions. I suggest to use hb_libLoad()/hb_libFree(). Your code will not work for lower case extenssion. I suggest to change it to sth like: cFunction := __DLL__ + ; left( aFiles[ddd,1], at( ., aFiles[ddd,1] ) -1 ) best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: USE error ?
Przemek: Yes but now there are some other problems in data sharing. We have fixed CP support so it's not possible to share data with xHarbour applications which uses incompatible CP implementation. It will cause index file corruption so it's necessary to precisely verify if both application uses the same binary collation order. The same CP in both applications may not be enough. [...] Yes. But it's also true between two Harbour applications. All of them have to use exactly the same locking schemes. Thanks Not only locking-scheme problem but proper CP implementation too So to share data files between Harbour and xHarbour (or some other systems) is a big risk of data corruption This include different Harbour releases, due to changes in locking schemes and CP implementation The rule seem to be (or has been ever :-)) to change all applications to same (x)Harbour release at same time David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Przemek: .DBT and .FPT file confusion
Przemek: g) Why Clipper and Harbour show different ? : SET( _SET_MBLOCKSIZE ) 64 SET( _SET_MBLOCKSIZE ) 0 It must be fixed ? 0 means use RDD default. 64 for FPT and 32 for SMT. Along years we know that but reference may vary For example, in Clipper 5.3 DBFCDX memo block is 32 bytes by default for FoxPro compatibility (I am reading from Clipper 5.3 handbook), and later in 5.3a, ... moved to 64 bytes to follow FoxPro movement ADS followed FoxPro and used 64 bytes But as today SET( _SET_MBLOCKSIZE ) return 64 in Clipper 5.3a and return 0 in Harbour This old Clipper code of my friend does not apply in Harbour: IF SET( _SET_MBLOCKSIZE ) 64 SET( _SET_MBLOCKSIZE, 64 ) David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2: Harbour 13841
Viktor: - So os2gcc reach 32K limit again and harbourm.dll can not build :( I could be seen in advance. I can't give any solution, but I hope someone will. As expected, Harbour has grown and can not fit in 32K limit :-) I'll suppress the libharu warnings. Thanks David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: USE error ?
On Thu, 11 Feb 2010, David Arturo Macias Corona wrote: Hi, Not only locking-scheme problem but proper CP implementation too So to share data files between Harbour and xHarbour (or some other systems) is a big risk of data corruption Just like between Harbour and Harbour or Clipper and Clipper. This include different Harbour releases, due to changes in locking schemes and CP implementation I do not know about any bugs in locking schemes which had to be fixed breaking backward compatibility. The rule seem to be (or has been ever :-)) to change all applications to same (x)Harbour release at same time It will not help if you do not set in all applications the same locking scheme and CP or if you do not use network/OS layer which supports necessary synchronization mechanisms on all client platforms. It doesn't matter you are using only Clipper, Harbour, xHarbour, xbase++, CLIP, FlagsShip, ... or mixed applications to access the same data. Each of them has to be configured in exactly the same way. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Przemek: .DBT and .FPT file confusion
On Thu, 11 Feb 2010, David Arturo Macias Corona wrote: This old Clipper code of my friend does not apply in Harbour: IF SET( _SET_MBLOCKSIZE ) 64 SET( _SET_MBLOCKSIZE, 64 ) It perfectly works in Harbour forcing 64 bytes block size. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to build and use pCode DLL with hbmk2
Hello Przemek It will work but I do not understand how it's possible to call function by macro knowing it's name when macro value is created but in other context you do not know this name. Your above description does not make any sense or you simply forgot to say about some important conditions. Below is some code to exemplify what I couldn't explain to you textually. Maybe it helps. It was enough to say that you are using DLL name as part of name of your DLL entry function :-). With HRB file it can be implemented easier using static function with fixed name, i.e. HRBMAIN() in each module which needs initialization. Sorry, but look at DLL2D:New(). The piece of code below is to show how it's possible to call function by macro knowing it's name when macro value is created but in other context you do not know this name. The name of the entry function is known and could be declarated as DYNAMIC in the exe, but see the macro below - it depends on the return of what you called the dll entry function: ... cFunction := __2D_ + ::cPrefix + ::aTopics[aaa,1] //This is the macro I'm talking about: both ::cPrefix and ::aTopics came from the DLL if FunctionExists(cFunction) ::aTopics[aaa,2] := .t. if ::aTopics[aaa,1] $ KT-KR ::aTopics[aaa,3] := (cFunction + '(TDK)') else ::aTopics[aaa,3] := (cFunction + '(,TDX)') endif endif ... BTW LIBLOAD()/LIBFREE() are xHarbour compatible functions. I suggest to use hb_libLoad()/hb_libFree(). Your code will not work for lower case extenssion. I suggest to change it to sth like: cFunction := __DLL__ + ; left( aFiles[ddd,1], at( ., aFiles[ddd,1] ) -1 ) okay thanks Regards Leandro ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2: hbqt
Pritpal continue highly focused in hbide and other people does not have hints for this case: --- d) hbqt List of source files which have errors on OS/2 and detailed flow of tests Alternatives: - Fix source code - Perhaps this code does not work on OS/2 - Qt But Pritpal is highly focused in hbide now :-) Most errors are of kind: 'A' is not a member of 'B' class 'C' has no member named 'D' 'E' was not declared in this scope expected primary-expression before ')' token invalid use of incomplete type 'F' incomplete type 'G' used in nested name specifier forward declaration of 'H' expected type-specifier before 'I' I do not know if: - Are valid errors which must be fixed on Harbour - Other compiler switchs required - They are errors related to OS/2-Qt code and not Harbour --- So I am still do not know if are errors in Harbour or OS/2-Qt If they belong to hbqt and are not fixed, then derived tools as hbide will not work too Now are ready new Qt 4.5.1 GA Release (for OS/2) but I am unsure if I must to test with current Harbour or wait response for previous errors Notes for Qt 4.5.1 for OS/2: - First I tried to build Qt451b5 libraries from source code (NetLabs), using os2gcc335-OMF type After some hours it build entirely and final directory reached 819 Mbytes (yes, 819 Mbytes :-) ). Qt is a monster - I tried hbqt with these libraries and reported results - Then I used pre-compiled Qt451b5 libraries from NetLabs available .wpi file. They used around 34 Mbytes - Repeated hbqt build with these Qt pre-compiled libraries and results were same, so was not a problem of my Qt libraries build - Now for Qt 4.5.1 GA + I do not want to create Qt libraries from source code :-) + Using Netlabs .wpi for libraries, dev, samples, ... are around 50 Mbytes I deleted old \qt451b5 directory and recovered my 819 Mbytes David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] FPT corruption
Hi,
few times per year we find corrupted .fpt files in databeses of our
customers. The problem is that this corruption is not detected by driver
and causes strange behavior. For example, application hangs-up, but do
not GPFs. After some tests we found, that it hangs-up because it uses
a huge amount of memory (ex. = 1GB) and OS do a lot of disk swap thus
stops application and system. This memory usage is caused by reading
some memo value. Total memo file length is not big (1MB), but corrupted
.ftp blocks contains huge size values. I've wrote some code to test for
such memofields, but it would be nice to have some corruption detection
code in fpt driver.
Regards,
Mindaugas
#include hbapi.h
#include hbrddfpt.h
HB_FUNC( FPTTESTFIELD )
{
DBFAREAP pArea = ( DBFAREAP ) hb_rddGetCurrentWorkAreaPointer();
USHORT uiField = hb_parni( 1 );
ULONGulBlock, ulSize, ulType;
BOOL bDeleted;
if( !pArea || !uiField || uiField pArea-uiFieldCount ||
!pArea-fHasMemo || pArea-bMemoType != DB_MEMO_FPT )
{
hb_retl( FALSE );
return;
}
/* Force record read */
SELF_DELETED( pArea, bDeleted );
if( hb_dbfGetMemoData( ( DBFAREAP ) pArea, uiField - 1, ulBlock,
ulSize, ulType ) != SUCCESS )
{
hb_retl( FALSE );
return;
}
if( ulBlock 0 )
{
FPTBLOCK fptBlock;
if( hb_fileReadAt( pArea-pMemoFile, ( BYTE * ) fptBlock,
sizeof( FPTBLOCK ),
( HB_FOFFSET ) ulBlock * ( HB_FOFFSET )
pArea-uiMemoBlockSize ) != sizeof( FPTBLOCK ) )
{
hb_retl( FALSE );
return;
}
ulType = HB_GET_BE_UINT32( fptBlock.type );
ulSize = HB_GET_BE_UINT32( fptBlock.size );
if( ( ulType FPTIT_TEXT ulType FPTIT_FLEX_GC ) ||
ulType FPTIT_FLEX_COMPRCH ||
ulSize 1048576 )
{
hb_retl( FALSE );
return;
}
}
hb_retl( TRUE );
}
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FPT corruption
Mindaugas Kavaliauskas wrote: USHORT uiField = hb_parni( 1 ); ULONG ulBlock, ulSize, ulType; BOOL bDeleted; Viktor will kill you if he sees these :) Cheers Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FPT corruption
Mindaugas Kavaliauskas wrote: USHORT uiField = hb_parni( 1 ); ULONG ulBlock, ulSize, ulType; BOOL bDeleted; Viktor will kill you if he sees these :) It won't compile, so such harsh action is not necessary ;) But yes, you are right, and I forgot to send a specific message about that: From now on, only new Harbour types should be used in any new code committed to Harbour SVN, the only exception is for OS/3rd party package API specific code, this is typically Windows or OS/2 parts. Anyhow even in this case developers should pay attention to use Harbour types when appropriate, here it's easier to miss since compiler won't report an error. There is still an undecided area about new types, namely HB_UCHAR vs. HB_BYTE issue (both can be used now, and they are equivalent), but otherwise current state can be considered stable. I recommend following the same rules for 3rd party developers, new types can be added for pre-2.1 Harbour and xhb builds also. They can test code by using -DHB_LEGACY_TYPES_OFF macro. This will be the default mode after next major release, so it's good to start the preparation. Here a little help to make the conversion: HB_ULONG - HB_MAXUINT HB_LONG - HB_MAXINT BOOL - HB_BOOL TRUE - HB_TRUE FALSE - HB_FALSE BYTE - HB_BYTE ULONG - HB_ULONG LONG - HB_LONG UINT - HB_UINT SHORT - HB_SHORT USHORT- HB_USHORT LONGLONG - HB_LONGLONG ULONGLONG - HB_ULONGLONG INT16 - HB_I16 UINT16- HB_U16 INT32 - HB_I32 UINT32- HB_U32 INT64 - HB_I64 UINT64- HB_U64 SCHAR - HB_SCHAR UCHAR - HB_UCHAR We use HB_SIZE for every variable denoting string/array length or position, so it's recommended to use it in such places, instead of ULONG, and to use temporary signed size type HB_ISIZ instead of LONG/long/int. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HB_BYTE vs. HB_UCHAR
Hi Przemek and All, We have this decision left regarding new types, and I'd like to clear it. We currently have two types which are mapped to the same ANSI C type 'unsigned char'. IMO if we want to keep both, we should give some clear guideline to Harbour and 3rd party developer, as to which should be used in what situations. If we cannot do so, or if there is indeed no clear different between them (meaning they are equivalent), we should keep only one of them. In this case, the question is which to keep. IMO we should keep HB_BYTE since it looks much more familiar for users/developers and it's also much older term in Harbour. Opinions are welcome. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: Harbour 13841
David, this is something in gcc4 on OS/2, with my old GCC 3.3.5 and latest make I can build harbour.dll and harbourm.dll without problems. Directory of E:\REPOSITORY\HARBOUR\bin\os2\gcc 11/02/10 13:44 DIR124 . 11/02/10 13:27 DIR124 .. 11/02/10 13:41 3.866.628124 a--- harbour.dll 11/02/10 13:28548.868124 a--- harbour.exe 11/02/10 13:44 3.874.820124 a--- harbourm.dll 11/02/10 13:44 24.580124 a--- hbformat.exe 11/02/10 13:44 12.292124 a--- hbi18n.exe 11/02/10 13:44663.556124 a--- hbmk2.exe 11/02/10 13:27147.460124 a--- hbpp.exe 11/02/10 13:44561.156124 a--- hbrun.exe 11/02/10 13:44372.740124 a--- hbtest.exe 11 file(s) 10.072.100 bytes used 178.536.230 K bytes free (E:\REPOSITORY\HARBOUR)bin\os2\gcc\harbour --version Harbour 2.1.0dev (Rev. 13844) Copyright (c) 1999-2010, http://www.harbour-project.org/ Maurilio. David Arturo Macias Corona wrote: Viktor: - So os2gcc reach 32K limit again and harbourm.dll can not build :( I could be seen in advance. I can't give any solution, but I hope someone will. As expected, Harbour has grown and can not fit in 32K limit :-) I'll suppress the libharu warnings. Thanks David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2: Harbour 13841
Maurilio: this is something in gcc4 on OS/2, with my old GCC 3.3.5 and latest make I can build harbour.dll and harbourm.dll without problems. Directory of E:\REPOSITORY\HARBOUR\bin\os2\gcc 11/02/10 13:41 3.866.628124 a--- harbour.dll 11/02/10 13:44 3.874.820124 a--- harbourm.dll We review this problem in detail many months ago, so Viktor and I expected this moment as unavoidable as long Harbour grow Problem is due os2gcc, any version, have an 32Kb limit somewhere and can not manage temp file to build harbour.dll and harbourm.dll Now you can build harbourm.dll in os2gcc335-a.out type because are below but near of limit. A few more new object files (maybe around 150 Kb) you will have this problem too You will see first in mt\harbour(dll) and later in harbour(dll) It happen now in os2gcc335 or os2gcc4xx in OMF type because gccomf string in longer than gcc used in a.out type so content of temp file is longer and bigger than 32 Kb My previous messages show detailed info about this 32K limit in ANY os2gcc, older and newer This case can only be fixed by someone who know os2gcc internals, but they are focused (as Bird) in VirtualBox development For me is difficult to explain, I only found that limit. For some with os2gcc source code knowledge, may be easy to find and supress that 32K limit (perhaps you, Paul Smedley, Andreas Buening, ... ) For now we have ( and you will have :-) ) to live with this os2gcc limitation David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] HB_BYTE vs. HB_UCHAR
I agree with the uniqueness of the type, but i like HB_UCHAR. The 'unsigned' qualifier is declared, despite of HB_BYTE (signed or unsigned?). I know that it's more familiar, but not so precise as the HB_UCHAR (leaving no doubt about the sign). Maurizio la Cecilia -Messaggio originale- Da: Viktor Szakáts [mailto:harbour...@syenar.hu] Inviato: giovedì 11 febbraio 2010 15.07 A: Harbour Project Main Developer List. Oggetto: [Harbour] HB_BYTE vs. HB_UCHAR Hi Przemek and All, We have this decision left regarding new types, and I'd like to clear it. We currently have two types which are mapped to the same ANSI C type 'unsigned char'. IMO if we want to keep both, we should give some clear guideline to Harbour and 3rd party developer, as to which should be used in what situations. If we cannot do so, or if there is indeed no clear different between them (meaning they are equivalent), we should keep only one of them. In this case, the question is which to keep. IMO we should keep HB_BYTE since it looks much more familiar for users/developers and it's also much older term in Harbour. Opinions are welcome. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: R: [Harbour] HB_BYTE vs. HB_UCHAR
Maurizio la Cecilia wrote: I agree with the uniqueness of the type, but i like HB_UCHAR. The 'unsigned' qualifier is declared, despite of HB_BYTE (signed or unsigned?). I know that it's more familiar, but not so precise as the HB_UCHAR (leaving no doubt about the sign). For me, HB_BYTE implies raw data, and so I prefer it as it does not mention signedness at all. Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi Viktor, That can work, but it means we don't support int64/double parameters and int64/double/float/char return values anymore. Currently we do, so maybe it'd be good to take care of it. We should also support both cdecl and stdcall versions. Yes I know, this is not perfect. Also I just think, that in C, we can not *force* (yes or yes) the use of CPU registers AFAIK. IMHO this solution could work with majority calls, to the rest is easier and safer to make a private/local wrapper. So I think that's good if it works with other compilers because the alternative is keep all hbwin outside present and future optimizations for this ASM hard code. Perhaps it's better separate this function to other optional library. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] MT app works under Linux but fails under Win
When I try to run an MT app that works perfectly under Linux I get the error below ( even with -g Harbour rebuild ). If I link against harbour.dll it works as expected. Win offers to send the error to MS and gives a long dump of info. Any idea? best regards, Lorenzo [New thread 2348.0xe40] warning: HEAP[ths.exe]: warning: Invalid Address specified to RtlSizeHeap( 0061, 00B70008 ) Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll (gdb) bt #0 0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll #1 0x7c97e139 in ntdll!RtlpNtMakeTemporaryKey () from C:\WINDOWS\system32\ntdll.dll #2 0x7c97e576 in ntdll!RtlpNtMakeTemporaryKey () from C:\WINDOWS\system32\ntdll.dll #3 0x7c97fe93 in ntdll!RtlpNtMakeTemporaryKey () from C:\WINDOWS\system32\ntdll.dll #4 0x7c95ade7 in ntdll!LdrFindEntryForAddress () from C:\WINDOWS\system32\ntdll.dll #5 0x0061 in ?? () #6 0x5061 in ?? () #7 0x00b70008 in ?? () #8 0x0022fd30 in ?? () #9 0x0022f914 in ?? () #10 0x77bfc024 in msvcrt!_msize () from C:\WINDOWS\system32\msvcrt.dll #11 0x0061 in ?? () #12 0x in ?? () ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: OS/2: hbqt
David Arturo Macias Corona wrote: Pritpal continue highly focused in hbide and other people does not have hints for this case: I know nothing about OS2 and hence not in a position to comment. One point which comes in mind is that Harbour is supporting Qt 5.5.3 and your experiments are centered around 4.5.1. There is likelyhood that some of the methods may not be available in 4.5.1. But to be doubly sure, can you some short log of errors ? Mostly these errors are the results of wrong headers. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/OS-2-hbqt-tp4554645p436.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] for each requires local definition?
Hi All,
Does 'For Each' require variables to be local defined?
proc test
local ary := {1,2,3}
local n with out this line a RTE Error BASE/1003 Variable does not
exist: N will occour
for each n in ary
? n
Next
Thanks
Abe
--
View this message in context:
http://n2.nabble.com/for-each-requires-local-definition-tp4555894p4555894.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: Harbour 13841
David, I've reviewed your messages, I think 32K is environment size limit for OS/2 processes; so, maybe os2gcc and/or ld receive something as an envvar and this is now bigger than 32Kb :( Maurilio. David Arturo Macias Corona wrote: Maurilio: this is something in gcc4 on OS/2, with my old GCC 3.3.5 and latest make I can build harbour.dll and harbourm.dll without problems. Directory of E:\REPOSITORY\HARBOUR\bin\os2\gcc 11/02/10 13:41 3.866.628124 a--- harbour.dll 11/02/10 13:44 3.874.820124 a--- harbourm.dll You can see detailed info in messages from: OS/2: harbourm.dll 4/10/09 07:28 AM David Macias ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13845] trunk/harbour
Revision: 13845 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13845view=rev Author: vszakats Date: 2010-02-11 17:18:40 + (Thu, 11 Feb 2010) Log Message: --- 2010-02-11 18:17 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_dll.c - Deleted WINAPI keyword from win64 .dll support. It has no meaning under win64, and win64 .dll support is not only meant to access winapi functions anyway. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_dll.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13846] trunk/harbour
Revision: 13846 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13846view=rev Author: vszakats Date: 2010-02-11 17:41:28 + (Thu, 11 Feb 2010) Log Message: --- 2010-02-11 18:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_dll.c % Simplified win64 support. ! Fixed win64 support for returning parameters passed by reference. * ChangeLog * Old TOFIXes marked DONE. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_dll.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13847] trunk/harbour
Revision: 13847 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13847view=rev Author: vszakats Date: 2010-02-11 17:49:24 + (Thu, 11 Feb 2010) Log Message: --- 2010-02-11 18:48 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_dll.c + Added 'double' type support for win64 .dll call. ; Untested, pls review. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_dll.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] for each requires local definition?
On Thu, 11 Feb 2010, AbeB wrote:
Hi,
Does 'For Each' require variables to be local defined?
No.
proc test
local ary := {1,2,3}
local n with out this line a RTE Error BASE/1003 Variable does not
exist: N will occour
for each n in ary
? n
Next
Pefect behavior. No 'n' variable is declared.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] for each requires local definition?
Hi Przemek and All,
IMO it would be more consistent behavior to create a private
variable in such case, since with regular FOR/NEXT it also
works without declaring the variable:
--- OK
FOR tmp := 1 TO Len( a )
NEXT
---
--- Not OK
FOR EACH tmp IN a
NEXT
---
'tmp' is a written variable in both cases.
Brgds,
Viktor
On 2010 Feb 11, at 19:09, Przemysław Czerpak wrote:
On Thu, 11 Feb 2010, AbeB wrote:
Hi,
Does 'For Each' require variables to be local defined?
No.
proc test
local ary := {1,2,3}
local n with out this line a RTE Error BASE/1003 Variable does not
exist: N will occour
for each n in ary
? n
Next
Pefect behavior. No 'n' variable is declared.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13848] trunk/harbour
Revision: 13848 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13848view=rev Author: vszakats Date: 2010-02-11 18:35:25 + (Thu, 11 Feb 2010) Log Message: --- 2010-02-11 19:33 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_dll.c + Added UNICODE and codepage conversion support for win32 .dll calls, too. ! Fix to win64 double support. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_dll.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FPT corruption
Hi, Alex Strickland wrote: USHORT uiField = hb_parni( 1 ); ULONG ulBlock, ulSize, ulType; BOOL bDeleted; Viktor will kill you if he sees these :) I have alibi. This code is created half year ago :) Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] for each requires local definition?
On Thu, 11 Feb 2010, Szak�ts Viktor wrote: Hi, IMO it would be more consistent behavior to create a private variable in such case, since with regular FOR/NEXT it also works without declaring the variable: --- OK FOR tmp := 1 TO Len( a ) NEXT Because you have explicit assignment ':=' which creates new memvar variable if it does not exists just like use as standalone operator without FOR statement. --- Not OK FOR EACH tmp IN a NEXT --- 'tmp' is a written variable in both cases. tmp in FOR EACH is only reference. Why we should create variable for such reference in FOR EACH but not in function call?, i.e.: func( @tmp ) ? tmp 'tmp' is also a written variable like in above both cases. Of course if most of Harbour users prefer to create new memvar variable in FOR EACH then I'll implement it but I do not like it. But do not forget that FOR EACH does not store dummy references after iteration but restores original variable value. proc main() x := 10 ? x for each x in ABC ? x next ? x return Personally I even think that FOR EACH should use their own temporary variables instead of declared ones. It will be much cleaner and faster. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] for each requires local definition?
tmp in FOR EACH is only reference. Why we should create variable for such reference in FOR EACH but not in function call?, i.e.: func( @tmp ) ? tmp 'tmp' is also a written variable like in above both cases. Of course if most of Harbour users prefer to create new memvar variable in FOR EACH then I'll implement it but I do not like it. But do not forget that FOR EACH does not store dummy references after iteration but restores original variable value. proc main() x := 10 ? x for each x in ABC ? x next ? x return Personally I even think that FOR EACH should use their own temporary variables instead of declared ones. It will be much cleaner and faster. Sounds reasonable. BTW for this is not a problem, but I've personally stumbled into this quite a few times (when creating small quick test code without -w switch) and found it non-natural. Anyway it's not huge problem for me and I can accept this explanation. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: for each requires local definition?
Przemysław Czerpak wrote: Personally I even think that FOR EACH should use their own temporary variables instead of declared ones. It will be much cleaner and faster. +1 - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/for-each-requires-local-definition-tp4555894p4556986.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] MSVS 2010 RC is out
http://msdn.microsoft.com/en-us/library/dd465215(VS.100).aspx http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx (interesting to see their IDE improvements. better late than never) Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13841] trunk/harbour
Hi Przemek,
Ok, I'll do it ...more slowly :)
Best regards,
--
Xavi
El 11/02/2010 12:48, Przemysław Czerpak escribió:
On Thu, 11 Feb 2010, jara...@users.sourceforge.net wrote:
Hi Xavi,
2010-02-11 04:25 UTC+0100 Xavi (jarabal/at/gmail.com)
* contrib/hbwin/wapi_winbase.c
+ Added wapi_GETSHORTPATHNAME()
Thank you very much. Just only few notes.
WAPI_* functions should be as closed to original implementation
as possible. We can introduce some small extensions and parameter
validation (it's even suggested) using additional information we
have due to Harbour item types but we should not change or ignore
valid parameters. In this case passing 0 as 3-rd parameter is ignored
Also the buffer is 1 or 3 in UNICODE mode bytes greater then request
by user. If programmer not precisely check the implementation details
then he can be seriously confused by the results.
If wapi_GETSHORTPATHNAME() supports the following parameters:
wapi_GETSHORTPATHNAME(cLongName [, @shortName [,nMaxSize ] ] )
-nShortLenght
then the implementation should follow it.
I also suggest to eliminate double call to GetShortPathName() if possible.
In some cases it can be quite expensive i.e. network volumes.
Below is your code a little bit modified to respect above conditions.
I think that we should add also wapi_GETLONGPATHNAME() and
wapi_GETFULLPATHNAME()
Can you implement them too?
best regards,
Przemek
HB_FUNC( WAPI_GETSHORTPATHNAME )
{
void * hLongPath;
DWORD length = 0;
LPCTSTR lpszLongPath = HB_PARSTR( 1,hLongPath, NULL );
if( lpszLongPath )
{
if( HB_ISBYREF( 2 ) )
{
TCHAR buffer[ HB_PATH_MAX ];
DWORD cchBuffer = ( DWORD ) HB_SIZEOFARRAY( buffer );
LPTSTR lpszShortPath = buffer;
HB_BOOL fSize = HB_ISNUM( 3 );
if( fSize )/* the size of buffer is limited by user */
{
cchBuffer = ( DWORD ) hb_parnl( 3 );
if( cchBuffer == 0 )
lpszShortPath = NULL;
else if( cchBuffer ( DWORD ) HB_SIZEOFARRAY( buffer ) )
lpszShortPath = ( LPTSTR ) hb_xgrab( cchBuffer * sizeof( TCHAR
) );
}
length = GetShortPathName( lpszLongPath, lpszShortPath, cchBuffer );
if( !fSize length cchBuffer ) /* default buffer size was too
small */
{
cchBuffer = length;
lpszShortPath = ( LPTSTR ) hb_xgrab( cchBuffer * sizeof( TCHAR ) );
length = GetShortPathName( lpszLongPath, lpszShortPath, cchBuffer
);
}
hbwapi_SetLastError( GetLastError() );
HB_STORSTRLEN( lpszShortPath, length cchBuffer ? 0 : length, 2 );
if( lpszShortPath lpszShortPath != buffer )
hb_xfree( lpszShortPath );
}
else
{
length = GetShortPathName( lpszLongPath, NULL, 0 );
hbwapi_SetLastError( GetLastError() );
}
}
hb_retnl( length );
hb_strfree( hLongPath );
}
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HB_BYTE vs. HB_UCHAR
On Thu, 11 Feb 2010, Szak�ts Viktor wrote: Hi, We have this decision left regarding new types, and I'd like to clear it. We currently have two types which are mapped to the same ANSI C type 'unsigned char'. IMO if we want to keep both, we should give some clear guideline to Harbour and 3rd party developer, as to which should be used in what situations. If we cannot do so, or if there is indeed no clear different between them (meaning they are equivalent), we should keep only one of them. In this case, the question is which to keep. IMO we should keep HB_BYTE since it looks much more familiar for users/developers and it's also much older term in Harbour. HB_UCHAR precisely define it's unsigned type. BYTE does not have to be signed or unsigned so replacing HB_UCHAR by HB_BYTE is not good idea in my opinion. We can eliminate HB_BYTE and use everywhere HB_UCHAR but I also do not find anything wrong in keeping this type to to mark memory blocks of data in bytes. Just like we are using 'char' for strings. In both cases the sign is unimportant. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HB_BYTE vs. HB_UCHAR
IMO if we want to keep both, we should give some clear guideline to Harbour and 3rd party developer, as to which should be used in what situations. If we cannot do so, or if there is indeed no clear different between them (meaning they are equivalent), we should keep only one of them. In this case, the question is which to keep. IMO we should keep HB_BYTE since it looks much more familiar for users/developers and it's also much older term in Harbour. HB_UCHAR precisely define it's unsigned type. BYTE does not have to be signed or unsigned so replacing HB_UCHAR by HB_BYTE is not good idea in my opinion. We can eliminate HB_BYTE and use everywhere HB_UCHAR but I also do not find anything wrong in keeping this type to to mark memory blocks of data in bytes. Just like we are using 'char' for strings. In both cases the sign is unimportant. I have no problem with either variation, though if we want to keep it, can you describe when to use HB_UCHAR and when to use HB_BYTE? Or give some examples from Harbour, that should make it easier to understand. [ After browsing through the whole codebase for days, I couldn't really find out the concept, so I can't help here. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FPT corruption
On Thu, 11 Feb 2010, Mindaugas Kavaliauskas wrote: Hi, few times per year we find corrupted .fpt files in databeses of our customers. The problem is that this corruption is not detected by driver and causes strange behavior. For example, application hangs-up, but do not GPFs. After some tests we found, that it hangs-up because it uses a huge amount of memory (ex. = 1GB) and OS do a lot of disk swap thus stops application and system. This memory usage is caused by reading some memo value. Total memo file length is not big (1MB), but corrupted .ftp blocks contains huge size values. I've wrote some code to test for such memofields, but it would be nice to have some corruption detection code in fpt driver. The maximum size of single memo block in FPT format is 4GB. Any upper limit check we can introduce without reducing functionality is comparing the size of memo block with the difference between total memo file size and block offset. For relatively small memo files it may help to early detect corruption but it will not help for big files and for sure in all cases it will cause performance reduction because we will have to add additional IO call to check current file size. To reduce the overhead we can add such verification only for blocks bigger then some arbitrary chosen by us limit i.e. 4MB. If you think it's worth to implement then I can do that. I can also enable strict TYPE verification but it may cause problems when some extended types stored by program compiled by other languages are used. There are many local extensions to FPT format. Now Harbour returns NIL for such fields. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi Xavi and All, On 2010 Feb 11, at 16:23, Xavi wrote: Hi Viktor, That can work, but it means we don't support int64/double parameters and int64/double/float/char return values anymore. Currently we do, so maybe it'd be good to take care of it. We should also support both cdecl and stdcall versions. Yes I know, this is not perfect. Also I just think, that in C, we can not *force* (yes or yes) the use of CPU registers AFAIK. We don't need to, if we keep the whole thing on C level. IMHO this solution could work with majority calls, to the rest is easier and safer to make a private/local wrapper. So I think that's good if it works with other compilers because the alternative is keep all hbwin outside present and future optimizations for this ASM hard code. Perhaps it's better separate this function to other optional library. The .c source file is about 100MB if we create separate function skeletons for all combinations, so it's not something realistic. (or maybe I'm wrong and it can be reduced using tricks) I can easily implement pure .c win32 .dll call support which drops support for int64/double parameters and int64/double/float return values. I'd also guess they are not very widely used, so it's probably not a big loss. Any opinion on that? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi Viktor, I can easily implement pure .c win32 .dll call support which drops support for int64/double parameters and int64/double/float return values. I'd also guess they are not very widely used, so it's probably not a big loss. I agree. If need it, is better to have a specific wrapper. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Res: [Harbour] MinGW dllcall function not run.
Hi Xavi, Hi Viktor, I can easily implement pure .c win32 .dll call support which drops support for int64/double parameters and int64/double/float return values. I'd also guess they are not very widely used, so it's probably not a big loss. I agree. If need it, is better to have a specific wrapper. I've since found the solution to not loose these types while keeping pure .c and just a reasonable amount of code. I hope I can commit something in a while. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour-users] (no subject)
I am looking for Harbour manual/documentation. I am aware about a quite old (x)Harbour help file being distributed along with minigui extended, but that document seems to not updated for a long time and does not cover many new functions introduced with Harbour v.2.00 and later. I am a frequent reader of the harbour-developers mailing list and there I see many new and very interesting hb_* functions, mentioned by core-developers in their responses, for which functions i cannot find any documentation. Does anybody know of such kind of documentation -in any format (even .txt)? thanks in advance, --- Pete __ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://mail.yahoo.gr ___ Harbour-users mailing list (attachment size limit: 40KB) Harbour-users@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour-users
