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

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

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

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

File #1, test1.d:
---
import test2;
typedef int test;

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

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

File #2, test2.d:
---
typedef int test;
---

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

File #3, test3.d:
---
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.

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

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.
> 
> File #1, test1.d:
> ---
> import test2;
> typedef int test;
> 
> void main()
> {
>     test1.test x = 5;
>     foo(x);
> }
> 
> void foo(test2.test y)
> {
> }
> ---
> 
> File #2, test2.d:
> ---
> typedef int test;
> ---
> 
> But that's not this problem.  I think this one is:
> 
> File #3, test3.d:
> ---
> 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

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.
> 
> File #1, test1.d:
> ---
> import test2;
> typedef int test;
> 
> void main()
> {
>     test1.test x = 5;
>     foo(x);
> }
> 
> void foo(test2.test y)
> {
> }
> ---
> 
> File #2, test2.d:
> ---
> typedef int test;
> ---
> 
> But that's not this problem.  I think this one is:
> 
> File #3, test3.d:
> ---
> 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

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

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

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