Revision: 13247
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13247&view=rev
Author: vszakats
Date: 2009-12-15 10:27:17 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-15 11:26 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* ChangeLog
! Fixed Cha
Revision: 13248
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13248&view=rev
Author: vszakats
Date: 2009-12-15 10:53:13 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-15 11:36 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbqt/hbqt.hbc
*
Hi All,
>We already have part of this enabled in fm.c, but only
>when building core in C++ mode, and if FMSTAT is enabled.
I tried to activate this part with:
@set HB_BUILD_MODE=cpp
@set HB_USER_CFLAGS=-DHB_FM_STATISTICS
in hbqt.hbc:
from:
{allgcc}lib
Hi,
>> We already have part of this enabled in fm.c, but only
>> when building core in C++ mode, and if FMSTAT is enabled.
>
> I tried to activate this part with:
>
> @set HB_BUILD_MODE=cpp
> @set HB_USER_CFLAGS=-DHB_FM_STATISTICS
> in hbqt.hbc:
> from:
> {allg
On Tue, 15 Dec 2009, Bisz István wrote:
Hi,
> >We already have part of this enabled in fm.c, but only
> >when building core in C++ mode, and if FMSTAT is enabled.
> I tried to activate this part with:
> @set HB_BUILD_MODE=cpp
> @set HB_USER_CFLAGS=-DHB_FM_STATISTICS
> in hbqt.h
Hi,
> Are you using single thread HVM intentionally?
No, in MT everything is ok, but I was rejected by Viktor, argued that MT
generates ~40% performance reduction.
> As long as USE_DL_PREFIX is not defined then DLMALLOC is not disabled
> on HVM exit so we should not have any problems on exit in
>> Are you using single thread HVM intentionally?
>
> No, in MT everything is ok, but I was rejected by Viktor, argued that MT
> generates ~40% performance reduction.
I rejected it because it doesn't seem like a _real_
solution, just a hack which accidentally (or at least
for unknown reason) w
Thanks.
It's half guessing, but it may mean that not all QT objects
are released by HBQT at HVM deinit.
One reason for this may be current default
HBQT_RELEASE_WITH_DELETE_LATER memory releasing mode.
The name suggest that this mode is also a way to hide
possible problems (GPFs) when using po
>One reason for this may be current default HBQT_RELEASE_WITH_DELETE_LATER
memory releasing mode.
Just one observation, to be more precise, in hbqt the default is
overwritten, as I remember correctly.
Best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailt
>> One reason for this may be current default HBQT_RELEASE_WITH_DELETE_LATER
> memory releasing mode.
> Just one observation, to be more precise, in hbqt the default is
> overwritten, as I remember correctly.
I guess you meant demoqt, and you're right. demoqt sets
memory release mode to HBQT_RELE
On Tue, 15 Dec 2009, Bisz István wrote:
Hi,
> >I can define USE_DL_PREFIX as default in ST builds but I'm afraid that
> >it will only hide some problems in HBQT code instead of resolving them.
> The default ST with VS2008 woks, just the default ST with MinGW fails on
> the first delete operator.
Hi Viktor,
As I have o more argues and we are back to some original issues, I am
stopping to write more on this thread.
But an another case should be analyzed too: if we define HB_FM_STD_ALLOC,
everything goes well, without crashes.
Best regards,
István
-Original Message-
From: harbour-b
> In previous messages you said that it crashes on application exit.
> Now on 1-st delete operator. So where it crashes really?
On application exit when the first delete operator is executed.
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-pro
Hi Istvan,
> Hi Viktor,
>
> As I have o more argues and we are back to some original issues, I am
> stopping to write more on this thread.
> But an another case should be analyzed too: if we define HB_FM_STD_ALLOC,
> everything goes well, without crashes.
It's also a system-wide setting (which B
Hi All,
cl.exe -I. -I../../../../../../include -nologo -Gs -TP -W4 -wd4127 -Ot2b1
-EHs-c- -IF:\devl\Qt\4.6.0-msvc\include -IF:\devl\Qt\4.6.0-msvc\include/QtCore
-IF:\devl\Qt\4.6.0-msvc\include/QtGui -IF:\devl\Qt\4.6.0-msvc\include/QtNetwork
-DQ»
hbqt_hbqsyntaxhighlighter.cpp
f:\devl\qt\4.6.0
Hi,
Am I missing something ?
I just tried the latest SVN release and now
Wapi_MessageBox(,"Hello éèçà","Test accents",) // same for legacy version
MessageBox(.)
Give me some garbage in place of specials chars ...
Regards,
JF<>___
Harbo
Revision: 13249
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13249&view=rev
Author: vszakats
Date: 2009-12-15 17:12:19 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-15 18:11 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* package/winuni/RELNOTES
Hi All,
I excluded most well known warnings.
win/msvc (PSDK 7):
-
...\harbour\src\compiler\obj\win\msvc\harboury.c(7003) : warning C4701:
potentially uninitialized local variable 'hb_complval' used
...\harbour\src\macro\obj\win\msvc\macroy.c(2985) : warning C4701: potentially
uninit
Hi JF,
You have to inform Harbour about the codepage you're
using in these strings (this is for UNICODE builds of
Harbour). F.e.:
REQUEST HB_CODEPAGE_HUWIN
set( _SET_CODEPAGE, "HUWIN" )
It's also good practice to set _SET_OSCODEPAGE to
inform non-UNICODE Harbour apps about CP configured
on W
Revision: 13250
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13250&view=rev
Author: druzus
Date: 2009-12-15 18:47:43 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-15 19:47 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbini
Thanks Viktor,
I was sure of something like that :-)
I tried to find it by myself but failed :-(.
In the future, is there a place where I can find this kind of info. I looked
Changelog but without success.
In all case thanks for the info.
Friendly,
JF,
-Message d'origine-
De : harbo
Revision: 13251
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13251&view=rev
Author: druzus
Date: 2009-12-15 19:44:33 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-15 20:43 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbini
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
hi,
> * harbour/include/hbinit.h
> + added new alternative form for initialization code activated
> by HB_INITSEG_STARTUP macro. This method uses asm() directive
> to store call to startup function in .init segment.
y
Revision: 13252
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13252&view=rev
Author: druzus
Date: 2009-12-15 20:15:33 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-15 21:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbini
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
> * explicitly restore .text segment for compilers which do not make
commit typo, it says .init at the end too :)
--
[-]
mkdir /nonexistent
___
Harbour mailing list (attachment size limit
Revision: 13253
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13253&view=rev
Author: druzus
Date: 2009-12-15 20:36:02 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-15 21:35 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbini
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
hi
> Revision: 13253
now something is broken again. i'm not sure what, as at one point i
had a working harbour ("working" at this stage i define as "hbrun
starts"), now for all of gcc/c, native/c, native/c++, when trying to
run hbrun,
On Tue, 15 Dec 2009, Tamas TEVESZ wrote:
Hi,
> now something is broken again. i'm not sure what, as at one point i
> had a working harbour ("working" at this stage i define as "hbrun
> starts"), now for all of gcc/c, native/c, native/c++, when trying to
> run hbrun, i get:
> Error BASE/1003 V
Revision: 13254
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13254&view=rev
Author: druzus
Date: 2009-12-15 23:00:38 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-16 00:00 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/bin/hb-func.s
Revision: 13255
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13255&view=rev
Author: druzus
Date: 2009-12-15 23:24:29 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-16 00:24 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/bin/hb-func.s
Revision: 13256
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13256&view=rev
Author: druzus
Date: 2009-12-15 23:26:43 + (Tue, 15 Dec 2009)
Log Message:
---
2009-12-16 00:26 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/ChangeLog
Hi JF,
On 2009 Dec 15, at 20:29, J. Lefebvre wrote:
> Thanks Viktor,
>
> I was sure of something like that :-)
>
> I tried to find it by myself but failed :-(.
>
> In the future, is there a place where I can find this kind of info. I looked
> Changelog but without success.
I can't tell you,
Revision: 13257
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13257&view=rev
Author: vszakats
Date: 2009-12-16 00:02:08 + (Wed, 16 Dec 2009)
Log Message:
---
2009-12-16 00:58 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbwin/Makefile
Revision: 13258
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13258&view=rev
Author: vszakats
Date: 2009-12-16 00:03:39 + (Wed, 16 Dec 2009)
Log Message:
---
2009-12-16 01:01 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* ChangeLog
! Typo in p
Revision: 13259
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13259&view=rev
Author: druzus
Date: 2009-12-16 00:26:31 + (Wed, 16 Dec 2009)
Log Message:
---
2009-12-16 01:26 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbwin
On Tue, 15 Dec 2009, dru...@users.sourceforge.net wrote:
hi,
> Revision: 13255
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13255&view=rev
> Author: druzus
> Date: 2009-12-15 23:24:29 + (Tue, 15 Dec 2009)
>
> Log Message:
> ---
> 2009-
On Wed, 16 Dec 2009, Tamas TEVESZ wrote:
hi,
> that didn't really help, and it's getting even more strange.
[...]
nevermind. all of a sudden it started working. if i did this, i have
no idea, what did i do. i'm going to stick a screwdriver through this
thing and go become a shepherd in new ze
I wonder why this didn't came up earlier, for one thing
hbmk script is unrelated to default build process, and in
default build process -n1 option is added by config/rules.mk.
This is right for libs, but not right for bins.
(default build process also uses hbmk2, but it's
using -n1/-n2 correct
Revision: 13260
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13260&view=rev
Author: vszakats
Date: 2009-12-16 00:54:21 + (Wed, 16 Dec 2009)
Log Message:
---
2009-12-16 01:53 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/rddsql/sddmy/mysq
Hi Xavi,
This seems pretty sensitive area of Windows, so it will need testing
on all compilers and especially on WinCE. I'm not sure we should
add it right now as it may delay the release. [ apparently some of
us are already doing build tests since today ]
In the meantime, I'd like to ask you
Revision: 13261
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13261&view=rev
Author: vszakats
Date: 2009-12-16 01:10:59 + (Wed, 16 Dec 2009)
Log Message:
---
2009-12-16 02:10 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbqt/hbqt_hbqmain
On Wed, 16 Dec 2009, Viktor Szakáts wrote:
> I wonder why this didn't came up earlier, for one thing
> hbmk script is unrelated to default build process, and in
> default build process -n1 option is added by config/rules.mk.
> This is right for libs, but not right for bins.
>
> (default
Revision: 13262
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13262&view=rev
Author: vszakats
Date: 2009-12-16 02:12:27 + (Wed, 16 Dec 2009)
Log Message:
---
2009-12-16 03:11 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* config/common/watcom.mk
Revision: 13263
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13263&view=rev
Author: vszakats
Date: 2009-12-16 02:18:08 + (Wed, 16 Dec 2009)
Log Message:
---
2009-12-16 03:17 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* config/common/watcom.mk
Viktor Szakáts wrote:
win/mingw64 (4.5.0-20091118)
-
...
x86_64-w64-mingw32-gcc -I. -I../../../../../include -Wall -W -O3
-fomit-frame-pointer -DUNICODE -ohb_btree.o -c ../../../hb_btree.c
../../../hb_btree.c: In function 'Grow':
../../../hb_btree.c:740:23: warning: cast from po
Revision: 13264
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13264&view=rev
Author: vszakats
Date: 2009-12-16 02:55:28 + (Wed, 16 Dec 2009)
Log Message:
---
2009-12-16 03:54 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* contrib/hbbtree/tests/cte
Hi,
Thank you, sorry to insist but I'd like to ask you
to fix formatting. For me it's a terrible waste of
time to fix all such code to have common format which
we use in all our files. There was a lot of energy
put in that, and as in all serious projects also
in Harbour its important to keep
One more minor note: is not necessary, HB_OS_WIN_USED
takes care of it, pls delete it.
Brgds,
Viktor
On 2009 Dec 16, at 03:47, Xavi wrote:
> Viktor,
>
> Ok, adapted as WAPI_ and WinCE .-
>
> Windows CE 1.01 and later
> Windows Mobile Version 5.0 and later
>
> http://msdn.microsoft.com/en-us
Revision: 13265
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13265&view=rev
Author: vszakats
Date: 2009-12-16 03:54:07 + (Wed, 16 Dec 2009)
Log Message:
---
2009-12-16 04:53 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
* utils/hbmk2/hbmk2.prg
hi,
it seems that something is wrong with g++2.95 builds afterall.
i took a fresh checkout of 13263, and tried building it on an older
linux/i386 box that has gcc 2.95.
(i changed HB_CMP to gcc-2.05 and g++-2.95 in config/linux/gcc.mk
because this has no gcc and g++ links, but that's all that
Hello All,
As per subject.
Goal is to trace calls for only the part I am
interested in. I do not want entire application tracing.
I have tried my level best but am not been successful.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/HB_TRACE%28%29---How-to-invok
51 matches
Mail list logo
