www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.038 and 2.022 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
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
Dec 14 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
 Version D 1.038   Dec 11, 2008
 New/Changed Features
     * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!
 # Bugzilla 2490: extern(C++) can not handle structs as return types

Shouldn't this only be in the D2 change log? --bb 2008/12/14 Walter Bright <newshound1 digitalmars.com>:
 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

Dec 14 2008
next sibling parent reply Daniel de Kok <daniel nowhere.nospam> writes:
On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:

 Version D 1.038   Dec 11, 2008
 New/Changed Features
     * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!

So, we'll see a new std2? :^) (I for one would be very happy)
Dec 14 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok <daniel nowhere.nospam> wrote:
 On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:

 Version D 1.038   Dec 11, 2008
 New/Changed Features
     * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!

So, we'll see a new std2? :^) (I for one would be very happy)

Not a new std2, just updates to the old one. But yeh. --bb
Dec 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok <daniel nowhere.nospam> wrote:
 On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:

 Version D 1.038   Dec 11, 2008
 New/Changed Features
     * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!

So, we'll see a new std2? :^) (I for one would be very happy)

Not a new std2, just updates to the old one. But yeh.

Apologies for the delay in updating std2. I've had a good reason (in addition to having a dissertation to complete), see www.erdani.org. :o) Andrei
Dec 14 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Dec 15, 2008 at 6:20 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok <daniel nowhere.nospam>
 wrote:
 On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:

 Version D 1.038   Dec 11, 2008
 New/Changed Features
    * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!

So, we'll see a new std2? :^) (I for one would be very happy)

Not a new std2, just updates to the old one. But yeh.

Apologies for the delay in updating std2. I've had a good reason (in addition to having a dissertation to complete), see www.erdani.org. :o)

I'm referring to this std2: http://www.dsource.org/projects/std2 I think you're referring to std in v2 Phobos, but if you really are referring to std2 then I look forward to the updates. ;-) --bb
Dec 14 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, Dec 15, 2008 at 6:20 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok <daniel nowhere.nospam>
 wrote:
 On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:

 Version D 1.038   Dec 11, 2008
 New/Changed Features
    * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!

So, we'll see a new std2? :^) (I for one would be very happy)

Not a new std2, just updates to the old one. But yeh.

Apologies for the delay in updating std2. I've had a good reason (in addition to having a dissertation to complete), see www.erdani.org. :o)

I'm referring to this std2: http://www.dsource.org/projects/std2 I think you're referring to std in v2 Phobos, but if you really are referring to std2 then I look forward to the updates. ;-) --bb

Sorry, I was indeed referring to std v2 in Phobos. I warn you guys, there's going to be plenty of changes to std.algorithm. Andrei
Dec 14 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Dec 15, 2008 at 7:43 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Mon, Dec 15, 2008 at 6:20 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok <daniel nowhere.nospam>
 wrote:
 On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:

 Version D 1.038   Dec 11, 2008
 New/Changed Features
   * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!

So, we'll see a new std2? :^) (I for one would be very happy)

Not a new std2, just updates to the old one. But yeh.

Apologies for the delay in updating std2. I've had a good reason (in addition to having a dissertation to complete), see www.erdani.org. :o)

I'm referring to this std2: http://www.dsource.org/projects/std2 I think you're referring to std in v2 Phobos, but if you really are referring to std2 then I look forward to the updates. ;-) --bb

Sorry, I was indeed referring to std v2 in Phobos. I warn you guys, there's going to be plenty of changes to std.algorithm.

With ranges and reference returns, I suspect so. D2's added special support for foreach over ranges, right? Is there anything else that had to change D2 in for ranges? Anyway, my personal goal with D2 is not so much to facilitate compiling D2 code in D1, but more to just bring similar functionality to D1. So if std2.algorithm gets stuck at today's rev because of porting issues, I can live with that. But currently there is no functioning version std.algorithm at all in D1 because of the heavy use of partial IFTI with those string alias parameters. --bb
Dec 14 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-12-14 18:55:58 -0500, "Bill Baxter" <wbaxter gmail.com> said:

 On Mon, Dec 15, 2008 at 7:43 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 
 On Mon, Dec 15, 2008 at 6:20 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Bill Baxter wrote:
 
 On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok <daniel nowhere.nospam>
 wrote:
 
 On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:
 
 Version D 1.038   Dec 11, 2008
 New/Changed Features
 * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!

So, we'll see a new std2? :^) (I for one would be very happy)

Not a new std2, just updates to the old one. But yeh.

Apologies for the delay in updating std2. I've had a good reason (in addition to having a dissertation to complete), see www.erdani.org. :o)

I'm referring to this std2: http://www.dsource.org/projects/std2 I think you're referring to std in v2 Phobos, but if you really are referring to std2 then I look forward to the updates. ;-) --bb

Sorry, I was indeed referring to std v2 in Phobos. I warn you guys, there's going to be plenty of changes to std.algorithm.

With ranges and reference returns, I suspect so. D2's added special support for foreach over ranges, right? Is there anything else that had to change D2 in for ranges? Anyway, my personal goal with D2 is not so much to facilitate compiling D2 code in D1, but more to just bring similar functionality to D1. So if std2.algorithm gets stuck at today's rev because of porting issues, I can live with that. But currently there is no functioning version std.algorithm at all in D1 because of the heavy use of partial IFTI with those string alias parameters.

Couldn't you use a double template? template doSomething(string predicate) { void doSomething(A)(a) { ... } } Then call it like this: doSomething!("hello!")(5); I'm using this trick at some places the D/Objective-C bridge. Anyway, it's probably not worth the trouble anymore given that the latest DMD fixes the problem. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 15 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Tue, Dec 16, 2008 at 10:28 AM, Michel Fortin
<michel.fortin michelf.com> wrote:
 On 2008-12-14 18:55:58 -0500, "Bill Baxter" <wbaxter gmail.com> said:

 On Mon, Dec 15, 2008 at 7:43 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Mon, Dec 15, 2008 at 6:20 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok <daniel nowhere.nospam>
 wrote:
 On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:

 Version D 1.038   Dec 11, 2008
 New/Changed Features
 * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!

