www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.038 and 2.022 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.038.zip



http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.022.zip
Dec 14 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
 Version D 1.038   Dec 11, 2008
 New/Changed Features
     * Added Partial IFTI Bugzilla 493

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

Shouldn't this only be in the D2 change log? --bb 2008/12/14 Walter Bright <newshound1 digitalmars.com>:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.038.zip



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

Dec 14 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 # Bugzilla 2490: extern(C++) can not handle structs as return types

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

No, because it also affects how D1 'COM' classes work on Linux.
Dec 14 2008
prev sibling 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



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




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




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 next sibling parent 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
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 "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
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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
This time the compilation of my dlibs (using V.1.038) has gone a little less
smoothly.

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

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

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

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

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

import std.stdio: writefln;

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

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

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

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

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

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

(building with DSSS and tango)

--bb

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

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

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

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

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

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

 import std.stdio: writefln;

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

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

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

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

 Bye,
 bearophile

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

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

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


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

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

 (building with DSSS and tango)


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

See my answer to Bill.
Dec 15 2008
prev sibling next sibling parent 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 next 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 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 next sibling parent 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
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:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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

that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

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

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

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

that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

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

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

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

that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

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

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

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

that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

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

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

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 "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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
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
 

that strips unnecessary imports once in a while to minimize intermodular dependencies. Maybe it could help in your case, too?

work? --bb

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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev 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 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 next 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 "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 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 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.

/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 "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
prev sibling next sibling parent "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

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
prev sibling next sibling parent "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

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
prev sibling next sibling parent "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
prev sibling parent "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.

/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
prev sibling next sibling 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 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