August 08, 2004
The following code gives this error message, but I think it should work:
v.d(3): import std conflicts with d.std at d.d(3)



[c.d]
module c;

import v;
import d;

V start;
std.stream.File file;



[d.d]
module d;

import std.c.windows.windows;



[v.d]
module v;

import std.stream;
struct V{}



[build.bat]
dmd c.d -c
pause



And, yes, it compiles fine if I change the last line of c.d to: "File file;"

Workarounds are great, but I think it should either compile as written or give a more detailed explanation in the error message.

By the way, this is from an issue discovered by clayasaurus in http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8423

I'm sure I posted an eerily similar bug report before, but I can't find it, so maybe I dreamed the whole thing.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/


August 09, 2004
In module c, add an import std.stream; and it should work.

"J C Calvarese" <jcc7@cox.net> wrote in message news:cf3s6f$2d84$1@digitaldaemon.com...
> The following code gives this error message, but I think it should work:
> v.d(3): import std conflicts with d.std at d.d(3)
>
>
>
> [c.d]
> module c;
>
> import v;
> import d;
>
> V start;
> std.stream.File file;
>
>
>
> [d.d]
> module d;
>
> import std.c.windows.windows;
>
>
>
> [v.d]
> module v;
>
> import std.stream;
> struct V{}
>
>
>
> [build.bat]
> dmd c.d -c
> pause
>
>
>
> And, yes, it compiles fine if I change the last line of c.d to: "File file;"
>
> Workarounds are great, but I think it should either compile as written or give a more detailed explanation in the error message.
>
> By the way, this is from an issue discovered by clayasaurus in http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8423
>
> I'm sure I posted an eerily similar bug report before, but I can't find it, so maybe I dreamed the whole thing.
>
> -- 
> Justin (a/k/a jcc7)
> http://jcc_7.tripod.com/d/
>


August 09, 2004
Walter wrote:
> In module c, add an import std.stream; and it should work.

Yes, that works. Thanks.

There are also two other ways to make it work. Change "std.stream.File" to either "File" or "c.std.stream.File" (of course if there's another File symbol hanging around, the short version isn't an option without using an alias).

Seems like 3 work-arounds to me, but I'm getting the impression this is how you intend for it to work. This wouldn't be any problem when all of files were 5 lines long and the importing only went 3 levels deep. But this example was culled from a much, much larger project (in fact two large projects were involved).

It'd help a lot if the error message would at least make a reference to the "std.stream.File file" line of c.d. The current message refers to the lines in v.d and d.d but in my experience, the line in c.d is the hardest to find. It took a lot of commenting out before I zeroed in on the std.stream.File reference. Seeing the v.d and d.d lines have only reinforced my confusion at the error.

Allow, the message could have mentioned that std.stream in particular was causing the problem, but I don't think that's as important.

Anyways, I hope you consider making a change regarding this issue (at least improve the error message) because I'm confident it'll become more prevalent as large projects become more common.

Thanks for your consideration.

> "J C Calvarese" <jcc7@cox.net> wrote in message
> news:cf3s6f$2d84$1@digitaldaemon.com...
> 
>>The following code gives this error message, but I think it should work:
>>v.d(3): import std conflicts with d.std at d.d(3)
>>
>>
>>
>>[c.d]
>>module c;
>>
>>import v;
>>import d;
>>
>>V start;
>>std.stream.File file;
>>
>>
>>
>>[d.d]
>>module d;
>>
>>import std.c.windows.windows;
>>
>>
>>
>>[v.d]
>>module v;
>>
>>import std.stream;
>>struct V{}
>>
>>
>>
>>[build.bat]
>>dmd c.d -c
>>pause
>>
>>
>>
>>And, yes, it compiles fine if I change the last line of c.d to:
>>"File file;"
>>
>>Workarounds are great, but I think it should either compile as written
>>or give a more detailed explanation in the error message.
>>
>>By the way, this is from an issue discovered by clayasaurus in
>>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8423
>>
>>I'm sure I posted an eerily similar bug report before, but I can't find
>>it, so maybe I dreamed the whole thing.
>>
>>-- 
>>Justin (a/k/a jcc7)
>>http://jcc_7.tripod.com/d/

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 09, 2004
On Mon, 09 Aug 2004 10:16:36 -0700, Walter wrote:

> In module c, add an import std.stream; and it should work.

So, if you know this can you teach the compiler to tell it to us? That would make possible to work on large applications.

beside the import on the v.d isn't private shouldn't it work as it is?

JCC, does it compile if all the modules are passed to the compiler at once?

> 
> "J C Calvarese" <jcc7@cox.net> wrote in message news:cf3s6f$2d84$1@digitaldaemon.com...

>> Workarounds are great, but I think it should either compile as written or give a more detailed explanation in the error message.

Ant

August 10, 2004
Walter,

I just distilled the same type of bug (attached)

I know it is a missing import, but all of my imports *ARE* private, so the compiler should just complain that it does not know anything about std.

Scott Sanders

J C Calvarese wrote:
> The following code gives this error message, but I think it should work:
> v.d(3): import std conflicts with d.std at d.d(3)


