>> This would make it easy for everyone to experiment >> with it in a swift fashion (without dealing with >> the huge HBQT libs). >> >> Just an idea. >> > > It is not easy to just start from small code. > Even to execute few lines, you need the full framework > working. The only change will be couple of classes to > experiment instead of 302 we have at this time. > And this does not make any difference either.
In my opinion in makes a huge difference. Currently any experimenting pass requires a huge amount of time (change generator, build generator, run generator, rebuild all HBQT libs), and finding out the exact root of any problem takes a huge amount of time as well, simple because of the amount of code involved. I know that because I tried it in the past. > The point to emphasis is: if I write from scratch, I > have to visualize the ways how the other way is, which > after an year of heavy dwelling into exiting code fragmenents, > I find difficult if not impossible. This type of approach > is more suitable to one who starts afresh, has not any > affinity to existing code. Whatever I will do will be influenced > by existing protocols. I may not be able to find another > solution at all, and at the end, new code will look a shadow > of the original one. It is human nature and I am not the > exception. Maybe you're right, but my impression is that you never really dwelled into the details we're currently discussing. At least not before implementing the whole heavy wrapper infrastructure. Hence my suggestion to step back and look at the thing, now that you know the perspective and the problems to look for. [ It's also worth reading Przemek's last e-mail regarding the matter, as I'm almost sure there are actual answers hidden there. ] > The biggest bug at present is object destructions and this > part will be the last one if we develop another approach. > So we will come to know about whether we could resolve > this issue or not ? And what If we could not. I think you just can't state that. Object destruction to me looks like a symptom, not the root cause. IOW to make proper object destruction, you need more precise tracking of what to destruct and when, you also need to understand when and where things are _constructed_. For that you need additional logic at all involved points. (f.e. when assigning one object to another object var). > All other components are working perfectly all right so far. > > In a nut-shell: someone with new thinking process has to > step-in. This puts HBQT in a risky position. Looks like nobody is interested to touch current large and heavy code. If you have Przemek in mind (who surely could help), even to get his help, it would be much better to start off with something simple and up to the point. I think there is not much chance to expect from him to create a pret-a-porter commit for current huge codebase. On a small example we could all understand the problems, find the principal solution and implement that solution on actual HBQT code. It won't be a one time commit. At the same time you should stop masking found problems by workarounds, and instead mark all these problem parts with TOFIX markers with description of the problem. (ideally this should be done for all past problems already masked) Another thing which may help you move forward from current position is to install Linux (Ubuntu f.e.) in a VirtualBox (free) VM and experiment with HBQT and HBIDE. You will have the full power of valgrind, plus it's fun to check other platforms for real. It helped me a lot with hbmk2. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
