www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Where is contribution most needed to the D community?

reply "Kira Backes" <kira.backes nrwsoft.de> writes:
Dear D users,


after a long time evaluating all options I think I finally 
committed to D and vibe.d! Since I’ll have a lot of memory usage 
and I want to do an MMORPG I always was scared off by GC-enabled 
languages, but after thoroughly evaluating what this language 
(and vibe.d) gives me in terms of performance, memory usage (this 
is especially important, a lot of GC-languages like Java have 
unacceptable memory bloat for objects etc.) and productivity I 
think this is the best decision. Obviously I’ll have some work to 
do later to move most of the objects out of the GC (they usually 
live from the start of the server to the end of the server) but I 
now thinks that this work is still a lot less then all the other 
work combined. I especially like the built-in contract 
programming, invariants and unit-tests and I think they’ll be 
worth a lot! And even more awesome is the compile-time reflection 
for serialization (very important for my projects).

So, what I actually wanted to ask, which part/project do you 
think mostly needs contribution? The D documentation on this 
page? Mono-D (I’ll be using that, already contributed to an 
issue)? DUB? vibe.d and its documentation? More tutorials on a 
seperate blog?

Please tell me what you think! :-)


rgds, Kira Backes
Jan 08 2014
next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:

 Dear D users,


 after a long time evaluating all options I think I finally 
 committed to D and vibe.d! Since I’ll have a lot of memory 
 usage and I want to do an MMORPG I always was scared off by 
 GC-enabled languages, but after thoroughly evaluating what this 
 language (and vibe.d) gives me in terms of performance, memory 
 usage (this is especially important, a lot of GC-languages like 
 Java have unacceptable memory bloat for objects etc.) and 
 productivity I think this is the best decision. Obviously I’ll 
 have some work to do later to move most of the objects out of 
 the GC (they usually live from the start of the server to the 
 end of the server) but I now thinks that this work is still a 
 lot less then all the other work combined. I especially like 
 the built-in contract programming, invariants and unit-tests 
 and I think they’ll be worth a lot! And even more awesome is 
 the compile-time reflection for serialization (very important 
 for my projects).

 So, what I actually wanted to ask, which part/project do you 
 think mostly needs contribution? The D documentation on this 
 page? Mono-D (I’ll be using that, already contributed to an 
 issue)? DUB? vibe.d and its documentation? More tutorials on a 
 seperate blog?

 Please tell me what you think! :-)


 rgds, Kira Backes


Hi and welcome here,
It's hard to tell what is most important. I feel that these days 
dub is an enabling project that deserves some help.
Jan 09 2014
prev sibling next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:

 Dear D users,


 after a long time evaluating all options I think I finally 
 committed to D and vibe.d! Since I’ll have a lot of memory 
 usage and I want to do an MMORPG I always was scared off by 
 GC-enabled languages, but after thoroughly evaluating what this 
 language (and vibe.d) gives me in terms of performance, memory 
 usage (this is especially important, a lot of GC-languages like 
 Java have unacceptable memory bloat for objects etc.) and 
 productivity I think this is the best decision. Obviously I’ll 
 have some work to do later to move most of the objects out of 
 the GC (they usually live from the start of the server to the 
 end of the server) but I now thinks that this work is still a 
 lot less then all the other work combined. I especially like 
 the built-in contract programming, invariants and unit-tests 
 and I think they’ll be worth a lot! And even more awesome is 
 the compile-time reflection for serialization (very important 
 for my projects).

 So, what I actually wanted to ask, which part/project do you 
 think mostly needs contribution? The D documentation on this 
 page? Mono-D (I’ll be using that, already contributed to an 
 issue)? DUB? vibe.d and its documentation? More tutorials on a 
 seperate blog?

 Please tell me what you think! :-)


 rgds, Kira Backes


A good web service stack is the main thing for Vibe I believe.
Because of this I started Cmsed (I'll push it into repo soon) a 
component library that also functions as a content management 
system. I also built and still working on an ORM (Dvorm [0]).
I need OpenDBX support for e.g. Mysql added to it. I have 
bindings to it available. Mongo already supported.

There is also standards like odata I wish to support with my 
router natively. For this I need some sort of relationship system 
within Dvorm.

I strongly believe some sort of GWT [1] inspired system is also 
required to work alongside a router. I did have this planned for 
DOOGLE [2] but since talk about a new gui base system, there's 
little point in me continuing it.

But from a practical side. We need articles showing good examples 
of simple code to do awesome stuff.
Benchmarks on memory/cpu usage ext. Also very important.

At the end of day, choose what you're good at and love. It'll 
help no matter what it is :)

