www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.037 and 2.020 releases

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



http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.021.zip
Nov 25 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Make that 2.021, not 2.020
Nov 25 2008
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 25 Nov 2008 14:22:47 -0800, Walter Bright wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.037.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.021.zip

It would appear that Bugzilla 313 () is not really fixed yet. // --- file: sub.d --- module sub; private int iPrivate = 12; public int iPublic = 13; --------------------------------- // --- file: test.d --- import sub; void main() { int i; int j; i = sub.iPrivate; j = sub.iPublic; } -------------------- C:>dmd test sub RESULTS: Successfully compiled ** which is not what I expected as sub.iPrivate is private. // --- file: test1.d --- import sub; void main() { int i; int j; i = iPrivate; j = iPublic; } -------------------- C:>dmd test1 sub RESULTS: test1.d: module test1 sub.iPrivate is private ** which is as I expected. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Nov 25 2008
parent Derek Parnell <derek psych.ward> writes:
On Wed, 26 Nov 2008 10:51:49 +0900, Bill Baxter wrote:

 On Wed, Nov 26, 2008 at 7:40 AM, Derek Parnell <derek psych.ward> wrote:
 On Tue, 25 Nov 2008 14:22:47 -0800, Walter Bright wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.037.zip

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

It would appear that Bugzilla 313 () is not really fixed yet. // --- file: sub.d --- module sub; private int iPrivate = 12; public int iPublic = 13; ---------------------------------

Maybe the problem is just with package-less top-level modules?

Just tested that too, and it still fails to do what I expected it to do. // --- file: foo/sub.d module foo.sub; private int iPrivate = 12; public int iPublic = 13; package int iPackage = 14; //------------------------------// // --- file: test.d module test; import foo.sub; void main() { int i; int j; int k; i = foo.sub.iPrivate; j = foo.sub.iPublic; k = foo.sub.iPackage; } //------------------------------// // --- file: test1.d module test; import foo.sub; void main() { int i; int j; int k; i = iPrivate; j = iPublic; k = iPackage; } //------------------------------// C:\temp>dmd test foo/sub C:\temp>dmd test1 foo/sub test1.d: module test foo.sub.iPrivate is private C:\temp>dmd Digital Mars D Compiler v2.021 Copyright (c) 1999-2008 by Digital Mars written by Walter Bright Documentation: http://www.digitalmars.com/d/2.0/index.html -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Nov 25 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.037.zip
 
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.021.zip
 

929 & 2326 fixed in D1... scope in D2... good times... Thanks Walter, Sean & everyone else involved!
Nov 25 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Robert Fraser (fraserofthenight gmail.com)'s article
 Walter Bright wrote:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.037.zip

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

Sean & everyone else involved!

Can I just say how weird it is to not have to rush and merge changes after a DMD release? :-) Sean
Nov 25 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
1.037 compiles my dlibs fine :-) And with no other increase of exe size.

Thank you for fixing 929, ASAP I'll remove about 100-150 lines of code from my
dlibs :-)
Also thank you for 1797, a little problem, but nice to have it fixed.

I am sad reading Derek Parnell say that 313 isn't fixed yet.

From D2:
- What is module(system) Identifier; syntax?
- Added range support to foreach statement. What is this?
- >The 'this' parameter to struct member functions is now a reference type,< I
know this was discussed, but how does this change code? Does this forces to
change C code when it is ported to D? How to do such porting? Few examples of
situations may be useful.

Bye and thank you,
bearophile
Nov 25 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 1.037 compiles my dlibs fine :-) And with no other increase of exe size.
 Thank you for fixing 929, ASAP I'll remove about 100-150 lines of code from my
dlibs :-)
 Also thank you for 1797, a little problem, but nice to have it fixed.
 I am sad reading Derek Parnell say that 313 isn't fixed yet.
 From D2:
 - What is module(system) Identifier; syntax?

I think this is to tell the compiler that the module is a "system" module and therefore should be exempt from "Safe D" checking.
 - >The 'this' parameter to struct member functions is now a reference type,< I
know this was

