www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD workforce contribution

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I want to donate my time to DMD's development team.
I've already forked the repo from GitHub and done all necessary setup.
Any suggestions where should I start and how could i get work items
assigned to me?
Nov 07 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2011 12:37 AM, Gor Gyolchanyan wrote:
 I want to donate my time to DMD's development team.
 I've already forked the repo from GitHub and done all necessary setup.
 Any suggestions where should I start and how could i get work items
 assigned to me?

What kind of things are you interested in working on?
Nov 07 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2011 1:19 AM, Gor Gyolchanyan wrote:
 I'm not quite familiar with DMD's internals, so the best answer would
 be "whatever is more important to do".

I take it you want to work on DMD itself, then! 1. Making shared libraries under Linux work would be a big improvement. 2. Another would be to investigate the Dwarf symbolic debug outfit and make dmd's output work well in gdb. 3. Run the dmd test suite under Linux with gcc's coverage analyzer turned on. Add test cases to cover dmd source code that is not tested. 4. There are many static analyzers on the market. Try compiling dmd with one or more of them, and propose fixes. 5. Go through the Bugzilla unresolved issues, pick what interests you, and propose patches to fix them. 6. Investigate popular benchmarks (such as the "shootout"). Compare the native code generated by dmd with that of C or C++, and identify inefficient code sequences. 7. Install NetBSD or OpenBSD, and port dmd to them.
Nov 07 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-07 10:51, Walter Bright wrote:
 On 11/7/2011 1:19 AM, Gor Gyolchanyan wrote:
 I'm not quite familiar with DMD's internals, so the best answer would
 be "whatever is more important to do".

I take it you want to work on DMD itself, then! 1. Making shared libraries under Linux work would be a big improvement. 2. Another would be to investigate the Dwarf symbolic debug outfit and make dmd's output work well in gdb. 3. Run the dmd test suite under Linux with gcc's coverage analyzer turned on. Add test cases to cover dmd source code that is not tested. 4. There are many static analyzers on the market. Try compiling dmd with one or more of them, and propose fixes. 5. Go through the Bugzilla unresolved issues, pick what interests you, and propose patches to fix them. 6. Investigate popular benchmarks (such as the "shootout"). Compare the native code generated by dmd with that of C or C++, and identify inefficient code sequences. 7. Install NetBSD or OpenBSD, and port dmd to them.

8. Port dmd to ARM. -- /Jacob Carlborg
Nov 07 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-11-07 13:21, Trass3r wrote:
 8. Port dmd to ARM.

One should rather work on gdc than trying to port dmd to ARM.

That's a good idea as well. -- /Jacob Carlborg
Nov 07 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-11-07 13:36, Gor Gyolchanyan wrote:
 1. Making shared libraries under Linux work would be a big improvement.

