April 12, 2013 Re: Vote for std.process | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tove | On Fri, 12 Apr 2013 16:32:37 -0400, Tove <tove@fransson.se> wrote: > On Friday, 12 April 2013 at 20:24:05 UTC, Steven Schveighoffer wrote: >> On Fri, 12 Apr 2013 15:26:12 -0400, Tove <tove@fransson.se> wrote: >> >> >> So for the most convenient/common case, you want to add an allocation? >> > > with the original proposal there is one anyway... I meant add an additional allocation to what is there. There needs to be one allocation to collect all the variables into one long string (on Windows), and with your suggestion, it has to go through an intermediate "key=value" format. > But with my suggested approach you could create many processes reusing the same env... only paying the conversion/allocation cost once(outside of the loop). This would be attractive. But I still want a indexable object. Having to generate a=b strings is awkward. It could be something that does the right thing on POSIX (generate "a=b" under the hood) or Windows (Probably can cache the generated environment string). -Steve |
April 12, 2013 Re: Vote for std.process | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Friday, 12 April 2013 at 20:52:55 UTC, Steven Schveighoffer wrote:
> On Fri, 12 Apr 2013 16:32:37 -0400, Tove <tove@fransson.se> wrote:
>
>> On Friday, 12 April 2013 at 20:24:05 UTC, Steven Schveighoffer wrote:
>>> On Fri, 12 Apr 2013 15:26:12 -0400, Tove <tove@fransson.se> wrote:
>>>
>>>
>>> So for the most convenient/common case, you want to add an allocation?
>>>
>>
>> with the original proposal there is one anyway...
>
> I meant add an additional allocation to what is there. There needs to be one allocation to collect all the variables into one long string (on Windows), and with your suggestion, it has to go through an intermediate "key=value" format.
>
>> But with my suggested approach you could create many processes reusing the same env... only paying the conversion/allocation cost once(outside of the loop).
>
> This would be attractive. But I still want a indexable object.
> Having to generate a=b strings is awkward.
>
> It could be something that does the right thing on POSIX (generate "a=b" under the hood) or Windows (Probably can cache the generated environment string).
>
> -Steve
Hmhm, I see your point. Could our custom indexable object have
'alias this' to an 'union env'? which is the in param to the process api?
|
April 13, 2013 Re: Vote for std.process | ||||
---|---|---|---|---|
| ||||
Posted in reply to angel | All progress requires risk. My vote is: YES |
April 13, 2013 Re: Vote for std.process | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | On Friday, 12 April 2013 at 04:46:52 UTC, Jesse Phillips wrote:
> 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.
Yes.
|
April 13, 2013 Re: Vote for std.process | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | On 2013-04-12 16:04, Jesse Phillips wrote: > I think this needs to happen prior to the formal review/voting. I would > say it should be a precursor to starting the official review, however > this would raise the bar too high for things like Jacob's Serialization > library; he has a working library, but it isn't ready for Phobos and it > would be silly to require the translation prior to approving it for Phobos. What's left is basically just to put it under the std namespace and convert tabs to spaces. -- /Jacob Carlborg |
April 13, 2013 Re: Vote for std.process | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | YES |
April 13, 2013 Re: Vote for std.process | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On 04/12/2013 10:14 AM, Manu wrote: > 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. It is only a single runtime call to _d_arraycatnT which precomputes the resulting length. https://github.com/D-Programming-Language/druntime/blob/e5415ed4f0638fcd1d0f8e06aec4197ad108449f/src/rt/lifetime.d#L2031 |
April 14, 2013 Re: Vote for std.process | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | On Friday, 12 April 2013 at 04:46:52 UTC, Jesse Phillips wrote:
> 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.
Yes
|
April 16, 2013 Re: Vote for std.process | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | Yes |
Copyright © 1999-2021 by the D Language Foundation