How to do such porting? Few examples of situations may be useful. I think it only affects structs: struct S { S fn() { return *this; // old D 2.0 return this; // new D 2.0 } } Sean
Nov 25 2008
prev sibling next sibling parent "Tim M" <a b.com> writes:
On Wed, 26 Nov 2008 17:24:03 +1300, yidabu <yidabu.spam gmail.com> wrote:

 On Tue, 25 Nov 2008 19:31:25 -0500
 bearophile <bearophileHUGS lycos.com> wrote:

 1.037 compiles my dlibs fine :-) And with no other increase of exe size.

I compiled dwtx.lib by DMD 1.037, the exe size bloat from 4.3 MB to 10.6 MB

Is that 4.3M compiled with dwt aswell? Do you mean that just dmd update alone caused it to grow to 10.6M?
Nov 25 2008
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
bearophile Wrote:

 - What is module(system) Identifier; syntax?

 - Added range support to foreach statement. What is this?

 - >The 'this' parameter to struct member functions is now a reference type,< I
know this was discussed, but how does this change code? Does this forces to
change C code when it is ported to D? How to do such porting? Few examples of
situations may be useful.

I'm affraid, this breaks my resource parser struct ResourceTable { ushort Shift; //alignment shift count ResourceType* FirstType() { return cast(ResourceType*)(this+1); } }
Nov 26 2008
parent John C <johnch_atms hotmail.com> writes:
Kagamin Wrote:

 - >The 'this' parameter to struct member functions is now a reference type,< I
know this was discussed, but how does this change code? Does this forces to
change C code when it is ported to D? How to do such porting? Few examples of
situations may be useful.

I'm affraid, this breaks my resource parser struct ResourceTable { ushort Shift; //alignment shift count ResourceType* FirstType() { return cast(ResourceType*)(this+1); } }

Try this: return cast(ResourceType*)(&this + 1);
Nov 26 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Nov 26, 2008 at 9:20 AM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:
 On Wed, Nov 26, 2008 at 9:06 AM, Kagamin <spam here.lot> wrote:
 - Added range support to foreach statement. What is this?


It's the ability to use foreach on the new ranges (see std.range).
 I'm affraid, this breaks my resource parser

 struct ResourceTable
 {
        ushort Shift; //alignment shift count
        ResourceType* FirstType()
        {
                return cast(ResourceType*)(this+1);
        }
 }

return cast(ResourceType)(&this + 1);

Erm, that's cast(ResourceType*), of course ;)
Nov 26 2008
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Nov 26, 2008 at 9:06 AM, Kagamin <spam here.lot> wrote:
 - Added range support to foreach statement. What is this?


It's the ability to use foreach on the new ranges (see std.range).
 I'm affraid, this breaks my resource parser

 struct ResourceTable
 {
        ushort Shift; //alignment shift count
        ResourceType* FirstType()
        {
                return cast(ResourceType*)(this+1);
        }
 }

return cast(ResourceType)(&this + 1);
Nov 26 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Nov 26, 2008 at 7:40 AM, Derek Parnell <derek psych.ward> wrote:
 On Tue, 25 Nov 2008 14:22:47 -0800, Walter Bright wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.037.zip

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

It would appear that Bugzilla 313 () is not really fixed yet. // --- file: sub.d --- module sub; private int iPrivate = 12; public int iPublic = 13; ---------------------------------

Maybe the problem is just with package-less top-level modules? Because the change definitely created lots of errors in my code about things I was using that I didn't know were private. For one, I was using std.conv.toString in a lot of places without realizing that toString was not actually publicly aliased by std.conv. I really think it should accessible via std.conv. Why should I have to import std.string to go from some type-->string, vs std.conv when I want to go string-->type? --bb
Nov 25 2008
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 25 Nov 2008 14:22:47 -0800, Walter Bright wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.037.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.021.zip

An update to the Bugzilla 313 issue... It appears that it is fixed only with respect to accessing routines but not fixed when accessing variables. // --- file: foo/sub.d module foo.sub; private { int iPrivate = 12; int rPrivate() { return 12; } } public { int iPublic = 13; int rPublic() { return 13; } } package { int iPackage = 14; int rPackage() { return 14; } } //------------------------------// // --- file: test.d module test; import foo.sub; void main() { int i; int j; int k; i = foo.sub.iPrivate; j = foo.sub.iPublic; k = foo.sub.iPackage; i = foo.sub.rPrivate(); j = foo.sub.rPublic(); k = foo.sub.rPackage(); } //------------------------------// // --- file: test1.d module test; import foo.sub; void main() { int i; int j; int k; i = iPrivate; j = iPublic; k = iPackage; i = rPrivate(); j = rPublic(); k = rPackage(); } //------------------------------// C:\temp>dmd test foo/sub test.d(13): Error: function sub.rPrivate is not accessible from test test.d(15): Error: function sub.rPackage is not accessible from test C:\temp>dmd test1 foo/sub test1.d: module test foo.sub.iPrivate is private test1.d: module test foo.sub.rPrivate is private test1.d(13): Error: function sub.rPrivate is not accessible from test test1.d(15): Error: function sub.rPackage is not accessible from test C:\temp>dmd Digital Mars D Compiler v1.037 Copyright (c) 1999-2008 by Digital Mars written by Walter Bright Documentation: http://www.digitalmars.com/d/1.0/index.html In my opinion, both test.d and test1.d should be issuing the same error messages, and the messages from test1.d (without full name qualifications) seem to be correct. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Nov 25 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Derek Parnell:
 An update to the Bugzilla 313 issue...
 It appears that it is fixed only with respect to accessing routines but not
 fixed when accessing variables.

The important thing is that there's movement still. Because as long as the compiler keeps moving forward, there's hope that eventually all or most of the bad holes in the current type system will be fixed :-) A request to fill another small hole: this line of code: import foo; has to import the module name "foo" in the current namespace. While this other line: import foo: bar; Has to import the "bar" name in the current namespace, but not the "foo" name. This makes things more clean, and for example allows to have the name "foo" inside the module "foo" with no risk of name clash inside the head of the programmer. Bye, bearophile
Nov 25 2008
prev sibling next sibling parent yidabu <yidabu.spam gmail.com> writes:
On Tue, 25 Nov 2008 19:31:25 -0500
bearophile <bearophileHUGS lycos.com> wrote:

 1.037 compiles my dlibs fine :-) And with no other increase of exe size.

I compiled dwtx.lib by DMD 1.037, the exe size bloat from 4.3 MB to 10.6 MB -- yidabu <yidabu.spam gmail.com> http://www.dsource.org/projects/dwin D -(D Chinese): http://www.d-programming-language-china.org/ http://bbs.d-programming-language-china.org/ http://dwin.d-programming-language-china.org/ http://scite4d.d-programming-language-china.org/
Nov 25 2008
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gghtrk$65d$1 digitalmars.com...
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.037.zip



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

Nice update! The 2.021.zip contains a folder dmd/src/runtime and dmd/src/druntime.. Is one of them obsolete? Which one? L.
Nov 25 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Lionello Lunesu wrote:
 The 2.021.zip contains a folder dmd/src/runtime and dmd/src/druntime.. 
 Is one of them obsolete? Which one?

runtime is the correct one. Delete the druntime one.
Nov 25 2008
prev sibling next sibling parent yidabu <yidabu.spam gmail.com> writes:
On Wed, 26 Nov 2008 19:14:26 +1300
"Tim M" <a b.com> wrote:

 On Wed, 26 Nov 2008 17:24:03 +1300, yidabu <yidabu.spam gmail.com> wrote:
 
 On Tue, 25 Nov 2008 19:31:25 -0500
 bearophile <bearophileHUGS lycos.com> wrote:

 1.037 compiles my dlibs fine :-) And with no other increase of exe size.

I compiled dwtx.lib by DMD 1.037, the exe size bloat from 4.3 MB to 10.6 MB

Is that 4.3M compiled with dwt aswell? Do you mean that just dmd update alone caused it to grow to 10.6M?

4.3 M compiled with dwtx.lib(by dsss 0.75) dmd ...1.035, 1.036, 1.037 builded dwt or dwtx static library causes exe grow to 10.6 MB. steps to build static library: 1. create file: dwtx_static, content: -release -O -version=TANGOSVN -JD:\dwt-addons\res -JD:\dwt-samples\res -JD:\dwt-win\res -lib -ofdwtx.lib dwtx\core\commands\AbstractParameterValueConverter.d dwtx\core\commands\CategoryEvent.d dwtx\core\commands\CommandEvent.d ... 2. run command: dmd dwtx_static -- yidabu <yidabu.spam gmail.com> http://www.dsource.org/projects/dwin D -(D Chinese): http://www.d-programming-language-china.org/ http://bbs.d-programming-language-china.org/ http://dwin.d-programming-language-china.org/ http://scite4d.d-programming-language-china.org/
Nov 25 2008
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

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

It is nice that there is now a way to have non-heap-allocating delegates, but it is bad that it is a breaking change (in terms of D1 vs D2). But how does it work? If I have foo(scope void delegate()) { } will then foo({ ... }); not allocate? -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Nov 26 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Lars Ivar Igesund wrote:
 But how does it work? If I have
 
 foo(scope void delegate()) { }
 
 will then
 
 foo({ ... });
 
 not allocate?

Correct.
Nov 26 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
To test the new scoping features of D 2.021 I have used a small stressing
program, coming from this page, originally by Knuth:

http://www.rosettacode.org/wiki/Man_or_boy_test

