RE: [Harbour] Re: About Harbour Documentation
Hi all, maybe I missed something, and someone has already told it, but I think that the main goal for a documentation is to be always available, so an online documentation must be a plus, a side feature of an offline documentation. There are many files available in the \doc folder but I can't see if there is a file that organize them in any way, such as alfabetical or category order. I'm a user of ng guides that I use almost every day when I don't remember the syntax of a function of the properties of a class. I know it's a very old tool but it does the job very well: to show documentation in a fast and proper way without the need of being on line or to scan \doc folder in search of the right file: I don't know if there is a Linux version too. Another consideration is that many informations that can be useful in advanced documentation can be borrowed from this mailing list: personally I'm registering the messages that I think of important for me. Finally another source is the Changelog. So in addition to documentation team that have been suggested, I think that it's important to have someone that has the time to read Changelog and this mailing list in search of the right answer or the proper implementation of a problem. I know that Changelog is updating fast but theare are informations that are valid documentation itself and the keep valid for a long time. Best regards, Marco _ Parla, scrivi, gioca... Scopri le novità di Messenger http://www.messenger.it/home_novita.aspx___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi, maybe I missed something, and someone has already told it, but I think that the main goal for a documentation is to be always available, so an online documentation must be a plus, a side feature of an offline documentation. There are many files available in the \doc folder but I can't see if there is a file that organize them in any way, such as alfabetical or category order. I'm a user of ng guides that I use almost every day when I don't remember the syntax of a function of the properties of a class. I know it's a very old tool but it does the job very well: to show documentation in a fast and proper way without the need of being on line or to scan \doc folder in search of the right file: I don't know if there is a Linux version too. You missed hbdoc2. Another consideration is that many informations that can be useful in advanced documentation can be borrowed from this mailing list: personally I'm registering the messages that I think of important for me. Finally another source is the Changelog. So in addition to documentation team that have been suggested, I think that it's important to have someone that has the time to read Changelog and this mailing list in search of the right answer or the proper implementation of a problem. I know that Changelog is updating fast but theare are informations that are valid documentation itself and the keep valid for a long time. Yes. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13930] trunk/harbour
Revision: 13930 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13930view=rev Author: vszakats Date: 2010-02-20 10:51:51 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 11:50 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbextern.ch * src/rtl/browdb.prg * src/rdd/dbcmd.c * contrib/xpp/dbcmdx.c * contrib/xpp/browdbx.prg + Cleaned the way TBrowseDB() skipper function is defined. This means that from now on by default the faster, .c implementation will be used (now called __DBSKIPPER()). The same will be used by xpp lib (via compatibility stub called DBSKIPPER()). The .prg implementation (now moved in core) will be used when HB_CLP_STRICT is enabled. * include/hbextern.ch + Added missing HB_DYNCALL(). * contrib/xpp/xpp.ch * Do not #define HB_COMPAT_XPP. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xpp/browdbx.prg trunk/harbour/contrib/xpp/dbcmdx.c trunk/harbour/contrib/xpp/xpp.ch trunk/harbour/include/hbextern.ch trunk/harbour/src/rdd/dbcmd.c trunk/harbour/src/rtl/browdb.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13931] trunk/harbour
Revision: 13931 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13931view=rev Author: vszakats Date: 2010-02-20 11:01:36 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 12:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/common/hbverdsp.c * include/hbsetup.ch * contrib/xhb/xhbver.prg - Deleted HB_COMPAT_VO, HB_COMPAT_DBASE, HB_COMPAT_CLIP as build-time options. They were not used, and in the future these should be implemented as addon libraries. * INSTALL * Minor terminogology adjustment. * examples/hbdoc2/tmplates.prg * examples/hbdoc2/hbdoc2.prg - Deleted special handling of FlagShip functions. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/contrib/xhb/xhbver.prg trunk/harbour/examples/hbdoc2/hbdoc2.prg trunk/harbour/examples/hbdoc2/tmplates.prg trunk/harbour/include/hbsetup.ch trunk/harbour/src/common/hbverdsp.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi! When I started the studies on this help format, I found many helpful information about the format NANFORUM in: http://www.kssoftware.com.br/ft_doc.zip And also the code in /harbour/examples/hbdoc2/tmplates.prg Regards, Vailton Renato ___ 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:[13932] trunk/harbour
Revision: 13932 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13932view=rev Author: vszakats Date: 2010-02-20 11:57:17 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 12:55 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbsetup.ch * src/common/hbverdsp.c - Deleted HB_COMPAT_FLAGSHIP, HB_COMPAT_FOXPRO. * include/hbextern.ch * src/rtl/seconds.c + Added HB_SECONDSCPU() (native Harbour version of FlagShip specific SECONDSCPU()) * tests/memtst.prg * tests/speedold.prg * tests/speedtst.prg * tests/vidtest.prg * Changed to use HB_SECONDSCPU(). + Added translation from SECONDSCPU() to HB_SECONDSCPU() when built for FlagShip (where applicable). * include/hbextern.ch * src/rtl/Makefile - src/rtl/strpeek.c - src/rtl/secondfs.c * contrib/Makefile + contrib/hbfship + contrib/hbfship/Makefile + contrib/hbfship/hbfship.hbc + contrib/hbfship/secondfs.c + contrib/hbfship/strpeek.c - Moved FlagShip specific function from core to new hbfship lib. * Changed SECONDSCPU() to be just a wrapper over core HB_SECONDSCPU(). ; INCOMPATIBLE: If you used SECONDSCPU() function, change it to HB_SECONDSCPU(), or add hbfship to your lib list. If you used STRPEEK() or STRPOKE() functions, add hbfship to your lib list. * utils/hbmk2/examples/contribf.hbc + Added hbfship. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/Makefile trunk/harbour/include/hbextern.ch trunk/harbour/include/hbsetup.ch trunk/harbour/src/common/hbverdsp.c trunk/harbour/src/rtl/Makefile trunk/harbour/src/rtl/seconds.c trunk/harbour/tests/memtst.prg trunk/harbour/tests/speedold.prg trunk/harbour/tests/speedtst.prg trunk/harbour/tests/vidtest.prg trunk/harbour/utils/hbmk2/examples/contribf.hbc Added Paths: --- trunk/harbour/contrib/hbfship/ trunk/harbour/contrib/hbfship/Makefile trunk/harbour/contrib/hbfship/hbfship.hbc trunk/harbour/contrib/hbfship/secondfs.c trunk/harbour/contrib/hbfship/strpeek.c Removed Paths: - trunk/harbour/src/rtl/secondfs.c trunk/harbour/src/rtl/strpeek.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13933] trunk/harbour
Revision: 13933 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13933view=rev Author: vszakats Date: 2010-02-20 12:03:26 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 13:02 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/Makefile - contrib/xpp + contrib/hbxpp * contrib/hbxpp/Makefile - contrib/hbxpp/xpp.hbc + contrib/hbxpp/hbxpp.hbc - contrib/hbxpp/xppextrn.ch + contrib/hbxpp/hbxppext.ch - contrib/hbxpp/xpp.ch + contrib/hbxpp/hbxpp.ch * contrib/hbxpp/tests/hbmk.hbm * utils/hbmk2/examples/contribf.hbc * Renamed 'xpp' lib to 'hbxpp'. Final name. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/Makefile trunk/harbour/contrib/hbxpp/Makefile trunk/harbour/contrib/hbxpp/tests/hbmk.hbm trunk/harbour/utils/hbmk2/examples/contribf.hbc Added Paths: --- trunk/harbour/contrib/hbxpp/ trunk/harbour/contrib/hbxpp/hbxpp.ch trunk/harbour/contrib/hbxpp/hbxpp.hbc trunk/harbour/contrib/hbxpp/hbxppext.ch Removed Paths: - trunk/harbour/contrib/hbxpp/xpp.ch trunk/harbour/contrib/hbxpp/xpp.hbc trunk/harbour/contrib/hbxpp/xppextrn.ch trunk/harbour/contrib/xpp/ 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] Re: About Harbour Documentation
2010/2/19 Viktor Szakáts harbour...@syenar.hu: For example, suppose I want to contribute documenting the hbsqlit3 contrib, wich is module I'm very interested. What I'm suposed to do? Create a directory /harbour/doc/en-EN/contrib/hbsqlit3 and write text files in NF format? All contribs are meant to be independent from core, so their docs should be stored in /contrib/name/doc/en-EN/* I searched for this en-EN locale identifier and it does not exists [1], [2] and [3]. It must be changed to en-US. [1] http://tools.ietf.org/html/rfc5646 [2] http://www.i18nguy.com/unicode/language-identifiers.html [3] http://en.wikipedia.org/wiki/Language_code Regards! -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour dialects
Okay, so with this change all dialect compatibility layers/subsystems are moved out from Harbour core to contrib or 3rd party domain. This means Harbour core is now purely for C5x features (both 5.2e and C5.3, latter always marked with HB_COMPAT_C53), plus Harbour extensions (always with 'hb' prefix). This also means that now it's possible to freely implement/extend any of these layers as simple 3rd party libs either in contrib area or elsewhere. As for naming rules and constraints, rule for contrib area are to use original names if those don't collide with core, or possibly with other contribs/3rd parties, and use 'xpp_', 'fs_', 'clip_', 'vo_', 'dbase_' (or even 'xhb_') prefix in respective dialects, if there is a chance for collision (f.e. to implement a dirty extension). If someone wants to be on the safe side, the easiest is to always use these prefixes. Each of these libs can have a central .ch header which implements commands, translations and extra constants, here the name of the .ch is the same as of the lib itself (f.e. hbfship.ch and hbxpp.ch). For non-contrib implementation, above rule is only a recommendation. Currently Harbour SVN implements these libs in contrib area: - hbfship: FlagShip compatibility lib - hbxpp: Xbase++ core compatibility lib - xhb: xhb compatibility lib Brgds, Viktor On 2010 Feb 20, at 13:03, vszak...@users.sourceforge.net wrote: Revision: 13933 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13933view=rev Author: vszakats Date: 2010-02-20 12:03:26 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 13:02 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/Makefile - contrib/xpp + contrib/hbxpp * contrib/hbxpp/Makefile - contrib/hbxpp/xpp.hbc + contrib/hbxpp/hbxpp.hbc - contrib/hbxpp/xppextrn.ch + contrib/hbxpp/hbxppext.ch - contrib/hbxpp/xpp.ch + contrib/hbxpp/hbxpp.ch * contrib/hbxpp/tests/hbmk.hbm * utils/hbmk2/examples/contribf.hbc * Renamed 'xpp' lib to 'hbxpp'. Final name. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/Makefile trunk/harbour/contrib/hbxpp/Makefile trunk/harbour/contrib/hbxpp/tests/hbmk.hbm trunk/harbour/utils/hbmk2/examples/contribf.hbc Added Paths: --- trunk/harbour/contrib/hbxpp/ trunk/harbour/contrib/hbxpp/hbxpp.ch trunk/harbour/contrib/hbxpp/hbxpp.hbc trunk/harbour/contrib/hbxpp/hbxppext.ch Removed Paths: - trunk/harbour/contrib/hbxpp/xpp.ch trunk/harbour/contrib/hbxpp/xpp.hbc trunk/harbour/contrib/hbxpp/xppextrn.ch trunk/harbour/contrib/xpp/ 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: About Harbour Documentation
Hi Daniel, For example, suppose I want to contribute documenting the hbsqlit3 contrib, wich is module I'm very interested. What I'm suposed to do? Create a directory /harbour/doc/en-EN/contrib/hbsqlit3 and write text files in NF format? All contribs are meant to be independent from core, so their docs should be stored in /contrib/name/doc/en-EN/* I searched for this en-EN locale identifier and it does not exists [1], [2] and [3]. It must be changed to en-US. [1] http://tools.ietf.org/html/rfc5646 [2] http://www.i18nguy.com/unicode/language-identifiers.html [3] http://en.wikipedia.org/wiki/Language_code Or rather plain 'en'? Can you confirm, if this is the valid ID for dialect-neutral English language? [ Unless we want to even have separate 'US' and 'GB' English dialect docs, which I believe we don't. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
It's better to use en-US, to better distinguish from others and to avoid mistakes. We should always follow the pattern xx-YY. 2010/2/20 Viktor Szakáts harbour...@syenar.hu: Hi Daniel, For example, suppose I want to contribute documenting the hbsqlit3 contrib, wich is module I'm very interested. What I'm suposed to do? Create a directory /harbour/doc/en-EN/contrib/hbsqlit3 and write text files in NF format? All contribs are meant to be independent from core, so their docs should be stored in /contrib/name/doc/en-EN/* I searched for this en-EN locale identifier and it does not exists [1], [2] and [3]. It must be changed to en-US. [1] http://tools.ietf.org/html/rfc5646 [2] http://www.i18nguy.com/unicode/language-identifiers.html [3] http://en.wikipedia.org/wiki/Language_code Or rather plain 'en'? Can you confirm, if this is the valid ID for dialect-neutral English language? [ Unless we want to even have separate 'US' and 'GB' English dialect docs, which I believe we don't. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error: Unresolved external '_HB_FUN_CURDRIVE'
Hi!I can't build harbour $Id: ChangeLog 13933 2010-02-20 12:03:26Z vszakats $../../../../../bin/win/bcc/harbour.exe ../../../hbmk2.prg -i./../../../../include -n1 -q0 -w3 -es2 -kmo -i- -lbcc32.exe -I. -I../../../../../include -q -tWM -CP437 -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF -I"c:\dev\borland\bcc55\bin\..\Include" -ohbmk2.obj -c hbmk2.chbmk2.c:ilink32.exe -L"c:\dev\borland\bcc55\bin\..\Lib" -L"c:\dev\borland\bcc55\bin\..\Lib\PSDK" -L"..\..\..\..\..\lib\win\bcc" -Gn -Tpe c0x32.obj hbmk2.obj, "..\..\..\..\..\bin\win\bcc\hbmk2.exe", nul, hbcplr hbpp hbcommon hbextern hbdebug hbvmmt hbrtl hblang hbcpage gtcgi gtpca gtstd gtwvt gtgui gtwin hbnulrdd hbrtl hbvmmt hbmacro hbcplr hbpp hbcommon hbpcre hbzlib kernel32 user32 ws2_32 advapi32 gdi32 cw32mt import32Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 BorlandError: Unresolved external '_HB_FUN_CURDRIVE' referenced from C:\DEV\HARBOUR_SVN\UTILS\HBMK2\OBJ\WIN\BCC\HBMK2.OBJRegards,Alexey Myronenko ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error: Unresolved external '_HB_FUN_CURDRIVE'
Hi, on Ubuntu 9.10 32bit Recompiling Harbour SVN Rev.: 13933 I get make[3]: `../../../../../bin/linux/gcc/hbrun' is up to date. gcc -L../../../../../lib/linux/gcc -L/usr/X11R6/lib -o../../../../../bin/linux/gcc/hbmk2 hbmk2.o -lhbcplr -lhbpp -lhbcommon -lhbextern -lhbdebug -lhbvmmt -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtcrs -lgtsln -lgtxwc -lgttrm -lhbnulrdd -lhbrtl -lhbvmmt -lhbmacro -lhbcplr -lhbpp -lhbcommon -lncurses -lslang -lX11 -lgpm -lpcre -lz -lrt -ldl -lpthread -lm hbmk2.o:(.data+0xb18): undefined reference to `HB_FUN_CURDRIVE' collect2: ld returned 1 exit status make[3]: *** [hbmk2] Error 1 make[2]: *** [descend] Error 2 make[1]: *** [hbmk2] Error 2 make: *** [utils] Error 2 ! Building Harbour 2.1.0dev from source - http://www.harbour-project.org Thank you Best regards Marco ___ 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:[13934] trunk/harbour
Revision: 13934 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13934view=rev Author: vszakats Date: 2010-02-20 14:56:27 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 15:55 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/philes.c * include/hbextern.ch + Added HB_CURDRIVE(). Similar to Xbase++ CURDRIVE(), but always provided by Harbour core. * utils/hbmk2/hbmk2.prg - Deleted mapping from hb_CurDrive() to CurDrive(). * examples/httpsrv/uhttpd.prg * examples/httpsrv/modules/tableservletdb.prg * examples/gtwvw/tests/wvwtest9.prg * Changed to use hb_CurDrive() which is always available in Harbour core, instead of Xbase++ specific CurDrive(). Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/examples/gtwvw/tests/wvwtest9.prg trunk/harbour/examples/httpsrv/modules/tableservletdb.prg trunk/harbour/examples/httpsrv/uhttpd.prg trunk/harbour/include/hbextern.ch trunk/harbour/src/rtl/philes.c trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error: Unresolved external '_HB_FUN_CURDRIVE'
same in win WIN-MAKE[2]: [install] Error 1 (ignored) ../../../../../bin/win/mingw/harbour.exe ../../../hbrun.prg -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer -march=i586 -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF -ohbrun.o -c hbrun.c gcc -L../../../../../lib/win/mingw -o ..\..\..\..\..\bin\win\mingw\hbrun.exe hbrun.o -lhbcplr -lhbpp -lhbcommon -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwvt -lgtgui -lgtwin -lhbrdd -lrddntx -lrddnsx -lrddcdx -lrddfpt -lhbsix -lhbhsx -lhbusrrdd -lhbuddall -lhbrtl -lhbvm -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32 -lhbmainstd 1 file copiati. ../../../../../bin/win/mingw/harbour.exe ../../../hbmk2.prg -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer -march=i586 -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF -ohbmk2.o -c hbmk2.c gcc -L../../../../../lib/win/mingw -o ..\..\..\..\..\bin\win\mingw\hbmk2.exe hbmk2.o -lhbcplr -lhbpp -lhbcommon -lhbextern -lhbdebug -lhbvmmt -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwvt -lgtgui -lgtwin -lhbnulrdd -lhbrtl -lhbvmmt -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32 -lhbmainstd hbmk2.o:hbmk2.c:(.data+0xb38): undefined reference to `HB_FUN_CURDRIVE' collect2: ld returned 1 exit status WIN-MAKE[3]: *** [hbmk2.exe] Error 1 WIN-MAKE[2]: *** [descend] Error 2 WIN-MAKE[1]: *** [hbmk2.inst] Error 2 WIN-MAKE: *** [utils.inst] Error 2 2010/2/20 vat...@polly.com.ua: Hi! I can't build harbour $Id: ChangeLog 13933 2010-02-20 12:03:26Z vszakats $ ../../../../../bin/win/bcc/harbour.exe ../../../hbmk2.prg -i./../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l bcc32.exe -I. -I../../../../../include -q -tWM -CP437 -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF -Ic:\dev\borland\bcc55\bin\..\Include -ohbmk2.obj -c hbmk2.c hbmk2.c: ilink32.exe -Lc:\dev\borland\bcc55\bin\..\Lib -Lc:\dev\borland\bcc55\bin\..\Lib\PSDK -L..\..\..\..\..\lib\win\bcc -Gn -Tpe c0x32.obj hbmk2.obj, ..\..\..\..\..\bin\win\bcc\hbmk2.exe, nul, hbcplr hbpp hbcommon hbextern hbdebug hbvmmt hbrtl hblang hbcpage gtcgi gtpca gtstd gtwvt gtgui gtwin hbnulrdd hbrtl hbvmmt hbmacro hbcplr hbpp hbcommon hbpcre hbzlib kernel32 user32 ws2_32 advapi32 gdi32 cw32mt import32 Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Error: Unresolved external '_HB_FUN_CURDRIVE' referenced from C:\DEV\HARBOUR_SVN\UTILS\HBMK2\OBJ\WIN\BCC\HBMK2.OBJ Regards, Alexey Myronenko ___ 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] SF.net SVN: harbour-project:[13936] trunk/harbour
Revision: 13936 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13936view=rev Author: vszakats Date: 2010-02-20 15:39:33 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 16:39 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/memvars.c * src/common/hbverdsp.c * doc/whatsnew.txt * include/hbsetup.ch * utils/hbtest/rt_str.prg * 5.3x - 5.3b Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/doc/whatsnew.txt trunk/harbour/include/hbsetup.ch trunk/harbour/src/common/hbverdsp.c trunk/harbour/src/vm/memvars.c trunk/harbour/utils/hbtest/rt_str.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] Re: About Harbour Documentation
I think we should use the IETF format, (the W3C model that Viktor mentioned) http://en.wikipedia.org/wiki/IETF_language_tag only two letters, except when we need it. As we lack documentation, at this stage it doesn't make sense to me even to split the pt language into pt-BR (my language) and pt only. We can use the ietf shortest code rule adding the -SUBCODE only when the necessity arrives. You can find the table here: http://www.iana.org/assignments/language-subtag-registry 2010/2/20 Daniel Gonçalves dan...@base4.com.br: Ok Viktor, I suggested the pattern because on other open-source projects I follow and participate, they use the pattern xx-YY, but I will use the rules for Harbour project. I hope you guys understands that I not trying to impose anything. I'm just trying to help using my knowledge and experience from other spheres! 2010/2/20 Viktor Szakáts harbour...@syenar.hu: It's just a pattern, so we all know that always be xx-YY for ALL languages and not xx for that one and for the other, but for another it is xx-YY, i guess! See! To avoid more things to think about! But this pattern is not true to the standard, it can also be xx, xx-YYY, xx-y-zzz, see the RFC. Each have different and meaningful meanings. I've just made an admonition: en-EN does not exists. I know, that's why I started this discussion in the first place :) If we follow a pattern, it will be one less thing to be concerned about. :-) I think we should follow the standard, rather than a limited pattern. If we invent our own pattern, it will not be possible to interchange our language code with tools which adhere to standards. BTW we should only worry about this _once_ for each language we translate our documentation to. So far we have bits in English and Spanish only, so it's not very complicated. Moreover IMO we should first concentrate on English only. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13937] trunk/harbour
Revision: 13937 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13937view=rev Author: druzus Date: 2010-02-20 17:07:00 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 18:05 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/task.c ! fixed casting for C++ builds * harbour/src/lang/msges.c ! added hack for Solaris builds where ES is macro TODDO: sync names of lang and corresponding code modules. * harbour/src/vm/dynlibhb.c * pacified warning * harbour/contrib/xpp/xppextrn.ch * harbour/contrib/xpp/dbcmdx.c * harbour/include/hbextern.ch * harbour/src/rdd/dbcmd53.c ! moved ordWildSeek() from XPP to HBRDD library. I have no idea if XPP has such function or if it's or not compatible with ORDWILDSEEK() functions I created for [x]Harbour * disable ordCount() and ordWildSeek() functions when HB_CLP_STRICT macro is set * harbour/include/hbsocket.ch + added macro values interface info flags: HB_SOCKET_IFF_* + added macro values for interface info array indexes: HB_SOCKET_IFINFO_* * harbour/include/hbsocket.h * harbour/src/rtl/hbsocket.c + added new C function: PHB_ITEM hb_socketGetIFaces( int af, HB_BOOL fNoAliases ); it returns array with existing interfaces description. This code was added for non MS-Windows based platforms only. Support for MS-Windows has to be added yet. Some platforms may not fill all fields in the returned array. When some fields are not supported by platform or interface then they can contain NIL value. On some platforms this code can effectively work only with IP4 interfaces and IP6 ones will need different implementation. TODO: add support for alternative long interface introduced in some new systems using 'struct lifreq' with SIOCGLIF* ioctls instead of 'struct ifreq' and SIOCGIF* TODO: add support for extracting hardware addreses (i.e. ethernet macaddresses) for systems which do not support SIOCGIFHWADDR. Please test this code with OS2 using OpenWatcom and GCC (old and new socket API). I enabled HB_HAS_SOCKADDR_SA_LEN in OS2 builds. OpenWatocm OS2 header files have such fields but I do know if it's also present in GCC socket API. * harbour/include/hbextern.ch * harbour/src/rtl/hbinet.c + added new PRG function: hb_inetIfInfo( [lNoAliases] [, nAddrFamily] ) - aInfo lNoAliases is .F. by default so aliases are included nAddrFamily is HB_SOCKET_AF_INET by default aInfo is an array in which each entry is also array with the following fields: HB_SOCKET_IFINFO_FAMILY1 // adress family HB_SOCKET_IFINFO_NAME 2 // interface name HB_SOCKET_IFINFO_FLAGS 3 // flags HB_SOCKET_IFF_* HB_SOCKET_IFINFO_ADDR 4 // interface address HB_SOCKET_IFINFO_NETMASK 5 // subnetmask HB_SOCKET_IFINFO_BROADCAST 6 // broadcast address HB_SOCKET_IFINFO_P2PADDR 7 // point-to-point address HB_SOCKET_IFINFO_HWADDR8 // hardware address Please use this code on different non MS-Windows platforms: proc main( noAlias ) local iface ? os(), version() ? interfaces: for each iface in hb_inetIfInfo( !empty( noAlias ), 0 ) ? hb_valToExp( iface ) next ? return and check if it returns correct information about available interfaces. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbxpp/dbcmdx.c trunk/harbour/contrib/hbxpp/hbxppext.ch trunk/harbour/include/hbextern.ch trunk/harbour/include/hbsocket.ch trunk/harbour/include/hbsocket.h trunk/harbour/src/lang/msges.c trunk/harbour/src/rdd/dbcmd53.c trunk/harbour/src/rtl/hbinet.c trunk/harbour/src/rtl/hbsocket.c trunk/harbour/src/vm/dynlibhb.c trunk/harbour/src/vm/task.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error building WinCE
Hi, I'm trying build WinCE-HB and i get : gcc -I. -I../../../../../include -Wall -W -O2 -fomit-frame-pointer -DHB_LEGACY_TYPES_OFF -DUNICODE -ohbpp.o -c ../../../hbpp.c gcc -L../../../../../lib/wce/mingwarm -o ..\..\..\..\..\bin\wce\mingwarm\hbpp.exe hbpp.o -lhbnortl -lhbcommon -lcoredll -lws2 d:/qt/4.5.3/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: cannot find -lcoredll collect2: ld returned 1 exit status mingw32-make[3]: *** [hbpp.exe] Error 1 rm hbpp.o mingw32-make[2]: *** [descend] Error 2 mingw32-make[1]: *** [pp.inst] Error 2 mingw32-make: *** [src.inst] Error 2 Waht's wrong ? My batch : SET PATH=D:\Qt\4.5.3\mingw\bin;%PATH% SET HB_BIN_COMPILE=D:\LASTHB\HARBOUR\bin SET HB_PLATFORM=wce SET HB_COMPILER=mingwarm SET HB_WITH_QT=D:\Qt\4.5.3\include SET HB_DIR_QT=D:\Qt\4.5.3 SET HB_QT_STATIC=yes SET HB_INSTALL_PREFIX=%~dp0 win-make clean install %1 %2 log-%HB_COMPILER%.txt 21 You will need the CEGCC version of mingw to create WinCE Harbour build, the Win32 edition won't do. See INSTALL for links and examples. After modifications : SET PATH=D:\hb20\comp\mingwarm\opt\mingw32ce\bin;%PATH% SET HB_BIN_COMPILE=D:\LASTHB\HARBOUR\bin SET HB_WITH_QT=D:\Qt\4.5.3\include SET HB_DIR_QT=D:\Qt\4.5.3 SET HB_QT_STATIC=yes SET HB_INSTALL_PREFIX=%~dp0 mingw32-make clean install %1 %2 log-%HB_COMPILER%.txt 21 ! Building Harbour 2.1.0dev from source - http://www.harbour-project.org ! MAKE: win-make 3.81 sh.exe clean install ! HB_INSTALL_PREFIX: D:\LASTHB\HARBOUR\ ! HB_HOST_PLAT: win (x86) HB_SHELL: nt ! HB_PLATFORM: wce (arm) (autodetected) ! HB_COMPILER: mingwarm (autodetected: D:/hb20/comp/mingwarm/opt/mingw32ce/bin/) ! HB_BIN_COMPILE: D:\LASTHB\HARBOUR\bin . . . arm-mingw32ce-gcc -I. -I../../../../../include -O2 -fomit-frame-pointer -DHB_LEGACY_TYPES_OFF -DUNICODE -D_WIN32_WCE -osqlite3.o -c ../../../sqlite3.c win-make[3]: *** [sqlite3.o] Error 1 win-make[2]: *** [descend] Error 2 win-make[1]: *** [sqlite3.inst] Error 2 win-make: *** [external.inst] Error 2 And what's wrong now ? -- Regards, Jaroslaw Kadziola ___ 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:[13938] trunk/harbour
Revision: 13938 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13938view=rev Author: druzus Date: 2010-02-20 17:36:15 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 18:36 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbsqlit3/hbsqlit3.c ! fixed to work without [U]LONGLONG defined in hbdefs.h Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbsqlit3/hbsqlit3.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13939] trunk/harbour
Revision: 13939 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13939view=rev Author: druzus Date: 2010-02-20 17:48:00 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 18:47 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/hbsocket.c ! fixed typo Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rtl/hbsocket.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Hbide ready to use
done http://harbourlanguage.blogspot.com/ I have problem with same image and receive an error when exit Visual c++ runtime library this application has requested the runtime to terminate in an unsual way please contact the application's support team for more information How can i correct? Why messages is sent from Visual c++ runtime if am using mingw? 2010/2/19 Pritpal Bedi bediprit...@hotmail.com: Massimo Belgrano wrote: here is updated incremental guide for hbide http://harbourlanguage.blogspot.com/ Your blog is almost outdated now. Take a look at the interface with new goodies. A lot has changed. -- Massimo Belgrano ___ 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:[13940] trunk/harbour
Revision: 13940 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13940view=rev Author: vszakats Date: 2010-02-20 18:32:39 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 19:32 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rdd/Makefile * src/rdd/dbcmd53.c + src/rdd/ordwldsk.c + src/rdd/ordcount.c + Moved Harbour extensions in Clipper namespace to separate sources. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rdd/Makefile trunk/harbour/src/rdd/dbcmd53.c Added Paths: --- trunk/harbour/src/rdd/ordcount.c trunk/harbour/src/rdd/ordwldsk.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error building WinCE
You will need the CEGCC version of mingw to create WinCE Harbour build, the Win32 edition won't do. See INSTALL for links and examples. After modifications : SET PATH=D:\hb20\comp\mingwarm\opt\mingw32ce\bin;%PATH% SET HB_BIN_COMPILE=D:\LASTHB\HARBOUR\bin SET HB_WITH_QT=D:\Qt\4.5.3\include SET HB_DIR_QT=D:\Qt\4.5.3 SET HB_QT_STATIC=yes SET HB_INSTALL_PREFIX=%~dp0 mingw32-make clean install %1 %2 log-%HB_COMPILER%.txt 21 ! Building Harbour 2.1.0dev from source - http://www.harbour-project.org ! MAKE: win-make 3.81 sh.exe clean install ! HB_INSTALL_PREFIX: D:\LASTHB\HARBOUR\ ! HB_HOST_PLAT: win (x86) HB_SHELL: nt ! HB_PLATFORM: wce (arm) (autodetected) ! HB_COMPILER: mingwarm (autodetected: D:/hb20/comp/mingwarm/opt/mingw32ce/bin/) ! HB_BIN_COMPILE: D:\LASTHB\HARBOUR\bin . . . arm-mingw32ce-gcc -I. -I../../../../../include -O2 -fomit-frame-pointer -DHB_LEGACY_TYPES_OFF -DUNICODE -D_WIN32_WCE -osqlite3.o -c ../../../sqlite3.c win-make[3]: *** [sqlite3.o] Error 1 win-make[2]: *** [descend] Error 2 win-make[1]: *** [sqlite3.inst] Error 2 win-make: *** [external.inst] Error 2 And what's wrong now ? Since there is no visible error in above log, I can just guess it's an installation problem. INSTALL says you need Cygwin in PATH, probably it's missing. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi Bacco, I think we should use the IETF format, (the W3C model that Viktor mentioned) http://en.wikipedia.org/wiki/IETF_language_tag only two letters, except when we need it. As we lack documentation, at this stage it doesn't make sense to me even to split the pt language into pt-BR (my language) and pt only. We can use the ietf shortest code rule adding the -SUBCODE only when the necessity arrives. I'm not familiar with Brazil dialect of Portuguese language, but if it's practically different from regular Portuguese, IMO we should use pt-BR as per the standard. We use this code already for Portuguese translation of hbmk2, and I just suspect it was used for good reason. A native speaker is better to make it clear here. All in all, let's use what the standard dictates, and not uniformly xx or uniformly xx-YY. For example, the proper code for Hungarian language is 'hu-HU'. (for generic English it's 'en'). Brgds, Viktor You can find the table here: http://www.iana.org/assignments/language-subtag-registry 2010/2/20 Daniel Gonçalves dan...@base4.com.br: Ok Viktor, I suggested the pattern because on other open-source projects I follow and participate, they use the pattern xx-YY, but I will use the rules for Harbour project. I hope you guys understands that I not trying to impose anything. I'm just trying to help using my knowledge and experience from other spheres! 2010/2/20 Viktor Szakáts harbour...@syenar.hu: It's just a pattern, so we all know that always be xx-YY for ALL languages and not xx for that one and for the other, but for another it is xx-YY, i guess! See! To avoid more things to think about! But this pattern is not true to the standard, it can also be xx, xx-YYY, xx-y-zzz, see the RFC. Each have different and meaningful meanings. I've just made an admonition: en-EN does not exists. I know, that's why I started this discussion in the first place :) If we follow a pattern, it will be one less thing to be concerned about. :-) I think we should follow the standard, rather than a limited pattern. If we invent our own pattern, it will not be possible to interchange our language code with tools which adhere to standards. BTW we should only worry about this _once_ for each language we translate our documentation to. So far we have bits in English and Spanish only, so it's not very complicated. Moreover IMO we should first concentrate on English only. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ 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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error building WinCE
Hi,
Since there is no visible error in above log, I can
just guess it's an installation problem. INSTALL says
you need Cygwin in PATH, probably it's missing.
Cygwin added to path and full log is :
! Building Harbour 2.1.0dev from source - http://www.harbour-project.org
! MAKE: win-make 3.81 D:/hb20/cygwin/bin/sh.exe clean install
! HB_INSTALL_PREFIX: D:\LASTHB\HARBOUR\
! HB_HOST_PLAT: win (x86) HB_SHELL: nt
! HB_PLATFORM: wce (arm) (autodetected)
! HB_COMPILER: mingwarm (autodetected: D:/hb20/comp/mingwarm/opt/mingw32ce/bin/)
! HB_BIN_COMPILE: D:\LASTHB\HARBOUR\bin
! Component: 'zlib' found in D:/LASTHB/HARBOUR/external/zlib (local)
! Component: 'pcre' found in D:/LASTHB/HARBOUR/external/pcre (local)
! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL.
! Component: 'gpm' not supported on wce 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 wce 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)
! 'gtwin' library skipped (platform not supported)
! 'gtxwc' library skipped (component not found)
! 'gtwvg' library skipped (platform not supported)
! 'gtalleg' library skipped ('allegro' not supported with mingwarm compiler)
! 'hbblat' library skipped (platform not supported)
! 'hbcairo' library skipped ('cairo' not found. Configure with HB_WITH_CAIRO.)
! 'hbcurl' library skipped ('libcurl' not found. Configure with HB_WITH_CURL.)
! 'hbfbird' library skipped ('firebird' not found. Configure with
HB_WITH_FIREBIRD.)
! 'hbfimage' library skipped ('freeimage' not found. Configure with
HB_WITH_FREEIMAGE.)
! '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_PGSQL.)
! Using QT 'moc' executable: D:\Qt\4.5.3\include\..\bin\moc.exe (autodetected)
! 'hbssl' library skipped (component not found)
! 'rddads' library skipped ('ads' not found. Configure with HB_WITH_ADS.)
! 'sddmy' library skipped ('mysql' not found. Configure with HB_WITH_MYSQL.)
! 'sddpg' library skipped ('postgresql' not found. Configure with
HB_WITH_PGSQL.)
! 'sddfb' library skipped ('firebird' not found. Configure with
HB_WITH_FIREBIRD.)
! Skip install, destination dir 'D:\LASTHB\HARBOUR\\doc' is the same as source
! Skip install, destination dir 'D:\LASTHB\HARBOUR\\doc/en-EN' is the same as
source
! Skip install, destination dir 'D:\LASTHB\HARBOUR\\include' is the same as
source
arm-mingw32ce-gcc -I. -I../../../../../include -O2 -fomit-frame-pointer
-DHB_LEGACY_TYPES_OFF -DUNICODE -D_WIN32_WCE -osqlite3.o -c ../../../sqlite3.c
win-make[3]: *** [sqlite3.o] Error 1
win-make[2]: *** [descend] Error 2
win-make[1]: *** [sqlite3.inst] Error 2
win-make: *** [external.inst] Error 2
--
Regards,
Jaroslaw Kadziola
___
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:[13878] trunk/harbour
From: Viktor Szakáts harbour...@syenar.hu Sent: Saturday, February 20, 2010 3:22 AM Subject: Re: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour Hi Andrzej, From: vszak...@users.sourceforge.net Revision: 13878 [...] * contrib/hbwin/hbwin.ch * Changed to use full (0xFF) color components for RGB presets. Viktor, this change is incompatible with Clipper. Previous colours were too dark, but 0xFF should stand for BRIGHT colours. Clipper uses RGBI palette, see here: * 4-bit RGBI palettes for explanation: http://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#4-bit_RGBI * EGA colour palette for hex values in implementation: http://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter#The_EGA_color_palette Clipper had no graphical printing, nor any special color printing support for that matter, RGBI palette is NOT for printing. I did NOT mention about printing at all. nor did it determine the actual colors that appeared on screen, so it's by no means a Clipper compatibility issue. Clipper did NOT define any *own* palette, it just used CGA palette available in DOS. The palette is used as CGA compatibility palette in EGA/VGA/Windows till now. If you mean to mimic MS-DOS (or rather VGA/EGA) screen colors in Windows printing, I can't see strong reason why this would be desired. I am not DTP professional, but I know at least two facts: * You cannot mix RGB and CMYK colour models. RGB is for screen, CMYK is for printing. All RGB_* #defines are in RGB colour model, so they are not to be used for printing. See: http://en.wikipedia.org/wiki/RGB_color_model * There is no simple colour conversion from RGB to CMYK. See: http://en.wikipedia.org/wiki/CMYK_color_model#Conversion As you already know, Clipper did NOT define any print colours and did NOT use any known printing colour palette. We can use system colour management (see http://en.wikipedia.org/wiki/Color_management) or define our own colour conversion scheme, but the palette should contain all 16 colours, normal and BRIGHT. --- (from old hbwin.ch) #define RGB_BLACK RGB( 0x00, 0x00, 0x00 ) #define RGB_BLUE RGB( 0x00, 0x00, 0x85 ) #define RGB_GREEN RGB( 0x00, 0x85, 0x00 ) #define RGB_CYAN RGB( 0x00, 0x85, 0x85 ) #define RGB_REDRGB( 0x85, 0x00, 0x00 ) #define RGB_MAGENTARGB( 0x85, 0x00, 0x85 ) #define RGB_BROWN RGB( 0x85, 0x85, 0x00 ) #define RGB_WHITE RGB( 0xC6, 0xC6, 0xC6 ) --- Once again, the above colours are in RGB colour model. They are defined for display, not for printing. That is not full Clipper colour palette, only non-BRIGHT part, and brown defined here is not brown on screen. F.e. why isn't white 0x85/0x85/0x85 to be consistent with other colors, or even more, why isn't it pure white: 0xFF/0xFF/0xFF, instead of being grey? :) I DID write and you DID quote: Previous colours were too dark, that's why they are inconsistent. I DID also write 0xFF should stand for BRIGHT colours, that's why white is really light grey. And I know that real white may be darker then the displayed one[1]. I linked also the explanation, why brown setting should be inconsistent, did you read it? I don't know why someone used such RGB values for the old colours – maybe he/she picked them from his/her own display or corrected them as CGA colours were too bright in his/her opinion. Still they are colours defined in RGB colour model, that is – for display, not for printing. [1] A good example for troubles with colour conversion for red and white you can see here: http://en.wikipedia.org/wiki/Flag_of_Poland#Design http://en.wikipedia.org/wiki/File:Flag_of_Poland.svg http://commons.wikimedia.org/wiki/File:Flag_of_Poland_(normative).svg Maybe on your screen you cannot see differences between the flag and the background colour in any places, but they are. Use some colour picker to check RGB codes or use some good old CRT monitor. -- Regards from The Harbour Project mirror in Poland Andrzej P. Woźniak -- Hosting 2GB za 40 zl brutto http://www.klatka.pl ___ 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:[13878] trunk/harbour
Hi Andrzej, Viktor, this change is incompatible with Clipper. Previous colours were too dark, but 0xFF should stand for BRIGHT colours. Clipper uses RGBI palette, see here: * 4-bit RGBI palettes for explanation: http://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#4-bit_RGBI * EGA colour palette for hex values in implementation: http://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter#The_EGA_color_palette Clipper had no graphical printing, nor any special color printing support for that matter, RGBI palette is NOT for printing. I did NOT mention about printing at all. That's right. It was originally added for printing in context of the hbwin code though. nor did it determine the actual colors that appeared on screen, so it's by no means a Clipper compatibility issue. Clipper did NOT define any *own* palette, it just used CGA palette available in DOS. The palette is used as CGA compatibility palette in EGA/VGA/Windows till now. Yes. If you mean to mimic MS-DOS (or rather VGA/EGA) screen colors in Windows printing, I can't see strong reason why this would be desired. I am not DTP professional, but I know at least two facts: * You cannot mix RGB and CMYK colour models. RGB is for screen, CMYK is for printing. All RGB_* #defines are in RGB colour model, so they are not to be used for printing. See: http://en.wikipedia.org/wiki/RGB_color_model * There is no simple colour conversion from RGB to CMYK. See: http://en.wikipedia.org/wiki/CMYK_color_model#Conversion Nevertheless when you print using GDI on Windows, and there you can specify your colors in RGB. Maybe there is alternative way, I don't know, but our current codebase doesn't support it. As you already know, Clipper did NOT define any print colours and did NOT use any known printing colour palette. We can use system colour management (see http://en.wikipedia.org/wiki/Color_management) or define our own colour conversion scheme, but the palette should contain all 16 colours, normal and BRIGHT. I'm not sure I see your point. These colors are not meant to mimic original EGA/VGA colors. They are just presets for some RGB colors. They have nothing to do with SETCOLOR() functionality. --- (from old hbwin.ch) #define RGB_BLACK RGB( 0x00, 0x00, 0x00 ) #define RGB_BLUE RGB( 0x00, 0x00, 0x85 ) #define RGB_GREEN RGB( 0x00, 0x85, 0x00 ) #define RGB_CYAN RGB( 0x00, 0x85, 0x85 ) #define RGB_REDRGB( 0x85, 0x00, 0x00 ) #define RGB_MAGENTARGB( 0x85, 0x00, 0x85 ) #define RGB_BROWN RGB( 0x85, 0x85, 0x00 ) #define RGB_WHITE RGB( 0xC6, 0xC6, 0xC6 ) --- Once again, the above colours are in RGB colour model. They are defined for display, not for printing. That is not full Clipper colour palette, only non-BRIGHT part, and brown defined here is not brown on screen. It was not the goal to be full Clipper palette. One may of course create Clipper-alike colors by using different values, but I can't see any use of that in hbwin.ch, neither does it seem like this was intent of original developers using above values. F.e. why isn't white 0x85/0x85/0x85 to be consistent with other colors, or even more, why isn't it pure white: 0xFF/0xFF/0xFF, instead of being grey? :) I DID write and you DID quote: Previous colours were too dark, that's why they are inconsistent. I DID also write 0xFF should stand for BRIGHT colours, that's why white is really light grey. And I know that real white may be darker then the displayed one[1]. I linked also the explanation, why brown setting should be inconsistent, did you read it? Well, if your point is that '0xFF/0xFF/0x00' color is wrongly named BROWN, when it should be YELLOW, I see it now. But it's much easier if you say so, or, it's possible I'm still missing your point. I'll commit a fix for the name of that one color. I don't know why someone used such RGB values for the old colours – maybe he/she picked them from his/her own display or corrected them as CGA colours were too bright in his/her opinion. Still they are colours defined in RGB colour model, that is – for display, not for printing. My best guess is that they were picked randomly, or by personal choice. [1] A good example for troubles with colour conversion for red and white you can see here: http://en.wikipedia.org/wiki/Flag_of_Poland#Design http://en.wikipedia.org/wiki/File:Flag_of_Poland.svg http://commons.wikimedia.org/wiki/File:Flag_of_Poland_(normative).svg Maybe on your screen you cannot see differences between the flag and the background colour in any places, but they are. Use some colour picker to check RGB codes or use some good old CRT monitor. I can see it and it's interesting article (I like flags), just can't see your exact point, sorry. In hbwin.ch these are just a few predefined constants to save some typing, for those users who need these basic RGB
[Harbour] SF.net SVN: harbour-project:[13941] trunk/harbour
Revision: 13941 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13941view=rev Author: vszakats Date: 2010-02-20 19:52:51 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 20:52 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/hbwin.ch ! Renamed HB_WIN_RGB_BROWN to HB_WIN_RGB_YELLOW to match real RGB color. I left old RGB_BROWN as is, even if was never really set to brown. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwin.ch 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] Re: About Harbour Documentation
I am a native pt-BR speaker, and I am web developer also, and here we use pt-BR on the web pages. Of course I like the idea to have pt-BR translation (and contribute too). May we agree in the IETF format? Maybe we can add the most wanted language folders to the main doc folder and into dirstruc.txt, to serve as example and eliminate the needs for further discussion about this theme. At least doc/en (just rename back) doc/es doc/pt-BR (maybe some placeholder.txt so it doesnt stay empty) Regards Bacco On Sat, Feb 20, 2010 at 17:01, Viktor Szakáts harbour...@syenar.hu wrote: Hi Bacco, I think we should use the IETF format, (the W3C model that Viktor mentioned) http://en.wikipedia.org/wiki/IETF_language_tag only two letters, except when we need it. As we lack documentation, at this stage it doesn't make sense to me even to split the pt language into pt-BR (my language) and pt only. We can use the ietf shortest code rule adding the -SUBCODE only when the necessity arrives. I'm not familiar with Brazil dialect of Portuguese language, but if it's practically different from regular Portuguese, IMO we should use pt-BR as per the standard. We use this code already for Portuguese translation of hbmk2, and I just suspect it was used for good reason. A native speaker is better to make it clear here. All in all, let's use what the standard dictates, and not uniformly xx or uniformly xx-YY. For example, the proper code for Hungarian language is 'hu-HU'. (for generic English it's 'en'). Brgds, Viktor You can find the table here: http://www.iana.org/assignments/language-subtag-registry 2010/2/20 Daniel Gonçalves dan...@base4.com.br: Ok Viktor, I suggested the pattern because on other open-source projects I follow and participate, they use the pattern xx-YY, but I will use the rules for Harbour project. I hope you guys understands that I not trying to impose anything. I'm just trying to help using my knowledge and experience from other spheres! 2010/2/20 Viktor Szakáts harbour...@syenar.hu: It's just a pattern, so we all know that always be xx-YY for ALL languages and not xx for that one and for the other, but for another it is xx-YY, i guess! See! To avoid more things to think about! But this pattern is not true to the standard, it can also be xx, xx-YYY, xx-y-zzz, see the RFC. Each have different and meaningful meanings. I've just made an admonition: en-EN does not exists. I know, that's why I started this discussion in the first place :) If we follow a pattern, it will be one less thing to be concerned about. :-) I think we should follow the standard, rather than a limited pattern. If we invent our own pattern, it will not be possible to interchange our language code with tools which adhere to standards. BTW we should only worry about this _once_ for each language we translate our documentation to. So far we have bits in English and Spanish only, so it's not very complicated. Moreover IMO we should first concentrate on English only. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ 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 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: About Harbour Documentation
On Sat, Feb 20, 2010 at 17:53, Bacco carlosba...@gmail.com wrote: I am a native pt-BR speaker, and I am web developer also, and here we use pt-BR on the web pages. Of course I like the idea to have pt-BR translation (and contribute too). May we agree in the IETF format? Maybe we can add the most wanted language folders to the main doc folder and into dirstruc.txt, to serve as example and eliminate the needs for further discussion about this theme. At least doc/en (just rename back) doc/es doc/pt-BR (maybe some placeholder.txt so it doesnt stay empty) (and eventually others that you are sure that will be needed, of course. These three I know that will be) Regards Bacco On Sat, Feb 20, 2010 at 17:01, Viktor Szakáts harbour...@syenar.hu wrote: Hi Bacco, I think we should use the IETF format, (the W3C model that Viktor mentioned) http://en.wikipedia.org/wiki/IETF_language_tag only two letters, except when we need it. As we lack documentation, at this stage it doesn't make sense to me even to split the pt language into pt-BR (my language) and pt only. We can use the ietf shortest code rule adding the -SUBCODE only when the necessity arrives. I'm not familiar with Brazil dialect of Portuguese language, but if it's practically different from regular Portuguese, IMO we should use pt-BR as per the standard. We use this code already for Portuguese translation of hbmk2, and I just suspect it was used for good reason. A native speaker is better to make it clear here. All in all, let's use what the standard dictates, and not uniformly xx or uniformly xx-YY. For example, the proper code for Hungarian language is 'hu-HU'. (for generic English it's 'en'). Brgds, Viktor You can find the table here: http://www.iana.org/assignments/language-subtag-registry 2010/2/20 Daniel Gonçalves dan...@base4.com.br: Ok Viktor, I suggested the pattern because on other open-source projects I follow and participate, they use the pattern xx-YY, but I will use the rules for Harbour project. I hope you guys understands that I not trying to impose anything. I'm just trying to help using my knowledge and experience from other spheres! 2010/2/20 Viktor Szakáts harbour...@syenar.hu: It's just a pattern, so we all know that always be xx-YY for ALL languages and not xx for that one and for the other, but for another it is xx-YY, i guess! See! To avoid more things to think about! But this pattern is not true to the standard, it can also be xx, xx-YYY, xx-y-zzz, see the RFC. Each have different and meaningful meanings. I've just made an admonition: en-EN does not exists. I know, that's why I started this discussion in the first place :) If we follow a pattern, it will be one less thing to be concerned about. :-) I think we should follow the standard, rather than a limited pattern. If we invent our own pattern, it will not be possible to interchange our language code with tools which adhere to standards. BTW we should only worry about this _once_ for each language we translate our documentation to. So far we have bits in English and Spanish only, so it's not very complicated. Moreover IMO we should first concentrate on English only. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ 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 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: About Harbour Documentation
I am a native pt-BR speaker, and I am web developer also, and here we use pt-BR on the web pages. Of course I like the idea to have pt-BR translation (and contribute too). May we agree in the IETF format? Yes. So to sum it up: Format: NANFORUM Location: root/doc/IETF language code/* Codepage: UTF-8 Some IETF language codes for well-known languages: en - English (generic) pt-BR - Portuguese (Brazil) es - Spanish (generic) hu-HU - Hungarian Maybe we can add the most wanted language folders to the main doc folder and into dirstruc.txt, to serve as example and eliminate the needs for further discussion about this theme. most wanted may be a little premature, given we have not even English docs at the moment :) At least doc/en (just rename back) doc/es doc/pt-BR (maybe some placeholder.txt so it doesnt stay empty) Okay for me. Though I think we should only add the translation dirs only if there is actual content, and for now we should focus on English docs. SVN supports empty dir BTW, so it's not technical issue. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error building WinCE
arm-mingw32ce-gcc -I. -I../../../../../include -O2 -fomit-frame-pointer -DHB_LEGACY_TYPES_OFF -DUNICODE -D_WIN32_WCE -osqlite3.o -c ../../../sqlite3.c win-make[3]: *** [sqlite3.o] Error 1 win-make[2]: *** [descend] Error 2 win-make[1]: *** [sqlite3.inst] Error 2 win-make: *** [external.inst] Error 2 Here it still misses the actual error. No more guesses, maybe wrong Cygwin version, for sure the compiler doesn't work in your environment. The make process and configuration itself (as indicated by rest of log) is alright, though. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13942] trunk/harbour
Revision: 13942 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13942view=rev Author: vszakats Date: 2010-02-20 20:20:24 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 21:19 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) + doc/en - doc/en-EN - contrib/hbgt/doc/en-EN + contrib/hbgt/doc/en - contrib/hbziparc/doc/en-EN + contrib/hbziparc/doc/en - contrib/rddads/doc/en-EN + contrib/rddads/doc/en - contrib/hbgd/doc/en-EN + contrib/hbgd/doc/en - contrib/hbmisc/doc/en-EN + contrib/hbmisc/doc/en - contrib/hbbtree/doc/en-EN + contrib/hbbtree/doc/en - examples/hbdoc/examples/core_en + examples/hbdoc/examples/en - examples/hbdoc/examples/core_es + examples/hbdoc/examples/es * Renamed to use IETF complient language ID. - examples/hbdoc/examples/hbmisc - Deleted. * utils/hbmk2/hbmk2.pt_BR.po * utils/hbmk2/hbmk2.hu_HU.po * utils/hbmk2/hbmk2.prg ! Fixed to not use en-EN language code, but plain en. * examples/hbdoc2/hbdoc2.prg * en-en - en Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/examples/hbdoc2/hbdoc2.prg trunk/harbour/utils/hbmk2/hbmk2.hu_HU.po trunk/harbour/utils/hbmk2/hbmk2.prg trunk/harbour/utils/hbmk2/hbmk2.pt_BR.po Added Paths: --- trunk/harbour/contrib/hbbtree/doc/en/ trunk/harbour/contrib/hbgd/doc/en/ trunk/harbour/contrib/hbgt/doc/en/ trunk/harbour/contrib/hbmisc/doc/en/ trunk/harbour/contrib/hbziparc/doc/en/ trunk/harbour/contrib/rddads/doc/en/ trunk/harbour/doc/en/ trunk/harbour/examples/hbdoc/examples/en/ trunk/harbour/examples/hbdoc/examples/es/ Removed Paths: - trunk/harbour/contrib/hbbtree/doc/en-EN/ trunk/harbour/contrib/hbgd/doc/en-EN/ trunk/harbour/contrib/hbgt/doc/en-EN/ trunk/harbour/contrib/hbmisc/doc/en-EN/ trunk/harbour/contrib/hbziparc/doc/en-EN/ trunk/harbour/contrib/rddads/doc/en-EN/ trunk/harbour/doc/en-EN/ trunk/harbour/examples/hbdoc/examples/core_en/ trunk/harbour/examples/hbdoc/examples/core_es/ trunk/harbour/examples/hbdoc/examples/hbmisc/ 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] Re: About Harbour Documentation
Hi all, me and some of my more skilled friends (and programmers) have experienced that the best technical books/docs are always written in english, so I think the documentation has to be written in english (by now). I've also examined the \doc folder and the only subfolder is \en-EN by now: there isn't a folder for spanish documentation (I haven't synched with svn today). Docs in other languages are welcome but I think it's better to have a complete (as possible) documentation, faq, howtos, in english before starting to translate in other languages or we will miss the goal. Best regards, Marco Subject: Re: [Harbour] Re: About Harbour Documentation From: harbour...@syenar.hu Date: Sat, 20 Feb 2010 21:12:31 +0100 To: harbour@harbour-project.org I am a native pt-BR speaker, and I am web developer also, and here we use pt-BR on the web pages. Of course I like the idea to have pt-BR translation (and contribute too). May we agree in the IETF format? Yes. So to sum it up: Format: NANFORUM Location: root/doc/IETF language code/* Codepage: UTF-8 Some IETF language codes for well-known languages: en - English (generic) pt-BR - Portuguese (Brazil) es - Spanish (generic) hu-HU - Hungarian Maybe we can add the most wanted language folders to the main doc folder and into dirstruc.txt, to serve as example and eliminate the needs for further discussion about this theme. most wanted may be a little premature, given we have not even English docs at the moment :) At least doc/en (just rename back) doc/es doc/pt-BR (maybe some placeholder.txt so it doesnt stay empty) Okay for me. Though I think we should only add the translation dirs only if there is actual content, and for now we should focus on English docs. SVN supports empty dir BTW, so it's not technical issue. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour _ Parla, scrivi, gioca... Scopri le novità di Messenger http://www.messenger.it/home_novita.aspx___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi all, me and some of my more skilled friends (and programmers) have experienced that the best technical books/docs are always written in english, so I think the documentation has to be written in english (by now). I've also examined the \doc folder and the only subfolder is \en-EN by now: there isn't a folder for spanish documentation (I haven't synched with svn today). Docs in other languages are welcome but I think it's better to have a complete (as possible) documentation, faq, howtos, in english before starting to translate in other languages or we will miss the goal. Fully agreed, and I haven't created any other language subdirs for now, to remind us that we should focus on English language docs. [ There is some leftover from the paste Spanish documentation in /examples, if there are no objections I will delete those, as they are incomplete and unmaintained since at least 8 years. ] Brgds, Viktor Best regards, Marco Subject: Re: [Harbour] Re: About Harbour Documentation From: harbour...@syenar.hu Date: Sat, 20 Feb 2010 21:12:31 +0100 To: harbour@harbour-project.org I am a native pt-BR speaker, and I am web developer also, and here we use pt-BR on the web pages. Of course I like the idea to have pt-BR translation (and contribute too). May we agree in the IETF format? Yes. So to sum it up: Format: NANFORUM Location: root/doc/IETF language code/* Codepage: UTF-8 Some IETF language codes for well-known languages: en - English (generic) pt-BR - Portuguese (Brazil) es - Spanish (generic) hu-HU - Hungarian Maybe we can add the most wanted language folders to the main doc folder and into dirstruc.txt, to serve as example and eliminate the needs for further discussion about this theme. most wanted may be a little premature, given we have not even English docs at the moment :) At least doc/en (just rename back) doc/es doc/pt-BR (maybe some placeholder.txt so it doesnt stay empty) Okay for me. Though I think we should only add the translation dirs only if there is actual content, and for now we should focus on English docs. SVN supports empty dir BTW, so it's not technical issue. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour La tua privacy è al sicuro con Internet Explorer 8. Scopri di più___ 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] Re: SF.net SVN: harbour-project:[13878] trunk/harbour
Viktor Szakáts wrote: My best guess is that they were picked randomly, or by personal choice. Not randomly. Peter Rees picked them and I redifind some parts. It was way back around 2003 and have come that way so long. May be someone tweaked them afterwards, but for sure these colors were very close to Clipper one, though I may be wrong. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13878-trunk-harbour-tp4573963p4604365.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] Re: About Harbour Documentation
On Sat, Feb 20, 2010 at 18:43, Marco Boeri boeri...@hotmail.com wrote: Hi all, me and some of my more skilled friends (and programmers) have experienced that the best technical books/docs are always written in english, so I think the documentation has to be written in english (by now). I've also examined Of course, it is the logical starting point. the \doc folder and the only subfolder is \en-EN by now: there isn't a folder for spanish documentation (I haven't synched with svn today). Docs in other languages are welcome but I think it's better to have a complete (as possible) documentation, faq, howtos, in english before starting to translate in other languages or we will miss the goal. I think we agreed in the folder nomenclature at this point only to avoid the need to discus this in the future. Of course you are right, the main documentation should be in English (but if someone decides to contribute right now by translating the few existing docs in any other language, I believe that is not right just forbid it). Best regards, Marco Subject: Re: [Harbour] Re: About Harbour Documentation From: harbour...@syenar.hu Date: Sat, 20 Feb 2010 21:12:31 +0100 To: harbour@harbour-project.org I am a native pt-BR speaker, and I am web developer also, and here we use pt-BR on the web pages. Of course I like the idea to have pt-BR translation (and contribute too). May we agree in the IETF format? Yes. So to sum it up: Format: NANFORUM Location: root/doc/IETF language code/* Codepage: UTF-8 Some IETF language codes for well-known languages: en - English (generic) pt-BR - Portuguese (Brazil) es - Spanish (generic) hu-HU - Hungarian Maybe we can add the most wanted language folders to the main doc folder and into dirstruc.txt, to serve as example and eliminate the needs for further discussion about this theme. most wanted may be a little premature, given we have not even English docs at the moment :) At least doc/en (just rename back) doc/es doc/pt-BR (maybe some placeholder.txt so it doesnt stay empty) Okay for me. Though I think we should only add the translation dirs only if there is actual content, and for now we should focus on English docs. SVN supports empty dir BTW, so it's not technical issue. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour La tua privacy è al sicuro con Internet Explorer 8. Scopri di più ___ 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] Re: Hbide ready to use
Massimo Belgrano wrote: done http://harbourlanguage.blogspot.com/ Thank you. But I cannot see the full images. May be this blog site does not give enough power. The images are cut right side and I cannot event presented with a horizontal scrollbar. Can you reduce the sizes? I have problem with same image and receive an error when exit Visual c++ runtime library this application has requested the runtime to terminate in an unsual way please contact the application's support team for more information How can i correct? Why messages is sent from Visual c++ runtime if am using mingw? I do not know about this fact. On my system every run exits normally. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Hbide-ready-to-use-tp4561432p4604372.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] Re: About Harbour Documentation
[ There is some leftover from the paste Spanish documentation in /examples, if there are no objections I will delete those, as they are incomplete and unmaintained since at least 8 years. ] I have seen the \es folder in the past but I didn't remember where it was placed. I remember to have examined that and the informations were already dated. I'm not Spanish so I can't vote pro or con, but an 8 years old doc is useless, in my opinion. Best regards, Marco _ Scatta, ritocca e condividi le tue foto online. Gratis per te http://www.windowslive.it/foto.aspx___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Hbide ready to use
Right click on the image and open in another window. The css of the blog is hiding the overflow of the image at the page render instead of providing scrollbars, but the image file is OK. On Sat, Feb 20, 2010 at 18:55, Pritpal Bedi bediprit...@hotmail.com wrote: Massimo Belgrano wrote: done http://harbourlanguage.blogspot.com/ Thank you. But I cannot see the full images. May be this blog site does not give enough power. The images are cut right side and I cannot event presented with a horizontal scrollbar. Can you reduce the sizes? I have problem with same image and receive an error when exit Visual c++ runtime library this application has requested the runtime to terminate in an unsual way please contact the application's support team for more information How can i correct? Why messages is sent from Visual c++ runtime if am using mingw? I do not know about this fact. On my system every run exits normally. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Hbide-ready-to-use-tp4561432p4604372.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 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:[13878] trunk/harbour
Hi Pritpal, Viktor Szakáts wrote: My best guess is that they were picked randomly, or by personal choice. Not randomly. Peter Rees picked them and I redifind some parts. It was way back around 2003 and have come that way so long. May be someone tweaked them afterwards, but for sure these colors were very close to Clipper one, though I may be wrong. Okay, thanks for the information. This is what I've found in GTWVT, which also confirms it: --- #define BLACK RGB( 0x0 ,0x0 ,0x0 ) #define BLUE RGB( 0x0 ,0x0 ,0x85 ) #define GREEN RGB( 0x0 ,0x85,0x0 ) #define CYAN RGB( 0x0 ,0x85,0x85 ) #define REDRGB( 0x85,0x0 ,0x0 ) #define MAGENTARGB( 0x85,0x0 ,0x85 ) #define BROWN RGB( 0x85,0x85,0x0 ) #define WHITE RGB( 0xC6,0xC6,0xC6 ) #define LIGHT_GRAY RGB( 0x60,0x60,0x60 ) #define BRIGHT_BLUERGB( 0x00,0x00,0xFF ) #define BRIGHT_GREEN RGB( 0x60,0xFF,0x60 ) #define BRIGHT_CYANRGB( 0x60,0xFF,0xFF ) #define BRIGHT_RED RGB( 0xF8,0x00,0x26 ) #define BRIGHT_MAGENTA RGB( 0xFF,0x60,0xFF ) #define YELLOW RGB( 0xFF,0xFF,0x00 ) #define BRIGHT_WHITE RGB( 0xFF,0xFF,0xFF ) --- So the story is that Peter Rees just copied these to WIN32PRN little test app, and I copied those constants from test app to central header at one point. IOW they were never meant to be general colors for the Windows or Windows printing subsystem. Case closed! [ Anyway if someone wants to use original MS-DOS-era RGB values, here they are. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: About Harbour Documentation
Of course you are right, the main documentation should be in English (but if someone decides to contribute right now by translating the few existing docs in any other language, I believe that is not right just forbid it). Yes, I see your point and I agree with you. Otherwise I will made a little example: I'm Italian, I could translate the existing documentation for italian users, but I do not, cause the documentation that I will write it will be full of technical and syntactical errors. Simply it will be a waste of time for all of us, not only for me. It would be better if I would write new docs on topic that aren't well documented yet: time well spent. Best regards, Marco _ La tua privacy è al sicuro con Internet Explorer 8. Scopri di più http://www.microsoft.com/italy/windows/internet-explorer/features/browse-privately.aspx?tabid=2catid=1___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Hbide ready to use
http://docs.google.com/View?id=dhmtv9fs_235db6hz754 2010/2/20 Pritpal Bedi bediprit...@hotmail.com: Massimo Belgrano wrote: done http://harbourlanguage.blogspot.com/ Thank you. But I cannot see the full images. May be this blog site does not give enough power. The images are cut right side and I cannot event presented with a horizontal scrollbar. Can you reduce the sizes? I have problem with same image and receive an error when exit Visual c++ runtime library this application has requested the runtime to terminate in an unsual way please contact the application's support team for more information How can i correct? Why messages is sent from Visual c++ runtime if am using mingw? I do not know about this fact. On my system every run exits normally. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Hbide-ready-to-use-tp4561432p4604372.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13943] trunk/harbour
Revision: 13943 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13943view=rev Author: vszakats Date: 2010-02-20 21:12:11 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 22:09 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * debian/dirs * doc/en/Makefile * harbour.spec ! en-EN - en - examples/hbdoc/examples - Deleted outdated docs. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/debian/dirs trunk/harbour/doc/en/Makefile trunk/harbour/harbour.spec Removed Paths: - trunk/harbour/examples/hbdoc/examples/ 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] Re: Hbide ready to use
BTW, is it planned to create an application icon for HBIDE? (I see it still has the original temp icon used also for GTWVG and all little test apps) Brgds, Viktor On 2010 Feb 20, at 22:10, Massimo Belgrano wrote: http://docs.google.com/View?id=dhmtv9fs_235db6hz754 2010/2/20 Pritpal Bedi bediprit...@hotmail.com: Massimo Belgrano wrote: done http://harbourlanguage.blogspot.com/ Thank you. But I cannot see the full images. May be this blog site does not give enough power. The images are cut right side and I cannot event presented with a horizontal scrollbar. Can you reduce the sizes? I have problem with same image and receive an error when exit Visual c++ runtime library this application has requested the runtime to terminate in an unsual way please contact the application's support team for more information How can i correct? Why messages is sent from Visual c++ runtime if am using mingw? I do not know about this fact. On my system every run exits normally. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Hbide-ready-to-use-tp4561432p4604372.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 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: About Harbour Documentation
Of course you are right, the main documentation should be in English (but if someone decides to contribute right now by translating the few existing docs in any other language, I believe that is not right just forbid it). Yes, I see your point and I agree with you. Otherwise I will made a little example: I'm Italian, I could translate the existing documentation for italian users, but I do not, cause the documentation that I will write it will be full of technical and syntactical errors. Simply it will be a waste of time for all of us, not only for me. It would be better if I would write new docs on topic that aren't well documented yet: time well spent. We should not forbid any translations, and we should think about it for the future, but for now we should _strongly focus_ on English, unless we want to create 3-4 incomplete (but multilanguage!) docs, instead of 1 complete one :) Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: About Harbour Documentation
We should not forbid any translations, and we should think about it for the future, but for now we should _strongly focus_ on English, unless we want to create 3-4 incomplete (but multilanguage!) docs, instead of 1 complete one :) Brgds, Viktor Exactly. I fully agree. By the way I'm not able to write one row of Harbour documentation: it's too far from my skills. Otherwise, if a group (I remember April White and Chen Kedem in the first time) of documentors will need some help for little tasks like proofreader for example, I'm available. ps. It's saturday (not only for me, at least). I'm coming from two days of headache and my job is one light-year far from Clipper-Harbour-xbase dialect, so this is like a hobby for me now and I spent my (little) free time following little web programming and the future of Clipper ... but what about all of you that stay in front of a screen on saturday night Ciao a tutti, Marco _ Parla, scrivi, gioca... Scopri le novità di Messenger http://www.messenger.it/home_novita.aspx___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Hbide ready to use
Hi carlos i follow your suggestion changing layout http://harbourlanguage.blogspot.com/ 2010/2/20 Bacco carlosba...@gmail.com: Right click on the image and open in another window. The css of the blog is hiding the overflow of the image at the page render instead of providing scrollbars, but the image file is OK. On Sat, Feb 20, 2010 at 18:55, Pritpal Bedi bediprit...@hotmail.com wrote: Massimo Belgrano wrote: done http://harbourlanguage.blogspot.com/ Thank you. But I cannot see the full images. May be this blog site does not give enough power. The images are cut right side and I cannot event presented with a horizontal scrollbar. Can you reduce the sizes? -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Errors in latest SVN
Error: Unresolved external '_HB_FUN_ORDCOUNT' referenced from E:\HARBOUR_CVS\HARBOUR\SRC\HBEXTERN\OBJ\WIN\BCC\HBEXTERN_DYN.OBJ Error: Unresolved external '_HB_FUN_ORDWILDSEEK' referenced from E:\HARBOUR_CVS\HARBOUR\SRC\HBEXTERN\OBJ\WIN\BCC\HBEXTERN_DYN.OBJ 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
[Harbour] SF.net SVN: harbour-project:[13944] trunk/harbour
Revision: 13944 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13944view=rev Author: vszakats Date: 2010-02-20 22:12:14 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 23:11 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rdd/ordwldsk.c * src/rdd/ordcount.c ! Typo. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rdd/ordcount.c trunk/harbour/src/rdd/ordwldsk.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Hbide ready to use
I surely won't, but since several dozen icons have been created for it, I was wondering why the most important one was missing yet. Brgds, Viktor On 2010 Feb 20, at 23:12, Pritpal Bedi wrote: Viktor Szakáts wrote: BTW, is it planned to create an application icon for HBIDE? (I see it still has the original temp icon used also for GTWVG and all little test apps) I am also waiting someone will provide one. Please suppy appropriate one. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Hbide-ready-to-use-tp4561432p4604598.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Hbide ready to use
Massimo Belgrano wrote: Hi carlos i follow your suggestion changing layout http://harbourlanguage.blogspot.com/ Thank you. It looks much better. However a few notes: 1) You can always resize the window to visualizable dimensions. 2) When you concentrate on one topic, close other docks. Why Ffunctions List dock is open when you are explaining Code Skeletons. 3) Do not show pull part of the screen as far as docks are concerned. Simply resize the different parts to bring focus on main widget you are discussing. In current case, Themes, Properties and other docks are shown outside of the main appln. It reduces hbIDE's interface value. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Hbide-ready-to-use-tp4561432p4604642.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] SF.net SVN: harbour-project:[13944] trunk/harbour
-Messaggio Originale- Da: vszak...@users.sourceforge.net A: harbour@harbour-project.org Data invio: sabato 20 febbraio 2010 23.12 Oggetto: [Harbour] SF.net SVN: harbour-project:[13944] trunk/harbour Thank you. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi all! I have a question that I found when I studied about documentation on NF format and I still can not completely understand: What name we give to new files containing the documentation on SVN? * Respecting the category of functions? * Respecting the category + subcategory? * There is no specific rule? Recalling that this type of nomenclature is important just to keep a certain order in the repository so it will be easy to find and compare the translation between languages of a specific function... because after exporting this data to other formats (web, pdf, etc.) this detail may not seem so important. I think it would be important to mention about it right now ... Regards, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi Vailton, On 2010 Feb 21, at 00:15, Vailton Renato wrote: Hi all! I have a question that I found when I studied about documentation on NF format and I still can not completely understand: What name we give to new files containing the documentation on SVN? * Respecting the category of functions? * Respecting the category + subcategory? * There is no specific rule? Recalling that this type of nomenclature is important just to keep a certain order in the repository so it will be easy to find and compare the translation between languages of a specific function... because after exporting this data to other formats (web, pdf, etc.) this detail may not seem so important. Good point. There is no specific rule yet. I think it's better to categorize functions only using keywords (tags) inside doc, otherwise we will have to keep filenames in sync with file content, which in practice will mean a lot cleanup work, and it will never be right. So, maybe the easiest is to create doc filenames from the _beginning_ of functions names (or class names) contained in them: /doc/en/a.txt - containing all A*() functions. /doc/en/bit.txt - containing HB_BIT*() functions. /doc/en/hb_f.txt - containing HB_F*() functions. /doc/en/hb_os.txt - containing HB_OS*() functions. /doc/en/ord.txt - containing ORD*() functions. /doc/en/tbrowse.txt - containing TBROWSE() class. /contrib/hbsqlit3/doc/en/sqlite3.txt - containing all SQLITE3_*() functions. The 'beginning' can the first letter, or first logical section (namespace), of the functions names. (If this is doubtful I can create more examples) This will also create a certain level of natural categorization, since our name are usually well formed, and it makes finding any functions very easy, without the need to grep or do any other sort of multi-file search. Opinions are welcome. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13937] trunk/harbour
Hi, + added new C function: PHB_ITEM hb_socketGetIFaces( int af, HB_BOOL fNoAliases ); it returns array with existing interfaces description. This code was added for non MS-Windows based platforms only. Support for MS-Windows has to be added yet. Xavi has mentioned a popular GetAdaptersInfo() way to get interface list. Windows also support another method that is more similar to your implementation (but less info could be obtained using with method): http://tangentsoft.net/wskfaq/examples/getifaces.html http://msdn.microsoft.com/en-us/library/ms741621(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms738568(VS.85).aspx Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Viktor, [ There is some leftover from the paste Spanish documentation in /examples, if there are no objections I will delete those, as they are incomplete and unmaintained since at least 8 years. ] rant It hard to object if you already deleted them an hour later. You can say that ALL docs are 8 or 10 years old so why don't just delete it all and be done with it. Some of the ES docs where translation of original EN for standard Clipper/Harbour functions. These should not changed in the past 10 years. I know that the docs were neglected, but sometimes it is better to have some reference to work with (future ES documenter) than to have nothing to start with. (I know they are in the SVN tree but for most users they are now gone). /rant *sigh* above were just some ranting because you already deleted them, I have some pending fix requests I made for them dusting in my mailbox for about a decade. So lets continue. Doc function header template can be found in doc/hdr_tpl.txt For start anyone want to contribute anything just post it to the list and if no one else volunteer to act as an editor (preferably a native English speaker) I can try to add them into SVN. Later if we will have enough material to work with, we can try adding some indexing along with doc status (like the funclist.txt we had in the old days). Chen. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
