• dsimcha (67/67) Jul 14 2012 I've been on somewhat of a hiatus these past few months and have only
• =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (18/85) Jul 14 2012 +1.
• Jonathan M Davis (16/22) Jul 15 2012 Someone was working on it (Tomaz?) and was supposedly making good progre...
• dsimcha (4/26) Jul 15 2012 Ok, well I'll at least try to get a better handle on what's involved and...
• Andrei Alexandrescu (4/7) Jul 15 2012 FWIW, it would be great if you worked on std.xml.
• David Nadlinger (10/18) Jul 15 2012 I take it you are referring to the GitHub commit messages which
• dsimcha (8/27) Jul 15 2012 Yeah. The problem is that for a while, D mailing lists became so

dsimcha <dsimcha yahoo.com> writes:

I've been on somewhat of a hiatus these past few months and have only 
worked on D-related development sporadically.  There are several reasons 
for my absence, some of which will hopefully change soon, and I hope to 
make a comeback.  Below are the reasons why my contributions have 
declined and some suggestions for improvements to the D community where 
the issues aren't specific to me:

0.  There's a lot less stuff that's broken or missing now than a few 
years ago when I started contributing.  This has led to a mild 
complacency as D is already awesome.  For example, it's been a long time 
since I hit a compiler bug that caused me significant hassle.

1.  I'm writing my Ph.D. thesis and looking for jobs.  I still have some 
time to contribute, but D development isn't the top idea in my mind due 
to these distractions.  This is in some ways the root of the problem, as 
I have less time and mental energy to keep up with D through informal 
channels.  I think my job search is over, though, so that's one less 
distraction.

2.  Because I'm writing my thesis, I don't program much for my research 
anymore.  I therefore don't notice little things that are broken or get 
cool ideas from other languages as often.  To make it easier for someone 
to find bugs and enchancement requests in areas he/she is already 
familiar with, I'd like to see an ability to search by module (for 
Phobos/druntime) or feature (for DMD) in Bugzilla.  For example, in 
Phobos I'm most familiar with std.range, std.algorithm, std.parallelism 
and std.functional.  I'd like to be able to easily query a list of bugs 
specific to those modules.

3.  As the community has grown larger, more people besides me have 
stepped up.  Of course this is a good thing.  The only downside is that 
I've lost track of who's working on what, what its status is, what still 
needs to be done, and what the holdups are.  Perhaps we need some 
central place other than this newsgroup where this information is posted 
for key D projects.  For example, we'd have a page that says "Person X 
is working on a new std.xml.  Here's the Github repository.  It's 
stalled because noone can agree on a design for Y."  We should also 
maintain a slightly more formal wishlist of stuff that noone's working 
on that's waiting to be done.

BTW, if noone is working on a new std.xml anymore, I might want to 
start.  I interviewed for a job where they wanted me to do a small 
prototype as part of the hiring process that involved parsing XML.  I 
was allowed to use any language I wanted.  I think my D projects played 
a large role in me getting an offer, but I couldn't use it for the 
prototype because std.xml is so bad.  I ended up using Python instead.

4.  The release cycle has slowed greatly.  What happened here?  The 1-2 
month release cycles were a good motivator because they created mild 
deadline pressure to get features and fixes checked in before the next 
release.

5.  The amount of stuff on this forum and the mailing lists has become 
overwhelming.  I've recently remedied this to a small degree by 
unsubscribing from dmd-internals.  I've never been a contributor to the 
compiler itself and had only subscribed to this list to track bug fixes 
and 64-bit support implementation.  Now, the signal-to-noise ratio of my 
inbox is good enough that I actually read the Phobos and druntime stuff 
again instead of just glossing over all my D-related email.

As far as this forum, I suggest a split something like the following, so 
that it has a better signal-to-noise ratio from the perspective of 
people with specific interests:

D.language-design:  Long, complicated threads about language features 
and the theory behind them belong here.

D.phobos-design:  Since the Phobos mailing list is intended mostly for 
regular contributors and is focused on individual pull requests and 
commits, this is where high-level design stuff would get discussed 
w.r.t. Phobos.

D.ecosystem:  Stuff about third-party libraries, Deimos, toolchains, 
etc. goes here.

D.adoption:  Discussions about why D was or wasn't adopted for a given 
project and how to increase its adoption go here.

D.learn:  Questions about using D.  We already have this, but we need to 
encourage people to use it more instead of posting to the main group.

=?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:

On 15-07-2012 06:02, dsimcha wrote:
 I've been on somewhat of a hiatus these past few months and have only
 worked on D-related development sporadically.  There are several reasons
 for my absence, some of which will hopefully change soon, and I hope to
 make a comeback.  Below are the reasons why my contributions have
 declined and some suggestions for improvements to the D community where
 the issues aren't specific to me:

 0.  There's a lot less stuff that's broken or missing now than a few
 years ago when I started contributing.  This has led to a mild
 complacency as D is already awesome.  For example, it's been a long time
 since I hit a compiler bug that caused me significant hassle.

