On 12 April 2013 17:35, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
On Fri, 12 Apr 2013 03:04:08 -0400, Manu <turkeyman@gmail.com> wrote:
string[string] is used in the main API to receive environment variables;
perhaps kinda convenient, but it's impossible to supply environment
variables with loads of allocations.

I think you meant "without"?

Yes.


What would be your suggestion?  string[string] is the built-in map type.  How do you pass an environment map without having some allocations?

I'd use string[].


toStringz is used liberally; alternatively, alloca() could allocate the
c-string's on the stack and zero terminate them there, passing a pointer to
the stack string to the OS functions.

This would be a lot of effort for pretty much zero gain for the majority of cases.

A trivial ... mixin template (?) could wrap it up, I don't see it particularly less convenient than calling toStringz().
Perhaps there are other tools missing from phobos if this is somehow hard...


String concatenation is rampant! Look at this code to parse the env
variables (which are already an AA):

    foreach (var, val; childEnv)
        envz[pos++] = (var~'='~val~'\0').ptr;

This could be improved.  It could also be optimized into a single allocation automatically by the compiler (it might already be).  The API would not be affected by this improvement, though.

I've never seem the compiler apply that optimisation, although I often wish it would.
I saw an appender appear a few pages below, that would be an improvement here too I guess. 


And many many more of the same...

This is a lib that spawns a process, I can't imagine why this library
should need to allocate a single byte, but it allocates wildly just to
perform a trivial pass-through to the OS.

It is not a trivial pass-through.  Different OSes require different parameter types.  Look at the difference between the windows and posix implementations.  We are writing a cross-platform library, so whatever we pick will have to be converted on at least one OS.

Writing cross-platform code is my life.
They are trivial conversions. It could be done on the stack easily.
Granted, ideally the compiler could theoretically perform some of those improvements, but it doesn't, and probably depends on other changes to be able to do so anyway.
For instance, the compiler couldn't confidently lower the allocations to the stack unless 'scope' arguments worked, so it knew it wouldn't escape the OS call it was being handed to.


This module is no exception either, basically all of phobos is like this,
and I'd like to see careful consideration made to these details in the
future.

I too like to avoid memory allocations.  But the level to which you require is too stringent.  Not even Tango, which made low heap-allocations a priority, avoided allocations in it's process library.

But it would be trivial to use the stack in these cases. It doesn't matter if it adds a few lines under the hood.

I'm really just trying to make the point that it should ALWAYS be a key consideration, and people should make it habit to think about/criticise these things when accepting code into phobos.
This is the standard library, it will be used in more D code than any other library ever. Why skimp here?


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.

We cannot cater to all developers.

In this case you certainly can, it would be fairly trivial to do.


 To put all developers through a lot of pain in order to attract the fringe ones is not a practical goal.

What pain? Are you saying a stack variable is somehow hard?
If that's the case, then there's clearly some other fundamental tools missing from phobos.


I think the convenience of std.process is what it is there for.  For the highest performance, you are able to call the OS functions directly.

No, it's to save (ideally) _all_ programmers the effort of rewriting this module themselves.
This is exactly the sort of thing I waste loads of my life doing, rewriting wheels because the author was a PC programmer, and simply didn't give a shit.
What a waste of life >_<

I re-iterate, maybe my points aren't of critical importance in relation to std.process specifically, I'm trying to raise some general issues with phobos submissions (that shouldn't exclude std.process either).