www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Re: DMD 1.038 and 2.022 releases

reply John C <johnch_atms hotmail.com> writes:
Walter Bright Wrote:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.038.zip
 
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.022.zip

What's changed in the compiler to increase compile times so dramatically with this build? It's about a five-fold increase. My code uses some templates, but not what you'd call excessively, and there are no cyclic imports.
Dec 19 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 19 Dec 2008 14:51:11 +0300, John C <johnch_atms hotmail.com> wrote:

 Walter Bright Wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.038.zip



 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.022.zip

What's changed in the compiler to increase compile times so dramatically with this build? It's about a five-fold increase. My code uses some templates, but not what you'd call excessively, and there are no cyclic imports.

Pure and nothrow semantics checks, perhaps (even if you don't use them)?
Dec 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 On Fri, Dec 19, 2008 at 9:12 PM, Denis Koroskin <2korden gmail.com> wrote:
 On Fri, 19 Dec 2008 14:51:11 +0300, John C <johnch_atms hotmail.com> wrote:
 What's changed in the compiler to increase compile times so dramatically
 with this build? It's about a five-fold increase. My code uses some
 templates, but not what you'd call excessively, and there are no cyclic
 imports.


D1 is slower too, so that doesn't explain it. Going from what's in the changelog, I've got my suspicions it's the fix for this one that's responsible: http://d.puremagic.com/issues/show_bug.cgi?id=2500 Total guess though.

That is the cyclic import problem. Can you check again to see if you have cyclic imports?
Dec 19 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,


 That is the cyclic import problem. Can you check again to see if you
 have cyclic imports?
 

could you add a flag to DMD that will give a waning on cyclical imports?
Dec 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 That is the cyclic import problem. Can you check again to see if you
 have cyclic imports?

could you add a flag to DMD that will give a waning on cyclical imports?

I could, but in the meantime I want to find the source of the slowdown.
Dec 19 2008
parent John C <johnch_atms hotmail.com> writes:
Bill Baxter Wrote:

 On Sat, Dec 20, 2008 at 10:39 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 BCS wrote:
 That is the cyclic import problem. Can you check again to see if you
 have cyclic imports?

could you add a flag to DMD that will give a waning on cyclical imports?

I could, but in the meantime I want to find the source of the slowdown.

Without such a warning it's a bit difficult to track down if there are cyclic imports or not. At least in my code. I was hoping John C's example is maybe of a little more manageable size. --bb

I'll look into it. John.
Dec 20 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Dec 20, 2008 at 10:39 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 BCS wrote:
 That is the cyclic import problem. Can you check again to see if you
 have cyclic imports?

could you add a flag to DMD that will give a waning on cyclical imports?

I could, but in the meantime I want to find the source of the slowdown.

Without such a warning it's a bit difficult to track down if there are cyclic imports or not. At least in my code. I was hoping John C's example is maybe of a little more manageable size. --bb
Dec 19 2008
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Fri, Dec 19, 2008 at 6:51 PM, BCS <ao pathlink.com> wrote:
 Reply to Walter,


 That is the cyclic import problem. Can you check again to see if you
 have cyclic imports?

could you add a flag to DMD that will give a waning on cyclical imports?

http://www.shfls.org/w/d/dimple/ Cyclic imports show up in red. I love it.
Dec 20 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Dec 19, 2008 at 9:12 PM, Denis Koroskin <2korden gmail.com> wrote:
 On Fri, 19 Dec 2008 14:51:11 +0300, John C <johnch_atms hotmail.com> wrote:

 Walter Bright Wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.038.zip



 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.022.zip

What's changed in the compiler to increase compile times so dramatically with this build? It's about a five-fold increase. My code uses some templates, but not what you'd call excessively, and there are no cyclic imports.

Pure and nothrow semantics checks, perhaps (even if you don't use them)?

D1 is slower too, so that doesn't explain it. Going from what's in the changelog, I've got my suspicions it's the fix for this one that's responsible: http://d.puremagic.com/issues/show_bug.cgi?id=2500 Total guess though. --bb
Dec 19 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Dec 19, 2008 at 8:51 PM, John C <johnch_atms hotmail.com> wrote:
 Walter Bright Wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.038.zip



 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.022.zip

What's changed in the compiler to increase compile times so dramatically with this build? It's about a five-fold increase. My code uses some templates, but not what you'd call excessively, and there are no cyclic imports.

John, is your code small enough that you could extract a reasonable test case to give to Walter? My code involves maybe a hundred files, and does perhaps use templates "excessively". :-) --bb --bb
Dec 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 My code involves maybe a hundred files, and does perhaps use templates
 "excessively". :-)