More info:
http://en.wikipedia.org/wiki/Man_or_boy_test

My purpose is to see the D2 compiler being able to compute results up to N=25
on my PC (that has 2 GB RAM and a 32 bit operating system).

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

This is the code I have used for DMD 1.037:

import std.c.stdio: printf;

int a(int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy int x5) {
    int delegate() b;
    b = {
        k -= 1;
        return a(k, b(), x1, x2, x3, x4);
    };
    return k <= 0 ? x4 + x5 : b();
}

void main() {
    printf("%d\n", a(15, 1, -1, -1, 1, 0)); // N is 15
}

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

This is the code I have used for DMD 2.021. I was not sure how to use the
scope, so if you have improvements please tell me:

import std.c.stdio: printf;

int a(scope int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy int
x5) {
    scope int delegate() b;
    b = {
        k -= 1;
        return a(k, b(), x1, x2, x3, x4);
    };
    return k <= 0 ? x4 + x5 : b();
}

void main() {
    printf("%d\n", a(15, 1, -1, -1, 1, 0)); // N is 15
}

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

The results for higher values of N are:
k   21           22            23         24          25
A   -389695     -865609     -1922362    -4268854    -9479595

In both cases I have compiled the code with:
dmd -O -release -inline -L/STACK:1700000000 man_or_boy.d

The results:

DMD V.1.037 (exe: 168_476: bytes):
  N=24:  788 MB RAM, 3 seconds
  N=25: 1.57 GB RAM, 6.42 seconds

DMD V.2.021 (exe: 99_356 bytes):

The code was too much slow in D2, so I have stopped it. Do you know if the D2
code can be improved to have performance similar to D1 ones?

Bye,
bearophile
Nov 26 2008
next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Nov 26, 2008 at 7:34 AM, bearophile <bearophileHUGS lycos.com> wrote:
 This is the code I have used for DMD 2.021. I was not sure how to use the
scope, so if you have improvements please tell me:

 import std.c.stdio: printf;

 int a(scope int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy
int x5) {
    scope int delegate() b;
    b = {
        k -= 1;
        return a(k, b(), x1, x2, x3, x4);
    };
    return k <= 0 ? x4 + x5 : b();
 }

 The code was too much slow in D2, so I have stopped it. Do you know if the D2
code can be improved to have performance similar to D1 ones?

