Viktor Szakáts wrote:
>
> You should definitely not neglect other things, since
> we should never forget the fun part and that we do
> Harbour because it gives us something. But it's fully up
> to you how to balance. If it starts to ruin other things,
> just stop. Never anybody called for a deadline or asked
> for anything to be there now and never will (or simply
> turn it down if anything like that happens.)
>
Not that anybody demanded, but because it is the
way I work... ( just outlined how somethings get skipped ).
> It's also about priorities: IMO development is not
> just pouring new code. It's about stabilizing what
> we have. It may be less fun at times, but only this
> way anything can become a serious product at the end.
> So in Harbour we tend to prioritize bug fixes over
> adding new features. IOW there is no point in having
> any feature rich product with a lose base and bugs
> lurking.
>
I will be more careful in future.
> Overall for me the only important thing is that we're
> on the right (agreed) track and speak on the same terms.
>
I was there always, you just misunderstood.
We as humans sometimes react otherwise but without
knowing it, so all is well. It happens... no issues.
> You could notice that I've fixed quite some things,
> but it's certainly not my duty to fix everything
> I happen to notice. Besides not my (or testers') duty,
> it's many times not possible, since a tester/reviewer
> doesn't also know what's the proper way, but can
> only tell that's something is wrong (this scenario
> happens when we get a bug report from user f.e.).
> HBQT is only one contrib, and we have lots of other
> things in Harbour to take care of. Plus its size is
> huge. And since you're the "father" of these components,
> you have to show care also when things are rough and
> problems are found. This is part of development.
>
> Also for me it _has_ been though but I went and
> fixed all reported hbmk2 issues to make it good and
> accepted. Believe me it was though sometimes to read
> 15 bullet points and get to the end of each of them,
> and reiterate, but it's worth it. In fact you can
> be grateful to anyone giving any sort of valuable
> feedback, it means that they care.
>
Thank you and all those helped.
Surely this is the way, I know.
> It's actually not Windows dependent matter at
> all, it's the same problem-set as in HBQT: How to
> handle the case when we assign GC collected pointers
> to low-level structures. How to ensure the object
> won't be freed by GC until it's used by low level
> structure? How to make sure it's getting released
> when it's not used anymore?
>
I got it.
This is exactly I do not have a solution to.
Lower level referencing is a must in certain situations.
Unless the reverse call to the function, which has
assigned it, is made it is not easy to free it.
In hbQT there are two places where it is like this -
hbqt_hbevents and hbqt_hbslots.cpp.
I am upgrading this issue on my priority list.
Regards
Pritpal Bedi
-----
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context:
http://n2.nabble.com/hbpqtui-class-tp4464679p4474375.html
Sent from the harbour-devel mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
