www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - process improvement for phobos

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
Walter,
There's a perception (rightly or wrongly) that submissions to phobos aren't 
processed in a timely and/or fair manner. What process should we use to 
communicate phobos changes to you that would speed things up? Should the 
changes be posted to the newsgroup for vetting, for example? Do you prefer 
entire files over diffs? What about changes that touch multiple files?

Personally I find emailing entire files (eg, std.stream) with the html doc 
updates works fine (the changes appear in the next release or if not I email 
with a reminder and it gets done). When the changes involve more than bug 
fixes I post to the newsgroup to get opinions, but usually not much comes up 
because the changes were prompted by some newsgroup discussion anyway.

-Ben 
Mar 29 2005
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:d2bk6d$1cm9$1 digitaldaemon.com...
 What process should we use to communicate phobos changes to you that would 
 speed things up?
I suppose another board might work, as the people here seem to be pretty responsible as to what gets posted to what boards. Although an official wiki or something would be nice.
 Do you prefer entire files over diffs?
Yes, for the simple fact that I wouldn't know what to do with a diff file, unless it's in the IPS format, in which case I can handle that ;) and if not, it'd probably require downloading some linux tool that needs to be run under Cygwin. It's a lot easier to read an actual file than to have to apply the diff to the existing file, and it's not like text files are all that big. There'd just need to be some commenting standard, so we'd be able to see (and document) any changes that were made.
 What about changes that touch multiple files?
Send 'em all.
Mar 29 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d2bk6d$1cm9$1 digitaldaemon.com...
 Walter,
 There's a perception (rightly or wrongly) that submissions to phobos
aren't
 processed in a timely and/or fair manner. What process should we use to
 communicate phobos changes to you that would speed things up? Should the
 changes be posted to the newsgroup for vetting, for example? Do you prefer
 entire files over diffs? What about changes that touch multiple files?

 Personally I find emailing entire files (eg, std.stream) with the html doc
 updates works fine (the changes appear in the next release or if not I
email
 with a reminder and it gets done). When the changes involve more than bug
 fixes I post to the newsgroup to get opinions, but usually not much comes
up
 because the changes were prompted by some newsgroup discussion anyway.
I know that's an issue, and I apologize for it. It comes about because I've been giving the compiler itself nearly all my attention, and the library went on the back burner. I suggest emailing me the changes and posting them to the newsgroup. The former means I won't miss them in the flood of messages here, and the latter means that others can use them immediately and/or comment on them. Many proposed additions I have no idea whether they are widely useful enough to be in Phobos or not; posting them in the n.g. will help with that. I don't want to fill Phobos up with functions of marginal utility, it needs to be widely useful, core building blocks. Some help making that determination would be much appreciated. It's fine for me if diffs are mailed, for small changes. For wholesale changes, the whole file would be better.
Mar 29 2005
parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <d2cb5d$2757$1 digitaldaemon.com>, Walter says...
 ...

I suggest emailing me the changes and posting them to the newsgroup. The
former means I won't miss them in the flood of messages here, and the latter
means that others can use them immediately and/or comment on them. Many
proposed additions I have no idea whether they are widely useful enough to
be in Phobos or not; posting them in the n.g. will help with that. I don't
want to fill Phobos up with functions of marginal utility, it needs to be
widely useful, core building blocks. Some help making that determination
would be much appreciated.

 ...
Ok, here's the code that I sent to Walter that I thought would be very useful to all, which I thought would complete std.conv to handle all the numerical data types. Please, feel free to improve, and / or give comments. The original message, "Extending std.conv with floating-point wrapper functions" posted 09.Nov.04 can be found here: (http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/12382) Also I've eMailed this code below to Walter on 03.Mar.05 for extending std.conv for floating-point conversions. The main point being: that since there are toString() functions in std.string to change floating points into char[]s, why couldn't I find any functions to change them back to floating point? Therefore, it seemed a bit odd to me why std.conv was so incomplete...since it did only whole number conversions; so I decided to write some D code (that's below) to solve that issue. --------------------------------- This is same code that I eMailed to Walter for inclusion into std.conv. David L. ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Mar 29 2005