Can you try declaring b as a nested function instead of as a delegate literal and see if that helps? (why are you declaring it the way you are, anyway?
Nov 26 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:
 Can you try declaring b as a nested function instead of as a delegate
 literal and see if that helps?

I think that may lead to nonworking code.
 (why are you declaring it the way you are, anyway?

Here you can find explanations: http://en.wikipedia.org/wiki/Man_or_boy_test Here you can find other two versions that work, but I think the version I have shown is the more robust one (that is: able to computer up to higher N values with D1 compiler): http://www.rosettacode.org/wiki/Man_or_boy_test#D Bye, bearophile
Nov 26 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 The reason I wonder is because I would expect that the compiler is
 still allocating the delegate on the heap if you use the first syntax.
  (the second is also shorter and clearer.)

There's no reason to suspect. Just obj2asm the output and see. Furthermore, better results will come from: int b() { k -= 1; return a(k, b(), x1, x2, x3, x4); }; instead of using the delegate.
Nov 26 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 There's no reason to suspect. Just obj2asm the output and see. 
 Furthermore, better results will come from:
      int b() {
          k -= 1;
          return a(k, b(), x1, x2, x3, x4);
      };
 instead of using the delegate.

I don't fully understand what's happening, maybe I am doing something wrong, so I just report what I have seen. -------------------- With DMD 1.036 this code works up to N=25, usign almost 1.6 GB of RAM (and I think a running time of just 6.4 seconds is very little, try to do this with any dynamic language, so I was impressed by D1): // code #1 import std.c.stdio: printf; int a(int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy int x5) { int delegate() b; b = { k -= 1; return a(k, b(), x1, x2, x3, x4); }; return k <= 0 ? x4 + x5 : b(); } void main() { printf("%d\n", a(24, 1, -1, -1, 1, 0)); } -------------------- While on DMD 1.036 the following code: // code #2 import std.c.stdio: printf; int a(int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy int x5) { int b() { k -= 1; return a(k, b(), x1, x2, x3, x4); } return k <= 0 ? x4 + x5 : b(); } void main() { printf("%d\n", a(24, 1, -1, -1, 1, 0)); } Outputs at compile time: man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral1 is a nested function and cannot be accessed from a man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral2 is a nested function and cannot be accessed from a man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral3 is a nested function and cannot be accessed from a man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral4 is a nested function and cannot be accessed from a man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral5 is a nested function and cannot be accessed from a But this code works on the codepad site, that uses DMD v.1.026 (I think with Tangobos), up to N=21 (then the site goes into timeout for safety): http://codepad.org/8GtKswm8 ------------------------------ DMD v2.021 outputs the same errors with code #2. ------------------------------ DMD is able to run code #1 and the following #3: // code #3 import std.c.stdio: printf; int a(scope int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy int x5) { scope int delegate() b; b = { k -= 1; return a(k, b(), x1, x2, x3, x4); }; return k <= 0 ? x4 + x5 : b(); } void main() { printf("%d\n", a(22, 1, -1, -1, 1, 0)); } All the following compilations are done with and N=20 and: dmd -O -release -inline -L/STACK:1700000000 man_or_boy.d dmd -O -release -inline -L/STACK:1700000000 man_or_boy2.d Note: in D2 the code #1 and code #3 seem to use the same amount of RAM and time to run, 2.46 s and about 94MB RAM (N=20). The same code #1 in DMD 1.036 runs in about 0.16 s and I am not able to know how much RAM it uses (N=20). ------------------------------ ASM of code #1 compiled with DMD 1.036: _D10man_or_boy1aFiLiLiLiLiLiZi comdat assume CS:_D10man_or_boy1aFiLiLiLiLiLiZi sub ESP,0Ch push EBX mov dword ptr 8[ESP],0 mov dword ptr 0Ch[ESP],0 lea EAX,0Ch[ESP] mov ECX,offset FLAT:_D10man_or_boy1aFiLiLiLiLiLiZi12__dgliteral1MFZi mov 8[ESP],EAX mov 0Ch[ESP],ECX cmp dword ptr 03Ch[ESP],0 jg L56 mov EAX,01Ch[ESP] mov EDX,020h[ESP] mov EBX,01Ch[ESP] call EDX push EAX sub ESP,4 mov EAX,01Ch[ESP] mov EDX,020h[ESP] mov EBX,01Ch[ESP] call EDX mov ECX,EAX add ESP,4 pop EAX add EAX,ECX jmp short L62 L56: mov EAX,8[ESP] mov EDX,ECX mov EBX,8[ESP] call EDX L62: pop EBX add ESP,0Ch ret 02Ch ------------------------------ ASM of code #1 compiled with DMD 2.021: assume CS:_D10man_or_boy1aFiLiLiLiLiLiZi L0: sub ESP,0Ch push EBX push ESI push EDI push 030h call near ptr __d_allocmemory mov ESI,EAX mov dword ptr [ESI],0 mov EAX,048h[ESP] mov 4[ESI],EAX mov EDX,044h[ESP] mov EAX,040h[ESP] mov 010h[ESI],EAX mov 014h[ESI],EDX mov EDX,03Ch[ESP] mov EAX,038h[ESP] mov 018h[ESI],EAX mov 01Ch[ESI],EDX mov EDX,034h[ESP] mov EAX,030h[ESP] mov 020h[ESI],EAX mov 024h[ESI],EDX mov EDX,02Ch[ESP] mov EAX,028h[ESP] mov 028h[ESI],EAX mov 02Ch[ESI],EDX mov dword ptr 8[ESI],0 mov dword ptr 0Ch[ESI],0 mov EBX,ESI mov ECX,offset FLAT:_D10man_or_boy1aFiLiLiLiLiLiZi12__dgliteral1MFZi mov 8[ESI],EBX mov 0Ch[ESI],ECX add ESP,4 cmp dword ptr 4[ESI],0 jg L9F mov EAX,028h[ESI] mov EDX,02Ch[ESI] mov EDI,028h[ESI] call EDX push EAX sub ESP,4 mov EAX,024h[ESP] mov EDX,028h[ESP] mov EDI,024h[ESP] call EDX mov ECX,EAX add ESP,4 pop EAX add EAX,ECX jmp short LA4 L9F: mov EAX,8[ESI] call ECX LA4: pop EDI pop ESI pop EBX add ESP,0Ch ret 02Ch _D10man_or_boy1aFiLiLiLiLiLiZi ends ------------------------------ ASM of code #3 compiled with DMD 2.021: _D11man_or_boy31aFMiLiLiLiLiLiZi comdat assume CS:_D11man_or_boy31aFMiLiLiLiLiLiZi L0: sub ESP,0Ch push EBX push ESI push EDI push 030h call near ptr __d_allocmemory mov ESI,EAX mov dword ptr [ESI],0 mov EAX,048h[ESP] mov 4[ESI],EAX mov EDX,044h[ESP] mov EAX,040h[ESP] mov 010h[ESI],EAX mov 014h[ESI],EDX mov EDX,03Ch[ESP] mov EAX,038h[ESP] mov 018h[ESI],EAX mov 01Ch[ESI],EDX mov EDX,034h[ESP] mov EAX,030h[ESP] mov 020h[ESI],EAX mov 024h[ESI],EDX mov EDX,02Ch[ESP] mov EAX,028h[ESP] mov 028h[ESI],EAX mov 02Ch[ESI],EDX mov dword ptr 8[ESI],0 mov dword ptr 0Ch[ESI],0 mov EBX,ESI mov ECX,offset FLAT:_D11man_or_boy31aFMiLiLiLiLiLiZi12__dgliteral1MFZi mov 8[ESI],EBX mov 0Ch[ESI],ECX add ESP,4 cmp dword ptr 4[ESI],0 jg L9F mov EAX,028h[ESI] mov EDX,02Ch[ESI] mov EDI,028h[ESI] call EDX push EAX sub ESP,4 mov EAX,024h[ESP] mov EDX,028h[ESP] mov EDI,024h[ESP] call EDX mov ECX,EAX add ESP,4 pop EAX add EAX,ECX jmp short LA4 L9F: mov EAX,8[ESI] call ECX LA4: pop EDI pop ESI pop EBX add ESP,0Ch ret 02Ch _D11man_or_boy31aFMiLiLiLiLiLiZi ends ------------------------------ Bye, bearophile
Nov 26 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Wed, 26 Nov 2008 17:02:54 -0500, bearophile wrote:

 While on DMD 1.036 the following code:
 
 // code #2
 import std.c.stdio: printf;
 
 int a(int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy int x5) {
     int b() {
         k -= 1;
         return a(k, b(), x1, x2, x3, x4);
     }
     return k <= 0 ? x4 + x5 : b();
 }
 
 void main() {
     printf("%d\n", a(24, 1, -1, -1, 1, 0));
 }
 
 Outputs at compile time:
 
 man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral1 is a nested function
and cannot be accessed from a
 man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral2 is a nested function
and cannot be accessed from a
 man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral3 is a nested function
and cannot be accessed from a
 man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral4 is a nested function
and cannot be accessed from a
 man_or_boy2.d(6): delegate man_or_boy2.a.b.__dgliteral5 is a nested function
and cannot be accessed from a
 
 But this code works on the codepad site, that uses DMD v.1.026 (I think with
Tangobos), up to N=21 (then the site goes into timeout for safety):
 http://codepad.org/8GtKswm8

[snip]
 All the following compilations are done with and N=20 and:
 dmd -O -release -inline -L/STACK:1700000000 man_or_boy.d
 dmd -O -release -inline -L/STACK:1700000000 man_or_boy2.d

Remove -inline from your compiler options, and #2 compiles and runs faster in both D1 and D2 than #1. lazy seems to do something funny when -inline is in effect.
Nov 26 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:
 Remove -inline from your compiler options, and #2 compiles and runs
 faster in both D1 and D2 than #1.
 lazy seems to do something funny when -inline is in effect.

You are right, I have tested it on D1. I think the codepad doesn't use -inline, that's why #2 works there. #2 also uses less RAM on D1, for example N=24 requires about 707 MB instead of 788 MB, and about 2.8 s instead of about 3 s. Sergey Gromov:
 Remove -inline from your compiler options, and #2 compiles and runs
 faster in both D1 and D2 than #1.
 lazy seems to do something funny when -inline is in effect.

You are right, I have tested it on D1. I think the codepad doesn't use -inline, that's why #2 works there. #2 also uses less RAM on D1, for example N=24 requires about 710 MB instead of 788 MB, and about 2.8 s instead of about 3 s. This is the Asm of the #2 compiled with D1 with -O -release, it's shorter still (but note there are some other parts that I don't show here): _D11man_or_boy21aFiLiLiLiLiLiZi comdat assume CS:_D11man_or_boy21aFiLiLiLiLiLiZi L0: push EAX push EBX cmp dword ptr 034h[ESP],0 jg L33 mov EAX,014h[ESP] mov EDX,018h[ESP] mov EBX,014h[ESP] call EDX push EAX sub ESP,4 mov EAX,014h[ESP] mov EDX,018h[ESP] mov EBX,014h[ESP] call EDX mov ECX,EAX add ESP,4 pop EAX add EAX,ECX jmp short L3C L33: lea EAX,4[ESP] call near ptr _D11man_or_boy21aFiLiLiLiLiLiZi1bMFZi L3C: pop EBX pop ECX ret 02Ch _D11man_or_boy21aFiLiLiLiLiLiZi ends -------------------------- I have then tested #1 and #2 without -inline on D2, and the results are very different from each other: #1 is very slow and uses lot of memory, while #2 (that contains no scope) acts as D1, using "only" 707 MB with N=24 and working with n=25 too. The asm code is similar the one I have just shown here. So compiling #2 witout -inline in D2 fulfulls my original desire of computing up to N=25 with D2 :-) I presume the -inline uncovers a small bug of DMD, that will be fixed. But what interests me more now is to understand how to write such fast code in general in D2. Bye, bearophile
Nov 26 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Wed, 26 Nov 2008 18:19:38 -0500, bearophile wrote:

 So compiling #2 witout -inline in D2 fulfulls my original desire of
 computing up to N=25 with D2 :-)
 
 I presume the -inline uncovers a small bug of DMD, that will be fixed.

I think so, too.
 But what interests me more now is to understand how to write such
 fast code in general in D2.

Seems like right now delegates are stack allocated only if they're passed directly as scope parameters. Assigning a delegate to a variable is always considered escaping, even if it's a local scope variable. This is probably because scope for declarations is something completely different than scope for arguments.
Nov 26 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 So my suspicion is correct, then?  That is:
 
 scope int delegate() b;
 b = { ... };
 
 Will allocate on the heap?

Yes. The scope for delegates takes effect as a parameter storage class, not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.
Nov 27 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Jarrett Billingsley wrote:
 So my suspicion is correct, then?  That is:

 scope int delegate() b;
 b = { ... };

 Will allocate on the heap?

Yes. The scope for delegates takes effect as a parameter storage class, not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.

Why? It would be useful to allow local scope delegates. The compiler can just forbid passing the delegate to a function which does not declare its parameter as scope. I assume the compiler knows a variable is scope since it must prevent escape of the delegate, no? So just use that information. I thought that was the point of all this... -Steve
Nov 27 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Jarrett Billingsley wrote:
 So my suspicion is correct, then?  That is:

 scope int delegate() b;
 b = { ... };

 Will allocate on the heap?

not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.

Why? It would be useful to allow local scope delegates. The compiler can just forbid passing the delegate to a function which does not declare its parameter as scope. I assume the compiler knows a variable is scope since it must prevent escape of the delegate, no? So just use that information. I thought that was the point of all this...

In order to make that work, the compiler would have to do full escape analysis, which is a lot of work to implement.
Nov 27 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 In order to make that work, the compiler would have to do full escape 
 analysis, which is a lot of work to implement.

But the D2 programmer may enjoy some ways to state what he/she/shi wants anyway, like in a cast, to make the compiler behave like the D1 compiler and avoid a slowdown. And such ways have to be intuitive enough to use. Bye, bearophile
Nov 27 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Jarrett Billingsley wrote:
 So my suspicion is correct, then?  That is:

 scope int delegate() b;
 b = { ... };

 Will allocate on the heap?

not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.

Why? It would be useful to allow local scope delegates. The compiler can just forbid passing the delegate to a function which does not declare its parameter as scope. I assume the compiler knows a variable is scope since it must prevent escape of the delegate, no? So just use that information. I thought that was the point of all this...

In order to make that work, the compiler would have to do full escape analysis, which is a lot of work to implement.

Maybe I've misunderstood the point of declaring a delegate parameter scope. Take the following example: void delegate(int) global_dg; void foo(void delegate(int) dg) { global_dg = dg; } void foo2(scope void delegate(int) dg) { dg(5); } void bar(scope void delegate(int) dg) { foo(dg); // should this compile? foo2(dg); // should this compile? } void baz() { int y; void dg(int x) { y += x; } bar(&dg); } Should bar's call to foo compile? If it does, then the benefit of having scope delegates is just a hint to the compiler that "I know what I'm doing". If it fails to compile the call to foo, what about the call to foo2? If that fails to compile, then this is a common convention (forwarding a delegate) that will cause lots of problems in existing correct code. If the call to foo2 should work, I don't see the difference between the above example and this: void baz2() { int y; void dg(int x) { y += x; } scope void delegate(int) dg2 = &dg; bar(dg2); } That is, if you can tell that a delegate is scope or not scope when it's being passed to another function, then why can't the compiler use that information when the delegate is assigned to another scope delegate? No full escape analysis is needed. -Steve
Dec 01 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 1 Dec 2008 14:10:27 -0500, Steven Schveighoffer wrote:

 "Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Jarrett Billingsley wrote:
 So my suspicion is correct, then?  That is:

 scope int delegate() b;
 b = { ... };

 Will allocate on the heap?

not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.

Why? It would be useful to allow local scope delegates. The compiler can just forbid passing the delegate to a function which does not declare its parameter as scope. I assume the compiler knows a variable is scope since it must prevent escape of the delegate, no? So just use that information. I thought that was the point of all this...

In order to make that work, the compiler would have to do full escape analysis, which is a lot of work to implement.

Maybe I've misunderstood the point of declaring a delegate parameter scope. Take the following example: void delegate(int) global_dg; void foo(void delegate(int) dg) { global_dg = dg; } void foo2(scope void delegate(int) dg) { dg(5); } void bar(scope void delegate(int) dg) { foo(dg); // should this compile? foo2(dg); // should this compile? } void baz() { int y; void dg(int x) { y += x; } bar(&dg); } Should bar's call to foo compile?

It compiles.
 If it does, then the benefit of having 
 scope delegates is just a hint to the compiler that "I know what I'm doing".

Yes, seems like for now it's just a hint. No checking is done. The problem is, the declaration: scope var = ...; means something completely different from void foo(scope void delegate() dg); foo(...); The former defines a scoped instance of a class. Ideally it should fail if used with any non-class type because it makes no sense with non-classes. The latter defines a delegate in a non-escaping context. Currently such definition is possible only as a parameter to a function call. If delegate is defined in a non-escaping context, it gets a stack closure. If it is defined as a scoped instance of a class... well, it makes no sense, so the scope is ignored and the delegate is created as usual, with a heap-allocated closure.
Dec 04 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sergey Gromov" wrote
 Mon, 1 Dec 2008 14:10:27 -0500, Steven Schveighoffer wrote:

 "Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Jarrett Billingsley wrote:
 So my suspicion is correct, then?  That is:

 scope int delegate() b;
 b = { ... };

 Will allocate on the heap?

class, not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.

Why? It would be useful to allow local scope delegates. The compiler can just forbid passing the delegate to a function which does not declare its parameter as scope. I assume the compiler knows a variable is scope since it must prevent escape of the delegate, no? So just use that information. I thought that was the point of all this...

In order to make that work, the compiler would have to do full escape analysis, which is a lot of work to implement.

Maybe I've misunderstood the point of declaring a delegate parameter scope. Take the following example: void delegate(int) global_dg; void foo(void delegate(int) dg) { global_dg = dg; } void foo2(scope void delegate(int) dg) { dg(5); } void bar(scope void delegate(int) dg) { foo(dg); // should this compile? foo2(dg); // should this compile? } void baz() { int y; void dg(int x) { y += x; } bar(&dg); } Should bar's call to foo compile?

It compiles.

I meant, should it compile in the final incarnation of this feature.
 If it does, then the benefit of having
 scope delegates is just a hint to the compiler that "I know what I'm 
 doing".

Yes, seems like for now it's just a hint. No checking is done. The problem is, the declaration: scope var = ...; means something completely different from void foo(scope void delegate() dg); foo(...); The former defines a scoped instance of a class. Ideally it should fail if used with any non-class type because it makes no sense with non-classes.

I was proposing to MAKE scope var = &dg mean what I said it should mean. I am not talking about the current spec.
 The latter defines a delegate in a non-escaping context.  Currently such
 definition is possible only as a parameter to a function call.

Currently being the key word here ;)
 If delegate is defined in a non-escaping context, it gets a stack
 closure.  If it is defined as a scoped instance of a class... well, it
 makes no sense, so the scope is ignored and the delegate is created as
 usual, with a heap-allocated closure.

