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 reply "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
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


 929 & 2326 fixed in D1... scope in D2... good times... Thanks Walter,
 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


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 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 reply 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
parent reply "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
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 parent reply Kagamin <spam here.lot> writes:
bearophile Wrote:


 - What is module(system) Identifier; syntax?


I think, module(safe) was meant, docs mention module(safe).


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


Good question, because what is called foreach range statement was implemented
long ago.


 - >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
next sibling 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?


 Good question, because what is called foreach range statement was implemented
long ago.


 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?


 Good question, because what is called foreach range statement was implemented
long ago.


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 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 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 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
parent reply "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
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 "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
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?


 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...


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?


 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...


 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?


 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...


 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?


 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...


 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 parent reply 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
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 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):


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:


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

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



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




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


to run, 2.46 s and about 94MB RAM (N=20).


how much RAM it uses (N=20).

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


_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
		
------------------------------


	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

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


_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:
 

 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





lazy seems to do something funny when -inline is in effect.
Nov 26 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sergey Gromov:



 lazy seems to do something funny when -inline is in effect.


You are right, I have tested it on D1.


788 MB, and about 2.8 s instead of about 3 s.

Sergey Gromov:



 lazy seems to do something funny when -inline is in effect.


You are right, I have tested it on D1.



788 MB, and about 2.8 s instead of about 3 s.


(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

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



(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.

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:



 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 parent reply "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
next 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 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 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 reply 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
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 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 next 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
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
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 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
 


Its not consistent with any other libraries of any other compilers I 
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
 


 Its not consistent with any other libraries of any other compilers I
 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
next sibling 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 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


 Its not consistent with any other libraries of any other compilers I
 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
prev sibling parent reply Pablo Ripolles <in-call gmx.net> writes:
Hello,

did anybody installed DMD 2.021 successfully in GNU/Linux?

I get lots of similar errors such as the following, whenever I try to build a
plain "hello world".
/usr/local/lib/phobos/std/c/stdio.d(200): Error: identifier 'va_list' is not
defined
/usr/local/lib/phobos/std/c/stdio.d(200): Error: va_list is used as a type
/usr/local/lib/phobos/std/c/stdio.d(200): Error: cannot have parameter of type
void

My /etc/dmd.conf has:
DFLAGS=-I/usr/local/lib/druntime/import -I/usr/local/lib/phobos

I installed as root with:
install -p -m 0755 dmd/bin/dmd dmd/bin/obj2asm dmd/bin/dumpobj dmd/bin/rdmd
/usr/local/bin/
install -p -m 0644 dmd/lib/libdruntime.a dmd/lib/libphobos2.a /usr/local/lib/
(cd dmd/src/druntime/; find -name '*.d' | xargs tar -c) | (cd
/usr/local/lib/druntime/; tar -xv)
(cd dmd/src/druntime/; find -name '*.di' | xargs tar -c) | (cd
/usr/local/lib/druntime/; tar -xv)
(cd dmd/src/phobos/; find -name '*.d' | xargs tar -c) | (cd
/usr/local/lib/phobos/; tar -xv)

Any idea of what I'm missing?

By the way, I followed the same procedure with DMD 1.037 and it did work.

Thanks a lot!


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
Nov 29 2008
parent reply Pablo Ripolles <in-call gmx.net> writes:
I've been following the same procedure (mutatis mutandi) with versions 2.020
and 2.019, only the latter worked.  Clearly there must be some issue related
with the druntime lib which I am missing in the installation procedure.  Any
idea? 

Cheers!


Pablo Ripolles Wrote:


 Hello,
 
 did anybody installed DMD 2.021 successfully in GNU/Linux?
 
 I get lots of similar errors such as the following, whenever I try to build a
plain "hello world".
 /usr/local/lib/phobos/std/c/stdio.d(200): Error: identifier 'va_list' is not
defined
 /usr/local/lib/phobos/std/c/stdio.d(200): Error: va_list is used as a type
 /usr/local/lib/phobos/std/c/stdio.d(200): Error: cannot have parameter of type
void
 
 My /etc/dmd.conf has:
 DFLAGS=-I/usr/local/lib/druntime/import -I/usr/local/lib/phobos
 
 I installed as root with:
 install -p -m 0755 dmd/bin/dmd dmd/bin/obj2asm dmd/bin/dumpobj dmd/bin/rdmd
/usr/local/bin/
 install -p -m 0644 dmd/lib/libdruntime.a dmd/lib/libphobos2.a /usr/local/lib/
 (cd dmd/src/druntime/; find -name '*.d' | xargs tar -c) | (cd
/usr/local/lib/druntime/; tar -xv)
 (cd dmd/src/druntime/; find -name '*.di' | xargs tar -c) | (cd
/usr/local/lib/druntime/; tar -xv)
 (cd dmd/src/phobos/; find -name '*.d' | xargs tar -c) | (cd
/usr/local/lib/phobos/; tar -xv)
 
 Any idea of what I'm missing?
 
 By the way, I followed the same procedure with DMD 1.037 and it did work.
 
 Thanks a lot!
 
 
 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
Nov 30 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Pablo Ripolles wrote:

 I've been following the same procedure (mutatis mutandi) with
 versions 2.020 and 2.019, only the latter worked.  Clearly there must
 be some issue related with the druntime lib which I am missing in the
 installation procedure.  Any idea?


I don't know what's going wrong with your setup. But the first thing is 
to fix DFLAGS so that the phobos comes before druntime, as phobos should 
be searched first.
Nov 30 2008
parent reply Pablo Ripolles <in-call gmx.net> writes:
Walter Bright Wrote:


 Pablo Ripolles wrote:

 I've been following the same procedure (mutatis mutandi) with
 versions 2.020 and 2.019, only the latter worked.  Clearly there must
 be some issue related with the druntime lib which I am missing in the
 installation procedure.  Any idea?


 
 I don't know what's going wrong with your setup. But the first thing is 
 to fix DFLAGS so that the phobos comes before druntime, as phobos should 
 be searched first.


Yes indeed! that was it!

It would be nice not to forget to update the install docs such as in
http://www.digitalmars.com/d/2.0/dmd-linux.html (there is no comment about
druntime stuff at all).

Something esle, there is this dmd.conf.5 man page which is deployed in man1
directory of the dmd zip file.  Shouldn't it be in a new man5 diretory?  again,
shouldn't it have renamed its internal number (the one that appears in the
header when you type "man dmd.conf" such as DMD.CONF(1)) to DMD.CONF(5)?