[0] https://github.com/rikkimax/Dvorm
[1] http://www.gwtproject.org/
[2] https://github.com/rikkimax/DOOGLE
Jan 09 2014
parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
Added to github.
Not ready yet for dub repository addition as I haven't finished 
with the base subpackage yet.

I want odata to be added before then. Maybe something else is 
required. I'll see. Shouldn't be long though.

[0] https://github.com/rikkimax/Cmsed
Jan 09 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-01-09 08:45, Kira Backes wrote:

 Dear D users,


 after a long time evaluating all options I think I finally committed to
 D and vibe.d! Since I’ll have a lot of memory usage and I want to do an
 MMORPG I always was scared off by GC-enabled languages, but after
 thoroughly evaluating what this language (and vibe.d) gives me in terms
 of performance, memory usage (this is especially important, a lot of
 GC-languages like Java have unacceptable memory bloat for objects etc.)
 and productivity I think this is the best decision. Obviously I’ll have
 some work to do later to move most of the objects out of the GC (they
 usually live from the start of the server to the end of the server) but
 I now thinks that this work is still a lot less then all the other work
 combined. I especially like the built-in contract programming,
 invariants and unit-tests and I think they’ll be worth a lot! And even
 more awesome is the compile-time reflection for serialization (very
 important for my projects).

 So, what I actually wanted to ask, which part/project do you think
 mostly needs contribution? The D documentation on this page? Mono-D
 (I’ll be using that, already contributed to an issue)? DUB? vibe.d and
 its documentation? More tutorials on a seperate blog?


We could use some help with all of those. It's hard to choose.

-- 
/Jacob Carlborg
Jan 09 2014
prev sibling next sibling parent "qznc" <qznc web.de> writes:
On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:

 Please tell me what you think! :-)


1. If you already have some code, you could refactor some of it 
into libraries and publish them via Dub aka code.dlang.org.

2. Using Dub, Phobos, DMD-betas, etc you probably find bugs. You 
can actively search for them by testing your code with each new 
beta release. You should report them. Ideally, you even fix them 
and submit pull requests.

3. Blog about your experience with D. Announce it here, on Hacker 
News, Reddit, etc.

4. Talk about D (commenting on reddit etc). Tell people about D. 
Give presentations at conferences (DConf 2014!), user groups, etc.
Jan 09 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/8/14 11:45 PM, Kira Backes wrote:

 So, what I actually wanted to ask, which part/project do you think
 mostly needs contribution? The D documentation on this page? Mono-D
 (I’ll be using that, already contributed to an issue)? DUB? vibe.d and
 its documentation? More tutorials on a seperate blog?

 Please tell me what you think! :-)


Welcome aboard! You are already doing something that D needs, which is 
establishing a track record of successful applications.

Other things I often here about are: (a) availability of libraries for 
anything and everything, e.g. database- and networking-related stuff; 
(b) distribution of such, i.e. http://code.dlang.org and dub.

Experience reports (blogs, articles) on use of D are also great to have. 
Documentation updates are welcome at all levels.


Cheers,

Andrei
Jan 09 2014
prev sibling next sibling parent "Kelet" <kelethunter gmail.com> writes:
On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:

 So, what I actually wanted to ask, which part/project do you 
 think mostly needs contribution?


Hello,

Given the low frequency of issue reports on some projects, I've 
definitely noticed a new face in the D ecosystem. I've thought 
about this problem a little bit as well.


 The D documentation on this page?


For the most part, I've been satisfied with D documentation on 
the official website. My only general gripe is that there are 
many outdated pages – sometimes to the point of irrelevance. This 
can confuse people, given it is on the official website and not 
marked as outdated. For example: http://dlang.org/safed.html 
confused me the other day. I did not know it had evolved into 
 safe.


 Mono-D (I’ll be using that, already contributed to an issue)?