It makes sense. A scope variable doesn't escape it's scope. Why should this be limited to classes? In fact, the scope delegate versus non-scope delegate is 100% analogous to scope classes versus non-scope classes. My point in all this is Walter is saying it cannot be done, when in fact it can, and should be easy to determine, assuming that the eventual goal of this feature is to prevent scope delegate escapes. Without knowing which delegates are scope and which are not is very important to escape analysis. Even partial escape analysis. If the compiler can't determine that, then all this does is give a hint to the compiler, which isn't very useful at all, and seems half-ass in the face of all the other great features D2 is creating. -Steve
Dec 04 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Brad Roberts:
 Walter, this is yet more evidence that shows that accepting and ignoring 
 these sorts of modifiers is the wrong thing to do.  Accepting dubious 
 definitions like 'public private int foo' and the above make life harder 
 than it needs to be.

I agree. What's the rationale behind accepting things and later ignoring them? (Maybe to allow a different D compiler to compile code even if can't manage every one of those modifiers?) Bye, bearophile
Nov 27 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 Accepting dubious 
 definitions like 'public private int foo' and the above make life harder 
 than it needs to be.

The code: public private int foo; produces the error message: test.d(1): redundant protection attribute
Nov 28 2008
prev sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Thu, 27 Nov 2008, Walter Bright wrote:

 Jarrett Billingsley wrote:
 So my suspicion is correct, then?  That is:
 
 scope int delegate() b;
 b = { ... };
 
 Will allocate on the heap?