Excess isn't the problem, I want to see if import cycles is. Also, try putting them all (most) on the same command line, and see if the speed improves.
Dec 19 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Excess isn't the problem, I want to see if import cycles is.

Generally all the modules in my dlibs import each other. This is nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently. Bye, bearophile
Dec 20 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
bearophile wrote:

 Walter Bright:
 Excess isn't the problem, I want to see if import cycles is.

Generally all the modules in my dlibs import each other. This is nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

Cyclic imports is very often a sign of bad design, it typically mean (if it is unavoidable), that the modules shouldn't be separated in the first place. And in D it _is_ a bad idea because static initialization cannot depend on each other, that is cyclic imports of modules with static ctors. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Dec 20 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Lars,

 bearophile wrote:
 
 Walter Bright:
 
 Excess isn't the problem, I want to see if import cycles is.
 

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

(if it is unavoidable), that the modules shouldn't be separated in the first place. And in D it _is_ a bad idea because static initialization cannot depend on each other, that is cyclic imports of modules with static ctors.

And yet it appears practically unavoidable in D in many situations, especially in porting software that with C, Java, or C++ heritage. Since other languages don't necessarily have the same module/package concept (except perhaps Java is the closest), porting such projects over to D inevitably triggers the cyclic dependency problem. The problem does indeed exacerbate when static initialization is thrown into the equation. One would have to build a D project from scratch in order to avoid it (eg Tango). The majority of projects, however, are going to be based on ported code. Thus, "bad design" becomes somewhat meaningless practically speaking, although I certainly wish there were an easy solution to the cyclic imports other than including all files in the same module. :) -JJR
Dec 20 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
John Reimer wrote:

 Hello Lars,
 
 bearophile wrote:
 
 Walter Bright:
 
 Excess isn't the problem, I want to see if import cycles is.
 

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

(if it is unavoidable), that the modules shouldn't be separated in the first place. And in D it _is_ a bad idea because static initialization cannot depend on each other, that is cyclic imports of modules with static ctors.

And yet it appears practically unavoidable in D in many situations, especially in porting software that with C, Java, or C++ heritage.

Being mostly a Java developer, I am well aware of the usage of cyclic dependencies in Java. Although it usually works fine technically, unless the dependencies are in the constructor itself, usage patterns are often made more difficult because of unnecessary cyclic dependencies and/or tight coupling. When porting something from Java, I don't really propose that you fix the errors of the original code, just saying that also the original code in that respect probably has made questionable design decisions. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Dec 21 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Lars,

 John Reimer wrote:
 
 Hello Lars,
 
 bearophile wrote:
 
 Walter Bright:
 
 Excess isn't the problem, I want to see if import cycles is.
 

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

(if it is unavoidable), that the modules shouldn't be separated in the first place. And in D it _is_ a bad idea because static initialization cannot depend on each other, that is cyclic imports of modules with static ctors.

especially in porting software that with C, Java, or C++ heritage.

dependencies in Java. Although it usually works fine technically, unless the dependencies are in the constructor itself, usage patterns are often made more difficult because of unnecessary cyclic dependencies and/or tight coupling. When porting something from Java, I don't really propose that you fix the errors of the original code, just saying that also the original code in that respect probably has made questionable design decisions.