Indeed! Things have gotten a lot better as of late.

 1.  I'm writing my Ph.D. thesis and looking for jobs.  I still have some
 time to contribute, but D development isn't the top idea in my mind due
 to these distractions.  This is in some ways the root of the problem, as
 I have less time and mental energy to keep up with D through informal
 channels.  I think my job search is over, though, so that's one less
 distraction.

 2.  Because I'm writing my thesis, I don't program much for my research
 anymore.  I therefore don't notice little things that are broken or get
 cool ideas from other languages as often.  To make it easier for someone
 to find bugs and enchancement requests in areas he/she is already
 familiar with, I'd like to see an ability to search by module (for
 Phobos/druntime) or feature (for DMD) in Bugzilla.  For example, in
 Phobos I'm most familiar with std.range, std.algorithm, std.parallelism
 and std.functional.  I'd like to be able to easily query a list of bugs
 specific to those modules.

+1.

 3.  As the community has grown larger, more people besides me have
 stepped up.  Of course this is a good thing.  The only downside is that
 I've lost track of who's working on what, what its status is, what still
 needs to be done, and what the holdups are.  Perhaps we need some
 central place other than this newsgroup where this information is posted
 for key D projects.  For example, we'd have a page that says "Person X
 is working on a new std.xml.  Here's the Github repository.  It's
 stalled because noone can agree on a design for Y."  We should also
 maintain a slightly more formal wishlist of stuff that noone's working
 on that's waiting to be done.

We should use Trello much more than we do now: https://trello.com/dlang

I've also been keeping an eye on Phabricator (http://phabricator.org)...

 BTW, if noone is working on a new std.xml anymore, I might want to
 start.  I interviewed for a job where they wanted me to do a small
 prototype as part of the hiring process that involved parsing XML.  I
 was allowed to use any language I wanted.  I think my D projects played
 a large role in me getting an offer, but I couldn't use it for the
 prototype because std.xml is so bad.  I ended up using Python instead.

 4.  The release cycle has slowed greatly.  What happened here?  The 1-2
 month release cycles were a good motivator because they created mild
 deadline pressure to get features and fixes checked in before the next
 release.

I'm not actually sure what happened here. I suspect the problem is that 
most people are against releasing with regressions, but there's no one 
to actually fix them.

 5.  The amount of stuff on this forum and the mailing lists has become
 overwhelming.  I've recently remedied this to a small degree by
 unsubscribing from dmd-internals.  I've never been a contributor to the
 compiler itself and had only subscribed to this list to track bug fixes
 and 64-bit support implementation.  Now, the signal-to-noise ratio of my
 inbox is good enough that I actually read the Phobos and druntime stuff
 again instead of just glossing over all my D-related email.

 As far as this forum, I suggest a split something like the following, so
 that it has a better signal-to-noise ratio from the perspective of
 people with specific interests:

 D.language-design:  Long, complicated threads about language features
 and the theory behind them belong here.

 D.phobos-design:  Since the Phobos mailing list is intended mostly for
 regular contributors and is focused on individual pull requests and
 commits, this is where high-level design stuff would get discussed
 w.r.t. Phobos.

 D.ecosystem:  Stuff about third-party libraries, Deimos, toolchains,
 etc. goes here.

 D.adoption:  Discussions about why D was or wasn't adopted for a given
 project and how to increase its adoption go here.

 D.learn:  Questions about using D.  We already have this, but we need to
 encourage people to use it more instead of posting to the main group.

I agree with all of these. The main D newsgroup has way too many things 
going on at the same time. We've needed this split badly for a while.

I would also suggest a forum for druntime/GC development and design. 
Whether it would be used, I don't know, but I think it's worth trying. 
Sometimes it's hard to get replies on the druntime mailing list, and I 
think a newsgroup would help here, since it's more persistent in nature.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Sunday, July 15, 2012 00:02:09 dsimcha wrote:
 BTW, if noone is working on a new std.xml anymore, I might want to
 start.  I interviewed for a job where they wanted me to do a small
 prototype as part of the hiring process that involved parsing XML.  I
 was allowed to use any language I wanted.  I think my D projects played
 a large role in me getting an offer, but I couldn't use it for the
 prototype because std.xml is so bad.  I ended up using Python instead.

