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!





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:




 
 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.

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


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