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




d

 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=




nd

 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=




ient

 code sequences.

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


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


e a

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

 -Steve
Nov 07 2011
parent reply "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
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=


:vladimir thecybershadow.net





 Nov 07 2011



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



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



  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 Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


 I think that a programming language that declares itself as a "System Lan=


guage" 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/proje=


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

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=










t.

 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 th=






at

 it
 is written in D.

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






o

 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=3D4071









 Nov 08 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



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



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



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



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



  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 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  parent reply 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 =


and able to write a patch to allow code like this (it's in Bugzilla, with n=
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



  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



 next sibling parent reply Brad Anderson <eco gnuk.net>  writes:


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.



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


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


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


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


 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