Yes. The scope for delegates takes effect as a parameter storage class, not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.

Walter, this is yet more evidence that shows that accepting and ignoring these sorts of modifiers is the wrong thing to do. Accepting dubious definitions like 'public private int foo' and the above make life harder than it needs to be. Later, Brad
Nov 27 2008
prev sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
Robert Jacques wrote:
 Just as a point of reference (in D1)
 scope Object a = new Object(); // Stack Allocated
 scope Object b;
 b = new Object(); // Heap Allocated
 
 So there may be some merit to scope int b() { .. } vs scope int b(); b = 
 {...}

I can't find any spec on exactly how scope works, but this makes 100% sense to me. Let me explain the way that I think scope does/might/should work: The thing to remember is that "scope" is *not* transitive. Scope limits the most shallow reference, *not* not anything deeper. It is perfectly valid to have a scope pointer to a non-scope thing. The point of scope is to enforce that the pointer cannot escape; it does not say anything about whether the pointed-to object escapes or not. The point then, is that you can create a non-scope object, and assign it to a scope pointer. When you do something like: BEGIN CODE scope <type> a; a = <allocate thing>; END CODE ...you are doing exactly that. (At least, that's how I think it ought to work.)
Dec 01 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 01 Dec 2008 10:26:31 -0700, Russell Lewis wrote:

 The thing to remember is that "scope" is *not* transitive.  Scope limits 
 the most shallow reference, *not* not anything deeper.  It is perfectly 
 valid to have a scope pointer to a non-scope thing.  The point of scope 
 is to enforce that the pointer cannot escape; it does not say anything 
 about whether the pointed-to object escapes or not.
 
 The point then, is that you can create a non-scope object, and assign it 
 to a scope pointer.  When you do something like:
 
 BEGIN CODE
 	scope <type> a;
 	a = <allocate thing>;
 END CODE
 
 ...you are doing exactly that.
 
 (At least, that's how I think it ought to work.)

http://www.digitalmars.com/d/1.0/attribute.html#scope Originally, the scope keyword wasn't about escaping, it was about memory management. The code scope C c = new C; was a sugar for C c =new C; scope(exit) delete c; The spec says, "Assignment to a scope, other than initialization, is not allowed." Therefore your example is illegal. I think the fact that DMD accepts such a code is a bug. I'll file a bug report.
Dec 01 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Nov 26, 2008 at 11:07 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Can you try declaring b as a nested function instead of as a delegate
 literal and see if that helps?

I think that may lead to nonworking code.

Uh, why? You are declaring the delegate as 'scope', yes? Meaning you don't expect the delegate to be allocated on the heap? Why don't you try it and see what happens instead of arguing?
 (why are you declaring it the way you are, anyway?

Here you can find explanations: http://en.wikipedia.org/wiki/Man_or_boy_test Here you can find other two versions that work, but I think the version I have shown is the more robust one (that is: able to computer up to higher N values with D1 compiler): http://www.rosettacode.org/wiki/Man_or_boy_test#D

I don't really care about what test it is. I'm just confused why you're doing: scope int delegate() b; b = { .. }; instead of: scope int b() { .. } The reason I wonder is because I would expect that the compiler is still allocating the delegate on the heap if you use the first syntax. (the second is also shorter and clearer.)
Nov 26 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
bearophile wrote:
 To test the new scoping features of D 2.021 I have used a small stressing
program, coming from this page, originally by Knuth:
 
 http://www.rosettacode.org/wiki/Man_or_boy_test
 
 More info:
 http://en.wikipedia.org/wiki/Man_or_boy_test
 
 My purpose is to see the D2 compiler being able to compute results up to N=25
on my PC (that has 2 GB RAM and a 32 bit operating system).
 
 ---------------------------
 
 This is the code I have used for DMD 1.037:
 
 import std.c.stdio: printf;
 
 int a(int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy int x5) {
     int delegate() b;
     b = {
         k -= 1;
         return a(k, b(), x1, x2, x3, x4);
     };
     return k <= 0 ? x4 + x5 : b();
 }
 
 void main() {
     printf("%d\n", a(15, 1, -1, -1, 1, 0)); // N is 15
 }
 
 ---------------------------
 
 This is the code I have used for DMD 2.021. I was not sure how to use the
scope, so if you have improvements please tell me:
 
 import std.c.stdio: printf;
 
 int a(scope int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy
int x5) {
     scope int delegate() b;
     b = {
         k -= 1;
         return a(k, b(), x1, x2, x3, x4);
     };
     return k <= 0 ? x4 + x5 : b();
 }
 
 void main() {
     printf("%d\n", a(15, 1, -1, -1, 1, 0)); // N is 15
 }
 
 ---------------------------
 
 The results for higher values of N are:
 k   21           22            23         24          25
 A   -389695     -865609     -1922362    -4268854    -9479595
 
 In both cases I have compiled the code with:
 dmd -O -release -inline -L/STACK:1700000000 man_or_boy.d
 
 The results:
 
 DMD V.1.037 (exe: 168_476: bytes):
   N=24:  788 MB RAM, 3 seconds
   N=25: 1.57 GB RAM, 6.42 seconds
 
 DMD V.2.021 (exe: 99_356 bytes):
 
 The code was too much slow in D2, so I have stopped it. Do you know if the D2
code can be improved to have performance similar to D1 ones?
 
 Bye,
 bearophile

Try marking all the "lazy" parameters as "scope" ("lazy" creates delegates).
Nov 26 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
Wed, 26 Nov 2008 20:33:35 +0000 (UTC), Jesse Phillips wrote:

 On Wed, 26 Nov 2008 12:18:27 -0800, Robert Fraser wrote:
 Try marking all the "lazy" parameters as "scope" ("lazy" creates
 delegates).

From change log: "The lazy storage class now implies scope so that lazy arguments won't trigger a heap allocated closure."

Also, the whole point of this test is delegate propagation. That's what makes it interesting.
Nov 26 2008
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 26 Nov 2008 12:18:27 -0800, Robert Fraser wrote:

 bearophile wrote:
 To test the new scoping features of D 2.021 I have used a small
 stressing program, coming from this page, originally by Knuth:
 
 http://www.rosettacode.org/wiki/Man_or_boy_test
 
 More info:
 http://en.wikipedia.org/wiki/Man_or_boy_test
 
 My purpose is to see the D2 compiler being able to compute results up
 to N=25 on my PC (that has 2 GB RAM and a 32 bit operating system).
 
 ---------------------------
 
 This is the code I have used for DMD 1.037:
 
 import std.c.stdio: printf;
 
 int a(int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4, lazy
 int x5) {
     int delegate() b;
     b = {
         k -= 1;
         return a(k, b(), x1, x2, x3, x4);
     };
     return k <= 0 ? x4 + x5 : b();
 }
 
 void main() {
     printf("%d\n", a(15, 1, -1, -1, 1, 0)); // N is 15
 }
 
 ---------------------------
 
 This is the code I have used for DMD 2.021. I was not sure how to use
 the scope, so if you have improvements please tell me:
 
 import std.c.stdio: printf;
 
 int a(scope int k, lazy int x1, lazy int x2, lazy int x3, lazy int x4,
 lazy int x5) {
     scope int delegate() b;
     b = {
         k -= 1;
         return a(k, b(), x1, x2, x3, x4);
     };
     return k <= 0 ? x4 + x5 : b();
 }
 
 void main() {
     printf("%d\n", a(15, 1, -1, -1, 1, 0)); // N is 15
 }
 
 ---------------------------
 
 The results for higher values of N are: k   21           22           
 23         24          25 A   -389695     -865609     -1922362   
 -4268854    -9479595
 
 In both cases I have compiled the code with: dmd -O -release -inline
 -L/STACK:1700000000 man_or_boy.d
 
 The results:
 
 DMD V.1.037 (exe: 168_476: bytes):
   N=24:  788 MB RAM, 3 seconds
   N=25: 1.57 GB RAM, 6.42 seconds
 
 DMD V.2.021 (exe: 99_356 bytes):
 
 The code was too much slow in D2, so I have stopped it. Do you know if
 the D2 code can be improved to have performance similar to D1 ones?
 
 Bye,
 bearophile

Try marking all the "lazy" parameters as "scope" ("lazy" creates delegates).

From change log: "The lazy storage class now implies scope so that lazy arguments won't trigger a heap allocated closure."
Nov 26 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Nov 26, 2008 at 4:13 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 The reason I wonder is because I would expect that the compiler is
 still allocating the delegate on the heap if you use the first syntax.
  (the second is also shorter and clearer.)

There's no reason to suspect. Just obj2asm the output and see.

That'd be great if I had it. I don't want to get into that, though.
 Furthermore,
 better results will come from:

    int b() {
        k -= 1;
        return a(k, b(), x1, x2, x3, x4);
    };

 instead of using the delegate.

So my suspicion is correct, then? That is: scope int delegate() b; b = { ... }; Will allocate on the heap?
Nov 26 2008
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 26 Nov 2008 13:24:57 -0500, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:
 scope int b() { .. }

 The reason I wonder is because I would expect that the compiler is
 still allocating the delegate on the heap if you use the first syntax.
  (the second is also shorter and clearer.)

Just as a point of reference (in D1) scope Object a = new Object(); // Stack Allocated scope Object b; b = new Object(); // Heap Allocated So there may be some merit to scope int b() { .. } vs scope int b(); b = {...}
Nov 26 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
27.11.08 в 01:12 Robert Jacques в своём письме писал(а):

 On Wed, 26 Nov 2008 13:24:57 -0500, Jarrett Billingsley  
 <jarrett.billingsley gmail.com> wrote:
 scope int b() { .. }

 The reason I wonder is because I would expect that the compiler is
 still allocating the delegate on the heap if you use the first syntax.
  (the second is also shorter and clearer.)

Just as a point of reference (in D1) scope Object a = new Object(); // Stack Allocated scope Object b; b = new Object(); // Heap Allocated So there may be some merit to scope int b() { .. } vs scope int b(); b = {...}

If so, then why all the three usages 1) scope Object a; 2) scope Object a = b; 3) scope Object a = new Object(); are allowed when only 3rd one stack-allocates? I believe only third one should be allowed unless scope analisys is implemented (in its very basic form, at least): scope Object a1 = new Object(); // ok Object a2 = a1; // not ok scope Object a3 = a1; // ok; return a1; // not ok return a2; // ok
Nov 26 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
2008/11/25 Walter Bright <newshound1 digitalmars.com>:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.037.zip



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

