www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's left to do for a stable D2?

reply Jason House <jason.james.house gmail.com> writes:
Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 
Jan 21 2010
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 

This page[1] has been getting regular updates, so it should do a good job answering the question. 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections
Jan 21 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jesse Phillips:
 This page[1] has been getting regular updates, so it should do a good
 job answering the question.
 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

Most things on that page seems OK and not too much complex to understand. There are two things in that page that I think need more discussion, because I don't understand them or I don't see their need: - Remove struct initializers. - Make array literals immutable. So I'd like an explanation of what the first means, and why body are useful/necessary. Bye, bearophile
Jan 21 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Thank you for your answers Simen kjaeraas.

No need for them when we have this: S s = S( 4 );<

If you have to initialize an array of many structs you have to repeat the name of the struct many times, this is redundant, and takes more space (and if you don't use an IDE it needs more time to type): struct Vector2 { double x, y; } Vector2[] data1 = [{1,2}, {3,4}, {0,1}, {1,2}, {2,3}, {3,4}, {4,5}, {5,6}, {6,7}, {7,8}, {8,9}, {9,10}, {10,11}, {11,12}, {12,13}, {13,14}, {14,15}, {15,16}, {16,17}, {17,18}, {18,19}, {19,20}]; Vector2[] data2 = [Vector2(0,1), Vector2(1,2), Vector2(2,3), Vector2(3,4), Vector2(4,5), Vector2(5,6), Vector2(6,7), Vector2(7,8), Vector2(8,9), Vector2(9,10), Vector2(10,11), Vector2(11,12), Vector2(12,13), Vector2(13,14), Vector2(14,15), Vector2(15,16), Vector2(16,17), Vector2(17,18), Vector2(18,19), Vector2(19,20)]; void main() {}
Literals are allocated in the static data segment, and thus should be
immutable.<

In Python I am used to modify the contents of array (list) literals, for example I can initialize them to some values and then change them. So I'd like array literals to be mutable, but I can live with them being immutable and dup them where necessary. There are times in D code where I write: foreach (direction; [[-1,+0],[+0,-1],[+1,+0],[+0,+1]]) { ... Where in a similar situation in Python I write (this bit of pattern matching is very handy, but D devs seems not interested in this): for sx, sy in [[-1,+0],[+0,-1],[+1,+0],[+0,+1]]: ... Currently ldc compiles that line of D1 code badly (creating a new array of all the directions in each loop cycle, ugly), with immutable literals there is never a risk of doing: foreach (ref direction; [[-1,+0],[+0,-1],[+1,+0],[+0,+1]]) { ... so the array initialization can surely be moved out of the loop (another small problem is that in D2 those little inner length-2 arrays are dynamic arrays, that's not much efficient). Bye, bearophile
Jan 22 2010
parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Thank you for your answers Simen kjaeraas.
 
 No need for them when we have this: S s = S( 4 );<

