Please correct me if I'm wrong.
It's not the allocation itself that is the problem it's that it will trigger the GC to stop the world at some point.

On Friday, 12 April 2013 at 08:14:25 UTC, Manu wrote:
> ...

While I generally agree with your point, std.process is hardly the place to start from. It is not performance-critical functionality and it is not basic functionality that may be used in other critical modules. It is blaming consequences instead of reasons, not really practical.

On Friday, 12 April 2013 at 07:53:04 UTC, Manu wrote:
> Honestly, any new module could have appeared for approval at this
> particular moment and I would have made the same criticisms.

Observation: this move wasn't something I would encourage. Jesse, the review manager for std.process, has specifically asked:

> Please place any further comments in the official review thread leaving only your vote and a short comment (there should be no need to reply to anyone).

There was ample time to discuss std.process during the informal and formal review. However, the situation with your replies is even worse: they don't even concern std.process in particular. Please consider starting a new thread next time, and stating your criticism aside to whatever poor module comes up the review queue ;)

On Friday, 12 April 2013 at 07:53:04 UTC, Manu wrote:
> On 12 April 2013 17:30, Vladimir Panteleev <vladimir@thecybershadow.net>wrote:
>
>> On Friday, 12 April 2013 at 07:22:42 UTC, Manu wrote:
>>
>>> I agree that spawning processes is a low-frequency operation, but it's a
>>> principle I'm trying to illustrate here.
>>>
>>
>> My point was that it is not that it's low-frequency, it's that the OS
>> process creation operation is so expensive, that a few memory allocations
>> will not make much of a difference in comparison. It's the same as
>> optimizing memory allocations in a program which is intrinsically disk- or
>> network-bound.
>
>
> Which OS are we talking about?
> What OS runs on an a Nintendo Wii? There's only 24mb of system memory in
> that machine, can we afford to allocate it frivolously?
>
> Will I avoid phobos as a policy? Yes.
>
>

Do you create process at all?

I always had the impression those environments used real time OS like libraries and multitasking is achieved by co-routines or threads, not real processes.

Just a dummy comment from an industry outsider.

--
Paulo

Yes.

On 12 April 2013 18:18, Vladimir Panteleev <vladimir@thecybershadow.net>wrote:

> On Friday, 12 April 2013 at 07:53:04 UTC, Manu wrote:
>
>> Which OS are we talking about?
>> What OS runs on an a Nintendo Wii? There's only 24mb of system memory in
>> that machine, can we afford to allocate it frivolously?
>>
>
> I wasn't aware that writing games for the Wii involves creating processes in the thousands.


Again, I'm just suggesting possibilities, and trying to illustrate that it's a STANDARD library, you can never predict where users will want to use it.


 I don't necessarily disagree with your point (although I don't agree
>> either). Perhaps in the context of std.process it's not so important...
>> but
>> it's still an opportunity to set a precedent.
>> Honestly, any new module could have appeared for approval at this
>> particular moment and I would have made the same criticisms. Not
>> necessarily picking on std.process in particular, I'm making a point about
>> phobos, and what is considered acceptable.
>>
>
> Don't forget that shifting focus when adjusting goals is always a question of tradeoffs. Sacrificing tersity, maintainability, usability, safety etc. for the sake of performance would be a poor move in the case of std.process.
>

Can you perhaps quantify how any of those things would be reduced by
addressing at least the details I highlight?
I'm basically advocating making a habit of using the stack where possible.
It's not exactly hard, or cryptic.

On 12 April 2013 18:21, Manipulator <volcz@kth.se> wrote:

> Please correct me if I'm wrong.
> It's not the allocation itself that is the problem it's that it will
> trigger the GC to stop the world at some point.
>

It's just another source of garbage. Which means this function of off limits beneath a routine that's disabled collection, for instance. There are lots of reasons to avoid making unnecessary garbage.

On 12 April 2013 18:21, Dicebot <m.strashun@gmail.com> wrote:

> On Friday, 12 April 2013 at 08:14:25 UTC, Manu wrote:
>
>> ...
>>
>
> While I generally agree with your point, std.process is hardly the place to start from. It is not performance-critical functionality and it is not basic functionality that may be used in other critical modules. It is blaming consequences instead of reasons, not really practical.
>

And I generally agree with your point. Like I said, I would have made this criticisms of whatever came alone ;)

Am Fri, 12 Apr 2013 17:04:08 +1000
schrieb Manu <turkeyman@gmail.com>:

> 
> I've said before, I sadly have to avoid phobos like the plague. Some modules (like this one) that provide fundamental functionality - not just helper functions - can't be avoided. Requirements for those should be extra strict in my opinion.
> 

Most (GC) allocations could be fixed without breaking the API. I can
see 2 places where the API forces _GC_ allocations:
* string[string]
* thrown Exceptions are allocated with the GC

There is no simple solution for these. Maybe we'll have a hashtable in the standard library at some point which will allow to use custom allocators. Then std.process could use these. Exceptions require some thinking. You can of course allocate them using any allocator, but freeing them is difficult...

If you want to get rid of all (not only GC) allocations, there's another issue: As D strings are not zero terminated we'll always have allocations passing those to C code. Maybe we should have a cstring type in phobos which would just be a string which is guaranteed to be zero terminated.

http://dpaste.dzfl.pl/e76aa995 (needs some inout though)

Am Fri, 12 Apr 2013 06:46:51 +0200
schrieb "Jesse Phillips" <Jessekphillips+d@gmail.com>:

> It is that time, If you would like to see the proposed std.process include into Phobos please vote yes. If one condition must be met specify under what condition, otherwise vote no.
> 
> std.process by Lars Kyllingstad and Steven Schveighoffer is a suggested improvement to the existing std.process and is a major change to the API. The original API remains but these will be going through deprecation.
> 
> In summary of the discussion there was concern of the use of Error and Exception. Lars is very interested in getting the standard hierarchy http://wiki.dlang.org/DIP33 thus leaving these at the safest level to allow for change without breaking code.
> 
> Please place any further comments in the official review thread leaving only your vote and a short comment (there should be no need to reply to anyone).
> 
> Docs: http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process.html
> 
> Source: https://github.com/kyllingstad/phobos/blob/std-process2/std/process.d
> 
> Friday April 19 PST will be the last day of voting.

Yes!