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
next sibling 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 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

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.

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

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


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?


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 "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):

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 =




 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 =




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




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




 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. =20 -Lars

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


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


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


 which got me a bit confused.

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

 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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):


I was about to suggest create, so: create++; -Steve
Sep 02 2011
prev sibling parent "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
prev sibling next 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 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
prev sibling next sibling parent 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
prev sibling 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