[Harbour] Errors in latest SVN
Error E2140 ../../../hbcom.c 1646: Declaration is not allowed here in function hb_comSend Error E2140 ../../../hbcom.c 1705: Declaration is not allowed here in function hb_comRecv EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14461] trunk/harbour
Hi Przemek, > Log Message: > --- > 2010-05-12 02:26 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/contrib/hbct/dummy.c >* removed dummy CT3 serial communication functions >; such files with dummy functions introduces very serious problems for > user code because they do not respect original module granularity > effectively breaking overloading only chosen functions so it breaks > also some real Clipper code. This file is not included in hbct library, so it won't cause any such harm. It's mere a place where we can track what's implemented and what's not. 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:[14461] trunk/harbour
Przemek,
What is the different between this and the functions we have in
contrib/hbtpathy?
>OS2 builds:
> - discard card is not supported
Is this the character to place when erroneous data is received?
I don't have original OS/2 headers, but in my (VERY) old OS/2 program I had
this working:
typedef struct
{
WORDwrite_tmo ;/* Write timeout in 10 ms ( 0 - 10, 1 - 20 ) */
WORDread_tmo ;/* Read timeout in 10 ms ( 0 - 10, 1 - 20 ) */
BYTEflag1 ;
BYTEflag2 ;
BYTEflag3 ;
BYTEerr_rep;
BYTEbrk_rep;
BYTExon_char ;
BYTExoff_char ;
} DCBINFO ;
DCBINFO dcb ; /* Device control block information */
/* ... after port is opened */
if ( !(nErr = DOSDEVIOCTL ((BYTE far*) &dcb, NULL, 0x73, 1,
pSio->shandle)))
{
dcb.read_tmo = zcom_readtmo ; /* 10 ms */
dcb.write_tmo = zcom_writetmo ; /* 10 ms */
dcb.flag1 = 0 ;
dcb.flag2 = 4|8 ;/* Error repl | 0-stripp */
dcb.flag3 = 2 ;/* Timeout proceccing bits */
dcb.err_rep = 'X';/* Error replace char */
dcb.brk_rep = 0 ;/* Break replace char */
if ( !(nErr = DOSDEVIOCTL (NULL, (BYTE far*) &dcb, 0x53, 1,
pSio->shandle)))
{
/* set baud and other staff ... */
}
}
Chen.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error Building SVN 2010-17:24 18:23 UTC-0800
12.05.2010 5:09, Mario H. Sabado написав(ла): Hi Przemek, I have encountered building latest Harbour SVN with the following error. I'm using WinXP/BCC58. - bcc32.exe -I. -I../../../../../include -q -tWM -CP437 -w -Q -w-sig- -d -6 -O2 -OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF -DHB_HAS_PCRE -ID:/harbour/external/pcre -DPCRE_STATIC -DHB_HAS_ZLIB -ID:/harbour/external/zlib -I"C:\BCC58\BIN\..\Include" -DUNICODE -ohbcom.obj -c ../../../hbcom.c ../../../hbcom.c: Error E2140 ../../../hbcom.c 1646: Declaration is not allowed here in function hb_comSend Error E2140 ../../../hbcom.c 1705: Declaration is not allowed here in function hb_comRecv *** 2 errors in Compile *** win-make[3]: *** [hbcom.obj] Error 1 win-make[2]: *** [descend] Error 2 win-make[1]: *** [rtl.inst] Error 2 win-make: *** [src.inst] Error 2 Thanks and best regards, Mario ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour With mingw all ok. C:\dev\harbour\bin\>harbour.exe -build Harbour 2.1.0beta1 (Rev. 14463) Copyright (c) 1999-2010, http://www.harbour-project.org/ Harbour Build Info --- Version: Harbour 2.1.0beta1 (Rev. 14463) Compiler: MinGW GNU C 3.4.5 (32-bit) Platform: Windows XP 5.1.2600 Service Pack 3 PCode version: 0.3 ChangeLog last entry: 2010-05-12 02:26 UTC+0200 Przemyslaw Czerpak (druzus/at/pr iv.onet.pl) ChangeLog ID: ChangeLog 14463 2010-05-12 01:24:41Z vouchcac Built on: May 12 2010 09:06:00 Build options: (Clipper 5.3b) (Clipper 5.x undoc) Regards, Alexey Myronenko ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Question about Preprocessor
Hi I am curious about this need. Can you provide some useful example? []'s Maniero 2010/5/11 CarozoDeQuilmes > Hi, when I put the following #translate in my program always convert the > parameter myparm to literal "myparm". It is good for me. > > Sample: > > #translate MYEXAMPLE ; > => ; >MYNEWEXAMPLE <(myparm)> > > function main() > MYEXAMPLE "cParm" > MYEXAMPLEcParm > Return .T. > > Code Generated: > > function main() > > MYNEWEXAMPLE "cParm" > > MYNEWEXAMPLE "cParm" > > Return .T. > > The question is: how make it in reverse ? (convert literal or variable to > variable) > > #translate MYEXAMPLE ; > => ; >MYNEWEXAMPLE > > function main() > MYEXAMPLE "cParm" > MYEXAMPLEcParm > Return .T. > > Generate: > > function main() > > MYNEWEXAMPLE cParm > > MYNEWEXAMPLE cParm > > Return .T. > > Thanks in advance > -- > CdQ > > ___ > 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] Error Building SVN 2010-17:24 18:23 UTC-0800
Hi Przemek, I have encountered building latest Harbour SVN with the following error. I'm using WinXP/BCC58. - bcc32.exe -I. -I../../../../../include -q -tWM -CP437 -w -Q -w-sig- -d -6 -O2 -OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF -DHB_HAS_PCRE -ID:/harbour/external/pcre -DPCRE_STATIC -DHB_HAS_ZLIB -ID:/harbour/external/zlib -I"C:\BCC58\BIN\..\Include" -DUNICODE -ohbcom.obj -c ../../../hbcom.c ../../../hbcom.c: Error E2140 ../../../hbcom.c 1646: Declaration is not allowed here in function hb_comSend Error E2140 ../../../hbcom.c 1705: Declaration is not allowed here in function hb_comRecv *** 2 errors in Compile *** win-make[3]: *** [hbcom.obj] Error 1 win-make[2]: *** [descend] Error 2 win-make[1]: *** [rtl.inst] Error 2 win-make: *** [src.inst] Error 2 Thanks and best regards, Mario ___ 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:[14463] trunk/harbour
Revision: 14463 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14463&view=rev Author: vouchcac Date: 2010-05-12 01:24:41 + (Wed, 12 May 2010) Log Message: --- 2010-17:24 18:23 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) + contrib/hbide/resources/curlinehilight.png Added missinf icon from prev commit. Modified Paths: -- trunk/harbour/ChangeLog Added Paths: --- trunk/harbour/contrib/hbide/resources/curlinehilight.png 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] Question about Preprocessor
Hi, when I put the following #translate in my program always convert the parameter myparm to literal "myparm". It is good for me. Sample: #translate MYEXAMPLE ; => ; MYNEWEXAMPLE <(myparm)> function main() MYEXAMPLE "cParm" MYEXAMPLEcParm Return .T. Code Generated: function main() MYNEWEXAMPLE "cParm" MYNEWEXAMPLE "cParm" Return .T. The question is: how make it in reverse ? (convert literal or variable to variable) #translate MYEXAMPLE ; => ; MYNEWEXAMPLE function main() MYEXAMPLE "cParm" MYEXAMPLEcParm Return .T. Generate: function main() MYNEWEXAMPLE cParm MYNEWEXAMPLE cParm Return .T. Thanks in advance -- CdQ ___ 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:[14462] trunk/harbour
Revision: 14462
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14462&view=rev
Author: vouchcac
Date: 2010-05-12 00:41:24 + (Wed, 12 May 2010)
Log Message:
---
2010-17:24 07:29 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
* contrib/hbide/plugins/savebackup.hrb
* contrib/hbide/plugins/savebackup.prg
! Fine tuned to receive correct number of parameters.
* contrib/hbqt/doc/en/class_hbqplaintextedit.txt
* contrib/hbqt/hbqt_hbqplaintextedit.cpp
* contrib/hbqt/hbqt_hbqplaintextedit.h
* contrib/hbqt/qtgui/HBQPlainTextEdit.cpp
* contrib/hbqt/qtgui/THBQPlainTextEdit.prg
* contrib/hbqt/qth/HBQPlainTextEdit.qth
* contrib/hbide/hbide.prg
* contrib/hbide/idedocks.prg
+ Added Icon: Toggle current Line Highlight in "Lines" toolbar.
Public API method is ::toggleCurrentLineHilight().
* contrib/hbide/ideedit.prg
* contrib/hbide/ideeditor.prg
* contrib/hbide/ideenviron.prg
! Reverted: line edits font - monospace to GUI.
* contrib/hbide/ideobject.prg
* contrib/hbide/ideplugins.prg
! tuned to send oIDE and cVer as first and second
argument to {plugin}_init( oIde, cVer ).
* contrib/hbide/ideprojmanager.prg
! Reverted: line edits font - monospace to GUI.
* contrib/hbide/ideshortcuts.prg
+ Public Method - ::toggleCurrentLineHilight().
Toggles displaying current line in distinct color.
* contrib/hbide/idethemes.prg
+ Activated: Selection Background slot.
It facilitates to control the color of selections per theme basis.
+ Prepared to toggle matching braces mode - both vs single.
"Setup" dialog will contain its place holder.
% Fixed many other artifacts coming into way, and possibly
might have broken a few ones, please report.
Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbide/hbide.prg
trunk/harbour/contrib/hbide/idedocks.prg
trunk/harbour/contrib/hbide/ideedit.prg
trunk/harbour/contrib/hbide/ideeditor.prg
trunk/harbour/contrib/hbide/ideenviron.prg
trunk/harbour/contrib/hbide/ideobject.prg
trunk/harbour/contrib/hbide/ideplugins.prg
trunk/harbour/contrib/hbide/ideprojmanager.prg
trunk/harbour/contrib/hbide/ideshortcuts.prg
trunk/harbour/contrib/hbide/idethemes.prg
trunk/harbour/contrib/hbide/plugins/savebackup.hrb
trunk/harbour/contrib/hbide/plugins/savebackup.prg
trunk/harbour/contrib/hbqt/doc/en/class_hbqplaintextedit.txt
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp
trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.h
trunk/harbour/contrib/hbqt/qtgui/HBQPlainTextEdit.cpp
trunk/harbour/contrib/hbqt/qtgui/THBQPlainTextEdit.prg
trunk/harbour/contrib/hbqt/qth/HBQPlainTextEdit.qth
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:[14461] trunk/harbour
Revision: 14461 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14461&view=rev Author: druzus Date: 2010-05-12 00:27:04 + (Wed, 12 May 2010) Log Message: --- 2010-05-12 02:26 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/external/minizip/ioapi.h ! fixed FreeBSD and HAIKU builds * harbour/src/rtl/fserr.c * added translation for EPERM * harbour/include/Makefile + harbour/include/hbapicom.h * harbour/src/rtl/Makefile + harbour/src/rtl/hbcom.c + added Harbour multiplatform serial port C API (hb_com*() functions). implemented code for *nixes, MS-Windows and OS2. DOS is not supported yet. Please make test on different platforms. ; few notes about this code: termios (*nix) based builds: - reading LSR is not supported - duration in break signal is fixed (at least 0.25 seconds, and not more that 0.5 seconds) - DTR/DSR hardware flow control is not supported - setting error character is not supported - discard card is supported only on few platforms - checking input/output flow state is not supported - if some platforms do not support some termio extensions then compile time warnings TODO_* should be generated. MS-Windows builds: - discard card is not supported OS2 builds: - checking for input flow state is not supported - discard card is not supported In all builds not all RS-232 hardware flags/state are available. OS2 build supports most of them, This code needs to be extensively tested. I wrote it without any serious tests. Especially OS2 builds should be verified by OS2 users. I wrote this port using only documentation which OS2 API available in the Internet. DOS is not supported yet though it's possible to compile termio code for *nixes with DJGPP. Anyhow it would be very nice if we can add our own DOS serial port code. I would like to ask if any of you has low level serial port code in C for DOS (i.e. used with Clipper) and can send it to us so we can use it with Harbour. I have my own serial port library for Clipper but it's written in assembler and it's much wider then sth what we need so it cannot be easy adopted for Harbour. * harbour/contrib/hbct/Makefile + harbour/contrib/hbct/ctcom1.c + harbour/contrib/hbct/ctcom.ch + harbour/contrib/hbct/ctcom2.c + added CT3 compatible COM_*() functions. + added CT3 compatible XMOBLOCK(), XMOCHECK(), ZEROINSERT() and ZEROREMOVE() functions. + added new CT COM function: COM_DEVNAME( [, ] ) -> which can be used to specify device name for given port in modern systems which do not give direct hardware access for the process. ; few notes about CT3 COM_*() functions in Harbour. In COM_OPEN() only 1-st parameter is significant, input/output buffer sizes and trap mode parameters are ignored. In modern OS-es such functionality is controlled by OS and usually buffered read/write is always enabled. The sizes of IO buffers can be used only as suggested IO buffer size for OS in some systems. It's possible that these additional parameters will be used in DOS builds in the future. COM_READ() does not support 2-nd parameter . It can be implemented but because we do not have direct access to OS buffers then we will have to emulate it ourselves what is rather inefficient. Anyhow I can implement it if users think it's critical. In COM_CRC() I fixed few CT3 bugs so it's not bug compatible with CT3, i.e. it works correctly for 8 bit and smaller polynomials instead of returning 0 or supports much larger polynomials up to 64bits. For 16/17 bit polynomials it gives the same results as CT3 so for most common usage it should be binary compatible with CT3. In ZEROREMOVE() I fixed decoding some wrong CCITT strings which does not have trailing 0 so it returns empty string "" for such corrupted data. If someone needs original CT3 behavior for some broken code then is can be enabled by HB_CT3_ZEROREMOVE_BUG macro. I haven't implemented few functions. COM_GETIO(), COM_SETIO(), COM_GETIRQ(), COM_SETIRQ() are not portable and can be implemented only for really few platforms, i.e. for DOS when/if we add support for serial ports to Harbour DOS builds. Similar functionality for all other platforms gives our new function COM_DEVNAME(). COM_KEY(), COM_SKEY() and COM_EVENT() are also not implemented. To make them well we should add support for asynchronous events to HVM and such extension is still unavailable. Some simulation can be implemented using idle tasks but this can be done also by final Harbour users so I decided to not make it. Please test it - I
[Harbour] Another .ini handling problem
Hi All, Someone reported to me privately that .ini value such as: -- [section] key=val=1 -- is wrongly read as 'val' instead of 'val=1' My opinion is still to move this code out of core to xhb, since it doesn't hit our quality level. Anyhow if someone wants to patch this (or other similar problems reported in hbini in the past), pls do so. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbIDE - Enumerate User Definable Options
Hello Everybody I am about to restructure hbIDE to honor user defined options which are set globally per hbIDE.ini. These options will be fetched through a tabbed dialog invokable under . So that I do not miss anything, please speak on the list what must go inside it. Also explain a little bit to help me understand the reference and context. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/hbIDE-Enumerate-User-Definable-Options-tp5038092p5038092.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] SF.net SVN: harbour-project:[14460] trunk/harbour
Revision: 14460 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14460&view=rev Author: vszakats Date: 2010-05-11 20:27:03 + (Tue, 11 May 2010) Log Message: --- 2010-05-11 22:22 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbziparc/Makefile * contrib/hbziparc/hbziparc.prg ! Fixed support in HB_ZIPFILE(). * config/postinst.prg % Simplified local implib creation logic. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/postinst.prg trunk/harbour/contrib/hbziparc/Makefile trunk/harbour/contrib/hbziparc/hbziparc.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
Re: [Harbour] Error building Harbour revision 14459
Viktor,
win-make clean
D:\programacion_disk\Programacion\harbour>win-make clean
! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: win-make 3.81 sh.exe clean
! HB_INSTALL_PREFIX: D:\programacion_disk\Programacion\hb-mingw
! HB_HOST_PLAT: win (x86) HB_SHELL: nt
! HB_PLATFORM: win (x86) (autodetected)
! HB_COMPILER: mingw (v44) (autodetected:
D:/programacion_disk/Programacion/harb
our/hb20/comp/mingw/bin/)
! Component: 'zlib' found in
D:/programacion_disk/Programacion/harbour/external/
zlib (local)
! Component: 'pcre' found in
D:/programacion_disk/Programacion/harbour/external/
pcre (local)
! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on win platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not found. Configure with HB_WITH_CURSES.
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on win platform
! 'gtcrs' library skipped (component not found)
! 'gtdos' library skipped (platform not supported)
! 'gtos2' library skipped (platform not supported)
! 'gtsln' library skipped (component not found)
! 'gttrm' library skipped (platform or compiler not supported)
! 'gtxwc' library skipped (component not found)
! 'gtalleg' library skipped ('allegro' not found. Configure with
HB_WITH_ALLEGRO
.)
! 'hbcairo' library skipped ('cairo' not found. Configure with
HB_WITH_CAIRO.)
! 'hbcups' library skipped ('cups' not found. Configure with HB_WITH_CUPS.)
! 'hbcurl' library skipped ('libcurl' not found. Configure with
HB_WITH_CURL.)
! 'hbfbird' library skipped ('firebird' not found. Configure with
HB_WITH_FIREBI
RD.)
! 'hbfimage' library skipped ('freeimage' not found. Configure with
HB_WITH_FREE
IMAGE.)
! 'hbgd' library skipped ('libgd' not found. Configure with HB_WITH_GD.)
! 'hbmysql' library skipped ('mysql' not found. Configure with
HB_WITH_MYSQL.)
! 'hbpgsql' library skipped ('postgresql' not found. Configure with
HB_WITH_PGSQ
L.)
! 'hbqt' library skipped ('qt' not found. Configure with HB_WITH_QT.)
! 'hbssl' library skipped (component not found)
! 'rddads' library skipped ('ads' not found. Configure with HB_WITH_ADS.)
! 'sddfb' library skipped ('firebird' not found. Configure with
HB_WITH_FIREBIRD
.)
! 'sddmy' library skipped ('mysql' not found. Configure with HB_WITH_MYSQL.)
! 'sddoci' library skipped ('ocilib' not found. Configure with
HB_WITH_OCILIB.)
! 'sddpg' library skipped ('postgresql' not found. Configure with
HB_WITH_PGSQL.
)
win-make install
D:\programacion_disk\Programacion\harbour>win-make install
! Building Harbour 2.1.0beta1 from source - http://www.harbour-project.org
! MAKE: win-make 3.81 sh.exe install
! HB_INSTALL_PREFIX: D:\programacion_disk\Programacion\hb-mingw
! HB_HOST_PLAT: win (x86) HB_SHELL: nt
! HB_PLATFORM: win (x86) (autodetected)
! HB_COMPILER: mingw (v44) (autodetected:
D:/programacion_disk/Programacion/harb
our/hb20/comp/mingw/bin/)
! Component: 'zlib' found in
D:/programacion_disk/Programacion/harbour/external/
zlib (local)
! Component: 'pcre' found in
D:/programacion_disk/Programacion/harbour/external/
pcre (local)
! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on win platform
! Component: 'slang' not found. Configure with HB_WITH_SLANG.
! Component: 'curses' not found. Configure with HB_WITH_CURSES.
! Component: 'x11' not found. Configure with HB_WITH_X11.
! Component: 'wattcp/watt-32' not supported on win platform
...
...
...
Extrange... now it worked.
I don't know why... I did as allways:
win-make clean
and then
win-make install
So... sorry :-(
Regards,
José Luis Capel
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error building Harbour revision 14459
Hi, Pls post the beginning of your log output and the dir listing of your mingw bin dir. Viktor On 2010 May 11, at 21:33, José Luis Capel wrote: > Hi, > > I've got this error when building Harbour: > > gcc -Wl,--nxcompat -Wl,--dynamicbase -L../../../../../lib/win/mingw -o > ..\..\ > ..\..\..\bin\win\mingw\hbpp.exe hbpp.o -lhbnortl -lhbcommon -lkernel32 > -luser32 > -lws2_32 -ladvapi32 -lgdi32 > d:/programacion_disk/programacion/harbour/hb20/comp/mingw/bin/../lib/gcc/mingw32 > /4.4.1/../../../../mingw32/bin/ld.exe: unrecognized option '--nxcompat' > d:/programacion_disk/programacion/harbour/hb20/comp/mingw/bin/../lib/gcc/mingw32 > /4.4.1/../../../../mingw32/bin/ld.exe: use the --help option for usage > information > collect2: ld returned 1 exit status > win-make[3]: *** [hbpp.exe] Error 1 > rm hbpp.o > win-make[2]: *** [descend] Error 2 > win-make[1]: *** [pp.inst] Error 2 > win-make: *** [src.inst] Error 2 > > Regards, > José Luis Capel > > > ___ > 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] Error building Harbour revision 14459
Hi, I've got this error when building Harbour: gcc -Wl,--nxcompat -Wl,--dynamicbase -L../../../../../lib/win/mingw -o ..\..\ ..\..\..\bin\win\mingw\hbpp.exe hbpp.o -lhbnortl -lhbcommon -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32 d:/programacion_disk/programacion/harbour/hb20/comp/mingw/bin/../lib/gcc/mingw32 /4.4.1/../../../../mingw32/bin/ld.exe: unrecognized option '--nxcompat' d:/programacion_disk/programacion/harbour/hb20/comp/mingw/bin/../lib/gcc/mingw32 /4.4.1/../../../../mingw32/bin/ld.exe: use the --help option for usage information collect2: ld returned 1 exit status win-make[3]: *** [hbpp.exe] Error 1 rm hbpp.o win-make[2]: *** [descend] Error 2 win-make[1]: *** [pp.inst] Error 2 win-make: *** [src.inst] Error 2 Regards, José Luis Capel ___ 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:[14459] trunk/harbour
Revision: 14459 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14459&view=rev Author: vszakats Date: 2010-05-11 19:21:03 + (Tue, 11 May 2010) Log Message: --- 2010-05-11 21:16 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * config/postinst.prg ! Fixed forming quoted paths in implib creation commands. * INSTALL ! Deleted space at EOL. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/config/postinst.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] Problem with HB_ZipFile
Hi, I have a little program that compress files to zip format by adding files with parameter setting to .T. for first file (to create the zip file) and the following files with setting to .F. to add files to ZIP. Sample: function main ferase( "pepe.zip" ) HB_ZIPFILE( "pepe.zip" , "minilib.mip" , 8 , NIL , *.T.* , NIL , .T. , .F. ) ? "First file Added. Press any key to continue" inkey(0) HB_ZIPFILE( "pepe.zip" , "fileinfo.prg" , 8 , NIL , *.F.* , NIL , .T. , .F. ) ? "Finished. Press any key to continue" inkey(0) Return .T. but when the process finished, "pepe.zip" only have the last file. Can anyone help me. This routine working fine in the past. Thanks in advance OS: Windows XP Harbour 2.1.0beta1 (Rev. 14394) -- Saludos/Regards/Abraços CdQ ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Contrib´s not build with 14457
Hi, There is a bug after recent changes. BTW, only these are the valid Harbour settings in you config, pls delete the rest to avoid confusion: > set HB_BUILD_DLL=yes > set HB_BUILD_IMPLIB=yes > set HB_CONTRIB_ADDONS=yes > set HB_BUILD_UNICODE=no > rem set HB_BUILD_UNICODE=yes > > set HB_WITH_PGSQL=C:\pgsql84\include > set HB_WITH_ADS=C:\ads81 > set HB_WITH_QT=C:\Qt\qt\include > set HB_WITH_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1\include > set HB_WITH_FREEIMAGE=C:\FreeImg\3120\Dist Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Slow create index under threads
Hi,
On 2010.05.11 18:52, rafa wrote:
Second;
A question
What advantages are there in using indexes MEMORY?
Rafa, you've completely changed the original idea:
>> OrdCreate("mem:file.ext", ...)
>> I've sent C code for copying file from/to memory a few days ago.
> Ok, thanks!
> I add MEMORY a command INDEX , And I'll post later the results on
> indices of memory.
INDEX ... MEMORY is completely different thing from
OrdCreate("mem:file.ext")
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Contrib´s not build with 14457
Hello, When I generate the binaries for this version I see no more files: "ace32.lib", "freeimage.lib" and "libpq.lib" These are my settings. [SETTINGS] set HB_BUILD_DLL=yes set HB_DIR_IMPLIB=yes set HB_BUILD_IMPLIB=yes set HB_BUILD_LOG=yes set HB_CONTRIB_ADDONS=yes set HB_BUILD_UNICODE=no rem set HB_BUILD_UNICODE=yes set HB_WITH_PGSQL=C:\pgsql84\include set HB_WITH_ADS=C:\ads81 set HB_WITH_QT=C:\Qt\qt\include set HB_WITH_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1\include set HB_WITH_FREEIMAGE=C:\FreeImg\3120\Dist set HB_DIR_PGSQL=C:\pgsql84 set HB_DIR_ADS=C:\ads81 rem set HB_DIR_QT=C:\Qt\qt\include set HB_DIR_QT=C:\Qt\qt set HB_DIR_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1 set HB_DIR_FREEIMAGE=C:\FreeImg\3120\Dist set HB_INC_PGSQL=C:\pgsql84\include set HB_INC_ADS=C:\ads81 set HB_INC_QT=C:\Qt\qt\include set HB_INC_FIREBIRD=C:\ARQUIV~1\Firebird\Firebird_2_1\include set HB_INC_FREEIMAGE=C:\FreeImg\3120\Dist [/SETTINGS] I use BCC 551. What can be ? Regards, Rossine. -- View this message in context: http://old.nabble.com/Contrib%C2%B4s-not-build-with-14457-tp28527275p28527275.html Sent from the Harbour - Dev 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] SF.net SVN: harbour-project:[14458] trunk/harbour
Hi Pritpal Please, make this a option. I unknown another code editor which highlighting only one brace and I ever used coding with pair highlighting. For me, highlight one brace is confusing, or highlight none or both braces. xMate is a bad example of code editor implementation. It has too many non standard features, please focus on a establish, rock solid and standard code editor to inspire you. Look at Visual Studio, Eclipse (which I don't like), CodeLite, IntelliJ IDEA, NetBeans, SlickEdit, UltraEdit, Notepad++, Crimson Editor, Hippo, Zeus, PSPad, Komodo, Emacs, PHPEd, Magic Editor, Code Insight, Delphi, Lazarus, Textmate/E-Texteditor, Scite, even VIM. []'s Maniero 2010/5/11 > Revision: 14458 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14458&view=rev > Author: vouchcac > Date: 2010-05-11 14:36:42 + (Tue, 11 May 2010) > > Log Message: > --- > 2010-05-11 07:29 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbqt/hbqt_hbqplaintextedit.cpp >% Optimized: selections display with proprietory color. > Now it oply operates within viewport() coordinates. > >% Changed: the behavior of matching brace. Now only corresponding > brace is highlighted instead of both. This is exactly like > xMate. Please note that highlighting both braces create > confusion and at time I am lost. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp > > > 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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
>>> I am compiling/linking a extremely large project >>> with hbIDE, hbMK2 ( hbMK2 is slightly modified to supply >>> sources to Harbour compiler one-by-one, rest remaining the >>> same as is ) with -xhb switch. >> >> Too bad, this way we will never know what the real problem is. >> Did you read my last e-mail regarding more possible tips? >> > > Yep. > > Then I searched the sources for #pragma directives. > Because I am not the author of those sources, I never knew that > multiple #pragma directives were in use. And that was the potential > reason to get thousands of warnings which ultimately was killing > the process. So this was the problem. I hope Przemek can take an expert look on this issue, as I'm sure it's not intentional that such options are changing across sources. F.e. this causes unpredictable results for anyone using 'harbour *.prg' on a *nix system f.e. These pragmas are meant to be per file. > With this method I am able to compile all sources. > After a couple of hours I will post what exactly I changed in the hbMK2 > to accept switches per source, may be you consider it to be included > in hbMK2 to make it more versatile engine. Sorry, but as I told I don't want to include it. I find it totally wrong on several levels. Rather, the #pragma handling should be fixed. >> I don't know why and how xhb tries to use _errno, >> but if you can check how xhb's own build system links the >> final executable and compare it with the hbmk2 link >> command, maybe we can get closer to the solution. >> > > It is xMate and open-source xHarbour we use. > The only difference I can see is in C switches what xMate > supplies and what hbMK2 supplies. I will show it a little later. > > May be this could be caused by C sources order or supply. It's possible. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Slow create index under threads
Hello All, First; Great! I have noticed is an improvement of about 2 minutes of not using Hb_detach () and remove the threads in the creation of indices. Second; A question What advantages are there in using indexes MEMORY? I do not appreciate any improvement is more, we analyzed under Windows XP and Vista (Server), as these index are simply created as temporary files; C: \ Documents and Settings \ Administrator \ Local Settings \ Temp \ hb602.tmp C: \ Documents and Settings \ Administrator \ Local Settings \ Temp \ hb66D.tmp Therefore, at least under Windows, I do not see that this is a pure memory index, as is using a temporary file In less demanding tests that look, creating over 400 indexes were; INDEX... MEMORY... MEMORY: 1 Thread 7.78 (minutes) MEMORY: 4 Threads 8.58 (minutes) INDEX DISC: 1 Thread 7.12 (minutes) WINNER! DISC: 4 Threads 8.76(minutes ) Or maybe I'm wrong? ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
Viktor Szakáts wrote: > >> I am compiling/linking a extremely large project >> with hbIDE, hbMK2 ( hbMK2 is slightly modified to supply >> sources to Harbour compiler one-by-one, rest remaining the >> same as is ) with -xhb switch. > > Too bad, this way we will never know what the real problem is. > Did you read my last e-mail regarding more possible tips? > Yep. Then I searched the sources for #pragma directives. Because I am not the author of those sources, I never knew that multiple #pragma directives were in use. And that was the potential reason to get thousands of warnings which ultimately was killing the process. It is not possible to change anyline in the source. So the solution is to supply each source saparately with needed switches. xMate doe it like this with successful link. Now hbIDE also does the same but only for harbour.exe, bcc32 is called as per hbMK2 anyway. As you also confirmed, if a #pragma is defined for one source, or is included in the source, this retains its effect throughout for next sources unless nullified. This also eliminates the possibility to supply all sources at once ( for this particular scenario where #pragmas are included in the source ). With this method I am able to compile all sources. After a couple of hours I will post what exactly I changed in the hbMK2 to accept switches per source, may be you consider it to be included in hbMK2 to make it more versatile engine. >> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland >> Error: Unresolved external '_errno' referenced from >> C:\XHARBOUR\LIB\PP.LIB|ppcore > > I don't know why and how xhb tries to use _errno, > but if you can check how xhb's own build system links the > final executable and compare it with the hbmk2 link > command, maybe we can get closer to the solution. > It is xMate and open-source xHarbour we use. The only difference I can see is in C switches what xMate supplies and what hbMK2 supplies. I will show it a little later. May be this could be caused by C sources order or supply. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/hbMK2-xHarbour-Oct-2007-Unresolved-External-tp5033192p5036718.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] [r|s]ddoci
Have you made
set HB_WITH_OCILIB=C:\ocilib
or
set HB_WITH_OCILIB c:\ocilib\include
set HB_WITH_OCILIB c:\ocilib\lib32
?
2010/5/11 Horodyski Marek (PZUZ) :
>> -Original Message-
>
> Still :
>
> ! 'sddoci' library skipped ('ocilib' not found. Configure with
> HB_WITH_OCILIB.) :(
>
> Tomorrow I'll try
>
--
Massimo Belgrano
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] [r|s]ddoci
> -Original Message-
> From: Massimo Belgrano [mailto:mbelgr...@deltain.it]
> Sent: Tuesday, May 11, 2010 4:17 PM
> To: Harbour Project Main Developer List.
> Subject: Re: [Harbour] [r|s]ddoci
>
> Hi Marek
> Hello i i read in c:\harbour\install follow info
>
> HB_WITH_OCILIB - OCILIB (C Driver for Oracle) [multiplatform,
> free, open-source]
> http://orclib.sourceforge.net/
>
> http://www.oracle.com/technology/tech/oci/instantclient/index.html
Still :
! 'sddoci' library skipped ('ocilib' not found. Configure with
HB_WITH_OCILIB.) :(
Tomorrow I'll try
Regards,
Marek Horodyski
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] [r|s]ddoci
> -Original Message- > From: Massimo Belgrano [mailto:mbelgr...@deltain.it] > Sent: Tuesday, May 11, 2010 4:17 PM > To: Harbour Project Main Developer List. > Subject: Re: [Harbour] [r|s]ddoci > > Hi Marek > Hello i i read in c:\harbour\install follow info > > HB_WITH_OCILIB - OCILIB (C Driver for Oracle) [multiplatform, > free, open-source] > http://orclib.sourceforge.net/ > > http://www.oracle.com/technology/tech/oci/instantclient/index.html > > Can you post here your final sample? > > (a facebook friend) >From your link have I download 3.5.1 wersion ( I was have oldest 3.2) And now analyze posinst.prg : 120│ IF GetEnv( "HB_COMPILER" ) == "mingw" .AND. ; 121│ ! Empty( GetEnv( "HB_WITH_OCILIB" ) ) 122│ hb_FCopy( GetEnv( "HB_WITH_OCILIB" ) + _PS_ + StrTran( "..\lib32\libociliba.a" ... 123│ hb_FCopy( GetEnv( "HB_WITH_OCILIB" ) + _PS_ + StrTran( "..\lib32\libocilibm.a" ... 124│ hb_FCopy( GetEnv( "HB_WITH_OCILIB" ) + _PS_ + StrTran( "..\lib32\libocilibw.a" ... 125│ ENDIF 126│ ENDIF A little more ... :) Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
> I am compiling/linking a extremely large project > with hbIDE, hbMK2 ( hbMK2 is slightly modified to supply > sources to Harbour compiler one-by-one, rest remaining the > same as is ) with -xhb switch. Too bad, this way we will never know what the real problem is. Did you read my last e-mail regarding more possible tips? > Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland > Error: Unresolved external '_errno' referenced from > C:\XHARBOUR\LIB\PP.LIB|ppcore I don't know why and how xhb tries to use _errno, but if you can check how xhb's own build system links the final executable and compare it with the hbmk2 link command, maybe we can get closer to the solution. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[14457] trunk/harbour
Hi, >>> * contrib/hbide/resources/environments.uic >>> + Applied: monospaced font "Courier" to input fields and text boxes. >> >> I don't know your motives, but this makes HBIDE >> look very substandard compared to any tools I know. >> (Not to mention much less text fits in the text boxes.) >> I would suggest to restore proportional fonts in >> dialogs. >> > > You may be right from pure aesthetics point of view. > > In single edit lines your view point is OK, I will change them. > But for edit boxes, it is more appropriate to apply monospaced > fonts, after all, we are dealing with code off-shoots. That's fine solution. Thanks. > For example, in source files listing in Project Properties, > at times it is needed that sources be alligned properly to visualize > some facts. Similarly, in Environments dialog too it is required > as we will be editing them regularily. A GUI font is always a pain > in the neck to be modified properly. May be I am getting old, > but the general fact remain the same. For multiline boxes where code is meant to be typed, it's okay. > Please have a look on artical Antonio posted few days back, > http://www.joelonsoftware.com/uibook/fog000249.html I've read this article many years ago, but it's a little too long to reread now :) Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbMK2 - xHarbour ( Oct 2007 ) - Unresolved External
Pritpal Bedi wrote: > > In continuation... > > "Hello World" prg buils fine with -lgtwin. > The compile and link flags are the same as of > larger application. > > So where is the catch? > Any clues guys ? I am struck to this very fact and appears to be a show-stopper to implement hbIDE in a really large environment. It appears to be a problem with dll calling convention. "_" prepended to the funtion name. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/hbMK2-xHarbour-Oct-2007-Unresolved-External-tp5033192p5036341.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] Re: SF.net SVN: harbour-project:[14457] trunk/harbour
Viktor Szakáts wrote: > >> * contrib/hbide/resources/environments.uic >>+ Applied: monospaced font "Courier" to input fields and text boxes. > > I don't know your motives, but this makes HBIDE > look very substandard compared to any tools I know. > (Not to mention much less text fits in the text boxes.) > I would suggest to restore proportional fonts in > dialogs. > You may be right from pure aesthetics point of view. In single edit lines your view point is OK, I will change them. But for edit boxes, it is more appropriate to apply monospaced fonts, after all, we are dealing with code off-shoots. For example, in source files listing in Project Properties, at times it is needed that sources be alligned properly to visualize some facts. Similarly, in Environments dialog too it is required as we will be editing them regularily. A GUI font is always a pain in the neck to be modified properly. May be I am getting old, but the general fact remain the same. Please have a look on artical Antonio posted few days back, http://www.joelonsoftware.com/uibook/fog000249.html - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14457-trunk-harbour-tp5033736p5036322.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] SF.net SVN: harbour-project:[14458] trunk/harbour
Revision: 14458 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14458&view=rev Author: vouchcac Date: 2010-05-11 14:36:42 + (Tue, 11 May 2010) Log Message: --- 2010-05-11 07:29 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/hbqt_hbqplaintextedit.cpp % Optimized: selections display with proprietory color. Now it oply operates within viewport() coordinates. % Changed: the behavior of matching brace. Now only corresponding brace is highlighted instead of both. This is exactly like xMate. Please note that highlighting both braces create confusion and at time I am lost. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp 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] [r|s]ddoci
Hi Marek Hello i i read in c:\harbour\install follow info HB_WITH_OCILIB - OCILIB (C Driver for Oracle) [multiplatform, free, open-source] http://orclib.sourceforge.net/ http://www.oracle.com/technology/tech/oci/instantclient/index.html Can you post here your final sample? (a facebook friend) 2010/5/11 Horodyski Marek (PZUZ) : > Hi, > > I’m try to use oci. > > What I can, or what can I do, to arrive exe from > \harbour\contrib\sddoci\tests\test1.prg ? > > > > Command : > > \harbour\bin\win\mingw\hbmk2.exe test1.prg does not work > > ( it say > /gcc/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: > cannot find –lsddoci) > > > > How should I reinstall Harbour ? > > > > Regards, > > Marek Horodyski > > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] [r|s]ddoci
Hi, I'm try to use oci. What I can, or what can I do, to arrive exe from \harbour\contrib\sddoci\tests\test1.prg ? Command : \harbour\bin\win\mingw\hbmk2.exe test1.prg does not work ( it say /gcc/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: cannot find -lsddoci) How should I reinstall Harbour ? Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Harbour "random" GPFs
> -Original Message- > From: Heinz V Bergen [mailto:hber...@ops.phl.ca] > Sent: Thursday, May 06, 2010 11:41 PM > To: harbour@harbour-project.org > Subject: Re: [Harbour] Harbour "random" GPFs > > > Whew! > My problem has been resolved by fix in Revision 14441. [...] > Przemysław Czerpak for the encouragement and final fix. > > Heinz My problem with GPF too was resolved. Many, many thanks :) Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Slow create index under threads
Hello, Mindaugas Kavaliauskas escribió: > Hi, > > > On 2010.05.11 12:22, rafa wrote: >>> Of cause. Did you expect your code to behave in a different way?... >> I thought he reindex all at once ;-) >> The reason is because only one index reindex a table, while the others >> wait, I do not know. > > The reason is hb_dbdetach(), hb_dbattach(). Workarea is attached only > after another thread have detached it. So, you should not expect any > parallelism here. Ok, I've modified the code to eliminate the use of hb_detach () and no thread is created for each index. Performing the test on these pending changes to disk dump memory of the indexes. > > >> I need to save time when re-indexing on the servers, because we handle a >> lot of information in the tables, over 12 GB in total. > > It is interesting what is copy files time for these 12GB on your > server. This can give some idea of the result you can reach. > > > Regards, > Mindaugas > ___ > 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
Re: [Harbour] Slow create index under threads
Hi, On 2010.05.11 12:22, rafa wrote: Of cause. Did you expect your code to behave in a different way?... I thought he reindex all at once ;-) The reason is because only one index reindex a table, while the others wait, I do not know. The reason is hb_dbdetach(), hb_dbattach(). Workarea is attached only after another thread have detached it. So, you should not expect any parallelism here. I need to save time when re-indexing on the servers, because we handle a lot of information in the tables, over 12 GB in total. It is interesting what is copy files time for these 12GB on your server. This can give some idea of the result you can reach. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Slow create index under threads
Mindaugas Kavaliauskas escribió:
> Hi,
>
>
>> Please could you tell me how to create the index in memory and then
>> flush to disk?
>
> OrdCreate("mem:file.ext", ...)
> I've sent C code for copying file from/to memory a few days ago.
Ok, thanks!
I add MEMORY a command INDEX , And I'll post later the results on
indices of memory.
>
>
>>> These crea() threads do not help to do any valuable job. Function
>>> aCreateIndexe() starts a separate crea() thread for each index tag,
>>> but indexes are not created in parallel, because only one thread has
>>> attached area.
>>>
>> Is it possible to improve this aspect?
>
> You can copy body of crea() into aCreateIndexe() and do not create a
> separate thread. It will save a small overhead of thread
> creation/synchronization, but it will be not significant.
>
Ok.
>
>> Under Windows, usndo ProcessXP, I could see the threads of the indices
>> only run one at a time, while the rest is waiting
>
> Of cause. Did you expect your code to behave in a different way?...
I thought he reindex all at once ;-)
The reason is because only one index reindex a table, while the others
wait, I do not know.
I need to save time when re-indexing on the servers, because we handle a
lot of information in the tables, over 12 GB in total.
Regards
Rafa Carmona
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Slow create index under threads
Hi,
Please could you tell me how to create the index in memory and then
flush to disk?
OrdCreate("mem:file.ext", ...)
I've sent C code for copying file from/to memory a few days ago.
These crea() threads do not help to do any valuable job. Function
aCreateIndexe() starts a separate crea() thread for each index tag,
but indexes are not created in parallel, because only one thread has
attached area.
Is it possible to improve this aspect?
You can copy body of crea() into aCreateIndexe() and do not create a
separate thread. It will save a small overhead of thread
creation/synchronization, but it will be not significant.
Under Windows, usndo ProcessXP, I could see the threads of the indices
only run one at a time, while the rest is waiting
Of cause. Did you expect your code to behave in a different way?...
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour for the iPad - ok
>> What you get is a .c source regardless of >> the -gc mode, but the problem is that we're >> running a translator from .prg to .c. In that >> sense it should not make a difference. >> > Yes, but this translator is run only once, during program build, from there on > it is a pure machine code executable. > > I think the problem with Apple is that they don't want the VM running on > iPhone/iPad because they cannot be sure the code does not contain malicious > parts/virus/exploits and so on. Most importantly they want to keep staying in control of their own platform. [ BTW even with -gc3, the VM has to be there and running. ] >> The other thing is that if you want to access >> any Apple API from .prg, it's inevitable >> to go through a set of wrapper functions, which >> is again something Apple seems to not like, >> because this way they are in the hands of wrapper >> developers regarding what feature is accessible >> from .prg code and how fully it is implemented. >> > I don't think so, you simply have some .c code which is a wrapper to something > that, in the end, becomes a .c source which gets compiled/linked to a pure cpu > specific assembler code. Apple want to keep out any extra layers between their API and application code. We can bend things however we want, but at the end, the extra layer will just be there, since you cannot make direct calls from .prg to Apple API. My emphasis from Section 3.3.1: "Applications must be originally written in Objective-C, C, C++, or JavaScript" "Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited." >> At least that's Apple's intent. As to how they >> can defend these rules "in court", I have no idea. >> > They don't defend it in court, they simply will not put your program on > iTunes, so you cannot distribute it. Yes, and/or if they find out about such practice they have the right to suspend your account I suppose. Question is how they can find it out, and what methods do they use to find it out, and if any developers want to make a risk here to push Apple and the license rules to the limits. Interesting reads: http://daringfireball.net/2010/04/why_apple_changed_section_331 http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler (with other affected tools listed and linked) Discussion on MonoTouch forum: http://forums.monotouch.net/yaf_postst645.aspx One more important thing to add is that 3.3.1 section only applies to Standard licensing, and it doesn't for Enterprise licensing, which means you can develop an internally distributed (non-iTunes Store) application without being affected by this rule. Another thing to add is there is quite a lot of confusion and uncertainty regarding the matter, so it's worth to see what comes out of it at the end. Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour for the iPad - ok
Viktor Szakáts wrote: > Hi Maurilio, > >> what about using -gc3 to have an application which is not executed by a VM? > > What you get is a .c source regardless of > the -gc mode, but the problem is that we're > running a translator from .prg to .c. In that > sense it should not make a difference. > Yes, but this translator is run only once, during program build, from there on it is a pure machine code executable. I think the problem with Apple is that they don't want the VM running on iPhone/iPad because they cannot be sure the code does not contain malicious parts/virus/exploits and so on. > The other thing is that if you want to access > any Apple API from .prg, it's inevitable > to go through a set of wrapper functions, which > is again something Apple seems to not like, > because this way they are in the hands of wrapper > developers regarding what feature is accessible > from .prg code and how fully it is implemented. > I don't think so, you simply have some .c code which is a wrapper to something that, in the end, becomes a .c source which gets compiled/linked to a pure cpu specific assembler code. > At least that's Apple's intent. As to how they > can defend these rules "in court", I have no idea. > They don't defend it in court, they simply will not put your program on iTunes, so you cannot distribute it. Best regards. Maurilio. -- __ | | | |__| 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
