On Saturday, February 23, 2013 19:47:54 Nathan M. Swan wrote:
> Jonathan M Davis wrote:
> > On Saturday, February 23, 2013 18:39:10 H. S. Teoh wrote:
> >> Alternatively, I would push for renaming the old std.process to something like old.process (or something else), which is much less of a breakage than deleting it from Phobos outright -- existing code just need to have their imports fixed and will continue working, whereas deleting the module outright leaves existing code with no recourse but to potentially rewrite from scratch. This may be easier to convince Walter & Andrei on, than outright killing old deprecated modules.
> > 
> > Possibly, but Walter takes a very dim view on most any code breakage, even if it means simply changing a makefile to make your code work again, so I'd be very surprised if he thought that moving the current std.process would be acceptable. If Andrei could be convinced, then we could probably do it, but I wouldn't expect him to agree, and IIRC, he had no problem with the std.process2 scheme and might even have suggested it. So, I suspect that your only hope of avoiding std.process2 is if you can come up with a better name.
> > 
> > - Jonathan M Davis
> 
> Why not just deprecate everything currently in std.process and drop in the new stuff? It might be a bit ugly, but it prevents both code breakage _and_ a proliferation of "std.module2"s.

That only works if there are no conflicts and none of the functions' behaviors are changed in a manner which would be incompatible with how they currently work. We _were_ able to do exactly what you're suggesting with std.path, but it isn't always possible. std.random would be a prime case where it would be a problem, because one of the main changes that we want to do is translate all of its structs into classes, which would break a lot of code, and wouldn't be compatible at all - not unless you come up with new names for everything, which would be downright ugly. I don't know how much the new std.process conflicts with the old one, but since the main fellow behind the new one is the same one who did the new std.path, I suspect that they conflict to much to be able to do the transition within a single module. I'd have to compare them to be sure though.

- Jonathan M Davis

On 24-02-2013 01:27, Jakob Bornecrantz wrote:
> 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.

Yes, Lars pulled in ~all of my changes.

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

On 2/24/13 4:58 AM, H. S. Teoh wrote:
> I find this rather frustrating... sometimes it feels like Phobos is
> suffering from premature standardization - we have a module with a
> design that isn't very good, but just because it somehow got put into
> Phobos, now it has to stick, no matter what.

It's a good sign - growing pains and acquiring users and all. Python broke even "hello, world" from one major release to another.

Andrei

On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
> Phobos modules which already use std.process would have to be changed
> to directly import std.process1 or std.process2.

This is problematic as has been discussed. I think we could address immediate needs by attaching an attribute to import, e.g.:

@"v2.070+" import std.process;

or similar. By default code would import the old library.


Andrei

On 02/23/2013 08:39 PM, H. S. Teoh wrote:
> On Sat, Feb 23, 2013 at 05:32:08PM -0800, Jonathan M Davis wrote:
>> 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:
> [...]
>>>> 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.
> [...]
>
> Well, std.regexp got lucky, in that the new module has a subtly
> different name std.regex, so we can just eventually stop documenting
> std.regexp but leave it in the codebase for whatever old code that uses
> it to continue working. Ditto with the upcoming std.io to replace
> std.stdio.
>
> But I can't think of any better name for the new std.process. :-( I'd
> suggest std.proc, but I'm pretty sure it will get shot down as it's too
> short and ambiguous (it could be misinterpreted as std.procedure for
> example).
>
> Alternatively, I would push for renaming the old std.process to
> something like old.process (or something else), which is much less of a
> breakage than deleting it from Phobos outright -- existing code just
> need to have their imports fixed and will continue working, whereas
> deleting the module outright leaves existing code with no recourse but
> to potentially rewrite from scratch. This may be easier to convince
> Walter&  Andrei on, than outright killing old deprecated modules.
>
>
> T
>
+1

