www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Review Queue: std.log, std.regionallocator, or something else?

reply dsimcha <dsimcha yahoo.com> writes:
Unless something has changed, the review of std.curl (formerly etc.curl 
but I think there's some agreement now that it should be in std) ends 
today.  (David Naglinger is the review manager.  David, please make this 
official.)

Since we have such an embarrassment of riches lately in terms of new 
modules to be reviewed, we don't want bubbles in the review queue.  The 
first thing we need to decide is whether a review is allowed to run 
concurrently with a vote.  Andrei has suggested that reviews never run 
concurrently with each other, and I agree.  However, since the vote 
stage takes up much less of the community's time, I think it's ok to run 
a review and a vote concurrently with each other.

Either way, here are the potential modules for next in the review queue. 
  Which ones are the highest priority and whether I missed any.

std.log  (Logging module by Jose Armando Garcia.  High priority because 
logging is a standard feature in modern languages.)

std.regionallocator (A segmented stack/region memory allocator, by me. 
I'd like to fast-track this because it's used by two of the GSoC 
projects that were done this summer so getting it into Phobos would 
simplify things.)

CSV parser  (By Jesse Phillips)

std.variant (Massive overhaul that includes runtime reflection, by 
Robert Jacques.)

In case you read my last review queue status post, I've taken 
std.process out of the pool because it needs a runtime fix on windows 
and std.parallel_algorithm because I decided to make it more 
comprehensive and need time to do so.
Aug 31 2011
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 31 Aug 2011 23:56:04 -0400, dsimcha wrote:


 Since we have such an embarrassment of riches lately in terms of new
 modules to be reviewed, we don't want bubbles in the review queue.  The
 first thing we need to decide is whether a review is allowed to run
 concurrently with a vote.  Andrei has suggested that reviews never run
 concurrently with each other, and I agree.  However, since the vote
 stage takes up much less of the community's time, I think it's ok to run
 a review and a vote concurrently with each other.


I don't see any reason why a review can't run concurrently with a vote.  
I say we go ahead with reviewing the region allocator -- the GSoC 
projects should have a high priority.

-Lars
Sep 01 2011
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-09-2011 15:01, Lars T. Kyllingstad wrote:

 On Wed, 31 Aug 2011 23:56:04 -0400, dsimcha wrote:


 Since we have such an embarrassment of riches lately in terms of new
 modules to be reviewed, we don't want bubbles in the review queue.  The
 first thing we need to decide is whether a review is allowed to run
 concurrently with a vote.  Andrei has suggested that reviews never run
 concurrently with each other, and I agree.  However, since the vote
 stage takes up much less of the community's time, I think it's ok to run
 a review and a vote concurrently with each other.


 I don't see any reason why a review can't run concurrently with a vote.
 I say we go ahead with reviewing the region allocator -- the GSoC
 projects should have a high priority.

 -Lars


+1 to this. I'd like to see std.log after std.regionallocator.

Completely unrelated question: What is the naming convention for Phobos 
modules? If the name consists of two words does it become "twowords" or 
"two_words"? I'm just asking because you mentioned parallel_algorithm 
which got me a bit confused.

- Alex
Sep 01 2011
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 01 Sep 2011 15:46:06 +0200, Alex Rønne Petersen wrote:


 On 01-09-2011 15:01, Lars T. Kyllingstad wrote:

 On Wed, 31 Aug 2011 23:56:04 -0400, dsimcha wrote:


 Since we have such an embarrassment of riches lately in terms of new
 modules to be reviewed, we don't want bubbles in the review queue. 
 The first thing we need to decide is whether a review is allowed to
 run concurrently with a vote.  Andrei has suggested that reviews never
 run concurrently with each other, and I agree.  However, since the
 vote stage takes up much less of the community's time, I think it's ok
 to run a review and a vote concurrently with each other.


 I don't see any reason why a review can't run concurrently with a vote.
 I say we go ahead with reviewing the region allocator -- the GSoC
 projects should have a high priority.

 -Lars


 
 +1 to this. I'd like to see std.log after std.regionallocator.
 
 Completely unrelated question: What is the naming convention for Phobos
 modules? If the name consists of two words does it become "twowords" or
 "two_words"? I'm just asking because you mentioned parallel_algorithm
 which got me a bit confused.


I seem to remember this being discussed, and the conclusion being that 
words should be separated with an underscore.

Anyway, I personally don't think the region allocator should have its own 
module, it should be in std.allocator or something like that.  AFAIK, the 
plan is to have multiple allocators adhering to the same interface.  But 
that's probably a discussion for the review. ;)

-Lars
Sep 01 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s

 Anyway, I personally don't think the region allocator should have its own
 module, it should be in std.allocator or something like that.  AFAIK, the
 plan is to have multiple allocators adhering to the same interface.  But
 that's probably a discussion for the review. ;)
 -Lars


If we want to do that,

Code:

https://github.com/dsimcha/TempAlloc
(regionallocator.d is the main proposal, gcallocator.d is a throw-in wrapper
around the garbage collector to create a standard allocator interface to it. 
The
repo is named TempAlloc because that's what the module used to be called before
its overhaul.)

Docs:

http://cis.jhu.edu/~dsimcha/d/phobos/std_regionallocator.html
(I forgot to compile the docs to gcallocator.  I'll do that at some point, but I
expect the vast majority of the discussion to be about regionallocator anyhow,
since gcallocator is just a trivial wrapper.)

One more thing:  std.regionallocator should **probably** be
std.allocators.regionallocator, but I'm too lazy to change this until we
officially settle on this as a name.
Sep 01 2011
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 9/1/11 4:28 PM, dsimcha wrote:

 If we want to do that,

 Code:

 https://github.com/dsimcha/TempAlloc
 (regionallocator.d is the main proposal, gcallocator.d is a throw-in wrapper
 around the garbage collector to create a standard allocator interface to it. 
The
 repo is named TempAlloc because that's what the module used to be called before
 its overhaul.)

 Docs:

 http://cis.jhu.edu/~dsimcha/d/phobos/std_regionallocator.html
 (I forgot to compile the docs to gcallocator.  I'll do that at some point, but
I
 expect the vast majority of the discussion to be about regionallocator anyhow,
 since gcallocator is just a trivial wrapper.)

 One more thing:  std.regionallocator should **probably** be
 std.allocators.regionallocator, but I'm too lazy to change this until we
 officially settle on this as a name.


Okay, etc.curl is suspended for the time being, let's move on swiftly!

Personally, I think it would be great to review David's region allocator 
soon, both because it is used by two GSoC projects, and because a 
well-defined memory allocator interface is key for successful 
improvements in other areas, e.g. containers.

Other suggestions?

Jonathan, as I somewhat cheated you out of your post for etc.curl, do 
you maybe want to volunteer as the review manager? If nobody else is 
inclined to do so, I guess I step up again as well (I even would have 
more time to spend on it than for the etc.curl one), but I'd rather not 
fill this role twice in a row.

David
Sep 01 2011
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, September 01, 2011 10:17 David Nadlinger wrote:

 On 9/1/11 4:28 PM, dsimcha wrote:

 If we want to do that,
 
 Code:
 
 https://github.com/dsimcha/TempAlloc
 (regionallocator.d is the main proposal, gcallocator.d is a throw-in
 wrapper around the garbage collector to create a standard allocator
 interface to it. The repo is named TempAlloc because that's what the
 module used to be called before its overhaul.)
 
 Docs:
 
 http://cis.jhu.edu/~dsimcha/d/phobos/std_regionallocator.html
 (I forgot to compile the docs to gcallocator. I'll do that at some
 point, but I expect the vast majority of the discussion to be about
 regionallocator anyhow, since gcallocator is just a trivial wrapper.)
 
 One more thing: std.regionallocator should **probably** be
 std.allocators.regionallocator, but I'm too lazy to change this until we
 officially settle on this as a name.


 
 Okay, etc.curl is suspended for the time being, let's move on swiftly!
 
 Personally, I think it would be great to review David's region allocator
 soon, both because it is used by two GSoC projects, and because a
 well-defined memory allocator interface is key for successful
 improvements in other areas, e.g. containers.
 
 Other suggestions?
 
 Jonathan, as I somewhat cheated you out of your post for etc.curl, do
 you maybe want to volunteer as the review manager? If nobody else is
 inclined to do so, I guess I step up again as well (I even would have
 more time to spend on it than for the etc.curl one), but I'd rather not
 fill this role twice in a row.


I'll do it if no one else wants to, but I'm in no hurry to volunteer. I just 
volunteered before because no one else had. I'm not unwilling, but I'm far 
from eager. I do think that it makes sense that you not have to do it twice in 
a row though.

- Jonathan M Davis
Sep 01 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-09-01 16:28, dsimcha wrote:

 == Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s

 Anyway, I personally don't think the region allocator should have its own
 module, it should be in std.allocator or something like that.  AFAIK, the
 plan is to have multiple allocators adhering to the same interface.  But
 that's probably a discussion for the review. ;)
 -Lars


 If we want to do that,

 Code:

 https://github.com/dsimcha/TempAlloc
 (regionallocator.d is the main proposal, gcallocator.d is a throw-in wrapper
 around the garbage collector to create a standard allocator interface to it. 
The
 repo is named TempAlloc because that's what the module used to be called before
 its overhaul.)

 Docs:

 http://cis.jhu.edu/~dsimcha/d/phobos/std_regionallocator.html
 (I forgot to compile the docs to gcallocator.  I'll do that at some point, but
I
 expect the vast majority of the discussion to be about regionallocator anyhow,
 since gcallocator is just a trivial wrapper.)

 One more thing:  std.regionallocator should **probably** be
 std.allocators.regionallocator, but I'm too lazy to change this until we
 officially settle on this as a name.


I think it's unnecessary to repeat "allocator" in the module name if the 
module is already in the allocators package.

-- 
/Jacob Carlborg
Sep 01 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/01/2011 04:28 PM, dsimcha wrote:

 == Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s

 Anyway, I personally don't think the region allocator should have its own
 module, it should be in std.allocator or something like that.  AFAIK, the
 plan is to have multiple allocators adhering to the same interface.  But
 that's probably a discussion for the review. ;)
 -Lars


 If we want to do that,

 Code:

 https://github.com/dsimcha/TempAlloc
 (regionallocator.d is the main proposal, gcallocator.d is a throw-in wrapper
 around the garbage collector to create a standard allocator interface to it. 
The
 repo is named TempAlloc because that's what the module used to be called before
 its overhaul.)
 [snip.]


Allocating a class or struct instance with a given allocator seems not 
to be part of the standard allocator interface. Why is that?

(their implementations would be almost identical between most 
allocators, but the same could be said about the newArray etc. member 
functions)

I am really looking forward to having a region allocator. Thanks!
Sep 01 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Timon Gehr (timon.gehr gmx.ch)'s article

 Allocating a class or struct instance with a given allocator seems not
 to be part of the standard allocator interface. Why is that?


Pure oversight.  This should probably be fixed.


 (their implementations would be almost identical between most
 allocators, but the same could be said about the newArray etc. member
 functions)


newArray, etc. weren't in Andrei's initial proposal.  I added them because an
allocator might want to do something "special" given type info.
Sep 01 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from dsimcha (dsimcha yahoo.com)'s article

 == Quote from Timon Gehr (timon.gehr gmx.ch)'s article

 Allocating a class or struct instance with a given allocator seems not
 to be part of the standard allocator interface. Why is that?


 Pure oversight.  This should probably be fixed.


BTW, any suggestions for a name for a function like this?  I can't think of a
good
one.
Sep 01 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/02/2011 06:20 AM, dsimcha wrote:

 == Quote from dsimcha (dsimcha yahoo.com)'s article

 == Quote from Timon Gehr (timon.gehr gmx.ch)'s article

 Allocating a class or struct instance with a given allocator seems not
 to be part of the standard allocator interface. Why is that?


 Pure oversight.  This should probably be fixed.


 BTW, any suggestions for a name for a function like this?  I can't think of a
good
 one.


Best suited would be 'New', but that would probably be against Phobos 
naming conventions (we could add an exception for names that would 
otherwise be keywords):

alloc.New!MyClass(arg1, arg2);

with(alloc) New!MyClass(arg1, arg2);

Others:

'instanceAlloc' or 'newInstance' (or 'instAlloc' or 'newInst'):

alloc.instanceAlloc!MyClass(arg1, arg2);
alloc.newInstance!MyClass(arg1, arg2);


Just 'instantiate' or 'instance':

alloc.instantiate!MyClass(arg1, arg2);
alloc.instance!MyClass(arg1, arg2);
Sep 02 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:j3q9o4$j3k$1 digitalmars.com...

 BTW, any suggestions for a name for a function like this?  I can't think 
 of a good
 one.


 Best suited would be 'New', but that would probably be against Phobos 
 naming conventions (we could add an exception for names that would 
 otherwise be keywords):


create, construct?
Sep 02 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 02 Sep 2011 09:43:38 -0400, Daniel Murphy  
<yebblies nospamgmail.com> wrote:


 "Timon Gehr" <timon.gehr gmx.ch> wrote in message
 news:j3q9o4$j3k$1 digitalmars.com...

 BTW, any suggestions for a name for a function like this?  I can't  
 think
 of a good
 one.


 Best suited would be 'New', but that would probably be against Phobos
 naming conventions (we could add an exception for names that would
 otherwise be keywords):


 create, construct?


I was about to suggest create, so:

create++;

-Steve
Sep 02 2011
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s article

 Anyway, I personally don't think the region allocator should have its own
 module, it should be in std.allocator or something like that.  AFAIK, the
 plan is to have multiple allocators adhering to the same interface.  But
 that's probably a discussion for the review. ;)
 -Lars


My concern with this is threefold:

1.  A single module with a whole bunch of allocators would get quite unwieldy.
std.regionallocator by itself is about 2k lines.

2.  I don't want to give the impression that I've implemented a comprehensive
suite of allocators as std.allocator would imply.  I haven't.  I've implemented
one important one to kick things off, plus a trivial wrapper.

3.  I think any new allocator is a big enough thing that it should go through a
full-fledged "new module" review.
Sep 01 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, September 01, 2011 14:05:37 Lars T. Kyllingstad wrote:

 On Thu, 01 Sep 2011 15:46:06 +0200, Alex R=C3=B8nne Petersen wrote:

 On 01-09-2011 15:01, Lars T. Kyllingstad wrote:

 On Wed, 31 Aug 2011 23:56:04 -0400, dsimcha wrote:

 Since we have such an embarrassment of riches lately in terms of =








new

 modules to be reviewed, we don't want bubbles in the review queue=








.

 The first thing we need to decide is whether a review is allowed =








to

 run concurrently with a vote.  Andrei has suggested that reviews
 never
 run concurrently with each other, and I agree.  However, since th=








e

 vote stage takes up much less of the community's time, I think it=








's

 ok
 to run a review and a vote concurrently with each other.


=20
 I don't see any reason why a review can't run concurrently with a
 vote.
 I say we go ahead with reviewing the region allocator -- the GSoC
 projects should have a high priority.
=20
 -Lars


=20
 +1 to this. I'd like to see std.log after std.regionallocator.
=20
 Completely unrelated question: What is the naming convention for Ph=




obos

 modules? If the name consists of two words does it become "twowords=




" or

 "two_words"? I'm just asking because you mentioned parallel_algorit=




hm

 which got me a bit confused.


=20
 I seem to remember this being discussed, and the conclusion being tha=


t

 words should be separated with an underscore.


And I would have said the opposite. Certainly, all existing modules are=
 all=20
lowercase and have no underscores. One with underscores would stand out=
 like a=20
sore thumb.

- Jonathan M Davis
Sep 01 2011
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Alex Rønne Petersen (xtzgzorex gmail.com)'s article

 On 01-09-2011 15:01, Lars T. Kyllingstad wrote:

 On Wed, 31 Aug 2011 23:56:04 -0400, dsimcha wrote:


 Since we have such an embarrassment of riches lately in terms of new
 modules to be reviewed, we don't want bubbles in the review queue.  The
 first thing we need to decide is whether a review is allowed to run
 concurrently with a vote.  Andrei has suggested that reviews never run
 concurrently with each other, and I agree.  However, since the vote
 stage takes up much less of the community's time, I think it's ok to run
 a review and a vote concurrently with each other.


 I don't see any reason why a review can't run concurrently with a vote.
 I say we go ahead with reviewing the region allocator -- the GSoC
 projects should have a high priority.

 -Lars


 +1 to this. I'd like to see std.log after std.regionallocator.
 Completely unrelated question: What is the naming convention for Phobos
 modules? If the name consists of two words does it become "twowords" or
 "two_words"? I'm just asking because you mentioned parallel_algorithm
 which got me a bit confused.
 - Alex


Beats me.  I was actually hoping we'd discuss that in the upcoming reviews.  I'm
not at all adverse to changing the name of std.parallel_algorithm or making a
std.allocators package to put RegionAllocator in.  (The latter will almost
certainly happen since the proposal now includes a wrapper struct to wrap the GC
in an allocator interface as a throw-in.  We can't have a top-level
std.regionallocator and std.gcallocator.  This would be ridiculous.)  I regard
these names as provisional.
Sep 01 2011
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 9/1/11 4:06 PM, dsimcha wrote:

 == Quote from Alex Rønne Petersen (xtzgzorex gmail.com)'s article

 […]
 Completely unrelated question: What is the naming convention for Phobos
 modules? If the name consists of two words does it become "twowords" or
 "two_words"? I'm just asking because you mentioned parallel_algorithm
 which got me a bit confused.


 Beats me.  I was actually hoping we'd discuss that in the upcoming reviews. 
I'm
 not at all adverse to changing the name of std.parallel_algorithm or making a
 std.allocators package to put RegionAllocator in.  (The latter will almost
 certainly happen since the proposal now includes a wrapper struct to wrap the
GC
 in an allocator interface as a throw-in.  We can't have a top-level
 std.regionallocator and std.gcallocator.  This would be ridiculous.)  I regard
 these names as provisional.


I agree on both points: Now that it looks like we are settling for a 
common allocator interface (Andrei, keep your ideas and comments coming, 
at least I find them very interesting ;)), a package for various 
implementations seems like a good idea to me.

