[Harbour] 2008-08-26 08:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-26 08:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * utils/hbmake/hbmake.prg ! Some liblists synced with xhb / hbmake. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-26 02:43 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-26 02:43 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/xhb/hbcrypt.c * contrib/hbw32/tprinter.c * contrib/hbw32/w32_ole.c * contrib/hbw32/w32_prn.c * contrib/hbfbird/tests/testapi.c * contrib/hbziparch/hbziparc.c * contrib/hbziparch/hbzipnew.cpp * contrib/hbhpdf/harupdf.c * contrib/hbfimage/fi_winfu.c * contrib/hbfimage/fi_wrp.c * contrib/hbgf/hbgfw32/win32.c * contrib/hbgf/hbgfos2/os2pm.c * source/rtl/filesys.c * utils/hbtest/rt_miscc.c * // -> ANSI comments. ; NOTE: hbwhat32 and gtwvg remain with //. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Typo in /harbour/utilt/hbtest/rt_math.prg
Hi Bill, Well hbtest is meant to check for Clipper compatibility, Clipper may be incorrect in cases, and if it's the case we may disable the given test to not bother us. In this case though it clearly shows some important difference so I'm not sure we should hide it at this point yet, since this Clipper problem also affects Harbour, and we haven't fixed in a consistent way yet. (again: some compilers on some platforms with Harbour will generate the wrong result, so will not.) I'd say let's tweak this a bit later. Brgds, Viktor On 2008.08.22., at 18:49, bill robertson wrote: - Original Message - From: "Szakáts Viktor" <[EMAIL PROTECTED] > To: "Harbour Project Main Developer List." > Sent: Friday, August 22, 2008 12:18 PM Subject: Re: [Harbour] Typo in /harbour/utilt/hbtest/rt_math.prg Hi Bill, Yes, with some compilers it's the correct one, with others it's the other one. We aim for Clipper compatibility, so the expect value in hbtest is the Clipper one. Hi Viktor When there are multiple items you may not be able or want to make Clipper compatibible. Consider the following pgm: //- function main() LOCAL nInfinity:= Infinity(.T.) Clear screen ? ? 2^1024 > nInfinity ? 2^1024 == nInfinity ? 2^1024 < nInfinity ? 1234567890*1234567890 ? RETURN 0 You get the following answers: clipper .F. .T. .F. 1524157875019052000 harbour .T. .F. .F. 1524157875019052100 Harbour gets the multiplication correct. Clipper sets the infinity() function to the largest 32-bit value but Harbour doesn't. AFAIR, this can be fixed for all systems if we introduce 64bit Harbour numeric types. I really need 64bit numerics just to read text files from the NIST. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Suggestion for harbour web site?
Hi Massimo, A total rewrite / redesign maybe. And/or wiki. Currently it's full of lost links, empty pages, smaller and bigger visual artifacts, and the whole format / content is also very outdated, and just frightening for anyone trying to get a level of confidence in this project. Brgds, Viktor On 2008.08.25., at 13:36, Massimo Belgrano wrote: Please post here any suggestion for harbour website ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: R: [Harbour] hbmake
Hi Massimo, I hope you had a nice holiday. i want refer a good documentation regarding harbour as chm/html http://www.oohg.org/manual/harbour/(x)harbour.html It is made by free helpmaker (http://www.vizacc.com/Default.aspx ) HelpMaker is a good Help Authoring tool.It can export htm,pdf,rtf This documentation is made by Janusz in the oop minigui project and i have his agreement on upload on Harbour csv. Can we include this documentation on next harbour distribution? This doc look very good (albeit tailored to xhb, so it'd need some adjustments here and there), but I don't like this tree-like framed web format very much, since it makes broader searching impossible. Also, I personally prefer open source/multiplatform tools to create documentation for something we upload to the SVN. How does this docs look as source code? Can you upload it to an FTP/website so that we can have a look? In any case we can either have a link to this manual page from our website, or - even better - we may also host a copy on our homepage. I think this would be great. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-26 00:43 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-26 00:43 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * make_vc.bat * make_vcce.bat * make_vc.mak - make_vcce.mak % make_vcce functionality merged into make_vc. * make_vcce.bat changed to a stub calling make_vc.bat. ; WinCE builds can be triggered using envvars: set HB_BUILD_WINCE=yes set HB_CC_NAME=vcce Please update your environment and test WinCE builds after this change. * make_vc.mak * contrib/mtpl_vc.mak * Changed HB_VISUALC_VER default to 80. It was 60 for non-WinCE builds and contribs, 80 for WinCE builds. Now it is 80 for all these cases. * make_b32.mak * Minor comment visual sync with make_vc.mak. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 23:30 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 23:30 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * doc/cmdline.txt * doc/hrb_faq.txt * doc/en/cmdline.txt * doc/en/dir.txt * doc/en/file.txt * doc/en/set.txt * doc/es/cmdline.txt * doc/es/dir.txt * doc/es/file.txt * doc/whatsnew.txt * contrib/hbct/disk.c * contrib/hbodbc/odbc.txt * contrib/hbwhat32/whtmapi.c * contrib/hbwhat32/whtsys.c * contrib/hbwhat32/whtinet.c * contrib/hbziparch/hbziparc.c * contrib/hbnf/chdir.c * contrib/hbnf/tempfile.prg * contrib/hbnf/ftisprn.c * contrib/hbnf/getenvrn.c * contrib/hbnf/mkdir.c * contrib/hbnf/rmdir.c * contrib/hbpgsql/readme.txt * contrib/hbclipsm/environ.c * contrib/hbclipsm/tests/testenv.prg * contrib/hbgd/tests/gdtest.prg * contrib/hbgd/tests/test_out.prg * contrib/hbgd/tests/gdtestcl.prg * contrib/hbgd/tests/testdpi.prg * contrib/hbgd/tests/counter.prg * contrib/hbtip/thtml.prg * contrib/hbvpdf/hbvpdf.prg * contrib/hbvpdf/tests/pdf_demo.prg * contrib/hbvpdf/hbvpdft.prg * contrib/examples/guestbk/guestbk.prg * contrib/examples/pe/editorlo.c * utils/hbdoc/genos2.prg * utils/hbdoc/hbdoc.prg * utils/hbmake/hbmake.prg ! Filename casing fixes. (nothing critical) -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbsetup.h ! Fixed OS_UNIX_COMPATIBLE + Small comments added. ; NOTE: I'd like to do the following global renames: HB_WINCE -> HB_OS_WIN_CE HB_OS_WIN_32 -> HB_OS_WIN Opinions? Especially on the latter. * include/hbdefs.h * include/hbinit.h * contrib/hbodbc/odbc.c * _WIN64 -> HB_OS_WIN_64 -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 22:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * make_vcce.mak ! Do not explicitly #define HB_WINCE. This should be autodetected in hbsetup.h. * include/hbsetup.h % Minor cleanup. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 22:35 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 22:35 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbsetup.h * source/common/hbver.c - Removed HB_OS_MAC support. It was nothing more than a simple detection and a static version string, so we didn't lose much. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 22:25 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 22:25 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * make_vcce.mak ! Attempt to fix /MANIFEST:NO warnings for MSVC 6.0. ! Attempt to fix WinCE .dll linking error. ; Jose, another test would be great. * make_vc.bat * make_vc.mak * make_vcce.bat * make_vcce.mak * Some syncing and minor fixes in comments. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-08-25 20:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Hi Przemek, Try: gcc --target-help You're right, these options are somehow visible on this help screen, but I did a few simple tests (compiling a simple program to return different value, if __CYGWIN__ is #defined, and also 'gcc -dD -E - < nul' dumps), and there is no sign that these switches are doing anything, __CYGWIN__ was never #defined, that is. This was done on 3.4.2, so I suspect this is true for newer versions. Do you mean this is needed for the Linux MingW cross-compiler environment, still? If that's the case, shouldn't we add this command line option in the starter .sh files? It does not depend on OS but on default compiler switches which can be changed/customized in all installations. If you think it's very seldom situation then we can leave it as is. It may cause problems for those who want to use MinGW 2.95 (which was still labeled Cygnus MinGW), but I suspect there is not many wanting to do this. I'm also not sure what was the default for this version, but maybe -mno-cygwin was indeed needed for this, maybe not. I don't have this version anymore, so I cannot test. But anyway, just like __CYGWIN__ support, HB_OS_MAC, this looks pretty much a thing of the past. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-08-25 21:56 UTC+0200 Viktor Szakats (harbour.01syenar hu)
Viktor, I test build WinCe.dll. I got a list of errors attached. Regards, José Luis Capel These are my sets: SET HB_ARCHITECTURE=w32 SET HB_GT_LIB=gtgui SET HB_GT_DEFAULT=gui SET HB_VISUALC_VER=60 SET HB_BUILD_MODE=c SET CLIBFLAGS=-DHB_OS_WIN_32 -DHB_WINCE -DHB_GTGUI_HACK -DHARBOUR_MAIN_WIN -DHB_TR_LEVEL_ALWAYS -DUNICODE SET HB_BUILD_DLL=yes - Original Message - From: "Szakáts Viktor" <[EMAIL PROTECTED]> To: Sent: Monday, August 25, 2008 9:56 PM Subject: [Harbour] 2008-08-25 21:56 UTC+0200 Viktor Szakats (harbour.01syenar hu) 2008-08-25 21:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * make_vcce.mak ! Fixed system library list to not contain gdi32.lib. This lib was previously used for harbour.dll generation, so I wonder if it was correct, but probably not. It would be great if someone could try an MSVC WinCE .dll build using the option: set HB_BUILD_DLL=yes -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour make_vcce.rar Description: Binary data ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-08-25 20:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
On Mon, 25 Aug 2008, Szakáts Viktor wrote: Hi Viktor, > There is no such option in any of the MinGW versions (3.4.2, > 3.4.5, 4.1.2, 4.3.1) I have installed (on Windows). [ Well, > 4.3.1 has -mcygwin in its help somewhere, but both -mcygwin, > and -mno-cygwin are completely ignored. ] Try: gcc --target-help AFAIR this option have been existing in all of the above MinGW versions for very long time. > I recall adding this in those times when the only way to > create a 'mingw32' build, was through a Cygwin installation > and this switch. In general it's for all MinGW installations which have CYGWIN interface enabled by default and we had -mno-cygwin to ignore such default settings. > Do you mean this is needed for the Linux MingW cross-compiler > environment, still? If that's the case, shouldn't we add this > command line option in the starter .sh files? It does not depend on OS but on default compiler switches which can be changed/customized in all installations. If you think it's very seldom situation then we can leave it as is. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 21:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 21:56 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * make_vcce.mak ! Fixed system library list to not contain gdi32.lib. This lib was previously used for harbour.dll generation, so I wonder if it was correct, but probably not. It would be great if someone could try an MSVC WinCE .dll build using the option: set HB_BUILD_DLL=yes -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error creating libs using eVc4
Hi, With latest svn I got this error (make_vcce): expropt1.c expropt2.c hbarch.c hbfsapi.c hbfopen.c hbgete.c hbwince.c hbhash.c hbdate.c hbstr.c hbtrace.c hbver.c hbverdsp.c reserved.c Microsoft (R) Library Manager Version 6.24.3077 Copyright (C) Microsoft Corporation. All rights reserved. hbpp.c LINK : warning LNK4044: unrecognized option '/MANIFEST:NO'; ignored LINK : fatal error LNK1181: cannot open input file 'gdi32.lib' These are my sets: SET HB_ARCHITECTURE=w32 SET HB_GT_LIB=gtgui SET HB_GT_DEFAULT=gui SET HB_VISUALC_VER=60 SET HB_BUILD_MODE=c SET CLIBFLAGS=-DHB_OS_WIN_32 -DHB_WINCE -DHB_GTGUI_HACK -DHARBOUR_MAIN_WIN -DHB_TR_LEVEL_ALWAYS -DUNICODE Regards, José Luis Capel ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-08-25 20:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Hi Przemek, There is no such option in any of the MinGW versions (3.4.2, 3.4.5, 4.1.2, 4.3.1) I have installed (on Windows). [ Well, 4.3.1 has -mcygwin in its help somewhere, but both -mcygwin, and -mno-cygwin are completely ignored. ] I recall adding this in those times when the only way to create a 'mingw32' build, was through a Cygwin installation and this switch. Do you mean this is needed for the Linux MingW cross-compiler environment, still? If that's the case, shouldn't we add this command line option in the starter .sh files? Brgds, Viktor On 2008.08.25., at 21:02, Przemyslaw Czerpak wrote: On Mon, 25 Aug 2008, Szakáts Viktor wrote: Hi Viktor, 2008-08-25 20:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * config/w32/mingw32.cf % -mno-cygwin options removed. No longer needed. If someone wants to compile a mingw build using cygwin, this option should be explicitly specified as C_USR/L_USR and 'gcc' should be used as a compiler. But this setup is barely supported in Harbour, so don't expect it work. (Rather, install MinGW) I do not understand. -mno-cygwin disables CYGWIN interface and forces MinGW one. -mcygwin is opposite option. Removing -mno-cygwin may break builds in environments which have CYGWIN interface enabled by default. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-08-25 20:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
On Mon, 25 Aug 2008, Szakáts Viktor wrote: Hi Viktor, > 2008-08-25 20:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu) >* config/w32/mingw32.cf > % -mno-cygwin options removed. No longer needed. If someone >wants to compile a mingw build using cygwin, this option >should be explicitly specified as C_USR/L_USR and 'gcc' >should be used as a compiler. But this setup is barely >supported in Harbour, so don't expect it work. >(Rather, install MinGW) I do not understand. -mno-cygwin disables CYGWIN interface and forces MinGW one. -mcygwin is opposite option. Removing -mno-cygwin may break builds in environments which have CYGWIN interface enabled by default. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 20:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 20:44 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * config/w32/mingw32.cf % -mno-cygwin options removed. No longer needed. If someone wants to compile a mingw build using cygwin, this option should be explicitly specified as C_USR/L_USR and 'gcc' should be used as a compiler. But this setup is barely supported in Harbour, so don't expect it work. (Rather, install MinGW) -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour OSX problem
Hi Przemek, Here's a somewhat fixed hbsetup.h + diff, what's your opinion? It's OK for me but why we still have: #define OS_DOS_COMPATIBLE instead of: #define HB_OS_DOS_COMPATIBLE ? Yes, I've cleaned this just now. BTW HB_OS_UNIX_COMPATIBLE is for native *nix systems and environments which try to emulate them, f.e. CYGWIN or CEGCC (it's not MinGW-CE). Probably we can remove it and use HB_OS_UNIX but first we should clean CYGWIN builds. I've seen in change log: ; TOFIX: (for __CYGWIN__) ../../filesys.c: In function `hb_fsPOpen': ../../filesys.c:577: warning: passing arg 1 of `pipe' from incompatible pointer type It means that in CYGWIN builds WIN32_IO is used and mixed with stdio. It cannot work. CYGWIN port developers should decide what they want to do. Use native windows API or POSIX one. If POSIX then all calls to MS-Win functions should be excluded and it should use int for file handles. In such case we can HB_OS_UNIX for this build and undef HB_OS_WIN32. Otherwise I do not see big sense in keeping CYGWIN builds as long as we have MinGW one. Well, if you ask me I think we can safely drop Cygwin as a supported platform. It sort of works after today's patches, but I wonder what is the point, GCC is an older version (3.4.4), installation is less straightforward, all executable are cygwin1.dll dependent, -mno-cygwin doesn't seem to currently work with Harbour... In case it can make things more clear inside Harbour, I'd say to drop support altogether. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 20:36 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 20:36 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * utils/hbmake/hbmake.prg ! Harbour executable detection cleanups and fix to look into current dir and detect Darwin as a Unix platform. (usable state is still very far) -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour OSX problem
On Mon, 25 Aug 2008, Szakáts Viktor wrote: Hi Viktor, > Here's a somewhat fixed hbsetup.h + diff, what's your opinion? It's OK for me but why we still have: #define OS_DOS_COMPATIBLE instead of: #define HB_OS_DOS_COMPATIBLE ? BTW HB_OS_UNIX_COMPATIBLE is for native *nix systems and environments which try to emulate them, f.e. CYGWIN or CEGCC (it's not MinGW-CE). Probably we can remove it and use HB_OS_UNIX but first we should clean CYGWIN builds. I've seen in change log: ; TOFIX: (for __CYGWIN__) ../../filesys.c: In function `hb_fsPOpen': ../../filesys.c:577: warning: passing arg 1 of `pipe' from incompatible pointer type It means that in CYGWIN builds WIN32_IO is used and mixed with stdio. It cannot work. CYGWIN port developers should decide what they want to do. Use native windows API or POSIX one. If POSIX then all calls to MS-Win functions should be excluded and it should use int for file handles. In such case we can HB_OS_UNIX for this build and undef HB_OS_WIN32. Otherwise I do not see big sense in keeping CYGWIN builds as long as we have MinGW one. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 20:14 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-08-25 20:14 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbw32/w32_ole.c * removed hack with malloc()/free() directly used to avoid memory leak reports - it's not necessary in Harbour. * harbour/contrib/hbfbird/firebird.c * harbour/contrib/examples/pp/hbppcore.c ! fixed buffer size calculation in hbstrnc*() functions * harbour/contrib/hbziparch/hbzipnew.cpp % use hb_strdup() instead of hb_xgrab()/hb_strncpy() * harbour/contrib/hbnf/getenvrn.c ! use hb_xgrab() instead of hb_xalloc() - the returned value was not checked and internal error is for sure better then GPF on NULL pointer * harbour/source/rdd/dbfntx/dbfntx1.c ! use memcpy() instead of hb_strncpy() to avoid problems when there is no place for tailing 0 best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour OSX problem
Hi Przemek, Okay, after my last commit Harbour works fine on OSX. [ I left those hbsetup.h cleanups for a later time, some of my initial comments were wrong anyway. ] Brgds, Viktor On 2008.08.25., at 19:43, Szakáts Viktor wrote: Hi Przemek, HB_OS_DARWIN seems alright. I've double checked and no, HB_OS_DARWIN is not right either. unix/__unix/__unix__ are not #defined by GCC/Darwin. I think it's safe to remove those, as __APPLE__ is a recently added #define to identify OSX, so it cannot be confused with Mac OS 9 and pre versions. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 19:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 19:49 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbsetup.h ! Fixed problem where Darwin autodetection went wrong between 1.0.0rc2 -> 1.0.0. * HB_OS_DARWIN added to the HB_OS_UNIX detection list. (no functional difference, just makes it more clear.) % HB_OS_OS2_EMX removed. It was unused. * source/compiler/gencobj.c * include/hbsetup.h % Removed OS_DOS_COMPATIBLE. It's equivalent to !defined(HB_OS_UNIX_COMPATIBLE). -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour OSX problem
Hi Przemek, HB_OS_DARWIN seems alright. I've double checked and no, HB_OS_DARWIN is not right either. unix/__unix/__unix__ are not #defined by GCC/Darwin. I think it's safe to remove those, as __APPLE__ is a recently added #define to identify OSX, so it cannot be confused with Mac OS 9 and pre versions. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour OSX problem
Hi Przemek, Here's a somewhat fixed hbsetup.h + diff, what's your opinion? Brgds, Viktor hbsetup.h Description: Binary data hbsetup.h.dif Description: video/dv On 2008.08.25., at 18:36, Przemyslaw Czerpak wrote: On Mon, 25 Aug 2008, Przemyslaw Czerpak wrote: Hi Viktor, I do not know what is the exact problem and if it's Harbour related. Too few information and too small knowledge about MacOSX. BTW Are you sure that platform auto detection for MacOSX in hbsetup.h works correctly and HB_OS_DARWIN is set? The only one place where we are accessing environ variable directly is in rtl/filesys.c and looks like MacOSX section in this code: #if defined( HB_OS_DARWIN ) #include #define environ (*_NSGetEnviron()) #elif !defined( __WATCOMC__ ) extern char **environ; #endif is ignored. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour OSX problem
Hi Przemek, (this is now a bit outdated but I'm sending it anyway) I've just found a fatal problem with OSX Harbour binaries, where ./hbmake (and hbmake, hbrun and hbtest) will say this: -- dyld: Symbol not found: _environ Referenced from /Users/vszakats/harbour/test1/usr/local/bin/ libharbour.1.dylib Expected in: flat namespace -- Notice that I've just extracted the whole Harbour binary installation using 'tar -zxvf' to a test directory and I've copied .dylibs to the /bin dir. Why did you copy dynamic library to bin directory? I do not know MacOSX but IMHO it should be in one of system library directories (or link to it), f.e. /usr/lib. Try to check 'ldd', 'ldconfig', 'dyld' and related tools documentation for default library location scanned by dynamic linker. I'm testing loads of different OSX builds and I don't like to clutter my root dir structure with any of these test Harbour versions (there is no way to cleanly uninstall these things and I don't like to clutter my OSX install this way anyway, BTW it's also quite cumbersome to achieve). In fact this is also something I wouldn't want to do even on Linux, but I have no idea how to achieve it. (this is also a reason why I don't like dynamic libs, in this case I just simply wanted to run hbmake for testing). Seems like I'm trying to p*ss against the wind here, but... :/ Back to the problem: It did find the Harbour .dylib, but it cannot load it because of this missing '_environ' symbol. I've tried adding -fPIC to C flags, but same thing happened. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour OSX problem
Hi Przemek, I do not know what is the exact problem and if it's Harbour related. Too few information and too small knowledge about MacOSX. BTW Are you sure that platform auto detection for MacOSX in hbsetup.h works correctly and HB_OS_DARWIN is set? The only one place where we are accessing environ variable directly is in rtl/filesys.c and looks like MacOSX section in this code: #if defined( HB_OS_DARWIN ) #include #define environ (*_NSGetEnviron()) #elif !defined( __WATCOMC__ ) extern char **environ; #endif Good find. HB_OS_DARWIN seems alright. But, this snippet is also guarded with HB_OS_UNIX_COMPATIBLE, and the detection of this one is indeed wrong (and it was wrong for quite a long time). Detection also looks quite clumsy to me. We should also fix HB_OS_UNIX detection to not rely on HB_OS_UNIX_COMPATIBLE. (but rather vice-versa) ] And another one: Maybe HB_OS_UNIX_COMPATIBLE is completely unnecessary, as we also seems to have HB_OS_UNIX, which seems to be enough for its purpose. If we're at it, I'm also not sure if it's right to set HB_OS_BSD, when HB_OS_DARWIN is detected. The idea was to have _one_ such HB_OS_* macro #defined at a time. What do you think? And who wants to clean this? :) Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour OSX problem
On Mon, 25 Aug 2008, Przemyslaw Czerpak wrote: Hi Viktor, > I do not know what is the exact problem and if it's > Harbour related. Too few information and too small knowledge > about MacOSX. BTW Are you sure that platform auto detection for MacOSX in hbsetup.h works correctly and HB_OS_DARWIN is set? The only one place where we are accessing environ variable directly is in rtl/filesys.c and looks like MacOSX section in this code: #if defined( HB_OS_DARWIN ) #include #define environ (*_NSGetEnviron()) #elif !defined( __WATCOMC__ ) extern char **environ; #endif is ignored. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 18:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 18:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * source/common/hbver.c ! Fix to commit '2008-07-11 18:20 UTC+0200' which effectively disabled Vista/2008 detection for everything but MSVC (>1400) compilers. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour OSX problem
On Mon, 25 Aug 2008, Szakáts Viktor wrote: Hi Viktor, > I've just found a fatal problem with OSX Harbour binaries, > where ./hbmake (and hbmake, hbrun and hbtest) will say this: > -- > dyld: Symbol not found: _environ > Referenced from /Users/vszakats/harbour/test1/usr/local/bin/ > libharbour.1.dylib > Expected in: flat namespace > -- > Notice that I've just extracted the whole Harbour > binary installation using 'tar -zxvf' to a test > directory and I've copied .dylibs to the /bin dir. Why did you copy dynamic library to bin directory? I do not know MacOSX but IMHO it should be in one of system library directories (or link to it), f.e. /usr/lib. Try to check 'ldd', 'ldconfig', 'dyld' and related tools documentation for default library location scanned by dynamic linker. > Could that be a problem? yes but also many other things can cause it. F.e. missing -fPIC on some platforms. > If this is indeed a problem, 1.0.0 is also affected. I do not know what is the exact problem and if it's Harbour related. Too few information and too small knowledge about MacOSX. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] AADD() - tilts under stress test
Hi Przemek, Well, you're right, I've tried this same example with MingW and it happily goes up to 10 iterations, with a top memory consumption of 32MB. Then I tested with BCC 5.8 and it went mad a bit later @ 4, and stayed on 232MB until reaching 10. One more reason to avoid BCC 5.5 for final apps. I think I'll now switch to 5.8 for the base compiler for both Harbour and on my projects (until switching to GCC that is). Brgds, Viktor On 2008.08.25., at 17:30, Przemyslaw Czerpak wrote: On Mon, 25 Aug 2008, Szakáts Viktor wrote: Hi Viktor, Classic problem with memory fragmentation. Algorithms used by your C compiler to allocate memory from OS and then divide it for application do not work well with such code which is BTW killer for many memory managers. We can try to reduce this problem by adding code for array preallocation anyhow programmers should now about it and try to write more memory manager friendly code. The problem with this is that such code (AAdd( a, v )) is fairly common in regular Clipper code and even in Harbour core .prg code. In tbrowse.prg for example, there is no way to know the number of columns in advance. teditor/dirscan are also affected. There is no problem with AADD() but with the _very_ large array and memory manager which is simply fatal. F.e. your code works perfectly on Linux with GLIBC. I added at the end: ? memory( HB_MEM_USED ) compiling it with FMSTAT and it reports: 4965585 It allocates less then 5MB for Harbour structures. It means that it should not need more then 20MB from OS if memory manager does not have some serious internal problems (in Linux total application memory is 17MB). I guess you are using BCC. Please try to compile Harbour with -DHB_FM_WIN32_ALLOC and check the results. It will be interesting if also default windows memory manager is effected. This example is very trivial and should not be a problem for good memory manager. The end result is that it's difficult to really exploit the "unlimited" size of arrays in Harbour since it chokes much earlier because of this. IOW AADD() can easily be considered as dangerous. If memory manager does not have some basic protection against memory fragmentation then any function which allocates memory can be dangerous in long working programs. Sooner or later we will have to implement our own memory manager which will be tuned for Harbour structures. Maybe we should try to replicate the xhb preallocation (and maybe lazy shrinking) methods to avoid this. But you probably have some other and/or better ideas too. We will add preallocation but I would like to join this modification with our own memory manager. Please remember that some CRTLs have quite nice MM and works very well without user preallocation, f.e. the one from GLIBC in Linux. Adding item preallocation like in xHarbour arrays reduces only the problem. But if your example exploits it with C compiler you are using then I can easy create other example which will also exploit current xHarbour code. [ I also wonder what other Harbour parts could suffer from the same effect. ] Pure AADD() is not dangerous as long as total memory consumption is less then half of total memory available for process. To recreate the problem it's necessary to resize many times very large array allocating new memory blocks between resizing using some primitive or buggy memory manager. AFAIR we only have one place which may need very large arrays resized dynamically. It's HB_DirScan(). I even though about changing this code to make preallocation but I was too lazy ;-( I can update it quite fast. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour OSX problem
Hi Przemek and all, I've just found a fatal problem with OSX Harbour binaries, where ./hbmake (and hbmake, hbrun and hbtest) will say this: -- dyld: Symbol not found: _environ Referenced from /Users/vszakats/harbour/test1/usr/local/bin/ libharbour.1.dylib Expected in: flat namespace -- Notice that I've just extracted the whole Harbour binary installation using 'tar -zxvf' to a test directory and I've copied .dylibs to the /bin dir. Could that be a problem? If this is indeed a problem, 1.0.0 is also affected. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] AADD() - tilts under stress test
On Mon, 25 Aug 2008, Szakáts Viktor wrote: Hi Viktor, > >Classic problem with memory fragmentation. Algorithms > >used by your C compiler to allocate memory from OS and > >then divide it for application do not work well with such > >code which is BTW killer for many memory managers. > >We can try to reduce this problem by adding code for > >array preallocation anyhow programmers should now about > >it and try to write more memory manager friendly code. > The problem with this is that such code (AAdd( a, v )) > is fairly common in regular Clipper code and even in > Harbour core .prg code. In tbrowse.prg for example, > there is no way to know the number of columns in advance. > teditor/dirscan are also affected. There is no problem with AADD() but with the _very_ large array and memory manager which is simply fatal. F.e. your code works perfectly on Linux with GLIBC. I added at the end: ? memory( HB_MEM_USED ) compiling it with FMSTAT and it reports: 4965585 It allocates less then 5MB for Harbour structures. It means that it should not need more then 20MB from OS if memory manager does not have some serious internal problems (in Linux total application memory is 17MB). I guess you are using BCC. Please try to compile Harbour with -DHB_FM_WIN32_ALLOC and check the results. It will be interesting if also default windows memory manager is effected. This example is very trivial and should not be a problem for good memory manager. > The end result is that it's difficult to really exploit > the "unlimited" size of arrays in Harbour since it > chokes much earlier because of this. IOW AADD() can > easily be considered as dangerous. If memory manager does not have some basic protection against memory fragmentation then any function which allocates memory can be dangerous in long working programs. Sooner or later we will have to implement our own memory manager which will be tuned for Harbour structures. > Maybe we should try to replicate the xhb preallocation > (and maybe lazy shrinking) methods to avoid this. But > you probably have some other and/or better ideas too. We will add preallocation but I would like to join this modification with our own memory manager. Please remember that some CRTLs have quite nice MM and works very well without user preallocation, f.e. the one from GLIBC in Linux. Adding item preallocation like in xHarbour arrays reduces only the problem. But if your example exploits it with C compiler you are using then I can easy create other example which will also exploit current xHarbour code. > [ I also wonder what other Harbour parts could suffer > from the same effect. ] Pure AADD() is not dangerous as long as total memory consumption is less then half of total memory available for process. To recreate the problem it's necessary to resize many times very large array allocating new memory blocks between resizing using some primitive or buggy memory manager. AFAIR we only have one place which may need very large arrays resized dynamically. It's HB_DirScan(). I even though about changing this code to make preallocation but I was too lazy ;-( I can update it quite fast. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 17:13 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 17:13 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * common.mak * utils/hbmake/Makefile * utils/hbmake/bld_b32.bat * utils/hbmake/bld_vc.bat * utils/hbmake/hbmake.prg - utils/hbmake/hbmutils.prg * hbmutils.prg merged into hbmake.prg. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 17:05 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 17:05 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * utils/hbdoc/bld_vc.bat * utils/hbdoc/bld_b32.bat * utils/hbmake/bld_b32.bat * utils/hbmake/bld_vc.bat + Harbour option: /w2 - Harbour option: /gc0 (now default) * common.mak * utils/hbmake/Makefile * utils/hbmake/bld_b32.bat * utils/hbmake/bld_vc.bat * utils/hbmake/hbmake.prg - utils/hbmake/pickarry.prg % Eliminated all STATIC vars in pickarry.prg. * pickarry.prg merged into hbmake.prg. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 16:37 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 16:37 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * common.mak * utils/hbmake/Makefile * utils/hbmake/bld_b32.bat * utils/hbmake/bld_vc.bat * utils/hbmake/hbmake.prg * utils/hbmake/hbmutils.prg * utils/hbmake/tmake.prg - utils/hbmake/ft_funcs.prg - utils/hbmake/tmake.prg ! Applied patches sent by Bill Robertson. ft_funcs.prg got replaced by standard file handling functions and HB_FREADLINE(), EOL handling fixes, typos and other fixes. Many thanks Bill. * Eliminated STATIC var in tmake.prg * Merged tmake.prg into hbmake.prg. (this was the easiest way to make the new s_aEOL variable available to this module.) ; Please test. * common.mak * utils/hbdoc/Makefile * utils/hbdoc/bld_b32.bat * utils/hbdoc/bld_vc.bat + utils/hbdoc/hbdfrdln.c + Added HB_FREADLINE() to hbdoc, too. It's not used, just a small help to allow using it here, too, instead of ft_funcs.prg. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error updating SVN
-Messaggio Originale- Da: "Enrico Maria Giordano" <[EMAIL PROTECTED]> A: "Harbour Project Main Developer List." Data invio: lunedì 25 agosto 2008 16.03 Oggetto: [Harbour] Error updating SVN REPORT of '/svnroot/harbour-project/!svn/vcc/default': Could not read response It's ok now. 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 Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-08-24 20:40 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Thanks Viktor, now work fine. Best Regards GVS Szakáts Viktor escribió: 2008-08-24 20:40 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/hbole/ole2.c ! Fixed GPF reported by Guillermo. (introduced in 1.0.0rc2 when switching from parnl to parptr as 64-bit cleanup, two calls were missed from the update). ! Fixed another potential problem. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour --- Texto añadido por Panda IS 2008: Este mensaje NO ha sido clasificado como SPAM. Si se trata de un mensaje de correo no solicitado (SPAM), haz clic en el siguiente vínculo para reclasificarlo: http://localhost:6083/Panda?ID=pav_745&SPAM=true&path=C:\Documents%20and%20Settings\Usuario\Configuración%20local\Datos%20de%20programa\Panda%20Software\AntiSpam --- ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error updating SVN
REPORT of '/svnroot/harbour-project/!svn/vcc/default': Could not read response 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 Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 16:01 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-08-25 16:01 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/macro.c
* harbour/source/vm/hvm.c
! fixed _FIELD indirectly used as alias, f.e.:
? ("_FIELD")->NAME
or:
M->var := "_FIELD"
? ("&var")->NAME
* harbour/include/hbclass.ch
* harbour/include/common.ch
* use a little bit simpler form for HB_SYMBOL_UNUSED()
* harbour/contrib/hbw32/w32_ole.c
* harbour/contrib/hbole/ole2.c
! fixed numeric to pointer casting
* accept both pointer and numeric values as window handle
for easier code migration
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] AADD() - tilts under stress test
Hi Przemek, Thanks for the explanation, std C allocator was a suspect for me, too. Classic problem with memory fragmentation. Algorithms used by your C compiler to allocate memory from OS and then divide it for application do not work well with such code which is BTW killer for many memory managers. We can try to reduce this problem by adding code for array preallocation anyhow programmers should now about it and try to write more memory manager friendly code. The problem with this is that such code (AAdd( a, v )) is fairly common in regular Clipper code and even in Harbour core .prg code. In tbrowse.prg for example, there is no way to know the number of columns in advance. teditor/dirscan are also affected. The end result is that it's difficult to really exploit the "unlimited" size of arrays in Harbour since it chokes much earlier because of this. IOW AADD() can easily be considered as dangerous. Maybe we should try to replicate the xhb preallocation (and maybe lazy shrinking) methods to avoid this. But you probably have some other and/or better ideas too. [ I also wonder what other Harbour parts could suffer from the same effect. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Question abour arrised error
Is that mistake should show? ? (GetNew())->Jamon Now appears : Error BASE/1065 Error de argumento: & ( Why & ) ? instead of : Error BASE/1002 No existe el alias: () or similar Best regards, Miguel Angel Marchuet ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 14:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * source/vm/cmdarg.c ! hb_hInstance, hb_hPrevInstance, s_iCmdShow, s_WinMainParam vars marked as 'static', hb_ prefix changed to s_. NOTE: This may pose a problem if some 3rd party code was relying on the names or the fact that these vars were exported by incident (since they were not declared in any Harbour headers.) [INCOMPATIBLE] * contrib/hbwhat32/whtmain.c ! Removed WinMain() function and some global vars colliding with some Harbour core ones. * HINSTANCE(), HPREVINSTANCE(), NCMDSHOW() functions now use Harbour API calls to retrieve values. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-08-23 11:38 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Hi Przemek,
Nice to see you back.
; Przemek, could you double check these changes pls?
I can send you the .diff if it helps.
I've just created one myself.
In few places this modifications are wrong and introduced bugs.
F.e. In DBFNTX replacing strncpy() by hb_strncpy() causes that
setting 'key_expr' damages 'unique' flag.
In most of cases when I was using strncpy() instead of hb_strncpy()
it was intentional because trailing 0 was not necessary or even
_MUST_NOT_BE_ set when string allocates whole buffer, f.e. in
low RDD structures.
Okay, can we someone make it like it so that we can
differentiate between legitimate and intentional
usage and possible mistakes? Maybe a macro, or comment
would do good.
Also, would you prefer to refix those parts which are
now wrong or should I just revert some or all of them?
I also do not find replacing all:
hb_strncpy( dest, src, CONST_DEFINE )
with:
hb_strncpy( dest, src, sizeof( dest ) - 1 )
as good idea because it will make code updating harder in some
cases, f.e. when I will want to change in some structure:
struct
{
...
char szBuffer[ BUFF_SIZE ];
...
}
with:
struct
{
...
char *szBuffer;
...
}
Yes, it's the only disadvantage I could actually find.
Dunno how this will be a problem in practice, pls
advise what to do.
to allocate buffer dynamically. Now I will have to check and updated
all places where szBuffer is set and restore previous version.
In many places the above modifications were really good idea but
I will have to revert them in some others to fix bugs and for easier
code modifications in the future. I'll try to check them carefully.
BTW: in contrib/hbwhat32/_winmain.c we have yet another WinMain()
implementation. I guest it exists for some historical reasons.
It should be removed and additional functions should be changed
to use variables set by source/vm/mainwin.c
Okay, I'll try to do that.
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] AADD() - tilts under stress test
On Fri, 22 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
> This reduced example give pretty much the same effect:
> ---
> Function Main()
> Local i
> Local aRecs := {}
>
> for i := 1 to 10
> aadd( aRecs, {} )
> ? i
> next
>
> Return nil
> ---
> It goes wild after a little more while.
> (400MB @ i = 4, 900MB @ i = 5000).
Classic problem with memory fragmentation. Algorithms
used by your C compiler to allocate memory from OS and
then divide it for application do not work well with such
code which is BTW killer for many memory managers.
We can try to reduce this problem by adding code for
array preallocation anyhow programmers should now about
it and try to write more memory manager friendly code.
> Strangely, replacing {} with "1234567890123456"
> seems to make it work okay.
It's expected because literal strings does not allocate
new memory and you do not have problem with fragmentation.
Change "1234567890123456" to space(32) and check what will
happen.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 14:12 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-08-25 14:12 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * make_vc.mak * make_vcce.mak % Cleaned list of system libraries for VC. winspool.lib removed, the rest documented. * Syncing between VC and VCCE. ; NOTE: WinCE system lib list didn't get anything removed (just added), but nevertheless pls test it. * ChangeLog * Some cleanups (regarding my entries). * source/pp/hbpp.c ! Comment typo. * source/rtl/gtclip.c ! Fixed for __CYGWIN__. * contrib/hbw32/dllcall.c ! Disabled asm parts for __CYGWIN__ to make it compile. * config/w32/gcc.cf ! Added missing system lib wsock32 for Cygwin. * config/w32/gcc.cf * config/w32/cemgw.cf * config/w32/mingw32.cf * config/w32/owatcom.cf * config/w32/pocc.cf * config/w32/watcom.cf * config/w32/xcc.cf * Attempt to sort out system libs needed for core from those needed for contribs. No system libraries have been removed or added so far. [ I wonder why we need to include contrib sys lib dependencies here, when Harbour GNU make system doesn't build any contrib dependent executables. Also, some ws2_32.lib seems definitely superfluous. ] ; TOFIX: (for __CYGWIN__) ../../filesys.c: In function `hb_fsPOpen': ../../filesys.c:577: warning: passing arg 1 of `pipe' from incompatible pointer type -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-08-25 14:09 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-08-25 14:09 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/tests/rddtest/rddmktst.prg * harbour/tests/rddtest/adscl52.prg * harbour/tests/rddtest/adscl53.prg * harbour/tests/rddtest/ntxcl52.prg * harbour/tests/rddtest/ntxcl53.prg * harbour/tests/rddtest/cdxcl52.prg * harbour/tests/rddtest/rddtst.prg * harbour/tests/rddtest/cdxcl53.prg * added copyright note. It's my code. * harbour/source/debug/dbgentry.c ! strip function name from module name used to initialize global and file wide variables. It fixes presenting file wide static variables in debugger. * harbour/source/debug/debugger.prg % minor optimization best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-08-23 11:38 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
On Sat, 23 Aug 2008, Szakáts Viktor wrote:
Hi Viktor,
[...]
>; Przemek, could you double check these changes pls?
> I can send you the .diff if it helps.
I've just created one myself.
In few places this modifications are wrong and introduced bugs.
F.e. In DBFNTX replacing strncpy() by hb_strncpy() causes that
setting 'key_expr' damages 'unique' flag.
In most of cases when I was using strncpy() instead of hb_strncpy()
it was intentional because trailing 0 was not necessary or even
_MUST_NOT_BE_ set when string allocates whole buffer, f.e. in
low RDD structures.
I also do not find replacing all:
hb_strncpy( dest, src, CONST_DEFINE )
with:
hb_strncpy( dest, src, sizeof( dest ) - 1 )
as good idea because it will make code updating harder in some
cases, f.e. when I will want to change in some structure:
struct
{
...
char szBuffer[ BUFF_SIZE ];
...
}
with:
struct
{
...
char *szBuffer;
...
}
to allocate buffer dynamically. Now I will have to check and updated
all places where szBuffer is set and restore previous version.
In many places the above modifications were really good idea but
I will have to revert them in some others to fix bugs and for easier
code modifications in the future. I'll try to check them carefully.
BTW: in contrib/hbwhat32/_winmain.c we have yet another WinMain()
implementation. I guest it exists for some historical reasons.
It should be removed and additional functions should be changed
to use variables set by source/vm/mainwin.c
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Suggestion for harbour web site?
Please post here any suggestion for harbour website ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] hbmake
i want refer a good documentation regarding harbour as chm/html http://www.oohg.org/manual/harbour/(x)harbour.html It is made by free helpmaker (http://www.vizacc.com/Default.aspx ) HelpMaker is a good Help Authoring tool.It can export htm,pdf,rtf This documentation is made by Janusz in the oop minigui project and i have his agreement on upload on Harbour csv. Can we include this documentation on next harbour distribution? -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di bill robertson Inviato: giovedì 21 agosto 2008 22.06 A: Harbour Project Main Developer List. Oggetto: Re: [Harbour] hbmake - Original Message - From: "Szakáts Viktor" <[EMAIL PROTECTED]> To: "Harbour Project Main Developer List." Sent: Thursday, August 21, 2008 2:11 PM Subject: Re: [Harbour] hbmake > Hi Bill, > > Can you send me a patch for the current version > of hbmake, with your fixes? > Hi Viktor, I never patched hbmake, only hbdoc and the fixes for hbdoc were for DOS/Windows only tools which are fairly limited in scope. I was hoping that someone would have answered your request in Dec for input about using a more modern documentor such as robodoc or natural doc. I thought about adding a module to hbdoc to produce robodoc files. However, when I looked at the document files, their format and quality was inconsistent. Some of the better docs didn't have any of the tags that hbdoc used. For example, none of the text files in \harbour\doc\ have the $tag$ format and they contain quite useful information. Most, but not all, of the text files in the en/ and es/ directories have $tag$ formats. To a lesser extent, the same is true of the .prg and .c files. Some of the files have no more than the following information. This isn't in the standard hbdoc format and while my changes handled this OK; it's of very limited use. * $Doc$ * $Description$ Debug function tests. *Based on classes.prg * $Requirement$ source\tools\stringp.prg *source\rtl\objfunc.prg *source\rtl\asort.prg * $End$ Because of these little problems, I loaded the windows version of the groff document processing packages and looked at the old macros I used to use with UNIX System V. Those macros (man, me, ms, mm) seem pretty dated to me now. Even the new mom macro didn't seem to produce much improvement without a lot of effort. No wonder xHarbour had such a cost overrun with their manual produced by Dr. Ziegler. As it stands, your idea of moving hbdoc and hbmake out of the main stream may be best. I might be able to make some small improvements in hbdoc and hbmake, but I'm quite novice compared to the harbour developers. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Wich choice for Multi-Window GT ?
Now that xharbour 1.0.0.0 is released, I hope that start exchange of opinion about MultiWIndows Gt proposed by Pritpal -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Pritpal Bedi Inviato: lunedì 16 giugno 2008 1.05 A: harbour@harbour-project.org Oggetto: [Harbour] Multi-Window GT - New Implementation Hello Viktor, all <<< hb_wSelect( [] ) -> nPrevSelectedWnd hb_wOpen( ... ) -> hb_wClose( wnd ) hb_wDispOut( wnd, "Text" [, cnColor ] ) hb_wDispOutAt( wnd, 10, 10, "Text" [, cnColor ] ) hb_wSetColor( wnd [, cnColor ] ) -> hb_wSetPos( wnd, r, c ) hb_wRow( wnd ) -> r hb_wCol( wnd ) -> c hb_wBox( wnd, ... ) hb_wShadow( wnd[, nMode ] ) -> hb_wMove( wnd, ... ) hb_wShow( wnd ) hb_wHide( wnd ) hb_wMaxRow( wnd ) hb_wMaxCol( wnd ) hb_wList() -> (list of all open windows) >>> <<< After such call all regular display functions will be rerouted to the selected window. Existing classes and other program parts which are supposed to keep writing to the same window (like TBrowse), should internally store the selected window at creation time, and select this whenever doing any output. >>> I am ready to provide the multi-window in above said manner. All output/input goes to window selected with hb_wSelect( [] ) -> nPrevSelectedWnd though other windows may be viewable by a click. It will need few more methods to be implemented in core GT. The skelton will be like: nWnd := hb_wCreate/Open( nTop, nLeft, nBottom, nRight ) /* NOTE: Base window will ever be 0 */ if nWnd > 0 ? SetAppWindow() // 1 SetColor( 'N/W' ) CLS @ 10,10 SAY [x]Harbour' @ 12,10 GET someVrbl READ Hb_wDestroy/Close( nWnd ) endif Now suppose base window is clicked by the user while nWnd is in READ state, how the GT should respond to it ? We may work on two angles: 1) Make it a modal window so that user is never allowed to click on base window. 2) Allow user to view the contents of base window then he is to click again on nWnd. If we agree on this I can start working on it. Basic prototype should be ready within a day or two. We can guard these method in core with a define also. Because these methods are additions and interfere nothing with thw core code, I suggest to keep these without guard. Awaiting opinions. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/Multi-Window-GT---New-Implementation-tp17855569p17855569.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] SVN: Created tag harbour-1.0.0
Thanks to everybody but particularly to Przemek and Viktor for this superb work. -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Szakáts Viktor Inviato: mercoledì 13 agosto 2008 17.42 A: Harbour Project Main Developer List. Oggetto: [Harbour] SVN: Created tag harbour-1.0.0 Hi all, I've created Harbour 1.0.0 tag just now. URL: https://harbour-project.svn.sourceforge.net/svnroot/harbour-project/tags/harbour-1.0.0 To use it, export the URL with 'svn export '. This URL is meant to be read-only, so don't checkout, and even more so don't commit to it anything. Again: Commit 1.0.0 patches to branch 1.0, and continue towards 1.1 development in main branch (trunk). [ Next move is to upload source downloads, than binaries, and update our homepage, and announce the release in relevant places. ] [ I'll now go to breath some fresh air to Sziget 2008 though :) ] Many thanks for everyone to help reaching this point. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
