www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - compiler message cannot convert GType to GType

reply Ant <duitoolkit yahoo.ca> writes:
gobject/ObjectG.d(389): cannot implicitly convert expression (objectType) of
type GType to 
GType

All unhelpful compiler message should be marked as high priority bugs.
this one is just an example

Ant
Mar 12 2006
next sibling parent reply Ant <duitoolkit yahoo.ca> writes:
Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression 
 (objectType) of type GType to GType
 
 All unhelpful compiler message should be marked as high priority bugs.
 this one is just an example
 
 Ant


Walter, I didn't realized it until now but, as 2 years ago,
I'm spending as much time fighting dmd as I am actually using it... :(

hey, but I'm still using it, I didn't go back to c++ ;)

Ant
Mar 12 2006
parent reply Brad Roberts <braddr puremagic.com> writes:
On Sun, 12 Mar 2006, Ant wrote:


 Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression (objectType) of
 type GType to GType
 
 All unhelpful compiler message should be marked as high priority bugs.
 this one is just an example
 
 Ant


 
 Walter, I didn't realized it until now but, as 2 years ago,
 I'm spending as much time fighting dmd as I am actually using it... :(
 
 hey, but I'm still using it, I didn't go back to c++ ;)
 
 Ant


Produce a test case that doesn't involve having to download packages and 
examine hundreds or thousands of lines of code, and chances are the 
problem _will_ be fixed.  In this case, you've neither given any 
indication of what the code actually is, where/how to get it, or how to 
reproduce the problem.  Take a look at existing bugs that are getting 
fixed for examples of what I mean.  The basic process:

  1) Make a copy of the file that's producing the error. 
  2) Remove as much code as possible while still producing the error.
  3) Remove imports (potentially copying code from the import into the 
     file you're working on.
  4) Rinse, repeat.

You should strive to get a file that's at max, 10's of lines of code and 
requires no imported modules.  If you don't, then someone else will have 
to.  Waiting for Walter to do it for you pretty much means it isn't going 
to happen.  There's pleanty of already reduced cases that are going to get 
looked at first simply because they're far easier to make progress on.

Make sense?

Later,
Brad
Mar 12 2006
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Actually, I think I saw this once... or twice.  It was a dumb mistake of 
mine, though.  It requires multiple files.


---
import test2;
typedef int test;

void main()
{
	test1.test x = 5;
	foo(x);
}

void foo(test2.test y)
{
}
---


---
typedef int test;
---

But that's not this problem.  I think this one is:


---
import test2;
typedef int test;

void main()
{
	test3.test x = 5;
	test2.test y = x;
}
---

Which produces the same error message.  In actuality, the compiler is 
100% correct - the two cannot be implicitly cast.  However, the error 
message is VERY ambiguous.

As you can tell, the root of the problem is that the error message 
doesn't use fully-qualified type names.  Personally, I like this better, 
but maybe at least for these sort of cases, they need to be fully-qualified.

Ant, do you think this is the issue you are running into?

Thanks,
-[Unknown]



 You should strive to get a file that's at max, 10's of lines of code and 
 requires no imported modules.  If you don't, then someone else will have 
 to.  Waiting for Walter to do it for you pretty much means it isn't going 
 to happen.  There's pleanty of already reduced cases that are going to get 
 looked at first simply because they're far easier to make progress on.
Mar 12 2006
next sibling parent reply Ant <duitoolkit yahoo.ca> writes:
Unknown W. Brackets wrote:

 Actually, I think I saw this once... or twice.  It was a dumb mistake of 
 mine, though.  It requires multiple files.
 

 ---
 import test2;
 typedef int test;
 
 void main()
 {
     test1.test x = 5;
     foo(x);
 }
 
 void foo(test2.test y)
 {
 }
 ---
 

 ---
 typedef int test;
 ---
 
 But that's not this problem.  I think this one is:
 

 ---
 import test2;
 typedef int test;
 
 void main()
 {
     test3.test x = 5;
     test2.test y = x;
 }
 ---
 
 Which produces the same error message.  In actuality, the compiler is 
 100% correct - the two cannot be implicitly cast.  However, the error 
 message is VERY ambiguous.
 
 As you can tell, the root of the problem is that the error message 
 doesn't use fully-qualified type names.  Personally, I like this better, 
 but maybe at least for these sort of cases, they need to be 
 fully-qualified.
 
 Ant, do you think this is the issue you are running into?
 


I already fixed it, thank you!

(the same enum was defined in different files.)

One of the problems is that I'm breaking my own rule of never, ever
define anything outside a class.
D is unusable if you don't encapsulate every thing in classes.
(of course every thing I say is my opinion).

BTW I've being frequenting the IRC D channel lately and found
that others have faced some of the problems I am complaining for 2 years
but they just keep silent.

I found D excellent but DMD still very immature...
barely usable - but that's why it's still beta, of course.

Ant
Mar 12 2006
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
When I first learned programming, the languages I used didn't even have 
proper structs, let alone classes.  I've never had much trouble avoiding 
multiple declarations - in my opinion, for smaller projects it's easier 
to centralize any shared declarations which are outside classes.

