On Friday, February 07, 2014 22:15:11 Jakob Ovrum wrote:
> On Friday, 7 February 2014 at 21:24:16 UTC, Brad Anderson wrote:
> > On Friday, 7 February 2014 at 21:05:43 UTC, Jerry wrote:
> >> I'd suggest reversing the arguments:
> >>  void buildPath(IR, OR)(OR result, IR segments)
> >> 
> >>      if (isInputRange!IR && isOutputRange!(OR, char));
> >> 
> >> That way you can use it as:
> >> 
> >> buffer.buildPath(p1, p2, ...);
> >> 
> >> It at least opens up chaining possibilities.
> > 
> > On the other hand the output buffer last allows stuff like this contrived example:
> > 
> > "some/foo/path"
> > 
> >   .splitter("/")
> >   .buildPath(buffer);
> > 
> > I'm not sure what would be more common and useful.
> 
> Those are two different overloads, so I think we could do both.

That's assuming that the same type wouldn't match both parameters, which would be very easy to do if you end up with any ranges that function as both input and output ranges (e.g. dchar[] would match both). I'm not sure how often you'd get an ambiguity error in practice, but it seems risky to me - and it potentially makes it harder to read code that uses it if you can arbitrarily flip the arguments.

- Jonathan M Davis

Am Fri, 07 Feb 2014 16:59:33 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 2/7/14, 3:11 PM, Brad Anderson wrote:
> > On Friday, 7 February 2014 at 23:10:50 UTC, Walter Bright wrote:
> >> On 2/7/2014 2:14 PM, Brad Anderson wrote:
> >>>
> >>> There's always alloca :)
> >>
> >> alloca() cannot be used to allocate stack data in a function enclosing
> >> the current one.
> >
> > Oh, right. Forgot about that.
> 
> You can with a default parameter...
> 
> void fun(void* sneaky = alloca(42));
> 
> will allocate memory on fun caller's frame and make it available to fun.
> 
> I've known this for a while and am not sure whether it's an awesome idiom of the spawn of devil.
> 
> 
> Andrei

I only recently discovered this method, but put it to good use
as well:
https://github.com/mleise/fast/blob/master/source/fast/cstring.d#L134

-- 
Marco

Am 08.02.2014 02:30, schrieb Jonathan M Davis:
> On Friday, February 07, 2014 11:23:30 Lars T. Kyllingstad wrote:
>> On Friday, 7 February 2014 at 10:29:07 UTC, Walter Bright wrote:
>>> On 2/7/2014 2:02 AM, Lars T. Kyllingstad wrote:
>>>> I don't understand. Even if your workspace is stack-based or
>>>> malloc-ed, you
>>>> still need that one GC allocation for the return value, no?
>>>
>>> If you have a path with 20 entries in it, and don't find the
>>> file, you do zero allocations instead of 20. If you find the
>>> file, that's do one allocation instead of 20/2 (on average),
>>> and you might be able to avoid that by passing it upwards, too
>>>
>>> :-)
>>
>> Ah, now I understand. I misunderstood you -- I thought you meant
>> that using ScopeBuffer to build the return array inside
>> buildPath(), while retaining the function's API, would somehow
>> improve its performance greatly. But what you're saying is that
>> you would change the signature as well, to something like this:
>>
>> void buildPath(IR, OR)(IR segments, OR result)
>> if (isInputRange!IR && isOutputRange!(OR, char));
>>
>> I fully agree, then, and I see how ScopeBuffer would be extremely
>> useful if more of Phobos' functions were written like this. In
>> the specific case of buildPath(), I've actually considered
>> letting the user supply their own buffer in the form of an array,
>> but this is of course a more general solution.
>
> We really should be moving to a model where any function that returns a new
> array has on overload which takes an output range and uses that for the output
> instead of returning a newly allocated array. That way, code that doesn't need
> the performance boost can just use the return value like we do now, but more
> performance-critical code can use output ranges and avoid GC allocations and
> the like.
>
> - Jonathan M Davis
>