So, we'll see a new std2? :^) (I for one would be very happy)

Not a new std2, just updates to the old one. But yeh.

Apologies for the delay in updating std2. I've had a good reason (in addition to having a dissertation to complete), see www.erdani.org. :o)

I'm referring to this std2: http://www.dsource.org/projects/std2 I think you're referring to std in v2 Phobos, but if you really are referring to std2 then I look forward to the updates. ;-) --bb

Sorry, I was indeed referring to std v2 in Phobos. I warn you guys, there's going to be plenty of changes to std.algorithm.

With ranges and reference returns, I suspect so. D2's added special support for foreach over ranges, right? Is there anything else that had to change D2 in for ranges? Anyway, my personal goal with D2 is not so much to facilitate compiling D2 code in D1, but more to just bring similar functionality to D1. So if std2.algorithm gets stuck at today's rev because of porting issues, I can live with that. But currently there is no functioning version std.algorithm at all in D1 because of the heavy use of partial IFTI with those string alias parameters.

Couldn't you use a double template? template doSomething(string predicate) { void doSomething(A)(a) { ... } } Then call it like this: doSomething!("hello!")(5); I'm using this trick at some places the D/Objective-C bridge. Anyway, it's probably not worth the trouble anymore given that the latest DMD fixes the problem.

Technically yes, but the code would require so many changes to make that work that I didn't think it was worth it. I might as well call it bills.algorithm at that point instead of std2.algorithm. Apparently Andrei didn't like the thought of having to write the code that way either, which is presume why he convinced Walter to change/fix IFTI in D2. --bb
Dec 15 2008
prev sibling next sibling parent "Christof Schardt" <csnews christof-schardt.de> writes:
 Apologies for the delay in updating std2. I've had a good reason (in 
 addition to having a dissertation to complete), see www.erdani.org. :o)

Bad news for D :-) Congratulations anyway. Christof
Dec 14 2008
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Andrei,

 Bill Baxter wrote:
 
 On Sun, Dec 14, 2008 at 8:40 PM, Daniel de Kok
 <daniel nowhere.nospam> wrote:
 
 On Sun, 14 Dec 2008 20:10:26 +0900, Bill Baxter wrote:
 
 Version D 1.038   Dec 11, 2008
 New/Changed Features
 * Added Partial IFTI Bugzilla 493

Hooray! Now I can finish porting std.algorithm and friends to D1!

So, we'll see a new std2? :^) (I for one would be very happy)

Not a new std2, just updates to the old one. But yeh.

Apologies for the delay in updating std2. I've had a good reason (in addition to having a dissertation to complete), see www.erdani.org. :o) Andrei

Aha! A baby! Congrats! Looks like Andrew is going to have a big head start with computers. :-) -JJR
Dec 15 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 # Bugzilla 2490: extern(C++) can not handle structs as return types

Shouldn't this only be in the D2 change log?

No, because it also affects how D1 'COM' classes work on Linux.
Dec 14 2008
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
the files are not present on the FTP server ?!


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

Dec 14 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Dec 14, 2008 at 8:41 PM, Extrawurst <spam extrawurst.org> wrote:
 the files are not present on the FTP server ?!


 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


Apparently not. I'm getting a 404 too. --bb
Dec 14 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Dec 14, 2008 at 7:13 AM, Bill Baxter <wbaxter gmail.com> wrote:
 On Sun, Dec 14, 2008 at 8:41 PM, Extrawurst <spam extrawurst.org> wrote:
 the files are not present on the FTP server ?!


 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


Apparently not. I'm getting a 404 too.

Agh, he's taunting us!
Dec 14 2008
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Dec 14, 2008 at 6:41 AM, Extrawurst <spam extrawurst.org> wrote:
 the files are not present on the FTP server ?!


 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


OK, they've been uploaded and the download links work now.
Dec 14 2008
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic tiscali.co.uk> writes:
"The requested URL /dmd.2.022.zip was not found on this server."
Dec 14 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Dejan Lekic wrote:
 "The requested URL /dmd.2.022.zip was not found on this server."

I always goof up something. They're there now.
Dec 14 2008
prev sibling next sibling parent reply Mike James <foo bar.com> writes:
Jarrett Billingsley Wrote:


 OK, they've been uploaded and the download links work now.

I can download the DMD 1.038 zip file but Windows Folders, 7-zip and WinRAR fail to open it - bad EOF. -=mike=-
Dec 14 2008
parent Mike James <foo bar.com> writes:
Mike James Wrote:

 Jarrett Billingsley Wrote:
 
 
 OK, they've been uploaded and the download links work now.

I can download the DMD 1.038 zip file but Windows Folders, 7-zip and WinRAR fail to open it - bad EOF. -=mike=-

It does now :-) -=mike=-
Dec 14 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
This time the compilation of my dlibs (using V.1.038) has gone a little less
smoothly.

With V.1.037 this line compiles fine, while statically asserts in V.1.038:
static assert(!is(typeof( xkeys([12:"ab", 5:"ba"]) )));

I have tried to track down the problem, but after going into a rat's nest for
40-50+ minutes I have surrendered and just commented out the line.

That line of code is present inside the unittests of xkeys(), an iterable class
whose opApply yields just the keys of the given associative array. Of course
that [12:"ab", 5:"ba"] AA can't be accepted because its values aren't dynamic
arrays, so it can't use a foreach on it yet.

-----------------------

I have seen the Bug #493 fixed, very nice. Of course the more I have the more I
want, so I'd like to be able to do something like this:

import std.stdio: writefln;

struct Spam(T, S) {
    T a;
    S b;
    void show() {
        writefln("typeof(T), typeof(S): ", typeid(T), " ", typeid(S));
    }
}

Spam!(T, S) spam(T, S)(T a, S b) {
    return Spam!(double, int)(a, b);
}