In other words, having an "enums.d" or "types.d" or something like that. 
  If you're not going to tie it to a class or at least module, that is. 
  Normally, in C, this is done with one central .h file.

I don't personally think DMD is that immature as a compiler.  It may not 
have the best error messages, but if you've ever tried to debug 
JavaScript in Internet Explorer, you'd know the meaning of useless error 
messages.  DMD could never even compare.

And I'm told Ruby has blindingly horrid error messages, although this 
may have improved.

-[Unknown]



 I already fixed it, thank you!
 
 (the same enum was defined in different files.)
 
 One of the problems is that I'm breaking my own rule of never, ever
 define anything outside a class.
 D is unusable if you don't encapsulate every thing in classes.
 (of course every thing I say is my opinion).
 
 BTW I've being frequenting the IRC D channel lately and found
 that others have faced some of the problems I am complaining for 2 years
 but they just keep silent.
 
 I found D excellent but DMD still very immature...
 barely usable - but that's why it's still beta, of course.
 
 Ant
Mar 12 2006
prev sibling parent Ant <duitoolkit yahoo.ca> writes:
Unknown W. Brackets wrote:

 Actually, I think I saw this once... or twice.  It was a dumb mistake of 
 mine, though.  It requires multiple files.
 

 ---
 import test2;
 typedef int test;
 
 void main()
 {
     test1.test x = 5;
     foo(x);
 }
 
 void foo(test2.test y)
 {
 }
 ---
 

 ---
 typedef int test;
 ---
 
 But that's not this problem.  I think this one is:
 

 ---
 import test2;
 typedef int test;
 
 void main()
 {
     test3.test x = 5;
     test2.test y = x;
 }
 ---
 
 Which produces the same error message.  In actuality, the compiler is 
 100% correct - the two cannot be implicitly cast.  However, the error 
 message is VERY ambiguous.
 
 As you can tell, the root of the problem is that the error message 
 doesn't use fully-qualified type names.  Personally, I like this better, 
 but maybe at least for these sort of cases, they need to be 
 fully-qualified.
 
 Ant, do you think this is the issue you are running into?
 


I already fixed it, thank you! :)

(the same enum was defined in different files.)

One of the problems is that I'm breaking my own rule of never, ever
define anything outside a class.
D is unusable if you don't encapsulate every thing in classes.
(of course every thing I say is my opinion).

BTW I've being frequenting the IRC D channel lately and found
that others have faced some of the problems I am complaining for 2 years
but they just keep silent.

I found D excellent but DMD still very immature...
barely usable - but that's why it's still beta, of course.

Ant
Mar 12 2006
prev sibling parent reply Ant <duitoolkit yahoo.ca> writes:
Brad Roberts wrote:

 On Sun, 12 Mar 2006, Ant wrote:
 

 Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression (objectType) of
 type GType to GType

 All unhelpful compiler message should be marked as high priority bugs.
 this one is just an example

 Ant


 Walter, I didn't realized it until now but, as 2 years ago,
 I'm spending as much time fighting dmd as I am actually using it... :(

 hey, but I'm still using it, I didn't go back to c++ ;)

 Ant


 
 Produce a test case that doesn't involve having to download packages and 
 examine hundreds or thousands of lines of code, and chances are the 
 problem _will_ be fixed.  In this case, you've neither given any 
 indication of what the code actually is, where/how to get it, or how to 
 reproduce the problem.


that was not my intention, I just want to say that Walter should change
the priority he is given to dumb compiler message.

(You could question my choice of posting on the bugs group.)

Ant
Mar 12 2006
parent Brad Roberts <braddr puremagic.com> writes:
On Sun, 12 Mar 2006, Ant wrote:


 Brad Roberts wrote:

 On Sun, 12 Mar 2006, Ant wrote:
 

 Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression
 (objectType) of
 type GType to GType
 
 All unhelpful compiler message should be marked as high priority bugs.
 this one is just an example
 
 Ant


 Walter, I didn't realized it until now but, as 2 years ago,
 I'm spending as much time fighting dmd as I am actually using it... :(
 
 hey, but I'm still using it, I didn't go back to c++ ;)
 
 Ant


 
 Produce a test case that doesn't involve having to download packages and
 examine hundreds or thousands of lines of code, and chances are the problem
 _will_ be fixed.  In this case, you've neither given any indication of what
 the code actually is, where/how to get it, or how to reproduce the problem.


 
 that was not my intention, I just want to say that Walter should change
 the priority he is given to dumb compiler message.
 
 (You could question my choice of posting on the bugs group.)
 
 Ant


I don't question posting in .bugs at all.  It's entirely appropriate as 
bad error messages are a big part of the usability of the compiler.  Maybe 
not as blocking as a crash, but still worth fixing.

My point is that like any problem report, to be useful it needs to be 
trivially reproducable.  That holds for warnings, errors, crashes, 
whatever.  Just showing the line of output by itself is insufficient in 
most cases.  So, to facilitate getting these issues fixed, tiny test cases 
would be invaluable.

