On Saturday, February 23, 2013 16:09:43 H. S. Teoh wrote:
> BTW, is "std.process2" just the temporary name, or are we seriously going to put in a "std.process2" into Phobos? I'm hoping the former, as the latter is unforgivably ugly.

In previous discussions, it was agreed that future replacement modules would simply have a number appended to them like that (e.g. std.xml2 or std.random2). I don't think that that decision is irreversible, but unless someone can come up with a much better name, I'd expect it to stick, and it has the advantage of making it very clear that it's replacing the old one.

- Jonathan M Davis

On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T. Kyllingstad wrote:
> It's been years in the coming, but we finally got it done. :)  The upshot is that the module has actually seen active use over those years, both by yours truly and others, so hopefully the worst wrinkles are already ironed out.
>
> Pull request:
> https://github.com/D-Programming-Language/phobos/pull/1151
>
> Code:
> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>
> Documentation:
> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html
>
> I hope we can get it reviewed in time for the next release.  (The wiki page indicates that both std.benchmark and std.uni are currently being reviewed, but I fail to find any "official" review threads on the forum.  Is the wiki just out of date?)

Does these include the changes that Alex/Zor did on it? I
submitted a "bug" report that he fixed.

Cheers, Jakob.

On Saturday, February 23, 2013 19:21:26 Steven Schveighoffer wrote:
> On Sat, 23 Feb 2013 18:59:05 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > I don't know what the new std.process is doing (I haven't look at it
> > yet), but
> > if it's throwing exceptions based on errno, it needs to at least put the
> > error
> > code in the exception and maybe have specific exception types if it
> > would make
> > sense to be catching exceptions from std.process based on what exactly
> > went
> > wrong. Get the value of errno after catching the exception is just
> > asking for
> > it, since who knows what code ran after the exception was originally
> > thrown.
> 
> It uses strerror to get the errno string representation, and uses that as the message.
> 
> I think it should also save the error code.
> 
> In a past life, I had a SystemException type (this was C++), and anything that died because of an errno error would throw a derivative of that, containing an errno copy.  If we already have a base ErrnoException, we ProcessException probably should derive from that.

Possibly, but you have to be a bit careful with that. For instance, std.file.FileException is in a weird place, because sometimes a FileException comes from errno and sometimes not, which means that if it were made to derive from ErrnoException, it could be a problem. ProcessException may not have that problem, but that sort of issue should be considered when deciding its inheritance hierarchy. If we had multiple inheritance, it would be an easier decision, but we don't. But an minimum, there should be a way to access the error code from errno if that's where an exception originated from (even if it's just that it's an exception that has ErrnoException as its next).

- Jonathan M Davis

On Sat, 23 Feb 2013 19:25:33 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Saturday, February 23, 2013 16:09:43 H. S. Teoh wrote:
>> BTW, is "std.process2" just the temporary name, or are we seriously
>> going to put in a "std.process2" into Phobos? I'm hoping the former, as
>> the latter is unforgivably ugly.
>
> In previous discussions, it was agreed that future replacement modules would
> simply have a number appended to them like that (e.g. std.xml2 or
> std.random2). I don't think that that decision is irreversible, but unless
> someone can come up with a much better name, I'd expect it to stick, and it
> has the advantage of making it very clear that it's replacing the old one.
>

Yeah, I don't want to get into this discussion again.  There are better ways (at least IMO :), but they were not favored.

Once std.process2 is accepted, and in use for a long time, we can probably deprecate std.process.  But I don't know if std.process2 would then be renamed.  I can't remember what was decided.

-Steve

On Sat, Feb 23, 2013 at 04:25:33PM -0800, Jonathan M Davis wrote:
> On Saturday, February 23, 2013 16:09:43 H. S. Teoh wrote:
> > BTW, is "std.process2" just the temporary name, or are we seriously going to put in a "std.process2" into Phobos? I'm hoping the former, as the latter is unforgivably ugly.
> 
> In previous discussions, it was agreed that future replacement modules would simply have a number appended to them like that (e.g. std.xml2 or std.random2). I don't think that that decision is irreversible, but unless someone can come up with a much better name, I'd expect it to stick, and it has the advantage of making it very clear that it's replacing the old one.
[...]

Ugh. I don't like this. I can see where it's coming from, and why it's necessary (to avoid breaking tons of code relying on the old API), but I really don't like it. It leads to the ugly situation of code that relies on both std.xyz7 and std.xyz19, just because parts of the code were written at different times, and it's too much work to clean up, which leaves people who read the code having to remember how version 19 of xyz differed from version 7.