And yes, all names should be regarded provisional unless the 
functionality in question is merged in – Jonas will probably rename 
etc.curl to std.curl as well, but still we need a handle for it during 
the review process.

David
Sep 01 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-09-01 16:14, David Nadlinger wrote:

 I agree on both points: Now that it looks like we are settling for a
 common allocator interface (Andrei, keep your ideas and comments coming,
 at least I find them very interesting ;)), a package for various
 implementations seems like a good idea to me.


I think that there should be a package for allocators.


 And yes, all names should be regarded provisional unless the
 functionality in question is merged in – Jonas will probably rename
 etc.curl to std.curl as well, but still we need a handle for it during
 the review process.

 David


BTW, shouldn't std/etc.curl be std.net.curl now when we have a std.net 
package.

-- 
/Jacob Carlborg
Sep 01 2011
prev sibling parent reply Don <nospam nospam.com> writes:
On 01.09.2011 16:06, dsimcha wrote:

 == Quote from Alex Rønne Petersen (xtzgzorex gmail.com)'s article

 On 01-09-2011 15:01, Lars T. Kyllingstad wrote:

 On Wed, 31 Aug 2011 23:56:04 -0400, dsimcha wrote:


 Since we have such an embarrassment of riches lately in terms of new
 modules to be reviewed, we don't want bubbles in the review queue.  The
 first thing we need to decide is whether a review is allowed to run
 concurrently with a vote.  Andrei has suggested that reviews never run
 concurrently with each other, and I agree.  However, since the vote
 stage takes up much less of the community's time, I think it's ok to run
 a review and a vote concurrently with each other.


 I don't see any reason why a review can't run concurrently with a vote.
 I say we go ahead with reviewing the region allocator -- the GSoC
 projects should have a high priority.

 -Lars


 +1 to this. I'd like to see std.log after std.regionallocator.
 Completely unrelated question: What is the naming convention for Phobos
 modules? If the name consists of two words does it become "twowords" or
 "two_words"? I'm just asking because you mentioned parallel_algorithm
 which got me a bit confused.
 - Alex


 Beats me.  I was actually hoping we'd discuss that in the upcoming reviews. 
