www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What can the community do to help D?

reply Peter Alexander <peter.alexander.au gmail.com> writes:
There have been threads about what the biggest issues with D are, and 
about the top priorities for D are, but I don't think there has been a 
thread about what the best things are that the community can do to help D.

Should people try to spread the word about D? I'm not even sure this is 
a good idea. We all know that D2 is far from stable at the moment, and 
getting people to try D in its current state might actually put them off 
(first impressions are very important).

Should people try to help with dmd and Phobos? If so, what are the best 
ways to do that?

Should people work on other D compilers (gdc and ldc in particular)? Is 
this even possible without a formal language specification?

What else can we do to help? And what would we consider to be the *best* 
ways to help?
Oct 23 2010
next sibling parent =?ISO-8859-1?Q?Can_Alpay_=c7ift=e7i?= <canalpayciftci gmail.com> writes:
I think, you can write document for beginners with D2. Because D2's document is
bad for beginners. And tpdl not for beginners.
Oct 23 2010
prev sibling next sibling parent Juanjo Alvarez <fake fakeemail.com> writes:
On Sat, 23 Oct 2010 16:09:37 +0100, Peter Alexander 
<peter.alexander.au gmail.com> wrote:

 thread about what the best things are that the community can do to 


help D.

And easy target would be to improve the documentation with better 
explanations for D outsiders and more examples. This way Walter et 
all could devote more time to coding.
Oct 23 2010
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
D needs good docs. See for example this question
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22405
Oct 23 2010
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 23/10/10 6:27 PM, Kagamin wrote:

 D needs good docs. See for example this question
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22405


