Hi Pritpal, >> However, before we do this, I'd like know if this is indeed the >> _real_ solution to the problem. Turning on MT mode decreases performance >> by ~30% (AFAIR) in mingw, so it's not a costless option. >> > > Does not matter how slow/fast it is, but it is needed. > I cannot imagine a Windows development platform with MT support. > HBXBP/demoQT definitely exploits it though I did not implement it > for HBIDE as this interface does not require it.
"Exploits it" and "cannot imagine" doesn't mean it _requires_ it. What I'm interested in, is whether HBQT _requires it_? IMO, it should not require it, but may give extra features if available, and for sure _be compatible with it_. If current implementation _requires it_, which means it cannot work or cannot reliably work without it, we should document this fact. >> I can see some MT stuff in some hbqt files, but I can't tell for >> sure if MT is really needed, and I don't remember of such >> requirement from past discussions, and I wonder why does it seem >> work on other systems. (although hbide is also far from stable on my >> system, I had to shut it down from Task Manager, plus I also had >> GPFs today). I'm also not sure why MT mode should be obligatory for >> a GUI lib. This is a pretty important requirement to know about >> before deciding on using HBQT in ones app. >> > > See above. Sorry, but it doesn't answer my question. >> I also can't see how GPFs can still occur by .prg level programming >> errors, and I'm in the dark regarding past memory leakage issues. >> Are they solved now? I can't understand three the HBQT_RELEASE_WITH_* >> methods, is this a permanent user option now? When should it be used? >> Or is it an experiment to check which of them works? If the latter, >> do we know this already? If the former, why users have to bother with >> such low level details? >> > > It is not prg level code which may produce GPF but certainly C level code > which is called by PRG is producing it. Also note that HBIDE is still > evolving > and you have decided the outcome otherwise. This misses my question. I know that GPF is caused by machine code and machine code is generated from C sources, and C is called by .prg level code, but it's irrelevant. What I notice is that you repeatedly fix GPFs by tweaking .prg level code, which suggest that one can write such .prg code which makes lower level components fail. This is unacceptable IMO, and for sure makes it very difficult to work with such component. Since you know the HBQT details inside out, it would be nice if you could give some hints on this topic. >> Can HBQT experts advise on any of above matters? >> > > This is the real problem. Here nobody is Qt expert, everybody > is trying to extract and making its roots firm for Harbour. As said before, > I had not heard of anything about Qt before 17March2009. > > By your posts for few days last I am gathering the impression > that implementation of Qt is just waste of efforts. So I propose to > drop it all together. Not exactly. The problem is that all I see is problems, and no final resolutions to them and problems are just being piled higher and higher. What I see that we're in a hurry building on a foundation which is unstable. This is of course nice and dandy in open-source, but it's also part of open-source that such concerns that I expressed may be raised, and ideally it will result in answers, and more general knowledge about the topic and eventually it will result in code fixes, and finally in robust code. In this e-mail I was trying to get some sort of status about problems, because it's quite difficult to see where we're now. Random GPFs are usual, and fixed in .prg code and memory issues are not closed AFAIK (but I may be wrong). This causes that we don't know where to look where any problems occur. Look at the struggle with 4.6.0 and MinGW. We're still unsure whether we need C++ mode, your .prg level fix or now MT mode to make the problems disappear :( I've spent two frustrating days on this, so I decided to write this letter to try debunking these problems from the root. I hope it will happen. Now it seems some theories (like C++ mode) were false and standard (new) MinGW can be used, now the only problem is that there's no easily installable MinGW version, but this will be solved by time, so it's not showstopper for us. MSVC binary build of QT _is_ frustrating, but we didn't lose much here, as 4.5.x didn't have such build at all, so we stand at the same place. IMO these areas should be thoroughly inspected in HBQT to make it stable platform: 1) Memory handling. No leaks, reference counting, whatever is needed, and automatic. It should be transparent to .prg level programmer. IOW: _whatever_ user does from .prg, it should never ever cause a memory leak or double freeing of memory. 2) Avoiding all GPFs that may result from calling any HBQT wrappers with any wrong parameters, or any sort of random order. This means HBQT should throw RTEs or handle invalid (NULL) pointers, and there should be no reference to freed pointersm, etc etc. IOW: _whatever_ user does from .prg, it should never ever cause a GPF. 3) Separation of components. I've written more about this. This isn't a showstopper, but seems an important task. My only concern towards QT _which is out of our control_, is that it's very heavy and can't be linked statically. But, from all other aspects it looks quite good and it will probably catch on even more, so IMO we should not drop but, but rather try to fix all the parts we can and make it a robust platform for Harbour. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