August 10, 2004
J C Calvarese wrote:
> Walter wrote:
> 
>> In module c, add an import std.stream; and it should work.
> 
> 
> Yes, that works. Thanks.
> 
> There are also two other ways to make it work. Change "std.stream.File" to either "File" or "c.std.stream.File" (of course if there's another 

Oops, "c.std.stream.File" doesn't work. I meant to write "v.std.stream.File" which does work.

But "d.std.stream.File" works, too? That doesn't make any sense to me. How does "import std.c.windows.windows;" tell the compiler any thing about std.stream.File?

(Argggh! Just when I thought this was making some sense.)

> File symbol hanging around, the short version isn't an option without using an alias).
> 
> Seems like 3 work-arounds to me, but I'm getting the impression this is how you intend for it to work. This wouldn't be any problem when all of files were 5 lines long and the importing only went 3 levels deep. But this example was culled from a much, much larger project (in fact two large projects were involved).
> 
> It'd help a lot if the error message would at least make a reference to the "std.stream.File file" line of c.d. The current message refers to the lines in v.d and d.d but in my experience, the line in c.d is the hardest to find. It took a lot of commenting out before I zeroed in on the std.stream.File reference. Seeing the v.d and d.d lines have only reinforced my confusion at the error.
> 
> Allow, the message could have mentioned that std.stream in particular was causing the problem, but I don't think that's as important.
> 
> Anyways, I hope you consider making a change regarding this issue (at least improve the error message) because I'm confident it'll become more prevalent as large projects become more common.
> 
> Thanks for your consideration.
> 
>> "J C Calvarese" <jcc7@cox.net> wrote in message
>> news:cf3s6f$2d84$1@digitaldaemon.com...
>>
>>> The following code gives this error message, but I think it should work:
>>> v.d(3): import std conflicts with d.std at d.d(3)
>>>
>>>
>>>
>>> [c.d]
>>> module c;
>>>
>>> import v;
>>> import d;
>>>
>>> V start;
>>> std.stream.File file;
>>>
>>>
>>>
>>> [d.d]
>>> module d;
>>>
>>> import std.c.windows.windows;
>>>
>>>
>>>
>>> [v.d]
>>> module v;
>>>
>>> import std.stream;
>>> struct V{}
>>>
>>>
>>>
>>> [build.bat]
>>> dmd c.d -c
>>> pause
>>>
>>>
>>>
>>> And, yes, it compiles fine if I change the last line of c.d to:
>>> "File file;"
>>>
>>> Workarounds are great, but I think it should either compile as written
>>> or give a more detailed explanation in the error message.
>>>
>>> By the way, this is from an issue discovered by clayasaurus in
>>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8423
>>>
>>> I'm sure I posted an eerily similar bug report before, but I can't find
>>> it, so maybe I dreamed the whole thing.
>>>
>>> -- 
>>> Justin (a/k/a jcc7)
>>> http://jcc_7.tripod.com/d/
> 
> 


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 10, 2004
Ant wrote:
> On Mon, 09 Aug 2004 10:16:36 -0700, Walter wrote:
> 
> 
>>In module c, add an import std.stream; and it should work.
> 
> 
> So, if you know this can you teach the compiler to tell it to us?
> That would make possible to work on large applications.
> 
> beside the import on the v.d isn't private shouldn't it work as it is?
> 
> JCC, does it compile if all the modules are passed to the compiler at once?

The error still appears if they're compiled together. I've been thinking about the situation and I've beginning to convince myself that the compiler's behavior makes some sense. (I still think the error message needs more info.) At least it does work when "std.stream.File" is re-written as "v.std.stream.File".

(But there still seems to be something weird going on because "d.std.stream.File" compiles without error, too.)

If you've run into an issue like this in DUI, now would be a good time to mention it. This kind of problem is bound to be more common and troublesome in larger projects.

>>"J C Calvarese" <jcc7@cox.net> wrote in message
>>news:cf3s6f$2d84$1@digitaldaemon.com...
> 
> 
>>>Workarounds are great, but I think it should either compile as written
>>>or give a more detailed explanation in the error message.
> 
> 
> Ant

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
August 10, 2004
"J C Calvarese" <jcc7@cox.net> wrote in message news:cf9689$14ql$1@digitaldaemon.com...
> to mention it. This kind of problem is bound to be more common and troublesome in larger projects.

Yes, it most certainly has been a troublesome for my (large-ish) project. I resolved it in the following fashion: avoid using Phobos where at all possible.

Inner imports resolved some problems, but ultimately it became a case of 'wrapping' the few remaining Phobos routines just to exorcise std imports from the general codebase. Many other projects will undoubtedly (IMO) take a similar approach ~ in my case, it was simply too much effort to resolve by any other available means.


August 10, 2004
On Mon, 09 Aug 2004 19:52:24 -0500, J C Calvarese wrote:

> If you've run into an issue like this in DUI, now would be a good time to mention it. This kind of problem is bound to be more common and troublesome in larger projects.

I reported this the best I could about 6 times on the last year.
Walter said it's a low priority, I guess he is right.
only fools will start large projects with a beta version
of something (note that my projects aren't complex, just large).
As I see it dmd is not ready for large projects. The problem
is that you might miss something that the compiler will ignore
and sudenlly the error surfaces and it's impossible to find.
this is one of the reasons I started the lib dool:
dmd deals with objects in a more restricted way. The look up
rules was another and my preference for OO was the 3rd reason.

Ant

August 10, 2004
On Mon, 09 Aug 2004 18:45:51 -0700, antiAlias wrote:

> I resolved it in the following fashion: avoid using Phobos where at all possible.

that was my solution! I called it dool.

> 
> Inner imports resolved some problems,

in the class body? I still use that I see no problems with it,
in fact it make sense as we are using the imported classes inside
the body of the class, not outside (at least I have one class/file)

> but ultimately it became a case of
> 'wrapping' the few remaining Phobos routines just to exorcise std
> imports from the general codebase.

This is ridiculous, I bet it's a simple fix to dmd to be more carefull using the imported declarations... well, Walter knows better.

Ant

« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home