Since I'm not a Java developer (or, to be honest, any kind of developer beyond a language enthusiast), I'd say I'm not in a good position to question the design decision of Java source that uses cyclic dependencies (such as SWT). All I can say is that I can agree that it looks like a bad idea because I can certainly see the painful problems it can produce. I think what I was trying to say, though, is that I'm genuinely curious how such design decisions could have been corrected in the original projects (eg SWT). After working with the code, I do indeed see an incredible example of "spaghetti" dependencies... but then I'm at a loss figuring out how the developers could have avoided it, given a language's limitations and the project's requirements. So I guess I'm a little cautious about wagging my finger at them. :) My guess is that in such a large project with so many widgets, if interdependencies were somehow lessoned, the bloat factor might have increased and, by implication, code reuse decreased. It seems to me that the project might have grown significantly larger. That's just conjecture, however. I'm very curious to know how people solve this and why a group of highly skilled developers felt it necessary to ignore this. The answer just might lie in SWT's historical roots, I'm guessing, since it started out from a Smalltalk project at IBM ages ago. Perhaps they experienced the similar porting "design" decisions that we face now. They were quite possibly stuck following the object heirarchy/interdepencies already in place. But I know your intent was to emphasize that it was just one of those questionable things, not necessarily to be categorically denied any relevance all together. I can certianly understand why it should be avoided; it has always been source of annoyance to me whenever I worked on dwt. I apologize for bringing the focus so heavily on SWT/DWT. -JJR
Dec 21 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
John Reimer wrote:
 
 Since I'm not a Java developer (or, to be honest, any kind of developer
 beyond a language enthusiast), I'd say I'm not in a good position to
 question the design decision of Java source that uses cyclic dependencies
 (such as SWT).
  All I can say is that I can agree that it looks like a bad idea because
 I can certainly see the painful problems it can produce.

I haven't used SWT enough, and certainly not looked much at the internals, to say whether I consider this a problem there or not. However, I've been using GWT for a while, and there was this widget I wanted to use. Unfortunately for me it missed a feature (or the ability to turn off a feature really) that I needed. And since it wasn't possible to fix this by subclassing either, I had to reimplement it all. Now, this wouldn't be so bad, but as it turned out it depended on a few other classes, and 4 or 5 of those had a back dependency on the main widget, meaning I had to reimplement those too. As it was, the discerning functionality of the main widget could have (should have) been put into an interface, the helper classes depend on that interface instead, the feature exposed, and by that time it would already be of much higher quality. Some more work would probably be needed with regards to the helper classes, but in the original code all of them could as well have been private classes of the widget. It is definately much more difficult to properly design code such that it has fewer cyclic dependencies, but I think that the choice between bottom-up or top-down approach will affect this a lot. If you start at the bottom, you're probably more likely to get a good result in this respect, just because there is only lower-level functionality to pick from when building the higher-level components. I do of course understand that bottom-up may not be the most obvious choice if high-level functionality is what you need in the first place. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Dec 22 2008
parent John Reimer <terminal.node gmail.com> writes:
Hello Lars,

 John Reimer wrote:
 
 Since I'm not a Java developer (or, to be honest, any kind of
 developer
 beyond a language enthusiast), I'd say I'm not in a good position to
 question the design decision of Java source that uses cyclic
 dependencies
 (such as SWT).
 All I can say is that I can agree that it looks like a bad idea
 because
 I can certainly see the painful problems it can produce.

internals, to say whether I consider this a problem there or not. However, I've been using GWT for a while, and there was this widget I wanted to use. Unfortunately for me it missed a feature (or the ability to turn off a feature really) that I needed. And since it wasn't possible to fix this by subclassing either, I had to reimplement it all. Now, this wouldn't be so bad, but as it turned out it depended on a few other classes, and 4 or 5 of those had a back dependency on the main widget, meaning I had to reimplement those too. As it was, the discerning functionality of the main widget could have (should have) been put into an interface, the helper classes depend on that interface instead, the feature exposed, and by that time it would already be of much higher quality. Some more work would probably be needed with regards to the helper classes, but in the original code all of them could as well have been private classes of the widget. It is definately much more difficult to properly design code such that it has fewer cyclic dependencies, but I think that the choice between bottom-up or top-down approach will affect this a lot. If you start at the bottom, you're probably more likely to get a good result in this respect, just because there is only lower-level functionality to pick from when building the higher-level components. I do of course understand that bottom-up may not be the most obvious choice if high-level functionality is what you need in the first place.