void main() {
    Spam!(double, int)(1.0, 33).show(); // OK
    spam(1.0, 33).show(); // OK
    Spam(1.0, 33).show(); // ERROR
}

Currently I use an auxiliary function (here named spam()) to do this with
structs (and classes).
It's just sugar, but may help me avoid about 20-30 little helper functions in
my dlibs.

Bye,
bearophile
Dec 14 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
For me, V1.038 compiles my code but takes a really really really long
time to do so.

It now takes  1 min 20 secs for a full build, when it used to compile
in 13 seconds.
Forget the 60% slowdown from LDC -- this is 515% slower!

(building with DSSS and tango)

--bb

On Mon, Dec 15, 2008 at 10:14 AM, bearophile <bearophileHUGS lycos.com> wrote:
 This time the compilation of my dlibs (using V.1.038) has gone a little less
smoothly.

 With V.1.037 this line compiles fine, while statically asserts in V.1.038:
 static assert(!is(typeof( xkeys([12:"ab", 5:"ba"]) )));

 I have tried to track down the problem, but after going into a rat's nest for
40-50+ minutes I have surrendered and just commented out the line.

 That line of code is present inside the unittests of xkeys(), an iterable
class whose opApply yields just the keys of the given associative array. Of
course that [12:"ab", 5:"ba"] AA can't be accepted because its values aren't
dynamic arrays, so it can't use a foreach on it yet.

 -----------------------

 I have seen the Bug #493 fixed, very nice. Of course the more I have the more
I want, so I'd like to be able to do something like this:

 import std.stdio: writefln;

 struct Spam(T, S) {
    T a;
    S b;
    void show() {
        writefln("typeof(T), typeof(S): ", typeid(T), " ", typeid(S));
    }
 }

 Spam!(T, S) spam(T, S)(T a, S b) {
    return Spam!(double, int)(a, b);
 }

 void main() {
    Spam!(double, int)(1.0, 33).show(); // OK
    spam(1.0, 33).show(); // OK
    Spam(1.0, 33).show(); // ERROR
 }

 Currently I use an auxiliary function (here named spam()) to do this with
structs (and classes).
 It's just sugar, but may help me avoid about 20-30 little helper functions in
my dlibs.

 Bye,
 bearophile

Dec 14 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Are you using a lot of templates and recursive imports?

Bill Baxter wrote:
 For me, V1.038 compiles my code but takes a really really really long
 time to do so.
 
 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!
 
 (building with DSSS and tango)

Dec 15 2008
next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Even if so, why has it become so much slower ?


Walter Bright wrote:
 Are you using a lot of templates and recursive imports?
 
 Bill Baxter wrote:
 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)


Dec 15 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Extrawurst wrote:
 Even if so, why has it become so much slower ?

See my answer to Bill.
Dec 15 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Dec 15, 2008 at 7:07 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Are you using a lot of templates and recursive imports?

A lot of templates, yes. A lot of recursive imports, I don't think so. Is there an easy way to see if I have recursive imports? I usually try to make my imports tree-like, but it's possible I may have some unintentional import cycles. --bb
 Bill Baxter wrote:
 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)


Dec 15 2008
next sibling parent BLS <nanali nospam.wanadoo.fr> writes:
Bill Baxter schrieb:
  Is there an easy way to see if I have recursive imports?  I
 usually try to make my imports tree-like, but it's possible I may have
 some unintentional import cycles.
 
 --bb

Yep, you can use DIL to analyse your code and draw dependency graphs. http://code.google.com/p/dil/ quote Produce module dependency graphs using the graphviz dot format. .....Cyclic edges (import statements) and nodes (modules) are highlighted in red. The edges of public imports are bold. end quote bls
Dec 15 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 On Mon, Dec 15, 2008 at 7:07 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Are you using a lot of templates and recursive imports?

A lot of templates, yes. A lot of recursive imports, I don't think so. Is there an easy way to see if I have recursive imports? I usually try to make my imports tree-like, but it's possible I may have some unintentional import cycles.

I don't know of an easy way to tell. The reason I ask is because modules that recursively import themselves will wind up doing a lot more template instantiations because the compiler can't tell which module will instantiate an external template reference. (Change in this behavior fixes a bug.)
Dec 15 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Are you using a lot of templates and recursive imports?

Note: the mysterious new bug I have found in V.1.038 may have some relation with recursive imports (removing them that bug more or less vanishes). Bye, bearophile
Dec 15 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 For me, V1.038 compiles my code but takes a really really really long
 time to do so.
 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!
 (building with DSSS and tango)

I have tested the compilation timings of my dlibs (using 'bud'), they contain lot of templates. Compilation timings (with unittest), no run: V1.037: 11.33 s V1.038: 11.52 s The size of the resulting exe is the same (1.887 MB). (Without unittests the compilation is much faster, about 0.47 seconds for 1.038). So it seems my compilation timings are grown, but not much. I have just found out that 'bud' isn't using both cores of my CPU. Why?? Bye, bearophile
Dec 15 2008
parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 15 Dec 2008 17:37:27 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:

 Bill Baxter:
 For me, V1.038 compiles my code but takes a really really really long
 time to do so.
 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!
 (building with DSSS and tango)

I have tested the compilation timings of my dlibs (using 'bud'), they contain lot of templates. Compilation timings (with unittest), no run: V1.037: 11.33 s V1.038: 11.52 s The size of the resulting exe is the same (1.887 MB). (Without unittests the compilation is much faster, about 0.47 seconds for 1.038). So it seems my compilation timings are grown, but not much. I have just found out that 'bud' isn't using both cores of my CPU. Why??

Neither does DMD (bud is just a thin wrapper around DMD). I use CodeBlocks and it has "number of parallel builds" option which is very helpful. DSSS on Linux can do that, too, IIRC.
 Bye,
 bearophile

Dec 15 2008
prev sibling next sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <ludwig informatik.uni-luebeck.de> writes:
Bill Baxter schrieb:
 For me, V1.038 compiles my code but takes a really really really long
 time to do so.
 
 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!
 
 (building with DSSS and tango)
 
 --bb
 

