Re: dmd 2.029 release
Russell Lewis wrote:
...
> Case in point: I have been bitten by this perhaps half a dozen times
> *already* porting older code. This code used to work fine:
>
> writefln("The value is: %d", myVar, ". Do something!");
>
...
I bet a lot of to-be-ported D code will have this bug, I know my code will.
When you want to print a format string this way - last argument(s) simply
appended, it saves you two characters typing. When something saves any
characters typing and produces the same result, programmers will do that.
Re: dmd 2.029 release
Michel Fortin wrote: > On 2009-04-21 11:18:39 -0400, Don said: > >> Yes. Actually, marking a nested function as pure doesn't make much sense. >> It's entirely equivalent to moving it outside the function; a nested >> pure function shouldn't be able to access any members of the enclosing >> function, otherwise it's not pure. But DMD doesn't enforce that, and >> so it creates inefficient and possibly buggy code. > > What about immutable local variables? A pure function can access > immutable globals, so it should be able to access immutable locals too. > If you treat the nested function's context pointer as a pointer to a struct matching the stack layout, then you can have pure nested functions -- they have exactly the same semantics as a pure struct member function. -- Daniel
Re: dmd 2.029 release
On 2009-04-21 11:18:39 -0400, Don said: Yes. Actually, marking a nested function as pure doesn't make much sense. It's entirely equivalent to moving it outside the function; a nested pure function shouldn't be able to access any members of the enclosing function, otherwise it's not pure. But DMD doesn't enforce that, and so it creates inefficient and possibly buggy code. What about immutable local variables? A pure function can access immutable globals, so it should be able to access immutable locals too. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 2.029 release
Andrei Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
If it were an error, I wouldn't let it go.
It's an error. It will lead to troubles.
Well at most you could say it's error-prone, something that is easier to
argue. The problem is that forcing it into an error makes quite a number
of valid uses impossible. An example is a logging application that
provides you a number of pieces of information (date, time, message,
etc.) and you get to specify how they should be formatted. Oftentimes
you'd choose to ignore some data.
Andrei
Fair enough. But then let's split off a version of the function which
allows unused arguments. For most users, in most cases, unused
arguments are indicative of an error.
Case in point: I have been bitten by this perhaps half a dozen times
*already* porting older code. This code used to work fine:
writefln("The value is: %d", myVar, ". Do something!");
Now, it interprets the trailing string as an unused argument, and
ignores it (silently). Ugh.
Ofc, looking back, I don't like that old coding style...I'm migrating
back more to C-style (give the whole format string first). But the fact
that I had a *silent* error was frustrating.
Russ
Re: dmd 2.029 release
On Tue, Apr 21, 2009 at 8:56 PM, Don wrote:
> bearophile wrote:
>>
>> Don:
>>>
>>> Yes. Actually, marking a nested function as pure doesn't make much sense.
>>> It's entirely equivalent to moving it outside the function; [...]
>>> I'm not sure that nested pure member functions should be legal.
>>
>> It's not fully equivalent to moving it out of the function because once
>> you pull it out you add a name to the outer namespace: nested functions are
>> useful to keep namespaces tidy too.
>> So I'd like to have nested pure functions too.
>>
>> pure int foo(int y) { return y + y; } // outer foo
>> pure void bar(int x) {
>> pure int foo(int y) { return y * y; }
>> return foo(x) * .foo(x);
>> }
>>
>> Thank you,
>> bye,
>> bearophile
>
> That's true, but it seems quite difficult to get right. A pure nested
> function can in theory access immutable members in the outer function -- but
> must not access the parameters of the outer function.
> If there are no immutable members in the outer function, the compiler would
> ideally convert it into an external pure function, so that it
> doesn't need a frame pointer to the outer function. But it would need error
> messages for any use of mutable outer function members. Etc.
> It seems quite a lot of work for something of very limited use.
> Making it into a external, private pure function is almost the same.
>
>
>
why not just make it a static pure nested function? or is that no
longer proper D2 ?
Re: dmd 2.029 release
On Mon, 20 Apr 2009 16:09:09 +0900, Walter Bright
wrote:
This is a major revision to Phobos, including Andrei's revolutionary new
range support.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.029.zip
Range is so cool!
Though...
I tried following code:
void main()
{
writeln("Case1");
{
Mt19937 gen = Mt19937(0);
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln("---");
{
Mt19937 gen = Mt19937(0);
advance(gen, 1); // skip 1 element
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln("\nCase2");
{
Mt19937 gen;
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln("---");
{
Mt19937 gen;
advance(gen, 1); // skip 1 element
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
}
Result:
Case1
2357136044 (1)
2546248239 (2)
---
2546248239 (2)
3071714933 (3)
Case2
581869302 (1)
3890346734 (2)
---
581869302 (1)?
3890346734 (2)?
I think 'Case1' is correct, but 'Case2' is wrong.
Mt19937's bug?
--
tama
http://profile.livedoor.com/repeatedly/
メンバー募集中
http://tpf.techtalk.jp/
std.bigint is missing from 2.029 release
I didn't mind so much when bigint was missing from the preview, but I hoped it would be in the actual release! :0 Paul
Re: dmd 2.029 release
Walter Bright wrote: Lutger wrote: what the hell...this code can't be human. I was replaced by Colossus years ago. Michael A. Jackson wouldn't approve 1175 gotos in 113 files.
Re: dmd 2.029 release
Walter Bright wrote: Stewart Gordon wrote: Walter, how often do you update your working copy from the SVN? Obviously less than once every 2 releases. As far as I know, it is current. Everything got checked in. So how has the fix for http://d.puremagic.com/issues/show_bug.cgi?id=2580 (and probably others) not been included? Stewart.
Re: dmd 2.029 release
bearophile wrote:
Don:
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; [...]
I'm not sure that nested pure member functions should be legal.
It's not fully equivalent to moving it out of the function because once you
pull it out you add a name to the outer namespace: nested functions are useful
to keep namespaces tidy too.
So I'd like to have nested pure functions too.
pure int foo(int y) { return y + y; } // outer foo
pure void bar(int x) {
pure int foo(int y) { return y * y; }
return foo(x) * .foo(x);
}
Thank you,
bye,
bearophile
That's true, but it seems quite difficult to get right. A pure nested
function can in theory access immutable members in the outer function --
but must not access the parameters of the outer function.
If there are no immutable members in the outer function, the compiler
would ideally convert it into an external pure function, so that it
doesn't need a frame pointer to the outer function. But it would need
error messages for any use of mutable outer function members. Etc.
It seems quite a lot of work for something of very limited use.
Making it into a external, private pure function is almost the same.
Re: dmd 2.029 release
Lutger wrote: what the hell...this code can't be human. I was replaced by Colossus years ago.
ACCU conference
I'm off to speak at it! http://accu.org/index.php/conferences/accu_conference_2009/accu2009_speakers
Re: dmd 2.029 release
Don:
> Yes. Actually, marking a nested function as pure doesn't make much sense.
> It's entirely equivalent to moving it outside the function; [...]
> I'm not sure that nested pure member functions should be legal.
It's not fully equivalent to moving it out of the function because once you
pull it out you add a name to the outer namespace: nested functions are useful
to keep namespaces tidy too.
So I'd like to have nested pure functions too.
pure int foo(int y) { return y + y; } // outer foo
pure void bar(int x) {
pure int foo(int y) { return y * y; }
return foo(x) * .foo(x);
}
Thank you,
bye,
bearophile
Re: dmd 2.029 release
Don wrote:
bearophile wrote:
I have also tested the semantics of nested function purity:
import std.c.stdio: printf;
import std.conv: to;
pure int double_sqr(int x) {
pure int sqr(int y) { return y * y; }
return sqr(x) + sqr(x);
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
Compiled without inlining:
-O -release
double_sqr.sqr:
mov EAX,4[ESP]
imulEAX,EAX
ret 4
double_sqr:
L0: pushEAX
pushEAX
xor EAX,EAX
callnear ptr double_sqr.sqr
pushEAX
sub ESP,4
xor EAX,EAX
pushdword ptr 8[ESP]
callnear ptr double_sqr.sqr
add ESP,4
mov ECX,EAX
pop EAX
add EAX,ECX
pop ECX
ret
main:
L0: pushEAX
cmp dword ptr 8[ESP],2
jne L1D
mov EDX,0Ch[ESP]
mov EAX,8[ESP]
pushdword ptr 0Ch[EDX]
pushdword ptr 8[EDX]
callnear ptr to!(int)()
jmp short L22
L1D:mov EAX,0Ah
L22:callnear ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
pushEAX
pushECX
callnear ptr printf
There's one call to double_sqr but unfortunately two to double_sqr.sqr.
Bye,
bearophile
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and so
it creates inefficient and possibly buggy code.
The bug is bugzilla 2807.
I'm not sure that nested pure member functions should be legal.
And it turns out that sqr() isn't actually pure, in the same way that it
wasn't nothrow in your first example. The 'pure' marker is silently
being ignored. If you put the 'pure' at the end, you get bug 2807.
--
Re: dmd 2.029 release
bearophile wrote:
I have tried the following code:
import std.c.stdio: printf;
import std.conv: to;
nothrow pure int double_sqr(int x) { // line 4
int y, z;
nothrow void do_sqr() { y *= y; }
y = x;
do_sqr();
z += y;
y = x;
do_sqr();
z += y;
return z;
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
The compiler spits the following error:
pure_impure_test.d(4): Error: function pure_impure_test.double_sqr 'double_sqr'
is nothrow yet may throw
but I don't understand why. What are the things inside it that can throw an
exception?
Bye,
bearophile
Obviously my 2808 patch only solved one part of the problem.
It compiles if you change do_sqr to
void do_sqr() nothrow { y *= y; }
Please add a bug report to Bugzilla.
Re: dmd 2.029 release
bearophile wrote:
I have also tested the semantics of nested function purity:
import std.c.stdio: printf;
import std.conv: to;
pure int double_sqr(int x) {
pure int sqr(int y) { return y * y; }
return sqr(x) + sqr(x);
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
Compiled without inlining:
-O -release
double_sqr.sqr:
mov EAX,4[ESP]
imulEAX,EAX
ret 4
double_sqr:
L0: pushEAX
pushEAX
xor EAX,EAX
callnear ptr double_sqr.sqr
pushEAX
sub ESP,4
xor EAX,EAX
pushdword ptr 8[ESP]
callnear ptr double_sqr.sqr
add ESP,4
mov ECX,EAX
pop EAX
add EAX,ECX
pop ECX
ret
main:
L0: pushEAX
cmp dword ptr 8[ESP],2
jne L1D
mov EDX,0Ch[ESP]
mov EAX,8[ESP]
pushdword ptr 0Ch[EDX]
pushdword ptr 8[EDX]
callnear ptr to!(int)()
jmp short L22
L1D:mov EAX,0Ah
L22:callnear ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
pushEAX
pushECX
callnear ptr printf
There's one call to double_sqr but unfortunately two to double_sqr.sqr.
Bye,
bearophile
Yes. Actually, marking a nested function as pure doesn't make much sense.
It's entirely equivalent to moving it outside the function; a nested
pure function shouldn't be able to access any members of the enclosing
function, otherwise it's not pure. But DMD doesn't enforce that, and so
it creates inefficient and possibly buggy code.
I'm not sure that nested pure member functions should be legal.
Re: dmd 2.029 release
I have also tested the semantics of nested function purity:
import std.c.stdio: printf;
import std.conv: to;
pure int double_sqr(int x) {
pure int sqr(int y) { return y * y; }
return sqr(x) + sqr(x);
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
Compiled without inlining:
-O -release
double_sqr.sqr:
mov EAX,4[ESP]
imulEAX,EAX
ret 4
double_sqr:
L0: pushEAX
pushEAX
xor EAX,EAX
callnear ptr double_sqr.sqr
pushEAX
sub ESP,4
xor EAX,EAX
pushdword ptr 8[ESP]
callnear ptr double_sqr.sqr
add ESP,4
mov ECX,EAX
pop EAX
add EAX,ECX
pop ECX
ret
main:
L0: pushEAX
cmp dword ptr 8[ESP],2
jne L1D
mov EDX,0Ch[ESP]
mov EAX,8[ESP]
pushdword ptr 0Ch[EDX]
pushdword ptr 8[EDX]
callnear ptr to!(int)()
jmp short L22
L1D:mov EAX,0Ah
L22:callnear ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
pushEAX
pushECX
callnear ptr printf
There's one call to double_sqr but unfortunately two to double_sqr.sqr.
Bye,
bearophile
Re: dmd 2.029 release
Leandro Lucarella wrote: Andrei Alexandrescu, el 21 de abril a las 07:38 me escribiste: Lars T. Kyllingstad wrote: Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip This is looking very nice! I want to switch from D1 to D2, but... I don't want to sound greedy or anything, and I know others have asked for this before, but is making a 64-bit Linux version of DMD a lot of work? I would kill for a 64-bit Linux DMD. I think it could take a lot of ways of coding to a whole new level. Sean and I have also been discussing how to integrate memory-mapped files with the garbage collector. In a 64-bit environment this makes for an awesome programming model. Can you elaborate on that? Not much time, but in short: Memory-mapped files are not a pure library thing, they are core because they manipulate the address space. So they are quite like memory allocation. Unmapping files by hand is as unsafe as calling delete. So memory mapped files must be integrated with the collector: you map a file by hand, and the garbage collector closes it when there are no more references to the memory mapped for the file. The programming model is pretty cool - in 32 bit I always need to mind the address space because it's so densely populated. In 64 bits I can map all of my data files in memory and let the paging system and the garbage collector take care of the rest. Andrei
Re: dmd 2.029 release
I have tried the following code:
import std.c.stdio: printf;
import std.conv: to;
nothrow pure int double_sqr(int x) { // line 4
int y, z;
nothrow void do_sqr() { y *= y; }
y = x;
do_sqr();
z += y;
y = x;
do_sqr();
z += y;
return z;
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
The compiler spits the following error:
pure_impure_test.d(4): Error: function pure_impure_test.double_sqr 'double_sqr'
is nothrow yet may throw
but I don't understand why. What are the things inside it that can throw an
exception?
Bye,
bearophile
Re: dmd 2.029 release
Andrei Alexandrescu, el 21 de abril a las 07:38 me escribiste: > Lars T. Kyllingstad wrote: > >Walter Bright wrote: > >> > >>This is a major revision to Phobos, including Andrei's revolutionary new > >>range > >>support. > >> > >>http://www.digitalmars.com/d/2.0/changelog.html > >>http://ftp.digitalmars.com/dmd.2.029.zip > >This is looking very nice! I want to switch from D1 to D2, but... > >I don't want to sound greedy or anything, and I know others have asked for > >this > >before, but is making a 64-bit Linux version of DMD a lot of work? > > I would kill for a 64-bit Linux DMD. I think it could take a lot of ways of > coding to a whole new level. Sean and I have also been discussing how to > integrate memory-mapped files with the garbage collector. In a 64-bit > environment this makes for an awesome programming model. Can you elaborate on that? Thanks. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: dmd 2.029 release
Don:
> From 2.208:
> 2804 Impure nested functions should be legal inside pure functions
Very good. Now that little example works:
import std.c.stdio: printf;
import std.conv: to;
pure int double_sqr(int x) {
int y, z;
void do_sqr() { y *= y; }
y = x;
do_sqr();
z += y;
y = x;
do_sqr();
z += y;
return z;
}
void main(string[] args) {
int x = args.length == 2 ? to!(int)(args[1]) : 10;
int y = double_sqr(x) + double_sqr(x);
printf("4 * x * x = %d\n", y);
}
The outout is correct:
4 * x * x = 400
"Cleaned up" ASM produced by DMD V.2.029, -O -release -inline:
double_sqr:
pushEAX
mov ECX,EAX
mov [ESP],0
mov [ESP],ECX
imulEAX,[ESP]
mov EDX,EAX
mov [ESP],EAX
mov EAX,ECX
mov [ESP],ECX
imulEAX,[ESP]
add EDX,EAX
mov [ESP],EAX
mov EAX,EDX
pop ECX
ret
double_sqr.do_sqr:
mov ECX,[EAX]
imulECX,[EAX]
mov [EAX],ECX
ret
main:
L0: sub ESP,014h
cmp dword ptr 018h[ESP],2
jne L21
mov EDX,01Ch[ESP]
mov EAX,018h[ESP]
mov EAX,8[EDX]
mov EDX,0Ch[EDX]
pushEDX
pushEAX
callnear ptr parseString
jmp short L26
L21:mov EAX,0Ah
L26:callnear ptr double_sqr
add EAX,EAX
mov ECX,offset FLAT:_DATA
pushEAX
pushECX
callnear ptr printf
As you can see there's only one call to double_sqr in the main program, so the
pure semantics is working here.
You can also see do_sqr is inlined into double_sqr. But the asm code inside
double_sqr looks very hairy and long, and double_sqr itself isn't inlined in
the main.
Bye,
bearophile
Re: dmd 2.029 release
Georg Wrede, el 21 de abril a las 09:25 me escribiste: > What's sad, http://en.wikipedia.org/wiki/Standard_Template_Library > really sucks at introducing the STL on a conceptual level. Even worse, that > is > actually the only thing it *should* do. Everyting else is optional. You should improve it then =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: dmd 2.029 release
Don wrote: > Lutger wrote: >> Daniel Keep wrote: >> >> ... -Lars >>> The best bet for 64-bit D executables at this point is probably LDC; >>> dunno what the current state is, though. >>> >>> -- Daniel >> >> if you grep the dmd backend sources for x86_64, you'll get some results. >> Don't know what that means though, the source looks like magic to me! >> >> > They're just part of the standard OBJ file format. Nothing to do with > code generation. Much more fun is: > $ cd src/dmd > $ grep "goto " * -R you forgot " | less" there, what the hell...this code can't be human.
Re: dmd 2.029 release
Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip Missing from the changelog: From 2.208: 2804 Impure nested functions should be legal inside pure functions From 2.209: std.math: Intrinsics std.math.yl2x and yl2xp1 added. Improves performance of std.math.log() and similar functions (and they are now pure nothrow). (Yes, I know, not very exciting compared to Andrei's new Phobos ).
Re: dmd 2.029 release
Lutger wrote: Daniel Keep wrote: ... -Lars The best bet for 64-bit D executables at this point is probably LDC; dunno what the current state is, though. -- Daniel if you grep the dmd backend sources for x86_64, you'll get some results. Don't know what that means though, the source looks like magic to me! They're just part of the standard OBJ file format. Nothing to do with code generation. Much more fun is: $ cd src/dmd $ grep "goto " * -R
Re: dmd 2.029 release
Andrei Alexandrescu wrote: Lars T. Kyllingstad wrote: Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip This is looking very nice! I want to switch from D1 to D2, but... I don't want to sound greedy or anything, and I know others have asked for this before, but is making a 64-bit Linux version of DMD a lot of work? I would kill for a 64-bit Linux DMD. [...] Who does one have to kill to get a 64-bit compiler around here? :) But seriously, now that the language itself is stabilising, I would consider this a major priority for further development of DMD. 64 bits is the (immediate) future. -Lars
Re: dmd 2.029 release
Max Samukha wrote: On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha wrote: On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip Wicked awesome! file:///C:/dmd/html/d/phobos/std_range.html#cons http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons Looks like bug 2676 was fixed in 2.027 Thanks. I uncommented the unittest, updated the doc, and checked in. Andrei
Re: dmd 2.029 release
Lars T. Kyllingstad wrote: Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip This is looking very nice! I want to switch from D1 to D2, but... I don't want to sound greedy or anything, and I know others have asked for this before, but is making a 64-bit Linux version of DMD a lot of work? I would kill for a 64-bit Linux DMD. I think it could take a lot of ways of coding to a whole new level. Sean and I have also been discussing how to integrate memory-mapped files with the garbage collector. In a 64-bit environment this makes for an awesome programming model. Andrei
Re: dmd 2.029 release
Walter Bright wrote: > > This is a major revision to Phobos, including Andrei's revolutionary new > range support. > > http://www.digitalmars.com/d/2.0/changelog.html > http://ftp.digitalmars.com/dmd.2.029.zip Thanks so much, looking good! The lambda template parameters: very cool.
Re: dmd 2.029 release
Daniel Keep wrote: ... >> -Lars > > The best bet for 64-bit D executables at this point is probably LDC; > dunno what the current state is, though. > > -- Daniel if you grep the dmd backend sources for x86_64, you'll get some results. Don't know what that means though, the source looks like magic to me!
Re: dmd 2.029 release
Daniel Keep wrote: Lars T. Kyllingstad wrote: Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip This is looking very nice! I want to switch from D1 to D2, but... [snip] The best bet for 64-bit D executables at this point is probably LDC; dunno what the current state is, though. The state for D2 is currently "very broken", AFAIK.
Re: dmd 2.029 release
Lars T. Kyllingstad wrote:
> Walter Bright wrote:
>>
>> This is a major revision to Phobos, including Andrei's revolutionary
>> new range support.
>>
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.029.zip
>
> This is looking very nice! I want to switch from D1 to D2, but...
>
> I don't want to sound greedy or anything, and I know others have asked
> for this before, but is making a 64-bit Linux version of DMD a lot of work?
>
> I admit I don't know much about these things, and what I'm going to say
> next may not make sense at all, but here goes:
>
> x86-64 is just a superset of x86, right? Wouldn't it be possible, as a
> first step in the direction of a full-fledged x86-64 compiler, to simply
> make one that uses the same instruction set as the current DMD, but, I
> dunno, marks the executable as 64-bit (or something like that)?
> Specialisation and optimisation for the 64-bit architecture could then
> come at a later point in time.
I'm pretty sure that 64-bit code is binary incompatible with 32-bit
code. For example:
struct Foo { void* ptr; }
Is a different size for 32-bit and 64-bit code.
> I know it is possible to run the 32-bit compiler (and the executables it
> produces) on a 64-bit operating system, but it isn't possible to link
> against 64-bit libraries. This means that one has to install and
> maintain 32-bit versions of all the libraries one wants to use, and
> those are, in general, not available through the repositories of most
> 64-bit distros.
This is because the OS puts the CPU into a 32-bit compatible mode, but
it can't magic away the differences between 32-bit and 64-bit code.
> -Lars
The best bet for 64-bit D executables at this point is probably LDC;
dunno what the current state is, though.
-- Daniel
Re: dmd 2.029 release
Lars T. Kyllingstad wrote: Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip This is looking very nice! I want to switch from D1 to D2, but... I don't want to sound greedy or anything, and I know others have asked for this before, but is making a 64-bit Linux version of DMD a lot of work? I admit I don't know much about these things, and what I'm going to say next may not make sense at all, but here goes: x86-64 is just a superset of x86, right? Wouldn't it be possible, as a first step in the direction of a full-fledged x86-64 compiler, to simply make one that uses the same instruction set as the current DMD, but, I dunno, marks the executable as 64-bit (or something like that)? Specialisation and optimisation for the 64-bit architecture could then come at a later point in time. It's not quite that simple. It's not a full superset; some x86 instructions are not valid x86-64 instructions. For example, I think 'inc' was removed to make place for prefixes that set some flags for the next instruction and allow it to use the extra registers r8-r15.
Re: dmd 2.029 release
Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip This is looking very nice! I want to switch from D1 to D2, but... I don't want to sound greedy or anything, and I know others have asked for this before, but is making a 64-bit Linux version of DMD a lot of work? I admit I don't know much about these things, and what I'm going to say next may not make sense at all, but here goes: x86-64 is just a superset of x86, right? Wouldn't it be possible, as a first step in the direction of a full-fledged x86-64 compiler, to simply make one that uses the same instruction set as the current DMD, but, I dunno, marks the executable as 64-bit (or something like that)? Specialisation and optimisation for the 64-bit architecture could then come at a later point in time. I know it is possible to run the 32-bit compiler (and the executables it produces) on a 64-bit operating system, but it isn't possible to link against 64-bit libraries. This means that one has to install and maintain 32-bit versions of all the libraries one wants to use, and those are, in general, not available through the repositories of most 64-bit distros. -Lars
Re: DCat - a compact web application server in D.
Steve Teale wrote: Jacob Carlborg Wrote: Steve Teale wrote: Michel Fortin Wrote: On 2009-04-19 15:19:24 -0400, Steve Teale said: This is incomplete at this point, but there's a working example. I have to break off now and do some building work. You can find documentation and a zip file (currently it is Windows only, DMD2.026, and Phobos) at http://www.britseyeview.com/dcat/. It works with Apache2, and uses the AJP13 protocol like Tomcat. Interesting. Just as I was thinking of creating a web app in D. What's the license? -- Michel Fortin michel.for...@michelf.com http://michelf.com/ Hmm, forgot about that stuff, BSD maybe - suggest one please. I suggest Boost or zlib/libpng. I realize there are legal subtleties in all these licenses. In your view, why is Boost better than BSD? Just curious. Because with Boost you don't have to include the license when distributing a copy that is, as the license says, "machine-executable object code generated by a source language processor"
Re: dmd 2.029 release
On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha wrote: >On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright > wrote: > >> >>This is a major revision to Phobos, including Andrei's revolutionary new >>range support. >> >>http://www.digitalmars.com/d/2.0/changelog.html >>http://ftp.digitalmars.com/dmd.2.029.zip > >Wicked awesome! > >file:///C:/dmd/html/d/phobos/std_range.html#cons http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons >Looks like bug 2676 was fixed in 2.027
Re: dmd 2.029 release
On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright wrote: > >This is a major revision to Phobos, including Andrei's revolutionary new >range support. > >http://www.digitalmars.com/d/2.0/changelog.html >http://ftp.digitalmars.com/dmd.2.029.zip Wicked awesome! file:///C:/dmd/html/d/phobos/std_range.html#cons Looks like bug 2676 was fixed in 2.027