I think you meant "Making shared libraries, written in D, under Linux work would be a big improvement.", because everything else works fine (i tested it) using core.sys.posix.dlfn; Since druntime needs some serious initialization, core.sys.windows.dll was invented to hide away all this and, if I'm not mistaken, this is precisely what it means to "support DLLs". since .so files don't have any auto-called functions, like DllMain, some additional shenanigans are required to get it to work as in Windows. There will still be helper functions that would be put inside some "main" function in .so functions, that should be called explicitly when loaded (probably inside a standard library loader). DllMain also has thread/process attach/detach routine callbacks, which are, AFAIK, are not necessary to simulate in .so files (otherwise, it'll go inside that pseudo-main function). Regarding the above information, all I have to do to make "shared libraries work under linux" is to make linux analogs for the dll helper functions, define the pseudo-main function requirement in D docs and make a specialization of LoadLibrary routine in druntime to call that function. I have a question regarding the general approach to shared libraries in D: Should we really use obsolete C library formats and jump through lots of hoops to work around the limitations? AFAIK, currently "DLL support" is purely an optional druntime feature, that allows one to quickly initialize druntime from DllMain by using the functions for attaching/detaching a thread/process. I understand, the GC, some handlers (like exception handler) as well as any other things i don't know about should be properly initialized. The problem is, that .so files in ELF format don't have anything similar. In order to make the two consistent some common logic should be developed on how does D treat

There is a GCC extension available for this: __attribute__((constructor)) http://stackoverflow.com/questions/2053029/how-exactly-does-attribute-constructor-work Oh, BTW, generating PIC needs to be fixed first. In addition to the GCC attribute Mac OS X also have a couple of low level functions for working with the dynamic linker: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/dyld.3.html Don't know if there's something similar available on Linux. -- /Jacob Carlborg
Nov 07 2011
prev sibling next sibling parent bcs <bcs example.com> writes:
On 11/07/2011 04:33 AM, Steven Schveighoffer wrote:
 On Mon, 07 Nov 2011 04:51:57 -0500, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 11/7/2011 1:19 AM, Gor Gyolchanyan wrote:
 I'm not quite familiar with DMD's internals, so the best answer would
 be "whatever is more important to do".

I take it you want to work on DMD itself, then! 1. Making shared libraries under Linux work would be a big improvement. 2. Another would be to investigate the Dwarf symbolic debug outfit and make dmd's output work well in gdb. 3. Run the dmd test suite under Linux with gcc's coverage analyzer turned on. Add test cases to cover dmd source code that is not tested. 4. There are many static analyzers on the market. Try compiling dmd with one or more of them, and propose fixes. 5. Go through the Bugzilla unresolved issues, pick what interests you, and propose patches to fix them. 6. Investigate popular benchmarks (such as the "shootout"). Compare the native code generated by dmd with that of C or C++, and identify inefficient code sequences. 7. Install NetBSD or OpenBSD, and port dmd to them.

9. (8 was already spoken for :) Improve DDOC. This might actually be a good way to learn how the code is represented internally (speaking from complete ignorance).

9+n: Improve the documentation?
 -Steve

Nov 07 2011
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 07.11.2011 13:36, Gor Gyolchanyan wrote:
 1. Making shared libraries under Linux work would be a big improvement.

I think you meant "Making shared libraries, written in D, under Linux work would be a big improvement.", because everything else works fine (i tested it) using core.sys.posix.dlfn; Since druntime needs some serious initialization, core.sys.windows.dll was invented to hide away all this and, if I'm not mistaken, this is precisely what it means to "support DLLs". since .so files don't have any auto-called functions, like DllMain, some additional shenanigans are required to get it to work as in Windows. There will still be helper functions that would be put inside some "main" function in .so functions, that should be called explicitly when loaded (probably inside a standard library loader). DllMain also has thread/process attach/detach routine callbacks, which are, AFAIK, are not necessary to simulate in .so files (otherwise, it'll go inside that pseudo-main function). Regarding the above information, all I have to do to make "shared libraries work under linux" is to make linux analogs for the dll helper functions, define the pseudo-main function requirement in D docs and make a specialization of LoadLibrary routine in druntime to call that function.

There are different ways to use and implement shared libraries written in D: 1. the shared library interfaces to any other library as a C library does, i.e. without any shared resources (e.g. it has its own heap and its own thread list). 2. the shared library shares resources with other libraries and the executable. The DLL support on windows covers the first case. I think such a shared library should work in any host application, even if it is not aware that it is written in D. There is limited support for the second case that only forwards calls to the GC into another shared library, but it won't work with other resources or in a multi threading environment. Some attempts have been made to put the phobos runtime library into a shared library on Windows (and OSX): http://d.puremagic.com/issues/show_bug.cgi?id=4071
Nov 07 2011
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
There is the DDL project with that approach: 
http://www.dsource.org/projects/ddl/wiki

I think that a programming language that declares itself as a "System 
Language" should be able to build and use native shared libraries.

On 08.11.2011 07:32, Gor Gyolchanyan wrote:
 Is there any ready plan, that will describe what exactly do we want to
 get in the end?
 I'm starting to think, that it would be great to have our own format
 for shared libraries.

 On Tue, Nov 8, 2011 at 10:25 AM, Rainer Schuetze<r.sagitario gmx.de>  wrote:
 On 07.11.2011 13:36, Gor Gyolchanyan wrote:
 1. Making shared libraries under Linux work would be a big improvement.

I think you meant "Making shared libraries, written in D, under Linux work would be a big improvement.", because everything else works fine (i tested it) using core.sys.posix.dlfn; Since druntime needs some serious initialization, core.sys.windows.dll was invented to hide away all this and, if I'm not mistaken, this is precisely what it means to "support DLLs". since .so files don't have any auto-called functions, like DllMain, some additional shenanigans are required to get it to work as in Windows. There will still be helper functions that would be put inside some "main" function in .so functions, that should be called explicitly when loaded (probably inside a standard library loader). DllMain also has thread/process attach/detach routine callbacks, which are, AFAIK, are not necessary to simulate in .so files (otherwise, it'll go inside that pseudo-main function). Regarding the above information, all I have to do to make "shared libraries work under linux" is to make linux analogs for the dll helper functions, define the pseudo-main function requirement in D docs and make a specialization of LoadLibrary routine in druntime to call that function.

There are different ways to use and implement shared libraries written in D: 1. the shared library interfaces to any other library as a C library does, i.e. without any shared resources (e.g. it has its own heap and its own thread list). 2. the shared library shares resources with other libraries and the executable. The DLL support on windows covers the first case. I think such a shared library should work in any host application, even if it is not aware that it is written in D. There is limited support for the second case that only forwards calls to the GC into another shared library, but it won't work with other resources or in a multi threading environment. Some attempts have been made to put the phobos runtime library into a shared library on Windows (and OSX): http://d.puremagic.com/issues/show_bug.cgi?id=4071


Nov 07 2011
parent reply Don <nospam nospam.com> writes:
On 08.11.2011 10:40, Gor Gyolchanyan wrote:
 I think that a programming language that declares itself as a "System
Language" should be able to build and use native shared libraries.

You're completely right. Just as D supports extern(C) to support C-function, it should support C-libraries. But this doesn't mean, that this is the way it should work always. At the end, all shared libraries are always usable, because they need a C API and D can interface with C APIs. There can even be neat high-level wrappers around those APIs to ease the access to C shared libraries. But I think encouraging programmers to wrote _new_ libraries in _D_ using those shared library formats is a bad idea. Too many workarounds, too much danger.
 There is the DDL project with that approach:
http://www.dsource.org/projects/ddl/wiki

I knew about DDL a long time ago. But it's D1 only and doesn't seem to be willing to add D2 support. If and when it supports D2, I'll take a look at it, test it for various traits and if it passes the tests I'll make a pull request to add it to Phobos.

Last serious update seems to be 4 years ago. D2 barely existed back then.
Nov 08 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-11-08 11:32, Don wrote:
 On 08.11.2011 10:40, Gor Gyolchanyan wrote:
 I think that a programming language that declares itself as a "System
 Language" should be able to build and use native shared libraries.

You're completely right. Just as D supports extern(C) to support C-function, it should support C-libraries. But this doesn't mean, that this is the way it should work always. At the end, all shared libraries are always usable, because they need a C API and D can interface with C APIs. There can even be neat high-level wrappers around those APIs to ease the access to C shared libraries. But I think encouraging programmers to wrote _new_ libraries in _D_ using those shared library formats is a bad idea. Too many workarounds, too much danger.
 There is the DDL project with that approach:
 http://www.dsource.org/projects/ddl/wiki

I knew about DDL a long time ago. But it's D1 only and doesn't seem to be willing to add D2 support. If and when it supports D2, I'll take a look at it, test it for various traits and if it passes the tests I'll make a pull request to add it to Phobos.

Last serious update seems to be 4 years ago. D2 barely existed back then.

There's a fork available that is a bit more recent: http://h3.gd/devlog/?p=12 -- /Jacob Carlborg
Nov 08 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I'm not quite familiar with DMD's internals, so the best answer would
be "whatever is more important to do".

On Mon, Nov 7, 2011 at 1:09 PM, Walter Bright
<newshound2 digitalmars.com> wrote:
 On 11/7/2011 12:37 AM, Gor Gyolchanyan wrote:
 I want to donate my time to DMD's development team.
 I've already forked the repo from GitHub and done all necessary setup.
 Any suggestions where should I start and how could i get work items
 assigned to me?

What kind of things are you interested in working on?

Nov 07 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-11-07 09:37, Gor Gyolchanyan wrote:
 I want to donate my time to DMD's development team.
 I've already forked the repo from GitHub and done all necessary setup.
 Any suggestions where should I start and how could i get work items
 assigned to me?

Have a look at the reported issues for DMD: http://d.puremagic.com/issues/ And start with the issues that have most votes, or something like that. -- /Jacob Carlborg
Nov 07 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Thanks for the info!
I'll start with bugzilla and see where it goes.
Nov 07 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Given how much often I find this problem in D coding, is someone willing and
able to write a patch to allow code like this (it's in Bugzilla, with normal
priority)?


const struct Foo {
    const int[5] a;
    const int[] b;
    const int[int] aa;
    this(in int n) pure {
        this.a[] = n; // line 6
        this.b = new int[5];
        this.b[0] = n; // line 8
        this.aa[1] = 2; // line 9
    }
}
void main() {}


The latest DMD gives:

test.d(6): Error: slice this.a[] is not mutable
test.d(8): Error: this.b[0] isn't mutable
test.d(9): Error: this.aa[1] isn't mutable

Bye,
bearophile
Nov 07 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/07/2011 11:57 AM, Jonathan M Davis wrote:
 That would be altering aa, which isn't legal. const variables can be
 initialized but _can't_ be assigned to. If you want to do something fancier
 than a simple initialization, you're going to need to create another array
 which you do everything to and _then_ initialize the const array with that.
 The errors that you're running into are completely by design.

What bearophile is asking for is to treat those cases like an initialization (what they, in fact, are) rather than like an assignment.
Nov 07 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/07/2011 05:13 PM, Gor Gyolchanyan wrote:
 I think the problem arises because in order for this to be fully safe,
 the constructor needs to be called before the object is allocated (by
 making an always-writable temporary) because otherwise the members
 could end up in ROM and physically immutable to the constructor.

 On Mon, Nov 7, 2011 at 8:08 PM, Timon Gehr<timon.gehr gmx.ch>  wrote:
 On 11/07/2011 11:57 AM, Jonathan M Davis wrote:
 That would be altering aa, which isn't legal. const variables can be
 initialized but _can't_ be assigned to. If you want to do something
 fancier
 than a simple initialization, you're going to need to create another array
 which you do everything to and _then_ initialize the const array with
 that.
 The errors that you're running into are completely by design.

What bearophile is asking for is to treat those cases like an initialization (what they, in fact, are) rather than like an assignment.


No. Things don't 'end up in ROM' the compiler puts them there. Afaik, currently, only static immutable data ends up there. And even then that is not real ROM, it is just an OS-enforced convention. That is really not the issue here. What makes the implementation non-trivial is the fact that the compiler would have to enforce in some conservative way that upon exit of the constructor only one reference to the dynamic array exists. Initalization of immutable members is somewhat moot anyways, consider this: import std.stdio; immutable(int)* p; void foo(){ // checks if values pointed to by p are really immutable static int[immutable(int)*] mem; if(p !in mem) mem[p] = *p; else assert(mem[p] == *p); // fail. } struct Foo{ immutable int x; this(int y){ p=&x; foo(); x=1; foo(); } } void main(){ auto foo=Foo(2); } I think the current initialization semantics are not restrictive enough.
Nov 07 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2011 4:57 AM, kenji hara wrote:
 I have call this concept "transitively modifiable", and I have
 implemented it with dmd/pull/166.

For those who don't yet know, Kenji is a very prolific and high quality contributor to dmd.
Nov 08 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/8/11 11:17 AM, Brad Anderson wrote:
 On Tue, Nov 8, 2011 at 1:52 AM, Walter Bright
 <newshound2 digitalmars.com <mailto:newshound2 digitalmars.com>>wrote:

     On 11/7/2011 4:57 AM, kenji hara wrote:

         I have call this concept "transitively modifiable", and I have
         implemented it with dmd/pull/166.


     For those who don't yet know, Kenji is a very prolific and high
     quality contributor to dmd.


 About half of the currently open dmd pull requests are from him (34 of
 69).  Very prolific is right.

I swear I met a guy who knows Kenji. He exists!! Andrei
Nov 08 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 07, 2011 05:49:52 bearophile wrote:
 Given how much often I find this problem in D coding, is someone willing and
 able to write a patch to allow code like this (it's in Bugzilla, with
 normal priority)?
 
 
 const struct Foo {
     const int[5] a;
     const int[] b;
     const int[int] aa;
     this(in int n) pure {
         this.a[] = n; // line 6
         this.b = new int[5];
         this.b[0] = n; // line 8
         this.aa[1] = 2; // line 9
     }
 }
 void main() {}
 
 
 The latest DMD gives:
 
 test.d(6): Error: slice this.a[] is not mutable
 test.d(8): Error: this.b[0] isn't mutable
 test.d(9): Error: this.aa[1] isn't mutable

I don't think that any of those are _supposed_ to work. When dealing with a const or immutable variable, it can only be initialized, not assigned to. For this.a[] = n; you're assigning all of the elements of n to all of the corresponding elements in a. That's an assignment, so of course it doesn't work. If you want to copy the array, then use this.a = n.dup; or this.a = n.idup; For this.b[0] you're assigning an element in the array. It's const, so that's not legal. The same goes with this.aa[1] = 2; That would be altering aa, which isn't legal. const variables can be initialized but _can't_ be assigned to. If you want to do something fancier than a simple initialization, you're going to need to create another array which you do everything to and _then_ initialize the const array with that. The errors that you're running into are completely by design. - Jonathan M Davis
Nov 07 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 The errors that you're running into are completely by design.

I see, thank you for your (and Steven's) answers. Isn't it possible to see unassigned constant array attributes as mutable just inside their struct/class constructor (and allow the code I've shown)? It's handy because often I just need to initialize them in the constructor, and later I don't need to change them any more. ------------------------- Steven Schveighoffer:
 Line 8 is invalid, because a const member is only allowed to be  
 initialized *once* in a constructor.

Is this a DMD bug then (this compiles and runs)? const struct Foo { const int y; this(in int x) pure { y = x; y = x + x; } } void main() { auto f = Foo(5); } In the following program Foo1 and Foo2 are not allowed, while Foo3 is allowed. Is this a good design? They seem similar enough cases to me. const struct Foo1 { const int[1] a; this(in int x) pure { a[0] = x; // Error } } const struct Foo2 { const int[1] a; this(in int x) pure { a = [x]; // Error } } const struct Foo3 { const int a; this(in int x) pure { a = x; // OK } } void main() {} Bye, bearophile
Nov 07 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 8. Port dmd to ARM.

One should rather work on gdc than trying to port dmd to ARM.
Nov 07 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 Nov 2011 05:49:52 -0500, bearophile <bearophileHUGS lycos.com>  
wrote:

 Given how much often I find this problem in D coding, is someone willing  
 and able to write a patch to allow code like this (it's in Bugzilla,  
 with normal priority)?


 const struct Foo {
     const int[5] a;
     const int[] b;
     const int[int] aa;
     this(in int n) pure {
         this.a[] = n; // line 6
         this.b = new int[5];
         this.b[0] = n; // line 8
         this.aa[1] = 2; // line 9
     }
 }
 void main() {}


 The latest DMD gives:

 test.d(6): Error: slice this.a[] is not mutable
 test.d(8): Error: this.b[0] isn't mutable
 test.d(9): Error: this.aa[1] isn't mutable

Of those, I think the only one which should be fixed is line 6. Line 8 is invalid, because a const member is only allowed to be initialized *once* in a constructor. Line 9 I think is not conceptually invalid, but you aren't *assigning* aa, you are using aa. I would expect this to be valid: this.aa = [1:2]; -Steve
Nov 07 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 Nov 2011 04:51:57 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 11/7/2011 1:19 AM, Gor Gyolchanyan wrote:
 I'm not quite familiar with DMD's internals, so the best answer would
 be "whatever is more important to do".

I take it you want to work on DMD itself, then! 1. Making shared libraries under Linux work would be a big improvement. 2. Another would be to investigate the Dwarf symbolic debug outfit and make dmd's output work well in gdb. 3. Run the dmd test suite under Linux with gcc's coverage analyzer turned on. Add test cases to cover dmd source code that is not tested. 4. There are many static analyzers on the market. Try compiling dmd with one or more of them, and propose fixes. 5. Go through the Bugzilla unresolved issues, pick what interests you, and propose patches to fix them. 6. Investigate popular benchmarks (such as the "shootout"). Compare the native code generated by dmd with that of C or C++, and identify inefficient code sequences. 7. Install NetBSD or OpenBSD, and port dmd to them.

9. (8 was already spoken for :) Improve DDOC. This might actually be a good way to learn how the code is represented internally (speaking from complete ignorance). -Steve
Nov 07 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
 1. Making shared libraries under Linux work would be a big improvement.

I think you meant "Making shared libraries, written in D, under Linux work would be a big improvement.", because everything else works fine (i tested it) using core.sys.posix.dlfn; Since druntime needs some serious initialization, core.sys.windows.dll was invented to hide away all this and, if I'm not mistaken, this is precisely what it means to "support DLLs". since .so files don't have any auto-called functions, like DllMain, some additional shenanigans are required to get it to work as in Windows. There will still be helper functions that would be put inside some "main" function in .so functions, that should be called explicitly when loaded (probably inside a standard library loader). DllMain also has thread/process attach/detach routine callbacks, which are, AFAIK, are not necessary to simulate in .so files (otherwise, it'll go inside that pseudo-main function). Regarding the above information, all I have to do to make "shared libraries work under linux" is to make linux analogs for the dll helper functions, define the pseudo-main function requirement in D docs and make a specialization of LoadLibrary routine in druntime to call that function. I have a question regarding the general approach to shared libraries in D: Should we really use obsolete C library formats and jump through lots of hoops to work around the limitations? AFAIK, currently "DLL support" is purely an optional druntime feature, that allows one to quickly initialize druntime from DllMain by using the functions for attaching/detaching a thread/process. I understand, the GC, some handlers (like exception handler) as well as any other things i don't know about should be properly initialized. The problem is, that .so files in ELF format don't have anything similar. In order to make the two consistent some common logic should be developed on how does D treat On Mon, Nov 7, 2011 at 1:51 PM, Walter Bright <newshound2 digitalmars.com> wrote:
 On 11/7/2011 1:19 AM, Gor Gyolchanyan wrote:
 I'm not quite familiar with DMD's internals, so the best answer would
 be "whatever is more important to do".

I take it you want to work on DMD itself, then! 1. Making shared libraries under Linux work would be a big improvement. 2. Another would be to investigate the Dwarf symbolic debug outfit and make dmd's output work well in gdb. 3. Run the dmd test suite under Linux with gcc's coverage analyzer turned on. Add test cases to cover dmd source code that is not tested. 4. There are many static analyzers on the market. Try compiling dmd with one or more of them, and propose fixes. 5. Go through the Bugzilla unresolved issues, pick what interests you, and propose patches to fix them. 6. Investigate popular benchmarks (such as the "shootout"). Compare the native code generated by dmd with that of C or C++, and identify inefficient code sequences. 7. Install NetBSD or OpenBSD, and port dmd to them.

Nov 07 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
good point. Is there any API docs for DMD i can read?
If not, can you recommend what parts of DMD's code i should start
reading from for an optimal understanding?

On Mon, Nov 7, 2011 at 4:33 PM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 On Mon, 07 Nov 2011 04:51:57 -0500, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 11/7/2011 1:19 AM, Gor Gyolchanyan wrote:
 I'm not quite familiar with DMD's internals, so the best answer would
 be "whatever is more important to do".

I take it you want to work on DMD itself, then! 1. Making shared libraries under Linux work would be a big improvement. 2. Another would be to investigate the Dwarf symbolic debug outfit and make dmd's output work well in gdb. 3. Run the dmd test suite under Linux with gcc's coverage analyzer turne=


 on. Add test cases to cover dmd source code that is not tested.

 4. There are many static analyzers on the market. Try compiling dmd with
 one or more of them, and propose fixes.

 5. Go through the Bugzilla unresolved issues, pick what interests you, a=


 propose patches to fix them.

 6. Investigate popular benchmarks (such as the "shootout"). Compare the
 native code generated by dmd with that of C or C++, and identify ineffic=


 code sequences.

 7. Install NetBSD or OpenBSD, and port dmd to them.

9. (8 was already spoken for :) =A0Improve DDOC. =A0This might actually b=

 good way to learn how the code is represented internally (speaking from
 complete ignorance).

 -Steve

Nov 07 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Mon, 07 Nov 2011 14:38:33 +0200, Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com> wrote:

 good point. Is there any API docs for DMD i can read?

This might be what you're looking for: http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Nov 07 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
This is PRECISELY what i was looking for! Thanks a bunch! :-)

On Mon, Nov 7, 2011 at 4:44 PM, Vladimir Panteleev
<vladimir thecybershadow.net> wrote:
 On Mon, 07 Nov 2011 14:38:33 +0200, Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com> wrote:

 good point. Is there any API docs for DMD i can read?

This might be what you're looking for: http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide -- Best regards, =A0Vladimir =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mailto=


Nov 07 2011
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
2011/11/7 bearophile <bearophileHUGS lycos.com>:
 Given how much often I find this problem in D coding, is someone willing =

ormal priority)? The filed issue is here. http://d.puremagic.com/issues/show_bug.cgi?id=3D6174
 const struct Foo {
 =A0 =A0const int[5] a;
 =A0 =A0const int[] b;
 =A0 =A0const int[int] aa;
 =A0 =A0this(in int n) pure {
 =A0 =A0 =A0 =A0this.a[] =3D n; // line 6
 =A0 =A0 =A0 =A0this.b =3D new int[5];
 =A0 =A0 =A0 =A0this.b[0] =3D n; // line 8
 =A0 =A0 =A0 =A0this.aa[1] =3D 2; // line 9
 =A0 =A0}
 }
 void main() {}


 The latest DMD gives:

 test.d(6): Error: slice this.a[] is not mutable
 test.d(8): Error: this.b[0] isn't mutable
 test.d(9): Error: this.aa[1] isn't mutable

 Bye,
 bearophile

Only line 6 should be allowed. Inside constructor, compiler can detect that this.a[n] is part of the fields of 'this' (because static array is value type), then should allow to bypass const type checking for assignment. But dynamic array and associative array are reference type, then compiler cannot detect that the elements of them (this.b[n] and this.aa[key]) are part of 'this'. Therefore line 8 and 9 cannot bypass const type checking, even if inside constructor, then should be rejected. I have call this concept "transitively modifiable", and I have implemented it with dmd/pull/166. "Transitively modifiable" is only checked inside constructor, and allow more flexible initializing. I think this is reasonable improvement. Kenji Hara.
Nov 07 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 Nov 2011 07:59:08 -0500, bearophile <bearophileHUGS lycos.com>  
wrote:

 Jonathan M Davis:

 The errors that you're running into are completely by design.

I see, thank you for your (and Steven's) answers. Isn't it possible to see unassigned constant array attributes as mutable just inside their struct/class constructor (and allow the code I've shown)? It's handy because often I just need to initialize them in the constructor, and later I don't need to change them any more. ------------------------- Steven Schveighoffer:
 Line 8 is invalid, because a const member is only allowed to be
 initialized *once* in a constructor.

Is this a DMD bug then (this compiles and runs)? const struct Foo { const int y; this(in int x) pure { y = x; y = x + x; } } void main() { auto f = Foo(5); }

I would say yes, though I supposed the compiler may be able to take leeway and prove that the y = x line is not needed. If it compiles at all, I think it would be implementation defined.
 In the following program Foo1 and Foo2 are not allowed, while Foo3 is  
 allowed. Is this a good design? They seem similar enough cases to me.


 const struct Foo1 {
     const int[1] a;
     this(in int x) pure {
         a[0] = x; // Error
     }
 }
 const struct Foo2 {
     const int[1] a;
     this(in int x) pure {
         a = [x]; // Error
     }
 }
 const struct Foo3 {
     const int a;
     this(in int x) pure {
         a = x; // OK
     }
 }
 void main() {}

I agree all of these should be valid. I think the ever-impressive Kenji Hara is working on that case. -Steve
Nov 07 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I think the problem arises because in order for this to be fully safe,
the constructor needs to be called before the object is allocated (by
making an always-writable temporary) because otherwise the members
could end up in ROM and physically immutable to the constructor.

On Mon, Nov 7, 2011 at 8:08 PM, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 11/07/2011 11:57 AM, Jonathan M Davis wrote:
 That would be altering aa, which isn't legal. const variables can be
 initialized but _can't_ be assigned to. If you want to do something
 fancier
 than a simple initialization, you're going to need to create another array
 which you do everything to and _then_ initialize the const array with
 that.
 The errors that you're running into are completely by design.

What bearophile is asking for is to treat those cases like an initialization (what they, in fact, are) rather than like an assignment.

Nov 07 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Is there any ready plan, that will describe what exactly do we want to
get in the end?
I'm starting to think, that it would be great to have our own format
for shared libraries.

On Tue, Nov 8, 2011 at 10:25 AM, Rainer Schuetze <r.sagitario gmx.de> wrote:
 On 07.11.2011 13:36, Gor Gyolchanyan wrote:
 1. Making shared libraries under Linux work would be a big improvement.

I think you meant "Making shared libraries, written in D, under Linux work would be a big improvement.", because everything else works fine (i tested it) using core.sys.posix.dlfn; Since druntime needs some serious initialization, core.sys.windows.dll was invented to hide away all this and, if I'm not mistaken, this is precisely what it means to "support DLLs". since .so files don't have any auto-called functions, like DllMain, some additional shenanigans are required to get it to work as in Windows. There will still be helper functions that would be put inside some "main" function in .so functions, that should be called explicitly when loaded (probably inside a standard library loader). DllMain also has thread/process attach/detach routine callbacks, which are, AFAIK, are not necessary to simulate in .so files (otherwise, it'll go inside that pseudo-main function). Regarding the above information, all I have to do to make "shared libraries work under linux" is to make linux analogs for the dll helper functions, define the pseudo-main function requirement in D docs and make a specialization of LoadLibrary routine in druntime to call that function.

There are different ways to use and implement shared libraries written in D: 1. the shared library interfaces to any other library as a C library does, i.e. without any shared resources (e.g. it has its own heap and its own thread list). 2. the shared library shares resources with other libraries and the executable. The DLL support on windows covers the first case. I think such a shared library should work in any host application, even if it is not aware that it is written in D. There is limited support for the second case that only forwards calls to the GC into another shared library, but it won't work with other resources or in a multi threading environment. Some attempts have been made to put the phobos runtime library into a shared library on Windows (and OSX): http://d.puremagic.com/issues/show_bug.cgi?id=4071

Nov 07 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
 I think that a programming language that declares itself as a "System Lan=

You're completely right. Just as D supports extern(C) to support C-function, it should support C-libraries. But this doesn't mean, that this is the way it should work always. At the end, all shared libraries are always usable, because they need a C API and D can interface with C APIs. There can even be neat high-level wrappers around those APIs to ease the access to C shared libraries. But I think encouraging programmers to wrote _new_ libraries in _D_ using those shared library formats is a bad idea. Too many workarounds, too much danger.
 There is the DDL project with that approach: http://www.dsource.org/proje=

I knew about DDL a long time ago. But it's D1 only and doesn't seem to be willing to add D2 support. If and when it supports D2, I'll take a look at it, test it for various traits and if it passes the tests I'll make a pull request to add it to Phobos. On Tue, Nov 8, 2011 at 10:45 AM, Rainer Schuetze <r.sagitario gmx.de> wrote= :
 There is the DDL project with that approach:
 http://www.dsource.org/projects/ddl/wiki

 I think that a programming language that declares itself as a "System
 Language" should be able to build and use native shared libraries.

 On 08.11.2011 07:32, Gor Gyolchanyan wrote:
 Is there any ready plan, that will describe what exactly do we want to
 get in the end?
 I'm starting to think, that it would be great to have our own format
 for shared libraries.

 On Tue, Nov 8, 2011 at 10:25 AM, Rainer Schuetze<r.sagitario gmx.de>
 =A0wrote:
 On 07.11.2011 13:36, Gor Gyolchanyan wrote:
 1. Making shared libraries under Linux work would be a big improvemen=





 I think you meant "Making shared libraries, written in D, under Linux
 work would be a big improvement.", because everything else works fine
 (i tested it) using core.sys.posix.dlfn;
 Since druntime needs some serious initialization, core.sys.windows.dll
 was invented to hide away all this and, if I'm not mistaken, this is
 precisely what it means to "support DLLs".
 since .so files don't have any auto-called functions, like DllMain,
 some additional shenanigans are required to get it to work as in
 Windows. There will still be helper functions that would be put inside
 some "main" function in .so functions, that should be called
 explicitly when loaded (probably inside a standard library loader).
 DllMain also has thread/process attach/detach routine callbacks, which
 are, AFAIK, are not necessary to simulate in .so files (otherwise,
 it'll go inside that pseudo-main function).
 Regarding the above information, all I have to do to make "shared
 libraries work under linux" is to make linux analogs for the dll
 helper functions, define the pseudo-main function requirement in D
 docs and make a specialization of LoadLibrary routine in druntime to
 call that function.

There are different ways to use and implement shared libraries written =



 D:
 1. the shared library interfaces to any other library as a C library
 does,
 i.e. without any shared resources (e.g. it has its own heap and its own
 thread list).
 2. the shared library shares resources with other libraries and the
 executable.

 The DLL support on windows covers the first case. I think such a shared
 library should work in any host application, even if it is not aware th=



 it
 is written in D.

 There is limited support for the second case that only forwards calls t=



 the
 GC into another shared library, but it won't work with other resources =



 in
 a multi threading environment.

 Some attempts have been made to put the phobos runtime library into a
 shared
 library on Windows (and OSX):

 http://d.puremagic.com/issues/show_bug.cgi?id=3D4071



Nov 08 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Yes. The idea is awesome. Being able to embed almost all of D's
constructs in a shared library is a great idea.
Unfortunately it stopped it's development right before it would
actually become useful.

Why don't we take it, refactor it for Phobos and include it?

On Tue, Nov 8, 2011 at 2:32 PM, Don <nospam nospam.com> wrote:
 On 08.11.2011 10:40, Gor Gyolchanyan wrote:
 I think that a programming language that declares itself as a "System
 Language" should be able to build and use native shared libraries.

You're completely right. Just as D supports extern(C) to support C-function, it should support C-libraries. But this doesn't mean, that this is the way it should work always. At the end, all shared libraries are always usable, because they need a C API and D can interface with C APIs. There can even be neat high-level wrappers around those APIs to ease the access to C shared libraries. But I think encouraging programmers to wrote _new_ libraries in _D_ using those shared library formats is a bad idea. Too many workarounds, too much danger.
 There is the DDL project with that approach:
 http://www.dsource.org/projects/ddl/wiki

I knew about DDL a long time ago. But it's D1 only and doesn't seem to be willing to add D2 support. If and when it supports D2, I'll take a look at it, test it for various traits and if it passes the tests I'll make a pull request to add it to Phobos.

Last serious update seems to be 4 years ago. D2 barely existed back then.

Nov 08 2011
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--f46d040710e952cf6404b13c5a57
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 8, 2011 at 1:52 AM, Walter Bright <newshound2 digitalmars.com>wrote:

 On 11/7/2011 4:57 AM, kenji hara wrote:

 I have call this concept "transitively modifiable", and I have
 implemented it with dmd/pull/166.

For those who don't yet know, Kenji is a very prolific and high quality contributor to dmd.

About half of the currently open dmd pull requests are from him (34 of 69). Very prolific is right. --f46d040710e952cf6404b13c5a57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <span style=3D"background-color: transparent; ">On Tue, Nov 8, 2011 at 1:52= AM, Walter Bright </span><span dir=3D"ltr" style=3D"background-color: tran= sparent; ">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 dig= italmars.com</a>&gt;</span><span style=3D"background-color: transparent; ">= wrote:</span><br> <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im= ">On 11/7/2011 4:57 AM, kenji hara wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I have call this concept &quot;transitively modifiable&quot;, and I have<br=

</blockquote> <br></div> For those who don&#39;t yet know, Kenji is a very prolific and high quality= contributor to dmd.<br> </blockquote></div><br><div>About half of the currently open dmd pull reque= sts are from him (34 of 69). =A0Very prolific is right.</div> --f46d040710e952cf6404b13c5a57--
Nov 08 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, November 08, 2011 09:17 Brad Anderson wrote:
 On Tue, Nov 8, 2011 at 1:52 AM, Walter Bright 

 On 11/7/2011 4:57 AM, kenji hara wrote:
 I have call this concept "transitively modifiable", and I have
 implemented it with dmd/pull/166.

For those who don't yet know, Kenji is a very prolific and high quality contributor to dmd.

About half of the currently open dmd pull requests are from him (34 of 69). Very prolific is right.

And he's actually one of the few who actively does work on both dmd and Phobos. We're definitely lucky to have him. - Jonathan M Davis
Nov 08 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
All i ever heard from him is pull requests. He basically makes DMD's
evolution possible :-)
Without any jokes, we should throw a party in his honor :-)

On Tue, Nov 8, 2011 at 10:16 PM, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 On Tuesday, November 08, 2011 09:17 Brad Anderson wrote:
 On Tue, Nov 8, 2011 at 1:52 AM, Walter Bright

 On 11/7/2011 4:57 AM, kenji hara wrote:
 I have call this concept "transitively modifiable", and I have
 implemented it with dmd/pull/166.

For those who don't yet know, Kenji is a very prolific and high quality contributor to dmd.

About half of the currently open dmd pull requests are from him (34 of 69). Very prolific is right.

And he's actually one of the few who actively does work on both dmd and Phobos. We're definitely lucky to have him. - Jonathan M Davis

Nov 08 2011
prev sibling parent Trass3r <un known.com> writes:
Am 08.11.2011, 09:52 Uhr, schrieb Walter Bright  
<newshound2 digitalmars.com>:

 On 11/7/2011 4:57 AM, kenji hara wrote:
 I have call this concept "transitively modifiable", and I have
 implemented it with dmd/pull/166.

For those who don't yet know, Kenji is a very prolific and high quality contributor to dmd.

Yep! I really wonder where that skill comes from, i.e. is he working in the compiler business or something like that? For me it's quite hard to figure out the most generic/appropriate way to fix a bug in dmd. But he seemed immediately knowledgeable about dmd's internals. Furthermore I wonder why he is that dedicated. I haven't seen him actually use D for some project ;)
Nov 08 2011