digitalmars.D.announce - DMD 1.038 and 2.022 releases

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

"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

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

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

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

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

"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

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

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

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

"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

"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

"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

"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

Dejan Lekic <dejan.lekic tiscali.co.uk> writes:

"The requested URL /dmd.2.022.zip was not found on this server."

Dec 14 2008

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

"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

"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

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

"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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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

"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

"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

"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

"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

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

"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

"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

"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

"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

"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

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

"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

"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

"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

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

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

"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

"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

"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

"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

"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

"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

"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

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

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

D Programming

C/C++ Programming

Other

digitalmars.D.announce - DMD 1.038 and 2.022 releases