Bill Baxter Wrote:

> On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> > Bill Baxter Wrote:
> >
> >> On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >> > Bill Baxter Wrote:
> >> >
> >> >> On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >> >> > Bill Baxter Wrote:
> >> >> >
> >> >> >> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >> >> >> > Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
> >> >> >> >
> >> >> >>
> >> >> >> Was this what you saw?
> >> >> >> "Unexpected OPTLINK Termination at EIP=0044C37B"
> >> >> >> http://d.puremagic.com/issues/show_bug.cgi?id=424
> >> >> >>
> >> >> >> Whatever it was, chances are good it's a known bug.  So it would be good to figure out which one it is that you're hitting exactly.
> >> >> >>
> >> >> >> --bb
> >> >> >
> >> >> > Yes, it is this issue: "Unexpected OPTLINK Termination at EIP=0041AFFD". And yes, there is 1 quite large file, 14k lines, but because of forward reference and cyclic imports problems we can't split it currently.
> >> >>
> >> >> Do you compile it with inlining on?  Not positive about this, but you may be able to cut down on the number of fixups it needs by not using inlining.   Which file is it, anyway?
> >> >>
> >> >> --bb
> >> >
> >> > it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both inlining and non-inlining.
> >>
> >> Ok.  Is it some kind of automatically generated file?  I don't see it in the qtd repo.
> >>
> >> --bb
> > yes, all files are automatically generated. If you wish I can upload it(compiled binding with headers) somewhere.
> 
> No, that's ok.  I was just curious.  So it sounds like the best hope is to try to find some way to split it up some.  There must be some way it can be broken up, even if that requires turning some private members public.  No?
> 
> --bb

It's in one file because of cyclic imports bug in dmd. The bug with optlink seems to be old, any chance that it's going to be fixed?

On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter <wbaxter@gmail.com> wrote:

>On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha <samukha@voliacable.com.removethis> wrote:
>> On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
>>
>>>Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
>>
>> This may be related to the famous http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't make extensive use of templates.
>
>It can also happen because of a single very large file.  Perhaps one created by some sort of automatic code generation.  Anything like that in qtd?
>
>--bb

Yes, all modules are autogenerated. You are right, we probably should think about splitting up that big file. For example, by placing enum definitions into a separate module. It is still a less preferred solution because it requires more tweaking of the original code generator, which is already messy.

Max Samukha Wrote:

> On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter <wbaxter@gmail.com> wrote:
> 
> >On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha <samukha@voliacable.com.removethis> wrote:
> >> On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >>
> >>>Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
> >>
> >> This may be related to the famous http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't make extensive use of templates.
> >
> >It can also happen because of a single very large file.  Perhaps one created by some sort of automatic code generation.  Anything like that in qtd?
> >
> >--bb
> 
> Yes, all modules are autogenerated. You are right, we probably should think about splitting up that big file. For example, by placing enum definitions into a separate module. It is still a less preferred solution because it requires more tweaking of the original code generator, which is already messy.

The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed.

On Mon, Feb 16, 2009 at 10:32 AM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:

> The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed.

I guess we'll just have to wait for LDC then, because eliminating the "too many fixups" issue in OPTLINK is completely and utterly impossible.

--bb
;-)

Eldar Insafutdinov Wrote:

> Max Samukha Wrote:
> 
> > On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter <wbaxter@gmail.com> wrote:
> > 
> > >On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha <samukha@voliacable.com.removethis> wrote:
> > >> On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> > >>
> > >>>Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
> > >>
> > >> This may be related to the famous http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't make extensive use of templates.
> > >
> > >It can also happen because of a single very large file.  Perhaps one created by some sort of automatic code generation.  Anything like that in qtd?
> > >
> > >--bb
> > 
> > Yes, all modules are autogenerated. You are right, we probably should think about splitting up that big file. For example, by placing enum definitions into a separate module. It is still a less preferred solution because it requires more tweaking of the original code generator, which is already messy.
> 
> The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed.

Anyway, I tried to place enums outside the classes, and I got:
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced
qt/core/QFile.d(24): Error: enum FileError is forward referenced

Circular import is present.

On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
>> The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed.
>
> Anyway, I tried to place enums outside the classes, and I got:
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>
> Circular import is present.

You would do well to remove all circular imports.  They make the compiler do stupid things.