If you have to initialize an array of many structs you have to repeat the name of the struct many times, this is redundant, and takes more space (and if you don't use an IDE it needs more time to type): struct Vector2 { double x, y; } Vector2[] data1 = [{1,2}, {3,4}, {0,1}, {1,2}, {2,3}, {3,4}, {4,5}, {5,6}, {6,7}, {7,8}, {8,9}, {9,10}, {10,11}, {11,12}, {12,13}, {13,14}, {14,15}, {15,16}, {16,17}, {17,18}, {18,19}, {19,20}]; Vector2[] data2 = [Vector2(0,1), Vector2(1,2), Vector2(2,3), Vector2(3,4), Vector2(4,5), Vector2(5,6), Vector2(6,7), Vector2(7,8), Vector2(8,9), Vector2(9,10), Vector2(10,11), Vector2(11,12), Vector2(12,13), Vector2(13,14), Vector2(14,15), Vector2(15,16), Vector2(16,17), Vector2(17,18), Vector2(18,19), Vector2(19,20)]; void main() {}

That's interesting. I would tend to use a function to initialize such things, though, so I suspect such use cases are quite rare. Note that C-style struct initializers add a lot of complexity to the language.
 Literals are allocated in the static data segment, and thus should be
immutable.<

In Python I am used to modify the contents of array (list) literals, for example I can initialize them to some values and then change them. So I'd like array literals to be mutable, but I can live with them being immutable and dup them where necessary.

Currently, any use of array literals in D is a performance disaster. Two days ago, I found that by changing one line of code in my app from: immutable int [] setbits = [ 1, 2, 4, 8, 16, 32, 64, 128]; into static immutable int [] setbits = [ 1, 2, 4, 8, 16, 32, 64, 128]; my entire app became about 5 times faster. That is ridiculous. And such a clumsy syntax for something so simple.
Jan 22 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 bearophile wrote:
 Thank you for your answers Simen kjaeraas.

 No need for them when we have this: S s = S( 4 );<

If you have to initialize an array of many structs you have to repeat the name of the struct many times, this is redundant, and takes more space (and if you don't use an IDE it needs more time to type): struct Vector2 { double x, y; } Vector2[] data1 = [{1,2}, {3,4}, {0,1}, {1,2}, {2,3}, {3,4}, {4,5}, {5,6}, {6,7}, {7,8}, {8,9}, {9,10}, {10,11}, {11,12}, {12,13}, {13,14}, {14,15}, {15,16}, {16,17}, {17,18}, {18,19}, {19,20}]; Vector2[] data2 = [Vector2(0,1), Vector2(1,2), Vector2(2,3), Vector2(3,4), Vector2(4,5), Vector2(5,6), Vector2(6,7), Vector2(7,8), Vector2(8,9), Vector2(9,10), Vector2(10,11), Vector2(11,12), Vector2(12,13), Vector2(13,14), Vector2(14,15), Vector2(15,16), Vector2(16,17), Vector2(17,18), Vector2(18,19), Vector2(19,20)]; void main() {}

That's interesting. I would tend to use a function to initialize such things, though, so I suspect such use cases are quite rare. Note that C-style struct initializers add a lot of complexity to the language.
 Literals are allocated in the static data segment, and thus should be 
 immutable.<

In Python I am used to modify the contents of array (list) literals, for example I can initialize them to some values and then change them. So I'd like array literals to be mutable, but I can live with them being immutable and dup them where necessary.

Currently, any use of array literals in D is a performance disaster. Two days ago, I found that by changing one line of code in my app from: immutable int [] setbits = [ 1, 2, 4, 8, 16, 32, 64, 128]; into static immutable int [] setbits = [ 1, 2, 4, 8, 16, 32, 64, 128]; my entire app became about 5 times faster. That is ridiculous. And such a clumsy syntax for something so simple.

Is this is bugzilla yet? FWIW I also submitted a related performance bug. Andrei
Jan 22 2010
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Jesse Phillips Wrote:

 Jason House wrote:
 
 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 

This page[1] has been getting regular updates, so it should do a good job answering the question. 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

I believe most "future directions" will be D3 or beyond. I'm pretty certain that Andrei wants TDPL to match D2. All but one chapter has been written, and TDPL related bugs have gotten priority. There should be very few feature changes between now and D2 finalization. Andrei, Walter, Sean, can you comment?
Jan 22 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Jesse Phillips Wrote:
 
 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 

job answering the question. 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

I believe most "future directions" will be D3 or beyond. I'm pretty certain that Andrei wants TDPL to match D2. All but one chapter has been written, and TDPL related bugs have gotten priority. There should be very few feature changes between now and D2 finalization. Andrei, Walter, Sean, can you comment?

You mean the list "Known D2.0, Language"? Here's what I think (Walter is the ultimate go-to person): # Operator overloading: opBinary!("+"), opUnary!("--"), opIndexAssign!("*"). D2 # opDollar ( Bugzilla:3474). D2 # Move complex and imaginary types from language into std.complex. D2 # Fix the array stomping issue (T[new] was one proposal for this). We have a design that partially resolves it. Steve Schveighoffer has implemented it. # Remove C-style declarations. I don't think they'll be removed, but TDPL doesn't mention them. # Remove typedef. D2 # Remove struct initializers. Dunno # Remove floating point NCEG operators D2 # Remove "length" from array index expressions ( Bugzilla:3474). Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature stays, Andrei
Jan 22 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrei Alexandrescu wrote:
 We have a design that partially resolves it. Steve Schveighoffer has 
 implemented it.

What I meant here is: Steve has implemented the design in addition to participating to it. Andrei
Jan 22 2010
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-22 11:21:09 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 # Remove "length" from array index expressions ( Bugzilla:3474).
 
 Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature stays,

Agree. That one must go. At the very list it should be an error if it shadows any other symbol, but it'd be better if it just goes. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 22 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 22 Jan 2010 11:21:09 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Jason House wrote:
 Jesse Phillips Wrote:

 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left?

job answering the question. 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

certain that Andrei wants TDPL to match D2. All but one chapter has been written, and TDPL related bugs have gotten priority. There should be very few feature changes between now and D2 finalization. Andrei, Walter, Sean, can you comment?

You mean the list "Known D2.0, Language"? Here's what I think (Walter is the ultimate go-to person): # Operator overloading: opBinary!("+"), opUnary!("--"), opIndexAssign!("*"). D2 # opDollar ( Bugzilla:3474). D2 # Move complex and imaginary types from language into std.complex. D2 # Fix the array stomping issue (T[new] was one proposal for this). We have a design that partially resolves it. Steve Schveighoffer has implemented it. # Remove C-style declarations. I don't think they'll be removed, but TDPL doesn't mention them. # Remove typedef. D2 # Remove struct initializers. Dunno # Remove floating point NCEG operators D2 # Remove "length" from array index expressions ( Bugzilla:3474). Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature stays,

What about propagating qualifiers to the return type (i.e. inout)? I think that is a major change and is in the book. It's currently partially implemented, but it does not work. -Steve

D2 Andrei
Jan 22 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 1/22/10 17:21, Andrei Alexandrescu wrote:
 Jason House wrote:
 Jesse Phillips Wrote:

 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating
 std.thread(?), and Walter's been fixing forward reference and CTFE
 bugs. What's left?

job answering the question. 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

I believe most "future directions" will be D3 or beyond. I'm pretty certain that Andrei wants TDPL to match D2. All but one chapter has been written, and TDPL related bugs have gotten priority. There should be very few feature changes between now and D2 finalization. Andrei, Walter, Sean, can you comment?

You mean the list "Known D2.0, Language"? Here's what I think (Walter is the ultimate go-to person): # Operator overloading: opBinary!("+"), opUnary!("--"), opIndexAssign!("*"). D2 # opDollar ( Bugzilla:3474). D2 # Move complex and imaginary types from language into std.complex. D2 # Fix the array stomping issue (T[new] was one proposal for this). We have a design that partially resolves it. Steve Schveighoffer has implemented it. # Remove C-style declarations. I don't think they'll be removed, but TDPL doesn't mention them. # Remove typedef. D2 # Remove struct initializers. Dunno # Remove floating point NCEG operators D2 # Remove "length" from array index expressions ( Bugzilla:3474). Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature stays, Andrei

What about the uniform function call syntax ?
Jan 23 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jacob Carlborg wrote:
 On 1/22/10 17:21, Andrei Alexandrescu wrote:
 Jason House wrote:
 Jesse Phillips Wrote:

 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating
 std.thread(?), and Walter's been fixing forward reference and CTFE
 bugs. What's left?

job answering the question. 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

I believe most "future directions" will be D3 or beyond. I'm pretty certain that Andrei wants TDPL to match D2. All but one chapter has been written, and TDPL related bugs have gotten priority. There should be very few feature changes between now and D2 finalization. Andrei, Walter, Sean, can you comment?

You mean the list "Known D2.0, Language"? Here's what I think (Walter is the ultimate go-to person): # Operator overloading: opBinary!("+"), opUnary!("--"), opIndexAssign!("*"). D2 # opDollar ( Bugzilla:3474). D2 # Move complex and imaginary types from language into std.complex. D2 # Fix the array stomping issue (T[new] was one proposal for this). We have a design that partially resolves it. Steve Schveighoffer has implemented it. # Remove C-style declarations. I don't think they'll be removed, but TDPL doesn't mention them. # Remove typedef. D2 # Remove struct initializers. Dunno # Remove floating point NCEG operators D2 # Remove "length" from array index expressions ( Bugzilla:3474). Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature stays, Andrei

What about the uniform function call syntax ?

Far as I know it's already in, with bugs. Andrei
Jan 23 2010
parent Jacob Carlborg <doob me.com> writes:
On 1/23/10 18:50, Andrei Alexandrescu wrote:
 Jacob Carlborg wrote:
 On 1/22/10 17:21, Andrei Alexandrescu wrote:
 Jason House wrote:
 Jesse Phillips Wrote:

 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating
 std.thread(?), and Walter's been fixing forward reference and CTFE
 bugs. What's left?

job answering the question. 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

I believe most "future directions" will be D3 or beyond. I'm pretty certain that Andrei wants TDPL to match D2. All but one chapter has been written, and TDPL related bugs have gotten priority. There should be very few feature changes between now and D2 finalization. Andrei, Walter, Sean, can you comment?

You mean the list "Known D2.0, Language"? Here's what I think (Walter is the ultimate go-to person): # Operator overloading: opBinary!("+"), opUnary!("--"), opIndexAssign!("*"). D2 # opDollar ( Bugzilla:3474). D2 # Move complex and imaginary types from language into std.complex. D2 # Fix the array stomping issue (T[new] was one proposal for this). We have a design that partially resolves it. Steve Schveighoffer has implemented it. # Remove C-style declarations. I don't think they'll be removed, but TDPL doesn't mention them. # Remove typedef. D2 # Remove struct initializers. Dunno # Remove floating point NCEG operators D2 # Remove "length" from array index expressions ( Bugzilla:3474). Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature stays, Andrei

What about the uniform function call syntax ?

Far as I know it's already in, with bugs. Andrei

I've not seen it being mentioned at all and I can't get it to work: void foo (Object o) { } void main () { Object o = new Object; o.foo(); } Compiling the above with dmd trunk results in: main.d(8): Error: no property 'foo' for type 'object.Object' Looking at http://www.dsource.org/projects/dmd/browser/trunk/src/expression.c#L6483 it seems it's not implemented.
Jan 24 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 22 Jan 2010 08:50:17 +0100, bearophile <bearophileHUGS lycos.com>  
wrote:

 Jesse Phillips:
 This page[1] has been getting regular updates, so it should do a good
 job answering the question.
 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

Most things on that page seems OK and not too much complex to understand. There are two things in that page that I think need more discussion, because I don't understand them or I don't see their need: - Remove struct initializers.

Struct initializers on the C form: struct S { int n; } S s = { 4 }; No need for them when we have this: S s = S( 4 ); and static opCall for those special occasions. This cleans up the language, and makes some things somewhat easier (e.g., what is the type of { 4, "Hi!" }?
 - Make array literals immutable.

Currently, string literals are immutable, but no other array literals are: auto s = "Foo!"; // typeof( s ) == immutable(char)[] auto i = [ 1, 2, 3, 4 ]; // typeof( i ) == int[] Literals are allocated in the static data segment, and thus should be immutable. -- Simen
Jan 22 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 22 Jan 2010 11:21:09 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Jason House wrote:
 Jesse Phillips Wrote:

 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating  
 std.thread(?), and Walter's been fixing forward reference and CTFE  
 bugs. What's left?

job answering the question. 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

certain that Andrei wants TDPL to match D2. All but one chapter has been written, and TDPL related bugs have gotten priority. There should be very few feature changes between now and D2 finalization. Andrei, Walter, Sean, can you comment?

You mean the list "Known D2.0, Language"? Here's what I think (Walter is the ultimate go-to person): # Operator overloading: opBinary!("+"), opUnary!("--"), opIndexAssign!("*"). D2 # opDollar ( Bugzilla:3474). D2 # Move complex and imaginary types from language into std.complex. D2 # Fix the array stomping issue (T[new] was one proposal for this). We have a design that partially resolves it. Steve Schveighoffer has implemented it. # Remove C-style declarations. I don't think they'll be removed, but TDPL doesn't mention them. # Remove typedef. D2 # Remove struct initializers. Dunno # Remove floating point NCEG operators D2 # Remove "length" from array index expressions ( Bugzilla:3474). Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature stays,

What about propagating qualifiers to the return type (i.e. inout)? I think that is a major change and is in the book. It's currently partially implemented, but it does not work. -Steve
Jan 22 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 22 Jan 2010 15:27:02 -0500, bearophile wrote:

 Thank you for your answers Simen kjaeraas.
 
No need for them when we have this: S s = S( 4 );<

If you have to initialize an array of many structs you have to repeat the name of the struct many times, this is redundant, and takes more space (and if you don't use an IDE it needs more time to type): struct Vector2 { double x, y; } Vector2[] data1 = [{1,2}, {3,4}, {0,1}, {1,2}, {2,3}, {3,4}, {4,5}, {5,6}, {6,7}, {7,8}, {8,9}, {9,10}, {10,11}, {11,12}, {12,13}, {13,14}, {14,15}, {15,16}, {16,17}, {17,18}, {18,19}, {19,20}]; Vector2[] data2 = [Vector2(0,1), Vector2(1,2), Vector2(2,3), Vector2(3,4), Vector2(4,5), Vector2(5,6), Vector2(6,7), Vector2(7,8), Vector2(8,9), Vector2(9,10), Vector2(10,11), Vector2(11,12), Vector2(12,13), Vector2(13,14), Vector2(14,15), Vector2(15,16), Vector2(16,17), Vector2(17,18), Vector2(18,19), Vector2(19,20)]; void main() {}

I'd use something like this in higher level languages™: case class Vector[T](x: T, y: T) val pairs = List( (1,2), (3,4), (0,1), (2,3), (3,4), (4,5) ) val vectors = pairs map { case (a:Int, b:Int) => Vector(a,b) } or class Vector[T](x: T, y: T) { def this(xy: (T,T)) = this(xy._1, xy._2) } val pairs = List( (1,2), (3,4), (0,1), (2,3), (3,4), (4,5) ) val vectors = pairs map (new Vector(_))
Jan 23 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 23 Jan 2010 12:00:32 +0100, Jacob Carlborg wrote:

 What about the uniform function call syntax ?

It might require more useless bikeshedding before anything can be decided.
Jan 23 2010
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Jan 23, 2010 at 12:00:32PM +0100, Jacob Carlborg wrote:
 What about the uniform function call syntax ?

Yes, please! -- Adam D. Ruppe http://arsdnet.net
Jan 23 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 22 Jan 2010 21:27:02 +0100, bearophile <bearophileHUGS lycos.com=
  =

wrote:
 Thank you for your answers Simen kjaeraas.

 No need for them when we have this: S s =3D S( 4 );<

If you have to initialize an array of many structs you have to repeat =

 the name of the struct many times, this is redundant, and takes more  =

 space (and if you don't use an IDE it needs more time to type):

Use a local alias. void foo( ) { alias StructWithHorriblyLongAndComplicatedName =E0=BA=95; auto s =3D [ =E0=BA=95( 1, "a" ), =E0=BA=95( 2, "b" ), =E0=BA=95( 3, = "c" ) ]; } -- = Simen
Jan 23 2010
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Jason House Wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 

D2 seems to be close to be declared stable. I would also like to know if 64 bit support is going to be the next thing on the list? In my opinion it is much more important than any feature (AST macros, annotations etc). MS is pushing Windows 7 in 64 bit version. It is the same case with Apple operation systems and Linux. Many people refuse to use D2 and fall back to ldc just for this reason.
Jan 22 2010
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 22/01/10 10:42, Eldar Insafutdinov wrote:
 D2 seems to be close to be declared stable. I would also like to know
 if 64 bit support is going to be the next thing on the list? In my
 opinion it is much more important than any feature (AST macros,
 annotations etc). MS is pushing Windows 7 in 64 bit version. It is
 the same case with Apple operation systems and Linux. Many people
 refuse to use D2 and fall back to ldc just for this reason.

I'd have to agree, myself being one of those users.
Jan 24 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Eldar Insafutdinov wrote:
 D2 seems to be close to be declared stable. I would also like to know
 if 64 bit support is going to be the next thing on the list? In my
 opinion it is much more important than any feature (AST macros,
 annotations etc). MS is pushing Windows 7 in 64 bit version. It is
 the same case with Apple operation systems and Linux. Many people
 refuse to use D2 and fall back to ldc just for this reason.

I'm very aware of the importance of 64 bits, and it's next after D2 is complete.
Jan 24 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Eldar Insafutdinov wrote:
 D2 seems to be close to be declared stable. I would also like to know
 if 64 bit support is going to be the next thing on the list? In my
 opinion it is much more important than any feature (AST macros,
 annotations etc). MS is pushing Windows 7 in 64 bit version. It is
 the same case with Apple operation systems and Linux. Many people
 refuse to use D2 and fall back to ldc just for this reason.

complete.

Just out of curiosity, how hard is 64-bit to implement given that you already have a 32-bit compiler?
Jan 24 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 Just out of curiosity, how hard is 64-bit to implement given that you already
have
 a 32-bit compiler?

Shouldn't be that bad. After all, the current code generator survived going from 16 to 32 bits with about 90% of it unchanged. Probably a lot more work will go into writing the inline assembler. I'll have a big problem with the (nonexistent) 64 bit linker on Windows, and a lesser problem with the nonexistent debugger and librarian. That means that the first 64 bit dmd will be for Linux/OSX.
Jan 24 2010
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 ...
 I'll have a big problem with the (nonexistent) 64 bit linker on Windows,
 and a lesser problem with the nonexistent debugger and librarian. That
 means that the first 64 bit dmd will be for Linux/OSX.

Maybe it's time to switch to using the GNU tools on WindoMaybe it's time to switch to using the GNU tools on WindoMaybe it's-vwwwip Sorry, broken record. :P
Jan 24 2010
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 01/24/2010 08:59 PM, Walter Bright wrote:
 I'll have a big problem with the (nonexistent) 64 bit linker on Windows,
 and a lesser problem with the nonexistent debugger and librarian. That
 means that the first 64 bit dmd will be for Linux/OSX.

Not that I know anything about GSoC, but do you think such a project make a good target for Google summer of code?
Jan 24 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Ellery Newcomer wrote:
 Not that I know anything about GSoC, but do you think such a project 
 make a good target for Google summer of code?

I know less than nothing about that.
Jan 24 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Robert Jacques wrote:
 But don't 16-bit and 32-bit x86 have the same number of registers, while 
 x86-64 doubled them? Which should result in ABI changes, etc in addition 
 to optimizer changes.

No optimizer changes, ABI changes are minor.
Jan 24 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 25 Jan 2010 02:43:28 +0100, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Eldar Insafutdinov wrote:
 D2 seems to be close to be declared stable. I would also like to know
 if 64 bit support is going to be the next thing on the list? In my
 opinion it is much more important than any feature (AST macros,
 annotations etc). MS is pushing Windows 7 in 64 bit version. It is
 the same case with Apple operation systems and Linux. Many people
 refuse to use D2 and fall back to ldc just for this reason.

I'm very aware of the importance of 64 bits, and it's next after D2 is complete.

Awesome! D just keeps getting better. -- Simen
Jan 24 2010
prev sibling next sibling parent Trass3r <un known.com> writes:
Am 25.01.2010, 03:08 Uhr, schrieb dsimcha <dsimcha yahoo.com>:
 Just out of curiosity, how hard is 64-bit to implement given that you  
 already have a 32-bit compiler?

According to LuaJIT, a 64Bit code generator isn't that easy even if you already have a 32Bit one. http://luajit.org/sponsors.html etc.
Jan 24 2010
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 24 Jan 2010 21:59:38 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:

 dsimcha wrote:
 Just out of curiosity, how hard is 64-bit to implement given that you  
 already have
 a 32-bit compiler?

Shouldn't be that bad. After all, the current code generator survived going from 16 to 32 bits with about 90% of it unchanged.

But don't 16-bit and 32-bit x86 have the same number of registers, while x86-64 doubled them? Which should result in ABI changes, etc in addition to optimizer changes. Also, FWIW, according to Wikipedia, position independent code is also easier and they threw out some old instructions.
Jan 24 2010
prev sibling next sibling parent reply grauzone <none example.net> writes:
Jason House wrote:
 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 

Documentation. The Phobos docs are rather bad, and don't even include the core modules. Also there's std.thread, shouldn't it be core.thread? You can't release D2 "on the masses" like that.
Jan 24 2010
next sibling parent Jason House <jason.james.house gmail.com> writes:
grauzone Wrote:

 Jason House wrote:
 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 

Documentation. The Phobos docs are rather bad, and don't even include the core modules. Also there's std.thread, shouldn't it be core.thread?

Didn't someone start a wiki page in an attempt to revamp the Phobos docs? What happened to that?
Jan 24 2010
prev sibling parent reply Don <nospam nospam.com> writes:
grauzone wrote:
 Jason House wrote:
 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 

Documentation. The Phobos docs are rather bad, and don't even include the core modules. Also there's std.thread, shouldn't it be core.thread? You can't release D2 "on the masses" like that.

It's only the language spec which is getting frozen, not the libraries. TDPL intentionally doesn't say much at all about Phobos.
Jan 25 2010
parent reply grauzone <none example.net> writes:
Don wrote:
 grauzone wrote:
 Jason House wrote:
 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 

Documentation. The Phobos docs are rather bad, and don't even include the core modules. Also there's std.thread, shouldn't it be core.thread? You can't release D2 "on the masses" like that.

It's only the language spec which is getting frozen, not the libraries. TDPL intentionally doesn't say much at all about Phobos.

Well, you see, as TDPL is releases, there will be much attention on D, and people will go and try it out. Keep in mind that those people will know next to nothing about D. If the first what they'll experience is crashing on the chaotic documentation, that's going to be a major disappointment. It's like giving a birthday party without cake.
Jan 25 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 Don wrote:
 grauzone wrote:
 Jason House wrote:
 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 

Documentation. The Phobos docs are rather bad, and don't even include the core modules. Also there's std.thread, shouldn't it be core.thread? You can't release D2 "on the masses" like that.

It's only the language spec which is getting frozen, not the libraries. TDPL intentionally doesn't say much at all about Phobos.

Well, you see, as TDPL is releases, there will be much attention on D, and people will go and try it out. Keep in mind that those people will know next to nothing about D. If the first what they'll experience is crashing on the chaotic documentation, that's going to be a major disappointment. It's like giving a birthday party without cake.

Expending a fraction of the energy spent in wringing hands on actually helping with the documentation would mark a definite improvement. Andrei
Jan 25 2010
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Andrei Alexandrescu wrote:
 grauzone wrote:
 Don wrote:
 grauzone wrote:
 Jason House wrote:
 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 

Documentation. The Phobos docs are rather bad, and don't even include the core modules. Also there's std.thread, shouldn't it be core.thread? You can't release D2 "on the masses" like that.

It's only the language spec which is getting frozen, not the libraries. TDPL intentionally doesn't say much at all about Phobos.

Well, you see, as TDPL is releases, there will be much attention on D, and people will go and try it out. Keep in mind that those people will know next to nothing about D. If the first what they'll experience is crashing on the chaotic documentation, that's going to be a major disappointment. It's like giving a birthday party without cake.

Expending a fraction of the energy spent in wringing hands on actually helping with the documentation would mark a definite improvement. Andrei

I'm not too worried about the quality of documentation, and as has been mentioned before, it's probably not necessary to finish Phobos before TDPL comes out. What I think should be done, however, is to clear out the parts of Phobos you intend to remove or substantially rewrite. First impressions matter, and I think it's better for a (potential) new user to be met with "this currently isn't available, but check back in a little while", rather than with a set of perhaps-not-so-well-designed modules that will disappear after some time anyway. -Lars
Jan 25 2010
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Jason House wrote:
 What's left? 

Getting D1 finished first. Why do people keep asking??? Stewart.
Jan 25 2010
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 24 de enero a las 20:33 me escribiste:
 Ellery Newcomer wrote:
Not that I know anything about GSoC, but do you think such a
project make a good target for Google summer of code?

I know less than nothing about that.

The backend is not free, only FLOSS projects can apply to GSoC. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------
Jan 25 2010