In my project compilation takes now several minutes for some files which compiled in about a second with 2.021. I stopped the compilation of the whole project after about 2 hours (took 2 min at most on 2.021). I'll try to track this down when I get the time, but i doubt that those times get anywhere near those of the original.
Dec 15 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
S÷nke Ludwig wrote:
 In my project compilation takes now several minutes for some files which 
 compiled in about a second with 2.021. I stopped the compilation of the 
 whole project after about 2 hours (took 2 min at most on 2.021).
 
 I'll try to track this down when I get the time, but i doubt that those 
 times get anywhere near those of the original.

Do you have modules that recursively import themselves, and instantiate a lot of templates?
Dec 15 2008
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= writes:
Walter Bright schrieb:
 S÷nke Ludwig wrote:
 In my project compilation takes now several minutes for some files 
 which compiled in about a second with 2.021. I stopped the compilation 
 of the whole project after about 2 hours (took 2 min at most on 2.021).

 I'll try to track this down when I get the time, but i doubt that 
 those times get anywhere near those of the original.

Do you have modules that recursively import themselves, and instantiate a lot of templates?

There were some import cycles and I've had some time now to remove all of them. There might be a small improvement but it feels just as slow as before (still multiple minutes for some files). In the particular region of the library there is a Variant template in use at two places as a typedef: "typedef Variant!(TypeEnum, type1, type2, ..., type8);". This would be my main suspect when it comes to templates. However, compiling the Variant module alone or a small module only using Variant takes a fraction of a second. I have attached the output of a CodeAnalyst profiling run. The file shows the hotspot section during the first 60 seconds of compiling one of the files. Percentages have to be multiplied roughly by 2 because this is a dual core system.
Dec 20 2008
parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= writes:
S÷nke Ludwig schrieb:
  Percentages have to be multiplied roughly by 2 because
 this is a dual core system.
 

Hm, ignore that part.. they are multiplied by 2 already...
Dec 20 2008
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com> wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?
Dec 20 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden gmail.com> wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com> wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

I'd love to have an unnecessary import finder tool. How does that work? --bb
Dec 20 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter gmail.com> wrote:

 On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden gmail.com>  
 wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>  
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

I'd love to have an unnecessary import finder tool. How does that work? --bb

It's easy: remove an import and try if it still works :) I recompile that file only and since all the imports are private, it generally doesn't break other files. The only exception - templates. They aren't fully analyzed until instanciated and therefore some imports may be removed even if they are necessary. A simple tag prevents an import from removal: private import std.algorithm; // force Works about 3 minutes to remove all redundant imports from DWT.
Dec 20 2008
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Denis Koroskin escribi├│:
 On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter gmail.com> wrote:
 
 On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden gmail.com> 
 wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com> 
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

I'd love to have an unnecessary import finder tool. How does that work? --bb

It's easy: remove an import and try if it still works :) I recompile that file only and since all the imports are private, it generally doesn't break other files. The only exception - templates. They aren't fully analyzed until instanciated and therefore some imports may be removed even if they are necessary. A simple tag prevents an import from removal: private import std.algorithm; // force Works about 3 minutes to remove all redundant imports from DWT.

A problem with import removal in D is conditional compilation: import foo; import bar; int lala() { version(FOO) { return somethingInModuleFoo(); } else { return somethingInModuleBar(); } } Now you need to compile your file twice, each time with a different version, and see if any import can be removed (in the example, if you remove foo, and FOO is not declared as a version, your file still compiles).
Dec 20 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Dec 20, 2008 at 10:01 PM, Denis Koroskin <2korden gmail.com> wrote:
 On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter gmail.com> wrote:

 On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden gmail.com> wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

I'd love to have an unnecessary import finder tool. How does that work? --bb

It's easy: remove an import and try if it still works :)

Oh. ok. Well, removing things and trying to recompile is more or less what I do now. That's not really what I'd call a "tool". That's what I'd call "doing it manually". --bb
Dec 20 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 20 Dec 2008 16:28:40 +0300, Bill Baxter <wbaxter gmail.com> wrote:

 On Sat, Dec 20, 2008 at 10:01 PM, Denis Koroskin <2korden gmail.com>  
 wrote:
 On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter gmail.com>  
 wrote:

 On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden gmail.com>  
 wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

I'd love to have an unnecessary import finder tool. How does that work? --bb

It's easy: remove an import and try if it still works :)

Oh. ok. Well, removing things and trying to recompile is more or less what I do now. That's not really what I'd call a "tool". That's what I'd call "doing it manually". --bb

No, it's fully automated.
Dec 20 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Dec 20, 2008 at 10:36 PM, Denis Koroskin <2korden gmail.com> wrote:
 On Sat, 20 Dec 2008 16:28:40 +0300, Bill Baxter <wbaxter gmail.com> wrote:

 On Sat, Dec 20, 2008 at 10:01 PM, Denis Koroskin <2korden gmail.com>
 wrote:
 On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden gmail.com>
 wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes  1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

I'd love to have an unnecessary import finder tool. How does that work? --bb

It's easy: remove an import and try if it still works :)

Oh. ok. Well, removing things and trying to recompile is more or less what I do now. That's not really what I'd call a "tool". That's what I'd call "doing it manually". --bb

No, it's fully automated.

Ah, now I get it. --bb
Dec 20 2008
prev sibling next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Denis Koroskin wrote:
 On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter gmail.com> wrote:
 
 I'd love to have an unnecessary import finder tool.  How does that work?

 --bb

It's easy: remove an import and try if it still works :) I recompile that file only and since all the imports are private, it generally doesn't break other files. The only exception - templates. They aren't fully analyzed until instanciated and therefore some imports may be removed even if they are necessary. A simple tag prevents an import from removal:

