Re: [Harbour] SF.net SVN: harbour-project:[13614] trunk/harbour
On Sun, Jan 17, 2010 at 8:11 AM, vouch...@users.sourceforge.net wrote: demoQT and demoXBP now consume very less memory when new dialogs are opened. It means memory management has improved with this commit. Anyhow still I can see memory growing specially in browser navigation. As I remember sometime in past I could manage the sonstant memory, but now I do not remember at what stage we were on Qt. Good job Pritpal. I'll do some tests in Linux. best regards, Lorenzo ___ 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:[13616] trunk/harbour
Revision: 13616 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13616view=rev Author: vszakats Date: 2010-01-17 09:38:30 + (Sun, 17 Jan 2010) Log Message: --- 2010-01-17 10:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbhpdf/harupdf.c ! HPDF_Page_TextWidth() fixed to return double instead of long. As suggested by Francesco Perillo. * contrib/hbwin/hbwin.ch * contrib/hbwin/tests/testprn.prg + Renamed FORM_* to WIN_PRN_DMPAPER*. (old constants are still there for compatibility. + Added new WIN_PRN_DMPAPER* constants. (the list is far from complete, but my first goal was to be about in sync with hbhpdf) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbhpdf/harupdf.c trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/contrib/hbwin/tests/testprn.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] SF.net SVN: harbour-project:[13616] trunk/harbour
Log Message: --- 2010-01-17 10:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbhpdf/harupdf.c ! HPDF_Page_TextWidth() fixed to return double instead of long. As suggested by Francesco Perillo. Thank you. Shouldn't it be [TOMERGE2.0] ? Francesco ___ 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:[13616] trunk/harbour
Log Message: --- 2010-01-17 10:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbhpdf/harupdf.c ! HPDF_Page_TextWidth() fixed to return double instead of long. As suggested by Francesco Perillo. Thank you. Shouldn't it be [TOMERGE2.0] ? You're right, it should. 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:[13617] trunk/harbour
Revision: 13617 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13617view=rev Author: vszakats Date: 2010-01-17 14:07:04 + (Sun, 17 Jan 2010) Log Message: --- 2010-01-17 15:06 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_tprn.prg ! Fixed to not refer to legacy function WIN_GETEXEFILENAME(). Probably this was causing the link-time symbol collision problem once reported by Mindaugas. * contrib/hbwin/hbwin.ch + Added WIN_RGB() macro to replace RGB(). Latter is now deprectaed. * ChangeLog + TOMERGE added to prev entry. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/contrib/hbwin/win_tprn.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] Re: OT: file size
Przemek: This is becoming more interesting :-) First thanks for your help In the past I was answering for such questions over 10 times. You may find these messages in the Harbour and xHarbour mailing list archives. A short description I added also to tests/xhb-diff.txt I read xhb-diff.txt and checked it About over 10 times: I have seen before your info about locking schemes and so on, but in that cases was not relevant because does not exist a direct need and we usually do not go deep in those messages if we are not involved For example, nobody have response for my recent messages about hbcurl, hbcairo, hbqt because are considered as irrelevant in this moment Surprisely, except for source code, there are not reference of DB_DBFLOCK_VFP, locking scheme in doc files and even changelog file My mail file for Harbour messages reached 105 Mb file size and no one editor in OS/2 can open it ( EPM, E, TEDIT, JEdit ) :-) So I used many hours to split file in many files until it can open under 50 Mb: harbour0 21 Mb, 2006 to 2007 harbour08 26 Mb, 2008 harbour09a 31 Mb, 2009 first six months harbour27 Mb, 2009 rest six months as we can see, 2009 was plenty of messages ... and surprisely too, in messages there are not too much info about dbf file sizes, locking schemes. Last and detailed message was around 30 Oct 2009 In source code we find info as this: /* LOCK SCHEMES */ #define DB_DBFLOCK_DEFAULT0 #define DB_DBFLOCK_CLIP 1 #define DB_DBFLOCK_CL53 2 #define DB_DBFLOCK_VFP3 #define DB_DBFLOCK_CL53EXT4 #define DB_DBFLOCK_XHB64 5 /* DBF locking schemes */ #define DBF_LOCKPOS_CLIP 10UL #define DBF_LOCKPOS_CL53 10UL #define DBF_LOCKPOS_VFP 0x4000UL #define DBF_LOCKPOS_VFPX 0x7ffeUL #define DBF_LOCKPOS_CL53EXT 40UL #define DBF_LOCKPOS_XHB64 HB_LL( 0x7FFF0001 ) which are difficult to understand for a user without too much knowledge For example, what is CL53EXT, VFPX ? For me was hard to find information about this case Perhaps info is there somewhere but I do not found it, so I suggest you to expand xhb-diff.txt or create a different one to clarify: - DBF file size limit ( currently brief ) - locking schemes so users can be oriented to file info in place to repeat in messages I do not know ADS details so I do not it's limitations. For sure it does not support all Harbour extenssions so they are smaller and for sure there is nothing in ADS what exceed Harbour any limits for DBFs and related files (memos and indexes) so migration to ADS without changing the format to ADT+ADM+ADI can only reduce the maximum supported file size or in some cases leave them on the same level. If someone claims sth different then he simply does not know what he's talking about and you can ignore him. If you need bigger files then you have to switch to different format. Each program which uses OS files is limited by OS API. The exact limitations can be found in the OS documentation and they depends on the operating system internals (OS kernel) and used file system (FS). Additionally please remember that locking schemes can seriously reduce maximum file size. On some systems it's not possible to read from locked area. In such case you have to switch all your applications accessing the files to locking scheme which do not cause such limitations, i.e. use Harbour 64bit locking. [...] They use non POSIX system i.e. DOS or WINDOWS with VFP locking scheme in which the RLOCK and FLOCK are is at range 0x6E6B27FF : 0x7FFE. In such systems read/write access from locked region is blocked by OS if client is not lock owner so the above error appear when other station [R|F]locked some records in DBF file and user program wants to read records which are located in the above range. That's all. It's expected behavior. They should read about locking schemes and switch to other locking scheme which do not cause such limitation. [...] And this is result of file corruption, i.e. due to wrong CPs or server/ client computer crash and FS corruption. I have more info provided by users They are using my (x)Harbour systems with ADS 6.2x and VFP systems with unknown connection type to ADS As you know ADS have two Locking Modes: - Advantage Proprietary Locking - Advantage Compatibility Locking with Xbase Files and I do not know which are technical details of each one, and if compatibility mode is based in VFP type or if 2 Gb size is involved I checked and my systems are using Proprietary mode and rights checkings by default but I do not know what is using VFP Along years I did not found detailed info in ADS docs about technical facts of both locking modes, so I respect to use Proprietary I do not know what is range 0x6E6B27FF : 0x7FFE :-) It is related to 2 Gb ? First info of users was about failure reaching 2 Gb, but maybe what is happening
Re: [Harbour] Re: OT: file size
Hi David,
I read xhb-diff.txt and checked it
About over 10 times:
I have seen before your info about locking schemes and so on, but in that
cases was not relevant because does not exist a direct need and we usually do
not go deep in those messages if we are not involved
For example, nobody have response for my recent messages about hbcurl,
hbcairo, hbqt because are considered as irrelevant in this moment
I did notice it and thanks for these tests, but I'd suggest
to patch (or send patches for) existing .hbc files, after you
tested them with hbmk2 successfully using OS/2 specific 3rd
party lib names. It's rather inefficient if I edit them without
testing and we iterate it endlessly. Plus for me it's impossible
to decide which one of the possible true OS/2 lib name setups
should be put into SVN .hbc files. Ideally the default here
should be what _most_ OS/2 users would expect.
You should add:
{os2}libs=...
Plus you should exclude existing libs= lines with
{!os2} if they are not currently protected.
Surprisely, except for source code, there are not reference of
DB_DBFLOCK_VFP, locking scheme in doc files and even changelog file
My mail file for Harbour messages reached 105 Mb file size and no one editor
in OS/2 can open it ( EPM, E, TEDIT, JEdit ) :-)
So I used many hours to split file in many files until it can open under 50
Mb:
harbour0 21 Mb, 2006 to 2007
harbour08 26 Mb, 2008
harbour09a 31 Mb, 2009 first six months
harbour27 Mb, 2009 rest six months
(if it's a text file you can use 'grep')
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Sharing experiences: Qt + MinGW + CodeBlocks for compile hbide.
Hi, It'd seem a good idea to add compiler switch to customize error/warning message output to make existing IDEs happy (and such patches unnecessary). BTW, my Code::Blocks build already had that .prg lexer preinstalled. (current release for Mac OS X) Brgds, Viktor On 2010 Jan 17, at 17:22, Xavi wrote: Hi All, Recently I explained to a new user, how to start working in Windows with Harbour SVN. I want to share with everyone maybe this it's can help to someone. 1) Donwload Qt LGPL SDK for Windows and install in D:\Qt .- http://qt.nokia.com/downloads We have Qt Creator and MinGW C/C++ copy in D:\Qt\2009.05\mingw To access Qt's dll, MinGW and our future Harbour's binaries inside D:\Qt\harbour .- Set Path=%PATH%;D:\Qt\2009.05\qt\bin;D:\Qt\2009.05\mingw\bin;D:\Qt\harbour\bin; This change should do in My PC context menu option Properties, Environment Variables. Create a new Environment Variables HB_USER_LIBPATHS with D:\Qt\2009.05\qt\lib To simplify Path parameter. 2) Download MinGW from the official page, from TMD and install in D:\Qt\MinGW .- http://www.tdragon.net/recentgcc Choose in Setup .- Select in tree control Or, select the optional components you wish to have installed: Components\gcc (TMD Unstable: 4.4.1-tmd-2-dw2)\Version\TMD Unstable: 4.4.1-tmd-2-dw2 [ Install ] Inside directory D:\Qt\MinGW\bin .- Copy gcc-dw2.exe to gcc.exe Copy g++-dw2.exe to g++.exe To change the working copy of MinGW only need change the Path to bin. Set Path=D:\Qt\MinGW\bin;D:\Qt\harbour\bin;D:\Qt\2009.05\qt\bin;%PATH% In My PC, Environment Variable (recommended) .- Path D:\Qt\MinGW\bin;D:\Qt\harbour\bin;D:\Qt\2009.05\qt\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem; 3) Donwload Code::Blocks (only need the IDE but if you want a copy of MinGW) and install in C:\Program files .- ... ___ 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:[13587] trunk/harbour
Hi! I'm getting an error with the latest version of hbide. I open a file and then hit ENTER and BACKSPACE then a GPF error appears. Inside the file hb_out.log I see: Called from QT_QEVENTLOOP_PROCESSEVENTS(0) Called from QEVENTLOOP:PROCESSEVENTS(0) in ../../../TQEventLoop.prg Called from APPEVENT(0) in ../../../xbpgeneric.prg Called from HBIDE:CREATE(323) in hbide.prg Called from MAIN(100) in hbide.prg The error remains even after running a make clean install. 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:[13618] trunk/harbour
Revision: 13618 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13618view=rev Author: vszakats Date: 2010-01-17 19:43:19 + (Sun, 17 Jan 2010) Log Message: --- 2010-01-17 20:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_reg.prg * contrib/hbwin/win_os.prg * contrib/hbwin/win_tprn.prg * contrib/hbwin/wapi_winbase.c * contrib/hbwin/hbwin.h * contrib/hbwin/hbwin.ch * contrib/hbwin/tests/testprn.prg * contrib/hbwin/tests/testcom1.prg * contrib/hbwin/tests/testcom2.prg * contrib/hbwin/tests/testreg.prg * contrib/hbwin/tests/testmapi.prg * contrib/hbwin/win_com.c * contrib/hbwin/win_prn1.c * MM_TO_INCH macro moved from hbwin.ch to win_tprn.prg. (INCOMPATIBLE is someone happened to use this in app code) + Prefixed all Windows constants with WIN_ in hbwin.ch. + Prefixed all hbwin specific constants with HB_ in hbwin.ch. + Retained all old legacy / deprecated hbwin.ch constants for compatibility. Users are encourages to use the new ones, as the old ones will be deleted in the future. * Changed WIN_MULDIV() to use hb_retni() (instead of hb_retnl()) * WIN_MULDIV() renamed to WAPI_MULDIV() and moved to wapi source. (INCOMPATIBLE, although it's unlikely anyone is using WIN_MULDIV() so I didn't keep it.) + Added some additional printing related Windows constants. + Added comments to hbwin.ch saying which constant is used in which WIN_*() function. * HB_WIN_MAPI_* constants renamed to WIN_MAPI_*. (I haven't dealt with compatibility as this is brand new functions with not much users yet) + Marked all hbwin.ch deprecated macros with HB_LEGACY_LEVEL3 ! Fixed to use hbwin.ch constants in few remaining places in testprn.prg ; Now it's possible to include hbwin.ch in .c files. ; QUESTION: Why RGB_* color constants aren't using pure colors? If there is no special reason, I think it should be changed to pure ones (with 0xFF components). * src/compiler/hbgenerr.c * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/contrib/hbwin/hbwin.h trunk/harbour/contrib/hbwin/tests/testcom1.prg trunk/harbour/contrib/hbwin/tests/testcom2.prg trunk/harbour/contrib/hbwin/tests/testmapi.prg trunk/harbour/contrib/hbwin/tests/testprn.prg trunk/harbour/contrib/hbwin/tests/testreg.prg trunk/harbour/contrib/hbwin/wapi_winbase.c trunk/harbour/contrib/hbwin/win_com.c trunk/harbour/contrib/hbwin/win_os.prg trunk/harbour/contrib/hbwin/win_prn1.c trunk/harbour/contrib/hbwin/win_reg.prg trunk/harbour/contrib/hbwin/win_tprn.prg trunk/harbour/src/compiler/hbgenerr.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] SF.net SVN: harbour-project:[13587] trunk/harbour
Hi Vailton Renato wrote: I'm getting an error with the latest version of hbide. I open a file and then hit ENTER and BACKSPACE then a GPF error appears. Inside the file hb_out.log I see: Called from QT_QEVENTLOOP_PROCESSEVENTS(0) Called from QEVENTLOOP:PROCESSEVENTS(0) in ../../../TQEventLoop.prg Called from APPEVENT(0) in ../../../xbpgeneric.prg Called from HBIDE:CREATE(323) in hbide.prg Called from MAIN(100) in hbide.prg The error remains even after running a make clean install. Can you check after r13615 ? I cannot reproduce is on my system. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13587--trunk-harbour-tp27171558p27202568.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13619] trunk/harbour
Revision: 13619 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13619view=rev Author: vszakats Date: 2010-01-17 21:52:34 + (Sun, 17 Jan 2010) Log Message: --- 2010-01-17 22:49 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/hbwin.ch + Added HB_WINFONT_* constants for WIN_ENUMFONTS() returned array positions. + Now possible to disable legacy defintions by defining HB_WIN_NO_LEGACY. This paves the way to include this file in .c files. * contrib/hbwin/win_prn1.c ! WIN_ENUMFONTS() fixed to return empty array (instead of NIL) in error cases. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/contrib/hbwin/win_prn1.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] SF.net SVN: harbour-project:[13587] trunk/harbour
Hi Pritpal, After rebuilding everything I'm getting a GPF when right clicking on the edit area, then the right-click menu appears, then I click back on the edit area and there it GPFs. An another error present since the feature was added: Split the edit area horizontally, then close the split, the split it vertically, it will split the area into 4 sections with two of them active. Brgds, Viktor On 2010 Jan 17, at 21:39, Pritpal Bedi wrote: Hi Vailton Renato wrote: I'm getting an error with the latest version of hbide. I open a file and then hit ENTER and BACKSPACE then a GPF error appears. Inside the file hb_out.log I see: Called from QT_QEVENTLOOP_PROCESSEVENTS(0) Called from QEVENTLOOP:PROCESSEVENTS(0) in ../../../TQEventLoop.prg Called from APPEVENT(0) in ../../../xbpgeneric.prg Called from HBIDE:CREATE(323) in hbide.prg Called from MAIN(100) in hbide.prg The error remains even after running a make clean install. Can you check after r13615 ? I cannot reproduce is on my system. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13587--trunk-harbour-tp27171558p27202568.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ 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:[13587] trunk/harbour
After rebuilding everything I'm getting a GPF when right clicking on the edit area, then the right-click menu appears, then I click back on the edit area and there it GPFs. Here's the log: Called from QT_QACTION_TEXT(0) Called from QACTION:TEXT(0) in ../../../TQAction.prg Called from IDEEDIT:EXEEVENT(1221) in ideeditor.prg Called from (b)IDEEDIT_CONNECTEDITSLOTS(1193) in ideeditor.prg Called from QT_QEVENTLOOP_PROCESSEVENTS(0) Called from QEVENTLOOP:PROCESSEVENTS(0) in ../../../TQEventLoop.prg Called from APPEVENT(0) in ../../../xbpgeneric.prg Called from HBIDE:CREATE(323) in hbide.prg Called from MAIN(100) in hbide.prg BTW, it still crashes on exit with MINGW/WIN7. (no log generated in this case) 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:[13620] trunk/harbour
Revision: 13620 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13620view=rev Author: vszakats Date: 2010-01-17 22:09:09 + (Sun, 17 Jan 2010) Log Message: --- 2010-01-17 23:08 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * hbqt/hbqt.h * hbqt/hbqt.ch * hbqt/hbqt_destruct.cpp * hbqt/hbqt_hbqsyntaxhighlighter.cpp * contrib/hbqt/tests/demoqt.prg - Deleted unused remains of memory release method selection. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt.ch trunk/harbour/contrib/hbqt/hbqt.h trunk/harbour/contrib/hbqt/hbqt_destruct.cpp trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp trunk/harbour/contrib/hbqt/tests/demoqt.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] SF.net SVN: harbour-project:[13587] trunk/harbour
Hi Viktor Szakáts wrote: After rebuilding everything I'm getting a GPF when right clicking on the edit area, then the right-click menu appears, then I click back on the edit area and there it GPFs. Yes, I can reproduce it. Will be fixing in a while with some other improvements. The current implementation has 0 tolerance, it is good. An another error present since the feature was added: Split the edit area horizontally, then close the split, the split it vertically, it will split the area into 4 sections with two of them active. Not an error but implementation lazyness. I will address this issue in a couple of days. Thank you for the input. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13587--trunk-harbour-tp27171558p27203564.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13587] trunk/harbour
Hi Viktor Szakáts wrote: Called from QT_QACTION_TEXT(0) Called from QACTION:TEXT(0) in ../../../TQAction.prg Called from IDEEDIT:EXEEVENT(1221) in ideeditor.prg Called from (b)IDEEDIT_CONNECTEDITSLOTS(1193) in ideeditor.prg Called from QT_QEVENTLOOP_PROCESSEVENTS(0) Called from QEVENTLOOP:PROCESSEVENTS(0) in ../../../TQEventLoop.prg Called from APPEVENT(0) in ../../../xbpgeneric.prg Called from HBIDE:CREATE(323) in hbide.prg Called from MAIN(100) in hbide.prg Fixed. And also at a couple of places more. BTW, it still crashes on exit with MINGW/WIN7. (no log generated in this case) Exit on crash may exist. This is for what the whole new exercise is done. It is bad that no logs are generated, but I am looking into different scenarios, hopefully will find a solution. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13587--trunk-harbour-tp27171558p27203941.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OT: using a shared folder on my WinXP box to hold source code for Harbour but shared by by my Ubuntu box
I've updated my Ubuntu box to 9.10 but lost all settings. I've manually rebuilt them, at this point I've got my Ubuntu box to mount the WinXP Harbour folder. I've got past the Ubuntu issue where it reports a Value too large for defined data type error while compiling. However I'm running into a problem where Ubuntu wants to create a symbolic link for libharbour.so on the WinXP harddrive and this raises an Operation not support error. When I re-run make this is bypassed but the compiled test program now cannot find libharbour.so I'd like to maintain only one copy of the repository tree, on my WinXP box, so what, if any, solution is there to this? Would rebuilding Harbour with HB_BUILD_SHARED=no circumvent this? April -- Yes, yes. Zathras is used to being beast of burden to other people's needs. Very sad life. Probably have very sad death. But, at least there is symmetry. - Babylon 5 ___ 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:[13587] trunk/harbour
Hi! The problem here remains with the revision 13620, but I could not compile the hbxbp using HB_USER_PRGFLAGS =-l- to display the line numbers. =( Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE
More suggestions: - At press ESC is closed the file, equals CTRL+W. See this ScreenCast. http://www.teleguia.com.py/hbide/esc_bug.ogv - At startup, the enconding no show in status bar, but working properly. Saludos ¿Estas buscando algún número telefónico? Visite: www.teleguia.com.py *:-.,_,.-:*'``'*:-.,_,.-:*:-.,_,.-:*'``'*:-.,_,.-: :: Rodrigo Machado :: FlaRo Sistemas www.flaro.net Telef: 0673 221 480 *:-.,_,.-:*'``'*:-.,_,.-:*:-.,_,.-:*'``'*:-.,_,.-: ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE
More suggestions: At open a file, in the OpenDialog set the default path equal the opened file. Saludos. ¿Estas buscando algún número telefónico? Visite: www.teleguia.com.py *:-.,_,.-:*'``'*:-.,_,.-:*:-.,_,.-:*'``'*:-.,_,.-: :: Rodrigo Machado :: FlaRo Sistemas www.flaro.net Telef: 0673 221 480 *:-.,_,.-:*'``'*:-.,_,.-:*:-.,_,.-:*'``'*:-.,_,.-: Sent from Asuncion, Paraguay ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour-users] program frozen
Using hbmk2
hbmk2 is a Tool that allow compile sample and large project
basic use of this tools is
hbmk2 ac_test
hbmk2 ac_test.prg
After this command you have ac_test.exe created
You can also immediaply execute simple using
hbmk2 ac_test -run
Hbmk2 is indipendent from Platform and Compiler that you use
Please also try the recommended way with hbmk2, it does
a similar job to your manual Makefile, but it's portable, works
for all future test programs and just one line.
If hbmk2 doesn't work for you for some reason, post your -trace output
How compile several. PRG lib?
hbmk2 test1 test2 testn -lmylib1 -lmylib2 -lmylibn
hbmk2 test1.prg test2.prg testn.prg mylib1.lib mylib2.lib mylibn.lib
How create a lib?
hbmk2 myprg1.PRG myprg2.prg myrc.rc -b -m -hblib -omiolib.lib
How have additional information?
hbmk2 test1 test2 testn -lmylib1 -lmylib2 -lmylibn
hbmk2 ac_test -info -trace
How disample compile incremental?
hbmk2 test1 test2 testn -lmylib1 -lmylib2 -lmylibn -rebuild
default os enable incremental build mode , so only modified part of
your project will be recompiled
-rebuild flag allow
How use a config library file (hbc)?
hbc contain the library used from the project
typically exist a template for each library for include all neccessary
references
se for eaxample
/harbour/contrib/hbxbp/hbxbp.hbc
Yoy can use use hbc adding to hbmk2 command line
use inside a hpb adding a line with path where hbc reside
#
# $Id: hbxbp.hbc 11447 2009-06-20 02:41:38Z vszakats $
#
incpaths=.
libs=hbxbp
libs=../hbqt/hbqt.hbc
How used a Project file (hbp)?
you can simply use
hbmk2 hbide.hbp
hbp contain all command contained in command line
#
# $Id: hbide.hbp 13463 2010-01-04 10:15:18Z vouchcac $
#
../hbxbp/hbxbp.hbc
-inc
-w3 -es2 -gc3
-ohbide
# Trick to make it link using default Harbour builds
-ldflag={msvc}-nodefaultlib:msvcrt.lib
-ldflag={msvc}-defaultlib:libcmt.lib
hbide.prg
ideobject.prg
idestylesheets.prg
idetags.prg
idemisc.prg
ideactions.prg
ideeditor.prg
idefindreplace.prg
idedocks.prg
idesaveload.prg
iderequests.prg
idethemes.prg
ideprojmanager.prg
ideparseexpr.c
What is hb.mk?
Is a default setting applied to all source compiled in this directory
How obain help?
hbmk2 - help
Harbour Make (hbmk2) 2.0.1dev (Rev. 13476)
Copyright (c) 1999-2010, Viktor Szakats
http://www.harbour-project.org/
Translation (it-IT): (add your name here)
Syntax:
hbmk2 [options] [script[s]]
src[s][.prg|.c|.obj|.o|.rc|.res|.po|.pot|.hbl|@.clp|.d]
Options:
-ooutnameoutput file name
-llibnamelink with libname library. libname should be without
path, extension and 'lib' prefix (unless part of libname).
-Llibpathadditional path to search for libraries
-ip|-incpath=p additional path to search for headers
-static|-sharedlink with static/shared libs
-mt|-stlink with multi/single-thread VM
-gtname link with GTname GT driver, can be repeated to link with
more GTs. First one will be the default at runtime
-hblib create static library
-hbdyn create dynamic library
-gui|-std create GUI/console executable
-main=mainfunc override the name of starting function/procedure
-fullstaticlink with all static libs
-[full|fix]shared create shared Harbour binaries without/with absolute dir
reference to Harbour library (default: 'fullshared' when
Harbour is installed on system location, 'fixshared'
otherwise) (fix/full option in *nix only)
-nulrdd[-] link with nulrdd
-[no]debug add/exclude C compiler debug info. For Harbour level
debug, use Harbour option -b as usual
-[no]optim toggle C compiler optimizations (default: on)
-[no]cpp[=def] force C/C++ mode or reset to default
-[no]map create (or not) a map file
-[no]implibcreate (or not) an import library (in -hbdyn mode)
-[no]strip strip (no strip) binaries
-[no]trace show commands executed
-[no]beep enable (or disable) single beep on successful exit, double
beep on failure
-[no]ignoreignore errors when running compiler tools (default: off)
-nohblib[-]do not use static core Harbour libraries when linking
-nolibgrouping[-] disable library grouping on gcc based compilers
-nomiscsyslib[-] don't add extra list of system libraries to default
library list
-traceonly show commands to be executed, but don't execute them
-[no]warn[=lev]set C compiler warning level
lev can be: yes, no, def (default: yes)
-[no]compr[=lev] compress executable/dynamic lib (needs UPX)
lev can be: min, max, def
-[no]run run/don't run output executable
-vcshead=filegenerate .ch header file with local repository
information.
