Very interesting results.
I think we should make it a high priority to fix HBQT,
otherwise everything built upon it is standing on weak
foundation.
Brgds,
Viktor
On 2010 Jan 7, at 17:20, Bisz István wrote:
> Hi,
>
>> In Fedora12 you can use valgrind which should give much
>> precise results.
>> For those interested in problem-free fixing of bugs in last
>> final release, 2.0.x branch was created at the time of the release,
>> and such work shall be done there. Volunteers may start it right
>> away by merging '[TOMERGE 2.0]' marked patches from trunk to
>> 2.0.x branch. This will ensure
> For those interested in problem-free fixing of bugs in last
> final release, 2.0.x branch was created at the time of the release,
> and such work shall be done there. Volunteers may start it right
> away by merging '[TOMERGE 2.0]' marked patches from trunk to
> 2.0.x branch. This will ensure that
Hi,
> In Fedora12 you can use valgrind which should give much
> precise results.
Thank you for the details. The link below contains the valgrind log files for
demoqt, demoxbp and hbide and a suppressions file: qt.supp:
{
demoqt_suppress_QApplication
Memcheck:Leak
...
fun:_ZN12QAp
Hi
Bisz István wrote:
>
> I should correct me, as I made a mistake in my test environment.
> Please find attached the trace files with very interesting results coming
> from Fedora12!
>
Interesting.
The logs suggest that hbqt_par_QString() is the culprit.
It is just a quick assertion and I
On Thu, 07 Jan 2010, Bisz István wrote:
Hi,
> I should correct me, as I made a mistake in my test environment.
> Please find attached the trace files with very interesting results
> coming from Fedora12!
I believe that this logs help to clean HBQT code anyhow
In Fedora12 you can use valgrind w
Why not release all 2.01?
imo TOMERGE 2.0 must be written in all 2.01 version
all hbide modify not have to merge 2.0 for example
IMO Merging is error
what part of 2.01 not be include in next release?
2010/1/7 Viktor Szakáts :
> For those interested in problem-free fixing of bugs in last
> final re
> As I see, maybe undesirable, as this list is declared a developers' list,
> but there are a lot of users in this list requesting knowledge from (us).
The fact that ppl are waiting for answers doesn't make this
a support list. We have support forums/lists which are meant to
solve these issues,
As I see, maybe undesirable, as this list is declared a developers' list,
but there are a lot of users in this list requesting knowledge from (us).
I don't know, but we are compulsively to serve them, but now we are far away
from our starting point. We should generate less protuberance in the syst
> Dear Viktor,
>
> You are right, the first goal is the software quality, but don't forget that
> there are peoples without so much knowledge about the inner things. Maybe
I still can't see what your point is.
> sometimes should be useful to put yourself in their position. But please
> consider
Dear Viktor,
You are right, the first goal is the software quality, but don't forget that
there are peoples without so much knowledge about the inner things. Maybe
sometimes should be useful to put yourself in their position. But please
consider these words, without any negative intentions, as an
On 2010 Jan 6, at 23:11, Bisz István wrote:
> Hi Viktor,
>
> We should made changes in a way that a "general user isn't affected" if it
> is possible. This is a general rule in every system life cycle.
> No problem we can handle it, as we are in development phase, forget it.
Sorry I don't under
Hi Viktor,
We should made changes in a way that a "general user isn't affected" if it
is possible. This is a general rule in every system life cycle.
No problem we can handle it, as we are in development phase, forget it.
Best regards,
István
___
Harb
On 2010 Jan 6, at 22:54, Bisz István wrote:
> Hi Viktor,
>
> For me is OK thank you, but we always should think about a general user.
I don't understand you. It's also meant for general users,
it's simply how it works, and it's even logical.
If you put options on the command line they are pro
Project Main Developer List.
Subject: Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1
test
Hi Istvan,
> The hbmk2 nohbcppmm is ineffective for hbide, so now we cant test hbide
on linux, maybe it is specific just to Fedora12.
To disable hbcppmm for hbide, pls try this command l
Hi Istvan,
> The hbmk2 –nohbcppmm is ineffective for hbide, so now we can’t test hbide on
> linux, maybe it is specific just to Fedora12.
To disable hbcppmm for hbide, pls try this command line:
hbmk2 hbide.hbp -nohbcppmm
The order of options is significant. If you issue -nohbcppmm
first, it
On Wed, 06 Jan 2010, Szak�ts Viktor wrote:
> So maybe the problem is that our malloc/realloc doesn't
> handle zero size, while std version do.
> In this case, we should probably allow zero size too.
DLMALLOC malloc()/realloc() allow to use 0 bytes. Only inside
hb_xgrab()/hb_xalloc() we have code
Behalf Of Viktor Szakáts
Sent: 2010. január 6. 19:01
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
So maybe the problem is that our malloc/realloc doesn't
handle zero size, while std version do.
In this case, we s
So maybe the problem is that our malloc/realloc doesn't
handle zero size, while std version do.
In this case, we should probably allow zero size too.
Brgds,
Viktor
On 2010 Jan 6, at 18:46, Bisz István wrote:
> Hi,
>
> Finally, I was able to put in work the hbcppmm on Fedora12 by inserting the
On Wed, 06 Jan 2010, Szak�ts Viktor wrote:
Hi,
> BTW, C++ method override comes directly from QT
> homepage, but nevertheless can be wrong or
> outdated. Maybe some variations are missing.
Or it's possible that new/delete operator overloading works
perfectly and the problem is only in our own
> Please just be creative, and simply remove -hbcppmm from hbqt.hbc locally
to disable this option. I'll look into it later.
OK. Thanks.
Best regards,
István
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://list
Hi All,
> The hbmk2 –nohbcppmm is ineffective for hbide, so now we can’t test hbide on
> linux, maybe it is specific just to Fedora12.
Please just be creative, and simply remove
-hbcppmm from hbqt.hbc locally to disable
this option. I'll look into it later.
BTW, C++ method override comes dire
22 matches
Mail list logo