Walter, thank you very much.
Dec 01 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Pablo Ripolles wrote:

 It would be nice not to forget to update the install docs such as in
 http://www.digitalmars.com/d/2.0/dmd-linux.html (there is no comment
 about druntime stuff at all).
 
 Something esle, there is this dmd.conf.5 man page which is deployed
 in man1 directory of the dmd zip file.  Shouldn't it be in a new man5
 diretory?  again, shouldn't it have renamed its internal number (the
 one that appears in the header when you type "man dmd.conf" such as
 DMD.CONF(1)) to DMD.CONF(5)?


I don't know. I don't know much about man files.


 Walter, thank you very much.
Dec 01 2008
parent Pablo Ripolles <in-call gmx.net> writes:
Walter Bright Wrote:


 Pablo Ripolles wrote:

 It would be nice not to forget to update the install docs such as in
 http://www.digitalmars.com/d/2.0/dmd-linux.html (there is no comment
 about druntime stuff at all).
 
 Something else, there is this dmd.conf.5 man page which is deployed
 in man1 directory of the dmd zip file.  Shouldn't it be in a new man5
 directory?  again, shouldn't it have renamed its internal number (the
 one that appears in the header when you type "man dmd.conf" such as
 DMD.CONF(1)) to DMD.CONF(5)?


 
 I don't know. I don't know much about man files.




Ok, I don't know much about man files either.  However here is the reasoning.

The man pages are structured in sections and section 1 contains descriptions of
"Executable programs or shell commands" while section 5 takes care of "File
formats and conventions".


*A typical example of the *first* case would be the gfortran executable, its
man file can be found in:

pablo baobab:~$ ls -al /usr/share/man/man1/ | grep gfortran
lrwxrwxrwx  1 root root    17 2008-11-26 16:12 gfortran.1.gz ->
gfortran-4.3.1.gz
-rw-r--r--  1 root root 13215 2008-09-28 18:02 gfortran-4.3.1.gz

which is in man1 and carries the 1 in its file name.  Moreover its man page
displays (1) on the top:

GFORTRAN(1)                           GNU                          GFORTRAN(1)

NAME
       gfortran - GNU Fortran compiler

SYNOPSIS
       gfortran [-c|-S|-E]
                [-g] [-pg] [-Olevel]
                [-Wwarn...] [-pedantic]
                [-Idir...] [-Ldir...]
                [-Dmacro[=defn]...] [-Umacro]
                [-foption...]        [-mmachine-option...]
                [-o outfile] infile...

       Only the most useful options are listed here; see below for the
       remainder.


*A typical example of the *second* case would be the xorg.conf config file, its
man file can be found in:

pablo baobab:~$ ls -al /usr/share/man/man5/ | grep xorg
-rw-r--r--  1 root root 17453 2008-11-15 17:57 xorg.conf.5.gz

which is in man5 and carries the 5 in its file name.  Moreover its man page
displays (5) on the top:

xorg.conf(5)                                                      xorg.conf(5)

NAME
       xorg.conf - configuration File for Xorg X server

INTRODUCTION
       Xorg  supports several mechanisms for supplying/obtaining configuration
       and run-time parameters: command line options,  environment  variables,

All this is just a matter of consistency, not very important obviously, nice
however.


Cheers!
Dec 02 2008