There quite a few Java libraries that follow this pattern.

--
Paulo

On Saturday, 8 February 2014 at 00:59:35 UTC, Andrei Alexandrescu wrote:
>
> void fun(void* sneaky = alloca(42));
>
> will allocate memory on fun caller's frame and make it available to fun.
>
> I've known this for a while and am not sure whether it's an awesome idiom of the spawn of devil.

Quoting the GNU alloca() man page:

"On many systems alloca() cannot be used inside the list of arguments of a function call, because the stack space reserved by alloca() would appear on the stack in the middle of the space for the function arguments."

So... devil spawn, then?

On 2/7/2014 4:59 PM, Andrei Alexandrescu wrote:
> On 2/7/14, 3:11 PM, Brad Anderson wrote:
>> On Friday, 7 February 2014 at 23:10:50 UTC, Walter Bright wrote:
>>> On 2/7/2014 2:14 PM, Brad Anderson wrote:
>>>>
>>>> There's always alloca :)
>>>
>>> alloca() cannot be used to allocate stack data in a function enclosing
>>> the current one.
>>
>> Oh, right. Forgot about that.
>
> You can with a default parameter...
>
> void fun(void* sneaky = alloca(42));
>
> will allocate memory on fun caller's frame and make it available to fun.

I think there's a bit of a problem in how the user specifies the 42?

On Saturday, 8 February 2014 at 07:43:06 UTC, Lars T. Kyllingstad wrote:
> "On many systems alloca() cannot be used inside the list of arguments of a function call, because the stack space reserved by alloca() would appear on the stack in the middle of the space for the function arguments."
>
> So... devil spawn, then?

alloca() is compiler dependent. LLVM has experimental support for alloca in parameters using a dedicated specification. This is the downside of depending on backends developed for C. For instance if the backend emits code that is relative to the end of the stack rather than the beginning of the stack frame you have to move down all locals whenever you call alloca():

{
BUFFER64K buffer;
auto dynarr = alloca(smallsize); // triggers a copy of 64KiB and fucks up all pointers to buffer
}

If you can rely on indexing relative to the beginning  of the stack frame you just have to change the stack pointer. If you insist on returns of a single dynamic sized temporary being at the end of the stack upon return (+whatever RET eats) you can just move your own stack frame, I believe.

Thus not wasting a lot of space of the caller stack frame and return the length, then the caller can adjust it's own stack pointer by adding the offset+length. And prepending to that dynamic array is cheap in simple function bodies, just push values onto the stack.

But the IR/backend must support it. C-semantics are viral… :-(

On Friday, 7 February 2014 at 11:21:54 UTC, Walter Bright wrote:
> On 2/7/2014 3:00 AM, Dicebot wrote:
>> Do you want this to included into review queue for formal voting?
>
> Sure.

Added to review queue : http://wiki.dlang.org/Review/std.buffer.scopebuffer

Stepping up as a review manager and turning this into initial review thread. Base discussion period is until Feb 17. After that I will make summary of concerns raised for you to either address or reject with own comment and make decision if it is ready to go through voting.

Inofficial list of Phobos quality guidelines can be found here : http://wiki.dlang.org/Phobos_Quality

Good luck.

By the way there was proposal to set up separate mail list for review announcements - who can do it?

On Saturday, 8 February 2014 at 19:37:24 UTC, Dicebot wrote:
> By the way there was proposal to set up separate mail list for review announcements - who can do it?

I'd much rather it be on the newsgroup personally.  It's annoying having to
check both email and the forums.

On Saturday, 8 February 2014 at 19:55:48 UTC, Brad Anderson wrote:
> On Saturday, 8 February 2014 at 19:37:24 UTC, Dicebot wrote:
>> By the way there was proposal to set up separate mail list for review announcements - who can do it?
>
> I'd much rather it be on the newsgroup personally.  It's annoying having to
> check both email and the forums.

NG is OK too (afaik there is mail list gate)