Unless we go through a deprecation process (no pun intended) where std.process2 is a temporary name until the old std.process is phased out, then std.process2 is renamed to std.process (perhaps leaving a wrapper public import in std.process2).

I would really hate to see Phobos deteriorate into a situation of std.algorithm5, std.io7, std.regex4, std.process3, std.range5, where nobody can remember which version of which module is the most current without looking it up, just because we have to keep all the old names for backwards-compatibility.


T

-- 
Why do conspiracy theories always come from the same people??

On Sat, 23 Feb 2013 19:44:29 -0500, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Sat, Feb 23, 2013 at 04:25:33PM -0800, Jonathan M Davis wrote:
>> On Saturday, February 23, 2013 16:09:43 H. S. Teoh wrote:
>> > BTW, is "std.process2" just the temporary name, or are we seriously
>> > going to put in a "std.process2" into Phobos? I'm hoping the former,
>> > as the latter is unforgivably ugly.
>>
>> In previous discussions, it was agreed that future replacement modules
>> would simply have a number appended to them like that (e.g. std.xml2
>> or std.random2). I don't think that that decision is irreversible, but
>> unless someone can come up with a much better name, I'd expect it to
>> stick, and it has the advantage of making it very clear that it's
>> replacing the old one.
> [...]
>
> Ugh. I don't like this. I can see where it's coming from, and why it's
> necessary (to avoid breaking tons of code relying on the old API), but I
> really don't like it. It leads to the ugly situation of code that relies
> on both std.xyz7 and std.xyz19, just because parts of the code were
> written at different times, and it's too much work to clean up, which
> leaves people who read the code having to remember how version 19 of xyz
> differed from version 7.
>
> Unless we go through a deprecation process (no pun intended) where
> std.process2 is a temporary name until the old std.process is phased
> out, then std.process2 is renamed to std.process (perhaps leaving a
> wrapper public import in std.process2).
>
> I would really hate to see Phobos deteriorate into a situation of
> std.algorithm5, std.io7, std.regex4, std.process3, std.range5, where
> nobody can remember which version of which module is the most current
> without looking it up, just because we have to keep all the old names
> for backwards-compatibility.

I'm not sure this would happen.  In order for a module to be "renumbered", it needs to be a complete rewrite from scratch, with no common ancestry.  If we have anything that goes to 3, something is wrong.  We should not be approving new designs if we plan to get rid of them later.

There are several modules in Phobos that are/were so bad they need to be rewritten from scratch.  std.process, std.xml are the two that come off the top of my head.  These were written back when Phobos was very young and foolish, and accepted any old design that a random programmer came up with.

std.range, std.algorithm, std.regex are all pretty safe, they aren't going to be rewritten unless something catastrophic is discovered in them that invalidates their entire design.  In fact, I think all of these were rewritten already.

So I think we just have to deal with it.  Just think, you will know some trivia when you are teaching D to some young developer someday :)

-Steve

On Saturday, February 23, 2013 19:32:48 Steven Schveighoffer wrote:
> Yeah, I don't want to get into this discussion again.  There are better ways (at least IMO :), but they were not favored.
> 
> Once std.process2 is accepted, and in use for a long time, we can probably deprecate std.process.  But I don't know if std.process2 would then be renamed.  I can't remember what was decided.

We might be able to remove std.process eventually and then rename std.process2 to std.process (leaving std.process2.d to import std.process), but Walter (and to some extent Andrei) seems to be very much in favor of leaving stuff around permanently. It's likely that std.process will be deprecated (which now defaults to warning about it rather than giving an error) and eventually undocumented, but actually killing it off may take a bit of doing given Walter's attitude about code breakage. He seems to be perfectly fine with leaving around old, dead code on the off-chance that some older code is using it and would break if it were removed.

- Jonathan M Davis

