[Harbour] SF.net SVN: harbour-project:[12597] trunk/harbour
Revision: 12597 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12597&view=rev Author: vszakats Date: 2009-09-22 07:49:14 + (Tue, 22 Sep 2009) Log Message: --- 2009-09-22 09:47 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * include/hbwince.h * source/common/hbwince.c + Added WIDE version of dummy winapi implementations for WinCE. * source/common/hbffind.c * source/common/hbfsapi.c * source/rtl/diskspac.c * source/rtl/disksphb.c * source/rtl/filesys.c * source/vm/dynlibhb.c * contrib/hbmzip/hbmzip.c * contrib/xhb/filestat.c * contrib/hbwin/win_dll.c * contrib/hbwin/wapi_winbase.c * contrib/hbwin/win_prn1.c * contrib/hbwin/win_prn2.c + Changed forced ANSI version of winapi calls to native version. ! Fixed potential GPF in WIN_LOADBITMAPFILE(). % Cleaned types/variables in hb_PrintFileRaw(). % Minor type cleanup and formatting in filestat.c. ; TODO: There are still some forced ANSI calls in Harbour code: (plus some dynamically called ones) --- source/common/hbver.c:264: if( GetVersionExA( &osVer ) ) source/common/hbver.c:306: if( GetVersionExA( ( OSVERSIONINFOA * ) &osVerEx ) ) source/common/hbgete.c:75: DWORD size = GetEnvironmentVariableA( szName, NULL, 0 ); source/common/hbgete.c:80: GetEnvironmentVariableA( szName, pszBuffer, size ); source/common/hbgete.c:114: bRetVal = GetEnvironmentVariableA( szName, szBuffer, nSize ) != 0; source/common/hbgete.c:157: return SetEnvironmentVariableA( szName, szValue ) != 0; source/rtl/filesys.c:2687: fResult = GetCurrentDirectoryA( ulSize, pszBuffer ); source/rtl/filesys.c:2876: type = GetDriveTypeA( buffer ); source/rtl/fstemp.c:153: if( ! GetTempPathA( ( DWORD ) ( HB_PATH_MAX - 1 ), pszName ) ) source/rtl/fstemp.c:270: if( ! GetTempPathA( ( DWORD ) HB_PATH_MAX, szTempDir ) ) source/rtl/fstemp.c:278: fResult = GetTempFileNameA( szTempDir, pszPrefix ? pszPrefix : "hb", 0, pszBuffer ); source/rtl/net.c:157: GetComputerNameA( pszValue, &ulLen ); source/rtl/net.c:186: GetUserNameA( pszValue, &ulLen ); contrib/hbwin/win_prn2.c:169: DWORD dwSize = GetProfileStringA( "windows", "device", "", pPrinterName, *pdwBufferSize ); --- ; Review me. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbmzip/hbmzip.c trunk/harbour/contrib/hbwin/wapi_winbase.c trunk/harbour/contrib/hbwin/win_dll.c trunk/harbour/contrib/hbwin/win_prn1.c trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/contrib/xhb/filestat.c trunk/harbour/include/hbwince.h trunk/harbour/source/common/hbffind.c trunk/harbour/source/common/hbfsapi.c trunk/harbour/source/common/hbwince.c trunk/harbour/source/rtl/diskspac.c trunk/harbour/source/rtl/disksphb.c trunk/harbour/source/rtl/filesys.c trunk/harbour/source/vm/dynlibhb.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12598] trunk/harbour
Revision: 12598 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12598&view=rev Author: vszakats Date: 2009-09-22 07:53:16 + (Tue, 22 Sep 2009) Log Message: --- 2009-09-22 09:52 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * source/vm/dynlibhb.c ! Minor typo. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/source/vm/dynlibhb.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] SF.net SVN: harbour-project:[12590] trunk/harbour
>-Original Message- >From: Viktor Szakáts [mailto:harbour...@syenar.hu] >Sent: Tuesday, September 22, 2009 12:15 AM >To: Harbour Project Main Developer List. >Subject: Re: [Harbour] SF.net SVN: harbour-project:[12590] >trunk/harbour > >Hi Mindaugas, > >And most importantly thanks for this contribution, I think >it's a very nice one and can easily replace any temp tables >created on disk. I'll now go and convert my app to use it. But what is the difference with dbCreateTemp() ? I use dbCreateTemp(), and in this solution OS is decided where table created (memory or disk). Regards, Marek Horodyski ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12590] trunk/harbour
+1 i can clean a lot of temp in my app with little effort Is not a rdd so i can't use something like NETIO_CONNECT(*? 2009/9/22 Viktor Szakáts > Hi Mindaugas, > > And most importantly thanks for this contribution, I think > it's a very nice one and can easily replace any temp tables > created on disk. I'll now go and convert my app to use it. > > Brgds, > Viktor > > > On 2009 Sep 21, at 21:54, Mindaugas Kavaliauskas wrote: > > Viktor Szakáts wrote: >> >>> Is there any particular reason you choose a name >>> without 'hb' prefix? >>> I'd like to add make files and rename it to hbmemio, >>> if possible. I'm not sure we should start a new special >>> prefix to store IO replacement libs yet. >>> Or, maybe we could rename both this lib and hbnetio >>> to hbiomem and hbionet. Any opinions? >>> >> >> >> Hi, >> >> >> I've just tried to follow the other similar cases. We have rdd* libraries, >> and also gt* libraries. I/O Driver sounds very similar to Replaceable Data >> Driver, so I've used iod* prefix. >> >> Feel free to change it. >> >> >> Regards, >> Mindaugas >> ___ >> 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 > -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12590] trunk/harbour
-Original Message- From: Viktor Szakáts [mailto:harbour...@syenar.hu] Sent: Tuesday, September 22, 2009 12:15 AM To: Harbour Project Main Developer List. Subject: Re: [Harbour] SF.net SVN: harbour-project:[12590] trunk/harbour Hi Mindaugas, And most importantly thanks for this contribution, I think it's a very nice one and can easily replace any temp tables created on disk. I'll now go and convert my app to use it. But what is the difference with dbCreateTemp() ? I use dbCreateTemp(), and in this solution OS is decided where table created (memory or disk). It's always created as a disk file. As such, it may be left on disk in case of error, and also exclusive access isn't guaranteed, plus since it's a disk file, performance is probably worse in most cases (even if fully cached). Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
Hi,
And most importantly thanks for this contribution, I think
it's a very nice one and can easily replace any temp tables
created on disk. I'll now go and convert my app to use it.
the primary idea was more a toy I/O driver than the really useful
addition to harbour. Linux users can reach a similar effect by storing
files at /dev/shm. Disk buffers also makes a disk to be a little similar
(by speed) to memory. I still wanted to test disk overhead on local
drives, so, I've wrote this I/O driver. Test (source code is presented
below) execution times are:
Mem I/O:
DBAPPEND 13203
INDEX8375
DBEVAL6890
File I/O:
DBAPPEND 24563
INDEX9266
DBEVAL 11484
But now I'm thinking about including this I/O driver into one of the
projects. We have about a 1 million records in database and report
generation is too slow in network environment (in local environment
speed is acceptable). I'm thinking about copying the whole remote file
(well, about 100MB...) to memory file system, and generating report from
memory.
Regards,
Mindaugas
REQUEST HB_IODMEM
#define COUNT 200
PROC main()
LOCAL nI, nJ, nT
FIELD F1, F2
? "Mem I/O:"
DBCREATE("mem:test", {{"F1", "C", 64, 0}, {"F2", "N", 9, 0}},, .T.,
"memtest")
nT := HB_MILLISECONDS()
FOR nI := 1 TO COUNT
DBAPPEND()
F2 := HB_RANDOM() * 100
F1 := "Blah, blah, blah..." + STR(RECNO()) + " " + STR(F2)
NEXT
? " DBAPPEND ", HB_MILLISECONDS() - nT
nT := HB_MILLISECONDS()
INDEX ON F2 TAG F2
? " INDEX ", HB_MILLISECONDS() - nT
nT := HB_MILLISECONDS()
nJ := 0
DBEVAL({|| nJ += F2})
? " DBEVAL ", HB_MILLISECONDS() - nT
DBCLOSEALL()
DBDROP("mem:test")
? "File I/O:"
DBCREATE("test", {{"F1", "C", 64, 0}, {"F2", "N", 9, 0}},, .T.,
"memtest")
nT := HB_MILLISECONDS()
FOR nI := 1 TO COUNT
DBAPPEND()
F2 := HB_RANDOM() * 100
F1 := "Blah, blah, blah..." + STR(RECNO()) + " " + STR(F2)
NEXT
? " DBAPPEND ", HB_MILLISECONDS() - nT
nT := HB_MILLISECONDS()
INDEX ON F2 TAG F2
? " INDEX ", HB_MILLISECONDS() - nT
nT := HB_MILLISECONDS()
nJ := 0
DBEVAL({|| nJ += F2})
? " DBEVAL ", HB_MILLISECONDS() - nT
DBCLOSEALL()
DBDROP("test")
RETURN
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] bio.c under Centos 5.3 issue
../../../bio.c: In function ‘HB_FUN_BIO_TEST_FLAGS’: ../../../bio.c:199: warning: implicit declaration of function ‘BIO_test_flags’ Centos 5.3 seems to have openssl-0.9.8e best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
Hi, File hb_out.log is generated: Application Memory Allocation Report - D:\TESTS\test.exe Terminated at: 2009.09.22 13:19:25 Total memory allocated: 107343446 bytes (913 block(s)) Warning, memory allocated but not released: 99808005 bytes (7 block(s)) Block 1 003AE5E8 (size 64) (0), "50BF3B0080B73B00" Block 2 003BBF50 (size 40) DBCREATE(0), "E32669049FAA6A0460001578D8BF3B0001006D00070027000700" Block 3 78150060 (size 74099359) DBCREATE(0), "036D091640420F0062004A004631004340004632004E09000D0020426C61682C20626C61682C20626C61682E2E2E20202020202020202031202020203937313036382020202020202020202020202020202020202020202020202020202039373130363820426C61682C20626C61682C20626C61682E2E2E20202020202020202032202020203739333239382020202020202020202020202020202020202020202020202020202037393332393820426C61682C20626C61" Block 4 003BBFD8 (size 9) DBCREATE(0), "test.dbf." Block 5 003BB780 (size 40) ORDCREATE(0), "00842C01A84788016000B87C20C73B0001000500B0C63B00" Block 6 7CB80060 (size 25708456) ORDCREATE(0), "060001802C011100090034001A004632" Block 7 003BC720 (size 9) ORDCREATE(0), "test.ntx." Application Memory Allocation Report - D:\MyXHb\ERROR\testh.exe Terminated at: 2009.09.22 13:21:12 Total memory allocated: 7535481 bytes (905 block(s)) Warning, memory allocated but not released: 68 bytes (1 block(s)) Block 1 003AE5E8 (size 64) (0), "" Application Memory Allocation Report - D:\MyXHb\ERROR\testh.exe Terminated at: 2009.09.22 13:23:00 Total memory allocated: 229933358 bytes (913 block(s)) Warning, memory allocated but not released: 224567773 bytes (7 block(s)) Block 1 003AE5E8 (size 64) (0), "50BF3B0080B73B00" Block 2 003BBF50 (size 40) DBCREATE(0), "634DD208E5FFEF0960005F67D8BF3B0001006D00070027000700" Block 3 675F0060 (size 166723557) DBCREATE(0), "036D091680841E0062004A004631004340004632004E09000D0020426C61682C20626C61682C20626C61682E2E2E20202020202020202031202020203130393830362020202020202020202020202020202020202020202020202020202031303938303620426C61682C20626C61682C20626C61682E2E2E20202020202020202032202020203137393735342020202020202020202020202020202020202020202020202020202031373937353420426C61682C20626C61" Block 4 003BBFD8 (size 9) DBCREATE(0), "test.dbf." Block 5 003BB780 (size 40) ORDCREATE(0), "59023AA1720360007E7420C73B0001000500B0C63B00" Block 6 747E0060 (size 57844026) ORDCREATE(0), "060001FC58021100090034001A004632" Block 7 003BC720 (size 9) ORDCREATE(0), "test.ntx." Best regards, Saulius ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bio.c under Centos 5.3 issue
Hi Lorenzo, Can you try with 'make -i' to list all missing components? Brgds, Viktor On 2009 Sep 22, at 12:27, Lorenzo Fiorini wrote: ../../../bio.c: In function ‘HB_FUN_BIO_TEST_FLAGS’: ../../../bio.c:199: warning: implicit declaration of function ‘BIO_test_flags’ Centos 5.3 seems to have openssl-0.9.8e best regards, Lorenzo ___ 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] bio.c under Centos 5.3 issue
On Tue, Sep 22, 2009 at 12:35 PM, Viktor Szakáts wrote: > Can you try with 'make -i' to list all missing components? These are my envs: export HB_INSTALL_PREFIX=/opt/harbour export HB_COMMERCE=yes export HB_BUILD_DLL=no export HB_EXTERNALLIBS="zlib pcre sqlite3" export HB_CONTRIBLIBS="hbct hblog hbxml hbmzip hbtip hbvpdf hbgd hbpgsql hbcurl hbmysql hbsqlit3 hbssl hbodbc" export HB_WITH_QT=/opt/qtsdk/qt/include export HB_WITH_ZLIB=local export HB_WITH_PCRE=local export HB_WITH_SQLITE3=local export HB_USER_CFLAGS=-fpic and I get: ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org ! MAKE: make 3.81 /bin/sh i ! HB_USER_CFLAGS: -fpic ! HB_INSTALL_PREFIX: /opt/harbour ! HB_BUILD_DLL: no ! HB_BUILD_SHARED: no ! HB_CONTRIBLIBS: hbct hblog hbxml hbmzip hbtip hbvpdf hbgd hbpgsql hbcurl hbmysql hbsqlit3 hbssl hbodbc ! HB_EXTERNALLIBS: zlib pcre sqlite3 ! HB_HOST_PLAT: linux (x86) HB_SHELL: sh ! HB_PLATFORM: linux (x86) (autodetected) ! HB_COMPILER: gcc (autodetected: /usr/bin/) ! Component: 'zlib' found in /mnt/shared/dvl/src/ws/harbour/external/zlib (local) ! Component: 'pcre' found in /mnt/shared/dvl/src/ws/harbour/external/pcre (local) ! Component: 'openssl' found in /usr/include ! Component: 'gpm' explicitly disabled ! Component: 'slang' explicitly disabled ! Component: 'curses' not found ! Component: 'x11' found in /usr/include ! Component: 'wattcp/watt-32' not supported on linux platform ! REVISION: exported best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bio.c under Centos 5.3 issue
I'd be interested in error output from hbssl. Brgds, Viktor On 2009 Sep 22, at 12:42, Lorenzo Fiorini wrote: On Tue, Sep 22, 2009 at 12:35 PM, Viktor Szakáts 0...@syenar.hu> wrote: Can you try with 'make -i' to list all missing components? These are my envs: export HB_INSTALL_PREFIX=/opt/harbour export HB_COMMERCE=yes export HB_BUILD_DLL=no export HB_EXTERNALLIBS="zlib pcre sqlite3" export HB_CONTRIBLIBS="hbct hblog hbxml hbmzip hbtip hbvpdf hbgd hbpgsql hbcurl hbmysql hbsqlit3 hbssl hbodbc" export HB_WITH_QT=/opt/qtsdk/qt/include export HB_WITH_ZLIB=local export HB_WITH_PCRE=local export HB_WITH_SQLITE3=local export HB_USER_CFLAGS=-fpic and I get: ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org ! MAKE: make 3.81 /bin/sh i ! HB_USER_CFLAGS: -fpic ! HB_INSTALL_PREFIX: /opt/harbour ! HB_BUILD_DLL: no ! HB_BUILD_SHARED: no ! HB_CONTRIBLIBS: hbct hblog hbxml hbmzip hbtip hbvpdf hbgd hbpgsql hbcurl hbmysql hbsqlit3 hbssl hbodbc ! HB_EXTERNALLIBS: zlib pcre sqlite3 ! HB_HOST_PLAT: linux (x86) HB_SHELL: sh ! HB_PLATFORM: linux (x86) (autodetected) ! HB_COMPILER: gcc (autodetected: /usr/bin/) ! Component: 'zlib' found in /mnt/shared/dvl/src/ws/harbour/external/zlib (local) ! Component: 'pcre' found in /mnt/shared/dvl/src/ws/harbour/external/pcre (local) ! Component: 'openssl' found in /usr/include ! Component: 'gpm' explicitly disabled ! Component: 'slang' explicitly disabled ! Component: 'curses' not found ! Component: 'x11' found in /usr/include ! Component: 'wattcp/watt-32' not supported on linux platform ! REVISION: exported best regards, Lorenzo ___ 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] bio.c under Centos 5.3 issue
On Tue, Sep 22, 2009 at 12:50 PM, Viktor Szakáts wrote: > I'd be interested in error output from hbssl. ../../../bio.c: In function ‘HB_FUN_BIO_TEST_FLAGS’: ../../../bio.c:199: warning: implicit declaration of function ‘BIO_test_flags’ best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12599] trunk/harbour
Revision: 12599 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12599&view=rev Author: druzus Date: 2009-09-22 10:58:10 + (Tue, 22 Sep 2009) Log Message: --- 2009-09-22 12:58 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbrddcdx.h * harbour/source/rdd/dbfcdx/dbfcdx1.c + added support for national sorting using accented and multibyte characters. Warning CDX indexes created so far for such CDPs are not sorted using the same conditions as current SVN code so new applications should reindex. Harbour codepages with accented characters: cs852, csiso, cskam, cswin, sk852, skiso, skkam, skwin sv850, sviso, svwin fr850, friso, frwin el737, elwin, Harbour codepages with multibyte characters: cs852, csiso, cskam, cswin, sk852, skiso, skkam, skwin Now string keys in CDX indexes using above codepages are sorted in the same way as HVM sorts strings. Please only remember that CDX internal format was designed for byte weight sorting so such CPs may reduce internal compression level increasing the size of final indexes. After this modification all native index types (NTX, NSX and CDX) fully respects national sorting defined in Harbour CPs. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbrddcdx.h trunk/harbour/source/rdd/dbfcdx/dbfcdx1.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bio.c under Centos 5.3 issue
I understand, so this is the only one error, even with -i. You can try to fix that using: HB_USER_CFLAGS=-DHB_OPENSSL_OLD_OSX_ Brgds, Viktor On 2009 Sep 22, at 12:57, Lorenzo Fiorini wrote: On Tue, Sep 22, 2009 at 12:50 PM, Viktor Szakáts 0...@syenar.hu> wrote: I'd be interested in error output from hbssl. ../../../bio.c: In function ‘HB_FUN_BIO_TEST_FLAGS’: ../../../bio.c:199: warning: implicit declaration of function ‘BIO_test_flags’ best regards, Lorenzo ___ 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] bio.c under Centos 5.3 issue
On Tue, Sep 22, 2009 at 1:10 PM, Viktor Szakáts wrote: > You can try to fix that using: > HB_USER_CFLAGS=-DHB_OPENSSL_OLD_OSX_ Yes, it worked. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12599] trunk/harbour
On Tue, Sep 22, 2009 at 12:58 PM, wrote: Sorry I'm not sure I've understood correctly. > Warning CDX indexes created so far for such CDPs are not sorted using > the same conditions as current SVN code so new applications should > reindex. Does it mean that we need to recreate all the indexes after this change? best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Tue, 22 Sep 2009, Saulius Zrelskis wrote: Hi, > File hb_out.log is generated: > Application Memory Allocation Report - D:\TESTS\test.exe > Terminated at: 2009.09.22 13:19:25 > Total memory allocated: 107343446 bytes (913 block(s)) > Warning, memory allocated but not released: 99808005 bytes (7 block(s)) We need self contain .prg example to replicate this problem. Without it it's hard to guess what is wrong. In my tests all works correctly without memory leaks. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
On Tue, 22 Sep 2009, Przemyslaw Czerpak wrote: > We need self contain .prg example to replicate this problem. > Without it it's hard to guess what is wrong. In my tests all > works correctly without memory leaks. Ups, I see you were replying to Mindaugas message with test code. I haven't tested it yet by I guess you did not remove tables and indexes created in memory. Use dbDrob() before application exit. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12599] trunk/harbour
On Tue, 22 Sep 2009, Lorenzo Fiorini wrote: Hi, > Sorry I'm not sure I've understood correctly. > > Warning CDX indexes created so far for such CDPs are not sorted using > > the same conditions as current SVN code so new applications should > > reindex. > Does it mean that we need to recreate all the indexes after this change? I thought that ChangeLog entry is clear enough. Have you used Harbour CDP with accented or multibyte characters? If yes then you have to recreated all character indexes. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbmemio issue
Hi Mindaugas and All, My very first problem towards implementing hbmemio as a replacement for temp tables is that I'd need to create *unique* "filenames". BTW the same problem goes to hbnetio, where I sometimes need to create unique temp files (which later get renamed to final table name) How to do that? Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] build 12599 and os/2
Hi, I'm getting a strange error gcc -I. -I../../../../../include -O3 -IE:/repository/harbour/external/zlib - opngwutil.o -c ../../../pngwutil.c for %i in ( *.o ) do @echo ADDMOD %i >> __lib__.tmp ar -M < __lib__.tmp & ..\..\..\..\..\config\os2rm -f __lib__.tmp SYS1079: & was unexpected at this time. make[3]: *** [libpng.a] Error 1 The strange thing is that it seems that make is splitting a line in the wrong position. What has changed since yesterday to make this happen? Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] build 12599 and os/2
Uhmm, wait, could it be that $(ARSTRIP) is empty here and this adds an empty line at the bottom of the define create_dynlib which adds a \r\n to the generated rule? Maurilio. Maurilio Longo wrote: > Hi, > > I'm getting a strange error > > gcc -I. -I../../../../../include -O3 -IE:/repository/harbour/external/zlib > - > opngwutil.o -c ../../../pngwutil.c > for %i in ( *.o ) do @echo ADDMOD %i >> __lib__.tmp > ar -M < __lib__.tmp > & ..\..\..\..\..\config\os2rm -f __lib__.tmp > SYS1079: & was unexpected at this time. > make[3]: *** [libpng.a] Error 1 > > The strange thing is that it seems that make is splitting a line in the wrong > position. > > What has changed since yesterday to make this happen? > > Maurilio. > > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] build 12599 and os/2
On 2009 Sep 22, at 14:37, Maurilio Longo wrote: Uhmm, wait, could it be that $(ARSTRIP) is empty here and this adds an empty line at the bottom of the define create_dynlib which adds a \r\n to the generated rule? Yes, that's it. If that causes a problem, we should add some sort of guard there, or add it to the same line as $(AR) (don't know how to do this on OS/2). Anyhow it's strange because we produce empty lines in places like 'clean::' rules (but there it's directly there, not through a var). Brgds, Viktor Maurilio. Maurilio Longo wrote: Hi, I'm getting a strange error gcc -I. -I../../../../../include -O3 -IE:/repository/harbour/ external/zlib - opngwutil.o -c ../../../pngwutil.c for %i in ( *.o ) do @echo ADDMOD %i >> __lib__.tmp ar -M < __lib__.tmp & ..\..\..\..\..\config\os2rm -f __lib__.tmp SYS1079: & was unexpected at this time. make[3]: *** [libpng.a] Error 1 The strange thing is that it seems that make is splitting a line in the wrong position. What has changed since yesterday to make this happen? Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ 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] SF.net SVN: harbour-project:[12600] trunk/harbour
Revision: 12600 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12600&view=rev Author: vszakats Date: 2009-09-22 12:57:36 + (Tue, 22 Sep 2009) Log Message: --- 2009-09-22 14:57 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbmemio/tests/test.prg * contrib/hbmemio/memio.c * Internal name also renamed to HB_MEMIO (from HB_IODMEM). * source/vm/dynlibhb.c + cast. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbmemio/memio.c trunk/harbour/contrib/hbmemio/tests/test.prg trunk/harbour/source/vm/dynlibhb.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] build 12599 and os/2
Viktor,
writing it like this works ok
ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
ARSTRIP = ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
else
ARSTRIP = @$(ECHO) did not strip $(LIB_DIR)/$@
endif
:)
Maurilio.
Viktor Szakáts wrote:
>
> On 2009 Sep 22, at 14:37, Maurilio Longo wrote:
>
>> Uhmm,
>>
>> wait, could it be that $(ARSTRIP) is empty here and this adds an empty
>> line at
>> the bottom of the define create_dynlib which adds a \r\n to the
>> generated rule?
>
> Yes, that's it. If that causes a problem, we should add some sort of guard
> there, or add it to the same line as $(AR) (don't know how to do this on
> OS/2). Anyhow it's strange because we produce empty lines in places like
> 'clean::' rules (but there it's directly there, not through a var).
>
> Brgds,
> Viktor
>
>
>>
>> Maurilio.
>>
>>
>> Maurilio Longo wrote:
>>> Hi,
>>>
>>> I'm getting a strange error
>>>
>>> gcc -I. -I../../../../../include -O3
>>> -IE:/repository/harbour/external/zlib -
>>> opngwutil.o -c ../../../pngwutil.c
>>> for %i in ( *.o ) do @echo ADDMOD %i >> __lib__.tmp
>>> ar -M < __lib__.tmp
>>> & ..\..\..\..\..\config\os2rm -f __lib__.tmp
>>> SYS1079: & was unexpected at this time.
>>> make[3]: *** [libpng.a] Error 1
>>>
>>> The strange thing is that it seems that make is splitting a line in
>>> the wrong
>>> position.
>>>
>>> What has changed since yesterday to make this happen?
>>>
>>> Maurilio.
>>>
>>>
>>
>> --
>> __
>> | | | |__| Maurilio Longo
>> |_|_|_|| farmaconsult s.r.l.
>>
>>
>> ___
>> 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
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] build 12599 and os/2
On 2009 Sep 22, at 14:58, Maurilio Longo wrote:
Viktor,
writing it like this works ok
ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
ARSTRIP = ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
else
ARSTRIP = @$(ECHO) did not strip $(LIB_DIR)/$@
endif
:)
hm ;) can't we use something which doesn't produce any output?
I guess plain empty $(ECHO) will not work unless we redefine
it to GNU version.
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
On Sun, 20 Sep 2009, Szak�ts Viktor wrote:
[...]
Usually in system installation we have existing structure like:
/bin - with executable files, one of PATH dirs
we should not use any subdirectories here
/lib - with shared libraries, one of system library dirs
we can use subdirectory for static libraries and
it's even suggested to reduce name conflicts
but native shared library have to be in this
localization
/include - with header files, we can and should use subdir
for our own header files
/share/man - with man files - sub dirs with strict meaning and
naming convention. Sometimes it's without share
/man (i.e. in /usr/local)
/share/doc - with non man documentation, we should use subdir
/etc - with configuration files, if necessary it's
possible to use subdirs with the exception to
/usr which stores configuration files in /etc
FHS suggests also to use /etc/opt and /etc/local
for configurations files from /opt /usr/local
For applications which can be globally accessed it's suggested to move
configuration files into '/etc' directory. It helps in creating backups
but also in locating configuration files by other programs bound with
given application, i.e. in our case we may talk about final user
applications compiled by Harbour which may look for some system global
Harbour configuration files, i.e. now /etc/harbour/hb-charmap.def which
is used optionally by some GTs like GTCRS or GTTRM (for details look at
source/rtl/gtcrs/hb-charmap.def, I plan to introduce also hb-keymap.def
and hb-termmap.def for GTTRM what should allow to configure some unknown
for GTTRM terminals by users or system admins) and I would like to keep
/etc/harbour as default global harbour configuration directory though
for packages installed in '/opt' FHS suggests to use '/etc/opt'.
It's not easy to create rules which can follow exactly different
distribution policy so we should give an interface to set each of the
above directory separately. It means that we have to introduce yet
two new envvars for man and configurations files, i.e. HB_MAN_INSTALL
and HB_ETC_INSTALL or HB_CNF_INSTALL.
Building RPM packages we have predefined macros like %{_bindir}, %{_libdir},
%{_includedir}, %{_mandir}, %{_sysconfdir}, %{_defaultdocdir}, ... which
can be used to set our own HB_*_INSTALL variables to suggested system
directories without touching HB_INSTALL_PREFIX so it's not a problem.
We do not use autoconf so we have to chose sth ourselves for 'manual'
installation using only HB_INSTALL_PREFIX. We have to remember also
that at runtime hbmk2 may need to replicate some parts of our detection
logic.
Here are 4 system wide installations which can be used in different
*nixes and try to confirm FHS as close as possible.
'->' means soft link,
1. FHS2.3 compliant localization for add-on applications:
=
/opt/
/harbour/
/bin/
/lib/
[//
]
[///
]
/include/
[//
]
/share/
/man/
/man1/
.1
/doc/
[//
]
/etc -> /etc/harbour
/etc/
/harbour/
/etc/
/opt/ (if exists)
/harbour -> /etc/harbour
if /opt/bin exists then we should create in this directory soft links
to executable files in /opt/harbour/bin
if /opt/lib exists then we should create in this directory soft links
to harbour shared libraries in /opt/harbour/lib
if /opt/man/man1 exists then we should create in this directory soft links
to harbour shared libraries in /opt/harbour/share/man/man1
2. FHS2.3 compliant localization for distribution applications:
===
/usr/
/bin/
/lib/
/harbour/
[//
[///
]
/include/
/harbour/
[//
]
/share/
/man/
/man1/
.1
/doc/
/harbour/
[//
]
/etc/
/harbour/
In some systems instead of /usr/share/doc/harbour we should use
/usr/share/doc/packages/harbour.
Such localizatio
Re: [Harbour] build 12599 and os/2
On Tue, 22 Sep 2009, Szak�ts Viktor wrote:
>> writing it like this works ok
>> ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
>> ARSTRIP = ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
>> else
>> ARSTRIP = @$(ECHO) did not strip $(LIB_DIR)/$@
>> endif
> hm ;) can't we use something which doesn't produce any output?
> I guess plain empty $(ECHO) will not work unless we redefine
> it to GNU version.
What about removing ARSTRIP from create_library and using sth like:
ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
ARSTRIP = & ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
endif
AR_RULE = $(create_library) $(ARSTRIP) & $(RM) __lib__.tmp
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12593] trunk/harbour
Hi, Przemyslaw Czerpak wrote: Ups, I see you were replying to Mindaugas message with test code. I haven't tested it yet by I guess you did not remove tables and indexes created in memory. Use dbDrob() before application exit. I'll add automatic memory file system cleanup on application exit. Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] build 12599 and os/2
Viktor Szakáts wrote: > I guess plain empty $(ECHO) will not work unless we redefine > it to GNU version. > Correct, OS/2 echo gives a echo is OFF (or ON) when called without parameters Maurilio. > Brgds, > Viktor > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] build 12599 and os/2
Przemyslaw,
Przemyslaw Czerpak wrote:
>
> What about removing ARSTRIP from create_library and using sth like:
>
>ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
> ARSTRIP = & ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
>endif
>
>AR_RULE = $(create_library) $(ARSTRIP) & $(RM) __lib__.tmp
>
ok, works with ARSTRIP empty, I'll try next to see if it works with it defined
as well.
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
Hi Przemek, Just some quick reaction, I have to go now. and HB_ETC_INSTALL or HB_CNF_INSTALL. What is the difference between ETC and CNF? If possible IMO we should not differentiate between types of config files. /lib/ [// ] [/// ] I suppose 'contrib' counts as 'addon'. IMO and if system rules allow it, we should put native libs also under plat/cc structure, since generally speaking we may support multiple compilers with incompatible lib formats (like watcom and gcc, or anything else in the future). Plus there must a plat/cc structure also below each addon. The shard library naming convention === @ - softlink * - hardlink @. -> @.. -> @... -> * is library name prefix, 'lib' in supported by Harbour *nix systems is base name, 'harbour' in our case is used to mark new or alternative branches, we are using 'mt' to mark alternative libraries with MT support. is library extension, 'dylib' in Darwin, 'sl' in HP-UX, 'so' in others. , , - version numbers (i.e. 2.0.0 for current SVN). i.e.: @libharbour.so -> @libharbour.so.2 -> @libharbour.so.2.0 -> *libharbour.so.2.0.0 Real/suggested usage in supported *nixes: Linux, Solaris, Haiku, NetBSD: @. -> * @.. -> * FreeBSD (some packages use Linux like form): @. -> *.. OpenBsd: *... Darwin??? On darwin the current naming seems to be the accepted one, although some libs use '-' to separate name form version no. [ I've just browsed my /usr/lib dir for above conclusion, so I don't know what's the official standpoint here, anyway I'd assumed the extension is fixed. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmemio issue
Hi, Viktor Szakáts wrote: My very first problem towards implementing hbmemio as a replacement for temp tables is that I'd need to create *unique* "filenames". BTW the same problem goes to hbnetio, where I sometimes need to create unique temp files (which later get renamed to final table name) How to do that? In Windows and real file system I use GetTempFileName() WinAPI, but I do not like this way. Some trivial solutions like HB_TTOS(HB_DATETIME()) + LTRIM(STR(HB_RANDOM(), 12, 0)) usually is also acceptable, but it would be nice to have more beautiful way to do that. Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12601] trunk/harbour
Revision: 12601 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12601&view=rev Author: snaiperis Date: 2009-09-22 14:09:59 + (Tue, 22 Sep 2009) Log Message: --- 2009-09-22 17:10 UTC+0300 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) * contrib/hbmemio/memio.c + added cleanup on application exit * some warnings pacified Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbmemio/memio.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OS/2 .dll
Hi, Ok, I'm able to build .dlls on OS/2 using gcc and they work since build 12599 (I've tested hbtest.exe only, but if it works everything should work as well). I still have a question though: on OS/2 .dll names are restricted to 8.3 only. So, how can I name harbour .dlls? Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
On Tue, 22 Sep 2009, Szak�ts Viktor wrote: Hi, > Just some quick reaction, I have to go now. >> and HB_ETC_INSTALL or HB_CNF_INSTALL. > What is the difference between ETC and CNF? > If possible IMO we should not differentiate between > types of config files. These are my propositions for our new envvar name. Chose one of them. Personally I preffer the 1-st one. >>/lib/ >> >> [// >> ] >> [/// >>] > I suppose 'contrib' counts as 'addon'. No, I was thinking about 3-rd party packages which may use many libraries. Contrib libraries only in some chosen cases if for some reasons we decide they should be separated. Please also note that such subdirectory exists in include. I do not think that people will like to update existing code and modify paths in #include directives but for new 3-rd party / add-on libraries it seems to be very interesting proposition which allows to resolve possible name conflicts by using directory with library name in included files, i.e. instead of: #include user can use: #include or use -I switch to give higher priority to some alternative files overloading our own ones. > IMO and if system rules allow it, we should put native > libs also under plat/cc structure, since generally speaking > we may support multiple compilers with incompatible lib formats > (like watcom and gcc, or anything else in the future). > Plus there must a plat/cc structure also below each addon. I do not think it's necessary. The default platform libraries always have to exists and shared libraries from this dir have to be linked with system library directory so we can store them without plat/cc what also nicely shows which binaries are platform native ones. Please also remember that /// is only some type of proposition not suggested form because it's not enough. In some cases it will be necessary to use sth different, i.e. I can have only linux/gcc builds but using different ABI or CPUs. The problem is how to bound such different configurations with hbmk2. For me ideal situation will be single parameter which allows me to chose library subdirectory and hbmk.cfg file, i.e. working on FreeBSD I'm using -arch=linux-x86_64 and hbmk2 sets default library directory to /lib/linux-x86_64/ and then looks in this directory for hbmk.cfg file to read default configuration. FHS allows to store some type of configuration/data files used in readonly mode in 'lib' directories. >> The shard library naming convention >> === >> @ - softlink >> * - hardlink >> >> @. -> >> @.. -> >> @... -> >> * >> >>is library name prefix, >> 'lib' in supported by Harbour *nix systems >>is base name, 'harbour' in our case >>is used to mark new or alternative branches, we are using >> 'mt' to mark alternative libraries with MT support. >>is library extension, >> 'dylib' in Darwin, >> 'sl' in HP-UX, >> 'so' in others. >> , , - version numbers (i.e. 2.0.0 for current SVN). >> >> i.e.: >> @libharbour.so -> >> @libharbour.so.2 -> >> @libharbour.so.2.0 -> >> *libharbour.so.2.0.0 >> >> Real/suggested usage in supported *nixes: >> Linux, Solaris, Haiku, NetBSD: >> @. -> * >> @.. -> >> * >> FreeBSD (some packages use Linux like form): >> @. -> >> *.. >> OpenBsd: >> *... >> >> Darwin??? > On darwin the current naming seems to be the accepted one, > although some libs use '-' to separate name form version no. > [ I've just browsed my /usr/lib dir for above conclusion, > so I don't know what's the official standpoint here, anyway > I'd assumed the extension is fixed. ] Thanks for the info, so it's in form like: @. -> @.. -> @... -> * which is not compatible with other *nixes. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2 .dll
On Tue, 22 Sep 2009, Maurilio Longo wrote: Hi, > Ok, I'm able to build .dlls on OS/2 using gcc and they work since build 12599 > (I've tested hbtest.exe only, but if it works everything should work as well). Thank you very much. > I still have a question though: on OS/2 .dll names are restricted to 8.3 only. > So, how can I name harbour .dlls? harbour.dll :-) BTW now we have GNU make for OS2 working with long internal definitions so I think we should remove FOR %I command loops from config/os2/gcc.cf and config/common/watcom.cf added as workaround for this problems and restore previous versions. Please remember that these rules causes that old files in given directory are added to library without any validation if they belongs to given library or not, i.e. they forced other workarounds to not add hbpp.obj to hbpp library. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2 .dll
Przemyslaw Czerpak wrote: >> I still have a question though: on OS/2 .dll names are restricted to 8.3 >> only. >> So, how can I name harbour .dlls? > > harbour.dll :-) Sure, the st one, but the mt? I was thinking about harbor.dll and harbormt.dll, that is with the american spelling of harbour. Otherwise I could use harbour and harbourm. > > BTW now we have GNU make for OS2 working with long internal > definitions so I think we should remove FOR %I command loops > from config/os2/gcc.cf and config/common/watcom.cf added as > workaround for this problems and restore previous versions. > Please remember that these rules causes that old files in given > directory are added to library without any validation if they > belongs to given library or not, i.e. they forced other > workarounds to not add hbpp.obj to hbpp library. > Sure; I'll update mine as soon as I've resolved the naming issue, then we can try with different rules. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmemio issue
Viktor Szakáts wrote: My very first problem towards implementing hbmemio as a replacement for temp tables is that I'd need to create *unique* "filenames". BTW the same problem goes to hbnetio, where I sometimes need to create unique temp files (which later get renamed to final table name) How to do that? In Windows and real file system I use GetTempFileName() WinAPI, but I do not like this way. Some trivial solutions like HB_TTOS(HB_DATETIME()) + LTRIM(STR(HB_RANDOM(), 12, 0)) usually is also acceptable, but it would be nice to have more beautiful way to do that. Yes, with real FS it's okay with our APIs, but such date/time/random based solution aren't rock solid (uniqueness isn't guaranteed), so indeed something better would be good. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2 .dll
Ok, I'm able to build .dlls on OS/2 using gcc and they work since build 12599 (I've tested hbtest.exe only, but if it works everything should work as well). I still have a question though: on OS/2 .dll names are restricted to 8.3 only. So, how can I name harbour .dlls? harbour.dll harbourm.dll Like in MS-DOS. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] build 12599 and os/2
Hi Przemek,
On Tue, 22 Sep 2009, Szak�ts Viktor wrote:
writing it like this works ok
ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
ARSTRIP = ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
else
ARSTRIP = @$(ECHO) did not strip $(LIB_DIR)/$@
endif
hm ;) can't we use something which doesn't produce any output?
I guess plain empty $(ECHO) will not work unless we redefine
it to GNU version.
What about removing ARSTRIP from create_library and using sth like:
ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
ARSTRIP = & ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
endif
AR_RULE = $(create_library) $(ARSTRIP) & $(RM) __lib__.tmp
Would this work also with MS-DOS shells? (we have the same
problem there probably)
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] MS SQL and ODBC.
I'm try to connect to MS SQL Serwer with code :
*
Local rdd
Cls
rdd := RDDSETDEFAULT( "SQLMIX" )
RDDINFO( 1001, { "ODBC", "Driver={SQL
Server};Server=MSSQL.alias.firma;Database=FIRMY;Trusted_Connection=yes;"
} )
DBUSEAREA( .T., "SQLMIX", "select ID_KLIENT, NAZWA from KLIENT where
nazwa like '%ZAKLAD%'", "CBKI")
RDDSETDEFAULT( rdd)
? Alias()
? "DB struct:", HB_VALTOEXP( DBSTRUCT() )
*
And app crash in dbusearea() with :
oErr:severity_ 2
oErr:osCode___ 65527
oErr:subsystem()__SDDODBC
oErr:subCode__ 1902
oErr:description__Invalid field type
oErr:filename_
oErr:operationselect ID_KLIENT, NAZWA from KLIENT where nazwa like
'%ZAKLAD%'
oErr:genCode__32
oErr:args_U
Invalid field type is NAZWA.
I can open this select with :
"select id_klient from klient where "
Id_klient is numeric, nazwa is varchar.
Can anybody check this ?
And another question : why I must change default rdd before :
RDDINFO( 1001, { "ODBC", "Driv ...
When I don't make this, app is crashed.
Regards,
Marek Horodyski
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12602] trunk/harbour
Revision: 12602 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12602&view=rev Author: vszakats Date: 2009-09-22 16:52:31 + (Tue, 22 Sep 2009) Log Message: --- 2009-09-22 18:51 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg * config/global.mk ! Changed .dll names for OS/2 to be the same as in MS-DOS: harbour/harbourm. (.dll names in OS/2 are limited to 8.3) * config/dos/djgpp.mk ! Attempt to fix empty line problem when stripping isn't requested. Something better would be good here. * config/os2/gcc.mk ! Fixed empty line problem when stripping isn't requested. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/dos/djgpp.mk trunk/harbour/config/global.mk trunk/harbour/config/os2/gcc.mk 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 Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] MS SQL and ODBC.
Hi,
Horodyski Marek (PZUZ) wrote:
I'm try to connect to MS SQL Serwer with code :
> And app crash in dbusearea() with :
oErr:severity_ 2
oErr:osCode___ 65527
oErr:subsystem()__SDDODBC
oErr:subCode__ 1902
oErr:description__Invalid field type
oErr:filename_
oErr:operationselect ID_KLIENT, NAZWA from KLIENT where nazwa like
'%ZAKLAD%'
oErr:genCode__32
oErr:args_U
Invalid field type is NAZWA.
I can open this select with :
"select id_klient from klient where "
Id_klient is numeric, nazwa is varchar.
Can anybody check this ?
I can not check because I do not have MS SQL, but to make error more
informative, I've passed field type to :osCode. You error log shows it
is value 65527. Since it is USHORT value, it can also mean -9, if it is
signed. I can not find nor -9 neither 65527 field type sql.h. Varchar is
defined equal to 12. More tests/docs required.
And another question : why I must change default rdd before :
RDDINFO( 1001, { "ODBC", "Driv ...
When I don't make this, app is crashed.
Because RDDINFO() uses default RDD by default. You can use 3rd parameter
to specify RDD, if you do not to change default.
Regards,
Mindaugas
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
Just some quick reaction, I have to go now. and HB_ETC_INSTALL or HB_CNF_INSTALL. What is the difference between ETC and CNF? If possible IMO we should not differentiate between types of config files. These are my propositions for our new envvar name. Chose one of them. Personally I preffer the 1-st one. I'd also prefer ETC. /lib/ [// ] [/// ] I suppose 'contrib' counts as 'addon'. No, I was thinking about 3-rd party packages which may use many libraries. Contrib libraries only in some chosen cases if for some reasons we decide they should be separated. I think it would go rather sooner than later as it starts to become a problem to manage collisions and it's an important step towards making contribs fully independent from core and each other. Please also note that such subdirectory exists in include. That's also needed, so it's good. I do not think that people will like to update existing code and modify paths in #include directives but for new 3-rd party / add-on libraries it seems to be very interesting proposition which allows to resolve possible name conflicts by using directory with library name in included files, i.e. instead of: #include user can use: #include or use -I switch to give higher priority to some alternative files overloading our own ones. This is also good, but I was thinking about something a little different. When using hbmk2, it's now possible to refer to a given "addon" (or contrib), via its .hbc file. Now in this .hbc file there are settings which automatically setup required additional lib and inc paths for that given component. It's possible to setup simple .hbc search rules, so that they are automatically found if placed according to some rules. It works quite beautifully on non-*nix, but it doesn't when libs/headers/docs are scattered around the system to different base dirs. Basically I'm looking for a way to implement something similar, but for *nix systems. Think of one contrib or addon as a "Harbour package" with libs, headers, docs, examples, whatnot. Something like we have now under /contrib/*/ dirs. It would be nice to handle them as one package even in 'localized' form. Or at least provide it as an option. IMO and if system rules allow it, we should put native libs also under plat/cc structure, since generally speaking we may support multiple compilers with incompatible lib formats (like watcom and gcc, or anything else in the future). Plus there must a plat/cc structure also below each addon. I do not think it's necessary. The default platform libraries always have to exists and shared libraries from this dir have to be linked with system library directory so we can store them without plat/cc what also nicely shows which binaries are platform native ones. Please also remember that /// is only some type of proposition not suggested form because it's not enough. In some cases it will be necessary to use sth different, i.e. I can have only linux/gcc builds but using different ABI or CPUs. The problem is how to bound such It's called build name (HB_BUILD_NAME), and can be added as a 3rd level above platform / compiler. It doesn't change fundamentals. We can give a somewhat more distinctive name though. different configurations with hbmk2. For me ideal situation will be single parameter which allows me to chose library subdirectory and hbmk.cfg file, I think for most users the best would be if they'd only choose the target 'platform / compiler / name' and hbmk2 would automatically know where to look for libs for that specific target. i.e. working on FreeBSD I'm using -arch=linux-x86_64 and hbmk2 sets default library directory to /lib/linux-x86_64/ and then looks in this directory for hbmk.cfg file to read default configuration. FHS allows to store some type of configuration/data files used in readonly mode in 'lib' directories. That part is okay, but for me the notion of "native" isn't something I like. In hbmk2 I don't really want to deal with what is native and handle it differently than any other targets. It creates all sorts of problems. (f.e. you have to move around libs when copying a Harbour installation to another system, or after you've upgraded your system to another ABI, f.e from 32-bit to 64-bit, given that 32-bit exes would otherwise still run on 64-bit - as on Darwin f.e.) We should also consider multi-host builds (similar to watcom compiler), where we provide tools for multiple ABI or platforms installed on one system. In this case which set of libs should be selected as "native" ones? and how non-native tools would be able to decide where to find those libs? Note that such multi-host build is something I plan for non-*nix, so we should possible try to support it on non-*nix. I can even imagine a watcom-like layout which just works on multiple operating systems if shared from
Re: [Harbour] SF.net SVN: harbour-project:[12601] trunk/harbour
Hi, Now in previous sample dbDrop() returns .F. for Mem I/O. Is this expected? Best regards, Saulius ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] build 12599 and os/2
I think, I'm still testing, that ARSTRIP has to start with an '&' which is
command separator in OS/2.
Maurilio.
Maurilio Longo wrote:
> Przemyslaw,
>
> Przemyslaw Czerpak wrote:
>> What about removing ARSTRIP from create_library and using sth like:
>>
>>ifneq ($(filter $(HB_BUILD_STRIP),all lib),)
>> ARSTRIP = & ${HB_CCPATH}${HB_CCPREFIX}strip -S $(LIB_DIR)/$@
>>endif
>>
>>AR_RULE = $(create_library) $(ARSTRIP) & $(RM) __lib__.tmp
>>
> ok, works with ARSTRIP empty, I'll try next to see if it works with it defined
> as well.
>
> Maurilio.
>
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Possible OLE bug
Viktor,
This code in olecore.c (hb_oleVariantToItem()) fails if the string has
embedded zeroes, as hb_itemPutCPtr() uses strlen() to calculate the
string length.
case VT_BSTR:
{
char* szString = WideToAnsi( pVariant->n1.n2.n3.bstrVal );
hb_itemPutCPtr( pItem, szString );
break;
}
case VT_BSTR | VT_BYREF:
{
char* szString = WideToAnsi( *pVariant->n1.n2.n3.pbstrVal );
hb_itemPutCPtr( pItem, szString );
break;
}
We appreciate your comments, thanks
best regards,
Antonio
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error building last SVN
Hi Viktor, I get this error building last SVN with mingw (msys + mingw on Vista) 2009-09-22 18:51 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) ! Building Harbour 2.0.0beta3 from source - http://www.harbour-project.org ! MAKE: make 3.81 /bin/sh clean install ! HB_USER_CFLAGS: -DHB_LEGACY_OFF -DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC -DHB_GC_AUTO -DHB_HASH_MSG_ITEMS ! HB_INSTALL_PREFIX: /j/cvs/harbour_mingw ! HB_BUILD_DLL: no ! HB_BUILD_SHARED: no ! HB_BUILD_DEBUG: no ! HB_HOST_PLAT: win (x86) HB_SHELL: sh ! HB_PLATFORM: win (x86) (autodetected) ! HB_COMPILER: mingw ! Component: 'zlib' found in /j/cvs/harbourSVN_trunk/external/zlib (local) ! Component: 'pcre' found in /j/cvs/harbourSVN_trunk/external/pcre (local) ! Component: 'openssl' not found ! Component: 'gpm' not supported on win platform ! Component: 'slang' not found ! Component: 'curses' not found ! Component: 'x11' not found ! Component: 'wattcp/watt-32' not supported on win platform config/global.mk:1421: *** missing `endif'. Stop. Best Regards, Francesco ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12599] trunk/harbour
On Tue, Sep 22, 2009 at 1:27 PM, Przemyslaw Czerpak wrote: > I thought that ChangeLog entry is clear enough. > Have you used Harbour CDP with accented or multibyte characters? > If yes then you have to recreated all character indexes. Sorry but I have multi-millions records tables, I need to carefully plan the rebuild indexes. I use codepages with accented ( at least we call them in such way ) but you didn't list them in the msg. Here is my setup: REQUEST HB_CODEPAGE_ITISB REQUEST HB_CODEPAGE_ITISO REQUEST HB_CODEPAGE_IT850 REQUEST HB_UTF8TOSTR HB_SETCODEPAGE( __CP_HOST__ ) HB_SETTERMCP( __CP_TERM__, __CP_HOST__, TRUE ) I also still have C53b/Fivewin apps that work on the same files. Not at the same site, Harbour apps are the next version of the same set of applications. Do I need to recreate the indexes when I switch between C53b/DBFCDX and Harbour? best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Which pelles c to use?
Hi, Which version of 32bits Pelles C can I use ? 5.xx 6.xx? Brgs, José Luis Capel ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12599] trunk/harbour
On Tue, 22 Sep 2009, Lorenzo Fiorini wrote: > > I thought that ChangeLog entry is clear enough. > > Have you used Harbour CDP with accented or multibyte characters? > > If yes then you have to recreated all character indexes. > Sorry but I have multi-millions records tables, I need to carefully > plan the rebuild indexes. > I use codepages with accented ( at least we call them in such way ) Sorry it's terminology/translation problem, probably Phil Krylov is the best person to define precis names but for sure not me not me. I thought about sorting method and our CPs definitions. Any of IT* CPs has marked accented characters. To reduce confusions I listed Harbour CPs which are defined with accented characters and multibyte characters. > but you didn't list them in the msg. > Here is my setup: >REQUEST HB_CODEPAGE_ITISB >REQUEST HB_CODEPAGE_ITISO >REQUEST HB_CODEPAGE_IT850 None of above CPs uses accented characters which are not sorted using simple byte weight just like normal letters. They also do not use multibyte characters so nothing will change for them just like for most of other CPs. >REQUEST HB_UTF8TOSTR >HB_SETCODEPAGE( __CP_HOST__ ) >HB_SETTERMCP( __CP_TERM__, __CP_HOST__, TRUE ) > I also still have C53b/Fivewin apps that work on the same files. Not > at the same site, Harbour apps are the next version of the same set of > applications. > Do I need to recreate the indexes when I switch between C53b/DBFCDX > and Harbour? The modification was only for CPs which cannot be Clipper compatible because Clipper supports only simply byte weight sorting. Any Harbour CPs using multibyte characters or accented characters which are not sorted using the same rules as for any other character (simple character weight) were not Clipper compatible and will never be so this modification did not change anything in Clipper compatibility area. Things which were not compatible because Clipper does not support extended national sorting are still not compatible. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12599] trunk/harbour
On Tue, Sep 22, 2009 at 9:27 PM, Przemyslaw Czerpak wrote: > Sorry it's terminology/translation problem, probably Phil Krylov is > the best person to define precis names but for sure not me not me. I guessed it, sorry if I was "pedantic" :) Using iso8859-15 terminology we call "accented" a char like "E9/233 LATIN SMALL LETTER E WITH ACUTE". best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12603] trunk/harbour
Revision: 12603 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12603&view=rev Author: vszakats Date: 2009-09-22 20:09:15 + (Tue, 22 Sep 2009) Log Message: --- 2009-09-22 22:05 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * config/global.mk ! Typo Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/global.mk This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12603] trunk/harbour
Hi Viktor, Il 22/09/2009 22.09, vszak...@users.sourceforge.net ha scritto: Revision: 12603 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12603&view=rev Author: vszakats Date: 2009-09-22 20:09:15 + (Tue, 22 Sep 2009) Thank you. Best Regards, Francesco ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12604] trunk/harbour
Revision: 12604 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12604&view=rev Author: snaiperis Date: 2009-09-22 21:11:13 + (Tue, 22 Sep 2009) Log Message: --- 2009-09-23 00:13 UTC+0300 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt) * contrib/hbmemio/memio.c ! fixed typo in hb_memfsDelete() Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbmemio/memio.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12601] trunk/harbour
Saulius Zrelskis wrote: Now in previous sample dbDrop() returns .F. for Mem I/O. Is this expected? Hi, should be fixed now. Thank You. Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: RE: [Harbour] "set deleted on"not workin anyore from last CVS
On Mon, 21 Sep 2009, J. Lefebvre wrote:
Hi,
> Using an older ADSRDD do not solve the problem . seem to be higher in RDD
> structure.
>> Compiling the very last cvs version I discovered 'SET DELETED ON' do not
>> work anymore (using ADSRDD).
>> I see some modification around the 15-09-2009.
>> Any idea ?
I do not see any problems in ADS RDD behavior. SET DELETED ON/OFF works
as expected. I used code below to make tests.
If you think that sth does not work as it should then please create
self contain code example like the one below so we can see what's
the problem (if any).
best regards,
Przemek
/*** tst.prg ***/
request ADS
proc main()
AdsSetServerType( 1 )
rddSetDefault("ADSCDX")
dbCreate( "_tst_", {{"F1","C",10,0},{"F2","D",8,0}} )
use _tst_
while lastrec() < 10
dbAppend()
if recno() % 3 != 0
dbDelete()
endif
enddo
? "set delete on"
set delete on
dbEval({||qout(recno())})
? "set delete off"
set delete off
dbEval({||qout(recno())})
close
wait
? "reuse"
use _tst_
? "set delete off"
set delete off
dbEval({||qout(recno())})
? "set delete on"
set delete on
dbEval({||qout(recno())})
close
wait
return
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Possible OLE bug
Proposed change:
case VT_BSTR:
{
char* szString = WideToAnsi( pVariant->n1.n2.n3.bstrVal );
hb_itemPutCLPtr( pItem, szString, WideCharToMultiByte(
CP_ACP, 0, pVariant->n1.n2.n3.bstrVal, -1, NULL, 0, NULL, NULL ) );
break;
}
best regards
Antonio
2009/9/22 Antonio Linares :
> Viktor,
>
> This code in olecore.c (hb_oleVariantToItem()) fails if the string has
> embedded zeroes, as hb_itemPutCPtr() uses strlen() to calculate the
> string length.
>
> case VT_BSTR:
> {
> char* szString = WideToAnsi( pVariant->n1.n2.n3.bstrVal );
> hb_itemPutCPtr( pItem, szString );
> break;
> }
>
> case VT_BSTR | VT_BYREF:
> {
> char* szString = WideToAnsi( *pVariant->n1.n2.n3.pbstrVal );
> hb_itemPutCPtr( pItem, szString );
> break;
> }
>
> We appreciate your comments, thanks
>
> best regards,
>
> Antonio
>
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Possible OLE bug
To all:
My dev PC (WinXP) died tonight, so don't expect frequent
SVN updates until the situation gets resolved.
I've also pulled Oracle access for the time being, pls
tell if it's needed and I try to make it online.
BTW, the patch looks wrong to me as WideToAnsi() isn't
passed any length data, so the conversion will cut the
string at the first zero byte and garbage will be
returned after that point by next hb_itemPutCLPtr()
call. Somehow data length should be pulled from pVariant
structure.
Brgds,
Viktor
On 2009 Sep 23, at 02:25, Antonio Linares wrote:
Proposed change:
case VT_BSTR:
{
char* szString = WideToAnsi( pVariant->n1.n2.n3.bstrVal );
hb_itemPutCLPtr( pItem, szString, WideCharToMultiByte(
CP_ACP, 0, pVariant->n1.n2.n3.bstrVal, -1, NULL, 0, NULL, NULL ) );
break;
}
best regards
Antonio
2009/9/22 Antonio Linares :
Viktor,
This code in olecore.c (hb_oleVariantToItem()) fails if the string
has
embedded zeroes, as hb_itemPutCPtr() uses strlen() to calculate the
string length.
case VT_BSTR:
{
char* szString = WideToAnsi( pVariant->n1.n2.n3.bstrVal );
hb_itemPutCPtr( pItem, szString );
break;
}
case VT_BSTR | VT_BYREF:
{
char* szString = WideToAnsi( *pVariant->n1.n2.n3.pbstrVal );
hb_itemPutCPtr( pItem, szString );
break;
}
We appreciate your comments, thanks
best regards,
Antonio
___
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: Possible OLE bug
On Wed, 23 Sep 2009, Szak�ts Viktor wrote: > To all: > My dev PC (WinXP) died tonight, so don't expect frequent > SVN updates until the situation gets resolved. Ups, hope you will resolve it soon. > BTW, the patch looks wrong to me as WideToAnsi() isn't > passed any length data, so the conversion will cut the > string at the first zero byte and garbage will be > returned after that point by next hb_itemPutCLPtr() > call. Somehow data length should be pulled from pVariant > structure. Better check current Harbour SVN code. He simply asked about help in code he copied from old Harbour SVN repository and is distributing himself. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12601] trunk/harbour
Hi, Mindaugai > should be fixed now. Thank You. Nooo, Thank You :) Excellent job ! Best regards, Saulius ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