Thanks for the explanation. I forgot about interfaces, which is probably a pretty big "OOP's" on my part ;-D. I imagine it to be a good way to solve this particular import interdependency problem in D, although, depending on the project, the approach may prove insufficient. Alas, this is the unforunate thing about porting large software projects and that one continues to urk me: you rarely can afford to change the design in such away that it adopts the most sane approach for a given situation (or the given language you've ported it to). So it seems that the ideal of good design is sometimes stymied by project requirements and apparent language compromises for platform technologies. My problem with most projects I work on is the (nearly) insatiable desire to have it done right or at least to look "right". However, it is strangely apparent that "right" isn't always clear, but "wrong", done thoroughly, is horrifyingly obvious. Porting software has been hard because I've dearly wanted to fixup all things that I perceive to be messy, even at the expense of "if it ain't broke, don't fix it". This mentality, naturally, compromises productivity. However, practicality inevitably overrides many decisions to indulge the ideal of productivity. :) The good news is that, after seeing the problems incurred by design decisions, I feel more motivated to understand the meaning of the concept of "good design". -JJR
Dec 22 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
John Reimer:
 Since other languages 
 don't necessarily have the same module/package concept (except perhaps Java 
 is the closest),

Despite few (bad) holes that need to be filled still, the closest is probably the Python module system. Bye, bearophile
Dec 21 2008
parent John Reimer <terminal.node gmail.com> writes:
Hello bearophile,

 John Reimer:
 
 Since other languages don't necessarily have the same module/package
 concept (except perhaps Java is the closest),
 

probably the Python module system. Bye, bearophile

You're probably right. -JJR
Dec 21 2008
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 20 Dec 2008 18:45:24 +0100, Lars Ivar Igesund wrote:

 bearophile wrote:
 
 Walter Bright:
 Excess isn't the problem, I want to see if import cycles is.

Generally all the modules in my dlibs import each other. This is nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

Cyclic imports is very often a sign of bad design, it typically mean (if it is unavoidable), that the modules shouldn't be separated in the first place. And in D it _is_ a bad idea because static initialization cannot depend on each other, that is cyclic imports of modules with static ctors.

Just thinking out aloud ... If two modules import each other and this can be 'fixed' by instead having both modules as a single module, what is stopping the compiler from just pretending that they are a single module for compilation purposes? This does assume that they are to be compiled at the same time rather than one-file-at-a-time. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Dec 20 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Derek,

 On Sat, 20 Dec 2008 18:45:24 +0100, Lars Ivar Igesund wrote:
 
 bearophile wrote:
 
 Walter Bright:
 
 Excess isn't the problem, I want to see if import cycles is.
 

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

(if it is unavoidable), that the modules shouldn't be separated in the first place. And in D it _is_ a bad idea because static initialization cannot depend on each other, that is cyclic imports of modules with static ctors.

If two modules import each other and this can be 'fixed' by instead having both modules as a single module, what is stopping the compiler from just pretending that they are a single module for compilation purposes? This does assume that they are to be compiled at the same time rather than one-file-at-a-time.

Interesting idea. :) Maybe there would be issues with module ctors and __FILE__/__LINE__ expressions too? Also it may mess up module info, debug, and other object attributes. -JJR
Dec 20 2008
parent Christopher Wright <dhasenan gmail.com> writes:
John Reimer wrote:
 Hello Derek,
 Just thinking out aloud ...

 If two modules import each other and this can be 'fixed' by instead
 having both modules as a single module, what is stopping the compiler
 from just pretending that they are a single module for compilation
 purposes?

 This does assume that they are to be compiled at the same time rather
 than one-file-at-a-time.

Interesting idea. :) Maybe there would be issues with module ctors and __FILE__/__LINE__ expressions too? Also it may mess up module info, debug, and other object attributes. -JJR