Mono-D is by far my favorite IDE for D. It is cross-platform, 
free as in speech/beer, and supports DUB package files. 
Unfortunately, there are a lot of unreported issues or 
non-reproducable issues which tends to happen when a development 

and not D though. One thing that may be possible and worth doing 
in the future is using DCD (mentioned later) with Mono-D and 
combining efforts. Though that is more of a major undertaking.


 DUB?


Sönke is moving along pretty quickly with DUB. I would say having 
a well fleshed out tutorial or more examples could do it well 
though.


 More tutorials on a seperate blog?


A lot of D language tutorials and informational resources pander 
to C++ programmers. I think that we should be more focused on 
attracting new users or perhaps people who tend to use 
interpreted languages. See: http://www.rustforrubyists.com/. A 
lot of people would like a more performant, statically checked, 
compiled language. D is expressive enough to intersect with a lot 
of the use cases of a scripting language.
Jan 09 2014
prev sibling next sibling parent reply "Kelet" <kelethunter gmail.com> writes:
And to expand a bit on my previous post with things I personally 
thing are important and rather low hanging:

- Create style and layout templates for ddox to help us 
non-designers
- Make DCD plugins for editors so they can autocomplete, go to 
definition, etc.
- Create idiomatic D wrappers around deimos/derelict or any other 
direct C bindings

But most of all, the D ecosystem simply needs users who are 
willing to generate activity in the form of:
- Usage of D libraries
- Willingness to file issues and follow up on them should a 
problem arise
- Release of software built using D
- Discussion within (mailing list, IRC) and beyond (reddit, HN) 
the D community
- Documenting your experiences and creating said discussion
- Openness to test drive prospective "big players" in the 
environment

To expand on that last point: I mean using things like DUB, ddox, 
Mono-D or Pegged early on if possible. This makes them viable 
that much faster, and we need an ecosystem that makes it simple 
for a new user to come in and set up a project.

Regards,
Kelet
Jan 09 2014
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 09, 2014 at 11:59:10PM +0000, Kelet wrote:

 And to expand a bit on my previous post with things I personally
 thing are important and rather low hanging:
 
 - Create style and layout templates for ddox to help us non-designers
 - Make DCD plugins for editors so they can autocomplete, go to
   definition, etc.
 - Create idiomatic D wrappers around deimos/derelict or any other
   direct C bindings
 
 But most of all, the D ecosystem simply needs users who are willing
 to generate activity in the form of:
 - Usage of D libraries
 - Willingness to file issues and follow up on them should a problem
   arise
 - Release of software built using D
 - Discussion within (mailing list, IRC) and beyond (reddit, HN) the D
   community
 - Documenting your experiences and creating said discussion
 - Openness to test drive prospective "big players" in the environment


[...]

You forgot the most important one: browse the bugtracker at
http://d.puremagic.com/issues for easy-to-fix Phobos bugs and submit
pull requests for them.  You don't have to be an "official" Phobos dev
to do that (I'm not, and I've had a good number of pulls merged
already).

Or browse the Phobos pull request list on github and help review pull
requests (we're very short of people on that front -- arguably this is
more important than submitting pulls, since a lot of pulls are
stagnating because nobody got around to reviewing them yet).

Phobos code is actually quite pleasant to read in spite of it being the
D standard library (for the most part anyway, Phobos does have its dark
corners but you need not go there). If you've ever tried reading the
source of, say, glibc, you'll know what I mean. Plus, reading Phobos
code will also teach you some powerful D idioms that you may not
otherwise think of. So you'll be learning "effective D" while helping to
improve the quality of its standard library. Double win!


T

-- 
Music critic: "That's an imitation fugue!"
Jan 09 2014
prev sibling parent "Suliman" <evermind live.ru> writes:
- Make DCD plugins for editors so they can autocomplete, go to


definition
+1
Jan 10 2014
prev sibling next sibling parent reply "FreeSlave" <freeslave93 gmail.com> writes:
The current state of Phobos documentation is terrible in some 
moments. Many types and functions are not described how to use. 
For example, from documentation I don't know how to use 
ErrnoException. Does it have field for error code copied from 
errno, or should I use errno directly when I meet this exception? 
What message does ErrnoException provide? It's from stderror 
function or some dependent on caller? Plenty of questions arise 
when you need to know how do class or function work, and you 
often need to browse source code to find out what happens. But 
ideally documentation must be full, so user does not have to look 
into sources.