I agree that better documentation would be nice, but really the 
documentation needs to be updated on the main page, and that's not 
something that the community at large can do (unless I'm mistaken).
Oct 23 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/23/10 13:28 CDT, Peter Alexander wrote:

 On 23/10/10 6:27 PM, Kagamin wrote:

 D needs good docs. See for example this question
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22405


 I agree that better documentation would be nice, but really the
 documentation needs to be updated on the main page, and that's not
 something that the community at large can do (unless I'm mistaken).


You could definitely influence that. We're having sort of catch-22. 
Consider you know for a fact you could write a superb tutorial on D, 
good to be on the first page of d-programming-language.org. But you are 
deadlocked by the spectrum of working in vain, so you end up not writing it.

Regarding the original question, it all depends on the level at which 
one wants to engage. We have some simple things that keep on falling 
towards the tail of the to-do list. In my experience, a strong proponent 
is the best recipe for success.

1. Quality articles, blog entries, experience reports always help. 
There's a good amount of solid knowledge around this group and some 
posts here are of very good quality - almost good to plop in a 
compelling blog and close to a real article. When being comfortable and 
appreciated within the community, it's very easy to forget that the 
outreach of newsgroups posts is minuscule and ephemeral. I've noticed 
that there are blips in TDPL's Amazon's rating whenever something about 
D gets out there (reddit, article, popular blog etc.) There is no 
correlation with even very fruitful and interesting newsgroup activity. 
Statistically, nobody knows about this group :o).

2. Code (whole applications, library submissions). Nothing adds to a 
language's credibility more than code samples, libraries, entire 
applications. Strong proposals for Phobos are still rare, though the 
situation is improving considerably.


Thanks,

Andrei
Oct 23 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Peter Alexander wrote:

 There have been threads about what the biggest issues with D are, and 
 about the top priorities for D are, but I don't think there has been a 
 thread about what the best things are that the community can do to help D.


Some things are (pick one that interests you):

Write articles about D and post them online in various forums

Go through bugzilla and submit patches for bugs

Provide D interfaces (.di files) to popular C libraries

Integrate D support for your favorite editor

Write convoluted code to try and break the compiler

Contribute to the GDC and LDC projects

Write library modules for an area that you know well
Oct 23 2010
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 23/10/10 7:30 PM, Walter Bright wrote:

 Peter Alexander wrote:

 There have been threads about what the biggest issues with D are, and
 about the top priorities for D are, but I don't think there has been a
 thread about what the best things are that the community can do to
 help D.


 Some things are (pick one that interests you):

 Go through bugzilla and submit patches for bugs

 Contribute to the GDC and LDC projects


These two a very difficult without a complete language spec. I just had 
a look through a bunch of bugs and I couldn't even tell if they are bugs 
or not because there's no spec to tell me.

For example, a recent bug regards the validity of:

void main()
{
   { static int x; }
   { static int x; }
}

It produces a linker error just now, but I don't know if that's correct 
behavior or not. The D website makes no mention of the correct behavior 
and TDPL doesn't go into that much detail either.

In fact, I don't think the website mentions static function scope 
variables at all (though TDPL does).

Even veteran D coders are confused about what's supposed to work and 
what's not: 
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=120112

I don't mean to be negative, but it would really help the language if 
there was a complete spec. Until there is, people will be reluctant to 
fix bugs, nobody is going to attempt to write another compiler, and 
certainly no one can write better documentation if they don't know how 
things work.
Oct 23 2010
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 24 Oct 2010 01:06:02 +0400, Peter Alexander  
<peter.alexander.au gmail.com> wrote:


 On 23/10/10 7:30 PM, Walter Bright wrote:

 Peter Alexander wrote:

 There have been threads about what the biggest issues with D are, and
 about the top priorities for D are, but I don't think there has been a
 thread about what the best things are that the community can do to
 help D.


 Some things are (pick one that interests you):

 Go through bugzilla and submit patches for bugs

 Contribute to the GDC and LDC projects


 These two a very difficult without a complete language spec. I just had  
 a look through a bunch of bugs and I couldn't even tell if they are bugs  
 or not because there's no spec to tell me.

 For example, a recent bug regards the validity of:

 void main()
 {
    { static int x; }
    { static int x; }
 }

 It produces a linker error just now, but I don't know if that's correct  
 behavior or not. The D website makes no mention of the correct behavior  
 and TDPL doesn't go into that much detail either.

 In fact, I don't think the website mentions static function scope  
 variables at all (though TDPL does).

 Even veteran D coders are confused about what's supposed to work and  
 what's not:  
 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=120112

 I don't mean to be negative, but it would really help the language if  
 there was a complete spec. Until there is, people will be reluctant to  
 fix bugs, nobody is going to attempt to write another compiler, and  
 certainly no one can write better documentation if they don't know how  
 things work.


FWIW, similar problem exists:

class Foo
{
     void foo1()
     {
         struct Bar {}
     }

     void foo2()
     {
         struct Bar { /* different set of fields and methods */ }
         // using Foo.foo2.Bar here
         // bang! linker errors
     }
}
Oct 23 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:


 FWIW, similar problem exists:
 
 class Foo
 {
      void foo1()
      {
          struct Bar {}
      }
 
      void foo2()
      {
          struct Bar { /* different set of fields and methods */ }
          // using Foo.foo2.Bar here
          // bang! linker errors
      }
 }


I have tried this, with no errors:


class Foo {
    void foo1() {
        struct Bar { string s; }
    }

    void foo2() {
        struct Bar { int x;
            int spam() { return 1; }
        }
        Bar b = Bar(10);
        int y = b.spam();
    }
}

void main() {
    auto f = new Foo;
    f.foo2();
}


Are you able to show me code (or a bug report) that doesn't work?

Bye,
bearophile
Oct 23 2010
parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 24 Oct 2010 01:33:33 +0400, bearophile <bearophileHUGS lycos.com>  
wrote:


 Denis Koroskin:


 FWIW, similar problem exists:

 class Foo
 {
      void foo1()
      {
          struct Bar {}
      }

      void foo2()
      {
          struct Bar { /* different set of fields and methods */ }
          // using Foo.foo2.Bar here
          // bang! linker errors
      }
 }


 I have tried this, with no errors:


 class Foo {
     void foo1() {
         struct Bar { string s; }
     }

     void foo2() {
         struct Bar { int x;
             int spam() { return 1; }
         }
         Bar b = Bar(10);
         int y = b.spam();
     }
 }

 void main() {
     auto f = new Foo;
     f.foo2();
 }


 Are you able to show me code (or a bug report) that doesn't work?

 Bye,
 bearophile


Slightly modified yours and here we go:

class Foo {
     void foo1() {
         struct Bar {
             string s;
             void spam() {
             }
         }

         Bar b = Bar("hello");
         b.spam();
     }

     void foo2() {
         struct Bar {
             int x;
             int spam() { return 1; }
         }
         Bar b = Bar(10);
         int y = b.spam();
     }
}

void main() {
     auto f = new Foo;
     f.foo1();
//    f.foo2();	// uncommenting produces different crash
}
Oct 23 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Peter Alexander wrote:

 I don't mean to be negative, but it would really help the language if 
 there was a complete spec. Until there is, people will be reluctant to 
 fix bugs, nobody is going to attempt to write another compiler, and 
 certainly no one can write better documentation if they don't know how 
 things work.



I think you've identified an area where you can contribute to D! Identify where 
the problems are in the spec, and propose patches. Stewart has done a lot of 
that, but more needs to be done.
Oct 23 2010
prev sibling parent reply Kagamin <spam here.lot> writes:
Peter Alexander Wrote:


 For example, a recent bug regards the validity of:
 
 void main()
 {
    { static int x; }
    { static int x; }
 }


Code is obviously valid. Storage has nothing to do with visibility. In fact,
local static variables were introduced in order to shrink scope of global
variables.
Oct 24 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Kagamin wrote:

 Peter Alexander Wrote:
 

 For example, a recent bug regards the validity of:
 
 void main() { { static int x; } { static int x; } }


 
 Code is obviously valid. Storage has nothing to do with visibility. In fact,
 local static variables were introduced in order to shrink scope of global
 variables.


Yes, I agree that should be valid.
Oct 24 2010
prev sibling next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
On Sat, 23 Oct 2010 16:09:37 +0100, Peter Alexander wrote:


 Should people work on other D compilers (gdc and ldc in particular)? Is
 this even possible without a formal language specification?


God, I hope so, because I've already sunk enough time into SDC. I'd like 
to have a usable compiler at the end! xD
Oct 27 2010
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Bernard Helyer (b.helyer gmail.com)'s article

 On Sat, 23 Oct 2010 16:09:37 +0100, Peter Alexander wrote:

 Should people work on other D compilers (gdc and ldc in particular)? Is
 this even possible without a formal language specification?


 God, I hope so, because I've already sunk enough time into SDC. I'd like
 to have a usable compiler at the end! xD


I hope so too!
Oct 27 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 23/10/2010 16:09, Peter Alexander wrote:

 There have been threads about what the biggest issues with D are, and
 about the top priorities for D are, but I don't think there has been a
 thread about what the best things are that the community can do to help D.

 Should people try to spread the word about D? I'm not even sure this is
 a good idea. We all know that D2 is far from stable at the moment, and
 getting people to try D in its current state might actually put them off
 (first impressions are very important).

 Should people try to help with dmd and Phobos? If so, what are the best
 ways to do that?

 Should people work on other D compilers (gdc and ldc in particular)? Is
 this even possible without a formal language specification?

 What else can we do to help? And what would we consider to be the *best*
 ways to help?


If you have good /Java skills/, the DDT project welcomes contributions 
(http://code.google.com/a/eclipselabs.org/p/ddt/).

The *best* ways to help, it depends on your skills and area of 
experience. One person may be much more useful and/or productive for the 
D community doing one thing versus another.

But if you want to know which areas are better to have contributions 
made, in my opinion it's the compilers, especially DMD. Second to that I 
would say the rest of the toolchain (IDEs, build tools, debuggers).

-- 
Bruno Medeiros - Software Engineer
Nov 24 2010