Some more exceptions: * http://d.puremagic.com/issues/show_bug.cgi?id=313 ("Fully qualified names bypass private imports") * http://d.puremagic.com/issues/show_bug.cgi?id=314 ("Static, renamed, and selective imports are always public")
Dec 20 2008
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Denis,

 On Sat, 20 Dec 2008 15:39:08 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:
 
 On Sat, Dec 20, 2008 at 9:11 PM, Denis Koroskin <2korden gmail.com>
 wrote:
 
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:
 
 For me, V1.038 compiles my code but takes a really really really
 long time to do so.
 
 It now takes  1 min 20 secs for a full build, when it used to
 compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!
 (building with DSSS and tango)
 
 --bb
 

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

I'd love to have an unnecessary import finder tool. How does that work? --bb

It's easy: remove an import and try if it still works :) I recompile that file only and since all the imports are private, it generally doesn't break other files. The only exception - templates. They aren't fully analyzed until instanciated and therefore some imports may be removed even if they are necessary. A simple tag prevents an import from removal: private import std.algorithm; // force Works about 3 minutes to remove all redundant imports from DWT.

So you've tried this with dwt? Were you able to see if it affected the final binary size or speed of compilation for dwt projects? Removing all redundant imports in DWT is something we should see happen in the repository. :) -JJR
Dec 20 2008
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com> wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal
Dec 20 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100 gmail.com>  
wrote:

 Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>  
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that! http://www.youtube.com/user/asterite
Dec 20 2008
next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sat, Dec 20, 2008 at 12:50 PM, Denis Koroskin <2korden gmail.com> wrote:
 You should watch Descent videos on youtube, it is *much* smarter that that!

 http://www.youtube.com/user/asterite

Wow, that's so awesome!
Dec 20 2008
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Denis Koroskin wrote:
 On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100 gmail.com>
 wrote:

 Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that! http://www.youtube.com/user/asterite

I watched the video. the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that. for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout. More over, if you wrote some of the imports yourself, or edited some code and removed the only call to some function, you can ask eclipse to orginize your imports and it'll remove unneeded imports and expand Java's Foo.* kind of import to a list of the actual modules the code needs. Descent is a great project and I want to thank all the developers involved in this great undertaking. All I'm saying is that it would be nice to also have an "organize imports" function in Descent. -- Yigal
Dec 20 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Yigal Chripun wrote:

 Denis Koroskin wrote:
 On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100 gmail.com>
 wrote:

 Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that! http://www.youtube.com/user/asterite

I watched the video. the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that. for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout. More over, if you wrote some of the imports yourself, or edited some code and removed the only call to some function, you can ask eclipse to orginize your imports and it'll remove unneeded imports and expand Java's Foo.* kind of import to a list of the actual modules the code needs. Descent is a great project and I want to thank all the developers involved in this great undertaking. All I'm saying is that it would be nice to also have an "organize imports" function in Descent.

And you know for certain that it doesn't have this? -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Dec 20 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Lars Ivar Igesund escribiˇ:
 Yigal Chripun wrote:
 
 Denis Koroskin wrote:
 On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100 gmail.com>
 wrote:

 Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that! http://www.youtube.com/user/asterite

I watched the video. the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that. for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout. More over, if you wrote some of the imports yourself, or edited some code and removed the only call to some function, you can ask eclipse to orginize your imports and it'll remove unneeded imports and expand Java's Foo.* kind of import to a list of the actual modules the code needs. Descent is a great project and I want to thank all the developers involved in this great undertaking. All I'm saying is that it would be nice to also have an "organize imports" function in Descent.

And you know for certain that it doesn't have this?