I'm
 not at all adverse to changing the name of std.parallel_algorithm or making a
 std.allocators package to put RegionAllocator in.  (The latter will almost
 certainly happen since the proposal now includes a wrapper struct to wrap the
GC
 in an allocator interface as a throw-in.  We can't have a top-level
 std.regionallocator and std.gcallocator.  This would be ridiculous.)  I regard
 these names as provisional.


While on this bikeshedding issue -- the name 'regionallocator' is 
horribly long for such an important object. I think if it stays with a 
long-winded name, it won't be used as frequently as it deserves.
Sep 01 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 9/1/11 8:45 PM, Don wrote:

 While on this bikeshedding issue -- the name 'regionallocator' is
 horribly long for such an important object. I think if it stays with a
 long-winded name, it won't be used as frequently as it deserves.


I guess std.alloc.region.RegionAlloc is about the shortest viable symbol 
name before it gets too confusing.

David
Sep 01 2011
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 01 Sep 2011 14:58:07 -0400, David Nadlinger <see klickverbot.at> wrote:


 On 9/1/11 8:45 PM, Don wrote:

 While on this bikeshedding issue -- the name 'regionallocator' is
 horribly long for such an important object. I think if it stays with a
 long-winded name, it won't be used as frequently as it deserves.


 I guess std.alloc.region.RegionAlloc is about the shortest viable symbol
 name before it gets too confusing.

 David


