[Ant]

So, I was very happy to be able to continue to work on Duit.
and I did, but...
I forgot to change the wrapper to move the import to the module level!
rebuilt all Duit classes and...
Did I get the same problem again? did I?
No!



Ant

[larsivi]

Hmm, I haven't made a comment on your discoveries, yet, but, I think the problems we looked into the other day (and the results you get now), IS a bug in DMD.

As long as class internal imports are allowed, and gives inconsistent results for some different versions of the rest of the code, the feature must be considered dangerous. Also, the exact errors we saw (calling the wrong methods) certainly don't have to do with symbol conflicts or similar, it wasn't as if the wrong drawRectangle method were called, but entirely other addresses in the executable (someone unnamed as far as I could see). As for why it matched those two parameters, I guess it has to do with the calling convention and how arguments are passed (the other way round).

[Ant]

[JJR]

I don't understand what you are saying, Ant.

Are you saying that the DUIT demo now works whether or not the imports are moved out of the class?

So the import wasn't the issue after all? It's not clear what you mean, but Lars seems to understand you?

What bug are you referring to in DMD?

-JJR

[larsivi]

I'm not sure I understood what happens now, after Ant did some stuff, I only said that what we observed the other day definately is a bug, whether it is in the within the class import code, or elsewhere. The address of the functions called (as inspected by printing the address using writef), equalled the address of some other function in the executable (these addresses was found by inspecting the executable using an early version of ELF-empowered ddlinfo). For example i printed drawRectangle's address using writef, then I searched the exe for that address, and got the symbol for Window.move (the one that was actually called).

This means that symbol conflicts or whatever would be a very bad excuse, as the function within the program get another address than originally assigned to it during linking. Getting it correct is "just" a matter of looking up the correct symbol, but I don't know where this happens. It might be a linux related problem, maybe a bug there, maybe related to the recently added -fPic code. Who knows. As it happens with a coding style few other even has tried the last year, I personally don't think it is an important bug, but a bug nonetheless. If nothing else, Walter should disallow such usage.

[h3r3tic]

The problem occurs only when linking a separate .a file with Duit. When all (with the example program) is compiled using Build, everything is fine.

Back to the bug:
I've tried 3 times stripping Duit to get a smaller version and each time I apparently stripped too much and got ... a working version :/
Have you got a version without all the gdk_ and g_object_ calls ? It's much easier to work without it...

[h3r3tic]

Nevermind. Regexps to the rescue

[h3r3tic]

I've got the bug pinned down. Posted a report on D.bugs Long life Duit !