www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Import Conflicts

reply "Charles" <noone nowhere.com> writes:
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
Dec 28 2005
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
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.
Dec 28 2005
parent Ant <Ant_member pathlink.com> writes:
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
Dec 28 2005
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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
Dec 28 2005
parent reply "Charles" <noone nowhere.com> writes:
 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
Dec 28 2005
parent reply J C Calvarese <technocrat7 gmail.com> writes:
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
Dec 28 2005
parent reply "Charles" <noone nowhere.com> writes:
 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
Dec 28 2005
parent Derek Parnell <derek psych.ward> writes:
On Wed, 28 Dec 2005 18:43:54 -0800, Charles wrote:



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


Yeah, yeah...I hear ya.

I'd already thought about this and it presents at least two problems. The
first is that I'd have to manipulate the source file to insert an 'import'
statement and that's no simple thing to do due to D's module naming
constraints, and the second is that programs that would compile under Build
would fail using other methods and that isn't nice. 

A compromise might be to create a 'lint' that picks up these issues so we
can manually update our source files.

-- 
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 1:23:22 PM
Dec 28 2005
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Dec 28 2005
parent reply Derek Parnell <derek psych.ward> writes:
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
Dec 28 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
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
Dec 28 2005
prev sibling parent jicman <jicman_member pathlink.com> writes:
Derek Parnell says...

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.


You know what would be nice, allow a python like import.  In python one could do
something like this,

from win32com.client.dynamic import Dispatch

so with the new D import version, one could do,

from std.stream import File

or better yet,

import std.stream.File alias ssFile;

which would import the File function from std.stream and would assign the alias
ssFile to that function.  Is this possible?
Dec 28 2005