There is also sensible lack of examples. Look at std.encoding. 
Well, actually I'm sure that the whole module needs to be 
rewritten, I don't see any benefits of "templated" approach to 
work with encoding.
Other thing is "auto" as returned type. It's very handy in code, 
but I think library documentation should mark returned types more 
explicitly.
So there is many work on Phobos documentation to make it better.

Also there are some deprecated modules needed for replacement, 
for example, std.stream and std.socketstream (but I'm not sure 
why). I believe streams are important to ease programming, but 
they need really good interface and implementation (flexible and 
extensible), maybe you have some ideas on it.
Jan 10 2014
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-01-10 12:36, FreeSlave wrote:

 The current state of Phobos documentation is terrible in some moments.
 Many types and functions are not described how to use. For example, from
 documentation I don't know how to use ErrnoException. Does it have field
 for error code copied from errno, or should I use errno directly when I
 meet this exception? What message does ErrnoException provide? It's from
 stderror function or some dependent on caller? Plenty of questions arise
 when you need to know how do class or function work, and you often need
 to browse source code to find out what happens. But ideally
 documentation must be full, so user does not have to look into sources.


I agree.


 There is also sensible lack of examples. Look at std.encoding. Well,
 actually I'm sure that the whole module needs to be rewritten, I don't
 see any benefits of "templated" approach to work with encoding.
 Other thing is "auto" as returned type. It's very handy in code, but I
 think library documentation should mark returned types more explicitly.
 So there is many work on Phobos documentation to make it better.


Ddoc needs to resolve "auto" to the actual type.


 Also there are some deprecated modules needed for replacement, for
 example, std.stream and std.socketstream (but I'm not sure why). I
 believe streams are important to ease programming, but they need really
 good interface and implementation (flexible and extensible), maybe you
 have some ideas on it.


I think they need to be able to work with ranges.

-- 
/Jacob Carlborg
Jan 10 2014
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 10 January 2014 at 14:02:16 UTC, Jacob Carlborg wrote:

 On 2014-01-10 12:36, FreeSlave wrote:

 The current state of Phobos documentation is terrible in some 
 moments.
 Many types and functions are not described how to use. For 
 example, from
 documentation I don't know how to use ErrnoException. Does it 
 have field
 for error code copied from errno, or should I use errno 
 directly when I
 meet this exception? What message does ErrnoException provide? 
 It's from
 stderror function or some dependent on caller? Plenty of 
 questions arise
 when you need to know how do class or function work, and you 
 often need
 to browse source code to find out what happens. But ideally
 documentation must be full, so user does not have to look into 
 sources.


 I agree.


 There is also sensible lack of examples. Look at std.encoding. 
 Well,
 actually I'm sure that the whole module needs to be rewritten, 
 I don't
 see any benefits of "templated" approach to work with encoding.
 Other thing is "auto" as returned type. It's very handy in 
 code, but I
 think library documentation should mark returned types more 
 explicitly.
 So there is many work on Phobos documentation to make it 
 better.


 Ddoc needs to resolve "auto" to the actual type.


Unless it's a voldemort type.
Jan 10 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-01-10 20:36, Brad Anderson wrote:


 Unless it's a voldemort type.


Now this becomes a bit tricky ;)

-- 
/Jacob Carlborg
Jan 10 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/10/14 3:36 AM, FreeSlave wrote:

 The current state of Phobos documentation is terrible in some moments.


Agreed. Please submit bug reports for it. This is one area in which 
literally every member of the community can contribute.

Andrei
Jan 10 2014
prev sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:

 So, what I actually wanted to ask, which part/project do you 
 think mostly needs contribution? The D documentation on this 
 page? Mono-D (I’ll be using that, already contributed to an 
 issue)? DUB? vibe.d and its documentation? More tutorials on a 
 seperate blog?


I'm going to answer with a question of my own.  What requirement
for your project do you feel is most lacking in D right now?  I'd
work on that, since you would have the best idea of what the
result should be and the greatest motivation to get it done.  Or
if there's nothing lacking, some tutorials would be awesome.
Jan 10 2014