On 02/23/2013 09:07 PM, Jonathan M Davis wrote:
> On Saturday, February 23, 2013 18:58:28 H. S. Teoh wrote:
>> I suppose std.proc is out of the question? ;-)
>
> I don't know. Maybe.
>
>> I find this rather frustrating... sometimes it feels like Phobos is
>> suffering from premature standardization - we have a module with a
>> design that isn't very good, but just because it somehow got put into
>> Phobos, now it has to stick, no matter what. That's what we should do
>> *after* we have a good design, but at this point, the current
>> std.process clearly isn't ready to be cast in stone yet, yet we insist
>> it can't be changed (at least, not easily). So every little design
>> mistake that got overlooked in review and made it into Phobos becomes
>> stuck, even when the design is really only experimental to begin with.
>
> To some extent, I agree, but at the same time, we're taking forever to
> stabilize things, and unless we do, D will never take off, because no one will
> be able to rely on its API.
>
>> I think we should seriously consider the idea someone brought up in this
>> forum recently, of an experimental section of Phobos where new stuff is
>> put in, and subject to actual field-testing (as opposed to just toy test
>> cases when it was written), before it goes into Phobos proper.
>
> I definitely think that this should be considered. I think that it's often the
> case that the stuff that makes it into Phobos was either created specifically
> for Phobos (and didn't get much use ahead of time), or it's someone's personal
> module that they thought would be useful (in which case, it may have gotten
> heavy use from them but not by many people besides them). And freezing APIs
> before they've been field-tested means that we'll be permanently stuck with
> subpar APIs.
>
>> I really
>> do not want to see this problem repeated over and over, and we end up
>> with 15 modules with 2 or 3 appended to their name just because nothing
>> can be changed after it's put in. It really detracts from D's
>> presentability, esp. to outsiders and prospective new users, IMO.
>
> I honestly wouldn't expect many modules to be replaced outright. It's mostly
> just the older ones which risk that. But if ever have to do that with modules
> that went through the full review process, then we need to rethink how that's
> done. A propationary area for modules (where they're in Phobos but not in std
> yet) may very well help mitigate any such problems.
>
> - Jonathan M Davis

std.future.process;

and we've talked about it too much at this point. It will never be done.

On Sunday, February 24, 2013 10:05:01 Andrei Alexandrescu wrote:
> On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
> > Phobos modules which already use std.process would have to be changed to directly import std.process1 or std.process2.
> 
> This is problematic as has been discussed. I think we could address immediate needs by attaching an attribute to import, e.g.:
> 
> @"v2.070+" import std.process;
> 
> or similar. By default code would import the old library.

An interesting idea, but someone would have to implement it, which could delay adding the new std.process to Phobos. Of course, if we take approach of putting new modules in a different place initially as we've occasionally discussed (e.g. experimental.process or future.process) in order to make sure that they're fully ironed out from actual, widespread, real-world use before freezing their APIs, then that would give us more time to implement such a feature before moving the module to std.process.

- Jonathan M Davis

24-Feb-2013 12:05, Andrei Alexandrescu пишет:
> On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
>> Phobos modules which already use std.process would have to be changed
>> to directly import std.process1 or std.process2.
>
> This is problematic as has been discussed. I think we could address
> immediate needs by attaching an attribute to import, e.g.:
>
> @"v2.070+" import std.process;
>
> or similar. By default code would import the old library.

The same could be achieved by simply using old version of compiler+druntime+phobos to compile old project.

I don't get the desire to keep old junk forever. A year or two - maybe. More then this is just insane.

>
>
> Andrei
>


-- 
Dmitry Olshansky

On Sunday, February 24, 2013 13:06:00 Dmitry Olshansky wrote:
> 24-Feb-2013 12:05, Andrei Alexandrescu пишет:
> > On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
> >> Phobos modules which already use std.process would have to be changed to directly import std.process1 or std.process2.
> > 
> > This is problematic as has been discussed. I think we could address immediate needs by attaching an attribute to import, e.g.:
> > 
> > @"v2.070+" import std.process;
> > 
> > or similar. By default code would import the old library.
> 
> The same could be achieved by simply using old version of compiler+druntime+phobos to compile old project.
> 
> I don't get the desire to keep old junk forever. A year or two - maybe. More then this is just insane.

I agree, but it _is_ more than a question of keeping old junk around in this case. We need a we to transition cleanly, and the only way at present that that means not breaking code is to put the new std.process somewhere other than std.process, since if we put it in std.process, it would mean breaking a lot of code which uses the current std.process, forcing everyone to stick with the old compiler until they'd updated their code. And we don't want that.

Whether the old std.process sticks around for more than a year or two is therefore a separate matter from what we name the new std.process unless we add a feature like Andrei is suggesting.

- Jonathan M Davis

24-Feb-2013 13:17, Jonathan M Davis пишет:
> On Sunday, February 24, 2013 13:06:00 Dmitry Olshansky wrote:
>> 24-Feb-2013 12:05, Andrei Alexandrescu пишет:
>>> On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
>>>> Phobos modules which already use std.process would have to be changed
>>>> to directly import std.process1 or std.process2.
>>>
>>> This is problematic as has been discussed. I think we could address
>>> immediate needs by attaching an attribute to import, e.g.:
>>>
>>> @"v2.070+" import std.process;
>>>
>>> or similar. By default code would import the old library.
>>
>> The same could be achieved by simply using old version of
>> compiler+druntime+phobos to compile old project.
>>
>> I don't get the desire to keep old junk forever. A year or two - maybe.
>> More then this is just insane.
>
> I agree, but it _is_ more than a question of keeping old junk around in this
> case. We need a we to transition cleanly, and the only way at present that
> that means not breaking code is to put the new std.process somewhere other
> than std.process, since if we put it in std.process, it would mean breaking a
> lot of code which uses the current std.process, forcing everyone to stick with
> the old compiler until they'd updated their code. And we don't want that.

I suppose it's easy to translate any active project (as in maintained) to the new std.process, as it's supposed to have easier/richer interface.

Then any old cruft that just works and there is no need to touch it can just use the older version of _compiler_. In any case the phrase "old code that needs to use new std.process" is kind of perplexing.

> Whether the old std.process sticks around for more than a year or two is
> therefore a separate matter from what we name the new std.process unless we
> add a feature like Andrei is suggesting.

Maybe I'm missing something but I don't see this feature solving anything yet.

-- 
Dmitry Olshansky