Digital Mars - digitalmars.D.announce

Max Samukha <samukha voliacable.com.removethis> writes:

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.

Feb 15 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

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.

Feb 15 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

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.

Feb 15 2009

Max Samukha <samukha voliacable.com.removethis> writes:

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.





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.

Feb 16 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

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.

Feb 16 2009

grauzone <none example.net> writes:

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.


 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.

Feb 16 2009

Bill Baxter <wbaxter gmail.com> writes:

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

Feb 15 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

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.

Feb 15 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

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.

Feb 15 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

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

Feb 15 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

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




 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?

Feb 15 2009

Don <nospam nospam.com> writes:

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..


 "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




 may be able to cut down on the number of fixups it needs by not using
 inlining.   Which file is it, anyway?

 --bb




 in the qtd repo.

 --bb




 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?


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.

Feb 16 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

Don Wrote:

 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..


 "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




 may be able to cut down on the number of fixups it needs by not using
 inlining.   Which file is it, anyway?

 --bb




 in the qtd repo.

 --bb




 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?


 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.


Ok, so I splitted all big files, circular imports now don't cause troubles. But
optlink still crashes. Something else I can try?

Feb 16 2009

Bill Baxter <wbaxter gmail.com> writes:

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

Feb 15 2009

Bill Baxter <wbaxter gmail.com> writes:

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

Feb 15 2009

Bill Baxter <wbaxter gmail.com> writes:

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

Feb 15 2009

Bill Baxter <wbaxter gmail.com> writes:

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




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

Feb 15 2009

Bill Baxter <wbaxter gmail.com> writes:

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/=


he 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.co=
re.Qt module you can't access it like Qt.A - which means that we have to ke=
ep 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
;-)

Feb 15 2009

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

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=




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.c=
ore.Qt module you can't access it like Qt.A - which means that we have to k=
eep 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.

Feb 15 2009

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Feb 16, 2009 at 7:10 AM, grauzone <none example.net> wrote:
 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.


Because that's redefining the problem rather than solving it?

Circular dependencies are not always a sign of bad design.  Shoving
everything into one module sure is.

Feb 16 2009

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Feb 16, 2009 at 8:26 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Eldar Insafutdinov 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..


 What you can do is try to obj2asm and dumpobj -p the .obj files, to see if
 those files are well-formed or not.


I don't know if you realize just how unbelievably unhelpful that
advice is for the typical user.

Feb 16 2009

Walter Bright <newshound1 digitalmars.com> writes:

Jarrett Billingsley wrote:
 On Mon, Feb 16, 2009 at 8:26 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Eldar Insafutdinov 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..


 those files are well-formed or not.


 I don't know if you realize just how unbelievably unhelpful that
 advice is for the typical user.


You aren't the typical user <g>. If the obj file is not well-formed, 
it's a compiler bug, and hence presumably much easier for me to fix.

Feb 16 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

Walter Bright Wrote:

 Eldar Insafutdinov 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..


 What you can do is try to obj2asm and dumpobj -p the .obj files, to see 
 if those files are well-formed or not.


I have never dealed with asm before and besides there are more than 200 files
in the project, that would be crucial to check them all.

Feb 16 2009

digitalmars.D.announce - Re: QtD 0.1 is out!