Later,
Brad
Mar 12 2006
prev sibling parent reply Ant <duitoolkit yahoo.ca> writes:
Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression 
 (objectType) of type GType to GType
 
 All unhelpful compiler message should be marked as high priority bugs.
 this one is just an example
 
 Ant


gtk/CellLayout.d(52): import gtk.CellLayout.std conflicts with 
gtk.CellRenderer.std at gtk/CellRenderer.d(59)

Please Walter...
What did the compiler found?

:(
:(
:(
:(

I'm not complaining about this specific case.
I'm just asking that the compiler messages problem  be attributed a 
higher priority.

I promise this is the last post I made on this.

I'm going to grep around just to find something the compiler already 
knows :(

Ant
Mar 19 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 19 Mar 2006 21:30:10 -0500, Ant <duitoolkit yahoo.ca> wrote:

 Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression  
 (objectType) of type GType to GType
  All unhelpful compiler message should be marked as high priority bugs.
 this one is just an example
  Ant


 gtk/CellLayout.d(52): import gtk.CellLayout.std conflicts with  
 gtk.CellRenderer.std at gtk/CellRenderer.d(59)


Are you still using import within class bodies?

Regan
Mar 19 2006
parent reply Ant <duitoolkit yahoo.ca> writes:
Regan Heath wrote:

 On Sun, 19 Mar 2006 21:30:10 -0500, Ant <duitoolkit yahoo.ca> wrote:

 Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression 
 (objectType) of type GType to GType
  All unhelpful compiler message should be marked as high priority bugs.
 this one is just an example
  Ant


 gtk/CellLayout.d(52): import gtk.CellLayout.std conflicts with 
 gtk.CellRenderer.std at gtk/CellRenderer.d(59)


 
 Are you still using import within class bodies?
 
 Regan


I wish I could, but no.

Ant
Mar 19 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 19 Mar 2006 23:47:12 -0500, Ant <duitoolkit yahoo.ca> wrote:

 Regan Heath wrote:

 On Sun, 19 Mar 2006 21:30:10 -0500, Ant <duitoolkit yahoo.ca> wrote:

 Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression  
 (objectType) of type GType to GType
  All unhelpful compiler message should be marked as high priority  
 bugs.
 this one is just an example
  Ant


 gtk/CellLayout.d(52): import gtk.CellLayout.std conflicts with  
 gtk.CellRenderer.std at gtk/CellRenderer.d(59)


  Are you still using import within class bodies?
  Regan


 I wish I could, but no.


You're not using them and you're still getting these error messages? Odd.

Regan
Mar 19 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 20 Mar 2006 16:52:03 +1200, Regan Heath <regan netwin.co.nz> wrote:

 On Sun, 19 Mar 2006 23:47:12 -0500, Ant <duitoolkit yahoo.ca> wrote:

 Regan Heath wrote:

 On Sun, 19 Mar 2006 21:30:10 -0500, Ant <duitoolkit yahoo.ca> wrote:

 Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression  
 (objectType) of type GType to GType
  All unhelpful compiler message should be marked as high priority  
 bugs.
 this one is just an example
  Ant


 gtk/CellLayout.d(52): import gtk.CellLayout.std conflicts with  
 gtk.CellRenderer.std at gtk/CellRenderer.d(59)


  Are you still using import within class bodies?
  Regan


 I wish I could, but no.


 You're not using them and you're still getting these error messages? Odd.


Where is the latest source, in SVN? I have an idea for tracking it down.

Regan
Mar 19 2006
parent reply Ant <duitoolkit yahoo.ca> writes:
Regan Heath wrote:

 On Mon, 20 Mar 2006 16:52:03 +1200, Regan Heath <regan netwin.co.nz> wrote:

 On Sun, 19 Mar 2006 23:47:12 -0500, Ant <duitoolkit yahoo.ca> wrote:

 Regan Heath wrote:

 On Sun, 19 Mar 2006 21:30:10 -0500, Ant <duitoolkit yahoo.ca> wrote:

 Ant wrote:

 gobject/ObjectG.d(389): cannot implicitly convert expression 
 (objectType) of type GType to GType
  All unhelpful compiler message should be marked as high priority 
 bugs.
 this one is just an example
  Ant


 gtk/CellLayout.d(52): import gtk.CellLayout.std conflicts with 
 gtk.CellRenderer.std at gtk/CellRenderer.d(59)


  Are you still using import within class bodies?
  Regan


 I wish I could, but no.


 You're not using them and you're still getting these error messages? Odd.


 
 Where is the latest source, in SVN? I have an idea for tracking it down.
 
 Regan


I'm sick of this.
I'll try a different approach.

Ant
Mar 19 2006
parent Ant <duitoolkit yahoo.ca> writes:
Ant wrote:

 gtk/CellLayout.d(52): import gtk.CellLayout.std conflicts with 
 gtk.CellRenderer.std at gtk/CellRenderer.d(59)










 
 I'm sick of this.
 I'll try a different approach.
 


Well, it worked.

I wrapped all std.string.x I'm using in a class.
dmd found all the missing imports and it was just a questions of typing 
them in.

This was possible because my application (Duit, the next DUI lib) is 
very simple (but not small).

Ant
Mar 19 2006