|
Archives
D Programming
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics
|
digitalmars.D - What's left to do for a stable D2?
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?
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
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
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
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.
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
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?
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
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
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/
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
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 ?
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
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.
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
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
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(_))
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.
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
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
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.
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.
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.
== 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?
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.
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
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?
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.
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.
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
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.
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.
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.
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?
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.
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.
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
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
Jason House wrote:
What's left?
Getting D1 finished first. Why do people keep asking???
Stewart.
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)
----------------------------------------------------------------------
|
|
C & C++
DMDScript
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> 