I want to say thank you for taking the community's requests into account when fixing the bugs for this release. I can't tell you how happy it makes me to see some of these fixed. I hope this keeps up ;)
Nov 26 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 I can't tell you how happy it makes me to see some of these fixed.

We aim to please <g>.
Nov 26 2008
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Great release, thank you!
Nov 26 2008
prev sibling parent reply Spacen Jasset <spacenjasset yahoo.co.uk> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.037.zip
 
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.021.zip
 

right. I get the impression that no so many people are using the phobos library these days, and won't notice such things.
Nov 28 2008
next sibling parent reply Spacen Jasset <spacenjasset yahoo.co.uk> writes:
I don't really consider this bug to be fixed in 1.037 and I have added 
comments explaining why. The bug has been marked as fixed though without 
any explanation as to why the shading mode (windows) and permissions 
(linux) are to be left as they are.
Dec 08 2008
parent reply torhu <no spam.invalid> writes:
Spacen Jasset wrote:
 I don't really consider this bug to be fixed in 1.037 and I have added 
 comments explaining why. The bug has been marked as fixed though without 
 any explanation as to why the shading mode (windows) and permissions 
 (linux) are to be left as they are.
 

Tango also opens files for writing with shared reading disabled by default. I'm not sure why, but maybe someone can remember the reason for it.
Dec 08 2008
parent reply Kagamin <spam here.lot> writes:
torhu Wrote:

 Tango also opens files for writing with shared reading disabled by 
 default.  I'm not sure why, but maybe someone can remember the reason 
 for it.

