digitalmars.D.learn - Import Conflicts
- "Charles" <noone nowhere.com> Dec 28 2005
- "Chris Miller" <chris dprogramming.com> Dec 28 2005
- Ant <Ant_member pathlink.com> Dec 28 2005
- clayasaurus <clayasaurus gmail.com> Dec 28 2005
- "Charles" <noone nowhere.com> Dec 28 2005
- J C Calvarese <technocrat7 gmail.com> Dec 28 2005
- "Charles" <noone nowhere.com> Dec 28 2005
- Derek Parnell <derek psych.ward> Dec 28 2005
- Manfred Nowak <svv1999 hotmail.com> Dec 28 2005
- Derek Parnell <derek psych.ward> Dec 28 2005
- Derek Parnell <derek psych.ward> Dec 28 2005
- jicman <jicman_member pathlink.com> Dec 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
Dec 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.
Dec 28 2005
Ant <Ant_member pathlink.com> 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
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
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...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
error message something _useful_. Ideally, another tool could be used
solve the problem , but I still dont even know what the problem is ( Im
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
around in root.d or mod.d , I get 100 other import conflicts in a
endless circle of time wasting. Walter -- Can we get a better error message ? What do these actually _mean_ ?
can i solve this without randomly moving around import statements ? Charlie
Dec 28 2005
In article <dov4p6$12sc$1 digitaldaemon.com>, Charles says...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
I think a posted a "bug report" on this a while back. It's probably not
Walter disagrees that this should be improved, but that he doesn't think
high priority. And I don't know if it should really be a high priority. I
I've wasted a lot of time trying to decipher these particular brand of
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...digitalmars.D.bugs/1307
Ahh, that is a good thread. Thanks all for the responses ( problem solved ) . Im going to post as a
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
Walter disagrees that this should be improved, but that he doesn't think
high priority. And I don't know if it should really be a high priority. I
I've wasted a lot of time trying to decipher these particular brand of
but once someone showed me the trick on how to decipher them it got a lot easier. jcc7
Dec 28 2005
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
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
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
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
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