Eldar Insafutdinov wrote:
> Bill Baxter Wrote:
> 
>> On Mon, Feb 16, 2009 at 4:38 AM, Eldar Insafutdinov
>> <e.insafutdinov@gmail.com> wrote:
>>> Bill Baxter Wrote:
>>>
>>>> On Mon, Feb 16, 2009 at 4:28 AM, Eldar Insafutdinov
>>>> <e.insafutdinov@gmail.com> wrote:
>>>>> Bill Baxter Wrote:
>>>>>
>>>>>> On Mon, Feb 16, 2009 at 4:11 AM, Eldar Insafutdinov
>>>>>> <e.insafutdinov@gmail.com> wrote:
>>>>>>> Bill Baxter Wrote:
>>>>>>>
>>>>>>>> On Mon, Feb 16, 2009 at 3:06 AM, Eldar Insafutdinov
>>>>>>>> <e.insafutdinov@gmail.com> wrote:
>>>>>>>>> Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
>>>>>>>>>
>>>>>>>> Was this what you saw?
>>>>>>>> "Unexpected OPTLINK Termination at EIP=0044C37B"
>>>>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=424
>>>>>>>>
>>>>>>>> Whatever it was, chances are good it's a known bug.  So it would be
>>>>>>>> good to figure out which one it is that you're hitting exactly.
>>>>>>>>
>>>>>>>> --bb
>>>>>>> Yes, it is this issue: "Unexpected OPTLINK Termination at EIP=0041AFFD". And yes, there is 1 quite large file, 14k lines, but because of forward reference and cyclic imports problems we can't split it currently.
>>>>>> Do you compile it with inlining on?  Not positive about this, but you
>>>>>> may be able to cut down on the number of fixups it needs by not using
>>>>>> inlining.   Which file is it, anyway?
>>>>>>
>>>>>> --bb
>>>>> it is qt/gui/QPaintDevice.d if you have it. It doesn't work with both inlining and non-inlining.
>>>> Ok.  Is it some kind of automatically generated file?  I don't see it
>>>> in the qtd repo.
>>>>
>>>> --bb
>>> yes, all files are automatically generated. If you wish I can upload it(compiled binding with headers) somewhere.
>> No, that's ok.  I was just curious.  So it sounds like the best hope
>> is to try to find some way to split it up some.  There must be some
>> way it can be broken up, even if that requires turning some private
>> members public.  No?
>>
>> --bb
> 
> It's in one file because of cyclic imports bug in dmd. The bug with optlink seems to be old, any chance that it's going to be fixed?
Approximately zero chance. Optlink is entirely written in asm, and AFAIK Walter doesn't want to touch it. There's a much greater chance of the circular imports bug getting fixed -- it has to happen one day.

On Sun, 15 Feb 2009 21:27:35 -0500, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:

>Eldar Insafutdinov Wrote:
>
>> Max Samukha Wrote:
>> 
>> > On Mon, 16 Feb 2009 03:55:58 +0900, Bill Baxter <wbaxter@gmail.com> wrote:
>> > 
>> > >On Mon, Feb 16, 2009 at 3:28 AM, Max Samukha <samukha@voliacable.com.removethis> wrote:
>> > >> On Sun, 15 Feb 2009 13:06:46 -0500, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
>> > >>
>> > >>>Finally we managed to compile qtd for Windows. But at the very last step when compiling example, optlink crashed with a messagebox containing X86 registers content. This seems to be a blocker for qtd working on windows..
>> > >>
>> > >> This may be related to the famous http://d.puremagic.com/issues/show_bug.cgi?id=424, though we don't make extensive use of templates.
>> > >
>> > >It can also happen because of a single very large file.  Perhaps one created by some sort of automatic code generation.  Anything like that in qtd?
>> > >
>> > >--bb
>> > 
>> > Yes, all modules are autogenerated. You are right, we probably should think about splitting up that big file. For example, by placing enum definitions into a separate module. It is still a less preferred solution because it requires more tweaking of the original code generator, which is already messy.
>> 
>> The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed.
>
You can still alias global enums into the class scope if you want Qt.A

>Anyway, I tried to place enums outside the classes, and I got:
>qt/core/QFile.d(24): Error: enum FileError is forward referenced
>qt/core/QFile.d(24): Error: enum FileError is forward referenced
>qt/core/QFile.d(24): Error: enum FileError is forward referenced
>qt/core/QFile.d(24): Error: enum FileError is forward referenced
>qt/core/QFile.d(24): Error: enum FileError is forward referenced
>qt/core/QFile.d(24): Error: enum FileError is forward referenced
>qt/core/QFile.d(24): Error: enum FileError is forward referenced
>qt/core/QFile.d(24): Error: enum FileError is forward referenced
>
>Circular import is present.

Taking them outside the class doesn't help. I proposed to put them in a separate module. That would require renaming them to include class names. Yes, that sucks but it seems there's not much choice.

----
module QFooEnums;
enum QFooState {}

----
module QBarEnums;
enum QBarState {}

----
module QFoo;
import QBar;
import QFooEnums;
import QBarEnums;

class QFoo
{
   alias QFooState State; // if you really want to
   void bar(QBarState e) {}
}

---
module QBar;
import QFooEnums;
import QBarEnums;

QBar
{
   alias QBarState State;
   void foo(QFooState e) {}
}

Or put all the enums in a single module (which will result in a big file but more digestable for optlink)

Btw, circular imports magically erase static constructors from the menu.

Jarrett Billingsley Wrote:

> On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov <e.insafutdinov@gmail.com> wrote:
> >> The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed.
> >
> > Anyway, I tried to place enums outside the classes, and I got:
> > qt/core/QFile.d(24): Error: enum FileError is forward referenced
> > qt/core/QFile.d(24): Error: enum FileError is forward referenced
> > qt/core/QFile.d(24): Error: enum FileError is forward referenced
> > qt/core/QFile.d(24): Error: enum FileError is forward referenced
> > qt/core/QFile.d(24): Error: enum FileError is forward referenced
> > qt/core/QFile.d(24): Error: enum FileError is forward referenced
> > qt/core/QFile.d(24): Error: enum FileError is forward referenced
> > qt/core/QFile.d(24): Error: enum FileError is forward referenced
> >
> > Circular import is present.
> 
> You would do well to remove all circular imports.  They make the compiler do stupid things.

It's the way Qt is. I can't change the API.

Jarrett Billingsley wrote:
> On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov
> <e.insafutdinov@gmail.com> wrote:
>>> The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed.
>> Anyway, I tried to place enums outside the classes, and I got:
>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>> qt/core/QFile.d(24): Error: enum FileError is forward referenced
>>
>> Circular import is present.
> 
> You would do well to remove all circular imports.  They make the
> compiler do stupid things.

I really wonder why Walter doesn't just forbid circular dependencies in the language spec.