On Wednesday, July 24, 2013 17:45:53 Nick Treleaven wrote:
> Also is there any info on std.io? I assume it's still worthwhile to update std.stdio docs and fix issues?

It is unknown when std.io will be ready for review, and the person working on it is quite busy. We certainly want to continue to fix issues in std.stdio. What is more questionable is adding a lot of functionality to it. But bug fixes and the like should be fine, and I'm sure that some new functionality would be fine as well. We definitely don't want to make major changes to it though, since we intend to replace it.

- Jonathan M Davis

On Wed, Jul 24, 2013 at 08:17:08PM -0400, Jonathan M Davis wrote:
> On Wednesday, July 24, 2013 17:45:53 Nick Treleaven wrote:
> > Also is there any info on std.io? I assume it's still worthwhile to update std.stdio docs and fix issues?
> 
> It is unknown when std.io will be ready for review, and the person
> working on it is quite busy. We certainly want to continue to fix
> issues in std.stdio.  What is more questionable is adding a lot of
> functionality to it. But bug fixes and the like should be fine, and
> I'm sure that some new functionality would be fine as well. We
> definitely don't want to make major changes to it though, since
> we intend to replace it.
[...]

This makes me wonder if we should adopt a convention of using a public fork/branch on GitHub when working on a new feature. That way, if the person who started it can't work on it for whatever reason (too busy IRL, working on other things, etc.), somebody else can step up and continue the work, instead of the work being stalled without any definite target completion time.

With GitHub, something like this is not only practical, but probably also beneficial. For example, recently, I started working on a D port of gdc's gdmd wrapper. After I got the initial functionality working, I got busy with other stuff, but thanks to the code being available on github, somebody else could step in and contribute pull requests. So development continues in spite of me being unable to work on it at the moment.  And sometimes, receiving pull requests on your branch is a big motivation for you to get cracking on the code again. :)

For something as crucial as std.io (or other key Phobos components, in general), I think this kind of approach is probably necessary. It doesn't help our public image at all if people take a look at our situation and say, "what's up with these D people, why is there only one person working on key feature X and no progress is made because that person is too busy". To improve our professionalism, this situation ought to be improved.

Not to mention, like this also helps improve our bus factor when it comes to key pieces of new functionality.


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.

On Thursday, 25 July 2013 at 01:57:45 UTC, H. S. Teoh wrote:
> On Wed, Jul 24, 2013 at 08:17:08PM -0400, Jonathan M Davis wrote:
>> On Wednesday, July 24, 2013 17:45:53 Nick Treleaven wrote:
>> > Also is there any info on std.io? I assume it's still worthwhile to
>> > update std.stdio docs and fix issues?
>> 
>> It is unknown when std.io will be ready for review, and the person
>> working on it is quite busy. We certainly want to continue to fix
>> issues in std.stdio.  What is more questionable is adding a lot of
>> functionality to it. But bug fixes and the like should be fine, and
>> I'm sure that some new functionality would be fine as well. We
>> definitely don't want to make major changes to it though, since we intend to replace it.
> [...]
>
> This makes me wonder if we should adopt a convention of using a public
> fork/branch on GitHub when working on a new feature. That way, if the
> person who started it can't work on it for whatever reason (too busy
> IRL, working on other things, etc.), somebody else can step up and
> continue the work, instead of the work being stalled without any
> definite target completion time.
>
> With GitHub, something like this is not only practical, but probably
> also beneficial. For example, recently, I started working on a D port of
> gdc's gdmd wrapper. After I got the initial functionality working, I got
> busy with other stuff, but thanks to the code being available on github,
> somebody else could step in and contribute pull requests. So development
> continues in spite of me being unable to work on it at the moment.  And
> sometimes, receiving pull requests on your branch is a big motivation
> for you to get cracking on the code again. :)
>
> For something as crucial as std.io (or other key Phobos components, in
> general), I think this kind of approach is probably necessary. It
> doesn't help our public image at all if people take a look at our
> situation and say, "what's up with these D people, why is there only one
> person working on key feature X and no progress is made because that
> person is too busy". To improve our professionalism, this situation
> ought to be improved.
>
> Not to mention, like this also helps improve our bus factor when it
> comes to key pieces of new functionality.
>
>
> T

https://github.com/schveiguy/phobos/blob/new-io/std/io.d

(which I amusingly found the URL of by Googling "std.io github site:dlang.org" and found a reply I made to you [1] with this URL back in February).

I wonder if Steve could be convinced to write up a TODO for std.io of where he left off.

1. http://forum.dlang.org/post/sbmntkiwhnmpcrfypvpw@forum.dlang.org

On 24/07/2013 18:53, Jakob Ovrum wrote:
> On Wednesday, 24 July 2013 at 17:26:58 UTC, Peter Alexander wrote:
>> On Wednesday, 24 July 2013 at 17:13:10 UTC, Jakob Ovrum wrote:
>>>     auto newlinePattern = ctRegex!"[\r\n]+";
>>
>> That will swallow empty lines.
>
> Yeah, it's just an example. The specific pattern obviously depends on
> the exact behaviour you want, but I think any desired behaviour
> regarding newlines can be trivially expressed with regex.

Nice idea, I wasn't aware of regex splitter. I'll try using:

auto newlinePattern = ctRegex!"\r\n|\r|\n";

In fact, if we add unicode line & paragraph separators to the pattern (like std.string.splitLines), that literal might be worthy of adding to std.regex.

On 25/07/2013 01:17, Jonathan M Davis wrote:
> On Wednesday, July 24, 2013 17:45:53 Nick Treleaven wrote:
>> Also is there any info on std.io? I assume it's still worthwhile to
>> update std.stdio docs and fix issues?
>
> It is unknown when std.io will be ready for review, and the person working on
> it is quite busy. We certainly want to continue to fix issues in std.stdio.
> What is more questionable is adding a lot of functionality to it. But bug fixes
> and the like should be fine, and I'm sure that some new functionality would be
> fine as well. We definitely don't want to make major changes to it though, since
> we intend to replace it.

Thanks for the info.

On 25/07/2013 03:22, Brad Anderson wrote:
> https://github.com/schveiguy/phobos/blob/new-io/std/io.d

Thanks, now added to the wiki:
http://wiki.dlang.org/Review_Queue#Current_Review_Queue