[JJR]

Well this is getting to be a excessively frustrating. I thought I was getting somewhere, but now I realize I'm getting hopelessly confused with the way DUI works.

First off, I've succeeded in getting a dynamic loader operational for DUI. It loads up all the necessary gtk, gdk, gobject, glib, pixbuf, and pango symbols for the DUI widgets at DUI application runtime.

At the moment, I'm trying to get the symbols integrated with the DUI project. This is a whole lot tougher than I thought, and I ended up having to rearrange several things in DUI to get it "kind of" working. I'm using the latest dool update with the fixup.

Issue number 1 is this: I'm getting Access violations during program execution during the widget setup phase (HelloWorld.d DUI sample). I've peppered the source with debug printf's and have narrowed down the general location of the problem, but the problem is so bizarre that I'm confused at what to do. The major part of the issue is that DUI has adopted the style of class-local imports. This is a well known dangerous practice because of D's infamous name resolution rules. Ant, I'm not sure why you are still doing this. It makes the source extremely difficult to troubleshoot.

For example, in this case, I was exceedingly surprised to discover that the getAutoShow() method, the source of much of my confusion, was returning a consistantly invalid value from within a constructor. It took a whole lot of digging to realize that the only getAutoShow() method in Widget was not being called at all! Widget does not inherit another getAutoShow so I was completely baffled as to why it kept returning a false value. I should have known better: I recall the agonizing that Kris and I had over a similar bug in mango about a year ago.

So I decided to make a quick search for other getAutoShow() methods in other DUI files. The only other one was in dui/Window.d. Widget does not inherit from Window.d. But it does import the Window.d module inside the class. An amazing thing happens now due to this intra-class import: Widget's getAutoShow method is miraculously overridden by the imported Window's getAutoShow. Even worse, Window.getAutoShow uses the override keyword which causes even more bizarre control of Widget's getAutoShow: try to rename the method in Widget, and you find that the Window getAutoShow demands that override be honored in the Widget module... even though it doesn't even inherit from it!

This was just one source of the errors. It still doesn't completely explain why I'm getting an Access Violation on Winxp. I'm able to get to the point where a window briefly flashes on the screen, but it disappears again in nanoseconds followed by the boring Access Violation message

These local imports also have a bizarre affect on the whole DUI structure. Widget also imports the event system inside the class. This includes a whole bunch of templates. If I try to move the event system imports outside the class, a whole bunch of errors occur across a whole bunch of files. If I try to move the template and imports outside the class, more happens. The web of dependency has already been weeved together in this project.

All I can say is that I think we should absolutely, positively stay away from class-local imports. It's evil, evil, evil as long as Walter believes in his name-lookup rules, and this style is well known to cause too many hard to find bugs due to name hiding. I don't think I can do much more for dynamic system for DUI in it's current state. I really thought it would be great because it simplifies app programming with DUI greatly, but I'm in over my head when comes to sorting out the library's organization.



-JJR

[Ant]

[JJR]

Wow! Thanks, Ant, for that long and detailed reply. You've spoken very honestly and for that I'm very thankful: it's hard to get that kind of answer from people these days. I completely understand your perspective and thank you for your insight.

I may give it a few more tries as I find time, but my feelings about dmd have much the same direction as you. I keep coming back because there's so much I'm interested in doing and learning, but, in the long run, the progress in the language is disturbingly slow.

Please forgive my post above; it was a bit of a rant of exasperation. I remember the forward reference problems well and the reasons for moving the imports locally to begin with. I may try to start moving them out to see if things work again with enough manipulation.

Congrats on the home improvements... such things are much more worthwhile and appreciable than things in the programming world.

And once again, welcome to Canada! Feel free to drop me an email from time to time, or if you're nearby, a visit .

-JJR

[h3r3tic]

[JJR]

Thanks Tom,

These particular modules don't have static initializers, although I have a separate loader module that does.

It should work somehow... It will just take a fair bit of unravelling to figure out.

Thanks for the tip!

-JJR