On Sat, 23 Feb 2013 20:07:43 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Saturday, February 23, 2013 19:32:48 Steven Schveighoffer wrote:
>> Yeah, I don't want to get into this discussion again.  There are better
>> ways (at least IMO :), but they were not favored.
>>
>> Once std.process2 is accepted, and in use for a long time, we can probably
>> deprecate std.process.  But I don't know if std.process2 would then be
>> renamed.  I can't remember what was decided.
>
> We might be able to remove std.process eventually and then rename std.process2
> to std.process (leaving std.process2.d to import std.process), but Walter (and
> to some extent Andrei) seems to be very much in favor of leaving stuff around
> permanently. It's likely that std.process will be deprecated (which now
> defaults to warning about it rather than giving an error) and eventually
> undocumented, but actually killing it off may take a bit of doing given
> Walter's attitude about code breakage. He seems to be perfectly fine with
> leaving around old, dead code on the off-chance that some older code is using
> it and would break if it were removed.

I don't see std.date around anymore...

-Steve

On Saturday, February 23, 2013 20:14:14 Steven Schveighoffer wrote:
> On Sat, 23 Feb 2013 20:07:43 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > On Saturday, February 23, 2013 19:32:48 Steven Schveighoffer wrote:
> >> Yeah, I don't want to get into this discussion again.  There are better ways (at least IMO :), but they were not favored.
> >> 
> >> Once std.process2 is accepted, and in use for a long time, we can
> >> probably
> >> deprecate std.process.  But I don't know if std.process2 would then be
> >> renamed.  I can't remember what was decided.
> > 
> > We might be able to remove std.process eventually and then rename
> > std.process2
> > to std.process (leaving std.process2.d to import std.process), but
> > Walter (and
> > to some extent Andrei) seems to be very much in favor of leaving stuff
> > around
> > permanently. It's likely that std.process will be deprecated (which now
> > defaults to warning about it rather than giving an error) and eventually
> > undocumented, but actually killing it off may take a bit of doing given
> > Walter's attitude about code breakage. He seems to be perfectly fine with
> > leaving around old, dead code on the off-chance that some older code is
> > using
> > it and would break if it were removed.
> 
> I don't see std.date around anymore...

Yes. I killed it, but Walter has never liked that sort of thing and has been increasingly outspoken about it, and Andrei seems to be jumping on that bandwagon. For instance, IIRC, they both griped about actually removing the deprecated functions from std.string. I'd _very_ much like to get rid of them outright, since they clutter the code and actually were generating errors when used until recently (since they were deprecated before the changes to deprecated). Keeping them around is just plain harmful IMHO, and I may yet manage to kill them off, but they don't seem to like the idea, and I fully expect a similar attitude towards something like std.process. Unfortunately, while replacing old solutions with new, better solutions seems to be fine, it doesn't seem to be okay to actually get rid of the old ones anymore.

- Jonathan M Davis

On Sat, Feb 23, 2013 at 07:59:45PM -0500, Steven Schveighoffer wrote:
> On Sat, 23 Feb 2013 19:44:29 -0500, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
[...]
> >I would really hate to see Phobos deteriorate into a situation of std.algorithm5, std.io7, std.regex4, std.process3, std.range5, where nobody can remember which version of which module is the most current without looking it up, just because we have to keep all the old names for backwards-compatibility.
> 
> I'm not sure this would happen.  In order for a module to be "renumbered", it needs to be a complete rewrite from scratch, with no common ancestry.  If we have anything that goes to 3, something is wrong.  We should not be approving new designs if we plan to get rid of them later.
> 
> There are several modules in Phobos that are/were so bad they need to be rewritten from scratch.  std.process, std.xml are the two that come off the top of my head.  These were written back when Phobos was very young and foolish, and accepted any old design that a random programmer came up with.
> 
> std.range, std.algorithm, std.regex are all pretty safe, they aren't going to be rewritten unless something catastrophic is discovered in them that invalidates their entire design.  In fact, I think all of these were rewritten already.
> 
> So I think we just have to deal with it.  Just think, you will know some trivia when you are teaching D to some young developer someday :)
[...]

Well, in this case, I'd push for a deprecation path for the badly designed modules, so that the current std.process will eventually be phased out and replaced with std.process2, and then we can rename std.process2 to std.process (and leave a public import in std.process2 to maintain compatibility with current code).

I really do not like the name "std.process2". It is exactly the kind of thing that will cause newbies to avoid it and go back to the old badly designed std.process, and then come back to complain about it, then when told to use std.process2, they will wonder "why the 2?". It's just ugly.

OTOH, if we're going to be reorganizing the Phobos module hierarchy, then that may be a good time to get the new std.process into the right name, and leave the old one somewhere else (maybe remain as std.process if the new one goes somewhere else in the hierarchy).


T

-- 
VI = Visual Irritation