Jump to page: 1 2
Thread overview
Import Conflicts
Dec 28, 2005
Charles
Dec 28, 2005
Chris Miller
Dec 28, 2005
Ant
Dec 28, 2005
clayasaurus
Dec 28, 2005
Charles
Dec 29, 2005
J C Calvarese
Dec 29, 2005
Charles
Dec 29, 2005
Derek Parnell
Dec 28, 2005
Manfred Nowak
Dec 28, 2005
Derek Parnell
Dec 29, 2005
Derek Parnell
Dec 29, 2005
jicman
December 28, 2005
Any sizable project is going to eventually run into the dreaded import conflicts.  Ive searched the old posts and come up with some possible solutions, but couldnt find anything from Walter about them .

If these conflicts are unavoidable, we need in the very least to make the error message something _useful_.  Ideally, another tool could be used to solve the problem , but I still dont even know what the problem is ( Im sure ive been told and forgotten ).

The error message Im getting now is :

root.d(4): import dparser.root.std conflicts with dparser.mod.std at
mod.d(19)

which is absouletly worthless.  std is a package, and if I move those lines around in root.d or mod.d , I get 100 other import conflicts in a seemingly endless circle of time wasting.

Walter --

Can we get a better error message ?  What do these actually _mean_ ?  How can i solve this without randomly moving around import statements ?

Charlie


December 28, 2005
On Wed, 28 Dec 2005 12:33:52 -0500, Charles <noone@nowhere.com> wrote:

> The error message Im getting now is :
>
> root.d(4): import dparser.root.std conflicts with dparser.mod.std at
> mod.d(19)
>
> which is absouletly worthless.  std is a package, and if I move those lines
> around in root.d or mod.d , I get 100 other import conflicts in a seemingly
> endless circle of time wasting.
>

Is it from a missing std import? e.g.

filea.d:
========
import std.string;

fileb.d:
========
import std.stdio;

mainapp.d:
==========
import filea, fileb;
int main() {
std.stdio.writefln("hello"); // tries to use std from filea and fileb since there's no std in mainapp.
return 0; }

I've had a similar error message before and this was the reason.
December 28, 2005
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1307

A good thread on these types of problems.

Charles wrote:
> Any sizable project is going to eventually run into the dreaded import
> conflicts.  Ive searched the old posts and come up with some possible
> solutions, but couldnt find anything from Walter about them .
> 
> If these conflicts are unavoidable, we need in the very least to make the
> error message something _useful_.  Ideally, another tool could be used to
> solve the problem , but I still dont even know what the problem is ( Im sure
> ive been told and forgotten ).
> 
> The error message Im getting now is :
> 
> root.d(4): import dparser.root.std conflicts with dparser.mod.std at
> mod.d(19)
> 
> which is absouletly worthless.  std is a package, and if I move those lines
> around in root.d or mod.d , I get 100 other import conflicts in a seemingly
> endless circle of time wasting.
> 
> Walter --
> 
> Can we get a better error message ?  What do these actually _mean_ ?  How
> can i solve this without randomly moving around import statements ?
> 
> Charlie
> 
> 
December 28, 2005
In article <op.s2h487rvpo9bzi@moe>, Chris Miller says...
>
>On Wed, 28 Dec 2005 12:33:52 -0500, Charles <noone@nowhere.com> wrote:
>
>> The error message Im getting now is :
>>
>> root.d(4): import dparser.root.std conflicts with dparser.mod.std at
>> mod.d(19)
>>
>> which is absouletly worthless.  std is a package, and if I move those
>> lines
>> around in root.d or mod.d , I get 100 other import conflicts in a
>> seemingly
>> endless circle of time wasting.
>>
>
>Is it from a missing std import? e.g.

Of course you know that's not the point of the original post.
the point(s) are:
- The messages from DMD are completly useless
- (and possibly) DMD should do a better job with import conflicts

It doesn't look like Walter uses D,
he will never figure out how critical this is...
Maybe someone can explain to Walter how critical this is, I couldn't.

Ant


December 28, 2005
Charles wrote:

[...]
> root.d(4): import dparser.root.std conflicts with
> dparser.mod.std at mod.d(19)
[...]

Without knowing what you actually are coding I assume, that you are using a member from one of the modules in the package std _and_ you have not imported this package in the module you use that member.

Confusing is the fact that the error message shows a wrong detection point "root.d(4):". Forget this part of the message.

One solution is to import std in every module where you use such a member.

I do not see any reason to not follow this solution.