Someone was working on it (Tomaz?) and was supposedly making good progress, 
but last time I checked, they hadn't posted anything since some time in 2010. 
So, as far as I can tell, that project is effectively dead. I have no idea what 
state it was in before it stalled or whether the code is available anywhere 
online. I expect that anyone who wants to work on it will either have to start 
from scratch or grabbing one of the existing xml parsers floating around and 
adjust it (though I suspect that if it's going to be range-based like it's 
supposed to be that any existing parsers floating around probably would need 
quite a bit of work to get the right API, but I don't know). It's the sort of 
thing that I'd love to work on given the time, but I have so much else going 
on that it would be ridiculous for me to even consider it. If you want to take 
up that baton, then I think that's great. Even if you end up taking a while to 
do it, that's better than getting nothing and seeing no progress as we have 
been for quite some time now.

- Jonathan M Davis

dsimcha <dsimcha yahoo.com> writes:

On 7/15/2012 4:54 AM, Jonathan M Davis wrote:
 On Sunday, July 15, 2012 00:02:09 dsimcha wrote:
 BTW, if noone is working on a new std.xml anymore, I might want to
 start.  I interviewed for a job where they wanted me to do a small
 prototype as part of the hiring process that involved parsing XML.  I
 was allowed to use any language I wanted.  I think my D projects played
 a large role in me getting an offer, but I couldn't use it for the
 prototype because std.xml is so bad.  I ended up using Python instead.

 Someone was working on it (Tomaz?) and was supposedly making good progress,
 but last time I checked, they hadn't posted anything since some time in 2010.
 So, as far as I can tell, that project is effectively dead. I have no idea what
 state it was in before it stalled or whether the code is available anywhere
 online. I expect that anyone who wants to work on it will either have to start
 from scratch or grabbing one of the existing xml parsers floating around and
 adjust it (though I suspect that if it's going to be range-based like it's
 supposed to be that any existing parsers floating around probably would need
 quite a bit of work to get the right API, but I don't know). It's the sort of
 thing that I'd love to work on given the time, but I have so much else going
 on that it would be ridiculous for me to even consider it. If you want to take
 up that baton, then I think that's great. Even if you end up taking a while to
 do it, that's better than getting nothing and seeing no progress as we have
 been for quite some time now.

 - Jonathan M Davis


Ok, well I'll at least try to get a better handle on what's involved and 
how much time I'm going to have over the next few months.  I'm not 
saying I definitely want to take it on yet.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/15/12 9:38 AM, dsimcha wrote:
[about std.xml]
 Ok, well I'll at least try to get a better handle on what's involved and
 how much time I'm going to have over the next few months. I'm not saying
 I definitely want to take it on yet.

FWIW, it would be great if you worked on std.xml.

Andrei

"David Nadlinger" <see klickverbot.at> writes:

On Sunday, 15 July 2012 at 04:02:48 UTC, dsimcha wrote:
 5.  The amount of stuff on this forum and the mailing lists has 
 become overwhelming.  I've recently remedied this to a small 
 degree by unsubscribing from dmd-internals.  I've never been a 
 contributor to the compiler itself and had only subscribed to 
 this list to track bug fixes and 64-bit support implementation.
  Now, the signal-to-noise ratio of my inbox is good enough that 
 I actually read the Phobos and druntime stuff again instead of 
 just glossing over all my D-related email.

I take it you are referring to the GitHub commit messages which 
are relayed to dmd-internals? Because except for those (which I 
just made a filter rule for), the list is really quite 
low-volume. Maybe we should create a dedicated d-commits list to 
which all the GitHub notifications get sent, similar to what 
other projects have? The occasional post-commit discussion could 
then be continued on one of the repository-specific lists, just 
like they are now.

David

"dsimcha" <dsimcha yahoo.com> writes:

On Sunday, 15 July 2012 at 15:46:38 UTC, David Nadlinger wrote:
 On Sunday, 15 July 2012 at 04:02:48 UTC, dsimcha wrote:
 5.  The amount of stuff on this forum and the mailing lists 
 has become overwhelming.  I've recently remedied this to a 
 small degree by unsubscribing from dmd-internals.  I've never 
 been a contributor to the compiler itself and had only 
 subscribed to this list to track bug fixes and 64-bit support 
 implementation.
 Now, the signal-to-noise ratio of my inbox is good enough that 
 I actually read the Phobos and druntime stuff again instead of 
 just glossing over all my D-related email.

 I take it you are referring to the GitHub commit messages which 
 are relayed to dmd-internals? Because except for those (which I 
 just made a filter rule for), the list is really quite 
 low-volume. Maybe we should create a dedicated d-commits list 
 to which all the GitHub notifications get sent, similar to what 
 other projects have? The occasional post-commit discussion 
 could then be continued on one of the repository-specific 
 lists, just like they are now.

 David

Yeah.  The problem is that for a while, D mailing lists became so 
overwhelming that I got into the habit of reflexively ignoring 
them completely due to poor signal-to-noise ratio w.r.t stuff I 
actually work on and being preoccupied with other things.  Your 
idea may be a good one, since only the core DMD devs care about 
every commit but others might want to participate in higher level 
discussions.