Given names like Malloc, REalloc, allocA, Calloc and Qalloc, what's wrong with
either ralloc, allocr or some other letter + alloc combination?
Sep 02 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 02.09.2011, 14:54 Uhr, schrieb Robert Jacques <sandford jhu.edu>:


 On Thu, 01 Sep 2011 14:58:07 -0400, David Nadlinger <see klickverbot.at>  
 wrote:


 On 9/1/11 8:45 PM, Don wrote:

 While on this bikeshedding issue -- the name 'regionallocator' is
 horribly long for such an important object. I think if it stays with a
 long-winded name, it won't be used as frequently as it deserves.


 I guess std.alloc.region.RegionAlloc is about the shortest viable symbol
 name before it gets too confusing.

 David


 Given names like Malloc, REalloc, allocA, Calloc and Qalloc, what's  
 wrong with either ralloc, allocr or some other letter + alloc  
 combination?


As a Java user, I agree with Lars on the naming. This is convenient for  
the user:

atd.allocator.GcAllocator
std.allocator.BikeshedAllocator
std.allocator.RegionAllocator

But it will make std/allocator.d grow, maybe to big. (In Java these would  
still be three files.)
So David's proposal looks like the best compromise to me.

std.alloc[ator[s]].region.R[egion]Alloc[ator] :)

