Hello
Viktor Szakáts wrote: > > "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. > HBQT may/may not _require it_ but HBXBP certainly _requires_ it. >From the day one HBXBP acquired first few lines of code, I was very much clear about its objective, Xbase++ modal, which is compulsory a MT modal. Probably I do not need to explain more. > 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. > I never tweaked the .prg to fix GPF, I just added the closing calls which which were necessary to pacify the Qt engine, for example, discooencting the slots which cannot be implemented through GC engine. You can call it _lazyness_ to forget to write few more lines which I should ever had. > 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. > The above all points are valid. But probably I am not expert on all matters. So a deeper attention by all of you is needed to address this issue. My focus at this point is to create the framework and working engine. Lately GC pointers were implemented but I could not recover consumed memory completely. But may be it is just a matter of time before me or someone else hits the bull's eye. Separation of Components: Well, I do not think any further separation will do. QtWebKit was an exception and it is isolated, though it is needed for HBXBP to be compatible with Xbase++'s XbpHTMLViewer(), but we can live without it. All other components are inter-dependant. For deeper reasons I request today, and had requested in the past too, Przemek's attention to this project. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13103--trunk-harbour-tp26627429p26683144.html Sent from the Harbour - Dev 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