This would work with two modules. How would it work with more than that? You'd have to come up with a complete import graph (which you already need, I assume), search it for cycles, then, for each cycle, resolve it by combining static constructors. It should work.
Dec 22 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
bearophile wrote:
 Walter Bright:
 Excess isn't the problem, I want to see if import cycles is.

Generally all the modules in my dlibs import each other. This is nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

Cyclic imports are a bad idea in general because of the impact they have on verifiability (unit testing). But as you say, sometimes they're unavoidable. Sean
Dec 20 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Sean,

 bearophile wrote:
 
 Walter Bright:
 
 Excess isn't the problem, I want to see if import cycles is.
 

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

have on verifiability (unit testing). But as you say, sometimes they're unavoidable. Sean

I'd going to wager that they are /often/ unavoidable, especially in ported projects from other languages that have either no concept or a different concept of modules/packages. DWT is perhaps the single worse example of cyclic imports. I'm not sure how the design could have been improved in Java's SWT. All it takes is the need to reference one symbol in each module (because each object apparently needs to just "know" about the other) to create a cyclic import issue in D. Static initialization has also been a problem in DWT such that a few significant workarounds were necessary. I agree that the interdepencies should be avoided in all new projects designed specifically for D. I'm just not sure what the solution would be for the great mass of ported software. -JJR
Dec 20 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"John Reimer" <terminal.node gmail.com> wrote in message 
news:28b70f8cfcfe8cb30c0a0e2ac70 news.digitalmars.com...
 Hello Sean,

 bearophile wrote:

 Walter Bright:

 Excess isn't the problem, I want to see if import cycles is.

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

have on verifiability (unit testing). But as you say, sometimes they're unavoidable. Sean

I'd going to wager that they are /often/ unavoidable, especially in ported projects from other languages that have either no concept or a different concept of modules/packages. DWT is perhaps the single worse example of cyclic imports. I'm not sure how the design could have been improved in Java's SWT. All it takes is the need to reference one symbol in each module (because each object apparently needs to just "know" about the other) to create a cyclic import issue in D. Static initialization has also been a problem in DWT such that a few significant workarounds were necessary. I agree that the interdepencies should be avoided in all new projects designed specifically for D. I'm just not sure what the solution would be for the great mass of ported software. -JJR

This might be a naive idea, and wouldn't solve the problems with cyclic dependancies in the general case: But regarding the static initializaton issue (which I've come up against myself), what if static initializers allowed some sort of clause like this: module foo; import bar; // Exact syntax not really important right now this() dependsOn(bar) { // Do some initing that depends on // bar's static initializer having been run. } That would force foo's static initialization to be run sometime after bar's. Obviously, any cycles in the graph of "dependsOn"s would be an error.
Dec 21 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Nick Sabalausky wrote:
 "John Reimer"<terminal.node gmail.com>  wrote in message
 news:28b70f8cfcfe8cb30c0a0e2ac70 news.digitalmars.com...
 Hello Sean,

 bearophile wrote:

 Walter Bright:

 Excess isn't the problem, I want to see if import cycles is.

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

have on verifiability (unit testing). But as you say, sometimes they're unavoidable. Sean

I'd going to wager that they are /often/ unavoidable, especially in ported projects from other languages that have either no concept or a different concept of modules/packages. DWT is perhaps the single worse example of cyclic imports. I'm not sure how the design could have been improved in Java's SWT. All it takes is the need to reference one symbol in each module (because each object apparently needs to just "know" about the other) to create a cyclic import issue in D. Static initialization has also been a problem in DWT such that a few significant workarounds were necessary. I agree that the interdepencies should be avoided in all new projects designed specifically for D. I'm just not sure what the solution would be for the great mass of ported software. -JJR

This might be a naive idea, and wouldn't solve the problems with cyclic dependancies in the general case: But regarding the static initializaton issue (which I've come up against myself), what if static initializers allowed some sort of clause like this: module foo; import bar; // Exact syntax not really important right now this() dependsOn(bar) { // Do some initing that depends on // bar's static initializer having been run. } That would force foo's static initialization to be run sometime after bar's. Obviously, any cycles in the graph of "dependsOn"s would be an error.

