On 2/8/2014 4:50 AM, Dicebot wrote:
> 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.

Thanks for taking care of this.

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

I expect that that would make them _less_ visible, as only a certain percentage of people will look at that, and there will be plenty of people who might look at it if they knew about it but won't initially. We already have the announce group for announcements. Why create a new announce group just for reviews - especially when review announcements aren't all that frequent? Even if we were having reviews as fast as we could, it would typically be 2+ weeks between posts.

And if you're proposing that the review itself be done in another list, again, that will cut down on the number of people who see it or pay attention to it.

I see no reason not to just use the newsgroups as they are and send review announcements to digitalmars-d-announce and the reviews be in digitalmars-d. What's wrong with continuing to do it that way?

- Jonathan M Davis

On Sunday, 9 February 2014 at 00:20:32 UTC, Jonathan M Davis wrote:
> On Saturday, February 08, 2014 19:37:23 Dicebot wrote:
>> By the way there was proposal to set up separate mail list for
>> review announcements - who can do it?
>
> I expect that that would make them _less_ visible, as only a certain
> percentage of people will look at that, and there will be plenty of people who
> might look at it if they knew about it but won't initially. We already have
> the announce group for announcements. Why create a new announce group just for
> reviews - especially when review announcements aren't all that frequent? Even
> if we were having reviews as fast as we could, it would typically be 2+ weeks
> between posts.

I notice some people mentioning thet have missed start of review or voting in almost any such thread. D.announce traffic is not that small these days actually, I doubt many will want to subscribe to all its posts to just to be notified about reviews. I don't propose to move discussion there - just make additional notifications identical to those that go to D.announce

In theory it shouldn't be needed but reality has been different so far. And I'd really love to get more participation from Phobos contributors who don't seem to  follow NG _that_ closely.

Counter proposals are highly welcome ;)

Am Sat, 08 Feb 2014 02:13:18 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> 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?

It depends on what syntax you expect. I solved it this way:

void fun(alias length)(void* sneaky = alloca(length));

void foo()
{
    size_t myLength = 42;
    fun!myLength();
}

-- 
Marco

On Sunday, 9 February 2014 at 04:14:05 UTC, Marco Leise wrote:
> It depends on what syntax you expect. I solved it this way:
>
> void fun(alias length)(void* sneaky = alloca(length));
>
> void foo()
> {
>     size_t myLength = 42;
>     fun!myLength();
> }

It defeats the point of alloca if the chunk size has to be known at compile-time. You could just use a void-initialized fixed-length array at that point.

On 02/09/2014 01:12 PM, Jakob Ovrum wrote:
> On Sunday, 9 February 2014 at 04:14:05 UTC, Marco Leise wrote:
>> It depends on what syntax you expect. I solved it this way:
>>
>> void fun(alias length)(void* sneaky = alloca(length));
>>
>> void foo()
>> {
>>     size_t myLength = 42;
>>     fun!myLength();
>> }
>
> It defeats the point of alloca if the chunk size has to be known at
> compile-time. ...

Why would it need to be known at compile time? 42 is just an example here; any other expression will do.

On 2014-02-07 09:24, Walter Bright wrote:
> https://github.com/D-Programming-Language/phobos/pull/1911
>
> This adds a package std.buffer, and the first entry in that package,
> std.buffer.scopebuffer.

Thinking out loud here:

* Could we put this in a more general package, like std.memory.buffer.scopebuffer. Then the upcoming std.allocator could be placed in std.memory.allocator

* Do we have any uses for this in druntime? Perhaps move core.memory to core.memory.gc and put this module in core.memory.buffer.scopebuffer.

-- 
/Jacob Carlborg

On Sunday, 9 February 2014 at 04:14:05 UTC, Marco Leise wrote:
> It depends on what syntax you expect. I solved it this way:
>
> void fun(alias length)(void* sneaky = alloca(length));
>
> void foo()
> {
>     size_t myLength = 42;
>     fun!myLength();
> }

Huge template bloat in current frontend state - new instance of `fun` for every single new function it is used in.

On Sunday, 9 February 2014 at 12:30:56 UTC, Jacob Carlborg wrote:
> * Could we put this in a more general package, like std.memory.buffer.scopebuffer. Then the upcoming std.allocator could be placed in std.memory.allocator

I don't like "buffer" as a package name at all. Probably better approach is to put it in same package with Appender and make it common package for all standard output range implementations.

Its relation to std.allocator is just a (desired) implementation detail.

On Sunday, 9 February 2014 at 12:25:51 UTC, Timon Gehr wrote:
> On 02/09/2014 01:12 PM, Jakob Ovrum wrote:
>> On Sunday, 9 February 2014 at 04:14:05 UTC, Marco Leise wrote:
>>> It depends on what syntax you expect. I solved it this way:
>>>
>>> void fun(alias length)(void* sneaky = alloca(length));
>>>
>>> void foo()
>>> {
>>>    size_t myLength = 42;
>>>    fun!myLength();
>>> }
>>
>> It defeats the point of alloca if the chunk size has to be known at
>> compile-time. ...
>
> Why would it need to be known at compile time? 42 is just an example here; any other expression will do.

Nevermind, didn't see the alias.