they just forgot? :)
Dec 08 2008
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-12-08 19:06:42 +0100, Kagamin <spam here.lot> said:

 torhu Wrote:
 
 Tango also opens files for writing with shared reading disabled by
 default.  I'm not sure why, but maybe someone can remember the reason
 for it.

they just forgot? :)

consistency with windows as far as I know, so the program behaves the same on windows and unix. Fawzi
Dec 09 2008
next sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-12-09 11:10:33 +0100, Fawzi Mohamed <fmohamed mac.com> said:

 On 2008-12-08 19:06:42 +0100, Kagamin <spam here.lot> said:
 
 torhu Wrote:
 
 Tango also opens files for writing with shared reading disabled by
 default.  I'm not sure why, but maybe someone can remember the reason
 for it.

they just forgot? :)

consistency with windows as far as I know, so the program behaves the same on windows and unix. Fawzi

Anyway you can try to file a ticket to change the default if you want...
Dec 09 2008
prev sibling parent reply Spacen Jasset <spacenjasset yahoo.co.uk> writes:
Fawzi Mohamed wrote:
 On 2008-12-08 19:06:42 +0100, Kagamin <spam here.lot> said:
 
 torhu Wrote:

 Tango also opens files for writing with shared reading disabled by
 default.  I'm not sure why, but maybe someone can remember the reason
 for it.

they just forgot? :)

consistency with windows as far as I know, so the program behaves the same on windows and unix. Fawzi

know of. The Linux implementation is in my opinion certainly incorrect.
Dec 09 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Spacen Jasset wrote:

 Fawzi Mohamed wrote:
 On 2008-12-08 19:06:42 +0100, Kagamin <spam here.lot> said:
 
 torhu Wrote:

 Tango also opens files for writing with shared reading disabled by
 default.  I'm not sure why, but maybe someone can remember the reason
 for it.

they just forgot? :)

consistency with windows as far as I know, so the program behaves the same on windows and unix. Fawzi

know of. The Linux implementation is in my opinion certainly incorrect.

On Windows, the "default" is not shared in the sense that that is what you get if you pass no specific sharing parameters (0). I'm not windows expert, but if I read the CreateFile docs correctly, having some form of sharing as default can be wrong (causing errors) in some cases? On Posix, the situation is quite different in that sharing is default. In fact non-sharing is not enforced by the system such that it is up to the application to figure out whether it should stay away or not. I believe there is room for improvement, but I'm not sure the default should be different? -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Dec 10 2008
parent Kagamin <spam here.lot> writes:
Lars Ivar Igesund Wrote:

 I'm not windows expert, but if I read the CreateFile docs correctly, having
some form of sharing as default can be wrong (causing errors) in some cases?

if fact errors happen when two applications (or even the same application) try to get exclusive (default) access to the same file.
Dec 10 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 08 Dec 2008 18:35:32 +0300, torhu <no spam.invalid> wrote:

 Spacen Jasset wrote:
 I don't really consider this bug to be fixed in 1.037 and I have added  
 comments explaining why. The bug has been marked as fixed though  
 without any explanation as to why the shading mode (windows) and  
 permissions (linux) are to be left as they are.

Tango also opens files for writing with shared reading disabled by default. I'm not sure why, but maybe someone can remember the reason for it.

Yeah, just hit by this one :( (can't read program log until it is finished)
Dec 08 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 08 Dec 2008 18:35:32 +0300, torhu <no spam.invalid> wrote:

 Spacen Jasset wrote:
 I don't really consider this bug to be fixed in 1.037 and I have added  
 comments explaining why. The bug has been marked as fixed though  
 without any explanation as to why the shading mode (windows) and  
 permissions (linux) are to be left as they are.

Tango also opens files for writing with shared reading disabled by default. I'm not sure why, but maybe someone can remember the reason for it.

Yeah, just hit by this one :( (can't read program log until it is finished)
Dec 08 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 10 Dec 2008 14:12:13 +0300, Lars Ivar Igesund <larsivar igesund.net>
wrote:

 Spacen Jasset wrote:

 Fawzi Mohamed wrote:
 On 2008-12-08 19:06:42 +0100, Kagamin <spam here.lot> said:

 torhu Wrote:

 Tango also opens files for writing with shared reading disabled by
 default.  I'm not sure why, but maybe someone can remember the reason
 for it.

they just forgot? :)

consistency with windows as far as I know, so the program behaves the same on windows and unix. Fawzi

know of. The Linux implementation is in my opinion certainly incorrect.

On Windows, the "default" is not shared in the sense that that is what you get if you pass no specific sharing parameters (0). I'm not windows expert, but if I read the CreateFile docs correctly, having some form of sharing as default can be wrong (causing errors) in some cases? On Posix, the situation is quite different in that sharing is default. In fact non-sharing is not enforced by the system such that it is up to the application to figure out whether it should stay away or not. I believe there is room for improvement, but I'm not sure the default should be different?

First of all, behaviour should be consistent across all platforms. Second, FILE_SHARE_READ is completely safe. There won't be any problems if you write sequentially, i.e. rarely seek back and rewrite what you already wrote (and this covers more than 90% of use cases). I wont cause any problems in the latter case, too (application won't crash, handle gets invalidated or anything, but reading application should take additional care to re-read file entirely sometimes to stay up to date).
Dec 10 2008