I'm curios - why isn't this a problem in other languages like Java (and I assume .net languages as well)? What's different in D that makes this so dificult? the static initializers? How is this handled in other languages?
Dec 21 2008
next sibling parent naryl <cyNOSPAM ngs.ru> writes:
Yigal Chripun Wrote:
 Nick Sabalausky wrote:
 This might be a naive idea, and wouldn't solve the problems with cyclic
 dependancies in the general case: But regarding the static initializaton
 issue (which I've come up against myself), what if static initializers
 allowed some sort of clause like this:

 module foo;
 import bar;

 // Exact syntax not really important right now
 this() dependsOn(bar) {
      // Do some initing that depends on
      // bar's static initializer having been run.
 }

 That would force foo's static initialization to be run sometime after bar's.
 Obviously, any cycles in the graph of "dependsOn"s would be an error.

I'm curios - why isn't this a problem in other languages like Java (and I assume .net languages as well)? What's different in D that makes this so dificult? the static initializers? How is this handled in other languages?

In Java static initializers are run during class loading. So cyclic dependencies in imports is not a problem. It's an error to make two or more static initializers depend on each other though.
Dec 21 2008
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Yigal,

 Nick Sabalausky wrote:
 
 "John Reimer"<terminal.node gmail.com>  wrote in message
 news:28b70f8cfcfe8cb30c0a0e2ac70 news.digitalmars.com...
 
 Hello Sean,
 
 bearophile wrote:
 
 Walter Bright:
 
 Excess isn't the problem, I want to see if import cycles is.
 

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

have on verifiability (unit testing). But as you say, sometimes they're unavoidable. Sean

ported projects from other languages that have either no concept or a different concept of modules/packages. DWT is perhaps the single worse example of cyclic imports. I'm not sure how the design could have been improved in Java's SWT. All it takes is the need to reference one symbol in each module (because each object apparently needs to just "know" about the other) to create a cyclic import issue in D. Static initialization has also been a problem in DWT such that a few significant workarounds were necessary. I agree that the interdepencies should be avoided in all new projects designed specifically for D. I'm just not sure what the solution would be for the great mass of ported software. -JJR

cyclic dependancies in the general case: But regarding the static initializaton issue (which I've come up against myself), what if static initializers allowed some sort of clause like this: module foo; import bar; // Exact syntax not really important right now this() dependsOn(bar) { // Do some initing that depends on // bar's static initializer having been run. } That would force foo's static initialization to be run sometime after bar's. Obviously, any cycles in the graph of "dependsOn"s would be an error.

(and I assume .net languages as well)? What's different in D that makes this so dificult? the static initializers? How is this handled in other languages?

For package scope, ie classes in the same directory, Java does /not/ seem to need an import statement, so somehow that suggests cyclic imports do not occur as they do in D for name resolution (in the specific case of package imports). But I don't know what happens under the hood: does the fact that Java sees the whole package for symbol resolution imply that it reads in all symbols initially for a package during compilation? If so, this would almost be equivalent to D, at compile time, reading all package modules as if they were one file somewhat similarly to what Derek was suggesting in another post. This is too much speculation from me, though. :) -JJR
Dec 21 2008
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 22 Dec 2008 00:07:42 +0200, Yigal Chripun wrote:

 Nick Sabalausky wrote:
 "John Reimer"<terminal.node gmail.com>  wrote in message
 news:28b70f8cfcfe8cb30c0a0e2ac70 news.digitalmars.com...
 Hello Sean,

 bearophile wrote:

 Walter Bright:

 Excess isn't the problem, I want to see if import cycles is.

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

have on verifiability (unit testing). But as you say, sometimes they're unavoidable. Sean

I'd going to wager that they are /often/ unavoidable, especially in ported projects from other languages that have either no concept or a different concept of modules/packages. DWT is perhaps the single worse example of cyclic imports. I'm not sure how the design could have been improved in Java's SWT. All it takes is the need to reference one symbol in each module (because each object apparently needs to just "know" about the other) to create a cyclic import issue in D. Static initialization has also been a problem in DWT such that a few significant workarounds were necessary. I agree that the interdepencies should be avoided in all new projects designed specifically for D. I'm just not sure what the solution would be for the great mass of ported software. -JJR

This might be a naive idea, and wouldn't solve the problems with cyclic dependancies in the general case: But regarding the static initializaton issue (which I've come up against myself), what if static initializers allowed some sort of clause like this: module foo; import bar; // Exact syntax not really important right now this() dependsOn(bar) { // Do some initing that depends on // bar's static initializer having been run. } That would force foo's static initialization to be run sometime after bar's. Obviously, any cycles in the graph of "dependsOn"s would be an error.