Since we already have a lot of std modules and I'm sometimes overwhelmed  
when I look for something on the D home page, I would prefer a speaking  
name for the top level at least. So allocator[s] instead of alloc (which  
misleads me to think of low-level C API functionality). YMMV.
Sep 02 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/02/2011 04:47 PM, Marco Leise wrote:

 Am 02.09.2011, 14:54 Uhr, schrieb Robert Jacques <sandford jhu.edu>:


 On Thu, 01 Sep 2011 14:58:07 -0400, David Nadlinger
 <see klickverbot.at> wrote:


 On 9/1/11 8:45 PM, Don wrote:

 While on this bikeshedding issue -- the name 'regionallocator' is
 horribly long for such an important object. I think if it stays with a
 long-winded name, it won't be used as frequently as it deserves.


 I guess std.alloc.region.RegionAlloc is about the shortest viable symbol
 name before it gets too confusing.

 David


 Given names like Malloc, REalloc, allocA, Calloc and Qalloc, what's
 wrong with either ralloc, allocr or some other letter + alloc
 combination?


 As a Java user, I agree with Lars on the naming. This is convenient for
 the user:

 atd.allocator.GcAllocator
 std.allocator.BikeshedAllocator
 std.allocator.RegionAllocator

 But it will make std/allocator.d grow, maybe to big. (In Java these
 would still be three files.)