If I am blind according to such a reason, then there is a severe problem because in case of an import heterarchy there might be multiple detection points, because the conflict is imported into several modules. I believe that the cause of such a conflict is not solvable algorithmically. If you then have a feasable algorithmically solution I am sure, that Walter will implement it. But as you say yourself, you cannot find a solution even in your fixed case without moving the imports randomly around.

In case of an import hierarchy its easier: find the lowest common anchestor of the conflicting modules an import the module there.

-manfred
December 28, 2005
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1307

Ahh, that is a good thread.

Thanks all for the responses ( problem solved ) .  Im going to post as a bug in .bugs , try to get walter to change the error message.

Charles


"clayasaurus" <clayasaurus@gmail.com> wrote in message news:doujln$2ur2$1@digitaldaemon.com...
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1307
>
> A good thread on these types of problems.
>
> Charles wrote:
> > Any sizable project is going to eventually run into the dreaded import conflicts.  Ive searched the old posts and come up with some possible solutions, but couldnt find anything from Walter about them .
> >
> > If these conflicts are unavoidable, we need in the very least to make
the
> > error message something _useful_.  Ideally, another tool could be used
to
> > solve the problem , but I still dont even know what the problem is ( Im
sure
> > ive been told and forgotten ).
> >
> > The error message Im getting now is :
> >
> > root.d(4): import dparser.root.std conflicts with dparser.mod.std at
> > mod.d(19)
> >
> > which is absouletly worthless.  std is a package, and if I move those
lines
> > around in root.d or mod.d , I get 100 other import conflicts in a
seemingly
> > endless circle of time wasting.
> >
> > Walter --
> >
> > Can we get a better error message ?  What do these actually _mean_ ?
How
> > can i solve this without randomly moving around import statements ?
> >
> > Charlie
> >
> >


December 28, 2005
On Wed, 28 Dec 2005 22:18:45 +0000 (UTC), Manfred Nowak wrote:


> One solution is to import std in every module where you use such a member.

My translation of Manfred's suggestion is that whenever one qualifies a member with a module reference, one must also explicitly import that module into the source file that contains the qualified reference.

That is to say if one codes

       std.stream.File ...

then one also needs to code

       import std.stream

in the same source file.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"A learning experience is one of those things that says,
 'You know that thing you just did? Don't do that.'" - D.N. Adams
29/12/2005 10:52:49 AM
December 29, 2005
P.S.  I agree that the current DMD message is straight out of a bad Monty Python skit. It looks full of content but is ultimately just silly.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"A learning experience is one of those things that says,
 'You know that thing you just did? Don't do that.'" - D.N. Adams
29/12/2005 10:58:19 AM
December 29, 2005
In article <dov4p6$12sc$1@digitaldaemon.com>, Charles says...
>
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1307
>
>Ahh, that is a good thread.
>
>Thanks all for the responses ( problem solved ) .  Im going to post as a bug in .bugs , try to get walter to change the error message.
>
>Charles

Good luck.

I think a posted a "bug report" on this a while back. It's probably not that Walter disagrees that this should be improved, but that he doesn't think it's a high priority. And I don't know if it should really be a high priority. I know I've wasted a lot of time trying to decipher these particular brand of messages, but once someone showed me the trick on how to decipher them it got a lot easier.

jcc7
December 29, 2005
> I think a posted a "bug report" on this a while back. It's probably not
that
> Walter disagrees that this should be improved, but that he doesn't think
it's a
> high priority. And I don't know if it should really be a high priority. I
know
> I've wasted a lot of time trying to decipher these particular brand of
messages,
> but once someone showed me the trick on how to decipher them it got a lot easier.

Yea, I over-reacted a little, once its pointed out it helps.  Still this error message actually makes the problem _worse_ in that its pointing out the wrong file(s).

Imagine how awesome it would be if BUILD could detect these import conflicts <hint,hint>.  Yea ... and some lint like capabilities too!

Charlie.


"J C Calvarese" <technocrat7@gmail.com> wrote in message news:dovb08$1gi1$1@digitaldaemon.com...
> In article <dov4p6$12sc$1@digitaldaemon.com>, Charles says...
> >
> >> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1307
> >
> >Ahh, that is a good thread.
> >
> >Thanks all for the responses ( problem solved ) .  Im going to post as a
bug
> >in .bugs , try to get walter to change the error message.
> >
> >Charles
>
> Good luck.
>
> I think a posted a "bug report" on this a while back. It's probably not
that
> Walter disagrees that this should be improved, but that he doesn't think
it's a
> high priority. And I don't know if it should really be a high priority. I
know
> I've wasted a lot of time trying to decipher these particular brand of
messages,
> but once someone showed me the trick on how to decipher them it got a lot easier.
>
> jcc7


« First   ‹ Prev
1 2