I'm curios - why isn't this a problem in other languages like Java (and I assume .net languages as well)? What's different in D that makes this so dificult? the static initializers? How is this handled in other languages?

In C/C++, if headers include each other and don't have any protection from multiple inclusion, they will include forever. If they *do* have protection, you get weird errors about unknown symbols which are obviously should be known. Only experience may tell you what happens. In Java ME used in mobile phones, when class A is loaded, its static initializers are run. If they refer to a class B which is not loaded yet, class B is loaded and its static initializers are run. If B's initializers refer to static fields of class A, they consider A already loaded and get uninitialized values. That is, crash at run-time. I don't know what Java SE does in this case.
Dec 21 2008
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Nick,

 "John Reimer" <terminal.node gmail.com> wrote in message
 news:28b70f8cfcfe8cb30c0a0e2ac70 news.digitalmars.com...
 
 Hello Sean,
 
 bearophile wrote:
 
 Walter Bright:
 
 Excess isn't the problem, I want to see if import cycles is.
 

nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

have on verifiability (unit testing). But as you say, sometimes they're unavoidable. Sean

ported projects from other languages that have either no concept or a different concept of modules/packages. DWT is perhaps the single worse example of cyclic imports. I'm not sure how the design could have been improved in Java's SWT. All it takes is the need to reference one symbol in each module (because each object apparently needs to just "know" about the other) to create a cyclic import issue in D. Static initialization has also been a problem in DWT such that a few significant workarounds were necessary. I agree that the interdepencies should be avoided in all new projects designed specifically for D. I'm just not sure what the solution would be for the great mass of ported software. -JJR

cyclic dependancies in the general case: But regarding the static initializaton issue (which I've come up against myself), what if static initializers allowed some sort of clause like this: module foo; import bar; // Exact syntax not really important right now this() dependsOn(bar) { // Do some initing that depends on // bar's static initializer having been run. } That would force foo's static initialization to be run sometime after bar's. Obviously, any cycles in the graph of "dependsOn"s would be an error.

Some sort of explicit ordering would likely be a solution. It would be /really/ nice if their were a clean way of implementing this... but it's really hard to say how it should be done. I'm not sure how it is done (if at all) in other languages that implement a similar feature. All I know is that, static initializations become almost useless at worst and extremely problematic at best in large projects, especially object based ones. There are workarounds, of course. One ends up having to learn not to be too dependent on this D feature. -JJR
Dec 21 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Walter Bright:
 Excess isn't the problem, I want to see if import cycles is.

Generally all the modules in my dlibs import each other. This is nearly unavoidable, if a module contains string functions, and another one contains math stuff, the string module will want to use some math stuff and the math module may need string representations and processing. In the D specs I haven't seen an advice to not use cyclic imports, so I don't want such compiler flag, I prefer a compiler able to manage such cyclic imports efficiently.

I understand your point, I am just trying to isolate the source of the problem rather than trying random things.
Dec 20 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Dec 20, 2008 at 10:41 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 My code involves maybe a hundred files, and does perhaps use templates
 "excessively". :-)

Excess isn't the problem, I want to see if import cycles is. Also, try putting them all (most) on the same command line, and see if the speed improves.

I'm pretty sure they are all on the same command line now for me, because I use DSSS with oneatatime turned off. I think in that case DSSS generates a single command like to compile everything. --bb
Dec 19 2008