What about

std/allocator.d:

public import impl.allocator.gcalloc;
public import impl.allocator.bsalloc;
public import impl.allocator.realloc;

?
Sep 02 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, August 31, 2011 23:56:04 dsimcha wrote:

 Unless something has changed, the review of std.curl (formerly etc.curl
 but I think there's some agreement now that it should be in std) ends
 today.  (David Naglinger is the review manager.  David, please make this
 official.)
 
 Since we have such an embarrassment of riches lately in terms of new
 modules to be reviewed, we don't want bubbles in the review queue.  The
 first thing we need to decide is whether a review is allowed to run
 concurrently with a vote.  Andrei has suggested that reviews never run
 concurrently with each other, and I agree.  However, since the vote
 stage takes up much less of the community's time, I think it's ok to run
 a review and a vote concurrently with each other.
 
 Either way, here are the potential modules for next in the review queue.
   Which ones are the highest priority and whether I missed any.
 
 std.log  (Logging module by Jose Armando Garcia.  High priority because
 logging is a standard feature in modern languages.)
 
 std.regionallocator (A segmented stack/region memory allocator, by me.
 I'd like to fast-track this because it's used by two of the GSoC
 projects that were done this summer so getting it into Phobos would
 simplify things.)
 
 CSV parser  (By Jesse Phillips)
 
 std.variant (Massive overhaul that includes runtime reflection, by
 Robert Jacques.)
 
 In case you read my last review queue status post, I've taken
 std.process out of the pool because it needs a runtime fix on windows
 and std.parallel_algorithm because I decided to make it more
 comprehensive and need time to do so.


Given that no one else other than David Nadlinger (who just was the review 
manager, so he shouldn't have to do it this time around) has volunteered to be 
the review manager for the next round, I guess that I'll volunteer to do it. 
And based on this discussion, it looks like the region allocator is next.

dsimcha, is there any reason not to start the review of the region allocator 
shortly? Does a review period of about 2 weeks, ending on Wednesday, the 21st 
sound good?

- Jonathan M Davis
Sep 05 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article

 dsimcha, is there any reason not to start the review of the region allocator
 shortly? Does a review period of about 2 weeks, ending on Wednesday, the 21st
 sound good?
 - Jonathan M Davis


Sounds perfect.  Thanks.  A few issues that I'd like mentioned in the initial
announcement because they need to be examined:

1.  This is both a proposal for RegionAllocator and a proposal for a more
general
allocator API in Phobos.  The allocator API will be a structural interface that
includes the intersection of gcallocator and regionallocator functionality.  I
don't have a more precise definition yet.  Hopefully the review process will
hammer out whatever ambiguities remain.

2.  Should we put this stuff in a std.allocators package, in a single
std.allocators module, or something else?

3.  We definitely want a reap (combination region and heap) eventually, though I
don't have one yet.  I want RegionAllocator to be reviewed for anything that
would
make it unnecessarily hard to write other allocators on top of it, most
importantly reaps but also free lists, etc.
Sep 05 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-09-06 02:33, dsimcha wrote:

 == Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article

 dsimcha, is there any reason not to start the review of the region allocator
 shortly? Does a review period of about 2 weeks, ending on Wednesday, the 21st
 sound good?
 - Jonathan M Davis


 Sounds perfect.  Thanks.  A few issues that I'd like mentioned in the initial
 announcement because they need to be examined:

 1.  This is both a proposal for RegionAllocator and a proposal for a more
general
 allocator API in Phobos.  The allocator API will be a structural interface that
 includes the intersection of gcallocator and regionallocator functionality.  I
 don't have a more precise definition yet.  Hopefully the review process will
 hammer out whatever ambiguities remain.

 2.  Should we put this stuff in a std.allocators package, in a single
 std.allocators module, or something else?


We should put this stuff in a std.allocators package, we definitely do 
NOT want yet another enormous module, yes I'm looking at you std.datetime.


 3.  We definitely want a reap (combination region and heap) eventually, though
I
 don't have one yet.  I want RegionAllocator to be reviewed for anything that
would
 make it unnecessarily hard to write other allocators on top of it, most
 importantly reaps but also free lists, etc.



-- 
/Jacob Carlborg
Sep 05 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, September 06, 2011 00:33:20 dsimcha wrote:

 == Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 

 dsimcha, is there any reason not to start the review of the region
 allocator shortly? Does a review period of about 2 weeks, ending on
 Wednesday, the 21st sound good?
 - Jonathan M Davis


 
 Sounds perfect.  Thanks.  A few issues that I'd like mentioned in the
 initial announcement because they need to be examined:
 
 1.  This is both a proposal for RegionAllocator and a proposal for a more
 general allocator API in Phobos.  The allocator API will be a structural
 interface that includes the intersection of gcallocator and regionallocator
 functionality.  I don't have a more precise definition yet.  Hopefully the
 review process will hammer out whatever ambiguities remain.
 
 2.  Should we put this stuff in a std.allocators package, in a single
 std.allocators module, or something else?
 
 3.  We definitely want a reap (combination region and heap) eventually,
 though I don't have one yet.  I want RegionAllocator to be reviewed for
 anything that would make it unnecessarily hard to write other allocators on
 top of it, most importantly reaps but also free lists, etc.


Can you provide a link to the current code and documentation so that I can 
post the start of the review? And do you want to provide a more in depth 
description than

-----------
std.regionallocator (A segmented stack/region memory allocator, by me. 
I'd like to fast-track this because it's used by two of the GSoC 
projects that were done this summer so getting it into Phobos would 
simplify things.)
-----------

which is what you previously posted?

- Jonathan M Davis
Sep 06 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
On 9/6/2011 4:42 AM, Jonathan M Davis wrote:

 Can you provide a link to the current code and documentation so that I can
 post the start of the review? And do you want to provide a more in depth
 description than

 -----------
 std.regionallocator (A segmented stack/region memory allocator, by me.
 I'd like to fast-track this because it's used by two of the GSoC
 projects that were done this summer so getting it into Phobos would
 simplify things.)
 -----------

 which is what you previously posted?

 - Jonathan M Davis


Docs:

http://cis.jhu.edu/~dsimcha/d/phobos/std_regionallocator.html

Code:

https://github.com/dsimcha/TempAlloc

Description (from docs):

RegionAllocator is a memory allocator based on segmented stacks. A 
segmented stack is similar to a regular stack in that memory is 
allocated and freed in last in, first out order. When memory is 
requested from a segmented stack, it first checks whether enough space 
is available in the current segment, and if so increments the stack 
pointer and returns. If not, a new segment is allocated. When memory is 
freed, the stack pointer is decremented. If the last segment is no 
longer in use, it may be returned to where it was allocated from or 
retained for future use.
Sep 06 2011
parent Jose Armando Garcia <jsancio gmail.com> writes:
On Tue, Sep 6, 2011 at 7:33 AM, dsimcha <dsimcha yahoo.com> wrote:

 RegionAllocator is a memory allocator based on segmented stacks. A segmented
 stack is similar to a regular stack in that memory is allocated and freed in
 last in, first out order. When memory is requested from a segmented stack,
 it first checks whether enough space is available in the current segment,
 and if so increments the stack pointer and returns. If not, a new segment is
 allocated. When memory is freed, the stack pointer is decremented. If the
 last segment is no longer in use, it may be returned to where it was
 allocated from or retained for future use.


Can't wait to review this. Just a small note. Isn't this description
implementation specific? We should describe the minimum possible to
describe the contract. To me that is that memory is free last alloc
first.
Sep 07 2011