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