Yigal is right, Descent doesn't have that kind of functionality. As I mentioned before, you'd need to try every possible conditional-compilation setup combination to see which are the unused imports. Also, when I first implemented it, I thought about adding selective imports in autocompletion, so that: --- void foo() { writefln| <-- autocomplete! } --- results in: --- import std.stdio : writefln; void foo() { writefln(...) } --- and successive uses of symbols in std.stdio would add to the selective import, but many people told me that selective imports have some problems (I can't remember which were them right now).
Dec 20 2008
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig escribiˇ:
 Lars Ivar Igesund escribiˇ:
 Yigal Chripun wrote:

 Denis Koroskin wrote:
 On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100 gmail.com>
 wrote:

 Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really 
 long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that! http://www.youtube.com/user/asterite

I watched the video. the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that. for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout. More over, if you wrote some of the imports yourself, or edited some code and removed the only call to some function, you can ask eclipse to orginize your imports and it'll remove unneeded imports and expand Java's Foo.* kind of import to a list of the actual modules the code needs. Descent is a great project and I want to thank all the developers involved in this great undertaking. All I'm saying is that it would be nice to also have an "organize imports" function in Descent.

And you know for certain that it doesn't have this?

Yigal is right, Descent doesn't have that kind of functionality. As I mentioned before, you'd need to try every possible conditional-compilation setup combination to see which are the unused imports.

Also: templates are not resolved until their instantiation, so that's a harder problem.
Dec 20 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Ary Borenszweig wrote:
 Lars Ivar Igesund escribiˇ:
 Yigal Chripun wrote:

 Denis Koroskin wrote:
 On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100 gmail.com>
 wrote:

 Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really
 long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that! http://www.youtube.com/user/asterite

I watched the video. the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that. for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout. More over, if you wrote some of the imports yourself, or edited some code and removed the only call to some function, you can ask eclipse to orginize your imports and it'll remove unneeded imports and expand Java's Foo.* kind of import to a list of the actual modules the code needs. Descent is a great project and I want to thank all the developers involved in this great undertaking. All I'm saying is that it would be nice to also have an "organize imports" function in Descent.

And you know for certain that it doesn't have this?

Yigal is right, Descent doesn't have that kind of functionality. As I mentioned before, you'd need to try every possible conditional-compilation setup combination to see which are the unused imports. Also, when I first implemented it, I thought about adding selective imports in autocompletion, so that: --- void foo() { writefln| <-- autocomplete! } --- results in: --- import std.stdio : writefln; void foo() { writefln(...) } --- and successive uses of symbols in std.stdio would add to the selective import, but many people told me that selective imports have some problems (I can't remember which were them right now).

Sounds awesome. if those problems (DMD bugs?) can be overcome, this would be one of my favorite features in descent. what about a compromise? for the sake of unused import elimination assume that all possible versions are used. it's not that far off.. suppose I have: import Foo; import Bar; version (foo) { // use symbols from Foo here } version (bar) { // use symbols from Bar here } removing either of the imports will be bad. more advanced functionality would be to move the imports to inside of the version blocks. I haven' t thought this through yet, but even some of this would be extremely useful. even if you just implement adding missing imports (and requiring me to remove redundant imports myself manually). Keep on the good work, and thanks for an awsome and very useful project! -- Yigal
Dec 20 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Lars Ivar Igesund wrote:
 Yigal Chripun wrote:

 Denis Koroskin wrote:
 On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun<yigal100 gmail.com>
 wrote:

 Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter<wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that! http://www.youtube.com/user/asterite

I watched the video. the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that. for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout. More over, if you wrote some of the imports yourself, or edited some code and removed the only call to some function, you can ask eclipse to orginize your imports and it'll remove unneeded imports and expand Java's Foo.* kind of import to a list of the actual modules the code needs. Descent is a great project and I want to thank all the developers involved in this great undertaking. All I'm saying is that it would be nice to also have an "organize imports" function in Descent.

And you know for certain that it doesn't have this?

yeap. this is one of the basic refactorings, I guess. Descent isn't implementing any refactorings yet, right? I think they are still working on finishing some other internal systems - The semantic parsing is still experimental IIRC. once the semantic parsing works fully refactorings on the AST can be implemented, but I don't think Descent reached that stage of development yet. correct me if I'm wrong. I read the InteliJ IDEA changelog for the latest version 8 today. they added 10 refactorings, one of which is doing a dataflow analysis on the pointed to symbol and shows in the call heirarchy where that symbol's value comes from. Sounds extremly useful to me. -- Yigal
Dec 20 2008
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Yigal Chripun escribi├│:
 Denis Koroskin wrote:
 On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100 gmail.com>
 wrote:

 Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that! http://www.youtube.com/user/asterite

I watched the video. the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that. for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout.

If you put the cursor right after Stdout, you get the autocompletion. But I understand what you say, you want ctrl+shift+o (organize imports). I need to add some hooks into the port of the compiler so when a "symbol undefined" is reported, show a popup suggesting an import. Aww... so many features I'd like to add. I wish more people would join the project. Many people say "thanks to all the developers involved in this project", and it's really just me, Robert Fraser, Bruno Medeiros, Frank Benoit helped a little in the beginning, and I can't remember if someone else helped... Of course, its testing, its usage, comments and suggestions by part of the community helped a lot also, but if more people would join the project, it would be much more powerful than now...
Dec 20 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
Ary Borenszweig wrote:
 Yigal Chripun escribi├│:
 Denis Koroskin wrote:
 On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100 gmail.com>
 wrote:

 Denis Koroskin wrote:
 On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter gmail.com>
 wrote:

 For me, V1.038 compiles my code but takes a really really really long
 time to do so.

 It now takes 1 min 20 secs for a full build, when it used to compile
 in 13 seconds.
 Forget the 60% slowdown from LDC -- this is 515% slower!

 (building with DSSS and tango)

 --bb

I generally make all my imports private and run a command line tool that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

When programming in Java, Eclipse knows to handle all of this for you. it will suggest adding missing imports, it can remove unused imports and it can convert a foo.bar.* into a list of the specific modules you actually used in the code. I wish that kind of tool would be available for D. Is this functionality implemented in descent? if not, is it planned? I do realize that it's more difficult to do this for D than it is for Java, because of Conditional compilation and other issues already mentioned in this thread. But it would be awesome if I could just write: Stdout("whatever").newline; and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list of imports. --Yigal

You should watch Descent videos on youtube, it is *much* smarter that that! http://www.youtube.com/user/asterite

I watched the video. the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that. for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout.

If you put the cursor right after Stdout, you get the autocompletion. But I understand what you say, you want ctrl+shift+o (organize imports). I need to add some hooks into the port of the compiler so when a "symbol undefined" is reported, show a popup suggesting an import. Aww... so many features I'd like to add. I wish more people would join the project. Many people say "thanks to all the developers involved in this project", and it's really just me, Robert Fraser, Bruno Medeiros, Frank Benoit helped a little in the beginning, and I can't remember if someone else helped... Of course, its testing, its usage, comments and suggestions by part of the community helped a lot also, but if more people would join the project, it would be much more powerful than now...

You read my mind :) I hear you. It's not easy to take such a huge undertaking on yourself. Well, I know Java, I don't know the sourcecode of eclipse and how to work with it. I have very little spare time. I'll be happy to help as much as I can, even if it's just testing and such. I can help test for 64bit (windows/linux)...
Dec 20 2008
prev sibling next sibling parent reply mastrost <titi.mastro free.fr> writes:
Hi,

first of all, thank you Walter and all the D community for making the great
"pure"
feature become reality.
I have 2 questions concerning the behaviour of this feature.

The first one concerns the existence -or not- of "pure delegates".
It makes sense to use a delegate if its closure is not empty -otherwise it is no
more than a function-. This is the reason why we can think delegates cannot be
pure. Let's take an example:

void foo(){
    int x=0;
    //bar is not pure at all in this context
    int bar(){
        return x;
    }
    writefln(bar()); // prints '0'
    ++x;
    writefln(bar()); // prints '1'
}

But the fact is that when returning a delegate, its closure freezes forever and
so
behaves like a local variable and not like a global variable by respect to the
delegate :

int delegate() getPureFunction(int x){
    int bar(){
        return x;
    }
    return &bar;
}

void main(){
    int delegate() myPureFunction;
    myPureFunction = getPureFunction(5);
}

In this example, myPureFunction looks like a pure function, does it?
So how does dmd 2.022 behave for such kind of "pure delegates" ? Do you think
there is a futur for pure delegates in the D language ? If not this would mean
that we cannot use the power of delegates (to do real functionnal programming)
and
the power of purity in the same time, which will be very disapointing for
programmers, don't you think ?

This was my first question. The second one concerns purity and parallel
programming. Is dmd 2.022 implementing some kind of parallelism thanks to pure
function? In fact I have been argued that "pure" keyword is not enough for the
compiler to make an efficient parallel program. The problem would be that the
compiler has no mean to know the granularity of the tasks. What are your
feelings
about that?

Thanks a lot
Dec 15 2008
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 16 Dec 2008 01:48:21 +0300, mastrost <titi.mastro free.fr> wrote:

 Hi,

 first of all, thank you Walter and all the D community for making the  
 great "pure"
 feature become reality.
 I have 2 questions concerning the behaviour of this feature.

 The first one concerns the existence -or not- of "pure delegates".
 It makes sense to use a delegate if its closure is not empty -otherwise  
 it is no
 more than a function-. This is the reason why we can think delegates  
 cannot be
 pure. Let's take an example:

 void foo(){
     int x=0;
     //bar is not pure at all in this context
     int bar(){
         return x;
     }
     writefln(bar()); // prints '0'
     ++x;
     writefln(bar()); // prints '1'
 }

 But the fact is that when returning a delegate, its closure freezes  
 forever and so
 behaves like a local variable and not like a global variable by respect  
 to the
 delegate :

 int delegate() getPureFunction(int x){
     int bar(){
         return x;
     }
     return &bar;
 }

 void main(){
     int delegate() myPureFunction;
     myPureFunction = getPureFunction(5);
 }

 In this example, myPureFunction looks like a pure function, does it?
 So how does dmd 2.022 behave for such kind of "pure delegates" ? Do you  
 think
 there is a futur for pure delegates in the D language ? If not this  
 would mean
 that we cannot use the power of delegates (to do real functionnal  
 programming) and
 the power of purity in the same time, which will be very disapointing for
 programmers, don't you think ?

Yes, it was previously discussed many times (not only delegates but any function in general (locally impure)). Current plan it to make pure function restrictive and then lift unnecessary restrictions where possible.
 This was my first question. The second one concerns purity and parallel
 programming. Is dmd 2.022 implementing some kind of parallelism thanks  
 to pure
 function? In fact I have been argued that "pure" keyword is not enough  
 for the
 compiler to make an efficient parallel program. The problem would be  
 that the
 compiler has no mean to know the granularity of the tasks. What are your  
 feelings
 about that?

This is not implemented yet. Pure function are just being added into language.
 Thanks a lot

Dec 15 2008
prev sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 15 Dec 2008 17:48:21 -0500, mastrost <titi.mastro free.fr> wrote:
 int delegate() getPureFunction(int x){
     int bar(){
         return x;
     }
     return &bar;
 }

int delegate() getPureFunction(int x){ int bar(){ return x++; // no longer pure } return &bar; }
 In this example, myPureFunction looks like a pure function, does it?

No it doesn't, but on the other hand, pure member functions argue that pure delegates are reasonable and useful. (i.e. delegates tagged as pure and then checked for references to non-pure data)
 This was my first question. The second one concerns purity and parallel
 programming. Is dmd 2.022 implementing some kind of parallelism thanks  
 to pure
 function? In fact I have been argued that "pure" keyword is not enough  
 for the
 compiler to make an efficient parallel program. The problem would be  
 that the
 compiler has no mean to know the granularity of the tasks. What are your  
 feelings
 about that?

I'd say that you're unlikely to get an optimal parallel program, but there already exists several functional languages (i.e. pure) that automatically parallelize their code bases quite efficiently.
Dec 16 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 16 Dec 2008 18:58:47 +0100, Robert Jacques <sandford jhu.edu>  
wrote:

 On Mon, 15 Dec 2008 17:48:21 -0500, mastrost <titi.mastro free.fr> wrote:

 In this example, myPureFunction looks like a pure function, does it?

No it doesn't

So this does not seem pure to you? int myPureFunction(int x) { return x; } -- Simen
Dec 16 2008
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 16 Dec 2008 12:28:43 -0800, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Tue, 16 Dec 2008 18:58:47 +0100, Robert Jacques <sandford jhu.edu>  
 wrote:

 On Mon, 15 Dec 2008 17:48:21 -0500, mastrost <titi.mastro free.fr>  
 wrote:

 In this example, myPureFunction looks like a pure function, does it?

No it doesn't

So this does not seem pure to you? int myPureFunction(int x) { return x; }

Short answer: That's a function, not a delegate and without a 'pure' tag it's unreasonable for the complier to know it's logically pure. Long answer: Your original arguement was:
 But the fact is that when returning a delegate, its closure freezes  
 forever and so

behaves like a local variable and not like a global variable by respect to the delegate : Which I read to mean that a returned delegate is inherently pure. On a second read, I think you mean that the closure heap variables may be treated as immutable once a delegate is returned if the delegate doesn't mutate them. While an interesting observation, it too is easily broken: int delegate() impure; int delegate() getPureFunction(int x){ int bar(){ return x; } int foo() { return x++; } impure = foo; // The closure may not be considered immutable since 'x' escapes return &bar; }
Dec 16 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 17 Dec 2008 00:39:00 +0100, Robert Jacques <sandford jhu.edu>  
wrote:

 On Tue, 16 Dec 2008 12:28:43 -0800, Simen Kjaeraas  
 <simen.kjaras gmail.com> wrote:

 So this does not seem pure to you?

    int myPureFunction(int x) {
      return x;
    }

Short answer: That's a function, not a delegate and without a 'pure' tag it's unreasonable for the complier to know it's logically pure.

I agree with this, but feel that's beside the point argued by mastrost. My point (and I believe mastrost's as well) was that the above function and mastrost's example could be considered pure by the simple addition of the 'pure' keyword.
 Long answer: Your original arguement was:

 But the fact is that when returning a delegate, its closure freezes  
 forever and so

behaves like a local variable and not like a global variable by respect to the delegate : Which I read to mean that a returned delegate is inherently pure. On a second read, I think you mean that the closure heap variables may be treated as immutable once a delegate is returned if the delegate doesn't mutate them. While an interesting observation, it too is easily broken:

Ah, I read it to mean that a delegate with no side effects is just as pure as a function with none, which I find hard to argue against. As D is a systems language, one might argue that casting a delegate to pure is reasonable, as it may be too hard to statically check if it is pure, and a cast is a confirmation from the programmer that yes, he knows what he's doing. -- Simen
Dec 17 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Simen Kjaeraas" wrote
 On Wed, 17 Dec 2008 00:39:00 +0100, Robert Jacques wrote:
 Which I read to mean that a returned delegate is inherently pure. On a 
 second read, I think you mean that the closure heap variables may be 
 treated as immutable once a delegate is returned if the delegate doesn't 
 mutate them. While an interesting observation, it too is easily broken:

Ah, I read it to mean that a delegate with no side effects is just as pure as a function with none, which I find hard to argue against. As D is a systems language, one might argue that casting a delegate to pure is reasonable, as it may be too hard to statically check if it is pure, and a cast is a confirmation from the programmer that yes, he knows what he's doing.

Please note, Walter's vision of pure is not the same as C's implementation of pure. Walter wants pure functions that have no side effects *AND* cannot be affected by other functions' side effects. Your example fails the second requirement. This is more in line with actual fucntional languages, where all data is invariant (and therefore, cannot be affected by outside functions). -Steve
Dec 17 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 18 Dec 2008 07:01:49 +0100, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 Walter wants pure functions that have no side effects *AND* cannot be
 affected by other functions' side effects.  Your example fails the second
 requirement.

I should have put that in there as well. My point was that a delegate /can be/ as pure as a normal function. -- Simen
Dec 18 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Simen Kjaeraas wrote:
 On Thu, 18 Dec 2008 07:01:49 +0100, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:
 
 Walter wants pure functions that have no side effects *AND* cannot be
 affected by other functions' side effects.  Your example fails the second
 requirement.

I should have put that in there as well. My point was that a delegate /can be/ as pure as a normal function.

Right, but the compiler might have to take it on faith that the delegate is really pure.
Dec 18 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 18 Dec 2008 13:27:16 +0100, Christopher Wright  
<dhasenan gmail.com> wrote:

 Simen Kjaeraas wrote:
 On Thu, 18 Dec 2008 07:01:49 +0100, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 Walter wants pure functions that have no side effects *AND* cannot be
 affected by other functions' side effects.  Your example fails the  
 second
 requirement.

I should have put that in there as well. My point was that a delegate /can be/ as pure as a normal function.

Right, but the compiler might have to take it on faith that the delegate is really pure.

Which is why I said a cast might be necessary. -- Simen
Dec 18 2008
parent mastrost <titi.mastro free.fr> writes:
Simen Kjaeraas Wrote:

 On Thu, 18 Dec 2008 13:27:16 +0100, Christopher Wright  
 <dhasenan gmail.com> wrote:
 
 Simen Kjaeraas wrote:
 On Thu, 18 Dec 2008 07:01:49 +0100, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 Walter wants pure functions that have no side effects *AND* cannot be
 affected by other functions' side effects.  Your example fails the  
 second
 requirement.

I should have put that in there as well. My point was that a delegate /can be/ as pure as a normal function.

Right, but the compiler might have to take it on faith that the delegate is really pure.

Which is why I said a cast might be necessary. -- Simen

In fact I thought that a returned delegate with no side effect was inherently pure, because I thought the delegate was the only one to have access to its closure variables. In fact, as Simen showed, the closure can be shared between several delegates. So if all delegates sharing the same closure have no side effect, can we say that they are all pure ?
Dec 18 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Christopher Wright" wrote
 Simen Kjaeraas wrote:
 On Thu, 18 Dec 2008 07:01:49 +0100, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 Walter wants pure functions that have no side effects *AND* cannot be
 affected by other functions' side effects.  Your example fails the 
 second
 requirement.

I should have put that in there as well. My point was that a delegate /can be/ as pure as a normal function.

Right, but the compiler might have to take it on faith that the delegate is really pure.

It depends on the delegate. I'd say that a delegate that points to a closure, or stack frame, is inherently unpure. However, a delegate that points to a class instance member function can be pure if the class instance is immutable. The purity will be stored with the signature of the function (and therefore the type). So normal casts should work in the case that you know what you are doing, but there can't be any way for the compiler to know to cast the stack frame to immutable. What you could do is form a requirement that if any inner function of another function is marked as pure, then ALL inner functions must be marked as pure. Then, at the moment you pass a delegate to one of those functions, or call one of those functions, all local data becomes immutable. I don't see a lot of benefit to all that, but then again, I'm not really experienced with functional programming techniques. -Steve
Dec 18 2008
prev sibling next sibling parent 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 "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
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.

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.

That is the cyclic import problem. Can you check again to see if you have cyclic imports?
Dec 19 2008
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
next sibling 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 reply "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
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 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 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
next 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
prev sibling 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.
 

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.

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.
 

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.

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.
 

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.

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.

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.

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.

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),
 

Despite few (bad) holes that need to be filled still, the closest is 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.
 

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.

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.
 

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

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.

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

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.

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

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.
 

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

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?

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.

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

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.
 

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

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.

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 reply Jason House <jason.james.house gmail.com> writes:
Is it possible to close the bugzilla bugs that were fixed?

More generally, bug owners get e-mails when bugs are closed, but don't receive
e-mails when new releases are made.  Here I was sitting around waiting for one
of my bugs to get fixed, and here it's been fixed a week and a half :(

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

Dec 21 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 Is it possible to close the bugzilla bugs that were fixed?
 
 More generally, bug owners get e-mails when bugs are closed, but
 don't receive e-mails when new releases are made.  Here I was sitting
 around waiting for one of my bugs to get fixed, and here it's been
 fixed a week and a half :(

Yes, I just haven't gotten around to it yet!
Dec 21 2008